command-code 1.4.1 → 1.4.3

package/dist/bundled/mod-builder/reference/overview.md

@@ -9,19 +9,24 @@ Mods are TypeScript packages that let you modify almost any behavior of Command
 A loadable mod IS an `AgentMod` once loaded; the mod host just builds it from a factory file instead of a code import:
 
 ```bash
-~/.commandcode/mods/review-guard.ts        one file = one mod
-        │
-        ▼  jiti (TypeScript, no build step)
+~/.commandcode/mods/review-guard.ts
+        │                one file = one mod
+        ▼  jiti · TypeScript, no build step
 default-export factory(cmd: ModApi)
         │
         ▼  createModHost().register(...)
-hooks + addTool  ──►  ONE AgentMod (id `mod:<name>`), appended after the built-ins
-addCommand       ──►  /slash dispatch + autocomplete in the TUI
-on(event)        ──►  AgentEvent bus subscription (observe-only)
-hooks.transformInput ─►  typed-prompt interception (transform / consume)
-addProvider      ──►  ProviderModule appended to the host's provider set
-addRenderer      ──►  custom feed entries (showEntry → styled lines in the TUI)
-queueMessage     ──►  the loop's steering / follow-up drains
+hooks + addTool      ──►  ONE AgentMod
+                          id `mod:<name>`,
+                          appended after built-ins
+addCommand           ──►  /slash dispatch
+                          + TUI autocomplete
+on(event)            ──►  AgentEvent bus
+                          (observe-only)
+hooks.transformInput ──►  typed-prompt
+                          interception
+addProvider          ──►  ProviderModule
+addRenderer          ──►  custom feed entries
+queueMessage         ──►  steering drains
 ```
 
 The factory receives the API bound as `cmd`. Registration verbs are all `add*` and each returns a `Disposable` - call `.dispose()` to undo exactly that one registration.
@@ -189,7 +194,15 @@ Built-in mods always win a name collision against a discovered mod of the same n
 
 ## Runnable examples
 
-Runnable, single-file example mods ship with Command Code inside the bundled `mod-builder` skill (`src/skills/bundled/mod-builder/examples/`) and are validated in CI - they load through the real loader on every test run, so they never rot. Ask Command Code to "build a mod" and it reads these.
+Command Code ships runnable, single-file example mods and reads them itself. You don't need to find them on disk - just ask:
+
+```
+build a mod that blocks dangerous shell commands
+```
+
+Command Code opens the matching example and works from it. Every example loads through the real mod loader in CI on every test run, so what it copies is proven to load.
+
+Ask for any of these by name or by what you want:
 
 | File | Shows |
 |---|---|
@@ -215,7 +228,7 @@ Runnable, single-file example mods ship with Command Code inside the bundled `mo
 - **Reload is the `/reload` path.** Mods load once per process; `/reload` restarts the process, which re-discovers and re-imports every mod (jiti caches nothing between loads). There is no in-place hot swap.
 - **Session controls stop at the harness surface.** `cmd.sessions` covers what the live harness owns (compact, tree, navigate, labels); creating/switching/forking sessions is host lifecycle, not harness state, and stays with the host UI.
 
-Embedders wire the same machinery directly: `createModHost` + `loadMods` + `createHarness({modHost})` (or `createNodeHarnessSession({modHost})`). See `packages/harness/src/mod-host/` for the pieces and its `__tests__/` for executable examples.
+Embedders wire the same machinery directly: `createModHost` + `loadMods` + `createHarness({modHost})` (or `createNodeHarnessSession({modHost})`), all exported from `@commandcode/harness`.
 
 ---
 

package/dist/bundled/mod-builder/reference/verify.md

@@ -55,4 +55,4 @@ Print mode loads user-scope and `--mod` mods with the UI bridge degraded to dete
 
 ## Working from the bundled examples
 
-Command Code ships runnable single-file examples inside the bundled `mod-builder` skill - each one loads through the real mod loader in CI on every test run, so copying one is copying something proven to load. In the Command Code repo itself, the same validation is a vitest suite (`packages/harness/src/mod-host/__tests__/examples.test.ts`); if you are contributing an example, that test must stay green.
+Ask Command Code to build the mod you want and it starts from a bundled example rather than a blank file - see [Runnable examples](./overview.md#runnable-examples) for the list. Each one loads through the real mod loader in CI on every test run, so what you start from is proven to load.