DEV Community: Jeremy Longshore

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.

A Path Is Not Proof of Identity

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

Five marketplace submissions rejected simultaneously for the same security defect class. Every one created local state under the default umask, checked permissions with [[ -f ]], then wrote to the name later. Between the check and the write, a same-UID attacker could plant a symlink at that path, and the open would follow it. The first remediation looked like the textbook answer: umask 077, stat -c %s for size, timeout 2 on jq, and mktemp + mv for atomic writes. The reviewer rejected that too.

The reason is this: [[ -f ]] resolves the path, stat resolves it again, and write_session() resolves it a third time. Nothing binds those three calls to the same inode. A path is a name. A name is resolved fresh on every syscall. Checking a name and then acting on it is a race condition, specifically a TOCTOU (time-of-check-time-of-use) bug. You cannot fix that bug in a language whose only handle is a name.

The defect class: a symlink race in local state

Five Omarchy plugin submissions hit this defect simultaneously (marketplace issues #2899 through #2903). Each plugin's shell helper:

created ~/.local/state/<plugin>/ under the default umask, so it was group/world readable during creation
wrote to a state file via > "$file" or >> "$file", which follows a pre-existing symlink
read the whole mutable file into jq with no regular-file check, no byte ceiling, and no timeout

A symlink planted at the state path redirects the write to any file the user owns. That is a plain symlink attack, and nothing in the helper was positioned to notice it. A FIFO or oversized file at the path hangs the jq that the QML side polls every five seconds.

The contributing-clanker lane (the shared security gate suite) told itself those places were safe. It enforced gates on network input, on QML rendering, on command construction. It never modeled filesystem object identity. A gate lane's blind spot is exactly where threat lives.

Round one: the rejection

The first remediation shipped what looked like a complete answer. Quiet Queue's round-one attempt (commit 5c7a817):

umask 077
root="${XDG_STATE_HOME:-$HOME/.local/state}/omarchy-quiet-queue"
session="$root/session.json"
mkdir -p "$root"

session_max_bytes=4096
read_session() {
  local filter="$1" default="$2" size
  if [[ ! -f "$session" || -L "$session" ]]; then printf '%s' "$default"; return; fi
  size="$(stat -c %s "$session" 2>/dev/null || printf 0)"
  if ! [[ "$size" =~ ^[0-9]+$ ]] || (( size > session_max_bytes )); then printf '%s' "$default"; return; fi
  timeout 2 jq -r "$filter" "$session" 2>/dev/null || printf '%s' "$default"
}

write_session() {
  local tmp
  tmp="$(mktemp "$root/.session.XXXXXX")"
  cat > "$tmp"
  mv -f "$tmp" "$session"
}

That closes a descriptor and then reopens a mutable pathname. The [[ -f ]] check, then stat, then jq are three separate path resolutions. Nothing binds them to the same inode. Between stat and jq, a same-UID competitor swaps the file for a symlink. The write_session function creates a temp file inside the private directory, but mktemp and mv each re-resolve $root. Rename $root to .parked, plant a symlink at $root pointing anywhere, and both calls land inside the attacker's target. The reviewer said no.

Why not the obvious approach?

The obvious move was to keep the helpers in bash and add more checks. Bash already powers every other plugin helper. The linting infrastructure already knew how to read it. Adding [[ -f ]], stat, and timeout is cheap.

It lost because bash has no way to hold a file descriptor across operations. There is no fstat, no O_NOFOLLOW, no O_DIRECTORY. Every check bash can express is a check on a name, not on an object. You cannot fix a TOCTOU bug in a language whose only handle is a name. Leaving bash meant a rewrite of six helpers, a tool orthogonal to the rest of the codebase, and an interpreter that immediately tripped an existing gate banning Perl shebangs as a non-guaranteed runtime (resolved below, in the same commit that taught C41 to see the new helpers). That cost is real. But it is the only honest fix.

Every round-one control has a round-two replacement, and the difference is always the same one thing: whether the check and the use touch the same object.

Round one, resolved by name	Round two, bound to a descriptor	What changes
`[[ -f "$session" ]]` then read	`sysopen($fh, ...)` then `stat($fh)`	The thing checked is the thing read
`mkdir -p` plus `umask 077`	`sysopen(O_DIRECTORY, O_NOFOLLOW)` then `chdir`	The parent cannot be swapped after the check
`mktemp` then `mv`	`sysopen(O_CREAT, O_EXCL, O_NOFOLLOW)` then `rename`	No window to adopt a file you did not create
`stat -c %s` then `jq`	byte ceiling taken from `stat($fh)`	The size checked is the size read
`timeout 2 jq`	`O_NONBLOCK` at open, then the `-f` test on `stat($fh)`	A FIFO cannot stall the open, and the regular-file check rejects it

Descriptor-bound lifecycles

Round two (commit 229d6d4) rewrote the runtime helpers from bash to Perl. The key move: hold the state directory open from the start and never let it go.

umask 0077;
my $root = File::Spec->catdir($base, "omarchy-quiet-queue");
make_path($root, { mode => 0700 }) unless -d $root;
my $dir;
sysopen($dir, $root, O_RDONLY | O_DIRECTORY | O_NOFOLLOW) or die "unsafe state directory\n";
my @ds = stat($dir);
die "unsafe state directory\n" unless @ds && -d _ && $ds[4] == $<;
chmod 0700, $dir;
chdir $dir or die "cannot pin state directory\n";

O_NOFOLLOW refuses a planted symlink at open time instead of after. O_DIRECTORY means the kernel will not open this if it is not a directory. O_RDONLY is the minimum. stat($dir) on the open filehandle (the $dir object you hold, not the name) proves you own it. chdir $dir pins the parent so later relative opens like session.json resolve inside the object you hold, not inside a path an attacker swapped.

The read side stats the open descriptor, not the name:

sub read_session {
  return { until => 0, owned => JSON::PP::false() } unless -e $session;
  my $fh;
  return { until => 0, owned => JSON::PP::false() } unless sysopen($fh, $session, O_RDONLY | O_NONBLOCK | O_NOFOLLOW);
  my @st = stat($fh);
  unless (@st && -f _ && $st[4] == $< && $st[7] > 0 && $st[7] <= $max_bytes) { close $fh; return { until => 0, owned => JSON::PP::false() } }
  # read from $fh...
}

stat($fh) interrogates the object you actually hold. O_NONBLOCK means a FIFO cannot stall the open, which a blocking O_RDONLY on a FIFO would do until a writer showed up. It does not reject the FIFO by itself. The -f _ test against stat($fh) on the next line does that. The $st[4] == $< check verifies you own this inode. The byte ceiling is enforced against the object, not a name that could be swapped between the check and the enforcement.

The write side uses O_EXCL:

sub open_temp {
  for (1 .. 32) {
    my $name = sprintf ".session.%d.%08x", $$, int(rand(0xffffffff));
    my $fh;
    return ($name, $fh) if sysopen($fh, $name, O_WRONLY | O_CREAT | O_EXCL | O_NOFOLLOW, 0600);
  }
  die "cannot create private session temp\n";
}

sub write_session {
  my ($data) = @_;
  my ($temp, $fh) = open_temp();
  my $payload = encode_json($data) . "\n";
  my $offset = 0;
  while ($offset < length $payload) {
    my $n = syswrite($fh, substr($payload, $offset));
    die "session write failed\n" unless defined($n) && $n > 0;
    $offset += $n;
  }
  $fh->sync or die "session fsync failed\n";
  close $fh or die "session close failed\n";
  rename $temp, $session or die "session replace failed\n";
  chmod 0600, $session;
}

O_EXCL means you created it or you failed. There is no window where you adopt someone else's file. fsync guarantees the data hits disk. rename is atomic. Every flag is load-bearing.

Proving it with an adversary

This is the second time this bug class has come up here. CodeQL caught the race I dismissed covers the same shape in TypeScript, where the fix was a same-descriptor openSync, fstatSync, writeSync chain. Different language, identical lesson.

A unit test that asserts "the file has mode 0600 and valid JSON" does not catch this bug. The bash version would pass that assertion while remaining vulnerable. The test had to become an attacker.

Tests acquired a fixture that races the helper in a tight loop:

const fs = require("node:fs")
const [dir, victim] = process.argv.slice(2)
const parked = `${dir}.parked`
for (;;) {
  try {
    fs.renameSync(dir, parked)
    fs.symlinkSync(victim, dir)
    fs.unlinkSync(dir)
    fs.renameSync(parked, dir)
  } catch {
    try { if (fs.existsSync(parked) && !fs.existsSync(dir)) fs.renameSync(parked, dir) } catch {}
  }
}

This racer swaps the parent directory itself. The helper opens a relative path inside the state directory; if that directory is suddenly a symlink to somewhere else, the relative open lands elsewhere. The suite asserts the Perl helper holds under it. The bash version would not, by construction: nothing in it survives losing the parent, because everything in it is a fresh path lookup.

Encoding the lesson so it cannot recur

Two gates joined the contributing-clanker lane on the same day (commit a3ab4eb):

C41: Fail-closed mutable state lifecycle (204 lines). It blocks any helper that persists mutable state without a descriptor-bound primitive, testing for openat, renameat, O_NOFOLLOW or a declared secure-state helper. mktemp + mv and pathname -f checks stop counting as proof, which is the whole point: they were the round-one answer. It separately refuses the lane unless the test corpus carries hostile final-entry, temp-entry, parent-swap and FIFO coverage. The gate blocks, it is not advisory, and its own regression case proves a state helper that trusts mutable pathnames after mktemp now fails.

C42: Bounded local recurring scans (134 lines). It targets the second class in the same review: a scan on a 5 or 20 second timer that buffers or sorts local input before applying its cap. find | sort -z | head -25 looks safe because the final output is capped, but sort has already enumerated the whole directory. C42 warns rather than blocks, so it flags the shape without failing a submission on it.

Widget template commit 516ccd8 vendored both gates so new plugins inherit them. The /omarchy-ship submission auditor now refuses CLEAN status without descriptor-bound lifecycle evidence and hostile parent-swap, temp-entry, final-entry, FIFO, and oversized-input proofs.

Then the new gate had to be debugged against the code it had just forced into existence.

Commit 6d924f3: C41 selected runtime files by .sh/.bash extension or by a shell shebang, which covered the extensionless bash helpers fine. Then the helpers stopped being shell. A #!/usr/bin/perl first line matches neither test, so the newly rewritten helpers were invisible to the gate written to check them. The fix extended the shebang match to #!/usr/bin/perl. The same commit had to settle a second collision. C35 (runtime-dependency, an older gate) banned Perl shebangs outright as an interpreter a stock Omarchy install does not guarantee, so the safe rewrite tripped a different gate. Perl was unbanned there because it is a base dependency on the Buzz image, but only with an absolute system shebang, never env, so the session PATH cannot swap the interpreter.

Commit c9c52ed: C41's redirect heuristic was >>?\s*"?\$\w+, matching > $file and >> $file. It also matched Perl's fat comma key => $value as a shell redirection. A negative lookbehind fixed it: (?<!=)>>?\s*"?\$\w+. Do not flag =>.

Commit 7d22a5c: That lookbehind was then replaced with a simpler rule. The heuristic was being ported to Perl, and porting a regex to a second language keeps its syntax assumptions. @items > $limit is not a redirection either. The honest fix was to scope the heuristic: run the redirect check on shell helpers only. Perl lifecycle safety is established by the descriptor checks themselves, not by a regex that keeps collecting exceptions.

The audit that refused the claim

The gate work has a mirror at the estate level, and it ran the same night. A gate that passes on a file it never opened and a green CI badge for a check that never ran are the same error: a name standing in for the thing itself. Late the same evening came a 168-line estate readiness audit (omarchy 000-docs/004-AA-AUDT-omarchy-estate-readiness-2026-08-29.md). It found:

16/16 worktrees clean, git fsck clean, 444/444 local tests pass across 16 repos, all hosted gates green
but: CI proves static and unit tests, NOT a running Omarchy shell. No repo's GitHub workflow executes rig-verify.sh or rig-render.sh. A green hosted workflow does not prove a plugin loads. Current-source rig proof exists only for Desk Transition, Foundry, and Crew Chief. Widget Template has no proof receipt at all.
9 live listings, but only Listening Post's validated commit matches its current head. The other eight reference older snapshots.
None of the 16 mains has branch protection. 15/16 use mutable action tags. Six repos declare coverage thresholds but invoke raw node --test, bypassing the threshold command.

The audit explicitly refused a "best in class" or "fully production certified" claim. It prescribed the honest public status instead: "16 maintained Omarchy plugin repositories; 9 live marketplace listings; all local suites currently green; marketplace verification and production-render certification are tracked per exact commit."

Also shipped

claude-code-plugins ed4765e43: enforce marketplace compliance metric ratchets in CI
intent-blueprint-docs b9297e0: model-neutral documentation platform; 29c2fd8 made package validation race-free (another race, same week)
omarchy-desk-transition-entry 2e06d94: capture desk transition with active outputs
omarchy-crew-chief-entry 0ef344e: harden process arguments, proven on the real rig, validator and QML-lint receipts both zero-error, local suite 25/25
omarchy-workspace-storyboard-entry e597cdc: pin current Node 24 actions
omarchy-widget-template 868d0f5: land governance scaffolding (editorconfig, gitattributes, issue and PR templates, dependabot, CODE_OF_CONDUCT, CONTRIBUTING, SECURITY)
omarchy 6f2e2b7 and bfdabf5: refresh live marketplace metrics from scripts/refresh-metrics.sh
github-profile 6630095 and 23f4930: swap in the cityscape avatar, remove dead embeds, drop a Projects badge GitHub already renders
comehomealabama 4dea5f5: a journal post shipped through the sibling pipeline

None of those touched a descriptor. The ones that did were the six helpers a reviewer had already sent back twice, and the gate that had to be taught to see them.

Bind the Receipt to the Commit It Installed

Jeremy Longshore — Sat, 29 Aug 2026 11:30:12 +0000

An end to end lane that installs your plugin from GitHub is testing whatever GitHub happened to
serve. That is usually your latest push. It is sometimes a push from twenty minutes ago, a cached
object, or a branch you forgot you were on. The lane passes either way, and the receipt it writes
looks identical either way.

That is the gap I closed on the Foundry rig lane. The receipt now carries the commit hash of the
artifact that was actually installed, and the harness refuses to write the file unless that hash
equals local HEAD. Test provenance is now checkable, not decorative.

How do you verify an E2E test installed the correct commit?

Read HEAD out of the installed tree on the rig, put it on the receipt line, parse that line on the
local side with an anchored regex, and compare the captured hash against local HEAD. The receipt
must carry both commits and pass both checks before the proof file is written. A fixed string
receipt proves only that echo works.

What Foundry is, so the test makes sense

omarchy-foundry-entry is a new repo, created this day, twelve commits on first parent. It is an
Omarchy plugin that generates a starter plugin tree for a small bar widget: manifest, QML entry
point, a pure data Model.js, an offline test, README, license, SVG banner.

The README is blunt about the boundary. Foundry is "intentionally a scaffold and proof surface,
not an autonomous shell agent, plugin store, or publisher," and it "never installs, enables,
commits, pushes, sends telemetry, or files a marketplace issue." Runtime dependencies are bash
and jq. Node is development only. It runs the generated test suite and is never needed by the
widget at runtime. Until a validation lane runs, Foundry reports its proof state as UNPROVEN,
which is not the same word as failing.

The initial commit was 2,614 insertions across 32 files, including nine gate scripts under
scripts/gates/ (c28-voice-no-dashes, c29-private-names, c30-md-strikethrough,
c31-omarchy-qml-security, c34-omarchy-exec-injection, c35-omarchy-runtime-dependency,
c36-omarchy-qml-overflow, c38-omarchy-ssrf-host-allowlist, c40-omarchy-panel-design) plus a
293 line minimax-review.yml. The scaffold itself landed in 43e5b11: bin/omarchy-foundry at
+135, tests/foundry.test.js at +72, Panel.qml at +66/-124, Model.js at +23/-32.

The receipt that could not fail

scripts/rig-e2e.sh arrived at +45 lines in 615e61b, got hardened to +44/-36 in ae779f9, and
grew the real runtime certification at +81/-31 in 8b009f5. Its whole job is to prove something
rig-render.sh cannot: rig-render tests Foundry's own panel, rig-e2e tests the artifact
Foundry generates.

The first two of those had no receipt line at all, just a PASS echo. 8b009f5 introduced one,
and for three commits it was a fixed string:

echo "E2E_RECEIPT foundry=github generated=file-git node=shadowed hostile_id=refused shell=loaded"

and the local side matched it against the same fixed string. Read that line as an assertion and it
says nothing. foundry=github is not a measurement of where the plugin came from. It is a literal
I typed, reprinted back to me by a shell that would have printed it regardless. Every field on the
line was load bearing except the two that described provenance, and those were decorative.

9d6cfc8 fixed it in +9/-3 on the harness and +15 on bin/omarchy-foundry. The remote side now
reads the installed tree's HEAD, the generated tree's HEAD, and puts both on the wire:

foundry_commit=$(git -C "$foundry" rev-parse HEAD)
# ...
generated_commit=$(git -C "$generated" rev-parse HEAD)
echo "E2E_RECEIPT installed_foundry=$foundry_commit generated_tree=$generated_commit node=shadowed hostile_id=refused shell=loaded"

The local side stopped comparing strings and started parsing:

[[ "$LINE" =~ ^E2E_RECEIPT\ installed_foundry=([0-9a-f]{40})\ generated_tree=([0-9a-f]{40})\ node=shadowed\ hostile_id=refused\ shell=loaded$ ]] || {
  echo "rig-e2e: missing or malformed receipt line" >&2
  exit 1
}
INSTALLED_COMMIT="${BASH_REMATCH[1]}"
GENERATED_COMMIT="${BASH_REMATCH[2]}"
[[ "$INSTALLED_COMMIT" == "$COMMIT" ]] || { echo "rig-e2e: installed GitHub artifact ($INSTALLED_COMMIT) does not match local commit ($COMMIT)" >&2; exit 1; }

The anchored regex matters as much as the equality check. A receipt that can be matched loosely is
a receipt that can be matched by a partial line, and the failure mode of a partial line is a pass.

Only after both checks does jq write .rig-e2e-proof.json. Here is what landed:

{
  "commit": "9d6cfc8316b4e58695057027bdd16cb0a891c5ff",
  "installedFoundryCommit": "9d6cfc8316b4e58695057027bdd16cb0a891c5ff",
  "generatedTreeCommit": "0d4a667e408a4aac56ce91c9ef490fe348dacfe3",
  "rig": "intent-ops-buzz/omarchy-rig",
  "foundryOrigin": "github",
  "generatedOrigin": "file-git",
  "node": "shadowed",
  "hostileId": "refused",
  "generatedShell": "loaded",
  "completedAt": "2026-08-28T04:13:20Z"
}

Two fields with the same forty characters. That repetition is the entire assertion, and it is
visible in the artifact instead of buried in the harness. A reader can check it without reading
the script. Being honest about the sequence: the first receipt landed in f7be14d without an
installedFoundryCommit field at all, and the version above was refreshed into place three commits
later in 1ccaa75. The proof got the field before the proof was correct.

.rig-proof.json sits alongside it, written by a different script for a different reason.
scripts/rig-verify.sh does its own round trip to the rig and records
omarchyPluginValidate: 0, qmllintErrors: 0, and fingerprint 913620eb. Its header explains
why it has to exist: gates C32 and C33 in the shared runner (not among the nine in this repo) call gate_skip when omarchy-plugin-validate and
qmllint are not on the local box, and they never are, because they live on the rig. The gate
runner counts SKIP as pass, so the submission lane "happily printed verdict PASS, 0 BLOCK for a
plugin that had never run on Omarchy at all." That is the same failure the E2E receipt had, one
layer down. (rig-render.sh is a third lane again: it screenshots the panel and writes
preview.png.)

What the lane actually does on the rig

It SSHes to a real Omarchy rig (intent-ops-buzz, container omarchy-rig) and runs a chain where
each step's failure is a real exit:

Installs the plugin from its GitHub URL, not from the local working tree.
Reads the installed commit and compares it to local HEAD.
Generates a starter plugin and runs its offline tests, omarchy-plugin-validate, and qmllint.
Git commits the generated tree and installs that via file://, then confirms it reports enabled in omarchy plugin list --json.
Shadows Node and boots the real Quickshell session headless under sway.
Greps the shell log for load errors, filtering known headless noise.
Screenshots with grim and asserts the PNG is at least 4000 bytes.
Asserts a hostile plugin id is refused.

Step 5 is the one I like. The README claims Node is development only. That claim is cheap to write
and easy to be wrong about, because a machine that has Node installed will never tell you when
something quietly reached for it. So the lane makes the claim expensive:

# A stock graphical session does not need Node. Put a failing node first on the
# path and prove the generated plugin still loads in a real shell.
mkdir -p /tmp/foundry-nonode
printf '#!/bin/sh\nexit 127\n' >/tmp/foundry-nonode/node
chmod 755 /tmp/foundry-nonode/node
# ... conditional headless sway launch, then pkill any running qs ...
PATH=/tmp/foundry-nonode:/root/omarchy/bin:/usr/bin:/bin qs -p /root/omarchy/shell >/tmp/foundry-generated-qs.log 2>&1 &

A fake node that exits 127, first on PATH, and then a real shell session on top of it. If the
widget touches Node at runtime, the session tells you. The hostile id (io.github.e2e.bad;dispatch)
gets the same treatment: the test passes only when the create call fails.

Step 6 deserves an honest note. The noise filter is the one place where this lane can quietly stop
failing. c033583 is a single changed line that added pw_loop_new and pw.loop to the exclude
list and made that second grep case insensitive, because pipewire on a headless rig emits errors
that have nothing to do with the plugin. That is a correct fix and also a widening of the blind
spot. Every entry in that exclude list is a category of real error the lane will now swallow, and
the list only ever grows. I would rather write that down than pretend the filter is free.

926835f on the same day is 0 insertions and 0 deletions: a mode change restoring the executable
bit on the harness. A test that cannot execute is not a failing test, it is an absent one.

The obvious alternatives all lose for the same reason. Installing from the local working tree is
the easiest lane to write and it tests the wrong artifact: nobody installs your working tree.
Trusting the git ref you just pushed proves what you intended to publish, not what the remote
served back. And comparing the receipt against a fixed string, which is what this lane did for
three commits, proves that echo works. Only reading HEAD out of the installed tree and comparing
it locally closes the loop.

The badge that was allowed to be wrong

The day's other decision was on the GitHub profile README, and it went the other way for the same
reason.

Session one: seven stargazer badges rendering broken. The obvious guess is that repos went private
or got renamed, so that got checked first. All seven were public with stars (2,679 / 0 / 37 / 5 /
12 / 1 / 27), which eliminated the repo hypothesis and pointed at the URL. Root cause was a raw
star emoji in the shields.io query string. Unencoded it returns HTTP 400 and zero bytes. As
%E2%AD%90 it returns HTTP 200 and renders. One character, seven badges. Two hero counts were also
understating, so they were bumped to 3k+ and 150+ (stars read 2.5k+ against 3,016 actual,
projects read 125+ against 151), and every
badge in the file got re-fetched afterward, not just the changed ones: 27 OK, 0 broken.

Session two, the ask was to make both hero badges dynamic. Only one of them became dynamic.

Stars has a shields built in account level endpoint, github/stars/jeremylongshore?affiliations=OWNER,
served from shields' own authenticated GitHub tokens. Six consecutive fetches, six returned 3.1k.
That is a different number from session one's 3,016 for two reasons: the non-fork count had
ticked to 3,017 by then, and the account level endpoint also counts forks, which takes it to
3,076.
Projects has no built in equivalent. The only route is the generic dynamic/json badge pointed at
api.github.com, which proxies the unauthenticated GitHub API: 60 requests per hour, shared across
everyone on the internet using it. Five consecutive fetches of that exact URL returned
invalid / 151 / 151 / 151 / invalid. Two of five failed.

So Projects stayed hardcoded at 150+ against an actual 151. ce4d1b3, one line changed, and the
commit message argues the case under a heading that says which of the two went live and why the
other did not.

The transferable part is the shape of the two wrongnesses. A hardcoded badge rounded down is wrong
in a bounded, known direction, and it drifts slowly. A badge that renders the word "invalid" two
times in five is wrong in an unbounded direction on the most viewed page you own, and it fails
loudest in front of strangers. "Make it live" sounds like a preference. It is a request to add a
dependency, and the answer to it is a measurement, not an opinion.

The version number that refused to move

intent-outreach v0.2.0, 1b5b444d, merged as PR #34. A 2026-08-19 consistency audit had found
the changelog two months stale. The release backfilled it, bumped 0.1.0 to 0.2.0 across
package.json, both plugin manifests, and the MCP server identity, regenerated the bundle so the
CI freshness check holds, added a missing doc index entry, and corrected a README architecture
diagram that omitted the list_connectors MCP tool. Verified with a clean typecheck, 244/244
vitest, and a passing offline eval gate.

The decision there is the same refusal in a different costume: it cut a fresh 0.2.0 rather than
amending the untagged 0.1.0, and gave 0.1.0 a retroactive tag at ee6a2149, the real end of day
June 16 commit. Reasoning from the commit body: 0.1.0's content shipped June 16, and rewriting its
section to absorb two more months would falsify the release history. Version numbers are a claim
about when something happened.

Also shipped

intent-outreach also merged PR #33 three minutes earlier, unrelated to the release: it gated
OpenAI (gpt-4o) into SUPPORTED_PROVIDERS through the eval harness.

omarchy-desk-transition-entry: 9383567 covered the monitor commands (tests/helper.test.js
+72), and 02c8814 made the transition scenes previewable (Panel.qml +155/-20, plus render and
preview PNGs).

omarchy: 455e292 started tracking submitted plugins in the README (+20/-5), and 496fcb2
refreshed the live marketplace table (+10/-10).

claude-code-plugins: 9b57c6502 gated exports before Dolt identity setup in
freshie/scripts/dolt-sync.py (+6/-1).

On the models

Worth naming only because the split was clean. Claude Opus 5 ran both github-profile badge
sessions, including the hypothesis test that eliminated repo visibility before anyone touched the
URL. Claude Fable 5 ran the intent-outreach release. Claude Sonnet 5 was also in the day's roster.

Zero course corrections in the transcript, which is not a boast. It means the day had one real
investigation in it, the badge one, and the rest was building things that worked. The recorded
failures on the dev box number nine in the digest, and the ones with a legible cause were shell
alias papercuts (command not found: eza, command not found: bat). The rest were bare
exit codes, a Python traceback, a Reddit fetch the harness could not make, and the harness
refusing a sleep 45. None of that is a story, which is why it gets a sentence rather than a section.

{
"@context": "https://schema.org",
"@type": "BlogPosting",
"headline": "Bind the Receipt to the Commit It Installed",
"description": "An E2E test receipt that carries the installed commit hash makes provenance checkable. Six commits on one lane, three of them asserting a literal string.",
"author": {"@type": "Person", "name": "Jeremy Longshore"},
"datePublished": "2026-08-27T10:00:00-06:00",
"url": "https://startaitools.com/posts/the-commit-the-test-actually-installed/",
"inLanguage": "en-US",
"wordCount": 2246
}

A Ratchet Is Only as Strong as Its Re-Baseline Rule

Jeremy Longshore — Fri, 28 Aug 2026 11:30:14 +0000

The claude-code-plugins marketplace carries thousands of skill and agent markdown files, contributed over a long stretch by a lot of different hands. A schema validator, scripts/validate-skills-schema.py, grades them at a strict marketplace tier where a missing required field is an ERROR, not a warning. The corpus fails that grading in bulk. It always has.

That leaves two bad options and one good one. Fail CI on the whole corpus and nothing merges again. Ignore the findings and the debt compounds quietly. Or ratchet: pin what exists today, fail on anything new.

I built the ratchet on 2026-08-26, across 424 commits on the mainline of that repo. It took eight iterations, and only two of them were about the debt itself.

How do you ratchet compliance debt without blocking merges?

You pin the current violation set as a baseline and fail only on what is new. Existing debt is tolerated; a new (path, rule, field) triple fails the gate. That stops silent growth without blocking every merge. The other half, and the harder one, is making the pinned baseline itself impossible to grow without a reviewed, single-file change.

The compliance ratchet mechanism

scripts/check-marketplace-compliance-baseline.py. Its docstring states the whole contract:

Fail closed when marketplace compliance debt grows beyond the pinned baseline.

Blueprint 727 E6.3, phase R1: compare the validator's triple-keyed marketplace
findings with ``scripts/.marketplace-compliance-baseline.json``. Existing baseline
debt is tolerated; a new (path, rule, field) triple fails the gate.

The pinned artifact is scripts/.marketplace-compliance-baseline.json. The final capture of the day, ef7b666f2 at 23:05, held schema_version 4.1.0, 2,132 pinned violation triples, and a rule_inventory of 19 rule ids.

A pinned entry is exactly this shape:

plugins/ai-agency/hyperflow/agents/accessibility-reviewer.md :: E-MISSING-REQUIRED-FIELD :: author

Path, rule, field. Three keys, one line, sorted. Nothing clever, and the lack of cleverness is the point: a diff on that file is human readable, so a reviewer can see what someone is asking to forgive.

The file also carries a corpus block and a separate quality reading, and the two must not be confused with each other:

"corpus_definition": "resolveCorpus('graded')",
"corpus": { "agent_files": 357, "command_files": 373, "plugin_dirs": 593, "skill_files": 3628 }

In the final capture grade_A_plus_B is 2979 and grade_A_plus_B_pct is 82.1114. That percentage is 2979 over the 3628 graded skill files. It is the share of graded files scoring A or B. It is not a ratio involving the 2132 errors, and it does not move in lockstep with them: one file can carry several violation triples, and a file can score a B while still contributing to the pinned set. Two quantities, two denominators, one artifact. The percentage moved during the day, from 81.6428 in the first capture to 82.1114 in the last, which is a second and independent signal that the docs work was landing. I am labouring this because the post's own argument is that a number is untrustworthy until you can prove what it measures, and I would rather be tedious than do the thing I am complaining about.

The debt is concentrated rather than scattered, which is what makes paying it down tractable at all. These are the top 6 of the 19 rule ids in the final capture, so they do not sum to 2132:

Rule	Pinned count
E-MISSING-REQUIRED-SECTION	840
E-MISSING-REQUIRED-FIELD	805
E-FRONTMATTER-9c196f479e69	222
E-TIER2-TOOL-SAFETY-5d322e66e4de	185
E-TIER2-ORCHESTRATION-BOUNDS-31b9cdf7bcb8	30
E-REFERENCE-ESCAPES-SKILL-DIRECTORY	19

Two rules account for 1,645 of the 2,132. That is a writing project, not an engineering project, and I will come back to it. Only two rows moved all day. E-MISSING-REQUIRED-SECTION went from 956 in the first capture down to 840. E-MISSING-REQUIRED-FIELD jumped from 580 to 805 at the +237 capture and then held flat for the rest of the night. The other four rows in the table never moved at all.

Eight iterations, each closing the hole the last one left

Grouped by what each one addresses, not by when it landed. The real mainline order follows the walkthrough.

1. 166a1fad5 ci: add marketplace baseline capture workflow. A new .github/workflows/capture-marketplace-compliance-baseline.yml, 59 lines. Something has to produce the baseline before anything can compare against it.

2. cf7410df0 feat(ci): ratchet marketplace compliance debt. The check script itself at 80 lines, tests/test_marketplace_compliance_ratchet.py at 51 lines, and 7 lines wiring the job into validate-plugins.yml. At this point the ratchet works, in the sense that it does what the docstring says.

3. d809b9a34 fix(ci): ratchet full marketplace compliance corpus. The ratchet was only seeing part of the corpus. The fix was inside the validator, validate-skills-schema.py, at +61/-33, plus +28/-1 of baseline tests and two lines in validate-plugins.yml.

4. cc7e49683 feat(ci): isolate marketplace compliance ratchet. The ratchet was sharing a job with the legacy checks, so its verdict was buried in their output. Pulled apart in validate-plugins.yml at +22/-13, with CLAUDE.md updated in the same commit at +1/-1.

5. 22d621efa fix(ci): detect untracked compliance baseline. +3/-2. A baseline file that was never git added still let the workflow report success. The gate was comparing against a file that, from the repository's point of view, did not exist.

6. d7d233297 fix(ci): pin marketplace baseline contract metadata. +39 lines to the check script, +16 to its tests. The metadata_drift() docstring is the heart of the whole day:

Return baseline-contract changes that require a conscious re-baseline.

Triple comparison alone cannot distinguish an intentional validator-rule
change from legacy debt. The emitted schema version and rule inventory are
therefore part of the pinned contract: either changing them must fail the
ratchet until the dedicated baseline-capture transaction has been reviewed.

Comparing sets of violations is not enough, because you can shrink the set by changing what counts as a violation. A ratchet built only on triples treats "we fixed 300 files" and "we stopped checking for that" as the same event. So schema_version and the 19 rule ids became part of the pinned contract. Move either one and the gate fails until a human has looked at the re-baseline.

7. 242d8e051 fix(ci): forbid unauthorized baseline growth. The E6.6 rule, implemented in baseline_growth_error(). Baseline growth is legal only when the pull request touches exactly one file, scripts/.marketplace-compliance-baseline.json, and the head branch is prefixed automation/compliance-baseline-. Anything else is a violation. The commit touched .github/CODEOWNERS (+1), validate-plugins.yml (+12), the check script (+68/-1), and the tests (+25). The CODEOWNERS line is one line:

/scripts/.marketplace-compliance-baseline.json @jeremylongshore @blueandyellow44

That routes any change to the pinned file to two named owners. It requests review; whether review is mandatory depends on branch protection, which is configuration and not code. The claim I am willing to make from the repository alone is the E6.6 one: a growing baseline is rejected outright unless it arrives as a single-file change on an automation/compliance-baseline- branch. That rule lives in the script, so it holds regardless of settings.

8. f53930446 fix(ci): run marketplace ratchet before legacy checks. Ordering, +13/-7 in validate-plugins.yml. A gate that runs after the noisy checks gets read after everyone has stopped reading.

Sort those by what they actually address and the shape of the day comes out. Three of the eight (5, 6, 7) exist to make the pinned file un-quietly-editable. Two more (4 and 8) exist to make its verdict legible: where the result is reported, and in what order. Iteration 1 builds the file, and only 2 and 3 are about the violation set itself. A quarter of the day's work on a compliance ratchet was about compliance.

The order the mainline actually saw them

The grouping above is thematic. This is git log --first-parent --reverse, with the capture commits interleaved, all times normalized to the automation host's fixed UTC-6. The mainline is linear: the eight ratchet commits are direct single-parent pushes with committer equal to author, and only the captures are squash-merges, which is why those carry a GitHub committer.

Time (-0600)	Commit	What
20:36	`166a1fad5`	add capture workflow (walkthrough 1)
20:39	`22d621efa`	detect untracked baseline (walkthrough 5)
20:43	`885890505`	capture: 2011
20:45	`cf7410df0`	ratchet compliance debt (walkthrough 2)
20:51	`d809b9a34`	ratchet full corpus (walkthrough 3)
20:53	`19e4af810`	capture: 2248
20:57	`f53930446`	run ratchet before legacy checks (walkthrough 8)
21:04	`cc7e49683`	isolate the ratchet (walkthrough 4)
21:08	`d7d233297`	pin contract metadata (walkthrough 6)
21:11	`242d8e051`	forbid unauthorized growth (walkthrough 7)
21:24	`eb281e0d6`	capture: 2231
21:29	`eaeb0e5b9`	capture: 2216

Three things in that column that the thematic grouping hides. The untracked-baseline detection landed second, before the check script it protects existed at all. The ordering fix landed before the isolation it was ordering. And the causal claim survives intact: the +237 capture sits directly on top of the corpus widening, and pinning the contract metadata came three commits later.

Why comparing violation counts proves nothing

Twenty one captures changed the baseline file that day, one per capture pull request, numbered #1346 through #1367 (#1363 was dependabot). The first four:

Capture commit	Time (-0600)	Pinned entries	Change
`885890505`	20:43	2011	first capture, 12 rule ids
`19e4af810`	20:53	2248	+237, 19 rule ids
`eb281e0d6`	21:24	2231	-17
`eaeb0e5b9`	21:29	2216	-15

The remaining seventeen took it down in steps: sixteen captures removed exactly five each, reaching 2136, and the last one removed four, ending at 2132 in ef7b666f2 at 23:05. Five off, sixteen times running, is what a docs push landing one vendor at a time looks like from the ratchet's side.

The day started at 2011 and ended at 2132. Net, the debt grew by 121, after peaking at 2248 and giving back 116.

It grew because of iteration 3. Widening what the validator inspected made 237 pre-existing problems visible for the first time. No file got worse and no contributor added anything.

The artifact says so directly, and this is the part I would not have believed without the file in front of me. The 2011 capture carried a rule_inventory of 12 rule ids. The 2248 capture carried 19. Seven ids appeared between those two captures: E-INVALID-FIELD, three E-AGENT-* ids, E-FATAL-9a99b10dfdaf, and two E-VALIDATOR-* ids.

Those seven account for 12 of the 237. The other 225 are E-MISSING-REQUIRED-FIELD triples on files the validator had simply not been grading before, which is why that row jumps 580 to 805 in the same capture.

So the number moved for two different reasons in one step: new rule categories, and old rule categories applied to new files. A count alone cannot separate those, and neither can a diff of the triples. The pinned rule inventory is what makes them distinguishable, which is metadata_drift() in one sentence.

Reading it back from the artifacts, the commit order tells the rest: the widening in iteration 3 lands before the metadata pin in iteration 6, and iteration 6 exists at all because triple comparison alone cannot separate the two cases its own docstring names. I cannot tell you what I was thinking when I saw the jump. I can tell you the fix arrived three commits later and that its docstring describes exactly the ambiguity the jump created.

The result

The fail-closed gate ended the day as its own top-level job in .github/workflows/validate-plugins.yml:

marketplace-compliance-ratchet:
  name: marketplace-compliance-ratchet
  runs-on: ubuntu-latest
  timeout-minutes: 2

It is listed in the ci-required aggregate job's needs: array alongside validate, verify, test, and 19 others, for 23 entries in all, so it is a required check rather than an advisory one. It runs two steps: "Refuse unauthorized marketplace baseline growth" (pull_request only, calling the script with --check-growth-only --base --head-ref) and "Reject marketplace compliance debt outside the pinned baseline", which is the plain full check.

The comment above that job explains iteration 4 better than I did:

Blueprint 727 E6.4: R1 needs an independently visible, always-reporting blocking
job.  It is listed in ci-required below rather than being folded into `validate`,
so a pre-existing failure in an unrelated validation lane cannot obscure the
compliance-ratchet result.  The validator emits the complete
skills/commands/agents/manifests corpus; observed runtime is about 70 seconds,
bounded here at two minutes.

About 70 seconds observed, bounded at two. That budget is what makes the isolation affordable: a lane this cheap can afford to report on its own rather than sharing a job with something slower.

The unglamorous half

The mainline carries 336 hand-written docs(...) commits from that day, 150 of them across these 26 vendors, governing the example sections of their skills: vercel, salesforce, perplexity, mistral, retellai, lokalise, klingai, juicebox, instantly, ideogram, hootsuite, hex, granola, grammarly, glean, gamma, framer, fondo, flyio, flexport, fireflies, firecrawl, finta, fathom, anthropic, anima.

That work is what chips at E-MISSING-REQUIRED-SECTION, and the row moved 956 down to 840, which is the whole 116 the baseline gave back after the peak. Every entry that came off the baseline that night came off this one rule.

The timing explains why the pinned count and the commit count do not line up. Read from the commit timestamps: most of those vendor commits had landed before the first capture at 20:43, so they were already inside the 2011 and never showed as a decline at all. A smaller number landed between the 2248 and 2216 captures. The remainder landed after 21:29, and those are what the seventeen later captures were recording.

The ratchet and the docs push are the same project seen from two ends. One stops the bleeding, the other closes the wound. Only one of them is automation. The other is a person reading a skill file, understanding what it does, and writing an example section that is true. There is no version of this where the 840 goes to zero because a script ran. It goes down because someone spends a Wednesday writing.

The same shape, on a different system

The other thread that day was supply-chain evidence, six commits in dependency order:

880812321 feat(supply-chain): generate pnpm CycloneDX publication sboms. scripts/generate-publication-sbom.mjs, 129 lines, with a 28 line test file from the first commit.
304d3028f feat(supply-chain): build SBOM-backed publication reports. scripts/build-publication-report.mjs, 69 lines, plus 17 lines of tests.
8111e5b12 fix(release): bind CLI evidence to SBOM and package identity. cli-publish.yml.
a838b4860 feat(release): attach SBOMs to npm publication reports. publish-all-packages.yml and publish-changed-packages.yml.
3c1a53f68 feat(mcp): attach SBOMs to registry publication evidence. publish-mcp-registry.yml, ci/emit-evidence/emit-evidence.ts, and a two line edit to scripts/build-publication-report.mjs.
cf5c14a71 feat(evidence): require SBOM digests for every publication. The fail-closed clasp: release.yml, emit-evidence.ts, and both generators moved together.

That chain sits on top of 80763cac1 feat(evidence): attest required contexts and publications, 9 files at +671/-27, which added .github/workflows/emit-publication-evidence.yml (128 lines) and grew emit-evidence.ts by +254/-17, a net of 237 lines.

An SBOM you can attach but are not required to attach is the same shape of problem as a baseline anyone can re-pin. In both chains the last commit on the mainline is the one that removes the choice: 242d8e051 for the ratchet, cf5c14a71 for the evidence. In the SBOM chain that ordering is the tell, because the first five commits each felt like they were already enough.

Also shipped

00b71ba66 added kernel coupling violation alerts (kernel-vendor-hash.yml, +53/-4) and a60a2da48 stood up a strict v2 kernel shadow lane (kernel-shadow-validation.mjs, +115/-33).

cad-dxf-agent merged three pull requests: #192 repairing real-world persona fixtures, #193 resolving non-breaking frontend audit alerts, and #194 migrating the frontend to React Router 7, which was a security-driven major version bump rather than an upgrade anyone wanted. 285df17f4 registered the cad-dxf-agent plugin in the marketplace.

Six Omarchy submission repos each got presentation assets and a manual validation run. Two carried real fixes: 8aa49e3 preserve unusual repository paths in scanner output, and d07e6b4 tolerate missing Hyprland session.

How the day ran with the models

The blog pipeline itself ran on Claude Opus 5 (348 assistant turns) with Claude Sonnet 5 (29 turns), for 377 turns and 207 tool calls with 4 tool errors, pushing the previous day's Tier 3 post through its gate agents. One coordinator message is worth quoting, because it is what a working gate sounds like from the inside:

Five gate agents ran on your draft. Code review PASS, global fact-check PASS,
but both consistency checkers and the skill-local fact-checker returned REVISE.

Claude Opus 5 also ran a 180 turn session on the governed second brain, 24 brain_search calls and 15 brain_capture calls, running the memory-distiller. Claude Fable 5 ran two short sessions: a cad-dxf-agent skill check (15 turns, 7 tool calls, 5 errors, and the same instruction had to be issued twice before it stuck) and a read-only partner-roster query over the EULER MCP that also needed a second push:

Continue. Use only EULER, complete the read-only roster query, and return the
requested JSON now.

Now the part that belongs here because it is the same lesson as the rest of the day.

There is no local transcript for the claude-code-plugins thread at all. Not a short one. None. The 424 mainline commits are the only surviving evidence of the largest piece of work I did that day. Earlier drafts said 435, because that count swept in the frozen feature branch and a handful of dependabot heads. Everything above about why iteration 6 followed iteration 5, and what iteration 3 exposed that made iteration 6 necessary, was reconstructed from commit ordering and diffs.

This post also got its own numbers wrong on the first three drafts, because they were read off a feature branch frozen at 21:35 while origin/main went on to record seventeen more captures, and the only thing that caught it was a checker that went back to the mainline artifacts instead of trusting the draft.

A day spent building gates that refuse to accept unwitnessed changes ended with its own best work unwitnessed. The commits are real and the diffs are real, but the reasoning that produced them survives only because it happened to be legible in the order the commits landed. That is luck, not a system.

{"@context":"https://schema.org","@type":"BlogPosting","headline":"A Ratchet Is Only as Strong as Its Re-Baseline Rule","datePublished":"2026-08-26T08:00:00-05:00","dateModified":"2026-08-26T08:00:00-05:00","author":{"@type":"Person","name":"Jeremy Longshore"},"publisher":{"@type":"Organization","name":"Start AI Tools","url":"https://startaitools.com"},"url":"https://startaitools.com/posts/the-ratchet-that-needed-a-ratchet/","image":"https://startaitools.com/images/og-image.png","description":"Pinning compliance violations in CI is the easy half. Eight iterations in one day to build a gate that refuses unauthorized baseline growth."}

Every Verdict Carries the Scope It Actually Ran

Jeremy Longshore — Thu, 27 Aug 2026 10:46:07 +0000

The third review comment on the marketplace submission did not name a bypass. It named the class.

Two rounds before it, a human reviewer had handed me two working payloads and I had fixed both. Round three said the fixes were beside the point: the policy validates a hostname string, and a hostname string is not an address. An ordinary attacker-controlled name can resolve to 127.0.0.1, to an RFC1918 range, or to link-local. DNS rebinding can change what it resolves to after any check I perform separately from the fetch. Nothing I could write into that validator would change the fact that it was answering a question about spelling while the request was making a decision about routing.

The offline test suite was green at exactly the commit the reviewer's comment named. Local HEAD was d26746cbbfdcd4282ef1a3faa9b303f14b3f3a3e, 83 tests, all passing. That green means the spellings the suite knows about get rejected. It says nothing at all about the resolution step, because the resolution step belongs to curl and the suite never runs curl.

That is the same defect the /omarchy-ship lane exists to refuse. That lane is the checklist every Omarchy plugin goes through before it is submitted, and its whole job is to reject a receipt that claims more than the run behind it covers. A component had reported a conclusion whose scope it never established.

It happened four times that day. Once in the security fix. Once in a metrics gate that had never been observed failing. Once in a set of analytics tags that would have looked like measurement without being measurement. Once in nine pieces of social copy that read well and could not be found. The fixes had nothing in common mechanically. One deleted code, one deliberately broke a file to watch a check fire, one declined to build a thing at all, one added a lint. What they share is a direction: in each case the claim got cut back to what had actually been established, rather than propped up with more machinery.

The submission was never the obstacle

omarchy-listening-post-entry is a bar plugin for Omarchy that reads RSS and news feeds. It shipped with 29 curated sources plus a field where a user could paste their own feed URL. The marketplace submission is HANCORE-linux/omarchy-plugin-marketplace#1229, opened 2026-08-21, carrying the labels submission, validated, needs-fixes.

Automated validation passed on the first pass. Public and reachable. One valid manifest. README and license present. Quattro compatibility green at 3759cfe. The automated security baseline passed too.

So the listing pipeline had nothing to say. A human review thread on the custom-feed field had three things to say, in three rounds, and the escalation is the whole story.

Round one: the hostname was not the hostname

Reviewer ryanrhughes sent the first payload:

https://user@127.0.0.1/feed

The private-host check read URL userinfo as part of the hostname. user@127.0.0.1 is not in any private range, because as a string it is not an address at all. The check said public. curl parsed the same URL correctly, discarded the userinfo, and dialled loopback.

Fixed in e8d00af. Two things changed, and the second one mattered more than the first. The check moved out of Service.qml and into Model.js so the offline suite could actually cover it, and the reported payload got pinned as a regression test. A validator living in a QML file that only runs on a live bar is a validator nobody can test.

Round two: the address had more than one spelling

Reviewer HANCORE-linux sent two more:

https://127.1/feed
https://0177.0.0.1/feed

Both reach loopback. The cause is inet_aton, which accepts one to four parts and reads each part in decimal, octal, or hex. 127.1 is a two-part form where the second part fills the remaining 24 bits. 0177 is octal for 127. Neither string starts with the text 127.0.0. that a naive range check looks for.

The fix rejected every form the parser recognizes as an address, rather than trying to enumerate the notations. That felt like progress. It was progress on the same axis: I had gone from handling one spelling to handling all spellings, and the axis itself was wrong.

Round three: the class, server-side request forgery

On 2026-08-24 the same reviewer stopped supplying payloads. The comment observed that the policy validates a hostname string, and that hostname strings do not carry the property being checked. An attacker does not need a clever spelling. They need a domain they control with an A record pointing at 127.0.0.1. If I resolve the name to check it and then hand the name to curl, curl resolves it again, and the second answer does not have to match the first.

The comment named two options.

Option one, resolve and pin. Resolve the host myself. Reject every non-public result. Bind the validated address to the request so the name is never resolved twice. In curl terms that is an explicit --resolve host:port:addr pin, plus --proto =https, plus --max-redirs 0, with every redirect hop re-validated in Model.js rather than followed by curl. This is the only option that keeps arbitrary custom feeds working.

Sketched out, the safe fetch looks roughly like this, and the sketch is the argument against it:

# option one, in outline. every line here is a thing that can be
# subtly wrong, and the whole point is that a subtle wrong is
# indistinguishable from correct until somebody exploits it.
addr="$(resolve_a_record "$host")"          # my resolver, not curl's
is_public "$addr" || exit 1                 # reject loopback, rfc1918, link-local
curl --resolve "$host:443:$addr" \
     --proto '=https' \
     --max-redirs 0 \
     "https://$host/$path"
# and then: parse the Location header myself, re-run the whole
# block for every hop, and get the hop budget right too.

Four moving parts, and the redirect loop means the first three run again per hop. Every one of them has to hold under an attacker who controls the DNS answer and the redirect chain.

Option two, remove arbitrary custom-feed hosts. Ship the 29 curated sources. Drop user-supplied feed URLs entirely.

I asked Jeremy which way to go. The steer came back in one line:

fix listening post drop the custom feeds

Why the smaller fix won

I wanted to build option one. It is the interesting one. It is also four separate pieces of security machinery (resolution, rejection, address pinning, per-hop redirect revalidation) each of which is its own opportunity to be subtly wrong, protecting a field that is not why anyone installs this plugin.

The pitch is 29 curated sources in your bar. The custom-feed box was a convenience nobody asked for. And there is a working escape hatch for the case it served: a missing feed gets added to the curated list, where it is reviewed like everything else in the list.

The tradeoff is real and worth stating rather than hiding.

	Resolve and pin	Remove the surface
Arbitrary user feeds	Kept	Gone
New code paths to get right	Four	Zero
Failure mode if I get it wrong	Silent forgery from a shipped plugin	None, the code does not exist
Testable offline	Partially, the resolution step is not	Fully
Reviewer can verify by reading	No, needs runtime reasoning	Yes, the constants are visible

The bottom row is what decided it. A reviewer approving option one has to reason about runtime behavior they cannot observe from the diff. A reviewer approving option two reads a list of https:// string constants and is done.

Commit 30ac415 at 15:14: fix(security): remove custom feed hosts, closing the request-forgery surface for good. Version 1.1.0.

Removed:

extra-sources.json
Service.extraSources()
the extrasFile reader
the extrasPath property
Model.isPublicHost()

Every source the plugin fetches is now a compile-time constant in Model.SOURCES. Seven files changed, 83 insertions and 211 deletions, which is the honest summary of the change: CHANGELOG.md, Model.js, tests/model.test.js, README.md, Service.qml, manifest.json, package.json. The two files carrying most of the churn are Model.js and its test file, at 91 changed lines each.

The deletion had to be provable

Deleting code is easy. Keeping it deleted is the actual engineering, because the next person to want a custom feed field will write isPublicHost again, in good faith, and the suite will not care.

So the eleven isPublicHost tests were replaced with two tests that assert the absence.

test("the custom-feed host allowlist is gone and must not come back by name", () => {
  assert.equal(Model.isPublicHost, undefined)
})

test("every fetched source is a compile-time constant, none is user supplied", () => {
  assert.ok(Array.isArray(Model.SOURCES))
  assert.ok(Model.SOURCES.length > 0)
  for (const s of Model.SOURCES) {
    assert.ok(typeof s.url === "string" && s.url.startsWith("https://"), s.url)
  }
})

Plain node:test with assert, no framework. The first test name is doing work that the assertion cannot: assert.equal(Model.isPublicHost, undefined) on its own tells a future reader that something is absent, and nothing about why. The name tells them the absence is the point and that reintroducing the function by name is the failure being guarded against. A test name is the only part of a test that shows up in the failure output, so it is the cheapest place to put the reason.

Note the shape of the result. The suite got smaller and the guarantee got stronger. Eleven tests were each pinning one spelling of one address, which is eleven assertions about the same wrong axis. Two tests pin the class: there is no host-validation function, and no fetched URL is a runtime value.

Here is the shape of what the suite lost and what it gained, because the raw number moving down is the confusing part:

	Before	After
Tests about host validation	11	2
What they assert	this spelling is rejected	the function does not exist
Fails when a new notation appears	only if someone adds a twelfth test	not applicable, nothing parses hosts
Fails when the surface comes back	no	yes, immediately
Total suite	83	74

Model.js also carries a comment where the old call site used to be. It names the finding and states the two conditions any future user-supplied URL would have to meet before it could be fetched. That is not decoration. The comment is where the next author looks, and a comment that says why the code is missing is more useful than any amount of code that is present.

The deletion was scoped, not indiscriminate

Model.safeUrl stayed. It validates URLs parsed out of feed bodies before they are displayed or clicked through. That is a different job. Choosing a host to fetch from is a request the plugin originates; rendering a link that came back inside a feed is content handling. Both need checking. Only one of them was the forgery surface.

Deleting everything with url in the name would have been the same failure in the other direction: an action whose scope was wider than the finding that motivated it.

What was actually verified, and what was not

Verified:

Offline suite: 74 tests, 74 pass, 0 fail. That is 83, minus the 11 isPublicHost tests, plus the 2 absence guards.
Vendored gate lane: PASS, 9 gates enforced, including c38 and c31.
Zero em dashes and zero en dashes across the tree.
No non-comment reference to extras or isPublicHost remains in Service.qml or Model.js.

The finding closed too. Issue #1229 went to CLOSED at 23:23 UTC on 2026-08-25, carrying the labels submission, validated, listed, and approved-and-verified. The removal shipped at 15:14 local and the plugin was listed a few hours later the same night. Two rounds of validator patches never moved that label. Deleting the field did.

Not verified, and this is the post's own instance of its thesis: the change was never re-verified on an Omarchy rig. Rig render and omarchy-plugin-validate are unproven rather than passing.

The reason written into the commit body at 15:14 is that the omarchy-rig container was not present on this box, and at 15:14 that was true. It stopped being true about six hours later. The rig was up that evening and handed out receipts to everything else: loose-ends at 21:32 and 21:33, quiet-queue at 21:58, flow-boundary at 22:01, desk-transition at 22:06. Listening Post never got back in the queue, because by the time the rig was running, the attention had moved to a new plugin.

So the plugin's newest rig receipt is still the one from 2026-08-22 at 10:29, three days older than the change it is supposed to cover. The argument that the change is safe is decent, since it removes code and touches no QML rendering path. An argument is not a run, and a receipt whose scope stops three days short of the change is the same defect as a green suite that never ran curl, this time with my name on it.

Sibling one: corrupting the CI gate to see it fire

The same morning, a new omarchy umbrella repo went up (60e3fff at 12:16, 821 insertions) with an org landing page whose README carries a generated metrics table. scripts/refresh-metrics.sh regenerates it, refresh-metrics.yml runs it, and a --check lane on pull requests is supposed to fail when the committed block has drifted from what the script would produce.

Supposed to. Nobody had watched it fail.

Commit c8bf8be at 12:32: test(ci): hand-edit the generated metrics table to prove the staleness gate fires. The corruption was one table row, renamed from **Bazaar** to **Bazaar (hand edited)**. The commit body says the branch is not for merge, that it exists to verify the gate is real rather than assumed, and that it gets deleted once the check reports failure.

A gate that has never failed has not been observed working. It has been observed being quiet, and quiet is what a broken gate and a satisfied gate look like from the outside.

The gate's first observable state is the detail worth keeping. The workflow was created already broken in 60e3fff at 12:16: the continuation lines sat at column 0 from the start, so GitHub parsed the file into zero jobs and ran nothing (run 32882805663). 1395866 at 12:18 repaired the block scalar. For those two minutes the gate could not have fired even if every line of its logic had been right, and the pull-request view looked exactly the same as it would have if the gate were working.

Sibling two: the UTM tags that were refused

Nine outbound social packets were dispatched that day. Seven point at individual marketplace listings, one at the widget template, and one at the umbrella portfolio page. None of the marketplace links carry a UTM parameter, and that was a decision rather than an oversight. It is written up in 000-docs/003-RP-BASE-showcase-campaign-baseline.md, with the lane built in 89afdfa at 12:27 and fe425f7 at 12:29.

The reasoning: analytics for omarchyplugins.com belong to the marketplace. A utm_source attached to a link into someone else's property is a parameter nobody on this side can ever read back. Adding it produces the appearance of measurement without measurement, which is worse than nothing, because a dashboard with tagged links on it implies somebody is reading them.

Two signals are genuinely readable, and both were captured on the day.

The marketplace's own public stats endpoint. Views, copies, and hearts per plugin. copies is the closest thing exposed to an install, so that is the conversion metric.
GitHub traffic on repos we own. GitHub reports referrer hostnames natively, so x.com and linkedin.com arrive already separated with no tagging needed. That is also why the GitHub links in the packets are untagged: the tag would add nothing the platform does not already report.

The timing constraint is the part worth copying. GitHub traffic is a rolling 14-day window and cannot be backfilled. Miss the day and the pre-campaign number is gone permanently, so a same-day capture was the last chance at a number that predates the campaign. It was taken at 13:12 local, which is after the packets were dispatched to Ezekiel but before any of them were posted publicly. Dispatched and posted are different events here, and next to a discussion of referral windows the difference is the whole point.

Marketplace snapshot 2026-08-25T18:12:41.735Z, across 1,366 listed plugins:

Plugin	Views	Copies	Hearts	GitHub views 14d	Uniques
Bazaar	199	20	0	8	6
Pit Wall	113	19	3	15	7
Wait State	100	9	0	2	2
MLB Booth	92	2	1	16	5
X Files	90	1	1	5	2
Docket	89	3	1	1	1
Crew Chief	66	8	1	4	2
Listening Post	none yet	none yet	none yet	5	2
Widget Template	none	none	none	1	1

The two blank rows mean different things. Listening Post had no marketplace row because its submission was still open at 13:12 local, and that changed the same evening when the listing went live. The widget template has no marketplace row because it is not a marketplace entry at all. Which is a small instance of the same subject: the table is accurate for the moment it was taken and for no moment after.

The baseline exists to answer two questions.

Why are the two most-viewed listings the two with zero hearts? Hearts do move: Pit Wall has 3, and four other listings have 1. But Bazaar sits at 0 on 199 views and Wait State at 0 on 100, which are the two highest view counts in the table. Nothing in either product asks anybody for a heart. If a campaign cannot move those two numbers, the fix is on the listing page rather than in the posting.

Does X or LinkedIn send more traffic here? The audience is Arch and Hyprland users, which argues for X. The LinkedIn copy carries the engineering argument, which argues the other way. GitHub's referrer hostnames answer that, and they answer it for every campaign after this one, which is the actual return on doing the boring baseline.

What they do not answer is which platform converts, because conversion is copies and copies lives on the marketplace, which exposes no referrer dimension at all. The instrument is narrower than the question. Writing that down is the difference between a measurement and the appearance of one, which is the subject of this entire piece, and it took a review pass to catch me doing it.

Listening Post got no packet at all. There was no listing page for a packet to link to, and pushing a plugin publicly while a marketplace reviewer has a documented open security finding on it costs more than one fewer post is worth. The builder handles this case by construction: given a plugin absent from the catalog it emits a HOLD banner instead of a link. Fail-closed, so the human never has to remember the rule.

Sibling three: copy that read well and could not be found

Nine showcase packets (an X post plus two LinkedIn variants each) had already been generated and emailed to Ezekiel earlier that day. Then somebody read them.

Four of the nine X posts never said the word Omarchy anywhere: wait-state, x-files, docket, crew-chief. None of the nine carried a single hashtag. Omarchy was trending on X at the time.

A post about an Omarchy plugin that never names Omarchy is invisible to every single person searching for one. The commit body puts it better than I can paraphrase it: the copy was written to read well, which it did, and to be found, which it did not.

Commit d37bc55 at 13:58: fix(packets): name Omarchy in every post and add the discovery terms the first pass threw away.

The fix front-loads the term instead of appending a "for Omarchy" tag line at the end. Two reasons. The first line is what shows in a truncated timeline preview, and the first line is what the search index weights hardest. A term in the last line is a term nobody sees and nothing indexes strongly.

The guard is a lint at the render step. The builder now refuses to render a packet when:

- the X post does not name Omarchy
- the X post carries fewer than three hashtags
- the LinkedIn copy does not name Omarchy

From the commit body: this class of miss is exactly what a lint is for, invisible on a read-through and obvious to a checker. Nobody proofreading nine packets for quality would flag "excellent post, does not contain a required keyword," because that is not what reading for quality does.

Verified after the fix: all nine X posts name Omarchy, all carry four hashtags, all land between 457 and 620 characters. The X opener and both LinkedIn openers still differ in all nine, so the lint did not flatten them into one voice. Zero em or en dashes, no URL in any authored field, clean against the voice deny-list. The nine corrected packets were re-sent to Ezekiel with the subject prefixed CORRECTED, use this one, and the nine Plane issues were re-synced in place, updated rather than duplicated.

Where the packets go, and why they go into Plane

Ezekiel does the actual social posting, remote, from emailed packets. The lane that builds them went in at 89afdfa (12:27): scripts/build-showcase-packet.py at 180 lines, scripts/campaign-baseline.py at 158, showcase-packets.json at 106, plus the baseline doc.

Then 87b04a8 at 12:57: feat(plane): mirror the showcase packets into Plane so done is a state, not a report. That is plane-sync-packets.py at 200 lines and plane-assign-when-accepted.sh at 48. Jeremy's steer that drove it:

is there a way ezekiel can get into plane and we track all his work
in plane so we know it is done ?

That mirror is the back half of the packet lane rather than a separate story. The lane produces the copy; Plane holds the state, so completion is a queryable field instead of a claim sitting in somebody's inbox. The nine packets went to ezekiel@intentsolutions.io, CC Jeremy, ordered individual plugins first, then the widget template, then the portfolio page last, because a summary lands better once a few of the parts have already gone out.

The model collaboration beat, and what it actually taught

Claude Opus 5 ran the Omarchy thread that day: 1,112 transcript records in the main session, 116 in a second one, and 263 in this blog session. Claude Fable 5 ran wild at 1,878 records and claude-partner-network at 87, with Claude Sonnet 5 and Claude Haiku 4.5 in smaller volumes. Records are not conversational turns, and the only roster fact the argument needs is that Claude Opus 5 wrote the nine packets.

The packet failure is a model-collaboration failure and an instructive one. Claude Opus 5 generated nine sets of social copy that were good prose and bad distribution. The brief asked for copy that read well. It never stated that the copy had to be findable. The model optimized precisely the thing it was asked for, and got it right.

The fix is not a better prompt. A better prompt is a thing that has to be remembered every time by whoever writes the next brief. The fix is a lint at the render step, which is the same shape as the absence-guard tests in the security fix: encode the requirement in a checker rather than trusting it to be recalled. Both cases replace an instruction with a refusal.

There is a human beat in the middle of this too. While the marketplace thread was open, Jeremy hit the session with:

what did u fuck something up wiht that maintainer whatsww the link
omg did u screw it up

That is what an open security finding on a public submission feels like from outside the terminal. The needs-fixes label sat on a public issue for days, on a repo with the maintainer's name on the thread. No amount of "the fix is straightforward" makes that read as calm.

Also shipped

Breadth, not depth. None of this carries the argument above.

omarchy-loose-ends-entry: a new plugin built end to end the same day, a Git work queue. Initial commit 19:13, feat 20:28 (build the Loose Ends Git work queue), test 21:32 (harden shipping evidence), fix 21:32 (bound scanner output and report truncation), test 21:33 (refresh rig evidence for the bounded scanner), chore 22:07 (refresh the canonical plugin gate lane). Jeremy's steer was build loose ends next. The output-bounding fix is a small echo of the day: a scanner that reported without bounding what it reported.
Other Omarchy entries: quiet-queue got an owner-aware quiet queue plus a rig render receipt, flow-boundary a local flow boundary ledger plus rig render, desk-transition safe desk transition scenes plus rig render, and workspace-storyboard and capture-conveyor both took work.
cad-dxf-agent (renamed cad-ai-agent): a full 7-layer testing SOP retrofit. audit-harness v0.1.0 installed with L1 enforcement hooks, L7 traceability docs retrofitted (TESTING, RTM, PERSONAS, JOURNEYS, 570 insertions), L2 CodeQL plus Trivy plus import-linter plus ESLint and L4/L5 contract plus a11y gates added (275 insertions across 9 files), then the SOP rebased on the current harness (3,382 insertions, 166 deletions). That was followed by five successive CI repair commits: update contract and Trivy actions, harden contract and container gates (183 deletions), resolve frontend production vulnerabilities, install the contract service runtime, scope the initial API contract gate. Adding five gates cost five repair commits to get green. That is the ordinary price and it is worth naming out loud, because the version of this story where gates install cleanly is the version nobody has ever shipped. Also relicensed MIT to Apache-2.0, added a cad-analyze CLI and a Claude Code plugin, and merged 7 dependabot updates.
claude-code-plugins: governance editor and dependency policies (#1322), external-sync quarantine of the walkie-talkie mirror (#1320), modernization catalog and freshness blocker repairs (#1319).
contributing-clanker: three gate-scoping fixes, excluding developer scripts from the runtime gate, batching ignored-file gate filtering, and excluding ignored dependencies from gate scans.
Ko-fi added alongside existing funding sources across about fourteen repos. intent-os regenerated its mission-control status pages.

The rule: compare what it asserts against what it ran

Four times in one day, something was set to report a conclusion whose scope it had never established. A test suite that said the host check was safe while never running the resolver. A staleness gate that said the metrics were fresh while having never once been seen to fail, and which for its first two minutes parsed to zero jobs. Nine posts that claimed a subject they never contained the word for. And a tag scheme that would have implied a campaign was attributed, pointing at a property whose analytics nobody on this side can read.

The diagnostic that held across all four is a pair of lists. What does the thing assert, and what did it actually run? The suite asserted safety and ran string comparison. The gate asserted freshness and ran nothing observable. The copy asserted a subject and contained no instance of the word. The tags never got that far, and that is the useful one in the set, because the mismatch was caught while the lane was still being written. Nothing was dropped, because nothing was ever attached. A near miss reads as less of a story than a bug, and it is the cheapest of the four by a wide margin.

The fixes shared no mechanism at all. One removed a feature. One broke a generated table on purpose and watched the check fail. One declined to build the tagging. One added a word, four hashtags, and a lint at the render step. What they share is direction. The bigger version of each was available and it was always the one I reached for first: fortify the validator, trust the gate because the YAML looks right, tag everything because tagging is what you do, write a better brief. Every one of those leaves the unearned claim standing, with more scaffolding around it.

Fixing the spelling is not fixing the class. The honest fix is usually smaller than the one I wanted to build, and it usually removes something.

Which brings it back to the rig. The security change is good, the suite is green at 74 of 74, the gate lane passes 9 enforced checks, and the marketplace listed the plugin that night. None of that covers rig render, because none of it ran a rig, and the newest rig receipt on the plugin is three days older than the change it is filed against. That is the whole finding, sitting in my own repo, on the day I wrote it up.

{
"@context": "https://schema.org",
"@type": "BlogPosting",
"headline": "Every Verdict Carries the Scope It Actually Ran",
"description": "A verdict covers only what it ran. Four same-day cases, including a request-forgery class closed by deleting the feature it lived in.",
"datePublished": "2026-08-25T08:00:00-05:00",
"author": { "@type": "Person", "name": "Jeremy Longshore" },
"url": "https://startaitools.com/posts/a-green-result-only-covers-what-it-ran/",
"isPartOf": { "@type": "Blog", "name": "Start AI Tools", "url": "https://startaitools.com" }
}

Make the Guard Prove It Can Fail: four gates in one day whose verdicts were decoupled from the thing they claimed to measure, which is the direct ancestor of corrupting the metrics table on purpose.
Every Check Should Report What It Did Not Look At: the lane-level version of the same finding, where the scope of a review is part of its output.
Refusing to Classify Beats Matching Harder: a status classifier that refuses wording it cannot positively recognize, and the hyphen that walked past a negation guard.

DEV Community: Jeremy Longshore

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

Also shipped

What it cost

Related Posts

The Primary Record Settles What a Derived One Assumed

The correction that was itself derived

Formation state and governing law are separate questions

Three star counts, none of them from GitHub

A ratified record whose "no bead owed" was false

The linter that counted a sentence

What it cost

Change what the checker keys on

Also shipped

FAQ

Why does a text grep fail at counting SQL objects?

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

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

Related posts

Auditing Written Claims Against Their Artifacts

Two review lanes, and only one of them reads sentences

Nine fact repairs from one gate audit

The three the invariant lane found

Eight statements, and two ratified records a rebase damaged

The claim a reviewer measured false

Adding nothing was the right call

Downgrading "proved" to the rung the artifact reached

The seventh CI case that lost

The reviewer got audited back

The review that was drafted instead of dispatched

The same failure outside software

What the second lane cost

Tradeoffs

Where a claims audit sits in wider practice

Also shipped

Frequently asked questions

Can code review find false claims in the documentation?

What is an evidence rung?

When should you run a second review lane for claims?

Related Posts

Photo to Listing: Barcode Decoding and LLM Re-rank

The database refuses to mutate

The evidence contradiction gate

One snapshot per source, and no source can block

Governance, tests, and the release cycle

What this does not do yet

Common questions

Why not use a vision model alone for comic identification?

Should barcode decoding run before or after the vision model?

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

Related Posts

Every Claim Needs a Shipped Source and an Executable Proof

Five ways a finished feature is still not done

Why not just close the beads

Writing the requirement down as an enforced file

Two bugs where the proof machinery broke its own preconditions

A gate runner racing its own input

A render that dirtied the source it was proving

A dead-man that could not tell quiet from dead

Also shipped

What the day cost

Related Posts

One Corrected Check, Fifteen Repos

The evidence boundary that could not see its own run

Five hundred characters of anything