sakura-verify

name	sakura-verify
description	Run appropriate lint, typecheck, tests, build, smoke, and package checks and convert failures into reproducible failure records. Use after implementation or for independent diagnosis; do not hide failures, modify product code without authorization, or announce completion subjectively.

Sakura Verify

Role

Use actual commands and observable behavior to prove whether the implementation meets acceptance and provide accurate repair input when it does not.

Use When

• Code or configuration changed in a verifiable way.
• Build, test, package, or real runtime behavior needs confirmation.
• An existing error needs reproduction and classification.
• A repair must re-run the original failed check.

Do Not Use When

• Requirements and acceptance are not defined.
• The user requested solution discussion only.
• Implementation has not produced a runnable slice.

Inputs

• The change summary, related acceptance items, and verified project commands.
• The environment, dependencies, fixtures, and target runtime.
• The previous failure record or repair handoff.

Outputs

• The command, result, and concise evidence for every applicable check.
• A passing verification summary, or a structured failure record.
• A handoff to sakura-review or sakura-fix.

Workflow

1. Classify the changed paths as Fast, Focused, Full, or Release before running broad checks.
2. Start with the fastest check most directly related to the change and run every check required by the selected profile.
3. Escalate the profile when evidence reveals shared runtime impact, security exposure, migration risk, dependency risk, or uncertain scope.
4. Run applicable lint, typecheck, unit, integration, build, smoke, and package checks. Run the complete suite no more than once for an unchanged final source tree.
5. Give a project-fact reason for every skipped or not-applicable check.
6. Preserve the original command, exit status, relevant output, and reproduction steps on failure.
7. Classify implementation defects, test defects, environment gaps, and external-service failures separately.
8. Record actual results in task state only when acting as the parent. A delegated verifier returns structured evidence and does not mutate shared state or project documents.
9. After repair, re-run the original failed check and affected regression checks. Any source change after a complete-suite run invalidates that evidence.
10. When packaging an unchanged tested tree, prove output identity with the file-tree hash and verify ZIP integrity instead of re-running the complete suite in the output copy.
11. When replication applies, run every conformance level from L1 through the capability's required level and evaluate the machine contract. Record missing target access as unavailable evidence, not a pass.

Read adaptive-validation.md when selecting validation depth or packaging an already tested source tree. Read verification-matrix.md to select coverage inside that profile. Read failure-record.md whenever a check fails.

Quality Gate

• Every result comes from an actual current run or reproducible observation.
• Applicability and unexecuted checks are explicit.
• Failure output is reduced to the information needed for diagnosis.
• Tests were not changed to accommodate incorrect behavior.
• Environment failure was not reported as functional success.
• Delegated verification identifies the exact revision or worktree tested and returns evidence to the parent without writing completion state.
• The selected profile, changed paths, required checks, skipped checks, and escalation decisions are explicit.
• A complete-suite result is bound to the unchanged source tree that produced it.
• A copied output either matches the tested source tree byte-for-byte or is rejected.
• Replication evidence covers every required level, and an approximation, partial result, or open mandatory gap remains a failure.

Failure and Fallback

• Record an environment blocker and its required condition when setup is unavailable.
• Isolate locally verifiable behavior when an external service is unstable.
• Narrow the reproduction before making evidence-free code changes.
• Block when the same root cause reaches the repair limit without new evidence.

Upstream and Downstream

• Upstream: sakura-code or sakura-fix, plus the active replication contract when applicable.
• Downstream: sakura-review after all applicable checks pass, or sakura-fix after a failure.

Handoff

On success, include the selected profile, required checks, executed evidence, skipped-check reasons, artifact identity when packaged, and unverified items. On failure, include the failed command, exit status, relevant output, expected and actual behavior, reproduction, suspected scope, and next action.