oco-verify-fix

OCO: Verify Fix

You are verifying that code changes are correct and complete. Follow this structured verification workflow.

Step 1: Identify What Changed

List all modified files:

git diff --name-only HEAD 2>/dev/null || git status --short

Step 2: Detect Project Type and Available Checks

Detect the verification suite from project manifests:

Signal	Build	Types	Lint	Test
Cargo.toml	cargo build	cargo check	cargo clippy	cargo test
package.json	npm run build	tsc --noEmit	npm run lint	npm test
pyproject.toml	-	mypy .	ruff check .	pytest
go.mod	go build ./...	go vet ./...	golangci-lint run	go test ./...

Use oco.verify_patch if available (auto-detects project type and runs all checks):

oco.verify_patch({ workspace: "." })

Otherwise, read the project manifest and run checks manually. Prefer scripts from package.json when available.

Step 3: Run Verification Sequence

Execute in order (stop on first failure):

1. Build — Does it compile?
2. Type check — Are types consistent?
3. Lint — Are there style/quality issues?
4. Test — Do tests pass? Are new tests needed?

For each step, report:

• Status: pass / fail / skip (not available)
• Output summary (compact, not raw dump)

Step 4: Assess Results and Impact Coverage

4a. Check impact coverage (if call graph is available)

For each modified function/method, check whether its callers are covered by tests:

• If oco_impact MCP tool is available:

  oco_impact({ symbol: "<modified_function>", max_depth: 2 })
  

  Check: are the transitive callers exercised by the test suite?

• If oco_routes MCP tool is available:

  oco_routes({ symbol: "<modified_function>", direction: "callers", max_depth: 2 })
  

• If yoyo MCP is available:

  yoyo.impact({ symbol: "<modified_function>" })
  

Flag any caller that is NOT covered by existing tests as a potential regression blind spot.

4b. Produce verdict

Produce a verification verdict:

VERDICT: PASS | FAIL | PARTIAL
- Build: [pass/fail/skip]
- Types: [pass/fail/skip]
- Lint:  [pass/fail/skip]
- Tests: [pass/fail/skip]
- Impact coverage: [covered / gaps detected / skip (no call graph)]
- Missing coverage: [description if applicable]

Step 5: Handle Failures

If any check fails:

1. Identify the specific failure
2. Fix it
3. Re-run the failing check
4. Continue the sequence

Step 6: Verification Complete

After all checks pass, the PostToolUse hook automatically detects verification commands (cargo test, npm test, etc.) and marks the session as verified. The Stop hook will then allow completion without warning.

No manual marker is needed — the hook system handles this automatically.

Rules

• Never skip a check that's available in the project
• Never report PASS if any check failed
• If tests are missing for the changed code, flag it explicitly
• Keep output summaries compact — report failures in detail, successes briefly