kibi-cli 0.16.1 → 0.17.0

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

@@ -2,7 +2,7 @@
 id: kibi-usage
 name: Kibi Usage
 description: Guides agents to use Kibi MCP, facts, relationships, and validation correctly
-version: 1.2.0
+version: 1.3.0
 kibiCompatibility: ">=0.11.0"
 tags:
   - kibi
@@ -15,6 +15,8 @@ resources:
   - resources/fact-lanes.md
   - resources/workflows.md
   - resources/operation-access.md
+  - resources/ui-requirements.md
+  - resources/logic-ir.md
 ---
 # Kibi Usage
 
@@ -22,10 +24,10 @@ Consult this skill before any Kibi knowledge base operation, on first interactio
 
 ## Interface Selection
 
-Use this order for every Kibi operation:
+Kibi exposes two peer surfaces over the same 18 operations: visible MCP tools and the trusted project-local CLI. Both accept the same business input and effects (see `resources/operation-access.md`). Choose by what is visible and approved in the current environment — MCP and the CLI are equal choices, not a preference order:
 
 1. If Kibi MCP tools are visible and approved in the current environment, use MCP.
-2. Otherwise, in a trusted workspace, use the project-local CLI through a non-installing runner: `npx --no-install kibi ...` or `bunx --no-install kibi ...`.
+2. Otherwise, in a trusted workspace, use the project-local CLI through a non-installing runner: `npx --no-install kibi ...` or `bunx --no-install kibi ...`. The CLI is a peer interface, not a fallback.
 3. If the project-local CLI is unavailable or too old for the needed route, stop and tell the operator to enable or install Kibi.
 4. Never use a global fallback or an installing runner. Never probe or install packages as a side effect of interface selection.
 
@@ -99,6 +101,14 @@ relationships:
     to: REQ-ADMIN-BILLING-POLICY
 ```
 
+## Typed Logic IR Lane
+
+Readable prose is retained for people, while every assertive proposition is inventoried and either grounded in a strict fact, a predicate fact, or a safe typed rule. Use the required extraction pass followed by an adversarial coverage audit; do not let a high-confidence single suggestion stand in for the rest of a compound requirement. Load `resources/logic-ir.md` for the IR grammar, proposition ledger, safety boundary, and proof semantics.
+
+Use `kb_semantic_advisor` with up to three typed `interpretations` for ambiguous clauses. Kibi canonicalizes alternatives and keeps materially different meanings unresolved. Create `fact_kind: rule_schema` and `fact_kind: rule` endpoints from `kb_model_requirement`'s validated plan, then link `req -> rule` with `requires_rule`. Run `rule-safety`, `rule-verifiability`, `semantic-completeness`, `logic-coverage`, and `domain-contradictions`; unresolved, incomplete, or timed-out reasoning is not evidence of consistency.
+
+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.
+
 ## 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`.
@@ -126,6 +136,12 @@ Use `kb_model_requirement` for automated strict-fact modeling when available. It
 
 Granular fact examples for coherence checks include `REQ-ROLE-SET-2` versus `REQ-ROLE-SET-3` on `user.roles.allowed_set` (`user,admin` versus `user,admin,superadmin`) and `REQ-ADMIN-CAN-MANAGE-BILLING` versus `REQ-ONLY-SUPERADMIN-MANAGES-BILLING` on `billing.manage.allowed_actor`. See `resources/fact-lanes.md`; `domain-contradictions` uses these canonical keys.
 
+## UI / Visual Requirement Modeling
+
+Optional, per-project lane for recording what the screen should look like so UI edits cannot silently drift from the spec. Non-UI projects skip it; no check rule requires it.
+
+Use three layers: a prose `req` as the searchable anchor, strict `property_value` facts for checkable positions/alignment/order (linked `constrains` / `requires_property`, so incompatible values on the same subject/property are rejected on write unless `supersedes`), and relational predicates linked with `requires_predicate` (built-in `visual_layout_rule(subject, relation, target)` for "X must remain visually aligned with Y"). Model UI components as `symbol` entities with `sourceFile` and `symbol_role: behavioral`, linked `implements` to the requirement, so component edits surface the visual spec in impact diagnostics. Full payloads and workflow: `resources/ui-requirements.md`.
+
 ## Complete Logical Coverage
 
 Readable prose is not evidence that a requirement is machine-checkable. Before treating a normative requirement as modeled, decompose its entire body into atomic normative clauses and ground every clause. One correct fact or relationship never proves that the other prose is covered.
@@ -133,12 +149,12 @@ 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.
-4. Ground each key through exactly one suitable logical lane: `requires_property` to one strict `property_value` fact, or `requires_predicate` to one ground `predicate` 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`, `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.
+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` or `requires_predicate` grounding slot per normative 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. 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.
 
 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.
 
@@ -168,8 +184,18 @@ Preserve the readable requirement prose. Facts add a machine-queryable model; th
 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.
 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 and report the requirement as logically incomplete.
-7. Validate every payload, create endpoints first, apply `kb_upsert` calls sequentially, read back all affected IDs, and run targeted `logic-coverage`, `predicate-verifiability`, and `domain-contradictions` checks before the final unfiltered `kb_check`. Exact query output can return an array when one relationship type has multiple targets; verify every target rather than reading only one edge.
+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.
+7. Validate every payload, create endpoints first, apply `kb_upsert` calls sequentially, read back all affected IDs, and run targeted `rule-safety`, `rule-verifiability`, `semantic-completeness`, `logic-coverage`, `predicate-verifiability`, and `domain-contradictions` checks before the final unfiltered `kb_check`. Exact query output can return an array when one relationship type has multiple targets; verify every target rather than reading only one edge.
+
+### Schema-aware proposition boundary
+
+A declared project-local predicate schema can encode one complete relation whose ordered arguments name several facets of the same claim. Do not split those arguments into separate propositions, invent one predicate per noun, or pass an explicit `clauses` array merely to enumerate the schema arguments. First ask `kb_semantic_advisor` about the complete sentence; add clauses only for independently asserted propositions that are not represented by the selected relation. For a schema-backed relation, preserve the one claim key for the complete relation, create the supporting `predicate_schema` with its minimal declared signature (supporting schemas do not carry `claim_key` or `logic_claims`), call `kb_suggest_predicates` on the complete claim, and apply its exact plan to create one ground predicate fact with the ordered schema arguments and that claim key. If `kb_model_requirement` returns an apply plan, execute that plan sequentially; do not fall back to observation facts when an explicitly declared schema fits. If a schema write is rejected, use `kb_validate_upsert` to reduce it to the supported signature, then retry once before considering an ontology gap.
+
+### Hard lane gates for unresolved prose and supplied schemas
+
+The advisor's proposition `status` is a safety gate, not a confidence hint. A `nonlogical` proposition (including `subjective`, rationale, example, heading, or commentary) never receives a `logic_claims` entry and never goes through `kb_suggest_predicates` or `kb_model_requirement`; preserve the complete prose as one `fact_kind: observation` only when an auditable record is useful. Do not manufacture atomic clauses from a subjective sentence merely because it contains `when`, a domain noun, or the word `predicate`. An `ambiguous` proposition remains an ambiguity observation until the operator supplies a typed interpretation. An `ontology_gap` remains unresolved unless an approved schema or validated IR is actually available.
+
+When authorized task input contains `projectLocalSchemas`, those declarations are the schema authority even if the first advisor or predicate lookup calls them an ontology gap. Do not treat an empty candidate list as final: create the minimal declared `predicate_schema` endpoint first, then call `kb_suggest_predicates` again on the one complete claim (with the current `existingLogicClaims`) and apply the resulting ground predicate plan. Preserve the single claim key for that relation; do not add keys for schema arguments. If the lookup still cannot return a plan after the declared schema exists, validate the exact schema-backed predicate payload once and report the remaining blocker rather than inventing a different predicate. For prohibition cues (`must not`, `never`, `cannot`, `forbidden`), use the positive schema with `polarity: deny`; never silently change it to `assert` or encode the negation in a new predicate name.
 
 Example: “Checkout requires payment authorization before order submission” fits `dependency_rule(subject, prerequisite, dependent)`. The ground model is `dependency_rule(checkout,payment_authorization,order_submission)`, stored as:
 
@@ -217,7 +243,7 @@ Never fire `kb_upsert` calls in parallel. Execute them sequentially to avoid loc
 
 ## Checks
 
-Run `kb_check` with specific rules during iteration for fast feedback. For normative requirement modeling, include `rules: ["logic-coverage", "predicate-verifiability", "domain-contradictions"]`; add `required-fields` and `no-dangling-refs` after writes. Run a full `kb_check` without rule filters before declaring Kibi work complete.
+Run `kb_check` with specific rules during iteration for fast feedback. For normative requirement modeling, include `rules: ["rule-safety", "rule-verifiability", "semantic-completeness", "logic-coverage", "predicate-verifiability", "domain-contradictions"]`; add `required-fields` and `no-dangling-refs` after writes. Run a full `kb_check` without rule filters before declaring Kibi work complete.
 
 The `domain-contradictions` rule detects conflicts between strict-lane facts linked to requirements. When a contradiction is found, the supported escape hatch is `supersedes`: create a new requirement that supersedes the old one, then link the new requirement to updated facts.
 

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

@@ -8,7 +8,7 @@ Logical coverage is clause-based, not entity-based. Give `kb_semantic_advisor` t
 
 - 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;
-- link it through exactly one `requires_property` for `property_value` or one `requires_predicate` for `predicate`;
+- 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`.
 
 Use the advisor-returned atomic inventory as the identity boundary. Trailing punctuation and copied conjunction commas are formatting, not new claims. `logic-coverage` rejects one claim grounded by multiple facts and distinct claim keys that resolve to the same ground logical term.
@@ -76,6 +76,16 @@ If another current requirement links an `assert` fact with the same predicate na
 
 The full logical representation of a requirement is the conjunction of all of its linked ground property and predicate terms. Conditions, exceptions, permissions, and ordering constraints remain explicit arguments of their declared schemas. Contradiction detection therefore depends on equivalent prose reusing the same predicate name, argument roles, ordered canonical values, and opposing polarity rather than inventing synonymous terms.
 
+### Lane gates before a predicate lookup
+
+Treat the advisor's proposition status as a hard routing decision. `nonlogical`/`subjective` prose is not a logical claim: keep it as one observation when needed and do not add its key to `logic_claims`. `ambiguous` prose stays an ambiguity observation. `ontology_gap` prose stays unresolved unless an approved schema or validated Logic IR is available. Never split a subjective or commentary sentence into synthetic clauses just because it contains conditional words or domain vocabulary.
+
+If authorized input supplies `projectLocalSchemas`, use those signatures as the authority. Create the minimal `predicate_schema` endpoint before lookup, then rerun `kb_suggest_predicates` on the complete relation if the first lookup had no candidate. Apply exactly one ground predicate and one claim key for that relation. For `must not`, `never`, `cannot`, or `forbidden` wording, preserve the positive schema and set `polarity: deny`; do not turn the result into an asserted predicate or invent a negative name. An empty lookup before the declared schema exists is a retry condition, not proof of an ontology gap.
+
+## Typed rule lane
+
+Use a validated `kibi.logic.v1` object for a proposition whose meaning includes a condition, exception, obligation, prohibition, permission, quantifier, cardinality bound, or bounded temporal relation. `kb_model_requirement` returns the `rule_schema` and `rule` facts plus a `requires_rule` edge. The rule stores canonical JSON and a deterministic hash; any rendered Prolog is an audit view and is never executed. Reject raw goals, function symbols, cuts, meta-calls, dynamic predicates, I/O, unsafe variables, unstratified negation, and unbounded aggregation. Keep the exact proposition in `claim_text`, its advisor key in `claim_key`, and its byte span in the semantic ledger. Run `rule-safety` and `rule-verifiability` before treating the rule as modeled.
+
 ### Strict scalar
 
 Claim: “Sessions expire after at most 30 minutes.” This is a scalar limit, not a predicate. Route it through `kb_model_requirement` to a subject plus `property_value` with `operator: lte`, `value_type: int`, and `value_int: 30`, linked by `constrains` and `requires_property`.

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

@@ -0,0 +1,43 @@
+# Typed Logic IR and Proposition Coverage
+
+Kibi stores human prose as readable requirement text, but verifiable meaning belongs in typed facts and `kibi.logic.v1` rule facts. The host agent may propose an interpretation; Kibi validates, canonicalizes, hashes, persists, and reasons over it. Never submit a Prolog source string, goal, module, or function symbol. Rendered Prolog is an inspection preview only.
+
+## Two-pass extraction
+
+1. Run `kb_semantic_advisor` over the complete text. Supply explicit `clauses` when sentence splitting could hide a condition, exception, definition, descriptive assertion, threshold, quantity, or temporal qualifier.
+2. Audit the returned `propositions` against the original UTF-8 text. Every assertive span must be `modeled`, `ambiguous`, `ontology_gap`, or `missing`; rationale, examples, and subjective commentary are `nonlogical` and remain readable prose.
+3. For each assertive proposition, submit up to three typed `interpretations` when alternatives are plausible. Kibi compares canonical semantic keys; materially different valid interpretations remain unresolved regardless of confidence.
+4. Apply only a validated plan, then read back the requirement, rule schema, rule fact, and all relationship targets. Run `rule-safety`, `rule-verifiability`, `semantic-completeness`, `logic-coverage`, and `domain-contradictions` before the final unfiltered check.
+
+When a project-local schema names several ordered arguments, those arguments are facets of one relation, not separate propositions. Preserve the advisor claim key for the complete relation and do not manufacture clauses for each argument. Supporting `predicate_schema` facts carry the declared signature only; the ground predicate fact carries the claim provenance. Apply the exact `kb_suggest_predicates`/`kb_model_requirement` plan, reducing a rejected schema payload through `kb_validate_upsert` rather than silently downgrading a fitting declared relation to an observation.
+
+## Logic IR shape
+
+The supported v1 forms are:
+
+- `kind: atom` with a ground `head`;
+- `kind: rule` with a range-restricted `head` and `body`;
+- `kind: constraint` with a body and no head.
+
+Terms are typed `const`, `var`, `number`, `duration`, or ISO `timestamp`. Variables are explicitly declared as `forall` (the default) or body-local `exists`; an existential variable may not occur in a rule head. Bodies use `all`, `any`, closed-world `not`, comparisons, bounded `count`, and bounded temporal expressions. Modalities are `assert`, `deny`, `oblige`, `permit`, and `forbid`.
+
+Every head and body variable must be bound by a positive atom. Negation is allowed only on an atom with `closedWorld: true`, and only when its variables are also positively bound. Function symbols, raw goals, cuts, meta-calls, dynamic predicates, I/O, unbounded aggregation, unsafe variables, and unstratified negation are rejected before persistence.
+
+Example (inspection data, not executable input):
+
+```json
+{
+  "version": "kibi.logic.v1",
+  "kind": "rule",
+  "modality": "oblige",
+  "variables": [{"name": "U", "type": "user", "quantifier": "forall"}],
+  "head": {"kind": "atom", "name": "audit", "args": [{"kind": "var", "name": "U", "type": "user"}]},
+  "body": {"kind": "atom", "name": "admin_action", "args": [{"kind": "var", "name": "U", "type": "user"}]}
+}
+```
+
+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.
+
+## Contradictions and uncertainty
+
+Kibi compares opposing modalities over matching heads and overlapping authority, scope, and validity intervals. `assert`/`deny`, `oblige`/`forbid`, and overlapping `permit`/`forbid` pairs can be contradictory. Different conditions, unresolved interpretations, unsupported ontology terms, analysis limits, and incomplete closure produce `unresolved`, never a false consistency proof. Preserve superseding requirements rather than deleting historical claims.

