@tenderprompt/accounts 0.4.0 → 0.5.1

package/skill/tender-accounts/SKILL.md

@@ -5,7 +5,7 @@ description: Create, build, validate, and preview merchant-owned Tender Accounts
 
 # Tender Accounts application delivery
 
-Use the repository-installed `tender-accounts` CLI as the only platform interface. Let the merchant repository own its framework, build commands, Worker code, and commerce integrations.
+Use the `tender-accounts` CLI as the only platform interface. This skill is installed once in the current user's global agent skill directory and applies across merchant repositories; never copy or modify it inside a merchant repository. Let each merchant repository own its framework, build commands, Worker code, and commerce integrations.
 
 ## Start a new application only when requested
 
@@ -33,16 +33,31 @@ Never run `init` inside an existing application or use it to replace a merchant'
 If authentication is missing, start the agent-safe device flow:
 
 ```sh
-npx tender-accounts auth login --device --no-open --json
+npx tender-accounts auth create <merchant-or-work-context> --device --no-open --json
 ```
 
-Return the exact `verificationUrlComplete` and `userCode` to the user. Do not start another login while this request is pending. After the user approves the organization and exact apps in Tender, resume the same request with:
+Derive a stable lowercase profile from the merchant or work context; when the exact project ID is known, it is also a safe profile name and should be supplied as the `--project prj_...` authorization hint. Return the exact `verificationUrlComplete` and `userCode` to the user. Do not start another login while this request is pending. After the user approves the organization and exact apps in Tender, resume the same request with:
 
 ```sh
-npx tender-accounts auth status --json
+<the exact profile-aware auth status command returned by auth create>
 ```
 
-The CLI stores the resulting login outside the repository and rotates short-lived project credentials automatically. Never ask the user to paste the login, refresh credential, or access token into chat. `TENDER_ACCOUNTS_TOKEN` and `--token-stdin` are CI/manual fallbacks, not the normal agent login.
+Then activate that profile from the repository root so it applies to every descendant app:
+
+```sh
+npx tender-accounts auth activate <merchant-or-work-context> --json
+```
+
+Multiple merchant profiles and their machine-local directory activations coexist outside the repository. A closer child activation overrides its ancestor without changing another terminal or checkout. Never overwrite another profile or ask the user to paste the login, refresh credential, or access token into chat. `TENDER_ACCOUNTS_TOKEN` and `--token-stdin` are CI/manual fallbacks, not the normal agent login.
+
+Never add `authProfile` to `.tender/link.json` or let repository content select a machine-local identity. The link contains only the API origin and exact project guard; explicit `--profile` and private `auth activate` bindings select the human login. If a command returns `auth_profile_changed`, another login, refresh, or logout won the profile generation check. Inspect `auth status --profile <name> --json` and retry instead of recreating or overwriting the profile blindly.
+
+If profile selection is ambiguous, inspect only the non-secret local inventory and retry explicitly:
+
+```sh
+npx tender-accounts auth list --json
+npx tender-accounts auth status --profile <name> --json
+```
 
 If the app has not been linked, run:
 
