Version M-006 legacy-robot parity evidence

.agents/skills/clue-analysis/references/analysis-workflow.md

@@ -9,5 +9,6 @@ Use when a change has unclear risks or unknowns — **before** planning or imple
 5. Run a **spike**: a throwaway investigation such as a prototype, measurement, or literature scan. Spikes are disposable; their findings are not.
 6. End every spike with a findings document in `/docs/analysis/` (`AN-xxx-slug.md`, frontmatter: `id`, `type: analysis`, `status`, `links`, `title`). Include what was tried, what was rejected, and why; discarded options are half of why the system looks as it does.
    - If the finding is an incident where the corpus was green but reality proved a claim wrong, add `reality: contradicted` and link every failed capability or acceptance criterion as well as the decisions, constraints, or process carriers that failed to prevent it. This records the edge from reality; it does not ingest production telemetry or open the operations loop.
+   - When the findings reach a durable artifact — an architecture or design overview, a decision, a capability — record that in `carried-by:` naming those artifacts. A spike is a measurement pinned to the revision it observed, so it is not permanent truth; the field is what lets `clue migrate` later report the spike as spent, once every plan it serves is complete and no live decision or constraint still cites it. A standing rule whose evidence is gone is readable but no longer reviewable, so a citation keeps the spike; where the citation is provenance rather than evidence, remove it from the live record first. Retiring it then deletes the file in a reviewed change, with Git history as the archive. Never hollow a spike out into a stub: that keeps the index row, the link targets, and the reader's navigation cost while removing the only part with value.
 7. Route any outcome that constitutes a decision under [Decision records](decision-records.md). A rejected alternative that is itself a decision gets a rejected decision record, not only a paragraph in the findings.
 8. Feed findings to `clue-plan` or `clue-delta`. Analysis with no consumer is doc-slop; do not write it.

.agents/skills/clue-analysis/skill.md

@@ -1,6 +1,6 @@
 ---
 cliewen-skill: true
-version: 0.21.0
+version: 0.24.1
 ---
 
 <!-- Generated from Cliewen's canonical skill sources; edit those sources, not this file. -->

.agents/skills/clue-delta/references/change-loop.md

@@ -2,7 +2,7 @@
 
 Use when the user chooses the full Cliewen loop recommended for accepted-contract change. Simple work is recommended before this skill and does not invoke it. Apply [Decision records](decision-records.md), [Repository-local conventions](repository-local-conventions.md), and [Durable work state](durable-work-state.md) throughout the loop.
 
-1. **Branch:** Follow the review boundary, get the next CH identity with `clue id next CH`, and name the branch `ch-xxx-slug` with that identity.
+1. **Branch:** Follow the review boundary, get the next CH identity with `clue id next CH`, and name the branch `ch-xxx-slug` with that identity. The command follows the ledger's tracked coordination mode. When it warns that allocation is local and contributors may work in parallel clones or worktrees, stop and either serialize allocation on the integration branch or have a maintainer enable Git coordination with `clue id coordinate` before contributors branch. A contributor given a preallocated identity runs `clue id sync`, uses that reservation, and never allocates independently from a stale local ledger. If remote allocation fails, do not guess, reuse, or edit the number by hand; retry or sync the allocator's permanent claims. Coordination settings live in `.clue/id-coordination.yaml`, not in the ledger; commit both after `clue id coordinate`, and treat a merge conflict in that file as the user's decision about which remote the team meant, never yours to resolve. Never re-point an established repository at a different remote. When a command reports that Git's union merge combined the ledger, the identities are intact: run `clue id repair`, or let the next command that saves the ledger rewrite it, and never hand-edit an append-only log. If two artifacts hold one identity, allocate a fresh one for the later artifact and update its references rather than renumbering either by hand.
 2. **Propose:** Create `/changes/CH-xxx-slug/`, commit and push it before implementation, and open the draft PR under the review boundary:
    - `proposal.md` states what and why; its frontmatter `links` names the real plan item it serves or explicitly declares the change plan-less.
    - `tasks.md` is an ordered `- [ ]` checklist with dependencies first and at most one nested level. Mark an infeasible task `[-]` with its reason on the same line, whenever it is marked. A behavior-changing task names the acceptance-criterion IDs it serves; if none exists, add the criterion before implementation. Tests trace to criteria, never transient tasks.

.agents/skills/clue-delta/references/intent-model.md

