Project Verification Capability Glossary

This glossary defines the accepted language for project-owned executable behavior verification in Harness.

Terms

Verification

Exercise observable product behavior through a real user path and retain evidence of the action, resulting state, and applicable side effects.

Code Review

Readonly inspection of a frozen change against its specification, standards, security, architecture, simplicity, and skill obligations.

Project Verifier

The project-owned collection of app-specific verification references consumed through the single verify-behavior entrypoint.

Surface Verification Reference

The Project Verifier content for one independently runnable app. It owns that app's Launch, Doctor, Drive, Evidence, Cleanup, Feature Map, and optional helpers.

Feature Map

The maintained index of executable user entry points, driver recipes, expected observable states, variants, side effects, prerequisites, and gotchas. Product specifications and domain documentation remain authoritative for meaning and requirements.

Cross-App Journey

One verification path that composes two or more Surface Verification References without duplicating their app-specific mechanics.

Reference Smoke Proof

A one-time end-to-end check that a newly created app reference can launch, pass Doctor, drive one mapped feature, retain evidence, and clean its run-owned state.

Uncovered Surface

An independently runnable app required by the selected verification scenario that has no Surface Verification Reference.

Uncovered Behavior

Required behavior with no Feature Map entry or executable drive path in an existing app reference.

Scenario Falsifier

An observable result that would disprove the selected verification scenario's expected behavior. Every selected scenario records a positive proof result and a falsifier.

Relevant Negative Condition

A failure or negative condition applicable to important behavior whose actual downstream result is verified. It is selected by relevance and does not require exhaustive negative testing for every scenario.

Relationships

• implement-spec selects the verification scenario and app, then invokes verify-behavior.
• An Uncovered Surface causes implement-spec to invoke create-verification-skill, complete a Reference Smoke Proof, and resume the original scenario.
• An Uncovered Behavior causes implement-spec to invoke update-verification-skill, prove the added drive path, and resume the original scenario.
• Creator or updater proof may be reused only when authority, code, runtime, and scenario conditions match the requesting verification scenario; otherwise the missing proof is run.
• A targeted updater may retire an obsolete Feature Map entry only with current source evidence and reconciled references, while preserving unrelated entries and documented product-expected semantics.
• Wiki specifications, behavior pages, flows, and domain knowledge are read-only inputs to Project Verifier creation and updates.
• review-phase performs Code Review and does not own Verification evidence or reruns.
• review-phase uses one comprehensive primary review with explicit per-axis coverage and one mandatory independent risk-focused challenger for a bounded independent risk area; autoreview is primary, and additional challengers may be assigned when larger changes require separate independent risk areas. The parent adjudicates findings and owns the report; incomplete coverage is not clean.

Axioms

• Verification and Code Review are separate gates.
• verify-behavior is the single verification entrypoint.
• Project-specific mechanics live in project-owned app references, not shared Harness product drivers.
• Scaffold and update post-command flows leave Project Verifier content unchanged.
• implement-spec owns Project Verifier coverage gaps for its selected scenario: creator for an Uncovered Surface, updater for Uncovered Behavior.
• docs-ingest-phase never invokes update-verification-skill or writes Feature Maps.
• Cleanup removes only run-owned resources. Evidence survives cleanup.
• Every selected scenario records a Scenario Falsifier.
• Important behavior uses a Relevant Negative Condition when applicable; no universal exhaustive negative suite is required.
• Review topology details belong to the Delivery Phase Flow Optimization specification.