# Architecture Decision Records (ADR) Index > Audience: vendor implementation team and reviewers. > Goal: single index over the ADR set with status, scope, and Azure/handover relevance. > Source of truth: each numbered file in `docs/adr/`. This README is an index, not a decision. ADRs are immutable once accepted. If a decision needs to change, write a new ADR that supersedes the old one and update both `Status` lines. Do not edit historical decisions. There are two ADR-001 files for historical reasons (see notes below). All other numbers are unique. --- ## ADR list | Number | Title | Status | Affected area | Handover relevance | | -----: | -------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- | -------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- | | 001* | [Owner Portal Placement in Existing Next.js App](001-owner-portal-placement.md) | Accepted | Repo layout / routing | Vendor port keeps owner portal colocated with the tenant runtime; revisit only if isolation is required for compliance. | | 001* | [Platform Operations Domain Model](001-platform-operations-domain-model.md) | Accepted | Platform / control-plane domain | Same domain model carries forward; vendor maps it to Azure-side resources. | | 002 | [Control Plane Tables Colocated in Tenant Supabase Project](002-control-plane-colocation.md) | Accepted | Database / control plane | Vendor will need to decide whether to keep colocation or split control plane to its own DB on Azure. | | 003 | [V1 — Dedicated Supabase Project Per Tenant](003-v1-dedicated-environments.md) | Accepted (V1 only) | Multi-tenant architecture | Direct equivalent on Azure: dedicated DB / per-tenant schema. See ADR 012 for sensitive-tenant policy. | | 004 | [Four-Layer Feature Entitlement Model](004-entitlement-layered-model.md) | Accepted | Entitlement / RBAC | Strongest piece of the existing app — carries forward. Do **not** rebuild (see operator's "do not do now" list). | | 005 | [Provisioning Execution Model — `after()` as Interim Bridge](005-provisioning-execution-model.md) | Accepted (V1 interim) — supersede when durable queue is adopted | Tenant provisioning | Vendor decision: pick a durable queue (Service Bus / Vercel Queues / etc.) and supersede this ADR. | | 010 | [Product Core vs Customer-Specific Adapter Separation](010-product-core-vs-customer-adapter-separation.md) | Accepted | Repo architecture rails | Customer-coupling check (`scripts/check-forbidden-strings.mjs`) enforces this. Vendor must not introduce customer-specific behaviour into product-core paths. | | 011 | [Modular Monolith First](011-modular-monolith-first.md) | Accepted | Architecture | Carries forward. Premature service split is out of scope for the port. | | 012 | [Dedicated Database Default for Sensitive Tenants](012-dedicated-database-default-for-bmw-sensitive-tenants.md) | Accepted (policy locked; physical implementation in Phase 9) | Multi-tenant data plane | **Critical** — drives the per-tenant DB layout decision in Azure. | | 013 | [Composition Profiles and Customer Variants](013-composition-profiles-and-customer-variants.md) | Accepted (skeleton in Phase 0; full wiring in Phase 9) | Build-time configuration | `npm run check:profiles` enforces the skeleton today. | | 014 | [Shared Platform Services Strategy](014-shared-platform-services-strategy.md) | Accepted (interfaces defined in Phase 0/1; full implementation Phase 3) | Platform services | Defines the seams (logger, cache, secrets, etc.) the vendor will swap to Azure-native services. | | 015 | [Architecture Boundary Enforcement](015-architecture-boundary-enforcement.md) | Accepted (warn level in Phase 0; promoted to error in Phase 2) | ESLint boundaries / scripts | `npm run check:boundaries` enforces this. Treat any violation as a real failure. | | 016 | [Logging and Observability Facade Strategy](016-logging-and-observability-facade.md) | Accepted (facade in Phase 1; OTel integration in Phase 3; vendor exporters Phase 9) | Logging / observability | **Vendor target:** Application Insights via OTel exporter. Do not introduce Sentry as the production monitor. | | 017 | [Security Baseline and Scan Policy](017-security-baseline-and-scan-policy.md) | Accepted (CI scans live in Phase 1; PENTEST + IAST in Phase 5) | Security / CI | SBOM + Trivy + ZAP + license scans. Pre-handover SBOM evidence lives in `docs/foundation/`. | | 018 | [CSP Enforcement Strategy](018-csp-enforcement-strategy.md) | Accepted (report-only in Phase 1; enforced in Phase 2 after report review) | Frontend security | Vendor decision: when to flip from report-only to enforce in production Azure environment. | | 019 | [New Module Golden Path and Ownership Rules](019-new-module-golden-path.md) | Accepted | Repo conventions | New work in the vendor's hands should follow this golden path. | | 020 | [No Customer Exception Without ADR](020-no-customer-exception-without-adr.md) | Accepted | Governance | If the vendor needs a customer-specific exception, it must land as a new ADR — never as silent code drift. | | 021 | [State-Management Strategy](021-state-management-strategy.md) | Accepted | Frontend state architecture | Forward-looking 5-category rule (component / server-cache / form / application / URL). Existing code stays; next state is explicit. | | 022 | [Caching Strategy (Next.js 16 App Router)](022-caching-strategy.md) | Accepted | Server / client cache layers | Five data-classes (per-user dynamic, master, tenant config, static, external API) mapped to Next.js' four cache layers. Forward-looking. | | 023 | [Fabrikanalyse Seed Data Contains BMW-Specific Assessment Content](023-fabrikanalyse-seed-data.md) | Accepted | Seed data / ADR-020 exception | Documented, scoped exception to ADR-020 — assessment content only, no BMW-specific code paths. Revisit if a second customer is onboarded. | | 024 | [QAF→Value-Stream-Integration (QVS)](024-qaf-value-stream-integration.md) | Accepted (P7 status update 2026-07-18, PR #341 — see ADR status addendum) | New module (`lib/qaf-value-stream/`) / VSM data model | Feature-flagged (`qafValueStream`) additive bridge from QAF to Wertstrom — `true` in `default`+`bmw` since P7 (2026-07-18), `false` only in `_template`. Vendor can treat E1–E6 as the binding contract for any follow-on phase work. | `*` ADR-001 is duplicated by accident (one was authored before number reservation; both are kept for traceability). Future ADRs continue the sequence (next number: 025). --- ## Status legend | Status | Meaning | | ------------------------------------- | ------------------------------------------------------------------------------------------------ | | `Accepted` | Decision is in force. Code is expected to comply. | | `Accepted (... interim)` | Decision is temporarily in force. A successor ADR is expected. | | `Accepted (... Phase N)` | Decision is accepted in principle; concrete implementation is planned for the named phase. | | `Superseded by ADR-NNN` | No longer in force — replaced by a newer ADR. | | `Proposed` | Drafted but not yet accepted. | --- ## Authoring a new ADR 1. Pick the next free number (currently `021`). 2. Use the existing files as a template — `## Status`, `## Date`, `## Context`, `## Decision`, `## Consequences`. 3. Update the table above. 4. Reference the ADR from the relevant code paths or other ADRs. 5. ADRs are immutable once accepted — to change a decision, write a new ADR that supersedes the old one and update both files' `Status` lines.