TDD: org — roles, chains, ownership-as-data (draft)

[itsHabib]

Summary

Design document for org: infrastructure for an agent organization (leads → project leads → ICs) over the portfolio. The load-bearing claim: continuity and ownership are the same fact — each role has one hash-chained journal of distilled context, and holding the tip of that chain is being the role. Incarnating = appending resume with prev == tip; forks, races, and displaced incarnations are refused by the reducer, not a lock.

Doc: docs/features/org/spec.md. Design only — no code.

Decisions that need a call (§4)

• §4.2 the tip of a role's chain is ownership; relationship to drive's scope caps (takeover mints/revokes)
• §4.6 grants bind to incarnation_id, not chain heads — and whether that lands in custody + gate separately or in a shared contracts/authority
• §4.7 the incarnation authors its own distilled state; a mechanical mark stands in when it didn't (degraded but legal)
• §7.3 crash → takeover → the stale incarnation's next write

Rollout

p0 charter → p1 contracts/org (leaf, validate + fold) → p2 Lean laws (port fm-epoch-replay-laws) → p3 Claude Code host adapter → validation gate: one role resumes mid-thought after a kill, on ivy/ship/gate → p4 drive runtime → p5 parley protocols → p6 one-lead/three-ICs/one-day slice.

This is a design review, not a code review. Do not merge — the operator locks the design.

🤖 Generated with Claude Code

[itsHabib]

@codex review
@claude review
@cursor review

