fix(cli): followups drift correctness — working-tree scan (#229) + appended follow-ups (#231)

[montfort]

Summary

Fixes two silent-data-loss bugs in straymark followups drift, both reported by the reference adopter (Sentinel). Both are prerequisites for wiring drift into the Charter-close flow — RFC #135 Tier 3 (the agreed "stabilize drift first" step).

Combined fw-4.25.0 / cli-3.21.0.

Bugs fixed

#229 — default scan was blind to the working tree

The default scan considered only the committed git range (git diff origin/main..HEAD). At pre-commit time — exactly when the documented drift --apply flow runs — the new AILOG is uncommitted (usually untracked), so it was invisible: drift --apply reported "in sync" while real §Follow-ups content went unextracted, recreating the silent-miss class the tool exists to prevent.

Fix: the default scan now unions the git range with the working tree (git status --porcelain, handling ??/M/A/rename), mirroring the v0 reference script. --scan-all semantics unchanged.

#231 — appended follow-ups silently dropped

fully_extracted_ailogs was a whole-AILOG idempotency gate: once an AILOG id landed in it, the file was never re-scanned. Follow-ups appended to that AILOG later — the multi-batch Charter pattern, where one AILOG's §Follow-ups grows across batches — were silently lost, with no drift signal and no non-zero exit.

Fix (approach chosen with the maintainer — stable content hash + legacy fallback): drift now dedups per follow-up by a stable content hash (fu_content_hash = SHA-256 of AILOG id + origin section + description, 12 hex), stored as each entry's Source-hash. Already-extracted AILOGs are re-scanned and individual follow-ups deduped, so appended content is caught.

The stored hash is captured at extraction time and never recomputed from the (later paraphrased) registry heading — so it preserves the zero-false-positive property that motivated the original per-AILOG choice (curated entries paraphrase the source bullet). Legacy entries (pre-cli-3.21.0, no Source-hash) fall back to recomputing the hash from Origin + description. fully_extracted_ailogs is retained as informational metadata (shown by followups status), no longer the skip gate.

Tests

• parse_porcelain_ailogs across ??/M/A/rename + quoted paths, filtered to the agent-logs dir ([adopter] cli-3.19.1: default 'followups drift' scan misses uncommitted/untracked AILOGs — breaks the documented pre-commit flow (v0 script handled this) #229).
• fu_content_hash stability/discrimination, split_origin, render_new_entry embeds matching hash, registry_extracted_hashes (stored-hash + legacy fallback + the appended-follow-up miss case) (followups drift: late-added follow-ups to an already-extracted AILOG are silently skipped (fully_extracted_ailogs is whole-AILOG granular) #231).
• Updated 3 integration tests whose fixtures encoded the old whole-AILOG semantics; they now assert the correct content-hash behavior.
• Full suite green (24 suites). New code is clippy-clean.

Docs

FOLLOW-UPS-BACKLOG-PATTERN.md (EN/ES/zh-CN): documents the working-tree union, the per-follow-up content-hash dedup (replacing the "Per-AILOG vs per-bullet granularity" section that documented the #231 bug as an intentional trade-off), the auto-managed Source-hash field, and the revised role of fully_extracted_ailogs. Version bumps across manifest, governance footers, and doc tables.

Closes #229
Closes #231

🤖 Generated with Claude Code