localpi 0.5.0 → 0.6.0

package/docs/2026-09-24-continue-on-truncation-plan.md

@@ -0,0 +1,115 @@
+---
+date: 2026-09-24
+author: Onur Solmaz
+title: Continue on truncation for localpi
+tags:
+  - localpi
+  - pi
+  - plan
+---
+
+# Continue on truncation for localpi
+
+## Status
+
+Planned. This document is the selected plan for the feature. It is the only source to follow.
+
+## Goal
+
+Give localpi an opt-in way to continue a Pi turn that stopped because it hit the output token limit.
+
+A truncated final reply is worthless in a batch run: the model stops mid-answer, the harness ends the
+run, and a verifier scores the half-written result as zero. Measured on the ShellBench Structured
+suite, this happened in 16 of 89 tasks with one model and 6 of 89 with another.
+
+The feature is off by default. A normal launch must behave exactly as it does today.
+
+## Design
+
+Today localpi declares the served limits itself: `--context-window` and `--max-tokens` (default
+8192). Pi stops a turn when the reply reaches the declared output cap and reports the turn as
+complete. localpi does nothing about it, so the reply stays truncated.
+
+Design rules:
+
+- Opt-in only. No flag and no environment variable means the current behavior, byte for byte.
+- Flag, then environment, then default, like every other localpi option.
+- Every default needs a flag or an environment variable, per `docs/design-principles.md`.
+- The guard is a Pi extension that uses only the documented public Pi extension API.
+- One implementation. The harness repository must not carry a second copy afterward.
+
+### Interface
+
+| Interface                            | Meaning                                                                      |
+| ------------------------------------ | ---------------------------------------------------------------------------- |
+| `--continue-on-truncation <n>`       | Continue at most `n` extra times when a turn ends on the output token limit. |
+| `LOCALPI_CONTINUE_ON_TRUNCATION=<n>` | Same meaning from the environment.                                           |
+| absent                               | Feature off.                                                                 |
+
+`n` must be a positive integer. `0` means off and is allowed only from the environment, so an
+operator can disable an inherited value without dropping the variable. An invalid `n` fails with one
+clear message and exit code 2, like the other option errors.
+
+### Behavior
+
+- Detect the truncation stop reason on the turn-end hook. Pi reports a turn that reached the output
+  cap as a length stop, so no guessing is needed.
+- Send exactly one follow-up user message that tells the model to continue where it stopped and not
+  to repeat earlier text.
+- Count continuations per session. Stop after `n` and let the run end normally, so the feature cannot
+  loop forever.
+- Never continue a turn that ended for any other reason, including a normal stop, a tool-only turn,
+  an error stop, or a user cancellation.
+- Write warnings and notes to stderr only. stdout stays free for protocol bytes and batch output.
+- The generated extension carries the limit inside its own source, like the other generated extension
+  sources, so no extra environment variable reaches the child.
+
+### Where the code goes
+
+- `src/pi/extension-sources/continue-on-truncation.ts`: the generated Pi extension source, plus the
+  factory that bakes the limit into it.
+- `src/pi/extensions.ts`: add the extension to the bundle only when the feature is enabled.
+- `src/localpi/options.ts`: the `continueOnTruncation` option, its flag, its environment variable, the
+  usage line, and its validation.
+- `src/cli/cli.ts`: pass the resolved value into the extension bundle.
+
+The extension source follows the existing pattern of the other `extension-sources` modules. The
+optional feature stays out of the runtime resolution path, so discovery, Pi config generation, and
+process launching keep their current separation.
+
+## Deliverables
+
+1. The new extension source module and its wiring.
+2. The option, the flag, the environment variable, the usage line, and validation.
+3. Tests: option parsing and validation, the extension bundle containing the guard only when it is
+   enabled, a truncated turn producing exactly one continuation message, the continuation count
+   stopping at `n`, and a non-truncated turn producing no continuation.
+4. A README section for the feature.
+5. An entry in `docs/runtime-specification.md` and a section in `docs/implementation-plan.md`.
+
+## Acceptance
+
+- `npm run check` passes, including `prettier --check`, `eslint`, `tsc --noEmit`, the full test
+  suite, and the build.
+- The tests prove the off-by-default behavior is unchanged, the enabled behavior continues at most
+  `n` times, and a non-truncated turn is untouched.
+- The coverage thresholds stay satisfied.
+- No generated output, model response, session file, or secret is committed.
+
+## Out of scope
+
+- Publishing to npm and creating a release.
+- Any change to the harness repository, including its existing guard and its published artifacts.
+- Any change to the thinking budget, the model profile limits, or the ACP mode contract.
+- Any change to a normal launch when the feature is off.
+
+## Constraints
+
+- Follow `AGENTS.md`: strict TypeScript, no `any`, validate unknown JSON at the boundary.
+- Keep local model discovery, Pi config generation, and process launching in separate modules.
+- Add or update tests for every behavior change.
+- Keep mutation testing out of the default gate.
+- Keep `@earendil-works/pi-coding-agent` a devDependency on the newest Pi release and keep the
+  generated-extension typecheck test.
+- Keep `@osolmaz/pi-factory` on the newest published version.
+- Use Conventional Commits, and add no coding agent branding.

package/docs/design-principles.md

@@ -0,0 +1,114 @@
+# Localpi Design Principles
+
+This document records the principles that shape localpi. Use it to decide how a new feature
+should look, and to judge whether a proposed change fits the project.
+
+## Simple
+
+Localpi does one job: connect Pi to local inference engines, then get out of the way.
+
+- Prefer the smallest change that solves the real problem.
+- Prefer one obvious way to do a thing over three configurable ways.
+- Do not add a second mechanism when the first one only needs a small extension.
+- Keep output short. A status line that reads well at a glance beats a dashboard.
+- Do not build infrastructure for a problem you can observe directly.
+
+## Unopinionated
+
+Localpi has a default for every choice, and none of the defaults are permanent.
+
+- Pick a sensible default, then make it changeable.
+- Never hard-code one vendor's behavior into another vendor's path.
+- Detect the engine instead of assuming it. When detection is impossible, say so and continue.
+- Report facts, not verdicts. If a model is unloaded, tell the user; do not silently load it.
+- When localpi cannot know something (for example, a token rate before the first token), show
+  nothing rather than a guess.
+- Keep measurements honest. Label estimated values as estimates.
+
+## Customizable
+
+Every default must have an escape hatch, and the escape hatch must be easy to find.
+
+- Follow a fixed precedence order: command-line flag, environment variable, saved setting, default.
+- Save what the user changes during a session so the next launch keeps it.
+- Expose the same setting through the flag, the environment, and the in-session command when that
+  costs little.
+- Keep user settings in `<state-dir>/settings.json`. Never scatter settings across files.
+- Never edit files that Pi owns. Write generated parts into the localpi state directory.
+
+## Pi-native
+
+Pi is the user interface. Localpi configures Pi and launches it.
+
+- Do not replace Pi's TUI, and do not add a parallel UI.
+- Use Pi extension APIs: `setWorkingMessage`, `setStatus`, `appendEntry`, `registerCommand`.
+- Prefer the documented Pi API over a local workaround. If the API is missing, propose it upstream
+  instead of building a private channel.
+- Generated extensions must depend only on the public Pi extension API and Node built-ins.
+- Keep generated code readable, because users can open it in `<state-dir>/pi-extensions/`.
+
+## Explicit and safe
+
+- Announce what localpi starts, stops, or reuses before doing it.
+- Never stop, unload, or reconfigure a server that localpi did not start.
+- Fail loudly with an actionable message, then stop. Do not guess a fix.
+- Keep tool approval explicit, and report denied calls back to the model.
+- Treat unknown input as unknown. Validate JSON at the boundary, then trust the typed value inside.
+
+## Worked example: the status display
+
+The status display shows the same principles in a small feature.
+
+1. **Simple.** One line answers "is this machine keeping up?" The line holds elapsed time, output
+   tokens, token rate, and context use. Nothing else.
+2. **Unopinionated.** Localpi does not impose colors, layout, or thresholds on users. The display
+   uses the active theme. Context coloring starts at 80 percent and 95 percent, and those numbers
+   are visible in one file.
+3. **Customizable.** `--stats off|line|full` sets the mode. `LOCALPI_STATS` sets it for a shell.
+   `/stats` changes it during a session and saves the result to `<state-dir>/settings.json`.
+   `--no-token-status` stays as a short alias for `--stats off`. The tool approval gate works the
+   same way, with `/approval ask|allow` and `on`/`off` as aliases: on by default, off on request,
+   and saved as the `permission` setting that new sessions start from. The dialog choice to allow
+   every tool call for one session is deliberately not saved, because that choice is about the task
+   at hand, not about the user's default.
+4. **Pi-native.** The display is a generated Pi extension. It uses `setFooter` for one status line,
+   `setWorkingMessage` for the live line, `appendEntry` for the transcript summary, and
+   `registerCommand` for `/stats`. It writes complete lines, so Pi keeps ownership of layout and
+   wrapping. It renders the same facts Pi showed, plus the engine next to the model, and it adds no
+   row of its own. The status line and the stats line are separate generated files, so the last
+   finished turn travels between them through one typed global. Pi loads every extension into one
+   process, and a second status item would add the row this design exists to avoid. When the bridge
+   is absent, only the rate disappears.
+5. **Explicit.** Prefill progress comes from the llama.cpp `/slots` endpoint. When that endpoint is
+   missing or slow, localpi stops polling and shows elapsed time instead of inventing a percentage.
+
+The three modes exist because users want different amounts of information:
+
+| Mode   | Status line | Live line | Transcript entry |
+| ------ | ----------- | --------- | ---------------- |
+| `off`  | Pi's own    | no        | no               |
+| `line` | localpi     | yes       | no               |
+| `full` | localpi     | yes       | yes              |
+
+## Worked example: the default look
+
+localpi picks the look and lets the user replace it.
+
+1. **Simple.** One palette file holds the colors. Both the Pi theme file and localpi's own terminal
+   colors come from it, so the launcher and the session match.
+2. **Unopinionated.** Catppuccin Mocha is the default, not a rule. `--no-themes` removes the theme,
+   `--use-theme <name>` selects another one, and `NO_COLOR` removes color from localpi's output.
+3. **Customizable.** The theme file lives in the localpi state directory, so a user can read it,
+   copy it, or edit it. Localpi never edits global Pi themes or settings.
+4. **Explicit.** localpi says which theme it loads only when it changes the session. Colors stay out
+   of piped output, so scripts keep the plain text.
+
+## Using the principles
+
+Before you add a feature, answer these questions in the pull request:
+
+- Which single problem does this solve?
+- Which default do I choose, and how does a user change it?
+- Which existing flag, environment variable, or command already covers part of this?
+- What does the feature show when the information is unavailable?
+- Which generated file or state file does this touch, and is that the right home for it?

