Integrate your business
The template provides authentication, basic account profiles, administration, commercial infrastructure and optional content. It has no required example business. Bookmark, Decision Log, organization collaboration and the tool dashboard have been retired from the current application.
Complete installation, then define one complete user task for your own product. Use an isolated local database while implementing and verifying it.
Establish ownership before adding a screen
| Responsibility | Where it belongs | Required decisions |
|---|---|---|
| Business entities and invariants | Your domain under src/server/ | Ownership, valid lifecycle transitions, input limits and concurrency rules |
| Public service contract | Domain-owned TypeScript contract | Queries, commands, safe results and failure/recovery semantics |
| Replaceable HTTP consumer | Domain-owned src/contracts/ protocol and generated client | Exact request/response schema, caller authority and error mapping |
| Persistence | Owned tables and reviewed migrations | Constraints, existing-data treatment and Cloudflare D1 support |
| Pages and Actions | Route-local src/app/ composition | Fresh identity, service calls and transport adaptation |
| UI | Route-local views or genuinely shared components | Drafts, pending/confirmed/rejected/unknown feedback and accessible controls |
| Product discovery | src/application/product/navigation/ | Only actual supported destinations, including login return and CTA paths |
A page or client supplies user input, never a trusted user ID, role or storage adapter. The service obtains current authority through Auth and checks each resource operation. Navigation visibility does not authorize a query or mutation.
Use the installed UI primitives and domain service boundaries. Keep database queries, payment interpretation and business transitions out of pages, table cells and forms. New frontend layouts should consume the same domain contract.
Commercial operations
Payments owns products, immutable offer revisions, checkout attempts and confirmed payment facts. A published catalog item is not itself a business capability. Bind an actual domain operation to an explicit entitlement policy and trusted commercial observations; the foundation contains no default paid example operation.
New sales are selected independently of existing purchases. /me/billing owns customer billing and original-attempt recovery. A checkout return URL cannot confirm payment, and uncertain payment or resource effects must not be replayed as a new command without the original domain recovery rules.
When retiring an old product, preserve recorded product and offer identity and resolve its existing billing obligations. Removing source code does not authorize deleting historical customer data or rewriting payment facts.
Product composition
src/config/product.ts declares public brand and capability selections. core disables new sales; personal-paid selects real checkout when provider and offer configuration is available. Docs, Blog, analytics and feedback attachments remain explicit selections. See configuration.
Basic account navigation contains Profile and Billing. Add a destination only when a supported user task and independently authorized route exist. Developer setup documentation remains in Docs; the customer account is not an onboarding tutorial or a collection of implementation examples.
Verify a complete task
Exercise successful creation or editing, a second account’s denied read/write, invalid input and a relevant conflict. If a command can have an unknown outcome, verify recovery without silently creating a second effect. Include direct route/API calls, keyboard operation and a narrow viewport. Use the repository’s named local-instance tooling for isolated application verification.
Test real public service consumers and the actual application. A fixture proves its bounded scenario; it does not prove provider delivery or deployed Worker behavior. Keep source checks, local application evidence and Cloudflare deployment evidence separate.