DEV Community: Jeremy Longshore

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.

Refusing to Classify Beats Matching Harder

Jeremy Longshore — Wed, 26 Aug 2026 10:26:32 +0000

Mission Control is the internal governance dashboard over the Intent Solutions estate. One of its views composes the decision log into a page: one row per governance record, each row carrying a status of ratified, pending, deferred, superseded, or unknown. The composer that produces those rows is ops/decisions-view/compose.py.

The house law for that view is parse-or-UNKNOWN. If the composer cannot read a record's status off the documented convention, the row lands on unknown and says so loudly. Nothing is inferred.

The composer's classifier, the classify_status function, violated that law on its first settlement review, and then violated it again after the fix.

The original bug: substring matching in the status classifier

Here is what the classifier looked like before any of this started.

STATUS_TOKENS = (
    ("SUPERSEDED", "superseded"),
    ("PENDING", "pending"),
    ("DEFER", "deferred"),
    ("RATIFIED", "ratified"),
    ("DECIDED", "ratified"),
)


def classify_status(status_raw):
    upper = status_raw.upper()
    for token, status in STATUS_TOKENS:
        if token in upper:
            return status
    return None

if token in upper is a substring containment test. RATIFIED is a substring of UNRATIFIED. DECIDED is a substring of UNDECIDED. RATIFIED is also a substring of NOT YET RATIFIED.

So three real classes of governance record (UNDECIDED, UNRATIFIED DRAFT, NOT YET RATIFIED) all classified as ratified and rendered the calm green badge. The page reported the exact opposite of what the record said. An independent code review found it during the B7.6 settlement walk and filed it CRITICAL, which is the correct severity: a dashboard that says settled over an unsettled record is worse than a dashboard that is down, because nobody goes and reads the record.

Round 1: word boundaries plus a negation refusal

The round-1 fix was two changes, not one.

First, the tokens became compiled patterns anchored at word boundaries, so containment stopped being the matching rule.

Second, and this is the part that carries the argument, a negation check ran before any positive match and refused classification outright.

NEGATED_STATUS = re.compile(
    r"\b(NOT|NEVER|NO|NON|WITHOUT|UN(?:RATIFIED|DECIDED|APPROVED|SETTLED))\b")
STATUS_TOKENS = (
    (re.compile(r"\bSUPERSEDED\b"), "superseded"),
    (re.compile(r"\bPENDING\b"), "pending"),
    (re.compile(r"\bDEFER"), "deferred"),
    (re.compile(r"\bRATIFIED\b"), "ratified"),
    (re.compile(r"\bDECIDED\b"), "ratified"),
)


def classify_status(status_raw):
    """Returns (status, None) on a classified token, or (None, reason)."""
    upper = status_raw.upper()
    if NEGATED_STATUS.search(upper):
        return None, ("Status wording contains a negation token ...")
    for token, status in STATUS_TOKENS:
        if token.search(upper):
            return status, None
    return None, ("Status text matches no documented mapping token "
                  "(SUPERSEDED/PENDING/DEFER/RATIFIED/DECIDED)")

Note the return type changed from a bare status to a (status, reason) pair. A refusal now has to explain itself, which means the unknown row on the page carries the specific reason it landed there rather than a shrug.

The stated rationale in the commit body was negation refusal over negation classification: UNKNOWN is the only safe landing for wording the mapping does not positively recognize. Two fixtures went in with it (D908 and D909, by their decision IDs) and drills 2, 6, and 7 were extended to cover them.

Three more defects rode along in the same commit, all in the renderer:

Rows missing a required file or title string now hit a clean rc=2 refusal. They used to raise a KeyError traceback, which is a refusal too, just an ugly one that looks like a crash instead of a decision.
The summary can no longer disagree with the rows beneath it. entries_total, the sum of status_counts, and the escalation entries_pending are all cross-checked against what actually rendered. A summary that is computed independently of the rows will eventually drift from them.
esc() escapes backslashes first, so a backslash in the input cannot re-arm a special character that a later escape step introduces. Escaping order is not a style question.

That shipped, and the settlement review re-ran against it.

Round 2: the badge came back through a hyphen

The round-2 review demonstrated a bypass on the same day: UN-RATIFIED and UN DECIDED.

Walk it through the round-1 code. NEGATED_STATUS looks for UNRATIFIED as one word. UN-RATIFIED is not that word. The hyphen is a word boundary, so the negation pattern misses. Then STATUS_TOKENS runs \bRATIFIED\b against UN-RATIFIED, and the boundary between UN- and RATIFIED is a real word boundary, so RATIFIED matches positively.

The green badge came back, and it came back through a negation pattern that only recognized the fused single-word form. Word boundaries are a wall between whole words. They are not a wall between a prefix and the word it negates, and a negation guard whose token list only spells the attached form inherits that gap for free.

Why word boundaries do not block prefixes

A word boundary is a transition between a word character and a non-word character. A hyphen is a non-word character and a space is a non-word character, so UN-RATIFIED and UN RATIFIED both carry a real boundary between the prefix and the token. That means two things at once. The negation pattern, if it only knows UNRATIFIED as a single word, does not match. The positive pattern \bRATIFIED\b then matches cleanly against the right half. Word boundaries are not a defense against a prefix, because the prefix is on the other side of the boundary. The only thing that covers the separated form is a pattern that names the separation.

The round-2 fix widened the negation pattern to recognize the detached prefix form.

NEGATED_STATUS = re.compile(
    r"\b(NOT|NEVER|NO|NON|WITHOUT)\b"
    r"|\bUN[-\s]?(?:RATIFIED|DECIDED|APPROVED|SETTLED|PENDING|DEFERRED|"
    r"SUPERSEDED)\b")

UN[-\s]? covers UNRATIFIED, UN-RATIFIED, and UN RATIFIED in one alternation, and the token list behind it grew to cover the states that round 1 had not enumerated (PENDING, DEFERRED, SUPERSEDED). Two more fixtures went in, numbered by ledger position and decision ID: 110/D910 for the hyphenated form and 111/D911 for the spaced form, and the fixture ledger reached 11 entries with the drill counts now derived from the ledger instead of hardcoded next to it.

Why not just fix the regex harder: refusal ordering against pattern breadth

This is the obvious objection and it deserves a straight answer, because the round-2 fix is a better regex. So what distinguishes it from the round-1 fix, which was also a better regex?

The ordering. Both rounds kept the same structural property: the refusal check runs first and returns unconditionally, and the positive matcher never gets to vote on a string that the negation guard has claimed. Round 1 established that structure. Round 2 only widened the pattern feeding it.

That matters because the failure mode is asymmetric. If the negation pattern is too narrow, a record gets classified wrongly and shows a confident green badge. If the negation pattern is too broad, a record that could have been read lands on unknown with a stated reason, and a human goes and reads it. One of those is a silent lie and the other is visible extra work. Every Safety Gate Has a Failure Direction works the same asymmetry through a set of pull-request gates.

So the choice was an explicit UN[-\s]?TOKEN prefix rather than a standalone \bUN\b negator. A bare UN negator would have been broader still, but it swallows unrelated words that happen to contain or abut UN, and breadth is only free up to the point where it starts refusing records that are perfectly readable. The prefix form covers the demonstrated bypass without reaching past it.

So the precise claim is narrower than "stop using regex" and more useful. Match as hard as you like on the refusal condition, and widen it the moment a bypass is demonstrated. Do not widen the acceptance condition to compensate, and never let it run first. Round 1 and round 2 are both better regexes. What makes them fixes rather than patches is that both of them added breadth on the side where being wrong costs a human ten minutes, not on the side where being wrong prints a false green badge. That ordering is the durable property. The pattern behind it will keep needing edits, and that is fine, because a too narrow refusal fails loudly the next time somebody writes a new negation and a review catches it. The Refusal Nobody Heard is the failure mode on the other side of that bet: a guard that refused correctly and had nothing wired to listen.

Verification, and what did not change

The classifier was probed against every reproduction the round-2 reviewer supplied (UN-RATIFIED DRAFT, UN RATIFIED, Un-Ratified, UN-DECIDED), all resolving to unknown with the negation reason attached. It was also probed against the adversarial cases that must not trip the guard: RE-RATIFIED and NOTWITHSTANDING kept their prior classifications, along with all five live modern records. run-proof.sh ran green with the extended drill.

