The dashboard shell is wired end to end, but nothing is pinned yet. A release cut today ships a placeholder page at {BasePath}/ui.
That is deliberate. Both pin files at the repo root read none:
.dashboard-shell-version none
.dashboard-shell-version.sha256 none
scripts/fetch-dashboard-shell.sh sees the sentinel, skips the download, keeps the committed placeholder, and exits 0 even under CI, warning loudly enough that a release built in this state says so in its own log. The alternative was failing the build when no shell is pinned, which would have blocked every forge release until the dashboard repo shipped its first tag, and that seemed like the wrong trade for a component that releases on its own cadence.
What unblocks it
Someone with release rights on xraph/forge-dashboard tags vX.Y.Z there first. Its release.yml builds apps/shell, packs forge-dashboard-shell-vX.Y.Z.tar.gz, and attaches it to the release. Nothing in this repo can do that step.
Then come back here, download the asset, take its digest, and write both values into the two pin files in one commit. The commands are in extensions/dashboard/shellassets/dist/README.md, which is where the fetch script's own error messages point you.
Why two files and not one
A GitHub release asset can be deleted and re-uploaded under an existing tag, with no commit and no trace in git history, so pinning a version fixes the artifact's name and tells you nothing whatsoever about what is inside it. Without the digest, write access to that repo's releases is write access to the JavaScript in every Forge binary that serves a dashboard.
The script treats a mismatch as a hard failure in every mode, including the soft-fail path. It also refuses a pinned version with no digest at all.
One correction to make at the same time
The README says "bumping one without the other fails the build, on purpose". True in one direction. Move the version ahead of the digest and you get a hard failure, which is what you want. Move the digest ahead of the version and the sentinel check runs first, so you get the placeholder and a clean exit. Safe, and loud, but the sentence claims more than the code delivers.
Where the pieces live
| Thing |
Where |
| Sentinel handling, digest check, atomic swap |
scripts/fetch-dashboard-shell.sh |
| Bump procedure |
extensions/dashboard/shellassets/dist/README.md |
| The placeholder a release ships today |
extensions/dashboard/shellassets/dist/index.html |
| Where the fetch runs |
.goreleaser.yml, before.hooks, after the go work init hook |
The shell app, its release workflow and the three npm packages all live in xraph/forge-dashboard on main. None of the packages are published yet either, so forge dashboard new currently scaffolds a project you cannot run pnpm install in. That clears up the same way, once the tag exists.
The dashboard shell is wired end to end, but nothing is pinned yet. A release cut today ships a placeholder page at
{BasePath}/ui.That is deliberate. Both pin files at the repo root read
none:scripts/fetch-dashboard-shell.shsees the sentinel, skips the download, keeps the committed placeholder, and exits 0 even under CI, warning loudly enough that a release built in this state says so in its own log. The alternative was failing the build when no shell is pinned, which would have blocked every forge release until the dashboard repo shipped its first tag, and that seemed like the wrong trade for a component that releases on its own cadence.What unblocks it
Someone with release rights on
xraph/forge-dashboardtagsvX.Y.Zthere first. Itsrelease.ymlbuildsapps/shell, packsforge-dashboard-shell-vX.Y.Z.tar.gz, and attaches it to the release. Nothing in this repo can do that step.Then come back here, download the asset, take its digest, and write both values into the two pin files in one commit. The commands are in
extensions/dashboard/shellassets/dist/README.md, which is where the fetch script's own error messages point you.Why two files and not one
A GitHub release asset can be deleted and re-uploaded under an existing tag, with no commit and no trace in git history, so pinning a version fixes the artifact's name and tells you nothing whatsoever about what is inside it. Without the digest, write access to that repo's releases is write access to the JavaScript in every Forge binary that serves a dashboard.
The script treats a mismatch as a hard failure in every mode, including the soft-fail path. It also refuses a pinned version with no digest at all.
One correction to make at the same time
The README says "bumping one without the other fails the build, on purpose". True in one direction. Move the version ahead of the digest and you get a hard failure, which is what you want. Move the digest ahead of the version and the sentinel check runs first, so you get the placeholder and a clean exit. Safe, and loud, but the sentence claims more than the code delivers.
Where the pieces live
scripts/fetch-dashboard-shell.shextensions/dashboard/shellassets/dist/README.mdextensions/dashboard/shellassets/dist/index.html.goreleaser.yml,before.hooks, after thego work inithookThe shell app, its release workflow and the three npm packages all live in
xraph/forge-dashboardonmain. None of the packages are published yet either, soforge dashboard newcurrently scaffolds a project you cannot runpnpm installin. That clears up the same way, once the tag exists.