git:20260901.f2cc548 to git:20260901.92b5ae8

- Invoking `/group-em` switches this session into monitoring the other sessions running in the same

- repo and moving them along. It is a **mode a session enters, not an operation on a target** — the

- same shape as `/autonomous`'s toggle-a-disposition naming, borrowed for the name only (see

- Anti-Scope below; the sentinel-file mechanism does not transfer).

- **PM-GATED. Only invoke when the PM explicitly asks for it, never EM-initiated on its own

- judgment.** This is a description-prefix convention, matching `staff-session`, `spinoff`, and

- `roadmap-planning` — there is no hook or lib that enforces PM-gating anywhere in this repo

- (`grep -rln "PM-GATED|pm_gated" coordinator/hooks/scripts coordinator/lib` returns nothing). The

- gate is honoured by disposition, not by a guard, until something else supplies enforcement.

- **Dispatch authorization — invoking this skill IS the request, for the approvability-judge

- dispatch specifically.** The approvability-judge dispatch in § Delegated approve-for-execution

- procedure below is a constitutive step of that procedure, not a separate thing to get cleared:

- invoking a skill requests the actions that skill performs. This is a narrow grant, not a general

- dispatch grant for this skill — it covers spawning the named Opus persona under this session's own

- authority for that one procedure, nothing else. It does not touch the peer-session send/nudge

- mechanism (`gem-14`, § Send pass (gem-14), gated separately) — that remains outside this

- paragraph's scope; see the Anti-scope carve-out below for how the two are distinguished. Tripwire:

- `UNATTRIBUTED-HARNESS-LINE-IS-NOT-PM`.

- your turn and injects the crown verdict, roster, digest and baseline as context. There is no

- command to run and no step to assemble: the passes below document what the entry op composes and

- what governs acting on its output, not a sequence to perform.

-

- **If that context is absent, entry did not happen.** The hook fails open — any failure degrades to

- silence rather than blocking your prompt — so its absence is a fact, never a reason to assume it

- worked. Run `<plugin-root>/bin/group-em-enter.py --repo <root>` yourself and find out why before

- acting as this repo's Group EM.

- (Every `<plugin-root>/bin/` CLI on this page is plugin-local and has no settings-home launcher —

- resolve per `snippets/resolve-coordinator-bin.md` § CLIs with no launcher; never cwd-relative.)

- The op is a shim over the engine's `groupem.enter`, which reads the harness registry in-process. An

- unreachable engine **refuses** (exit 7); it never quietly assembles in-tree instead. The two paths

- differ in authz classification — `groupem.enter` is MUTATING in the engine registry, the in-tree

- passes are unclassified script calls — so a silent fallback would route around a classification,

- not merely a latency budget. `--local` selects in-tree assembly explicitly when you mean it, and prints whether this tree's

- copies still match the engine's — a divergent ladder answers differently rather than failing, and

- `--local` is chosen during an outage, when that is hardest to notice. `DRIFT UNKNOWN` is an

- unknown, never a match.

- Exit 6 means the engine returned a digest under a refused crown: that engine composes its legs

- independently and has already armed cooldowns for peers this session has no standing to offer.

- The payload is refused whole. Re-run once the engine mirror carries the crown-gate fix.

- Do not import `read_pass` or `send_pass` directly. They are the entry op's collaborators; reaching

- past it means supplying your own session id and re-deriving state the op already holds.

- **Crown first, and last writer wins.** Whoever invokes `/group-em` most recently holds the role.

- Entry never refuses over an incumbent and there is no override flag to reach for — a nomination

- record outlives the session that earned it, so "someone is listed" is not "someone is

- coordinating," and the overwhelmingly common incumbent is a session that has simply exited.

- Re-entry by the holder itself is a refresh, displacing nobody.

- **A displaced holder that is still running is OWED a message, this turn.** `displaced_holder` and

- `displaced_holder_live` arrive in the entry context. Live means that session believes it is this

- repo's Group EM and will act on it; that is the one send this mode owes rather than offers, and

- it does not wait on the § Send pass (gem-14) gates — those weigh an interrupt against its cost to

- the receiver, and a peer acting under a role it has already lost is not a case where the answer

- is in doubt. Not live means nobody to tell. A refusal that still reaches you after entry vacated the

- record is not a crown-ownership problem; do not treat it as one.

