@readymadeit/mcp 0.0.0-stage → 0.1.0

package/bundle/docs/content/board-json.md

@@ -0,0 +1,277 @@
+# Board JSON
+
+Every board is a single JSON document — readable, diffable, and the whole of what a board is.
+
+---
+
+## The shape
+
+Two keys carry a board, and they are the two the loader actually insists on
+(`isBoardDescriptor` checks for these and nothing else):
+
+| Key | |
+|---|---|
+| `runtimes` | an ordered array of execution environments. **Order is the chain**: the result of one becomes the input of the next |
+| `services` | a map from runtime id to that runtime's ordered service list. **Order is the pipeline** |
+
+Everything else is optional:
+
+| Key | |
+|---|---|
+| `boardName` | display name |
+| `description` | a sentence about the board, shown where boards are listed |
+| `facade` | the app-like surface of widgets drawn over the board |
+| `unit` | what this board imports and exports, if it is used as a unit |
+| `units` | the boards this one is assembled from → `concepts/units.md` |
+| `blocks` | services defined once and used by reference wherever a pipeline names them → `concepts/blocks.md` |
+| `assets` | content — a page, a script, an image — declared once as descriptors and named from service state as `hkp-asset://<id>` → `concepts/assets.md` |
+| `registry` | what a runtime reported it could build. Written by machinery, not authored |
+
+```json
+{
+  "boardName": "My Board",
+  "description": "optional, shown in the board list",
+  "runtimes": [ /* runtime descriptors, in chain order */ ],
+  "services": {
+    "<runtimeId>": [ /* service instances, in pipeline order */ ]
+  },
+  "facade": { /* optional */ },
+  "units": [ /* optional */ ]
+}
+```
+
+There is no version field and no schema URL. A board is read by the code that
+holds these types (`hkp-frontend/src/types.ts`), and unknown keys are carried
+along rather than rejected.
+
+---
+
+## Runtime descriptor
+
+```json
+{
+  "id": "my-runtime",
+  "name": "My Runtime",
+  "type": "rest",
+  "url": "https://server.example.com",
+  "color": "#7c3aed",
+  "state": { "minimized": false, "wrapServices": true }
+}
+```
+
+| Field | |
+|---|---|
+| `id` | **required.** The stable key everything else in the document uses — the `services` map, mount references, the chain |
+| `name` | **required.** A display label, and what `processRuntimeByName` matches |
+| `type` | **required.** `browser`, `rest` or `graphql` |
+| `url` | for a remote runtime: an address the person wrote |
+| `remote` | for a remote runtime: the **name** of a runtime server, looked up among the remotes the client opening the board keeps |
+| `color`, `bundles` | presentation, and plugin libraries to load. Beside `state`, not inside it |
+| `state` | per-runtime settings — see below |
+
+**Two older spellings still load**: `realtime` means `rest` and `remote` means
+`graphql`. Boards in the wild carry them, so anything comparing a type should
+compare canonical forms (`toCanonicalRuntimeClassType`).
+
+A remote runtime carries **exactly one** of `url` and `remote`. Both is an
+error, not a preference: a name resolves differently for each
+person, so a board that could fall back from a name to an address would give
+whoever wrote it two attempts at making a client dial something. A board with a
+`url` and nothing else is valid forever — nothing here asks an existing board to
+change.
+
+Three names are the same in every board that uses them: `embedded`, the hkp-rt
+the Readymade app that opened the board embeds, and `node` and `python`, the
+hkp-node and the hkp-python the person opening it keeps under those names. A
+board meant to be handed on uses them rather than an address, which is one
+person's → `concepts/remotes.md`.
+
+The address a `remote` resolves to is **never written into the
+document**. It lives with the running board on the client that resolved it, and
+a save writes the name back → `concepts/remotes.md`.
+
+A `url` need not be a plain address:
+
+- `HKP_RUNTIME_HOST` is substituted at load, for boards written before the host
+  is known;
+- `hkp://remotes/<name>` addresses the runtime the app itself embeds →
+  `concepts/runtime.md`. It is a name in a url's clothing — the spelling from
+  before `remote` existed — and counts as one: it cannot sit beside a `remote`.
+  It names one app's runtime by that app's name for it; a board meant for
+  whichever app opens it says `"remote": "embedded"` instead →
+  `concepts/remotes.md`.
+
+`state` holds what the runtime remembers between loads: display preferences like
+`minimized` and `wrapServices`, and — once a board is deployed and logging is
+switched on — `logging`, `logLevel` and `logData` → `concepts/logging.md`.
+
+---
+
+## Service instance
+
+```json
+{
+  "uuid": "timer-svc",
+  "serviceId": "hookup.to/service/timer",
+  "serviceName": "Timer",
+  "state": {
+    "periodic": true,
+    "periodicValue": 300,
+    "periodicUnit": "ms",
+    "running": true
+  }
+}
+```
+
+| Field | |
+|---|---|
+| `uuid` | **required.** Unique *within its runtime* — see below |
+| `serviceId` | **required.** What the runtime looks up to build the service |
+| `serviceName` | **required in practice.** A display label with no effect on behaviour |
+| `state` | whatever the service last reported |
+
+A `sub-service` reports two further fields, which is what makes it a
+**scope** (`concepts/scopes.md`):
+
+| Field in `state` | |
+|---|---|
+| `stopPropagation` | whether what its pipeline produced leaves the service. Absent means `false` |
+| `scope` | what the services inside can see — today `{ "slots": "own" \| "inherit" }` |
+
+Both are reported even at their defaults, so a saved board says outright what
+each scope does with its answer and its cells rather than leaving a reader to
+infer a boundary from what follows it.
+
+### The uuid is scoped to its runtime, not the board
+
+Two runtimes may each hold a service called `intake`; that has always been
+legal, and composing boards from units depends on it — a unit contributes whole
+runtimes, and its service uuids are never rewritten because the runtime already
+scopes them (`concepts/units.md`).
+
+The consequence: nothing addresses a service by uuid alone. A facade widget, a
+mount reference, a configure call — each names the runtime and the uuid
+together.
+
+### A service inside another is addressed by the path to it
+
+A `sub-service` holds a pipeline of its own, and what is in it is not in the
+runtime's list. Those services are named by the path through the services
+holding them, dot-separated:
+
+```json
+{ "serviceUuid": "list.kept-articles", "path": "rows" }
+```
+
+`serviceUuid` is the address and `path` is still the field inside that service's
+state, so the two stay separable however deep the nesting goes —
+`read.list.feed-doc` is three services, not a field called `list`.
+
+The separator is a dot because a service address is carried in a URL path
+segment, which a slash would split — the same constraint that decided the
+separator between a unit's name and its runtime ids (`concepts/units.md`).
+
+A flat uuid is always tried first, so a board whose service uuid happens to
+contain a dot goes on meaning that service. See `concepts/scopes.md`.
+
+### An entry may name a block instead
+
+Anywhere a service instance may stand, a **use** of one of the board's `blocks`
+may stand instead — an entry with `block` and no `serviceId`:
+
+```json
+{ "block": "note", "instanceId": "kick", "params": { "trigger": "kick" } }
+```
+
+Opening the board expands it into the service the block defines, and saving
+writes it back as it is written here. → `concepts/blocks.md`
+
+A use says nothing but `block`, `instanceId` or `uuid`, `serviceName` and
+`params`; an object saying anything else is data. Below a runtime's own list —
+where a service may hold arrays of data of its own — entries are read as uses
+only in a document that defines blocks, so a board without any opens with its
+services' state untouched.
+
+### `serviceId` is the one that matters
+
+It is what the registry resolves. When a board names an id the registry no
+longer has, the service is not built: the board still opens, looking fine, minus
+a piece. That failure is quiet enough that two test suites exist to catch it →
+`testing.md`.
+
+`serviceName` exists so the JSON reads without consulting a registry. Renaming
+it changes nothing.
+
+### `state` is a report, not a form
+
+A service's state is what that service last said about itself, which means it
+holds both what you configured and anything the machinery wrote there. Keys
+beginning `__hkp` are reserved for that machinery — `__hkpMount` is the address
+a mount currently has (`concepts/mounts.md`) — and a service must not use such a
+name for anything of its own.
+
+---
+
+## What a board does and does not contain
+
+**No secret values.** A credential appears only as a reference —
+`{{secret.smtp}}` — which is resolved at the point of use and never reported
+back through `getState`. That is what makes a board safe to commit and to share,
+and it is a designed property rather than a convention: a resolved value cannot
+travel back out the way it came in.
+
+**No content that belongs elsewhere.** A service that serves or loads content
+holds a reference to one of the board's `assets` — `hkp-asset://player` — rather
+than the content itself, and each runtime resolves it where it is used. An asset
+can be inline in the document, or a URL the runtime fetches.
+
+**But not free of machine-written state.** Since `state` is a report, a board can
+carry a resolved endpoint or a port the system assigned. A runtime asked for
+`"port": 0` is given a free one, and saving the board writes down the one it
+got.
+
+**Complete, but not self-contained.** The document says everything about the
+board. It does not carry the things the board *reaches* — a board naming a
+runtime on a machine at your desk is a board about your desk, and it opens
+elsewhere only as far as that runtime is reachable.
+
+---
+
+## Working with the document
+
+The board menu is where the JSON itself is reachable:
+
+| | |
+|---|---|
+| **Edit Board Source** | shows the document and rebuilds the board from whatever you apply |
+| **Download Source** | writes it to a file |
+| **Create share link** | packs it into a URL, so sharing a board is sharing an address |
+
+A board can also be opened straight from a link — which is how every demo board
+on this site opens in the playground.
+
+Committing boards to git gives a readable history: adding a service appends one
+object to an array, changing a setting updates one value in a `state` object. No
+binary blobs and no generated identifiers, so a diff shows what somebody
+actually changed.
+
+---
+
+## Where it lives in the code
+
+| Concern | Where |
+|---|---|
+| The types | `hkp-frontend/src/types.ts` (`BoardDescriptor`, `RuntimeDescriptor`, `ServiceDescriptor`) |
+| What counts as a board | `hkp-frontend/src/types.ts` (`isBoardDescriptor`) |
+| Reading and writing one | `hkp-frontend/src/core/boardPersistence.ts` |
+| Facade shape | `hkp-frontend/src/facade/types.ts` |
+| Unit and composition shape | `hkp-frontend/src/runtime/board/units.ts` |
+| Blocks and their uses | `hkp-frontend/src/runtime/board/blocks.ts`, `hkp-frontend/src/core/linkBlocks.ts` |
+| Assets and references to them | `hkp-frontend/src/runtime/board/assets.ts` |
+| Example boards | `boards/` |
+
+---
+
+See also: **Board** (`concepts/board.md`) for what the document means when it is
+running, and **Units and compositions** (`concepts/units.md`) for assembling one
+board out of several.

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

