@vess-id/ai-identity 0.19.0 → 0.20.0

package/dist/registry/__tests__/action-registry-doc-review.spec.d.ts

@@ -0,0 +1,14 @@
+/**
+ * Tests for the doc_review.submit_response action in ACTION_REGISTRY.
+ *
+ * doc_review.submit_response is the response leg of the doc-review A2A task
+ * (Phase D). Like scheduling.submit_response it is an internal inbox write
+ * (no external OAuth), carries the single nominal base scope `inbox`, and is
+ * risk:'high' so it never skips the human-approval leg. Findings are computed
+ * LLM-side; the server only validates the shape. Its tool name is auto-derived
+ * from the first action segment ('doc_review').
+ *
+ * Spec: A2A Phase D doc-review design §3.1
+ */
+export {};
+//# sourceMappingURL=action-registry-doc-review.spec.d.ts.map

package/dist/registry/__tests__/action-registry-doc-review.spec.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"action-registry-doc-review.spec.d.ts","sourceRoot":"","sources":["../../../src/registry/__tests__/action-registry-doc-review.spec.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;GAWG"}

package/dist/registry/__tests__/action-risk.spec.d.ts

@@ -8,7 +8,12 @@
  * Phase 1 baseline rule (registry-free, deterministic):
  *   - HIGH_RISK_SUFFIXES → 'high'
  *   - LOW_RISK_SUFFIXES  → 'low'
- *   - everything else    → 'medium' (fail-safe default)
+ *   - everything else    → 'high'   (fail-CLOSED default, #1285)
+ *
+ * The default was 'medium' until #1285. That was not fail-safe: the Cedar
+ * default policy permits low and medium unconditionally
+ * (api/src/grant/services/system-policy.service.ts:105), so an unregistered
+ * action landed on the permit side AND skipped Gate-2 resource pinning.
  *
  * Classification is based on the **last dotted segment** of the action
  * name (case-insensitive).

package/dist/registry/__tests__/action-risk.spec.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"action-risk.spec.d.ts","sourceRoot":"","sources":["../../../src/registry/__tests__/action-risk.spec.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;GAcG"}
+{"version":3,"file":"action-risk.spec.d.ts","sourceRoot":"","sources":["../../../src/registry/__tests__/action-risk.spec.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;GAmBG"}

package/dist/registry/__tests__/salient-completeness.spec.d.ts

@@ -0,0 +1,43 @@
+/**
+ * Salient-field completeness test (P1 / #1205, Step 2).
+ *
+ * The decision-bound authorization design (docs/proposals/1205-P1-...) binds a
+ * hash of the approval-critical ("salient") parameters into the signed VC. The
+ * PEP later refuses to adopt a VC approval whose executed params do not hash to
+ * the committed value. For that binding to actually protect an action, the
+ * action MUST declare a `approval_salient_fields` set — otherwise the digest is
+ * `undefined`, the issuer omits `params_hash`, and the salient gate silently
+ * degrades to a no-op (plan §6 "salient set 無しのアクション").
+ *
+ * The set of actions that go through OOB (out-of-band) human approval is
+ * exactly the set of high-risk actions: the approval flow's
+ * `validateHighRiskResources` (packages/api/.../narrow-delegates.ts) filters
+ * on `risk === 'high' || risk === 'critical'`, and `resolveActionRisk` returns
+ * the registry `risk` verbatim. So the predicate here is registry
+ * `risk ∈ {high, critical}` — the exact set that mints an OOB approval.
+ *
+ * This test is the guard the plan (§0.5) relies on to catch the class of bug
+ * where a salient field name is a typo that does not exist in the action's
+ * input_schema (the plan's own `pr_number` example — the real github field is
+ * `pullNumber`). It asserts, for every approval-gated action:
+ *   1. a non-empty `approval_salient_fields` is declared;
+ *   2. every declared field name exists in `input_schema.properties`;
+ *   3. no declared field is typed as a non-integer number (float ban, rule 5);
+ *   4. the salient set includes the resource-binding param(s) so it agrees with
+ *      `canonicalResourceId`'s resource extraction (plan §6: salient ⊇
+ *      resource-binding);
+ *   5. UNDER-INCLUSION heuristic: no input_schema property whose NAME matches a
+ *      known-dangerous pattern (ownership/targeting or effect/destructiveness
+ *      flags) is silently OMITTED from the salient set unless it is in an
+ *      explicit, documented allowlist.
+ *
+ * Two caveats on the guarantee this file provides:
+ *   (a) under-inclusion is now HEURISTICALLY guarded (assertion 5), but the
+ *       heuristic only catches name-pattern matches — human security judgment is
+ *       still required to decide the substance-of-approval fields for each action;
+ *   (b) a user/Cedar policy can only REMOVE actions from approval (narrow), never
+ *       add, so binding the registry high|critical set is a safe SUPERSET of what
+ *       actually reaches OOB approval.
+ */
+export {};
+//# sourceMappingURL=salient-completeness.spec.d.ts.map

package/dist/registry/__tests__/salient-completeness.spec.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"salient-completeness.spec.d.ts","sourceRoot":"","sources":["../../../src/registry/__tests__/salient-completeness.spec.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAwCG"}