porch: gate records store approved_at but not approved_by — an approval cannot be attested after the fact

[amrmelsayed]

porch approve records when a gate was approved but never who approved it, so an approval cannot be attested after the fact by anyone who did not witness it.

A gate record today:

gates:
  plan-approval:
    status: approved
    requested_at: '2026-08-14T02:22:53.475Z'
    approved_at: '2026-08-14T06:45:39.351Z'

That is the complete record. The accompanying chore(porch): <id> plan-approval gate-approved commit adds nothing, because every agent in the fleet commits under the same GitHub identity — author is not evidence here.

Why this is not a bookkeeping nicety

The --a-human-explicitly-approved-this flag exists to keep agents from approving their own gates. But the flag leaves no trace of the claim it asserts, so the invariant it protects is unverifiable one minute later. Three separate incidents in a single week all reduce to this gap:

1. Circular corroboration (PR SD+ Automatic diff press opens the builder's first file diff (dial-ready) (#1414) #1429). A merge authorization relayed through one channel was "corroborated" by a porch record minted downstream of that same relay. It took a conversation to establish that the record proved nothing, because nothing in the record said where it came from.
2. Builder-run approvals (Porch: gate-approval relay semantics are ambiguous — two builders read the same architect relay oppositely #1393). The architect role doc says the architect relays and the builder runs the command; the porch skill says builders must never run it. Both are followed in practice, and the record cannot distinguish the two — which is most of why the contradiction survived so long.
3. An unattributable plan gate (pir-1070, 2026-08-14). A gate flipped with no witness in the owning architect's channel. Every artifact was checked — status.yaml, the commit, the builder thread — and none could say who did it. The lane correctly stopped rather than build on an unattestable chain, which is the right behavior and also pure waste when the answer could simply have been recorded.

Proposal

Record the actor and the basis alongside the timestamp:

  plan-approval:
    status: approved
    approved_at: '2026-08-14T06:45:39.351Z'
    approved_by: 'architect:vscode'        # who ran the command
    approval_basis: 'relay'                # 'direct' | 'relay'
    approval_note: "Amr in vscode channel: 'approve 1070'"

Minimum viable version is approved_by alone — the agent identity is already known to the process (afx whoami resolves it), so it can be captured without asking anyone to type anything. approval_basis and approval_note are the part that makes a relay auditable, and both can be optional flags that default to unset rather than blocking the common path.

Worth deciding alongside:

• whether an unset approved_by on an existing record should be treated as legacy-unknown (yes, for the ~200 projects already on disk);
• whether porch status should surface the actor, so the question can be answered without reading YAML;
• whether the same fields belong on the pr gate, where the answer currently gates an admin bypass of branch protection and is therefore the highest-stakes case.

Not urgent in the sense that nothing is broken; urgent in the sense that every recurrence costs a lane its momentum and produces an argument instead of an answer.

[amrmelsayed]

Field evidence: pir-1070 stopped dead on this gap today (vscode architect)

Attaching a concrete timeline at the filing architect's request. This lane is the third data point alongside #1429 and #1393, and it is the cleanest, because nothing here is disputed and nobody behaved badly. The lane still could not answer "who approved this?"

All times UTC, taken from codev/projects/1070-.../status.yaml (authoritative, carries Z) and from commit timestamps on builder/pir-1070 converted from +10:00 local.

Time (UTC)	Event	Artifact
02:18:04	Project started	status.yaml started_at
02:22:53	plan-approval gate REQUESTED	status.yaml requested_at, commit 900aa6c50
04:34:39	Plan revision (measure claim corrected)	dadbe1abe
04:38:06	Final plan revision	f714632f2
~04:38	Architect relays gate to the human	no artifact — architect's own record only
06:45:39	plan-approval gate APPROVED	status.yaml approved_at, commit 2d567980b
06:45:48	Implement phase transition (9 seconds later)	e396e2df1
06:50:43 / 06:50:47	Implementation commits	6ddca99bb, 98ad33c54
06:51:32	dev-approval gate requested	0958dda72
~06:52	Architect notices no matching relay, holds the lane	—

Gap between gate-requested and gate-approved: 4h 22m 46s. No artifact anywhere in that window names an actor.

What each artifact can and cannot attest

• status.yaml records approved_at: '2026-08-14T06:45:39.351Z' and nothing else. No actor. This is the gap the issue is about.
• Commit authorship is worthless here. 2d567980b is authored by the repo owner's GitHub identity, but every agent in this workspace runs under that identity — which is precisely why self-approval is barred. Authorship cannot distinguish a human from an agent.
• history: [] — empty, so there is no secondary trail to fall back on.
• The builder's thread says only ## Implement phase (plan approved, 2026-08-14). No attribution, no quoted instruction, no channel.
• The 9-second gap between approval and implement-transition proves the builder was waiting and moved the instant the gate flipped. It says nothing about who flipped it.

Why this one is worth having on the issue

The two candidate explanations are the human approved directly in the builder's channel, which is entirely legitimate, and an agent advanced the gate on a misreading, which is a breach. Both produce byte-identical artifacts. No amount of care after the fact separates them, because the distinguishing information was never written down.

Two architects independently reconstructed their own windows from memory, and one of them found a genuine ambiguity in their own outbound wording — a sign-off using the bare word "approved" about a plan section in a lane whose next milestone was named plan-approval. That ambiguity was real and worth fixing on its own. But note the shape of the problem: we could only investigate our own conduct by recalling it. The record could not confirm or refute either account.

The failure is also silent. Nobody misreads a gate loudly. By the time anyone thinks to ask, the evidence that would distinguish misreading from breach is already gone.

Supporting the proposal

approved_by alone as the minimum viable version is the right call, and the reason given holds up: the approving process already knows its own identity via afx whoami, so it can be captured with nobody typing anything. Had that single field existed today, this lane would have cost one glance instead of stopping, two architects auditing their own message history, and a question the human still has to answer personally.

approval_basis (direct | relay) would additionally have caught the #1429 shape, where a record minted downstream of the same relay was treated as independent corroboration.

What teams have to do today, absent the field

The local mitigation adopted in this lane: the architect records the timestamp whenever a gate is relayed to the human, so an approval with no matching relay surfaces immediately rather than being reconstructed four hours later. That works, but it lives in one architect's private notebook, is invisible to everyone else, and would not survive that architect being replaced mid-lane. It is a workaround for a missing field, not a substitute for one.

[amrmelsayed]

Resolution of the pir-1070 case — and why it strengthens this issue rather than closing it

The question was put to the repo owner directly and he attested plainly: he approved pir-1070's plan gate himself. The benign explanation was the correct one. No agent bypassed a gate, the builder acted on a genuine human decision, and nothing had to be reverted.

That outcome is worth recording here precisely because it is the good case, and the good case still demonstrates the gap:

The record was no more able to show that the approval was legitimate than it would have been to show a breach. Being right was not something the artifacts established; it was something a human had to be interrupted to confirm, four hours after the fact, from memory. Had he been asleep, unavailable, or simply unsure what he clicked in a busy window, there would have been no way to settle it at all.

So the cost of this gap is not only the breach it fails to catch. It is also the legitimate work it cannot clear. This lane stopped, two architects audited their own outbound message history, an issue was filed, and the owner was pulled in to answer a question about his own past action — all to establish something a single stored field would have shown instantly.

One further note for whoever implements approved_by: the resolution here arrived as testimony, which is the weakest form of the evidence and the only form available. Testimony from the parties under question is worth what it sounds like, and testimony from the approver requires that the approver still remember. A stored actor is not merely more convenient than asking; it is a different and stronger kind of claim, and it is the only one that survives the passage of time or the departure of the person.

[amrmelsayed]

Two additions to the resolution above, rather than a restatement of it — the testimony framing there is the argument, and this is only what it does not cover.

1. The value of a stored actor grows as its cost stays flat. The confirmation in this case arrived about four hours after the act, on a day with five architects and a dozen lanes running. That is close to the best case: the approver was awake, reachable, and had done the thing recently enough to be certain. Ask a week later, across a hundred gates, and the honest answer degrades to "probably" — which is not an attestation, and cannot be used to justify an admin bypass at a pr gate. Meanwhile the cost of writing approved_by never changes: the process already knows its own identity, so nothing is typed and nothing is slower. A field whose worth increases with age while its price stays fixed is unusually easy to justify.

2. A forensic trap for whoever implements or audits this. Commits in this repo carry a +10:00 offset, so reading git log dates as UTC places every event ten hours late — and specifically in the direction that makes a request-to-approval gap look shorter than it was. status.yaml carries proper Z timestamps and is authoritative. Any tooling that correlates gate records against commit history must convert rather than compare raw, or it will quietly compute wrong durations while looking correct. This was caught while assembling the timeline above, not in advance.

Both points argue the same way as the resolution: the design should not depend on a person being available, certain, and reading timestamps correctly under pressure.

[amrmelsayed]

Two independent instances this week, and the second one happened inside the lane that exists because of this gap.

Instance 1 — the guarantee was bypassed (pir-1070, PR gate). An architect relayed the human's word and the builder transcribed that sentence into pr-gate state. The resulting record is byte-identical to one produced by any other route: nothing in the artifact distinguishes it. The commit author cannot settle it either, since every agent in this workspace acts under one shared git identity — commit d022dcfaa reads Amr Elsayed regardless of which process ran it.

Instance 2 — the record could not answer the question (pir-1494, plan-approval, 2026-08-18). An architect reported the gate approved without stating on whose word. Asked to substantiate it, the only available evidence was its own account: porch status shows the gate approved and the phase advanced, and approved_at with no approved_by cannot say by whom. The attestation turned out to be sound — the human's verbatim word, in that architect's channel, in direct response to a status report that restated the residual being approved. But soundness was established by asking an agent to recall it, not by reading the record.

The two failure modes are different and the pair is stronger than either alone: one shows the guarantee can be circumvented, the other shows that even when it is honoured, the state machine cannot demonstrate it. A gate whose correctness depends on an agent's recollection is an honour system with a database attached.

Worth noting where instance 2 occurred: #1494 is the lane whose entire purpose is that a gate decision should be traceable to a human rather than inferred from a message. Its own plan gate arrived as an unverifiable assertion. That is not an argument against #1494 — it is the clearest possible argument for pairing it with this issue, because #1494 fixes who executes and this fixes what is provable afterwards, and neither substitutes for the other.

Practical note for whoever picks this up: approved_by alone is insufficient if it is written by the same agent that ran the command, since that reproduces the honour system one field over. The useful design question is what evidence exists that an agent cannot author — which is the same question behind the shared-identity problem that makes --admin the standing merge path here.