[arcaven]

A Claude Code seat that takes mail is never woken while it sits idle unless the channel cue is on, and the getting-started page and the shim reference do not say so, so an operator who starts a seat by hand learns it by missing mail. This adds the two settings that turn the cue on and the startup prompt they bring, so a seat that should wake is started correctly the first time.

docs/getting-started.md section 4 gains one subsection after the dialog note and the join checks. It gives DIRECTOR_CUE=1 in the shim's env and --dangerously-load-development-channels server:director on the claude command line, with the per-invocation form shown with both added. It says the flag brings a one-time startup prompt that needs a person to answer it, that a seat without the cue reads mail only when it polls, and that the cue is enabled only for the client protocol version it was measured on, so a release that changes it leaves a seat with both settings never woken. Arrivals close together fold into one notice, and no notice is sent while a wait is open. docs/shim-reference.md gains a DIRECTOR_CUE row in the Environment section.

Docs only; no code, README or script changes. The README launcher text waits for the launcher PR.

Facts are from cmd/director-mcp/cue.go (only the exact value 1 enables it), sim/design/channel-cue.md and the director-session launcher's own notice about the startup prompt.

Check: git grep -nE 'DIRECTOR_CUE=1' -- docs/getting-started.md docs/shim-reference.md hits both files, and git grep -n 'development-channels' -- docs/getting-started.md hits the same subsection.

[arcavenai]

REQUEST_CHANGES at 7a39cc6, on two sentences in the new getting-started text. Each states a cue behaviour that cue.go does not have. A reader who follows them will watch for the wrong thing when a seat does not wake. Both fixes are short rewordings, and everything else in the new text matches the code and the design.

Blocker 1: the cue is not one notice per arrival. docs/getting-started.md:188-189 says the shim sends "one notice per arrival, naming the sender, the performative and the message id". In the code, three things differ:

• Coalescing. Arrivals within the floor after a cue (5 s) fold into one cue carrying meta.count (cmd/director-mcp/cue.go:435, :450-456; sim/design/channel-cue.md:137-140: "A roll call of thirty replies is at most one cue per floor").
• Which message it names. The meta names the oldest waiting message, not each arrival (cue.go:450; design :141-142).
• Open waits. No cue is sent while a wait_for_message is open (cue.go:426-428; design :133-136). An unanswered cue is sent once more after W (cue.go:437-443; design :163-166).

Something like "one notice when mail arrives (arrivals within a few seconds share one, with a count), naming the sender, performative and message id of the oldest waiting message" would match. The shim-reference row's "when mail arrives" (docs/shim-reference.md:64) is already right.

Blocker 2: there is a third outcome, off. :209-210 says that after the prompt the shim reports the cue "live once the model answers it, or unverified if it does not". The cue turns on only when the client's MCP protocol version is on the measured list, which today is 2025-11-25 (cue.go:56). Any other version answers as before, with no channel declared, and the cue stays off with the reason "protocol not verified" (cue.go:160-169, called from mcp.go:183; design :227). So a Claude Code release that moves its protocol version gives a seat that has both settings and still never wakes. The cue state then reads off, not unverified. One clause would cover it: "or off, with the reason, if this Claude Code's protocol version is not one the cue was measured on".

Low: "no effect on a codex session" rests on the launcher, not the shim. :211 matches the launcher, which says the same and adds no flag under codex (skills/director/scripts/director-session:252-253). The shim, though, gates on the client's protocol version, not on the harness (mcp.go:176-185). The codex 0.154.0 binary carries the string 2025-11-25, which is evidence only, since I did not run codex. If codex sends that version, a shim with DIRECTOR_CUE=1 declares the channel and sends notices that codex does not act on. The self-test would then go unechoed (cue.go:388), and the presence would read unverified. "codex does not act on the cue" would hold either way.

What I checked

• The variable and value. Only the exact value 1 turns it on: os.Getenv("DIRECTOR_CUE") == "1" (cue.go:67-69). That matches :194 and the shim-reference row (docs/shim-reference.md:60, :64).
• The flag and the server name.
  • The flag --dangerously-load-development-channels server:<name> matches the design (channel-cue.md:37) and the launcher, which uses server:director for the per-invocation form (director-session:276, :346).
  • The command block is the existing recommended form (docs/getting-started.md:140-141), with only the flag and "DIRECTOR_CUE":"1" added. The JSON is the same apart from those keys.
  • The note that director is the name the server is registered under is right: the persistent form registers director-mcp (:153), so server:director would be wrong there, and the text says so.
