bherbruck
b238132e01
scripts/split_archives.py (run with python3 -I) splits the frozen plan/findings.md
(425 `## ` sections) and plan/upstream-issues.md (436 `#### ` entries) into one file
per record under plan/findings/ and plan/upstream-issues/, moves the archives' intro
and "Note: duplicate IDs" text into the READMEs, and deletes the archives.
`split_archives.py check` proves the split lossless against the archives at 4fe6f4d51.
site/build.py reads issues only from the directory (intro from its README);
check-frozen-archives.sh now fails if either archive comes back.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QaDuBSC1mqS9DnQoEsr7LJ
Progress site
site/build.py generates the GitHub Pages site from data already in the repository;
nothing on it is maintained by hand except the short intro paragraph in the generator.
python3 site/build.py && python3 -m http.server -d bin/site 8000 # build (~3 s), then open http://localhost:8000
Python 3.11+ standard library only (tomllib). Output goes to bin/site/ (gitignored);
--out DIR writes elsewhere. The output is deterministic: the only date on it is the
commit date of HEAD.
| Page | Data |
|---|---|
Overview (index.html) |
plan/units/*.toml via harness/plan/progress.py (summary, is_ready), claims from the "In progress" section of plan/PROGRESS.md, reports/ssi-corpus.json, and the plan along main's first-parent git history for the timeline (plan/units/, or plan/modules.toml before the per-unit split). The history is read once; overall, per-module and per-unit series come from the same pass |
Module pages (areas/<module>.html) |
plan/units/ and its history: the same chart as the overview, over that module's units only |
Units (units/index.html) |
plan/units/*.toml, harness/callgraph/units.json, reports/difftest/*.json (cases_*, deferred_by_unit; copied to reports/<unit>.json on the site). Reports are not committed: CI fetches main's latest set with scripts/fetch-reports.sh before building; run it locally too |
Unit pages (units/<id>.html) |
the above, plus the `//! |
Dependency graph (graph.html, assets/graph.json) |
plan/units/*.toml (depends_on, module, status) and claims, laid out as one force-directed cluster per module; lists of ready and most-blocking units are rendered server-side, the graph by site/assets/graph.js |
Upstream issues (issues.html) |
plan/upstream-issues/*.md, one #### <SERIES>-<n>. entry per file, in name order; the intro is that directory's README.md |
SSI corpus (ssi.html) |
reports/ssi-corpus.json |
Solids (solids.html; tile on the overview) |
reports/solids/solids.json: the primitives example's --json output (schema in crates/solidcore/examples/primitives/main.rs; copied to reports/solids.json on the site). Not committed: CI's test job uploads it from main as the solids-report artifact and the Pages build fetches it with scripts/fetch-solids.sh. Without it the page says "no data yet". The "Corpus (real models)" section is a placeholder until corpus.models is filled |
Text from the repository is HTML-escaped before a small markdown subset (inline code,
bold, italic, http(s) links, nested - lists) is applied, so raw HTML written in a PR
never reaches the page. Charts are inline SVG; site/assets/app.js only sorts and
filters tables, drives the chart tooltips and the overview's module picker (without JS the overview
shows the all-units chart). The only third-party code is d3-force (ISC), vendored under
site/assets/vendor/ and used only by the graph page (see ATTRIBUTION.md). No external assets.
Deployment: .github/workflows/pages.yml rebuilds on every push to main, after a
"Progress checklist" run that pushed a new plan/PROGRESS.md (those commits carry
[skip ci], so they do not trigger a push build), and on manual dispatch. GitHub Pages
must be enabled with source "GitHub Actions".