@readymadeit/mcp 0.0.0-stage → 0.1.0

package/bundle/docs/content/concepts/assets.md

@@ -0,0 +1,245 @@
+# Assets
+
+Content — a page, a script, an image, an audio sample — declared once in a board and named from service state by reference. Each runtime resolves a reference when a service uses it, from wherever the content actually lives.
+
+---
+
+## The problem
+
+Inline content works, and keeps working, until one of three things is true:
+
+- **It is used twice.** Each use is a full copy, and changing it means finding
+  every copy.
+- **It is large.** A sample library or a model does not belong in a board
+  document. It has to be named there and kept somewhere else.
+- **It is not the service's concern.** A page an endpoint serves is the thing
+  being served, not a setting of the service that serves it — and as a string in
+  that service's state it can only be edited as one line of escaped JSON.
+
+A [block](./blocks.md) does not help: a block is a piece of a pipeline, and an
+asset is a value that goes *into* a service.
+
+---
+
+## What an asset is
+
+A board declares its assets beside its runtimes and services, as **descriptors**:
+an id, a media type and exactly one source.
+
+```json
+"assets": [
+  { "id": "player",    "mediaType": "text/html; charset=utf-8", "text": "<!doctype html>…" },
+  { "id": "logo",      "mediaType": "image/png", "base64": "iVBOR…" },
+  { "id": "whisper",   "mediaType": "application/octet-stream",
+    "url": "https://models.example.com/whisper-small.bin", "sha256": "…", "size": 487000000 }
+]
+```
+
+| Field | |
+|---|---|
+| `id` | **required.** What references use: letters, digits, `.`, `-` and `_` |
+| `mediaType` | **required.** What the content is; a served asset is sent with it |
+| `text` \| `base64` \| `url` | **exactly one.** The content, or where it lives |
+| `sha256` | the version: an integrity check, and what lets a runtime cache a URL without asking again |
+| `size` | for the view, and for refusing oversized content |
+| `name` | what a person calls it |
+| `runtimes` | the runtimes that are given it, by id. Absent: every runtime of the document declaring it |
+
+An entry missing what is required is left out when the board loads, and named in
+a warning; it costs that one asset, not the board. The optional fields are kept
+where they are well-formed and dropped where they are not — a `sha256` that is
+not 64 hex digits, a header whose value is not a string — which is how every
+runtime reads the same descriptor.
+
+**An asset carries no request headers and names no secret.** A `url` source is
+an address anyone may fetch. An asset is resolved without anyone looking, by
+every runtime holding it — no place for a credential, and a header written into
+the board would travel with every copy of it. A descriptor that declares
+`headers` is read without them, and says so. Content that needs a credential is
+fetched by a service that shows where it sends it, like
+[`http-client`](../services/http-client.md), or read from a `file://` source on
+the runtime's own host.
+
+Service state holds a **reference** — `hkp-asset://<id>` — as a whole field, and
+never the content:
+
+```json
+"template": { "meta": { "status": 200 }, "body": "hkp-asset://player" }
+```
+
+`getState` echoes the reference and saving writes back what was configured, so
+there is nothing to take back out on save. This is the same reason a secret is
+`{{secret.…}}` in state rather than its value.
+
+---
+
+## Who resolves it
+
+**The runtime that uses the content, at the moment it uses it**, from its own
+**asset store**. The board's frontend does not substitute anything.
+
+Each runtime's store is *pushed* the descriptors of its document — **all of
+them**, whether or not one of its services names them. Which asset a service
+uses can be decided while the board runs — by the input of an
+[`asset`](../services/asset.md) service, by the response an endpoint is handed
+— so a reference has to resolve wherever it arrives. What is pushed is the
+descriptor: for content at a `url`, an address, not the content.
+
+An asset that should not be everywhere says where it belongs:
+
+```json
+{ "id": "ledger", "mediaType": "application/json", "text": "…", "runtimes": ["node"] }
+```
+
+Only the runtimes it names are given it, the browser runtime included; on any
+other, a reference to it does not resolve.
+
+The pushes happen:
+
+- with the **create payload**, so a service that loads content while being
+  configured has it by then;
+- again on **attach**, because a runtime that restarted still has its services
+  but has lost its store;
+- and whenever an asset is **edited**. That push is the point: a service
+  resolves its reference on its next use, so editing an asset changes what is
+  served **without reconfiguring anything**.
+
+A pipeline nested inside a service asks the runtime around it, as it does for
+secrets, so an edit reaches it immediately too. The browser runtime needs no
+push at all: its store *is* the board's `assets`.
+
+A reference is *found* by its scheme anywhere in a string — which is how the
+asset view says where an asset is used, and how a rename reaches every mention —
+but *resolved* only as a whole value. Nothing is spliced into longer text: a
+page that needs a script loads it as a second asset, the way the web does.
+
+---
+
+## Sources
+
+| Source | Resolved by | |
+|---|---|---|
+| `text`, `base64` | anyone | already in the descriptor |
+| `http://`, `https://` | the runtime using it | fetched by that runtime as anyone would fetch it — never relayed through the browser, with no headers of the board's, following redirects to other `http(s)` addresses — and revalidated with its ETag, or not at all when it has a `sha256` |
+| `file://` | only a host that owns the path | on hkp-node, `file:///<volume>/<path>` inside the tenant's own volumes, read as [`filesystem`](../services/filesystem.md) reads. On hkp-rt, a path inside the folder `HKP_ASSET_ROOT` names, and nothing when it is unset. Anything outside is refused, never read |
+| anything else | nobody | refused by name — `s3://` included, until a runtime has a client for it |
+
+A `file://` source is deliberately narrow: a shared board naming
+`file:///etc/passwd` behind an HTTP endpoint would otherwise be a leak.
+hkp-python and the browser runtime cannot read one at all.
+
+| Runtime | Store | Resolves |
+|---|---|---|
+| Browser | the board's `assets`, read as they are now — nothing is pushed | text, base64, `http(s)://` (as the source's CORS allows) |
+| hkp-node | pushed; nested pipelines delegate | text, base64, `http(s)://`, `file://` in a volume |
+| hkp-python | pushed; nested pipelines delegate | text, base64, `http(s)://` |
+| hkp-rt | pushed; nested pipelines delegate | text, base64, `http(s)://`, `file://` under `HKP_ASSET_ROOT` |
+
+**Inline content has a size.** A descriptor travels in the requests that
+configure a runtime, so what it carries itself — `text`, `base64` — is limited:
+on hkp-node to 8 MB per asset (`HKP_MAX_INLINE_ASSET_BYTES`), and to 32 MB for
+everything one request carries (`HKP_MAX_ASSET_REQUEST_BODY_BYTES`). Since a
+runtime is given all of its board's assets, that second number is how much
+inline content a board may hold. Content past either is named by `url` and
+fetched by the runtime, where the limit is the runtime's own.
+
+---
+
+## An asset that does not resolve
+
+**Fails loudly.** An endpoint whose body names an asset it cannot resolve answers
+`500` with the asset's id and the reason — an unknown id, a refused source,
+content that is not base64, a failed fetch, a hash that does not match — and
+reports it on the service. The
+[`asset`](../services/asset.md) service answers with an error status. Neither
+passes the reference on as if it were the content.
+
+---
+
+## Which services take one
+
+Only the ones that consume content resolve a reference themselves:
+
+- **HTTP endpoints** (`http-server-subservices` on hkp-node, hkp-python and
+  hkp-rt): an answer whose
+  `body` is a reference is sent as the asset's content, with the asset's media
+  type unless the answer names one.
+- **The [`asset`](../services/asset.md) service** puts an asset into the
+  pipeline for any service that has no support of its own. This is how anything
+  else uses an asset — by composition.
+
+Everything else sees `hkp-asset://…` as the string it is.
+
+---
+
+## The asset view
+
+A third way of looking at a board, beside its runtimes and the overview, switched
+from the toolbar:
+
+- **A list** of the board's assets: name, id, media type, where the content is,
+  and its size.
+- **An editor** for inline text, highlighted by media type. Changes take effect
+  on **Apply**, which pushes the descriptor to the runtimes given it — never
+  on each keystroke, since a page served half-written is worse than a stale one.
+  A runtime that did not take the push goes on using the version before, so it
+  is named on the asset and **Apply** stays available to send it again.
+  A URL source is edited as a descriptor.
+- **Given to**: every runtime, including one added later, or only the ones
+  ticked — and then taken from a runtime that is unticked. Ticking all of them
+  is still a list: a runtime added later is not on it.
+- **Used by**: every service on the board's own runtimes whose state names the
+  asset, found by a scan of what the services hold now, each a way to that
+  service.
+- **New** from text, a file or a URL. **Renaming** gives the asset under its new
+  id to the runtimes it is for, then rewrites every reference, then
+  removes the old id — so no service is told to use an id its runtime has not
+  been given, and the board declares both ids until the last reference has
+  moved. A runtime or a service that does not take its part puts the rename
+  back, and the new id is taken back from the runtimes that were given it.
+- **Deleting** one that is still referenced asks first. A runtime the deletion
+  did not reach still holds the asset — out of the board, but there for an
+  `asset` service asked for it by name — so it is named, with a retry.
+- Inline content past a size suggests moving out to a URL — where it goes is
+  the author's call.
+
+What is being edited belongs to the board that is open: an edit not yet applied
+is dropped when another board replaces it, and one still on its way to the
+runtimes stops where it is.
+
+---
+
+## Units and deploying
+
+A runtime's store is filled from the document that contributed the runtime. A
+runtime a [unit](./units.md) brings resolves against that unit's assets, so
+references are lexical and nothing needs renaming when units are composed. The
+same id in the board and in a unit names two assets: the asset view lists, checks
+and pushes the board's own, and an `asset` service's panel offers the ones its
+runtime resolves against. An asset's `runtimes` name runtimes of the document
+that declares it, by the ids they have there.
+
+> **Warning — unit assets are not deployed:** A board deployed to a
+> [coordinator](./cloud-boards.md) carries only the top-level board's asset
+> descriptors. A runtime contributed by a unit receives none of that unit's
+> assets. Any service on that runtime that uses `hkp-asset://…` for a
+> unit-owned asset will fail to resolve it after deployment. Such boards work
+> locally, but cannot currently be deployed correctly while they depend on
+> unit-owned assets.
+
+For the top-level board's own runtimes, the coordinator sends all of the
+top-level board's descriptors, less those restricted to other runtimes — as the
+browser does.
+
+---
+
+## Where it lives in the code
+
+| Concern | Where |
+|---|---|
+| The vocabulary: descriptors, the scheme, finding and renaming references | `hkp-frontend/src/runtime/board/assets.ts` |
+| Pushing edits, *Used by*, checking | `hkp-frontend/src/core/assetActions.ts` |
+| The browser runtime's resolver | `hkp-frontend/src/runtime/browser/assetResolver.ts` |
+| The asset view | `hkp-frontend/src/assets/` |
+| The runtimes' stores | `hkp-node/src/assets.ts`, `hkp-python/src/hkp/assets.py`, `hkp-rt/lib/include/assets.h` + `lib/src/assets.cpp` |
+| The runtimes' routes | `POST /runtimes/:id/assets` (merge; `null` removes), `GET /runtimes/:id/assets/:assetId` (a check, never content) |

