Timeline

zit update, open, merge and bisect collapsed ApplyError.StateRecordInvalid and ApplyError.Corrupt onto one line, "cannot read repository: repository is corrupt". They are different claims. Corrupt means stored bytes do not match the name they are stored under. StateRecordInvalid means only that a stored artifact was not usable as a check-in state record, which says nothing about integrity.

An intact fossil clone reaches the second routinely: fossil stores and syncs artifacts it declines to crosslink itself. Assembly treats those as fatal while the read verbs skip them, so update accused an undamaged clone of corruption while timeline read the same store fine.

StateRecordInvalid now carries its own reason text, shared across the four verbs so they cannot drift or re-merge. The bisect mapper had a blanket else arm swallowing the whole set into that corruption line; it is now exhaustive over ApplyError.

Diagnostics only: assembly still rejects these artifacts, so update still exits 1 on such a clone. The tolerance fix is separate; the shape that triggers it, an anonymous wiki page with no U card, is pinned. closed check-in: f75dfdfbe7 user: dmestas tags: fix10-update-diag

zit serve rebuilt its whole in-memory snapshot from the log on every request, and classified held-vs-phantom by calling content on every rid, forcing a full inflate of the entire repository per request. A clone cost O(rounds x store) of server work; past a few thousand artifacts one round outran the connection deadline and the server answered nothing at all.

ArtifactStore grows heldCount, the aggregate of the existing non-inflating held predicate, and serve counts with it rather than re-deriving a worse predicate caller-side. ServeCtx caches the snapshot and rebuilds only when a stat shows the append-only log grew, so a commit made alongside a live server is still advertised on the next request.

Reuse needs isolation: the responder interns phantoms and upgrades entries as it answers, and that would change what later rounds serve. A new OverlayStore answers each request over a per-request write overlay, reads falling through, writes confined to the overlay. The persist pass now takes an ArtifactStore.

On 67,499 artifacts: unfixed, no round completes; fixed, one snapshot build then sub-millisecond rounds. check-in: 2874978461 user: dmestas tags: fix9-serve-stall

Harden native Linux filesystem behavior, deterministic repository iteration, update and undo transitions, Fossil smoke-process containment, and the three-platform CI matrix. check-in: be97df0398 user: dmestas tags: trunk, version-0.1.1

The limitations table stopped short of where a reader would look for more detail; it now points at the release notes rather than growing into a second copy of them. The named build steps were missing zig build cov, the kcov coverage report over the test suite. check-in: 7f7828b7d6 user: dmestas tags: trunk, version-0.1.0

The notes named the fossil version smoke passed against, which is a legitimate conformance fact, but then explained CI runner provisioning and told a future editor to reconcile it against a workflow log. That is tooling detail with no place in a document meant to outlive the tooling. The fossil version stands alone as the fact that matters. check-in: 07c840ae4b user: dmestas tags: trunk

The package version and the version the binary prints move from the 0.0.0 development placeholder to 0.1.0, the first tagged release. Both sites carry the same string so the manifest and the running binary never disagree about what this is. check-in: 9e0be2fc75 user: dmestas tags: trunk

The generator only ever emitted strictly increasing, unique modification times, so the equal-second corner -- where two check-ins tie and the name must resolve by DAG ancestry, not hash order -- was covered only by hand-written regression tests. That corner was a real bug once. A new tie mode reuses the previous mtime on a seeded, bounded roll and shapes a reused-mtime check-in as a descendant chain, the exact shape the bug took; the oracle resolves a tie the way production does, by ancestry and then least hash, so a resolver that fell back to hash order is caught. Order comparison is done up to that tie-break, with the two genuinely implementation-defined dimensions skipped under ties and documented. Reverting the real tie-break in a scratch build makes the tie sweep fail where the unique sweep stays green -- proof the simulator now sees the class it was blind to. Default seeds draw no extra entropy, so the existing universe is unchanged. check-in: b354fb5947 user: dmestas tags: trunk

sim/gen.zig emitted strictly-increasing unique mtimes, so the same-second selection tie -- once a real defect, the B1 regression cluster -- was only example-tested, blind to a class that already bit once.

gen.zig gains a tie-permitting mode: a seeded roll reuses the previous mtime, bounded to short runs, and each reused-mtime check-in is shaped as a linear child of the previous one, so an equal-mtime run is a real descendant chain. oracle.zig now computes the documented tie-break in resolveName, tipSlot and openLeafOf -- descendant-before-ancestor over full ancestry, then least artifact hash (repostate.zig ancestryMaximal) -- so a resolution reverting to hash order is caught, not mirrored.

dst.zig runs the tie sweep as additional coverage; the unique sweep is unchanged. Order-independence keeps its total-rule dimensions (leaf set, name resolution) under ties and skips the open-leaf set, whose equal-mtime supersede is implementation-defined (Section 5.3); the Section 6.3 branch representative is first-seen under a tie, checked in the unique sweep only.

Reverting the tie-break to hash order trips the tie sweep at seed 1. closed check-in: c52cc8cc76 user: dmestas tags: h10-ties

Phase 2 only ever proved convergence after the network was fully healed, so a protocol that converges on a perfect wire but livelocks under sustained loss would have passed. A new degraded phase holds a fixed, never-healed drop and duplication rate on both links and drives a fresh session through the same safety, convergence and termination oracles, within a window scaled to the loss rate: a round makes progress only if both its request and reply arrive, so the expected round count grows as one over the delivered-fraction squared, times a safety factor, with the derivation in a recomputable comment. It converges with wide margin -- across many seeds the worst run finished in a small fraction of the window at every rate tested -- so there is no livelock. Pinning the window below the real need trips the oracle, so the check is not vacuous. The gate runs one modest rate; the soak sweeps a range. check-in: b8ef4a68e5 user: dmestas tags: trunk

The loss-scaled convergence window used divCeil with a catch unreachable for the divide-by-zero arm, which the precommit guard flags outside tests. The delivered-percent denominator is provably at least one, so plain integer ceil division gives the same bound with no error union. closed check-in: 0fbc9225bf user: dmestas tags: h7-degraded

zit serve accepts one connection at a time and read its request head and body with no deadline, so a single peer that opened a connection and then dribbled or withheld its request pinned the accept loop and starved every other client -- a real availability gap the in-memory fuzzers could not see, since they never touch the socket. The connection now runs under a whole-connection deadline: the request work races a timed sleep, and a peer that misses the deadline is dropped so the loop moves on. The bind is loopback only and the deadline is generous, so a legitimate request -- even at the reply ceiling -- always finishes far inside it; only a stalled peer is shed. Four end-to-end abuses -- a slow-loris head, a half-sent body, a mid-response disconnect, an idle-connection burst -- each prove the server still answers a fresh request and a real clone still converges, and the fix is shown to be load-bearing by wedging with it removed. A per-read idle timeout and a configurable value are left for later. check-in: 56c17d0675 user: dmestas tags: trunk

The sync sweep proved convergence only after the network fully healed, so a protocol that converges on a perfect wire but livelocks under sustained loss would still pass.

Phase 2b runs a fresh session over a wire held at a fixed drop/dup rate, never healed, asserting the same convergence and termination oracles within a window scaled from the loss rate: expected rounds are the clean window over (1 - p_loss) squared per direction, times a safety factor, recomputed in a comment rather than a magic number. No corruption is injected -- a corrupted body is already a lost round.

The protocol converges comfortably: over 200 seeds the worst run took 7, 13, and 18 rounds at 10, 25, and 40 percent loss, against windows of 160, 228, and 356 -- no livelock. The gate joins at 10 percent; the soak sweeps the wider rate set. Pinning the window below the real need trips the liveness oracle, so the check is not vacuous. The liveness-under-faults discipline follows TigerBeetle's VOPR. check-in: 464b82c888 user: dmestas tags: h7-degraded

zit serve accepts one connection to completion before the next (single-threaded, serve.zig), and receiveHead plus the body read blocked with no deadline. A loopback peer that dribbles a request head, half-sends a body, or connects idle and holds could pin the accept loop forever -- the socket read path the exchange fuzzers never reach, covered before only by happy-path interop.

Add a whole-connection deadline: the request work runs on its own unit of concurrency raced against a timed sleep, and draining the loser cancels the blocked read, freeing the loop. A per-read SO_RCVTIMEO is unusable here (the Io backend treats a socket-timeout EAGAIN as a bug). serve binds 127.0.0.1 only, so a legitimate same-host request finishes in milliseconds even at the 512 MiB body ceiling; the 5 s bound never fires on a real client and only sheds a stalled one.

Four end-to-end scenarios abuse a live server over loopback -- dribbled head, half-sent body, mid-response disconnect, idle-connection burst -- and assert with bounded waits that a fresh request is still answered and a clone still converges (sync 3.7). closed check-in: e87fb840d1 user: dmestas tags: h11-serve-socket

The working tree -- the one place a version-control tool can lose a user's data -- had no crash simulation; only the log store did. A new faulty directory layer tears and freezes writes at a seeded crash point, and a sweep replays an update across every crash cut, reopens, and checks four invariants. Three hold: an untracked file the update must preserve is never touched, a crashed update recovers to its target through the undo journal, and the checkout record never names a check-in whose tree did not finish materializing. The fourth does not, and that is the point of the harness: the payload write lands in place rather than through the write-temp-and-rename the metadata already uses, so a crash mid-write can leave a managed file spliced from old and new bytes -- torn, but recoverable. The gate runs the three that hold; the fourth is pinned by a test asserting the splice IS produced, so it flips the day the write is made atomic. Crash-point enumeration follows TigerBeetle's storage model. check-in: 5401ce245f user: dmestas tags: trunk

Add sim/faulty_dir.zig, a decorator std.Io that cuts a run at a seeded mutating-op boundary the way a power loss does: the crashing write persists at most a torn prefix and every later mutation is a frozen no-op, so the checkout layer's own recovery moves no byte. Crash-point enumeration follows TigerBeetle's storage-fault-injection lineage, ported to the directory surface update.zig and checkout.zig write through.

Add sim/checkout_sweep.zig: it materializes a check-in, replays an A-to-B update.applyCheckin under a crash at every reachable cut, reopens, and asserts unmanaged files are preserved, the checkout record names only a complete target, and the tree recovers to the target via the undo journal. Joins the dst gate per seed at bounded cuts; the soak walks every boundary.

Finding: update.writePayload writes working files in place (createFile truncate, write, sync), not through the atomic write-temp+fsync+rename that checkout.write, the managed set, and the undo journal use. A crash mid-write can leave a file matching neither its pre- nor its post-image. The sweep pins this; a working-tree write-journal is the fix. closed check-in: 0cea021cf9 user: dmestas tags: h2-checkout-dst

The storage and network simulations ran off the same seed but never intersected, so no simulated exchange ever crossed a store that could lose its tail. This composes them: the sync client's content is backed by a real log over a tearable file, and between rounds -- on a seeded coin -- the store is crash-restarted mid-persist, reopened to its recovered prefix, and the session resumed with a fresh client. The existing safety and liveness oracles must survive the composition: no corrupt content accepted, the recovered set never exceeds what was held before the crash, and once both the network and the disk heal a fresh session still converges within the bounded window. Green across the gate and a deep 120-seed run; a retained switch that makes recovery accept a torn frame trips the oracle, so the check is not vacuous. The fault-composition follows TigerBeetle's VOPR. check-in: 9b689ebafe user: dmestas tags: trunk

The sync sweep and the storage sweep ran in disjoint PRNG streams off the same seed and never intersected: no exchange ever ran over a client store that could tear. A partial pull could leave torn frames that recovery accepts but a resumed session never converges past.

runCrashResume backs the client store with a real LogStore over a tearable FaultyFile instead of the pure MemStore, seeded healthy then armed to tear. Between phase-1 rounds, on a seeded coin, it power-cuts the store mid-persist, reopens it, reloads the recovered prefix, and resumes with a fresh Client over the same durable store, mirroring cmd/sync's loadContentStore for wire-name to log-digest identity.

The oracle keeps every existing sync invariant and adds the crash bite: post-recovery contents are a subset of the pre-crash held set, no corrupt frame crosses the boundary, and phase-2 liveness heals both domains before a fresh session converges in the bounded window (sync 3.7). One seeded PRNG stream drives the whole run, so a failure replays from the shared reproduce line.

The composed-fault and liveness-under-faults discipline follows TigerBeetle's VOPR. closed check-in: d2b5f729ef user: dmestas tags: h3-crashsync

Only two targets asserted that their generator still reaches the interesting outcomes; the other 25 could rot to instant-rejection and pass every no-crash check while testing nothing. Six targets that split into distinct outcomes now carry a reached-outcomes floor above a measured minimum round count -- decode-bounded, target-size, predicates, adversarial sync parsers, logstore open, and unframe each must reach both their accept and reject arms, or the run fails. Thresholds are measured at a fixed seed and re-checked at a second, and each floor is proven to trip when the generator is biased to one arm. Single-outcome round-trip targets carry a one-line exemption instead of a vacuous assert. The measurement also named several generators that under-reach their target's arms; those are recorded for follow-up, not fixed here. check-in: 57d8994848 user: dmestas tags: trunk

serve_fuzz already fails a run when its generator stops reaching the dispatch arms it exists to exercise, and merge3 does the same for conflict shapes. Generalize that guard so a generator that has drifted to one outcome can no longer pass every no-crash round while testing nothing on the arm it dropped.

Six targets gain a measured reached-outcomes floor: delta decodeInt and targetSize (a decoded value vs MalformedDelta), artifact predicates (simple-pathname and wiki-name each accepting and rejecting), sync card parsers (push/igot/uvgimme each accepting and rejecting), logstore open (torn-tail recovery vs Corrupt), and transport deframe (a damaged container both decoding and being rejected). Every threshold is counted at a fixed seed, stated in the comment, and set below the arm's measured frequency; each floor gates above a minimum round count so short runs never trip it.

Every other target carries a one-line note on why its outcome space does not partition: round-trips have only a success arm, and several garbage generators reach only their reject arm, the accept arm covered by the round-trip and deterministic tests. closed check-in: 1abe1089c1 user: dmestas tags: h9-fuzzcov

