Issue 11 Scaffold Wiki Fumadocs Routing

Initial Situation

Issue 11 reports reusable scaffold friction from a MultiplAI wiki deployment. The scaffolded wiki app existed, but nested monorepo docs were not automatically projected into Fumadocs routes. /docs could render while deeper domains, specs, requirements, reference docs, runbooks, and app-root Vercel builds depended on manual content copying and metadata repair.

Debt

The generated wiki seed did not include an explicit content projection step for existing monorepo source docs. A repo could have useful material under docs/, <wiki-root>/specs, or <wiki-root>/domains, but the deployable Fumadocs app only reads <wiki-root>/content/docs.

Bounded Fix

• Add a generated <wiki-root>/scripts/sync-content.mjs.
• Run that sync before generated wiki build and check-types.
• Project <wiki-root>/specs into /docs/project/specs.
• Project optional <wiki-root>/domains into /docs/harness.
• Project monorepo docs/requirements, docs/reference, docs/runbooks, and docs/tech-decisions.md into /docs/project/* when those sources exist.
• Generate or merge recursive meta.json files for copied folders.
• Leave checked-in content/docs usable when app-root deployment does not include monorepo docs/.

Non-Goals

• Full docs-ingest semantics or domain summarization.
• Replacing hand-authored routed wiki pages.
• Deleting stale generated projections.
• Product-specific MultiplAI wiki content.

Acceptance Checks

• Scaffold init tests prove the sync script is generated.
• Scaffolded package scripts run the sync before Fumadocs build/type generation.
• Operator docs describe the sync boundary and app-root Vercel fallback.