fix: /office-hours and /ceo-review accidentally contradict Boil the Lake

[simonemacario]

The problem

gstack tells users to "narrow scope" in /office-hours (Q4: Narrowest Wedge, "Narrow beats wide, early") and "cut everything" in /plan-ceo-review (SCOPE REDUCTION, Focus as subtraction, Subtraction default) — but doesn't distinguish product scope from implementation scope.

Users conflate the two. They hear "minimum viable" and skip tests. They hear "narrow your scope" and cut error handling. This directly contradicts the Completeness Principle and Boil the Ocean.

Related: #340 (office-hours issues)

Concrete before/after

Before this PR — user runs /office-hours, gets told to narrow scope, then implements:

"The office hours session said to find the narrowest wedge. So I'm building just the core flow — no tests, no error handling, no edge cases. We can add those later."

The skills say "narrow" without specifying which axis. The user reasonably applies it to everything.

After this PR:

"The narrowest wedge is the product surface — one feature, one workflow. But that wedge gets complete implementation: all edge cases, full test coverage, every error path. The wedge is small. The engineering is thorough."

The distinction is now explicit in Q4, in SCOPE REDUCTION, in Focus as subtraction, and in the shared Completeness Principle preamble that all skills inherit.

The fix: two axes, one mantra

Scope is two axes, not one.

• Product scope (WHAT you build) — narrow early. Narrowest wedge, focus as subtraction, fewer things done better. This is strategy.
• Implementation scope (HOW COMPLETELY you build it) — always maximal. Boil the Lake. Every edge case, every test, every error path. This is engineering.

Narrow the product. Boil the implementation.

The M in MVP describes the product surface, not the code quality.

Changes (5 bisected commits)

1. ETHOS.md — New "2. The Two Axes of Scope" section in the builder philosophy, between Boil the Lake and Search Before Building
2. scripts/gen-skill-docs.ts — Two-axis distinction added to generateCompletenessSection(). Propagates to ALL skills via {{PREAMBLE}}
3. office-hours + plan-ceo-review templates — Surgical clarifications:
   • Q4 Narrowest Wedge: "this is PRODUCT scope, not implementation quality"
   • "Narrow beats wide": appended completeness clause
   • SCOPE REDUCTION: "cut features, not quality"
   • Focus as subtraction: "do fewer things, but do them completely"
   • Subtraction default: "never subtract tests or error handling"
4. Regenerated SKILL.md files — Mechanical output of template changes
5. ETHOS.md section numbering — Consistent numbering (1, 2, 3)

Test plan

• bun run gen:skill-docs — regenerated for both hosts
• bun test — 557 tests pass, 0 failures
• Completeness Principle spot-checks (test/skill-validation.test.ts L826-861) all pass
• Verified "Two axes of scope" appears in generated SKILL.md for all preamble skills

How I found this

Discovered while actually using gstack — /office-hours recommended narrowing scope for a feature I was building with Claude Code, which confused me because gstack's own philosophy says completeness is cheap. This is the contributor workflow working exactly as designed.

🤖 Generated with Claude Code

[simonemacario]

Code review

No issues found. Checked for bugs and CLAUDE.md compliance.

Verified: template-to-output pipeline (generateCompletenessSection(ctx) signature change + call site), commit bisection (4 logical commits), .tmpl editing workflow, and generated SKILL.md regeneration. All 557 tests pass per PR description.

🤖 Generated with Claude Code

_{- If this code review was useful, please react with 👍. Otherwise, react with 👎.}