TODO: SF should sha-track milestone files and diff on change
Some checks are pending
CI / detect-changes (push) Waiting to run
CI / docs-check (push) Blocked by required conditions
CI / lint (push) Blocked by required conditions
CI / build (push) Blocked by required conditions
CI / integration-tests (push) Blocked by required conditions
CI / windows-portability (push) Blocked by required conditions
CI / rtk-portability (linux, blacksmith-4vcpu-ubuntu-2404) (push) Blocked by required conditions
CI / rtk-portability (macos, macos-15) (push) Blocked by required conditions
CI / rtk-portability (windows, blacksmith-4vcpu-windows-2025) (push) Blocked by required conditions

Captures a real bug class observed during today's session: nothing
notices when a milestone file (CONTEXT.md, ROADMAP.md, slice PLAN.md,
etc.) is edited out of band — by a human, another agent, or a git pull.
SF keeps using the cached state and drifts.

Wanted: per-file sha tracking in sf.db, diff surface on change, +
hooks for accept/reject/import/archive. Storage cost negligible.

Useful in concert with the cross-repo triage and slash-command routing
gaps already in this TODO.md — together they close most of the
"unattended SF actually works" surface.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
Mikael Hugo 2026-05-11 19:45:05 +02:00
parent 41b7842fd8
commit 902be6d1de

35
TODO.md
View file

@ -89,6 +89,41 @@ Wanted: extend the triage JSON schema so each implementation task is
and update `appendBacklogItems` + a future milestone-escalator to read
the structured tier rather than re-parsing markdown.
## Detect manual edits to milestone files (sha-tracked, diff on change)
Milestone files (`CONTEXT.md`, `MILESTONE-SUMMARY.md`, `ROADMAP.md`,
`SUMMARY.md` + each slice's `PLAN.md` / `SUMMARY.md` + each task's
`PLAN.md` / `SUMMARY.md`) are source of truth for SF planning. Today
nothing notices if a human (or another agent) edits one out of band:
SF keeps using the in-memory or DB-cached state, drifts from disk, and
downstream tools see a different milestone than the human just wrote.
Wanted: on session start (and on each autonomous-cycle entry), walk
`.sf/milestones/**/*.md`, hash each file, compare to the last-known
sha in `sf.db` (new column `milestone_files.sha256`,
`milestone_files.last_seen_at`). For any file whose sha has changed:
1. Compute the diff against the last-seen content (stored alongside
the sha as a compressed blob, or just re-fetched from git if the
file is tracked).
2. Surface to the operator: "Milestone M003-abc123 CONTEXT.md changed
since SF last saw it — review or accept?" with the diff inline.
3. If accepted (or in autonomous mode with a configured policy), update
the DB-cached version + sha and continue. If rejected, restore from
the last-known content.
4. New files (sha not in DB) → import as if they were a fresh
`new-milestone` scaffold and add to the index.
5. Deleted files (DB has sha but file is gone) → mark the milestone
archived and prompt the operator before purging.
Useful for: hand-edits, cross-agent edits (another LLM in a different
session modified the milestone), git pulls that bring in upstream
changes to milestone files, the milestone-from-triage path I sketched
earlier (so the autonomous loop notices its own scaffold).
Storage cost: ~20 bytes per file (sha + last_seen_at) plus optional
compressed snapshot. Negligible vs. the rest of `sf.db`.
## Phases-helpers extension-load error on every SF run
Every `sf …` invocation today prints: