Skip to content

7579f894.md

Latest commit

 

History

History
349 lines (234 loc) · 30.8 KB

7579f894.md

File metadata and controls

349 lines (234 loc) · 30.8 KB
Raw
uid 7579f894
type playbook
title Dispatch Walker — First-Use Walk Test-Harness
description Operational protocol for dispatching sa.first-use-walker against a release ship-zip. Stage 3.1 of release-test-plan v2 (3-stage gauntlet). Sub-playbook of run-release-test-plan.
version 0.3.1
status active
locked_by argus-a45
locked_at 2026-05-05
locked_by_v0_3 vela-v37
locked_at_v0_3 2026-05-01
owner vela
readers
agent
human
scope single-session
trigger release-stage-3-walker-dispatch
domain test-harness
estimated_duration 30-90 min wall-clock end-to-end (dispatcher prep + walker walk + verdict triage)
target_artifact_type release
verdict_format PASS / PARTIAL / FAIL
tags
test-harness
walker
release-gate
kernel-tier
v1.4.2
doctrine-grounded
governed_by e7b3c509
composes_into
playbook role
run-release-test-plan
stage-3-1-walker-dispatch
relationships
kind target
implements
fb925dea
kind target
dispatches
6742f183
kind target
composes-into
4c8f6d2a
kind target
governed-by
b19e8d43
kind description
grounded-in
The Patient Honing Doctrine — institutionalizes walker dispatch as kernel primitive. v1.4.1 cycle proved the discipline; v1.4.2 ships it as substrate (not session memory).
created 2026-04-30
created_by vela-v37
modified 2026-05-01
modified_by vela-v37
schema_version 2
extraction_scope ship
member_of
8e4a2c1f
76bab75f

Dispatch Walker — First-Use Walk Test-Harness

Sprint 2 first-instance test-harness playbook. Codifies the walker dispatch protocol previously held in V36/V35 session memory. Per The Patient Honing Doctrine: the workshop IS the system; the system compensates for forgetting. Walker dispatch is workshop primitive from v1.4.2 forward.

Intent

Dispatch sa.first-use-walker (6742f183) against a release ship-zip during Stage 3.1 of release-test-plan v2. The walker's job is to verify that a stranger encounters shipped capabilities (NOT artifact correctness — that's cold-boot's lane); this playbook codifies how the dispatcher (Mike or Metis) prepares the [PENDING] request, spawns the walker session with proper fixture isolation, and triages the verdict.

Why this is kernel primitive (not crew operational doc). The v1.4.0 → v1.4.1 cycle proved walker dispatch works. It also proved the dispatch logic lives in V36's session memory rather than substrate; a fresh dispatcher would have to reconstruct the protocol from records. This playbook makes the protocol discoverable + executable by anyone with allowlist authority (Mike, Metis-<gen>). Per release.capsule v3.1 Rule 10, walker is now a required pre-ship gate; the gate needs a kernel-tier protocol, not tribal knowledge.

Transitional invocation mode (until Sprint 4). Until run-release-test-plan.playbook (Sprint 4 task 4c8f6d2a) lands, this playbook is invoked directly by the dispatcher as Stage 3.1 of the manual gauntlet. Direct invocation is a transitional valid mode; once the orchestrator exists, direct invocation becomes a code-smell (orchestrator-bypass) auditable by the absence of a parent run-release-test-plan record.

Scope clarification (v0.3.1, v1.7 Stream C1)

This playbook governs sa.first-use-walker dispatch ONLY. The walker's independence requirement (spawn_blocklist: [vela, argus] per fb925dea) is specific to the walker — it exists because the walker's job is to verify stranger-encounter, and Vela / Argus are insiders who cannot perform that role.

Other sa.* dispatch mechanisms are out of scope. Specifically:

  • sa.cold-boot dispatch uses dispatch-cold-boot.playbook v0.2 — Stage 3.2/3.3 of the gauntlet; different allowlist/blocklist (cold-boot allows any executive per Rule 9 of that playbook).
  • General-purpose sa.* dispatch from pipeline steps uses dispatch-sa-step.skill (1a308e85) — NEW v1.7 Stream A6; no walker-style independence blocklist; executor-orchestrated multi-instance dispatch for agents like sa.hub-groomer (NEW v1.7).

