Fleet Series 06 — Git Objects as Pipeline Memory

Working notes for a planned episode — an outline, not an article. Details will shift when it gets scripted. Series index: Building the Fleet.

Deep dive on repo-native provenance: gate verdicts, framing decisions, and execution journals stored as git objects — refs and notes — inside the target repo itself.

The hook

Where does the paper trail live when a robot writes your code? Not in a SaaS dashboard that disappears when the vendor pivots. In git. The repo already has a tamper-evident, distributed, content-addressed database bolted to it — the fleet just writes its receipts there.

What the viewer walks away with

• The inventory of git-object types the pipeline uses: notes on commits (leaf provenance on landed worker commits, gate verdicts on the epic tip), dedicated refs (recording the approved framing per epic), and git-bug issues (tasks living in-repo)
• Why git objects and not a database: the provenance travels with every clone, survives forge migrations, diffs and merges like everything else, and needs zero extra infrastructure
• The wave journal as reconstitutable memory: attempt counts and what-landed let a replan pick up where the last run left off (the K-line idea from the Society-of-Mind notes, made operational)
• Adjacent ecosystem: git-bug, git-appraise (review + CI notes), and the emerging git-meta spec — the fleet deliberately rides a git-native wave rather than inventing formats
• The consumer side: sprinkles renders all of it, which is episode 07

Beats

• Open with git log --notes on a worker-landed commit: the verdict is right there, in the terminal, no forge needed
• Tour the object types one by one, each with a real example from a real repo
• The "clone is the backup" argument: delete the forge, clone survives with full provenance
• Honest limits: notes don't push by default, refs need fetch configuration, tooling is young — what the sharp edges actually are

Demo ideas

• Fresh clone of a pipeline-built repo on a machine that's never seen the fleet; recover the entire epic story from git objects alone
• Side-by-side: same commit in plain git CLI vs. rendered in the sprinkles UI

Source material

• The repo-native provenance build: gate verdicts as git notes on the epic tip, leaf provenance notes on landed worker commits, the approved framing recorded in a per-epic provenance ref
• The git-appraise CI-notes mirror and the git-meta spec watch (sprinkles side)
• Society of Mind — a Lens on the Fleet — the K-line/journal framing

Open questions

• How deep into git internals (refs, notes plumbing) before a general audience checks out? Maybe a "git notes in 60 seconds" sidebar
• Coordinate with episode 07 so the two don't double-cover the sprinkles rendering

Borrowed framing — the two-layer spine

The loop-engineering crash course splits persistent loop state into two layers with different lifecycles, and the split maps cleanly onto this episode:

• Progress layer — checkpoints, updated at every run end. Our version is the episode's subject: the wave journal + task status, living in git objects (which is the stronger form of the claim).
• Rules layer — durable lessons, read at every run start, updated when a mistake repeats (their "hill-climbing loop"). Our version is the distillation/K-line side — the per-repo agent-instructions files — though per-target-repo worker lessons aren't systematic yet.
• Two lines worth quoting on screen: "the front of the diary holds lessons; the back holds checkpoints," and "no spine, no loop" — without persisted state every beat restarts identical. Our convergence story (stable task identifiers, journal-aware replans) is the same principle.
• Cost discipline for the rules layer: keep it short — every byte is paid for on every beat.