"The first thing the polish Charter tried — booting ./sentinel from main to run the §5 smoke — failed with two distinct panics."

That sentence opened Issue #199 on May 22, filed by the Sentinel adopter as an RFC. By the time the thread closed five comment-updates later, the count had grown from two to ten. The polish Charter — the closing Charter of Etapa 2, planned as a docket of WCAG audits and quickstart verification — had spent six hours doing something else: catching a class of latent regression that none of the per-Charter test suites of the eight previous Charters had caught, and that none of them could have caught given how they were written.

This post is the reconstruction of why that happened, what the recurring shape underneath it turned out to be, and the deliberate decision in PR #200 to name the anti-pattern but not yet tool for it. The cycle is familiar to readers who followed the previous posts on emergent observation and chain evolution — this is the third pattern in two weeks to crystallize via the same arc: surface in N=1, name the meta, defer the cross-project tooling until N=2 validates.

The two cases that mattered​

Of the ten gaps the polish session surfaced, eight were either dependency rot (a huma upgrade introduced a panic on *string parameters; Go 1.22 tightened http.ServeMux wildcard semantics) or runbook drift (env vars missing from §boot, smoke recipes that mixed mutually-exclusive modes, claims about a fake provider's stdout that the fake never wrote to). Each one merits a fix. None of them rewrites the playbook.

The two that did rewrite the playbook are different. They share a shape.

US3 Preference Center, shipped May 12. When recipients of a Sentinel-sent email click the unsubscribe-style footer link, they land on a JWT-in-path URL like /preferences/<token>. The handler is intentionally public-by-contract: the JWT is the auth; no Authorization header is expected. The handler's doc-comment said so. The integration test, written in humatest, mounted the handler directly through the testing adapter and confirmed: given a valid JWT in the path, the handler returns the right HTML. CI passed. The feature shipped to main.

What never happened: anything that exercised the production middleware chain in front of that handler. internal/core/middleware/auth.go has a publicPrefixes list of route prefixes that bypass the Authorization check. /preferences/ was not in it. For ten days, every recipient who clicked an unsubscribe link got a 401 missing authorization header from the middleware before the request ever reached the handler that knew not to expect one. The Preference Center was reachable in tests, unreachable in production.

OTel observability instruments for the send pipeline, shipped the same week. Eight metric instruments — counters, histograms, gauges — declared in internal/core/metrics/commshub.go, registered with the OpenTelemetry meter at boot. The Charter's Constitution Check §IV formally declared the FR-039..042 observability gate satisfied: the API layer was correct, the registrations went through, dashboards were planned. Seven of those eight instruments had zero .Add() / .Record() call sites in the entire commshub module. Declared, registered, never invoked. The dashboards that ops built on top of those series had been receiving zero data for ten days. The polish Charter's manual smoke — boot an OTel Collector, generate a few sends, grep collector output for the FR-039..042 names — surfaced this instantly.

Neither case is exotic. Neither case is a hard bug. They are both instances of the same mechanical mistake: an artifact got declared in one place, and the implementation that was supposed to wire it lived in another place, and nothing in the codebase or in CI correlated the two.

The name the anti-pattern wanted​

A name matters when the same shape shows up enough times to deserve one. By the third comment update on #199, the Sentinel author had counted four sub-classes of the same underlying mistake:

The unifier — the one-liner that the new governance doc opens with — is:

Every declared surface artifact has at least one wiring site reachable from a real request.

The anti-pattern's name, which lands canonically in dist/.straymark/00-governance/POLISH-CHARTER-PATTERN.md, is Surface declaration without wiring. That is the deliverable. The polish Charter is the discovery vehicle, not the thesis.

Why integration tests systematically miss this​

This part is worth dwelling on because it shapes the rest of the post. The common failure mode across all four sub-classes is that the standard integration-test harness — humatest.NewTestAdapter in Go, the equivalent in TypeScript, Python, Rust — mounts handlers directly via the testing API. The handler under test is wired correctly by the fixture. The production composition step — where the route registration meets the middleware chain meets the env-var inventory meets the embedded asset table — is what's broken. CI's green light is genuine for what it claims: the handler returns the right response given the right request. It says nothing about whether the request can reach the handler in production, or whether the artifact the handler depends on was ever wired to the runtime.

There's a temptation to read this as a critique of humatest. It isn't. humatest (and its equivalents) is doing exactly what it was designed to do: let you test handler logic in isolation, fast, without standing up the whole composition tree. That isolation is a feature. The cost of the isolation is what we just named — and the cost only becomes visible when something outside the isolation surfaces a divergence. The polish Charter is the cheapest method to surface that divergence, because it does what no test fixture does: it boots the actual binary and runs the actual documented operator recipe against it.

This is the load-bearing claim of the new pattern doc. Not that polish Charters are valuable for cosmetic reasons. That they are the only place where the production composition gets exercised end-to-end against an externally-readable specification (the operator runbook). If you treat the polish Charter as cosmetic cleanup, you also treat that surfacing capacity as cosmetic. Sentinel's data argues the opposite.

The decision: B′, not B​

The RFC proposed three options. The decision in PR #200 was none of them as stated — call it B′. Worth saying why, because the structural choice matters more than it looks.

The RFC's Option B asked for a pattern doc under docs/patterns/. That directory does not exist in StrayMark today, and creating it would have split the project's documentation convention. The empirical patterns that already live in the canon — FOLLOW-UPS-BACKLOG-PATTERN.md, CHARTER-CHAIN-EVOLUTION.md, EMERGENT-OBSERVATION-DESIGN.md, SPECKIT-CHARTER-BRIDGE.md — all live in dist/.straymark/00-governance/. They share an i18n mirror infrastructure (every governance doc has English, Spanish, and Simplified Chinese siblings). Adding a third documentation surface would have multiplied the i18n overhead and pulled the project's patterns across two homes. Keeping the new doc inside 00-governance/ reused the existing infrastructure with zero marginal cost.

The RFC's Option C asked for a straymark charter polish-checklist or straymark analyze declared-vs-wired CLI helper. The Sentinel author had already prototyped one (CHARTERs 25/26/27, the three preparatory CI guards) and offered to seed it upstream. The decision here was conservative: defer. Not because the prototype isn't valuable — it is — but because Sentinel is N=1. The four sub-classes were the ones one adopter, one stack surfaced. The fifth, sixth, and seventh sub-classes that the framework would have to anticipate to ship a useful cross-project CLI don't exist yet, because no second adopter has pushed them. We've been down this road before. FOLLOW-UPS-BACKLOG-PATTERN.md shipped as v0 in fw-4.10.0 and has lived there for a month and a half, waiting for a second adopter to validate before graduating to a straymark followups subcommand. The same gate applies here. The new doc's ## Open questions says so explicitly: "Crystallization as straymark analyze declared-vs-wired CLI subcommand … Gate: N=2 adopters."

B′ is what landed. A new governance pattern doc in the canonical location, in three languages. A seventh Format conventions bullet in the Charter template pointing authors at it when closing an Etapa or SpecKit Polish Phase. A row in the QUICK-REFERENCE ## Patterns table. A fw-4.18.0 bump with the footer cascade across thirty-some docs. No CLI subcommand. No new frontmatter field. No schema change. The anti-pattern has a name; the discovery ritual has a doc; the tooling waits.

The arc that keeps repeating​

Three weeks ago, the follow-ups backlog pattern crystallized via the same arc: an adopter surfaced a need, the pattern got named at v0, the CLI helper was deferred. Two weeks ago, the chain-evolution patterns crystallized: Pattern 1 (pre-declare SpecKit refresh) and Pattern 2 (post-close audit-driven Batch N.4), surfaced from the same Sentinel adopter, named in fw-4.16.0, with straymark charter refresh-suggest as a soft helper rather than a hard gate. One week ago, the meta — EMERGENT-OBSERVATION-DESIGN.md — codified what made any of those observations possible in the first place: formal cross-referencing plus cultural permission. This week, this pattern.

That's four crystallizations in a month, all from the same adopter, all following the same shape: surface in N=1 → name the meta → tool only after N=2. The temptation when a pattern surfaces vividly — and ten production gaps in six hours is vivid — is to skip the name and go straight to the tool. The discipline is the opposite. The name does most of the work. The tool, when it comes, is parameterized by what at least two adopters have surfaced; built on N=1, it's an extrapolation from one stack and one team's failure modes, and it tends to ossify those choices into framework defaults that don't generalize.

There is one piece of this iteration that is genuinely new and worth flagging. The new pattern doc names a falsifiable prediction the Sentinel author already committed to publishing: the next Etapa's polish Charter, executed against the three preparatory CI guards that just landed in Sentinel CHARTERs 25/26/27, should surface roughly 80% fewer gaps. If that prediction holds, the case for graduating Option C from "open question" to "CLI subcommand" gets quantitative backing. If it fails — if the next polish Charter still surfaces ten gaps but in a fifth, unanticipated sub-class — the failure itself is the next data point, and reshapes the spec before tooling is built. Either result is useful. Neither result has been observed yet. We wait.

A note on what was deliberately not done​

There is no phase: polish field in the Charter frontmatter. There is no straymark charter polish-checklist <ID>. There is no automated analyzer scanning Go (or any other language) code for declared-but-unwired symbols. The pattern doc lists each of those as a candidate evolution, gated explicitly on N=2 or on the post-Etapa-3 retrospective. None of them are present in fw-4.18.0.

This is intentional and worth saying out loud, because the natural reaction to a vivid finding is to over-build the response. Each one of those deferrals trades short-term thoroughness for long-term portability. A frontmatter field commits the framework to a vocabulary the next adopter may not share. A CLI helper commits the framework to a runtime that mirrors one specific stack's failure modes. An analyzer commits the framework to scanning a language whose conventions may diverge from the next adopter's. None of those commitments should be made on a single domain's signal, however clean the signal is. The pattern doc itself can be revised; a CLI subcommand cannot be unshipped without breaking adopters.

What I'd suggest you look at, if you've read this far​

If you operate a codebase with mock-adapter integration tests — which is most codebases — you can run a useful internal exercise without adopting anything from StrayMark at all. Pick the most recent feature your team shipped that has both (a) a docs-side declaration (env vars, OpenAPI specs, embedded HTML, metric instruments) and (b) a wiring site that lives in a different file. Boot the binary from a clean shell. Run the operator-facing recipe from the runbook end-to-end. If it works on the first try, your codebase doesn't yet have the latent debt this pattern catches — or it does and you got lucky on this one. If it doesn't, count the gaps. The number is the calibration you need for whether the polish-Charter-as-debt-detection ritual would be worth its overhead in your project.

If you've adopted StrayMark and you're closing an Etapa with handlers tested through humatest-style adapters, the new pattern doc has the four sub-class checks scoped for you. Budget the polish Charter as L, not XS or S. Expect emergent follow-on Charters, not residual cleanup scope creep. Read POLISH-CHARTER-PATTERN.md before scoping the work, not after.

And if you're an adopter on a stack other than Go — TypeScript, Python, Rust, Elixir — the four sub-classes are language-agnostic, but the concrete check shape is not. Surfacing a fifth or sixth sub-class in your stack is exactly the second-adopter signal the pattern needs to graduate from v0. The path from "interesting observation in your project" to "named in the StrayMark canon" runs through the same channel #199 went through: open an issue. The cost of opening it is low; the cost of leaving the pattern under-validated is real.

StrayMark fw-4.18.0 — Issue #199 · PR #200 · tag fw-4.18.0. Sentinel anchors: AIDEC-2026-05-22-001 · CHARTERs 25/26/27 PR.

This document was produced with assistance from generative AI tools (Claude 4.7); all responsibility for the content rests with the human author.

"Hi, did we already deal with Issue #153?"

That's how the conversation started, today, May 16th, in the morning. A short, almost-housekeeping question, before getting into something else. The answer was no — Issue #153 was open on purpose, waiting for a second domain to exercise the mechanic before crystallizing it (StrayMark's Principle #12: validation against a second domain before canonization). But the question opened another door, and by the end of that conversation I had codified a design property of the framework that had been doing its job in silence for months, surfaced by an episode from just two days ago.

This post is the reconstruction of that arc, because it's worth keeping. Not for the outcome — a new canonical doc, a Principle #8, a PR already merged — but for the mechanism it revealed. StrayMark has a human project behind it: making sure that agent-assisted development doesn't slip through the fingers of the engineers who are responsible for the software being produced. And this episode exposed a concrete design property pushing in that direction.

A note on craft: StrayMark gets tested first on my own projects. Sentinel is one of them — private, but its interaction with StrayMark is documented in the public Issues of the StrayMark repo, so the context is linkable. I'm the author and first adopter of the framework. Principle #12 obliges me to wait for a second domain before declaring any new mechanic canonical; but the first domain is me, and this post acknowledges that without disguise.

The incident: an agent that flagged what nobody asked it to flag​

On May 14, two days ago, in Sentinel, an agent brought to my attention an observation I hadn't requested. It was about to help me fill out CHARTER-18 — a concrete piece of work inside an already-long chain — and before writing a single line of code it said, in essence:

(translated from the original in Spanish) There's a problem. The specs/002-commshub/plan.md was frozen on April 21. Since then seven consecutive Charters have passed, and across the AILOGs of that chain there are twelve empirical learnings unreflected in the plan that materially affect the scope of US5. If we fill out CHARTER-18 reading the stale plan, the next audit cycle is going to remediate divergences atomically pre-close — with approximately 50% probability of at least one critical or high finding from stale-premise inheritance.

And it cited the specific AILOGs by ID. And the concrete code references.

Nobody asked for that analysis. There was no trigger configured. There was no CLI command whose purpose was to produce that output. The agent was there to help me with the next task, not to audit the project's state. But while positioning itself for that next task, it saw a divergence between two sources that StrayMark's documentation explicitly connects, and it chose to flag it before proceeding.

I filed Issue #150 that same afternoon as an RFC, and between 5pm and the night the manual spec-refresh discipline got discussed and landed in fw-4.14.3. The next day, May 15, I raised Issue #156 to upstream the two patterns the exercise had revealed: a pre-declare SpecKit refresh and a post-close Batch N.4 amendment. By the early hours of May 16 they were canonized in fw-4.16.0 as CHARTER-CHAIN-EVOLUTION.md, with dedicated telemetry and a CLI helper (straymark charter refresh-suggest). The behavior reproduced, the patterns crystallized, cycle closed.

But when I sat down that same morning of the 16th to open the conversation with Issue #153 — "did we deal with this?" — and then bounced back the inverse question — "hold on, what made that observation possible in the first place?" — I realized the cycle had only half closed. What got codified in fw-4.16.0 was the application of the pattern. What remained to be codified was the mechanism that produced it.

The human question, said with technical words​

I phrased it like this, in the conversation with the agent that generated this post:

(translated from the original in Spanish) I was somewhat surprised by the agent's behavior — that it noticed the accumulated knowledge that, if not applied, would cause problems with the implementation of Charter 18. That is, it wasn't a task I asked it to analyze, nor was it the result of a prompt trigger being activated, and it seems to me that it was thanks to the StrayMark documentation. I'd like to dig deeper into how this happened, which I think is positive, so that we can take advantage of the experience and hook it into StrayMark's habitual behavior — this emergent pattern that came from the agent and its relationship to the generated documentation was very interesting.

What I'm asking there isn't to implement a feature. It's to understand a mechanism in order to reproduce it. The difference matters. When you ask to implement something, the path is clear: spec → tasks → code. When you ask to understand why something worked, the path is rarer: you have to diagnose a working system, identify which pieces made it work, and separate the accidental from the structural.

There's a particular urgency to this kind of question when you're building tools to collaborate with AI agents. Because if what worked was an accident, the next agent — or the next version of the same agent — may not reproduce it. If what worked was structure, then it can be preserved deliberately. The difference between those two things, for a project that intends to give engineers control over AI-assisted development, is the difference between luck and design.

The audit: which pieces of StrayMark made the observation possible?​

I asked an agent to systematically map StrayMark's documentation with three concrete questions:

1. Which documentary mechanisms connect sources explicitly to each other? (Frontmatter, canonical sections, stable IDs, CLI commands that cross sources.)
2. Where does the documentation give the agent explicit permission to flag things beyond the task asked?
3. What pairs of sources exist, beyond the one that originated this case, that could produce similar emergent observations if the infrastructure is present?

The report came back structured, with file:line for each finding. What mattered wasn't the individual details (frontmatter with originating_charter:, sections §Risk: R<N>, conventions of stable IDs, commands like charter drift) but the pattern that emerged when seeing them together. Two properties consistently coexisted:

Property 1: mandatory structural cross-referencing. Each document type has required fields and canonical sections that declare, in the document's own structure, which other documents it points to. When an agent reads an AILOG, it doesn't have to guess which Charter it belongs to — the originating_charter: tells it. When it sees a risk, it isn't an observation in free prose — it's an R<N> entry in a canonical, countable section. When the spec points to Charters, it does so formally; when Charters point to AILOGs, the same. It's an explicit linkage graph the agent can triangulate without creative work.

Property 2: cultural permission without blocking gatekeeping. AGENT-RULES §6 tells the agent: "Be Proactive — Identify potential risks, Suggest improvements when evident, Alert about technical debt". PRINCIPLES §2 tells it: "Not hide relevant information". And critically, AGENT-RULES §3 gives it autonomy to create documents (AILOG, AIDEC, TDE) without operator pre-approval. The operator retains prioritization, not creation. The agent doesn't have to ask permission to flag something: flagging it is rule execution, not a value judgment.

What's interesting is that neither property alone produces the behavior. If you only had formal linkage (Property 1) without cultural permission, you'd have a queryable corpus no agent dares to query proactively. If you only had cultural permission (Property 2) without structure, you'd have vague flags — "I think something might be wrong somewhere" — that operators can't act on.

Combined, they produce something that deserves its own name: the agent externalized "should I say something?" as "is there a canonical section where this fits?". If the answer is yes, flagging stops being an emotional decision and becomes mechanical execution. The cost of flagging drops because the destination — the canonical section — already exists.

Why this matters beyond StrayMark​

We're in a moment where AI agents can write code as fast as we think, and the question of how not to lose control of the process is genuinely urgent. It's not an apocalyptic question — it's an operational, craft-level question, asked by people who are building software right now and have to ship. The very pace of this episode is evidence: from the agent's diagnosis to the canonized meta-pattern less than 72 hours passed. That speed is a gain, but it's also why visibility mechanisms matter so much.

The dominant response in the industry today is some variant of stricter prompts, more rules in context, more gates in CI. Those approaches are valid but have one characteristic worth naming: they turn the agent into something closer to a worker executing orders in verifiable pipelines. That solves reliability but at the cost of emergent observation. An agent that only does what it's ordered to do isn't going to flag something nobody asked it to flag, no matter how good its reasoning.

What the Sentinel episode showed is a different, complementary response: build the documentary apparatus such that important divergences are structurally visible, and give the agent cultural permission to flag them without asking approval. That preserves emergent observation as a property of the system, not as luck depending on how good the agent is or how long the prompt is.

There's something almost Taoist about this stance: we don't tell the agent what to look for; we build an environment where what needs to be seen is visible. The pair "visible structure + permission to name" does the work. The agent becomes, paraphrasing some colleagues, an honest broker between living documentation and the state of the code.

And this is what the human project behind StrayMark pursues, even if it's rarely said in those words: that the dizzying change of AI-assisted development doesn't throw us into a world where engineers lose visibility over what's being built. Visibility isn't preserved with more bureaucratic controls; it's preserved by designing the environment the agent works in so that what matters is naturally visible. The engineer doesn't become a reviewer of endless Pull Requests — they become a prioritizer of observations the agent brings structured and named.

What we did about it​

With the diagnosis clear, the question was how to hook it into StrayMark's habitual behavior without killing the emergent quality. This tension is real: every time you turn a spontaneous behavior into an obligation, you turn it into something else. A hard rule can be robust, but it can also generate agent resistance or false signal when triggered out of context.

The decision was conservative: name the meta-pattern, don't mandate its use.

Concretely, in PR #160 released as fw-4.17.0:

• A new canonical doc — EMERGENT-OBSERVATION-DESIGN.md — articulates the design property with its two components, presents the Sentinel empirical case as anchor, and builds a pyramid of instances: the meta-pattern at the top, and underneath all the applications already canonized (Pattern 1 and Pattern 2 of chain evolution; charter drift; follow-ups backlog drift; TDE-vs-R<N> escalation; external audit checkpoint). What previously seemed like ad hoc patterns reveal themselves as applications of the same underlying principle. This visualization alone is worth it: when you see seven things that seemed different and suddenly recognize they share a shape, the framework gains internal coherence without having added anything.

• A new Principle #8 — Cross-Source Dissonance Surfacing — in PRINCIPLES.md. It's the cultural rule condensed in five lines. The agent reads it when onboarding into the project and applies it recursively.

• An expansion of AGENT-RULES.md §6 "Be Proactive" with concrete examples of divergence to watch for: stale spec, accumulated R<N> not escalated to TDE, ADR contradicted by implementation, follow-ups crossing the backlog-pattern threshold, audit findings emerging post-close. They're not obligations; they're examples of what a proactive agent would notice. The difference matters for preserving the emergent quality.

• Four open axes identified as gaps — places where the cross-referencing infrastructure exists partially but the pattern isn't named: MCARD ↔ deployed model code, SBOM ↔ lockfiles, ADR vigente ↔ contradicting implementation, Constitution Check ↔ framework version bump. Each one needs N=1 empirical validation before crystallizing — Principle #12 applies. They got recorded in Issue #161 as a tracking RFC, waiting for a second domain to push one of them.

• Explicit anti-patterns: how the meta breaks. If a new document type ships with optional frontmatter linkage, cross-referencing develops blind spots. If a canonical section is replaced by free prose, queryability evaporates. If blocking gatekeeping is introduced into AILOG/AIDEC/TDE creation, the cultural permission breaks. If telemetry evolves without preserving signals like r_n_plus_one_emergent_count, the feedback loop breaks. These anti-patterns are cheap but effective protection against accidental erosion: any future change proposal can be checked against the list to detect whether it's regressing the meta-pattern.

All of this, from diagnosis to merge and the published fw-4.17.0 release, took place between 9am and 4am the same day. Fifteen hours. Which is exactly the kind of pace the blog admits: you have to learn to operate under this clock, or control slips away.

What I learned from the process​

Three things I didn't expect to learn when I started by answering "no, Issue #153 is still open":

First, that codifying a meta-pattern is different from codifying a pattern. The meta-pattern doesn't add obligations; it adds vocabulary and visibility of the underlying property. That property was already doing its job; what was missing was giving it a name to protect it under future framework evolution. Whoever reads EMERGENT-OBSERVATION-DESIGN.md doesn't learn to do something new — they learn to recognize something that was already there. That's what allows preserving it deliberately.

Second, that the emergent property disappears if over-regulated. There was a moment in the conversation where I chose not to turn Pattern 1 into a hard obligation ("the agent MUST run refresh-suggest before declaring Charter-(N+1)") and instead keep it as recommendation plus the naming of the meta. That decision is counterintuitive if you come from the world of "more controls = more reliability", but it's the right call for this kind of property. Agent proactivity is fragile: the moment it becomes a mandate, it stops being proactivity. What scales is the cultural engine ("Be Proactive") plus the structural linkage, not the list of specific obligations.

Third, that the documentary apparatus we build for agents is also educating us humans. When I saw the seven patterns scattered across various governance docs and recognized them as instances of the same meta, I understood something about StrayMark I hadn't understood before — and StrayMark is me building it over months. The framework is revealing things to its own author. That property — that structured documentation produces insights about itself when audited — is a domestic variant of what the agent does when it flags a divergence. It's the same mechanism, applied at a different scale.

The human project behind it​

I mean it when I say StrayMark has a human project. I'm not building a documentation governance framework because frontmatter fields obsess me. I'm building it because I have the suspicion — increasingly less speculative — that the next five years of software engineering are going to be a constant negotiation between the speed agents offer and the visibility engineers need to keep being responsible for the product. If that negotiation tilts to the agents' side, we end up in a world where code gets written and nobody knows why. If it tilts to bureaucratic control, we end up without the productivity gains that justified the experiment.

The balance isn't theoretical. It's built with concrete decisions: where to put a frontmatter field, which section should be canonical versus free, when to give the agent autonomy and when to retain prioritization. Each of those decisions tilts the balance one way or the other. And the only way to know if the balance is right is to test it — and to name what works when it works, so it survives the next change in the framework.

The CHARTER-18 episode, two days ago, was a test. It worked. What I wrote today was giving it a name. The next test already has candidates: MCARD, SBOM, ADR vigente vs implementation, Constitution Check ↔ framework bump. Four axes where the meta-pattern could reproduce if we close the infrastructure gaps. I'll wait for a second domain to push one empirically before codifying it. Principle #12 — validation against a second domain before crystallizing — remains the guardrail.

If you're reading this and you work with agents to develop software, I invite you to look at your own documentary apparatus with these two questions: which sources are formally connected, with explicit linkage an agent can triangulate without creative work? and how cheap is it for the agent to flag something not asked when it detects a divergence? If the answer to the first question is "few" and to the second is "expensive", you're probably leaving emergent observations on the table. Which isn't the end of the world — but it's exactly what separates an AI-assisted development process under human control from one that slips away.

StrayMark fw-4.17.0 — Issue #150 · #156 · #161 · PR #160 · tag fw-4.17.0

This document was produced with assistance from generative AI tools (Claude 4.7); all responsibility for the content rests with the human author.

1. Twenty-seven hours to name them​

PR #152, which closed the Post 9 episode, merged on 14 May at 21:39 UTC. It brought fw-4.14.3 and the three canonized gates of the manual refresh.

PR #157 — the one this post comes to tell — merged on 16 May at 00:31 UTC. Twenty-seven hours later. It brought fw-4.16.0 / cli-3.14.0 and, with that, two named meta-patterns:

• Pattern 1 — pre-declare SpecKit refresh. Refresh the spec before declaring the next Charter in a chain.
• Pattern 2 — post-close audit-driven Batch N.4. Amend an already-closed Charter when external audit surfaces findings post-close, without opening a new Charter.

Post 9 covered the manually applied discipline on CHARTER-18. This post covers what came after: the two named patterns, the canonical document that names them (CHARTER-CHAIN-EVOLUTION.md), the telemetry schema that measures them, the two CLI helpers that scaffold them — and, as the closing of the entire editorial arc, one hour and seventeen minutes later, a philosophical meta-pattern that reabsorbs both upward.

It's the last post of the arc. The blog Post 1 opened from ahead closes here from behind.

2. Pattern 1 — Pre-declare refresh​

The literal definition, copied from the canonical document:

"A dedicated refresh PR lands between Charter-N close and Charter-(N+1) declare. It touches only the non-locked sections of the SpecKit artifacts (plan.md, data-model.md, contracts, quickstart.md, research.md)."

This is exactly what Sentinel did manually for CHARTER-18 in Post 9. The difference between Post 9 and Post 10 is one of kind: Post 9 documents the procedure; Post 10 documents its conditional activation — when the framework recommends to the adopter that Pattern 1 should be applied.

The activation criteria are quantifiable, and the document names them without softening:

• The module has ≥ 3 closed Charters on the same spec.
• The rolling mean (last 3 Charters) of the agent_quality.r_n_plus_one_emergent_count field in telemetry is greater than 6.
• No refresh PR has landed since the last branch point.

The > 6 threshold isn't arbitrary. It's Sentinel CHARTER-18 turned into a rule: the average of emergent findings (risks discovered during the Charter that weren't declared in the original plan) during CHARTER-15, 16, 17 was exactly what triggered the feeling that the spec was accumulating too much debt. The framework, instead of asking the adopter to trust intuition, gives them a number their telemetry can compare against.

What Pattern 1 produces, when applied:

• A categorized table in research.md that enumerates what was discovered in prior Charters into four types: reusable patterns, code gaps, discipline patterns, empirical corrections.
• Explicit operational decisions (D1, D2, etc.) if categorization shows trade-offs.
• Citations in the next Charter's §Context, by id, pointing to the integrated items.
• An opt-in pre_declare_refresh: telemetry block in the charter-telemetry.yaml of the Charter receiving the refresh.

The metric that holds the pattern up comes from Sentinel CHARTER-18 itself, cited literally in CHARTER-CHAIN-EVOLUTION.md:

"Sentinel CHARTER-18 was the first Charter in a 7-Charter chain to close cleanly without a mid-flight remediation Charter. estimation_drift_factor: 1.0, pre_work.items_discovered_during_planning: 0, overall_satisfaction: 5/5."

One single domain. N=1. The document says so without shortcuts: the pattern is empirically validated in Sentinel. Wait for the second domain before crystallizing it higher.

3. Pattern 2 — Amend-on-emergence​

The literal definition:

"The amendment rides the same execute branch as the original Charter (the branch is still mergeable to main; the amendment commit lands on top)."

The idea: when a closed Charter receives post-close external audit findings — critical or high — the framework doesn't force opening a new Charter. The operator can amend the closed Charter while the execute branch is still mergeable to main.

The justification, also literal from the document:

"A new Charter would have created multi-week governance overhead for ~6h of focused engineering."

That asymmetry — weeks of governance vs. six hours of engineering — is what the pattern resolves. Opening a new Charter to fix five post-close findings means: declare new context, repeat external audit, generate new AILOG, register telemetry from scratch. For a correction that in code takes an afternoon. Pattern 2 says: no.

The activation criteria, also quantifiable:

• Critical/High findings appear post-close, after external audit.
• The Charter's closure criterion was materially unmet by those findings.
• The fix surface is under 25 files.
• It doesn't require architectural reopening (design decisions the original Charter assumed closed).

If all four criteria hold, Pattern 2 applies. If any fails, you have to open a new Charter.

What it produces, when applied:

• An amendment commit on the same execute branch as the original Charter.
• A new AILOG (don't edit the original) with risk_level: high, review_required: true, and an amends: field pointing to the original AILOG.
• A ## Historical correction (YYYY-MM-DD) section in the original AILOG pointing forward to the new one. It's archival: the original AILOG isn't rewritten; it's linked.
• A post_close_amendment: telemetry block in the charter-telemetry.yaml.

The empirical metric backing Pattern 2, cited literally:

"Sentinel CHARTER-18 closed 2026-05-15 with audit reports landing 2026-05-15..05-17. Five findings (4 from gpt-5.3-codex, 1 from gemini-2.5-pro) were code-level fixes — DI wiring, retry header parsing, multi-tenant filter, timeout default. The Batch 7.4 amendment closed all five in one cohesive commit (19 files, +2257/-106 lines)."

One commit, 19 files, two auditor models converging on similar findings, five fixes. If it had been a new Charter: minimum two weeks between declare, external audit, and close. Instead: an amendment on the same branch, six hours.

4. Composition, not exclusion​

The most interesting piece of the document — and, I think, the one that best closes the arc — is the section on how the two patterns relate. Cited literally:

"A Charter that received Pattern 1 is more likely to avoid Pattern 2, because the refresh absorbs pre-execution risk that would otherwise surface as post-close findings. But CHARTER-18 needed both — the refresh handled spec-level drift; the amendment handled runtime-level drift the refresh did not reach into."

They aren't rival patterns. They're applications of the same principle at different moments of the cycle. Pattern 1 absorbs spec-level drift — what the original plan no longer describes correctly. Pattern 2 absorbs runtime-level drift — what only shows up once the code runs, external auditors look at it fresh, and it emerges from the code itself.

Sentinel CHARTER-18 needed both. The refreshed spec eliminated emergent findings a later audit cycle would have had to remediate atomically; the later amendment absorbed what the refresh couldn't have predicted — DI wiring, retry header parsing, a multi-tenant filter, a timeout default. Things the plan couldn't know and that only emerged when the code existed.

The framework, by naming the two patterns and explicitly declaring their composition, does something I want to underline: it puts on record that discipline isn't linear. There isn't a single inspection point before each Charter; there's one before (Pattern 1) and one after (Pattern 2), and both may be necessary in the same Charter. The chain evolves; the patterns evolve too.

5. The schema and the helpers​

What fw-4.16.0 added to the telemetry schema are two optional sub-objects in charter-telemetry.schema.v0.json v0.2:

pre_declare_refresh:
  enabled: boolean
  refresh_pr: string | null
  refresh_aidec: string | null
  reusable_patterns_integrated: integer  # ≥ 0
  code_gaps_integrated: integer
  discipline_patterns_integrated: integer
  empirical_corrections_integrated: integer
  operator_decisions_ratified: integer

post_close_amendment:
  applied: boolean
  trigger: external_audit | production_incident | deferred_implementation
  ailog_id: string
  findings_closed: integer
  files_modified: integer
  effort_hours: number

Integer counters, not narratives. The decision is deliberate: what the telemetry schema captures is what the agent or operator can count mechanically. What can't be counted — how deep the problem was, how clever the fix was — lives in the AILOG, not in telemetry. The schema measures the shape of work; the documents carry the content.

And cli-3.14.0 added two helpers, neither mutator:

• straymark charter refresh-suggest <module> [--threshold N] — read-only. It reads the telemetry of the last three closed Charters of the module, computes the rolling mean of r_n_plus_one_emergent_count, and emits a recommendation: refresh-now, not-needed, or insufficient-data. Exit 0 always. It's informational, never a CI gate.

• straymark charter amend <CHARTER-ID> --trigger <kind> --ailog-title <title> [--findings-closed N] [--merge-into <PATH>] — scaffolding. It creates an AILOG stub with the correct fields (risk_level: high, review_required: true, amends: pointing to the original), adds the ## Historical correction section to the original AILOG, and renders the post_close_amendment: YAML block. Doesn't touch git.

Keeping the two helpers humble — one only recommends, the other only prepares — is consistent with the A1 decision of Post 4: "the CLI orchestrates but doesn't invoke APIs". Here: the CLI suggests but doesn't decide; scaffolds but doesn't mutate. The human remains the point where discipline happens. The framework only puts the tools within reach.

6. Seventy-seven minutes later​

There's one more piece worth recording before the arc's closing. PR #157 merged at 00:31 UTC on 16 May. PR #160 — the one from Post 1, EMERGENT-OBSERVATION-DESIGN.md, fw-4.17.0 — merged at 01:48 UTC the same day. Seventy-seven minutes later.

What happened in those seventy-seven minutes is the inverted closing of the arc. The philosophical meta-pattern Post 1 named — emergent observation composed of formal links plus cultural permission to flag — crystallized one hour and seventeen minutes after the two operational meta-patterns of this post. The philosophical meta-pattern doesn't precede the discipline; it succeeds it. It's the ascending reading of the same evidence.

CHARTER-CHAIN-EVOLUTION.md records it explicitly in its §Related section:

"EMERGENT-OBSERVATION-DESIGN.md — the meta-pattern of which Pattern 1 and Pattern 2 are applications (formal cross-referencing + cultural permission to surface)."

Pattern 1 is composition of formal links (the r_n_plus_one_emergent_count telemetry, the citations by id in §Context, the categorized AILOGs) with cultural permission (the rule that an agent should flag drift between spec and code when it finds it). Pattern 2 is similar composition (the AILOGs with amends:, the Historical correction section linking forward) with permission to flag post-close findings instead of absorbing them in silence. The two patterns are applications of the same cultural+structural principle that Post 1 named from above.

It's an ending I keep liking: the blog that opened saying "the agent saw something nobody asked it to see" closes saying, in the chronologically preceding episode, "here are the two things the agent can see well because the framework names them".

7. Closing the arc​

Ten posts. Eleven episodes covered (H-01 through H-13, with several bundled). One editorial decision — retroactive publication — that Post 2 introduced and the nine following posts honored without violating it. A bilingual commitment that held at every close.

Some things I learned writing the blog and that are worth recording before closing it:

1. The pattern is born of the discipline. The phrase already appeared in Post 9, but the entire arc holds it. The meta-patterns of this post weren't designed; they were extracted. Each documented milestone had its operational episode first and its name after.

2. The cadence isn't uniform. Nineteen days between the first commit (Post 2, 27 January) and the first bounded unit with external audit (Post 3, 25 April). Five hours between applied discipline and canonized discipline (Post 9, 14 May). Seventy-seven minutes between two meta-patterns and their philosophical reading (Posts 10 and 1, 16 May). The project went through every speed, and the blog records them all.

3. The framework isn't neutral with respect to its adopter. Sentinel made it possible for each pattern to be empirically validated before being crystallized. The blog doesn't hide that provenance; it underlines it as a methodological precondition.

4. What isn't named, isn't seen. Post 5 formulated it as structural visibility; Post 7 applied it to transversal debt; Post 8 pointed it out about the language outlier. It's the most persistent regularity of the arc. Existing as a technical artifact isn't enough. The name activates the artifact.

The arc the blog came to tell — milestones H-01 to H-13, the four names of the project, the six Plans, the first-class Charters, the external audit cycle, Issue #113, the rebrand to StrayMark, the TDE, the audit-prompt outlier, the manual discipline, and the two meta-patterns — closes here. What's left as explicit debt: H-14, the straymark explore TUI (which appeared laterally in Post 8 as a visibility tool), and the candidate milestones H-?-A to H-?-E that PLAN-INVESTIGACION.md §1.43-55 listed as pending. Possible future second batch. No promise.

One last observation, symmetric to Post 1. That post opened saying: "the agent saw something nobody asked it to see". What the blog closes by recording, after ten episodes, is the other half of the sentence: the agent saw because the framework had put it in conditions to see. The emergent observation of Post 1 is the proof; the named patterns of this post are the preconditions. Every thing the agent surfaced during the four months the arc covers was possible because some prior episode had put an artifact, a trigger, a formal link, a visible surface where there was nothing before.

The blog finishes telling the story. The framework goes on.

Anchors: Issue #156. PR #157 — fw-4.16.0 / cli-3.14.0 (merged 2026-05-16 00:31 UTC). Canonical document: CHARTER-CHAIN-EVOLUTION.md. Schema: dist/.straymark/schemas/charter-telemetry.schema.v0.json v0.2. Successor meta-pattern: EMERGENT-OBSERVATION-DESIGN.md, fw-4.17.0 (merged 2026-05-16 01:48 UTC, 77 minutes later).

This document was produced with assistance from generative AI tools (Claude 4.7); all responsibility for the content rests with the human author.

— End of the H-01 → H-13 arc of the StrayMark blog.

1. Four months between intuition and standard​

On 15 May 2026, at 19:05 UTC, PR #155 closed the framework as fw-4.15.0 / cli-3.13.2. What it brought is a single new file in the list of directives the CLI injects: AGENTS.md, at the adopter's repo root, parallel to the ones already there (CLAUDE.md, GEMINI.md, .github/copilot-instructions.md, .cursorrules, .cursor/rules/straymark.md).

This would be trivial if it weren't for the fact that exactly four months earlier, on 27 January 2026, the project's first AIDEC — the one Post 2 covered with the typo'd-year anecdote — had declared:

"AI agents (Claude, Gemini, Copilot, Cursor) process instructions equally well in any language, so translating their config files provides no functional benefit."

That sentence, written six hours after the project's initial commit, contained an intuition the framework had been operationalizing ever since: agents are a single technical audience. Config files (CLAUDE.md, etc.) stayed in English (while human documentation got translated into three languages) because the "AI agents" audience didn't benefit from translation. What was missing to close that intuition was giving it a single place to point at, without having to clone the file four or five times for each different vendor.

This post covers exactly that: how AGENTS.md — an open standard donated to the Agentic AI Foundation in December 2025 — completed four months later the decision the first AIDEC had opened in January.

2. The fragmentation AGENTS.md resolves​

Between 2024 and 2026, while AI agent CLIs proliferated, each one invented its own instruction-file format:

• Anthropic published CLAUDE.md with the first version of Claude Code.
• Google adopted GEMINI.md for Gemini CLI.
• GitHub established .github/copilot-instructions.md for Copilot CLI.
• Cursor started with .cursorrules and later migrated to .cursor/rules/*.md.
• OpenAI used another path for Codex CLI; Aider, Devin, Continue, Roo Code, Factory Droids, Sourcegraph Amp, Zed AI, Windsurf, Amazon Q each had their own.

A StrayMark adopter using two or three of those CLIs had to maintain two or three copies of the same content, hand-synced, hoping none diverged. Up to fw-4.14.x, the framework acknowledged that fragmentation in its straymark init command: it injected into the five most common vendor-specific files. But the other ten or fifteen CLIs were left out. The adopter handled them by copying content by hand.

In late 2025, the community of open-source projects producing agent CLIs did what gets done when a fragmentation becomes costly: they agreed on a standard. AGENTS.md at the repo root, read by everyone. The donation to the Agentic AI Foundation (Linux Foundation, December 2025) gave it institutional governance. The specification is deliberately minimal: a Markdown file, no imposed schema, in a predictable location. What each CLI does with that file is its own business; the canonical question — "where is the agent configuration for this repo?" — now has a single answer.

By May 2026, the list of CLIs that read AGENTS.md includes (cited literally from the PR #155 body):

"Claude Code, OpenAI Codex CLI, Cursor, Aider, Devin, Sourcegraph Amp, Google Jules, Zed AI, Continue, Roo Code, Factory Droids, GitHub Copilot, Gemini CLI, Windsurf, Amazon Q and others."

Fifteen CLIs. Some still read also their vendor-specific files for historical compatibility. But all fifteen know to look for AGENTS.md first.

3. Adopt without killing your own​

The most interesting decision of fw-4.15.0 isn't adopting AGENTS.md; that was inevitable once the standard had critical mass. What's interesting is how. The PR body articulates it without softening:

"Parallel to CLAUDE.md / GEMINI.md: marker block points to STRAYMARK.md, with a minimum-viable body below for readers that cannot follow relative links."

Three key words: parallel, marker block, minimum-viable body.

Parallel means AGENTS.md doesn't replace vendor-specific files. It coexists. The framework still injects CLAUDE.md, GEMINI.md, .cursorrules and the others. The reason is pragmatic: some CLIs (notably Cursor in its legacy version) require the full content to be embedded, not behind a relative link. Keeping the sibling files preserves that compatibility without each adopter having to wrestle with their specific CLI.

Marker block is the convention the framework already used in the other vendor-specific files: an HTML-commented block between <!-- straymark:begin --> and <!-- straymark:end --> pointing to STRAYMARK.md as source-of-truth. Any straymark update-framework replaces only what's between those markers. Whatever the adopter wrote outside them — for instance, project-specific instructions — stays intact. The framework respects the adopter's file; it only governs its own section.

Minimum-viable body is the concession to CLIs that don't follow relative links. Below the marker block, AGENTS.md carries a short body with the essentials: agent identity, review requirements, pre-commit checklist, regulatory frontmatter snippet, NIST AI 600-1 risk categories, observability rules, naming convention. It's enough for an agent that can't read STRAYMARK.md to operate correctly; it's insufficient to replace the canonical document. The asymmetry is deliberate: we want the agent to want to open STRAYMARK.md.

The defensive CLI detail (cli/src/commands/remove.rs:13) closes the operational flank: AGENTS.md was added to LEGACY_DIRECTIVE_TARGETS. If an adopter loses their .straymark/dist-manifest.yml and runs straymark remove, the legacy fallback cleans AGENTS.md too instead of leaving it orphaned. It's boring housekeeping, but it's the difference between a framework that uninstalls completely and one that leaves debris.

4. No ADR​

It's worth naming an absence. The decision to adopt AGENTS.md did not get its own ADR.

It's a deliberate contrast with Post 6's StrayMark rebrand, which did have a public ADR-2026-05-08-001 with three evaluated alternatives and enumerated consequences. It's also a contrast with Post 12's Phase 2, which had a dense CHANGELOG entry with architectural justification. fw-4.15.0 had only the PR body as documentary justification — a good body, with a clear argument, but not an ADR.

Why? The operational answer: the decision was perceived as additive, not structural. Adopting an open standard that coexists with existing formats doesn't change the framework's model; it only extends it. There's no alternative whose dismissal would require formal justification: not adopting AGENTS.md would mean leaving fifteen CLIs out for aesthetic preference, and nobody had that argument to make.

But there's a recordable lesson here. The blog has seen the pattern before — Phase 2 closes an empirical loop, the rebrand changes identity, Post 10's meta-patterns name what was already there — and in each case the question "does this deserve an ADR?" has a different answer. The operational rule the framework seems to have adopted, without naming it, is this: an ADR is justified when the decision closes costly alternatives and leaves a record of those not chosen. fw-4.15.0 didn't close costly alternatives — it only added a layer. So the PR was enough.

I leave it on the record here because it's worth acknowledging that not every change deserves an ADR, nor is every PR a historical document. Archival discipline has its own criteria.

5. Visibility for agents, two layers​

Ten days before fw-4.15.0, on 9 May, Issue #113 was closed — the episode Post 5 documented as "Charters invisible to the agents". The operator had worked six hours with a capable, attentive agent, with the canonical onboarding apparatus loaded, and the agent had never proposed using a Charter. The conclusion that post canonized: structural visibility is the framework's responsibility, not the agent's property.

fw-4.15.0 covers the other face of the same problem.

Post 5 was about internal structural visibility: how we ensure an agent already reading our repo discovers the framework's core concepts. PR #122's answer (Post 5) was to multiply the internal surfaces where Charter appears as a concept: STRAYMARK.md §15, CLAUDE.md/GEMINI.md directives, /straymark-* skills, status output, templates, the bridge to SpecKit. Nine internal surfaces.

This post is about external structural visibility: how we ensure any agent entering the repo, whatever its vendor, finds the framework's apparatus. fw-4.15.0's answer is to adopt the canonical meeting point the community chose. One external surface, read by fifteen vendors.

Both layers share the same conceptual axis — a technical artifact only exists for the agent if the surface names it — but a different scope. Internal visibility guarantees the agent sees the Charters while reading STRAYMARK.md. External visibility guarantees the agent sees STRAYMARK.md when entering the repo. One layer without the other is incomplete.

6. What the adopter does when running update-framework​

The operational part of the release, cited literally from the CHANGELOG:

"straymark update-framework brings the new template and injects AGENTS.md at the project root. The injection follows the same rules as every other directive target: it creates the file if absent, replaces the marker block on subsequent runs, and appends safely when the file pre-exists without StrayMark markers (very common in 2026 — many adopters already hand-maintain an AGENTS.md)."

Three important behaviors:

1. If it doesn't exist, the CLI creates it with the canonical template.
2. If it already exists with StrayMark markers, the CLI replaces only the content between markers.
3. If it already exists without markers — very common in 2026, because many adopters were already writing their own AGENTS.md by hand — the CLI appends its markers at the end of the file, without touching what the adopter had written.

It's the same archival respect the blog already documented in Posts 3 and 6: the framework governs its section, not the whole file. If the adopter wants to write project-specific instructions in their AGENTS.md — internal policies, naming conventions, instructions specific to a particular codebase — those instructions stay intact at every update. The StrayMark block lives within its small marked boundary, and updates within that boundary.

The CHANGELOG note closes with a small operational warning worth recording: "If your .gitignore excludes AGENTS.md, adjust it before update-framework so the injection lands in version control." It's honest about edge cases the framework can't resolve on its own — the adopter's choice to ignore the file is sovereignty, not error.

7. Closing​

What I took from the process, in four claims:

1. Four months between intuition and materialization is what it takes to close a loop well. January's AIDEC carried the intuition — "agents are a single audience". fw-4.15.0 closed it with an open standard. Between the two, the framework iterated on vendor-specific archetypes until the universal substitute appeared. The early intuition was right; the timeline was what the ecosystem's maturation required.

2. Adopting an open standard doesn't require renouncing your own format. AGENTS.md coexists with CLAUDE.md, GEMINI.md, .cursorrules. The decision isn't "one replaces the others" but "one joins the others when it contributes". The framework gains external visibility without losing compatibility with CLIs that require specific formats.

3. Not every change deserves an ADR. The StrayMark rebrand closed costly alternatives and left a formal record of the discarded ones. fw-4.15.0 only added a universal layer: no ADR would have enriched the decision. Archival discipline has operational criteria, not doctrines.

4. Visibility for agents operates in two layers. The internal layer (Post 5, fw-4.12.0) ensures the agent sees the framework's concepts while reading the repo. The external layer (fw-4.15.0) ensures the agent enters the repo through the right door regardless of which CLI orchestrates it. One without the other leaves either capable agents reading in silence or disoriented agents with no entry point.

Anchors: PR #155 — fw-4.15.0 / cli-3.13.2 (merged 2026-05-15 19:05 UTC). Original AIDEC (Post 2): .chronicle/07-ai-audit/decisions/AIDEC-2025-01-27-001-i18n-strategy.md (commit 7b7193e, ID with typo'd year). Injected template: dist/dist-templates/directives/AGENTS.md. Standard specification: agents.md — donated to the Agentic AI Foundation (Linux Foundation), December 2025.

This document was produced with assistance from generative AI tools (Claude 4.7); all responsibility for the content rests with the human author.

1. Two gestures in seventy-two hours​

On 13 May 2026, at 06:20 UTC, fw-4.13.4 merged. It closed two small i18n coverage gaps — the ISO-25010 reference document that was only in English, and the Charter template that was missing in Simplified Chinese. Twenty-two canonical framework files reached structural EN/ES/zh-CN parity.

On 15 May, at 00:14 UTC, sixty-five hours later, PR #154 merged. It added a badge to the README — the CLA Assistant one, that small visible square that tells the visitor the repo accepts contributions under a Contributor License Agreement. The CLA policy had existed for months already in CONTRIBUTING.md; the only thing that changed was that it now appears in the README at first glance.

This post covers the two gestures. Seen separately, they're small — one completes the last 5% of a technical job, the other publishes something that was already there. Seen together, they're the moment the framework decides to present itself to the outside. The piece an open-source project does when it stops talking to itself and starts talking to whoever wants to read it.

2. The last 5% of i18n coverage​

fw-4.13.4 isn't a big release. PR #144 has 511 addition lines and almost all are translations. But the PR summary says something worth recording:

"Brings governance docs to full 20/20/20 parity across EN + ES + zh-CN."

Twenty over twenty over twenty. Twenty-two canonical files in dist/.straymark/00-governance/ (the count grew later; in May it was twenty), all with their counterpart in i18n/es/ and i18n/zh-CN/. Full parity, not approximate.

The two files that closed parity are specific:

• ISO-25010-2023-REFERENCE.md — the normative reference to the international software quality standard, cited from framework principles. Up to fw-4.13.4 it existed only in English. The release added i18n/es/ISO-25010-2023-REFERENCE.md and i18n/zh-CN/ISO-25010-2023-REFERENCE.md, 150 lines each.
• charter-template.md in zh-CN. The Charter template was already translated into Spanish; Simplified Chinese was missing, 211 lines.

It's not glamorous work. It's the piece that closes a frame. But it matters for two things. First: until that release, a Chinese adopter cloning the framework was going to find essential templates in English only, which contradicts the promise that the framework is available in three languages. Second: the blog already documented in Post 8 that the framework's i18n coverage was nearly complete, with two minor gaps remaining as recorded debt. fw-4.13.4 closed that debt. What looked like a side note in a post about the audit-prompt outlier turned out to be a release of its own, with its own CHANGELOG entry.

3. What gets translated and what doesn't​

There's an operational rule that PR #144 codifies explicitly and that's worth recording, because it's the framework's clearest rule on i18n:

"LLM-processed assets (skills, workflows, schemas) stay EN-only; human-primary artifacts get translated."

That is: what AI agents read — skills, workflows in .claude/, .gemini/, .agent/, schemas in dist/.straymark/schemas/, prompts in dist/.straymark/audit-prompts/ — lives in English only. What humans read — documentation, principles, contribution guides, templates with human-facing copy — gets translated into the three languages.

It's the same principle Post 13 documented as the intellectual ancestor of the universal AGENTS.md: agents are a single technical audience that doesn't benefit from translation. What's recordable here is that the rule, in May, is written into a PR as an operational criterion, not as an intuition. Technical proposals cite it; reviewers use it to decide whether a new file goes into i18n/ or not.

One additional detail from PR #144 is worth recording literally:

"docs/contributors/TRANSLATION-GUIDE.md gap was left intentional — its target audience already reads English to read the guide."

The translation guide stayed intentionally in English because its audience — contributors translating the framework into other languages — necessarily already reads English. It's operational honesty: 20/20/20 parity isn't 22/22/22 for every repo file. It's 20/20/20 for files whose translation adds user value. The difference between total coverage and applicable coverage.

4. The badge that introduced nothing new​

PR #154 is the pedagogical opposite of fw-4.13.4. Where fw-4.13.4 closes technical work, PR #154 publishes something that was already there. Its 12 lines of change add exactly this to the README (in English, Spanish, and Chinese):

[![CLA assistant](https://cla-assistant.io/readme/badge/StrangeDaysTech/straymark)](https://cla-assistant.io/StrangeDaysTech/straymark)

A badge. A small image that appears above the README, next to the other project badges (license, version, downloads). Visually unremarkable.

But the badge isn't decoration. It's a signal. And the signal says something concrete: "this repo accepts external contributions, and here are the rules". Any visitor who opens the README can click the badge and land at CLA Assistant — the service that automatically comments on any contributor's first pull request, asking them to sign the Contributor License Agreement. One signature covers all future contributions to the project.

What matters is that the CLA, the CONTRIBUTING.md, the full review policy, all of that existed before PR #154. It was coded, alive, operational. The framework already accepted external contributions — it's just that the casual repo visitor had to open CONTRIBUTING.md to find out how it worked.

PR #154 makes a distinction worth naming: having the policy and publishing the policy are two different things. The first is internal discipline; the second is a public invitation. Until 15 May, the framework had the policy. From 15 May, it publishes it.

It's an editorial change, not an architectural one. But the day an open-source project decides to put the CLA Assistant badge above the README is the day it decides to formally present itself as adoptable by third parties. It's the moment the framework stops being a one-developer-and-its-adopter (Sentinel) project and becomes a project that accepts having more adopters, more contributors, more hands.

5. When a framework feels ready to be seen​

These two milestones, read together, record a specific moment in a young framework's life: the moment it feels ready to be seen by people who didn't write it.

fw-4.13.4 closes the technical promise. If the framework says it's bilingual Spanish-English with experimental Simplified Chinese support, the twenty-two canonical files must be in all three languages. Not nineteen out of twenty. Not twenty out of twenty-one with two pending. Twenty over twenty over twenty. Full parity is what makes the promise credible when the visitor checks.

PR #154 closes the social promise. If the framework says it accepts external contributions, the CLA badge in the README is the industry-standard way of saying so. Without the badge, the openness exists but you have to discover it; with the badge, it's signposted. The visitor's first click finds the path.

It's worth naming the asymmetry of the two gestures. Closing the last 5% of technical work costs exactly that — a dedicated release, two translated files, a CHANGELOG entry. Publishing a preexisting policy costs twelve lines of Markdown. The cheap one is sometimes the operationally most significant gesture, because it changes how the outside world perceives the project without changing anything about the project itself.

It's the "opening the framework" version of the pattern Post 5 documented as structural visibility: what exists but isn't named, doesn't exist for the agent. Here: what exists but isn't published, doesn't exist for the external adopter. Seventy-two hours in May, two small milestones — one technical, one editorial — and the framework crosses the line between "it works but whoever wrote it knows it" and "it works and anyone can see it".

6. Symbolic closing of the arc​

With this post, the blog covers the last pending milestones from the second batch that RETOMAR-AQUI.md §5 listed after the closing of the main H-01 → H-13 arc. The four identified candidates — H-?-C (validate + schemas), H-?-A (universal AGENTS.md), H-?-B (full i18n coverage), H-?-E (CLA badge) — are all covered: three in their own posts (Posts 12, 13, this one) and one combined.

What I learned writing the second batch, looking at the four milestones together:

• Phase 2 / validate (Post 12) is structural: the framework starts to verify what it had been promising.
• TUI explore (Post 11) is about visibility: the framework becomes navigable.
• Universal AGENTS.md (Post 13) is about reach: the framework becomes discoverable by any CLI.
• Full i18n coverage + CLA badge (this post) is about opening: the framework becomes visible to the external visitor.

Each one covers a distinct dimension of the same idea, which the blog already encoded in earlier posts: what a framework says it is isn't enough for it to be; it has to be present on every surface where someone — agent, external adopter, visitor — can build a model of the project. The second batch's milestones are the mature version of the structural visibility Post 5 named with a governance Issue.

Now, after Post 14, there are no more candidates in the queue. If new framework milestones emerge between today and when the blog's next session activates, RETOMAR-AQUI will be used again as the resumption point. If none emerge, this post is the real closing — the closing that completes the inventory the blog set out to cover.

7. Closing​

What I took from the process, in four claims:

1. Total coverage costs little at the end of the work and a lot at the beginning. The last 5% — those two files in Chinese — is a dedicated release. But it's only trivially closable because the other 95% was already done. 20/20/20 parity isn't born at the start; it's pursued for months and closed at the end with a small PR.

2. Having a policy and publishing it are two different things. The framework's CLA existed months before the badge. Twelve lines of Markdown turned an internal policy into a public invitation. The day you put the badge you invent nothing; you declare you're ready to be found.

3. The operational rule of what gets translated is archival. What humans read gets translated; what agents read lives in English. That distinction, intuited from January's first AIDEC, became an explicit review criterion in May. Every new framework file passes through that question before choosing its destination.

4. When a framework becomes adoptable by third parties is a decision, not a state. There's a day when the operator decides the framework can be seen without embarrassment by people who didn't write it. That day materializes in small gestures — completing translations, publishing the badge — that don't change functionality but change posture. The framework stops talking to itself.

With this the blog closes the second batch. The arc that started retroactively with the project's prehistory (Post 2, January) and completed with the meta-patterns (Post 10, May) now also has its corollary: the milestones that made the framework adoptable. Fourteen posts, twenty-eight files (fourteen ES + fourteen EN), between twenty-five and twenty-six thousand words per language. As the closing of Post 10 said: the blog finishes telling the story. The framework goes on.

Anchors: PR #144 — fw-4.13.4 (merged 2026-05-13 06:20 UTC, full i18n coverage). PR #154 — CLA Assistant badge in READMEs (merged 2026-05-15 00:14 UTC). Full policy: CONTRIBUTING.md (repo root + translations in docs/i18n/{es,zh-CN}/CONTRIBUTING.md).

This document was produced with assistance from generative AI tools (Claude 4.7); all responsibility for the content rests with the human author.

— End of the second batch of the StrayMark blog.

1. The right question​

Issue #150, opened on 14 May at 16:59 UTC, wasn't looking for a yes/no. What the operator was asking was for the question to be reframed:

"The real question the bridge doc should address is how, not whether: what discipline ensures spec stays in sync with code during multi-Charter execution without the regeneration step lying about the parts that already shipped."

The discipline already existed. It was being applied in Sentinel at that very moment, on CHARTER-18, by hand, with the feeling that any false step would bury the work of six previous Charters. What was missing — what the Issue documented with uncomfortable precision — was the name. The when. The rules a future adopter could follow without going through the pain of inventing them.

This post covers the five hours between that Issue and the PR that canonized the discipline as upstream governance, the 12 empirical learnings that justified the canonization, and the concrete operational episode — Sentinel's CHARTER-18 — that exercised the pattern before the pattern existed. The next post will cover what came 27 hours later: the name.

2. Seven Charters on the same plan​

Context, in one line: Sentinel executed specs/002-commshub/plan.md — written in commit be29421 on 21 April 2026 — through seven consecutive Charters (CHARTER-07 through CHARTER-17), one calendar month, without refreshing the plan once.

The original plan was good. It was carefully written, with four user stories (US1-US4) detailed, the data-model declared, the contracts sketched. But the plan was a snapshot of how the operator imagined, back in April, the code would behave. Execution discovered things the plan couldn't have anticipated:

• Infrastructure patterns that appeared during execution and turned out to be reusable (a namespace in core.processed_events, a withRLS helper, PL/pgSQL triggers for invariants).
• Code gaps the plan assumed resolved (AnomalyDetector half-built, missing idempotency dedup, Recipient.TenantID schema gap).
• Charter/audit patterns that crystallized over the month (cross-family audit cycle, HTTP layer test coverage gap, cursor pagination with strict-greater-than).

When the time came to plan CHARTER-18 for US5, the plan was a month old and the code had a month of empirical learning on top. The two weren't in sync. And SPECKIT-CHARTER-BRIDGE.md — the framework document that would normally answer "what do I do here?" — was silent on the case. The rule "how spec stays in sync with code during multi-Charter execution" didn't exist yet.

3. The twelve empirical learnings​

Issue #150 enumerates the twelve learnings that had accumulated without reflection in the plan. The literal table, grouped by type, is worth keeping in view:

Four infrastructure patterns discovered or refined during execution. Four code gaps the plan didn't anticipate. Four Charter/audit patterns crystallized on the fly. Twelve pieces, in a single month, all real. The plan didn't have them. And the next Charter — CHARTER-18 — was going to read the plan as if they didn't exist.

The estimate the operator documented in the Issue is honest:

"Estimated probability of ≥1 critical/high finding from stale-premise inheritance: ~50%."

Coin flip, in one word. Half of Charters started on a stale plan end with a critical finding a later audit cycle has to remediate atomically pre-close. And the other half escape only by luck.

4. Alternative 4: the discipline applied by hand​

What happened inside Sentinel, that same day, before the discipline had a name: the operator evaluated five concrete alternatives and chose the fourth. Sentinel's private AIDEC — AIDEC-2026-05-14-001-speckit-plan-scope-limited-us5-refresh.md — records the analysis without softening. I paraphrase it here because the detailed content lives in the private repo, but the structure of the reasoning is what matters:

• Alternative 1 — "Read it as before". Keep the plan stale and read it as the previous six times. Cost: pay the debt in a later audit cycle, ~50% probability of critical finding.
• Alternative 2 — Regenerate everything with /speckit-plan. Risk: overwriting assertions about US1-US4 that the real code doesn't satisfy; the regenerator doesn't know the current state.
• Alternative 3 — Refresh in another PR without restrictions. Same risk as Alt 2 plus review friction.
• Alternative 4 — Scope-limited refresh + 3 gates. The chosen one.
• Alternative 5 — Defer CHARTER-18, do a refactor Charter first. High calendar cost, marginal benefit over Alt 4.

The fourth consisted of three concrete mechanisms:

First mechanism — scope-limited prompt. Run /speckit-plan with an explicitly restrictive prompt: regenerate only Phase 7+8 corresponding to US5; leave US1-US4 byte for byte as they are, marked with <!-- LOCKED: prior US shipped --> comments the agent must respect. Without that explicit restriction, SpecKit's regeneration is destructive: it rewrites the whole plan, overwriting descriptions the real code already contradicts.

Second mechanism — Gate (a): validation against code reality. An ad-hoc script, ~30 lines of bash + grep, that diffs each non-US5 entity in data-model.md against the real schema in db/migrations/*.sql, and each non-US5 endpoint in contracts/*.md against the actual handler signatures in internal/modules/commshub/handler_*.go. Any divergence blocks merge. The script exists in Sentinel's repo; it isn't elegant, it's operational. What the framework would canonize later as gate (a) was already there, as artisanal bash.

Third mechanism — Gate (b): granular hunk-by-hunk review. Review git diff file by file, hunk by hunk, accepting no changes to locked sections without justification. The operator explicitly notes the expected friction in R1 of the AIDEC: if the agent regenerates more hunks than necessary, the human reviewer tires and the discipline collapses. Mitigation: hunks over 50 lines trigger P1 review.

Fourth mechanism — Gate (c): two-PR split. The refresh is an independent PR, reviewed against current code. The Charter-fill that follows is another PR, reviewed against the already-refreshed plan. Don't mix the two reviews — because if they're mixed, the refresh's debt hides behind the new work.

Four mechanisms. Applied manually, with no upstream documentation backing them. A single adopter (me), a single session, and the feeling the whole time of solving a case no one had solved before.

5. The result​

CHARTER-18 closed the same day. The Charter Telemetry metrics, recorded literally in the closure YAML:

• estimation_drift_factor: 1.0 — the Charter finished exactly in the estimated hour range.
• pre_work.items_discovered_during_planning: 0 — no unexpected items appeared during planning.
• overall_satisfaction: 5/5 — the operator's best subjective calibration in the entire chain.

More important than the metrics: CHARTER-18 was the first Charter in the chain of seven to close without a mid-flight remediation Charter. The previous six had each needed, at least one, an atomic pre-close remediation to cover divergences between what was declared and what was delivered. CHARTER-18 didn't. The operator's closing statement, cited literally from the later CHARTER-CHAIN-EVOLUTION.md:

"The SpecKit refresh from PR #76 eliminated most ambiguity that drove drift in prior Charters. No mid-flight remediation Charter required — the EC1..EC15 empirical-corrections inventory in research.md absorbed what would have been pre-execution risk into in-execution awareness."

The manual discipline worked. It didn't just close the Charter cleanly; it changed the nature of the risk. What used to be pre-execution risk (discovering divergences during Charter execution, remediating atomically) became pre-planning awareness (the EC1..EC15 inventory enumerates the empirical corrections before declaring the Charter). The risk isn't eliminated; it's moved to a moment where it's manageable.

6. Four hours and forty minutes​

The chronology is worth keeping precise, because it's what the blog comes to record:

• 14 May, 16:59 UTC — Issue #150 opened. Twelve learnings enumerated, three gates proposed, probability analysis published.
• 14 May, 21:39 UTC — PR #152 merged. fw-4.14.3 shipped. "Spec maintenance during multi-Charter execution" added as a new section of SPECKIT-CHARTER-BRIDGE.md with the three gates canonized literally as framework governance. Four hours and forty minutes between the question and the upstream answer.

What PR #152 documented as governance is exactly what the private AIDEC had applied by hand hours earlier. The three gates with the same names: validation against code reality (gate a), granular hunk-by-hunk review (gate b), two-PR split (gate c). Plus four heuristics of when to refresh: ≥3 closed Charters on the same plan, ≥4 weeks + ≥2 Charters, R<N>(new) count > 6, target US touches refined infra. Plus an explicit note on why NOT to re-run /speckit-tasks (because it destroys the [X] markers and the *CHARTER-NN:* <sha> annotations that form the historical trace). Plus a roadmap note mentioning a future straymark spec-drift CLI that would mechanize gate (a).

Four hours. It's no exaggeration to say the framework wrote the guidance while the operator still had git diff open in another window. The discipline and its canonization were practically simultaneous. And that's worth recording because it's the reverse of the order the academic governance apparatus usually assumes: theory first, then practice. Here it went the other way. Practice first, while it hurt. Theory after, while the pain was still fresh.

7. Closing​

What I took from the process, in four claims:

1. The pattern is born of the discipline, not the other way around. The three gates of fw-4.14.3 weren't designed in the abstract; they were extracted from a concrete operational episode, hours after being applied by hand. Governance is post-empirical when the framework respects the order.

2. Explicit probability is discipline. "~50% probability of critical finding from stale-premise inheritance" isn't Bayesian precision; it's a public claim that forces the decision to be justified. Without that number, the question "should we refresh?" gets decided by intuition. With it, it gets decided by risk arithmetic.

3. Twelve learnings in thirty days is the actual cadence. It's not noise capturable with "let me read it later". It's empirical density the original plan couldn't have anticipated, and that destroys any long-range planning assumption. The cadence of agent-assisted development is this.

4. Four hours is not a record; it's a property of the process. When the discipline is already being applied in one domain, canonizing it upstream is execution, not design. Same as we saw in Post 4 about the external audit cycle ("five PRs in a day"), same in Post 6 about the rebrand ("forty-three minutes"). The framework didn't invent the discipline; it extracted it and gave it a name.

Next, in the following post, the last episode of the arc this blog came to tell: "Pattern 1 + Pattern 2 — chain evolution" (H-12). Twenty-seven hours after PR #152, the three governance gates crystallized as two named meta-patterns — pre-declare refresh and amend-on-emergence — with a telemetry schema and CLI helpers. It's the closing of the arc Post 1 opened from ahead.

Anchors: Issue #150 (14 May 16:59 UTC). PR #152 — fw-4.14.3 (14 May 21:39 UTC). Canonized section: SPECKIT-CHARTER-BRIDGE.md §"Spec maintenance during multi-Charter execution". CHARTER-18 metrics reported in CHARTER-CHAIN-EVOLUTION.md (fw-4.16.0). Private source paraphrased per GUIA-EDITORIAL.md §7: AIDEC-2026-05-14-001-speckit-plan-scope-limited-us5-refresh.md in Sentinel's repo.

This document was produced with assistance from generative AI tools (Claude 4.7); all responsibility for the content rests with the human author.

1. One line from the commit​

This is the post's operational opening. Commit a8a1ac5 from 12 May 2026 carries a body that begins with this sentence:

"The unified audit-prompt template at dist/.straymark/audit-prompts/ was the only framework artifact whose canonical content lived in Spanish — every other template, skill, workflow, and governance doc follows the EN-canonical + i18n/<lang>/ overlay pattern resolved by cli/src/utils.rs:146."

One single file. Among dozens. It lived backwards. And it had been living that way since May of the previous year, without anyone noticing.

This post is deliberately short. The fix it covers — PR #142, fw-4.13.3 and cli-3.12.3, merged on 13 May — is not a major narrative milestone. It's a maintenance piece. But it records one of the regularities I keep running into in this craft: outliers are useful. They teach you the convention by contrast.

2. Where the outlier came from​

The audit-prompt wasn't born in the framework. It was born as a local skill of Sentinel's — sentinel/.claude/skills/plan-audit/ — during the six-Plan experiment Post 3 covered, in April. It was a context-specific skill, written by the operator (me) in Spanish for reasons that can now be enumerated honestly: it was a private experiment, the operator speaks Spanish, and nobody was going to read the skill ever again. I improvised it in my language because it was for me.

When the experiment crystallized into the framework — the fw-4.4.0 to fw-4.9.0 arc Post 4 covered — the skill was ported to the canonical path dist/.straymark/audit-prompts/audit-prompt.md. The port was mechanical: copy the file, generalize it enough that it didn't mention Sentinel-specific components, adjust the Plan → Charter nomenclature. What wasn't done: translate it to English. The file entered the framework in the language it had been written in. Without anyone deciding it, Spanish became the canonical version of that one artifact.

The rest of the framework — every other template, every skill, the canonical governance docs — had been written in English since January, with Spanish and zh-CN as overlays under i18n/<lang>/. The audit-prompt was the silent exception, for six weeks, until 12 May.

3. How it was found: by visual inspection​

It wasn't emergent observation from the agent. The operator noticed it, visually. The CHANGELOG entry records it without metaphor:

"Surfaced empirically when Sentinel audited the straymark explore rendering and the user noted that audit-cycle templates were ES while all other templates and skills were EN."

straymark explore is the framework's TUI — the interactive documentation browser Post 14 will cover. Its value is rendering all templates side by side, in the same view. And when all templates are side by side, one in another language is obvious. That's the observation.

It's worth leaving the data because it matters for the blog's honesty. Post 1 articulated the pattern of emergent observation — an agent flagging something nobody asked it to flag — and Post 5 documented what happens when that pattern is missing because of structural visibility. This episode is neither. It's a more pedestrian observation: a new surface of the framework (the TUI) put all the files in simultaneous view, and the inconsistency became as obvious as when you tidy the bookshelf and notice one book is shelved with the spine backwards. Tools also produce visibility.

4. The fix: three moves in one commit​

PR #142 did three things in the same commit:

• dist/.straymark/audit-prompts/audit-prompt.md rewritten in English as the canonical version. 312 lines. The translation took care to preserve the severity structure and calibration examples of the original.
• dist/.straymark/audit-prompts/i18n/es/audit-prompt.md created as an overlay. 318 lines. It's the Spanish content that used to live in root, now in its correct place.
• cli/src/commands/charter/audit.rs wired to the i18n resolver. Until then, the subcommand hardcoded the dist/.straymark/audit-prompts/audit-prompt.md path without consulting the adopter's language field in .straymark/config.yml. After the PR, it reads the project config and resolves the localized path — if the adopter has language: es, they get the Spanish overlay; if they have language: zh-CN, it falls back to EN canonical (there's no zh-CN translation of the audit-prompt yet); if they have language: en or don't specify, they get the canonical.

Three new tests cover the three paths. Zero functional change for English users (who are the majority). For Spanish users, an improvement: before, they received the prompt in Spanish by accident (because the canonical path pointed to ES); now they receive it in Spanish by convention (because the resolver decides it).

5. The lateral move​

While doing the language switch, the operator took the chance to extract a specificity that had carried over from the Sentinel origin. The §Step 5 section of the prompt — about severity calibration of findings — cited a literal case from the April experiment: "Etapa 12 Pub/Sub stub vs gochannel". A perfectly didactic example, but specific to a Sentinel component no other adopter would recognize.

The English translation replaced that example with a vendor-neutral formulation: "declared deferral, not a defect — a charter that introduces a thin adapter slated for replacement in a future Charter". The idea — a stub that is declared debt, not a defect — is preserved. What goes is the component's name.

The move is small but coherent with the blog's principle. When there's an opportunity to detach the framework from a specific adopter without losing pedagogy, take it. It's the same generalization operation Post 3 documented for the six Plans and Post 4 for the first Charter: empirical content stays in Sentinel; what enters the framework is the vendor-neutral abstraction. The audit-prompt, almost a year later, finally finished honoring that rule.

6. Closing​

Three short claims:

1. In a framework with a convention, a single file violating it is a sign of legacy, not of design. The audit-prompt was the outlier because it was born earlier, and nobody migrated it when the other artifacts aligned. Outliers accumulate provenance.

2. New tools produce visibility. The ES → EN switch wasn't decided by systematic repo review. It was decided because a new TUI put all the templates on the same screen and the inconsistency became obvious. The same applies to grep, to aggregate views, to status outputs: every new surface exposes what was misaligned.

3. Small rebrands are opportunities to de-identify. When you touch a file to change the language, the marginal cost of also extracting the adopter specificity left from origin is zero. The blog has recorded this pattern before (Plan → Charter, DevTrail → StrayMark); this is the miniature version. The framework becomes more vendor-neutral one file at a time.

Next, in the following post, an episode that already brushed Post 1 but deserves its own treatment: "Manual discipline before the pattern" (H-11). How Sentinel handled CHARTER-18 before the Pattern 1 of chain evolution existed — the empirical learning that Post 1 later named as meta-pattern.

Anchors: PR #142. Releases: fw-4.13.3 / cli-3.12.3. Key commit: a8a1ac5. Files: dist/.straymark/audit-prompts/audit-prompt.md (EN canonical) + dist/.straymark/audit-prompts/i18n/es/audit-prompt.md (overlay). CLI: cli/src/commands/charter/audit.rs wired to the i18n resolver.

This document was produced with assistance from generative AI tools (Claude 4.7); all responsibility for the content rests with the human author.

1. Zero TDEs across thirteen Charters​

Issue #128 opens with a disquieting asymmetry:

"Sentinel adopter (primary, fw-4.12.0) created zero TDEs across 13 closed Charters despite ≥7 instances of transversal debt routed through parallel mechanisms."

Thirteen closed Charters. At least seven recognizable pieces of transversal debt — inherited from prior Charters, crossing modules, persisting between sessions. Zero TDEs. If the operator had been discussing quotas, the data wouldn't mean anything. But the operator was me and the adopter was the same project that empirically validates the framework. If Sentinel — the repo where the full framework was being used most aggressively — wasn't producing TDEs even once in thirteen tries, something was broken.

What was broken wasn't the debt, which was being captured by other channels (R<N> (new, not in Charter) inside the AILOGs, entries in follow-ups-backlog.md). What was broken was that no criterion in the framework said "this specific piece deserves TDE, not R". The document type existed. The operational trigger didn't.

This post covers the 11-12 May 2026 episode: how the missing trigger was diagnosed, how it was closed with four canonical criteria (fw-4.13.0), and how the PR chain that fixed the problem left behind, in passing, an operational lesson about stacked-PRs that ended up codified in the project's CLAUDE.md. It's the first blog episode where the framework fixes two different things in the same arc, and where the second is accidental.

2. The type existed. The trigger didn't.​

TDE — Technical Debt Entry — has existed in the framework since the January initial commit (Post 2 recorded it: it was on the list of eight original types in the v1.0.0 README). The template was there. The taxonomy field was there. The 06-evolution/technical-debt/ folder was there.

What wasn't there was a sentence, somewhere in the canonical apparatus, that said "create a TDE now". Issue #128 put it without softening:

"Reading the adopter-facing docs (AGENT-RULES.md, DOCUMENTATION-POLICY.md, QUICK-REFERENCE.md, CLAUDE.md autonomous rules), there is no clear trigger that says 'create a TDE now'. The trigger language exists for AILOG (creation freely), AIDEC (when alternatives considered), ETH (high risk PII), ADR (architectural decisions), but TDE is just listed as 'agent can Identify'."

"Agent can identify." Identify if you feel like it. An agent entering the repo reads that line, shrugs, and moves on to AILOG and AIDEC, which do tell it when. The defect is the same one from Issue #113 (Post 5): the artifact technically exists, but the canonical surface doesn't give the agent the verb needed to activate it. What makes this case different from #113 is the consequence. For Charters, not seeing them meant not using the new flow. For TDE, not seeing them meant something worse: transversal debt was being captured — but fragmented, with no consolidated view, no prioritization across artifacts, no assigned_to or priority field for a human reviewer to order it.

The Issue cites that consequence with embarrassing detail, because it enumerates everything that wasn't happening:

"No queryable 'all open technical debts' view at the document level. No impact × effort prioritization matrix per item. No assigned_to / priority fields surfaced to the human reviewer. Architectural debt that legitimately spans multiple charters (e.g., scope authorization gap heritage across modules) gets fragmented into per-charter R-numbers instead of consolidated into a single TDE."

Thirteen Charters' worth of debt fragmented into per-Charter R<N>. From the repo operator's point of view: no consolidated list, none explicitly named as inherited, no piece of debt prioritizable at project level. Everything was in the repo. None of it was in the place the repo builds for the humans coming in from outside to read it.

3. Four criteria for a piece of debt​

PR #129 (fw-4.13.0, merged 11 May at 19:38 UTC, exactly thirteen hours after the Issue was opened) closed the gap with a new section in AGENT-RULES.md §3 titled "TDE vs `R (new, not in Charter)". The four criteria, literal:

The operational rule: if a piece of debt satisfies at least one of the four criteria, it's a TDE. If it satisfies none, it stays as R<N> inside the Charter where it appeared.

The four each have their logic. Heritage (1) captures debt that persists across time, which a reviewer would want grouped by origin, not by Charter. Multi-module or multi-Charter (2) captures debt that lives between artifacts, not inside one. Dedicated Charter (3) acknowledges that some pieces of debt are large enough to deserve their own cycle and therefore don't fit as risk declared ex-ante. Human prioritization (4) acknowledges the autonomy limit: there are decisions the agent can flag but can't resolve, and those decisions deserve a document where a human can queue up.

The same PR added a new field to the TDE template's frontmatter — promoted_from_followup: FU-NNN | null — and a section in FOLLOW-UPS-BACKLOG-PATTERN.md documenting how to promote a follow-ups entry to a TDE. The promotion has two shapes, both recorded literally: promotion of an existing entry (a follow-up that had been on the list for weeks matures into a TDE) and retropromotion at creation (when the TDE is created, it's acknowledged it originated in a prior follow-up and noted). The frontmatter field closes the trail: any TDE can now point back to the follow-up that originated it, if one existed.

4. Three TDEs in Sentinel — the empirical loop closed​

Issue #128 didn't close by argument; it closed by evidence. The same day, Sentinel — the same adopter that had been through thirteen Charters without a single TDE — created three:

• A TDE for a RequireScope architectural gap, heritage crossing modules. Criteria 1 + 2 + 3.
• A TDE about missing test coverage in the HTTP layer, debt persisting across feature Charters. Criteria 1 + 4.
• A TDE for review of legacy AILOGs predating Charter format v3, a piece needing its own cycle. Criteria 1 + 3.

Three documents in hours. The speed matters less than the fact that each one applied at least one of the criteria and none landed in gray territory. The criteria worked as an unambiguous heuristic — the operator didn't have to negotiate with himself about whether a piece was TDE or R<N>. The empirical loop the Issue had opened in the morning closed with three documents that same afternoon.

PR #136 (fw-4.13.1, merged the next day) refined two criteria based on that same experience. Heritage (1) was explicitly split into strict heritage vs pattern propagation because one of Sentinel's three TDEs showed the second case clearly: the debt wasn't literally inherited; it was the same pattern reappearing when the same procedure was followed. Multi-module (2) was reformulated as "multiple modules or Charter execution boundaries" because another of the three TDEs was governance-trail (crossing session boundaries without crossing code modules). The criteria grew one single refinement-pass after being exercised on three real cases. The framework validated principle #12 again: no schema crystallizes without a second domain.

5. The stacked-PR lesson​

This is where the post deliberately veers off. The PR chain #129 → #131 → #133 that closed Issue #128 left behind an adjacent operational lesson — not about TDE but about how not to stack branches. The lesson is documented literally in CLAUDE.md (lines 181-220) of the public repo under the section "Stacked PRs — avoid, or use merge commits".

How it broke​

PR #131 (cli-3.12.1, validator fix that was rejecting status: identified on TDEs) was opened with base = #129 because #131 needed #129's code to compile its tests. Then #129 was merged to main with squash. The current CLAUDE.md describes it with a precision worth quoting in full:

"When you stack PR B on top of PR A's branch (base of B is A's head, not main), and A is squash-merged to main, B's content gets stranded:

— The squash merge of A creates a new commit on main with content equivalent to A but a different SHA than A's original commits.

— B's branch still points at A's original commits, which now have no descendant on main.

— When B is merged, GitHub merges it into A's branch (its declared base), not main. The 'merge to main' never happens — even though GitHub UI shows B as MERGED."

The practical result in the #129/#131 cycle: GitHub's UI showed #131 as MERGED, the validator tests were ostensibly on main, but the content never arrived. PR #133 was the procedural sync that had to be opened later to carry the content to its destination. Time lost in diagnosis: about three hours. Time of the recovery operation once understood: five minutes.

How to prevent it​

The CLAUDE.md documents two strategies, one conservative and one pragmatic:

"1. Sequential, not stacked. Wait for PR A to merge to main, then rebase B onto main and open B as a standalone PR with base = main. Slower but bulletproof.

2. If you must stack, use merge commits (not squash) for the parent. A merge commit preserves shared history, so subsequent merges of stacked PRs into main resolve cleanly. Pay the cost of a noisier git log for the stacked-PR safety."

Sentinel and StrayMark default to squash. That choice is good for keeping git log clean, one decision per feature, one commit per PR. But it costs exactly this: incompatibility with stacked-PRs. The rule CLAUDE.md now codifies is honest: either don't stack, or pay in commit history to be able to stack. There's no third option that doesn't break something.

How to recover (if it already happened)​

The recovery section of the CLAUDE.md is the most operational piece of the document. Four steps:

"1. git checkout -b chore/sync-<B-content>-to-main main

2. git cherry-pick <B's merge commit SHA> — should be clean because B touches files outside A's conflict zone (which is why it could be stacked in the first place).

3. Push, open PR with base = main, head = chore/sync-.... Cherry-pick produces a fresh commit on top of main, so no conflicts.

4. The branch protection may require --admin merge if the content was already reviewed in B (the original PR) — sync PRs are purely procedural."

The last step is editorially important: explicit note that an --admin merge is authorized only for procedural PRs like this — where the content was already reviewed in the original PR. It's the only exception to the "content goes through human review" rule of the project.

The reason it's worth registering the lesson as a sub-section of the TDE post — and not as a separate post — is that they share a trait: both are pieces of transversal process debt the framework now explicitly names. One is code debt (TDE as a new type); the other is workflow debt (stacked-PR as a documented anti-pattern). They share an origin: real operational friction was what triggered the document.

6. What the episode left in the repo​

Four PRs in under twenty-four hours, three recorded lessons:

• PR #129 (fw-4.13.0, 11 May 19:38 UTC) — TDE activation trigger. Four criteria + new section in AGENT-RULES.md §3 + FU → TDE path.
• PR #131 (cli-3.12.1, 11 May 19:39 UTC) — validator accepts status: identified on TDEs. Without the fix, the first TDE created under the new trigger failed validation.
• PR #134 (12 May 04:54 UTC) — the stacked-PR lesson documented in CLAUDE.md. It didn't change framework code; it changed the repo's operational rules.
• PR #136 (fw-4.13.1, 12 May 04:54 UTC) — TDE trigger refinements based on Sentinel's three real cases.

What I most want to flag about the chronology: CLAUDE.md (PR #134) was updated in the same arc that closed Issue #128. The stacked-PR lesson didn't wait to be forgotten. If the framework's discipline is "every significant change leaves a documented trace", that applies to operational friction too, not only to design. The framework exists, in part, so expensive learnings don't evaporate.

7. Closing​

What I took from the process, in four claims:

1. A document type without a trigger is an invisible type. Same as in Issue #113, what the agent doesn't see on entering the repo doesn't exist for it. TDE existed technically from January, but only started being used when the four criteria appeared in AGENT-RULES.md §3. Structure without an activating verb is decoration.

2. Transversal debt deserves its own type. Fragmenting debt into per-Charter R<N> destroys the most important property of a governance system: the consolidated view. Four criteria, any one is enough, holds the line between this is risk of the Charter and this is debt of the project.

3. Operational learnings get documented too. PR #134 updated the project's CLAUDE.md the same day the lesson surfaced. It isn't archival paranoia; it's the same rule applied to process: if the friction cost you three hours today, write the lesson today.

4. The framework grows from features as well as from anti-patterns. This episode left behind a new type (TDE as operational entity) and a documented anti-pattern (stacked-PRs incompatible with squash). Both are framework material, even if only one shows up as a version bump.

Next, in the following post, a brief but structural episode: "The Spanish audit-prompt was the outlier" (H-10). An i18n convention detail that revealed which language had been the canonical one — and why fixing it changed, without meaning to, how the framework thinks about translation.

Anchors: Issue #128. PRs #129 · #131 · #134 · #136. Releases: fw-4.13.0 / cli-3.12.1 / fw-4.13.1. Stacked-PR lesson codified in CLAUDE.md lines 181-220 of the repo.

This document was produced with assistance from generative AI tools (Claude 4.7); all responsibility for the content rests with the human author.

1. Having schemas is not the same as validating against schemas​

straymark validate had existed since 25 March 2026 — PR #27, part of the first arc of CLI Phase 1. What it did back then was small: verify that documents in .straymark/ had valid Markdown syntax, parseable frontmatter, and the minimum fields of the correct type. It was useful. It was not enforcement.

What changed on 11 May 2026, with the fw-4.6.0 / cli-3.7.0 release, was something else: Phase 2 of the CLI roadmap closed a full arc of seven PRs (#73 to #79) and consolidated them into one (#80). The CHANGELOG says it without metaphor:

"The first feature-bearing release since the repositioning... Phase 2 of Propuesta/devtrail-cli-roadmap.md lands as 7 bisect-safe PRs (#73–#79), grouped here for reviewers. The release closes the empirical loop the Sentinel experiment opened: telemetry at Charter close, drift detection at Charter close, and a canonical approval signal for review_required: true documents."

What matters for this post isn't the seven PRs as individual milestones; it's the three that touched the validate command and the schemas. What in March was "I check that this looks like a document" in May became "I check that this satisfies the canonical schema of the type, in the mode you ask for, with concrete operational consequences".

2. From artisanal bash to a command flag​

One of the most visible pieces of the change is small: the --staged flag.

Until Phase 2, the recommended pattern for adopters to validate their documents before a commit was a bash script called pre-commit-docs.sh. It lived in dist/.straymark/scripts/ and had 464 lines. It did the reasonable thing: read git diff --cached --name-only, filter files in .straymark/, parse their frontmatter with awk, check fields. It worked. And it was 464 lines of bash each adopter had to trust executed the right thing, in the right version, with the right YAML parser.

A PR on 28 March (commit d9ea874) replaced the 464 lines with a flag:

straymark validate --staged

Reads staged files the same, filters by .straymark/ the same, validates the same. The difference: today all of that lives in Rust inside the binary, not in bash on disk. The adopter doesn't have to maintain the script; the script can't diverge between versions; the behavior is the same on Linux, macOS and Windows. The framework stopped asking the adopter to trust a loose script and started giving them a command with the implicit promise of a versioned binary.

It's the same pattern Post 6 documented for archival discipline (preserve git history instead of rewriting) or Post 4 documented with decision A1 (orchestrate without invoking APIs): move from "the operator does X manually with risk of divergence" to "the framework canonizes X in a declarative command". --staged isn't an exotic feature; it's manual debt swept away.

3. The three v0 schemas​

Phase 2 also consolidated the three schemas that live in dist/.straymark/schemas/:

Each schema carries a $comment field in its root. The one in charter.schema.v0.json says literally:

"EXPERIMENTAL v0. Crystallized from Sentinel /plan-audit (6 cycles, format v1 → v2 → v3). Will not stabilize to v1.0 until validated in a second domain (frontend, ML pipeline, or infra-as-code)."

The one in charter-telemetry.schema.v0.json, similar:

"EXPERIMENTAL v0. Derived from 5 PLAN-NN.telemetry.yaml files in Sentinel (one project, Go backend) — same N=1-domain caveat as charter.schema.v0.json. Will not stabilize to v1.0 until validated in a second domain."

The one in audit-output.schema.v0.json, idem:

"EXPERIMENTAL v0.x. Phase 3 of the CLI roadmap. Crystallized from the dual-audit pattern validated empirically in Sentinel."

All three share an explicit declaration: no crystallizes without a second domain. It's framework principle #12, not as a separate paragraph in governance documentation, but inside the JSON Schema itself, in a field any standard validator reads and any schema-explorer tool renders to the user. The framework doesn't hide the provisional nature of its schemas; it puts it where nobody can miss it.

This matters more than it seems. The usual practice in schema ecosystems (JSON Schema, OpenAPI, Avro) is to publish v1 and then bump as things change. Marking v0 with a $comment saying "this is experimental until a second domain validates it" is admitting, from the start, that the first crystallization isn't definitive. The schema itself is honest.

4. Three modes of the command​

straymark validate is no longer a command with one flow. After Phase 2 it has three operational modes, each coupled to a moment in the life cycle:

• all mode (default) — straymark validate with no flags. Walks .straymark/ recursively, parses each .md file, tries to resolve its type (AILOG, AIDEC, ADR, ETH, REQ, TES, INC, TDE, MCARD, SBOM, SEC, DPIA, Charter), applies the corresponding schema, and reports per-file violations. This is the full audit mode. Useful for CI, useful for reviewing a fresh repo, useful when an adopter wants to measure how much formal debt accumulated.

• --staged mode — straymark validate --staged. The one that replaced bash. Only validates files git diff --cached --name-only reports as staged within .straymark/. Its natural home is .git/hooks/pre-commit, and since fw-4.6.0 there's a straymark init --hooks that installs it automatically. This is the operational gate mode — the one that prevents broken documents from reaching main.

• --check-pending-reviews mode — straymark validate --check-pending-reviews. The subtlest of the three, and the one that justifies more paragraphs.

Until Phase 2, a document the agent marked review_required: true in the frontmatter (an AIDEC with low confidence, an AILOG with high risk, etc.) sat waiting for human approval. But there was no canonical way to signal that approval. The operator read the document, mentally approved it, moved on. No structural trace of the approval. This was exactly Issue #67.

--check-pending-reviews closes that hole. The command walks all documents with review_required: true and lists them with their confidence, their risk_level, their author (human or agent), and their date. Approval is a commit that changes review_required: true → review_required: false with human co-authorship in the commit message — and validate --check-pending-reviews stops listing the document. Approval is a canonical signal, not a verbal agreement with oneself.

This is the piece that closes the agent's loop. The framework lets the agent create documents without prior human approval (Post 1, property #2: "cultural permission without blocking control"); but marks them for review when appropriate; and now has a command to list what's pending, with no escape hatch. No audit document gets lost silently.

5. Phase 2 closes the empirical loop​

The full CHANGELOG sentence is worth keeping because it condenses what the release means:

"The release closes the empirical loop the Sentinel experiment opened: telemetry at Charter close, drift detection at Charter close, and a canonical approval signal for review_required: true documents (resolving issue #67)."

Three pieces that close an arc that started with the six-Plan experiment (Post 3):

1. Telemetry at Charter close — the YAML block Sentinel filled by hand during the experiment became the validatable charter-telemetry.schema.v0.json.
2. Drift detection at Charter close — the 145-line bash script (check-plan-drift.sh) became the straymark charter drift subcommand, integrated into the validate flow.
3. Canonical approval signal — what the operator did mentally became a command with structural consequences: --check-pending-reviews.

It's the pattern the blog has seen recur: every time the framework crystallizes a practice Sentinel was doing manually, it does it after empirically validating that the practice works. The difference this time is that the command that verifies the crystallization is part of the package. Before Phase 2, Sentinel had templates, declared schemas, and the implicit promise that documents followed the schemas. After Phase 2, there is a command that checks. It isn't a capability change; it's a guarantee change.

6. Principle #12, turned into a schema​

The philosophical piece of the post — and the one I most want on record — is this:

The $comment of the three v0 schemas encodes a principle the framework had been declaring in prose since April. Post 4 named it like this: "schema marked v0 on purpose, not v1, because the framework's principle #12 says no schema crystallizes without a second domain validating it". Post 7 applied it to the TDE design: "the framework validated principle #12 again: no schema crystallizes without a second domain". Post 10 applied it to Pattern 1 and Pattern 2: "the document says so without shortcuts: the pattern is empirically validated in Sentinel. Wait for the second domain before crystallizing it higher".

Phase 2 does something different. It doesn't declare the principle; it writes it inside the schema itself, in a place any schema consumer is going to read. The $comment isn't marketing; it's protocol. Any JSON Schema 2020-12 validator exposes it; any IDE that parses the schema shows it. It's the first time the framework formalizes the provisional nature of its formalizations.

If I had to sum it up in one sentence: the framework validates what it has, knowing that what it has is provisional, and puts that in writing in the place where validation happens. Validating the provisional is discipline. Crystallizing prematurely and validating the crystallized is theology.

7. Closing​

What I took from the process, in four claims:

1. Having schemas is not the same as validating against schemas. The first step is declarative; the second is operational. Phase 2 did the second, not the first. The difference between the two framework modes — "I have the promise" vs. "I have the command that checks it" — determines whether the adopter can trust what's declared.

2. The "artisanal bash → command flag" pattern is structural. --staged isn't an isolated feature. It's Phase 2's version of the same pattern Post 4 documented for the external audit cycle, that Post 10 documented for the chain-evolution CLI helpers: verbose imperative → readable declarative → versioned. Every time the framework sweeps a bash script for a flag, it raises a layer of guarantees.

3. --check-pending-reviews closes the agent's loop. What Post 1 named as cultural permission without pre-approval completes here: the agent can create, but documents marked for review don't get lost — the command lists them until a human approves them with an explicit commit. Without that signal, the cultural permission of Post 1 would be negligence.

4. Declared provisionality > premature formalization. The $comment of v0 schemas makes principle #12 protocol, not doctrine. Any tool that consumes the schema knows the formalization is provisional. It's the strongest structural honesty a young framework can have: validate what you have, without pretending what you have is definitive.

Anchors: PR #27 — original validate version (March 2026). Phase 2: PRs #73 to #79 + PR #80 — fw-4.6.0 / cli-3.7.0 (merged 2026-05-11). Schemas: dist/.straymark/schemas/{charter,charter-telemetry,audit-output}.schema.v0.json. Issue #67 — origin of --check-pending-reviews.

This document was produced with assistance from generative AI tools (Claude 4.7); all responsibility for the content rests with the human author.

1. Six hours not to see it, five minutes to see it​

Issue #113 opens with one of those sentences that, read back months later, sounds obvious and at the same time cost a lot to reach:

"Time to detect: ~6 hours of session work; never autonomously surfaced. Time to resolve once user prompted: ~5 minutes."

Six hours working with a capable, attentive agent, with the framework's whole canonical onboarding apparatus loaded — STRAYMARK.md, the project constitution, the CLAUDE.md checklist, the /straymark-* skills available, /straymark-status run at the start — and not once, over six hours, did the agent suggest using a Charter. When I asked for it directly, the flow was incorporated in five minutes. The asymmetry isn't about capability. It's about visibility.

This post covers a short, specific episode: Issue #113, opened on 7 May 2026, three days after Charters crystallized as a first-class entity in the framework (fw-4.4.0, 2 May). It's the natural counterweight to this blog's first post. That post named a property that appeared when everything was in place. This post documents what happens when a structural piece exists but isn't on the surface the agent reads first.

2. The accidental experiment​

The setup wasn't designed as an experiment. It was a real project: a greenfield in Rust, CLI+TUI suite, on its first v0.1 version. The agent was Claude Opus 4.7 with a 1M-token window, enough to keep the whole repo in context without paging. The flow was the canonical SpecKit one: /speckit-specify, /speckit-plan, /speckit-tasks, and between tasks and implement the idea of splitting into Charters should have surfaced — in theory.

The Issue formulates it with almost cold precision:

"A capable, attentive agent following the canonical project onboarding (DEVTRAIL.md, the project constitution, CLAUDE.md checklist, available /devtrail-* skills, /devtrail-status) did not autonomously identify Charters as a workflow concept during plan/tasks generation, even though the project clearly fit their use case (multi-session implementation, multi-phase tasks, audit value)."

(The Issue still uses DEVTRAIL.md because, given the chronology, the rebrand to StrayMark was being merged almost in parallel. The mixed nomenclature is calendar residue, not oversight.)

The project met each condition where a Charter is the right unit: multi-session implementation, multiple phases, audit value. The agent did everything right — read the constitution, ran status, identified available skills, generated a reasonable SpecKit plan — and never connected to Charters. As if the concept didn't exist. To the agent, in its model of the repo, it didn't.

The most uncomfortable thing about the Issue, in hindsight, is that the agent didn't fail from incapacity. It failed because the framework, without meaning to, had built a map where Charters weren't marked.

3. Nine gaps converging on one​

When the operator (me) opened the Issue and sat down to audit why it had happened, the problem wasn't one thing. It was nine. And all of them were versions of the same defect:

Nine failures and one single defect: the Charter existed as a technical artifact (valid schema, working command, template ported from Sentinel), but wasn't named in any of the places where the agent builds its mental model of the project on entry.

The agent reads STRAYMARK.md and the constitution to understand what the project is about. If Charter doesn't appear, it isn't there. The agent reviews which skills are available to use. If there's no /straymark-charter-new, it isn't there. The agent runs /straymark-status to understand what kinds of files live in the repo. If the output doesn't mention Charters, they aren't there. Each surface the agent passes through on onboarding repeats the same silence. And the sum of silences convinces the agent the concept isn't part of this project.

4. Why this episode matters beyond the Issue​

It's worth pausing here, because this is exactly the episode the fw-4.17.0 meta-pattern — the pattern of emergent observation — needed to have happened first in order to be formulated at all.

A week after #113, in EMERGENT-OBSERVATION-DESIGN.md, the framework named two properties whose composition produces an agent surfacing things nobody asked it to surface: formal links between artifacts (originating_charter, originating_ailog, originating_spec in frontmatter), and cultural permission to flag dissonances between sources. Those two properties, composed, produce the agent reading the AILOG, counting the R<N>(new, not in Charter) entries, and flagging the delta without being asked.

But there's a precondition that formulation takes for granted: that the agent sees the Charters on entering the repo. If the Charters aren't on the visible surface, no formal link between artifacts can compose into emergent observation — because one of the composition's terms doesn't exist for the agent.

Issue #113 is the episode that documented that precondition from the reverse. Fw-4.17.0 named the pattern when it was present; fw-4.12.0 (five days earlier) closed the gap that prevented it from being present at all. Without Issue #113 and its correction, the meta-pattern wouldn't have anywhere to stand. The framework doesn't surface what it can't see, and it can't see what the surface doesn't name.

5. The response: multiplying surfaces​

PR #122 (fw-4.12.0, 9 May) closed the nine gaps with a single operational strategy: name Charter in every place where the agent builds its model of the project. The PR's numbers are honest: +1211 lines, −92 lines, 36 files modified, almost entirely documentation and templates. There was no code refactor. There was a redistribution of visibility.

Main changes, grouped:

• In the canonical document (STRAYMARK.md): a new section dedicated to Charter as a concept (§15), plus rows in the §6/9/10/11/13 tables that listed document types without Charter.
• In agent directives (CLAUDE.md, GEMINI.md, copilot-instructions.md): an explicit trigger teaching the agent when to suggest a Charter, not only when to create one if asked.
• In skills: new /straymark-charter-new (Claude, Gemini, agnostic versions). /straymark-status updated to list active Charters.
• In the CLI: a Charters block added to straymark status output, so the agent running the command sees it among the initial signals.
• In templates: moved to a dedicated subdirectory dist/.straymark/templates/charter/, no longer mixed with other templates.
• New document: SPECKIT-CHARTER-BRIDGE.md (171 lines, EN/ES/zh-CN). Makes the bridge between SpecKit's plan.md and StrayMark's Charter explicit — the four criteria for a SpecKit feature to produce one or more Charters, the three cases where it doesn't apply, the four granularity heuristics, the originating_spec ↔ originating_charter ↔ originating_ailog frontmatter linkage.

The epilogue of SPECKIT-CHARTER-BRIDGE.md records the case that originated the entire change without metaphor:

"Cited the empirical context (issue #113): Greenfield Rust CLI/TUI suite, Claude Opus 4.7 onboarding via canonical entry points. Charters were eventually adopted (2 Charters: foundation + MVP) only after explicit user prompt — confirming the gap was systemic, not session-specific. This document removes the gap."

The gap was systemic, not session-specific. That sentence is the Issue's operational lesson. It wasn't a distracted agent one day; it was the framework that didn't speak to the agent about Charters in any of the places the agent was looking.

6. What I learned about structural visibility​

The lesson, written in prose and not in a table:

Creating an artifact in a framework is not the same as making it visible to the agents that work in repos of that framework. They're two steps. The first — schema, command, template, examples — is the visible step: it shows up in the CHANGELOG, ships in the release, appears in git log. The second — anchoring the artifact on every surface where the agent enters the repo — is invisible: nothing about the second step appears as a feature in itself; it's cross-references, lines in checklists, items in outputs, sections in docs. But the second step is what decides whether the first one exists for the agent.

The framework governs agents that read the repo from outside the session where the artifact was created. Each agent entering the repo builds its mental model from scratch, reading the canonical documents, the available skills, the status outputs. If the artifact isn't named there, it doesn't exist in the model. And a model without the artifact doesn't propose using it, doesn't audit its absence, doesn't flag related dissonances. The agent's technical capability is irrelevant if the repo's surface doesn't give it the right noun on entry.

That's what I now call, internally, structural visibility. It isn't a property of the agent. It's a property of the repo, and by extension, a responsibility of the framework: every time it crystallizes a new concept, it has to multiply the surfaces where that concept is named. One single surface — the schema, the command, the template — isn't enough. There are nine, minimum, and they're the nine in Issue #113.

7. Closing​

What I took from the process, in four claims:

1. Existing as an artifact isn't the same as being visible to the agent. Charters had schema, command, template, examples — and were still invisible. The difference between the two states is the nine surfaces of Issue #113.

2. Six hours vs. five minutes. A capable agent can spend hours not detecting what, once named, takes minutes to integrate. The asymmetry doesn't diagnose the agent; it diagnoses the repo.

3. Structural visibility is the framework's responsibility. When it crystallizes a concept, it doesn't end with the command that creates it. It ends when the concept is named on every surface where the agent builds its model of the repo: canonical document, directive, skill, status, template, bridge to other frameworks.

4. Without structural visibility there is no emergent observation. The properties that later made it possible for an agent to surface dissonances between sources — formal links + cultural permission — need, as a precondition, the artifacts to be visible from the first moment of onboarding. Issue #113 documents what happens when that precondition is missing.

Next, in the following post: an episode adjacent to this one — the rebranding to StrayMark (H-08). Issue #113 was resolved in the same temporal arc as the rename from DevTrail to StrayMark, and they share something worth naming — the responsibility of a framework to declare its identity with clarity, both to its agents and to its adopters.

Anchors: Issue #113 (opened 2026-05-07). PR #122 — fw-4.12.0 (merged 2026-05-09). Document generated by the PR: SPECKIT-CHARTER-BRIDGE.md.

This document was produced with assistance from generative AI tools (Claude 4.7); all responsibility for the content rests with the human author.

1. The rename that wasn't looking for the concept​

ADR 2026-05-08-001 opens with a sentence that, for anyone who read Post 2 of this blog, sounds out of place:

"The decision is motivated by legal certainty over the trademark rather than by product strategy or user feedback."

The three renames of January (Chronicle → Monimen → DevTrail) were rushed searches for the concept. Each one ratified a distinct intuition about what the product was. None had an ADR; commit messages were all the documentary justification that existed.

The fourth rename, the May one, is of a different nature. It doesn't come from looking for the concept. It comes from a trademark conflict investigation — commissioned via a Claude.ai web session in early May — which surfaced "legal uncertainty about trademark ownership as the project gained adopters." In January the project had zero adopters and renames could be improvised. In May the project had one adopter (Sentinel), 286 crate downloads, two open issues, and a public manifesto promising structured governance. The threshold for improvising another rebrand had already been crossed.

This post covers three things: the disciplined decision made on 8 May, the operational arc of five PRs in forty-three minutes the following day, and the residuals that surfaced two days later. And, underneath all that, a subtler distinction: when a rebrand is purely surface, and when — without quite meaning to — it also changes identity.

2. The first disciplined rename​

What's new on 8 May is the form. This time there was:

• A prior investigation. It wasn't decide-rebrand-then-justify; first a conflict was detected, then the decision followed from it.
• A public ADR. Three alternatives explicitly considered (keep "DevTrail" and accept the trademark risk; hybrid branding with legacy + new in parallel; reset to v0.1.0 under StrayMark as "new project"). All three dismissed with literal argument.
• A temporal calculation. The ADR itself frames the cost this way: "The rename window narrows over time — every new adopter increases the cost of changing later... The legal risk dominates. Acting now, with one self-owned adopter, is materially cheaper than acting later under pressure."

The reason the calculation matters is structural. If the rebrand had waited two more months — until the second adopter showed up, or the third — the migration cost would have multiplied. Each adopter repo would have had to run mv .devtrail .straymark, update its CLAUDE.md/AGENT.md, regenerate its pipelines. With a single adopter (the operator himself), the cost was contained and reversible. What the ADR calls "acting now is materially cheaper" is exactly that: the rebrand was an exercise in minimizing future debt, not a marketing decision.

There's an unintended echo with Post 2. That one closed with the line "there probably won't be another rebranding." This post, written from May, knows there was. The difference between promising and ratifying is that the fourth rename, unlike the first three, was forced by external circumstances no operator can foresee — a trademark conflict — and was faced with the discipline January didn't have.

3. In scope, out of scope — the ADR's masterpiece​

The ADR section that shapes the rest of this post is the one that distinguishes what gets renamed from what gets preserved. Cited literally:

"In scope (the 'live state' of the project): all identifiers in source code, Cargo metadata, source-of-truth path, 30 skill/workflow files, public documentation, CI workflows, GitHub repository name."

"Out of scope (immutable history, preserved verbatim): all commits, commit messages, and git history; all tags published before this ADR; all release titles and bodies of releases published before; all prior CHANGELOG.md sections."

That distinction is the rebrand's armature. The live — paths, commands, URLs, release assets, README — is renamed in one stroke. The historic — git log, devtrail-cli@3.10.0 tags, prior CHANGELOG sections, closed issues — is preserved literally. The project doesn't rewrite itself backwards.

It's the same archival discipline that Post 3 documented for the Plan → Charter rename, now applied to the framework-wide operational rebrand. I lay it out as a table because it helps to see it:

Version continuity is the most visible proof. The next release wasn't 0.1.0 or 1.0.0; it was fw-4.11.0 and cli-3.11.0. The numbering declares, without metaphor, that the project is the same project.

4. Five PRs, forty-three minutes​

On 9 May, between 06:05 and 06:48 UTC, five PRs merged in a chain:

The order is deliberate and goes from outside in: first the law (ADR), then internal code, then what adopters see (docs), then distribution (CI), finally the consummated fact (release). This sequence has an archival reading: when someone six months out reviews git log chronologically, they'll first see the decision, then the implementation. Causality lives in the repo.

It's worth naming a piece of the arc that broke the original plan. The ADR had contemplated nine distinct PRs (one per logical layer). In practice, the CLI tests depended on hardcoded paths — include_str!("../../dist/.devtrail/...") — and breaking the path without updating the tests at the same time left CI red. The plan compacted to five because the layers were technically coupled, not because the conceptual discipline failed. The PR #115 note records it without softening: "The consolidation was forced by tight coupling: tests use include_str! on dist/.devtrail/ paths."

Forty-three minutes for a rebrand that touched around two hundred sixty files. The pace is only possible because the ADR had closed every decision before code was touched. Framework principle #6 — "when the proposal is well-written, implementation is execution, not design" — found another validation case, similar to the external audit cycle one in Post 4.

5. Why StrayMark does change more than the name​

Up to here the ADR is clear: the rebrand is on the surface, the conceptual identity is preserved. But there's a nuance worth naming.

PR #120 — merged hours after the main arc, the same 9 May — added the "Why StrayMark?" section to the README. It isn't code; it's a manifesto. And it says things no prior document of the project had articulated:

"Code is just the fossil trace of a mental battle. Real engineering happens in the chaos of decisions, calculated risks, and the paths you chose not to take. Traditionally, all that human trail is discarded as stray marks (accidental smudges) in a project's history. At Strange Days Tech, we believe those marks are the signal, not the noise."

The name choice, viewed from the manifesto, isn't arbitrary. The stray marks — the erratic traces, the accidental tracks most projects discard — are exactly what the framework drags to the foreground: AIDECs, AILOGs, TDEs, Charters. What in any conventional project would be discardable noise is, in this project, the raw material of audit. The name embodies the product's thesis in a way DevTrail never did. DevTrail was a neutral path; StrayMark is a claim.

The manifesto closes with three lines that later became what an editor would call an operational tagline:

"Capture the noise. Weave the signal. Humanize the machine."

Here's the small interesting tension of the rebrand. The ADR says only the surface changed; the manifesto from the same day suggests the identity was also articulated — perhaps for the first time with clarity. It's not a contradiction: the moment of the operational rebrand was used to write down what was already in the project but hadn't been named yet. The identity didn't change. It became legible.

6. What was left undone​

Even with a public ADR and a disciplined arc, "complete" remains an approximation.

Two days after the rebrand, while Sentinel was preparing its next external audit cycle, the agent surfaced three classes of residuals. The chronology — captured honestly in CHANGELOG.md as inline errata — is worth keeping visible:

• PR #137 (11 May, 22:55) — Orphaned skill directories. The rebrand rewrote the name: field inside each SKILL.md, but didn't rename the directories of the three platforms (.gemini/skills/devtrail-*, .claude/skills/devtrail-*, .agent/workflows/devtrail-*.md). Thirty orphaned artifacts: new name, old path. Gemini CLI reported it as ten conflict warnings at startup.
• PR #138 (11 May, 23:32) — Legacy Charter paths. Three framework artifacts still referenced docs/charters/ after fw-4.12.0 had migrated the canonical path to .straymark/charters/. Worst of all: the pre-pr.sh hook was gated on [ ! -d docs/charters ], which made for a silent exit 0 for any post-4.12.0 adopter. The drift check had been installed for seven months but was no-op.
• PR #139 (12 May, 12:02) — Broken installers. install.sh and install.ps1 still pointed to REPO=StrangeDaysTech/devtrail, BINARY=devtrail, asset name devtrail-cli-v*. The README — already rebranded — pointed to the new URL. Result: any user copying the README command from 9 May onward got a GitHub 404 running the installer. The product was broken in production for seventy-two hours.
• PR #140 (12 May, 16:49) — Micro-residual. Line one of .gitignore still read # DevTrail - .gitignore. Plus a new entry for Aparador/ in internal-dev patterns.

The lesson isn't that the discipline was insufficient. It's that discipline does not prevent residuals — it makes them findable, documentable, and repairable in a public inline errata. The first three renames (January) probably had equivalent residuals; we never cataloged them because there was no documentary habit. The fourth rebrand cataloged them. It's the first project rebrand that admits, in the public repo and in the CHANGELOG itself, that the operator didn't catch everything on the first pass.

The most uncomfortable detail — broken installers for seventy-two hours — is the one I most care to record. If instead of one solo adopter (the operator) there had been a team, that window would have hit real users. Acting now, with one self-owned adopter, was materially cheaper, says the ADR. That's exactly what the sentence was buying: the right to be wrong for seventy-two hours without hurting anyone.

7. Closing​

What I took from the process, in four claims:

1. Not all renames are the same type. The three of January were looking for the concept; the May one was defending the project against future legal debt. Only the May one could be done with a public ADR, because only the May one was born of external evidence and not internal intuition.

2. The surface vs. identity distinction belongs to the document, not to rhetoric. The ADR itself declares what gets renamed and what gets preserved. That list — paths yes, git log no; release titles yes, prior tags no — is the rebrand's armature. Without that explicit list, "rebrand" means anything you want.

3. Identity can be made legible without changing. The "Why StrayMark?" manifesto didn't invent what the project was; it articulated it clearly for the first time. The operational rebrand was used to write down what was already in the code but hadn't made it to the README. Identity wasn't rewritten — it was published.

4. Discipline does not prevent residuals; it makes them findable. Four errata PRs two days later aren't a failure of the rebrand; they're evidence that the rebrand was honest enough to admit what slipped through. The three January renames probably had equivalents; they were never documented.

Next, in the following post, an episode that connects directly with the last point: TDE as a mechanism for naming transversal debt (H-09). The first real case the framework used to articulate how to surface debt — and which left a hard lesson about stacked-PRs that deserves its own paragraph when we get there.

Anchors: ADR 2026-05-08-001. Core arc: PRs #114 · #115 · #116 · #117 · #118. Manifesto: PR #120. Residuals: PRs #137 · #138 · #139 · #140. Release: fw-4.11.0 / cli-3.11.0.

This document was produced with assistance from generative AI tools (Claude 4.7); all responsibility for the content rests with the human author.

1. When discipline starts to feel like ceremony​

By late April, Sentinel closed its fourth Charter of the month with a feeling that, in writing, sounds slightly pathetic: external audit was working — Copilot 9.25, Gemini 9.5, the drift script with zero false positives — but every close had me opening three files by hand, copying three prompts into three different windows, waiting for replies, pasting three calibration YAMLs back into the telemetry file, and eyeballing the hashes to make sure they matched. Forty minutes of copy-paste per Charter on top of work that took two hours. Discipline was working; the ritual was becoming a problem.

The audit-skills-design.md proposal, written on 3 May, named it without softening:

"If at every close the operator had to manually move data between files, throughput would collapse and discipline would stop being virtuous friction and turn into ceremony. Whatever can be automated reversibly should be automated; the documents are kept for ex-post human audit."

This post covers three days — from 2 to 6 May 2026 — during which two parallel arcs finished at the same time. One: the Charter stopped being artisanal practice and became a first-class entity of the CLI. Two: the external audit cycle stopped being a manual ritual with ad-hoc prompts and became a canonical command (with a counterintuitive architectural decision behind it that deserves its own section).

2. What Sentinel was already doing, and what StrayMark didn't have​

The 3 May proposal puts it in a sentence that's barely elegant but precisely accurate about what was happening:

"Sentinel has the skills, StrayMark doesn't."

What Sentinel had: sentinel/.claude/skills/plan-audit/ and plan-audit-review/ — local skills that generated a prompt, calibrated the response on return, and merged it into telemetry. They worked. They had been validated across six cycles. But they were coupled to Sentinel-specific paths (docs/plans/, internal/modules/, go vet) and to the "Plan" vocabulary, which had already been renamed to Charter a week earlier.

What StrayMark didn't have: nothing equivalent. The framework, up to April, was documentation + skills + a CLI with init, update, remove. The unit that in Sentinel was called Plan — the bounded unit, declared ex-ante, audited ex-post — didn't exist as a CLI artifact. It existed as practice.

The arc of fw-4.4.0 (2 May) and of fw-4.7 → 4.9 (3-5 May) consists, almost verbatim, of porting what Sentinel did by hand into generic commands that any framework adopter can invoke. The migration table, copied from cli-roadmap.md, is honest about the origin:

The fw-4.4.0 CHANGELOG frames it without metaphor: "Crystallizes the Charter pattern — bounded, auditable units of work declared ex-ante and validated ex-post — that emerged from the 6-cycle Sentinel /plan-audit experiment." The crystallization is the point. What in April was custom-with-a-bash-script, in May is a command with a validatable schema.

3. What happens when something becomes "first-class"​

PR #65 (fw-4.4.0 / cli-3.6.0, 2 May) does three concrete things:

• It creates the straymark charter new command. Auto-increments the number (NN-slug.md), pre-populates the origin (originating_ailogs if it's born from a prior AILOG; originating_spec if it's born from a SpecKit plan.md), and supports the --type X|S|M|L flag to fix the size from the first moment.
• It introduces charter-template.md, ported from Sentinel's TEMPLATE.md v3. It carries embedded the six conventions that the April experiment was crystallizing cycle by cycle: Local/Production checks separation, effort in time (not story points), structured sub-sections, R<N> risk documentation, closure with post-merge reconciliation via AILOG, and auto-checklist drift.
• It ships dist/.straymark/schemas/charter.schema.v0.json — the schema marked v0 on purpose, not v1, because the framework's principle #12 says no schema crystallizes without a second domain validating it. Sentinel is one domain. The second is missing.

PR #68 (3 May) does something that looks small but matters: the atomic Charter closure pattern, format v4. In Sentinel, the step "update the Plan-doc post-merge if the AILOG documents divergences" existed as a note in the TEMPLATE but had no systematic trigger. In practice, that meant when there was divergence between what was declared and what was delivered, the operator (me) relied on memory to reconcile the document — and memory failed. The drift stayed in the repo for days, sometimes weeks, until the next cycle caught it. Format v4 makes the reconciliation a mandatory step of closure, not a marginal note.

PR #69 (same day) closes one friction detail: manual numbering. Before, you had to decide whether the next Charter was 11 or 12; now straymark charter new reads the directory and proposes the next number. Pure UX. But it's the class of friction that, summed across twenty Charters, decides whether the framework gets used or abandoned.

The three PRs shipped in the same commit storm of a Sunday and a Monday. That cadence is deliberate: once the pattern crystallizes, UX details have to close together, not in separate bumps that leave the adopter with half the flow.

4. Three releases in a day​

What came next — fw-4.7.0, fw-4.8.0, fw-4.9.0 — are consecutive releases of the external audit cycle. The audit-skills-rollout.md proposal records the pace without disguise:

"Phase 1 executed in 1 calendar day (5 sequential PRs on 3 May 2026), substantially faster than the 1.5-2 weeks focused estimate. The throughput is due to the design in audit-skills-design.md already having the decisions crystallized (D1/D2/D3) and the arborist heuristic with explicit graceful-degradation — there were no pending decisions during implementation. It serves as additional operational evidence for principle #6 (when the proposal is well-written, implementation is execution, not design)."

The concrete external audit cycle consists of three chained commands:

1. straymark charter audit prepare <CHARTER-NN> — generates canonical prompts for external auditors from the closed Charter, its associated AILOG, and the diff of touched files. Output: three .prompt.md files in audit/<CHARTER-NN>/{copilot,gemini,claude}.prompt.md.
2. (The human carries those prompts to their auditor of choice, receives replies, pastes them back.)
3. straymark charter audit collect <CHARTER-NN> — takes the responses, validates each one against the audit schema, merges calibrations into the Charter's telemetry, and produces a summary with the convergence (or divergence) between auditors.

Decision D1 in the proposal is what holds everything else up:

"Skills delegate via Bash(straymark charter audit *) to the canonical implementation. Templates live only in dist/.straymark/audit-prompts/. Zero drift possible between skill and CLI."

There's only one place where the prompts live, one single implementation of the flow, and skills (Claude, Cursor) invoke it via Bash. It's a humble pattern — the CLI is the single source — but it avoids what in any framework with two surfaces (skill + CLI) ends up being the chronic problem: that the skill and the CLI say different things depending on who updated which last.

5. Why the CLI orchestrates but doesn't invoke APIs​

This is the strangest decision of May, and the one that took me the most work to make. It's documented literally in cli-roadmap.md §0 as "architectural decision A1":

"A1 (Phase 3): orchestration-only, no HTTP API clients in v0. Roadmap §5.4 originally suggested 'support OpenAI/Google/Anthropic in v0' with API key handling. The implemented reality is that the CLI prepares prompts, validates outputs against schema, and integrates with telemetry — but does NOT invoke APIs. The operator pastes the prompts into their auditor of choice manually."

The reasoning, also literal:

"Implementing 3 HTTP clients is 1-2 weeks + perpetual maintenance when the APIs change (premature for an experimental v0); the human-in-the-loop pattern matches Sentinel's /plan-audit; complies with principle #10 ('it is not an LLM gateway'); closes RFC #82 by design. HTTP clients reopen in v1 when a real adopter justifies it with data."

Three arguments, each with its own weight.

The first is pragmatic. Three HTTP clients — OpenAI, Anthropic, Google — are between one and two weeks of implementation, plus permanent maintenance every time any of the three changes something. For a command whose manual form was already working empirically in Sentinel, that's an absurd cost. It's engineering to solve a problem no adopter had asked to solve.

The second is about continuity. What Sentinel validated in April was precisely the human-in-the-loop pattern: the operator pastes the prompt into Copilot/Gemini/Claude by hand, reads the response, pastes it back. The six-Plan experiment that gave rise to this whole arc never invoked APIs. If the CLI now invoked APIs on its own, it would be replacing a validated pattern with an unvalidated one, with no empirical reason.

The third is about identity. StrayMark is not an LLM gateway. Framework principle #10 says it explicitly. There are dozens of products that are — LangChain, LiteLLM, LiteLLM Proxy, OpenRouter, every wrapper — and they're useful for what they do. StrayMark does something else: it structures discipline around the work done with those models, whichever model that is. Whether the CLI invokes or doesn't invoke APIs changes what the framework is; keeping it orchestration-only keeps the identity clean.

The part of the paragraph I care about most: "HTTP clients reopen in v1 when a real adopter justifies it with data." The decision wasn't closed by dogma; it was deferred behind an evidence threshold. If in six months an adopter shows that the human-in-the-loop flow breaks their throughput, the HTTP clients land. Until then, the forty seconds of manual friction it takes to paste the prompt into another window is trivial compared to the cost of maintaining three live SDKs.

6. What the framework decided not to automate​

It's worth closing with the other face of the same decision. The audit-skills-design.md proposal says:

"Whatever can be automated reversibly should be automated; the documents are kept for ex-post human audit."

The first half explains May's three releases: prompts generated automatically, calibrations merged automatically, drift detected automatically. The second half — "the documents are kept for ex-post human audit" — explains what was chosen to stay manual on purpose.

What the framework does not automate:

• The operator's reading of the AILOG before closing the Charter. The straymark charter audit prepare command generates the prompts, but the operator has to open the AILOG and read it. If we automated that — an agent that reads, summarizes, decides — we'd lose the moment of human judgment that justifies the Charter existing at all.
• The decision to accept or reject the external audit. The CLI merges calibrations into the telemetry, but doesn't act on them. If an auditor scores the Charter a 4, the Charter doesn't auto-reopen: the operator decides whether to reopen, to argue, or to declare it acceptable-with-known-debt. That decision is the discipline; automating it would destroy it.
• The invocation of the models. As argued above: the pause where the operator copies the prompt is exactly where they decide which model to use, which prompt to tweak, whether the question as phrased seems fair. That pause is feature, not bug.

The criterion running through all three is one: automate what's reversible and mechanical; preserve as manual what's judgment. Forty seconds of copy-paste aren't too many if they buy keeping the judgment human.

7. Closing​

What I took from the process, in four claims:

1. A practice that works empirically doesn't need to be reinvented to be canonized. Sentinel did the validation work in April; May only ported it into the framework. The crystallization is transfer, not design-from-scratch.

2. When the proposal is well-written, implementation is execution. Three releases in a day are only possible when all the decisions were closed before code was touched. Principle #6 says it more prosaically, but this is what it means.

3. Not everything automatable should be automated. Decision A1 — the CLI orchestrates but doesn't invoke APIs — is the technical version of a philosophical decision: human-in-the-loop isn't legacy to get rid of, it's a feature that holds the discipline up.

4. A framework's identity is defined as much by what it does as by what it doesn't. "It is not an LLM gateway" is one of the few principle #10 sentences worth remembering verbatim. What StrayMark does, it does well because there are many things it refuses to do.

Next, in the following post: the methodological episode that connects with the very start of this blog — Issue #113: Charters invisible to the agents — where the framework discovers that creating commands and schemas isn't enough if the repo's surface doesn't speak to the agent. It's the natural counterweight to this post: here we talk about what got canonized; there we talk about what didn't get seen.

Anchors: PRs #65 · #68 · #69 (Charters first-class). Proposals audit-skills-design.md · audit-skills-rollout.md · audit-cli-flow.md · cli-roadmap.md (decision A1 §0). Releases fw-4.4.0 → fw-4.9.0.

This document was produced with assistance from generative AI tools (Claude 4.7); all responsibility for the content rests with the human author.

1. A footnote that says a lot​

In the charter-telemetry.md proposal, written on 30 April 2026, there's a terminological note at the top:

"What this document calls 'Charter' was called 'Plan' in the Sentinel experiment (PLAN-01..06). The empirical data cited below refers to those historical Plans by their original name; the schema shape and prospective examples use the going-forward name 'Charter'."

It's a footnote, technical, drama-free. But it records the exact moment the artifact changed names — and, more interestingly, it records an archival decision the blog also respects: what was called Plan at the time keeps being called Plan in the original records. Rewriting the name backwards would falsify the trace.

This post covers two things that happened in five days: the framework's first systematic experiment — Sentinel's six Plans, run between 25 and 28 April — and the rename that came right after, on the 30th. They aren't two separate events. One led to the other.

2. Six Plans on paper, five in practice​

The experiment was designed with six Plans (PLAN-01 through PLAN-06) and executed with five. PLAN-04 never ran: it stayed as a catalog of seven deferred features, a list of things we wanted to do but the test cycle couldn't cover. It's only honest to say so, because the very document that validates the thesis (thesis-validation.md) records it openly in its summary table:

Five Plans, four distinct sizes: three XS, one S, one M. Deliberately heterogeneous domains — an operations deploy, two admin endpoints, a contract bump, a backend feature with configuration logic. It wasn't a synthetic benchmark. It was Sentinel's real code between 25 and 28 April, partitioned into bounded units and audited piece by piece with three models (Copilot, Gemini, Claude) acting as external auditors.

That the sixth Plan didn't run matters for two reasons. The obvious one: the experiment ran out of time. The more interesting one: PLAN-04 was the only large Plan in the batch — seven accumulated features, no natural boundary. That precisely that Plan was the one that didn't make it through was already saying something about the size the format could tolerate. Small Plans, yes; roadmap-Plans, no. That lesson was canonized later without anyone having to write it: StrayMark's Charters today are "bounded units, hours to days, one branch", not quarterly roadmaps.

3. The experiment iterated on itself​

Five executed Plans produced three different formats. It wasn't on a whim; it was because each cycle exposed something the previous format didn't capture.

• v1 — the first three Plans (01, 02, 03) ran on an original format. Five recurring patterns were identified in the audit AILOGs, but none was formalized into a template. They existed as habit, not as contract.

• v2 — for PLAN-05, those five patterns were materialized into TEMPLATE.md, plus a "Format conventions" section in the README. Doc-only: nothing executable yet. The hypothesis: if the format is explicit, external auditors converge better. AILOG-020 says it plainly: "Internal patterns that have been applied for a while but have no name remain invisible to external auditors. Naming them formally turns practice into a public signal."

• v3 — for PLAN-06, a new pattern was added (auto-checklist drift) and, this time, executable tooling: scripts/check-plan-drift.sh, ~145 lines of bash that validate whether the actual delivery matches what the Plan declared. For the first time, the format stopped being prose only and started having a verifier.

What I want to point out here is the shape of the curve. v1 captured latent practice. v2 named it. v3 wrote a program that checks it. That's the full arc of any useful standardization — only compressed into five Plans, not five years.

It's also the first concrete evidence of something that, two months later, would be named explicitly as Pattern 1 (pre-declare refresh) and Pattern 2 (amend-on-emergence) in CHARTER-CHAIN-EVOLUTION.md. What got canonized there as a meta-pattern started here, in April, as habit-without-a-name.

4. The hardest evidence: external auditors converging​

The most loaded assumption of the thesis was: "structured notes reduce failure modes, and the reduction is visible when external auditors look". The way to prove it: send the output of each Plan — the modified files, the AILOG, the Plan-doc under TEMPLATE — to three auditors who hadn't participated in development (Copilot, Gemini, and a critical analysis from Claude) and compare the aggregate scores.

The number thesis-validation.md reports for PLAN-05 (the first Plan under v2, and the only M-size one) is clear:

"Best combined auditor calibration across 5 cycles (Copilot 9.25, Gemini 9.5). Accumulated hypothesis confirmed: TEMPLATE v2 + rich AILOGs reduce the ambiguity surface for external audit."

Two heterogeneous models, different instructions, converging around 9.3 out of 10 — on the largest Plan in the batch, no less, not the smallest. That's signal, not noise. And it replicated when v3's check-plan-drift.sh was exercised:

"PLAN-05 (with known drifts): script reports 3 omitted files: evaluator_test.go (F4), repository.go (F1/R6), statuscenter/service.go (F5) — exactly the 3 drifts that Copilot+Gemini captured in their audits. Zero false positives."

The automated script and the two external auditors agreed exactly on which Plan files had been left undone. This isn't an argument that the script is smart — it's bash and grep; it couldn't be dumber. It's an argument that the Plan format, once formalized, makes any inspector (human, agent, script) see the same things. Structured discipline doesn't require intelligence to be audited: it requires clarity.

5. What the experiment didn't prove​

This is the section I most want on the record, because it's where it gets tested whether the blog is willing to be honest.

thesis-validation.md was explicitly designed to break the thesis, not to defend it. The first line of the document reads:

"This document confronts that thesis with data. It does not defend it; it tries to break it. The goal is that a reader who didn't buy the thesis can, reading only this text, decide whether the available evidence supports it, qualifies it, or refutes it."

The final verdict, with the thesis's six assumptions faced against the evidence, is this:

Three assumptions fully validated, two partial, one without evidence, zero refuted. The assumption about non-binary approvals went untested because Sentinel is a single-owner project; ruling on it would require a real team with multiple signers. And cryptographic signing — Sigstore, hash-chaining, the technical guarantees of an append-only log — wasn't exercised because no Plan touched that part of the flow. That stays in the document as an explicit gap, not as a hand-waved claim.

What the experiment didn't prove matters more than what it did. If we'd published six greens instead of five honest verdicts, the blog would be marketing. The way to avoid it is to say, without softening: here are assumptions we don't have evidence for, and a one-operator project can't generate it. Others will; the framework will mature with that data.

6. Why Plan became Charter​

The 30 April rename wasn't marketing. The reason is written literally in WHAT-IS-A-CHARTER.md:

"GitHub SpecKit already uses the word 'plan' (/speckit.plan, plan.md) for a different artifact, and the nominal collision generated friction in adopter docs that combine both flows."

SpecKit already had a plan.md. StrayMark had one too. In the documentation of an adopter using both, plan meant different things in adjacent paragraphs. The rename existed to fix that collision.

But behind the pragmatism there's a nuance worth naming. The two artifacts are distinct, and the distinction is structural:

What SpecKit calls plan looks more like an ADR with an architectural skeleton. What StrayMark calls Charter looks more like a task-card with contractual verification and an audit anchor. They're complementary artifacts, not competitors; SPECKIT-CHARTER-BRIDGE.md makes that explicit later, in May. But the nomenclature had to stop colliding before complementarity could even be discussed.

The part I find important to highlight is the adjacent decision: Sentinel's historical records — the AILOGs, the telemetry, the check-plan-drift.sh, the sentinel/docs/plans/ folders — preserve the name Plan. WHAT-IS-A-CHARTER.md itself argues it this way:

"Sentinel's historical records (Plans 01–06, sentinel/docs/plans/, sentinel/scripts/check-plan-drift.sh, AILOGs and YAML telemetries PLAN-NN.telemetry.yaml) preserve the original name — they are empirical evidence of a specific moment in time, and rewriting history would falsify the record."

Rewriting history would falsify the record. For me, that sentence is the true heart of the rename. The framework exists to preserve a trace, not to rewrite one. When the artifact changed names, the change was prospective: from 30 April onward, new ones are Charters. The old ones, the experiment ones, are still Plans. The inconsistency is deliberate, and the inconsistency is the evidence.

The 30 April rename's other companion — the telemetry proposal — came the same day for reasons that look obvious in hindsight: if the emergent pattern deserved a new name, it also deserved structured measurement. The charter-telemetry.schema.v0.json schema, with its fields for invested time, detected drifts, size, domain, is the machinery that runs today what Sentinel was still measuring by hand in YAML. Plan got renamed to Charter on the same day we decided to start counting Charters.

7. Closing​

What I took from the process, in four claims:

1. The experiment was designed to break, not to confirm. "It does not defend it; it tries to break it" — that was, literally, the brief of the document that validated the thesis. Any technical blog worth respecting has to tolerate that framing.

2. Five Plans executed, of six designed, in four days. The one that didn't run (the largest, a seven-feature roadmap) was, accidentally, the first evidence of what size the unit can tolerate. Today Charters are bounded by contract. In April, they were bounded by accident.

3. The format evolved inside the experiment itself: from habit, to template, to script. Five Plans produced three versions of the format. The v1 → v2 → v3 curve is the curve of any useful standardization — just compressed.

4. The rename came from pragmatism, not marketing. And historical preservation came from principle. Plan keeps being called Plan in Sentinel, where that's what it was called. Charter started being used from April onward. The framework doesn't rewrite its own archive: that's why it's worth tracing.

Next, in the following post: two close-by milestones that codify qualitatively new capabilities — Charters as a first-class entity (PR #65, fw-4.4.0) and the external multi-model audit cycle (audit-skills-design, audit-cli-flow, releases fw-4.7 → fw-4.9). That's where the Sentinel experiment became CLI functionality.

Anchors: proposals thesis-validation.md and charter-telemetry.md (both 2026-04-30). Canonical Charter definition: WHAT-IS-A-CHARTER.md. Operational schema: dist/.straymark/schemas/charter-telemetry.schema.v0.json.

This document was produced with assistance from generative AI tools (Claude 4.7); all responsibility for the content rests with the human author.

1. The tool that two weeks later revealed the outlier​

Post 8 of this blog covered a very specific episode: the discovery of the only framework file whose canonical language was Spanish. The operator didn't find it through systematic inspection; they found it by running straymark explore --lang es during an audit preparation and noticing, visually, that one template was written backwards relative to the rest. The line from that post:

"A new surface of the framework (the TUI) put all the files into simultaneous view, and the inconsistency became obvious — like tidying the bookshelf and noticing one book is shelved spine-backwards."

This post covers the tool. The TUI straymark explore was born almost three weeks before the discovery it enabled — on 25 April 2026 in cli-3.4.0 — and matured across four more releases, all closed in under 48 hours. This isn't a post about code. It's a post about a specific piece of tooling that ratifies a thesis the blog already named: new tools produce visibility without meaning to.

2. Why a TUI in a Markdown framework​

By late April 2026, the framework had something like fifty governed Markdown files — PRINCIPLES.md, AGENT-RULES.md, DOCUMENTATION-POLICY.md, QUICK-REFERENCE.md, SPECKIT-CHARTER-BRIDGE.md, plus templates in dist/.straymark/templates/, plus audit prompts, plus the versions in three languages of each one (i18n/es/, i18n/zh-CN/). All on disk, all browsable with find and cat, all perfectly accessible.

And, at the same time, all invisible. For an adopter cloning the framework for the first time, the first question wasn't "where is rule N?". It was "what's here?". And a recursive ls doesn't answer that question — it overwhelms it. A grep requires knowing what to search for. An editor opens one file at a time. The framework had reached the size where its own surface had become opaque.

straymark explore was born precisely to fix that: a navigable surface that answered "what's here?" in three seconds. Not an IDE; not a Read-the-Docs-style system; not a static site. A TUI — terminal user interface — that runs on the adopter's repo, indexes the framework's canonical files, shows them grouped by category, and lets you read them with a colored Markdown viewer inside the terminal.

The decision to build a TUI and not a web app is aligned with two things the blog already argued. First, Post 4's principle #10 — "StrayMark is not an LLM gateway" — generalizes to "StrayMark is not whatever already does something else". We don't compete with MkDocs or Material for MkDocs. Second, the A1 decision of the same Post 4: orchestration-only. The TUI doesn't require a server, doesn't require a build step, doesn't require a connection: it runs on the adopter's repo, where the framework already lives. It's the humblest piece that could solve the problem.

3. What landed in cli-3.4.0​

PR #57 from 25 April, merged as cli-3.4.0, did three concrete things:

• Introduced the straymark explore command. Two-panel layout when the terminal has 100 columns or more: navigation on the left (30%), document on the right (70%). Narrower terminals collapse to a single panel. Status bar at the foot with relevant shortcuts.
• Indexed the framework's canonical files into a navigable hierarchy: governance docs (AGENT-RULES.md, DOCUMENTATION-POLICY.md, ...), templates (dist/.straymark/templates/), audit prompts, and the adopter's directories (docs/charters/, .straymark/07-ai-audit/, ...). Each node expandable with Enter.
• Wired in the i18n resolver. The --lang <code> option lets you run straymark explore --lang es and get all governance docs in Spanish if a translation is available. If not, silent fallback to canonical EN. The commit's literal description:

"Wire language config and a new --lang flag through the explore TUI so framework governance docs are served from i18n/<lang>/ when a translation exists, falling back silently to English otherwise."

The i18n resolver part matters more than the TUI itself. Until cli-3.4.0, the helper resolve_localized_path was used only by straymark new (to resolve which template to inject into the adopter in the right language). PR #57 extracted it into cli/src/utils.rs:146 as a shared helper, so that a single definition of how i18n/<lang>/ overlays resolve backs both the new command and the explore command. The behavior stays predictable for the adopter: if you translate a template into i18n/es/, the TUI will show it the same way generation will use it. No surprises.

Markdown rendering uses pulldown-cmark for the parser and ratatui widgets to paint. Color-coded syntax, code blocks with borders, tables with rounded borders, headings indented by level. It isn't flashy; it's readable.

4. Four refinements in thirty-six hours​

What happened between 25 and 27 April is what Post 9 named months later as a property of the process: when the proposal is well-written, implementation is execution. Four more PRs, closed in under 36 hours, took the TUI from "works" to "done":

The arc's speed repeats the pattern. The five PRs of fw-4.11.0 covered in Post 6 (rebrand to StrayMark) closed in forty-three minutes. The three audit-cycle releases covered in Post 4 closed in one day. The TUI curve is similar: the design was clear in PR #57, and refinements came as the operator started using the command frequently and noticed the frictions.

The anecdote worth recording is cli-3.5.2: the l and h keys it removed were vim aliases — the operator uses them out of muscle memory in their editor. But when the uppercase-L language switcher landed hours earlier, the lowercase l and the uppercase L shared the same physical key, and the visual transition was confusing. The fix was to remove the undocumented aliases: the full-letter spelling (j/k/g/G) stays; the abbreviations that duplicated functions go away. It's a small UX detail that illustrates how TUI decisions tune against real use, not UX theory.

5. What the TUI revealed two weeks later​

Here the post picks up Post 8's thread from the other end. What cli-3.4.0 added to the framework wasn't just a navigation command; it was a surface of simultaneous visualization. That is: before the TUI, the framework's files existed but were read one by one. After the TUI, they could be seen all at once, grouped, tagged, in the same presentation mode.

That changes what the operator can notice.

On 12 May, two and a half weeks after the cli-3.4.0 merge, the operator ran straymark explore --lang es before an external audit cycle. They got to the "audit prompts" group. Opened it. And noticed something that had been there for a year: the root audit-prompt.md was written in Spanish, while every other canonical framework file had English in root and i18n/es/ overlays. One file, backwards relative to the convention.

The detail wasn't found by systematic review. It was found by visual contrast. It's exactly what Post 8 §3 codified as thesis:

"New tools produce visibility."

The TUI didn't cause the outlier — the outlier had existed since the first commit that ported the Sentinel skill plan-audit into the canonical framework (Post 3 records this). The TUI didn't look for the outlier either; it isn't an inconsistency-detection tool. All it did was put every file on the same screen, in the same presentation mode, and let the human eye notice what had been there from the start. The conclusion worth recording is structural: any framework that crosses fifty canonical files needs a surface of simultaneous visualization, not because the surface is pedagogically important in itself, but because without it certain regularities of the repo become unobservable.

6. Small technical decisions that matter​

Three TUI design details worth recording, all coherent with framework principles the blog has already named:

Feature flag tui. The CLI's Cargo.toml declares the TUI as an optional dependency (ratatui + crossterm + pulldown-cmark live behind the tui flag, enabled by default). An adopter who only wants init, update, validate can build a binary without the TUI via cargo build --no-default-features. It closes a sub-architectural decision that recurs in the framework: give the adopter value by default, but let them choose a lighter binary when the TUI adds nothing to the flow.

Lazy document loading. The DocIndex keeps a HashMap<PathBuf, Document> that fills up as each node is opened, not at startup. For a repo with a hundred governance files, this means straymark explore boots in under 200ms and only reads disk when the operator hits Enter. The decision is technically trivial; what isn't trivial is that it was made consciously. The TUI doesn't compete with an IDE; it competes with cat. It has to feel just as immediate.

History stack for hyperlinks. When one framework document mentions another (e.g., AGENT-RULES.md §3 refers to DOCUMENTATION-POLICY.md §6), the TUI lets you jump to the referenced one with a click — and back with Esc. Internally there's a navigation stack that restores the previous document's scroll position. It's the piece that turns reading the framework from "I open a file, close it, open another" into "I follow a conversation between documents without losing the thread". The number of cross-references the framework has today — between principles, agent rules, schemas, templates — makes this navigation structurally important, not cosmetic.

7. Closing​

What I took from the process, in four claims:

1. A framework that crosses a certain size needs a surface of simultaneous visualization. It isn't ergonomics; it's the condition for certain regularities of the repo to be observable. Post 8 documented the consequence; this post documents the tool.

2. The TUI doesn't cause the discoveries; it enables them. The audit-prompt outlier had existed since May of the previous year. All that changed in April was that a screen appeared where it could be seen next to its peers. The tool doesn't have opinions about content; it changes the conditions under which the human eye can notice regularities.

3. When the design is clear, implementation is hours, not sprints. Five PRs in thirty-six hours — language-aware, live switcher, OS detection, panel i18n, keybinding cleanup — are only possible because the design was closed in PR #57. It's the same pattern as Posts 4, 6 and 9.

4. The most interesting technical decision can be a compile-time flag. The tui feature flag explicitly declares that the TUI is optional, that the framework still works without it, that the adopter decides. That architectural humility is the difference between a CLI that assumes how the adopter works and a CLI that offers itself where it can be useful.

With this post the blog covers the H-14 milestone the first batch left as explicit debt. The remaining candidate milestones that PLAN-INVESTIGACION.md §1.43-55 recorded — AGENTS.md universal inject, full EN/ES/zh-CN i18n coverage, straymark validate as a formal layer, CLA assistant — stay available for future batches. No promised cadence, but recorded.

Anchors: PR #57 — cli-3.4.0 (language-aware explore, 25 Apr 2026). PRs #60 · #61 · #62 · #63 — refinements cli-3.5.0 to cli-3.5.2 (25-26 Apr 2026). Code: cli/src/tui/ (15 files). Adopter doc: docs/adopters/CLI-REFERENCE.md §straymark explore.

This document was produced with assistance from generative AI tools (Claude 4.7); all responsibility for the content rests with the human author.

Editorial note: this is the first post published retroactively on the blog. The date in the frontmatter corresponds to a point inside the arc the post narrates, not the day it was written. The entire blog is being built this way, backwards, starting from the episode that triggered me to write it at all (emergent-observation-design, 2026-05-16). Pretending otherwise wouldn't help anyone.

1. The day after​

On 28 January 2026, at 17:29 Central Time, this commit landed in the repo:

chore: rebrand Chronicle to Monimen

One day. Twenty-nine hours, to be exact, after the project's initial commit. The framework barely existed, and it was already changing its name.

I'm telling this in the past tense, but it happened three months ago. And three months ago, two more renames later, it still wasn't called StrayMark. The project that today bills itself as Documentation Governance for AI-Assisted Software Development carries a short, disorderly prehistory that's worth naming before moving on.

2. Five events, four months​

Three renames in three days. Then a month-long pause. Then the org rebrand with the Rust CLI bundled in. Then another two-month pause. Then StrayMark, this time with a public ADR anchoring the decision.

A small detail worth flagging: the 28 January commit (Chronicle → Monimen) was not marked BREAKING CHANGE. The 29 January one (Monimen → DevTrail) was. "BREAKING CHANGE: Complete rebrand from Monimen to DevTrail", the commit body reads. The difference is small but telling: the second rename felt more definitive. It was, for two months.

3. What doesn't move​

This is the section that interests me most. The project changes names four times in four months. The idea doesn't.

The README of the initial commit — the one that lived in the repo when it was called Enigmora Chronicle Framework — opens with this line:

Documentation Governance for AI-Assisted Software Development

It's the same line that opens the StrayMark README today. Four names, one tagline.

A bit further down, that same v1.0.0 README states the project's thesis in an explicit block quote:

"No significant change without a documented trace."

That sentence is, today, Principle #1 of the framework. It lives in PRINCIPLES.md §1 — Total Traceability. The wording shifted slightly when translated into Spanish, but the weight of the claim stayed intact: no significant change without a documented trace.

The eight document types listed in the v1.0.0 README — REQ, ADR, TES, INC, TDE, AILOG, AIDEC, ETH — are all still alive. Others were added later (MCARD, SBOM, SEC, DPIA), but none displaced the originals. The January taxonomy held.

The name moves four times; the idea doesn't. What changed across those four months wasn't the what — it was the label that fit on it.

4. The AIDEC with a typo'd year​

There's a small anecdote I keep coming back to.

The project's first structured document — the first AIDEC, the document that, in the framework's own taxonomy, records a decision made with an agent's assistance — is AIDEC-2025-01-27-001-i18n-strategy.md. It lives in commit 7b7193e, added at 18:01 on 27 January 2026, six hours after the initial commit.

The ID says 2025. The commit is from 2026.

The very document that established the [TYPE]-[YYYY-MM-DD]-[NNN] identifier convention has a typo in its own year. The framework started imperfect, and nobody fixed it in time. Anyone who clones the repo and looks at the ID closely will notice it — and will also see that the commit which introduced it is dated correctly. That's the best evidence I have that audit discipline is something that arrives later; it doesn't ship with the repo.

But more interesting than the typo is what that AIDEC decides. The question José posed in January, with help from Claude Opus 4.5, was: how do you internationalize a framework that exists for humans but whose configuration is read by agents? The answer, from the justification section of the AIDEC itself:

"AI agents (Claude, Gemini, Copilot, Cursor) process instructions equally well in any language, so translating their config files provides no functional benefit."

The decision that document made — translate what humans read (documentation, templates); keep what agents read (CLAUDE.md, GEMINI.md, .cursorrules) in English — was an early intuition that the framework has two distinct audiences. The blog itself ratifies that intuition today: bilingual Spanish/English for the humans who'll read it, while the skills and prompts that orchestrate agents stay in English only. Three months later, it's still the right call.

5. The birth of the CLI — and the missing number​

5a. The day the project became software​

On 1 March 2026, at 19:05, commit c7e9026 landed:

"feat: rebrand to Strange Days Tech, add CLI scaffolder, restructure repo"

Until that day, the project was prose. It was templates, skills, governance rules, and a pile of Markdown that depended on the operator (me) copying it by hand into the repos where I wanted to use it. There was a bash script called copy-devtrail.sh. It was a toy.

That 1 March commit introduced cli/Cargo.toml and cli/src/main.rs. The first CLI was called devtrail-cli, version 2.0.0, and had three commands:

enum Commands {
    Init { path: String },
    Update,
    Remove { full: bool },
}

init, update, remove. Three operations. Everything else came later: status, repair, validate, new, compliance, metrics, analyze, audit, explore. But the original three are still there, almost untouched.

The important thing about that commit isn't the three commands: it's that, on that day, the project stopped being a body of documentation living in its own repo and started being an executable tool that gets installed into other repos. The boundary between "documentation governance project" and "framework with tooling" was crossed that Sunday in March. It matters more than any of the renames that came before.

It was also, incidentally, the day the project moved GitHub accounts: from enigmora/devtrail to StrangeDaysTech/devtrail. The organization renamed itself from Enigmora to Strange Days Tech, S.A.S., in the same commit that shipped the CLI. Simultaneous renames: the product's (Monimen to DevTrail) had happened in January; the company's, in March. Two distinct layers of identity moving on different clocks.

(A side note, important for archival accuracy: agent co-authorship — the Co-Authored-By: Claude Opus X.Y line that appears in commits — does not start in March. The initial commit of 27 January is already signed by Claude Opus 4.5. Transparency about AI co-authorship was a rule from the first line of code. What changes on 1 March isn't the practice, it's the scale: the CLI is the first artifact where co-authorship produces executable code, not documentation.)

5b. The missing number​

There's a detail about framework versioning that makes more sense if you just look at git tag:

fw-2.0.0
fw-2.1.0
fw-4.0.0
fw-4.1.0
...

There is no fw-3.x.x. The project deliberately jumped from 2 to 4.

The jump syncs with commit 21e03b2, dated 27 March 2026, whose body describes the change like this:

"Reposition DevTrail from 'documentation helper' to 'ISO 42001-aligned AI governance platform' across all user-facing docs. Lead with regulatory urgency (EU AI Act Aug 2026) and compliance value proposition."

Until March, DevTrail presented itself as a documentation helper. From that commit onward, it presented itself as an ISO 42001-aligned AI governance platform. The version-number jump (2 → 4, skipping 3) marked the magnitude of the thesis shift. It was a conscious call: one major bump wasn't enough to signal the difference.

And this is where the prehistory starts to make retrospective sense. The intuition that had been in the repo since January — the idea of a robust, normative, standards-alignable record-keeping system — was only named explicitly in March. We'll see this more clearly in the next section, when we talk about the second name.

6. About the names​

Three of the four renames have no ADR. The justification lives only in commit messages, and sometimes not even there: the commit chore: rebrand Chronicle to Monimen doesn't say why Monimen. The next one, chore: rebrand Monimen to DevTrail, doesn't say why DevTrail either. The practice of the ADR as a disciplined artifact came later; in January the name would change with a commit and the justification would evaporate into the conversation that produced it.

But some etymology is rescuable.

• Chronicle (27 Jan). Historical record. Logbook. The name speaks for itself: what you do with a chronicle is write down what happened, in order, so it can be reviewed later. No ADR, but the word carries its own meaning.

• Monimen (28 Jan). This is the only name whose intuition I do remember and that's worth telling. Monimen came from a wordplay on Monumento (Monument in English). The analogy that motivated the suggestion: the norms already being intuited at that point — AIDEC, AILOG, alignable with the emerging ISO 42001 governance regime — represented something solid and durable. A monument is something erected to last; an immovable reference point for a community. That's what the framework wanted to be. The clipped suffix — Monimen instead of Monument — was an attempt to give the term a more agile, software-like feel, less marble. It lasted twenty-five hours. But the intuition didn't die: what would, in March, get named explicitly as ISO 42001-aligned AI governance platform is the mature version of that same impulse. Monimen was a name with the right thesis and the wrong tongue.

• DevTrail (29 Jan). The developer's trail. Less solemn than Monimen, more concrete. The commit marked it BREAKING CHANGE — which, viewed from May, carries some irony: the most definitive of the first three rebrands was precisely the one that lasted three and a half months before being replaced.

• StrayMark (8-9 May). The mark, the trace that's left behind. But this rebrand deserves its own post: there's already a public ADR (2026-05-08-001), an arc of five core PRs (#114-#118), and a "Why StrayMark?" manifesto in the README that earns separate treatment. Here, I just close it as the rebrand that finally came with documentary discipline behind it.

The point isn't the etymology itself. It's that each name ratified a distinct intuition about what the product was: logbook (Chronicle), normative pillar (Monimen), developer's trail (DevTrail), residual mark (StrayMark). Four names are four hypotheses about the concept. The search ends when the concept stabilizes — and only then can the name sit still.

7. Closing​

What I took from the process, in four claims:

1. We weren't looking for a name. We were looking for the concept. The four renames are evidence of searching, not of indecision. The concept got sharper as it cycled through names.

2. Three of four renames without an ADR. The practice of the ADR as a disciplined artifact came later. In January there was no habit yet. That isn't debt — it's honesty about pace. Governance habits are the result of wanting to record what was already happening, not the precondition for starting.

3. The project became software on 1 March 2026. Before that, it was prose. The Rust CLI is the boundary. Any conversation about StrayMark as a framework has to acknowledge there's a before and an after that commit.

4. There probably won't be another rebranding. But the blog isn't promising it. The project is honest about its own mutability, and promising otherwise would betray the first claim of the first post.

When I started writing this blog, two weeks ago, I didn't intend to cover the prehistory. The idea was to talk about Charters, about emergent observation, about the things the framework actually does today. But the blog itself is a retroactive act — it exists because something surprised me enough to make me start writing. And once I decided to write backwards, getting to January was inevitable. To the three renames in three days. To the AIDEC with the typo'd year. To Monimen.

Next, in the following post: the framework's first real methodological experiment — Sentinel's six Plans, and the day Plan got renamed to Charter. That's where the story the blog came to tell actually begins.

Anchors: commits 7c58b6d · 0b772bc · 25ab7a4 · 7b7193e · c7e9026 · 21e03b2. Original README: git show v1.0.0:README.md.

This document was produced with assistance from generative AI tools (Claude 4.7); all responsibility for the content rests with the human author.