The walker's blocklist does NOT propagate. A primary executor (e.g., Argus or Vela) dispatching sa.hub-groomer via dispatch-sa-step.skill is operating in a different governance regime; the walker's independence rules don't apply. This clarification closes the v1.6 process-gap finding (Walker BLOCKED) by being explicit that the blocklist is walker-specific, not vault-wide.

v1.6 process-gap closure note. During v1.6 ship, sa.first-use-walker dispatch returned BLOCKED because argus-a44 attempted to dispatch despite the blocklist. The correct hand-off path (Mike or Metis dispatches per Rule 1 below) was honored; the gauntlet stage was skipped at v1.6 with verification resting on the remaining 4 instruments + Mike B4. v1.7's hand-off discipline + dispatch-sa-step.skill introduction establishes the broader pattern: each sa.* dispatch mechanism has its own allowlist; agents check the right mechanism for the right agent.

Rules

  1. Dispatcher MUST be on the walker's allowlist. Allowed: mike (founder authority, implicit) or metis-<gen> (per spawnable_by: [metis] in walker frontmatter). Walker REFUSES dispatch from vela-<gen> or argus-<gen> per spawn_blocklist: (independence violation per fb925dea). If denylisted executive needs the walk, hand off.
  2. The user story MUST be verbatim from release plan §0 at dispatch time. Paraphrase causes walker BLOCK.
  3. Pre-walk fixture confirmation (SHA-256 + file count + spawn cwd realpath) MUST be obtained against the build entry's recorded values before authoring [PENDING]. Walker's domain is encounter, not fixture integrity.
  4. Walker session cwd MUST be the resolved-real-path of the extracted ship-zip, not the dev repo, not a symlink-into-dev-repo. Dispatcher computes realpath of the spawn cwd; walker refuses if realpath(cwd) resolves under the dev-repo prefix. Structural check, not heuristic — symlinked dev-repo can defeat heuristic checks (CLAUDE.md auto-load through symlinks is harness-version-dependent).
  5. Walker verdict IS the test result. Re-walking after artifact-under-test failure is BLOCKED — record the verdict and proceed to remediation. Re-walking is for fresh attempts after surfacing-layer fixes, not for "let me try again."
  6. PASS clears Stage 3.1; PARTIAL or FAIL blocks ship until surfacing-layer remediation + regression dispatch (fresh walker, fresh NNN). Both PARTIAL and FAIL block ship per walker v0.2 §Ship-blocking semantics.
  7. Verdict transcription to release entry MUST be literal string-copy. Per Step 9: the verdict: field appended to release entry's verification_artifacts: array is a literal copy of the walker [DONE] block's verdict line — no re-interpretation, no "the gaps are minor so PASS" reclassification. Mismatch is a Gate 5 audit violation.
  8. Dispatcher MUST author the [PENDING] block themselves. Copy-pasting another agent's draft (especially from a denylisted author — Vela / Argus) is a Gate 5 independence violation auditable post-hoc by record-time inspection. The walker's allowlist check is nominal (whose handle is in the field), not substantive (whether they ghostwrote it). Authorship is the dispatcher's audit obligation; this rule names the obligation. Per walker capsule v0.2: "Adding the dispatcher's own-voice attestation in the independence verification line raises the cost of proxy attacks but does not eliminate them."

Steps

Step 1. Confirm fixture integrity + resolve spawn cwd

Owner: dispatcher. Deadline: before authoring [PENDING].

Three values to compute + match:

# Compute SHA-256 of the ship-zip
shasum -a 256 <path-to-ship-zip>            # macOS / Linux
# OR: openssl dgst -sha256 <path-to-ship-zip>

# Count files in the extracted target (excluding macOS metadata)
find <extracted-path> -type f \! -name '.DS_Store' | wc -l

# Resolve real path of the spawn cwd (REQUIRED — symlink defense per Rule 4)
realpath <extracted-path>

