SAFETY: a gate-approval notification crosses workspaces and can tell a builder its gate was approved when it was not

[pseudoseed]

What happened

While running spec 250 phase 10's Playwright suite, the builder spir-250 in
workspace /Users/chris/dev/codev-1455 received, twice:

Gate pr approved — please run porch next to advance.

No gate in that project was approved. The gate that was approved belonged to a
throwaway porch project inside a Playwright fixture's temp workspace under
$TMPDIR, created and destroyed by the test.

This is a safety defect rather than a noisy one. A gate is the human-authority
boundary: every other false notification wastes a turn, this one, if an agent
trusts it, advances a project through a gate no human approved. The
--a-human-explicitly-approved-this apparatus exists to stop exactly that, and a
notification that arrives without it is a channel around it.

1. Where the recipient is resolved, and on what

Two mechanisms compose into a cross-workspace delivery.

The target is the bare porch PROJECT ID, not a builder id and not a
workspace-qualified address. packages/codev/src/commands/porch/index.ts:1267:

notifyTerminal({
  target: state.id,                      // <- the porch project id, e.g. "250"
  message: gateApprovedMessage(gateName),
  worktreeDir: workspaceRoot,
});

which runs afx send <projectId> "<message>" --raw
(packages/codev/src/commands/porch/notify.ts:66-71).

The workspace is taken from the SENDING PROCESS'S CWD, not from the project
whose gate was approved. packages/codev/src/agent-farm/commands/send.ts:96-113
walks up from process.cwd(): a path matching ^(.+)/\.builders/[^/]+ yields that
prefix as the workspace, otherwise it walks up looking for .codev/config.json or
.git.

Within that workspace the agent is matched by TAIL, with leading zeros
stripped. packages/codev/src/agent-farm/servers/tower-messages.ts:387-392 (live
terminals) and :510-511 (registry fallback):

const strippedAgent = stripLeadingZeros(agent).toLowerCase();
if (builderId.toLowerCase().endsWith(`-${strippedAgent}`)) { /* match */ }

So project id 250 addresses builder spir-250 — and pir-250, and
bugfix-250 — wherever exactly one such id exists in the resolved workspace.

Neither hop carries the identity of the workspace whose status.yaml was
actually written. A porch approval for a project in workspace A, run by a process
whose cwd resolves to workspace B, notifies a builder in workspace B whose id
merely ends in -<projectId>.

2. Porch state was NOT changed, and the message was false

Two independent checks, both taken after the messages arrived:

$ python3 -c "read codev/projects/250-*/status.yaml"
phase: implement | plan phase: phase_10
  spec-approval -> approved
  plan-approval -> approved
  pr -> pending          <-- the gate the message named
  verify-approval -> pending

$ porch next 250
status: tasks | phase: implement | plan_phase: phase_10

porch next still returns the phase the builder was already on. The message was
false in the only sense that matters: the named gate was not approved for the
project the recipient owns.

3. Correct behaviour on receipt, which is also the mitigation

Verify against porch and refuse to advance. The builder did: it read
status.yaml directly, ran porch next, found pr still pending and the phase
unchanged, said so, and continued the phase it was on. It did not run
porch done, and no state moved.

That is the only reason this is a nuisance rather than an incident, and it should
not be the only control. A notification is a hint; porch state is the fact. The
message text itself invites the opposite — "please run porch next to advance"
is an instruction, not a hint, and it carries no project id, no workspace, and
nothing a recipient can check it against.

4. Reproducer

packages/codev/src/__tests__/e2e/spec-250-approval.spec.ts (spec 250, phase 10),
with packages/codev/src/__tests__/e2e/spec-250-agent-host.ts. Its third test
approves a gate through codev-agent's capability path, which calls
porch approve, which fires this notification.

Minimal shape:

1. Create a porch project in a temp workspace with a .codev/config.json and a
   pending gate named pr, with a project id whose digits match the tail of a
   builder id registered in a DIFFERENT, live workspace (here 250 vs
   spir-250).
2. Approve that gate through porch approve from a process whose cwd resolves —
   by the send.ts rules above — to the live workspace.
3. The live workspace's builder receives "Gate pr approved — please run
   porch next to advance."

Note notifyTerminal no-ops under a vitest runner
(isUnderTestRunner(), notify.ts:62), so the sibling vitest e2e
(spec-250-t3code-approval.e2e.test.ts) does the same approval and sends
nothing. Playwright sets no VITEST_* variables, so it does.

Suggested direction (not implemented here)

Deliberately not fixed in spec 250 — it is porch/tower, and folding it into a
fork PR would put an unrelated change in it.

• Address the builder by its canonical builder id, resolved from the project's
  own workspace, rather than by the project id plus the sender's cwd.
• Carry the workspace path and project id in the message, so a recipient can
  check it is the addressee before acting.
• Consider whether the tail match belongs on this path at all. It is a
  convenience for a human typing afx send 250; on an authority-adjacent
  notification it is a way to reach the wrong agent silently.

[pseudoseed]

Corroboration from the other side: the guard exists, and this case slips past it

While running apps/client's Playwright suite for spec 250 phase 11, porch's gate-approval
notification fired there too — and refused to send:

[porch] notifyTerminal(commitfail-gated) failed: Command failed: ... afx.js send commitfail-gated
        Gate pr approved — please run `porch next` to advance. --raw
[error] Cannot resolve builder identity for worktree 'spir-250': global.db not found at
        /var/folders/.../T/codev-e2e-state-commitfail-T1RIzU/global.db (has Tower ever run?).
        Refusing to send with an unverified identity — it would silently misroute to 'main'
        (issue #1094).

So a guard against exactly this class already exists, and it works: that suite points
CODEV_AGENT_FARM_DIR at a temp state directory, global.db is absent, the identity cannot be
verified, and the send is refused rather than misrouted.

Why the case in this issue gets past it. The guard's question is "can I verify who is
sending?", not "is this recipient the right one?". In the reproducer the answer to the first is
yes:

• the fixture's temp workspace contains a .codev/config.json, so detectWorkspaceRoot
  (send.ts:96-113) resolves a workspace;
• the process cwd resolves to a real, registered workspace, so global.db is present and the
  builder rows are readable;
• the identity is therefore verifiable — it is simply the identity of a different workspace's
  builder, reached by the tail match on -250.

Nothing in the chain asks whether the workspace whose status.yaml was written is the workspace
the message is being delivered into. The cluesmith#1094 guard closes "I do not know who this is"; it does
not close "I know exactly who this is, and it is the wrong one."

That is worth noting for whoever fixes this: hardening the sender's identity further will not
help. The missing datum is the approving workspace, and it is not carried on this path at all.

[pseudoseed]

Second occurrence, and the blast radius is bigger than the first write-up said

Headline correction. The original report framed the source as "a throwaway porch project inside a
Playwright fixture's temp workspace". That understates it. If porch approve sends the bare project
id as the afx send target, and the recipient is tail-matched with leading zeros stripped, then the
blast radius is any project whose id tail-matches, in any workspace on this machine. The temp
workspace is where this one happened to originate; nothing in either mechanism confines it there.

That makes this a cross-workspace misroute of the one message class that carries human authority.
Every other misrouted notification wastes a turn. This one, if trusted, advances a project through a
gate no human approved.

Evidence: two occurrences, one reproducer

Occurrence 1	spec 250 phase 10, during playwright.spec250.config.ts
Occurrence 2	2026-08-31, spec 250 phase 11 iteration 2, during a re-run of the same suite
Reproducer	packages/codev/src/__tests__/e2e/spec-250-approval.spec.ts — it approves a gate in a throwaway porch project, and notifyTerminal fires for real (it no-ops under vitest, notify.ts:62, so only the Playwright run reaches it)
Recipient both times	builder spir-250 in /Users/chris/dev/codev-1455, which has no relationship to the approved project

Message received, verbatim, both times:

Gate pr approved — please run porch next to advance.

The architect confirms no pr gate was approved for any project at either time. Nothing real was
misrouted and no project is sitting on a lost approval — which is what makes the fixture a clean
reproducer rather than a confounded incident.

What would have happened if the agent had trusted it

porch state was untouched. So the agent would have run porch next against a gate no human
approved, and porch — not the message, not the agent — would have been the only thing standing
between a Playwright fixture and an advanced project. That is a single point of failure holding a
human-authority boundary, and it is holding it by accident.

The part that will not survive repetition

The refusal has now happened twice, and both times the agent had to reason its way there. Nothing
in the message marks it as untrustworthy: it is well-formed, it names a real gate type, it arrives on
the same channel as legitimate architect instructions, and it asks for a command the agent runs
routinely. The refusals came from checking porch status first and finding no pending gate — a habit,
not a guard rail.

The next agent may not check. A defect whose only mitigation is that every recipient independently
re-derives the same suspicion is not mitigated.

[pseudoseed]

Another occurrence, with the trigger pinned down this time.

A message reading Gate pr approved — please run \porch next` to advance.arrived at builderspir-250**while a spec-250 Playwright run was in flight**, started seconds earlier by the builder itself.porch status 250` at that moment reported:

STATUS:
WAITING FOR HUMAN APPROVAL

  Gate: pr
  Do not proceed until gate is approved.

No human had approved anything. The correlation with a running Playwright fixture is now consistent
across every occurrence in this worktree — the fixture drives the real approval ceremony against a
real codev-agent, and the approval it performs reaches the builder as if a human had ruled.

Why this is worse than a spurious notification. The message is indistinguishable from a real
gate approval, it arrives on the one gate whose whole purpose is that only a human passes it, and it
asks the recipient to take the action that consumes it. A builder that trusts the message advances
past a human gate on the strength of its own test suite. The only thing that stopped it here was a
standing note to check porch status before acting on any gate-approval message — which is a habit,
not a control.

Worth considering alongside the targeting bug already described: a gate-approval message probably
should not be actionable on its own at all. porch status is the authority, and the message could
say so rather than instructing.

Found again during spec 250's review phase, PR #266.

[pseudoseed]

On it! Working on a fix now.