← Priority list
In progress

Land the sazabi.com dark landing page capture in Good-UI-Designs (deploy to TinySite for owner review, then PR after approval)

Remaining: once TinySite publishing works again, deploy dark-landing-sazabi/ from Good-UI-Designs branch wip/dark-landing-sazabi-handoff-2026-10-09 (head 1659dbe) to TinySite, send the owner the link, test the deployed site, and after explicit owner approval remove _wip-sazabi-capture-tools/, add the README entry and open the PR (never include the TinySite link). State: the capture (300 files, 44 MB, real site assets with documented URL/basePath/no-analytics edits) was verified frame-by-frame against the live site under a sub-path; blocked on the TinySite fix handoff because TinySite publishes fail with RELAY_FORWARD_FAILED (verified 2026-10-13).

In progress via hf-2026-10-13-restore-tinysite-publishing-diagnose-the-tinysite-to-filedrop-relay-forward-failed-outage-decide-the-urlresolver-pr-1226-design-land-the-outage-fix-prs-and-redeploy-sfs-filedrop-tinysite (claimed by fable-orchestrator)

Handoff document

Markdown

Land the sazabi.com dark landing page capture in Good-UI-Designs

RE-VERIFY: write-time snapshot 2026-10-13 ~00:15 UTC. Re-check the branch with gh api repos/CodexCoder21Organization/Good-UI-Designs/branches/wip/dark-landing-sazabi-handoff-2026-10-09 -q .commit.sha and TinySite with a one-file ~/.claude/skills/good-ui-designs/scripts/tinysite-deploy.sh publish before acting.

Blocked on: url://handoff/handoffs/hf-2026-10-13-restore-tinysite-publishing-diagnose-the-tinysite-to-filedrop-relay-forward-failed-outage-decide-the-urlresolver-pr-1226-design-land-the-outage-fix-prs-and-redeploy-sfs-filedrop-tinysite (TinySite fix). On 2026-10-13 a one-file TinySite publish failed at POST /api/sites with HTTP 502 RELAY_FORWARD_FAILED (TinySite→filedrop relay path), so the review deploy this skill requires cannot happen yet. Split out of that handoff on 2026-10-13 at the owner's request.

Mission

On 2026-10-08 the owner asked: "Use your good ui design skills to fetch https://www.sazabi.com/". Follow the good-ui-designs skill (~/.claude/skills/good-ui-designs/SKILL.md) exactly: the deliverable is the site's real HTML/CSS/JS/assets (never a reimplementation), verified against the live page, deployed to TinySite for the owner to review, and only after the owner explicitly approves, a PR to https://github.com/CodexCoder21Organization/Good-UI-Designs. The TinySite review link must never appear in the PR.