package/docs/implementation-plan.md

@@ -73,3 +73,36 @@ Older workspace wrappers outside this repository still mention `localagent --fin
   - approval denial in an interactive tool call
   - token status display in an interactive session
 - Run `npm run check` before merging implementation changes.
+
+## 8. ACP Mode
+
+- [x] Add `--acp` and `LOCALPI_ACP=1`, and keep a normal launch as the default.
+- [x] Pin `pi-acp` in `package.json` and the lockfile. Do not vendor its source.
+- [x] Keep the ACP start in its own module next to the existing launcher.
+- [x] Resolve the model and write the Pi configuration a normal launch writes, then start the adapter with inherited stdio.
+- [x] Point `PI_ACP_PI_COMMAND` at a generated launcher script that execs Pi with the complete launch line of a normal launch, and pass the environment a normal launch uses.
+- [x] Require an explicit model from the flag, environment, or model profile, and fail with one clear message instead of printing a picker.
+- [x] Keep stdout for protocol bytes only, and send diagnostics, warnings, and startup notes to stderr.
+- [x] Refuse a Pi command that is localpi itself, and set `LOCALPI_ACP=0` for the child, so a spawned child cannot re-enter ACP mode.
+- [x] Unit-test the command and environment, stdout purity, the missing-model failure, exit-code propagation, and the absence of ACP re-entry, with a fake adapter child.
+- [x] Document ACP mode in the README and in `docs/runtime-specification.md`.
+- [x] Keep `npm run check` green, and leave the thinking budget and model profile semantics unchanged.
+
+## 9. Continue On Truncation
+
+- [x] Add `--continue-on-truncation <n>` and `LOCALPI_CONTINUE_ON_TRUNCATION=<n>`, where `n` is a positive integer and is the maximum number of extra continuations.
+- [x] Keep the feature off by default, so a normal launch, an ACP launch, and demo mode behave exactly as they do today with no flag and no environment variable.
+- [x] Treat `0` from the environment as off, so an inherited value can be disabled without dropping the variable.
+- [x] Keep the usual precedence, command-line flag, environment variable, then default, and add the usage line.
+- [x] Fail an invalid value with one clear message and exit code 2.
+- [x] Add the generated extension source `src/pi/extension-sources/continue-on-truncation.ts`, and bake the continuation limit into the generated source.
+- [x] Include the extension in the bundle only when the feature is enabled, and change nothing in the bundle otherwise.
+- [x] Detect the length stop on the turn-end hook, and continue only for that reason.
+- [x] Leave a truncated turn that already asked for a tool alone, because Pi runs the tool and keeps going on its own.
+- [x] Send exactly one follow-up user message that tells the model to continue where it stopped and not to repeat earlier text.
+- [x] Count continuations per session, and stop after the limit, so the feature cannot loop forever.
+- [x] Never continue a turn that ended for another reason, including a normal stop, a tool-only turn, an error stop, and a user cancellation.
+- [x] Write diagnostics to stderr only, and keep stdout free for protocol bytes and batch output.
+- [x] Unit-test option parsing and validation, the bundle containing the guard only when it is enabled, one continuation message on a truncated turn, the count stopping at the limit, and no continuation on a normal turn.
+- [x] Document the feature in the README and in `docs/runtime-specification.md`.
+- [x] Keep `npm run check` green, and leave the thinking budget, the model profile limits, and the ACP contract unchanged.

package/docs/runtime-specification.md

@@ -7,8 +7,9 @@ It should make the common local-model path one command while keeping the selecte
 ## Goals
 
 - Run Pi against local open-weight models without hand-editing Pi config.
+- Treat llama.cpp as the default engine and the preferred discovery target.
 - Discover local providers by default and select from the loaded model catalog.
-- Support LM Studio and vLLM as built-in OpenAI-compatible providers.
+- Support llama.cpp, LM Studio, and vLLM as built-in OpenAI-compatible providers.
 - Keep managed `llama-server` as an optional fallback when no external model is loaded.
 - Keep the tool generic: no classifier prompts, topic schemas, dataset generation, or final-schema output.
 - Keep large model memory usage predictable by managing only one localpi-owned `llama-server` process at a time.
@@ -21,16 +22,34 @@ Default runtime.
 
 Localpi:
 
-- probes built-in LM Studio and vLLM endpoints
+- probes a running llama.cpp server first, then built-in LM Studio and vLLM endpoints
 - loads configured OpenAI-compatible providers from `--providers-file`, `LOCALPI_PROVIDERS_FILE`, or `LOCALPI_MODELS_FILE`
 - includes the localpi-owned `llama-server` catalog as startable fallback entries when available
-- selects the only loaded model automatically
+- selects the only loaded model automatically, preferring llama.cpp when several engines have loaded models
 - opens Pi's native model selector when multiple loaded models are available in an interactive TTY
 - never prompts in non-interactive runs; automation can pin a model with concrete `--provider` and `--model` values
 - treats `--provider` without `--model` as catalog scoping, not as a concrete model choice
 - skips automatic managed `llama-server` fallback when the configured `llama-server` command is unavailable
 - writes Pi config for all launch-time loaded catalog entries so Pi `/model` can switch among them
 
+### `llama-cpp`
+
+Default external engine.
+
+Localpi:
+
+- probes `http://127.0.0.1:8080/v1` by default and is listed first in `auto` discovery
+- reads llama.cpp `/v1/models` entries: a model with `status.value` `loaded`, or with no status, is usable
+- offers a model with `status.value` `unloaded` as startable only when `/props` reports `models_autoload`, because the llama.cpp router loads it on request
+- reports unloaded models that the server will not autoload as a catalog warning instead of claiming they are usable
+- reads llama.cpp `meta.n_ctx` as the model context window when the server reports it
+- never starts, stops, or unloads an external llama.cpp server
+
+```bash
+localpi --runtime llama-cpp
+localpi --runtime llama-cpp --base-url http://127.0.0.1:9931/v1 --model ternary-bonsai-2-27b-pq2_0
+```
+
 ### `llama-server`
 
 Managed runtime.