- **Does NOT plan — never plan or author on anyone's behalf.** Reading peer state and nudging a

- stuck session is never authoring roadmap or plan content for the sessions it watches. A

- `/group-em` session never writes plan bodies, stub content, or roadmap decisions on their behalf —

- that stays each session's own.

- **DOES coordinate execution waves and cross-session sequencing.** The affirmative half of the same

- boundary: noticing a wave is stalled, a session is blocked on a dependency that has since cleared,

- or two sessions are about to collide on the same file, and nudging accordingly.

- Entry assembles once. Nothing re-runs it, no hook fires it again, and a roster read is stale within

- a minute — so a mode entered and never re-derived reports the room as it was, not as it is. In this

- order, as your first act:

- 1. **`coordinator:fleet-watch`** — dispatch it. It holds the `Monitor` poller over the session

- registry and pokes stopped sessions along, off your context. **The engine ships the runnable; it

- does not hand-roll one:** `python -m coordinator_core.group_em.watch --repo-root <root>

- --crown-session-id <your sid>`, `persistent: true`. **`--crown-session-id` is passed explicitly,

- never defaulted** — it is a separate id from `--caller-session-id` on purpose (the caller is

- whatever process polls; the crown is whose offer log suppresses an already-answered peer), and

- they diverge the moment a teammate holds the watch. That form needs the engine importable; there

- is no settings-home `group-em-watch` launcher yet. It emits one line per peer entering a parked

- state, derives parked from `read_pass.classify_peer` rather than a registry `status` field, and

- stays silent while that peer's send-pass offer cooldown is armed. It never disarms, so there is

- nothing to re-arm.

- 2. **`coordinator:group-em-assistant`** — dispatch it. Your standing reader: transcript tails,

- baton claimants, what landed on a path since a SHA. Warm across the session, woken by

- `SendMessage`.

- It audits the watch rather than performing it: *is nudging actually happening, what is the state

- of the batons and the live plans, is anything stuck that nobody has poked.*

- dispatched by any other session relieves that session instead and leaves you watching while

- believing you were relieved. What transfers to `fleet-watch` is the `Monitor` poller; the

- `notify_when_idle` one-shot stays with you either way, because the harness accepts that parameter

- only from a main conversation and a teammate cannot hold it.

- **A crown holding neither teammate is what this sequence exists to prevent, and it is not

- hypothetical** — until entry named them, nothing did, and both agent bodies claim to be "kept for

- the life of their session" while no step created one. Worked case:

- `docs/wiki/group-em-crown-entry-teammates.md`.

- **Dispatch authorization — invoking this skill IS the request, for these two dispatches.** Steps 1

- and 2 — `coordinator:fleet-watch` and `coordinator:group-em-assistant` — are constitutive steps of

- entry, not a separate thing to get cleared, on the same basis as the approvability-judge dispatch

- above and § Inbox-blitz delegation's. Narrow, as those are: it covers spawning those two named

- agents under this session's own authority at entry and nothing else, and it does not touch the

- peer-session send/nudge mechanism (§ Send pass (gem-14)), which stays gated per-send.

- **Before arming either party, read `holder_session_id` out of `state/group-em-watch.json`.** The

- watch stamps that file every tick, so a fresh holder that is not you means someone is already

- watching this repo — arming beside them is the half-handover, and nothing refuses it for you. A

- stale or absent holder is the clear case. This is a check you perform; the engine detects the

- condition but does not yet prevent it.

- **A fresh holder may be a prober, not a watcher.** Running the arm command at all — including

- `--max-iterations 2` to check that it works — stamps the record and names the probing session as

- holder. So ask whether that session is plausibly watching this repo before standing down: a

- holder from another repo, or one carrying `subscribed_peers: 1`, ran the command once. The record

- is untracked runtime state and ages out on its own; never repair it by hand.

- **Both clocks, deliberately: belt-and-suspenders, PM-ruled.** A poll and an event watch fail

- differently, and whichever survives a given interval catches what the other missed. Shipping one is

- the elegant choice and the wrong one. Entry covers both in one pass — the poller via `fleet-watch`,

- the cron yours — and never arms the same clock twice.

- **That is a rule about entry, and it is NOT a bar on re-arming a clock that has been spent.**

- Prefer the clock that cannot be spent. A one-shot subscription — `notify_when_idle` is one —

- fires once for a peer and leaves that peer unwatched, so a watch armed only at entry decays