What was done (verified 2026-10-08)

  • Capture method. Headless Chromium (Playwright chromium_headless_shell-1228) with SwiftShader WebGPU recorded every response while loading the live page and scrolling it end to end: 260 responses, including 125 isometric-city frames from the site's blob storage, the Draco decoder from gstatic, GLB models, EXR/KTX2 textures and audio. build.js then fetched referenced-but-unloaded chunks and assets, giving 300 files and 44 MB.
  • Page structure. The page is a Next.js (Turbopack) app whose hero is a three.js WebGPURenderer cockpit scene. Without WebGPU it shows its own "3D experience unavailable" notice.
  • Edits made. Only URL and mount-path changes; all are documented in the README on the branch:
    • absolute URLs were made relative, and third-party assets are mirrored under _ext/;
    • Next's compiled addBasePath/removeBasePath/hasBasePath and two direct location.pathname checks use the directory the page is served from, which is equivalent to a basePath build. Without this the app didn't see the home route: it hit a hydration error (#418), never released its scroll lock, and skipped its asset loader;
    • next/image is set to unoptimized;
    • the site's own consent check treats Do-Not-Track as on, so the copy sends no analytics (PostHog, Vercel Analytics, RB2B, Sazabi log intake);
    • links to the site's other pages point to the live sazabi.com.
  • Verification. The copy was served under a sub-path (/s/test/, simulating TinySite) and compared with the live site in headless Chromium:
    • the hero's WebGPU scene, the ALERTS/AGENTS/CHAT carousel, the investor strip, the "Ready for action" section, the feature cards, the integration orbit, the manifesto and the footer matched frame by frame;
    • the only console messages were the live site's own four warnings (GSAP target, "Invalid scope", THREE.Clock deprecated, a TSL normal-attribute warning);
    • there were zero failed requests and zero external requests.
  • Over file://. All asset paths resolve to files that exist, but Chromium blocks fetch() and CORS-mode font/texture loads from file origins, so the 3D scene, fonts and textures don't load there. The README therefore says to view it over HTTP. Embedding the 44 MB of assets into the HTML to make file:// work was judged not worthwhile; the owner hasn't ruled on it.

Relevant PRs / refs

Repo Branch Remote head SHA PR What is on it State
CodexCoder21Organization/Good-UI-Designs wip/dark-landing-sazabi-handoff-2026-10-09 1659dbe69853c082c55c389152c02d5c28641d39 no PR dark-landing-sazabi/ (the captured site, screenshot.png, README) and _wip-sazabi-capture-tools/ (record.js, build.js, serve.js, the verification scripts, env.sh; delete before the PR) verified over HTTP under a sub-path; not deployed to TinySite; not owner-approved; the repository README entry is not added yet

The raw 36 MB recording wasn't committed; regenerate it with record.js. Nothing was published or deployed for this capture.

Next steps

  1. Wait until the dependency handoff is complete and a multi-file TinySite publish works.
  2. Check out the branch. Deploy only dark-landing-sazabi/ with ~/.claude/skills/good-ui-designs/scripts/tinysite-deploy.sh <checkout>/dark-landing-sazabi --title dark-landing-sazabi. README.md is excluded automatically; screenshot.png doesn't need publishing (pass explicit paths if you want to leave it out).
  3. Send the owner the link immediately, then test the deployed site:
    • check the bytes and Content-Type of the published files;
    • load it in headless Chromium with the WebGPU flags below, watching pageerror, requestfailed, status ≥400 and external requests;
    • inspect the first frame;
    • scroll through and confirm the carousel cycles. Report honestly what was checked.
  4. Wait for explicit approval. Then:
    • delete _wip-sazabi-capture-tools/;
    • add a top-level README.md entry with the preview;
    • commit and open the PR with a why-first description. The owner's request was "Use your good ui design skills to fetch https://www.sazabi.com/". Never include the TinySite link.
  5. Offer to merge.

Operational knowledge

  • Headless Chromium on the /code box (aarch64).
    • Install Playwright's chromium-headless-shell.
    • The missing libraries come from Debian bookworm arm64 .debs. The apt lists are empty, so resolve file names from http://deb.debian.org/debian/dists/bookworm/main/binary-arm64/Packages.gz and extract with dpkg -x into ~/.cache/chromium-deps.
    • Set LD_LIBRARY_PATH=~/.cache/chromium-deps/usr/lib/aarch64-linux-gnu:~/.cache/chromium-deps/lib/aarch64-linux-gnu.
    • WebGPU flags: --enable-unsafe-swiftshader --use-angle=swiftshader --enable-unsafe-webgpu --enable-features=Vulkan,WebGPUService --use-vulkan=swiftshader --use-webgpu-adapter=swiftshader --ignore-gpu-blocklist (in gpu.js).
    • Software rendering is slow, so allow about 20 s after load before the first screenshot. A run against the live site once crashed the renderer partway through.
  • To regenerate the capture: node record.js <recDir>, then node build.js <recDir> <outDir>, then node serve.js <outDir> 8731 /s/test/ and run the verification scripts against http://localhost:8731/s/test/.

No status reports yet.

Add dependency

Complete this handoff

Moves it out of every priority list and into ArchiveArea.