Claude Code के Compact फीचर के लिए समस्याएं और समाधान

बाद में, मैंने एक प्लगइन बनाया जो स्वचालित रूप से निम्नलिखित सामग्री शामिल कर सकता है और कॉम्पैक्ट सुविधा को पारदर्शी रूप से बढ़ा सकता है।

https://x.com/u1/status/2073742408555343968

Claude Code का Compact वास्तव में कैसे काम करता है

एक आधार के रूप में, Claude Code का compact दो पथों से चलता है:

• मैनुअल compact (/compact): उपयोगकर्ता द्वारा स्पष्ट रूप से ट्रिगर किया जाता है। किसी भी समय चलाया जा सकता है।
• ऑटोमैटिक compact: स्वचालित रूप से तब चलता है जब सत्र संदर्भ उपयोग सीमा के करीब पहुँच जाता है (व्यवहार में लगभग 90-95%)। यह उपयोगकर्ता के इच्छित सटीक क्षण पर नहीं चलता, बल्कि टर्न बाउंड्री पर चलता है जहाँ आपको अचानक पता चलता है कि यह संपीड़ित हो गया है।

दोनों पथों में, सामग्री समान होती है: पिछले वार्तालाप इतिहास को LLM को भेजा जाता है ताकि एक प्राकृतिक भाषा सारांश बनाया जा सके, और सारांश + हाल के टर्न + सिस्टम प्रॉम्प्ट को एक नए संदर्भ के रूप में पुनर्निर्मित किया जाता है। सारांश "क्या किया गया" का एक कथा-आधारित विवरण बन जाता है, और परिणामस्वरूप, निर्णय संरचना—जैसे "वह विकल्प क्यों चुना गया," "कौन सी योजनाएँ अस्वीकार कर दी गईं," और "हम वर्तमान में किस चरण में हैं"—कमजोर हो जाती है। इसके अलावा, एक बार संपीड़न चलने के बाद, यह एक अपरिवर्तनीय ऑपरेशन है; आप संपीड़न से पहले के रॉ लॉग पर वापस नहीं जा सकते।

हुक के दृष्टिकोण से, संपीड़न को PostCompact इवेंट द्वारा पकड़ा जा सकता है। हालाँकि, PostCompact हुक additionalContext वापस नहीं कर सकता, इसलिए संपीड़न के तुरंत बाद एजेंट में सीधे निर्देश इंजेक्ट करने का कोई रास्ता नहीं है। निर्देश डालने के लिए, बाद के UserPromptSubmit इवेंट से गुज़रना होगा। यह बाध्यता इस लेख में हुक डिज़ाइन को निर्धारित करती है।

स्टैंडर्ड Compact में क्या गलत है

Claude Code का /compact वार्तालाप इतिहास का सारांश बनाता है, परिणाम को एक नए सत्र के लिए प्रारंभिक संदर्भ के रूप में रखता है। जबकि सारांश स्वयं उचित है, यह "भविष्य में क्या करना है इसके लिए निर्देश" के बजाय "अतीत का कार्य लॉग" है। परिणामस्वरूप, संपीड़न के बाद का एजेंट निम्नलिखित गलतफहमियों का शिकार हो जाता है:

• "कार्य निर्देशों" और "कार्य लॉग" के बीच की सीमा खोना। यदि सारांश कहता है "प्लान A पर विचार किया गया था," तो एजेंट वास्तव में अपनाई गई प्लान B के बजाय प्लान A को लागू करना शुरू कर सकता है।
• सत्यापन चरण को कार्यान्वयन चरण के साथ भ्रमित करना। "डिप्लॉय करने से पहले वास्तविक मशीन पर सत्यापित करें" का आधार सारांश से गायब हो जाता है, और एजेंट अगले टर्न में विनाशकारी डिप्लॉयमेंट ऑपरेशन में कूद सकता है।
• पहले से खारिज किए गए गलत दृष्टिकोणों को फिर से प्रस्तावित करना। सारांश रिकॉर्ड कर सकता है कि एक दृष्टिकोण "आज़माया गया" था, लेकिन "इसे अस्वीकार करने का कारण" नहीं।
• "सत्र स्थिति" जैसे प्लान मोड, वर्कर डेलिगेशन, या टास्क ट्री खोना। एजेंट प्लान मोड से बाहर काम जारी रख सकता है या tmux में चल रहे वर्कर्स के अस्तित्व को भूल सकता है और खुद काम करना शुरू कर सकता है।

