@hivecast/demos (1.1.33)
Installation
@hivecast:registry=npm install @hivecast/demos@1.1.33"@hivecast/demos": "1.1.33"About this package
@hivecast/demos
The action-grain prototype in src/catalogue/action-grain.ts also stays
unlisted pending full inference acceptance. Inspired by the Python study's
explicit set/bag action semantics, its Lisp distinguishes three collection
occurrences from two qualified subjects. It compiles a complete proposed batch
before sending owner commands; the model may propose text, while the original
collection supplies every receiver and qualifier. This is useful when the same
document appears in several queues or workspaces and a batch operation should
act once per document. Occurrence-based actions remain a separate valid policy.
tests/action-grain.spec.ts checks public subject-identity parity, both policies
against the real packaged review owner, and refusals before effects. The browser
journey proves the three-editor preview and guarded Stop on a phone; S39's shared
editor journey still passes after sharing its identity reader. The full journey
reached hosted inference but received No provider resolved. Set an explicit
provider, exact override, or principal default. Full posting and draft retention
after inferred proposals are not yet accepted. A configured test identity is
required; this example does not provision a provider or substitute fake inference.
Its test sessions use the existing hosted session API for scoped cleanup.
The remembered-intent prototype in src/catalogue/remembered-intent.ts is
deliberately unlisted until its complete browser path is proven. It joins S38's
actual native-example learner to the existing personal saved-word owner: a word
returns an inert recipe with its purpose and an input placeholder. Discovery
reads those descriptions, actual inference chooses an offered name from a new
intention, and pure Lisp composes a detail sheet and binds a fresh question.
The composed recipe has the same representation and can itself be rediscovered.
One separate kept binder word admits only the declared stock inventory/detail
templates. No evaluator, package loader, index or saved-form contract is added.
tests/remembered-intent.spec.ts proves inert discovery, source round trips,
fresh input substitution and composition. It now saves the actual recipe and
binder through the source Agents service's saved-form RPCs, stops that runtime,
then starts a new runtime and broker on the same temporary SQLite home. The
retrieved words run in a separate evaluator with a different input question;
another person's list remains empty. This uses the existing owner and store,
not a second recipe store. Agents is a test-only dependency of Demos.
The lesson's exact keep/cleanup words also test fresh saves, refusing an existing
name before writing, and releasing only the lesson's successful save. The write
uses let after its guard: internal definitions initialize before body checks.
The corresponding browser journey preserves the complete intended path,
including actual inference and lazy word recall in a fresh secondary Shell.
It requires a home with a running personal saved-word owner. On the current
machine-local non-founder home, hosted system.agents reports tenantOwned: false and refuses saved-form.list as not owned; browser acceptance is not
established, and the prerequisite is an explicit skip. That refusal is not
bypassed. The demo's own kept words are temporary and cleaned up by its run.
S39, One review, two places, shows one live subject in separate working
contexts. Run (demo "S39") with Stream and Demos installed. The complete Lisp
maps two placement definitions into the packaged workshop's ordinary collection:
(map (lambda (place)
(hash-map "key" (car place) "name" (car (cdr place)) "post" "harbour"))
'(("working" "Working notes") ("comparison" "Comparison desk")))
The distinct collection keys open two instances of the same discovered Review view, both pointing at the same qualified post. Write different drafts, then post only the comparison reply: both views show the shared observation while the working editor retains its text and attachment choice. The lesson changes from a feed to horizontal cards and lets you revisit the same live editors. Finish requires posting or clearing remaining drafts. Stop preserves unfinished editors and the workshop instead of deleting their data.
This pattern is useful for a work queue beside an editor, or several tools over
one subject. The placement definitions and choreography live in Lisp; Stream
uses its existing collection and view contracts, and the review actor and view
remain packaged together in Demos. sharedReviewProgram(streamReceiver, workshopReceiver, postKey) exports that exact complete lesson. The workshop
accepts one to four named placements of existing posts and refuses invalid
configuration before opening a session. Data is in-memory in one browser;
cross-user collaboration, durable drafts and federation are outside this example.
Run All labels its script-posted observation; separate drafts are demonstrated
interactively.
Native coverage is in tests/media-review.spec.ts. The real non-founder journey
shared-review-places.journey.spec.ts checks both editors and their DOM identities,
shared replies, independent text and attachment choices, layout changes, guarded
Stop and owned cleanup at phone, portrait and landscape sizes. Source-preview
acceptance does not claim installed delivery.
S38, Learn a UI adaptation from one example, separates a demonstration, a
portable recipe and its live command bindings. Run (demo "S38"), select an
application in the example inventory and choose Cards. The program compares
the same control before and after. It derives a small value containing the
stated intent and table-to-card transition; it captures no actor address, query,
credential or selection. This can automate a presentation preference across
different working inventories without recording a brittle sequence of clicks.
The same recipe is then bound to two controls in another app. The existing compiler previews the exact receiver-scoped commands before sending them. Both controls keep their identities and current choices. Replanning from their fresh card state produces zero commands and preserves a newer selection. Unchanged, replaced, redefined and ambiguous examples are refused before planning an effect.
The complete script is src/catalogue/learned-panel-recipe.ts; its learner and
planner are ordinary Lisp, reusing S22's native panel compiler. The intent is
supplied explicitly and the example admits one native table/card change. This is
mechanical abstraction, not statistical inference or durable intent discovery.
The recipe is kept in this run and can be copied as data. The lesson adds no
evaluator, renderer, package manager or authority. Native interpreter tests in
tests/learned-panel-recipe.spec.ts check fresh binding, typed refusals and
convergence. The corresponding browser journey demonstrates the actual click,
preview, changes and retained DOM identity. Run All labels its scripted example.
S37, Operate a UI through its own contract, opens a separate control desk for a
native inventory that is already in use. Its shared Operations view generates the
items.panel form from the source actor's schema; a stock log observes that same
actor's real selection events. Invalid panels are refused. A valid change keeps
the original actor and selected application. Closing the desk leaves the source
inventory usable. This is useful for building inspectors and temporary command
surfaces for compatible controls without writing a second renderer.
Run (demo "S37") with Explorer and the Operations provider from Explorer Views
installed. The entire copyable script is src/catalogue/control-desk.ts:
(control-desk-form layout control-address parent-address) accepts stack or
split and returns an ordinary app form using shared components. It borrows the
source address, adds no authority, and implements no autonomous policy or durable
event history. app.describe with wait: true waits for addressed sheets to
stand; normal snapshot reads stay synchronous. Run All explicitly labels its
script-selected examples. Homes without a HiveDock use existing page-only apps.
tests/control-desk.spec.ts runs the builder through the real interpreter and
checks both layouts against the native app grammar. ui-control-desk.journey.spec.ts
uses the canonical source and actual Operations form, checks refusal, selection
and DOM identity, observes an event while the desk is in the background, and
closes the desk independently. Source-preview mode loads the real packaged
Operations module and declaration; it does not claim installed delivery.
S36, Find the smallest useful UI change, combines S17's finite UI search with
S22's checked live-control compiler. Run (demo "S36") to select real installed
apps and open windows, compare four presentation candidates, preview the cheapest
legal change and apply it without replacing the controls. Replanning costs zero
commands; a second requirement keeps the latest selection. An impossible request
produces no plan. The program scores small panel vectors first and compiles only
the winner, checking that its predicted cost equals the actual command count.
Cost means commands, not latency; this example admits tables and cards only.
Requirements are explicit Lisp predicates, without inference or a solver library.
Its complete source is src/catalogue/least-change-ui.ts; the shared finite-choice
handler and live compiler are embedded in that copyable program. Native tests
tests/least-change-ui.spec.ts check ranking, changed current panels, convergence
and impossible requirements in the actual interpreter. The browser journey
least-change-ui.journey.spec.ts runs the same canonical source through the real
Shell, uses actual controls, preserves document identity and newer selections,
and records the teaching stops. A home without its own HiveDock uses the Shell's
existing page-only app mode; the demo does not claim durable workspace saving.
S91, Reopen a held workspace, is the executable manual for checked saved-graph reopening.
Run (demo "S91") in a separate Shell session with Explorer and Canvas closed. Its canonical
program (src/catalogue/held-workspace.ts) creates those views, saves their graph, closes only
the original occurrences, and checks that the same graph reopens fresh occurrences. It removes
its own graph and leaves the reopened tools available. Exact source generation, installation,
module and effective-byte checks refuse changed sources; a saved reference grants no permission.
The browser journey held-graph-reopen.journey.spec.ts also tests real taskbar composition and
page reload. Explicit pin/unpin and composition-owned temporary view reclamation remain F2 work.
S90, Release your temporary interest, is the executable manual for the existing
container's new retention/v1 operations. It creates one real saved definition in this
secondary screen, borrows its source-qualified reference, retains two independent scopes,
checks deletion and stale-fence refusals, releases each scope with duplicate acknowledgement,
and removes only its own definition. Cleanup is registered before retaining. The five-minute
deadline bounds an interrupted example; existing application state and other scopes are
untouched. A retained definition is distinct from a durable pin and a live actor/process lease.
The owner admits identity; a reference and a supplied holder grant nothing. The lesson prints
the actual owner scope and counters, and explains incomplete/global observations.
Its canonical source is src/catalogue/retention.ts; node --import tsx --test tests/retention.spec.ts executes that exact program against Core's actual container owner.
tests/browser-regression/journeys/temporary-retention.journey.spec.ts runs it in the Shell.
Core's container-retention.spec.ts covers hostile callers, independent scopes, collection
action parity, qualifiers, expiry and replacement fences. This slice does not implement a
distributed collector, dependency reactivation or pin/reload recovery; those have separate
managed-lifetime work orders.
The demos are an application of their own (founder, 2026-10-19: "demos should be demos; they are their
own application that has many actors in it"). Its root is the Demos keeper: the catalogue as a
collection/v1 of families and demos, and under it an actor per demo that answers reference.demo/v1
with what the demo is for, what you do, what it proves, and the Omega program that shows it. The Demo
tab is this package's view, published in matrix.package.json (browser.views), so any explorer that
picks a demo shows it. The package's own page hosts the one explorer (mx-explorer) over its Demos
workspace and, beside it at <page>.driver, the demos' driver (demos.driver/v1: driver.aim,
driver.open, driver.press, driver.describe). (demo "J1") in the Shell bar opens this page; the
driver picks the demo's row with its Demo tab and turns each press of the running program into
explorer/v1 operations over the bus. The Chat press is said to the keeper of the person's
conversations (system.agents), and its answer is heard as that keeper's activity.
The example estate the demos are tried on (src/estate/) is under the keeper at applications.demos.estate
(EstateThing): made-up machines, HiveDocks, agents, a catalogue, a shelf, an archive, a ticker, a job board,
a delivery feed and a REST thermostat served on this machine (hence network: true), each an example actor
that keeps what it is told in memory. It answers program.evaluate and program.run over its own things,
and its keeper of saved graphs is applications.demos.estate.saved.
The catalogue (src/catalogue/) and estate moved here from the retired Reference Explorer. Demos owns
both; its page uses the shared Explorer, and the Shell owns execution presentation. Other explorers can
discover the published Demo view and route Run program to this application without carrying another player.
Functional requirements are executable Lisp lessons — founder, 2026-10-21
The founder requires a Lisp/Omega demo whenever a functional requirement is delivered, in this existing Demos application, and asks to use suitable demos as walkthrough tests because Lisp is the platform's shell scripting language. This applies to new or materially changed functional behavior; it is not an instruction to rewrite every old unit test before delivering the requested feature.
Keep one canonical program per scenario in src/catalogue/, supplied by demoProgram(demo). A person
runs that program from Demos/the Shell, and automated acceptance executes the same program through the
ordinary interpreter and owner-operation path. Do not maintain a second fake implementation, separate
JSON script or recursive shell.bar.say playback for tests. Reuse lesson, shared execution presentation,
cleanup and workflow/effect owners. Allocate unused catalogue IDs from current main.
Each requirement links to its demo and semantic walkthrough test. Show the actual before state, owner
operation/receipt, and after state or typed refusal. Assert the promised behavior: merely opening a page,
printing success, accepting an RPC or displaying a screenshot is insufficient. Catalogue status stays
honest: planned until implemented; estate describes example-estate-only coverage; runs needs its real
walk. An in-memory estate does not prove durable transactions or restart recovery.
tests/demos.spec.ts already compiles runnable entries with the canonical Omega compiler, checks their
lesson/presentation and the 16,384-character program bound, and checks that runnable entries name an
existing walk. Extend the existing every-demo-shows.journey.spec.ts path and add focused assertions where
needed. Native/headless tests may execute the same program with real isolated owners. Browser acceptance
also proves discovery, interaction and the visible result. No new general test framework is required.
Move scenario-style unit/integration tests into this shared-program form when the same assertions and failure detection remain covered. Keep focused parser, state-machine, authorization, idempotency and clock tests. Keep real multi-process crash and multi-session storage tests where those are the guarantee. Fake clocks do not prove crash recovery; browser screenshots do not prove isolation. Fault injection stays inside authorized isolated test infrastructure. Cleanup uses owner operations and must not hide a failed rollback, erase unresolved prepared work or alter a user's real state.
Performance work should also have useful demos where behavior/counters can be exercised: parallel owner queries, selective refresh, control responsiveness during heavy work, event-driven idle/recovery, and local versus multi-owner commit. Measure actual counters and equal correctness/durability contracts; report regressions. Retain native/CI benchmarks for host/build-only changes rather than inventing a UI or production authority solely for a demo.
S30: run a repository-selected Fleet ticket through its owners
S30 is the one canonical Fleet program; repository onboarding extends it rather
than creating another resolver or lesson. Its source generator is
fleetWorkflowProgram(routeOwner, ticketOwner, ticketId, advance, filing, discovery). Existing explicit-owner calls remain unchanged. For repository-first
use, leave routeOwner and ticketOwner empty and supply the final non-secret
discovery value with exact repository, admitted program, and workload
coordinates selected by the installed hivecast fleet inspect/join/eligible
commands. Those native trust, sign-in, credential and checkout operations remain
outside an already connected Shell.
The program queries only this home's Registry for smithers.fleet-route/v1 and
requires exactly one exact-home owner whose fleet.route.describe repeats all
three coordinates, names its own route, and proves that discovery performed no
claim and did not treat the joining checkout as the worker. An absent optional
mounted-subject identity is tolerated for the legacy Registry row; a present one
must match the home and mount. Empty, incomplete, refused, cross-home or
ambiguous results stop before Tickets claim or worker start. Successful discovery
defaults only the well-known central Tickets owner for this same home, reads the
selected case and admitted recipe, and still reaches fleet.route.run only after
the person chooses Continue ticket. Closing the confirmation keeps the same
central case open.
Expected output names the verified route and coordinates, the owner-backed
ticket/selection/progress, and—only when central Tickets is closed—its retained
candidate, combined, served and target evidence. Reopen with advance=false to
observe the same retained operation; do not file a replacement. S30 creates no
private scheduler, polling loop, credential, broker, repository checkout or
disposable server, so there is no lesson-owned infrastructure cleanup. The
catalogue remains planned until installed Demos/Explorer success, refusal and
reconnect walks pass against real owners.
For the transaction/recovery continuation, see the active work item and technical design. Long workflows may contain short transaction steps. Lesson breakpoints, person approval, LLM work and installs must stay outside prepared transactions. This policy adds acceptance obligations; it does not claim those transaction demos or the runtime feature already exist.
Package-owned help, examples and lessons — ordered integration, 2026-10-22
The Shell-then-Omega priority list
includes a package-content feature.
It is open/unclaimed, not an existing dynamic contribution API. Current built-in demos continue to use
src/catalogue/; the integration must expose package contributions through these same Demos collection,
reference.demo/v1 and execution paths. Do not create a second catalogue authority or player.
A package should ship versioned help topics, explanations of practical use, executable example/demo source, requirements, expected outcomes and cleanup. Help and examples must be inspectable without evaluating library code. An explicit Run performs the real operation. One source asset may serve a help example, a demo and its semantic test; adapters reference it rather than copy its logic. Tests use the existing native/browser runners and assert actual output/owner state/refusal. Test dependencies and secrets are not runtime content. Install/update/remove changes discoverability through existing package owners; running/pinned programs retain their correct artifact identity.
Every earlier feature in the sequence still supplies its own current help/manual, useful lesson and
same-program test when delivered. General package aggregation is not a reason to postpone them. A
feature's work order links requirement → canonical source → semantic test, and the lesson explains what
the feature is for before demonstrating it. Preserve the existing planned/estate/runs distinction.
Transactions and performance as executable documentation
Run (demo "S24") in the Shell for a durable two-owner transfer, same-identity query/retry,
ordinary-write conflict, abort and restoration. It uses the exact TRANSACTION_PROGRAM exercised by
tests/transactions.spec.ts and durable-transactions.journey.spec.ts. Example balances are made up;
their SQLite state, prepared intents and coordinator decisions are durable under the Demos installation's
declared data/demos/transactions path. Missing durable storage refuses; it never selects an in-memory store.
Run (demo "S25") for real host/runtime CPU, RSS, PID grouping, event-loop delay and interval history. The physical-process table lists every logical member sharing each PID, so split cohorts remain visible instead of being hidden by one group name.
Both lessons use (request owner "operation" "field" value ...): the result contains outcome and the
actual typed reply in value. This uses the ordinary door, caller admission, scope and message budget.
Reply data is transient; retained request receipts contain metadata. ask and tell retain their existing
receipt behavior. (help "request") is the in-platform reference.
| Job | Executable entrypoint | What the number means |
|---|---|---|
| Parallel independent requests | (demo "S12") |
Ordered real receipts from a bounded parallel scatter, retaining refusals and silence |
| Selective UI changes | (demo "S22") |
A previewed plan changes existing controls, preserves selection and converges to zero commands |
| Latest runtime costs | (request dock "runtime.stats") |
Bytes, CPU percent, sample time and loop delay; count shared PIDs once per host |
| Runtime history | (request dock "runtime.stats.history" "runtimeId" id "window" 60000) |
Existing bounded samples, not a new polling loop |
| Machine history | (request dock "host.stats.history" "window" 60000) |
Machine totals; avoid summing the same machine once per HiveDock |
| Handler counts/times | (request actor "$counters" "limit" 50) |
Process-level actor table; grouped actors share a process |
| Full environment census | node tools/fleet/runtime-footprint.mjs |
Own checkout's declared environment; includes process/swap accounting beyond runtime rows |
| Qualified idle cost | node tools/fleet/runtime-cost.mjs |
60-second read-only census with browser/PID/broker continuity and eligibility |
| Matched transaction costs | pnpm --dir applications/demos bench:transactions --samples 200 |
Independent owner processes, real NATS, disk-backed durable stores and conserved balances |
| Crash recovery | pnpm --dir applications/demos test:transactions |
Canonical Omega semantics plus real coordinator/participant kills and durable effect counts |
| Build freshness | node tools/build/refresh-stale-bundles.mjs --package @hivecast/demos --json |
Owning source/dependency hashes against built bytes; add --fix for the existing incremental repair |
The native benchmark compares the same conserved transfer and readback through a local owner, an explicit one-participant coordinator, and two independent participants. It reports p50/p95/p99 with sample counts, throughput, unrelated-control latency, actual committed write-transaction counters, messages/bytes, worker CPU/RSS, event-loop delay, physical write bytes and PostgreSQL WAL bytes. Cold environment/worker readiness and a separate 10-second instrumented fixture idle sample precede warm requests. This idle sample is not the whole-platform 60-second qualification. The benchmark also exercises contended and disjoint resources. Its JSON states hardware, durability and measurement scope; worker CPU/RSS exclude the database and broker; interpreter and browser presentation are also outside this native benchmark. These single-host measurements do not predict cross-host latency. Use the local owner operation when one owner holds the invariant: forcing that case through a distributed coordinator pays for prepare, decision and settlement unnecessarily.
The shared implementation is TransactionCoordinator with TransactionJournal and explicit participant
ports; domain owners keep admission and business validation. The PostgreSQL and SQLite adapters stage
private intents in each owner's store and retain a read/write barrier until the coordinator records every
participant finalized. A timeout is unknown to the caller. Query/recover the same context; never create a
fresh attempt while an old one may commit. Recovery excludes a live driver. SQLite driver locks are per
durably registered transaction identity, released by the OS on process death, with file count bounded by
retained journal entries. Do not unlink live driver files.
transaction.receipts pages the durable journal, including attempts whose caller disappeared. The stock
Durable decisions collection shows the same records and participant references; ledger.status reads an
individual participant's protocol state without exposing private values or bypassing the ordinary-data
barrier. Demos captures pending records at startup and starts one recovery pass after its actors are ready.
transaction.recoverPending starts another pass when an absent participant returns; its acknowledgement
means work started, and the receipts remain the source of commitment and settlement.
This first scope is serializable declared owner resources within one authority root, up to eight
participants, 64 KiB values and 10,000 retained entries per store owner. Enrollment is sealed before
prepare; different payloads/fences/generations under an existing identity refuse. The coordinator keeps
metadata, not private state. There is no ambient transaction around arbitrary ask, no cross-root
transaction, and no rollback of LLM, human, install or external physical effects. Multi-owner projections
are not atomic read snapshots. Authority is checked by the existing owner before preparation; preparation
admits only the exact effect. Revocation before preparation refuses admission; this first scope admits the
exact prepared effect until decision, rather than continuously reauthorizing inside the prepared interval.
After a durable decision, recovery finishes that effect rather than admitting
a different business request. The public example ledgers confer no authority over product state.
The real product integration is InstalledConfigurationClient.patch(changes) / preferences.patch.
An exact installed target and every field's current qualified revision are required. The existing owner
validates every schema and installation binding, then one SQLite transaction compares and writes the
entire batch. It publishes the existing invalidation only after commit. Unsupported stores refuse with
PREFERENCE_ATOMIC_PATCH_UNSUPPORTED. Provider credentials retain their current encrypted local owner.
The PostgreSQL adapter uses durable logical intents, not native PREPARE TRANSACTION. The audit outbox
uses its existing JSON envelope and table for private reservations, so existing owner schemas need no
migration. Prepare exposes no deliverable audit event or wakeup; committed notifications retain the
existing durable replay path. system-audit's transaction-outbox.spec.ts checks capacity refusal before
the commit decision, abort release, partial finalization and stable-event replay.
Owner adapters may supply local/prepare/commit/abort effect hooks. Prepare must durably reserve every
constraint needed for commitment in the same database transaction as the private intent. The audit outbox
reserves its bounded slot without notifying or publishing; commit promotes that exact event, and abort
releases it. A plain local callback remains available for one-owner changes but refuses joined prepare
with TRANSACTION_EFFECT_NOT_PREPARABLE. Arbitrary SQL callbacks and external side effects are not
a promise of distributed rollback.
Run (demo "S26") to inspect actual Task-journal recovery state. It reads the
installed coordinator's Task-owner mount, durable cursor and cached journal
head; it creates no Task and starts no coding worker. A missing installed owner
is shown explicitly. Its estate status means the crash is proven in the native
fixture, rather than induced in this home. Run
pnpm --dir applications/smithers test:recovery for producer-only SIGKILL,
consumer restart, lost/duplicate wakeups, backlog, same-identity retry and idle
probe checks with independent processes, private NATS and durable SQLite. The
same canonical Omega diagnostic program runs against those owners. Host fault
injection remains native-only.
Measured transaction costs
On 2026-10-21, the command above ran 200 warmed transfers per path on a four-vCPU AMD EPYC-Milan host with 16 GB RAM and Node 22.23.2. Each transfer conserved the same two balances and read them back. SQLite used WAL/FULL; PostgreSQL used separate coordinator/participant databases on a disk-backed cluster with fsync and synchronous commit enabled. These are same-host observations, not a cross-host forecast.
| Store | Path | p50 / p95 / p99 ms | Transfers/s | Durable write commits/transfer | Published messages/transfer | Node CPU ms/transfer | Control p99 ms |
|---|---|---|---|---|---|---|---|
| sqlite | Local owner | 1.973 / 4.157 / 8.132 | 415.14 | 1 | 4 | 1.574 | 5.335 |
| sqlite | One participant + coordinator | 10.633 / 16.335 / 22.939 | 87.64 | 6 | 18 | 9.014 | 2.112 |
| sqlite | Two independent owners | 13.774 / 20.182 / 29.648 | 67.78 | 9 | 33 | 14.547 | 1.917 |
| postgres | Local owner | 5.468 / 10.969 / 16.134 | 158.42 | 1 | 4 | 3.414 | 2.834 |
| postgres | One participant + coordinator | 23.069 / 46.248 / 53.129 | 38.37 | 6 | 18 | 12.837 | 3.435 |
| postgres | Two independent owners | 30.376 / 57.707 / 72.577 | 29.25 | 9 | 33 | 21.762 | 3.823 |
The local owner retains the fast path. Two-owner commitment pays for durable prepare, decision, finalization, settlement and clearing the visibility barriers; it increases latency, traffic, writes and Node CPU. The product preference patch stays in its existing owner's single SQLite transaction, without a distributed journal. The table does not benchmark preference-schema validation or audit publication throughput. Published-message counts include the control probe and its reply; a write commit is an acknowledged database transaction, not a physical fsync count.
Both stores committed all 20 attempts on disjoint declared resources. Under 20 hot-resource attempts, SQLite committed 10 and aborted 10 with TRANSACTION_IN_DOUBT. PostgreSQL committed 6, aborted 2 (RESOURCE_BUSY / IN_DOUBT), and refused 12 RESOURCE_BUSY before starting a transfer. There is no automatic retry queue; contention is a real throughput tradeoff. Ordinary calls retain the same visibility barrier.
The separate first 10 seconds without business requests recorded zero intent/decision writes and 0.5 published messages/s for each three-process fixture. SQLite workers used 334.689 ms CPU and 426,147,840 bytes RSS; PostgreSQL workers used 411.540 ms CPU and 398,086,144 bytes RSS. This includes post-startup runtime work and diagnostic sampling, excludes database/broker CPU/RSS, and does not establish a steady-state or whole-platform idle budget. Individual worker readiness took 555–776 ms.
Active worker RSS rose from 448,299,008 to 476,348,416 bytes on SQLite and from 417,484,800 to 457,068,544 on PostgreSQL across the sequential modes. Retained receipts and warmed caches/JIT accumulate: these snapshots are not a per-transfer allocation measurement. For 200 local/two-owner transfers SQLite worker physical writes were 4,972,544 / 25,989,120 bytes; PostgreSQL WAL advanced 237,032 / 1,379,344 bytes. PostgreSQL's zero Node-process physical-write counter excludes its actual database-server writes; it does not mean zero disk I/O. Re-run the JSON-producing command for current numbers, startup timings, all counters and contention outcomes.
pnpm test serializes Demos test files because they boot complete private runtimes. Crash workers
acknowledge their configuration listener before setup and retain startup phase diagnostics inside the
existing five-second budget. The crash tests measure the recovery request after driver exclusion;
failure detection and the lost caller's timeout are separate from that recovery latency.
Illustrated review and field notebook
S35, Images, replies and usable software, is a small reusable archetype for a
visual critique or a field notebook. Run (demo "S35") with Demos, Stream and
Explorer installed. Its full program is
src/catalogue/media-review.ts. The program
performs the operations and supplies the narration and breakpoints; the view
does not contain a second lesson runner.
The Demos page contains an ordinary MediaWorkshopElement actor named
media-workshop. media-review.begin chooses review or field-notes and
returns its actual qualified collection source, post keys and run id. An optional
tool is a real installed application row read from Registry; its standard
Application view still resolves against the admitted catalogue. posts is the
Stream source. replies, with a post key as parent, is the related collection.
Both use the existing container implementation for paging and search.
The reference.media-review/v1 Review facet is declared in this package's
manifest, registered from its browser module and found by Explorer. It draws the
same packaged image data as the existing image.read/v1 Picture view. Posting
uses the ordinary command bus. A reply retains the exact post reference and an
optional attachment reference {authorityRoot, mount, qualifier} from the
workshop's image library. A foreign or unknown attachment is refused before any
reply is written. Owner events update the replies without replacing a person's
textarea. An unsent draft prevents silent closure.
Reuse the exported mediaReviewProgram(streamReceiver, workshopReceiver, 'field-notes') from @hivecast/demos/catalogue, or copy its complete
media-review-tour Lisp function and change the variant. The same function
accepts explicit actor receivers or discovers the installed pages. The generic
Stream has no media-specific branch: stream.layout switches between deck and
feed; the real application document and image reply draft stay alive. Custom
views and images ship in this package rather than inlined lesson HTML.
The walkthrough reads Stream’s existing close guard before releasing the workshop,
then closes its view as its last context-changing operation;
an unsent draft keeps both alive. media-review.end {runId} releases only that workshop session. A different run
id cannot remove the current review; repeated cleanup is safe. Replies are
bounded to 32 and text to 500 characters. These are in-memory example
guarantees: closing the containing page loses its replies. The two images are
deterministic packaged illustrations. No camera recording, file upload,
production video playback, social identity or durable attachment service is
claimed. Still-image cards run no player or offscreen playback timer. Installed
interactive apps keep their ordinary lifecycle.
pnpm --dir applications/demos exec tsx --test --test-concurrency=1 tests/media-review.spec.ts tests/photos.spec.ts tests/manifest.spec.ts
HIVECAST_BASE_URL=<local-Shell-source-preview> HIVECAST_STREAM_SOURCE_PREVIEW=1 HIVECAST_PROOF_IDENTITY_FILE=<non-founder-identity-file> pnpm --dir tests/browser-regression exec playwright test journeys/shell-media-replies-archetype.journey.spec.ts
The explicit source-preview test composes the actual built public browser modules in an admitted non-founder page. Its actor messages, collections, discovered facets, command bus and installed app delivery are real. It does not claim publication or staging installation of those source modules.
Dependencies
Dependencies
| ID | Version |
|---|---|
| @open-matrix/contracts | 1.1.33 |
| @open-matrix/conversation | 1.1.33 |
| @open-matrix/core | 1.1.33 |
| @open-matrix/dashboard-components | 1.1.33 |
| @open-matrix/explorer | 1.1.33 |
| @open-matrix/hivecast-brand | 1.1.33 |
| @open-matrix/omega-core | 1.1.33 |
| @open-matrix/system-sqlite | 1.1.33 |
Development Dependencies
| ID | Version |
|---|---|
| @matrix/test-utils | 1.1.33 |
| @open-matrix/agents | 1.1.33 |
| @open-matrix/hive-pm | 1.1.33 |
| @open-matrix/package-runtime | 1.1.33 |
| @open-matrix/system-platform | 1.1.33 |
| @open-matrix/system-postgres | 1.1.33 |
| @types/node | ^25.0.10 |
| @types/pg | ^8.11.10 |
| esbuild | ^0.27.3 |
| linkedom | ^0.16.11 |
| nats | ^2.29.3 |
| pg | ^8.13.0 |
| tsx | ^4.21.0 |
| typescript | ^5.7.0 |