← graph

design-wg-pi-compaction-kick

Design authoritative WG Pi compaction kick

Metadata

Statusdone
Agent identity02e879681e52e0a384106169be043416c4d946e850ab26b2269c57681b52a6e7
Created2026-08-05T20:52:42.481149301+00:00
Started2026-08-06T07:54:37.039523038+00:00
Completed2026-08-06T08:29:34.253525137+00:00
Tagspi, compaction, design, watchdog
Tokens8293109 in / 36432 out

Description

Objective

Synthesize the reproducer, upstream research, and WG seam audit into an implementation-ready design for safely kicking an unattended Pi task worker that becomes idle immediately after successful threshold compaction while explicit WG work remains unresolved.

Exactly-once is scoped per distinct qualifying successful threshold-compaction occurrence, not per task or attempt: two successive qualifying threshold compactions must produce two distinct kicks. Duplicate/replayed events for the same occurrence must deduplicate by a durable compaction occurrence/session-entry identity. Do not impose a one-kick-per-attempt cap; only the existing explicit overall continuation/time safety budget may stop repeated legitimate recoveries, and exhaustion must be loud.

The design must reuse the existing watchdog/lifecycle/session proof and finite continuation authority. Specify event/state transitions, the exactly-once durable action key, who grants the nudge, who delivers it into the live Pi session, how delivery is acknowledged, and how replay behaves across crashes before/after permit and send. Define explicit suppression for manual compaction, overflow (willRetry=true), failed/aborted compaction, queued steering/follow-up, non-idle Pi, accepted wg_done/wg_fail/wg_wait, unsafe in-flight effects, route/session/process mismatch, and exhausted continuation budget. The kick must preserve task generation, attempt, worktree lease, Pi session/branch, process epoch when same PID, and frozen route.

Also decide whether this belongs in the embedded WG Pi plugin, the Rust harness/watchdog, or a split permit+delivery protocol. Do not implement code.

Validation

  • The design includes a state table and crash matrix covering compaction start/end, settled, terminal races, process exit, duplicate/replayed events, and delivery acknowledgement.
  • No heuristic prose classification is required to decide whether WG protocol remains unresolved; authority comes from task/lifecycle receipts.
  • Exactly one kick is possible per distinct qualifying compaction occurrence; two successive qualifying compactions produce two kicks, while duplicate events for either occurrence deduplicate. Only the explicit overall continuation/time safety budget prevents loops—there is no one-kick-per-attempt cap.
  • A normal final answer, manual compact, overflow retry, queued continuation, and non-WG human Pi session are must-not-over-trigger cases.
  • The test plan requires a real installed wrapper + embedded plugin + Pi JSON flow and a failing pre-fix trace.
  • The design names precise production files, schema/compat implications, migration behavior, and rollback/disable controls; git diff --check passes.

Depends on

Required by

✓ Messages 6 messages (replied)

  1. #1user2026-08-05T20:53:17.384809290+00:00delivered
    Use upstream issue pi#6424 as the precise defect. Strong candidate architecture to assess: WG watchdog owns durable permit/exactly-once/terminal suppression; embedded Pi plugin owns in-process delivery via sendUserMessage only after session_compact + settled/idle/no-pending checks. Do not adopt this without reconciling JSON-mode exit and crash acknowledgement.
  2. #2design-wg-pi-compaction-kick2026-08-06T06:22:59.321678479+00:00read
    Acknowledged — I will treat pi#6424 as the exact defect and assess the proposed split protocol, explicitly resolving JSON-mode exit plus pre/post-permit/send/ack crash behavior rather than assuming in-process delivery survives.
  3. #3design-wg-pi-compaction-kick2026-08-06T06:40:42.115437761+00:00read
    Done — commit 439966eb applies your #6424 direction but rejects the post-settled send variant after reconciling JSON exit. The design uses lifecycle/watchdog authorize+permit and embedded custom-followUp delivery during awaited successful session_compact, with custom message_start ack and an explicit Uncertain/no-redelivery crash state.
  4. #4design-wg-pi-compaction-kick2026-08-06T06:42:50.209765871+00:00read
    Operator repair needed for completion only:  rejects the valid manifest because done dependency  has no immutable completion candidate. Worker capability cannot cross-task repair it. Design commit 439966eb is complete/pushed/validated.
  5. #5design-wg-pi-compaction-kick2026-08-06T06:42:58.649116170+00:00read
    Operator repair needed for completion only: wg submit rejects the valid manifest because done dependency .assign-design-wg-pi-compaction-kick has no immutable completion candidate. Worker capability cannot cross-task repair it. Design commit 439966eb is complete, pushed, and validated.
  6. #6user2026-08-06T06:56:16.356096590+00:00delivered
    Design correction from operator: "exactly once" means exactly once PER distinct qualifying successful threshold-compaction occurrence, not once per task/attempt. A long task may compact repeatedly and must recover after every qualifying occurrence while WG work remains unresolved. Remove the draft's default dedicated cap of one per attempt. Key candidate/action identity must include a monotonic compaction occurrence/generation (or equivalent durable unique event identity), so successive threshold compactions authorize distinct kicks and duplicate delivery/events for the same occurrence remain idempotent. Retain only the existing explicit finite overall continuation/time safety budget (or a clearly justified configurable overall bound), with loud HeldOperatorRequired when exhausted. The two-successive-compactions hardening case must produce two kicks, one per compaction, not suppress the second as already-used.

Log