वास्तव में किस तरह की दुर्घटनाएँ हुईं

पिछले सप्ताह में अपने सत्रों को देखते हुए, मैंने एक compact के तुरंत बाद कम से कम चार पैटर्न देखे। सभी "कार्य निर्देशों" को "कार्य लॉग" से अलग करने में विफलता में निहित प्रतीत होते हैं:

• सत्यापन से पहले डिप्लॉयमेंट: "फ़ाइलें रखने से पहले मशीन पर व्यवहार सत्यापित करें" पर सहमत होने के बावजूद, एजेंट ने संपीड़न के बाद सारांश में केवल पूर्णता छवि देखी, सत्यापन छोड़ दिया, और गंतव्य को अधिलेखित कर दिया।
• अस्वीकृत शॉर्टकट को फिर से निष्पादित करना: क्योंकि सारांश ने एक असफल शॉर्टकट दृष्टिकोण को "आज़माई गई प्रक्रिया" के रूप में रिकॉर्ड किया, एजेंट ने इसे फिर से निष्पादित किया और फिर से उसी विफलता में कदम रखा।
• डिज़ाइन सिद्धांतों को भूलना: सत्र के दौरान स्थापित सिद्धांत, जैसे "गंतव्य के बजाय स्रोत रिपॉजिटरी को संपादित करें," सारांश से गायब हो गए, जिससे एजेंट ने प्रत्यक्ष संपादन किए जो अल्पावधि में काम करते हैं लेकिन पुनरुत्पादनीय नहीं हैं।
• कार्य लक्ष्यों को गलत समझना: संपीड़न से पहले तय किए गए एक परीक्षण का विशिष्ट उद्देश्य खो गया, जिससे एजेंट परिधीय जांच में भटक गया और पूरी तरह से अलग लाइन पर काम शुरू कर दिया।

ये एक ही सत्र के भीतर कई बार हुए, प्रत्येक compact के बाद विभिन्न प्रकार की गलतफहमियाँ हुईं। मैं इन्हें पृथक दुर्घटनाओं के बजाय मानक compact विनिर्देश की संरचनात्मक विफलताओं के रूप में देखता हूँ।

मैंने क्या बनाया

(1) compact-prep स्किल

एक स्लैश कमांड के रूप में कार्यान्वित एक स्किल जिसे उपयोगकर्ता /compact टाइप करने से पहले स्पष्ट रूप से हिट करता है। यह "निर्णय संरचना" और "सत्र स्थिति" निकालता है जो संभवतः सारांश में फिट नहीं होगी और उन्हें एक विशिष्ट प्रारूप में एक निश्चित पथ ($ {TMPDIR}/claude-compact-state/<session_id>.md) पर एक स्थिति फ़ाइल में सहेजता है।

सहेजी गई वस्तुओं में वे शामिल हैं जो सारांश में कैप्चर करना कठिन हैं:

• सक्रिय योजना (प्लान फ़ाइल पथ और वर्तमान चरण)
• कार्य सूची सारांश (प्रगति पर कार्य और पूरक)
• सत्र निर्णय (अपनाई गई योजनाएँ / अस्वीकृत योजनाएँ / अस्वीकृति के कारण)
• बाधाएँ और अवरोधक
• वर्कर टोपोलॉजी (tmux-bridge पेन / भूमिकाएँ / असाइनमेंट)
• फ़ाइलों का संपादन (असुरक्षित या अप्रमाणित परिवर्तनों पर नोट्स)
• पुनर्प्राप्ति नोट्स (संपीड़न के बाद के स्वयं को एक पत्र)