Where to find the build entry's canonical values. The build entry is a separate ledger object from the release entry (do not conflate). The build entry lives at vault/files/<build-uid>.md and is type build. Its frontmatter declares the canonical fields:

  • verification.ship_zip_sha: — the ship-zip's SHA-256 hash (canonical)
  • verification.file_count: — file count in the extracted target (canonical)
  • extracted_path: (or per-build path field) — where the build was extracted

Match your local SHA + file count against the build entry's recorded values. If mismatch, HALT and surface to the release-engineer (Vela or whoever ran build-release.py). Do NOT proceed with stale or corrupted fixture.

If you cannot identify the build entry UID for the release under test, HALT — do not paper over with raw values alone. The build-entry UID is the audit anchor.

If realpath resolves under the dev-repo prefix (e.g., /Users/<user>/dev/tropo-ai/... rather than /tmp/... or ~/test-extracts/...), HALT — the spawn cwd is not actually the extracted ship-zip. Re-extract to a clean path outside the dev repo.

Step 2. Lift user story from release plan §0

Owner: dispatcher. Deadline: same minute as Step 1.

Open the cycle's release plan vault entry. Locate §0 user story. Copy the exact text — DO NOT paraphrase, summarize, or "tighten." The walker's dispatcher-validation v0.2 rules require verbatim correspondence to the release plan.

If the release plan has no §0 user story, HALT and surface to the release author. A walker dispatch without an authoritative user story has no anchor for the verdict.

Step 3. Verify dispatcher allowlist

Owner: dispatcher. Deadline: same minute as Step 2.

Confirm the dispatcher short-handle is mike (founder, implicit) or metis-<gen> (e.g., metis-g48). If the dispatcher is Vela (vela-<gen>), Argus (argus-<gen>), Cosmo (cosmo-<gen>), Orpheus (orpheus-<gen>), or any role currently in walker's spawn_blocklist:, HALT and hand off to an allowed dispatcher per the lane discipline lock at Cycle Kickoff Brief (e5bcd9a2).

Joint dispatchers (Mike + Vela, Metis + Argus) are also BLOCKED per walker v0.2 §Dispatcher validation rule 5 — the denylisted party contaminates independence.

Step 4. Determine next NNN

Owner: dispatcher.

List agents/sa/sa.first-use-walker/activation-log/. Find the highest existing 3-digit prefix. Increment by 1. The dispatcher numbers the record; the walker does NOT (race-condition prevention per walker v0.2 §Activation-Log Convention).

Filename collision recovery (rare). If you create the file and find another dispatcher already used the same NNN (concurrent dispatchers + filesystem race), ls the directory before write — second author renames their file to <NNN+1>-... and amends their [PENDING] filename reference; both records persist as audit trail.

Step 5. Author [PENDING] entry

Owner: dispatcher. Authored personally per Rule 8 — dispatcher writes the block themselves; no copy-paste from another agent's draft.

Create agents/sa/sa.first-use-walker/activation-log/<NNN>-<dispatcher>-<release>.md with these required fields (per walker v0.2 §How Walks Are Requested + Rule 4):

[PENDING] First-Use Walk: <release version> against extracted zip at <path>

User story (from release plan §0):
  "<exact user-story text — verbatim, no paraphrase>"

Time bound: <e.g., "30-60 min" or "no time bound; completion-criterion-based">

Dispatcher: <short-handle>   # e.g., mike, metis-g48 — NOT full name with spaces

Independence verification: <one line in dispatcher's own voice attesting non-collaboration with release-stream authors on the walk request>

Pre-walk fixture confirmation: SHA <hex>; <N> files in extracted target (matches build entry [<build-uid>])

Resolved spawn cwd realpath: <output of `realpath <extracted-path>`>

Peer cold-boot record UID: <activation-log/<NNN>-<dispatcher>-<release>.md path of sibling cold-boot record, if running as part of release-test-plan v2 Stage 3 gauntlet; OMIT if walker dispatched standalone>

All 7 fields required when running as part of the Stage 3 gauntlet (the Peer cold-boot record UID is required for convergence-by-disagreement citation per §Report Format). If walker dispatched standalone (no sibling cold-boot), the Peer cold-boot record UID field MAY be omitted; walker will not produce a convergence note.

