kibi-cli 2.31.1 → 2.35.1

package/dist/public/schemas/entity.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"entity.d.ts","sourceRoot":"","sources":["../../../src/public/schemas/entity.ts"],"names":[],"mappings":"AAwTA,QAAA,MAAM,YAAY,EAAE,MAAM,CAAC,MAAM,EAAE,OAAO,CAwazC,CAAC;AAEF,eAAe,YAAY,CAAC"}
+{"version":3,"file":"entity.d.ts","sourceRoot":"","sources":["../../../src/public/schemas/entity.ts"],"names":[],"mappings":"AAmUA,QAAA,MAAM,YAAY,EAAE,MAAM,CAAC,MAAM,EAAE,OAAO,CA6czC,CAAC;AAEF,eAAe,YAAY,CAAC"}

package/dist/public/schemas/entity.js

@@ -16,6 +16,7 @@
  along with this program.  If not, see <https://www.gnu.org/licenses/>.
  */
 import { ENTITY_ORIGIN_SCHEMA } from "../entity-origin.js";
+import { EVIDENCE_LEVELS } from "../evidence-levels.js";
 import { PROOF_BINDINGS_SCHEMA, PROOF_CONTRACT_SCHEMA, } from "../proof-protocol.js";
 import { PROOF_RECEIPT_SCHEMA } from "../proof-receipt.js";
 // Typed fact field enums per proposal
@@ -338,6 +339,11 @@ const entitySchema = {
             enum: ["firm", "default", "exploratory"],
             description: "Requirement and ADR only. How firmly the decision was made. firm: a human stated it as a rule; it needs a ref (origin.ref, or approval_ref on a requirement) to their words, and only a human may change it. default: a delegated or agent choice; a later agent may supersede it with evidence. exploratory: a flagged guess, expected to be revisited. When absent, it reads as default if an agent wrote the entity (origin.kind agent) and as firm otherwise (a person's, imported or migrated decision); set it explicitly when recording a decision.",
         },
+        required_evidence: {
+            type: "string",
+            enum: [...EVIDENCE_LEVELS],
+            description: "Requirement-only. The weakest evidence level this current requirement accepts; the evidence-floor check rule fails while its computed evidence level is lower. proved: a re-checkable certificate covers every case. tested: fresh passing E2E receipts cover every linked scenario. asserted: a person stands behind it. unverified: no floor. When absent, it is tested for a firm requirement and unverified otherwise.",
+        },
         expects: {
             type: "string",
             enum: ["success", "rejection", "error"],
@@ -508,9 +514,38 @@ const entitySchema = {
         },
         subject_key: { type: "string" },
         property_key: { type: "string" },
-        operator: { type: "string", enum: ["eq", "neq", "lt", "lte", "gt", "gte"] },
-        value_type: { type: "string", enum: ["string", "int", "number", "bool"] },
+        // matches: value_string is a JavaScript regular expression (u flag) the
+        // property's values match as a whole; only string facts use it.
+        // includes: every member of value_set has the property (the members
+        // that have it include the set); subset_of: every member that has the
+        // property is in value_set; excludes: no member of value_set has it.
+        // Only set facts use these three.
+        operator: {
+            type: "string",
+            enum: [
+                "eq",
+                "neq",
+                "lt",
+                "lte",
+                "gt",
+                "gte",
+                "matches",
+                "includes",
+                "subset_of",
+                "excludes",
+            ],
+        },
+        value_type: {
+            type: "string",
+            enum: ["string", "int", "number", "bool", "set"],
+        },
         value_string: { type: "string" },
+        value_set: {
+            type: "array",
+            items: { type: "string", minLength: 1 },
+            minItems: 1,
+            uniqueItems: true,
+        },
         value_int: { type: "integer" },
         value_number: { type: "number" },
         value_bool: { type: "boolean" },
@@ -609,6 +644,7 @@ const entitySchema = {
                         { required: ["value_int"] },
                         { required: ["value_number"] },
                         { required: ["value_bool"] },
+                        { required: ["value_set"] },
                         { required: ["unit"] },
                         { required: ["scope"] },
                         { required: ["polarity"] },
@@ -681,6 +717,7 @@ const entitySchema = {
                         { required: ["approval_ref"] },
                         { required: ["rationale"] },
                         { required: ["exempts_claims"] },
+                        { required: ["required_evidence"] },
                     ],
                 },
             },

