Quality Harness and private Quality Platform

GitHub · praxis-quality

Quality Harness is the delivered role package for reviewing a selected work result. It inspects Developer evidence and configured checks, persists findings, then offers a separate preview and approved Apply. The private Quality Platform is a distinct planned product for each project’s quality history and an overview across multiple projects. A local review is not evidence of a deployed history service or scheduled customer audit.

What you do with it

With Quality Harness, inspect one WP’s evidence, actual check results, review verdict and any approved application. For longitudinal trends across projects, discuss the separate private Platform direction with the team.

flowchart TD
  H[Prepared WP + Developer evidence] --> V[Quality review: persist findings]
  V --> R[Findings for rework]
  V --> P[Preview Quality outcome]
  P --> A[Human-approved Apply]
  A --> G[Separately approved Git delivery]
  G --> M[PR or MR awaiting human review and merge]

Role/stage: qa / quality. Download the Quality Harness from praxis-quality Releases (praxis-quality.zip) and check that release’s release-meta.json for prerequisites. Discuss private Platform access separately.

Before merge

The Developer handoff links requirements, decisions, intention and verification evidence. Quality Harness reviews the prepared local WP and persists its result. Applying that result to Jira is a separate approved action; Git delivery and merge have their own steps.

The verdict can include:

• which required checks ran, failed, were blocked or were skipped;
• whether the implementation still matches the requirement and design decisions;
• findings from the checks actually configured and supported;
• exact evidence and affected paths;
• a return to Developer with a blocking reason.

The person remains the merge gate.

Across projects: private Platform direction

A series of individually acceptable changes can still accumulate debt. The planned private Platform would retain comparable observations for each project over time, then provide an overview across projects. Recurring evaluations and a project dashboard belong to that Platform direction. Discuss access and scope.

Quality harness skills

Skill	Use when	Reads	Produces	Mutation / gate	Next
quality-status	Inspect Runtime and WP health	WP identifier, Runtime and service health	Current status; this skill does not start the service	Read-only; ensure separately when needed	review-work-package
review-work-package	Developer result is ready	Prepared WP, Developer evidence and configured checks	Persisted local review and findings; then an Apply preview	Review writes local evidence without Apply confirmation. Jira Apply requires approval, confirmation=YES and the matching fingerprint	Inspect outcome or rework
resume-qa	A QA session was interrupted	Runtime health, WP state, preview and persisted report	Recovered operation state and next action	Re-check state before any separately approved Apply	Continue the pending step

These are the three skills in the current hosted Quality ZIP. Broader source playbooks may also contain session-start or verify-work-package; those names are not installed by this ZIP.

Quality runs only product commands declared by the project configuration. Any proposal to write test files requires a separately approved file list. The harness does not invent Jira issues or change product source during verification.

Handoff requirements

Quality expects a valid developer.quality.handoff with:

• WP ID and merge-request reference;
• implementation intention;
• linked requirements and decisions;
• build, test, lint, and package-criteria states;
• executable acceptance checks when supplied.

Missing required evidence blocks promotion. A completed review with a failing verdict is still a successful Quality operation: the finding was produced and persisted, while the change remains blocked.

Returns, incidents, and learning

The source role playbook describes returns, incidents and learning proposals. Treat these as source workflow guidance; confirm which operations exist in your installed release. A finding or proposed team rule still needs human review.

Access boundary

Quality Harness is the fourth role in the handoff chain. Its role-package distribution does not settle its license or the private Platform’s access policy. The Platform is a separate future product for multi-project histories. The operator reference below describes the current local Runtime review/apply contract.

Talk to us about Quality Platform

Current Runtime review and approval

In a configured local Runtime, the current integration separates three actions:

1. Ensure: start or reuse the Runtime-managed Quality service. This is local execution, not approval.
2. Review: execute acceptance checks and the project's configured tests, then persist design/<WP>/qa/quality-review.json and review records. This does not write Jira and does not require Apply confirmation.
3. Apply: preview exact Jira changes, then use confirmation=YES and the matching fingerprint. A passing review can become qualityState=approved and Jira Done only through this approved transition.

Developer completion remains In Progress until Quality Apply. A changed source snapshot needs a fresh review. Read-only status reports divergent state instead of silently reconciling it; a partial Apply retries the same approved fingerprint.

See authorized Quality operations, Quality-only workflow, and troubleshooting. These pages document the supported local operator contract. Obtain the Quality Harness from praxis-quality Releases; contact the team separately about the private Platform.