aimeat 2.7.0 → 3.0.0

package/dist/src/utils/inline-script-parse.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"inline-script-parse.js","sourceRoot":"","sources":["../../../src/utils/inline-script-parse.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA8BG;AACH,OAAO,KAAK,EAAE,MAAM,SAAS,CAAC;AAK9B;;;;GAIG;AACH,MAAM,CAAC,MAAM,SAAS,GAA6D;IACjF,EAAE,IAAI,EAAE,qBAAqB,EAAE,MAAM,EAAE,iBAAiB,EAAE,IAAI,EAAE,QAAQ,EAAE;IAC1E,EAAE,IAAI,EAAE,mBAAmB,EAAE,MAAM,EAAE,aAAa,EAAE,IAAI,EAAE,QAAQ,EAAE;IACpE,EAAE,IAAI,EAAE,0BAA0B,EAAE,MAAM,EAAE,mBAAmB,EAAE,IAAI,EAAE,QAAQ,EAAE;CAClF,CAAC;AAEF;;;;;GAKG;AACH,MAAM,UAAU,mBAAmB;IACjC,OAAO,OAAQ,EAAgD,CAAC,gBAAgB,KAAK,UAAU,CAAC;AAClG,CAAC;AAED;;;;;;;;GAQG;AACH,MAAM,UAAU,WAAW,CAAC,MAAc,EAAE,QAAgB,EAAE,OAAkB,QAAQ;IACtF,IAAI,IAAI,KAAK,QAAQ,EAAE,CAAC;QACtB,0FAA0F;QAC1F,wFAAwF;QACxF,MAAM,gBAAgB,GAAI,EAExB,CAAC,gBAAgB,CAAC;QACpB,IAAI,OAAO,gBAAgB,KAAK,UAAU,EAAE,CAAC;YAC3C,MAAM,IAAI,KAAK,CACb,8FAA8F;kBAC5F,6BAA6B,CAAC,CAAC;QACrC,CAAC;QACD,+FAA+F;QAC/F,IAAI,gBAAgB,CAAC,MAAM,EAAE,EAAE,UAAU,EAAE,QAAQ,EAAE,CAAC,CAAC;QACvD,OAAO;IACT,CAAC;IACD,8DAA8D;IAC9D,IAAI,EAAE,CAAC,MAAM,CAAC,MAAM,EAAE,EAAE,QAAQ,EAAE,CAAC,CAAC;AACtC,CAAC;AAED;;;;;;;;;GASG;AACH,MAAM,UAAU,oBAAoB,CAAC,IAAY;IAC/C,MAAM,GAAG,GAA8D,EAAE,CAAC;IAC1E,MAAM,EAAE,GAAG,4CAA4C,CAAC;IACxD,IAAI,CAAyB,CAAC;IAC9B,IAAI,CAAC,GAAG,CAAC,CAAC;IACV,OAAO,CAAC,CAAC,GAAG,EAAE,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC,KAAK,IAAI,EAAE,CAAC;QACpC,CAAC,IAAI,CAAC,CAAC;QACP,MAAM,KAAK,GAAG,CAAC,CAAC,CAAC,CAAC,IAAI,EAAE,CAAC;QACzB,IAAI,YAAY,CAAC,IAAI,CAAC,KAAK,CAAC;YAAE,SAAS;QACvC,MAAM,IAAI,GAAG,gCAAgC,CAAC,IAAI,CAAC,KAAK,CAAC,EAAE,CAAC,CAAC,CAAC,EAAE,WAAW,EAAE,CAAC;QAC9E,IAAI,IAAI,IAAI,CAAC,qDAAqD,CAAC,IAAI,CAAC,IAAI,CAAC;YAAE,SAAS;QACxF,2FAA2F;QAC3F,+FAA+F;QAC/F,uDAAuD;QACvD,GAAG,CAAC,IAAI,CAAC,EAAE,KAAK,EAAE,CAAC,EAAE,MAAM,EAAE,CAAC,CAAC,CAAC,CAAC,IAAI,EAAE,EAAE,IAAI,EAAE,IAAI,KAAK,QAAQ,CAAC,CAAC,CAAC,QAAQ,CAAC,CAAC,CAAC,QAAQ,EAAE,CAAC,CAAC;IAC5F,CAAC;IACD,OAAO,GAAG,CAAC;AACb,CAAC;AAED,sGAAsG;AACtG,MAAM,UAAU,QAAQ;IACtB,KAAK,MAAM,CAAC,IAAI,SAAS,EAAE,CAAC;QAC1B,IAAI,KAAK,GAAG,KAAK,CAAC;QAClB,8FAA8F;QAC9F,6FAA6F;QAC7F,8FAA8F;QAC9F,IAAI,CAAC;YAAC,WAAW,CAAC,CAAC,CAAC,MAAM,EAAE,aAAa,CAAC,CAAC,IAAI,GAAG,EAAE,CAAC,CAAC,IAAI,CAAC,CAAC;QAAC,CAAC;QAAC,MAAM,CAAC;YAAC,KAAK,GAAG,IAAI,CAAC;QAAC,CAAC;QACtF,IAAI,CAAC,KAAK,EAAE,CAAC;YACX,MAAM,IAAI,KAAK,CACb,mDAAmD,CAAC,CAAC,IAAI,kCAAkC;kBACzF,0EAA0E,CAAC,CAAC;QAClF,CAAC;IACH,CAAC;AACH,CAAC"}

package/dist/src/utils/json-merge-patch.d.ts