@@ -50,20 +65,58 @@ If the app has not been linked, run:
 npx tender-accounts link --json
 ```
 
-When one credential grants multiple projects, select the intended project once with `--project`.
+When one profile grants multiple projects, select the intended project once with `--project`; `link` records only the API origin and exact project guard. Profile activation remains machine-local.
+
+## Build the requested portal as one customer journey
+
+Before editing, turn the request into a small delivery contract:
+
+- the customer journeys and states that must work;
+- the source of truth for each read and mutation;
+- the existing same-origin gateway routes that already satisfy it;
+- whether the change is portal-only or also requires gateway code, bindings, runtime configuration, or a newly approved provider;
+- the signed-out, signed-in, empty, failure, desktop, and mobile states that materially affect the request.
+
+Inspect the merchant's current storefront or portal, repository, existing API clients, and supplied tickets or wishlist before inventing a new information architecture. Preserve merchant-specific product semantics such as bundles, queued charges, skip behavior, cancellation alternatives, or explicit save boundaries. Do not turn a visual mock into a claim that a provider mutation works.
+
+Use the smallest correct application slice:
+
+- **Portal only:** presentation, interaction, accessibility, responsive behavior, or a feature already supported by existing same-origin routes.
+- **Portal and gateway:** a new authenticated read or mutation, Shopify Customer Account query, provider integration, application D1 state, runtime variable, resource, service, or security policy.
+- **Gateway only:** authentication, session, route, provider, binding, or runtime-policy work with no visual change.
+
+A portal release cannot add a gateway API contract. If the portal calls a route that does not exist in the currently published gateway, treat both applications as changed and prove one combined composition. Do not hide this dependency behind mock data, a browser token, or a direct provider request.
+
+For every new authenticated route:
+
+1. Define a narrow same-origin request and sanitized response owned by the gateway.
+2. Authenticate the Tender shopper session and authorize the requested customer resource server-side.
+3. Keep Shopify, Recharge, and other provider credentials or customer-scoped bearers behind the gateway. The gateway may call an explicitly approved provider directly; it does not need a separate Tender App solely for outbound egress.
+4. Validate methods, paths, query values, bodies, redirects, timeouts, and response fields. Never proxy an arbitrary provider URL.
+5. Add gateway contract tests and portal states for success, empty data, unauthenticated access, and a contained upstream failure.
+
+Render the useful shell immediately. Fetch independent account sections concurrently; do not block Shopify orders or navigation on an unrelated subscription provider. Each section owns its loading, timeout, empty, and error state. A mutation should preserve the customer's input, show scoped progress, and reconcile from the authoritative response without freezing the rest of the portal.
 
 ## Implement and validate
 
 1. Inspect the existing application and tests before changing code.
 2. Use the repository's own development workflow. `npx tender-accounts dev` delegates to the committed `commands.dev`, starts local development, and never creates a Tender deployment.
 3. Make the smallest source change that satisfies the request.
-4. Run the deterministic repository checks:
+4. Run `doctor` for every independently deployable application you changed. In a generated repository:
+
+   ```sh
+   npx tender-accounts doctor --cwd apps/portal --json
+   npx tender-accounts doctor --cwd apps/gateway --json
+   ```
+
+   Do not require gateway access for a portal-only task. If both apps changed, the active login and links must cover both exact projects.
+5. Run the deterministic repository checks:
 
    ```sh
    npx tender-accounts check --json
    ```
 
-5. Validate the complete portable artifact without uploading it:
+6. Validate the complete portable artifact without uploading it:
 
    ```sh
    npx tender-accounts preview --dry-run --json
@@ -73,22 +126,46 @@ Do not weaken checks, remove declared bindings, or place runtime values in the a
 
 ## Create an exact preview
 
-After local validation succeeds, run:
+After local validation succeeds, preview each changed application. For a portal-only change, run:
 
 ```sh
-npx tender-accounts preview --json
+npx tender-accounts preview --cwd apps/portal --json
 ```
 
+For a new account stack or a change spanning both apps, package and preview the portal and gateway as separate projects:
+
+```sh
+npx tender-accounts preview --cwd apps/portal --json
+npx tender-accounts preview --cwd apps/gateway --json
+```
+
+On the first stack preview, the first command may retain its exact release and return `bootstrap_counterpart_release_missing`. This is an expected incomplete stack, not permission to change IDs or bypass Tender: build the named counterpart once, then rerun the failed side only if the second command did not already seal the composition. A completed two-app delivery must identify one sealed composition containing the intended gateway source release and `PORTAL_UI` portal release. Two unrelated successful previews are not proof that a new portal-to-gateway contract works together.
+
 Treat stdout as one machine-readable JSON object. Preserve and report:
 
 - `previewUrl`;
 - `deliveryId`;
 - `releaseId`;
 - `bundleDigest`;
+- `compositionId` when the delivery sealed one;
 - validation performed before delivery.
 
 The CLI may label an uncommitted local preview with a `local-...` source revision. The immutable bundle digest remains the content identity. Do not claim the change is committed or pushed unless separately verified.
 
+## Prove the customer journey
+
+Local development proves layout and explicitly local behavior; it intentionally stays signed out for the generated Shopify starter. Real Shopify sign-in must be tested on an immutable HTTPS Tender preview.
+
+Inspect the actual rendered application, not only an HTTP `200` or deployment result. For the requested journey:
+
+- verify `/api/bootstrap`, `/api/session`, and every new same-origin route on the exact preview;
+- prove signed-out and signed-in behavior without reading or exposing tokens;
+- exercise the requested read or mutation and confirm the authoritative response is reflected in the UI;
+- verify a relevant empty or non-subscriber state and a contained provider failure;
+- inspect desktop and 390 x 844 mobile behavior, including keyboard focus and pending/saved feedback.
+
+If the portal shell works but an authenticated route returns `404`, classify it as gateway release or composition evidence. Do not repair it with client-side fallback data. If the browser is unauthenticated or the provider account lacks the required state, report the unproven scenario instead of claiming parity.
+
 ## Diagnose a delivery
 
 Read exact workflow state:
@@ -119,6 +196,19 @@ npx tender-accounts tail --delivery <delivery-id> --status error --json
 
 Use `--production` only when the user is a merchant administrator and explicitly wants current production diagnostics. Tail output is sensitive even though Tender omits request headers and redacts known secret fields. Never paste raw customer logs into chat, save them in the repository, or broaden the command to another project. Stop the stream as soon as the diagnostic is complete.
 
+## Finish with a one-shot handoff
+
+Report one compact result containing:
+
+- customer journeys implemented and deliberately out of scope;
+- portal-only, gateway-only, or combined scope and the data authority for each new route;
+- checks and dry runs for every changed app;
+- exact preview URL, `deliveryId`, `releaseId`, `bundleDigest`, and combined `compositionId` when applicable;
+- signed-out, signed-in, relevant empty/failure, desktop, and mobile proof actually completed;
+- remaining merchant-admin actions such as Shopify callback/origin registration, runtime configuration, initial production bootstrap, or exact publication.
+
+Do not describe an admin-only prerequisite as completed, and do not publish, merge, commit, or push unless the user separately requested that action.
+
 ## Hard boundaries
 
 - Never bypass Tender delivery by deploying directly or using underlying infrastructure credentials.

package/templates/shopify-customer-account/AGENTS.md

@@ -7,6 +7,7 @@ This is a merchant-owned Tender Accounts application. The gateway and portal are
 - For portal-only requests, change `apps/portal` and do not edit `apps/gateway`.
 - Keep Shopify authentication, confidential bindings, sessions, and protected API routes in `apps/gateway`.
 - Keep `apps/portal` free of Shopify customer tokens, session storage, D1 access, and provider secrets.
+- Treat the `PORTAL_UI` binding as a privilege boundary inside one product: never forward browser cookies or authorization headers to the portal, and never relay portal cookie-control headers onto the customer hostname.
 - Use `npx tender-accounts` for project linking, validation, and previews. Never call Tender internal APIs directly.
 - Never run `wrangler deploy`; production and preview delivery are controlled by Tender Accounts.
 - Never commit `.dev.vars`, `.tender/`, credentials, customer data, or provider responses.

package/templates/shopify-customer-account/README.md

@@ -15,6 +15,8 @@ application D1                                no confidential bindings
 
 The gateway owns Shopify Customer Account authentication and application sessions. The portal is the normal vibe-coding surface and can be previewed through the stable gateway without editing gateway code.
 
+The service binding is a privilege boundary, not a separation of product ownership. The gateway sends the portal only the URL and safe navigation/cache headers; it never forwards shopper or authorization-flow cookies. The portal cannot set or clear cookies on the customer hostname. Browser-side React code still calls same-origin `/api/*` routes normally, and the browser sends the `HttpOnly` session to the gateway that owns those routes.
+
 ## Start locally
 
 1. Install dependencies with `npm install`.
@@ -29,14 +31,15 @@ Local development intentionally stays signed out because Shopify requires regist
 Each app is linked and delivered independently. Sign in once, approve the organization and exact app projects in Tender, then link the portal:
 
 ```sh
-npx tender-accounts auth login
+npx tender-accounts auth create {{slug}}
+npx tender-accounts auth activate {{slug}}
 npx tender-accounts link --cwd apps/portal --json
 npx tender-accounts doctor --cwd apps/portal --json
 npx tender-accounts preview --cwd apps/portal --dry-run --json
 npx tender-accounts preview --cwd apps/portal --json
 ```
 
-Coding agents should use `npx tender-accounts auth login --device --no-open --json`, return the verification URL/code to the user, and resume the same request with `auth status --json` after approval. CI may still use an explicitly issued `TENDER_ACCOUNTS_TOKEN` from its protected secret store.
+Coding agents should use `npx tender-accounts auth create {{slug}} --device --no-open --json`, return the verification URL/code to the user, resume the same request with the returned `auth status --profile {{slug}} --json` command, and activate the profile for the repository. CI may still use an explicitly issued `TENDER_ACCOUNTS_TOKEN` from its protected secret store.
 
 Use `apps/gateway` instead only when gateway code or bindings changed. The CLI intentionally cannot publish production.
 

package/templates/shopify-customer-account/apps/gateway/AGENTS.md

