devflow-kit 3.7.0 → 3.9.0

package/src/assets/commands/implement.mds

@@ -2,7 +2,7 @@
 description: Execute a single task through implementation, quality gates, and PR creation - accepts plan documents, issues, or task descriptions
 output-dir: dist/commands
 ---
-@import { knowledge_load, knowledge_writeback } from "./_partials/_knowledge.mds"
+@import { knowledge_load, knowledge_writeback_after_load } from "./_partials/_knowledge.mds"
 @import { decisions_load } from "./_partials/_decisions.mds"
 @import { docs_root } from "./_partials/_docs_root.mds"
 @import { evidence_policy } from "./_partials/_evidence_policy.mds"
@@ -13,7 +13,7 @@ output-dir: dist/commands
 @import "./_partials/_settings.mds" as settings
 # Implement Command
 
-Orchestrate a single task through implementation by spawning specialized agents. The orchestrator only spawns agents and passes context - all work is done by agents.
+Orchestrate a single task through implementation by spawning specialized agents.
 
 ## Usage
 
@@ -40,8 +40,6 @@ $ARGUMENTS
 
 {{issue_ref_grammar()}}
 
-> **Tip**: For best results, run `/plan` first to produce a design artifact, then pass it to `/implement`.
-
 ## Phases
 
 ### Re-validation Continuation Path
@@ -50,13 +48,13 @@ When the user explicitly asks to re-validate, re-check, or re-run quality gates
 
 ### Phase 1: Setup
 
-<!-- learning:on -->
-**Produces:** TASK_ID, BASE_BRANCH, EXECUTION_PLAN, DECISIONS_CONTEXT, FEATURE_KNOWLEDGE, FEATURE_KNOWLEDGE_RULES, PR_DESCRIPTION_GUIDANCE, ISSUE_NUMBER, ISSUE_PR_LINK, EVIDENCE_POLICY, ISSUE_REQUIRED, APPLY_CONVENTIONS, REQUIRE_NON_AUTHOR_APPROVAL, PR_EXCEPTIONS, TEST_PLAN, EVIDENCE_FILE, PR_TEST_PLAN_BLOCK, REVIEW_PUBLICATION
-<!-- learning:off -->
-**Produces:** TASK_ID, BASE_BRANCH, EXECUTION_PLAN, FEATURE_KNOWLEDGE, FEATURE_KNOWLEDGE_RULES, PR_DESCRIPTION_GUIDANCE, ISSUE_NUMBER, ISSUE_PR_LINK, EVIDENCE_POLICY, ISSUE_REQUIRED, APPLY_CONVENTIONS, REQUIRE_NON_AUTHOR_APPROVAL, PR_EXCEPTIONS, TEST_PLAN, EVIDENCE_FILE, PR_TEST_PLAN_BLOCK, REVIEW_PUBLICATION
-<!-- learning:end -->
+<!-- curation:on -->
+**Produces:** TASK_ID, BASE_BRANCH, BASE_REF, EXECUTION_PLAN, DECISIONS_CONTEXT, FEATURE_KNOWLEDGE, FEATURE_KNOWLEDGE_RULES, PR_DESCRIPTION_GUIDANCE, ISSUE_NUMBER, ISSUE_PR_LINK, EVIDENCE_POLICY, ISSUE_REQUIRED, APPLY_CONVENTIONS, REQUIRE_NON_AUTHOR_APPROVAL, PR_EXCEPTIONS, TEST_PLAN, EVIDENCE_FILE, PR_TEST_PLAN_BLOCK, REVIEW_PUBLICATION, GATE_LEVEL
+<!-- curation:off -->
+**Produces:** TASK_ID, BASE_BRANCH, BASE_REF, EXECUTION_PLAN, FEATURE_KNOWLEDGE, FEATURE_KNOWLEDGE_RULES, PR_DESCRIPTION_GUIDANCE, ISSUE_NUMBER, ISSUE_PR_LINK, EVIDENCE_POLICY, ISSUE_REQUIRED, APPLY_CONVENTIONS, REQUIRE_NON_AUTHOR_APPROVAL, PR_EXCEPTIONS, TEST_PLAN, EVIDENCE_FILE, PR_TEST_PLAN_BLOCK, REVIEW_PUBLICATION, GATE_LEVEL
+<!-- curation:end -->
 
-Record the current branch name as `BASE_BRANCH`. Stop the run unless it matches `^[A-Za-z0-9._/+@,#-]{1,200}$`, telling the user it allows only ASCII letters, digits and `._/+@,#-`, at most 200.
+Record the current branch name as `BASE_BRANCH`. Stop the run unless it matches `^(?![-#]|origin\/|(?:@|(?:FETCH_|ORIG_|MERGE_)?HEAD)$)(?!.*\.\.)[A-Za-z0-9._\/+@,#-]{1,200}$` (judge the match by reading; never pass the value to a command), telling the user it allows only ASCII letters, digits and `._/+@,#-`, at most 200; no leading `-` or `#`, no `origin/` prefix, no `..`, not `@` or a HEAD name.
 
 {{docs_root()}}
 
