CalvinBackup/gstack
1
0
Fork 0
mirror of https://github.com/garrytan/gstack.git synced 2026-08-21 13:37:14 +02:00
Code Issues Packages Projects Releases Wiki Activity

v1.57.4.0 refactor(ethos): rename Boil the Lake principle to Boil the Ocean (#1912)

Browse Source 
* refactor(ethos): rename Boil the Lake principle to Boil the Ocean

Reframes the completeness principle so the ocean (the complete thing) is the
goal and lakes are the boilable units you ship on the way there. "Don't boil
the ocean" was right when engineering time was the bottleneck; AI killed that
bottleneck, so the ocean is now the destination.

Resolves an existing split: the scope_appetite psychographic, archetypes, and
the completeness intro flow already used "boil the ocean" as the
complete-implementation pole while the named principle still said "lake".

Sources only: ETHOS.md philosophy, CLAUDE.md, README.md, the preamble
resolvers, and the plan/autoplan/document-generate templates.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* test: update assertions + golden fixtures for Boil the Ocean rename

skill-validation and terse-build now assert "Boil the Ocean"; the three ship
golden fixtures are regenerated to match the renamed Completeness Principle
header and intro prose.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* docs: regenerate SKILL.md files for Boil the Ocean rename

Mechanical `bun run gen:skill-docs` output: the Completeness Principle header
and intro flow now read "Boil the Ocean" across every generated skill.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* chore: bump version and changelog (v1.57.4.0)

Boil the Ocean rename: completeness principle renamed across ETHOS, every
generated skill, CLAUDE.md, README, and the preamble resolvers. Text only,
no runtime behavior change.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
Garry Tan
2026-06-08 05:41:07 -07:00
committed by GitHub
co-authored by Claude Opus 4.8
parent d8c91c6267
commit 41c6d3ebf6
66 changed files with 237 additions and 178 deletions
Download Patch File Download Diff File Expand all files Collapse all files
plan-ceo-review/SKILL.md.tmpl
+1 -1
View File
@@ -64,7 +64,7 @@ But your posture depends on what the user needs:
* SELECTIVE EXPANSION: You are a rigorous reviewer who also has taste. Hold the current scope as your baseline — make it bulletproof. But separately, surface every expansion opportunity you see and present each one individually as an AskUserQuestion so the user can cherry-pick. Neutral recommendation posture — present the opportunity, state effort and risk, let the user decide. Accepted expansions become part of the plan's scope for the remaining sections. Rejected ones go to "NOT in scope."
* HOLD SCOPE: You are a rigorous reviewer. The plan's scope is accepted. Your job is to make it bulletproof — catch every failure mode, test every edge case, ensure observability, map every error path. Do not silently reduce OR expand.
* SCOPE REDUCTION: You are a surgeon. Find the minimum viable version that achieves the core outcome. Cut everything else. Be ruthless.
* COMPLETENESS IS CHEAP: AI coding compresses implementation time 10-100x. When evaluating "approach A (full, ~150 LOC) vs approach B (90%, ~80 LOC)" — always prefer A. The 70-line delta costs seconds with CC. "Ship the shortcut" is legacy thinking from when human engineering time was the bottleneck. Boil the lake.
* COMPLETENESS IS CHEAP: AI coding compresses implementation time 10-100x. When evaluating "approach A (full, ~150 LOC) vs approach B (90%, ~80 LOC)" — always prefer A. The 70-line delta costs seconds with CC. "Ship the shortcut" is legacy thinking from when human engineering time was the bottleneck. Boil the ocean.
Critical rule: In ALL modes, the user is 100% in control. Every scope change is an explicit opt-in via AskUserQuestion — never silently add or remove scope. Once the user selects a mode, COMMIT to it. Do not silently drift toward a different mode. If EXPANSION is selected, do not argue for less work during later sections. If SELECTIVE EXPANSION is selected, surface expansions as individual decisions — do not silently include or exclude them. If REDUCTION is selected, do not sneak scope back in. Raise concerns once in Step 0 — after that, execute the chosen mode faithfully.
Do NOT make any code changes. Do NOT start implementation. Your only job right now is to review the plan with maximum rigor and the appropriate level of ambition.