Independence verification — examples:

  • ✅ Valid (substantive, first-person): "I authored this [PENDING] independently and have not discussed v1.4.2-rc1 ship-readiness with Vela or Argus."
  • ❌ Invalid (insufficiently specific): "Independence confirmed."
  • ❌ Invalid (third-person): "Dispatcher attests independence."

Filename rules:

  • <NNN> — 3-digit zero-padded sequential, dispatcher-assigned in Step 4
  • <dispatcher> — normalized short-handle (NOT full name with spaces, NOT full role title)
  • <release> — release version frozen at dispatch time. Canonical pattern: matches the release entry's version: frontmatter field verbatim (e.g., v1.4.2-rc1, v1.4.0-final). If release is renamed mid-cycle, filename keeps the original.

Activation-log records ARE extraction_scope: argo-private by classification — they don't ship — but the dispatcher does not need to add frontmatter; the activation-log directory's CAPSULE/AGENTS.md governs.

Step 6. Spawn walker session

Owner: dispatcher.

Canonical harness: Claude Code. Spawn via the Agent tool with subagent_type: general-purpose, prompt = the MODE A or MODE B walker-spawn template per agents/sa/commission-quickref.md. Walker is MODE A by default (live channel — walker writes [QUERY], dispatcher writes [RESPONSE], walker walks, writes [DONE]).

The cwd-control discipline is load-bearing. In Claude Code's Agent tool, the spawned sub-agent inherits the parent's working directory by default. To force the walker into the extracted ship-zip's resolved real path:

# Before spawning — change parent session cwd:
cd <realpath-of-extracted-ship-zip>

# Then spawn the walker via Agent tool. Sub-agent inherits cwd.

OR pass the resolved real path explicitly in the spawn prompt and instruct the walker to verify it before booting.

Other harnesses (Codex, Gemini CLI, etc.): best-effort equivalents. The dispatcher's responsibility is fresh-session + cwd-isolation + no-parent-context-bleed. If the harness cannot honor cwd isolation, file an issue and use Claude Code for this dispatch.

The walker's v0.2 boot sequence checks for harness contamination (vault CLAUDE.md auto-load, project-root context, pre-loaded vault context) AND will additionally refuse if realpath(cwd) resolves under the dev-repo prefix. If [BLOCKED] for contamination, fix the spawn (fresh session, correct cwd) and retry with a fresh NNN — meaning NNN+1, the next sequential number after the blocked record's NNN. The blocked record is permanent audit trail; do not edit, overwrite, or reuse its NNN.

Step 7. Wait for [QUERY] then [IN-PROGRESS] then [DONE]

Owner: dispatcher.

The walker writes [QUERY] Boot complete — stranger and ready. Where is the zip, and what's the user story I'm walking against? Append [RESPONSE] to the activation-log record file confirming the path and user story (already in [PENDING]; this is the live-channel acknowledgment).

The walker then writes [IN-PROGRESS] (begins the walk) and eventually [DONE] using the 7-section output format (USER STORY / WALK NARRATIVE / UNPROMPTED ENCOUNTERS / EXPECTED-BUT-MISSING / CEREMONY-LOAD / VERDICT / RECOMMENDATIONS).

If walker writes [BLOCKED] instead of [IN-PROGRESS], dispatch validation failed — read the failure reason, remediate the [PENDING], dispatch with a fresh NNN (NNN+1, not the blocked NNN). The blocked record stays for audit.

If walker times out without [DONE], this is walker-runtime failure (rare; see walker v0.2 §Mid-walk discipline). Surface to release-engineer; a new walker session may be spawned to retry.

Step 8. Triage the verdict

Owner: dispatcher.

Per walker v0.2 §Verdict criteria + §Ship-blocking semantics:

  • PASS → Stage 3.1 clears. Proceed to Step 9.
  • PARTIAL → ship blocked. Surfacing-layer remediation required (concierge re-routing, CAPSULE bench signage, welcome flow, KB discoverability — never the artifacts themselves). After remediation: regression cold-boot pre-walker (dispatch-cold-boot.playbook), THEN fresh walker dispatch (new NNN, new session). DO NOT re-walk in the same session.
  • FAIL → ship blocked. Same remediation discipline as PARTIAL.