Live truth was unchanged through the whole episode: 66 records at 3 ratified, 1 deferred, 0 superseded, 1 pending, 61 unknown, escalation unknown. That is the honest framing from the round-1 commit body, and it is worth repeating. The fix changes what a hostile future record could do to the page. It does not change what today's page says. Nobody had actually filed an UN-RATIFIED record yet.

The evidence bundle got refused too

The round-2 audit returned EVIDENCE_INCOMPLETE on a second and completely unrelated ground. The rollback receipt in the evidence bundle named the prior commit, while the bundle README described a future re-rehearsal as already done.

The receipt was rewritten as a ledger of executed rehearsals only. Three entries, each with a recorded tree hash, no future-tense claims. A stale seven-entry fixture count in the slice README got corrected in the same pass.

This is the same defect class as the classifier, one layer up. A document that asserts a rehearsal happened because it was scheduled to happen is inferring past a fact it does not have, exactly like a classifier reporting ratified because RATIFIED appeared somewhere in the string.

The same lesson, from the other direction

The founder-view hardening landed the same day, under spine-bxp.8, and it carries the sharper version of the point.

The schema founder-portfolio-view.v0 went 1.0.0 to 1.1.0. The coverage-present rule now requires a present, nonzero populations.governed as a standalone law, rather than one enforced only transitively through the upstream contract, so an omission upstream can no longer smuggle a coverage claim through. The renderer picked up the backslash-first escaping law at value level across reasons, states, count keys, and observed_at, plus structural validation that cleanly refuses non-dict sections, non-dict payloads, unknown section names, and missing envelope fields at rc=2 instead of a traceback.

The interesting part is what the new drill found. The coverage-present branch had zero drill coverage. Exercising it for the first time exposed a latent CRITICAL: the upstream ownership state governed was outside the view's section enum, which means the founder view would have hard FATALed on the exact day the estate actually became governed.

That bug was scheduled to fire on success. Every test to date passed because the condition it depended on had never been true yet, and the day it became true is the day the dashboard goes down. Undrilled branches do not fail on the schedule you would pick.

The fix widened the enum verbatim rather than mapping governed to ready, because the house law is that upstream state passes through verbatim. Same instinct as the negation guard: do not translate a value you do not own into one you do.

Verification: run-proof.sh green across 13 drill groups, schemas/validate.py green over 72 schemas with 119 valid and 144 invalid fixtures. The regenerated page surfaced the capability matrix as stale-loud at 126 hours, which is honest drift shown rather than suppressed.

Settling the epic

decision-log/065 (D216) closed the lifecycle. B7.1 through B7.6 closed with independent evidence. spine-bxp.7 was formally deferred and never closed, carrying a full re-entry authority chain, which is the difference between deciding not to do something and quietly dropping it. The guardian pass returned APPROVE, and the fact that it ran after the settlement rather than before it was recorded rather than smoothed over.

The final integrated audit ran on merged main and returned EVIDENCE_COMPLETE on three dimensions: no false-green (every dark source renders dark), no disclosure drift (gate clean over 1622 files plus a manual sweep), and cross-view consistency (the B6 producers-absent story identical across views, populations consistent, all provenance lines resolving).

One thing is owed and named in the CHANGELOG rather than buried: the mc:matrix regen. The committed capability-matrix page trails its local state artifact by about two days. That is outside B7 scope and it is written down where the next person will hit it. A page that trails its own state artifact and says so is the document-layer version of the unknown badge, which is the entire point.

Also shipped

One more instance of the same instinct, at a different layer. The claude-code-plugins marketplace finally enforced its own census deadline, a month after that deadline passed. Refusing to list a source that cannot pass the bar is the catalog-level version of refusing to classify a string the mapping cannot read. A whole-catalog quality census on 2026-07-08 put failing sources on a fix-or-removed clock with notify issues filed upstream and a deadline of 2026-07-22. On 2026-08-23, census-watch --enforce re-validated every notified skill at upstream default-branch HEAD using validate-skills-schema.py --marketplace. Clusters still failing had their sources.yaml entries removed (dated NOTE comments left in place), their mirror directories under plugins/ deleted, and their catalog entries removed: 27 source entries across two clusters, numman-ali/n-skills and wondelai/skills, landing as 343 files changed and 72,206 deletions. Re-listing is explicitly welcome once the skills pass the validator.

A cascade of template-stamped pack delistings followed the same procedure: Veeva, Wispr, StackBlitz, and duplicate placeholder skills pulled from the Together pack. Separately, fix(freshie): make stub detection deterministic landed, and the Adobe pack's skill sections were completed rather than removed.

Worth being precise about what is and is not interesting there. The line counts are large because deleting a mirrored catalog is mechanically large. What matters is that a deadline the marketplace published against itself a month and a half earlier was actually enforced against its own inventory, on a re-validation run, with the removal criteria unchanged from the announcement.

Elsewhere: one journal post landed on comehomealabama. A self-updating profile card shipped to the GitHub profile repo and was reverted the same day. The previous day's post dual-published to tonsofskills.com/blog and went into the intent-solutions-landing field notes.

Every Safety Gate Has a Failure Direction works the same asymmetry through a set of shell gates on every pull request: which way a gate falls when it cannot tell is the whole design.

Reject PII at the Source: A Disclosure Gate at Intake applies refusal at the data boundary rather than attempting interpretation downstream.

Software Supply Chain Security After Axios covers the harder version of the same problem: a source that clears every bar you set and is still hostile. The census only bounds the easy case, sources that cannot clear the bar at all.

Every Check Should Report What It Did Not Look At

Jeremy Longshore — Mon, 24 Aug 2026 11:30:12 +0000

Yesterday I wrote about the gate runner that counted SKIP as PASS, and the rig proof receipt that closed it. That is the setup, not today's subject. Today's subject is what happened next. The same defect shape surfaced twice more inside a single day, and the second time it was inside the tooling built to catch it.

58 commits across 11 repos. The interesting part is that three of them are the same bug wearing different clothes.

The review lane that could not review

Seven plugin repos vendor a four lane MiniMax review workflow. Every lane carries the same guard.

jobs:
  review-correctness:
    if: vars.ENABLE_MINIMAX_REVIEW == 'true'
    # three sibling lanes, same condition

If the repository variable is unset, or the API key is absent, the workflow conditional evaluates false and GitHub Actions skips the jobs. A skipped job renders as a grey tick. A reader scanning a pull request sees four ticks in the checks list and concludes the pull request was reviewed. Nothing ran. No model read a line of the diff.

That is precisely the shape I had spent the week digging out of the gate runner, reintroduced in the workflow whose entire job is to catch bad diffs.

Does a skipped GitHub Actions job show as passing

Not literally, but in practice yes. A skipped job renders as a grey tick in the checks list rather than a red X, and a reader scanning the list reads absence of failure as success. GitHub reports the job's real state accurately. The failure is that a human, and a branch protection summary, treat grey and green the same way.

The fix is a status job with no if at all, so it always runs and always reports. When the lanes are off it emits a GitHub warning annotation, and the annotation says the thing plainly: green ticks on this PR do not mean it was reviewed. On a fork pull request it reports a notice instead of a warning, because a fork never receives the repository secret, so skipping there is by design rather than misconfiguration. A warning that fires on every external contribution is a warning people learn to ignore.

Why not just fail the build

The obvious approach is to make the workflow fail when the lanes are disabled. No ambiguity, no annotation to read, a red X that nobody mistakes for a pass.

I did not do that, and the reason is what the lanes are. They are advisory. A maintainer can merge a plugin fix without a model review, and the seven repos deliberately ship with the feature off until someone sets the variable and the key. Failing the build converts an optional feature into a mandatory one by side effect. The next person to hit a red X on a repo that never enabled reviews would not go enable reviews, they would delete the check, and then the disabled state becomes invisible again with an extra step of history behind it.

The requirement was never that the lanes must run. It is that a disabled lane must not be mistakable for a passing one. An always running status job satisfies exactly that requirement and nothing more. Failing the build satisfies a stronger requirement I did not have and do not want.

The fix that shipped a merge conflict

The commit that landed this is titled "stop a disabled review lane from rendering as a passing one." It shipped a merge conflict into .github/workflows/minimax-review.yml and pushed it to main. Six of the seven entry repos carried three conflict markers each.