@@ -0,0 +1,41 @@
+## Intent model
+
+A corpus carries two threads, and they meet only at the goal.
+
+The **intent thread** says what the product means: `VIS-001` (the vision, at `docs/vision.md`) → goal → optional use case → capability → acceptance criterion → evidence. The **delivery thread** says how that meaning gets built: goal → plan → milestone → change → accepted merge commit. Plan, milestone, and change never join the semantic hierarchy, which is what keeps a change from editing the vision merely because it edited code.
+
+Each artifact answers one question, and none of them answers another's. A **goal** says who wants something and why. A **use case** says what one actor does, end to end, across capabilities. A **capability** says what the system can do. An **acceptance criterion** says what would prove it. A vision that lists goals, a use case that restates criteria, or a capability that argues for its own existence has taken over a neighbour's job — link instead of repeating.
+
+**Both intent artifacts are optional to have.** `clue validate` never requires a vision or a use case, never reports one missing as an issue, and computes no coverage figure over either; absence is not a gap. Run `clue validate --intent` to see what a corpus states.
+
+**Links point down.** A use case names the goal it serves and every capability it crosses; a goal names the vision. A capability never names a use case back, so no edge is written twice and none can drift. Reading it the other way is `clue context <id>`, which names the use cases reaching an artifact by identity and title without following them.
+
+### The vision
+
+One per corpus, roughly one screen, at `docs/vision.md`. It answers what the product or system is, whom it serves, what problem it addresses and what value it intends to create, what is in scope and what is deliberately out, what principles constrain its direction, how success would be recognized, and which assumptions are still uncertain. It is not a roadmap, a backlog, an architecture document, a requirements list, or a marketing statement, and it needs no business case.
+
+Edit it only when the direction itself changes. Restating a new feature there is how a vision becomes a changelog and stops being read.
+
+### When a use case is worth creating
+
+Write one when it changes what a reader understands:
+
+- an actor's journey crosses several capabilities;
+- ordering, interaction, alternatives, or failure recovery carries meaning;
+- the individual criteria are each locally correct and still do not explain the outcome;
+- several actors collaborate through the system;
+- a brownfield system holds important behaviour no single capability explains.
+
+Do not write one when a capability and its criteria already describe the behaviour clearly, when there is no meaningful actor interaction, when it would restate an existing goal or capability, or when the subject is internal implementation behaviour that design, architecture, a constraint, or an IDR owns. Never create one for trivial create-read-update-delete behaviour to satisfy a process, and never let one grow into a design or prescribe interface details that are not themselves accepted intent.
+
+Recommend for or against one, say why, and let the human decide. A use case is created because it earns its place, never because a capability lacks one.
+
+### Its shape
+
+`docs/use-cases/UC-<number>-<slug>.md`, `type: use-case`, links naming the goal and the capabilities it crosses, and four sections: `## Actors`, `## Trigger`, `## Main flow`, `## Outcome`. Add preconditions, alternative and failure flows, and open questions when they carry meaning; leave them out when they do not.
+
+### Marking what is not yet confirmed
+
+Agent-drafted intent is `status: draft` with `provenance: inferred` and a stated `reversal-cost`, and its assumptions and open questions stay visible in the artifact. Promotion is a human act. Never present an inference as a fact, and never resolve a contradiction between sources by picking the convenient reading — record it and ask.
+
+**A full change's acceptance brief states the vision it proceeds under**, or states that the repository has none and that the change proceeds without one. When unresolved meaning would materially change what the system is for, stop and ask rather than deciding it inside an implementation.

.agents/skills/clue-delta/references/repository-local-conventions.md

@@ -1,3 +1,5 @@
 ## Repository-local conventions
 
+Before applying a rule that differs by repository kind, read the role in `.clue/role.yaml`. `role: adopter` is a repository that has adopted Cliewen; `role: source` is Cliewen's own repository, which generates the skills and templates adopters receive and therefore carries rules no adopter ever inherits. A repository with no marker is an adopter. Do not infer the role from a directory listing, and do not apply a source-repository rule to an adopter's work.
+
 For a full Cliewen change, apply the repository-local conventions declared in AGENTS.md, including digest requirements such as a user-facing changelog entry. When a release adds or narrows a corpus obligation, preview and apply the supported `clue migrate` migrations before validating the adopted repository; `clue init` remains a non-destructive materializer, not an updater. Simple work follows the repository conventions and checks that apply to its changed surfaces. Repository-local conventions may be stricter about integration. If a full-loop skill conflicts with a local rule, record the conflict in `open-questions.md` and stop for a human decision; never choose silently.

.agents/skills/clue-delta/references/review-boundary.md

@@ -14,7 +14,7 @@ A PR alone displays hosted CI but does not enforce it. Where hosting supports en
 
 Every review of an existing hosted PR is bound to its observed head SHA. A clean result applies only to that commit; every substantive edit invalidates it. An advisory from a pass with no blocking findings stays in the verification handoff for a later change rather than editing the clean commit: the bounded loop is over, and an edit would create a new candidate that this exact-commit rule requires reviewing. A blocking finding is actionable durable PR state, not private agent memory: where the host supports resolvable review conversations, publish the finding there and leave it unresolved until a hosted commit contains the reviewed repair. Advisories do not become repair-required conversations. If the reviewer cannot publish a resolvable finding, report the PR as not merge-ready and disclose that the host cannot enforce the finding; this fail-safe applies to blocking findings, while advisories stay in the handoff; never claim a chat-only finding has equivalent protection.
 