The verdict is final per the walker capsule. Don't argue it; remediate or escalate.

Recommendation triage discipline. Before opening remediation tasks from the walker's RECOMMENDATIONS, the dispatcher MUST classify each recommendation as surfacing-layer or artifact-layer. Walker capsule v0.2 declares RECOMMENDATIONS surfacing-layer-only — but the boundary is fuzzy when the artifact IS the surface (e.g., vault/files/e98420c3.md is both an artifact under test AND the surface). Artifact-layer recommendations redirect to cold-boot lane or architect review; only surfacing-layer recommendations open as walker-cycle remediation tasks.

Step 9. Append to release entry's verification_artifacts:

Owner: dispatcher (or release-engineer if dispatcher lacks write access to the release entry).

Per release.capsule v3.1 Rule 10, the release entry's verification_artifacts: array MUST cite this walker record. Append using the canonical shape declared in release.capsule v3.1 §Rule 10:

verification_artifacts:
  - type: walker
    record_uid: <activation-log-record-uid>
    verdict: <literal string-copy from walker [DONE] block — PASS / PARTIAL / FAIL>
    dispatcher: <short-handle>
    dispatched_at: <iso8601-date>

Per Rule 7 (literal string-copy): the verdict: field is a literal copy of the walker [DONE] block's verdict line — no re-interpretation. If walker reports PARTIAL, the array entry says verdict: PARTIAL; if walker reports FAIL, verdict: FAIL. The dispatcher does not classify or re-rank; the walker's verdict is the verdict. Mismatch (e.g., walker [DONE]: PARTIAL but release entry verdict: PASS) is a Gate 5 audit violation.

If verdict was PARTIAL/FAIL, do NOT append — the release is not ship-eligible. The activation-log record stays as audit trail; the release entry's verification_artifacts: accumulates only PASS verdicts.

Outcomes

