command-code 1.1.0 → 1.1.1

package/CHANGELOG.md

@@ -1,11 +1,35 @@
 # command-code
 
+## 1.1.1
+
+### Patch Changes
+
+- fix: capture the real cause when a self-update fails (#3047)
+- 11e7eb1: fix: mods calling `cmd.ui.setStatus` / `cmd.ui.widget` / `cmd.ui.refreshWidgets` no longer crash
+
+    These methods are documented in the mod-builder UI reference but were never present on the `ModUi` runtime, so any mod written against the docs threw `cmd.ui.setStatus is not a function` (surfaced as a `mod_error`). They are now safe, inert no-ops (rendering into the TUI is still pending) and the docs say so.
+
+- cd3452a: fix: capture the real cause when a self-update fails
+
+    `executeUpdate` swallowed the underlying `exec` error and returned a bare
+    `false`, so every update failure was tracked as a generic `Update failed:
+<from> -> <to>` with no way to tell a permission denial from a network drop
+    from a timeout. The install error (exit code, signal, and stderr tail) is now
+    threaded through `performAutoUpdate` → `UpdateFailureReport` into the failure
+    telemetry (`cmd.update.failure_reason` / `update.failure_reason` and the error
+    message) for the CLI, TUI, and `cmd update` paths.
+
 ## 1.1.0
 
 ### Minor Changes
 
+- feat: improve mods and cmd knowledge internal docs
+
+## 1.0.1
+
+### Patch Changes
+
 - fix: /reload header
-  feat: improve mods and cmd knowledge internal docs
 
 ## 1.0.0
 

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

@@ -30,6 +30,74 @@ This page is the whole mods surface end to end: the quick start and loading rule
 
 ---
 
+## Just ask Command Code to build it
+
+You rarely need to hand-write a mod. Command Code already knows this entire API - describe the behavior you want and it writes the mod, loads it with `--mod`, and iterates until it works. The fastest way in is to ask what's possible, then ask for the one you want:
+
+```text copy filename="Prompt"
+What kinds of mods can I build for Command Code? Show me a few examples.
+```
+
+```text copy filename="Prompt"
+Build me a mod that roasts me every time I greet you with "hi".
+```
+
+```text copy filename="Prompt"
+Add a /standup slash command that summarizes what changed in git today.
+```
+
+```text copy filename="Prompt"
+Block any shell command containing "rm -rf" unless I confirm it first.
+```
+
+Under the hood it reads the [bundled examples](#runnable-examples) and writes against the same `ModApi` this page documents. When it's done, `cmd --mod ./your-mod.ts` tries it instantly - no build step.
+
+### A real one, built by asking
+
+[`cmd-mod-hi`](https://github.com/ahmadawais/cmd-mod-hi) started as exactly that prompt - "roast me when I say hi" - and shipped to npm. Install it and greet your agent:
+
+```bash
+cmd mods add npm:cmd-mod-hi -g
+```
+
+Then type `hi`, `yo`, `howdy`, or `hello` and watch it judge you; `/hi-stats` tallies the damage. The whole mod is one `transformInput` hook plus a renderer:
+
+```ts
+import type {ModApi} from '@commandcode/harness';
+
+const roasts = [
+	'"hi" — bold. groundbreaking. truly pushing the boundaries of human communication.',
+	'you typed "hi" and pressed enter. your ancestors are weeping.',
+	// …a dozen more
+];
+
+let greetingCount = 0;
+
+export default function (cmd: ModApi): void {
+	cmd.addRenderer('hi-roast', (data: {text: string}) => ['[cmd-mod-hi]: ' + data.text]);
+
+	cmd.addCommand({
+		name: 'hi-stats',
+		description: 'See how many times you\'ve been roasted for saying "hi"',
+		handler: () => ({message: `[cmd-mod-hi]: You've been roasted ${greetingCount} times.`}),
+	});
+
+	cmd.hooks({
+		transformInput({text}) {
+			if (/^(hi|hello|hey|yo|sup|howdy)[.!?\s]*$/.test(text.trim().toLowerCase())) {
+				greetingCount += 1;
+				cmd.showEntry('hi-roast', {text: roasts[greetingCount % roasts.length]});
+			}
+			return undefined; // let the greeting through - the roast is a side show
+		},
+	});
+}
+```
+
+Want to understand what it's doing, or write one by hand? The rest of this page is the full reference.
+
+---
+
 ## Quick start
 
 Create `~/.commandcode/mods/review-guard.ts`:
@@ -133,7 +201,6 @@ Runnable, single-file example mods ship with Command Code inside the bundled `mo
 | `custom-entry-renderer.ts` | `addRenderer` + `showEntry` - styled feed rows |
 | `flags-and-options.ts` | `addFlag` / `getFlag` + `--mod-option` |
 | `lifecycle-hooks.ts` | `hooks.onStop` (Stop) + `onSessionStart`/`onSessionEnd` + `afterToolCall` `isError` + `on('subagent_start'/'subagent_stop')` |
-| `status-and-widgets.ts` | `ui.setStatus` footer segment + `ui.widget` above the editor + a timed confirm |
 | `kitchen-sink.ts` | every capability in one annotated file |
 
 ---

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

@@ -21,11 +21,11 @@ const proceed = await cmd.ui.confirm({
 });
 ```
 
-## Footer status segments
+## Footer status segments and editor widgets
 
-`cmd.ui.setStatus(text | null)` - a persistent per-mod segment in the TUI footer (under the input panel). One segment per mod: a new call replaces the text, `null` clears it, the returned `Disposable` clears it too. Segments from multiple mods concatenate in load order. Headless: renders nowhere (no-op).
+> **Not wired into the TUI yet.** `cmd.ui.setStatus`, `cmd.ui.widget`, and `cmd.ui.refreshWidgets` exist on the surface and are safe to call - they never throw and return the documented `Disposable` - but they currently render **nowhere** (no-op everywhere, interactive and headless alike). The contract below is the intended design; wire-up is pending. Build against it, but don't rely on anything appearing on screen today.
 
-## Editor widgets
+`cmd.ui.setStatus(text | null)` - a persistent per-mod segment in the TUI footer (under the input panel). One segment per mod: a new call replaces the text, `null` clears it, the returned `Disposable` clears it too. Segments from multiple mods concatenate in load order. Headless: renders nowhere (no-op).
 
 `cmd.ui.widget({placement: 'above-editor' | 'below-editor', render: () => lines})` - a line-based widget the TUI renders around the input panel. Same verbatim-lines contract as `addRenderer` (style with ansi); `render` re-runs on every repaint, and `cmd.ui.refreshWidgets()` requests a repaint after your data changes. A throwing render is skipped (reported as a `mod_error`) so siblings keep rendering. Headless: no-op.
 
@@ -56,8 +56,6 @@ Rendering is deliberately **line-based, not component-based**: mods return style
 | `confirm` | modal | resolves `false` |
 | `select` / `input` | modal | resolves `undefined` |
 | timed dialog | countdown, auto-resolve at deadline | resolves `timeoutValue` immediately |
-| `setStatus` | footer segment | no-op |
-| `widget` | rendered around the editor | no-op |
+| `setStatus` | no-op (wire-up pending) | no-op |
+| `widget` | no-op (wire-up pending) | no-op |
 | `showEntry` | rendered feed row | dropped |
-
-The `status-and-widgets.ts` bundled example exercises all of this in one file - see [Runnable examples](./overview.md#runnable-examples).