Problem
Projects that already use docs/ for their own documentation (specs, API docs, etc.) experience path conflicts when compound-engineering auto-generates and references files under the same docs/ directory. This creates ambiguity about what is project-owned vs plugin-generated content.
Proposal
Allow users to configure the output path for plugin-generated documents (brainstorms, plans, solutions, specs) via a global or project-level setting — similar to how other paths are already configurable.
Example:
{
"compound-engineering": {
"docsPath": ".compound/docs"
}
}
This would redirect all auto-generated reads/writes from docs/ to the configured path.
Why it matters
docs/ is a widely used convention (VitePress, Docusaurus, API docs, etc.)
- Mixing project docs with plugin-generated artifacts makes both harder to navigate
- A simple path override keeps the default ergonomic while unblocking projects that need separation
Problem
Projects that already use
docs/for their own documentation (specs, API docs, etc.) experience path conflicts when compound-engineering auto-generates and references files under the samedocs/directory. This creates ambiguity about what is project-owned vs plugin-generated content.Proposal
Allow users to configure the output path for plugin-generated documents (brainstorms, plans, solutions, specs) via a global or project-level setting — similar to how other paths are already configurable.
Example:
{ "compound-engineering": { "docsPath": ".compound/docs" } }This would redirect all auto-generated reads/writes from
docs/to the configured path.Why it matters
docs/is a widely used convention (VitePress, Docusaurus, API docs, etc.)