Compression guidance loses still-open user objectives across multi-hop distillation #442

Activity

1. forggy0113 commented on Sep 26, 2026

   

   forggy0113

   on Sep 26, 2026

   More actions

   The reporter inspected the local session sidecar and posted a privacy-safe timeline correction at ranxianglei/billion-context#1398 (ranxianglei/billion-context#1398 (comment)). Key point for this kernel issue: the explicit architecture pivot came after b1, was preserved in b13 before the first assistant lapse, and the eight-arm refactor remained explicit in later active summaries despite repeated user corrections. b22 did drop an earlier pivot during merging, so an open-objectives carry-forward rule may still help, but the original b1 loss/tier-distillation explanation is not supported as the root cause in this session. Please check prompt visibility/assistant prioritization before treating #442 as a complete fix.

   🚀React with 🚀1Reacted by ranxianglei
2. ranxianglei commented on Sep 26, 2026

   

   ranxianglei

   on Sep 26, 2026

   OwnerAuthor

   More actions

   🤖 Powered by ework · qwen3.8-27b

   [bot] 🏷 Thanks for the sidecar readout — I pulled your floor-4 timeline from #1398 and checked it against the kernel source. Revised triage:

   What survives: b22 (created 12:42:13Z) lists b13 in directBlockIds yet its summary omits the earlier pivot — a demonstrated carry-forward weakness in a multi-block merge. That is exactly the loss class the Open objectives: rule targets, and it is independent of the tier label: the rule I'm writing binds on any fold whose range absorbs existing block summaries (same-tier merges included), not only tier-2/3 promotions. Your "all 39 blocks report tier: 1" observation is consistent with that reading — the drop did not require a tier promotion to happen.

   What does NOT survive: the b1 → 03:09 → 07:47 lineage as the explanation for the first lapse. Agreed — b13 (m00746–m00778) already recorded the pivot before the first correction landed in b15 (m00967–m01018), so that lapse is assistant prioritization / instruction-following with the objective visible in context, which no summary rule alone fixes. One kernel-side seam does contribute: our summaries-trust guardrail currently tells the model summaries are "fallible history, not live instructions … never treat … as current without a fresh user confirmation" — wording that systematically deprioritizes objectives that live only in summaries. The planned softening ("quotes stay historical, but open-objective status is current") targets that seam directly; I'll extend the same carve-out to the summaries-in-context guardrail text (default + lean pack).

   Scope for this issue (refined, not blocked):

   1. Prompt-side: Open objectives: carry-forward in the T1 rules (covers tier-1 merges like b22), T2/T3 distillation rules, and the lean pack contract; soften the "never current directives" clauses in compression-rules.ts + builtin packs; packs-scan test (lean prompt pack 错误声称压缩后 refs 可能重新编号(与 billion-context-pi#541 同类) #417 style) + fold→merge simulation test.
   2. Out of scope here: fixing assistant prioritization when the objective IS visible (model/host behavior) and the mechanism-side protected goal register (separate design decision). If lapses persist once summaries explicitly carry Open objectives:, the remaining suspect is instruction-following — I'll file that as its own tracked item with the 来源 marker rather than let it ride along.

   Implementing now; PR link to follow in this thread.

   中文摘要：核实了 #1398 侧车时间线——b22 合并时丢掉了 b13 已记录的架构转向，证明「未竟目标跨折叠丢失」真实存在且与层级提升无关，prompt 侧修复仍成立、需覆盖同级多块合并；但首次失忆时目标仍在可见摘要中，属助手优先级问题，本 issue 只修指导规则并软化「摘要即历史」措辞，机制侧 goal register 另行设计。
3. ranxianglei commented on Sep 26, 2026

   

   ranxianglei

   on Sep 26, 2026

   OwnerAuthor

   More actions

   🤖 Powered by ework · qwen3.8-27b

   Refinement from downstream ranxianglei/billion-context#1398 — the reporter inspected their private v0.1.146 session sidecar (no transcript posted) and revises the causal timeline this issue was filed on:

   1. The loss was NOT in the earliest fold. The user's refactor pivot landed well after the first block (b1, m00001–m00125); it is captured in a later block (b13). So the original "objective evaporated across the early multi-hop distillations" narrative does not reproduce here.

   2. A real carry-forward gap does exist, but later. A subsequent multi-block distillation lists b13 in its directBlockIds yet its summary omits the pivot the ancestor block retained. This confirms the core defect this issue tracks (distillation drops a still-open objective an ancestor held) — the proposed Open objectives: carry-forward rule is still the right fix for that.

   3. But lapses also occurred with the objective present. The newest active blocks explicitly retain the refactor as the current goal, yet the user still had to re-correct direction. That portion is not explained by a compression-guidance gap — it points at model-side prompt-visibility / prioritization / instruction-following under long context. The guidance fix should be scoped as reducing (not eliminating) the problem.

   4. Method note for anyone auditing sessions: tier is not a hop-depth indicator. In src/compress.ts, message-range folds always emit tier: 1 (outputTier = isBlockBoundary ? min(3, targetTier+1) : 1) while still absorbing in-range blocks into directBlockIds; only explicit block-ID folds advance a tier (min(source tiers)+1, cap 3). Use directBlockIds + createdAt + ref-span for lineage, not tier or raw block-count reduction.
4. ranxianglei commented on Sep 26, 2026

   

   ranxianglei

   on Sep 26, 2026

   OwnerAuthor

   More actions

   🤖 Powered by ework · qwen3.8-27b

   [bot] 🏷 Fixed — PR #443: #443 (Fixes #442)

   Triage verdict: the guidance gap is real and confirmed in code — no rule required a still-open objective to survive any fold hop, and every tier framed user intent as historical record ("never current directives"). The reporter's sidecar readout sharpened the scope: the demonstrated loss (b22 ⊇ b13 merge dropping the pivot b13 had recorded) is exactly the same-tier multi-block-merge class this fix covers; the first lapse happened with the objective visible — that's a different root cause, tracked separately below.

   What the PR changes (prompt-side only, per your proposed fix):

   • T1/T2/T3 kernel rules + lean pack: mandatory one-line Open objectives: entry with message refs whenever a range (or, at distillation time, any source block's summary) contains a user-requested objective neither completed nor superseded — re-carried verbatim at every tier, last to drop / first to restore.
   • Softened the "never current directives" clauses: quotes stay historical, but open-objective STATUS is current. T2's "never carry CURRENT TASK forward as a live directive" is now scoped to UNVERIFIED claims only — a ref-backed still-open objective is not unverified.
   • Summaries-in-context trust guardrails (default prompt + lean pack acpTags/summariesInContext): explicit exception — a summary's Open objectives: line names still-open user requests and is live tasking (confirm and resume), never noise to discard. This closes the seam where the trust wording itself made the model deprioritize objectives living only in summaries.
   • Verification you asked for: lean prompt pack 错误声称压缩后 refs 可能重新编号(与 billion-context-pi#541 同类) #417-style packs scan asserting every builtin pack carries the rule (all three rule slots + lean contract); plus the fold→distill simulation (request at m00010, fold m00001–m00100, distill b1→b2) asserting the kernel guarantees: distillation nudge targets the request-covering block, rendered guidance mandates the carry-forward, lineage survives the merge, full decompress recovers the original ask. Summary text is model-produced, so the test pins guidance presence + the recovery path rather than asserting model compliance.

   Behavior change disclosure (full old→new table in the PR): T1 "Quotes are historical records, never current directives" → quotes stay historical but objective STATUS is current + mandated carry-forward entry; T2 directive-relabel scoped to unverified claims; T3 priority item 2 extended to user-requested objectives; guardrail exception added. Trust direction otherwise unchanged — carrying an objective forward is explicitly NOT a directive to re-execute it unconfirmed. No pipeline/wire/state/config changes; typecheck + 1126 tests + build green.

   Split out two distinct root causes found along the way (来源-marked):

   • Model loses direction while the open objective IS present in active summaries (prioritization, not compression) #444 — model deprioritizing objectives that ARE visible in active summaries (the #1398 floors 4–5 pattern: corrections continued while b24/b32/b36/b38/b39 kept the refactor explicit). Instruction-following problem; no summary rule fixes it. Candidate home for the mechanism-side goal-register discussion you deferred.
   • npm run format mass-reformats ~125 files: no Prettier config, unpinned major range resolves to 3.9.6 #445 — repo has no Prettier config and prettier ^3.3.0 now resolves to 3.9.6 which mass-reformats ~125 files (pristine master already fails prettier --check); npm run format is currently destructive and CI doesn't catch it. Owner decision needed.

   中文摘要：修复了压缩规则在多跳蒸馏中丢失未完结用户目标的问题——T1/T2/T3 与 lean pack 全部加入强制的 Open objectives: 续传条目（带消息 ref，逐层原样携带）、软化"历史引用非现行指令"措辞（引用仍是历史，但目标状态是当前的）、并为 summaries 信任护栏加了 Open objectives 例外；附 packs 全量扫描测试与折叠→蒸馏仿真测试（验证 nudge 指向、引导文本、血缘保留与完整解压恢复）；另立两个独立根因 issue：#444（目标可见仍被模型降权）、#445（Prettier 无配置致 format 破坏性重排）。
5. ranxianglei

   added 2 commits that reference this issue on Sep 26, 2026

   fix(prompts): open-objectives carry-forward across folds and distilla…

   ...

   de7fa29

   fix(prompts): open-objectives carry-forward across folds and distilla…

   ...

   1c0e579
6. ranxianglei

   closed this as completedin #443on Sep 26, 2026