acstack 0.52.0 → 0.52.2

package/cli/package.json

@@ -1,6 +1,6 @@
 {
   "name": "acstack-cli",
-  "version": "0.52.0",
+  "version": "0.52.2",
   "description": "CLI for the ACStack agentic coding stack",
   "type": "module",
   "license": "MIT",

package/docs/workflows.md

@@ -179,7 +179,12 @@ flowchart LR
 - Practical tests-first work remains preferred
 - Another agent adds independent interpretation or review when useful or required by the shared policy
 - Choosing separate test ownership prevents the implementer from weakening those tests
-- Formatting and project-required completion checks still apply
+- One verification owner gathers formatting and project-required completion evidence for the final revision
+    - Use focused checks during implementation and reuse valid results across agents, nodes, and commits
+    - Rerun affected checks when relevant code, inputs, or environment change, or validity is uncertain
+- Review depth follows plausible failures in affected security, resource lifecycle, concurrency, and performance paths
+- Adjacent cleanup stays advisory unless the user approves it; approved independent work can run in parallel without blocking delivery
+- Deep modules hide complexity: callers need fewer facts, and each rule has one owner
 - Frontend design checks run under `skills/implement/design-pass.md`, even without a delegated checker
 - Configured real-browser verification runs on the final code after required gates pass
 - Report commands, results, and blocked checks rather than phase narration

package/orchestrator/AGENTS.md

@@ -189,6 +189,11 @@ flowchart TD
     - Never declare consequential behavior safe without evidence
 - Derive assertions from requirements and observable behavior, not the implementation's current answers
 - Test counts and mocked assertions alone never prove adequate coverage
+- Tie review depth to plausible failures in the changed behavior and connected paths
+    - Inspect authentication, authorization, trust boundaries, and sensitive data handling when affected
+    - Inspect resource ownership and cleanup for leaks, cancellation, and concurrency when affected
+    - Check expensive paths for query amplification, blocking work, and unbounded memory or runtime; measure when performance claims matter
+    - Expand scope when evidence reveals wider risk, not merely because another file is nearby
 
 ### Investigate, test, and implement
 
@@ -202,6 +207,9 @@ flowchart TD
     - Investigate source, interfaces, living specs, and existing tests for an answer
     - Prefer narrower behavior and assertions that still detect unmet requirements
     - Report any blocked requirement and the question that settles it
+- Prefer deep modules: hide substantial complexity behind small, useful interfaces
+    - Ask whether callers need fewer facts, each rule has one owner, and the interface hides complexity rather than moving it
+    - Keep names and control flow readable; more helpers, shorter functions, and fewer lines are not goals by themselves
 - Read `test-conventions` before writing tests
 - Before the first edit under configured `frontend.directory`, read the pre-edit procedure in `skills/implement/design-pass.md`
     - Check the design gate and load design context once per task when it is on
@@ -219,7 +227,14 @@ flowchart TD
     - Route incorrect or incomplete tests back to their owner
 - Without separate ownership, the implementer may write source and tests
 - A task-checker is an optional independent verifier, not a required step after every executor
+- Give each reviewer a bounded question, affected paths, requirements, known risks, and available check evidence
+    - A focused reviewer checks that question; it does not inherit ownership of every completion gate
+    - Expand the review when findings reveal wider risk, and report the reason
 - Assign non-overlapping files when delegating concurrent work
+- Adjacent cleanup is advisory by default, not a delivery gate or an automatic source edit
+    - Report worthwhile cleanup separately; ask the user before adding it to scope
+    - Approved cleanup may run in parallel on non-overlapping files or isolated worktrees, without blocking the main change
+    - A defect that prevents the requested behavior or exposes a consequential risk is not merely cleanup; fix it within scope or report the blocker
 
 ### Complete required gates
 
@@ -229,7 +244,8 @@ flowchart TD
 - Audit whether checks detect realistic mistakes, including circular mock assertions and missing integration
 - Respect separate test ownership when reviewing changes
 - For changed frontend files, the verification owner runs configured frontend build, lint, and tests
-- The verification owner is the session responsible for completion, or a delegated verifier with that responsibility
+- Choose one verification owner: the session responsible for completion, or a delegated verifier explicitly assigned that responsibility
+- Reuse valid command evidence under Build verification; do not make every agent repeat completion checks
 - When the design gate is on and configured frontend files changed, complete the design pass in `skills/implement/design-pass.md`
     - File discovery, static checks, and the detector may belong to a delegated verifier
     - The parent session types audit and polish; a read-only checker returns its file list and findings without editing
@@ -312,29 +328,34 @@ Read-only reviewers report discrepancies to the completion owner.
 
 ## Build verification (mandatory)
 
-**Before marking ANY task as complete, you MUST verify the project builds.**
+The verification owner gathers passing completion evidence for the final revision before declaring the request or parent effort complete or creating a PR.
 
-Read `.acstack/project.yaml` for the specific commands. The general pattern:
+Read `.acstack/project.yaml` for the specific commands:
 
-1. Run the build command if the project configures one
-2. Run lint
-3. Run typecheck if the project configures one
-4. Run the full test suite – ALL tests must pass
-5. Compare the test count against `.acstack/.test-baseline`. The count must not drop.
-6. Run the frontend build and lint if the project configures a frontend
+1. Run the configured build, lint, and typecheck commands
+2. Run the configured full test suite; all tests must pass
+3. When `commands.test_collect` is configured, compare the count against `.acstack/.test-baseline` if present; investigate removed coverage and honor project baseline requirements
+4. Run configured frontend build, lint, and tests when frontend files changed
+5. Complete configured design and browser gates when applicable
 
-### When to run
+### During implementation
 
-- **After EVERY commit** that touches source code
-- **Before marking parent task as done**
-- **Before creating a PR**
+Use focused checks for each change, fix, or map node. Resolve a node only when its behavior and applicable risk review are verified; do not claim the whole effort is verified until completion gates pass.
+Do not rerun all completion commands after every node, review finding, agent handoff, or commit solely because that event occurred.
+Project-specific and explicit user requirements for additional checks still apply.
+
+### Reuse evidence without hiding stale results
+
+- Record each command, working directory, tested revision (including uncommitted changes), relevant environment, and result
+- Share result or log references with reviewers and receiving agents
+- Reuse a result only when its relevant source, tests, configuration, dependencies, generated inputs, and environment are unchanged
+- Rerun affected checks after changes; rerun when validity is uncertain or the check depends on external state that may have changed
+- A commit alone does not invalidate evidence; hook edits or generated changes can
+- Independent review still examines the assigned behavior and test adequacy; a passing command is not a substitute
 
 ### If verification fails
 
-1. **DO NOT mark task complete**
-2. Fix the error immediately
-3. Re-run verification
-4. Only proceed when all checks pass
+Do not claim completion with failed or blocked required checks. Investigate, fix, and rerun affected checks. Report unresolved failures and remaining risk.
 
 ---
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "acstack",
-  "version": "0.52.0",
+  "version": "0.52.2",
   "private": false,
   "description": "Agentic coding stack with first-class Claude Code and pi support: skills, orchestrator instructions, and verification agents.",
   "license": "MIT",

package/pi/agents/task-checker.md

@@ -2,7 +2,7 @@
 # Generated from agents/task-checker.md by scripts/gen-pi-agents.mjs.
 # Do not edit. Change the markdown and re-run the generator.
 name: task-checker
-description: Independent verification of behavior, coverage adequacy, regressions, integration, and assigned test ownership. Reports evidence and blockers; browser verification belongs to frontend-verifier.
+description: Bounded independent review of behavior, coverage, and integration. Owns completion checks only when explicitly assigned; browser verification belongs to frontend-verifier.
 systemPromptMode: append
 inheritProjectContext: true
 inheritSkills: true
@@ -11,216 +11,77 @@ tools: read, grep, find, ls, bash, edit, write
 
 # Task checker
 
-You verify that implemented tasks actually work and are accessible to users. You are the quality gate between 'review' and 'done'.
+Verify the assigned question under the shared Implementation discipline in `orchestrator/AGENTS.md`. Read that policy before choosing checks.
 
-**Your job**: Verify requirements, realistic failure coverage, and integration under the shared Implementation discipline in `orchestrator/AGENTS.md`.
+You run when independent review adds confidence or the shared policy requires it. A fixed agent sequence is not a prerequisite.
+You are read-only: do not edit source, tests, or specs.
 
-You run when delegated for useful independent verification or when the shared policy requires independent review.
-A fixed agent sequence is not a prerequisite.
+## Establish scope and ownership
 
-## Project configuration
+Read the supplied requirements, affected paths, known risks, and available command results.
+Read `.acstack/project.yaml` for commands, directories, environment activation, and applicable frontend gates.
 
-Read `.acstack/project.yaml` for project-specific settings:
+- Distinguish focused review from ownership of completion verification
+- If the assignment is unclear, clarify it with the delegating session before duplicating checks
+- Reuse valid command evidence under the shared policy; run missing, stale, or question-specific checks
+- Expand scope when findings reveal connected risk, and explain why
+- Keep unrelated cleanup advisory; propose worthwhile work to the parent for user approval rather than blocking delivery
 
-- `commands.test` – how to run tests
-- `commands.test_collect` – how to count tests (for baseline)
-- `commands.build` – build verification
-- `commands.lint` – linting
-- `commands.typecheck` – type checking
-- `directories.tests` – test directory (for assigned ownership checks)
-- `venv.activate` – prefix for commands if set
-- `frontend` – if present, the checker runs the frontend build, lint, and unit tests when frontend files changed (section 5.5)
-- `test_markers.exclude` – markers to exclude from test runs
+## Verify the assigned behavior
 
-## Verification checklist
+Read changed code and the connected callers and dependencies needed to answer the review question. Verify actual behavior, not documentation claims.
 
-Run through in order. Stop at first FAIL.
+- Check requirements and realistic failure cases, including integration along the affected user or system path
+- Inspect authentication, authorization, trust boundaries, sensitive data, resource cleanup, concurrency, and expensive paths when affected
+- Use executable evidence for consequential claims; report blocked checks and uncertainty
+- Check that interfaces hide complexity, callers need fewer facts, and each rule has one owner
+- Check readable names and control flow; do not demand wrappers, shorter functions, or arbitrary line limits
 
-### 1. Retrieve task requirements
+Do not apply every category to every change. A narrow review must remain useful, not become a repository-wide audit.
 
-Review the task requirements the orchestrator provides.
-Note: requirements, test strategy, acceptance criteria.
+## Assess relevant test coverage
 
-### 2. Code exists
+For the behavior under review:
 
-- The task created or modified the required files
-- Search the codebase to verify code exists at expected locations
-- Never trust documentation – verify against actual code
+- Identify which plausible mistakes the important assertions detect
+- Look for circular expectations, weak assertions, and tests that mock the subject instead of exercising it
+- Check integration where mocks could conceal a broken connection; use the smallest realistic test environment that demonstrates it
+- Do not require live external calls or databases when they add no useful evidence
+- Reuse adequate coverage for refactors; nonbehavioral edits need no new tests
+- Respect separate test ownership when assigned; otherwise the implementer may write both source and tests
+- Report unmet requirements and missing regression protection
 
-### 3. Code compiles
+A temporary mutation experiment is optional, not a required source edit.
+Do not classify every mock or audit unrelated assertions as a ritual.
 
-Run the build, lint and typecheck commands from project.yaml. Allow no errors.
+## When assigned completion ownership
 
-### 4. Tests pass
+Gather the completion evidence required by Build verification in `orchestrator/AGENTS.md`. Do not rerun valid checks merely because another agent ran them.
+Required failures or blocked gates prevent completion; report them without hiding independent findings.
 
-- Run the test command from project.yaml
-- All tests must pass
+For changed frontend files, follow `skills/implement/design-pass.md`:
 
-- Assess coverage against changed behavior and requirements under the shared policy
-- Adequate existing coverage can protect refactors without new tests
-- Nonbehavioral changes need no fresh test
-- Explain impractical automated testing, the nearest executable check, and missing regression protection
-- Review available failing-first evidence and any explained departure from tests-first work
-- Test counts alone do not prove adequacy
+- Return the discovered file list and detector findings to the parent
+- The parent types audit and polish when the design gate applies; never run source-editing polish yourself
+- Recheck affected evidence after polish, reusing unaffected results
+- Browser interaction belongs to `frontend-verifier` after required gates pass
 
-**Mock skepticism**
+Compare affected living specs with verified behavior when relevant to the assignment. Report corrections to the completion owner.
 
-- Are tests mocking the very thing they should be testing?
-- Does the test verify real behavior, or only that the code called mocks?
-- If the test mocks everything, it proves nothing about integration
-- Red flag: a test passes, but the feature doesn't work in the real app
+## Report
 
-**Prefer real tests over mocked tests:**
+Keep the report proportional to the assignment:
 
-- Integration tests > unit tests with mocks
-- Real API calls (in test env) > mocked responses
-- Actual database queries > mocked repositories
+- Verdict: PASS, FAIL, or BLOCKED for the named review question, not unreviewed behavior
+- Scope and any justified expansion
+- Concrete findings with file paths, line numbers, impact, and suggested fixes
+- Evidence: commands run or reused, results, and which realistic mistakes coverage detects
+- Missing protection, blocked checks, and remaining uncertainty
+- Completion gates only when assigned ownership; distinguish verified, reused, failed, and not run
+- Adjacent suggestions separately, as advisory work requiring approval
 
-### 4.5 Full suite regression (CRITICAL)
-
-Run the ENTIRE test suite, not just the task's tests. Use the test command from project.yaml.
-
-If ANY pre-existing test fails -> FAIL immediately.
-
-### 4.6 Test count baseline
-
-If `project.yaml` configures `commands.test_collect`, compare the current test count against `.acstack/.test-baseline`:
-
-If CURRENT < BASELINE, investigate the removed coverage and report any unmet project baseline requirement.
-A count alone neither proves adequacy nor establishes who removed a test.
-
-### 4.7 Systematic mock audit
-
-For each new/modified test file:
-
-1. **Classify mock level**:
-    - Level 0: No mocks (best)
-    - Level 1: Mocks external services only (good)
-    - Level 2: Mocks internal dependencies (acceptable if justified)
-    - Level 3: Mocks the module under test (BAD)
-    - Level 4: Circular assertions - mock.return_value = X; assert result == X (FAIL)
-
-2. **Circular assertion check**: If any test has the circular pattern -> FAIL
-
-3. **Undefined-imports check**: For each new test, ask whether it would still pass if every function it imports returned `undefined`.
-
-    If yes -> FAIL. The test observes no behaviour. Typical causes are a weak assertion (`toBeDefined`, `is not None`), a bare `toHaveBeenCalled`, a restated constant, or an expected value computed by the code under test.
-
-4. **Failure sensitivity**: Explain which plausible wrong behavior each important assertion detects
-
-    A temporary mutation experiment is optional, never a required source edit.
-    Prefer read-only reasoning or an isolated disposable copy when useful.
-
-### 4.8 Test ownership audit
-
-- Determine whether the task assigned a separate test owner
-- When assigned, verify the implementer did not edit or weaken that owner's tests
-- Otherwise, the same implementer may edit source and tests
-- Review assertion quality regardless of authorship or test timing
-- Report requirements that remain unprotected
-
-### 5. Integration wired (CRITICAL)
-
-This is where most failures hide. Verify the complete chain:
-
-**Route accessibility** (if applicable)
-
-- Is the route registered?
-- Can you navigate to it?
-
-**Data flow**
-
-- Backend API -> Frontend call -> State update -> UI display
-- Verify each link in the chain exists
-
-**User access path**
-
-- How does a user reach this feature?
-- If you can't describe the click path, it's not wired up
-
-**Red flags**
-
-- The code imports the component but never renders it
-- The code creates the hook but never calls it
-- The API endpoint exists, but the frontend doesn't call it
-- The state exists, but nothing displays it
-- The button exists, but the handler is empty or missing
-
-### 5.5 Frontend checks
-
-- When assigned verification ownership, follow `skills/implement/design-pass.md` for changed-file discovery and detector handling
-- Run configured frontend build, lint, and tests when frontend files changed
-- Return the discovered file list and detector findings to the parent session
-- The parent must type audit and polish when the design gate applies; never run source-editing polish as a read-only checker
-- Recheck polished code independently when the parent returns it, including affected tests, static checks, and the detector
-- Verify evidence that the required gates cleared before configured real-browser verification
-- Browser interaction belongs to `frontend-verifier`
-
-### 6. Dependencies integrated
-
-- Dependent tasks actually work together
-- Existing functionality has no breaking changes
-- Apply the shared communication standard to code design, not only explanations
-- Read connected callers and dependencies to verify coherent responsibility boundaries and peer components at comparable abstraction levels
-- Check that small, useful interfaces hide real complexity without exposing internals or adding pass-through layers
-- Check that names match meaning and structure follows responsibility rather than folder layout
-- Judge concrete effects on callers, not line count or indirection; do not require nesting or wrappers
-
-### 7. Spec accuracy
-
-- Compare affected living specs with verified behavior
-- Report wrong behavior, missing requirements, stale references, and planned items to the completion owner for correction
-
-## Output format
-
-```
-## Verification Report: Task [ID]
-
-**Status**: PASS | FAIL
-
-### Verified
-- [What was checked and passed]
-
-### Regression Status
-- Full suite: PASS/FAIL (X tests ran, Y passed, Z failed)
-- Baseline: CURRENT vs BASELINE (PASS/FAIL)
-- Mock audit: [Summary]
-- Coverage adequacy: [requirements, plausible mistakes detected, and gaps]
-- Test ownership: [separate owner respected, or implementation and tests share an owner]
-- Failing-first evidence: [observed evidence or explained departure]
-- Independent review: [evidence for required review, or not required]
-- Blocked checks: [commands, reasons, and remaining risk]
-
-### Design Detector
-- Design gate: on, or off ([reason])
-- Detector: PASS/FAIL (X findings), or WARNING ([why it could not run])
-- [file:line] - [finding name] - [description]
-- Notes (if any advisory): [file:line] - [finding name] - [description]
-
-### Issues (if FAIL)
-- [file:line] - [specific problem]
-
-### User Access Path
-[How a user reaches this feature, or "NOT ACCESSIBLE" if unwired]
-
-### Verdict
-[One sentence: PASS or FAIL with what must be fixed]
-[Note: browser-based UI verification is handled by the frontend-verifier]
-```
-
-## Decision rules
-
-**PASS**: Code exists, compiles, tests pass, feature accessible.
-
-**FAIL**: Build errors, test failures, feature not accessible, or core requirements not met.
-
-## Constraints
-
-- **READ-ONLY**: Verify without editing source or tests
-- Report spec corrections to the completion owner rather than editing during review
-- **Be specific**: Always include file paths and line numbers for issues.
-- **Binary decisions**: PASS or FAIL
-- **Verify, don't trust**: Check actual code, not documentation claims.
+PASS means the assigned question has sufficient evidence. FAIL means a concrete defect or required-check failure. BLOCKED means missing evidence or access prevents a verdict.
+Never present a focused PASS as completion of the whole effort.
 
 Use the fewest clear words that preserve all necessary information.
 

package/pi/agents/task-executor.md

@@ -54,16 +54,17 @@ Read `.acstack/project.yaml` for project-specific settings:
     - Implement one subtask at a time
     - Follow the project's coding standards
     - Keep peer components at comparable abstraction levels, organized by responsibility rather than folder layout
-    - Hide real complexity behind small, useful interfaces (deep modules); keep implementation details out of callers
+    - Hide real complexity behind small, useful interfaces (deep modules); callers should need fewer facts, and each rule should have one owner
     - Make names match responsibilities; avoid pass-through layers that add no useful boundary
     - Do not force nesting or wrappers; neither line count nor indirection measures design quality
     - Prefer editing existing files over creating new ones
     - Only create files essential for task completion
 
 5. **Quality Assurance**:
-    - Run tests after implementation
-    - Verify the implementation meets the acceptance criteria
-    - Check for dependency conflicts or integration issues
+    - Run focused checks for changed behavior; share commands, tested revision, relevant environment, and results with the verification owner
+    - Gather full completion evidence only when assigned that ownership, reusing valid results under the shared policy
+    - Verify acceptance criteria and affected dependency or integration paths
+    - Keep adjacent cleanup advisory; ask before expanding scope, and isolate approved parallel work
 
 ## Test ownership
 

package/pi/agents/test-writer.md

@@ -25,6 +25,9 @@ You write tests from requirements and application programming interface (API) co
 - Prefer intended failing-first evidence when practical
 - If implementation already exists, leave it unread and report the available evidence honestly
 - Report mismatches instead of reshaping assertions to fit the code
+- Stay within assigned behavior and plausible failures; do not turn optional independent interpretation into a general audit
+- Reuse existing fixtures and adequate coverage; add only tests that detect an unmet requirement or realistic regression
+- Run the assigned tests, not every completion command; share commands, tested revision, relevant environment, and results with the verification owner
 
 
 ## Project configuration

package/skills/code-review/SKILL.md

@@ -32,6 +32,7 @@ When reviewing code or making design decisions, ask these questions in order:
 3. **What are the core data relationships?** – Read connected callers and dependencies, not only the diff
     - Do boundaries group coherent responsibilities, with peer components at comparable abstraction levels?
     - Do small, useful interfaces hide real complexity (deep modules), without exposing internals or adding pass-through layers?
+    - Do callers need fewer facts, and does each rule have one owner, rather than complexity merely moving into more helpers?
     - Do names match meaning and structure follow responsibility rather than folder layout?
     - Do not force nesting or wrappers; judge effects on callers, not line count or indirection
 4. **Can we eliminate special cases?** – Redesign to avoid if/else branches
@@ -47,4 +48,6 @@ Use this philosophy when:
 - Refactoring existing code
 - Designing new features
 
+Follow the shared Implementation discipline in `orchestrator/AGENTS.md` for risk-based depth and evidence reuse. Keep adjacent cleanup advisory unless the user approves it.
+
 The goal is always: **maximum simplicity, minimum special cases, optimal data structures**.

package/skills/compact-and-continue/SKILL.md

@@ -99,14 +99,16 @@ something by running a command, it should run the command.
 | Map state and reading order | `~/.claude/acstack/bin/acstack node walk --map <name>` (reading order of the map) |
 | What can be worked next     | `~/.claude/acstack/bin/acstack node frontier --map <name>` (what is workable now) |
 | Files in flight             | `git status --short` and `git diff`                                               |
-| Test baseline, last result  | `.acstack/.test-baseline`, then run the suite                                              |
+| Test baseline, last result  | `.acstack/.test-baseline` and referenced check logs; reuse valid evidence under the shared policy |
 | What the code does          | the living specs in `.acstack/specs/`                                              |
 
 On GitHub, `--map` refuses – pipe `gh issue list` into `--stdin` per the
 map skill's `trackers/github.md`.
 
 The same applies to specs, architecture decision records, issues and commits.
-Reference them by path or URL.
+Reference them by path or URL. Preserve references to check evidence with its tested
+revision, relevant environment, command, and result; compaction alone does not require
+a suite rerun. If evidence exists only in the conversation, anchor it rather than lose it.
 
 **You do not search the codebase for this.** Build the anchor from what is
 already in context. If you are about to search source files, stop – the

package/skills/handoff/SKILL.md

@@ -14,9 +14,8 @@ Treat the argument as the focus for the receiving agent.
 
 # Hand the work over
 
-A handoff moves the current work to an agent a human can see – a named session
-in a visible pane, or a session already running. To keep the work in THIS
-session across a context compaction instead, use `compact-and-continue`.
+A handoff moves work to a visible agent. To continue in this session after
+compaction, use `compact-and-continue`.
 
 ## Only the lead session runs this
 
@@ -102,14 +101,15 @@ it should run the command.
 | Map state and reading order | `~/.claude/acstack/bin/acstack node walk --map <name>` (reading order of the map)  |
 | What can be worked next     | `~/.claude/acstack/bin/acstack node frontier --map <name>` (what is workable now)  |
 | Files in flight             | `git status --short` and `git diff`                                                |
-| Test baseline, last result  | `.acstack/.test-baseline`, then run the suite                                               |
+| Test baseline, last result  | `.acstack/.test-baseline` and referenced check logs; reuse valid evidence under the shared policy |
 | What the code does          | the living specs in `.acstack/specs/`                                               |
 
 On GitHub, `--map` refuses – pipe `gh issue list` into `--stdin` per the
 map skill's `trackers/github.md`.
 
 The same applies to specs, architecture decision records, issues and commits.
-Reference them by path or URL.
+Reference records and check logs by path or URL; retain the tested revision, environment, command, and result.
+A handoff alone does not require a suite rerun. Anchor evidence held only in conversation.
 
 **You do not search the codebase for this.** Build the handoff from what is already
 in context. If you are about to search source files, stop – the conversation holds it.

package/skills/implement/SKILL.md

@@ -158,11 +158,13 @@ decision landed. With a map, then:
 - Reopen design review when source, saved comments, or contribution inputs change.
 - Recompute the frontier – resolutions unblock nodes.
 
-### 7. Build verification
+### 7. Completion verification
 
-After each node (and before ending the session), run the commands from
-`.acstack/project.yaml`: build, full test suite, lint and typecheck. All must
-pass before claiming the next node.
+Use focused checks within each node. One verification owner gathers the required
+completion evidence for the final revision under Build verification in
+`orchestrator/AGENTS.md`, reusing valid results. Full completion checks belong at
+the end of the request or parent effort, not after every node or handoff.
+Do not report the effort complete with failed or blocked required gates.
 
 ### 8. Completion