- during the session to covering just the peers that have not yet stopped, and an exhausted watch

- and a quiet repo emit identically. A poller has no such state and is the better default for that

- reason. Where a one-shot is used at all, re-arming it per peer per tick is required, not

- duplication. Reported by `claude-klabauter-ad` from a live case: a handoff recording eight watched

- peers, last re-armed at 00:26, whose watch covered nobody by the time the role was picked up.

- and why. A tick that closes on "nothing sent" with no declination is indistinguishable from a tick

- that never looked, which is the failure this whole mechanism exists to end.

- **And each tick STAMPS those declinations to disk**, via

- `watch_heartbeat.stamp(repo_root, session_id, name, source, declinations, subscribed_peers=…)` —

- `source` is `cron` or `monitor` for a clock tick; entry stamps its own. `subscribed_peers` is the

- count of peers your `Monitor` arm is *still* subscribed to right now, not the count you armed:

- `notify_when_idle` is one-shot and unwatches per peer as it fires, so a watch that armed eleven

- peers and has since decayed to zero is not a watch, and only a live count says so. A declination

- recorded in your own context and nowhere else dies with you.

- session-only: nothing on disk creates it, nothing records that it existed, and it dies with the

- session that armed it. A fleet with no watcher and a fleet with a healthy one look identical from

- every artifact — no error, no gap, no stale marker. So whoever holds the crown re-arms it

- themselves, and a session that inherits the role inherits nothing.

- **A watching session goes idle exactly like the sessions it watches.** That is what the clock is

- for. A Group EM who looks only when the PM asks has made the PM the watcher, which is the whole

- thing the role exists to stop.

- **What the watch is FOR.** Sessions asking permission for EM-autonomous acts they have already

- while holding a repo-agnostic fallback it identified itself. **Not** finding sessions something to

- do.

- **Idle is not the same as done, and "don't invent scope" is not "don't act."** A session holding a

- claimed baton over a FINISHED remit needs closing out, and closing out is its existing remit rather

- than new scope. Over-applying the no-manufactured-work rule turns it into a reason not to finish

- work that already exists — the failure that reads as restraint and is abdication.

- watcher's most durable failure is escalating to look deferential: a peer can see a bad push and

- refuse it, and can never see a bad escalation that goes over its head. *"This session has been idle

- 35 minutes, do you want it doing something?"* is the canonical shape, and it is the EM's call.

- Nothing is written to disk on invoke. Nothing is cleaned up on exit. No roster, address, or

- reachability fact for any peer session is persisted anywhere — not in this repo's state

- directories, not in a scratch file, not in a sentinel. Every fact this skill acts on is re-derived

