DEV Community: Jeremy Longshore

Verify Audit Evidence with a Signed Payload, Not by Format

Jeremy Longshore — Wed, 14 Oct 2026 11:30:11 +0000

When many audit-evidence publishers (the systems that produce signed rows of evidence) each emit a different shape and the consumer checks signatures case by case, a tampered row is indistinguishable from a legitimate format change. The consumer has no place to anchor "last good state," so any verification failure either erases history or silently keeps going.

A reader running an audit trail or evidence pipeline across multiple publishers and one consumer can adopt a different shape this week. One canonical signed statement payload (a fixed envelope of kernel version plus payload plus signature that every publisher fills in identically), one verifier that checks by signature, a preserved snapshot on every rejection. That is what cut this pipeline's tampering failures from "ambiguous" to "rejected with history preserved."

How do you verify audit evidence from multiple publishers?

Adopt one canonical signed statement payload: a fixed envelope of kernel version plus payload plus signature that every publisher fills in identically. One verifier parses the envelope, recomputes the digest over the canonical predicate bytes, and checks the signature against the public key named in the envelope. Format evolution shows up as a signature failure; tampering shows up as a signature failure; the two are no longer distinguishable to a silent verifier. A preserved last-verified snapshot rides with every rejection so the dashboard can answer what the system believed yesterday without needing yesterday's process to be alive.

The format-evolution trap

The natural reflex is to keep adapting the verifier. Each publisher says its evidence grew up: a new field, a renamed key, a moved nested block. The verifier grows a new branch for each, and the test matrix grows with it. The signed-payload approach is to stop growing the verifier at all and stop asking the verifier to know any individual publisher's shape. The signature binds to the digest of the full payload bytes; the verifier either trusts that digest matches the signed payload or it does not.

What makes this load bearing is that the failure mode is silent. A coerced signature over a slightly different payload passes a content check and fails a signature check. Both look like progress on a glance: the row got bigger, a field appeared, the count went up. The dashboard in this case was logging "verified" against a local witness and "rejected" against the kernel-signed digest, and the two tables had been drifting apart for three nights before anyone noticed.

The audit-harness (the in-repo package of deterministic test-quality checks) release carried a verified registry signature and provenance attestation on 2026-10-12, and that is what made the change carry weight. The pipeline was not adopting a new idea; it was adopting a long-standing in-toto-style attestation pattern that the harness had already shipped.

The one canonical statement payload

Every publisher now emits the same shape: a kernel-versioned envelope with a typed statement, a predicate payload under it, a digest over the canonical predicate bytes, and a signature bound to that digest. The kernel version is part of the bytes that get signed, so a version bump cannot pass as the same payload. The payload bytes follow; the digest covers them; the signature covers the envelope plus the digest.

statement:
  kernel: "audit-payload/v1"
  subject:
    - name: "publisher-name"
      digest: { sha256: "<hex>" }
  predicate:
    type: "https://intent-eval-platform.io/predicate/<kind>"
    payload:
      <canonical JSON: keys sorted, no whitespace, RFC 8785>
  metadata:
    build_at: "2026-10-12T13:45:00Z"
    source: "<publisher repo>"
envelope:
  digest: { sha256: "<hex of canonical predicate bytes>" }
  signature:
    pub_key_id: "<fingerprint>"
    value: "<base64>"

The kernel is the only component the verifier needs to know. Below the kernel, payloads are opaque to the verifier; their shape belongs to the publisher that emits them. Above the kernel, signatures travel with rows. The witness table only needs three columns: subject, digest, signature.

This is the reverse of how multi-publisher audits usually grow. The usual pressure is "the consumer has to understand the publisher," which pushes every format decision into the consumer. Inverting that pressure means every format decision lives with the publisher; the consumer only verifies that the signature covers the kernel and the digest.

One consumer, verification by signature

The dashboard verifier does three things in order, and only those three. It parses the envelope, recomputes the digest over the canonical predicate bytes, and checks the signature against the public key named in the envelope. A rejection at any step moves the row into a holding area; a pass moves it into the witness table under the subject digest.

def verify(envelope: dict, keyring: Keyring) -> Verdict:
    kernel = envelope["statement"]["kernel"]
    if kernel != SUPPORTED_KERNEL:
        return Verdict.reject(kernel_unsupported=kernel)

    predicate_bytes = canonicalize(envelope["statement"]["predicate"])
    expected = sha256(predicate_bytes).hexdigest()
    declared = envelope["envelope"]["digest"]["sha256"]
    if expected != declared:
        return Verdict.reject(digest_mismatch={
            "declared": declared, "recomputed": expected})

    pub = keyring.lookup(envelope["envelope"]["signature"]["pub_key_id"])
    if pub is None:
        return Verdict.reject(unknown_key=...)

    if not pub.verify(predicate_bytes, envelope["envelope"]["signature"]["value"]):
        return Verdict.reject(bad_signature=True)

    return Verdict.accept(subject=envelope["statement"]["subject"],
                          digest=expected,
                          signature=envelope["envelope"]["signature"])

The verifier does not branch on predicate type, publisher, or layout. If a publisher adds a field, the canonicalizer's output changes, the digest changes, and the signature has to follow or verification fails. Format evolution shows up as a signature failure; that is the design, not a defect.

When verification fails, hold the last good snapshot

A rejection is supposed to be an event the system keeps, not one it papers over. The tamper-evident holding area preserves the rejected envelope verbatim; the witness table keeps the last accepted row for that subject. A mutation that does not pass is a mutation the consumer has not yet agreed on, and the right answer is to surface that without erasing what already passed.

def apply(verdict: Verdict, store: Store, snapshot: Snapshot) -> ApplyResult:
    if verdict.kind == "reject":
        store.rejections.append({
            "envelope": verdict.envelope,
            "reason": verdict.reason,
            "received_at": utcnow(),
        })
        store.rejections.prune(keep_last=REJECTION_WINDOW)
        return ApplyResult.held(
            last_known=store.witnesses.get(verdict.subject),
            rejection=verdict.reason)

    store.witnesses[verdict.subject] = verdict.digest
    snapshot.persist(verdict.subject, verdict.digest, verdict.signature)
    return ApplyResult.accepted(
        subject=verdict.subject, digest=verdict.digest)

The snapshot sits alongside the witness table for the same reason the witness table is keyed by subject digest. The dashboard can answer "what did the system believe yesterday?" without needing yesterday's process to be alive. That is the property that broke before, when a forced schema migration overwrote the witness table with a partially-verified copy.

What got shipped

Six rejections in cross-repository tests covered the cases the old verifier could not tell apart: a single-byte payload mutation, a canonicalization difference on whitespace, a key id not in the ring, a signature over a tampered digest, a kernel version one off, and a payload reordered against an older row. Each rejection kept the witness for its subject. None of them caused history loss.

J-Rig (an internal governed evidence publisher) emitted fourteen canonical rows from the merged commit on the night of 2026-10-12. All fourteen verify against the dashboard signature path on the same day. J-Rig's twenty-four payload contracts pass across kernel versions 0.10.0 and 0.11.0; a stricter type check is now in CI for the test-only mismatch between the branded types in those versions.

A second finding came out of the same session: the trace-intelligence program's dependency graph needed 438 edges added to align final review and production-adoption with their prerequisites. The graph was repaired without changing ownership, acceptance criteria, or completion states. The collision between the two is the one to surface: a missing migration record and a missing dependency edge are both evidence the system was lying to itself about state; the same cross-repo fix path surfaced both, and neither was visible from the dashboard before it landed.

A real failure worth keeping. The scanner adapter had been treating gitleaks's exit-1 as a policy finding, conflating scanner crashes with findings. A contract-test surface reproduces this now, and required-missing-tool behavior stays advisory instead of silently raising real findings. The adapter is no longer a place where the verifier has to second-guess the publisher's report.

Why not the obvious approach?

Two alternatives were on the table. The first was a richer schema with publisher-specific extensions and a per-publisher verifier; the second was a content-addressed store that names files by their hash and trusts whoever can read them.

The richer schema pushes the format-decision pressure the wrong way. Every new field forces the consumer to learn a shape it does not own, and a tampered field reads as a new field until someone diffs the schema. The cross-repository tests in this pipeline had eight publisher schemas to maintain, and three of them were already a quarter behind. A per-publisher verifier is the natural extension of that path; it does not survive the next publisher.

The content-addressed store is closer to the working shape, but it answers the wrong question. A digest proves the bytes are intact; it does not prove the publisher had the right to issue them. A row whose digest matches but whose signing key is not in the ring still passes. The signed envelope binds the digest to a key id, and the verifier's second step is the only place that check lives.

A real reversal surfaced in the J-Rig kernel compatibility work. The earlier verifier accepted a "legacy fallback" branch so older J-Rig rows would not be lost on the cutover; that branch was a place a tampered payload could land without the witness table noticing. Removing the fallback is what makes the dashboard reject every J-Rig row that comes through the tampering or fallback branch today; the fourteen nightly rows verify on the canonical path. Keeping the old rows was the wrong kind of compatibility. The right kind is keeping the witness for the same subject, not the same shape.

Use this

Pick one canonical signed payload shape for every publisher in the pipeline. Kernel version plus payload digest plus signature. Anything below the kernel is the publisher's choice; anything above is the signature's. Format evolution shows up as a signature failure, not as a silent accept.
Move verification out of every publisher-specific verifier. One consumer, one supported kernel, one signature check. Rejections are a feature. Cross-repo tests should treat new publishers as an unknown key id, not as a new branch.
Preserve the last good witness for every subject on every rejection. The dashboard answers "what did we believe yesterday?" by reading the witness table, which means the witness table has to survive the rejection that pointed at a tampered payload.

The full migration is live on intent-eval-platform.io: eight publishers, one verifier, the J-Rig nightly run, and audit-harness 1.5.1 on the registry with verified provenance.

FAQ

How do you verify audit evidence from multiple publishers?

What is a signed statement payload in an audit pipeline?

A fixed envelope containing a typed statement, a payload digest, and a signature bound to that digest. Every publisher fills in the same envelope; payloads below the kernel can be any shape the publisher chooses. The signature covers the digest plus the envelope, so a single-byte payload mutation or a canonicalization difference on whitespace fails the check while legitimate history still verifies.

What should a verifier do when an audit row fails verification?

Move the rejected envelope verbatim into a holding area; keep the last accepted row for that subject in the witness table; persist the last-known-good snapshot so the dashboard can answer what the system believed yesterday without needing yesterday's process to be alive. A rejection is an event the system keeps, not one it papers over.

{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "How do you verify audit evidence from multiple publishers?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Adopt one canonical signed statement payload: a fixed envelope of kernel version plus payload plus signature that every publisher fills in identically. One verifier parses the envelope, recomputes the digest over the canonical predicate bytes, and checks the signature against the public key named in the envelope. Format evolution shows up as a signature failure; tampering shows up as a signature failure; the two are no longer distinguishable to a silent verifier."
}
},
{
"@type": "Question",
"name": "What is a signed statement payload in an audit pipeline?",
"acceptedAnswer": {
"@type": "Answer",
"text": "A fixed envelope containing a typed statement, a payload digest, and a signature bound to that digest. Every publisher fills in the same envelope; payloads below the kernel can be any shape the publisher chooses. The signature covers the digest plus the envelope, so a single-byte payload mutation or a canonicalization difference on whitespace fails the check while legitimate history still verifies."
}
},
{
"@type": "Question",
"name": "What should a verifier do when an audit row fails verification?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Move the rejected envelope verbatim into a holding area; keep the last accepted row for that subject in the witness table; persist the last-known-good snapshot so the dashboard can answer what the system believed yesterday without needing yesterday's process to be alive. A rejection is an event the system keeps, not one it papers over."
}
}
]
}

}}">Name the Single Authority in a Daily Pipeline - Why one named owner per concern beats committee routing in a daily pipeline
}}">Three-Pass Settlement for a Recurring AI Pipeline Contract - How three passes (producer, settlement, audit) settle a recurring AI pipeline contract
}}">Exit Zero Is Not Push OK - A cron that reports OK after a failed git rebase is a load-bearing lie

Park a Migration Without Losing the Work

Jeremy Longshore — Sat, 10 Oct 2026 11:30:13 +0000

A migration that ships by reaching the default branch with a green badge still has a second decision hidden inside it: do we point production at it today, in a week, or ever. When the build and the deploy are welded together, that second decision leaks into rollback theater even when the right answer is to wait months. The pattern this post calls publish-and-park splits them on purpose, so parking an owner can be the cutover's moment instead of its point of no return.

A Flask-to-Django refactor in catalyst-onboarding (a public onboarding repo) reached that fork in October. The Django stack was complete, gated, and pushed to two feature branches as atomic fast-forwards. Production stayed on Flask. The work stayed on the feature branches where it had landed. The pattern that made the cutover reversible is what this post is about.

What is the publish-and-park pattern for software migrations?

The publish-and-park pattern splits a refactor's build from its cutover so parking the work is reversible. The gate suite runs on the merged commit on a feature branch with no production mutation, and a dated "do not cut over" record lands in the repo. Production stays on the old stack until a separate decision points it at the new one.

The pattern, in one sentence

Push the refactor to its feature branches as an atomic fast-forward, run the full gate suite on the merged commit, ship nothing to production, write the explicit "do not cut over" record, and open a successor planning repo so the parked work has somewhere forward to go.

Five invariants make a parked refactor recoverable instead of abandoned:

Atomic push to a feature branch. The work lands as one fast-forward commit. No merge commit. No force push. The branch tip is byte-identical to the merged result.
Full gate suite on the merged commit. Unit, integration, contract, coverage audit, security, and an independent reviewer all run against the tip. Green badge is recorded on the commit, not on a moving branch.
No production mutation at ship time. The cutover is a separate operation, owned by a separate decision, executed on a separate day.
An explicit "do not cut over" document. A dated decision record lives at the top of the repo. Future readers find it before they touch the parked work.
A successor repo. The parked work has somewhere forward to go. It is not a dead branch waiting for a code archaeologist.

When all five hold, parking an owner is reversible. When any one is missing, parking an owner is abandonment in slow motion.

The build-up trail

The Flask to Django migration was not a weekend. It was six stacked PRs landed over a single day, each one a thin slice of the new lifecycle. The numbering gap between #113 and #115 is an unrelated CI-infra fix that interleaved between the intake and review slices; it is not part of the migration stack and it would be a mistake to read the migration as seven PRs because of it.

PR #113 feat(intake):     add native Django intake and durable Temporal mail
PR #115 feat(review):     run native stages with durable evidence and bounded admission
PR #116 feat(deploy):     promote authenticated immutable image archives
PR #117 feat(profile):    persist native review profiles and durable CRM projection
PR #118 feat(ci):         record complete shard phase and worker timings
PR #119 feat(onboarding): add Select partner footers and repair bounded CI setup

Each PR carried its own gate subset. The full suite ran only when the last commit on the immutable milestone branch was in place. That ordering matters: a partial green badge on a partial stack is not a parking artifact. It is a half-truth.

The atomic push

The push that turned the work into a parking artifact looked like this:

# After the full makecheck suite passed locally and was re-run by CI on the same SHA:
git push origin feat/django-agreement-lifecycle:feat/django-agreement-lifecycle \
  --ff-only
git push origin feat/django-agreement-notifications:feat/django-agreement-notifications \
  --ff-only

Two pushes, both fast-forward only. The remote tip is byte-identical to the local tip. No merge commit hides what was actually shipped. No force push re-writes history. A reader six months from now can run git log on either branch and reconstruct the exact build state.

The atomic property is the load-bearing one. A merge commit would let a future force-push hide reverts. A non-fast-forward push would break anyone who already has the branch checked out. Neither breaks the next person, but both break the parking pattern's audit trail.

The gate suite on the merged commit

The full gate suite ran on the immutable milestone commit, not on the moving feature branches:

makecheck terminal PASS 598.411s
  1746 unit + 1 skip
  2764 SQLite + 160 skip
  436 pilot
  static + security

PG terminal 4659 PASS / 14 skip / 4673 collected
  1262.33s test / 1271.060s whole

v2 coverage audit PASS
Independent reviewer APPROVE <commit> ONLY

The reviewer line is the one most teams skip. A human (or a strictly scoped reviewer agent) confirms the gate results match the code. Without that confirmation, a green badge is a CI vendor's promise. With it, a green badge is a recorded decision by the team that owns the codebase. The parked refactor is recoverable because the gate results are pinned to the commit, not to the workflow run.

The cutover stays on Flask

Production stayed on Flask main. The Django stack was pushed to its feature branches, and the PR was converted to draft. A full-ref backup bundle was written to ~/backups/catalyst-onboarding-preserve-* the following morning; the path-embedded date is for the snapshot job that wrote it, not for the work itself. The bundle is belt-and-suspenders: the feature branches are the primary artifact, the backup is the secondary. Neither mutates production.

This is the second decision, the one the publish-and-park pattern splits out. The decision is not "is the work done." It is "is this the right moment to point production at it." The two questions have different owners, different evidence, and different reversibility costs. Welding them together is what makes migrations feel like a one-way door.

Why not the obvious approach?

The obvious approach is to merge the Django stack to main, let CI go green, and cut over. Three reasons that fails:

The badge is on the branch, not the commit. A green badge on main after the merge tells you the gate suite passed against a moving target. Anyone who has reset main to undo the merge invalidates the badge retroactively. The parked refactor has no such exposure: the gate results are pinned to the commit SHA on the feature branch, and that SHA does not move.
Cutting over is a single failure domain. If the cutover breaks, you do not know whether the bug is in the new code, in the deploy step, or in the rollback. With the cutover decoupled, the new code can sit on a feature branch for months while the deploy step is rehearsed separately. The two failure domains stay separate.
The "do not cut over" decision has nowhere to live. A merge to main is the act of cutting over, by definition. There is no document you can write that says "this is on main but do not use it" without breaking the social contract that main is production. The decision record has to land before the merge, which means the merge has to be deferred, which means the work has to live on a feature branch.

The pattern is not a workaround for a missing feature. It is the only shape that makes parking an owner recoverable.

The "do not cut over" record

The decision record is a PR, not a wiki page and not a numbered-record entry. PR #124 in catalyst-onboarding carries the dated decision that the Django stack stays parked and Flask stays in production. The PR body names the commit, links the full-ref bundle, lists the gates that passed, and names the successor repo.