package/dist/public/skills/kibi-usage/resources/operation-access.md

@@ -2,26 +2,26 @@
 
 This table is the machine-readable interface map for Kibi's shared operation catalog. Every CLI route shown is dedicated; there is no generic operation runner. `--input JSON or flags` means the route supports exact MCP-shaped JSON from a file or stdin as well as its established human flags. `--input JSON` means the dedicated parity route is JSON-only.
 
-| MCP tool name | CLI route | Input mode | Mutability | Requires Prolog | Effects | Capability preference |
+| MCP tool name | CLI route | Input mode | Mutability | Requires Prolog | Effects | Interface |
 |---|---|---|---|---|---|---|
-| `kb_skills_list` | `skills-list` | `--input JSON` | read | no | `local-read` | MCP-first; CLI-fallback |
-| `kb_skills_load` | `skills-load` | `--input JSON` | read | no | `local-read` | MCP-first; CLI-fallback |
-| `kb_skills_read` | `skills-read` | `--input JSON` | read | no | `local-read` | MCP-first; CLI-fallback |
-| `kb_query` | `query` | `--input JSON or flags` | read | yes | `kb-read` | MCP-first; CLI-fallback |
-| `kb_search` | `search` | `--input JSON or flags` | read | yes | `kb-read` | MCP-first; CLI-fallback |
-| `kb_status` | `status` | `--input JSON or flags` | read | yes | `kb-read, workspace-read` | MCP-first; CLI-fallback |
-| `kb_find_gaps` | `find-gaps` | `--input JSON or flags` | read | yes | `kb-read` | MCP-first; CLI-fallback |
-| `kb_coverage` | `coverage` | `--input JSON or flags` | read | yes | `kb-read` | MCP-first; CLI-fallback |
-| `kb_graph` | `graph` | `--input JSON or flags` | read | yes | `kb-read` | MCP-first; CLI-fallback |
-| `kb_semantic_advisor` | `semantic-advisor` | `--input JSON` | read | no | `local-read` | MCP-first; CLI-fallback |
-| `kb_model_requirement` | `model-requirement` | `--input JSON` | read | yes | `kb-read` | MCP-first; CLI-fallback |
-| `kb_suggest_predicates` | `suggest-predicates` | `--input JSON` | read | yes | `kb-read` | MCP-first; CLI-fallback |
-| `kb_autopilot_generate` | `autopilot-generate` | `--input JSON` | read | no | `workspace-read` | MCP-first; CLI-fallback |
-| `kb_validate_upsert` | `validate-upsert` | `--input JSON` | read | yes | `kb-read` | MCP-first; CLI-fallback |
-| `kb_upsert` | `upsert` | `--input JSON` | write | yes | `kb-write, workspace-write` | MCP-first; CLI-fallback |
-| `kb_delete` | `delete` | `--input JSON` | write | yes | `kb-write, workspace-write` | MCP-first; CLI-fallback |
-| `kb_check` | `check` | `--input JSON or flags` | read | yes | `kb-read, workspace-read` | MCP-first; CLI-fallback |
-| `kb_sparql_remote` | `sparql-remote` | `--input JSON` | read | no | `network-read` | MCP-first; CLI-fallback |
+| `kb_skills_list` | `skills-list` | `--input JSON` | read | no | `local-read` | peer; capability-selected |
+| `kb_skills_load` | `skills-load` | `--input JSON` | read | no | `local-read` | peer; capability-selected |
+| `kb_skills_read` | `skills-read` | `--input JSON` | read | no | `local-read` | peer; capability-selected |
+| `kb_query` | `query` | `--input JSON or flags` | read | yes | `kb-read` | peer; capability-selected |
+| `kb_search` | `search` | `--input JSON or flags` | read | yes | `kb-read` | peer; capability-selected |
+| `kb_status` | `status` | `--input JSON or flags` | read | yes | `kb-read, workspace-read` | peer; capability-selected |
+| `kb_find_gaps` | `find-gaps` | `--input JSON or flags` | read | yes | `kb-read` | peer; capability-selected |
+| `kb_coverage` | `coverage` | `--input JSON or flags` | read | yes | `kb-read` | peer; capability-selected |
+| `kb_graph` | `graph` | `--input JSON or flags` | read | yes | `kb-read` | peer; capability-selected |
+| `kb_semantic_advisor` | `semantic-advisor` | `--input JSON` | read | no | `local-read` | peer; capability-selected |
+| `kb_model_requirement` | `model-requirement` | `--input JSON` | read | yes | `kb-read` | peer; capability-selected |
+| `kb_suggest_predicates` | `suggest-predicates` | `--input JSON` | read | yes | `kb-read` | peer; capability-selected |
+| `kb_autopilot_generate` | `autopilot-generate` | `--input JSON` | read | no | `workspace-read` | peer; capability-selected |
+| `kb_validate_upsert` | `validate-upsert` | `--input JSON` | read | yes | `kb-read` | peer; capability-selected |
+| `kb_upsert` | `upsert` | `--input JSON` | write | yes | `kb-write, workspace-write` | peer; capability-selected |
+| `kb_delete` | `delete` | `--input JSON` | write | yes | `kb-write, workspace-write` | peer; capability-selected |
+| `kb_check` | `check` | `--input JSON or flags` | read | yes | `kb-read, workspace-read` | peer; capability-selected |
+| `kb_sparql_remote` | `sparql-remote` | `--input JSON` | read | no | `network-read` | peer; capability-selected |
 
 ## JSON execution recipes
 

