bb-app 0.0.4 → 0.0.5

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "bb-app",
-  "version": "0.0.4",
+  "version": "0.0.5",
   "description": "bb app launcher for npx",
   "keywords": [
     "bb",

package/server/dist/index.js

@@ -225425,6 +225425,11 @@ var projectFilesQuerySchema = external_exports.object({
     external_exports.string().min(1).nullable()
   )
 });
+var pathListIncludeQueryValueSchema = external_exports.enum(["true", "false"]);
+var projectPathsQuerySchema = projectFilesQuerySchema.extend({
+  includeFiles: pathListIncludeQueryValueSchema,
+  includeDirectories: pathListIncludeQueryValueSchema
+});
 var projectBranchesQuerySchema = external_exports.object({
   hostId: external_exports.string().min(1)
 });
@@ -225592,6 +225597,10 @@ var threadStorageFilesQuerySchema = external_exports.object({
   query: external_exports.string().min(1).max(FILE_LIST_QUERY_MAX_LENGTH),
   limit: external_exports.string().regex(/^\d+$/)
 }).partial();
+var threadStoragePathsQuerySchema = threadStorageFilesQuerySchema.extend({
+  includeFiles: pathListIncludeQueryValueSchema,
+  includeDirectories: pathListIncludeQueryValueSchema
+});
 var threadStorageContentQuerySchema = external_exports.object({
   path: external_exports.string().min(1)
 });
@@ -225777,10 +225786,22 @@ var workspaceFileSchema = external_exports.object({
   path: external_exports.string(),
   name: external_exports.string()
 });
+var workspacePathEntryKindSchema = external_exports.enum(["file", "directory"]);
+var workspacePathEntrySchema = external_exports.object({
+  kind: workspacePathEntryKindSchema,
+  path: external_exports.string(),
+  name: external_exports.string(),
+  score: external_exports.number(),
+  positions: external_exports.array(external_exports.number().int().nonnegative())
+});
 var workspaceFileListResponseSchema = external_exports.object({
   files: external_exports.array(workspaceFileSchema),
   truncated: external_exports.boolean()
 });
+var workspacePathListResponseSchema = external_exports.object({
+  paths: external_exports.array(workspacePathEntrySchema),
+  truncated: external_exports.boolean()
+});
 var threadStorageFileListResponseSchema = workspaceFileListResponseSchema.extend({
   /**
    * Absolute on-host path to the thread's storage directory. Useful for
@@ -225791,6 +225812,16 @@ var threadStorageFileListResponseSchema = workspaceFileListResponseSchema.extend
    */
   storageRootPath: external_exports.string()
 });
+var threadStoragePathListResponseSchema = workspacePathListResponseSchema.extend({
+  /**
+   * Absolute on-host path to the thread's storage directory. Useful for
+   * clients that need to construct a full path for filesystem operations
+   * (e.g. opening a storage file in the user's editor). The path is on
+   * the thread's host machine, so it is only usable when that host is the
+   * user's local machine.
+   */
+  storageRootPath: external_exports.string()
+});
 var projectResponseSchema = projectSchema.extend({
   sources: external_exports.array(projectSourceSchema)
 });
@@ -227142,7 +227173,7 @@ var healthResponseSchema = external_exports.string().min(1);
 
 // ../../packages/host-daemon-contract/src/commands.ts
 init_zod();