package/dist/public/skills/kibi-bootstrap/SKILL.md

@@ -2,7 +2,7 @@
 id: kibi-bootstrap
 name: kibi-bootstrap
 description: "Use for any Kibi bootstrap or onboarding task: seeding a new or thin knowledge base; reviewing a bootstrap or onboarding plan, preview, or evidence; judging approval readiness or coverage; diagnosing a blocked, partial, or failed bootstrap or its repair; applying an approved bootstrap plan; or asking the human which knowledge sources hold intent. Covers kb_status first, source interview, cited intent claims, read-only kb_plan_bootstrap preview, explicit approval, exact-plan kb_apply_plan, and repair-safe close-out."
-version: 3.16.0
+version: 3.17.0
 kibiCompatibility: ">=1.0.0"
 tags:
   - kibi
@@ -43,7 +43,7 @@ Seed branch-local Kibi knowledge from cited product intent, without creating a p
 9. **Read back** with `kb_query` and `kb_search` to confirm writes and citations.
 10. **Close out** with `kb_check`, then `kb_status`.
 11. **Deepen.** Bootstrap is complete; the KB is now half-way, holding cited `req` entries and review facts but no scenarios, tests or predicates. Load `kibi-usage` and continue in the normal Kibi workflow, one area at a time, telling the human what you author:
-    - **Unplanned claims.** For every claim suppressed as `invalid_write` and every `sourceOnlySignals` entry ("Author requirement …"), restate the claim's statement and citation (`sourceId:reference`), model it with `kb_model` (`mode: "requirement"`, or `mode: "predicates"` for domain claims), and write the result with `kb_upsert` (`dryRun: true` first) with `origin: {kind: "import", ref: "<sourceId:reference>"}` and `firmness: "firm"`, as the plan does for the claims it writes. Without an explicit origin `kb_upsert` records the requirement as the agent's own `default` choice, which a later agent may supersede without asking.
+    - **Unplanned claims.** For every claim suppressed as `invalid_write` and every `sourceOnlySignals` entry ("Author requirement …"), restate the claim's statement and citation (`sourceId:reference`), model it with `kb_model` (`mode: "requirement"`, or `mode: "predicates"` for domain claims), and write the result with `kb_upsert` (`dryRun: true` first) with `origin: {kind: "import", ref: "<sourceId:reference>"}` and `firmness: "firm"` and `required_evidence: "asserted"`, as the plan does for the claims it writes; raise the floor (drop `required_evidence`) only once an end-to-end proof covers the requirement. Without an explicit origin `kb_upsert` records the requirement as the agent's own `default` choice, which a later agent may supersede without asking.
     - **Scenarios.** Write scenarios from the cited ticket's acceptance criteria, one scenario per criterion, not bulk drafts from the requirement title; ask the human when the source states none. Give each a plain title, the scenario prose in `document.body` (never in `properties`), and `assumes` links to the `property_value` facts whose values the scenario relies on. Set `expects` only when the scenario links `assumes` facts (or its criterion names concrete values that become them); `expects` without `assumes` only yields a feasibility-unknown warning, so a draft tagged `needs-human-review` omits `expects`. Then link the requirement with `specified_by` (upsert the `req` with its stored `title`, a `status` and that relationship only). Example: criterion "Given an annotation in draft state, when the user deletes it, the draft is cleared" becomes `{"type":"scenario","id":"SCEN-annotation-delete-clears-draft","properties":{"title":"Deleting a draft annotation clears the draft","status":"active","expects":"success"},"document":{"body":"Given an annotation in draft state, when the user deletes it, then the draft is cleared and nothing is published.\n\nThe acceptance criterion comes from the cited ticket; reviewers asked for it so a deleted draft never reappears after reload.\n"},"relationships":[{"type":"assumes","from":"SCEN-annotation-delete-clears-draft","to":"FACT-annotation-state-draft"}]}`, where the assumed fact is a `property_value` (`annotation.state` `eq` `draft`). Link existing tests that exercise it; never invent test evidence.
     - **Predicates.** Run `kb_model` with `mode: "predicates"` and `requirementId` on each persisted requirement and apply a returned plan with `requires_predicate` to its `relationshipTarget` (the planned `FACT-PRED-…` id, never a `SUGGEST-…` candidate id), or record the `review:ontology-gap` observation it returns, with its prose in `document.body`. A non-empty `existingGrounding` means the bootstrap already grounded that claim: on `replace_grounding` leave it unless the human wants the `replacementPlan` swap; on `provide_argument_bindings` retry with the listed arguments bound; on `record_ontology_gap` still write the returned gap observation, which is not a grounding link. Count what `kb_query` shows afterwards, not the calls you made.
     - **Unrecorded ambiguity.** Record any conflict or open question you found but did not declare in step 3 as a cited `fact_kind: observation` tagged `review:conflict` or `review:open-question`.

