Block streampixels on its 3D redirection; heimdall leads the three

StreamPixels is changing direction: 2D animation could not express what
the spec required, so it is moving to a 3D-rendered overlay, and whether
that runs in WebGL or needs dedicated rendering infrastructure is open.
The client funding it cannot absorb rendering overhead, which is what makes
the WebGL question load-bearing rather than a preference.

Its deployment shape is downstream of that answer -- a WebGL overlay keeps
roughly the current two-unit shape, rendering infrastructure is a new
target class with hardware requirements this host has never expressed. A
binding written now would pin the shape being replaced.

The survey of its current defects stays as a record but is marked
superseded, with an explicit instruction not to act on it. The tsx-at-
runtime path is exactly the kind of thing a passing agent would tidy, and
tidying it would be work spent on something being replaced.

heimdall leads the remaining three instead. Its prerequisite is deeper
than repixelizer's but far better understood: a vendor/CultLib gitlink,
following Ghostlight's existing vendor/eve pattern, replacing a
cultlib_commit hardcoded in a shell manifest.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Meta Vens 2026-09-06 00:38:31 +02:00
commit d32d46e7be

View file

@ -41,14 +41,21 @@ Migrate in dependency order, and migrate the authority's own dependencies last:
resident to produce frames nothing rendered. The only reference to
`gjallar.overview` in the estate is one Odin test file. Stopped and disabled;
420 MB under `/srv/gjallar` is reclaimable.
1. **`streampixels`** — first of the three. See *The first three targets*: it
already has real build scripts and no external dependencies, but must split
into two Idunn targets and stop running TypeScript through `tsx`.
2. **`repixelizer`** — second. No CultLib dependency at all; needs an artifact
story for Python before a recipe means anything. Unit is `repixelizer-gui`.
3. **`heimdall`** — third, not first. Most release-shaped, but takes CultLib
from a sibling checkout via `file:../CultLib`, so it needs a `vendor/CultLib`
gitlink before its source can be sealed.
1. **`heimdall`** — first. Most release-shaped of what remains, and its one
prerequisite follows an existing estate pattern: it takes CultLib from a
sibling checkout via `file:../CultLib`, so it needs a `vendor/CultLib`
gitlink before its source can be sealed. See *The first three targets*.
2. **`repixelizer`** — second. No CultLib dependency at all, but runs a venv
interpreter against a checkout, so it needs an artifact story for Python
before a recipe means anything. Unit is `repixelizer-gui`.
3. **`streampixels`** — **blocked, like Ghostlight.** The product has changed
direction: 2D animation could not express what the spec required, so it is
moving to a 3D-rendered overlay, and whether that runs in WebGL or needs
rendering infrastructure is undecided. Its deployment shape depends on that
answer — a WebGL overlay is the current two-unit shape, rendering
infrastructure is a new target class with hardware requirements. Do not
migrate it, and do not "fix" the 2D animation path: it is being replaced, not
repaired. There is a paying client, so coordinate rather than assume.
**Their continuity is already broken, and has been.** The legacy actuator
restarts all three with
@ -170,7 +177,23 @@ Surveyed 2026-09-06. **None of the three can take a recipe as they stand.** Each
needs a change in its own repository first, and the changes are not the same
shape, so they are not one piece of work. Ordered by how much has to happen.
### `streampixels` — split one target into two, then use the build it already has
### `streampixels` — blocked on a product redirection, do not migrate
**Superseded 2026-09-06.** The findings below were surveyed before learning the
product is changing direction. 2D animation could not express what the spec
required; StreamPixels is moving to a **3D-rendered overlay**, and whether that
is achievable in WebGL or needs dedicated rendering infrastructure is still
open. The client funding it reportedly cannot absorb rendering overhead, which
is what makes the WebGL question load-bearing rather than a preference.
Its deployment shape is downstream of that decision. A WebGL overlay keeps
roughly the current two-unit shape; rendering infrastructure is a new target
class with hardware requirements Idunn has never expressed on this host. Writing
a binding now would pin the shape being replaced.
Keep the survey below only as a record of the current deployment's defects, and
do not act on it — in particular, do not repair the `tsx`-at-runtime path. It is
being replaced, not fixed.
Both apps already have build scripts: `apps/service` runs `tsc -p
tsconfig.json`, `apps/web` runs `next build`, and the root has `pnpm -r build`.