FOCUS: Architecture for People Who Ship Software — Chapter 01 Memory: About the Author

Stage: Previewed — awaiting reading
Next Step: Wait for the reader to say “done” or /review, then ask 2–3 active-recall questions.
Reading Span: PDF pages 13–20
Source Text: /library/FOCUS Architecture/Chapter-01-About-the-Author/Chapter-01-source-text.md (the chapter's own words; read instead of the PDF)
Full Record: /library/FOCUS Architecture/Chapter-01-About-the-Author/Chapter-01-chapter-notes.md (read only if needed)
Last Updated: 2026-10-01

Carried-in Context (from earlier chapters)

First chapter — nothing carried in. (Same author as Spec Driven Development and Context Engineering; the trilogy map in SDD says FOCUS answers “where”: where each rule belongs in code, dependencies pointing inward.)

Core Question: How can software stay easy to change as it grows, without making a small change hard to locate or risky to make?
Watch-For Themes: What the “F12 test” measures when navigating unfamiliar code; how two project stories show different ways cost of change rises; which measure the author uses to judge an architecture beyond apparent simplicity; how he moves from experience to the four-piece structure and what evidence would convince; why locating a rule matters more when code is generated quickly.
Core Thesis: Pending synthesis.
Key Concepts: F12 test; cost of change; architectural layers; locating business rules.
Notable Arguments / Evidence Limits: Pending.
Action Item: Pending synthesis.

Cross-book: does the organization of code change the information a human or model can recover, as suggested by the reader's open Context Engineering thread?