The workflow no longer parsed. Every run died at 0s, while the gate lane and the test jobs reported success in the same checks list beside it.

Root cause was a rebase where I assumed only the changelog conflicted.

git checkout --ours CHANGELOG.md
git add -A               # staged the workflow WITH its conflict markers
git rebase --continue    # committed them

git add -A does not care whether a file still contains <<<<<<<. It stages what is on disk.

The part worth writing down is not the rebase mistake. It is the verification. I checked the fix had landed by grepping for the string Review lanes status, found a match, and reported the file present and correct. The string was there. It was inside a file that could not parse.

That is a check narrower than the claim it makes. Which is the same defect the broken commit was fixing. The fix for skip renders as green shipped a workflow that renders as nothing at all.

The second verification parses instead of greps.

grep -c '^<<<<<<<\|^=======\|^>>>>>>>' "$f"          # expect 0
python3 -c 'import yaml,sys; yaml.safe_load(open(sys.argv[1]))' "$f"
actionlint "$f"

0 conflict markers, yaml.safe_load succeeds, actionlint reports 0 issues across all six files. A grep answers "does this text appear." Only a parser answers "is this a workflow."

The agent that reports the denominator

In claude-code-plugins I added an agent called omarchy-coverage-reporter.

Every other internal agent in that repo answers "is this correct." None of them answered "what did we actually look at." Five separate incidents in the days before had turned on that second question, so it got its own agent.

It runs the gate lane, the rig checks and the offline tests, then reports the denominator: how many applicable checks exist, and how many executed. The core of it is splitting the single SKIP token into two verdicts that mean opposite things and were previously aggregated together.

Verdict	Condition	What it means
NOT APPLICABLE	Predicate false. No QML in this tree, so a QML gate has nothing to say.	Counts as a pass.
UNPROVEN	Predicate true, checker could not run. Tree has QML, qmllint was unresolvable.	Never a pass.
INCONCLUSIVE	Any UNPROVEN in the set.	Neither pass nor fail. Nobody knows yet.

INCONCLUSIVE is neither failure nor pass. It means nobody knows yet. That is the state the old runner had no way to express, which is why it kept reporting green: given only PASS, FAIL and SKIP, an unresolvable checker has to land somewhere, and SKIP was the least alarming bucket.

The agent has no Write tool and no Edit tool. That constraint is deliberate and it is the design decision I would defend hardest. A reporter that can repair what it measures cannot be trusted about what it measured. If it can fix the qmllint resolution and then report full coverage, the report is a claim about a tree the reporter changed, and no reader can tell which findings were observations and which were consequences of its own edits. Repairs route to omarchy-gate-author. Judgment routes to omarchy-submission-auditor.

I chose a new agent over extending the existing auditor because counting what ran and judging what it means are different jobs. The auditor had already demonstrated the failure mode of merging them: it produced a confident verdict over a corpus it never established. It was not wrong about the files it read. It was wrong about which files there were.

The same principle in two smaller places

Naming these is the point. One fix is a fix. Three places in one day, counting the coverage reporter, is a pattern.

The changelog generator silently dropped any commit subject that was not a conventional commit. It now reports the count and lists examples. Running it surfaced exactly one skipped commit per affected repo, and each one was GitHub's auto generated "Initial commit." Correctly skipped, and now visibly so. The output did not change its behaviour, it changed what it admits.

In omarchy-crew-chief-entry, the spool reader is bounded to the newest 64 files at 4 KB each. It now emits a census line stating how many files exist, not how many it read.

sessions: 63 shown, +338 not shown (401 files, 713 KB)

Under a deliberate 401 file, 713 KB flood, including one 500 KB garbage file, the reader returned 10 KB and the widget rendered 63 live sessions. Before the census line, the parser received well formed chunks, found nothing malformed, and concluded nothing was missing. It would have reported a complete fleet that was short 338 sessions. Every individual piece of that pipeline behaved correctly. The bound was correct, the parse was correct, the report was correct about its input. Nobody was carrying the number 401.

Also shipped

contributing-clanker closed an SSRF that had escaped review twice. Listening Post guarded its curl call with a regex meant to allow only literal IPv4.

/^\d{1,3}(\.\d{1,3}){3}$/   // four decimal parts and nothing else

curl resolves through inet_aton, which accepts one to four parts, reads a leading 0 as octal and 0x as hex. So 127.1, 0177.0.0.1 and 0x7f.1 all fail the regex, get treated as public hostnames, and reach loopback. New gate c38 flags that regex shape in any file that also touches the network, and the fix hint teaches the inversion (allowlist what you accept, then resolve and check the resolved address) rather than adding three more bad patterns to match, because enumerating bad forms is exactly what failed twice.

The changelog security classifier matched on the pattern 'bound ' with a trailing space. That matches "bound the spool read" and misses "bounded read," so a real security fix could file under Fixed and quietly leave the security section of a release note. This one is a plain false negative rather than an instance of the pattern above, since nothing new gets reported, the match just stopped being wrong. Verified both directions: "add a bounded read" now classifies as Security and did not before.

Gate c37, the rig receipt fingerprint, widened to cover every shipped .js rather than just the manifest and QML. These plugins keep parsing, host filters and state handling in a Model.js that QML imports, so the receipt was certifying a tree whose entire behaviour could change underneath it.

Gate c36 now requires a width constraint AND an overflow rule, not either. It had accepted a QML Text as bounded if it declared any one of width, elide or wrapMode. That is wrong on QML semantics: elide with no width constraint is a no op, since elision is computed against element width. The gate's own fix hint already read "elide with a width" while the check accepted elide alone, so the enforcement was looser than the advice it printed.

rig-render.sh landed in omarchy-widget-template. It starts a headless sway on the wlroots backend, installs the plugin into the rig's Omarchy config, launches Quickshell, opens the panel through the plugin's own IPC target, and grabs the frame with grim. Every plugin in the family had been submitted having never been loaded. Static tools cannot see a contract error: Bazaar shipped a PanelWindow where the first party popup is a KeyboardPanel, passed all nine gates and qmllint, and only a running shell said Cannot assign to non-existent property contentHeight.

omarchy-bazaar-entry gained install, installed state and a kind filter. Measured before the change: Okomart 1,148 views and 286 installs, Plugin Manager 209 views and 95 installs at 45 percent conversion, Bazaar 82 views and 11 installs at 13 percent. Install shells out to the first party CLI with an argv array and no shell string, because the repository URL comes from a third party catalog and building a shell string out of it is the exec injection shape gate c34 exists to refuse. The installed state scan keys on the id inside each manifest, never the directory name, because Omarchy installs under the full plugin id while a hand clone is usually a short name, and the rig carried both listening-post and io.github.jeremylongshore.listening-post for the same plugin. Tests caught a version comparison bug: the first version treated a missing segment as smaller than everything, so 1.2.0 read as newer than 1.2, and every up to date plugin on a two segment version would have shown a phantom update badge.

omarchy-pit-wall-entry coloured the Formula 1 standings tables by team. Only the hue comes from the team. Saturation and lightness are fixed at the call site, so Ferrari reads as Ferrari without a hardcoded hex fighting whatever theme the user runs, and unknown or future teams fall through to a stable hue derived from the name instead of collapsing into a single default.

omarchy-wait-state-entry shipped a PSI monitor.

Per repo commit counts: omarchy-pit-wall-entry 8, omarchy-bazaar-entry 7, omarchy-crew-chief-entry 7, omarchy-x-files-entry 7, omarchy-listening-post-entry 6, omarchy-mlb-booth-entry 6, omarchy-docket-entry 6, omarchy-wait-state-entry 4, claude-code-plugins 4, omarchy-widget-template 2, contributing-clanker 1.

Who did what

The claude-code-plugins work ran across seven sessions in two different CLIs: 456 turns, 677 tool calls, 27 errors hit, spanning 1397 minutes. Claude Opus 5 ran the Claude Code side and carried the gate work and the coverage reporter design. GPT-5.6 Sol ran the Codex side, where it built the Wait State plugin and traced a governed-brain startup failure to a config pointing at a cached plugin version 1.1.2 that no longer existed on disk, with only 1.2.0 installed.

