RFC: opt-in context-pressure wrap-up suppression and durable pending-action carry-forward for auto-mode

[gunish]

Summary

Two small-but-important auto-mode improvements worked well in local use and look upstreamable if split cleanly:

1. Opt-in suppression of context-pressure wrap-up for repos that prefer smaller task decomposition over forced closeout pressure.
2. Durable carry-forward of required unfinished work from completed task summaries into replanning, so required leftovers do not disappear into prose.

I believe these should be discussed as two separate PRs, but they are related enough to start from one issue/RFC because both touch GSD auto-mode behavior.

Problem

1) Context-pressure wrap-up can bias auto-mode toward premature closeout

Today the context-pressure continue-here monitor in src/resources/extensions/gsd/auto-timers.ts emits:

• customType: "gsd-auto-wrapup"
• "**CONTEXT BUDGET WARNING — wrap up this unit now.**"

That is sensible as a default, but some repos intentionally prefer a different strategy:

• split work into smaller follow-up tasks earlier
• keep timeout supervision intact
• avoid context pressure itself becoming a strong closeout steer

An opt-in repo preference would let those repos choose that mode explicitly without changing defaults for anyone else.

2) Required unfinished work can be documented but still not become continuation state

GSD already has durable blocker-based replanning via blocker_discovered: true, and it already has carry-forward context from prior task summaries.

What is still missing is a lightweight, durable way for a completed task to say:

• "this task is complete enough to close out honestly"
• and
• "there is still required follow-up work that must be chained into later tasks or a replan"

Right now that kind of leftover work can live in prose, but it does not become a first-class continuation signal.

Proposal

PR 1 — opt-in context-pressure wrap-up suppression

Add a typed repo preference such as:

auto_supervisor:
  disable_context_pressure_wrapup: true

Behavior:

• disables only the context-pressure continue-here / wrap-up monitor
• keeps soft/idle/hard timeout supervision intact
• preserves default behavior unless explicitly enabled

Why this is a good first PR:

• opt-in only
• small blast radius
• easy to test
• no default behavior change

PR 2 — pending-actions carry-forward + replan chaining

Add a stable markdown convention inside task summaries, likely in ## Known Issues:

Pending actions:
- action 1
- action 2

Then:

• parse those pending actions from completed task summaries
• include them in carry-forward context for later task execution
• route the slice into replanning-slice before continuing when required pending actions remain
• if no incomplete tasks remain, allow replanning to add a new task rather than falling straight to slice summarization

Why this shape:

• lighter than adding a new tool/API field immediately
• fits GSD’s artifact-driven design
• backward-compatible with existing summaries

Important related issue

There is already a closely related upstream bug:

• DB-backed replan loop protection blocks second+ replans on same slice #2479 — DB-backed replan loop protection blocks second+ replans on same slice

That issue matters here because pending-actions chaining should not use slice-wide/coarse loop protection. If a later completed task introduces new required carry-forward work, a prior replan on the same slice should not suppress the new legitimate replan.

My current view is:

• PR 2 should probably use task-scoped or trigger-scoped loop protection
• that would likely complement or partially supersede the coarse slice-wide guard discussed in DB-backed replan loop protection blocks second+ replans on same slice #2479

Benefits

• reduces premature closeout pressure in repos that explicitly opt in
• encourages smaller task decomposition without losing continuity
• makes required unfinished work durable and actionable
• prevents slices from silently completing while known required follow-up still exists
• builds on existing blocker/replan seams instead of inventing a new workflow layer

Scope / non-goals

• Do not change default timeout values globally
• Do not change default context-pressure behavior globally
• Do not add a broad new orchestration abstraction
• For PR 2, avoid adding a new gsd_task_complete.pendingActions API field unless maintainers prefer that over the markdown convention

Suggested review path

1. Confirm whether the opt-in wrap-up suppression is acceptable as a core preference
2. Confirm whether Pending actions: in summaries is an acceptable first durable contract
3. If yes, land as two PRs:
   • PR 1: context-pressure opt-out
   • PR 2: pending-actions carry-forward + replan chaining

If this direction sounds right, I can open the two PRs separately after forking and rebuilding the changes against current main.

[gunish]

Split the RFC into two PRs:

• PR feat(gsd-extension): add opt-in context-pressure wrapup disable #3411 — opt-in context-pressure wrap-up suppression
• PR feat(gsd-extension): carry forward pending actions into replanning #3413 — pending-action carry-forward + automatic replanning

Both branches are locally verified (typecheck, focused tests, broader derive-state/prompt tests, build).

Current hosted CI status on both PRs: the lightweight PR workflows ran, but the main CI workflow is currently in GitHub action_required with no jobs started, which looks like the standard maintainer approval gate for forked PR workflows rather than a contributor-side code failure.

So from the contributor side the next step is maintainer review / workflow approval.

[jeremymcs]

This project has made rapid advancements since this was posted. If you're still experiencing this issue, please make sure you're on the latest version and re-open.