@@ -44,6 +63,19 @@ Localpi:
 - writes Pi config that points at that endpoint
 - stops the old localpi-owned server before starting a different managed model
 - reports any detected LM Studio loaded models before starting a large managed model
+- passes the reasoning flags of the selected thinking level: `--reasoning off` and no budget when
+  thinking is off, and `--reasoning on` with a token budget otherwise
+- caps thinking with `--thinking-budget <n>` or `LOCALPI_THINKING_BUDGET` when set, where `-1` means
+  unrestricted and a positive value replaces the budget of the thinking level
+- injects a default message before the end-of-thinking tag when the budget is finite, so a model
+  that loops in its thinking still answers
+- rewords that message with `--thinking-budget-message <text>` or `LOCALPI_THINKING_BUDGET_MESSAGE`,
+  and passes no message flag when the value is empty
+- records the reasoning mode, the budget, and the message in the managed server metadata, and
+  restarts the owned server when a recorded value changes
+
+The engine reads the thinking tags from the model template, so localpi passes no tag of its own. A
+budget of `-1` leaves thinking unrestricted.
 
 ### LM Studio
 
@@ -81,7 +113,7 @@ Localpi:
 
 ### Configured Providers
 
-Provider registry JSON can define additional OpenAI-compatible providers:
+Provider registry JSON can define additional OpenAI-compatible providers, and can override the built-in `llama-cpp` provider with `type: "llama-cpp"`:
 
 ```json
 {
@@ -91,11 +123,19 @@ Provider registry JSON can define additional OpenAI-compatible providers:
       "name": "vLLM Qwen",
       "baseUrl": "http://127.0.0.1:8000/v1",
       "discover": true
+    },
+    "llama-cpp": {
+      "type": "llama-cpp",
+      "name": "llama.cpp",
+      "baseUrl": "http://127.0.0.1:9931/v1",
+      "discover": true
     }
   }
 }
 ```
 
