One decision, traced end to end: the I-AUTOSHIP invariant

What this is

This receipt walks a complete chain from a specification claim, through an incident, through a SPEC amendment, through a hardening commit, to a verified live result. Every step is a public artifact. The reader can audit each one.

The incident is small. The chain is the point.

The sequence

Day one: the unstated assumption

On 2026-05-31 the operator finalized version three of the content pipeline SPEC. The SPEC governed how the autoship pipeline produced and shipped daily blog content. It declared invariants for content caps, voice rules, and quality gates. It did not explicitly declare which branch the pipeline should target. The assumption was implicit: the pipeline runs on whatever branch the working tree happens to be on.

That implicit assumption was load-bearing and undeclared. Most failure modes are unstated assumptions.

Day two: the incident

On 2026-06-07 at approximately 05:17 EDT the autoship pipeline fired its daily run. The working tree at that moment was checked out to v2.6-foundation, a feature branch holding in-progress Question Box code. The pipeline ran successfully. It drafted a post, passed every voice and quality gate, committed the post, and pushed to the remote. The commit hash was 425b509.

The post was correctly written, correctly gated, correctly pushed. The deploying platform never built it because the deploying platform builds from main. The post existed in the repository. It was not visible on the live site. A visitor at vibekoded.com on 2026-06-07 saw the previous day's most recent post and nothing new.

The operator surfaced this around 6 PM EDT: "nothing posted today there is no new post on June 7th which is today." A verification task confirmed the post existed on v2.6-foundation but not on main.

Day two: the recovery

The recovery move was to cherry-pick 425b509 onto main as a standalone operation. A dispatched task verified the commit touched only content files (no source code), confirmed clean cherry-pick parents, performed the cherry-pick, verified the author identity matched the platform requirements, and pushed main. The post became live within minutes.

Recovery commit on main: 1618ce6. Same content as 425b509, different hash because cherry-pick creates a new commit. Both visible in the repository history.

The recovery worked because the commits were content-only and the cherry-pick had no conflicts. Had the pipeline run modified source code rather than content, the recovery would have been harder.

Day two: the SPEC amendment

The implicit assumption that broke was now explicit. The operator named the failure mode and ratified a new invariant: I-AUTOSHIP-TARGET-MAIN. The wording: every autoship pipeline stage (research, drafter, SEO, revision, autoship) verifies HEAD on main at entry. Feature-branch state is auto-recovered via stash, checkout main, do the work, checkout original, stash pop. Pipeline never commits content posts to a non-main branch.

The reason clause was attached to the invariant: the deploy platform builds from main, so content shipped to a feature branch is invisible to visitors until merged, which breaks the trust transaction of "post lands, visitor reads."

The SPEC amendment landed in the relevant content pipeline SPEC files within the hour.

Day two: the hardening commit

A dispatched task implemented the invariant. It identified the pipeline's command files, added a STEP 0 to each that verifies HEAD on main and performs the stash-and-restore dance when needed, ran the gate stack, committed with the platform-approved identity, and pushed. The implementation landed on main on 2026-06-08 in the morning. The pipeline command files now begin every run with the branch check.

Day three: the verification

On 2026-06-08 and 2026-06-09 the autoship pipeline ran on its daily schedule. Both runs fired the new STEP 0. Both verified HEAD on main before proceeding. Both produced live posts on the deployment branch within the expected time window. Neither required operator intervention.

The 2026-06-09 post is the most recent verification: it landed on main directly because the pipeline's hardening worked. The post is visible at the time-of-writing.

What this audit trail demonstrates

Three things, in order of importance.

A specification's silence is also a specification. The pipeline SPEC did not say "target main" because the operator never imagined the pipeline would target anything else. The pipeline did not target anything else for weeks. Then one day it did. The unstated assumption was a real assumption, and when it broke, it broke quietly because no gate had been written for it.

The lesson generalizes: assumptions that are not declared are not gated. Every load-bearing decision needs a written invariant, or it will eventually fail in a way that no gate catches because no gate exists for it.

Incidents become invariants. The June 7 failure was not a code bug. It was an architectural gap. The methodology turns architectural gaps into named invariants, which then become enforced rules. The pipeline that produced 425b509 would not produce that same mistake today because the SPEC that governs it now forbids it, and the command files that implement the SPEC now enforce it. The failure mode is closed.

That closing process is auditable. The reader can read the SPEC amendment, find the commit that implements it, run the commit's diff, and verify that the hardening matches the SPEC. The trail is complete.

The fix is faster than the incident. The pipeline ran on the wrong branch at 05:17 EDT on June 7. The operator noticed at approximately 6 PM. The recovery cherry-pick landed within an hour. The SPEC amendment was ratified within hours of that. The hardening commit shipped overnight. The verification happened on the next day's pipeline run, twenty-four hours after the original incident.

That cadence is the methodology working. Detection in hours, recovery in minutes, hardening in the same day, verification on the next cycle. Most production systems do not achieve that cadence on the first iteration. The methodology gets there because the failure mode goes through a written process rather than an ad-hoc patch.

The chain in artifact form

Stage	Artifact	Hash / file
Original SPEC (silent assumption)	SPEC-content-pipeline-v3.md and related	repo at root
Pipeline run on wrong branch	autoship commit	425b509 on v2.6-foundation
Operator detection	conversation log + verify task report	(operator-side)
Recovery cherry-pick to main	platform-targeted cherry-pick	1618ce6 on main
SPEC amendment with new invariant	I-AUTOSHIP-TARGET-MAIN	content-pipeline SPEC files
Hardening implementation	STEP 0 added to pipeline command files	commit on main
Verification run day 1	next-day autoship	live post on main
Verification run day 2	next-next-day autoship	today's post on main

Every row is a real artifact. The reader can find each one in the repository. The chain is end-to-end auditable.

The methodology lesson

A SPEC document is not the work. The chain from SPEC to live result is the work. A SPEC without verification at the end is a wish. A live result without a SPEC at the beginning is luck.

This receipt walks one chain. The methodology produces this shape for every consequential decision. That is the whole claim. The reader can verify it by running their finger down the chain.

Verifiable artifacts

• Pipeline run commits on 2026-06-07 (425b509 on v2.6-foundation) and 2026-06-08 cherry-pick (1618ce6 on main)
• The I-AUTOSHIP-TARGET-MAIN hardening commit on main
• The SPEC files containing the amended invariant
• The 2026-06-08 and 2026-06-09 autoship runs as live posts on the deployment branch
• The daily pipeline state files in the repo's pipeline state directory