Blog ADRs — Overview

Architecture Decision Records for the public-facing blog at blog.comptech-lab.com — captures the load-bearing decisions made while building the Astro + ReactFlow + multi-collection site.

This sub-section captures Architecture Decision Records (ADRs) for the public blog at blog.comptech-lab.com. The blog is intentionally a separate concern from the comptech platform documented in the rest of /docs/, but the ADR discipline applies the same way: each load-bearing decision gets a short, dated record explaining the context, the decision, and the consequences — including the alternatives considered and rejected.

The blog ADRs are numbered independently (0001 onward) from the platform ADRs, and they live in a sub-folder to keep audiences separate. If you’re here for OpenShift platform decisions, see the parent 06-architecture-decisions/ section.

What’s in here

ADRTitleStatus
0001Multi-collection content modelAccepted
0002ReactFlow over Mermaid for all diagramsAccepted
0003Category-based sidebar with frontmatter metadataAccepted
0004Learning section as parallel collection to docsAccepted
0005SEO baseline (sitemap, RSS, OG, JSON-LD)Accepted
0006Brac POC as a top-level content collectionSuperseded by 0007
0007/docs/ as a master section with per-module sub-treesAccepted

Format

Each ADR follows the standard template:

  • Status — Proposed / Accepted / Superseded, with date and (if superseded) a pointer to the replacement.
  • Context — what triggered the decision; what alternatives were on the table.
  • Decision — the actual choice made.
  • Consequences — what changed in the codebase, in the operating model, in future-flexibility.
  • Related — cross-links to other ADRs, blog posts, or code locations.

ADRs are not implementation guides. They’re the explanation for why the code is the way it is, written close enough in time to the decision that the rationale isn’t lost.

Last reviewed: 2026-05-10