@msdavid/pi-distro 0.2.0 → 0.3.0

package/extensions/show.ts

@@ -7,15 +7,15 @@ import type { ExtensionAPI } from "@earendil-works/pi-coding-agent";
 import { readFileSync, existsSync } from "node:fs";
 import { join } from "node:path";
 
-import { readFullHarnessMd, listBundledFiles, readCatalogue, findHarness, parsePackageList } from "./catalogue.ts";
+import { readFullHarnessMd, listBundledFiles, readCatalogue, findHarness, parsePackageList, sourceLabel } from "./catalogue.ts";
 import type { HarnessEntry } from "./catalogue.ts";
 import { parseFrontmatter, extractBody } from "./frontmatter.ts";
-import { looksLikeGithubRef, parseGithubRef, fetchGithubDistro } from "./github.ts";
+import { looksLikeGithubRef, parseGithubRef, fetchGithubDistro, fetchOfficialDistro } from "./github.ts";
 import { display } from "./util.ts";
 
 /** Build the dry-run preview for a harness (used by local and GitHub show). */
 export async function buildShowPreview(harness: HarnessEntry): Promise<string> {
-  const fullMd = await readFullHarnessMd(harness.harnessMdPath);
+  const fullMd = await readFullHarnessMd(harness.harnessMdPath!);
   const fm = parseFrontmatter(fullMd);
   const body = extractBody(fullMd);
   const packages = parsePackageList(body);
@@ -41,7 +41,7 @@ export async function buildShowPreview(harness: HarnessEntry): Promise<string> {
 - **Description:** ${fm?.description ?? harness.description}
 - **Version:** ${fm?.version ?? harness.version}
 - **Tags:** ${tags}
-- **Source:** ${harness.source}
+- **Source:** ${sourceLabel(harness.source)}
 
 ### pi packages to install
 ${packages.length > 0 ? packages.map((p) => `- \`${p}\``).join("\n") : "_(none)_"}
@@ -84,7 +84,8 @@ export async function handleShow(pi: ExtensionAPI, name?: string): Promise<void>
     return;
   }
 
-  // Local catalogue
+  // Local catalogue (official distros appear here as needsFetch listing entries;
+  // user distros are read straight from disk).
   const catalogue = await readCatalogue();
   const harness = findHarness(name, catalogue);
   if (!harness) {
@@ -92,5 +93,21 @@ export async function handleShow(pi: ExtensionAPI, name?: string): Promise<void>
     display(pi, `Distro '${name}' not found. Available: ${available}`);
     return;
   }
+  // Official listing entry — fetch the actual distro from GitHub before previewing.
+  if (harness.needsFetch) {
+    let fetched;
+    try {
+      fetched = fetchOfficialDistro(harness.name);
+    } catch (err) {
+      display(pi, `**Error:** ${err instanceof Error ? err.message : String(err)}`);
+      return;
+    }
+    try {
+      display(pi, await buildShowPreview(fetched.entry));
+    } finally {
+      fetched.cleanup();
+    }
+    return;
+  }
   display(pi, await buildShowPreview(harness));
 }

package/extensions/update.ts

