@hybridlabor-api/aos 4.3.0 → 4.4.1

package/mcps/tdmcp/docs/guide/ai-controlled-party.md

@@ -1,215 +0,0 @@
----
-title: AI-Controlled Party
-description: "Run a safe AI-assisted party rehearsal with tdmcp and TouchDesigner: local dashboard, ShowIntent policy, approvals, simulated effects, Telegram, Ollama and TD boundaries."
----
-
-# AI-Controlled Party
-
-AI-Controlled Party is a show mode pattern for using tdmcp and TouchDesigner as
-an AI co-pilot for live visuals. The AI can suggest and select approved cues,
-change visual mood, draft announcements and react to operator or Telegram text.
-TouchDesigner remains the deterministic stage runtime, and the human operator
-keeps final authority over hazardous effects.
-
-The current implementation is a **local rehearsal POC**, not autonomous show
-control. It proves the decision loop, dashboard, audit trail, optional local LLM
-path, optional Telegram path and optional TouchDesigner visual surface. It does
-not prove venue hardware.
-
-```text
-dashboard / Telegram / operator text
-  -> optional Ollama parser or deterministic fallback
-  -> ShowIntent envelope
-  -> policy decision
-  -> allow, approval queue or block
-  -> simulation or TouchDesigner control-panel update
-  -> real hardware only after a separate venue adapter and approval gates exist
-```
-
-## What exists now
-
-| Surface | Status | What it proves |
-| --- | --- | --- |
-| `tdmcp-agent show-director` | Shipped policy CLI | Validates one `ShowIntent`, returns `allow`, `require_approval` or `block`, and updates approval/audit JSON without connecting to TD or hardware. |
-| `tdmcp-agent ai-party-poc` | Shipped offline producer runner | Runs the seven-moment producer rehearsal with fan-in, policy decisions, approval state, audit summary and simulated effects only. |
-| `npm run ai-party:dev` | Local live rehearsal POC | Starts the Live Nervous System backend and dashboard, normally at `http://127.0.0.1:8787/`. |
-| `npm run ai-party:dry` | Fast smoke proof | Runs the deterministic doors -> mood -> brand -> fog approval -> approval -> audio-reactive -> safety proof sequence with no external service. |
-| `npm run ai-party:td-build` | Optional TD visual surface | Builds `/project1/ai_party_poc` with a control panel, visual TOP chain, simulated DMX table, disabled DMX placeholder and `preview_out`. |
-| `npm run ai-party:telegram` | Optional local Telegram path | Uses Bot API long polling with allowlisted chat IDs; it replies through Telegram but still routes every request through the same policy layer. |
-| `tdmcp-agent ai-party` | Earlier Hermes/Telegram gateway | Dry-runs one Telegram/Hermes-style message through the Show Director policy surface. It remains policy-only and does not build a TD context. |
-
-The dashboard includes command input, example chips, cue deck, approval queue,
-live state, TouchDesigner preview status, event-log filters and a safety panel.
-The local service writes JSONL audit events to
-`POC_EVENT_LOG_PATH` (`./data/ai-party-poc-events.jsonl` by default).
-
-## Recommended local rehearsal
-
-Start with the offline proof:
-
-```bash
-npm run ai-party:dry
-npm run ai-party:test
-```
-
-Then run the dashboard:
-
-```bash
-npm run ai-party:dev
-```
-
-Open the printed URL. Useful test prompts:
-
-- `deixa a sala mais premium tropical`
-- `prepara fumaça curta no próximo drop`
-- `blackout total e strobo máximo e raw dmx`
-
-Expected behavior:
-
-- The first prompt selects a safe visual cue or mood.
-- The fog prompt creates an approval item; approving it still simulates the
-  physical effect unless live gates and a real adapter are deliberately added.
-- The blackout / max-strobe / raw-DMX prompt is blocked and logged.
-
-## Optional Ollama
-
-Set a local model only if you want the LLM parser in the loop:
-
-```bash
-OLLAMA_BASE_URL=http://127.0.0.1:11434
-OLLAMA_MODEL=qwen2.5:3b
-npm run ai-party:dev
-```
-
-No specific model is required for the POC. If Ollama is unavailable or
-`OLLAMA_MODEL` is unset, the dashboard reports that state and uses deterministic
-fallback parsing for the built-in demo commands.
-
-## Optional TouchDesigner preview
-
-Start the tdmcp bridge, then build the demo network:
-
-```bash
-npm run ai-party:td-build
-```
-
-The builder creates or replaces `/project1/ai_party_poc`. Every created operator
-gets explicit `nodeX` / `nodeY` coordinates so the network is readable instead
-of stacked. The dashboard preview endpoint targets:
-
-```text
-/project1/ai_party_poc/preview_out
-```
-
-Cue and mood actions can update the TD control panel when the bridge is
-reachable. Physical effects remain represented by a simulated DMX table and a
-disabled output placeholder.
-
-## Optional Telegram bench
-
-Use Telegram long polling for local rehearsal:
-
-```bash
-TELEGRAM_BOT_TOKEN=... \
-TELEGRAM_ALLOWED_CHAT_IDS=123456789 \
-TELEGRAM_POLLING_ENABLED=true \
-npm run ai-party:telegram
-```
-
-Supported commands include `/status`, `/cues`, `/cue <cue_name>`,
-`/mood <text>`, `/fog <seconds> <intensity>`, `/approve <approval_id>`,
-`/reject <approval_id>`, `/panic` and `/demo`.
-
-Keep Telegram allowlisted. Webhook mode is deployment work, not the local POC
-path.
-
-## Safety model
-
-The LLM only interprets text into structured `ShowIntent` JSON. It never gets to
-dispatch raw DMX, raw Python, arbitrary endpoints, fixture channels, mixer
-commands, PA actions or laser / moving-head control.
-
-Allowed low-risk intents:
-
-- `announce`
-- `change_mood`
-- `request_cue` for pre-approved visual cues
-- `log_note`
-- `panic_status`
-
-Approval-gated by default:
-
-- `fog`
-- `hazer`
-- bounded `strobe`
-
-Blocked or operator-only by default:
-
-- `blackout`
-- `freeze`
-- `moving_head`
-- `laser`
-- `mixer_gain`
-- `pa_mute`
-- `audio_routing`
-- input gain, mute groups, patching, channel-strip edits and raw adapter
-  commands
-
-Approval is checked twice: once when the request enters the queue, and again
-when the operator approves it. Runtime cooldown state is part of that second
-check, so two queued fog requests cannot both dispatch if the first approval
-puts the effect inside its cooldown window.
-
-`HARDWARE_ENABLED` and `DMX_LIVE_ENABLED` are integration gates for future
-adapters. Do not treat them as a venue-ready DMX driver. The current TD POC uses
-`sim_dmx_table` and `dmx_out_disabled`, and real fixtures still require a
-separate adapter, patch map, emergency-stop path, bench validation and venue
-rehearsal.
-
-## Mixer scene arming study
-
-The designed Soundcraft Ui24R extension remains **planned**, not live execution:
-
-- The proposed intent is `arm_mixer_scene`, separate from hazardous
-  `mixer_gain`, `pa_mute` and `audio_routing` effects.
-- The AI may prepare a specific Ui24R show, snapshot or cue target.
-- The MVP policy must always require human approval before any adapter can
-  dispatch the action.
-- The first implementation slice should be contract + dry-run adapter only.
-- Bitfocus Companion is still the recommended first live backend after isolated
-  bench validation; a direct Node bridge is deferred until the Ui24R protocol is
-  proven against the target firmware.
-
-The durable design spec lives in
-[AI Party Ui24R Scene-Arming Design](../superpowers/specs/2026-06-04-ai-party-ui24r-scene-arming-design.md).
-
-The important safety finding is that a Ui24R show/snapshot/cue can hide broad
-mixer-state changes. A mixer scene is only AI-armable if a trusted venue catalog
-and manifest prove the target scene excludes gain, PA mute, routing, patching,
-channel-strip, mute-group and phantom-power changes. Otherwise it remains
-operator-only/manual.
-
-## Validation plan
-
-Use the POC as a harness. Each pass should prove one boundary before the next
-one is trusted:
-
-| Stage | What to prove | Pass signal |
-| --- | --- | --- |
-| Offline policy | Text and scripted events become valid `ShowIntent`s. | `npm run ai-party:dry` and `npm run ai-party:test` pass; allowed, queued and blocked paths all appear. |
-| Dashboard rehearsal | The operator can see current cue, pending approvals, policy reasons, panic state and audit events. | `npm run ai-party:dev` serves the dashboard, approvals can be approved/rejected, and blocked requests stay blocked. |
-| TouchDesigner preview | TD can host the visual POC without depending on device hardware. | `npm run ai-party:td-build` creates `/project1/ai_party_poc`; `/api/td/preview` can read `preview_out` when the bridge is available. |
-| Telegram bench | A bot can receive allowed operator messages and send status replies. | Long polling processes only allowlisted chats and maps `/cue`, `/mood`, `/fog`, `/approve`, `/reject` and `/panic` through policy. |
-| Venue hardware | Every fixture, output and effect has a safe state before live control. | Still pending: fixture patching, real DMX/fog/strobe/hazer/PA adapters, emergency stop, cooldowns and operator rehearsal must be venue-specific. |
-
-Repeat the offline policy and dashboard stages whenever the policy changes.
-Repeat the hardware stages for every venue.
-
-## Not yet live-validated
-
-Real STT, OpenClaw wiring, deployed Telegram webhooks, fixture patching, DMX
-output, fog/hazer hardware, strobe hardware, moving heads, lasers, PA control,
-Soundcraft Ui24R scene recall, venue emergency stop and show-pressure operator
-rehearsal all require a venue-specific validation pass. Do not treat the local
-POC, the dry-run planner or the planned mixer-scene contract as a hardware
-controller.

