Skip to content

Evidence

The useful evidence is available before the recordings are: public source, repository-owned configuration, dated measurement snapshots, reproduction methods, lifecycle boundaries, and essays that explain the operating method. This register separates those inspectable receipts from the recording backlog.

Inspectable now

Source repositories, implementation boundaries, reproduction methods, dated measurements, and four essays are published now.

Recording register

0 published casts. Recording plans remain backlog until a real .cast artifact exists. Planned entries below are not players and make no claim that the session has run.

  1. Planned

    thumos

    Target: kernel boot — qemu-system-arm -machine virt

    Would establish: The same primary qemu-feature build and runner invocation used by CI, with the banner, boot-complete, and service-loop markers observed after a zero exit.

    Would not establish: The complete CI sequence or hardware bring-up on the physical AGM M7. QEMU proves this boot path, not the modem/WiFi/BT/GPS vendor blobs.

    Inspect the planned recording script →

  2. Planned

    aletheia

    Target: disposable boot and health check — public health route and seeded demo-agent registration

    Would establish: A disposable copy of the repository's demo instance passing configuration validation, booting, answering `/api/health`, and exposing its seeded demo agent.

    Would not establish: Memory recall, an LLM response, the TUI, or the desktop app. The plan makes no model-quality claim.

    Inspect the planned recording script →

  3. Planned

    kanon

    Target: lint --fix, then gate — run against the public aletheia repo, not kanon's own source

    Would establish: The standards engine finding and fixing a seeded, explicitly labeled violation class, then running the configured gate against a public repository.

    Would not establish: kanon's own source.

    Inspect the planned recording script →

  4. Planned

    harmonia

    Target: disposable server boot and health check — public /api/system/health route

    Would establish: A real server boot from disposable configuration and SQLite state, followed by the public health route returning its documented `status: ok` response.

    Would not establish: A library scan or import. The current admin-protected `POST /api/library/scan` route returns 202 without performing a scan.

    Inspect the planned recording script →

  5. Planned

    akroasis

    Target: CHIRP import, then vault verify — akroasis radio import / vault identity

    Would establish: Real CLI sessions against the shipped crates: syntonia's CHIRP workflow and kryphos's vault, --json output included.

    Would not establish: Live mesh traffic or radio programming. The mesh CLI is static until daemon mode lands, and radio read/program waits on the protocol session backend. StubHardware is the default; the caption says so.

  6. Planned

    logismos

    Target: CPU golden-fixture parity test — phase_3_stella_parity, against embeddings_dim1024.safetensors

    Would establish: The ignored parity test executing on CPU with `/models/stella-1.5b-v5` available, rather than a zero-test green exit.

    Would not establish: Any GPU run. Phase 4 remains hardware-blocked.

    Inspect the planned recording script →

  7. Planned

    hamma

    Target: handshake + control-protocol type tests — hamma-core, dictyon

    Would establish: The Noise-handshake and control-protocol-type tests passing — modest, explicitly test-suite-shaped, matching where the project actually is.

    Would not establish: Two peers joining a tailnet. The WireGuard data plane is not wired in.

    Inspect the planned recording script →