# Meet-join skill — Agent Instructions

All Meet runtime code lives under this directory. The daemon module, tools,
routes, config schema, wire-contracts, and Meet-bot container image are all
consolidated here so the skill can evolve — or be lifted out of the repo
entirely — without hunting down scattered references across the monorepo.

## The isolation rule

The `assistant/` module must never import from `skills/meet-join/` via
relative paths, and `skills/meet-join/` must never import from `assistant/`.
Both directions are enforced by `assistant/src/__tests__/skill-boundary-guard.test.ts`.

Meet-join runs as a separate `bun run` subprocess. The daemon ships
this directory's source plus a generated `manifest.json` alongside its
binary; on startup it installs proxy tools/routes/hooks from the manifest
and spawns the meet-host child on first invocation via the
`assistant-skill.sock` IPC socket. See `assistant/src/daemon/meet-host-startup.ts`
and `assistant/src/daemon/meet-host-supervisor.ts` for the daemon side.

Skills wire into the assistant through the `SkillHost` contract from
`@vellumai/skill-host-contracts`. The meet-host entrypoint constructs a
`SkillHostClient` against the IPC socket and passes it to `register(host)`;
the skill uses `host.registries.*` instead of direct imports from `assistant/`:

- **Tools**: `host.registries.registerTools(() => [...])`
- **Routes**: `host.registries.registerSkillRoute({ pattern, methods, handler })`
- **Shutdown**: `host.registries.registerShutdownHook(name, hook)`

Sub-modules (`audio-ingest`, `speaker-resolver`, `tts-bridge`, …)
expose host-accepting factories and register them into
`daemon/modules-registry.ts`. The session manager resolves those
factories by name through `getSubModule`, so adding a new sub-module
does not require editing `register.ts`.

The meet skill owns its config schema (`config-schema.ts`) and reads its
configuration from `<workspace>/config/meet.json` via `meet-config.ts`. The
workspace directory is supplied by the caller (`host.platform.workspaceDir()`
in production). The assistant's global `config.json` does not contain meet
configuration.

## When you need a new external reference

Before adding a new reference to `skills/meet-join/` from outside the skill,
check whether the new code could instead live inside `skills/meet-join/` or be
moved into `assistant/src/`.

## Central registries that stay put

A handful of central files reference Meet by design — they are per-domain
entries in a repo-wide registry, and splitting one entry out into the skill
would break the "one file per domain" pattern the registry relies on. These
are **not** candidates for relocation into `skills/meet-join/`:

- **`assistant/src/daemon/message-types/meet.ts`** — the Meet entry in the
  daemon-client SSE wire-protocol index. Each domain has one file here
  (`apps.ts`, `browser.ts`, `contacts.ts`, etc.), all re-exported from
  `assistant/src/daemon/message-protocol.ts`. Meet's server->client push
  message shapes (e.g. `MeetJoined`, `MeetTranscriptChunk`) live in this
  file alongside every other domain's wire types. This is protocol-level
  surface, not runtime code.

- **`meta/feature-flags/feature-flag-registry.json`** — the central
  declaration of every assistant feature flag, including `meet`. This is
  the canonical flag registry; per-flag entries are not relocated to
  owning skills.

## Browser control: the extension package (`meet-controller-ext/`)

Browser-side Meet control lives in the sibling `meet-controller-ext/`
package, NOT in `bot/`. The bot launches google-chrome-stable as a plain
subprocess with `--load-extension=/app/ext` (where `/app/ext` is the
built output of `meet-controller-ext/`). Bot ↔ extension communication
flows through Chrome Native Messaging over a Unix socket owned by the
bot process.

**Rationale**: Playwright-driven Chrome is detected by Meet's BotGuard;
we use a real Chrome subprocess with a bundled extension instead. Any
attempt to reintroduce CDP (`--remote-debugging-port`,
`--enable-automation`, Playwright, Puppeteer) will fail at the Meet
prejoin surface. See `.private/plans/archived/meet-phase-1-11-chrome-extension.md`
for the empirical repro.

**Where each piece lives**:

- `meet-controller-ext/src/features/` — in-page logic: `join.ts`,
  `participants.ts`, `speaker.ts`, `chat.ts`.
- `meet-controller-ext/src/dom/` — Meet DOM selectors + wait helpers,
  with fixture-backed tests under `src/dom/__tests__/`.
- `meet-controller-ext/src/messaging/` — extension-side transport to
  the bot's native messaging host.
- `bot/src/native-messaging/` — bot-side socket server + NMH shim.
- `contracts/native-messaging.ts` — zod-validated wire protocol for
  `BotToExtensionMessage` / `ExtensionToBotMessage`.

Do not re-introduce Playwright or any CDP-based automation library into
`bot/`. See `bot/AGENTS.md` for the bot-side architecture.

## Release gating

The `meet` feature flag defaults to **off** in
`meta/feature-flags/feature-flag-registry.json`. Turning it on in
production requires both of the following to be true:

1. All Blocking and Important PRs in the Phase 1.12 plan have landed on
   `main` and been live-verified (no regressions against a real Meet).
2. The LaunchDarkly provisioning PR in `vellum-assistant-platform` has
   merged, creating the Terraform entry for `meet` so the platform can
   remote-sync the flag to managed assistants. This companion PR is
   tracked in `meta/feature-flags/PENDING_PLATFORM_PRS.md` — the entry
   there should be removed once the platform PR lands.

Until both conditions are met, the flag must stay off for all users
outside the local development environment.