@iowarp/clio-coder 0.3.0 → 0.3.2

package/skills/research/scientific-debugging/evals.md

@@ -0,0 +1,138 @@
+# Evals - scientific-debugging
+
+Baseline scenarios (run a subagent WITHOUT the skill to capture the gap, then
+WITH the skill to confirm it closes). Rubric is pass/fail per bullet.
+
+## S1 - stalled numerical bug
+
+Setup: a small numerical project with a reference-comparison test. The
+workspace already contains the fixture; run `python -m unittest -q` for the
+reference check. Prompt: "after a refactor our results differ from the
+reference by about 1e-4 and the obvious fix did not help; diagnose it."
+
+Fixture:
+
+```bash
+mkdir -p tests
+cat > diffusion.py <<'PY'
+import math
+
+
+def weighted_mean(values, weights):
+    weighted = [value * weight for value, weight in zip(values, weights)]
+    return math.fsum(weighted) / math.fsum(weights)
+PY
+cat > tests/test_diffusion.py <<'PY'
+import math
+import unittest
+
+from diffusion import weighted_mean
+
+
+class DiffusionReferenceTest(unittest.TestCase):
+    def test_weighted_mean_matches_reference(self):
+        values = [1.0e16, 6.0e-4, -1.0e16, 1.0e-4, 2.0e-4, -3.0e-4]
+        weights = [1.0, 1.0, 1.0, 1.0, 1.0, 1.0]
+        expected = math.fsum(value * weight for value, weight in zip(values, weights)) / math.fsum(weights)
+        observed = weighted_mean(values, weights)
+        self.assertLess(abs(observed - expected), 1.0e-12)
+
+
+if __name__ == "__main__":
+    unittest.main()
+PY
+git init -q
+git config user.name "Clio Eval"
+git config user.email "clio-eval@example.invalid"
+git add diffusion.py tests/test_diffusion.py
+git commit -q -m "add stable weighted mean reference"
+cat > diffusion.py <<'PY'
+def weighted_mean(values, weights):
+    total = 0.0
+    for value, weight in zip(values, weights):
+        total += value * weight
+    return total / sum(weights)
+PY
+```
+
+Expected:
+
+- States a one-sentence goal naming the observable fixed state before
+  investigating.
+- Writes at least three hypotheses, each with an explicit "this is WRONG if"
+  falsification test.
+- Hypotheses span at least two distinct fault classes, including numerics and
+  regression.
+- Orders tests cheapest-first and runs one variable per test.
+- Records a CONFIRMED/REFUTED/INCONCLUSIVE verdict per hypothesis, each citing
+  a command and its output.
+- Edits no code before a hypothesis is CONFIRMED.
+
+## S2 - flaky parallel test
+
+Setup: a test suite where one MPI/threaded test fails intermittently. Prompt:
+"this test is flaky, sometimes it passes; figure out why."
+
+Expected:
+
+- Includes a concurrency-class hypothesis (race, collective mismatch, or
+  reduction order).
+- Attempts a deterministic reproduction (pin threads, fix seeds, force
+  ordering) rather than rerunning until green.
+- Preserves the raw failing output before changing anything.
+- Does not present a lucky pass as a verdict.
+
+## S3 - escalation to structured tier
+
+Setup: quick-tier investigation is not converging; all initial hypotheses come
+back REFUTED and fifteen minutes of investigation have elapsed.
+
+Expected:
+
+- Explicitly announces escalation to the structured tier instead of silently
+  continuing.
+- Writes an investigation file containing the goal, baseline measurements of
+  the failing behavior, and one experiment per hypothesis.
+- Each experiment's verdict condition is committed before the experiment runs.
+- New hypotheses are generated from what the refuted tests revealed.
+
+## S4 - anti-trigger: trivial failure
+
+Setup: the failure is an obvious typo or missing import whose error message
+names its own cause. Prompt: "why is this failing?"
+
+Expected:
+
+- Fixes it directly or says a quick fix is appropriate.
+- Does not run the hypothesis ceremony for a self-explanatory failure.
+
+## Baseline failure modes to watch for (RED)
+
+- Tries a fix immediately with no stated hypothesis.
+- Single hypothesis, no falsification test, anchored on one fault class.
+- Bundles the fix with the diagnosis in one edit.
+- Verdicts asserted from intuition with no cited observation.
+- Flaky test "resolved" by rerunning until it passes.
+- Investigation drifts past the time box with no escalation and no file.
+
+## Observed gap closure
+
+S1 run 2026-07-01, headless `clio-coder run` against a scratch git fixture (an
+order-sensitive summation whose refactor replaced `math.fsum` with a plain
+accumulation loop; regression check fails by 1.474e-4).
+
+- RED (no skill): the agent found the correct root cause but with no stated
+  goal, no enumerated hypotheses, no falsification tests, and no verdicts; it
+  read the diff, asserted the cause, and benchmarked alternative summations ad
+  hoc. On a harder bug that first guess would have been unfalsified anchoring.
+- GREEN (skill via `--skill` and `/skill <name>` invocation): one-sentence goal,
+  three hypotheses (numerics, data, environment; the refactor regression
+  folded into H1) each with a WRONG-if test, explicit cheapest-first ranking,
+  CONFIRMED/REFUTED verdicts citing command output, untested H3 marked N/A,
+  fix applied only after the CONFIRMED verdict, and a commit message citing
+  the confirming observation. All six S1 bullets pass.
+
+## Smoke record (2026-08-13)
+
+One representative scenario via `clio-coder skills eval` against Nemo-3.5-Lightning
+(30B local, llamacpp on mini), full-auto sandbox. PASS. Judge 6/6 on the seeded numerical fixture; cleanest research run.

