@draht/coding-agent 2026.3.2 → 2026.3.3

package/dist/modes/interactive/theme/dark.json

@@ -1,5 +1,5 @@
 {
-	"$schema": "https://raw.githubusercontent.com/badlogic/pi-mono/main/packages/coding-agent/src/modes/interactive/theme/theme-schema.json",
+	"$schema": "https://raw.githubusercontent.com/draht-dev/draht/main/packages/coding-agent/src/modes/interactive/theme/theme-schema.json",
 	"name": "dark",
 	"vars": {
 		"cyan": "#00d7ff",

package/dist/modes/interactive/theme/light.json

@@ -1,5 +1,5 @@
 {
-	"$schema": "https://raw.githubusercontent.com/badlogic/pi-mono/main/packages/coding-agent/src/modes/interactive/theme/theme-schema.json",
+	"$schema": "https://raw.githubusercontent.com/draht-dev/draht/main/packages/coding-agent/src/modes/interactive/theme/theme-schema.json",
 	"name": "light",
 	"vars": {
 		"teal": "#5a8080",

package/dist/prompts/commands/discuss-phase.md

@@ -8,12 +8,12 @@ Capture implementation decisions before planning a phase.
 ```
 
 ## Steps
-1. Run `draht phase-info N` to load phase context
+1. Run `draht-tools phase-info N` to load phase context
 2. Identify gray areas based on what's being built
 3. Present 1-2 questions at a time about preferences
 4. If `.planning/DOMAIN.md` exists, load it and validate discovered terms against the glossary. Add any new domain terms found during discussion.
-5. Record decisions with `draht save-context N`
-6. Commit: `draht commit-docs "capture phase N context"`
+5. Record decisions with `draht-tools save-context N`
+6. Commit: `draht-tools commit-docs "capture phase N context"`
 
 ## Gray Area Categories
 - **Visual features** → Layout, density, interactions, empty states

package/dist/prompts/commands/execute-phase.md

@@ -8,36 +8,36 @@ Execute all plans in a phase with atomic commits.
 ```
 
 ## Steps
-1. Run `draht discover-plans N` to find and order plans
+1. Run `draht-tools discover-plans N` to find and order plans
 2. For each plan in dependency order:
-   a. Load plan: `draht read-plan N P`
+   a. Load plan: `draht-tools read-plan N P`
    b. Execute each task in strict TDD cycle:
 
       **🔴 RED — Write failing tests first**
       - Write the test cases from `<test>`
       - Run tests — confirm they FAIL (if they pass, the test is wrong)
-      - Commit failing tests: `draht commit-task N P T "red: test description"`
+      - Commit failing tests: `draht-tools commit-task N P T "red: test description"`
 
       **🟢 GREEN — Minimal implementation**
       - Write the minimum code from `<action>` to make tests pass
       - Use domain language from `<context>` and `<domain>` for all names
       - Run tests — confirm they PASS
-      - Commit: `draht commit-task N P T "green: task name"`
+      - Commit: `draht-tools commit-task N P T "green: task name"`
 
       **🔵 REFACTOR — Clean up with safety net**
       - Apply improvements from `<refactor>` (if any)
       - Run tests after each change — must stay green
       - Verify domain language compliance (names match DOMAIN.md)
-      - Commit: `draht commit-task N P T "refactor: description"`
+      - Commit: `draht-tools commit-task N P T "refactor: description"`
 
       **✅ VERIFY**
       - Run the `<verify>` step
       - Confirm `<done>` criteria met
 
-   c. Write summary: `draht write-summary N P`
-3. Phase verification: `draht verify-phase N`
-4. Update state: `draht update-state`
-5. Final commit: `draht commit-docs "complete phase N execution"`
+   c. Write summary: `draht-tools write-summary N P`
+3. Phase verification: `draht-tools verify-phase N`
+4. Update state: `draht-tools update-state`
+5. Final commit: `draht-tools commit-docs "complete phase N execution"`
 
 ## TDD Rules
 - Never write implementation before a failing test exists

package/dist/prompts/commands/map-codebase.md

@@ -8,7 +8,7 @@ Analyze existing codebase before planning.
 ```
 
 ## Steps
-1. Run `draht map-codebase [dir]`
+1. Run `draht-tools map-codebase [dir]`
 2. Tool generates: STACK.md, ARCHITECTURE.md, CONVENTIONS.md, CONCERNS.md
 3. Review output, supplement with your own analysis if needed
 4. Identify implicit bounded contexts from directory structure:
@@ -29,4 +29,4 @@ Analyze existing codebase before planning.
    - Existing coverage configuration and goals (if any)
    - Which layers have tests today (unit, integration, e2e)
    - Gaps and recommendations
-8. Commit: `draht commit-docs "map existing codebase"`
+8. Commit: `draht-tools commit-docs "map existing codebase"`

package/dist/prompts/commands/new-project.md

@@ -8,11 +8,11 @@ Initialize a new GSD project: questioning → research → requirements → road
 ```
 
 ## Steps
-1. Run `draht init` to check preconditions
-2. If existing code detected, run `draht map-codebase` first
+1. Run `draht-tools init` to check preconditions
+2. If existing code detected, run `draht-tools map-codebase` first
 3. Deep questioning phase (3-7 rounds, 1-2 questions at a time)
-4. Run `draht create-project` with gathered info
-5. Run `draht create-domain-model` to define bounded contexts, entities, and ubiquitous language
+4. Run `draht-tools create-project` with gathered info
+5. Run `draht-tools create-domain-model` to define bounded contexts, entities, and ubiquitous language
 6. Create `.planning/DOMAIN.md` with:
    - `## Bounded Contexts` — each context with name, responsibility, and brief description
    - `## Ubiquitous Language` — glossary of domain terms agreed with the user (term → definition)
@@ -25,11 +25,11 @@ Initialize a new GSD project: questioning → research → requirements → road
    - `## Coverage Goals` — target coverage percentage and which paths are critical
    - `## Testing Levels` — what is tested at unit level vs integration vs e2e, with examples
    - `## Excluded` — what is explicitly not tested and why (config files, generated code, etc.)
-8. Optional research phase via `draht research`
-9. Run `draht create-requirements` with v1/v2/out-of-scope (map requirements to bounded contexts)
-10. Run `draht create-roadmap` with phases
-11. Run `draht init-state`
-12. Git commit via `draht commit-docs "initialize GSD project"`
+8. Optional research phase via `draht-tools research`
+9. Run `draht-tools create-requirements` with v1/v2/out-of-scope (map requirements to bounded contexts)
+10. Run `draht-tools create-roadmap` with phases
+11. Run `draht-tools init-state`
+12. Git commit via `draht-tools commit-docs "initialize GSD project"`
 
 ## Rules
 - Ask 1-2 questions at a time, never dump 10 at once

package/dist/prompts/commands/pause-work.md

@@ -8,5 +8,5 @@ Create a handoff document for session continuity.
 ```
 
 ## Steps
-1. Run `draht pause` — creates CONTINUE-HERE.md
-2. Commit: `draht commit-docs "pause work"`
+1. Run `draht-tools pause` — creates CONTINUE-HERE.md
+2. Commit: `draht-tools commit-docs "pause work"`

package/dist/prompts/commands/plan-phase.md

@@ -8,17 +8,17 @@ Create atomic execution plans for a roadmap phase.
 ```
 
 ## Steps
-1. Run `draht load-phase-context N` to gather all context
-2. Optional: `draht research-phase N` for domain research
+1. Run `draht-tools load-phase-context N` to gather all context
+2. Optional: `draht-tools research-phase N` for domain research
 3. Goal-backward planning:
    a. State the goal (outcome, not activity)
    b. Derive observable truths (3-7 from user perspective)
    c. From each observable truth, derive the test scenarios that would prove it (specific inputs → expected outputs or state changes)
    d. Map to required artifacts (files, endpoints, schemas)
    e. Break into atomic tasks (2-5 per plan)
-4. Write plans: `draht create-plan N P`
-5. Validate: `draht validate-plans N`
-6. Commit: `draht commit-docs "create phase N plans"`
+4. Write plans: `draht-tools create-plan N P`
+5. Validate: `draht-tools validate-plans N`
+6. Commit: `draht-tools commit-docs "create phase N plans"`
 
 ## Plan Format
 Plans use XML task format:

package/dist/prompts/commands/progress.md

@@ -8,5 +8,5 @@ Show current project status.
 ```
 
 ## Steps
-1. Run `draht progress` — outputs formatted status
+1. Run `draht-tools progress` — outputs formatted status
 2. Display the result as-is

package/dist/prompts/commands/quick.md

@@ -8,12 +8,12 @@ Execute a small ad-hoc task with GSD tracking.
 ```
 
 ## Steps
-1. Run `draht next-quick-number` to get task number
-2. Create quick plan: `draht create-quick-plan NNN "description"`
+1. Run `draht-tools next-quick-number` to get task number
+2. Create quick plan: `draht-tools create-quick-plan NNN "description"`
 3. Execute tasks following the TDD cycle:
    - **🔴 RED** — Write a failing test that describes the desired behaviour
    - **🟢 GREEN** — Write the minimum implementation to make it pass
    - **🔵 REFACTOR** — Clean up while keeping the test green
    - *Exception: skip the TDD cycle only for pure config or documentation-only tasks that have no testable behaviour*
-4. Write summary: `draht write-quick-summary NNN`
-5. Update state: `draht update-state`
+4. Write summary: `draht-tools write-quick-summary NNN`
+5. Update state: `draht-tools update-state`

package/dist/prompts/commands/resume-work.md

@@ -8,6 +8,6 @@ Resume from last session state.
 ```
 
 ## Steps
-1. Run `draht resume` — loads CONTINUE-HERE.md or STATE.md
+1. Run `draht-tools resume` — loads CONTINUE-HERE.md or STATE.md
 2. Display context and ask to continue
 3. Delete CONTINUE-HERE.md after confirmation

package/dist/prompts/commands/verify-work.md

@@ -15,13 +15,13 @@ Walk through acceptance testing of completed phase work.
    - Load `.planning/DOMAIN.md` and extract all defined terms
    - Scan source files for PascalCase identifiers not present in the glossary
    - Flag any bounded context boundary violations (cross-context direct imports)
-3. Run quality gate: `draht quality-gate --strict`
-4. Run `draht extract-deliverables N` to get testable items
+3. Run quality gate: `draht-tools quality-gate --strict`
+4. Run `draht-tools extract-deliverables N` to get testable items
 5. Walk user through each deliverable one at a time
 6. Record results (pass/fail/partially/skip)
-7. For failures: diagnose and create fix plans via `draht create-fix-plan N P`
+7. For failures: diagnose and create fix plans via `draht-tools create-fix-plan N P`
    - Fix plans MUST include a reproducing test that demonstrates the failure before any implementation
-8. Write UAT report: `draht write-uat N`
+8. Write UAT report: `draht-tools write-uat N`
    - Report must include: test health summary (pass/fail/coverage), domain model status (any glossary violations), deliverable results
 9. If all passed: mark phase complete
 10. If failures: route to `execute-phase N --gaps-only`

package/docs/compaction.md

@@ -2,14 +2,14 @@
 
 LLMs have limited context windows. When conversations grow too long, pi uses compaction to summarize older content while preserving recent work. This page covers both auto-compaction and branch summarization.
 
-**Source files** ([pi-mono](https://github.com/badlogic/pi-mono)):
-- [`packages/coding-agent/src/core/compaction/compaction.ts`](https://github.com/badlogic/pi-mono/blob/main/packages/coding-agent/src/core/compaction/compaction.ts) - Auto-compaction logic
-- [`packages/coding-agent/src/core/compaction/branch-summarization.ts`](https://github.com/badlogic/pi-mono/blob/main/packages/coding-agent/src/core/compaction/branch-summarization.ts) - Branch summarization
-- [`packages/coding-agent/src/core/compaction/utils.ts`](https://github.com/badlogic/pi-mono/blob/main/packages/coding-agent/src/core/compaction/utils.ts) - Shared utilities (file tracking, serialization)
-- [`packages/coding-agent/src/core/session-manager.ts`](https://github.com/badlogic/pi-mono/blob/main/packages/coding-agent/src/core/session-manager.ts) - Entry types (`CompactionEntry`, `BranchSummaryEntry`)
-- [`packages/coding-agent/src/core/extensions/types.ts`](https://github.com/badlogic/pi-mono/blob/main/packages/coding-agent/src/core/extensions/types.ts) - Extension event types
+**Source files** ([pi-mono](https://github.com/draht-dev/draht)):
+- [`packages/coding-agent/src/core/compaction/compaction.ts`](https://github.com/draht-dev/draht/blob/main/packages/coding-agent/src/core/compaction/compaction.ts) - Auto-compaction logic
+- [`packages/coding-agent/src/core/compaction/branch-summarization.ts`](https://github.com/draht-dev/draht/blob/main/packages/coding-agent/src/core/compaction/branch-summarization.ts) - Branch summarization
+- [`packages/coding-agent/src/core/compaction/utils.ts`](https://github.com/draht-dev/draht/blob/main/packages/coding-agent/src/core/compaction/utils.ts) - Shared utilities (file tracking, serialization)
+- [`packages/coding-agent/src/core/session-manager.ts`](https://github.com/draht-dev/draht/blob/main/packages/coding-agent/src/core/session-manager.ts) - Entry types (`CompactionEntry`, `BranchSummaryEntry`)
+- [`packages/coding-agent/src/core/extensions/types.ts`](https://github.com/draht-dev/draht/blob/main/packages/coding-agent/src/core/extensions/types.ts) - Extension event types
 
-For TypeScript definitions in your project, inspect `node_modules/@mariozechner/pi-coding-agent/dist/`.
+For TypeScript definitions in your project, inspect `node_modules/@draht/coding-agent/dist/`.
 
 ## Overview
 
@@ -116,7 +116,7 @@ Never cut at tool results (they must stay with their tool call).
 
 ### CompactionEntry Structure
 
-Defined in [`session-manager.ts`](https://github.com/badlogic/pi-mono/blob/main/packages/coding-agent/src/core/session-manager.ts):
+Defined in [`session-manager.ts`](https://github.com/draht-dev/draht/blob/main/packages/coding-agent/src/core/session-manager.ts):
 
 ```typescript
 interface CompactionEntry<T = unknown> {
@@ -140,7 +140,7 @@ interface CompactionDetails {
 
 Extensions can store any JSON-serializable data in `details`. The default compaction tracks file operations, but custom extension implementations can use their own structure.
 
-See [`prepareCompaction()`](https://github.com/badlogic/pi-mono/blob/main/packages/coding-agent/src/core/compaction/compaction.ts) and [`compact()`](https://github.com/badlogic/pi-mono/blob/main/packages/coding-agent/src/core/compaction/compaction.ts) for the implementation.
+See [`prepareCompaction()`](https://github.com/draht-dev/draht/blob/main/packages/coding-agent/src/core/compaction/compaction.ts) and [`compact()`](https://github.com/draht-dev/draht/blob/main/packages/coding-agent/src/core/compaction/compaction.ts) for the implementation.
 
 ## Branch Summarization
 
@@ -183,7 +183,7 @@ This means file tracking accumulates across multiple compactions or nested branc
 
 ### BranchSummaryEntry Structure
 
-Defined in [`session-manager.ts`](https://github.com/badlogic/pi-mono/blob/main/packages/coding-agent/src/core/session-manager.ts):
+Defined in [`session-manager.ts`](https://github.com/draht-dev/draht/blob/main/packages/coding-agent/src/core/session-manager.ts):
 
 ```typescript
 interface BranchSummaryEntry<T = unknown> {
@@ -206,7 +206,7 @@ interface BranchSummaryDetails {
 
 Same as compaction, extensions can store custom data in `details`.
 
-See [`collectEntriesForBranchSummary()`](https://github.com/badlogic/pi-mono/blob/main/packages/coding-agent/src/core/compaction/branch-summarization.ts), [`prepareBranchEntries()`](https://github.com/badlogic/pi-mono/blob/main/packages/coding-agent/src/core/compaction/branch-summarization.ts), and [`generateBranchSummary()`](https://github.com/badlogic/pi-mono/blob/main/packages/coding-agent/src/core/compaction/branch-summarization.ts) for the implementation.
+See [`collectEntriesForBranchSummary()`](https://github.com/draht-dev/draht/blob/main/packages/coding-agent/src/core/compaction/branch-summarization.ts), [`prepareBranchEntries()`](https://github.com/draht-dev/draht/blob/main/packages/coding-agent/src/core/compaction/branch-summarization.ts), and [`generateBranchSummary()`](https://github.com/draht-dev/draht/blob/main/packages/coding-agent/src/core/compaction/branch-summarization.ts) for the implementation.
 
 ## Summary Format
 
@@ -250,7 +250,7 @@ path/to/changed.ts
 
 ### Message Serialization
 
-Before summarization, messages are serialized to text via [`serializeConversation()`](https://github.com/badlogic/pi-mono/blob/main/packages/coding-agent/src/core/compaction/utils.ts):
+Before summarization, messages are serialized to text via [`serializeConversation()`](https://github.com/draht-dev/draht/blob/main/packages/coding-agent/src/core/compaction/utils.ts):
 
 ```
 [User]: What they said
@@ -264,7 +264,7 @@ This prevents the model from treating it as a conversation to continue.
 
 ## Custom Summarization via Extensions
 
-Extensions can intercept and customize both compaction and branch summarization. See [`extensions/types.ts`](https://github.com/badlogic/pi-mono/blob/main/packages/coding-agent/src/core/extensions/types.ts) for event type definitions.
+Extensions can intercept and customize both compaction and branch summarization. See [`extensions/types.ts`](https://github.com/draht-dev/draht/blob/main/packages/coding-agent/src/core/extensions/types.ts) for event type definitions.
 
 ### session_before_compact
 
@@ -305,7 +305,7 @@ pi.on("session_before_compact", async (event, ctx) => {
 To generate a summary with your own model, convert messages to text using `serializeConversation`:
 
 ```typescript
-import { convertToLlm, serializeConversation } from "@mariozechner/pi-coding-agent";
+import { convertToLlm, serializeConversation } from "@draht/coding-agent";
 
 pi.on("session_before_compact", async (event, ctx) => {
   const { preparation } = event;

package/docs/custom-provider.md

@@ -31,7 +31,7 @@ See these complete provider examples:
 ## Quick Reference
 
 ```typescript
-import type { ExtensionAPI } from "@mariozechner/pi-coding-agent";
+import type { ExtensionAPI } from "@draht/coding-agent";
 
 export default function (pi: ExtensionAPI) {
   // Override baseUrl for existing provider
@@ -200,7 +200,7 @@ pi.registerProvider("custom-api", {
 Add OAuth/SSO authentication that integrates with `/login`:
 
 ```typescript
-import type { OAuthCredentials, OAuthLoginCallbacks } from "@mariozechner/pi-ai";
+import type { OAuthCredentials, OAuthLoginCallbacks } from "@draht/ai";
 
 pi.registerProvider("corporate-ai", {
   baseUrl: "https://ai.corp.com/v1",
@@ -293,11 +293,11 @@ interface OAuthCredentials {
 For providers with non-standard APIs, implement `streamSimple`. Study the existing provider implementations before writing your own:
 
 **Reference implementations:**
-- [anthropic.ts](https://github.com/badlogic/pi-mono/blob/main/packages/ai/src/providers/anthropic.ts) - Anthropic Messages API
-- [openai-completions.ts](https://github.com/badlogic/pi-mono/blob/main/packages/ai/src/providers/openai-completions.ts) - OpenAI Chat Completions
-- [openai-responses.ts](https://github.com/badlogic/pi-mono/blob/main/packages/ai/src/providers/openai-responses.ts) - OpenAI Responses API
-- [google.ts](https://github.com/badlogic/pi-mono/blob/main/packages/ai/src/providers/google.ts) - Google Generative AI
-- [amazon-bedrock.ts](https://github.com/badlogic/pi-mono/blob/main/packages/ai/src/providers/amazon-bedrock.ts) - AWS Bedrock
+- [anthropic.ts](https://github.com/draht-dev/draht/blob/main/packages/ai/src/providers/anthropic.ts) - Anthropic Messages API
+- [openai-completions.ts](https://github.com/draht-dev/draht/blob/main/packages/ai/src/providers/openai-completions.ts) - OpenAI Chat Completions
+- [openai-responses.ts](https://github.com/draht-dev/draht/blob/main/packages/ai/src/providers/openai-responses.ts) - OpenAI Responses API
+- [google.ts](https://github.com/draht-dev/draht/blob/main/packages/ai/src/providers/google.ts) - Google Generative AI
+- [amazon-bedrock.ts](https://github.com/draht-dev/draht/blob/main/packages/ai/src/providers/amazon-bedrock.ts) - AWS Bedrock
 
 ### Stream Pattern
 
@@ -312,7 +312,7 @@ import {
   type SimpleStreamOptions,
   calculateCost,
   createAssistantMessageEventStream,
-} from "@mariozechner/pi-ai";
+} from "@draht/ai";
 
 function streamMyProvider(
   model: Model<any>,
@@ -469,7 +469,7 @@ pi.registerProvider("my-provider", {
 
 ## Testing Your Implementation
 
-Test your provider against the same test suites used by built-in providers. Copy and adapt these test files from [packages/ai/test/](https://github.com/badlogic/pi-mono/tree/main/packages/ai/test):
+Test your provider against the same test suites used by built-in providers. Copy and adapt these test files from [packages/ai/test/](https://github.com/draht-dev/draht/tree/main/packages/ai/test):
 
 | Test | Purpose |
 |------|---------|

package/docs/development.md

@@ -5,7 +5,7 @@ See [AGENTS.md](../../../AGENTS.md) for additional guidelines.
 ## Setup
 
 ```bash
-git clone https://github.com/badlogic/pi-mono
+git clone https://github.com/draht-dev/draht
 cd pi-mono
 npm install
 npm run build

package/docs/extensions.md

@@ -55,7 +55,7 @@ See [examples/extensions/](../examples/extensions/) for working implementations.
 Create `~/.pi/agent/extensions/my-extension.ts`:
 
 ```typescript
-import type { ExtensionAPI } from "@mariozechner/pi-coding-agent";
+import type { ExtensionAPI } from "@draht/coding-agent";
 import { Type } from "@sinclair/typebox";
 
 export default function (pi: ExtensionAPI) {
@@ -137,10 +137,10 @@ To share extensions via npm or git as pi packages, see [packages.md](packages.md
 
 | Package | Purpose |
 |---------|---------|
-| `@mariozechner/pi-coding-agent` | Extension types (`ExtensionAPI`, `ExtensionContext`, events) |
+| `@draht/coding-agent` | Extension types (`ExtensionAPI`, `ExtensionContext`, events) |
 | `@sinclair/typebox` | Schema definitions for tool parameters |
-| `@mariozechner/pi-ai` | AI utilities (`StringEnum` for Google-compatible enums) |
-| `@mariozechner/pi-tui` | TUI components for custom rendering |
+| `@draht/ai` | AI utilities (`StringEnum` for Google-compatible enums) |
+| `@draht/tui` | TUI components for custom rendering |
 
 npm dependencies work too. Add a `package.json` next to your extension (or in a parent directory), run `npm install`, and imports from `node_modules/` are resolved automatically.
 
@@ -151,7 +151,7 @@ Node.js built-ins (`node:fs`, `node:path`, etc.) are also available.
 An extension exports a default function that receives `ExtensionAPI`:
 
 ```typescript
-import type { ExtensionAPI } from "@mariozechner/pi-coding-agent";
+import type { ExtensionAPI } from "@draht/coding-agent";
 
 export default function (pi: ExtensionAPI) {
   // Subscribe to events
@@ -519,7 +519,7 @@ Use this to update UI elements (status bars, footers) or perform model-specific
 Fired before tool executes. **Can block.** Use `isToolCallEventType` to narrow and get typed inputs.
 
 ```typescript
-import { isToolCallEventType } from "@mariozechner/pi-coding-agent";
+import { isToolCallEventType } from "@draht/coding-agent";
 
 pi.on("tool_call", async (event, ctx) => {
   // event.toolName - "bash", "read", "write", "edit", etc.
@@ -553,7 +553,7 @@ export type MyToolInput = Static<typeof myToolSchema>;
 Use `isToolCallEventType` with explicit type parameters:
 
 ```typescript
-import { isToolCallEventType } from "@mariozechner/pi-coding-agent";
+import { isToolCallEventType } from "@draht/coding-agent";
 import type { MyToolInput } from "my-extension";
 
 pi.on("tool_call", (event) => {
@@ -573,7 +573,7 @@ Fired after tool executes. **Can modify result.**
 - Handlers can return partial patches (`content`, `details`, or `isError`); omitted fields keep their current values
 
 ```typescript
-import { isBashToolResult } from "@mariozechner/pi-coding-agent";
+import { isBashToolResult } from "@draht/coding-agent";
 
 pi.on("tool_result", async (event, ctx) => {
   // event.toolName, event.toolCallId, event.input
@@ -843,7 +843,7 @@ Tools run with `ExtensionContext`, so they cannot call `ctx.reload()` directly.
 Example tool the LLM can call to trigger reload:
 
 ```typescript
-import type { ExtensionAPI } from "@mariozechner/pi-coding-agent";
+import type { ExtensionAPI } from "@draht/coding-agent";
 import { Type } from "@sinclair/typebox";
 
 export default function (pi: ExtensionAPI) {
@@ -882,7 +882,7 @@ Register a custom tool callable by the LLM. See [Custom Tools](#custom-tools) fo
 
 ```typescript
 import { Type } from "@sinclair/typebox";
-import { StringEnum } from "@mariozechner/pi-ai";
+import { StringEnum } from "@draht/ai";
 
 pi.registerTool({
   name: "my_tool",
@@ -1030,7 +1030,7 @@ pi.registerCommand("stats", {
 Optional: add argument auto-completion for `/command ...`:
 
 ```typescript
-import type { AutocompleteItem } from "@mariozechner/pi-tui";
+import type { AutocompleteItem } from "@draht/tui";
 
 pi.registerCommand("deploy", {
   description: "Deploy to an environment",
@@ -1282,8 +1282,8 @@ Note: Some models are idiots and include the @ prefix in tool path arguments. Bu
 
 ```typescript
 import { Type } from "@sinclair/typebox";
-import { StringEnum } from "@mariozechner/pi-ai";
-import { Text } from "@mariozechner/pi-tui";
+import { StringEnum } from "@draht/ai";
+import { Text } from "@draht/tui";
 
 pi.registerTool({
   name: "my_tool",
@@ -1322,7 +1322,7 @@ pi.registerTool({
 });
 ```
 
-**Important:** Use `StringEnum` from `@mariozechner/pi-ai` for string enums. `Type.Union`/`Type.Literal` doesn't work with Google's API.
+**Important:** Use `StringEnum` from `@draht/ai` for string enums. `Type.Union`/`Type.Literal` doesn't work with Google's API.
 
 ### Overriding Built-in Tools
 
@@ -1346,20 +1346,20 @@ See [examples/extensions/tool-override.ts](../examples/extensions/tool-override.
 **Your implementation must match the exact result shape**, including the `details` type. The UI and session logic depend on these shapes for rendering and state tracking.
 
 Built-in tool implementations:
-- [read.ts](https://github.com/badlogic/pi-mono/blob/main/packages/coding-agent/src/core/tools/read.ts) - `ReadToolDetails`
-- [bash.ts](https://github.com/badlogic/pi-mono/blob/main/packages/coding-agent/src/core/tools/bash.ts) - `BashToolDetails`
-- [edit.ts](https://github.com/badlogic/pi-mono/blob/main/packages/coding-agent/src/core/tools/edit.ts)
-- [write.ts](https://github.com/badlogic/pi-mono/blob/main/packages/coding-agent/src/core/tools/write.ts)
-- [grep.ts](https://github.com/badlogic/pi-mono/blob/main/packages/coding-agent/src/core/tools/grep.ts) - `GrepToolDetails`
-- [find.ts](https://github.com/badlogic/pi-mono/blob/main/packages/coding-agent/src/core/tools/find.ts) - `FindToolDetails`
-- [ls.ts](https://github.com/badlogic/pi-mono/blob/main/packages/coding-agent/src/core/tools/ls.ts) - `LsToolDetails`
+- [read.ts](https://github.com/draht-dev/draht/blob/main/packages/coding-agent/src/core/tools/read.ts) - `ReadToolDetails`
+- [bash.ts](https://github.com/draht-dev/draht/blob/main/packages/coding-agent/src/core/tools/bash.ts) - `BashToolDetails`
+- [edit.ts](https://github.com/draht-dev/draht/blob/main/packages/coding-agent/src/core/tools/edit.ts)
+- [write.ts](https://github.com/draht-dev/draht/blob/main/packages/coding-agent/src/core/tools/write.ts)
+- [grep.ts](https://github.com/draht-dev/draht/blob/main/packages/coding-agent/src/core/tools/grep.ts) - `GrepToolDetails`
+- [find.ts](https://github.com/draht-dev/draht/blob/main/packages/coding-agent/src/core/tools/find.ts) - `FindToolDetails`
+- [ls.ts](https://github.com/draht-dev/draht/blob/main/packages/coding-agent/src/core/tools/ls.ts) - `LsToolDetails`
 
 ### Remote Execution
 
 Built-in tools support pluggable operations for delegating to remote systems (SSH, containers, etc.):
 
 ```typescript
-import { createReadTool, createBashTool, type ReadOperations } from "@mariozechner/pi-coding-agent";
+import { createReadTool, createBashTool, type ReadOperations } from "@draht/coding-agent";
 
 // Create tool with custom operations
 const remoteRead = createReadTool(cwd, {
@@ -1388,7 +1388,7 @@ pi.registerTool({
 The bash tool also supports a spawn hook to adjust the command, cwd, or env before execution:
 
 ```typescript
-import { createBashTool } from "@mariozechner/pi-coding-agent";
+import { createBashTool } from "@draht/coding-agent";
 
 const bashTool = createBashTool(cwd, {
   spawnHook: ({ command, cwd, env }) => ({
@@ -1418,7 +1418,7 @@ import {
   formatSize,        // Human-readable size (e.g., "50KB", "1.5MB")
   DEFAULT_MAX_BYTES, // 50KB
   DEFAULT_MAX_LINES, // 2000
-} from "@mariozechner/pi-coding-agent";
+} from "@draht/coding-agent";
 
 async execute(toolCallId, params, signal, onUpdate, ctx) {
   const output = await runCommand();
@@ -1473,7 +1473,7 @@ export default function (pi: ExtensionAPI) {
 
 ### Custom Rendering
 
-Tools can provide `renderCall` and `renderResult` for custom TUI display. See [tui.md](tui.md) for the full component API and [tool-execution.ts](https://github.com/badlogic/pi-mono/blob/main/packages/coding-agent/src/modes/interactive/components/tool-execution.ts) for how built-in tools render.
+Tools can provide `renderCall` and `renderResult` for custom TUI display. See [tui.md](tui.md) for the full component API and [tool-execution.ts](https://github.com/draht-dev/draht/blob/main/packages/coding-agent/src/modes/interactive/components/tool-execution.ts) for how built-in tools render.
 
 Tool output is wrapped in a `Box` that handles padding and background. Your render methods return `Component` instances (typically `Text`).
 
@@ -1482,7 +1482,7 @@ Tool output is wrapped in a `Box` that handles padding and background. Your rend
 Renders the tool call (before/during execution):
 
 ```typescript
-import { Text } from "@mariozechner/pi-tui";
+import { Text } from "@draht/tui";
 
 renderCall(args, theme) {
   let text = theme.fg("toolTitle", theme.bold("my_tool "));
@@ -1526,7 +1526,7 @@ renderResult(result, { expanded, isPartial }, theme) {
 Use `keyHint()` to display keybinding hints that respect user's keybinding configuration:
 
 ```typescript
-import { keyHint } from "@mariozechner/pi-coding-agent";
+import { keyHint } from "@draht/coding-agent";
 
 renderResult(result, { expanded }, theme) {
   let text = theme.fg("success", "✓ Done");
@@ -1700,7 +1700,7 @@ ctx.ui.theme.fg("accent", "styled text");  // Access current theme
 For complex UI, use `ctx.ui.custom()`. This temporarily replaces the editor with your component until `done()` is called:
 
 ```typescript
-import { Text, Component } from "@mariozechner/pi-tui";
+import { Text, Component } from "@draht/tui";
 
 const result = await ctx.ui.custom<boolean>((tui, theme, keybindings, done) => {
   const text = new Text("Press Enter to confirm, Escape to cancel", 1, 1);
@@ -1758,8 +1758,8 @@ See [tui.md](tui.md) for the full `OverlayOptions` API and [overlay-qa-tests.ts]
 Replace the main input editor with a custom implementation (vim mode, emacs mode, etc.):
 
 ```typescript
-import { CustomEditor, type ExtensionAPI } from "@mariozechner/pi-coding-agent";
-import { matchesKey } from "@mariozechner/pi-tui";
+import { CustomEditor, type ExtensionAPI } from "@draht/coding-agent";
+import { matchesKey } from "@draht/tui";
 
 class VimEditor extends CustomEditor {
   private mode: "normal" | "insert" = "insert";
@@ -1799,7 +1799,7 @@ See [tui.md](tui.md) Pattern 7 for a complete example with mode indicator.
 Register a custom renderer for messages with your `customType`:
 
 ```typescript
-import { Text } from "@mariozechner/pi-tui";
+import { Text } from "@draht/tui";
 
 pi.registerMessageRenderer("my-extension", (message, options, theme) => {
   const { expanded } = options;
@@ -1848,7 +1848,7 @@ theme.strikethrough(text)
 For syntax highlighting in custom tool renderers:
 
 ```typescript
-import { highlightCode, getLanguageFromPath } from "@mariozechner/pi-coding-agent";
+import { highlightCode, getLanguageFromPath } from "@draht/coding-agent";
 
 // Highlight code with explicit language
 const highlighted = highlightCode("const x = 1;", "typescript", theme);

package/docs/json.md

@@ -8,7 +8,7 @@ Outputs all session events as JSON lines to stdout. Useful for integrating pi in
 
 ## Event Types
 
-Events are defined in [`AgentSessionEvent`](https://github.com/badlogic/pi-mono/blob/main/packages/coding-agent/src/core/agent-session.ts#L102):
+Events are defined in [`AgentSessionEvent`](https://github.com/draht-dev/draht/blob/main/packages/coding-agent/src/core/agent-session.ts#L102):
 
 ```typescript
 type AgentSessionEvent =
@@ -19,7 +19,7 @@ type AgentSessionEvent =
   | { type: "auto_retry_end"; success: boolean; attempt: number; finalError?: string };
 ```
 
-Base events from [`AgentEvent`](https://github.com/badlogic/pi-mono/blob/main/packages/agent/src/types.ts#L179):
+Base events from [`AgentEvent`](https://github.com/draht-dev/draht/blob/main/packages/agent/src/types.ts#L179):
 
 ```typescript
 type AgentEvent =
@@ -41,12 +41,12 @@ type AgentEvent =
 
 ## Message Types
 
-Base messages from [`packages/ai/src/types.ts`](https://github.com/badlogic/pi-mono/blob/main/packages/ai/src/types.ts#L134):
+Base messages from [`packages/ai/src/types.ts`](https://github.com/draht-dev/draht/blob/main/packages/ai/src/types.ts#L134):
 - `UserMessage` (line 134)
 - `AssistantMessage` (line 140)
 - `ToolResultMessage` (line 152)
 
-Extended messages from [`packages/coding-agent/src/core/messages.ts`](https://github.com/badlogic/pi-mono/blob/main/packages/coding-agent/src/core/messages.ts#L29):
+Extended messages from [`packages/coding-agent/src/core/messages.ts`](https://github.com/draht-dev/draht/blob/main/packages/coding-agent/src/core/messages.ts#L29):
 - `BashExecutionMessage` (line 29)
 - `CustomMessage` (line 46)
 - `BranchSummaryMessage` (line 55)

package/docs/packages.md

@@ -149,7 +149,7 @@ If no `pi` manifest is present, pi auto-discovers resources from these directori
 
 Third party runtime dependencies belong in `dependencies` in `package.json`. Dependencies that do not register extensions, skills, prompt templates, or themes also belong in `dependencies`. When pi installs a package from npm or git, it runs `npm install`, so those dependencies are installed automatically.
 
-Pi bundles core packages for extensions and skills. If you import any of these, list them in `peerDependencies` with a `"*"` range and do not bundle them: `@mariozechner/pi-ai`, `@mariozechner/pi-agent-core`, `@mariozechner/pi-coding-agent`, `@mariozechner/pi-tui`, `@sinclair/typebox`.
+Pi bundles core packages for extensions and skills. If you import any of these, list them in `peerDependencies` with a `"*"` range and do not bundle them: `@draht/ai`, `@draht/agent-core-core`, `@draht/coding-agent`, `@draht/tui`, `@sinclair/typebox`.
 
 Other pi packages must be bundled in your tarball. Add them to `dependencies` and `bundledDependencies`, then reference their resources through `node_modules/` paths. Pi loads packages with separate module roots, so separate installs do not collide or share modules.