The part I did not plan is the one worth keeping. GPT-5.6 Sol spent its later sessions running the coverage reporter role that Claude Opus 5 had authored earlier the same day, as an independent read-only audit, on a tree the authoring model had never seen. It stated the rule back before using it, that the denominator comes from the canonical lane and a skipped applicable check counts as unproven rather than pass, and then it returned a BLOCK on Wait State: install reality unproven, because the repository had no commits and no remote, so the documented clone URL could not be resolved. That is the UNPROVEN verdict doing exactly the job it was written for, on day one, in the hands of a model that did not write it. It also found the freshness checker could only discover canonical gates whose names were already in the local manifest, which is a coverage hole of precisely the kind the agent exists to name.

Claude Fable 5 ran a short intent-os thread. Claude Sonnet 5 was on the blog pipeline thread.

Zero operator course corrections that day, and that deserves one honest sentence rather than a victory lap. It was not a day of being redirected. It was a day of parallel repair on a defect shape that had already been named, which is the easiest kind of day to run unattended and tells you very little about how the system handles a novel problem.

The 27 errors were real and mostly environmental. A shellcheck lint job failed the L2 gate. The rig container answered sh: line 4: python3: command not found. QML threw TypeError: Property 'spoolTruncated' of object [object Object] is not a function while the census line was being wired in. A script call hit bash: scripts/gen-changelog.sh: No such file or directory. The headless rig was missing swaybg. Every one of those was loud. None of them is the category of failure this post is about, which is the quiet kind that reports success.

{
"@context": "https://schema.org",
"@type": "BlogPosting",
"headline": "Every Check Should Report What It Did Not Look At",
"description": "A status job that always runs reports which checks executed and which are unproven, so a skipped GitHub Actions job cannot read as a pass.",
"datePublished": "2026-08-22T08:00:00-05:00",
"author": { "@type": "Person", "name": "Jeremy Longshore" },
"url": "https://startaitools.com/posts/the-lane-that-reviewed-nothing/",
"isPartOf": { "@type": "Blog", "name": "Start AI Tools", "url": "https://startaitools.com" }
}

What a Skipped Check Is Worth in CI

We Told the Auditors to Refute Us

The Gate That Could Not Fail

What a Skipped Check Is Worth in CI

Jeremy Longshore — Sun, 23 Aug 2026 11:30:11 +0000

A gate runner has three verdicts and only two of them are honest. PASS means the check ran and the code was fine. BLOCK means the check ran and the code was not. SKIP means nothing ran at all, and if your aggregator folds SKIP into the pass column, the summary line at the bottom of the run is not reporting on your code. It is reporting on your tooling install.

That is what gate-runner omarchy-submit was doing in contributing-clanker. Two of the gates in the lane call gate_skip when their binary is not resolvable:

c32 shells out to omarchy-plugin-validate
c33 shells out to qmllint

Both of those binaries live on the Omarchy rig. Neither exists on a dev box, and a dev box is where the lane actually runs. So the runner walked the whole set, hit two unresolvable binaries, skipped them, counted the skips as passes, and printed verdict PASS, 0 BLOCK for plugins that had never run on Omarchy at all.

They were being validated by hand every time instead. Which is exactly the "if someone remembers" failure the lane exists to end.

An undesigned skip that greens the aggregate is worse than no gate, because it manufactures confidence.

Seven repos vendor a copy of this lane (omarchy-x-files-entry, omarchy-listening-post-entry, omarchy-docket-entry, omarchy-mlb-booth-entry, omarchy-crew-chief-entry, omarchy-pit-wall-entry, and omarchy-widget-template), so the fix had to be one that copies cleanly. About fifty commits landed across twelve repos on the day, and the plugin repos took between one and eight each.

Why the gate cannot just do the check

The obvious move is to make c32 and c33 reach the rig themselves. Run the container, run the validator, report what it says. No skip, no receipt, no new file format.

The runner enforces a ten second wall clock per gate. A rig round trip does not fit in ten seconds, and raising the ceiling to fit it would mean every gate in the lane now waits on the slowest possible one. Gates that finish in fifty milliseconds would start sharing a budget with a container boot.

So the check moves off the gate and the gate checks the evidence instead. The rig run happens once, deliberately, through scripts/rig-verify.sh, and it leaves a receipt at .rig-proof.json. The new gate c37 reads the receipt.

What the receipt has to prove

A receipt is only worth what it is coupled to. Four properties, each with a reason it exists.

It fingerprints the manifest and every .qml file. Those are precisely what the rig validates. Fingerprinting them means the receipt cannot certify code nobody ran. Change a file, the fingerprint moves, the receipt stops matching.

It records failures rather than omitting them. If the rig run fails, that goes in the receipt as a failure. A receipt that only ever recorded successes would make "the rig said no" and "the rig was never asked" the same observable state, which is the original bug wearing a different hat.

It expires after fourteen days. The rig tracks upstream Omarchy. A proof from six weeks ago is a proof about a platform that has since moved.

It blocks only at submit time. Gating every intermediate save on a rig round trip would teach people to work around the lane, and a lane people route around is not a lane.

Verification, end to end against a real plugin entry: the lane BLOCKED with no receipt present, scripts/rig-verify.sh produced one from an actual run inside the omarchy-rig container, the lane then PASSED at eleven gates (the count before c38 landed later the same day), and editing a single .qml file flipped it straight back to BLOCK.

Widening the fingerprint the same day

The first version of c37 fingerprinted the manifest and the QML. That scope was chosen to match what the rig's two tools read, and that was the wrong reason to choose it.

The receipt does not claim "those two tools were happy." It claims this code was proven to run. These plugins keep their parsing, host filtering, and state handling in a Model.js that QML imports at load. Under the original scope, that entire file could change and the receipt would still match.

Proven concretely: after the SSRF fix landed in Listening Post's Model.js, c37 still returned PASS. The receipt was certifying a tree whose whole behaviour had changed underneath it.

So the fingerprint now covers every shipped .js too, including extension-less executables that previously sat below a maxdepth of 2. The choice was widening the existing fingerprint function rather than adding a second receipt field, because this function and the one inside rig-verify.sh have to agree byte for byte, and a single definition is the only way that stays true over time.

The widened c37 BLOCKs the fixed Listening Post tree until rig-verify.sh is re-run, and PASSes after. The coupling holds in both directions, which is the only version of that test worth running.

The clipped Text nobody could see

Separate gate, same week, and it explains why "the tools are happy" is a weak claim.

A QML Text element with no width, no elide, and no wrapMode lays out on a single line and gets clipped by whatever container holds it. The last words simply vanish.

// lays out on one line, container clips it, tail is gone
Text {
    text: "The spend meter is your friend"
}

qmllint reports zero errors on that. Clipping is valid QML.

I caught this three times by eye and never once by a test. The four plugin entries that existed at the time carry 240 offline tests between them and not one of them exercises a .qml file. It reached a published marketplace preview.png whose footer reads The spend meter is y. Root cause was the widget template's own list row, so it is one defect copied into all four of them.

c36 is the detector. The interesting part is not that it exists, it is how it decides.

The rhyme: enumerating bad forms is the failure mode

c36 shipped twice. The first version enumerated the shapes it knew about and missed the plain form:

text: someProperty

That is how an attacker-controlled GitHub author login reached a row with no width bound on it. The pattern list did not have that pattern.

The second version stops matching shapes. It strips string literals and asks whether any identifier remains. If something computed is going into text, the element needs a width constraint and an overflow rule, full stop.

# `value` is the right hand side of `text:`, captured, not the whole line.
# Strip the string literals out of it and see whether an identifier survives.
residue = re.sub(r'"[^"\\]*(?:\\.[^"\\]*)*"', "", value)
residue = re.sub(r"'[^'\\]*(?:\\.[^'\\]*)*'", "", residue)
bound = bool(re.search(r"[A-Za-z_]\w*", residue))

A pure literal leaves an empty residue and is not flagged as computed. Anything
with a surviving identifier is computed, so its length is not authored, so it
needs a bound. There is a second shape underneath it for the case the first one
does not cover: a string literal long enough to overrun a bar panel on its own,
which the gate puts at more than 40 characters.

Now hold that next to c38, which landed the same day on a completely different problem.

Listening Post guarded a curl call with a host filter:

// four decimal parts, and nothing else
if (/^\d{1,3}(\.\d{1,3}){3}$/.test(host)) { reject(host) }

