qa-review

qa-review is the new unified quality entry point. It replaces the old "review first, then verify" dual-path approach and is uniformly responsible for:

1. Identify the current scope and risk boundaries
2. Perform quality review at the code and architecture level
3. Run verification commands
4. Fix blocking items and re-verify
5. Write the current session artifacts/qa-review.json
6. If the current contract still requires advisor / visual / closeout, continue to fill in the corresponding evidence

Quality Modes

• standard: default mode. Focus on the current changes, related configuration, and real risk boundaries, avoiding irrelevant expanded investigation
• deep: high-risk or long-task closeout mode. Perform a more complete blocking review across 12 dimensions, and prioritize filling in the evidence chain

If contract.json provides qaMode and qaFocus, prioritize following it.

Review Dimensions

All modes must cover at least the following dimensions:

• Functional correctness: boundary conditions, null values, error paths, real data flow
• Security: authentication, injection, sensitive information, permission bypass
• Reliability: timeouts, resource release, exception recovery, consistency
• Performance and capacity: repeated computation, inefficient queries, large-loop I/O, build artifact size
• Maintainability: responsibility boundaries, duplicated logic, naming, dead code, over-abstraction
• Delivery contract: whether requirements / tasks / contract are truly satisfied

deep In mode, additionally check:

• Compatibility
• Observability and operations
• Test effectiveness
• Architecture and dependency boundaries
• Usability
• Evolvability

Evidence Requirements

Blocking issues must provide:

• File location:{file}:{line}
• Observed phenomenon
• Why it constitutes a blocker
• Specific fix direction

Do not give only vague assessments.

Check task completion criteria item by item

If a solution package exists and tasks.md contains a task list, it must be checked item by item:

• For each task marked complete, verify item by item against its "completion criteria" whether it is truly satisfied
• Completion criteria must be independently verifiable boolean conditions—if after reading the criteria you still need additional context to judge, then the criteria itself is unqualified; mark it as [-] and state the reason
• Verification does not depend on main session context: anyone (or another AI) reading the criteria + the current code state should be able to make the same pass/fail determination
• Write the check result to artifacts/qa-review.json of taskVerification field

Verification Commands

Sources of verification commands:

• .helloagents/verify.yaml
• package.json of lint / typecheck / test / build
• pyproject.toml of ruff / mypy / pytest

When a command fails:

1. First explain the root cause
2. Fix blocking items
3. Re-run the relevant command
4. Until it passes, or a real blocker is hit

Structured Evidence

After completing this quality closure, immediately call:

scripts/qa-review-state.mjs write

Write the current session artifacts/qa-review.json, recording at least:

• qaMode
• scope
• outcome
• conclusion
• findings
• fileReferences
• commands

If blocking issues remain,outcome must be written as findings. Do not let the runtime guess conclusions from natural language.

Delivery Requirements

• Without seeing verification output, you cannot claim completion
• Not written qa-review.json, the current result cannot be treated as a trustworthy quality closed loop
• If the current contract requires advisor.json / visual.json / closeout.json, it must continue to be completed