The companion to the library assert pass, now on the two split verb files. Eighteen asserts stating invariants that already hold: in the read verbs (cmd/history.zig), that a name decodes to a full digest before it is rendered and that a windowed or -n-capped listing's shown count matches the walked set; in the mutating verbs (cmd/checkout.zig), the preconditions at each destructive entry -- a full valid target id before update, both bisect endpoints present, exactly one pending merge or special op, every revert target in the managed set, and the checkout-record and managed-set agreement commit assembles a manifest from. Asserts only, no behaviour change; all sit on paths the e2e and simulation sweeps already drive, and all survive them. No assert fired, so no finding. check-in: 58763bb760 user: dmestas tags: trunk

Mirror the H5a assert idiom (state invariants that already hold, no behavior change) across the split read and mutating verbs. Asserts only; wire output and exit codes unchanged.

history.zig read verbs: - decodeFullId: a validated name decodes to a whole 20/32-byte digest, never a truncated prefix. - walkLog: every checkin/phantom line renders a full valid name, and the -n cap (parseLimitValue maps 0 to null) never overruns. - stat --artifacts / timeline: the listing projects the walked rid set, is capped by -n, and the printed count matches it. - tag add: the mint targets a check-in by its full artifact id.

checkout.zig mutating verbs: - update/amend: the applied/amended target is a full artifact id. - bisect: both endpoints present before the span move. - merge: exactly one pending op (merge_parent XOR special_op) before applyMerge; revert restores only managed paths. - commit: checkout record and managed set agree before the manifest assembles; root has no pending op, merge and special exclusive, a child's parent resolved, every captured card tracked. closed check-in: 99e0c73447 user: dmestas tags: h5b-verbasserts

The interop smoke only ever went one way -- fossil confirming what zit authored, always pull or clone direction. The push side of the wire, where capability negotiation and igot/gimme ordering live, was never exercised against the reference. Two scenarios close it, same policy as before (zit authors every byte; fossil only confirms; a mismatch prints the diff and its RFC citation, exits nonzero, and is a ledger decision). zit pushes a grown check-in to a live fossil server and a fresh fossil checkout must reconstruct the file byte for byte; then fossil commits a zit-authored blob that zit pulls and reads back through the library, re-verifying content against its artifact name. The smoke log now opens with the exact fossil version each run, so the conformance claim always names what it was confirmed against. check-in: 3ad0bf90da user: dmestas tags: trunk

Every smoke scenario drove pull/clone only -- fossil pulling from zit, zit pulling from fossil -- so zit's push wire (its igot/gimme ordering and capability negotiation as the sync client uploading to a server) never met the reference implementation.

Two scenarios in src/smoke.zig close that gap under the file's standing policy: every compared byte is zit-authored, fossil only confirms. S7 has zit push a grown check-in to a live fossil server, then reads it back from a fossil checkout byte-for-byte (sync 3.3/3.7). S8 lets a fossil commit extend the shared repo with our bytes, has zit pull it, and confirms convergence through the library reader -- Repository.blob re-verifying content against its artifact name (sync 3.2/3.7, artifact 7.2). Both share a prelude that seeds a zit repo, has fossil clone it for a common project-code, grants the anonymous loopback sync user check-in, and disables the autosync the clone inherits.

Smoke also prints the fossil version verbatim at the head of its log, so the exact reference implementation the scenarios confirmed against is recorded wherever smoke runs. closed check-in: a2672203c0 user: dmestas tags: h4-interop

The fuzz and simulation harnesses defer real depth to a nightly runner that was never written; the gate only ever ran a shallow smoke. scripts/ soak.sh is that runner. In a ReleaseSafe build it runs the deterministic simulation over many seeds and long step counts, then every fuzz target -- enumerated from the runner's own usage so the list cannot drift -- under an equal wall-clock budget per target, so a cheap target reaches far more rounds than an expensive one with no second cost table to maintain. A failure appends a runnable reproduce line to a dated log, drops a flag file, and exits nonzero; it never files or fixes anything, and its logs live outside the checkout. Proven to catch both a seeded simulation regression and a seeded fuzz regression, each replaying from the logged line. Installing the schedule and the first full nightly are operator steps, documented in the script and its README. check-in: 1b447f8b47 user: dmestas tags: trunk

The pre-commit gate runs the DST and fuzz harnesses shallow. Every comment deferring depth to an out-of-band runner pointed at a script that did not exist; scripts/ held only mirror-export.sh. This is that runner.

On a ReleaseSafe build (asserts on) it runs the repostate+sync DST at a deep seed/step sweep, then every fuzz target enumerated from the runner's own usage output, so the list cannot drift, under an equal per-target wall-clock budget. --rounds grows from measured speed to fill each budget, so a cheap target sweeps millions of rounds while a pack round-trip sweeps thousands.

On the first failure it appends a runnable reproduce line to a dated log, drops a flag file, and exits non-zero; it never files and never fixes. It owns an explicit fresh seed per fuzz invocation, because the fuzz runner's buffered stderr is dropped on the error-return path: a crashing target prints only its error name, not the seed it flushed before running.

Logs and the flag live outside the repo. Installing the schedule and the first full nightly are operator actions, documented in the header and soak.README. closed check-in: 9f00c44a8f user: dmestas tags: h1-soak

The fault simulator only ever corrupted at crash and restart boundaries. It could not model a latent sector error: bit rot that surfaces during a read of a store that opened clean. A new read_rot_pct knob does that -- a read returns payload-derived, never-self-healing corruption for a frame that is intact on disk -- and a sweep reopens a healthy store, arms it, and reads every held hash. The oracle: each read returns exactly the stored bytes or a declared corruption error, never wrong bytes as success. The append open path re-runs the whole-frame checksum per read, so it catches the rot; the sweep is green and a companion test proves the sweep can fail by reading through the checksum-skipping read-only open. The knob is inert at zero, so every existing seed keeps its byte stream. The crash-point fault technique follows TigerBeetle's storage fault model. check-in: ba805e5913 user: dmestas tags: trunk

FaultyFile injected corruption only at crash/restart boundaries. Add a read_rot_pct knob: a read of an intact byte interns one offset in its span as permanently corrupt (payload-derived mask, never self-heals) -- a latent sector error surfacing at content() time on a store that opened clean, independent of any crash. A healthy disk draws nothing, so existing sweeps keep a byte-identical PRNG stream.

New storage_sweep.readRotSweep joins the dst gate: after a healthy open, every content-bearing hash reads back either its exact bytes or a declared corruption error -- wrong bytes presented as success is SilentCorruption. The append open path re-runs each frame's whole-frame CRC per read, so latent rot is detected and the gate stays green. The verified-on-open read path (openReadOnly) trusts the scan-time CRC on an immutable-length assumption that bit rot violates; a test drives that path to prove the oracle fires SilentCorruption.

Read-fault model follows TigerBeetle's storage-fault-injection lineage. closed check-in: fde61b03b2 user: dmestas tags: h8-readrot

Assert density was collapsing exactly where the working tree and the wire are touched: update.zig held 2 asserts across 2127 lines, serve.zig 3, transport.zig 2 -- against the hundreds in the artifact and sync cores. This pass adds 17 asserts stating invariants that already hold: the checkout-state transitions in update (managed-set, record and rollback image agreement around each applyCheckin stage), the request/response postconditions in serve (media, arity and body-ceiling), and the frame, redirect and body-cap postconditions in transport. Asserts only, no behaviour change; where a result had to be named to assert on it the error mapping is preserved exactly. All survive the deterministic simulation sweeps, which is the point of landing them before the checkout crash-recovery sweep that will hammer update. check-in: 9654d06838 user: dmestas tags: trunk

Raise assert density in the three thinnest library modules, enforcing invariants that already hold. Asserts only, no behavior change.

update.zig: guard the checkout-state transition. applyCheckin asserts the desired managed set equals the target plan membership (validateTopology proves the paths unique); requireClean asserts a clean tree's plan membership equals the recorded managed set; recordUndoImage asserts the affected union covers both operands; commitMaterialization self-guards that the committed record names exactly the staged check-in and that the managed set is its membership; the merge path asserts one rollback pre-image per path and a shared pre-merge managed baseline.

serve.zig: a servable request is a POST bearing a request-valid compressed media type (§4 L759-764); an accepted body honors the §4 L1148-1149 ceiling; a compressed reply is application/x-fossil (§4.1); the accept loop honors its request bound.

transport.zig: a framed container carries its 4-byte length prefix (§4.1); an unframed reply stays within reply_body_cap (§4 r9); a followed redirect lands only on an http/https transport (§4 r12/r13). closed check-in: c9fb87f554 user: dmestas tags: h5a-asserts

Fourth and final family extraction. A pure behaviour-preserving move: the mutating checkout verbs -- update, bisect, merge, revert, undo, redo, commit, amend -- and the helpers private to them (the undo journal, the dirty-tree gate, the checkout record, the commit and amend manifest assembly) move verbatim into src/cmd/checkout.zig, byte-identical to their source but for the pub the dispatch forces on the eight handlers. commitEpoch stays in main.zig because main itself builds the ambient clock from it; shared helpers stay pub and aliased. With this, main.zig holds only main, the verb dispatch, init, the shared helpers and the test surface -- the eleven-thousand-line file is now four cmd families plus a thin dispatch core. No helper duplicated, no cross-cmd import, test count unchanged. check-in: ae54e47b3c user: dmestas tags: trunk

The final family extraction, completing the split of the CLI surface out of main.zig. A pure behaviour-preserving move: the mutating verbs -- update, bisect, merge, revert, undo, redo, commit, amend -- and the helpers and tests private to them move verbatim into src/cmd/checkout.zig, byte-identical to their source but for the pub the dispatch switch forces on the eight dispatched handlers.

The move is non-contiguous: the update error mapper, the digest wire helpers, mintControlArtifact, and commitEpoch stay in main.zig because they are shared with other verbs or with main itself, so moving them would cross a cmd boundary or duplicate them. Shared helpers stay pub and are aliased so the moved bodies read unchanged. No helper duplicated, no cross-cmd import, test count unchanged.

After this, main.zig retains only main, the verb dispatch, runInit, the genuinely shared helpers, and the test helpers. closed check-in: 9870033d32 user: dmestas tags: s5-checkout

Third of four family extractions. A pure behaviour-preserving move: the read surface -- stat, log, leaves, timeline, branch, tag, info, ls, cat, artifact, annotate -- and the name-resolution and rendering helpers private to it move verbatim into src/cmd/history.zig, byte-identical to their source but for the pub the dispatch switch forces on the eleven handlers. The extraction is non-contiguous: the mutating checkout verbs interleave with the read verbs in the file and stay exactly in place. repoReadFail stays pub in main.zig because the sync family calls it, so moving it would cross cmd boundaries. Shared helpers stay pub and aliased so moved bodies read unchanged. No helper duplicated, no cross-cmd import, test count unchanged. check-in: 3bbc572acd user: dmestas tags: trunk

Move the read-only inspection verbs — stat, log, leaves, timeline, branch, tag, info, ls, cat, artifact, annotate — together with the name-resolution and rendering helpers private to them out of src/main.zig into the new src/cmd/history.zig, mirroring the S2 sync and S3 tracking extractions.

Pure behaviour-preserving move: every relocated declaration is byte-identical to its main.zig source. The only changes are the new import prologue and the pub forced on the eleven dispatch-called handlers. Helpers shared with the still-in-main checkout verbs (repoReadFail, openRepo, reasonOf, firstCommentLine, renderBranchList, lessByHash, mintControlArtifact, and the per-verb help strings) stay pub in main.zig and are aliased back in the prologue.

The extraction is non-contiguous: the checkout family — update, bisect, merge, revert, undo, redo, commit, amend — is interleaved among the moved verbs and is left exactly in place.

main.zig keeps the verb-dispatch switch, now calling cmd_history.runStat and its siblings; its test root imports the new file so the moved inline test keeps running. closed check-in: 8e2c31c8ba user: dmestas tags: s4-history

Second of four family extractions. A pure behaviour-preserving move: the eight working-tree handlers -- add, rm, mv, status, extras, clean, addremove, diff -- and the helpers private to them, including the whole diff-and-compare machinery, move verbatim into src/cmd/tracking.zig, byte-identical to their source but for the pub visibility the dispatch switch forces on the eight handlers. init stays in main.zig because clone bootstraps through it, and stat stays too; both are called by more than this family. Helpers shared with staying verbs stay pub in main.zig, aliased so the moved bodies read unchanged. No helper duplicated, no cross-cmd import created, test count unchanged. check-in: 1df44c39bd user: dmestas tags: trunk

Release step S3, the second of four family extractions from main.zig. A pure behaviour-preserving move: the eight working-tree tracking handlers -- add, rm, mv, status, extras, clean, addremove, diff -- and the helpers and tests private to them move verbatim into src/cmd/tracking.zig, byte-identical to their source but for the pub visibility the dispatch switch forces on the moved handlers. Helpers shared with other verbs (runStat, commit, merge, revert) stay pub in main.zig and are aliased back so the moved bodies read unchanged. No helper is duplicated and no cross-cmd import is created; runInit and runStat stay in main.zig. The test count is unchanged, so nothing was orphaned. main.zig keeps main, the verb dispatch, and the shared helpers. closed check-in: ed32969b32 user: dmestas tags: s3-tracking

First of four family extractions from main.zig. A pure behaviour- preserving move: the eight network and store-transfer handlers -- serve, clone, open, pack, pull, push, sync, remote -- and the helpers private to them move verbatim into src/cmd/sync.zig, byte-identical to their source but for the pub visibility the file boundary forces on the handlers the dispatch switch still calls. Helpers shared with other verbs stay in main.zig, aliased back so the moved bodies read unchanged. No helper is duplicated and no cross-cmd import is created; the test count is unchanged, so nothing was orphaned. main.zig keeps main, the verb dispatch, and the shared helpers. check-in: 47a2717952 user: dmestas tags: trunk

