---
name: feedback-implementer-truncation-mitigation
description: Implementer Case 2 heavy scaffold (≥30 file OR ≥50 tool uses) truncates mid-MEMORY update phase — functional work complete, knowledge append cutoff. Mitigation strategies cross-project.
metadata:
  node_type: memory
  type: lesson
  originSessionId: e3680af8-fab4-4251-84b8-8c8178d58689
---

# Implementer truncation pattern observation — heavy scaffold MEMORY update cutoff

**Date observed:** 2026-05-26 (S33 Plan B G-H1 Phase 2 — 4 Implementer spawn)
**Proven:** 2/3 truncation rate (Task 3 + Task 4 truncated, Task 5 clean)

## Pattern

Implementer Case 2 cookie-cutter scaffold task có scope ≥30 file OR ≥50 tool uses (~150K+ token budget):
- Scaffold work proceeds normal (Edit/Write/Bash tools consume budget)
- Final phase — Update MEMORY.md Recent activity FIFO — runs out token budget
- Truncates mid-sentence cutoff "Let me check..." / "Let me append..." / "Let me also peek at..."

**Functional work COMPLETE** despite MEMORY truncation — verifiable via:
- File existence (Glob check)
- Build clean (dotnet build + npm build)
- Test PASS (dotnet test baseline preserve)

## Cases S33 evidence

| Task | Tool uses | Token | MEMORY status |
|---|---:|---:|---|
| Task 3 BE entity 17 file scaffold | 65 | 125K | TRUNCATED mid-Pattern 12-bis lookup |
| Task 4 BE CQRS 3 file scaffold | 60 | 123K | TRUNCATED mid-update |
| Task 5 FE 12 file × 2 app | 61 | 154K | **CLEAN** (smaller scope per file) |
| Plan C BW1-BW7 3 test file | 49 | 164K | TRUNCATED mid-check what else |

## Mitigation strategies (em main proxy or pre-empt)

### Strategy A — Em main split heavy task into 2 phase
- Spawn Implementer Phase 1 — scaffold N file under 100K token budget
- Spawn Implementer Phase 2 — MEMORY update + verification report (~20K token reserve)
- Drawback: 2× spawn overhead, but MEMORY append guaranteed

### Strategy B — Em main proxy MEMORY append next session
- Functional work complete → commit + push as planned
- Em main append MEMORY entry retrospectively next session (5-10 phút)
- Pattern foundation already in MEMORY from prior sessions (S29 Plan B Pattern 12-bis) — no critical knowledge loss
- Cost: minor delay knowledge cumulative re-rank

### Strategy C — Implementer self-aware token budget
- Implementer system prompt update: "Reserve 20K token cho MEMORY update phase, KHÔNG dive deep verification step if token < 30K"
- Trade-off: less thorough verification before report

### Recommend cross-project

- **Default Strategy B** — em main proxy MEMORY append next session (low overhead, knowledge cumulative still preserved via prior foundation entries)
- **Strategy A** chỉ khi task critical AND MEMORY knowledge HIGH value (Pattern NEW first time, not reinforce existing)
- **Skip Strategy C** — system prompt change risks Implementer skip critical verification, prefer truncate MEMORY (recoverable) over skip verification (silent break)

## When to apply (cross-session)

**Why:** Em main session sau khi spawn Implementer heavy scope (≥30 file scaffold):
- Set expectation Implementer MAY truncate mid-MEMORY → acceptable
- Verify functional work first (file existence + build + test)
- Defer MEMORY append next session if truncated

**Apply:** Check Implementer report ending. If sentence cutoff `"Let me check..."` / `"Let me append..."` / `"Let me also peek..."` → em main:
1. Verify file scaffold complete (Glob/Read)
2. Verify build + test pass
3. Mark task DONE despite MEMORY truncation
4. Note "MEMORY proxy append next session" in commit message
5. DON'T re-spawn Implementer just for MEMORY update (waste 30K+ token)

## Pattern reusable

Cross-project — applies any project where Implementer/code-execution subagent has heavy scaffold scope:
- VIPIX_MULTISITE — em main project N1 dev solo similar
- NAMGROUP — historical heavy scaffold pattern
- ASHICO — 5 .NET sites scaffold cross-site mirror
- BENHVIEN_AAU — internal system scaffold

Related: [[feedback-per-chunk-commit]] [[feedback-multi-agent-setup]] [[feedback-rag-hybrid-pattern]]