@thebassclef/lite 1.0.4 → 1.1.1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (275) hide show
  1. package/dist/cli.cjs +298 -55
  2. package/dist/cli.js +298 -55
  3. package/dist/index.cjs +1 -1
  4. package/dist/index.d.ts +1 -1
  5. package/dist/index.js +1 -1
  6. package/dist/lite/.claude/agents/architect.md +70 -0
  7. package/dist/lite/.claude/agents/builder.md +114 -0
  8. package/dist/lite/.claude/agents/designer.md +156 -0
  9. package/dist/lite/.claude/agents/reviewer.md +88 -0
  10. package/dist/lite/.claude/hooks/bassclef-sync.sh +85 -27
  11. package/dist/lite/.claude/hooks/longrun-prep-compounding-axis-check.sh +492 -0
  12. package/dist/lite/.claude/hooks/longrun-prep-render-check.sh +236 -0
  13. package/dist/lite/.claude/hooks/persona-name-scrub-check.sh +105 -0
  14. package/dist/lite/.claude/hooks/skill-step-list-check.sh +171 -0
  15. package/dist/lite/.claude/luminaries/alan-cooper.md +170 -0
  16. package/dist/lite/.claude/luminaries/alistair-cockburn.md +140 -0
  17. package/dist/lite/.claude/luminaries/amazon-pr-faq.md +34 -0
  18. package/dist/lite/.claude/luminaries/andreas-zeller.md +74 -0
  19. package/dist/lite/.claude/luminaries/ash-maurya.md +121 -0
  20. package/dist/lite/.claude/luminaries/bill-buxton.md +210 -0
  21. package/dist/lite/.claude/luminaries/charles-sanders-peirce.md +150 -0
  22. package/dist/lite/.claude/luminaries/david-ogilvy.md +192 -0
  23. package/dist/lite/.claude/luminaries/don-norman.md +173 -0
  24. package/dist/lite/.claude/luminaries/edward-tufte.md +179 -0
  25. package/dist/lite/.claude/luminaries/eric-evans.md +160 -0
  26. package/dist/lite/.claude/luminaries/frederick-brooks.md +50 -0
  27. package/dist/lite/.claude/luminaries/gang-of-four.md +157 -0
  28. package/dist/lite/.claude/luminaries/glenford-myers.md +230 -0
  29. package/dist/lite/.claude/luminaries/hunt-thomas.md +115 -0
  30. package/dist/lite/.claude/luminaries/hyrum-wright.md +94 -0
  31. package/dist/lite/.claude/luminaries/jason-fried-dhh.md +46 -0
  32. package/dist/lite/.claude/luminaries/jesse-james-garrett.md +154 -0
  33. package/dist/lite/.claude/luminaries/john-ousterhout.md +94 -0
  34. package/dist/lite/.claude/luminaries/karl-popper.md +132 -0
  35. package/dist/lite/.claude/luminaries/kent-beck.md +168 -0
  36. package/dist/lite/.claude/luminaries/linus-torvalds.md +218 -0
  37. package/dist/lite/.claude/luminaries/martin-fowler.md +164 -0
  38. package/dist/lite/.claude/luminaries/michael-feathers.md +125 -0
  39. package/dist/lite/.claude/luminaries/michael-nygard.md +118 -0
  40. package/dist/lite/.claude/luminaries/robert-c-martin.md +164 -0
  41. package/dist/lite/.claude/luminaries/saltzer-schroeder.md +194 -0
  42. package/dist/lite/.claude/luminaries/sophia-prater.md +193 -0
  43. package/dist/lite/.claude/luminaries/stephen-toulmin.md +131 -0
  44. package/dist/lite/.claude/luminaries/tony-hoare.md +170 -0
  45. package/dist/lite/.claude/luminaries/vaughn-vernon.md +50 -0
  46. package/dist/lite/.claude/luminaries/w-edwards-deming.md +158 -0
  47. package/dist/lite/.claude/rules/accessor-library-discipline.md +110 -0
  48. package/dist/lite/.claude/rules/adr-discipline.md +96 -0
  49. package/dist/lite/.claude/rules/api-conventions.md +115 -0
  50. package/dist/lite/.claude/rules/artifact-ingestion.md +137 -0
  51. package/dist/lite/.claude/rules/assert-only-after-verify.md +111 -0
  52. package/dist/lite/.claude/rules/blocked-items.md +139 -0
  53. package/dist/lite/.claude/rules/bootstrap-pair-discipline.md +106 -0
  54. package/dist/lite/.claude/rules/branching.md +28 -0
  55. package/dist/lite/.claude/rules/cold-adopter-harness-discipline.md +93 -0
  56. package/dist/lite/.claude/rules/commit-conventions.md +22 -0
  57. package/dist/lite/.claude/rules/compounding-axis-fresh-analysis.md +173 -0
  58. package/dist/lite/.claude/rules/compounding-sequence-fresh-analysis.md +173 -0
  59. package/dist/lite/.claude/rules/context-engineering.md +155 -0
  60. package/dist/lite/.claude/rules/context-management.md +85 -0
  61. package/dist/lite/.claude/rules/defensive-bash.md +52 -0
  62. package/dist/lite/.claude/rules/deferred-actions.md +233 -0
  63. package/dist/lite/.claude/rules/destructive-operations.md +69 -0
  64. package/dist/lite/.claude/rules/diagnosis.md +38 -0
  65. package/dist/lite/.claude/rules/github-issue-flash-tweet.md +114 -0
  66. package/dist/lite/.claude/rules/guardrails.md +73 -0
  67. package/dist/lite/.claude/rules/hook-wire-on-author.md +77 -0
  68. package/dist/lite/.claude/rules/identifier-leak-prevention.md +73 -0
  69. package/dist/lite/.claude/rules/iteration-bet-brief-completeness.md +43 -0
  70. package/dist/lite/.claude/rules/lite-manifest-schema-change-discipline.md +79 -0
  71. package/dist/lite/.claude/rules/longrun-prep-plan-doc-compression.md +77 -0
  72. package/dist/lite/.claude/rules/loop-discipline.md +71 -0
  73. package/dist/lite/.claude/rules/manual-prod-approval.md +100 -0
  74. package/dist/lite/.claude/rules/marker-enrichment-discipline.md +72 -0
  75. package/dist/lite/.claude/rules/mobile-ephemeral-session.md +109 -0
  76. package/dist/lite/.claude/rules/new-dependency-check.md +44 -0
  77. package/dist/lite/.claude/rules/oo-ad-entry-point.md +95 -0
  78. package/dist/lite/.claude/rules/operator-facing-prose.md +177 -0
  79. package/dist/lite/.claude/rules/option-label-discipline.md +82 -0
  80. package/dist/lite/.claude/rules/pattern-annotation.md +83 -0
  81. package/dist/lite/.claude/rules/persona-name-leak-scrub.md +90 -0
  82. package/dist/lite/.claude/rules/plain-english-discipline.md +132 -0
  83. package/dist/lite/.claude/rules/plan-enumeration-needs-value-props.md +177 -0
  84. package/dist/lite/.claude/rules/pr-body-shape.md +195 -0
  85. package/dist/lite/.claude/rules/pr-strategy.md +142 -0
  86. package/dist/lite/.claude/rules/pr-title-shape.md +90 -0
  87. package/dist/lite/.claude/rules/prototype-workflow.md +53 -0
  88. package/dist/lite/.claude/rules/reserved-skill-names.md +103 -0
  89. package/dist/lite/.claude/rules/schema-management.md +42 -0
  90. package/dist/lite/.claude/rules/sdlc-gates.md +149 -0
  91. package/dist/lite/.claude/rules/security.md +37 -0
  92. package/dist/lite/.claude/rules/session-artifacts.md +236 -0
  93. package/dist/lite/.claude/rules/skill-composition-declarations.md +105 -0
  94. package/dist/lite/.claude/rules/skill-description-clarity.md +196 -0
  95. package/dist/lite/.claude/rules/skill-procedure-step-list.md +119 -0
  96. package/dist/lite/.claude/rules/sprint-prep-preset-picker.md +76 -0
  97. package/dist/lite/.claude/rules/state-schema-validation.md +156 -0
  98. package/dist/lite/.claude/rules/stuck-signal-diagnostic.md +111 -0
  99. package/dist/lite/.claude/rules/substrate-config-schema.md +85 -0
  100. package/dist/lite/.claude/rules/test-list-discipline.md +129 -0
  101. package/dist/lite/.claude/rules/test-sufficiency.md +186 -0
  102. package/dist/lite/.claude/rules/testing-tier-config.md +125 -0
  103. package/dist/lite/.claude/rules/testing.md +38 -0
  104. package/dist/lite/.claude/rules/turn-estimate-grounding.md +82 -0
  105. package/dist/lite/.claude/rules/visual-hierarchy.md +427 -0
  106. package/dist/lite/.claude/rules/we-dont-break-adopters.md +103 -0
  107. package/dist/lite/.claude/rules/whereami-load-bearing.md +184 -0
  108. package/dist/lite/.claude/rules/writing-craft-discipline.md +72 -0
  109. package/dist/lite/.claude/rules/wu-sequencing-compounds.md +119 -0
  110. package/dist/lite/.claude/skills/build/SKILL.md +640 -0
  111. package/dist/lite/.claude/skills/chronicle/SKILL.md +55 -0
  112. package/dist/lite/.claude/skills/clean-artifacts/SKILL.md +249 -0
  113. package/dist/lite/.claude/skills/decompose/SKILL.md +280 -0
  114. package/dist/lite/.claude/skills/diagnose/SKILL.md +297 -0
  115. package/dist/lite/.claude/skills/feynman/SKILL.md +90 -0
  116. package/dist/lite/.claude/skills/howdoi/SKILL.md +105 -0
  117. package/dist/lite/.claude/skills/ia-model/SKILL.md +108 -0
  118. package/dist/lite/.claude/skills/interaction-design/SKILL.md +112 -0
  119. package/dist/lite/.claude/skills/interpret-input/SKILL.md +180 -0
  120. package/dist/lite/.claude/skills/journal/SKILL.md +209 -0
  121. package/dist/lite/.claude/skills/kiss/SKILL.md +449 -0
  122. package/dist/lite/.claude/skills/launch/SKILL.md +915 -0
  123. package/dist/lite/.claude/skills/lean-canvas/SKILL.md +332 -0
  124. package/dist/lite/.claude/skills/longrun/SKILL.md +512 -0
  125. package/dist/lite/.claude/skills/luminary/SKILL.md +481 -0
  126. package/dist/lite/.claude/skills/ogilvy-writing-audit/SKILL.md +177 -0
  127. package/dist/lite/.claude/skills/onboard-repo/SKILL.md +1640 -0
  128. package/dist/lite/.claude/skills/pattern-review/SKILL.md +99 -0
  129. package/dist/lite/.claude/skills/personas/SKILL.md +207 -0
  130. package/dist/lite/.claude/skills/promote/SKILL.md +283 -0
  131. package/dist/lite/.claude/skills/requirement/SKILL.md +98 -0
  132. package/dist/lite/.claude/skills/retro/SKILL.md +117 -0
  133. package/dist/lite/.claude/skills/riff/SKILL.md +114 -0
  134. package/dist/lite/.claude/skills/roadmap-reconcile/SKILL.md +163 -0
  135. package/dist/lite/.claude/skills/session-end/SKILL.md +309 -0
  136. package/dist/lite/.claude/skills/session-log/SKILL.md +299 -0
  137. package/dist/lite/.claude/skills/skills/SKILL.md +228 -0
  138. package/dist/lite/.claude/skills/spec/SKILL.md +105 -0
  139. package/dist/lite/.claude/skills/sprint/SKILL.md +418 -0
  140. package/dist/lite/.claude/skills/stage/SKILL.md +384 -0
  141. package/dist/lite/.claude/skills/state-a-problem/SKILL.md +185 -0
  142. package/dist/lite/.claude/skills/temperance/SKILL.md +108 -0
  143. package/dist/lite/.claude/skills/use-case/SKILL.md +417 -0
  144. package/dist/lite/.claude/skills/user-stories/SKILL.md +268 -0
  145. package/dist/lite/.claude/skills/value-prop/SKILL.md +251 -0
  146. package/dist/lite/.claude/skills/verify/SKILL.md +160 -0
  147. package/dist/lite/.claude/skills/visual-review/SKILL.md +503 -0
  148. package/dist/lite/.claude/skills/whats-the-plan/SKILL.md +202 -0
  149. package/dist/lite/.claude/skills/whereami/SKILL.md +307 -0
  150. package/dist/lite/AGENTS.md +79 -0
  151. package/dist/lite/CLAUDE-lite.md +85 -0
  152. package/dist/lite/CODE_OF_CONDUCT.md +28 -0
  153. package/dist/lite/CONTRIBUTING.md +177 -0
  154. package/dist/lite/README.md +173 -0
  155. package/dist/lite/SECURITY.md +19 -0
  156. package/dist/lite/architecture/decisions/ADR-029-release-pipeline.md +79 -0
  157. package/dist/lite/architecture/decisions/ADR-031-non-breaking-changes-adopter-discipline.md +139 -0
  158. package/dist/lite/architecture/decisions/ADR-032-adopter-sync-dispatcher-architecture.md +192 -0
  159. package/dist/lite/architecture/decisions/ADR-039-release-tagging-scheme.md +145 -0
  160. package/dist/lite/architecture/decisions/ADR-040-planning-skill-vocabulary-and-lite-profile.md +155 -0
  161. package/dist/lite/architecture/decisions/ADR-044-unified-skill-body-template.md +162 -0
  162. package/dist/lite/lib/clean-artifacts-sweep.sh +112 -0
  163. package/dist/lite/lib/code-comment-discipline.sh +144 -0
  164. package/dist/lite/lib/composer-preflight.sh +459 -0
  165. package/dist/lite/lib/deferred-actions.sh +146 -0
  166. package/dist/lite/lib/hook-header-parser.sh +61 -0
  167. package/dist/lite/lib/hook-heartbeat.sh +152 -0
  168. package/dist/lite/lib/hook-inject.sh +255 -0
  169. package/dist/lite/lib/hook-installer.sh +195 -0
  170. package/dist/lite/lib/luminary-pick.sh +96 -0
  171. package/dist/lite/lib/output-discipline.sh +143 -0
  172. package/dist/lite/lib/prose-scan-boundary.sh +171 -0
  173. package/dist/lite/lib/rewrite-check.sh +214 -0
  174. package/dist/lite/lib/session-rescue.sh +151 -0
  175. package/dist/lite/lib/source-graph-walker.sh +277 -0
  176. package/dist/lite/lib/state.sh +1372 -0
  177. package/dist/lite/lib/telemetry.sh +205 -0
  178. package/dist/lite/lib/tier-check.sh +187 -0
  179. package/dist/lite/lib/tier-dependency-audit.sh +1088 -0
  180. package/dist/lite/presence/install/bassclef-hook-connect.sh +178 -0
  181. package/dist/lite/presence/install/bassclef-sync.dispatcher.template.sh +841 -0
  182. package/dist/lite/presence/install/bassclef-sync.template.sh +2278 -0
  183. package/dist/lite/presence/install/schedule-auto-save.cron.sh +88 -0
  184. package/dist/lite/presence/install/schedule-auto-save.taskscheduler.md +122 -0
  185. package/dist/lite/scripts/aggregate-telemetry.sh +217 -0
  186. package/dist/lite/scripts/analyze-tier-dependencies.sh +239 -0
  187. package/dist/lite/scripts/generate-lite-manifest.sh +505 -0
  188. package/dist/lite/scripts/generate-tier-manifest.sh +28 -0
  189. package/dist/lite/scripts/intent-drift-check.sh +456 -0
  190. package/dist/lite/scripts/lite-manifest-drift-check.sh +146 -0
  191. package/dist/lite/scripts/render-lite-manifest-doc.sh +150 -0
  192. package/dist/lite/standards/adr-template.md +86 -0
  193. package/dist/lite/standards/api-conventions/nextjs.md +84 -0
  194. package/dist/lite/standards/artifact-composition.md +209 -0
  195. package/dist/lite/standards/bash-hook-safety.md +246 -0
  196. package/dist/lite/standards/bassclef-configs-schema.md +232 -0
  197. package/dist/lite/standards/bassclef-evolution.md +143 -0
  198. package/dist/lite/standards/bassclef-internal-jargon.md +244 -0
  199. package/dist/lite/standards/bassclef-managed-sentinel.md +96 -0
  200. package/dist/lite/standards/bassclef-source-config.md +228 -0
  201. package/dist/lite/standards/branch-stacking.md +408 -0
  202. package/dist/lite/standards/code-safety-principles.md +176 -0
  203. package/dist/lite/standards/composer-prerequisites.md +155 -0
  204. package/dist/lite/standards/deferred-actions-schema.md +204 -0
  205. package/dist/lite/standards/dependency-discipline/cargo.md +39 -0
  206. package/dist/lite/standards/dependency-discipline/gem.md +43 -0
  207. package/dist/lite/standards/dependency-discipline/go-mod.md +41 -0
  208. package/dist/lite/standards/dependency-discipline/npm.md +42 -0
  209. package/dist/lite/standards/dependency-discipline/pip.md +42 -0
  210. package/dist/lite/standards/deployment-topology/ec2-tailscale.md +225 -0
  211. package/dist/lite/standards/deployment-topology.md +69 -0
  212. package/dist/lite/standards/docs-sync-allowlist.md +76 -0
  213. package/dist/lite/standards/domain-and-dns.md +145 -0
  214. package/dist/lite/standards/frontend-stack.md +67 -0
  215. package/dist/lite/standards/frontmatter-schema.md +154 -0
  216. package/dist/lite/standards/graceful-exit.md +227 -0
  217. package/dist/lite/standards/hook-idempotency.md +102 -0
  218. package/dist/lite/standards/hook-injection-discipline.md +202 -0
  219. package/dist/lite/standards/hook-install-class.md +215 -0
  220. package/dist/lite/standards/input-handler-interface.md +152 -0
  221. package/dist/lite/standards/lite-manifest-schema-changes.md +180 -0
  222. package/dist/lite/standards/lite-manifest.json +2797 -0
  223. package/dist/lite/standards/luminary-matching.md +105 -0
  224. package/dist/lite/standards/luminary-problem-patterns.md +481 -0
  225. package/dist/lite/standards/migration-discipline/active-record.md +50 -0
  226. package/dist/lite/standards/migration-discipline/alembic.md +43 -0
  227. package/dist/lite/standards/migration-discipline/gorm.md +50 -0
  228. package/dist/lite/standards/migration-discipline/prisma.md +53 -0
  229. package/dist/lite/standards/migration-discipline/sqlalchemy.md +51 -0
  230. package/dist/lite/standards/mobile-ephemeral-session.md +167 -0
  231. package/dist/lite/standards/model-routing-discipline.md +160 -0
  232. package/dist/lite/standards/ogilvy-writing-rules.md +225 -0
  233. package/dist/lite/standards/opener-discipline.md +96 -0
  234. package/dist/lite/standards/operator-facing-prose-discipline.md +201 -0
  235. package/dist/lite/standards/persona-schema.md +229 -0
  236. package/dist/lite/standards/pluggable-luminaries.md +323 -0
  237. package/dist/lite/standards/pr-body-discipline.md +115 -0
  238. package/dist/lite/standards/preview-state-schema.md +189 -0
  239. package/dist/lite/standards/project-directory-layout.md +276 -0
  240. package/dist/lite/standards/release-tagging.md +137 -0
  241. package/dist/lite/standards/reserved-skill-names.md +120 -0
  242. package/dist/lite/standards/scannable-multi-option-output.md +265 -0
  243. package/dist/lite/standards/sdlc-compliance.md +286 -0
  244. package/dist/lite/standards/sdlc-gates/typescript.md +57 -0
  245. package/dist/lite/standards/secrets-lifecycle.md +210 -0
  246. package/dist/lite/standards/security-scanner-adapter.md +145 -0
  247. package/dist/lite/standards/session-board.md +256 -0
  248. package/dist/lite/standards/skill-output-discipline.md +121 -0
  249. package/dist/lite/standards/state-spine-contract.md +255 -0
  250. package/dist/lite/standards/state-spine.md +511 -0
  251. package/dist/lite/standards/steering-hints/kiss-words.md +11 -0
  252. package/dist/lite/standards/substrate-config-schema.md +267 -0
  253. package/dist/lite/standards/tech-stack-config.md +109 -0
  254. package/dist/lite/standards/tier-dependency-analysis.md +167 -0
  255. package/dist/lite/standards/tier-runtime-deps/lite.md +57 -0
  256. package/dist/lite/standards/tier-tag-schema.md +155 -0
  257. package/dist/lite/standards/two-layer-config.md +99 -0
  258. package/dist/lite/standards/use-case-format.md +292 -0
  259. package/dist/lite/standards/user-story-invest.md +268 -0
  260. package/dist/lite/standards/velocity-and-appetite.md +229 -0
  261. package/dist/lite/standards/voice-input-pattern.md +119 -0
  262. package/dist/lite/standards/whereami-schema.md +301 -0
  263. package/dist/lite/standards/worktree-management.md +211 -0
  264. package/dist/lite/standards/writing-guide.md +213 -0
  265. package/dist/lite/templates/chronicle-template.md +75 -0
  266. package/dist/lite/templates/deferred-action-template.md +45 -0
  267. package/dist/lite/templates/memory-proposal-template.md +77 -0
  268. package/dist/lite/templates/persona-template.md +200 -0
  269. package/dist/lite/templates/pr-faq.md +45 -0
  270. package/dist/lite/templates/secret-rotation-template.md +162 -0
  271. package/dist/lite/templates/spec-template.md +131 -0
  272. package/dist/lite/templates/use-case-template.md +194 -0
  273. package/dist/lite/templates/user-story-template.md +107 -0
  274. package/dist/lite/templates/whereami-template.md +101 -0
  275. package/package.json +12 -5
