Control drift across web, mobile, pages, and database

Create an experience contract for [feature or workflow] that must stay aligned across marketing pages, the authenticated web application, native mobile applications, APIs, and the database.
Actors and workspace or account contexts: [roles and contexts]
Public page entry points: [URLs or components]
Web application entry points: [routes and components]
Mobile entry points: [screens and navigation]
Shared API endpoints and events: [contracts]
Current database tables, fields, constraints, and policies: [schema details]
Authorization rules: [who can see and do what]
Persistence and synchronization needs: [rules]
Release branches, environments, and owners: [details]

Start by separating shared product meaning from platform presentation. The contract must define the same actors, trigger, permissions, business rules, action meaning, state names, persistence, errors, counterpart visibility, audit evidence, and downstream result across platforms. Allow layouts, navigation patterns, controls, and native capabilities to differ when the user outcome remains equivalent.

Produce:
1. Goal, scope, exclusions, actors, entry points, prerequisites, and source-of-truth order.
2. A state machine showing valid states, transitions, initiating actor, authorized responder, failure states, retry behavior, and terminal outcomes.
3. A parity matrix with rows for behavior, labels, permissions, API fields, loading, empty, error, offline, accessibility, analytics, persistence, and counterpart visibility; columns for public page, web app, iOS, Android, API, and database.
4. A canonical data contract with field name, type, nullability, default, validation, owner, sensitivity, authorization, migration impact, backward compatibility, and deprecation plan.
5. Database safeguards: constraints, indexes, row-level authorization or equivalent enforcement, migration and rollback plan, seed or fixture impact, and read/write compatibility during staged releases.
6. Acceptance tests that close the complete initiating and receiving loop on every affected platform, including reload or reopen persistence and evidence captured.
7. Drift controls for CI: schema diff checks, generated client or type checks, API contract tests, shared fixtures, snapshot limits, platform checklists, and a contract version referenced by implementation work.
8. A release sequence that prevents an old client, new API, or partially migrated database from exposing unsafe behavior.

Do not force pixel-identical interfaces. Do not assume that matching field names proves matching behavior. Backend authorization must precede UI exposure. Database changes, production configuration, and deployment remain separately approved. Mark every unsupported fact [TO CONFIRM] and finish with unresolved decisions, owners, and concrete runtime evidence required for completion.

Response requirements:
- Begin with a short summary of the goal, confirmed facts, assumptions, and missing information.
- Ask focused clarification questions before completing the work when a missing answer would materially change the result.
- Use clear headings, tables, checklists, or numbered steps where they make the output easier to use.
- Keep source facts separate from recommendations. Quote or cite supplied evidence when the task depends on source material.
- Mark unsupported details, decisions, owners, dates, costs, credentials, and commitments as [TO CONFIRM].
- Identify the three most important risks, failure conditions, or quality checks.
- End with a practical next-action checklist that names the responsible role and the evidence needed to confirm completion.
- Include a final self-review: check the answer against this prompt, list any unmet requirement, and correct it before responding.
- Do not claim that you accessed a system, verified an external fact, completed an action, or tested the result unless evidence in this conversation proves it.

Version 1.0 · Updated 2026-10-10 · Free starter template. Evaluate the output in your approved environment.