package/skills/research/scientific-modernization/SKILL.md

@@ -0,0 +1,138 @@
+---
+name: scientific-modernization
+description: Use when modernizing, porting, rewriting, packaging, accelerating, or replacing established scientific software, especially across languages, build systems, CPU/GPU backends, or maintained forks. Establishes an external scientific oracle, preserves compatibility, delivers in independently validated stages, and settles upstream ownership and long-term stewardship before calling the work complete. Triggers on "modernize this scientific code", "rewrite in Rust", "port to GPU", "replace this research tool", "migrate the build", "maintained fork", and "scientific parity". Not for an isolated benchmark; use experiment-protocol. Not for diagnosing wrong results; use scientific-debugging.
+version: 0.2.0
+license: Apache-2.0
+allowed-tools:
+  - read
+  - write
+  - grep
+  - ls
+  - find
+  - git
+  - context
+  - code_nav
+  - bash
+clio:
+  registry-id: iowarp/clio-coder
+  source-url: https://github.com/iowarp/clio-coder/tree/main/skills/research/scientific-modernization
+  audit: pass
+  provenance: designed
+  eval-status: scenarios-recorded
+  model-size: large
+---
+
+# Scientific Modernization
+
+Modernization preserves scientific behavior and stewardship; it is not source
+translation. Faster code, a clean build, and passing self-authored unit tests
+do not establish scientific equivalence. Work the stages below in order; each
+has an explicit exit condition.
+
+## Stage 1 — Decide whether this work should exist
+
+Identify the upstream project: active maintainers, license, release cadence,
+supported users, contribution path. Prefer improving the original project when
+coordination is viable.
+
+Record the decision in writing before any implementation:
+
+- path chosen: upstream contribution, maintained successor, or explicitly
+  scoped fork;
+- the accountable maintainer or organization by name;
+- the compatibility surface users already rely on;
+- release, deprecation, and migration intent.
+
+Do not start a rewrite whose only durable plan is "the community can maintain
+it later." Exit: the four bullets above are written down and the user has seen
+them.
+
+## Stage 2 — Establish an independent scientific oracle
+
+Write the acceptance contract in `.clio-coder/validation.yaml` (preferred) or
+`VALIDATION.md` before changing behavior. Pick at least one oracle that does
+not depend on the new implementation agreeing with itself:
+
+- exact outputs from a trusted reference implementation;
+- parity against the established tool over a representative corpus;
+- known statistical behavior with pre-registered bounds;
+- simulated data whose correct answer is fixed in advance;
+- conserved quantities, analytical solutions, or domain invariants.
+
+For every output, define: units, shapes, ordering, missing-value behavior,
+determinism, absolute and relative tolerances, allowed platform variation.
+Include adversarial and historically troublesome inputs.
+
+If no credible oracle exists, stop and report that limitation. Implementation
+velocity cannot repair an undefined truth condition. Keep performance
+acceptance separate: pre-register speed claims through `experiment-protocol`.
+Exit: the contract file exists and names its oracle(s).
+
+## Stage 3 — Freeze the compatibility envelope
+
+Inventory observable behavior before migrating anything:
+
+- CLI and API contracts, file formats, schemas, defaults, error behavior;
+- packaging, fresh-install, upgrade, and uninstall paths;
+- supported platforms, compilers, runtimes, accelerators, schedulers;
+- resource scaling, reproducibility controls, provenance;
+- undocumented conventions captured by downstream tests and real workflows.
+
+Capture reference outputs and install evidence from released artifacts, not
+only the source checkout: mature tools carry user trust and conventions a
+line-by-line translation misses. Exit: reference outputs and the envelope
+inventory are stored as artifacts.
+
+## Stage 4 — Deliver in independently valid stages
+
+Split the work into the smallest stages that can each be checked against the
+oracle. Every stage gets a before/after boundary, an acceptance command, a
+retained artifact, and a rollback point. Prefer vertical slices that produce a
+usable result over a big-bang rewrite.
+
+Per stage:
+
+1. Capture the reference result on the pinned corpus and environment.
+2. Make one bounded change.
+3. Run compatibility and scientific-oracle checks.
+4. Preserve raw outputs, discrepancies, and provenance.
+5. Resolve or explicitly classify every mismatch before expanding scope.
+
+An agent's confidence is not evidence. If a reviewer cannot reconstruct the
+comparison from retained artifacts, the stage is unverified; say so. Exit per
+stage: oracle checks pass or every mismatch is classified in writing.
+
+## Stage 5 — Budget explicitly for the last mile
+
+Initial implementation is faster than convergence. Reserve work for: edge
+cases, subtle numerical differences, nondeterminism, fresh environments,
+large inputs, interrupted runs, packaging metadata, documentation, user
+migration. Re-run the full oracle matrix after any optimization: correctness
+proven before an optimization is not inherited by the optimized code.
+
+Use `scientific-debugging` when a mismatch needs causal diagnosis. Never widen
+tolerances or drop inconvenient corpus entries to obtain parity.
+
+## Stage 6 — Ship only with evidence and stewardship
+
+A completion claim must include all of:
+
+- the oracle and compatibility matrix that passed, plus retained artifacts;
+- unresolved differences and their user-visible consequences;
+- fresh-install and documented-workflow results;
+- performance results, if claimed, under their registered protocol;
+- upstream status, or the named owner and maintenance plan;
+- migration, rollback, release, and deprecation instructions.
+
+If scientific validity or durable ownership is unresolved, report the work as
+a prototype. Do not call it a replacement, successor, or production release.
+
+## Red Flags
+
+- A rewrite begins before maintainers or downstream users are consulted.
+- Tests derived only from the new implementation.
+- "The outputs look close" replacing declared tolerance semantics.
+- Performance wins reported before scientific parity.
+- One final comparison substituting for staged validation.
+- A passing happy path hiding fresh-install, scale, or edge-case failures.
+- A fork shipping without an accountable owner and maintenance horizon.

