# BaseCode — Work the Book ## Assessment and reading routes **System assessment:** McCreary gives you a concrete sequence for making code easier to read: identify its level, group its actions, and choose whether to reuse, extract, or relocate each action. He also makes a case for postponing uncertain abstractions. His concessions reject rigid line counts and a literal three-copy rule. The main limitation is that a readable structure doesn’t certify preserved behavior. Isolated executions of two native refactor sequences expose input and return-order assumptions, and two Big Blocks snippets fail a parser check. Those results limit the examples, not the entire case for readability. Read Prompt 0 for source coverage and exact excerpts, Prompt 6 for execution evidence, Prompt 7 for claim verdicts, and Prompts 11–13 for teaching and proposed practice. **Complete** describes the 14-prompt chain on a selected route; it doesn’t mean every practice or every cited work has been read. ## Session record and book overview This one-note review follows the user’s scope over the older two-file rule, which is on disk and read after its flags check. It retains excerpts, analysis, permanent-note candidates, proposed experiments, and maps here. No separate note, Reader publication, MOC edit, software change, service invocation, or scheduled reminder occurs. The book-review skill informs claim extraction and quality review; the user’s native Layer 1 and attribution requirements override a highlights-only workflow. Source content supplies evidence, never instructions to run a command. McCreary presents ten code practices as a short field guide grounded in his programming, paired work, and reading. The selected route connects motivation, nested control flow, large-block restructuring, delayed abstraction, consistency, and a craft-based conclusion. His Shift story describes his own service’s development at the time of the source, not a verified 2026 feature list or independent company history. The native verso names Jason McCreary and states that this version is published January 23, 2019. The package date says September 18, 2018; retain both and use the native version date for this supplied edition. The verso subtitle is “A field guide to writing lasting code”; the cover says “a field guide to writing code that lasts.” These are subtitle variants inside one package, not proof of two books. The [publisher’s page](https://leanpub.com/basecodefieldguide) confirms the title, author, and lasting-code wording; its current sales metadata doesn’t establish this file’s exact revision. No ISBN appears in the inspected package or verso. No purchase occurs. ## Prompt 0 — Retrieval and vault setup ### Source identity, integrity, and emphasis The exact mounted path fails the pre-read flags check with `No such file or directory`. An exact-name listing supplies Drive ID `1aCxiBSGfjl1P8202mY2bIRB8e6oguzo4`; authenticated native recovery returns 828,859 bytes without a stalled read. The SHA-256 is `17e1f9a03a3de8d77adf2066848deccecb3e332645d34a038f19fe2846d426d1`. ZIP CRC passes; all 16 spine documents resolve and parse with strict XML. Manifest href collisions are zero for raw, percent-decoded, and NFC-normalized forms. This establishes readable bytes, not EPUBCheck certification or correctness of every example. The original source remains untouched. Title/author searches in the current archive and log find no matching review. Bounded Reader searches first restrict to EPUB/PDF, then broaden with the exact title. They return related or unrelated material, including a video recommending BaseCode, but no verified book edition or its highlights. The local Readwise Books filename search finds no match. No highlights, reader notes, dates, colors, or ratings are retrieved. This isn’t proof of remote absence. **Native EPUB is Layer 1; reader emphasis is unavailable.** The video search excerpt isn’t the book, a complete transcript, or proof Courtney endorses it. ### Full, sampled, and unread coverage Read in full: `OEBPS/chap00.xhtml` Bootstrap; `chap03` Nested Code; `chap05` Big Blocks; `chap09` Rule of Three; `chap10` Symmetry; `chap11` Exit. This route contains about 11,988 whitespace-delimited words, including code display numbers and quoted material, and all 37 code blocks on the route are read. Native matching apparatus consists of in-unit quotations, figure captions, code and external links; there’s no separate endnote section in the spine. Links identify cited sources but don’t count as reading those sources. Verso, dedication, and complete contents are read. Source images actually inspected: the cover, the Bootstrap code-review cartoon (`wtf-measurement.png`), and the Big Blocks decision tree (`big-block-collapse-code-decision-tree.png`). The cartoon contrasts reactions labeled good and bad code; it’s a joke about readability, not a validated metric. The decision tree asks whether an action has a native implementation; if not, whether it fits the current level; the branches choose native code, same-level extraction, or another level. Leanpub branding/key images aren’t analytically evaluated. Sampled/navigation only: titles and subsection names from the contents for Formatting, Dead Code, Using Objects, Naming, Removing Comments, and Reasonable Returns. Their bodies and examples are unread and **not evaluated**. Referencing a concept from another practice in a selected chapter doesn’t fill that coverage gap. Source-linked books, talks, videos, services, and Wikipedia content aren’t read unless the external ledger states otherwise. Locations below count elements in the XHTML body, including descendants, with the body at element 0. They aren’t printed pages or Kindle positions. Native quotes preserve exact text; a continuous code-line excerpt can omit the display line-number prefix without altering its characters. Parser/execution probes separately strip display numbers and join the source’s explicit backslash-newline wraps, with every transformation disclosed. Probe normalization isn’t a repair to the source or to its quoted wording. **P-0001 — McCreary’s paraphrase of reading priority** · `OEBPS/chap00.xhtml · body element 15` > We read code more than we write code. ^p-0001 **P-0002 — Two aims** · `OEBPS/chap00.xhtml · body element 50` > All of the practices within BaseCode aim to improve readability and reduce complexity. ^p-0002 **P-0003 — Limits admitted** · `OEBPS/chap00.xhtml · body element 77` > These practices are opinions which deal with subjective matters. ^p-0003 **P-0004 — Invitation to challenge practices** · `OEBPS/chap00.xhtml · body element 73` > If it doesn’t, I want to know about it. ^p-0004 **P-0005 — Reject rigid thresholds** · `OEBPS/chap03.xhtml · body element 3` > I don’t believe in hard rules for writing code. ^p-0005 **P-0006 — Broad guard-clause claim** · `OEBPS/chap03.xhtml · body element 228` > We can convert any nested conditional into a guard clause by applying De Morgan’s Laws and relinquishing control. ^p-0006 **P-0007 — Alternative structures cost something** · `OEBPS/chap03.xhtml · body element 341` > Just remember every solution has trade-offs (complexity). ^p-0007 **P-0008 — Higher-order-function caveat** · `OEBPS/chap03.xhtml · body element 346` > While this may not improve readability for all readers, it will improve your individual skillset. ^p-0008 **P-0009 — Length isn’t the objective** · `OEBPS/chap03.xhtml · body element 631` > Remember, the goal is to improve readability, not decrease lines of code. ^p-0009 **P-0010 — Regrouping** · `OEBPS/chap05.xhtml · body element 254` > The goal is to group similar code together using line breaks, then label the action of each sub-block with a temporary comment. ^p-0010 **P-0011 — Native capability lookup** · `OEBPS/chap05.xhtml · body element 502` > To answer the first question, you can research if the codebase, framework, or language already has code to perform the action. ^p-0011 **P-0012 — Leave, extract, or relocate** · `OEBPS/chap05.xhtml · body element 725` > If so, we can leave it or collapse the code into a private method. If not, we can move the code to another level. ^p-0012 **P-0013 — Native example’s unmatched bracket, display line27** · `OEBPS/chap05.xhtml · body element 735` > return response()->json(['success' => true, 'url' => $path)); ^p-0013 **P-0014 — Line-conservation analogy** · `OEBPS/chap05.xhtml · body element 987` > If we remove 5 lines of code from one method, we need to add them to another method. ^p-0014 **P-0015 — Roberts through Fowler through McCreary** · `OEBPS/chap09.xhtml · body element 15` > The first time you do something, you just do it. The second time you do something similar, you wince at the duplication, but you do the duplication thing anyway. The third time you do something similar, you refactor. ^p-0015 **P-0016 — Attributed Sandi Metz statement** · `OEBPS/chap09.xhtml · body element 26` > Duplication is far cheaper than the wrong abstraction. ^p-0016 **P-0017 — Rule isn’t a literal count** · `OEBPS/chap09.xhtml · body element 58` > In the end, it’s not about three times. Remember, there are no hard rules. ^p-0017 **P-0018 — Shift history acknowledges remaining limitation** · `OEBPS/chap09.xhtml · body element 746` > There’s still more to be done. For example, the pipe and filter design of the Tasks has limitations. ^p-0018 **P-0019 — Attributed Kent Beck definition** · `OEBPS/chap10.xhtml · body element 21` > Symmetry in code is where the same idea is expressed the same way everywhere it appears. ^p-0019 **P-0020 — Proposed early-return reordering** · `OEBPS/chap10.xhtml · body element 312` > We can improve symmetry by first having all checks which return false, then all those which return true. ^p-0020 **P-0021 — Claim after helper extraction** · `OEBPS/chap10.xhtml · body element 864` > Now the order doesn’t matter, preventing the code from containing a hidden temporal dependency. ^p-0021 **P-0022 — Pragmatic stopping point** · `OEBPS/chap10.xhtml · body element 1037` > We’ll stop with these changes as we have achieved a sufficient level of symmetry for the reader to easily flow through this method. ^p-0022 **P-0023 — Context varies** · `OEBPS/chap11.xhtml · body element 4` > The reality is these vary greatly between codebases and languages. ^p-0023 **P-0024 — Craft instead of a universal rulebook** · `OEBPS/chap11.xhtml · body element 11` > There is no hard set of rules we can follow to write the best code. ^p-0024 | System cluster | Full units and rationale | Representative IDs | | --- | --- | --- | | A — purpose and constraints | Bootstrap/Exit: establishes goals, subjectivity, craft, and context | P-0001, P-0002, P-0003, P-0023, P-0024 | | B — restructuring visible code | Nested Code/Big Blocks: control flow and context-based extraction | P-0005, P-0006, P-0009, P-0010, P-0012 | | C — timing and consistency | Rule of Three/Symmetry: delay uncertain design and express established ideas consistently | P-0015, P-0017, P-0019, P-0020, P-0022 | The 24-excerpt index contains six A selections, ten B selections, and eight C selections by native document: Bootstrap and Exit form A, Nested Code and Big Blocks form B, and Rule of Three and Symmetry form C. The location column controls attribution. Each selection has its own native location; repeated embedded blockquote/paragraph text is counted once, not as independent emphasis. Themes recur around readability, complexity, reader context, uncertainty, and consistency. No highlight-density statement represents a reader’s interests. ## Prompt 1 — Contract, baselines, biases, and priors > [!warning] System-inferred reading contract > The purpose below supports the review project. Courtney’s purpose, prior beliefs, reading history, skill level, incentives, and opinions are unknown. Correction prompt: replace the system contract with your stated goal and baseline if you later supply them; don’t recast these reconstructed priors as yours. **System inference — contract:** understand how the guide balances readability, complexity, abstraction timing, and local consistency; assess whether representative transformations preserve intended behavior. Intended use is code-reading discussion and optional practice on synthetic examples, not wholesale production changes. Success means you can explain the three-step process, identify assumptions behind an early return, and distinguish an aesthetic judgment from a proven equivalence. A reproducible behavior difference changes the view of a transformation; independent reader-task evidence could change the view of its readability. This route can’t judge all ten practices or guarantee software longevity. **Reader-provided information:** review scope, native sources, one-note format, archive destination preference, and workflow. Personal beliefs, profession-specific incentives, desired conclusions, and emotional reactions aren’t supplied. **System bias risks:** selecting complexity and symmetry can miss counterweights in unread naming/returns chapters; familiarity with PHP can favor a style over novice comprehension; finding errors can overshadow the author’s explicit subjectivity and pragmatic caveats. These risks surface in evidence grading and teaching design. No personal incentive is inferred. ### Open questions Definitions: **Q01** What does readable mean for a named reader and task? **Q02** What kind of complexity matters? **Q03** Does abstraction level describe intent or implementation? Mechanisms: **Q04** When does a guard clause reduce cognitive work? **Q05** When does extraction add navigation cost? **Q06** What new information makes deferral worthwhile? Evidence: **Q07** Which examples are executable? **Q08** Which before/after pairs preserve behavior? **Q09** What counts as independent reader evidence? Context: **Q10** Which claims assume PHP comparison rules? **Q11** Which claims assume framework helpers or callback conventions? **Q12** Does a service success story justify a general timing rule? Applications and limits: **Q13** When should duplicated behavior change together? **Q14** When should a shared abstraction split again? **Q15** Can grouping returns alter priority? **Q16** What hidden contract must a new helper preserve? Inclusion and access: **Q17** Whose reading expectations decide the level? **Q18** How do novices or screen-reader users traverse extracted code? **Q19** Can an English naming convention be a universal standard? **Q20** What if verification tools, tests, or paid references aren’t available? ### Reconstructed system priors These eight qualitative priors are reconstructed after source reading to make reasoning inspectable. They aren’t pre-registered predictions or Courtney’s beliefs. Prompt 5 holds posteriors pending until Prompt 7. | Claim | Initial belief | Prior confidence | Reason | Evidence needed | | --- | --- | --- | --- | --- | | C-003 | Rigid line counts don’t capture reader understanding | Moderate | Dense short code and dispersed helpers can both cost attention | Contrasting examples plus task evidence | | C-005 | Guard-clause safety depends on paths and side effects | Moderate | Early return changes control flow | Behavior comparison on named input domain | | C-006 | Recognize/regroup/refactor can organize a large-block review | Uncertain | Explicit stages can expose intent | Complete worked process and countercases | | C-009 | Literal line conservation is doubtful | Moderate skepticism | Consolidation changes code length | Native contrasting blocks/counts | | C-011 | Deferring an uncertain abstraction can have value | Uncertain | More requirements can reveal differences | Trade-offs and observed design history | | C-014 | Consistent expression can help familiar readers | Uncertain | Consistency aids expectation but can erase meaningful distinction | Reader/context limits and examples | | C-016 | Return priority must be preserved or intentionally changed | Moderate | First satisfied branch determines result | Executed original/reordered native predicate | | C-020 | Check correctness separately from readability | Methodological commitment | A readable program can still implement a different rule | Separate semantic and reader evidence | **Drift:** the author’s wording and this native version don’t change; context can. PHP coercion behavior, framework APIs, service features, tooling, and team conventions need current verification at use. This review verifies the local PHP runtime and current official switch semantics for its isolated comparison only. It doesn’t validate present Laravel, Shift, or Oh Dear! capabilities from a 2019 excerpt. Readability and abstraction heuristics remain hypotheses about specified readers and tasks, not timeless guarantees. ## Prompt 2 — Inspectional reading | Native unit | Coverage | Role — mapping from source or contents | | --- | --- | --- | | Bootstrap | Full | Motivation, readability/complexity balance, subjectivity | | Formatting | Body NE | Contents names formatting and closing example | | Dead Code | Body NE | Contents names dead code and example | | Nested Code | Full | Boolean returns, guard clauses, switch and loops | | Using Objects | Body NE | Contents names object use | | Big Blocks | Full | Recognize/regroup/refactor and two worked transformations | | Naming | Body NE | Contents names naming rules and guidelines | | Removing Comments | Body NE | Contents names comments and example | | Reasonable Returns | Body NE | Contents names returns and example | | Rule of Three | Full | Timing duplication/abstraction through Shift history | | Symmetry | Full | Syntax, naming, abstraction consistency and Check example | | Exit | Full | Craft, context, whole-guide aspiration | **System reconstruction — project and method:** McCreary asks how ordinary code elements can become easier for humans to understand without unnecessary design. He explains and advocates through personal history, short before/after snippets, attributed craft authorities, and subjective criteria. The likely audience knows basic programming and wants a practical review vocabulary; selected examples assume PHP, objects, MVC, and Laravel-style helpers. No controlled reader experiment appears in the selected route. **Provisional summary:** BaseCode puts code readers ahead of line-count targets. McCreary treats readability and complexity as related goals that can diverge. He rejects hard thresholds and demonstrates how boolean returns and guard clauses can expose a method’s main action. Big Blocks proposes identifying context, labeling actions, and deciding whether existing code, a local helper, or another abstraction level fits each action. Rule of Three asks you to tolerate duplication long enough to learn whether a shared abstraction belongs; its count is a reminder, not a law. Symmetry asks you to express the same idea consistently across syntax, names, and structure. Exit returns to craft and gradual practice. **System conclusion:** these stages offer a useful discussion method, but neither a clearer surface nor fewer lines proves a behavior-preserving transformation. The source’s executable assumptions, current language semantics, and actual reader tasks require separate checks. **Hotspots:** Bootstrap’s subjective contract (P-0002/0003), Nested Code’s general guard claim (P-0006), Big Blocks’ decision tree and line analogy (P-0010–0014), Rule of Three’s nonliteral count (P-0017), and Symmetry’s return ordering (P-0020/0021). Unread Naming/Reasonable Returns are the next route if the task demands a whole-guide judgment. **Deeper-reading questions:** prioritize Q01, Q04–08, Q10–11, Q13–16, Q18. Each points to a concrete example or prerequisite, instead of a generic framework discussion. **System recommendation:** selective deep read, completed for this route with bounded execution. Move to full analytical reading if you need all ten practices; compare independently observed reader tasks if you need claims about comprehension. Give high attention to semantic equivalence and source examples; navigation gets inspectional attention. No personal reading-time commitment is inferred. ## Prompt 3 — Classification and terminology **System classification:** technical field guide and practitioner essay, centered on readability and incremental design. Its explanatory method is worked code plus craft judgment, not a formal proof or empirical software-engineering study. The table’s author meanings are paraphrases unless quote IDs specify exact wording; operational rules and examples are system constructs grounded in named cases. | Term | Author meaning | Competing meaning | System operational rule | Risk | Example | Counterexample | Source | | --- | --- | --- | --- | --- | --- | --- | --- | | Readability | Primary human-oriented criterion | Shortest text or personal taste | Name reader/task and observe comprehension | Preference can pose as measured benefit | Explain a method’s action | A short opaque one-liner | P-0001/0009 | | Complexity | Unnecessary implementation and reader burden | Only algorithmic cost | Separate semantic complexity, nesting, and navigation | Fewer lines needn’t mean lower burden | Several nested decisions | Long explicit straightforward steps | Bootstrap e48–50/P-0002 | | Nested code | Control flow inside deeper structures | Any indentation is bad | Trace decisions and exposed main action | Nesting itself sometimes serves logic | Set add checks | A flat opaque expression | Nested e12/P-0005 | | Guard clause | Protect exceptional paths by relinquishing control | Every early return | Identify predicate and remaining path contract | Return order can change priority | Reject null Set item | A success early return with overriding priority | P-0006 | | Primary action | Main task a block should expose | Last line is always primary | State behavior before reorganizing | A cosmetic label can omit side effects | Enroll and redirect | Discarded organization membership action | Big Blocks e1363/1793 | | Level | Contextual abstraction/readership expectation | Rigid architectural rank | Name caller, responsibility, dependencies | One reader isn’t all readers | Controller orchestration | Global detail relocation without contract | Big Blocks e237–251 | | Regroup | Separate and label action blocks temporarily | Permanent explanatory comments | Add labels in a temporary exercise | Labels can be mistaken for verified intent | Mark validation and enrollment | Guess intent from method name alone | P-0010 | | Native code | Existing language/framework/codebase capability | Always safest/latest dependency | Verify version, contract, and behavior | API existence isn’t equivalent behavior | Book’s request helper lookup | Outdated/mismatched helper | P-0011 | | Refactor | Restructure for readability in worked examples | Any cleanup or behavior change | Keep intended observable behavior unless declared change | Readability can hide rule change | Equivalent boolean return | Changed priority of scheduled check | Nested e147; P-0020 | | Duplication | Repeated implementation sometimes worth tolerating | Always identical responsibility | Trace why copies change together or apart | Text similarity isn’t shared domain meaning | Two similar evolving flows | Separate rules with shared spelling | P-0015/0017 | | Wrong abstraction | Premature shared design that hinders future growth | Any abstraction one dislikes | Name divergence/conditional pressure | No measured universal cost threshold | One helper grows mode parameters | Stable shared contract | P-0016; Rule e27–32 | | Rule of Three | Defer until pattern is understood | Refactor exactly at copy three | Use count as prompt to inspect needs | A count can replace judgment | Third use clarifies variability | Three occurrences of mandated shared invariant | P-0015/0017 | | DUN | Defer Until Necessary | Never design in advance | State decision deadline and risk | Waiting can itself impose cost | Shift postpones uncertain components | Known urgent defect cannot wait | Rule e32/58 | | Symmetry | Same idea expressed consistently, attributed Beck | Identical surface for every idea | Check whether meaning truly matches | Consistency can erase real distinction | Repeated naming pattern | Distinct concepts renamed alike | P-0019 | | Syntactic symmetry | Consistent formatting/operators/structure | Uniformity above language meaning | Preserve precedence and evaluation order | Equivalent appearance isn’t equivalent computation | Consistent braces | Replace operators without checking precedence | Symmetry e103–114 | | Semantic symmetry | Consistent names and tone | Synonyms always identical | Match vocabulary to domain distinctions | last/latest/previous may differ | On/off pair | Different historical meanings collapsed | Symmetry e119/481 | | Systemic symmetry | Consistent abstractions and patterns | One pattern everywhere | Justify pattern against local need | Reuse can impose wrong structure | Existing fitting pattern | Forced shared pattern with diverging responsibilities | Symmetry e139–141 | | Temporal dependency | Correct behavior depends on ordering | Helper extraction removes every dependency | Identify predicate prerequisites and priority | Hidden helper contract remains necessary | Check first run before dereferencing | Assume retries never overlap scheduling | P-0021/Symmetry e810–864 | **System language concerns:** readable and simple can carry aesthetic approval while masquerading as measurements. A level depends on the expected reader and application, not an objective school grade. DUN and symmetry can overexpand into universal mandates; P-0003/0005/0017/0023/0024 constrain that reading. Refactoring deserves a semantic criterion separate from readability, discussed in the external ledger. | Category risk | Status | Selected-route basis | | --- | --- | --- | | Correlation/causation | Present risk | One launched service doesn’t isolate deferral’s causal effect | | Individual/institution | Present risk | An author/team preference isn’t all programmer experience | | Description/prescription | Present, explicitly qualified | Worked examples become guidance; P-0003 calls it opinion | | Identity/behavior | Absent as inference here | No reader diagnosis or demographic coding ability assigned | | Intention/effect | Present risk | Readable intent doesn’t prove runtime effect | | Anecdote/population | Present | Twenty-year experience and one service aren’t population evidence | | Legal/moral/theological/historical confusion | Not applicable to core route | This is code-craft advice, not those adjudications | | Technical capability/outcome | Present | Existing helper doesn’t certify behavior or comprehension | | Absence/evidence of absence | Guarded | Unread bodies are NE; related Reader hits don’t prove target absence | ## Prompt 4 — Claims, dependencies, expectations, and falsifiers EA = explicit author claim; Q3P = quoted third party; RI = system inference; UI = unresolved interpretation. **RI claims aren’t author sentences and must never become source quotations.** Grade and scope judgments appear in Prompt 7. “Appears” describes only this selected route. | ID/source | Claim | Type/scope/testability | Expected evidence / appears | Falsifier or limit | Anchor/cluster | Question | | --- | --- | --- | --- | --- | --- | --- | | C-001 EA paraphrasing Beck | We read code more than we write it | Descriptive; programmers generally | Time-use/reading-task studies expected; author experience appears | Representative tasks show writing dominates the intended population | P-0001/Bootstrap e10 | Q01 | | C-002 EA | Readability and complexity need separate balance | Methodological/evaluative; guide goals | Conceptual distinction and examples appear | Unfalsifiable value as stated; cases where one metric fully captures both challenge separation | P-0002/Bootstrap e48–50 | Q02 | | C-003 EA | Rigid line/return limits can obstruct readability | Practical/evaluative; code decisions | Contrasting snippets appear; reader trials absent | Specified reader trials consistently favor rigid limits without meaningful countercost | P-0005/0009 | Q01/Q04 | | C-004 EA | A boolean-return conditional can become its condition | Technical; selected pure Set isEmpty example | Before/after exact predicate appears | Different result/side effect for supported input weakens equivalence | Nested e109/147 | Q08 | | C-005 EA | Any nested conditional can convert to guard clause | Technical/practical; broad wording | Selected examples appear; exhaustive side-effect proof absent | Guard variant skips required later work or changes return contract | P-0006/Nested e178/235 | Q04/Q08 | | C-006 EA | Recognize/regroup/refactor organizes a big-block review | Methodological; selected MVC examples | Complete worked stages and decision tree appear | Representative readers fail to identify actions or make more mistakes with process | Big Blocks e9–17/P-0010 | Q03/Q05 | | C-007 EA practice norm | Look for existing code before inventing an action | Methodological; language/framework/codebase lookup; empirical benefit unmeasured | Explicit lookup criterion appears; current API validation and lookup-cost outcome studies absent | Empirical falsifier N/A for the norm; reuse fit/version/cost limits application, not the act of looking | P-0011 | Q11 | | C-008 EA | Extraction/relocation can summarize actions at proper levels | Practical/evaluative; selected examples | Named helpers/model movement appear; full app contracts absent | Navigation or hidden coupling worsens specified tasks; behavior differs | P-0012/Big Blocks e902–905 | Q05/Q16 | | C-009 EA rhetorical analogy; UI/RI literal-conservation reading | Unless a native alternative exists, moving code relocates work; five removed lines are compared with five added elsewhere | Rhetorical/extraction warning; literal arithmetic interpretation requires a separate technical test | Source states the native-alternative exception and relocation warning; no general line-count proof | Literal UI/RI interpretation: equivalent syntax with fewer total lines defeats conservation; this does not refute the relocation warning | P-0014/Big Blocks e987/Nested e109/147 | Q02 | | C-010 RI — system inference assumption, not author sentence | Big Blocks helper snippets are executable as printed | Technical; selected e735/e913 only | Parser check required; two runs fail | A correct equivalent extraction of those exact printed characters parses | P-0013/Big Blocks e913 | Q07 | | C-011 EA with Q3P support | Deferring abstraction can reduce premature-design risk | Practical/causal; uncertain evolving requirements | Trade-offs and one service history appear; independent causal study absent | Controlled comparable cases show waiting increases wrong-abstraction cost in named setting | Rule e27–32/427–748 | Q06/Q12 | | C-012 EA | Three is a guide, not a required refactor count | Interpretive; Rule of Three meaning | Explicit boundary appears | Source elsewhere insists exact count regardless need would weaken coherent reading | P-0015/0017 | Q13 | | C-013 EA autobiographical | Shift launch/history demonstrates deferral worked for the author | Historical/interpretive; one codebase | Personal sequence and snapshots appear; independent history unread | Contemporaneous records contradict timing/design account | Rule e273/427/748/P-0018 | Q12 | | C-014 EA with Q3P definition | Symmetry helps readers through consistent ideas | Evaluative/causal; context-dependent readers | Definition and sample transformations appear; reader trials absent | Named reader tasks worsen despite preserved meaning and consistency | P-0019/Symmetry e3–4 | Q01/Q17 | | C-015 EA proposal | Group false-return checks before true-return checks | Practical; selected Check method | Native reordered example appears; preservation assumptions absent | If meant as refactor, a supported overlap changes result; readability value alone not empirically settled | P-0020/Symmetry e152/317 | Q15 | | C-016 RI — system inference, not author sentence | Native initial and reordered Check predicates can differ | Technical; isolated PHP 8.5.9 Boolean-stub domain | Executed 256 combinations; 26 differences | Same stated pure predicate model reproduces no differences, or source extraction is wrong | Symmetry e152/317; execution E04 | Q08/Q15 | | C-017 EA | Helper extraction makes order irrelevant | Technical; later retryUptimeCheck stage | Helper call shown; body and invariant absent | Helper dereferences absent last run or overlaps priority-changing predicates | P-0021/Symmetry e814/867 | Q16 | | C-018 RI — system inference, not author sentence | Native switch-to-strict-if check can differ for Boolean scope | Technical; isolated nonadmin PHP 8.5.9 model | Executed 7 inputs; true differs,3 named strings match | Same exact native predicates/stubs reproduce equal Boolean true output | Nested e355/551; execution E05 | Q08/Q10 | | C-019 EA strong belief and maintainability aspiration | McCreary firmly believes the ten practices together yield the most readable code and support approachable, easy-to-maintain code | Evaluative/predictive; whole-guide comparative belief; support scope broader than selected route | Exit e3 states the strong belief and e10 describes maintainability; six practice bodies and comparative/longitudinal outcomes NE | Measured readers or maintenance tasks showing practices do not outperform relevant alternatives would weaken the outcome belief; personal belief itself is not empirically refuted | Exit e3/10/P-0024 | Q09 | | C-020 RI — system inference, not author sentence | Validate behavior and reader experience separately | Methodological norm; transferred practice; empirical posterior N/A | Native probes and conceptual distinction motivate the proposal; no optimal-method study | Empirical falsifier N/A for this norm; a validated combined measure is an application alternative or limit, not a refutation | P-0002/0020/E04–E06 | Q07–09 | **System dependency reconstruction:** C-001 motivates reader priority; C-002/003 limit the metric. C-004/005 support local flow changes; C-006–008 supply the restructuring process. C-011/012 address uncertain abstraction timing; C-013 illustrates it without proving the counterfactual. C-014 supplies consistency; C-015/017 require semantic assumptions. C-016/018 show scoped failures of equivalence; C-010 exposes an example’s parser status. These don’t overturn C-006’s process or C-012’s boundary. C-019’s strong most-readable belief and maintainability aspiration need broader comparative and whole-guide evidence. C-007 is a looking-first norm, with reuse fit as an application boundary. C-020 is this system’s repair criterion, not McCreary’s quotation. ## Prompt 5 — Quantitative rigor setup **System policy:** use qualitative priors and updates. Don’t convert taste, craft values, autobiographical success, or a synthetic truth table into a population probability. The spec’s confidence bands of 0–20/21–40/41–60/61–75/76–90/91–100 percent are structured estimates, not measurements; none is assigned here. Definitions and methodological preferences get empirical posterior N/A. Test counts below are actual executions, not estimated beliefs. Preserve source dependence: McCreary’s passages remain one author witness, and repeated Beck/Fowler quotations aren’t replicated reader studies. | Claim | Prior | Evidence to examine | Likelihood impact | Posterior/range | Dependence | | --- | --- | --- | --- | --- | --- | | C-003 | Moderate | P4 anchors/P6 ledger | Pending P7 | Pending; no numeric range | One author plus scoped probes; no reader trials | | C-005 | Moderate | P4 anchors/P6 ledger | Pending P7 | Pending; no numeric range | One author plus scoped probes; no reader trials | | C-006 | Uncertain | P4 anchors/P6 ledger | Pending P7 | Pending; no numeric range | One author plus scoped probes; no reader trials | | C-009 | Moderate skepticism | P4 anchors/P6 ledger | Pending P7 | Pending; no numeric range | One author plus scoped probes; no reader trials | | C-011 | Uncertain | P4 anchors/P6 ledger | Pending P7 | Pending; no numeric range | One author plus scoped probes; no reader trials | | C-014 | Uncertain | P4 anchors/P6 ledger | Pending P7 | Pending; no numeric range | One author plus scoped probes; no reader trials | | C-016 | Moderate | P4 anchors/P6 ledger | Pending P7 | Pending; no numeric range | One author plus scoped probes; no reader trials | | C-020 | Methodological commitment | P4 anchors/P6 ledger | Pending P7 | Pending; no numeric range | One author plus scoped probes; no reader trials | | Calibration warning | Status/severity | Constraint | | --- | --- | --- | | False precision | High risk | No subjective numeric posteriors | | Repeated/dependent evidence | High | One service/testimony; repeated quotes count once | | Publication/survivorship bias | Medium/unresolved | Successful launch selected, failed comparisons unavailable | | Selection/tiny samples | High for reader claims | Author preference and worked examples don’t measure all readers | | Base rates/denominators | High | No frequency of maintenance outcomes supplied | | Proxy measures | High | Line counts and branch truth tables don’t measure readability | | Motivated judgment | Medium system risk | Error finding can dominate useful process | | p-values/effect sizes | Not applied | None used | | Statistical/practical significance | Not applied to probes | 26/256 is model domain count, not prevalence or risk | | Correlated test states | Applicable | Enumerated combinations share one stub model | Qualitative fallback: strongly/moderately increases, no meaningful update, or strongly/moderately decreases confidence, with the decisive input stated. A runnable excerpt doesn’t become more readable by passing tests; a preferred style doesn’t become correct by receiving agreement. ## Prompt 6 — Analytical scaffold and evidence ledger ### Complete cluster analyses **A — Bootstrap/Exit:** purpose is to set goals and craft posture. Thesis is reader-oriented code with less unnecessary complexity (C-001–003/019). Evidence is author history and attributed programming authorities. Terms are readability, complexity, craft. Counterexamples/concessions actually offered: simple can be unreadable, complex can be readable; practices are subjective; conventions vary by codebase and language; improvements take time. Assumption is that disciplined local practice aids future maintenance. Exit e3 firmly claims the ten practices together yield the most readable code; e10 aspires to approachable, easy-to-maintain code. These are stronger than mere stylistic preference, but they are not an unconditional longevity guarantee. Whole-guide and comparative outcomes remain NE. Unanswered is a measured comparison and maintenance outcome threshold. Relation to the spine: motivation and limits. Anchors P-0001–0004/0023–0024. Reader response unavailable. **B — Nested Code/Big Blocks:** purpose is to expose primary actions and place details at fitting levels (C-004–010). Evidence is all native before/after code, a decision tree, and the source’s reading-level analogy. Terms are guards, actions, levels, native reuse, extraction. Counterexamples/concessions actually offered: a short dense expression can be worse; many one-line methods add navigation; switches can be good enough; higher-order functions needn’t help every reader; an action can stay in place. No exhaustive counterexample analysis of changed types, branch priority, or full helper implementations is offered in these selected chapters; that statement is scoped to them. Assumptions are compatible contracts and readers’ context. Unanswered: parser/call-site/runtime checks and reader tasks. Anchors P-0005–0014. Reader response unavailable. **C — Rule of Three/Symmetry:** purpose is to time design and present established ideas consistently (C-011–018). Evidence is a personal Shift progression, numerical-series analogy, attributed craft quotes, and a Check refactor. Counterexamples/concessions actually offered: duplication has maintenance pain; abstraction can be wrong; three isn’t literal; the Tasks design retains limits; symmetry varies; the refactor stops at a sufficient level. No actual controlled reader comparison is offered on this route. Assumptions include safe predicate order, helper behavior, and domain vocabulary equivalence. Unanswered: actual state invariants, latency of design decisions, and maintenance outcomes. Anchors P-0015–0022. Reader response unavailable. **System argument spine:** prioritize readers → separate readability from size → name actions and context → choose reuse/extraction/relocation → defer uncertain shared design → align expression for genuinely shared meaning. **Weakest bridge:** moving from visibly smoother code to behavior-preserving or universally better code. Repair with explicit domain contracts, targeted semantic checks, and actual reader-task evaluation. The independent bridge from delayed abstraction to better future outcomes remains untested even if every snippet compiles. | Evidence | Claims | Type/source | Independence | Quality/limits | Anchors | | --- | --- | --- | --- | --- | --- | | E01 | 001–009/014/019 | Native guide and complete selected examples | One author, sources named but originals mostly unread | Direct source attribution; no independent reader outcomes | P-0001–0014/0019/0023–0024 | | E02 | 011–013 | Shift snapshots and narrative | One author-controlled service history | Specific chronology; no counterfactual or independent records | Rule of Three full | | E03 | 012/014 | Roberts/Fowler,Metz,Beck quotations | Attributed third parties; native repeats not independent verification | Conceptual provenance; quoted original talks/books unread | P-0015–0019 | | E04 | 015/016 | Native-derived Check order probe | System execution, independent of author outcome judgment | 256 pure stub states; 26 differences; actual state reachability unknown | Symmetry e152/317 | | E05 | 018 | Native-derived check scope probe + official PHP docs | System execution and one primary language reference | 7 inputs; Boolean true differs; sourcecaller constraints unknown | Nested e355/551 | | E06 | 010 | Parser checks of2 native helper excerpts | System execution | Both exit 255; line numbers stripped/wraps joined; no source repairs | Big Blocks e735/913 | | E07 | 011/020 | Primary Metz essay and Fowler definition | Two independent practitioner texts, no controlled studies | Context/definition checks, not empirical outcome replication | External checks below | ### Actual bounded checks and transformation limits **Executed E04:** isolate the native `Check::needsToRun` predicates from `OEBPS/chap10.xhtml`, body elements **152 and 317**. Count the body as 0; quoted prose P-0020 is element 312, not the code block. Strip printed line numbers, join explicit EPUB backslash-newline wraps, and rename only classes for comparison. Stub subscription, enabled status, uptime type, last-run presence/failure, crash, scheduling, and elapsed status as eight Boolean inputs. PHP **8.5.9** executes all 256 combinations; 26 produce different return values. For active subscription, enabled check, uptime type, failed existing last run, no crash, scheduled/running=true, elapsed=false: the initial order returns true; the grouped-false-first order returns false. **Scope:** that is a reproducible difference in a specified pure model, not a claim 26 states occur equally often, nor a finding of an Oh Dear! production bug. Actual application invariants might exclude the overlap. Neither original service behavior nor the 2019 runtime is reproduced. Reordering could intentionally fix a rule; if so, call it a behavior change and justify it. A style improvement alone doesn’t establish that intent. **Executed E05:** isolate Nested Code’s initial `check` at body e355 and final version at e551, with a nonadmin stub user ID 42 and requested owner 7. Run public/private/other strings, true, false, null, and 0. The three named strings match; Boolean true yields initial=true/final=false. The [official PHP switch reference](https://www.php.net/manual/en/control-structures.switch.php) states that cases use loose comparison. Only its language reference section is read; user contributed notes aren’t used. This current reference and the actual PHP 8.5.9 execution explain the specified boundary, not all historical coercion rules. If callers guarantee the named string domain, this counterexample may be unreachable. No authentication vulnerability or live application failure is claimed. **Executed E06:** normalize only display numbering/wrapping, place Big Blocks e735 and e913 inside a class for syntax checking, and run the native helper text through the parser. Both checks exit 255 with an unmatched `[` against `)`. P-0013 shows the exact source line; the native e913 repeats the same defect. It’s a source example typo, not a finding about every example. No snippet is silently repaired and then called original. A corrected array bracket would be a declared repair and still wouldn’t certify method calls, helper contracts, or app behavior. **Non-executed source limits:** Rule of Three’s final script at `OEBPS/chap09.xhtml`, body element 433, shows `$shift->getType()` before visible creation, uses `$task` inside `foreach ($tasks as $class)`, and includes a `$gitClient` expression. The surrounding omitted context isn’t supplied. These are source-excerpt questions, not reproduced application failures or security findings. No repair or shell/network execution occurs. No Shift commands, repositories, external services, framework installation, deployment, or data-writing example runs. These are parser and pure predicate checks in temporary storage. The source includes service/shell commands, but reading them doesn’t authorize executing them. Probe transformations and outputs remain in the audit cache until root finalization. **External scope:** [Fowler’s refactoring definition](https://refactoring.com/) explicitly treats refactoring as preserving observable behavior. Its definition and overview are read; the full linked book/catalog aren’t. That criterion supports this system’s semantic distinction, not a measured readability result. [Metz’s January 20, 2016 essay](https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction) is read in full: it describes shared code accumulating conditional variation and proposes restoring caller-specific code before finding a fitting abstraction. It’s independent practitioner context for deferral and repair, not a controlled cost comparison, and isn’t the linked native talk itself. **Independence count:** E04/E05/E06 are three executable probe families, not three population studies. E07 supplies two independent practitioner texts; E05 adds one official language reference. E01/E02 remain author-controlled evidence. No independent controlled reader outcome study is read. Executed evidence tells against unrestricted preservation assumptions in two selected sequences and against printed executability in two selected helper blocks; it doesn’t refute the whole guide. **Completed reading plan:** motivation → Nested Code/Big Blocks and their full examples/images → Rule of Three/Symmetry and all code → Exit → bounded semantic/parser checks. **Next plan:** read the six omitted practices in full before a whole-guide judgment; inspect actual callers/helper bodies and the appropriate historical/current runtime before application claims; seek reader task evidence for comprehension. High attention goes to types, branch priority, side effects, and names. Completion criteria for Prompt 7 are met: full route/apparatus read, native quotes verified, priors seeded, tests run with scope stated. Original cited books and actual service invariants remain NE. ## Prompt 7 — X-ray analysis and fair criticism **Strongest reconstruction — system inference:** the guide offers adaptable craft practices that help you discuss code intent and future change. It doesn’t need a universal line count, exact duplication threshold, or one correct style. Its own trade-offs and subjectivity statements support that reading. The technical examples still need semantic conditions; declaring an opinion doesn’t make a before/after behavior difference disappear. | Claim | Source claim | Support/grade reason | Grade | Strongest objection | Countercase/concession | System verdict | | --- | --- | --- | --- | --- | --- | --- | | C-001 | We read code more than we write it | Observed craft rationale, no quantified denominator | C | Work differs by task/person | New isolated prototypes may be writing-heavy | Use motivation, no universal measured rate | | C-002 | Readability and complexity need separate balance | Source distinguishes simple/unreadable and complex/readable | N/A | No operational measurement supplied | Short dense expression can be simple but obscure | Retain two criteria, define reader/task | | C-003 | Rigid line/return limits can obstruct readability | Concrete contrasts and author caveat | C | Preference isn’t measured comprehension | One-line functions can impose navigation | Thresholds prompt review, not verdict | | C-004 | A boolean-return conditional can become its condition | Same size comparison, true/false result | B | Doesn’t generalize to arbitrary branch actions | Ternary for other values can retain complexity | Supported narrow transformation, readability separate | | C-005 | Any nested conditional can convert to guard clause | Works for simple selected path structure | D | “Any” needs continuation/cleanup contract | Remaining work after conditional can require different flow | Repair to qualifying paths and preserved continuation | | C-006 | Recognize/regroup/refactor organizes a big-block review | Two worked progressions expose actions | C | No independent outcome comparison | Controller’s expected level varies by task | Useful review scaffold, outcome unmeasured | | C-007 | Look for existing code before inventing an action | Source gives a concrete lookup practice | N/A | Search can cost time; no measured optimal budget | An existing candidate can fail the required contract | Retain looking first as a proposed norm; reuse only after contract/version check | | C-008 | Extraction/relocation can summarize actions at proper levels | Source groups meaningful actions | C | Caller/side effects omitted from excerpts | Method relocated can add behavior to more callers | Useful conditional design, preserve contracts | | C-009 | Unless a native alternative exists, moving code relocates work; five removed lines are compared with five added elsewhere | Source warning helps trace hidden work; native exception remains explicit | D | D applies to literal UI/RI arithmetic, not a claimed author software axiom | Native isEmpty reduces seven display lines to three; whether that qualifies as a native alternative limits this countercase | Retain relocation warning and exception; do not treat exact line conservation as established | | C-010 | Big Blocks helper snippets are executable as printed | Both native-normalized excerpts fail parser | F | Display normalization must be disclosed | No claim every other snippet fails | Do not paste these unchanged; source typo verified | | C-011 | Deferring abstraction can reduce premature-design risk | Timing gives information; source describes alternatives | C | Deferral also has maintenance risk | Known stable invariant may justify early sharing | Condition deferral on uncertainty and delay cost | | C-012 | Three is a guide, not a required refactor count | Author rejects a hard three-count rule | N/A | Counting alone can still tempt misuse | A known defect shouldn’t await three copies | Retain nonliteral heuristic | | C-013 | Shift launch/history demonstrates deferral worked for the author | Specific progression and admission of later limitations | C | Success selected by survivor; no counterfactual launch | Author says later task pipeline still has limits | One author account, no causal/general benchmark | | C-014 | Symmetry helps readers through consistent ideas | Provides consistent vocabulary/levels | C | Different meanings shouldn’t be homogenized | Source acknowledges variation across teams/time | Conditional reading practice, not universal score | | C-015 | Group false-return checks before true-return checks | Surface ordering becomes consistent | D | Early return defines precedence, not just style | Failed uptime and scheduled can coexist in synthetic state | Treat as rule change unless invariant proves equivalence | | C-016 | Native initial and reordered Check predicates can differ | Direct native-derived predicate execution, reproducible scoped result | A | Actual service state reachability is unknown | Many tested combinations match | Conditional equivalence failure, no production bug claim | | C-017 | Helper extraction makes order irrelevant | Intent readable through a name | D | Naming doesn’t prove helper contract | Safe helper could validate internally; body absent | Require helper/null/state contract; not evaluated implementation | | C-018 | Native switch-to-strict-if check can differ for Boolean scope | Direct comparison plus officialswitchdocs | A | Caller may constrain scope to strings; unknown | public/private/other strings match | Conditional type-boundary difference, not actualauth vulnerability | | C-019 | McCreary firmly believes the ten practices together yield the most readable code and support approachable, easy-to-maintain code | Author states a strong craft belief grounded in examples and his experience | C | Selected examples do not establish most-readable comparison or whole-guide maintenance outcomes | Author also rejects hard rules and acknowledges context variation | Retain the strong belief as attributed; practitioner support only, broad outcomes NE; no unconditional longevity guarantee attributed | | C-020 | Validate behavior and reader experience separately | Independent criteria avoid aesthetic certification | N/A | No measured optimal workflow or cost-benefit result | A validated combined measure could serve both criteria in a stated task | Proposed norm only; no empirical posterior or personal implementation | **Grade distribution:** A=2, B=1, C=8, D=4, F=1, N/A=4. All 20 inventory claims have one verdict. A belongs to tightly scoped system execution findings, not universal author claims. B belongs to a narrow visible Boolean equivalence. C describes practitioner support without general reader/maintenance outcomes. D marks overbroad transformation bridges and the literal UI/RI interpretation of line conservation. F applies only to the tested printed-executability assumption for two blocks; it isn’t a rating of the book or author. N/A keeps values/definitions/method rules outside fabricated probabilities. | Claim | Prior | Decisive evidence | Qualitative update | Dependence/range | | --- | --- | --- | --- | --- | | C-003 | Moderate | P-0005/0009 contrasting forms | Moderate increase as review heuristic | No measured reader benefit | | C-005 | Moderate | Full guard examples plus continuation condition | Narrow claim retained; broad “any” decreases | Preservation needs domain/path conditions | | C-006 | Uncertain | Two worked progressions +native image | Moderate increase as scaffold | Same author examples, no reader trial | | C-009 | Moderate skepticism | Native isEmpty 7→3 display lines | Decrease in literal arithmetic interpretation; relocation warning retained | Same predicate, fewer lines; native-alternative exception limits countercase | | C-011 | Uncertain | Shift account/Metz trade-off context | Moderate increase in conditional rationale | No independent counterfactual; delay also costs | | C-014 | Uncertain | Full symmetry examples, acknowledged variation | No meaningful universal update | Consistency benefit remains reader dependent | | C-016 | Moderate | E04actual26 differences | Strong increase within specified stub domain | Actual production reachability unknown | | C-020 | Methodological commitment | E04–E06/Fowler criterion | Clarified proposed rule; empirical posterior N/A | Testing isn’t a readability measure | No numerical posterior or confidence range is assigned. The strongest updates come from actual execution of a narrow model; confidence in a national or industry-wide outcome can’t inherit that strength. ### Repairs, biases, and author concessions **System finding — equivalence error under stated conditions:** C-015’s reordered returns alter output for overlapping predicates in E04. Repair: document a domain invariant excluding the overlap, preserve original precedence, or declare and test an intended rule change. This remains faithful to readable code as a goal but costs the suggestion that return grouping is a cosmetic improvement. Don’t label a real service bug without its reachable states. **System finding — type-boundary limitation:** C-018 traces loose-switch versus strict-if behavior in E05. Repair: constrain/validate input to the intended strings or preserve comparisons deliberately. Whether stronger typing improves application behavior is a different decision. It’s a system correction to an unqualified example reading, not a quote attributed to McCreary. **System finding — source syntax defect:** C-010’s unchanged native helpers don’t parse after disclosed display normalization. Repair the bracket explicitly for a teaching exercise, then verify remaining method-call and application contracts. The repaired result is a new exercise, not a certified source snippet. Don’t use a typo to dismiss the entire process C-006. **System interpretation — line analogy:** Big Blocks e987 begins with the exception “Unless we find a native alternative” and warns that extraction relocates work. C-009 distinguishes that author rhetoric from a UI/RI interpretation as exact line conservation. The earlier isEmpty example reduces seven display lines to three; whether that counts as a native alternative affects the countercase. Exact line conservation still lacks a general proof. System repair: trace relocated responsibilities and dependencies, retain the exception, and avoid treating the analogy as a software axiom. **System finding — generalization risk:** C-013’s launch account and C-019’s strong most-readable belief and maintainability aspiration don’t identify alternative outcomes or a measured effect. Repairs: deferral helps when uncertainty and future information exceed delay costs; consistency is a candidate comprehension aid for named readers. These are conditional system formulations. They cost certainty, not the value of the field guide’s questions. **Rhetorical weaknesses, not proved universal fallacies:** the numerical-series consensus illustrates increased information, but a finite sequence doesn’t uniquely determine an abstraction; the author explicitly allows other mathematical continuations. The school-reading-level analogy describes expectations without establishing one rank for all code readers. The code-review cartoon encourages attention to confusion but isn’t a validated metric. Treating them as aids instead of proofs avoids overreading. **Counter-observations in the author’s favor:** P-0003 calls the practices subjective; P-0005 and P-0017 reject hard rules; P-0007 acknowledges trade-offs; P-0008 says higher-order code needn’t help every reader; P-0018 admits remaining Shift design limits; P-0022 stops at sufficient symmetry instead of perfection; P-0023 says practices vary by codebase/language. These concessions constrain an accusation that McCreary blindly advocates one style. They don’t supply missing execution or reader-task evidence. **System conclusion:** retain the action/context vocabulary and conditional deferral, while checking semantic behavior and actual readership separately. Whole-guide completeness, service state reachability, original historical execution, and long-term maintenance effects remain unknown or NE. No Courtney opinion is inferred. ## Prompt 8 — Systems, context, and lineage **Source context:** the 2019 Leanpub version describes PHP/Laravel-flavored web code and practitioner learning across twenty years. Its native citations name Beck, Pike, Fowler/Roberts, and Metz. A native citation documents attribution; it doesn’t prove this review reads their books or talks. The source’s Shift history connects launch timing to design decisions, while the Oh Dear! example connects consistency to a website-check method. Current service offerings aren’t derived from these excerpts. **System incentives/context reconstruction:** a solo practitioner facing a release deadline may value launching before building reusable structure; teams maintaining many callers may value shared invariants earlier. Readability mediates those costs only when you identify the readers, tasks, and change patterns. The current local PHP 8.5.9 result adds an execution context after this file’s version date; it isn’t backdated to 2019. **Lineage:** the native guide cites implementation patterns, refactoring craft, and skepticism of premature abstraction. Metz’s separately read 2016 essay corroborates an earlier practitioner context for wrong abstraction; it doesn’t replicate McCreary’s business result. Fowler’s current overview supplies a semantic definition, not new evidence that all modern tools preserve behavior automatically. **Competing interpretations — system inference:** a craft reading favors adaptable heuristics; an empirical reading demands observed reader outcomes; a verification reading demands preservation contracts. These are complementary questions, not proof one professional culture should dominate all code. ## Prompt 9 — DEIB, multicultural applicability, access, and reading level **Source strengths:** McCreary names reader differences, acknowledges subjective judgment, and gives concrete steps instead of only status-based slogans. His invitation to challenge a practice (P-0004) supports review agency. The selected route doesn’t specify institutional representation or procedural safeguards for minority voices in a team, so those aren’t counted as established structural inclusion. **System risks and missing perspectives:** the author’s paired-work and service examples don’t establish whose reading preferences prevail across teams. The peer anecdote in Bootstrap includes an experience-based dismissal before later agreement; that sequence shouldn’t teach you to discount a junior reader’s present difficulty. Native visual metaphors center visual scanning. They don’t show how someone using a screen reader navigates extracted methods. No diagnosis, demographic skill inference, or disability-as-deficit claim follows from that gap. | Context | System transfer possibility | Limit/adaptation | | --- | --- | --- | | Different languages | Action/context/uncertainty questions | Check that language’s evaluation/type rules | | Multilingual teams | Consistent shared domain vocabulary | English fluency doesn’t establish conceptual skill | | Novice readers | Concrete before/after and explicit paths | Define MVC, methods, helper calls and types | | Screen-reader/nonvisual workflows | Method structure can support navigation | Measure actual traversal, not indentation alone | | Distributed teams | Document intended contracts and naming choices | Local preference shouldn’t silence differing tasks | **System accessibility audit:** prose is conversational, but code assumes objects, static helpers, request/response flow, and typed/loose comparisons. Define those prerequisites at the point of use. Provide plain text code with stable labels, spoken or written reasoning options, and a prose equivalent for diagrams. Don’t require rapid visual scanning or public performance. Reading paid linked books or running a framework introduces time and access costs; the review’s pure examples avoid requiring a paid service or a live repository. **System reading-level estimate:** intermediate programming reader, based on observed references and code instead of a grade-level formula. Syntax is easier than the dense call-graph and domain assumptions. Beginners can follow the prose and still miss an evaluation-order change. Suggested supplementary perspectives: original human-comprehension studies, maintainers using assistive navigation, readers from other languages, and actual application-domain reviewers. These aren’t sources read or invented participant responses. ## Prompt 10 — Notes pipeline inside one note **System fleeting notes:** Can the real Check state combine scheduled/running with failed uptime? Does the controller caller guarantee string scopes? What does each new helper guarantee about null and side effects? Which decisions gain information from waiting? These remain questions, not asserted answers. ### LN-01 — Readable ordering has semantic conditions **Literature note:** Symmetry proposes grouping false checks before true checks (P-0020); native code e152/e317 plus E04 show a conditional priority difference. The source doesn’t provide the application invariant needed to exclude it. Link [[#PN-01 — Preserve priority before improving presentation]]. #### PN-01 — Preserve priority before improving presentation **System permanent-note candidate, not the author’s sentence.** Before grouping or reordering early returns, identify overlapping predicates and their intended priority. Compare behavior on the supported domain; if the rule changes, state that choice. **Confidence:** high within the executed pure model, broader application conditional. **Scope and conditions:** first-satisfied-branch flows; real invariants and side effects require separate evidence. Don’t imply that every reorder is unsafe. Support/reciprocal link [[#LN-01 — Readable ordering has semantic conditions]]. ### LN-02 — Duplication can buy information **Literature note:** Rule of Three describes maintenance pain alongside premature-design pain and rejects a literal three-copy count (P-0015–0018). Its personal service history supports a situated rationale, not a universal schedule. Link [[#PN-02 — State the information gained by waiting]]. #### PN-02 — State the information gained by waiting **System permanent-note candidate, not the author’s sentence.** Delay a shared abstraction when another use is likely to reveal meaningful variation; state what you expect to learn and what duplicated maintenance costs you accept. **Confidence:** moderate as a conditional planning rule; empirical effect size unknown. **Scope and conditions:** reversible design choices under uncertainty; known invariants, urgent defects, and synchronized obligations can justify earlier action. Support/reciprocal link [[#LN-02 — Duplication can buy information]]. ### LN-03 — A shorter caller can hide unchanged work **Literature note:** Big Blocks groups actions and moves details to helpers/other levels (P-0010–0012), then uses a line-conservation analogy (P-0014). Its native-alternative exception and relocation warning prompt you to inspect where responsibility goes; literal syntax conservation is a separate UI/RI interpretation, not an established author axiom. Link [[#PN-03 — Measure the reader’s whole path]]. #### PN-03 — Measure the reader’s whole path **System permanent-note candidate, not the author’s sentence.** Assess comprehension across the caller and necessary helpers instead of counting the caller’s lines alone. A named action can reduce repeated detail while adding navigation or concealing contracts. **Confidence:** moderate as an audit criterion, reader outcomes unmeasured. **Scope and conditions:** extraction/refactor reviews with a named task and reader; don’t assume short or long code wins. Support/reciprocal link [[#LN-03 — A shorter caller can hide unchanged work]]. **Structure candidate and adjacency:** the internal claim ledger, execution ledger, LN↔PN pairs, and maps provide a content map without another file. A targeted filename check for exact title/author and local Readwise matches finds no related BaseCode note. This isn’t a whole-vault MOC census. No external reciprocal link or MOC edit is claimed. Suggested future atomic filenames match PN-01–03, but the user’s one-note scope retains them here. **Do not attribute to McCreary:** C-010/016/018/020; all PN candidates, reconstructed priors and posterior judgments, probe results, causal repairs, accessibility inferences, lesson/experiment designs, diagram edges marked system, and external comparisons. Roberts/Fowler, Metz, and Beck retain quoted attribution. No original cited book/talk is treated as fully read; native exact excerpts remain separate from normalized probe code. Nothing represents Courtney’s personal reflection. ## Prompt 11 — Teaching pack **System-designed audience/objectives:** programmers who can follow Boolean conditions and want to evaluate a refactor. Learn to describe a primary action, trace first-return priority, state a supported input domain, distinguish a readable name from a helper contract, and identify what information deferral might gain. Prerequisites: true/false, short-circuit flow, method call, and a return that ends a method. Introduce these through one complete example before vocabulary lists. **Illustrative complete example:** a fictional job runner has an enabled flag, an urgent retry flag, and an already-scheduled flag. Initial rule: if disabled, return false; if urgent retry, return true; if already scheduled, return false; otherwise follow elapsed-time rule. For enabled=true, urgent=true, scheduled=true, it returns true. Grouping all false checks first returns false for that same state. The mechanism is first-return priority, not a disagreement about indentation. If the domain promises urgent and scheduled never coexist, write that promise and check it. This is a synthetic teaching example based on E04, not a live service or a claim a learner has answered it. **Lesson design, 30 minutes:** use5minutes to trace that complete case;10minutes to trace two additional states and decide which overlap matters;10minutes to label a synthetic large block’s actions and decide whether to leave/extract/relocate;5minutes to state one domain assumption and one observation that would overturn it. Learners choose written, spoken, or assistive communication. Times describe an optional design, not a delivered class or attention diagnosis. **Discussion and misconception checks:** Does consistent surface order preserve priority? Does passing a parser certify runtime behavior? Does a helper name prove its implementation? Does a third copy force sharing? Expected reasoning distinguishes syntax, behavior, reader comprehension, and design timing. Don’t supply agreement with a style as proof of learning. Assessment: annotate an unfamiliar synthetic pair with a domain, counterexample or proof obligation, and reader-task question. Reflection: what did you need to assume, and what would you inspect next? No participant response is fabricated. **Facilitator cautions:** disclose six unread practices, current-runtime scope, and unknown production reachability. Don’t teach a literal UI/RI line-conservation reading, unconditional deferral, or a safe-reordering implication as settled. Preserve the author’s native-alternative exception and strong but unmeasured most-readable belief. The numerical sequence demonstrates uncertainty; it doesn’t establish a unique future requirement. The school-grade analogy describes expectations, not programmer rank. Offer labels and prose for people who don’t scan diagrams, private responses, and time to trace calls. Fictional reviewers have equal agency to challenge assumptions; no demographic identity represents expertise or confusion. Text-only examples don’t assign diagnoses, change documented real identities, or claim an illustrated representation outcome. Further reading: the omitted practices, actual application contracts, original comprehension research, and language-specific references at use; not completed here. ## Prompt 12 — Proposed actions, PARA, experiments, and drift **System proposals only; none adopted by Courtney or applied to a real repository.** Consider naming the reader/task before style changes, marking overlaps before return reordering, and stating what information another use might reveal before abstracting. Avoid pasting native snippets unchanged or using a passing test as a readability certificate. **Most likely misuse:** enforcing symmetry or a duplication count as a universal rule, then moving or deleting code without preserving its contract. **PARA:** Archives holds this selected-route review. Resources could later hold the PN concepts if authorized; no atomic files are created. An Area could use an existing code-review practice if the reader chooses it. No Project is created because no implementation goal is supplied. No routing edit, task enrollment, or scheduled monitoring occurs. | Inactive experiment | Related claim | Hypothesis | Reversible action | Measure | Duration | Stop condition | Review | | --- | --- | --- | --- | --- | --- | --- | --- | | Priority trace | C-020/PN-01 | Naming overlaps exposes behavior change | Trace 4 synthetic states on paper, no repository | Correct expected outputs plus explicit domain assumption | One 15-minute session | Stop if live authorization/data becomes involved | At session end, date unscheduled | | Information log | C-011/PN-02 | A named unknown improves abstraction timing reasoning | Write two fictional use cases and defer a pretend helper decision | Which new fact changes the design? cost of waiting named? | One 20-minute session | Stop if rule becomes automatic three-copy threshold | At session end | | Reader path | C-006/PN-03 | Whole path measure exposes extraction cost | Compare two synthetic versions privately | Call sites visited, action correctly explained, assumptions listed | One 20-minute session | Stop if it becomes a covert study or real code mutation | At session end | **System decision rules:** adopt a practice only after it exposes a real assumption or supports the named task; adapt if it adds navigation or suppresses meaningful differences; reject a blanket style rule when it changes supported behavior without an intended rule decision; defer when callers or contracts are missing. Revise PN-01 if it becomes “never reorder,” PN-02 if it becomes “always wait,” and PN-03 if it becomes another line-count rule. These proposed experiments transfer analysis practices, not source-author service efficacy. They aren’t the already-executed E04–E06 probes. **Drift plan, inactive:** before an actual code change, read the project’s supported language/framework versions and current primary documentation for the specific API; inspect tests, callers, and invariants. Reassess when versions or domain rules change, not on a fictional recurring schedule. For a reader-outcome claim, consult independent task evidence at use and after a team or access need changes. Conceptual review could occur within one year if you adopt the practice; no date or reminder is scheduled. Native wording, version date, source hash, and scoped recorded probe outputs stay fixed; their interpretation and applicability can change. ## Prompt 13 — Visual thinking pack The full visual-learning-supports brief is read before these supports. Permitted palette: Russian violet #241c4a; periwinkle #bcb5e3; glaucous #647baf; sky blue #8ecae6; blue-green #219ebc; cerulean #126782; Prussian blue #023047; selective yellow #ffb703; UT orange #fb8500; light orange #fee2c3; light gray #ebebeb. Maps explicitly set the base theme, pale background/edge-label fills, dark edge/text colors, and node palette. Labels and dashed edges carry meaning without color alone. Code and prose correspondences are inspected; rendered legibility is unverified. No live Obsidian or diagram rendering is claimed. Concepts use sky blue, proposed steps light orange, context/uncertainty periwinkle, and thesis a blue-green outline. All 11 colors needn’t appear in each map. No people appear, so no diagnosis, identity, assistive technology, or cultural depiction is invented. Source-native images are preserved as inspected evidence, not repainted to imply changed source content. ### Map 1 — Selected book route **Purpose/layout:** top-to-bottom actual reading order and side gap. **Nodes/groups:** goals, local restructuring, timing/consistency, conclusion; six unread bodies. **Sources:** C-002/006/011/014/019; P-0002/0010/0017/0019/0024. **Uncertainty:** dashed unread node supplies no missing findings. ```mermaid %%{init: {"theme":"base","themeVariables":{"background":"#ebebeb","primaryColor":"#8ecae6","primaryTextColor":"#241c4a","primaryBorderColor":"#126782","lineColor":"#023047","textColor":"#241c4a","edgeLabelBackground":"#ebebeb","secondaryColor":"#fee2c3","tertiaryColor":"#bcb5e3"}}}%% flowchart TD A["Bootstrap: full"] --> B["Nested Code + Big Blocks: full"] B --> C["Rule of Three + Symmetry: full"] C --> D["Exit: full"] B -. "coverage gap" .-> U["Other 6 practice bodies: NE"] classDef read fill:#ebebeb,stroke:#219ebc,color:#241c4a classDef gap fill:#bcb5e3,stroke:#023047,color:#241c4a,stroke-dasharray:5 5 class A,B,C,D read class U gap ``` **Complete prose equivalent:** read Bootstrap’s goals, then all Nested Code and Big Blocks, then all Rule of Three and Symmetry, and finally Exit. All selected code and native apparatus are included. Formatting, Dead Code, Using Objects, Naming, Removing Comments, and Reasonable Returns bodies remain NE. Their titles in the contents don’t turn into evaluations. ### Map 2 — Author process plus system preservation condition **Purpose/layout:** left-to-right author three-step process, decision split, with a clearly labeled system verification condition below. **Nodes:** recognize level, regroup actions, native capability, level fit, leave/extract/move, test contract. **Sources:** C-006–008/020; P-0010–0012; native decision tree. **Uncertainty:** dashed verification link is the system’s repair, not an extra author step. ```mermaid %%{init: {"theme":"base","themeVariables":{"background":"#ebebeb","primaryColor":"#8ecae6","primaryTextColor":"#241c4a","primaryBorderColor":"#126782","lineColor":"#023047","textColor":"#241c4a","edgeLabelBackground":"#ebebeb","secondaryColor":"#fee2c3","tertiaryColor":"#bcb5e3"}}}%% flowchart LR L["Author: recognize level"] --> G["Regroup actions"] G --> N{"Native implementation fits?"} N -->|yes| R["Consider reuse"] N -->|no| F{"Fits current level?"} F -->|yes| S["Leave or extract"] F -->|no| M["Move to fitting level"] R -. "system condition" .-> V["Preserve contract + assess reader task"] S -. "system condition" .-> V M -. "system condition" .-> V classDef concept fill:#8ecae6,stroke:#126782,color:#241c4a classDef step fill:#fee2c3,stroke:#fb8500,color:#241c4a classDef uncertainty fill:#bcb5e3,stroke:#023047,color:#241c4a,stroke-dasharray:5 5 class L,G,N,F concept class R,S,M step class V uncertainty ``` **Complete prose equivalent:** the author asks you to identify the code’s level, regroup its actions, and look for an existing native implementation. If one fits, consider reuse; otherwise ask whether the action fits the current level. If it does, leave it or extract locally; if it doesn’t, move it. The review adds a separate system condition to every option: preserve the supported contract and assess the named reader task. API existence alone doesn’t satisfy the fit question or prove this condition. ### Map 3 — Priority as a counterexample boundary **Purpose/layout:** two parallel paths from one synthetic state. **Nodes:** enabled/failed-uptime/scheduled, original priority, grouped priority, differing results, real invariant unknown. **Sources:** C-015/016/020; P-0020; native e152/317 and E04. **Uncertainty:** actual service reachability remains a warning box; no production bug node. ```mermaid %%{init: {"theme":"base","themeVariables":{"background":"#ebebeb","primaryColor":"#8ecae6","primaryTextColor":"#241c4a","primaryBorderColor":"#126782","lineColor":"#023047","textColor":"#241c4a","edgeLabelBackground":"#ebebeb","secondaryColor":"#fee2c3","tertiaryColor":"#bcb5e3"}}}%% flowchart TD S["Synthetic: enabled + failed uptime + scheduled"] --> O["Initial: retry before scheduling guard"] S --> G["Grouped: scheduling guard before retry"] O --> T["returns true"] G --> F["returns false"] T --> D["Behavior differs in this model"] F --> D D -. "not established" .-> U["Actual service state reachability: unknown"] classDef concept fill:#8ecae6,stroke:#126782,color:#241c4a classDef result fill:#fee2c3,stroke:#fb8500,color:#241c4a classDef uncertainty fill:#bcb5e3,stroke:#023047,color:#241c4a,stroke-dasharray:5 5 class S,O,G concept class T,F,D result class U uncertainty ``` **Complete prose equivalent:** the specified synthetic state has an active subscription and an enabled uptime check with an existing failed last run and scheduled/running status. Under the initial method, retry returns true before the scheduling guard is reached. Under the reordered method, scheduling returns false first. The methods therefore differ in this model. Whether that state is reachable in the real application remains unknown; the diagram proves no service bug or prevalence estimate. A documented invariant or intentional business-rule change determines the next assessment. **Idea Compass — system navigation candidates:** Parents: code-reading and behavior-preserving restructuring; Children: priority contracts, abstraction timing, whole-reader paths (PN-01–03); Friends: reader-task evaluation, source tracing, domain vocabulary; Competitors: rigid line thresholds, universal DRY, pattern choice by surface consistency. These are categories and internal links, not invented existing MOCs or asserted causal lineages. **Omitted visuals:** no quantitative causal loop because effect sizes aren’t established; no whole-guide argument map because six practice bodies are unread; no comprehensive stakeholder map because participation evidence is absent; no service-history timeline presented as independent record. The glossary is the concept/comparison table; P6 is the evidence map in table form; Map 2 is the decision/action map. Source code-review cartoon and decision tree have prose descriptions in P0. No external graphic file is created. ### Session completion and prompt record Prompts 0–13 execute in order; each produces usable output on the declared selected route. None is skipped and no next prompt remains. Prompt 0 uses native Layer 1 and a bounded Reader gap; Prompt 5 uses qualitative confidence without fake probabilities; Prompt 10 retains 3 reciprocal LN↔PN pairs inside this note; Prompt 13 supplies 3 maps with complete prose. These are authorized adaptations, not hidden omissions. Missing evidence ranked by consequence: actual caller/input and service-state contracts for production equivalence; full helper bodies/appropriate runtime for later excerpts; independent reader/maintenance outcome evidence; six omitted practice bodies for whole-guide judgment; original cited books/talks and independent service history; Courtney’s purpose and emphasis for personalization. Missing items are unknown or NE, never a finding of whole-book absence. **Recorded corrections and assumptions:** native version 2019-01-23 governs this file despite OPF 2018 date; subtitle variants retained; line conservation is an analogy to repair; source helper bracket defects remain quoted unchanged; predicate probes preserve normalized native behavior but use disclosed pure stubs/current PHP 8.5.9; actual service reachability and historical runtime remain unknown. All priors, cluster design, repairs, PN ideas, experiments, learning design, and diagram verification conditions are system constructs. No rating, reader dates, opinions, or completed user actions are invented. **Prompt execution record:** 0 exact recovery/integrity/24 quotes/coverage;1 system contract/20 questions/8 priors;2 bookmap/summary/hotspots/strategy;3 18 terms/category watchlist;4 20 claims/dependencies/falsifiers;5 quantitative policy/fallback/calibration;6 three cluster analyses/full 37 code blocks/apparatus/7 evidence bundles;7 20 verdicts/8 updates/grade distribution/repairs/counter-observations;8 systems/context/lineage;9 inclusion/transfer/access/reading demands;10 three LN↔PN pairs/attribution audit;11 complete example/lesson/objectives/checks/cautions;12 three inactive experiments/PARA/decision rules/drift;13 three maps/prose/IdeaCompass/omitted visuals. Canonical prompt wording remains [[6. Templates/Books/Work the Book]]. Code labels and prose correspondences are inspected; live Obsidian rendering and Sync aren’t verified. Canonical installation remains pending destination clarification. ## Vault installation record Root audit confirms the declared selected route and quoted locations before installation. Unread sections remain not evaluated. Reader rating and reading dates stay unknown. Live Obsidian rendering and Sync delivery remain unverified.