Complete documentation validation pass
This commit is contained in:
@@ -16,5 +16,6 @@ weatherreporter generate daily --date 2026-05-29 --out ./daily.md
|
|||||||
- [CLI reference](docs/cli.md)
|
- [CLI reference](docs/cli.md)
|
||||||
- [Configuration reference](docs/config.md)
|
- [Configuration reference](docs/config.md)
|
||||||
- [Operations guide](docs/operations.md)
|
- [Operations guide](docs/operations.md)
|
||||||
|
- [Troubleshooting](docs/troubleshooting.md)
|
||||||
- [Architecture policy](docs/policy/architecture.md)
|
- [Architecture policy](docs/policy/architecture.md)
|
||||||
- [Development policy](docs/policy/development.md)
|
- [Development policy](docs/policy/development.md)
|
||||||
|
|||||||
@@ -77,44 +77,36 @@ unimplemented work belongs only under `docs/roadmap/`.
|
|||||||
|
|
||||||
## Policy Compliance Assessment
|
## Policy Compliance Assessment
|
||||||
|
|
||||||
Required documents for a modular, staged, CLI/config-driven, stateful
|
Required documents for a modular, CLI/config-driven, stateful application are
|
||||||
application are mostly present: `README.md`, `docs/cli.md`, `docs/config.md`,
|
present: `README.md`, `docs/cli.md`, `docs/config.md`,
|
||||||
`docs/operations.md`, `docs/internal/`, and `docs/policy/development.md`.
|
`docs/operations.md`, `docs/internal/`, and `docs/policy/development.md`.
|
||||||
The main required gap is that `docs/policy/development.md` is not in the
|
|
||||||
canonical contributor-workflow shape required by `docs/policy/documentation.md`.
|
|
||||||
|
|
||||||
Recommended documentation gaps:
|
Recommended documentation is also present:
|
||||||
|
|
||||||
- `docs/troubleshooting.md` is missing.
|
- `docs/troubleshooting.md` covers recurring operator-facing failure modes.
|
||||||
- Validated examples are limited to `examples/config.yml`; there is no minimal
|
- `examples/config.yml` and `examples/minimal-config.yml` are validated by
|
||||||
example config.
|
config tests.
|
||||||
- `docs/internal/app-orchestration.md` is missing for the implemented
|
- `docs/internal/app-orchestration.md` documents the workflow coordinator.
|
||||||
application workflow layer.
|
|
||||||
|
|
||||||
Documents that are stale or in the wrong canonical home:
|
Documents that were stale or in the wrong canonical home have been corrected:
|
||||||
|
|
||||||
- `docs/policy/development.md` contains proposed layout, MVP wording, and future
|
- `docs/policy/development.md` is the contributor workflow policy.
|
||||||
design notes that should live in roadmap docs or be removed once implemented.
|
|
||||||
- `docs/roadmap/future.md` is the current home for deferred project work.
|
- `docs/roadmap/future.md` is the current home for deferred project work.
|
||||||
- `README.md` links to the implementation roadmap. The README should link to
|
- `README.md` links to current user/operator/developer docs.
|
||||||
current user/operator/developer docs and, if useful, a future-work roadmap
|
- `docs/integrations/weatherapi.md` is limited to the implemented adapter
|
||||||
that is clearly labeled as such.
|
contract.
|
||||||
- `docs/integrations/weatherapi.md` includes endpoint details beyond the
|
|
||||||
implemented adapter fan-out and should be narrowed.
|
|
||||||
|
|
||||||
Content that appears planned, historical, or aspirational outside
|
Content that appears planned, historical, or aspirational outside
|
||||||
`docs/roadmap/`:
|
`docs/roadmap/`:
|
||||||
|
|
||||||
- `docs/policy/development.md` uses proposed/future/MVP language and describes
|
- Non-roadmap docs should remain limited to implemented behavior. Some
|
||||||
some behavior as intended rather than current contributor practice.
|
policy-level wording about future work is legitimate; feature-specific
|
||||||
- Non-roadmap docs should be searched for future-oriented terms during the
|
deferred behavior belongs under `docs/roadmap/`.
|
||||||
migration. Some instances in policy docs are legitimate policy wording, but
|
|
||||||
feature-specific plans should move under `docs/roadmap/`.
|
|
||||||
|
|
||||||
Examples:
|
Examples:
|
||||||
|
|
||||||
- `examples/config.yml` exists and matches the implemented configuration shape,
|
- `examples/config.yml` and `examples/minimal-config.yml` exist and load
|
||||||
but the documentation should state how it is validated.
|
through the config test suite.
|
||||||
- No generated report examples should be added unless they can be maintained
|
- No generated report examples should be added unless they can be maintained
|
||||||
without live Weather API and Scriptorium dependencies.
|
without live Weather API and Scriptorium dependencies.
|
||||||
- No workflow examples should be added for unimplemented daemon, cleanup,
|
- No workflow examples should be added for unimplemented daemon, cleanup,
|
||||||
|
|||||||
Reference in New Issue
Block a user