@oisincoveney/pipeline 2.2.0 → 2.3.1

package/.agents/skills/critique/SKILL.md

@@ -9,6 +9,8 @@ description: Conducts multi-axis code review. Use before merging any change. Use
 
 Multi-dimensional code review with quality gates. Every change gets reviewed before merge — no exceptions. Review covers correctness, readability, architecture, security, performance, and the [[quality-gate]] smell check.
 
+**A review is the act of checking, not the act of approving.** "LGTM" with no findings and no evidence you walked the axes is not a review — it is a rubber stamp wearing one. The checkable signal (borrowed from [[doubt]]'s anti-theater rule): if the diff is non-trivial and you produced *zero* findings across all six axes, you almost certainly didn't review it — look again before you approve. You are also entitled to the upstream artifacts: the ticket's acceptance criteria, the test evidence ([[test]]), and the quality-gate evidence ([[quality-gate]]). A change that arrives without them isn't ready for review — send it back rather than reviewing a claim you can't check.
+
 **The approval standard:** Approve a change when it definitely improves overall code health, even if it isn't perfect. Perfect code doesn't exist — the goal is continuous improvement. Don't block a change because it isn't exactly how you would have written it. If it improves the codebase and follows the project's conventions, approve it.
 
 ## When to Use
@@ -225,6 +227,12 @@ After any refactoring or implementation change, check for orphaned code:
 
 Don't leave dead code lying around — it confuses future readers and agents. But don't silently delete things you're not sure about. When in doubt, ask.
 
+```
+DEAD CODE IDENTIFIED:
+- formatLegacyDate() in src/utils/date.ts — replaced by formatDate()
+- OldTaskCard component in src/components/ — replaced by TaskCard
+- LEGACY_API_URL constant in src/config.ts — no remaining references
+→ Safe to remove these?
 ```
 
 ## Specialized review lenses
@@ -236,12 +244,6 @@ Use these lenses inside the same review, not as separate top-level skills:
 - **Quality gate:** load [[quality-gate]] and block workarounds, unsafe casts/assertions, type-system escapes, massive branching, duplicated condition clusters, shallow wrappers, dead code, and disabled checks.
 - **Requesting review:** package the diff with a short description, requirements/plan, base/head SHAs, verification run, and known risks. Do not hand the reviewer your whole session history.
 - **Receiving review:** verify each finding against the code before implementing it. Fix valid Critical and Important issues; push back with evidence when a comment is technically wrong.
-DEAD CODE IDENTIFIED:
-- formatLegacyDate() in src/utils/date.ts — replaced by formatDate()
-- OldTaskCard component in src/components/ — replaced by TaskCard
-- LEGACY_API_URL constant in src/config.ts — no remaining references
-→ Safe to remove these?
-```
 
 ## Review Speed
 

package/.agents/skills/diagnose/SKILL.md

@@ -57,6 +57,8 @@ Write the regression test **before** the fix — *if there is a correct seam* fo
 
 Then ask: **what would have prevented this?** If the answer is architectural — no good seam, tangled callers, hidden coupling — hand off to [[improve]] with specifics, *after* the fix is in, when you know the most.
 
+**The artifacts you emit are the deterministic feedback loop and the winning hypothesis.** The loop is what proves the fix ([[fix]] and [[verify]] re-run it against the original scenario); the winning hypothesis is the confirmed root cause [[fix]] builds on. A "diagnosed" claim with no reusable loop and no written hypothesis is a story, not a diagnosis — you have not finished this skill until both exist.
+
 ## The short version
 
 Build a fast deterministic feedback loop — that's 90% of it. Reproduce the *real* bug. 3–5 falsifiable hypotheses before testing. Instrument one variable at a time, tagged. Regression-test at a correct seam (or flag its absence). Clean up, and write down the hypothesis that won.

package/.agents/skills/doubt/SKILL.md

@@ -161,7 +161,7 @@ Acknowledge the skip in the output (*"Proceeding with single-model findings only
 **Non-interactive contexts** (CI, `/loop`, autonomous-loop, scheduled runs):
 
 - Cross-model is **skipped**, and the skip must be **announced** in the output: *"Cross-model skipped: non-interactive context."*
-- **Never invoke an external CLI without explicit user authorization** — this is a load-bearing safety property.
+- **Never invoke a separate external reviewer/model CLI without explicit user authorization** — this is a load-bearing safety property for cross-model review tools. This does not apply to normal repository commands, package scripts, Git/GitHub delivery, CI, deployment, or verification commands required by the assigned task.
 
 Cross-model adds cost, latency, and tool fragility. The agent surfaces the choice every cycle; the user decides whether this artifact warrants it.
 
@@ -202,7 +202,7 @@ If 3 cycles is "obviously insufficient" because the artifact is large: the artif
 | "Two opinions are always better than one" | Not when the second has less context and produces noise. Reconcile, don't defer. |
 | "The reviewer disagreed so I was wrong" | The reviewer lacks your context — disagreement is information, not verdict. Re-read the artifact, classify, then decide. |
 | "Cross-model is always better" | Cross-model catches blind spots a single model shares with itself, but it adds cost and tool fragility. Offer it every interactive doubt cycle — the user decides whether the artifact warrants it. The agent's job is to surface the choice, not to gate it. |
-| "User said yes once, so I can keep invoking the CLI" | Each invocation is its own authorization. The artifact, the prompt, and the flags change between calls — re-confirm the exact command with the user before every run. |
+| "User said yes once, so I can keep invoking an external reviewer CLI" | Each reviewer invocation is its own authorization. The artifact, the prompt, and the flags change between calls — re-confirm the exact reviewer command with the user before every run. |
 
 ## Red Flags
 
@@ -240,4 +240,4 @@ After applying doubt-driven development:
 - [ ] A stop condition was met (trivial findings, 3 cycles, or user override)
 - [ ] In interactive mode, cross-model was **explicitly offered** to the user (regardless of artifact stakes) and the response was acknowledged in the output
 - [ ] In non-interactive mode, cross-model was skipped and the skip was announced
-- [ ] Any external CLI invocation was preceded by a PATH check, a working-binary test, syntax confirmation with the user, and explicit authorization to run
+- [ ] Any separate external reviewer/model CLI invocation was preceded by a PATH check, a working-binary test, syntax confirmation with the user, and explicit authorization to run

package/.agents/skills/execute/SKILL.md

@@ -15,6 +15,15 @@ Use this skill when the user hands you a ticket, issue, plan item, or direct imp
 
 Do not batch the work horizontally: no "models first, then API, then UI, then tests." A completed increment should be small, coherent, and runnable: one observable behaviour, through the real public interface, with the tests and verification that prove it.
 
+## The completion contract
+
+You took the work. You finish the work. This skill exists to stop the two failures that look like progress but aren't:
+
+- **You do not silently abandon a unit.** Stopping mid-ticket and handing back half the work with a cheerful summary is the failure, not the fallback. If you genuinely cannot finish, that is a **loud, structured escalation** (see below) — every acceptance criterion marked met-with-evidence or unmet-with-blocker — never a quiet stop and never a reframing of "I gave up" as "here's where I got to."
+- **"Partial" is never reported as "done."** Done means *every* acceptance criterion is satisfied and evidenced. One unmet criterion means the work is not done — it is in-progress or escalated. There is no rounding up. "Mostly works", "the happy path passes", "should be fine" are partial; say so in those words.
+
+You also inherit the chain of custody from the skills upstream of you. Before you build, the artifacts they emit must exist and you must read them: the **source list** from [[research]] for any unfamiliar API, the **evaluated-candidates note** from [[library-first-development]] for anything you might hand-roll, and the **binding Definition of Done** from the ticket ([[scope]]). Missing artifact = the upstream work wasn't done = you generate it now or escalate, you do not paper over it.
+
 ## Phase 0 — Route to the right skills
 
 Execute is an orchestrator. Decide what kind of work this is, then load only the skills that apply:
@@ -146,6 +155,18 @@ Stop and surface the problem when:
 
 Do not keep looping. Do not guess. Stop, say what is happening, and ask.
 
+**Escalation has a shape — use it; a vague "I got stuck" is not an escalation.** When you stop short of done, hand back exactly this:
+
+```text
+Status: BLOCKED (not done)
+Met:    - <criterion> — <evidence: command/output/assertion>
+        - <criterion> — <evidence>
+Unmet:  - <criterion> — <the specific blocker, what you tried, what you need>
+Need:   <the decision, access, or input that unblocks it>
+```
+
+Every acceptance criterion appears in exactly one of Met or Unmet. A criterion you can't account for is itself a finding. This is the *only* acceptable way to end a unit without finishing it — and it is a genuine, valued outcome, far better than a silent partial dressed up as success.
+
 ## Phase 5 — Complete the work
 
 Before claiming done:

package/.agents/skills/fix/SKILL.md

@@ -22,7 +22,9 @@ Also forbidden: making the compiler, linter, or test suite shut up without fixin
 
 ## Before you write the fix: walk the ladder
 
-You should already know the root cause (via [[trace]]). Confirm where the fix belongs:
+**Precondition:** you have [[trace]]'s confirmed root cause in hand — the three-level explanation, the reverse-test result, the class-not-instance statement. If you don't, you are not fixing yet, you are guessing; go back to [[trace]]. "I'm pretty sure it's X" is not a confirmed root cause. A fix without one is the bandaid this skill exists to forbid, just wearing a confident face.
+
+With the cause confirmed, walk the ladder to place the fix:
 
 1. **Symptom.** State the user-visible fault precisely — the symptom, not your guess at the cause.
 2. **Proximate cause.** Which exact code is wrong — and is the defect at the line you'd patch, or upstream of it? The line that *fires* the error is rarely the line that *contains* it.
@@ -47,6 +49,8 @@ A fix is not "fixed" until you have *watched* it work:
 
 No "should work", "probably fixed", "that ought to do it". If you haven't run it and read the output this session, you haven't verified it — say what you actually know.
 
+**The artifact you emit is the red→green evidence** — the test failing before, passing after, the original repro gone, the suite still green. [[verify]] consumes it and will not pass a "fixed" claim that can't produce it. "Fixed" is a claim about evidence you can show, not a feeling about code you wrote.
+
 ## The short version
 
 - Root-cause fix, or stop and escalate. No third option.

package/.agents/skills/grill/SKILL.md

@@ -30,7 +30,9 @@ Record a decision as an **ADR only when all three hold**: it's hard to reverse,
 
 ## When it's done
 
-The plan is grilled when you can't find a term that two people would read differently, a boundary that a scenario can break, or an assumption the code contradicts. Hand the hardened plan back to [[scope]] for decomposition — every ambiguity you killed here is a ticket that won't stall mid-implementation.
+"It looks fine" is not grilled — grilled means you *ran the interview* and came up empty: you went looking for a term two people would read differently, a boundary a scenario can break, an assumption the code contradicts, and against the actual repo and glossary you could no longer find one. Declaring a plan grilled without having hunted is the failure this skill exists to prevent; the absence of questions is only meaningful after the search.
+
+**The artifact you emit is the hardened plan plus the resolutions** — the sharpened terms (written into the glossary), the boundary decisions, the code-contradictions found and closed. [[scope]] consumes it: a plan handed to decomposition without evidence it was actually grilled is a guess wearing a checklist, and every ambiguity you *didn't* kill here becomes a ticket that stalls mid-implementation. Hand the hardened plan back to [[scope]].
 
 ## The short version
 

package/.agents/skills/improve/SKILL.md

@@ -32,6 +32,8 @@ Surface the **deepening opportunities** as candidates — for each: the problem
 
 Use a strict maintainability lens when looking for candidates: giant files, repeated condition clusters, pass-through wrappers, hidden shared state, confusing compatibility shims, and branches that grow by accretion usually indicate a missing deeper module or misplaced seam.
 
+**Every candidate carries its deletion-test verdict as evidence, not a vibe.** "This feels shallow" is not a finding; "delete this and the complexity redistributes across its three callers — the boundary is misplaced" is. A candidate without a stated deletion-test result is an opinion, and the user can't act on opinions. **The artifact you emit is this candidate report** — [[scope]] consumes it to decide where depth and seams live *before* cutting tickets, so a candidate that can't survive the deletion test never becomes an architecture ticket built on a guess.
+
 ## Phase 3 — Grill the chosen design
 
 Once the user picks a candidate, design the interface *with* them — and grill it (this is [[grill]] pointed at a design): what are the real constraints? What will the seam need to support a year from now? Update the glossary inline as new terms settle. If a candidate is *rejected* for a reason worth preserving — a trade-off the next person would otherwise re-open — record it as an ADR (and only then: hard to reverse, surprising, genuine trade-off).

package/.agents/skills/inspect/SKILL.md

@@ -15,3 +15,5 @@ When a generated Moka command is active, follow that command's dispatch instruct
 - summarize findings with file references;
 - avoid edits, commits, generated output, or destructive commands;
 - report uncertainty when the repository does not contain enough evidence.
+
+**Every claim about the repo cites the `file:line` you actually read this session — not what you assume the code probably does.** Inspection that describes the codebase from memory or inference, without having opened the files, is the same failure [[research]] forbids for external sources: a confident guess dressed as a finding. If you didn't read it, say so or go read it. "The repo doesn't contain enough evidence to answer" is a valid, valued result; a fabricated summary is not.

package/.agents/skills/library-first-development/SKILL.md

@@ -9,6 +9,21 @@ Default position: **someone has probably already built this, better, and maintai
 
 This is not "add dependencies carelessly." It's "don't reinvent the wheel, *and* don't bolt on a junk wheel." Library-driven development means: use the ecosystem's maintained code path first, prefer mechanical generation for mechanical files, then vet hard.
 
+## The contract
+
+You may not hand-roll, scaffold by hand, or call something "trivial" until **every** line below is true *and recorded*:
+
+- **You named the capability in one sentence** and checked the project first — dependency files, framework features, local scripts, `bin/`, package scripts, Makefiles, existing generated-file conventions.
+- **You evaluated ≥2 real maintained candidates** via [[research]] — actual options from primary sources, not a half-remembered name — and vetted the front-runner against the criteria below.
+- **For mechanical files, you checked the official CLI/generator** before hand-creating anything.
+- **If you still hand-roll or hand-create, the reason is written down** — in a code comment or the PR, not in your head: the specific candidates/CLI you checked and the specific disqualifier for each.
+
+**"Trivial" is not a feeling — it is a test you can fail.** Trivial means: you can *enumerate every edge case out loud* and there is only a handful, with no ongoing maintenance burden. If you cannot list the edge cases, it is **not** trivial — that uncertainty is exactly the class of problem libraries exist to own. "It's just a few lines" about parsing, dates, money, time, auth, retries, or encoding is the tell that you're about to hand-roll a bug.
+
+**Burden of proof is on hand-rolling, not on the library.** "I'd rather just write it" is not a disqualifier. "It was faster to write by hand" is not a disqualifier. The exit costs a written, specific reason precisely so that using the maintained path is the path of least resistance.
+
+**The artifact you emit is the evaluated-candidates note** — what you checked, what you chose, why. [[execute]] and [[critique]] read it and are entitled to reject a hand-rolled implementation of a standard hard problem that arrives without one. This skill consumes the source list from [[research]]: you find candidates there, you decide here.
+
 ## The workflow
 
 1. **Name the capability** in one sentence ("parse and diff ISO-8601 durations", "rate-limit outbound calls with backoff", "create a database migration for a new table"). If a mature library or framework tool category exists for it, you're in scope.
@@ -72,11 +87,11 @@ curl -s "https://api.scorecard.dev/projects/github.com/<owner>/<repo>" | jq '{sc
 
 ## When hand-rolling IS the right call
 
-Build it yourself only when one of these is true — and write the reason in a comment or the PR:
+Build it yourself only when one of these is true — and the reason is written in a comment or the PR, per the contract:
 
 - No maintained library actually fits (you evaluated real ones; document which and why they fell short).
 - No official/local CLI can safely generate the mechanical files (you checked it; document the command or docs).
-- The capability is genuinely trivial (a few lines, no edge cases, no ongoing maintenance burden).
+- The capability is genuinely trivial *by the test above* — you enumerated every edge case and there are only a handful, with no ongoing maintenance burden.
 - A dependency would be reckless here (unmaintained, unacceptable license, security-critical surface you must control).
 
 "I'd rather just write it" is not a reason. "I evaluated `x`, `y`, `z`; `x` is abandoned, `y` pulls 40 transitive deps for a 10-line need, `z`'s license is GPL and we ship proprietary — so a 12-line inline implementation is the right trade-off" *is* a reason.

package/.agents/skills/migrate/SKILL.md

@@ -110,6 +110,8 @@ Migrate consumers one at a time, not all at once. For each consumer:
 
 ### Step 4: Remove the Old System
 
+Removal is the one irreversible step here, so it carries the highest evidence bar — and "I assume nothing uses it anymore" is exactly the failure that deletes something still in production. You remove on **measured** zero usage (metrics, logs, dependency analysis you ran this session), never on the belief that migration "should be" complete. Before deleting anything, [[verify]] applies: the claim "zero active consumers" is a claim that needs fresh evidence, not a hope. If you cannot measure usage, you cannot safely remove — say so and stop.
+
 Only after all consumers have migrated:
 
 ```

package/.agents/skills/optimize/SKILL.md

@@ -37,6 +37,8 @@ Measure before optimizing. Performance work without measurement is guessing —
 5. GUARD    → Add monitoring or tests to prevent regression
 ```
 
+**The artifact you emit is the before/after measurement pair — specific numbers, same conditions.** "It's faster now" with no baseline is not an optimization, it is a hope; [[verify]] and [[critique]] consume the numbers and an optimization that can't show a measured delta did not happen. This cuts both ways: a "fix" that didn't move the number you measured is either aimed at the wrong bottleneck or wasn't needed — revert it rather than keeping complexity that bought nothing. No baseline → no claim. No re-measure → not done.
+
 ### Step 1: Measure
 
 Two complementary approaches — use both:

package/.agents/skills/orchestrate/SKILL.md

@@ -0,0 +1,83 @@
+---
+description: Local multi-agent orchestrator — decompose a task and fan it out to the MoKa specialist roster on the current machine instead of submitting to the remote Moka pipeline. The local twin of the MoKa Orchestrator. On Claude Code, dispatch each agent with `opencode run`; on OpenCode, spawn native Task subagents. Use when the user wants parallel specialist agents driven locally rather than as Argo/k8s jobs.
+name: orchestrate
+---
+
+# Orchestrate
+
+The **local twin of the MoKa Orchestrator**. The MoKa Orchestrator decomposes a task and submits a schedule to Argo/k8s via `moka submit`, where the runtime executes it as DAG jobs on the cluster. Orchestrate runs the **same roster, same loop, on the current machine** — no schedule, no `moka submit`, no Argo. It is the hands-on, here-and-now path for getting work done through specialist agents.
+
+Use this skill when the user wants real work driven through **parallel specialist agents locally**: a task large enough to decompose into research / test / implement / verify lanes, where you stay the controller and the agents do the labor.
+
+## When NOT to use
+
+- **Durable, reproducible, or cluster-scale runs** → use [[quick]] or [[execute]] (these submit through `moka submit`). Orchestrate is ephemeral and local; it leaves no schedule artifact.
+- **Trivial single-threaded work** → just do it inline. Spawning agents for a one-line change is pure overhead.
+- **You need package gates enforced as part of a pipeline run** → that is the remote path's job. Orchestrate still *uses* the gate agents (Verifier, Acceptance Reviewer, Thermo Nuclear Reviewer) but does not replace pipeline-level gating.
+
+## The roster
+
+The same specialist agents the MoKa pipeline uses, mirrored locally. Each is `mode: all`, so it works both as an `opencode run --agent` subprocess and as a native Task subagent.
+
+| Role        | Agent name              | Writes        | Job |
+|-------------|-------------------------|---------------|-----|
+| Research    | `MoKa Researcher`       | `research.json` only | Read-only; map the codebase, gather context, extract acceptance criteria. |
+| Test        | `MoKa Test Writer`      | `*.test.ts` only | Write failing tests that describe the desired behaviour. |
+| Implement   | `MoKa Code Writer`      | `src/**` only | Smallest production change that makes the failing tests pass. |
+| Verify      | `MoKa Verifier`         | nothing       | Run checks, judge the diff against AC, emit `PASS`/`FAIL` with evidence. |
+| Acceptance  | `MoKa Acceptance Reviewer` | nothing    | Audit the change against each acceptance criterion; `PASS`/`FAIL` with evidence. |
+| Code review | `MoKa Thermo Nuclear Reviewer` | nothing | Final code-quality review of the integrated change — the heavyweight reviewer, distinct from the AC audit. |
+| Learn       | `MoKa Learner`          | memory only   | Store durable lessons from the completed run (qdrant memory). The pipeline's LEARN phase. |
+| Inspect     | `MoKa Inspector`        | nothing       | Read-only repository inspection / explanation. |
+
+Keep each agent inside its lane — never ask the Code Writer to touch tests, or a reviewer to write files. The lane boundaries are what make fan-out safe. (`MoKa Schedule Planner` is intentionally **not** in this roster: it plans the DAG for remote `moka submit`; locally *you* do that in the Plan step.)
+
+## Dispatch by host
+
+The orchestration **doctrine below is identical on every host**. Only the spawn mechanism differs — select the branch for the host you are actually running in.
+
+### On Claude Code → `opencode run`
+
+Spawn each roster member as a headless OpenCode subprocess and read its JSON back:
+
+```sh
+opencode run --agent "MoKa Code Writer" --format json \
+  "<scoped task + acceptance criteria + paths to read>"
+```
+
+- Select the roster member with `--agent "<exact name>"` (names from the table above).
+- Use `--format json` so the agent's structured result comes back machine-readable; parse it, do not eyeball it.
+- **Parallelize independent lanes**: launch each `opencode run` as a background Bash process (one tool call per lane in the same turn), then collect. Run dependent lanes only after their inputs land.
+- Pass context by path, not by paste — agents read the worktree directly. Hand them the files/AC the Researcher produced.
+- `--model` / `--variant` only when a lane genuinely needs a different tier; otherwise inherit.
+
+### On OpenCode → native Task subagents
+
+You are already inside OpenCode — do not shell out to `opencode run`. Spawn the roster directly with the native **Task** tool, selecting the agent by the same name:
+
+- `task` → `MoKa Researcher`, `MoKa Test Writer`, `MoKa Code Writer`, `MoKa Verifier`, `MoKa Acceptance Reviewer`, `MoKa Thermo Nuclear Reviewer`, `MoKa Learner`.
+- Issue independent Task calls together so they run concurrently; sequence dependent ones.
+- Each subagent's structured output returns to you as the controller — gather, do not re-do their work.
+
+## The loop
+
+Whichever host you are on, run the same six steps:
+
+1. **Plan** — Decompose the task into a DAG of agent lanes. Model parallelism *structurally*: independent lanes fan out together, dependents wait on their inputs (research → tests → implementation → verify). Do not invent JSON-pointer fanout; nest the work as real lanes.
+2. **Dispatch** — Fan out per the host branch above. Scope each agent tightly: one job, its lane's write boundary, explicit acceptance criteria.
+3. **Gather** — Collect each agent's structured output (`research.json`, the Verifier's verdict JSON, etc.). Treat the returned artifact as the source of truth.
+4. **Gate** — Run `MoKa Verifier` (checks vs AC), `MoKa Acceptance Reviewer` (audits each acceptance criterion), and `MoKa Thermo Nuclear Reviewer` (final code-quality review). Do **not** accept work on a `FAIL` from any gate. Loop the relevant lane (re-dispatch Code Writer with the failure evidence) rather than papering over it.
+5. **Learn** — Once the gates pass, run `MoKa Learner` to store durable lessons from the run (qdrant memory) when there is something worth reusing. This mirrors the canonical pipeline's LEARN phase; skip it only when the run produced nothing reusable.
+6. **Synthesize** — Report only the evidence the agents actually returned: what passed, what the diff is, what the reviewers proved. Never fabricate or assume an outcome an agent did not report.
+
+## Rules
+
+- **Doctrine is host-neutral; only the Dispatch section is host-specific.** Do not leak `opencode run` syntax into an OpenCode run or Task-tool talk into a Claude run.
+- **You are the controller, not a worker.** Decompose, dispatch, gate, synthesize. Let the specialists do the labor inside their lanes.
+- **Evidence only.** Report what agents returned. A green claim needs a Verifier `PASS` with evidence behind it — see [[verify]].
+- **Respect lane write boundaries.** Researcher/Verifier/both Reviewers write no repo files (Researcher emits only `research.json`; Learner writes only to memory); Test Writer touches only tests; Code Writer touches only `src/`. Mixed lanes corrupt parallel fan-out.
+- **Local, not durable.** If the user needs a reproducible cluster run or a schedule artifact, route to [[quick]] / [[execute]] instead.
+
+## The short version
+
+Orchestrate is `moka submit` brought home: same roster, same decompose → dispatch → gather → gate → learn → synthesize loop, run on this machine. On Claude Code each agent is an `opencode run --agent` subprocess; on OpenCode each is a native Task subagent. You stay the orchestrator — fan out the lanes, gate on real verifier *and* reviewer evidence, capture lessons via the Learner, and report only what the agents proved.

package/.agents/skills/quality-gate/SKILL.md

@@ -81,6 +81,8 @@ Acceptable evidence depends on the repo, but use what exists:
 
 If the repo lacks tool enforcement, do a manual gate and report that it was manual.
 
+**This evidence is the artifact you emit** — the clean typecheck/lint/test output plus the diff review. [[verify]] and [[critique]] consume it; "quality-gate clean" asserted without it is exactly the "tests pass while casts and workarounds remain" failure the gate exists to catch. A manual gate is valid only if you say it was manual and list what you actually inspected.
+
 ## The short version
 
 If a change needs a cast, assertion, workaround, huge branch, duplicate condition cluster, shallow wrapper, or disabled tool to pass, the design is not done. Fix the data flow, interface, module boundary, or tool-supported setup. If the proper fix is bigger than the task, stop and say that.

package/.agents/skills/quick/SKILL.md

@@ -16,3 +16,5 @@ moka submit --quick <task description>
 ```
 
 The quick path should stay compact: generate or submit the quick schedule, preserve package-owned gates, and report only the evidence returned by the pipeline runtime.
+
+**Compact is not undisciplined.** "Quick" describes the *size* of the task, not a licence to skip the gates — the same completion contract applies: the work is finished and evidenced, or it is an explicit escalation, never a silent partial. Preserve every package-owned gate; reporting "done" still means reporting the runtime's actual evidence, not your assumption that it passed. If a task turns out to need real planning, a failing-test loop, or a root-cause investigation, it was never a quick task — route it to [[scope]], [[test]], or [[trace]] instead of forcing it through this path to save steps.

package/.agents/skills/research/SKILL.md

@@ -7,12 +7,24 @@ description: Use whenever researching a technical question — a library, tool,
 
 The failure mode this kills: one search, then everything else confabulated from training data, padded with SEO articles written to rank for agents rather than to be correct. That produces confident, outdated, wrong answers. Research means *reading current primary sources*, not pattern-matching memory.
 
-## Two hard rules
+## The contract
 
-1. **No coasting.** One search is never the research. Run several varied queries, open multiple sources, and read them. Any claim about current or version-specific behaviour must trace to a source you actually opened *this session* — not to training data. If you're stating something from memory, say so, then go verify it.
-2. **Source quality is gated.** Prefer primary, high-signal sources. Actively distrust and avoid agent-bait. A wrong source is worse than no source.
+You have not researched until **every** line below is true *and you can show it*. This is the floor, not the aspiration:
 
-## Source tiers
+- **≥3 sources opened this session, ≥1 of them Tier-A primary** (official docs, source code, changelog/release notes). One search is not research. One blog is not research. If you ran one query and stopped, you have not started.
+- **≥2 varied queries** from different angles — not the same query reworded. A single search that happened to return a good link is luck, not method.
+- **Every load-bearing claim traces to a source you opened this session** — a pasteable URL, not "I think the docs say." If you didn't open it this session, it does not count as researched.
+- **Memory is labelled at the claim, inline.** Anything you state from training data rather than a source you opened this session reads `[unverified — from memory]` *on that sentence* — not in a footnote, not a blanket "some of this may be dated" at the end. The specific claim wears the label.
+
+**The artifact you emit is the source list** — what you opened, its tier, and its date. The next skill in the chain ([[library-first-development]], or the implementer acting on your answer) reads it and is entitled to reject a handoff without one. A research result with no source list is a memory dump wearing a lab coat.
+
+### The "unverified" exit is honest only when shown
+
+"I couldn't confirm this" is a valid, valued answer — *when you show the trail*: the queries you ran and the sources you opened that failed to settle it. An "unverified" label with no visible search behind it is not honesty, it is coasting with a disclaimer attached. Earn the label by searching first; a confident guess and a lazy shrug are the same failure in different clothes.
+
+## Source quality is gated
+
+Prefer primary, high-signal sources. Actively distrust and avoid agent-bait. A wrong source is worse than no source.
 
 **Tier A — primary, trust first:**
 - Official docs, specs, standards, RFCs for the actual thing.
@@ -44,7 +56,7 @@ If a page fails the smell test, drop it and find a Tier A/B source instead. Don'
 - Cross-check every load-bearing claim against a primary source.
 - When sources disagree, say so and explain which you trust and why — don't silently pick one.
 - **Cite what you actually read** (the URL/source), not where you *think* the information lives.
-- If you couldn't verify something, label it **unverified** rather than stating it as fact. "I couldn't confirm this" is a valid, valued answer; a confident guess is not.
+- A claim you couldn't verify is labelled **unverified** per the contract above — shown, not shrugged.
 
 ## Source-driven implementation
 
@@ -52,7 +64,7 @@ When research feeds framework-specific code, the implementation decision must tr
 
 ## When this feeds a build decision
 
-Choosing a library/tool from this research? Hand the candidates to [[library-first-development]] for the vetting step — adoption, maintenance, bus factor, license, security.
+Choosing a library/tool from this research? Hand the candidates *and the source list* to [[library-first-development]] for the vetting step — adoption, maintenance, bus factor, license, security.
 
 ---
 

package/.agents/skills/schedule-graph-shaping/SKILL.md

@@ -14,3 +14,11 @@ Use this skill to shape Moka schedules as explicit DAGs instead of blindly expan
 - Prefer parallel nodes only when dependencies and shared file ownership allow safe concurrency.
 - Keep gates explicit and downstream of the work they verify.
 - Make reruns deterministic by naming nodes after stable work units, not transient agent attempts.
+
+## The gates are load-bearing, not decorative
+
+This skill shapes the graph that drains [[scope]]'s tickets, so it carries their binding contract into the DAG — the graph is where "partial ≠ done" becomes structural:
+
+- **Every implementation node has a verification gate downstream of it that encodes the ticket's Definition of Done.** A deliverable is not "complete" in the graph until its gate node passes on real evidence ([[verify]]). A graph with implementation nodes and no verifying gates has scheduled the exact silent-partial failure the rest of the chain exists to prevent.
+- **Gates do not get pruned to make the graph look parallel.** Dropping or merging a gate to flatten the DAG removes the evidence requirement, not just a node. If two nodes can't run in parallel without skipping a gate, they aren't parallel — sequence them.
+- **A gate must be reachable and falsifiable.** A "verification" node that can't actually fail (no command, no criterion, no evidence) is theatre — it satisfies the graph's shape while proving nothing. Name what it checks and what output proves it.

package/.agents/skills/scope/SKILL.md

@@ -7,6 +7,17 @@ description: Use BEFORE starting any non-trivial feature, change, or fix — whe
 
 A plan is finished when an agent fleet could drain it without you in the room: every ticket is a single unit of work, spawnable in parallel, with acceptance criteria that say exactly when it's done, and a dependency graph that makes the fan-out order computable rather than guessed. Planning *is* the work — the tickets are just its output. Coast on the planning and you pay for it N times over, once per agent that picks up an under-specified ticket.
 
+## The contract
+
+The output of this skill is not "tickets." It is a set of **binding contracts** that travel to the draining agents. A ticket binds only if **every** line is true:
+
+- **It carries a Definition of Done the implementer executes and may not renegotiate** — every acceptance criterion, plus the concrete evidence that proves each one (the command, the assertion, the observed output). The agent's job is to satisfy the contract you wrote, not to decide mid-worktree that something else is "good enough."
+- **"Partial" is not a state the ticket permits.** A ticket is met or it is an explicit, structured escalation back to you ("criteria 1–3 met with this evidence; criterion 4 blocked by X") — never a silent stop, never a quiet hand-back of half the work. Build this expectation *into the ticket* so the draining agent inherits it.
+- **It is satisfiable only by producing per-criterion evidence.** If an agent could plausibly mark the ticket done without showing evidence for each criterion, the ticket is under-specified — that gap is *yours* to close now, not the implementer's to improvise later.
+- **It names the libraries/CLIs and the smell constraints for its slice** (below), so deviation requires a recorded reason the reviewer reads — not a silent choice the agent makes alone.
+
+This is the lever on the symptom you're trying to kill: an agent "does whatever it wants" or "stops without finishing" exactly when the ticket left it room to. A binding DoD with per-criterion evidence and no "partial" exit removes the room. Tickets you emit are read by [[execute]] (which drains them) and [[verify]] (which gates them) — they enforce this contract; you author it.
+
 ## The discipline
 
 Don't decompose first. Decomposition is step 5. Walk the work down to bedrock, *then* cut it into pieces.
@@ -42,7 +53,7 @@ This is the constraint everything else serves. **Every ticket must be all seven:
 
 - **One unit of work** — implementable, testable, and verifiable in a single focused agent session. An "and" in the title is two tickets. Two independent subsystems is two tickets.
 - **Independently spawnable** — an agent can take it with nothing but the ticket and the repo. No "ask Sarah", no "coordinate with the other branch". A shared contract (types, an API shape, a schema) is its *own earlier ticket* that the others depend on — define it once, then the dependents fan out without colliding.
-- **Acceptance-criteria-complete** — explicit, testable done-conditions. "Implement the feature" is not acceptance criteria; "`POST /tasks` returns 201 with the created task; empty title returns 422" is.
+- **Acceptance-criteria-complete** — explicit, testable done-conditions, *each paired with the evidence that proves it*. "Implement the feature" is not acceptance criteria; "`POST /tasks` returns 201 with the created task (asserted in `tasks.test.ts`); empty title returns 422 (asserted)" is. A criterion with no nameable evidence is a wish, not a done-condition.
 - **Dependency-declared** — it names what it depends on, so the batch order is *computed*, not eyeballed.
 - **Implementation-complete** — it carries the slice of the design it owns: the interface it implements, the files it will touch, the test seam. The implementing agent should *execute* the plan, not re-derive it.
 - **Library/CLI-declared** — it names the library, framework feature, package script, or generator command to use; if manual code is required, it says why the maintained path does not fit.
@@ -96,7 +107,7 @@ Each ticket is built with [[test]] unless it's genuinely trivial (config, copy,
 
 ## When NOT to do all this
 
-A single-file change with obvious scope doesn't need an epic — just do it (with [[test]] if it's behavior). The machinery earns its keep when work is large, parallelizable, or unclear. Don't ceremony-wrap a one-liner.
+This is a narrow exit, not a blanket one. Skip the epic machinery *only* when the work is a single-file change whose scope is genuinely obvious and whose done-condition you can state in one line — then just do it (with [[test]] if it's behavior). "This feels small" is not the test; "one file, one obvious change, one statable done-condition" is. The moment the work is multi-file, parallelizable, touches an unfamiliar API, or has a done-condition you can't write in a sentence, it is back in scope — do not use this exit to skip planning on work that needed it. Don't ceremony-wrap a one-liner; don't under-plan a feature because you'd rather start coding.
 
 ## Red flags
 

package/.agents/skills/secure/SKILL.md

@@ -340,7 +340,7 @@ Dependency risk is part of security. Slow down on dependencies that are stale, s
 
 ## Verification
 
-After implementing security-relevant code:
+Security claims are the *last* place to accept a ticked box on faith — a checked item here means you ran the check and read the output this session, per [[verify]], not that you believe it's probably fine. "Auth is checked on every endpoint" is a claim that needs the grep/test that proves it; "no secrets in history" needs the actual scan. An unrun security checklist is more dangerous than none, because it reads as assurance. After implementing security-relevant code:
 
 - [ ] `npm audit` shows no critical or high vulnerabilities
 - [ ] No secrets in source code or git history

package/.agents/skills/spec/SKILL.md

@@ -21,6 +21,8 @@ Write a structured specification before writing any code. The spec is the shared
 
 ## The Gated Workflow
 
+**The artifact you emit is the spec — and its Success Criteria are binding downstream.** [[scope]] turns them into per-ticket Definitions of Done and [[execute]]/[[verify]] gate on them, so a success criterion that isn't specific and testable (names the check that proves it) isn't a criterion — it's a wish that will let the implementing agent decide "done" for itself. "Make it faster" is not a criterion; "Dashboard LCP < 2.5s on 4G, asserted by the Lighthouse CI check" is. Every criterion names its evidence, or it doesn't belong in the spec.
+
 Spec-driven development has four phases. Do not advance to the next phase until the current one is validated.
 
 ```

package/.agents/skills/test/SKILL.md

@@ -48,6 +48,8 @@ A bug fix *starts* with a failing test, not a fix. Write a test that reproduces
 - [ ] The code is the minimum for *this* test — no speculative features.
 - [ ] The test would survive an internal refactor.
 
+**The artifact you emit is the red-then-green evidence** — you *watched* each test fail for the right reason, then pass. "I watched it fail" is a claim about output you saw this session, not a courtesy phrase; [[verify]] and [[execute]] consume this evidence and a test you never saw fail counts for nothing. A behaviour with no test, or a test with no observed RED, is not done — it is untested code wearing a green check.
+
 ## Red flags
 
 - A test that passed the first time you ran it (you never saw RED).

package/.agents/skills/trace/SKILL.md

@@ -113,6 +113,10 @@ If the root cause is architectural — no good seam, tangled callers, hidden cou
 
 ## Phase 4 — Hand off to the fix
 
+Phase 3 is a gate, not a self-assessment. You do not leave it by *feeling* confident — you leave it by having all six confirmation checks actually pass. "It's obviously X" is exactly the thought that precedes the six checks failing.
+
+**The artifact you emit is the confirmed root cause** — the three-level explanation (what / why / why-not-prevented), the reverse-test result, and the class-not-instance statement. This is what [[fix]] consumes: a fix that arrives without a confirmed root cause behind it is a guess, and [[fix]] is entitled to send it back here. The handoff is not "go fix it" — it is "here is the cause, confirmed, with the evidence."
+
 Once the cause is confirmed, the fix itself is governed by [[fix]]: a minimal fix at the source, a test that reproduces the bug, and proof the symptom is actually gone. One change — no "while I am here" refactoring bundled in.
 
 ## Stop if you catch yourself thinking…

package/.agents/skills/verify/SKILL.md

@@ -9,6 +9,15 @@ Claiming work is complete without fresh evidence is not efficiency. It is guessi
 
 **Core rule:** evidence before claims, always.
 
+## The hard stop
+
+This skill is the gate the whole chain terminates in. Two claims are forbidden here, no exceptions:
+
+- **"Done" while any acceptance criterion is unmet or unevidenced.** Done is all-criteria-met-with-fresh-evidence or it is not done. You may not round up from "the important parts pass." If a criterion lacks evidence you ran *this session*, it is unverified, and unverified blocks the "done" claim — full stop.
+- **"Done" that is actually "partial."** If some criteria pass and others don't, the honest output is a partial report that names every unmet criterion (see *If You Cannot Verify*), never a success claim with the gaps omitted. Omitting a known gap to make the claim land is the failure this skill exists to catch.
+
+A claim that survives this gate carries its evidence with it. A claim that can't produce the evidence does not get made.
+
 ## The Gate
 
 Before saying anything is done, fixed, passing, ready, safe, or complete:
@@ -50,14 +59,21 @@ These phrases are not banned; unsupported claims are. Run the check first, then
 
 ## If You Cannot Verify
 
-Say exactly what is missing:
+Say exactly what is missing, criterion by criterion — the same structured shape [[execute]] escalates in, so a partial result is legible rather than a shrug:
+
+```text
+Verified:   - <criterion> — <command/output that proves it>
+Unverified: - <criterion> — <why: missing access/data/blocker, what you tried>
+```
+
+Concrete, not vague:
 
 - "I could not run `npm test` because dependencies are not installed."
 - "I verified the unit tests, but not the browser flow."
 - "The original bug requires production data I do not have."
 - "The check failed: 3 tests still fail in `billing.test.ts`."
 
-Then either fix the blocker, ask for the missing access/input, or report the remaining risk. Do not convert uncertainty into a success claim.
+Then either fix the blocker, ask for the missing access/input, or report the remaining risk. Do not convert uncertainty into a success claim. Every criterion lands in Verified or Unverified — one you can't place is itself a gap to report.
 
 ## Common Patterns
 

package/defaults/profiles.yaml

@@ -30,6 +30,9 @@ mcp_gateway:
       workspace_path_source: PIPELINE_TARGET_PATH
       tool_prefixes: [backlog]
 skills:
+  orchestrate:
+    path: .agents/skills/orchestrate/SKILL.md
+    source_root: package
   execute:
     path: .agents/skills/execute/SKILL.md
     source_root: package
@@ -85,8 +88,8 @@ profiles:
   moka-orchestrator:
     runner: opencode
     description: Orchestrate the configured pipeline and enforce gates.
-    instructions: { inline: "Orchestrate the configured pipeline through package-defined entrypoints, native agents, and gates. Do not bypass configured runner subprocesses or package-configured gates." }
-    skills: [execute, quick, inspect]
+    instructions: { inline: "Orchestrate the configured pipeline locally. Load the `orchestrate` skill and spawn the roster as native Task subagents on this machine. Do not submit to Argo or run `moka submit`. Enforce only package-configured gates." }
+    skills: [orchestrate, execute, quick, inspect]
     mcp_servers: [pipeline-gateway]
     tools: [read, list, grep, glob, bash]
     filesystem: { mode: read-only, allow: ["**/*"], deny: ["node_modules/**", "dist/**", ".git/**"] }

package/dist/argo-submit.d.ts

@@ -22,7 +22,6 @@ declare const submitRunnerArgoWorkflowOptionsSchema: z.ZodObject<{
   namespace: z.ZodString;
   opencodeAuthSecretName: z.ZodOptional<z.ZodString>;
   payloadJson: z.ZodString;
-  queueName: z.ZodOptional<z.ZodString>;
   scheduleYaml: z.ZodString;
   serviceAccountName: z.ZodOptional<z.ZodString>;
 }, z.core.$strict>;

package/dist/argo-submit.js

@@ -2,9 +2,8 @@ import { ArgoGraphCompilerError, compileArgoExecutionGraph } from "./argo-graph.
 import { buildRunnerTaskDescriptor } from "./runner-command/task-descriptor.js";
 import { buildRunnerArgoWorkflowManifest, runnerArgoWorkflowManifestSchema } from "./argo-workflow.js";
 import { normalizeRunnerRepositoryForSubmit } from "./git-remote-url.js";
+import { compileScheduleArtifact, parseScheduleArtifact } from "./planning/generate.js";
 import { parseRunnerCommandPayload, runnerCommandPayloadSchema } from "./runner-command-contract.js";
-import { compileScheduleArtifact, parseScheduleArtifact } from "./schedule/planner.js";
-import "./schedule-planner.js";
 import { workflowSubmitResultSchema } from "./workflow-submit-contract.js";
 import { stringify } from "yaml";
 import { z } from "zod";
@@ -40,7 +39,6 @@ const submitRunnerArgoWorkflowOptionsSchema = z.object({
 	namespace: z.string().min(1),
 	opencodeAuthSecretName: z.string().min(1).optional(),
 	payloadJson: z.string().min(1),
-	queueName: z.string().min(1).optional(),
 	scheduleYaml: z.string().min(1),
 	serviceAccountName: z.string().min(1).optional()
 }).strict().refine((options) => options.name !== void 0 || options.generateName !== void 0, { message: "Argo submit options must declare name or generateName" });
@@ -89,7 +87,6 @@ async function submitRunnerArgoWorkflow(rawOptions, dependencies = {}) {
 		opencodeAuthSecretName: options.opencodeAuthSecretName,
 		payloadConfigMapName,
 		plan: compiled.plan,
-		queueName: options.queueName,
 		scheduleConfigMapName: scheduleArtifactConfigMapName,
 		serviceAccountName: options.serviceAccountName,
 		taskDescriptorConfigMapName

package/dist/argo-workflow.d.ts

@@ -1,4 +1,4 @@
-import { WorkflowExecutionPlan } from "./workflow-planner.js";
+import { WorkflowExecutionPlan } from "./planning/compile.js";
 import { z } from "zod";
 
 //#region src/argo-workflow.d.ts
@@ -143,7 +143,6 @@ declare const buildRunnerArgoWorkflowOptionsSchema: z.ZodObject<{
   }, z.core.$strict>>;
   payloadConfigMapKey: z.ZodDefault<z.ZodString>;
   payloadConfigMapName: z.ZodString;
-  queueName: z.ZodOptional<z.ZodString>;
   resources: z.ZodOptional<z.ZodObject<{
     limits: z.ZodOptional<z.ZodRecord<z.ZodString, z.ZodString>>;
     requests: z.ZodOptional<z.ZodRecord<z.ZodString, z.ZodString>>;

package/dist/argo-workflow.js

@@ -153,7 +153,6 @@ const buildRunnerArgoWorkflowOptionsSchema = z.object({
 	}).strict().optional(),
 	payloadConfigMapKey: z.string().min(1).default("payload.json"),
 	payloadConfigMapName: kubernetesNameSchema,
-	queueName: kubernetesNameSchema.optional(),
 	resources: argoWorkflowResourceRequirementsSchema.optional(),
 	scheduleConfigMapKey: z.string().min(1).default("schedule.yaml"),
 	scheduleConfigMapName: kubernetesNameSchema,
@@ -191,7 +190,6 @@ function buildRunnerArgoWorkflowManifest(rawOptions) {
 			...options.activeDeadlineSeconds ? { activeDeadlineSeconds: options.activeDeadlineSeconds } : {},
 			entrypoint: RUNNER_WORKFLOW_ENTRYPOINT,
 			...options.imagePullSecretName ? { imagePullSecrets: [{ name: options.imagePullSecretName }] } : {},
-			...options.queueName ? { podMetadata: { labels: { "kueue.x-k8s.io/queue-name": options.queueName } } } : {},
 			onExit: "pipeline-finalizer",
 			serviceAccountName: options.serviceAccountName,
 			templates: [