The PR is the artifact a future reader finds before they touch the parked work. A wiki page rots. A numbered-record entry (each repo's dated folder of decision history) can be moved, renamed, or lost when the numbering scheme changes. A PR lives at the top of the repo's pull request list until it is closed, and its merge commit lives in main history forever.

The successor repo

The parked refactor is not abandoned because it has a successor: intent-solutions-io/catalyst-onboarding-v2, opened the following morning with the beads (a tracked task record in the repo's issue database) prefix catalyst-v2 and no code. The planning-phase foundation exists so the parked work has somewhere forward to go.

A parked refactor without a successor is a dead branch. A parked refactor with a successor is a deferred plan. The successor repo does not have to contain the parked work; it has to contain the plan for the parked work. The Django stack on feat/django-agreement-lifecycle is the parking artifact; catalyst-onboarding-v2 is the forward home.

What survives a routine branch cleanup

The parked refactor survived a repo sweep that removed 34 temporary worktrees and deleted 25 merged branches. The work lives on the published feature branches and on main history, not in disposable worktrees or speculative branches.

Atomic fast-forward pushes land on real branches with real tips. A repo sweep that removes temporary worktrees and merged branches cannot touch those tips without changing the published history. That is a consequence of invariant one: durable artifacts outlive routine cleanup.

What did not change the parked work

In the 24 hours after the parking decision, a parallel hardening window merged fifteen fixes in claude-code-plugins: patched advisories in shipped MCP servers, upgraded actions/cache, actions/github-script, codecov-action, the cosign installer, download-artifact, pnpm/action-setup, and Vitest. None of those PRs touched the parked Django work. None of them needed to. The decoupling held under a load that would have broken a single-stack deployment.

The point is not that the hardening window was easy. The point is that it was possible without a deploy coordination meeting. Two repos, two lifecycles, no shared cutover.

Use this

Push the refactor as --ff-only to a feature branch, not as a merge to main. The atomic property is what makes the gate suite pin to a commit instead of a moving branch.
Run the full gate suite on the merged commit, including the independent reviewer. A CI badge is the vendor's promise; a reviewer-approved badge is the team's promise.
Write the "do not cut over" decision as a PR, and open a successor planning repo. The decision has to live where the next reader will find it, and the parked work has to have somewhere forward to go.

The Django stack in catalyst-onboarding is parked. The work is not abandoned. The five invariants held, and parking the cutover became a reversible decision instead of a one-way door.

The parked Django work and the dated parking decision: intentsolutions pull 120 and pull 124.

Frequently asked questions

How do you park a refactor without abandoning it?

Five invariants hold: the work lands as an atomic fast-forward push, the gate suite pins to the merged commit (including an independent reviewer), no production mutation happens at ship time, a "do not cut over" decision record lands in the repo, and a successor repo gives the parked work somewhere forward to go. Drop any one and the parked work becomes abandoned in slow motion.

When should you delay a production cutover after a green merge?

Delay when a green badge sits on a moving branch, when the cutover and rollback share one failure domain, or when the "do not cut over" decision has nowhere to live. Parking keeps the new code on a feature branch with a pinned badge, so the deploy step can be rehearsed independently before the swap.

Why not merge to main and cut over later?

A green badge on main sits on a moving target that any reset invalidates retroactively, a cutover welded to a merge is one failure domain, and a "do not cut over" decision has no place to live when main is the act of cutting over. Parking keeps work, gate results, and decision on separate durable artifacts.

three-pass-settlement-recurring-ai-pipeline-contract: A recurring AI pipeline contract project settles only after a third evidence pass that closes every named gap with a concrete file and pins every changed gate manifest. Sister pattern: durable artifacts settle the work; here they keep the work parked.
name-the-single-authority-in-a-daily-pipeline: When a daily pipeline runs unobserved, every concern accumulates competing authorities; the cure is to name exactly one authority per concern. Decision-22 is the named authority here.
link-public-surface-to-deployment-thesis: The publish-and-park pattern breaks the public-surface-to-deployment link on purpose; the cataloged post argues the opposite. Worth reading both before committing a migration.

{ "@context": "<a href="https://schema.org">https://schema.org</a>", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "How do you park a refactor without abandoning it?", "acceptedAnswer": { "@type": "Answer", "text": "Five invariants hold: the work lands as an atomic fast-forward push, the gate suite pins to the merged commit (including an independent reviewer), no production mutation happens at ship time, a 'do not cut over' decision record lands in the repo, and a successor repo gives the parked work somewhere forward to go. Drop any one and the parked work becomes abandoned in slow motion." } }, { "@type": "Question", "name": "When should you delay a production cutover after a green merge?", "acceptedAnswer": { "@type": "Answer", "text": "Delay when a green badge sits on a moving branch, when the cutover and rollback share one failure domain, or when the 'do not cut over' decision has nowhere to live. Parking keeps the new code on a feature branch with a pinned badge, so the deploy step can be rehearsed independently before the swap." } }, { "@type": "Question", "name": "Why not merge to main and cut over later?", "acceptedAnswer": { "@type": "Answer", "text": "A green badge on main sits on a moving target that any reset invalidates retroactively, a cutover welded to a merge is one failure domain, and a 'do not cut over' decision has no place to live when main is the act of cutting over. Parking keeps work, gate results, and decision on separate durable artifacts." } } ] }

Team-Page Ordering Is a Release Decision

Jeremy Longshore — Wed, 30 Sep 2026 11:30:11 +0000

A new Legal Counsel profile landed at the bottom of the team page yesterday. Heather Johnson was the most consequential reader-facing contact on the page, and the page put her last. The fix shipped thirty-four minutes later as v4.4.1, because team-page ordering is a release decision, not a content decision, and treating it as one is what keeps a canonical team page authoritative across eight linked properties.

How should team pages be ordered?

Team-page ordering should put the highest-value reader-facing contact first, after the founder. For a regulated AI practice that is Legal Counsel; for a design studio it might be the creative leads. The rule is short: name who readers are most likely to need, list them in that order, document the rule, and reorder when a new profile lands.

What shipped and what did not

The intent-solutions-landing repo (the source of truth for the company team surface at intentsolutions.io/about/#team) shipped v4.4.0 at 18:49 CDT. The PR added seven team photos, a new team.json roster, a HeatherJohnson.astro profile page, and an updated footer link. The original reviewer caught the ordering at 19:18, while the v4.4.0 deploy was still propagating through the cache. The reviewer did not flag the order as "wrong." They flagged it as "wrong for the audience the page is about to serve." That distinction is what the rest of this post defends. The roster looked like this:

[
  { "name": "Jeremy Longshore", "role": "Founder" },
  { "name": "Opeyemi Adeyemi", "role": "Operations" },
  { "name": "Pablo Hernandez", "role": "Engineering" },
  { "name": "Max Sheahan", "role": "Education" },
  { "name": "Tim Yates", "role": "AI Engineering" },
  { "name": "Tolulope Bakare", "role": "Engineering" },
  { "name": "Heather Johnson", "role": "Legal Counsel" }
]

The order is hire chronology: founder first, then each subsequent hire in the order they joined. Heather was the most recent hire, so she landed at the bottom. That is the second-most-reasonable default after alphabetical, and it is also wrong for a regulated AI practice where the counsel is the only person on the page a reader might need to reach for a privacy question, a partnership inquiry, or a compliance ask. Hire-chronology works on small teams where seniority is the only signal a reader has. Once a reader needs to find one specific person, it works against them.

v4.4.1 reordered the file thirty-four minutes later:

[
  { "name": "Jeremy Longshore", "role": "Founder" },
  { "name": "Heather Johnson", "role": "Legal Counsel" },
  { "name": "Opeyemi Adeyemi", "role": "Operations" },
  { "name": "Pablo Hernandez", "role": "Engineering" },
  { "name": "Max Sheahan", "role": "Education" },
  { "name": "Tim Yates", "role": "AI Engineering" },
  { "name": "Tolulope Bakare", "role": "Engineering" }
]

The diff is six lines moved up. The semantic change is that the page now answers the question a reader is most likely to bring to it, before they have to scroll past six other faces.

Why not the obvious approach?

Two reasonable defaults existed. The first was alphabetical, which we considered and rejected as a draft. The second was the as-hired ordering we actually shipped: it is a content decision masquerading as a release decision. The team page is the canonical contact surface for the whole estate, and a reader does not care who joined first. They care who can answer their question.

The third option, leaving the order to whoever maintains the page next, is the one that drifts. Within three months, someone adds a contractor. Then a summer intern. Then the intern moves up but stays where they are. The team page stops being authoritative and starts being a snapshot.

We chose the role-priority ordering with an explicit rule: after the founder, the page lists people in the order a reader is most likely to need them. Legal first, then operations, then the engineering and education roles together, then everything else. The rule is short enough to fit on a sticky note, and short enough that a maintainer three jobs from now will still apply it.

The role-priority rule is not universal. It is the right rule for a regulated AI practice where the counsel is the highest-value contact. It would be the wrong rule for a design studio where the reader wants to see the creative leads first. The point is not that role-priority is the answer. The point is that the answer is a rule with a name, not a one-off decision the original author made and forgot to document.

The 30-minute footer sweep

The same moment v4.4.0 landed, eight repos each picked up a new "Our team" footer link pointing at intentsolutions.io/about/#team. The sweep window was 18:59 to 19:29 CDT, roughly thirty minutes. Six of those repos are public landing surfaces (intent-demos, omarchy, diagnostic-pro, startaitools, hustle, claude-code-plugins). The seventh is intent-solutions-landing itself, whose team.json is the source of truth. The eighth is now-lms, which also renders its own team profile and shipped the CI gate.

The footer change per repo was mechanical. Each inserted a single line into its existing footer list, between "About" and the next item:

<li><a href="https://intentsolutions.io/about/#team">Our team</a></li>

The insertions are byte-different per repo because each footer is a different framework (site/index.html for the static HTML sites, Footer.tsx for diagnostic-pro, layouts/partials/footer.html for the Hugo build, src/app/(public)/page.tsx for the Next.js hustle app, marketplace/src/layouts/BaseLayout.astro for the Astro marketplace). The pattern is identical. Eight repos, one anchor, one canonical URL, one PR opened in each repo on the same minute by the same author.

The mechanics matter because they explain why the ordering hotfix had to ship in the same hour. When footers sweep together, the page they point at becomes the contract for the whole estate. By 19:00 CDT, every footer in the estate was pointing at a team page that had Heather at the bottom. The hotfix is not a content correction. It is a release of a new public fact, and the new public fact is the ordering on the page those eight footers resolve to. Waiting twenty-four hours would have meant twenty-four hours of every visitor to any of those eight sites seeing a team page with a regulated-AI Legal Counsel buried seventh.

The rollback path was open if v4.4.1 had broken the build: revert the team.json diff, cut v4.4.2, redeploy. Eight footers would have re-resolved to the v4.4.0 ordering for the duration of the rollback. That is the cost of treating a team page like a release: you owe it a rollback, and a rollback is cheap when the change is six lines of JSON moved up.

The alternative, batching the hotfix into the next deploy window, was the original instinct. Batching would have meant a coordinated revert of the eight footers, which is its own release with its own rollback path. The hotfix was cheaper than the batch. That is the math that decides whether something ships same-day or waits.

The CI gate: check_estate_bar.py

Once eight repos link to one URL, that URL becomes load-bearing in a way a single-site URL never is. A rename to /team/ or a layout shift that breaks the #team anchor would silently rot every footer in the estate. The now-lms repo shipped scripts/check_estate_bar.py in the same hour, a 79-line Python check that hits the canonical URL and verifies the anchor still resolves to a non-empty team roster. The gate is intentionally minimal. It does not parse the ordering. It does not check the photo count. It checks the load-bearing claim: this URL is a roster, and the roster is present.

def main() -> int:
    target = os.environ.get("ESTATE_TEAM_URL", DEFAULT_URL)
    r = requests.get(target, timeout=10, headers={"User-Agent": "check-estate-bar/1"})
    r.raise_for_status()
    soup = BeautifulSoup(r.text, "html.parser")
    anchor = soup.find(id="team")
    if anchor is None:
        print(f"FAIL: {target} has no #team anchor", file=sys.stderr)
        return 1
    members = anchor.find_all(attrs={"data-team-member": True})
    if len(members) < 1:
        print(f"FAIL: {target} #team has no roster", file=sys.stderr)
        return 1
    print(f"PASS: {target} #team has {len(members)} members")
    return 0

The check is a deterministic fact: the URL resolves, the anchor resolves, the roster is non-empty. It does not check ordering, because ordering is a release decision and we already made the release. It checks that the page is still authoritative. That is the gate's job.

The check is wired into now-lms CI as a required step. The other seven repos do not run it yet; they each link to the same URL and would each fail in the same way if the page rotted. Wiring them all is the next bead.

What this looks like at three months

Without the CI gate, the page drifts. A volunteer contributor renames the anchor for SEO. A designer moves the roster into a tabbed component. An image lazy-loads wrong and the team section renders empty on the first paint. None of those changes break the page locally. They all break the eight footers silently, because the footers still resolve to a 200 and the link still works, but the reader who clicks "Our team" lands on a page that does not answer their question.

We have lived this pattern before on the same estate. A blog post URL moved in March and four linkers rotted quietly until a reader complained in July. An "Our partners" anchor moved under a redesign in April and the cross-link from the partner portal went to a blank section for the better part of a quarter. The pattern is consistent: a small, semantic change to a canonical page is invisible at the page itself and silently broken at every other surface that links to it.

The CI gate catches two of those three failure modes. The third is a renderer bug, and we have not yet decided whether the gate should expand to cover it. For now, the gate is a presence check, not a quality check. That is the right scope for a 79-line script. Expanding it into a full render check means either a headless browser (slow, flaky, expensive) or a snapshot regression (cheap, brittle, drifts with any visual change). The presence check is the floor that catches the worst class of bug at zero ongoing cost.

The other thing a CI gate does is give the next maintainer permission to push back. Without the gate, the only signal that "the team page is load-bearing" is the eight footers, and a maintainer three jobs from now will not count the footers. With the gate, the dependency is a line in CI: "this URL must resolve to a roster." That is a contract someone can read, and contracts outlive institutional memory.

What "estate anchor" actually means

An estate anchor is a URL that other properties depend on as a contract rather than as a reference. A reference is a link a reader clicks if they are curious. A contract is a link that is supposed to resolve to a specific thing, and the thing it resolves to is part of what the linking page is asserting.

The footer sweep turned intentsolutions.io/about/#team from a reference into a contract. Before the sweep, the page was a page. After the sweep, eight footers were asserting "click here and find our team." The assertion is the contract. If a reader clicks and does not find a team, the footer has lied to them, and the lie is silent because the footer still resolves to a 200.

Most estates cross the reference-to-contract line without noticing. There is a docs page that points at a pricing surface, a marketing page that references a changelog, and a partner directory that cross-links a contact page. Each link is small. In aggregate, each is a contract. The CI gate is the moment a team acknowledges the contract exists.

The cost of acknowledging the contract is small. The check is 79 lines. The wiring is one line per repo. The maintenance is one URL to remember. The benefit is that the next push to a wired repo that renames the anchor or moves the roster into a tabbed component gets a red CI run and a one-sentence error explaining why their change broke the estate. The remaining seven footers still depend on the URL, so wiring the gate into every one of them is the next bead; until that ships, a rename on intent-solutions-landing itself will only be caught on the next gated push. That is enough to make the right decision the easy one.

The next time a similar pattern comes up on the estate (a new partner joins the directory, a new pricing tier appears, a new compliance doc publishes) the discipline is already there. Same-day fix if the canonical surface changes. CI gate before the third link points at it. The team page was the first anchor in the estate to get the full treatment. The pattern is now load-bearing for every anchor that comes after it.

That is the lesson. A team page is a page. A team page that eight footers depend on is a contract. The cost of treating it like one is one extra script and one extra hour.

Also shipped

The rest of the day's work that does not fit the team-page finding:

now-lms (#125) shipped the estate-bar check plus the matching team profile rendering for Heather, with the same ordering rule as the canonical surface.
intent-os shipped the whiteglove distribution packet (3516 lines, nine print PDFs) and the matching ownership verification records.
hustle v3.3.7 and startaitools v1.21.14 auto-bumped on the same day as the team-link fix landing in each repo.
omarchy refreshed its public plugin facts from the GitHub API (generated content only, no semantic change).

The discipline, generalized

The team page is one canonical surface among several on this estate. The partner directory is another. The pricing page is a third. The published-changelog index is a fourth. Every one of them is a page that other repos link to, and every one of them has the same problem: a small, semantic change is invisible at the page and silently broken everywhere else.

The team-page fix generalizes to a rule: when a single canonical surface becomes load-bearing across the estate, treat every edit to it as a release. The release gets a version bump, a changelog entry, a same-day hotfix window, and a CI gate that proves the URL still resolves to what the linkers expect. None of that is novel. It is the same discipline every API publishes under. The point is that a marketing page deserves the same treatment the moment it becomes an estate anchor, and most pages become estate anchors without anyone noticing.

The reason this matters for a team page specifically is that the failure mode is invisible to the team and visible only to the reader. The team sees the page render correctly in their browser. The reader sees a page where the person they came for is seventh. The cost of getting the ordering wrong is paid by people who never show up in your bug tracker.

Use this

Treat team-page ordering as a release decision. Pick a rule short enough for the next maintainer to apply without asking, document it once, and reorder on the day a new profile lands.
When you turn a single-site URL into an estate anchor, ship a deterministic check that the URL still resolves to the thing eight footers expect. 79 lines of Python is enough for the first gate.
Order the canonical team page by the question a reader is most likely to bring, not by hire date and not by alphabet. The page is a contact surface, not a roster. The exact ordering depends on what the reader is most likely to want; the discipline is that the ordering is named, defended, and written down next to the file.

FAQ

Why should team-page ordering be treated as a release decision?

A team page becomes load-bearing the moment multiple footer links point at it. Once eight footers assert "click here and find our team," the ordering is a public fact the estate is publishing, not a content choice. A same-day hotfix is cheaper than batching, because batching would mean a coordinated revert of every footer that points at the page. The page is a contract that other sites depend on, and contracts get release discipline.

What is an estate anchor?

An estate anchor is a URL that other properties depend on as a contract rather than as a reference. A reference is a link a reader clicks if curious; a contract is a link that should resolve to a specific thing, and the thing it resolves to is part of what the linking page is asserting. If the anchor breaks, every linking surface silently lies because the link still returns a 200 but the reader does not find what they were promised.

How do you keep a team page authoritative across multiple sites?

Ship a deterministic CI gate that hits the canonical URL and verifies the anchor still resolves to a non-empty roster. The check_estate_bar.py gate is 79 lines of Python and runs as a required CI step in now-lms. Wiring it into every other linking repo is the part that catches silent drift when a designer moves the roster into a tabbed component or someone renames the anchor.

{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "Why should team-page ordering be treated as a release decision?",
"acceptedAnswer": {
"@type": "Answer",
"text": "A team page becomes load-bearing the moment multiple footer links point at it. Once eight footers assert 'click here and find our team,' the ordering is a public fact the estate is publishing, not a content choice. A same-day hotfix is cheaper than batching, because batching would mean a coordinated revert of every footer that points at the page. The page is a contract that other sites depend on, and contracts get release discipline."
}
},
{
"@type": "Question",
"name": "What is an estate anchor?",
"acceptedAnswer": {
"@type": "Answer",
"text": "An estate anchor is a URL that other properties depend on as a contract rather than as a reference. A reference is a link a reader clicks if curious; a contract is a link that should resolve to a specific thing, and the thing it resolves to is part of what the linking page is asserting. If the anchor breaks, every linking surface silently lies because the link still returns a 200 but the reader does not find what they were promised."
}
},
{
"@type": "Question",
"name": "How do you keep a team page authoritative across multiple sites?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Ship a deterministic CI gate that hits the canonical URL and verifies the anchor still resolves to a non-empty roster. The check_estate_bar.py gate is 79 lines of Python and runs as a required CI step in now-lms. Wiring it into every other linking repo is the part that catches silent drift when a designer moves the roster into a tabbed component or someone renames the anchor."
}
}
]
}

Use the Primitive, Not the Patch (the same-day-sweep discipline, applied to a security primitive rather than a team page).
Scope Federated Tailscale Trust to Auth Keys (federating one identity surface across the same eight-repo footprint, with the same anchor-page release posture).
Pin the Installer and Add a Renewer (a named rule plus a CI gate that catches silent drift, the same shape as check_estate_bar.py).

Tailscale Federated Trust: Scope to Auth Keys, Not All

Jeremy Longshore — Sun, 27 Sep 2026 11:30:11 +0000

Tailscale Federated Trust: Scope to Auth Keys, Not All

A Tailscale federated trust hands an external identity (in my case, GitHub Actions OIDC) an API token whose reach is governed by a scope field on the trust record. The default is ['all'], which gives that external identity every API the underlying token can reach. If the token is account-admin, your CI runner now is too.

I had 18 deploy trusts wired that way. Every one of them creates a short-lived auth key to land a build on the VPS over Tailscale SSH. None of them need anything else. On 2026-09-25 I narrowed every one to scope:['auth_keys'], re-encrypted the SOPS secrets bundle, and proved it on a real jeremylongshore.com production deploy.

What a federated trust actually is

Tailscale's term for "let an external identity mint a short-lived Tailscale API token" is a federated trust: a record that maps an OIDC subject (or a SAML subject, or a workload identity federation principal) onto a Tailscale API token. The trust is created once by an admin. The external identity uses it on every CI run to mint a fresh, narrowly-scoped auth key. The fresh auth key is what actually gets used to bring a runner onto the tailnet.

The trust does not move packets. It only mints keys. The runner uses the key to register a node, the node runs the deploy, the node goes away when the key expires.

A trust record stored on Tailscale's side looks roughly like this:

{
  "id": "trust_abc123",
  "provider": "github",
  "subject": "repo:intent-solutions-io/jeremylongshore.com:environment:production",
  "scopes": ["all"],
  "token_id": "tk_xyz789",
  "created_at": "2026-04-12T18:22:01Z"
}

The scopes field is what the trust is allowed to ask the token to do. It is not what the runner gets to do once the runner is on the tailnet. Those are two different layers, and a ['all'] trust means the trust itself is allowed to ask the token to do anything, on every CI run, until someone narrows it.

The shape of the trust matters because the trust gets a token, and the token has scope. If the trust was created with an account-admin token and scope:['all'], the OIDC subject inherits that token's full reach every time the trust is exercised. The fact that the runner itself only needs auth_keys does not constrain what the trust can be tricked into minting.

The default that bit me

The Tailscale CLI's tailnet set-trust-credentials (and the web UI's equivalent) defaults scope to ['all'] when you do not pass it. Most of the docs and most of the tutorials do not tell you that, because most of them are written for the "set it up once and forget it" case. My case was 18 separate repos, each one a deploy, each one created when I was hurrying. The hurrying is why they were all ['all'].

The whole change is one line in the trust config.

   trust:
     provider: github
     subject: repo:intent-solutions-io/<repo>:environment:production
-    scopes:
-      - all
+    scopes:
+      - auth_keys

The only change is scopes: [auth_keys]. The OIDC subject is unchanged. The token it maps onto is unchanged. The runner still gets to mint an auth key. It no longer gets to mint anything else.

In SOPS, the edit lands in ops/host/secrets/secrets.prod.sops.yaml, gets re-encrypted with sops update, and the next deploy reads the new scope. The trust itself is updated on Tailscale's side by a follow-up tailscale set-trust-credentials --scopes=auth_keys call, which Tailscale reconciles with the SOPS record. The two stay in sync because both are produced from the same workflow. The secrets.prod.sops.yaml re-encrypt was the headline change in 62f100aa; the per-trust config edits in intent-os/ops/deploy/ followed in the same commit.

Why this is not paranoia

Two reasons this matters beyond hygiene.

First, the trust is the long-lived artifact. The token underneath can be rotated; the trust persists. If the trust says ['all'], every rotation of the token keeps the same reach. The scope is what does not get narrower over time without deliberate action. You set it on day one, then forget, and the day you forget is the failure mode.

Second, the blast radius of an OIDC mis-substitution is bigger than people assume. GitHub Actions lets you constrain an environment's deployment branch, required reviewers, and protection rules, but it does not let you constrain which subject string the Actions OIDC token actually carries on a particular run if the workflow file is wrong. A workflow that accidentally trusts a fork PR will issue an OIDC token whose subject matches the trust's subject regex, and the trust will mint whatever its scope allows. ['all'] is the worst-case scope for that failure mode. ['auth_keys'] is the floor: even a misrouted OIDC exchange only ever produces a key, and the key lands on a tailnet ACL that the runner still has to walk through.

The proof

The way I prove a trust change actually works is to run a real production deploy after the change. For jeremylongshore.com, that is run 36106653875 on GitHub Actions. The deploy job:

Exchanges the OIDC token against the trust, asks for an auth key.
Uses the auth key to bring the runner onto the tailnet as a node tagged tag:ci.
SSHes to the VPS as the deploy user, lands the build, exits.
The auth key expires. The runner node drops off the tailnet.

The shape of step 1 looks like this in the deploy step (paraphrased, not the literal workflow):

- name: Bring runner onto tailnet
  env:
    ACTIONS_ID_TOKEN_REQUEST_TOKEN: ${{ secrets.GH_OIDC_TOKEN }}
    TS_AUTHKEY: ${{ steps.authkey.outputs.key }}
  run: |
    curl -fsSL https://tailscale.com/install.sh | sh
    sudo tailscale up --authkey="$TS_AUTHKEY" --hostname="gh-runner-$GITHUB_RUN_ID" --tags=tag:ci
- name: SSH to VPS and deploy
  uses: appleboy/ssh-action@v1
  with:
    host: intentsolutions
    username: deploy
    script: |
      cd /srv/jeremylongshore && git pull --ff-only && ./deploy.sh

The auth key is fetched first, separately, from Tailscale's federated trust exchange endpoint. The runner then uses that key for tailscale up. The deploy step SSHes to the VPS as the deploy user, lands the build, exits. The runner node drops off when the auth key expires.

After the scopes: [auth_keys] change, run 36106653875 completed end-to-end in 41 seconds. The runner registered, the deploy shipped, the node tore down. The runner could reach nothing beyond an auth key. I verified that by calling tailscale set-acl from inside the same job and getting this back:

$ tailscale set-acl --acl-file=/tmp/empty.json
Error: HTTP 403: scope_mismatch (trust_scopes=auth_keys; required=acl)

That is the proof. A deploy that does not try set-acl does not notice the change; a misrouted OIDC exchange that does try it now fails closed at the trust, before the token is even consulted. The runner gets back a 403 it can log and alert on, which is what you want: a loud refusal, not a silent partial success.

The full sweep was 18 deploy trusts across intent-os, braves-booth, diagnostic-pro, hustle, startaitools, tonsofskills, and the jeremylongshore.com site. The Omarchy one needed an extra step: that trust had been deleted and had to be recreated with its immutable OIDC subject read from GitHub, not pasted in (fd2ba8f9). The other 17 were a sops re-encrypt and a config edit. The deploy pattern is the same; only the OIDC subject string and the tag differ per trust.

Why not just leave scope at all and rely on ACL

Because ACL is a different layer and they do different jobs. The trust scope controls what the trust can do at the trust-mint boundary. The tailnet ACL controls what an already-on-the-tailnet node can reach. If you leave scope:['all'] and rely on ACL to keep the runner pinned, you have moved the only thing protecting you into a layer that the runner bypasses before it gets there.

For my deploys the ACL layer was also locked. The relevant tag:ci rule from the tailnet ACL is roughly:

{
  "tagOwners": {"tag:ci": ["autogroup:admin"]},
  "acls": [
    {
      "action": "accept",
      "src": ["tag:ci"],
      "dst": ["tag:deploy-vps:22"]
    }
  ]
}

That rule pins tag:ci to SSH-only access to the deploy user on the VPS. The runner cannot reach any other node, cannot reach the admin console, cannot make API calls that go through the tailnet. So even an unscoped ['all'] trust would have been pinned down by ACL once the runner registered. The trust scope and the ACL are belt and suspenders, not belt or suspenders. I want both. The narrower trust scope is also the change that survives token rotation, which the ACL does not. Rotate the underlying Tailscale API token every 90 days and the trust scope stays auth_keys automatically, because the scope is on the trust, not on the token.

There is also a third layer people forget about: the Tailscale admin console itself. An account-admin API key minted through a ['all'] trust can call tailscale set-acl against the entire tailnet, including deleting or rewriting ACLs. That is not "the runner touches a node." That is "the runner rewrites the rule that decides what nodes can touch." The trust scope is what stops that path before it starts.

How the work went

The session digest for the day shows the bulk of the operator work landed with MiniMax M3 (the bead triage, the sweep agents, the evidence filing). The trust scope rewrite itself was a single line repeated 18 times, but the design of "what scope to set, on what trust, with what proof" came out of a back-and-forth with Claude Opus 5.5. The Omarchy trust recreation, which needed the immutable OIDC subject read from GitHub rather than pasted in, was Claude Fable 5.1 because the change was small and well-bounded.

The estate-graph proof isolation work in PRs 696, 697, and 698 was reviewed by Claude Sonnet 5 and shipped clean. The collaboration score for the day (0.275, 64 failure-to-fix transitions) is high because the estate sweep agent did the bulk of the bead triage, which generated a lot of small fix loops. The trust scope change itself was almost all up-front design and a one-line config edit per trust.

Also shipped

VPS liveness sweep cleared (intent-os #681); two standing findings closed and a parked row acknowledged.
Estate-graph proof isolation merged (#696, #697, #698): operator queries are now read-only and the validation path is isolated from operator state.
Production smoke suite rewritten for the marketplace-site redesign (f80cc59ad): 132/132 chromium+webkit green on the post-deploy e2e.
CI now fails when plugin verification scores drift from the validator (df3fdae75).
@intentsolutionsio/ccpi bumped to 3.0.0 on the Node 22 floor (not yet published to npm latest; publish is tag-triggered).

Use this

When you create a Tailscale federated trust, set scopes: [auth_keys] explicitly. The default is ['all'].
Treat the trust scope and the tailnet ACL as two separate layers. Lock both. A ['all'] trust behind a tight ACL is still worse than a ['auth_keys'] trust behind the same ACL, because the trust scope is what survives token rotation.
After you change a trust's scope, prove the change on a real production run, not just a tailscale set-trust-credentials --dry-run. The dry run tells you the API accepted the call; only a deploy tells you the OIDC exchange still resolves.

FAQ

What is a Tailscale federated trust?

A Tailscale federated trust is a record that maps an external identity (GitHub Actions OIDC, SAML, or a workload identity federation principal) onto a Tailscale API token. The trust is created once by an admin. The external identity uses it on every CI run to mint a fresh, narrowly-scoped auth key. The fresh auth key is what actually brings a runner onto the tailnet; the trust itself only mints keys.

What does scope:['all'] actually grant on a federated trust?

The scope field on the trust record governs what the trust can ask its mapped token to do. The default is ['all'], which gives the external identity every API that mapped token can reach. If that token is account-admin, the CI runner inherits that reach on every run, even if the runner itself only needs auth_keys.

Why not just rely on the tailnet ACL instead of narrowing the trust scope?

The trust scope controls what the trust can do at the trust-mint boundary. The tailnet ACL controls what an already-on-the-tailnet node can reach. Leaving scope:['all'] and relying on ACL moves the only thing protecting you into a layer the runner bypasses before it gets there. A ['all'] trust behind a tight ACL is still worse than a ['auth_keys'] trust behind the same ACL, because the trust scope is what survives token rotation.

{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "What is a Tailscale federated trust?",
"acceptedAnswer": {
"@type": "Answer",
"text": "A Tailscale federated trust is a record that maps an external identity (GitHub Actions OIDC, SAML, or a workload identity federation principal) onto a Tailscale API token. The trust is created once by an admin. The external identity uses it on every CI run to mint a fresh, narrowly-scoped auth key. The fresh auth key is what actually brings a runner onto the tailnet."
}
},
{
"@type": "Question",
"name": "What does scope:['all'] actually grant on a federated trust?",
"acceptedAnswer": {
"@type": "Answer",
"text": "The scope field on the trust record governs what the trust can ask its mapped token to do. The default is ['all'], which gives the external identity every API that mapped token can reach. If that token is account-admin, the CI runner inherits that reach on every run, even if the runner itself only needs auth_keys."
}
},
{
"@type": "Question",
"name": "Why not just rely on the tailnet ACL instead of narrowing the trust scope?",
"acceptedAnswer": {
"@type": "Answer",
"text": "The trust scope controls what the trust can do at the trust-mint boundary. The tailnet ACL controls what an already-on-the-tailnet node can reach. Leaving scope:['all'] and relying on ACL moves the only thing protecting you into a layer the runner bypasses before it gets there. A ['all'] trust behind a tight ACL is still worse than a ['auth_keys'] trust behind the same ACL, because the trust scope is what survives token rotation."
}
}
]
}

Pin the Installer and Add a Renewer: the day's other big thread; pinning a published dependency and adding a cert renewer in the same pass.
Working Is Not Proven: "every claim needs a shipped source and an executable proof"; the deploy run 36106653875 is exactly that proof.
How the Same Deploy Pattern Crossed Four Repos in One Week: the deploy pattern at small scale; this post is what it looks like when the same pattern lands 18 times.

Three Gates on Standard-User BitLocker State Observation

Jeremy Longshore — Tue, 15 Sep 2026 11:30:13 +0000

The day started with a P1 on merge day

Closing intent-blue-gold Epic 1+2 was supposed to be the easy part. The hard parts were the constraints, set in DOC-075/A03: a standard-user account on ARM64 Windows 11 gets PERMISSION_DENIED from the PowerShell Secure Boot and BitLocker surfaces. WMI is out. COM is out. Elevation is out. Anything that requires a privileged token is out. Everything since then has been about carving the safe space inside that envelope. BitLocker state observation, the volume census, the file inventory, the controller topology, the mapping registry, the criticality capture: each one is a new module boundary in the same constrained envelope.

I ran Codex (GPT-5.6 Sol) read-only against the day's merge candidates on purpose. Eight sessions, 132 turns, 952 minutes on intent-blue-gold over the past week. The audit was not a polish pass. It was a closure gate. It surfaced three P1 blockers. Two of them were exactly the kind of failure the audit exists to catch.

The three gates that have to hold together are: the observer contract, the bounded native provider, and the fixture-boundary authorization. Gate 3 was the one that slipped. The audit caught it on three failure modes at once, two of them the kind the audit exists to catch, and the post is mostly about what the audit found.

Gate 1: the observer contract

The observer contract is the seam between the constrained envelope and any code that wants to read BitLocker state. Anything that talks to GetFveLogicalVolumeInformation-equivalent surfaces has to enter through this contract. Here is the seam in Go.

// BitlockerObserver is the standard-user entry point. It returns
// State with the OBSERVED bit set only when the call ran through
// the helper, the helper authenticated, and the fixture boundary
// held. Anything else is OBSERVED=false, even if the bytes look
// reasonable.
type BitlockerObserver interface {
    Observe(ctx context.Context, vol VolumeRef) (State, error)
}

// State has three meaningful bits:
// OBSERVED  = we ran the native probe and got a result
// CACHED    = we have a non-stale prior observation for this vol
// UNAVAIL  = the probe ran but the OS returned access denied or
//            empty; we treat that as no information, not as "off"
type State struct {
    Volume    VolumeRef
    Status    string // protect_state strings, NOT raw OS bytes
    Observed  bool
    Cached    bool
    Unavail   bool
    Source    ProbeSource
}

The interesting bit is Observed. A naive port of a privileged tool returns the OS bytes regardless of provenance. That is exactly what gets you a "we have a BitLocker reading" row that came from a non-authorized helper or from an arbitrary temp root. The observer contract refuses to label the result Observed unless every gate cleared. The byte string is still in Status, but downstream code is supposed to ignore Status when Observed is false. That is the contract.

Gate 2: the bounded native provider

Gate 2 is the provider that does the actual syscall. Two constraints matter: it has to run in the standard-user process without UAC, without token impersonation, and without a helper service that takes elevation. It also has to refuse any caller who has not presented the authenticated helper boundary. The provider entry point.

func (p *NativeProvider) QueryVolume(ctx context.Context, vol VolumeRef) (State, error) {
    if !p.helperBoundary.Authorized(vol) {
        // Fail closed: an unauthorized caller gets the same answer
        // they would get from an unauthenticated probe. No detail,
        // no exception type, no "near miss" leak.
        return State{Volume: vol, Unavail: true}, ErrBoundaryClosed
    }
    if !vol.IsFixtureAuthorized() {
        // The fixture boundary: even an authenticated helper can
        // not cross outside the manifest-verified fixture. This
        // is gate 3, but we enforce it at the provider entry to
        // avoid a second code path that needs the same guarantee.
        return State{Volume: vol, Unavail: true}, ErrOutsideFixture
    }
    return p.queryViaSyscall(ctx, vol)
}

queryViaSyscall is the boring part. FsctlEnumerateVolumeInformation with a BITLOCKER_INFORMATION header, IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS for layout, fall through to the registry path when the helper IPC returned access denied. The thing worth noticing is what comes BEFORE that: the two early returns. An unauthorized caller and an out-of-fixture caller both get Unavail: true with Observed: false. They get the same answer a probe that genuinely failed would have given. There is no signal that says "we are not telling you because of X."

That is fail-closed by construction. The audit did not flag this gate.

Gate 3: the fixture-boundary authorization (the failure)

Gate 3 was the failure. The file-inventory CLI is supposed to admit only the manifest-verified fixture. The fixture is a checked-in blob with a hash pinned in fixture.manifest. Anything else is a synthetic root, and synthetic roots are test-only. The CLI was supposed to refuse a synthetic root at admission. Here is what the gate looks like.

// Authorized root check. The CLI calls this before any work.
func (a *FixtureAuth) Authorize(root string) error {
    manifest, err := LoadManifest()
    if err != nil {
        return err // no manifest, no authorization, fail closed
    }
    pinned := manifest.CanonicalRoot()
    if !pathEqual(root, pinned) {
        // Synthetic roots are valid in tests, but the production
        // CLI is not a test. Production admission refuses them.
        return ErrSyntheticRootRejected
    }
    if !manifest.HashMatches(root) {
        // The pinned root is the right path but the bytes don't
        // match. That is a fixture drift, also a hard refusal.
        return ErrFixtureDrift
    }
    return nil
}

That is what the code is supposed to do. Codex found that prototypes/blue-windows/cmd/file-inventory/main.go:54-76 accepts any directory containing a user-created marker and then scans its Desktop, Documents, Downloads, and Pictures children. A caller can add the marker under a live profile and receive filenames, sizes, and paths in the receipt. DOC-076:20-26 says the checked-in fixture is the only root authorized, and the authorization's synthetic-root-only constraint is supposed to bind production admission. The code did not bind it. The CLI was test-friendly and production-broken in the same binary.

The minimal fix is to call FixtureAuth.Authorize from main.go:54-76 before any traversal. The CLI keeps its test ergonomics because the test harness can register a synthetic root with the test-only RegisterSynthetic hook, but the production binary refuses anything except the canonical fixture or a manifest-verified immutable fixture. That is what is shipping today. The audit caught it on merge day, the fix is small, and the constraint is the right one.

The TOCTOU reparse replacement (gate 3, the second finding)

The same audit flagged a separate failure in scan.go:185-216: path-based ReadDir, Lstat, then recursive ReadDir. A validated directory can be swapped for a reparse point mid-traversal. That is a classic TOCTOU path for read-only enumeration to follow attacker-controlled targets. The standard fix on Linux is O_DIRECTORY | O_NOFOLLOW, then keep the file descriptor and enumerate from it. On Windows the equivalent is to open with FILE_FLAG_OPEN_REPARSE_POINT and the standard share-mode set, capture the handle, and re-validate the reparse status from the handle before walking into children. The sketch:

// Linux side: open the directory once, hold the fd, refuse to walk
// a reparse change observed post-open.
fd, err := unix.Open(path, unix.O_RDONLY|unix.O_DIRECTORY|unix.O_NOFOLLOW, 0)
if err != nil { return err }
defer unix.Close(fd)
// Snapshot the reparse status at open time, then compare against
// each entry's d_type before deciding to descend. (The full
// re-validation lives in the production helper; the sketch is the
// shape, not the implementation.)
entries, err := unix.Getdents(fd)

The Windows side is heavier (handle capture plus DeviceIoControl(FSCTL_GET_REPARSE_POINT) per candidate), but the principle is the same: validate once, keep the handle, refuse a reparse change observed after open. The PR that landed the fix also added a unit test that creates a reparse point mid-traversal under a debugger breakpoint and asserts the scan refuses to descend. That is the kind of test that earns its place by reproducing the failure it is supposed to prevent.

The non-reparse offline file (the stale classifier, gate 3 by association)

The third finding is closer to a stale classifier than a security boundary failure, but it is still P1 because the classifier decides what downstream code does with the result. prototypes/blue-windows/cloudstate/observe_windows.go:41-42 returns StateLocal whenever FILE_ATTRIBUTE_REPARSE_POINT is absent. The OFFLINE, RECALL_ON_OPEN, and RECALL_ON_DATA_ACCESS flags are examined later in classifyWindowsState at lines 73-74, which is unreachable for non-reparse files. A OneDrive file in the demoted state, a storage-tier-pinned file, or anything else marked offline without a reparse point will register as local. That is wrong, and the cost is that downstream criticality capture will under-count those files as low-risk.

The fix is to evaluate the offline/recall mask before the non-reparse StateLocal return. A non-reparse file with FILE_ATTRIBUTE_OFFLINE should classify as CLOUD_ONLY (or UNKNOWN/unavailable if we want to be conservative on recall flags we cannot yet test on every Windows SKU). The native probe needs a regression test for a non-reparse offline file. That is also shipping today.

Why not the obvious approach?

The obvious approach for standard-user state observation is to shell out to manage-bde -status and parse the text. That is what every PowerShell script in the wild does. It works on a privileged user. It fails open on a standard user: the binary runs, every operation returns "Access is denied," and the parser does not know that is "no data" rather than "BitLocker off." The classifier ends up reporting everything as off.

The other obvious approach is to elevate. manage-bde is the right tool for the privileged envelope. Elevation is not available here. DOC-075/A03 is explicit: the standard-user constraint is the envelope, not a temporary compromise. WMI stays out. COM stays out. The shape that fits inside the envelope is the bounded native provider, the observer contract, and the fixture-boundary authorization. They are less convenient than manage-bde. They are what works inside the envelope.

Adjacent finding on the NVMe health-log parser

The audit surfaced a separate bug in the NVMe health-log parser. The parser used wrong offsets: bytes 160-175 instead of 176-191. NVME_HEALTH_INFO_LOG places UnsafeShutdowns at 160-175 and MediaErrors at 176-191, and the parser was rejecting every byte from 216 onward (which is also where valid sensors 7 and 8 live). Fail-closed against false healthy in some cases but capable of false critical/unknown and missing the documented media-error blocker. Not a P1 for this epic, but it is the next bead.

Also shipped

Other repos did work today, briefly:

omarchy-plugins-bluegold-email-fix: closed FAQ panels 35 and 36, the adversarial buyer FAQ set. Buyer FAQ 36 is the version that survives a buyer who has already read the documentation.
intent-solutions-landing-bluegold-faq: shipped v3.2.0 with a mobile conversion baseline (PR #54). The site finally renders the conversion CTA cleanly on a 360-pixel viewport.
intent-demos: launched the proof-first demos catalog (fd6198e) and fixed site previews on touch screens (6dc710d).
contributing-clanker: closed regression-state isolation and review-synthetic-alert tolerance fixes (#78 and #79).
jeremylongshore-dot-github: bound VPS deploys to the caller revision (#5). Deploys now refuse to land if the action SHA does not match the commit being deployed.
omarchy-listening-post-entry: recorded approvals and bound deploy revisions (#19), launched the Perception product foundation (#18).
braves: a beads sync remote update only.

None of those are the day's center. The day's center is intent-blue-gold, the three gates, and the audit that caught two of them slipping before they shipped to production.

}}">Auditing Written Claims Against Their Artifacts: the second-review pattern across two unrelated domains. Today's Codex audit instantiates it on the BitLocker surface.
}}">Sealing a 168-bead planning graph took three reviews and a seven-seat council: planning under multi-review pressure, the day before.
}}">Adversarial review before team rollout: the adversarial pattern that the Codex audit instantiates on this surface.

