Source Projects
This page tracks the internal repositories that the documentation portal can cover. It exists because the long-term goal is a single documentation site for multiple internal AI-assisted and operations projects, but each product should only be added after the audience, owner, deployment path, and source-of-truth behavior are clear enough to document responsibly.
Coverage model
Source repository ── contributes ── product docs
Product docs ── link to ── operations and reference pages
Operations pages ── explain ── shared procedures
Reference pages ── define ── stable vocabulary and ownership| Project | Path | Initial docs status |
|---|---|---|
| Commercial Aquatics Inspection System | /data/projects/pool-inspection | Started |
| PoolTracker / Preseason | /data/projects/preseason | Started |
| APS Calculator | /data/projects/aps-calculator-1.51 and /data/projects/aps_calc | Planned |
| CA Calc | /data/projects/ca-calc | Planned |
| Parts tools | /data/projects/parts | Planned |
| Pool billing dashboard | /data/projects/pb_dashboard | Planned |
| Maintenance contracts | /data/projects/maintcontracts | Planned |
Rule for adding a project
Add a product page only after identifying the primary audience, data sources, deployment model, and operational owner. Otherwise the docs become a folder dump instead of a usable portal.
Pitfalls
- Do not add a repository just because it exists under
/data/projects; unmanaged pages become stale quickly. - Do not document sensitive credentials, production secrets, or private customer details in the docs portal.
- Do not mix user tutorials with raw implementation notes on the same page when separate pages would be clearer.
Related pages
- Overview explains the portal structure.
- Product Docs explains the per-project section model.
- Deployments explains why app and docs deployment paths should remain separate.
Last updated on