Skip to content

RFC/tracking: cross-Charter knowledge layer (Cubeta B from #150 + #146 Proposal D) — post-announcement Charter #153

@montfort

Description

@montfort

Summary

Tracking issue for the cross-Charter knowledge layer — a set of mechanics that live above the Charter as a unit, surfaced empirically by two independent adopter cycles in Sentinel. Both data points landed within ~10 days of each other and point at the same conceptual gap.

This issue is scope-defining, not implementation-bound. It collects context across the announcement cycle so the post-announcement Charter can be designed cohesively rather than as two disjoint fixes.

Data points motivating this layer

#146 Proposal D — Cross-Charter lessons-learned index

Sentinel CHARTER-17 (CommsHub US4) closed with knowledge generated during execution that was reusable across Charters but documented only inside the originating AILOG. Examples from that cycle:

  • Multi-language template regex case-sensitivity ([A-Za-z_] vs [A-Z]) — relevant to any future Charter shipping template-variable validation in a non-English-identifier language.
  • processed_events core table reuse vs new dedup tables — relevant to any future Charter adding an event consumer handler.

These accumulated knowledge points are buried in per-Charter AILOGs. Finding "has anyone hit this case before?" today requires scanning every AILOG. Proposal D suggested .straymark/lessons-learned.md as a cross-Charter index with stable IDs (LL-YYYY-MM-DD-NNN), tags, and a CLI promotion helper.

Deferred from #146 with the explicit commitment to revisit post-announcement.

#150 Ask 3 — straymark spec-drift CLI

Sentinel ran a single specs/002-commshub/plan.md (committed 2026-04-21) through seven consecutive Charters (CHARTER-07..17, ~1 month). 12 unreflected learnings accumulated in the gap between the planning artifacts and the actually-shipped code. The fw-4.14.3 release ships the manual discipline (when to refresh + three gates + warnings — closes Asks 1, 2, 4 of #150).

Ask 3 was deferred: a CLI command analogous to straymark charter drift but operating at spec granularity — parsing data-model.md entities and diffing against schema sources, parsing contracts/*.md endpoints and diffing against handler signatures. It would mechanize Gate (a) of the spec-refresh discipline.

Why they belong in the same Charter

Both #146 D and #150 Ask 3 share three structural characteristics:

  1. They live above the Charter as a unit. Charter drift (straymark charter drift) and Batch Ledger gates operate inside one Charter. These two operate across Charters.
  2. They are knowledge-management primitives. Lessons-learned is reusable insight; spec-drift is canonical artifact reconciliation. Both are about what survives between Charters.
  3. They have non-trivial design surface. Lessons-learned needs schema decisions (frontmatter shape, ID format, tag taxonomy, discovery integration with straymark explore). spec-drift needs a language-detection layer (Go vs Rust vs TypeScript vs Python handler signatures; SQL vs ORM-defined schemas) and a question about whether to ship v0 single-language or require tree-sitter-level abstraction.

Designing them in isolation risks calcifying choices that the other will contradict. Designing them together in a dedicated Charter post-announcement lets the schemas, CLI surface, and discovery patterns be consistent.

Speculative scope (subject to design)

The Charter, when filed, will likely cover at least:

  • .straymark/lessons-learned.md schema — frontmatter (LL-YYYY-MM-DD-NNN, tags, origin AILOG reference, reusable-in scopes), body format, file-vs-multi-file decision.
  • straymark lessons subcommand familylessons promote --from AILOG-X --section Risk|Batch, lessons list, lessons status, possibly lessons find --tag <tag> for discovery.
  • straymark spec-drift subcommand — v0 language-detection scope decision (single-language seed vs abstracted from the start); contract surface for the parser interfaces; integration with charter drift's existing patterns.
  • Discovery integration — does straymark explore get a new view? Do lessons surface during charter new to prime risk anticipation?
  • Distinction from TDE — TDE is actionable debt that needs scheduling; lessons-learned is resolved-and-reusable knowledge that prevents future repetition. The Charter must keep the two artifacts distinct in the operator's mental model.
  • Possible umbrella straymark spec command — if spec-drift, spec-refresh, spec-status cluster naturally, a parent command may emerge.

What's explicitly out of scope for this tracking issue

  • No implementation. This issue is a context preservation vehicle, not an RFC for approval.
  • No design freeze. The scope above is speculative; the actual Charter will design cohesively against the state of the world at the time of filing (which may include additional adopter signals).
  • No commitment to timeline. Tied to the announcement cycle and to whether a second adopter exercises one of these mechanics with real data — that's the natural trigger per Principle feat: add devtrail repair command to restore broken structure #12 (validation against a second domain before crystallization).

Sentinel reconciliation in the meantime

Cross-references

Filed from PR #152 (fw-4.14.3) merge — preserves the Cubeta A/B split context across the announcement cycle.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions