@aitne/daemon 0.1.8 → 0.1.9

package/dist/services/browser-history/automation/lite-final-confirm-tokens.d.ts

@@ -0,0 +1,100 @@
+/**
+ * Lite-final-confirm tokens — pure helpers for the browser-task
+ * single-use, 5-minute-TTL DM confirmation flow.
+ *
+ * BROWSER_TASK_REDESIGN_PLAN.md §5 ("Final-confirm tokens are NOT B-4
+ * purchase tokens") / §14.11 / §13 testing table.
+ *
+ * The shape and lifecycle mirror `purchase-tokens.ts` deliberately —
+ * both surfaces emit `!~xxxxxxxx` strings on the same primary channels,
+ * and the messaging adapter's `jti`-prefix dispatcher (§14.11 Q#6) fans
+ * a single inbound to whichever handler holds the matching token. The
+ * structural separation lives at:
+ *
+ *  - DB table (`browser_task_final_confirm_tokens` vs.
+ *    `browser_automation_purchase_tokens`)
+ *  - Handler (`final-confirm-handler.ts` vs. `purchase-handler.ts`)
+ *  - DM template (a future "Aitne confirmation required" marker, kept
+ *    distinct from B-4's "Aitne purchase confirmation" so the outbound
+ *    guard's marker set in `purchase-tokens.ts` does not overlap)
+ *
+ * Pure — no FS, no DB, no clock. Lives in the 100%-coverage gate. The
+ * shape constants (`B4_TOKEN_*`) come from `managed-chromium/types.ts`
+ * — those are not B-4-specific despite the historical naming, they are
+ * the shared `!~xxxxxxxx` envelope every Aitne single-use DM token
+ * uses.
+ */
+/** Mint the random 8-char base32 tail of a fresh lite-final-confirm
+ *  token. Same construction as `purchase-tokens.mintPurchaseTokenTail`
+ *  — uniform distribution via `& 0x1f` masking (256 ÷ 32 = 8 exactly,
+ *  no rejection sampling needed). Pure (CSPRNG via node:crypto). */
+export declare function mintLiteFinalConfirmTokenTail(): string;
+/** Compose `!~xxxxxxxx` from a freshly minted tail. */
+export declare function formatLiteFinalConfirmToken(tail: string): string;
+/** Mint a fresh canonical token (prefix included). */
+export declare function mintLiteFinalConfirmToken(): string;
+/** Compute the expiry timestamp for a freshly-minted token given
+ *  `nowMs`. */
+export declare function computeLiteFinalConfirmExpiry(nowMs: number): number;
+/** Pattern-match a body against the canonical token regex. Same shape
+ *  as `purchase-tokens.parsePurchaseToken`. The messaging adapter's
+ *  inbound classifier calls BOTH parsers and routes by jti prefix
+ *  when both produce a match (the regex is identical so a match on
+ *  one implies a match on the other; the dispatcher then queries each
+ *  store and routes to whichever returns a row). */
+export declare function parseLiteFinalConfirmToken(body: string): string | null;
+/** Pure SHA-256 hex of the inbound message body, for the audit-trail
+ *  hash that joins replies to tokens without persisting the raw
+ *  string. Same shape as B-4 `hashReplyBody`. */
+export declare function hashReplyBody(body: string): string;
+/** Constant-time string equality for the consume-time CAS. */
+export declare function liteFinalConfirmTokenEquals(a: string, b: string): boolean;
+/** Redact a token for log / DM surfaces — never log the raw form. */
+export declare function redactToken(token: string): string;
+/** Persisted view used by the classifier — the subset of the DB row
+ *  the pure decision tree reads. Decoupled from the full DB-row shape
+ *  so a future column add does not require classifier changes. */
+export interface LiteFinalConfirmTokenRowView {
+    jti: string;
+    token: string | null;
+    taskId: string;
+    status: "pending" | "confirmed" | "cancelled" | "expired";
+    issuedAt: number;
+    expiresAt: number;
+    consumedAt: number | null;
+    cancelledAt: number | null;
+    deliveredChannels: readonly string[];
+}
+/** Decision tree for an inbound `!~xxxxxxxx`-shaped reply. Same shape
+ *  as `classifyPurchaseReply`. Pure — the caller (store + handler) is
+ *  responsible for the atomic CAS that flips the row to `consumed`. */
+export type LiteFinalConfirmReplyDecision = {
+    kind: "shape_invalid";
+} | {
+    kind: "no_match";
+} | {
+    kind: "already_consumed";
+    row: LiteFinalConfirmTokenRowView;
+} | {
+    kind: "already_cancelled";
+    row: LiteFinalConfirmTokenRowView;
+} | {
+    kind: "expired";
+    row: LiteFinalConfirmTokenRowView;
+} | {
+    kind: "wrong_channel";
+    row: LiteFinalConfirmTokenRowView;
+} | {
+    kind: "consume";
+    row: LiteFinalConfirmTokenRowView;
+};
+export declare function classifyLiteFinalConfirmReply(input: {
+    body: string;
+    channelRef: string;
+    row: LiteFinalConfirmTokenRowView | null;
+    nowMs: number;
+}): LiteFinalConfirmReplyDecision;
+/** Predicate for the supervisor's orphan sweep — given a row's
+ *  status/expiry/consume/cancel timestamps and the current wall clock,
+ *  is the row a candidate for `expired` transition? */
+export declare function isLiteFinalConfirmExpired(row: Pick<LiteFinalConfirmTokenRowView, "status" | "expiresAt" | "consumedAt" | "cancelledAt">, nowMs: number): boolean;

