Skip to content
ramose.ai

Before production

Use this checklist before any real principal or durable data reaches a production Ramose stage.

Identity and edge

Section titled “Identity and edge”
  • Verify token issuer, audience, keys, expiry, clock tolerance, and callback origins for the production hostname.
  • Derive principals and the authorized database from trusted configuration; reject caller-supplied internal database or catalog ids.
  • Confirm unauthenticated /db/* and /mcp requests fail closed.
  • Use short-lived browser and MCP tokens and redact them from logs.
  • Restrict CORS and OAuth redirect targets to exact production origins.

Catalog and policy

Section titled “Catalog and policy”
  • Apply read policy and exact operation rules to every production schema.
  • Test owner, member, viewer, suspended, removed, and newly invited principals with real identity tokens.
  • Prove hidden facts cannot leak through joins, counts, relationship traversal, discovery, errors, or operation target checks.
  • Review every targetless creation grant and every generated CRUD operation explicitly.
  • Stage incompatible catalog evolution through additive releases and backfills.

Database lifecycle

Section titled “Database lifecycle”
  • Keep dashboard queries bounded; do not load every tenant or project row eagerly.
  • Test database archive, restore, export, and deletion.
  • Model cross-database work as recoverable workflows rather than transactions.

Browser and offline

Section titled “Browser and offline”
  • Test first activation, snapshot restore, resume, forced resnapshot, offline reload, and reconnect.
  • Test queued operations across browser restart and multiple tabs.
  • Test later server rejection after optimistic UI and preserve user-authored input where needed.
  • Switch principals without exposing the prior principal’s replica or receipts.
  • Keep ready or stale data visible during transient connectivity failures.

Query and capacity limits

Section titled “Query and capacity limits”
  • Measure representative query latency, candidate work, projection width, snapshot size, and incremental update cost.
  • Bound every page, nested collection, and recursive rule.
  • Set conservative browser, server, and MCP query budgets.
  • Load-test the expected number of simultaneously active queries, not only the number of stored entities.
  • Verify query_budget_exceeded provides safe, actionable recovery without internal plans.

MCP

Section titled “MCP”
  • Publish correct OAuth protected-resource metadata for POST /mcp.
  • Confirm tools/list contains exactly describe, query, and mutate.
  • Review catalog descriptions for agent clarity and sensitive details.
  • Test discovery pagination, stale catalog tokens, opaque cursors, operation retry, and invocation conflict.
  • Invoke through MCP and observe the ordinary web app converge.

Reliability and operations

Section titled “Reliability and operations”
  • Alert on health, storage faults, synchronization lag, resnapshot rate, query-budget failures, and rejected/internal operation outcomes.
  • Correlate requests and receipts with safe opaque identifiers.
  • Practice restore, export, stage rollback, and catalog rollback procedures using non-production data.
  • Document retention and deletion behavior for database data, history, snapshots, and receipts.
  • Confirm test hooks and instrumentation routes are inert in production.

Final launch test

Section titled “Final launch test”

Run the starter’s critical user journey from a clean browser, an existing offline replica, a second tab, a server-side Worker, and an MCP client. Use both a permitted and denied principal. The product should tell a consistent story in every surface because all of them share the same catalog, policy, queries, and operations.