Context
After #128 (TDE activation trigger), #129 (fw-4.13.0 governance), #130/#131 (validator fix), and the Sentinel empirical validation at #128 comment (3 TDEs filed via StrangeDaysTech/sentinel#61), the question surfaced: what's next for follow-ups automation?
This RFC catalogs the four possible tiers of automation, the cost/benefit/risk of each, and the crystallization gate that should govern when (if at all) we advance from one to the next. It also lands the Tier 1 refinements from Sentinel feedback as the immediately actionable scope.
Current state of FOLLOW-UPS-BACKLOG-PATTERN.md
Verified by reading the framework + CLI source after fw-4.13.0 + cli-3.12.1:
| Surface |
State |
| `dist/.straymark/00-governance/FOLLOW-UPS-BACKLOG-PATTERN.md` |
Convention doc, v0, ~220 lines (with #129's FU→TDE promotion path included) |
| `dist/.straymark/scripts/` |
Only `check-charter-drift.sh` — does not contain `check-followups-drift.sh` |
| CLI Rust (`cli/src/`) |
Zero references to `followups` or `backlog` |
| `straymark charter close` |
Prompts `outcome_new_followups: u32` as a telemetry count only — does not inspect the backlog file or run any drift script |
| Sentinel adopter |
Owns the canonical `scripts/check-followups-drift.sh` (~296 lines POSIX bash) in their own repo |
Conclusion: today the pattern is documented convention only. The execution layer is fully adopter-side. The framework provides the schema for the registry file and the workflow prose — nothing more.
The 4 tiers
Tier 1 — Land Sentinel's refinements (fw-4.13.1, governance-only)
Scope: Apply the four refinements proposed in the Sentinel feedback comment:
- `AGENT-RULES.md §3` heritage trigger: distinguish strict heritage (prior Charter introduced the debt; subsequent Charters merely propagate it without re-introducing it — e.g., legacy DB schema decision) from pattern propagation (prior Charter set a pattern; subsequent Charters re-introduce the same debt by following the pattern). Both are TDE-worthy; current text reads as the first interpretation only.
- `AGENT-RULES.md §3` multi-module trigger: reformulate as "applies to multiple modules or Charter execution boundaries" — captures governance-trail debt that spans sessions without spanning code modules (Sentinel TDE-003 case: 2 specific AILOG docs whose impact crosses CHARTER-04 → CHARTER-08 → CHARTER-13 deferral boundaries).
- `FOLLOW-UPS-BACKLOG-PATTERN.md` "Promotion to TDE" section: document the retroactive promotion at creation case alongside the standard "promote existing open FU" case. Sentinel's 3 cases were born `promoted` retroactively (no pre-existing `open` FU); pattern worked but doesn't explicitly cover.
- Schema canonicalization: add `total_promoted` to the backlog header schema documentation, mirroring existing `total_open` / `total_closed_in_session` / `total_phase_blocked`. Sentinel already added this on their side.
Cost: ~2-3 hours. Pure governance, 3-language i18n sweep.
Risk: ≈ zero. Textual refinements + schema clarification.
Benefit: Closes the public feedback loop on #128. Heuristic captured all 3 Sentinel TDEs correctly even with current wording — these are non-blocking clarifications, but landing them removes the residual ambiguity for adopter N=2+.
Crystallization gate: None. This is the gate's output, not its input. Implement immediately.
Tier 2 — Ship the bash script in the framework (deferred, optional)
Scope: Move `check-followups-drift.sh` from Sentinel's repo into `dist/.straymark/scripts/`, parallel to the existing `check-charter-drift.sh`. The script becomes part of the framework distribution; adopters get it via `straymark init` / `update-framework` instead of copy-pasting from an external repo.
Cost: ~1-2 hours (port the script, regenerate checksums, update FOLLOW-UPS-BACKLOG-PATTERN.md to reference the canonical path, add to `dist-manifest.yml`).
Risk: Low. The script is autonomous POSIX bash, no CLI integration. Still operator-driven; no `straymark` subcommand wraps it.
Benefit: Lowers adoption friction. Adopter N=2 doesn't need to know Sentinel exists.
Crystallization gate: A second adopter expresses interest in the pattern but cites the Sentinel-copy-paste step as friction. Until then, the Sentinel-as-reference-impl model works fine.
Tier 3 — Soft integration with `charter close` (deferred)
Scope: After `straymark charter close`, automatically invoke `check-followups-drift.sh --apply` to extract any new FUs from the just-closed AILOG. Add an interactive prompt: "Detected N FU candidates from this AILOG. Review the four TDE criteria — promote any?" Operator decides; CLI only detects + suggests.
Cost: ~4-6 hours (Rust wrapper paralleling `charter/drift.rs`, prompt UX, telemetry capture, regression tests). Requires Tier 2 first (script must live in the framework).
Risk: Medium. Touches the Charter close workflow — sensitive UX surface; requires care with the "operator declined" path.
Benefit: Closes the loop between Charter close and follow-ups registry without manual operator step. Reduces drift between AILOG `§Follow-ups` blocks and the backlog file.
Crystallization gate: A second adopter actively uses the pattern AND reports the manual `scripts/check-followups-drift.sh` step as friction. Sentinel runs it manually and doesn't complain — there's no signal yet that automation here is needed.
Tier 4 — CLI subcommand trio `straymark followups list/status/promote/drift` (deferred indefinitely)
Scope: First-class CLI surface mirroring `straymark charter list/status/close/drift`. `list` enumerates open/promoted/closed entries with filters; `status` shows registry health; `promote` automates the FU → TDE flow with prompts for the four criteria; `drift` wraps the bash script.
Cost: ~20-30 hours. New module, prompts, schema validation, comprehensive regression tests, i18n for all output strings.
Risk: High — crystallizes a CLI surface based on a single adopter's mental model. The pattern doc already declares this deferred at `FOLLOW-UPS-BACKLOG-PATTERN.md:179` ("Cristalization as `straymark followups` CLI") against the second-adopter validation gate per design principle #12 ("no premature crystallization; schemas marked v0 until validated against a second domain").
Benefit: First-class workflow ergonomics. Would feel natural alongside `straymark charter *`.
Crystallization gate: At least one second adopter actively using the pattern, AND alignment on the subcommand vocabulary across both adopters' mental models. Sentinel alone is not enough — principle #12 was written specifically against this kind of single-data-point design.
Reasoning summary
| Tier |
Decision |
Why |
| 1 |
Do now (fw-4.13.1) |
Sentinel proposed it explicitly; non-blocking, zero risk, closes the empirical-validation loop publicly |
| 2 |
Defer, optional |
No friction signal from Sentinel. Adopter N=2 might prefer a different distribution mechanism (e.g., the `straymark` binary embedding the script). Wait for the signal. |
| 3 |
Defer |
Cost is medium and UX is sensitive. Sentinel runs the script manually post-Charter close without complaint. No friction signal. |
| 4 |
Do not crystallize until N=2 adopters align on vocabulary |
Principle #12 was written for exactly this case. The 20-30 hour investment could lock the project into a subcommand surface that a second adopter would have designed differently. |
The general shape: let empirical signal pull the framework toward automation, don't push from anticipated need. Each tier above the current state requires concrete operator friction, not just imagined ergonomic improvements.
Tier 1 implementation
Will be implemented in a follow-up PR as `fw-4.13.1` patch (governance-docs-only, no CLI changes). The PR will:
- Apply the 4 refinements (EN + ES + zh-CN i18n sweep)
- Bump `dist-manifest.yml` 4.13.0 → 4.13.1
- Update footers (8 governance docs × 3 langs)
- Update versioning tables in README + CLI-REFERENCE (3 langs each)
- Add `## Framework 4.13.1` CHANGELOG entry
🤖 Issue body co-authored with Claude Code.
Context
After #128 (TDE activation trigger), #129 (fw-4.13.0 governance), #130/#131 (validator fix), and the Sentinel empirical validation at #128 comment (3 TDEs filed via StrangeDaysTech/sentinel#61), the question surfaced: what's next for follow-ups automation?
This RFC catalogs the four possible tiers of automation, the cost/benefit/risk of each, and the crystallization gate that should govern when (if at all) we advance from one to the next. It also lands the Tier 1 refinements from Sentinel feedback as the immediately actionable scope.
Current state of FOLLOW-UPS-BACKLOG-PATTERN.md
Verified by reading the framework + CLI source after fw-4.13.0 + cli-3.12.1:
Conclusion: today the pattern is documented convention only. The execution layer is fully adopter-side. The framework provides the schema for the registry file and the workflow prose — nothing more.
The 4 tiers
Tier 1 — Land Sentinel's refinements (fw-4.13.1, governance-only)
Scope: Apply the four refinements proposed in the Sentinel feedback comment:
Cost: ~2-3 hours. Pure governance, 3-language i18n sweep.
Risk: ≈ zero. Textual refinements + schema clarification.
Benefit: Closes the public feedback loop on #128. Heuristic captured all 3 Sentinel TDEs correctly even with current wording — these are non-blocking clarifications, but landing them removes the residual ambiguity for adopter N=2+.
Crystallization gate: None. This is the gate's output, not its input. Implement immediately.
Tier 2 — Ship the bash script in the framework (deferred, optional)
Scope: Move `check-followups-drift.sh` from Sentinel's repo into `dist/.straymark/scripts/`, parallel to the existing `check-charter-drift.sh`. The script becomes part of the framework distribution; adopters get it via `straymark init` / `update-framework` instead of copy-pasting from an external repo.
Cost: ~1-2 hours (port the script, regenerate checksums, update FOLLOW-UPS-BACKLOG-PATTERN.md to reference the canonical path, add to `dist-manifest.yml`).
Risk: Low. The script is autonomous POSIX bash, no CLI integration. Still operator-driven; no `straymark` subcommand wraps it.
Benefit: Lowers adoption friction. Adopter N=2 doesn't need to know Sentinel exists.
Crystallization gate: A second adopter expresses interest in the pattern but cites the Sentinel-copy-paste step as friction. Until then, the Sentinel-as-reference-impl model works fine.
Tier 3 — Soft integration with `charter close` (deferred)
Scope: After `straymark charter close`, automatically invoke `check-followups-drift.sh --apply` to extract any new FUs from the just-closed AILOG. Add an interactive prompt: "Detected N FU candidates from this AILOG. Review the four TDE criteria — promote any?" Operator decides; CLI only detects + suggests.
Cost: ~4-6 hours (Rust wrapper paralleling `charter/drift.rs`, prompt UX, telemetry capture, regression tests). Requires Tier 2 first (script must live in the framework).
Risk: Medium. Touches the Charter close workflow — sensitive UX surface; requires care with the "operator declined" path.
Benefit: Closes the loop between Charter close and follow-ups registry without manual operator step. Reduces drift between AILOG `§Follow-ups` blocks and the backlog file.
Crystallization gate: A second adopter actively uses the pattern AND reports the manual `scripts/check-followups-drift.sh` step as friction. Sentinel runs it manually and doesn't complain — there's no signal yet that automation here is needed.
Tier 4 — CLI subcommand trio `straymark followups list/status/promote/drift` (deferred indefinitely)
Scope: First-class CLI surface mirroring `straymark charter list/status/close/drift`. `list` enumerates open/promoted/closed entries with filters; `status` shows registry health; `promote` automates the FU → TDE flow with prompts for the four criteria; `drift` wraps the bash script.
Cost: ~20-30 hours. New module, prompts, schema validation, comprehensive regression tests, i18n for all output strings.
Risk: High — crystallizes a CLI surface based on a single adopter's mental model. The pattern doc already declares this deferred at `FOLLOW-UPS-BACKLOG-PATTERN.md:179` ("Cristalization as `straymark followups` CLI") against the second-adopter validation gate per design principle #12 ("no premature crystallization; schemas marked v0 until validated against a second domain").
Benefit: First-class workflow ergonomics. Would feel natural alongside `straymark charter *`.
Crystallization gate: At least one second adopter actively using the pattern, AND alignment on the subcommand vocabulary across both adopters' mental models. Sentinel alone is not enough — principle #12 was written specifically against this kind of single-data-point design.
Reasoning summary
The general shape: let empirical signal pull the framework toward automation, don't push from anticipated need. Each tier above the current state requires concrete operator friction, not just imagined ergonomic improvements.
Tier 1 implementation
Will be implemented in a follow-up PR as `fw-4.13.1` patch (governance-docs-only, no CLI changes). The PR will:
🤖 Issue body co-authored with Claude Code.