Review with Quality Harness
Quality Harness reviews a particular work result. It is a delivered role package used with a configured local Runtime and review context. Its distribution and license should be checked from its own release; access to the separate private Quality Platform does not define access to this harness. The Platform is planned to retain quality history within multiple projects and show an overview across them.
Select the local Runtime root and WP, then inspect the Architect design, Developer completion evidence and developer.quality.handoff. Jira Done is not the readiness signal. With the Quality role Skill, use praxis_quality_status, then praxis_quality_ensure if the local service is not started. Ensure starts the service; it does not approve a review. praxis_quality_review runs supported acceptance checks and configured tests, persists design/<WP>/qa/quality-review.json and local review records, and leaves Jira unchanged. Checks may be skipped or blocked; inspect the actual result rather than assuming a universal verdict vocabulary.
If the result is ready to apply, inspect praxis_quality_apply_preview; stop for the action-specific approval. praxis_quality_apply requires confirmation=YES and the matching current fingerprint. Verify Jira, local manifest and persisted review afterward. An interrupted Apply resumes from status and its approved fingerprint when still valid; external Jira drift requires a new preview. Review, applied status, Git delivery and merge are separate decisions.
I am reviewing <runtime-WP-or-mapped-Jira-key> in <code-path>.
Show the design, Developer evidence, missing or skipped checks and current
review status. Run the configured review and persist findings. Do not apply
Jira changes or deliver Git changes without a separate preview and approval.For a single review, see Quality operations. To discuss future cross-project history and managed oversight, request Platform access.