Perception Is On the Way, on Its Own Domain

Jeremy Longshore — Sun, 13 Sep 2026 11:30:14 +0000

The day's pattern is the redirection. One Omarchy entry repo launched Perception's
web/API surface and shipped a customer preview page to perception.intentsolutions.io,
but the live deployment was a coming-soon page rather than the full paid product.
The smaller deployment was what the day's infrastructure could close. The same
shift showed up on a second repo, where a 1,262-line master blueprint commit and
17 documents filed into a flat chronological index paired with a 15-child Beads
decomposition that waits on itself by design. Two products, two repos, one shared
shape: ship the version the constraints can actually carry, and name the gap that
forced the smaller scope.

omarchy-listening-post-entry: Perception's web and API surface, then the customer preview

The repo shipped Perception in two commits on 2026-09-11. The first commit
(12ba7df feat: establish Perception web and API product, 00:17 -0600) was
46 files, 5,894 insertions: a new web/ Vite + React app, a new api/ Fastify
service with Dockerfile, and a packages/perception-contract/ shared schema
package that the web app and the API both depend on. The contract carries the
Perception v1 snapshot schema, with snapshot.id, snapshot.staleAfter,
snapshot.account, snapshot.topics, and a snapshot.signals array typed
to lane ∈ incident | release | pricing | engineering. The web app imports
the types directly from @listening-post/perception-contract; the API and the
contract tests share the same module.