• The command line is unexecuted. As the body says, I did not run it either: it starts a live shim against a bus. I checked it by reading only.
• The startup prompt. The quoted wording matches the C-0 capture (_kos/findings/finding-016-the-channel-cue-on-one-seat-c0-results.md:30-35) and the fixture in skills/director/scripts/verify-freebusy.sh:518. "Needs a person" matches the launcher, which never answers it (director-session:58-60).
• Self-test. The self-test is sent after initialize (cue.go:172-185), resent with backoff, and live only on a nonce echo (cue.go:193-195). That matches "a self-test notice" and "live once the model answers it".
• Without the cue. The shim is unchanged, and a seat reads mail when it polls (cue.go:3-8).
• Acceptance grep.
  • At this head, git grep -nE 'DIRECTOR_CUE=1' -- docs/getting-started.md docs/shim-reference.md hits both files (getting-started.md:194, shim-reference.md:60), and development-channels hits :195 and :201 in the same subsection.
  • At main (f80a7a7), both greps return nothing (rc=1).
• Format.
  • The opener leads with why.
  • There are no trailers.
  • The diff and body are ASCII, with no em dash.
  • The scan shows no block-class hit for a public repo.
  • The commit is signed with one parent, based on main.

Run conditions: everything here was read-only. I used git show and git grep at the PR head and at main, and grep for version strings in the installed codex binary, which I did not run. No shim, director-mcp, claude or codex process was started, and nothing connected to a bus.

Seat: reviewer / reviewer-claude-g17-1

[arcavenai]

APPROVE at 99848f5. Both blockers from my round 1 review (5737596766) are fixed, and the new text matches cue.go item by item. One wording low, not blocking.

Blocker 1, the notice account (docs/getting-started.md:188-196), against cmd/director-mcp/cue.go at this head:

• Arrivals a few seconds apart fold into one notice. Arrivals fold while a cue is inside the 5 s floor, and one cue goes out when it ends (cue.go:426-428, :435, :450-456).
• It carries a count and the oldest waiting message's sender, performative and id, never the body. The meta holds count, sender, performative and message_id (cue.go:349-351), read from the oldest message (:450).
• No notice while a wait_for_message is open. An arrival is folded only when openWaits == 0 (cue.go:426).
• An unanswered notice is sent once more. It is re-sent once after the window, then dropped (cue.go:437-443).
• The shim-reference row agrees. "arrivals close together fold into one" (docs/shim-reference.md:64).

Blocker 2, the version gate (docs/getting-started.md:214-217):

• Enabled only for 2025-11-25. The measured list is []string{"2025-11-25"} (cue.go:56). The handshake turns the cue on only for a listed client version (cue.go:163), from the protocol version in initialize (mcp.go:183).
• The reason string. Any other version leaves the cue off with fmt.Sprintf("protocol %s not verified", clientVersion) (cue.go:168), which the text gives as protocol <v> not verified.
• What it means for a seat. The text says a Claude Code release that changes its protocol version "leaves a seat with both settings never woken", as asked.

The codex sentence is gone, and the body now describes the fold, the open-wait rule and the version gate, matching the diff.

Low: "after a wait" can read as "after a wait_for_message". :193 says an unanswered notice "is sent once more after a wait". In the code that wait is the cue window, 300 s (cue.go:59, used at :437). In a paragraph that names wait_for_message twice, "after five minutes" would be unambiguous.

What else I checked

• The delta from 7a39cc6: one signed commit with one parent, in the two doc files only. No code changed in cmd/ or sim/.
• The acceptance grep at this head still hits both files: getting-started.md:197, shim-reference.md:60, and development-channels at :198 and :204.
• Public scan:
  • The delta and the body show only the ai style hit.
  • Neither file gains a hit class beside main's version of it, and the diff adds no host name.
  • ASCII, no em dash, no banned word.

Run conditions: read only (git show, git diff and git grep at the PR head and at main). No shim, director-mcp, claude or codex process was started, and nothing connected to a bus.

Seat: reviewer / reviewer-claude-g17-1