Claude Code First, specification version 0.1.0. The plain-language guide
Version 0.1.0. Grade R3/S3.
F103 A design or diagnosis written before implementation was overturned by implementation, while the symptom the task stated held
| Field | Value |
|---|---|
| Status | active |
| Topic | Planning, recording, and what the person decides |
| Grade | R3/S3 |
| Cases | roadkeep (recorded of a repository it does not name), polyweave, winwright |
| Contrary | none |
| Harness facts | none |
Claim
In three projects the design or diagnosis recorded for a task before its implementation was found wrong once the task was implemented or measured, while the symptom the task line recorded stayed accurate.
Mechanism
A task's rationale is written when it is filed, from what the author knows then; the code and the measurements move before somebody claims it. The symptom (what does not work) is an observation, and the design (what to build) is a prediction, so the prediction is the part that fails. roadkeep's task-line format keeps the two apart by allowing the symptom and never a solution name in the line.
Observations
- roadkeep. RK310 records design sections found stale on implementation: "Measured in one block of eleven tasks, twice." [roadkeep@402ef7fc:docs/IMPROVEMENTS.md#L106]
One proposed a field that the existing friendly URL made unnecessary; the other dismissed an endpoint as a new subsystem when that subsystem had already shipped. Both times the task became smaller once the section was checked against the code. The ledger states it as "A design section can carry a stale premise and ship drops it in silence" [roadkeep@91754240:docs/CHANGELOG.md#L130]. The repository in which the block was measured is not named. The line format that keeps the symptom apart from the design is "never a solution name" [roadkeep@91754240:docs/ROADMAP.md#L17-L21].
- polyweave. Two occasions on 2026-09-23. For PW73, "The first reading was that cp1252 cannot hold an em dash" [polyweave@f203b0a],
which was wrong: "What reads the pipe decodes UTF-8" [polyweave@f203b0a]. The lint rule the design leant towards "would have enforced the wrong thing" [polyweave@f203b0a], and the change PW71 had shipped an hour earlier was reverted. The task line survived: "the premise was false, not the observation" [polyweave@f203b0a]. For PW63, "The design proposed a declared range, and measuring it is what settled the line the other way." [polyweave@7024e7e]
- winwright. WW249 was implemented, measured and reverted: "take the per-code-unit send back out, the rate did not move" [winwright@5012473].
Independence
At least three origins. polyweave and winwright each record their own occurrence (rule 1). roadkeep's record is of a repository it does not name; it is dated 2026-08-05, before polyweave's first commit and before winwright's, so it is not either of those. Whether it is Shio, roadkeep itself or a repository outside the corpus cannot be told from the source, so it is counted once. The symptom-not-solution format is one remedy, roadkeep's.
Counter-evidence
Designs also survived measurement. In polyweave PW45 measured parallel against serial sampling and the result was "Which is what the design predicted" [polyweave@871a15b]. No source gives a rate of overturned designs except RK310's two in one block of eleven tasks, and that block's repository is unknown. That the symptom line "held" is stated only in polyweave (f203b0a); the other observations record the design failing, not the line surviving.
Grade
R3: independent occurrences in at least three projects. S3: roadkeep's record counts two overturned sections in a block of eleven tasks. The polyweave and winwright observations are dated incidents (S2). Not S4: nothing checks a design against the code before it is claimed.