mirror of
https://github.com/garrytan/gstack.git
synced 2026-05-31 07:19:31 +02:00
a6fb31726c
* 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>
179 lines
8.1 KiB
TypeScript
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');
|