@@ -0,0 +1,48 @@
+/**
+ * @file src/utils/json-merge-patch.ts
+ * @description JSON Merge Patch (RFC 7386) — the merge semantics behind PATCH /v1/memory/:key.
+ *
+ *   The reason this exists: a record written by several principals at once. Six Sanomat agents each
+ *   own one subtree of one edition; a marketplace app and its owner each own part of one listing.
+ *   Without a merge each writer has to own a whole key, which is how a pipeline ends up sharding into
+ *   one key per writer and burning the key budget (the memory-key-shape audit, 2026-08-09).
+ *
+ *   RFC 7386 is deliberately small, and the small parts are the load-bearing ones:
+ *     - an object in the patch merges KEY BY KEY into an object in the target, recursively;
+ *     - `null` in the patch DELETES that key from the target (this is why the format cannot express
+ *       "set this field to null" — a caller that needs a stored null must model it another way);
+ *     - anything else — a scalar, an array, or an object replacing a non-object — REPLACES wholesale.
+ *   Arrays are replaced, never merged element-wise. There is no index-level merge in the RFC and
+ *   inventing one would make two concurrent list appends silently reorder each other.
+ * @structure
+ *   - applyMergePatch(target, patch) -> the merged value (pure; never mutates either argument)
+ *   - mergePatchTouchesReservedRoot(patch, roots) -> the first reserved top-level key the patch
+ *     writes, or null. Lets a caller refuse a patch that reaches into a namespace it may not touch.
+ * @usage import { applyMergePatch } from '../utils/json-merge-patch.js';
+ *   const merged = applyMergePatch(existing?.value ?? {}, req.body.patch);
+ * @version-history
+ *   v1.0.0 — 2026-08-09 — Initial, with PATCH /v1/memory/:key.
+ */
+/** A JSON value, as it arrives from a request body. */
+export type Json = null | boolean | number | string | Json[] | {
+    [k: string]: Json;
+};
+/**
+ * Apply an RFC 7386 merge patch and return the result. Pure: neither argument is mutated, so a
+ * caller can compute the merged value, run it past the size and schema guards, and still have the
+ * original in hand to retry with when a concurrent writer wins the compare-and-swap.
+ *
+ * When `patch` is not an object the result IS the patch — that is the RFC's rule, and it means
+ * `PATCH` with a scalar body replaces the whole record. Callers that want to forbid that should
+ * reject a non-object patch before calling, which the route does.
+ */
+export declare function applyMergePatch(target: unknown, patch: unknown): Json;
+/**
+ * The first top-level key in `patch` that appears in `roots`, or null.
+ *
+ * A merge patch can reach anywhere in a record, so the reserved-key rules that guard a whole KEY
+ * (`appMayWriteKey`) need a companion for the fields INSIDE one. Without it, a principal allowed to
+ * patch a record could reach a subtree it would be refused as its own key.
+ */
+export declare function mergePatchTouchesReservedRoot(patch: unknown, roots: readonly string[]): string | null;
+//# sourceMappingURL=json-merge-patch.d.ts.map

package/dist/src/utils/json-merge-patch.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"json-merge-patch.d.ts","sourceRoot":"","sources":["../../../src/utils/json-merge-patch.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;GAwBG;AAEH,uDAAuD;AACvD,MAAM,MAAM,IAAI,GAAG,IAAI,GAAG,OAAO,GAAG,MAAM,GAAG,MAAM,GAAG,IAAI,EAAE,GAAG;IAAE,CAAC,CAAC,EAAE,MAAM,GAAG,IAAI,CAAA;CAAE,CAAC;AAOrF;;;;;;;;GAQG;AACH,wBAAgB,eAAe,CAAC,MAAM,EAAE,OAAO,EAAE,KAAK,EAAE,OAAO,GAAG,IAAI,CAiBrE;AAED;;;;;;GAMG;AACH,wBAAgB,6BAA6B,CAAC,KAAK,EAAE,OAAO,EAAE,KAAK,EAAE,SAAS,MAAM,EAAE,GAAG,MAAM,GAAG,IAAI,CAIrG"}

package/dist/src/utils/json-merge-patch.js

@@ -0,0 +1,73 @@
+/**
+ * @file src/utils/json-merge-patch.ts
+ * @description JSON Merge Patch (RFC 7386) — the merge semantics behind PATCH /v1/memory/:key.
+ *
+ *   The reason this exists: a record written by several principals at once. Six Sanomat agents each
+ *   own one subtree of one edition; a marketplace app and its owner each own part of one listing.
+ *   Without a merge each writer has to own a whole key, which is how a pipeline ends up sharding into
+ *   one key per writer and burning the key budget (the memory-key-shape audit, 2026-08-09).
+ *
+ *   RFC 7386 is deliberately small, and the small parts are the load-bearing ones:
+ *     - an object in the patch merges KEY BY KEY into an object in the target, recursively;
+ *     - `null` in the patch DELETES that key from the target (this is why the format cannot express
+ *       "set this field to null" — a caller that needs a stored null must model it another way);
+ *     - anything else — a scalar, an array, or an object replacing a non-object — REPLACES wholesale.
+ *   Arrays are replaced, never merged element-wise. There is no index-level merge in the RFC and
+ *   inventing one would make two concurrent list appends silently reorder each other.
+ * @structure
+ *   - applyMergePatch(target, patch) -> the merged value (pure; never mutates either argument)
+ *   - mergePatchTouchesReservedRoot(patch, roots) -> the first reserved top-level key the patch
+ *     writes, or null. Lets a caller refuse a patch that reaches into a namespace it may not touch.
+ * @usage import { applyMergePatch } from '../utils/json-merge-patch.js';
+ *   const merged = applyMergePatch(existing?.value ?? {}, req.body.patch);
+ * @version-history
+ *   v1.0.0 — 2026-08-09 — Initial, with PATCH /v1/memory/:key.
+ */
+/** True for a mergeable object: a plain object, not an array and not null. */
+function isMergeableObject(v) {
+    return typeof v === 'object' && v !== null && !Array.isArray(v);
+}
+/**
+ * Apply an RFC 7386 merge patch and return the result. Pure: neither argument is mutated, so a
+ * caller can compute the merged value, run it past the size and schema guards, and still have the
+ * original in hand to retry with when a concurrent writer wins the compare-and-swap.
+ *
+ * When `patch` is not an object the result IS the patch — that is the RFC's rule, and it means
+ * `PATCH` with a scalar body replaces the whole record. Callers that want to forbid that should
+ * reject a non-object patch before calling, which the route does.
+ */
+export function applyMergePatch(target, patch) {
+    if (!isMergeableObject(patch))
+        return patch;
+    // A non-object target is replaced by an empty object first: RFC 7386 says merging an object into
+    // a scalar discards the scalar. Copying rather than mutating keeps the function pure.
+    const out = isMergeableObject(target) ? { ...target } : {};
+    for (const [k, v] of Object.entries(patch)) {
+        if (v === null) {
+            delete out[k]; // null means REMOVE, not "store null"
+        }
+        else if (isMergeableObject(v)) {
+            out[k] = applyMergePatch(out[k], v); // recurse; a scalar under k is replaced
+        }
+        else {
+            out[k] = v; // scalar or array: wholesale replace
+        }
+    }
+    return out;
+}
+/**
+ * The first top-level key in `patch` that appears in `roots`, or null.
+ *
+ * A merge patch can reach anywhere in a record, so the reserved-key rules that guard a whole KEY
+ * (`appMayWriteKey`) need a companion for the fields INSIDE one. Without it, a principal allowed to
+ * patch a record could reach a subtree it would be refused as its own key.
+ */
+export function mergePatchTouchesReservedRoot(patch, roots) {
+    if (!isMergeableObject(patch))
+        return null;
+    for (const k of Object.keys(patch))
+        if (roots.includes(k))
+            return k;
+    return null;
+}
+//# sourceMappingURL=json-merge-patch.js.map

