fix(meta,work-package): the artifacts checkout is the git target for planning artifacts (#343 corpus)

meta/activities/04-end-workflow.yaml

@@ -1,23 +1,24 @@
 id: end-workflow
-version: 4.2.0
+version: 4.4.0
 name: End Workflow
 description: Close out the client workflow.
 required: true
 steps:
+  - kind: technique
+    id: read-session
+    technique: workflow-engine::read-session
   - kind: technique
     id: verify-outcomes
     technique:
       name: workflow-engine::verify-outcomes
       inputs:
         outcomes: target_workflow_outcomes
-        state: client_state
   - kind: technique
     id: generate-summary
     technique:
       name: workflow-engine::generate-summary
       inputs:
         workflow_definition: target_workflow_id
-        execution_trace: client_trace
   - kind: checkpoint
     id: completion-confirmed
     message: Session summary presented above. Confirm closure or return to the workflow to address remaining items.

meta/techniques/agent-conduct.md

@@ -1,6 +1,6 @@
 ---
 metadata:
-  version: 4.5.0
+  version: 4.6.0
 ---
 
 ## Capability
@@ -95,7 +95,7 @@ On resume, still dispatch a worker via [dispatch-activity](./workflow-engine/dis
 
 ### orchestrator-component-path-scope
 
-Branch creation, PR creation, and code commits MUST be performed inside the component directory (the submodule), NEVER in the host monorepo root. Planning artifact commits (`.engineering/artifacts/`) MUST be performed in the host repo where that directory lives, on the current branch — do NOT create a new branch in the host repo.
+Branch creation, PR creation, and code commits MUST be performed inside the component directory (the submodule), NEVER in the host monorepo root. Planning artifact commits (`.engineering/artifacts/`) land on the current branch of the checkout that holds that directory — which checkout that is, and the primitive it takes, are resolved by [commit-and-persist](./workflow-engine/commit-and-persist.md). Do NOT create a new branch for them.
 
 ### orchestrator-automatic-transitions
 

meta/techniques/gitnexus-operations/TECHNIQUE.md

@@ -1,6 +1,6 @@
 ---
 metadata:
-  version: 3.2.0
+  version: 3.3.0
 ---
 
 ## Capability
@@ -11,15 +11,19 @@ Codebase intelligence via the GitNexus knowledge graph — indexing, structural
 
 ### query-not-grep
 
-Apply [query](./query.md) / [context](./context.md) for execution flows and relationships. Grep is for text patterns and string literals only — when structure matters, use GitNexus.
+Apply [query](./query.md) / [context](./context.md) for execution flows and relationships among code symbols — that is what the graph holds. For a markdown tree it holds paths and no prose, so a question about which text states a claim is a grep question, and [query](./query.md) answers it with unrelated matches rather than nothing, which means a miss there does not read as a miss. Grep is also for text patterns and string literals in code.
 
 ### detect-changes-after-edit
 
 Always apply [detect-changes](./detect-changes.md) after applying a rename or batch edits to verify only expected files were affected.
 
 ### index-freshness-first
 
-Apply [verify-index](./verify-index.md) at the start of any GitNexus session. Stale indexes return misleading results.
+Apply [verify-index](./verify-index.md) at the start of any GitNexus session, and again before any operation whose answer turns on the current tree — [impact](./impact.md), [detect-changes](./detect-changes.md), [orphan-scan](./orphan-scan.md), [diff-coverage-map](./diff-coverage-map.md). A stale index answers in the same shape as a fresh one and says nothing about its own age, so an unverified answer is indistinguishable from a correct one.
+
+### keyword-shaped-queries
+
+Phrase [query](./query.md) as keywords, not as a natural-language question. Its ranking fuses keyword and semantic scoring, and the semantic half contributes only where the index carries embeddings — which is a property of how the repo was indexed, not something the query can assert. Keyword-shaped input is the phrasing that works either way.
 
 ### must-use-operations
 

meta/techniques/workflow-engine/commit-and-persist.md

@@ -1,6 +1,6 @@
 ---
 metadata:
-  version: 1.7.0
+  version: 1.8.0
 ---
 
 ## Capability
@@ -28,14 +28,17 @@ Path to the planning folder.
 2. Set the header-line `**Status:**` to the current lifecycle milestone for that workflow (text — distinct from Progress Status; see [Progress table](../../resources/planning-readme.md#progress-table)).
 3. If the README already matches after steps 1–2, leave content equivalent — still include the file in the engineering commit below so a prior local-only edit is pushed.
 4. If `{host_repo_path}/{component_path}` has uncommitted changes (`git status --porcelain` non-empty), apply [version-control](../version-control/TECHNIQUE.md)::[commit-submodule](../version-control/commit-submodule.md)(*paths*=changed files, *submodule_message*=`'<type>(<workflow-id>): <activity-id> source changes'` with the Conventional Commits type that fits the activity — feat for implement, fix for post-impl-review fixes, refactor for cleanup, *parent_branch*=current parent branch). Skip when the working tree is clean.
-5. **Engineering commit + push:** Apply [version-control](../version-control/TECHNIQUE.md)::[commit-regular-files](../version-control/commit-regular-files.md)(*paths*=ALL changes under `.engineering/artifacts/` within `{planning_folder_path}`, including `README.md`, `session.json` and `.session-token`, *message*=`docs(<workflow-id>): <activity-id> artifacts`). This post-activity hook **is** the commit request — do not wait for a separate user confirmation. Push must succeed before this operation returns: Engineering links and resume assume the remote holds the commit, so a local-only README or artifact update does not satisfy this step.
+5. **Engineering commit + push:** Commit ALL changes under `.engineering/artifacts/` within `{planning_folder_path}`, including `README.md`, `session.json` and `.session-token`, with *message*=`docs(<workflow-id>): <activity-id> artifacts`. The primitive follows the layout, classified by `version-control.infrastructure-submodule-paths`. This post-activity hook **is** the commit request — do not wait for a separate user confirmation. Push must succeed before this operation returns: Engineering links and resume assume the remote holds the commit, so a local-only README or artifact update does not satisfy this step.  
+   > When `.engineering` is a checkout of its own, apply [commit-submodule](../version-control/commit-submodule.md)(*submodule_path*=`.engineering`) — its own branch and remote carry the artifacts.  
+   > Otherwise apply [commit-regular-files](../version-control/commit-regular-files.md) — the artifacts are ordinary files of the host checkout.  
+   > Where the host branch accepts changes only through pull requests, the parent's submodule-pointer bump lands in a PR; a direct push to that branch is refused, and the engineering push above already satisfies this step without it.
 6. Confirm the engineering push landed (remote tracking branch includes the new commit). If push failed, retry once; if still failing, surface the error and do not advance to the next activity.
 
 ## Rules
 
 ### commit-after-activity
 
-After every completed activity, BOTH source-side changes (under `{host_repo_path}/{component_path}`, via [commit-submodule](../version-control/commit-submodule.md)) AND engineering artifacts (under `.engineering/artifacts/`, via [commit-regular-files](../version-control/commit-regular-files.md)) MUST be committed and **pushed** before evaluating transitions to the next activity. Skipping either scope leaves a dirty or remote-stale tree that breaks resume, Engineering links, and downstream activities. The submodule commit may be skipped only when the working tree at `{host_repo_path}/{component_path}` is clean. The engineering commit may be skipped only when the planning folder has no local changes **and** README Progress Status for `{activity_id}` already shows the intended post-activity status on the remote (complete, or cancelled/N/A when `{mark_progress_na}` applied) per [Status vocabulary](../../resources/planning-readme.md#status-vocabulary) — otherwise Apply sync-progress-status (step 1) then commit and push. Scope: this orchestrator post-activity hook only — distinct from [explicit-commit](../version-control/TECHNIQUE.md#explicit-commit), which governs ad-hoc commits outside this hook.
+After every completed activity, BOTH source-side changes (under `{host_repo_path}/{component_path}`) AND engineering artifacts (under `.engineering/artifacts/`) MUST be committed and **pushed** before evaluating transitions to the next activity. Skipping either scope leaves a dirty or remote-stale tree that breaks resume, Engineering links, and downstream activities. The submodule commit may be skipped only when the working tree at `{host_repo_path}/{component_path}` is clean. The engineering commit may be skipped only when the planning folder has no local changes **and** README Progress Status for `{activity_id}` already shows the intended post-activity status on the remote (complete, or cancelled/N/A when `{mark_progress_na}` applied) per [Status vocabulary](../../resources/planning-readme.md#status-vocabulary) — otherwise Apply [sync-progress-status](./sync-progress-status.md) then commit and push. Scope: this orchestrator post-activity hook only — distinct from [explicit-commit](../version-control/TECHNIQUE.md#explicit-commit), which governs ad-hoc commits outside this hook.
 
 ### readme-progress-before-persist
 

meta/techniques/workflow-engine/generate-summary.md

@@ -1,6 +1,6 @@
 ---
 metadata:
-  version: 1.0.0
+  version: 1.2.0
 ---
 
 ## Capability
@@ -15,7 +15,7 @@ Workflow definition (id, title, outcomes)
 
 ### execution_trace
 
-Completed activities, checkpoint decisions, artifacts produced
+Completed activities, checkpoint decisions, and artifacts produced.
 
 ## Outputs
 
@@ -26,7 +26,6 @@ Completed activities, checkpoint decisions, artifacts produced
 ## Protocol
 
 1. Draw from `{execution_trace}` to compose the summary sections: workflow id and title, start/completion timestamps, activities completed, key checkpoint decisions, artifacts with paths, outcomes satisfied vs. unmet, follow-up items. Return the assembled markdown as `{completion_summary}`.
-   > Obtain the execution trace through the `inspect_session` tool — `view: activities` for completed activities, `view: checkpoints` for checkpoint decisions, `view: history` for the event trace, or `view: summary` for all of it — rather than reading `session.json` directly.
 
 ## Rules
 

meta/techniques/workflow-engine/read-session.md

@@ -0,0 +1,32 @@
+---
+metadata:
+  version: 1.0.0
+---
+
+## Capability
+
+The live session record — its variable bag and its execution trace — for a consumer that reasons over what the session has actually done.
+
+## Outputs
+
+### session_state
+
+The session's variable bag as the server holds it.
+
+### execution_trace
+
+Completed activities, checkpoint decisions, artifacts produced, and the event history behind them.
+
+## Protocol
+
+1. Read the session through the `inspect_session` tool: `view: variables` yields `{session_state}`; `view: activities`, `view: checkpoints` and `view: history` each yield a slice of `{execution_trace}`, and `view: summary` yields both products in one call.
+
+## Rules
+
+### session-file-is-not-a-source
+
+The session file on disk is the server's own store, not a read surface: it may be sealed, and it lags a call still in flight. Every consumer of the two products above takes them from this operation, so one contract governs what a session read returns.
+
+### trace-is-not-the-only-witness
+
+A worker's `activity_complete` envelope holds ground truth from its own user interaction, so where the record and a just-completed envelope disagree on a value an orchestrator decision rests on, apply [dispatch-activity](./dispatch-activity.md#distrust-then-reconcile).

meta/techniques/workflow-engine/verify-outcomes.md

@@ -1,6 +1,6 @@
 ---
 metadata:
-  version: 1.2.0
+  version: 1.4.0
 ---
 
 ## Capability
@@ -13,9 +13,13 @@ Compare a workflow's declared `outcomes` against state and identify gaps.
 
 Array of expected outcome strings to evaluate.
 
-### state
+### session_state
 
-Current variable state and completed-activities trace
+The session's variable bag.
+
+### execution_trace
+
+Completed activities and the event history behind them.
 
 ## Outputs
 
@@ -26,5 +30,4 @@ Array of unsatisfied outcomes
 ## Protocol
 
 1. Resolve the outcome list to evaluate: prefer a non-empty `{outcomes}` binding when supplied; otherwise fall back to the calling activity's declared `outcome:` list. Outcome strings are plain declarative prose — never encode or parse conditional predicates inside them. When a producing step was structurally gated out on the path taken, skip the outcomes that step would have satisfied rather than reporting them as unmet gaps.
-2. For each entry in that list, evaluate satisfaction against state variables, artifact presence in `planning_folder_path`, and the completed-activities trace; collect every unmet item into `{gaps}`.
-   > Read the state variables and completed-activities trace through the `inspect_session` tool (`view: variables` and `view: activities`, or `view: summary` for both) rather than reading `session.json` directly. When `inspect_session` disagrees with a just-completed worker envelope for a critical path, prefer the envelope and planning-folder evidence (same reconcile stance as [dispatch-activity](./dispatch-activity.md#distrust-then-reconcile)).
+2. For each entry in that list, evaluate satisfaction against `{session_state}`, artifact presence in `planning_folder_path`, and `{execution_trace}`; collect every unmet item into `{gaps}`.

meta/workflow.yaml

@@ -1,6 +1,6 @@
 $schema: ../../schemas/workflow.schema.json
 id: meta
-version: 5.12.0
+version: 5.14.0
 title: Meta Workflow
 description: Top-level lifecycle workflow that orchestrates client workflow sessions. Excluded from list_workflows — bootstrap navigates here directly.
 author: m2ux
@@ -53,13 +53,7 @@ variables:
     defaultValue: false
   - name: target_workflow_outcomes
     type: string
-    description: The client workflow's declared outcomes, read by verify-outcomes during end-workflow close-out
-  - name: client_state
-    type: string
-    description: The dispatched client workflow's final variable state, read by verify-outcomes during end-workflow
-  - name: client_trace
-    type: string
-    description: The dispatched client workflow's execution trace, read by generate-summary during end-workflow
+    description: The client workflow's own outcome list, seeded in its bag
   - name: workflow_match_ambiguous
     type: boolean
     description: Whether the user request matched multiple workflows — gates the workflow-selection checkpoint in discover-session

work-package/activities/13-submit-for-review.yaml

@@ -1,5 +1,5 @@
 id: submit-for-review
-version: 1.14.0
+version: 1.15.0
 name: Submit for Review
 description: Submit the work for review — PR review lifecycle normally; a verified private-remote push in stealth mode.
 required: true
@@ -18,8 +18,22 @@ steps:
       operator: ==
       value: true
   - kind: technique
-    id: publish-review-artifacts
-    technique: publish-review-artifacts
+    id: resolve-artifact-publish
+    technique: resolve-artifact-publish
+    condition:
+      type: simple
+      variable: is_review_mode
+      operator: ==
+      value: true
+  - kind: technique
+    id: commit-review-artifacts
+    technique:
+      name: manage-git::artifact-commits
+      inputs:
+        activity_name: submit-for-review
+        issue_key: issue_number
+        files: publishable_files
+        branch: artifact_publish_ref
     condition:
       type: simple
       variable: is_review_mode

work-package/activities/14-complete.yaml

@@ -1,5 +1,5 @@
 id: complete
-version: 1.7.0
+version: 1.9.0
 name: Complete Work Package
 description: Wrap up the work package after PR merge (or after review-mode close-out).
 required: true
@@ -66,6 +66,9 @@ steps:
       variable: is_review_mode
       operator: "!="
       value: true
+  - kind: technique
+    id: read-session
+    technique: workflow-engine::read-session
   - kind: technique
     id: conduct-retrospective
     technique: conduct-retrospective::retrospective
@@ -81,12 +84,23 @@ steps:
       - action: validate
         target: broken_artifact_links == []
         message: "Planning artifacts carry links that do not resolve: {broken_artifact_links}. Repoint each to a target that resolves at the publish ref, then re-run."
+  - kind: technique
+    id: resolve-close-out-publish
+    technique: resolve-artifact-publish
+    condition:
+      type: simple
+      variable: is_review_mode
+      operator: ==
+      value: true
   - kind: technique
     id: publish-close-out-artifacts
     technique:
-      name: publish-review-artifacts
+      name: manage-git::artifact-commits
       inputs:
-        publishing_activity: complete
+        activity_name: complete
+        issue_key: issue_number
+        files: publishable_files
+        branch: artifact_publish_ref
     condition:
       type: simple
       variable: is_review_mode

work-package/activities/README.md

@@ -366,11 +366,10 @@ Definition: [`13-submit-for-review.yaml`](./13-submit-for-review.yaml)
 ```mermaid
 graph TD
     entryNode(["Entry"]) --> reviewMode{"Review mode?"}
-    reviewMode -->|"yes"| consolidate["Consolidate review findings"]
-    consolidate --> genSummary["Generate review summary"]
-    genSummary --> cpSummaryApproval{"review-summary-approval checkpoint"}
-    cpSummaryApproval --> postReview["Post PR review"]
-    postReview --> awaitReview
+    reviewMode -->|"yes"| consolidate["Consolidate review findings → resolve publish ref → commit artifacts → generate review summary"]
+    consolidate --> cpSummaryApproval{"review-summary-approval checkpoint"}
+    cpSummaryApproval --> persistSummary["Persist review summary → post PR review"]
+    persistSummary --> awaitReview
 
     reviewMode -->|"no"| cpDco{"dco-sign-off-confirmation checkpoint"}
     cpDco --> stealthMode{"Stealth mode?"}
@@ -431,7 +430,7 @@ graph TD
     docsGate -->|"yes"| retrospective["Conduct the retrospective into COMPLETE.md, then verify planning-folder links"]
 
     retrospective --> publishGate{"Review mode?"}
-    publishGate -->|"yes"| republish["Publish close-out artifacts on the publish branch"]
+    publishGate -->|"yes"| republish["Resolve the publish ref, then commit the close-out artifacts onto it"]
     publishGate -->|"no"| removeWorktree
     republish --> removeWorktree["Remove component worktree (when this run created one)"]
     removeWorktree --> selectNext["Select next work package"]