@@ -0,0 +1,94 @@
1
+ ---
2
+ tier: lite
3
+ name: John Ousterhout
4
+ slug: john-ousterhout
5
+ claimed_by: [architect, reviewer, builder]
6
+ referenced_by_skills: [pattern-review, decompose]
7
+ primary_domain: engineering
8
+ depth: stub
9
+ sources:
10
+ - type: book
11
+ title: "A Philosophy of Software Design"
12
+ authors: ["John Ousterhout"]
13
+ year: 2021
14
+ edition: "2nd"
15
+ url: "https://web.stanford.edu/~ouster/cgi-bin/aposd.php"
16
+ isbn: "9781732102217"
17
+ methodology_covered:
18
+ - "Deep modules — small interface hiding complex implementation"
19
+ - "Complexity is incremental — small drips add up; resist each one"
20
+ - "Define errors out of existence — design APIs so error conditions cannot occur"
21
+ - "Comments encode design decisions the code itself cannot"
22
+ - "Strategic vs tactical programming — invest in design over short-term wins"
23
+ - "Information hiding — modules expose only what callers need; the rest stays internal"
24
+ - type: course
25
+ title: "Stanford CS 190 — Software Design Studio"
26
+ authors: ["John Ousterhout"]
27
+ year: 2018
28
+ url: "https://web.stanford.edu/class/cs190/"
29
+ methodology_covered:
30
+ - "Source course where the principles in A Philosophy of Software Design were developed and tested"
31
+ verification_status: verified
32
+ description: "\"Complexity is anything that makes software hard to understand or modify."
33
+ ---
34
+
35
+ # John Ousterhout
36
+
37
+ ## Signature
38
+
39
+ *"Complexity is anything that makes software hard to understand or modify. The goal of software design is to reduce complexity."*
40
+
41
+ Stanford professor. Creator of the Tcl scripting language and Raft consensus protocol. Author of **A Philosophy of Software Design** (2018, 2nd ed 2021), the modern SENTINEL_bassclef_text on simplicity, deep modules, and complexity-as-incremental-drift. Pairs with Beck (TDD) and Fowler (refactoring tactics): Beck asks "is it tested?", Fowler asks "how do I restructure it?", Ousterhout asks "is it the right shape in the first place?"
42
+
43
+ ## Discipline anchor
44
+
45
+ **Design judgment + complexity-as-enemy.** Ousterhout supplies the WHY-to-refactor framing that Beck and Fowler leave to the engineer's judgment.
46
+ INSTEAD: Beck owns the red-green-refactor cycle; Fowler owns the catalog of refactorings; Ousterhout owns the design-quality lens that tells you whether the shape you're refactoring toward is actually better. Without this lens, refactors can shuffle complexity without reducing it.
47
+
48
+ This luminary fires on architectural-judgment moments — picking module boundaries, naming interfaces, deciding whether to split a class, evaluating whether a comment is doing real work or restating the code.
49
+ INSTEAD of citing Ousterhout for test mechanics, refactoring tactics, or pattern catalog selection: route those concerns to Beck, Fowler, and GoF respectively.
50
+
51
+ ## Key principles
52
+
53
+ - **Deep modules** — A module is deep when it has a small interface and a large, complex implementation hidden behind it. Shallow modules push knowledge to callers and produce a system where understanding the whole requires understanding every part. When tempted to split a class for "smaller files," ask: does the split produce TWO deep modules, or TWO shallow ones?
54
+ INSTEAD of defaulting to file-size as the splitting metric: use interface-shape as the metric. Two deep modules from a split is a win; two shallow modules from a split is a regression even if the line count drops.
55
+
56
+ - **Complexity is incremental** — Complexity accumulates one small decision at a time. A single special case, a single dependency, a single inconsistency feels harmless. Sum across a session, a release, a year — that's how systems become unmaintainable. The discipline is to resist each small drip rather than promise to clean up the puddle later.
57
+ INSTEAD of deferring cleanup to a future refactor: refuse the small drip at the moment it appears. Future-refactor cleanups almost never happen; the cost of resisting at write-time is the cheapest moment.
58
+
59
+ - **Define errors out of existence** — Design APIs so error conditions cannot occur, rather than designing APIs that throw errors and asking every caller to handle them. The classic example: `unset` on a variable that does not exist is an error in older shells.
60
+ INSTEAD: the right shape is for `unset` to be idempotent. Applied to bassclef: hooks that BLOCK on missing artifacts are weaker than hooks that bootstrap the artifact when absent, where bootstrapping is safe.
61
+
62
+ - **Comments encode design decisions code cannot** — Code says what it does. Comments must say what the code cannot — the WHY (invariant), the WHAT-IF (alternative considered and rejected), the WATCH-OUT (subtle constraint a future reader will miss).
63
+ INSTEAD of comments that restate code: write comments that record decisions. This principle is load-bearing for bassclef's `bassclef-configs.jsonc` discipline: inline comments are the adopter-discovery surface, not exhaust.
64
+
65
+ ## When to cite this luminary
66
+
67
+ Cite `@luminary john-ousterhout` when:
68
+
69
+ - **Reviewing module boundaries** (`/pattern-review`) — is this class deep or shallow? Would splitting it make two deep modules or two shallow ones?
70
+ - **Decomposing responsibilities** (`/decompose` GRASP audit) — does each responsibility assignment produce a deep module, or push complexity to callers?
71
+ - **Designing bassclef-configs.jsonc or other adopter-edit surfaces** — inline comments must encode WHY-to-pick and WHEN-to-pick, not restate the field name. This is "comments-as-design" applied to substrate configuration.
72
+ - **Evaluating whether complexity is essential or accidental** — when a feature feels harder to ship than it should, ask whether the difficulty is in the problem domain (essential) or in how earlier decisions shaped the code (accidental). Accidental complexity is the refactor signal.
73
+
74
+ When the question is test mechanics, refactoring step-by-step, design-pattern selection, distributed-systems scalability, or algorithmic complexity, route elsewhere.
75
+ INSTEAD: cite Beck (test mechanics), Fowler (refactoring tactics), GoF (pattern selection), Kleppmann (Phase C, scalability anchor), Bentley (Phase C, Big-O practical discipline).
76
+
77
+ ## Composes with
78
+
79
+ - **Kent Beck** — TDD makes deep modules testable. Tests verify that the interface is actually small; without tests, deep modules look the same as shallow ones from outside.
80
+ - **Martin Fowler** — Refactoring tactics serve Ousterhout's design judgment. Fowler tells you HOW to extract a method; Ousterhout tells you WHETHER the extraction produces a deeper module or shuffles complexity.
81
+ - **Gang of Four** — Design patterns are deep-module exemplars when applied well. The Decorator pattern is a deep module; the over-applied Visitor pattern is often shallow because it pushes traversal logic to callers.
82
+ - **Michael Feathers** (bassclef luminary catalog) — Characterization testing makes it safe to refactor toward deeper modules in legacy code where the original boundaries are unclear.
83
+
84
+ ## Refs
85
+
86
+ - bassclef#1036 — this luminary's filing ticket
87
+ - bassclef#867 — anchor-luminary verification pattern (stub-tier shape this entry follows)
88
+ - bassclef#1037 — sibling ticket; testing-tier-config primitive (Ousterhout's comments-as-design framing anchors the Tier 0 vs Tier 3 comment rules)
89
+ - bassclef#478 — `@pattern` annotation discipline (analog for `@luminary` citation discipline)
90
+
91
+ ## Stub-to-full
92
+
93
+ This is a stub entry per bassclef#867 verification pattern — frontmatter plus 4-section body grounded in primary source. Full body (worked examples in bassclef's own substrate, anti-patterns catalog, signature stack-translation paragraph) is deferred to a luminary-authoring follow-on bet.
94
+ INSTEAD of blocking citation on full-body completion: the stub is sufficient for `/pattern-review` and `/decompose` to invoke the lens today; the full entry deepens worked examples in a later pass.
@@ -0,0 +1,132 @@
1
+ ---
2
+ tier: lite
3
+ name: Karl Popper
4
+ slug: karl-popper
5
+ claimed_by: [architect, reviewer, closer]
6
+ referenced_by_skills: [diagnose, architect-review, promote, state-a-problem]
7
+ primary_domain: philosophy
8
+ depth: full
9
+ sources:
10
+ - type: book
11
+ title: "The Logic of Scientific Discovery"
12
+ authors: ["Karl R. Popper"]
13
+ year: 1959
14
+ original_year: 1935
15
+ url: "https://www.routledge.com/The-Logic-of-Scientific-Discovery/Popper/p/book/9780415278447"
16
+ isbn: "9780415278447"
17
+ methodology_covered:
18
+ - "Falsifiability as demarcation criterion for scientific claims"
19
+ - "Bold conjectures + severe tests as the actual method"
20
+ - "Verification is impossible; falsification is decisive"
21
+ - type: book
22
+ title: "Conjectures and Refutations: The Growth of Scientific Knowledge"
23
+ authors: ["Karl R. Popper"]
24
+ year: 1963
25
+ url: "https://www.routledge.com/Conjectures-and-Refutations-The-Growth-of-Scientific-Knowledge/Popper/p/book/9780415285940"
26
+ isbn: "9780415285940"
27
+ methodology_covered:
28
+ - "Knowledge grows by refutation, not confirmation"
29
+ - "Better theories forbid more; the more a theory forbids the better"
30
+ - "All observation is theory-laden; there is no view from nowhere"
31
+ - type: book
32
+ title: "The Open Society and Its Enemies"
33
+ authors: ["Karl R. Popper"]
34
+ year: 1945
35
+ url: "https://press.princeton.edu/books/paperback/9780691158136/the-open-society-and-its-enemies"
36
+ isbn: "9780691158136"
37
+ methodology_covered:
38
+ - "Piecemeal social engineering over utopian planning"
39
+ - "Institutions that expose leaders to falsification"
40
+ - "Critical rationalism as social discipline"
41
+ verification_status: verified
42
+ description: "\"Good tests kill flawed theories; we remain alive to guess again.\""
43
+ ---
44
+
45
+ # Karl Popper
46
+
47
+ ## Signature
48
+
49
+ *"Good tests kill flawed theories; we remain alive to guess again."*
50
+
51
+ Austrian-British philosopher (1902-1994). Author of *The Logic of Scientific Discovery* (Hutchinson, 1935 German / 1959 English) and *Conjectures and Refutations* (1963). The bassclef voice on falsifiability, hypothesis testing, and the discipline that a claim which cannot be falsified is steering language, not truth.
52
+
53
+ ## Core methods
54
+
55
+ - **Falsifiability as demarcation** — a claim is scientific to the extent that it can be shown wrong. Unfalsifiable claims may be inspiring; they are not knowledge. In substrate work: an assertion with no rebuttal cell is either a definition or an act of faith.
56
+ - **Conjectures and refutations** — knowledge grows by making bold conjectures and then trying hard to break them. The bolder the claim, the more the world it forbids, the more informative it is when it survives testing.
57
+ - **The severity of tests** — a test that could have refuted the claim but did not is severe. A test the claim was designed to pass is weak. Testing is not a formality; it is the entire epistemic engine.
58
+ - **Piecemeal engineering** — for social + technical systems, small changes that can be reverted are better than sweeping redesigns that cannot. The value is not the change itself; it is the reversibility.
59
+ - **All observation is theory-laden** — there is no raw data. Every observation runs through the framework the observer brings. This is why the warrant matters, not just the data.
60
+
61
+ ## When to channel this luminary
62
+
63
+ When the primary risk is root-cause claims, cure recommendations, or diagnostic assertions shipping without stated conditions for being wrong. Popper dominates for `/diagnose` output (root-cause hypotheses), audit findings (severity claims), cure recommendations (why THIS cure, not another), and any assertion the operator will act on. Pair with Toulmin (Popper's rebuttal cell IS Toulmin's rebuttal cell) and Peirce (Peirce names the alternatives; Popper says test each).
64
+
65
+ Pass-through cases (Popper adds no value):
66
+
67
+ - Pure definition claims ("this is what we call X"). INSTEAD of falsification testing: preserve the definition; it is a naming act, not a knowledge claim.
68
+ - Aesthetic preference statements. INSTEAD of falsification testing: preserve the preference; it is Peirce's pragmatic-maxim category, not Popper's.
69
+ - Operator-authored directives. INSTEAD of falsification testing: honor the directive; operator preference is a starting point for inquiry, not a hypothesis to be falsified.
70
+
71
+ ## Stack translation
72
+
73
+ In bassclef substrate work:
74
+
75
+ - **`/diagnose` output** → hypothesis + falsification test. What repro would show the hypothesis is wrong? Write it before writing the fix.
76
+ - **Audit finding severity** → what evidence would demote HIGH to MEDIUM? Name it. If nothing would demote it, the severity is either a definition or a decree.
77
+ - **Cure recommendation** → what evidence would show this cure does not close the class? Name the test. If no test would falsify, the cure is faith not analysis.
78
+ - **Turn estimate** → the estimate is a prediction. What actuals would falsify it? Grounding estimates in prior WU turn counts is Popper's discipline — the prior WUs are the tests the estimate survives.
79
+ - **Root-cause claim** → the cause is the hypothesis. Removing it should remove the symptom. If removal does not remove the symptom, the cause was wrong. Test before shipping.
80
+
81
+ ## Anti-patterns it prevents
82
+
83
+ - **Unfalsifiable severity** — "This is HIGH-severity because it matters." No evidence would demote it. Not a claim.
84
+
85
+ INSTEAD: state the criteria that would demote the finding. If none exist, the finding is a decree, not evidence.
86
+
87
+ - **Root-cause attribution without repro** — "The cause is X" with no test that would show removing X does not remove the symptom.
88
+
89
+ INSTEAD: state the repro that would falsify. Run it. Ship the fix only after the test discriminates.
90
+
91
+ - **Cure recommendation without a losing condition** — "This cure closes the class" with no criterion that would show it does not.
92
+
93
+ INSTEAD: state the observation that would show the class still reproduces after the cure. That IS the acceptance test.
94
+
95
+ - **Confirmation-only diagnosis** — running only the test the hypothesis passes.
96
+
97
+ INSTEAD: run the severest test the hypothesis could survive. If it survives that, it is stronger than a test that was designed to pass.
98
+
99
+ - **Sweeping redesign** — replacing a hook, a rule, or a substrate primitive with a cleaner version, all at once, no reversibility path.
100
+
101
+ INSTEAD: ship the smallest reversible change. Piecemeal engineering ships smaller changes with revert paths.
102
+
103
+ ## Worked example
104
+
105
+ For a claim that a hook is dead-letter:
106
+
107
+ Popper's discipline:
108
+
109
+ - **Conjecture**: The hook `X.sh` is dead-letter — it exists on disk but is not wired in `.claude/settings.json`. Its checks do not fire.
110
+ - **Severe test**: Deliberately trigger the condition the hook is supposed to catch. Author a file that violates the hook's stated rule; attempt to write it. If the write succeeds without the hook firing, the conjecture is confirmed. If the hook fires and blocks the write, the conjecture is falsified.
111
+ - **Result**: Wrote the violating file. Write succeeded. No BLOCK message. The hook did not fire. Conjecture survives; hook is dead-letter.
112
+ - **What would falsify**: A BLOCK message appearing in the write attempt. It did not appear.
113
+
114
+ Without Popper's discipline the diagnosis would read "the hook seems broken" — no test, no falsification criterion, no way to distinguish "actually broken" from "I did not trigger it right." INSTEAD: state the conjecture, name the severe test, run it, report the result.
115
+
116
+ ## Sources
117
+
118
+ - *The Logic of Scientific Discovery* — Popper, Hutchinson (1935 German original; 1959 English translation; Routledge reprint)
119
+ - *Conjectures and Refutations: The Growth of Scientific Knowledge* — Popper, Routledge (1963)
120
+ - *The Open Society and Its Enemies* — Popper, Routledge (1945; Princeton reissue 2020)
121
+ - *Objective Knowledge: An Evolutionary Approach* — Popper, Oxford University Press (1972)
122
+ - Stanford Encyclopedia of Philosophy: entry on Popper — plato.stanford.edu/entries/popper/
123
+
124
+ ## Related luminaries
125
+
126
+ - **Stephen Toulmin** — Toulmin's argument model gives the shape (claim/data/warrant); Popper sharpens the rebuttal cell. A Toulmin argument without the rebuttal cell is a Popperian pseudo-claim. Both ship in bet 2026-07-01b WU-2.
127
+ - **Charles Sanders Peirce** — Peirce's abductive reasoning names multiple hypotheses; Popper says test each one severely. Peirce fills the alternatives; Popper says which alternative survives. Both ship in bet 2026-07-01b WU-2.
128
+ - **W. Edwards Deming** — Deming's PDCA cycle is Popper's conjecture-and-refutation applied to management. Plan (conjecture), Do (test), Check (see if the test broke the plan), Act (revise).
129
+ - **Michael Feathers** — Feathers' characterization tests are severe tests for legacy code. Without characterization tests, refactoring is unfalsifiable — no test would show the refactor broke behavior.
130
+ - **Kent Beck** — Beck's TDD is Popper at the code layer. The red test is the severe test the claim must survive to become green. TDD without a red step is unfalsifiable design.
131
+
132
+ Anchors `.claude/rules/assert-only-after-verify.md` alongside Toulmin + Peirce. Primary luminary for `/diagnose` skill in root-cause hypothesis testing.
@@ -0,0 +1,168 @@
1
+ ---
2
+ tier: lite
3
+ name: Kent Beck
4
+ slug: kent-beck
5
+ claimed_by: [builder, reviewer]
6
+ referenced_by_skills: [verify, pattern-review]
7
+ primary_domain: engineering
8
+ depth: full
9
+ sources:
10
+ - type: book
11
+ title: "Test-Driven Development: By Example"
12
+ authors: ["Kent Beck"]
13
+ year: 2002
14
+ url: "https://www.pearson.com/en-us/subject-catalog/p/test-driven-development-by-example/P200000009450"
15
+ isbn: "9780321146533"
16
+ methodology_covered:
17
+ - "TDD red/green/refactor cycle"
18
+ - "Test-first as design discipline, not verification afterthought"
19
+ - "Tests as the first client of your code"
20
+ - type: book
21
+ title: "Extreme Programming Explained: Embrace Change"
22
+ authors: ["Kent Beck", "Cynthia Andres"]
23
+ year: 2004
24
+ url: "https://www.pearson.com/en-us/subject-catalog/p/extreme-programming-explained-embrace-change/P200000009290"
25
+ isbn: "9780321278654"
26
+ methodology_covered:
27
+ - "XP practices: TDD, pair programming, continuous integration, simple design"
28
+ - "Embrace change as a competitive advantage"
29
+ - "Four rules of simple design — passes tests, reveals intention, no duplication, fewest elements"
30
+ - type: book
31
+ title: "Tidy First? A Personal Exercise in Empirical Software Design"
32
+ authors: ["Kent Beck"]
33
+ year: 2023
34
+ url: "https://www.oreilly.com/library/view/tidy-first/9781098151232/"
35
+ isbn: "9781098151249"
36
+ methodology_covered:
37
+ - "Tidy First — structural changes commit separately from behavioral changes"
38
+ - "Don't bundle refactor and feature in one PR"
39
+ - "Empirical software design — measure what works, adjust accordingly"
40
+ verification_status: verified
41
+ description: "\"Make it work. Make it right. Make it fast. Tests are the first client of your code.\""
42
+ ---
43
+
44
+ # Kent Beck
45
+
46
+ ## Signature
47
+
48
+ *"Make it work. Make it right. Make it fast. Tests are the first client of your code."*
49
+
50
+ Extreme Programming (XP) creator. Co-author of **the JUnit framework**.
51
+ Author of **Test-Driven Development: By Example** and **Extreme Programming
52
+ Explained**. The bassclef voice on TDD, simple design, and iterative
53
+ engineering practice.
54
+
55
+ ## Core methods
56
+
57
+ - **TDD red/green/refactor** — write failing test, write minimum code
58
+ to pass, refactor with tests passing. Not "write tests after" — the
59
+ test comes first and drives the design.
60
+ - **Four rules of simple design** — (1) passes all tests, (2) reveals
61
+ intention, (3) no duplication, (4) fewest elements. Apply in order
62
+ during refactoring.
63
+ - **Three phases of development** — Make it work (get the feature
64
+ functional), make it right (clean it up with tests protecting),
65
+ make it fast (optimize, measured).
66
+ - **Patterns for testability** — Fake It ('Til You Make It, Obvious
67
+ Implementation, Triangulation. Techniques for moving from red to
68
+ green without skipping steps.
69
+ - **XP practices** — pair programming, continuous integration, small
70
+ releases, simple design, refactoring, collective ownership.
71
+ Practices reinforce each other; removing any degrades the rest.
72
+ - **Tidy First** — distinguishing between structural changes (tidying,
73
+ no behavior change) and behavioral changes. Commit them separately.
74
+
75
+ ## When to channel this luminary
76
+
77
+ When the primary risk is code quality degrading under change pressure.
78
+ Beck dominates for teams new to TDD, Construction work where tests
79
+ aren't yet a reflex, and refactoring-heavy iterations. Pair with Fowler
80
+ (refactoring catalog) and Uncle Bob (SOLID principles) for the
81
+ engineering-quality triad.
82
+
83
+ Do NOT channel Beck for: research code that will be thrown away,
84
+ spike work where discovery matters more than sustainability, or work
85
+ on systems where the test infrastructure doesn't yet exist (wrong
86
+ layer — infrastructure first).
87
+
88
+ ## Stack translation
89
+
90
+ In Next.js + vitest + Playwright:
91
+
92
+ - **TDD for pure functions** → write failing unit test in
93
+ `src/__tests__/`, write function to pass, refactor. Scoring logic,
94
+ parsing, validation all belong here.
95
+ - **TDD for components** → failing React Testing Library assertion,
96
+ minimum component to pass, refactor for structure.
97
+ - **TDD for API routes** → failing integration test against real DB +
98
+ Redis, minimum route implementation to pass.
99
+ - **Tidy First** → structural refactor commits separate from feature
100
+ commits. "refactor: extract ScoringStrategy interface" + "feat: add
101
+ ML scorer" as two PRs, not one.
102
+ - **Three phases** → first PR makes feature work, subsequent PRs
103
+ right/fast. Don't bundle all three.
104
+
105
+ ## Anti-patterns it prevents
106
+
107
+ - **Test-after** — writing tests once the code "works" produces tests
108
+ that confirm what exists, not tests that drive design. Beck rejects
109
+ this as TDD.
110
+ - **Batched refactoring** — saving all cleanup for a quarterly "tech
111
+ debt sprint." Refactoring is continuous, inside the red/green/refactor
112
+ loop.
113
+ - **Premature optimization** — making it fast before making it work.
114
+ The order matters.
115
+ - **Pristine-never-commits** — holding a branch to "get it perfect"
116
+ before merging. Beck's XP favors small, frequent merges.
117
+ - **Test-less refactors** — rearranging code without tests is just
118
+ changing code. Can't claim refactor without behavior preservation,
119
+ and you can't prove preservation without tests.
120
+ - **Tidy mixed with feature** — commit that both refactors and adds
121
+ behavior makes review and revert harder.
122
+
123
+ ## Worked example
124
+
125
+ For adding POA deal-stage validation:
126
+
127
+ Beck's approach:
128
+ 1. **Red**: write failing test
129
+ `test('deal cannot advance past LOI without signed NDA', ...)`
130
+ 2. **Green**: add minimum code to pass — if-check in the stage-advance
131
+ controller
132
+ 3. **Refactor**: extract `IStageTransitionPolicy` interface,
133
+ `NdaSignedPolicy` implementation, `StagePolicyRegistry`
134
+ 4. **Tidy commit** separate from feature: "refactor: extract stage
135
+ transition policy interface" → PR merged first
136
+ 5. **Feature commit**: "feat: enforce NDA-signed requirement for LOI
137
+ advance" → PR merged second
138
+
139
+ What Beck would NOT produce: a single 400-line PR that adds the
140
+ feature, refactors the policy structure, adds telemetry, and fixes
141
+ three unrelated smells. That's everything bundled.
142
+
143
+ ## Sources
144
+
145
+ - *Test-Driven Development: By Example* — Beck, Addison-Wesley (2002)
146
+ - *Extreme Programming Explained: Embrace Change* — Beck, Addison-Wesley
147
+ (2nd ed 2004)
148
+ - *Tidy First?* — Beck, O'Reilly (2023)
149
+ - *Implementation Patterns* — Beck (2007)
150
+ - kentbeck.com + kent-beck.com — primary sites
151
+ - JUnit — software itself is bassclef reference
152
+
153
+ ## Related luminaries
154
+
155
+ - **Martin Fowler** — Refactoring catalog operationalizes Beck's
156
+ red/green/refactor loop. Beck credited Fowler's work as foundational.
157
+ - **Robert C. Martin** — SOLID principles frame what "right" looks
158
+ like in Beck's make-it-right step.
159
+ - **Ward Cunningham** — XP co-creator, Wiki inventor. Historically
160
+ inseparable from Beck.
161
+ - **Michael Feathers** — Working with Legacy Code handles the
162
+ before-state (no tests exist) that TDD assumes away. Both
163
+ luminaries became verification-side primaries on bassclef's
164
+ `/architect-review` SKILL per bet 27c WU-9.5 (2026-06-27); per
165
+ ADR-035 substrate-as-system tenet, every rule's mechanism claim
166
+ is a contract Beck's TDD pins + Feathers's characterization
167
+ tests verify. See `architecture/audits/2026-06-27-audit-method-blind-spot.md`
168
+ for the recursive Act phase that named the lens-gap.
@@ -0,0 +1,218 @@
1
+ ---
2
+ tier: lite
3
+ name: Linus Torvalds
4
+ slug: linus-torvalds
5
+ claimed_by: [architect, reviewer]
6
+ referenced_by_skills: [release, decompose, architect-review]
7
+ primary_domain: distribution-stability
8
+ depth: full
9
+ solves_problems_brownfield:
10
+ - "Substrate rename / refactor / path-change broke adopter sessions silently after merge"
11
+ - "Adopter following a citation in shipped substrate hit a 404 because the referenced path was renamed"
12
+ - "Hook filename change in bassclef caused adopter's session-start hook to fire stale logic"
13
+ - "PR ships a cleaner name for a hook / skill / rule and breaks every adopter inheriting through additionalDirectories"
14
+ - "Sync template version bumped without compat shim — adopter on prior version is in undefined behavior"
15
+ solves_problems_greenfield:
16
+ - "Designing a new adopter-observable surface where future renames must stay non-breaking"
17
+ - "Planning a release pipeline that catches adopter-breaking changes before they ship"
18
+ - "Authoring the first version of an adopter-facing manifest schema where every field becomes load-bearing once used"
19
+ - "Designing a compat-shim layer ahead of a planned rename so the deprecation window drains cleanly"
20
+ - "Building a representative-adopter integration test that runs against every substrate change"
21
+ anti_patterns:
22
+ - "Dev-machine-only test — works for the author, breaks at sync time for adopters"
23
+ - "Clean-break rename motivated by conceptual integrity — costs more than it saves once observers exist"
24
+ - "Announcement-as-shim — written notice that the old name has gone away, with no surviving artifact"
25
+ - "Deprecation window without a real-adopter migration test — the deprecation tail outlasts the window"
26
+ sources:
27
+ - type: archive
28
+ title: "LKML 2012-12-23: 'We do not break userspace'"
29
+ authors: ["Linus Torvalds"]
30
+ year: 2012
31
+ url: "https://lkml.org/lkml/2012/12/23/75"
32
+ methodology_covered:
33
+ - "Userspace stability as non-negotiable kernel discipline"
34
+ - "Regressions are bugs even when prior behavior was buggy"
35
+ - type: book
36
+ title: "Linux Kernel Development (3rd ed.)"
37
+ authors: ["Robert Love"]
38
+ year: 2010
39
+ url: ""
40
+ methodology_covered:
41
+ - "Kernel ABI stability discipline across versions"
42
+ - "Syscall number preservation; new behavior gets new syscall"
43
+ - type: archive
44
+ title: "Stability of the Linux ABI — Linux Foundation TAB"
45
+ authors: ["Linux Foundation Technical Advisory Board"]
46
+ year: 2014
47
+ url: "https://www.linuxfoundation.org/"
48
+ methodology_covered:
49
+ - "Module ABI stability commitments"
50
+ - "Internal API churn vs external ABI freeze"
51
+ - type: talk
52
+ title: "Driver ABI Stability"
53
+ authors: ["Greg Kroah-Hartman"]
54
+ year: 2015
55
+ url: "https://elinux.org/ELC_2015_Presentations"
56
+ methodology_covered:
57
+ - "Why kernel internals stay unstable on purpose; why exported ABI stays frozen"
58
+ - type: archive
59
+ title: "LKML 'regressions are bugs' thread (multiple instances 2008–2021)"
60
+ authors: ["Linus Torvalds", "LKML community"]
61
+ year: 2008
62
+ url: "https://lkml.org/"
63
+ methodology_covered:
64
+ - "Revert-on-regression default"
65
+ - "Producer pays migration cost, adopter pays nothing"
66
+ verification_status: verified
67
+ description: "\"We do not break userspace.\" — INSTEAD: the kernel team pays the migration cost so every program that ran yesterday keeps running today."
68
+ ---
69
+
70
+ # Linus Torvalds
71
+
72
+ ## Signature
73
+
74
+ *"We do not break userspace."* — INSTEAD: the kernel team pays the migration cost so every program that ran yesterday keeps running today.
75
+
76
+ Principal architect of Linux. The kernel's single most-cited rule across 30+ years of evolution is the userspace stability commitment. The cost of evolution rides with the kernel team. Adopters carry zero migration burden. This is the discipline bassclef applies at the substrate → adopter boundary.
77
+
78
+ ## Core principle
79
+
80
+ Userspace stability is the ceiling, not a tradeoff. Linus's framing (LKML 2012, restated dozens of times since): a change that breaks user programs is a kernel bug, regardless of whether the user program was relying on documented or undocumented behavior. The kernel team has rejected technically-better designs because the migration cost to userspace was too high. Shipped compatibility shims have outlived the original feature by a decade. Permanent code complexity is accepted as the price of adopter trust.
81
+
82
+ Three operational consequences flow from this:
83
+
84
+ 1. **Regressions are bugs even when prior behavior was buggy.** INSTEAD of fixing forward into a cleaner state: revert, fix the underlying problem from a different angle, ship the fix without changing the observable surface adopters depend on.
85
+ 2. **The producer pays the cost.** INSTEAD of telling adopters to migrate: ship the compat shim, keep the old surface alive, document the retirement condition as "when the last known adopter migrates."
86
+ 3. **Conceptual integrity has a budget.** INSTEAD of treating rename-for-cleanliness as free: weigh the rename benefit against migration cost × adopter count. When the cost exceeds the benefit, hold the rename.
87
+
88
+ ## What this looks like in Linux
89
+
90
+ - **Syscall ABI is permanent.** Once a syscall ships, the signature stays. INSTEAD of changing an existing syscall: a new behavior gets a new syscall number; the old one keeps working forever.
91
+ - **Struct layouts grow but stay backward-compatible.** Removed fields stay as reserved holes. INSTEAD of rearranging fields: a new struct gets introduced; the old one stays usable.
92
+ - **/proc and /sys accumulate compatibility commitments.** Even ad-hoc debug surfaces become quasi-stable once tools parse them.
93
+ - **Compatibility shims live forever.** The kernel still supports 32-bit syscalls on 64-bit kernels for old binaries — INSTEAD of forcing a migration to 64-bit.
94
+ - **Regressions revert by default.** When a feature change breaks any adopter, the change reverts. INSTEAD of asking the adopter to adapt: the kernel team re-engineers from a different angle.
95
+
96
+ ## Core methods
97
+
98
+ Five named methods an agent can invoke by name during review or design:
99
+
100
+ - **Adopter-observable surface enumeration** — Before any substrate change, list every surface adopters can observe (filesystem paths, hook filenames, schema field names, skill names referenced by settings.json, symlink targets, sync-template version markers). When the enumeration is missing from the PR body, the change is not yet reviewable. INSTEAD of reviewing on faith: send the PR back with a request for the surface list.
101
+
102
+ - **Compat-shim-first ship discipline** — Build the shim in the same release as the change. Symlink at the old path, alias at the old name, forwarding stub at the old hook filename, schema accommodation that accepts both names during transition. INSTEAD of "ship the rename now, add the shim later": ship both together; the gap between them is the window where adopters break.
103
+
104
+ - **Real-adopter integration test** — Test the change against a clone of a representative adopter. Run the adopter's actual sync hook against proposed substrate HEAD. Confirm zero observable change. INSTEAD of dev-machine validation: the cold-adopter harness IS the real-adopter test surface; the change waits for the harness when it isn't yet built.
105
+
106
+ - **Revert-on-regression default** — When a feature change breaks any adopter, revert by default and fix from a different angle. INSTEAD of trading adopter trust for the partial win: adopter trust is the ceiling; the feature is re-engineered.
107
+
108
+ - **Permanent-shim acceptance** — Accept that some compat shims live forever. The kernel still supports 32-bit syscalls for old binaries. INSTEAD of cycling shims through deprecation: document the retirement condition honestly ("when all known adopters migrate") and expect the answer is "forever."
109
+
110
+ ## When to channel this luminary
111
+
112
+ When the primary risk is **adopter-observable surface change**. Linus dominates the review lens any time a PR touches:
113
+
114
+ - Filesystem paths under `~/src/sunj-labs/` that adopter symlinks resolve through
115
+ - Filenames inside `.claude/hooks/`, `.claude/skills/`, `.claude/rules/`, `.claude/agents/` (adopter settings.json + symlinks reference them by name)
116
+ - Schema shapes in `standards/state-spine/schemas/`
117
+ - Sync-template version markers in `presence/install/`
118
+ - `.bassclef-source.json` schema
119
+ - Adopter migration tooling under `scripts/migrate-*`
120
+ - Release pipeline andon decisions (per ADR-029)
121
+ - Rename / move / refactor of any of the above
122
+
123
+ Pair with Hyrum Wright (provides the theoretical why — observability creates dependency), Michael Nygard (ADR lifecycle for the breaking-change decision), and Vaughn Vernon (anticorruption layer is the structural shape Linus's discipline produces).
124
+
125
+ Outside this scope, route elsewhere. INSTEAD of channeling Linus for bassclef-internal refactors that touch zero adopter-observable surface: channel John Ousterhout (deep modules) or Kent Beck (TDD cycle). INSTEAD of channeling Linus for operator-private content under `docs/operator-private/`: that content stays in bassclef-upstream and doesn't ship to adopters; Linus's discipline is silent there. INSTEAD of channeling Linus for chronicles and journal entries: those are operator narrative, not contract; voice luminaries apply.
126
+
127
+ ## Stack translation
128
+
129
+ bassclef is a substrate. Adopters are the userspace. Every adopter-observable surface is a syscall: once shipped, the surface keeps working forever unless an explicit multi-cycle deprecation runs.
130
+
131
+ Map:
132
+
133
+ | Linux kernel | bassclef substrate |
134
+ |---|---|
135
+ | Syscall ABI | hook filenames, skill names, agent names referenced by adopter settings.json |
136
+ | `/proc` + `/sys` | filesystem paths under `~/src/sunj-labs/` that adopter symlinks resolve through |
137
+ | Struct layouts | state-spine schema shapes |
138
+ | Module ABI | sync-template version markers in `presence/install/bassclef-sync.template.sh` |
139
+ | Boot interface | `.bassclef-source.json` schema fields |
140
+ | LKML release announcements | `/release` PR body Summary section + adopter changelog entry |
141
+ | Kernel-internal refactors | bassclef-internal refactors touching only `docs/operator-private/`, chronicles, internal scripts unexposed to adopters |
142
+
143
+ When bassclef renames `canonical → bassclef`, that is the equivalent of removing a syscall. The discipline answer: leave a compatibility shim (symlink, alias, forwarding stub) at the old name. Deprecate explicitly. Give adopters a grace period measured in `/release` cycles. INSTEAD of removing the shim once a deadline passes: remove only with an explicit ADR documenting the breaking change and citing the migration test that proves zero adopter remains on the old name.
144
+
145
+ ## Anti-patterns it prevents
146
+
147
+ - **Dev-machine-only test.** "It works on my machine." INSTEAD: clone a representative adopter; run their sync hook; confirm zero observable change. The dev machine is one environment among many.
148
+
149
+ - **Clean-break rename motivated by conceptual integrity.** "The new name is clearer." INSTEAD: weigh the rename benefit against migration cost × adopter count. Hold the rename when the math tips against it. Brooks's conceptual-integrity is a budget, not a license.
150
+
151
+ - **Announcement-as-shim.** "We told them in advance." INSTEAD: ship the technical artifact (symlink, alias, forwarding stub) that keeps the old name working. Communication is necessary AND insufficient on its own.
152
+
153
+ - **Single-adopter dismissal.** "Only one adopter uses this surface." INSTEAD: ship the shim anyway. Hyrum's Law applies the moment any adopter observes the surface; declared user count fails as the metric.
154
+
155
+ - **Deprecation window without a real-adopter migration test.** "We gave them three release cycles." INSTEAD: the migration test verifies adopters actually moved; the calendar window verifies only that time passed.
156
+
157
+ ## Worked example
158
+
159
+ **Scenario:** Tonight's bet 25e shipped a structural cold-adopter harness. The next bet ships shape b — a sync round-trip harness that runs against a fresh clone. The harness will catch regressions like #336 (bassclef-sync.sh §4 missing PreToolUse template embedding).
160
+
161
+ **The Linus lens applied at PR-review time for #336 fix:**
162
+
163
+ 1. **Adopter-observable surface enumeration** — the agent reviewing the #336 PR lists every adopter-observable surface the fix touches: the PreToolUse hook matcher, the settings.json template merged into adopter sessions, the hook firing order, and the stderr contract on BLOCK exits. All four are observable; all four must stay stable across the fix. INSTEAD of accepting a PR body that lists only the bug fix: send back for the surface enumeration.
164
+
165
+ 2. **Compat-shim-first** — the fix ships the embedding template AND the test that catches it in the same PR. INSTEAD of "add the embedding now, add the test next bet": same release, or the gap between fix and verification is the window where adopters silently inherit the buggy state.
166
+
167
+ 3. **Real-adopter integration test** — the new shape b harness IS the real-adopter test. Once the harness ships (next bet), the #336 fix gets re-run against the cold-adopter clone and the PreToolUse path fires correctly post-sync. INSTEAD of trusting unit tests alone: the harness validates the adopter-observable surface end-to-end.
168
+
169
+ 4. **Revert-on-regression default** — if the #336 fix causes any adopter-observable regression (a different hook stops firing, a stderr message changes, the merge logic drops an operator key like #340 did), the fix reverts. INSTEAD of trading adopter trust for the partial win: revert, re-engineer from a different angle, ship without changing the observable surface.
170
+
171
+ 5. **Permanent-shim acceptance** — the cp-fallback in additive_merge_settings (the surface #340 patches) is exactly the kind of shim that lives forever. Adopters on older `jq` versions, adopters without `jq` at all, adopters whose settings.json predates the new schema — the cp-fallback covers them all. INSTEAD of removing the fallback once a new merger ships: keep both paths alive; the cost is permanent merge-logic complexity; the benefit is permanent adopter compatibility.
172
+
173
+ The shape-b harness shipping as a methodology-only document with a deferred mechanical layer fails this lens. INSTEAD: the mechanical layer IS the discipline — without the harness running against every PR, the adopter-observable surface stays untested and the next #336-class regression ships silently.
174
+
175
+ ## How to apply
176
+
177
+ When designing or reviewing a substrate change:
178
+
179
+ 1. **Identify every adopter-observable surface the change touches.** When the surface list is missing from the PR body, the change is not yet ready. INSTEAD of guessing: enumerate explicitly.
180
+ 2. **Ask "would an adopter's existing program break?"** INSTEAD of "should it" — would it. Think about every adopter shape: vendored snapshot, thin-pointer, cold-onboarding, partial-sync.
181
+ 3. **When the answer is yes, build the shim first.** Symlink, alias, forwarding stub, schema accommodation. Whatever makes the old name keep working.
182
+ 4. **Document the shim's retirement condition.** "When all known adopters migrate" or "after N release cycles." INSTEAD of "forever": match Linus's commitment to permanent code when the data demands it.
183
+ 5. **Test the shim against a real adopter.** The cold-adopter harness is the substrate's vehicle for this. INSTEAD of dev-machine validation: clone a representative adopter, run their sync hook, confirm zero observable change.
184
+ 6. **Ship the shim in the SAME release as the rename.** INSTEAD of "we'll add a shim later": same PR, same release; the gap between rename and shim is the breakage window.
185
+
186
+ ## How bassclef channels Linus
187
+
188
+ The discipline lives in:
189
+
190
+ - `.claude/rules/we-dont-break-adopters.md` — methodology layer; cites Hyrum's Law as the theoretical why and Linus's discipline as the operational answer
191
+ - `architecture/decisions/ADR-031-non-breaking-changes-adopter-discipline.md` — decision layer; adopts the discipline as Tier 1
192
+ - `architecture/dual-repo-flow.md` "Non-breaking changes to adopters" section — architectural layer
193
+ - `scripts/migrate-adopter-references.sh` — adopter self-healing tool for the canonical → bassclef cascade
194
+ - `presence/install/bassclef-sync.template.sh` — the sync surface that adopters depend on; load-bearing per this discipline
195
+ - `scripts/cold-adopter-harness.sh` (bet 25e) + planned shape b sync round-trip (#341) — the real-adopter integration test surface
196
+ - bassclef-upstream#1360 — Phase 2 mechanical layer (pre-rename CI test against representative adopter, redirect registry, versioned sync protocol)
197
+
198
+ ## Sources
199
+
200
+ - LKML 2012-12-23 — "We do not break userspace" thread (Linus Torvalds, re: PowerPC syscall change)
201
+ - *Linux Kernel Development* — Robert Love, Addison-Wesley (3rd ed. 2010)
202
+ - *Stability of the Linux ABI* — Linux Foundation Technical Advisory Board (2014)
203
+ - ELC 2015 — Greg Kroah-Hartman, "Driver ABI Stability"
204
+ - LKML "regressions are bugs" thread — multiple instances 2008, 2011, 2014, 2017, 2021
205
+
206
+ ## Related luminaries
207
+
208
+ - **Hyrum Wright** — provides the theoretical why (observability creates dependency); Linus provides the operational answer (we just keep userspace working). They pair as why + how.
209
+ - **Michael Nygard** — stability patterns at runtime; ADR lifecycle for the breaking-change decision. Operates at runtime-failure layer where Linus operates at API-surface layer; complementary.
210
+ - **Vaughn Vernon** — anticorruption layer is the structural pattern Linus's discipline produces in practice. When the substrate must do an internal rename, the anticorruption layer between substrate-internal and adopter-observable preserves stability.
211
+ - **Frederick Brooks** — frames the conceptual-integrity-vs-migration-cost tradeoff. Linus picks adopter stability every time; Brooks gives the language to reason about when the tradeoff actually costs more than it saves.
212
+ - **Kent Beck** — adjacent at the test-first layer. Linus's real-adopter integration test IS Beck's red-first discipline applied at the adopter boundary.
213
+
214
+ ## Refs
215
+
216
+ - bassclef-upstream#1360 — Phase 2 mechanical layer
217
+ - 2026-06-21 chronicle — the canonical → bassclef cascade + recovery + rule authoring
218
+ - ADR-031 — non-breaking-change adopter discipline (decision layer)