kibi-cli 0.17.0 → 0.18.1

package/src/public/operations/runtime-types.ts

@@ -31,8 +31,16 @@ export interface FilesystemPort {
 export interface GitPort {
   revParse(...args: readonly string[]): Promise<string>;
   showToplevel(): Promise<string>;
+  workspaceSnapshot?(workspaceRoot: string): Promise<WorkspaceSnapshot>;
 }
 
+export type WorkspaceSnapshot = Readonly<{
+  version: "kibi.workspace-snapshot.v1";
+  hash: string;
+  dirty: boolean;
+  fileCount: number;
+}>;
+
 export interface NetworkPort {
   fetch(input: string | URL, init?: RequestInit): Promise<Response>;
 }

package/src/public/operations/specs/check.ts

@@ -5,7 +5,7 @@ export const checkSpec = {
   name: "kb_check",
   cliName: "check",
   description:
-    "Run KB validation rules and return violations. Use before or after mutations, and after meaningful source edits with impact options to surface symbol granularity and semantic-review diagnostics. Do not use for point lookups. No write side effects. Prefer explicit rules for faster iteration; omit rules for final full validation plus full-KB qualityDiagnostics review.",
+    "Run KB validation rules and return violations. Use before or after mutations, and after meaningful source edits with impact options to surface symbol granularity and semantic-review diagnostics. Do not use for point lookups. No write side effects. Prefer explicit rules for faster iteration; omit rules for final full validation plus full-KB qualityDiagnostics review, including telemetry acceptance when .kb/usage.log exists.",
   businessInputSchema: {
     type: "object",
     properties: {
@@ -33,7 +33,7 @@ export const checkSpec = {
           ],
         },
         description:
-          "Optional rule subset. Allowed: must-priority-coverage, symbol-coverage, symbol-traceability, no-dangling-refs, no-cycles, required-fields, deprecated-adr-no-successor, domain-contradictions, strict-fact-shape, strict-req-fact-pairing, predicate-verifiability, logic-coverage, rule-safety, rule-verifiability, semantic-completeness, query-plan-safety. If omitted, server runs all rules plus the full-KB qualityDiagnostics audit scan; if supplied, server preserves scoped validation and skips the full-KB advisory scan.",
+          "Optional rule subset. Allowed: must-priority-coverage, symbol-coverage, symbol-traceability, no-dangling-refs, no-cycles, required-fields, deprecated-adr-no-successor, domain-contradictions, strict-fact-shape, strict-req-fact-pairing, predicate-verifiability, logic-coverage, rule-safety, rule-verifiability, semantic-completeness, query-plan-safety. If omitted, server runs all rules plus the full-KB qualityDiagnostics audit scan, including usage telemetry acceptance when evidence exists; if supplied, server preserves scoped validation and skips the full-KB advisory scan.",
       },
       sourceFiles: {
         type: "array",

package/src/public/operations/specs/discovery.ts

@@ -118,7 +118,7 @@ export const statusSpec = {
   name: "kb_status",
   cliName: "status",
   description:
-    "Report current branch, snapshot, and freshness metadata for the attached KB. Read-only status inspection with no mutation side effects.",
+    "Report current branch, KB snapshot and freshness metadata, plus the deterministic workspace snapshot used to validate execution receipts. Read-only status inspection with no mutation side effects.",
   businessInputSchema: { type: "object", properties: {} },
   requiresProlog: true,
   effects: ["kb-read", "workspace-read"],

package/src/public/operations/specs/modeling.ts

@@ -109,7 +109,7 @@ export const suggestPredicatesSpec = {
   name: "kb_suggest_predicates",
   cliName: "suggest-predicates",
   description:
-    "Suggest ontology predicate schemas for prose requirements before agents write facts. Read-only guidance returns ranked candidates, a safe predicate-fact applyPlan, a separate requires_predicate relationshipPlan when a requirement ID is supplied, or an explicit ontology-gap observation when no predicate fits.",
+    "Suggest ontology predicate schemas for prose requirements before agents write facts. Read-only guidance returns ranked candidates, an applicable predicate-fact plan only when every ordered argument is bound, a separate requires_predicate relationship plan when a requirement ID is supplied, or an explicit ontology-gap observation when no predicate fits.",
   businessInputSchema: {
     type: "object",
     required: ["text"],
@@ -156,6 +156,24 @@ export const suggestPredicatesSpec = {
         description:
           "Whether to include existing KB fact_kind=predicate_schema facts alongside Kibi's built-in predicate catalog. Default: true.",
       },
+      schemaId: {
+        type: "string",
+        minLength: 1,
+        description:
+          "Optional exact reviewed predicate schema ID. When supplied, Kibi selects that schema instead of lexical rank order and fails closed if it is unavailable.",
+      },
+      argumentBindings: {
+        type: "object",
+        additionalProperties: { type: "string", minLength: 1 },
+        description:
+          "Optional exact predicate argument values keyed by a candidate schema's argument_names. Required before applying a candidate whose binding_status is incomplete; Kibi never substitutes guessed values for unbound arguments.",
+      },
+      polarityHint: {
+        type: "string",
+        enum: ["assert", "deny"],
+        description:
+          "Optional reviewed polarity override for claims whose surface negation does not express predicate denial. Use only after reviewing the selected schema and full claim scope.",
+      },
       existingLogicClaims: {
         type: "array",
         items: { type: "string", pattern: "^CLAIM-[A-F0-9]{16}$" },

package/src/public/operations/specs/mutation-schemas.ts

@@ -1,3 +1,5 @@
+import { VERIFICATION_RECEIPT_SCHEMA } from "../../verification-receipt.js";
+
 export const ENTITY_TYPES = [
   "req",
   "scenario",
@@ -67,6 +69,11 @@ export const ENTITY_PROPERTIES_SCHEMA = {
       description:
         "Optional text anchor/reference. Example: 'requirements.md#L40'.",
     },
+    semantic_text: {
+      type: "string",
+      description:
+        "Requirement-only authored prose used for semantic inventory hashes and UTF-8 spans. Keep text_ref available for independent document or code evidence.",
+    },
     logic_claims: {
       type: "array",
       minItems: 1,
@@ -75,6 +82,31 @@ export const ENTITY_PROPERTIES_SCHEMA = {
       description:
         "Requirement-only manifest of every atomic normative claim key returned by kb_semantic_advisor. A requirement is logic-complete only when every key is grounded by a linked property_value or predicate fact with the same claim_key.",
     },
+    semantic_clauses: {
+      type: "array",
+      minItems: 1,
+      items: { type: "string", minLength: 1 },
+      description:
+        "Optional complete atomic decomposition used by kb_semantic_advisor and proposition-complete ingestion. Preserve it when automatic sentence splitting needs a reviewed override.",
+    },
+    semantic_inventory_version: {
+      type: "string",
+      const: "kibi.semantic-inventory.v1",
+      description:
+        "Requirement-only proposition ledger contract version returned by kb_semantic_advisor.",
+    },
+    semantic_source_field: {
+      type: "string",
+      enum: ["semantic_text", "text_ref", "title"],
+      description:
+        "Requirement field whose exact UTF-8 bytes anchor semantic_inventory spans.",
+    },
+    semantic_source_hash: {
+      type: "string",
+      pattern: "^[a-f0-9]{64}$",
+      description:
+        "SHA-256 of the exact semantic source text returned in the advisor inventory contract.",
+    },
     sourceFile: {
       type: "string",
       description:
@@ -116,6 +148,13 @@ export const ENTITY_PROPERTIES_SCHEMA = {
       description:
         "Optional typed verification perspective for test entities. Example: 'consumer'.",
     },
+    verification_receipts: {
+      type: "array",
+      maxItems: 50,
+      items: VERIFICATION_RECEIPT_SCHEMA,
+      description:
+        "Append-only test execution evidence. Proof accepts only the newest valid passed receipt bound to the current code snapshot and within the seven-day freshness window.",
+    },
     fact_kind: {
       type: "string",
       enum: [
@@ -276,7 +315,14 @@ export const ENTITY_PROPERTIES_SCHEMA = {
     claim_span_start: { type: "integer", minimum: 0 },
     claim_span_end: { type: "integer", minimum: 0 },
   },
-  allOf: [CLAIM_PROVENANCE_CONDITIONAL],
+  allOf: [
+    CLAIM_PROVENANCE_CONDITIONAL,
+    {
+      if: { required: ["verification_receipts"] },
+      // biome-ignore lint/suspicious/noThenProperty: JSON Schema conditional keyword.
+      then: { required: ["verification_scope"] },
+    },
+  ],
   required: ["title", "status"],
 } as const;
 

package/src/public/operations/specs/reporting.ts

@@ -1,10 +1,17 @@
+import { VERIFICATION_RECEIPT_MAX_AGE_SECONDS } from "../../verification-receipt.js";
+import {
+  type LegacyMigrationPlan,
+  buildLegacyMigrationPlanFromContext,
+} from "../legacy-migration-plan.js";
 import {
   runOperationJsonQuery,
   toPrologAtom,
   toPrologList,
 } from "../prolog-json.js";
+import { type RepairPlan, buildRepairPlan } from "../repair-plan.js";
 import type { OperationContext } from "../runtime-types.js";
 import type { OperationResult, OperationSpec } from "../types.js";
+import { readWorkspaceSnapshot } from "../workspace-snapshot.js";
 
 const ENTITY_TYPES = [
   "req",
@@ -41,11 +48,18 @@ export type CoverageInput = {
   readonly includeTransitive?: boolean;
   readonly limit?: number;
   readonly offset?: number;
+  readonly includeMigrationPreview?: boolean;
+  readonly migrationLimit?: number;
+  readonly migrationOffset?: number;
+  readonly migrationPredicateLimit?: number;
+  readonly migrationPredicateMinScore?: number;
 };
 
 export type CoveragePayload = {
   readonly summary: Readonly<Record<string, number>>;
   readonly rows: readonly Readonly<Record<string, unknown>>[];
+  readonly repairPlan?: RepairPlan;
+  readonly legacyMigrationPlan?: LegacyMigrationPlan;
   readonly meta?: Readonly<Record<string, unknown>>;
 };
 
@@ -142,22 +156,57 @@ export async function executeCoverage(
   context: OperationContext,
 ): Promise<OperationResult<CoveragePayload>> {
   try {
+    const snapshotEvidence = await readWorkspaceSnapshot(context);
+    const codeSnapshot = snapshotEvidence.available
+      ? snapshotEvidence.snapshot.hash
+      : "unknown";
+    const checkedAt = context.clock().toISOString();
     const payload = await runOperationJsonQuery<CoveragePayload>(
       requireProlog(context),
       "discovery.pl",
-      `discovery:coverage_report_json('${input.by ?? "req"}', ${toPrologList(input.tags)}, ${input.includePassing ?? false}, ${input.includeTransitive ?? true}, ${input.limit ?? 100}, ${input.offset ?? 0}, JsonString)`,
+      `discovery:coverage_report_json('${input.by ?? "req"}', ${toPrologList(input.tags)}, ${input.includePassing ?? false}, ${input.includeTransitive ?? true}, ${input.limit ?? 100}, ${input.offset ?? 0}, ${toPrologAtom(codeSnapshot)}, ${toPrologAtom(checkedAt)}, ${VERIFICATION_RECEIPT_MAX_AGE_SECONDS}, JsonString)`,
       "Coverage execution",
     );
-    const fullyCovered = Number(payload.summary?.fullyCovered ?? 0);
-    const total = Number(payload.summary?.total ?? 0);
+    const repairPlan = buildRepairPlan(payload, input, codeSnapshot);
+    const legacyMigrationPlan =
+      input.includeMigrationPreview === true && repairPlan !== undefined
+        ? await buildLegacyMigrationPlanFromContext(
+            repairPlan,
+            input,
+            codeSnapshot,
+            context,
+          )
+        : undefined;
+    const enrichedPayload = {
+      ...payload,
+      ...(repairPlan !== undefined ? { repairPlan } : {}),
+      ...(legacyMigrationPlan !== undefined ? { legacyMigrationPlan } : {}),
+      meta: {
+        ...(payload.meta ?? {}),
+        verificationReceiptMaxAgeSeconds: VERIFICATION_RECEIPT_MAX_AGE_SECONDS,
+        verificationSnapshot: codeSnapshot,
+        verificationSnapshotAvailable: snapshotEvidence.available,
+        ...(snapshotEvidence.available
+          ? {
+              verificationSnapshotDirty: snapshotEvidence.snapshot.dirty,
+              verificationSnapshotFileCount:
+                snapshotEvidence.snapshot.fileCount,
+              verificationSnapshotVersion: snapshotEvidence.snapshot.version,
+            }
+          : { verificationSnapshotError: snapshotEvidence.error }),
+      },
+    };
+    const fullyCovered = Number(enrichedPayload.summary?.fullyCovered ?? 0);
+    const proofProven = Number(enrichedPayload.summary?.proofProven ?? 0);
+    const total = Number(enrichedPayload.summary?.total ?? 0);
     return {
       content: [
         {
           type: "text",
-          text: `Coverage summary: ${fullyCovered} fully covered out of ${total}.`,
+          text: `Coverage summary: ${fullyCovered} structurally covered and ${proofProven} proven out of ${total}.`,
         },
       ],
-      structuredContent: payload,
+      structuredContent: enrichedPayload,
     };
   } catch (error) {
     const message = error instanceof Error ? error.message : String(error);
@@ -169,7 +218,7 @@ export const coverageSpec = {
   name: "kb_coverage",
   cliName: "coverage",
   description:
-    "Generate curated coverage reports for requirements, symbols, or grouped types. Read-only reporting with no mutation side effects.",
+    "Generate curated structural coverage and conservative end-to-end requirement proof reports for requirements, symbols, or grouped types. Requirement reports include a deterministic, dependency-ordered, read-only repair plan; optional legacy migration previews reconstruct authored proposition inventories and rank exact schema candidates without producing executable writes. Paginated plans identify incomplete scope. Requirement rows keep coverageStatus separate from proofStatus and require fresh snapshot-bound E2E receipts before proof. No mutation side effects.",
   businessInputSchema: {
     type: "object",
     properties: {
@@ -179,6 +228,42 @@ export const coverageSpec = {
       includeTransitive: { type: "boolean", default: true },
       limit: { type: "integer", default: 100 },
       offset: { type: "integer", default: 0 },
+      includeMigrationPreview: {
+        type: "boolean",
+        default: false,
+        description:
+          "Opt in to a deterministic, read-only kibi.legacy-migration-plan.v1 preview for ready semantic-inventory repair batches.",
+      },
+      migrationLimit: {
+        type: "integer",
+        minimum: 1,
+        maximum: 10,
+        default: 1,
+        description:
+          "Maximum requirement migration batches to preview. Defaults to one review batch.",
+      },
+      migrationOffset: {
+        type: "integer",
+        minimum: 0,
+        default: 0,
+        description: "Zero-based offset into ready semantic-inventory batches.",
+      },
+      migrationPredicateLimit: {
+        type: "integer",
+        minimum: 1,
+        maximum: 20,
+        default: 5,
+        description:
+          "Maximum exact predicate-schema candidates retained per assertive proposition.",
+      },
+      migrationPredicateMinScore: {
+        type: "number",
+        minimum: 0,
+        maximum: 1,
+        default: 0.35,
+        description:
+          "Minimum deterministic predicate-schema rank score retained in migration previews.",
+      },
     },
   },
   requiresProlog: true,

package/src/public/operations/specs/semantic.ts

@@ -39,7 +39,7 @@ export async function executeSemanticAdvisor(
         title,
         status: optionalString(args.status) ?? "open",
         source,
-        text_ref: text,
+        semantic_text: text,
       },
     },
     ...(args.clauses !== undefined ? { clauses: args.clauses } : {}),

package/src/public/operations/workspace-snapshot.ts

@@ -0,0 +1,28 @@
+import type { OperationContext, WorkspaceSnapshot } from "./runtime-types.js";
+
+export type WorkspaceSnapshotEvidence =
+  | Readonly<{ available: true; snapshot: WorkspaceSnapshot }>
+  | Readonly<{ available: false; error: string }>;
+
+export async function readWorkspaceSnapshot(
+  context: OperationContext,
+): Promise<WorkspaceSnapshotEvidence> {
+  if (!context.git?.workspaceSnapshot) {
+    return {
+      available: false,
+      error:
+        "The active operation runtime does not expose workspace snapshots.",
+    };
+  }
+  try {
+    return {
+      available: true,
+      snapshot: await context.git.workspaceSnapshot(context.workspaceRoot),
+    };
+  } catch (error) {
+    return {
+      available: false,
+      error: error instanceof Error ? error.message : String(error),
+    };
+  }
+}

package/src/public/schemas/entity.ts

@@ -18,6 +18,7 @@
 
 // Typed fact field enums per proposal
 import { SYMBOL_ROLES, type SymbolRole } from "../symbol-granularity.js";
+import { VERIFICATION_RECEIPT_SCHEMA } from "../verification-receipt.js";
 
 type FactKind =
   | "subject"
@@ -355,12 +356,34 @@ const entitySchema: Record<string, unknown> = {
     severity: { type: "string" },
     links: { type: "array", items: { type: "string" } },
     text_ref: { type: "string" },
+    semantic_text: {
+      type: "string",
+      description:
+        "Requirement-only authored prose whose exact UTF-8 bytes anchor the semantic inventory without replacing text_ref evidence.",
+    },
     logic_claims: {
       type: "array",
       minItems: 1,
       uniqueItems: true,
       items: { type: "string", pattern: "^CLAIM-[A-F0-9]{16}$" },
     },
+    semantic_clauses: {
+      type: "array",
+      minItems: 1,
+      items: { type: "string", minLength: 1 },
+    },
+    semantic_inventory_version: {
+      type: "string",
+      const: "kibi.semantic-inventory.v1",
+    },
+    semantic_source_field: {
+      type: "string",
+      enum: ["semantic_text", "text_ref", "title"],
+    },
+    semantic_source_hash: {
+      type: "string",
+      pattern: "^[a-f0-9]{64}$",
+    },
     semantic_inventory: {
       type: "array",
       items: {
@@ -430,6 +453,11 @@ const entitySchema: Record<string, unknown> = {
       type: "string",
       enum: ["internal", "consumer"] satisfies VerificationPerspective[],
     },
+    verification_receipts: {
+      type: "array",
+      maxItems: 50,
+      items: VERIFICATION_RECEIPT_SCHEMA,
+    },
     type: {
       type: "string",
       enum: [
@@ -569,16 +597,31 @@ const entitySchema: Record<string, unknown> = {
           anyOf: [
             { required: ["verification_scope"] },
             { required: ["verification_perspective"] },
+            { required: ["verification_receipts"] },
           ],
         },
       },
     },
+    {
+      if: { required: ["verification_receipts"] },
+      // biome-ignore lint/suspicious/noThenProperty: JSON Schema conditional keyword.
+      then: { required: ["verification_scope"] },
+    },
     {
       if: {
         properties: { type: { const: "req" } },
       },
       else: {
-        not: { required: ["semantic_inventory"] },
+        not: {
+          anyOf: [
+            { required: ["semantic_inventory"] },
+            { required: ["semantic_clauses"] },
+            { required: ["semantic_text"] },
+            { required: ["semantic_inventory_version"] },
+            { required: ["semantic_source_field"] },
+            { required: ["semantic_source_hash"] },
+          ],
+        },
       },
     },
     ...factConditionals,

package/src/public/skills/kibi-traceability/SKILL.md

@@ -34,6 +34,7 @@ echo '{"sourceFiles":["src/auth/login.ts"],"includeImpactDiagnostics":true,"incl
 - After meaningful source edits, run `kb_check({sourceFiles:[...], includeImpactDiagnostics:true, includeWorkingTreeDiff:true})` or the equivalent `check --input` JSON recipe before deciding whether traceability is current.
 - Apply traceability updates sequentially through `kb_upsert` or `upsert --input` for requirements, scenarios, tests, facts, behavioral symbols, and source-linked relationships.
 - Validate constraints and consistency through `kb_check` or `check --input` after updates.
+- Run `kb_coverage` by requirement after validation. Treat `coverageStatus` as structural compatibility only; use the separate `proofStatus`, `proofStages`, `proofGaps`, and ranked `proofRepairs` to decide whether the complete intent-to-code chain is proven.
 - Use `kb_delete` or `delete --input` only for explicit cleanup of obsolete records or relationships.
 
 ## Guidance
@@ -42,6 +43,11 @@ echo '{"sourceFiles":["src/auth/login.ts"],"includeImpactDiagnostics":true,"incl
 - Preserve source-file traceability whenever adding or changing requirements, scenarios, tests, facts, behavioral symbols, or implementation links.
 - Preserve the canonical chain `REQ-* -> SCEN-* -> TEST-*` when adding or changing requirements.
 - Production symbols should implement requirements; test symbols should remain executable evidence for tests.
+- A proof-bearing test must be reached through the requirement's scenario, declare `verification_scope: end_to_end`, and carry a fresh passed `kibi.verification-receipt.v1` bound to the live `verificationSnapshot`. Link its executable code with `executable_for`; link each production symbol with `implements` and `covered_by` to that qualifying test. Durable `status: passing` is structural metadata, not execution proof.
+- Read `kb_status` immediately before a proof-bearing run, execute the exact recorded command, then append—not replace—the receipt history with test ID, scope, runner, command, snapshot, environment hash, timestamps, outcome, and artifact digest. Re-read coverage; wrong-snapshot, stale, failed, malformed, future-dated, or unavailable evidence must remain a gap.
+- A green structural count is not proof. Do not report success while a proposition is absent or unresolved, grounding is incomplete or non-bijective, contradiction analysis is incomplete, the E2E path is direct-only, its execution receipt is not fresh for the live snapshot, or proof-bearing symbols lack current generated coordinates.
+- Use `kb_coverage.repairPlan` to turn row-local `proofRepairs` into small dependency-ordered batches. Require `scope.complete: true` before treating it as a project-wide inventory, apply only `state: ready` work, and treat every `autoApplicable: false` batch as reviewed guidance rather than an executable mutation payload. Query current endpoints, follow its validation policy, keep upserts sequential, then rerun coverage after each batch; newly visible downstream gaps supersede the older plan. Never reinterpret `no_conflict_found` as universal consistency; it only describes the modeled ground claims Kibi could inspect.
+- When `.kb/usage.log` exists, run `kibi usage-metrics --format json --require-acceptance` after the final complete coverage call. A successful graph check does not override failed or insufficient `kibi.telemetry-acceptance.v1` evidence; follow ranked telemetry diagnostics for advisor/preflight bypasses, lookup misses, stalled proof recovery, receipt freshness, or repeated mutation failures.
 - Resolve impact at behavioral-symbol granularity when Kibi reports symbol-level diagnostics; avoid treating a whole file as impacted when the report identifies narrower linked behavior.
 - Treat `symbol_semantic_review_needed` as a prompt to inspect linked requirements and tests; Kibi reports graph links but does not prove prose semantics.
 - Do not read or edit files inside `.kb` directly; all modeling and cleanup goes through the selected Kibi interface.
@@ -51,4 +57,4 @@ Public training trajectories:
 [{"taskId":"kibi-traceability-requirement-discovery-train-1","family":"requirement-discovery","reflection":"Discover the requirement linked to the supplied source symbol. This is train case 1; use only the public Kibi MCP surface."},{"taskId":"kibi-traceability-requirement-discovery-train-2","family":"requirement-discovery","reflection":"Discover the requirement linked to the supplied source symbol. This is train case 2; use only the public Kibi MCP surface."},{"taskId":"kibi-traceability-symbol-impact-granularity-train-1","family":"symbol-impact-granularity","reflection":"Resolve impact at behavioral symbol granularity rather than file granularity. This is train case 1; use only the public Kibi MCP surface."},{"taskId":"kibi-traceability-symbol-impact-granularity-train-2","family":"symbol-impact-granularity","reflection":"Resolve impact at behavioral symbol granularity rather than file granularity. This is train case 2; use only the public Kibi MCP surface."},{"taskId":"kibi-traceability-relationship-chain-train-1","family":"relationship-chain","reflection":"Trace the requirement, scenario, and test relationship chain. This is train case 1; use only the public Kibi MCP surface."},{"taskId":"kibi-traceability-relationship-chain-train-2","family":"relationship-chain","reflection":"Trace the requirement, scenario, and test relationship chain. This is train case 2; use only the public Kibi MCP surface."},{"taskId":"kibi-traceability-executable-coverage-train-1","family":"executable-coverage","reflection":"Establish executable test identity and behavioral coverage links. This is train case 1; use only the public Kibi MCP surface."},{"taskId":"kibi-traceability-executable-coverage-train-2","family":"executable-coverage","reflection":"Establish executable test identity and behavioral coverage links. This is train case 2; use only the public Kibi MCP surface."}]
 
 Previous development gate:
-{"mean":0,"hardPasses":0,"worstFamilyMean":0}
+{"mean":0,"hardPasses":0,"worstFamilyMean":0}

package/src/public/skills/kibi-usage/SKILL.md

@@ -109,6 +109,12 @@ Use `kb_semantic_advisor` with up to three typed `interpretations` for ambiguous
 
 The portable skill body must carry the core contract even when its detailed resources are unavailable: `kb_semantic_advisor` returns a `propositions[]` ledger and `semantic_inventory`; submit typed `interpretations` when wording has more than one plausible logical reading; validate modeled conditions through `kibi.logic.v1`; and preserve unresolved propositions as explicit gaps. Do not read or edit files inside `.kb` directly.
 
+Requirement proof also requires fresh execution evidence. Read the available `verificationSnapshot` from `kb_status`, run the scenario-backed E2E command, and append a `kibi.verification-receipt.v1` carrying test ID, typed scope, runner, command, snapshot, environment hash, timestamps, outcome, and artifact digest. Never rewrite receipt history or treat durable `status: passing` as execution proof; re-run coverage and repair every receipt-specific gap.
+
+Requirement-mode `kb_coverage` also returns `kibi.repair-plan.v1`. Use it only when `scope.complete` is true; a partial plan means pagination hid actionable requirements. Apply only the earliest `ready` batch for each requirement, query before mutation, create endpoints before relationships, validate every payload, and keep `kb_upsert` calls sequential. Batches are deliberately `autoApplicable: false`: semantic resolution, contradiction supersession, E2E execution, and source ownership always require review. Re-run coverage after every batch instead of continuing from a stale plan.
+
+When `.kb/usage.log` exists, treat `kibi.telemetry-acceptance.v1` as the process-evidence lane. Run `kibi usage-metrics --format json --require-acceptance` before completion and inspect unfiltered `kb_check.qualityDiagnostics[]` for ranked `category: telemetry` repairs. The rolling report requires fresh evidence for advisor-before-requirement-write, exact validation-before-upsert, source-linked lookup results, proof-gap recovery, receipt freshness, and mutation retry discipline. `insufficient_evidence` is not a pass: capture current complete coverage and diagnostic events rather than waiving stale, partial, or pre-upgrade logs. A missing usage log means diagnostic logging is not active; do not invent telemetry evidence.
+
 ## Strict Fact Lane
 
 Normative requirements that must participate in contradiction blocking use the strict fact lane. Create a `fact_kind: subject` fact and link it from the requirement via `constrains`. Create a `fact_kind: property_value` fact and link it via `requires_property`.
@@ -148,13 +154,13 @@ Readable prose is not evidence that a requirement is machine-checkable. Before t
 
 1. Call `kb_semantic_advisor` with the complete requirement prose. When the automatic split is incomplete or a sentence contains multiple obligations, pass an explicit `clauses` array containing every atomic normative clause.
 2. Use the stable `claim_key` returned for each clause. Every ground `property_value` or `predicate` fact must preserve that key in `claim_key` and preserve the clause in `claim_text`. Use the advisor-returned inventory exactly; do not add punctuation or wording variants of an existing clause.
-3. Put the complete set of keys in the requirement's `logic_claims` manifest. Merge returned keys with existing values; never overwrite earlier claims while modeling a later clause.
+3. Put exactly the current assertive proposition keys in the requirement's `logic_claims` manifest. Preserve unrelated metadata, but remove stale claim keys when the source meaning changes; never silently omit an earlier proposition that remains in the current prose.
 4. Ground each key through exactly one suitable logical lane: `requires_property` to one strict `property_value` fact, `requires_predicate` to one ground `predicate` fact, or `requires_rule` to one safe `rule` fact. A subject fact supports a strict claim but does not ground a key by itself. Observation, meta, ambiguity, and ontology-gap facts explicitly remain unresolved and do not count as logical coverage.
 5. Run `kb_check` with `logic-coverage`, `rule-safety`, `rule-verifiability`, `semantic-completeness`, `predicate-verifiability`, and `domain-contradictions`. `logic-coverage` enforces a one-claim/one-ground-fact mapping and rejects distinct claim keys that encode the same logical term; human or agent review still confirms that the atomic clauses exhaust the prose and that each ground term preserves its meaning.
 
 Kibi emits a non-blocking logical-coverage debt diagnostic for every current requirement without a manifest, independent of title wording. The `logic-coverage` rule is enabled by default for requirements that do declare manifests, so an unfiltered final check catches missing or orphaned ground claims while legacy requirements remain explicit backfill work.
 
-A complete `logic_claims` manifest alone is not a complete model. Semantic-advisor readiness remains partial until the payload has at least one distinct `requires_property`, `requires_predicate`, or `requires_rule` grounding slot per assertive claim. This count prevents one token edge from suppressing the remaining plans; only `logic-coverage` readback proves that each slot reaches the fact with the matching claim key.
+A complete `logic_claims` manifest alone is not a complete model. Preserve the advisor's `inventory_contract` as `semantic_inventory_version`, `semantic_source_field`, and `semantic_source_hash`; every ledger span must select its exact claim text from that field. For new or migrated requirements, use requirement-only `semantic_text` for normalized authored prose and keep `text_ref` available for independent code or document evidence. Legacy direct payloads may still declare `text_ref` or `title`; an explicitly declared but empty semantic source fails closed instead of falling through. Mutation rejects duplicate or omitted propositions and requires every `modeled` entry to resolve through exactly one logical edge to a fact with the same claim key. Explicit unresolved entries remain ingestible but cannot prove the requirement.
 
 Never invent, reuse across different clauses, or manually alter a claim key. Kibi derives it from `claim_text` and rejects mismatched mutation and Markdown inputs.
 
@@ -181,7 +187,7 @@ Preserve the readable requirement prose. Facts add a machine-queryable model; th
 
 1. Call `kb_semantic_advisor` on the complete prose, verify its atomic clause inventory, and choose one lane per clause.
 2. For each relational clause, call `kb_suggest_predicates` with that clause and the current `existingLogicClaims`. Read each candidate as a Prolog-shaped ground term `predicate_name(arg1,...,argN)`: the schema fixes the predicate name, arity, argument roles, and argument order.
-3. Accept a candidate only when its meaning and every ordered argument fit the prose. Use the returned `applyPlan`, including its exact `predicate_name`, `predicate_args`, `canonical_key`, and `polarity`; never invent a predicate name, reorder arguments, add variables, or write a raw Prolog clause.
+3. Accept a candidate only when its meaning and every ordered argument fit the prose. If lexical rank order prefers a false positive, retry with the reviewed candidate's exact `schema.id` as `schemaId`; do not mutate the candidate or treat a missing schema reference as an ontology gap. If it returns `binding_status: incomplete`, retry with exact `argumentBindings` for every `unbound_arguments` name; its empty `applyPlan` is a safety gate, and the literal `unknown` must never be persisted. Use `polarityHint` only when review of the complete claim proves that surface negation does not deny the selected predicate. Once complete, use the returned `applyPlan`, including its exact `predicate_name`, `predicate_args`, `canonical_key`, and `polarity`; never invent a predicate name, reorder arguments, add variables, or write a raw Prolog clause.
 4. Create or confirm the requirement and `fact_kind: predicate` endpoints, preserve `claim_key` and `claim_text`, merge the returned `logicClaims` into the requirement, then link requirement -> predicate fact with `requires_predicate`. Treat the requirement's logical representation as the conjunction of every linked ground term. Encode a prohibition with `polarity: deny` on the fitting positive schema, not a made-up negative predicate. An `assert` and `deny` requirement over the same namespace, name, and ordered arguments are a blocking `domain-contradictions` conflict, so requirements must reuse the same canonical schema and argument vocabulary for equivalent domain claims.
 5. Use an existing built-in or project-local `fact_kind: predicate_schema`. Create a new schema only when the task explicitly authorizes ontology extension and supplies a stable name, arity, `argument_names`, and `argument_types`; otherwise record `fact_kind: observation` with `review:ontology-gap`.
 6. For each scalar, threshold, duration, boolean, enum-set, or cardinality clause, use `kb_model_requirement` with the current `existingLogicClaims` and the strict subject/property lane instead. For ambiguity or a lexical false positive, preserve the prose as a review observation, apply its returned `relates_to` review anchor when present, and report the requirement as logically incomplete. Use `review:ambiguity` for unresolved scope or interpretation and `review:keyword-false-positive` when a vocabulary match is not a domain assertion.
@@ -264,7 +270,7 @@ Call `kb_status` when branch KB context may be stale or after switching context.
 | Tags as multi-ID lookup | Tags are metadata, not identifiers | Use `kb_query` with explicit `id` values |
 | `relates_to` for strict modeling | Loses contradiction safety | Use `constrains` and `requires_property` instead |
 | One fact for a compound requirement | Leaves untracked prose outside contradiction checks | Decompose all atomic clauses, preserve claim keys, and validate `logic_claims` with `logic-coverage` |
-| Replacing `logic_claims` on each call | Discards previously grounded clauses | Pass existing keys and merge the returned manifest |
+| Keeping stale `logic_claims` after prose changes | Makes the manifest disagree with the source ledger | Replace it atomically with exactly the current assertive keys while preserving unrelated metadata |
 | Observation counted as coverage | Ambiguity or ontology gaps appear machine-checkable | Keep the claim unresolved until a strict or predicate ground fact exists |
 | Relationship type used as predicate name | Confuses graph edges with ontology terms | Select a declared predicate schema and keep `requires_predicate` as the req -> fact edge |
 | `status: implemented` on requirements | Not a valid lifecycle status | Use a valid status such as `closed`, add an `implemented` tag, and link evidence instead |

package/src/public/skills/kibi-usage/resources/fact-lanes.md

@@ -7,7 +7,7 @@ Requirement prose remains the human-readable source. Facts add queryable semanti
 Logical coverage is clause-based, not entity-based. Give `kb_semantic_advisor` the complete requirement body and verify that its `clauses` list contains every atomic obligation. Supply the `clauses` input yourself when automatic splitting would combine or omit obligations. For every normative clause:
 
 - preserve the returned stable key as `claim_key` and the exact clause as `claim_text` on its ground fact;
-- add the key to the requirement `logic_claims` manifest without removing existing keys;
+- add the key to the exact current `logic_claims` set, removing only stale keys whose propositions no longer exist in the source;
 - link it through exactly one `requires_property` for `property_value`, one `requires_predicate` for `predicate`, or one `requires_rule` for a safe `rule` fact;
 - leave ambiguity and ontology gaps visibly unresolved—observations do not satisfy `logic-coverage`.
 

package/src/public/skills/kibi-usage/resources/logic-ir.md

@@ -36,7 +36,7 @@ Example (inspection data, not executable input):
 }
 ```
 
-Use `rule_schema` facts for stable predicate signatures and link a requirement to a `rule` fact with `requires_rule`. Keep `logic_claims` for backward-compatible ground claim manifests; `semantic_inventory` is the complete proposition ledger. A manifest is not proof until each key is linked to exactly one intended fact and the rule checks pass.
+Use `rule_schema` facts for stable predicate signatures and link a requirement to a `rule` fact with `requires_rule`. Keep `logic_claims` as the exact current assertive key set; `semantic_inventory` is the complete proposition ledger, anchored by `semantic_inventory_version`, `semantic_source_field`, and `semantic_source_hash`. Prefer requirement-only `semantic_text` as the semantic source for normalized authored prose so `text_ref` can remain independent code or document evidence; retain `text_ref` and `title` only as legacy semantic-source choices. A manifest is not proof until each modeled key is linked to exactly one same-key fact and the rule checks pass.
 
 ## Contradictions and uncertainty
 

package/src/public/skills/kibi-usage/resources/workflows.md

@@ -13,9 +13,16 @@ The canonical workflow for any KB operation follows this pattern:
 7. **Create endpoints**: validated `kb_upsert` for new entities, sequentially
 8. **Link**: validated `kb_upsert` with `requires_rule`, `requires_predicate`, `constrains`, or `requires_property`, sequentially
 9. **Validate coverage and consistency**: targeted `rule-safety`, `rule-verifiability`, `semantic-completeness`, `logic-coverage`, `predicate-verifiability`, and `domain-contradictions`, then final full `kb_check`
+10. **Prove execution**: read `kb_status.verificationSnapshot`, run each scenario-backed E2E command, append its `kibi.verification-receipt.v1`, and re-run `kb_coverage`; never promote durable test status into fresh evidence
+11. **Repair incrementally**: require `kb_coverage.repairPlan.scope.complete`, apply only one `ready` dependency batch per requirement, validate before every sequential write, and rerun coverage before selecting the next batch
+12. **Gate workflow evidence**: when `.kb/usage.log` exists, run `kibi usage-metrics --format json --require-acceptance`; repair ranked telemetry diagnostics and never treat stale or insufficient evidence as a pass
 
 Every current requirement without `logic_claims` remains visible as non-blocking backfill debt. Once a manifest and `semantic_inventory` exist, the unfiltered check enforces correspondence to linked ground facts/rules and rejects silently missing assertive propositions.
 
+`kibi.repair-plan.v1` is a deterministic read-only plan, not a mutation script. Its phase order keeps source and proposition analysis ahead of ground endpoints, endpoints ahead of manifests/links, logic ahead of contradictions, scenarios ahead of tests and receipts, and production ownership ahead of coverage and coordinate refresh. A `blocked` batch is waiting on every listed `dependsOn` batch. If pagination makes the plan partial, increase the requirement coverage limit rather than applying an incomplete project view.
+
+`kibi.telemetry-acceptance.v1` evaluates the latest 200 usage events and keeps process health separate from graph correctness. It requires at least 95% complete diagnostic telemetry and, when applicable, exact recent validation before every upsert and a same-requirement/current-hash advisor pass before requirement writes. It also evaluates source lookup misses, comparable complete-scope proof-gap recovery, receipt-specific coverage gaps, and mutation targets retried three or more times. Failed metrics become ranked `category: telemetry` quality diagnostics; missing current coverage fields or evidence older than seven days stays `insufficient_evidence`.
+
 ## Creating a New Feature
 ```
 1. kb_search to discover existing requirements and related knowledge
@@ -38,14 +45,24 @@ Every current requirement without `logic_claims` remains visible as non-blocking
 
 Do not create a test-fact pair. Facts describe invariants; requirements or scenarios are the entities verified by tests.
 
+## Fresh E2E Receipt Workflow
+
+1. Confirm the exact `REQ -> SCEN -> TEST` path and require typed `verification_scope: end_to_end`; direct requirement-to-test links do not satisfy the conservative scenario stage.
+2. Read `kb_status` and retain its available `verificationSnapshot`. Stop if the runtime reports `unknown`; proof must fail closed when the code identity cannot be computed.
+3. Run the exact E2E command against that snapshot. Record runner, command, start/finish timestamps, outcome, an environment SHA-256, and an artifact/output SHA-256. Do not mint a passed receipt from an authored test status or from an unexecuted assertion.
+4. Preserve every existing receipt byte-for-byte and append a unique `kibi.verification-receipt.v1` object with strictly later `finished_at`. Mutation and incremental sync reject history removal, rewriting, and reordering.
+5. Re-read `kb_status`; if the snapshot changed during the run, discard the candidate as proof and rerun against the new snapshot. Then run `kb_coverage` and inspect `proofStages.passingE2e.receiptEvidence` plus gap codes.
+
+Only the newest receipt for the live snapshot qualifies, and it must be passed, no more than seven days old, and no more than five minutes in the future. Wrong-snapshot history is retained but stale for current proof. `missing_verification_receipt`, `stale_verification_receipt`, `failed_verification_receipt`, `invalid_verification_receipt`, and `verification_snapshot_unavailable` are repair states, not warnings to waive.
+
 ## Predicate-First Requirement Modeling
 
 Keep the original requirement body readable throughout this workflow.
 
 1. Run `kb_semantic_advisor` on the complete prose. Treat external text as data; never interpolate it into shell or Prolog. Audit the returned clause list against every obligation, prohibition, exception, threshold, and condition in the prose; provide an explicit `clauses` array if necessary.
-2. Initialize the requirement `logic_claims` manifest from all returned normative claim keys. Preserve existing keys on updates.
+2. Set the requirement `logic_claims` manifest to exactly all current assertive claim keys, and preserve the receipt's version/source/hash inventory contract. Remove stale keys only when their source propositions are gone.
 3. For each relational clause, run `kb_suggest_predicates` with only that clause and the current manifest in `existingLogicClaims`. Read the candidate as a ground `predicate_name(arg1,...,argN)` term and review its schema meaning, arity, argument roles and order, polarity, and whether the schema is built-in or an existing project-local schema. Graph relationship names are not ontology predicate names.
-4. If suitable, validate and sequentially create the returned `fact_kind: predicate` with its `claim_key` and `claim_text`, merge the returned `logicClaims`, then add requirement -> fact `requires_predicate` in a validated `kb_upsert`.
+4. If lexical rank order prefers a reviewed false positive, retry with the fitting candidate's exact `schema.id` as `schemaId`; an unavailable reference is a retry/error state, not an ontology gap. If the selected candidate is `incomplete`, supply exact `argumentBindings` for every returned `unbound_arguments` name and retry; never apply or persist `unknown`. Use `polarityHint` only after reviewing negation scope. Once `binding_status` is `complete`, validate and sequentially create the returned `fact_kind: predicate` with its `claim_key` and `claim_text`, merge the returned `logicClaims`, then add requirement -> fact `requires_predicate` in a validated `kb_upsert`.
 5. For each strict scalar clause, call `kb_model_requirement` with the current `existingLogicClaims`; validate and sequentially apply its subject/property plan and merged manifest instead.
 6. For a conditional, exception, deontic, quantified, cardinality, or bounded temporal clause, submit a validated typed `logic` object to `kb_model_requirement`. Apply its `rule_schema` and `rule` facts sequentially and link the requirement with `requires_rule`; rendered Prolog is for inspection only.
 7. If wording is ambiguous, a candidate is only a lexical false positive, or no schema/IR interpretation fits, create the advised observation review artifact and apply its returned `relates_to` review anchor when present; report that claim key as unresolved. Use `review:ambiguity` for unresolved interpretation, `review:keyword-false-positive` for a vocabulary match that is not a domain assertion, and `review:ontology-gap` only for a true catalog gap. Define a new `predicate_schema` only when the task explicitly authorizes ontology extension and provides a stable signature.