@iowarp/clio-coder 0.4.2 → 0.4.3

package/skills/workflow/grill-me/evals.md

@@ -76,3 +76,156 @@ Expected:
 
 One representative scenario via `clio-coder skills eval` against Nemo-3.5-Lightning
 (30B local, llamacpp on mini), full-auto sandbox. PASS (smoke). Skill loaded and interviewed; judge emitted nothing (truncation).
+
+## Battletest record (2026-09-03)
+
+Fixture: `/home/akougkas/eval-temp/harness/test_grillme.py`, continuing the
+planning category's shared HPC log-triage domain. Seeds the *decided* v1
+architecture doc (`docs/hpc-log-triage-architecture.md`: on-demand reads
+chosen over an always-on pipeline, alerting explicitly listed "Not
+decided"), the partial `src/scanner.py` (`FailureEvent` + OOM-only
+`scan_oom`), and a `pyproject.toml` declaring `pytest` as the test runner
+— a repo fact the interview must find via `read`, not ask about (evals.md
+S2). The prompt is S1's vague-but-grounded feature request: "grill me on
+adding Slack alerting... nothing about notifications or Slack is decided
+yet." `ask_user` in this harness auto-cancels immediately with no operator
+(confirmed by the planning category and reconfirmed here), which makes
+this skill's entire premise — a one-question-at-a-time live interview — the
+thing under test. Graded 10 checks against the reconstructed final
+assistant text and the raw JSONL's tool-call/safety-block stream: zero
+safety blocks; zero `tasks` calls; no wasted `ask_user` retries (<=3
+calls); repo facts (`scan_oom`, `FailureEvent`, on-demand, `click`,
+`pytest`, `scan_ecc`/`scan_xid`, top-3) grounded in the final text; the
+Step 5 decision-log shape present (`Decision Log`/`Deferred`/`Open
+risks`/`Recommended next step`, not a summary paragraph); decisions
+numbered; the `assumed — confirm` monologue used 3+ times; the Question
+Priority order respected (user/problem framing before naming/polish); and
+**the phase map actually completed** (4+ distinct phase numbers named,
+not a stall after phase 0/1). S3 (user defers) and S5 (stop signal) are
+not separately exercised — a headless run cannot produce a live "whatever
+you think" or "stop" reply to react to; by construction, the
+assumed-confirm monologue *is* the "whatever you think" case running for
+every decision, so S3's expected behavior (record the recommendation,
+say so explicitly) is exercised implicitly on every phase, every run.
+S4 (long phased interview, near round-limit closeout) was not exercised
+standalone. Primary model `qwen3.8-27b` on `dynamo` (LM Studio); cross-model
+confirm on `ornith1.5-35b-moe` on `mini` (llama.cpp), required per this
+session's brief because a prior pass in the same mission found fixes tuned
+on one model family did not always transfer to another.
+
+| run | model | wall | turns | in / out tokens | safety blocks | score | outcome |
+|---|---|---|---|---|---|---|---|
+| baseline (no skill) | qwen3.8-27b | 42s | 3 | 32.5k / 3.7k | 0 | 5/10 | never invoked `/skill grill-me`; read both key files and grepped for "alerting", grounded correctly, but produced one live-style question and stopped — no phase map, no decision log (expected: this is what the skill exists to fix) |
+| v1 (frozen 0.4.0) | qwen3.8-27b | 57s | 7 | 91.8k / 5.2k | 2 (1 real: `tasks` refused; 1 benign ENOENT on a fixture-dangling doc path) | 3/10 | opened a `tasks` plan for its own phase map (refused — `tasks` was never called out as off-surface in the frozen body), scanned thoroughly, then asked exactly **one** question in plain text and ended the turn — never called `ask_user` at all, never produced a decision log. This is the exact failure the session was built to catch: the frozen skill's fallback line ("if `ask_user` is unavailable, ask in plain text... keep an internal decision log") reads as permission to have an ordinary single-question live conversation, and the model took it literally |
+| v2 (first hardened cut, 0.5.0) | qwen3.8-27b | 121s | 6 | 78.9k / 11.2k | 1 (benign ENOENT, same dangling doc path) | 9/10 | scanned via `git`/`read`/`ls`, reasoned "ask_user is not in my tool surface" (not quite accurate — it's always exempt — but harmless), and correctly ran the full assumed-confirm monologue through Phases 0-5 to a complete, correctly-shaped decision log, entirely without ever calling `ask_user`. Fixture's dangling PRD reference removed after this run to isolate real vs. benign blocks |
+| v2 re-run (fixture fixed) | qwen3.8-27b | 134s | 7 | 101.0k / 12.1k | 1 real: `bash wc`/`bash head` on the sample log, refused | 9/10 | same strong monologue and decision log; the one new gap was a `bash` reflex the frozen and first-cut bodies never explicitly forbade (grill-me never had `bash` in `allowed-tools`, but nothing told the model not to reach for it) |
+| v3 (bash-refusal added) | qwen3.8-27b | 97s | 5 | n/a | 0 | 6/10 | `bash` reflex gone, but a **regression**: stated "this harness has no `ask_user` tool" (still not quite accurate) and, without ever calling `ask_user`, asked one plain-text question and ended the turn on "Answer 1 / 2 / 3" — the exact frozen-skill failure recurring under the hardened body, proving the earlier fix's trigger ("switch on the first `cancelled` result") had a gap: a model that never calls `ask_user` at all never receives a `cancelled` result to trigger the switch |
+| v4 (no-back-and-forth line added) | qwen3.8-27b | 124s | 6 | 85.1k / 11.0k | 0 | **10/10** | full 9-round monologue (Phases 0-5), correctly-shaped decision log, zero `tasks`/`bash` calls |
+| v5 (stability re-run) | qwen3.8-27b | 95s | 5 | n/a | 0 | **10/10** | repeat of v4's result, confirming v3's regression was not the new steady state |
+| final (cross-model confirm) | ornith1.5-35b-moe (mini) | 64s | 5 | 12.5k / 5.4k | 0 | **10/10** | full monologue and decision log on the second model family too; independently proposed a Slack-message trigger threshold not in the fixture and, in its closing line, distinguished what it would still "press on live" from what it correctly resolved on its own headless — the clearest sign the headless/live distinction actually landed as a real distinction, not just prose the model echoes back |
+
+**Changes** (0.4.0 -> 0.5.0):
+
+1. **`## Arguments` contract**, the section the skill never had — slash-free
+   conversational syntax, and the ported no-operator/`ask_user`-auto-cancels
+   rule from the planning category, adapted for a skill whose entire
+   contract is "one question at a time" rather than a document write.
+2. **The critical fix, found empirically, not guessed up front**: the
+   frozen skill's fallback line ("if `ask_user` is unavailable, ask in
+   plain text... one question at a time... internal decision log") reads,
+   correctly, as "have a normal one-question conversation" — which is
+   exactly wrong when there is no second turn for a reply to land in. The
+   fix that actually held (v4/v5, and the cross-model run) is a **"this run
+   has no back-and-forth" statement that does not gate on receiving a
+   `cancelled` result** from `ask_user` — v3's first attempt gated the
+   switch-to-monologue on "the first round comes back cancelled," which
+   left a real gap: a model that reasons "`ask_user` isn't available" and
+   never calls it at all never receives that trigger, and fell straight
+   back into the frozen skill's exact failure. The held version states the
+   no-reply-coming rule as a fact about the run itself, independent of
+   whether `ask_user` was ever invoked.
+3. **Explicit `tasks` and `bash` refusal**, in Arguments and Red Flags —
+   `tasks` was v1's real safety block (opened a plan for its own phase
+   map); `bash` was a reflex on the v2 re-run (`bash wc`/`bash head` on a
+   file that should have been `read`). Both are outside `allowed-tools`
+   already; the gap was that nothing said so in the body.
+4. **Step 3 and Step 4 rewritten** to name the headless-cancellation
+   handling explicitly at the exact point in the workflow it applies (not
+   only in Arguments): Step 3 states that neither a `cancelled` result nor
+   never calling `ask_user` at all is a reason to wait; Step 4 draws the
+   line between a live stop signal (still respected) and a headless
+   `cancelled` result (not a stop signal, a cue to keep going).
+5. **`git` tool and `code_nav` called out explicitly in Step 1** for repo
+   state and symbol lookups respectively — `code_nav` remains unexercised
+   by every run this session (see Still weak); `git` was used in every
+   hardened run once named.
+6. Five Red Flags entries rewritten or added around the concrete failures
+   observed: `tasks`/`bash` reaches, re-calling `ask_user` after a
+   cancellation, treating `cancelled` as a user stop signal, and — the
+   headline one — ending a turn on "Answer 1/2/3" instead of running the
+   monologue to the decision log.
+
+**Still weak**: `code_nav` (in `allowed-tools`) was never exercised by any
+run this session — this fixture's grounding lived entirely in prose files
+and one Python module small enough that `read`/`grep` sufficed; a fixture
+with a larger call graph might exercise it, but none was built. S3 and S5
+are reasoned about, not directly run (see the fixture note above) — a
+harness that could inject a specific `ask_user` reply (rather than always
+auto-cancelling) would let those two scenarios run for real instead of by
+inference. S4's near-round-limit closeout behavior is unverified; every
+hardened run here converged well under any plausible `max_rounds` value.
+v3's regression is the one data point worth remembering past this session:
+gating a headless-degradation rule on "the first tool result that comes
+back a certain way" is fragile against a model that skips the tool call
+entirely and reasons its way to the same wrong conclusion by a different
+path — the fix needed to be a fact about the run, not a reaction to one
+tool's return value. Two consecutive clean runs on the primary model and
+one clean cross-model run is reasonable but not exhaustive evidence that
+v3's failure mode is fully closed rather than just less frequent; only a
+larger run count would raise that confidence further.
+
+## Live interactive confirmation (2026-09-03, Herdr pane)
+
+The headless harness can only prove the assumed-confirm monologue path; it
+cannot produce a genuine "whatever you think" or "stop" reply because
+`ask_user` always auto-cancels with no operator. To exercise S3 and S5 for
+real, this session ran the hardened 0.5.0 skill interactively: a Herdr pane
+running `clio-coder` (target `mini`, model `ornith1.5-35b-moe`, switched
+in-session via `/model`) against the same fixture repo the battletest used
+(`/home/akougkas/eval-temp/grillme-final`, skill installed project-locally
+at `.clio-coder/skills/grill-me/` so the live session resolved this
+repo's edited SKILL.md rather than the separately npm-installed package
+copy — `/skill grill-me` has no path-override flag the way `clio-coder run
+--skill` does), with a human answering each `ask_user` round live via the
+TUI's modal.
+
+Result: Step 1 scanned the repo before asking anything (architecture doc,
+scanner.py, sample log). Round 1 asked a single root-decision question
+(trigger model) with the recommended option first and real tradeoffs on
+the alternatives. After the human's real answer came back, the model's own
+reasoning explicitly named the distinction the whole hardening pass turned
+on: *"The modal returned round_answered — there is an operator here...
+this is a live interview, not headless. I'll continue with one question
+per round and wait for your answers."* — proof the headless/live branch is
+a real fork in the model's behavior, not just prose it echoes. Five rounds
+ran in priority order (trigger, success measure, non-goals, delivery/
+secrets, payload shape); round 3 was answered "whatever you think is
+best" and recorded the stated recommendation as the decision (S3,
+confirmed live, not just implied by the monologue path); round 5 was
+answered with an appended stop signal ("...; stop") and the model called
+`ask_user` `action: "complete"` immediately, with no confirmation question
+(S5, confirmed live). The final decision log matched the Step 5 shape
+exactly (numbered decisions, Deferred, Open risks, Recommended next step)
+and, unprompted, flagged a real cross-cutting risk the fixture didn't
+spell out: the alerting feature's success measure depends on Phase 2's
+ranking/CLI, which doesn't exist in `scanner.py` yet — a genuine "hole
+poked," not filler. Zero safety blocks; zero `tasks` calls. One aside, not
+a skill defect: the TUI's own usage nudge fired ("9+ read-only exploration
+calls without a successful Scout dispatch") — Step 1's repo scan currently
+reaches for `read`/`grep`/`ls` directly rather than delegating broad
+reconnaissance to a Scout dispatch, worth a look in a future pass but out
+of scope for this one since the scan itself was correct and grounded.
+
+This closes the S3/S5-not-directly-run gap noted above for the specific
+case of a genuine live operator; the headless assumed-confirm path
+remains separately and repeatedly confirmed on its own terms.