+A `llama-cpp` provider uses the llama.cpp status and autoload rules described in the `llama-cpp` runtime section. When `baseUrl` is omitted, it defaults to `http://127.0.0.1:8080/v1`.
+
 Set `discover: false` when the endpoint should not be probed during startup. Explicit `--provider <id> --model <id>` can still select that provider and generate Pi config.
 
 ## Capability Profiles
@@ -124,6 +164,14 @@ When the served model id matches `model` or `id`, localpi uses the profile to ge
 
 Name-based capability detection remains fallback behavior. Built-in vLLM Gemma 4 model ids are treated as reasoning-capable with `qwen-chat-template`, matching vLLM Gemma servers launched with `--reasoning-parser gemma4`.
 
+### Image input
+
+A llama.cpp server reports model architecture in `/v1/models`. Localpi reads `architecture.input_modalities` and writes `input: ["text", "image"]` into the Pi model config when the entry lists `image`, so Pi passes image attachments to that model. Every other model is written as `input: ["text"]`.
+
+A model profile states the same fact for a server that reports nothing: add `"image": true` to `capabilities`. The profile wins over the server, so `"image": false` also disables image input for a model that reports it.
+
+The server side must hold up its end: the model needs a multimodal projector, and the server must run with `--mmproj <file>.gguf`. A llama.cpp router passes the projector of a model directory to the child server on its own. Test a model with one real image request before you trust it, because a text-only server answers an image request with text about the prompt, not the picture.
+
 ## Model Selection
 
 `--model` should accept:
