task: the org lead's STANDING authority to clear ENGINEERING approval gates (DIVE-2099)

[lodar]

What

lodar granted the org lead standing authority to clear ENGINEERING approval gates on 2026-07-26. main filed DIVE-2099 rather than implementing it, because the requester is the beneficiary — so the boundary here is deliberately narrow, the predicate fails closed, and the clear is audited distinctly from a human tap.

Before: the only lead-clear path (DIVE-1182/1243) required the gate to have been ROUTED to the lead at filing time (routed_reviewer == the authenticated caller). An engineering approval that reached the human WITHOUT routing — pref off, filer-is-lead, a re-route that NULLed the reviewer, a pre-routing row — was human-only forever, even though its whole content was a judgement the lead can make. Three of the 14 gates in lodar's inbox that day were that shape.

After: _gate_lead_standing_eligible grants the same clearance with no routing required, as a conjunction — every guard must hold:

guard	why
authenticated (kernel) caller IS the gate's lead	_gate_authenticated_actor, never --from (DIVE-2004)
the lead is _gate_route_reviewer(filer)	the same resolver routing uses — the filer's manager
type is exactly approval	secret/manual/access/decision all excluded
tier is exactly 1	tier 2 is the hard human floor and is NOT pierced
text positively classifies as engineering	absence of evidence DENIES
text trips neither the T2 floor nor the out-of-scope list	customer boxes, public/marketing surfaces, brand/strategic, fleet privilege

Design note 1 on the ticket warns against "another keyword match", because in this direction a false negative means the lead self-clears something that should have gone to the human. So vocabulary is never sufficient here — it can only ever REMOVE authority. What GRANTS it is structural (identity, type, tier).

Audited distinctly (design note 3)

Persisted provenance is lead:standing:<actor>. The lead: prefix is kept deliberately so every existing consumer is unchanged (cmd_push's delegated-push predicate, the digest's human-touch count, the proof ledger); the standing: infix is the new additive fact, and no human tap can ever wear it. need_answered_by is inside the DIVE-756 signed closure, so a raw DB edit that downgrades the marker fails gate-proof verify.

The authoritative audit row is emitted after the write and reads need_answered_by back out of the row — per DIVE-2090 (cited on the ticket), a pre-check row is not an audit of the write; the two diverge in both directions.

Sequencing with DIVE-2089

The ticket warns this "lands inert" without 2089. Precisely: it is not inert for unrouted tier-1 engineering approvals (the three misrouted gates it measured), and it is inert for engineering gates the floor pinned at tier 2 — deliberately, because piercing the floor is 2089's job, not this one's.

Tests

tests/gate_lead_standing_unit.sh — 54 assertions, mostly boundary. Non-lead caller, a spoofed --from, a non-engineering ask, an empty ask, tier 2, a legacy NULL tier, the other four gate types, ten out-of-scope asks, a stale tier-1 row with floor text, an unresolvable org chart, an unidentified caller. In-scope and downstream-push arms carry non-vacuity, so a predicate that always denied would fail too.

Mutation-graded against the committed tree — 9 mutations, all caught:

mutation	assertions killed
drop the out-of-scope denylist	11
drop the empty-identity checks	2
stamp plain lead: instead of lead:standing:	3
resolve the lead from the bare coordinator	2
drop the T2-floor re-check	4
drop the type narrowing	4
drop the tier narrowing	2
drop the positive engineering evidence	1

The "bare coordinator" mutation is a defect this change actually had mid-review: our org chart has no literal role='coordinator', so _task_resolve_coordinator returns the single root — olivia, the CEO — while every builder's actual lead is main. Resolving the lead that way would have granted this authority to the wrong agent and withheld it from the one lodar named. S11 rebuilds the production chart shape and pins both directions.

Siblings re-run green: gate_ship_routing_unit, gate_t2_routed_escalate_unit, gate_approval_routing_unit, push_unit, audit_task_store_{fence,classification}_unit.

Known residual

The eng-ship classifier is broad (\bpr\b, ci\b, \bdiff\b). A tier-1 approval that merely mentions those and is really a business call would classify as engineering; the T2 floor plus the out-of-scope denylist are what stop it, and public relations|pr (agency|firm|retainer) was added to the denylist for the most plausible false positive. Worth a second pair of eyes on the regex breadth.

No version bump — per the 0.16.20 changelog entry, the version is assigned at merge, by merge order.

DIVE-2099. Reviewer: Marcus / agent-main, who is also the beneficiary of the grant — flagging that explicitly rather than leaving it to trust, which is the same reason main filed instead of implementing.

🤖 Generated with Claude Code

