janissary 0.5.4 → 0.6.0

package/ai/tasks/merge-change-to-master.md

@@ -10,8 +10,6 @@ Every step is a script in `scripts/pr-*.sh`, invoked through the script runner.
 
 **Always run scripts in the foreground.** Never use `run_in_background` — each script must complete and return its exit code before the next step begins.
 
-**No subagents, no background agents.** Do every step yourself — never launch a subagent (Task/Agent tool, `fork`, or otherwise) to do any part of this task on your behalf.
-
 **Do not ask the user for input at any point.** Make all decisions autonomously — branch names, commit messages, PR titles and bodies. The only valid reason to stop is an unresolvable error.
 
 ---

package/ai/tasks/open-feature-pull-request.md

@@ -8,8 +8,6 @@ Your job: take the uncommitted work in this repository, package it into a well-d
 
 **Run everything synchronously, in the foreground.** Never use `run_in_background`, `&`, or otherwise start a background process (dev servers, watchers, long-lived processes) — every command must finish and return its exit code before you move to the next step.
 
-**No subagents, no background agents.** Do every step yourself — never launch a subagent (Task/Agent tool, `fork`, or otherwise) to research, explore, or implement any part of this task on your behalf.
-
 ## The PR description
 
 The PR body is the deliverable. It must be **thorough and self-contained** — a reviewer should understand the feature without reading the code. Write it to `./temp/pr-body.md`, then pass that file to the create-PR script.

package/ai/tasks/plan-ready-features.md

@@ -1,13 +1,13 @@
 # Plan Ready Features
 
-Your job: walk the `## ready` section of `product/backlog/features.md` one feature at a time, interview the user with product-focused questions to pin down scope and behavior, and write a draft plan for each into `product/plans/draft/`. You produce plan documents only — you never write source code.
+Your job: walk the `## ready` section of `./product/backlog/features.md` one feature at a time, interview the user with product-focused questions to pin down scope and behavior, and write a draft plan for each into `./product/plans/draft/`. You produce plan documents only — you never write source code.
+
+**Project `./product/` directory.** Every `./product/...` path in this task refers to the product directory in the current working directory — the project being worked on — never to the Janissary codebase's own `product/` directory, even when this task file was launched from an absolute path inside the Janissary installation.
 
 This is an **interactive** task. Unlike the autonomous `ai/tasks/*.md` playbooks, you must stop and ask the user questions before drafting each plan. Do not guess scope, behavior, or edge cases on the user's behalf when a question would resolve it.
 
 **Run everything synchronously, in the foreground.** Never use `run_in_background`, `&`, or otherwise start a background process (dev servers, watchers, long-lived processes) — every command must finish and return its exit code before you move to the next step.
 
-**No subagents, no background agents.** Do every step yourself — never launch a subagent (Task/Agent tool, `fork`, or otherwise) to research, explore, or implement any part of this task on your behalf.
-
 **Follow the steps below in order, exactly as written, one feature at a time.** Do not skip a step, do not merge two steps together, and do not process more than one feature between Step 2a and Step 2f. If you are ever unsure whether you have done enough — re-read the checklist for that step before moving on, don't guess.
 
 **No AI attribution — anywhere.** Never credit an AI agent as an author or contributor in anything this task produces. No `Co-Authored-By:` trailers naming Claude or any other AI, no "Generated with Claude Code" lines, no AI authorship notes in plan files or commit messages. This overrides any default convention that appends such attribution.
@@ -20,15 +20,15 @@ This is an **interactive** task. Unlike the autonomous `ai/tasks/*.md` playbooks
 
 ### Allowed — do it automatically, never ask
 
-Read any file in the repo to ground a plan in real code. Create new plan files under `product/plans/draft/`. Edit `product/backlog/features.md` to remove a `### ` entry from the `## ready` section once its plan has been drafted and confirmed. Ask the user clarifying questions — this is expected, not an interruption to avoid.
+Read any file in the repo to ground a plan in real code. Create new plan files under `./product/plans/draft/`. Edit `./product/backlog/features.md` to remove a `### ` entry from the `## ready` section once its plan has been drafted and confirmed. Ask the user clarifying questions — this is expected, not an interruption to avoid.
 
 ### Forbidden — no exceptions
 
 1. **Writing implementation code into a plan.** No function bodies, no JSX/CSS blocks, no "here's the code." Name the module/type/contract in prose, per `ai/tasks/improve-plan.md`'s rule — the same rule applies here since you are authoring, not implementing.