package/skills/workflow/workflow-distiller/SKILL.md

@@ -7,7 +7,7 @@ triggers:
   - turn this into a reusable workflow
   - distill this repeated process
   - create a skill from this session
-version: 0.3.0
+version: 0.4.0
 license: Apache-2.0
 allowed-tools:
   - read
@@ -38,6 +38,37 @@ following skill-craft. skill-craft also governs how every skill this
 distiller produces is written: description, body, and pruning rules live
 there, not here.
 
+## Arguments
+
+```text
+/skill workflow-distiller [<what to distill>]
+```
+
+With arguments, the text names the workflow to distill; without, distill
+whichever workflow just ran in this session. Everything else in the request
+(the conversation so far) is the session record Phase 1 reconstructs from,
+not more arguments.
+
+A live operator can answer Phase 2's interview and Phase 4's design gate for
+real - treat a real, non-cancelled `ask_user` reply as proof an operator is
+present and continue asking one question per round. There is no operator in
+a headless run: `ask_user` is not registered and every call resolves
+`cancelled` immediately, whether or not it is ever called at all. When that
+is the run's condition, do not wait for a reply that cannot come: answer
+every remaining interview question and the Phase 4 gate yourself as an
+assumed-confirm monologue (state the question, give your best-grounded
+answer or design choice, mark it `assumed - confirm`) and proceed straight
+through to Phase 5, the same way as a live "looks fine, write it." A skill
+file is a plain, reversible artifact under version control, not an
+irreversible external action - write it and say so in the final reply,
+rather than stopping at the gate with nothing produced.
+
+`tasks` sits outside this skill's tool surface (`read`, `grep`, `find`,
+`ls`, `context`, `write`, `ask_user`) and any call is refused; the six
+phases above are the plan, not a task list. This skill never has `bash` or
+`git`, so it never commits or pushes the file it writes - say so in the
+final reply and let the user commit it.
+
 ## Phase 1 - Reconstruct From Evidence
 
 Before asking anything, list the concrete steps that visibly executed in this
