devflow-kit 3.15.0 → 3.17.0

package/src/assets/commands/_partials/_engine.mds

@@ -1,216 +0,0 @@
-@define gate1_postcode():
-### GATE 1 — Post-code pipeline
-
-Run in this order:
-
-1. **Polish agent**
-2. **Harden agent** — 9-pillar self-review (deep structural analysis); returns `{"status": "PASS" | "FIXED" | "BLOCKED"}`
-   - BLOCKED (a P0 issue cannot be fixed in scope), or a missing or unrecognised status, which counts as BLOCKED → stop the pass and escalate as `harden-blocked`; Validate does not run on code Harden could not accept
-3. **Validate agent** — build / typecheck / lint / test; returns `{"verdict": "PASS" | "FAIL", "details": "..."}`. It runs last and unconditionally: one full run over the HEAD that Polish and Harden left, so it covers their commits
-   - FAIL → Fix agent fix (max 2 retries), each followed by a Validate agent re-run
-   - If still FAIL after 2 retries → escalate as `validation-exhausted`
-
-**Gate 1 contains NO Evaluate agent and NO Test agent.** Those are Gate 2 only.
-
-Depth scales to change size and budget: a one-line fix gets a lighter pass.
-
-**Cadence — Gate 1 runs at exactly two points per ticket:**
-1. **Gate 1 #1** — immediately after the initial Code agent implementation (inside `implement_bundle()`). An escalated result — Validate exhausted, or Harden BLOCKED — returns early: the ticket's engine returns `ESCALATED` with one escalation, and Gate 2 and the review pass never run on a broken or unfinished build.
-2. **Gate 1 #2** — the final gate, after all Gate-2 fixes and the entire review pass have completed. Harden BLOCKED here is `ESCALATED` as well.
-@end
-
-@define gate2_acceptance():
-### GATE 2 — Acceptance gate (per ticket, plan-scoped)
-
-Gate 2 fires once: after the implement-bundle and before the review pass. It does not re-run after review-fixes (those get Gate 1 only).
-
-**Evaluate agent** (only if a plan exists):
-- Run `evaluator_panel()`
-- If the Evaluate agent returns FAIL (either lens failed): fix-and-continue — a Fix agent applies the demanded fixes and self-verifies its own build (batched as in the review pass if numerous). The recorded verdict becomes `FAIL-FIXED` (fixes applied, not re-evaluated); Gate 2 then proceeds. In SINGLE mode the run reports it as `UNVERIFIED`, never PASS.
-
-**Test agent** (only if acceptance criteria or a test plan exist):
-- Scenario-based acceptance tests covering functionality, API contracts, performance
-- FAIL → fix-and-continue — a Fix agent applies the demanded fixes and self-verifies its own build. The recorded verdict becomes `FAIL-FIXED`; Gate 2 then proceeds. In SINGLE mode the run reports it as `UNVERIFIED`, never PASS.
-- BLOCKED (no result), or any other or missing verdict → no fix, and the run never reports PASS.
-
-**When Gate 2 inputs are absent:**
-- No plan → skip the Evaluate agent silently (note in output: "Gate 2 Evaluate agent skipped — no plan available")
-- No acceptance criteria and no test plan → skip Test agent silently (note in output: "Gate 2 Test agent skipped — no criteria available")
-@end
-
-@define evaluator_panel():
-### Evaluate agent spawn (one agent, two lenses)
-
-Run one Evaluate agent whose prompt names both lenses, as the SINGLE skeleton's Gate 2 prompt words them: acceptance criteria (negative criteria included) and scope or intent drift. FAIL when either lens fails.
-@end
-
-@define implement_bundle():
-### Implement bundle
-
-Run in order:
-
-```
-<!-- curation:on -->
-Code(agentType:"Code", prompt: "OPERATION: implement" first line, then full task + plan + DECISIONS_CONTEXT + COMPLIANCE_DIRECTIVE + handoff if sequential)
-<!-- curation:off -->
-Code(agentType:"Code", prompt: "OPERATION: implement" first line, then full task + plan + COMPLIANCE_DIRECTIVE + handoff if sequential)
-<!-- curation:end -->
-  → gate1_postcode()
-  → gate2_acceptance()   ← Gate 2 runs HERE — before the review pass, not after
-```
-
-<!-- curation:on -->
-Every Code-family agent prompt opens with `OPERATION: <mode>` as its first line: `implement` and `issue-fix` go to `agentType:"Code"`, `validation-fix`, `alignment-fix` and `qa-fix` go to `agentType:"Fix"`. It must include: task description, implementation plan (if one exists), relevant DECISIONS_CONTEXT (the index you loaded before authoring), the compliance directive (`COMPLIANCE_DIRECTIVE` — every Code prompt carries it when it is not empty, fix prompts included), and any PRIOR_PHASE_SUMMARY / HANDOFF_FILE for sequential multi-phase tickets.
-<!-- curation:off -->
-Every Code-family agent prompt opens with `OPERATION: <mode>` as its first line: `implement` and `issue-fix` go to `agentType:"Code"`, `validation-fix`, `alignment-fix` and `qa-fix` go to `agentType:"Fix"`. It must include: task description, implementation plan (if one exists), the compliance directive (`COMPLIANCE_DIRECTIVE` — every Code prompt carries it when it is not empty, fix prompts included), and any PRIOR_PHASE_SUMMARY / HANDOFF_FILE for sequential multi-phase tickets.
-<!-- curation:end -->
-@end
-
-@define review_pass():
-### Review → verify → fix (single pass)
-
-The review pass runs exactly ONCE per ticket. One full-branch review → one adversarial verification → one batched fix phase → final Gate 1 (#2). Budget scales roster and verification votes, NEVER the number of passes.
-
-**Step 1 — Spawn Review agents in parallel (one agent() per focus)**
-
-**Review scope:** the entire branch diff, `DIFF_RANGE: {base commit}...HEAD`; the base commit is the 40 or 64 hex commit that the ticket branch was forked from, as the setup step reported it; a ticket with none stops `base-missing`.
-
-Core Review agents (always, 8 total): security, architecture, performance, complexity, consistency, regression, testing, reliability
-
-Conditional by file type detected in the diff (add these when relevant):
-- `.ts` / `.tsx` → typescript
-- `.tsx` / `.jsx` → react, accessibility, ui-design
-- `.css` / `.scss` → ui-design
-- `.go` → go
-- `.java` → java
-- `.py` → python
-- `.rs` → rust
-- database schema / query files → database
-- `package.json` / `go.mod` / `Cargo.toml` / etc. → dependencies
-- Markdown / doc files → documentation
-
-**Spawn pacing:** launch Review agents in staggered chunks of 4–6 (sequential groups of parallel spawns).
-
-**Review agent result contract:** every Review agent must return a structured result with fields `focus`, `reviewed: true`, `filesExamined`, and `findings`. Each item in `findings` must carry: `file` (path of the primary file the finding relates to, or `null` if scope is unknown), `description` (one-sentence issue statement), and `severity` (`critical | high | medium | low`). A result is DEAD if: the agent returned null, threw, returned a guard string, or `reviewed !== true`. A DEAD Review agent is never treated as a clean reviewer. Retry once sequentially. If still dead after retry: record the focus in `coverageGaps`. A pass with any coverage gaps can never early-exit as clean, and the run verdict can never be PASS; escalate with message "review coverage incomplete: <focus>".
-
-**Step 2 — Adversarial finding verification**
-
-Before any fix, verify findings with 2–3 agents, one per lens of the skeleton's verification panel.
-
-Majority-survives: a finding needs >50% of verification lenses to confirm it. Strip unconfirmed findings.
-
-**Step 3 — Early exit or fix**
-
-If no surviving findings: return early (no fixes needed). Any coverageGaps are carried in the return — they block a PASS verdict downstream, not the early exit.
-
-If survivors remain: batch the confirmed findings for fixing: group findings by file — one file per set of sub-batches, chunked at max 5 findings per sub-batch; never mix two files in one batch. A finding with no `file` field is its own singleton batch. Sub-batches for the same file run sequentially (never two Code agents editing the same file concurrently); sub-batches for distinct files run via `parallel()` in staggered chunks of ~5. Each Code agent's prompt pins a return contract: `{"status": "fixed"|"blocked", "commitShas": [...], "unresolved": [...]}` — a chunk is FIXED only when `result.status === "fixed"` AND `commitShas` is non-empty AND `result.unresolved` is empty; never decide disposition from status alone. A non-empty `unresolved` list means the agent named work it could not complete — carry the whole chunk into `survivingFindings` rather than guessing which findings the strings map to. `survivingFindings` = findings not addressed: fix Code agent dead/failed/blocked/deferred or committed but left work named in `unresolved`. The fixing Code agent **self-verifies its own fix builds** (build/typecheck per the Code agent's Running commands block, once over its whole batch). Do not run Gate 1 or Gate 2 inside the pass (no Validate, Polish, Harden, Evaluate or Test agent).
-@end
-
-@define concurrency_doctrine():
-### Code agent concurrency doctrine
-
-**DEFAULT: SEQUENTIAL.** Parallelism is the rare, tightly-gated exception.
-
-- **Same task → sequential Code agents with handoff. Never parallel.**
-- **Different tasks may parallelize, but only when all three bars hold:**
-  1. Completely different areas of the code — different files/modules, no imports between them, no shared contracts/interfaces
-  2. Different feature logic — they do not touch the same feature's logic or cooperate on a single outcome
-  3. Different goals — they are not two steps converging on the same end state
-- "They look independent" is not sufficient. If two tasks are somewhat related — they touch the same feature, one's completion makes the other meaningful, or they march toward a shared goal — run them sequentially.
-- **When in doubt, sequential.** Parallel must be affirmatively justified against all three bars.
-
-This applies to both: multiple Code agents working on a single ticket and multi-ticket scheduling in a wave.
-@end
-
-@define build_execution_doctrine():
-### Build execution doctrine — the Running commands block
-
-The Code, Fix, Refactor, Validate and Test agents each carry this `## Running commands` block in their bodies, so each prompt in this engine names the block ("your Running commands block") instead of copying it:
-
-Run builds, typechecks, lints and tests in the foreground, each with an explicit Bash `timeout` above its expected run time. The ceiling is 600000 ms, or `BASH_MAX_TIMEOUT_MS` when set (`echo ${BASH_MAX_TIMEOUT_MS:-600000}`).
-
-- Capture, then tail, in one Bash call: `LOG=$(mktemp); echo "LOG=$LOG"; <command> >"$LOG" 2>&1; rc=$?; tail -n 40 "$LOG"; printf '\nEXIT=%s\n' "$rc"`. The last `EXIT=` line is the result; never decide one from a grep count.
-- Never background a build or test, and never poll across turns: no `sleep` or `true` turns, no sentinel-file checks, no Monitor.
-- Prefer the scoped command for the change; for the whole set, one workspace command over per-package loops.
-- A run past its timeout moves to the background: no tool call, even a Read, until its end notice, then Read the last `EXIT=` line of the file the move names, not `$LOG`; it alone sets the label, not the notice. With none read it is BLOCKED: report its duration and log path. Report only after the end notice.
-- A run expected to exceed the ceiling may be split into parts, run in sequence.
-- Never re-run a command when nothing it reads has changed.
-- Never wrap a build or test command in `sh -c`, `bash -c`, `python3 -c` or `node -e`: permission rules deny wrapped commands they allow directly.
-- The same rules hold inside a dynamic Workflow sub-agent.
-
-**Cheapest-sufficient validation:** iterate with the fastest check that proves the change — `tsc --noEmit`, `cargo check`, `go vet`, a single test file. Reserve full builds and whole-suite runs for the final gates.
-
-**One build gate per phase:** batch related fixes, validate once. A fix-pass Code agent runs one light check over its whole batch, never one per fix. After the wave, the full-workspace regression is the human's job.
-@end
-
-@define engine_output_schema():
-### Engine output schema
-
-Each ticket engine run returns a structured result. The engine fills `verdict`: the SINGLE skeleton's `overallVerdict`, or `ESCALATED` from the ticket-link or branch stop. The wave merges `PASS` and `UNVERIFIED` and quarantines every other value, or none.
-
-```json
-{
-  "ticket": "string — ticket ID or description",
-  "branch": "string — the branch this ticket's setup-task created, or (none)",
-  "verdict": "PASS | UNVERIFIED | PARTIAL | FAIL | ESCALATED",
-  "issueId": "string — the Issue ID captured from this ticket's setup-task Handoff Values, or (none)",
-  "issuePrLink": "string — the PR link line captured from the same block, or (none)",
-  "survivingFindings": [
-    {
-      "focus": "string — Review agent focus area",
-      "file": "string — primary file the finding relates to, or null if scope unknown",
-      "description": "string — one-sentence issue statement",
-      "severity": "critical | high | medium | low",
-      "status": "surviving"
-    }
-  ],
-  "fixedFindings": [
-    {
-      "focus": "string — Review agent focus area",
-      "file": "string — primary file the finding relates to, or null if scope unknown",
-      "description": "string — one-sentence issue statement",
-      "severity": "critical | high | medium | low",
-      "status": "fixed",
-      "commitShas": ["string — commit SHAs from the fix Code agent"]
-    }
-  ],
-  "reviewCoverage": {
-    "failedFocuses": ["string — focus areas where Review agent died after retry"],
-    "complete": "boolean — true iff no coverage gaps"
-  },
-  "escalations": [
-    {
-      "type": "merge-conflict | gate2-fail | validation-exhausted | harden-blocked | ambiguous-resolution | review-coverage-incomplete | dependency-blocked | engine-crash | ticket-link-missing | branch-missing | base-missing",
-      "description": "string"
-    }
-  ],
-  "gate2": {
-    "evaluateVerdict": "PASS | FAIL | FAIL-FIXED | SKIPPED",
-    "testVerdict": "PASS | FAIL | FAIL-FIXED | SKIPPED | BLOCKED",
-    "skipReasons": ["string — why a gate was skipped, if applicable"]
-  }
-}
-```
-@end
-
-@define engine_invariants():
-### Engine invariants
-
-1. **Code is written only by the Code family (Code, Fix).** No other agent type writes code.
-2. **Findings are verified before any fix is written.** Unverified findings are not passed to the Code agent.
-3. **All written code passes Gate 1.** No code merge, commit, or handoff before Polish agent + Harden agent + Validate agent (in that order).
-4. **Gate 2 runs once, at implementation acceptance.**
-5. **NEVER auto-merge to main or master.** All merges target the integration branch.
-6. **No unauthorized tracker or remote side-effects.** Sub-agents NEVER create issues/PRs on the tracker, comment on them, or push beyond the ticket-authorized branch unless the ticket, plan, or user explicitly authorizes that exact action. This applies to whatever tracker is resolved, not to one vendor. Proposed follow-ups go in the run report.
-7. **The review pass runs exactly ONCE per ticket.** Never author additional cycles or a delta re-review of fix commits.
-@end
-
-@export gate1_postcode
-@export gate2_acceptance
-@export evaluator_panel
-@export implement_bundle
-@export review_pass
-@export concurrency_doctrine
-@export build_execution_doctrine
-@export engine_output_schema
-@export engine_invariants

