ADR Index

Chronological index of every architecture decision record, with status, one-line summary, and the supersession/refinement graph that ties them together.

This page is the flat, chronological list of every accepted ADR in the workspace. The 15 ADRs that have their own pages in this section are linked inline; the rest (tactical workspace policy ADRs that don’t get a full public treatment) are noted with a short one-liner and a pointer to the source file.

Status legend

StatusMeaning
AcceptedIn force. Operating decisions and code must comply.
SupersededAn older accepted ADR whose decision has been replaced by a newer accepted ADR. Body remains for historical context.
Refined byOlder ADR still in force, but a newer ADR amends a specific section of it.
ProposedDrafted but not yet accepted. Reviewers are still commenting.

ADR dependency graph

The graph below shows only the ADRs that constrain or supersede each other. Standalone VM-service ADRs (Redis, WSO2, Jenkins, SigNoz, monitoring, DefectDojo) are independent of each other and are not drawn — they all sit at the same level as “VM-hosted lab platform services.”

Read the graph as: solid black arrow = “this ADR depends on / constrains that ADR,” dashed green = “this ADR refines (amends a section of) that ADR,” solid amber = “this ADR supersedes that ADR.” The two amber-bordered nodes (ADR 0001 cluster-list portion, ADR 0003) are the parts of older ADRs that have been formally superseded.

Chronological list

2026-05-04 — Workspace foundations

  • ADR 0001 — Maintain a local operator workspace. Status: Accepted (cluster-list portion superseded by 0022). Establishes /home/ze/opp-full-plat as the operator’s local workspace with AGENTS.md, CLUSTERS.md, ASSESSMENT.md, RUNBOOK.md, TODO.md, lab-gitops-full/, secrets/. → Section page.
  • ADR 0002 — Subagent-first workflow. Status: Accepted. Tactical: when work spans multiple subsystems, multiple clusters, or more than two files, delegate to a subagent rather than execute serially in the main thread. Not a public section page; source: adr/0002-subagent-first-workflow.md.
  • ADR 0003 — GitOps basic pull model. Status: Superseded by 0018. Historical reference for the original hub-dc / spoke-dc pull model design. Not a public section page; source: adr/0003-gitops-basic-pull-model.md.

2026-05-05 — Hub design

  • ADR 0004 — Management hubs stay storage-light. Status: Accepted. Keep LVMS on hubs, remove ODF/NooBaa/OpenShift Pipelines/Tekton-Results/logging/tracing/MinIO/Loki/Tempo from hub desired state. ACM backup goes to external MinIO. → Section page.

2026-05-08 — Rebuild network plus standalone platform services

  • ADR 0005 — OpenShift rebuild network, ingress, PKI, IPv6 baseline. Status: Accepted; §IPv6 refined by 0026. 30.30.0.0/16 machine network, 30.30.75.0/24 reserved for OpenShift addressing, PowerDNS authoritative, no HAProxy in OpenShift ingress, offline OpenSSL CA day-zero, Vault PKI later, IPv4-only at install. → Section page.
  • ADR 0006 — Redis Sentinel hardening before application onboarding. Status: Accepted. Redis stays a VM service; six hardening gates (TLS, ACL/Vault, network, backups, observability, operational resilience) must close before BFSI apps treat Redis as production. → Section page.
  • ADR 0007 — Kafka KRaft production readiness. Status: Accepted. Parallel structure to Redis: Kafka KRaft VM cluster is lab-ready, not production-ready, until hardening gates close. Not a public section page; source: adr/0007-kafka-kraft-production-readiness.md.
  • ADR 0008 — WSO2 APIM and Identity standalone VMs. Status: Accepted. Reintroduce WSO2 IS 7.2.0.26 and APIM 4.7.0 as two standalone Ubuntu cloud-init VMs (wso2-is-0, wso2-apim-0), not on RKE2 or OpenShift. → Section page.
  • ADR 0009 — Jenkins single VM controller. Status: Accepted. One Ubuntu 24.04 VM (jenkins-0), OpenJDK 21, Jenkins LTS APT repo, HAProxy terminates TLS, Jenkins port 8080 reachable only from HAProxy. → Section page.
  • ADR 0010 — SigNoz standalone VM observability service. Status: Accepted. Self-hosted SigNoz v0.122.0 via Docker Compose on a standalone Ubuntu VM (signoz-0). OTLP ingestion stays private; only the UI is HAProxy-exposed. → Section page.
  • ADR 0011 — Trivy Ubuntu VM scanner service. Status: Accepted. Standalone Trivy scanner VM, supports DefectDojo (0013) and the federated build path (0015). Not a public section page; source: adr/0011-trivy-ubuntu-vm-scanner.md.
  • ADR 0012 — Monitoring observability learning VM. Status: Accepted. A second observability stack alongside SigNoz, built component-by-component (Grafana, Prometheus, Alertmanager, Loki, Tempo, Pyroscope, Grafana Alloy, Blackbox Exporter) for learning the primitives. → Section page.
  • ADR 0013 — DefectDojo VM security dashboard. Status: Accepted. DefectDojo 2.58.1 Docker Compose on a standalone Ubuntu VM (defectdojo-0), replacing a stale RKE2 backend. Imports Trivy results via API. → Section page.

