Make root www/ the canonical, safe site-operations template and propagate it estate-wide #53

Outcome

Replace the template's duplicated root-level .well-known/ arrangement with a canonical root-level www/ site-operations bundle, then propagate the resulting template shape to estate repositories through the normal RSR update mechanism.

The bundle should give projects a safe, expert starting hand for public web metadata, site policy, authoritative DNS, encrypted-DNS/privacy discovery, TLS, security headers, web-server integration, validation and operational runbooks. Everything beyond the baseline remains explicitly opt-in: minting a repository must not start BIND, publish experimental declarations, or enable HTTP 430 enforcement.

Current evidence

At origin/main on 2026-08-31 the template tracks three files only at the
repository root:

• .well-known/{ai.txt,humans.txt,security.txt}

An existing local development branch also contains byte-identical copies under
www/.well-known/, but those copies are not on origin/main and are not treated
as more canonical than the tracked root files. The documentation names root
.well-known/ as canonical, while the Trustfile already asserts that website
directories such as www/ contain .well-known/, security_headers/ and
resource_records/. origin/main has no www/ tree, so the declared site
arrangement is incomplete.

Proposed canonical layout

www/
├── README.adoc
├── .well-known/          # explicitly public protocol metadata
│   ├── security.txt
│   ├── humans.txt
│   ├── ai.txt
│   └── aibdp.json        # experimental template; not enabled as enforcement
├── public/               # ordinary publishable HTML/assets
├── policies/             # human-readable privacy/AI-use/acceptable-use pages
├── errors/               # static 4xx/5xx bodies
├── security_headers/     # CSP/HSTS/etc. source templates; not served
├── webservers/           # Caddy/nginx/Apache integration examples
├── dns/
│   ├── bind9/            # authoritative-only safe starting hand
│   ├── records/          # zone/resource-record templates
│   └── privacy/          # DoT/DoQ/DoH/ODoH/ECH discovery guidance
├── tls/                  # policy/rotation guidance; never private keys
├── profiles/             # explicit opt-in composition
├── schemas/              # validators for public/generated artefacts
├── tests/                # local probes plus planted controls
└── runbooks/             # deploy/rollback/rotation/incident procedures

Publication boundary — security-critical

www/ is a site-operations source bundle, not a directory that may safely be served wholesale.

A supported deployment must:

1. serve www/public/ as ordinary content;
2. explicitly expose www/.well-known/ at /.well-known/;
3. keep dns/, tls/, security_headers/, webservers/, profiles/, schemas/, tests/ and runbooks/ outside the public document surface;
4. fail validation if a generated deployment would publish operational configuration.

Do not store private keys, issued certificate secrets, TSIG secrets, live zone journals, caches, PID files, logs or runtime databases in the template. Examples use reserved names such as example.invalid and placeholders, never live credentials.

Initial opt-in profiles

• baseline-site: security headers, security.txt, humans.txt, ai.txt, safe errors and validation.
• consent-aware-web: AIBDP 0.2 declaration plus human policy page, observe/declaration-only by default. HTTP 430 remains experimental and requires a separate explicit enforcement choice.
• authoritative-dns: BIND 9 authoritative configuration, zone/resource-record templates, DNSSEC/CAA guidance and checks. No open recursion and no automatically started daemon.
• privacy-enhanced: ECH and encrypted-DNS discovery/configuration where actually supported; direct DoT/DoQ/DoH and oblivious ODoH remain correctly distinguished.
• full-expert: composes the above through explicit selections; it must not introduce hidden enablement.

Consent-Aware Web constraints

Use metadatastician/consent-aware-web as the source proposal, while preserving its status:

• local draft-jewell-aibdp-00 and draft-jewell-http-430-consent-required-00 are experimental and not Datatracker submissions;
• AIBDP is a mapped alternative representation of AIPREF where they overlap;
• purpose headers are unverified assertions and User-Agent inference is heuristic;
• unknown purpose remains unknown;
• installing or minting the template does not emit 430;
• a future enforcement profile must be versioned, explicit, provenance-bearing and independently testable.

DNS/BIND constraints

• Provide an authoritative-server example first; recursive/stub resolver roles are separate profiles.
• Default to no recursion, minimal exposure and reserved example zones.
• Separate authoritative, recursive/stub, ODoH relay and ODoH target roles in documentation and configuration.
• Do not claim ODoT/ODoQ; use standard ODoH/OHTTP with HTTP/3 where appropriate and keep direct DoQ/DoT modes non-oblivious.
• Include DNSSEC and CAA examples without generating or committing operational keys.
• Document ECH/DoH/DoQ/ODoH capability detection rather than promising universal support.

Migration and estate propagation

1. Make www/.well-known/ canonical in the template.
2. Remove the duplicated root .well-known/ files from the template after updating all live references, allow-lists, checks and documentation.
3. Add a migration that compares both locations before moving anything. If a downstream repository has divergent or unpushed content, report a conflict and preserve both; never overwrite on path name alone.
4. Update the RSR propagation mechanism so existing repositories receive the new layout according to their website capability/profile.
5. Repositories without a website may retain the scaffold as inactive template material or explicitly decline the capability; they must not be forced to deploy it.
6. State the propagation horizon and reconcile counts with an enumerated repository list; do not infer estate-wide completion from a capped search.

Acceptance criteria

• www/ contains the documented categories and useful safe templates, not placeholder-only claims.
• Root .well-known/ is absent and every live reference uses www/.well-known/ or the deployed URL /.well-known/ as appropriate.
• A validator proves only www/public/ and www/.well-known/ are publishable.
• BIND example passes syntax validation and a planted open-recursion control is rejected.
• .well-known examples pass their applicable validators; experimental files are labelled as such.
• Consent-aware profile defaults to declaration/observe-only and cannot silently enable 430.
• Profiles compose explicitly and can be enabled/disabled independently.
• No secret, key, journal, cache, log or runtime-state path is tracked.
• Migration handles identical, missing and divergent root/www copies without data loss.
• Template mint/smoke tests prove the generated layout and publication boundary.
• Estate propagation reports an enumerated denominator, successes, opt-outs and conflicts.

Delivery split

This should land in reviewable stages:

1. canonical layout + documentation + root .well-known migration;
2. baseline website/security templates and publication-boundary validator;
3. authoritative BIND/resource-record profile and tests;
4. Consent-Aware Web and privacy-enhanced experimental profiles;
5. downstream RSR propagation with conflict-safe reporting.

The issue tracks the complete estate outcome; individual PRs should distinguish scaffolded, configured, validated, wired and deployed rather than collapsing those states.