"""Shared instructions for existing templates and future starter snapshots."""

CLOUD_CONTRACT_INSTRUCTIONS = """# P2HS Cloud backend contract

P2HS Cloud is the only authoritative backend for generated HTML, React and Nuxt apps.
Core owns tenancy, permissions, entitlements, configuration and provisioning policy.
Cloud owns records, app-user authentication, storage, jobs and provider execution.

## Rendering and data access

Keep the template's design and framework. Nuxt/Nitro (and CF Pages Functions for
React/HTML) can render pages and run thin, per-port BFF routes. Do not create Nitro
useStorage databases, local SQLite/JSON/password stores, in-memory authoritative Maps,
or browser-local business databases. UI state and disposable caches are fine. Missing
Cloud configuration must produce HTTP 503, never fake success or a fallback database.
Display sample data must be explicitly labelled as a demo; do not persist it as real
customer data or seed reusable login credentials.

Every Cloud capability (auth, records, storage, bookings, jobs, ai, functions, imports)
is installed as its own typed route from the Platform Port Catalog, pinned in
p2hs/platform-ports.lock.json. There is no single catch-all BFF proxy — never create one,
never hand-edit an installed file, and never add a route that shadows an installed path;
the pre-push guard rejects all three. Call installed routes directly.

Use platform auth for identities. The bundled /api/records adapter (and /api/admin/users)
is a staff-only administrative surface; it authenticates admin/super_admin then uses the
service token. Do not use that adapter for customer records or simply remove its staff
check. Customer-facing BFF routes on an rls_enabled entity must forward the user's own
JWT to Cloud (via the session-gated aggregate/facet/bulk-update/bulk-delete routes, or a
route you write) so row-level security remains effective — never swap in the service
token for a customer operation. Use the full project manifest for exact entity keys,
action contracts and availability. Declare entities/fields in p2hs/provision.json; Core
provisions them before deployment. Do not create arbitrary entities at request time.

Every project with auth enabled has three fixed role tiers — super_admin (workspace
owner; billing + staff management) > admin (invited staff) > member (default customer
role) — carried in the session JWT. Do not redesign these per project. Default routes are
/login (customer) and /admin (staff, role-gated inside) unless the user names others.

Use p2hs/feature-packs.json to install a whole-workflow pack (check the manifest's
feature_packs.catalog first — do not duplicate a pack's own record schema or functions).
Use p2hs/functions.json only for a standalone library function not covered by any pack.
A catalog entry is not evidence that its providers are connected or ready.

## Row-level security

Set rls_enabled for private per-user records. Customer-facing BFF calls must forward
the signed-in app user's Authorization header to Cloud. Do not replace it with
CLOUD_SERVICE_TOKEN: that credential bypasses RLS. Never accept a caller's role or
owner ID as proof of authorization. Cloud scopes ordinary reads/writes to the user.

Privileged server tasks without a user session must enforce their own authorized scope.
Creating an RLS record with a service credential requires a top-level owner_user_id,
outside data. Do not invent a default owner or use a shared template/demo user.
Authentication and staff management use platform auth; business profiles may reference
its user IDs but must not duplicate passwords or serve as another login directory.

## Credentials and durable work

PROJECT_ID, CLOUD_GATEWAY_URL and CLOUD_SERVICE_TOKEN are injected by Core. The service
token and provider credentials remain server-only; never expose them through public
Nuxt/Vite configuration, client bundles, committed files, or browser responses.
Bookings use Cloud's reservation operation, payments use trusted server-side pricing,
and reminders/provider calls use Cloud jobs. Do not simulate durable work in the BFF.

## Existing-template migration

Inspect custom API routes, auth, persistence and UI callers together. Preserve visuals
and API semantics while replacing storage with Cloud calls and declaring schemas.
Do not migrate demo accounts into a customer's project. Run the backend guard and
framework build, then test cross-user RLS and missing-configuration behavior before
updating the starter branch. Instruction updates alone do not migrate custom code.
"""