package/dist/public/skills/kibi-commit-review/SKILL.md

@@ -1,8 +1,8 @@
 ---
 id: kibi-commit-review
 name: kibi-commit-review
-description: "Use when kibi check --staged or the Kibi pre-commit hook blocks a commit (kibi_impact_evidence_missing, symbols_manifest_stale, symbol_granularity_violation, symbol-coverage, kibi check-generated drift, Staged impact review failed), or when preparing a commit or pull-request impact review. Covers reading the per-file Detail lines, authoring .kb/symbols.yaml symbol entries through kb_upsert, kibi sync --refresh-symbol-coordinates, staging the tracked Kibi evidence with git add, kb_prepare_impact_review for a staged or diff scope, the kibi signoff requirements summary to show before a commit, and how merge commits and migration renames are judged."
-version: 1.2.1
+description: "Use when kibi check --staged or the Kibi pre-commit hook blocks a commit (kibi_impact_evidence_missing, symbols_manifest_stale, symbol_granularity_violation, symbol-coverage, kibi check-generated drift, Staged impact review failed), or when preparing a commit or pull-request impact review. Covers reading the per-file Detail lines, authoring .kb/symbols.yaml symbol entries through kb_upsert, staging the tracked Kibi evidence with git add (symbol coordinates are derived and never staged), kb_prepare_impact_review for a staged or diff scope, the kibi signoff requirements summary to show before a commit, and how merge commits and migration renames are judged."
+version: 1.3.0
 kibiCompatibility: ">=1.0.0"
 tags:
   - kibi
@@ -55,17 +55,17 @@ Never read or open any file under `.kb`, not even read-only with a file tool to
    - New or uncovered symbols: author a `symbol` entity per listed symbol
      through `kb_upsert` (`title` = the member the extractor names,
      `sourceFile`, `status: active`, `symbol_role: behavioral`, `implements`
-     to the requirement, `covered_by` to the test). Then run
-     `kibi sync --refresh-symbol-coordinates`.
-   - Only coordinates moved: `kibi sync --refresh-symbol-coordinates`.
+     to the requirement, `covered_by` to the test).
+   - Only lines moved: nothing to do. Symbol coordinates are derived locally
+     by every sync and never committed.
    - No behavior change (a genuine false positive): see the audited
      no-impact note in `resources/staged-gate.md`; it never covers a real
      behavior change.
 4. **Stage the evidence.** Kibi authors tracked files but never Git-stages or
    commits them. `git status --short .kb` lists what it wrote; `git add` the
-   entity Markdown, `.kb/relationships/` shards, `.kb/symbols.yaml` and
-   `.kb/symbol-coordinates.yaml` that belong to this change (use `git add -p`
-   when the files hold unrelated edits).
+   entity Markdown, `.kb/relationships/` shards and `.kb/symbols.yaml` that
+   belong to this change (use `git add -p` when the files hold unrelated
+   edits). `.kb/symbol-coordinates.yaml` is gitignored; never stage it.
 5. **Re-run** `kibi check --staged` (and `kibi check-generated --staged` when it
    failed) until it passes. Never bypass the hook (`--no-verify`) unless the
    person says so.

package/dist/public/skills/kibi-commit-review/resources/staged-gate.md

@@ -8,10 +8,10 @@ not the working tree, so a fix counts only once it is staged.
 ## Reading a finding
 
 ```text
-symbols_manifest_stale: .kb/symbol-coordinates.yaml is stale or missing for staged source files: src/billing/refund.ts
+symbols_manifest_stale: .kb/symbols.yaml does not cover the declarations of staged source files: src/billing/refund.ts
   Detail: src/billing/refund.ts — extraction finds 4 symbol(s), evidence covers 3.
       Not in .kb/symbols.yaml: approveRefund (line 42)
-  Suggestion: Author .kb/symbols.yaml entries for the uncovered symbols (kibi upsert, with implements/covered_by links), then run kibi sync --refresh-symbol-coordinates && git add .kb/symbol-coordinates.yaml .kb/symbols.yaml, then re-run kibi check --staged.
+  Suggestion: Author .kb/symbols.yaml entries for the uncovered symbols (kibi upsert, with implements/covered_by links). Stage .kb/symbols.yaml with the behavior edit, then re-run kibi check --staged.
 ```
 
 - Detail lines name every symbol, never a shortened list. `Evidence without a
@@ -24,17 +24,22 @@ symbols_manifest_stale: .kb/symbol-coordinates.yaml is stale or missing for stag
 
 | Id or message | Cause | Fix |
 | --- | --- | --- |
-| `kibi_impact_evidence_missing` | A staged behavior edit (changed lines in exported or behavior-bearing code, not comments or formatting) has no staged Kibi evidence. Test-only edits do not need it unless they add executable test symbols. | Query the owning knowledge; update it when behavior changed; stage entity Markdown under `.kb/`, authored `.kb/symbols.yaml` entries for the listed symbols, or refreshed `.kb/symbol-coordinates.yaml`. |
-| `symbols_manifest_stale` | Extraction output changed and the staged coordinates (or manifest) do not match it. | Author entries for the listed symbols first, then `kibi sync --refresh-symbol-coordinates`, then stage both manifests. |
+| `kibi_impact_evidence_missing` | A staged behavior edit (changed lines in exported or behavior-bearing code, not comments or formatting) has no staged Kibi evidence. Test-only edits do not need it unless they add executable test symbols. | Query the owning knowledge; update it when behavior changed; stage entity Markdown under `.kb/` or authored `.kb/symbols.yaml` entries for the listed symbols. A file whose every declaration already has a `.kb/symbols.yaml` entry needs nothing more. |
+| `symbols_manifest_stale` | A staged behavior file declares symbols `.kb/symbols.yaml` has no entry for, or an entry names a declaration that is gone. | Author entries for the listed symbols, re-point or retire entries whose declaration is gone, and stage `.kb/symbols.yaml`. Coordinates are derived locally and never staged. |
 | `symbol_granularity_violation` | A changed behavioral member is owned only by a coarse class or module symbol while a narrower declaration exists. | Add a symbol for the member itself (`title` = `Class.method` or the exported function) with its own links; use `granularity_reason` (`config-artifact`, `module-level-behavior`, `extractor-miss`, `legacy-link`, `test-suite`) only when it is true. |
 | `symbol-coverage` | A changed symbol, or a symbol whose staged manifest entry changed, fails the full-check rule on the staged knowledge. | The symbol `implements` the requirement and is `covered_by` a test that verifies it: through the requirement's scenario (`verified_by` scenario -> test) when it has one, else `verified_by` requirement -> test. A direct requirement -> test link does not count while a scenario exists. The finding's suggestion names the missing link (see `kibi-traceability`). |
 | `kibi_impact_override_missing_rationale` | A `Kibi-Impact: none` declaration has no `Rationale:` line. | Add the rationale, or drop the declaration and stage real evidence. |
 | `entity-context-missing` (staged entity) | A staged requirement, scenario, test, ADR or observation fact has fewer than 12 words of context. | Upsert a sectioned `document.body` (see `kibi-usage`, Entity body contract). |
-| `domain-contradictions`, `scenario-feasibility`, `exception-claim-keys` (staged `.kb/` change) | The staged knowledge introduces a violation the last commit did not have. | Fix the knowledge; a contradiction with a recorded rule goes to the person (`kibi-decisions`). |
+| `domain-contradictions`, `kb-consistency`, `scenario-feasibility`, `exception-claim-keys` (staged `.kb/` change) | The staged knowledge introduces a violation the last commit did not have. `kb-consistency` also catches facts that contradict only together and names their requirements. | Fix the knowledge; a contradiction with a recorded rule goes to the person (`kibi-decisions`). |
 | Proposition-complete ingestion | A staged requirement's semantic inventory is missing or no longer matches its prose. | Re-derive it (`kb_model` analyze with the complete prose) or run `kibi migrate` for drift. |
-| `kibi check-generated --staged` drift | The staged `.kb/symbols.yaml` or `.kb/symbol-coordinates.yaml` differs from a refresh computed from the index. | `kibi sync --refresh-symbol-coordinates`, review the diff, stage only the intended hunks (`git add -p`). |
+| `kibi check-generated --staged` drift | The staged `.kb/symbols.yaml` is not in the layout sync writes, or `.kb/symbol-coordinates.yaml` is tracked. | `kibi sync --refresh-symbol-coordinates`, review the diff, stage only the intended hunks (`git add -p`); untrack a tracked coordinates file with `kibi migrate` (or `git rm --cached`). |
 | `Staged impact review failed: impact_review_invalid: ...` | The base commit has `.kibi/impact-policy.json` and the staged `.kibi/impact-review.json` is missing, stale or incomplete. The message names the cause (missing review path, stale fingerprint, ...). | Prepare a fresh record (below). Any later staged change makes the fingerprints stale again, so prepare it last. |
 
+The staged gate does not judge evidence levels: the `evidence-floor` rule
+runs only in a full `kibi check`. A firm requirement staged without an
+end-to-end proof passes the commit and fails that check later (see
+`kibi-decisions` for `required_evidence`).
+
 ## Advisory findings
 
 These warn but do not block. Read them; they are often the real review.
@@ -93,6 +98,6 @@ does not prove it. Put the person's id there only when they reviewed it.
 npx --no-install kibi check --staged                    # the gate
 npx --no-install kibi check --staged --format json      # with full evidence
 npx --no-install kibi check-generated --staged          # manifest drift
-npx --no-install kibi sync --refresh-symbol-coordinates # refresh coordinates
+npx --no-install kibi sync --refresh-symbol-coordinates # rebuild local coordinates
 git status --short .kb                                  # what Kibi wrote
 ```

package/dist/public/skills/kibi-decisions/SKILL.md

@@ -2,7 +2,7 @@
 id: kibi-decisions
 name: kibi-decisions
 description: "Use when the person states a rule or decision (must, never, always, from now on, we decided), when a Kibi hook asks to confirm or warns about an edit to code that implements a firm requirement, when the Stop hook says source files changed but nothing was recorded, when kb_check quotes requirement_statement_unverified, or when a request conflicts with a recorded requirement or ADR. Covers reading firmness and origin, recording a person's rule as firm with origin.ref, superseding with a Why this changed section, the kb_compile_intent unresolved/reviewCandidates/conflictReviews loop, asking before overriding a firm rule, and putting decisions to the person as one numbered kibi signoff --questions view."
-version: 1.2.1
+version: 1.4.0
 kibiCompatibility: ">=1.0.0"
 tags:
   - kibi
@@ -74,6 +74,16 @@ name the missing capability. Never read or edit `.kb/` files directly.
   quoting their words and where they said them, a sectioned `document.body`,
   a scenario, and an `implements` link from the code that enforces it. Use
   `kb_compile_intent` first when the rule may touch several requirements.
+  A firm rule needs `tested` evidence by default, so `kb_check`'s
+  `evidence-floor` rule fails on it until an end-to-end test proves its
+  scenario. When the change includes that test, give it a proof contract and
+  run `kibi prove`. Otherwise set `required_evidence: asserted`, say in the
+  body that no end-to-end test proves the rule yet, and report it as
+  asserted, not tested. Kibi's bootstrap and migration give an untested firm
+  rule the same floor. When the rule is a claim a certificate kind checks
+  (allowed values, transitions, a pattern, a rule over roles, a config,
+  route or schema read), a certificate test proves it instead: see
+  Certificate proof kinds in kibi-usage `resources/proof.md`.
 - **The person changes a rule:** supersede it (new requirement linked
   `supersedes` new -> old, `firmness: firm` when the old one was firm, a
   `## Why this changed` section of at least 12 words naming their instruction
@@ -124,7 +134,8 @@ Validation is not completion. When a request conflicts with a recorded rule and
 
 End with `kb_check` (and `kb_status` when freshness matters) and say:
 
-- which rules you followed, asked about, recorded or changed (ids, firmness);
+- which rules you followed, asked about, recorded or changed (ids, firmness,
+  evidence level);
 - under "Decisions I changed", each supersede and its evidence;
 - the open question, if a conflict is waiting on the person;
 - or, when the session made no decision, one line saying so.

package/dist/public/skills/kibi-decisions/resources/decision-records.md

@@ -43,7 +43,7 @@ says it, link to it instead of restating it. Otherwise write the scenario
 first, then the requirement (the requirement's write sends `specified_by`):
 
 ```json
-{"type":"req","id":"REQ-billing-refund-approval","properties":{"title":"Refunds above 500 EUR need a finance approval","status":"open","priority":"must","firmness":"firm","origin":{"kind":"agent","ref":"session request: \"from now on refunds above 500 EUR must be approved by finance\""}},"relationships":[{"type":"specified_by","from":"REQ-billing-refund-approval","to":"SCEN-billing-refund-approval"}],"document":{"body":"Refunds above 500 EUR need a finance approval.\n\n## Context\n\nThe person asked for this rule while changing the refund flow; reason not stated.\n\n## Source\n\n> from now on refunds above 500 EUR must be approved by finance\n\nSession request."}}
+{"type":"req","id":"REQ-billing-refund-approval","properties":{"title":"Refunds above 500 EUR need a finance approval","status":"open","priority":"must","firmness":"firm","required_evidence":"asserted","origin":{"kind":"agent","ref":"session request: \"from now on refunds above 500 EUR must be approved by finance\""}},"relationships":[{"type":"specified_by","from":"REQ-billing-refund-approval","to":"SCEN-billing-refund-approval"}],"document":{"body":"Refunds above 500 EUR need a finance approval.\n\n## Context\n\nThe person asked for this rule while changing the refund flow; reason not stated. No end-to-end test proves it yet.\n\n## Source\n\n> from now on refunds above 500 EUR must be approved by finance\n\nSession request."}}
 ```
 
 Then link the enforcing symbol with `implements` (and its test with
@@ -58,6 +58,14 @@ validation, not the write.
   `origin.approved_by` to the person.
 - A rule from a document, test or ticket a person wrote is `firm` too, with
   `origin.ref` to that source.
+- `required_evidence: asserted` keeps an untested firm rule from failing
+  the `evidence-floor` check while it is recorded. Drop it (the floor goes
+  back to `tested`) once an end-to-end test with a proof contract and a
+  passing `kibi prove` receipt covers the rule's scenario; never set it below
+  `asserted` on a firm rule. A rule that a certificate kind checks (allowed
+  values, transitions, a pattern, a rule over roles, a config, route or
+  schema read) can instead be proved by a certificate test; see Certificate
+  proof kinds in kibi-usage `resources/proof.md`.
 - Your own choice is `default`; a guess is `exploratory`. Write the value
   explicitly whenever you record a decision.
 - For strict modeling (claim keys, predicate facts) follow `kibi-usage`,

package/dist/public/skills/kibi-freshness/SKILL.md

@@ -2,7 +2,7 @@
 id: kibi-freshness
 name: kibi-freshness
 description: Check exact Git attachment, branch migration/quarantine, compiled-store freshness, source linkage, and repair state before decisions or writes.
-version: 2.1.0
+version: 2.3.0
 kibiCompatibility: ">=1.0.0"
 tags:
   - kibi
@@ -66,6 +66,10 @@ For every freshness, branch, or completion question, call `kb_status` first, the
   evidence-dependent closeout. Name the exact paths/symbol IDs and whether the
   result is fixed, accepted, or deferred.
 - If entities look stale, refresh context through an approved Kibi capability and then re-query.
+- When asked whether a requirement is proven, quote its `evidenceLevel` and
+  `evidenceFloor` from `kb_coverage`. `pending_reproof` (receipts older than
+  the code, or than a file a `source` proof read) is stale evidence, not proof; `kibi prove` refreshes it, and
+  `kibi check --fresh-evidence` is the check that fails on it.
 - Preserve source-file traceability by carrying `sourceFile`, text references, and validation evidence through discovery, mutation, and completion.
 - Do not read or edit files inside `.kb` directly; use the selected Kibi interface instead.
 - Kibi authors tracked files but never Git-stages or commits them; ordinary Git workflows remain responsible for review and commit.

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

@@ -2,7 +2,7 @@
 id: kibi-traceability
 name: kibi-traceability
 description: Maintain source-first requirement, scenario, test, symbol, and proof traceability through Kibi's peer interfaces.
-version: 2.0.0
+version: 2.3.0
 kibiCompatibility: ">=1.0.0"
 tags:
   - kibi
@@ -64,3 +64,14 @@ stale snapshots, unavailable receipts, and incomplete grounding explicit.
 Fresh proof requires a current verification snapshot, the exact contracted E2E
 command, an append-only receipt, and current symbol coordinates. Structural
 coverage and a green check are not proof by themselves.
+
+Report each requirement's `evidenceLevel` from `kb_coverage` as it is:
+`proved` only when certificate proofs (exhaustive, typecheck, arithmetic,
+smt, rule, state_machine, regex, source) bound at code or harness scope
+derive every applicable claim (intent-scope bindings stay `tested`), named in each contract's `proves`
+(`claimSummary` and `unprovedClaims` say which are missing), `tested` for fresh passing E2E receipts,
+`asserted` when only a person stands behind it, `unverified` otherwise. Its
+`evidenceFloor` says what `kb_check`'s `evidence-floor` rule requires:
+`below` is a traceability gap to close with links, tests and `kibi prove`;
+`pending_reproof` means the receipts are older than the code and need
+`kibi prove`. Never lower `required_evidence` to clear either.

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

@@ -2,7 +2,7 @@
 id: kibi-usage
 name: Kibi Usage
 description: Use Kibi's source-first, exact-Git, migration-aware, proof-aware operations safely across MCP or the trusted local CLI, including partial completion repair.
-version: 2.24.0
+version: 2.32.0
 kibiCompatibility: ">=1.0.0"
 tags:
   - kibi
@@ -434,9 +434,13 @@ safe normative claims; use `observation` or `meta` for bug/workaround notes and
 tests, symbol ownership, and fresh proof-bearing receipts before claiming proof.
 For an existing product KB that needs semantic backfill, read
 `resources/kb-improvement.md`, and `resources/proof.md` for the proof workflow.
-When a proof ratchet fails, follow Debugging proof regressions in
-`resources/proof.md`: use `kibi proof explain` and compare current proof state
-to committed `proof/baseline.json` with `kibi proof impact`.
+Each current requirement has an evidence floor (`required_evidence`, else
+`tested` when firm); certificate proof kinds (exhaustive, typecheck,
+arithmetic, smt, rule, state_machine, regex, source) reach `proved` for the claims their contract names in
+`proves`, and a requirement is proved only when every claim is. A rule
+predicate bound with `harness_for` (scope `harness`) also counts toward
+`proved`; an intent-scope binding stays `tested`. When the `evidence-floor` rule fails, follow Debugging
+proof regressions in `resources/proof.md` and use `kibi proof explain`.
 
 ## Predicate Ontology Decision Tree