ADR Status Matrix

This matrix is a practical reading of the ADRs across kilolockoss and kilolockcloud.

How to read this

Accepted in an ADR means "chosen direction", not "fully finished".
Proposed means "still open or still intentionally directional".
Many early ADRs are duplicated in both repos and are already reflected in the
code, even when later follow-up work is still incomplete.

Evaluation labels used here:

Implemented means the codebase materially matches the ADR already.
Largely implemented means the architecture is in place, with follow-up work
still open.
In progress means meaningful implementation exists, but the ADR still reads
like active design work.
Still proposed means the repo does not yet justify treating it as accepted.

Shared / Core ADRs

These ADRs exist in both kilolockoss/docs/adr and kilolockcloud/docs/adr. They are evaluated once here because the intent is shared.

ADR	Doc status	Implementation evidence	Evaluation
0001 Foundations	Accepted	Apache 2.0 license, Go codebase, PostgreSQL store, separate CLI/server binaries all exist in practice.	Implemented
0002 v0 scope - Queryable state	Accepted	Query/import/export flows and normalized state model are already present in `pkg/store`, `cmd/kl`, and backend APIs.	Implemented
0003 Governance and monetization	Accepted	License, CLA, trademark, maintainers, and OSS/commercial framing are already reflected in repo files and product split.	Largely implemented
0004 Resource lifecycles	Accepted	Lifecycle schema and history-oriented storage are implemented in migrations and store code such as `resource_history.go`.	Implemented
0005 v1 scope - Provider-aware refresh	Accepted	Refresh architecture exists in `internal/refresh`, provider launch code, and `kl refresh`.	Implemented
0006 Refresh implementation	Accepted	Orchestrator/factory/CLI structure is already the actual implementation shape.	Implemented
0007 Parallel apply on shared state	Proposed	Reservations, apply orchestration, wait/release logic, and state-engine locks exist, but the full "parallel apply on shared state" story is still maturing.	In progress
0013 Environment isolation	Accepted (E1-E2 implemented)	Tenants, environments, routing, quotas, and dedicated-environment support exist, but the ADR itself already admits staged implementation.	Largely implemented
0014 File-scoped fast plan/apply	Proposed	`--file` planning/apply support and scope analysis exist in `cmd/kl`, `internal/plan`, and `internal/configscope`.	In progress
0015 Control-plane separation	Accepted (partially implemented)	The split between core backend and customer-facing services is already visible in the repo layout and cloud runtime binaries.	Largely implemented
0016 Operator RBAC and delegation	Accepted (partially implemented)	Scoped roles, control tokens, RBAC checks, and admin scope enforcement exist in `pkg/store/rbac.go`, `control_operators.go`, and control server routes.	Largely implemented
0017 State-first targeted plan/apply	Proposed	Target-aware planning/apply support exists, but the stronger state-first semantics still look partial rather than fully settled.	In progress
0021 Large state payloads and object storage	Proposed	I do not see evidence of a completed offload architecture replacing the current Postgres-first historical model.	Still proposed
0022 Bootstrap credentials vs data encryption keys	Proposed	Cloud deployment already treats bootstrap secrets, Secret Manager, and KMS as separate concerns, but the repo-wide decision still reads partly operational rather than fully codified.	Partially implemented
0023 Human PATs, environment grants, and automation tokens	Accepted (partially implemented)	Personal access tokens, PAT grants, environment-scoped auth, and portal/control auth flows are implemented across store, portal, and cloud services.	Largely implemented
0024 Unified apply builds a spec	Accepted	`kl apply` and planning logic already revolve around a plan spec model.	Implemented
0025 Queryable state API and resource-level repair	Accepted	Query APIs, history inspection, and resource rollback are implemented in backend/store/CLI.	Implemented
0026 Resource-row-authoritative repair	Proposed	Repair capabilities exist, but I do not see clear evidence that the stronger "resource rows authoritative, raw state regenerated" model is the settled implementation.	Still proposed
0027 Split client CLI from server/runtime binary	Accepted	`kl`, `kld`, `klc`, and `klp` confirm the split is real and already adopted.	Implemented

OSS-only ADRs

These currently exist only under kilolockoss/docs/adr.

ADR	Doc status	Implementation evidence	Evaluation
0028 Backend-enriched graph assisted slice planning	Proposed	State-engine scope expansion, config intent discovery, and scope contracts already exist in `internal/backend/state_engine.go` and `internal/configscope`.	In progress
0029 State-engine protocol for sliced state and resource locking	Proposed	There is real state-engine surface area already, including scope expansion, reservation endpoints, and state-engine metadata.	In progress
0030 Testing boundaries and coverage reporting	Proposed	This is mainly a policy/process ADR. The repo has broad tests and coverage artifacts, but the decision is still more guidance than frozen architecture.	Reasonable to keep proposed
0031 Native state archive export and import	Accepted (initial implementation landed)	Native export/import endpoints, CLI support, and archive integration tests already exist.	Largely implemented
0032 State branch access policies	Proposed	Current auth is tenant/environment scoped. Fine-grained branch/resource policy is not yet present.	Still proposed

Cloud-only ADRs

These currently exist only under kilolockcloud/docs/adr.

ADR	Doc status	Implementation evidence	Evaluation
0018 Self-serve signup, Google OIDC login, and billing entitlements	Accepted (partially implemented)	Signup, Google OIDC, billing checkout, and Stripe webhook flows already exist in `klc` / `klp` and portal UI.	Largely implemented
0019 Cloud-first managed operations	Accepted	GCP deployment, Secret Manager, bootstrap job, Stripe integration, and managed-ops posture are all reflected in deploy docs and code.	Largely implemented
0020 Customer portal service boundary	Accepted (partially implemented)	`klp` exists as a separate service boundary from `klc`, with portal API/UI flow already split.	Largely implemented
0028 GCP deployment, bootstrap, and ingress model	Accepted (implementation in progress)	`deploy/gcp` already contains the three-service Cloud Run model, load balancer outputs, bootstrap job, Secret Manager, and operations bucket wiring.	Largely implemented
0029 Multi-provider SSO for customer portal	Proposed	Current implementation is Google OIDC plus `trusted_header`, not a generic multi-provider OIDC layer.	Still proposed

Suggested status cleanup

If the team wants the ADR set to read more cleanly, these are the ones I would update first:

Keep 0026, 0032, and Cloud 0029 as genuinely proposed until the code
clearly matches the stronger design claims.
Leave 0007, 0014, 0017, 0028, and 0029 as in-progress proposals
unless the team wants an intermediate status like Active.