curl does not resolve addresses that way. It resolves via inet_aton, which accepts one to four parts, reads a leading 0 as octal and a leading 0x as hex. So 127.1, 0177.0.0.1 and 0x7f.1 all sail past a filter that only knows one spelling of loopback, and all three reach loopback. That SSRF escaped human review twice on marketplace submission 1229.

c38 flags that regex shape in any file that also reaches the network. Its fix hint teaches the inversion, which is to allowlist the canonical form, rather than naming three more bad patterns, because enumerating bad forms is precisely what failed twice.

Verified: c38 BLOCKs the pre-fix Listening Post tree at Model.js:257, the exact line the maintainer cited, and PASSes the fixed tree.

Two detectors, two different domains, same failure and same fix. Both broke the first time by listing the bad forms they had seen. Both got fixed by inverting to a structural rule about what a correct form has to contain.

That is a denylist losing to an allowlist, which is not a new idea. What is worth noting is that neither of these started life looking like a security control. One was a layout rule and one was a host filter, and the denylist shape got in through the side door both times, because listing the bad cases you have already seen is simply the obvious way to write a check. The enumeration is the bug, and it does not announce itself as one.

c36 got tightened later the same day for a related reason. The original rule accepted "a width constraint OR an elide", and elide without a width is a no-op in QML, so half the accepted forms did nothing. It now requires a width constraint AND an overflow rule. Blast radius was measured on a scratch copy before applying it: those same four entries and the template still pass.

A detector living inside the tree it scans

Candidate repos vendor the lane. That puts the detectors physically inside the tree they are scanning, and a detector's source necessarily contains examples of the pattern it hunts.

So c34 flagged its own shell-injection example and failed a CI run on a repo whose plugin code was clean.

