These records explain the platform direction shared by more than one service. Service-specific and point-in-time decisions live beside the service they affect.
ADR-001: Keep independently deployed repositories
Status: Active
Decision: Keep each product in its own repository while deployments, runtimes, access, and release ownership remain independent.
Consequence: Shared documentation must be checked against every repository rather than assuming one release represents the whole platform.
ADR-002: Put an identity boundary in front of administration
Status: Active
Decision: Use Cloudflare Access as the first identity boundary for protected browser administration, then enforce product-specific authorization in the application.
Consequence: A route is not treated as private until its edge policy and application checks are both verified. API-key recovery paths remain narrow and service-specific.
ADR-003: Use verified, tokenized calendar feeds
Status: Active
Decision: Verify a calendar subscription request by email, issue a random feed token, and store its hash rather than the plaintext token.
Consequence: Calendar clients can fetch the feed without an interactive login, while operators retain token rotation and revocation controls.
ADR-004: Use one Markdown source for Obsidian and Quartz
Status: Active
Decision: Treat quartz/content as the canonical documentation vault. Edit the same Markdown in Obsidian and publish it through Quartz.
Consequence: Content stays in frontmatter, Markdown, wikilinks, callouts, tables, and Mermaid. Layout belongs in shared Quartz and Obsidian CSS, not page-specific HTML.
ADR-005: Replace the n8n Pub scheduler
Status: Superseded record
Recorded: January 12, 2026
Original decision: Document the three n8n scheduling workflows as one service.
Current state: The scheduler moved to the Pub Worker and D1 in May and June 2026. The shared service page now describes the Worker implementation; the original n8n workflow is historical.
ADR-006: Keep Pub docs shared and the product separate
Status: Active
Decision: Keep Pub technical documentation in this searchable vault while treating Pub code, planning, access, permissions, operators, and deployment as separate from Resident Council products.
Consequence: Cross-service maps may show Pub for discovery, but RC Console does not own Pub authorization or releases. Physical-equipment tutorials publish with the Pub product.
Documentation rules
- Current service code is authoritative for implementation details.
- Active pages state shipped behavior; dated design documents preserve intent and history.
- Contributing and maintaining defines the writing and visual standard.
- Naming conventions defines technical labels used in diagrams.