Add area quality gate
This commit is contained in:
41
.trellis/tasks/08-04-add-area-quality-gate/prd.md
Normal file
41
.trellis/tasks/08-04-add-area-quality-gate/prd.md
Normal file
@@ -0,0 +1,41 @@
|
||||
# Add area quality gate
|
||||
|
||||
## Goal
|
||||
|
||||
Add a lightweight check:area command that turns diagnostics and manifests into pass/fail quality gates.
|
||||
|
||||
## Requirements
|
||||
|
||||
- Add a lightweight `check:area` npm command for an area quality gate.
|
||||
- The command must not run QGIS, Blender, Cesium, compression, or rebuild stages.
|
||||
- The command must reuse the same diagnostics source of truth used by
|
||||
`diagnose:area`; avoid duplicating OSM parsing, artifact checks, GLB budget
|
||||
checks, or manifest stale checks.
|
||||
- The first quality gate must fail on:
|
||||
- invalid or missing OSM bounds
|
||||
- malformed building multipolygon relations
|
||||
- missing baseline GLB / metadata / Cesium preview artifacts
|
||||
- invalid metadata JSON
|
||||
- GLB size / node / image budgets exceeded
|
||||
- missing, invalid, or stale expected stage manifests
|
||||
- Missing QGIS preview remains a warning in this first version.
|
||||
- The command must print a concise pass/fail report and use exit code `0` for
|
||||
pass and `1` for fail.
|
||||
- README and pipeline spec must document command usage and failure policy.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [x] `npm run check:area -- --config config/areas/nantaizi-lake-innovation-valley.json`
|
||||
passes against current nantaizi outputs.
|
||||
- [x] The check report includes pass/fail counts and any warning lines.
|
||||
- [x] `check:area` exits non-zero for a deliberately impossible missing-output
|
||||
config or equivalent controlled failure case.
|
||||
- [x] `diagnose:area` still works after any shared diagnostics refactor.
|
||||
- [x] Syntax checks pass for changed Node scripts.
|
||||
- [x] README and Trellis pipeline spec document `check:area`.
|
||||
|
||||
## Notes
|
||||
|
||||
- Keep `prd.md` focused on requirements, constraints, and acceptance criteria.
|
||||
- Lightweight tasks can remain PRD-only.
|
||||
- For complex tasks, add `design.md` for technical design and `implement.md` for execution planning before `task.py start`.
|
||||
Reference in New Issue
Block a user