Files
solvecraft/site
bherbruck 38680cd37f chore: remove solidcore-smlib-api and the SolidCraft preset (#1823 review)
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>
2026-10-30 20:38:39 -04:00
..

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".