@vess-id/ai-identity 0.20.0 → 0.22.0

package/dist/registry/__tests__/action-input-validator.spec.d.ts

@@ -1,10 +0,0 @@
-/**
- * Tests for validateActionInput — lightweight registry-schema validation of
- * tool-call parameters, run at the callTool entry point (before approval / VC
- * gates) so malformed AI calls fail fast with self-correcting diagnostics
- * instead of minting an approval request that later fails on invoke.
- *
- * Task 20: 承認リクエスト発行前のパラメータ形状検証.
- */
-export {};
-//# sourceMappingURL=action-input-validator.spec.d.ts.map

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

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

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

@@ -1,14 +0,0 @@
-/**
- * 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

@@ -1 +0,0 @@
-{"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-registry-freebusy.spec.d.ts

@@ -1,13 +0,0 @@
-/**
- * Tests for the calendar.freebusy action in ACTION_REGISTRY.
- *
- * calendar.freebusy is a read-only availability probe used to check whether a
- * calendar is busy over a time window before proposing meeting slots. It never
- * returns event details (only busy/free intervals), so it stays in the
- * low-risk `calendar.read.basic` capability alongside calendar.event.list /
- * calendar.event.read.
- *
- * Spec: docs/specs/2026-07-03-scheduling-wow-phase1-design.md §4.1
- */
-export {};
-//# sourceMappingURL=action-registry-freebusy.spec.d.ts.map

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

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

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

@@ -1,9 +0,0 @@
-/**
- * Tests for the Agent Inbox actions registered in ACTION_REGISTRY.
- *
- * The 5 inbox.* actions back the Agent Inbox MCP tools so they can be
- * exposed and Cedar-evaluated. Risk levels are part of the security contract
- * (inbox.send sends a task request to another person → high).
- */
-export {};
-//# sourceMappingURL=action-registry-inbox.spec.d.ts.map

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

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

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

@@ -1,13 +0,0 @@
-/**
- * Tests for the scheduling.request façade action in ACTION_REGISTRY.
- *
- * scheduling.request is a meeting-time negotiation façade over inbox.send.
- * Candidate slots are computed LLM-side; the server only validates. The
- * action is internal (no external OAuth), so it carries the single nominal
- * base scope `inbox`. Its tool name is auto-derived from the first action
- * segment ('scheduling').
- *
- * Spec: docs/specs/2026-06-10-inbox-intent-routing-design.md §2.1
- */
-export {};
-//# sourceMappingURL=action-registry-scheduling.spec.d.ts.map

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

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

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

@@ -1,13 +0,0 @@
-/**
- * Tests for actionMetaSchema validation — `risk` is a REQUIRED field.
- *
- * Spec ref:
- * - docs/specs/2026-05-27-action-risk-registry-driven.md §4.1
- *
- * Rationale: risk resolution is now registry-driven (RT1). An action added
- * without a `risk` field would silently fall back to the suffix heuristic in
- * Cedar (e.g. `os.secret.read` → low → auto-permit), a security regression.
- * Making `risk` schema-required turns that omission into a CI failure.
- */
-export {};
-//# sourceMappingURL=action-registry-validation.spec.d.ts.map

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

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

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

@@ -1,15 +0,0 @@
-/**
- * Tests for registry-driven resolveActionRisk (OpenQ-5 root fix).
- *
- * Spec ref:
- * - docs/specs/2026-05-27-action-risk-registry-driven.md §3, §4.2
- *
- * Contract: ACTION_REGISTRY is the single source of truth for risk.
- *   - resolveActionRisk(name) returns the registry `risk` when the action
- *     exists in ACTION_REGISTRY (authoritative).
- *   - Falls back to the suffix heuristic only for unknown (non-registry)
- *     actions.
- *   - Lookup is case-insensitive (input lowercased before Map lookup).
- */
-export {};
-//# sourceMappingURL=action-risk-registry-driven.spec.d.ts.map

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

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

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

@@ -1,22 +0,0 @@
-/**
- * Tests for resolveActionRisk (Cedar unification Step 1).
- *
- * Spec refs:
- * - docs/specs/2026-05-24-cedar-unification-design.md §7.2 (risk_level
- *   resolution rule, Phase 1 baseline)
- *
- * Phase 1 baseline rule (registry-free, deterministic):
- *   - HIGH_RISK_SUFFIXES → 'high'
- *   - LOW_RISK_SUFFIXES  → 'low'
- *   - 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).
- */
-export {};
-//# sourceMappingURL=action-risk.spec.d.ts.map

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