@@ -75,7 +73,7 @@ If `PR_DESCRIPTION_GUIDANCE` was not set above (non-plan paths: issue input or t
 
 **Empty input.** When `COMMAND_INPUT` is empty — a plan handoff arrives this way, with the plan already in the conversation — there is no argument to name the branch from, and the Git agent sees none of this conversation. Write the description yourself: one line, taken from the plan's title or, with no plan, from the conversation. Send it as the setup-task `TASK_DESCRIPTION` below.
 
-Spawn Git agent to set up task environment. The Git agent derives the branch name automatically from the issue or task description:
+Spawn Git agent to set up the task:
 
 ```
 Agent(subagent_type="Git"):
@@ -90,33 +88,14 @@ Derive branch name from issue or description, create feature branch, and fetch i
 Return the branch setup summary."
 ```
 
-The issue token is forwarded **unclassified**, and the routing is decided by
-SHAPE alone — how many tokens `COMMAND_INPUT` has, and whether it ends in `.md`.
-
-`setup-task` is the one step that has resolved a provider, and therefore the only
-one that knows what an issue reference looks like on this machine: `#123`,
-`PROJ-12` and `ENG-12` are three providers' spellings of the same thing. A
-`starts with #` test here would be a github test wearing a neutral name — it
-reclassifies every other provider's reference as a task description, so the
-branch is derived from prose and no issue is ever fetched, with nothing reporting
-a problem. Token COUNT is the gate that stays provider-neutral: every one of
-those spellings is a single token, and no free-text task description is.
+The issue token is forwarded **unclassified**; routing is by SHAPE alone (the token count of `COMMAND_INPUT` and a `.md` ending). Only `setup-task` has resolved a provider, so a `starts with #` test would be a github test that reclassifies `PROJ-12` and `ENG-12` as task descriptions: the branch comes from prose, no issue is fetched and nothing reports it. Token COUNT is provider-neutral: every issue spelling is one token and no free-text description is.
 
-The two tests this command does make are its own under every provider:
-
-- **Extension.** A path ending in `.md` is a plan document, never an issue
-  reference — it goes to `PLAN_ARTIFACT_PATH` and neither of the other two keys.
-  `ISSUE_INPUT` then carries the plan's frontmatter `issue` instead, never the
-  path (Plan Document Handling step 4).
-- **Token count.** A single token is an issue reference. Two or more is prose:
-  forwarding only its FIRST token would send `/implement fix the login bug` to
-  the Git agent as `ISSUE_INPUT: fix` with no description at all, and
-  `setup-task` fetches whatever it is handed — so the command would derive a
-  branch from a failed lookup and drop the request on the floor.
+- **Extension.** A path ending in `.md` is a plan document, never an issue reference: it goes to `PLAN_ARTIFACT_PATH` only, and `ISSUE_INPUT` carries the plan's frontmatter `issue`, never the path (Plan Document Handling step 4).
+- **Token count.** One token is an issue reference; two or more is prose. Forwarding the FIRST token alone would send `/implement fix the login bug` as `ISSUE_INPUT: fix` with no description, so the request is dropped.
 
 **Capture from Git agent output** (used throughout flow):
 - `TASK_ID`: The branch name created by Git agent (use as TASK_ID for rest of flow)
-- `BASE_BRANCH`: Branch this feature was created from (for PR target)
+- `BASE_BRANCH`: Branch this feature was created from (for PR target); stop unless it passes the setup check
 - `ISSUE_NUMBER`: the provider-canonical issue identifier for this task — the same value the Git agent emits as `ISSUE_ID` (if provided, or created by the Git agent's issue-first step in setup-task)
 - `branch_slug`: `TASK_ID` with every `/` replaced by `-`. It names `handoff-{branch_slug}.md` and `evidence-{branch_slug}.md` only when it matches `^[A-Za-z0-9._-]{1,200}$`; any other branch name stops the run here, telling the user it cannot name those files.
 
@@ -162,18 +141,20 @@ Phase 11 passes the resolved value to the evidence script (`publish`), which dec
 Pass `COMPLIANCE_DIRECTIVE` to every Code and Fix spawn, on a line of its own.
 
 {{decisions_load()}}
-<!-- learning:on -->
+<!-- curation:on -->
 Pass `DECISIONS_CONTEXT` to Code agent (Phase 2) and Harden agent (Phase 4).
 
-<!-- learning:end -->
+<!-- curation:end -->
 {{knowledge_load()}}
 
+**Fresh base.** Before Phase 2, write `BASE_BRANCH` with the Write tool to the file that `F="$(mktemp)" && echo "F=$F"` prints, after one Read of it. If the Write tool fails, treat the value as missing; never write it with a shell command. Then run `F="{name file}"; trap 'rm -- "$F"' EXIT; cd "{worktree}" && node "$HOME/.devflow/scripts/resolve-base.cjs" local --name-stdin < "$F"; echo "exit=$?"`. Output other than one `BASE_REF=` line (40 or 64 hex, or `none`) with `exit=0` counts as `NOTE=stop`, `REASON=resolver-unavailable`. Record `BASE_REF`. By `NOTE`: `none` continues; `info` prints one plain line; `degraded` records `TRACEABILITY: DEGRADED (base {REASON}; fix: {fix})`; `stop` (`BASE_REF=none`) stops the run, naming REASON and its fix. Fix by REASON: no-merge-base `git fetch --unshallow`; no-ref or timeout `git fetch origin <base>` (`<base>` stays as written); resolver-unavailable `re-run; if it repeats, run devflow init`; invalid-name the allowed set, never the name; any other REASON none, and `; fix: {fix}` is left out.
+
 ### Phase 2: Implement
 
 **Produces:** CODE_AGENT_OUTPUT, FILES_CHANGED
 **Requires:** TASK_ID, BASE_BRANCH, EXECUTION_PLAN
 
-Based on Setup context (plan document, issue body, or conversation context), use the three-strategy framework:
+Setup context is the plan document, issue body or conversation.
 
 **Strategy Selection**:
 - If plan document provided: use `execution-strategy` from frontmatter (if absent, use the table below)
@@ -187,7 +168,7 @@ Based on Setup context (plan document, issue body, or conversation context), use
 
 ---
 
-**SINGLE_CODE_AGENT** (default):
+**SINGLE_CODE_AGENT**:
 
 ```
 Agent(subagent_type="Code"):
@@ -198,15 +179,15 @@ BASE_BRANCH: {base branch}
 EXECUTION_PLAN: {full plan from setup context}
 PATTERNS: {patterns from plan document or empty}
 FEATURE_KNOWLEDGE: {feature_knowledge}
-<!-- learning:on -->
+<!-- curation:on -->
 DECISIONS_CONTEXT: {decisions_context}
-<!-- learning:end -->
+<!-- curation:end -->
 {COMPLIANCE_DIRECTIVE}"
 ```
 
 ---
 
-**SEQUENTIAL_CODE_AGENTS** (>= 10 files or >= 7 steps):
+**SEQUENTIAL_CODE_AGENTS**:
 
 Spawn Code agents one at a time. Each appends its own phase section to the handoff file, and the next reads only the section before it:
 
@@ -220,9 +201,9 @@ BASE_BRANCH: {base branch}
 EXECUTION_PLAN: {phase 1 steps}
 PATTERNS: {patterns from plan document or empty}
 FEATURE_KNOWLEDGE: {feature_knowledge}
-<!-- learning:on -->
+<!-- curation:on -->
 DECISIONS_CONTEXT: {decisions_context}
-<!-- learning:end -->
+<!-- curation:end -->
 {COMPLIANCE_DIRECTIVE}
 HANDOFF_REQUIRED: true
 HANDOFF_FILE: {worktree}/.devflow/docs/handoff-{branch_slug}.md"
@@ -240,19 +221,19 @@ PATTERNS: {patterns from plan document or empty}
 PRIOR_PHASE_SUMMARY: {summary from previous Code agent}
 FILES_FROM_PRIOR_PHASE: {list of files created}
 FEATURE_KNOWLEDGE: {feature_knowledge}
-<!-- learning:on -->
+<!-- curation:on -->
 DECISIONS_CONTEXT: {decisions_context}
-<!-- learning:end -->
+<!-- curation:end -->
 {COMPLIANCE_DIRECTIVE}
 HANDOFF_REQUIRED: {true if not last phase}
 HANDOFF_FILE: {worktree}/.devflow/docs/handoff-{branch_slug}.md"
 ```
 
-**Handoff Protocol**: Each sequential Code agent receives the prior Code agent's implementation summary via PRIOR_PHASE_SUMMARY and FILES_FROM_PRIOR_PHASE. The Code agent's built-in branch orientation step handles git log scanning, file reading, and pattern discovery automatically. Each Code agent with HANDOFF_REQUIRED=true appends its own `## Phase {N} Implementation Summary` section, at most 8,192 bytes, to `{worktree}/.devflow/docs/handoff-{branch_slug}.md` (survives context compaction), never rewriting an earlier section and keeping any `## Evidence Exceptions` section byte-identical; the next Code agent reads only the section of the phase immediately before its own through HANDOFF_FILE. The orchestrator writes no phase section. Delete `{worktree}/.devflow/docs/handoff-{branch_slug}.md` once the PR exists — after Phase 9 (cleanup).
+**Handoff Protocol**: Each Code agent with HANDOFF_REQUIRED=true appends its own `## Phase {N} Implementation Summary` section, at most 8,192 bytes, to `{worktree}/.devflow/docs/handoff-{branch_slug}.md`, never rewriting an earlier section and keeping any `## Evidence Exceptions` section byte-identical; the next Code agent reads only the section of the phase immediately before its own through HANDOFF_FILE. The orchestrator writes no phase section. Delete `{worktree}/.devflow/docs/handoff-{branch_slug}.md` once the PR exists — after Phase 9 (cleanup).
 
 ---
 
-**PARALLEL_CODE_AGENTS** (rare - truly independent artifacts):
+**PARALLEL_CODE_AGENTS**:
 
 Spawn multiple Code agents **in a single message**, each with independent subtask:
 
@@ -265,9 +246,9 @@ BASE_BRANCH: {base branch}
 EXECUTION_PLAN: {subtask 1 steps}
 PATTERNS: {patterns}
 FEATURE_KNOWLEDGE: {feature_knowledge}
-<!-- learning:on -->
+<!-- curation:on -->
 DECISIONS_CONTEXT: {decisions_context}
-<!-- learning:end -->
+<!-- curation:end -->
 {COMPLIANCE_DIRECTIVE}"
 
 Agent(subagent_type="Code"):  # Code agent 2 (same message)
@@ -278,24 +259,26 @@ BASE_BRANCH: {base branch}
 EXECUTION_PLAN: {subtask 2 steps}
 PATTERNS: {patterns}
 FEATURE_KNOWLEDGE: {feature_knowledge}
-<!-- learning:on -->
+<!-- curation:on -->
 DECISIONS_CONTEXT: {decisions_context}
-<!-- learning:end -->
+<!-- curation:end -->
 {COMPLIANCE_DIRECTIVE}"
 ```
 
-**Independence criteria** (all must be true for PARALLEL_CODE_AGENTS):
-- No shared contracts or interfaces
-- No integration points between subtasks
-- Different files/modules with no imports between them
-- Each subtask is self-contained
+**Independence criteria** (all must be true for PARALLEL_CODE_AGENTS): no shared contracts, interfaces or integration points between subtasks; different files/modules with no imports between them.
 
 ### Phase 3: Polish
 
 **Produces:** POLISH_OUTPUT
-**Requires:** BASE_BRANCH
+**Requires:** BASE_REF, GATE_LEVEL
 
-After the Code agent completes, spawn Polish agent to polish the code. The Phase 6 Validate covers its commits. `{branch_diff}` is the output of `git diff --name-only --diff-filter=d {BASE_BRANCH}...HEAD`, run again at each spawn.
+**Gate level.** At `standard` or `lean`, once per run, run `d="${CLAUDE_CONFIG_DIR:-}"; case "$d" in /*) ;; *) d="$HOME/.claude" ;; esac; printf '%s\n' "$d"` in Bash and Read `<that directory>/skills/devflow:agent-references/references/commands/implement-levels.md` with the Read tool, and apply each row to the phase it names.
+
+- No row or rule overrides the next two lines.
+- If the Read fails, or the file has no `## Phases` heading with the `| Phase | standard | lean |` header, or a row breaks its grammar, apply no row, keep `GATE_LEVEL` and say `level reference unreadable: no level rows applied`.
+- Validate, the CI gate, the evidence claims and the compliance directive run at every level. An enabled compliance lens keeps Harden.
+
+After the Code agent completes, spawn Polish agent to polish the code. The Phase 6 Validate covers its commits. `{branch_diff}` is the output of `git diff --name-only --diff-filter=d {BASE_REF}...HEAD`, run again at each spawn; a non-zero exit stops, and an empty list counts only on exit 0.
 
 ```
 Agent(subagent_type="Polish"):
@@ -309,17 +292,17 @@ Commit any improvements with a conventional-commit message."
 ### Phase 4: Self-Review
 
 **Produces:** HARDEN_OUTPUT
-**Requires:** BASE_BRANCH
+**Requires:** BASE_REF
 
-After Polish agent completes, spawn Harden agent as the quality gate:
+After Phase 3, spawn Harden agent as the quality gate:
 
 ```
 Agent(subagent_type="Harden"):
 "TASK_DESCRIPTION: {task description}
 FILES_CHANGED: {branch_diff}
-<!-- learning:on -->
+<!-- curation:on -->
 DECISIONS_CONTEXT: {decisions_context}
-<!-- learning:end -->
+<!-- curation:end -->
 FEATURE_KNOWLEDGE: {feature_knowledge_rules}
 Evaluate 9 pillars, fix P0/P1 issues, report status"
 ```
@@ -329,7 +312,7 @@ Harden agent reports `### Status: PASS | FIXED | BLOCKED`. **If BLOCKED:** repor
 ### Phase 5: Alignment Check
 
 **Produces:** ALIGNMENT_RESULT
-**Requires:** BASE_BRANCH, EXECUTION_PLAN
+**Requires:** BASE_REF, EXECUTION_PLAN
 
 After Harden agent passes, spawn Evaluate agent to validate alignment. Evaluate agent receives `FEATURE_KNOWLEDGE_RULES` as acceptance context only; pattern and anti-pattern judgments belong to Harden agent:
 
@@ -357,9 +340,9 @@ Validate alignment with request and plan. Report ALIGNED or MISALIGNED with deta
    TASK_DESCRIPTION: Fix alignment issues
    MISALIGNMENTS: {structured misalignments from Evaluate agent}
    SCOPE: Fix only the listed misalignments, no other changes
-   <!-- learning:on -->
+   <!-- curation:on -->
    DECISIONS_CONTEXT: {decisions_context}
-   <!-- learning:end -->
+   <!-- curation:end -->
    {COMPLIANCE_DIRECTIVE}"
    ```
    - Loop back to Phase 5 (re-check alignment). The fix is not validated here: the Phase 6 run covers it.
@@ -368,13 +351,15 @@ Validate alignment with request and plan. Report ALIGNED or MISALIGNED with deta
 ### Phase 6: Validate
 
 **Produces:** VALIDATION_RESULT, VALIDATED_HEAD
-**Requires:** BASE_BRANCH
+**Requires:** BASE_REF, GATE_LEVEL
 
 Validate takes the one full-suite slot, after every commit it must cover: Code, Polish, Harden and the alignment fixes. After Evaluate agent passes, spawn Validate agent. `FILES_CHANGED` is the branch diff:
 
 ```
 Agent(subagent_type="Validate"):
-"FILES_CHANGED: {branch_diff}
+"GATE_LEVEL: {GATE_LEVEL}
+BASE_SHA: {BASE_REF}
+FILES_CHANGED: {branch_diff}
 VALIDATION_SCOPE: full
 Run build, typecheck, lint, test. Report pass/fail with failure details."
 ```
@@ -391,9 +376,9 @@ Run build, typecheck, lint, test. Report pass/fail with failure details."
    TASK_DESCRIPTION: Fix validation failures
    VALIDATION_FAILURES: {parsed failures from Validate agent}
    SCOPE: Fix only the listed failures, no other changes
-   <!-- learning:on -->
+   <!-- curation:on -->
    DECISIONS_CONTEXT: {decisions_context}
-   <!-- learning:end -->
+   <!-- curation:end -->
    {COMPLIANCE_DIRECTIVE}"
    ```
    - Loop back to Phase 6 (re-validate at the new HEAD, full scope)
@@ -415,7 +400,7 @@ Run build, typecheck, lint, test. Report pass/fail with failure details."
 ### Phase 7: QA Testing
 
 **Produces:** QA_RESULT
-**Requires:** BASE_BRANCH, EXECUTION_PLAN, TEST_PLAN, VALIDATED_HEAD
+**Requires:** BASE_REF, EXECUTION_PLAN, TEST_PLAN, VALIDATED_HEAD
 
 After Phase 6 passes, spawn Test agent for scenario-based acceptance testing:
 
@@ -445,9 +430,9 @@ After every Test agent run — PASS or FAIL, first run or retry — append its T
    TASK_DESCRIPTION: Fix QA test failures
    QA_FAILURES: {structured failures from Test agent}
    SCOPE: Fix only the listed failures, no other changes
-   <!-- learning:on -->
+   <!-- curation:on -->
    DECISIONS_CONTEXT: {decisions_context}
-   <!-- learning:end -->
+   <!-- curation:end -->
    {COMPLIANCE_DIRECTIVE}"
    ```
    - Loop back to Phase 7 (re-run Test agent). The fix is not validated here: Phase 8 covers it.
@@ -474,21 +459,22 @@ Verify the qa-fix commits did not break anything."
 ### Phase 9: Open PR
 
 **Produces:** PR_NUMBER
-**Requires:** BASE_BRANCH, TASK_ID, ISSUE_NUMBER, ISSUE_PR_LINK, PR_EXCEPTIONS, PR_TEST_PLAN_BLOCK, PR_DESCRIPTION_GUIDANCE, APPLY_CONVENTIONS, CODE_AGENT_OUTPUT
+**Requires:** BASE_BRANCH, BASE_REF, TASK_ID, ISSUE_NUMBER, ISSUE_PR_LINK, PR_EXCEPTIONS, PR_TEST_PLAN_BLOCK, PR_DESCRIPTION_GUIDANCE, APPLY_CONVENTIONS, CODE_AGENT_OUTPUT
 
-Run once, after the gates, under every strategy. This phase sits outside the strategy branches, so no run reaches the end with commits and no PR. No Code agent opens a PR: the Git agent does, and it pastes `ISSUE_PR_LINK`, `PR_EXCEPTIONS` and `PR_TEST_PLAN_BLOCK` through their paste gates and scrubs the body (D11) before `gh pr create`. This command renders no link line and creates no PR itself: the Git agent's Phase-1 rendering is the only one, forwarded verbatim.
+Run once, after the gates, under every strategy. No Code agent opens a PR: the Git agent does, and it pastes `ISSUE_PR_LINK`, `PR_EXCEPTIONS` and `PR_TEST_PLAN_BLOCK` through their paste gates and scrubs the body (D11) before `gh pr create`. This command renders no link line and creates no PR itself: the Git agent's Phase-1 rendering is the only one, forwarded verbatim.
 
 ```
 Agent(subagent_type="Git"):
 "OPERATION: ensure-pr-ready
 WORKTREE_PATH: {worktree}
 BASE_BRANCH: {base branch}
+BASE_REF: {BASE_REF}
 TASK_ID: {task-id}
 ISSUE_NUMBER: {ISSUE_ID captured in Phase 1, or (none)}
 ISSUE_PR_LINK: {ISSUE_PR_LINK captured in Phase 1, or (none)}
 PR_EXCEPTIONS: {the ## Evidence Exceptions section of {worktree}/.devflow/docs/handoff-{branch_slug}.md verbatim, or (none)}
 PR_TEST_PLAN_BLOCK: {PR_TEST_PLAN_BLOCK verbatim, or (none)}
-PR_DESCRIPTION_GUIDANCE: {pr_description_guidance from Phase 1 unless it is (none), then the Code agents' reports from CODE_AGENT_OUTPUT in spawn order — Implementation, Commits and Key Decisions, and a sequential agent's ## Phase {N} Implementation Summary}
+PR_DESCRIPTION_GUIDANCE: {pr_description_guidance from Phase 1 unless it is (none), then the Code agents' reports from CODE_AGENT_OUTPUT in spawn order — Implementation, Commits and Key Decisions, and a sequential agent's ## Phase {N} Implementation Summary, then Validate's `Lint pack:` line if UNVERIFIED, for Testing}
 APPLY_CONVENTIONS: {APPLY_CONVENTIONS}
 COMMIT_UNCOMMITTED: false
 Open the pull request for this branch and return the pre-flight summary."
@@ -517,11 +503,11 @@ git push origin HEAD; echo "exit=$?"
 3. **If NO_PR or NO_CI** → skip: "No PR/CI configured, skipping CI validation." Proceed to Phase 11.
 4. **If PENDING** and fewer than 3 waits have run → wait again (step 1). After the third wait → report "CI still running — verify manually before merging" and proceed.
 5. **If INDETERMINATE** and fewer than 3 waits have run → wait again (step 1). After the third wait → report "CI status unknown — verify manually before merging" and proceed.
-<!-- learning:on -->
+<!-- curation:on -->
 6. **If FAILING** and fewer than 2 fixes have run → report the failing checks from the line. Spawn `Agent(subagent_type="Fix")` whose prompt opens with `OPERATION: ci-fix`, with `COMPLIANCE_DIRECTIVE` (when it is not empty), `CI_FAILURES`, `DECISIONS_CONTEXT` and `PUSH: false`; `CI_FAILURES` holds the failing-check names from the line and nothing else, because the Fix agent fetches the full names and reads the logs itself and this command reads none. After a fix, push with the command above and, if a wait remains, wait again (step 1); a failed push records `TRACEABILITY: DEGRADED (ci push failed)`, reports "CI status unknown — verify manually before merging" and stops waiting. After the second fix still FAILING → report the failing checks and proceed.
-<!-- learning:off -->
+<!-- curation:off -->
 6. **If FAILING** and fewer than 2 fixes have run → report the failing checks from the line. Spawn `Agent(subagent_type="Fix")` whose prompt opens with `OPERATION: ci-fix`, with `COMPLIANCE_DIRECTIVE` (when it is not empty), `CI_FAILURES` and `PUSH: false`; `CI_FAILURES` holds the failing-check names from the line and nothing else, because the Fix agent fetches the full names and reads the logs itself and this command reads none. After a fix, push with the command above and, if a wait remains, wait again (step 1); a failed push records `TRACEABILITY: DEGRADED (ci push failed)`, reports "CI status unknown — verify manually before merging" and stops waiting. After the second fix still FAILING → report the failing checks and proceed.
-<!-- learning:end -->
+<!-- curation:end -->
 7. **Budget**: at most 3 waits and 2 fixes in all. When one is spent, report the current status and proceed.
 <!-- /PATTERN: ci-status-gate -->
 
@@ -530,7 +516,7 @@ git push origin HEAD; echo "exit=$?"
 **Produces:** EVIDENCE_RESULT
 **Requires:** PR_NUMBER, EVIDENCE_FILE, REVIEW_PUBLICATION
 
-Run once, after Phase 10, under every strategy: the PR exists by now, opened in Phase 9. The re-validation path has no CI gate and runs this phase straight after Phase 9. Skip it only when Phase 9 stopped the run. A `ci` TP reads `INDETERMINATE` only when the CI gate could not tell or did not run.
+Run once, after Phase 10, under every strategy. Skip it only when Phase 9 stopped the run. A `ci` TP reads `INDETERMINATE` only when the CI gate could not tell or did not run.
 
 **Push first.** Every claim is keyed to the HEAD an agent reported, and a Harden or Fix agent may have committed without pushing; a claim whose SHA is not in the PR reads `UNVERIFIED`. So push the branch once before the script — never force, and no retry:
 
@@ -550,30 +536,27 @@ Drop the `--evidence` pair when that file does not exist or its path does not ma
 
 ### Phase 12: Report
 
-**Requires:** VALIDATION_RESULT, ALIGNMENT_RESULT, QA_RESULT, PR_NUMBER, EVIDENCE_RESULT
+**Requires:** VALIDATION_RESULT, ALIGNMENT_RESULT, QA_RESULT, PR_NUMBER, EVIDENCE_RESULT, GATE_LEVEL
 
-Display completion summary with phase status, PR info, and next steps.
+Display completion summary with phase status, `Gate level: {GATE_LEVEL}` with any level note, Validate's `Lint pack:` line if any, PR info, and next steps.
 
 Show the test plan's evidence from Phase 11: `Test plan: {VERIFIED-CI + ATTESTED-LOCAL}/{total} verified (VERIFIED-CI {n}, ATTESTED-LOCAL {n})`, read from the `EVIDENCE` line and never inferred, then its `**Body**:` / `**Comment**:` line verbatim. Without an `EVIDENCE` line, show `Test plan: evidence unavailable`; with no test plan, `Test plan: missing`.
 
-If any Git agent output emitted `TRACEABILITY: DEGRADED ({reason})` lines during the run, or Phase 10's push, Phase 11's push or Phase 11's script output carried one, surface them verbatim in the report under a `### Traceability` subsection so the user can act on them.
+If any Git agent output emitted `TRACEABILITY: DEGRADED ({reason})` lines during the run, or the fresh base step, Phase 10's push, Phase 11's push or Phase 11's script output carried one, surface them verbatim in the report under a `### Traceability` subsection so the user can act on them.
 
 If Phase 9 listed uncommitted files, show them as a `### Uncommitted files` subsection: the user commits them or discards them.
 
 If Phase 1 recorded an evidence exception, show its `## Evidence Exceptions` lines in the report.
 
-{{knowledge_writeback()}}
+{{knowledge_writeback_after_load()}}
 
 ## Architecture
 
 ```
-/implement (orchestrator - spawns agents only)
-│
-├─ Re-validation Path (when user says "re-validate"/"re-check"/"re-run gates")
-│  └─ Branch safety → skip Phase 2 → record BASE_BRANCH → Phases 3-8 → Phase 9, 11, 12
+/implement
 │
 ├─ Phase 1: Setup
-├─ Phase 2: Implement (3-strategy framework)
+├─ Phase 2: Implement
 ├─ Phase 3: Polish
 ├─ Phase 4: Self-Review
 ├─ Phase 5: Alignment Check
@@ -582,7 +565,7 @@ If Phase 1 recorded an evidence exception, show its `## Evidence Exceptions` lin
 ├─ Phase 8: Re-Validate (only if a qa-fix committed)
 ├─ Phase 9: Open PR (every strategy, outside the strategy branches)
 ├─ Phase 10: CI Status Gate (every strategy)
-├─ Phase 11: Evidence (every strategy, once the PR exists)
+├─ Phase 11: Evidence (every strategy)
 ├─ Phase 12: Report
 │
 └─ Feature Knowledge Write-Back (Conditional)
@@ -590,15 +573,11 @@ If Phase 1 recorded an evidence exception, show its `## Evidence Exceptions` lin
 
 ## Principles
 
-1. **Orchestration only** - Command spawns agents, never does work itself; the inline calls are the bounded plumbing the charter allows: the Phase 10 and Phase 11 pushes, the Phase 10 ci-wait call, the Phase 11 evidence publish call and the evidence script checks
-2. **Agent ownership** - Each agent owns its output completely
-3. **Honest reporting** - Display agent outputs directly
-4. **Strict delegation** - Never perform agent work in main session. "Spawn X" means call Agent tool with X, not do X's work yourself
-5. **Validate agent owns validation** - Never run `npm test`, `npm run build`, or similar in main session; always delegate to Validate agent
-6. **Fix agent owns fixes** - Never implement fixes in main session; spawn Fix agent for validation failures and alignment fixes
-7. **Loop limits** - Max 2 validation retries, max 2 alignment fix iterations, max 2 QA retries before escalating to user; the CI gate allows at most 3 waits and 2 fixes
-8. **CI awareness** - CI status is checked before merge under every strategy, once Phase 9 has opened the PR; test-plan evidence (Phase 11) is recorded under every strategy once the PR exists
+1. **Orchestration only** - Command spawns agents, never does work itself (no tests, builds or fixes); "Spawn X" means call the Agent tool; the inline calls are the bounded plumbing the charter allows: the fresh base step's resolver calls (Phase 1, re-validation), the Phase 10 and 11 pushes, the Phase 10 ci-wait call, the Phase 11 evidence publish call and the evidence script checks
+2. **Honest reporting** - Display agent outputs directly
+3. **Loop limits** - Max 2 validation retries, max 2 alignment fix iterations, max 2 QA retries before escalating to user; the CI gate allows at most 3 waits and 2 fixes
+4. **CI awareness** - CI status is checked before merge; test-plan evidence (Phase 11) is recorded under every strategy
 
 ## Error Handling
 
-If any agent fails, report the phase, agent type, and error. Offer options: retry phase, investigate systematically, or escalate to user.
+If any agent fails, report the phase, agent type and error. Offer: retry the phase, investigate, or escalate to user.

package/src/assets/commands/plan.mds

@@ -104,17 +104,17 @@ If the user says "skip" or "just proceed" — skip remaining questions, present
 
 **MANDATORY**: Do not spawn any agents until Gate 0 is confirmed — the Step 0 issue fetch (if applicable) is the sole exception; it precedes and informs Gate 0 and must complete before Gate 0 begins.
 
-<!-- learning:on -->
+<!-- curation:on -->
 #### Phase 2: Orient + Load Decisions
-<!-- learning:off -->
+<!-- curation:off -->
 #### Phase 2: Orient
-<!-- learning:end -->
+<!-- curation:end -->
 
-<!-- learning:on -->
+<!-- curation:on -->
 **Produces:** SKIM_CONTEXT, DECISIONS_CONTEXT, FEATURE_KNOWLEDGE, FEATURE_KNOWLEDGE_RULES, GATE_LEVEL
-<!-- learning:off -->
+<!-- curation:off -->
 **Produces:** SKIM_CONTEXT, FEATURE_KNOWLEDGE, FEATURE_KNOWLEDGE_RULES, GATE_LEVEL
-<!-- learning:end -->
+<!-- curation:end -->
 **Requires:** CONFIRMED_SCOPE
 
 {{settings.settings_resolve()}}
@@ -124,9 +124,9 @@ Spawn Skim agent for codebase context:
 ```
 Agent(subagent_type="Skim"):
 "Orient in codebase for design planning: {feature/issues}
-<!-- learning:on -->
-LEARNING: {LEARNING from the settings line}
-<!-- learning:end -->
+<!-- curation:on -->
+CURATION: {CURATION from the settings line}
+<!-- curation:end -->
 Run rskim on source directories (NOT repo root) to identify:
 - Existing patterns and conventions in the affected area
 - File structure and module boundaries
@@ -138,17 +138,17 @@ Return codebase context for requirements analysis."
 {{docs_root()}}
 
 {{decisions_load()}}
-<!-- learning:on -->
+<!-- curation:on -->
 This produces a compact index of active ADR/PF entries. Pass the Skim agent context to all subsequent agents. Pass `DECISIONS_CONTEXT` to the Design agents of the gap-analysis phase as one shared slice — prior decisions constrain design, known pitfalls inform gap analysis. Design agents use `devflow:apply-decisions` to Read full entry bodies on demand.
 
-<!-- learning:end -->
+<!-- curation:end -->
 {{knowledge_load()}}
 
-<!-- learning:on -->
+<!-- curation:on -->
 Pass `FEATURE_KNOWLEDGE` to Explore and Design agents. Pass `DECISIONS_CONTEXT` to Design agents only.
-<!-- learning:off -->
+<!-- curation:off -->
 Pass `FEATURE_KNOWLEDGE` to Explore and Design agents.
-<!-- learning:end -->
+<!-- curation:end -->
 
 **Gate level.** At `standard` or `lean`, once per run, run `d="${CLAUDE_CONFIG_DIR:-}"; case "$d" in /*) ;; *) d="$HOME/.claude" ;; esac; printf '%s\n' "$d"` in Bash and Read `<that directory>/skills/devflow:agent-references/references/commands/plan-levels.md` with the Read tool, and apply it to Phases 3-14.
 
@@ -190,11 +190,11 @@ Combine into: user needs, similar features, constraints, failure modes"
 #### Phase 5: Gap Analysis (Parallel)
 
 **Produces:** GAP_OUTPUTS, COMPLIANCE_ACTIVE, COMPLIANCE_FRAMEWORKS
-<!-- learning:on -->
+<!-- curation:on -->
 **Requires:** EXPLORATION_SYNTHESIS, SKIM_CONTEXT, DECISIONS_CONTEXT
-<!-- learning:off -->
+<!-- curation:off -->
 **Requires:** EXPLORATION_SYNTHESIS, SKIM_CONTEXT
-<!-- learning:end -->
+<!-- curation:end -->
 
 {{compliance_gate()}}
 
@@ -220,9 +220,9 @@ Each Design agent receives:
 - Focus: (their assigned focus from table)
 - Exploration synthesis from Phase 4
 - Skim agent context from Phase 2
-<!-- learning:on -->
+<!-- curation:on -->
 - `DECISIONS_CONTEXT` (index from Phase 2)
-<!-- learning:end -->
+<!-- curation:end -->
 - `COMPLIANCE_FOCUS_DIRECTIVE` (compliance focus only)
 - Multi-issue: all issue bodies
 
@@ -232,9 +232,9 @@ Each Design agent receives:
 Agent(subagent_type="Design"):
 "Mode: gap-analysis
 Focus: {completeness|architecture|security|performance|compliance|consistency|dependencies}
-<!-- learning:on -->
+<!-- curation:on -->
 DECISIONS_CONTEXT: {decisions_context}
-<!-- learning:end -->
+<!-- curation:end -->
 FEATURE_KNOWLEDGE: {feature_knowledge}
 {COMPLIANCE_FOCUS_DIRECTIVE}  (compliance focus only)
 Run `d="${CLAUDE_CONFIG_DIR:-}"; case "$d" in /*) ;; *) d="$HOME/.claude" ;; esac; printf '%s\n' "$d"` in Bash, then Read `<that directory>/skills/devflow:gap-analysis/references/compliance.md` with the Read tool and apply it as your focus patterns.  (compliance focus only)
@@ -242,11 +242,11 @@ Artifacts:
   Feature/Issues: {feature description or issue bodies}
   Exploration synthesis: {Phase 4 output}
   Codebase context: {Phase 2 output}
-<!-- learning:on -->
+<!-- curation:on -->
 Analyze only your assigned focus area. Follow devflow:apply-decisions for DECISIONS_CONTEXT.
-<!-- learning:off -->
+<!-- curation:off -->
 Analyze only your assigned focus area.
-<!-- learning:end -->
+<!-- curation:end -->
 Cite evidence from provided artifacts."
 ```
 
@@ -544,11 +544,11 @@ Display completion summary:
 │  ├─ Phase 1: GATE 0 - Requirements Discovery ⛔ MANDATORY
 │  │  ├─ Git agent (fetch-issue / fetch-issues-batch) - issue mode only
 │  │  └─ AskUserQuestion: Validate interpretation
-<!-- learning:on -->
+<!-- curation:on -->
 │  ├─ Phase 2: Orient + Load Decisions
-<!-- learning:off -->
+<!-- curation:off -->
 │  ├─ Phase 2: Orient
-<!-- learning:end -->
+<!-- curation:end -->
 │  ├─ Phase 3: Explore Requirements (PARALLEL)
 │  └─ Phase 4: Synthesize Exploration
 │

package/src/assets/commands/release.mds

@@ -55,31 +55,31 @@ Read `.release/RELEASE-FLOW.md`:
 
 ### Phase 1b: Load Context
 
-<!-- learning:on -->
+<!-- curation:on -->
 **Produces:** DECISIONS_CONTEXT, FEATURE_KNOWLEDGE, FEATURE_KNOWLEDGE_RULES
-<!-- learning:off -->
+<!-- curation:off -->
 **Produces:** FEATURE_KNOWLEDGE, FEATURE_KNOWLEDGE_RULES
-<!-- learning:end -->
+<!-- curation:end -->
 
-<!-- learning:on -->
+<!-- curation:on -->
 {{settings.settings_resolve()}}
 
 {{decisions_gate()}}
 
 {{decisions_locate()}}
 
-Read `{ledger}/.devflow/learning/index.md`. If the file is absent or empty, set `DECISIONS_CONTEXT` to `(none)`; otherwise use the file content as `DECISIONS_CONTEXT`.
+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`.
 
 {{decisions_slice()}}
 
-<!-- learning:end -->
+<!-- curation:end -->
 {{knowledge_load()}}
 
-<!-- learning:on -->
+<!-- curation:on -->
 Pass `DECISIONS_CONTEXT` and `FEATURE_KNOWLEDGE` only to agents whose contract declares them; the Validate and Git agents this command spawns do not.
-<!-- learning:off -->
+<!-- curation:off -->
 Pass `FEATURE_KNOWLEDGE` only to agents whose contract declares it; the Validate and Git agents this command spawns do not.
-<!-- learning:end -->
+<!-- curation:end -->
 
 ### Phase 1c: Resolve the Evidence Policy
 
@@ -234,11 +234,11 @@ On completion:
 │  └─ Read .release/RELEASE-FLOW.md (learned) or proceed to detect (fresh)
 │
 ├─ Phase 1b: Load Context
-<!-- learning:on -->
+<!-- curation:on -->
 │  └─ Load DECISIONS_CONTEXT and FEATURE_KNOWLEDGE for the agents that declare them
-<!-- learning:off -->
+<!-- curation:off -->
 │  └─ Load FEATURE_KNOWLEDGE for the agents that declare it
-<!-- learning:end -->
+<!-- curation:end -->
 │
 ├─ Phase 2: Detect Release Process (first run only)
 │  └─ Tiered scan: package.json, CI workflows, git history