package/dist/public/skills/kibi-usage/resources/ui-requirements.md

@@ -0,0 +1,96 @@
+# UI / Visual Requirement Modeling
+
+Optional, per-project lane for recording what the screen should look like so UI edits cannot
+silently drift from the spec. Non-UI projects skip it entirely; no check rule requires it.
+
+## Three layers
+
+1. **Prose `req`** — the full on-screen description lives in the requirement body as the
+   searchable anchor agents discover with `kb_search` / `kb_query`.
+2. **Strict facts** — checkable visual invariants as `fact_kind: subject` (`subject_key`,
+   linked `constrains`) plus `fact_kind: property_value` (`property_key`, `operator`, typed
+   `value_*`, linked `requires_property`). Incompatible values on the same subject/property
+   from two current requirements are rejected on write unless `supersedes`.
+3. **Relational predicates** — ground `fact_kind: predicate` linked with `requires_predicate`.
+   The built-in `visual_layout_rule(subject, relation, target)` covers "X must remain visually
+   aligned with Y" (relation `aligned_with`). Other relational layout claims need a
+   project-local `predicate_schema` when the task authorizes ontology extension.
+
+Kibi enforces stated facts and links, not pixels. Freeform spatial prose is stored and
+searchable but is not machine-checked.
+
+## Button position
+
+```yaml
+id: FACT-UI-SUBMIT-REGION
+fact_kind: subject
+subject_key: settings.screen.submit_button
+```
+
+```yaml
+id: FACT-UI-SUBMIT-POSITION
+fact_kind: property_value
+subject_key: settings.screen.submit_button
+property_key: position
+operator: eq
+value_type: string
+value_string: bottom_right
+canonical_key: settings.screen.submit_button.position.eq.bottom_right
+```
+
+Link both facts from the requirement:
+
+```yaml
+id: REQ-UI-SETTINGS
+relationships:
+  - type: constrains
+    from: REQ-UI-SETTINGS
+    to: FACT-UI-SUBMIT-REGION
+  - type: requires_property
+    from: REQ-UI-SETTINGS
+    to: FACT-UI-SUBMIT-POSITION
+```
+
+A later requirement writing `position: top_left` on the same subject is rejected on write.
+
+## Header item order
+
+Use one indexed `property_key` per slot against the same subject region:
+`nav_order_1: home`, `nav_order_2: search`, `nav_order_3: profile`, each as a separate
+`property_value` fact linked with `requires_property`. This makes each slot independently
+contradiction-checkable.
+
+## Relational alignment
+
+```yaml
+id: FACT-UI-NAV-ALIGN
+fact_kind: predicate
+predicate_name: visual_layout_rule
+predicate_args: [navigation_rail, aligned_with, header]
+polarity: assert
+canonical_key: visual_layout_rule(navigation_rail,aligned_with,header)
+```
+
+Link with `requires_predicate`. An `assert`/`deny` pair over the same predicate namespace,
+name, and ordered arguments is a blocking `domain-contradictions` conflict.
+
+## UI component traceability
+
+Model the component as a `symbol` with `sourceFile` and `symbol_role: behavioral`, linked
+`implements` to the requirement, so component edits surface the visual spec in impact
+diagnostics (`symbol_semantic_review_needed`).
+
+## Workflow
+
+1. `kb_semantic_advisor` on the full description; audit or supply `clauses`.
+2. Relational clauses: `kb_suggest_predicates`, apply the predicate plan and
+   `requires_predicate`.
+3. Scalar placement/alignment/order clauses: `kb_model_requirement`, apply the strict
+   subject/property plan and `constrains` / `requires_property`.
+4. Preserve `claim_key` / `claim_text`; merge every key into the requirement
+   `logic_claims` manifest.
+5. `kb_validate_upsert`, create endpoints first, then sequential `kb_upsert`.
+6. `kb_check` with `logic-coverage`, `predicate-verifiability`, `domain-contradictions`,
+   then a final unfiltered `kb_check`.
+
+Non-UI projects: declare `has_ui: false` during bootstrap and no UI entities are proposed.

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

