docs(corpus): add architecture-context template (#1328)

[serina-mcfall]

Node

corpus-template-architecture-context, at launchpad/docs/corpus/templates/architecture-context.md.

Issue type

Task

Note on DoD

Issue #1328's definition-of-done text ("states scope and authority/source of the
policy," "separates MUST requirements from SHOULD guidance," "defines
enforcement/checks and exception/escalation process," "links decisions or
higher-order policy instead of duplicating them") is byte-identical to issues #1309's
and #1312's — both standards-track (policy) tasks, not template tasks. This document is
built against parent Feature #605's real acceptance criterion for a template instead:
"every template states its purpose, required sections, evidence expectations and the
industry model/standard it adapts." The other DoD bullets (one hand-authored document,
schema-valid front matter, one independently maintainable idea, traceable claims, links
instead of duplication, checked against provenance, clean validation) are generic to any
corpus node and this document satisfies them the same way any node does. The document's
own "Note on this document's structure" section states this too, so a reviewer isn't
left wondering why there's no MUST/SHOULD split.

type chosen

type: governance. Checked node.schema.json, schema/README.md and
schema/COMPATIBILITY.md directly — the type enum is a closed list of 13 corpus
surfaces (architecture, layers, capabilities, ..., governance, agent, ingestion) with no
template or policy member, and COMPATIBILITY.md records no precedent for adding
one. Every existing corpus meta-document about how to author content rather than
being architecture/capability/etc. content itself uses governance (README.md,
standards/confidence.md, standards/decision-references.md) or agent (AGENTS.md,
which is literally an agent-facing procedure). governance is the closest true fit here
too, at confidence: 0.8 (an INFERENCE in the node's own ledger, not asserted as
settled). Important distinction stated explicitly in the document itself: this
template document is governance, but a real architecture-context node built
from this template should carry type: architecture instead — the template doesn't
inherit its own front-matter type into its instances.

Relationships

