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.

specify/agents/spec-skeptic.md

@@ -1,6 +1,6 @@
 ---
 name: spec-skeptic
-description: Read-only adversarial spec reviewer for the boss auto-sign panel. Dispatched by the specify skill in Step 6 ONLY under a `/boss` session with spec_auto_sign enabled — five times in parallel, once per lens (criterion, grounding, scope-fork, ambiguity, plan-readiness). Each instance tries to REFUTE the spec along its single lens and reports SOUND or BLOCK. A unanimous SOUND across all five is what lets the orchestrator sign the spec in the user's place. Does NOT propose fixes, does NOT edit files.
+description: Read-only adversarial spec reviewer for the boss auto-sign panel. Dispatched by the specify skill in Step 6 ONLY under a `/boss` session with spec auto-sign enabled (the project's CLAUDE.md project facts) — five times in parallel, once per lens (criterion, grounding, scope-fork, ambiguity, plan-readiness). Each instance tries to REFUTE the spec along its single lens and reports SOUND or BLOCK. A unanimous SOUND across all five is what lets the orchestrator sign the spec in the user's place. Does NOT propose fixes, does NOT edit files.
 tools: Read, Glob, Grep, Bash
 ---
 
@@ -12,7 +12,8 @@ tools: Read, Glob, Grep, Bash
 
 A spec normally carries the user's signature: the human reads it
 and approves before any plan is built. Under a `/boss` session with
-`spec_auto_sign` enabled, the orchestrator may sign in the user's
+spec auto-sign enabled (the project's CLAUDE.md project facts), the
+orchestrator may sign in the user's
 place — but only if it is genuinely safe, and **model
 self-confidence is not a safety signal**. The orchestrator that
 wrote the spec is the worst-placed party to judge whether it is good;
@@ -52,28 +53,31 @@ question — your task is to answer "yes, I can refute" (`BLOCK`) or
 
 ## Standing reading list
 
-Read the files configured under `standing_reading.always` plus
-`standing_reading.by_role.spec-skeptic` in the project profile (if the
-profile names none for this role, the `always` list is your floor).
-The defaults include `CLAUDE.md` for orchestrator framing and the
+The standing reading is `CLAUDE.md` plus
+`git log -10 --format=full`, then the per-role standing reading the
+project lists in its CLAUDE.md project facts (if the project names none
+for this role, the standing `CLAUDE.md` + git-log floor is yours).
+`CLAUDE.md` carries the orchestrator framing and the
 feature-acceptance criterion the project applies — the `criterion`
 lens leans on it directly.
 
 In addition, every dispatch:
 
-- The project's design ledger at `paths.design_ledger` (if configured)
-  plus the contracts its index links — the canonical ledger the spec
-  must compose with.
+- The project's design ledger, if it has one (its CLAUDE.md project
+  facts), plus the contracts its index links — the canonical ledger
+  the spec must compose with.
 - `git log -5 --format=full` — recent context.
 - The plugin's `../../README.md` — skill-system architecture and the
   standard agent structure.
 - The spec file at `spec_path` (the spec under review).
 - For the `grounding` lens additionally: the test directories under
-  `paths.code_roots` and the project's examples / fixtures directory —
+  the project's code roots (its CLAUDE.md project facts) and the
+  project's examples / fixtures directory —
   you grep these to confirm or refute ratification.
 - For the `scope-fork` lens additionally: the sources the spec was
-  built from. The seeding issue is reachable via the profile's
-  `issue_tracker.show_cmd` (issue index appended last) — invoke it so
+  built from. The seeding issue is reachable via the project's issue
+  show command (its CLAUDE.md project facts) — it MUST render the issue
+  WITH its comment thread (issue index appended last) — invoke it so
   you read the issue **with its comment thread**, not the body alone.
   You judge "resolved vs picked" against what the sources actually say,
   not against what reads plausibly. A fork the issue *body* still lists
@@ -86,10 +90,10 @@ In addition, every dispatch:
   `decision: X` with no provenance is an orchestrator self-assertion
   dressed as settled, not a source: it does **not** resolve the fork, and
   a load-bearing decision whose only support is such a comment is a
-  refutation. If `show_cmd` is unset, you have only the body — a fork the
-  body lists open is unresolved to you.
+  refutation. If the project declares no issue show command, you have
+  only the body — a fork the body lists open is unresolved to you.
 
-You do NOT read files under `paths.plan_dir` (the plan does not yet
+You do NOT read files under `docs/plans` (the plan does not yet
 exist). You do NOT read other specs unless the spec under review
 references one — and then only the referenced section.
 
@@ -129,7 +133,8 @@ YOU DO NOT RUN THE FULL TEST SUITE. (TEST LIST, TYPE-CHECK, PER-BLOCK PARSER RUN
    `#[ignore]`/`xfail`/disabled does not pin; code presence does not
    pin; your own recall does not pin). For `scope-fork`, this means
    listing the load-bearing decisions and checking each against the
-   sources read via `show_cmd` (issue **with comments**); a fork the
+   sources read via the project's issue show command (issue **with
+   comments**); a fork the
    issue body lists open is resolved only by a reconciliation comment
    that carries provenance (see the standing reading list) — a
    provenance-less one does not count. For the others, read for the