@@ -8,13 +8,13 @@ The canonical workflow for any KB operation follows this pattern:
 2. **Confirm**: `kb_query` for exact IDs and state
 3. **Inspect**: `kb_status` when freshness matters
 4. **Decompose**: `kb_semantic_advisor` on the complete normative prose; verify or supply every atomic clause
-5. **Choose per-clause lanes**: `kb_suggest_predicates` for relational clauses; `kb_model_requirement` for strict scalar clauses; observation review for ambiguity, false positives, and ontology gaps
+5. **Choose per-clause lanes**: strict facts for scalar claims; `kb_suggest_predicates` for approved ground ontology relations; `kb_model_requirement` with `kibi.logic.v1` for conditions, exceptions, modalities, quantifiers, cardinality, and bounded temporal rules; observation review for ambiguity, nonlogical prose, and ontology gaps
 6. **Preflight**: `kb_validate_upsert` for every intended entity or relationship payload
 7. **Create endpoints**: validated `kb_upsert` for new entities, sequentially
-8. **Link**: validated `kb_upsert` with `requires_predicate`, `constrains`, or `requires_property`, sequentially
-9. **Validate coverage and consistency**: targeted `logic-coverage`, `predicate-verifiability`, and `domain-contradictions`, then final full `kb_check`
+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`
 
-Every current requirement without `logic_claims` remains visible as non-blocking backfill debt. Once a manifest exists, the default unfiltered check enforces its correspondence to linked ground facts.
+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.
 
 ## Creating a New Feature
 ```
@@ -47,8 +47,9 @@ Keep the original requirement body readable throughout this workflow.
 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`.
 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. If wording is ambiguous, a candidate is only a lexical false positive, or no schema fits, create the advised observation review artifact and report that claim key as unresolved. Use `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.
-7. Read back the requirement and all facts. Confirm every manifest key occurs on exactly one intended ground fact, no punctuation variant minted a second claim, and no two claim keys encode the same logical term. Exact query output may represent repeated relationship types as arrays, so inspect every target. Then run `kb_check` with `logic-coverage`, `predicate-verifiability`, and `domain-contradictions`. Finish with an unfiltered `kb_check`.
+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.
+8. Read back the requirement, proposition ledger, and all facts. Confirm every manifest key occurs on exactly one intended ground fact/rule, no punctuation variant minted a second claim, and no two claim keys encode the same logical term. Exact query output may represent repeated relationship types as arrays, so inspect every target. Then run `kb_check` with `rule-safety`, `rule-verifiability`, `semantic-completeness`, `logic-coverage`, `predicate-verifiability`, and `domain-contradictions`. Finish with an unfiltered `kb_check`.
 
 Do not treat the manifest itself as proof of grounding. The advisor keeps readiness partial while there are fewer logical edge slots than normative claims; final readback and `logic-coverage` bind those slots to exact claim keys and ground terms.
 
@@ -56,6 +57,20 @@ Examples: built-in permission and deny claims use the suggested `permission_rule
 
 On resume after interruption, repeat `kb_query` for exact endpoints and apply only missing validated writes. Keep `kb_upsert` concurrency at one.
 
+## UI / Visual Requirement Modeling
+
+Optional per-project workflow for recording what the screen should look like. Non-UI projects skip this lane entirely.
+
+1. Create a prose `req` holding the full visual description; it is the searchable anchor agents discover before touching a UI file.
+2. Run `kb_semantic_advisor` on the description; audit or supply `clauses`.
+3. For relational layout clauses ("X must remain visually aligned with Y"), call `kb_suggest_predicates`, apply the returned `fact_kind: predicate` plan with `predicate_name: visual_layout_rule` and `requires_predicate`.
+4. For scalar placement, alignment, and ordering clauses, call `kb_model_requirement` and apply strict `fact_kind: subject` / `fact_kind: property_value` facts linked with `constrains` / `requires_property`. Model header order as indexed property keys (`nav_order_1`, `nav_order_2`, ...) against one subject region.
+5. Preserve `claim_key` / `claim_text` on every ground fact and merge every key into the requirement `logic_claims` manifest.
+6. Model UI components as `symbol` entities with `sourceFile` and `symbol_role: behavioral`, linked `implements` to the requirement.
+7. `kb_validate_upsert`, create endpoints first, then sequential `kb_upsert`. Run `kb_check` with `logic-coverage`, `predicate-verifiability`, and `domain-contradictions`, then a final unfiltered `kb_check`.
+
+Incompatible values on the same subject/property from two current requirements are rejected on write; change an intentional value via a replacement requirement linked with `supersedes`. Full payloads are in `resources/ui-requirements.md`.
+
 ## Fixing a Traceability Gap
 ```
 1. kb_query --sourceFile <code-file> to find linked entities