package/src/assets/commands/_partials/_factory.mds

@@ -1,122 +0,0 @@
-@define factory_shape():
-### Ticket-factory pipeline shape (generalized)
-
----
-
-#### Stage 1 — Draft (one agent per ticket, parallelisable)
-
-Spawn one Design agent or Synthesize agent per candidate ticket. DRAFT_SCHEMA:
-
-```json
-{
-  "type": "object",
-  "required": ["title", "summary", "wave", "dependsOn", "scope", "acceptanceCriteria", "openQuestions"],
-  "properties": {
-    "title":             { "type": "string" },
-    "summary":           { "type": "string" },
-    "wave":              { "type": "number" },
-    "dependsOn":         { "type": "array", "items": { "type": "string" } },
-    "scope":             { "type": "object",
-                           "properties": { "in": { "type": "array", "items": { "type": "string" } },
-                                           "out": { "type": "array", "items": { "type": "string" } } } },
-    "acceptanceCriteria":{ "type": "array", "items": { "type": "string" } },
-    "openQuestions":     { "type": "array", "items": { "type": "string" } }
-  }
-}
-```
-
----
-
-#### Stage 2 — Two-lens review (parallel per ticket)
-
-For each draft, run two independent Review agents **in parallel**, one per lens, with the checks and severities the skeleton's review prompts state: Lens A, planner-readiness (a cold read), and Lens B, accuracy and scope discipline. A scope hole is a thing the feature obviously needs that neither In nor Out names. A smuggled anti-feature is a scope item the initiative explicitly excludes.
-
-REVIEW_SCHEMA:
-
-```json
-{
-  "type": "object",
-  "required": ["verdict", "findings"],
-  "properties": {
-    "verdict":  { "type": "string", "enum": ["ready", "needs-work"] },
-    "findings": { "type": "array", "items": {
-      "type": "object",
-      "required": ["severity", "issue", "suggestion"],
-      "properties": {
-        "severity":   { "type": "string", "enum": ["critical", "major", "minor"] },
-        "issue":      { "type": "string" },
-        "suggestion": { "type": "string" }
-      }
-    }}
-  }
-}
-```
-
----
-
-#### Stage 3 — Revise (one agent per ticket, per review findings)
-
-For each ticket, spawn one Synthesize agent or Design agent to apply review findings. REVISE_SCHEMA:
-
-```json
-{
-  "type": "object",
-  "required": ["title", "changesMade", "remainingConcerns"],
-  "properties": {
-    "title":            { "type": "string" },
-    "changesMade":      { "type": "array", "items": { "type": "string" } },
-    "remainingConcerns":{ "type": "array", "items": { "type": "string" } }
-  }
-}
-```
-
----
-
-#### Stage 4 — Whole-set cross-critic (single agent, sees all revised tickets)
-
-One Design agent reviews the full revised set for set-level issues, not individual prose quality, on the four axes the skeleton's cross-critic prompt names: coverage, overlaps and contradictions, the dependency graph, and acceptance-criteria coherence. The dependency-graph check also flags a dependency that a ticket needs but does not declare.
-
-CRITIC_SCHEMA:
-
-```json
-{
-  "type": "object",
-  "required": ["setVerdict", "perTicketAmendments", "trackingGuidance"],
-  "properties": {
-    "setVerdict": { "type": "string" },
-    "perTicketAmendments": { "type": "array", "items": {
-      "type": "object",
-      "required": ["title", "amendments"],
-      "properties": {
-        "title":      { "type": "string" },
-        "amendments": { "type": "array", "items": { "type": "string" } }
-      }
-    }},
-    "trackingGuidance": { "type": "string" }
-  }
-}
-```
-
----
-
-#### Stage 5 — Per-ticket amend (parallel, only tickets with amendments)
-
----
-
-#### Stage 6 — Assemble tracking issue
-
-One Synthesize agent writes the tracking-issue document from the final ticket set + critic guidance.
-
----
-
-#### Usage notes
-
-- Each schema is its stage's return shape, passed as `schema:`: `{ agentType: "Design", schema: DRAFT_SCHEMA }`, `{ agentType: "Review", schema: REVIEW_SCHEMA }`, `{ agentType: "Synthesize", schema: REVISE_SCHEMA }`, `{ agentType: "Design", schema: CRITIC_SCHEMA }`. A field that the host script's `Return:` line adds joins the schema.
-- The `candidates` array is **what the model proposed + user confirmed** — never hardcoded.
-- The `initiative` variable is the raw user input (a description, a spec doc path, or inline text) — read it and distill before passing to agents.
-- The `constraints` variable is optional: any cross-cutting rules (naming discipline, scope filters, authority order) the user supplied.
-- Write each ticket's artifact file inside an agent, with the ticket body template above.
-- For large initiatives (more than ~8 tickets), chunk the `parallel(map())` fan-outs into batches (e.g. `for` loop over slices, `await`-ing each batch) so agent concurrency stays bounded and provider rate limits are respected.
-@end
-
-@export factory_shape

