Gallery home ConduitOS visual journey Follow one ordinary QEMU session from boot, through Body and Play lifecycle, across a hot-plugged Line, and into Tour and Patchbay interaction.
The five-minute path Start with the story; dive into all 42 checkpoints when you want the machinery.
FREESTANDING EMULATOR EVIDENCE, NOT PHYSICAL HARDWARE EVIDENCE. The guest records and acceptance assertions prove the named behavior; these real captured pixels make that proof human-inspectable.
Exact evidence identity Accepted commit: 2aefd591ec7d508689321cd68775c283ccdb8abd · Correlated journey manifest
Checkpoint 1 of 42 · Boot
What you see The native Crèche offers a Body name, a naming tradition, and the locally reviewed keyboard Form. What just happened The image opened the Crèche as its first ordinary product surface. What the harness proves The checked Form was inspected while Body, Wake, Plan, and Play remained absent. Concepts in view Crèche · Host · Form Checkpoint 2 of 42 · Return
What you see The chosen Body is named and its included keyboard Form is listening. What just happened Return accepted the Crèche selection, birthed the Body, then requested Wake, Plan, and Play in order. What the harness proves Separate lifecycle records retain the exact Body, workset, Host, Boot, admitted Plan, and Play identities for each successful stage. Concepts in view Body · Wake · Plan · Play Checkpoint 3 of 42 · F2
What you see The exact-detail inspector lists the operations this running Host currently offers. What just happened F2 advanced through identity and binding details to CURRENT OFFERS. What the harness proves The visible inventory is projected from current Host truth while the same Body, Plan, and Play remain in place; it is not an authored Form claim or a catalog-wide availability promise. Concepts in view Host · offers · inspection · Plan Checkpoint 4 of 42 · F2 / Escape
What you see The same admitted Play is quiescent and awaiting later input after its initial work drains. What just happened F2 opened details; Escape returned input focus to the Form without completing or replacing the Play. What the harness proves Inspection preserves the exact Body, Plan, and Play while structural drain remains distinct from semantic completion. Concepts in view Plan · Play · quiescence · focus Checkpoint 5 of 42 · H E L L O
What you see The presentation shows HELLO while the same quiescent Play remains available for more input. What just happened Five keys crossed the admitted keyboard path, each with a press and release, and continued the existing Play. What the harness proves Every event retains the same Body, Plan, and Play; output is correlated with the port-specific kernel result without claiming completion. Concepts in view Form · Play · quiescence · presentation Checkpoint 6 of 42 · F10
What you see The resident Patchbay presents the active keyboard canvas and its live topology. What just happened F10 opened Patchbay from the running Body without replacing its current Form result. What the harness proves Patchbay projects the same Body, Plan, Play, and resident Form truth rather than fabricating a second runtime. Concepts in view Patchbay · Body · resident Forms Checkpoint 7 of 42 · F11
What you see Patchbay visibly acknowledges an edit request for the current Body. What just happened F11 crossed the ordinary application-action path while Patchbay was selected. What the harness proves The request is correlated with the current Body and remains distinct from topology realization or a new Play. Concepts in view Patchbay · edit request · Body Checkpoint 8 of 42 · F1
What you see Patchbay presents the Body with its newly realized Presenter topology. What just happened F1 requested an ordinary Presenter replan that prepared and started a fresh immutable Plan and Play before replacing the old route. What the harness proves The same Body keeps surviving manifestation continuity while exact Presenter, implementation, Host, Boot, resource, and availability truth comes from the new Plan. Concepts in view Patchbay · Presenters · Plan · Play Checkpoint 9 of 42 · Form switch + F10
What you see The resident Tour Form presents its HELLO result inside the same Body. What just happened The journey selected Tour and ran its admitted action through the shared application path. What the harness proves A distinct resident Form can run and retain output without replacing the Body or erasing the canvas result. Concepts in view Resident Forms · Tour · retained result Checkpoint 10 of 42 · O N E
What you see The resident memory Form is selected and preserves the text ONE. What just happened The journey switched from the initial keyboard canvas Form to the memory lantern Form and typed one bounded value. What the harness proves Form selection, input focus, and retained output are separate from Body identity and Play admission. Concepts in view Resident Forms · focus · output Checkpoint 11 of 42 · Form switch
What you see The keyboard canvas Form still presents HELLO after switching away and back. What just happened The journey returned to the canvas Form after editing the memory Form. What the harness proves Resident Forms retain independent results without turning view selection into a new Play or Body. Concepts in view Resident Forms · retained state Checkpoint 12 of 42 · Backspace
What you see The memory Form remains selected after its value is erased. What just happened Backspace events removed the value previously entered in the memory Form. What the harness proves Edits are scoped to the active resident Form and do not mutate the canvas Form's retained value. Concepts in view Resident Forms · scoped input Checkpoint 13 of 42 · Form switch
What you see Patchbay again presents the keyboard canvas after resident Forms were edited. What just happened The journey returned through Patchbay after changing memory and canvas values. What the harness proves Patchbay projects the current shared Body truth while each resident Form keeps its independently retained result. Concepts in view Patchbay · resident Forms · continuity Checkpoint 14 of 42 · Form switch
What you see The memory Form shows HI while the canvas Form separately retains HELLOXY. What just happened The journey edited both resident Forms, then returned to the memory Form. What the harness proves Each resident Form retains its own typed Port result across selection changes inside the same Body and Play. Concepts in view Resident Forms · Port result · retention Checkpoint 15 of 42 · F8 / F7
What you see The Body is retained and no Play is active. What just happened F8 explicitly stopped the Play; F7 then lulled the Body. What the harness proves Execution stopped without erasing Body or journey identity. Concepts in view Body · Lull · Play Checkpoint 16 of 42 · F12
What you see The product reports one current bounded Line backed by the emulated FTDI USB function. What just happened F12 opened the Line view after QEMU had supplied the separate USB function. What the harness proves Guest records establish the exact controller, endpoints, binding, Host, and Boot; the screenshot only shows their presentation. Concepts in view Cord · Line · ports Checkpoint 17 of 42 · Hello / Ready
What you see The Line view reports that the harness peer completed its bounded greeting. What just happened The peer exchanged the canonical Hello and Ready bytes over the emulated USB device. What the harness proves Bytes crossed the real emulated carrier, while the record keeps connectivity distinct from Body membership or trust. Concepts in view Line · peer · authority Checkpoint 18 of 42 · Value + acknowledgment
What you see HELLO USB LINE is manifested in the guest. What just happened The peer delivered one bounded value and acknowledged the session. What the harness proves Delivery is correlated to distinct Line, binding, Plan, active Play, Host, Boot, and unchanged Body identities. Concepts in view Line · value · Play Checkpoint 19 of 42 · QMP device removal
What you see The product visibly reports that the USB Line has disappeared. What just happened The harness used QMP to remove the separately pinned FTDI USB function. What the harness proves Removal is detected, the stale session is refused, and Body identity remains unchanged rather than turning loss into success. Concepts in view Line loss · stale identity Checkpoint 20 of 42 · F9
What you see The canonical meet-one-gear lesson is open and has not run yet. What just happened F9 opened Tour from the ordinary product after the Body returned to Lulled. What the harness proves The same emulated keyboard and portable action path reaches the shared Tour application without creating a second runtime. Concepts in view Tour · Form · Gear Checkpoint 21 of 42 · F10
What you see Tour displays HELLO from its canonical Form. What just happened F10 ran the lesson. What the harness proves The production kernel result remains correlated to exact source, checked Form, expanded Form, Plan, and active Play identities. Concepts in view Tour · Form · Plan · Play Checkpoint 22 of 42 · Run completion
What you see A separate confirmation surface is visible above the completed Tour result. What just happened The successful run manifested its bounded confirmation transient. What the harness proves The transient has its own surface identity and relationship without replacing the result or becoming application truth. Concepts in view Tour · transient · presentation Checkpoint 23 of 42 · Escape
What you see The confirmation is gone and the retained Tour result is visible again. What just happened Escape dismissed the exact confirmation surface. What the harness proves Dismissal closes only the transient while preserving the underlying result and workspace identities. Concepts in view Tour · transient closure · result Checkpoint 24 of 42 · F3 / F10 / Escape
What you see The second lesson presents MAKE THIS LOUD through the same native Tour workspace. What just happened F3 selected the next exercise; F10 ran its authored Form; Escape dismissed its nonblank confirmation. What the harness proves The shared Tour program retains the exercise-specific source, checked Form, expanded Form, Plan, Play, and result identities. Concepts in view Tour · authored Form · retained result Checkpoint 25 of 42 · F3 / F10 / Escape
What you see The third lesson presents SOS after executing its two-Gear Form. What just happened F3 selected the next exercise; F10 ran it; Escape dismissed the bounded confirmation. What the harness proves Multiple manifestations remain one exact planned application result rather than separate improvised programs. Concepts in view Tour · Gears · manifestations Checkpoint 26 of 42 · F5 / F10 / Escape
What you see The comparison lesson reports that direct and recursive realizations agree. What just happened F5 advanced to chapter two; F10 executed both admitted realizations; Escape dismissed confirmation. What the harness proves The distinct expanded Form and Plan identities are retained while their observable results agree. Concepts in view Tour · comparison · Plan identities Checkpoint 27 of 42 · F5 / F10 / Escape
What you see The finite counter lesson presents 1 and records an explicit stopped terminal outcome. What just happened F5 advanced to chapter three; F10 ran the bounded exercise; Escape dismissed confirmation. What the harness proves Stopping is preserved as its own machine-readable outcome rather than being relabeled as generic completion. Concepts in view Tour · bounded work · stopped Checkpoint 28 of 42 · F5 / F10 / Escape
What you see The first two-host lesson presents hello across one Cord. What just happened F5 advanced to chapter four; F10 ran the planned source-to-sink transfer; Escape dismissed confirmation. What the harness proves Source and sink fragments, active Plays, typed ports, and the exact Line remain distinct and correlated. Concepts in view Tour · two hosts · Cord · Line Checkpoint 29 of 42 · F3 / F10 / Escape
What you see The second two-host lesson also presents hello across one Cord through its own exact realization. What just happened F3 selected the sibling exercise; F10 ran it; Escape dismissed confirmation. What the harness proves The shared application path preserves the second exercise's separate source, sink, Plan, Play, and Line identities. Concepts in view Tour · sibling Form · two hosts Checkpoint 30 of 42 · F5
What you see The native Tour shows the complete fifth chapter page with its beginner-facing explanation. What just happened F5 navigated forward after completing every executable exercise in chapters one through four. What the harness proves A chapter page is retained presentation state, not fabricated execution or an unplanned Play. Concepts in view Tour · chapter · presentation Checkpoint 31 of 42 · F5
What you see The native Tour shows the complete sixth chapter page. What just happened F5 advanced through the same shared Tour program and native presentation implementation. What the harness proves Navigation changes the presented page while preserving the Tour application and Body identities. Concepts in view Tour · navigation · continuity Checkpoint 32 of 42 · F5
What you see The native Tour shows its final chapter page without an empty panel or dialog. What just happened F5 advanced to the final page after every earlier chapter and exercise had been visited. What the harness proves The final page is rendered from the same canonical Tour catalog used by the other hosts. Concepts in view Tour · complete catalog · native presentation Checkpoint 33 of 42 · F6 / F10
What you see Returning to the first lesson preserves its HELLO result and completed state. What just happened F6 navigated back through every chapter; F10 exercised the already-completed action path. What the harness proves Revisiting does not invent a new result or erase the exact identities retained by the original run. Concepts in view Tour · navigation · retained completion Checkpoint 34 of 42 · F10
What you see A distinct refusal surface explains that the completed lesson cannot be run again. What just happened F10 requested Run after the action had become unavailable. What the harness proves The same input path produces a machine-readable refusal rather than a second Play or false success. Concepts in view Tour · refusal · unavailable action Checkpoint 35 of 42 · Escape
What you see The refusal is closed and the completed lesson remains unchanged. What just happened Escape dismissed the refusal surface. What the harness proves Closing presentation state does not erase the refusal record or mutate the completed application state. Concepts in view Tour · refusal · presentation closure Checkpoint 36 of 42 · F11
What you see The shared Patchbay view shows the lesson's Form and retained result. What just happened F11 opened Patchbay inside the same Tour workspace. What the harness proves Presentation continuity uses the shared Patchbay surface and makes no claim that another Play occurred. Concepts in view Tour · Patchbay · ports · cords Checkpoint 37 of 42 · Primary button
What you see The Patchbay chooser transient visibly owns pointer focus. What just happened A primary-button report crossed the emulated USB mouse path into the chooser. What the harness proves Focus belongs to the exact transient manifestation and is distinct from hover, selection, and keyboard focus. Concepts in view Patchbay · transient · pointer focus Checkpoint 38 of 42 · Pointer motion
What you see Patchbay visibly marks the Gear under the pointer. What just happened A relative-motion report moved the QEMU USB mouse onto the Gear. What the harness proves A real emulated xHCI, USB, HID, and portable pointer path produced the correlated hover transition. Concepts in view Patchbay · Gear · pointer Checkpoint 39 of 42 · Primary button
What you see The hit-tested Patchbay Gear is selected. What just happened A distinct primary-button press selected the hovered Gear. What the harness proves The record distinguishes press, selection, and later release while the screenshot documents the resulting manifestation. Concepts in view Patchbay · Gear · selection Checkpoint 40 of 42 · Pointer motion + primary button
What you see The independent Gear inspector visibly owns pointer focus. What just happened Pointer motion and a primary-button press targeted the inspector after selection. What the harness proves The retained routed pointer identity reaches the exact auxiliary surface and stale manifestations remain inadmissible. Concepts in view Patchbay · inspector · routed pointer identity Checkpoint 41 of 42 · Long detail presentation
What you see The focused inspector presents its complete bounded detail text without losing the auxiliary surface. What just happened The native journey retained the focused inspector after rendering a longer detail value. What the harness proves The same production presentation path carries the longer value inside its admitted surface instead of truncating, replacing, or inventing application state. Concepts in view Patchbay · inspector · bounded text Checkpoint 42 of 42 · Close
What you see The Inspector is dismissed and its auxiliary surface is gone. What just happened The journey activated the native Inspector Close control. What the harness proves The retained Inspector surface was removed and input focus returned to the remaining Tour workspace. Concepts in view Inspector · lifecycle · focus 
