solution-erp/.claude/auto-memory/feedback_implementer_truncation_mitigation.md

name, description, metadata

name	description	metadata
feedback-implementer-truncation-mitigation	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.	node_type type originSessionId memory lesson 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