Here is Claude's plan:
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
 Plan: Standards Framework — Scalable Governance Architecture

Context

Standards are currently scattered: validation-standards.adoc in
patterns/operations, project-structure.adoc in patterns/documentation, normative
 rules embedded in CLAUDE.md files. The Pattern Journal is explicitly a "field
notebook" (descriptive, dated, experiential) — standards are fundamentally
different (prescriptive, undated, enforceable). They need their own first-class
section.

The user's vision: become a documentation and standardization expert across all
facets of work. The framework must scale infinitely (add domains without
restructuring) and be AI-agent-ready (machine-parseable, single lookup point).

Core distinction

┌─────────────┬───────────────────┬─────────────────────┬───────────────────┐
│             │     Standard      │       Pattern       │       Codex       │
├─────────────┼───────────────────┼─────────────────────┼───────────────────┤
│ Voice       │ Prescriptive      │ Descriptive ("when  │ Referential       │
│             │ ("MUST")          │ I hit X...")        │ ("syntax is...")  │
├─────────────┼───────────────────┼─────────────────────┼───────────────────┤
│ Temporality │ Undated — current │ Dated entries with  │ Rarely changes    │
│             │  truth            │ context             │                   │
├─────────────┼───────────────────┼─────────────────────┼───────────────────┤
│ Scope       │ Cross-domain,     │ Single domain,      │ Single tool,      │
│             │ enforceable       │ experiential        │ lookup            │
├─────────────┼───────────────────┼─────────────────────┼───────────────────┤
│ Audience    │ Humans AND AI     │ Humans reviewing    │ Humans needing    │
│             │ agents            │ experience          │ syntax            │
└─────────────┴───────────────────┴─────────────────────┴───────────────────┘

Architecture

Nav placement: 2nd top-level section (after Strategic Objectives)

Strategic Objectives  →  WHERE we're going
Standards             →  HOW we enforce quality (governance layer)
Training Sessions     →  HOW we build skill
Pattern Journal       →  WHAT we've learned (descriptive)

Directory structure

pages/standards/
├── index.adoc              # Framework — what is a standard, lifecycle, how to
write one
├── registry.adoc           # Master registry of ALL standards (including
scattered ones)
├── operations/             # Change control, validation, deployment gates
├── documentation/          # Project structure, file naming, AsciiDoc
conventions
├── security/               # Secrets handling, hardening
├── ai-interaction/         # Agent behavioral rules, delegation boundary
├── infrastructure/         # Deployment checklists
└── workflow/               # CLI quality, verify-before-after

Scaling rule: Add new domain directories as needed. No restructuring required.
Each domain gets an index.adoc only when it has ≥1 standard.

Standard document attributes (machine-parseable)

Every standard includes:
:std-id: STD-NNN
:std-status: Draft | Active | Superseded | Retired
:std-domain: operations | documentation | security | ai-interaction | ...
:std-owner: {author}

AI agents grep :std-status: Active to enumerate enforceable standards. CLAUDE.md
 references standards by STD-NNN ID, not file path.

Registry as bridge

The registry page (standards/registry.adoc) cross-references ALL standards
regardless of current location. This solves the scattered problem immediately —
no migration needed upfront.

| STD-001 | Project Structure    | patterns/documentation/ (pending migration) |
 Active |
| STD-002 | Validation Standards | patterns/operations/ (pending migration)    |
 Active |

Migration path (non-disruptive)

You already have ~15 standards — they're just not called that

The normative content is scattered across three layers:

Layer 1: CLAUDE.md files (behavioral enforcement)
- File naming conventions (13 prefixes)
- AsciiDoc conventions (no :toc:, attributes over literals, build check)
- Secrets handling (never print values, redact with <REDACTED>)
- Delegation boundary (document-only default, explicit grant)
- CLI quality (verify-before-after, idempotent commands)

Layer 2: Pattern Journal (normative disguised as patterns)
- project-structure.adoc — "Every new project MUST follow this standard"
- validation-standards.adoc — 40+ checks across 8 domains
- change-management.adoc — "Verify-change-verify is non-negotiable"
- systemd.adoc — "encrypt hook MUST come before btrfs and filesystems"
- luks-btrfs.adoc — "Always format mapper devices, never raw partitions"
- eap-tls.adoc — "Certificate CN and nmcli identity MUST match"
- pki-certificates.adoc — "Each machine MUST have its own keypair"
- vault-operations.adoc — "Always use -format=json and tee"
- stow-dotfiles.adoc — "ssh:// URL format with :443 is required"

Layer 3: Infrastructure patterns with embedded rules
- VLAN troubleshooting — "Services need explicit firewall rules per VLAN"
- Hooks — "PreToolUse fires before execution, always exit 0"
- Agent orchestration — "Never apply without reviewing the plan first"

On the partials question

You asked if standards should follow the partial+page pattern. Your own STD-001
says "partials hold content, pages are shells" — but that was written for
projects. Here's the trade-off:

Partial+page gives you composability. A standard partial can be include::'d into
 multiple contexts — the standards section, a project's verification phase, a
runbook. That's the "AI ready" argument: standards become building blocks, not
monoliths.

Standalone pages are simpler. One file per standard, no shell/partial split to
maintain. Every pattern journal page is standalone today.

Given your vision — scalable, composable, AI-agent-ready — the partial pattern
is the stronger choice. It follows your own architectural principle and it means
 a project's Phase 11 page could include:: the validation standard directly
rather than duplicating or cross-referencing it.

The structure would be:

partials/standards/
├── operations/
│   ├── validation.adoc          # Content lives here
│   └── change-control.adoc
├── documentation/
│   ├── project-structure.adoc
│   ├── file-naming.adoc
│   └── asciidoc-conventions.adoc
├── security/
│   └── secrets-handling.adoc
└── ai-interaction/
    └── delegation-boundary.adoc

pages/standards/
├── index.adoc                   # Framework (standalone — not a shell)
├── registry.adoc                # Registry (standalone)
├── operations/
│   ├── index.adoc               # Domain overview (standalone)
│   ├── validation.adoc          # Shell →
include::partial$standards/operations/validation.adoc[]
│   └── change-control.adoc      # Shell
├── documentation/
│   ├── index.adoc
│   ├── project-structure.adoc   # Shell
│   └── ...

Do you want me to restructure to the partial+page pattern now and start
migrating the existing scattered standards into the framework? That's a
significant batch of work — probably 10-15 partials to extract and write. Or do
you want to start with the framework as-is and migrate incrementally as each
standard gets touched?

Context

The structural audit of domus-captures found 2,954 .adoc files across 20
top-level page directories, 68 projects, 8 nav partials, and a 500+ file
examples library. STD-009 has the abstract and skeleton but is missing critical
structural details that would let someone replicate the system. Additionally, 5
content areas have normative conventions but no formal standards, creating
deviation risk.

Part 1: Enhance STD-009 with verified structural metrics

What's missing from STD-009