Spec: App-Surfaced Wiki Root Selection

User Input

address @github issue 44 with $delivery-phase . full parallel mode. perform ALL steps throoughyl, follow closely all nested skills of all routes

Issue #44 summary:

dp scaffold init seeded a root wiki/ path based on generic single-repo guidance. In this repo, final project policy moved the generated wiki app to app/wiki and removed stale root wiki/ and apps/wiki paths, making the initial root wiki output stale for app-surfaced single repos.

Issue #44 expected behavior:

When scaffolding a repo that is not a true monorepo but is organized with app surfaces under app/, the init/setup flow should either ask for the wiki root or clearly guide reconciliation so the generated wiki lands at the project-canonical surface, e.g. app/wiki, before durable specs/plans/docs are authored.

Context

dp scaffold init currently has a two-shape wiki root model: monorepo-shaped targets seed apps/wiki, and single-repo targets seed wiki. Issue #44 came from a third repository shape: a non-workspace repository organized around app surfaces under app/, where the canonical wiki application belongs at app/wiki.

Harness operators and generated agents need the initial wiki root to match the repository's app boundary before docs onboarding, requirements grill artifacts, specs, plans, and routed project docs are authored. A stale root wiki/ causes immediate reconciliation work and can scatter durable planning artifacts into a path the project later removes.

Non-Goals

• Treating every repository with an app/ directory as a monorepo.
• Renaming the existing apps/wiki monorepo convention.
• Removing support for standalone wiki/ roots.
• Changing backlog provider, wiki framework, or docs-onboarding semantics.
• Rewriting scaffold setup pack detection beyond what is needed to keep wiki-root guidance coherent.

Acceptance Criteria

• dp scaffold init no longer silently seeds root wiki/ for a non-workspace repository whose project-canonical wiki surface is under app/wiki.
• The init flow uses one chosen behavior for app-surfaced single repos: select app/wiki from observable repository shape, ask the operator for the wiki root, or emit an explicit reconciliation instruction before durable docs onboarding artifacts are written.
• The generated operator prompt names the resolved wiki root and tells the next agent to treat that root as canonical for specs, raw inputs, routed project docs, and ingest bookkeeping.
• Existing behavior is preserved for monorepo-shaped apps/wiki targets.
• Existing behavior is preserved for standalone single-repo wiki/ targets that do not expose an app-surfaced wiki boundary.
• Once app/wiki is present as the selected wiki surface, scaffold update checks preserve that root and do not propose a competing wiki/ or apps/wiki tree.
• Focused regression coverage proves the app-surfaced single-repo scenario and the existing apps/wiki and wiki scenarios.
• Operator docs and project runbooks describe the app-surfaced single-repo shape and the required reconciliation rule before specs, plans, or onboarding docs are authored.

Constraints

• Keep CLI behavior deterministic where the repository shape is unambiguous.
• If path selection cannot be inferred safely, prefer an explicit operator prompt or reconciliation instruction over inventing project policy.
• Keep consumer-repo product policy out of the CLI; the CLI may recognize repository shape and surface placement, but not Traveolution-specific business rules.
• Preserve current scaffold ownership: apps/cli owns init/setup/update behavior; docs/ owns operator runbooks; apps/wiki/content/docs/project owns routed project specs and internal project docs.
• Do not hand-edit generated .agents/skills/* or apps/cli/skills/* as the source of truth.

Technical Notes

• Current init wiki target selection is in apps/cli/src/scaffold/stage.ts.
• Current init tests for single-repo wiki, monorepo apps/wiki, and output already inside apps/wiki live in apps/cli/src/scaffold/stage.test.ts.
• Current update wiki alignment prefers existing apps/wiki, then existing wiki, then falls back to monorepo shape in apps/cli/src/update/run.ts; it does not model app/wiki.
• Current requirements docs state only two default roots: monorepo-shaped target => apps/wiki/, single-repo target => wiki/.

Open Questions

Decision Log