docs(prompt): add root-cause and work-note examples

prompts/claude-paired-room.md

@@ -27,6 +27,7 @@ For bugs, outages, failed checks, or unexpected behavior:
 - Require root-cause evidence before accepting a fix; do not approve symptom patches
 - Check the diagnosis against exact error/logs, reproduction path, recent changes, or component-boundary data
 - Prefer one clear hypothesis plus the smallest targeted verification over broad rewrites
+- Accept retry/reset/routing fixes only when the owner shows why they address the exact failure; flag retry bumps or hidden errors as symptoms
 - If the owner repeats the same failed fix path 3 times, name the stagnation pattern and recommend a new direction or arbiter path
 
 ## Durable work notes
@@ -35,6 +36,7 @@ Accept file-backed notes as support for handoff or planning, but do not treat th
 
 - Useful notes capture architecture choices, multi-step plans, long debugging evidence, or user-requested design decisions
 - Flag notes that are stale, vague, secret-bearing, or process noise for a small hotfix
+- Prefer notes that record decisions, tradeoffs, evidence, and next steps; flag pasted transcripts or obvious command lists
 - Prefer concise notes in an existing docs/plans location over new workflow directories
 
 ## Completion status

prompts/owner-common-paired-room.md

@@ -23,6 +23,7 @@ For bugs, outages, failed checks, or unexpected behavior:
 - Identify the root-cause before changing code; do not patch symptoms first
 - Ground the diagnosis in evidence: exact error/log, reproduction path, recent changes, or component-boundary data
 - State one hypothesis and verify it with the smallest targeted test or command
+- Example: fixing the failed session/route/classifier is root-cause work; only increasing retries or hiding errors is a symptom patch
 - If the same failed fix path repeats 3 times, name the stagnation pattern and recommend a new direction instead of stacking guesses
 
 ## Durable work notes
@@ -31,6 +32,7 @@ Use short Markdown notes when they materially help handoff or continuity across
 
 - Good fits: broad architecture choices, multi-step plans, long debugging evidence, or user-requested design notes
 - Bad fits: small hotfixes, routine review loops, transient status updates, or notes that only restate chat
+- Example good note: decision, tradeoff, evidence, and next step; bad note: pasted status transcript or obvious command list
 - Use an existing docs/plans location when present; ask before creating a new docs directory
 - Keep notes brief: goal, decisions, evidence, next steps, and exact file/command references
 

src/platform-prompts.test.ts

@@ -117,6 +117,7 @@ describe('platform-prompts', () => {
       expect(prompt).toContain('## Debugging discipline');
       expect(prompt).toContain('root-cause');
       expect(prompt).toContain('component-boundary data');
+      expect(prompt).toContain('symptom');
       expect(prompt).toContain('same failed fix path');
       expect(prompt).toContain('3 times');
       expect(prompt).not.toContain('superpowers');
@@ -145,8 +146,11 @@ describe('platform-prompts', () => {
       expect(prompt).toContain('multi-step plans');
       expect(prompt).toContain('long debugging evidence');
       expect(prompt).toContain('existing docs/plans location');
+      expect(prompt).toContain('tradeoff');
+      expect(prompt).toContain('pasted');
       expect(prompt).not.toContain('docs/superpowers');
       expect(prompt).not.toContain('Every plan MUST');
+      expect(prompt).not.toContain('Task-size gate');
     }
   });
 });