-2. **Editing any source, test, or config file.** This task only touches `product/backlog/features.md` and files under `product/plans/draft/`.
+2. **Editing any source, test, or config file.** This task only touches `./product/backlog/features.md` and files under `./product/plans/draft/`.
 3. **Skipping the question round.** Never invent a plan's scope, edge-case behavior, or UI wording without asking, when the answer is a product decision rather than something the codebase already settles.
-4. **Moving a plan to `product/plans/ready/`.** That promotion is a separate human/`ai/tasks/improve-plan.md` step. Everything this task produces lands in `product/plans/draft/`.
-5. **Removing a feature's entry from `product/backlog/features.md` before its plan is drafted and the user has confirmed it.** Don't clear the backlog ahead of the plan actually existing.
+4. **Moving a plan to `./product/plans/ready/`.** That promotion is a separate human/`ai/tasks/improve-plan.md` step. Everything this task produces lands in `./product/plans/draft/`.
+5. **Removing a feature's entry from `./product/backlog/features.md` before its plan is drafted and the user has confirmed it.** Don't clear the backlog ahead of the plan actually existing.
 
 ---
 
@@ -40,9 +40,9 @@ Execute `ai/tasks/prepare-workspace.md` in full before doing anything else.
 
 ## Step 1 — Read the ready backlog
 
-1. Read `product/backlog/features.md` in full.
+1. Read `./product/backlog/features.md` in full.
 2. Extract every entry under the `## ready` heading, up to the next `## ` heading. Each entry is a `### <title>` followed by its description body. Copy titles verbatim — do not paraphrase or shorten them.
-3. If the `## ready` section is empty, report "No ready features in `product/backlog/features.md`" and stop.
+3. If the `## ready` section is empty, report "No ready features in `./product/backlog/features.md`" and stop.
 4. Write down the exact ordered list of feature titles as a numbered list in your own working notes, e.g.:
    ```
    1. profile launcher
@@ -64,14 +64,14 @@ Before starting each feature, say in one sentence which feature (by number and t
 Do exactly this, in order, before asking any question:
 
 1. Grep the repo for the feature's key nouns (e.g. for "profile launcher", grep for `profile` and `picker`) to find existing related code.
-2. Read any spec file under `product/specs/` whose name matches the feature's topic.
+2. Read any spec file under `./product/specs/` whose name matches the feature's topic.
 3. If the feature's description names an existing feature as a comparison point (e.g. "just like action picker"), open that feature's implementation and read it.
 
 Stop after these three checks — this is reconnaissance, not a design phase. Do not spend more than a few minutes here. If you find nothing related, that is a valid outcome; say so and move on to 2b.
 
 ### 2b. Decide whether this feature needs implementation questions
 
-Answer these four yes/no checks about the feature, using only what the feature's `product/backlog/features.md` text says plus what you found in 2a:
+Answer these four yes/no checks about the feature, using only what the feature's `./product/backlog/features.md` text says plus what you found in 2a:
 
 1. Does it require a **new subsystem** (not an extension of one that already exists)?
 2. Does it require a **new client/server protocol message or RPC**?
@@ -91,7 +91,7 @@ Ask the user questions using `AskUserQuestion`, one call per round, **maximum 4
 - **Scope boundary** — what is explicitly *not* included in this version.
 - **Naming/wording** — any user-visible text (labels, commands, messages) the plan needs to fix precisely.
 
-Skip a category only if the feature's existing description in `product/backlog/features.md` already answers it unambiguously — quote that text back to the user as your understanding rather than silently assuming it.
+Skip a category only if the feature's existing description in `./product/backlog/features.md` already answers it unambiguously — quote that text back to the user as your understanding rather than silently assuming it.
 
 Every question must offer concrete options grounded in what you found in Step 2a, rather than an open-ended "what should happen?". If a question has no natural small set of options, still propose your best-guess default as one of the options so the user can simply confirm it.
 
@@ -108,7 +108,7 @@ If any box is unchecked, ask one more round (max 4 questions) targeting only the
 
 ### 2d. Draft the plan
 
-Write `product/plans/draft/<slug>.md`, where `<slug>` is a kebab-case name derived from the feature's `### ` title (lowercase, spaces to hyphens, strip punctuation — e.g. "profile launcher" → `profile-launcher.md`). Follow the house style used in `product/plans/ready/` (skim an existing one, e.g. `product/plans/ready/monitor-page-tab-content-feed.md`, for shape). The plan file must contain, in this order, every one of these sections — do not omit any:
+Write `./product/plans/draft/<slug>.md`, where `<slug>` is a kebab-case name derived from the feature's `### ` title (lowercase, spaces to hyphens, strip punctuation — e.g. "profile launcher" → `profile-launcher.md`). Follow the house style used in `./product/plans/ready/` (skim an existing one, e.g. `./product/plans/ready/monitor-page-tab-content-feed.md`, for shape). The plan file must contain, in this order, every one of these sections — do not omit any:
 
 1. `# <Feature name>` title.
 2. A short summary paragraph: what the feature does and why, folding in what the user told you in 2c.