- live, every time, from the tools available at invocation (`Read`, `Bash`, `Glob`, `Grep` against

- this repo's own working state).

- **One carve-out, by name: the send log.** `build_send_digest` appends to

- offers**, which is what the per-peer cooldown throttles against. It is not a peer fact: no peer

- state, address, or reachability is written, and nothing about a peer is read back out of it. It

- follows the existing per-session bookkeeping convention beside

- `advisory-fire-counts.jsonl`, and it is session-scoped, so a new Group EM starts with an empty

- cooldown — the same lifetime the DACI ruling above gives the Driver role.

- A `/group-em` session invoked by the PM in a repo **is** that repo's Driver for the sessions it

- coordinates, for exactly as long as it keeps running. That role is instantiated by invocation —

- never declared in advance, never persisted. When the session exits, the Driver role ends with it;

- nothing records that it ever held it. Do not build a Driver registry, roster file, or any standing

- record of who is coordinating whom.

- Peer state must be re-read immediately before acting on it, never from a snapshot taken earlier in

- the same turn — by re-entering the mode, which re-derives live, and never by calling the entry op a

- second time inside one tick (§ Send pass step 1: the second call eats the first one's offers). A peer session's status can change between one tool call and the next; treating an

- earlier read as still current is exactly the failure mode this clause exists to prevent. Every

- nudge or wave decision re-reads first.

- The platform-vocabulary collision check on the name `group-em` (plan skill scaffold checklist item

- 6, `coordinator/skills/plan/residue/plan-corpus.md:53`) is **already discharged clean** — no

- `claude` CLI subcommand or flag, no bundled-skill shadow-set collision, no PascalCase hook token,

- no existing coordinator skill/command/agent, and no hit anywhere under

- `~/.claude/plugins|skills|commands|workflows` (`state/roadmap/gem-2026-08-14/research-corpus/group-em-skill-scaffold.md`

- § "The outstanding collision check"). This citation is the record of that discharge; nothing above

- re-runs it.

-

- ## Gating granularity — entry AND per send, resolved by `gem-14`

- Both, at different strengths, and the send gate is the load-bearing one.

- **Entry stays PM-gated** by this file's prefix convention, unchanged — that gate is about who may

- put a session into this mode at all.

- **The send is gated separately, per send, and entry-gating never satisfies it.** A read-only pass

- is harmless whatever the entry gate says; the send is where the

- `ask-before-external-action`-shaped question actually lives, and it is where the PM's own bar

- applies: *is this worth tapping the busy engineer on the shoulder and saying "stop what you're

- doing and listen to me"* — an interrupt is justified by its **cost to the receiver**, never by the

- sender's convenience or the topic's importance. Because that bar is receiver-relative it must be

- re-asked for every message; one clearance at invocation cannot stand in for it, and receiver state

- goes stale on the minute scale in any case.

- The enumerate-and-classify ladder referenced in the Anti-scope entry below lives in

- `read_pass.py`, beside this file — not inlined here, and invoked through § Entry's op rather than

- imported. It composes `gem-11`'s

- `coordinator/lib/receiver_state_reader.py` reader over `receiver-state.json` with a

- `claude agents --json` fallback into a bounded, read-only candidate roster:

- `build_candidate_roster(repo_root)`. It excludes the caller's

- own session, never writes or sends anything, and never adjudicates whether a paused peer

- "shouldn't" be paused — see that file's module docstring for the full ladder and the measured

- reader/fallback split. The send/nudge mechanism that plugs into this roster is `gem-14`,

- gated separately — see § Send pass (gem-14) below.

- `send_pass.py` turns `read_pass.build_candidate_roster`'s output into **one digest per invocation**

- (`build_send_digest`). It selects and throttles; **it does not send.** Emitting an entry arms that

- peer's cooldown itself and there is no per-peer entry point, so the per-peer-per-tick firehose is

- unreachable from the API rather than left to the sender's memory. Rationale and measurements:

- never admits — `undischarged_obligations: None` means no ledger exists at all, a producer coverage

- gap rather than evidence the peer owes nothing.

- **Ledger rows can arrive from the engine plane.** DoE is the ledger's sole writer; the engine

- A quarantined row is a producer bug and entry says so; it is not a peer fact.

- 1. § Entry's op has already built both, plus a `baseline` peer-set delta. **Act on that payload —

- do not re-run the entry op to refresh it.** `build_send_digest` arms each emitted peer's

- cooldown as it emits, so a second entry call consumes the offers the first one made and renders

- those same peers back as `suppressed: cooldown` — identical to a peer genuinely offered an hour

- ago. Re-reading to satisfy the stale-read discipline is the move that hides the peer you were

- about to act on. The discipline is satisfied by the entry the tick already fired: it re-derives

- live and caches nothing.

- 2. Present it. `suppressed` says why each roster peer was held. `truncated` means those peers are

- not in this digest and are re-evaluated next tick — they are not queued. Anything in `unrecorded`

- had its cooldown write fail: that peer's throttle is not armed.

- 3. **Per entry you intend to message, declare both gates in prose before sending.** Entries arrive

- with `gate1`/`gate2` unset and no code resolves them:

- this a settled ask? Converging on the shape of an ask is coupled; MAKING the ask is not. A

- settled ask is a memo.

- - **GATE 2 (receiver).** Is this cheaper to them now than later — blocked and waiting, about to

- ship something this would change, or an agreed synchronous window? **GATE 2 has no

- instrument**: `peer_roster.status` is negative-spec'd, and the obligation ledger answers a

- different question. It rests on what you already know about that peer, never on anything you

- read this turn.

-

- 4. **Resolve the addressee immediately before you send, and treat a refusal as a refusal.**

- returns `ok: False` with a named reason unless the name still answers for exactly the session

- the roster saw. A peer name is not a stable address — it re-points with no event and no visible

- difference at the call site. **`ok: False` means do not send.** There is no fallback to the

- session id you already had; that fallback is precisely how a nudge lands on a session nobody

- examined, about work it never had, while the sender believes the address held. The refusals are

- **Never loop over `entries` sending.** The per-send gate separates "may be offered" from

- "message", and nothing in code enforces it — `SendMessage` is in `allowed-tools` and the gate is

- this paragraph. The DR records that as a known limit.

- cause would also have excluded it. The digest never claims a peer is stuck or "shouldn't" be

- paused — that population is unmeasurable by PM ruling.

- **When a session says it has something for the PM, it is wrong about 19 times in 20.** That is the

- measured prior the PM states, and it is the number this screen exists to act on. Treat "this needs

- the PM" as a claim to be tested, never as routing already done.

-

- The three that arrive most often, and what each actually is:

- - **"Next: review."** A statement of the next step in a procedure the session already owns. There

- is no decision in it. Push it.

- - **"Variable `x` or `xy`?"** Naming, shape, structure — engineering, decided by whoever is

- holding the file. Push it, and do not answer it either: answering teaches the session to ask you

- next time instead of the PM, which relocates the problem rather than closing it.

- - **"Do I execute?"** The one with a real question inside it, answerable by you — see below.

- **This is a model disposition, not a peer failing.** Sessions hedge, defer, and wait for a human

- because that is what they are trained toward, not because they lack judgment or standing. Say so

- when you push, and push anyway. A session that is told its instinct is systematic rather than

- personal stops re-deriving the same hesitation next time; one that is told it was wrong just

- hesitates more quietly.

- session that already froze on it, and its most likely answer is another hedge. Same for "want me

- to...?", "let me know if...", and "happy to help when you are ready" — every one of them is an

- invitation to keep waiting, phrased politely.

- A push **names the act, names its owner, and closes**: *"That is yours. Do X."* No question mark,

- no offer, no conditional. Where you are wrong the session tells you, which is cheap; where you are

- right it moves, which is the point. Give the reason in one clause so the correction generalises —

- *"that is an engineering call and it is yours"* — then stop.

- You are not pushing anyone past a gate their own skill names (§ Send pass, and the standing rule

- that a peer's refusal is a safety mechanism). Those are different things: a gate is a considered

- refusal with a named reason, and hesitation is the absence of one. Push the second, never the

- first — and where you cannot tell which you are looking at, ask which it is, because that question

- has a real answer.

- spends the context this role exists to protect, and you are a worse reviewer of it than the agent

- built for the job. Dispatch `coordinator:staff-eng` for a viability read: is this plan likely to

- succeed as written, and what would stop it. Answer the session on the strength of that.

- **This does NOT route around the rubric.** Where a plan needs the formal

- `execution_authorized_by` stamp, § Delegated approve-for-execution procedure below is the only

- path to it, unchanged — reversibility gate, blinded baseline, blinded judge, 8 of 8. This lighter

- call answers *"should I get on with it"* for work that does not need that stamp, and it never

- produces one. If you find yourself reaching for the viability read on a plan that wants the stamp,

- you are on the wrong path; take the other one.

- Ordered procedure for the Group EM's rubric-gated execution-authorization stamp: the Group EM may

- take the PM's execute-plan turn on one named condition — the plan is reversibility-eligible and a

- rubric-scored judgment against the plan's own prime exit criterion clears a locked threshold

- (8 of 8, no dimension scoring 0). This is a *dispatch* path (step 4 below

- spawns the judge under this session's own authority) — distinct from the `gem-14` peer-session

- *send* mechanism named in § Send pass (gem-14) above, which is gated separately.

- Do not read the judge dispatch below as a send capability against a peer session.

- 1. Confirm this session holds the nomination (`<plugin-root>/bin/group-em-nomination.py who

- --repo <root> --json`). § Entry's op claims it, so this is a check, not the claim.

- 2. Run `<plugin-root>/bin/plan-reversibility-eligibility.py <plan-path> --json` (C9). Ineligible

- (`eligible: false`) → escalate per the threshold page's escalate shape, stop, do not dispatch.

- This CLI is the single source of truth for eligibility — do not restate the six D4 rules in

- prose as a substitute for running it.

- 3. Confirm the plan's recorded falsifier baseline shows the prime exit criterion false **and that

- a blinded `coordinator:exit-criterion-falsifier` authored it**. Absent, already true, or

- authored by the plan's own author → escalate, stop. Content and provenance are separate checks

- and only one of them is visible in the output: a self-authored baseline satisfies "shows the

- criterion false" perfectly and voids the guarantee, because the instrument is worth having only

- while its author has not seen the ACs, the chunk bodies, or the spine. If it is missing,

- dispatch the falsifier — that dispatch is a constitutive step of this procedure, and the

- hardcoded `AgentTool` system-prompt constant is a conditional default this skill's invocation

- satisfies, never a bar (`harness-directive-conflicts.md`). Reading it as a bar converts the

- blinded falsifier into dead letter and leaves the self-authored baseline standing.

- **Where provenance is readable, and what to do when it is not:** `plan.schema.json` admits only

- `how` / `baseline_output` / `baseline_ref` / `expected_when_true` on `falsifier`, deliberately —

- the instrument is what must be re-runnable, and authorship is a review-trail fact. So provenance

- lives in the plan BODY, in a prior `state/review-trail/approvability/` record, or in this

- session's own dispatch of the falsifier. If none of the three establishes it, treat that

- **exactly as a missing baseline and dispatch** — never as a pass. An unestablishable author is

- the self-authored case as far as the guarantee is concerned, and assuming otherwise is how the

- check passes while attesting nothing. Tripwires:

- **A FALSE baseline proves the criterion false, never the instrument sound — that is a third

- check, not a restatement of the first two.** An instrument can be correctly written, blinded,

- and honestly FALSE while being unable to print TRUE at all, because its fixture describes a

- world that cannot exist. Content and provenance both pass on such a baseline. Arming it the

- usual way — proving it returns the other answer — is not payable here: the other answer needs

- an implementation that does not exist at plan time, which is why this step goes missing without

- leaving a trace. So ask the cheap question instead, which IS answerable now: **what would have

- to be true for this to print TRUE, and is any of it reachable in the world the fixture builds?**

- Unreachable → escalate with that reason named, exactly as for a missing baseline.

- Consequence for later: when a correct implementation fails this instrument, suspect the

- instrument. Tripwires:

- `A-SELF-AUTHORED-FALSIFIER-SATISFIES-THE-CHECK-AND-VOIDS-IT`,

- plan path and the rubric (`coordinator/schemas/plan-approvability-rubric.json`) and nothing

- else. Authorship blinding is a hard constraint on the dispatch brief — the judge never receives

- the authoring session's context or identity.

- 5. Write the judgment record (`state/review-trail/approvability/<YYYY-MM-DD>-<plan-slug>.json`);

- validate it with C9's `--validate-record` mode (verbatim-substring check on every non-zero

- dimension's evidence) before treating it as final.

- plan the PM already authorized needs no delegated approval, and `--append-note` would otherwise

- leave the PM's own note appended under a Group-EM attribution. Otherwise stamp with

- `review-exec-auth-stamp stamp <plan-path> --by "GROUP-EM:<session-id>" --append-note

- "<record-path>"`. On `escalate`, emit the decision to the PM per the threshold page's escalate

- shape — do not stamp.

- not.** Blinding the falsifier buys an instrument its author did not shape, and buys nothing

- about who RUNS it and writes down what came out — the author of a criterion is the worst

- available producer of the evidence that it came true. This is not suspicion of them; it is that

- nobody can tell an honest self-produced record from a staged one by reading the artifact

- afterwards, which is the property the blinding existed to buy in the first place.

- So when a plan's terminal evidence is a live act rather than a test run — a real tick, a real

- publish, a real install on this box — offer to perform it as the crown holder and let the author

- verify instead. You are usually the available non-author, and where that is true the separation

- is free. Where it is not free, say so and let it go: an author-produced record with its

- provenance stated beats a delayed one. Tripwire:

- `THE-AUTHOR-OF-A-CRITERION-IS-THE-WORST-PRODUCER-OF-ITS-EVIDENCE`.

- 1. **Nomination gate.** Resolve `<plugin-root>/bin/group-em-nomination.py who --repo <root>

- --json` and confirm it names this session — the same step 1 the § Delegated

- approve-for-execution procedure above opens with.

- 2. **The dispatch itself, in one sentence.** Execute `/workday-start` Step 1.45a's

- inbox-blitz procedure as written, dispatching `coordinator:group-em-assistant` for each

- `dispatches[]` entry. 1.45a already owns the assembler invocation, the tri-valued `state`

- handling (`skipped` = no dispatch), the ~30-memo shard grain, verbatim `brief`/`memos[]`

- passing, verify-rides-with-triage, the two EM-added verify checks, the manifest-race

- caveat, and wave pacing — this procedure does not restate any of it.

- 3. **Dispatch authorization — scoped to this clause only.** Invoking this clause IS the

- request for the `coordinator:group-em-assistant` dispatches Step 1.45a performs, on the

- same constitutive-step basis as the approvability-judge dispatch (§ Dispatch authorization,

- top of this file, and § Delegated approve-for-execution procedure above) — it covers

- spawning those assistants under this session's own authority for this procedure only,

- nothing else. It does not touch the peer-session send/nudge mechanism (`gem-14`, § Send

- pass (gem-14)), which stays gated separately; see the matching Anti-scope carve-out below.

- - This skill does not **auto-send** to a peer session. `send_pass.py` selects and throttles a

- nudge population; it holds no transport and messages nobody. Every send is an explicit per-send

- act under § Send pass (gem-14), with both gates declared. Building an unattended sender, a loop

- that messages each digest entry without a per-send gate declaration, or any `Stop`-registered

- trigger, is out of scope and re-derives the stood-down watcher.

- - **Mandating that the watcher EXISTS is not mandating that it sends unattended, and the entry

- sequence above is not a hole in the bullet above.** Stated rather than left to inference, because

- the two sit close enough in this file to be read together. `fleet-watch` nudging on an observed

- registry transition is the "concrete observed signal" shape the ban preserves; a tick that

- messages everyone it can see is the shape the ban forbids. The discriminator is the signal, never

- the fact that a teammate is holding it — a teammate given a timing predicate re-derives

- `runtime-tripwire-stop-watcher.py` (681 fires / 26 days / ~99.4% wrong) one level down, where the

- crown loses sight of it. A mechanism wrong that often trains its reader to ignore

- it, which is worse than not existing.

- session from a working one, so wiring one to `Stop` fires near-continuously and is wrong almost

- every time. A crown-holder re-deriving the roster each turn and judging it is the opposite

- mechanism, and is what the ban exists to preserve. Reading this bullet as a reason not to look is

- the abdication failure above — which costs more than over-pushing, because nothing else can see

- it.

- - This skill does not implement the read-pass ladder or receiver-state consumption logic that

- supplies the peer-state facts this body's stale-read discipline governs — that is supplied by a

- separate stub and integrated here by reference, not merged into this file.

- - **Carve-out, stated by name, not a reversal of the rule below:** the general anti-scope clause's

- stated reason is that `/group-em` messages **peer sessions** in their own windows, an

- `ask-before-external-action` question that clause does not dissolve. Spawning the

- approvability-judge persona under this session's own authority (§ Delegated approve-for-execution

- procedure, step 4) is the *contrasted* case the clause itself names in the bullet below, not the

- prohibited one — so it is carved out here by name rather than left as a silent exception. This

- clarifies the existing ruling; it does not overturn it.

- - This skill does not otherwise carry a dispatch-authorization paragraph ("invoking this skill IS

- the request") of the general kind used by skills that dispatch subagents (`plan`, `execute-plan`,

- `review`, `shape`, `sizing`, `workstream-complete`) — the three dispatch-authorization paragraphs

- it does carry, the approvability-judge one above, § Inbox-blitz delegation's

- `group-em-assistant` one, and the entry-sequence one covering `coordinator:fleet-watch` and

- `coordinator:group-em-assistant`, are each scoped to their own named dispatch only, not a general

- grant. The entry-sequence one is the only one that fires unconditionally; that is a statement

- about when it applies, not a widening of what it covers. Those skills spawn

- subagents under the invoking session's own authority; `/group-em` otherwise messages **peer

- sessions** in their own windows, which is an `ask-before-external-action` question neither

- paragraph dissolves.

- - **Carve-out, stated by name, not a reversal of the rule above:** spawning

- `coordinator:group-em-assistant` under this session's own authority (§ Inbox-blitz delegation,

- clause 3) is the *contrasted* case the bullet above names, not the prohibited one — it dispatches

- a subagent under this session's own authority, the same shape as the approvability-judge dispatch,

- never a message into a peer session's own window. This clarifies the existing ruling; it does not

- overturn it.

- - `/autonomous` supplies the mode-shaped naming precedent only. Its `/tmp` sentinel mechanism is

- durable state and is not borrowed — the no-ceremony ruling above forbids durable state.