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.

implement/agents/implementer.md

@@ -30,14 +30,15 @@ disappears.
 
 ## Standing reading list
 
-Read the files configured under `standing_reading.always`
-plus `standing_reading.by_role.implementer` in the project
-profile. The defaults include `CLAUDE.md` for orchestrator
-framing and the project's design ledger (if configured) for
-the binding architectural decisions.
+The standing reading is fixed: `CLAUDE.md` plus
+`git log -10 --format=full` (see docs/conventions.md). On top
+of that, read the per-role standing reading the project lists
+in its CLAUDE.md project facts for `implementer`. `CLAUDE.md`
+gives the orchestrator framing, and the project's design
+ledger (if it has one) the binding architectural decisions.
 
 You do **not** open plan or spec files under
-`paths.plan_dir` / `paths.spec_dir` directly. The controller
+`docs/plans` / `docs/specs` directly. The controller
 has already extracted what you need from them and hands it
 to you via the carrier (see below). If something is missing
 from the carrier, that is a `NEEDS_CONTEXT` situation —
@@ -82,8 +83,8 @@ to enforce the discipline anyway.
 Exceptions where RED-first does not apply:
 
 - Pure refactors with no behaviour change — existing tests
-  are the verification; if the project's `commands.test`
-  is green pre and post, you're fine.
+  are the verification; if the project's test command (its
+  CLAUDE.md project facts) is green pre and post, you're fine.
 - Test-only tasks — you ARE writing the test, so no
   separate RED step.
 - Doc / comment / formatting changes.
@@ -94,8 +95,8 @@ is yes — write the test.
 ## Architecture rules
 
 The binding architectural rules of the project are declared
-in `CLAUDE.md` and (if the project has one) the design
-ledger at `paths.design_ledger`. The specific rules are
+in `CLAUDE.md` and (if the project has one) its design
+ledger. The specific rules are
 project-specific, but they typically cover:
 
 - **Determinism contracts.** Canonical forms, sort orders,
@@ -149,8 +150,8 @@ substitute.
    - **REFACTOR** (optional, only if the diff has
      duplication or unclear names): clean up while keeping
      the test green. Don't add behaviour.
-6. **Verify** with the project's `commands.build` and
-   `commands.test`. Both MUST be green. The test you wrote
+6. **Verify** with the project's build and test commands
+   (its CLAUDE.md project facts). Both MUST be green. The test you wrote
    in RED MUST pass; no other test may regress.
 7. **Property doc comment.** The new test's doc comment
    names the property it protects, not just what it
@@ -225,7 +226,7 @@ know to unblock you, and stop. Do not implement on a hunch.
 | "The plan mentions a helper I should reuse but I'll inline it for now" | Cross-task context says use the helper. Use the helper. Inlining "for now" creates the duplication the plan tried to avoid. |
 | "Task says 'add function X' — plan didn't script a test, so I'll just write X" | TDD is independent of the plan. If the task adds behaviour, RED-first applies even if the plan template forgot it. Add the test inline; report the plan gap. |
 | "I wrote the test after the function but it tests the same thing — same outcome" | No. Tests-after pass immediately and prove nothing about whether the test would have caught the bug pre-implementation. Delete the function, write the test, watch it fail, then write the function. Spirit-not-ritual is the exact rationalisation TDD is built to defeat. |
-| "Refactor only — no test, no verification" | Wrong half. No new test, but `commands.test` MUST still pass. A "refactor" that breaks an existing test is a behaviour change you didn't notice. |
+| "Refactor only — no test, no verification" | Wrong half. No new test, but the project's test command MUST still pass. A "refactor" that breaks an existing test is a behaviour change you didn't notice. |
 
 ## Red Flags — STOP
 
@@ -238,11 +239,11 @@ know to unblock you, and stop. Do not implement on a hunch.
 - About to report `DONE` while a concern is unspoken
 - About to substitute a "better" approach for the one in
   the task block at `task_text_path`
-- About to open `paths.plan_dir` or `paths.spec_dir` files
+- About to open `docs/plans` or `docs/specs` files
   directly when the file at `task_text_path` should already
   contain what you need
 - About to write production code while the corresponding
   RED test does not yet exist (or has not yet been run +
   observed to fail)
 - About to mark a refactor `DONE` without re-running the
-  project's `commands.test`
+  project's test command