Cinch
Sign inStart a workspace
Explore

Decision register

History stays visible when the system changes.

This is a curated public register: foundational decisions maintained by the marketing repository plus exact application claims approved for public use. Private and pending ADRs remain in their owning repository.

Last verifiedAugust 10, 2026
ScopeCinch application and public-marketing repositories
PostureCurated public engineering snapshot

Current index

Decision, consequence, proof, gap.

Operational identifiers, secrets, commands, and private evidence locations remain in their owning repository. The public record keeps enough specificity to make the tradeoff inspectable.

ADR-001Application delivery
AcceptedExercised

Interruption-resistant application releases

Use a health-gated blue/green strategy for routine stateless web releases while leaving the stateful synchronization service unchanged.

Decision

  • Maintain a two-instance serving floor for the stateless web tier.
  • Start and validate the complete replacement fleet before traffic promotion.
  • Promote an immutable source identity and retain the prior image plus recovery command.
  • Treat synchronization-runtime changes as a separate maintenance event.

Consequence

Deployments briefly use additional compute, database changes must remain backward compatible, and the stateful synchronization tier keeps a separately disclosed availability limit.

Evidence

  • Configuration policy
  • Candidate readiness checks
  • Two exercised production promotions
  • Post-cutover public journeys
  • Immutable-image recovery record
Implemented or referenced byMarketing 14 · Public engineering dossierApplication 2026.08.10 · Health-gated blue/green application delivery
Known limit

Active authenticated-session and WebSocket continuity through promotion remains an explicit evidence gap. The public claim is interruption-resistant—not a universal zero-interruption guarantee.

ADR-002Product and platform
Publication pendingValidated

Tenant-aware browser push notifications

The accepted record defines tenant ownership, private subscription storage, transactional fan-out, delivery-time authorization, privacy-preserving previews, and bounded retry behavior.

Decision

  • Require explicit per-browser opt-in and separate preview consent.
  • Keep subscription capabilities outside client synchronization and structured logs.
  • Recheck membership, attention, access, deletion, and read state before delivery.
  • Make retries durable, per-device, bounded, and safe under concurrent workers.

Consequence

Notification delivery can be intentionally absent when access, attention, read state, visibility, or subscription validity changes. Telemetry must distinguish those outcomes without recording message content.

Evidence

  • Tenant-policy tests
  • Transactional fan-out tests
  • Worker authorization and retry tests
  • Route and service-worker tests
Implemented or referenced byMarketing 14 · Public engineering dossier
Known limit

A disposable-browser production exercise is still required. This index records the decision without presenting browser push as a generally available feature.

MKT-001Public boundary
ImplementedExercised

Separate public marketing from the authenticated runtime

Give the public site its own source, dependencies, hosting identity, release history, and narrowly scoped feature-board datastore.

Decision

  • Do not import product runtime packages or receive product secrets.
  • Keep public feature requests separate from tenant and authentication data.
  • Enter the product only through the account host; do not proxy authentication.
  • Release and roll back marketing independently from the application.

Consequence

Cross-host journeys become explicit, but a public-content release cannot rebuild tenant workloads or receive authority over authenticated data.

Evidence

  • Repository-boundary tests
  • Cookie-free edge policy
  • Independent Sites release history
  • Dedicated public feature-board binding
Implemented or referenced byMarketing 14 · Public engineering dossierMarketing 13 · Shared Cinch brand package
Known limit

This is maintained as a marketing-boundary decision rather than an application ADR; it is included here so the public index covers consequential decisions across both repositories.

ADR-067Validated

Channel-scoped external guest invitations

Cinch can invite an external guest directly into one selected public or private channel while preserving single-use credentials, tenant-bound authorization, and channel-exact access.

Known scope and limits

New guest invitations require one active named channel; redemption rechecks and grants only that membership. A composite tenant foreign key, RLS, safe pending metadata, recipient binding, legacy-link fallback, and existing guest permissions preserve the boundary. Focused tests, both type checks, lint, schema drift, build, and the 238-file/1,887-test suite pass. CI, release, and production exercise remain pending; the approved wording is bounded to validated capability.

ADR-001Exercised in production

Health-gated blue/green application releases

Application releases use a blue/green strategy. The complete replacement web fleet and fresh SBOM-backed image policy must pass before traffic is promoted, the prior image is retained as rollback evidence, and routine application releases leave the real-time sync service unchanged.

Known scope and limits

Releases on 2026-08-10 exercised healthy replacement Machines, immutable identity, public checks, the private Zero hop, and unchanged Zero. On 2026-08-11 refreshed vulnerability data blocked two candidates without an exception or promotion. Later, evidence-backed OpenSSL dispositions yielded zero blocked findings; source 70e27f0ffa484fc0964f0672fc08a567d058adb0 passed the same gate, promoted two healthy Machines, passed all twelve public checks, and left Zero unchanged. Active-session continuity remains an evidence gap, so zero-interruption wording is not approved.

Decision threshold

Not every code change deserves an ADR.

A record is expected when work changes a trust or system boundary, introduces durable infrastructure, changes data or security posture, constrains future delivery, or is expensive to reverse.

  1. 01Context

    Name the pressure, constraints, and why a durable choice is needed.

  2. 02Options

    Include plausible alternatives and the option to defer.

  3. 03Decision

    State scope, ownership, authority, and the chosen boundary.

  4. 04Consequences

    Record costs, risks, reversibility, and follow-on work.

  5. 05Evidence

    Link tests, exercises, observations, and unresolved gaps.

Next chapter

Place each decision inside the working topology.

Infrastructure