@tenderprompt/accounts 0.8.4 → 0.9.0

package/skill/tender-accounts/SKILL.md

@@ -1,372 +0,0 @@
----
-name: tender-accounts
-description: Create, build, validate, and preview merchant-owned Tender Accounts applications with the project-scoped CLI. Use when starting a new customer account, changing a repository that contains tender-accounts.json, implementing a customer-account feature, diagnosing a Tender Accounts preview, or preparing an exact preview for review.
----
-
-# Tender Accounts application delivery
-
-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
-
-When the user asked for a new Shopify customer-account repository and the target is empty, inspect the exact plan and then create the optional starter:
-
-```sh
-npx @tenderprompt/accounts init --name "Merchant customer account" --directory ./merchant-account --dry-run --json
-npx @tenderprompt/accounts init --name "Merchant customer account" --directory ./merchant-account --json
-```
-
-Never run `init` inside an existing application or use it to replace a merchant's architecture. It creates a stable gateway and independently editable `apps/portal`. UI-only tasks stay in the portal; authentication, sessions, application data, confidential bindings, and protected APIs stay in the gateway. The command deliberately does not install dependencies, initialize Git, link projects, or deploy.
-
-## Materialize an existing app before scope discovery
-
-If the user gives an exact `prj_...` but the current workspace is empty, do not
-ask them to open a repository before asking Tender which managed source belongs
-to that project. Install this skill, authenticate to the exact project, then run:
-
-```sh
-npx @tenderprompt/accounts auth create prj_... --device --project prj_... --json
-# After approval:
-npx @tenderprompt/accounts auth status --profile prj_... --json
-npx @tenderprompt/accounts auth activate prj_... --json
-npx @tenderprompt/accounts source status --project prj_... --json
-npx @tenderprompt/accounts source pull --project prj_... --json
-```
-
-`source pull` uses standard Git. In an empty directory it clones the exact
-connected Tender-managed repository; in an existing clean matching checkout it
-performs a fast-forward-only pull. It then writes the machine-local project link
-for the configured app. The short-lived repository credential exists only in
-the Git child process and is never stored in the remote URL, repository, CLI
-output, or shell history.
-
-The command refuses non-empty non-Git directories, dirty worktrees, detached
-HEADs, mismatched remotes, paused sources, conflicting project links, and unsafe
-managed working directories. Do not work around those checks with `source
-connect`, a hand-written remote, or a copied token. If the project uses
-merchant-hosted Git instead of Tender-managed Git, open that exact checkout and
-continue with `link`; Tender cannot clone a private third-party repository with
-a managed-source credential.
-
-## Start every task with scope discovery
-
-1. After the checkout exists, read the closest `AGENTS.md` files and `tender-accounts.json`. In a generated two-service repository, identify whether the request belongs to `apps/portal` or `apps/gateway` before editing.
-2. Run:
-
-   ```sh
-   npx @tenderprompt/accounts doctor --json
-   ```
-
-3. Stop if configuration, authentication, linking, or project access fails. Report the exact error code and remediation. Never bypass the CLI with direct API calls.
-4. Confirm the linked project is the application the user requested. Use `--cwd apps/portal` or `--cwd apps/gateway` from a generated repository. Do not edit a gateway, service, or portal outside the current repository and credential scope.
-
-If authentication is missing, start the agent-safe device flow:
-
-```sh
-npx @tenderprompt/accounts auth create <merchant-or-work-context> --device --no-open --json
-```
-
-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
-<the exact profile-aware auth status command returned by auth create>
-```
-
-Then activate that profile from the repository root so it applies to every descendant app:
-
-```sh
-npx @tenderprompt/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. Ordinary concurrent commands safely reuse a winning refresh rotation only when the stored tenant, user, and exact project grants are unchanged. If a command returns `auth_profile_changed`, a non-equivalent login, replacement, 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 @tenderprompt/accounts auth list --json
-npx @tenderprompt/accounts auth status --profile <name> --json
-```
-
-If the app has not been linked, run:
-
-```sh
-npx @tenderprompt/accounts link --json
-```
-
-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.
-
-If the merchant wants Tender to own the Git transport, use the CLI for either
-the linked gateway or service project:
-
-```sh
-npx @tenderprompt/accounts source connect --publication preview-only --json
-npx @tenderprompt/accounts source status --json
-npx @tenderprompt/accounts source pull --json
-npx @tenderprompt/accounts source push --json
-```
-
-Run these commands from the independently deployable app directory, or use its
-exact `--cwd`. `source connect` derives the project working directory and build
-contract from Git plus `tender-accounts.json`; do not recreate that contract by
-hand in the admin. Protected gateways must stay `preview-only`. Use
-`--publication default-branch` only for an ordinary service when the merchant
-explicitly wants successful default-branch previews promoted automatically.
-
-`source push` includes only the committed revision. On a reviewed repository it
-uploads a bounded Git bundle through Tender; the trusted runner verifies the
-exact commit and may update only the named non-default branch. The developer
-never receives a provider write credential. On a repository that has not yet
-enabled reviewed changes, the legacy short-lived Git credential path remains
-available during migration. Never copy any credential into a remote URL,
-credential helper, repository file, shell script, or chat. `source pull` is the
-inverse operation for an already connected repository and never creates or
-replaces the source connection. `source token` is read-only.
-
-When `source status` reports `changeRequestProtection: enabled`, use the normal
-reviewed flow:
-
-```sh
-npx @tenderprompt/accounts source push --branch feature/account-copy --json
-npx @tenderprompt/accounts source change create \
-  --head feature/account-copy \
-  --title "Update account copy" --json
-npx @tenderprompt/accounts source change show --change scr_... --json
-```
-
-Return the `scr_` ID and exact preview state to the user. A developer or coding
-agent stops after the exact preview is ready. Approval and **Land in main** are
-merchant-administrator actions in Tender. Do not push the default branch,
-obtain a raw provider token, call internal APIs, or replace this flow with
-`source promote` after reviewed changes are enabled.
-
-Inspect branches and history through read-only ephemeral credentials:
-
-```sh
-npx @tenderprompt/accounts source branches --json
-npx @tenderprompt/accounts source log --branch main --limit 20 --json
-npx @tenderprompt/accounts source compare --base main --head feature/account-copy --json
-```
-
-Use standalone source-administration commands only for repositories where
-reviewed changes are not enabled and when the user explicitly requests a
-default-branch or history change and the active profile belongs to a merchant
-source administrator. First record `source branches`, `source compare`, the
-successful exact preview for the proposed head, and the current production
-composition. Run the exact operation with `--dry-run` before applying it.
-
-For an ordinary checked fast-forward, supply the current target SHA and a
-stable idempotency key:
-
-```sh
-npx @tenderprompt/accounts source promote \
-  --head feature/account-copy \
-  --expected-current <exact-current-default-sha> \
-  --idempotency-key account-copy-v1 \
-  --dry-run --json
-```
-
-For an exceptional migration, use only the guarded history workflow:
-
-```sh
-npx @tenderprompt/accounts source history replace \
-  --head app-only-main \
-  --expected-current <exact-current-default-sha> \
-  --confirm <exact-src-repository-id> \
-  --idempotency-key app-only-history-v1 \
-  --dry-run --json
-```
-
-Inspect the returned `sop_` operation with `source operation status`. Apply the
-same request without `--dry-run` only after the dry-run evidence matches the
-intended repository, project, branches, SHA, preview build, and composition.
-Never substitute a raw token, direct API, Git force push, ref deletion, or D1
-edit. Tender creates and verifies an archive before history replacement and
-uses an expected-SHA compare-and-swap for the target. History migration always
-suppresses automatic production publication; protected gateways always remain
-preview-only.
-
-If a durable source operation fails for a transient provider or runner reason,
-inspect and resume that same reviewed intent by ID:
-
-```sh
-npx @tenderprompt/accounts source operation status --operation sop_... --json
-npx @tenderprompt/accounts source operation retry --operation sop_... --json
-```
-
-Do not create a replacement request merely to retry infrastructure. A stale
-target, missing preview, archive conflict, or rejected permission requires the
-stated remediation and a newly reviewed request instead.
-
-For reviewed repositories, a moved head invalidates the previous approval and
-the newest source build becomes the next exact snapshot. A moved base makes the
-change stale. Rebase or update the feature branch, push a new committed
-revision, wait for its exact preview, and have the administrator review that
-new snapshot. Source landing never calls the production publisher directly;
-after landing, the repository's already configured default-branch policy may
-publish the same successful exact preview. Protected gateways remain
-preview-only.
-
-Treat source administration and production publication as different acts. A
-source operation may create a new immutable preview lineage, but only the
-merchant's established exact-composition control can publish production. For a
-portal and gateway changed together, preview both immutable revisions and
-review the sealed combined composition; do not pretend two repository refs can
-be changed atomically or publish whatever happens to be on each default branch.
-
-## 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 @tenderprompt/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 `doctor` for every independently deployable application you changed. In a generated repository:
-
-   ```sh
-   npx @tenderprompt/accounts doctor --cwd apps/portal --json
-   npx @tenderprompt/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 @tenderprompt/accounts check --json
-   ```
-
-6. Validate the complete portable artifact without uploading it:
-
-   ```sh
-   npx @tenderprompt/accounts preview --dry-run --json
-   ```
-
-Do not weaken checks, remove declared bindings, or place runtime values in the artifact to make validation pass.
-
-## Create an exact preview
-
-After local validation succeeds, preview each changed application. For a portal-only change, run:
-
-```sh
-npx @tenderprompt/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 @tenderprompt/accounts preview --cwd apps/portal --json
-npx @tenderprompt/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:
-
-```sh
-npx @tenderprompt/accounts delivery status --delivery <delivery-id> --json
-```
-
-Retry only a requested or failed preview workflow:
-
-```sh
-npx @tenderprompt/accounts delivery retry --delivery <delivery-id> --json
-```
-
-Mint a new browser session for an already-succeeded delivery without rebuilding:
-
-```sh
-npx @tenderprompt/accounts delivery preview --delivery <delivery-id> --json
-```
-
-`<delivery-id>` is the `dly_` value returned by `preview`. A `dwf_` value is a production workflow ID and must not be passed to developer-delivery commands. If a merchant administrator sees a `dwf_` publish waiting with zero attempts, the supported recovery is **Activity → Resume exact publish**; it resumes the stored exact composition without rebuilding. Use the error code, request ID, and suggested command from the CLI. Do not retry with altered IDs, another project, or raw HTTP requests.
-
-When runtime evidence is needed, stream only the linked project and exact target:
-
-```sh
-npx @tenderprompt/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.
-- Never call Tender Accounts internal APIs with `curl` or custom scripts.
-- Never print, read back, commit, or copy `.dev.vars`, CLI login, refresh, or access-token values.
-- Never put Shopify, subscription-provider, or other merchant credentials in source, build output, logs, or screenshots.
-- Never claim the log relay can redact a credential that merchant code writes as an unlabelled string; application logging must avoid customer data and secrets.
-- Never change `.tender/link.json` by hand; use `tender-accounts link`.
-- Never publish production from an agent credential. The CLI intentionally has no publish command.
-- Never expand project scope. Ask a merchant administrator for a different credential when the requested app is outside the current grant.
-- Never treat a successful preview as a production release, merge, commit, or push.
-
-Production moves only through the merchant's protected default-branch policy or an authenticated merchant administrator in the Tender Accounts console.

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

@@ -1,15 +0,0 @@
-# __APP_NAME__ application boundary
-
-This is a merchant-owned Tender Accounts application. The gateway and portal are independently deployable projects.
-
-## Working rules
-
-- 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 @tenderprompt/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.
-- Shopify and selected commerce providers remain systems of record. Do not duplicate their durable business state without an explicit design.
-- Run the closest app checks and `npx @tenderprompt/accounts preview --dry-run --json` before creating a preview.

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

@@ -1 +0,0 @@
-@AGENTS.md

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

@@ -1,50 +0,0 @@
-# __APP_NAME__
-
-Merchant-owned Shopify customer account built as two independently deployable Tender Accounts applications:
-
-```text
-customer hostname
-       |
-       v
-apps/gateway  -- PORTAL_UI service binding -->  apps/portal
-Shopify auth                                  React UI
-HttpOnly sessions                             no customer tokens
-application D1                                no confidential bindings
-/auth/* and /api/*
-```
-
-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`.
-2. Initialize Git and make the first commit.
-3. Copy `apps/gateway/.dev.vars.example` to `apps/gateway/.dev.vars` and replace only the public configuration values.
-4. Run `npm run dev`.
-
-Local development intentionally stays signed out because Shopify requires registered HTTPS callback URLs. Use an immutable Tender preview to test real sign-in.
-
-## Create a preview
-
-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 @tenderprompt/accounts auth create {{slug}}
-npx @tenderprompt/accounts auth activate {{slug}}
-npx @tenderprompt/accounts link --cwd apps/portal --json
-npx @tenderprompt/accounts doctor --cwd apps/portal --json
-npx @tenderprompt/accounts preview --cwd apps/portal --dry-run --json
-npx @tenderprompt/accounts preview --cwd apps/portal --json
-```
-
-Coding agents should use `npx @tenderprompt/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.
-
-## Configure Shopify
-
-Register the canonical gateway hostname as the JavaScript origin and use its `/auth/callback` and `/auth/logout/callback` URLs in Shopify Customer Account settings. Put the public client ID and Shopify domains in the gateway's local `.dev.vars`; Tender injects the environment values for previews and production.
-
-If the platform connects a merchant vanity domain, add that exact origin plus its `/auth/callback` and `/auth/logout/callback` URLs in Shopify, then set `ACCOUNT_VANITY_HOSTNAMES` in the gateway environment. Production sign-in and renewal will stay on the vanity hostname. Unregistered preview hosts continue to use the canonical callback and a one-time exact-host handoff. This value is public hostname policy, not a credential. The React portal needs no vanity-domain configuration.

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

@@ -1,10 +0,0 @@
-# Gateway boundary
-
-This app owns authentication, HttpOnly sessions, application D1 state, `/auth/*`, and protected `/api/*` routes.
-
-- 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/CLAUDE.md

@@ -1 +0,0 @@
-@AGENTS.md

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

@@ -1,9 +0,0 @@
-# Gateway
-
-Stable backend for __APP_NAME__. It owns Shopify Customer Account PKCE authentication, shopper sessions in D1, application API routes, and the `PORTAL_UI` service binding.
-
-The customer-auth implementation is normal merchant source code copied by the starter. The merchant can inspect, edit, or replace it. Shopify remains the customer system of record; D1 stores only transient auth state and application sessions.
-
-Local HTTP development returns an explicit signed-out state. Real Shopify sign-in must use an HTTPS Tender preview whose canonical callback and logout URLs are registered in Shopify.
-
-The generated `.dev` hostname stays the Shopify callback anchor. When a merchant vanity domain is activated, add it to the public comma-separated `ACCOUNT_VANITY_HOSTNAMES` environment value so the exact-host session policy can safely return the shopper there. Do not move Shopify callback configuration to the vanity hostname.

package/templates/shopify-customer-account/apps/gateway/database-schema.json

@@ -1,49 +0,0 @@
-{
-  "schema": "tender.d1-schema/v1",
-  "statements": [
-    "CREATE TABLE IF NOT EXISTS public_customer_auth_flows (\n    project_id TEXT NOT NULL,\n    state_digest TEXT NOT NULL,\n    browser_binding_digest TEXT NOT NULL,\n    client_key_digest TEXT NOT NULL,\n    interaction_mode TEXT NOT NULL,\n    pkce_verifier TEXT NOT NULL,\n    return_hostname TEXT NOT NULL,\n    created_at INTEGER NOT NULL,\n    expires_at INTEGER NOT NULL,\n    consumed_at INTEGER,\n    PRIMARY KEY (project_id, state_digest),\n    CHECK (length(project_id) BETWEEN 2 AND 128),\n    CHECK (length(state_digest) = 64),\n    CHECK (state_digest NOT GLOB '*[^0-9a-f]*'),\n    CHECK (length(browser_binding_digest) = 64),\n    CHECK (browser_binding_digest NOT GLOB '*[^0-9a-f]*'),\n    CHECK (length(client_key_digest) = 64),\n    CHECK (client_key_digest NOT GLOB '*[^0-9a-f]*'),\n    CHECK (interaction_mode IN ('interactive', 'silent')),\n    CHECK (length(pkce_verifier) BETWEEN 43 AND 128),\n    CHECK (length(return_hostname) BETWEEN 1 AND 253),\n    CHECK (return_hostname = lower(return_hostname)),\n    CHECK (expires_at > created_at),\n    CHECK (consumed_at IS NULL OR consumed_at BETWEEN created_at AND expires_at)\n  )",
-    "CREATE INDEX IF NOT EXISTS public_customer_auth_flows_by_expiry\n    ON public_customer_auth_flows (expires_at)",
-    "CREATE TABLE IF NOT EXISTS public_customer_auth_sessions (\n    project_id TEXT NOT NULL,\n    session_digest TEXT NOT NULL,\n    audience_hostname TEXT NOT NULL,\n    session_data TEXT NOT NULL,\n    created_at INTEGER NOT NULL,\n    expires_at INTEGER NOT NULL,\n    PRIMARY KEY (project_id, session_digest),\n    CHECK (length(project_id) BETWEEN 2 AND 128),\n    CHECK (length(session_digest) = 64),\n    CHECK (session_digest NOT GLOB '*[^0-9a-f]*'),\n    CHECK (length(audience_hostname) BETWEEN 1 AND 253),\n    CHECK (audience_hostname = lower(audience_hostname)),\n    CHECK (length(session_data) BETWEEN 1 AND 65536),\n    CHECK (expires_at > created_at)\n  )",
-    "CREATE INDEX IF NOT EXISTS public_customer_auth_sessions_by_expiry\n    ON public_customer_auth_sessions (expires_at)",
-    "CREATE TABLE IF NOT EXISTS public_customer_auth_handoffs (\n    project_id TEXT NOT NULL,\n    handoff_digest TEXT NOT NULL,\n    return_hostname TEXT NOT NULL,\n    session_digest TEXT NOT NULL,\n    session_seal TEXT NOT NULL,\n    created_at INTEGER NOT NULL,\n    expires_at INTEGER NOT NULL,\n    claimed_at INTEGER,\n    PRIMARY KEY (project_id, handoff_digest),\n    CHECK (length(project_id) BETWEEN 2 AND 128),\n    CHECK (length(handoff_digest) = 64),\n    CHECK (handoff_digest NOT GLOB '*[^0-9a-f]*'),\n    CHECK (length(return_hostname) BETWEEN 1 AND 253),\n    CHECK (return_hostname = lower(return_hostname)),\n    CHECK (length(session_digest) = 64),\n    CHECK (session_digest NOT GLOB '*[^0-9a-f]*'),\n    CHECK (length(session_seal) BETWEEN 80 AND 100000),\n    CHECK (expires_at > created_at),\n    CHECK (claimed_at IS NULL OR claimed_at BETWEEN created_at AND expires_at)\n  )",
-    "CREATE INDEX IF NOT EXISTS public_customer_auth_handoffs_by_expiry\n    ON public_customer_auth_handoffs (expires_at)"
-  ],
-  "objects": [
-    {
-      "type": "table",
-      "name": "public_customer_auth_flows",
-      "tableName": "public_customer_auth_flows",
-      "statementIndex": 0
-    },
-    {
-      "type": "index",
-      "name": "public_customer_auth_flows_by_expiry",
-      "tableName": "public_customer_auth_flows",
-      "statementIndex": 1
-    },
-    {
-      "type": "table",
-      "name": "public_customer_auth_sessions",
-      "tableName": "public_customer_auth_sessions",
-      "statementIndex": 2
-    },
-    {
-      "type": "index",
-      "name": "public_customer_auth_sessions_by_expiry",
-      "tableName": "public_customer_auth_sessions",
-      "statementIndex": 3
-    },
-    {
-      "type": "table",
-      "name": "public_customer_auth_handoffs",
-      "tableName": "public_customer_auth_handoffs",
-      "statementIndex": 4
-    },
-    {
-      "type": "index",
-      "name": "public_customer_auth_handoffs_by_expiry",
-      "tableName": "public_customer_auth_handoffs",
-      "statementIndex": 5
-    }
-  ]
-}

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

@@ -1,12 +0,0 @@
-# Public Shopify and Tender runtime configuration. Replace these locally.
-ACCOUNT_TENANT_ID=ten_replace_me
-ACCOUNT_PROJECT_ID=prj_replace_me
-ACCOUNT_RUNTIME_BASE_DOMAIN=tenderprompt.dev
-ACCOUNT_VANITY_HOSTNAMES=
-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 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/migrations/0001_customer_auth.sql

@@ -1,76 +0,0 @@
--- Application-owned auth/session state. Shopify remains the customer system of record.
-
-CREATE TABLE IF NOT EXISTS public_customer_auth_flows (
-    project_id TEXT NOT NULL,
-    state_digest TEXT NOT NULL,
-    browser_binding_digest TEXT NOT NULL,
-    client_key_digest TEXT NOT NULL,
-    interaction_mode TEXT NOT NULL,
-    pkce_verifier TEXT NOT NULL,
-    return_hostname TEXT NOT NULL,
-    created_at INTEGER NOT NULL,
-    expires_at INTEGER NOT NULL,
-    consumed_at INTEGER,
-    PRIMARY KEY (project_id, state_digest),
-    CHECK (length(project_id) BETWEEN 2 AND 128),
-    CHECK (length(state_digest) = 64),
-    CHECK (state_digest NOT GLOB '*[^0-9a-f]*'),
-    CHECK (length(browser_binding_digest) = 64),
-    CHECK (browser_binding_digest NOT GLOB '*[^0-9a-f]*'),
-    CHECK (length(client_key_digest) = 64),
-    CHECK (client_key_digest NOT GLOB '*[^0-9a-f]*'),
-    CHECK (interaction_mode IN ('interactive', 'silent')),
-    CHECK (length(pkce_verifier) BETWEEN 43 AND 128),
-    CHECK (length(return_hostname) BETWEEN 1 AND 253),
-    CHECK (return_hostname = lower(return_hostname)),
-    CHECK (expires_at > created_at),
-    CHECK (consumed_at IS NULL OR consumed_at BETWEEN created_at AND expires_at)
-  );
-
-CREATE INDEX IF NOT EXISTS public_customer_auth_flows_by_expiry
-    ON public_customer_auth_flows (expires_at);
-
-CREATE TABLE IF NOT EXISTS public_customer_auth_sessions (
-    project_id TEXT NOT NULL,
-    session_digest TEXT NOT NULL,
-    audience_hostname TEXT NOT NULL,
-    session_data TEXT NOT NULL,
-    created_at INTEGER NOT NULL,
-    expires_at INTEGER NOT NULL,
-    PRIMARY KEY (project_id, session_digest),
-    CHECK (length(project_id) BETWEEN 2 AND 128),
-    CHECK (length(session_digest) = 64),
-    CHECK (session_digest NOT GLOB '*[^0-9a-f]*'),
-    CHECK (length(audience_hostname) BETWEEN 1 AND 253),
-    CHECK (audience_hostname = lower(audience_hostname)),
-    CHECK (length(session_data) BETWEEN 1 AND 65536),
-    CHECK (expires_at > created_at)
-  );
-
-CREATE INDEX IF NOT EXISTS public_customer_auth_sessions_by_expiry
-    ON public_customer_auth_sessions (expires_at);
-
-CREATE TABLE IF NOT EXISTS public_customer_auth_handoffs (
-    project_id TEXT NOT NULL,
-    handoff_digest TEXT NOT NULL,
-    return_hostname TEXT NOT NULL,
-    session_digest TEXT NOT NULL,
-    session_seal TEXT NOT NULL,
-    created_at INTEGER NOT NULL,
-    expires_at INTEGER NOT NULL,
-    claimed_at INTEGER,
-    PRIMARY KEY (project_id, handoff_digest),
-    CHECK (length(project_id) BETWEEN 2 AND 128),
-    CHECK (length(handoff_digest) = 64),
-    CHECK (handoff_digest NOT GLOB '*[^0-9a-f]*'),
-    CHECK (length(return_hostname) BETWEEN 1 AND 253),
-    CHECK (return_hostname = lower(return_hostname)),
-    CHECK (length(session_digest) = 64),
-    CHECK (session_digest NOT GLOB '*[^0-9a-f]*'),
-    CHECK (length(session_seal) BETWEEN 80 AND 100000),
-    CHECK (expires_at > created_at),
-    CHECK (claimed_at IS NULL OR claimed_at BETWEEN created_at AND expires_at)
-  );
-
-CREATE INDEX IF NOT EXISTS public_customer_auth_handoffs_by_expiry
-    ON public_customer_auth_handoffs (expires_at);

package/templates/shopify-customer-account/apps/gateway/package.json

@@ -1,25 +0,0 @@
-{
-  "name": "__APP_SLUG__-gateway",
-  "version": "0.1.0",
-  "private": true,
-  "type": "module",
-  "scripts": {
-    "build": "node ./scripts/build-worker.mjs",
-    "cf:types": "wrangler types --include-runtime false",
-    "check": "npm run typecheck && npm run test && npm run build && npm run pack:check",
-    "db:migrate:local": "wrangler d1 migrations apply __APP_SLUG__-sessions --local",
-    "dev": "wrangler dev",
-    "pack:tender": "node ./scripts/pack-tender-artifact.mjs",
-    "pack:check": "node ./scripts/pack-tender-artifact.mjs --vars .dev.vars.example --source-revision ffffffffffffffffffffffffffffffffffffffff",
-    "test": "vitest run",
-    "typecheck": "tsc --noEmit"
-  },
-  "devDependencies": {
-    "@cloudflare/workers-types": "^5.20260825.1",
-    "@types/node": "^26.2.0",
-    "esbuild": "^0.25.9",
-    "typescript": "^7.0.2",
-    "vitest": "^4.1.11",
-    "wrangler": "^4.125.0"
-  }
-}

package/templates/shopify-customer-account/apps/gateway/scripts/build-worker.mjs

@@ -1,15 +0,0 @@
-import { build } from "esbuild";
-
-await build({
-  entryPoints: ["src/worker.ts"],
-  outfile: ".tender/build/worker.mjs",
-  bundle: true,
-  format: "esm",
-  platform: "neutral",
-  target: "es2022",
-  external: ["node:*"],
-  legalComments: "none",
-  sourcemap: false,
-  minify: false,
-  logLevel: "info",
-});