Modeled on three researched precedents (see README): OpenWrt's Table of
Hardware for the browsable sortable/filterable table UX, postmarketOS's
working/community/testing tiers for the status field (collapsed to
working/partial/broken here), and RaspiBlitz's scattered GitHub-issues
approach as a negative example to avoid — hence structured YAML report
files validated against a JSON Schema instead of free-text issue threads.
- data/reports/*.yml + data/schema.json: one file per report, schema
requires `issues` whenever status is partial/broken
- scripts/build.py: validates every report and builds site/data.json,
fails loudly on bad data (same idea as archy's own
validate-app-manifest.sh)
- site/: plain HTML/CSS/JS, no framework or build step, fetches data.json
client-side — search, filter by status/form-factor, sortable columns,
click a row for issues/notes detail
- .github/ISSUE_TEMPLATE/hardware-report.yml: structured submission path
for contributors who don't want to touch git directly
- .gitea/workflows/ci.yml: runs the build/validate step on push and PRs
Not yet deployed anywhere — see README's Deployment section.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