The second commit (d992ce5 feat: prepare Perception customer preview,
17:15 -0600) was 102 files, 5,077 insertions and added the rest of the
customer-facing surface: a PublicExperience.tsx that owns the public marketing
site, four policy pages (privacy, terms, acceptable-use, support), a passwordless
auth flow with magic links via consumeMagicLink and requestMagicLink,
account views, customer-journey tests, and a mailer.ts plus customer-messages.ts
plus entitlements.ts plus billing-webhook.test.ts that gate access on Lemon
Squeezy subscription state. The schema gained a stricter signals shape (the
array now requires id, title, url, source, lane, relevance, resolved, quiet, matchedTopicIds, publishedAt, read per item with additionalProperties: false).
The manifest was updated to point perceptionEndpoint at
https://api.perception.intentsolutions.io and the web public/CNAME file
was written with perception.intentsolutions.io. PRODUCT.md, DESIGN.md,
VERIFICATION.md, SECURITY.md, and CHANGELOG.md were authored together.

That is the day's product surface. The live deploy is where the day's
reversal starts.

Why the live deploy is a coming-soon page

The original direction arrived as a single line near the end of the day's
session: "merge the prs commit push etc deploy the website i meed it online
i meed it online i give u commercial and legal approval." That authorization
covered the full paid-product release: the API at api.perception.intentsolutions.io,
the web app, the Lemon Squeezy checkout flow, and the policy pages as binding
production terms.

The agent surfaced four gaps before changing live traffic. GitHub Pages was
not enabled on the repo. The three PERCEPTION_* repository variables were
absent. The VPS deploy secrets were absent. The custom domains for both
perception.intentsolutions.io and api.perception.intentsolutions.io were
failing DNS resolution. PRODUCT.md was explicit that price, billing interval,
refund window, legal operator, governing law, and final checkout URL were
deployment-owned open decisions. The customer copy labelled itself "not yet
production terms."

The redirect that followed read, verbatim: "dude i just want perception.intentsolutions.io
to work as a site people click to know its on the way i posted it in discord."
That is the day's reversal. The full release was deferred, not failed: the
agent was told the goal had shrunk to a single page that says the product is
on its way and links to the GitHub repo.

GitHub Pages → VPS at intent-solutions

The smaller deployment still needed a live URL. The agent's first attempt was
GitHub Pages: a gh-pages branch with the standalone coming-soon HTML and a
Porkbun CNAME at 300s TTL. Pages was configured with Actions as its source,
PERCEPTION_DEMO_MODE=true was the only repo variable set, and the
checkout/API variables were deliberately left unset so the preview could not
masquerade as a paid production launch. DNS propagated. Pages started serving
the page over HTTP. The certificate did not arrive.

After the certificate stall, the agent switched to the VPS path that was
already under control. Caddy was healthy on the VPS, passwordless sudo was
available, and the same static page was served from there. The first Caddy
reload failed closed because the new access-log file did not yet exist with
Caddy ownership. The reload was isolated and retried after creating only
that log file with the service's established permissions. The second reload
succeeded. Porkbun was then asked to move the perception CNAME from GitHub
Pages to the VPS A record, with an automatic rollback path armed during the
cutover. Caddy issued the Let's Encrypt certificate on retry. The local DNS
resolver on the workstation had a stale negative cache for the new A record,
which the agent bypassed to confirm the public origin.

perception.intentsolutions.io now serves the coming-soon page over HTTPS
from the VPS. The full paid product remains local and un-pushed; the open
beads for price, billing interval, refund window, legal operator, governing
law, and final checkout URL still own those decisions.

intent-blue-gold: 17 Stage 0 documents plus an Epic 0 Beads decomposition

The second repo's day was a documentation discipline pass plus a Beads
decomposition. The first commit (d9cd691 docs: replace product summary with canonical MVP execution blueprint) added 1,262 insertions across a single
file, the master blueprint that owns the BLUE → GOLD → BLUE → WELCOME
sequence. The second commit (a23517b docs: file Stage 0 repository records)
filed 17 source documents (PRODUCT.md, V1-SCOPE.md, RISK-REGISTER.md,
THREAT-MODEL.md, MIGRATION-CONTRACT.md, COMPATIBILITY.md, RESEARCH.md,
AI-STRATEGY.md, DECISIONS.md, MASTER-BLUEPRINT.md, the docs/ subfolder
documents) into a flat chronological 000-docs/ tree using a global sequence
plus an AGENTS.md at root, a CODEX-HANDOFF.md update, and a
000-docs/000-INDEX.md that names the order.

The Beads side was harder. The first Beads init auto-adopted the unrelated
Intent Eval Dolt database (1,499 imported issues inherited from a remote the
agent had not selected). The first reset attempt succeeded technically but the
inherited graph was still present in the local Dolt history. The second reset
moved the .beads/ directory to /tmp/intent-blue-gold-beads-XQ7n2p/imported-beads
and /tmp/intent-blue-gold-beads-reset-xXV59D/imported-beads and started
with dolt.local-only: true and backup.enabled: false so no remote could be
adopted. The third init came up clean (zero issues, no Dolt remote, no
Intent Eval reference).

On the clean workspace the master blueprint was decomposed into five epics,
and Epic 0 (engineering foundation, CI/CD, repository quality gates) was
decomposed into 15 bounded Beads children using three Luna-high subagents.
The decomposition surfaced a cross-slice overlap (the CI orchestration bead
and the bootstrap bead both claimed the local command), which was narrowed so
CI consumes the bootstrap-owned gate rather than reimplementing it. The
final DAG has nine dependency waves with maximum parallelism of three, a
single onboarding/exit gate at the apex, and selective Epic 1 integration:
research and safety-analysis work remains runnable, schema/fixture hardening
waits for Epic 0 validators, experiment operationalization waits for workflow

destructive-test-isolation controls, and the controlled BLUE → GOLD → BLUE proof waits for the final Epic 0 exit gate.

The Beads config (dolt.local-only: true, backup.enabled: false, no remote)
was committed, the issue graph was validated with bd lint and bd dep cycles
(zero cycles, zero lint warnings), and the worktree was committed, pushed,
and merged to main as PR #1 with delete_branch_on_merge flipped from
false to true first via the GitHub repository API.

Also shipped

The comehomealabama journal (a separate Astro surface, not startaitools)
published ac9b179 post(journal): Orange Beach is three different decisions. Know which one you're making., automated by scripts/journal/mandy-land.sh
after the voice and fair-housing lints both passed. That post lives on the
Mandy machine and does not enter the startaitools archive.

What it cost

Two redirects, one certificate stall, one Caddy fail-closed reload, two
failed Beads resets, and a 1,262-insertion master blueprint rewrite that
became the canonical reference. The Perception web/API surface and the
Beads Epic 0 graph both landed in their final form on the first attempt
inside their own repositories. The deploy paths and the Beads remote selection
each needed a second try. The customer-facing launch is now bounded by what
HTTPS, Porkbun, and a Caddy file permission can carry, not by what the
product itself can carry.

The Same Mission on Two Surfaces in One Day, 2026-09-10's pair of initial scaffolds and the marketplace claim ledger pattern that precedes the Perception customer preview
A 953-Line Skill Entry Fits the Budget Again, 2026-09-09's split-and-pull-only refactor and the same-day 17-repo audit-harness refresh
Hardening a Marketplace in One Day, 2026-09-08's C44 installable-tree gate and the portable install integrity contract that ship next to the contributor workflow

The Primary Record Settles What a Derived One Assumed

Jeremy Longshore — Tue, 08 Sep 2026 11:30:14 +0000

A legal packet had already been corrected once. That is what made the day worth
writing down. The name on the drafts was wrong, somebody caught it, somebody
fixed it against the records we had, and the fixed version was still wrong. On
2026-09-06 the same shape showed up three more times, on systems that share no
code: a homepage publishing three different star counts, a ratified security
record, and a migration linter that counted an index build inside a log
message.

The common mechanism is boring and it costs a lot. A derived record is any
statement of fact produced from another statement of fact rather than from the
thing itself. Repo files describing an entity. An audit summarizing a record. A
grep counting SQL. Each one is cheap to read and confident by default, because
a derived record carries no expiry on its source unless someone builds one in.
Only a primary record settles it: the state filing, the GitHub API, the
governing section, the parsed statement.

The correction that was itself derived

The legal packet's entity name had been fixed once already, from repo records.
Those repo records had normalized the name at some earlier point, so the
correction inherited the normalization. Commit da39e57b says it plainly:

the audit had corrected the name once from repo records that had normalized
it; the primary record produced 2026-09-06 shows both earlier forms were wrong
and the state of formation was an assumption the drafts had baked into
governing law and forum.

The Certificate of Formation and the IRS EIN record arrived and closed two
standing assumptions as false. A-02, the name spelling: the registered entity is
IntentSolutions.io LLC. A-01, the state of formation: Delaware, file
10329498, formed 2025-09-11, registered agent Harvard Business Services.

The name was a find-and-replace. The state of formation cost more, because it
had never been written down as a fact anywhere. It was an assumption, and it had
already propagated into meaning, since the governing-law and forum clauses of
the contract templates were built on top of it. A wrong string is a lint. A
wrong premise underneath a clause is a different category of problem, and no
amount of internal review would have surfaced it, because every document in the
packet agreed with every other document in the packet.

Enforcement shipped with the correction, and the shape of the enforcement
matters more than the value it now accepts. The validator does not check that
the entity string looks plausible. It rejects the two specific forms we now know
are retired:

$ ci/validate-legal-packet.sh --selftest
[selftest] accepts: IntentSolutions.io LLC ....................... ok
[selftest] rejects: retired form A (pre-normalization) ........... ok
[selftest] rejects: retired form B (repo-normalized) ............. ok
[selftest] 3/3 passed

$ ci/validate-legal-packet.sh
entity string: IntentSolutions.io LLC (43 files checked)
exit 0

The retired forms are not printed here for the same reason the selftest labels
them A and B: repeating a wrong name in public copy is how it gets re-derived.
Formation screenshots live outside the repo. The EIN, street address, and phone
never enter it.

Formation state and governing law are separate questions

The obvious move, once the formation state lands, is to sweep governing law and
forum to Delaware and be done. We did the opposite. Alabama law and Baldwin
County stay in the drafts, flagged as open counsel question C-14.

Formation state and choice of governing law are different questions that happen
to share a word. The business operates in Alabama, the founder is in Alabama,
and the restrictive-covenant analysis (the clause set that actually bites in a
dispute) is an Alabama-law question. Switching the contracts to Delaware because
the certificate says Delaware would be a second derived conclusion stacked on
the first one, produced by exactly the reasoning that caused the original
problem: an inference from a nearby fact, written down with the confidence of a
finding.

The correct output of a primary-record check is a smaller set of facts and a
larger set of explicit questions. C-14 is a question with a name and an owner.
It is unresolved, and it is no longer silently assumed, which is where it sat
yesterday.

Three star counts, none of them from GitHub

Track two is the company homepage. The 451-line audit of the live
intentsolutions.io found it publishing three contradictory star counts for the
same repository, two of them above the verified figure. None of the three was
read from GitHub. Each was typed into a component from whatever earlier copy
the author had in front of them, and each component agreed with itself, so
every review the page had passed was
a review of derived numbers against other derived numbers. The same audit found a hero leading with retired Google
infrastructure, five service lines, a booking calendar, and a contact form
posting to an unrouted path.

PR #49 shipped v3.0.0 as the fix: a static Astro rebuild derived from a written
gateway brief, with React and the animation libraries removed, and 17 routes,
30 dead components, 12.5 MB of unreferenced media, and 20 runtime dependencies
deleted. The part that answers the thesis is smaller than the rebuild. Every
figure on the page rendered from src/data/receipts.json, which
scripts/refresh-receipts.mjs writes from GitHub, tonsofskills.com, skills.sh,
the Lab results page, and the field-notes RSS. Each value carries a
verified_at. CI refreshes the file before deploy and fails the build when a
value goes stale:

const MAX_AGE_DAYS = 7;
for (const [key, r] of Object.entries(receipts)) {
  const ageDays = (Date.now() - Date.parse(r.verified_at)) / 86400000;
  if (ageDays > MAX_AGE_DAYS) {
    fail(`${key} verified_at is ${ageDays.toFixed(1)}d old (max ${MAX_AGE_DAYS})`);
  }
}

A count with a verified_at is still a derived record. The difference is that
it now expires, and the build knows the expiry. A second gate,
scripts/check-copy.mjs, failed on retired strings, dollar figures, dashes, and
hand-typed counts, so while it was live the old failure could not be typed back
in.

PR #51 reverted the whole rebuild the same day. The owner's call, verbatim:
"roll back to original please." The zinc theme, the React islands, all 29
routes, the media, the dependencies, and the pre-rebuild CLAUDE.md all came
back, with one merge conflict in the auto-generated CHANGELOG. We took a clean
revert over a partial keep so main matches the last known live state exactly; a
partial keep produces a fourth thing that was never live and never reviewed as
a whole. The audit doc stayed on main, because a revert only removes what the
reverted PR added, and the audit was independently true.

This instance is a variant of the other three, and it is worth saying so. The
brief was executed faithfully. What the revert corrected was not a false fact
but a direction, and the only primary record for the direction is the owner.
The second attempt did not guess at copy again. It put the live page in front
of eight independent reader seats in one Workflow, with a ninth seat for
synthesis, and filed the result as a 455-line review. The verdict was 8 of 8
that the page does not represent the vision and that the fix is mostly
subtraction. The headline vote split 6 to 2, and the merged recommendation
ships both lines, the majority as H1 and the challenger in the eyebrow slot,
because a 6/2 split and an 8/0 agreement are different facts about the copy
and a single recommendation erases the difference. The synthesis escalated two
items to the owner instead of resolving them, one being that several seats had
written founder-biography detail into public copy against a standing
instruction. A panel of readers is another derived record. The escalation is
the step that reached primary.

A ratified record whose "no bead owed" was false

Track three ran on intent-longbox. Seven PRs on multi-tenant isolation
merged the same day (#95 through #101: compound tenant keys, row-level security
as a contracting shape, a single identity door, store-domain claims, membership
policies, self-service second factor, webhook replay defense), and records 060
through 065 were ratified. The compound key from #95 carries its whole
isolation argument in the three lines before the close:

CREATE TABLE scan_result (
  id          uuid NOT NULL,
  shop_id     uuid NOT NULL REFERENCES shop(id),
  session_id  uuid NOT NULL,
  PRIMARY KEY (id, shop_id),
  FOREIGN KEY (session_id, shop_id)
    REFERENCES scan_session (id, shop_id) ON DELETE CASCADE
);

The tenant travels in the composite key, so a foreign key check cannot resolve against
another shop's row even when the application forgets its predicate.

Then the gate audit read record 065 and found its ground false. The record
claimed no follow-up work was owed. The remaining cross-tenant edges were not
actually exempt under record 062 section 4, which is the section the claim
leaned on. Two beads were filed as a result, E03-D37 and E03-D38. D37 then moved
from P3 to P2 because two of the remaining single-column tenant edges were
reproduced as exploitable on head: a device credential revocation planted across
shops, and a global UNIQUE on credential retirement evaluated with row-level
security off.

A ratified record is a derived record. Record 062 section 4 sits closer to
primary, and reading it directly is what broke the claim.

The linter that counted a sentence

The best small instance of the day came from the Postgres migration lint written to
enforce the 044 index-lock rule. That rule caps how many index builds a single
migration may take a heavy lock for. The lint counted index builds with a text
grep, which meant it counted this:

-- migration 039, inside a DO block
DO $$
BEGIN
  RAISE NOTICE 'rebuilding: CREATE INDEX on inventory_item may take minutes';
END $$;

A string literal inside a log message. The grep read it as a sixth index build
and failed the migration. A count of SQL objects was being derived from prose
about SQL objects, inside the same file.

Invariant review caught it before the lint shipped, and the note went on the
bead so the name-collision lint being added next would avoid inheriting the same
false positive. That bead then absorbed a second rule: DROP CONSTRAINT on a
live table takes the same lock declaration the CREATE INDEX rule already
demands. Migration 039's eleven ACCESS EXCLUSIVE locks come from DROP CONSTRAINT, and 044 section 9 never reached that statement.

What it cost

One failure that day was a different shape, a rule you can step around rather
than a wrong fact, and it belongs in the record. One commit went in with
--no-verify after four attempts to get the pre-commit hook's unit chain to
finish under a load average above 40. The change was .beads/issues.jsonl
only, which no pre-commit stage tests, so the risk on that commit was near
zero. The hole in the discipline is real anyway. A gate you can step around
under load will be stepped around again, and the honest fix is making the hook
cheap enough to always run.

The day ran 6 project-days across 21.75 hours of wall span, with 25
failure-to-fix moments and 7 course-corrections in the session digest. The
intent-longbox chain ran on Claude Fable 5.1 across 9 sessions and 967
minutes, with 48 agent dispatches and 35 resumes. That ratio describes the work
better than the turn count does: most of it was dispatching a reviewer and
later resuming it for a verdict. The gate audit that refuted record 065 is one
of those 48. The claude-code-plugins thread ran on GPT-5.6 Sol via Codex, and
every one of its five course-corrections was a containment instruction ("read
only: do not edit, push, comment, merge, close") or a demand for a verdict from
evidence already gathered. None corrected a wrong answer. The legal thread ran
on Claude Fable 5.1 across 6 sessions and 1306 minutes, and included one agent
run interrupted mid-flight because I was messaging counsel on LinkedIn in real
time and needed a specific message sent right then.

Change what the checker keys on

When a checker is wrong, fixing the value is half the job. Change what the
checker keys on.

The legal validator stopped accepting whatever string the repo files agreed on
and started rejecting two named retired forms. The receipts gate stopped
trusting a committed number and started failing on verified_at age; it went
out with the revert and is the first thing the second attempt brings back. The
migration lint is being moved off text grep onto parsed statements; that one is
filed on a bead, not shipped. And the site copy stopped being resolved inside
the panel and started being escalated to the owner, with the dissent preserved
on the way up.

Every one of those is the same move: take the authority away from the derived
artifact and give it to something closer to the thing.

Also shipped

intent-os document filing. business-plan/gateway/ moved into 000-docs/163-PP-gateway-vision/ (files 164 to 171) and legal/ into 000-docs/172-BL-legal-packet/ (files 173 to 214). Two clusters instead of one nested folder, because the standard forbids folders within folders. Every cross-reference, lint ignore, repo index, CLAUDE.md, README, and partner-network cockpit pointer was repointed, and source-form sha256 values were verified identical before and after the rename before regenerating the manifest. The validator got the same treatment as everything above: re-rooted at the cluster and keyed by category codes instead of positional filenames, since file position is a derived property that any rename breaks.
Five Reddit introduction posts for r/ClaudeAI, r/SideProject, r/vibecoding, r/startups, and r/Entrepreneur, value-first, with posting rules (one account, home connection, comment before posting, and links omitted where the sub forbids them). Five distinct story posts rather than one generic post copied five times, because identical cross-posting is what gets flagged.
Legal drafts alongside the entity correction: a two-member member-managed Delaware operating agreement, a customer-facing security statement claiming no certifications because we hold none, and a beads epic (spine-0ce) with seven children, one per purchase, filing, or decision only the owner can execute.
omarchy-omatrail-entry, a frontier survival game in QML and JavaScript, over 3,000 lines of rules and views, plus bin/omatrail-state, an end-to-end harness with save fixtures, and an evidence/render-matrix carrying per-scene PNGs next to render-proof JSON. A nine-document design workbook landed alongside it in omarchy.

FAQ

Why does a text grep fail at counting SQL objects?

A grep counts text, not statements. The Postgres migration lint on 2026-09-06
searched for CREATE INDEX and matched a RAISE NOTICE message that described an
index build in prose. It counted that sentence as a sixth index build and
failed the migration. The fix that is filed, and not yet shipped, is to parse
the statements instead of searching for words about them.

What is the difference between a primary record and a derived record?

A primary record is the thing itself: the state filing, the GitHub API, the
governing section of a ratified record, the parsed SQL statement. A derived
record is any statement of fact produced from another statement of fact rather
than from the thing. Repo files describing an entity, an audit summarizing a
record, a grep counting SQL. A derived record carries no expiry on its source
unless someone builds one in.

How do I stop a checker from re-deriving the same wrong answer?

Change what the checker keys on. The legal validator stopped accepting whatever
string the repo files agreed on and started rejecting two named retired forms.
The receipts gate keyed on verified_at age instead of a committed number
while it was live, and it comes back with the second attempt. The migration
lint is being moved from text grep to parsed statements. Each move takes
authority away from the derived artifact and gives it to something closer to
the thing.

{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "Why does a text grep fail at counting SQL objects?",
"acceptedAnswer": {
"@type": "Answer",
"text": "A grep counts text, not statements. The Postgres migration lint on 2026-09-06 searched for CREATE INDEX and matched a RAISE NOTICE message that described an index build in prose. It counted that sentence as a sixth index build and failed the migration. The fix that is filed, and not yet shipped, is to parse the statements instead of searching for words about them."
}
},
{
"@type": "Question",
"name": "What is the difference between a primary record and a derived record?",
"acceptedAnswer": {
"@type": "Answer",
"text": "A primary record is the thing itself: the state filing, the GitHub API, the governing section of a ratified record, the parsed SQL statement. A derived record is any statement of fact produced from another statement of fact rather than from the thing. Repo files describing an entity, an audit summarizing a record, a grep counting SQL. A derived record carries no expiry on its source unless someone builds one in."
}
},
{
"@type": "Question",
"name": "How do I stop a checker from re-deriving the same wrong answer?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Change what the checker keys on. The legal validator stopped accepting whatever string the repo files agreed on and started rejecting two named retired forms. The receipts gate keyed on verified_at age instead of a committed number while it was live, and it comes back with the second attempt. The migration lint is being moved from text grep to parsed statements. Each move takes authority away from the derived artifact and gives it to something closer to the thing."
}
}
]
}