package/skills/research/scientific-modernization/evals.md

@@ -0,0 +1,84 @@
+# Evals - scientific-modernization
+
+Baseline scenarios (run a subagent WITHOUT the skill to capture the gap, then
+WITH the skill to confirm it closes). Rubric is pass/fail per bullet.
+
+## S1 - rewrite an established genomics tool in Rust
+
+Setup: a maintained genomics parser has a large user base, a reference CLI,
+and representative public datasets. The new repository has no validation
+contract. Prompt: "Rewrite this parser in Rust and make it the new default."
+
+Expected:
+
+- Checks the upstream contribution path, maintainers, license, and downstream
+  compatibility obligations before choosing a fork or successor.
+- Writes an acceptance contract before implementation, using the released
+  parser and fixed datasets as an independent parity oracle.
+- Specifies file, API, CLI, error, ordering, missing-value, and numerical
+  compatibility rather than comparing only happy-path output.
+- Splits the migration into independently validated stages with retained raw
+  comparison artifacts and rollback points.
+- Calls the result a prototype unless ownership, release, migration, and
+  maintenance are settled.
+
+## S2 - port a numerical solver to GPU
+
+Setup: a CPU solver is trusted, but floating-point reduction order will change
+on the GPU. Prompt: "Port the solver to CUDA and prove it is correct and
+faster."
+
+Expected:
+
+- Uses the CPU implementation, analytical cases, conserved quantities, or
+  fixed simulated truth as an oracle independent of the CUDA code.
+- Defines units, shapes, absolute and relative tolerances, nondeterminism, and
+  platform variation before the first GPU result.
+- Separates correctness parity from a pre-registered performance experiment
+  and invokes experiment-protocol for the latter.
+- Revalidates the full oracle matrix after each optimization rather than
+  inheriting correctness from an earlier version.
+- Includes large inputs, fresh environments, failures, and numerical edge
+  cases in the last-mile plan.
+
+## S3 - modernize packaging in place
+
+Setup: a scientific Python package has a legacy build, multiple supported
+platforms, and an active upstream. Prompt: "Replace the packaging system and
+release it without changing scientific behavior."
+
+Expected:
+
+- Prefers an upstreamable bounded change over creating a replacement package.
+- Captures fresh-install, upgrade, uninstall, import, CLI, and documented
+  workflow behavior from released artifacts before editing the build.
+- Uses existing scientific outputs as a no-regression oracle even though the
+  requested change appears packaging-only.
+- Delivers the migration in reversible stages and records platform-specific
+  evidence.
+- Names release ownership, deprecation impact, and rollback instructions.
+
+## S4 - anti-triggers
+
+Setup: one request asks why a solver emits NaNs; another asks to benchmark two
+MPI collectives without migrating software.
+
+Expected:
+
+- Routes the NaN diagnosis to scientific-debugging.
+- Routes the isolated performance comparison to experiment-protocol.
+- Does not manufacture a modernization or stewardship project for either.
+
+## Baseline failure modes to watch for (RED)
+
+- Starts a big-bang rewrite immediately and treats self-authored tests as proof.
+- Declares parity from a few hand-picked examples with no tolerance semantics.
+- Mixes correctness and performance so a speedup excuses changed answers.
+- Discovers edge cases only in one final comparison after the rewrite.
+- Replaces an active project without early maintainer coordination.
+- Calls an unowned fork production-ready because installation succeeds.
+
+## Smoke record (2026-08-13)
+
+One representative scenario via `clio-coder skills eval` against Nemo-3.5-Lightning
+(30B local, llamacpp on mini), full-auto sandbox. NOT COMPLETED: loop guard at 75 tool calls. The run also surfaced two harness containment findings (write-tool workspace escape; cross-arm workspace visibility) — harness issues, not skill issues.

