harness-everything 0.11.7 → 0.12.1

package/to-spec/templates/schema-doc.md

@@ -28,4 +28,18 @@ What breaks for existing consumers, if anything, and what the mitigation is (dua
 
 One realistic, complete example instance of the schema.
 
+## Contract Requirements
+
+For every normative schema behavior this document owns, assign a stable requirement identity:
+
+```md
+### REQ-001 — <short behavior name>
+**Status:** CURRENT
+**Revision:** 1
+**Decision lineage:** ADR-0001 (or None)
+<observable validation, compatibility, or migration contract>
+```
+
+Do not recycle requirement IDs. A changed schema/validation contract increments the revision before implementation completion.
+
 </spec-template>

package/to-tickets/SKILL.md

@@ -4,7 +4,7 @@ description: Break a to-spec feature-spec, a plan, or a conversation into tracer
 license: Apache-2.0
 metadata:
   author: Miya Daniel
-  version: 0.4.0
+  version: 0.12.0
 ---
 
 # To Tickets

package/to-tickets/references/publishing-and-templates.md

@@ -48,6 +48,19 @@ Give each ticket its **blocking edges** — the other tickets that must complete
 
 **Wide refactors are the exception to vertical slicing.** A **wide refactor** is one mechanical change — rename a column, retype a shared symbol — whose **blast radius** fans across the whole codebase, so a single edit breaks thousands of call sites at once and no vertical slice can land green. Don't force it into a tracer bullet; sequence it as **expand–contract**. First expand: add the new form beside the old so nothing breaks. Then migrate the call sites over in batches sized by blast radius (per package, per directory), each batch its own ticket blocked by the expand, keeping CI green batch to batch because the old form still exists. Finally contract: delete the old form once no caller remains, in a ticket blocked by every migrate batch. When even the batches can't stay green alone, keep the sequence but let them share an integration branch that all block a final integrate-and-verify ticket — green is promised only there.
 
+# Contract lineage and change impact
+
+When a ticket comes from an authoritative spec, it must carry the exact source requirement identity and revision. A ticket may refine implementation scope, but it never silently rewrites the approved contract.
+
+Every ticket must classify its impact:
+
+- **none** — bookkeeping/non-behavioral work; explain why no contract changes.
+- **implementation** — implementation changes while approved behavior and architectural rationale stay unchanged.
+- **behavior** — caller/user-visible behavior changes. Update the living spec requirement and revision first, then obtain requirement-linked RED evidence before accepting implementation.
+- **architecture** — a hard-to-reverse decision/rationale changes. Publish a new/superseding ADR, update the living spec requirement/revision, then obtain RED evidence.
+
+If the impact classification changes during implementation, stop treating the original ticket as completion authority. Reconcile the source artifacts first, then update the ticket's source revision.
+
 # Ticket Templates
 
 <local-ticket-template>
@@ -58,9 +71,15 @@ Give each ticket its **blocking edges** — the other tickets that must complete
 
 **Blocked by:** the numbers/titles of the tickets that gate this one, or "None — can start immediately".
 
+**Source requirements:** `REQ-001@rev1` (add every requirement this ticket changes or proves).
+
+**Change impact:** `none | implementation | behavior | architecture`
+
+**Impact rationale:** one sentence explaining why this classification is correct.
+
 **Status:** ready-for-agent
 
-- [ ] Acceptance criterion 1
+- [ ] [REQ-001] Acceptance criterion 1
 - [ ] Acceptance criterion 2
 
 </local-ticket-template>

package/verification-loop/SKILL.md

@@ -4,7 +4,7 @@ description: "Run objective verification gates (build, types, lint, tests, secur
 license: Apache-2.0
 metadata:
   author: Miya Daniel
-  version: 0.4.0
+  version: 0.12.0
 ---
 
 # Verification Loop
@@ -41,6 +41,7 @@ and rerun from the first affected gate.
 4. Tests and coverage: `npm run test -- --coverage`.
 5. Security scan: secrets and stray logs.
 6. Diff review: `git diff --stat` and unintended-change checks.
-7. Fill `<this-skill-dir>/templates/verification-report.template.md` with evidence.
+7. Contract reconciliation when the work cites `REQ-*` / ADR/spec/ticket lineage or a contract-integrity trace exists: run the strict `<this-skill-dir>/scripts/contract-integrity-audit.js` gate with current #58 evidence. `AUDIT`, `NOT_EVALUATED`, stale source binding, or drift is **not ready** for delivery.
+8. Fill `<this-skill-dir>/templates/verification-report.template.md` with evidence.
 
 Deep dive: `<this-skill-dir>/references/verification-phases.md`

package/verification-loop/references/verification-phases.md

@@ -10,8 +10,14 @@ flowchart TD
     Lint --> Test[4. Phase 4: Test Suite Execution]
     Test --> Security[5. Phase 5: Security & Secret Scan]
     Security --> Diff[6. Phase 6: Diff Review]
+    Diff --> Contract{7. Contract lineage applicable?}
+    Contract -- Yes --> Reconcile[Run contract-integrity strict reconciliation]
+    Contract -- No --> CheckScript
+    Reconcile --> ContractResult{PASS?}
+    ContractResult -- No --> Fix
+    ContractResult -- Yes --> CheckScript
     
-    Diff --> CheckScript{7. Is verify-gate.js / Template Available?}
+    Diff --> CheckScript{8. Is verify-gate.js / Template Available?}
     
     CheckScript -- Yes --> RunScript[Run harness-everything/scripts/verify-gate.js / Fill verification-report.template.md]
     CheckScript -- No --> DirectReport[Output Verification Report Inline in Response]
@@ -93,6 +99,24 @@ Review each changed file for:
 - Missing error handling
 - Potential edge cases
 
+## Phase 7: Contract Reconciliation
+
+This phase is applicable when any of the following is true:
+
+- the task/spec/ticket cites stable `REQ-*` identities;
+- an ADR/spec/ticket change is classified as `behavior` or `architecture`;
+- the project has a contract-integrity trace for the affected scope.
+
+Use the current trace plus current #58 TDD evidence:
+
+```bash
+node "<this-skill-dir>/scripts/contract-integrity-audit.js" <trace.json> --tdd-evidence <tdd-evidence.json> --output <report.json> --markdown <report.md>
+```
+
+Delivery requires strict **PASS**. Treat `FAIL`, `AUDIT`, `NOT_EVALUATED`, source conflicts/defects, stale spec/test/implementation lineage, surviving required probes, and audit-only output as **NOT READY**. Do not downgrade the gate merely because build/tests are otherwise green.
+
+If this phase is not applicable, record `NOT_APPLICABLE` with a one-line reason. Never use `NOT_APPLICABLE` to hide known requirement lineage.
+
 ## Output Format
 
 After running all phases, fill in `verification-loop/templates/verification-report.template.md` with the actual results and present it.

package/verification-loop/scripts/contract-integrity-audit.js

@@ -0,0 +1,31 @@
+#!/usr/bin/env node
+'use strict';
+
+const fs = require('fs');
+const path = require('path');
+
+function resolveAuditRuntime() {
+  const candidates = [
+    path.resolve(__dirname, '../../contract-integrity/scripts/audit.js'),
+    path.resolve(__dirname, '../../../contract-integrity/scripts/audit.js'),
+  ];
+  for (const candidate of candidates) {
+    if (fs.existsSync(candidate)) return candidate;
+  }
+  throw new Error('contract-integrity audit runtime is not packaged with this verification-loop installation');
+}
+
+function main() {
+  try {
+    const target = resolveAuditRuntime();
+    const { runCli } = require(target);
+    if (typeof runCli !== 'function') throw new Error('contract-integrity audit runtime does not export runCli');
+    process.exitCode = runCli([process.execPath, target, ...process.argv.slice(2)]);
+  } catch (error) {
+    console.error('[Verification Contract Gate] ' + error.message);
+    process.exitCode = 2;
+  }
+}
+
+if (require.main === module) main();
+module.exports = { resolveAuditRuntime };

package/verification-loop/templates/verification-report.template.md

@@ -7,6 +7,9 @@ Lint:      [PASS/FAIL] (X warnings)
 Tests:     [PASS/FAIL] (X/Y passed, Z% coverage)
 Security:  [PASS/FAIL] (X issues)
 Diff:      [X files changed]
+Contract:  [PASS/FAIL/NOT_APPLICABLE] (REQ IDs / trace report / reason)
+            Strict PASS required when contract lineage is applicable.
+            AUDIT or NOT_EVALUATED is NOT READY.
 
 Overall:   [READY/NOT READY] for PR