@@ -90,27 +121,47 @@ Validation scenario: <prompt, expected observable behavior>
 ```
 
 No skill file is written before the user approves. "Looks fine, but change X"
-means revise and re-present.
+means revise and re-present. In a headless run with no operator (see
+Arguments), treat the design as approved once it is internally consistent
+with Phase 2's decisions, mark it `assumed - confirm` in your final reply,
+and proceed to Phase 5 - do not stop the run with a presented-but-unwritten
+design.
 
 ## Phase 5 - Create
 
-Write `SKILL.md` under `.clio-coder/skills/<approved-name>/`, following skill-craft
-for the frontmatter contract, a triggers-only third-person description, and
-the pruning pass, with `requires: [skill:<name>]` for every skill the overlap
-check referenced. Confirm it loads with `clio-coder skills validate`. Scope
-defaults to project; use the user skill store only when the user said the
-workflow crosses repositories. Placeholders replace every session-specific
-path, name, and value; distill the pattern, not the incident. Keep the
-generated skill under 120 lines; reference instead of inlining. If
-the session repeatedly dispatched the same worker pattern, also offer a recipe
-sketch for the agents surface, but do not write recipe files.
+Write `SKILL.md` under `.clio-coder/skills/<approved-name>/` with the
+frontmatter contract below - a triggers-only third-person description, and
+the pruning pass - with `requires: [skill:<name>]` for every skill the
+overlap check referenced. Do not try to load skill-craft's own file mid-run
+to check this: only one skill can be active at a time, and a second
+`context(scope="skills", name="skill-craft")` call is refused while this
+skill is still pending. The frontmatter contract, current as of this
+writing: `name`, `description` (third-person triggers, no "I"/"you"),
+`triggers` (a non-empty list), `version` (start `0.1.0`), `license`,
+`allowed-tools` (canonical lowercase Clio tool names only - `bash`/`git`
+capitalized or spelled differently is rejected), and `requires` when Phase 3
+found a reference. If in doubt about the exact shape, `read` an already-
+installed skill's `SKILL.md` (this skill's own file is always available) and
+mirror its frontmatter keys rather than guessing or trying to load
+skill-craft. Scope defaults to project; use the user skill store only when
+the user said the workflow crosses repositories. Placeholders replace every
+session-specific path, name, and value; distill the pattern, not the
+incident. Keep the generated skill under 120 lines; reference instead of
+inlining. If the session repeatedly dispatched the same worker pattern, also
+offer a recipe sketch for the agents surface, but do not write recipe files.
 
 ## Phase 6 - Validate
 
 Record one RED-GREEN scenario agreed with the user: the prompt, and the
-observable behavior that distinguishes with-skill from without. Run it once if
-cheap (a single small headless run); otherwise record it in the skill body's
-example section as the standing validation obligation.
+observable behavior that distinguishes with-skill from without. `clio-coder
+skills validate` needs `bash`, which is outside this skill's tool surface -
+never attempt it; instead `read` the file back and confirm the frontmatter
+contract from Phase 5 by eye (required keys present, `allowed-tools` entries
+canonical lowercase, under the line budget), and say plainly that a real
+`clio-coder skills validate` pass is still owed once bash is available.
+Otherwise record the scenario in the skill body's example section as the
+standing validation obligation. This skill has no `bash`/`git`, so it never
+commits or pushes the file it writes; say so and let the user commit it.
 
 ## Worked Example
 
@@ -128,15 +179,23 @@ script, and verified row counts against the source, three sessions in a row.
    installed; no references.
 4. Gate: summary presented; user approves after tightening the description.
 5. Create: write `.clio-coder/skills/csv-ingest/SKILL.md`, placeholders for the
-   export URL and column map; `clio-coder skills validate` passes.
+   export URL and column map; frontmatter contract confirmed by reading the
+   file back (no `bash`, so no `clio-coder skills validate` this turn).
 6. Validate: scenario "ingest this month's export" must show fetch,
    normalize, count-verify, spot-check in that order; recorded in the body.
 
 ## Red Flags
 
-- Writing any skill before the design gate is approved.
+- Writing any skill before the design gate is approved by a live operator,
+  or before a headless run has marked it `assumed - confirm`.
+- Stopping the run at Phase 4 with a presented-but-unwritten design when the
+  run is headless - that's the backlog pattern (guard an irreversible
+  action), and a written skill file is not that; it is reversible.
 - A reconstruction that lists steps nothing in the session shows.
 - Reimplementing an installed skill's job instead of referencing it.
 - Session-specific paths or values surviving into the generated skill.
 - Batching interview questions or ignoring a stop signal.
 - Distilling a one-off without asking about recurrence.
+- Calling `bash` for `clio-coder skills validate`, or `context` with a
+  second skill's name to consult it mid-run: both are outside this skill's
+  tool surface and refused.

package/skills/workflow/workflow-distiller/evals.md

@@ -105,3 +105,121 @@ prompt; the phases still had to run in order.
 
 One representative scenario via `clio-coder skills eval` against Nemo-3.5-Lightning
 (30B local, llamacpp on mini), full-auto sandbox. PASS. Inline session-trace setup engaged; judge 5/6.
+
+## Battletest record (2026-09-03)
+
+This skill's core loop (a several-turn interview, a live-or-headless design
+gate, a write) is genuinely interactive, so it was tested primarily through
+a live Herdr-driven `clio-coder` pane with a real human answering
+`ask_user` rounds, not only through the headless harness the rest of this
+category used — plus one headless confirm run to exercise the no-operator
+path directly. Fixture: the shared HPC log-triage repo (`test_grillme.py`'s
+`setup_fixture`, `docs/hpc-log-triage-architecture.md` + partial
+`src/scanner.py`/`tests/test_scanner.py`), compounded with a real Part 1
+task ("add `scan_ecc` mirroring `scan_oom`, test it, commit it") run to
+completion *before* invoking `/skill workflow-distiller`, so Phase 1 had a
+genuine session record to reconstruct from rather than a scripted one.
+
+**v1 (frozen 0.3.0), live, `ornith1.5-35b-moe` on mini**: Phase 1
+reconstruction was precise and correctly cited to real tool calls. The
+5-round interview (confirm+recurrence, varies/fixed, rigidity/failure,
+scope cuts, name) ran cleanly, one question per round, recommended-first.
+Phase 3's overlap check correctly found nothing to reference. Phase 4's
+design gate presented the exact template shape and correctly waited for a
+live "looks fine, write it" before writing anything. Two real bugs
+surfaced in Phase 5/6: (1) "load skill-craft" is dead - `context(scope=
+"skills", name="skill-craft")` while workflow-distiller is itself the
+active pending skill is refused ("pending skill request(s)"); only one
+skill can be active at a time. (2) Phase 6's "confirm it loads with
+`clio-coder skills validate`" is dead - `bash` is outside this skill's
+`allowed-tools`, so that command can never run. The model self-recovered
+both times (read its own installed SKILL.md as a frontmatter mirror; did a
+by-eye read-back instead of the blocked validate command) and reported the
+gap honestly rather than fabricating a clean validate - a good sign for
+model robustness, but the skill body should not depend on a model
+inventing its own workaround for a dead instruction.
+
+**Changes (0.3.0 -> 0.4.0)**: new `## Arguments` section stating the
+live-vs-headless distinction explicitly (a real, non-cancelled `ask_user`
+reply proves an operator is present and interview/gate proceed normally;
+`ask_user` unregistered and auto-cancelling means assumed-confirm through
+Phase 2 and Phase 4 and straight on to Phase 5 - a written skill file is a
+reversible, version-controlled artifact, not the kind of irreversible
+action `backlog`'s Step 3 guards, so it does not get that skill's
+stop-and-report treatment); explicit `tasks` refusal and a "never commits"
+note; Phase 4 gate prose updated with the headless branch; Phase 5 rewrote
+the skill-craft consultation into a concrete, achievable frontmatter
+contract (the required keys, and "`read` an already-installed skill's file
+to mirror the shape, never try to load a second skill mid-run"); Phase 6
+rewrote the validate step to a real, achievable by-eye check instead of
+the dead `bash` command; the worked example's line claiming `clio-coder
+skills validate` passes was corrected to match; two new Red Flags entries
+for the two dead-instruction failure modes.
+
+**v2 (hardened 0.4.0), live, `ornith1.5-35b-moe` on mini, fresh session**:
+same compound Part 1 + Part 2 scenario end to end. Real finding along the
+way, unrelated to this skill: the model cannot self-invoke `/skill` - it
+is operator-gated UI, not an agent tool, confirmed twice (once via a
+direct `context` call, once by embedding `/skill workflow-distiller` in a
+larger message instead of sending it standalone) - both times the model
+correctly recognized the constraint, said so, and asked the operator to
+run it rather than retrying or faking activation. Once invoked properly:
+Phase 1 reconstruction included the real mid-session detour (a genuine
+case-sensitivity bug the model introduced and fixed via byte-level
+debugging) rather than a cleaned-up story. The interview produced a
+materially different design from v1's run on the same scenario (different
+name chosen, "leave uncommitted" instead of "commit via bash" for the
+generated skill) - real evidence the interview is actually deciding things,
+not replaying a script. Phase 4 correctly said "this is a live run, so
+I'll hold off writing until you approve" and, when a later `ask_user`
+round had already closed, correctly fell back to a plain-text approval
+request rather than stalling - explicitly restating, unprompted, every
+constraint this session's hardening pass had just added (no commit, no
+`clio-coder skills validate`, `tasks` out of surface). Phase 5 went
+straight to `read`-ing its own installed SKILL.md to mirror the frontmatter
+contract, with zero attempt to load skill-craft - bug #1 confirmed fixed.
+The generated `.clio-coder/skills/add-signature-scanner/SKILL.md` (97
+lines) has valid frontmatter, canonical-lowercase `allowed-tools`, real
+placeholders, and a concrete validation scenario.
+
+**A real, separate platform-level finding, not a skill-body bug**: during
+this same v2 live session's Phase 6, a `bash wc -l` call executed
+successfully (`exit 0`, green checkmark confirmed via `--format ansi`) even
+though `bash` is not in workflow-distiller's `allowed-tools` - and the
+identical class of call had been correctly refused earlier in this exact
+mission's v1 session under the same skill ("bash is outside the tool
+surface declared by the active skill(s)"). The model's own final report
+then claimed "I can't run bash" in the same breath as having just run it.
+This reads as skill tool-surface narrowing lapsing partway through a long,
+many-turn interactive session (Phase 1 through 6 spans several real
+conversation turns; the headless harness's single-turn monologue shape
+never exercises this), not anything a SKILL.md can fix by itself. Worth a
+maintainer look at the interactive admission path specifically, independent
+of this skill or this mission's edits.
+
+**Headless confirm, `qwen3.8-27b` on dynamo, fresh fixture**: single
+`clio-coder run --skill ... --autonomy full-auto --json`. Real fixture
+mismatch, deliberately not corrected: the prompt claimed a prior
+`scan_ecc` commit that does not exist in this fresh fixture (no Part 1 ran
+here). Phase 1 caught the discrepancy against real evidence (`grep` found
+no `scan_ecc`, git log has one seed commit, the docstring still says "not
+yet implemented"), tagged the claim `assumption - unverified`, and
+grounded the distillation in the real architecture doc and `scan_oom`'s
+actual code instead of fabricating verification of a commit that never
+happened - the skill's stated identity ("runtime truth... reconstruction
+wins") holding on a weaker/non-live model under direct pressure to just
+agree. Ran the full assumed-confirm monologue through Phase 2 and Phase 4
+(explicitly marked), wrote `.clio-coder/skills/signature-scanner/SKILL.md`
+(92 lines, valid frontmatter, canonical-lowercase tools, real placeholders,
+a concrete failure-behavior section, a validation scenario naming the still
+-owed real `clio-coder skills validate` pass). Zero safety blocks.
+
+**Still weak**: the skill-craft mid-run-load and dead-`bash`-validate bugs
+are confirmed fixed by re-test, but only against this one fixture shape.
+S2 (overlap with an installed skill) was not exercised this pass - this
+fixture's only installed skill is workflow-distiller itself, so the overlap
+check always correctly found nothing; a fixture with a second installed
+skill covering one step is still owed. S3 (no recurrence, offer to stop)
+was not exercised standalone. The tool-surface-lapse finding above is
+real, reproduced, and unresolved - it is the single biggest risk this pass
+surfaced, and it sits outside this skill (and outside `skills/`) entirely.

package/src/cli/configure-interop.ts

@@ -1,5 +1,7 @@
 import { stdout as output } from "node:process";
 import type { createInterface } from "node:readline/promises";
+import chalk from "chalk";
+
 import { readSettings } from "../core/config.js";
 import {
 	acceptInteropAgents,
@@ -12,6 +14,9 @@ import {
 	renderProposalEntry,
 } from "../domains/interop/index.js";
 import { askYesNo } from "./ask.js";
+import { railPrefix } from "./configure-target.js";
+import { createLifecyclePresenter, type LifecyclePresenter } from "./lifecycle-presenter.js";
+import { canSelect, promptMultiSelect } from "./select.js";
 import { printOk } from "./shared.js";
 
 function describe(proposal: InteropProposal): string {
@@ -30,38 +35,125 @@ function describe(proposal: InteropProposal): string {
 	return `${lines.join("\n")}\n`;
 }
 
+/** What one row of the picker says about an agent, beyond its name. */
+function proposalHint(proposal: InteropProposal): string {
+	const command = [proposal.entry.command, ...(proposal.entry.args ?? [])].join(" ");
+	return proposal.needsNetworkInstall ? `${command} (npx fetches the adapter on first use)` : command;
+}
+
+export interface InteropReviewStreams {
+	in: NodeJS.ReadableStream;
+	out: NodeJS.WritableStream;
+}
+
+export interface InteropReviewIo {
+	/** Readline interface for the numbered fallback. Null means nothing can answer. */
+	rl: ReturnType<typeof createInterface> | null;
+	streams?: InteropReviewStreams;
+	/** Rail to draw on when the caller already owns one. */
+	presenter?: LifecyclePresenter;
+	rail?: string;
+	/** Skip the "nothing to connect" line, for a caller whose transcript says enough. */
+	quiet?: boolean;
+}
+
+export interface InteropReviewOutcome {
+	code: number;
+	/** Agent ids that were wired, in the order they were written. */
+	wired: string[];
+	/** The user left the review without answering it. */
+	back: boolean;
+}
+
 /**
  * Review detected agents and, with an explicit answer per agent, wire them as
  * delegation peers. Without a TTY this prints the proposals and writes nothing:
  * no code path adds a peer the operator did not agree to.
+ *
+ * On a terminal this is one multi-select rather than a run of `[y/N]`
+ * questions. The questions were identical apart from a name, they hid how many
+ * there were, and once the second one was on screen the first could not be
+ * changed. The per-agent paragraph they each carried says the same two facts
+ * every time, so it is stated once above the list and the row carries what is
+ * actually different: the command Clio would run.
  */
-export async function runInteropReview(rl: ReturnType<typeof createInterface> | null): Promise<number> {
+export async function reviewInteropAgents(io: InteropReviewIo): Promise<InteropReviewOutcome> {
 	const report = await detectInteropAgents({ cwd: process.cwd(), probeVersion: true });
 	const proposals = interopProposals(report, readSettings());
 	if (proposals.length === 0) {
-		output.write("No new coding agents to connect.\n");
-		return 0;
+		if (!io.quiet) output.write("No new coding agents to connect.\n");
+		return { code: 0, wired: [], back: false };
 	}
-	if (rl === null) {
+	const streams = io.streams;
+	// The picker needs a terminal, not a readline interface; the caller that owns
+	// the rail deliberately keeps no readline open, because one left attached
+	// echoes the keys the picker is reading.
+	const interactive =
+		streams !== undefined && canSelect(streams.in as NodeJS.ReadStream, streams.out as NodeJS.WriteStream);
+	if (!interactive && io.rl === null) {
 		for (const proposal of proposals) output.write(describe(proposal));
 		output.write("\nRun `clio-coder configure --interop` on a terminal to connect any of these.\n");
-		return 0;
+		return { code: 0, wired: [], back: false };
 	}
+
 	const accepted: InteropAgentId[] = [];
 	const declined: InteropAgentId[] = [];
-	for (const proposal of proposals) {
-		output.write(describe(proposal));
-		const yes = await askYesNo(rl, `Add ${proposal.label} as delegation agent \`${proposal.entry.id}\`?`, false);
-		(yes ? accepted : declined).push(proposal.kind);
+
+	if (interactive && streams) {
+		const presenter = io.presenter ?? createLifecyclePresenter({ stream: streams.out });
+		const rail = io.rail ?? railPrefix(presenter.isPlain());
+		presenter.note(
+			`Clio found ${proposals.length === 1 ? "one coding agent" : `${proposals.length} coding agents`} it can delegate to. A peer receives your task text and never the project projection, and its tool calls are gated by Clio safety.`,
+		);
+		const result = await promptMultiSelect<InteropAgentId>({
+			heading: ["", chalk.bold("Delegate to any of these?")],
+			choices: proposals.map((proposal) => ({
+				value: proposal.kind,
+				label: proposal.label,
+				hint: proposalHint(proposal),
+			})),
+			railPrefix: rail,
+			backLabel: "back",
+			confirmLabel: "confirm",
+			clearOnExit: true,
+			input: streams.in as NodeJS.ReadStream,
+			output: streams.out as NodeJS.WriteStream,
+		});
+		if (result.kind === "back") return { code: 0, wired: [], back: true };
+		if (result.kind === "quit") return { code: 0, wired: [], back: false };
+		for (const proposal of proposals) {
+			(result.values.includes(proposal.kind) ? accepted : declined).push(proposal.kind);
+		}
+	} else if (io.rl !== null) {
+		for (const proposal of proposals) {
+			output.write(describe(proposal));
+			const yes = await askYesNo(io.rl, `Add ${proposal.label} as delegation agent \`${proposal.entry.id}\`?`, false);
+			(yes ? accepted : declined).push(proposal.kind);
+		}
 	}
