jbr870/devwork-skills
1
0
Fork 0
Code Issues 3 Pull requests Projects Releases Packages Wiki Activity Actions

S2 gap: /resolve steers to /qa-fix inside a sequencer session (discards retained reasoning) #8

New issue
Open
opened 2026-07-01 07:50:53 +00:00 by jbr870 · 0 comments
jbr870 commented 2026-07-01 07:50:53 +00:00
Owner
Copy link

The gap

Inside a single-context sequencer session (/qa-code, /qa-e2e, …), the S1/S2 "disposition-resume"
work sharpened the sequencer's own STOP/next-step text to say: after /resolve, re-run /qa-<d> in
the same conversation (it skips the re-validate and resumes at the fix, keeping the validator's reasoning
live) and do not use /qa-fix <d> (that forks a fresh sub-agent and discards the reasoning).

But /resolve was not updated. When it settles a fix-now disposition, its per-decision "next step"
hint still emits:

→ Next: /qa-fix <d> — the next fix round picks it up and applies …

So within one sequencer session the two surfaces point in opposite directions: the sequencer says
"re-run /qa-<d> here," /resolve says "go run /qa-fix <d>." An operator following /resolve literally
defects to the orchestrator sub-agent — the exact context-discard S2 exists to prevent.

Why it matters / scope

  • Structural, not a one-off. It fires on every path-(c) fix-now resume in a sequencer session,
    across all six domains and both lifecycle shapes.
  • Currently masked by the model. In the verity #99 qa-e2e run the model bridged it (stayed in context
    and re-ran /qa-e2e correctly despite /resolve recommending /qa-fix e2e), so it didn't bite — but
    it's load-bearing on model judgment, which S2 was meant to remove.
  • S2 patched the six sequencers' STOP text; /resolve's fix-now hint (and any fix-workflow "next step"
    text it echoes) is sequencer-unaware.

Where it surfaced

Dogfooding verity #99 (doubts-mcp), /qa-e2e round. After resolving D-PO-99-7-2 (E2E-2 mobile
buttons) → fix-now, /resolve printed "→ Next: /qa-fix e2e" while the sequencer's own STOP text (from
the same session) correctly said "re-run /qa-e2e in this same conversation; do not use /qa-fix e2e."

Candidate fix (not committed)

Two options, decide at S1 extraction time (this issue is a placeholder until then, tied to the
qa-domain-sequencer.md extraction in the tracker):

  1. Make the hint sequencer-aware. When the decision originates from a sequencer PO (detectable from the
    posting skill / PO shape), /resolve emits the same-conversation re-run guidance instead of /qa-fix.
  2. Sequencer overrides it. The sequencer suppresses/replaces /resolve's next-step hint in its own
    summary (partly already true — the sequencer's STOP text is correct; the gap is only the /resolve
    output the operator sees between the stop and the re-run).

Prefer folding this into the shared-sequencer extraction rather than hand-patching /resolve now, so the
resume messaging lives in one place with the disposition-resume logic.

Reference

Tracker: sdlc-qa-single-context-sequencer.md — "Evidence — verity #99" (learning #2) and TODO #2 (S1
extraction, refinement (b)).

## The gap Inside a **single-context sequencer** session (`/qa-code`, `/qa-e2e`, …), the S1/S2 "disposition-resume" work sharpened the *sequencer's own* STOP/next-step text to say: after `/resolve`, **re-run `/qa-<d>` in the same conversation** (it skips the re-validate and resumes at the fix, keeping the validator's reasoning live) and **do not** use `/qa-fix <d>` (that forks a fresh sub-agent and discards the reasoning). But `/resolve` was **not** updated. When it settles a **fix-now** disposition, its per-decision "next step" hint still emits: > → *Next: `/qa-fix <d>`* — the next fix round picks it up and applies … So within one sequencer session the two surfaces point in **opposite directions**: the sequencer says "re-run `/qa-<d>` here," `/resolve` says "go run `/qa-fix <d>`." An operator following `/resolve` literally defects to the orchestrator sub-agent — the exact context-discard S2 exists to prevent. ## Why it matters / scope - **Structural, not a one-off.** It fires on **every** path-(c) **fix-now** resume in a sequencer session, across all six domains and both lifecycle shapes. - **Currently masked by the model.** In the verity #99 qa-e2e run the model bridged it (stayed in context and re-ran `/qa-e2e` correctly despite `/resolve` recommending `/qa-fix e2e`), so it didn't bite — but it's load-bearing on model judgment, which S2 was meant to remove. - S2 patched the six sequencers' STOP text; `/resolve`'s fix-now hint (and any fix-workflow "next step" text it echoes) is sequencer-unaware. ## Where it surfaced Dogfooding **verity #99 (doubts-mcp)**, `/qa-e2e` round. After resolving `D-PO-99-7-2` (E2E-2 mobile buttons) → fix-now, `/resolve` printed *"→ Next: `/qa-fix e2e`"* while the sequencer's own STOP text (from the same session) correctly said "re-run `/qa-e2e` in this same conversation; do not use `/qa-fix e2e`." ## Candidate fix (not committed) Two options, decide at S1 extraction time (this issue is a placeholder until then, tied to the `qa-domain-sequencer.md` extraction in the tracker): 1. **Make the hint sequencer-aware.** When the decision originates from a sequencer PO (detectable from the posting skill / PO shape), `/resolve` emits the same-conversation re-run guidance instead of `/qa-fix`. 2. **Sequencer overrides it.** The sequencer suppresses/replaces `/resolve`'s next-step hint in its own summary (partly already true — the sequencer's STOP text is correct; the gap is only the `/resolve` output the operator sees *between* the stop and the re-run). Prefer folding this into the shared-sequencer extraction rather than hand-patching `/resolve` now, so the resume messaging lives in one place with the disposition-resume logic. ## Reference Tracker: `sdlc-qa-single-context-sequencer.md` — "Evidence — verity #99" (learning #2) and TODO #2 (S1 extraction, refinement (b)).
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
qa-sequencer-disposition-resume
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
jbr870/devwork-skills#8
No description provided.