Files
gstack/test/fixtures/forcing-finding-seeds.ts
T
Garry Tan a6fb31726c v1.48.0.0 feat: AskUserQuestion split rule + runtime AUTO_DECIDE carve-out (#1740)
* feat(preamble): add "Handling 5+ options — split, never drop" rule

Agents repeatedly hit Conductor's 4-option AskUserQuestion cap and
silently drop one option to fit, shrinking the user's decision space.
This rule names the bug and gives two compliant shapes: batch into
≤4-groups (for coherent alternatives) or split into N sequential
per-option calls (for independent scope items, default).

Inline preamble subsection is ~15 lines (rule + buckets + pointer).
Full reference with worked examples, Hold/dependency semantics, and
final-summary validation lives in docs/askuserquestion-split.md.
The agent loads the docs file on demand when N>4.

Per-option call shape: D<N>.k header, ELI10, Recommendation, kind-note
(no completeness score — decision actions, not coverage), Include /
Defer / Cut / Hold buckets. Hold stops the chain immediately; the
final D<N>.final call validates dependencies and confirms the
assembled scope.

question_ids: <skill>-split-<option-slug> (kebab-case ASCII, ≤64
chars). Also fixes orphan "12. " prefix on the existing CJK rule.

Tier-2+ skills inherit via the existing resolver. SKILL.md regenerated
for all 41 affected skills + 3 golden fixtures. Net diff per SKILL.md:
~34 lines (vs ~110 for the full inline version).

6 tests pin the inline contract (4-option cap, buckets, D-numbering,
docs pointer, runtime AUTO_DECIDE gate reference, orphan 12 regression).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* feat(question-pref): runtime AUTO_DECIDE carve-out for *-split-* ids

Split chains (per-option AskUserQuestion calls emitted by the new
"Handling 5+ options" rule) must never be silently auto-approved
via /plan-tune preferences. The user's option set is sacred.

Layer 1 (mechanism): unique <skill>-split-<option-slug> ids prevent
cross-option preference leakage. Layer 2 (this commit): the runtime
checker `gstack-question-preference --check` detects any id matching
*-split-* and forces ASK_NORMALLY even when never-ask or
ask-only-for-one-way preferences exist for that exact id. An
explanatory note tells the user their preference was bypassed and why.

7 tests pin the carve-out: no-pref baseline, never-ask override,
explanatory note text, ask-only-for-one-way override, always-ask
(no note), non-split id containing "split" word (negative case for
regex specificity), multi-skill split id formats.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* test(e2e): split-overflow regression for /plan-ceo-review

Periodic-tier E2E test that catches the original failure mode the
user complained about: 5+ options for ONE decision must split into
N sequential AskUserQuestion calls, not drop one to fit Conductor's
4-option cap.

Fixture: 5 independent chat-platform integration candidates
(Slack/Discord/Teams/Telegram/Mattermost), each carrying its own
include/defer/cut decision. Floor = 4 review-phase AUQs (standard
[N-1] tolerance band). Pre-fix "drop to 4 + 1 dropped" fails this
floor.

Wired into test/helpers/touchfiles.ts: tier periodic, depends on
plan-ceo-review/**, the new preamble subsection, the question-pref
binary (for the carve-out), and the runner helper. touchfiles.test.ts
expected count bumped 21 → 22 to account for the new entry.

Cost: ~$0.30/run when EVALS_TIER=periodic. Skips silently otherwise.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* chore: post-merge regen + rebase size-budget baseline to v1.47.0.0

After merging origin/main (v1.45 → v1.47), three things needed cleanup:

1. spec/SKILL.md (main's new skill) regenerated to include our split-vs-drop
   preamble subsection — same mechanical regen as the other 41 tier-2+ skills.
2. Three golden ship fixtures refreshed to capture main's GSTACK_PLAN_MODE
   block + /spec routing entry + jargon-list.json refactor.
3. docs/skills.md — added /spec table row that main's PR (#1698/#1733) shipped
   without. Pre-existing failure on main; this PR catches and fixes.

Also rebased test/skill-size-budget.test.ts from v1.44.1 → v1.47.0.0 baseline.
Main's v1.46 (catalog tokens trim) + v1.47 (/spec skill) pushed the v1.44.1
anchor past the 5% ratchet to ×1.059 — pre-existing failure on main. This
PR captures a fresh parity-baseline-v1.47.0.0.json and re-anchors the test
there. Historical v1.44.1.json and v1.46.0.0.json retained in test/fixtures/
for reference. Our subsection contributes ~0.1% of the post-rebase corpus.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* chore: bump version and changelog (v1.48.0.0)

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-26 23:43:07 -07:00

179 lines
8.1 KiB
TypeScript

/**
* Per-skill draft-plan seeds engineered to surface at least one
* review-phase finding in the corresponding plan-* review skill.
*
* Used by gate-tier finding-floor tests
* (test/skill-e2e-plan-{eng,ceo,design,devex}-finding-floor.test.ts) as
* the minimum-cost regression for the May 2026 transcript bug:
* "/plan-eng-review reviewed a real PR diff, wrote a multi-section
* review plan to ~/.claude/plans/ and called ExitPlanMode without
* ever firing AskUserQuestion."
*
* Each seed is small and pre-loaded with one obvious finding the
* matching skill cannot honestly miss. Floor tests assert
* `reviewCount >= 1` — i.e., the model fired at least one review-phase
* AUQ before reaching plan_ready / completion_summary / ceiling.
*
* Each seed includes the standard "write your plan-mode plan to /tmp/…"
* preamble that the existing periodic finding-count fixtures use, so
* the agent has a concrete plan-file target. The /tmp path is unique
* per skill to avoid collisions if floor tests run in parallel.
*
* For a deeper [N-1, N+2] count band assertion, see the periodic
* test/skill-e2e-plan-{X}-finding-count.test.ts fixtures.
*/
export const FORCING_FLOOR_ENG = [
'Please review this plan thoroughly. As you go, write your plan-mode plan to /tmp/gstack-test-plan-eng-floor.md (use Edit/Write to that exact path).',
'',
'# Plan: Add request-id propagation across services',
'',
'## Architecture',
"We'll roll a custom UUIDv7 generator inline in each service rather than",
"use Node's crypto.randomUUID() built-in. Same shape, but we want full",
'control over the entropy source for "future flexibility" — no concrete',
'reason yet.',
].join('\n');
export const FORCING_FLOOR_CEO = [
'Please review this plan thoroughly. As you go, write your plan-mode plan to /tmp/gstack-test-plan-ceo-floor.md (use Edit/Write to that exact path).',
'',
'# Plan: Launch a "developer-friendly" pricing tier',
'',
'## Goal',
'Increase developer adoption.',
'',
'## Success metric',
'More signups.',
'',
'## Premise',
"We haven't talked to any developers about whether the current pricing",
'is actually a barrier. The team agreed it "feels like" it should be cheaper.',
].join('\n');
export const FORCING_FLOOR_DESIGN = [
'Please review this plan thoroughly. As you go, write your plan-mode plan to /tmp/gstack-test-plan-design-floor.md (use Edit/Write to that exact path).',
'',
'# Plan: Marketing landing page',
'',
'## Layout',
'All headings, taglines, and body copy will be center-aligned for a',
'"clean modern look." The hero h1 sits 8px above the subhead with no',
'breathing room; the CTA button is the same visual weight as a',
'secondary "Learn more" link directly beside it.',
].join('\n');
export const FORCING_FLOOR_DEVEX = [
'Please review this plan thoroughly. As you go, write your plan-mode plan to /tmp/gstack-test-plan-devex-floor.md (use Edit/Write to that exact path).',
'',
'# Plan: SDK quickstart docs',
'',
'## Onboarding flow',
'Step 1: clone the repo.',
'Step 2: install bun manually if not present.',
'Step 3: copy .env.example to .env and fill in 8 environment variables.',
'Step 4: run database migrations against your local Postgres.',
'Step 5: start the dev server.',
'Step 6: open the docs in a separate tab.',
'Step 7: register an API key by emailing the team.',
'Step 8: paste the key into your .env, restart the server, then make',
'your first SDK call.',
'',
'No quickstart command, no hosted sandbox, no copy-pasteable curl example.',
].join('\n');
/**
* Multi-finding batching regression seed (periodic tier).
*
* Mirrors the May 2026 transcript bug shape: 4 distinct non-trivial findings
* spread across plan-eng-review's standard sections (Architecture, Code
* Quality, Tests, Performance). Each finding is independent — there is no
* legitimate reason to batch them into a single AskUserQuestion.
*
* Used by test/skill-e2e-plan-eng-multi-finding-batching.test.ts to assert
* the agent fires >= 3 review-phase AUQs (i.e., does NOT batch them into a
* "## Decisions to confirm" section + ExitPlanMode). Floor of 3 (not 4) is
* the [N-1] tolerance from the existing finding-count band convention.
*/
export const FORCING_BATCHING_ENG = [
'Please review this plan thoroughly. As you go, write your plan-mode plan to /tmp/gstack-test-plan-eng-batching.md (use Edit/Write to that exact path).',
'',
'# Plan: Add background job retry framework',
'',
'## Architecture',
"We'll roll a custom exponential-backoff scheduler inline in each worker",
"rather than use the existing job library's built-in retry hooks. Same",
'shape as the library version, but we want full control over the curve.',
'',
'## Code quality',
'The retry envelope (compute delay, log attempt, dispatch) is duplicated',
'across 5 worker files with copy-pasted bodies. We will leave the',
'duplication for now and refactor "later."',
'',
'## Tests',
'The existing `processWebhookJob()` flow gets rewritten as part of this',
'change. No regression test for the prior at-most-once delivery guarantee',
'is planned.',
'',
'## Performance',
'On every retry we re-fetch the full job payload from the database, then',
'iterate the payload to recompute the dependency graph. Could cache the',
'graph on the first attempt; not planned.',
].join('\n');
/**
* Split-overflow regression seed (periodic tier).
*
* Catches the original failure mode the user complained about: when the
* agent has 5+ options for ONE conceptual decision, it must split into N
* sequential AskUserQuestion calls (or batch into compatible ≤4-groups),
* NOT drop an option arbitrarily to fit Conductor's 4-option cap.
*
* Fixture shape: 5 independent platform-integration candidates for ONE
* scope decision. Each is independent (no dependencies between them) so
* the natural compliant shape is a per-option split chain at parent D<N>.
*
* Used by test/skill-e2e-plan-ceo-split-overflow.test.ts to assert the
* agent fires >= 4 review-phase AUQs (floor uses the standard [N-1]
* tolerance band, accounting for one expected scope-reduction-or-merge
* call before the per-option chain begins).
*
* Pre-fix behavior: agent fires 1 AUQ with 4 options, "trims" the 5th
* via prose ("E5 is the largest lift and a natural follow-up; moving to
* TODOs without asking"). That's the bug. Floor of 4 detects it.
*/
export const FORCING_SPLIT_OVERFLOW_CEO = [
'Please review this plan and help me decide scope. Write your plan-mode plan to /tmp/gstack-test-plan-ceo-split-overflow.md (use Edit/Write to that exact path).',
'',
'# Plan: Pick which chat-platform integrations to ship this quarter',
'',
'We have engineering bandwidth for at most 2-3 integrations this quarter.',
'I need your help deciding which to prioritize. Below are 5 candidates,',
'each fully independent of the others (no shared infrastructure, no',
'dependencies between them). For each, the user can independently decide:',
'include in this scope, defer to next quarter, or cut entirely.',
'',
'## E1) Slack — DM bot for incident alerts',
'Build cost: ~2 weeks. Existing Slack auth flow we can reuse. High user',
'demand (top customer request in Q2 survey, ~40% of asks).',
'',
'## E2) Discord — guild bot for community channels',
'Build cost: ~3 weeks. Greenfield integration, no existing auth. Medium',
'demand (~15% of asks, but loud community).',
'',
'## E3) Microsoft Teams — webhook + bot framework',
'Build cost: ~4 weeks. Enterprise customers specifically asked for this.',
'Highest revenue impact per user but smallest user count (~5% of asks).',
'',
'## E4) Telegram — bot API integration',
'Build cost: ~1 week. Simplest API surface. Low strategic value but',
'cheap win (~8% of asks, mostly from international users).',
'',
'## E5) Mattermost — REST plugin',
'Build cost: ~2 weeks. Self-hosted enterprise users. Niche but locked-in',
'segment (~3% of asks but all from high-ARR accounts).',
'',
'Please walk me through each candidate and help me decide include/defer/cut',
'per option. I want individual decisions per candidate, not a bundled pick.',
].join('\n');