Checked, not assumed absent. Ran git ls-tree -r --name-only origin/launchpad -- launchpad/docs/corpus — at HEAD a44cf52fc740ebebbdd671427480d14f0bce0115 that tree
carries exactly four validated nodes: corpus-agents, corpus-readme,
corpus-standard-confidence, corpus-standard-decision-references. A references edge
to corpus-agents would validate today. Declared none anyway, for the same reason
standards/confidence.md and standards/decision-references.md already give for
themselves: the edge that matters most is to the sibling architecture-container
(#1327) and architecture-component (#1326) templates this document repeatedly points
at by issue number, and neither is merged — a relationships[].target naming an id
nothing carries is a hard validation error. Revisit once the first sibling template
merges. Per the batch brief, none of #1326/#1327/#1328/#1335/#1347 targets another
sibling, since none will be merged when review starts on the others.

Industry model + research note

Adapts the C4 model's System Context diagram (Simon Brown, c4model.com — fetched and
read directly this session) plus arc42 §3 "Context and Scope" (docs.arc42.org —
likewise fetched directly, since arc42.org/sections/03-context 404s). Both primary
sources were opened, not recalled, so they're cited as FACT. The unmerged research
note at launchpad/Research/project-documentation-templates.md
(launchpad-26/buzz#1466, not merged) frames C4 as "diagrams, not prose... slots into
arc42 §3/§5/§7" — cited as TEAM_KNOWLEDGE with provided_by naming the PR, never as
settled fact. That framing checked out against the primary sources themselves (neither
reaches into the other's territory), so no conflict to flag there.

One place I found the corpus's own constraints bite the research note's framing: the
corpus is Markdown-only today (non-.md files must live in generated/, and the
checker rejects them there too — no generator exists yet). A C4 diagram can't be a
separate image file right now, so the template requires an embedded Mermaid C4Context
fenced block instead (verified Mermaid supports this natively, though it's documented as
experimental) with a same-shape flowchart fallback if it doesn't render somewhere. Filed
no new issue for this — #1312 (open, "document corpus standard for diagrams") is the
right owner of any future canonical diagram mechanism, and the template says so.

Self-review caught one real defect before commit: an earlier draft attributed "GitHub
renders this wherever Mermaid is supported" to Mermaid's own docs, which never said
that. Fixed by fetching GitHub's actual diagram-rendering docs, adding a proper FACT
citation, and narrowing the claim to what's actually confirmed (GitHub renders Mermaid
fences generally; whether the experimental C4Context type specifically renders there
is undetermined and stays flagged in the node's own Scope and omissions).

Verify-gate and validator

python3 -m unittest discover -s launchpad/docs/corpus/schema/tests -p "test_*.py" -v
# Ran 27 tests in 0.034s — OK

Run as a lone, unpiped command each time immediately before committing (learned the hard
way mid-session: piping the output through tail to shorten it made the exit code
unattributable to the harness's stamp writer, so those runs silently didn't stamp —
re-ran unpiped and it stamped correctly both times). Real stamp, not touched.

python3 launchpad/project-intelligence/corpus/validate.py
# PASS  corpus validation found no errors; 14 item(s) reported unverified

All 14 UNVERIFIED notices are the expected non-fatal kind: one commit-reference
provenance citation, one git_ls_tree(...) tool-result citation, and the rest are
external (non-GitHub) URLs to the C4/arc42/Mermaid/GitHub-docs sources — exactly the
citation shapes AGENTS.md documents as unverifiable-but-legitimate. Zero errors.

Pipeline

Single-document task; skipped separate plan-issue/review-plan invocations as
overkill per the batch brief, but did think through the shape before drafting (research
first, then draft, then adversarial self-review). Cross-model review (Codex) is down
(#1467), so this is a same-model self-review pass only, not independent — noted rather
than silently substituted. The self-review pass is the one that caught the
GitHub-rendering misattribution above, which is exactly what it's for.

Escalations

None filed. Everything found during drafting either resolved directly (the type
question, the diagram-representation constraint) or is already owned by an existing,
tracked issue (#1312 for diagram mechanics, #1327/#1326 for the sibling templates this
document's boundary section depends on). No contradiction was found between this
document's context/container boundary and arc42's actual text, so no escalation there
either.

Closes #1328

[tucktuck101]

Review — architecture-context template (#1328)

C4 system-context fidelity is good and the required sections are the right ones. Three findings, one
of which is the sentence that locates the template in the model.

Medium — the hierarchy sentence maps three templates onto two C4 levels and contradicts itself

The Purpose section (:122-124) names a three-member triad then maps it onto two levels: "the
outermost of the architecture triad this batch defines (architecture-context ...;
architecture-container, issue #1327; architecture-component, issue #1326), mapped one-to-one onto
the outer two levels of the C4 model's own four-level hierarchy — system context and container —
with component and code going deeper still."

Three templates cannot map one-to-one onto two levels, and the same sentence both lists
architecture-component as a triad member and puts "component" in the excluded "deeper still" group.
c4model.com lists four hierarchical diagrams (system context, containers, components, code), so
the trio maps onto the outer three. Your own Boundary section correctly places
architecture-component at C4's component level, and both siblings say "outer three"
(architecture-container.md:363-366, architecture-component.md:174-177). This is the load-bearing
locating sentence, and it is both self-contradictory and wrong about C4.

Medium — the skeleton makes the grouping construct mandatory and the system element the fallback

Required section 2 mandates the system be drawn as "a single System_Boundary (or the top-level
system element if no internal boundary is drawn)", and the skeleton realises that as an empty
System_Boundary(sys, "<System>") { } with Rel endpoints pointing at the boundary alias.

c4model.com/diagrams/system-context names the primary element as "The software system in scope" (a
box), and Mermaid's C4 support provides System(alias, label, ?descr, ...) for exactly that,
listing System_Boundary separately among grouping constructs. The template inverts the two, so an
author copying the skeleton produces a diagram whose centre is an empty labelled boundary rather
than the system — contrary to the source cited. (Whether Mermaid renders a Rel whose endpoint is a
boundary alias is unverified; the node discloses that same gap. The C4 deviation is independent of
rendering.)

Low — the COMPATIBILITY.md rule is stated backwards

The FACT at :26 says "schema/COMPATIBILITY.md's rule governs adding a field, enum value or
narrowed type". The rule is the inverse. launchpad/docs/corpus/schema/COMPATIBILITY.md:6 declares
breaking "Any change ... that removes a field, removes an enum value, or narrows a type",
and :14-15 exempts additions explicitly: "Additive changes — a new optional field, a new enum
value, a new relationship type — are not breaking and do not require an entry here." "Adding a
narrowed type" is not something the document describes either. The statement's second half ("records
no prior addition or precedent of a template or policy type value") holds.

Not findings, ruled out on evidence

• Index registration: the corpus AGENTS.md and README.md both state that indexes are
  generated derived views, never hand-authored, and the ten-step "Creating a node" procedure has
  no registration step. All 26 template PRs leaving AGENTS.md untouched is correct.
• CI green at head (latest run per check); node validates clean.

Reviewed by tucktuck101's review lane. Every failing claim reported above was reproduced by me against this PR head before posting.