@astrasyncai/verification-gateway 2.5.1 → 3.1.0

package/dist/{types-B3USs-Kx.d.mts → types-Cuh7ELfr.d.mts}

@@ -482,6 +482,22 @@ interface RouteAccessConfig {
     allowedJurisdictions?: string[];
     /** Maximum transaction value for this route */
     maxTransactionValue?: number;
+    /**
+     * Backend-evaluator strict mode (audit F-A1-09): when true AND
+     * `allowedPurposes` is non-empty, verify-access denies requests arriving
+     * WITHOUT a purpose. Configured in the dashboard; passed through here.
+     */
+    requirePurpose?: boolean;
+    /**
+     * SEND-mapping (Bug 14, §4.6) — not an allow-list: the PDLSS tokens the
+     * middleware STAMPS on verify-access calls matching this route, replacing
+     * the generic `data`/`data.*` method-table fallback. `purpose` = bare
+     * category noun (`shopping`, `trading`); `action` = dotted verb
+     * (`shopping.search`, `trading.execute`). Authoritative over agent-supplied
+     * headers — the dashboard is merchant policy, the way MCP toolGates are.
+     */
+    purpose?: string;
+    action?: string;
 }
 /**
  * Express middleware options.
@@ -500,6 +516,15 @@ interface ExpressMiddlewareOptions extends GatewayConfig {
     extractCredentials?: (req: unknown) => AgentCredentials;
     /** Function to extract purpose from request */
     extractPurpose?: (req: unknown) => string | undefined;
+    /**
+     * Function to extract the PDLSS action from a request — symmetric with
+     * `extractPurpose` (Bug 14, §4.6: the action axis previously had NO
+     * override and hardwired the HTTP verb). When configured it masks the
+     * `X-Astra-Action` header step; returning undefined falls through to the
+     * pinned method→action table (GET→data.read, POST/PUT/PATCH→data.write,
+     * DELETE→data.delete). Dashboard route mapping still outranks it.
+     */
+    extractAction?: (req: unknown) => string | undefined;
     /** Skip verification for certain paths */
     skipPaths?: string[];
     /** Custom response for denied requests */

package/dist/{types-B3USs-Kx.d.ts → types-Cuh7ELfr.d.ts}

@@ -482,6 +482,22 @@ interface RouteAccessConfig {
     allowedJurisdictions?: string[];
     /** Maximum transaction value for this route */
     maxTransactionValue?: number;
+    /**
+     * Backend-evaluator strict mode (audit F-A1-09): when true AND
+     * `allowedPurposes` is non-empty, verify-access denies requests arriving
+     * WITHOUT a purpose. Configured in the dashboard; passed through here.
+     */
+    requirePurpose?: boolean;
+    /**
+     * SEND-mapping (Bug 14, §4.6) — not an allow-list: the PDLSS tokens the
+     * middleware STAMPS on verify-access calls matching this route, replacing
+     * the generic `data`/`data.*` method-table fallback. `purpose` = bare
+     * category noun (`shopping`, `trading`); `action` = dotted verb
+     * (`shopping.search`, `trading.execute`). Authoritative over agent-supplied
+     * headers — the dashboard is merchant policy, the way MCP toolGates are.
+     */
+    purpose?: string;
+    action?: string;
 }
 /**
  * Express middleware options.
@@ -500,6 +516,15 @@ interface ExpressMiddlewareOptions extends GatewayConfig {
     extractCredentials?: (req: unknown) => AgentCredentials;
     /** Function to extract purpose from request */
     extractPurpose?: (req: unknown) => string | undefined;
+    /**
+     * Function to extract the PDLSS action from a request — symmetric with
+     * `extractPurpose` (Bug 14, §4.6: the action axis previously had NO
+     * override and hardwired the HTTP verb). When configured it masks the
+     * `X-Astra-Action` header step; returning undefined falls through to the
+     * pinned method→action table (GET→data.read, POST/PUT/PATCH→data.write,
+     * DELETE→data.delete). Dashboard route mapping still outranks it.
+     */
+    extractAction?: (req: unknown) => string | undefined;
     /** Skip verification for certain paths */
     skipPaths?: string[];
     /** Custom response for denied requests */

package/dist/{types-CgDCUfo8.d.mts → types-CyFwZ_Yu.d.mts}

@@ -1,4 +1,4 @@
-import { A as AccessLevel, c as CounterpartyType, T as TokenGuidance } from './types-B3USs-Kx.mjs';
+import { A as AccessLevel, c as CounterpartyType, T as TokenGuidance } from './types-Cuh7ELfr.mjs';
 
 /**
  * AstraSync Gateway - Types for gateway modes, local evaluation, and adapter interface.

package/dist/{types-R5N4ET6x.d.ts → types-WIRp_BP_.d.ts}

@@ -1,4 +1,4 @@
-import { A as AccessLevel, c as CounterpartyType, T as TokenGuidance } from './types-B3USs-Kx.js';
+import { A as AccessLevel, c as CounterpartyType, T as TokenGuidance } from './types-Cuh7ELfr.js';
 
 /**
  * AstraSync Gateway - Types for gateway modes, local evaluation, and adapter interface.

package/dist/ui/index.d.mts

@@ -1,4 +1,4 @@
-import { C as CommerceShieldProps, i as VerificationResult, a as AgentCredentials, e as GuidanceInfo, h as TrustLevel } from '../types-B3USs-Kx.mjs';
+import { C as CommerceShieldProps, i as VerificationResult, a as AgentCredentials, e as GuidanceInfo, h as TrustLevel } from '../types-Cuh7ELfr.mjs';
 
 /**
  * AstraSync Commerce Shield Component

package/dist/ui/index.d.ts

@@ -1,4 +1,4 @@
-import { C as CommerceShieldProps, i as VerificationResult, a as AgentCredentials, e as GuidanceInfo, h as TrustLevel } from '../types-B3USs-Kx.js';
+import { C as CommerceShieldProps, i as VerificationResult, a as AgentCredentials, e as GuidanceInfo, h as TrustLevel } from '../types-Cuh7ELfr.js';
 
 /**
  * AstraSync Commerce Shield Component

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@astrasyncai/verification-gateway",
-  "version": "2.5.1",
+  "version": "3.1.0",
   "description": "AstraSync KYA Platform SDK — counterparty verification gateway (verify incoming requests) + agent registration (register AI agents with the KYA backend).",
   "main": "./dist/index.js",
   "module": "./dist/index.mjs",