Trust starts with an honest boundary.

01 · Readiness at a glance

Three states, kept separate.

02 · Identity and authorization

Provider identity does not choose the application role.

• Clerk authenticates a user and active organization only when production keys are configured.
• An application session requires an active workspace and an exact database membership for that user.
• Database roles are authoritative: owner, admin, designer, operator, and viewer have distinct permissions.
• Provider organization roles are ignored for ordinary authorization; the first-owner provisioning path is a narrow exception.
• Studio routes and APIs are identity-protected by default; the exact signed Stripe webhook POST is the named billing exception.
• The local development bypass requires development mode, explicit flags, and a host that is loopback or ends in .localhost.

Team invitations, provider-to-database membership synchronization, role-change and removal automation, revocation, and audit events are not yet claimed as production-complete.

03 · Tenant data boundaries

The browser cannot nominate a workspace target.

Project and asset routes obtain the workspace identifier from the authenticated server session. The URL carries a project or asset identifier, but not an authoritative tenant target. The durable database design uses a non-bypass application role and installs workspace scope inside transactions before tenant queries.

The repository includes exact role and row-level policy guidance, but the real production database roles and migration state must be audited on the chosen Postgres service before launch.

04 · Request and file safety

Untrusted input meets a bounded boundary.

• State-changing browser routes require an authenticated role and an exact same-origin request.
• Save requests use strong version preconditions and idempotency keys; stale writes are rejected instead of silently overwriting a newer revision.
• Project archives are inspected for canonical paths, one project document, entry count, decompressed size, compression ratio, JSON complexity, schema support, and matching project identity.
• Cloud images are capped, stream-bounded, and accepted only when declared type and magic bytes agree for supported raster formats.
• Server-computed hashes are checked before stored project bundles or assets are returned.
• Missing durable database or private object storage configuration returns an unavailable response; production does not fall back to browser or in-memory persistence.

05 · Publishing safety

Unsupported work stops before promotion.

Go live binds a request to one immutable reviewed revision. Eligibility is computed from the authored components, their required modules, and relevant delivery swaps. A Naratake project is a full application with a database behind it; the cloud publish lane can currently ship only the parts that need no database, because the managed database service is not wired up yet. A project that needs one is rejected before any build, artifact, or provider change.

1. 01
   Freeze

   Bind the request to the exact revision and its server-verified project bundle.

2. 02
   Build away from production

   Create a bounded release artifact through the worker contract.

3. 03
   Verify

   Check the immutable result and release state before changing the stable pointer.

4. 04
   Promote or roll back

   Retain release history so a prior verified release can be selected.

Cloud publishing does not yet cover the modules that need a running database — orders, payments, reservations, appointments, customers, and the rest of the operational side. That is a limit of this delivery path today, not of what a Naratake project can contain. Custom domains are also not claimed on this page.

06 · Billing boundary

Billing is server-configured and fail-closed.

When configured, the browser chooses only an approved price alias. The server maps it to Stripe, creates canonical return URLs, and records a durable idempotency claim before the provider call. The exact Stripe webhook route reads a bounded raw body, verifies its signature and expected API version, and processes duplicate or out-of-order events through durable claims and cursors.

Provider customer, Checkout, and subscription identifiers use a dedicated narrow billing role; ordinary workspace database credentials must not access global billing claim tables. Raw payment-card input is handled on Stripe-hosted pages rather than Naratake forms.

07 · What is not claimed

No trust badge ahead of the evidence.

Production deployment must use HTTPS, but transport and storage protections ultimately depend on the selected providers and configuration. Naratake does not present that dependency as an independently certified encryption program.

08 · Customer responsibilities

Security is also a workspace practice.

• Protect the identity-provider account and use multi-factor authentication when the provider offers it.
• Assign the least-privileged application role and remove access when a person no longer needs the workspace.
• Do not paste credentials, private keys, customer secrets, or raw card data into page copy, project notes, support mail, or public assets.
• Review every release, link, form, policy, integration, and public business fact before promotion.
• Keep an independent copy of critical source content until production backup and restore operations are approved and tested.
• Report suspected account, workspace, or published-site compromise promptly.

See the Privacy Notice for data handling and the Service Terms for acceptable use and launch responsibility.

09 · Report an issue

Give us enough detail to reproduce safely.

Email a concise report with the affected Naratake URL or surface, impact, reproducible steps, and a safe proof of concept. Do not access another customer’s data, disrupt service, exfiltrate content, run denial-of-service tests, or include live credentials and sensitive personal information. There is currently no public bug-bounty program or response-time SLA.