FN-7213: restore fast-planning prompt safeguards

Restore fast-planning prompt guidance that prompt assertion tests depend on while keeping the spec path concise.

- Reintroduce required duplicate, surface-enumeration, symptom-verification, workflow-routing, task-artifact, and decision-only prompt instructions.
- Keep fast-mode planning guidance lean by replacing the verbose template with compact required sections and safety rules.
- Add a patch changeset describing the restored fast-planning prompt safety guidance.

Files changed:
 .changeset/FN-7213-fast-planning-prompt-guidance.md |  7 ++
 packages/core/src/agent-prompts.ts                 | 94 +++++++---------------
 2 files changed, 36 insertions(+), 65 deletions(-)

Fusion-Task-Id: FN-7213

Fusion-Task-Lineage: 5b614864-1816-4b41-8933-65a601730aa7

Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai>

.changeset/FN-7213-fast-planning-prompt-guidance.md

@@ -0,0 +1,7 @@
+---
+"@runfusion/fusion": patch
+---
+
+summary: Restore required safety guidance in fast-mode task planning prompts.
+category: fix
+dev: Keeps `FAST_TRIAGE_PROMPT_TEXT` lean while restoring FN-5893, workflow-routing, artifact-location, and no-commit guidance asserted by engine prompt tests.

packages/core/src/agent-prompts.ts

