@readymadeit/mcp 0.0.0-stage → 0.1.0

package/bundle/docs/content/boards/dropitapp-board.md

@@ -0,0 +1,57 @@
+# DropApp
+
+AirDrop, built out of parts: pick an image on a phone, chunk it, upload it to a
+runtime on your own machine, and hand the phone its interface as a QR code.
+
+## What it does
+
+It shows a QR code. Scan it with a phone and you get a picker; choose an image
+and it lands in a `dropitapp` folder on the machine running the server runtime —
+inside the folder that runtime gives boards, `~/.hkp/cpp/files` in the desktop
+app.
+
+## How it works
+
+Two runtimes: a browser one that builds and serves the phone's interface, and a
+REST one that receives the file.
+
+### UI — the browser
+
+1. **Phone Board**, a [Sub-Service](../services/sub-service.md) in `source`
+   mode, *contains a whole second board* called **AirDrop Phone** — an
+   [Image Picker](../services/image-picker.md), a
+   [Chunked File Provider](../services/chunked-file-provider.md) and an
+   [HTTP Uploader](../services/http-uploader.md) pointed at
+   `HKP_RUNTIME_URL/runtimes/upload-server`. That inner board never runs here;
+   it is cargo.
+2. **HTTP Uploader Token Injector** puts the credential the upload will need
+   into that inner board — at hand-out time, so the token is not sitting in the
+   saved document.
+3. [LZ Compress](../services/lz-compress.md) compresses the inner board.
+4. **URL Builder**, a [Map](../services/map.md), wraps it in a playground URL.
+5. [QR Code](../services/qr-code.md) renders that URL.
+
+### Upload Server — a REST runtime
+
+A single [Filesystem](../services/filesystem.md) service in `write` mode,
+writing to `dropitapp`: a relative path, so it lands in the runtime's default
+folder for boards, whichever machine that is.
+
+## Why the phone's board is cargo
+
+The phone is not running an app you installed; it is running a board that this
+board handed it, encoded in the QR code it scanned. The interesting consequence
+is that changing what the phone does means editing the sub-service's pipeline
+and re-showing the code — there is nothing to deploy, and nothing on the phone
+to update.
+
+The chunking matters too: [Chunked File Provider](../services/chunked-file-provider.md)
+breaks the image into pieces so a large photo uploads as a sequence rather than
+one request that may not survive a phone's connection.
+
+## Try it
+
+Open it in the Readymade desktop app: the upload runtime names the app's own
+runtime (`"remote": "embedded"`), and the phone must be able to reach that
+runtime's URL. To save somewhere else, add the folder under *Folders boards may
+use* in the app's settings and type its path into *Save folder*.

package/bundle/docs/content/boards/encrypt-board.md

@@ -0,0 +1,36 @@
+# Encrypt / Decrypt
+
+Two independent runtimes, one encrypting and one decrypting, sharing nothing but
+a passphrase you type into both. The smallest board that shows a runtime is a
+boundary and not just a list.
+
+## What it does
+
+Type text in the Encrypt panel and see the AES ciphertext. Paste ciphertext into
+the Decrypt panel, give it the same secret, and get the text back.
+
+## How it works
+
+Two [browser runtimes](../concepts/runtime.md).
+
+**Encrypt** — [Injector](../services/injector.md) takes the input,
+[Encrypt](../services/encrypt.md) applies AES with the configured secret, and
+[Monitor](../services/monitor.md) shows the result.
+
+**Decrypt** — [Decrypt](../services/decrypt.md) reverses it with its own copy of
+the secret, and a [Monitor](../services/monitor.md) shows the plaintext.
+
+## Why they are separate
+
+Nothing connects the two. The second runtime does not receive the first one's
+output; you carry the ciphertext across by hand, which is the point — it
+demonstrates that the ciphertext is all that is needed, and that the secret is
+configured independently at each end rather than travelling with the message.
+
+Set the two secrets differently and decryption fails, which is the correct
+behaviour and worth seeing once.
+
+## The facade
+
+Two panels, Encrypt and Decrypt, each with a text input for the message, a text
+input for the secret, and a line of text for the result.

package/bundle/docs/content/boards/face-alert-board.md