मुख्य डिज़ाइन बिंदु "यांत्रिक प्रवर्तन" है। यह session_id न मिलने पर फ़ाइल निर्माण को रोकने के लिए एक हार्ड गेट, चूक का पता लगाने के लिए निश्चित शीर्षकों के साथ एक फोर्सिंग फ़ंक्शन, और स्थिति भ्रष्टाचार को रोकने के लिए प्रतिबंधित अनुमत-उपकरणों का उपयोग करता है।

(2) दो-चरणीय हुक: PostCompact + UserPromptSubmit

भले ही (1) एक स्थिति फ़ाइल लिखता है, यह बेकार है यदि संपीड़न के बाद का एजेंट इसे नहीं पढ़ता है। चूँकि PostCompact additionalContext वापस नहीं कर सकता, मैंने दो-चरणीय कॉन्फ़िगरेशन का उपयोग किया:

1. PostCompact हुक session_id के साथ एक मार्कर फ़ाइल लिखता है (कोई निर्देश नहीं, केवल यह रिकॉर्ड करना कि संपीड़न हुआ)।
2. जब अगला UserPromptSubmit हुक मार्कर का पता लगाता है, तो यह additionalContext के माध्यम से निर्देश इंजेक्ट करता है: "प्लान फ़ाइल पढ़ें / स्थिति फ़ाइल पढ़ें / कार्य सूची जांचें / सारांश के अगले चरणों को परिकल्पना के रूप में मानें / यदि प्लान मोड निष्क्रिय किया गया था तो पुन: प्रवेश की पुष्टि करें," फिर मार्कर को हटा देता है।

चूँकि Claude Code में हुक के बीच साझा स्थिति तंत्र का अभाव है, फ़ाइल सिस्टम पर एक मार्कर ही संचार का एकमात्र रास्ता है। यह प्रत्येक हुक को एकल जिम्मेदारी के साथ पतला रखता है। सामान्य टर्न में, ओवरहेड केवल एक test -f जाँच है।

(3) 60% सूचना (ऑटोमैटिक compact से बचने के लिए)

पिछले उपकरण मानते हैं कि उपयोगकर्ता मैन्युअल रूप से /compact-prep → /compact चलाता है। हालाँकि, ऑटोमैटिक compact बिना चेतावनी के चलता है, इस प्रवाह को दरकिनार करता है। यदि ऑटोमैटिक compact पहले हिट करता है, तो स्थिति फ़ाइल सहेजी नहीं जाती है, और रॉ लॉग को एक सारांश में कुचल दिया जाता है, जिससे पुनर्प्राप्ति सामग्री खो जाती है।

समाधान एक ऐसी स्थिति बनाना है जहाँ उपयोगकर्ता ऑटोमैटिक compact ट्रिगर होने से पहले मैन्युअल रूप से prep चला सके। यह 60% सूचना का उद्देश्य है।

60% क्यों?

• पर्याप्त लीड टाइम: ऑटोमैटिक compact लगभग 90-95% पर ट्रिगर होता है। 60% 30% का मार्जिन प्रदान करता है, यह सुनिश्चित करता है कि उपयोगकर्ता अगले टर्न से पहले चेतावनी देखता है जो ऑटो-कॉम्पैक्ट को ट्रिगर कर सकता है।
• रुकने के बिंदु तक पहुँचने के लिए जगह: 60% पर, स्थिति सहेजने से पहले एक उप-कार्य समाप्त करने के लिए अभी भी 30% क्षमता शेष है।
• यांत्रिक ट्रिगर: यह एक फोर्सिंग फ़ंक्शन के रूप में कार्य करता है जब आप संदर्भ खपत को नोटिस करने के लिए बहुत अधिक केंद्रित होते हैं।
• 1M संदर्भ धारणा: 200K संदर्भ के साथ, 60% बहुत छोटा है। मैं 1M संदर्भ (Opus 4.7) का उपयोग करता हूँ, जहाँ 60% लगभग 600K टोकन छोड़ता है—काम खत्म करने और prep चलाने के लिए पर्याप्त जगह।