The dispatch-walker.playbook is COMPLETE when:

  • [REQUIRED] A walker [DONE] (or [BLOCKED]) record exists at agents/sa/sa.first-use-walker/activation-log/<NNN>-<dispatcher>-<release>.md
  • [REQUIRED] A verdict (PASS / PARTIAL / FAIL) is recorded in the [DONE] block
  • [REQUIRED-IF-PASS] If PASS: the verdict is appended to the release entry's verification_artifacts: array (literal string-copy per Rule 7); Stage 3.1 of release-test-plan is closed
  • [REQUIRED-IF-PARTIAL-OR-FAIL] If PARTIAL or FAIL: surfacing-layer remediation work is opened (typically a task entry in the release-cycle's project); ship is blocked until regression dispatch yields PASS

The playbook is NOT complete on [BLOCKED] — a blocked dispatch is a dispatcher-side defect, not a verdict. Remediate and re-dispatch with fresh NNN (NNN+1).

Verification

Self-attestation. The dispatcher executing this playbook self-reports completion via the activation-log record (which IS the audit trail). No separate harness verifies the dispatcher; the walker's record + the verdict + the verification_artifacts entry together constitute the evidence chain.

The TARGET-side verification of the release zip is the walker's job (declared in §Report Format below); the dispatcher's verification of the dispatch protocol is the activation-log record's existence + completeness.

Report Format

This section satisfies the test-harness subtype's Additional Required Body Section (per playbook.capsule v2.4 §Subtypes §Test-Harness).

Verdict line. One of: PASS / PARTIAL / FAIL. Tri-valued; middle bucket (PARTIAL) operationally meaningful with explicit trigger conditions:

  • PASS — All four walker capsule v0.2 §Verdict criteria conditions met: ≥3 distinct unprompted encounters, ≥3 tagged [STRONG], encounters product-surface-delivered, user-story goal achieved or near-achieved.
  • PARTIAL — Use this bucket when the walker encounters ≥1 surfacing-layer gap that blocks user-story completion BUT does not indicate artifact-layer absence. Specific triggers: 1-2 unprompted encounters / ≥2 of ≥3 encounters tagged [WEAK] / user-story near-achieved with significant gaps / ceremony-load 4-5 with goal achieved. PARTIAL signals "the artifact is correct but the stranger doesn't reach it through the surface."
  • FAIL — Use this bucket when the walker encounters absence of an expected capability via the product surface. Specific triggers: 0 unprompted encounters / walker explicitly reports "no idea what resources existed around me" / user-story goal could not be reached / EXPECTED-BUT-MISSING shows walker reached for clearly-shipped capability and didn't find it. FAIL signals "absence" — the artifact may exist but the surface didn't deliver it.

The walker writes the verdict directly in its [DONE] block per walker v0.2 §Output Format. Replicated to release entry's verification_artifacts: array per Step 9 with literal string-copy discipline (Rule 7).

Evidence section. Walker [DONE] contains: USER STORY (verbatim) / WALK NARRATIVE / UNPROMPTED ENCOUNTERS ([STRONG] / [WEAK] tagged) / EXPECTED-BUT-MISSING / CEREMONY-LOAD (1-5) / RECOMMENDATIONS.

Findings table. Walker's RECOMMENDATIONS list IS the structured findings table for this harness. The capsule's "P0/P1/P2 or equivalent severity convention" rule is satisfied as follows:

  • [STRONG] UNPROMPTED ENCOUNTERS map to no-finding (capability surfaced)
  • [WEAK] UNPROMPTED ENCOUNTERS or EXPECTED-BUT-MISSING entries map to P0 (ship-blocker if verdict PARTIAL/FAIL) or P1/P2 (dispatcher post-triage classification per cycle context)
  • The [STRONG] / [WEAK] tagging is the equivalent severity convention; explicit P0/P1/P2 classification is the dispatcher's responsibility when triaging in Step 8

Convergence note. Walker is Stage 3.1; cold-boot is Stage 3.2 (dispatched via dispatch-cold-boot.playbook — Sprint 3 sibling sub-playbook). When both run as part of release-test-plan v2's Stage 3 gauntlet, the walker record MUST cite the peer cold-boot record UID in its WALK NARRATIVE or RECOMMENDATIONS section. The citation slot is delivered to the walker via Step 5's Peer cold-boot record UID: field in [PENDING] — the walker echoes this UID into its [DONE] block. Convergence-by-disagreement (walker PASS + cold-boot FAIL, or vice versa) signals a real divergence between encounter and correctness — both verdicts stand; investigate, do not collapse. Per release-test-plan v2 (f4a8c2d6): both Stage 3.1 + Stage 3.2 PASS or PASS-WITH-FINDINGS required for atomic-triangle commit eligibility per release.capsule v3.1 Rule 10.

Resources

Knowledge Base

Distinguishing Build Entry from Release Entry

Two distinct ledger objects, both relevant:

  • Build entry (type: build): per-build artifact recording the ship-zip's SHA, file count, extracted path, version stamps. Created by build-release.py per build.capsule v1.1 (b3d7e5a1). Dispatcher reads this in Step 1 to anchor fixture confirmation.
  • Release entry (type: release): per-release artifact aggregating verification artifacts (walker + cold-boot verdicts), composing build entry, declaring shipped state. Dispatcher writes to this in Step 9 (verification_artifacts: append).

A release composes a build (composes_into:); a build is referenced by a release (derived_from:). The atomic-triangle pattern (release entry + build entry + release-plan) is declared in release.capsule v3.1 (b19e8d43) Rule 3.

Sub-Playbooks

This playbook is a sub-playbook of run-release-test-plan.playbook (Sprint 4; not yet authored — see §Intent Transitional Mode). It does NOT call sub-playbooks — the walker session is a dispatched session-agent, declared in relationships: kind: dispatches (canonical agent-dispatch shape per playbook.capsule v2.5 candidate amendment; v0.2 retrofits when capsule lands).

Templates

The [PENDING] block shape in Step 5 IS the dispatcher template. No separate template file needed; copy from this playbook into the activation-log record at dispatch time.

Exemplar Records

Past walker [DONE] records (read-only references for shape):

These are pre-v0.1-playbook records; they precede the structured [PENDING] shape declared in Step 5. Use them for the [DONE] output shape, not the [PENDING] template.

Known Enforcement Gaps

Gap Severity Tracking Land at
composes_into: run-release-test-plan is forward reference; orchestrator playbook not yet authored stub-warn at v2.4 (per playbook.capsule §Subtypes §Test-Harness composition rule) Sprint 4 task 4c8f6d2a v1.4.2 Sprint 4 close (orchestrator authored + calls: lists this playbook)
dispatches: typed frontmatter field not yet canonicalized in playbook.capsule §Subtypes §Test-Harness open [QUERY] for Argus per sa.arch-specs 025 F5 playbook.capsule v2.5+ amendment when Argus signs amendment direction (typed dispatches: field OR codify relationships: kind: dispatches as canonical)
Max-attempts ceiling on PARTIAL → remediation → walker → PARTIAL loop not declared P1 from sa.skeptic 025 F3 likely belongs in run-release-test-plan.playbook (Sprint 4) — defer-by-naming, not by silence Sprint 4 close OR v0.3 amendment if scope shifts
§Escalation Heuristics section (when does PARTIAL escalate to architect-level redesign? HALT-on-unavailable-release-engineer protocol? escalation channel for verdict disputes?) P1 from sa.skeptic 025 F5 Round 2 polish; substrate-vs-session-memory boundary v0.3 amendment OR Sprint 4 close (whichever lands first)
Walker time-bound enforcement (max-time abort if walker silently exceeds bound) P2 here; P1 against walker capsule v0.2 (out-of-scope for this playbook) upstream walker capsule amendment walker capsule v0.3 (Argus-domain)

Changelog

Version Date Change Author
0.1 2026-04-30 Initial draft per Sprint 2 of v1.4.2 cycle. Codifies walker dispatch protocol previously held in V36/V35 session memory. Authored against playbook.capsule v2.4 test-harness subtype. vela-v37
0.3 2026-05-01 Stream 1 cross-sprint sweep close — descriptor drift fixed ("release-test-plan v1" → "release-test-plan v2"; UID resolution preserved); §Outcomes [REQUIRED] / [REQUIRED-IF-X] tags added per playbook.capsule v2.4 §3 §Outcomes worked example (closes arch-specs 025 sibling-cut finding); §Known Enforcement Gaps row 1 (composes_into forward reference to run-release-test-plan) RESOLVED — orchestrator (af8fc98a) v0.2 locked 2026-05-01 with reciprocal calls: declaration; Check 21 bidirectional consistency loop closes cleanly. vela-v37
0.2 2026-05-01 Round 1 BATCH remediation — folds 2 P0 + 7 P1 from three-instrument convergence (sa.cold-boot 102 + sa.arch-specs 025 + sa.skeptic 025). P0-1 (cold-boot F1): added Peer cold-boot record UID: field to Step 5 [PENDING] template + walker convergence-citation slot. P0-2 (skeptic F1): added Rule 4 realpath cwd discipline + Step 1 realpath computation + Step 6 walker-side enforcement note. P1 fixes: removed calls: line (arch-specs F5 — agent-dispatch via relationships: kind: dispatches instead); added explicit PARTIAL/FAIL trigger conditions in §Report Format (arch-specs F1); added Step 1 SHA snippet + named build-entry frontmatter keys (cold-boot F2); named Claude Code Agent tool with cwd handling in Step 6 (cold-boot F3); added §Resources distinction between build entry and release entry (cold-boot F5); added Rule 8 anti-proxy authoring obligation (skeptic F2); added Rule 7 + Step 9 verdict literal-copy discipline (skeptic F4). Added §Known Enforcement Gaps + §Intent transitional invocation mode + exemplar records + independence verification examples + filename collision recovery + recommendation triage discipline. Round 2 (post-active polish): max-attempts ceiling (skeptic F3 — likely Sprint 4), §Escalation Heuristics (skeptic F5), remaining P2/P3. vela-v37

dispatch-walker.playbook | v0.3 active (cross-sprint sweep close 2026-05-01) | Vela V37 | 2026-05-01 "The walker walks; the dispatcher prepares. Both must be substrate, not memory."