kibi-cli 2.36.0 → 2.39.0

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

@@ -2,7 +2,7 @@
 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, 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
+version: 1.4.0
 kibiCompatibility: ">=1.0.0"
 tags:
   - kibi
@@ -91,7 +91,11 @@ apps); never attach the `.html` as a file, which chat apps show as raw source;
 past 15 requirements the Markdown stops and only the page lists them all.
 Host details: `kibi-decisions`, `resources/signoff-views.md`. `--no-proof` skips the proof lookup, which reads coverage and is slow
 on a large knowledge base. The summary is not an approval: never set
-`approved_by` or `origin.ref` from it.
+`approved_by` or `origin.ref` from it. Show it before you open or merge the
+pull request. When the person answers, record their answer in the same
+change (their name in `approved_by`, their words in `origin.ref` or
+`approval_ref`) and push it to the same pull request; never move a signoff,
+firmness or waiver approval into a separate pull request.
 
 ## Impact reviews
 

package/src/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.4.0
+version: 1.5.0
 kibiCompatibility: ">=1.0.0"
 tags:
   - kibi
@@ -115,7 +115,12 @@ again until none is open, then record each rule with their words in
 `origin.ref`. Fields and outputs: `resources/signoff-views.md`.
 
 Never invent words for `origin.ref`, never set `approved_by` yourself, and
-mark your own picks `default` and guesses `exploratory`. Payload shapes,
+mark your own picks `default` and guesses `exploratory`. Once the person has
+answered, recording their answer (their name in `approved_by` or a
+`*_waiver_approved_by` field, their words in `origin.ref` or `approval_ref`)
+is yours to do: put it on the branch of the change it approves and push it to
+that pull request, never to a separate one. Ask before you open or merge the
+pull request, so the answer lands in it. Payload shapes,
 refusal messages and the `kb_compile_intent` review loop are in
 `resources/decision-records.md`.
 

package/src/public/skills/kibi-decisions/resources/signoff-views.md

@@ -51,7 +51,9 @@ writes and opens the page; `--format json` prints the view.
 The person answers by number ("1 yes, 2 exploratory, 3 reword: ..."). Copy
 each answer into `answer`, render again, and record the rules only once every
 question is answered. An answer is the person's words: quote it in
-`origin.ref`; a view itself is never an approval.
+`origin.ref`; a view itself is never an approval. Record the answers on the
+branch of the change they approve and push them to its pull request, never to
+a separate one.
 
 ## Summary contents
 

package/src/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.32.0
+version: 2.37.0
 kibiCompatibility: ">=1.0.0"
 tags:
   - kibi
@@ -137,7 +137,9 @@ For an edit that keeps the governing rule, limit the consultation before the edi
    `unknown`, or `none`, which is not proof), the `exceptions` that exempt it,
    and the `unknowns` the checks could not decide. Those links and verdicts are
    discovery, not proof. Pass `sourceLocations` before changing a source file,
-   and `rankingMode: "legacy"` for literal identifier lookups. See
+   and `rankingMode: "legacy"` for literal identifier lookups. A weak answer
+   may add `queryAnalysis.hints` (requirements the question may mean): re-ask
+   in their words, never cite a hint as the rule. See
    `resources/workflows.md` for the mode recipe.
 2. Resolve genuine ambiguity with the human; use `kb_model` for deterministic
    interpretation and typed facts.
@@ -286,7 +288,9 @@ authored. Each one is the order the write path accepts.
    its scenario: `specified_by` (req → scenario) is sent in the
    requirement's write, never in the scenario's, so create the scenario
    first, with `assumes` links (scenario → `property_value` fact, sent in
-   the scenario's own write) to the values its outcome relies on. Set
+   the scenario's own write) to the values its outcome relies on; add a
+   rejection scenario that assumes a forbidden value next to the success
+   one (see Quantified claims below). Set
    `expects` only on a scenario that has `assumes` links; `expects: success`
    without them only yields `scenario-feasibility-unknown` ("assumes
    nothing"). A
@@ -368,6 +372,14 @@ human sets `approved_by`; `kb_check` flags approvals an agent recorded without
 corroboration. Never fill in an approval yourself. Record why a requirement
 exists in `rationale`, or link the ADR that explains it.
 
+A signoff belongs to the change it approves. Ask for it before you open or
+merge the pull request, and when the person answers, record their answer
+(`approved_by` or a `*_waiver_approved_by` field set to them, their words in
+`origin.ref` or `approval_ref`) on the same branch and push it to the same pull
+request. Writing down an answer the person gave is not approving it yourself.
+Never open a separate pull request only to carry a signoff, firmness or waiver
+approval.
+
 ## Decision firmness
 
 Requirements and ADRs carry `firmness`, which says what you may do with them.
@@ -442,6 +454,41 @@ 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`.
 
+## Quantified claims: model the dimension
+
+When a claim says every, each, all, any, only, at least, at most, exactly, a
+role, a status or a count, ground it on what varies, never on `= true`: an int
+count or bound (`role_count eq 1`, `uninstrumented_loaded_files eq 0`), a set,
+or a typed rule with a `forall` variable. Keep `value_type: bool` for genuinely
+binary properties (a flag is on). A `shadow_analysis` cue from `kb_model`
+(`mode: "analyze"`) with `kind: quantifier` or `numeric` and `represented:
+false` means the planned grounding hides the dimension. When
+`mode: "predicates"` finds no schema for such a claim, do not stop at the
+ontology-gap observation: call `kb_model` with `mode: "requirement"` and an
+int `subjectKey`/`propertyKey`/`operator`/`value` for the count, and keep the
+gap only when no count, set or rule expresses the claim.
+
+Specify the requirement with scenarios that carry their inputs. Each scenario
+sets `expects` and `assumes` its own `property_value` fact: same `subject_key`
+and `property_key` as the grounding, with the scenario's value. These
+assumed-value facts are linked only by the scenario's `assumes`, never by the
+requirement, so a forbidden value does not contradict the grounding; it is
+what makes the scenario a rejection. Write at least:
+
+- a success scenario assuming an allowed value (`expects: success`);
+- a rejection scenario assuming a forbidden value (`expects: rejection`, or
+  `error`); a scenario that only describes the refusal in prose, without
+  `expects` and `assumes`, does not count;
+- for a quantified claim, cases at zero, one and many when they differ.
+
+```json
+{"type":"fact","id":"FACT-member-role-count-2","properties":{"title":"Member holds two roles","status":"active","fact_kind":"property_value","subject_key":"organization.member","property_key":"role_count","operator":"eq","value_type":"int","value_int":2}}
+{"type":"scenario","id":"SCEN-member-two-roles-rejected","properties":{"title":"A member with two roles is rejected","status":"active","expects":"rejection"},"relationships":[{"type":"assumes","from":"SCEN-member-two-roles-rejected","to":"FACT-member-role-count-2"}]}
+```
+
+Then send `specified_by` to every scenario in the requirement's write.
+Details: `resources/fact-lanes.md`, Model the Dimension, Not the Verdict.
+
 ## Predicate Ontology Decision Tree
 
 Call `kb_model` with `mode: "analyze"` on the complete prose before encoding a clause.

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

@@ -15,6 +15,40 @@ Use the advisor-returned atomic inventory as the identity boundary. Trailing pun
 
 Example compound prose: “Checkout requires payment authorization before order submission, and customer data must be retained for 7 years.” This is two claims, not one. The first becomes `dependency_rule(checkout,payment_authorization,order_submission)`; the second becomes a strict retention property. Both fact records carry different advisor-issued claim keys, and both keys appear in the requirement manifest. A single `requires_predicate` edge is incomplete.
 
+## Model the Dimension, Not the Verdict
+
+A claim that says every, each, all, any, only, at least, at most, exactly, no more than, a role, a status or a count ranges over something. Ground it on the thing that varies, not on a boolean that says the claim holds:
+
+| The claim varies over | Ground it on |
+| --- | --- |
+| a count or bound ("at most 5 owners", "exactly one role") | `property_value` with `value_type: int` and `eq`/`lte`/`gte` |
+| each member of a collection ("every loaded file") | an int count of the members that break the rule (`eq 0`), or a typed rule with a `forall` variable over the member |
+| a closed set of values ("only admins and owners") | a canonical string set, or a predicate argument with `argument_constants` |
+| a status or lifecycle ("a closed invoice cannot reopen") | a typed rule over the status, or a `state_machine` proof |
+
+Use `value_type: bool` (`= true`) only when the property itself is binary: a flag is on, a feature is enabled. `module.loader.instruments_all_loaded_files = true` restates the claim and gives Kibi nothing that can vary: no boundary, no zero/one/many case, and no contradiction with another requirement that bounds the same count.
+
+`kb_model` (`mode: "analyze"`) lists `shadow_analysis` cues. A `quantifier` or `numeric` cue with `represented: false` means the grounding does not carry the dimension yet. Do not ignore it: re-plan the grounding as a count, a rule variable or a set before writing. When no typed shape fits, keep the clause `ontology_gap` rather than downgrading it to a boolean verdict.
+
+Example: "Each organization member must hold exactly one role."
+
+```yaml
+# Avoid: the verdict
+- { fact_kind: property_value, subject_key: organization.member, property_key: holds_exactly_one_role, operator: eq, value_type: bool, value_bool: true }
+# Prefer: the dimension
+- { fact_kind: property_value, subject_key: organization.member, property_key: role_count, operator: eq, value_type: int, value_int: 1 }
+```
+
+### Scenarios carry their inputs
+
+A requirement grounded on a dimension is specified by scenarios that pick values of it. Each scenario `assumes` the `property_value` facts that state its input (same `subject_key` and `property_key` as the requirement's grounding, with the scenario's value) and sets `expects`:
+
+- one success scenario whose assumed value the requirement allows (`role_count = 1`, `expects: success`);
+- at least one rejection or error scenario whose assumed value the requirement forbids (`role_count = 2`, `expects: rejection`): a requirement that constrains behavior is not specified by its happy path alone;
+- for a quantified claim, scenarios at zero, one and many of the varying thing whenever those behave differently (no files loaded, one file, several files).
+
+Assumed-value facts are ordinary `property_value` facts linked only by the scenario's `assumes`; never link them from the requirement. Only requirement-linked facts are compared for contradictions, so an assumed forbidden value (`role_count = 2` next to the grounding `role_count eq 1`) is not a conflict: it is the input that makes the scenario a rejection. A refusal described only in prose, without `expects` and `assumes`, does not specify anything Kibi can check. Create them and the scenarios before the requirement write that sends `specified_by`. `scenario-feasibility` then checks every success scenario against the requirement, and the `happy_path_only` proof gap reports a requirement none of whose scenarios expects rejection or error while assuming a value that opposes one of its claims.
+
 ## Predicate Lane (Relational Claims)
 
 Call `kb_model` with `mode: "analyze"`, then with `mode: "predicates"`. Apply a candidate only when its schema meaning and ordered arguments fit the claim. Use the returned `applyPlan` rather than hand-writing unsupported predicate names, and link the requirement to the predicate fact with `requires_predicate`.

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

@@ -173,7 +173,10 @@ left:
   Enum values, dict keys, list/tuple/set items) and rejects a
   certificate that does not cover exactly its members, so a hand-listed or
   partial domain stays `tested`. An import from build output is mapped back
-  to its source through `tsconfig.json` `outDir`/`rootDir`.
+  to its source through `tsconfig.json` `outDir`/`rootDir`. For a list of
+  records (a catalog), add `field: <name>` and pass
+  `key: (item) => item.<name>` to `exhaustiveCertificate`; the members are
+  that field's values.
 - `typecheck`: a witness file that stops compiling when a domain member
   goes unhandled (a switch ending in a `never` assignment, or a
   `satisfies Record<Domain, ...>` map). Set `witness.path` and
@@ -195,7 +198,8 @@ left:
   evaluates the number export itself and adds `variable eq value` as an
   assumption. For a count claim over a collection ("exactly 32 tools") add
   `measure: count` and name the list, set, map or object export; Kibi uses
-  its size, so do not add a number export just for the proof. A count
+  its size, so do not add a number export just for the proof. A dotted
+  export (`POLICY.eventLimit`) reads one field of an object export. A count
   claim needs only `value_source`. Naming the claim's own fact in
   `constraint_source` assumes the claim: without `value_source` Kibi counts
   that derivation as intent only (tested), and with it a code value that
@@ -244,7 +248,7 @@ left:
   `subset_of` and `excludes`. Rules over a machine use `transition`,
   `reachable`, `initial`, `terminal`, `state`.
 - `regex`: set `pattern_source` to a `RegExp`, a Python `re.compile(...)` or
-  a string constant. Model "X must match `re`" as a string fact with
+  a string constant (`export: BRAND.name` reads one field of an object). Model "X must match `re`" as a string fact with
   `operator: matches` (a JavaScript pattern with the `u` flag, matched
   whole); Kibi decides exact language equality and reports the shortest
   string only one side accepts. Backreferences, lookaround, `\b`, the `g`,
@@ -254,7 +258,8 @@ left:
 - `source`: Kibi reads a project source itself and checks a set fact
   against what it read, so the test only runs the proof (it may write
   nothing, or `sourceCertificate({ testId })`). Set `source: {reader, ...}`:
-  `json`/`yaml` (`file`, `path`, `select`), `glob` (`pattern`, `capture`),
+  `json`/`yaml` (`file`, `path`, `select`, `field` to read one key of
+  each list item, such as the `run` of each workflow step), `glob` (`pattern`, `capture`),
   `openapi` (`file`, `select: operations|unsecured_operations|...`),
   `references` (`files`, `extract: env|imports|calls|string_args|thrown|
   property`), `schema` (`format: drizzle|prisma|sql`, `select:
@@ -271,7 +276,10 @@ left:
   `nullable_fields` (only `eq`/`includes`) with bare members `name` for
   "every table" (it also covers tables added later) or `table.name` for
   one; `middleware` with `includes` for "every route under /p must use M"
-  (Kibi checks each route). Name middleware with `names_from`: a
+  (Kibi checks each route); `precedes` with `includes` and members
+  `"A -> B"` for an order in a list ("the gate runs before the push"):
+  A and B are both in the list and every A comes before every B. Name
+  middleware with `names_from`: a
   zero-argument factory export such as `requireAuth()` names the
   middleware it returns `requireAuth`. Write the fact with `kb_model`
   (requirement mode, `operator` plus a list `value`) or `kb_upsert`. The

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

@@ -78,6 +78,16 @@ no-answer, so widen the query or drop to lexical search rather than treating it
 as "nothing exists". A literal identifier lookup is still best served
 lexically.
 
+When the project activates a `kibi.search-hints.v1` plugin (for example
+`kibi-plugin-search-hints`), a weak or abstained intent answer also carries
+`queryAnalysis.hints`: up to ten current requirements the question may mean,
+found by meaning rather than shared words, each with a `score` and, when it
+was reached through a scenario, test or fact, that entity as `via`. Hints are
+suggestions, never governing requirements, and they never change the results
+or the answer layer. Re-ask `kb_search` in the words of a hint that fits, or
+pass them as `semanticFacets.aliases`, then read the requirement with
+`kb_query`; never cite a hint as the rule. `hints: false` turns them off.
+
 On the first page, intent mode also returns an answer layer in `data.answer`
 (`kibi.search-answer.v1`; turn it off with `answer: false`):
 

package/src/schemas/entity.schema.json

@@ -562,6 +562,18 @@
       "minLength": 1,
       "description": "Requirement-only. Optional reference to the approval decision record (ticket, ADR or review link) for an exception requirement."
     },
+    "failure_side_waiver": {
+      "type": "string",
+      "minLength": 1,
+      "pattern": "\\S",
+      "description": "Requirement-only. Why the requirement has no failure side to test: its claims state a capability or an output shape, so there is no input or attempt for Kibi to refuse. Waives the happy_path_only gap once failure_side_waiver_approved_by is set."
+    },
+    "failure_side_waiver_approved_by": {
+      "type": "string",
+      "minLength": 1,
+      "pattern": "\\S",
+      "description": "Requirement-only. The person who accepted failure_side_waiver. Without it the waiver is reported as awaiting approval and the gap stays open."
+    },
     "rationale": {
       "type": "string",
       "minLength": 1,
@@ -684,6 +696,32 @@
           },
           "reason": {
             "type": "string"
+          },
+          "dimension": {
+            "type": "object",
+            "required": [
+              "quantifier",
+              "rewrites"
+            ],
+            "properties": {
+              "quantifier": {
+                "type": "string",
+                "minLength": 1
+              },
+              "rewrites": {
+                "type": "array",
+                "items": {
+                  "type": "string",
+                  "enum": [
+                    "bound",
+                    "rule",
+                    "count",
+                    "set"
+                  ]
+                }
+              }
+            },
+            "additionalProperties": false
           }
         },
         "additionalProperties": false
@@ -831,6 +869,11 @@
               "type": "string",
               "minLength": 1,
               "description": "The name the domain is exported under in the symbol's source file, when the symbol's title is not that name."
+            },
+            "field": {
+              "type": "string",
+              "minLength": 1,
+              "description": "exhaustive: when the export is a list of records, the field of each record that names a domain member (a catalog's name)."
             }
           },
           "additionalProperties": false
@@ -861,7 +904,7 @@
         },
         "value_source": {
           "type": "array",
-          "description": "arithmetic and smt: code constants the assumptions read. Kibi evaluates each export at ingest and requires the certificate to assume the variable equals that value, so the proof is about the code and not only the knowledge base. With measure count the value is the size of a list, set, map or object export, so a count claim reads the collection itself. An entry {source, measure: count} counts the members Kibi reads from a project source (routes, tables, environment variables).",
+          "description": "arithmetic and smt: code constants the assumptions read. Kibi evaluates each export at ingest and requires the certificate to assume the variable equals that value, so the proof is about the code and not only the knowledge base. With measure count the value is the size of a list, set, map or object export, so a count claim reads the collection itself. A dotted export (POLICY.eventLimit) reads one field of an object export. An entry {source, measure: count} counts the members Kibi reads from a project source (routes, tables, environment variables).",
           "minItems": 1,
           "items": {
             "type": "object",
@@ -1597,6 +1640,30 @@
     "claim_text": {
       "type": "string"
     },
+    "dimension_waiver": {
+      "type": "string",
+      "minLength": 1,
+      "pattern": "\\S",
+      "description": "Fact-only. Why the quantifier word in claim_text (each, every, all, or a cardinality bound) ranges over nothing, so the claim needs no count, set or rule. Waives dimension_unrepresented for the claim once dimension_waiver_approved_by is set."
+    },
+    "dimension_waiver_approved_by": {
+      "type": "string",
+      "minLength": 1,
+      "pattern": "\\S",
+      "description": "Fact-only. The person who accepted dimension_waiver. Without it the waiver is reported as awaiting approval and the gap stays open."
+    },
+    "case_waiver": {
+      "type": "string",
+      "minLength": 1,
+      "pattern": "\\S",
+      "description": "Fact-only. Why the edge cases Kibi derives from this fact (the value past a bound, a value outside a set) are covered some other way or cannot occur. Waives uncovered_case for the fact once case_waiver_approved_by is set."
+    },
+    "case_waiver_approved_by": {
+      "type": "string",
+      "minLength": 1,
+      "pattern": "\\S",
+      "description": "Fact-only. The person who accepted case_waiver. Without it the waiver is reported as awaiting approval and the gap stays open."
+    },
     "predicate_name": {
       "type": "string"
     },
@@ -1834,6 +1901,26 @@
                 "claim_text"
               ]
             },
+            {
+              "required": [
+                "dimension_waiver"
+              ]
+            },
+            {
+              "required": [
+                "dimension_waiver_approved_by"
+              ]
+            },
+            {
+              "required": [
+                "case_waiver"
+              ]
+            },
+            {
+              "required": [
+                "case_waiver_approved_by"
+              ]
+            },
             {
               "required": [
                 "predicate_name"
@@ -2046,6 +2133,16 @@
                 "approval_ref"
               ]
             },
+            {
+              "required": [
+                "failure_side_waiver"
+              ]
+            },
+            {
+              "required": [
+                "failure_side_waiver_approved_by"
+              ]
+            },
             {
               "required": [
                 "rationale"