Analysis, Readiness, and Verification
Understand how Workspai separates findings, release preparedness, and the final governed verdict.
Analyze, Readiness, and Verify answer different questions. Treating them as one generic health check hides the evidence boundary that explains a blocker.
| Surface | Question | Canonical artifact |
|---|---|---|
| Analyze | What findings follow from current workspace evidence? | .workspai/reports/analyze-last-run.json |
| Readiness | Is the workspace prepared for the release policy? | .workspai/reports/release-readiness-last-run.json |
| Verify | Do impact, diagnostics, contracts, analysis, and readiness form an acceptable verdict? | .workspai/reports/workspace-verify-last-run.json |
Run the complete chain
npx workspai workspace intelligence run --for-agent generic --strict --jsonThe runner preserves the canonical eleven-stage order. Use the individual commands for targeted inspection or when a blocker-resolution hint identifies one producer that must be refreshed.
npx workspai analyze --json
npx workspai readiness --json
npx workspai workspace verify --strict --jsonFollow producer evidence
When Verify reports missing or stale evidence, consume its structured
sourceCommand and sourceArtifact. Run that producer once, refresh Verify, and
continue from current evidence. Never infer a command from a familiar filename or
mark a warning as passed because an unrelated check succeeded.
passed, failed, and blocked are distinct terminal outcomes. Strict mode may
promote policy warnings to a non-zero process result, but it does not rewrite the
underlying evidence status.
Command details: analyze,
readiness, and
workspace verify.