package/src/assets/commands/_partials/_preamble.mds

@@ -1,112 +0,0 @@
-@import "./_decisions.mds" as decisions
-
-A partial: the Workflow-authoring preamble that the three Workflow hosts
-(dynamic-build, dynamic-plan and dynamic-tickets) share, and the decisions step
-that precedes authoring.
-
-D-DECISIONS-AUTHORING-STEP: the "DECISIONS_CONTEXT — obtain BEFORE authoring" step
-is its own define, `authoring_decisions()`, expanded by the same three hosts right
-after their settings block, so the gate in it reads a line already resolved.
-`authoring_preamble()` carries no decisions text. D-LEARNING-VARIANTS: the whole of
-`authoring_decisions()` is a curation-on arm, so a curation-off build carries no decisions
-step.
-
-D-DECISIONS-DECLARED-ONLY: the step names, as the receivers of the index, only the
-agent types whose contract declares `DECISIONS_CONTEXT` among the valid
-`agentType`s. `tests/decisions/decisions-seam.test.ts` computes the declared set
-from the agent sources and holds every pass sentence to it.
-
-@define authoring_preamble():
-## Your task: author a Claude Code dynamic Workflow and run it
-
-You (the main model) author the Workflow script body inline and pass it to the `Workflow` tool.
-
-### Workflow runtime contract
-
-A workflow script must begin with a pure-literal export:
-
-```js
-export const meta = {
-  name: "devflow-dynamic-...",   // flat hyphenated namespace — always prefix devflow-dynamic-
-  description: "...",
-  phases: ["..."]
-};
-```
-
-The script body uses only these hooks:
-
-```js
-agent(prompt, opts)      // spawn a sub-agent; opts.agentType resolves devflow installed agents
-parallel(thunks)         // barrier — awaits all; concurrency capped ~min(16, cores-2)
-pipeline(items, ...fns)  // stream items through stages (no barrier between stages)
-phase(name, fn)          // named phase boundary for resume / progress
-log(msg)                 // structured log
-workflow(fn)             // nest one level
-```
-
-Globals available in the script body: `args`, `budget`, `workflow()`.
-
-**The script body has NO filesystem / Node.js / CLI access** — no tracker CLI of any kind, `gh` included. All file reading, issue fetching, git operations and shell commands happen inside the agents the script spawns. There is no `fs`, `exec` or `fetch` in scope.
-
-### Agent reuse via agentType
-
-Spawn devflow agents with:
-
-```js
-agent("your prompt here", { agentType: "Code" })
-```
-
-Valid `agentType` values: Code, Fix, Validate, Polish, Harden, Evaluate, Test, Review, Git, Synthesize, Design, Architect.
-
-**Omit `opts.model` whenever `agentType` is set.** The agent frontmatter sets its own model tier, and `opts.model` overrides it.
-
-Do not write logic that depends on an agent listing its own skills.
-
-### Pre-flight self-check — required before the first live `Workflow` call
-
-Audit the script against this checklist:
-
-- **`meta` is a pure literal** — `name` and `description` present; no variables, function calls, spreads or template interpolation anywhere inside `meta`.
-- **Every `pipeline(x, …)` / `parallel(x)` first argument is a real array** — never a function, object, or possibly-undefined value. If it derives from a prior agent result, coerce it: `parallel((maybeList || []).map(...))`.
-- **No reference to a possibly-undefined field** — guard every cross-result field access with optional chaining.
-- **`.filter(Boolean)` before mapping over `agent()` / `parallel()` results** — an agent can return `null` (skipped, or died after retries); strip nulls before `.map` or field access. filter(Boolean) is crash-safety only; it must never convert missing required coverage into success.
-- **`phase()` titles match the phases declared in `meta`** — every `phase("…")` call has a matching declared phase, and vice-versa.
-
-Then run a syntax gate: write the authored script to a fresh, run-unique scratch file `/tmp/df-wf-check-<meta.name>-<epoch-seconds>.js` (never a prior run's path), run `node --check` on that file, and only then pass the script text to the `Workflow` tool.
-
-### Budget scaling
-
-Scale the Review roster and the verification votes to the `budget` global: fewer at a low budget, more at a high budget. Never hardcode a roster size.
-
-### Handoff convention for sequential Code agents within a ticket
-
-When a ticket requires multiple sequential Code agent phases, each Code agent appends its own `## Phase {N} Implementation Summary` section, at most 8,192 bytes, to `{toplevel}/.devflow/docs/handoff-{branch_slug}.md`, `{branch_slug}` being the ticket's branch name with every `/` replaced by `-`, and `{toplevel}` being `git rev-parse --show-toplevel` in the checkout the ticket's branch is in — never a subdirectory. It never rewrites an earlier section. The next Code agent reads, via HANDOFF_FILE input, only the section of the phase immediately before its own, not the whole file. PRIOR_PHASE_SUMMARY is the in-context form. The code is authoritative over the summaries.
-
-### IRON RULE (LLM-vs-plumbing)
-
-**Author no deterministic feature code:** no parsers, schedulers, topological sorts, dependency-graph helpers or confidence formulas. The workflow's agents do all issue reading, dependency reasoning and scheduling by judgment at runtime.
-
-### SAFETY BANNER
-
-**NEVER merge to main or master** — the workflow merges to an integration branch only. This rule must appear as an `engine_invariants()` note in every workflow that touches git.
-@end
-
-@define authoring_decisions():
-<!-- curation:on -->
-### DECISIONS_CONTEXT — obtain BEFORE authoring
-
-{{decisions.decisions_gate()}}
-
-{{decisions.decisions_locate()}}
-
-Before you author the workflow script, read `{ledger}/.devflow/curation/index.md`. If the file is absent or empty, set `DECISIONS_CONTEXT` to `(none)`; otherwise use the file content as `DECISIONS_CONTEXT`.
-
-Then inject the relevant DECISIONS_CONTEXT into the prompts of the Code, Fix, Design, Architect, Review and Harden agents, which follow `devflow:apply-decisions`. Those are the agent types above whose contract declares it; every other agent type gets no decisions context.
-
-{{decisions.decisions_slice()}} The script carries one `DECISIONS_CONTEXT` for every agent, so cut it once, over the whole run.
-
-<!-- curation:end -->
-@end
-
-@export authoring_preamble
-@export authoring_decisions

package/src/assets/commands/_partials/_roster.mds

@@ -1,31 +0,0 @@
-@define agent_roster():
-### Confirmed agent roster
-
-Model tiers are for reference only; never pass `opts.model`.
-
-| agentType | Model tier | Role |
-|---|---|---|
-| Code | sonnet | Implements the plan and fixes review findings |
-| Fix | sonnet | Fixes the listed validation, alignment and QA failures |
-| Validate | haiku | Build / typecheck / lint / test — fast correctness gate |
-| Polish | sonnet | Reduces complexity, removes duplication, improves readability |
-| Harden | opus | 9-pillar self-review — deep structural analysis |
-| Evaluate | sonnet | Plan-fidelity / alignment — "was the plan implemented correctly?" |
-| Test | sonnet | Scenario-based acceptance tests against acceptance criteria |
-| Review | opus | Focus-parameterized code review |
-| Git | haiku | Branches, commits, merges, worktree management |
-| Synthesize | haiku | Aggregates multi-agent outputs |
-| Design | opus | Gap analysis: tickets, critics, wave reads |
-| Architect | opus | Plans, anti-pattern review |
-@end
-
-@define agent_caveats():
-### Agent caveats
-
-- **The Code family writes every fix** — Code for review findings, Fix for gate failures; no other agent type writes code. Finding verification uses adversarial Review passes.
-- **Review agents are focus-parameterized.** Make one `agent()` call with `agentType: "Review"` per focus, with the focus in the prompt. Never batch focuses into one Review call.
-- Give each agent its full context in its prompt.
-@end
-
-@export agent_roster
-@export agent_caveats

package/src/assets/commands/_partials/_ticket_template.mds

@@ -1,56 +0,0 @@
-@define ticket_body_template():
-### Ticket body template
-
----
-
-**Wave:** N
-**Depends on:** {ISSUE_REF}, {ISSUE_REF} (or "none")
-**Issue:** {ISSUE_REF} — written only by `/devflow:dynamic-tickets`' filing step, after the workflow; a drafting agent never writes it
-
----
-
-## Summary
-
-One paragraph: what this ticket implements and why it exists in this wave.
-
-## Scope
-
-**In scope:**
-- Explicit list of what this ticket covers
-- Named deliverables (files, functions, APIs, schemas)
-
-**Out of scope (anti-features — do NOT implement):**
-- Explicit list of what this ticket deliberately excludes
-- Related things that belong to other tickets
-- Future work that must NOT be anticipated
-
-At least one anti-feature is required per ticket.
-
-## Invariants
-
-System properties that MUST remain true after this ticket is merged:
-- Backward compatibility guarantees (if any)
-- Data integrity constraints
-- Performance contracts inherited from prior work
-
-## Acceptance criteria
-
-Numbered, for the Evaluate and Test agents.
-
-1. POSITIVE: The system MUST...
-2. POSITIVE: The API MUST return...
-3. NEGATIVE: The system MUST NOT...
-4. NEGATIVE: Existing behavior X MUST NOT regress...
-
-(Minimum: at least one negative criterion)
-
-## Open questions
-
-Questions that must be answered before implementation begins. If none, write "None".
-
----
-
-**Note for wave scheduler — `Depends on:` cardinality and grammar:** the field lists **zero or more** provider-canonical issue references this ticket must wait for, comma-separated, or the literal `none`. Each entry is one `{ISSUE_REF}`; under `github` an `{ISSUE_REF}` is `#`-prefixed, so a two-dependency ticket renders `Depends on: #{n}, #{n}`. Write the reference exactly as the tracker renders it — never a bare number, never a URL, never a title. The `Wave: N` label is a human-readable hint; actual ordering is determined by reading the `Depends on` relationships.
-@end
-
-@export ticket_body_template