feat(dynamic): add devflow-dynamic plugin — MDS-composed dynamic workflow recipes

.claude-plugin/marketplace.json

@@ -156,6 +156,19 @@
         "best-practices"
       ]
     },
+    {
+      "name": "devflow-dynamic",
+      "source": "./plugins/devflow-dynamic",
+      "description": "Dynamic workflow recipes — dependency-aware tickets→plan→build delivery pipeline",
+      "version": "1.8.3",
+      "keywords": [
+        "dynamic",
+        "workflow",
+        "pipeline",
+        "tickets",
+        "wave"
+      ]
+    },
     {
       "name": "devflow-typescript",
       "source": "./plugins/devflow-typescript",

.devflow/decisions/decisions-ledger.jsonl

@@ -27,3 +27,5 @@
 {"id":"obs_u8elbu","type":"decision","pattern":"Migrations must leave a clean house — delete all legacy artifacts, not just move new-path files","evidence":["I think that the migration should leave a clean house, unless there's a risk. The migration should leave a clean house, and we should clean up after us. Let's do that, please","Straightforward plan — extend Step 7 to delete the known legacy files before attempting rmdir, fix the one stale comment, and add test coverage","Cleaned 15 projects (18 total minus 3 skipped)"],"details":"context: consolidate-to-devflow-dir migration moved files to .devflow/ but left legacy directories behind because skip-list files were never deleted; decision: migrations must explicitly delete all legacy files (including those in skip-lists) and clean up old empty directories — the goal is a fully clean state, not just successful file movement; rationale: leaving legacy directories alongside new ones creates confusion, risks stale writes from non-reinstalled hooks, and requires manual cleanup across all user projects","count":1,"confidence":0.95,"quality_ok":true,"status":"created","created":"2026-05-19T14:23:29.773Z","last_seen":"2026-05-19T14:23:29.773Z","artifact_path":"/Users/dean/Sandbox/devflow/.devflow/decisions/decisions.md#ADR-002","anchor_id":"ADR-002","decisions_status":"Retired"}
 {"id":"obs_6rp5ri","type":"pitfall","pattern":"Post-migration hook writes land at old path when hooks are not rebuilt and reinstalled after a path refactor","evidence":["Why did the refresh write to the old path? Because the hooks installed in your system at that point still used getFeaturesDir() → .features/. The new code that uses .devflow/features/ is on this branch — it wasn't installed globally until you rebuilt and re-inited today","the .features/ copy says updated: 2026-05-19 (today's refresh) — a knowledge refresh hook fires (session-end or background) — it regenerates KNOWLEDGE.md at the old .features/ path","Same story for index.js"],"details":"area: knowledge refresh hooks, sidecar-evaluate, path refactors generally; issue: after a migration moves data to a new path, background hooks (session-end, sidecar) still point to the old path if not yet rebuilt+reinstalled — they silently regenerate files at the legacy location; impact: data divergence between old and new paths; knowledge refreshes updating stale .features/ copy while .devflow/features/ has an older version; impact is silent (no errors, just wrong destination); resolution: any hook path refactor requires explicit rebuild (npm run build) and reinstall (devflow init) on every affected machine before hooks will write to the correct new location; document this dependency in migration notes","count":1,"confidence":0.95,"quality_ok":true,"status":"created","created":"2026-05-19T14:23:29.773Z","last_seen":"2026-05-19T14:23:29.773Z","artifact_path":"/Users/dean/Sandbox/devflow/.devflow/decisions/pitfalls.md#PF-003","mayBeStale":true,"staleReason":"code-ref-missing:KNOWLEDGE.md","anchor_id":"PF-003","decisions_status":"Retired"}
 {"id":"obs_3vt99r","type":"pitfall","pattern":"Assuming a workflow capability does not exist without checking existing agents — the Evaluator already implements intent-vs-implementation comparison","evidence":["are you sure devflow doesn't already do this? isn't it exactly what the evaluator is doing?","You're right to push back — the Evaluator is doing intent-vs-implementation comparison. Let me be precise about what it already does vs what's actually new.","No production tool compares plan/spec intent against implementation. (Confirmed across all 3 research tracks.) — this claim was made before checking devflow's own Evaluator agent"],"details":"area: bug-analysis workflow design, research phase; issue: research concluded no tool performs plan-intent vs implementation comparison, then proceeded to design this as a new capability — without checking whether devflow's own Evaluator agent already does this; impact: wasted design effort and potential duplication; the Evaluator already receives ORIGINAL_REQUEST, EXECUTION_PLAN, FILES_CHANGED, ACCEPTANCE_CRITERIA and performs goal-backward verification; resolution: before designing any new capability that sounds like it overlaps with existing agents (Evaluator, Scrutinizer, Reviewer), explicitly check the existing agent roster and their input contracts first","count":1,"confidence":0.9,"quality_ok":true,"status":"created","created":"2026-05-23T21:17:01.106Z","last_seen":"2026-05-23T21:17:01.106Z","artifact_path":"/Users/dean/Sandbox/devflow/.devflow/decisions/pitfalls.md#PF-005","anchor_id":"PF-005","decisions_status":"Retired"}
+{"id":"obs_pfyb8b","type":"decision","pattern":"Dynamic workflow plugin ships as pure-instruction command recipes — markdown that teaches the model to author and run a dynamic workflow at runtime, with ZERO authored orchestration code (no parser, scheduler, topo-sort, or formula), now or ever","details":"context: the devflow-dynamic plugin (tickets->plan->build delivery pipeline) needed a build/runtime architecture; an L0 ticket-DAG parser (Kahn topological sort run via Bash and passed to the workflow as args) had been drafted into the design doc as the one programmatic dependency; decision: ship the dynamic commands as pure-instruction command recipes — markdown that instructs the main model how to author and run a Claude Code dynamic workflow at runtime — carrying ZERO deterministic code that devflow authors (no parser, scheduler, topo-sort, FP-ratio/cycle formulas); every judgment (which tickets are independent, wave ordering, parallel vs serial, review-cycle counts) is LLM reasoning at runtime, done by agents that read the GitHub issues and their Depends-on relationships with gh; the recipes are thin orchestrators over devflows ALREADY-installed agents (agentType resolves the real agent identity/skills/per-agent model tier, confirmed by spike F5), so no agent prompts are inlined; rationale: a pure-instruction recipe survives the moving dynamic-workflow API, adapts to arbitrary input, and distributes through the command channel devflow already ships, while any authored parser/formula becomes a brittle deterministic dependency the user categorically rejected (not now, not ever); this extends the LLM-vs-plumbing principle from artifact CONTENT to workflow ORCHESTRATION","anchor_id":"ADR-019","decisions_status":"Accepted","date":"2026-06-12"}
+{"id":"obs_10svdf","type":"decision","pattern":"In the dynamic-build pipeline, every Coder code mutation runs a post-code quality pipeline in fixed order Validate->Simplify->Scrutinize, the Evaluator runs ONLY when there is an implementation plan (not after fixes), and the Resolver is split — a Coder writes fixes while adversarial verification strips false positives before any fix is attempted","details":"context: defining the agent topology for the /devflow:dynamic-build recipe (a fusion of /implement + /code-review + /resolve); decision: (1) the Simplifier->Scrutinizer->Evaluator order is a load-bearing, non-negotiable invariant; (2) every Coder mutation (initial implement, resolve-fix, alignment-fix, qa-fix) runs a post-code pipeline of Validate->Simplify->Scrutinize, but the Evaluator runs ONLY when there is an implementation plan to verify against — it is skipped after plain fixes; the Tester is part of this gate; (3) the Resolver is split into two halves — its validate-the-issue-is-real half becomes an adversarial verification pass that strips false positives BEFORE any fix, and its write-the-fix half is handled by a Coder (a Coder loads far more relevant context than a Resolver); rationale: the Evaluators job is to confirm the PLAN was implemented properly, so it is meaningless without a plan and wasteful on every fix; a Coder produces better fixes than a Resolver because of the context it loads; gating every fix behind adversarial false-positive verification prevents wasting Coder effort on non-real findings; preserving the Simplify/Scrutinize order on every code mutation keeps the same quality dynamic the static /implement pipeline enforces","anchor_id":"ADR-020","decisions_status":"Accepted","date":"2026-06-12"}

.devflow/decisions/decisions.md

@@ -1,4 +1,4 @@
-<!-- TL;DR: 17 decisions. Key: ADR-014, ADR-015, ADR-016, ADR-017, ADR-018 -->
+<!-- TL;DR: 19 decisions. Key: ADR-016, ADR-017, ADR-018, ADR-019, ADR-020 -->
 # Architectural Decisions
 
 Append-only. Status changes allowed; deletions prohibited.
@@ -156,3 +156,21 @@ Append-only. Status changes allowed; deletions prohibited.
 - **Decision**: drop Guard B entirely from scripts/hooks/preamble so first-word keyword prompts dispatch regardless of a trailing question mark
 - **Consequences**: users routinely phrase command-style prompts as questions
 - **Source**: self-learning:obs_preamble3
+
+## ADR-019: Dynamic workflow plugin ships as pure-instruction command recipes — markdown that teaches the model to author and run a dynamic workflow at runtime, with ZERO authored orchestration code (no parser, scheduler, topo-sort, or formula), now or ever
+
+- **Date**: 2026-06-12
+- **Status**: Accepted
+- **Context**: the devflow-dynamic plugin (tickets->plan->build delivery pipeline) needed a build/runtime architecture
+- **Decision**: ship the dynamic commands as pure-instruction command recipes — markdown that instructs the main model how to author and run a Claude Code dynamic workflow at runtime — carrying ZERO deterministic code that devflow authors (no parser, scheduler, topo-sort, FP-ratio/cycle formulas)
+- **Consequences**: a pure-instruction recipe survives the moving dynamic-workflow API, adapts to arbitrary input, and distributes through the command channel devflow already ships, while any authored parser/formula becomes a brittle deterministic dependency the user categorically rejected (not now, not ever)
+- **Source**: self-learning:obs_pfyb8b
+
+## ADR-020: In the dynamic-build pipeline, every Coder code mutation runs a post-code quality pipeline in fixed order Validate->Simplify->Scrutinize, the Evaluator runs ONLY when there is an implementation plan (not after fixes), and the Resolver is split — a Coder writes fixes while adversarial verification strips false positives before any fix is attempted
+
+- **Date**: 2026-06-12
+- **Status**: Accepted
+- **Context**: defining the agent topology for the /devflow:dynamic-build recipe (a fusion of /implement + /code-review + /resolve)
+- **Decision**: (1) the Simplifier->Scrutinizer->Evaluator order is a load-bearing, non-negotiable invariant
+- **Consequences**: the Evaluators job is to confirm the PLAN was implemented properly, so it is meaningless without a plan and wasteful on every fix
+- **Source**: self-learning:obs_10svdf