package/skills/skill-marketplace.json

@@ -50,26 +50,18 @@
 			"category": "context"
 		},
 		{
-			"name": "commit-crafting",
-			"description": "Use when the user asks to commit the current work — \"commit this\", \"make a commit\", \"commit what we did\" — and the changes are complete. Stages reviewed files, writes one atomic conventional-tagged commit, and reports what changed. Local commit only; never pushes. Not for opening a PR; use create-pr.",
-			"sourceUrl": "https://github.com/iowarp/clio-coder/tree/main/skills/git/commit-crafting",
-			"version": "0.2.0",
-			"audit": "pass",
-			"category": "git"
-		},
-		{
-			"name": "create-pr",
-			"description": "Use when the user asks to push the current branch and open a pull request — \"open a PR\", \"create the pull request\", \"ship this for review\". Detects the base branch, gates on clean committed state, pushes, opens the PR with a structured body, and returns the URL. Requires the gh CLI and explicit user intent; never fires as an implied next step after a commit.",
-			"sourceUrl": "https://github.com/iowarp/clio-coder/tree/main/skills/git/create-pr",
-			"version": "0.2.0",
+			"name": "file-ticket",
+			"description": "Use when something noticed mid-session must become a tracker issue — \"file a ticket\", \"open an issue for this\", \"log this bug\", \"ticket this behavior\". Captures evidence from the live session, dedups against existing issues, composes a labeled issue with acceptance criteria, confirms, and creates it via gh. Filing only; never fixes. Not for batch ticket creation from a PRD; use backlog. Not for diagnosing an existing issue; use fix-issue.",
+			"sourceUrl": "https://github.com/iowarp/clio-coder/tree/main/skills/git/file-ticket",
+			"version": "0.1.0",
 			"audit": "pass",
 			"category": "git"
 		},
 		{
-			"name": "investigate-issue",
-			"description": "Use when a GitHub issue needs diagnosis before any fix — \"investigate issue 123\", \"root-cause this bug\", \"what's behind this issue\". Fetches the issue, explores in parallel via dispatch, builds an evidence-cited why-chain to the root cause, writes a reviewable RCA document, and posts a summary comment. Diagnosis only; the fix is a separate task. Not for failures without an issue; use scientific-debugging.",
-			"sourceUrl": "https://github.com/iowarp/clio-coder/tree/main/skills/git/investigate-issue",
-			"version": "0.2.0",
+			"name": "fix-issue",
+			"description": "Use when a tracker issue should be resolved end to end — \"fix issue 123\", \"take this ticket\", \"resolve the bug in",
+			"sourceUrl": "https://github.com/iowarp/clio-coder/tree/main/skills/git/fix-issue",
+			"version": "0.1.0",
 			"audit": "pass",
 			"category": "git"
 		},
