Version. 0.8
Date. 2026-08-05
Supersedes. v0.7 (filed 798e70e) and its predecessors. All stand as siblings, unaltered.
Author. Claude.ai (drafting session). Operator: Marvin Percival.
Status. Standing. Applies to every versioned document a session executes from, and to the sessions that draft them.
Changes from v0.7. One section added: an instruction repeated is not an instruction that works. Change requests have carried a branch-discipline instruction in both their body and their kickoff, and sessions have committed to the main line anyway, repeatedly. The instruction is converted into a step — every Step 0 begins by creating the branch — and the general form is recorded, because this will not be the last instruction that is stated clearly and ignored.
Changes from v0.6. Two unverified specifics dropped. v0.6's changes-line located a rule "two lines below" another and a mechanism "four lines below that" — the first is eighteen lines, not two. The executing session's own report had said two lines earlier as loose phrasing without counting; the drafting session hardened it into a positional assertion rather than checking it, which is this note's own rule about carried text operating on a session report instead of a prior version. And "three consecutive versions" is dropped as unverifiable: it is ambiguous between versions filed and versions drafted, and the drafts that would settle it were halted before filing and so are not in the record to count. Both are dropped rather than corrected — neither earns anything.
Changes from v0.5. One invented count removed. v0.5 said the vacuous-path check "has fired twice, both times catching a filing whose source had never arrived" — doubling a count and changing its noun, from a build directory to a filing's source, while dropping v0.4's accurate description. It appears below the rule a correct number attached to the wrong noun is the commonest form, and arrived by the mechanism named below that: the sentence was carried from v0.4 and rewritten rather than re-verified. The tally is dropped rather than corrected — the discipline is complete without one, and the instances the drafting session had in mind were in conversation rather than in the record, which is precisely what it should not be asserting from.
Changes from v0.4, re-checked. A new section — the kickoff rule, moved here from where it kept failing. CR-2026-164 carried a paragraph inside its own kickoff asserting what the block would not do; it broke that claim at v0.1 and again at v0.2, and the correction pass at v0.2 edited the very sentence that carried one of the surviving defects. A rule re-asserted inside every change request is a rule broken inside every change request. It lives here now, is swept once, and settles the ambiguity that made the second sweep a judgement call. Also: five drafting rules collected from a week of halts, all of the same family.
The record's filing discipline is siblings, never overwrites. For a document that is read — a manifest, a findings report, a scoping note — a superseded sibling is history, and preserving it is the point.
**For a document that is executed, a superseded sibling is not history. It is a live instruction set that no longer matches the decision.**
CR-2026-159 is the worked case. Its v0.5 reversed the seam design, and its v0.10 built the opposite of what v0.1 to v0.4 specified. A session opening any of the first four by filename would have built an approach the project had proved unsound and abandoned.
The hazard is self-propagating. Each version carries a kickoff naming its own path, so a session starting from a stale sibling is told by that sibling that it has the right document.
Before executing any versioned document, confirm it is the highest version present — sorting numerically, not lexically. ls sorts v0_10 between v0_1 and v0_2. A gap in the series is normal — drafts halted at pre-flight are never filed — so highest means highest present, not highest expected.
A version bump that changes behaviour is named as such in its own changes-line.
The kickoff block names a version, never a bare document.
When the kickoff and the record disagree, the session stops and surfaces the mismatch. Neither wins automatically.
No standing note outranks an instruction the Operator typed. A note can require that a conflict be surfaced. It cannot decide one. One message resolves it, and the resolution is his.
New at v0.5, and it belongs here rather than in each change request.
A change request's kickoff block is what a session is pasted and acts on first. The body and the block therefore hold two copies of anything stated in both — and when the body changes, the block is what goes stale.
The rule: a kickoff restates no fact that can drift. No count. No file path into the code. No commit identifier. No scope boundary. No step's contents. No argument or reasoning. Those live in the body alone, so a change there cannot leave the block lying.
What a kickoff does carry:
The entry point — the change request's path and version, the grounding documents that must be read before it, and the charter. Naming what to read is not a restatement. (Settled at v0.5. An executing session correctly identified this as ambiguous: a grounding path is a path by the letter of the rule, and a kickoff that cannot say what to read first is useless. The carve-out extends to everything that must be read before the change request, and no further.)
Standing fences — facts true regardless of any particular change request: playground_dev is the live production database; deployment is never a session's act; commit to a branch and check the branch before the first commit; append the outcome to the status brief. These appear in both places deliberately and are labelled as fences, because they cannot go stale.
Pointers — Section 5 carries the step sequence, not a summary of it.
And a kickoff carries no paragraph describing itself. (The rule that produced this rule. CR-2026-164 asserted its own compliance twice and failed twice, and the second failure was inside a sentence the correction pass had just edited. A self-describing claim is a second thing to keep true, and it is the thing that keeps failing while the block it describes is substantively fine.)
Added at v0.8. Change requests have carried check the current branch before the first commit in both their body and their kickoff block. Sessions have committed to the main line anyway, repeatedly, across separate change requests and separate sessions — most recently landing an entire change request on main, so its checkpoint tagged the head directly instead of marking a merge.
The consequence is small and specific. Nothing is lost and nothing is wrong in the code. What is lost is the shape: without the merge, a change request is no longer a bounded set of commits you can see as one thing, and the tag marks a moment rather than a unit.
The rule: a step a session must perform beats an instruction it must remember.
Every change request's Step 0 begins by creating the branch, as its first numbered action, before pre-flight and before anything else. Not "check the branch" — "create the branch." A check is something a session can be diligent about and forget; a step is something it either did or did not do, and its own report shows which.
The general form, which is the part worth keeping. When an instruction has been stated clearly and ignored more than once, the instruction is not the fix. Restating it more firmly produces a more firmly ignored instruction. Convert it into a step, a default, or a thing that cannot be skipped without the skip being visible.
All of one family: a specific stated where the work needed none, and therefore never verified.
State no specific the work does not need. A line number never read. A commit identifier gestured at rather than looked up. A count of anchors standing beside the anchors themselves. None changed what got built; every one had to be caught by an executing session. Where a count is the finding, it stays — eighty-three sites across thirty-six files earns its place. Where it is decoration, it goes.
Count the thing; do not read the figure. Five new items where there were six; two built rooms named three in the next sentence; six change requests above a table listing five. A correct number attached to the wrong noun is the commonest form.
When a decision changes, sweep for its dependents, not just its statement. A decision reversed in the section that states it leaves the checkpoint, the kickoff, the gate and the framing all describing the decision it replaced.
Re-read carried text; do not carry it. A changes-line marked carried was written against a different document. Carried text reads as already-checked, which is exactly why it is the most likely to still be wrong — re-reading one such block found two further errors beyond the one that prompted it.
Delete a false claim rather than annotating it. CR-2026-162's §2 asserted the engine was untouched, which was never true, and a correction block beneath a later section carried the exception. The block went stale repeatedly because it explained scope rather than stating it, and so read as commentary in every sweep. Deleting the claim deleted the annotation.
A sweep pattern must not encode an assumption about its target. Step [0-9] skips Steps. A pattern ending in a backtick skips fenced blocks. \bsix\b skips Six. grep -c counts lines where the caller means occurrences. In each case the check passed by being narrower than the check it claimed to be.
An exception assertion names the exception. pytest.raises(Exception) around an invariant keeps passing after the invariant is removed. A regression test that passes for the wrong reason is worse than no test, because it retires the question.
Parsing is not compiling. ast.parse accepts a repeated keyword argument that compile() rejects.
A check against a path that does not exist passes vacuously. Confirm the target exists before treating its silence as a pass. Its documented origin is a verification instruction naming a directory that was never created, which reported clean by having nothing to test.
Test the claim; do not read it. A document asserting its own compliance is evidence of intent, not of compliance.
Nothing is edited retroactively. Superseded versions stay as filed; supersession is marked in the new version, not by editing the old.
Ordinary archival is unaffected. This note governs the moment before execution, and the drafting that precedes it.
The charter is F-4 — its amendments are Operator acts. These are working disciplines that sit under it. If the Operator wants any of them in the charter proper, that is his to decide at cadence; nothing is blocked either way.
DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks — standing note — superseded versions of executable documents — v0.8 — 2026-08-05 A document that is read has history. A document that is executed has only a current version — and no document should have to claim it is disciplined.