|
| 1 | +## Phase 2 Plan: Quality Ledger & Metrics |
| 2 | + |
| 3 | +### Summary |
| 4 | +- Implement Phase 2 on branch `codex/phase-2-quality-ledger`. |
| 5 | +- Capture one quality snapshot per release tag (`vNNNN`) with Lighthouse, broken-link count, and build time. |
| 6 | +- Persist snapshots in-repo for future dashboarding, while preventing metrics commits from triggering deploy/version loops. |
| 7 | +- Add an issue template field for `Site Version` so bug reports can be attributed to releases. |
| 8 | + |
| 9 | +### Implementation Changes |
| 10 | +- Update deploy workflow in `.github/workflows/deploy.yml`: |
| 11 | + - Move tag creation to after the Pages deploy step so a tag represents an already-deployed version. |
| 12 | + - Add `paths-ignore` for the quality ledger file(s) so metrics-only commits do not trigger deploy/version bump. |
| 13 | +- Add a new workflow (for example `.github/workflows/quality-ledger.yml`) that runs on tag pushes matching `v*` and on manual dispatch: |
| 14 | + - Read version from the tag. |
| 15 | + - Run `bundle exec jekyll build` and record elapsed seconds. |
| 16 | + - Serve `_site` locally and run Lighthouse audits; capture Performance, Accessibility, and SEO. |
| 17 | + - Run `linkinator` against the built/served site and capture broken-link count. |
| 18 | + - Append a new record to `_data/quality_log.yml` with: `version`, `release_date`, `commit_sha`, `lighthouse.performance`, `lighthouse.accessibility`, `lighthouse.seo`, `broken_links`, `build_time_seconds`, `workflow_run_url`. |
| 19 | + - Commit the updated ledger back to `main` with a bot commit message. |
| 20 | +- Add/enable issue templates: |
| 21 | + - Create `.github/ISSUE_TEMPLATE/bug_report.yml` with required `site_version` field and helper text to copy from footer (`rev.XXXX`). |
| 22 | + - Add `.github/ISSUE_TEMPLATE/config.yml` (disable blank issues if desired) and direct bug reporters to include version. |
| 23 | +- Documentation updates: |
| 24 | + - Update `README.md` with “Quality Ledger” behavior and where the data lives. |
| 25 | + - Mark Phase 2 checklist progress in `ROADMAP.md` as each item lands. |
| 26 | + |
| 27 | +### Public Interfaces / Data Contract |
| 28 | +- New data contract in `_data/quality_log.yml`: one entry per released version with stable keys listed above. |
| 29 | +- New contributor-facing interface: GitHub bug issue form with required `Site Version`. |
| 30 | +- CI contract: release tags (`vNNNN`) become the trigger for quality snapshot collection. |
| 31 | + |
| 32 | +### Test Plan |
| 33 | +- Workflow validation: |
| 34 | + - Run `quality-ledger` via `workflow_dispatch` once to verify parsing/output and ledger append format. |
| 35 | + - Push/create a test tag in a safe branch/repo context to confirm tag-trigger behavior. |
| 36 | +- Data validation: |
| 37 | + - Ensure new ledger entry is appended (not overwritten) and version key matches tag. |
| 38 | + - Confirm numeric parsing for Lighthouse scores, broken links, and build seconds. |
| 39 | +- Regression checks: |
| 40 | + - Confirm metrics-only ledger commit does not trigger deploy workflow. |
| 41 | + - Confirm normal content changes still trigger deploy and version bump. |
| 42 | +- Issue template checks: |
| 43 | + - Open “New issue” UI and verify `site_version` is required and guidance text is present. |
| 44 | + |
| 45 | +### Assumptions & Defaults |
| 46 | +- Defaulted storage choice: in-repo ledger at `_data/quality_log.yml` (chosen to support Phase 4 dashboarding). |
| 47 | +- Lighthouse target is the locally served built site for repeatable CI numbers; production URL checks can be added later as a secondary metric. |
| 48 | +- Bug counts are “attributable” in Phase 2 by collecting `Site Version` in issue intake; aggregate reporting is deferred to Phase 4 dashboard/trends. |
0 commit comments