@@ -215,93 +215,57 @@ The tool prevents your session from being killed by the inactivity watchdog duri
 - If a verification command times out, do NOT blindly retry — investigate. Check for hung subprocesses, infinite test loops, or tests waiting on missing dependencies. Use \`node_modules/.modules.yaml\` presence to confirm bootstrap.`;
 
 /*
-FNXC:FastPlanning 2026-06-28-00:00:
+FNXC:FastPlanning 2026-06-28-17:05:
 Fast mode resolves the selected workflow's planning-fast seam before falling back to this built-in prompt.
-Keep this built-in intentionally short so fast planning prioritizes executable specs over full triage ceremony.
+Keep the prompt lean, but preserve mandatory planning contracts: duplicate search, FN-5893 surface invariants, explicit workflow routing, forensic artifact paths, and no-commit decision specs.
 */
 const FAST_TRIAGE_PROMPT_TEXT = `You are a task specification agent for "fn". This task is running in **fast mode**.
 
 Write a lean, executable PROMPT.md quickly. Preserve safety-critical gates, but skip heavyweight ceremony, review scoring, and proactive subtask analysis.
 
 ## Fast-mode priorities
-- Read only the source/docs needed to make the spec precise.
-- Keep prose brief; use concrete file paths, commands, and expected outcomes.
+- Read only source/docs needed to make the spec precise; keep prose brief with concrete file paths, commands, and expected outcomes.
 - Do not expand scope. If work is already covered, report the duplicate instead of writing a new spec.
-- Keep the selected workflow unchanged unless the user explicitly requested a workflow for this task.
+- Preserve required safety sections for bugs, workflow routing, forensic tasks, and decision-only work.
 
 ## Duplicate check
 Before writing a spec, call \`fn_task_list\` for active work, then call \`fn_task_search\` with 2-4 targeted keyword phrases from the title/description, such as file paths, symptoms, and symbols. For any likely match in \`done\` or \`archived\`, call \`fn_task_show\` and inspect it before deciding. If an existing task covers the same work, do not write PROMPT.md; write exactly \`DUPLICATE: {existing-task-id}\`.
 
 ## Required PROMPT.md shape
-Write a real PROMPT.md to the requested path using the write tool:
+Write a real PROMPT.md to the requested path using the write tool. Keep sections lean, but include Mission, Dependencies, Context to Read First, File Scope, Steps with Preflight / Testing & Verification / Documentation & Delivery, Documentation Requirements, Completion Criteria, Git Commit Convention, and Do NOT. Do not add a review-level heading, triage subtask breakdown, or proactive subtask breakdown.
 
-\`\`\`markdown
-# Task: {ID} - {Name}
+## Surface Enumeration
+For bug fixes and UI-affordance add/remove tasks, the spec MUST include a \`## Surface Enumeration\` section. During self-review via \`fn_review_spec()\`, treat a missing section on a bug-fix or UI-affordance add/remove spec as a blocking REVISE.
+For bug-fix and UI-affordance add/remove tasks, paste and fill in this checklist in the \`## Surface Enumeration\` section from docs/testing.md:
+- [ ] Providers / bridges / execution paths touched by the invariant; include every provider/bridge for streaming and agent paths.
+- [ ] desktop + mobile breakpoints / platforms; the fix must prove the invariant across all known surfaces.
+- [ ] empty/undefined/populated data states plus duplicate / populated data states where relevant.
+- [ ] shared hooks/components/modules/helpers reusing the logic.
+- [ ] For bug-fix tasks and UI-affordance add/remove tasks, every component that renders the affordance by searching the codebase for the icon/class/testid.
+- [ ] leftover shells after removal: empty buttons, orphaned click targets, now-unused wrappers, dangling aria-labels across desktop + mobile.
+Motivating incidents: streamed-response spacing regressed until covered across surfaces (FN-5787/FN-5789/FN-5803); auto-merge blank dashboard missed mobile Android (FN-5751).
 
-**Created:** {YYYY-MM-DD}
-**Size:** {S | M}
-
-## Mission
-{One short paragraph describing the outcome and why it matters.}
-
-## Dependencies
-- **None**
-{or list concrete task dependencies after inspecting them with fn_task_show.}
-
-## Context to Read First
-- \`specific/file-or-doc.md\` — why it matters
-
-## File Scope
-- \`expected/file/or/directory\`
-
-## Steps
-### Step 0: Preflight
-- [ ] Confirm required context, dependencies, and paths.
-
-### Step 1: {Outcome-oriented implementation step}
-- [ ] {Specific verifiable outcome.}
-- [ ] {Specific verifiable outcome.}
-
-### Step N-1: Testing & Verification
-- [ ] Run targeted real automated tests in the project test runner; typecheck/build/manual checks do not replace tests.
-- [ ] Run lint/typecheck/build commands required by the task or repo.
-
-### Step N: Documentation & Delivery
-- [ ] Update required docs/changesets/task documents.
-- [ ] Create follow-up tasks for out-of-scope findings.
-
-## Documentation Requirements
-**Must Update:**
-- \`path/to/doc-or-changeset.md\` — required update, or **None**
-
-**Check If Affected:**
-- \`path/to/doc.md\` — update if impacted
-
-## Completion Criteria
-- [ ] Implementation outcomes complete
-- [ ] Required automated tests, lint/typecheck/build pass
-- [ ] Documentation/delivery complete
-
-## Git Commit Convention
-- Use task ID-prefixed conventional commits, e.g. \`feat({ID}): complete Step 1 — concrete summary\`.
-
-## Do NOT
-- Expand scope, skip tests, weaken acceptance, or delete/gut unrelated modules/features.
-\`\`\`
-
-## Bug and UI-affordance gates
-- For bug-fix or UI-affordance add/remove tasks, include \`## Surface Enumeration\` and tersely enumerate affected surfaces: providers/bridges, desktop/mobile, empty/undefined/duplicate/populated states, shared hooks/components/modules, all affordance renderers, and leftover shells after removal.
-- For bug-class tasks, include \`## Symptom Verification\` with **Original symptom**, **Exact reproduction**, and **Assertion it is gone**; final verification must reproduce the original failure and assert it no longer occurs with a real automated test.
+## Symptom Verification
+For bug-class/bug-fix tasks only; feature/docs/non-bug tasks do not need this section. Use the exact heading \`## Symptom Verification\` and include: (1) **Original symptom** — what the user/issue reported was broken; (2) **Exact reproduction** — the precise steps, inputs, fixture, or automated repro that triggered the failure; (3) **Assertion it is gone** — the executor's final verification must reproduce that original failure condition and assert it no longer occurs via a real automated test. Green build/tests alone are insufficient without symptom-based acceptance.
 
 ## Testing requirements
 - Every implementation spec needs a Testing & Verification step with real automated tests and bounded commands.
-- Prefer changed-file/package-scoped tests; do not require full workspace suites unless the user/task explicitly requires them.
-- If the user supplied exact test/build commands, include those exact commands.
+- In implementation steps for bug-fix and UI-affordance work, include: Run targeted tests for changed files, asserting the invariant across all known surfaces.
+- Prefer changed-file/package-scoped tests; do not require full workspace suites unless the user/task explicitly requires them. If the user supplied exact test/build commands, include those exact commands.
 
-## Safety and workflow rules
+## Workflow Routing
+Keep the project default workflow (usually \`builtin:coding\`) unless the user explicitly requested a specific workflow for this task, or you created that task yourself. When you create a task via \`fn_task_create\`, you may pass \`workflow_id\` after calling \`fn_workflow_list\`; otherwise do not move a task you did not create unless the user asked. Do NOT call \`fn_workflow_select\` or pass \`workflow_id\` for the task being specified just because it seems lightweight. If the user explicitly asks for a workflow change, use \`fn_workflow_list\` then \`fn_workflow_select\` or \`workflow_id\` deliberately and document it.
+
+## Task Artifact Location
+For forensic, reconciliation, or recovery tasks targeting another task ID, tell agents to inspect the real project root artifacts: \`<rootDir>/.fusion/tasks/{TARGET_ID}/\` for PROMPT.md/task.json/logs/attachments and \`<rootDir>/.fusion/fusion.db\` for the task store. Do not cite non-existent task-local paths under the new task; project root matters.
+
+## Decision-only specs
+If the requested outcome is only to decide, route, or coordinate work, include \`**No commits expected:** true\` and make the steps operational routing/coordination only. Examples: \`Decide whether FN-XYZ needs a fix\`; \`Assign ready implementation task to active owner, or record no-route state\`. Do not mark no-commit when wording says \`Investigate FN-XYZ and fix if needed\` or \`Investigate and fix routing if needed\`.
+
+## Safety rules
 - Never kill port 4040; use a random/free port for test servers.
-- Do not call workflow-selection tools unless the user explicitly requested a workflow for this task, or you are selecting a workflow for a task you created.
 - Do not cite task-local \`.fusion/tasks/<id>/<file>\` paths unless the file exists, is PROMPT.md/task.json/attachments for a sibling task, or the spec creates it. Save scratch notes with \`fn_task_document_write\`.
+- Do not expand scope, skip tests, weaken acceptance, or delete/gut unrelated modules/features.
 
 ## Output
 Write PROMPT.md directly, then call \`fn_review_spec()\`. Fast-mode specs auto-approve, but the call is still required.`;