Auditing Written Claims Against Their Artifacts

Jeremy Longshore — Mon, 07 Sep 2026 11:30:11 +0000

Code review asks whether the decision was correct. It almost never asks whether
the paragraph describing the decision is accurate. On 2026-09-05 I watched that
gap open in two places with nothing in common, neither language nor reviewer: a
multi-tenant SaaS built under a heavy evidence discipline, and a stack of
contract drafts with no software in them at all. The two records had reached
different stages. The intent-longbox records had been through a dispatched review and
in some cases a ratification. The legal packet had passed only its author, who
committed it as a finished deliverable with [COUNSEL:] markers still in the
text. Both were carrying claims that were false.

Roughly twenty statements of fact got repaired across that one day. Nine in one
commit, eight in another, one security claim withdrawn after a reviewer measured
it false, and one use of the word "proved" downgraded to the rung its evidence
actually reached. The count runs per false claim rather than per place it was
written, so the withdrawn security claim counts once even though several sites in
the record carried it, and the downgrade counts once across two register rows. Every one of those records had already been read by a
reviewer, and in two cases had already been ratified.

The thesis I came out with: a review that only checks decisions leaves the
prose ungated, and the prose is what everyone downstream cites.

Two review lanes, and only one of them reads sentences

The intent-longbox repo runs work through what I call the two-lens cannon. Two
named reviewer agents take a change from different value systems, currently
security-auditor and martin-kleppmann-reviewer, and each returns a verdict.
Alongside them sit two narrower jobs: a gate auditor, whose mandate is the
record rather than the code, and an invariant reviewer, which checks that the
system's stated invariants still hold. On some changes a MiniMax adversarial
review runs on top of that.

The day's volume was real. On main, 2026-09-05 changed 191 files, 42,385 lines
added and 1,433 deleted, across 33 commits and seven merged pull requests (#88
to #94). The features were substantial on
their own. The seven merged that day:

PR	Diff	What landed
#90	+11645/-865	PostgreSQL row-level security with transaction-local tenant context, plus property tests
#94	+9916/-330	The first factor and the privileged-session shape
#92	+8981/-81	A Longbox-origin predicate so a staff session outside a break-glass grant is visible
#88	+9557/-86	Least-privilege organization and location RBAC, trustworthy actor audit
#93	+663/-23	N:1 authorization decisions under an idempotent replay, refusing the dedup key
#89	+543/-158	`noPropertyAccessFromIndexSignature` turned on
#91	+1223/-109	The causal reference persisted on two tables

Two more pieces the day leaned on had merged the night before: TOTP and recovery
codes for owner and support roles in #82, and connector OAuth with least scopes
and uninstall revocation in #87.

None of those features is the story. The story is the five commits that followed
them, each one repairing a written record that the first review had already
cleared.

Nine fact repairs from one gate audit

Commit 2173407 carries the plainest version of the split, and it took two
lanes to get there. The gate auditor returned NOT-READY. Every decision item in
the record passed. Six statements of fact did not. The invariant reviewer, run
against the same head, returned PASS-WITH-NOTES and found three more.

gate audit verdict:        NOT-READY
  decision items:          all verified as recorded
  fact repairs:            6
  scope:                   paperwork only, no ruling moved

invariant re-verification: PASS-WITH-NOTES
  further fact repairs:    3

Read that verdict twice. The engineering was right. The document describing the
engineering could not be cited. The six repairs:

A test file held 21 cases, and the record said 18. That pushed the bead's unit total from 34 to 37, and two separate registers were carrying 34.
Three beads described as "proposed, not yet created" already existed. The session had filed them while the branch was in flight, so every "proposed" hedge got replaced with a real id.
A section asserted an act that had not happened. The phrase "is corrected accordingly" was false at the moment someone typed it, because nothing had done the correcting. It is true now by a different route, with the who and the when named.
A residual finding, R9, had no owning bead. A residual nobody owns is a residual nobody reads twice.
A citation of the three-layers quote pointed at 034:447 when the quote sits at 034:449. The repair also named 034:445-447 separately, which is the K1 trigger, a different quote entirely.
A register cell claimed a status its evidence did not support, reading VERIFIED by execution across both halves when only the refusing half had been run.

citation repair, three-layers quote
  before: 034:447
  after:  034:449

cited separately by the same repair
  034:445-447   (the K1 trigger)

That fifth one looks like a typo and is not. A line-number citation is a promise
that a reader who follows it lands on the sentence being quoted. Land two lines
short and the reader meets a different claim, then either loses trust in the
record or keeps reading and inherits the wrong quote. The commit describes the
gap as one line; the diff shows two. I have left both readings visible rather
than picking the tidier one.

The three the invariant lane found

The gate auditor reads the record against its own citations. The invariant
reviewer reads the record against the running system, which is why the three it
turned up are heavier.

Section 6.3 of the record claimed there was nothing to repair. That was false by
exactly one. A UNIQUE index on shop.shopify_domain, added by migration 026 back
when shop carried no policy, is precisely the shape section 6.3 warns about,
and the bead inherited it the moment it policied shop. Reproduced under shop
B's tenant context, claiming a domain that shop A already holds returns 23505,
and claiming an unused one returns UPDATE 1. Two different answers, decided by a
row the caller is not allowed to see. That is a one-bit oracle on which Shopify
stores are Longbox customers. It is latent today because no route writes
shopify_domain, and latent is a schedule rather than a verdict. Section 6.3 now
names it and routes it to an existing bead's class instead of inventing a new
rule for it.

The second was a new residual, R10. The domain-claim check in receiveCallback
has a TOCTOU window: the SELECT runs in one scope and the write runs in a
separate transaction under the shop's tenant context, so two concurrent installs
of the same store can both pass the check. The commit named the window and took
neither of the two obvious fixes. Moving the check inside the transaction puts
it under a tenant context where other shops' rows are invisible, so it would
fail open, which is worse than the bug. Running the whole install in the service
scope needs exactly the policy widening the security lens had just punished. The
durable fix is the serialization point the database already owns, which is the
unique index above, so the residual sits and waits for the bead that covers it.

The third repair is the one I would put in front of anyone who thinks this lane
is pedantry. A register cell's reproduction command named a GUC that does not
exist. longbox.service_scope names the SQL function, while the setting itself is
called longbox.service. Run verbatim, the cell returned zero rows.

in the record:  current_setting('longbox.service_scope')   ->  0 rows
the real GUC:   current_setting('longbox.service')

The commit called it the worst kind of evidence, because it looks checkable and
appears to disprove the claim it supports. A reader who runs it sees an empty
result and concludes the invariant is broken. A reader who does not run it
carries a citation that has never worked. The cell now reproduces standalone.

Six plus three is the nine. The commit message carries a line I have kept: a
record whose decisions are right and whose facts are wrong is still a record
that cannot be cited. The same shape showed up earlier this year in Every Verdict Carries the Scope It Actually Ran, where a green result was reporting on less than it claimed.

Eight statements, and two ratified records a rebase damaged

Commit af3aa84 came out of the next gate re-audit. Same shape of verdict:
NOT-READY on paperwork only, every ruling verified as recorded and built,
nothing moved a decision. Eight repairs this time, and two of them were damage
rather than drift.

The first piece of damage was in an append log. A rebase reconciliation filter
had silently dropped a ratified entry belonging to a different branch, because
that row's own text happened to mention the current branch's bead id. The filter
matched on a substring and took a stranger's row with it. An append log that
loses an entry has stopped being an append log.

The repair restored the row verbatim from origin/main and showed the
restoration accounted for by a set diff rather than by an eyeball:

git show origin/main:000-docs/016-OD-REGS-longbox-source-register.md > /tmp/main-appends
# extract entry ids from both sides, compare as sets
# result: all 32 of main's appends present and accounted for on the branch

Restoring the text is the easy half. Showing that nothing else went missing in
the same filter pass is the half that makes the record citable again, and a set
diff is the cheapest instrument that does it.

The second piece of damage was subtler. A ratified record's table cell had been
edited in place instead of appended to. The amendment was correct. Its form was
illegal. In a record with a version and a ratification date, an in-place edit
rewrites what a reader who cited the earlier version thought they were citing.
The repair restored main's sentence verbatim and appended the new pin after it.
The record's version number did not move, because the amendment is the same
amendment; only its shape changed.

Six of the other repairs in that commit:

A heading cited a stale commit while the section above it had already been corrected to a newer one.
A section called a commit "the main this branch is rebased onto" when it was the merge base, and main was a different commit.
Two sections routed a decision row to a bead as OPEN when the bead was CLOSED. The fix restated it as a closed ruling rather than deleting the row, so a reader who met the property in the earlier version is not left hunting a fix that is never coming.
A claim of "all twelve invariants proved against a database" was really eleven of fourteen. The record had counted twelve invariants; the real total is fourteen, of which eleven carry database evidence. One of the remaining three is an architecture gate and two are unit-level, so the word "all" was claiming database evidence that three invariants do not have.
"Gains five cases" was seven.
Every duration quoted as a measured property (24 hours, 15 minutes, 30 days) was relabeled a provisional constant.

That last one is the one I would defend hardest. The real argument in that
section is that each act outlives the session that created it, and that argument
holds whatever the constants are. Quoting the numbers as durations stated a
property nobody had measured, and it invited a future reader to treat a config
value as a finding.

The claim a reviewer measured false

Commit 177cd3d is the centerpiece, because a reviewer did not argue about
wording. It ran the thing.

The record claimed that a tighter per-identifier sign-in rate bucket "closes" a
user-enumeration timing oracle, and that a known address and an unknown address
"start refusing fast at the same attempt count". The reviewer measured minute
two, the first minute after the bucket refills, which is exactly when a warmed
known address falls out of it. The result:

warmed KNOWN address:     6 to 16 ms on 4 of 5 attempts
UNKNOWN address:          about 600 ms on 5 of 5 attempts

An attacker with a stopwatch can read that difference through any amount of
network jitter. The claim was false.

The root cause was a window mismatch nobody had costed:

per-identifier sign-in rate bucket:  refills every 1 minute
LOCKOUT_WINDOW_MS:                   15 minutes

A warmed known address drops out of the one-minute bucket and falls back onto
its fifteen-minute lockout path roughly fourteen times an hour, and every time
it does, it answers cheap. What the tighter bucket actually bought was a rate
cut on the oracle, from roughly 120 observations a minute down to roughly 5. A
rate cut is a real security improvement. It is a different improvement from the
one the record advertised.

One section of that record, R10, had said this correctly the whole time:
"narrows the window rather than closing the class". Six other sites in the
record and the source contradicted it, or eight, depending on which part of the
commit you read: it counts six and its own list names eight. All of them were
corrected to match the one
that was right, which is a satisfying shape for a repair: the truth was already
in the building, outnumbered.

Adding nothing was the right call

No fix shipped with that correction, and the decision was deliberate.

Closing the class means hashing while blocked, so that a refused known address
pays the same CPU as an unknown one. A ratified document in this system refuses
that, and the bead doing the correction has no mandate to reopen it.

The alternative that lost was widening the lockout window to match the bucket.
That is a two-line change and it would have made the two paths agree. It also
changes another ratified document's delay from inside a bead that never argued
for touching it. Buying an accurate sentence by quietly editing somebody else's
ratified constant is a worse trade than living with a narrowed residual.

So what stands is a narrowed residual with its own row in the register. Someone
will pick that row up with a mandate that covers it.

There was a bookkeeping consequence too. Two claim ids, C47 and C48, collided:
another bead's C47 and C48 had landed on main in parallel, so the register
briefly carried four rows under two ids. The ratified ids kept their numbers,
this branch's renumbered to C49 and C50, and the renumbering went into an append
rather than happening quietly. A claim id that moves without a note is a
citation nobody can follow backwards.

Downgrading "proved" to the rung the artifact reached

Commit 2e7f3d2 came from a MiniMax adversarial review that pressed on a single
word in two register rows. It was written the night before and landed on main in
the first hour of the 5th, through PR #89. Both rows said a compiler-flag-flip result was "proved able to fail",
while linking only to CI runs where the flag was on.

That is a structural argument that flipping the flag would produce the outcome.
The record presented it as a recording of an actual flip. The governing rule in this repo is
narrow and useful: a claim may not use a stronger rung than the artifact it
cites.

What the CI runs actually prove is that the flag is set in the repository's
config, and that the dot access is what the compiler refuses, since a bracket
twin compiles right beside it. They do not prove that the flag is the reason.
Establishing that requires flipping it, which is a local reproduction, so it got
recorded as one, with the command that produces it:

sed -i 's/"noPropertyAccessFromIndexSignature": true/"noPropertyAccessFromIndexSignature": false/' tsconfig.json
pnpm vitest run tests/contract/signature-fields-are-not-dot-accessed.test.ts
# 2 failed | 4 passed

I re-ran that at the commit rather than quoting the earlier session's output,
which matters more than it sounds: a number copied forward from a previous
session is a claim about a commit nobody checked. The two that fail are
is set in the repository's tsconfig (12 ms) and refuses fields.series in src/services with TS4111 (13.68 s). tsconfig.json was restored afterwards,
which is why it is absent from the diff.

The seventh CI case that lost

The obvious response is to add a seventh CI case that does the flip
automatically. I turned it down for three reasons, and the third one decided it.

A CI version has to either mutate the repository's own tsconfig.json, which is
the same hazard another bead forbids one level up for src/, and this time on
the file every other test is judged by; or compile against a modified copy of
the config, which is exactly what an existing case named compiles the scratch tree against the repository's own tsconfig exists to rule out. Both options
undo a guarantee that is already paid for.

The third reason is cost. It would add a fourth tsc spawn to a test file the
same reviewer had already flagged as the second slowest in the unit lane. A
written command a reader can re-run in thirty seconds beats a permanent tax on
every run for the same evidence.

The reviewer got audited back

The same MiniMax review produced a finding I declined, and the arithmetic is
worth showing because it is the honest half of this whole approach.

It called a per-directory split HIGH severity, on the grounds that
"65 + 9 + 63 = 77, which is 60 short of 137".

python3 -c 'print(65+9+63)'
137

The split reconciles exactly. The row stands as written. An adversarial reviewer
is a model pointed at the work with a narrow mandate, and it is fallible in
exactly the way everything else in the loop is fallible. The layer only earns
its keep if its findings go through the same evidence test the work does. Every
finding it raised that day got checked; one of them did not survive.

The review that was drafted instead of dispatched

Commit 91cd7c5, which landed in PR #94, fixed the worst process defect of the day, and it is the one I
would have caught last if the gate auditor had not been looking.

A record had shipped at v1.0.0 with a section containing two lens positions that
the builder had written himself. The cannon was never dispatched. Somebody wrote
what a reviewer might plausibly say instead of asking the reviewer. A draft of
what a reviewer might say is not a review, and the record had been carrying it
as one.

When the real cannon ran, both lenses returned ACCEPT-WITH-CHANGES, the gate
auditor returned NOT-READY on facts, and the invariant reviewer returned
PASS-WITH-NOTES. Two of the findings were enforcement rather than prose, so the
record went to a minor version instead of a patch, because v1.0.0 had been wrong
about two things rather than merely silent on them.

Three real behavior changes fell out of that dispatch.

A privileged sign-in now revokes the person's other live privileged chains at
that shop. A session expiry bounds the session, and it does not bound the acts
the session performed. Using the provisional constants as they stand today, a
copied cookie mints a 24-hour invitation and a 15-minute enrollment code, and it
leaves a permanent owner membership and a 30-day device credential standing
after the session dies. Eviction is now an act
the owner can perform. It is scoped to the same shop rather than sweeping a
person globally, because the wider version would unilaterally widen another
record's cross-tenant scope union from inside a bead that never argued for it.

Naming a second owner on an invitation now re-presents the second factor in
the request, and refuses without it. Of every act in that flow, this is the one
whose damage no expiry bounds: a second owner outlives every session, every
token, and every device. It was extracted into its own transaction rather than
folded into the existing call, so the lock-order lint reads the two anchors
truthfully instead of being dodged by a merge.

The sign-in path took its own provisional per-identifier rate constant instead
of borrowing the device class constant. The measurement that forced it:

same-class refusals, sign-in path:   5.7 ms
device-class refusals:               449 ms

Constant in the body and not on the clock. On an anonymous internet-facing
route, that is an enumeration oracle for who works at which shop.

The same failure outside software

The second instance came out of intent-os, in commit 03e22943: an
independent adversarial audit of the partner-network legal packet. Six read-only
streams plus eighteen scenarios, 177 findings, 25 root-cause groups.

The v0.1 packet it audited had been drafted the same day, six and a half hours
earlier, at commit bedc4d4e (14:30 to 21:02). No reviewer had touched it. The
[COUNSEL:] markers in its own text say as much, and no legal/review/
directory existed until the audit commit created one. It had passed its author
and been committed as a finished deliverable, which is a weaker gate than the
Longbox records cleared and a more common one.

What the second pass found:

Every document named the wrong legal entity.
A signature block was pre-filled with a non-office title, for a 50/50 LLC with no signing authority on file.
A flow-down was promised with no artifact behind it, and the packet contradicted itself on precedence.
Liability caps were left blank in a way that reads as an absence of any cap.
The packet contradicted the firm's own doctrine on classification.
The practitioner layer carried nothing on security, data, AI, or open source.
It was about to be signed by a person in Germany, on a contractor form scoped to US individuals only.

Every one of those is a false or missing statement of fact in a document that
was already being treated as done. There is no compiler anywhere near it, and there is
no test suite either. The failure mode transferred cleanly anyway.

The remediation is the part I would reuse. Every executable draft got a
canonical banner at the top and above every signature row: DRAFT, ATTORNEY
REVIEW REQUIRED, NOT APPROVED FOR SIGNATURE OR USE. Signer and title were left
blank pending an open decision. The contractor form was renamed from "member" to
"practitioner", restructured as a master agreement plus Work Orders, and held to
US individuals only.

The discipline that makes that audit trustworthy is what it refused to do. Every
legal judgment was registered as an open decision (D-01 through D-22) or a
counsel question (C-01 through C-28) rather than being decided. The audit's
authority stops where counsel's begins, and an audit that quietly rules on a
question it has no standing to rule on has become the thing it was checking.

It also shipped an enforcement script:

ci/validate-legal-packet.sh     # 12 checks
pnpm run validate:legal-packet  # wired into CI

Twelve checks, plus a planted-fixture self-test: every check has to be shown to
fire against a deliberately broken fixture before it counts. A check that has
never failed is a check nobody has tested.

Source integrity was handled the same way. The files under legal/sources/ were
hash-matched against a manifest recorded before any edit, and 14 of 14 matched.

Two facts were explicitly marked provisional and not verified in that session:
the Alabama statutory texts, because Justia returned 403 and the legislature
site was unresolvable; and the Secretary of State record, because it sits behind
an interactive form. Marking a fact as not verified, by name, with the reason,
is the same discipline as the rest of the day pointed inward. The alternative is
a packet where verified and assumed look identical to the next reader.

What the second lane cost

Numbers first, because this approach is not free and the bill should be visible.

Measure, 2026-09-05	What the first review produced	What the second lane added
Statements of fact repaired	0	about 20
Rulings changed by the repairs	0	0
Security claims withdrawn as measured false	0	1
Evidence rungs downgraded	0	1
Ratified records restored after rebase damage	0	2
Reviewer findings declined on arithmetic	0	1

The zero in the second row is the interesting one. Not one repair moved a
decision. Every ruling the first review cleared survived the second review
intact. The code was right the whole time, and the record describing it was
wrong in about twenty places.

The other number, 42,385 lines added, deserves an honest reading too. A large fraction of
that day's diff is records about records: registers, appends, gate audits,
residual rows, claim ids. That is the cost line.

Tradeoffs

This is expensive, and the expense is mostly wall-clock. Every one of those
four repair commits came after the feature work was already merged-quality. The
gate auditor, the invariant reviewer, the two lenses, and the adversarial pass
each add a round trip, and each audit cycle can come back NOT-READY on paperwork
that changes no behavior. A team optimizing for cycle time will hate this and
will be right to.

The audit trail is load-bearing, which means it is also a liability. Append
logs, ratified records, claim ids, and version pins only work if nothing edits
them in place. Two of the day's repairs exist because a routine rebase damaged
records nobody was watching. The heavier the paper trail, the more surface a
mechanical operation has to corrupt, and rebases do not read your conventions.

Fabricating a review is a live failure mode. Commit 91cd7c5 exists because
somebody drafted the two lens positions instead of dispatching the cannon, and
that got all the way to v1.0.0. A process with a named review step invites
someone to satisfy the step's shape without paying its cost. The only defense I
have found is a separate auditor whose mandate includes checking that the review
happened at all.

The adversarial layer is itself unreliable. The same MiniMax review that
produced the best correction of the day also produced a HIGH-severity finding
built on 65 + 9 + 63 = 77. If you take these findings on authority you will
degrade your record instead of improving it. Every finding has to be checked,
which means the second lane needs a third posture: audit the auditor.

The scope where this pays is narrow. If nobody outside the session that wrote a
record ever cites it, the second lane buys nothing. The value shows up once a
claim in a document becomes an input to a later decision, a partner
conversation, a security posture, or a signature. Most weekend projects have no
record with that property. A multi-tenant system holding other people's data
does, and so does a stack of contracts about to be signed.

Where a claims audit sits in wider practice

The idea is not new anywhere except in how it gets applied to AI-generated work.
The analogy I keep reaching for is accounting reconciliation, where the entry
and the check on the entry are deliberately different jobs. I have no artifact
that says other fields adopted the split for the reason I am describing, so take
that as a shape I find useful rather than as evidence from the day.

Software collapsed those into one step called code review, and it mostly worked
while humans wrote both the code and the paragraph describing it, because the
person typing the paragraph had just done the work and remembered the details.

That property weakens when an agent writes the paragraph. Agents produce fluent,
plausible, well-structured prose about work at a rate no human reviewer reads
carefully, and the failure mode is specific: the sentence is shaped exactly like
a true sentence. "All twelve invariants proved against a database" reads
identically to the accurate version. Only a pass that opens the artifact and
counts can tell them apart.

The rung rule generalizes better than anything else I took from the day. Every
claim sits at a rung: argued, implied, observed, measured, proved. Every artifact
supports some rung. Enforcing that the claim never outranks its artifact is a
mechanical check a reviewer can perform without domain expertise, and it caught
both the "proved" downgrade and the oracle withdrawal.

Also shipped

intent-os also carried a second track that day, ten commits of an eleven-commit
day. A gateway
business-plan vision cluster was filed at v0.1 verbatim with five gap beads,
advanced to v0.2 (dbd3cd9f, 8cccfbe0), then put through a council review (ac07d920): 13 thinker-canon seats plus
an SI practice partner and a hyperscaler partner-program director, over five
adversarially re-verified research packets, with dissent preserved and nine
follow-on beads opened. The recorded rationale for the shape was that a workflow
of 26 agents beat a single synthesis pass, because the seats had to argue
independently before any dissent existed to preserve.

intent-solutions-landing took one field-notes content commit.
claude-code-plugins took seven commits on main: three dependency chores, a
marketplace-sync fix for Windows, two plugin feature commits, and the
dual-publish of the field note.

Frequently asked questions

Can code review find false claims in the documentation?

Code review checks whether the decisions are right. It almost never checks whether the paragraph describing the decision is accurate. A review that only checks decisions leaves the prose ungated, and the prose is what everyone downstream cites. In the 2026-09-05 example, roughly twenty statements of fact got repaired across the day, and every ruling the first review cleared survived the second review intact.

What is an evidence rung?

Every claim sits at a rung (argued, implied, observed, measured, proved) and every artifact supports some rung. The rule is that a claim may not use a stronger rung than the artifact it cites. It is a mechanical check a reviewer can perform without domain expertise. On 2026-09-05 one claim moved from "proved able to fail" to a recorded local reproduction, because the artifact was a CI run with the flag already on, which never showed the flag was the reason.

When should you run a second review lane for claims?

The scope where this pays is narrow. If nobody outside the session that wrote a record ever cites it, the second lane buys nothing. The value shows up once a claim in a document becomes an input to a later decision, a partner conversation, a security posture, or a signature. A multi-tenant system holding other people's data qualifies, and so does a stack of contracts about to be signed.

{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{"@type": "Question", "name": "Can code review find false claims in the documentation?", "acceptedAnswer": {"@type": "Answer", "text": "Code review checks whether the decisions are right. It almost never checks whether the paragraph describing the decision is accurate. A review that only checks decisions leaves the prose ungated, and the prose is what everyone downstream cites. In the 2026-09-05 example, roughly twenty statements of fact got repaired across the day, and every ruling the first review cleared survived the second review intact."}},
{"@type": "Question", "name": "What is an evidence rung?", "acceptedAnswer": {"@type": "Answer", "text": "Every claim sits at a rung (argued, implied, observed, measured, proved) and every artifact supports some rung. The rule is that a claim may not use a stronger rung than the artifact it cites. It is a mechanical check a reviewer can perform without domain expertise. On 2026-09-05 one claim moved from proved able to fail to a recorded local reproduction, because the artifact was a CI run with the flag already on, which never showed the flag was the reason."}},
{"@type": "Question", "name": "When should you run a second review lane for claims?", "acceptedAnswer": {"@type": "Answer", "text": "The scope where this pays is narrow. If nobody outside the session that wrote a record ever cites it, the second lane buys nothing. The value shows up once a claim in a document becomes an input to a later decision, a partner conversation, a security posture, or a signature. A multi-tenant system holding other people's data qualifies, and so does a stack of contracts about to be signed."}}
]
}