package/dist/services/browser-history/automation/lite-final-confirm-tokens.js

@@ -0,0 +1,126 @@
+/**
+ * Lite-final-confirm tokens — pure helpers for the browser-task
+ * single-use, 5-minute-TTL DM confirmation flow.
+ *
+ * BROWSER_TASK_REDESIGN_PLAN.md §5 ("Final-confirm tokens are NOT B-4
+ * purchase tokens") / §14.11 / §13 testing table.
+ *
+ * The shape and lifecycle mirror `purchase-tokens.ts` deliberately —
+ * both surfaces emit `!~xxxxxxxx` strings on the same primary channels,
+ * and the messaging adapter's `jti`-prefix dispatcher (§14.11 Q#6) fans
+ * a single inbound to whichever handler holds the matching token. The
+ * structural separation lives at:
+ *
+ *  - DB table (`browser_task_final_confirm_tokens` vs.
+ *    `browser_automation_purchase_tokens`)
+ *  - Handler (`final-confirm-handler.ts` vs. `purchase-handler.ts`)
+ *  - DM template (a future "Aitne confirmation required" marker, kept
+ *    distinct from B-4's "Aitne purchase confirmation" so the outbound
+ *    guard's marker set in `purchase-tokens.ts` does not overlap)
+ *
+ * Pure — no FS, no DB, no clock. Lives in the 100%-coverage gate. The
+ * shape constants (`B4_TOKEN_*`) come from `managed-chromium/types.ts`
+ * — those are not B-4-specific despite the historical naming, they are
+ * the shared `!~xxxxxxxx` envelope every Aitne single-use DM token
+ * uses.
+ */
+import { createHash, randomBytes, timingSafeEqual } from "node:crypto";
+import { B4_TOKEN_BASE32_ALPHABET, B4_TOKEN_PREFIX, B4_TOKEN_REGEX, B4_TOKEN_TAIL_LENGTH, B4_TOKEN_TTL_MS, } from "../managed-chromium/types.js";
+/** Mint the random 8-char base32 tail of a fresh lite-final-confirm
+ *  token. Same construction as `purchase-tokens.mintPurchaseTokenTail`
+ *  — uniform distribution via `& 0x1f` masking (256 ÷ 32 = 8 exactly,
+ *  no rejection sampling needed). Pure (CSPRNG via node:crypto). */
+export function mintLiteFinalConfirmTokenTail() {
+    const bytes = randomBytes(B4_TOKEN_TAIL_LENGTH);
+    let out = "";
+    for (let i = 0; i < B4_TOKEN_TAIL_LENGTH; i++) {
+        out += B4_TOKEN_BASE32_ALPHABET[bytes[i] & 0x1f];
+    }
+    return out;
+}
+/** Compose `!~xxxxxxxx` from a freshly minted tail. */
+export function formatLiteFinalConfirmToken(tail) {
+    if (tail.length !== B4_TOKEN_TAIL_LENGTH) {
+        throw new Error(`formatLiteFinalConfirmToken: tail must be exactly ${B4_TOKEN_TAIL_LENGTH} chars`);
+    }
+    if (!/^[A-Z2-7]+$/.test(tail)) {
+        throw new Error("formatLiteFinalConfirmToken: tail must be base32 [A-Z2-7]");
+    }
+    return `${B4_TOKEN_PREFIX}${tail}`;
+}
+/** Mint a fresh canonical token (prefix included). */
+export function mintLiteFinalConfirmToken() {
+    return formatLiteFinalConfirmToken(mintLiteFinalConfirmTokenTail());
+}
+/** Compute the expiry timestamp for a freshly-minted token given
+ *  `nowMs`. */
+export function computeLiteFinalConfirmExpiry(nowMs) {
+    if (!Number.isFinite(nowMs) || nowMs < 0) {
+        throw new Error("computeLiteFinalConfirmExpiry: nowMs must be a non-negative finite number");
+    }
+    return nowMs + B4_TOKEN_TTL_MS;
+}
+/** Pattern-match a body against the canonical token regex. Same shape
+ *  as `purchase-tokens.parsePurchaseToken`. The messaging adapter's
+ *  inbound classifier calls BOTH parsers and routes by jti prefix
+ *  when both produce a match (the regex is identical so a match on
+ *  one implies a match on the other; the dispatcher then queries each
+ *  store and routes to whichever returns a row). */
+export function parseLiteFinalConfirmToken(body) {
+    if (typeof body !== "string")
+        return null;
+    const trimmed = body.trim();
+    if (!B4_TOKEN_REGEX.test(trimmed))
+        return null;
+    return trimmed;
+}
+/** Pure SHA-256 hex of the inbound message body, for the audit-trail
+ *  hash that joins replies to tokens without persisting the raw
+ *  string. Same shape as B-4 `hashReplyBody`. */
+export function hashReplyBody(body) {
+    return createHash("sha256").update(body, "utf8").digest("hex");
+}
+/** Constant-time string equality for the consume-time CAS. */
+export function liteFinalConfirmTokenEquals(a, b) {
+    if (typeof a !== "string" || typeof b !== "string")
+        return false;
+    if (a.length !== b.length)
+        return false;
+    return timingSafeEqual(Buffer.from(a, "utf8"), Buffer.from(b, "utf8"));
+}
+/** Redact a token for log / DM surfaces — never log the raw form. */
+export function redactToken(token) {
+    if (typeof token !== "string" || token.length < 5)
+        return "<redacted>";
+    return `${token.slice(0, 2)}****${token.slice(-3)}`;
+}
+export function classifyLiteFinalConfirmReply(input) {
+    const parsed = parseLiteFinalConfirmToken(input.body);
+    if (parsed === null)
+        return { kind: "shape_invalid" };
+    if (!input.row)
+        return { kind: "no_match" };
+    if (input.row.consumedAt !== null) {
+        return { kind: "already_consumed", row: input.row };
+    }
+    if (input.row.cancelledAt !== null || input.row.status === "cancelled") {
+        return { kind: "already_cancelled", row: input.row };
+    }
+    if (input.row.status === "expired" || input.nowMs > input.row.expiresAt) {
+        return { kind: "expired", row: input.row };
+    }
+    if (!input.row.deliveredChannels.includes(input.channelRef)) {
+        return { kind: "wrong_channel", row: input.row };
+    }
+    return { kind: "consume", row: input.row };
+}
+/** Predicate for the supervisor's orphan sweep — given a row's
+ *  status/expiry/consume/cancel timestamps and the current wall clock,
+ *  is the row a candidate for `expired` transition? */
+export function isLiteFinalConfirmExpired(row, nowMs) {
+    if (row.status !== "pending")
+        return false;
+    if (row.consumedAt !== null || row.cancelledAt !== null)
+        return false;
+    return nowMs > row.expiresAt;
+}

