From 902be6d1deaa1c06053592b0dc5dc24badb1aae4 Mon Sep 17 00:00:00 2001 From: Mikael Hugo Date: Mon, 11 May 2026 19:45:05 +0200 Subject: [PATCH] TODO: SF should sha-track milestone files and diff on change MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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) --- TODO.md | 35 +++++++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+) diff --git a/TODO.md b/TODO.md index 2921fec69..908b59e23 100644 --- a/TODO.md +++ b/TODO.md @@ -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: