kibi-cli 2.36.0 → 2.38.0

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.36.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
@@ -442,6 +446,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

@@ -831,6 +831,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 +866,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",