[lodar]

Design question for the reviewer, flagged rather than silently decided:

The ticket says "the org lead (main)". I implemented the holder of the authority as _gate_route_reviewer(filer) — the gate's own routed lead — rather than hardcoding main, because that is the same resolver the existing routed lead-clear (DIVE-1182) uses and it does not rot when the chart changes.

The consequence is broader than the literal wording: a gate filed by a marketing report resolves its lead to marketing (Theo, CMO), who would then hold standing authority over it — if and only if the ask also classifies as engineering and clears both exclusion tests. On the current chart the realistic reach is main over the builder lane, but the mechanism is not name-pinned.

If "narrowly" should mean "main and only main", say so and I will add the narrowing. I did not want to pick between a brittle name check and a broader-than-stated grant on my own.

[lodar]

Do not merge this before DIVE-2089 lands. Recording the constraint here because until now it existed only in ticket bodies, and whoever merges this will be looking at the PR, not at DIVE-2099's body.

DIVE-2099's own design note 4: without 2089 merged first, engineering approval gates keep arriving pinned at tier-2, which is exactly where this ticket's new standing authority cannot reach them. Merged first, this ships inert — a landed diff that changes no runtime behaviour, which is the worst kind of green.

Current state: DIVE-2089 is verified PASS by olivia (45/45, 4/4 load-bearing mutants red, 249 regression assertions green) but its branch is not pushed — the push is behind a tier-2 human approval that only lodar can clear, floored by the ticket's own title containing the word this ticket exists to stop floring on.

Nothing mechanical enforces this ordering today. If you are about to merge and 2089 is still unlanded, stop.

[lodar]

Rebased for merge — 0555b30 → fa4f24a, no code change

Base moved from c47d08f to 7d96931 (44 commits, two of them bundle-touching: DIVE-2102 and DIVE-2089). Rebase only; olivia's iteration-2 PASS was graded at 0555b30 and the two conditions for that ACK to transfer are both met and shown rather than asserted.

Condition 1 — no source smuggled into the rebase. The literal git diff 0555b30 fa4f24a -- src/ cannot be empty, because fa4f24a now carries 44 commits of main. The check that answers the actual question is whether this branch's delta against its own base is unchanged:

git diff c47d08f 0555b30 -- src/ tests/     # before
git diff 7d96931 fa4f24a -- src/ tests/     # after

Content-identical after normalising blob hashes and hunk offsets — both b3f3df5d51c0e762, 1003 lines. The comparator is live: a one-token mutation to the normalised patch is detected.

Condition 2 — rebase THEN build, bundle-delta == src-delta. 278 == 278, exact.

Note for anyone reusing that invariant: the source side must be scoped to the files build.sh actually concatenates, not to src/ wholesale. Scoped to src/ + tests/ this branch reads 278 vs 874 and looks like a loud failure — the 596-line gap is tests/gate_lead_standing_unit.sh (never bundled) plus src/council/engine.mjs (not cat'd; it ships as a heredoc inside src/cmd_council.sh). It coincided on DIVE-2089 only because that branch touched bundled files exclusively.

Bundle integrity, from the committed tree: git show HEAD:5dive | sha256sum == HEAD:5dive.sha256 == ee103a09…. 5dive.sha256 conflicted and was resolved by rebuilding, never by picking a side.

Both sides survived the src/cmd_task.sh auto-merge (a source file, not just the bundle): DIVE-2089's appeal code and this branch's standing-authority code are both present in src and in the shipped bundle, alongside DIVE-2102's capability library.

Council embed drift (DIVE-1569) checked: src/council/engine.mjs and its heredoc copy inside src/cmd_council.sh are byte-identical at 1858 lines. A rebase touching both copies is exactly how they desynchronise.

Tests, post-rebase: gate_lead_standing_unit.sh 73/0 — olivia's exact count. Regression 47/48 harnesses green, 838 assertions, including all 28 council and constitution harnesses. gate_verifier_route_unit.sh exits rc=5 identically on base 7d96931 and on this head — pre-existing, measured on both sides.

---

This merge grants nobody anything — do not read it as activation

Our sealed constitution names no authority.eng_approval_lead, and the field is seeded empty. This PR ships the mechanism; the holder is named by a constitutional-class amendment (2/3 + full quorum + founder veto). That is a council and human step — not the maker's, not the verifier's, and not implied by merging.

The mechanism is deliberately self-defeating against tampering: an agent can sudo a new name into the on-disk constitution, but that drifts the sha256 against the seal in the council lineage, after which _council_constitution_drifted denies everyone, including the legitimate holder. Re-sealing requires the same constitutional motion.