Edward Langley
188f3e94ef
improvise-d31's finished artifact depends on improvise-9x6 (the worker-hosted server) through improvise-djm. The *pipeline* does not, and building it now is what stops the delivery half from being a mystery when the worker lands: the swap from websocket transport to worker transport then changes what is bundled, not how it is built and shipped. Two jobs in ci.yml rather than a second workflow. `pages-build` runs on every push and pull request, so a change that breaks `web/build.sh` or the bundle fails on the PR that made it. `pages-deploy` runs only on a push to main and `needs: [test, wasm, pages-build]`, so nothing that failed `cargo test` or the existing wasm32 gate can reach the published site — the deploy depends on those checks instead of repeating them. Deliberately not path-filtered. The bundle is improvise-wasm-client plus improvise-protocol, improvise-core and improvise-formula, so a filter meaning "skip when the bundle cannot have changed" would have to name most of the workspace, and getting it wrong leaves a stale site with nothing saying so. wasm-pack is a pinned release tarball, v0.15.0 — the version `nix develop` now supplies — so the local run that produced 346 KB of wasm (120 KB gzipped) is evidence about the CI run. The devShell was missing wasm-pack entirely: the `wasm` job only runs `cargo check`, which does not need it, so nothing had ever required the one tool that turns a passing check into a loadable page. What this cannot do yet, said on the page itself rather than routed around: web/app.js is a thin client that holds no model, so a copy served from a static host paints an empty grid until it is pointed at an improvise-ws-server with ?ws=. The notice is static HTML, not something app.js decides, because it is true on every load and a page that cannot reach a server cannot be trusted to explain why. README says the same and names the deployed URL. Verified: cargo test --workspace 1134 passed / 0 failed, clippy clean, fmt clean, actionlint clean, ./web/build.sh succeeds and the assemble step produces a 388 KB site whose every reference resolves inside it. NOT verified: the workflow has never run — GitHub Pages is not enabled on the repository (GET /repos/fiddlerwoaroof/improvise/pages is 404), which is improvise-3gy. The deploy job asks configure-pages to enable it; if the token may not, that step is where the run fails and the fix is the repository setting. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EoW5BB87ZZdm96SvBTWawH
71 lines
2.9 KiB
HTML
71 lines
2.9 KiB
HTML
<!doctype html>
|
|
<html lang="en">
|
|
<head>
|
|
<meta charset="utf-8" />
|
|
<meta name="viewport" content="width=device-width, initial-scale=1" />
|
|
<title>improvise</title>
|
|
<link rel="stylesheet" href="./style.css" />
|
|
</head>
|
|
<body>
|
|
<!--
|
|
The browser shell for improvise-ws-server (improvise-cr3).
|
|
|
|
Deliberately three elements and no framework. Everything that could be
|
|
*wrong* — what a cell is, whether it may be typed into, where the
|
|
selection sits, how the category tree flattens — is decided in Rust and
|
|
arrives already decided (see `render.rs`). This page paints it.
|
|
|
|
Build the wasm module into ./pkg first:
|
|
|
|
wasm-pack build crates/improvise-wasm-client --target web --out-dir ../../web/pkg
|
|
|
|
then serve this directory over http (a module script will not load from
|
|
file://) and run the server beside it:
|
|
|
|
improvise-ws-server bank-info.improv --port 8787
|
|
python3 -m http.server 8080 --directory web
|
|
|
|
The socket address can be overridden with ?ws=ws://host:port.
|
|
-->
|
|
<header>
|
|
<h1>improvise</h1>
|
|
<span id="view-name"></span>
|
|
<span id="mode"></span>
|
|
<span id="status" role="status"></span>
|
|
</header>
|
|
|
|
<!--
|
|
This page is the *client* half and nothing else. It holds no model: what
|
|
a cell is, what it says and whether it may be typed into is decided by a
|
|
server and arrives already decided. So a copy served from a static host
|
|
— GitHub Pages included — paints an empty grid and says "disconnected"
|
|
until it is pointed at one.
|
|
|
|
Two servers are possible. `improvise-ws-server`, which exists, is a
|
|
native process you run yourself; pass its address as ?ws=ws://host:port.
|
|
The in-page worker (improvise-9x6), which does not exist yet, is what
|
|
makes this page standalone. Until it lands the honest description of a
|
|
Pages deployment is "the delivery pipeline, carrying a client with
|
|
nowhere to connect" — which is why this notice is static HTML rather
|
|
than something app.js decides: it is true on every load, and a page that
|
|
cannot reach a server cannot be trusted to explain why.
|
|
-->
|
|
<p id="backend-notice">
|
|
improvise in the browser is a thin client: the document lives in a
|
|
server. Run <code>improvise-ws-server model.improv --port 8787</code>
|
|
and reload with <code>?ws=ws://127.0.0.1:8787</code>. Served over
|
|
https, a <code>ws://</code> address is blocked as mixed content — use
|
|
<code>wss://</code> or a local http server. Running with no separate
|
|
process at all is the in-page worker (improvise-9x6), and it is not
|
|
built yet.
|
|
</p>
|
|
|
|
<main>
|
|
<aside id="categories" aria-label="Categories"></aside>
|
|
<div id="grid" tabindex="0" aria-label="Grid"></div>
|
|
</main>
|
|
|
|
<script type="module" src="./app.js"></script>
|
|
</body>
|
|
</html>
|