package/mcps/tdmcp/docs/guide/body-tracking.md

@@ -1,169 +0,0 @@
----
-description: "Full-body and pose tracking in TouchDesigner with tdmcp — drive skeletons and body-reactive visuals from a webcam via MediaPipe, with a synthetic mode that needs no camera."
----
-
-# Body & pose tracking
-
-Track a person with nothing but a webcam and turn their movement into visuals — a
-glowing skeleton, dots that follow the hands and feet, motion trails that smear
-behind the body. tdmcp builds these from plain language, the same way it builds
-everything else.
-
-No Kinect, no depth camera, no Windows-only hardware: the tracking comes from
-[MediaPipe](https://github.com/torinmb/mediapipe-touchdesigner), Google's free
-pose model, which runs on macOS and Windows from an ordinary webcam.
-
-::: tip You can try it before installing anything
-Every body-tracking tool defaults to a **synthetic** source — a self-contained
-animated figure — so the network builds and previews instantly with no camera and
-no plugin. Use it to dial in the look, then switch the source to your webcam.
-:::
-
-## 1. Try it now (no camera, no plugin)
-
-In your AI assistant:
-
-> *"Build a pose skeleton and show me a preview."*
-
-You'll get a stick figure — 33 landmarks (head, shoulders, elbows, wrists, hips,
-knees, ankles) joined by glowing lines — moving on its own. Then iterate:
-
-- *"Make the lines magenta and thicker."*
-- *"Now give me body-reactive glowing dots instead."*
-- *"Add motion trails."*
-
-## 2. Install the MediaPipe plugin (for a real performer)
-
-To track a real person you need the free, GPU-accelerated MediaPipe plugin
-(Mac + PC). tdmcp can fetch it for you — in a terminal:
-
-```bash
-npx --yes --package=@dpantani/tdmcp tdmcp install mediapipe-touchdesigner
-```
-
-`tdmcp install <lib>` stages manifest-listed community libraries safely; here it grabs
-the MIT-licensed
-[torinmb/mediapipe-touchdesigner](https://github.com/torinmb/mediapipe-touchdesigner)
-and extracts it under `~/.tdmcp/packages`.
-
-Then, with TouchDesigner open, ask the assistant:
-
-> *"set up body tracking"*
-
-The **setup_body_tracking** tool loads the plugin into your project, finds its
-pose-landmarks CHOP, and wires up `create_pose_tracking` plus a live skeleton —
-all you do is pick your webcam on the new `mediapipe_pose` component and enable
-**Pose**.
-
-Prefer to do it by hand? Open `MediaPipe TouchDesigner.toe` (or drag a `.tox` from
-the staged package under `~/.tdmcp/packages`) into your project, enable
-**Pose**, then point a tool's `mediapipe_chop_path` at the plugin's pose-landmarks
-CHOP (33 samples, channels `tx`/`ty`/`tz`).
-
-::: warning macOS camera permission
-The first time TouchDesigner reads your webcam, macOS pops a permission dialog.
-**Click Allow** — until you do, TouchDesigner may look frozen. See
-[Troubleshooting](/guide/troubleshooting#macos-microphone-camera-permission).
-:::
-
-## 3. Point the visuals at your body
-
-Tell the assistant to use the plugin as the source:
-
-> *"Build a pose skeleton from the MediaPipe plugin at
-> `/project1/mediapipe1/select_pose` and show a preview."*
-
-> *"Make body-reactive trails from my webcam pose."*
-
-The assistant sets the tool's `source` to `mediapipe` and points
-`mediapipe_chop_path` at the plugin's pose CHOP. Everything else — the skeleton,
-the dots, the trails — works exactly as it did in synthetic mode.
-
-## 4. What you can build
-
-Three tools cover the pipeline; the AI picks them for you, but it helps to know
-the vocabulary:
-
-| Tool | What it makes |
-| --- | --- |
-| **create_pose_tracking** | The foundation. A clean pose signal (33 landmarks) plus ready-to-bind scalar channels like `r_wrist_y`, `hand_span`, `height`. Smoothing and Mirror built in. |
-| **create_pose_skeleton** | The classic stick-figure skeleton rendered to a TOP — glowing lines connecting the landmarks. |
-| **create_body_reactive** | Glowing marks that follow the body, in three styles: **points** (crisp dots), **glow** (bloomed dots), **trails** (motion smears). |
-
-You can chain them: build `create_pose_tracking` once, then point both the
-skeleton and the reactive visual at its output so they share one tracked body.
-
-## 5. Bind your body to anything
-
-`create_pose_tracking` also exposes a **keypoints** CHOP of plain scalar channels,
-so you can drive *any* parameter with a body part:
-
-- *"Make the blur amount follow my right hand height."*
-- *"Map how wide my arms are open to the feedback feedback amount."*
-- *"When I crouch, dim the lights."* (the `height` channel shrinks)
-
-Bind a parameter to `op('…/pose_tracking/keypoints')['r_wrist_y']` (or
-`hand_span`, `hips_x`, `height`, …) and it tracks your movement live.
-
-## 6. Put a hologram in your hand
-
-Hands are not only controller data. `create_hand_hologram` builds a complete
-visual system where an open palm reveals a translucent cube floating just above
-the hand. The visual defaults to a synthetic two-hand source, so you can preview
-the look before touching the webcam:
-
-> *"Build a futuristic holographic cube floating above my open palm. Start with a
-> synthetic preview, make it transparent cyan with a violet accent, and let a
-> pinch from my other hand grow the cube."*
-
-Under the hood, `create_hand_hologram` creates a nested `create_hand_gesture_bus`.
-That bus publishes stable channels like `float_x`, `float_y`, `palm_size`,
-`pinch_power`, `light_gain` and `audio_level`. The hologram shader reads those
-channels instead of raw MediaPipe landmarks, so the same bus can later drive
-lasers, particles, projection cues or audio controls.
-
-When you are ready for the real hand, switch the source:
-
-> *"Rebuild the hand hologram with MediaPipe hands from my webcam, keep it higher
-> above the palm, and send the futuristic audio to my audio device."*
-
-`audio_mode` defaults to `none`; use `synth` for an internal signal or
-`device_out` when you explicitly want an Audio Device Out CHOP.
-
-## 7. Use hands as Ableton filter controls
-
-Hands can also become a four-channel Ableton controller when you use TDAbleton.
-The `create_hand_ableton_mapper` tool builds the TouchDesigner side: MediaPipe
-hands in, a skeleton overlay with star joints, and a `mapper_send` CHOP for
-TDAbleton. AbletonMCP is not required for this recipe.
-
-Default mapping:
-
-| Mapper slot | Gesture |
-| --- | --- |
-| `map1` | Left-hand thumb/index distance |
-| `map2` | Right-hand thumb/index distance |
-| `map3` | Left wrist roll |
-| `map4` | Right wrist roll |
-
-On the TDAbleton `TDA_Mapper`, point the input CHOP to
-`/project1/hand_ableton_mapper/mapper_send`, set `Reorder` to
-`map1 map2 map3 map4`, keep `Bypass1..4` off, and map the four slots manually to
-Auto Filter frequency, resonance, drive, or rack macros inside Ableton.
-
-If TouchDesigner values move but Ableton does not, run
-`diagnose_tdableton_mapper`. It checks the real mapper path, input CHOP, `Reorder`,
-bypass states, `Min/Max` ranges, and missing `map1..map4` channels. This catches
-the common stale-target problem where a mapper looks healthy but points at the
-wrong track or device.
-
-## Ready-made recipes
-
-Two browsable templates ship in the recipe gallery — ask *"list recipes"* or see
-the [Recipe gallery](/guide/recipes):
-
-- **Pose Skeleton (MediaPipe)** — the stick-figure skeleton from a live webcam.
-- **MediaPipe Body Dots** — glowing dots tracking every joint.
-
-Both expect the MediaPipe plugin; point their `posein` Select CHOP at its pose
-landmarks CHOP.

package/mcps/tdmcp/docs/guide/codex.md

@@ -1,107 +0,0 @@
----
-title: Codex + TouchDesigner
-description: "Connect OpenAI Codex CLI to TouchDesigner with tdmcp — the TouchDesigner MCP server. Build real node networks from plain-language prompts in Codex, with a create → verify → preview loop."
----
-
-# Codex + TouchDesigner
-
-**tdmcp** connects the **Codex CLI** to TouchDesigner over the
-[Model Context Protocol](https://modelcontextprotocol.io). Once it's wired up you
-describe a visual in plain language inside Codex and it builds the actual network
-of operators in your project — then checks it for errors and shows you a preview.
-
-If you also use Claude or Cursor, the setup is the same idea; this page is the
-Codex-specific path. For the full picture see [Install](/guide/install).
-
-## What you need
-
-- **[TouchDesigner](https://derivative.ca/download)** — the free non-commercial
-  edition is fine.
-- **[Node.js 20+](https://nodejs.org)** — Codex runs the tdmcp server as a local
-  `node` process over stdio.
-- The **Codex CLI** installed and working (`codex --version`).
-
-## Connect tdmcp to Codex
-
-You can register tdmcp from the published npm package (no clone) or from a local
-build. Either way Codex launches it as a stdio MCP server.
-
-::: tip Let Codex do it for you
-Paste this into Codex and it installs and wires everything itself, stopping only
-for the one TouchDesigner line:
-
-```text
-Install and connect tdmcp for me using the official install guide:
-https://pantani.github.io/tdmcp/guide/install
-Do every step yourself; only stop when you need me to do the TouchDesigner bridge step.
-```
-:::
-
-### Option A — from npm (no clone)
-
-Add tdmcp to `~/.codex/config.toml` (merge into any existing `[mcp_servers.*]`):
-
-```toml
-[mcp_servers.tdmcp]
-command = "npx"
-args = ["--yes", "--package=@dpantani/tdmcp", "tdmcp"]
-```
-
-### Option B — from a local build
-
-Clone and build, then point Codex at `dist/index.js`:
-
-```bash
-git clone https://github.com/Pantani/tdmcp.git
-cd tdmcp
-npm run setup   # installs, builds, and prints the exact connect line
-```
-
-Then either run `codex mcp add tdmcp -- node <project-path>/dist/index.js`
-(`<project-path>` is the cloned folder — run `pwd` inside it), or add it to
-`~/.codex/config.toml` by hand:
-
-```toml
-[mcp_servers.tdmcp]
-command = "node"
-args = ["<project-path>/dist/index.js"]
-```
-
-**Restart your Codex session** afterwards so it picks up the new server.
-
-## Turn on the bridge in TouchDesigner
-
-tdmcp needs a small bridge running *inside* TouchDesigner. The easiest way is to
-drag the release `.tox` in — no Textport
-([see Install](/guide/install#drag-in-tox)). Prefer one paste? Open the **Textport**
-(**Dialogs → Textport and DATs**), paste this one line, and press Enter:
-
-```python
-import urllib.request; exec(urllib.request.urlopen("https://github.com/Pantani/tdmcp/raw/v0.12.0/td/bootstrap.py").read().decode())
-```
-
-You should see `[tdmcp] bridge running on port 9980`. This is the only step that
-has to happen inside TouchDesigner — see [Install](/guide/install#turn-on-the-bridge)
-for the details and how to remove it later.
-
-## Make something
-
-With TouchDesigner open and the bridge on, ask Codex in plain language:
-
-> *"Create an audio-reactive particle galaxy and show me a preview."*
-
-It builds the network, checks it for errors, and returns a thumbnail. Keep going
-in plain language — *"make it warmer," "add a feedback trail," "output it
-fullscreen."* More ideas are in the [prompt cookbook](/guide/prompt-cookbook), and
-[Your first visual](/guide/first-visual) walks through one end to end.
-
-## Not connecting?
-
-- Confirm the bridge is on: `curl http://127.0.0.1:9980/api/info` should return
-  JSON.
-- **Restart the Codex session** after editing `~/.codex/config.toml` — MCP servers
-  are loaded at startup.
-- Full [Troubleshooting](/guide/troubleshooting) covers the common cases.
-
-For host/port, environment variables, and the local copilot CLI, see the
-[CLI reference](/reference/cli) and [environment variables](/reference/environment).

package/mcps/tdmcp/docs/guide/components.md

@@ -1,126 +0,0 @@
----
-description: "Turn a tdmcp-built TouchDesigner network into a reusable, parameterized, scriptable .tox component — add custom-parameter knobs, scaffold a Python extension class, and save it as a .tox you can drop into any project."
----
-
-# Reusable components
-
-A network you built with tdmcp is great for one show — but to reuse it across
-projects you want three things: **knobs** to tune it, **behavior** you can call by
-name, and a single **`.tox` file** you can drop anywhere. Three tools cover the
-full story:
-
-| Step | Tool | What it does |
-|------|------|--------------|
-| Build | (any generator) | Make the network — e.g. a feedback tunnel. |
-| Knobs | `add_custom_parameters` | Append a custom-parameter page (sliders, toggles, menus, pulses, RGB/XYZ). |
-| Behavior | `scaffold_extension` | Give the COMP a Python extension class with methods you can call. |
-| Package | `manage_component` | Save the COMP as a reusable `.tox` (or load one back, live-linked). |
-
-You can drive every step in plain language. Here's the whole arc.
-
-## 1. Build the network
-
-> *"Create a feedback tunnel from noise with blur and displace, wrap it in a
-> container, and show me a preview."*
-
-Say the container landed at `/project1/tunnel`. Everything below tunes **that
-COMP** so it becomes a self-contained, reusable widget.
-
-## 2. Add knobs (`add_custom_parameters`)
-
-> *"On `/project1/tunnel`, add a 'Controls' page with a Feedback knob (0–1,
-> default 0.9), a Zoom knob (0.5–2), a Spin knob (−180 to 180) and a Reset
-> pulse."*
-
-This appends a custom-parameter page so the component exposes a clean control
-surface instead of forcing the next user to dig into the internal nodes. An
-existing parameter is **skipped with a warning**, never overwritten, so re-running
-it to add one more knob is safe.
-
-::: tip Bind the knobs to the work
-The knobs are just inputs until you point them at something. Ask to
-*"bind the Feedback knob to the feedback level's brightness"* (that's
-[`create_control_panel`](/reference/tools) / `create_macro` under the hood), or
-read them from the extension class you'll add next.
-:::
-
-## 3. Add behavior (`scaffold_extension`)
-
-Knobs hold values; an **extension class** gives the component real methods:
-
-> *"Scaffold an extension class `TunnelExt` on `/project1/tunnel` with methods
-> `Reset` and `Randomize`, and promote it."*
-
-That creates a Text DAT inside the COMP holding:
-
-```python
-class TunnelExt:
-    def __init__(self, ownerComp):
-        self.ownerComp = ownerComp
-
-    def Reset(self):
-        pass
-
-    def Randomize(self):
-        pass
-```
-
-…wires it into the COMP's extension slot and **promotes** it, so the methods are
-callable straight off the component — `op('/project1/tunnel').Reset()`. Fill in
-the stubs (ask the AI, or edit the DAT) and the component now *does* things, not
-just *holds* values.
-
-::: tip Promoted = callable by name
-Promoted members (capitalized, like `Reset`) are reachable directly on the COMP.
-The extension parameter names live on the COMP's built-in **Extensions** page;
-tdmcp probes for them so it keeps working across TouchDesigner builds.
-:::
-
-## 4. Save it as a `.tox` (`manage_component`)
-
-> *"Save `/project1/tunnel` as `/Users/me/td-components/tunnel.tox`."*
-
-Now you have a single file that carries the network, its knobs and its extension
-class. Drop it into any project:
-
-> *"Load `/Users/me/td-components/tunnel.tox` into `/project1` as a live-linked instance."*
-
-A live-linked instance (`externaltox`) re-reads the file whenever it changes, so
-fixing the component once updates every show that uses it.
-
-## The same thing from the shell
-
-Every step has a `tdmcp-agent` command, so you can package a component in a script:
-
-```bash
-# 2. knobs
-tdmcp-agent add-params --params '{
-  "comp_path": "/project1/tunnel",
-  "page": "Controls",
-  "params": [
-    { "name": "Feedback", "type": "Float", "default": 0.9, "min": 0, "max": 1 },
-    { "name": "Reset", "type": "Pulse" }
-  ]
-}'
-
-# 3. behavior
-tdmcp-agent scaffold-ext --params '{
-  "comp_path": "/project1/tunnel",
-  "class_name": "TunnelExt",
-  "methods": ["Reset", "Randomize"]
-}'
-
-# 4. package
-tdmcp-agent component --params '{
-  "action": "save",
-  "comp_path": "/project1/tunnel",
-  "file_path": "/Users/me/td-components/tunnel.tox"
-}'
-```
-
-## Where to go next
-
-- [Prompt cookbook](/guide/prompt-cookbook) — ready-made prompts for building the
-  network you'll turn into a component.
-- [Tools reference](/reference/tools) — the full input schema for
-  `add_custom_parameters`, `scaffold_extension` and `manage_component`.