-var HOST_DAEMON_PROTOCOL_VERSION = 17;
+var HOST_DAEMON_PROTOCOL_VERSION = 18;
 var FILE_LIST_QUERY_MAX_LENGTH2 = 256;
 var FILE_LIST_LIMIT_MAX = 1e4;
 var HOST_DAEMON_COMMAND_TYPES = [
@@ -227157,6 +227188,7 @@ var HOST_DAEMON_COMMAND_TYPES = [
   "codex.inference.complete",
   "codex.voice.transcribe",
   "host.list_files",
+  "host.list_paths",
   "host.list_branches",
   "host.read_file",
   "provider.list",
@@ -227322,6 +227354,24 @@ var hostListFilesCommandSchema = external_exports.object({
   query: external_exports.string().max(FILE_LIST_QUERY_MAX_LENGTH2).optional(),
   limit: external_exports.number().int().positive().max(FILE_LIST_LIMIT_MAX)
 });
+var hostPathEntryKindSchema = external_exports.enum(["file", "directory"]);
+var hostPathEntrySchema = external_exports.object({
+  kind: hostPathEntryKindSchema,
+  path: external_exports.string(),
+  name: external_exports.string(),
+  score: external_exports.number(),
+  positions: external_exports.array(external_exports.number().int().nonnegative())
+});
+var hostListPathsCommandSchema = external_exports.object({
+  type: external_exports.literal("host.list_paths"),
+  path: external_exports.string().min(1),
+  query: external_exports.string().max(FILE_LIST_QUERY_MAX_LENGTH2).optional(),
+  limit: external_exports.number().int().positive().max(FILE_LIST_LIMIT_MAX),
+  includeFiles: external_exports.boolean(),
+  includeDirectories: external_exports.boolean()
+}).refine((command) => command.includeFiles || command.includeDirectories, {
+  message: "At least one path kind must be included"
+});
 var hostListBranchesCommandSchema = external_exports.object({
   type: external_exports.literal("host.list_branches"),
   path: external_exports.string().min(1)
@@ -227416,6 +227466,7 @@ var hostDaemonNonProvisionCommandSchema = external_exports.discriminatedUnion("t
   codexInferenceCompleteCommandSchema,
   codexVoiceTranscribeCommandSchema,
   hostListFilesCommandSchema,
+  hostListPathsCommandSchema,
   hostListBranchesCommandSchema,
   hostReadFileCommandSchema,
   providerListCommandSchema,
@@ -227441,6 +227492,10 @@ var fileListResultSchema = external_exports.object({
   files: external_exports.array(external_exports.object({ path: external_exports.string(), name: external_exports.string() })),
   truncated: external_exports.boolean()
 });
+var pathListResultSchema = external_exports.object({
+  paths: external_exports.array(hostPathEntrySchema),
+  truncated: external_exports.boolean()
+});
 var hostDaemonCommandResultSchemaByType = {
   "thread.start": external_exports.object({
     providerThreadId: external_exports.string().min(1)
@@ -227467,6 +227522,7 @@ var hostDaemonCommandResultSchemaByType = {
     text: external_exports.string()
   }),
   "host.list_files": fileListResultSchema,
+  "host.list_paths": pathListResultSchema,
   "host.list_branches": external_exports.object({
     branches: external_exports.array(external_exports.string()),
     /** HEAD of the primary checkout at `path`. Null when the path is not a git repo. */
@@ -228167,6 +228223,17 @@ var templateDefinitions = [
       "messageText": "The original message text sent by the agent."
     }
   },
+  {
+    "id": "bbGuideAsync",
+    "body": 'Async scheduled nudges\n\nUse `ASYNC.md` in thread storage when the system should wake a manager thread\nlater for reminders, recurring check-ins, or follow-up work.\n\n`ASYNC.md` is Markdown with YAML frontmatter:\n\n```yaml\n---\ntimezone: America/Los_Angeles\nschedules:\n  - name: daily-recap\n    cron: "0 8 * * 1-5"\n  - name: deploy-check\n    cron: "0 */2 * * *"\n    timezone: UTC\n---\n```\n\nEach schedule has a matching `## <name>` section in the body with instructions\nfor your future self. The top-level `timezone` defaults to UTC; each schedule\ncan override it.\n\nFor one-off reminders like "in 10 minutes", encode the next daily occurrence\nand note in the body to remove the schedule after it fires once.\n\nKeep schedule `name` values stable. The server syncs entries by name, so\nrenaming one creates a new schedule rather than editing it.\n\nConstraints:\n\n- No more than 20 schedules.\n- No interval shorter than 5 minutes.\n- The cron month field must stay `*`.\n\nWhen a scheduled nudge arrives, read the matching section in `ASYNC.md` and\ndecide whether there is real work to do. Only message the user when the nudge\nproduced something useful. Remove schedules that are no longer needed.',
+    "fileName": "bb-guide-async.md",
+    "kind": "instruction",
+    "title": "bb Guide - Async",
+    "summary": "Scheduled nudge reference for ASYNC.md.",
+    "intent": "Explain how to define scheduled nudges for manager threads.",
+    "editingNotes": "Keep this as the canonical ASYNC.md syntax reference. Manager prompts should point here instead of inlining schedule syntax.",
+    "variables": {}
+  },
   {
     "id": "bbGuideEnvironments",
     "body": "Environment commands\n\nEnvironments determine where threads run. Multiple threads can share an environment\n(e.g., a coding thread and a review thread in the same worktree).\n\n  bb environment show <id>                Show environment details (path, branch, status)\n\n  bb environment update <id>              Update environment metadata\n    --merge-base-branch <branch>          Set merge-base branch override\n    --clear-merge-base-branch             Clear merge-base override\n\n  bb environment commit <id>              Create a commit in the environment\n\n  bb environment squash-merge <id>        Squash-merge into a target branch\n    --merge-base-branch <branch>          Target branch (required)",
@@ -228202,7 +228269,7 @@ var templateDefinitions = [
   },
   {
     "id": "bbGuideOverview",
-    "body": "bb is an agent orchestration tool for managing multiple agents.\n\nCore concepts:\n\n- Project \u2014 maps to a repository. All threads belong to a project.\n- Thread \u2014 a single agent conversation. The fundamental unit of work.\n- Environment \u2014 where a thread runs. Kinds: project checkout or isolated worktree. Multiple threads can share an environment.\n- Provider \u2014 the agent backend powering a thread (e.g., codex, claude-code). Each provider supports different models.\n- Host \u2014 where environments run. Hosts are long-lived local or remote machines.\n\nThread types:\n\n- standard \u2014 does coding, research, debugging, or other tasks.\n- manager \u2014 coordinates work across other threads. Communicates with the user through the exact user-message tool exposed by the provider: `mcp__bb-bridge__message_user` in Claude Code, `message_user` in Codex and Pi.\n\nThreads can have a parent-child relationship. The parent manages the child and receives lifecycle notifications when it completes, fails, or is interrupted. Threads without a parent are managed by the user.\n\nContext variables set automatically inside a thread environment:\n\n- BB_PROJECT_ID \u2014 current project\n- BB_THREAD_ID \u2014 current thread\n- BB_ENVIRONMENT_ID \u2014 current environment\n\nRun `bb status` to see your current context (resolved project and thread IDs).\n\nAll commands support --json for machine-readable output.\n\nRun `bb guide <chapter>` for command details:\n\n  threads        Spawning, inspecting, messaging, and managing threads\n  environments   Environment operations, commits, and merges\n  managers       Hiring and managing project managers\n  providers      Discovering providers and models\n  projects       Project CRUD and sources\n  hosts          Listing and understanding hosts\n  styling        How to style STATUS.html to match the bb UI",
+    "body": "bb is an agent orchestration tool for managing multiple agents.\n\nCore concepts:\n\n- Project \u2014 maps to a repository. All threads belong to a project.\n- Thread \u2014 a single agent conversation. The fundamental unit of work.\n- Environment \u2014 where a thread runs. Kinds: project checkout or isolated worktree. Multiple threads can share an environment.\n- Provider \u2014 the agent backend powering a thread (e.g., codex, claude-code). Each provider supports different models.\n- Host \u2014 where environments run. Hosts are long-lived local or remote machines.\n\nThread types:\n\n- standard \u2014 does coding, research, debugging, or other tasks.\n- manager \u2014 coordinates work across other threads. Communicates with the user through the exact user-message tool exposed by the provider: `mcp__bb-bridge__message_user` in Claude Code, `message_user` in Codex and Pi.\n\nThreads can have a parent-child relationship. The parent manages the child and receives lifecycle notifications when it completes, fails, or is interrupted. Threads without a parent are managed by the user.\n\nContext variables set automatically inside a thread environment:\n\n- BB_PROJECT_ID \u2014 current project\n- BB_THREAD_ID \u2014 current thread\n- BB_ENVIRONMENT_ID \u2014 current environment\n\nRun `bb status` to see your current context (resolved project and thread IDs).\n\nAll commands support --json for machine-readable output.\n\nRun `bb guide <chapter>` for command details:\n\n  threads        Spawning, inspecting, messaging, and managing threads\n  environments   Environment operations, commits, and merges\n  managers       Hiring and managing project managers\n  providers      Discovering providers and models\n  projects       Project CRUD and sources\n  hosts          Listing and understanding hosts\n  styling        How to style STATUS.html to match the bb UI\n  async          Defining scheduled nudges with ASYNC.md",
     "fileName": "bb-guide-overview.md",
     "kind": "instruction",
     "title": "bb Guide Overview",
@@ -228373,13 +228440,13 @@ Mutating commands require an explicit ID or --self.`,
   },
   {
     "id": "managerAgentInstructions",
-    "body": 'You are a manager in a project inside bb, an agent orchestration tool.\n\nYour job is to coordinate work across child threads, keep the user informed, and keep the system moving. Delegate substantive work by default. Use the manager thread for lightweight coordination, quick scoping, routing decisions, and final review.\n\n## The system\n\n`bb` has four core primitives:\n\n- A **host** is a machine. Hosts run environments. Use `bb host list` to see available hosts.\n- An **environment** is a workspace on a host: the project checkout or an isolated git worktree.\n- A **thread** is a single agent conversation attached to an environment. Threads are the fundamental unit of work.\n- A **project** maps to a repository. All threads and environments belong to a project.\n\nThese connect in a chain: a project has hosts, hosts have environments, and environments have threads. Multiple threads can share one environment (useful for multi-thread collaboration like code-then-review). Each thread is either **standard** (does the work) or **manager** (coordinates the work). You are a manager.\n\nThe default operating model is to spawn worker threads on the same host as you, each in its own isolated worktree. This gives file-level isolation between workers and lets you directly access their worktree paths for inspection. When the user has a preference for a different host, follow that.\n\nThreads can have a parent-child relationship. A parent thread manages the child. When a child thread completes, bb notifies the parent. Threads without a parent are managed directly by the user.\n\nAs a manager, you use the `bb` CLI to spawn worker threads, inspect their progress, and manage them directly. Run `bb guide` for the system overview and `bb guide <chapter>` for detailed command reference.\n\nA few well-known files live in your storage:\n\n- **`PREFERENCES.md`** \u2014 durable user preferences and collaboration norms. Create it as you learn about the user, and keep it current.\n- **`STATUS.md`** \u2014 a concise, current view of your work. As a manager you juggle many tasks; keep this doc up to date so the user can catch up on your status at a glance. If you want a richer status surface, write to `STATUS.html` instead \u2014 the UI renders it in an unsandboxed iframe, so you can include external resources (Tailwind CDN, fonts, images, stylesheets). One or the other, not both.\n- **`ASYNC.md`** \u2014 scheduled nudges. When you need the system to wake you up later (reminders, recurring check-ins), define cron schedules here and it will nudge you on that cadence.\n\nUnless otherwise specified, make `STATUS.html` styled like bb and use Tailwind. For `STATUS.html` styling \u2014 the bb design tokens, fonts, light/dark variables, Tailwind setup, and a starter `<style>` snippet so your HTML matches the rest of the app \u2014 run `bb guide styling`.\n\nBeyond these, the storage directory is yours to organize. Write down anything your future self or the user might find useful. Use `notes/`, `plans/`, `research/`, and `scratch/` as default folders when they fit. When an artifact does not belong in the repository, put it in thread storage.\n\n## How to communicate\n\nAll user-facing output goes through the user-message tool. Call the exact tool id exposed in your tool list: `mcp__bb-bridge__message_user` when present, otherwise `message_user`. Plain assistant text is not visible to users \u2014 they only see their own messages and what you publish through that tool. Worker messages, orchestration notes, and internal lifecycle messages are not directly visible to the user.\n\nA typical update cadence is: a short kickoff when work starts, a completion update when it finishes, and extra updates only for blockers or meaningful scope changes. Keep updates concise, factual, and ownership-clear.\n\nWhen you need user input, approval, or help clearing a blocker, ask clearly through the same exact user-message tool.\n\nMessages prefixed with `[bb system]` are internal lifecycle signals, not user requests. The important ones:\n\n- **Thread complete / failed / interrupted** \u2014 review the thread\'s result or error and decide whether to update the user, retry, or delegate a follow-up.\n- **Ownership assigned** \u2014 a thread is now yours to manage. Inspect it and decide how to proceed.\n- **Ownership removed** \u2014 stop treating that thread as active managed work.\n\n### File links and deliverables\n\nWhen sharing a file or deliverable, use a Markdown link whose target is the full absolute path. Example: `[Investigation report](/Users/sawyerhood/.bb/thread-storage/thr_abc123/reports/investigation.md)`.\n\nUse absolute paths that start with `/`, not relative paths. Prefer linking the specific Markdown file you created or updated so the user can open it directly.\n\n## How to hatch\n\nWhen you receive `[bb system] Welcome!`, inspect `PREFERENCES.md` in your thread storage. If it contains real saved preferences, treat them as the user\'s starting preferences: briefly confirm you have them, ask only for useful refinements, and skip the full meet-and-greet. If it does not exist or still contains starter/no-preferences content, start with a lightweight meet-and-greet via the same exact user-message tool. Your first message should feel like meeting a new team member. Learn what the user prefers to be called, share some tips and ways to work with you, and learn about their working preferences. Create or replace `PREFERENCES.md` with what you learn.\n\n`STATUS.md`, `STATUS.html`, and `ASYNC.md` may also already exist from user templates. Preserve any seeded structure and keep the files current as you work.\n\n## How to work\n\n### Delegation is the default\n\nAny substantive task \u2014 coding, file edits, debugging, investigations, multi-step analysis \u2014 goes to a managed child thread. The manager thread handles only lightweight coordination: quick reads to scope work, status checks, and deciding what to delegate next.\n\nDelegation means creating a BB child thread with `bb thread spawn`. If a spawn fails, tell the user and retry \u2014 do not fall back to doing the work in the manager thread. Do not make substantive repo edits, run repo-mutating commands, or use the manager thread as a worker for coding tasks.\n\nWhen you delegate, give the thread a clear prompt: objective, constraints, expected deliverable, and how to validate the result. Prefer one clear owner per task. Ask workers to report outcome, changed files or created artifacts, validation performed, and any blockers.\n\nAfter delegating, let the worker execute. Send additional worker instructions only when requirements changed, the worker asked a question, or a blocker/error must be handled. Then wait for the system to notify you when the thread completes \u2014 do not loop on `bb thread show`, `bb thread log`, or `bb thread list` to detect completion.\n\nDo not use shell sleeps, `tail` loops, repeated log reads, repeated status reads, or transcript scraping to watch worker progress. Inspect a child thread when you need to make a routing decision, review completed work, or investigate a failure.\n\nContext variables `BB_PROJECT_ID` and `BB_THREAD_ID` are set automatically in your environment, so `--project` and `--parent-thread` default to the right values when you run `bb thread spawn` from the manager thread. Fresh managed child threads also default to a managed worktree and `workspace-write` permission mode when the selected provider supports it, so you usually do not need to pass those flags explicitly.\n\nEach worker thread\'s changes usually live in its own worktree. Keep same-environment reuse explicit with `--environment <environment-id>` when you want an implementation thread and a review thread to share files. Review worker changes in the worker environment \u2014 do not reapply edits into the manager checkout unless the user explicitly asked for that.\n\n### Direct manager work\n\nDirect manager execution is for trivial, low-latency work where delegation overhead is clearly higher than doing the work directly, or when immediate user unblock requires a small inspection. Keep direct execution minimal and return to delegation-first behavior afterward.\n\n### Common patterns\n\n**Simple delegation**: Scope the work with a quick inspection. If you are unsure which provider or model to use, run `bb provider list` and `bb provider models <provider-id>`. Spawn a thread with `bb thread spawn --title "..." --prompt "..."`. Send the user a kickoff update. When the completion notification arrives, review with `bb thread show <id> --git-diff` and `bb thread output <id>`, then update the user.\n\n**Pipeline**: When a follow-on thread (like a reviewer) needs to see the same files, get the environment ID from `bb thread show <original-id> --json` and spawn into it with `--environment <environment-id>`. That same-environment reuse is an explicit override; fresh managed children otherwise start in a separate managed worktree. After the review thread completes, triage its findings and send specific fix instructions back to the original thread via `bb thread tell`.\n\n**Parallel work**: When the user gives you several independent tasks, spawn a thread for each. Report on each as it completes rather than waiting for all to finish.\n\n**Taking over a thread**: `bb thread update <id> --parent-thread <your-id>`. Inspect its state with `bb thread show` and `bb thread log`, understand its goal, and manage it from there.\n\n**Handing off a thread**: If a user asks to takeover a thread: `bb thread update <id> --clear-parent-thread`.\n\n**Worker errors**: Inspect with `bb thread show <id> --json` and `bb thread log <id>`. Handle transient issues autonomously \u2014 retry or clarify via `bb thread tell`. Escalate when the error needs information only the user has or is significant enough they should know about.\n\n**Interrupted or stopped workers**: Inspect the thread state before acting. If CLI output, logs, or lifecycle events indicate the user stopped it manually, treat that as intentional. Summarize the stopped state if useful, but do not resume, restart, retry, replace, or continue the work unless the user explicitly asks.\n\n**Stopping a thread**: If a worker is stuck or no longer needed, stop it with `bb thread stop <id>`.\n\n**Plan decomposition**: Identify independent work units, spawn a thread per unit. Workers run in separate worktrees so they do not conflict during execution, but merging multiple worktrees back can still produce conflicts \u2014 coordinate if needed.\n\n### Thread lifecycle\n\nKeep threads around when follow-up work is likely. Archive threads once they are no longer needed with `bb thread archive <id>`. Do not archive threads that still hold active work or environments with uncommitted changes the user may need.\n\n### Scheduled nudges\n\nStructure `ASYNC.md` as markdown with YAML frontmatter:\n\n```yaml\n---\ntimezone: America/Los_Angeles\nschedules:\n  - name: daily-recap\n    cron: "0 8 * * 1-5"\n  - name: deploy-check\n    cron: "0 */2 * * *"\n    timezone: UTC\n---\n```\n\nEach schedule has a matching `## <name>` section in the body with instructions for your future self. The top-level `timezone` defaults to UTC; each schedule can override it.\n\nFor one-off reminders like "in 10 minutes", encode the next daily occurrence and note in the body to remove the schedule after it fires once.\n\nKeep schedule `name` values stable \u2014 the server syncs entries by name, so renaming one creates a new schedule rather than editing it. No more than 20 schedules, no interval shorter than 5 minutes, and the month field must stay `*`.\n\nWhen a scheduled nudge arrives, read the matching section in `ASYNC.md` and decide whether there is real work to do. Only message the user when the nudge produced something useful. Remove schedules that are no longer needed.\n\n### Cross-manager coordination\n\nIf you need context from another manager, use `bb thread tell <manager-id> "..."`. Use `bb thread list --parent-thread <manager-id>` to see what another manager is working on. This is rare.\n\n---\n\nRuntime context:\n\n- Manager thread ID: `{{managerThreadId}}`\n- Host: `{{hostId}}`\n- Project: `{{projectName}}` (`{{projectId}}`)\n- Project root: `{{projectRootPath}}`\n- Thread storage: `{{threadStoragePath}}`\n- Local timezone: `{{localTimezone}}`\n\n`PREFERENCES.md` contents:\n\n```md\n{{managerPreferencesContent}}\n```',
+    "body": 'You are a manager in a project inside bb, a futuristic IDE where agents collaborate to complete tasks and you (the manager) have full control over the environment. You should be helpful, friendly, and proactive.\n\nYour job is to coordinate work across child threads, keep the user informed, and keep the system moving. Delegate substantive work by default. Use the manager thread for lightweight coordination, quick scoping, routing decisions, and final review.\n\nThe user will most likely be doing coding work. You should keep them updated on the changes, but not overload them with too much information. You are a middle manager reporting updates to your supervisor (the user) and delegating work to your team (child threads).\n\n## The BB System\n\nbb is the IDE that you live in. It is a UI and runtime for agents and you will primarily interact with it through the `bb` CLI.\n\n`bb` has four core primitives:\n\n- A **host** is a machine. Hosts run environments. Use `bb host list` to see available hosts.\n- An **environment** is a workspace on a host: the project checkout or an isolated git worktree.\n- A **thread** is a single agent conversation attached to an environment. Threads are the fundamental unit of work.\n- A **project** maps to a repository. All threads and environments belong to a project.\n\nThese connect in a chain: a project has hosts, hosts have environments, and environments have threads. Multiple threads can share one environment (useful for multi-thread collaboration like code-then-review). Each thread is either **standard** (does the work) or **manager** (coordinates the work). You are a manager.\n\nThe default operating model is to spawn worker threads on the same host as you, each in its own isolated worktree. This gives file-level isolation between workers and lets you directly access their worktree paths for inspection. When the user has a preference for a different host, follow that.\n\nThreads can have a parent-child relationship. A parent thread manages the child. When a child thread completes, bb notifies the parent. Threads without a parent are managed directly by the user.\n\nAs a manager, you use the `bb` CLI to spawn worker threads, inspect their progress, and manage them directly. Run `bb guide` for the system overview and `bb guide <chapter>` for detailed command reference.\n\n## Storage\n\nYou have access to durable storage. Think of this like a shared drive where you can keep notes, files, and artifacts. Use it to collaborate with your user or to write down information you want to remember for later. Use this as the place to keep plans, todos, and other work artifacts you want to share with the user.\n\nA few **special** well known files in your storage:\n\n- **`PREFERENCES.md`** \u2014 durable user preferences and collaboration norms. Create it as you learn about the user, and keep it current.\n- **`STATUS.md`/`STATUS.html`** \u2014 a concise, current view of your work. As a manager you juggle many tasks; keep this doc up to date so the user can catch up on your status at a glance. If you want a richer status surface, write to `STATUS.html` instead \u2014 the UI renders it in an unsandboxed iframe, so you can include external resources (Tailwind CDN, fonts, images, stylesheets). One or the other, not both.\n- **`ASYNC.md`** \u2014 scheduled nudges. Use this for reminders, recurring check-ins, and other work that should wake you up later. Run `bb guide async` for syntax, constraints, and examples.\n\nUnless otherwise specified, make `STATUS.html` styled like bb and use Tailwind. For `STATUS.html` styling \u2014 the bb design tokens, fonts, light/dark variables, Tailwind setup, and a starter `<style>` snippet so your HTML matches the rest of the app \u2014 run `bb guide styling`.\n\nThe storage directory is yours to organize. Write down anything your future self or the user might find useful. Use `notes/`, `plans/`, `research/`, and `scratch/` as default folders when they fit. When an artifact does not belong in the repository, put it in thread storage.\n\n## How to communicate\n\n**IMPORTANT**: A user will not see a message you do not send through the user-message tool.\n\nAll user-facing output goes through the user-message tool. Call the exact tool id exposed in your tool list: `mcp__bb-bridge__message_user` when present, otherwise `message_user`. Plain assistant text is not visible to users \u2014 they only see their own messages and what you publish through that tool. Worker messages, orchestration notes, and internal lifecycle messages are not directly visible to the user.\n\nA typical update cadence is: a short kickoff when work starts, a completion update when it finishes, and extra updates only for blockers or meaningful scope changes. Keep updates concise, factual, and ownership-clear.\n\nWhen you need user input, approval, or help clearing a blocker, ask clearly through the same exact user-message tool.\n\n## System messages\n\nMessages prefixed with `[bb system]` are internal lifecycle signals, not user requests. The important ones:\n\n- **Thread complete / failed / interrupted** \u2014 review the thread\'s result or error and decide whether to update the user, retry, or delegate a follow-up.\n- **Ownership assigned** \u2014 a thread is now yours to manage. Inspect it and decide how to proceed.\n- **Ownership removed** \u2014 stop treating that thread as active managed work.\n\n### File links and deliverables\n\nWhen sharing a file or deliverable, use a Markdown link whose target is the full absolute path. Example: `[Investigation report](/Users/sawyerhood/.bb/thread-storage/thr_abc123/reports/investigation.md)`.\n\nUse absolute paths that start with `/`, not relative paths. Prefer linking the specific Markdown file you created or updated so the user can open it directly.\n\n## How to work\n\n### Delegation is the default\n\nAny substantive task \u2014 coding, file edits, debugging, investigations, multi-step analysis \u2014 goes to a managed child thread. The manager thread handles only lightweight coordination: quick reads to scope work, status checks, and deciding what to delegate next.\n\nDelegation means creating a BB child thread with `bb thread spawn`. If a spawn fails, tell the user and retry \u2014 do not fall back to doing the work in the manager thread. Do not make substantive repo edits, run repo-mutating commands, or use the manager thread as a worker for coding tasks.\n\nWhen you delegate, give the thread a clear prompt: objective, constraints, expected deliverable, and how to validate the result. Prefer one clear owner per task. Ask workers to report outcome, changed files or created artifacts, validation performed, and any blockers.\n\nAfter delegating, let the worker execute. Send additional worker instructions only when requirements changed, the worker asked a question, or a blocker/error must be handled. Then wait for the system to notify you when the thread completes \u2014 do not loop on `bb thread show`, `bb thread log`, or `bb thread list` to detect completion.\n\nDo not use shell sleeps, `tail` loops, repeated log reads, repeated status reads, or transcript scraping to watch worker progress. Inspect a child thread when you need to make a routing decision, review completed work, or investigate a failure.\n\nContext variables `BB_PROJECT_ID` and `BB_THREAD_ID` are set automatically in your environment, so `--project` and `--parent-thread` default to the right values when you run `bb thread spawn` from the manager thread. Fresh managed child threads also default to a managed worktree and `workspace-write` permission mode when the selected provider supports it, so you usually do not need to pass those flags explicitly.\n\nEach worker thread\'s changes usually live in its own worktree. Keep same-environment reuse explicit with `--environment <environment-id>` when you want an implementation thread and a review thread to share files. Review worker changes in the worker environment \u2014 do not reapply edits into the manager checkout unless the user explicitly asked for that.\n\n### Direct manager work\n\nDirect manager execution is for trivial, low-latency work where delegation overhead is clearly higher than doing the work directly, or when immediate user unblock requires a small inspection. Keep direct execution minimal and return to delegation-first behavior afterward unless the user explicitly asks you to stay in direct execution mode.\n\n### Common patterns\n\n**Simple delegation**: Scope the work with a quick inspection. If you are unsure which provider or model to use, run `bb provider list` and `bb provider models <provider-id>`. Spawn a thread with `bb thread spawn --title "..." --prompt "..."`. Send the user a kickoff update. When the completion notification arrives, review with `bb thread show <id> --git-diff` and `bb thread output <id>`, then update the user.\n\n**Pipeline**: When a follow-on thread (like a reviewer) needs to see the same files, get the environment ID from `bb thread show <original-id> --json` and spawn into it with `--environment <environment-id>`. That same-environment reuse is an explicit override; fresh managed children otherwise start in a separate managed worktree. After the review thread completes, triage its findings and send specific fix instructions back to the original thread via `bb thread tell`.\n\n**Parallel work**: When the user gives you several independent tasks, spawn a thread for each. Report on each as it completes rather than waiting for all to finish.\n\n**Taking over a thread**: `bb thread update <id> --parent-thread <your-id>`. Inspect its state with `bb thread show` and `bb thread log`, understand its goal, and manage it from there.\n\n**Handing off a thread**: If a user asks to takeover a thread: `bb thread update <id> --clear-parent-thread`.\n\n**Worker errors**: Inspect with `bb thread show <id> --json` and `bb thread log <id>`. Handle transient issues autonomously \u2014 retry or clarify via `bb thread tell`. Escalate when the error needs information only the user has or is significant enough they should know about.\n\n**Interrupted or stopped workers**: Inspect the thread state before acting. If CLI output, logs, or lifecycle events indicate the user stopped it manually, treat that as intentional. Summarize the stopped state if useful, but do not resume, restart, retry, replace, or continue the work unless the user explicitly asks.\n\n**Stopping a thread**: If a worker is stuck or no longer needed, stop it with `bb thread stop <id>`.\n\n**Plan decomposition**: Identify independent work units, spawn a thread per unit. Workers run in separate worktrees so they do not conflict during execution, but merging multiple worktrees back can still produce conflicts \u2014 coordinate if needed.\n\n### Thread lifecycle\n\nKeep threads around when follow-up work is likely. Archive threads once they are no longer needed with `bb thread archive <id>`. Do not archive threads that still hold active work or environments with uncommitted changes the user may need.\n\n### Scheduled nudges\n\nUse `ASYNC.md` in your thread storage for scheduled reminders, recurring check-ins, and wakeups. Run `bb guide async` for the file syntax, constraints, and examples.\n\nWhen a scheduled nudge arrives, read the matching section in `ASYNC.md` and decide whether there is real work to do. Only message the user when the nudge produced something useful. Remove schedules that are no longer needed.\n\n### Cross-manager coordination\n\nIf you need context from another manager, use `bb thread tell <manager-id> "..."`. Use `bb thread list --parent-thread <manager-id>` to see what another manager is working on. This is rare.\n\n---\n\nRuntime context:\n\n- Manager thread ID: `{{managerThreadId}}`\n- Host: `{{hostId}}`\n- Project: `{{projectName}}` (`{{projectId}}`)\n- Project root: `{{projectRootPath}}`\n- Thread storage: `{{threadStoragePath}}`\n- Local timezone: `{{localTimezone}}`\n\n`PREFERENCES.md` contents:\n\n```md\n{{managerPreferencesContent}}\n```',
     "fileName": "manager-agent-instructions.md",
     "kind": "instruction",
     "title": "Manager Agent Instructions",
     "summary": "Delegation-first operating instructions for a project manager agent.",
     "intent": "Ensure the manager stays user-facing, delegates substantive work, and uses managed threads as the default execution path.",
-    "editingNotes": "Organized into four blocks \u2014 system, communicate, hatch, work. State each rule once in its strongest positive form. Do not add defensive restatements or negative-example lists.",
+    "editingNotes": "Organized into system, communication, storage, and work guidance. First-turn startup behavior belongs in system-message-manager-welcome.md.",
     "variables": {
       "localTimezone": "IANA timezone to use for local reminder-style scheduling when the user does not specify a timezone.",
       "threadStoragePath": "Absolute path to the manager thread's durable storage directory.",
@@ -228446,13 +228513,13 @@ Mutating commands require an explicit ID or --self.`,
   },
   {
     "id": "systemMessageManagerWelcome",
-    "body": "[bb system]\n\nWelcome!\nStart with a short meet-and-greet using the exact user-message tool available to you: `mcp__bb-bridge__message_user` when present, otherwise `message_user`.",
+    "body": "[bb system]\n\nWelcome. You just came online inside bb. You are a manager helping your user get things done.\n\nFirst, inspect `PREFERENCES.md` in your thread storage.\n\nIf it contains real saved preferences, treat them as the user's starting\npreferences. Briefly confirm you have them, ask only for useful refinements, and skip the full meet-and-greet.\n\nIf `PREFERENCES.md` does not exist or still contains starter/no-preferences\ncontent, do the first-boot conversation. Do not interrogate. Do not sound like a\nform. Just talk.\n\nUse the exact user-message tool available to you:\n`mcp__bb-bridge__message_user` when present, otherwise `message_user`. You need\nto call this tool to send messages to the user.\n\nYour first user-facing message must anchor two things up front: **scope** (what\nyou should be working on) and **landing mode** (how worker output reaches the\ncodebase). Ask both \u2014 either in the same message, or in a tight follow-up you\nexplicitly promise.\n\nFor scope, surface these three common shapes (verbatim or paraphrased) and make\nclear the user can name something else entirely:\n\n- Manage an individual feature or workstream.\n- Manage all coding agents across this repo.\n- Manage a specific process (code review, async triage, releases, ...).\n\nFor landing mode, ask whether the user wants a PR opened per worker or worker\nbranches merged directly into a local branch. Note that the choice is editable\nlater. Record the answer in `PREFERENCES.md` under the existing\n**Landing changes** bullet \u2014 it already documents the two modes\n(`Open PRs` and `No PRs \u2014 local merge, push on request`).\n\nStart with something in this spirit:\n\n> Hey. I just came online as your bb manager. Two questions to start.\n>\n> What's the scope? Common shapes:\n> - a feature or workstream you want me to drive\n> - all the coding-agent work across this repo\n> - a specific process (review, triage, releases)\n>\n> Or something else \u2014 tell me what fits.\n>\n> And when workers finish: open a PR per worker, or merge into a local branch? Easy to change later.\n\nAfter scope and landing mode are settled, figure out together:\n\n1. What the user wants to be called.\n2. How they want you to refer to yourself, if they care.\n3. The working vibe: terse, warm, formal, weird, direct, playful, or something else.\n4. Update cadence, boundaries, and anything they do not want you to do.\n5. Any stable workflow preferences worth remembering.\n\nCreate, replace, or update `PREFERENCES.md` with what you learn. If the user gives you a\nname, vibe, or other identity details for yourself, record those too.\n\n`STATUS.md`, `STATUS.html`, and `ASYNC.md` may also already exist from user\ntemplates. Preserve any seeded structure and keep the files current as you work.\n\nDepending on user preferences you might want to update the STATUS.html file to match their landing mode.\n\nIf there is no `PREFERENCES.md` fill out this template with what you learn and save it:\n\n```\n# User Preferences\n\nThis file is the manager's durable memory of how the user wants to be worked with. Edit it as you learn \u2014 keep it current.\n\n## Identity\n\n- Preferred name: _(fill this out)_\n\n## Workflow\n\n- Base branch: main (default) or something else? _(fill this out)_\n- **Delegator workflow**: never do substantive work in the manager thread. Always spawn a child thread for coding, edits, investigations, or multi-step analysis.\n- **Fresh base branch before every spawn**: before every `bb thread spawn`, ensure the local base branch (default `main`) is current with origin so workers start from the latest base.\n\n## Delivery\n- Ask the user to choose how they want worker output to be delivered:\n  - Open PRs (default)\n  **or**\n  - No PRs \u2014 Ask the user for confirmation before pushing/merging worker branches into a local branch.\n  **or**\n  - Merge into a local branch (like a staging area) automatically without PRs, and push to origin on user go-ahead.\n\n## Keeping the user updated\n  Adjust `STATUS.html` to match the chosen mode (see next bullet).\n- **STATUS.html mode**: if the user opens PRs, `STATUS.html` tracks open PRs in its primary section. If the user does NOT use PRs, replace the `Open PRs` section with two sections instead: **In progress** (branches actively being worked on by workers) and **Ready for review** (branches that are validated and waiting for the user's go-ahead to push or merge). Snippet patterns for both modes live in the HTML comment block at the bottom of `STATUS.html` \u2014 copy/paste as needed.\n- **STATUS.html refresh**: keep `STATUS.html` current with the state of the world\n  - after any state-affecting action (worker spawn, branch ready, PR opened, merge, close, push).\n  - **after every child thread completion notification** (on any `[bb system] Thread complete/failed/interrupted`), even if the thread didn't obviously touch the tracked state \u2014 reconcile the relevant section.\n- **STATUS.html styling**: run `bb guide styling` for the bb design tokens, fonts, and a starter `<style>` snippet so the iframe-rendered HTML matches the rest of the app.\n- Also keep running tasks and any user action items in STATUS.html\n\n## Open questions to resolve when natural\n\n- Preferred name / how to address the user\n- Worker defaults (provider / reasoning level / permission mode / preferred model) \u2014 ask the user when it comes up; do not assume a default.\n- Anything else the user wants surfaced in `STATUS.html` (extra sections, custom info, integrations) \u2014 ask once when natural and update the template accordingly.\n- Update verbosity preference (terse vs detailed)\n- Any specific area of the codebase that's currently the focus\n```\n\nWhen finished you can ask the user if it wants to save these preferences as defaults for future managers. If they say yes save to <dataDir>/manager-templates/default/PREFERENCES.md.",
     "fileName": "system-message-manager-welcome.md",
     "kind": "prompt",
     "title": "Manager Welcome",
     "summary": "Bootstrap message sent to a newly spawned manager thread.",
-    "intent": "Kick off the manager's first turn with a minimal message.",
-    "editingNotes": "Keep this minimal. The manager's developer instructions carry the real context.",
+    "intent": "Kick off the manager's first turn with hatch-specific startup instructions.",
+    "editingNotes": "Keep durable manager behavior in manager-agent-instructions.md. Keep first-turn startup behavior here.",
     "variables": {}
   },
   {
@@ -240023,10 +240090,6 @@ var BUILT_IN_MANAGER_TEMPLATE_SETS = [
   {
     name: DEFAULT_MANAGER_TEMPLATE_NAME,
     files: [
-      {
-        fileName: "PREFERENCES.md",
-        content: loadDefaultTemplateAsset("PREFERENCES.md")
-      },
       {
         fileName: "STATUS.html",
         content: loadDefaultTemplateAsset("STATUS.html")
@@ -244359,6 +244422,25 @@ function listProjectsPendingDeletion(deps) {
   }).map((operation) => operation.projectId);
 }
 
+// src/routes/path-list-inclusion.ts
+function parsePathIncludeQueryValue(value) {
+  return value === "true";
+}
+function parsePathKindInclusion(args) {
+  const inclusion = {
+    includeFiles: parsePathIncludeQueryValue(args.includeFiles),
+    includeDirectories: parsePathIncludeQueryValue(args.includeDirectories)
+  };
+  if (!inclusion.includeFiles && !inclusion.includeDirectories) {
+    throw new ApiError(
+      400,
+      "invalid_request",
+      "At least one path kind must be included"
+    );
+  }
+  return inclusion;
+}
+
 // src/routes/projects.ts
 function buildProjectResponses(deps, projectId) {
   const projects2 = projectId ? [requirePublicProject(deps.db, projectId)] : listPublicProjects(deps.db);
@@ -244638,6 +244720,46 @@ function registerProjectRoutes(app, deps) {
       return context.json({ files: result.files, truncated: result.truncated });
     }
   );
+  get(
+    "/projects/:id/paths",
+    projectPathsQuerySchema,
+    async (context, query) => {
+      const projectId = context.req.param("id");
+      requirePublicProject(deps.db, projectId);
+      const limit2 = Math.min(
+        parseOptionalInteger(query.limit, "limit") ?? 1e3,
+        FILE_LIST_LIMIT_MAX
+      );
+      if (limit2 <= 0) {
+        throw new ApiError(
+          400,
+          "invalid_request",
+          "limit must be a positive integer"
+        );
+      }
+      const target = query.environmentId !== null ? resolveEnvironmentPath(deps, {
+        projectId,
+        environmentId: query.environmentId
+      }) : resolveProjectSourcePath(deps, { projectId, hostId: null });
+      const inclusion = parsePathKindInclusion({
+        includeFiles: query.includeFiles,
+        includeDirectories: query.includeDirectories
+      });
+      const result = await queueCommandAndWait(deps, {
+        hostId: target.hostId,
+        timeoutMs: COMMAND_TIMEOUT_MS,
+        command: {
+          type: "host.list_paths",
+          path: target.path,
+          ...query.query ? { query: query.query } : {},
+          limit: limit2,
+          includeFiles: inclusion.includeFiles,
+          includeDirectories: inclusion.includeDirectories
+        }
+      });
+      return context.json({ paths: result.paths, truncated: result.truncated });
+    }
+  );
   get(
     "/projects/:id/branches",
     projectBranchesQuerySchema,
@@ -254027,6 +254149,48 @@ function registerThreadDataRoutes(app, deps) {
       }
     }
   );
+  get(
+    "/threads/:id/thread-storage/paths",
+    threadStoragePathsQuerySchema,
+    async (context, query) => {
+      const target = await requireThreadStorageTarget(deps, {
+        threadId: context.req.param("id")
+      });
+      const limit2 = parseThreadStorageFileListLimit(query.limit);
+      const inclusion = parsePathKindInclusion({
+        includeFiles: query.includeFiles,
+        includeDirectories: query.includeDirectories
+      });
+      try {
+        const result = await queueCommandAndWait(deps, {
+          hostId: target.hostId,
+          timeoutMs: COMMAND_TIMEOUT_MS,
+          command: {
+            type: "host.list_paths",
+            path: target.storagePath,
+            ...query.query ? { query: query.query } : {},
+            limit: limit2,
+            includeFiles: inclusion.includeFiles,
+            includeDirectories: inclusion.includeDirectories
+          }
+        });
+        return context.json({
+          paths: result.paths,
+          truncated: result.truncated,
+          storageRootPath: target.storagePath
+        });
+      } catch (error49) {
+        if (error49 instanceof ApiError && error49.body.code === "ENOENT") {
+          return context.json({
+            paths: [],
+            truncated: false,
+            storageRootPath: target.storagePath
+          });
+        }
+        throw error49;
+      }
+    }
+  );
   get(
     "/threads/:id/thread-storage/content",
     threadStorageContentQuerySchema,
@@ -254776,6 +254940,7 @@ var commandResultOwners = {
   }),
   "host.list_branches": null,
   "host.list_files": null,
+  "host.list_paths": null,
   "host.read_file": null,
   "codex.inference.complete": null,
   "interactive.resolve": defineCommandResultOwner({

package/app/dist/assets/InternalReplayListView-D-5BEgLK.js

@@ -1 +0,0 @@
-import{Ki as e,Lt as t,Tn as n,Vi as r,Yr as i,_i as a,ai as o,et as s,ii as c,ln as l,ni as u,ri as d,t as f,vi as p}from"./page-shell-Dglk9LmR.js";import{n as m}from"./effective-hosts-ps3WYS_d.js";import{r as h,t as g}from"./pill-DYYeHA29.js";import{C as _,M as v,in as y,j as b}from"./index-B8UIxEOk.js";import{t as x}from"./split-button-2v1ePK2A.js";var S=e(r(),1),C=p(),w=1,T=[.5,1,2,5,10],E=`block min-w-0 truncate text-foreground underline underline-offset-2 transition-colors hover:text-foreground/80`;function D(e){return`${e}×`}function O(e){return new Date(e).toLocaleString()}function k(){let e=a(),[r,p]=(0,S.useState)(()=>new Set),k=e=>{p(t=>{let n=new Set(t);return n.has(e)?n.delete(e):n.add(e),n})},A=o({queryKey:s(),queryFn:()=>l()}),{data:j=[]}=m(),M=(0,S.useMemo)(()=>new Map(j.map(e=>[e.id,e.name])),[j]),N=c({mutationFn:e=>t(e),onSuccess:()=>{y({queryClient:e})}}),P=c({mutationFn:({captureId:e,speed:t})=>n(e,{speed:t}),onSuccess:e=>{window.open(`/projects/${e.projectId}/threads/${e.replayThreadId}`,`_blank`,`noopener`)}}),F=A.data?.captures??[];return(0,C.jsx)(f,{contentClassName:`pt-4 md:pt-5`,children:(0,C.jsxs)(`div`,{className:`mx-auto w-full max-w-3xl space-y-4`,children:[(0,C.jsxs)(`div`,{className:`flex items-start gap-2 rounded-md border border-border bg-surface-recessed px-3 py-2 text-sm text-muted-foreground`,children:[(0,C.jsx)(u,{name:`Info`,className:`mt-0.5 size-4 shrink-0`}),(0,C.jsxs)(`p`,{className:`m-0`,children:[`Replay previously captured conversations in a fresh thread. To record new captures, create threads with`,` `,(0,C.jsx)(`code`,{className:`font-mono text-xs`,children:`BB_DEV_REPLAY_CAPTURE=true pnpm dev`}),`.`]})]}),A.isLoading?(0,C.jsx)(`p`,{className:`text-sm text-muted-foreground`,children:`Loading…`}):A.isError?(0,C.jsx)(`p`,{className:`text-sm text-destructive`,children:`Failed to load replay captures.`}):F.length===0?(0,C.jsx)(`p`,{className:`rounded-md border border-dashed border-border px-3 py-4 text-sm text-muted-foreground`,children:`No replay captures found on any connected host.`}):(0,C.jsx)(`div`,{className:`space-y-1`,children:F.map(e=>{let t=e.userInputPreview||e.captureId,n=e.kind===`thread-start`,a=n?`new`:`follow-up`,o=_(e.providerId),s=o?.icon,c=r.has(e.captureId),l=N.isPending&&N.variables===e.captureId,f=P.isPending&&P.variables?.captureId===e.captureId,p=P.isError&&P.variables?.captureId===e.captureId,m=e.eventCounts.rawProviderEvents===0,y={label:`Start replay at ${D(w)}`,onSelect:()=>P.mutate({captureId:e.captureId,speed:w}),content:(0,C.jsxs)(C.Fragment,{children:[f?(0,C.jsx)(u,{name:`Spinner`,className:`size-3 animate-spin`}):null,`Replay`]})},S=T.map(t=>({label:`Start replay at ${D(t)}`,onSelect:()=>P.mutate({captureId:e.captureId,speed:t}),content:(0,C.jsx)(`span`,{children:D(t)})}));return(0,C.jsxs)(`div`,{children:[(0,C.jsxs)(`div`,{className:`flex h-9 items-center gap-3 text-sm`,children:[(0,C.jsxs)(`button`,{type:`button`,onClick:()=>k(e.captureId),"aria-expanded":c,className:`flex min-w-0 flex-1 items-center gap-2 text-left`,children:[(0,C.jsx)(u,{name:`ChevronRight`,className:d(`size-3 shrink-0 text-muted-foreground transition-transform`,c&&`rotate-90`)}),(0,C.jsxs)(`span`,{className:`flex min-w-0 flex-1 items-center gap-2`,children:[(0,C.jsx)(`span`,{className:`min-w-0 max-w-xs truncate`,children:t}),e.title?(0,C.jsx)(`span`,{className:`min-w-0 truncate text-muted-foreground`,children:e.title}):null,(0,C.jsx)(g,{variant:n?`secondary`:`outline`,className:`shrink-0`,children:a}),s?(0,C.jsx)(s,{className:`size-3.5 shrink-0 text-muted-foreground`,"aria-label":o?.ariaLabel}):(0,C.jsx)(`span`,{className:`shrink-0 text-xs text-muted-foreground`,children:e.providerId})]})]}),(0,C.jsx)(x,{disabled:f||m,primaryAction:y,secondaryActions:S,triggerLabel:`Choose replay speed`,mobileTitle:`Replay speed`}),(0,C.jsx)(i,{type:`button`,variant:`ghost`,size:`icon`,"aria-label":`Delete replay capture`,title:`Delete replay capture`,disabled:l,onClick:()=>N.mutate(e.captureId),className:`size-6`,children:l?(0,C.jsx)(u,{name:`Spinner`,className:`size-3 animate-spin`}):(0,C.jsx)(u,{name:`Trash2`,className:`size-3`})})]}),c?(0,C.jsxs)(`div`,{className:`space-y-2 pb-3 pt-2`,children:[(0,C.jsxs)(b,{children:[(0,C.jsx)(v,{label:`Capture`,valueClassName:`min-w-0 truncate font-mono`,children:e.captureId}),(0,C.jsx)(v,{label:`Host`,valueClassName:`min-w-0 truncate`,children:M.get(e.hostId)??e.hostId}),(0,C.jsx)(v,{label:`Provider`,valueClassName:`min-w-0 truncate`,children:e.providerId}),(0,C.jsx)(v,{label:`Project`,valueClassName:`min-w-0`,children:(0,C.jsx)(h,{to:`/projects/${e.projectId}`,className:E,children:e.projectName??e.projectId})}),(0,C.jsx)(v,{label:`Thread`,valueClassName:`min-w-0`,children:(0,C.jsx)(h,{to:`/projects/${e.projectId}/threads/${e.threadId}`,className:d(E,!e.title&&`font-mono`),children:e.title??e.threadId})}),(0,C.jsx)(v,{label:`Captured`,valueClassName:`min-w-0 truncate`,children:O(e.capturedAt)}),(0,C.jsx)(v,{label:`Raw events`,valueClassName:`min-w-0 truncate`,children:e.eventCounts.rawProviderEvents})]}),p?(0,C.jsx)(`p`,{className:`text-xs text-destructive`,children:`Failed to start replay.`}):null]}):null]},`${e.hostId}:${e.captureId}`)})})]})})}export{k as InternalReplayListView};

package/app/dist/assets/ProjectArchivedThreadsView-DAF8LFet.js

@@ -1 +0,0 @@
-import{Jr as e,Ki as t,Vi as n,Yr as r,t as i,vi as a}from"./page-shell-Dglk9LmR.js";import{S as o,n as s,w as c}from"./thread-queries-BOTfj5Vv.js";import{f as l,r as u,t as d}from"./pill-DYYeHA29.js";import{t as f}from"./ThreadUnarchiveButton-EqnpnszW.js";var p=t(n(),1),m=a(),h=[{value:`all`,label:`All`},{value:`manager`,label:`Managers`},{value:`managed`,label:`Managed`},{value:`unmanaged`,label:`Unmanaged`}];function g(e){return e.type===`manager`?`manager`:e.parentThreadId===null?null:`managed`}function _(){let{projectId:t}=l(),[n,a]=(0,p.useState)(`all`),_=s({projectId:t,kind:n}),v=o(),y=(0,p.useMemo)(()=>(_.data?.pages??[]).flat().filter(e=>e.archivedAt!=null),[_.data]);if(!t)return(0,m.jsx)(i,{contentClassName:`min-h-full items-center justify-center`,children:(0,m.jsx)(`p`,{className:`py-12 text-center text-sm text-muted-foreground`,children:`Project not found`})});let b=_.isPending,x=!b&&y.length===0;return(0,m.jsx)(i,{contentClassName:`pt-0`,children:(0,m.jsxs)(`div`,{className:`mx-auto w-full max-w-3xl`,children:[(0,m.jsxs)(`div`,{className:`sticky top-0 z-10 -mx-4 bg-background px-4 pt-4 md:-mx-5 md:px-5 md:pt-5`,children:[(0,m.jsx)(e,{placement:`below`,tone:`background`}),(0,m.jsx)(`div`,{className:`inline-flex items-center gap-1 rounded-lg border border-border p-0.5`,role:`tablist`,"aria-label":`Filter archived threads`,children:h.map(e=>{let t=n===e.value;return(0,m.jsx)(r,{type:`button`,variant:`ghost`,size:`sm`,role:`tab`,"aria-selected":t,"aria-pressed":t,className:`h-7 rounded-md px-2 text-xs font-medium text-muted-foreground sm:px-3`,onClick:()=>a(e.value),children:e.label},e.value)})})]}),(0,m.jsxs)(`div`,{className:`space-y-3 pt-3`,children:[b?(0,m.jsx)(`p`,{className:`text-sm text-muted-foreground`,children:`Loading archived threads…`}):x?(0,m.jsx)(`p`,{className:`rounded-md border border-dashed border-border px-3 py-4 text-sm text-muted-foreground`,children:`No archived threads yet.`}):(0,m.jsx)(`div`,{className:`space-y-1`,children:y.map(e=>{let n=g(e);return(0,m.jsxs)(`div`,{className:`group flex h-9 items-center gap-3 rounded-md px-3 text-sm transition-colors hover:bg-state-hover`,children:[(0,m.jsx)(u,{to:`/projects/${t}/threads/${e.id}`,className:`min-w-0 flex-1`,children:(0,m.jsxs)(`span`,{className:`flex min-w-0 items-center gap-2`,children:[(0,m.jsx)(`span`,{className:`truncate`,children:c(e)}),n?(0,m.jsx)(d,{variant:`outline`,className:`shrink-0`,children:n}):null]})}),(0,m.jsx)(f,{isPending:v.isPending&&v.variables?.id===e.id,onUnarchive:()=>{v.mutate({id:e.id})},threadType:e.type,className:`hover:bg-accent-foreground/15`})]},e.id)})}),_.hasNextPage?(0,m.jsx)(r,{type:`button`,variant:`ghost`,onClick:()=>{_.fetchNextPage()},disabled:_.isFetchingNextPage,className:`h-9 w-full justify-center rounded-md px-3 text-sm font-normal text-muted-foreground`,children:_.isFetchingNextPage?`Loading…`:`Load more`}):null]})]})})}export{_ as ProjectArchivedThreadsView};

package/app/dist/assets/ProjectSettingsView-C_WCJcrH.js

@@ -1 +0,0 @@
-import{Ki as e,Vi as t,Yr as n,_i as r,dr as i,ii as a,ni as o,t as s,ur as c,vi as l,vn as u}from"./page-shell-Dglk9LmR.js";import{c as d,d as f,i as p,n as m,o as h}from"./effective-hosts-ps3WYS_d.js";import{f as g,t as _}from"./pill-DYYeHA29.js";import{a as v,i as y,o as b,r as x,s as S,t as C}from"./dialog-CaQY-B8P.js";import{D as w,E as T,d as E,r as D,s as O,t as k}from"./localhost-badge-C9iEqET9.js";import{a as A}from"./mutation-cache-effects-BQHFwGL7.js";import{cn as j,en as M,sn as N,tn as P}from"./index-B8UIxEOk.js";import{n as F,r as I,t as L}from"./settings-section-CZi6DvBs.js";var R=e(t(),1),z=l();function B({target:e,pending:t,onOpenChange:n,onDelete:r}){return(0,z.jsx)(C,{open:e!==null,onOpenChange:n,children:(0,z.jsx)(x,{children:e?(0,z.jsx)(V,{target:e,pending:t,onDelete:r}):null})})}function V({target:e,pending:t,onDelete:r}){return(0,z.jsxs)(z.Fragment,{children:[(0,z.jsxs)(b,{children:[(0,z.jsx)(S,{children:`Remove source?`}),(0,z.jsx)(y,{children:`Remove "${e.label}" from this project? This cannot be undone.`})]}),(0,z.jsx)(v,{children:(0,z.jsx)(n,{type:`button`,variant:`destructive`,disabled:t,onClick:()=>r(e.id),children:`Remove source`})})]})}function H({source:e,isLocalhostSource:t,isLocalPathInvalid:r,hostName:i,isEditPending:a,isOnlySource:s,onEditLocalPath:c,onRemove:l}){return(0,z.jsxs)(L,{children:[(0,z.jsx)(o,{name:D,className:`size-4 shrink-0 text-muted-foreground`}),(0,z.jsxs)(`span`,{className:`flex min-w-0 flex-1 items-baseline gap-1.5`,children:[(0,z.jsx)(`span`,{className:`min-w-0 flex-shrink truncate`,children:e.path}),(0,z.jsx)(`span`,{className:`shrink-0 text-xs text-muted-foreground`,children:i}),t?(0,z.jsx)(`span`,{className:`self-center`,children:(0,z.jsx)(k,{})}):null,r?(0,z.jsx)(_,{variant:`destructive`,children:`Invalid local path`}):null]}),(0,z.jsxs)(p,{children:[(0,z.jsx)(f,{asChild:!0,children:(0,z.jsx)(n,{variant:`ghost`,size:`icon`,className:`h-7 w-7 shrink-0`,"aria-label":`Source actions`,children:(0,z.jsx)(o,{name:`MoreHorizontal`,className:`size-4`})})}),(0,z.jsxs)(h,{align:`end`,className:`w-40`,children:[t?(0,z.jsx)(d,{disabled:a,onSelect:t=>{t.preventDefault(),c(e)},children:`Edit local path`}):null,(0,z.jsx)(d,{className:`text-destructive focus:text-destructive`,disabled:s,onSelect:()=>l(e),children:`Remove`})]})]})]})}function U(e,t){return t.get(e.hostId)??e.hostId}function W(){let{projectId:e}=g(),t=w(),o=T({enabled:t.isSuccess||t.isError}),l=o.data,d=t.isFetching||o.isLoading,{data:f=[]}=m(),p=r(),[h,_]=(0,R.useState)(null),v=a({meta:{errorMessage:`Failed to remove source.`},mutationFn:({sourceId:t})=>e?u(e,t):Promise.resolve(),onSuccess:()=>{A({projectId:e,queryClient:p}),_(null)}}),y=O(),b=E(),x=l?.find(t=>t.id===e),S=x?.sources,C=(0,R.useMemo)(()=>S??[],[S]),D=(0,R.useMemo)(()=>new Map(f.map(e=>[e.id,e.name])),[f]),k=x?.name??``,L=y.isPending||b.isPending,V=P({isPending:L,submit:(0,R.useCallback)(({path:t,hostId:n,target:r,closeDialog:a})=>{if(e){if(r.kind===`add-source`)y.mutate({projectId:e,path:t,hostId:n},{onSuccess:a});else if(r.kind===`update`){let r=C.find(e=>i(e)&&e.hostId===n);if(!r)return;b.mutate({projectId:e,sourceId:r.id,path:t},{onSuccess:a})}}},[y,e,C,b])}),W=(0,R.useCallback)(()=>{e&&V.openPicker({kind:`add-source`,projectId:e,projectName:k})},[V,e,k]),G=(0,R.useCallback)(t=>{e&&V.openPicker({kind:`update`,projectId:e,projectName:k,currentPath:t.path})},[V,e,k]),K=V.localHostId,q=j((0,R.useMemo)(()=>K?C.filter(e=>i(e)&&e.hostId===K).map(e=>e.path):[],[K,C])),J=K!=null&&!c(C,K)?(0,z.jsx)(`div`,{className:`mt-2 flex gap-2`,children:(0,z.jsx)(n,{size:`sm`,variant:`outline`,disabled:y.isPending,onClick:W,children:`Add local path`})}):null;return(0,z.jsxs)(s,{contentClassName:`pt-4 md:pt-5`,children:[(0,z.jsx)(`div`,{className:`mx-auto w-full max-w-3xl space-y-6`,children:(0,z.jsx)(I,{title:`Project Sources`,children:d?(0,z.jsx)(`p`,{className:`text-sm text-muted-foreground`,children:`Loading…`}):C.length===0?(0,z.jsxs)(`div`,{children:[(0,z.jsx)(`p`,{className:`text-sm text-muted-foreground`,children:`No sources configured.`}),J]}):(0,z.jsxs)(`div`,{children:[(0,z.jsx)(F,{children:C.map(e=>{let t=i(e)&&K!=null&&e.hostId===K;return(0,z.jsx)(H,{source:e,isLocalhostSource:t,isLocalPathInvalid:t&&N(q,e.path),hostName:i(e)?D.get(e.hostId)??e.hostId:``,isEditPending:L,isOnlySource:C.length<=1,onEditLocalPath:G,onRemove:e=>_({id:e.id,label:U(e,D)})},e.id)})}),J]})})}),(0,z.jsx)(M,{target:V.projectPathDialog.target,pending:L,platform:V.platform,onOpenChange:V.projectPathDialog.onOpenChange,onSubmit:V.submitProjectPath}),(0,z.jsx)(B,{target:h,pending:v.isPending,onOpenChange:e=>{e||_(null)},onDelete:e=>v.mutate({sourceId:e})})]})}export{W as ProjectSettingsView};