Skip to content

B-M9JX-append-only-event-log-with-frontmatter-cache

Status: closed/abandoned

We keep hitting friction from using git as the store for mutable runtime state rather than immutable history. In a single /sdlc:task-work run we saw: the start-commit rebase conflicting on adjacent frontmatter lines (readiness_verified_at / last_reviewed); parallel sessions mutating the shared main index (untracked files staged under us, the prs: commit guard tripping); recording prs: requiring a direct push to main (blocked by the push guard); SHA-keyed quality baselines mismatching between the main checkout and the worktree; and audit_entities corpus-count noise in baseline diffs. The common cause: git history is append-only-shaped, but task/lease state is mutable and concurrently written, so every in-place edit is a conflict surface.

Idea: make an append-only event log the source of truth for entity state, and treat the frontmatter (and other views) as a derived, rebuildable cache of that log. Appends don’t collide the way in-place rewrites do — two sessions appending status -> in-progress / pr -> <url> events merge trivially, where two frontmatter rewrites conflict. State is reconstructed by folding the log; the cache can be regenerated at any time and is never the authority.

This would dissolve most of the conflict class we keep paying for:

  • No frontmatter rebase conflicts on start / verify / record-pr — each becomes an appended event, not a competing rewrite.
  • Recording the PR URL becomes an appended event, not a mutate-and-push-to-main.
  • Lease transitions and status flips stop racing on a single mutable ref/file.

Related: the existing alternative control plane state tracking backlog item raises the same theme (git-commit state tracking feels brittle); this proposes a concrete shape — event log + derived cache. Surfaced again by the PR #150 (add-backlog-capture) post-mortem’s runtime-state-in-git friction thread.

Out of scope for this capture (the design work this item seeds): the log format, where the log lives (refs? a log file? a sidecar store?), the cache-rebuild trigger, and how it interoperates with the lease protocol.

Closed 2026-08-16: absorbed by ledger phases E2 and E6 of D-VSLI-distributed-work-runner-architecture. E2 makes frontmatter status a derived cache over the authoritative lease, and E6 stores run records as append-only JSONL journals.


← Back to Backlog