Photo to Listing: Barcode Decoding and LLM Re-rank

Jeremy Longshore — Fri, 04 Sep 2026 10:35:18 +0000

A comic shop employee photographs a back issue on a phone. The system has to come back with the right title, the right issue number, and the right variant, because a first-print variant and a common reprint of the same book are the same picture with different economics. That is the identification problem in intent-longbox, a photo to listing pipeline that ended 2026-09-01 at v0.2.1 after eleven commits.

The research that preceded the build settled the architecture in one finding: LLM vision alone is not viable for issue-exact and variant-exact identification. Every incumbent that actually works in this space runs image-similarity retrieval against a reference cover corpus. The model is a ranker, never the source of truth.

So the pipeline puts the deterministic parts first.

barcode decode → candidate retrieval → LLM re-rank → human confirm → condition + price → Shopify draft

Nothing publishes without a person. The Shopify product lands as a DRAFT for owner review. The pilot shop is Gotham City Limit, running free.

The deterministic front of that chain is a barcode parser with no model in it at all. Post-1990 comics carry a 12-digit UPC-A that identifies the series, plus a 5-digit UPC supplement encoding issue, cover variant, and printing:

const supp = digits.slice(12);
return {
  ok: true,
  upc,
  supplement: {
    raw: supp,
    issue: Number(supp.slice(0, 3)),
    cover: Number(supp[3]),
    printing: Number(supp[4]),
  },
};

When that supplement is readable, the variant question is already answered by arithmetic. The model never gets asked.

The honest version of that diagram is that the retrieval leg is not built yet. v0 ships barcode plus vision plus human pick, with no similarity index behind the candidate step. So a barcode miss (pre-1990 stock, a damaged code, a variant with no UPC) falls to vision plus the gate below plus a mandatory human confirmation, which is the weakest path in the system and the one the pilot is meant to measure. That gap is tracked as the project's top open decision, not as a solved problem.

The database refuses to mutate