@@ -164,6 +212,49 @@ Localpi appends a short system prompt that tells the model:
 
 The prompt should be generic and should not mention localpager, OpenClaw, datasets, or classifier labels.
 
+## ACP Mode
+
+`localpi --acp` and `LOCALPI_ACP=1` start localpi as an ACP agent, so an ACP client such as an editor can drive the same Pi that a normal launch runs.
+
+Localpi:
+
+- follows the usual precedence, command-line flag, environment variable, then default, and keeps a normal launch as the default
+- resolves the model and writes the same Pi configuration a normal launch writes before it starts the adapter
+- starts the pinned `pi-acp` adapter from `node_modules` on stdio as a child process with inherited stdio, and does not vendor its source
+- writes a launcher script into `<state-dir>/acp/`, and sets `PI_ACP_PI_COMMAND` to that script, because the adapter starts Pi itself and passes only its own arguments. The script quotes the Pi program and every argument, so a program path with a space survives, and it execs Pi with the complete launch line of a normal launch, so the models file, the settings file, the extensions, the system prompt, the theme, and the tool flags stay the same
+- passes the environment a normal launch uses: the Pi config directory, the provider base URL, the API key name, the thinking level, and the session directory
+- requires an explicit model from the flag, the environment, or a model profile, because there is no TTY, and fails with one clear message instead of printing a picker
+- keeps stdout for protocol bytes only, and writes diagnostics, warnings, and startup notes to stderr
+- refuses `--demo`, a forwarded Pi `--mode`, forwarded Pi session flags, and forwarded prompts, because the adapter owns the session
+- refuses the immediate commands together with a command-line `--acp`, and lets a command-line immediate command win over an environment-set `LOCALPI_ACP=1`, the way `LOCALPI_DEMO` behaves
+- refuses a Pi command that is localpi itself, and sets `LOCALPI_ACP=0` for the child, so a spawned child cannot re-enter ACP mode
+- runs a different adapter build only when `LOCALPI_ACP_ADAPTER` names its entrypoint
+- leaves the thinking budget and the model profile limits unchanged, and never invents a smaller reply cap than the declared one
+
+The adapter spawns Pi as `pi --mode rpc --no-themes`, adds `--session <path>` when a session path exists, and does not pass `--no-extensions`, so Pi extension discovery stays enabled. Approval dialogs reach the ACP client, because the adapter forwards Pi extension UI requests as ACP permission requests.
+
+Pi has no ACP mode of its own. ACP support always comes from the adapter, and localpi only configures it and launches it.
+
+## Continue On Truncation
+
+`localpi --continue-on-truncation <n>` and `LOCALPI_CONTINUE_ON_TRUNCATION=<n>` continue a Pi turn that stopped because it reached the output token limit, so a run finishes its answer instead of ending with a half-written reply.
+
+- `n` is a positive integer and is the maximum number of extra continuations
+- the feature is off by default. With no flag and no environment variable, a normal launch, an ACP launch, and demo mode behave exactly as they do today
+- follows the usual precedence, command-line flag, environment variable, then default
+- treats `0` from the environment as off, so an inherited value can be disabled without dropping the variable
+- fails an invalid value with one clear message and exit code 2
+- detects the length stop on the turn-end hook, and continues only for that reason
+- leaves a truncated turn that already asked for a tool alone, because Pi runs the tool and keeps going on its own
+- sends exactly one follow-up user message that tells the model to continue where it stopped and not to repeat earlier text
+- counts continuations per session, and stops after the limit, so the feature cannot loop forever
+- never continues a turn that ended for another reason, including a normal stop, a tool-only turn, an error stop, and a user cancellation
+- writes diagnostics to stderr only, and keeps stdout free for protocol bytes and batch output
+- is not a default extension. Localpi installs the guard extension only when the feature is enabled. When it is enabled, the guard is part of the extensions localpi writes, so an ACP launch uses it too
+- leaves the thinking budget, the model profile limits, and the ACP contract unchanged
+
+The guard changes no served limit. It reacts to the stop reason Pi reports, so a run that reached the declared output cap continues inside the declared limits.
+
 ## Out Of Scope
 
 - `--final-schema`
