refactor: drop dev-cycle-profile.yml for conventions + CLAUDE.md facts

The profile was never parsed — it was prose the skill bodies told the model to read, so most slots were dead, constant across every project, or fiction (the whole pipeline block, including the "tdd is opt-in" claim, was enforced by nothing).

Split it in two: constants become fixed conventions named directly by the skills (new docs/conventions.md), and the few genuinely per-project facts move to each project's CLAUDE.md under '## Skills plugin: project facts'. tdd/fieldtest/docwriter are now always available; the only behavioural toggle left is spec auto-sign.

Delete docs/profile-schema.md and templates/project-profile.yml; add docs/conventions.md and a project-facts section to templates/CLAUDE.md.fragment; rewrite all SKILL/agent prose and the pipeline/design/migration/README/INSTALL docs accordingly.
This commit is contained in:
2026-06-13 16:30:02 +02:00
parent 268ee705f4
commit 26e9630496
40 changed files with 752 additions and 894 deletions
+6 -4
View File
@@ -20,7 +20,7 @@ debt — even when audit reports `clean`.
The skill produces a friction-and-bug spec that the next
iteration's `planner` consumes as a reference. The spec sits
next to cycle-design specs under `paths.spec_dir`, with a
next to cycle-design specs under `docs/specs`, with a
`fieldtest-` prefix in the slug.
The substantive process — read the design ledger + cycle spec
@@ -29,7 +29,8 @@ per cycle axis, implement each as a downstream consumer, run
the result, classify findings, write the spec — lives in
`agents/fieldtester.md`. That file also carries the spec
template, the source-isolation discipline (no reading under
`paths.code_roots` or `paths.bench_dir`), and the per-finding
the project's code roots or its benchmark directory, if it has
one — its CLAUDE.md project facts), and the per-finding
classification rules. This skill file only governs trigger,
dispatch, and handoff.
@@ -106,8 +107,9 @@ EVERY FRICTION POINT AND BUG IS RECORDED. NONE IS WORKED AROUND.
The first clause is load-bearing: the whole point of the
field test is to simulate a downstream consumer who has only
the public interface. The agent file enforces this with a
hard path allowlist (computed from `paths.public_interface`
in the profile); the orchestrator must trust that contract
hard path allowlist (computed from the project's public
interface, if it has one — its CLAUDE.md project facts); the
orchestrator must trust that contract
and not feed the agent implementation-internal hints in the
carrier.
+33 -29
View File
@@ -34,20 +34,22 @@ is for. Diagnostic unclear is *the finding*. Spec silent is
## Standing reading list
Read the files configured under `standing_reading.always`
plus `standing_reading.by_role.fieldtester` in the project
profile. The defaults include `CLAUDE.md` for role boundaries.
Always read `CLAUDE.md` (for role boundaries) and
`git log -10 --format=full`, plus the per-role standing reading
the project lists in its CLAUDE.md project facts for the
fieldtester role.
In addition, you may read **only** files under the paths
configured in `paths.public_interface` in the project profile.
In addition, you may read **only** files under the project's
public interface, if it has one (its CLAUDE.md project facts).
This is the project's outward-facing surface (typically:
README, the design ledger at `paths.design_ledger` if any,
the docs directory, the examples corpus). You may NOT use
the examples as a hint about how the implementation handles
edge cases; only as a hint about the shape of the surface.
README, the design ledger if any, the docs directory, the
examples corpus). You may NOT use the examples as a hint about
how the implementation handles edge cases; only as a hint about
the shape of the surface.
You may also read fixtures you yourself create under
`paths.fieldtest_examples`, plus any artefacts you produce
You may also read fixtures you yourself create under the
project's fieldtest examples directory, if it has one (its
CLAUDE.md project facts), plus any artefacts you produce
by running the project (binaries, output files, generated
IR, etc.).
@@ -69,7 +71,7 @@ skill references it rather than restating it.
| `commit_range` | `<prev-cycle-close>..HEAD` |
If `axis_hints` is empty, infer from the cycle's spec under
`paths.spec_dir` and the most recent iter commit bodies; if
`docs/specs` and the most recent iter commit bodies; if
both are also empty, return `NEEDS_CONTEXT`.
### Milestone-scope variant
@@ -105,13 +107,13 @@ RECORD WHAT HAPPENS. DO NOT FIX. DO NOT WORK AROUND.
The first clause is what makes this dispatch a field test
rather than yet another internal review. If you are about to
read anything under `paths.code_roots` or `paths.bench_dir`
(from the project profile), **stop**.
read anything under the project's code roots or its benchmark
directory (its CLAUDE.md project facts), **stop**.
The paths you may open are exactly:
- Files under `paths.public_interface` (from the profile)
- Files under `paths.fieldtest_examples` that **you** create
- Files under the project's public interface (its CLAUDE.md project facts)
- Files under the project's fieldtest examples directory that **you** create
- Artefacts you produce by running the project (binaries,
output files, generated IR if exposed as part of the public
interface)
@@ -147,9 +149,9 @@ Each phase completes before the next starts.
current working tree.** A field test that runs a stale pre-built binary
silently inverts its own purpose: it reports the *previously shipped*
state as current, producing false positives on already-fixed bugs and
masking newly-introduced ones. Run the build command from
`commands.build` (or build the specific consumer binary the examples
invoke) and confirm it succeeds before Phase 2 step 1; if the examples
masking newly-introduced ones. Run the project's build command (its
CLAUDE.md project facts) — or build the specific consumer binary the
examples invoke and confirm it succeeds before Phase 2 step 1; if the examples
invoke a release binary, build the release profile, not just debug. When
in doubt, invoke the tool through the build system (e.g. `cargo run`)
rather than a path to a pre-existing artefact, so HEAD is always what
@@ -164,8 +166,9 @@ For each example, in this order:
tool, etc.). Reach for the cycle's new surface where it
fits naturally — but do not contort an example to use a
feature that doesn't fit.
2. Save under `paths.fieldtest_examples` with a name
like `<cycle-short>_<n>_<slug>.<ext>`.
2. Save under the project's fieldtest examples directory (its
CLAUDE.md project facts) with a name like
`<cycle-short>_<n>_<slug>.<ext>`.
3. Run the project the way a user would. Record the exact
commands, the exact output, the exact errors.
4. Record verbatim:
@@ -208,8 +211,9 @@ not merged.
### Phase 5 — Write the spec, hand back
Write the fieldtest spec under `paths.spec_dir` with a name
shape per the project's naming convention. Use the spec
Write the fieldtest spec under `docs/specs` with a name
following the `NNNN-slug.md` convention (4-digit prefix,
per-directory; see `docs/conventions.md`). Use the spec
template below. Leave all artefacts (the fixtures and the
spec file) in the working tree as unstaged changes. You do
NOT commit — the orchestrator commits after reading the
@@ -280,7 +284,7 @@ At most 350 words, structured:
+ outcome (built? ran? matched expected?).
- **Findings count by class:** e.g.
`bugs: 1, friction: 2, spec_gap: 1, working: 3`.
- **Spec path:** under `paths.spec_dir`.
- **Spec path:** under `docs/specs`.
- **Per-finding recommendation:** `bug → debug`,
`friction → plan` (tidy iteration),
`spec_gap → ratify` or `tighten the design ledger`,
@@ -298,7 +302,7 @@ fields are:
| Field | Content |
|-------|---------|
| `spec_path` | spec file under `paths.spec_dir` with a `fieldtest-` prefix |
| `spec_path` | spec file under `docs/specs` with a `fieldtest-` prefix |
| `examples_added` | list of fixture paths committed |
| `findings` | list, each with class (`bug` / `friction` / `spec_gap` / `working`) + recommendation |
@@ -309,8 +313,8 @@ fields are:
- Refactors of existing fixtures in the examples corpus.
- Edits to any file under the design ledger or specs
directory. Spec gaps are reported, not patched.
- Edits to anything under `paths.code_roots` or
`paths.bench_dir`.
- Edits to anything under the project's code roots or its
benchmark directory (its CLAUDE.md project facts).
- A `friction` finding without a 1-line recommendation.
Every finding is actionable or it isn't a finding.
- An "all-clean" report on a cycle that touched user-visible
@@ -333,8 +337,8 @@ fields are:
## Red Flags — STOP and re-read the public interface
- About to open any path under `paths.code_roots` or
`paths.bench_dir`
- About to open any path under the project's code roots or its
benchmark directory (its CLAUDE.md project facts)
- About to open an implementation-source file at all
- About to hand-author an intermediate representation,
internal serialisation, or any non-canonical fixture form