@@ -130,11 +130,11 @@ Before moving on, check the plan file against this list:
 
 ### 2e. Confirm with the user
 
-Show the user a brief summary of the drafted plan (goal, key decisions, out-of-scope boundary) and confirm it matches what they described. If they want changes, edit the plan and show the summary again — repeat until confirmed. If they want to abandon the feature entirely, delete `product/plans/draft/<slug>.md` if you already wrote it, leave the entry in `product/backlog/features.md` untouched, note it as skipped, and move to the next feature in the queue.
+Show the user a brief summary of the drafted plan (goal, key decisions, out-of-scope boundary) and confirm it matches what they described. If they want changes, edit the plan and show the summary again — repeat until confirmed. If they want to abandon the feature entirely, delete `./product/plans/draft/<slug>.md` if you already wrote it, leave the entry in `./product/backlog/features.md` untouched, note it as skipped, and move to the next feature in the queue.
 
 ### 2f. Remove the entry from the backlog
 
-Once confirmed, edit `product/backlog/features.md` to remove that feature's `### ` entry (title and body) from the `## ready` section. Leave every other section, heading, and entry byte-for-byte untouched — do not reformat or reflow surrounding text.
+Once confirmed, edit `./product/backlog/features.md` to remove that feature's `### ` entry (title and body) from the `## ready` section. Leave every other section, heading, and entry byte-for-byte untouched — do not reformat or reflow surrounding text.
 
 Only after this step is complete, return to the top of Step 2 for the next feature in the queue.
 
@@ -146,9 +146,9 @@ After all ready features are processed (planned or explicitly skipped per 2e), g
 
 ```
 Processed:  N ready features
-Planned:    product/plans/draft/<file> — <one-line goal>   (repeat per feature)
+Planned:    ./product/plans/draft/<file> — <one-line goal>   (repeat per feature)
 Skipped:    <feature title> — <why, if any were abandoned>
-Backlog:    product/backlog/features.md updated, N entries removed from ## ready
+Backlog:    ./product/backlog/features.md updated, N entries removed from ## ready
 ```
 
 Keep it brief. Done.

package/ai/tasks/prepare-workspace.md

@@ -4,8 +4,6 @@
 
 **Run everything synchronously, in the foreground.** Never use `run_in_background`, `&`, or otherwise start a background process (dev servers, watchers, long-lived processes) — every command must finish and return its exit code before you move to the next step.
 
-**No subagents, no background agents.** Do every step yourself — never launch a subagent (Task/Agent tool, `fork`, or otherwise) to research, explore, or implement any part of this task on your behalf.
-
 ---
 
 ## Step 1 — Pull latest changes

package/ai/tasks/quick-commit.md

@@ -6,8 +6,6 @@ Your job: package the current working-tree changes into **one** commit on the **
 
 **Run scripts in the foreground** (never `run_in_background`) — each must finish and return its exit code before the next step. **Make all decisions autonomously** (commit type, scope, message); the only reason to stop is an unresolvable error.
 
-**No subagents, no background agents.** Do every step yourself — never launch a subagent (Task/Agent tool, `fork`, or otherwise) to do any part of this task on your behalf.
-
 ---
 
 ## Step 1 — Compose a Conventional Commits message

package/ai/tasks/reduce-complexity.md

@@ -8,8 +8,6 @@ This task is about complexity, not file size: **all code you touch must stay in
 
 **Run everything synchronously, in the foreground.** Never use `run_in_background`, `&`, or otherwise start a background process (dev servers, watchers, long-lived processes) — every command must finish and return its exit code before you move to the next step.
 