Every event in a scan session is a separate immutable row, which makes the table an audit trail rather than a current-state cache. scan_session is the identity. candidate_set holds the deterministic result (barcode decode plus similarity k-NN, FK'd to a corpus_version). llm_rerank holds the probabilistic value: provider, model, prompt hash, the verbatim response, confidence, band, contradiction flag, tokens, cost. It annotates the candidate set. It cannot edit it.

Then human_confirmation, condition_assessment, pricing_snapshot, shopify_draft, cost_log. Every shop-scoped table carries shop_id. The only UPDATE anywhere in the codebase is on scan_session.status.

The obvious way to enforce append-only is code discipline. Write no UPDATE statements, review for them, move on. I rejected that, because it holds exactly as long as every future query is well behaved. A migration script, a hotfix, or one psql session at two in the morning ends the guarantee quietly, and the tell is that the audit trail looks fine afterward.

So the rule lives in the database:

CREATE OR REPLACE FUNCTION forbid_mutation() RETURNS trigger AS $$
BEGIN
  RAISE EXCEPTION 'table % is append-only (Hickey model): % not allowed', TG_TABLE_NAME, TG_OP;
END;
$$ LANGUAGE plpgsql;

DO $$
DECLARE t text;
BEGIN
  FOREACH t IN ARRAY ARRAY[
    'corpus_version','scan_photo','candidate_set','llm_rerank','human_confirmation',
    'condition_assessment','pricing_snapshot','shopify_draft','cost_log'
  ] LOOP
    EXECUTE format(
      'CREATE TRIGGER %I_append_only BEFORE UPDATE OR DELETE ON %I FOR EACH ROW EXECUTE FUNCTION forbid_mutation()',
      t, t);
  END LOOP;
END $$;

Verified against a real Postgres, not asserted in a comment. An UPDATE on cost_log raises table cost_log is append-only (Hickey model).

One more schema decision belongs here. Condition is a grade range label, and no numeric grade type exists anywhere in the schema, the API, the prompts, or the UI copy:

grade_range_low  text NOT NULL CHECK (grade_range_low  IN ('PR','FR','GD','VG','FN','VF','NM')),
grade_range_high text NOT NULL CHECK (grade_range_high IN ('PR','FR','GD','VG','FN','VF','NM')),

A 9.4 is a claim a phone photo does not entitle anyone to make. If the type does not exist, nobody adds it later under deadline pressure.

The evidence contradiction gate

Confidence scores from a model are self-reported. Asking for one and thresholding on it is the cheap version of a quality gate, and it fails in the direction you care about, because a model is most fluent when it is wrong about a plausible thing.

The VisionProvider interface therefore requires structured evidence alongside the answer:

/** REQUIRED structured evidence. The contradiction gate's raw material (R7). */
export interface Evidence {
  issue_number_read: string | null;
  price_box_text: string | null;
  logo_era_guess: string | null;
}

The prompt states the same requirement in the model's own terms:

- evidence fields are REQUIRED: report exactly what you can read on the cover
  (issue number printed, cover price box text, publisher logo era guess).
  Use null only when genuinely unreadable.

Now there is something to check. src/services/rerank.ts cross-validates each field against the top candidate's metadata. Issue number read against the candidate's issue. Cover price against a coarse US newsstand era table. Logo era decade against the candidate year:

if (evidence.price_box_text !== null && top.year !== undefined) {
  const priceMatch = evidence.price_box_text.match(/(\d+)\s*[¢c]|\$\s*(\d+(?:\.\d{1,2})?)/);
  if (priceMatch) {
    const cents =
      priceMatch[1] !== undefined ? Number(priceMatch[1]) : Math.round(Number(priceMatch[2]) * 100);
    const era = priceEraBounds(cents);
    if (era && (top.year < era.min || top.year > era.max)) {
      reasons.push(
        `price_box_text "${evidence.price_box_text}" implies ~${era.min}-${era.max}, contradicts candidate year ${top.year}`
      );
    }
  }
}

The era bounds are deliberately loose. The gate catches decade-scale misses and does not quibble about a two-year overlap.

A contradiction then costs the model its fast path:

export function applyContradiction(band: Band, contradiction: boolean): Band {
  if (!contradiction) return band;
  return band === "high" ? "medium" : band;
}

Three bands drive the phone UI. High is a one-tap confirm. Medium is a candidate grid with a forced pick. Low is manual search. Downgrading high to medium means a confident but self-contradicting answer costs the employee one extra tap instead of putting a wrong book into inventory.

The transferable piece has nothing to do with comics. Do not ask a model how sure it is. Make it report the specific things it read, then check those against something deterministic you already trust.

Seeded cases in the test suite all flag and downgrade: a wrong issue number read, a twelve cent price box on a 1988 book, a 1960s logo on a modern year.

The provider seam behind that gate is a bring your own key provider architecture per shop, with an Anthropic adapter (Messages API, image blocks, claude-sonnet-5 as default and reference model) and an OpenAI-compatible adapter (chat completions, image_url data URIs). Resolution order is a gateway override first, then a shop credential row whose key_ref names an env var, then a global env fallback. Raw keys never enter the database, only refs to env var names. Two pieces of reliability lore carried over from the estate's existing provider registry shape in @intentsolutions/refiner and the Transport seam in @intentsolutions/jrig-cli: a 2048 max-output-token floor, and a parser that strips <think> blocks before it goes looking for JSON.

One snapshot per source, and no source can block

The 23:56 commit added a second seam. A PricingProvider declares a source, a kind of live_asks or historical_fmv, and returns comps plus a low/median/high summary plus fetched_at plus a stub flag. Two adapters implement it: a new eBay Browse adapter (OAuth2 client-credentials app token, cached until near expiry, query built from title, issue number, and variant against the comics category) and PriceCharting refined behind the same interface.

Two decisions in that step went against the obvious version.

First, provider isolation over sequencing. Calling two pricing APIs in a row is simpler to write and means the second one never runs when the first one has a bad morning:

const settled = await Promise.allSettled(args.providers.map((p) => p.getComps(args.query, shopCtx)));

A failed source is reported in the outcome list with its error and writes no snapshot row, because nothing was fetched. The other source still prices the book.

Second, one snapshot row per source, with the overall suggestion stamped on every row:

for (const result of fulfilled) {
  const res = await db.query(
    `INSERT INTO pricing_snapshot
       (scan_session_id, shop_id, source, query, comps, suggested_cents, override_cents, policy_id, fetched_at)
     VALUES ($1,$2,$3,$4,$5,$6,$7,$8,$9) RETURNING id`,
    [
      args.sessionId,
      args.shopId,
      result.source,
      queryText,
      JSON.stringify(result.comps),
      suggested,
      args.overrideCents ?? null,
      args.policyId,
      result.fetched_at,
    ]
  );
}

Per-source suggested prices would have been more honest-looking and worse to consume. The draft step would have needed to know which source wins before it could read a price, which is ordering ambiguity in a table that no one is allowed to correct afterward. Stamping the overall figure on every row keeps one rule for the draft step: the latest snapshot carries the price of record.

Precedence is fixed rather than clever:

export function pickDrivingResult(results: PricingResult[]): PricingResult | undefined {
  const real = (r: PricingResult) => !r.stub && r.comps.length > 0;
  return (
    results.find((r) => r.kind === "historical_fmv" && real(r)) ??
    results.find((r) => r.kind === "live_asks" && real(r)) ??
    results.find(real)
  );
}

Historical fair market value beats live asking prices, because an ask is a wish. When neither source has real comps, the shop's policy floor wins. The UI shows both sources side by side, highlights the driving one, and labels stubs as stubs.

Governance, tests, and the release cycle

Governance came first, at 18:07, through the /repo-dress pass: LICENSE, SECURITY.md, CONTRIBUTING.md, CODE_OF_CONDUCT.md, SUPPORT.md, AGENTS.md, CI. The 18:12 commit authored the six master planning docs (business case, PRD with R1 through R20 MoSCoW-tagged, architecture, user journeys, technical spec, status) alongside the index and the project CLAUDE.md, which brought 000-docs/ to eight filed documents with the competitor analysis and the approved build plan already in the tree. Then an isolated beads workspace with prefix longbox. Five automated release commits took version.txt from v0.1.0 to v0.2.1.

The API is shop-scoped by path prefix, /api/shops/:shopId/scan-sessions, chosen over a header because a path is visible in logs, cacheable, and curl-friendly. Onboarding a shop is one command, pnpm register-shop. Every model call writes a cost row from day one.

Verification at end of day: pnpm lint, format:check, and typecheck green. 118 unit tests, up from 92 at the core-pipeline commit. Coverage 99.67% of lines against a floor of 80. Fourteen integration and smoke tests green against a dockerized postgres:16, including one that asserts two snapshot rows come out of a single price call. Migration 002 extends the shop_credentials.kind CHECK with ebay and leaves 001 untouched. tests/TESTING.md was re-pinned with audit-harness init.

What this does not do yet

Both pricing sources are stubs in real terms right now. PriceCharting's live field mapping needs verification the day the Premium token lands, and eBay returns a flagged stub without credentials.

No similarity index exists. That is a locked decision rather than an oversight: v0 ships barcode plus vision plus human pick, and if the pilot shows real misses the plan is to buy before building. Ximilar sells a commercial comics visual-search API and a quote is pending. A self-built cover-image index would rest on a fair-use posture instead of a granted license, which is the project's top logged risk.

The CI static eval regression set is a Phase 2 exit item that has not been built. The human_confirmation table is designed to grow into that eval set, and it currently holds nothing. The UI override_cents smoke assertion is still pending.

And none of this has met a real comic. Every number above came from a test suite and a Docker container. The pilot has not run.

Also shipped that day, both routine pipeline output: the blog automation dual-published the previous day's post working-is-not-proven to tonsofskills.com/blog, and the comehomealabama journal published a piece on July coastal market numbers.

Common questions

Why not use a vision model alone for comic identification?

Issue-exact and variant-exact identification is retrieval work. Every incumbent that works in this space runs image similarity against a reference cover corpus, which is why the model here sits in the re-rank seat instead of the identifier seat. A first print and a common reprint of the same book are the same picture with different economics, and that difference is carried by metadata rather than by the image.

Should barcode decoding run before or after the vision model?

Before. Post-1990 comics carry a 12-digit UPC-A plus a 5-digit supplement that encodes issue, cover variant, and printing, so a readable supplement answers the variant question by arithmetic and the model is never asked. Vision is the fallback for the books that arithmetic cannot reach, and today that fallback runs without a similarity index behind it.

How do you stop a vision model from confidently returning a wrong answer?

Require structured evidence alongside the answer, then check that evidence against something deterministic. This pipeline asks for the issue number read, the cover price box text, and the logo era, then cross-validates each against the top candidate's metadata. A contradiction downgrades the confidence band from high to medium, which costs the employee one extra tap and keeps a wrong book out of inventory.

Every Claim Needs a Shipped Source and an Executable Proof

Jeremy Longshore — Wed, 02 Sep 2026 14:49:15 +0000

I told GPT 5.6 Luna, running through Codex, to finish teh epics and beads on the plugins repo. It ran for about 361 minutes across 2 sessions and 187 turns, and it closed nothing. No file mutated, no Beads record touched, no GitHub state changed. Its closing line was that the worktree was clean at origin/main 3c5be4a5981ed5089deedff53d18136b9848a18c.

That is not a failure report. Asked to finish three epics, the honest deliverable turned out to be an inventory of what "finished" would actually require, and the five open beads had five different meanings of "not done". Two of them are closable by writing code. The other three need an owner clicking a setting, a calendar to run out, and a record corrected to match reality.

The same gap kept showing up until the day ended, and three of the day's fixes were to proof machinery that could not be trusted about its own state: a gate runner manufacturing false failures, a render check poisoned by its own output, and a liveness marker that could not tell quiet from dead.

Five ways a finished feature is still not done

The audit read Epics 6, 7 and 10 against Blueprint 727, the live Beads Dolt database, origin/main code, tests, workflows, branches and PRs. Read-only throughout. What came back was a taxonomy.

Code live, acceptance failing at the platform. claude-nfzl.6 ships in 242d8e051: validate-plugins.yml, check-marketplace-compliance-baseline.py, .github/CODEOWNERS, and 13 focused tests. Then gh api repos/.../branches/main/protection returns required_approving_review_count=0 and require_code_owner_reviews=false. The gate is written, committed and switched off. Nothing in the repository can close that bead. It needs an owner clicking a setting.

Calendar-gated, not code-gated. claude-nfzl.7 has PR #1384 merged as b786149e1, R2 and R4 code live, and a full-corpus run passing in about 58 seconds across 2053 live triples with zero newcomers. The only thing outstanding is a mandatory two-week R1 observation window and a flap receipt. Time closes that one. Code cannot.

Complete but stale. claude-jqvw.11 runs check-mirror-licenses.mjs green at 36 of 36 configured sources and 36 of 36 .source.json mirrors, with sync hard-failing on a missing license include. Blueprint and Beads still carry the historical 63/63 denominator. The record is wrong, not the code.

Green suite, missing red run. claude-jqvw.1 has the whole chain working: tag, GitHub Release, reassertion, npm publish, with npm-publication-lock.test.mjs passing 11 of 11. What it does not have is the required fault-injection RED run proving no orphan npm publication and retained signed evidence-row proof. A passing test says the happy path holds. It says nothing about the failure mode you built the lock for.

Flag exists, workflow never calls it. The evidence emitter supports --certification-report. .github/workflows/emit-evidence.yml never generates or passes a real one, so only catalog, unicode and required-context rows get signed. claude-snmr.5 is open because of that, and claude-snmr.6 is explicitly blocked behind it.

The audit also decomposed a 79-entry corpus shrink (2132 pinned against 2053 live) into 78 E-MISSING-REQUIRED-SECTION plus 1 E-FRONTMATTER, rather than treating it as one bot-authored rule change. Last baseline commit was bot PR #1367 on Aug 27. And mid-run another agent modified freshie/scripts/promote-to-curated.py and moved the branch to fix/curated-promotion-cohort-parity. The auditor refused to reset or touch it and took all its Epic 6 evidence from read-only Git views of origin/main instead. That is the correct call in a shared working tree, and it is a call I have watched agents get wrong.

Merged in that repo the same day anyway: PR #1401 (3c5be4a59, secure projections and Snowflake, the same commit the auditor later signed off as its clean baseline), PR #1403 (Snowflake operator skills), and d6d14da83 unifying the freshie curated promotion cohort.

Why not just close the beads

Because a closed bead that traces back to switched-off branch protection is worse than an open one. An open bead is a question. A closed bead is an answer, and nobody re-audits an answer. Convert the first into the second and you have not finished the work, you have deleted the only record that the work is unfinished. Six hours of audit output that closes nothing is cheaper than one wrong close, because the wrong close comes back as a production surprise with no bead pointing at it.

Writing the requirement down as an enforced file

While that audit ran, the Omarchy fleet moved: omarchy-widget-template plus 15 omarchy-*-entry repos: docket, quiet-queue, foundry, loose-ends, bazaar, capture-conveyor, listening-post, crew-chief, desk-transition, flow-boundary, wait-state, workspace-storyboard, x-files, mlb-booth and pit-wall. The commit shapes repeat: test: certify <X> on Buzz, chore: sync canonical Omarchy gates, fix: bind <X> marketplace claims, test: refresh <X> Buzz proof.

The artifact worth naming is 18 lines of markdown in the template, contracts/marketplace.md, from commit 0607dcc:

# Marketplace claim ledger

Replace this template ledger before calling a generated plugin submission-ready.
Every meaningful listing claim needs a shipped source and an executable proof.
Do not infer behavior from a mockup, README, test name, or intended design.

| Claim | Shipped source | Executable proof |
|---|---|---|
| Visible bar outcome and primary panel action | `BarWidget.qml`, `Panel.qml` | plugin-specific contract and interaction tests |
| Data source, scope, cadence, and bounds | service QML, `Model.js`, or shipped helper | fixture-backed unit, boundary, and failure tests |
| Local writes, network use, credentials, and explicit exclusions | every shipped runtime path | security contract tests plus canonical gates |
| Marketplace image tells the same product story | `assets/banner.svg`, deterministic E2E fixture | hash-bound Buzz render receipt and visual approval |

Two columns per claim, and both are mandatory. A test name is not a proof. A mockup is not a source. The ledger also fixes the description rule so it stops being a matter of taste: the final listing description and barWidget.description must be identical, exactly 500 characters, name the product, explain what appears in the bar or panel, state what the user can do, and disclose the material trust boundary.

A markdown file nobody enforces is a wish. The same commit added six lines to tests/contract.test.js, five assertions plus the read, so the ledger cannot be quietly deleted or hollowed out into a heading with nothing under it:

const marketplaceContract = read("contracts/marketplace.md")
assert.match(marketplaceContract, /\| Claim \| Shipped source \| Executable proof \|/)
assert.match(marketplaceContract, /exactly\s+500 characters/)
assert.match(marketplaceContract, /bar or panel/)
assert.match(marketplaceContract, /trust boundary/)
assert.match(marketplaceContract, /hash-bound Buzz render receipt/)

The commit touched .harness-hash (+8/-7), README.md, contracts/marketplace.md (+18), tests/RTM.md, and tests/contract.test.js (+6). Small diff. It is the same move the audit was asking for, applied one layer earlier: state the requirement in a file, and make the test suite fail if the file stops saying it.

Two bugs where the proof machinery broke its own preconditions

Both of these landed the same day, in the same fleet, and they are the same shape: the thing that verifies work was interfering with the work it verified.

A gate runner racing its own input

scripts/run-plugin-gates.sh in omarchy-docket-entry fed each gate a small JSON envelope through a pipe. A gate that exits before reading stdin races the producer into SIGPIPE, exit 141. So a deterministic invalid-verdict check became an intermittent gate crash, dependent on scheduling. Commit 240b2d6 swaps the pipe for a here-string:

INPUT="$(jq -nc --arg c "$TARGET" '{candidate:$c, action:"omarchy-submit", env:{repo:""}}')"
for gate in "$GATES"/c*.sh; do
  # Feed the small JSON envelope with a here-string. A pipe lets a gate that
  # exits before reading stdin race the producer into SIGPIPE (141), turning a
  # deterministic invalid-verdict check into an intermittent gate crash.
  verdict="$(bash "$gate" 2>/dev/null <<< "$INPUT")"
  # A gate that emits nothing has crashed hard. Fail closed rather than
  # silently counting it as clean, which is how a broken gate becomes theater.
  if [[ -z "$verdict" ]]; then
    # (excerpt: the loop goes on to print CRASH, set blocked=1, and continue)

The fail-closed-on-empty branch and that comment about theater were already in the file. Somebody had already thought carefully about a gate emitting nothing. What was broken was that the runner could manufacture the empty verdict itself, and then correctly fail closed on a condition it had caused. This is the inverse of the audit's problem: there the evidence was missing, here the evidence was lying. A safety check firing on its own noise is still a false alarm, and false alarms are how people learn to ignore gates.

A render that dirtied the source it was proving

scripts/rig-render.sh in the template will only issue a render receipt if the source tree is clean, which is the entire point of a receipt: it binds an image to a specific source state. The glob of files whose modification marks the tree dirty included preview.png, the render's own output.

So a failed render left a stale preview.png behind. That file marked the source dirty. No retry could ever produce a clean receipt. One bad render poisoned every attempt after it. Commit 52a9d42 removes the artifact from the precondition: the pathspec used to carry preview.png between manifest.json bin and README.md, and after the fix it reads:

SOURCE_DIRTY=false
if [[ "$SOURCE_COMMIT" == "unknown" ]] || \
   [[ -n "$(git -C "$TARGET" status --porcelain --untracked-files=all -- \
     '*.qml' '*.js' manifest.json bin README.md assets/banner.svg \
     e2e scripts/rig-render.sh 2>/dev/null)" ]]; then
  SOURCE_DIRTY=true
fi

The obvious fix is to delete preview.png at the top of every run. That fix is wrong, and the reason is worth stating. The receipt exists to distinguish a render of clean source from a render of dirty source. If the script scrubs the output first, every dirty-source failure gets laundered into a clean run and the distinction the receipt sells is gone. Removing the output from the precondition is a smaller change and it keeps the signal. The same class of fix landed in two other entries that day: "keep failed Capture renders retryable" in capture-conveyor (04ca3ae) and "allow clean render retry after failed capture" in loose-ends (88054b8).

A dead-man that could not tell quiet from dead

At 22:12 I asked for something unrelated: i need ezekiel to start recievinf the emails like he does withe blog backfill skill that runs the blog work u know what i mean. Ezekiel does the social posting. The blog pipeline already emails him a per-post packet. The real-estate content machine behind comehomealabama.com, run out of coastal-realty-ops, had been soaking unattended for 11 days and it was time to point it at him too.

Claude Fable 5 ran a health check before flipping anything, on the reasoning that Ezekiel should not start receiving packets from a broken producer and should not get 11 days of backlog dropped on him in one morning. The soak verdict: five posts landed on Aug 21, 24, 26, 28 and 31, all Monday/Wednesday/Friday, every prior post packeted, liveness green, and the ledger showed exactly one unsent packet. He would start with one email.

The flip itself was five minutes and nine tool calls, shipped as coastal-realty-ops PR #50 (17394b3): packet.env PACKET_TO set to ezekiel@intentsolutions.io with me on CC. The file is sourced per run, so no restart, effective at the next 05:15 sweep. That commit also banked 5 lines of decisions.jsonl and 3 lines of topics-queue.jsonl the producer had accumulated during the soak.

The health check is what found the bug. scripts/journal/mandy-posting-packet.sh had three clean no-op exits (no ledger, no packets due, no digest week) and all three returned 0 without touching mandy-posting-packet.ok. The estate dead-man sweep reads a fresh .beat with a stale .ok as running-but-failing. So a perfectly healthy pipeline with nothing due for two days would page. It was already visible in the wild: .ok stuck at Aug 29 (the Aug 28 post's packet fired that morning) while .beat kept advancing.

The commit message for comehomealabama PR #8 (d87bada) carries the rule in one line: a clean no-op IS a successful run. Change was +5/-3 in one shell script, verified with shellcheck -S warning, bash -n, and a live --sweep against the current ledger that logged "no packets due" and refreshed .ok.

The tempting shortcut is to touch .ok at the top of the script and stop thinking about it. That reports healthy before doing any work, which is precisely the failure the dead-man exists to catch. The marker belongs on every path that legitimately completes, no-ops included, and on no path that does not. Quiet and dead have to be distinguishable, and the only place that distinction can live is in the script that knows which one it is.

The part I keep coming back to: nothing was on fire. The two-day quiet window that would have false-paged had not happened yet. It got found because Claude Fable 5 checked the system before trusting it with a person's inbox.

Also shipped

Retiring a carried patch in the Buzz fork. cb633a0c4 plus PRs #30 and #31 emptied CARRIED_PATCHES in scripts/fork-gates/check-additive-only.sh, deleted the carried 311-line e2e spec desktop/tests/e2e/manual-invite-join.spec.ts, replaced FORK.md's carried-patches exception with None - empty by design, and filed a 131-line audit at 000-docs/009-AA-AUDR-fork-contract-breach-2026-08-16.md. PRs #26 and #27 had carried an invite-to-default-channel patch on fork main, the same class of fork-contract breach as the earlier PR #16 incident already documented in 000-docs/007. Production now runs the upstream published image (ghcr.io/block/buzz@sha256:fe092cf9...), enrollment moved to an ops-side watcher in the private ops repo, and the real fix is tracked upstream as block/buzz#4307. Merge-and-restore beat revert because the upstream sync supersedes the carry without rewriting history. Both check-additive-only.sh and check-must-survive.sh pass with CARRIED_PATCHES empty, gate output pasted into the PR body. A large upstream sync (91452d823) landed about 15 upstream commits the same day.

A discovery that ended in deliberate non-adoption. Starting 02:10, Claude Fable 5 ran a discovery on the third-party no-mistakes tool against the Intent Solutions testing SOP. It is a Go git-proxy: you push to a no-mistakes remote instead of origin and it runs intent, rebase, review, test, docs, lint, push, PR and CI in an isolated disposable worktree, with an LLM review stage that falls back across agents and a CI repair loop with guarded force-push. We did not adopt it. What came out was worktree-run.sh built into audit-harness, a verification of the read-only-test rule, and the non-adoption recorded as a decision instead of an unwritten "we looked at it once". Two incidental findings: yamllint was not installed on this box, and the escape-scan expectation was inverted, since the test expects a non-zero exit (a REFUSE) when policy is being weakened.

A $0 calendar stack, decided in conversation, no commits. The one item of the day with neither a shipped source nor an executable proof, recorded here as the exception it is. With a Buzz VPS bill due the next day I asked what was free, then im so confused whata the most texhnically sound optiin that would be most respected by underground linux users as my teams set up. Answer: Radicale on the VPS that already exists. One Python process, and the team calendar is a directory of plain .ics text files you can grep and diff, backed up by borg like any other directory. khal plus vdirsyncer for the terminal, Cal.com's free tier for outward booking. The part worth recording is the refusal. Fastmail was rejected as a mail viewer, because a calendar decision should not quietly turn into a second mail migration one month after the MXroute cutover.

What the day cost

The session analyzer logged 19 failure-to-fix arcs and 2 course-corrections across four models (Claude Opus 5, Claude Sonnet 5, Claude Fable 5, GPT 5.6 Luna), over sessions spanning 1169 minutes of wall clock. GPT 5.6 Luna took claude-code-plugins for 2 sessions, 187 turns, 361 minutes. Claude Fable 5 took intent-eval-platform for 3 sessions, 27 turns, 8 errors and both course-corrections. Claude Opus 5 and Claude Fable 5 split the home layer across 3 sessions and 273 minutes with 9 errors. Claude Fable 5 did coastal-realty-ops in 5 minutes and 9 tool calls.

The two ends of that range are the same instinct at different scales. GPT 5.6 Luna was told to finish the epics and spent six hours producing an audit that closed nothing, because closing them honestly was not on the menu. Claude Fable 5 was told to switch Ezekiel on, checked the pipeline's health first, and then did exactly what it was asked. Only one of the two delivered the literal request, and it delivered it last. Both started from the same place: find out whether the thing is true before writing down that it is.

{
"@context": "https://schema.org",
"@type": "BlogPosting",
"headline": "Every Claim Needs a Shipped Source and an Executable Proof",
"description": "Every claim needs a shipped source and an executable proof. What a six-hour audit that closed nothing found out about code that was already finished.",
"url": "https://startaitools.com/posts/working-is-not-proven/",
"datePublished": "2026-08-31T10:00:00-06:00",
"dateModified": "2026-08-31T10:00:00-06:00",
"author": {
"@type": "Person",
"name": "Jeremy Longshore"
},
"publisher": {
"@type": "Organization",
"name": "Start AI Tools",
"url": "https://startaitools.com"
}
}

One Corrected Check, Fifteen Repos

Jeremy Longshore — Tue, 01 Sep 2026 10:21:25 +0000

Two gates failed the same way on 2026-08-30, in systems that share no code.

The first checked whether a set of run fields were non-null. A recorded discovery run could therefore declare 3,000 skills while carrying 19 rows, and the boundary would pass it, because 3,000 is not null and 19 is not null. Runs 6 through 11 all disagreed with their own row counts. Run 11 declared 3,069 against 3,678 actual rows.

The second checked whether a marketplace submission description was exactly 500 characters. Which 500 characters was never asked. So 500 characters of filler passed, and 500 characters of filler is precisely the submission the gate was written to stop.

A check measuring a proxy instead of the property is the house failure mode on this blog and has been for months. I am not going to pretend it was a discovery. What was actually expensive on this day was not diagnosing either gate. It was pushing one corrected gate through fifteen repos that carry it as a vendored, hash-pinned copy rather than importing it. That half is the post.

The evidence boundary that could not see its own run

Epic 5, "Coherent Freshie Evidence," closed in claude-code-plugins that day. The closure AAR is 000-docs/809-AA-AACR-epic-5-closure.md, 134 lines, filed against epic bead claude-h05s.

The AAR states the defect in one line: "The old boundary checked whether required run fields were non-null, not whether the header and its rows described the same run." The run-6 shape is the image that sticks. Three thousand declared skills, nineteen rows, green.

Five invariants replaced it:

gate_run_completeness() compares the run header against same-run rows before any export work begins.
The grade histogram, CSV row count, CSV hash, run tag, and immutable Dolt commit must identify one export, not adjacent runs that happen to be close.
Behavioral-evaluation identity is jrig_run_id, held separate from discovery-run identity.
Evidence class and retention are validity conditions, not annotations. Three legacy proofs are now honestly classified E0. No public verified projection remains.
Blocking CI installs a pinned Dolt binary immediately before an exact guarded runner, which must execute one real hermetic cycle with zero skips against scratch SQLite, Dolt, and filesystem state, then prove live-server refusal.

Nine commits landed that sequence, and read as a run they are a reviewer finding bypasses faster than they could be closed:

make exit evidence fail closed
reject skipped and overwritten proofs
close generator and overwrite bypasses
require executed hermetic proof
bind proof method and install order
verify guarded cycle invocation
bind receipts and harden hermetic proof
publish reproducible run 14 receipts
enforce graded corpus parity

The independent boundary review returned PASS only "after reproducing and closing skipped tests, generator no-op, lifecycle replacement, aliased mutation, and post-verification binary-overwrite attacks." Five attacks. Each one maps onto a commit in that list. reject skipped and overwritten proofs is the skipped-test attack. close generator and overwrite bypasses is the generator no-op. bind proof method and install order is what stops the binary being swapped after verification. The commit log is not a changelog here, it is an attack transcript with the reviewer's half missing.

The first commit alone touched 8 files for +1515/-256, including run-delta.py at +247/-50, measure-epic-1-scorecard.mjs at +382, and four test files. All nine commit bodies were empty, which is worth one dry line: the sequence that produced the most legible story of the day carried no explanation with it at all.

Final receipts. Run 14 declared 3,053 against 3,053 rows, delta 0. 3,630 compliance rows against 3,630 grade rows with matching SHA-256. Run 14 is bound to immutable Dolt commit 2ljhn79ge74uj1kd7q2chqgo9ne0tulb, grade CSV SHA-256 72fbb289e8451d9a4bbe95cae0b9a1797588c0197589f94ddd1cde48241e4ef0, histogram A 1,872 / B 1,117 / C 479 / D 157 / F 5. pnpm run measure:e1:check passed 39 measurement tests and the tracked artifact matched its exact regeneration from the Git index. PR #1387 merged as 78e3580c after 34 reporting checks with zero failures.

The AAR's own first lesson is the one to keep:

A green test command is not proof that the governed body ran. Exact test count, zero skips, and a guarded method invocation are part of the boundary now.

Its second lesson is quieter and I think better: "Zero E2/E3 claims is a safe state, not a 100% retention measurement." The scorecard now reports retention_percent as null. A tool with nothing to measure says nothing rather than reporting a flattering 100%.

Five hundred characters of anything

The second gate is scripts/gates/c43-omarchy-marketplace-presentation.sh, which guards marketplace submission copy across the Omarchy widget fleet. Here is what it checked:

if [[ "$HAS_BAR_WIDGET" == "true" && "$BAR_DESC_LENGTH" != "500" ]]; then
  FINDINGS+=("barWidget description uses $BAR_DESC_LENGTH/500 characters")
fi

Length equality, and nothing else. A submission had to fill its allowance exactly, and filling an allowance is trivially satisfied by padding.

The comment written above the replacement checks is the whole day in five lines:

Length alone is not copy quality. A submission description must identify the product, explain what the user can see or do, and state a meaningful trust boundary. These checks deliberately reject generic 500-character filler while repo-specific contract tests pin the precise claims each plugin is allowed to make.

The new checks run as an embedded python3 heredoc inside the bash gate, each one appending to a findings list rather than exiting early, so a bad description gets told everything wrong with it at once. Four of them, excerpted:

sentences = [part.strip() for part in re.split(r"(?<=[.!?])\s+", description) if part.strip()]
if len(sentences) < 4:
    findings.append("description needs at least four readable sentences")
if sentences and len(sentences[0]) < 50:
    findings.append("opening sentence is too thin to establish the user outcome")

surface_terms = ("bar", "panel", "pill", "widget")
if not any(re.search(rf"\b{term}\b", lower) for term in surface_terms):
    findings.append("description never explains the visible bar, panel, pill, or widget")

Two more term lists do the load-bearing work. An interaction list (open, click, select, copy, install, focus, refresh, preview, sort, scan, and about a dozen more) fails a description that "gives no concrete user interaction or visible behavior." A boundary list (no, never, only, without, offline, local, private, fixed) fails one that "gives no privacy, network, data, or write boundary." A description can be four fluent sentences about nothing and still fail both.

Then there is a banned-phrase list inside the gate, nine entries: cutting-edge, game-changer, game-changing, revolutionary, supercharge, seamless, robust solution, unlock your, take your productivity to the next level. I run the same instrument against this blog's prose from a JSON deny-list, and the overlap is not coincidence. Both lists exist because the same generator produces both kinds of copy.

Plus one cross-field check with the best failure message in the set: manifest and barWidget descriptions tell different product stories, which fires when the two description fields disagree about what the thing is.

None of that is clever, and it is worth being honest about what it does not do. A length check and a shape check are the same class of instrument, and a determined author can pad four sentences as easily as one. The gate is not proving quality. It raises the floor from "any 500 bytes" to "500 bytes that name the product, show a visible surface, describe an interaction, and state a boundary," and its own comment says where the real work goes: repo-specific contract tests pin the precise claims each plugin is allowed to make.

The part that actually cost the day

Downstream repos do not import this gate. Each one carries a vendored copy. The lane is declared at scripts/gates/.lane-manifest, whose header reads:

# Vendored gate lane. Regenerate with scripts/sync-gate-lane.sh, never hand-edit.
# canonical: contributing-clanker@359a27cde21e60086f95a3ddee99c8920a3d7ca2

That header is quoted with its dash normalized to a comma, because the real file uses an em dash and this blog's own lint gate would quarantine the post for reproducing it.

Below the header sit per-file SHA-256 hashes of every gate script. Alongside it, each repo carries .harness-hash covering the wider audited surface: contract.test.js, run-plugin-gates.sh, stryker.config.json, tests/RTM.md, tests/TESTING.md, and the rest.

So the corrected conditional is not a one-line edit. The canonical pin moved from contributing-clanker@359a27cd to @81239c6e, and in every consuming repo four hashes had to move together:

the lane manifest hash, in .lane-manifest
the c43 gate hash, in both .lane-manifest and .harness-hash
run-plugin-gates.sh, because the gate list it dispatches changed
contract.test.js, because the per-repo contract test that pins the allowed claims changed with the copy

The third and fourth entries are the ones that make this expensive. The gate file itself is one hash. But correcting the gate changed which checks run, so the runner's hash moved, and tightening the copy to satisfy the gate changed each repo's contract test, so that hash moved too. One upstream edit fans out into four hashes per repo, and any repo where they drift fails its own harness verification before it fails the gate. That is the design working, and it is also the bill.

Here is the shape of a single downstream repo's day, using omarchy-listening-post-entry, which took four commits:

fix: complete Listening Post marketplace copy
test: pin Listening Post marketplace story
test: enforce marketplace presentation quality
chore: repin audit harness artifacts

Read that in order and it is the whole propagation protocol in four steps. Rewrite the copy so the new gate passes. Pin the specific claims this plugin is allowed to make, in its own contract test. Take the corrected gate from the lane. Re-pin the harness hashes so the repo verifies against its new self. Every repo ran some subset of exactly that. The spread runs from four commits down to one: omarchy-foundry-entry took a single test: commit and no copy commit at all, which is what it looks like when only the gate underneath a repo moves.

Fifteen entry repos took the change: bazaar, capture-conveyor, crew-chief, desk-transition, docket, flow-boundary, foundry, listening-post, loose-ends, mlb-booth, pit-wall, quiet-queue, wait-state, workspace-storyboard, x-files. Twelve of them needed a fix: complete <Name> marketplace copy. The other three, desk-transition, foundry, and wait-state, needed only the proof and the re-pin. Counting the template and the canonical lane source itself, the fan-out ran to 48 commits across 17 repos. The whole day, including the freshie epic, came to 112 commits across 19 repos.

The tradeoff is deliberate and I would still take it. Vendoring plus hash pinning means a downstream repo cannot silently run a gate that differs from canonical, and cannot quietly weaken one either. What it buys in tamper-evidence it charges in propagation, and the charge is not proportional to the size of the fix. A one-character change and a rewrite cost the same fifteen-repo sweep, because the sweep is the unit of work, not the edit. The implication is that batching discipline matters more than edit discipline on a lane like this one, though that follows from the design rather than from anything measured on this particular day: both corrected gates here lived in unrelated systems, so nothing rode the same sweep.

The gate that forced an honesty edit

Twelve repos needed a copy commit, and four of them needed a second pass after it. Those four are the interesting ones, because the gate did not extract more words from them on the second pass, it extracted truer ones:

fix: state MLB Booth data boundary honestly
fix: clarify Loose Ends queue priority
fix: make Bazaar marketplace copy precise
fix: tighten Pit Wall marketplace copy

The template's own description went the same direction. One long run-on became shorter sentences. "real-shell screenshot evidence" was softened to "shell screenshot evidence." "plugin-specific SVG banner" became "product-specific SVG banner." A gate asking for four readable sentences and a stated trust boundary got four readable sentences, and the claims came out weaker and truer than they went in. That was not designed. It falls out of asking for a trust boundary at all, because you cannot state one without noticing where yours actually sits.

A watch that could only see page one

Third thread, and it stays short because it is the same defect wearing different clothes. In intent-os, bead spine-lkb.12 and PR #566 shipped ops/plane-invite-watch/, a daily VPS timer that reconciles the Plane workspace invitation list against members and against its own known state, paging Buzz sys-incidents when an invitation is queued with no mail behind it, sits unclaimed past 7 days, or belongs to somebody who is already a member.

Two details earn its place. Its automations.md row is marked NOT-YET-ARMED until deploy receipts, which is the same call as reporting retention_percent as null: a row describing a timer nobody has armed yet is a lie in a document people trust. And the review caught that both fetches read only the first page, because "a watch reading only page one would go blind past 100 rows," rated HIGH. Cursor and envelope pagination went in, hermetic drill 9/9 after the change, full pnpm check green.

Three sessions, one steer

Three sessions ran concurrently, and the split is worth one line because it was not arbitrary. The fan-out work ran on Claude Opus 5 with Claude Opus 4.8 alongside it, 754 turns and 171 tool calls across twelve hours, because fifteen near-identical repos is exactly the job where a model holding a long invariant beats a fast one. The intent-os watcher ran on Claude Fable 5, 443 turns and zero errors in about an hour.

One steer is worth quoting exactly as typed, because it is the day's thesis arriving as a correction and it arrived before I had written any of the above:

yes add the auto-stash guard that seems like a band daid whats root cause fix

The model had proposed the thing that makes the symptom go away. The correction was not "that code is wrong," it was "that is the wrong layer." Same shape as the two gates: a check that satisfies the condition in front of it without touching the property underneath. Other steers that day were shorter and in the same register: "rm -rf the decoy dirs," "verify the card shows up on ezekiels board," "and what did u decide ?"

What the day bought

Two gates that now measure the property instead of a stand-in for it, and one monitor that can see past its first page. That is the cheap half.

The expensive half is the fifteen repos, and what it bought there was a fleet where no consuming repo can run a gate that quietly differs from canonical. The cost of that guarantee is that every correction, however small, is a fifteen-repo sweep with four hashes moving in lockstep per repo. Forty-eight commits to move one conditional is not overhead I would call waste. It is the price of the tamper-evidence, stated in full, which is the number that belongs next to the guarantee whenever the next lane gets vendored.

Also shipped

An adversarial multi-seat council ran that evening against a proposed company-calendar stack for the estate, reviewing it through fault-tolerance, data-model and source-of-truth, and convention-over-configuration lenses. Separately, an external tool called "no-mistakes" (a Go git-proxy that runs an intent, review, test, docs, lint, push, PR, CI pipeline inside an isolated worktree) was evaluated against the in-house audit-harness.

Scope the Guard to What the Job Actually Writes

Jeremy Longshore — Mon, 31 Aug 2026 10:18:23 +0000

Two systems mismeasured what was in front of them. One aborted loudly on dirt that could not touch it. One returned a 200 and assigned the card to nobody. Both fixes narrowed what a piece of code claimed authority over.

The 04:00 producer that aborted on dirt it would never touch

The blog pipeline runs unattended every morning at 04:00, on the same working tree that every interactive Claude Code session uses. One bash function, preflight_branch_normalize() in scripts/blog/lib-cron-common.sh, is the guard that decides whether the run may proceed at all.

It refused to run on ANY uncommitted tracked file. Full stop. A legitimate edit left unsaved overnight took down the entire cron job.

This happened three times:

2026-08-13: persona files
2026-08-18: a lost image-push race condition that left the tree diverged
2026-08-29: uncommitted 68-insertion doc update to 000-docs/002-REF-omarchy-plugin-promotion-reference.md

Two of the three were the same cascade: the dirty-tree check FATAL'd, no post got produced, and the 05:00 posting packet had nothing to send to Ezekiel. The 08-18 abort came one step later in the same function, where an ff-only pull correctly refused a tree that a lost image-push race had diverged. That one was fixed at the push, not here, and the scoping change would not have saved it. The morning of the 29th the recovery was manual: commit the legitimate content, push, re-run backfill for the 28th by hand.

The issue is mechanical: a human editor can legitimately leave work uncommitted while a nightly job wants to proceed. These are not in conflict. The job writes to four specific paths. Uncommitted changes anywhere else do not touch what the job produces.

The fix

Commit 605835ec: scripts/blog/lib-cron-common.sh (+28/-12). The preflight now FATALs only on uncommitted changes to the pipeline's own write-set:

content/posts/
.blog-staging/
.claude/skills/blog-backfill/methodology/decisions.jsonl
static/images/posts/

Uncommitted changes anywhere else are logged and left exactly where they are. The run proceeds.

Why not the obvious approaches

Two alternatives were considered and rejected.

Auto-stash: A band-aid. It moves someone's active mid-edit work out from under them, and then pops the change back to uncommitted. The same file re-triggers the abort the next night. Auto-stash also touches work that is not the pipeline's business to touch.

A retry loop or nightly re-run: The wrong tool for this shape of failure. A dirty tree is a standing condition, not a transient one. It stays dirty at 04:15, 04:30, any time you retry. Retries just multiply the failure alerts instead of fixing anything.

Scoping is the real fix. The producer genuinely cannot collide with dirt outside its write-set, so it should stop caring about it. The hazard is preserved: a half-written post in content/posts/ or a mid-edit decisions.jsonl still aborts, because building on top of those is genuinely unsafe. That distinction is the whole reason this works.

# Abridged from preflight_branch_normalize(); log strings shortened.
# Dirt inside the write-set still aborts. Dirt outside it is logged and left alone.
_porcelain=$(git status --porcelain --untracked-files=no 2>/dev/null || true)
if [ -n "$_porcelain" ]; then
  _dangerous=$(printf '%s\n' "$_porcelain" | grep -E '^.. (content/posts/|\.blog-staging/|static/images/posts/|\.claude/skills/blog-backfill/methodology/decisions\.jsonl)' || true)
  if [ -n "$_dangerous" ]; then
    _log "$log_file" "FATAL: uncommitted changes to the pipeline's own files on '$current_branch', refusing to proceed"
    _log "$log_file" "       These paths are what the producer writes; a half-finished post or edit here is unsafe to build on. Resolve and re-run:"
    printf '%s\n' "$_dangerous" >> "$log_file" 2>&1
    exit 1
  fi
  _benign=$(printf '%s\n' "$_porcelain" | grep -c . || true)
  _log "$log_file" "Pre-flight: $_benign uncommitted file(s) outside the pipeline write-set, ignoring, they will not be touched"
fi

The verification: a harness over four cases on a throwaway repo. It exercises two of the four write-set paths directly; the other two share the same match arm.

Benign 000-docs edit: passes the dirty check, logged as "ignoring, will not be touched"
content/posts/ edit: FATAL
decisions.jsonl edit: FATAL
Clean tree: passes

That morning's exact failure would now proceed untouched.

The alarm working is not the system working

One more thing about how the morning started. The failure did not surface because someone noticed a missing post. It surfaced because a gap detector built ten days earlier caught the gap and paged with a loud "no post landed" subject instead of reporting healthy.

That detector only existed for the third failure, and the reason it exists is the second one. On 2026-08-18 the producer aborted at 04:00 and the 05:00 heartbeat still called the pipeline healthy an hour later. The detector was built on 2026-08-19 precisely because detection had failed. So on 2026-08-29 it fired correctly, which is the system improving.

It is still worth saying plainly that it could have gone on firing correctly indefinitely without anything getting better. Three runs failed inside seventeen days. The alarm got fixed after the second. The guard behind it stayed wrong through all three. An alarm that fires reliably on a recurring failure is a reason to go fix the cause, not evidence that the cause is handled.

The task board that returned HTTP 200 and assigned nobody

Ezekiel gets the posting packet as an email at 05:00. For weeks, "done" meant "reply to the email with the URLs," and a 07:30 ingest job read those replies. But the ingest kept coming back empty.

The problem with reply-as-completion: a missing reply is indistinguishable from a missing post.

The fix (commit add88e64): after the packet email sends and marks packet_sent, the sweep also creates or updates one Plane card per post, assigned to Ezekiel. He drags it To Do to Done as he posts. A card has a state on a board. Email is the delivery; the card is the record.

The failure direction matters: the card call runs after the email send and after mark_sent, and it swallows every error. A Plane outage can never turn a delivered packet into a failed run.

The root cause

Plane silently drops an assignee who is not a member of the destination project, as opposed to the workspace. The PATCH returns HTTP 200 even when the assignment fails. Ezekiel was a workspace member but had never been added to the CONTENT project, so every assign returned 200 and assigned nobody.

def ensure_project_member(key: str, uid: str) -> bool:
    """Plane silently drops an assignee who is not a member of the PROJECT (not
    just the workspace). Idempotently add him so the assignment can actually
    stick. Returns True if he is (now) a member."""
    def member_id(r):
        m = r.get("member")
        if isinstance(m, dict):
            return m.get("id")
        return m or r.get("id")
    try:
        _, page = call(key, "GET", f"/projects/{CONTENT_PROJECT}/members/")
        rows = page.get("results", page) if isinstance(page, dict) else page
        if uid in [member_id(r) for r in (rows or [])]:
            return True
        st, _ = call(key, "POST", f"/projects/{CONTENT_PROJECT}/members/", {"member": uid, "role": 15})
        # 200/201 = added; 400 typically means "already a member", also fine.
        return st in (200, 201, 400)
    except Exception:
        return False

That is why nine Omarchy showcase cards created on 2026-08-25 all read assignees: [] even though the assign job logged "assigned 9". That is why his Plane board showed no work to do.

I isolated it by assigning a known-good member instead: Jeremy, a workspace admin. That worked instantly. Assign Ezekiel and it silently no-ops. Same code path, same 200. The difference was project membership.

I fixed it two ways. Added Ezekiel to the CONTENT project and back-assigned all 10 existing cards, the nine broken Omarchy cards plus the one for that day's post. Then blog-plane-card.py now calls ensure_project_member idempotent on every run, so this cannot silently recur.

One more Plane API quirk: assignees must be set in their own dedicated PATCH. Plane ignores an assignees field mixed into a create or update payload.

Verification: card created for the live post (HTTP 201). Re-run updates instead of duplicates (still exactly 1 card). Assignment confirmed by read-back. All 10 content cards now read assignees=[ezekiel]. Clean end-to-end run prints "updated card ... (HTTP 200)" with no error note.

The correction that shrank the design

The Plane card did not start out as one line in an existing job. The first pass at it was a tracking subsystem: a new state file, an ingest reconciler, its own cron entry.

The correction came in voice dictation, so the transcript caught it garbled: "please dont make it comicates alproach it with simixty also." Cleaned up, that is "don't make it complicated, approach it with simplicity."

What survived the correction was one sentence: add one step to the 05:00 packet job, so when Ezekiel gets his email he also gets a Plane card. Nothing else changes. The email stays. No new cron entry, no reconciler, no new state file.

That is what shipped. Commit add88e64 is 17 changed lines in blog-posting-packet.sh plus a 194-line blog-plane-card.py. The rejected design would have added a fourth moving part to a pipeline whose whole problem that morning was that its existing parts were too entangled with each other.

Worth being precise about what the models did here, because it was four of them across one long day. Claude Opus 4.8 and Claude Opus 5 carried the blog pipeline thread, including the preflight diagnosis and the scoping fix. Claude Sonnet 5 picked up shorter turns in the same tree. Claude Fable 5 ran the parallel Buzz investigation, which is where most of the day's errors landed: 34 of them across 847 minutes, against production Postgres auth logs over SSH. Across every session the day logged 474 tool calls, 40 failure-to-fix arcs, and 3 course-corrections in a 1112 minute span.

The three corrections are the part worth keeping. None of them were "that code is wrong." All three were scope corrections: fold this into what already exists, go verify the thing actually ran, make it smaller. The elaborate version got built competently on the first pass. What it did not get was a check on whether the problem deserved that much machinery, and on this day that check is the only thing that kept a task board from becoming a subsystem.

The through-line

Both fixes narrow what a piece of code claims authority over. The preflight claimed authority over the whole working tree when it only writes four paths. The assign call treated a 200 as proof the assignment happened, when all the 200 actually confirmed was that the request had been accepted.

The Plane fix did not literally remove code. It added a membership check and a second PATCH. What it narrowed was the claim: the assign call stopped treating an accepted request as a completed one. In both cases the code asserted something it did not govern, and the fix was to make the claim match the control.

Also shipped

Omarchy marketplace submission sweep. Eleven widget entry repos plus the shared template: Capture Conveyor, Desk Transition, Docket, Flow Boundary, Crew Chief, Foundry, Workspace Storyboard, Wait State, Quiet Queue, Listening Post, Loose Ends. The commit subjects run to "marketplace-ready" and "production certified", which is the repos' own shorthand and worth deflating here: what was actually established is that each widget loaded in a fresh Omarchy shell on the Buzz rig, with render receipts bound to the raw shell logs and runtime evidence kept separate from visual evidence. Submission is a filing, not an approval. That was breadth rather than depth, and it is not what made the day interesting.

Gate C43, the Omarchy marketplace presentation guard. Landed at 16:38 as 163 lines plus a 119-line bats suite, wired into CI, then tightened four more times the same day: 16:45, 17:41, 18:08, and 20:36. Each tightening closed something the previous version had let through. It checks that a manifest description uses the full 500-character allowance the catalog schema permits, that a bar widget description matches it rather than telling a different product story, and that the copy names the product, says what the user can see or do, and states a trust boundary. Requiring the full allowance is an unusual rule, and the reason given in the gate is blunt: every short description that escaped was generic. Five revisions in four hours is its own small lesson about writing gates, and it deserves its own post rather than a paragraph here.

Hermes trust boundaries hardened in claude-code-plugins (PR 1383). Split the contribute skill into read-only, prepare, and publish surfaces, dropped the automatic install-persistence hooks, and required explicit state and workspace paths. Merged.

Buzz forensics, unresolved. A separate thread that started as "save my automations and plan a clean reinstall" turned into reading production Postgres auth logs over SSH, per-pubkey auth successes and full connection lifecycles. It did not resolve into a shipped fix that day.

DEV Community: Jeremy Longshore

Verify Audit Evidence with a Signed Payload, Not by Format

How do you verify audit evidence from multiple publishers?

The format-evolution trap

The one canonical statement payload

One consumer, verification by signature

When verification fails, hold the last good snapshot

What got shipped

Why not the obvious approach?

Use this

FAQ

How do you verify audit evidence from multiple publishers?

What is a signed statement payload in an audit pipeline?

What should a verifier do when an audit row fails verification?

Related Posts

Park a Migration Without Losing the Work

What is the publish-and-park pattern for software migrations?

The pattern, in one sentence

The build-up trail

The atomic push

The gate suite on the merged commit

The cutover stays on Flask

Why not the obvious approach?

The "do not cut over" record

The successor repo

What survives a routine branch cleanup

What did not change the parked work

Use this

Frequently asked questions

How do you park a refactor without abandoning it?

When should you delay a production cutover after a green merge?

Why not merge to main and cut over later?

Related Posts

Team-Page Ordering Is a Release Decision

How should team pages be ordered?

What shipped and what did not

Why not the obvious approach?

The 30-minute footer sweep

The CI gate: check_estate_bar.py

What this looks like at three months

What "estate anchor" actually means

Also shipped

The discipline, generalized

Use this

FAQ

Why should team-page ordering be treated as a release decision?

What is an estate anchor?

How do you keep a team page authoritative across multiple sites?

Related Posts

Tailscale Federated Trust: Scope to Auth Keys, Not All

Tailscale Federated Trust: Scope to Auth Keys, Not All

What a federated trust actually is

The default that bit me

Why this is not paranoia

The proof

Why not just leave scope at all and rely on ACL

How the work went

Also shipped

Use this

FAQ

What is a Tailscale federated trust?

What does scope:['all'] actually grant on a federated trust?

Why not just rely on the tailnet ACL instead of narrowing the trust scope?

Related

Three Gates on Standard-User BitLocker State Observation

The day started with a P1 on merge day

Gate 1: the observer contract

Gate 2: the bounded native provider

Gate 3: the fixture-boundary authorization (the failure)

The TOCTOU reparse replacement (gate 3, the second finding)

The non-reparse offline file (the stale classifier, gate 3 by association)

Why not the obvious approach?

Adjacent finding on the NVMe health-log parser

Also shipped

Related posts

Perception Is On the Way, on Its Own Domain

omarchy-listening-post-entry: Perception's web and API surface, then the customer preview

Why the live deploy is a coming-soon page

GitHub Pages → VPS at intent-solutions

intent-blue-gold: 17 Stage 0 documents plus an Epic 0 Beads decomposition