with one click
manifold-m5-verify
// Verify ALL artifacts against ALL constraints. Produces a verification matrix showing coverage and gaps
// Verify ALL artifacts against ALL constraints. Produces a verification matrix showing coverage and gaps
[HINT] Download the complete skill directory including SKILL.md and all related files
| name | manifold-m5-verify |
| description | Verify ALL artifacts against ALL constraints. Produces a verification matrix showing coverage and gaps |
Verify ALL artifacts against ALL constraints.
This phase ONLY reads existing artifacts and creates/updates .manifold/<feature>.verify.json. It verifies what exists — it does not create what's missing.
DO NOT do any of the following during m5-verify:
.manifold/Gaps are FINDINGS, not work orders. Document gaps in the verification matrix and gap list. The user decides whether to fix them. After creating/updating .verify.json: display verification matrix, list gaps, suggest next step, STOP.
| Field | Valid Values |
|---|---|
| Sets Phase | VERIFIED |
| Next Phase | Return to INITIALIZED for iteration, or workflow complete |
| Convergence Statuses | NOT_STARTED, IN_PROGRESS, CONVERGED |
| Verification Symbols | ✓ (SATISFIED), ◐ (PARTIAL), ✗ (MISSING), - (N/A) |
See SCHEMA_REFERENCE.md for all valid values. Do NOT invent new phases or statuses.
/manifold:m5-verify <feature-name> [--strict] [--actions] [--verify-evidence] [--run-tests] [--execute] [--levels]
| Flag | Purpose |
|---|---|
--strict | Fail on any gaps |
--actions | Generate copy-paste executable actions for gaps (v2) |
--verify-evidence | Verify concrete evidence for required truths (v3) |
--run-tests | Execute test evidence verification (requires --verify-evidence) (v3) |
--execute | Run configured test_runner subprocess (v3.1). Requires .manifold/config.json with test_runner |
--levels | Show satisfaction level breakdown: DOCUMENTED / IMPLEMENTED / TESTED / VERIFIED (v3.1) |
Every constraint is checked across four artifact dimensions:
| Dimension | Question |
|---|---|
| Code | Is it implemented? |
| Test | Is it validated? |
| Docs | Is it documented? |
| Ops | Is it monitored? |
Verification statuses:
| Status | Symbol | Meaning |
|---|---|---|
| SATISFIED | ✓ | Fully implemented and verified |
| PARTIAL | ◐ | Partially addressed, gaps remain |
| MISSING | ✗ | Not addressed in this artifact |
| N/A | - | Not applicable to this artifact |
Default: INVARIANTs must be ✓ in Code + Test. BOUNDARIEs must be ✓ in Code. GOALs can be ◐ or ✓.
Strict (--strict): All constraints must be ✓ across all applicable artifacts. No ◐ allowed.
Constraints are classified by verification depth when --levels is used:
| Level | Meaning | Evidence Required |
|---|---|---|
DOCUMENTED | Constraint acknowledged in docs/specs | manual_review evidence |
IMPLEMENTED | Code exists that addresses constraint | file_exists evidence |
TESTED | Tests verify constraint behavior | test_passes with VERIFIED or STALE status |
VERIFIED | Automated verification confirms | test_passes + status VERIFIED |
Invariant-type constraints SHOULD reach at least TESTED level.
Critical: A test_passes evidence item with status PENDING means the test file exists but has NOT been executed. This counts as IMPLEMENTED, not TESTED. Only VERIFIED or STALE statuses count toward TESTED.
Evidence items can declare test_tier: unit, integration, or e2e. Constraints involving external systems should require at least integration tier. Example evidence:
{ "id": "E1", "type": "test_passes", "path": "tests/kafka.integration.ts", "test_name": "produces message to real Kafka", "test_tier": "integration" }
With --verify-evidence, each required truth's evidence is checked:
| Type | Verification Method |
|---|---|
file_exists | Check file exists on disk |
content_match | Grep for pattern in file content |
test_passes | Run test and check exit code (requires --run-tests) |
metric_value | Check runtime metric meets threshold |
manual_review | Skip (requires human verification) |
Evidence lives on Required Truths, not directly on constraints. The chain: RT.evidence --> RT.maps_to --> Constraint satisfaction.
When multiple RTs map to the same constraint, aggregate their evidence before computing the level:
| Evidence combination | Satisfaction Level |
|---|---|
| No evidence | DOCUMENTED |
| file_exists or content_match | IMPLEMENTED |
| test_passes (PENDING) | IMPLEMENTED |
| test_passes (VERIFIED or STALE) | TESTED |
| All evidence VERIFIED + test passed | VERIFIED |
Propagation algorithm:
maps_to includes that constraint IDIMPLEMENTEDmanifold drift <feature> # Check for changes since last verify
manifold drift <feature> --update # Recompute and store current hashes
File hashes are stored at verify time. After successful verification, capture baseline with manifold drift <feature> --update. Skipping this means post-verification changes go undetected.
Create .manifold/config.json to configure test execution:
{
"test_runner": "bun test",
"test_args": ["--timeout", "30000"],
"test_tier_patterns": { "unit": ["*.test.ts"], "integration": ["*.integration.ts"], "e2e": ["*.e2e.ts"] },
"drift_hooks": { "on_drift": "echo 'Drift detected!'" }
}
Annotate test functions with constraint IDs for automatic traceability:
describe('IdempotencyService', () => {
// @constraint B1
it('rejects duplicate payment attempts', async () => {
// Satisfies: B1 (no duplicates)
});
});
The verify command parses @constraint and // Satisfies: annotations to build a matrix: {constraint_id -> [test_file:test_function]}.
challenger: assumption as a convergence risksource: assumption not confirmed by m4-generatechallenger: regulation constraints were never traded off in tension resolution| Constraint kind | SATISFIED means |
|---|---|
deterministic | Artifact provably does not exceed the ceiling |
statistical | Artifact addresses the distribution — test coverage includes percentile cases |
Flag any statistical constraint verified with a single deterministic test.
ONE_WAY entries in reversibility_log must have a corresponding risk watch list entryVIOLATED propagation effects mean the tension resolution is invalidTIGHTENED constraints with challenger: assumption must be confirmed before acceptanceanchors.binding_constraint exists, verify the referenced required truth was addressedWith --actions, gaps are converted to executable tasks:
| Gap Type | Generated Action |
|---|---|
| Missing test | Test file path + test function skeleton |
| Missing integration | Wiring command (see /manifold:m6-integrate) |
| Missing docs | Documentation section template |
| Missing feature flag | Config edit command |
| Missing import | Import statement to add |
Actions are grouped as blocking vs non-blocking. Fix blocking actions first, then re-run /manifold:m5-verify.
/manifold:m5-verify payment-retry
CONSTRAINT VERIFICATION: payment-retry
VERIFICATION MATRIX:
| Constraint | Type | Code | Test | Docs | Ops | Status |
|------------|------|------|------|------|-----|--------|
| B1: No duplicates | INVARIANT | ✓ | ✓ | ✓ | ✓ | SATISFIED |
| B2: 95% success | GOAL | ✓ | ◐ | ✓ | ✓ | PARTIAL |
| T1: <200ms | BOUNDARY | ✓ | ◐ | ✓ | ✓ | PARTIAL |
COVERAGE SUMMARY:
- INVARIANTS: 4/4 (100%) ✓
- GOALS: 3/5 (60%) ◐
- BOUNDARIES: 2/3 (67%) ◐
GAPS IDENTIFIED:
Gap G1: B2 (95% success) - Missing load test validating success rate
Gap G2: T1 (<200ms) - Missing performance test measuring p99 latency
VERIFICATION RESULT: PARTIAL (2 gaps)
Updated: .manifold/payment-retry.verify.json
Verification writes .manifold/<feature>.verify.json:
{
"verification": {
"timestamp": "<ISO timestamp>",
"result": "PARTIAL",
"matrix": [
{ "constraint": "B1", "type": "INVARIANT", "code": true, "test": true, "docs": true, "ops": true, "status": "SATISFIED" },
{ "constraint": "T2", "type": "GOAL", "code": true, "test": false, "docs": true, "ops": true, "status": "PARTIAL", "gap": "Missing load test", "action": "Add concurrency test" }
],
"coverage": {
"invariants": { "satisfied": 4, "total": 4, "percentage": 100 },
"goals": { "satisfied": 3, "total": 5, "percentage": 60 },
"boundaries": { "satisfied": 2, "total": 3, "percentage": 67 }
},
"gaps": [
{ "id": "G1", "constraint": "T2", "issue": "No test coverage", "action": "Add load test in integration.test.ts" }
]
}
}
Always emit
.manifold/<feature>.verify.json, regardless of result. SATISFIED, PARTIAL, or blocked — the artifact is always written. Blockers keep the phase atGENERATED(not advanced toVERIFIED) but do NOT suppress the artifact..verify.jsonpresence is the signal that m5 ran; phase is the signal of whether it converged.
.manifold/<feature>.json and content from .manifold/<feature>.md// Satisfies: B1)--verify-evidence: verify evidence for each required truth (file_exists, content_match, test_passes if --run-tests, metric_value, manual_review)maps_to mappings--levels: display satisfaction level breakdown per constraint--actions: generate executable actions for each gap--strict, fail on any gaps or failed evidenceiterations[] and calculate convergence status.manifold/<feature>.verify.json with full resultsmanifold drift <feature> --updateWhen verifying JSON+Markdown manifolds, check:
#### ID: Title in Markdown### ID: Title in Markdown### ID: Title in Markdowntension.between references exist as constraint IDsrequired_truth.maps_to references existm5-verify is mostly read-only — its output is a verification matrix + .verify.json artifact + suggested next steps. The verify report itself does NOT need AskUserQuestion (it is a status report, end with "Waiting for your command"). However, two interactive paths can arise:
--strict failures: when blocking gaps appear, the model may need to ask the user how to proceed (e.g., "open a follow-up", "amend the manifold", "accept and re-verify"). Those questions MUST use AskUserQuestion, not prose.REOPENED findings during solution-tension validation: the user must decide accept / change option / modify, per the spec. That decision MUST use AskUserQuestion.If your reply contains a question soliciting a user response → use AskUserQuestion. Markdown options ending in "which one?" are the anti-pattern. See install/agents/interaction-rules.md; the prompt-enforcer.ts hook reinforces at runtime.
Run manifold validate <feature> after updates. Shared directives (output format, interaction rules, validation) injected by phase-commons hook.