Closed gates: four definition values that read as working and are not

meta/activities/03-dispatch-client-workflow.yaml

@@ -1,5 +1,5 @@
 id: dispatch-client-workflow
-version: 5.7.0
+version: 5.8.0
 name: Dispatch Client Workflow
 description: Drive the client workflow's activity loop, each worker carrying a bounded run of activities.
 required: true
@@ -95,6 +95,13 @@ steps:
           - action: set
             target: worker_agent_id
             value: null
+  - kind: action
+    id: record-client-completion
+    when: current_activity == null
+    actions:
+      - action: set
+        target: client_workflow_completed
+        value: true
 transitions:
   - to: end-workflow
     condition:
@@ -107,3 +114,4 @@ outcome:
   - Each worker carried a bounded run of activities in one context, so the harness baseline was paid once a run rather than once an activity
   - The user retained control over every decision point — checkpoints surfaced to them and their selections steered the workflow
   - The client workflow has no further activities to run, so the meta can proceed to close it out
+  - Reaching the end of the activity loop is recorded, so close-out can tell a completed run from one that stopped at the iteration bound

work-package/activities/10-post-impl-review.yaml

@@ -1,8 +1,15 @@
 id: post-impl-review
-version: 1.20.0
+version: 1.21.0
 name: Post-Implementation Review
 description: Review implementation quality before validation.
 required: true
+triggers:
+  - workflow: prism
+    description: Run the full analytical pipeline over the change surface when the problem is complex; a simpler one binds prism/structural-analysis inline instead.
+    passContext:
+      - target_path
+      - component_name
+      - issue_title
 steps:
   - kind: action
     id: announce-start
@@ -76,10 +83,13 @@ steps:
       inputs:
         findings_destination: code-review.md
     when: problem_complexity != 'complex'
-  - kind: action
+  - kind: technique
     id: dispatch-prism
     when: problem_complexity == 'complex'
-    actions: []
+    technique:
+      name: workflow-engine::handle-sub-workflow
+      inputs:
+        workflow_id: prism
   - kind: technique
     id: test-suite-review
     technique: review-test-suite

work-package/techniques/naming-conventions.md

@@ -1,6 +1,6 @@
 ---
 metadata:
-  version: 1.0.0
+  version: 1.1.0
 ---
 
 ## Capability
@@ -11,7 +11,7 @@ Derive the feature branch name and the canonical worktree target path for a work
 
 ### issue_type
 
-The issue category (feature, bug, task, enhancement, epic) — drives the branch-name type prefix.
+The issue category (feature, bug, task, enhancement, epic) — drives the branch-name type prefix through a total mapping, one prefix per category.
 
 ### issue_title
 
@@ -42,9 +42,19 @@ Canonical feature-worktree path `<checkout>/.worktrees/<slug>/`, distinct from `
 ## Protocol
 
 1. Skip branch derivation when `{is_review_mode}` is `true` — `{branch_name}` was already captured from the PR reference.
-2. Derive the branch-name type prefix from `{issue_type}`: feature → `feat`, bug → `fix`, task/enhancement → `chore`/`refactor` as appropriate.
+2. Set `{$branch_type_prefix}` from `{issue_type}`, which is one of the five categories [issue-type-detection](./issue-type-detection.md) settles. The table is total, so no run supplies a prefix of its own:
+
+   | `{issue_type}` | `{$branch_type_prefix}` | Why |
+   |---|---|---|
+   | `feature` | `feat` | delivers capability that was not there |
+   | `enhancement` | `feat` | delivers capability the user sees, on something already there |
+   | `epic` | `feat` | the epic's own delivery branch; its member tickets carry their own |
+   | `bug` | `fix` | restores stated behaviour |
+   | `task` | `chore` | maintenance with no change to capability |
+
+   Stop and report when `{issue_type}` is unset, which is what an unsettled category leaves behind: the prefix is part of the branch and pull-request identity and is expensive to change once a pull request is open, so the category is the binding activity's gate to settle, never this step's to guess.
 3. Slugify `{issue_title}` (lowercase, dashes, max ~40 chars) for the description segment.
-4. Set `{branch_name}` to `{type}/{issue_number}-{slugified-title}` per the convention `type/issue-number-short-description`.
+4. Set `{branch_name}` to `{$branch_type_prefix}/{issue_number}-{slugified-title}` per the convention `type/issue-number-short-description`.
 5. Determine the work-package slug `{$wp_slug}` as the basename of `{planning_folder_path}` (the planning slug `YYYY-MM-DD-{initiative-name}`), so the worktree name stays aligned with the server's planning folder. In review mode, derive `{$wp_slug}` from the PR title or branch name instead.
 6. Take `{$checkout_root}` as the ancestor of `{planning_folder_path}` above `.engineering/artifacts/planning/`, and set `{target_path}` to `{$checkout_root}/.worktrees/{$wp_slug}/` — the gitignored feature-worktree directory nested in the checkout. From this point on, "inside `{target_path}`" refers to this worktree (not the checkout at `{host_repo_path}`). Never place `{target_path}` under `{planning_folder_path}` or under `{host_repo_path}`, and never anchor it to a home directory or an install root.
 

workflow-design/techniques/audit-schema-validation.md

@@ -1,6 +1,6 @@
 ---
 metadata:
-  version: 1.1.0
+  version: 1.2.0
 ---
 
 ## Capability
@@ -21,14 +21,16 @@ Count of YAML files that failed schema validation.
 
 ### 1. Validate YAML Schemas
 
-- Run `npx tsx scripts/validate-workflow-yaml.ts <workflow-path>` on every YAML file (`workflow.yaml`, activity files, technique files)
+- Run `npx tsx scripts/validate-workflow-yaml.ts <workflow-path>` on every YAML file (`workflow.yaml`, activity files, technique files), where `<workflow-path>` is the workflow directory **inside the tree under review**
 - Record pass/fail per file with the validator's error message; resolve every failure
 - Set `{pass_count}` and `{fail_count}`
 
 ### 2. Check Technique References
 
-- Run `npx tsx scripts/check-all-refs.ts` to verify every `step.technique` reference resolves through the loader
+- Run `npx tsx scripts/check-all-refs.ts --root <workflows-dir>` to verify every `step.technique` reference resolves through the loader
+- `<workflows-dir>` is the corpus root of the tree under review. Every guard resolves its corpus as `--root` > `WORKFLOWS_DIR` > the server checkout's own `workflows/`, so an omitted root measures that checkout and reports a clean pass on definitions the review never looked at
 
 ### 3. Check Binding Fidelity
 
-- Run `npx tsx scripts/check-binding-fidelity.ts` to verify the change introduces no new binding drift — every `step.technique.inputs` key is a declared input, and every interpolation/condition read resolves to a producer (a declared id, a dollar-prefixed step-local, a `workflow.yaml` variable, or a set-target). It fails only on violations beyond the committed baseline; if a flagged change is intentional, re-snapshot with `--update-baseline`
+- Run `npx tsx scripts/check-binding-fidelity.ts --root <workflows-dir>` to verify the change introduces no new binding drift — every `step.technique.inputs` key is a declared input, and every interpolation/condition read resolves to a producer (a declared id, a dollar-prefixed step-local, a `workflow.yaml` variable, or a set-target)
+- A finding the guard has no verdict for is reported as untriaged. Give it one in `scripts/binding-fidelity-triage.json` — `harmless`, `fix-later`, or `live-bug`, each against a named rationale — so an accepted finding and a real defect stop being the same silence. Classification is a human judgement: there is no flag that suppresses a finding without one