@@ -55,7 +55,7 @@ export async function handleUpdate(pi: ExtensionAPI, ctx: ExtensionCommandContex
       return;
     }
   } else {
-    // Local catalogue (seed or user).
+    // Local catalogue (user distros only — official distros use the github: branch above).
     current = await resolveCatalogueEntry(prov.appliedHarness);
     if (!current) {
       ctx.ui.notify(

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@msdavid/pi-distro",
-  "version": "0.2.0",
+  "version": "0.3.0",
   "description": "Reusable, composable configurations for the pi coding agent — seed distros, project snapshots, and GitHub sharing with version-aware updates.",
   "type": "module",
   "license": "MIT",
@@ -28,7 +28,6 @@
   "files": [
     "extensions",
     "skills",
-    "harnesses",
     "README.md",
     "docs",
     "LICENSE",

package/skills/pi-distro/SKILL.md

@@ -40,7 +40,8 @@ When you receive a kickoff message from the `deploy` command, it contains:
 - The merge-don't-clobber rule.
 - An instruction to write/update provenance.
 
-The distro may come from the local catalogue (seed or user-saved) or from GitHub
+The distro may come from the local catalogue (official, fetched from GitHub, or
+user-saved) or directly from another GitHub repo
 (`/pi-distro deploy owner/repo`). For GitHub distros, the extension has already
 cloned the repo, displayed a security warning + preview, and obtained the user's
 explicit confirmation before sending the kickoff — so you can proceed normally.
@@ -130,15 +131,15 @@ them from there as usual.
    <!-- pi-distro provenance
         appliedHarness: <name>
         appliedVersion: <version>
-        sourceCatalogue: <user|seed|none>
+        sourceCatalogue: <user|github:owner/repo[/subpath]>
         lastUpdated: <ISO8601>
    -->
    ```
 
    - `appliedHarness`: the name of the distro that was deployed.
    - `appliedVersion`: the version from the distro frontmatter.
-   - `sourceCatalogue`: `seed` if it came from the package seeds, `user` if from
-     `~/.pi/harnesses/`.
+   - `sourceCatalogue`: `user` if from `~/.pi/harnesses/`, or
+     `github:owner/repo[/subpath]` (official distros are `github:msdavid/pi-distro/harnesses/<name>`).
    - `lastUpdated`: current timestamp in ISO 8601 format.
 
 6. **Report.** Summarise what was deployed, merged, skipped, and any packages installed.
@@ -296,10 +297,10 @@ be bundled.
    the kickoff message exactly:
    - Ask the user whether to **save as a new distro** or **update an existing distro**.
    - If **save as new**: validate the slug; warn on collisions with existing user
-     distros or seed names and ask whether to overwrite.
+     distros or official distro names (fetched from GitHub) and ask whether to overwrite.
    - If **update existing**: let the user pick from the existing user distros listed in
-     the kickoff. Refuse to update names not in that list (those are read-only package
-     seeds). Back the old distro up to `~/.pi/harnesses/.trash/<name>-<timestamp>/` before
+     the kickoff. Refuse to update names not in that list (official/GitHub distros are
+     read-only locally). Back the old distro up to `~/.pi/harnesses/.trash/<name>-<timestamp>/` before
      overwriting. **Bump the version**: read the old distro's `version` and increment it
      with semver — **patch** for small tweaks/bug fixes, **minor** for new capabilities or
      config additions, **major** for breaking changes (removed packages, changed

package/harnesses/minimal/README.md

@@ -1,21 +0,0 @@
-# minimal
-
-A clean starting point for any project. Drops in a basic `AGENTS.md` and a sensible
-`.pi/settings.json` — nothing more, nothing less.
-
-## What it sets up
-
-- **`AGENTS.md`** — a minimal explore-before-acting methodology: investigate before
-  implementing, make surgical changes, keep solutions simple.
-- **`.pi/settings.json`** — a sensible default thinking level (pi's default
-  one-at-a-time steering already applies).
-
-No pi packages are installed. Use this as a blank canvas — tailor the `AGENTS.md` to your
-project's build/test commands and conventions, then layer on packages and skills as you go.
-
-## When to use
-
-- You want a clean baseline without opinions about which packages to install.
-- You're starting a new project and just want the agent oriented with good defaults.
-- You want to build your own distro from a minimal starting point (deploy this, then
-  `/pi-distro save` after customizing).

package/harnesses/minimal/files/AGENTS.md

@@ -1,20 +0,0 @@
-# Project Instructions
-
-Brief guidance for working in this project. Add your own rules below.
-
-## Build & Test Commands
-
-<!-- e.g. npm run build, npm test, npm run lint -->
-- Build:
-- Test:
-- Lint:
-
-## Code Style
-
-<!-- e.g. use TypeScript, 2-space indent, prefer named exports -->
--
-
-## Project Structure Notes
-
-<!-- e.g. src/ for source, tests/ for tests, docs/ for documentation -->
--

package/harnesses/minimal/files/settings.json

@@ -1,4 +0,0 @@
-{
-  "packages": [],
-  "defaultThinkingLevel": "medium"
-}

package/harnesses/minimal/harness.md

@@ -1,24 +0,0 @@
----
-name: minimal
-title: Minimal
-description: Clean starting point: a basic AGENTS.md and .pi/settings.json.
-version: 0.1.0
----
-
-# Minimal
-
-## Bundled files
-The following bundled files are provided under `files/` and should be placed into the
-target project. For any path that already exists, do NOT overwrite — show the user a diff
-and ask whether to overwrite, keep theirs, or merge. Merge JSON settings objects field by
-field. Append (not replace) `AGENTS.md` content under a clearly-delimited section.
-
-- `files/AGENTS.md` → `./AGENTS.md`
-- `files/settings.json` → `./.pi/settings.json` (merge with existing settings)
-
-## Context
-This harness provides a minimal starting point for any project. After placing the bundled
-files, ensure the `AGENTS.md` is tailored to the project's actual build/test commands and
-conventions. The `settings.json` sets a sensible default thinking level — adjust as needed.
-
-No additional pi packages are required for this harness.

package/harnesses/pi-distro-one/README.md

@@ -1,50 +0,0 @@
-# pi-distro-one
-
-A complete Claude Code–style coding agent configuration for pi. The primary capability is
-spawning and coordinating autonomous sub-agents; everything else — web research, browser
-automation, live shell, model routing, task management — is integrated in support of that.
-
-This is a personal draft shot at using the most popular pi coding packages to closely
-resemble the capabilities of Claude Code. It's opinionated and not for everyone — but it
-makes a great starting point to fork and make your own.
-
-## What it sets up
-
-- **`AGENTS.md`** — an explore-before-acting working methodology: investigate before
-  implementing, surface interpretations and tradeoffs, make surgical changes, keep
-  solutions simple, execute against verifiable goals, and treat documentation as part of
-  the implementation.
-- **`.pi/settings.json`** — high thinking level, one-at-a-time steering, hidden thinking
-  blocks, and hardware cursor.
-- **`.pi/extensions/claude-statusline.ts`** — a Claude-style status-line footer
-  (model | dir | thinking level | context-window bar gauge + cache % | git branch status).
-  Auto-enables on session start and **auto-expands tool outputs** (the Ctrl+O effect) so
-  full output is visible by default. Toggle with the `/claude-statusline` command.
-
-## Packages installed (all project-local)
-
-| Package | What it does |
-|---------|-------------|
-| `npm:@tintinweb/pi-subagents` | Claude Code–style autonomous sub-agents — spawn specialized agents in isolated sessions with own tools/prompt/model/thinking; parallel execution, live widget, mid-run steering, resumption (**primary capability**) |
-| `npm:pi-web-access` | Web search, URL fetching, GitHub cloning, PDF/video extraction |
-| `npm:pi-agent-browser-native` | Real browser automation and web interaction |
-| `npm:pi-bash-live-view` | Live terminal rendering for shell commands |
-| `npm:@yeliu84/pi-model-router` | Model routing / fallback across providers |
-| `npm:@robhowley/pi-openrouter` | OpenRouter provider integration |
-| `npm:@juicesharp/rpiv-todo` | Task list management |
-| `npm:pi-goal` | Persistent autonomous goals — `/goal` loops until complete, paused, or budget-limited |
-| `npm:@trevonistrevon/pi-loop` | Cron/event-based agent re-wake loops + background process monitoring — schedule agents to re-wake on time/events |
-| `npm:@juicesharp/rpiv-ask-user-question` | Structured questionnaire the model puts to the user (typed options instead of guessing) |
-
-## Prerequisites
-
-- **Auth and model routing** are not part of this distro — configure those independently
-  (e.g. set `defaultProvider` and `defaultModel` in your global `~/.pi/settings.json`,
-  or use OpenRouter via the `@robhowley/pi-openrouter` package installed above).
-- **Restart pi** after deploying — packages and extensions load at startup.
-
-## When to use
-
-- You want a Claude Code–like experience in pi.
-- You work on complex tasks that benefit from multi-agent coordination.
-- You want an opinionated, batteries-included setup to fork and customize.

package/harnesses/pi-distro-one/files/.pi/extensions/claude-statusline.ts

@@ -1,220 +0,0 @@
-/**
- * Claude-style status line for pi.
- *
- * Clones the Claude Code footer format:
- *   <model> | <dir> | <style> | [████████░░] 80% | 45% cached | <branch (status)>
- *
- * - model       : active model name/id
- * - dir         : basename of ctx.cwd
- * - style       : current thinking level (pi's analog of Claude's "output style")
- * - context     : UTF-8 bar gauge of context-window usage (eighths resolution),
- *                 colored by level (accent → warning → error), plus usage % and
- *                 cache-read % (same token math as the Claude Code statusLine
- *                 command in ~/.claude/settings.json)
- * - git         : branch from footerData + dirty(!)/untracked(?) markers, refreshed
- *                 in the background so render() never spawns a process
- *
- * Auto-enables on session start. Also auto-expands tool outputs on session start
- * (the Ctrl+O effect) so full output is visible by default. Toggle the status line
- * with the /claude-statusline command.
- */
-
-import { execSync } from "node:child_process";
-import { basename } from "node:path";
-import type { ExtensionAPI, ExtensionContext } from "@earendil-works/pi-coding-agent";
-import type { AssistantMessage } from "@earendil-works/pi-ai";
-import { truncateToWidth } from "@earendil-works/pi-tui";
-
-const REFRESH_MS = 2000;
-
-/** Eighth-block characters for sub-cell bar precision (index = eighths, 0 = empty). */
-const EIGHTHS = ["", "▏", "▎", "▍", "▌", "▋", "▊", "▉", "█"];
-const BAR_WIDTH = 10;
-
-interface GitCache {
-	branch: string | null;
-	dirty: boolean;
-	untracked: boolean;
-}
-
-export default function (pi: ExtensionAPI) {
-	let enabled = false;
-	let timer: ReturnType<typeof setInterval> | undefined;
-	let gitCache: GitCache = { branch: null, dirty: false, untracked: false };
-
-	function refreshGit(cwd: string): void {
-		try {
-			// One porcelain call gives us both dirty (staged/modified) and untracked flags.
-			const out = execSync("git status --porcelain=v1 -z", {
-				cwd,
-				encoding: "utf8",
-				stdio: ["ignore", "pipe", "ignore"],
-				timeout: 1500,
-			});
-			let dirty = false;
-			let untracked = false;
-			// -z separates records with NUL. Each record: <XY><space><path>\0...
-			const records = out.split("\0").filter((r) => r.length > 0);
-			for (const rec of records) {
-				const xy = rec.slice(0, 2);
-				if (xy === "??") {
-					untracked = true;
-				} else {
-					dirty = true;
-				}
-				if (dirty && untracked) break;
-			}
-			gitCache = { ...gitCache, dirty, untracked };
-		} catch {
-			// Not a git repo, or git unavailable — clear flags.
-			gitCache = { ...gitCache, dirty: false, untracked: false };
-		}
-	}
-
-	function startTimer(ctx: ExtensionContext): void {
-		stopTimer();
-		refreshGit(ctx.cwd);
-		timer = setInterval(() => refreshGit(ctx.cwd), REFRESH_MS);
-		// Don't keep the event loop alive solely for footer refreshes.
-		if (timer && typeof timer.unref === "function") timer.unref();
-	}
-
-	function stopTimer(): void {
-		if (timer) {
-			clearInterval(timer);
-			timer = undefined;
-		}
-	}
-
-	/**
-	 * Render a fixed-width UTF-8 bar gauge for a fraction in [0,1].
-	 * Filled cells use full blocks; the boundary cell uses an eighth-block for
-	 * sub-cell precision. Returns [filled, empty] strings for separate coloring.
-	 */
-	function barGauge(fraction: number): { filled: string; empty: string } {
-		const clamped = Math.max(0, Math.min(1, fraction));
-		const totalEighths = Math.round(clamped * BAR_WIDTH * 8);
-		const fullCells = Math.floor(totalEighths / 8);
-		const remainder = totalEighths % 8;
-		const filled = "█".repeat(fullCells) + (remainder > 0 ? EIGHTHS[remainder] : "");
-		const filledWidth = fullCells + (remainder > 0 ? 1 : 0);
-		const empty = "░".repeat(Math.max(0, BAR_WIDTH - filledWidth));
-		return { filled, empty };
-	}
-
-	function enable(ctx: ExtensionContext): void {
-		enabled = true;
-		startTimer(ctx);
-
-		ctx.ui.setFooter((tui, theme, footerData) => {
-			const unsub = footerData.onBranchChange(() => {
-				gitCache = { ...gitCache, branch: footerData.getGitBranch() };
-				tui.requestRender();
-			});
-			gitCache = { ...gitCache, branch: footerData.getGitBranch() };
-
-			return {
-				dispose: () => {
-					unsub();
-					stopTimer();
-				},
-				invalidate() {},
-				render(width: number): string[] {
-					const segments: string[] = [];
-
-					// 1. Model
-					const model = ctx.model;
-					segments.push(theme.fg("accent", model?.name ?? model?.id ?? "no-model"));
-
-					// 2. Cwd basename
-					segments.push(theme.fg("dim", basename(ctx.cwd) || ctx.cwd));
-
-					// 3. Style -> thinking level (pi's analog of output style).
-					// getThinkingLevel() lives on the ExtensionAPI (pi), not on ctx.
-					segments.push(theme.fg("dim", pi.getThinkingLevel()));
-
-					// 4. Context: bar gauge + usage % + cache %.
-					// Use pi's own context estimate (ctx.getContextUsage) — it represents the
-					// current context size of the most recent request, matching Claude Code's
-					// `context_window.current_usage`. Summing per-message usage would double-
-					// count, since each request's input already includes prior context.
-					const usage = ctx.getContextUsage();
-					const usedPct = usage?.percent ?? 0;
-
-					// Cache-read % comes from the last assistant message's usage (the most
-					// recent request): cacheRead / (input + cacheWrite + cacheRead).
-					let cachePct = 0;
-					const branch = ctx.sessionManager.getBranch();
-					for (let i = branch.length - 1; i >= 0; i--) {
-						const e = branch[i];
-						if (e.type === "message" && e.message.role === "assistant") {
-							const u = (e.message as AssistantMessage).usage;
-							const totalInput = u.input + u.cacheWrite + u.cacheRead;
-							cachePct = totalInput > 0 ? Math.floor((u.cacheRead * 100) / totalInput) : 0;
-							break;
-						}
-					}
-
-					const { filled, empty } = barGauge(usedPct / 100);
-					const barColor = usedPct >= 95 ? "error" : usedPct >= 80 ? "warning" : "accent";
-					const bar = theme.fg(barColor, filled) + theme.fg("dim", empty);
-					const pctLabel = theme.fg("dim", `${Math.floor(usedPct)}%`);
-
-					let ctxInfo = `${bar} ${pctLabel}`;
-					if (cachePct > 0) ctxInfo += theme.fg("dim", ` | ${cachePct}% cached`);
-					segments.push(ctxInfo);
-
-					// 5. Git: branch (!dirty ?untracked)
-					if (gitCache.branch) {
-						let status = "";
-						if (gitCache.dirty) status += "!";
-						if (gitCache.untracked) status += "?";
-						const gitInfo = status ? `${gitCache.branch} (${status})` : gitCache.branch;
-						segments.push(theme.fg("dim", gitInfo));
-					}
-
-					// Join with dim separators.
-					const sep = theme.fg("muted", " | ");
-					const line = segments.join(sep);
-
-					return [truncateToWidth(line, width)];
-				},
-			};
-		});
-	}
-
-	function disable(ctx: ExtensionContext): void {
-		enabled = false;
-		stopTimer();
-		ctx.ui.setFooter(undefined);
-	}
-
-	// Auto-enable on every (re)start, and auto-expand tool outputs (the Ctrl+O effect).
-	pi.on("session_start", async (_event, ctx) => {
-		enable(ctx);
-		ctx.ui.setToolsExpanded(true);
-	});
-
-	pi.on("session_shutdown", async (_event, _ctx) => {
-		stopTimer();
-	});
-
-	// Refresh git right after a turn settles (catches file writes from the agent).
-	pi.on("turn_end", async (_event, ctx) => {
-		if (enabled) refreshGit(ctx.cwd);
-	});
-
-	// Manual toggle.
-	pi.registerCommand("claude-statusline", {
-		description: "Toggle the Claude-style status line footer",
-		handler: async (_args, ctx) => {
-			if (enabled) {
-				disable(ctx);
-				ctx.ui.notify("Claude status line: off", "info");
-			} else {
-				enable(ctx);
-				ctx.ui.notify("Claude status line: on", "info");
-			}
-		},
-	});
-}

package/harnesses/pi-distro-one/files/AGENTS.md

@@ -1,166 +0,0 @@
-# Quick Rules
-
-- Never commit or push until I explicitly ask
-- **Always update documentation** when planning, implementing, or refactoring
-  - Update README, docs/, inline comments, docstrings, and any related docs
-  - Include documentation updates as explicit steps in plans
-- **EYU** = Explain Your Understanding of the request and wait for approval
-  - Example: User says "EYU" → Summarize what you understood, then stop and wait
-
----
-
-# Approach to Changes
-
-Before planning or implementing any changes, adopt a "deep researcher" mindset.
-
-## Core Principle
-
-**Understand before you act.** Don't jump to implementation. Your first instinct should be to explore the codebase, not to write code.
-
-## Surface, Don't Hide
-
-- **Present interpretations, don't pick silently.** If a request has more than one reasonable reading, lay them out and let me choose.
-- **Surface tradeoffs and push back.** If a simpler approach exists, say so. If the request seems wrong or overcomplicated, challenge it before building it.
-- **Name confusion instead of papering over it.** If something is still unclear after investigating, stop and say exactly what's confusing.
-- Investigate what the code can answer (see "When uncertain, investigate more"); *ask* only about genuine intent or scope ambiguity the code can't resolve.
-
-## When to Explore vs Plan
-
-- **Always explore first** before any plan or implementation
-- **Default behavior**: Explore → Implement
-- **When user says "EYU"**: Explain understanding → Wait for approval → Explore → Plan/Implement
-
-## Before Any Task
-
-1. **Find existing examples first.** Use grep, glob, or read files to locate similar features. Study at least 2-3 examples of how comparable things are implemented before proposing changes.
-
-2. **Map the full surface area.** For any change, actively investigate:
-   - How are similar things structured and named? (conventions, patterns)
-   - What's the full lifecycle? (creation, registration, configuration, persistence, cleanup)
-   - What are all integration points? (UI, menus, context menus, commands, keybindings, APIs)
-   - What files document this? (README, docs/, inline comments, docstrings)
-   - What tests exist for similar features? How do they test this kind of thing?
-   - What registries, configs, or manifests need updating?
-
-3. **Learn the local conventions.** Every codebase has its own patterns. Discover them before writing new code. Match the existing style exactly.
-
-4. **Think in systems.** A request to "add X" means "integrate X into the existing system." Understand the system's architecture first.
-
-5. **When uncertain, investigate more.** Read more files. Run the code. Check tests. Don't guess—know.
-
-6. **Update all documentation.** Treat documentation as part of the implementation, not an afterthought. Update README, docs/, docstrings, inline comments, and any related documentation files. If the change affects public APIs, update their documentation first.
-
-## In Practice
-
-When given a task:
-- Start by exploring, not planning (unless SYP is requested)
-- Use tools to read related code before proposing changes
-- List all affected files/areas before making edits
-- Identify all documentation that needs updating (README, docs/, docstrings, comments)
-- Ask clarifying questions if the scope seems larger than implied
-
----
-
-# Implementation Principles
-
-Once you understand the task, these govern how you write the code.
-
-## Simplicity First
-
-Write the minimum code that solves the problem. Nothing speculative.
-
-- No features beyond what was asked.
-- No abstractions for single-use code.
-- No "flexibility" or "configurability" I didn't request.
-- No error handling for scenarios that can't actually happen.
-- If you wrote 200 lines and it could be 50, rewrite it.
-- Gut check: *"Would a senior engineer call this overcomplicated?"* If yes, simplify.
-
-(This is about not writing unnecessary code; the File Size Limits below are about splitting code that has already grown too large — a different problem.)
-
-## Surgical Changes
-
-Touch only what you must. Clean up only your own mess.
-
-When editing existing code:
-- Don't "improve" adjacent code, comments, or formatting.
-- Don't refactor things that aren't broken.
-- If you notice unrelated dead code, *mention* it — don't delete it.
-- (Matching existing style is already required under "Learn the local conventions" — it holds here too, even when you'd do it differently.)
-
-When your changes create orphans:
-- Remove imports/variables/functions that *your* changes made unused.
-- Don't remove pre-existing dead code unless I ask.
-
-**The test:** every changed line should trace directly to my request.
-
-## Goal-Driven Execution
-
-Define success criteria up front, then loop until they're verified.
-
-Turn vague tasks into verifiable goals:
-- "Add validation" → write tests for invalid inputs, then make them pass.
-- "Fix the bug" → write a test that reproduces it, then make it pass.
-- "Refactor X" → confirm tests pass before and after.
-
-For multi-step work, state a brief plan with a check per step:
-1. [Step] → verify: [check]
-2. [Step] → verify: [check]
-
-Strong success criteria let you loop independently; weak ones ("make it work") force constant clarification — so define them precisely. (those gate *whether* you start; success criteria define *when you're done*.)
-
----
-
-# Code Quality Guidelines
-
-## File Size Limits
-
-| Type | Warning | Consider Split | Must Split |
-|------|---------|----------------|------------|
-| Python | 500 | 600 | 700 |
-| TypeScript (general) | 400 | 500 | 600 |
-| React components | 200 | 300 | 400 |
-| Next.js pages/routes | 300 | 400 | 500 |
-| Custom hooks | 100 | 150 | 200 |
-| Utility/service files | 400 | 500 | 600 |
-
-## Test File Size Limits
-| Type | Warning | Consider Split | Must Split |
-|------|---------|----------------|------------|
-| Python tests | 800 | 1000 | 1200 |
-| TypeScript tests | 600 | 800 | 1000 |
-| React component tests | 400 | 500 | 600 |
-| Hook tests | 200 | 300 | 400 |
-| E2E/integration tests | 800 | 1000 | 1200 |
-
-When a test file approaches these limits, first consider whether the module under test should be split before splitting the test file.
-
-## Verify, don't guess
-
-- If you find yourself reconstructing an API, function signature, config key, or
-  command flag from memory, stop and confirm it before writing it. Memory of these
-  is the single biggest source of confident-but-wrong code.
-- Check the right source for the kind of doubt:
-  - Project conventions, types, helpers, existing patterns → search the codebase.
-  - External library/framework behavior, versions, deprecations → search online,
-    preferring official docs and the library's changelog over blog posts or older
-    Stack Overflow answers.
-- A search is cheap; a wrong assumption is expensive to debug. When unsure whether
-  it's worth checking, check.
-- When a non-obvious choice rests on something you looked up, note the source in one
-  line (e.g. "per React 19 docs") so it can be verified.
-- Treat anything that may have changed since your training cutoff — latest versions,
-  new APIs, deprecations — as something to look up, not recall.
-
-## When debugging
-
-- State your current hypothesis for the cause before each fix attempt. If it's the
-  same hypothesis as the last failed attempt, do not try another variation — the
-  diagnosis is suspect, not just the fix. Gather new information instead.
-- After 2 failed attempts, stop iterating and treat your understanding of the problem
-  as the thing that's wrong. Re-examine the premise.
-- Get fresh ground truth instead of reasoning from memory: read the actual error
-  message in full, read the actual source of the function involved, and search the
-  literal error text online — others have usually hit it.
-- Never repeat a fix that already failed.
-- If you're stuck after re-examining, surface the competing hypotheses to me rather than continuing to guess.

package/harnesses/pi-distro-one/files/settings.json

@@ -1,9 +0,0 @@
-{
-  "defaultThinkingLevel": "high",
-  "showHardwareCursor": true,
-  "steeringMode": "one-at-a-time",
-  "transport": "auto",
-  "hideThinkingBlock": true,
-  "collapseChangelog": true,
-  "treeFilterMode": "all"
-}