@@ -0,0 +1,50 @@
+# Face Alert
+
+Watches the camera and sends a push notification when a face appears. Seven
+services and a block, none of which knows what the others are for.
+
+## What it does
+
+Twice a second it looks at the camera. When a face comes into view — not while
+it stays there — it posts a message to an [ntfy](https://ntfy.sh) topic, which
+arrives on your phone. The image never leaves the device; only the message
+does.
+
+## How it works
+
+One [browser runtime](../concepts/runtime.md).
+
+1. A [Timer](../services/timer.md) ticks every 500 ms.
+2. [Camera](../services/camera.md) captures a frame on each tick.
+3. [Detect](../services/detect.md) finds the faces in it with a model shipped
+   with the app, and reports on **every** frame — `count: 0` included.
+4. [Changes](../services/changes.md) watches `params.count > 0` and lets a frame
+   through only when that **becomes true**. This is the step that turns "a face
+   is there" (every frame) into "a face appeared" (once).
+5. [Debounce](../services/debounce.md) holds a 30-second cooldown, so a face
+   that the detector loses and finds again for a moment does not notify twice.
+6. [Map](../services/map.md) writes the message.
+7. The **ntfy notification** [block](../concepts/blocks.md) sends it — the one
+   the build ships in its [preset library](../concepts/presets.md), copied into
+   this board so it opens anywhere. Its topic, title, priority and tags are the
+   block's params, set on its bar; the topic is made at random for this board.
+
+Steps 3 to 5 are the design, and each is a different question: *what is there*,
+*is that new*, *is it too soon*. None of them is specific to faces — the same
+chain turns any repeated report into an alert.
+
+## The facade
+
+What the board sees — the camera's frame with each face it found outlined, the
+`detect` widget — and how many faces are in view. The camera widget is there
+too, drawing nothing (`"preview": false`): it is what captures the frames, and
+the picture worth showing is the one after Detect.
+
+## Try it
+
+Open the board and allow the camera. The ntfy block is given a random topic of
+its own the first time the board opens — anyone who knows a topic on ntfy.sh can
+read it, so a shared default would tell strangers when someone is in front of
+your camera. Copy it from `topic` on the block's bar in the board view,
+subscribe to it in the ntfy app, and **save the board** so it keeps that topic.
+Then look into the camera.

package/bundle/docs/content/boards/game-board.md

@@ -0,0 +1,69 @@
+# Breakout Game
+
+A playable Breakout, split across four runtimes, with a phone as the paddle
+controller. The most elaborate browser-only board here, and the best example of
+services reaching sideways rather than only forwards.
+
+## What it does
+
+A ball, a bar, and bricks on a canvas at 50 frames a second. You control the bar
+with an on-screen XY pad — or by scanning a QR code and using your phone.
+
+## How it works
+
+Four [browser runtimes](../concepts/runtime.md). Three of them are the game; the
+fourth exists to hand a controller to a second device.
+
+### Input
+
+1. [Peer Socket](../services/peer-socket.md) in *Receive only*, registered as
+   `breakout-host`, listening for `breakout-phone`.
+2. [XY Pad](../services/xy-pad.md) — the on-screen control, for playing without
+   a phone.
+3. **Map Input**, a [Map](../services/map.md), normalises whichever arrived.
+4. **Send to Cache**, a [Configurator](../services/configurator.md), writes the
+   position into the `game` runtime's cache. It does **not** pass through: the
+   input chain ends here, having deposited a value somewhere else.
+
+### Game
+
+1. [Timer](../services/timer.md) at 20 ms — the game loop.
+2. **State Cache**, a [Cache](../services/cache.md), holds the world between
+   frames. A pipeline is stateless, so the state has to live in a service, and
+   this is it.
+3. **Game Logic**, a [Map](../services/map.md), advances the world one step.
+4. **Cache Game State**, a [Configurator](../services/configurator.md), writes
+   the new world back — this one *does* pass through, so the frame continues.
+5. [Tracks](../services/tracks.md) draws it: one track for the ball, one for
+   the bar.
+
+### Canvas
+
+[Canvas](../services/canvas.md) draws the frame and reports its size. **Cache
+Size** then writes that size back into the game runtime's cache, but only
+through a [Filter](../services/filter.md) that stops unless the size actually
+changed — otherwise the game state would be rewritten fifty times a second for
+nothing.
+
+### Phone Controller
+
+A [Sub-Service](../services/sub-service.md) in `source` mode holds an entire
+second board — *Breakout Controller* — containing an
+[XY Pad](../services/xy-pad.md) and a [Peer Socket](../services/peer-socket.md)
+in *Send only*. That inner board is
+[LZ-compressed](../services/lz-compress.md) into a URL, which becomes the QR
+code you scan. Open it on a phone and the phone is now the paddle, talking
+directly to the host over WebRTC.
+
+## Why it is built this way
+
+Three of the four runtimes write into the same cache using
+[Configurator](../services/configurator.md) rather than passing values along a
+line. Input arrives on its own schedule, the canvas resizes whenever the window
+does, and the game loop runs on a timer — three rates that do not line up, so a
+single chain could not carry all three. The cache is the shared state and the
+configurator is how a service in one runtime writes to a service in another.
+
+The phone controller is the other idea worth taking away: a board can *contain*
+another board and hand it out as a link. Nothing was deployed to make the phone
+work.

package/bundle/docs/content/boards/game-of-life-board.md

@@ -0,0 +1,47 @@
+# Game of Life
+
+Conway's Game of Life, simulated on an infinite sparse grid, with each
+generation sent down two branches at once: one draws it, the other plays it.
+The same generation becomes a picture and a chord.
+
+## What it does
+
+It runs the cellular automaton and shows the result twice over — as cells on a
+canvas, and as notes from a synthesiser. Watching it and listening to it are
+the same data arriving in two forms.
+
+## How it works
+
+Everything is in one [browser runtime](../concepts/runtime.md). The chain is
+three services deep, and the third one forks.
+
+1. [Timer](../services/timer.md) ticks at 220 BPM, firing immediately on start
+   rather than waiting out the first interval. A beat is the natural unit here
+   because the output is partly music.
+2. [Game of Life](../services/game-of-life.md) advances one generation per tick
+   and emits the live cells. It only simulates — it draws nothing, which is what
+   lets the next step send the same generation two ways.
+3. [Tracks](../services/tracks.md) runs two named branches over that one
+   generation:
+
+   **`visual-branch`** —
+   [Game of Life Renderer](../services/game-of-life.md) turns cells into draw
+   commands at 8 px a cell, and [Canvas](../services/canvas.md) draws them.
+
+   **`audio-branch`** — [Map](../services/map.md) extracts the objects,
+   a second Map enriches them, [Sort](../services/sort.md) orders them by how
+   alive they are, [Limit](../services/limit.md) keeps the top six,
+   a third Map turns those into notes, and [Sound](../services/sound.md) plays
+   them on a sawtooth synth.
+
+The audio branch is worth reading closely: it is a small query. Sort by
+liveness, take six, map to pitch. Six is there because a chord of six notes is
+about as much as the ear takes, and the loudest cells being the played ones is a
+decision expressed as `sort` then `limit` rather than as code.
+
+## Why it is split this way
+
+The simulation and its renderer are separate services on purpose — see
+[Game of Life](../services/game-of-life.md). A simulation that drew its own
+output could not have been sent to a synthesiser without being changed. Because
+it only emits state, the branch that plays it did not have to be anticipated.

package/bundle/docs/content/boards/hacker-news-board.md

@@ -0,0 +1,76 @@
+# Hacker News Reader
+
+Hacker News as an app: the stories on one side, the discussion of the one you
+picked on the other.
+
+## What it does
+
+The buttons along the top pick a list — **Top** (the front page), **New**,
+**Best** (recent stories past 300 points, newest first), **Ask** and **Show**.
+The search field searches every story ever posted, by relevance. A headline
+opens the story; a story without a link of its own (an Ask HN, say) opens its
+page on Hacker News instead.
+
+**N comments** under a story reads its discussion in the right-hand column:
+the post itself where it has text, then the whole thread. On a phone the
+discussion takes the place of the list instead, and back returns to the list
+where you left it. Every reply sits
+under the comment it answers, indented one step further; the top-level comments
+come in the order Hacker News ranks them, and the replies under each in the
+order they were written. A deleted comment keeps its place when it has
+replies, so they are not left under the wrong one. The link under the title
+opens the thread on Hacker News.
+
+**[–]** beside a comment folds it: its replies go, it shrinks to its first
+line, and the next thread moves up — the quick way past a branch that is not
+worth reading. **[+N]** says how many replies it hides and opens it again.
+**Collapse all** folds the thread down to its top-level comments, each one line,
+to open the ones worth reading; **Expand all** puts everything back. What is
+folded is remembered per story, so a thread opened again is the way it was
+left.
+
+## How it works
+
+One browser runtime, nothing to install. It holds three small pipelines, one
+for each thing the facade asks, each a [sub-service](../services/browser-sub-service.md)
+that keeps its result to itself — so opening a discussion does not reload the
+list:
+
+1. **Which list** — a [Map](../services/map.md) holding the five lists, each
+   with the address and parameters that fetch it, and saying which one is
+   picked. The buttons are drawn from it, so the list in force is the one
+   highlighted.
+2. **Stories** — an [http-client](../services/http.md) asking the search API
+   [Algolia hosts for Hacker News](https://hn.algolia.com/api), and three Maps
+   that turn each hit into what a row shows: title, site, points, author, age.
+   Picking a list configures the client with that list's address and
+   parameters and runs the pipeline again.
+3. **Discussion** — a thread asked for twice at once, with
+   [Tracks](../services/tracks.md) running two requests side by side. The
+   facade sends only the story's id; each track makes its own address from it
+   with a Map and hands it to its client as `meta.url`, so nothing is
+   reconfigured per story. Algolia sends the whole thread in one document but
+   lists the comments oldest first; Hacker News's own API sends the story's
+   comment ids in the order it ranks them. The [SQL](../services/sql.md)
+   service puts the two together.
+
+The comments arrive as HTML. A facade's text is plain text, so the SQL
+statement cuts the tags out — a recursive query removing one tag per step until
+none is left — and turns paragraphs into blank lines. Entities such as `>`
+are decoded only afterwards, so a `<` someone typed is never mistaken for a
+tag. The same statement walks the tree of replies depth first, giving each
+comment a sort key made of its parent's with its own place appended — so
+ordering by it puts every reply under the comment it answers — and an indent
+the facade draws as an empty column before the text.
+
+Folding is the one thing the board keeps. Two tables in the browser's SQL
+database hold it: one row per comment someone folded or opened, and one per
+story collapsed as a whole, which a comment's own row overrides. The comments
+query stops walking the tree at a folded comment and counts what it skipped. So
+that folding does not fetch the thread again, the thread is put in a
+[Hold](../services/hold.md) when it arrives: a fold enters the discussion
+pipeline at the statement that records it, and the Hold hands the kept thread
+to the queries after it.
+
+Both APIs answer any origin, which is what lets the browser call them directly.
+Nothing is signed in: the board reads Hacker News and does not post to it.

package/bundle/docs/content/boards/health-log-browser-demo-board.md

@@ -0,0 +1,56 @@
+# Private Health Log (Browser)
+
+[Private Health Log](./health-log-demo-board.md) with the database moved into
+the browser. The same measurements, the same journal, the same charts — and
+nothing to install.
+
+This demo records and displays values. It does not interpret them, recommend
+targets, detect emergencies or replace professional care, a meter, a CGM, or an
+official device application.
+
+## What it does
+
+The **Log** tab takes blood glucose, blood pressure, weight and a daily
+journal; **Trends** draws them as time-series charts; **Your data** shows the
+rows themselves and deletes the ones you select, or all of them. **Generate
+fake data** there writes six months of fictional history to look at, and
+**Export as .sqlite** saves the whole database as a file. Everything you enter
+is still there the next time you open the board.
+
+## How it works
+
+One browser runtime holding the other board's services:
+[SQL](../services/sql.md) for every write and the read at the end, and a
+[sub-service](../services/browser-sub-service.md) whose Monitor shows the event
+each new entry produced. The `sql` service exists in both runtimes with one
+contract, and both runtimes are SQLite, so moving the board meant changing the
+runtime it sits in — and naming the browser's Monitor by its own id — and
+nothing else.
+
+In the browser, SQL runs SQLite compiled to WebAssembly and keeps the database
+in this browser's storage.
+
+The one thing this board adds is the export, first in the pipeline: a
+sub-service holding an SQL service in `export` mode with `format: "sqlite"`
+and a [Download](../services/download.md) that saves what it hands on as
+`health-log.sqlite`. It stops propagation, and nothing enters the pipeline
+above it, so only its own button reaches it — no entry ever passes through.
+
+## What moving it cost
+
+Reach. On hkp-node the history belongs to a runtime you choose — your own
+machine, or a server you can open it from on any device. Here it belongs to
+this browser on this device: another browser, or this one with its site data
+cleared, starts empty.
+
+For trying the board, or for a log you only keep at one screen, that is
+enough — and the export is how the history leaves: the file opens in any
+SQLite tool (`sqlite3 health-log.sqlite`, DB Browser for SQLite), with the
+tables exactly as the board wrote them. To read the same history from your
+phone and your laptop, run [Private Health Log](./health-log-demo-board.md) on
+hkp-node.
+
+## Try it
+
+Open it. The schema is created on first run, and the history is kept in the
+browser's IndexedDB under the database name `private-health-log`.

package/bundle/docs/content/boards/health-log-demo-board.md

@@ -0,0 +1,138 @@
+# Private Health Log
+
+A personal record of blood glucose, blood pressure and weight, kept in the
+board's own SQLite database and shown as both rows and time-series charts. It is
+an example of keeping a usable copy of data on infrastructure you choose while
+still leaving room for separate analytics and notification boards.
+
+This demo records and displays values. It does not interpret them, recommend
+targets, detect emergencies or replace professional care, a meter, a CGM, or an
+official device application.
+
+## What it does
+
+The **Log** tab accepts three measurements plus a daily journal:
+
+- blood glucose in mg/dL;
+- blood pressure as systolic/diastolic in mmHg;
+- weight in kg;
+- free text about meals, drinks, sleep, exercise, symptoms or anything else the
+  person considers relevant that day.
+
+There is one journal row per calendar day. Saving again on the same day updates
+that entry. It is deliberately free text rather than a medical questionnaire:
+the board stores what the person chose to say without interpreting it.
+
+Submitting creates an event id and UTC timestamp in the facade action. Those
+same values travel to SQL and through the post-entry extension point, so a
+downstream board can receive the identity and time of the exact event that was
+stored rather than inventing its own on arrival.
+
+The **Trends** tab reads the complete SQL history into three charts. Blood
+pressure contains two series; glucose and weight each select their own series.
+Hovering a point shows its precise timestamp, value and the journal for that
+day. The journal is joined onto the query result, so the reusable chart only
+needs its generic `contextField` setting and has no health-specific behavior.
+The **Your data** tab shows the underlying records and can delete selected
+events. Selecting one blood-pressure event removes both its systolic and
+diastolic rows. **Delete all entries** empties the log after asking:
+every measurement and every journal entry.
+
+## The services
+
+One REST runtime on hkp-node contains:
+
+1. **Record one value** — stores scalar measurements such as glucose and
+   weight.
+2. **Record blood pressure** — parses one `120/80`-shaped event into two rows
+   sharing an event id.
+3. **Save daily journal** — inserts or updates the free-text entry for the
+   current day.
+4. **After a new entry** — a SubService whose **Entry event** Monitor shows the
+   event available for downstream work.
+5. **Delete selected entries** — removes events selected in the data table, or
+   every measurement when asked to delete all.
+6. **Delete the journal** — removes every journal entry, only when asked to
+   delete all: a selection names measurements, not days.
+7. **Generate fake measurements** and **Generate fake journal** — write six
+   months of fictional history when asked, and nothing otherwise.
+8. **Read personal history** — joins the daily journal onto each measurement
+   and returns the history used by both table and
+   charts.
+
+Every mutation uses `emit: "input"` and ends at the same read query. The screen
+therefore reflects the database after each action rather than maintaining a
+second copy of the history in facade state.
+
+## Analytics and notifications are another board's job
+
+The health log records observations and does not decide what they mean. That
+separation is intentional: a board that graphs personal history should not
+silently become a clinical rules engine.
+
+`After a new entry` is the composition point. Today its Monitor makes the event
+contract visible. An HTTP Client can be placed after it and configured with an
+`hkp-mount://<runtime>/<service>` endpoint belonging to a composed analytics
+board. That other board can aggregate, notify, export or apply user-chosen
+rules without changing data entry or storage here. Journal saves travel through
+the same extension point, which makes a later learning or analysis board
+possible without coupling that work to this log.
+
+Deleting history starts later in the top-level pipeline, so deletions refresh
+the display but do not masquerade as new measurement events.
+
+## Where the data lives
+
+The database belongs to this board on the configured hkp-node runtime. With a
+local runtime, the history stays in that runtime's local SQLite storage. If the
+runtime URL points at another machine, entries are sent to and stored on that
+machine instead. The board does not claim encryption or regulatory compliance;
+ownership still depends on where and how its runtime is operated.
+
+Free-text journals may be more identifying and sensitive than the numeric
+measurements. The demo never sends them to a model by itself; doing so requires
+an explicit downstream board chosen and configured by the person operating it.
+
+Starter rows are synthetic and are seeded once. A marker in the database keeps
+deleted samples from returning after a restart.
+
+## A history to look at
+
+A handful of starter rows says little about how the charts and the table behave
+after months of use. **Generate fake data**, on the **Your data** tab, asks
+first and then writes 180 days of fictional measurements — two glucose readings
+and a weight every day, a blood pressure every other — and a journal entry
+every third day, all counted back from today.
+
+The rows are computed in SQL from the day's number, so the same press always
+produces the same history, and they carry event ids beginning with `fake-`.
+Pressing again adds nothing, because those ids are already there; deleting some
+of them and pressing again brings those back. A day that already has a journal
+keeps its own. Like deleting, generating enters the pipeline after **After a
+new entry**, so several hundred invented rows are not announced downstream as
+measurements somebody took.
+
+There is no button that removes only them. They are ordinary rows, removable
+from the table like any other or with everything else by **Delete all
+entries**, which is the reason to try this on a log that does not hold
+measurements of your own. The starter rows do not come back after deleting
+all: the marker that seeded them stays.
+
+## A query-backed line chart
+
+The line-chart facade widget accepts either one live point or an array that
+replaces its complete history. `seriesField`, `valueField` and `timeField` map a
+board's own query columns onto the chart without requiring a market-price
+schema. `symbol` or `symbols` selects which series a particular chart draws.
+An optional `contextField` adds per-point text to the hover card and
+`contextLabel` names it.
+
+This keeps the SQL result useful to the table and the charts at the same time:
+neither needs a service devoted only to reshaping the other's data.
+
+## Try it
+
+Run hkp-node, keep it under the name `node` in *Manage runtime servers*, and
+open **Private Health Log** from the demo list.
+The initial values are fictional and exist only to make the charts immediately
+inspectable.

package/bundle/docs/content/boards/helloworld-board.md

@@ -0,0 +1,40 @@
+# Hello World
+
+The smallest board that does something visible: a timer ticks once a second, a
+template turns the tick count into a line of text, and a canvas draws it. Three
+services, one runtime, no configuration — the shape of every other board on
+this page, with nothing else in the way.
+
+## What it does
+
+It prints `HELLO WORLD #1`, then `HELLO WORLD #2`, and keeps counting. That is
+all it does, and the point is how little had to be said to make it happen.
+
+## How it works
+
+Everything runs in the [browser runtime](../concepts/runtime.md) — the page
+itself, in the same process as the interface. Nothing here needs a server, so
+nothing here has one.
+
+The order of the three services is the wiring; there are no connections to
+draw.
+
+1. [Timer](../services/timer.md) emits every second. Nothing feeds it — it is
+   one of the services that produce output on their own, which is what gives a
+   board a heartbeat rather than waiting to be poked.
+2. [Map](../services/map.md) receives the tick and reshapes it into a canvas
+   drawing instruction. Its template is a single `text` element whose content is
+   the expression `"Hello World #" + params.triggerCount`, so the count comes
+   from the tick that triggered it rather than from state anybody has to keep.
+3. [Canvas](../services/canvas.md) receives that instruction and draws it,
+   clearing between frames.
+
+Read it as a sentence: *every second, build a line of text, draw it.* That
+sentence is the board.
+
+## Where to go next
+
+[Animate](./animate-board.md) is this board with a moving picture and a GIF
+recorder on the end. [Game of Life](./game-of-life-board.md) keeps the same
+timer-and-canvas spine but splits the output into two branches that run from
+one tick.

package/bundle/docs/content/boards/link-debugger.md

@@ -0,0 +1,31 @@
+# Link Debugger
+
+Three services that turn a shared board link back into the board it encodes. A
+tool for working on Readymade rather than an app built with it.
+
+## What it does
+
+Paste a compressed `?fromLink=…` payload and read the board JSON it contains.
+
+## How it works
+
+One [browser runtime](../concepts/runtime.md).
+
+1. **Compressed Link**, an [Injector](../services/injector.md) in plain-text
+   mode, is where you paste the string.
+2. **Decompress**, an [LZ Compress](../services/lz-compress.md) in `decompress`
+   mode, expands it.
+3. **Board JSON**, a [Monitor](../services/monitor.md), shows the result.
+
+## Why it exists
+
+A board travels as a link: the whole document, LZ-compressed into a URL
+parameter. That is what every *Open in Playground* button on these pages
+produces, and what a QR code shared from the app encodes. When one of those
+links does not load, the question is always whether the payload is wrong or the
+loading is — and this board answers it by showing you exactly what the link
+says.
+
+It is also the shortest demonstration that a board can be a developer tool. The
+same three services in the other direction would make links instead of reading
+them.