@withandeo/cli 0.9.0 → 0.9.1

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@withandeo/cli",
-  "version": "0.9.0",
+  "version": "0.9.1",
   "description": "Developer CLI for Andeo applications",
   "type": "module",
   "license": "UNLICENSED",

package/skill/tender-accounts/SKILL.md

@@ -5,6 +5,8 @@ description: Create, build, validate, and preview merchant-owned Andeo applicati
 
 # Andeo application delivery
 
+The product name is **Andeo**. In customer-facing copy, describe sign-in, organization membership, app access, and application storage without naming infrastructure providers. Keep exact technical identifiers in executable code and configuration, and name merchant integrations when they explain the feature.
+
 Use the `andeo` CLI (`npx @withandeo/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
@@ -193,7 +195,7 @@ npx @withandeo/cli source history replace \
 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
+Never substitute a raw token, direct API, Git force push, ref deletion, or database
 edit. Andeo 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
@@ -242,7 +244,7 @@ Inspect the merchant's current storefront or portal, repository, existing API cl
 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.
+- **Portal and gateway:** a new authenticated read or mutation, Shopify Customer Account query, provider integration, application database 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.

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

@@ -6,7 +6,7 @@ This is a merchant-owned Andeo application. The gateway and portal are independe
 
 - 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.
+- Keep `apps/portal` free of Shopify customer tokens, session storage, database 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 @withandeo/cli` for project linking, validation, and previews. Never call Andeo internal APIs directly.
 - Never run `wrangler deploy`; production and preview delivery are controlled by Andeo.

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

@@ -9,7 +9,7 @@ customer hostname
 apps/gateway  -- PORTAL_UI service binding -->  apps/portal
 Shopify auth                                  React UI
 HttpOnly sessions                             no customer tokens
-application D1                                no confidential bindings
+application database                                no confidential bindings
 /auth/* and /api/*
 ```
 

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

@@ -1,10 +1,10 @@
 # Gateway boundary
 
-This app owns authentication, HttpOnly sessions, application D1 state, `/auth/*`, and protected `/api/*` routes.
+This app owns authentication, HttpOnly sessions, application database 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 expose customer access tokens, ID tokens, database 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/README.md

@@ -1,8 +1,8 @@
 # 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.
+Stable backend for __APP_NAME__. It owns Shopify Customer Account PKCE authentication, shopper sessions in the application database, 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.
+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; The application database 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.
 

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

@@ -1,7 +1,7 @@
 # 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_RUNTIME_BASE_DOMAIN=andeo.dev
 ACCOUNT_VANITY_HOSTNAMES=
 SHOPIFY_STOREFRONT_DOMAIN=example.myshopify.com
 SHOPIFY_CUSTOMER_ACCOUNT_CLIENT_ID=replace_me

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

@@ -2,7 +2,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.
+- Keep it presentation-only. It may call same-origin gateway routes but must not receive Shopify customer tokens, database 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.