package/bundle/docs/content/concepts/blocks.md

@@ -0,0 +1,300 @@
+# Blocks
+
+A configured sub-service — and the pipeline inside it — defined once in a board
+and used wherever a pipeline names it.
+
+---
+
+## The problem
+
+A pipeline repeats itself. In a drum pattern, *play a sound, then wait* appears
+dozens of times, and so does *two hi-hats, the first accented*. Written out, each
+repetition is a full copy: the same services, the same state, a different
+number here and there. The board gets long, and changing the idea means finding
+and changing every copy.
+
+A preset does not help with that. It is a service's configuration *applied* — a
+copy, from then on independent of where it came from. What a repeated idea
+wants is a **reference**: one definition, many places that name it, and what
+varies between them said at each place.
+
+Nor does a unit. A unit is half an app and contributes whole runtimes; a block is
+a piece of a pipeline, and sits inside one.
+
+---
+
+## What is added to a board
+
+Definitions in the board's `blocks`, and **uses** in any pipeline:
+
+```json
+"blocks": [
+  {
+    "id": "note",
+    "name": "Note",
+    "serviceId": "sub-service",
+    "params": { "trigger": "hihat", "volume": 0.5, "beats": 0.5 },
+    "state": {
+      "scope": { "slots": "inherit" },
+      "pipeline": [
+        { "block": "hit", "instanceId": "hit",
+          "params": { "trigger": "{{param.trigger}}", "volume": "{{param.volume}}" } },
+        { "serviceId": "hookup.to/service/timer", "instanceId": "wait",
+          "state": { "oneShotDelay": "{{param.beats}}", "oneShotDelayUnit": "beats" } }
+      ]
+    }
+  }
+]
+```
+
+```json
+{ "block": "note", "instanceId": "kick", "params": { "trigger": "kick", "volume": 0.9 } }
+```
+
+A **definition is a preset used by reference**: the same fields — `id`, `name`,
+`serviceId`, `serviceName`, `description`, `state` — read by the same parser,
+without the `"preset"` marker, since `blocks` already says what it is. `params`
+declares every parameter the state refers to, with the value it has when a use
+says nothing.
+
+**A block is a sub-service** (`sub-service`, or `hookup.to/service/sub-service`)
+whose state has a `pipeline`; a definition naming any other service is refused
+when the board opens. A use is refreshed — its params changed, its block's
+definition applied or an edit cancelled — by configuring the running service
+with its definition, and a sub-service configured with a pipeline rebuilds it in
+every runtime (`services/sub-service.md`), so what a definition no longer says
+is gone from every use. The sub-service's own fields are applied only when named,
+so each use is configured with all of them, filled in with their defaults where
+the definition leaves them out. Other services take a configure as a patch, and
+would keep what a definition dropped. A single service is made a block by
+wrapping it in a sub-service.
+
+A **use** stands where a service would. It carries the id the service would
+have (`instanceId` in a pipeline, `uuid` in a runtime's own list), and a use
+written without one is given one when the board opens. `serviceName` renames it;
+`params` gives values.
+
+### Parameters
+
+`{{param.name}}` anywhere in a definition's state. A reference that is a whole
+string takes the value as it is — a number stays a number — and one inside a
+longer string is written into it as text. A reference with no value is left in
+place and warned about.
+
+Parameters are **lexical**: inside a definition, `{{param.x}}` is that block's.
+A block used inside another is handed what it needs through its own `params`,
+which may refer to the outer block's — that is how *Note* passes `trigger` to
+*Hit*. A parameter may even name a block, `{ "block": "{{param.beat}}" }`, so
+one definition can be told which block to repeat.
+
+### A value made for each use
+
+A param's default may contain `{{random}}`:
+
+```json
+"params": { "topic": "readymade-{{random}}" }
+```
+
+Each use that does not give the param a value of its own gets one made —
+20 lowercase letters and digits, about 103 bits — the first time it is
+expanded, and **keeps it**: the value is written into the use's `params`, so
+saving the board saves it and the board opens with the same one next time. It
+shows on the use's bar, where it can be copied or replaced; typing
+`{{random}}` there makes a new one. For what must differ between copies and
+must not be guessable — an ntfy topic, a channel name — where a fixed default
+would put every copy of a board on the same one. A use inside another block's
+definition is not saved on its own, so it gets a new value each time the board
+opens. Applying a preset makes one for the copy the same way.
+
+A unit's parameters (`concepts/units.md`) share the syntax and not the scope:
+they are substituted into a unit's services — including the params its uses pass
+— and never into its `blocks`.
+
+---
+
+## A use is frozen while the board runs
+
+Opening a board **expands** every use into the service it stands for. No runtime
+knows blocks exist; what is provisioned is an ordinary board.
+
+Saving **writes each use back** as the board holds it — as it was written, with
+the params set on it since. Nothing running is compared against anything. That
+is what makes the model small, and it rests on one rule: **the inside of a use
+belongs to its definition.** So:
+
+- **It is locked on screen.** A use shows a bar — the block's name, its params,
+  its actions — in place of its panel, which appears only once the use is
+  edited or detached. A level opened on it shows what is inside, out of reach
+  (`inert`) and dimmed. An edit made there would be thrown away on save, which
+  is worse than not being able to make it. What only reads stays reachable: a
+  service's configuration opens read-only, and a panel that locks its own
+  controls instead (the Timeline's, whose editor opens as a read-only view)
+  keeps what shows details. What a use passes on is the use's own, so its
+  output plug sits beside the bar, where the Flow Inspector opens as it does on
+  any service.
+- **Nothing addresses it.** A facade widget or a Configurator naming a service
+  inside a use is refused when it is called, and warned about when the board is
+  opened. A use is addressed as a whole. This is a board rule, not a security
+  boundary: a remote runtime's own API still reaches the service.
+- **Runtime state inside a use is live only.** Whatever a service inside one
+  learns or reports while running is not saved — the way a Timer's `running` is
+  not.
+
+What a use does take:
+
+| | |
+|---|---|
+| **Params** | from its bar. A change re-instantiates that use and configures it with the result; for a sub-service only its own pipeline rebuilds |
+| **Detach** | turns the use into an ordinary copy of what it expanded to, saved from then on as whatever runs. The uses inside it stay uses |
+| **Edit block** | unlocks this use as a working copy of the definition, in its real context. **Apply** makes the copy the definition and re-instantiates every use of it; **Cancel** puts the copy back |
+| **Remove** | takes it out of its pipeline |
+
+When a definition is edited, **param-driven fields belong to the use**. Where the
+definition held `{{param.x}}`, the reference is kept, and a value changed there
+becomes the working copy's param; everything else becomes the definition's, for
+every use. A reference inside a longer string cannot be traced back once the
+text changes, so the new text is kept and the change is warned about.
+
+---
+
+## Making one, and using it again
+
+**Make block**, in a sub-service's menu, turns it into a definition and the
+service into its first use — nothing about what runs changes. Blocks already
+inside it stay uses. The board's blocks then appear in the **Building Blocks**
+sidebar, and dropping one on a runtime adds a new use with its default params.
+
+Services that are not yet in a sub-service are made a block in one step.
+**Shift-click** a service's header to pick it, and shift-click another in the
+same runtime to pick everything between the two — always a run, since a
+runtime's order is its wiring and a run with a gap in it could not be wrapped
+without rewiring what was left out. While services are picked, the runtime's
+header offers **Wrap in SubService** and **Make block**; so does the menu of any
+picked service. Make block asks for a name, wraps the run in a sub-service
+where it was, and makes that the block's first use. On its own, any service at
+the top of a runtime offers Make block in its menu, wrapping just itself. Escape,
+or selecting another runtime, lets the picked services go.
+
+On a phone a sub-service's sheet offers Make block, and a use's sheet Edit
+block, Detach, and Apply or Cancel while it is the working copy. One ordinary
+service is not offered as a block there — a preset keeps its configuration —
+so making a block of services is done from the runtime: **Make block** in its
+menu wraps all of them (a runtime holding just one sub-service makes that one
+a block where it is), and **Select services** puts a box on each, with a bar
+at the bottom offering Wrap and Make block once the picked services are a run.
+The add-service sheet keeps the board's blocks and the library's behind a
+**Building Blocks** tab, beside Services, from the same list the sidebar draws
+(`core/palette.ts`). A deployed board offers none of this: what it is made of
+changes in the playground and is deployed again.
+
+Wrapping keeps the board doing what it did:
+
+- The services are recreated inside the sub-service from the configuration they
+  report, under their own ids — so what they were set to carries over, and what
+  they only held while running (a recording, a timer's position) starts again.
+- The sub-service reads the runtime's slots (`scope.slots: "inherit"`), so a
+  Hold or a tempo reader inside reaches the cells it reached before.
+- A service inside a sub-service finds others by id only within it. A
+  Configurator whose target is on the other side of the new
+  boundary, or an `hkp-mount://` reference to a service in the run, would stop
+  resolving, so the wrap is **refused** and says which. A reference with both
+  ends in the run moves with it.
+- A facade addressing a service in the run is rewritten to reach it through the
+  sub-service (`the-hit` becomes `<sub-service>.the-hit`). A block's inside is
+  not addressable, so Make block refuses such a run instead.
+- Uses of blocks in the run stay uses, inside the new sub-service.
+
+Only services at the top of a runtime can be picked; a sub-pipeline's own
+services cannot yet.
+
+### Blocks from the library
+
+A block need not start in the board. The [preset library](presets.md) holds
+sub-service presets, and one that declares `params` is offered in the same
+sidebar as a block: shipped with the build (**ntfy notification**), imported
+from a file or a URL, or saved from a service. Dropping it **copies its
+definition into the board's `blocks`** and places a use of it — from then on it
+is the board's own block, exactly as if it had been made there:
+
+- The board opens anywhere, without the library, and a share link carries the
+  definition.
+- A second drop, of the same block, uses the copy the board already holds —
+  under whatever id it has there — rather than copying it again. One that
+  differs from a board block with the same id is given a free id (`ntfy-2`).
+- The library's version changing later — edited, or updated from its source —
+  does not reach the board's copy. Edit the board's block, or drop the newer
+  one beside it.
+
+The copy leaves behind what is the library's business: the `preset` marker and
+`origin`.
+
+---
+
+## Where a board goes
+
+| | Blocks |
+|---|---|
+| Saving, drafts and snapshots | kept: the documents, with their uses |
+| Share link, board source | kept for the board's own blocks; a unit's uses are expanded, since the link carries no unit to name |
+| Deploying | expanded: a coordinator is handed what runs, the way a bundle is |
+| Units | each document keeps its own. A unit's uses resolve against the unit's blocks, never the composition's, and save back into the unit |
+
+---
+
+## Presets and blocks
+
+The two are one idea with two verbs. A preset is a service's configuration
+**applied** — copied, and independent from then on. A block is the same
+document **used** — referenced, and following its definition. Presets take
+`params` too: applying one substitutes its defaults, which is a use detached the
+moment it is made.
+
+What still differs: a preset is keyed by the service it configures and its id,
+and lives in files and the preset library; a block is named by its id within one
+board. The library is where they meet: a sub-service preset with params is
+dropped as a block, its definition copied into the board. A use never names the
+library itself, so a board depends on nothing outside it.
+
+---
+
+## Known gaps
+
+- **Moving a use to another pipeline** writes it back expanded: it is found by
+  its id within the pipeline it was placed in.
+- **Nested drops.** The palette adds a use to a runtime's own services; inside a
+  sub-pipeline a block is not yet offered by its selector.
+- **Mobile** drills into a service's `pipeline` only. A service holding several
+  — Switch, If, Feedback, Tracks, Hold — draws them through the desktop's
+  pipeline editor, which a phone does not show, so their pipelines and any use
+  inside them are out of reach there.
+- **Applying an edit closes a level open on the working copy**, since its
+  pipeline is rebuilt.
+
+---
+
+## Where it lives in the code
+
+| Concern | Where |
+|---|---|
+| Expanding, writing back, params, detach, the working copy | `hkp-frontend/src/runtime/board/blocks.ts` |
+| Parameter substitution, shared with presets | `hkp-frontend/src/runtime/board/params.ts` |
+| Definitions read as presets; presets with params | `hkp-frontend/src/core/presets.ts` (`parseBlockDefinition`, `presetState`) |
+| Linking into a board and its units, and back out; address checks | `hkp-frontend/src/core/linkBlocks.ts` |
+| What a person does to a use | `hkp-frontend/src/core/blockActions.ts` |
+| Wrapping picked services, and making a block of them | `hkp-frontend/src/runtime/board/wrap.ts` (what may be wrapped), `hkp-frontend/src/core/wrapActions.ts` (doing it), `hkp-frontend/src/ui-components/runtime-ui/WrapSelection.tsx` |
+| Picking services | `hkp-frontend/src/selection/SelectionContext.tsx`, `hkp-frontend/src/runtime/ServiceUiContainer.tsx` |
+| Adding a use from the palette | `hkp-frontend/src/core/palette.ts` (what is offered), `hkp-frontend/src/core/serviceOperations.ts` (`addService`) |
+| The phone's actions and selection mode | `hkp-frontend/src/views/playground/mobile/ServiceSheet.tsx`, `MobileBoardCanvas.tsx`, `MakeBlockSheet.tsx` |
+| Copying a library block into a board | `hkp-frontend/src/runtime/board/blocks.ts` (`withAdoptedDefinition`), `core/presets.ts` (`isUsableAsBlock`) |
+| Blocks the build ships | `hkp-frontend/presets/sub-service/`, listed in `src/presetRegistry.ts` |
+| The bar, the lock, the edit bar | `hkp-frontend/src/runtime/ui/BlockUse.tsx` |
+| Refusing addresses into a use | `hkp-frontend/src/facade/boardServices.ts` |
+| Worked example | `boards/nested-rhythm-demo-board.json` |
+| Tests | `runtime/board/tests/blocks.test.ts`, `runtime/board/tests/wrap.test.ts`, `core/tests/linkBlocks.test.ts`, `core/tests/block-use.integration.test.ts`, `core/tests/wrap-services.integration.test.ts`, `core/tests/palette.test.ts`, `tests/mobile-building.test.tsx`, `e2e/tests/blocks.spec.ts` |
+
+---
+
+See also: **Presets** (`concepts/presets.md`) for the verb blocks share a document
+with, **Scopes** (`concepts/scopes.md`) for the sub-service boundary most blocks
+are, and **Units and compositions** (`concepts/units.md`) for composing at the
+size of a board.