@@ -0,0 +1,56 @@
+# Alpaca Markets
+
+A live stock trade feed over an authenticated WebSocket, where the interesting
+part is not the data but the handshake — a three-step login conducted by
+services that feed their own output back into themselves.
+
+## What it does
+
+It connects to Alpaca's market data stream, authenticates, subscribes to trades,
+and shows them in a table with a running volume delta.
+
+## How it works
+
+One [browser runtime](../concepts/runtime.md). Four services at the top level,
+and the first one contains the whole protocol.
+
+**1. Alpaca Feed Feedback** — a Feedback service wrapping a sub-pipeline. A
+WebSocket handshake is a conversation: connect, be told to authenticate, send
+credentials, be told you are authenticated, subscribe, be told you are
+subscribed. Each of the server's replies has to produce the next message. That
+is a loop, and feedback is how this board expresses one — the inner pipeline's
+output goes back in as its input until `handshakeComplete` is set, at which
+point `skipFeedbackWhen` opens the loop and messages flow on downstream.
+
+Inside it:
+
+- **Alpaca Stream**, a WebSocket client on `wss://stream.data.alpaca.markets/v2/iex`.
+- **Unpack**, a [Map](../services/map.md) taking one message out of the array.
+- **Auth**, an [If](../services/if.md) matching `T == 'success' && msg == 'connected'`,
+  whose sub-pipeline builds the auth message.
+- **Subscribe**, an If matching `msg == 'authenticated'`, building the
+  subscribe message.
+- **Detect Subscribe Ack**, an If matching `T == 'subscription'`, which sets the
+  runtime variable `handshakeComplete` and then
+  [Stops](../services/stopper.md) — the acknowledgement itself is not trade
+  data and should go no further.
+
+**2. Format Trade** — a [Map](../services/map.md) shaping each trade for display.
+
+**3. Volume Delta** — computes the change per 1000 ms interval.
+
+**4. Trade Feed** — a [Monitor](../services/monitor.md) keeping the last 100.
+
+## Why it is worth reading
+
+Most boards on this page are a line. This one is a state machine, and it is
+built out of the same parts: three `If` services standing in for three states,
+a runtime variable as the flag, a stopper to swallow the message that only meant
+"ready", and feedback to run the whole thing until it settles. No branching
+syntax appears anywhere — see [control flow](../concepts/runtime.md#control-flow).
+
+## Try it
+
+It needs an Alpaca API key and secret, entered in the facade's two text inputs.
+The JSON input holds the subscription request, so you can change which symbols
+it follows without touching the board.

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

@@ -0,0 +1,40 @@
+# Animate
+
+A hand-drawn parallax scene — sun, clouds, two ranks of trees, a walker — drawn
+25 times a second and recordable as a GIF. Every layer is a template, and the
+scene is what you get when five of them run from the same tick.
+
+## What it does
+
+It animates a looping landscape on a canvas. Each element moves at its own
+speed, which is all parallax is, and a recorder on the end of the chain can
+capture the result as an animated GIF without anything else changing.
+
+## How it works
+
+One [browser runtime](../concepts/runtime.md), five services, and the whole
+scene comes out of the third one.
+
+1. [Timer](../services/timer.md) ticks every 40 ms — 25 frames a second.
+2. [Tracks](../services/tracks.md) is where the drawing happens. It runs five
+   named tracks over that one tick, each a single [Map](../services/map.md)
+   producing the draw commands for one layer: `☀️`, `☁️`, `🌳`, `🌲`, `🚶‍♀️`. The
+   tracks are named with the emoji of the thing they draw, which reads better in
+   the overview than `layer-3` would. Running `serial` means their outputs are
+   reduced in order, so the list of shapes comes back stacked back-to-front.
+3. [Monitor](../services/monitor.md) shows the combined frame as data, which is
+   how you debug a drawing that has gone wrong.
+4. [Canvas](../services/canvas.md) draws it, clearing between frames and
+   capturing each one because `capture` is on.
+5. [GIF Recorder](../services/gif-encoder.md) collects captured frames while
+   `recording` is set, up to 300 of them, and writes `animation.gif`.
+
+The interesting part is step 2. Nothing wires the sun to the clouds; five
+independent templates each answer the same tick, and *fan-out then reduce* is
+the only structure needed to compose a picture out of layers. Adding a sixth
+layer is adding a sixth track.
+
+## Try it
+
+Open it and it runs. To record, set the GIF Recorder's `recording` to true,
+let it collect frames, then turn it off to get the file.

package/bundle/docs/content/boards/ascii-cam-board.md

@@ -0,0 +1,37 @@
+# ASCII Cam
+
+The camera, three times a second, rendered as text. A short chain that turns a
+live video frame into a grid of characters and shows it — with a facade so it
+can be used without seeing any of that.
+
+## What it does
+
+It shows what your webcam sees, drawn in ASCII, with knobs for the character
+grid and a switch to invert it.
+
+## How it works
+
+One [browser runtime](../concepts/runtime.md) — the camera and the display are
+both in the page, so nothing leaves it. No frame is uploaded anywhere.
+
+1. [Timer](../services/timer.md) ticks every 300 ms and fires immediately. This
+   is the frame rate: the camera is sampled on demand rather than streaming.
+2. [Camera](../services/camera.md) captures one frame per tick.
+3. [ASCII Art](../services/ascii-art.md) reduces the frame to a 100 × 60 grid of
+   characters, optionally inverted.
+4. [Monitor](../services/monitor.md) displays it in `ascii` mode at 550 × 500.
+
+Monitor is doing display duty here rather than debugging duty — in `ascii` mode
+it is the screen, which is why the board needs no canvas.
+
+## The facade
+
+One panel, `ASCII Cam`, holds the camera view, two knobs for the grid
+dimensions, four buttons and a line of text. The knobs write straight into the
+ASCII Art service's `cols` and `rows`, so turning one re-renders at a different
+resolution. That is the whole point of a [facade](../concepts/board.md#the-facade):
+the person using it adjusts a knob, not a service's state.
+
+## Try it
+
+It needs camera permission, and the browser will ask. Everything runs locally.

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

@@ -0,0 +1,47 @@
+# Audiolize
+
+Wikipedia's live edit stream, played as music. Every edit anywhere in Wikipedia
+arrives as an event; the board turns each one into a note and plays what comes
+out.
+
+## What it does
+
+It opens the public Wikimedia recent-changes stream and sonifies it. Small edits
+become one voice, large ones another, and the result is a rhythm that follows
+how busy Wikipedia happens to be.
+
+## How it works
+
+One [browser runtime](../concepts/runtime.md). The whole thing is four services,
+two of which are [Tracks](../services/tracks.md) doing different jobs.
+
+1. **Wikipedia Recent Changes**, an [Input](../services/input.md), holds a
+   persistent connection to `stream.wikimedia.org` and injects every message as
+   a new pipeline trigger. This is the board's clock — it has no timer, because
+   the data arrives on its own schedule.
+2. **Notes**, a [Tracks](../services/tracks.md), maps one edit into two possible
+   notes over two tracks, `snare` and `bass`, each a [Map](../services/map.md)
+   deciding what that edit sounds like.
+3. **Aggregates**, a second [Tracks](../services/tracks.md), is the musical
+   part. Each track picks its note out and hands it to an
+   [Aggregator](../services/aggregator.md) with an interval:
+   - `snare` aggregates over **90 ms**, taking the most frequently occurring
+     note (`val_max_occ`) in that window.
+   - `bass` aggregates over **180 ms** — half the rate, so it plays half as
+     often.
+
+   Its `reduce` track then collapses whatever the two produced into a single
+   thing to play.
+4. [Sound](../services/sound.md) plays it.
+
+## Why the aggregators are the design
+
+Wikipedia edits do not arrive on a beat; they arrive in bursts. Feeding them
+straight to a synthesiser would produce noise. The two aggregation windows
+impose a tempo — one fast voice, one at half speed — so the music has a pulse
+that the data does not. Changing the feel of this board means changing two
+numbers.
+
+It is also a clean example of fan-out and reduce being used twice in a row for
+different reasons: first to *derive* two interpretations of one event, then to
+*rate-limit* each one independently before they are recombined.

package/bundle/docs/content/boards/court-booking-browser-demo-board.md

@@ -0,0 +1,43 @@
+# Court Booking (Browser)
+
+[Court Booking](./court-booking-demo-board.md) with the database moved into the
+browser. The same three courts, the same calendar, the same statements — and
+nothing to install.
+
+## What it does
+
+It draws the day as a calendar — one column per court, one row per hour — and
+lets you take or give back an hour by tapping a cell. Your bookings are still
+there the next time you open the board.
+
+## How it works
+
+One browser runtime, three [SQL](../services/sql.md) services. They are the
+other board's services, unchanged: 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 nothing else.
+
+In the browser, SQL runs SQLite compiled to WebAssembly and keeps the database
+in this browser's storage. The two club rules are still unique indexes in the
+schema, and **The day** still returns cells that already know what they are.
+
+## What moving it cost
+
+The club. On hkp-node the tables belong to a server, and every member sees the
+same day from their own device. Here they belong to this browser, so the only
+member there is to be is whoever is signed in at this screen.
+
+Who is booking is decided by the same statements as on the server: whoever is
+signed in to the app, named on the line above the calendar. Signed out, the
+calendar is drawn but offers no hour. In a browser nothing verifies the
+account — the browser is the person — so what it buys is that the board is the
+same board on both runtimes, not that anybody is kept out.
+
+So this is the version for trying the board, or for booking something that is
+yours to share out — a room at home, a shared car. For a real club, run
+[Court Booking](./court-booking-demo-board.md) on hkp-node.
+
+## Try it
+
+Open it signed in. The schema is created on first run, and the bookings are kept in the
+browser's IndexedDB under the database name `tennis`.

package/bundle/docs/content/boards/court-booking-demo-board.md

@@ -0,0 +1,120 @@
+# Court Booking
+
+Three courts, an hourly calendar from 07:00 to 22:00, one hour per member per
+day. A small booking system where both club rules are enforced by the database
+rather than by the board.
+
+## What it does
+
+It draws the day as a calendar — one column per court, one row per hour — and
+lets a member take or give back an hour by tapping a cell.
+
+## How it works
+
+One [REST runtime](../concepts/runtime.md#the-servers) on hkp-node, three
+services, all [SQL](../services/sql.md):
+
+1. **Give an hour back** — releases a booking.
+2. **Take an hour** — makes one.
+3. **The day** — returns the whole day as cells that already know what they are:
+   free, yours, or somebody else's.
+
+The [calendar widget](../concepts/board.md#the-facade) draws whatever that last
+query returns. It contains no rules of its own.
+
+## The rules are indexes, not logic
+
+Two club rules — *a slot is bookable once*, and *a member gets one hour a day* —
+are **unique indexes** in the schema. Not checks in the board, not conditions in
+a template.
+
+That distinction earns its keep the moment two members tap the same slot at the
+same instant. A board that checked availability and then booked would have a gap
+between the two, and both taps would succeed. A unique index has no gap: the
+second insert fails, and the failure is the answer.
+
+It also means the rules cannot be bypassed by another board, a direct query, or
+a future version of this one that forgets them.
+
+Whoever loses is told. A tap that asked for a free hour and did not get it —
+because somebody else took it first, because the member already holds an hour
+that day, or because it was never theirs to take — comes back with a `notice`
+on the day **The day** returns (*Court 2 at 18:00 was just taken by someone
+else.*), and the facade raises it as a toast. It is the same value on every
+cell, so the notice reads it from the first, and empty on every other tap.
+Because a member's notifications go to that member alone, only the person who
+tapped sees it.
+
+## One query draws the screen
+
+**The day** returns cells already carrying their own state, so the widget
+performs no interpretation — it draws what it was given. Every tap enters the
+same pipeline and the query at the end re-reads what changed, which is why the
+calendar is correct after somebody else's booking without anything having to
+push an update.
+
+## Who is booking
+
+Every hour is booked in somebody's name, and the board never takes that name
+from the request. Each statement uses the verified caller directly:
+
+```sql
+$caller_email
+```
+
+`$caller_email` is the address of whoever began the run, **stated by the server
+that verified their sign-in** — see
+[SQL: who is calling](../services/sql.md#who-is-calling). There is no member
+field in the facade or its process payloads. Without a signed-in caller with a
+verified address, the board displays its calendar but offers no bookable hours.
+A timer, mount request, or forged identity field therefore books nothing.
+
+This is what makes the board safe to **share**. Deployed to a coordinator and
+[shared with a club](../concepts/cloud-boards.md#sharing-a-board-members),
+every tap of every member enters the same pipeline in the owner's database,
+and a member's client is free to send any payload it likes. It can claim to be
+someone else; the statements do not ask it. What it sends is also held to the
+club's week, courts and whole hours by the insert itself, since the facade's
+buttons are not the only thing that can call it.
+
+Other members are never shown an address. A taken hour is labelled with the
+name the club's member list gave its holder when they booked, and *Member*
+where it gave none.
+
+## The facade
+
+One panel: the calendar, the days of the week above it, and a line saying who
+is booking and for which day — *Booking as Anna on 2026-10-09*. The name is the
+signed-in account (`{ "$user": "name" }`), the day is the one **The day** last
+returned. That line is for the person reading it — nothing the server acts on —
+and there is no editable booking identity.
+
+## Sharing it with a club
+
+1. Deploy the board to a coordinator.
+2. Open it in Cloud Boards and choose **Members**: one entry per person, the
+   address they sign in with and the name the others should see.
+3. Send them the link from *Copy link*. It opens only for somebody on the list.
+
+Each member sees the calendar from their own side and nothing else of the
+board. One thing to know: a member's calendar is redrawn by their own actions,
+so somebody else's booking shows on their next tap rather than at once.
+
+## Try it
+
+Needs a signed-in account and an hkp-node kept under the name `node` in
+*Manage runtime servers*. The schema is created on
+first run, in a table of its own (`court_booking`) — the board's earlier
+`booking` table is left as it was.
+
+## Building something of your own on it
+
+This board is a starting point, not a finished product: there are no payments,
+no reminders, and one club. What it does have is the part that is expensive to
+add later — the rules held by the database rather than the board, and a caller
+the server vouches for.
+
+If you take it further and sell what you build, a commercial licence is the paid
+alternative to the AGPL: your product under your own name, with your own source
+closed. The **Open-source licences** page on the website says what it covers and
+who needs none of it.

package/bundle/docs/content/boards/current-time-board.md

@@ -0,0 +1,32 @@
+# Current Time
+
+A two-service board that answers with the date and time as a sentence somebody
+could say out loud. It exists to be called by another board rather than opened
+on its own.
+
+## What it does
+
+Given any trigger, it returns `{ "text": "Today it's Friday, July, 17. 2026 21:13" }`.
+That is the whole contract.
+
+## How it works
+
+One [browser runtime](../concepts/runtime.md), two services.
+
+1. **Build Sentence**, a [Map](../services/map.md) in `replace` mode, formats
+   the current date and time into a speakable string.
+2. **Sentence**, a [Monitor](../services/monitor.md), reports it so you can see
+   the answer when the board is open by itself.
+
+## Why it is a board and not a service
+
+This is a **skill target**: the Voice Assistant with skills board
+(`boards/voice-assistant-skills-demo-board.json`) routes a spoken request here
+through
+[Skill Router](../services/skill-router.md), and the calling board's
+[text-to-speech](../services/text-to-speech.md) reads the returned `text` aloud.
+
+Phrasing a skill as a board rather than a service is what makes it replaceable
+without touching the assistant. The dispatcher finds it **by name**, so the
+board has to be saved locally as `current time` for the lookup to succeed — see
+[Board Service](../services/board-service.md) for how one board plays another.