T01: establish canonical milestone sequence, record F-0001

Three documents defined conflicting milestone sequences; an unqualified
reference to e.g. 'M2' was ambiguous across the corpus.

- docs/TestDriverInitialMilestones.md (M0-M10) is now canonical
- INTENT.md and ConceptModel section 15 carry superseded banners plus a
  mapping table rather than being deleted
- canonical order is explicitly distinguished from execution order
- research/findings/ established; F-0001 filed as CONCEPT_DRIFT, resolved
  via path 2 (concept deliberately revised), with one residual for T10

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1629012@bnt-lap001
Assistant-Session: 78d4fb13-8a1e-474b-87a3-9b9261c49a39

research/findings/F-0001-milestone-sequence-drift.md

@@ -0,0 +1,77 @@
+---
+id: F-0001
+type: framework-finding
+class: CONCEPT_DRIFT
+status: resolved
+discovered: "2026-08-22"
+resolved: "2026-08-22"
+discovered_by: concept-assessment
+source: history/2026-08-22-concept-assessment-swot.md
+workplan: TD-WP-0002
+task: TD-WP-0002-T01
+---
+
+# F-0001 — Three conflicting milestone sequences
+
+## Class
+
+`CONCEPT_DRIFT` — the repository carried three mutually inconsistent statements
+of the same concept, with no explicit decision revising any of them.
+
+Note the unusual shape: §5 of the Improvement Loop defines concept drift as
+*implementation* diverging from concept. Here there was no implementation at all.
+The drift was **document-to-document**, which the taxonomy does not currently
+name. See "Residual" below.
+
+## Observation
+
+Three documents each defined a milestone sequence for the same project:
+
+| Document | Sequence |
+|---|---|
+| `INTENT.md` § Initial Milestones | M0–M3 |
+| `docs/TestDriverConceptModel.md` § 15 | M0–M3 (different content) |
+| `docs/TestDriverInitialMilestones.md` | M0–M10 |
+
+The two M0–M3 sequences disagreed with each other and both disagreed with the
+M0–M10 sequence. `M2`, for instance, denoted "Adaptation and Crystallization" in
+one document and "Test-Driver Lab" in another — so an unqualified reference to
+"M2" was ambiguous across the corpus.
+
+## Why it matters
+
+The project's own thesis is that implementations must not silently redefine
+intended behaviour, and that concept drift is a first-class finding. The corpus
+exhibited the failure it was written to prevent, before a single line of code
+existed. Left unresolved, every subsequent milestone reference in commits,
+workplans and evidence would have been ambiguous.
+
+## Resolution
+
+Path 2 of §5 — *the concept is deliberately revised*.
+
+`docs/TestDriverInitialMilestones.md` (M0–M10) is now **canonical**. It is the
+most complete of the three, is the only one carrying exit criteria and success
+metrics, and is the only one that names the lab, self-verification, the
+improvement loop and the compression review.
+
+The other two sections were replaced in place with a superseded banner and a
+mapping table rather than deleted, so that references from earlier commits and
+from `history/` remain interpretable.
+
+Execution order is deliberately *not* the canonical order:
+`workplans/TD-WP-0002-vertical-spike-crystallization.md` drives one thin thread
+through canonical M1–M7 rather than completing each milestone in turn. Canonical
+sequence and execution sequence are now distinct and separately stated.
+
+## Residual
+
+The finding taxonomy (§9) has no class for divergence **between concept
+documents** — `CONCEPT_DRIFT` is defined as implementation-vs-concept. This
+finding was classified `CONCEPT_DRIFT` as the nearest fit.
+
+Carry into `TD-WP-0002-T10` (compression review): either widen `CONCEPT_DRIFT`
+to cover intra-conceptual inconsistency, or accept that pre-implementation
+document drift is not a framework finding at all and should be handled as
+ordinary editorial hygiene. Do not add a new finding class before that question
+is answered — the taxonomy is already larger than the evidence supporting it.

research/findings/README.md

@@ -0,0 +1,19 @@
+# Framework Findings
+
+Findings about **test-driver itself**, kept strictly separate from findings about
+any system under test. Classes are defined in
+`docs/TestDriverImprovementLoop.md` § 9:
+
+`PRODUCT_DEFECT` · `TEST_DEFECT` · `MECHANICAL_ADAPTATION` · `SEMANTIC_CHANGE` ·
+`CONCEPT_DRIFT` · `FRAMEWORK_LIMITATION` · `EVIDENCE_FAILURE` ·
+`UNNECESSARY_COMPLEXITY`
+
+File naming: `F-NNNN-<slug>.md`. Identifiers are stable and never reused.
+
+Each finding carries frontmatter (`id`, `class`, `status`, dates, originating
+workplan/task) and, when resolved, states which of the three §5 resolution paths
+was taken. A finding that leaves an open question records it under "Residual" and
+names the task that will answer it — residuals are not parked in prose.
+
+The wider research control plane (`hypotheses/`, `experiments/`, `concepts/`,
+`decisions/`) is built in `TD-WP-0002-T03`.