in.gnu6

Most graphics engines mix two questions: "what exists?" and "how do we draw it?". The mix holds until the day you want to change rendering engines, export a scene, or run two products on the same model — and then everything has to be rewritten.

in.gnu6 separates the two. A TypeScript core maintains the scene: identities, relations, hierarchy, spatial constraints, deterministic time, dynamics, topology, deformations, queries and reproducible observations. The renderers — a browser with PixiJS, a native Vulkan engine, or a consuming product — only project that state.

Docklab, a dock of nested cards, and a harness for a jewellery shop, a fan of tarot cards: two trades with nothing in common. They must run on the same core, without either one forking its laws.

This is milestone MQ-10. The two products share a single test scene, with one clock, one space and one topology registry. They are allowed only adapters and configuration: no product name, no special branch in the engine's code.

The run also found a fault: a hard-coded assumption about the direction in which a card lifts. It was repaired, and putting it back makes an end-to-end test fail; once fixed, the core passes 96 tests across 24 files.

Two observations recur in the repository's documents, and they are interesting precisely because they are bounded.

Endurance: 9,370 frames presented in 124.994 seconds, without a single discarded frame — about 75 frames per second on average, with a p95 of 13.478 ms. Measured locally, through the Wayland compositor's presentation timestamps.

Real exchange: a Rust program and the TypeScript semantic projector exchanged 40 real Wayland events over a private Unix socket, with an exact sequence match and 1,497 frames presented in 20 seconds, without loss.

9,370 frames presented by the compositor, none discarded. 9,368 intervals fall between 12.9 and 14 ms, around the screen period (13.34 ms). The only one above 20 ms is the very first, at start-up: 26.65 ms.

The repository does not present a list of features: it presents a list of milestones to ratify. Each must rest on a law, a falsification test, an execution observation — or remain explicitly open. A milestone can be rejected by a failing test, and the rejection stays written down.

A side experiment in the repository shows the method at work. A Rust supervisor hands a graphics computation to a separate process, under a distinct system account, and eleven gates are written before the run. Three acquisitions failed; they are kept. The fourth passes the ten lab gates — and the eleventh, the authorisation to publish, remains refused for lack of an independent human review.

The two consuming products presented above play their part here: if either needed a second scene, the separation would be wrong.

This discipline explains the figures at the top of the page: 16 ratified milestones do not mean "ready", and 9,370 frames without loss do not mean "smooth for you". Every number carries its frame.

The repository does not keep a task list: it keeps a quest log. The main questline defines what "complete" means; side quests keep what was learned along the way.

A quest has fifteen possible states, from UNKNOWN to CLOSED, and they do not form a ladder: "green locally" does not imply "observed", and "observed" does not imply "ratified". Side quests may be urgent or valuable; that does not make them mandatory. Their priority belongs to the human operator, and the log says so in plain words.

in.gnu6 is a programme of evidence. To become a dependency you install, it needs an accepted native renderer, a licence, a stable API and a publication — four things it does not claim today.