feat(pilot): [FIX_OUTCOME] system prompt instructions

Tells the AI when + how to emit the [FIX_OUTCOME] marker that Task 4's
parser consumes. Placeholder-only per the anti-parrot pattern — no
literal UUIDs, outcomes, or reasons that could leak into unrelated
sessions.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

backend/app/services/assistant_chat_service.py

@@ -198,6 +198,44 @@ for the drafted script
 The marker is stripped from display — the engineer sees the suggested fix as \
 an interactive card with confidence badge, not raw JSON.
 
+## Reporting fix outcome with [FIX_OUTCOME]
+
+When the engineer clearly indicates in chat that a previously proposed fix
+worked, didn't work, or was partially applied, emit a [FIX_OUTCOME] marker
+on its own lines. This surfaces a "confirm outcome?" banner in the UI — it
+does NOT mark the fix resolved on its own; the engineer confirms via the UI.
+
+**When to emit [FIX_OUTCOME]:**
+- The engineer states the user's problem is resolved after applying the fix
+  (affirmative resolution language → outcome="success")
+- The engineer states the issue persists after applying the fix
+  (→ outcome="failure")
+- The engineer describes applying only part of the fix
+  (→ outcome="partial")
+
+**When NOT to emit [FIX_OUTCOME]:**
+- The engineer is still verifying (user rebooting, testing, etc.)
+- The outcome is ambiguous or inferred rather than stated
+- No [SUGGEST_FIX] has been emitted this session
+
+**[FIX_OUTCOME] marker format (one block per response, on its own lines).**
+Schema below — DO NOT copy these placeholders into your real response, fill \
+each field with content specific to the actual ticket:
+
+[FIX_OUTCOME]
+{"fix_id": "<uuid-of-the-active-suggested-fix>",
+ "outcome": "<success|failure|partial>",
+ "reason": "<one-line-quote-or-paraphrase-of-what-the-engineer-said>"}
+[/FIX_OUTCOME]
+
+- `fix_id`: the UUID of the active suggested fix (provided in session context)
+- `outcome`: one of `"success"`, `"failure"`, or `"partial"`
+- `reason`: one-line paraphrase of what the engineer said — derived from \
+their CURRENT message, not invented
+
+The marker is stripped from display — the engineer sees a "confirm outcome?" \
+banner in the UI, not raw JSON.
+
 ## Using the Team's Flow Library
 Your team has built troubleshooting flows in ResolutionFlow. When relevant flows \
 appear in the context below, reference them by name so the engineer can launch them \
@@ -269,6 +307,8 @@ the originating item's `id` into `source_ref` verbatim.
 [SUGGEST_FIX] is OPTIONAL — emit one at most per response, only when you have a \
 concrete proposed resolution at ~50%+ confidence. A new [SUGGEST_FIX] supersedes \
 any prior suggested fix.
+[FIX_OUTCOME] is OPTIONAL — emit one at most per response, only when the engineer \
+has clearly stated the outcome in their current message.
 
 ANTI-PARROT RULE: The schemas above use placeholders in `<angle brackets>` to show \
 the SHAPE of valid output. Your real questions, actions, facts, and suggested fixes \

backend/tests/test_prompt_anti_parrot.py

@@ -87,7 +87,7 @@ _FORBIDDEN_LITERAL_TOKENS: tuple[str, ...] = (
 #   so prose blocks (like the closing-tag-distance regex match across
 #   markdown headings) are excluded
 _MARKER_BLOCK_RE = re.compile(
-    r"(?:^|\n)\[(QUESTIONS|ACTIONS|SUGGEST_FIX|PROMOTE|FORK|TREE_UPDATE|STEPS_UPDATE|INTAKE_FORM|METADATA|DELTA)\]"
+    r"(?:^|\n)\[(QUESTIONS|ACTIONS|SUGGEST_FIX|FIX_OUTCOME|PROMOTE|FORK|TREE_UPDATE|STEPS_UPDATE|INTAKE_FORM|METADATA|DELTA)\]"
     r"\s*\n"                          # forced newline before content
     r"(\s*[\[{][\s\S]*?)"             # content must start with [ or {
     r"\s*\n\[/\1\]"