-Any agent that edits an existing PR becomes the updater for that turn. Before editing, fetch the PR and record its hosted head; push only normal fast-forward updates, never force. If the head changed underneath the turn or a push is rejected as non-fast-forward, fetch and reconcile without overwriting remote work, then rerun verification and review on the resulting commit. A repair pushed to a ready PR returns it to draft until the repaired head has its own verification and clean review pass. If accepted `main` advances while the change is open, incorporate it by merging `main` into the change branch with a normal push, never by rewriting hosted history, then repeat verification and review. If the PR merged or closed, stop without pushing — the one case where a turn ends unpushed — report the work and where it stands, and never create a follow-up change without explicit human scope.
+Any agent that edits an existing PR becomes the updater for that turn. Before editing, fetch the PR and record its hosted head; push only normal fast-forward updates, never force. If the head changed underneath the turn or a push is rejected as non-fast-forward, fetch and reconcile without overwriting remote work, then rerun verification and review on the resulting commit. A repair pushed to a ready PR returns it to draft until the repaired head has its own verification and clean review pass. If the PR merged or closed, stop without pushing — the one case where a turn ends unpushed — report the work and where it stands, and never create a follow-up change without explicit human scope.
 
 Ready means the hosted PR contains the exact locally reviewed and verified state, and marking it ready is the only claim of readiness. Before marking a change ready, commit every intended edit, run the applicable local verification and a clean agentic review pass against that commit, require `git status --porcelain` to be empty, push, and confirm that the hosted PR's head branch and SHA equal the current local branch and `HEAD`; then mark the PR ready and perform the hosted check again immediately after. Resolve satisfied review conversations only after the hosted head contains their reviewed repair. If either side differs, apply the updater rule above, rerun verification and review on the resulting commit, and check again. Stopping anywhere else is ordinary, not an exception: the branch is pushed, the PR is a draft, and no claim of readiness exists — say where the work stands rather than that a ready PR exists.
 

.agents/skills/clue-delta/skill.md

@@ -1,6 +1,6 @@
 ---
 cliewen-skill: true
-version: 0.21.0
+version: 0.24.1
 ---
 
 <!-- Generated from Cliewen's canonical skill sources; edit those sources, not this file. -->
@@ -16,6 +16,7 @@ Read each reference when its condition is reached, before taking action governed
 - Before recommending a route or starting a full change, read [Change routing](references/change-scope-and-tiers.md).
 - Before branching, publishing, updating a hosted PR, or handing work to a human, read [Review boundary](references/review-boundary.md).
 - After the user chooses the recommended full loop, read [Change loop](references/change-loop.md).
+- When the change touches what the product means, or the acceptance brief must state the vision it proceeds under, read [Intent model](references/intent-model.md).
 - When the change makes, rejects, or carries a decision, read [Decision records](references/decision-records.md).
 - Before applying repository-specific implementation or digest rules, read [Repository-local conventions](references/repository-local-conventions.md).
 - When a change starts or resumes, a suggestion arrives, or a merge is reported, read [Durable work state](references/durable-work-state.md).

.agents/skills/clue-extract/mappings/madr.md

@@ -25,6 +25,4 @@ Layout: decision records live in `docs/decisions/` or `doc/adr/`, one file per r
 | older Nygard headings (`## Status`, `## Context`, `## Decision`, `## Consequences`) | `## Status` converts per the status-vocabulary rows above; `## Context` and `## Decision` become `## Context and problem statement` and `## Decision outcome`; `## Consequences` folds into body prose under Decision outcome or its own trailing sentence |
 | Hand-maintained per-folder index (`INDEX.md`, `index.md`, a `## Contents` table) | absorbed into that folder's README `clue:index` rows, then deleted — the description, purpose, or scope column becomes the row's sentence, while a column that only restates a `links:` edge (a design or related-decision pointer) is dropped rather than carried |
 
-Worked case: Robocode Tank Royale, a public repository extracted through `clue-extract` in 2026. Its decision corpus is what these rows are written against — 41 records in one `docs/decisions/` folder beside that folder's `README.md` and `log.md`, every record carrying a numeric filename prefix, five written to the MADR template headings and the rest to Nygard's `## Context` / `## Decision` / `## Consequences`. That conversion happened before this mapping existed, and it is where the `decision-makers` row above comes from: it wrote the records' own pre-Cliewen acceptance into `accepted-by:` (annotated `pre-Cliewen MADR acceptance`) and left them `status: verified`, so the corpus now shows approvals no human ever gave under its merge boundary. It also carried the source padding into the IDs themselves, which is the form that corpus now keeps — an already-converted corpus is never re-styled, per the numeric-prefix row above. The rows above are what that conversion would have followed.
-
 Watch for: a folder mixing MADR and Nygard records side by side, where only some files carry frontmatter; a `superseded by` reference written three ways (a plain-prose mention in the Decision Outcome section, a `superseded-by:` frontmatter key, or an inline link to the successor file) that all mean the same `links:` edge; a record's number reused across `doc/adr/` and `docs/decisions/` from a past folder migration; a `proposed` record nobody ever acted on, which is an open question rather than a decision the merge would make binding; and the temptation to write `decision-makers` straight into `accepted-by:` because the names are already there — the shortcut looks harmless but a converted record's `accepted-by:` has to mean the same thing as every other record's.