Verifies that the implementation complies with the specs, design, and task plan.

/sdd-verify <change-name>

• The tasks artifact — what was planned:

  • mem_search(query: "sdd/{change-name}/tasks")

    →

    mem_get_observation(id)

    .
  • If not found and Engram not reachable: tasks content passed inline from orchestrator.
• The spec artifact — what was required:

  • mem_search(query: "sdd/{change-name}/spec")

    →

    mem_get_observation(id)

    .
  • If not found and Engram not reachable: spec content passed inline from orchestrator.
• The design artifact — how it was designed:

  • mem_search(query: "sdd/{change-name}/design")

    →

    mem_get_observation(id)

    .
  • If not found and Engram not reachable: design content passed inline from orchestrator.
• The code files that were created/modified

• [number and description of each one]

**Severity:**

- Incomplete core logic tasks → CRITICAL
- Incomplete cleanup/docs tasks → WARNING

1. I look for evidence in the code that it is implemented
2. For EACH Given/When/Then scenario:
   • Is the GIVEN handled? (precondition/guard)
   • Is the WHEN implemented? (the action/endpoint)
   • Is the THEN verifiable? (the correct result)

undefined

config.yaml (at project root)

verify_commands

if config.yaml (at project root) exists and has key verify_commands:
    → use the listed commands in order
    → do NOT check level 2 or run auto-detection
    → for each command:
         run the command via Bash tool
         capture exit code + stdout/stderr
         record in ## Tool Execution section with source label "verify_commands (config level 1)"
    → skip levels 2 and 3 entirely
else:
    → proceed to level 2 check

verify_commands

verify.test_commands

if config.yaml (at project root) exists and has key verify.test_commands:
    if verify.test_commands is not a list:
        → emit WARNING: "verify.test_commands is not a list — treating as absent"
        → proceed to level 3 (auto-detection)
    else if verify.test_commands is an empty list []:
        → treat as absent (empty list falls through — prevents silent zero-command success)
        → proceed to level 3 (auto-detection)
    else:
        → use the listed commands in order
        → do NOT run auto-detection
        → for each command:
             run the command via Bash tool
             capture exit code + stdout/stderr
             record in ## Tool Execution section with source label "verify.test_commands (config level 2)"
        → skip level 3 entirely
else:
    → proceed to level 3 (auto-detection)

verify_commands

verify.test_commands

package.json

scripts.test

npm test

yarn test

yarn.lock

pnpm test

pnpm-lock.yaml

pyproject.toml

pytest.ini

setup.cfg

pytest

Makefile

test

make test

build.gradle

gradlew

./gradlew test

mix.exs

mix test

1. I execute the detected command via Bash tool
2. I capture the exit code (0 = pass, non-zero = failure)
3. I capture stdout/stderr output for analysis
4. I record: runner name, command executed, exit code, summary of failures (if any)

• If the command cannot be executed (missing dependencies, command not found): I report "Test Execution: ERROR — [error message]" with status WARNING and continue to subsequent steps
• If tests run but some fail: I report the failure count and list failing test names if parseable from the output
• If no test runner is detected: I report "Test Execution: SKIPPED — no test runner detected" with status WARNING

verify.build_command

verify.type_check_command

if config.yaml (at project root) exists and has key verify.build_command:
    if verify.build_command is not a string:
        → emit WARNING: "verify.build_command is not a string — treating as absent"
        → proceed to auto-detection for build command
    else:
        → use verify.build_command as the build/type-check command
        → skip the auto-detection table below for the build/type-check command

if config.yaml (at project root) exists and has key verify.type_check_command:
    if verify.type_check_command is not a string:
        → emit WARNING: "verify.type_check_command is not a string — treating as absent"
        → proceed to auto-detection for type check command
    else:
        → use verify.type_check_command as the type-check command
        → skip auto-detection for type check command

verify.build_command

package.json

scripts.typecheck

npm run typecheck

package.json

scripts.build

npm run build

tsconfig.json