@@ -173,3 +264,6 @@ The prompt should be generic and should not mention localpager, OpenClaw, datase
 - GitHub issue or pull request fetching
 - reposhell-specific behavior
 - dataset generation
+- an ACP server implemented inside localpi, because the adapter is a pinned dependency
+- ACP file system or terminal delegation, because Pi reads, writes, and runs commands in its own process
+- interactive model selection in ACP mode, because ACP has no terminal

package/package.json

@@ -1,17 +1,17 @@
 {
   "name": "localpi",
-  "version": "0.5.0",
+  "version": "0.6.0",
   "description": "Swiss army knife for running Pi with local inference engines.",
   "type": "module",
   "license": "MIT",
   "repository": {
     "type": "git",
-    "url": "git+https://github.com/dutifuldev/localpi.git"
+    "url": "git+https://github.com/osolmaz/localpi.git"
   },
   "bugs": {
-    "url": "https://github.com/dutifuldev/localpi/issues"
+    "url": "https://github.com/osolmaz/localpi/issues"
   },
-  "homepage": "https://github.com/dutifuldev/localpi#readme",
+  "homepage": "https://github.com/osolmaz/localpi#readme",
   "publishConfig": {
     "access": "public"
   },
@@ -26,7 +26,8 @@
     "LICENSE"
   ],
   "scripts": {
-    "build": "tsc -p tsconfig.json",
+    "build": "tsc -p tsconfig.json && chmod +x dist/src/cli/main.js",
+    "prepare": "npm run build",
     "format": "prettier --check .",
     "lint": "eslint .",
     "typecheck": "tsc --noEmit",
@@ -40,6 +41,7 @@
     "check": "npm run format && npm run lint && npm run typecheck && npm test && npm run build"
   },
   "devDependencies": {
+    "@earendil-works/pi-coding-agent": "^0.87.0",
     "@eslint/js": "^9.0.0",
     "@stryker-mutator/core": "^9.6.1",
     "@stryker-mutator/typescript-checker": "^9.6.1",
@@ -48,13 +50,15 @@
     "@vitest/coverage-v8": "^3.0.0",
     "eslint": "^9.0.0",
     "prettier": "^3.0.0",
-    "slophammer-ts": "0.4.0",
+    "slophammer-ts": "0.4.1",
     "tsx": "^4.19.4",
     "typescript": "^5.0.0",
     "typescript-eslint": "^8.0.0",
     "vitest": "^3.0.0"
   },
   "dependencies": {
-    "@dutifuldev/pi-factory": "^0.1.1"
+    "@osolmaz/pi-factory": "^0.7.0",
+    "pi-acp": "0.0.33",
+    "pi-demo-mode": "github:osolmaz/pi-demo-mode#v0.1.0"
   }
 }