package/dist/src/utils/json-merge-patch.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"json-merge-patch.js","sourceRoot":"","sources":["../../../src/utils/json-merge-patch.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;GAwBG;AAKH,8EAA8E;AAC9E,SAAS,iBAAiB,CAAC,CAAU;IACjC,OAAO,OAAO,CAAC,KAAK,QAAQ,IAAI,CAAC,KAAK,IAAI,IAAI,CAAC,KAAK,CAAC,OAAO,CAAC,CAAC,CAAC,CAAC;AACpE,CAAC;AAED;;;;;;;;GAQG;AACH,MAAM,UAAU,eAAe,CAAC,MAAe,EAAE,KAAc;IAC3D,IAAI,CAAC,iBAAiB,CAAC,KAAK,CAAC;QAAE,OAAO,KAAa,CAAC;IAEpD,iGAAiG;IACjG,sFAAsF;IACtF,MAAM,GAAG,GAAyB,iBAAiB,CAAC,MAAM,CAAC,CAAC,CAAC,CAAC,EAAE,GAAG,MAAM,EAAE,CAAC,CAAC,CAAC,EAAE,CAAC;IAEjF,KAAK,MAAM,CAAC,CAAC,EAAE,CAAC,CAAC,IAAI,MAAM,CAAC,OAAO,CAAC,KAAK,CAAC,EAAE,CAAC;QACzC,IAAI,CAAC,KAAK,IAAI,EAAE,CAAC;YACb,OAAO,GAAG,CAAC,CAAC,CAAC,CAAC,CAA8B,sCAAsC;QACtF,CAAC;aAAM,IAAI,iBAAiB,CAAC,CAAC,CAAC,EAAE,CAAC;YAC9B,GAAG,CAAC,CAAC,CAAC,GAAG,eAAe,CAAC,GAAG,CAAC,CAAC,CAAC,EAAE,CAAC,CAAC,CAAC,CAAQ,wCAAwC;QACxF,CAAC;aAAM,CAAC;YACJ,GAAG,CAAC,CAAC,CAAC,GAAG,CAAC,CAAC,CAAiC,qCAAqC;QACrF,CAAC;IACL,CAAC;IACD,OAAO,GAAG,CAAC;AACf,CAAC;AAED;;;;;;GAMG;AACH,MAAM,UAAU,6BAA6B,CAAC,KAAc,EAAE,KAAwB;IAClF,IAAI,CAAC,iBAAiB,CAAC,KAAK,CAAC;QAAE,OAAO,IAAI,CAAC;IAC3C,KAAK,MAAM,CAAC,IAAI,MAAM,CAAC,IAAI,CAAC,KAAK,CAAC;QAAE,IAAI,KAAK,CAAC,QAAQ,CAAC,CAAC,CAAC;YAAE,OAAO,CAAC,CAAC;IACpE,OAAO,IAAI,CAAC;AAChB,CAAC"}

package/dist/src/utils/login-identifier.d.ts

@@ -0,0 +1,34 @@
+/**
+ * @file src/utils/login-identifier.ts
+ * @description Reads what a person typed into a sign-in field. Three shapes arrive there and they
+ *   must not be confused: an email address, a full GHII (`alice@node-id`, local or federated), and a
+ *   plain owner handle. The `@` alone cannot tell them apart, which is why this is one function
+ *   rather than an inline test at each call site: an email routed as a GHII becomes a federated
+ *   login to a node named "gmail.com".
+ * @structure parseLoginIdentifier(raw, nodeId) → { kind, localName, federatedNodeId }.
+ * @usage const id = parseLoginIdentifier(req.body.username, config.nodeId);
+ * @version-history
+ *   v1.0.0 — 2026-08-07 — Extracted when POST /v1/ghii/login learned to accept a verified email.
+ */
+export type LoginIdentifier = 
+/** An email address — it SELECTS an account by its verified address; resolve it before lookup. */
+{
+    kind: 'email';
+    localName: string;
+    federatedNodeId?: undefined;
+}
+/** A GHII whose node part is another node — authentication belongs to that node. */
+ | {
+    kind: 'federated';
+    localName: string;
+    federatedNodeId: string;
+}
+/** A local handle, whether typed bare or as `alice@this-node-id`. */
+ | {
+    kind: 'local';
+    localName: string;
+    federatedNodeId?: undefined;
+};
+/** Classify a typed sign-in identifier. Trims and lowercases; never touches storage. */
+export declare function parseLoginIdentifier(raw: string, nodeId: string): LoginIdentifier;
+//# sourceMappingURL=login-identifier.d.ts.map

package/dist/src/utils/login-identifier.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"login-identifier.d.ts","sourceRoot":"","sources":["../../../src/utils/login-identifier.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;GAWG;AAKH,MAAM,MAAM,eAAe;AACvB,kGAAkG;AAChG;IAAE,IAAI,EAAE,OAAO,CAAC;IAAC,SAAS,EAAE,MAAM,CAAC;IAAC,eAAe,CAAC,EAAE,SAAS,CAAA;CAAE;AACnE,oFAAoF;GAClF;IAAE,IAAI,EAAE,WAAW,CAAC;IAAC,SAAS,EAAE,MAAM,CAAC;IAAC,eAAe,EAAE,MAAM,CAAA;CAAE;AACnE,qEAAqE;GACnE;IAAE,IAAI,EAAE,OAAO,CAAC;IAAC,SAAS,EAAE,MAAM,CAAC;IAAC,eAAe,CAAC,EAAE,SAAS,CAAA;CAAE,CAAC;AAExE,wFAAwF;AACxF,wBAAgB,oBAAoB,CAAC,GAAG,EAAE,MAAM,EAAE,MAAM,EAAE,MAAM,GAAG,eAAe,CASjF"}

package/dist/src/utils/login-identifier.js

@@ -0,0 +1,29 @@
+/**
+ * @file src/utils/login-identifier.ts
+ * @description Reads what a person typed into a sign-in field. Three shapes arrive there and they
+ *   must not be confused: an email address, a full GHII (`alice@node-id`, local or federated), and a
+ *   plain owner handle. The `@` alone cannot tell them apart, which is why this is one function
+ *   rather than an inline test at each call site: an email routed as a GHII becomes a federated
+ *   login to a node named "gmail.com".
+ * @structure parseLoginIdentifier(raw, nodeId) → { kind, localName, federatedNodeId }.
+ * @usage const id = parseLoginIdentifier(req.body.username, config.nodeId);
+ * @version-history
+ *   v1.0.0 — 2026-08-07 — Extracted when POST /v1/ghii/login learned to accept a verified email.
+ */
+/** A dot-bearing domain marks an email. GHII node ids (`aimeat-fi-001-genesis`) never carry one. */
+const EMAIL_RE = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
+/** Classify a typed sign-in identifier. Trims and lowercases; never touches storage. */
+export function parseLoginIdentifier(raw, nodeId) {
+    const value = (raw || '').trim().toLowerCase();
+    if (EMAIL_RE.test(value))
+        return { kind: 'email', localName: value };
+    const at = value.indexOf('@');
+    if (at === -1)
+        return { kind: 'local', localName: value };
+    const nodePart = value.substring(at + 1);
+    const name = value.substring(0, at);
+    if (nodePart && nodePart !== nodeId)
+        return { kind: 'federated', localName: name, federatedNodeId: nodePart };
+    return { kind: 'local', localName: name };
+}
+//# sourceMappingURL=login-identifier.js.map

