From d36338b578eb61e358761ee5f50af95d35abd71b Mon Sep 17 00:00:00 2001 From: Sinabina Date: Thu, 23 Jul 2026 11:47:33 -0700 Subject: [PATCH 1/2] fix: time constraints cap scale and bind the whole chain (#886) A /plan run on a hackathon-demo ask burned 18 AskUserQuestion rounds: the Scale budgets never reached the chained eng/design reviews (separate invocations with no Scale header, and plan-design-review/design-review/ review were not #886 targets), the collected time box was never used, and reviews spent rounds on ceremony (re-confirming handoff-named targets, one round per finding, optional-extras offers). - Overlay #886 now targets review, plan-design-review, and design-review; the binding scale inherits across chain handoffs; an explicit user time constraint caps scale at session/hobby regardless of higher vectors; obvious in-boundary fixes are applied and reported, not asked; question rounds are batched and never spent on ceremony. - The /plan Build scale section makes the time-constraint ceiling explicit and requires every handoff to carry scale + time box. - Shared judgment contract gains infer-don't-ask and time-budget clauses for all six dispatchers. - EXPECTED_PARITY_CHECKS 5027 -> 5033 (2 per newly targeted module). Evidence: ~/.claude/projects/-Users-sinabina-orca-projects-SwipeMusic/1b922b73-*.jsonl Co-Authored-By: Claude Fable 5 --- scripts/gstack2/bug-fix-overlays.ts | 25 ++++++++++++++++++++----- scripts/gstack2/generate-skill-tree.ts | 8 +++++++- scripts/gstack2/run-parity.ts | 6 ++++-- 3 files changed, 31 insertions(+), 8 deletions(-) diff --git a/scripts/gstack2/bug-fix-overlays.ts b/scripts/gstack2/bug-fix-overlays.ts index 291658decf..9ff34874f8 100644 --- a/scripts/gstack2/bug-fix-overlays.ts +++ b/scripts/gstack2/bug-fix-overlays.ts @@ -346,21 +346,29 @@ At the Phase 5 approval gate, print the full design-doc body as direct assistant pr: 886, url: 'https://github.com/garrytan/gstack/issues/886', title: 'Scale planning machinery to the printed build scale', - targets: ['office-hours', 'plan-ceo-review', 'plan-eng-review', 'plan-devex-review', 'spec', 'autoplan'], + targets: ['office-hours', 'plan-ceo-review', 'plan-eng-review', 'plan-devex-review', 'spec', 'autoplan', 'review', 'plan-design-review', 'design-review'], anchor: 'GSTACK2_FIX_886_PROPORTIONAL_PLANNING', body: `### Proportional planning for the printed build scale -The /plan dispatcher prints a \`Scale:\` header line classified from fifteen build-scale vectors (its Build scale section). This rule authorizes every planning specialist to size its machinery to that scale while keeping every STOP gate and approval boundary; a polite user answering every question is not evidence the full machinery is wanted, and the user can always ask for the complete treatment. +The /plan dispatcher prints a \`Scale:\` header line classified from fifteen build-scale vectors (its Build scale section). This rule authorizes every planning and review specialist to size its machinery to that scale while keeping every STOP gate and approval boundary; a polite user answering every question is not evidence the full machinery is wanted, and the user can always ask for the complete treatment. + +The binding scale comes from the first available source: the printed \`Scale:\` header, a chain handoff that names a scale or time box, or on-the-spot classification from the prompt and cheap repository evidence. An explicit user time constraint is a ceiling, not one vector among fifteen: work that must fit one sitting caps the scale at \`session\`, and a day-or-two deadline caps it at \`hobby\`, regardless of higher vectors. A chained invocation inherits the upstream scale and time box without re-asking, and every handoff it emits carries them forward. - \`session\` and \`hobby\`: batch every question the initial prompt left unanswered into one AskUserQuestion round (two rounds for hobby); skip web or landscape research, outside voices, second opinions, and visual sketches unless the user asks (privacy gates are unchanged whenever they run); cap any adversarial or spec review loop at one iteration; keep the decision artifact near one page with next steps sized in hours (session) or days (hobby), never a phased multi-week roadmap or a distribution plan the user did not ask for. - \`project\`: run the specialist's default workflow, batching question rounds where its source authorizes smart skips; size the roadmap in weeks. - \`product\` and \`venture\`: the full specialist workflow and its complete question pressure apply; this rule removes nothing. - Never run a questioning round merely to classify scale. Classify from the prompt and cheap repository evidence, defaulting unknown vectors low; a specialist's own later questions may raise the scale mid-session, and an upgrade restores the full workflow from that point. +Review specialists spend question rounds on decisions, not ceremony — at every scale, and sharpest at \`session\`/\`hobby\`: + +- When the handoff or prompt names the review target unambiguously, print it on the Target line and proceed. Re-confirming a target the chain already fixed is not a STOP gate; the target gate exists for genuinely ambiguous targets. +- A finding whose fix is obvious and inside the authorized mutation boundary is applied and reported in a compact applied-changes list. Question rounds are reserved for genuine forks — scope changes, user-visible tradeoffs, anything hard to reverse — and are batched, up to four questions per round, never one round per finding. +- Optional extras (opening resources, offering the next review or a follow-up phase) never get their own question round at \`session\`/\`hobby\`: fold them into an existing round or a one-line closing offer. + For office-hours specifically: at session or hobby scale, batch the Phase 2B questions (this refines the one-at-a-time rule, whose pressure exists for startup diagnostics), default-skip the Phase 2.75 landscape search, gate the visual sketch and outside design voices on an explicit ask, and cap the Spec Review Loop at one iteration.`, regression: { - input: { audience: 'self', users: 'none', commercial: 'none', deployment: 'none', horizon: 'session', stakes: 'fun', extensibility: 'fixed' }, - expected: { scale: 'session', questions_batched: true, question_rounds_max: 1, web_search: 'on-request', outside_voices: 'on-request', review_iterations_max: 1, step_unit: 'hours' }, + input: { audience: 'public', users: 'handful', commercial: 'none', deployment: 'none', horizon: 'session', stakes: 'fun', maintenance: 'throwaway', stated_time_constraint: 'one-sitting', handoff_target: 'docs/designs/hackathon-demo.md', minor_findings: 4 }, + expected: { scale: 'session', time_constraint_caps_scale: true, questions_batched: true, question_rounds_max: 1, web_search: 'on-request', outside_voices: 'on-request', review_iterations_max: 1, step_unit: 'hours', target_confirmation_round: false, minor_findings_applied_not_asked: true }, }, }, { @@ -647,20 +655,27 @@ export function evaluateBugFixRegression(pr: number, rawInput: unknown): Record< compliance: { none: 0, some: 2, audited: 4 }, }; // Highest tier any vector demands wins; unknown vectors default low. - const rank = Object.entries(ranks).reduce( + let rank = Object.entries(ranks).reduce( (max, [vector, levels]) => Math.max(max, levels[String(input[vector] ?? '')] ?? 0), 0, ); + // An explicit user time constraint is a ceiling, not one vector among fifteen. + const ceilings: Record = { 'one-sitting': 0, hackathon: 0, hours: 0, 'day-or-two': 1, days: 1 }; + const cap = ceilings[String(input.stated_time_constraint ?? '')]; + if (cap != null) rank = Math.min(rank, cap); const scale = ['session', 'hobby', 'project', 'product', 'venture'][rank]; const small = rank <= 1; return { scale, + time_constraint_caps_scale: cap != null, questions_batched: rank <= 2, question_rounds_max: small ? rank + 1 : null, web_search: small ? 'on-request' : 'privacy-gated-offer', outside_voices: small ? 'on-request' : 'offer', review_iterations_max: small ? 1 : 3, step_unit: ['hours', 'days', 'weeks', 'stage-appropriate', 'stage-appropriate'][rank], + target_confirmation_round: input.handoff_target == null, + minor_findings_applied_not_asked: small, }; } default: diff --git a/scripts/gstack2/generate-skill-tree.ts b/scripts/gstack2/generate-skill-tree.ts index 74e5251da3..36e025b4cb 100644 --- a/scripts/gstack2/generate-skill-tree.ts +++ b/scripts/gstack2/generate-skill-tree.ts @@ -225,6 +225,10 @@ Classify the request on fifteen scale vectors before any questioning begins, fro Vectors: audience (self → friends/team → public), expected users (none → handful → many), commercial intent (none → maybe → core), deployment target (none/local → hosted → production), time horizon (one sitting → days → weeks → months+), maintenance expectation (throwaway → kept → maintained), integration surface (standalone → consumes APIs → exposes APIs/multi-service), extensibility ask (fixed → configurable → customizable platform), data sensitivity (none → personal → regulated), failure stakes (lost fun → annoyance → money/trust/safety), team (solo → few → org), codebase (greenfield → existing repo → legacy production), reversibility (discardable → migrations/breaking changes), distribution (private → shared → published), compliance (none → some → audited). The highest tier any vector demands wins: \`session\` (all vectors low — one sitting, for fun, self only), \`hobby\` (kept personal tool, days), \`project\` (shared or in a real repo, weeks), \`product\` (external users, hosted, revenue intent), \`venture\` (startup ambition, platform/API surface, team, months+). "A cool space animation in my terminal" is session-scale. "A startup with customizable APIs" is venture-scale. Print the result on the header's Scale line with the two or three vectors that decided it. + +An explicit user time constraint is a ceiling, not one vector among fifteen: work that must fit one sitting (a hackathon demo, a stated hour count, "before my flight") caps the scale at \`session\`, and a day-or-two deadline caps it at \`hobby\`, no matter how public the audience or how ambitious the idea. The user's clock outranks every ambition vector. Print the constraint with the scale: \`Scale: session (hackathon, one sitting)\`. + +The scale binds the whole chain, not just this invocation. Every handoff to a chained review or specialist names the scale and any time box, and the receiving workflow applies its proportional-planning port to the inherited scale without re-asking or re-classifying upward. ` : ''; @@ -476,7 +480,9 @@ function sharedJudgmentContract(): string { '7. Preview artifacts and diffs before approval. Approval remains mandatory before merge, deploy, destructive mutation, or spending.', '8. Match the user language. Empty or contradictory evidence blocks confident success.', '9. Recommendations remain traceable downstream, including what evidence would change them.', - '10. The user makes the final decision.', + '10. Ask only what cannot be inferred. Question rounds are for decisions that are consequential and still open after the prompt, the repository, and platform convention are consulted; infer the rest, state each inferred default in one line, and batch what remains. Never spend a round confirming what a handoff already names or offering optional extras.', + '11. A user-stated time constraint binds every phase and every chained skill. Skip or compress optional phases that do not fit it, noting each skip in one line.', + '12. The user makes the final decision.', '', ].join('\n'); } diff --git a/scripts/gstack2/run-parity.ts b/scripts/gstack2/run-parity.ts index fe289dcfcf..7b93727368 100644 --- a/scripts/gstack2/run-parity.ts +++ b/scripts/gstack2/run-parity.ts @@ -24,8 +24,10 @@ const ALLOWED_DISPOSITIONS = new Set(['VERBATIM_PORT', 'MECHANICAL_PORT', 'JUDGM // targets) added 13 more. The design-doc concision overlay for issue #2000 // (27 -> 28, office-hours only) added 5 more. The self-contained-questions // overlay for issue #879 (28 -> 29, targets '*', all 55 modules) added 113 -// more (2 per module + 3 regression checks). -export const EXPECTED_PARITY_CHECKS = 5027; +// more (2 per module + 3 regression checks). Extending the #886 overlay to +// the review specialists (review, plan-design-review, design-review) added +// 6 more (2 per newly targeted module). +export const EXPECTED_PARITY_CHECKS = 5033; function sha256(value: string | Uint8Array): string { return createHash('sha256').update(value).digest('hex'); From 0eb15b06d00ea04fb5b57a6280b99681c6d744b7 Mon Sep 17 00:00:00 2001 From: Sinabina Date: Thu, 23 Jul 2026 11:47:39 -0700 Subject: [PATCH 2/2] chore: regenerate gstack2 tree for chain-wide proportionality (#886) Co-Authored-By: Claude Fable 5 --- docs/gstack-2/JUDGMENT-PARITY.md | 2 +- docs/gstack-2/JUDGMENT-PROVENANCE.json | 10 ++++++-- docs/gstack-2/SKILL-MIGRATION.md | 6 ++--- evals/parity/contracts/design-review.json | 1 + .../parity/contracts/plan-design-review.json | 1 + evals/parity/contracts/review.json | 1 + evals/parity/manifest.json | 10 ++++++-- evals/parity/regressions/pr-886.json | 21 +++++++++++----- .../transcripts/deterministic/ceo-review.json | 2 +- .../deterministic/code-review.json | 7 ++++++ .../deterministic/design-review.json | 7 ++++++ .../transcripts/deterministic/dx-review.json | 2 +- .../deterministic/engineering-review.json | 2 +- .../deterministic/office-hours.json | 2 +- .../deterministic/specification.json | 2 +- evals/parity/transcripts/policy-units.json | 18 ++++++------- skills/debug/references/SHARED-JUDGMENT.md | 4 ++- skills/design/references/SHARED-JUDGMENT.md | 4 ++- .../design/references/legacy/design-review.md | 25 +++++++++++++++++++ .../references/legacy/plan-design-review.md | 25 +++++++++++++++++++ skills/plan/SKILL.md | 4 +++ skills/plan/references/SHARED-JUDGMENT.md | 4 ++- skills/plan/references/legacy/autoplan.md | 10 +++++++- skills/plan/references/legacy/office-hours.md | 10 +++++++- .../plan/references/legacy/plan-ceo-review.md | 10 +++++++- .../references/legacy/plan-design-review.md | 25 +++++++++++++++++++ .../references/legacy/plan-devex-review.md | 10 +++++++- .../plan/references/legacy/plan-eng-review.md | 10 +++++++- skills/plan/references/legacy/spec.md | 10 +++++++- skills/qa/references/SHARED-JUDGMENT.md | 4 ++- skills/review/references/SHARED-JUDGMENT.md | 4 ++- skills/review/references/legacy/review.md | 25 +++++++++++++++++++ skills/ship/references/SHARED-JUDGMENT.md | 4 ++- 33 files changed, 242 insertions(+), 40 deletions(-) diff --git a/docs/gstack-2/JUDGMENT-PARITY.md b/docs/gstack-2/JUDGMENT-PARITY.md index 1bb2770297..eeae3d6ec6 100644 --- a/docs/gstack-2/JUDGMENT-PARITY.md +++ b/docs/gstack-2/JUDGMENT-PARITY.md @@ -2,7 +2,7 @@ Parity is executable, not a prose claim. Run `bun run scripts/gstack2/run-parity.ts` or the dedicated Bun tests. -The pinned release inventory passes **5,027 checks** across 55 specialist sources, 16 carved sections, 25 routing scenarios, 28 regression ports, and **78 assets**. +The pinned release inventory passes **5,033 checks** across 55 specialist sources, 16 carved sections, 25 routing scenarios, 28 regression ports, and **78 assets**. The suite verifies: diff --git a/docs/gstack-2/JUDGMENT-PROVENANCE.json b/docs/gstack-2/JUDGMENT-PROVENANCE.json index fa2c95496e..22d3c1c890 100644 --- a/docs/gstack-2/JUDGMENT-PROVENANCE.json +++ b/docs/gstack-2/JUDGMENT-PROVENANCE.json @@ -1726,6 +1726,7 @@ 679, 2030, 2189, + 886, 879 ], "original_source_file": "plan-design-review/SKILL.md.tmpl", @@ -1862,6 +1863,7 @@ 2030, 2189, 696, + 886, 879 ], "original_source_file": "design-review/SKILL.md.tmpl", @@ -3629,6 +3631,7 @@ 2030, 2141, 579, + 886, 452, 879 ], @@ -5835,7 +5838,7 @@ "owner_tree": "design", "consumer_tree": "plan", "target": "skills/plan/references/legacy/plan-design-review.md", - "sha256": "7ae61a9b6a642ce58bde446116347c320c5414ce1f8fc6396762cd6a7974f532", + "sha256": "998496daab27f77d5613ddb838566c14cb1ed6071cef1c1a0ce30bd6eb6b4706", "disposition": "SHARED_MODULE" }, { @@ -7490,7 +7493,10 @@ "plan-eng-review", "plan-devex-review", "spec", - "autoplan" + "autoplan", + "review", + "plan-design-review", + "design-review" ], "anchor": "GSTACK2_FIX_886_PROPORTIONAL_PLANNING" }, diff --git a/docs/gstack-2/SKILL-MIGRATION.md b/docs/gstack-2/SKILL-MIGRATION.md index 617425fced..573691fe6e 100644 --- a/docs/gstack-2/SKILL-MIGRATION.md +++ b/docs/gstack-2/SKILL-MIGRATION.md @@ -27,8 +27,8 @@ The fixed public modes are: Design = `Explore | Generate | Critique | Implement` | `/design-consultation` | `$design --mode Generate --module design-consultation` | internal (primary) | yes | #679, #2030, #2189, #879 | | `/design-shotgun` | `$design --mode Explore --module design-shotgun` | internal (primary) | yes | #679, #1777, #879 | | `/design-html` | `$design --mode Implement --module design-html` | internal (primary) | yes | #679, #879 | -| `/plan-design-review` | `$design --mode Critique --module plan-design-review` | internal (primary) | yes | #679, #2030, #2189, #879 | -| `/design-review` | `$design --mode Implement --module design-review` | internal (primary) | yes | #679, #1920, #2030, #2189, #696, #879 | +| `/plan-design-review` | `$design --mode Critique --module plan-design-review` | internal (primary) | yes | #679, #2030, #2189, #886, #879 | +| `/design-review` | `$design --mode Implement --module design-review` | internal (primary) | yes | #679, #1920, #2030, #2189, #696, #886, #879 | | `/ios-design-review` | `$design --mode Critique --module ios-design-review` | internal (primary) | yes | #679, #879 | | `/diagram` | `$design --mode Generate --module diagram` | internal (internal) | no | #679, #879 | | `/make-pdf` | `$design --mode Generate --module make-pdf` | internal (internal) | no | #679, #879 | @@ -51,7 +51,7 @@ The fixed public modes are: Design = `Explore | Generate | Critique | Implement` | `/freeze` | `$debug --mode Diagnose-only --module freeze` | internal (internal) | no | #679, #879 | | `/guard` | `$debug --mode Diagnose-only --module guard` | internal (internal) | no | #679, #879 | | `/unfreeze` | `$debug --mode Diagnose-only --module unfreeze` | internal (internal) | no | #679, #879 | -| `/review` | `$review --mode Normal --module review` | internal (primary) | yes | #610, #645, #679, #2030, #2141, #579, #452, #879 | +| `/review` | `$review --mode Normal --module review` | internal (primary) | yes | #610, #645, #679, #2030, #2141, #579, #886, #452, #879 | | `/cso` | `$review --mode Security --module cso` | internal (primary) | yes | #679, #2030, #1523, #1053, #879 | | `/health` | `$review --mode Deep --module health` | internal (primary) | yes | #679, #879 | | `/codex` | `$review --mode Deep --module codex` | internal (primary) | yes | #679, #879 | diff --git a/evals/parity/contracts/design-review.json b/evals/parity/contracts/design-review.json index 5bdc86d378..4eaca7590b 100644 --- a/evals/parity/contracts/design-review.json +++ b/evals/parity/contracts/design-review.json @@ -17,6 +17,7 @@ 2030, 2189, 696, + 886, 879 ], "contract": { diff --git a/evals/parity/contracts/plan-design-review.json b/evals/parity/contracts/plan-design-review.json index 105ba92f50..f5ab1d5728 100644 --- a/evals/parity/contracts/plan-design-review.json +++ b/evals/parity/contracts/plan-design-review.json @@ -15,6 +15,7 @@ 679, 2030, 2189, + 886, 879 ], "contract": { diff --git a/evals/parity/contracts/review.json b/evals/parity/contracts/review.json index 9efff60590..e5762894f9 100644 --- a/evals/parity/contracts/review.json +++ b/evals/parity/contracts/review.json @@ -18,6 +18,7 @@ 2030, 2141, 579, + 886, 452, 879 ], diff --git a/evals/parity/manifest.json b/evals/parity/manifest.json index fa2c95496e..22d3c1c890 100644 --- a/evals/parity/manifest.json +++ b/evals/parity/manifest.json @@ -1726,6 +1726,7 @@ 679, 2030, 2189, + 886, 879 ], "original_source_file": "plan-design-review/SKILL.md.tmpl", @@ -1862,6 +1863,7 @@ 2030, 2189, 696, + 886, 879 ], "original_source_file": "design-review/SKILL.md.tmpl", @@ -3629,6 +3631,7 @@ 2030, 2141, 579, + 886, 452, 879 ], @@ -5835,7 +5838,7 @@ "owner_tree": "design", "consumer_tree": "plan", "target": "skills/plan/references/legacy/plan-design-review.md", - "sha256": "7ae61a9b6a642ce58bde446116347c320c5414ce1f8fc6396762cd6a7974f532", + "sha256": "998496daab27f77d5613ddb838566c14cb1ed6071cef1c1a0ce30bd6eb6b4706", "disposition": "SHARED_MODULE" }, { @@ -7490,7 +7493,10 @@ "plan-eng-review", "plan-devex-review", "spec", - "autoplan" + "autoplan", + "review", + "plan-design-review", + "design-review" ], "anchor": "GSTACK2_FIX_886_PROPORTIONAL_PLANNING" }, diff --git a/evals/parity/regressions/pr-886.json b/evals/parity/regressions/pr-886.json index c9b6961b48..881b23dbe4 100644 --- a/evals/parity/regressions/pr-886.json +++ b/evals/parity/regressions/pr-886.json @@ -8,28 +8,37 @@ "plan-eng-review", "plan-devex-review", "spec", - "autoplan" + "autoplan", + "review", + "plan-design-review", + "design-review" ], "anchor": "GSTACK2_FIX_886_PROPORTIONAL_PLANNING", - "body": "### Proportional planning for the printed build scale\n\nThe /plan dispatcher prints a `Scale:` header line classified from fifteen build-scale vectors (its Build scale section). This rule authorizes every planning specialist to size its machinery to that scale while keeping every STOP gate and approval boundary; a polite user answering every question is not evidence the full machinery is wanted, and the user can always ask for the complete treatment.\n\n- `session` and `hobby`: batch every question the initial prompt left unanswered into one AskUserQuestion round (two rounds for hobby); skip web or landscape research, outside voices, second opinions, and visual sketches unless the user asks (privacy gates are unchanged whenever they run); cap any adversarial or spec review loop at one iteration; keep the decision artifact near one page with next steps sized in hours (session) or days (hobby), never a phased multi-week roadmap or a distribution plan the user did not ask for.\n- `project`: run the specialist's default workflow, batching question rounds where its source authorizes smart skips; size the roadmap in weeks.\n- `product` and `venture`: the full specialist workflow and its complete question pressure apply; this rule removes nothing.\n- Never run a questioning round merely to classify scale. Classify from the prompt and cheap repository evidence, defaulting unknown vectors low; a specialist's own later questions may raise the scale mid-session, and an upgrade restores the full workflow from that point.\n\nFor office-hours specifically: at session or hobby scale, batch the Phase 2B questions (this refines the one-at-a-time rule, whose pressure exists for startup diagnostics), default-skip the Phase 2.75 landscape search, gate the visual sketch and outside design voices on an explicit ask, and cap the Spec Review Loop at one iteration.", + "body": "### Proportional planning for the printed build scale\n\nThe /plan dispatcher prints a `Scale:` header line classified from fifteen build-scale vectors (its Build scale section). This rule authorizes every planning and review specialist to size its machinery to that scale while keeping every STOP gate and approval boundary; a polite user answering every question is not evidence the full machinery is wanted, and the user can always ask for the complete treatment.\n\nThe binding scale comes from the first available source: the printed `Scale:` header, a chain handoff that names a scale or time box, or on-the-spot classification from the prompt and cheap repository evidence. An explicit user time constraint is a ceiling, not one vector among fifteen: work that must fit one sitting caps the scale at `session`, and a day-or-two deadline caps it at `hobby`, regardless of higher vectors. A chained invocation inherits the upstream scale and time box without re-asking, and every handoff it emits carries them forward.\n\n- `session` and `hobby`: batch every question the initial prompt left unanswered into one AskUserQuestion round (two rounds for hobby); skip web or landscape research, outside voices, second opinions, and visual sketches unless the user asks (privacy gates are unchanged whenever they run); cap any adversarial or spec review loop at one iteration; keep the decision artifact near one page with next steps sized in hours (session) or days (hobby), never a phased multi-week roadmap or a distribution plan the user did not ask for.\n- `project`: run the specialist's default workflow, batching question rounds where its source authorizes smart skips; size the roadmap in weeks.\n- `product` and `venture`: the full specialist workflow and its complete question pressure apply; this rule removes nothing.\n- Never run a questioning round merely to classify scale. Classify from the prompt and cheap repository evidence, defaulting unknown vectors low; a specialist's own later questions may raise the scale mid-session, and an upgrade restores the full workflow from that point.\n\nReview specialists spend question rounds on decisions, not ceremony — at every scale, and sharpest at `session`/`hobby`:\n\n- When the handoff or prompt names the review target unambiguously, print it on the Target line and proceed. Re-confirming a target the chain already fixed is not a STOP gate; the target gate exists for genuinely ambiguous targets.\n- A finding whose fix is obvious and inside the authorized mutation boundary is applied and reported in a compact applied-changes list. Question rounds are reserved for genuine forks — scope changes, user-visible tradeoffs, anything hard to reverse — and are batched, up to four questions per round, never one round per finding.\n- Optional extras (opening resources, offering the next review or a follow-up phase) never get their own question round at `session`/`hobby`: fold them into an existing round or a one-line closing offer.\n\nFor office-hours specifically: at session or hobby scale, batch the Phase 2B questions (this refines the one-at-a-time rule, whose pressure exists for startup diagnostics), default-skip the Phase 2.75 landscape search, gate the visual sketch and outside design voices on an explicit ask, and cap the Spec Review Loop at one iteration.", "regression": { "input": { - "audience": "self", - "users": "none", + "audience": "public", + "users": "handful", "commercial": "none", "deployment": "none", "horizon": "session", "stakes": "fun", - "extensibility": "fixed" + "maintenance": "throwaway", + "stated_time_constraint": "one-sitting", + "handoff_target": "docs/designs/hackathon-demo.md", + "minor_findings": 4 }, "expected": { "scale": "session", + "time_constraint_caps_scale": true, "questions_batched": true, "question_rounds_max": 1, "web_search": "on-request", "outside_voices": "on-request", "review_iterations_max": 1, - "step_unit": "hours" + "step_unit": "hours", + "target_confirmation_round": false, + "minor_findings_applied_not_asked": true } } } diff --git a/evals/parity/transcripts/deterministic/ceo-review.json b/evals/parity/transcripts/deterministic/ceo-review.json index 324bff5b8e..d54f5d6b86 100644 --- a/evals/parity/transcripts/deterministic/ceo-review.json +++ b/evals/parity/transcripts/deterministic/ceo-review.json @@ -101,7 +101,7 @@ "issue_or_pr": "https://github.com/garrytan/gstack/issues/886", "reproduced_defect": "Scale planning machinery to the printed build scale", "regression_fixture": "evals/parity/regressions/pr-886.json", - "explanation": "### Proportional planning for the printed build scale\n\nThe /plan dispatcher prints a `Scale:` header line classified from fifteen build-scale vectors (its Build scale section). This rule authorizes every planning specialist to size its machinery to that scale while keeping every STOP gate and approval boundary; a polite user answering every question is not evidence the full machinery is wanted, and the user can always ask for the complete treatment.\n\n- `session` and `hobby`: batch every question the initial prompt left unanswered into one AskUserQuestion round (two rounds for hobby); skip web or landscape research, outside voices, second opinions, and visual sketches unless the user asks (privacy gates are unchanged whenever they run); cap any adversarial or spec review loop at one iteration; keep the decision artifact near one page with next steps sized in hours (session) or days (hobby), never a phased multi-week roadmap or a distribution plan the user did not ask for.\n- `project`: run the specialist's default workflow, batching question rounds where its source authorizes smart skips; size the roadmap in weeks.\n- `product` and `venture`: the full specialist workflow and its complete question pressure apply; this rule removes nothing.\n- Never run a questioning round merely to classify scale. Classify from the prompt and cheap repository evidence, defaulting unknown vectors low; a specialist's own later questions may raise the scale mid-session, and an upgrade restores the full workflow from that point.\n\nFor office-hours specifically: at session or hobby scale, batch the Phase 2B questions (this refines the one-at-a-time rule, whose pressure exists for startup diagnostics), default-skip the Phase 2.75 landscape search, gate the visual sketch and outside design voices on an explicit ask, and cap the Spec Review Loop at one iteration." + "explanation": "### Proportional planning for the printed build scale\n\nThe /plan dispatcher prints a `Scale:` header line classified from fifteen build-scale vectors (its Build scale section). This rule authorizes every planning and review specialist to size its machinery to that scale while keeping every STOP gate and approval boundary; a polite user answering every question is not evidence the full machinery is wanted, and the user can always ask for the complete treatment.\n\nThe binding scale comes from the first available source: the printed `Scale:` header, a chain handoff that names a scale or time box, or on-the-spot classification from the prompt and cheap repository evidence. An explicit user time constraint is a ceiling, not one vector among fifteen: work that must fit one sitting caps the scale at `session`, and a day-or-two deadline caps it at `hobby`, regardless of higher vectors. A chained invocation inherits the upstream scale and time box without re-asking, and every handoff it emits carries them forward.\n\n- `session` and `hobby`: batch every question the initial prompt left unanswered into one AskUserQuestion round (two rounds for hobby); skip web or landscape research, outside voices, second opinions, and visual sketches unless the user asks (privacy gates are unchanged whenever they run); cap any adversarial or spec review loop at one iteration; keep the decision artifact near one page with next steps sized in hours (session) or days (hobby), never a phased multi-week roadmap or a distribution plan the user did not ask for.\n- `project`: run the specialist's default workflow, batching question rounds where its source authorizes smart skips; size the roadmap in weeks.\n- `product` and `venture`: the full specialist workflow and its complete question pressure apply; this rule removes nothing.\n- Never run a questioning round merely to classify scale. Classify from the prompt and cheap repository evidence, defaulting unknown vectors low; a specialist's own later questions may raise the scale mid-session, and an upgrade restores the full workflow from that point.\n\nReview specialists spend question rounds on decisions, not ceremony — at every scale, and sharpest at `session`/`hobby`:\n\n- When the handoff or prompt names the review target unambiguously, print it on the Target line and proceed. Re-confirming a target the chain already fixed is not a STOP gate; the target gate exists for genuinely ambiguous targets.\n- A finding whose fix is obvious and inside the authorized mutation boundary is applied and reported in a compact applied-changes list. Question rounds are reserved for genuine forks — scope changes, user-visible tradeoffs, anything hard to reverse — and are batched, up to four questions per round, never one round per finding.\n- Optional extras (opening resources, offering the next review or a follow-up phase) never get their own question round at `session`/`hobby`: fold them into an existing round or a one-line closing offer.\n\nFor office-hours specifically: at session or hobby scale, batch the Phase 2B questions (this refines the one-at-a-time rule, whose pressure exists for startup diagnostics), default-skip the Phase 2.75 landscape search, gate the visual sketch and outside design voices on an explicit ask, and cap the Spec Review Loop at one iteration." }, { "classification": "INTENTIONAL_IMPROVEMENT", diff --git a/evals/parity/transcripts/deterministic/code-review.json b/evals/parity/transcripts/deterministic/code-review.json index 44454fb48d..47cbee9c75 100644 --- a/evals/parity/transcripts/deterministic/code-review.json +++ b/evals/parity/transcripts/deterministic/code-review.json @@ -126,6 +126,13 @@ "regression_fixture": "evals/parity/regressions/pr-579.json", "explanation": "### MCP-server packaging checks (informational)\n\nWhen the diff adds or modifies an MCP server package (`glama.json`, an `mcpServers` block in `package.json`, or a server entry point), add informational packaging checks. Flag `package.json` `exports`/`main`/`bin` that resolve into `src/` or a `.ts` file rather than the compiled `dist/` output, because registry Docker builds run the compiled artifact. Flag relative ESM imports missing `.js` extensions under `moduleResolution: \"NodeNext\"`/`\"Node16\"`, since bundler resolution hides it locally but Node ESM fails at runtime. Flag `moduleResolution: \"bundler\"` on a standalone Node MCP server (correct for frontend, wrong for an npm/Docker-distributed server). Flag a missing or malformed `glama.json` (needs `$schema` and a `maintainers` array). Do not flag frontend packages using `bundler`, or MCP packages consumed as libraries rather than standalone servers." }, + { + "classification": "INTENTIONAL_IMPROVEMENT", + "issue_or_pr": "https://github.com/garrytan/gstack/issues/886", + "reproduced_defect": "Scale planning machinery to the printed build scale", + "regression_fixture": "evals/parity/regressions/pr-886.json", + "explanation": "### Proportional planning for the printed build scale\n\nThe /plan dispatcher prints a `Scale:` header line classified from fifteen build-scale vectors (its Build scale section). This rule authorizes every planning and review specialist to size its machinery to that scale while keeping every STOP gate and approval boundary; a polite user answering every question is not evidence the full machinery is wanted, and the user can always ask for the complete treatment.\n\nThe binding scale comes from the first available source: the printed `Scale:` header, a chain handoff that names a scale or time box, or on-the-spot classification from the prompt and cheap repository evidence. An explicit user time constraint is a ceiling, not one vector among fifteen: work that must fit one sitting caps the scale at `session`, and a day-or-two deadline caps it at `hobby`, regardless of higher vectors. A chained invocation inherits the upstream scale and time box without re-asking, and every handoff it emits carries them forward.\n\n- `session` and `hobby`: batch every question the initial prompt left unanswered into one AskUserQuestion round (two rounds for hobby); skip web or landscape research, outside voices, second opinions, and visual sketches unless the user asks (privacy gates are unchanged whenever they run); cap any adversarial or spec review loop at one iteration; keep the decision artifact near one page with next steps sized in hours (session) or days (hobby), never a phased multi-week roadmap or a distribution plan the user did not ask for.\n- `project`: run the specialist's default workflow, batching question rounds where its source authorizes smart skips; size the roadmap in weeks.\n- `product` and `venture`: the full specialist workflow and its complete question pressure apply; this rule removes nothing.\n- Never run a questioning round merely to classify scale. Classify from the prompt and cheap repository evidence, defaulting unknown vectors low; a specialist's own later questions may raise the scale mid-session, and an upgrade restores the full workflow from that point.\n\nReview specialists spend question rounds on decisions, not ceremony — at every scale, and sharpest at `session`/`hobby`:\n\n- When the handoff or prompt names the review target unambiguously, print it on the Target line and proceed. Re-confirming a target the chain already fixed is not a STOP gate; the target gate exists for genuinely ambiguous targets.\n- A finding whose fix is obvious and inside the authorized mutation boundary is applied and reported in a compact applied-changes list. Question rounds are reserved for genuine forks — scope changes, user-visible tradeoffs, anything hard to reverse — and are batched, up to four questions per round, never one round per finding.\n- Optional extras (opening resources, offering the next review or a follow-up phase) never get their own question round at `session`/`hobby`: fold them into an existing round or a one-line closing offer.\n\nFor office-hours specifically: at session or hobby scale, batch the Phase 2B questions (this refines the one-at-a-time rule, whose pressure exists for startup diagnostics), default-skip the Phase 2.75 landscape search, gate the visual sketch and outside design voices on an explicit ask, and cap the Spec Review Loop at one iteration." + }, { "classification": "INTENTIONAL_IMPROVEMENT", "issue_or_pr": "https://github.com/garrytan/gstack/pull/452", diff --git a/evals/parity/transcripts/deterministic/design-review.json b/evals/parity/transcripts/deterministic/design-review.json index b65f2571ae..7b41cc39b9 100644 --- a/evals/parity/transcripts/deterministic/design-review.json +++ b/evals/parity/transcripts/deterministic/design-review.json @@ -116,6 +116,13 @@ "regression_fixture": "evals/parity/regressions/pr-696.json", "explanation": "### Cognitive-load audit\n\nRate every audited screen on a System 1 to System 2 scale from 0 to 10, grounded in browse data already collected (element counts, link counts, load times), not impression. Most screens should sit at S1 (0-3); higher scores are acceptable only as intentional friction such as destructive or financial decisions. For any screen above the threshold that is not deliberate friction, name the specific UX laws it breaks (Fitts, Hick, Jakob, Miller, Peak-End, Von Restorff, Zeigarnik, Gestalt) and cite the measurement that proves it." }, + { + "classification": "INTENTIONAL_IMPROVEMENT", + "issue_or_pr": "https://github.com/garrytan/gstack/issues/886", + "reproduced_defect": "Scale planning machinery to the printed build scale", + "regression_fixture": "evals/parity/regressions/pr-886.json", + "explanation": "### Proportional planning for the printed build scale\n\nThe /plan dispatcher prints a `Scale:` header line classified from fifteen build-scale vectors (its Build scale section). This rule authorizes every planning and review specialist to size its machinery to that scale while keeping every STOP gate and approval boundary; a polite user answering every question is not evidence the full machinery is wanted, and the user can always ask for the complete treatment.\n\nThe binding scale comes from the first available source: the printed `Scale:` header, a chain handoff that names a scale or time box, or on-the-spot classification from the prompt and cheap repository evidence. An explicit user time constraint is a ceiling, not one vector among fifteen: work that must fit one sitting caps the scale at `session`, and a day-or-two deadline caps it at `hobby`, regardless of higher vectors. A chained invocation inherits the upstream scale and time box without re-asking, and every handoff it emits carries them forward.\n\n- `session` and `hobby`: batch every question the initial prompt left unanswered into one AskUserQuestion round (two rounds for hobby); skip web or landscape research, outside voices, second opinions, and visual sketches unless the user asks (privacy gates are unchanged whenever they run); cap any adversarial or spec review loop at one iteration; keep the decision artifact near one page with next steps sized in hours (session) or days (hobby), never a phased multi-week roadmap or a distribution plan the user did not ask for.\n- `project`: run the specialist's default workflow, batching question rounds where its source authorizes smart skips; size the roadmap in weeks.\n- `product` and `venture`: the full specialist workflow and its complete question pressure apply; this rule removes nothing.\n- Never run a questioning round merely to classify scale. Classify from the prompt and cheap repository evidence, defaulting unknown vectors low; a specialist's own later questions may raise the scale mid-session, and an upgrade restores the full workflow from that point.\n\nReview specialists spend question rounds on decisions, not ceremony — at every scale, and sharpest at `session`/`hobby`:\n\n- When the handoff or prompt names the review target unambiguously, print it on the Target line and proceed. Re-confirming a target the chain already fixed is not a STOP gate; the target gate exists for genuinely ambiguous targets.\n- A finding whose fix is obvious and inside the authorized mutation boundary is applied and reported in a compact applied-changes list. Question rounds are reserved for genuine forks — scope changes, user-visible tradeoffs, anything hard to reverse — and are batched, up to four questions per round, never one round per finding.\n- Optional extras (opening resources, offering the next review or a follow-up phase) never get their own question round at `session`/`hobby`: fold them into an existing round or a one-line closing offer.\n\nFor office-hours specifically: at session or hobby scale, batch the Phase 2B questions (this refines the one-at-a-time rule, whose pressure exists for startup diagnostics), default-skip the Phase 2.75 landscape search, gate the visual sketch and outside design voices on an explicit ask, and cap the Spec Review Loop at one iteration." + }, { "classification": "INTENTIONAL_IMPROVEMENT", "issue_or_pr": "https://github.com/garrytan/gstack/issues/879", diff --git a/evals/parity/transcripts/deterministic/dx-review.json b/evals/parity/transcripts/deterministic/dx-review.json index 34e4023573..c313683687 100644 --- a/evals/parity/transcripts/deterministic/dx-review.json +++ b/evals/parity/transcripts/deterministic/dx-review.json @@ -102,7 +102,7 @@ "issue_or_pr": "https://github.com/garrytan/gstack/issues/886", "reproduced_defect": "Scale planning machinery to the printed build scale", "regression_fixture": "evals/parity/regressions/pr-886.json", - "explanation": "### Proportional planning for the printed build scale\n\nThe /plan dispatcher prints a `Scale:` header line classified from fifteen build-scale vectors (its Build scale section). This rule authorizes every planning specialist to size its machinery to that scale while keeping every STOP gate and approval boundary; a polite user answering every question is not evidence the full machinery is wanted, and the user can always ask for the complete treatment.\n\n- `session` and `hobby`: batch every question the initial prompt left unanswered into one AskUserQuestion round (two rounds for hobby); skip web or landscape research, outside voices, second opinions, and visual sketches unless the user asks (privacy gates are unchanged whenever they run); cap any adversarial or spec review loop at one iteration; keep the decision artifact near one page with next steps sized in hours (session) or days (hobby), never a phased multi-week roadmap or a distribution plan the user did not ask for.\n- `project`: run the specialist's default workflow, batching question rounds where its source authorizes smart skips; size the roadmap in weeks.\n- `product` and `venture`: the full specialist workflow and its complete question pressure apply; this rule removes nothing.\n- Never run a questioning round merely to classify scale. Classify from the prompt and cheap repository evidence, defaulting unknown vectors low; a specialist's own later questions may raise the scale mid-session, and an upgrade restores the full workflow from that point.\n\nFor office-hours specifically: at session or hobby scale, batch the Phase 2B questions (this refines the one-at-a-time rule, whose pressure exists for startup diagnostics), default-skip the Phase 2.75 landscape search, gate the visual sketch and outside design voices on an explicit ask, and cap the Spec Review Loop at one iteration." + "explanation": "### Proportional planning for the printed build scale\n\nThe /plan dispatcher prints a `Scale:` header line classified from fifteen build-scale vectors (its Build scale section). This rule authorizes every planning and review specialist to size its machinery to that scale while keeping every STOP gate and approval boundary; a polite user answering every question is not evidence the full machinery is wanted, and the user can always ask for the complete treatment.\n\nThe binding scale comes from the first available source: the printed `Scale:` header, a chain handoff that names a scale or time box, or on-the-spot classification from the prompt and cheap repository evidence. An explicit user time constraint is a ceiling, not one vector among fifteen: work that must fit one sitting caps the scale at `session`, and a day-or-two deadline caps it at `hobby`, regardless of higher vectors. A chained invocation inherits the upstream scale and time box without re-asking, and every handoff it emits carries them forward.\n\n- `session` and `hobby`: batch every question the initial prompt left unanswered into one AskUserQuestion round (two rounds for hobby); skip web or landscape research, outside voices, second opinions, and visual sketches unless the user asks (privacy gates are unchanged whenever they run); cap any adversarial or spec review loop at one iteration; keep the decision artifact near one page with next steps sized in hours (session) or days (hobby), never a phased multi-week roadmap or a distribution plan the user did not ask for.\n- `project`: run the specialist's default workflow, batching question rounds where its source authorizes smart skips; size the roadmap in weeks.\n- `product` and `venture`: the full specialist workflow and its complete question pressure apply; this rule removes nothing.\n- Never run a questioning round merely to classify scale. Classify from the prompt and cheap repository evidence, defaulting unknown vectors low; a specialist's own later questions may raise the scale mid-session, and an upgrade restores the full workflow from that point.\n\nReview specialists spend question rounds on decisions, not ceremony — at every scale, and sharpest at `session`/`hobby`:\n\n- When the handoff or prompt names the review target unambiguously, print it on the Target line and proceed. Re-confirming a target the chain already fixed is not a STOP gate; the target gate exists for genuinely ambiguous targets.\n- A finding whose fix is obvious and inside the authorized mutation boundary is applied and reported in a compact applied-changes list. Question rounds are reserved for genuine forks — scope changes, user-visible tradeoffs, anything hard to reverse — and are batched, up to four questions per round, never one round per finding.\n- Optional extras (opening resources, offering the next review or a follow-up phase) never get their own question round at `session`/`hobby`: fold them into an existing round or a one-line closing offer.\n\nFor office-hours specifically: at session or hobby scale, batch the Phase 2B questions (this refines the one-at-a-time rule, whose pressure exists for startup diagnostics), default-skip the Phase 2.75 landscape search, gate the visual sketch and outside design voices on an explicit ask, and cap the Spec Review Loop at one iteration." }, { "classification": "INTENTIONAL_IMPROVEMENT", diff --git a/evals/parity/transcripts/deterministic/engineering-review.json b/evals/parity/transcripts/deterministic/engineering-review.json index 09a3e28fcd..2d3244bd98 100644 --- a/evals/parity/transcripts/deterministic/engineering-review.json +++ b/evals/parity/transcripts/deterministic/engineering-review.json @@ -115,7 +115,7 @@ "issue_or_pr": "https://github.com/garrytan/gstack/issues/886", "reproduced_defect": "Scale planning machinery to the printed build scale", "regression_fixture": "evals/parity/regressions/pr-886.json", - "explanation": "### Proportional planning for the printed build scale\n\nThe /plan dispatcher prints a `Scale:` header line classified from fifteen build-scale vectors (its Build scale section). This rule authorizes every planning specialist to size its machinery to that scale while keeping every STOP gate and approval boundary; a polite user answering every question is not evidence the full machinery is wanted, and the user can always ask for the complete treatment.\n\n- `session` and `hobby`: batch every question the initial prompt left unanswered into one AskUserQuestion round (two rounds for hobby); skip web or landscape research, outside voices, second opinions, and visual sketches unless the user asks (privacy gates are unchanged whenever they run); cap any adversarial or spec review loop at one iteration; keep the decision artifact near one page with next steps sized in hours (session) or days (hobby), never a phased multi-week roadmap or a distribution plan the user did not ask for.\n- `project`: run the specialist's default workflow, batching question rounds where its source authorizes smart skips; size the roadmap in weeks.\n- `product` and `venture`: the full specialist workflow and its complete question pressure apply; this rule removes nothing.\n- Never run a questioning round merely to classify scale. Classify from the prompt and cheap repository evidence, defaulting unknown vectors low; a specialist's own later questions may raise the scale mid-session, and an upgrade restores the full workflow from that point.\n\nFor office-hours specifically: at session or hobby scale, batch the Phase 2B questions (this refines the one-at-a-time rule, whose pressure exists for startup diagnostics), default-skip the Phase 2.75 landscape search, gate the visual sketch and outside design voices on an explicit ask, and cap the Spec Review Loop at one iteration." + "explanation": "### Proportional planning for the printed build scale\n\nThe /plan dispatcher prints a `Scale:` header line classified from fifteen build-scale vectors (its Build scale section). This rule authorizes every planning and review specialist to size its machinery to that scale while keeping every STOP gate and approval boundary; a polite user answering every question is not evidence the full machinery is wanted, and the user can always ask for the complete treatment.\n\nThe binding scale comes from the first available source: the printed `Scale:` header, a chain handoff that names a scale or time box, or on-the-spot classification from the prompt and cheap repository evidence. An explicit user time constraint is a ceiling, not one vector among fifteen: work that must fit one sitting caps the scale at `session`, and a day-or-two deadline caps it at `hobby`, regardless of higher vectors. A chained invocation inherits the upstream scale and time box without re-asking, and every handoff it emits carries them forward.\n\n- `session` and `hobby`: batch every question the initial prompt left unanswered into one AskUserQuestion round (two rounds for hobby); skip web or landscape research, outside voices, second opinions, and visual sketches unless the user asks (privacy gates are unchanged whenever they run); cap any adversarial or spec review loop at one iteration; keep the decision artifact near one page with next steps sized in hours (session) or days (hobby), never a phased multi-week roadmap or a distribution plan the user did not ask for.\n- `project`: run the specialist's default workflow, batching question rounds where its source authorizes smart skips; size the roadmap in weeks.\n- `product` and `venture`: the full specialist workflow and its complete question pressure apply; this rule removes nothing.\n- Never run a questioning round merely to classify scale. Classify from the prompt and cheap repository evidence, defaulting unknown vectors low; a specialist's own later questions may raise the scale mid-session, and an upgrade restores the full workflow from that point.\n\nReview specialists spend question rounds on decisions, not ceremony — at every scale, and sharpest at `session`/`hobby`:\n\n- When the handoff or prompt names the review target unambiguously, print it on the Target line and proceed. Re-confirming a target the chain already fixed is not a STOP gate; the target gate exists for genuinely ambiguous targets.\n- A finding whose fix is obvious and inside the authorized mutation boundary is applied and reported in a compact applied-changes list. Question rounds are reserved for genuine forks — scope changes, user-visible tradeoffs, anything hard to reverse — and are batched, up to four questions per round, never one round per finding.\n- Optional extras (opening resources, offering the next review or a follow-up phase) never get their own question round at `session`/`hobby`: fold them into an existing round or a one-line closing offer.\n\nFor office-hours specifically: at session or hobby scale, batch the Phase 2B questions (this refines the one-at-a-time rule, whose pressure exists for startup diagnostics), default-skip the Phase 2.75 landscape search, gate the visual sketch and outside design voices on an explicit ask, and cap the Spec Review Loop at one iteration." }, { "classification": "INTENTIONAL_IMPROVEMENT", diff --git a/evals/parity/transcripts/deterministic/office-hours.json b/evals/parity/transcripts/deterministic/office-hours.json index 8e3978bb1f..21e8543e7c 100644 --- a/evals/parity/transcripts/deterministic/office-hours.json +++ b/evals/parity/transcripts/deterministic/office-hours.json @@ -115,7 +115,7 @@ "issue_or_pr": "https://github.com/garrytan/gstack/issues/886", "reproduced_defect": "Scale planning machinery to the printed build scale", "regression_fixture": "evals/parity/regressions/pr-886.json", - "explanation": "### Proportional planning for the printed build scale\n\nThe /plan dispatcher prints a `Scale:` header line classified from fifteen build-scale vectors (its Build scale section). This rule authorizes every planning specialist to size its machinery to that scale while keeping every STOP gate and approval boundary; a polite user answering every question is not evidence the full machinery is wanted, and the user can always ask for the complete treatment.\n\n- `session` and `hobby`: batch every question the initial prompt left unanswered into one AskUserQuestion round (two rounds for hobby); skip web or landscape research, outside voices, second opinions, and visual sketches unless the user asks (privacy gates are unchanged whenever they run); cap any adversarial or spec review loop at one iteration; keep the decision artifact near one page with next steps sized in hours (session) or days (hobby), never a phased multi-week roadmap or a distribution plan the user did not ask for.\n- `project`: run the specialist's default workflow, batching question rounds where its source authorizes smart skips; size the roadmap in weeks.\n- `product` and `venture`: the full specialist workflow and its complete question pressure apply; this rule removes nothing.\n- Never run a questioning round merely to classify scale. Classify from the prompt and cheap repository evidence, defaulting unknown vectors low; a specialist's own later questions may raise the scale mid-session, and an upgrade restores the full workflow from that point.\n\nFor office-hours specifically: at session or hobby scale, batch the Phase 2B questions (this refines the one-at-a-time rule, whose pressure exists for startup diagnostics), default-skip the Phase 2.75 landscape search, gate the visual sketch and outside design voices on an explicit ask, and cap the Spec Review Loop at one iteration." + "explanation": "### Proportional planning for the printed build scale\n\nThe /plan dispatcher prints a `Scale:` header line classified from fifteen build-scale vectors (its Build scale section). This rule authorizes every planning and review specialist to size its machinery to that scale while keeping every STOP gate and approval boundary; a polite user answering every question is not evidence the full machinery is wanted, and the user can always ask for the complete treatment.\n\nThe binding scale comes from the first available source: the printed `Scale:` header, a chain handoff that names a scale or time box, or on-the-spot classification from the prompt and cheap repository evidence. An explicit user time constraint is a ceiling, not one vector among fifteen: work that must fit one sitting caps the scale at `session`, and a day-or-two deadline caps it at `hobby`, regardless of higher vectors. A chained invocation inherits the upstream scale and time box without re-asking, and every handoff it emits carries them forward.\n\n- `session` and `hobby`: batch every question the initial prompt left unanswered into one AskUserQuestion round (two rounds for hobby); skip web or landscape research, outside voices, second opinions, and visual sketches unless the user asks (privacy gates are unchanged whenever they run); cap any adversarial or spec review loop at one iteration; keep the decision artifact near one page with next steps sized in hours (session) or days (hobby), never a phased multi-week roadmap or a distribution plan the user did not ask for.\n- `project`: run the specialist's default workflow, batching question rounds where its source authorizes smart skips; size the roadmap in weeks.\n- `product` and `venture`: the full specialist workflow and its complete question pressure apply; this rule removes nothing.\n- Never run a questioning round merely to classify scale. Classify from the prompt and cheap repository evidence, defaulting unknown vectors low; a specialist's own later questions may raise the scale mid-session, and an upgrade restores the full workflow from that point.\n\nReview specialists spend question rounds on decisions, not ceremony — at every scale, and sharpest at `session`/`hobby`:\n\n- When the handoff or prompt names the review target unambiguously, print it on the Target line and proceed. Re-confirming a target the chain already fixed is not a STOP gate; the target gate exists for genuinely ambiguous targets.\n- A finding whose fix is obvious and inside the authorized mutation boundary is applied and reported in a compact applied-changes list. Question rounds are reserved for genuine forks — scope changes, user-visible tradeoffs, anything hard to reverse — and are batched, up to four questions per round, never one round per finding.\n- Optional extras (opening resources, offering the next review or a follow-up phase) never get their own question round at `session`/`hobby`: fold them into an existing round or a one-line closing offer.\n\nFor office-hours specifically: at session or hobby scale, batch the Phase 2B questions (this refines the one-at-a-time rule, whose pressure exists for startup diagnostics), default-skip the Phase 2.75 landscape search, gate the visual sketch and outside design voices on an explicit ask, and cap the Spec Review Loop at one iteration." }, { "classification": "INTENTIONAL_IMPROVEMENT", diff --git a/evals/parity/transcripts/deterministic/specification.json b/evals/parity/transcripts/deterministic/specification.json index 26fd042bb9..a6e4101a05 100644 --- a/evals/parity/transcripts/deterministic/specification.json +++ b/evals/parity/transcripts/deterministic/specification.json @@ -94,7 +94,7 @@ "issue_or_pr": "https://github.com/garrytan/gstack/issues/886", "reproduced_defect": "Scale planning machinery to the printed build scale", "regression_fixture": "evals/parity/regressions/pr-886.json", - "explanation": "### Proportional planning for the printed build scale\n\nThe /plan dispatcher prints a `Scale:` header line classified from fifteen build-scale vectors (its Build scale section). This rule authorizes every planning specialist to size its machinery to that scale while keeping every STOP gate and approval boundary; a polite user answering every question is not evidence the full machinery is wanted, and the user can always ask for the complete treatment.\n\n- `session` and `hobby`: batch every question the initial prompt left unanswered into one AskUserQuestion round (two rounds for hobby); skip web or landscape research, outside voices, second opinions, and visual sketches unless the user asks (privacy gates are unchanged whenever they run); cap any adversarial or spec review loop at one iteration; keep the decision artifact near one page with next steps sized in hours (session) or days (hobby), never a phased multi-week roadmap or a distribution plan the user did not ask for.\n- `project`: run the specialist's default workflow, batching question rounds where its source authorizes smart skips; size the roadmap in weeks.\n- `product` and `venture`: the full specialist workflow and its complete question pressure apply; this rule removes nothing.\n- Never run a questioning round merely to classify scale. Classify from the prompt and cheap repository evidence, defaulting unknown vectors low; a specialist's own later questions may raise the scale mid-session, and an upgrade restores the full workflow from that point.\n\nFor office-hours specifically: at session or hobby scale, batch the Phase 2B questions (this refines the one-at-a-time rule, whose pressure exists for startup diagnostics), default-skip the Phase 2.75 landscape search, gate the visual sketch and outside design voices on an explicit ask, and cap the Spec Review Loop at one iteration." + "explanation": "### Proportional planning for the printed build scale\n\nThe /plan dispatcher prints a `Scale:` header line classified from fifteen build-scale vectors (its Build scale section). This rule authorizes every planning and review specialist to size its machinery to that scale while keeping every STOP gate and approval boundary; a polite user answering every question is not evidence the full machinery is wanted, and the user can always ask for the complete treatment.\n\nThe binding scale comes from the first available source: the printed `Scale:` header, a chain handoff that names a scale or time box, or on-the-spot classification from the prompt and cheap repository evidence. An explicit user time constraint is a ceiling, not one vector among fifteen: work that must fit one sitting caps the scale at `session`, and a day-or-two deadline caps it at `hobby`, regardless of higher vectors. A chained invocation inherits the upstream scale and time box without re-asking, and every handoff it emits carries them forward.\n\n- `session` and `hobby`: batch every question the initial prompt left unanswered into one AskUserQuestion round (two rounds for hobby); skip web or landscape research, outside voices, second opinions, and visual sketches unless the user asks (privacy gates are unchanged whenever they run); cap any adversarial or spec review loop at one iteration; keep the decision artifact near one page with next steps sized in hours (session) or days (hobby), never a phased multi-week roadmap or a distribution plan the user did not ask for.\n- `project`: run the specialist's default workflow, batching question rounds where its source authorizes smart skips; size the roadmap in weeks.\n- `product` and `venture`: the full specialist workflow and its complete question pressure apply; this rule removes nothing.\n- Never run a questioning round merely to classify scale. Classify from the prompt and cheap repository evidence, defaulting unknown vectors low; a specialist's own later questions may raise the scale mid-session, and an upgrade restores the full workflow from that point.\n\nReview specialists spend question rounds on decisions, not ceremony — at every scale, and sharpest at `session`/`hobby`:\n\n- When the handoff or prompt names the review target unambiguously, print it on the Target line and proceed. Re-confirming a target the chain already fixed is not a STOP gate; the target gate exists for genuinely ambiguous targets.\n- A finding whose fix is obvious and inside the authorized mutation boundary is applied and reported in a compact applied-changes list. Question rounds are reserved for genuine forks — scope changes, user-visible tradeoffs, anything hard to reverse — and are batched, up to four questions per round, never one round per finding.\n- Optional extras (opening resources, offering the next review or a follow-up phase) never get their own question round at `session`/`hobby`: fold them into an existing round or a one-line closing offer.\n\nFor office-hours specifically: at session or hobby scale, batch the Phase 2B questions (this refines the one-at-a-time rule, whose pressure exists for startup diagnostics), default-skip the Phase 2.75 landscape search, gate the visual sketch and outside design voices on an explicit ask, and cap the Spec Review Loop at one iteration." }, { "classification": "INTENTIONAL_IMPROVEMENT", diff --git a/evals/parity/transcripts/policy-units.json b/evals/parity/transcripts/policy-units.json index dfb5fe9777..2a076b8cbf 100644 --- a/evals/parity/transcripts/policy-units.json +++ b/evals/parity/transcripts/policy-units.json @@ -43,7 +43,7 @@ "prompt_sha256": "a0fcff9cad68f9305da861fa5a58990e1ef51d9d84298fe2df7ba8a2f56b1dba", "semantic_attempt_sha256": "7724c3d954f421753c597364c383bd76bc01ba9803f99fb14488287bb925aeb6" }, - "policy_sha256": "c7df25a16073d69da15243f258a2ef72a69c03ee3114eac2c19cf1c7e126532b", + "policy_sha256": "22215ded6036aa1872f3a37b58503bb44c35b535b4acc208eea71aff86fce16c", "policy_present": true, "prompt_is_not_authority_input": true, "verdict": "PASS" @@ -88,7 +88,7 @@ "prompt_sha256": "04d82a21358f188cb823dcceeecaebea0b4ed8b9c1f8d00220ef3b499c48b1c8", "semantic_attempt_sha256": "9639406995955284517acb30f56b37dedc42a6c08142163dfa8fe0295105cbbf" }, - "policy_sha256": "8dd78f6f8e01eb9cf1fe0f3f43d7fcd072a4f3f2f0dc14d9f1b5d3ff1250b972", + "policy_sha256": "52fd639558834ab81fc82c2445399ca707c26af55a8da30edc72d049e3acb264", "policy_present": true, "prompt_is_not_authority_input": true, "verdict": "PASS" @@ -138,7 +138,7 @@ "prompt_sha256": "8ad639f708a2ccd5c7c438b1dedf6afacdfa4eac3883a7a046ea23f29314e1c4", "semantic_attempt_sha256": "4c450039e4c622fbeaa34b7f7dfc810d3b7369aaf7e5f4d240cd6cc18a31331a" }, - "policy_sha256": "7c7ccb7ff64ea6c73b668848ae5a663606798abc345d7e5c6bb0880732bb29c3", + "policy_sha256": "8061aa7c71a72267a03e4a51d61a598c3c3d2b700be53ba08f1f90ee800ea0bf", "policy_present": true, "prompt_is_not_authority_input": true, "verdict": "PASS" @@ -188,7 +188,7 @@ "prompt_sha256": "d2aa9aee06a116bf04cb62772e8abdf8dbd606811b6d38565389c88e86c79ede", "semantic_attempt_sha256": "64885a66bdc6688b880cbb9a59babf314834c068eb040657501bf287bfcb0d2b" }, - "policy_sha256": "c7df25a16073d69da15243f258a2ef72a69c03ee3114eac2c19cf1c7e126532b", + "policy_sha256": "22215ded6036aa1872f3a37b58503bb44c35b535b4acc208eea71aff86fce16c", "policy_present": true, "prompt_is_not_authority_input": true, "verdict": "PASS" @@ -232,7 +232,7 @@ "prompt_sha256": "377e3a2dfc7b04272f857d27e77c9aa3c9f36c3feb63c03e5aee3ecd3dea8e2a", "semantic_attempt_sha256": "a49b1528091886749278dc22e7da4556c090800989b2bca9c0e1c09dd880fed7" }, - "policy_sha256": "7969ac784f398b09cec2ad44f623de95f1e326721043272b12aaec1c622e840c", + "policy_sha256": "6f87de77b02031d391534ff4299e6a6ca3617446aea23de9ecf70f7877bb77a0", "policy_present": true, "prompt_is_not_authority_input": true, "verdict": "PASS" @@ -279,7 +279,7 @@ "prompt_sha256": "a01bb977de84e53d8ce3dfa427bcc93d73c6e449cd4e9c1ff63b436fd41fb0d1", "semantic_attempt_sha256": "ce5c64c62c3ff9b60949f34717dffbc908f62ce30f8a4a48ec182eba4363a206" }, - "policy_sha256": "4134088a9b22fd7d3d2d6492c812ecbc55650df25ab1101189dd24721fe1763d", + "policy_sha256": "7e0b3eaf8d242015b347bf352ab9eb1b29e3cc3b9047ded0d4abd6429126b500", "policy_present": true, "prompt_is_not_authority_input": true, "verdict": "PASS" @@ -330,7 +330,7 @@ "prompt_sha256": "95e97e26268ad7e509527e0f54c943ed6c4105d919f250648a2ad59ce77cbdb9", "semantic_attempt_sha256": "dacd11a78e32aeb6c0065496bedd4a9770f7bbac1036e003d3768fac41eb84f0" }, - "policy_sha256": "c7df25a16073d69da15243f258a2ef72a69c03ee3114eac2c19cf1c7e126532b", + "policy_sha256": "22215ded6036aa1872f3a37b58503bb44c35b535b4acc208eea71aff86fce16c", "policy_present": true, "prompt_is_not_authority_input": true, "verdict": "PASS" @@ -381,7 +381,7 @@ "prompt_sha256": "bdd7e8adfa7c15cf8531f84c3adaaacc725075f1a78f7487225300750547b82d", "semantic_attempt_sha256": "32c11b63412c5d873ff29dcc87c45bef1b50daa218a5c6c1075864aa24d7c3b6" }, - "policy_sha256": "c7df25a16073d69da15243f258a2ef72a69c03ee3114eac2c19cf1c7e126532b", + "policy_sha256": "22215ded6036aa1872f3a37b58503bb44c35b535b4acc208eea71aff86fce16c", "policy_present": true, "prompt_is_not_authority_input": true, "verdict": "PASS" @@ -426,7 +426,7 @@ "prompt_sha256": "51b7d53bc342e8632e34ae31a167cbde568ab5ee2a6dd2ccc980583a30604164", "semantic_attempt_sha256": "06f77b27c9bd360562655b23ca00a0dd021bdb14ebaaf3d836845e4e0cb43d68" }, - "policy_sha256": "226f7b3d386e486e58d301ca48575a100086fc523d9b6d3b333d5f2311b3f41a", + "policy_sha256": "f3ee13490333d9703903fe2dca012dbd5d8868696ad5db2a31768fee90063399", "policy_present": true, "prompt_is_not_authority_input": true, "verdict": "PASS" diff --git a/skills/debug/references/SHARED-JUDGMENT.md b/skills/debug/references/SHARED-JUDGMENT.md index 236316f215..0db5d4da05 100644 --- a/skills/debug/references/SHARED-JUDGMENT.md +++ b/skills/debug/references/SHARED-JUDGMENT.md @@ -12,4 +12,6 @@ This contract constrains every specialist without replacing specialist judgment. 7. Preview artifacts and diffs before approval. Approval remains mandatory before merge, deploy, destructive mutation, or spending. 8. Match the user language. Empty or contradictory evidence blocks confident success. 9. Recommendations remain traceable downstream, including what evidence would change them. -10. The user makes the final decision. +10. Ask only what cannot be inferred. Question rounds are for decisions that are consequential and still open after the prompt, the repository, and platform convention are consulted; infer the rest, state each inferred default in one line, and batch what remains. Never spend a round confirming what a handoff already names or offering optional extras. +11. A user-stated time constraint binds every phase and every chained skill. Skip or compress optional phases that do not fit it, noting each skip in one line. +12. The user makes the final decision. diff --git a/skills/design/references/SHARED-JUDGMENT.md b/skills/design/references/SHARED-JUDGMENT.md index 236316f215..0db5d4da05 100644 --- a/skills/design/references/SHARED-JUDGMENT.md +++ b/skills/design/references/SHARED-JUDGMENT.md @@ -12,4 +12,6 @@ This contract constrains every specialist without replacing specialist judgment. 7. Preview artifacts and diffs before approval. Approval remains mandatory before merge, deploy, destructive mutation, or spending. 8. Match the user language. Empty or contradictory evidence blocks confident success. 9. Recommendations remain traceable downstream, including what evidence would change them. -10. The user makes the final decision. +10. Ask only what cannot be inferred. Question rounds are for decisions that are consequential and still open after the prompt, the repository, and platform convention are consulted; infer the rest, state each inferred default in one line, and batch what remains. Never spend a round confirming what a handoff already names or offering optional extras. +11. A user-stated time constraint binds every phase and every chained skill. Skip or compress optional phases that do not fit it, noting each skip in one line. +12. The user makes the final decision. diff --git a/skills/design/references/legacy/design-review.md b/skills/design/references/legacy/design-review.md index e0aeebe586..cdaadf1c73 100644 --- a/skills/design/references/legacy/design-review.md +++ b/skills/design/references/legacy/design-review.md @@ -1135,6 +1135,31 @@ Accept a coherent design thesis expressed through product principles, visual rat Rate every audited screen on a System 1 to System 2 scale from 0 to 10, grounded in browse data already collected (element counts, link counts, load times), not impression. Most screens should sit at S1 (0-3); higher scores are acceptable only as intentional friction such as destructive or financial decisions. For any screen above the threshold that is not deliberate friction, name the specific UX laws it breaks (Fitts, Hick, Jakob, Miller, Peak-End, Von Restorff, Zeigarnik, Gestalt) and cite the measurement that proves it. + +## Upstream judgment port: issue #886 + +[Scale planning machinery to the printed build scale](https://github.com/garrytan/gstack/issues/886) + +### Proportional planning for the printed build scale + +The /plan dispatcher prints a `Scale:` header line classified from fifteen build-scale vectors (its Build scale section). This rule authorizes every planning and review specialist to size its machinery to that scale while keeping every STOP gate and approval boundary; a polite user answering every question is not evidence the full machinery is wanted, and the user can always ask for the complete treatment. + +The binding scale comes from the first available source: the printed `Scale:` header, a chain handoff that names a scale or time box, or on-the-spot classification from the prompt and cheap repository evidence. An explicit user time constraint is a ceiling, not one vector among fifteen: work that must fit one sitting caps the scale at `session`, and a day-or-two deadline caps it at `hobby`, regardless of higher vectors. A chained invocation inherits the upstream scale and time box without re-asking, and every handoff it emits carries them forward. + +- `session` and `hobby`: batch every question the initial prompt left unanswered into one AskUserQuestion round (two rounds for hobby); skip web or landscape research, outside voices, second opinions, and visual sketches unless the user asks (privacy gates are unchanged whenever they run); cap any adversarial or spec review loop at one iteration; keep the decision artifact near one page with next steps sized in hours (session) or days (hobby), never a phased multi-week roadmap or a distribution plan the user did not ask for. +- `project`: run the specialist's default workflow, batching question rounds where its source authorizes smart skips; size the roadmap in weeks. +- `product` and `venture`: the full specialist workflow and its complete question pressure apply; this rule removes nothing. +- Never run a questioning round merely to classify scale. Classify from the prompt and cheap repository evidence, defaulting unknown vectors low; a specialist's own later questions may raise the scale mid-session, and an upgrade restores the full workflow from that point. + +Review specialists spend question rounds on decisions, not ceremony — at every scale, and sharpest at `session`/`hobby`: + +- When the handoff or prompt names the review target unambiguously, print it on the Target line and proceed. Re-confirming a target the chain already fixed is not a STOP gate; the target gate exists for genuinely ambiguous targets. +- A finding whose fix is obvious and inside the authorized mutation boundary is applied and reported in a compact applied-changes list. Question rounds are reserved for genuine forks — scope changes, user-visible tradeoffs, anything hard to reverse — and are batched, up to four questions per round, never one round per finding. +- Optional extras (opening resources, offering the next review or a follow-up phase) never get their own question round at `session`/`hobby`: fold them into an existing round or a one-line closing offer. + +For office-hours specifically: at session or hobby scale, batch the Phase 2B questions (this refines the one-at-a-time rule, whose pressure exists for startup diagnostics), default-skip the Phase 2.75 landscape search, gate the visual sketch and outside design voices on an explicit ask, and cap the Spec Review Loop at one iteration. + + ## Upstream judgment port: issue #879 diff --git a/skills/design/references/legacy/plan-design-review.md b/skills/design/references/legacy/plan-design-review.md index 49cc9dfb76..a2ed85e9e3 100644 --- a/skills/design/references/legacy/plan-design-review.md +++ b/skills/design/references/legacy/plan-design-review.md @@ -650,6 +650,31 @@ Persist a learning only when the interaction contains a useful, reusable signal Accept a coherent design thesis expressed through product principles, visual rationale, interaction philosophy, or equivalent framing. Evaluate substance and consistency; do not require a literal “design thesis” heading or one exact vocabulary to award credit. + +## Upstream judgment port: issue #886 + +[Scale planning machinery to the printed build scale](https://github.com/garrytan/gstack/issues/886) + +### Proportional planning for the printed build scale + +The /plan dispatcher prints a `Scale:` header line classified from fifteen build-scale vectors (its Build scale section). This rule authorizes every planning and review specialist to size its machinery to that scale while keeping every STOP gate and approval boundary; a polite user answering every question is not evidence the full machinery is wanted, and the user can always ask for the complete treatment. + +The binding scale comes from the first available source: the printed `Scale:` header, a chain handoff that names a scale or time box, or on-the-spot classification from the prompt and cheap repository evidence. An explicit user time constraint is a ceiling, not one vector among fifteen: work that must fit one sitting caps the scale at `session`, and a day-or-two deadline caps it at `hobby`, regardless of higher vectors. A chained invocation inherits the upstream scale and time box without re-asking, and every handoff it emits carries them forward. + +- `session` and `hobby`: batch every question the initial prompt left unanswered into one AskUserQuestion round (two rounds for hobby); skip web or landscape research, outside voices, second opinions, and visual sketches unless the user asks (privacy gates are unchanged whenever they run); cap any adversarial or spec review loop at one iteration; keep the decision artifact near one page with next steps sized in hours (session) or days (hobby), never a phased multi-week roadmap or a distribution plan the user did not ask for. +- `project`: run the specialist's default workflow, batching question rounds where its source authorizes smart skips; size the roadmap in weeks. +- `product` and `venture`: the full specialist workflow and its complete question pressure apply; this rule removes nothing. +- Never run a questioning round merely to classify scale. Classify from the prompt and cheap repository evidence, defaulting unknown vectors low; a specialist's own later questions may raise the scale mid-session, and an upgrade restores the full workflow from that point. + +Review specialists spend question rounds on decisions, not ceremony — at every scale, and sharpest at `session`/`hobby`: + +- When the handoff or prompt names the review target unambiguously, print it on the Target line and proceed. Re-confirming a target the chain already fixed is not a STOP gate; the target gate exists for genuinely ambiguous targets. +- A finding whose fix is obvious and inside the authorized mutation boundary is applied and reported in a compact applied-changes list. Question rounds are reserved for genuine forks — scope changes, user-visible tradeoffs, anything hard to reverse — and are batched, up to four questions per round, never one round per finding. +- Optional extras (opening resources, offering the next review or a follow-up phase) never get their own question round at `session`/`hobby`: fold them into an existing round or a one-line closing offer. + +For office-hours specifically: at session or hobby scale, batch the Phase 2B questions (this refines the one-at-a-time rule, whose pressure exists for startup diagnostics), default-skip the Phase 2.75 landscape search, gate the visual sketch and outside design voices on an explicit ask, and cap the Spec Review Loop at one iteration. + + ## Upstream judgment port: issue #879 diff --git a/skills/plan/SKILL.md b/skills/plan/SKILL.md index e7809662fb..1fbc777c40 100644 --- a/skills/plan/SKILL.md +++ b/skills/plan/SKILL.md @@ -48,6 +48,10 @@ Vectors: audience (self → friends/team → public), expected users (none → h The highest tier any vector demands wins: `session` (all vectors low — one sitting, for fun, self only), `hobby` (kept personal tool, days), `project` (shared or in a real repo, weeks), `product` (external users, hosted, revenue intent), `venture` (startup ambition, platform/API surface, team, months+). "A cool space animation in my terminal" is session-scale. "A startup with customizable APIs" is venture-scale. Print the result on the header's Scale line with the two or three vectors that decided it. +An explicit user time constraint is a ceiling, not one vector among fifteen: work that must fit one sitting (a hackathon demo, a stated hour count, "before my flight") caps the scale at `session`, and a day-or-two deadline caps it at `hobby`, no matter how public the audience or how ambitious the idea. The user's clock outranks every ambition vector. Print the constraint with the scale: `Scale: session (hackathon, one sitting)`. + +The scale binds the whole chain, not just this invocation. Every handoff to a chained review or specialist names the scale and any time box, and the receiving workflow applies its proportional-planning port to the inherited scale without re-asking or re-classifying upward. + ## Top-level modes diff --git a/skills/plan/references/SHARED-JUDGMENT.md b/skills/plan/references/SHARED-JUDGMENT.md index 236316f215..0db5d4da05 100644 --- a/skills/plan/references/SHARED-JUDGMENT.md +++ b/skills/plan/references/SHARED-JUDGMENT.md @@ -12,4 +12,6 @@ This contract constrains every specialist without replacing specialist judgment. 7. Preview artifacts and diffs before approval. Approval remains mandatory before merge, deploy, destructive mutation, or spending. 8. Match the user language. Empty or contradictory evidence blocks confident success. 9. Recommendations remain traceable downstream, including what evidence would change them. -10. The user makes the final decision. +10. Ask only what cannot be inferred. Question rounds are for decisions that are consequential and still open after the prompt, the repository, and platform convention are consulted; infer the rest, state each inferred default in one line, and batch what remains. Never spend a round confirming what a handoff already names or offering optional extras. +11. A user-stated time constraint binds every phase and every chained skill. Skip or compress optional phases that do not fit it, noting each skip in one line. +12. The user makes the final decision. diff --git a/skills/plan/references/legacy/autoplan.md b/skills/plan/references/legacy/autoplan.md index aa40a26ac8..f87550a2ee 100644 --- a/skills/plan/references/legacy/autoplan.md +++ b/skills/plan/references/legacy/autoplan.md @@ -1096,13 +1096,21 @@ When only one model produced a review row, label it **Claude-only** or **Codex-o ### Proportional planning for the printed build scale -The /plan dispatcher prints a `Scale:` header line classified from fifteen build-scale vectors (its Build scale section). This rule authorizes every planning specialist to size its machinery to that scale while keeping every STOP gate and approval boundary; a polite user answering every question is not evidence the full machinery is wanted, and the user can always ask for the complete treatment. +The /plan dispatcher prints a `Scale:` header line classified from fifteen build-scale vectors (its Build scale section). This rule authorizes every planning and review specialist to size its machinery to that scale while keeping every STOP gate and approval boundary; a polite user answering every question is not evidence the full machinery is wanted, and the user can always ask for the complete treatment. + +The binding scale comes from the first available source: the printed `Scale:` header, a chain handoff that names a scale or time box, or on-the-spot classification from the prompt and cheap repository evidence. An explicit user time constraint is a ceiling, not one vector among fifteen: work that must fit one sitting caps the scale at `session`, and a day-or-two deadline caps it at `hobby`, regardless of higher vectors. A chained invocation inherits the upstream scale and time box without re-asking, and every handoff it emits carries them forward. - `session` and `hobby`: batch every question the initial prompt left unanswered into one AskUserQuestion round (two rounds for hobby); skip web or landscape research, outside voices, second opinions, and visual sketches unless the user asks (privacy gates are unchanged whenever they run); cap any adversarial or spec review loop at one iteration; keep the decision artifact near one page with next steps sized in hours (session) or days (hobby), never a phased multi-week roadmap or a distribution plan the user did not ask for. - `project`: run the specialist's default workflow, batching question rounds where its source authorizes smart skips; size the roadmap in weeks. - `product` and `venture`: the full specialist workflow and its complete question pressure apply; this rule removes nothing. - Never run a questioning round merely to classify scale. Classify from the prompt and cheap repository evidence, defaulting unknown vectors low; a specialist's own later questions may raise the scale mid-session, and an upgrade restores the full workflow from that point. +Review specialists spend question rounds on decisions, not ceremony — at every scale, and sharpest at `session`/`hobby`: + +- When the handoff or prompt names the review target unambiguously, print it on the Target line and proceed. Re-confirming a target the chain already fixed is not a STOP gate; the target gate exists for genuinely ambiguous targets. +- A finding whose fix is obvious and inside the authorized mutation boundary is applied and reported in a compact applied-changes list. Question rounds are reserved for genuine forks — scope changes, user-visible tradeoffs, anything hard to reverse — and are batched, up to four questions per round, never one round per finding. +- Optional extras (opening resources, offering the next review or a follow-up phase) never get their own question round at `session`/`hobby`: fold them into an existing round or a one-line closing offer. + For office-hours specifically: at session or hobby scale, batch the Phase 2B questions (this refines the one-at-a-time rule, whose pressure exists for startup diagnostics), default-skip the Phase 2.75 landscape search, gate the visual sketch and outside design voices on an explicit ask, and cap the Spec Review Loop at one iteration. diff --git a/skills/plan/references/legacy/office-hours.md b/skills/plan/references/legacy/office-hours.md index d021036d0a..9a2c2d2e96 100644 --- a/skills/plan/references/legacy/office-hours.md +++ b/skills/plan/references/legacy/office-hours.md @@ -778,13 +778,21 @@ At the Phase 5 approval gate, print the full design-doc body as direct assistant ### Proportional planning for the printed build scale -The /plan dispatcher prints a `Scale:` header line classified from fifteen build-scale vectors (its Build scale section). This rule authorizes every planning specialist to size its machinery to that scale while keeping every STOP gate and approval boundary; a polite user answering every question is not evidence the full machinery is wanted, and the user can always ask for the complete treatment. +The /plan dispatcher prints a `Scale:` header line classified from fifteen build-scale vectors (its Build scale section). This rule authorizes every planning and review specialist to size its machinery to that scale while keeping every STOP gate and approval boundary; a polite user answering every question is not evidence the full machinery is wanted, and the user can always ask for the complete treatment. + +The binding scale comes from the first available source: the printed `Scale:` header, a chain handoff that names a scale or time box, or on-the-spot classification from the prompt and cheap repository evidence. An explicit user time constraint is a ceiling, not one vector among fifteen: work that must fit one sitting caps the scale at `session`, and a day-or-two deadline caps it at `hobby`, regardless of higher vectors. A chained invocation inherits the upstream scale and time box without re-asking, and every handoff it emits carries them forward. - `session` and `hobby`: batch every question the initial prompt left unanswered into one AskUserQuestion round (two rounds for hobby); skip web or landscape research, outside voices, second opinions, and visual sketches unless the user asks (privacy gates are unchanged whenever they run); cap any adversarial or spec review loop at one iteration; keep the decision artifact near one page with next steps sized in hours (session) or days (hobby), never a phased multi-week roadmap or a distribution plan the user did not ask for. - `project`: run the specialist's default workflow, batching question rounds where its source authorizes smart skips; size the roadmap in weeks. - `product` and `venture`: the full specialist workflow and its complete question pressure apply; this rule removes nothing. - Never run a questioning round merely to classify scale. Classify from the prompt and cheap repository evidence, defaulting unknown vectors low; a specialist's own later questions may raise the scale mid-session, and an upgrade restores the full workflow from that point. +Review specialists spend question rounds on decisions, not ceremony — at every scale, and sharpest at `session`/`hobby`: + +- When the handoff or prompt names the review target unambiguously, print it on the Target line and proceed. Re-confirming a target the chain already fixed is not a STOP gate; the target gate exists for genuinely ambiguous targets. +- A finding whose fix is obvious and inside the authorized mutation boundary is applied and reported in a compact applied-changes list. Question rounds are reserved for genuine forks — scope changes, user-visible tradeoffs, anything hard to reverse — and are batched, up to four questions per round, never one round per finding. +- Optional extras (opening resources, offering the next review or a follow-up phase) never get their own question round at `session`/`hobby`: fold them into an existing round or a one-line closing offer. + For office-hours specifically: at session or hobby scale, batch the Phase 2B questions (this refines the one-at-a-time rule, whose pressure exists for startup diagnostics), default-skip the Phase 2.75 landscape search, gate the visual sketch and outside design voices on an explicit ask, and cap the Spec Review Loop at one iteration. diff --git a/skills/plan/references/legacy/plan-ceo-review.md b/skills/plan/references/legacy/plan-ceo-review.md index 3c0ebaf728..e26fe81f8b 100644 --- a/skills/plan/references/legacy/plan-ceo-review.md +++ b/skills/plan/references/legacy/plan-ceo-review.md @@ -655,13 +655,21 @@ Persist a learning only when the interaction contains a useful, reusable signal ### Proportional planning for the printed build scale -The /plan dispatcher prints a `Scale:` header line classified from fifteen build-scale vectors (its Build scale section). This rule authorizes every planning specialist to size its machinery to that scale while keeping every STOP gate and approval boundary; a polite user answering every question is not evidence the full machinery is wanted, and the user can always ask for the complete treatment. +The /plan dispatcher prints a `Scale:` header line classified from fifteen build-scale vectors (its Build scale section). This rule authorizes every planning and review specialist to size its machinery to that scale while keeping every STOP gate and approval boundary; a polite user answering every question is not evidence the full machinery is wanted, and the user can always ask for the complete treatment. + +The binding scale comes from the first available source: the printed `Scale:` header, a chain handoff that names a scale or time box, or on-the-spot classification from the prompt and cheap repository evidence. An explicit user time constraint is a ceiling, not one vector among fifteen: work that must fit one sitting caps the scale at `session`, and a day-or-two deadline caps it at `hobby`, regardless of higher vectors. A chained invocation inherits the upstream scale and time box without re-asking, and every handoff it emits carries them forward. - `session` and `hobby`: batch every question the initial prompt left unanswered into one AskUserQuestion round (two rounds for hobby); skip web or landscape research, outside voices, second opinions, and visual sketches unless the user asks (privacy gates are unchanged whenever they run); cap any adversarial or spec review loop at one iteration; keep the decision artifact near one page with next steps sized in hours (session) or days (hobby), never a phased multi-week roadmap or a distribution plan the user did not ask for. - `project`: run the specialist's default workflow, batching question rounds where its source authorizes smart skips; size the roadmap in weeks. - `product` and `venture`: the full specialist workflow and its complete question pressure apply; this rule removes nothing. - Never run a questioning round merely to classify scale. Classify from the prompt and cheap repository evidence, defaulting unknown vectors low; a specialist's own later questions may raise the scale mid-session, and an upgrade restores the full workflow from that point. +Review specialists spend question rounds on decisions, not ceremony — at every scale, and sharpest at `session`/`hobby`: + +- When the handoff or prompt names the review target unambiguously, print it on the Target line and proceed. Re-confirming a target the chain already fixed is not a STOP gate; the target gate exists for genuinely ambiguous targets. +- A finding whose fix is obvious and inside the authorized mutation boundary is applied and reported in a compact applied-changes list. Question rounds are reserved for genuine forks — scope changes, user-visible tradeoffs, anything hard to reverse — and are batched, up to four questions per round, never one round per finding. +- Optional extras (opening resources, offering the next review or a follow-up phase) never get their own question round at `session`/`hobby`: fold them into an existing round or a one-line closing offer. + For office-hours specifically: at session or hobby scale, batch the Phase 2B questions (this refines the one-at-a-time rule, whose pressure exists for startup diagnostics), default-skip the Phase 2.75 landscape search, gate the visual sketch and outside design voices on an explicit ask, and cap the Spec Review Loop at one iteration. diff --git a/skills/plan/references/legacy/plan-design-review.md b/skills/plan/references/legacy/plan-design-review.md index 49cc9dfb76..a2ed85e9e3 100644 --- a/skills/plan/references/legacy/plan-design-review.md +++ b/skills/plan/references/legacy/plan-design-review.md @@ -650,6 +650,31 @@ Persist a learning only when the interaction contains a useful, reusable signal Accept a coherent design thesis expressed through product principles, visual rationale, interaction philosophy, or equivalent framing. Evaluate substance and consistency; do not require a literal “design thesis” heading or one exact vocabulary to award credit. + +## Upstream judgment port: issue #886 + +[Scale planning machinery to the printed build scale](https://github.com/garrytan/gstack/issues/886) + +### Proportional planning for the printed build scale + +The /plan dispatcher prints a `Scale:` header line classified from fifteen build-scale vectors (its Build scale section). This rule authorizes every planning and review specialist to size its machinery to that scale while keeping every STOP gate and approval boundary; a polite user answering every question is not evidence the full machinery is wanted, and the user can always ask for the complete treatment. + +The binding scale comes from the first available source: the printed `Scale:` header, a chain handoff that names a scale or time box, or on-the-spot classification from the prompt and cheap repository evidence. An explicit user time constraint is a ceiling, not one vector among fifteen: work that must fit one sitting caps the scale at `session`, and a day-or-two deadline caps it at `hobby`, regardless of higher vectors. A chained invocation inherits the upstream scale and time box without re-asking, and every handoff it emits carries them forward. + +- `session` and `hobby`: batch every question the initial prompt left unanswered into one AskUserQuestion round (two rounds for hobby); skip web or landscape research, outside voices, second opinions, and visual sketches unless the user asks (privacy gates are unchanged whenever they run); cap any adversarial or spec review loop at one iteration; keep the decision artifact near one page with next steps sized in hours (session) or days (hobby), never a phased multi-week roadmap or a distribution plan the user did not ask for. +- `project`: run the specialist's default workflow, batching question rounds where its source authorizes smart skips; size the roadmap in weeks. +- `product` and `venture`: the full specialist workflow and its complete question pressure apply; this rule removes nothing. +- Never run a questioning round merely to classify scale. Classify from the prompt and cheap repository evidence, defaulting unknown vectors low; a specialist's own later questions may raise the scale mid-session, and an upgrade restores the full workflow from that point. + +Review specialists spend question rounds on decisions, not ceremony — at every scale, and sharpest at `session`/`hobby`: + +- When the handoff or prompt names the review target unambiguously, print it on the Target line and proceed. Re-confirming a target the chain already fixed is not a STOP gate; the target gate exists for genuinely ambiguous targets. +- A finding whose fix is obvious and inside the authorized mutation boundary is applied and reported in a compact applied-changes list. Question rounds are reserved for genuine forks — scope changes, user-visible tradeoffs, anything hard to reverse — and are batched, up to four questions per round, never one round per finding. +- Optional extras (opening resources, offering the next review or a follow-up phase) never get their own question round at `session`/`hobby`: fold them into an existing round or a one-line closing offer. + +For office-hours specifically: at session or hobby scale, batch the Phase 2B questions (this refines the one-at-a-time rule, whose pressure exists for startup diagnostics), default-skip the Phase 2.75 landscape search, gate the visual sketch and outside design voices on an explicit ask, and cap the Spec Review Loop at one iteration. + + ## Upstream judgment port: issue #879 diff --git a/skills/plan/references/legacy/plan-devex-review.md b/skills/plan/references/legacy/plan-devex-review.md index 26b96d2f2f..d9fef3dc62 100644 --- a/skills/plan/references/legacy/plan-devex-review.md +++ b/skills/plan/references/legacy/plan-devex-review.md @@ -693,13 +693,21 @@ Persist a learning only when the interaction contains a useful, reusable signal ### Proportional planning for the printed build scale -The /plan dispatcher prints a `Scale:` header line classified from fifteen build-scale vectors (its Build scale section). This rule authorizes every planning specialist to size its machinery to that scale while keeping every STOP gate and approval boundary; a polite user answering every question is not evidence the full machinery is wanted, and the user can always ask for the complete treatment. +The /plan dispatcher prints a `Scale:` header line classified from fifteen build-scale vectors (its Build scale section). This rule authorizes every planning and review specialist to size its machinery to that scale while keeping every STOP gate and approval boundary; a polite user answering every question is not evidence the full machinery is wanted, and the user can always ask for the complete treatment. + +The binding scale comes from the first available source: the printed `Scale:` header, a chain handoff that names a scale or time box, or on-the-spot classification from the prompt and cheap repository evidence. An explicit user time constraint is a ceiling, not one vector among fifteen: work that must fit one sitting caps the scale at `session`, and a day-or-two deadline caps it at `hobby`, regardless of higher vectors. A chained invocation inherits the upstream scale and time box without re-asking, and every handoff it emits carries them forward. - `session` and `hobby`: batch every question the initial prompt left unanswered into one AskUserQuestion round (two rounds for hobby); skip web or landscape research, outside voices, second opinions, and visual sketches unless the user asks (privacy gates are unchanged whenever they run); cap any adversarial or spec review loop at one iteration; keep the decision artifact near one page with next steps sized in hours (session) or days (hobby), never a phased multi-week roadmap or a distribution plan the user did not ask for. - `project`: run the specialist's default workflow, batching question rounds where its source authorizes smart skips; size the roadmap in weeks. - `product` and `venture`: the full specialist workflow and its complete question pressure apply; this rule removes nothing. - Never run a questioning round merely to classify scale. Classify from the prompt and cheap repository evidence, defaulting unknown vectors low; a specialist's own later questions may raise the scale mid-session, and an upgrade restores the full workflow from that point. +Review specialists spend question rounds on decisions, not ceremony — at every scale, and sharpest at `session`/`hobby`: + +- When the handoff or prompt names the review target unambiguously, print it on the Target line and proceed. Re-confirming a target the chain already fixed is not a STOP gate; the target gate exists for genuinely ambiguous targets. +- A finding whose fix is obvious and inside the authorized mutation boundary is applied and reported in a compact applied-changes list. Question rounds are reserved for genuine forks — scope changes, user-visible tradeoffs, anything hard to reverse — and are batched, up to four questions per round, never one round per finding. +- Optional extras (opening resources, offering the next review or a follow-up phase) never get their own question round at `session`/`hobby`: fold them into an existing round or a one-line closing offer. + For office-hours specifically: at session or hobby scale, batch the Phase 2B questions (this refines the one-at-a-time rule, whose pressure exists for startup diagnostics), default-skip the Phase 2.75 landscape search, gate the visual sketch and outside design voices on an explicit ask, and cap the Spec Review Loop at one iteration. diff --git a/skills/plan/references/legacy/plan-eng-review.md b/skills/plan/references/legacy/plan-eng-review.md index b9b74ec5ec..b610f79237 100644 --- a/skills/plan/references/legacy/plan-eng-review.md +++ b/skills/plan/references/legacy/plan-eng-review.md @@ -303,13 +303,21 @@ Before reviewing anything, run a pre-mortem: it is three months later and this p ### Proportional planning for the printed build scale -The /plan dispatcher prints a `Scale:` header line classified from fifteen build-scale vectors (its Build scale section). This rule authorizes every planning specialist to size its machinery to that scale while keeping every STOP gate and approval boundary; a polite user answering every question is not evidence the full machinery is wanted, and the user can always ask for the complete treatment. +The /plan dispatcher prints a `Scale:` header line classified from fifteen build-scale vectors (its Build scale section). This rule authorizes every planning and review specialist to size its machinery to that scale while keeping every STOP gate and approval boundary; a polite user answering every question is not evidence the full machinery is wanted, and the user can always ask for the complete treatment. + +The binding scale comes from the first available source: the printed `Scale:` header, a chain handoff that names a scale or time box, or on-the-spot classification from the prompt and cheap repository evidence. An explicit user time constraint is a ceiling, not one vector among fifteen: work that must fit one sitting caps the scale at `session`, and a day-or-two deadline caps it at `hobby`, regardless of higher vectors. A chained invocation inherits the upstream scale and time box without re-asking, and every handoff it emits carries them forward. - `session` and `hobby`: batch every question the initial prompt left unanswered into one AskUserQuestion round (two rounds for hobby); skip web or landscape research, outside voices, second opinions, and visual sketches unless the user asks (privacy gates are unchanged whenever they run); cap any adversarial or spec review loop at one iteration; keep the decision artifact near one page with next steps sized in hours (session) or days (hobby), never a phased multi-week roadmap or a distribution plan the user did not ask for. - `project`: run the specialist's default workflow, batching question rounds where its source authorizes smart skips; size the roadmap in weeks. - `product` and `venture`: the full specialist workflow and its complete question pressure apply; this rule removes nothing. - Never run a questioning round merely to classify scale. Classify from the prompt and cheap repository evidence, defaulting unknown vectors low; a specialist's own later questions may raise the scale mid-session, and an upgrade restores the full workflow from that point. +Review specialists spend question rounds on decisions, not ceremony — at every scale, and sharpest at `session`/`hobby`: + +- When the handoff or prompt names the review target unambiguously, print it on the Target line and proceed. Re-confirming a target the chain already fixed is not a STOP gate; the target gate exists for genuinely ambiguous targets. +- A finding whose fix is obvious and inside the authorized mutation boundary is applied and reported in a compact applied-changes list. Question rounds are reserved for genuine forks — scope changes, user-visible tradeoffs, anything hard to reverse — and are batched, up to four questions per round, never one round per finding. +- Optional extras (opening resources, offering the next review or a follow-up phase) never get their own question round at `session`/`hobby`: fold them into an existing round or a one-line closing offer. + For office-hours specifically: at session or hobby scale, batch the Phase 2B questions (this refines the one-at-a-time rule, whose pressure exists for startup diagnostics), default-skip the Phase 2.75 landscape search, gate the visual sketch and outside design voices on an explicit ask, and cap the Spec Review Loop at one iteration. diff --git a/skills/plan/references/legacy/spec.md b/skills/plan/references/legacy/spec.md index 0c6bff0241..3b92c7d109 100644 --- a/skills/plan/references/legacy/spec.md +++ b/skills/plan/references/legacy/spec.md @@ -813,13 +813,21 @@ Write questions, progress updates, reports, and artifacts in the language used b ### Proportional planning for the printed build scale -The /plan dispatcher prints a `Scale:` header line classified from fifteen build-scale vectors (its Build scale section). This rule authorizes every planning specialist to size its machinery to that scale while keeping every STOP gate and approval boundary; a polite user answering every question is not evidence the full machinery is wanted, and the user can always ask for the complete treatment. +The /plan dispatcher prints a `Scale:` header line classified from fifteen build-scale vectors (its Build scale section). This rule authorizes every planning and review specialist to size its machinery to that scale while keeping every STOP gate and approval boundary; a polite user answering every question is not evidence the full machinery is wanted, and the user can always ask for the complete treatment. + +The binding scale comes from the first available source: the printed `Scale:` header, a chain handoff that names a scale or time box, or on-the-spot classification from the prompt and cheap repository evidence. An explicit user time constraint is a ceiling, not one vector among fifteen: work that must fit one sitting caps the scale at `session`, and a day-or-two deadline caps it at `hobby`, regardless of higher vectors. A chained invocation inherits the upstream scale and time box without re-asking, and every handoff it emits carries them forward. - `session` and `hobby`: batch every question the initial prompt left unanswered into one AskUserQuestion round (two rounds for hobby); skip web or landscape research, outside voices, second opinions, and visual sketches unless the user asks (privacy gates are unchanged whenever they run); cap any adversarial or spec review loop at one iteration; keep the decision artifact near one page with next steps sized in hours (session) or days (hobby), never a phased multi-week roadmap or a distribution plan the user did not ask for. - `project`: run the specialist's default workflow, batching question rounds where its source authorizes smart skips; size the roadmap in weeks. - `product` and `venture`: the full specialist workflow and its complete question pressure apply; this rule removes nothing. - Never run a questioning round merely to classify scale. Classify from the prompt and cheap repository evidence, defaulting unknown vectors low; a specialist's own later questions may raise the scale mid-session, and an upgrade restores the full workflow from that point. +Review specialists spend question rounds on decisions, not ceremony — at every scale, and sharpest at `session`/`hobby`: + +- When the handoff or prompt names the review target unambiguously, print it on the Target line and proceed. Re-confirming a target the chain already fixed is not a STOP gate; the target gate exists for genuinely ambiguous targets. +- A finding whose fix is obvious and inside the authorized mutation boundary is applied and reported in a compact applied-changes list. Question rounds are reserved for genuine forks — scope changes, user-visible tradeoffs, anything hard to reverse — and are batched, up to four questions per round, never one round per finding. +- Optional extras (opening resources, offering the next review or a follow-up phase) never get their own question round at `session`/`hobby`: fold them into an existing round or a one-line closing offer. + For office-hours specifically: at session or hobby scale, batch the Phase 2B questions (this refines the one-at-a-time rule, whose pressure exists for startup diagnostics), default-skip the Phase 2.75 landscape search, gate the visual sketch and outside design voices on an explicit ask, and cap the Spec Review Loop at one iteration. diff --git a/skills/qa/references/SHARED-JUDGMENT.md b/skills/qa/references/SHARED-JUDGMENT.md index 236316f215..0db5d4da05 100644 --- a/skills/qa/references/SHARED-JUDGMENT.md +++ b/skills/qa/references/SHARED-JUDGMENT.md @@ -12,4 +12,6 @@ This contract constrains every specialist without replacing specialist judgment. 7. Preview artifacts and diffs before approval. Approval remains mandatory before merge, deploy, destructive mutation, or spending. 8. Match the user language. Empty or contradictory evidence blocks confident success. 9. Recommendations remain traceable downstream, including what evidence would change them. -10. The user makes the final decision. +10. Ask only what cannot be inferred. Question rounds are for decisions that are consequential and still open after the prompt, the repository, and platform convention are consulted; infer the rest, state each inferred default in one line, and batch what remains. Never spend a round confirming what a handoff already names or offering optional extras. +11. A user-stated time constraint binds every phase and every chained skill. Skip or compress optional phases that do not fit it, noting each skip in one line. +12. The user makes the final decision. diff --git a/skills/review/references/SHARED-JUDGMENT.md b/skills/review/references/SHARED-JUDGMENT.md index 236316f215..0db5d4da05 100644 --- a/skills/review/references/SHARED-JUDGMENT.md +++ b/skills/review/references/SHARED-JUDGMENT.md @@ -12,4 +12,6 @@ This contract constrains every specialist without replacing specialist judgment. 7. Preview artifacts and diffs before approval. Approval remains mandatory before merge, deploy, destructive mutation, or spending. 8. Match the user language. Empty or contradictory evidence blocks confident success. 9. Recommendations remain traceable downstream, including what evidence would change them. -10. The user makes the final decision. +10. Ask only what cannot be inferred. Question rounds are for decisions that are consequential and still open after the prompt, the repository, and platform convention are consulted; infer the rest, state each inferred default in one line, and batch what remains. Never spend a round confirming what a handoff already names or offering optional extras. +11. A user-stated time constraint binds every phase and every chained skill. Skip or compress optional phases that do not fit it, noting each skip in one line. +12. The user makes the final decision. diff --git a/skills/review/references/legacy/review.md b/skills/review/references/legacy/review.md index e0aafa27b1..f6396afc54 100644 --- a/skills/review/references/legacy/review.md +++ b/skills/review/references/legacy/review.md @@ -748,6 +748,31 @@ When a patch widens an accepted input, loosens validation, changes a default, or When the diff adds or modifies an MCP server package (`glama.json`, an `mcpServers` block in `package.json`, or a server entry point), add informational packaging checks. Flag `package.json` `exports`/`main`/`bin` that resolve into `src/` or a `.ts` file rather than the compiled `dist/` output, because registry Docker builds run the compiled artifact. Flag relative ESM imports missing `.js` extensions under `moduleResolution: "NodeNext"`/`"Node16"`, since bundler resolution hides it locally but Node ESM fails at runtime. Flag `moduleResolution: "bundler"` on a standalone Node MCP server (correct for frontend, wrong for an npm/Docker-distributed server). Flag a missing or malformed `glama.json` (needs `$schema` and a `maintainers` array). Do not flag frontend packages using `bundler`, or MCP packages consumed as libraries rather than standalone servers. + +## Upstream judgment port: issue #886 + +[Scale planning machinery to the printed build scale](https://github.com/garrytan/gstack/issues/886) + +### Proportional planning for the printed build scale + +The /plan dispatcher prints a `Scale:` header line classified from fifteen build-scale vectors (its Build scale section). This rule authorizes every planning and review specialist to size its machinery to that scale while keeping every STOP gate and approval boundary; a polite user answering every question is not evidence the full machinery is wanted, and the user can always ask for the complete treatment. + +The binding scale comes from the first available source: the printed `Scale:` header, a chain handoff that names a scale or time box, or on-the-spot classification from the prompt and cheap repository evidence. An explicit user time constraint is a ceiling, not one vector among fifteen: work that must fit one sitting caps the scale at `session`, and a day-or-two deadline caps it at `hobby`, regardless of higher vectors. A chained invocation inherits the upstream scale and time box without re-asking, and every handoff it emits carries them forward. + +- `session` and `hobby`: batch every question the initial prompt left unanswered into one AskUserQuestion round (two rounds for hobby); skip web or landscape research, outside voices, second opinions, and visual sketches unless the user asks (privacy gates are unchanged whenever they run); cap any adversarial or spec review loop at one iteration; keep the decision artifact near one page with next steps sized in hours (session) or days (hobby), never a phased multi-week roadmap or a distribution plan the user did not ask for. +- `project`: run the specialist's default workflow, batching question rounds where its source authorizes smart skips; size the roadmap in weeks. +- `product` and `venture`: the full specialist workflow and its complete question pressure apply; this rule removes nothing. +- Never run a questioning round merely to classify scale. Classify from the prompt and cheap repository evidence, defaulting unknown vectors low; a specialist's own later questions may raise the scale mid-session, and an upgrade restores the full workflow from that point. + +Review specialists spend question rounds on decisions, not ceremony — at every scale, and sharpest at `session`/`hobby`: + +- When the handoff or prompt names the review target unambiguously, print it on the Target line and proceed. Re-confirming a target the chain already fixed is not a STOP gate; the target gate exists for genuinely ambiguous targets. +- A finding whose fix is obvious and inside the authorized mutation boundary is applied and reported in a compact applied-changes list. Question rounds are reserved for genuine forks — scope changes, user-visible tradeoffs, anything hard to reverse — and are batched, up to four questions per round, never one round per finding. +- Optional extras (opening resources, offering the next review or a follow-up phase) never get their own question round at `session`/`hobby`: fold them into an existing round or a one-line closing offer. + +For office-hours specifically: at session or hobby scale, batch the Phase 2B questions (this refines the one-at-a-time rule, whose pressure exists for startup diagnostics), default-skip the Phase 2.75 landscape search, gate the visual sketch and outside design voices on an explicit ask, and cap the Spec Review Loop at one iteration. + + ## Upstream judgment port: PR #452 diff --git a/skills/ship/references/SHARED-JUDGMENT.md b/skills/ship/references/SHARED-JUDGMENT.md index 236316f215..0db5d4da05 100644 --- a/skills/ship/references/SHARED-JUDGMENT.md +++ b/skills/ship/references/SHARED-JUDGMENT.md @@ -12,4 +12,6 @@ This contract constrains every specialist without replacing specialist judgment. 7. Preview artifacts and diffs before approval. Approval remains mandatory before merge, deploy, destructive mutation, or spending. 8. Match the user language. Empty or contradictory evidence blocks confident success. 9. Recommendations remain traceable downstream, including what evidence would change them. -10. The user makes the final decision. +10. Ask only what cannot be inferred. Question rounds are for decisions that are consequential and still open after the prompt, the repository, and platform convention are consulted; infer the rest, state each inferred default in one line, and batch what remains. Never spend a round confirming what a handoff already names or offering optional extras. +11. A user-stated time constraint binds every phase and every chained skill. Skip or compress optional phases that do not fit it, noting each skip in one line. +12. The user makes the final decision.