Publishing Long-Form Reports Alongside the Web App
When HTML reports should live under public/, how to link them from docs, and why static bundles complement live APIs.
Reports are not APIs
Readiness narratives, executive summaries, and integration matrices are often authored as static HTML or Markdown. They age like documentation: useful for humans, not a substitute for live verification (tests, gates, OpenAPI).
Making them reachable
If users should open reports in a browser without cloning the repository, copy (or build) the static files into the web app's public tree. That yields stable URLs such as /reports/.../index.html on the same host as the product site.
Keep a single source of truth in the repository for edits, then sync to public during release or in CI so production does not drift from the canonical folder.
Link from docs
A short docs page that lists the index, major sections, and "how to update" reduces support questions. Link related API and proxy docs so readers know where to go for behavior, not just commentary.
What we avoid putting in public reports
Treat public bundles as non-sensitive summaries. Do not embed credentials, private customer data, or unreleased roadmap details. If a report was generated from internal-only inputs, strip or redact before publishing.
Build with proof, not promises
Join the developers compiling intent into deployable software with deterministic gates.