package/dist/public/symbol-granularity.d.ts

@@ -4,6 +4,14 @@ export declare const TRACEABILITY_RELATIONSHIP_TYPES: readonly ["implements", "c
 export type TraceabilityRelationshipType = (typeof TRACEABILITY_RELATIONSHIP_TYPES)[number];
 export declare const ALLOWED_GRANULARITY_REASONS: readonly ["config-artifact", "module-level-behavior", "extractor-miss", "legacy-link"];
 export type GranularityReason = (typeof ALLOWED_GRANULARITY_REASONS)[number];
+/**
+ * Granularity reasons that document coarse file/module-level coverage for which
+ * generated per-symbol coordinates are not expected. These anchors legitimately
+ * carry no coordinate artifact entries. `legacy-link` is intentionally excluded:
+ * it is a canonical reason but still coordinates a real extractable symbol.
+ */
+export declare const COARSE_GRANULARITY_REASONS: readonly ["config-artifact", "module-level-behavior", "extractor-miss", "test-suite"];
+export type CoarseGranularityReason = (typeof COARSE_GRANULARITY_REASONS)[number];
 export type SymbolKind = "function" | "class" | "method" | "property" | "accessor" | "interface" | "type" | "variable" | "enum" | "unknown";
 export type SourceSymbolKind = SymbolKind;
 export interface GranularSymbolCandidate {
@@ -16,6 +24,7 @@ export declare const inferSymbolRoleFromKind: typeof inferSymbolRole;
 export declare function isSymbolRole(value: unknown): value is SymbolRole;
 export declare function isTraceabilityRelationshipType(value: unknown): value is TraceabilityRelationshipType;
 export declare function isAllowedGranularityReason(value: unknown): value is GranularityReason;
+export declare function isCoarseGranularityReason(value: unknown): value is CoarseGranularityReason;
 export declare function getSymbolRole(candidate: GranularSymbolCandidate): SymbolRole;
 export declare function isBehavioralSymbol(candidate: GranularSymbolCandidate): boolean;
 export declare function getBehavioralSymbolNames(candidates: GranularSymbolCandidate[]): string[];

package/dist/public/symbol-granularity.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"symbol-granularity.d.ts","sourceRoot":"","sources":["../../src/public/symbol-granularity.ts"],"names":[],"mappings":"AAAA,eAAO,MAAM,YAAY,oFAOf,CAAC;AAEX,MAAM,MAAM,UAAU,GAAG,CAAC,OAAO,YAAY,CAAC,CAAC,MAAM,CAAC,CAAC;AAEvD,eAAO,MAAM,+BAA+B,yDAIlC,CAAC;AAEX,MAAM,MAAM,4BAA4B,GACtC,CAAC,OAAO,+BAA+B,CAAC,CAAC,MAAM,CAAC,CAAC;AAEnD,eAAO,MAAM,2BAA2B,wFAK9B,CAAC;AAEX,MAAM,MAAM,iBAAiB,GAAG,CAAC,OAAO,2BAA2B,CAAC,CAAC,MAAM,CAAC,CAAC;AAE7E,MAAM,MAAM,UAAU,GAClB,UAAU,GACV,OAAO,GACP,QAAQ,GACR,UAAU,GACV,UAAU,GACV,WAAW,GACX,MAAM,GACN,UAAU,GACV,MAAM,GACN,SAAS,CAAC;AAEd,MAAM,MAAM,gBAAgB,GAAG,UAAU,CAAC;AAE1C,MAAM,WAAW,uBAAuB;IACtC,IAAI,EAAE,MAAM,CAAC;IACb,IAAI,CAAC,EAAE,UAAU,CAAC;IAClB,IAAI,CAAC,EAAE,UAAU,CAAC;CACnB;AASD,wBAAgB,eAAe,CAAC,IAAI,EAAE,UAAU,GAAG,UAAU,CAgB5D;AAED,eAAO,MAAM,uBAAuB,wBAAkB,CAAC;AAEvD,wBAAgB,YAAY,CAAC,KAAK,EAAE,OAAO,GAAG,KAAK,IAAI,UAAU,CAIhE;AAED,wBAAgB,8BAA8B,CAC5C,KAAK,EAAE,OAAO,GACb,KAAK,IAAI,4BAA4B,CAIvC;AAED,wBAAgB,0BAA0B,CACxC,KAAK,EAAE,OAAO,GACb,KAAK,IAAI,iBAAiB,CAE5B;AAED,wBAAgB,aAAa,CAAC,SAAS,EAAE,uBAAuB,GAAG,UAAU,CAI5E;AAED,wBAAgB,kBAAkB,CAChC,SAAS,EAAE,uBAAuB,GACjC,OAAO,CAET;AAED,wBAAgB,wBAAwB,CACtC,UAAU,EAAE,uBAAuB,EAAE,GACpC,MAAM,EAAE,CAMV;AAED,wBAAgB,2BAA2B,CACzC,UAAU,EAAE,uBAAuB,EAAE,GACpC,MAAM,EAAE,CAQV"}
+{"version":3,"file":"symbol-granularity.d.ts","sourceRoot":"","sources":["../../src/public/symbol-granularity.ts"],"names":[],"mappings":"AAAA,eAAO,MAAM,YAAY,oFAOf,CAAC;AAEX,MAAM,MAAM,UAAU,GAAG,CAAC,OAAO,YAAY,CAAC,CAAC,MAAM,CAAC,CAAC;AAEvD,eAAO,MAAM,+BAA+B,yDAIlC,CAAC;AAEX,MAAM,MAAM,4BAA4B,GACtC,CAAC,OAAO,+BAA+B,CAAC,CAAC,MAAM,CAAC,CAAC;AAEnD,eAAO,MAAM,2BAA2B,wFAK9B,CAAC;AAEX,MAAM,MAAM,iBAAiB,GAAG,CAAC,OAAO,2BAA2B,CAAC,CAAC,MAAM,CAAC,CAAC;AAE7E;;;;;GAKG;AACH,eAAO,MAAM,0BAA0B,uFAK7B,CAAC;AAEX,MAAM,MAAM,uBAAuB,GACjC,CAAC,OAAO,0BAA0B,CAAC,CAAC,MAAM,CAAC,CAAC;AAE9C,MAAM,MAAM,UAAU,GAClB,UAAU,GACV,OAAO,GACP,QAAQ,GACR,UAAU,GACV,UAAU,GACV,WAAW,GACX,MAAM,GACN,UAAU,GACV,MAAM,GACN,SAAS,CAAC;AAEd,MAAM,MAAM,gBAAgB,GAAG,UAAU,CAAC;AAE1C,MAAM,WAAW,uBAAuB;IACtC,IAAI,EAAE,MAAM,CAAC;IACb,IAAI,CAAC,EAAE,UAAU,CAAC;IAClB,IAAI,CAAC,EAAE,UAAU,CAAC;CACnB;AAYD,wBAAgB,eAAe,CAAC,IAAI,EAAE,UAAU,GAAG,UAAU,CAgB5D;AAED,eAAO,MAAM,uBAAuB,wBAAkB,CAAC;AAEvD,wBAAgB,YAAY,CAAC,KAAK,EAAE,OAAO,GAAG,KAAK,IAAI,UAAU,CAIhE;AAED,wBAAgB,8BAA8B,CAC5C,KAAK,EAAE,OAAO,GACb,KAAK,IAAI,4BAA4B,CAIvC;AAED,wBAAgB,0BAA0B,CACxC,KAAK,EAAE,OAAO,GACb,KAAK,IAAI,iBAAiB,CAE5B;AAED,wBAAgB,yBAAyB,CACvC,KAAK,EAAE,OAAO,GACb,KAAK,IAAI,uBAAuB,CAElC;AAED,wBAAgB,aAAa,CAAC,SAAS,EAAE,uBAAuB,GAAG,UAAU,CAI5E;AAED,wBAAgB,kBAAkB,CAChC,SAAS,EAAE,uBAAuB,GACjC,OAAO,CAET;AAED,wBAAgB,wBAAwB,CACtC,UAAU,EAAE,uBAAuB,EAAE,GACpC,MAAM,EAAE,CAMV;AAED,wBAAgB,2BAA2B,CACzC,UAAU,EAAE,uBAAuB,EAAE,GACpC,MAAM,EAAE,CAQV"}

package/dist/public/symbol-granularity.js

@@ -17,8 +17,21 @@ export const ALLOWED_GRANULARITY_REASONS = [
     "extractor-miss",
     "legacy-link",
 ];
+/**
+ * Granularity reasons that document coarse file/module-level coverage for which
+ * generated per-symbol coordinates are not expected. These anchors legitimately
+ * carry no coordinate artifact entries. `legacy-link` is intentionally excluded:
+ * it is a canonical reason but still coordinates a real extractable symbol.
+ */
+export const COARSE_GRANULARITY_REASONS = [
+    "config-artifact",
+    "module-level-behavior",
+    "extractor-miss",
+    "test-suite",
+];
 const traceabilityRelationshipTypeSet = new Set(TRACEABILITY_RELATIONSHIP_TYPES);
 const allowedGranularityReasonSet = new Set(ALLOWED_GRANULARITY_REASONS);
+const coarseGranularityReasonSet = new Set(COARSE_GRANULARITY_REASONS);
 export function inferSymbolRole(kind) {
     switch (kind) {
         case "function":
@@ -46,6 +59,9 @@ export function isTraceabilityRelationshipType(value) {
 export function isAllowedGranularityReason(value) {
     return typeof value === "string" && allowedGranularityReasonSet.has(value);
 }
+export function isCoarseGranularityReason(value) {
+    return typeof value === "string" && coarseGranularityReasonSet.has(value);
+}
 export function getSymbolRole(candidate) {
     if (candidate.role)
         return candidate.role;