कार्यान्वयन में एक स्टेटसलाइन हुक शामिल है जो थ्रेशोल्ड पर एक चेतावनी मार्कर लिखता है, और एक UserPromptSubmit हुक जो इसका पता लगाता है और /compact-prep चलाने का सुझाव देता है।

परिणाम

सत्र अब लगभग 10 संपीड़न के बाद भी तार्किक विघटन के बिना स्थिर हैं!

• संपीड़न के कारण कार्य हानि लगभग शून्य है।
• अस्वीकृत विचारों का पुन: प्रस्ताव गायब हो गया है।
• प्लान मोड बनाए रखा जाता है।
• tmux में कई वर्कर्स चलाते समय टोपोलॉजी को भूलना अब नहीं होता।

संदर्भ: कार्यान्वयन कोड

नीचे वास्तविक स्किल और हुक कोड हैं। वे मानक Claude Code निर्देशिका (~/.claude/) में कॉपी करके काम करते हैं।

A: compact-prep स्किल बॉडी

~/.claude/skills/compact-prep/SKILL.md में रखें।

1---
2name: compact-prep
3description: |
4  Claude Code में /compact निष्पादित करने से पहले, वर्तमान सत्र स्थिति को एक अस्थायी स्थिति फ़ाइल में सहेजें।
5  अनिवार्य ट्रिगर: /compact-prep, compact-prep, संपीड़न तैयारी।
6  ट्रिगर न करें: compact के बाद पुनर्प्राप्ति, सामान्य प्रगति रिपोर्ट, योजना निर्माण।
7strict_procedure: true
8argument-hint: "[पुनर्प्राप्ति नोट्स]"
9allowed-tools: Read Write Bash(~/.claude/scripts/get-session-id.sh *) Bash(mkdir *) Bash(date *) Bash(pwd)
10---
11
12# compact-prep
13
14सत्र स्थिति सहेजता है जो संपीड़न सारांश में रखना कठिन है
15`${TMPDIR}/claude-compact-state/${SESSION_ID}.md` में `/compact` से पहले।
16
17## सख्त प्रक्रिया प्रोफ़ाइल
18
19- सख्ती: strict-procedure.
20- हार्ड गेट: यदि session_id प्राप्त नहीं किया जा सकता तो रुकें।
21- फोर्सिंग फ़ंक्शन: सहेजने के बाद निश्चित पथ और अनिवार्य शीर्षक जाँच।
22- पूर्णता रसीद: फ़ाइल पथ, सहेजी गई वस्तुएँ, और `/compact` चलाने का मार्गदर्शन रिपोर्ट करें।
23
24## प्रक्रिया
25
261. `~/.claude/scripts/get-session-id.sh` के माध्यम से session_id प्राप्त करें।
272. पथ सेट करें `${TMPDIR:-/tmp}/claude-compact-state/${SESSION_ID}.md` पर।
283. कार्य सूची, सक्रिय योजना, tmux-bridge, और संपादन फ़ाइलों की जाँच करें।
294. शीर्षक क्रम में सहेजें: # Compact Prep State, ## Active Plan, ## Current Phase, ## TaskList Summary, ## Session Decisions, ## Constraints and Blockers, ## Worker Topology, ## Editing Files, ## Recovery Notes.
305. सत्यापित करें कि सभी शीर्षक मौजूद हैं।
316. उपयोगकर्ता को बताएं: "तैयारी पूर्ण। कृपया `/compact` निष्पादित करें।"

B: पुनर्प्राप्ति हुक (2 चरण)

B-1: PostCompact हुक

~/.claude/hooks/compaction-recovery.sh

B-2: UserPromptSubmit हुक (इंजेक्शन)

~/.claude/hooks/userpromptsubmit-compaction-recovery.sh

C: 60% सूचना

C-1: statusline हुक थ्रेशोल्ड शाखा

~/.claude/hooks/statusline.sh में जोड़ा गया।

C-2: UserPromptSubmit हुक (अनुस्मारक)

~/.claude/hooks/userpromptsubmit-compact-prep-reminder.sh

D: settings.json पंजीकरण

हुक को ~/.claude/settings.json में जोड़ें।