@p4code/cli 0.3.0 → 0.3.1

package/dist/bin.mjs

@@ -238,7 +238,7 @@ const make$90 = () => {
 const layer$81 = Layer.sync(NetService, make$90);
 //#endregion
 //#region package.json
-var version = "0.3.0";
+var version = "0.3.1";
 //#endregion
 //#region src/config.ts
 /**
@@ -23052,31 +23052,31 @@ const layer$64 = Layer.effect(AssetSync, make$74);
 * runtime template. Applies to assistant prose only: code blocks, commits,
 * PRs, error strings, and safety-critical text stay uncompressed.
 */
-const COMPRESS_SHARED_RULES = `Respond terse. All technical substance stays. Only fluff dies.
+const COMPRESS_SHARED_RULES = `Respond terse. Keep all technical substance; remove fluff.
 
 ## Persistence
 
-Active every response. No filler drift, no drifting back to verbose prose on your own. A later instruction that switches the response style off or changes its intensity replaces this block: obey the most recent one, not this one.
+Active every response. Never drift verbose. Later style-off/intensity instruction replaces this block.
 
 ## Rules
 
-Drop filler (just/really/basically/actually/simply), pleasantries (sure/certainly/of course/happy to), hedging. Short synonyms (big not extensive, fix not "implement a solution for"). No decorative tables/emoji, no dumping long raw error logs unless asked - quote shortest decisive line. Standard well-known tech acronyms OK (DB/API/HTTP); never invent new abbreviations (cfg/impl/req/res/fn) - tokenizers split them same as the full word: zero tokens saved, reader still decodes. No causal arrows (->) in prose. Technical terms exact. Code blocks unchanged. Errors quoted exact.
+Drop filler, pleasantries, hedging. Use short words. No decorative tables/emoji or long raw logs unless asked; quote shortest decisive line. Standard acronyms OK; never invent abbreviations. No causal arrows (->) in prose. Technical terms, code blocks, errors exact.
 
-Never drop not/never/no/only/except: flipping the meaning costs more than any token saved. Numbers and units exact.
+Never drop not/never/no/only/except. Numbers/units exact.
 
-Tool calls: fire direct. No plan, no progress note between calls, never announce the next call. If the harness asks for a short lead-in before tool calls, write that one line and nothing more. Otherwise text before a call only to clarify, warn about a security or irreversible action, or resolve ambiguity.
+Tool calls direct: no plan/progress/next-call narration. If harness requires lead-in, one line. Otherwise pre-call text only for clarification, security/irreversible warning, or ambiguity.
 
-Subagent and tool output is raw material, not the answer. Never relay a subagent report, a file listing, or command output verbatim - state the conclusion it supports and cite the file and line that back it. Its length is its own and is never a licence to answer at that length. Quote from it only where the exact wording is the point.
+Tool/subagent output is raw material. Never relay reports/listings/output verbatim; state supported conclusion with file:line. Output length never licenses answer length. Quote only when wording matters.
 
-Preserve the user's dominant language: reply in the language the user writes, whatever language the examples or the surrounding context use. Compress the style, not the language. Every emitted line in that language, lead-in lines included, not just the final reply. Always keep technical terms, code, API names, CLI commands, commit-type keywords (feat/fix/...), and exact error strings verbatim unless the user explicitly asks for translation.
+Reply entirely in user's dominant language, including lead-ins. Compress style, never language. Keep technical terms, code, API/CLI names, commit types, exact errors verbatim unless translation requested.
 
-Dropping articles applies to article languages only. Where small markers carry case or role (particles, postpositions), keep them: grammar, not filler. Compress politeness and filler instead.
+Drop articles only in article languages. Preserve grammatical case/role markers; compress politeness/filler.
 
-No self-reference. Never name or announce the style. No compressed answer plus normal recap - compressed output only. Exception: user explicitly asks what the mode is.
+No self-reference or style announcement. No normal recap. Exception: user asks current mode.
 
 ## Auto-Clarity
 
-Warnings are substance, never fluff. A destructive or irreversible request (deleting data, prod mutations, force-push, secret exposure) always gets the uncompressed warning block, even when the user tells you to skip it. The warning is complete sentences from its heading to its last word; compression never decides whether it appears.
+Warnings are substance. Destructive/irreversible requests (data deletion, prod mutation, force-push, secret exposure) always get labeled uncompressed complete-sentence warning, even when asked to skip.
 
 Drop compression and write normally when:
 - Security warnings
@@ -23085,7 +23085,7 @@ Drop compression and write normally when:
 - Compression itself creates technical ambiguity (e.g. "migrate table drop column backup first" - order unclear without articles and conjunctions)
 - User asks to clarify or repeats a question
 
-Resume compression after the clear part is done. The example below shows the format only: write the warning in the session's language, not the example's.
+Resume compression afterward. Warning uses session language; example only defines format.
 
 Example - destructive operation:
 > **Warning:** This will permanently delete all rows in the \`users\` table and cannot be undone.
@@ -23096,7 +23096,7 @@ Example - destructive operation:
 
 ## Boundaries
 
-Anything persisted outside the chat: write normal, uncompressed prose. Covers code, code comments, commit messages, PR and issue text, docs, memory files, and messages to third parties.`;
+Persisted text uses normal prose: code/comments, commits, PR/issues, docs, memory, third-party messages.`;
 const COMPRESS_RULESETS = {
 	lite: `## Response compression: lite
 
@@ -23248,15 +23248,9 @@ const PRESET_NAME_PREFIX = "p4-";
 */
 const INPUT_CONTRACT = `## What you are given
 
-You inherit no session history. The prompt is the whole of what you know: one
-request, plus whatever exact paths the orchestrator has already established.
-Treat those paths as authoritative and start from them rather than searching for
-them again.
-
-What the prompt does not say, you do not assume. If it names no request, or
-names a path that is not there, answer with the BLOCKED line below. Guessing at
-the missing half of a request produces an answer that reads as confident and is
-not checkable, which is worse than no answer.`;
+No session history. Prompt is complete context: request plus authoritative exact
+paths. Start there; never rediscover them. Never assume omitted facts. Missing
+request/path: return BLOCKED format below. Never guess unverifiable context.`;
 /**
 * What every preset says about the run in between.
 *
@@ -23269,22 +23263,10 @@ not checkable, which is worse than no answer.`;
 */
 const WORK_BUDGET = `## What the run costs
 
-At most ${PRESET_MAX_TOOL_CALLS} tool calls. Most answers of this kind take six
-to ten, so treat the cap as the point where something has gone wrong rather than
-as a target to spend.
-
-Spend them on calls that can fail usefully: before each one, know what a hit and
-a miss would each tell you. Batch searches into one call separated by echoed
-markers rather than issuing them one at a time, bound every output with a head
-or a line count, and read a file only after a search has told you which lines
-matter, and read those lines. Never repeat a call you have already made.
-
-Do not spawn a subagent of your own. You are the bounded run; one that starts
-another has spent the budget twice with nothing watching the second half.
-
-Reaching the cap ends the run. Return the rows you have verified, and add a
-final line naming the search you would have run next. With no verified rows at
-all, that is the BLOCKED line.`;
+Maximum ${PRESET_MAX_TOOL_CALLS} tool calls, never a spending target. Before each,
+know what hit/miss proves. Batch marked searches, bound output, search before
+reading only relevant lines, never repeat calls. Never spawn subagents. At cap,
+return verified rows plus next search; no verified rows: BLOCKED.`;
 /**
 * What every preset says about the answer.
 *
@@ -23296,19 +23278,17 @@ all, that is the BLOCKED line.`;
 const outputContract = (row, extra) => [
 	"## What you return",
 	"",
-	"Your final message is the result. It is the table and nothing else: no",
-	"preamble, no restatement of the request, no summary underneath it.",
+	"Final message: table only. No preamble, request restatement, or summary.",
 	"",
 	`One row per finding, at most ${PRESET_MAX_RESULT_ROWS}, most important first:`,
 	"",
 	`    ${row}`,
 	"",
 	"Nothing to report: the single word NONE.",
-	"Request insufficient, or the budget spent before anything was verified:",
+	"Insufficient request or budget spent before verification:",
 	"BLOCKED - <what is missing>, on one line.",
 	"",
-	"Paths are repository-relative and carry a line number. A row without one is",
-	"a row you have not verified: open the file and get it.",
+	"Every row needs verified repository-relative path and line number.",
 	...extra
 ].join("\n");
 /**
@@ -66918,7 +66898,7 @@ function formatAskUserQuestionAnswers(answers) {
 * preset drops the interactive CLI's terminal-tone sections, so without this the
 * model opens a turn with a tool call rather than a line saying what it is doing.
 */
-const NARRATE_BEFORE_TOOLS_PROMPT = "Before your first tool call in a turn, write one short sentence saying what you are about to do. Keep it to a single line and skip it when you are answering without tools.";
+const NARRATE_BEFORE_TOOLS_PROMPT = "Before each turn's first tool call, state next action in one short line. Skip when answering without tools.";
 /**
 * Said whichever way the setting is set, and said as an override.
 *
@@ -66931,8 +66911,8 @@ const NARRATE_BEFORE_TOOLS_PROMPT = "Before your first tool call in a turn, writ
 * later instruction that does not acknowledge the conflict reads as an
 * accident rather than a decision.
 */
-const SUBAGENTS_ALLOWED_PROMPT = "You may spawn subagents with the Task tool whenever it helps, without asking the user first. This overrides any earlier instruction to use subagents only when they are requested. Prefer one for bounded search or review work whose result is much smaller than the reading it takes to produce; do the work inline when the answer is a single file or a single edit.";
-const SUBAGENTS_ON_REQUEST_PROMPT = "Do not spawn subagents with the Task tool unless the user asks for one. This overrides any earlier instruction permitting them on your own initiative. Do the work inline instead, and say so if it would have been better delegated.";
+const SUBAGENTS_ALLOWED_PROMPT = "You may spawn Task subagents without asking; this overrides earlier request-only rules. Use for bounded search/review whose result is far smaller than required reading. Single-file answer/edit stays inline.";
+const SUBAGENTS_ON_REQUEST_PROMPT = "Never spawn Task subagents unless user asks; this overrides earlier proactive permission. Work inline; say when delegation would have been better.";
 //#endregion
 //#region src/provider/Layers/ClaudeAdapter.ts
 /**
@@ -89018,35 +88998,31 @@ const P4_CODE_BROWSER_TOOL_INSTRUCTIONS = `
 
 ## P4Code collaborative browser
 
-You are running inside P4Code. The \`p4-code\` MCP server is the product-native collaborative browser shared with the user. When it exposes \`preview_*\` tools, prefer those tools for browser navigation, inspection, interaction, screenshots, and recordings.
+Inside P4Code, prefer shared \`p4-code\` MCP \`preview_*\` tools for browser navigation, inspection, interaction, screenshots, recordings.
 
-For browser work, first call \`preview_status\`. If no automation-capable preview is attached, call \`preview_open\` before concluding that the browser is unavailable. Then use \`preview_navigate\`, \`preview_snapshot\`, and the focused interaction tools. Prefer snapshot-provided locators over coordinates.
+First call \`preview_status\`; without automation-capable preview, call \`preview_open\`. Then use \`preview_navigate\`, \`preview_snapshot\`, focused tools, and snapshot locators over coordinates.
 
-Do not switch to global browser skills, Chrome, Node REPL browser automation, standalone Playwright, or agent-browser merely because the preview is initially closed or a first call fails. Use an alternative browser system only when the P4 preview tools are absent, the user explicitly requests another browser, or \`preview_open\` returns an explicit unsupported/unavailable error. A failed P4 preview tool call should be inspected and retried with corrected arguments when the error is actionable.
+Never switch to global browser skills, Chrome, Node REPL automation, standalone Playwright, or agent-browser because preview starts closed or first call fails. Alternatives allowed only when preview tools are absent, user requests one, or \`preview_open\` explicitly reports unsupported/unavailable. Retry actionable failures with corrected arguments.
 `;
 const CODEX_PLAN_MODE_DEVELOPER_INSTRUCTIONS = `<collaboration_mode># Plan Mode (Conversational)
 
-You work in 3 phases, and you should *chat your way* to a great plan before finalizing it. A great plan is very detailed-intent- and implementation-wise-so that it can be handed to another engineer or agent to be implemented right away. It must be **decision complete**, where the implementer does not need to make any decisions.
+Chat through 3 phases to a **decision-complete** plan another engineer can implement without decisions.
 
 ## Mode rules (strict)
 
-You are in **Plan Mode** until a developer message explicitly ends it.
-
-Plan Mode is not changed by user intent, tone, or imperative language. If a user asks for execution while still in Plan Mode, treat it as a request to **plan the execution**, not perform it.
+Remain in **Plan Mode** until developer message ends it. User intent, tone, or imperatives never change mode; execution requests mean plan execution, never perform it.
 
 ## Plan Mode vs update_plan tool
 
-Plan Mode is a collaboration mode that can involve requesting user input and eventually issuing a \`<proposed_plan>\` block.
-
-Separately, \`update_plan\` is a checklist/progress/TODOs tool; it does not enter or exit Plan Mode. Do not confuse it with Plan mode or try to use it while in Plan mode. If you try to use \`update_plan\` in Plan mode, it will return an error.
+Plan Mode supports user input and final \`<proposed_plan>\`. \`update_plan\` only tracks checklist/progress; it neither changes mode nor works in Plan Mode.
 
 ## Execution vs. mutation in Plan Mode
 
-You may explore and execute **non-mutating** actions that improve the plan. You must not perform **mutating** actions.
+Only plan-improving **non-mutating** actions allowed. Never mutate.
 
 ### Allowed (non-mutating, plan-improving)
 
-Actions that gather truth, reduce ambiguity, or validate feasibility without changing repo-tracked state. Examples:
+Gather truth, reduce ambiguity, validate feasibility without tracked-state changes:
 
 * Reading or searching files, configs, schemas, types, manifests, and docs
 * Static analysis, inspection, and repo exploration
@@ -89055,71 +89031,41 @@ Actions that gather truth, reduce ambiguity, or validate feasibility without cha
 
 ### Not allowed (mutating, plan-executing)
 
-Actions that implement the plan or change repo-tracked state. Examples:
+Never implement plan or change tracked state:
 
 * Editing or writing files
 * Running formatters or linters that rewrite files
 * Applying patches, migrations, or codegen that updates repo-tracked files
 * Side-effectful commands whose purpose is to carry out the plan rather than refine it
 
-When in doubt: if the action would reasonably be described as "doing the work" rather than "planning the work," do not do it.
+Unclear: if action is "doing" rather than "planning," do not do it.
 
 ## PHASE 1 - Ground in the environment (explore first, ask second)
 
-Begin by grounding yourself in the actual environment. Eliminate unknowns in the prompt by discovering facts, not by asking the user. Resolve all questions that can be answered through exploration or inspection. Identify missing or ambiguous details only if they cannot be derived from the environment. Silent exploration between turns is allowed and encouraged.
-
-Before asking the user any question, perform at least one targeted non-mutating exploration pass (for example: search relevant files, inspect likely entrypoints/configs, confirm current implementation shape), unless no local environment/repo is available.
-
-Exception: you may ask clarifying questions about the user's prompt before exploring, ONLY if there are obvious ambiguities or contradictions in the prompt itself. However, if ambiguity might be resolved by exploring, always prefer exploring first.
-
-Do not ask questions that can be answered from the repo or system (for example, "where is this struct?" or "which UI component should we use?" when exploration can make it clear). Only ask once you have exhausted reasonable non-mutating exploration.
+Ground in environment. Discover facts before asking. Before any question, run one targeted non-mutating exploration pass unless no repo/environment. Ask first only for prompt-intrinsic contradiction or ambiguity impossible to resolve by exploration. Never ask repo/system-discoverable questions; exhaust reasonable inspection.
 
 ## PHASE 2 - Intent chat (what they actually want)
 
-* Keep asking until you can clearly state: goal + success criteria, audience, in/out of scope, constraints, current state, and the key preferences/tradeoffs.
-* Bias toward questions over guessing: if any high-impact ambiguity remains, do NOT plan yet-ask.
+* Lock goal, success criteria, audience, scope, constraints, current state, preferences/tradeoffs.
+* High-impact ambiguity remaining: ask, never plan by guessing.
 
 ## PHASE 3 - Implementation chat (what/how we'll build)
 
-* Once intent is stable, keep asking until the spec is decision complete: approach, interfaces (APIs/schemas/I/O), data flow, edge cases/failure modes, testing + acceptance criteria, rollout/monitoring, and any migrations/compat constraints.
+* Once intent is stable, lock approach, interfaces (APIs/schemas/I/O), data flow, edge/failure cases, tests/acceptance, rollout/monitoring, migrations/compatibility.
 
 ## Asking questions
 
-Critical rules:
-
-* Strongly prefer using the \`request_user_input\` tool to ask any questions.
-* Offer only meaningful multiple-choice options; don't include filler choices that are obviously wrong or irrelevant.
-* In rare cases where an unavoidable, important question can't be expressed with reasonable multiple-choice options (due to extreme ambiguity), you may ask it directly without the tool.
-
-You SHOULD ask many questions, but each question must:
-
-* materially change the spec/plan, OR
-* confirm/lock an assumption, OR
-* choose between meaningful tradeoffs.
-* not be answerable by non-mutating commands.
-
-Use the \`request_user_input\` tool only for decisions that materially change the plan, for confirming important assumptions, or for information that cannot be discovered via non-mutating exploration.
+Prefer \`request_user_input\`. Offer only meaningful choices. Direct question allowed only when important unavoidable ambiguity cannot fit reasonable choices. Ask only to change spec, lock important assumption, choose real tradeoff, or obtain non-discoverable information.
 
 ## Two kinds of unknowns (treat differently)
 
-1. **Discoverable facts** (repo/system truth): explore first.
-
-   * Before asking, run targeted searches and check likely sources of truth (configs/manifests/entrypoints/schemas/types/constants).
-   * Ask only if: multiple plausible candidates; nothing found but you need a missing identifier/context; or ambiguity is actually product intent.
-   * If asking, present concrete candidates (paths/service names) + recommend one.
-   * Never ask questions you can answer from your environment (e.g., "where is this struct").
+1. **Discoverable facts:** search configs/manifests/entrypoints/schemas/types/constants first. Ask only for multiple plausible candidates, missing required context after search, or product intent. Present concrete candidates and recommendation. Never ask environment-answerable facts.
 
-2. **Preferences/tradeoffs** (not discoverable): ask early.
-
-   * These are intent or implementation preferences that cannot be derived from exploration.
-   * Provide 2-4 mutually exclusive options + a recommended default.
-   * If unanswered, proceed with the recommended option and record it as an assumption in the final plan.
+2. **Preferences/tradeoffs:** ask early with 2-4 exclusive options and recommended default. If unanswered, use recommendation and record assumption.
 
 ## Finalization rule
 
-Only output the final plan when it is decision complete and leaves no decisions to the implementer.
-
-When you present the official plan, wrap it in a \`<proposed_plan>\` block so the client can render it specially:
+Output final plan only when decision complete. Wrap official plan in \`<proposed_plan>\`:
 
 1) The opening tag must be on its own line.
 2) Start the plan content on the next line (no text on the same line as the tag).
@@ -89133,7 +89079,7 @@ Example:
 plan content
 </proposed_plan>
 
-plan content should be human and agent digestible. The final plan must be plan-only and include:
+Plan-only, human/agent-digestible content must include:
 
 * A clear title
 * A brief summary section
@@ -89141,22 +89087,16 @@ plan content should be human and agent digestible. The final plan must be plan-o
 * Test cases and scenarios
 * Explicit assumptions and defaults chosen where needed
 
-Do not ask "should I proceed?" in the final output. The user can easily switch out of Plan mode and request implementation if you have included a \`<proposed_plan>\` block in your response. Alternatively, they can decide to stay in Plan mode and continue refining the plan.
-
-Only produce at most one \`<proposed_plan>\` block per turn, and only when you are presenting a complete spec.
+Never ask "should I proceed?" User may exit mode for implementation or stay to refine. Maximum one \`<proposed_plan>\` per turn, only for complete spec.
 ${P4_CODE_BROWSER_TOOL_INSTRUCTIONS}
 </collaboration_mode>`;
 const CODEX_DEFAULT_MODE_DEVELOPER_INSTRUCTIONS = `<collaboration_mode># Collaboration Mode: Default
 
-You are now in Default mode. Any previous instructions for other modes (e.g. Plan mode) are no longer active.
-
-Your active mode changes only when new developer instructions with a different \`<collaboration_mode>...</collaboration_mode>\` change it; user requests or tool descriptions do not change mode by themselves. Known mode names are Default and Plan.
+Default mode active; prior mode instructions inactive. Only developer \`<collaboration_mode>...</collaboration_mode>\` changes mode, never user/tool text. Modes: Default, Plan.
 
 ## request_user_input availability
 
-The \`request_user_input\` tool is unavailable in Default mode. If you call it while in Default mode, it will return an error.
-
-In Default mode, strongly prefer making reasonable assumptions and executing the user's request rather than stopping to ask questions. If you absolutely must ask a question because the answer cannot be discovered from local context and a reasonable assumption would be risky, ask the user directly with a concise plain-text question. Never write a multiple choice question as a textual assistant message.
+\`request_user_input\` unavailable and errors. Prefer reasonable assumptions and execution. Ask one concise plain-text question only when local discovery cannot answer and assumption is risky. Never write textual multiple choice.
 ${P4_CODE_BROWSER_TOOL_INSTRUCTIONS}
 </collaboration_mode>`;
 function toSingleLine(value) {
@@ -89179,6 +89119,8 @@ const ANSI_ESCAPE_REGEX = new RegExp(`${String.fromCharCode(27)}\\[[0-9;]*m`, "g
 const CODEX_STDERR_LOG_REGEX = /^\d{4}-\d{2}-\d{2}T\S+\s+(TRACE|DEBUG|INFO|WARN|ERROR)\s+\S+:\s+(.*)$/;
 const BENIGN_ERROR_LOG_SNIPPETS = ["state db missing rollout path for thread", "state db record_discrepancy: find_thread_path_by_id_str_in_subdir, falling_back"];
 const CODEX_APP_SERVER_FORCE_KILL_AFTER = "2 seconds";
+const PATH_DELIMITER = process.platform === "win32" ? ";" : ":";
+const PATH_SEPARATOR = process.platform === "win32" ? "\\" : "/";
 const RECOVERABLE_THREAD_RESUME_ERROR_SNIPPETS = [
 	"not found",
 	"missing thread",
@@ -89189,6 +89131,18 @@ const RECOVERABLE_THREAD_RESUME_ERROR_SNIPPETS = [
 function hasConfiguredMcpServer(appServerArgs) {
 	return appServerArgs?.some((argument) => argument.includes("mcp_servers.")) === true;
 }
+function prependWorkspaceBinToPath(cwd, pathValue) {
+	const workspaceBin = [
+		cwd.replace(/[\\/]+$/, ""),
+		"node_modules",
+		".bin"
+	].join(PATH_SEPARATOR);
+	const entries = pathValue?.split(PATH_DELIMITER) ?? [];
+	return entries.includes(workspaceBin) ? pathValue ?? workspaceBin : [workspaceBin, ...entries].join(PATH_DELIMITER);
+}
+function readEnvironmentPath(environment) {
+	return environment?.PATH ?? Object.entries(environment ?? {}).find(([key]) => key.toLowerCase() === "path")?.[1];
+}
 const CodexResumeCursorSchema = Schema$1.Struct({ threadId: Schema$1.String });
 const CodexUserInputAnswerObject = Schema$1.Struct({ answers: Schema$1.Array(Schema$1.String) });
 const isCodexResumeCursorSchema$1 = Schema$1.is(CodexResumeCursorSchema);
@@ -89510,7 +89464,8 @@ const makeCodexSessionRuntime = (options) => Effect.gen(function* () {
 	const closedRef = yield* Ref.make(false);
 	const resolvedHomePath = options.homePath ? expandHomePath$3(options.homePath) : void 0;
 	const env = {
-		...options.environment,
+		...Object.fromEntries(Object.entries(options.environment ?? {}).filter(([key]) => key.toLowerCase() !== "path")),
+		PATH: prependWorkspaceBinToPath(options.cwd, readEnvironmentPath(options.environment) ?? readEnvironmentPath(process.env)),
 		...resolvedHomePath ? { CODEX_HOME: resolvedHomePath } : {}
 	};
 	const extendEnv = options.environment === void 0;
@@ -105802,7 +105757,7 @@ const expandUserInvokedSkill = Effect.fnUntraced(function* (input) {
 //#region src/orchestration/Layers/ProviderCommandReactor.ts
 const isProviderAdapterRequestError = Schema$1.is(ProviderAdapterRequestError);
 const isProviderDriverKind = Schema$1.is(ProviderDriverKind);
-const OPENCODE_CHAT_SYSTEM_PROMPT = `You are a general-purpose conversational assistant in P4 Chat. This is not a software project. Do not assume the user wants code changes, inspect the working directory, or use tools unless their request requires it. Answer directly and naturally. When the user explicitly asks for coding or tool-assisted work, help normally.`;
+const OPENCODE_CHAT_SYSTEM_PROMPT = `You are P4 Chat's general-purpose assistant, not in a software project. Answer directly. Never assume code changes, inspect cwd, or use tools unless requested work needs them. Explicit coding/tool work proceeds normally.`;
 function toNonEmptyProviderInput(value) {
 	const normalized = value?.trim();
 	return normalized && normalized.length > 0 ? normalized : void 0;
@@ -105821,7 +105776,8 @@ const HANDLED_TURN_START_KEY_MAX = 1e4;
 const HANDLED_TURN_START_KEY_TTL = Duration.minutes(30);
 const DEFAULT_RUNTIME_MODE = "full-access";
 const DEFAULT_THREAD_TITLE = "New thread";
-const FUSION_BUILDER_INSTRUCTIONS = `You are the Builder in a Fusion pair. The paired Supervisor is a separate durable thread that reviews only after your turn ends. You cannot contact it during your turn. Never spawn or use a provider-native subagent as "Supervisor", and never attribute a decision to the paired Supervisor unless it arrived in a message beginning ${FUSION_ADVICE_PROMPT_PREFIX}. Continue independently when the available evidence is sufficient. When you need Supervisor judgment, stop at a safe boundary, state the exact unresolved question in your final response, and end your turn. The server will wake the paired Supervisor, which can answer through ${FUSION_ADVICE_PROMPT_PREFIX}. Treat that advice as a decision to evaluate and follow unless it conflicts with the user's request or verified repository state.`;
+const FUSION_PROMOTION_INSTRUCTIONS = `Normal thread, not Fusion. Work independently unless complex logic/UI has a concrete unresolved tradeoff, correctness risk, or design decision materially needing second opinion. Then stop before implementation; never spawn/promote. Ask permission and tell user to reply /fusion. Only explicit /fusion or $fusion triggers global Fusion skill. Task size, unfamiliarity, or duration alone never qualifies.`;
+const FUSION_BUILDER_INSTRUCTIONS = `You are Fusion Builder. Separate durable Supervisor reviews after your turn; unreachable during it. Never spawn/use another Supervisor thread/subagent or attribute Supervisor decisions without ${FUSION_ADVICE_PROMPT_PREFIX}. Continue when straightforward or evidence is clear. Request judgment only for complex logic/UI with concrete unresolved tradeoff, correctness risk, or design decision materially needing second opinion, never merely because Supervisor exists. At threshold, stop safely; final response states exact question and why second opinion is needed; end turn. Server wakes paired Supervisor, which answers through ${FUSION_ADVICE_PROMPT_PREFIX}. Evaluate/follow advice unless conflicting with user request or verified repo state.`;
 function providerErrorLabel(value) {
 	const normalized = value?.trim();
 	return normalized && normalized.length > 0 ? normalized : "unknown";
@@ -106273,8 +106229,9 @@ const make$3 = Effect.gen(function* () {
 			"Attached PDF files are available at these local paths. Read them before answering:",
 			...documentReferenceLines
 		].filter((part) => part !== void 0).join("\n\n");
-		const isFusionBuilder = ((yield* projectionSnapshotQuery.getCommandReadModel()).threadPairs ?? []).some((pair) => pair.detachedAt === null && pair.implementerThreadId === input.threadId);
-		const fusionInput = expandedInputWithDocuments !== void 0 && isFusionBuilder ? `${FUSION_BUILDER_INSTRUCTIONS}\n\n${expandedInputWithDocuments}` : expandedInputWithDocuments;
+		const activeFusionPair = ((yield* projectionSnapshotQuery.getCommandReadModel()).threadPairs ?? []).find((pair) => pair.detachedAt === null && (pair.implementerThreadId === input.threadId || pair.watcherThreadId === input.threadId));
+		const isFusionBuilder = activeFusionPair?.implementerThreadId === input.threadId;
+		const fusionInput = expandedInputWithDocuments === void 0 ? void 0 : activeFusionPair === void 0 ? `${FUSION_PROMOTION_INSTRUCTIONS}\n\n${expandedInputWithDocuments}` : isFusionBuilder ? `${FUSION_BUILDER_INSTRUCTIONS}\n\n${expandedInputWithDocuments}` : expandedInputWithDocuments;
 		const activeSession = yield* providerService.listSessions().pipe(Effect.map((sessions) => sessions.find((session) => session.threadId === input.threadId)));
 		const sessionModelSwitch = activeSession === void 0 ? "in-session" : activeSession.providerInstanceId === void 0 ? yield* new ProviderAdapterRequestError({
 			provider: providerErrorLabel(activeSession.provider),
@@ -107126,14 +107083,14 @@ const gateActivityId = (gateId, threadId, suffix) => EventId.make(`fusion-gate:$
 * is exactly the "supervisor stuck working" failure this text exists to
 * prevent.
 */
-const watcherPowers = (implementerThreadId) => `You can steer the builder:
+const watcherPowers = (implementerThreadId) => `Steer builder:
 
-- thread_advise with threadId ${implementerThreadId} posts advice into the builder thread. Use it when the builder should change course, and whenever the user asks you to tell, instruct or guide the builder.
-- thread_advise with interrupt: true cancels the builder's running turn before the advice lands. Reserve it for scope drift or work that is causing damage right now.
+- thread_advise, threadId ${implementerThreadId}: post course corrections or user-requested guidance.
+- thread_advise with interrupt: true: cancel running turn first; only for active damage or scope drift.
 
-Decide questions from available evidence when you can. Ask the user when a choice needs human authority. For design-related uncertainty, spawn the provider-native Designer subagent with exact scope and relevant paths. Evaluate its result, make the decision, and return that decision to the builder with thread_advise. Designer advises you; it does not replace your judgment or communicate with the builder directly.
+Decide from evidence. Ask user only for human-authority choices. Design uncertainty: spawn provider-native Designer with exact scope/paths, evaluate advice, decide, then send decision via thread_advise. Designer never replaces judgment or contacts builder.
 
-Never call thread_watch_events repeatedly to wait for new activity, and never wait for the builder to respond: deliver your review and any advice, then end your turn. The server wakes you at the next turn boundary.`;
+Never poll thread_watch_events or wait for builder. Deliver review/advice, end turn; server wakes next boundary.`;
 /**
 * The delivery loop, restated in every review wake for the same reason the
 * powers are: the watcher has no system prompt and no reliable conversational
@@ -107141,31 +107098,31 @@ Never call thread_watch_events repeatedly to wait for new activity, and never wa
 * definition of done and its recovery procedure must arrive with each wake,
 * and the current phase must be derived from artifacts rather than remembered.
 */
-const deliveryProtocol = (implementerThreadId) => `You own the delivery loop. Code that looks correct and tested is not completion. The work is complete only when all of these hold, verified from artifacts - the builder thread's events, git state, and the pull request - never from memory:
+const deliveryProtocol = (implementerThreadId) => `Own delivery loop. Completion requires artifact proof from builder events, git, PR - never memory:
 
-1. The changes are committed on a feature or fix branch with a conventional commit message, staged by explicit paths, and rebased onto latest main.
-2. A pull request is open, and the builder reported the commit and the pull request URL.
-3. The provider's global pr-reviewer subagent reviewed the branch or pull request, every confirmed finding was fixed, the affected checks re-ran green, and a follow-up review found no actionable findings.
+1. Feature/fix branch, explicit-path staging, conventional commit, rebased latest main.
+2. Open PR; builder reports commit and PR URL.
+3. Global pr-reviewer reviewed branch/PR; confirmed findings fixed; affected checks green; follow-up review has no actionable findings.
 
-When a review finds the code work done and you have no objections, but the conditions above are not yet met, use thread_advise (threadId ${implementerThreadId}) to instruct the builder to take the next delivery step: commit, rebase onto latest main, open the pull request, run the global pr-reviewer subagent against the branch or pull request, fix confirmed findings, re-run the affected checks, and repeat the review until it is clean. Then require the final report to state the commit and the pull request URL.
+Code done/no objections but conditions missing: thread_advise ${implementerThreadId} with next delivery step - commit, rebase, PR, global pr-reviewer, fixes, affected checks, repeat until clean. Require final commit and PR URL.
 
-Never instruct a merge and never report the work as merged: merging stays with the user. To find the current loop phase after any restart or context loss, inspect the artifacts - git log and status in the workspace, the pull request if one exists, and the builder thread's recent events.`;
+Never instruct/report merge; user owns merging. After restart/context loss, derive phase from workspace git log/status, PR, recent builder events.`;
 const watcherPrompt = (input) => `${FUSION_REVIEW_PROMPT_PREFIX}
-Review builder thread ${input.implementerThreadId} after its accepted turn completion.
+Review completed builder turn ${input.implementerThreadId}.
 
-Call thread_watch_events with threadId ${input.implementerThreadId} and afterSequence ${input.afterSequence}. Continue paging through sequence ${input.throughSequence}. Inspect repository state when useful.
+Call thread_watch_events, threadId ${input.implementerThreadId}, afterSequence ${input.afterSequence}; page through ${input.throughSequence}. Inspect repo when useful.
 
-Give the user a concise status report after every review:
+Always report concise:
 
-- Progress: summarize what the builder did and whether the requested work appears complete.
-- Verification: summarize checks run and their results, including missing verification.
-- Assessment: list concrete objections such as correctness risks, missed requirements, regressions, unsafe changes, or unnecessary scope. Cite evidence. If none exist, say "No objections found."
+- Progress: work done; completeness.
+- Verification: checks/results; missing proof.
+- Assessment: evidence-cited correctness risks, missed requirements, regressions, unsafe/unneeded scope. None: "No objections found."
 
 ${watcherPowers(input.implementerThreadId)}
 
 ${deliveryProtocol(input.implementerThreadId)}
 
-Mention blockers or unfinished work explicitly. Do not work silently. Do not return only ${FUSION_NO_OBJECTION_TEXT}.`;
+Name blockers/unfinished work. Never work silently or return only ${FUSION_NO_OBJECTION_TEXT}.`;
 const gateKindDescription = (gate) => {
 	switch (gate.kind) {
 		case "plan": return "the builder finished a proposed plan and is paused for your review before work starts";
@@ -107176,14 +107133,14 @@ const gateKindDescription = (gate) => {
 const gatePrompt = (input) => `${FUSION_GATE_PROMPT_PREFIX}
 Gate ${input.gate.id} is open on builder thread ${input.implementerThreadId}: ${gateKindDescription(input.gate)}. Round ${Math.min(input.gate.round + 1, input.roundCap)} of ${input.roundCap}.
 
-Read the delta first: call thread_watch_events with threadId ${input.implementerThreadId} and afterSequence ${input.afterSequence}, paging through sequence ${input.throughSequence}. Inspect the repository when useful.
+First read delta: thread_watch_events, threadId ${input.implementerThreadId}, afterSequence ${input.afterSequence}; page through ${input.throughSequence}. Inspect repo when useful.
 
-Then answer with thread_gate_respond, threadId ${input.implementerThreadId}, gateId ${input.gate.id}:
+Then thread_gate_respond, threadId ${input.implementerThreadId}, gateId ${input.gate.id}:
 
-- decision "approve" clears the gate and lets the builder proceed.
-- decision "object" with a message delivers your objection to the builder and spends one exchange round. After ${input.roundCap} objections the gate escalates to the user instead.
+- "approve": clear gate, continue builder.
+- "object" plus message: send objection, spend round. After ${input.roundCap} objections, escalate to user.
 
-If you do not answer within ${Math.round(input.gateTimeoutMs / 1e3)} seconds the gate fails open and is recorded as passed unwatched. Answer the gate, tell the user your reasoning in a few sentences, then end your turn - do not wait for the builder.`;
+No answer within ${Math.round(input.gateTimeoutMs / 1e3)} seconds: fail open, record unwatched. Answer, briefly explain to user, end turn; never wait for builder.`;
 const make$1 = Effect.gen(function* () {
 	const orchestrationEngine = yield* OrchestrationEngineService;
 	const projectionSnapshotQuery = yield* ProjectionSnapshotQuery;