package/dist/src/pi/extension-sources/demo-mode.js

@@ -1,110 +0,0 @@
-export function demoModeExtensionSource(prompts) {
-    const initialPromptSource = JSON.stringify(prompts.initial);
-    const followupPromptSource = JSON.stringify(prompts.followup);
-    return `import type { ExtensionAPI, ExtensionContext, TurnEndEvent } from "@earendil-works/pi-coding-agent";
-
-const initialPrompt = ${initialPromptSource};
-const followupPrompt = ${followupPromptSource};
-const compactAtContextPercent = 70;
-const demoCompactionInstructions = [
-  "Preserve the demo narrative state, named entities, current setting,",
-  "unresolved plot threads, and latest user direction.",
-  "Keep the summary concise so the story can continue after compaction."
-].join(" ");
-
-export default function localpiDemoMode(pi: ExtensionAPI): void {
-  let started = false;
-  let stopped = false;
-  let compacting = false;
-
-  function queueInitialPrompt(): void {
-    queueMicrotask(() => {
-      if (!stopped) {
-        pi.sendUserMessage(initialPrompt);
-      }
-    });
-  }
-
-  function queueFollowup(): void {
-    queueMicrotask(() => {
-      if (!stopped && !compacting) {
-        pi.sendUserMessage(followupPrompt, { deliverAs: "followUp" });
-      }
-    });
-  }
-
-  function compactThenFollowup(ctx: ExtensionContext): void {
-    if (compacting) {
-      return;
-    }
-    compacting = true;
-    ctx.compact({
-      customInstructions: demoCompactionInstructions,
-      onComplete: () => {
-        compacting = false;
-        queueFollowup();
-      },
-      onError: (error) => {
-        compacting = false;
-        stopped = true;
-        ctx.ui.notify("Demo compaction failed: " + error.message, "error");
-      }
-    });
-  }
-
-  pi.on("session_start", (event, ctx) => {
-    if (started || stopped || event.reason !== "startup" || ctx.mode !== "tui") {
-      return;
-    }
-    started = true;
-    queueInitialPrompt();
-  });
-
-  pi.on("turn_end", (event, ctx) => {
-    if (!started || stopped || compacting || ctx.mode !== "tui") {
-      return;
-    }
-    if (event.message.role !== "assistant") {
-      return;
-    }
-    switch (event.message.stopReason) {
-      case "aborted":
-      case "error":
-        stopped = true;
-        return;
-      case "toolUse":
-        return;
-    }
-    if (shouldCompactBeforeFollowup(event, ctx)) {
-      compactThenFollowup(ctx);
-      return;
-    }
-    queueFollowup();
-  });
-
-  pi.on("session_shutdown", () => {
-    stopped = true;
-  });
-}
-
-function shouldCompactBeforeFollowup(event: TurnEndEvent, ctx: ExtensionContext): boolean {
-  const contextPercent = currentContextPercent(event, ctx);
-  return contextPercent !== undefined && contextPercent >= compactAtContextPercent;
-}
-
-function currentContextPercent(event: TurnEndEvent, ctx: ExtensionContext): number | undefined {
-  const usage = ctx.getContextUsage();
-  if (usage?.percent !== undefined && usage.percent !== null) {
-    return usage.percent;
-  }
-  if (event.message.role !== "assistant") {
-    return undefined;
-  }
-  const contextWindow = ctx.model?.contextWindow;
-  if (contextWindow === undefined || contextWindow <= 0) {
-    return undefined;
-  }
-  return (event.message.usage.totalTokens / contextWindow) * 100;
-}
-`;
-}