feat(framework): fw-4.14.3 — spec-refresh discipline for multi-Charter execution (#150 Cubeta A)

[montfort]

Summary

Closes Cubeta A of #150. Surfaced by Sentinel after running a single specs/002-commshub/plan.md through seven consecutive Charters (CHARTER-07..17, ~1 month). The bridge doc covered Charter declaration but said nothing about spec maintenance during multi-Charter execution.

The empirical case: 12 unreflected learnings (infrastructure patterns refined during execution, code gaps the plan didn't anticipate, Charter/audit patterns crystallized over the cycle) accumulated to the point that the next Charter (CHARTER-18, US5) carries ~50% probability of inheriting a critical/high audit finding from stale-premise inheritance. But naively re-running /speckit-plan is worse — regeneration asserts things about already-shipped user stories that the actual code does not implement.

This PR ships the canonical discipline as governance documentation. Cubeta B (the straymark spec-drift CLI that mechanizes Gate (a), plus the cross-Charter lessons-learned index from #146 Proposal D) is deferred to a dedicated post-announcement Charter — tracking issue to be filed in the next commit on main.

What's in scope

dist/.straymark/00-governance/SPECKIT-CHARTER-BRIDGE.md (EN + i18n/es + i18n/zh-CN)

New section "Spec maintenance during multi-Charter execution" with:

• Empirical anchor: cites RFC/discussion: spec-refresh discipline in SPECKIT-CHARTER-BRIDGE — empirical staleness across multi-Charter execution #150 + Sentinel CHARTER-07..17 cycle as the discovery source.
• When to refresh — four heuristics: ≥3 closed Charters / ≥4 weeks + ≥2 Charters / R<N>(new) count >6 / target US touches refined infra. Explicit guidance to skip when none hold.
• How to refresh: scope-limited prompt — name target phase, list locked sections, cite refinement AILOGs, forbid tasks.md regeneration.
• Three mechanical gates — (a) Validation against code reality (diff non-target entities/endpoints vs migrations/handler signatures); (b) Granular hunk-by-hunk review; (c) Two-PR split (refresh PR separate from Charter-fill PR).
• Why NOT re-run /speckit-tasks — regenerating destroys [X] completion marks and *CHARTER-NN:* <sha>* annotations. Manual edit for the target phase only.
• Constitution Check re-evaluation cadence — per-Charter (recommended) + per-spec-refresh (mandatory) + NOT per-framework-bump alone. Closes the implicit-cadence ambiguity.
• Roadmap: straymark spec-drift — explicitly names the deferred CLI so adopters know the mechanization is coming.

Plus a new anti-pattern entry pointing at the safe path.

docs/contributors/WHAT-IS-A-CHARTER.md

§4 Mode A: cross-link inserted right after the SpecKit-driven flow diagram, surfacing "what happens when a single spec drives many Charters?" with a pointer to the new bridge-doc section. Contributors landing on the conceptual doc find the operational discipline at the natural decision point.

Versioning

• dist/dist-manifest.yml → 4.14.3.
• Governance footers (QUICK-REFERENCE.md, AGENT-RULES.md, DOCUMENTATION-POLICY.md, C4-DIAGRAM-GUIDE.md, FOLLOW-UPS-BACKLOG-PATTERN.md, SPECKIT-CHARTER-BRIDGE.md) bumped to v4.14.3 across EN + ES + zh-CN.
• Version tables in README.md + i18n + CLI-REFERENCE.md + i18n updated.
• CHANGELOG.md entry explaining the Cubeta A/B split and the rationale.

What's NOT in scope

• No CLI changes. cli-3.13.1 remains the matching CLI version. No cli/ files touched, no Cargo.toml bump.
• No straymark spec-drift implementation. Cubeta B; deferred to post-announcement Charter.
• No new schema or template. The discipline lives in governance docs, not in code.
• No template-level changes to charter-template.md. The pattern applies across Charters; the per-Charter template is unchanged.

Why a patch release (not just a docs PR)

SPECKIT-CHARTER-BRIDGE.md is shipped to every adopter via straymark init. Without bumping the framework, straymark update-framework would not bring the new section to existing installations. Sentinel reads the section before filling CHARTER-18 — time-sensitive.

Test plan

• cat dist/dist-manifest.yml shows version: \"4.14.3\"
• grep \"Spec maintenance during multi-Charter\" dist/.straymark/00-governance/SPECKIT-CHARTER-BRIDGE.md finds the new section
• Same grep against i18n/es/ and i18n/zh-CN/ overlays — paridad
• grep \"v4.14.3\" dist/.straymark/00-governance/QUICK-REFERENCE.md shows the new footer
• grep \"fw-4.14.2[^+]\" returns 0 results across docs (no stale footers)
• CI release-framework workflow packages straymark-fw-4.14.3.zip cleanly (post-tag)
• Sentinel applies the discipline on CHARTER-18 fill; reports outcome (post-merge, async)

Follow-up — Cubeta B tracking

A separate tracking issue will be filed on main post-merge consolidating:

• RFC/discussion: spec-refresh discipline in SPECKIT-CHARTER-BRIDGE — empirical staleness across multi-Charter execution #150 Ask 3 (the straymark spec-drift CLI command)
• Multi-batch Charter AILOG ledger: structural gap between declare and close — propose batch-complete CLI + drift gate (C) and cross-Charter lessons-learned index (D) #146 Proposal D (cross-Charter lessons-learned.md index)

Both are mechanics living above the Charter as a unit — the missing "cross-Charter knowledge layer". A post-announcement Charter will design them cohesively. Linking that issue here once filed.

🤖 Generated with Claude Code