Move the sync / network / store-transfer verbs — serve, clone, open, pack, pull, push, sync, remote — together with the helpers and tests private to them out of main.zig into a new src/cmd/sync.zig. This is a pure behaviour-preserving move: every relocated line is byte-identical to its main.zig source; only cmd/sync.zig's import prologue and the handlers' pub visibility are new.

Helpers still shared with other verbs stay in main.zig, now made pub and aliased back in cmd/sync.zig so the moved bodies call them by their original unqualified names. The verb-dispatch switch stays in main.zig and calls into the new file; main.zig's test block imports it so the moved inline tests keep running.

No behaviour change: the full test count is unchanged and the dead-file guard reaches cmd/sync.zig through the dispatch import, with no allowlist entry. closed check-in: 254575cbd8 user: dmestas tags: s2-sync

Zig runs only the tests reachable from a root the build compiles. A source file no root imports still compiles -- its tests just stop running, and nothing fails. That is the defining hazard of the coming main.zig split, so the guard lands first. A test walks every src/**/*.zig, builds the import graph, and asserts each file is reachable from one of the three roots: root.zig, main.zig's test block, or dst.zig. The failure names the file and the one-line import that fixes it. Six files that build.zig wires as their own roots are allowlisted, and the list itself is checked so a stale or newly-reachable entry fails rather than hiding a real orphan.

The DeadFilesDetector pattern is borrowed from TigerBeetle's src/tidy.zig. check-in: 60b10a6332 user: dmestas tags: trunk

Zig runs only the tests reachable from a root the build compiles. A .zig file that no root imports still compiles -- its tests simply stop running and coverage evaporates with no error. tidy.zig walks src/**/*.zig, builds the @import graph, and asserts every file is reachable from one of the three test roots: root.zig (exported module), main.zig's test block (CLI surface), and dst.zig (harnesses). An allowlist carries the files build.zig wires as their own roots -- e2e, smoke, and the benchmarks -- each verified rather than papered over, and a hygiene check fails if an allowlist entry goes stale or becomes reachable. On a miss the failure names the file and the one-line import that re-roots it.

This lands before the main.zig to src/cmd split so that move cannot silently orphan a file's tests.

Mechanism borrowed from TigerBeetle's src/tidy.zig DeadFilesDetector, which walks its own tree and fails the build when a file falls out of the import graph. closed check-in: a8d7f6b621 user: dmestas tags: s1-tidy

Adds the release notes as a shipped asset and a limitations section to the README, both stating plainly what 0.1.0 does not do: diff is name-status against the current check-in only, the sync server code is an informational placeholder while the project code is real, the R and W cards are carried but not interpreted, and stash/grep/ui/settings and rev-to-rev diff are absent. The notes record what the conformance claim rests on -- smoke driving the real fossil binary in CI -- and cite the pack measurements to their existing benchmark rather than restating them as fresh claims. The version stamp is left for the ship step. check-in: 7ba838ab6c user: dmestas tags: trunk

Help already listed all dispatched verbs, but nothing held it that way: a verb added later could ship without a help line and no test would notice. An end-to-end pin now drives off the Verb enum itself and fails, naming the offender, if any dispatched verb is absent from zit help -- so the audit cannot silently rot as the command set grows. check-in: 7a0735c415 user: dmestas tags: trunk

The #7 fix taught the timeline read path to tolerate fossil's 2008 cvs2fossil-era check-ins, whose F cards carry a dangling trailing separator the strict grammar has no production for. The baseline read path had the same defect: parseBaseline used the strict parser, so files and merge on a delta whose baseline is one of those legacy manifests failed as an unresolvable baseline. It now reads through parseForImport, the same tolerance, and threads the normalized copy the manifest borrows into the owned baseline so it is freed exactly once. The strict parser still runs first and remains the sole grammar oracle; any other malformation is still refused. check-in: cd63fa1766 user: dmestas tags: trunk

The files/ls path eagerly reads a delta check-in's B-card baseline and parsed it through the strict reference parser. fossil's own 2008 cvs2fossil-era manifests carry F cards with a dangling trailing separator after the hash -- a space where a perm token would go -- which the section 4.2 grammar has no production for, so the strict parser rejects them as corrupt. When such a manifest is a delta's baseline, the rejection surfaced as BaselineUnresolvable and the check-in's whole file set vanished.

The target-manifest read path already tolerates this shape through parseForImport; the baseline path now does too. The strict parser still runs first and stays the sole grammar oracle; tolerance engages only when a well-framed, Z-valid artifact is rejected, strips exactly one trailing separator per F card, re-seals the checksum, and re-runs the strict parser -- any other malformation is still refused. The tolerated normalized copy is owned by the parsed baseline and freed with it. closed check-in: 7bb5af134e user: dmestas tags: iss7b

The command summary described -n as previewing the destructive verbs alone; it also caps timeline and log at the most recent N, and -R reads a repository with no working tree. Both are stated so the summary does not undersell what shipped. closed check-in: 80913fe845 user: dmestas tags: p5b-docs

Add an end-to-end check that runs `zit help` and asserts every member of the dispatched Verb enum is listed as a command, keyed off the enum itself rather than a hand-copied list. A verb wired into the dispatcher without a help line now fails the build instead of shipping undiscoverable.

The match is anchored on the command column, so a name that appears only inside another verb's description — "sync" in serve's line, "stat" within "status" — cannot satisfy it; a dropped command entry is caught by name.

The shipped help already names all verbs, so this changes no output; it pins that state against future drift. closed check-in: 64b9a0ee71 user: dmestas tags: p5a-help

Add a Limitations section to the README and a docs/RELEASE-NOTES-0.1.0.md release asset, both re-derived from current shipped behavior rather than assumed.

The caveats are the deliberate deferrals, verified against the binary and source: diff is working-tree-vs-current-check-in and name-status only, with no rev-to-rev form; the sync server code is a fixed informational placeholder while the per-repo project code is real (derived on init, persisted, adopted on clone); the R and W cards are parsed but not interpreted, whereas T and U are acted on; and stash/grep/ui/settings have no equivalent.

The notes name the local fossil 2.28 that the interop smoke passes against, flag that the runner version lags and must be confirmed at ship, and cite the pack re-deltification measurements to their benchmark commit bab9303056. check-in: ab4951c2e8 user: dmestas tags: p5b-docs

timeline stopped partway through a large fossil-origin repository and lost every check-in at and beyond that point. The cause was not an I/O fault, as the shared "input/output error" wording suggested, but a strict parse: fossil's own 2008 cvs2fossil-era check-ins carry F cards with a dangling trailing separator after the hash, which the §4.2 grammar has no production for and the reference parser rejects as corrupt. Repository.manifest -- the timeline read path -- used that strict parser, so the first such check-in and all older ones vanished.

It now reads through parseForImport, the same read-path tolerance the diff baseline already relies on. The strict parser still runs first and stays the sole grammar oracle; tolerance engages only when a well-framed, Z-valid artifact is rejected, strips exactly one trailing separator per F card, re-seals the checksum, and re-runs the strict parser -- so any other malformation is still refused. Complete history renders again, down to the repository's 2007 root. check-in: 4e8d402bb6 user: dmestas tags: trunk

A read verb could only reach a store by walking up from the cwd, and timeline/log could only emit the whole history. -R/--repo names a store directly, so timeline, log, leaves, branch, tag, info, ls, cat, artifact and annotate run against it with no working tree; a verb that reads or writes the checkout refuses -R by name rather than silently operating on the cwd's store. -n N caps timeline and log at the N most recent check-ins (0 means all), ordered by the same DAG the full listing uses. The -n spelling stays --dry-run on add/rm/clean/addremove, a per-verb overload matching fossil, so those verbs reject -n N and keep their boolean sense.

stat is left out of the -R grant on purpose: it interrogates only the store, but its handler takes no redirected repository, so it refuses -R by name rather than read the cwd's store while appearing to honor the flag. check-in: 43468196c2 user: dmestas tags: trunk

Repositories that enable fossil's manifest setting expect manifest, manifest.uuid and manifest.tags in the checkout, and their builds read them to stamp a version. A zit checkout could not produce them, so such a build failed or, worse, succeeded with no version embedded. zit open --manifest writes them; the bare flag means ru, and a value picks any combination of r (the check-in artifact), u (its hash) and t (its branch and symbolic tags). The choice is recorded in the checkout record, so every later update refreshes the files; absent flag writes nothing. The selection is explicit rather than read from the cloned repository because the two places fossil keeps it can disagree and only one syncs, so a checkout reading the setting could diverge from a fossil checkout carrying a local override while claiming fidelity. Contents match fossil byte for byte, including the sterilizing comment it appends to manifest. check-in: b38b3be769 user: dmestas tags: trunk

mv recorded a rename in the managed set and persisted it before attempting the filesystem move, with no rollback. A move into a nonexistent directory left the set naming a path that held no file: status invented a missing entry, commit refused over it, and the recovery mv --help documents did not work.

mv now validates that the destination's parent exists and refuses before touching anything, so the failing case records nothing.

Two further defects on the same path. An inverse rename replaced the pending record instead of dropping it, so 'mv a b' followed by 'mv b a' left a b-to-a rename queued; the next commit carrying a real change would then emit an old-name F card asserting the file was formerly named b, a name never committed. That is false provenance in a permanent artifact, produced by the exact sequence the help text advertises as recovery. mvRecord now nets an inverse rename back out.

The error path printed raw Zig error names — a user saw 'AccessDenied' where clean and init already print 'permission denied' through reasonOf. It now uses the same mapping.

A residual window remains: a crash between the move and the record write is not atomic, documented at the site. Full working-tree crash consistency is a separate concern. check-in: 33a2ceb6d1 user: dmestas tags: trunk

`mv --help` advertises `zit mv NEW OLD` as the way to undo a rename, so it is the sequence a user is most likely to run. It left the pending record replaced rather than cleared: OLD->NEW->OLD queued a §4.7.6 old-name F card asserting OLD was formerly NEW -- a name no manifest has ever carried. The next commit with any real change would write that false claim about the past into a permanent artifact, where it cannot be taken back. A rename and its inverse are a no-op, so the pair now nets the record out.

This survived the guard because the guard's oracle was indirect: commit reports "nothing to commit" on CONTENT alone, so a stranded record passes it silently and surfaces only at the next commit that carries a change. The record is now read back directly.

mv's move errors render through `reasonOf` rather than `@errorName`, so EACCES reads "permission denied" instead of "AccessDenied". This was deferred as errno-sweep work, but the mapping already exists and `init` and `clean` print through it -- reuse, not new scope. A raw Zig error name is an internal identifier, not a diagnostic. closed check-in: 7235a86bcd user: dmestas tags: blockers

mv recorded the rename durably before attempting the filesystem move and rolled nothing back when it failed, leaving the set naming a path that does not exist and commit ready to record a rename that never happened. The reversal mv --help promises -- "run zit mv NEW OLD" -- failed too: it saw the old path still occupied and refused the collision.

mvCommit now renames first, then records; if the record fails the file is renamed back and nothing is persisted. Move-first beats record-first because undoing a durable write needs a second durable write, which can itself fail, nesting a failure inside the failure handler. Renaming a file back cannot realistically fail -- the source directory and name are still free. Build the guarantee on the rollback that cannot fail.

mvCheckLegal gains a dest-parent-exists check: stat of a path under a missing directory fails, so the old collision check read "absent" and waved it through. Residual window: a crash between move and record leaves the file at NEW with the set naming OLD, recoverable with add NEW + rm OLD.

ENOENT and EACCES were both rendered "input/output error". check-in: d7dd9ea30b user: dmestas tags: blockers

Lands the B6 increment (d8e5e811) on trunk. The fix itself is unchanged from that commit and its full reasoning is recorded there; this message covers the landing, because the merge was not a formality.

WHAT B6 FIXES

`tag` was read-only. `tag list` was the only subcommand, so a repository could not be given a name for a check-in at all. Unlike the other five blockers this was not a wrong answer — the verb told the truth about what existed — but the capability was simply absent. `zit tag add NAME CHECKIN` now mints one CONTROL artifact carrying a single `T +sym-NAME` card, targeting the resolved check-in's 64-hex hash.

THE SIGN IS THE WHOLE CORRECTNESS ARGUMENT

The card is a SINGLETON (`+`), not a propagating (`*`) tag. `resolveName` (src/repostate.zig:891) picks the max-`event.mtime` check-in among ALL active `sym-` rows, so a propagating `*sym-v1` would be inherited by every descendant and then resolve to the NEWEST of them — the name would silently drift off the check-in the user tagged, which is the same class of wrong answer as B1. `applyTagOps` (src/repostate.zig:727) gates propagation on `op.type != .singleton`, so a `+` card pins the name with ZERO repostate changes. The contrast with a branch is deliberate: a *branch* sym propagates precisely because descendants must inherit it; a *tag* sym does not, precisely because they must not.

CONFLICT RESOLUTION, STATED

One conflict, src/e2e.zig, positional rather than semantic: trunk's B5 block and B6's block are both appended at the end of the file over an empty common ancestor. Fossil again emitted the five-part conflict rather than the usual four — a "####### SUGGESTED CONFLICT RESOLUTION follows" section carrying its own proposed merge sits between the local copy and the ancestor section. Splitting only on the four familiar markers swallows that separator into the kept text, which then compiles as garbage; B3's landing recorded the same trap and it recurred here verbatim.

The two candidate sections were compared before choosing: the SUGGESTED section and the MERGED IN section are byte-identical (257 lines each), and the common ancestor is a single empty line. The resolution keeps trunk's 8 B5 tests plus exactly one copy of B6's 5-test block. Verified post-resolution: no residual marker of any of the five kinds, 432 tests in the file, no duplicated test name, and the B3 (5), B5 (8) and B6 (7) blocks all present at their expected counts. One further edit was needed — the splice left a doubled blank line at the seam, which `zig fmt` flagged; the reformat is that one blank line and nothing else.

TEST EVIDENCE ON THE MERGED TREE