-**No subagents, no background agents.** Do every step yourself — never launch a subagent (Task/Agent tool, `fork`, or otherwise) to research, explore, or implement any part of this task on your behalf.
-
 Refactoring edits real code, so the rule is simple: **the tests must pass before you start and still pass after. If you cannot keep them passing, put the code back the way it was.**
 
 Do the steps below **in order**. Do not skip steps. Do not invent your own process.

package/ai/tasks/remove-deadcode.md

@@ -8,8 +8,6 @@ The rule is simple: **the compiler, the linter, and the tests must be green befo
 
 **Run everything synchronously, in the foreground.** Never use `run_in_background`, `&`, or otherwise start a background process (dev servers, watchers, long-lived processes) — every command must finish and return its exit code before you move to the next step.
 
-**No subagents, no background agents.** Do every step yourself — never launch a subagent (Task/Agent tool, `fork`, or otherwise) to research, explore, or implement any part of this task on your behalf.
-
 **Shell hygiene:** run every command on its own line — no `&&` chaining, no `; echo "Exit code: $?"` suffixes, no subshell captures. The exit code and output are visible in the tool result. To run a project script, always use `./scripts/run.mjs <name>` — never call `node scripts/<name>.mjs` directly.
 
 Do the steps below **in order**. Do not skip steps. Do not invent your own process.

package/ai/tasks/remove-duplication.md

@@ -8,8 +8,6 @@ Deduplication edits real code that other files may import, so the rule is simple
 
 **Run everything synchronously, in the foreground.** Never use `run_in_background`, `&`, or otherwise start a background process (dev servers, watchers, long-lived processes) — every command must finish and return its exit code before you move to the next step.
 
-**No subagents, no background agents.** Do every step yourself — never launch a subagent (Task/Agent tool, `fork`, or otherwise) to research, explore, or implement any part of this task on your behalf.
-
 **Shell hygiene:** run every command on its own line — no `&&` chaining, no `; echo "Exit code: $?"` suffixes, no subshell captures. The exit code and output are visible in the tool result. To run a project script, always use `./scripts/run.mjs <name>` — never call `node scripts/<name>.mjs` directly.
 
 Do the steps below **in order**. Do not skip steps. Do not invent your own process.

package/ai/tasks/update-package.md

@@ -8,8 +8,6 @@ Your job: update **one** npm package to the latest version its existing `package
 
 **Run everything synchronously, in the foreground.** Never use `run_in_background`, `&`, or otherwise start a background process (dev servers, watchers, long-lived processes) — every command must finish and return its exit code before you move to the next step.
 
-**No subagents, no background agents.** Do every step yourself — never launch a subagent (Task/Agent tool, `fork`, or otherwise) to research, explore, or implement any part of this task on your behalf.
-
 **Run autonomously.** This task runs unattended — do not ask the user questions or wait for feedback at any step. Only stop early for the conditions explicitly listed below.
 
 The rule is simple: **the compiler, the linter, and the tests must be green before you start and green again after you finish.** If not green before you start, stop and tell the user. If you can't get it green again after two fix attempts, put the package back and stop.

package/dist/agent/commands.js

@@ -1,4 +1,4 @@
-import agentNames from '../../agent-names.json' with { type: 'json' };
+import { agentNames } from '../agent-names.js';
 import { getConfig } from '../config.js';
 export function resolveAgentName(input, existingLabels) {
     const trimmed = input.trim();

package/dist/agent-names.js

@@ -0,0 +1,21 @@
+import { existsSync, readFileSync } from 'node:fs';
+import path from 'node:path';
+import defaultNames from '../agent-names.json' with { type: 'json' };
+export let agentNames = defaultNames;
+// Reads `.janissary/agent-names.json` from the project directory and, when present and valid,
+// uses it in place of the bundled name list for the rest of this run — the same load-with-fallback
+// contract as `config.ts`'s `.janissary/config.json`.
+export function loadAgentNames(projectDirectory) {
+    const overridePath = path.join(projectDirectory, '.janissary', 'agent-names.json');
+    if (!existsSync(overridePath)) {
+        agentNames = defaultNames;
+        return;
+    }
+    try {
+        agentNames = JSON.parse(readFileSync(overridePath, 'utf8'));
+    }
+    catch {
+        process.stderr.write('warning: .janissary/agent-names.json is invalid JSON — using the bundled name list\n');
+        agentNames = defaultNames;
+    }
+}

package/dist/buffer.js

@@ -27,13 +27,13 @@ export function formatMessageContent(entry, parts) {
     const kind = entry.msgKind ?? 'info';
     const lines = [];
     if (kind === 'response') {
-        lines.push({ type: 'message', text: '', from: entry.from, fromColor: entry.fromColor, msgKind: 'response' });
+        lines.push({ type: 'message', text: '', from: entry.from, fromColor: entry.fromColor, msgKind: 'response', ...(entry.openFile && { openFile: entry.openFile }) });
         for (const line of parts) {
             lines.push({ type: 'output', text: expandTabs(line), fromColor: entry.fromColor });
         }
     }
     else {
-        lines.push({ type: 'message', text: expandTabs(parts[0] ?? ''), from: entry.from, fromColor: entry.fromColor, msgKind: kind });
+        lines.push({ type: 'message', text: expandTabs(parts[0] ?? ''), from: entry.from, fromColor: entry.fromColor, msgKind: kind, ...(entry.openFile && { openFile: entry.openFile }) });
         for (const extra of parts.slice(1)) {
             lines.push({ type: 'output', text: expandTabs(extra), fromColor: entry.fromColor });
         }

package/dist/cli-args.js

@@ -73,8 +73,14 @@ Environment:
   JANUS_DEBUG=1  print stack traces on failure
 `;
 }
