Step 7 - Add curated docs

Goal: capture the knowledge no single unit owns - patterns, practices, architecture, conventions - as hand-written docs that pass the same gate as generated ones. Optional: do it when you have cross-cutting knowledge worth teaching, not as a checkbox.

Your job is to name what deserves canonicalizing; the agent scaffolds and authors it:

canonicalize our error-handling conventions as a curated doc
canonicalize docs/adr/ - the accepted ADRs - as architecture docs
document the multi-tenancy pattern, referent: packages/tenancy/src

What the agent runs

alloy new curated <category>/<slug>     # e.g. conventions/error-handling

The scaffold already validates: sections come from the manifest with one ⚠️ GAP placeholder each, and the frontmatter carries the governance fields (an owner plus a freshness mechanism) from birth. The agent replaces each placeholder with real content - leaving a GAP marker anywhere it cannot fill honestly - then:

alloy validate .alloy/corpus/shared/<category>/<slug>.md
alloy stamp .alloy/corpus/shared/<category>/<slug>.md

The one decision that is yours

Every curated doc gets its freshness one of two mutually exclusive ways - tell the agent which:

• --referent <source:path> (repeatable) - names the code the doc is about; a change to those files marks the prose drifted, mechanically. Prefer this wherever real code governs the doc.
• --review-after <YYYY-MM-DD> - a calendar review date, for pure practice or philosophy no source file governs. Defaults to today plus 180 days.

You have stood Alloy up end to end

Review the docs the agent authored - curated docs are your team's voice, so edit freely - then commit. Between the campaign and curated docs, your repo hosts a full corpus: units with provenance, cross-cutting knowledge governed, everything through one gate.

From here, wire it into your agents: Integrate with agents.