package/dist/src/utils/login-identifier.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"login-identifier.js","sourceRoot":"","sources":["../../../src/utils/login-identifier.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;GAWG;AAEH,oGAAoG;AACpG,MAAM,QAAQ,GAAG,4BAA4B,CAAC;AAU9C,wFAAwF;AACxF,MAAM,UAAU,oBAAoB,CAAC,GAAW,EAAE,MAAc;IAC5D,MAAM,KAAK,GAAG,CAAC,GAAG,IAAI,EAAE,CAAC,CAAC,IAAI,EAAE,CAAC,WAAW,EAAE,CAAC;IAC/C,IAAI,QAAQ,CAAC,IAAI,CAAC,KAAK,CAAC;QAAE,OAAO,EAAE,IAAI,EAAE,OAAO,EAAE,SAAS,EAAE,KAAK,EAAE,CAAC;IACrE,MAAM,EAAE,GAAG,KAAK,CAAC,OAAO,CAAC,GAAG,CAAC,CAAC;IAC9B,IAAI,EAAE,KAAK,CAAC,CAAC;QAAE,OAAO,EAAE,IAAI,EAAE,OAAO,EAAE,SAAS,EAAE,KAAK,EAAE,CAAC;IAC1D,MAAM,QAAQ,GAAG,KAAK,CAAC,SAAS,CAAC,EAAE,GAAG,CAAC,CAAC,CAAC;IACzC,MAAM,IAAI,GAAG,KAAK,CAAC,SAAS,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC;IACpC,IAAI,QAAQ,IAAI,QAAQ,KAAK,MAAM;QAAE,OAAO,EAAE,IAAI,EAAE,WAAW,EAAE,SAAS,EAAE,IAAI,EAAE,eAAe,EAAE,QAAQ,EAAE,CAAC;IAC9G,OAAO,EAAE,IAAI,EAAE,OAAO,EAAE,SAAS,EAAE,IAAI,EAAE,CAAC;AAC9C,CAAC"}

package/dist/src/utils/reserved-keys.d.ts

@@ -4,27 +4,81 @@
  *   behavior, plus the write gate that stops a scoped H-2 app-grant principal (role 'app') from
  *   poisoning them. An app-grant token's `sub` is the OWNER's GHII, so its `memory:write` lands in the
  *   owner's own namespace — the same namespace the server reads for: the AI-provider URL a decrypted
- *   key is sent to (`openrouter.*`), the daily AI-spend cap (`ai-usage.*`), and the public directory /
- *   matchmaking inputs (`profile.*`). A granted app must never write these; the owner manages them via
- *   the dedicated owner-only routes (`/v1/openrouter/settings`, `/v1/ghii`). Mirrors the ecosystem
- *   path's `ecoMayWriteKey` (services/ecosystem-access.ts). See
+ *   key is sent to (`openrouter.*`), the daily AI-spend cap (`ai-usage.*`), the public directory /
+ *   matchmaking inputs (`profile.*`), who may read another owner's whole finance area
+ *   (`finance.*`), and the seller's payout address and PSP secret (`commerce.*`). A granted app must
+ *   never write these; the owner manages them via the dedicated owner-only routes
+ *   (`/v1/openrouter/settings`, `/v1/ghii`, `/v1/finance/accountants`, `/v1/commerce/payout/*`), and
+ *   an agent through the named commerce tools. Mirrors the ecosystem path's `ecoMayWriteKey`
+ *   (services/ecosystem-access.ts). See
  *   docs/coding-guidelines/security-development-dna.md invariant #2.
- * @structure RESERVED_OWNER_KEY_PREFIXES · isReservedServerKey(key) · appMayWriteKey(roles, key)
+ * @structure RESERVED_OWNER_KEY_PREFIXES · isReservedServerKey(key) ·
+ *   appMayWriteKey(roles, key, delegatedOwnerWrite?, reservedAllowed?)
  * @usage import { appMayWriteKey } from '../utils/reserved-keys.js';
  * @version-history