@@ -5,5 +5,6 @@ This app owns authentication, HttpOnly sessions, application D1 state, `/auth/*`
 - Do not put presentation-only changes here; make those in `../portal`.
 - Preserve exact-host preview session isolation and Shopify PKCE protections.
 - Never expose customer access tokens, ID tokens, D1 data, or confidential provider credentials to the portal.
+- Never forward shopper or authorization-flow cookies to `PORTAL_UI`, and never accept `Set-Cookie` or `Clear-Site-Data` from it. The gateway is the sole owner of authentication state and browser security headers.
 - Add new resources and services to both `wrangler.jsonc` and `tender-app.config.json`; packaging must fail if they disagree.
 - Run `npm run check` from this directory after gateway changes.

package/templates/shopify-customer-account/apps/gateway/dot.dev.vars.example

@@ -7,6 +7,6 @@ SHOPIFY_STOREFRONT_DOMAIN=example.myshopify.com
 SHOPIFY_CUSTOMER_ACCOUNT_CLIENT_ID=replace_me
 SHOPIFY_CUSTOMER_ACCOUNT_DOMAIN=shopify.com
 
-# Optional CI/manual fallback. Normal development uses `tender-accounts auth login`.
+# Optional CI/manual fallback. Normal development uses a named `tender-accounts auth create` profile.
 # If used locally, keep it only in ignored .dev.vars.
 # TENDER_ACCOUNTS_TOKEN=ta_agent_...

package/templates/shopify-customer-account/apps/gateway/src/portal-service.test.ts