npx tsc --noEmit

Makefile

build

make build

build.gradle

gradlew

./gradlew build

mix.exs

mix compile --warnings-as-errors

1. I execute the detected command via Bash tool
2. I capture the exit code (0 = pass, non-zero = failure)
3. I capture error output for analysis
4. I record: command executed, exit code, error summary (if any)

• If the command cannot be executed: I report "Build/Type Check: ERROR — [error message]" with status WARNING and continue
• If the build fails: I report "Build/Type Check: FAILING" and include error output in the detail section
• If no build command is detected: I report "Build/Type Check: SKIPPED — no build command detected" with status INFO (not WARNING)

1. I read

   config.yaml (at project root)

   and look for

   coverage.threshold

   (e.g.,

   coverage: { threshold: 80 }

   )
2. If no threshold is configured: I skip this step entirely and report "Coverage Validation: SKIPPED — no threshold configured"
3. If a threshold is configured: a. I parse the coverage percentage from the Step 6 test output (looking for common coverage summary formats) b. I compare the actual coverage against the configured threshold c. I report the result:
   • Actual >= threshold: "Coverage: [X]% (threshold: [Y]%) — PASS"
   • Actual < threshold: "Coverage: [X]% (threshold: [Y]%) — BELOW THRESHOLD" with status WARNING
4. If coverage data cannot be parsed from the test output: I report "Coverage Validation: SKIPPED — could not parse coverage from test output" with status WARNING

1. I read all spec content from the active persistence mode (same source as Step 1)
2. For each spec file, I extract every Given/When/Then scenario
3. For each scenario, I cross-reference against:
   • Code implementation evidence from Step 3 (Correctness Check)
   • Test results from Step 6 (Run Tests) — if tests were executed
4. I assign a compliance status per scenario:

• The matrix is still produced using code inspection evidence from Step 3
• Scenarios verified only by code inspection receive COMPLIANT or PARTIAL (never UNTESTED, since code evidence was checked)

undefined

verify-report.md

[x]

1. A tool command was run and its output confirms the criterion, OR
2. The user provided an explicit evidence statement

[ ]

[x]

## Tool Execution

verify-report.md

mem_save

topic_key: sdd/{change-name}/verify-report

type: architecture

project: {project}

undefined

• [issue description] [or: "None."]

• [issue description] [or: "None."]

**Conversational output** (shown to user but NOT persisted):

The full detail sections — Completeness tables, Correctness requirement-by-requirement tables, Coherence decision tracking, Testing coverage tables, Spec Compliance Matrix, Coverage Validation, and SUGGESTIONS — are presented in the conversational response. This gives the user full visibility without inflating the persisted artifact.

The conversational output MUST still include all detail sections from Steps 2-9 — the user needs to see the full analysis. Only the **persisted artifact** is compact.

• [description] [or: "None."]

• [description] [or: "None."]

---

• I ONLY report — I fix nothing during verification
• I read real code — I do not assume something works just because the file exists
• I am objective: I report what IS, not what should be
• If there are deviations documented in tasks.md, I evaluate them with context
• A FAIL is not personal — it is information for improvement
• I run tests if possible (via Bash tool): I report the actual results
• The

  ## Tool Execution

  section is mandatory in every

  verify-report.md

  — even when skipped; when skipped it MUST state "Test Execution: SKIPPED — no test runner detected"
• A criterion marked

  [x]

  MUST have verifiable evidence: tool output or an explicit user evidence statement; abstract reasoning or code inspection alone MUST NOT suffice
• Test command resolution uses a three-level priority model: level 1 (

  verify_commands

  ) > level 2 (

  verify.test_commands

  ) > level 3 (auto-detection); each level is only consulted when all higher levels are absent or invalid
• Empty

  verify.test_commands: []

  falls through to auto-detection — it is NOT treated as zero-command success

• verify.build_command

  and

  verify.type_check_command

  override their respective auto-detected commands when present and are strings; non-string values emit a WARNING and fall back to auto-detection