The handbook says substantial features need Product Owner approval
before implementation, but not how a proposal gets there, what counts
as substantial, or what happens when no answer comes. Add the full
workflow: triage within 7 days, a decision brief, four product labels,
a lazy-consensus timeout that only applies to big-but-reversible work,
and definitions for every judgement call (small, big, reversible, new
direction, fits ROADMAP, objection, recorded decision).
The Feature Request form gets three optional fields for the brief, and
the PR template, CONTRIBUTING and triage point at the workflow.
Setup, configuration and deployment docs live in website/, which is
published as the docs site, but the map sent them to /docs and did not
list website/ at all. Add it, and drop the "when those paths are used"
hedge on /specs, which exists.
CODEOWNERS has no rules until #593 settles the per-area map; say so
instead of describing reviewers it does not list.
CONTRIBUTING.md still had a single maintainer curating main, which the
Release Maintainer section replaces. Name the Product Owner's GitHub
account and say where a community proposal starts, matching the
existing issue forms.
Adapt the agreed maintainer responsibilities and risk-based review policy for the public repository. Add evidence-driven security review, CodeQL triage, release guidance and a discoverable contributing link.
Léo