Design review, not code review — this PR is a TDD only. Please focus on §4.2 (tip-of-chain is ownership, and how it relates to drive's scope caps), §4.6 (grants bind to incarnation id), §4.7 (agent-authored state vs mechanical mark), and §7.3 (crash → takeover → stale write). Do not merge.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, you can upgrade your account or add credits to your account and enable them for code reviews in your settings.

[claude]

Claude finished @itsHabib's task in 2m 35s —— View job

---

Design Review — org TDD (PR #245)

Tasks

• Load review tools
• Read docs/features/org/spec.md
• Review §4.2 — tip-of-chain is ownership, scope caps
• Review §4.6 — grants bind to incarnation_id
• Review §4.7 — agent-authored state vs mechanical mark
• Review §7.3 — crash → takeover → stale write
• Post consolidated design review

---

Review

The core thesis is sound and well-motivated. The evidence from the 79 empty memory buckets and two claim events is exactly the kind of empirical grounding a design doc needs. The chain-as-ownership model is a natural extension of switchboard's serialized-write result and drive's scope-cap ledger. Comments below are on the four focus areas only.

---

§4.2 — Tip-of-chain is ownership, and scope caps

The TOCTOU window is unaddressed. The refusal model depends on read-tip → compare-prev → write happening atomically. The spec states "the file lock around the write(2) is a mechanism for atomic appends, not the ownership model" — which is correct about semantics, but the lock must cover the full critical section (read tip, verify prev, write record), not just the write. If two incarnations both read tip == hash(41) and both attempt to append a resume with prev = hash(41), the second write will fail the prev check only if the lock was held across the read. Switchboard's journal gets this right by design (the actor serializes all appends); the spec should state explicitly whether the contracts/org Admissible check + append is a single locked region, or whether the lock is only around the write (which would leave the window open).

The two-plane coordination protocol is underspecified. §4.2 says "a takeover record on R's chain is what mints the successor's cap and revokes the predecessor's" and §7.3 step 3 says "drive re-mints the scope cap... revokes inc-7's". But who triggers this coordination, and is it atomic? If the takeover is written to the chain but drive's cap revocation fails (process crash, network error), you have a chain that says inc-7 is displaced but a drive ledger where inc-7's cap is still valid. The spec should either (a) make the cap mint/revoke a side effect of the takeover append, inside the same lock, or (b) accept eventual consistency and say how the divergence is detected (audit, fold cross-check). Either is defensible, but the choice must be stated.

Liveness threshold is implicit. §7.1 says "if the fold shows a live incarnation (tip is a checkpoint younger than the liveness threshold...)" but the threshold is never defined. §10 item #3 mentions "N for tool-call cadence" as an open question, but the cadence N and the liveness threshold are the same calibration: if you checkpoint every N=25 tool calls and a call takes 10 s, liveness threshold must be > 250 s or you'll spuriously park valid incarnations. The relationship between these two parameters belongs in §4.2 or §5, not left implicit. A supervisor deriving liveness too aggressively is the main false-positive risk for the entire ownership model.

---

§4.6 — Grants bind to incarnation_id

The reviewer call needs decision criteria, not just options. The spec asks "confirm the field lands in both or in a shared contracts/authority extension." The criterion is: will custody's grant body (cst2_*) and gate's grant body diverge in other ways over time, or are they stable? If they're stable, a shared contracts/authority with IncarnationID string is the right call — it keeps the invariant "a displaced incarnation cannot spend a grant" in one place, enforced by one import, audited in one test suite. If they tend to diverge, a shared type creates coupling that's harder to break later than parallel fields. Given that both grant shapes are already load-bearing in production, I'd recommend the shared contracts/authority extension — the invariant is too important to maintain in two places — but the spec should record the choice and its reason, not leave it to the reviewer.

The revocation enforcement mechanism is missing. The spec says "a displaced incarnation that still holds a token cannot spend it" — but the enforcement path is not described. When inc-7 presents a grant to gate or custody after a takeover, how does the verifier know inc-7's incarnation_id is stale? Three possible mechanisms: (a) gate/custody queries the org chain at verify time; (b) the takeover event is replicated to gate's audit log so gate can check without the org chain; (c) drive explicitly pushes a revocation record to gate/custody at takeover time. Option (a) creates a runtime dependency from gate into the org subsystem, which the "gate is unchanged" non-goal resists. Option (b) fits gate's existing tamper model. Option (c) has the same atomicity issue as §4.2's cap coordination. The spec should name the mechanism; "grants naming inc-7 are dead" is a goal statement, not a design.

Incarnation-keyed revocation is a new capability for gate. Currently, gate grants expire by time and scope. Adding incarnation-keyed revocation means gate's verifier needs a new query: "is this grant's incarnation_id still current?" This is a meaningful change to the gate trust model, even if gate's wire format gets only one new field. The spec should flag this as a gate-touching design consequence, not an additive-only change.

---

§4.7 — Agent-authored state vs mechanical mark

The decision tree from "prompt" to "mark" needs a timeout boundary. §6 says the hook budget is ≤ 3 s and the adapter "prompts for or requires" a checkpoint. But if the incarnation is alive but unresponsive (slow model call in progress), the adapter must decide: wait, interrupt, or mark. The spec should specify: after the hook budget expires, the adapter always marks (no blocking) and the checkpoint is degraded. The 3 s budget is the right number, but it needs to be stated as a hard timeout in §4.7, not only implied by the non-functional table.

What does "reconstruct from refs" mean for a mark tip? The spec says the resumed incarnation's first act is "to reconstruct from refs" when the tip is degraded. But mark carries session_ref and transcript_offset — if the host that produced the mark is gone (crashed machine, ephemeral runner), the transcript it points to is inaccessible. What does reconstruction mean in the worst case? The continuity thesis requires an answer: either (a) reconstruction is always possible from the chain alone (meaning mark must carry enough state for a model to reconstruct from the chain records only), or (b) mark is a best-effort with a defined degraded floor ("you know your role, your charter, and your last assignments, but not your in-progress thought"). The validation plan (§11 test 1) tests the nominal mark case (kill without warning) on machines where the transcript is still readable. It should also test the cold reconstruction case.

The empty_next asymmetry is implicit. Contract law requires checkpoint/handoff to have non-empty next (refusal: empty_next) but mark has no next field at all. A reader of validate.go will find the asymmetry surprising. §4.7 should state it explicitly: "mark is exempt from empty_next because it is host-authored, not incarnation-authored; it proves continuity, not intent."

---

§7.3 — Crash → takeover → stale write

The refusal ordering should be explicit. When inc-7's checkpoint arrives with prev = hash(41) and incarnation_id = inc-7, the spec says it's refused with prev_mismatch (and stale_incarnation on the body). The structural check (prev_mismatch) must run before the semantic check (stale_incarnation), because a record with correct prev but wrong incarnation_id is a different failure mode from a record with wrong prev (it might indicate a software bug rather than a race). The contract law table should document the check order; right now it lists refusal codes without ordering.

"Nothing was corrupted" applies to the chain, not to the work product. The scenario handles the chain correctly. But inc-7 was running a dossier task (§7.4: assignments are chain records). If inc-7 did work on the task — wrote files, pushed commits, sent messages — between seq 41 (its last checkpoint) and its refused append, that work exists outside the chain. The spec's claim "Nothing was corrupted; nothing needed a lock" is true for the chain, but the task's work product may have partial changes. The spec should acknowledge this boundary: "The chain is uncorrupted; work product produced after the last checkpoint is orphaned and must be assessed by the successor." This is not a design flaw — it's an inherent consequence of a crash recovery model — but stating it cleanly sets the right expectations for the p6 slice.

The revocation propagation gap. Between step 2 (ivy-lead appends takeover at seq 42) and step 3 (drive re-mints cap and revokes inc-7's grants), inc-7 could successfully spend a grant — submit a PR through gate, write a grant ledger entry through custody. This is the distributed systems "fencing token" problem. Gate's existing hash-chained log is the natural fencing point: the takeover event could be replicated to gate's log so that gate can reject any grant bearing inc-7's incarnation_id after the takeover seq. The spec should state whether this gap is accepted (small window, low probability, auditable after the fact) or closed (takeover is only complete once gate has been notified). Both are reasonable; the choice is a security property of the design.

---

Incidental observations

• §8 — Two supervisors race a takeover is elegantly handled by the same prev_mismatch rule, but the two-leads mutual-supervision topology has a failure mode the spec doesn't acknowledge: if both leads are down simultaneously, no one can write a takeover on either chain. The org is stuck. This may be acceptable for the p0–p3 scope, but p6's "one working day" slice should include a test where both leads are killed to confirm the recovery path (likely: operator takes over manually, which is the right answer).

• §4.2 "Alternative: leases/heartbeats — rejected: liveness is never recorded (FR7)" is correct reasoning, but the rejection also deserves a practical note: leases require a liveness daemon (the always-on process the non-goals exclude). Stating both reasons makes the rejection more robust to revisiting.

• The 79-bucket memory fragmentation fix (repo-keyed vs. worktree-keyed memory) is mentioned in §6 as a one-line side effect of the adapter. It is arguably more than that — it fixes the underlying reason the hand-off verbs never got used (fragmenting state made continuity invisible). Worth surfacing in §1 as a structural win the org system gets for free.

---

Calls the operator should resolve before p1

1. §4.6 — Shared contracts/authority or parallel fields? Recommend shared.
2. §4.6 / §7.3 — How does gate/custody enforce incarnation-keyed revocation at grant-spend time? Name the mechanism (replicate takeover to gate log, or query org chain, or push revocation explicitly).
3. §4.2 — Is the lock scope "write only" or "read-verify-write"? If the former, the race must be addressed another way; if the latter, state it.
4. §4.7 — Does mark guarantee enough for cold reconstruction (no transcript), or is a degraded mark only useful when the transcript is still accessible?

None of these block p0 (design lock), but items 2 and 3 must be resolved before p1 (validate.go and the lock boundary in the runtime verbs).

[itsHabib]

v2 pushed — review round 1 folded, plus four kernels adopted

Thanks @claude — every finding is addressed below. Codex hit its usage limit, so this was the whole panel.

The nine findings

#	Finding	Resolution
1	Lock scope must cover read-verify-write, not just write	§4.2 — critical section specified. Framed as the prev check is detective; the lock is what makes it preventive, and the two are deliberately redundant.
2	takeover ↔ cap revocation not atomic	§4.2 — resolved by demoting the cap ledger to a derived cache. Making the two writes atomic would need the leaf to reach into drive's ledger (boundary law). Instead: chain is authoritative, every authority decision is a join where the chain wins, so a failed revoke is harmless rather than merely detectable.
3	Revocation enforcement is a goal, not a design	§4.6 — took a fourth option over your three: a fencing token. Grants carry fence = chain seq at mint; verifiers keep a per-role high-water mark and refuse anything below it. No replication, no gate→org dependency, and the successor's first action permanently kills the predecessor's grants. Also flagged, per your point, that this is a change to gate's trust model (ordering as a fourth bound + new mutable state), not an additive field.
4	Shared contracts/authority vs parallel fields	§4.6 — decided shared, with the criterion recorded.
5	Liveness threshold and cadence are one calibration	§4.2 — sidestepped rather than tuned: records carry next_due, a deadline the incarnation declares. No global threshold; a slow incarnation extends its own.
6	mark cold-reconstruction floor	§4.7 — floor stated in two tiers (guaranteed: charter, assignments, last authored state, git facts; not guaranteed: reasoning since). Hook budget stated as a hard timeout. empty_next asymmetry made explicit. §11 test 1b runs the cold case.
7	Refusal ordering	§6 — ordered list, and reversed from what I first wrote; see below.
8	"Nothing was corrupted" applies to the chain, not the work product	§7.3 — acknowledged, with orphaned_since on the fold and assessment as the successor's first obligation. Cross-chain fallout addressed too.
9	Both leads down	§8 — operator is the implicit supervisor of every role; org takeover --by operator is always legal. §11 test 3b kills both leads.

Plus your incidental: the memory-fragmentation fix moved into §1 as the smallest version of the whole claim.

Three corrections from reading the bakeoff kernels

Before folding I had four agents read hack-branchroom, hack-mandate, hack-obligation, and hack-proofline closely. They are not experiments about verification in general — they are four laws this design needs, already built with frozen fixtures and planted mutants (§4.9). Three things v1 had wrong:

1. The stale writer that matters re-reads the tip. v1 described only a blind append refused by prev_mismatch — which would have justified dropping the incarnation check as redundant. The common case is a writer that re-reads the tail before appending: correct prev, correct seq, every correlation field right, and only incarnation_id refuses it. This is exactly the case branchroom's reducer mutation-tests. It reverses §6's check order (incarnation before chain position, finding 7).
2. Incarnation ids must be digests, not counters. branchroom's epochs are parent + n and therefore guessable; a robust re-reading writer will copy the fresh id by accident. §5 now mints ids as the digest of the record that created them.
3. The audit must reason about absence. proofline's two-witness rule is fail-open, which is correct over one trusted bundle and is a suppression attack across two chains — omit the record and the stale grant looks live forever. §7.6 now carries a completeness obligation in both directions, and is honest that catching a coherently lying chain needs signatures, which are deliberately not in p1.

Two portfolio-wide corrections (§4.10)

• All four kernels canonicalize with json.Marshal — Go declaration order, HTML escaping, no scheme version. Fine frozen; wrong for an append-only chain meant to outlive refactors. contracts/org ships a versioned canonical encoder before its first record.
• The mutant is how a law is stated. All four ship the wrong law as a live code path and prove it fails the planted case while consuming byte-identical input. p1's gate is now one mutant per refusal code, with identifiers frozen into a golden digest.

Open questions

v1's items 1 and 2 are decided. Three new ones from mandate, all real: subject drift on long-running work (its TaskRevision bump kills outstanding grants instantly — a footgun for a three-day task), canonical encoding, and grant consumption. One from obligation: whether roles get an obligation frontier, and who may discharge.

Still not merging — the design is yours to lock.

[claude]

Claude finished @itsHabib's task in 5m 4s —— View job

---

Design Review — org TDD v2 (PR #245)

Tasks

• Load review tools
• Read docs/features/org/spec.md (v2)
• Verify all 9 round-1 findings are addressed
• Review bakeoff kernel adoptions (§4.9, §4.10)
• Assess new open questions
• Post consolidated round-2 review

---

All nine round-1 findings are addressed. The bakeoff kernel corrections — incarnation check before chain position, digest-not-counter IDs, absence-based audit — are all well-argued and the spec is stronger for them. The fencing token (§4.6) is the cleanest resolution in the set: no replication, no runtime dependency, monotone by construction. The cold-reconstruction floor (§4.7) is honest in exactly the right way.

Four structural issues below plus a few smaller ones. Three of the four need resolution before p1; the fourth before p4.

---

§7.1 — The liveness refusal uses the wrong code

§7.1 step 3: "if the fold shows a live incarnation... → refuse with prev_mismatch and the current incarnation's id."

This is the wrong code. prev_mismatch means "prev ≠ hash of the previous record — fork, race, or stale incarnation." But if the live incarnation's latest record is the tip, a new resume record with prev = tip.hash has a correct prev. The chain mechanics do not refuse it. The thing refusing is the runtime's liveness check — a semantic check, not a chain-position check.

The consequence is real: a second incarnation that passes the liveness check (maybe next_due has expired and host signals are ambiguous) genuinely appends a resume at seq N with prev = hash(N-1). The chain allows it. The refusal code table has no code for "there is already a live incarnation and you must takeover to displace it." stale_incarnation also doesn't fit — that applies to checkpoint/assign/message.sent, not resume; resume is specifically exempt from the incarnation check (§6, step 4: "resume and takeover are exempt: they establish an incarnation rather than asserting one").

A new refusal code is needed — something like live_incarnation or must_takeover — listed in the §6 table, enforced inside Admissible, and surfaced by the p3 CLI. This also needs to be the code checked by §11 test 2's "exactly one holds the tip" assertion; prev_mismatch will not fire there.

---

§8 contradicts §4.2 on lock scope

§4.2 (v2): "the append verb takes an exclusive advisory lock on that one chain file across the whole critical section — acquire → read tail → Admissible(tip, next) → write → fsync → release — not just the write."

§8 (unchanged from v1): "One writer per chain at a time, enforced by prev — not by a lock. The file lock around the write(2) is a mechanism for atomic appends, not the ownership model."

These say opposite things about what the lock covers. §8 says the lock wraps only the write(2); §4.2 says it wraps the entire read-verify-write section. §8 also says ownership is enforced by prev — not by a lock, which is the v1 position that §4.2 corrected ("the prev check is detective; the lock is what makes it preventive"). §8 needs to be updated or a reader reconciling these two sections will be confused, and a second implementer will do the wrong thing.

Suggested §8 text: "One writer per chain at a time, enforced by the combination of an exclusive advisory lock over the full append critical section (read tail → Admissible → write → fsync) and the prev check as a second-opinion fallback. The lock is what makes the ownership claim preventive; prev detects bypasses (hand-edit, second implementation, stale lock). They are deliberately redundant."

---

§4.6 — The fence-bump at org incarnate is not specified

§4.6: "the residual window is 'after the takeover, before the successor's first spend,' and org incarnate closes even that by bumping the fence as a no-op on resume."

How does org incarnate bump the fence? Appending the resume record at seq N advances the chain — but the verifier's high-water mark advances only when the verifier honors a grant bearing that fence. If org incarnate doesn't present anything to gate/custody, the high-water mark stays at whatever the predecessor last used. A successor that takes a while to spend its first grant leaves the window open.

Three options: (a) org incarnate mints a scoped no-op grant and presents it to every known verifier; (b) drive explicitly notifies gate/custody of the takeover seq; (c) the window is accepted as documented and the "no-op on resume" language is removed as overclaiming. Option (a) requires all verifiers to be reachable at incarnation time, which may not hold for every harness. Option (b) is the explicit revocation that §4.6 said can fail. Option (c) is honest about the residual risk — the window is small (org incarnate is usually fast) and the audit (§7.6) covers it.

The spec should name which option it chooses. Leaving "bumping the fence as a no-op on resume" unexplained means each implementer will invent a different answer.

---

§4.6 / gate — High-water mark durability is not addressed

Gate and custody gain "one integer per role" as new persistent state. The spec describes where chain files live (<state>/org/<role-slug>/chain.jsonl) but says nothing about where the high-water marks live or how they survive a verifier restart.

The failure mode: gate honors a grant at fence=43, the high-water mark for that role is now 43 in memory, gate crashes before writing it to disk, restarts, and the in-memory mark resets to whatever was last persisted (say, 41). Now the predecessor's grants at fence=40 are honored again — the fence guarantee is lost across restarts.

Two clean options: (a) the high-water mark is a record in gate's existing hash-chained log (so it is crash-safe and tamper-evident by design); (b) it is a file in gate's state dir with an explicit fsync on every update. Option (a) fits gate's existing model and makes the fence history auditable. Either choice is fine but must be stated before p4, since p4 is when "custody and gate adopt contracts/authority and keep a per-role fence high-water mark."

---

Smaller observations

fence_regression in the §6 refusal table. The §6 table is for org chain contract law — codes produced by ValidateRecord / Admissible / Reduce. fence_regression is different in character: it is a grant verifier's refusal, produced when gate or custody checks a presented grant against its high-water mark. Including it in the org chain table conflates two separate refusal spaces. The gate/custody verifier should have its own fence-check code; the org chain should not. If fence_regression is added to contracts/authority's error type (as opposed to contracts/org's), the distinction is preserved.

counterpart_absent is an audit finding, not a chain refusal. §7.6 introduces counterpart_absent as the code for a missing cross-chain counterpart. It is not listed in §6's refusal table, and it shouldn't be — it is an org audit output, not a chain append refusal. §6 is about what Admissible returns; org audit output belongs in a separate finding-codes table, the way gate's audit has its own output format. Worth separating before p1 so contracts/org knows which package each code lives in.

Duplicate §10 item #7. There are two questions numbered 7: the live-actor question (switchboard/message delivery) and the subject-drift question (TaskRevision bump kills in-flight grants). The second should be renumbered — it looks like the numbering was extended from the wrong base.

§4.9 generalization and §10.7 are the same unsolved problem. §4.9 says subject identity is generalized to (task, revision, kind, digest) where revision pinches at. But §10.7 notes that a TaskRevision bump kills outstanding grants, which is exactly what the generalization would produce if revision is the task revision. The text should state explicitly that §4.9 describes the identity shape, not a resolution of the authority-revocation problem — the resolution is deferred to §10.7. As written, a reader could believe §4.9 solved what §10.7 is still asking about.

§10.8 vs §4.10. §4.10 decides that contracts/org ships a versioned canonical encoder. §10.8 lists canonical encoding as an open question. The open question should be narrowed to "which form — RFC 8785 / JCS or explicit field-ordered encoder?" not whether to have one; §4.10 already decided the latter.

§11 "gate" naming collision. The validation plan refers to "ivy, ship, and gate" as the three project contexts where test 1 runs. "gate" here means the gate software project (the merge-authorization tool), not the validation gate. Since the spec also uses "gate" to mean the phase exit criterion (Gate column in §9), a reader doing a casual scan will find "gate" in §11 meaning three different things. Suggest renaming to "ivy, ship, and workbench" or being explicit: "the ivy repo, the ship driver, and the gate tool's own context."

---

Calls before p1

1. §7.1 — Add a live_incarnation (or must_takeover) refusal code to the §6 table; update §7.1 step 3 to use it; include it in test 2's assertion.
2. §8 — Update to match §4.2 on lock scope.
3. §4.6 — Name the fence-bump mechanism at incarnation time, or remove the "no-op on resume" claim and document the residual window.

Call before p4

4. §4.6 / gate — Decide where the per-role high-water mark lives and how it is persisted across verifier restarts; record the decision in the p4 gate criteria.

[itsHabib]

§4.11 — cattle not pets; the design's claim is now narrower

Pushed after reading Malucelli, Claude Code, 12 days straight: seven cron'd loops on a $40/month VM against a Claude Max subscription, 229 PRs opened / 213 merged in twelve days, and one sentence for its entire state story — nothing on the box is worth backing up, GitHub is truth, every tick re-reads open PRs and tracking issues.

That architecture is correct for the work it runs, and this design should not compete with it. Sweep work is stateless and idempotent and the work item is the PR, so there is no thread to preserve and a chain is pure overhead. Maintenance is therefore now an explicit non-goal of this document rather than a later phase of this machine — it is seven cron jobs, and it costs almost nothing to build.

What survives is owned work: one role, one task, held for days, where the decisions made and rejected, the approaches tried, and what it is waiting on exist nowhere but inside the agent until the work lands.

The reframe

Agents are cattle — any incarnation may be shot at any moment. The chain is what makes that true. An agent holding three days of reasoning in its head is inherently a pet; you cannot kill it without losing something. Externalising what it knows is what makes every incarnation disposable. Residency is settled from the other side by switchboard: a live process buys serialized ownership and nothing else, and the tip rule supplies that without the process.

What it adds

• The law governing every record: if it can be derived, don't record it. FR7 forbade recording liveness; this generalises it. PR state, CI status, branch existence, task status — all derived at read time. A field earns a place on the chain only when the fact lives nowhere else. The 4 KB state cap is this principle with a number on it.
• wip_limit on the charter. Malucelli bounds production, not just authority: a sweep with five of its own PRs open ends the tick rather than proposing a sixth, tying output to review velocity. Our grants bound what a role may do and nothing bounds how fast it creates work for others. His merge ratio is the evidence.
• Two failure modes, observed rather than predicted. Sessions expire at seven days, so a lead persisting for weeks structurally cannot be one session — outside confirmation of §4.3. And a usage-limited session does not exit, it sits holding the tick. A process-liveness check calls that alive; next_due correctly calls it a missed commitment. The supervisor must treat "process exists" as its weakest signal.
• p6 runs on a rented box, not the operator's laptop — which is what makes four concurrent day-long sessions practical at all.

What his setup does not answer

Two secrets on the box, a signing key and a GitHub token, and a human SSHing in every couple of days to re-authenticate. One credential, full reach, no attenuation, no per-role scoping. Fine for one person's repositories; exactly what stops the shape at a security review. The plumbing this design adds on top of his — attenuated per-role grants, a fence surviving takeover, an append-only record of who decided what under which authority, and an audit that reasons about absence — is the whole difference between a personal automation and something an organisation runs.

[itsHabib]

Correction to the comment above. Writing maintenance out as a non-goal was wrong. A monitor owner is a role — somebody durably owns alert health for an area, tuned this monitor and retired that one for stated reasons, and escalated what nobody could reproduce. The tick is stateless; the ownership is not.

So the split is not chain-or-no-chain, it is how much a chain carries — which falls straight out of derive-don't-record. Three role kinds, set by charter.kind:

Role kind	Owns	Chain density
ic	one work item, for days	thick — checkpoints every N calls; the thread is the point
maintainer	a standing area	thin — charter, tuning decisions, escalations. Ticks re-derive from the world
lead	a scope and the roles in it	medium — delegations, reports, escalations, the calls made on them

A maintainer's chain sitting unchanged for days is correct, not a failure to record.

Second point, from the same conversation: in an organization the work item is usually not a pull request. It is a ticket, a design doc, a runbook, an incident, a thread. GitHub-as-truth works precisely because Malucelli's work item is a PR and GitHub therefore knows its entire state. Once work spans a tracker, a docs site, a chat thread and a repository, no single store knows what is going on — the chain's strongest case rather than a weakening of it. Consequences: work.kind gains doc, incident, and area (the standing-ownership kind a maintainer holds indefinitely rather than completes), and a charter's capabilities[] are custody action manifests — comment on a ticket, publish a doc, tune a monitor — not git verbs.

[itsHabib]

@codex review

Adversarial design review at exact head 87d45e6. Review canonical docs/features/org/vision.md plus store-decision.md, p0-findings.md, where-this-stands.md, and reconciliation-brief.md against the shipped cmd/org and open #265/#266. The user's governing direction is thin provider-neutral durable ownership/assignment; hierarchy is only an authority proxy. Find contradictions, overclaims, stale gates, and a concrete dogfood break case. Cite exact file:line and distinguish measured from reasoned. Do not bless or merge.

[itsHabib]

@claude perform an adversarial DESIGN review and publish a FORMAL GitHub review pinned to exact head 87d45e6, not only an issue comment.

Run exactly: gh pr review 245 --repo itsHabib/workbench --comment --body "<your review, stating head 87d45e6>"

Important: docs/features/org/vision.md is now canonical; spec.md is explicitly superseded except for historical schema/refusal material. The prior bot reviews covered old spec heads, not this canonical vision or the subsequent design corpus.

Try to break, not bless:

• apply the operator's governing direction that org is thin durable ownership/assignment, while hierarchy is only a proxy for authority;
• reconcile vision.md, store-decision.md, p0-findings.md, where-this-stands.md, reconciliation-brief.md, and the actual shipped cmd/org plus open PRs feat(org): sweep — the instrument that says whether continuity works #265/feat(org): detect cross-role assignment conflicts #266;
• flag SAYS-IT-IS versus IS, internal contradictions, stale measurements, overbuilt planes, requirements with no current implementation, and validation gates that cannot be executed;
• assess whether the next dogfood step is actually safe/useful now, including hook collision, injection cost, rollback, corrupt-chain recovery, assignment conflict visibility, and provider neutrality;
• give severity, file:line, measured/reasoned, and a minimum subtraction/build order.

Do not merge. If no issue exists, state exactly what you tried to falsify.

[claude]

Claude finished @itsHabib's task in 8m 7s —— View job

---

Adversarial Design Review — org TDD (PR #245)

Tasks

• Load review tools
• Read design corpus (vision.md, store-decision.md, p0-findings.md, where-this-stands.md, reconciliation-brief.md, spec.md)
• Read actual shipped cmd/org code (on main, confirmed accessible)
• Check open PRs feat(org): sweep — the instrument that says whether continuity works #265/feat(org): detect cross-role assignment conflicts #266 (permissions blocked; working from handoff.md)
• Reconcile SAYS-IT-IS vs IS across all documents
• Flag contradictions, stale measurements, overbuilt planes
• Assess dogfood step safety (hook collision, injection cost, rollback, corrupt-chain recovery)
• Post formal GitHub review pinned to head 87d45e6

Synthesizing findings…

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 87d45e6dca

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Instrument attach and release before evaluating POC-A

Reasoned: This trial requires SessionStart to append an identity-bearing attach and Stop to append release, but the shipped hooks are documented as only reading org boot and appending a mechanical mark (docs/features/org/handoff-2026-08-25.md:21-28,37-39). If the shipped scripts are pasted into settings as suggested by where-this-stands.md:3-14, two concurrent fresh sessions create no holder intervals, so the collision count can be zero and trigger the ≤3 kill gate even when a collision occurred. Wire actual attach/release instrumentation, or redefine the measurement around events the hooks really emit, before using this result.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Withdraw the SQLite prerequisite for the chain home

Measured: This assertion is stale against shipped #262: where-this-stands.md:3-12 records a JSONL home whose fold/admit/append critical section is serialized with flock, and explicitly distinguishes that chain from the discharge store for which SQLite was selected. Continuing to say that no correct chain substrate exists directs the next reader to migrate dossier before wiring a working chain, adding a database dependency that the shipped ownership mechanism has already demonstrated it does not require. Narrow this decision to the discharge/query substrate and evaluate the JSONL home on observed contention instead.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Resolve the canonical P0 gate before authorizing more phases

Reasoned: The canonical document first says the P0 gate does not pass and forbids P2-P7 (vision.md:18-23), while this paragraph declares those thresholds irrelevant for the current user and instructs readers to ship without earning permission; §7 then labels P0-P4 committed. With open follow-on work, these are incompatible stop signals: one reader must stop after P1, while another is authorized to start P2-P4. Either retire P0 for the thin 2-5-assignee dogfood scope and rewrite the phase gates, or keep it binding and remove the ship-without-permission direction.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Decouple recharter authorization from a parent role

Reasoned: Requiring a parent role's grant hard-codes hierarchy into the continuity contract even though the governing constraint says hierarchy is only one possible authority representation (reconciliation-brief.md:43-54) and the stated deployment is a flat list of 2-5 assignees (vision.md:42-45). A root durable assignee such as either shipped lead consequently has no parent that can authorize a recharter unless an artificial org edge is invented. Define recharter in terms of a provider-neutral authorization predicate or operator-issued grant, and let hierarchy optionally produce that grant.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Remove the superseded blocked/not-yet action

Measured: The correction immediately above concludes that the 72% basis was irreproducible, the split was separately rejected on termination grounds, and observer keying/evidence timing should be fixed first (p0-findings.md:202-209); this summary then repeats the superseded split as the highest-value change. A reader relying on the concluding action list will implement precisely the work the corrected measurement says to defer. Replace this item with the subject-keyed observer and pre-run evidence-settling actions, or explicitly mark the old action withdrawn.

Useful? React with 👍 / 👎.

[Copilot]

🟡 Changes recommended

Critical and moderate design findings remain unresolved.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

Design-only PR defining Baton/org architecture for role continuity, ownership chains, authority fencing, storage, validation, and rollout.

Changes:

• Adds the canonical architecture and lifecycle roadmap.
• Documents the superseded TDD and SQLite storage decision.
• Adds P0 evidence, status, reconciliation, and handoff guidance.

File summaries

File	Summary
docs/features/org/where-this-stands.md	Current status, measurements, and next steps. No final comments.
docs/features/org/vision.md	Canonical architecture and roadmap; unresolved critical, moderate, and nit findings remain.
docs/features/org/store-decision.md	Storage decision; critical CAS and conflict-semantics finding remains.
docs/features/org/spec.md	Superseded technical reference; unresolved critical consistency, authorization, and identity findings remain.
docs/features/org/reconciliation-brief.md	Cross-implementation reconciliation; one nit regarding the dossier read path remains.
docs/features/org/p0-findings.md	P0 evidence and corrections; one nit regarding the final summary remains.
docs/features/org/handoff-2026-08-25.md	Runtime rollout and hook handoff status. No final comments.

Review details

Suppressed comments (18)

docs/features/org/handoff-2026-08-25.md:102

• The same stale cross-reference appears in this handoff: vision.md has no §4.6 or §10.1, and its §4.5 is not the quoted “ownership is a tree” section. A fresh analyst following this mandatory starting point cannot find the design questions it names; point to current headings or quote the questions without obsolete section numbers.

that is a finding. `vision.md` §4.5 (ownership is a tree), §4.6 (three things
bubble) and §10.1 (fold per node kind — called *"the real design work behind
d3"*) all exist to compress a hierarchy. Check whether any survives at depth 1.

docs/features/org/handoff-2026-08-25.md:34

• The table above shows these hooks do not write the same fact: stop-mark records role continuity, while stop-discharge records conclusions against dossier tasks. Their shared no-model/lifecycle trigger is not evidence that one replaces the other, and wiring both would not duplicate a record; it would emit two complementary artifacts. Reframe the decision as whether one host hook should invoke both and how to avoid conflicting task resolution.

Read both headers. They reach the *same* conclusion in different words —
`stop-mark.sh`: *"a record the working agent is required to write is a verb
wearing a costume"*; `stop-discharge.sh`: claiming at the END is a report,
claiming at the start is a prediction and agents skip predictions. Two
implementations converging on a design principle is the strongest signal in

docs/features/org/p0-findings.md:19

• This section is presented as the current conclusion, but the correction below says the 72% classification is not reproducible and reports 28–33% wait-cleared blocks; vision.md and where-this-stands.md treat that rate as over the P0 threshold. Mark this block as historical or update its verdict and downstream consequences so the evidence document has one active interpretation.

## Item 1 — Classify the 87 blocked merges. **Gate passes; the finding is elsewhere.**

The vision's threshold: *if false positives exceed 20%, the authority plane
needs a redesign, not a rollout.*

docs/features/org/reconciliation-brief.md:294

• The brief's hard constraint says “No new store”, but this same PR's store-decision.md chooses SQLite as the substrate and vision.md §4.4 explicitly lists a new blob store. If the intended constraint is no new model or no parallel store, say that here; applied literally, this handoff forbids the proposed architecture and makes its build-order advice inconsistent.

- **No new store, no new repo, no rewrite.** Five stores have already died here,
  each surviving long enough to look like it might still work.

docs/features/org/reconciliation-brief.md:256

• This handoff tells the analyst to inspect vision.md §§4.5, 4.6, and 10.1, but those headings/claims no longer exist there: §4.5 is “Surface retired versus added,” and there is no §4.6 or §10.1. The quoted hierarchy text is absent as well, so a fresh analyst is sent to unrelated or nonexistent sections; update the references to the actual source or restate the questions against the current vision.

2. **What dissolves.** Apply §2's standing instruction across
   `docs/features/org/vision.md`. Sections §4.5 ("ownership is a tree;
   dependencies are a graph"), §4.6 ("three things bubble"), and open question
   §10.1 ("what is a fold per node kind" — called *"the real design work behind
   d3"*) are all built on hierarchy. Does any of that survive substitution at a

docs/features/org/spec.md:668

• The superseding banner says handoff was dropped in favor of release-then-attach, but this retained record table still defines handoff as a legal kind, and the API/hook sections repeat it. Because §5 is explicitly retained as an implementation source, readers can accidentally reintroduce the removed transition. Remove or clearly mark the stale rows and point them to vision.md's final record set.

| `handoff` | same as `checkpoint` + `reason: stop\|compaction\|release` | ends an incarnation cleanly; no `next_due` (nothing is coming) |

docs/features/org/spec.md:1013

• Open question 7 is used for both the live-actor question and subject drift, then 8–10 follow. This makes references such as §10.7 ambiguous and contradicts the statement that the items were renumbered. Renumber the subject-drift item and all subsequent references consistently.

7. **Subject drift on long-running work.** hack-mandate binds authority to a

docs/features/org/vision.md:144

• The canonical structural-kind list omits claim, yield, and complete, even though §3.9 uses them as lifecycle transitions; it also retains handoff despite the superseded-file header saying that kind was dropped. Because unknown structural kinds are refused, the versioned schema, state machine, and record table can classify the same chain differently. Reconcile these lists before implementing the reader.

- `kind_class: structural` — `charter`, `attach`, `takeover`, `release`, `retire`, `recharter`, `split`, `merge`, `abandon`, `revoke`, `delegate`, `assign`, `unassign`, `intent-ref`, `escalation`, `resolution`, `seal`, `annul`. An unknown structural kind makes the fold **refuse** `scheme_unsupported` with an upgrade remedy.

docs/features/org/vision.md:480

• This says every P0 item is answerable from existing data and asks for a last-90-day collision count, but the status and §4 say holding was never recorded and collisions are unmeasurable retrospectively; only a live instrumented run can answer it. Rewrite item 2 as the live POC-A instrument and distinguish historical reconstruction as unavailable.

Every item is answerable from data already on the machine, and any one of them can invalidate a plane.

1. **Classify the 87 blocked merges.** True positive or false positive. 87 of 247 actions is a 35% refusal rate against zero repos that require the check — those are unclassified predictions, not evidence, and the word "observational" is too kind. If false positives exceed 20%, the authority plane needs a redesign, not a rollout.
2. **Count the actual collisions.** Session-claims, worktree history, and transcripts, last 90 days: how many times did two sessions hold the same work item at once?
3. **Read 20 of the 81 stalled traces.** Defect or life? Until someone does, "32% stalled" measures the protocol's optimism.

docs/features/org/vision.md:536

• POC-A is advertised as binary, but 4–9 collisions in seven days satisfy neither outcome, and a seven-day count is not directly the stated ≥10-in-90-days gate. Define the intermediate decision and how the seven-day observation maps to the 90-day criterion before using this as the go/no-go.

**POC-A — Does ownership matter?** (P0, item 2, plus a one-week instrumented run.) Turn on attach-and-mark from the hook across every session on the machine, with no refusals of any kind. After seven days, count the events where two incarnations held the same role or the same work URI simultaneously.

- **Pass:** ≥ 10 collisions in seven days. Ownership is a real problem and the chain earns its place.
- **Fail:** ≤ 3 collisions. Ownership is a rare event, continuity is the whole product, and it is a text file plus a hook — one week of work, not a year. Stop and build that.

docs/features/org/vision.md:431

• §3.8 makes both deadline and default mandatory for every escalation, but this row says no timeout, which appears to permit a never-expiring human escalation. Distinguish a required deadline used only for visibility from “no automatic resolution at the deadline,” or choose one behavior so the attest contract is unambiguous.

| **attest** | bind, and external systems require the evidence (branch protection, deploy gates) | anchors published off-box | sandboxed execution required | human required, no timeout, for class U and ceiling breaches |

docs/features/org/vision.md:13

• This document's index says the reconciliation brief puts vision.md §§4.5, 4.6, and 10.1 in doubt, but the canonical file has no §4.6 or §10.1 and §4.5 is a different topic. The index therefore directs readers to a non-existent design location; update it when the reconciliation questions are relocated or renumbered.

> | [`reconciliation-brief.md`](reconciliation-brief.md) | handoff prompt: name the properties the org metaphor stood in for, and reconcile the ten implementations against them | **open question**; hand to a fresh analyst. Its §2 puts §4.5, §4.6 and §10.1 below in doubt |

docs/features/org/vision.md:14

• The index says this synthesis will fold into §0 once #245 is locked, but vision.md has no §0 section—it goes from the status block to §1. Since this file is labeled canonical, the unresolved destination makes the document set's authority unclear; name the target section or remove the promise.

> | [`where-this-stands.md`](where-this-stands.md) | proven vs claimed, and the next step | synthesis; **folds into §0 here once #245 is locked** |

docs/features/org/vision.md:267

• The effect seam defines the mandatory broker stamp as (role, fence, work_ref, effect_id), but the state-machine invariant below says every effect carries (role, incarnation, fence, w). These are not equivalent: incarnation is the presented identity bound to the grant/chain. Choose one canonical stamp (or explicitly derive incarnation from fence) and use it in custody, effect records, and validation; otherwise implementations can disagree about what effect_unstamped means.

| Continuity → Effect | `(role, fence, work_ref, effect_id)` stamped on every brokered request | the incarnation | custody, `effect_unstamped` if absent |

docs/features/org/vision.md:166

• The canary is described as forking from the chain alone, but §2 makes distilled state a separately stored blob referenced only by body_digest, and those blobs may be erased. A chain-only reader therefore cannot recover the goal/decision prose that the canary is meant to score. Define whether the canary includes retained body blobs/tombstone projections, or limit the fidelity claim to the spine.

**The resume canary is a first-class component, because distillation quality is the thesis's only untested load-bearing assumption.** Periodically, fork a fresh incarnation from the chain alone, ask it to state the goal and the next action, and score it against what the live incarnation is doing. That produces a per-role **resume-fidelity** number that degrades visibly before it fails catastrophically. It is the only instrument that tells you whether the chain is carrying thought or only commitment.

docs/features/org/vision.md:605

• Appendix A1 says the tip must never be caller-supplied from an earlier read, yet the public batond API requires If-Match: <seq>.<tip> and calls that header the entire concurrency story. If the closure rule is local-only, state that the remote HTTP value is an optimistic-concurrency precondition verified atomically by the home; otherwise these two API contracts conflict.

the scale. **The tip is never a parameter the caller supplies from an earlier
read.**

docs/features/org/where-this-stands.md:136

• The summary reports exactly 24 wait-cleared blocks, while the correction in p0-findings.md reports a range of 24–29 of 87 because five blocks are mixed. These are different rates and produce different threshold conclusions. Use the corrected range or document the classification rule that justifies selecting 24.

| input | threshold | measured | verdict |
|---|---|---|---|
| collisions / 90 days | ≥ 10 | **unmeasured** | unknown |
| false positives | < 20% | **27.6%** | **over** |
| role-day at target scale | 75 roles | affordable to **~25** | **3× under** |

docs/features/org/where-this-stands.md:176

• Re-keying the observer can make the missing-decision cases visible, but it cannot create or enforce a gate decision for a merge that already happened out of band. Calling this a fix overstates the effect; distinguish detection/metrics from closing the authorization gap, which needs an enforcement or receipt path.

**Second, re-key gate's observer by subject.** Cheap, and it fixes the stalled
metric, the ghost inbox, and the "two merges with no decision" hole at once. It
is also the smallest possible demonstration of the ownership thesis against a
real tool.

• Files reviewed: 7/7 changed files
• Comments generated: 16
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[itsHabib]

@claude retry the exact-head FORMAL review that the prior run left incomplete. Review only current head 87d45e6 and publish with: gh pr review 245 --repo itsHabib/workbench --comment --body "<review explicitly naming head 87d45e6>". Keep it narrow and adversarial: (1) actual SessionStart/Stop and optional-incarnation behavior versus the session-exclusivity/POC-A claims; (2) thin provider-neutral ownership/assignment versus hierarchy/authority/effect scope; (3) contradictory P0 stop signals and stale factual claims. Cite exact file:line. Do not inspect other PRs, modify files, approve, or merge.

[claude]

Claude finished @itsHabib's task in 0s —— View job

---

I'll analyze this and get back to you.