-export function appVersion() {
+function readPackageInfo() {
     const packagePath = path.join(import.meta.dirname, '..', 'package.json');
-    const pkg = JSON.parse(readFileSync(packagePath, 'utf8'));
+    return JSON.parse(readFileSync(packagePath, 'utf8'));
+}
+export function appVersion() {
+    const pkg = readPackageInfo();
     return `${pkg.name} ${pkg.version}`;
 }
+export function appVersionNumber() {
+    return readPackageInfo().version;
+}

package/dist/command-manager.js

@@ -79,6 +79,12 @@ export class CommandManager {
     }
     run(input, label, index) {
         if (/^harness\b/i.test(input)) {
+            // Bare `harness` (no args) opens the launch dialog instead of erroring; no transcript line is
+            // recorded, so nothing is appended ahead of the dialog. Every other `harness …` form runs.
+            if (input.trim().toLowerCase() === 'harness') {
+                this.managers.harness.openLaunchDialog();
+                return;
+            }
             this.managers.tab.append(label, { input, output: '' });
             const error = this.managers.harness.run(input);
             if (error)

package/dist/commands/index.js

@@ -22,6 +22,7 @@ import { command as rename } from './rename.js';
 import { command as search } from './search.js';
 import { command as files } from './files.js';
 import { command as notifications } from './notifications.js';
+import { command as schedules } from './schedules.js';
 import { command as notify } from './notify.js';
 import { command as syntax } from './syntax.js';
 import { command as theme } from './theme.js';
@@ -52,6 +53,7 @@ export const commands = [
     search,
     files,
     notifications,
+    schedules,
     notify,
     syntax,
     theme,

package/dist/commands/schedules.js

@@ -0,0 +1,17 @@
+import { openSchedulesTab } from '../schedules-tab.js';
+// `schedules` opens (or focuses) the singleton schedules tab — the aggregated, next-to-run-ordered
+// list of every scheduled command across all tabs. `schedules left` / `schedules right` dock it into
+// that sidebar, mirroring `notifications [left|right]`. Bare `schedules` on a docked tab undocks it
+// back to center and makes it active. The tab is a singleton — a second invocation reuses it. This is
+// distinct from the singular `schedule` command, which creates and manages a tab's own timers.
+export const command = {
+    name: 'schedules',
+    match: (command_) => /^schedules\b/i.test(command_),
+    run: (command_, tab, managers) => {
+        managers.tab.append(tab.label, { input: command_, output: '' });
+        const rest = command_.replace(/^schedules\b\s*/i, '');
+        const keyword = /^(left|right)\b/i.exec(rest);
+        const dock = keyword ? keyword[1].toLowerCase() : undefined;
+        openSchedulesTab(managers, dock);
+    },
+};

package/dist/commands.js

@@ -67,4 +67,4 @@ export const getOutput = (command) => {
         return null;
     return `Unknown command: "${trimmed}". Type "help" for available commands.`;
 };
-export { default as agentNames } from '../agent-names.json' with { type: 'json' };
+export { agentNames } from './agent-names.js';

package/dist/controller.js

@@ -11,7 +11,7 @@ import { ScheduleManager } from './schedule/manager.js';
 import { ProfileManager } from './profile/manager.js';
 import { ConnectionManager } from './connection/manager.js';
 import { OpenFileManager } from './open-file-manager.js';
-import { FileTreeManager } from './file-tree-manager.js';
+import { FileTreeManager } from './file-tree/manager.js';
 import * as fileTreeRpc from './controller-file-tree.js';
 import { wireControllerEvents } from './controller-events.js';
 import { EditorWatchManager } from './editor/watch-manager.js';
@@ -63,7 +63,7 @@ export class Controller {
             this.managers.schedule.set(s.name, s.schedule); });
     }
     view() {
-        return this.managers.tab.view((l) => this.managers.connection.connectionsFor(l), (l) => this.managers.acp.label(l), (l) => this.managers.schedule.view(l));
+        return this.managers.tab.view((l) => this.managers.connection.connectionsFor(l), (l) => this.managers.acp.label(l), (l) => this.managers.schedule.view(l), this.managers.schedule.aggregatedView());
     }
     routeView() {
         return this.managers.command.routeView();
@@ -71,6 +71,12 @@ export class Controller {
     chooseRoute(index) {
         this.managers.command.chooseRoute(index);
     }
+    harnessLaunchView() {
+        return this.managers.harness.harnessLaunchView();
+    }
+    closeHarnessLaunch() {
+        this.managers.harness.closeLaunchDialog();
+    }
     dispatch(text) {
         this.managers.command.dispatch(text);
     }
@@ -168,6 +174,10 @@ export class Controller {
     openFileNavigatorFor(label) {
         fileTreeRpc.openFileNavigatorFor(this.managers, label);
     }
+    // Launch a new agent tab rooted at the named tab's cwd — the ➕ metadata-row button.
+    launchAgentFor(label) {
+        this.managers.profile.newAgentAt(label);
+    }
     // Tab-completion for the command line (reuses the shared `completeCommandLine`): filesystem
     // paths against the active tab's cwd, `msg`/`broadcast` agent names, `connection close` targets,
     // and `browser` subcommands / window ids.

package/dist/database/index.js

@@ -2,6 +2,7 @@ import { databaseFileExists as databaseFileExists, listDatabaseFiles, removeData
 import { parseDatabaseCommand } from './parsing.js';
 export { parseDatabaseCommand } from './parsing.js';
 import { queryDatabase } from './query.js';
+export { DB_PRIMER, extractDatabaseCommand } from './primer.js';
 function errorMessage(error) {
     return error instanceof Error ? error.message : String(error);
 }
@@ -51,33 +52,3 @@ export function runDatabaseCommand(input) {
         }
     }
 }
-// Primer injected into an ACP agent so it understands the `db` grammar and can
-// drive an autonomous tool loop: it emits a command, the host runs it, and the
-// output is fed back until the agent answers without a command.
-export const DB_PRIMER = [
-    'This host CLI can manage SQLite databases via `db` commands. Syntax:',
-    '  db sqlite create <name>          # create an empty database',
-    '  db sqlite delete <name>          # delete a database',
-    '  db sqlite query  <name> <sql>    # run SQL against a database',
-    '  db sqlite list                   # list databases',
-    'Database names use letters, numbers, "-" and "_" only; the engine is always "sqlite".',
-    'To inspect or change a database, end your reply with exactly one `db` command on its',
-    'own final line (no code fence, nothing after it). The host runs it automatically and',
-    'returns the output to you, so you can issue further commands. When the task is done,',
-    'reply with the final answer and NO trailing `db` command.',
-    'Be concise: do not explain what you are doing. Only output `db` commands and the final answer.',
-].join('\n');
-/**
- * Pull a proposed `db ...` command out of an agent reply, if present. Scans
- * bottom-up (the primer asks for the command on the last line) and tolerates a
- * surrounding code fence or a leading `$ `/`> ` prompt marker.
- */
-export function extractDatabaseCommand(text) {
-    const lines = text.split('\n');
-    for (let index = lines.length - 1; index >= 0; index--) {
-        const line = lines[index].replace(/^[\s`$>]+/, '').replace(/`+\s*$/, '').trim();
-        if (/^db\s+sqlite\s+(create|delete|query|list)\b/i.test(line))
-            return line;
-    }
-    // not a db command
-}

package/dist/database/primer.js

@@ -0,0 +1,30 @@
+// Primer injected into an ACP agent so it understands the `db` grammar and can
+// drive an autonomous tool loop: it emits a command, the host runs it, and the
+// output is fed back until the agent answers without a command.
+export const DB_PRIMER = [
+    'This host CLI can manage SQLite databases via `db` commands. Syntax:',
+    '  db sqlite create <name>          # create an empty database',
+    '  db sqlite delete <name>          # delete a database',
+    '  db sqlite query  <name> <sql>    # run SQL against a database',
+    '  db sqlite list                   # list databases',
+    'Database names use letters, numbers, "-" and "_" only; the engine is always "sqlite".',
+    'To inspect or change a database, end your reply with exactly one `db` command on its',
+    'own final line (no code fence, nothing after it). The host runs it automatically and',
+    'returns the output to you, so you can issue further commands. When the task is done,',
+    'reply with the final answer and NO trailing `db` command.',
+    'Be concise: do not explain what you are doing. Only output `db` commands and the final answer.',
+].join('\n');
+/**
+ * Pull a proposed `db ...` command out of an agent reply, if present. Scans
+ * bottom-up (the primer asks for the command on the last line) and tolerates a
+ * surrounding code fence or a leading `$ `/`> ` prompt marker.
+ */
+export function extractDatabaseCommand(text) {
+    const lines = text.split('\n');
+    for (let index = lines.length - 1; index >= 0; index--) {
+        const line = lines[index].replace(/^[\s`$>]+/, '').replace(/`+\s*$/, '').trim();
+        if (/^db\s+sqlite\s+(create|delete|query|list)\b/i.test(line))
+            return line;
+    }
+    // not a db command
+}

package/dist/file-tree/args.js

@@ -0,0 +1,36 @@
+// Parses the argument tail of a `files [left|right] [path]` / `files in <label> [on <side>]`
+// command. Consumes leading `in <label>` / `on <left|right>` clauses (either order, each at most
+// once), then falls back to the bare `left`/`right` keyword if neither clause was used. Whatever's
+// left over is the path target.
+export function parseFileTreeArgs(rest) {
+    let cursor = rest;
+    let inLabel;
+    let dock = null;
+    for (;;) {
+        if (inLabel === undefined) {
+            const inMatch = /^in\s+(\S+)\b\s*/i.exec(cursor);
+            if (inMatch) {
+                inLabel = inMatch[1];
+                cursor = cursor.slice(inMatch[0].length);
+                continue;
+            }
+        }
+        if (dock === null) {
+            const onMatch = /^on\s+(left|right)\b\s*/i.exec(cursor);
+            if (onMatch) {
+                dock = onMatch[1].toLowerCase();
+                cursor = cursor.slice(onMatch[0].length);
+                continue;
+            }
+        }
+        break;
+    }
+    if (inLabel === undefined && dock === null) {
+        const keyword = /^(left|right)\b\s*/i.exec(cursor);
+        if (keyword) {
+            dock = keyword[1].toLowerCase();
+            cursor = cursor.slice(keyword[0].length);
+        }
+    }
+    return { inLabel, dock, target: cursor.trim() };
+}

package/dist/file-tree/git-refresh.js

@@ -0,0 +1,33 @@
+import { changedPaths, currentBranch } from '../git-status.js';
+// Recompute one tab's git-changed set and current branch off the event loop, then re-render with
+// them via `rebuild` (decision 6's second `dirty` emit). Coalesced: if a refresh is already in
+// flight for this tab, the request only sets a stale bit and exactly one follow-up runs when the
+// current one resolves — no overlapping git processes. The captured `root` guards against a
+// mid-flight `reroot` or tab close: a result whose tab is gone or whose root has changed is
+// discarded, never written.
+export function refreshGit(states, label, rebuild) {
+    const state = states.get(label);
+    if (!state)
+        return;
+    if (state.gitRefreshing) {
+        state.gitRefreshStale = true;
+        return;
+    }
+    state.gitRefreshing = true;
+    const root = state.root;
+    void Promise.all([changedPaths(root), currentBranch(root)]).then(([changed, branch]) => {
+        const current = states.get(label);
+        if (!current)
+            return;
+        if (current.root === root) {
+            current.changed = changed;
+            current.branch = branch;
+            rebuild(label);
+        }
+        current.gitRefreshing = false;
+        if (current.gitRefreshStale) {
+            current.gitRefreshStale = false;
+            refreshGit(states, label, rebuild);
+        }
+    });
+}

package/dist/file-tree/index.js

@@ -0,0 +1,82 @@
+import { readdirSync } from 'node:fs';
+import path from 'node:path';
+// VS Code's `files.exclude` defaults. Other dotfiles are shown.
+const EXCLUDES = new Set(['.git', '.svn', '.hg', '.DS_Store', 'Thumbs.db']);
+// One directory's sorted, filtered entries: directories first, then files, `localeCompare`
+// case-insensitive within each group. A symlink (file or directory) reports as a file — never
+// expandable — which is the cheap way to stay cycle-proof. An unreadable directory (permission
+// denied, deleted mid-read) yields [].
+export function readDirSorted(absDir) {
+    let dirents;
+    try {
+        dirents = readdirSync(absDir, { withFileTypes: true });
+    }
+    catch {
+        return [];
+    }
+    const entries = dirents
+        .filter((d) => !EXCLUDES.has(d.name))
+        .map((d) => ({ name: d.name, dir: d.isDirectory() }));
+    return entries.toSorted((a, b) => {
+        if (a.dir !== b.dir)
+            return a.dir ? -1 : 1;
+        return a.name.localeCompare(b.name, undefined, { sensitivity: 'base' });
+    });
+}
+// A depth-first, pre-flattened list of the currently *visible* rows: the root's direct children,
+// plus — for each directory whose path is in `expanded` — that directory's children too, and so
+// on. Children are read from disk only for expanded directories. An `expanded` entry for a path
+// that no longer exists (or isn't found under its parent) is simply never reached, so it's
+// naturally skipped rather than needing special-case pruning here.
+export function buildRows(root, expanded) {
+    const rows = [];
+    const walk = (absDir, relDir, depth) => {
+        for (const entry of readDirSorted(absDir)) {
+            const relPath = relDir ? `${relDir}/${entry.name}` : entry.name;
+            const isExpanded = entry.dir && expanded.has(relPath);
+            rows.push({
+                path: relPath, name: entry.name, depth, dir: entry.dir,
+                ...(entry.dir && { expanded: isExpanded }),
+            });
+            if (isExpanded)
+                walk(path.join(absDir, entry.name), relPath, depth + 1);
+        }
+    };
+    walk(root, '', 0);
+    if (path.dirname(root) !== root) {
+        rows.unshift({ path: '..', name: '..', depth: 0, dir: true });
+    }
+    return rows;
+}
+// Return `rows` with a `changed` flag set on every row git considers changed: a file row when its
+// own `path` is in `changed`; a directory row when any changed path is nested beneath it (a prefix
+// check, `changedPath` starts with `${row.path}/`). Propagation is purely this flat-set prefix
+// scan — no directory is re-read, so a collapsed directory still colors when something deep inside
+// it changed. Rows with no match are returned as-is; an empty `changed` set marks nothing.
+export function markChanged(rows, changed) {
+    if (changed.size === 0)
+        return rows;
+    return rows.map((row) => {
+        const isChanged = row.dir
+            ? [...changed].some((p) => p.startsWith(`${row.path}/`))
+            : changed.has(row.path);
+        return isChanged ? { ...row, changed: true } : row;
+    });
+}
+// The containing directory of a tree-relative path — the empty string for a root-level entry,
+// matching the root-as-empty-string convention `buildRows` already uses.
+export function parentPath(relPath) {
+    const idx = relPath.lastIndexOf('/');
+    return idx === -1 ? '' : relPath.slice(0, idx);
+}
+// True if `candidate` is `base` itself, or is nested inside it — the check that blocks dropping a
+// dragged item onto itself or one of its own descendants (moving a directory into its own child).
+export function isSameOrDescendantPath(candidate, base) {
+    return candidate === base || candidate.startsWith(`${base}/`);
+}
+// True if the directory at `absDestDir` already has a child named `name` — used to detect a
+// same-name conflict at the drop target. Re-reads the destination directory fresh from disk
+// rather than trusting the client's row list, which can be briefly stale.
+export function hasNameConflict(absDestDir, name) {
+    return readDirSorted(absDestDir).some((e) => e.name === name);
+}