package/dist/services/browser-history/automation/payment-path-blocker.d.ts

@@ -0,0 +1,62 @@
+/**
+ * Payment-path blocker — pure URL pattern guard for the workflow runner.
+ *
+ * MANAGED_CHROMIUM_IMPLEMENTATION_PLAN.md §10 / §13 step 46.
+ *
+ * Hard-blocks any workflow whose primary URL navigates to a payment
+ * surface: any path ending in /checkout, /payment, /place-order, /buy,
+ * or /place-bid. The check runs BEFORE the workflow's own
+ * `allowlistRegex` so a workflow that mistakenly includes a payment
+ * sub-tree in its allowlist still fails closed.
+ *
+ * Why structural: B-3 introduces user-approved write workflows operating
+ * against logged-in profiles. Payment surfaces are categorically
+ * different — they commit money and belong to B-4 (which gates with a
+ * DM-issued single-use token, screenshot-first consent, and per-site
+ * spend caps). A B-3 workflow holding a generic Approve token must not
+ * be able to navigate to a payment path: the user-facing approval
+ * dialog explicitly does not authorise that semantic class.
+ *
+ * The runner applies this guard to every non-purchase workflow (anon,
+ * auth, and any future variant). Only `variant === "purchase"`
+ * bypasses it — those workflows ship via B-4 with their own gate.
+ *
+ * Pure — no FS, no DB, no network. Lives in the 100%-coverage gate.
+ */
+/** Closed set of payment-path categories. The category is surfaced in
+ *  the audit row's `detail` so the dashboard can distinguish "this
+ *  workflow tried to reach checkout" from "this workflow tried to
+ *  reach a bid form" — useful when triaging an over-eager workflow
+ *  declaration without scanning the raw URL. */
+export type PaymentPathCategory = "checkout" | "payment" | "place-order" | "buy" | "place-bid";
+export interface PaymentPathBlockMatch {
+    category: PaymentPathCategory;
+    matchedPath: string;
+}
+/**
+ * Returns the matched category when the URL's pathname matches one of
+ * the payment-path patterns, or null when the URL is safe. Tolerant of
+ * malformed input — non-string / unparseable values return null and the
+ * upstream URL-validator catches them via the per-workflow input schema.
+ *
+ * The function only inspects the URL's `pathname` — query string,
+ * fragment, and hostname are not consulted. A workflow can hand the
+ * function a query that mentions "checkout" without triggering the
+ * block; this is intentional, since query-string filtering would over-
+ * match (legitimate URLs frequently carry `?ref=checkout` etc.).
+ */
+export declare function classifyPaymentPath(url: string): PaymentPathBlockMatch | null;
+/** Exposed for tests so the registry validator (registry.ts) can scan
+ *  every workflow's `allowlistRegex.source` for a payment pattern and
+ *  reject the declaration at module load. The validator iterates this
+ *  table — adding a new pattern automatically tightens the check. */
+export declare function listPaymentPathPatterns(): ReadonlyArray<{
+    category: PaymentPathCategory;
+    pattern: RegExp;
+}>;
+export declare const __testing: {
+    PAYMENT_PATH_PATTERNS: readonly {
+        category: PaymentPathCategory;
+        pattern: RegExp;
+    }[];
+};