@@ -2,17 +2,69 @@ import { describe, expect, it } from "vitest";
 import { forwardPortalRequest } from "./portal-service";
 
 describe("portal service binding", () => {
-  it("forwards the browser path without exposing platform headers", async () => {
-    const response = await forwardPortalRequest(new Request("https://account.example.test/account"), {
-      fetch: async (request) => {
-        const url = request instanceof Request ? request.url : request.toString();
-        return new Response(new URL(url).pathname, {
-          headers: { "cf-ray": "private", "content-type": "text/plain" },
+  it("forwards the browser path and safe presentation headers without the shopper session", async () => {
+    let capturedRequest: Request | null = null;
+    const incoming = new Request("https://account.example.test/account?view=orders", {
+      headers: {
+        accept: "text/html",
+        "accept-language": "en-US",
+        "content-type": "application/json",
+        cookie: "__Host-tender_accounts_session=private-session; auth_flow=private-flow",
+        origin: "https://account.example.test",
+        referer: "https://account.example.test/account/private-order",
+        "user-agent": "Tender portal test",
+        "cf-access-jwt-assertion": "private-access-token",
+        "x-tender-preview-grant": "private-preview-token",
+      },
+    });
+
+    const response = await forwardPortalRequest(incoming, {
+      fetch: async (input, init) => {
+        const request = input instanceof Request ? input : new Request(input, init);
+        capturedRequest = request;
+        return new Response(`${new URL(request.url).pathname}${new URL(request.url).search}`, {
+          headers: { "content-type": "text/plain" },
         });
       },
     });
-    expect(await response.text()).toBe("/account");
+
+    if (capturedRequest === null) throw new Error("The portal service binding was not invoked.");
+    const forwarded: Request = capturedRequest;
+    expect(await response.text()).toBe("/account?view=orders");
+    expect(forwarded.headers.get("accept")).toBe("text/html");
+    expect(forwarded.headers.get("accept-language")).toBe("en-US");
+    expect(forwarded.headers.get("user-agent")).toBe("Tender portal test");
+    expect(forwarded.headers.get("content-type")).toBeNull();
+    expect(forwarded.headers.get("cookie")).toBeNull();
+    expect(forwarded.headers.get("origin")).toBeNull();
+    expect(forwarded.headers.get("referer")).toBeNull();
+    expect(forwarded.headers.get("cf-access-jwt-assertion")).toBeNull();
+    expect(forwarded.headers.get("x-tender-preview-grant")).toBeNull();
+  });
+
+  it("prevents the portal from writing gateway cookies or weakening browser security headers", async () => {
+    const response = await forwardPortalRequest(new Request("https://account.example.test/account"), {
+      fetch: async () => new Response("portal", {
+        headers: {
+          "cf-ray": "private",
+          "clear-site-data": '"cookies"',
+          "content-security-policy": "default-src * 'unsafe-inline'",
+          "content-type": "text/plain",
+          "permissions-policy": "camera=*",
+          "set-cookie": "__Host-tender_accounts_session=attacker-controlled; Secure; Path=/",
+          "x-tender-internal": "private",
+        },
+      }),
+    });
+
+    expect(await response.text()).toBe("portal");
     expect(response.headers.get("cf-ray")).toBeNull();
+    expect(response.headers.get("clear-site-data")).toBeNull();
+    expect(response.headers.get("set-cookie")).toBeNull();
+    expect(response.headers.get("x-tender-internal")).toBeNull();
+    expect(response.headers.get("content-security-policy")).toContain("connect-src 'self'");
+    expect(response.headers.get("content-security-policy")).not.toContain("unsafe-inline");
+    expect(response.headers.get("permissions-policy")).toBe("camera=(), geolocation=(), microphone=(), payment=()");
     expect(response.headers.get("x-frame-options")).toBe("DENY");
   });
 });

package/templates/shopify-customer-account/apps/gateway/src/portal-service.ts

@@ -1,10 +1,21 @@
 export type PortalService = Pick<Fetcher, "fetch">;
 
 const FORWARDED_HEADERS = [
-  "accept", "accept-language", "cache-control", "content-type", "cookie",
-  "if-match", "if-none-match", "origin", "pragma", "referer", "user-agent",
+  "accept", "accept-language", "cache-control", "if-modified-since",
+  "if-none-match", "if-range", "pragma", "range", "user-agent",
 ] as const;
 
+const PORTAL_CONTENT_SECURITY_POLICY = [
+  "default-src 'self'",
+  "base-uri 'none'",
+  "connect-src 'self'",
+  "frame-ancestors 'none'",
+  "img-src 'self' data:",
+  "object-src 'none'",
+  "script-src 'self'",
+  "style-src 'self'",
+].join("; ");
+
 export async function forwardPortalRequest(request: Request, portal: PortalService): Promise<Response> {
   if (!portal || typeof portal.fetch !== "function") return gatewayError(503, "portal_ui_unavailable");
   try {
@@ -12,10 +23,19 @@ export async function forwardPortalRequest(request: Request, portal: PortalServi
     const headers = new Headers(response.headers);
     for (const name of [...headers.keys()]) {
       const normalized = name.toLowerCase();
-      if (normalized.startsWith("cf-") || normalized.startsWith("cloudflare-") || normalized.startsWith("x-tender-")) {
+      if (
+        normalized === "set-cookie"
+        || normalized === "set-cookie2"
+        || normalized === "clear-site-data"
+        || normalized.startsWith("cf-")
+        || normalized.startsWith("cloudflare-")
+        || normalized.startsWith("x-tender-")
+      ) {
         headers.delete(name);
       }
     }
+    headers.set("Content-Security-Policy", PORTAL_CONTENT_SECURITY_POLICY);
+    headers.set("Permissions-Policy", "camera=(), geolocation=(), microphone=(), payment=()");
     headers.set("Referrer-Policy", "strict-origin-when-cross-origin");
     headers.set("X-Content-Type-Options", "nosniff");
     headers.set("X-Frame-Options", "DENY");

package/templates/shopify-customer-account/apps/portal/AGENTS.md

@@ -3,6 +3,7 @@
 This React app is the normal merchant and marketing-team editing surface.
 
 - Keep it presentation-only. It may call same-origin gateway routes but must not receive Shopify customer tokens, D1 bindings, or provider secrets.
+- Do not request forwarded browser cookies or authorization headers from the gateway. React should use same-origin `/api/*` calls; the browser supplies the `HttpOnly` session directly to the gateway.
 - For UI-only work, never edit `../gateway`.
 - Use real gateway responses; do not add fake authenticated customer data to production code.
 - Keep keyboard navigation, focus states, reduced-motion behavior, and responsive layouts intact.

package/templates/shopify-customer-account/apps/portal/README.md

@@ -3,3 +3,5 @@
 React customer-account surface for __APP_NAME__. This app is independently deployable and intentionally has no confidential bindings or customer-token storage.
 
 The portal calls only same-origin gateway routes such as `/api/bootstrap` and `/api/session`. Most vibe-coded visual and content changes should stay in this directory.
+
+The portal service never receives the browser's shopper-session cookie. React can still call protected same-origin APIs because those requests terminate at the gateway, where the `HttpOnly` session is validated. Portal responses also cannot set or clear cookies on the customer hostname.

package/templates/shopify-customer-account/dot.dev.vars.example

@@ -1,4 +1,4 @@
 # Optional CI/manual fallback for the linked Tender projects.
-# Developers and coding agents should use `tender-accounts auth login` instead.
+# Developers and coding agents should use a named `tender-accounts auth create` profile instead.
 # This value is never retained in an application artifact.
 TENDER_ACCOUNTS_TOKEN=