The fix is one exclusion in the shared gate_tree_files helper (gates no longer scan scripts/gates/**) rather than a patch inside each gate. One exclusion in the shared enumerator covers every gate added later. Patching them one at a time would have covered exactly the gates that existed that afternoon.

The chokepoint that was not one

precheck-hook.sh intercepts gh commands before they run. It covered four of them: issue comment, pr create, pr ready, pr merge.

A marketplace submission is filed with gh issue create.

So the one command that actually submits a plugin to the marketplace bypassed the chokepoint entirely, and running the gate lane before submitting was a choice rather than a gate. That was the last "if someone remembers" step in the chain.

The new guard requires both a lane run and c37's rig receipt, because per the whole first half of this post, a lane run on its own is not evidence. It resolves the plugin tree from the issue body's ### Repository URL line, maps the repo name to ~/000-projects/<name>, runs that repo's vendored run-plugin-gates.sh, then runs c37 from the canonical lane, because c37 is not vendored into any plugin repo.

Posture matches the hook's existing unmatched-candidate path: fail OPEN while the tree is unidentified (warn and allow), fail CLOSED once it is identified. You cannot block on a check you were unable to aim.

Extending this hook beat adding a second one. Two chokepoints on a single action drift apart, and this hook already owns the log and the kill switch.

Two incidental bugs surfaced while testing it, both the same root cause and both worth knowing. A bracket expression written inline in a [[ =~ ]] test takes an escaped octal like \047 literally instead of as a quote character, which silently excluded digits from body-file paths. grep -oE has the identical problem with the identical expression. Same shape of bug, two tools, one afternoon.

The vendored copy that was intact but stale

run-plugin-gates.sh runs a manifest check that proves a vendored copy is intact. It cannot prove canonical has not moved on. Which is exactly the gap that let a stale c36 sit here reporting green.

scripts/check-lane-freshness.sh plus a CI step now fetches canonical and compares hashes. It is wired advisory (continue-on-error), not blocking, because it needs network and a GitHub blip must not fail an unrelated PR.

That is one more case where the stricter option is the worse one. Blocking would be stricter and would be worse: a check that cries wolf is one people learn to ignore, which is how the original drift survived in the first place.

Where the lane sits now

Canonical lane full suite: 71 passed, 0 failed. PR #73 merged, five files, +356/-3. Lane green on four of six plugin repos at the time of the c38 commit; the two findings in crew-chief and pit-wall were pre-existing and reported separately.

What actually changed is narrower than the commit count suggests. The lane can now tell the difference between "checked and fine" and "could not check," it can prove the rig ran against the exact bytes being submitted, its two filter-shaped detectors ask structural questions instead of matching known-bad spellings, and the submission command is finally inside the chokepoint. Claude Opus 5 carried most of the implementation across the day.

Also shipped: claude-code-plugins dual-published a blog post to tonsofskills.com/blog and merged PR #1295 adding two internal Omarchy plugin agents; omarchy-mlb-booth-entry and omarchy-docket-entry moved API credentials to stdin for jq and curl instead of argv; omarchy-x-files-entry corrected a stale test count and some deleted-CLI references in docs; comehomealabama and intent-solutions-landing each took one content commit.

A Closed Epic Is a Claim, Not a Fact

Jeremy Longshore — Sat, 22 Aug 2026 11:30:25 +0000

Closing a bead is a claim. Merging a PR is a claim. Writing an after-action record that says
the gate is wired and green is a claim about a claim. None of those are facts. The only way to
turn a claim into a fact is to execute it again, later, with someone whose job is to prove it
false.

That is what happened to four epics I had already closed. Blueprint 727's Epics 1 through 4 went
out across 2026-08-18 and 2026-08-19: 48 merged pull requests in the #1242 to #1289 span, four
after-action records, four closed parent beads. Signed off. Done. The next morning the directive
was one sentence:

go over the so-called completed epics and beads in detail and make sure the work is really done

"So-called completed" is the whole brief. Not "confirm the work." Not "write a summary." The word
is an accusation, and the right response to an accusation is an adversary, not a reviewer.

So the audit was built as three parallel Explore agents, one per epic cluster, each instructed
to refute rather than confirm. Execute every claimed gate. Read every bead back from the
store. Check main's live CI, not the record's description of it. All of it pinned to a single
verified state: main at a9fb4a9f9, working tree clean, so nothing verified was uncommitted local
work sitting on my box.

They came back with 34 of 37 claims confirmed by execution and three actionable defect classes,
which is the unit the record disposes on: A, B, and C. B covers both of the Epic 1 residual
items, C covers the record drifts. This post is about the three, and then about what I did with
them, because finding a defect is the cheap half. The
expensive half is making that exact defect structurally unable to happen again: a found defect
becomes a gate, and the gate becomes a template.

How do you audit an epic that is already closed?

Brief the auditors to refute rather than confirm, and pin them to one verified state. Three
parallel agents, one per epic cluster, re-executed every claimed gate against main at a9fb4a9f9
instead of reading the closure records. They confirmed 34 of 37 claims by execution and surfaced
three actionable defect classes.

Refute, not confirm, is a different instruction than it sounds

The distinction matters more than it reads. An agent told to "verify the epic is complete" reads
the closure record, sees the gate name, sees main is green, and confirms. Every one of those steps
is a document lookup. The claim and the evidence for the claim come from the same author.

An agent told to refute has to go somewhere else for its evidence. It runs npm run validate:model-id-classifier itself and reads the exit code. It pulls the branch protection
contexts off the API instead of off the README. It asks when a secret was created and compares that
timestamp to when the record asserted the secret was working. That last one is what caught
Finding B, and no amount of reading would ever have surfaced it.

The three auditors got the same shape of brief and different scope:

Epic 4, 14 beads. Verdict 14/14 confirmed, 0 refuted. Every gate executed with exit 0 during the audit: the gitleaks shape gate with its 10 documented exceptions and no blanket allows, the safety ratchet with exact pinned counts, the MCP destructive-policy registry at 14/14 plugins with both refusal tests passing, the denylist gate across the 52 first-party skills that carry a denylist (not the full skill corpus, which is far larger and shows up again in Finding C), the dolt guard suite 6/6, the python suite 55/55. The strongest single proof was that the push leg ran green on a real push to main, verified at step-level conclusions rather than at the badge.
Epics 1 and 2. Closure bodies confirmed. All 12 doc-governance and supply-chain gates exist, are wired through ci-required, and exited 0 live. Two defects in the Epic 1 residual.
Epic 3, 10 claims. 9 confirmed, 1 refuted, and the refuted one was red at HEAD while CI had been reporting green for two days.

I want the 34 in the record as loudly as the 3. A post where an audit only finds damage is a post
that misrepresents the audit. The epics' bodies were real. The gates existed and had teeth. What
the refutation directive bought was not a demolition, it was three specific things that the
confirm-shaped version of this exercise would have walked straight past.

Finding A: a gate whose only drift detector reads untracked state

Epic 3 shipped a model-id classifier gate. It keeps a committed exclusion list of bead handles that
look like model identifiers but are not, so that a real unpinned model handle in the corpus goes
red. The list at schemas/canonical/v0/model-id-exclusions.json held 393 handles. The live census
counted 394.

The missing one was claude-or1m. That is Epic 4's own epic bead.

not ok 4 - the exclusion list stays regenerable from the live beads export
  error: 'live handle claude-or1m missing from the committed exclusion list'

Epic 4 broke Epic 3's gate simply by existing, and nothing caught it for two reasons that stacked.

One: the only assertion that could detect drift self-skips in CI. The census test reads
.beads/issues.jsonl, which is an untracked export. It is present on my box and absent on every CI
checkout, so the test skipped, and a skip is not a failure. Main's green CI carried no signal at all
for that gate.

Two: the gate script never ran. validate:model-id-classifier executed only the test file. It
never invoked scripts/classify-model-ids.mjs, which was a reporting tool that always exited 0.
Two independent design choices, each defensible alone, that together produce a gate with no
reachable path to red in the environment where it is supposed to run. That defect class is not new
here. I wrote it up two days earlier in The Gate That Could Not Fail,
which is the uncomfortable part: I had just published the shape of this bug and still shipped an
instance of it. Knowing a failure mode is not a control. What follows is the control.

This drift class recurs with every new epic bead we create. So the fix targeted the class, not
the instance. Pinning claude-or1m would have taken thirty seconds and bought nothing.

PR #1291 added a census that runs from tracked artifacts alone:

// walk the tracked tree only, so this leg is identical on a CI checkout
// and on a dev box. no untracked export, no skip path.
// pinned is injectable, which is what makes the detection path testable.
export function unpinnedTrackedHandles(pinned = new Set(loadExclusions().protected_handles)) {
  const missing = new Map();                       // prefix -> first "file:line" sighting
  for (const file of trackedTextFiles()) {         // git ls-files, text extensions only
    lines(file).forEach((line, i) => {
      if (!/bead/i.test(line)) return;             // bead-context lines only
      for (const token of line.match(BEAD_ID_SCAN) || []) {
        if (!BEAD_ID.test(token) || MODEL_FAMILY.test(token)) continue;  // claude-opus-5 etc
        if (line.includes(token + '...')) continue;                      // claude-7yz... in prose
        const prefix = token.split('.')[0];
        if (NOT_A_HANDLE.has(prefix) || pinned.has(prefix)) continue;    // claude-code stoplist
        if (!missing.has(prefix)) missing.set(prefix, `${file}:${i + 1}`);
      }
    });
  }
  return missing;
}

The reason this works is a property of our own process rather than of the code: a new epic bead
lands in a tracked after-action record almost immediately, as a line reading
Bead: `claude-<hash>.1`. The handle is in the tracked tree before it is anywhere else CI can
see. So the census now has a real signal from a real file, and the drift goes red where it matters.

The gate also grew the two-step shape its sibling gates already used:

{
  "validate:model-id-classifier": "node --test scripts/classify-model-ids.test.mjs && node scripts/classify-model-ids.mjs --check"
}

The reporting tool became a gate by gaining a --check mode that exits non-zero and names the
offender with a file and line:

Running node scripts/classify-model-ids.mjs --check against the pre-fix list exits 1 and prints a
single model-id-check: FAIL line to stderr. Paraphrased, because the real string carries
punctuation this blog does not print, it says: handle claude-or1m, referenced at
000-docs/791-AA-AACR-epic-4-safety-register.md:8, is missing from
schemas/canonical/v0/model-id-exclusions.json, regenerate from .beads/issues.jsonl.

The failure names the handle, the file, the line, the list it belongs in, and how to regenerate it.
A gate that goes red without telling you which of 394 handles moved is a gate people learn to skip.

Two design decisions inside that PR worth naming, because both had a plausible alternative that
lost.

List invariants assert always, not conditionally. Sorted and unique are properties of the
committed file itself. They have no dependency on any export, so there is no defensible reason for
them to sit behind a skip. Anything that can assert from the tracked tree should assert
unconditionally. That is the general form of Finding A.

KNOWN_HARNESSES moved to scripts/lib/harness-lexicon.mjs. Both the portability gate and the
denylist gate needed the same lexicon. The cheap option was to have one gate import the other. I
chose lib extraction instead, because two gate scripts should not share lifecycles: the moment one
imports the other, changing gate A's internals can turn gate B red for reasons that have nothing to
do with what gate B checks. A gate should depend on data, not on another gate.

A Greptile review on that PR asked a good question: does the scan actually surface real handles, or
does it only prove that a correct pin set passes? Fair, and the answer required a new test that
runs the detection path under an empty pin set and asserts real handles come back. A gate that
has only ever been observed passing is a gate you are trusting on faith.

The best moment in the whole PR: the tripwire caught its own author. The doc comment I wrote to
explain the scan used claude-xxxx.1 as an illustrative example, and the scan flagged it. I had to
reword my own documentation to get my own gate to pass. That is not embarrassing, that is the gate
working on the first live input it ever saw.

Evidence, run against the pre-fix list: --check exits 1 naming claude-or1m at
000-docs/791-AA-AACR-epic-4-safety-register.md:8. Simulated CI checkout with the JSONL removed,
as recorded in #1291's verification at merge time: 5 pass, 1 skip, --check PASS. The file has
grown a case since.

That one remaining skip is the old live-export parity leg, and it still skips without the untracked
JSONL. I left it that way deliberately. The difference is that it is no longer the only detector:
the tracked-tree census and the --check step both run unconditionally on the same checkout, so
the skip now sits behind a leg that cannot skip. A skip is acceptable when something else is
carrying the signal. It was never acceptable as the whole gate.

Finding B: an OR on a credential is a quieter shade of green

The Epic 1 residual shipped a daily npm stats refresh workflow. It had this in it:

token: ${{ secrets.BOT_PR_TOKEN || secrets.GITHUB_TOKEN }}

That reads like resilience. It is the opposite. BOT_PR_TOKEN is a fine-grained PAT whose pull
requests re-trigger required status checks. GITHUB_TOKEN cannot do that: PRs opened by
github-actions[bot] do not fire required status checks. That is documented behavior rather than house
lore: GitHub's own workflow triggering docs
state that events raised with the default GITHUB_TOKEN do not create a new workflow run. So the
fallback path is the zero-checks path.

Token expiry on the first branch does not fail. It silently relocates the pipeline onto a path
where nothing is verified, and every run after that is green because nothing is looking. That
fallback is precisely why the pre-fix scheduled runs had looked healthy.

The auditor then asked the question I would not have thought to ask. When was the secret actually
created? Answer: 87 seconds before the first green run, and that run was a manual dispatch. The
Epic 1 closure record asserted the scheduled trigger was working under the real token at a moment
when the real token had existed for under two minutes and had never been exercised by the schedule
at all.

PR #1292:

- name: Require BOT_PR_TOKEN (no silent fallback)
  env:
    BOT_PR_TOKEN: ${{ secrets.BOT_PR_TOKEN }}
  run: |
    if [ -z "$BOT_PR_TOKEN" ]; then
      echo "::error::BOT_PR_TOKEN is absent or empty (expired, revoked, or never set). [...]"
      exit 1
    fi
    echo "BOT_PR_TOKEN present."

The secret binds through env: and the test reads the shell variable, rather than expanding the
secret expression directly into the script body. That is the small habit worth copying: a secret
interpolated into run: text becomes part of the script, and scripts get echoed in more places
than people expect.

Both token sites lost the fallback. The network fetch steps gained timeout-minutes. And the proof
that was missing got obtained during remediation rather than asserted: the 2026-08-20 00:27 UTC
scheduled run 32317409056 completed success in 30.4 minutes and opened PR #1290 authored by
jeremylongshore via the fine-grained PAT, with ci-required reporting on it. That run fired at
00:27 UTC on the pre-#1292 workflow, more than two hours before #1292 merged at 02:43 UTC, so its
30.4 minutes ran without the timeout that section adds. Hold onto that number. That is one
completed run on the real trigger. A manual dispatch is evidence of the code path. It is not
evidence of the schedule.

The reversal: my corrective timeout broke a healthy pipeline

Proving Finding B produced two corrections to the audit's own findings, which is the part of this
day I would keep if I could only keep one.

The original audit finding described a "~29 minute hang." That was a mischaracterization, and I
wrote the fix against the mischaracterization.

A healthy fetch legitimately takes 25 to 35 minutes. There are 423 candidate packages at four
requests each, roughly 1,700 requests, run strictly serially (concurrency = 1) with a 250ms
inter-request sleep. That sleep is a ceiling of 4 requests per second, not the achieved rate:
the throttle alone accounts for about 7 minutes, and network round-trip time on the remaining
1,700 calls is what fills the other 20-odd. Measured, the pipeline lands near 1 request per second
end to end, and the last six green runs came in between 29 and 35 minutes. The run the auditor saw
as stuck had actually been killed by the next dispatch's concurrency group, mid-normal-run.

That distinction between the configured ceiling and the measured throughput is the whole reason the
first fix was wrong. I read "4 req/s" off the code comment, did the division, got 7 minutes, and
concluded a 10-minute timeout was generous.

So the 10-minute timeout-minutes merged in #1292 was calibrated against the incident instead of
against measured healthy runtime, and it did exactly what a miscalibrated timeout does: it failed a
healthy dispatch. PR #1293 raised timeout-minutes to 45, which still fails fast against the 6 hour job default
while leaving the real distribution room to breathe.

Same PR, second correction, found while reading the fetch code to figure out why it was serial:

// the parameter is an options object. a positional 4 was accepted
// and silently discarded, so concurrency was always 1.
// signature: collectStats(pkgNames, { concurrency = 1, throttleMs = 250 } = {})
await collectStats(names, 4);   // before: the positional 4 was silently discarded
await collectStats(names);      // after: the defaults are the real behavior, so say nothing

The behavior did not change. The honesty did. Code that claims a concurrency of 4 and runs 1 will
eventually cause someone to reason about capacity from a number that was never true.

And a third thing surfaced in the same window: the pipeline could open unmergeable pull requests
by construction. The workflow hardcoded its PR title as a decorated string that predates our
conventional-commit PR-title gate, so commit-scope-check fails every PR the automation opens.
This was observed live on #1290. Title generation now emits
chore(marketplace-site): refresh daily npm download stats.

Three findings on the corrective work for one finding on the original work. Fixing a defect is
itself a change, and changes need the same skepticism the audit applied. Nobody audits the audit's
remediation, which is exactly why it is a good place for defects to hide.

Finding C: dated records drift by design

The third class is record drift, and unlike A and B it is not owned by one epic. It is the
disposition bucket the audit record uses for everything that is wrong in a record rather than in
a gate: two numbers in Epic 2's closure record, a counting basis in an earlier one, and the two
observations Epic 4's auditor filed as designed-behavior rather than defects. One class, several
instances, which is why the headline count is three classes and not three sentences. The
disposition is the part worth transferring.

After-action record 777 states 2 effective authority claimants and 12 canonical-table links. Live
is 3 and 13, because Epic 4's register landed after 777 was written. The pinned test moved with
reality. The dated record did not.

Record 786's "2,700 first-party SKILL.md files" is a file-edit count across duplicated trees:
roughly 1,456 are plugin skills and the rest are curated-mirror copies of the same skills. The
earlier change from 1,454 to 2,700 was a counting-basis change (per-skill to per-file-copy), not a
new round of discoveries. The withdrawal it describes still holds. The number needs a basis note it
never had.

No source edits to dated records. The correction mechanism is an addendum, which is what record
802 is. A dated record is a statement of what was believed true on a date. Silently editing it
destroys the only thing it was for. Pinned tests are the surface that must track reality; records
are the surface that must not.

No epic reopens either. The warden standard we run here: deliverables shipped and verified,
corrections are records, not rework. Reopening four epics because three findings landed would have
turned an audit leg that ran in well under two hours into a week of rework, and taught the team
that closing anything is provisional.

The same principle, applied forward

The audit half of this day was backward-looking. The other half was the same idea pointed at work
that had not shipped yet, and it produced a cleaner demonstration of the ratchet: defect to gate to
template.

Six Omarchy bar-widget repos were built or hardened the same day. Counting only that day's commits:
omarchy-mlb-booth-entry went from initial commit to v1.0.0 in 11, omarchy-pit-wall-entry took 9
(of 13 in the repo's life), omarchy-listening-post-entry 7, omarchy-x-files-entry 6,
omarchy-crew-chief-entry 3. Four of those commits are review-panel remediation by name, including
fix: apply the four-reviewer panel findings before submission on MLB Booth and
fix: address four-reviewer panel findings (2 BLOCK security, 2 BLOCK correctness, taste, idiom)
on Listening Post.

The interesting part is not that a review panel found things. It is that the findings became
permanent gates in contributing-clanker the same day, which means the next person to write a
widget cannot ship those defects at all.

c34: the `--exec` command injection nobody would have guessed

A four-agent security review of the Listening Post and X Files entries caught a remote code
execution class that the existing gate c31 did not cover.

Omarchy dispatches a notification click action by running the --exec value through a login shell:

// excerpt from the Omarchy shell's Commons/Util.qml singleton, call shape only
execDetached(command)  ->  Quickshell.execDetached(["bash", "-lc", command])

So this, in a poller that builds a notification from a feed item (the real line is
bin/listening-post-poll:154 at b8316bb, where the array was still named args):

args.push("--exec", "xdg-open " + it.url)

is command injection the instant a feed-derived or reply-derived URL carries a ;, a $(...), a
backtick, a |, or ${IFS}. The URL is attacker-influenced by definition; it came off a network
feed.

The hardened form single-quotes every interpolated segment:

flags.push("--exec", "xdg-open '" + it.url + "'")

Gate c34 blocks the absence of that wrap: every double-quoted string literal immediately followed
by a + must end in a single quote, and every template-literal ${...} reaching such a call must
be single-quote-wrapped.

The design decision that mattered was file selection. I chose a shebang scan over an
extension-only scan, and the first cut proved why. Filtering by extension silently skipped the
actual vulnerable file, because the real bug lived in bin/<name>-poll, an extensionless node
script. The gate false-passed. The historical regression caught exactly that, which is the whole
argument for testing a gate against the real pre-fix commit rather than against synthetic cases
only.

Evidence: 7 synthetic unit cases green, c34 BLOCKs the real pre-fix commit b8316bb that shipped
the unquoted concat, c34 PASSes the hardened tree, harness 40/40, lane at 37 gates and 0 BLOCK.

c35: the runtime that exists on exactly one machine

This class shipped twice and would have reached real users.

Two entries were built with a Node.js poller CLI spawned by the QML shell. Both worked on the dev
rig. Both passed every other gate. The dev rig carries a system node at /usr/bin/node.

A stock Omarchy install does not. Omarchy installs Node through mise, and mise's shims are exported
only to an interactive shell, never onto the PATH of the graphical session that launches Quickshell. Verified
against a real Omarchy tree: no PATH export in uwsm/env, no profile hook, no environment.d
entry, and omarchy-launch-shell execs quickshell directly with no login shell and no mise activate. Node is part of the optional dev environment, so a base user may have none at all.

The user-visible result is the worst shape a defect can take. The plugin installs cleanly. It
enables cleanly. It then silently never populates. Nothing errors, nothing logs, the widget is
just always empty.

The marketplace-validated pattern from MLB Booth and Pit Wall has no extra runtime at all: fetch
with curl from a QML Process, parse in a plain-JS Model.js on Quickshell's own engine,
persist with FileView { atomicWrites: true }. Every Omarchy box has a shell, curl, and jq.

Gate c35 blocks two shapes:

BLOCK shape 1: a shipped executable whose shebang names an interpreter
               Omarchy does not guarantee
               #!/usr/bin/env node | deno | bun | python* | ruby | perl

BLOCK shape 2: a .qml spawning one as the first element of a Process
               command array (comments stripped before matching)
               command: ["node", root + "/bin/x-files-poll"]

PASS:          bash, sh

The scoping choices are where a gate earns or loses its keep. c35 applies only to trees with a
manifest.json declaring entryPoints, and SKIPs otherwise, so it does not fire on repos that are
not widgets. tests/, test/, docs/, *.md and node_modules/ are exempt, because a node unit
suite never runs on the user's
machine and blocking it would push authors to delete their tests to satisfy a gate.

Evidence: 8 unit cases green, c35 BLOCKs both real pre-fix trees
(omarchy-listening-post-entry@fad97bf, omarchy-x-files-entry@2829b83) and PASSes their node-free
current versions, harness 52/52 (c35's 8 cases plus the regressions and fixtures that landed
alongside them, which is why it is not simply 40 plus 8), [C35] PASS on all five entries, lane at
38 gates and 0 BLOCK.
Both entries were then re-verified with node shadowed by a stub that exits 127, which is the only
honest way to simulate a machine that does not have it.

Those two entries carry commits reading fix!: remove the node runtime dependency, poll from QML instead. That is the same defect c35 now blocks. The fix and the gate landed the same day, and the
ordering is the point: a fix without a gate is a fix for one repo.

The last click: the template

The final piece was omarchy-widget-template, a skeleton carrying the architecture and security
patterns that two shipped entries (Pit Wall and Crew Chief) earned the hard way. A new widget now
starts from a state that already passes the pre-submit gates.

That is the full ratchet:

A defect is found in one repo.
It becomes a gate, tested against the real pre-fix commit, so it cannot recur in any repo.
It becomes a template default, so new work starts past it and the gate never has to fire.

Step 2 without step 3 means every new author meets the gate as a rejection. Step 3 without step 2
means the pattern erodes the first time someone starts from something other than the template.

Tradeoffs

None of this is free, and some of it is arguably not worth it depending on what you are running.

Audit time is real time. Three parallel auditors plus remediation plus the addendum record
consumed most of a working day for work that was already shipped and already paying. If your
closure records are load-bearing for nobody, this is pure cost. Ours are cited by later blueprints
and read by people who were not there, which is what makes a false record expensive later.

A gate is a permanent maintenance obligation. c34 and c35 will need updating every time
Omarchy's runtime story or Quickshell's dispatch changes. The census gate needs its stoplist tended
as our bead vocabulary grows. Thirty-eight gates in a submission lane is thirty-eight things that
can develop their own defects, and the census gate is exactly the proof that a gate can be broken
and quiet.

False positives cost author trust faster than false negatives cost users. The c34 quote-wrap
rule is a syntactic heuristic, not semantic analysis. It will eventually block a correct
construction that happens not to match the shape. c35's manifest.json scoping and tests/
exemption exist to shrink that surface, and they shrink detection too. Every scoping decision is a
false-negative decision wearing different clothes.

The warden standard is a real bet. "Corrections are records, not rework" keeps a team moving,
and it also means an epic can be marked complete while carrying a known correction. That works
because the corrections are discoverable in the addendum. It stops working the moment addenda stop
being read, and nothing in the system enforces that they are.

A template can encode a pattern before it is proven. omarchy-widget-template freezes what two
shipped widgets earned. If either of those patterns turns out to be wrong at ten widgets instead of
two, the template has been quietly propagating the mistake the entire time, and templates are much
harder to un-propagate than gates are to change. I took that bet knowingly: the patterns in it are
the ones that survived a four-agent security panel, not the ones that merely worked.

Adversarial agents are optimizers, and refutation is a target. An agent told to refute will
find something. Two of the three auditors reported honest observations that were designed behavior
rather than defects (a PR-diff gate passing vacuously on push events, a self-disclosed
enforce_admins: false residual), and labeled them as such. That labeling discipline is what keeps
"refute" from degrading into manufactured findings, and it is the thing I would watch closest if I
scaled this pattern up.

Where this sits in the broader picture

Supply-chain review practice converged on the same idea from a different direction. The industry
answer to "is this dependency safe" stopped being "read the attestation" and became "re-execute the
build and compare," because a record produced by the party under review is not independent
evidence. Reproducible builds, in-toto attestations, and provenance verification are all the same
move: do not trust the claim, re-derive it.

Marketplace review is behind that. Most plugin and extension marketplaces still review submissions
by reading them, and most of the interesting defects in this day's work are invisible to reading.
The --exec injection reads as ordinary string concatenation. The absent runtime reads as a normal
shebang. The census self-skip reads as a well-written test. All three are only visible by running
something.

The transferable version, for anyone running gates on their own work:

Every gate needs at least one leg that runs from tracked artifacts alone. If your only drift detector reads untracked state, the gate is blind in the environment it was built for.
A logical OR on a load-bearing credential converts expiry into silent degradation. If the credential matters, its absence is red.
A closure claim about scheduled automation needs one completed run on the real trigger.
Calibrate timeouts against measured healthy runtime. The incident is the worst possible baseline because it is by definition not the normal case.
Test every new gate against the real commit that motivated it, not only against synthetic cases. Synthetic cases pass on a gate that reads the wrong files.

The collaboration

Eight sessions on claude-code-plugins, 463 turns, 1002 tool calls, 51 errors hit, 1429 minutes of
span, run by Claude Fable 5 and Claude Opus 4.8 across the day. Claude Opus 5 ran a separate
profile-card thread, Claude Sonnet 5, Claude Opus 4.8, Grok 4.5, and Claude Sonnet 4.6 covered
other repos.

The audit phase was the strongest argument I have seen for parallel agents doing something a single
session cannot. Three auditors, three scopes, no shared context, reporting at 00:14, 00:15 and
00:19. They had no way to launder one another's assumptions, which is most of the
value: the Epic 3 auditor did not know that Epic 4's bead existed, so it had no reason to excuse
the census failure as expected.

One human course-correction that day, and it was on the widget work rather than the audit:

hold on their is some confusino braves booth has nothing to do with crew cchief that is way
jacked up think about that for a minute then fidx it

Two widget repos had gotten cross-contaminated in the model's working picture, and the fix was not
a code change so much as a re-partition of what belonged to which repo. Worth noting because the
audit and remediation ran the whole way with no steer at all, and the one place a human had to
intervene was where two similar-shaped projects sat side by side. That is where agent context
bleeds, every time.

Also shipped

intent-os took PRs #540 and #541 on mission control: an agent and cohort activity view composed so
that a denied read emits nothing rather than an empty row, plus a settlement fix so nothing in the
receipts ledger can be silently invisible. Same principle as everything above, applied to a
dashboard: absent data has to look absent.

contributing-clanker PR #70 cleared all 21 open Dependabot alerts via npm audit fix plus a
puppeteer 25 major bump, which is the boring dependency work that has to land before the gate PRs
(#71, #72) are reviewable without noise.

A GitHub profile card generator got built in github-profile with Claude Opus 5. The ImageMagick
preview reported overlapping SVG tspan columns that librsvg rendered correctly, so the preview
tool was lying and a faithful renderer had to be found before any preview could be trusted. Your
preview tool is also under test. It also caught its own accuracy bug, counting 103 "public sources"
because the token could see private repositories, corrected to 85 to match the REST count.

DEV Community: Jeremy Longshore

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

The part that actually cost the day

The gate that forced an honesty edit

A watch that could only see page one

Three sessions, one steer

What the day bought

Also shipped

Related Posts

Scope the Guard to What the Job Actually Writes

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

The fix

Why not the obvious approaches

The alarm working is not the system working

The task board that returned HTTP 200 and assigned nobody

The root cause

The correction that shrank the design

The through-line

Also shipped

Related Posts

A Path Is Not Proof of Identity

The defect class: a symlink race in local state

Round one: the rejection

Why not the obvious approach?

Descriptor-bound lifecycles

Proving it with an adversary

Encoding the lesson so it cannot recur

The audit that refused the claim

Also shipped

Related Posts

Bind the Receipt to the Commit It Installed

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

What Foundry is, so the test makes sense

The receipt that could not fail

What the lane actually does on the rig

The badge that was allowed to be wrong

The version number that refused to move

Also shipped

On the models

Related Posts

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

How do you ratchet compliance debt without blocking merges?

The compliance ratchet mechanism

Eight iterations, each closing the hole the last one left

The order the mainline actually saw them

Why comparing violation counts proves nothing

The result

The unglamorous half

The same shape, on a different system

Also shipped

How the day ran with the models

Related posts

Every Verdict Carries the Scope It Actually Ran

The submission was never the obstacle

Round one: the hostname was not the hostname

Round two: the address had more than one spelling

c34: the `--exec` command injection nobody would have guessed