Re-verified on trunk after the merge, not inherited from the branch: `zig fmt --check .`, `zig build`, `zig build test`, `zig build e2e` (432/432, no filtering), `zig build dst` (6 seeds x 1000 steps) and `zig build smoke` (S1-S6) each exit 0. `fossil extras --dotfiles` is empty.

The blocker repro was also driven by hand against the rebuilt merged binary rather than inferred from the source: `zit tag add v1 tip` exits 0 and prints the artifact hash; after a second commit `zit cat a.txt v1` is the tagged content while `zit cat a.txt tip` is the newer one, and `zit tag list tip` does NOT carry v1 — the singleton pins and is not inherited. `zit tag add v1` alone is a usage error at exit 2, and `zit tag add v2 nosuchcheckin` exits 1 naming the check-in and leaves no tag behind.

CHANGED EXPECTATIONS (all three encoded the missing capability, nothing else)

cli tag B-tag-7 (src/cli.zig) and cli tag B-tag-13 (src/e2e.zig) used the literal token `add` as their stand-in for "not a subcommand". `add` IS one now, so both use `cancel`, a word that still is not — cancel/remove semantics stay deferred to 0.2. cli tag B-tag-11's verbatim `tag_help_expected` gains the `add` usage line and its paragraph, because `tag --help` must teach the new grammar. The diff was audited for other expectation changes and there are none.

RECORDED, NOT ASSUMED: branch creation shares no read-only gap. It is already served by `commit --branch`, which mints the propagating branch/sym pair directly on the check-in manifest (src/cli.zig `composeCommitTags`), so there is no `branch add` to write.

No borrowed technique: the singleton-sign argument and the `mintControlArtifact` extraction are original to this change. No performance claim is made. check-in: a5b6db7a8c user: dmestas tags: trunk

Lands the B3 increment (1aeb531cac) on trunk. The fix itself is unchanged from that commit and its reasoning is recorded there; this message covers the landing, because the merge was not a formality.

WHAT B3 FIXES

A symlink anywhere in the checkout permanently wedged `commit`. `extras.zig` classified a symlink as an extra, and the recursive `add DIR` / `addremove` paths reused that sweep as their add set without re-applying the kind test that explicit `zit add sym.txt` and `commit` both apply. The recursive path tracked exactly what the direct path refused, so after `zit add .` every subsequent `zit commit` died with "cannot commit 'sym.txt': not a regular file" and the only way out (`zit rm sym.txt`) was named nowhere. Consistent refusal is the contract: 0.1.0 does not version symlinks on any path.

WHY IT LANDED SEPARATELY

B3 was committed to `blockers` off the old branch tip and never reached trunk; trunk meanwhile took B1, B5 and a CI change. The sibling B6 commit (d8e5e811) had already absorbed B3 into its own tree, so B3 would eventually have arrived on trunk bundled inside B6. Landing it on its own keeps each increment gated and merged on its own evidence rather than riding in on another's, and it shrinks the diff B6 still has to land.

CONFLICT RESOLUTION, STATED

One conflict, src/e2e.zig, positional rather than semantic: trunk's B5 block and B3's block are both appended at the end of the file, over an empty common ancestor. Both blocks are kept, one copy each.

Worth recording because it is a trap: fossil emitted a five-part conflict, not the usual four. Between the local copy and the ancestor section it inserted a "####### SUGGESTED CONFLICT RESOLUTION follows" section carrying its own proposed merge. Splitting only on the four familiar markers silently swallows that separator line into the kept text, which then compiles as garbage — it surfaced here as `zig fmt` and the compiler both failing at that exact line, not as anything that looked like a merge problem. The resolution keeps the local copy plus fossil's suggested section (B5 then B3) and drops the duplicate merged-in copy, which was verified to be a strict substring of what was kept. Post-resolution the file holds 13 tests in that region with no duplicated test name and no residual marker of any of the five kinds.

TEST EVIDENCE ON THE MERGED TREE

Re-verified on trunk after absorbing the latest sibling (861b223e3c), not inherited from the branch: `zig fmt --check .`, `zig build`, `zig build test`, `zig build e2e`, `zig build dst` (6 seeds x 1000 steps) and `zig build smoke` (S1-S6) each exit 0. Full battery, no filtering. `fossil extras --dotfiles` is empty.

The B3 repro was also driven by hand against the rebuilt binary: `zit add .` skips sym.txt and says so on stderr, `zit commit` succeeds, `zit status` reports nothing, `zit extras` lists sym.txt, explicit `zit add sym.txt` refuses with the symlink wording at exit 1, and `addremove` withholds it silently.

No borrowed technique. No performance claim is made. check-in: 01dc9f8e8a user: dmestas tags: trunk

The sweep could not finish inside its own 10-minute step timeout. Per-target cost varies by roughly 276x across the corpus: artifact_parse_garbage runs 100 rounds in 0.18s, while logstore_pack_same_path_round_trip takes 49s because it performs a full store pack every round. At 2000 rounds that single target needs about 16 minutes on its own.

The original figure was extrapolated from one cheap target on the assumption that per-round cost was roughly uniform. It is not, and the assumption was never measured. 100 rounds is measured: the full 27-target sweep takes about 76s.

This makes CI fuzzing a regression check — every target still runs clean on every push — rather than a bug hunt. Finding new defects needs depth, and depth belongs in an out-of-band run with its own budget, where a long sweep costs nobody a merge. check-in: 861b223e3c user: dmestas tags: trunk

`tag` was read-only: `tag list` was the only subcommand, so a repository could not be given a name for a check-in at all (blocker B6). The verb told the truth about what existed, but the capability was simply absent.

WHAT CHANGED

`zit tag add NAME CHECKIN` mints one CONTROL artifact carrying a single `T +sym-NAME` card targeting the resolved check-in's 64-hex hash.

THE SIGN IS THE WHOLE CORRECTNESS ARGUMENT. The card is a SINGLETON (`+`), not a propagating (`*`) tag. `repostate.resolveName` (src/repostate.zig:891) picks the max-`event.mtime` check-in among ALL active `sym-` rows, so a propagating `*sym-v1` would be inherited by every descendant and then resolve to the NEWEST of them — the name would silently drift off the check-in the user tagged, which is the same class of wrong answer as B1. `applyTagOps` (src/repostate.zig:727) gates propagation on `op.type != .singleton`, so a `+` card pins the name with ZERO repostate changes. The contrast with a branch is deliberate and now documented at both sites: a *branch* sym propagates precisely because descendants must inherit it; a *tag* sym does not, precisely because they must not.

`amend`'s steps 5-6 — assemble the control manifest, run the runtime-safety round-trip self-check, `putArtifact` + `commit` under the single fsync — are extracted into `mintControlArtifact`, and `tag add` is its second consumer. Both verbs resolve a check-in, compose a T run, then mint; that last step is now written once. amend's existing battery guards the extraction unchanged. The helper's error set is `logstore.OpenError`, the widest of the three the body can produce, so each verb renders it under its own name.