+ *   v1.3.0 — 2026-08-11 — `finance.` and `commerce.` join the list (August 2026 audit H-6, H-23).
+ *     Both became server-trusted after the list was written and neither was added.
+ *     `finance.accountants` is the CROSS-OWNER authorization list for the whole finance area:
+ *     services/finance/accountant-access.ts hands another owner the invoices, vouchers, VAT report,
+ *     P&L and the CSV / Finvoice exports on the strength of that record's contents alone, so an app
+ *     that appended itself read the books. `commerce.psp` holds the seller's payout address, Stripe
+ *     secret and webhook secret, read as fact by commerce/x402.ts and
+ *     commerce/sellable-resolvers.ts.
+ *     The prefixes are deliberately BROAD rather than the two exact keys: `commerce.order.*`,
+ *     `commerce.hold.*`, `commerce.payable.*` and `commerce.benefit.*` are the money ledger the
+ *     books read back as fact, and a forged entry there is the same class of lie as a forged payout
+ *     address. Nothing legitimate writes either prefix through the memory API — the owner routes
+ *     and the settlement code call storage directly, and the agent-facing door is the commerce MCP
+ *     tools, which go through services/memory-write.ts and are gated on `commerce:psp` /
+ *     `commerce:sell` instead.
+ *   v1.1.0 — 2026-08-08 — The gate keys off the TARGET namespace, not only the role: an agent with
+ *     `memory:write-as-owner` reaches the same keys an app grant does, and would otherwise have
+ *     bypassed a guard written for that exact attack.
+ *   v1.2.0 — 2026-08-08 — `reservedAllowed`: the owner may hand even the reserved keys to one named
+ *     agent (`memory:write-reserved`), for an agent that administers the account. Deliberately NOT
+ *     in the '*' bundle: '*' is one click in the UI and nobody picking it is deciding that an agent
+ *     may redirect a decrypted AI key.
  *   v1.0.0 — 2026-07-10 — Created to close the app-grant reserved-key write hole (the C-2 class:
  *     OpenRouter key exfiltration via openrouter.settings.baseUrl, ai-usage budget-cap reset, and
  *     profile/directory poisoning — all via a granted app's memory:write into the owner namespace).
  */
-/** Owner-namespace key prefixes the server reads and trusts for behavior — never app-writable. */
-export declare const RESERVED_OWNER_KEY_PREFIXES: readonly ["openrouter.", "ai-usage.", "profile."];
+/**
+ * Owner-namespace key prefixes the server reads and trusts for behavior — never app-writable.
+ *
+ * The test for membership is not "is this sensitive" but **"does the server change what it DOES
+ * because of what it finds here"**: the URL a decrypted AI key is posted to, the spend cap it
+ * checks before billing, the directory entry it publishes, the list it consults before showing one
+ * owner's books to another, the address it pays out to. User data the server only hands back
+ * belongs nowhere near this list, because every prefix here costs a granted app a capability.
+ *
+ * Adding one is a behaviour change for principals that already exist. Measure it first: a prefix
+ * refuses role 'app' and delegated owner writes on every memory door, so anything that legitimately
+ * writes it through the memory API stops. The safe shapes are an owner-only route or a server-side
+ * write that never passes through this gate, which is what the openrouter, finance and commerce
+ * keys all use.
+ */
+export declare const RESERVED_OWNER_KEY_PREFIXES: readonly ["openrouter.", "ai-usage.", "profile.", "finance.", "commerce."];
 /** True iff `key` falls under a reserved, server-trusted owner-namespace prefix. */
 export declare function isReservedServerKey(key: string): boolean;
 /**
- * May a principal with these `roles` write `key`? Denies ONLY a role-'app' (H-2 app grant) principal
- * writing a reserved server-trusted key — because an app grant resolves to the OWNER's GHII namespace,
- * unlike an agent/ecosystem principal which writes to its own GAII/`eco:` namespace. All non-'app'
- * principals (owner, agent, ecosystem) are unaffected.
+ * May a principal with these `roles` write `key`?
+ *
+ * The real question is NOT "which role is this" but **"does this write land in the owner's GHII
+ * namespace"** — that is where the server reads the keys it trusts. Role 'app' always does, which is
+ * why the original gate could key off the role alone.
+ *
+ * `delegatedOwnerWrite` exists because role 'app' stopped being the only way in: an agent holding
+ * `memory:write-as-owner` and asking for it explicitly also writes there. Without this parameter that
+ * agent would walk straight through a gate built for exactly this attack — writing
+ * `openrouter.settings.baseUrl` to redirect a decrypted AI key, resetting `ai-usage.*` to clear the
+ * spend cap, poisoning `profile.*`, adding itself to `finance.accountants` to read another owner's
+ * books, or pointing `commerce.psp` at its own payout address. Same namespace, same danger, so the
+ * same refusal.
+ *
+ * **It means DELEGATED, not "the namespace happens to be the owner's".** The account holder writing
+ * their own keys is the whole point of those keys; passing `true` for an owner session locks the
+ * owner out of their own record, which is what happened the first time this parameter was added and
+ * what test/e2e-app-grants.ts ("guard is app-scoped") exists to catch.
  */
-export declare function appMayWriteKey(roles: string[], key: string): boolean;
+export declare function appMayWriteKey(roles: string[], key: string, delegatedOwnerWrite?: boolean, reservedAllowed?: boolean): boolean;
 //# sourceMappingURL=reserved-keys.d.ts.map

package/dist/src/utils/reserved-keys.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"reserved-keys.d.ts","sourceRoot":"","sources":["../../../src/utils/reserved-keys.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;GAiBG;AAEH,kGAAkG;AAClG,eAAO,MAAM,2BAA2B,mDAAoD,CAAC;AAE7F,oFAAoF;AACpF,wBAAgB,mBAAmB,CAAC,GAAG,EAAE,MAAM,GAAG,OAAO,CAExD;AAED;;;;;GAKG;AACH,wBAAgB,cAAc,CAAC,KAAK,EAAE,MAAM,EAAE,EAAE,GAAG,EAAE,MAAM,GAAG,OAAO,CAGpE"}
+{"version":3,"file":"reserved-keys.d.ts","sourceRoot":"","sources":["../../../src/utils/reserved-keys.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA2CG;AAEH;;;;;;;;;;;;;;GAcG;AACH,eAAO,MAAM,2BAA2B,4EAE9B,CAAC;AAEX,oFAAoF;AACpF,wBAAgB,mBAAmB,CAAC,GAAG,EAAE,MAAM,GAAG,OAAO,CAExD;AAED;;;;;;;;;;;;;;;;;;;GAmBG;AACH,wBAAgB,cAAc,CAC5B,KAAK,EAAE,MAAM,EAAE,EAAE,GAAG,EAAE,MAAM,EAAE,mBAAmB,UAAQ,EAAE,eAAe,UAAQ,GACjF,OAAO,CAQT"}

package/dist/src/utils/reserved-keys.js

@@ -4,32 +4,95 @@
  *   behavior, plus the write gate that stops a scoped H-2 app-grant principal (role 'app') from
  *   poisoning them. An app-grant token's `sub` is the OWNER's GHII, so its `memory:write` lands in the
  *   owner's own namespace — the same namespace the server reads for: the AI-provider URL a decrypted
- *   key is sent to (`openrouter.*`), the daily AI-spend cap (`ai-usage.*`), and the public directory /
- *   matchmaking inputs (`profile.*`). A granted app must never write these; the owner manages them via
- *   the dedicated owner-only routes (`/v1/openrouter/settings`, `/v1/ghii`). Mirrors the ecosystem
- *   path's `ecoMayWriteKey` (services/ecosystem-access.ts). See
+ *   key is sent to (`openrouter.*`), the daily AI-spend cap (`ai-usage.*`), the public directory /
+ *   matchmaking inputs (`profile.*`), who may read another owner's whole finance area
+ *   (`finance.*`), and the seller's payout address and PSP secret (`commerce.*`). A granted app must
+ *   never write these; the owner manages them via the dedicated owner-only routes
+ *   (`/v1/openrouter/settings`, `/v1/ghii`, `/v1/finance/accountants`, `/v1/commerce/payout/*`), and
+ *   an agent through the named commerce tools. Mirrors the ecosystem path's `ecoMayWriteKey`
+ *   (services/ecosystem-access.ts). See
  *   docs/coding-guidelines/security-development-dna.md invariant #2.
- * @structure RESERVED_OWNER_KEY_PREFIXES · isReservedServerKey(key) · appMayWriteKey(roles, key)
+ * @structure RESERVED_OWNER_KEY_PREFIXES · isReservedServerKey(key) ·
+ *   appMayWriteKey(roles, key, delegatedOwnerWrite?, reservedAllowed?)
  * @usage import { appMayWriteKey } from '../utils/reserved-keys.js';
  * @version-history
+ *   v1.3.0 — 2026-08-11 — `finance.` and `commerce.` join the list (August 2026 audit H-6, H-23).
+ *     Both became server-trusted after the list was written and neither was added.
+ *     `finance.accountants` is the CROSS-OWNER authorization list for the whole finance area:
+ *     services/finance/accountant-access.ts hands another owner the invoices, vouchers, VAT report,
+ *     P&L and the CSV / Finvoice exports on the strength of that record's contents alone, so an app
+ *     that appended itself read the books. `commerce.psp` holds the seller's payout address, Stripe
+ *     secret and webhook secret, read as fact by commerce/x402.ts and
+ *     commerce/sellable-resolvers.ts.
+ *     The prefixes are deliberately BROAD rather than the two exact keys: `commerce.order.*`,
+ *     `commerce.hold.*`, `commerce.payable.*` and `commerce.benefit.*` are the money ledger the
+ *     books read back as fact, and a forged entry there is the same class of lie as a forged payout
+ *     address. Nothing legitimate writes either prefix through the memory API — the owner routes
+ *     and the settlement code call storage directly, and the agent-facing door is the commerce MCP
+ *     tools, which go through services/memory-write.ts and are gated on `commerce:psp` /
+ *     `commerce:sell` instead.
+ *   v1.1.0 — 2026-08-08 — The gate keys off the TARGET namespace, not only the role: an agent with
+ *     `memory:write-as-owner` reaches the same keys an app grant does, and would otherwise have
+ *     bypassed a guard written for that exact attack.
+ *   v1.2.0 — 2026-08-08 — `reservedAllowed`: the owner may hand even the reserved keys to one named
+ *     agent (`memory:write-reserved`), for an agent that administers the account. Deliberately NOT
+ *     in the '*' bundle: '*' is one click in the UI and nobody picking it is deciding that an agent
+ *     may redirect a decrypted AI key.
  *   v1.0.0 — 2026-07-10 — Created to close the app-grant reserved-key write hole (the C-2 class:
  *     OpenRouter key exfiltration via openrouter.settings.baseUrl, ai-usage budget-cap reset, and
  *     profile/directory poisoning — all via a granted app's memory:write into the owner namespace).
  */
-/** Owner-namespace key prefixes the server reads and trusts for behavior — never app-writable. */
-export const RESERVED_OWNER_KEY_PREFIXES = ['openrouter.', 'ai-usage.', 'profile.'];
+/**
+ * Owner-namespace key prefixes the server reads and trusts for behavior — never app-writable.
+ *
+ * The test for membership is not "is this sensitive" but **"does the server change what it DOES
+ * because of what it finds here"**: the URL a decrypted AI key is posted to, the spend cap it
+ * checks before billing, the directory entry it publishes, the list it consults before showing one
+ * owner's books to another, the address it pays out to. User data the server only hands back
+ * belongs nowhere near this list, because every prefix here costs a granted app a capability.
+ *
+ * Adding one is a behaviour change for principals that already exist. Measure it first: a prefix
+ * refuses role 'app' and delegated owner writes on every memory door, so anything that legitimately
+ * writes it through the memory API stops. The safe shapes are an owner-only route or a server-side
+ * write that never passes through this gate, which is what the openrouter, finance and commerce
+ * keys all use.
+ */
+export const RESERVED_OWNER_KEY_PREFIXES = [
+    'openrouter.', 'ai-usage.', 'profile.', 'finance.', 'commerce.',
+];
 /** True iff `key` falls under a reserved, server-trusted owner-namespace prefix. */
 export function isReservedServerKey(key) {
     return RESERVED_OWNER_KEY_PREFIXES.some((prefix) => key.startsWith(prefix));
 }
 /**
- * May a principal with these `roles` write `key`? Denies ONLY a role-'app' (H-2 app grant) principal
- * writing a reserved server-trusted key — because an app grant resolves to the OWNER's GHII namespace,
- * unlike an agent/ecosystem principal which writes to its own GAII/`eco:` namespace. All non-'app'
- * principals (owner, agent, ecosystem) are unaffected.
+ * May a principal with these `roles` write `key`?
+ *
+ * The real question is NOT "which role is this" but **"does this write land in the owner's GHII
+ * namespace"** — that is where the server reads the keys it trusts. Role 'app' always does, which is
+ * why the original gate could key off the role alone.
+ *
+ * `delegatedOwnerWrite` exists because role 'app' stopped being the only way in: an agent holding
+ * `memory:write-as-owner` and asking for it explicitly also writes there. Without this parameter that
+ * agent would walk straight through a gate built for exactly this attack — writing
+ * `openrouter.settings.baseUrl` to redirect a decrypted AI key, resetting `ai-usage.*` to clear the
+ * spend cap, poisoning `profile.*`, adding itself to `finance.accountants` to read another owner's
+ * books, or pointing `commerce.psp` at its own payout address. Same namespace, same danger, so the
+ * same refusal.
+ *
+ * **It means DELEGATED, not "the namespace happens to be the owner's".** The account holder writing
+ * their own keys is the whole point of those keys; passing `true` for an owner session locks the
+ * owner out of their own record, which is what happened the first time this parameter was added and
+ * what test/e2e-app-grants.ts ("guard is app-scoped") exists to catch.
  */
-export function appMayWriteKey(roles, key) {
-    if (!roles.includes('app'))
+export function appMayWriteKey(roles, key, delegatedOwnerWrite = false, reservedAllowed = false) {
+    const isOwnerSession = roles.includes('owner') && !roles.includes('agent') && !roles.includes('ecosystem');
+    if (isOwnerSession)
+        return true;
+    if (!roles.includes('app') && !delegatedOwnerWrite)
+        return true;
+    // The owner can hand even these over, deliberately and per agent — see WRITE_RESERVED_SCOPE in
+    // routes/memory/owner-target.ts for why that grant is NOT part of the '*' bundle.
+    if (reservedAllowed)
         return true;
     return !isReservedServerKey(key);
 }

package/dist/src/utils/reserved-keys.js.map

@@ -1 +1 @@
-{"version":3,"file":"reserved-keys.js","sourceRoot":"","sources":["../../../src/utils/reserved-keys.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;GAiBG;AAEH,kGAAkG;AAClG,MAAM,CAAC,MAAM,2BAA2B,GAAG,CAAC,aAAa,EAAE,WAAW,EAAE,UAAU,CAAU,CAAC;AAE7F,oFAAoF;AACpF,MAAM,UAAU,mBAAmB,CAAC,GAAW;IAC7C,OAAO,2BAA2B,CAAC,IAAI,CAAC,CAAC,MAAM,EAAE,EAAE,CAAC,GAAG,CAAC,UAAU,CAAC,MAAM,CAAC,CAAC,CAAC;AAC9E,CAAC;AAED;;;;;GAKG;AACH,MAAM,UAAU,cAAc,CAAC,KAAe,EAAE,GAAW;IACzD,IAAI,CAAC,KAAK,CAAC,QAAQ,CAAC,KAAK,CAAC;QAAE,OAAO,IAAI,CAAC;IACxC,OAAO,CAAC,mBAAmB,CAAC,GAAG,CAAC,CAAC;AACnC,CAAC"}
+{"version":3,"file":"reserved-keys.js","sourceRoot":"","sources":["../../../src/utils/reserved-keys.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA2CG;AAEH;;;;;;;;;;;;;;GAcG;AACH,MAAM,CAAC,MAAM,2BAA2B,GAAG;IACzC,aAAa,EAAE,WAAW,EAAE,UAAU,EAAE,UAAU,EAAE,WAAW;CACvD,CAAC;AAEX,oFAAoF;AACpF,MAAM,UAAU,mBAAmB,CAAC,GAAW;IAC7C,OAAO,2BAA2B,CAAC,IAAI,CAAC,CAAC,MAAM,EAAE,EAAE,CAAC,GAAG,CAAC,UAAU,CAAC,MAAM,CAAC,CAAC,CAAC;AAC9E,CAAC;AAED;;;;;;;;;;;;;;;;;;;GAmBG;AACH,MAAM,UAAU,cAAc,CAC5B,KAAe,EAAE,GAAW,EAAE,mBAAmB,GAAG,KAAK,EAAE,eAAe,GAAG,KAAK;IAElF,MAAM,cAAc,GAAG,KAAK,CAAC,QAAQ,CAAC,OAAO,CAAC,IAAI,CAAC,KAAK,CAAC,QAAQ,CAAC,OAAO,CAAC,IAAI,CAAC,KAAK,CAAC,QAAQ,CAAC,WAAW,CAAC,CAAC;IAC3G,IAAI,cAAc;QAAE,OAAO,IAAI,CAAC;IAChC,IAAI,CAAC,KAAK,CAAC,QAAQ,CAAC,KAAK,CAAC,IAAI,CAAC,mBAAmB;QAAE,OAAO,IAAI,CAAC;IAChE,+FAA+F;IAC/F,kFAAkF;IAClF,IAAI,eAAe;QAAE,OAAO,IAAI,CAAC;IACjC,OAAO,CAAC,mBAAmB,CAAC,GAAG,CAAC,CAAC;AACnC,CAAC"}

package/dist/src/utils/scope-coverage.d.ts

@@ -0,0 +1,72 @@
+/**
+ * @file src/utils/scope-coverage.ts
+ * @description "Does this principal already hold that scope?" — the one place that answers it,
+ *   including the scopes a wildcard deliberately does NOT carry.
+ *
+ *   `requireScope` treats `*` and `{domain}:*` as covering everything beneath them, and for almost
+ *   every scope that is right. `memory:write-reserved` is the exception: it hands over the keys the
+ *   server itself trusts (the AI-provider URL a decrypted key is sent to, the spend cap, the public
+ *   profile), so `hasWriteReserved` tests the EXACT string — "Full access" is one click and nobody
+ *   clicking it is deciding that.
+ *
+ *   That exception only holds if every gate agrees about it. Two did not, and both were reachable
+ *   by an agent with no owner involved at all:
+ *
+ *   - `aimeat_operator_agent_configure` skipped its narrow-only check entirely when the TARGET held
+ *     `*` (`added.length > 0 && !granted.has('*')`), on the reasoning that a `*` agent cannot gain
+ *     anything. That reasoning was true until exactly one scope stopped being covered by `*`. An
+ *     agent proposed `['*','memory:write-reserved']` for itself, minted the confirm token and
+ *     consumed it in the next call — the token binds to the caller, so the "show this to the owner"
+ *     step is instruction text, not a gate.
+ *   - the device-auth same-owner auto-approve skipped its escalation filter for a `*` approver, and
+ *     its coverage test read `memory:*` as covering `memory:write-reserved`.
+ *
+ *   Neither was an escalation before this scope existed. Both were, the moment it did.
+ * @structure SCOPES_OUTSIDE_WILDCARD · scopeIsCovered(held, scope) · uncoveredScopes(held, wanted)
+ * @usage
+ *   import { uncoveredScopes } from '../utils/scope-coverage.js';
+ *   const added = uncoveredScopes(agent.defaultScopes ?? [], proposed.scopes);
+ *   if (added.length > 0) return err(`…${added.join(', ')}`);
+ * @version-history
+ *   v1.1.0 — 2026-08-11 — ACCOUNT_SECURITY_SCOPE. Out of the wildcard from the day it exists,
+ *     because the narrow-only check on the agent-configure surface asks THIS file whether a scope
+ *     is already covered: a '*' agent would have been told yes and could have written the word
+ *     onto itself, which is the exact path the two cases above describe.
+ *   v1.0.0 — 2026-08-08 — Initial, closing the two paths that let an agent grant itself
+ *     memory:write-reserved without the owner's tick.
+ */
+/** The scope an owner grants an agent to write into the owner's own namespace. */
+export declare const WRITE_AS_OWNER_SCOPE = "memory:write-as-owner";
+/**
+ * The stronger grant on top of it: also the RESERVED, server-trusted keys — `openrouter.*` (the URL
+ * a decrypted AI key is sent to), `ai-usage.*` (the spend cap) and `profile.*` (the public
+ * directory). For an agent that administers the account on the owner's behalf.
+ */
+export declare const WRITE_RESERVED_SCOPE = "memory:write-reserved";
+/**
+ * The doors that decide who can get back INTO the account: the password, the recovery address, the
+ * second factor, the identity proof, and deleting or exporting everything. Enforced by
+ * requireOwnerPrincipal() in auth/middleware.ts, which admits an owner principal outright and any
+ * other principal only on this exact word.
+ *
+ * It is out of every wildcard for the same reason the reserved-write scope is, only sharper: an
+ * agent that can set the password can become the person. Nobody was grandfathered onto it either
+ * (services/scope-vocabulary-migration.ts), so an agent holding it was ticked by hand.
+ */
+export declare const ACCOUNT_SECURITY_SCOPE = "account:security";
+export declare const SCOPES_OUTSIDE_WILDCARD: readonly string[];
+/** True when `scope` is one of the scopes only an exact grant can confer. */
+export declare function isOutsideWildcard(scope: string): boolean;
+/**
+ * Does a principal holding `held` already have `scope`?
+ *
+ * Same rules as requireScope — the global wildcard, the domain wildcard, or the exact string — with
+ * the one deliberate exception above, where only the exact string counts.
+ */
+export declare function scopeIsCovered(held: readonly string[], scope: string): boolean;
+/**
+ * Which of `wanted` this principal does NOT already hold. Empty means the request grants nothing
+ * new, which is what a narrow-only surface requires before it applies anything.
+ */
+export declare function uncoveredScopes(held: readonly string[], wanted: readonly string[]): string[];
+//# sourceMappingURL=scope-coverage.d.ts.map

package/dist/src/utils/scope-coverage.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"scope-coverage.d.ts","sourceRoot":"","sources":["../../../src/utils/scope-coverage.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAoCG;AAEH,kFAAkF;AAClF,eAAO,MAAM,oBAAoB,0BAA0B,CAAC;AAE5D;;;;GAIG;AACH,eAAO,MAAM,oBAAoB,0BAA0B,CAAC;AAE5D;;;;;;;;;GASG;AACH,eAAO,MAAM,sBAAsB,qBAAqB,CAAC;AAiCzD,eAAO,MAAM,uBAAuB,EAAE,SAAS,MAAM,EACiB,CAAC;AAEvE,6EAA6E;AAC7E,wBAAgB,iBAAiB,CAAC,KAAK,EAAE,MAAM,GAAG,OAAO,CAExD;AAED;;;;;GAKG;AACH,wBAAgB,cAAc,CAAC,IAAI,EAAE,SAAS,MAAM,EAAE,EAAE,KAAK,EAAE,MAAM,GAAG,OAAO,CAM9E;AAED;;;GAGG;AACH,wBAAgB,eAAe,CAAC,IAAI,EAAE,SAAS,MAAM,EAAE,EAAE,MAAM,EAAE,SAAS,MAAM,EAAE,GAAG,MAAM,EAAE,CAE5F"}

package/dist/src/utils/scope-coverage.js

@@ -0,0 +1,115 @@
+/**
+ * @file src/utils/scope-coverage.ts
+ * @description "Does this principal already hold that scope?" — the one place that answers it,
+ *   including the scopes a wildcard deliberately does NOT carry.
+ *
+ *   `requireScope` treats `*` and `{domain}:*` as covering everything beneath them, and for almost
+ *   every scope that is right. `memory:write-reserved` is the exception: it hands over the keys the
+ *   server itself trusts (the AI-provider URL a decrypted key is sent to, the spend cap, the public
+ *   profile), so `hasWriteReserved` tests the EXACT string — "Full access" is one click and nobody
+ *   clicking it is deciding that.
+ *
+ *   That exception only holds if every gate agrees about it. Two did not, and both were reachable
+ *   by an agent with no owner involved at all:
+ *
+ *   - `aimeat_operator_agent_configure` skipped its narrow-only check entirely when the TARGET held
+ *     `*` (`added.length > 0 && !granted.has('*')`), on the reasoning that a `*` agent cannot gain
+ *     anything. That reasoning was true until exactly one scope stopped being covered by `*`. An
+ *     agent proposed `['*','memory:write-reserved']` for itself, minted the confirm token and
+ *     consumed it in the next call — the token binds to the caller, so the "show this to the owner"
+ *     step is instruction text, not a gate.
+ *   - the device-auth same-owner auto-approve skipped its escalation filter for a `*` approver, and
+ *     its coverage test read `memory:*` as covering `memory:write-reserved`.
+ *
+ *   Neither was an escalation before this scope existed. Both were, the moment it did.
+ * @structure SCOPES_OUTSIDE_WILDCARD · scopeIsCovered(held, scope) · uncoveredScopes(held, wanted)
+ * @usage
+ *   import { uncoveredScopes } from '../utils/scope-coverage.js';
+ *   const added = uncoveredScopes(agent.defaultScopes ?? [], proposed.scopes);
+ *   if (added.length > 0) return err(`…${added.join(', ')}`);
+ * @version-history
+ *   v1.1.0 — 2026-08-11 — ACCOUNT_SECURITY_SCOPE. Out of the wildcard from the day it exists,
+ *     because the narrow-only check on the agent-configure surface asks THIS file whether a scope
+ *     is already covered: a '*' agent would have been told yes and could have written the word
+ *     onto itself, which is the exact path the two cases above describe.
+ *   v1.0.0 — 2026-08-08 — Initial, closing the two paths that let an agent grant itself
+ *     memory:write-reserved without the owner's tick.
+ */
+/** The scope an owner grants an agent to write into the owner's own namespace. */
+export const WRITE_AS_OWNER_SCOPE = 'memory:write-as-owner';
+/**
+ * The stronger grant on top of it: also the RESERVED, server-trusted keys — `openrouter.*` (the URL
+ * a decrypted AI key is sent to), `ai-usage.*` (the spend cap) and `profile.*` (the public
+ * directory). For an agent that administers the account on the owner's behalf.
+ */
+export const WRITE_RESERVED_SCOPE = 'memory:write-reserved';
+/**
+ * The doors that decide who can get back INTO the account: the password, the recovery address, the
+ * second factor, the identity proof, and deleting or exporting everything. Enforced by
+ * requireOwnerPrincipal() in auth/middleware.ts, which admits an owner principal outright and any
+ * other principal only on this exact word.
+ *
+ * It is out of every wildcard for the same reason the reserved-write scope is, only sharper: an
+ * agent that can set the password can become the person. Nobody was grandfathered onto it either
+ * (services/scope-vocabulary-migration.ts), so an agent holding it was ticked by hand.
+ */
+export const ACCOUNT_SECURITY_SCOPE = 'account:security';
+/**
+ * Scopes no wildcard carries — neither `*` nor `{domain}:*`. Only the exact string counts, anywhere
+ * a scope is checked, proposed, or approved.
+ *
+ * The frontend mirror is NOT_IN_WILDCARD in public/views/profile/agents/scope-model.js; the two are
+ * asserted to agree in test/unit/agent-scope-model.test.ts. Adding an entry here without adding it
+ * there produces a checkbox that lies about what it granted.
+ */
+/**
+ * Eight tool calls the HTTP door reserves to an owner session and the tool surface let an agent
+ * make on an ordinary permission. Each is either the owner's money or who else sees the owner's
+ * data: the seller's Stripe credentials, the AI budget and the models it routes to, rewriting an
+ * agent's own permissions, the sharing groups that decide who reads memory, the roster of a shared
+ * board, and recording a beneficiary as payable.
+ *
+ * The answer is not to shut the agent out — an agent should be able to do what a person can. It is
+ * that each of these costs its own tick, and no wildcard carries it. "Full access" is one click,
+ * and nobody clicking it is deciding that an agent may repoint their payouts.
+ *
+ * Every agent that could already reach one of these tools was handed the new word at boot, once, by
+ * services/scope-vocabulary-migration.ts, so nothing lost a capability it had.
+ */
+const OWN_TICK_SCOPES = [
+    'commerce:psp', // write or destroy the seller's payment credentials
+    'commerce:beneficiary-verify', // record a beneficiary as verified, i.e. as payable
+    'agent:permissions', // rewrite an agent's granted permissions
+    'consent:groups', // create a sharing group, add or remove who is in it
+    'share:manage', // hand another account a standing right to read part of the owner's memory
+    'social:members', // change who may read a shared board
+];
+export const SCOPES_OUTSIDE_WILDCARD = [WRITE_RESERVED_SCOPE, ACCOUNT_SECURITY_SCOPE, ...OWN_TICK_SCOPES];
+/** True when `scope` is one of the scopes only an exact grant can confer. */
+export function isOutsideWildcard(scope) {
+    return SCOPES_OUTSIDE_WILDCARD.includes(scope);
+}
+/**
+ * Does a principal holding `held` already have `scope`?
+ *
+ * Same rules as requireScope — the global wildcard, the domain wildcard, or the exact string — with
+ * the one deliberate exception above, where only the exact string counts.
+ */
+export function scopeIsCovered(held, scope) {
+    if (held.includes(scope))
+        return true;
+    if (isOutsideWildcard(scope))
+        return false;
+    if (held.includes('*'))
+        return true;
+    const domain = scope.split(':')[0];
+    return !!domain && held.includes(`${domain}:*`);
+}
+/**
+ * Which of `wanted` this principal does NOT already hold. Empty means the request grants nothing
+ * new, which is what a narrow-only surface requires before it applies anything.
+ */
+export function uncoveredScopes(held, wanted) {
+    return wanted.filter(s => !scopeIsCovered(held, s));
+}
+//# sourceMappingURL=scope-coverage.js.map