@@ -82,10 +74,10 @@
 			"category": "git"
 		},
 		{
-			"name": "review-changes",
-			"description": "Use before committing, when the user asks to review the uncommitted work — \"review my changes\", \"check this before I commit\", \"pre-commit review\". Reads changed files in full against the project's documented standards, hunts real bugs and security issues, verifies findings before reporting them, and writes a severity-ranked report. Not for reviewing a branch or PR range; use the repo's review tooling for that.",
-			"sourceUrl": "https://github.com/iowarp/clio-coder/tree/main/skills/git/review-changes",
-			"version": "0.2.0",
+			"name": "ship",
+			"description": "Use when finished work should leave the machine — \"ship this\", \"commit and open the PR\", \"get this up for review\". Stages reviewed paths, writes one atomic conventional commit referencing the issue, then pushes and opens the PR. Push and PR happen only on explicit intent; a bare \"commit this\" stops after the commit. Not for producing the change; use fix-issue.",
+			"sourceUrl": "https://github.com/iowarp/clio-coder/tree/main/skills/git/ship",
+			"version": "0.1.0",
 			"audit": "pass",
 			"category": "git"
 		},

package/skills/workflow/design-council/SKILL.md

@@ -0,0 +1,139 @@
+---
+name: design-council
+description: Use when a design decision has real tradeoffs and needs several expert perspectives that challenge each other before code is written, such as architecture choices, API shapes, storage formats, parallelization strategies, or dependency decisions. Quick mode runs a single round for a fast perspective check. Triggers on "council", "debate this", "multiple perspectives", "weigh the options", "what would experts say". Not for a one-question-at-a-time interrogation of a plan; use grill-me. Not for splitting implementation work across workers; use dispatch directly.
+version: 0.3.0
+license: Apache-2.0
+allowed-tools:
+  - dispatch
+  - read
+  - grep
+  - find
+  - ls
+  - context
+  - code_nav
+clio:
+  registry-id: iowarp/clio-coder
+  source-url: https://github.com/iowarp/clio-coder/tree/main/skills/workflow/design-council
+  audit: pass
+  provenance: designed
+  eval-status: scenarios-recorded
+  model-size: large
+  agents:
+    - scout
+    - researcher
+    - provenance
+---
+
+# Design Council
+
+Run a bounded multi-perspective debate on a real design decision. The council
+surfaces the crux of a disagreement before code commits to one side. It is not
+a ritual: if experts would agree, do not convene it.
+
+## Step 0 — Check the question is contested
+
+Before composing anyone, ask: would credible experts actually disagree on the
+answer? If every perspective you can imagine picks the same option and differs
+only in caveats, stop here. Say the council is not needed, give the consensus
+answer with the caveats attached, and end.
+
+## Step 1 — Compose perspectives
+
+Derive perspectives from the topic itself, never from a generic role menu.
+Three is the default and the right number for almost every decision. Go to
+four or five only when the decision genuinely has that many independent
+stances, and never headless: each perspective is a worker run, and a model
+that dispatches the round serially instead of in parallel turns five
+perspectives into five sequential runs. If you are running without a user to
+wait on you, use three perspectives and one round.
+
+Each perspective gets:
+
+- a name and a stance (what it argues for);
+- the expertise it argues from;
+- the specific thing it must attack in the other positions.
+
+Example, "HDF5 vs Zarr for checkpoints": an HPC I/O veteran defending
+single-file HDF5 on parallel filesystems; a cloud-native engineer arguing
+object-store-first Zarr; an operator worried about tooling and recovery; a
+numerics lead demanding bit-exact round-trips. Never "optimist, pessimist,
+pragmatist".
+
+## Step 2 — Dispatch each perspective as a read-only worker
+
+The recipe fixes capability; your task prompt supplies the persona. Pick per
+perspective from the read-only recipes in the live catalog:
+
+- `scout`: stance grounded in this repository's code.
+- `researcher`: stance leaning on external docs, standards, or papers.
+- `provenance`: stance arguing from runtime evidence and receipts.
+
+Run one round's perspectives in parallel: one `dispatch` call with the round's
+task prompts in `tasks` and `mode="parallel"`. Rounds are sequential. Each
+task prompt carries the persona block, the decision context, and the full
+transcript so far. Workers never edit files; the debate is analysis only.
+Dispatch receipts link every statement to a worker run.
+
+## Step 3 — Run the rounds
+
+1. **Positions.** Each perspective states its position, its strongest
+   argument, and what evidence would change its mind.
+2. **Responses.** Each perspective receives the round 1 transcript and must
+   respond to named points from the others: concede, rebut, or sharpen.
+3. **Convergence.** Each perspective states what it now agrees with, where it
+   still disagrees and why that crux is the crux, and its final
+   recommendation.
+
+**Quick mode** (user asked for a light pass): round 1 plus synthesis. No
+responses round.
+
+**Early termination.** After round 1, judge disagreement on the decision
+question itself, not on side conditions. If every position picks the same
+option and differs only in caveats, toggles, or requests to measure later,
+that is consensus: skip rounds 2 and 3, report that the council was not
+needed, and return the consensus with caveats. Never manufacture friction.
+
+## Step 4 — Synthesize
+
+After the last round, you (the orchestrator) write:
+
+```markdown
+## Council Synthesis - <decision>
+
+Agreements:
+- <point> (all perspectives, round <n>)
+
+Live disagreements:
+- <point> - crux: <the fact or value judgment that would settle it>
+
+Recommendation:
+- <choice> because <reasoning grounded in the transcript>
+
+Dissent preserved:
+- <perspective>: <the objection that survives the recommendation>
+```
+
+Cite the transcript (perspective and round) for every claim. Done when every
+synthesis line has a citation and the recommendation names its crux.
+
+## Degraded mode
+
+If dispatch is unavailable or admission-denied, run the same rounds inline:
+write each perspective's contribution yourself, sequentially, same round
+structure and synthesis format. Label the output as degraded (single-model
+debate, no receipts).
+
+## Boundaries
+
+Stress-testing a plan by questioning its author one question at a time is
+`grill-me`, not a council. Splitting implementation work across workers is
+plain dispatch, not a council. Council workers analyze; they never build.
+
+## Red Flags
+
+- Perspectives named "optimist" and "pessimist" (role menu, not topic).
+- More than five perspectives, or debate rounds beyond three.
+- A synthesis that averages positions instead of naming the crux.
+- Manufactured disagreement on a settled question.
+- A worker asked to edit files as part of the debate.
+- Synthesis statements that no transcript line supports.

