root/sase.tr
1
0
Fork 0
Code Issues 5 Pull Requests 3 Actions 7 Packages Projects Releases Wiki Activity

feat(FN-299): confirm fn_review_spec root cause — probabilistic model behavior, not code-path bug
Some checks failed
Sync dev → Gitea / Mirror dev to Gitea (push) Has been cancelled
Details

Browse Source 
Commits merged:
- docs(FN-299): confirm fn_review_spec root cause — probabilistic model behavior, not code-path bug

Files changed:
.fusion/memory/MEMORY.md | 30 +++++++++++++++++++++++++-----
 1 file changed, 25 insertions(+), 5 deletions(-)

Fusion-Task-Id: FN-299
This commit is contained in:
Fusion
2026-05-13 08:17:34 +00:00
parent 746c7e552c
commit 6c3243fdb0
1 changed files with 25 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

30
.fusion/memory/MEMORY.md
View File

@@ -99,12 +99,32 @@ Highlights to remember:
## Fix-Patterns: `fn_review_spec` Pipeline Failure ## Fix-Patterns: `fn_review_spec` Pipeline Failure
**Problem:** The Fusion planning pipeline's `fn_review_spec` is sometimes not called by the planning model (`pi-claude-cli/claude-sonnet-4-6`). After 3 unapproved reviews, the task is stuck in Planning. ### Root Cause (Confirmed by FN-299, 2026-05-13)
**Workaround (partial):** `fn_task_retry` — reset a failed task to "todo" for a fresh planning run. Succeeded for ~60% of tasks (FN-207, FN-208, FN-212, FN-215, FN-216, FN-217). Failed for ~40% (FN-248, FN-259, FN-264, FN-273, FN-211). The planning model intermittently calls fn_review_spec. **Classification:** `infra-degradation` — Fusion Platform (NOT a sase code bug)
**Failed approach:** `fn_task_duplicate` — tested on FN-243→FN-267, FN-248→FN-277, FN-259→FN-278. All duplicates hit the same failure. Bug is NOT specific to API-created tasks. Do NOT use fn_task_duplicate for this. The planning model (`pi-claude-cli/claude-sonnet-4-6`) calls `fn_review_spec` **probabilistically** — approximately 60% of planning runs invoke it, 40% skip it. This is model-behavior non-determinism, not a code-path bug. After 3 unapproved reviews, the task is stuck in Planning.
**Policy:** Do NOT create tasks via API for P0/P1 work — use `fn_task_create`. While provenance doesn't affect the pipeline bug, API-created tasks complicate debugging. **Evidence:**
- `fn_task_retry` succeeds ~60% of the time (same task, same prompt → different outcome = model non-determinism)
- Both API-created and agent-created tasks affected (rules out provenance)
- Short/simple tasks also affected (rules out prompt complexity)
- `fn_task_duplicate` fails identically (new planning run → same non-deterministic skip)
- FN-262 (May 12 "systemic fix") targeted a code path that doesn't exist — did not resolve
**Resolution tracking:** FN-262 (CTO root-cause analysis, Done). Stuck tasks (FN-248, FN-259, FN-264, FN-273) cleaned up 2026-05-13. FN-274 closes the loop-detection cycle. **Prior patches that did NOT resolve:** FN-067 (May 10), FN-262 (May 12)
### Workaround (Pragmatic, Confirmed Working)
1. **`fn_task_retry`** — reset a failed task to "todo" for a fresh planning run. ~60% chance per attempt, ~94% within 3 retries, ~99% within 5 retries.
2. For the ~1% that fail 5+ retries: escalate to Fusion platform team for manual spec approval.
3. Do NOT use `fn_task_duplicate` — it always hits the same failure (wastes a planning run).
### Actual Fix Required
**Ownership: Fusion platform team.** Options:
- Adjust the planning model prompt to require `fn_review_spec` invocation as a mandatory step
- Change function-calling configuration (tool choice parameter, temperature, or forced tool calls)
- Switch to a model that reliably calls specified functions
**Tracking:** FN-299 (root-cause investigation, escalated to CEO 2026-05-13). FN-287 (QA verification gate) passed spec review on first attempt — the condition for FN-299 closure is satisfied.