+
+	const wired: string[] = [];
 	if (accepted.length > 0) {
 		const result = acceptInteropAgents(accepted, report);
-		for (const diagnostic of result.diagnostics) output.write(`note: ${diagnostic}\n`);
-		for (const id of result.wired) printOk(`delegation agent ${id} added; use \`/delegate ${id} <task>\``);
+		for (const diagnostic of result.diagnostics) {
+			if (io.presenter) io.presenter.warn(diagnostic);
+			else output.write(`note: ${diagnostic}\n`);
+		}
+		for (const id of result.wired) {
+			wired.push(id);
+			// A caller with a rail lists what it wrote in its own completion rows.
+			if (!io.presenter) printOk(`delegation agent ${id} added; use \`/delegate ${id} <task>\``);
+		}
 	}
 	if (declined.length > 0) {
 		declineInteropAgents(declined, report);
-		output.write(`Declined ${declined.join(", ")}; Clio stays quiet about them until their version or path changes.\n`);
+		const line = `Declined ${declined.join(", ")}; Clio stays quiet about them until their version or path changes.`;
+		if (io.presenter) io.presenter.note(line);
+		else output.write(`${line}\n`);
 	}
-	return 0;
+	return { code: 0, wired, back: false };
+}
+
+export async function runInteropReview(io: InteropReviewIo): Promise<number> {
+	return (await reviewInteropAgents(io)).code;
 }

