Context
The shared SCAD runtime already ships openscad_docsgen / openscad-docsgen, and tool.scad-project already owns scad-project docs-lint for validating structured .scad documentation.
brainboxemb/lib.scad.forge#18 is adopting source-driven API/reference documentation now, with generated local output kept below bld/.
What is not yet generic is publication of that generated API/source reference through the normal scad.docs capability.
Goal
Retain the cross-project requirement for a later coordinated tooling/migration decision:
.scad docsgen comments
↓
tool.scad-project scad.docs
↓
bld/<source-api-docs namespace>
↓
dev/pr-N/bld / prod/bld / rel/vX.Y.Z/bld
The exact namespace and configuration are intentionally not decided by this issue.
Existing baseline
docker.scad-toolchain exposes openscad-docsgen and openscad-mdimggen;
tool.scad-project docs-lint already invokes openscad-docsgen -m -T for structured project source;
scad.docs currently owns generated design documentation under bld/design/**;
design documentation and API/source reference are explicitly separate concerns.
Questions for later migration
Should scad.docs gain a second generated output namespace such as bld/api or bld/reference?
What minimal project.scad.yml configuration selects source/API documentation generation?
Should generation include Files, ToC, Index, Topics and CheatSheet by default?
How are direct project source, reusable libraries and external checkouts treated?
Should API documentation generation be enabled by repository/library role rather than every CAD project?
How should generated API documentation be linked from repository READMEs and generated Build indexes?
Is openscad-mdimggen part of the initial contract or a later enhancement?
Which current libraries should act as migration canaries after Forge?
Boundary
proposed follow-up only; do not activate a migration from this issue;
do not block Forge Follow-up: make physical-verification document packages self-contained #18
do not commit generated source/API docs to normal source branches merely to avoid tooling work;
keep the upstream docsgen syntax/runtime in their existing owners rather than wrapping it unnecessarily.
Related agent-discoverability planning: #124 .
Context
The shared SCAD runtime already ships openscad_docsgen / openscad-docsgen, and tool.scad-project already owns scad-project docs-lint for validating structured .scad documentation.
brainboxemb/lib.scad.forge#18 is adopting source-driven API/reference documentation now, with generated local output kept below bld/.
What is not yet generic is publication of that generated API/source reference through the normal scad.docs capability.
Goal
Retain the cross-project requirement for a later coordinated tooling/migration decision:
The exact namespace and configuration are intentionally not decided by this issue.
Existing baseline
Questions for later migration
Boundary
Related agent-discoverability planning: #124.