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>

test/fixtures/forcing-finding-seeds.ts

@@ -120,3 +120,59 @@ export const FORCING_BATCHING_ENG = [
   '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');