`tag add` closes its read view BEFORE the read-write append (commit's durability pattern), so it owns its repository lifetime rather than sharing the listing path's `defer repo.deinit`. Resolution and the empty-NAME check both precede the mint: a run that cannot resolve its CHECKIN mints nothing, asserted by a test.

`selectInheritedSyms`'s comment said zit mints no singleton syms itself, so the §6.2 exclusion of them from a branch move's cancel set was reachable only via a synced `T +sym-X *`. That is no longer true — the comment is corrected. The behavior needed no change, and its unit test already covered a singleton sym.

RECORDED, NOT ASSUMED: branch creation shares no read-only gap. It is already served by `commit --branch`, which mints the propagating branch/sym pair directly on the check-in manifest (src/cli.zig `composeCommitTags`), so there is no `branch add` to write. Cancel/remove semantics stay deferred to 0.2 — closing "cannot create tags" is the blocker; a full tag lifecycle is not.

RED PROOF (per BLOCKER-FIX-PLAN.md section 2, no product code changed until RED was proven; markers `// REGRESSION B6:`)

End-to-end, src/e2e.zig — all five failed pre-fix at `tag add` with exit 2 ("unknown subcommand 'add'"):

cli REGRESSION B6: tag add creates a tag that tag list and tag list CHECKIN report cli REGRESSION B6: a created tag pins to its check-in and is not inherited by a descendant (tag before commit) cli REGRESSION B6: a created tag pins to its check-in and is not inherited by a descendant (commit before tag) cli REGRESSION B6: a created tag survives pack cli REGRESSION B6: a created tag survives a clone

The pinning pair runs both orderings — tag-then-commit exercises inheritance at commit time, commit-then-tag exercises the propagation walk over already crosslinked descendants. Identical behavior in both is what proves the mechanism rather than luck. pack and clone prove the round trip: a synced artifact that does not survive sync is a worse lie than a missing verb.

Added alongside them: `tag add`'s arity errors, and an unresolvable CHECKIN leaving no tag behind. Unit, src/cli.zig: the parser's add grammar (both positionals required, `--help`/bad option winning over arity, `--` handling), `composeTagAddCards` minting exactly one `+sym-` card at the target, its control round trip through `artifact.parse` proving the sign survives the wire, and leak-freedom under `checkAllAllocationFailures`.

TEST EVIDENCE NOW

In this worktree at the committed tree: `zig fmt --check .`, `zig build`, `zig build test`, and `zig build e2e` each exit 0 — full battery, no filtering.

CHANGED EXPECTATIONS (both encoded the missing capability, nothing else)

cli tag B-tag-7 (src/cli.zig) and cli tag B-tag-13 (src/e2e.zig) used the literal token `add` as their stand-in for "not a subcommand". `add` IS one now, so both use `cancel`, a word that still is not.

cli tag B-tag-11's verbatim `tag_help_expected` gains the `add` usage line and its paragraph, because `tag --help` must teach the new grammar.

No borrowed technique: the singleton-sign argument and the mint extraction are original to this change. No performance claim is made.

SIBLING MERGE

This checkout absorbed the sibling B3 commit (1aeb531cac) before landing. The only conflict was in src/e2e.zig and was positional, not semantic: both changes append a new regression block at the end of the file. Both blocks are kept, one copy each; the two candidate B3 hunks fossil presented were byte-identical, and the full battery above was re-run on the merged tree, not just on mine. check-in: d8e5e8117d user: dmestas tags: blockers

A merge whose only effect was an ADDED file was silently lost: the file landed on disk but never in .zit-managed, so status said "nothing to report", extras listed it as junk, and commit refused "nothing to commit (no changes)" while dropping the merge parent. The branch existed on one disk and undo was the only escape.

No new state was needed — CheckoutState.merge_parent already carried the pending merge and commit already consumed it as a two-token P card. The gap was the managed set and two refusals that did not know about it. applyMerge now derives the membership mutation from the same entry stream that drives the filesystem effects, which also fixes the symmetric bug for free (a merge-deleted file used to stay managed and invent a phantom "missing") and covers cherrypick/backout, which share the seam. status names a pending merge/cherrypick/backout. commit's no-op refusal no longer fires over a pending merge, so a convergent-content merge can no longer wedge the tree.

One test expectation changed: the new add-idempotence case asserted the "already tracked" notice on stdout; it has always been a stderr diagnostic (three shipped e2e cases assert it there). The test had the stream wrong, not the product.

Merged tree re-verified on trunk rather than inherited from the branch: zig fmt --check ., zig build, zig build test, full zig build e2e (420 tests, all eight REGRESSION B5 cases green including the contract-partner undo guard) and smoke S1-S6 all exit 0. fossil extras --dotfiles is empty. The blocker repro was also driven by hand against the rebuilt binary end to end.

Landed alongside, not merged here: another session committed B3 (1aeb531cac) to blockers off the OLD blockers tip, leaving that branch with two leaves. This increment branched off trunk, so the two do not interact and B3 remains that session's to land. check-in: 99f4895c04 user: dmestas tags: trunk

A merge whose only effect was an ADDED file was silently lost. `merge` wrote the incoming file to the working tree but never inserted it into `.zit-managed`, so the file was simultaneously on disk and untracked: `status` said "nothing to report", `extras` listed it as junk, and `commit` refused with "nothing to commit (no changes)" — dropping the merge parent that `merge` had recorded in `.zit-checkout`. The branch existed on exactly one disk and `undo` was the only escape.

No new state was needed. CheckoutState.merge_parent already carries the pending merge (src/checkout.zig), runMerge already records it, and commit already consumes it as a two-token P card and clears it. The gap was entirely in the managed set and in two refusals that did not know about it.

applyMerge now DERIVES the membership mutation from the same entry stream that drives the filesystem effects, rather than accepting a parallel list from the caller: a `.write` registers its path (insert is idempotent, so an ordinary edit-merge is unaffected) and a `.delete` deregisters it. One stream, one truth. Deriving it there rather than in computeAndApplyMerge also fixes the symmetric adjacent bug for free — a merge-deleted file used to stay managed and invent a phantom "missing" that commit then refused over — and covers cherrypick and backout, which share the same seam. The pre-merge set joins the in-process rollback images so a mid-apply failure restores membership along with the files and the checkout; the undo journal already snapshotted `.zit-managed`, so abort and undo deregistration fall out unchanged.

The set is read twice rather than rebuilt from `old.iterate()`: the on-disk record carries a pending `mv` rename beyond the bare membership, and rebuilding would have silently dropped it.

status now names a pending merge/cherrypick/backout in its header block. A merge whose file effects are already materialized was otherwise indistinguishable from a clean tree, with no way to see that a second parent was queued.

commit's no-op refusal no longer fires while a merge or special op is pending. A convergent-content merge — both sides making the same edit — composes to F cards identical to the parent's, so `unchanged` went true and the pending merge wedged with no commit path at all. The P/Q card is itself the change.

Test-expectation change: the new "zit add of a merge-added file is idempotent" case asserted the "already tracked" notice on stdout. That notice has always been a stderr diagnostic (three shipped e2e cases assert it there); the test had the stream wrong, not the product. The assertion's intent — add sees the merge-registered file as already tracked and does not re-add it — is unchanged.

No technique was borrowed here: the mechanism rides zit's existing applyMerge, ManagedSet and journal seams. Fossil's vmerge/vfile registration was consulted as an analog for the SHAPE of the problem only, and none of its code or algorithm is reproduced.

Verified in this worktree: fmt, build, zig build test, full zig build e2e (420 tests, all eight REGRESSION B5 cases green, contract-partner undo guard still green), and smoke S1-S6. The blocker repro was also driven by hand against the rebuilt binary: merge reports 1 file changed, status shows "pending merge with <hash>" and "added feat.txt", extras is empty, commit lands, and info tip shows both parents. closed check-in: de05152541 user: dmestas tags: blockers

A symlink anywhere in the checkout permanently wedged `commit`. `extras.zig` classifies a symlink as an extra (B-extras-9), and the recursive `add DIR` / `addremove` paths reuse that sweep as their add set without re-applying the kind test that explicit `zit add sym.txt` and `commit` both apply. The recursive path therefore TRACKED exactly what the direct path REFUSED: after `zit add .`, every subsequent `zit commit` died with "cannot commit 'sym.txt': not a regular file", `zit status` called an on-disk file missing, and the only way out (`zit rm sym.txt`) was named nowhere. `add .` is the documented whole-tree workflow, so any repo containing a symlink was stuck.

WHAT CHANGED

Consistent refusal: 0.1.0 does not version symlinks, on every path.

1. `extras.Extras` entries widen from a bare path to `Entry{path, is_symlink}`. The sweep already lstat-classified every entry (`resolveKind`); the verdict now rides out on the entry instead of being re-derived by callers. That is the point of the shape: `add` and `addremove` do NOT re-stat swept items, so the two paths cannot drift from the deep module's classification again — which is the mechanism of this bug. Ordering is unchanged (sort is by `path`; `is_symlink` never participates), and every postcondition assert is preserved.

2. The five `items()` consumers split by role. `extras` and `clean` ignore the tag — enumerating verbs do not judge, and a symlink stays a listable, deletable extra. `add`'s directory sweep and `addremove`'s insert loop filter on it.

3. `classifyPath`'s catch-all `else => .not_regular` splits: `.sym_link` gets its own `Outcome` and the wording `symlink (not versioned in 0.1.0)`; a fifo/socket/device keeps "not a regular file". Those are not the same refusal and must not read as one. The wording is one shared const so the explicit refusal and the recursive skip notice cannot diverge.

4. `commit`'s `Capture.not_regular` carries whether the entry was a symlink, and `commitNotRegular` renders the recovery for that case: "run 'zit rm PATH' to stop tracking it". This is how repos already wedged by a pre-fix `add .` get out; there is no migration code and none is needed.

REPORTING DECISION (stated, not implied)

`add` prints each skip to stderr, alongside its existing already-tracked notice: add's contract is per-argument feedback. `addremove` withholds symlinks SILENTLY. Its report is a two-channel ADDED/REMOVED ledger of state transitions, and a skipped symlink is a non-transition; growing a third notice channel there would change the shape of a report other tooling reads. `zit extras` is the verb that shows the symlink is still present and untracked.

`status` needed no change: post-fix the symlink is simply untracked.

TESTS

Five e2e regressions, marker `// REGRESSION B3:`: the breakdown doc's repro chain verbatim (init/add ./commit/status/extras); an `addremove` variant with symlinks sorting BOTH before and after the regular file the sweep also yields, so a filter that latched off the previous item's kind fails one of the two; explicit `add sym.txt` refusing with the symlink wording and tracking nothing; the wedge-recovery chain (pre-tracked symlink -> commit names `zit rm` -> rm -> commit succeeds -> status clean); and a `clean --dry-run` contract-partner guard that was green before the fix and stays green through it, proving clean still lists a symlink as an extra after the `Extras` type change. A unit assertion in `extras.zig` pins the tag itself, and `commitNotRegular`'s renderer test covers both branches.

Two pre-existing e2e expectations changed, both because they encoded the bug or its wording:

- `cli addremove B-addremove-2` asserted the ADDED set was byte-identical to `zit extras`, symlink included. That identity IS the defect. It now asserts the add set is the extras set MINUS symlinks, and additionally that the symlink remains an extra. - `cli add B-add-5` asserted the fifo-generic wording for a named symlink. It now asserts the symlink-specific wording.

Four `commit` invocations inside the new B3 tests use `runCommitEnv` with an explicit user rather than bare `runZit`; the isolated e2e environment has no resolvable author, which is a harness requirement, not a behavior change.

TEST EVIDENCE

In this worktree at the committed tree: `zig fmt --check .`, `zig build`, `zig build test`, `zig build e2e` (417 tests) and `zig build dst` each exit 0 — full battery, no filtering. Pre-fix the four B3 repro tests failed and the `clean --dry-run` guard passed, as designed.

No borrowed technique: the entry-tag shape is original to this change. No performance claim is made. check-in: 1aeb531cac user: dmestas tags: blockers

Three commits inside one second made 'zit cat f.txt tip' return the root's content and 'trunk' the middle's, while 'zit leaves' named the newest — the binary contradicting itself, exit 0, no warning.

The diagnosis that opened the campaign was wrong and is worth recording: it blamed a single lexicographic-hash tiebreak in mergeBaseOf. Building the equal-mtime chain in BOTH hash orderings produced identical failures, which ruled hash order out as the mechanism. There were three independent tie sites — tipForm settled on events insertion order, resolveName on tagxref iteration order, mergeBaseOf on artifact hash. A fix confined to the originally-blamed line would have left tip and trunk still wrong.

Equal event.mtime is now settled by ancestry: a descendant beats its ancestor. Genuinely concurrent nodes keep a deterministic least-hash fallback — hash order between unrelated leaves was never the defect. Timeline gets a second pass re-ordering equal-mtime runs descendants-first.

Ride-alongs on the same surface: 'update' accepts symbolic names (SF1), and a 'tip' naming a non-leaf is now an in-binary assertion (SF5) — the tripwire that would have caught this originally.

Merged tree re-verified on trunk: fmt, build, test, e2e, dst 6x1000 all green. Remote CI is unavailable (self-hosted runner offline); the local battery is the gate per operator direction. check-in: bc7b914316 user: dmestas tags: trunk

Three commits made inside the same second made `zit` return the WRONG file content for `tip` and `trunk`, and made the binary contradict itself: `zit info tip` reported "leaf: no" while `zit leaves` named the same check-in a leaf. `zit cat f.txt tip` returned the ROOT's content and `zit cat f.txt trunk` returned the MIDDLE's, on a three-commit chain whose newest content was `v3`. A version-control system that silently hands back an old revision under a name that means "newest" is disqualifying, so this lands before anything else.

WHAT WAS WRONG — three independent tie sites, not one

The originally-recorded diagnosis blamed a single lexicographic artifact-hash tiebreak in `mergeBaseOf`. That was wrong for the reported symptom: the RED-proof gate built the equal-mtime chain in BOTH hash orderings and observed IDENTICAL failures, which rules out hash order as the mechanism. Fixing only that line would have left `cat tip` and `cat trunk` still returning wrong answers. The real picture:

- `tipForm` — `mtime > best_mtime`, a strict `>` with no tiebreak at all, so the first entry in `events` INSERTION order won. Symptom: `tip` -> ROOT. - `resolveName` — ties settled by `tagxref` hash-map ITERATION order. Symptom: `trunk` -> MID. - `mergeBaseOf` — lexicographic artifact hash. A genuine defect, proven RED at unit level, but not the cause of the tip/trunk symptom and unreachable from the e2e merge path.

WHAT CHANGED

Equal-`event.mtime` ties are now settled by DAG ancestry: a descendant beats its ancestor. Genuinely concurrent nodes — same mtime, no ancestry relation — keep a deterministic least-artifact-hash fallback, documented at each site; hash order between UNRELATED leaves was never the bug. The shared helper (`MtimeMaxPick`) is used by `tipForm`, `resolveName`, `openLeafOf` and `dateResolve`, so every symbolic-name surface settles ties one way.

Timeline ordering gets a second pass that re-orders each equal-mtime RUN descendants-first, deliberately overriding the hash tiebreak. It is a per-run repeated-maximal-element extraction, NOT a sort predicate: "descends-from, else hash" is not a strict weak order, and handing it to `std.mem.sort` would be undefined behavior. Runs are bounded by the check-ins sharing one millisecond.

Settling a tie by ancestry allocates, so `resolveName`/`resolve`/`openLeafOf` gained `OutOfMemory`. Every caller switches it as an ABORT, never as a mismatch or "already correct" verdict — reporting an allocation failure as the exit-0 up-to-date message is exactly the lie those switches exist to prevent. `repository_test`'s closed-error-set assertion moved 2 -> 3 for that reason: it encoded the pre-fix set, not an inconvenient expectation.

Two ride-alongs on the same resolution surface:

- SF1 — `zit update trunk` used to fail as "invalid check-in ID": update accepted ONLY canonical 40/64-hex. Its argument is a check-in name like every other verb's, so it now runs the shared 8.3 procedure. A canonical ID still short-circuits, leaving update's cold path byte-for-byte as it was. - SF5 — a `tip` that names a non-leaf is now an in-binary assertion, not just a test. It is legitimate ONLY under a non-monotone clock (a child stamped strictly earlier than its parent); a child that TIES its parent means the ancestry tiebreak failed to fire, which is the defect itself. This tripwire would have caught the original bug.

RED PROOF (recorded by the RED-proof gate, 2026-07-19; per BLOCKER-FIX-PLAN.md section 2, no product code changed until RED was proven)

Unit, `src/repostate_test.zig`, deterministic equal-mtime chains built directly in BOTH hash orderings — no wall-clock dependence:

repostate REGRESSION B1: tip resolves to the descendant on an equal-mtime chain (head has the greatest hash) repostate REGRESSION B1: tip resolves to the descendant on an equal-mtime chain (head has the least hash) repostate REGRESSION B1: resolveName picks the descendant on an equal-mtime chain (head has the greatest hash) repostate REGRESSION B1: resolveName picks the descendant on an equal-mtime chain (head has the least hash) repostate REGRESSION B1: tip and resolveName agree with the leaf set in both hash orderings repostate REGRESSION B1: mergeBaseOf picks the deepest common ancestor when every candidate shares an mtime [failed pre-fix: expected 2, found 1]

End-to-end, `src/e2e.zig`, same-second commits with NO sleep between them — same-second IS the point:

cli REGRESSION B1: same-second commits resolve tip and trunk to the newest check-in cli REGRESSION B1 (SF1): update accepts a symbolic name and lands on the newest check-in cli REGRESSION B1: open materializes the newest same-second check-in into a fresh clone cli REGRESSION B1: a same-second two-branch merge picks the correct base and is never up to date

All of the above failed against pre-fix trunk; the two hash-ordering pairs failed IDENTICALLY, which is the evidence that retired the hash-order theory.

TEST EVIDENCE NOW

In this worktree at the committed tree: `zig fmt --check .`, `zig build`, and `zig build test` each exit 0 — full battery, no filtering. The only pre-existing expectation changed is the `repository_test` error-set count noted above, and it changed because it encoded the old set.

Markers `// REGRESSION B1:` are stable so state probes can grep trunk for them.

No borrowed technique: the ancestry tiebreak and the per-run topological micro-ordering are original to this change. check-in: bdb49cc5ca user: dmestas tags: blockers

Lands the last of the seven 0.1.0 release blockers. merge3 — the three-way merge — had no fuzz target, and silent merge corruption is the worst failure a version-control system can have, because it produces a tree that looks right.

The merged tree was re-verified on trunk after the merge, not inherited from the branch: zig fmt --check ., zig build, and zig build test all exit 0. The merge reported no conflicts and touched four files; fossil extras is empty, so nothing referenced went unadded. The conflict-marker sequences a repo-wide grep reports in src/merge3.zig and src/e2e.zig are that module's own sentinel constants and the tests asserting on them, not merge residue.

Landed by hand rather than by the release workflow: its TigerStyle gate spent its three-round budget on this diff and halted without a confirming pass. The final round's two blockers were real — a zig fmt failure and an oracle hole where conflict spans were validated individually but never as ordered and disjoint, which would have let one widened span exempt every line from oracle 4 — and both were fixed by the round that followed. Verified here before landing: fmt clean, the ordered/closes_once checks present, and merge3_properties running clean at seed 1 over 2000 rounds. check-in: 08e7c6d6f1 user: dmestas tags: trunk

Silent merge corruption is the worst failure a version-control system can have — it produces a tree that looks right — and merge3 had no fuzz target. This adds one, driving the merger with generated base/current/other triples and asserting the properties that must hold for any input.

Oracle 4 (no invented lines) needs a carve-out, because the merger is supposed to fabricate lines inside a conflict envelope. That carve-out is only sound if the recorded spans really are envelopes, so expectNoInventedLines validates the claim before subtracting anything: each span must be in-bounds, open at a line boundary with conflict_sentinel, close with conflict_terminator, start at or after the previous span's end, and carry no second terminator inside it.

The ordering and interior-terminator checks are load-bearing, not belt-and- braces. inAnySpan matches on overlap, so an over-long span exempts every output line up to its end. End-pinning alone admits a single span stretched from the first envelope's start to the last one's end — it opens and closes correctly and overlaps nothing — which would exempt the clean lines between two envelopes from the oracle entirely. closes_once catches that case on the first envelope's terminator. merge3 asserts ordering itself, but only under runtime_safety, which a ReleaseFast sweep — the build a fuzz run uses — erases; this loop holds in every optimize mode.

merge3.zig gains one export: conflict_terminator, the closing counterpart of the existing conflict_sentinel, with a comptime tripwire pinning its shape. Additive only, no behavior change — it lets the oracle pin both envelope ends against the module that produces them instead of re-typing the literal, so the two cannot drift apart.

Battery green in the worktree: zig fmt --check ., zig build, zig build test, zig build e2e, zig build dst (6 seeds x 1000 steps). The new target runs clean at seed 1 over 2000 rounds; no bug was found, so no regression seed is pinned. closed check-in: 21ca364fb3 user: dmestas tags: release-0.1

Two gaps the first green run exposed.

The repository carried 26 fuzz targets that CI never fuzzed. They reached CI only through their fixed-seed smoke tests inside `zig build test`, so the fuzzing investment was half-realized: the targets compiled and ran a handful of canned cases, but nothing swept them. `zig build fuzz` runs one target per invocation, so the new step loops. The target list is read from the step's own usage output rather than kept in the workflow — a target added to fuzz_tests.zig is swept automatically, with no second list to drift. Seed and rounds are fixed (1, 2000), not random: a red run has to be reproducible verbatim on a developer machine. Bare `zig build fuzz` exits non-zero because it is a usage error, so the enumeration tolerates that; every real invocation still fails the job. Verified by running the identical block under bash — 26/26 targets pass at seed 1.

src/ci_test.zig moves with it. `fuzz` leaves not_in_ci (its stated reason was that wiring a bounded CI invocation belonged to a later step — that step is this one) and a new ci_parameterized table records it as covered-in-a-loop, carrying the exact anchor that proves the invocation exists. The anchor is verified, not trusted: an entry whose anchor drifts out of the workflow fails like any other gap. That distinction is kept separate from not_in_ci on purpose — conflating 'runs, in a loop' with 'deliberately skipped' is how a step silently stops being covered while a stale excuse keeps the pin green.

actions/checkout v4 -> v5 clears the Node 20 deprecation warning the green run reported. check-in: 394b4efa27 user: dmestas tags: trunk

GitHub-hosted runners are unavailable to this repository: it is private, and private-repo Actions minutes are billed, so the first hosted run never started — 'recent account payments have failed or your spending limit needs to be increased', zero steps executed. The gate now runs on the self-hosted mac-mini-zit (macOS/ARM64), which is online and already carries the toolchain.

- runs-on names the specific machine ([self-hosted, mac-mini-zit]) rather than bare self-hosted, so a second runner joining the account cannot silently pick this job up on a different OS or architecture. - The Zig tarball is the aarch64-macos build with its published digest from ziglang.org/download/index.json. macOS ships shasum rather than GNU sha256sum, so the digest is compared explicitly; a swapped tarball still fails the job rather than building silently. - fossil is verified rather than apt-installed — the runner is a developer machine carrying 2.28, newer than what apt ships. The step hard-fails when fossil is absent, because a skipped smoke step would silently stop exercising the conformance claim the release rests on.

src/ci_test.zig moves in lockstep: the runs-on line, the digest constant, the digest-check form, and the fossil-guard pin all now assert the macOS shape. Pins and workflow must change together or zig build test goes red, which is the point of having them. check-in: c8cccb2723 user: dmestas tags: trunk

Lands P4-F6, closing the last unfuzzed attack surface in the release scope. transport.zig and serve.zig are the only two files a remote peer can reach with bytes it fully controls, and neither had a fuzz target: the sync_parsers_adversarial target covers the layer above them, so the HTTP framing itself — the first code to touch untrusted input — was exercised only by hand-written smoke cases. These two targets hit that framing directly.

The increment: src/transport_fuzz.zig (205 L) and src/serve_fuzz.zig (303 L), registered in the fuzz_tests.zig dispatch table alongside the existing 24 and pinned by that file's registration test. serve.zig's driveHttp is promoted to pub with a comment stating why — it is the receiveHead to handleHttpRequest seam the smoke tests and the fuzz target both need, and duplicating it would have meant fuzzing a copy of the request path rather than the real one. Both sides stay in-memory, so neither target binds a port and neither can flake in CI. dst.zig picks up the two targets plus fuzz_tests.zig itself, the latter so the registration pin has a test step to run in: zig build fuzz has none.

Evidence, re-verified on the merged tree rather than on the branch, since trunk had advanced: zig fmt --check ., zig build, and zig build test each exit 0. Both new targets run clean seeded — invoking zig build fuzz with each target name and --seed 1 exits 0 for transport_frame_garbage and for serve_request_garbage — and found no crash, leak, or UB to fix, so this step carries no pinned-seed regression. The merge reported no conflicts; a repo-wide grep for conflict markers is clean, and fossil extras is empty, so both added files are tracked and nothing referenced went unadded. check-in: b8db5ecabd user: dmestas tags: trunk

The 24 existing fuzz targets cover the delta, artifact, sync-parser and logstore layers, but not the two CLI-layer modules that consume bytes an untrusted remote peer chose. `sync_parsers_adversarial` covers the layer above; the HTTP framing itself was unfuzzed. These are the last two wire surfaces on the release bar, and they are what a hostile peer reaches first.

What landed:

- `src/transport_fuzz.zig` — `frameGarbage`, registered as `transport_frame_garbage`. Client-side §4/§4.1 framing and redirect policy: the round-trip law (whatever `frame` produces, `unframe` returns exactly those plaintext bytes), mutation of framed containers (bit damage never survives as *different* plaintext — it either fails the container's Adler-32/zlib checks or, in the length-field range the §4.1 compression-length erratum makes a capacity bound, decodes back to the same bytes), and garbage `Location` headers through `resolveRedirect`. Totality is the asserted contract: every input yields a value whose postconditions hold or a declared member of `TransportError`.

- `src/serve_fuzz.zig` — `requestGarbage`, registered as `serve_request_garbage`. Server-side HTTP request path: raw bytes into `std.http.Server.receiveHead`, then `handleHttpRequest`'s dispatch (`classifyXfer` -> body read -> responder -> reply framing). It does not re-feed `handleXfer` in isolation — that decoding is already fuzzed twice — it reaches it only as the tail of a full-path dispatch, which is the point. Asserted contract: any `receiveHead` error is a clean rejection, `handleHttpRequest` returns void, and any produced response begins with an HTTP/1.1 status line.

- `src/serve.zig`: `driveHttp` becomes `pub`. It is the request-path seam two callers need and neither should reimplement — the §4 smoke tests and this fuzz target. In-memory reader/writer on both sides, so the target binds no port and cannot flake in CI.

- `src/fuzz_tests.zig`: both targets registered in the `targets` table, and `targets` becomes `pub` for a new structural registration pin. An unregistered target compiles, passes review, and is then never run by any invocation; the pin asserts every target the release bar names is actually reachable from the runner, so the registration cannot rot.

- `src/dst.zig`: aggregates both new files plus `fuzz_tests.zig` into `zig build test`. This root is the one that reaches serve.zig and transport.zig relatively while carrying the `zit` dep those two import; `zig build fuzz` has no test step, so it is also the only place the registration pin can run.

No bug found, so no fix and no pinned-seed regression in this commit — both surfaces held over the seeded runs below. The targets are the standing check, not a one-time sweep.

Test evidence (this worktree, after `fossil update` absorbed the sibling `zit open` commit 5ba418801d and its 8 modified files):

- `zig build fuzz -- transport_frame_garbage --seed 1 --rounds 2000` — clean, no crash/leak/UB. - `zig build fuzz -- serve_request_garbage --seed 1 --rounds 2000` — clean, no crash/leak/UB. - `zig build test` — green, including the new registration pin and the fixed-seed smoke tests at the foot of both new files. - `zig build` and `zig fmt --check .` — green.

No borrowed technique in this change. check-in: cec4afaf89 user: dmestas tags: release-0.1

Lands the last of the three P3 CLI cliffs. A clone previously produced only an artifact log: there was no verb that turned one into a working tree, so clone-to-usable-checkout was unreachable and unproven by any test. `zit open` closes that path, resolving the trunk tip and materializing the check-in into the target directory.

The merged tree — not merely the branch — was re-verified on trunk after the merge: zig fmt --check ., zig build, and zig build test all exit 0. The merge reported no conflicts and touched six already-tracked files; fossil extras is empty, so nothing referenced went unadded. The conflict-marker byte sequences that a repo-wide grep reports in src/merge3.zig and src/e2e.zig are that module's own conflict sentinel and the tests asserting on it, not merge residue.

Landed separately from the sibling status increment (3b7fe2fbe1) rather than folded into one commit: the two are independent release steps and each keeps its own subject and evidence. check-in: 91c682fd06 user: dmestas tags: trunk

Lands release step P3-F5-status on trunk, completing the B-status-16 deferral.

The increment: `status` previously classified only `added` and `missing`, so a tracked file that was present but modified produced no line at all — the gap was documented in a comment, in `--help`, and in an e2e test that pinned the silence. Documenting a hole is not the same as not having one, and "your working copy looks clean" is the wrong thing for a version control system to say about an edited file. `status` now resolves the current check-in and compares every tracked file against it, emitting an `edited` row when the bytes or the file mode differ; a file whose contents match is still not listed.

The comparison is not a second implementation. The check-in resolution, the legacy trailing-separator F-card tolerance, the delta-manifest walk, and the merge against the sorted managed set were all machinery `diff` already had; that machinery is extracted into `CheckinBaseline` and `walkWorkingTree`, and both verbs now run through it, with each verb supplying only a sink. `diff` is a pure refactor here — same output, less code. Dirtiness remains a non-failure: every `added`/`edited`/ `missing` row exits 0 (B-status-15); only a genuine comparison failure exits 1. `--help` no longer defers edited-file detection and now narrows the deferral text to the two cases that genuinely remain out of scope.

This lands the full detection called for by P3-F5, not the fallback. The plan's fallback of record required an explicit operator decision; none was taken and none was needed.

Merge evidence: `fossil merge release-0.1` reported no conflicts, updating only src/e2e.zig and src/main.zig. The tree carries no conflict markers — the three open-marker occurrences a grep turns up in src/e2e.zig are string literals inside assertions pinning zit's own merge3 conflict sentinel, not merge residue.

Verification evidence: the merged tree — not merely the branch — was re-verified on trunk after the merge. `zig fmt --check .`, `zig build`, and `zig build test` each exit 0. Behavioral evidence rides in the branch commit's new e2e coverage, which pins each acceptance criterion: an edited tracked file is reported as edited; a rewrite with identical bytes (mtime bump, same content) is not reported; an executable-bit-only change is reported; a file deleted from the check-in but no longer tracked is still not reported; and a delta checkout with an absent B-card baseline fails cleanly rather than reporting a false clean tree. The e2e that pinned the old deferral is replaced by those tests, and the help-text e2es compare against a hand-written expected string, so the `--help` change is pinned too.

`fossil extras` is empty, so the merge adds no file it fails to track.

No performance claim is made here. No borrowed techniques in this change, so no attribution is owed. check-in: 3b7fe2fbe1 user: dmestas tags: trunk

`zit clone` builds a repository file and nothing else. The checkout it left behind was the same UNBORN record `init` writes (`version == ""`, branch `trunk`), with no managed set and no files, and there was no way to turn it into a usable tree: `zit update` accepts only a literal 40/64-hex check-in ID, so a freshly cloned tree could not name its own tip. Clone was a dead end.

`zit open` is the second half of fossil's own clone+open UX. It resolves the tip of the main branch out of this repository's derived state and hands materialization to the SAME `update.applyCheckin` engine every other working-tree move rides — journal-armed, transactional, rollback-safe. Tip resolution is the only work that is open's own; everything else is wiring.

What changed:

- `cli.parseOpenArgs` / `OpenArgs` / `OpenResult`: an operand-free surface. `-h`/`--help` is the only accepted token and wins over every other token; a bare `-x` is an unknown option, anything else an extra argument. The verb takes no operand by design — it derives its target from the repository. - `main.runOpen` plus the `open` entries in the `Verb` enum, the dispatch switch, and the `verb_help` table, so the verb is added in one place and the total switch stays total. `runOpen` writes NO checkout record and NO managed set of its own: `init` already wrote the unborn record, an absent managed set already reads as the empty set, and the update engine stays the single writer of the born record. A second writer of that bootstrap state would only be a second thing to keep in sync. - `main.openApplyFail`: one arm per `update.ApplyError` variant and no `else`, so a new variant fails the compile and forces a decision, mirroring `updateApplyFail`. `SymlinkUnsupported` / `InvalidPath` / `ReservedPath` are raised while planning the TARGET manifest and are reachable on a perfectly intact repository, so they get honest prose instead of a corruption claim. - `update.planUpdate`: an UNBORN record now takes the same arm as an absent one. Unborn is the normal state of every fresh repository, so without this the first `update` after a clone handed `""` to `buildPlan`, failed `artifact.validateName("")`, and reported `CurrentStateInvalid` — a clean, correct tree diagnosed as broken. A record that names no check-in but claims a merge parent or a pending special operation stays incoherent and is still `CurrentStateInvalid`. - BORN-ness, not presence, is the "already open" signal. A presence-based gate would have rejected a clone followed by an open on every clone, the primary path the verb exists to serve.

Test evidence (all run in this worktree after absorbing the sibling P3-F4 commit 281c0ed815, which arrived during this step and was merged by hand in `src/e2e.zig` — both sides had appended the identical P3-F4 block, so the duplicate was dropped):

- `zig build test` — green, including new `update_test.zig` coverage of the unborn-record arm and its incoherent-record rejections. - `zig build e2e` — green, including the P3-F3 block: clone → open → byte-identical tree → update → commit round-trip; a plain clone's unborn checkout tolerated by `update`; an untracked file in the way failing the open and materializing nothing; re-opening an already-open tree refused with no change; a repository with no check-in reported rather than failed; outside a repository failing with the not-a-repo diagnostic (exit 1); unknown option and positional as usage errors (exit 2); and the verb present in top-level help with one help text behind both `--help` and `help open`. - `zig build smoke` — green, with the new S6 scenario (§3.7/§4): `zit clone` + `zit open` against a REAL fossil server materializes the committed bytes byte-for-byte. This is the cross-implementation proof that the new path produces a working tree fossil itself agrees with. - `zig fmt --check .`, `zig build`, and `zig build dst` (6 seeds x 1000 steps) also green.

No borrowed technique in this change. No new file: the work lands entirely in existing modules. check-in: 5ba418801d user: dmestas tags: release-0.1

Completes the B-status-16 deferral. `status` previously classified only `added` and `missing`: a tracked file that was present but modified produced no line at all, and the gap was documented in a comment, in `--help`, and in an e2e test that pinned the silence. Documenting a hole is not the same as not having one, and "your working copy looks clean" is the wrong thing for a version control system to say about an edited file.

What changed:

- `status` now resolves the current check-in and compares every tracked file against it, emitting an `edited` row naming the path when the bytes or the file mode differ. A file whose contents match is still not listed.

- The comparison is not a second implementation. `diff` already resolved the current check-in, tolerated the legacy trailing-separator F-card, walked the delta manifest, and merged that effective file set against the sorted managed set. That machinery is extracted into `CheckinBaseline` (open/resolve) and `walkWorkingTree` (the merge), and both verbs now run through it. `diff` is a pure refactor here -- same output, less code. The `diff*Fail` diagnostic mappers become `compare*Fail` and take the verb as a parameter, the shape `checkoutFail` and `managedFail` already used.

- A verb supplies only a sink with `emit(entry)`. `DiffSink` renders diff records; `StatusSink` renders human rows and drops the deleted-from-check-in class, which `status` still defers because it iterates the managed set. The sink is comptime-generic rather than an erased pointer pair: both sinks are known at compile time, so the call stays direct and type-checked.

- The whole report is buffered and written once, as `diff` already did. A comparison failure part-way through the walk now leaves stdout empty rather than a header above a truncated report. Dirtiness is still never a failure: every `added`/`edited`/`missing` row exits 0 (B-status-15). Only a genuine comparison failure -- unreadable tracked file, corrupt or unresolvable check-in -- exits 1.

- `CheckinBaseline` is self-referential (the walk borrows the resolver, which borrows the log, which reads through the file storage), so it is initialized in place and must not be moved. The open/deinit contract used to rest purely on each call site placing its `defer` correctly; an `opened` flag now makes that invariant assertable, and both `deinit` and the failure path assert it.

- `walkWorkingTree` carries a termination guard against the exact bound (one step per managed path, one per effective file), plus a per-iteration progress assertion, because correctness of the merge rests on every switch arm advancing exactly one cursor. Debug-only, alongside the existing debug-only assertion that the managed set is sorted.

- `--help` no longer defers edited-file detection. It documents the three row classes and narrows the deferral text to the two cases that genuinely remain out of scope: a file deleted from the check-in but no longer tracked, and untracked "extra" files -- pointing at `zit diff` and `zit extras`.

Test evidence: new e2e coverage pins each acceptance criterion -- an edited tracked file is reported as edited in the born state; a rewrite with identical bytes (mtime bump, same content) is not reported; an executable-bit-only change is reported as edited; a file deleted from the check-in but untracked is still not reported; and a current delta checkout with an absent B-card baseline fails cleanly rather than reporting a false clean tree. The pre-existing e2e that pinned the deferral is replaced by the tests above. The help-text e2es compare against a hand-written expected string, so the `--help` change is pinned too. `zig build` and `zig build test` pass in this worktree after absorbing the sibling add/rm recursion commit (281c0ed815), and the commit is proved against a clean `fossil open` checkout running `zig build` then `zig build test`. check-in: 02d993f860 user: dmestas tags: release-0.1

Lands release step P3-F4-addrm on trunk. `zit add DIR` and `zit rm DIR` were hard errors directing the user to name individual files, which made `zit add .` and adding a source subtree dead ends. The increment makes both verbs recurse: `add DIR` expands over the already-shipped `extras.sweep` of the checkout root rather than introducing a second walker, so the exclusions, the no-follow symlink posture, and the tracked-set subtraction are the ones `addremove` and `clean` already use, with the sweep lazy and memoized so multiple directory arguments still perform one enumeration. `rm DIR` expands over the tracked keys via `ManagedSet.iterate` rather than over the disk, so an already-deleted directory remains forgettable. A single containment predicate, `pathUnderDir`, serves both verbs so the prefix-boundary case cannot diverge between them. Help text and exit-status wording now describe recursion instead of the removed directory error.

Merge evidence: `fossil merge release-0.1` reported no conflicts, updating only src/e2e.zig and src/main.zig; the tree carries no conflict markers (the open-marker occurrences that a grep turns up in src/merge3.zig and src/e2e.zig are that module's own conflict sentinel constant and the tests asserting on it, not merge residue). The merged tree — not merely the branch — was re-verified green on trunk after the merge: `zig fmt --check .`, `zig build`, and `zig build test` all exit 0. `fossil extras` is empty, so the merge adds no file it fails to track.

No borrowed techniques in this change, so no attribution is owed. check-in: fca1e073c2 user: dmestas tags: trunk

`zit add DIR` and `zit rm DIR` were hard errors that told the user to name individual files. That made the two most common invocations -- `zit add .` and adding a source subtree -- dead ends, and it was the last place where the CLI asked the user to do work the repository already knows how to do.

What changed:

- `add DIR` now expands to every untracked file beneath the directory. It reuses the ALREADY SHIPPED `extras.sweep` of the checkout root rather than introducing a second walker: the same walk, the same exclusions, the same no-follow symlink posture `addremove` and `clean` use. The sweep is lazy and memoized for the whole invocation, so `zit add a b c` over three directories still performs exactly one enumeration. Because the sweep already subtracts the tracked set and the depth-0 control names, neither can be re-inserted or re-reported by the directory path. - `rm DIR` expands over the TRACKED keys via `ManagedSet.iterate`, never over the disk, so a directory the user has already deleted is still forgettable. Keys are copied into the arena before the first removal, because `iterate()`'s slice and its backing bytes are invalidated by `remove` -- the same discipline `addremove` uses for its remove set. Ascending order is preserved and every expanded key still passes the per-key control-file guard (B-rm-7). - One containment predicate, `pathUnderDir`, serves both verbs, so the boundary case cannot diverge between them: `src2/c` is not under `src`, because containment requires the separator immediately after the directory's bytes. - No new diagnostic class. `zit rm .` with nothing tracked resolves to the existing not-tracked message rather than inventing an empty-expansion error; `zit add .` on a tree holding only control files adds nothing and succeeds. - The `add` and `rm` help text and exit-status wording now describe recursion instead of the removed directory error.

Test evidence: the B-add-5 and B-rm-5 contract tests were rewritten to pin the new behavior (a named symlink is still rejected; a directory now recurses; `.` at the root is never reported as outside the repository), and a new P3-F4 block of end-to-end tests covers nested trees, prefix-boundary siblings, multiple directory arguments sharing one sweep, --dry-run, --hard, and rm of a directory that no longer exists on disk. `zig build test` passes in this worktree after absorbing the sibling packaging commit (3645c03e2d), and the commit is proved against a clean `fossil open` checkout running `zig build` then `zig build test`. check-in: 281c0ed815 user: dmestas tags: release-0.1

The mirror is a derived view for running CI, never a source of truth — fossil is the repository, and every push is a replay of fossil history, which is why it pushes --mirror and nothing is ever committed git-side.

Why a script when 'fossil git export' already works: its configuration (mirror directory and autopush URL) is per-checkout state, machine-local and invisible to anyone else cloning this repo. The script documents the one supported way to run the export and fails with the exact 'fossil git export ... --autopush ...' fix line when a checkout has never been configured.

It also re-drives the push explicitly rather than relying on autopush. Autopush is best-effort: the first export of the CI commit hit a transient connection refusal to github.com, left the local mirror ahead of the remote, and 'fossil git status' still reported up-to-date — because that status describes the export, not the push. Re-driving makes the push's exit status the script's.

The mirror is PRIVATE and stays private; the script never touches visibility. check-in: ef4efe16b3 user: dmestas tags: trunk

CI is the multiplier for the rest of the 0.1.0 sequence: from here every fix lands with fmt/build/test/e2e/dst/smoke gated automatically, and the smoke conformance claim — zit artifacts and deltas validated against the real fossil binary — becomes continuously enforced instead of milestone-manual.

- .github/workflows/ci.yml: single ubuntu-latest gating job on push and PR. Zig 0.16.0 pinned by version AND sha256 digest, verified with sha256sum --check --strict before use; fossil installed for smoke; the battery runs in order with a 20-minute job ceiling and a 5-minute bound on smoke, which is the one step that can hang without producing output. - src/ci_test.zig: structural pins over the workflow, so the file cannot drift from what it claims. Each pin is anchored to a whole line with its YAML indentation — a loose substring is satisfied by the phrase appearing in a comment while the block that governs the run says something else. The digest pin names ZIG_SHASUM and the tarball together, so the digest this repo pins is provably the digest the workflow checks. - src/packaging_test.zig: a negative-space pin asserting every path build.zig embeds is version-controlled. This diff is why: build.zig came to depend on .github/workflows/ci.yml while that file was untracked, and bare 'fossil extras' does not list dotfiles, so the commit-discipline check reported clean. The pin runs 'fossil ls' and fails on any embed that is not tracked.

The mirror is PRIVATE (github.com/danmestas/zit) and stays private; publishing is a separate decision that is deliberately not part of this release. check-in: 8a003b2ada user: dmestas tags: trunk

Second increment of the 0.1.0 release sequence, landed on trunk as it completes rather than accumulating to a big-bang merge at the end.

The increment: build.zig.zon .paths named the whole docs directory. A Zig package is cut from the working tree, not from what fossil tracks, so the ignore-glob does not govern it -- a bare docs entry ships whatever sits under docs/ at package time, including the ignore-glob'd docs/plans/*.md working documents, which are internal and must never leave the repository. .paths now names docs/rfcs directly, which is also what the repo convention already states (0ad7fa92c6: "docs/ is for the RFCs only"); the manifest encodes that convention instead of relying on docs/ happening to stay clean.

Evidence: a new pin in src/packaging_test.zig asserts both halves -- that .paths contains "docs/rfcs", and, as negative space, that a bare "docs" entry is absent, so the ship-everything form cannot drift back unnoticed.

The merged tree was re-verified before this commit: zig fmt --check, zig build, and zig build test all green on the merge result. Green on the branch does not imply green on the merge, since trunk advances with concurrent work.

No borrowed techniques in this change, so no attribution is owed. check-in: 0c22d3a950 user: dmestas tags: trunk

`.paths` named the whole `docs` directory. A Zig package is cut from the working tree, not from what fossil tracks, so the ignore-glob does not govern it: a bare `docs` entry ships whatever sits under docs/ at package time — including the ignore-glob'd docs/plans/*.md working documents, which are internal and must never leave the repository.

Naming docs/rfcs directly is also what the repo convention already states (0ad7fa92c6: 'docs/ is for the RFCs only'); the manifest now encodes that convention instead of relying on docs/ happening to stay clean. A new pin in src/packaging_test.zig asserts it so the bare-docs form cannot drift back. check-in: 3645c03e2d user: dmestas tags: release-0.1

P1 landed on trunk (8117eab3b2) per the continuous-integration rule, so the release branch absorbs trunk to keep a single lineage. Content-identical merge — this records the ancestry so later increments do not re-traverse it. check-in: 6d229acebf user: dmestas tags: release-0.1

First increment of the 0.1.0 release sequence, landed on trunk immediately per the plan's continuous-integration rule rather than accumulating to a big-bang merge at P6.

- LICENSE at the repo root (BSD-2-Clause, copyright Daniel Mestas 2026). zit is an independent reimplementation from the Fossil RFCs, not a derivation of Fossil source, so the choice was open; BSD-2-Clause matches the Fossil heritage and the systems-Zig ecosystem. - build.zig.zon .paths names LICENSE, so it ships inside a fetched package. - The commit-description-* scratch file is gone and the pattern is in the versioned ignore-glob. - src/packaging_test.zig pins these as executable facts, including a negative-space pin asserting every repo-root path build.zig embeds is also named in .paths — the embeds attach to the test-only module, never to the exported zit module, so a consumer never depends on a file outside .paths.

The merged tree was re-verified before this commit (fmt/build/test green): green on the branch does not imply green on the merge, since trunk advances with concurrent work. check-in: 8117eab3b2 user: dmestas tags: trunk

The release plan is a working document, not a shipped artifact. Repo convention (0ad7fa92c6) is that docs/ carries the RFCs only, with docs/plans/* already in the versioned ignore-glob; the plan, the readiness assessment, and its earlier draft all belong there. P1 added the plan because its own scope text said to commit it — that instruction is wrong and has been removed from the plan.

The file is unchanged on disk, now at docs/plans/RELEASE-0.1.0-PLAN.md. It remains in the history of 122998a428 — fossil history is immutable and shunning it would be disproportionate for a working doc. check-in: 3179b6805a user: dmestas tags: release-0.1

A release without a license grants nobody any rights, so this is the legally gating step of the 0.1.0 sequence. zit is an independent reimplementation from the Fossil RFCs rather than a derivation of Fossil source, so the choice was open; BSD-2-Clause matches the Fossil heritage and the systems-Zig ecosystem.

What changed:

- LICENSE at the repo root, BSD 2-Clause, copyright Daniel Mestas 2026. - build.zig.zon .paths now names LICENSE, so the file actually ships inside a fetched package instead of only existing in the checkout. - The leftover commit-description-413190fb92be991f.txt scratch file is gone and .fossil-settings/ignore-glob carries commit-description-* so the class of file cannot drift back in. - src/packaging_test.zig pins the above as executable facts: LICENSE content, LICENSE named inside the manifest's brace-matched .paths block, a line-anchored ignore-glob pin, and a negative-space pin asserting every repo-root path build.zig embeds is also named in .paths. These acceptance criteria are file-structure facts, which rot silently because nothing executes them; the battery alone cannot catch a .paths regression. - build.zig grows build_unit_test_module: the pinned repository files attach as anonymous imports to a test-only compile of root.zig, never to the exported zit module. Attaching them to zit made every consumer's build depend on files outside .paths and a fetched package failed on a missing .fossil-settings/ignore-glob before compiling a line. The negative-space pin exists to catch exactly that recurrence. - docs/RELEASE-0.1.0-PLAN.md, the plan of record for the 0.1.0 release, is committed alongside the first step it describes.

Test evidence: zig build and zig build test green in the working checkout. This commit is additionally gated on a clean-checkout proof — fossil open into a fresh temp directory, then zig build and zig build test there — which is the check that catches a file referenced but never added.

No borrowed techniques in this change, so no attribution is owed. check-in: 122998a428 user: dmestas tags: release-0.1

These four bench-run outputs (baseline / step2-pickbase / step3-pack-redeltify / step4-samepath) were measurement artifacts committed under docs/plans/bench — they do not belong in version control (docs/ is for the RFCs only). Remove them from the tip and add docs/plans/* to the versioned ignore-glob so the pattern cannot recur. They remain in the historical check-ins that added them (9aaf485847 and the integration merges) — Fossil history is immutable; purging them from provenance entirely would require fossil shun, deliberately not done. check-in: 0ad7fa92c6 user: dmestas tags: trunk

Lands amend, artifact, bisect, log PATH, annotate, merge --cherrypick/--backout, and addremove — the VCS-verb-survey recommendations — onto trunk, already integrated with the storage branch's pack re-deltification.

- amend: mint display-metadata T cards, never rewrite history (also corrects the git-reflex table's wrong immutability lesson). - artifact: the plumbing window (whatis + raw dump) over the one parser. - bisect: DAG binary search (bad/good/next/status/reset), state in .zit-bisect. - log PATH: per-file history folded into log (fossil finfo). - annotate: per-line provenance; the version chain is ordered by TOPOLOGY (matching fossil's generation walk), not mtime, so a parent is never misattributed to its child on a timestamp collision. - merge --cherrypick/--backout: alternate-baseline special merges recording a 4.7.14 Q card, rendered by info; the plain merge surface is byte-identical. - addremove: one sweep, add every extra and drop every missing.

Built decomposed (focused implementers + adversarial review) after the monolithic workflow thrashed on API instability. 1678 unit + 376 e2e + dst 6x1000 green. check-in: e5fffafdb8 user: dmestas tags: trunk

Brings trunk bab930 (the storage branch's at-rest re-deltification / zit pack generational rewrite, plus src/pack.zig and its bench baselines) into the cli-verbs-2 slice. One conflict, in src/root.zig — both branches added a module export at the same spot; resolved by keeping both (pub const bisect and pub const pack). logstore.zig and main.zig auto-merged. Integrated tree green: 1678 unit + 376 e2e; the seven new verbs and the pack pass together. closed check-in: e640119891 user: dmestas tags: cli

zit info on a cherrypick or backout check-in now shows a provenance line derived from the parsed 4.7.14 Q card: a 'cherrypick:' line for Q plus and a 'backout:' line for Q minus, each carrying the full REV hash, placed right after the parent and merge lines with the value column aligned. It reads through the shipped artifact parse path (repo.manifest then artifact.parse then parseQCard, iterating manifest.q) — no bespoke re-parse. A check-in with no Q card prints no such line and is byte-identical to before.

Also fixes an allocator-symmetry bug uncovered here: renderInfo now threads gpa (was arena) so info's manifest frees against the same allocator, ending an Invalid free panic at repo.deinit on every info call. Closes the last deferred clause of the cli-verbs-2 slice. 1678 unit + 376 e2e green. check-in: 4b1be918ab user: dmestas tags: cli

An adversarial review found zit annotate could charge a line to the too-recent CHILD when a parent and child check-in share an identical (or non-monotone) event mtime — the chain was ordered (mtime asc, hash). Fossil orders its annotate walk by pure topology (generation number, descendants.c/diff.c), so a parent is ALWAYS processed before its child. Match that.

New repostate.ancestryLinearized runs Kahn's over the reversed (child->parent) ancestry edges within the file's ancestor set, emitting newest->oldest with a (mtime desc, hash) ready-queue among topologically-INCOMPARABLE nodes, then reverses to the engine's oldest-first order — topology is now the PRIMARY key, mtime/hash only orders incomparable versions. annotateFile consumes it in place of the old sort; the attribute engine (primary-parent pass-through, oldest origin, binary refusal, layout) is unchanged. Amends the RESOLVED annotate-attribution rule. Linear/monotone history is byte-identical (degenerates to mtime-ascending); new tests (same-mtime parent-first, non-monotone, merge primary-parent) fail against the old order. 1678 unit + 376 e2e green. check-in: ff9662dfee user: dmestas tags: cli

fossil-style best-of-N delta base selection (pickBase, plan §5) plus a `zit pack` re-deltification pass with a monotonic-shrink guard (§6.1) and same-path candidates (§6.2). At-rest only: all four RFCs conformant, wire interop preserved, every repacked frame hash-verified against the log.

Measured (whole-file, index-inclusive): sqlite: 207.3 MB -> 174.4 MB (1.40x -> 1.18x vs fossil 147.7 MB) fossil-scm: 117.5 MB -> 108.1 MB (1.63x -> 1.50x vs fossil 72.2 MB)

The monotonic-shrink guard (keep the smaller of {existing frame, re-encoding}) is what turned re-deltifying a clone of fossil-quality wire deltas into a net win instead of a +33% regression. check-in: bab9303056 user: dmestas tags: trunk

zit addremove [--dry-run] — checkout-layer convenience (fossil/hg parity; git add -A). ONE scan via the shipped extras.sweep (the exact untracked/exclusion walk zit extras and zit clean use) is the ADD set; every managed file absent from disk (no-follow stat, as status checks) is the REMOVE set. Both mutate the managed set through the shipped ManagedSet.insert/remove/write (write-temp + fsync + rename) — no second walker, no ad-hoc mutation. A present-but-modified file is never touched; control/never-tracked names are never added. --dry-run leaves .zit-managed byte-identical and prints the same report (ADDED block then REMOVED block, each ascending, root-relative). 1675 unit + 374 e2e green. check-in: f0dc5f4e2a user: dmestas tags: cli

Both are alternate-baseline choices inside the shipped merge machinery, per merge-flags contract B-merge-30..40 (which lifts merge.md's v1 non-goal); the flagless zit merge NAME surface is byte-identical (B-merge-31 re-asserts it).

- --cherrypick REV: three-way with base = REV's primary parent, other = REV, current = checkout (apply REV's own changes). --backout REV: base = REV, other = REV's primary parent (reverse REV). Same classifyFile/applyMerge engine; a root REV yields an empty side; zero entries refuse (B-merge-39). Flags are mutually exclusive and reject an extra positional / dirty tree. - A cherrypick/backout commit stays SINGLE-parent (REV is never a merge parent) and mints exactly one artifact 4.7.14 Q card (Q +rev / Q -rev), cleared one-shot; a plain merge keeps its two-token P card and empty Q. - The pending op is a new checkout special_op field (4th TLV, no default, threaded everywhere); undo serializes it (journal fmt v1->2) so undo unwinds a pending cherrypick/backout (B-merge-35).

B-merge-1..29 e2e all still pass. 1675 unit + 362 e2e green; fmt clean. Follow-up: B-merge-41 (zit info Q-card render line) deferred — its pinned text was absent from the plan; the Q card is already readable via zit artifact. check-in: 20bf0a31c6 user: dmestas tags: cli

zit annotate PATH — which check-in introduced each line of one tracked file at the current checkout, and when. One canonical spelling (no blame/praise). The engine walks the file's full-ancestry version chain (repostate.ancestorsOf, the same 3.3 walk merge-base/bisect use; per-version content via Repository.fileAt, the one 8 effective-set query), diffs adjacent versions with the one house line-diff core (merge3.matchLines), and pushes each line's origin back to the OLDEST version carrying it. Across a merge, a line in ANY parent side is charged to that parent (primary first, repo-state 3.2), never to the merge; the merge is charged only for lines in no parent version. Output: 10-char hash, ISO date from event mtime, the line verbatim; a binary file refuses exit 1. Reviewed adversarially (merge attribution hand-traced correct). 1673 unit + 352 e2e green. check-in: f774a1a2a7 user: dmestas tags: cli

The bisect check-in landed every edited file but not the new bisect.zig itself (committed without a prior add), so that check-in would not build from a clean checkout. Add the file; no code change. check-in: b937bca55b user: dmestas tags: cli

Same-path predecessors sourced from check-in manifest walk, offered ahead of chronological window candidates (fossil's mlink analog per §6.2).

fossil-scm-clone: zit=108143984B fossil=72245248B ratio=1.4969 [Step-4 packed store (measured this run), accounting EXACT (header64 + zlib + delta + config == 108,143,984): zlib 8369 frames / 82,268,624 B (76.1%, avg 9830 B); delta 59130 frames / 25,875,208 B (23.9%, avg 437 B); config 1 frame / 88 B; raw 0. Artifact-type split: checkin/manifest 20848 / 23,816,728 B (22.0%), other-artifact 6929 / 4,706,432 B (4.4%), file-blob 39722 / 79,620,672 B (73.6%). Header+padding overhead 3,710,123 B (3.4%).] | sqlite: zit=174352688B fossil=147709952B ratio=1.1804 [Step-4 packed store (measured this run), accounting EXACT (header64 + zlib + delta + config == 174,352,688): zlib 9248 frames / 113,074,896 B (64.9%, avg 12226 B); delta 121746 frames / 61,277,640 B (35.1%, avg 503 B); config 1 frame / 88 B; raw 0. Artifact-type split: checkin/manifest 36515 / 65,427,440 B (37.5%), other-artifact 4775 / 5,462,856 B (3.1%), file-blob 89704 / 103,462,240 B (59.3%). Header+padding overhead 7,211,093 B (4.1%).] vs baseline: fossil-scm-clone: zit=117528088B fossil=72245248B ratio=1.627 [raw=0B/0f; zlib=92073728B/9647f (78.3%); delta=25454120B/57852f (21.7%); config=176B/2f. Header+padding overhead 3711845B (3.2%). Artifact-type: checkin/manifest 26721968B/20848, other 4835264B/6929, file-blob 85970616B/39722. Accounting exact.] | sqlite: zit=207344544B fossil=147709952B ratio=1.404 [raw=0B/0f; zlib=140422768B/10847f (67.7%); delta=66921536B/120147f (32.3%); config=176B/2f. Header+padding overhead 7212808B (3.5%). Artifact-type: checkin/manifest 81006048B/36515, other 5531960B/4775, file-blob 120806296B/89704. Accounting exact.] check-in: 0375766879 user: dmestas tags: storage

zit log CHECKIN [PATH]. With no PATH, behavior is byte-identical to today. With PATH, the ancestry walk emits only the check-ins that CHANGE that path: a check-in K changes PATH iff PATH's effective content (via Repository.fileAt, the one artifact 8 effective-set query — no CLI-side F-card re-derivation) differs from PATH's content in K's PRIMARY parent (first-listed P card, repo-state 3.2). Presence flips count (root add, delete, rename departure/arrival as delete+add, no old-name following); equal hashes are no change; a phantom parent reads as absent. walkLog gained an optional filter; the null path preserves the shipped DFS verbatim. The finfo/log split was historical accident, not design — one deep log replaces a shallow sibling, no new verb. 1661 unit + 343 e2e green; fmt clean. check-in: 6a360f33ff user: dmestas tags: cli

zit bisect bad NAME | good NAME | next | status | reset. Marking bad/good moves the checkout to the next probe automatically (fossil parity); next re-announces it; reset restores. The candidate set (full-ancestry ancestors of bad minus the good ancestor-sets minus skipped), the lower-median probe by ascending event-mtime with hash tiebreak, and the culprit are ONE general-purpose repostate query RepoState.bisectSpan, composed from collectAncestors / mergeBaseOf / isAncestorOf / mtimeOf / hashOf per the RESOLVED bisect-midpoint rule (repo-state 2/3.2/3.3/8.3) — the CLI never walks ancestry. Bisection state is checkout-local in .zit-bisect on the undo.zig state-file tier (atomic write + fsync, magic/CRC frame, corrupt -> exit 1), in the never-tracked/extras set; probe/culprit/reset moves go through the journal-armed update.applyCheckin behind requireCleanTree. Refusals (inverted marks, unrelated histories) exit 1. 1661 unit + 339 e2e green; fmt clean. check-in: 343d41b2f3 user: dmestas tags: cli

zit artifact HASH [--raw] — zit's cat-file/whatis. No flag: a whatis summary (hash, structural type per artifact 5.1/5.3, size, one line per A..W card in stored order, and the 6.2 Z self-checksum verdict). A blob reports type file, size, and binary-or-not. --raw emits the verbatim stored bytes. Resolves a 4-64 hex prefix over the LogStore (ambiguous -> exit 1), reads via the existing 7.2 blob path. Everything shown comes from the ONE existing artifact parser — refactored into frameNoZ/frame/assemble with a Z-tolerant parseWindow — never a CLI-side re-parse. 1649 unit + 335 e2e (13 new B-artifact) green; fmt clean. check-in: f477c3bf19 user: dmestas tags: cli

zit amend NAME [--comment TEXT] [--user NAME] [--date ISO] [--branch NAME] mints ONE control artifact whose T cards change how the target check-in displays — comment, user, date, and the repo-state 6.2 branch-move set — retargeted at the check-in hash, never '*'. History stays append-only: the original manifest is untouched and a new control artifact is crosslinked in (artifact 4.7.16 T / 4.7.5 D / 4.7.17 U / 4.7.19 Z; repo-state 4/5 crosslink, 5 tag propagation). Display is honored through a new general RepoState.activeTagValue / Repository.override consumed by timeline and info.

Also removes amend from the git-reflex rejection table: teaching against fossil-semantics amend with the immutability lesson conflated it with git's history-rewriting amend — amend is in fact the proof of zit's immutability, not a violation. 1643 unit + 322 e2e (15 new B-amend) green; fmt clean. check-in: 6c6d1babc2 user: dmestas tags: cli

The prior cli leaf was a closed integration point from before the recent slice; this reopens cli development at current trunk (timeline, mv, undo/redo, extras, clean, merge all present). The next verb slice — bisect, annotate, amend, artifact, addremove per the VCS verb survey — builds here and converges on cli, then one merge cli -> trunk. check-in: 9b5605ad79 user: dmestas tags: cli