package/src/cli/configure-oauth.ts

@@ -0,0 +1,57 @@
+/**
+ * The browser sign-in half of `clio-coder configure`.
+ *
+ * This stays on readline rather than the arrow-key prompts: an OAuth flow ends
+ * with a code the user pastes, and there is no list to choose from. It lives in
+ * its own file so the first-run wizard can start a login without importing the
+ * rest of configure.ts.
+ */
+import type { createInterface } from "node:readline/promises";
+
+import { openAuthStorage } from "../domains/providers/auth/index.js";
+import type { RuntimeDescriptor } from "../domains/providers/types/runtime-descriptor.js";
+import { createDelayedManualCodeInput } from "./oauth-manual-input.js";
+import { promptOAuthSelection } from "./oauth-select.js";
+import { credentialWriteFailed, printError, printOk } from "./shared.js";
+
+export async function loginOAuthRuntime(
+	rl: ReturnType<typeof createInterface>,
+	runtime: RuntimeDescriptor,
+): Promise<boolean> {
+	const auth = openAuthStorage();
+	if (runtime.authNotice) process.stdout.write(`note: ${runtime.authNotice}\n`);
+	const manualCodeInput = createDelayedManualCodeInput(
+		rl,
+		"Paste verification code if browser callback does not complete automatically: ",
+	);
+	try {
+		await auth.login(runtime.oauthProviderId ?? runtime.id, {
+			onAuth: ({ url, instructions }) => {
+				process.stdout.write(`\nOpen: ${url}\n`);
+				if (instructions) process.stdout.write(`${instructions}\n`);
+				process.stdout.write("Waiting for the browser callback. A manual code prompt will appear if needed.\n");
+			},
+			onDeviceCode: ({ verificationUri, userCode }) => {
+				process.stdout.write(`\nOpen: ${verificationUri}\n`);
+				process.stdout.write(`Enter code: ${userCode}\n`);
+			},
+			onPrompt: async (prompt) => {
+				const answer = await rl.question(`${prompt.message}${prompt.allowEmpty ? " " : ": "}`);
+				return prompt.allowEmpty ? answer : answer.trim();
+			},
+			onSelect: (prompt) => promptOAuthSelection(rl, prompt),
+			onManualCodeInput: manualCodeInput.onManualCodeInput,
+			onProgress: (message) => {
+				process.stderr.write(`${message}\n`);
+			},
+		});
+		if (credentialWriteFailed(auth, `credential for ${runtime.id} was not stored`)) return false;
+		printOk(`authenticated ${runtime.id}`);
+		return true;
+	} catch (error) {
+		printError(error instanceof Error ? error.message : String(error));
+		return false;
+	} finally {
+		manualCodeInput.cancel();
+	}
+}