CP21 evidence

What whole-product dogfooding taught us

CP21 used a temporary incident-management client to exercise Trestle exclusively through its published HTTP interfaces. Its findings now inform Incident Desk, a separate supported example repository with a proper product surface and trust-boundary documentation.

Product paths exercised

  • First-run administration, application users, rotating sessions and collection access rules.
  • Typed collections, record writes, idempotency, querying and relation values.
  • Scoped service credentials and authenticated file upload and download.
  • Durable events, SSE replay, audit facts, jobs, webhooks and Lambda diagnostics.
  • Backup creation, download and restore preflight from a clean data directory.

Repairs and decisions

  • The false Project / Default selector was removed because one Trestle process currently owns one database.
  • Dashboard routes became refreshable, including direct collection routes.
  • Webhook configuration was separated from delivery-time DNS resolution without weakening SSRF checks.
  • Relation fields remain explicit record IDs until target-aware constraints and expansion are implemented.
  • Provider credentials remain operator configuration and were never bundled into the dogfood client.
Repository boundary

Future example applications should live in their own repositories and meet their own product, documentation and release quality bar. Trestle's core repository remains focused on the platform.

Explore Incident Desk