diff --git a/docs/gstack-2/JUDGMENT-PARITY.md b/docs/gstack-2/JUDGMENT-PARITY.md index 796ac91e03..506ac0d64b 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,074 checks** across 55 specialist sources, 16 carved sections, 25 routing scenarios, 28 regression ports, and **78 assets**. +The pinned release inventory passes **5,080 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 856c4d2654..281d92bafd 100644 --- a/docs/gstack-2/JUDGMENT-PROVENANCE.json +++ b/docs/gstack-2/JUDGMENT-PROVENANCE.json @@ -1727,6 +1727,7 @@ 679, 2030, 2189, + 886, 879 ], "original_source_file": "plan-design-review/SKILL.md.tmpl", @@ -1863,6 +1864,7 @@ 2030, 2189, 696, + 886, 879 ], "original_source_file": "design-review/SKILL.md.tmpl", @@ -3630,6 +3632,7 @@ 2030, 2141, 579, + 886, 452, 879 ], @@ -5836,7 +5839,7 @@ "owner_tree": "design", "consumer_tree": "plan", "target": "skills/plan/references/legacy/plan-design-review.md", - "sha256": "7ae61a9b6a642ce58bde446116347c320c5414ce1f8fc6396762cd6a7974f532", + "sha256": "998496daab27f77d5613ddb838566c14cb1ed6071cef1c1a0ce30bd6eb6b4706", "disposition": "SHARED_MODULE" }, { @@ -7492,7 +7495,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 fddc2942cf..6854224f44 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 856c4d2654..281d92bafd 100644 --- a/evals/parity/manifest.json +++ b/evals/parity/manifest.json @@ -1727,6 +1727,7 @@ 679, 2030, 2189, + 886, 879 ], "original_source_file": "plan-design-review/SKILL.md.tmpl", @@ -1863,6 +1864,7 @@ 2030, 2189, 696, + 886, 879 ], "original_source_file": "design-review/SKILL.md.tmpl", @@ -3630,6 +3632,7 @@ 2030, 2141, 579, + 886, 452, 879 ], @@ -5836,7 +5839,7 @@ "owner_tree": "design", "consumer_tree": "plan", "target": "skills/plan/references/legacy/plan-design-review.md", - "sha256": "7ae61a9b6a642ce58bde446116347c320c5414ce1f8fc6396762cd6a7974f532", + "sha256": "998496daab27f77d5613ddb838566c14cb1ed6071cef1c1a0ce30bd6eb6b4706", "disposition": "SHARED_MODULE" }, { @@ -7492,7 +7495,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 0b259c4af4..6249612d7e 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 2189621842..3a211c84a3 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": "80221cf6e756c013db7b29979a96b5214cf9f7d1ee8e0aba35b923983caf3a52", + "policy_sha256": "22ee756104aa017dd939635cab84f1eb9eb75dcb4364d83cebd8584be2f2ddd8", "policy_present": true, "prompt_is_not_authority_input": true, "verdict": "PASS" @@ -88,7 +88,7 @@ "prompt_sha256": "04d82a21358f188cb823dcceeecaebea0b4ed8b9c1f8d00220ef3b499c48b1c8", "semantic_attempt_sha256": "9639406995955284517acb30f56b37dedc42a6c08142163dfa8fe0295105cbbf" }, - "policy_sha256": "7c65e6b6f507abaf3481b2f5ce58d9ed7ec3eef2d9081349755f8e66acf969b9", + "policy_sha256": "0ce379f2e3e85239a1bed3e3124c496c5d7b910b9919a8f55cb8d0200a15160b", "policy_present": true, "prompt_is_not_authority_input": true, "verdict": "PASS" @@ -138,7 +138,7 @@ "prompt_sha256": "8ad639f708a2ccd5c7c438b1dedf6afacdfa4eac3883a7a046ea23f29314e1c4", "semantic_attempt_sha256": "4c450039e4c622fbeaa34b7f7dfc810d3b7369aaf7e5f4d240cd6cc18a31331a" }, - "policy_sha256": "a06a65d69f4f2df210bf925353868739351d298e06961e607ff65c17718e71eb", + "policy_sha256": "9e6ba0cdc988df2694d5eb8cc6835e3d81e9aa3cb52fe29991af1eaf9cb1b7af", "policy_present": true, "prompt_is_not_authority_input": true, "verdict": "PASS" @@ -188,7 +188,7 @@ "prompt_sha256": "d2aa9aee06a116bf04cb62772e8abdf8dbd606811b6d38565389c88e86c79ede", "semantic_attempt_sha256": "64885a66bdc6688b880cbb9a59babf314834c068eb040657501bf287bfcb0d2b" }, - "policy_sha256": "80221cf6e756c013db7b29979a96b5214cf9f7d1ee8e0aba35b923983caf3a52", + "policy_sha256": "22ee756104aa017dd939635cab84f1eb9eb75dcb4364d83cebd8584be2f2ddd8", "policy_present": true, "prompt_is_not_authority_input": true, "verdict": "PASS" @@ -232,7 +232,7 @@ "prompt_sha256": "377e3a2dfc7b04272f857d27e77c9aa3c9f36c3feb63c03e5aee3ecd3dea8e2a", "semantic_attempt_sha256": "a49b1528091886749278dc22e7da4556c090800989b2bca9c0e1c09dd880fed7" }, - "policy_sha256": "b1e6f4a3f0a96c4f85e5308ce1ff4b1f0da8c48143b2fb23f927e95593827de4", + "policy_sha256": "b3f4a740cac18645e31487e1479a16f0862dc0d50a8fd34b600d2cfd665fc94e", "policy_present": true, "prompt_is_not_authority_input": true, "verdict": "PASS" @@ -279,7 +279,7 @@ "prompt_sha256": "a01bb977de84e53d8ce3dfa427bcc93d73c6e449cd4e9c1ff63b436fd41fb0d1", "semantic_attempt_sha256": "ce5c64c62c3ff9b60949f34717dffbc908f62ce30f8a4a48ec182eba4363a206" }, - "policy_sha256": "f44bdd611a10f589aa33457b209a5937c07b76e3d0c5c947dff4aeb8d25e179e", + "policy_sha256": "0052fa07b92825e223b8e070d33b628d0e32429c2a37f7e059e8aa456c81bb1a", "policy_present": true, "prompt_is_not_authority_input": true, "verdict": "PASS" @@ -330,7 +330,7 @@ "prompt_sha256": "95e97e26268ad7e509527e0f54c943ed6c4105d919f250648a2ad59ce77cbdb9", "semantic_attempt_sha256": "dacd11a78e32aeb6c0065496bedd4a9770f7bbac1036e003d3768fac41eb84f0" }, - "policy_sha256": "80221cf6e756c013db7b29979a96b5214cf9f7d1ee8e0aba35b923983caf3a52", + "policy_sha256": "22ee756104aa017dd939635cab84f1eb9eb75dcb4364d83cebd8584be2f2ddd8", "policy_present": true, "prompt_is_not_authority_input": true, "verdict": "PASS" @@ -381,7 +381,7 @@ "prompt_sha256": "bdd7e8adfa7c15cf8531f84c3adaaacc725075f1a78f7487225300750547b82d", "semantic_attempt_sha256": "32c11b63412c5d873ff29dcc87c45bef1b50daa218a5c6c1075864aa24d7c3b6" }, - "policy_sha256": "80221cf6e756c013db7b29979a96b5214cf9f7d1ee8e0aba35b923983caf3a52", + "policy_sha256": "22ee756104aa017dd939635cab84f1eb9eb75dcb4364d83cebd8584be2f2ddd8", "policy_present": true, "prompt_is_not_authority_input": true, "verdict": "PASS" @@ -426,7 +426,7 @@ "prompt_sha256": "51b7d53bc342e8632e34ae31a167cbde568ab5ee2a6dd2ccc980583a30604164", "semantic_attempt_sha256": "06f77b27c9bd360562655b23ca00a0dd021bdb14ebaaf3d836845e4e0cb43d68" }, - "policy_sha256": "9e4f2bb725d02e9f612e17ada4a73ddaf2ea12fb7889ceb6de224b276fad2606", + "policy_sha256": "56016ba9f4cddd018479cee25cb40f468cad147432e6d92be93f8dbfff830d4a", "policy_present": true, "prompt_is_not_authority_input": true, "verdict": "PASS" diff --git a/scripts/gstack2/bug-fix-overlays.ts b/scripts/gstack2/bug-fix-overlays.ts index 20aa977848..99c317b6af 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 }, }, }, { @@ -666,20 +674,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, }; } case 538: { diff --git a/scripts/gstack2/generate-skill-tree.ts b/scripts/gstack2/generate-skill-tree.ts index 2f26fe1248..13a6cc749e 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 c5a23a63af..743894b504 100644 --- a/scripts/gstack2/run-parity.ts +++ b/scripts/gstack2/run-parity.ts @@ -28,8 +28,10 @@ const ALLOWED_DISPOSITIONS = new Set(['VERBATIM_PORT', 'MECHANICAL_PORT', 'JUDGM // overlay for issue #538 (29 -> 30, office-hours only) added 5 more. The // per-tree code-intelligence offer contract added 18 (3 per dispatcher). The // third-party web-action contract added 24 more (4 per tree: exists, marker -// format, dispatcher load, consent/secret content). -export const EXPECTED_PARITY_CHECKS = 5074; +// format, dispatcher load, consent/secret content). 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 = 5080; function sha256(value: string | Uint8Array): string { return createHash('sha256').update(value).digest('hex'); 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 94d3a5af73..7944dbc0c7 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 aabf03ed8a..e4f64b5ec2 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.