2026-05-09 — Federated architecture and v6 management

  • ADR 0014 — Developer readiness platform contract. Status: Accepted. Defines the contract the platform must offer to application teams (golden paths, image promotion, evidence). Not a public section page; source: adr/0014-developer-readiness-platform-contract.md.
  • ADR 0015 — Federated GitOps repository architecture. Status: Accepted; constrained by 0018 on OpenShift platform ops. Splits ownership across openshift-platform-gitops, vm-platform-ops, division app monorepos, division GitOps repos; defines build-once-promote-by-digest model. → Section page.
  • ADR 0016 — Workspace execution governance. Status: Accepted. Every task that executes commands, edits files, or touches live systems must have an issue, milestone, phase/gate, and ADR before work begins; every completion gets a closeout in GitHub and the local session record. → Section page (filename retained for URL stability; content is workspace execution governance).
  • ADR 0017 — Parallel worktree isolation policy. Status: Accepted. Extends 0016. When more than one writer commits to the same repo in parallel, each writer gets a dedicated worktree, branch, ownership boundary, and tracking issue. → Section page.
  • ADR 0018 — ACM + OpenShift GitOps pull model for v6 management. Status: Accepted; supersedes 0003; constrains 0015. Hub coordinates ACM placement + ApplicationSet; each spoke runs its own Argo CD that pulls from internal GitLab. → Section page.
  • ADR 0019 — Nexus-only image supply chain for OpenShift. Status: Accepted. Three Nexus endpoints — mirror-registry.* (oc-mirror only), docker-group.* (build pulls), app-registry.* (CI pushes). Runtime allowlist, IDMS/ITMS in GitOps. → Section page (filename retained for URL stability; content is Nexus-only supply chain).

2026-05-10 — Compliance baseline and fleet purge

  • ADR 0020 — PCI-DSS profile compliance baseline for spoke-dc-v6. Status: Accepted. Compliance Operator v1.9.0, ocp4-pci-dss-4-0 + ocp4-pci-dss-node-4-0 as primary profiles, custom workers-storage ScanSetting, scan desired state in GitOps. → Section page.
  • ADR 0022 — v6 fleet membership. Status: Accepted; supersedes cluster-list portion of 0001. Active fleet is hub-dc-v6 + spoke-dc-v6 only; pre-v6 hub-dr / spoke-dr decommissioned; hub-dr-v6 / spoke-dr-v6 reserved names but not built. → Section page.
  • ADR 0023 — Federated GitLab group and repository ownership model. Status: Accepted. Implementation detail of 0015 on the GitLab side: two top-level group trees, eleven ct-* role groups, eight operational repos, code-owner-enforced protected branches, fixed review-approver table. → Section page.
  • ADR 0024 — OpenShift-only platform GitOps repo boundary. Status: Accepted. Locks openshift-platform-gitops to OpenShift cluster state only; VM platform tools, application source, and per-release manifests are explicitly out. Boundary enforced by GitLab group access, branch protection, CODEOWNERS, and validation-only CI. → Section page.
  • ADR 0025 — GitOps-only operations and break-glass policy. Status: Accepted. Normal OpenShift changes flow through GitOps; oc, console, SSH, direct API are break-glass under four named conditions, with five mandatory controls per action and a 24-hour backport clock. → Section page.

2026-05-11 — IPv6 reality

  • ADR 0026 — IPv6 baseline for OVN-Kubernetes. Status: Accepted; refines 0005 §IPv6. Host-kernel IPv6 disable breaks OVN-K; the 4 verifiable invariants are “IPv6 not used for cluster traffic” instead of “IPv6 not present on hosts.” The #135 incident on 2026-05-10 — both kernel-arg and sysctl drop-in mechanisms broke OVN-K — drove this revision. → Section page.

Supersession and refinement table

Newer ADROlder ADRRelationshipScope
00180003SupersedesWhole ADR (pull model for v6)
00220001SupersedesCluster-list portion only; rest of 0001 remains in force
00260005Refines§IPv6 only; rest of 0005 (30.30.0.0/16, PowerDNS, no HAProxy in OpenShift ingress, OpenSSL CA day-zero) remains in force

How to add a new ADR

  1. Pick the next monotonic number (ls opp-full-plat/adr/ | tail -1).
  2. Copy the template from this section’s overview page.
  3. Open the review issue in zeshaq/opp-full-plat. Title: adr: review NNNN <slug>.
  4. Set ## Status: Proposed. Push to a branch; link the file in the review issue.
  5. Address reviewer comments. When the issue closes “Accepted,” edit the file to ## Status: Accepted, append to the ADR Index issue (#131), and merge.
  6. Update opp-full-plat/CURRENT_STATE.md, SESSION_LOG.md, and any affected runbook/handbook.
  7. If the new ADR supersedes or refines an older one, append the supersession to the older ADR’s ## Status block and update this index page.

References

  • Every ADR file: opp-full-plat/adr/0001-*.md through 0026-*.md.
  • ADR Index issue: zeshaq/opp-full-plat#131.
  • Workspace governance rules: ADR 0016.
  • This section’s overview page: Overview: How ADRs Work.

Last reviewed: 2026-05-11