@@ -1 +0,0 @@
-{"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__/guidance-examples.spec.d.ts

@@ -1,2 +0,0 @@
-export {};
-//# sourceMappingURL=guidance-examples.spec.d.ts.map

package/dist/registry/__tests__/guidance-examples.spec.d.ts.map

@@ -1 +0,0 @@
-{"version":3,"file":"guidance-examples.spec.d.ts","sourceRoot":"","sources":["../../../src/registry/__tests__/guidance-examples.spec.ts"],"names":[],"mappings":""}

package/dist/registry/__tests__/high-risk-resource-binding-invariant.spec.d.ts

@@ -1,30 +0,0 @@
-/**
- * Registry invariant — every HIGH-risk action must have a RESOLVABLE
- * resource_id binding (#883 class-killer).
- *
- * Why this exists (2026-07-04): Gate-2 enforcement
- * (`ToolExecutorService.validateVCResourceConstraint`, strict for high risk
- * post-#886) fail-closes any high-risk invocation whose runtime resource
- * cannot be canonicalized (`RESOURCE_UNRESOLVED`) — and issuance pins VC
- * delegates through the SAME function (`canonicalResourceId`, INV-1). An
- * action that is high-risk but has no resolvable binding is therefore
- * IMPOSSIBLE to execute end-to-end: approval succeeds, the VC is pinned, and
- * the invoke still dies at Gate-2. That failure mode shipped at least twice
- * (#883 github write actions; g7.6/7.7/7.13 gmail.message.send unpinned
- * permit-path issuance). This spec turns the class into a test failure at the
- * moment the registry entry is added.
- *
- * Contract per high-risk action:
- *   (a) `canonicalResourceId(action, <schema-faithful params>)` resolves to a
- *       non-empty string — i.e. the binding exists AND its param(s) actually
- *       exist in the action's input_schema (a binding pointing at a param the
- *       schema doesn't carry can never resolve at runtime), OR
- *   (b) the action is on the explicit allowlist below, each entry justified.
- *
- * Adding a high-risk action? Give it `target_bindings.resource_id` bound to a
- * param that exists in `input_schema.properties` (for CREATE actions: the
- * container/parent that exists pre-execution — see the registry header
- * comment), or consciously extend the allowlist with a justification.
- */
-export {};
-//# sourceMappingURL=high-risk-resource-binding-invariant.spec.d.ts.map

package/dist/registry/__tests__/high-risk-resource-binding-invariant.spec.d.ts.map

@@ -1 +0,0 @@
-{"version":3,"file":"high-risk-resource-binding-invariant.spec.d.ts","sourceRoot":"","sources":["../../../src/registry/__tests__/high-risk-resource-binding-invariant.spec.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;GA2BG"}

package/dist/registry/__tests__/reauth-constants.spec.d.ts

@@ -1,2 +0,0 @@
-export {};
-//# sourceMappingURL=reauth-constants.spec.d.ts.map

package/dist/registry/__tests__/reauth-constants.spec.d.ts.map

@@ -1 +0,0 @@
-{"version":3,"file":"reauth-constants.spec.d.ts","sourceRoot":"","sources":["../../../src/registry/__tests__/reauth-constants.spec.ts"],"names":[],"mappings":""}

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

@@ -1,43 +0,0 @@
-/**
- * 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

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

package/dist/types/__tests__/cedar-policy.spec.d.ts

@@ -1,8 +0,0 @@
-/**
- * Tests for Cedar policy types (Phase 1 Step 2).
- *
- * These are opaque wire types — runtime tests only verify the literal values
- * for CedarDecisionValue + shape acceptance for diagnostics.
- */
-export {};
-//# sourceMappingURL=cedar-policy.spec.d.ts.map

package/dist/types/__tests__/cedar-policy.spec.d.ts.map

@@ -1 +0,0 @@
-{"version":3,"file":"cedar-policy.spec.d.ts","sourceRoot":"","sources":["../../../src/types/__tests__/cedar-policy.spec.ts"],"names":[],"mappings":"AAAA;;;;;GAKG"}

package/dist/types/__tests__/permission-vc-v3.spec.d.ts

@@ -1,9 +0,0 @@
-/**
- * Tests for PermissionVcClaims V2/V3 union (Phase 1 Step 2).
- *
- * Spec refs:
- * - docs/specs/2026-05-23-cedar-rar-permission-redesign.md §3.1
- * - docs/specs/2026-05-23-cedar-rar-implementation-plan-phase1.md Task 2.1
- */
-export {};
-//# sourceMappingURL=permission-vc-v3.spec.d.ts.map

package/dist/types/__tests__/permission-vc-v3.spec.d.ts.map

@@ -1 +0,0 @@
-{"version":3,"file":"permission-vc-v3.spec.d.ts","sourceRoot":"","sources":["../../../src/types/__tests__/permission-vc-v3.spec.ts"],"names":[],"mappings":"AAAA;;;;;;GAMG"}

package/dist/types/__tests__/phase1-vc-factory.spec.d.ts

@@ -1,9 +0,0 @@
-/**
- * Tests for Phase 1 VC factory (buildPhase1VcClaims).
- *
- * Spec refs:
- * - docs/specs/2026-05-23-cedar-rar-implementation-plan-phase1.md Task 2.5 (rev 5)
- * - docs/specs/2026-05-23-cedar-rar-permission-redesign.md §3.1 Phase 1 layer 固定 note
- */
-export {};
-//# sourceMappingURL=phase1-vc-factory.spec.d.ts.map

package/dist/types/__tests__/phase1-vc-factory.spec.d.ts.map

@@ -1 +0,0 @@
-{"version":3,"file":"phase1-vc-factory.spec.d.ts","sourceRoot":"","sources":["../../../src/types/__tests__/phase1-vc-factory.spec.ts"],"names":[],"mappings":"AAAA;;;;;;GAMG"}

package/dist/types/__tests__/policy-ref.spec.d.ts

@@ -1,9 +0,0 @@
-/**
- * Tests for PolicyRef discriminated union (Phase 1 Step 2).
- *
- * Spec refs:
- * - docs/specs/2026-05-23-cedar-rar-permission-redesign.md §3.2
- * - docs/specs/2026-05-23-cedar-rar-implementation-plan-phase1.md Task 2.1
- */
-export {};
-//# sourceMappingURL=policy-ref.spec.d.ts.map

package/dist/types/__tests__/policy-ref.spec.d.ts.map

@@ -1 +0,0 @@
-{"version":3,"file":"policy-ref.spec.d.ts","sourceRoot":"","sources":["../../../src/types/__tests__/policy-ref.spec.ts"],"names":[],"mappings":"AAAA;;;;;;GAMG"}