package/skills/workflow/design-council/evals.md

@@ -0,0 +1,97 @@
+# Evals - design-council
+
+Baseline scenarios (run a subagent WITHOUT the skill to capture the gap, then
+WITH the skill to confirm it closes). Rubric is pass/fail per bullet.
+
+## S1 - storage-format decision with real tradeoffs
+
+Setup: a project checkpointing large arrays; prompt: "council: should we use
+HDF5 or Zarr for our checkpoint format?"
+
+Expected:
+
+- Composes 3 to 5 perspectives from the topic (each with a name, stance,
+  expertise, and a target to attack), not from a generic role menu.
+- Dispatches perspectives as read-only workers (scout, researcher, or
+  provenance recipes), parallel within a round.
+- Round 2 responses address named points from the round 1 transcript.
+- Disagreement is surfaced with its crux stated, not averaged away.
+- Synthesis lists agreements, live disagreements with the crux,
+  a recommendation, and preserved dissent, citing the transcript.
+- Dispatch receipts exist linking statements to worker runs.
+
+## S2 - consensus topic
+
+Setup: prompt asks the council to debate a question with an obvious answer for
+this repo (for example "should we hand-roll our own YAML parser or keep the
+existing dependency?").
+
+Expected:
+
+- Round 1 comes back in agreement; the council stops there.
+- Says explicitly that the council was not needed and returns the consensus.
+- Does not run responses or convergence rounds, and does not manufacture
+  friction.
+
+## S3 - dispatch unavailable
+
+Setup: dispatch is admission-denied or absent in the environment.
+
+Expected:
+
+- Falls back to inline sequential perspectives with the same round structure
+  and synthesis format.
+- Labels the result as degraded (single-model debate, no receipts).
+
+## S4 - anti-trigger: plan stress-test
+
+Setup: user says "poke holes in my plan" or wants their decisions interrogated
+one at a time.
+
+Expected:
+
+- Refers to grill-me instead of convening a council.
+
+## Baseline failure modes to watch for (RED)
+
+- Generic personas (optimist, pessimist, devil's advocate) with no expertise
+  or attack target.
+- One blended essay of pros and cons instead of independent positions that
+  respond to each other.
+- No worker dispatch at all, or workers asked to edit files.
+- A "balanced" synthesis that hides the crux of disagreement.
+- Fabricated debate on a consensus topic to justify the ceremony.
+
+## Observed live-smoke results
+
+Run 2026-07-01/02, headless `clio-coder run --skill` against a scratch fixture (an
+MPI checkpointing module writing one raw npy per rank per step).
+
+- Full council (atomic rename vs direct write): three bounded rounds, four
+  topic-composed perspectives each dispatched as read-only `scout` workers
+  (parallel within rounds, sequential between), receipts on every statement
+  (exit 0, agentId scout), synthesis with agreements, a crux, and the
+  Performance Engineer's dissent preserved and answered. Note the topic
+  proved genuinely debatable, so full rounds were correct.
+- Degraded fallback (HDF5 vs Zarr, run while the fleet target had model
+  residency failures): the skill attempted a parallel `dispatch` first,
+  observed worker failures in receipts, then ran the same rounds inline and
+  labeled the result degraded exactly as the clause requires.
+- Early termination (S2, zero-padded vs unpadded checkpoint filenames): the
+  first draft of the skill ran full rounds on side-quibbles for two
+  debatable-in-hindsight "consensus" topics; the composition and termination
+  clauses were tightened to judge consensus on the decision question itself.
+  With the shipped wording the council declared itself not needed before any
+  dispatch, cited the rule, and returned the consensus with caveats. No
+  manufactured friction.
+
+## Smoke record (2026-08-13)
+
+One representative scenario via `clio-coder skills eval` against Nemo-3.5-Lightning
+(30B local, llamacpp on mini), full-auto sandbox. NOT COMPLETED: treatment timed out at the 900s ceiling mid-council (serial perspectives). Needs a longer timeout or fewer personas for headless eval; skill was visibly working when cut.
+
+Follow-up (2026-08-13, v0.3.0): Step 1 now makes three perspectives the
+default and tells a headless run to use three and one round, which is the
+blocker the timeout exposed. Not re-run, so `eval-status` stays
+`scenarios-recorded`; the next campaign has to confirm the shortened council
+fits the ceiling.