package/dist/services/browser-history/automation/payment-path-blocker.js

@@ -0,0 +1,113 @@
+/**
+ * Payment-path blocker — pure URL pattern guard for the workflow runner.
+ *
+ * MANAGED_CHROMIUM_IMPLEMENTATION_PLAN.md §10 / §13 step 46.
+ *
+ * Hard-blocks any workflow whose primary URL navigates to a payment
+ * surface: any path ending in /checkout, /payment, /place-order, /buy,
+ * or /place-bid. The check runs BEFORE the workflow's own
+ * `allowlistRegex` so a workflow that mistakenly includes a payment
+ * sub-tree in its allowlist still fails closed.
+ *
+ * Why structural: B-3 introduces user-approved write workflows operating
+ * against logged-in profiles. Payment surfaces are categorically
+ * different — they commit money and belong to B-4 (which gates with a
+ * DM-issued single-use token, screenshot-first consent, and per-site
+ * spend caps). A B-3 workflow holding a generic Approve token must not
+ * be able to navigate to a payment path: the user-facing approval
+ * dialog explicitly does not authorise that semantic class.
+ *
+ * The runner applies this guard to every non-purchase workflow (anon,
+ * auth, and any future variant). Only `variant === "purchase"`
+ * bypasses it — those workflows ship via B-4 with their own gate.
+ *
+ * Pure — no FS, no DB, no network. Lives in the 100%-coverage gate.
+ */
+/**
+ * Anchored on a path-segment boundary so a benign URL like
+ * `/checkout-faq` or `/buying-guide` does NOT match. The trailing
+ * alternation `(?:\/|\?|#|$)` ensures the matched segment is the last
+ * segment, or that the URL continues with a separator (query, fragment,
+ * or end-of-string). Case-insensitive — site URLs sometimes vary case
+ * in the wild.
+ *
+ * `payments` (plural) is included alongside `payment` because real-
+ * world e-commerce uses both (Amazon: `/gp/buy/payselect/`, Shopify:
+ * `/payments/...`). The cost of a false positive (rejecting a
+ * legitimate non-commerce path that happens to contain `/payment/`) is
+ * a clear error the user can route around by re-scoping the workflow;
+ * the cost of a false negative (letting an agent navigate `/buy` under
+ * a B-3 token) is a financial commitment without B-4 protections. We
+ * favour false positives.
+ */
+const PAYMENT_PATH_PATTERNS = Object.freeze([
+    {
+        category: "checkout",
+        pattern: /\/checkout(?:\/|\?|#|$)/i,
+    },
+    {
+        category: "payment",
+        pattern: /\/payments?(?:\/|\?|#|$)/i,
+    },
+    {
+        category: "place-order",
+        // Both `place-order` (hyphenated) and `placeorder` (no separator)
+        // — Amazon historically used the latter in older URL schemes.
+        pattern: /\/place[-_]?order(?:\/|\?|#|$)/i,
+    },
+    {
+        category: "buy",
+        // `/gp/buy/` (Amazon) + plain `/buy` + `/buy-now`. The trailing
+        // `(?:-now)?` allows the "Buy Now" pattern many storefronts use as
+        // the express-checkout entry-point.
+        pattern: /\/(?:gp\/buy|buy(?:-now)?)(?:\/|\?|#|$)/i,
+    },
+    {
+        category: "place-bid",
+        // eBay / Yahoo Auctions surface. `/place-bid` and `/bid` are both
+        // bid-commitment surfaces under the same risk class.
+        pattern: /\/(?:place-bid|bid)(?:\/|\?|#|$)/i,
+    },
+]);
+/**
+ * Returns the matched category when the URL's pathname matches one of
+ * the payment-path patterns, or null when the URL is safe. Tolerant of
+ * malformed input — non-string / unparseable values return null and the
+ * upstream URL-validator catches them via the per-workflow input schema.
+ *
+ * The function only inspects the URL's `pathname` — query string,
+ * fragment, and hostname are not consulted. A workflow can hand the
+ * function a query that mentions "checkout" without triggering the
+ * block; this is intentional, since query-string filtering would over-
+ * match (legitimate URLs frequently carry `?ref=checkout` etc.).
+ */
+export function classifyPaymentPath(url) {
+    if (typeof url !== "string" || url.length === 0)
+        return null;
+    let parsed;
+    try {
+        parsed = new URL(url);
+    }
+    catch {
+        return null;
+    }
+    // The pathname is what the patterns key off — they each carry an
+    // anchored boundary that handles trailing / / ? / # / $.
+    const path = parsed.pathname;
+    for (const { category, pattern } of PAYMENT_PATH_PATTERNS) {
+        if (pattern.test(path)) {
+            return { category, matchedPath: path };
+        }
+    }
+    return null;
+}
+/** Exposed for tests so the registry validator (registry.ts) can scan
+ *  every workflow's `allowlistRegex.source` for a payment pattern and
+ *  reject the declaration at module load. The validator iterates this
+ *  table — adding a new pattern automatically tightens the check. */
+export function listPaymentPathPatterns() {
+    return PAYMENT_PATH_PATTERNS;
+}
+export const __testing = {
+    PAYMENT_PATH_PATTERNS,
+};