SolidCraft's C-API composition stays in SolidCraft (its crates/smlib adapter, tangency-labs/solidcraft#8526), as brett19 asked on #1823. solidcore stays the SMLib/SM_API port. This removes the solidcore-smlib-api crate, the UpstreamFixes::solidcraft() preset and its records test, the difftest "solidcraft" fix alias, plan/smlib-api and the site's SolidCraft API page. Kept: the general kernel pieces #1823 brought (WR-596 box_face_failures_propagate, local_operation_simple, the brep p2/p5 and primitive helpers) and every UpstreamFixes field; SolidCraft chooses which to turn on. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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 each CI
run on main (fresh difftest reports), hourly (claims from open port: PRs) and on manual
dispatch. It first generates the unit checklist (harness/plan/progress.py --prs), which
the site publishes as PROGRESS.md; nothing is committed back to main. GitHub Pages
must be enabled with source "GitHub Actions".