@hobin/developer 0.1.7 → 0.1.9

package/skills/sketch/references/closure-and-conventional-interfaces.md

@@ -0,0 +1,87 @@
+# Closure And Conventional Interfaces
+
+Use this reference after [Design Levels And Boundaries](design-levels-and-boundaries.md)
+when the unresolved question is which operations keep results inside one
+composable value world and which operations intentionally finalize outside it.
+
+## Closure Unit
+
+```text
+unit predicate: what values belong to the world
+primitives: smallest units
+closed operations: Unit... -> Unit
+observers/finalizers: Unit -> outside world
+invalid combinations: forbidden by meaning or cost
+```
+
+Example:
+
+```text
+Panel = Text(content) | Image(src) | Row(List<Panel>) | Column(List<Panel>)
+```
+
+`Row` and `Column` accept and produce `Panel`, so primitive and compound panels
+combine uniformly. Rendering is `Panel -> Pixels`, an explicit finalizer.
+
+Do not make every method chainable. Preserve closure only for the central
+composition unit.
+
+## Procedures As Values
+
+A higher-order role is justified when variation has a stable contract:
+
+```text
+aggregate(items, base, project, combine)
+```
+
+Record preconditions, effects, errors, order, and cost. Passing a callback does
+not make mutation, retry, or demand irrelevant.
+
+## Conventional Interface
+
+Independent stages may exchange a shared shape:
+
+```text
+enumerateOrders : Query -> Sequence<Order>
+eligible        : Sequence<Order> -> Sequence<Order>
+invoice         : Sequence<Order> -> Sequence<Invoice>
+sum             : Sequence<Invoice> -> Money
+```
+
+State whether the sequence is eager/lazy, ordered/unordered, finite/unbounded,
+single-use/replayable, and effectful/pure. A common type name does not guarantee
+operational compatibility.
+
+## Artifact
+
+```text
+Composition unit and membership rule:
+Primitives:
+Closed operations:
+Observers/finalizers:
+Invalid combinations:
+Higher-order role contracts:
+Conventional interface operational assumptions:
+Transfer composition and failure check:
+```
+
+## Stop And Separation
+
+Stop when closed operations can build every required larger value of the same
+unit, finalizers are explicit, and conventional stages agree on operational
+semantics.
+
+Use `representation-barriers` when raw layout rather than composability is the
+question, and `process-shape-and-resources` when eager/lazy/order/resource
+assumptions need their own execution design.
+
+## Source Trace
+
+- Harold Abelson and Gerald Jay Sussman with Julie Sussman, *Structure and
+  Interpretation of Computer Programs*, Second Edition,
+  Section 1.3
+  for procedures as values and
+  Section 2.2
+  for closure and conventional interfaces.
+- Operational interface assumptions and finalizer failure checks are Developer
+  adaptations of those composition boundaries.

package/skills/sketch/references/composition-by-wishes.md

@@ -0,0 +1,69 @@
+# Composition By Wished Operations
+
+Use this reference after the data-driven recipe when one accepted purpose contains
+several independently meaningful subproblems whose results must compose.
+
+## Wish Before Helper Bodies
+
+Write the product-level result first:
+
+```text
+publishableTasks(tasks):
+  return sortByPriority(onlyReady(normalize(tasks)))
+```
+
+For each wished operation state:
+
+```text
+purpose and domain result
+contract and failure behavior
+representative examples
+its own data-derived template
+why it is an independent subproblem
+```
+
+A helper is earned when it solves a separately nameable domain problem, delegates
+to another data definition, or exposes a required intermediate result. Length
+alone is not a purpose.
+
+## Composition Boundary
+
+Check that adjacent results have compatible meaning, ordering, eagerness,
+replayability, effects, and failure behavior. Acquisition, pure transformation,
+and effects often deserve separate owners because their contracts differ, but do
+not split an atomic invariant merely to obtain a neat pipeline.
+
+## Artifact
+
+```text
+Top-level wished composition:
+Subproblem purposes and contracts:
+Intermediate result meanings:
+Ordering, effect, and failure compatibility:
+Independent examples and templates:
+First composable implementation slice:
+Deferred helpers:
+```
+
+## Stop And Separation
+
+Stop when each wished operation can be designed and checked independently and the
+top-level composition reads in product language without hiding an incompatible
+process boundary.
+
+Use `earned-abstraction` only after several completed correct designs expose
+stable shared roles. Use process/state routes when the unresolved issue is
+execution or history rather than decomposition.
+
+## Source Trace
+
+- Matthias Felleisen et al., *How to Design Programs*, living build 9.2.0.3,
+  Chapter 11
+  for wish lists, composition, and independently designed functions.
+- Harold Abelson and Gerald Jay Sussman with Julie Sussman, *Structure and
+  Interpretation of Computer Programs*, Second Edition,
+  Section 1.1
+  for wishful decomposition and black-box procedures.
+- Zachary Tellman, *Elements of Clojure*, Leanpub 2019-02-11, Composition,
+  public-manuscript pp. 98-115, calibrates composition units and phase ownership;
+  process details remain on their dedicated route.

package/skills/sketch/references/data-driven-design.md

@@ -1,10 +1,17 @@
 # Data-Driven Design
 
 Use this reference when product information should determine the program shape.
-The central insight is concrete: **a data definition is a construction rule for
-valid values, and that same rule determines the first honest function
-template**. Code shape should not be guessed from framework files or a favorite
-pattern when the cases are already present in the data.
+It extends `sketch` from accepted meaning through data, examples, template, and
+first executable item. Specialized references refine one later step; they do not
+replace this derivation.
+
+The central insight is concrete: **a data definition states how valid values are
+constructed and what they mean, and that construction rule determines the first
+honest structural template**. The template inventories possible branches,
+fields, recursions, and delegations. Purpose and examples decide which available
+parts the completed function actually uses. Code shape should not be guessed
+from framework files or a favorite pattern when the cases are already present
+in the data.
 
 ## The Six-Artifact Recipe
 
@@ -24,9 +31,31 @@ required case, repair the data definition. If the template exposes all required
 ingredients but the result is wrong, repair the completed body. If no template
 ingredient can express the purpose, design an auxiliary with its own recipe.
 
-In an existing repository, recover the same artifacts from schemas, types,
-fixtures, callers, UI states, persistence, and tests. Do not copy pedagogical
-comments into production merely to imitate the recipe.
+In an existing repository, recover equivalent evidence from schemas, types,
+fixtures, callers, UI states, persistence, and tests. This recovery is a
+Developer adaptation for production repositories, not a claim that HtDP replaces
+its pedagogical artifacts with those sources. Do not copy recipe comments into
+production merely to imitate the teaching form.
+
+## Function Recipe Versus Program Recipe
+
+The six artifacts organize one function. Whole-program design has a different
+collaboration:
+
+```text
+analyze the information and external interfaces
+-> sketch a top-down wish list of needed functions
+-> choose a coherent inspectable slice
+-> design wished functions bottom-up with the small recipe
+-> run or demonstrate the slice
+-> refine the model and work list from observed discrepancies
+```
+
+Do not flatten top-down planning and bottom-up function construction into one
+large template. Iterative refinement changes an intentionally simplified model
+and propagates the change through data examples, behavior examples, templates,
+implementations, tests, and compatibility surfaces. It is not arbitrary cleanup
+of an unchanged problem.
 
 ## Complete Example: Let The Variants Write The Skeleton
 
@@ -108,20 +137,29 @@ Run all three examples. Then try a fake fourth variant. A compiler failure or
 explicit missing branch reveals the exact extension point; a catch-all returning
 an empty string would hide it.
 
-## Select The Specific Recipe
+## Select One Design Extension
 
-Read only the detail that matches the unresolved design question:
+Read only the extension that answers the unresolved question:
 
-| Evidence | Read | Expected artifact |
+| Question after the base recipe | Read | Expected artifact |
 | --- | --- | --- |
-| atomic values, intervals, itemizations, records, recursive or mutually recursive data, multiple complex inputs, complex outputs, or event loops | [Data-Shape Template Catalog](data-shape-template-catalog.md) | a template whose branches, selectors, recursive positions, and delegations correspond to the data definition |
-| wished helpers, several completed concrete functions, generated subproblems, termination uncertainty, repeated work, or lost traversal knowledge | [Composition, Generative Recursion, And Accumulators](composition-generative-recursion-and-accumulators.md) | separately designed auxiliaries, a justified abstraction, a generation template plus termination argument, or an accumulator invariant |
+| Which branches, selectors, recursive positions, or delegations follow from this data shape? | [Data-Shape Template Catalog](data-shape-template-catalog.md) | a data-corresponding template |
+| Which independently meaningful operations compose the result? | [Composition By Wished Operations](composition-by-wishes.md) | wished-operation contracts and one composable slice |
+| Which stable roles appear across several completed designs? | [Earned Abstraction](earned-abstraction.md) | completed-design alignment, variation-role table, and candidate handoff |
+| How are new problem instances generated, preserved, and proven to progress? | [Generative Recursion](generative-recursion.md) | generation, preservation, combination, and progress artifacts |
+| What lost knowledge or repeated work should traversal carry? | [Accumulator Invariants](accumulator-invariants.md) | an original/current/accumulated invariant with ownership and semantic-delta checks |
 
-These documents extend this recipe; they do not replace the six artifacts.
+Each extension refines a different design step. Select several only when their
+questions are independently consequential; do not treat them as a progression or
+one bundled recursion topic.
 
-## Existing-Code Recovery
+## Existing-Code Recovery (Developer Adaptation)
 
-Use this recovery table rather than assuming the declared type is complete.
+Use this recovery table rather than assuming the declared type is complete. The
+evidence sources and compatibility obligations below adapt HtDP's artifacts to
+an existing repository; they are package-owned operational guidance.
+
+<!-- markdownlint-disable MD013 -->
 
 | Artifact | Repository evidence | Typical contradiction |
 | --- | --- | --- |
@@ -132,10 +170,31 @@ Use this recovery table rather than assuming the declared type is complete.
 | template | branches, selectors, traversal, delegation | catch-all hides a meaningful clause |
 | completed body | implementation | code needs information absent from the data model |
 
+<!-- markdownlint-enable MD013 -->
+
 When evidence conflicts, keep the contradiction visible. `model` owns disputed
 validity or policy; this reference shapes the implementable surface once the
 meaning is accepted.
 
+## Propagate Model Refinement
+
+When a required case cannot be represented or a forbidden value remains easy to
+construct, revise one accepted model fact and propagate it through:
+
+```text
+data definition and interpretation
+-> data examples
+-> behavior examples
+-> template
+-> implementation
+-> checks
+-> persisted and public compatibility surfaces
+```
+
+A type edit is not complete while older serialized values or callers still use
+the prior model. Propagation is a consistency obligation, not permission for
+unrelated cleanup.
+
 ## Sketch Output
 
 ```text
@@ -152,6 +211,8 @@ Deferred: abstractions or policies not yet earned
 
 ## Failure Diagnosis
 
+<!-- markdownlint-disable MD013 -->
+
 | Symptom | Return to |
 | --- | --- |
 | valid product case has no representation | data definition and interpretation |
@@ -163,15 +224,31 @@ Deferred: abstractions or policies not yet earned
 | abstraction precedes comparable completed designs | abstraction-from-examples recipe |
 | changed type ignores stored/public older forms | existing-code recovery and compatibility model |
 
+<!-- markdownlint-enable MD013 -->
+
 ## Source Trace
 
 - Matthias Felleisen, Robert Bruce Findler, Matthew Flatt, and Shriram
-  Krishnamurthi, *How to Design Programs, Second Edition*, MIT Press, 2018,
-  and the [official living edition](https://htdp.org/2026-5-28/Book/index.html):
-  information analysis, data definitions and interpretations, examples,
-  signatures and purpose statements, templates, implementations, tests, and
-  iterative refinement.
+  Krishnamurthi, *How to Design Programs*, official living build 9.2.0.3,
+  released 2026-05-28 and audited 2026-05-28:
+  Preface: Systematic Program Design
+  for the ordered recipe and function/program distinction;
+  Chapter 3: How to Design Programs
+  for signatures, purpose, examples, templates, definitions, and tests;
+  Chapter 6: Itemizations and Structures
+  for mixed-data derivation; and
+  Epilogue: Moving On
+  for top-down work lists, bottom-up construction, feedback, and maintenance
+  communication.
+- The repository-recovery table, compatibility surfaces, and production artifact
+  substitutions are Developer adaptations derived from the source method; they
+  are not canonical HtDP artifacts.
 - Harold Abelson and Gerald Jay Sussman with Julie Sussman, *Structure and
   Interpretation of Computer Programs*, Second Edition, MIT Press, 1996:
-  wishful decomposition and the distinction between procedure text and the
-  process it generates.
+  Section 2.1
+  for wishful decomposition and
+  Section 1.2
+  for the distinction between procedure text and the process it generates. Data
+  interpretation, templates, ordered recipe steps, repository recovery, and
+  compatibility artifacts remain HtDP-derived or Developer adaptations as
+  identified above.

package/skills/sketch/references/data-shape-template-catalog.md

@@ -1,7 +1,10 @@
 # Data-Shape Template Catalog
 
 Use this catalog after the six-artifact recipe in
-[Data-Driven Design](data-driven-design.md). Its core rule is:
+[Data-Driven Design](data-driven-design.md) when the unresolved step is deriving
+the structural template. Stop after branches, selectors, recursions, and
+delegations correspond to accepted data; generated algorithms and carried
+knowledge have separate routes. Its core rule is:
 
 ```text
 data clause          -> function branch
@@ -10,8 +13,10 @@ self-reference       -> natural recursive call at that exact position
 reference to B       -> delegation to B's template at that exact position
 ```
 
-The template inventories available ingredients. The purpose and examples decide
-how to combine them.
+The initial template inventories all structurally available ingredients. The
+purpose and examples decide how to combine them and may justify omitting an
+irrelevant selector, recursion, or delegation from the completed body. Record
+that omission instead of pretending the data reference never existed.
 
 ## Atomic And Fixed-Size Data
 
@@ -57,13 +62,17 @@ render(result):
 ```
 
 Merge two clauses only when their product meaning, not merely their current body,
-is the same. A catch-all branch is suspicious when adding a variant should force
-a new decision.
+is the same. A catch-all branch is justified only when every accepted remainder
+has one known meaning. It is suspicious when adding a variant should force a new
+decision, or when it groups unmodeled external values with a domain default.
 
 ## Structures And Records
 
-A record groups a fixed natural whole. List only fields relevant to the purpose;
-the template is not permission to expose every stored field.
+A record groups a fixed natural whole. The canonical structural template first
+lists the record's selectors so the complete inventory is visible. A production
+sketch may destructure only purpose-relevant fields, but that is a Developer
+adaptation: explain why omitted fields cannot affect the stated result instead of
+silently treating them as nonexistent.
 
 ```text
 Schedule = Schedule(start, end, timezone)
@@ -79,8 +88,9 @@ than stated or the data definition lacks information.
 ## Self-Referential Data
 
 A valid self-referential definition has at least one non-recursive clause from
-which values can be constructed and at least one recursive clause that creates
-larger values.
+which finite values can be constructed and at least one recursive clause that
+creates larger values. A self-reference with no reachable base describes no
+finite value and must be repaired before a recursive template is trusted.
 
 ```text
 Tasks = Empty | Node(Task, Tasks)
@@ -147,8 +157,11 @@ countBlock(block):
     Image(src)      -> 0
 ```
 
-The reference graph, not convenience, determines the delegations. An oversized
-function with nested tags usually means the template family was collapsed.
+The reference graph, not convenience, determines the initial delegations. An
+oversized function with nested tags usually means the template family was
+collapsed. In a completed function, purpose may eliminate a structurally
+available delegation; the evidence is the explicit purpose, not convenience or
+call-count reduction.
 
 ## Two Complex Inputs
 
@@ -156,11 +169,16 @@ Do not automatically multiply every clause. Decide how the two values move.
 
 ### One input controls
 
-`applyDiscounts(cart, rules)` traverses the cart while `rules` is constant or
-queried. Derive the traversal from `Cart`; treat `Rules` as domain knowledge.
+`applyDiscounts(cart, rules)` traverses the cart while `rules` is carried as a
+complete value or queried. Derive recursive progress from `Cart`; do not
+decompose `Rules` merely because its representation is complex.
 
 ### Inputs move in lockstep
 
+Use this route only when a same-size or same-shape invariant and positional
+correspondence make progress on both inputs meaningful. State what happens when
+the invariant is violated; do not inherit shortest-input truncation silently.
+
 `sameShape(leftTree, rightTree)` compares corresponding nodes. State the shape
 relation and branch on paired cases:
 
@@ -172,9 +190,16 @@ relation and branch on paired cases:
 
 ### Inputs vary independently
 
+When neither control nor lockstep correspondence applies, enumerate the
+Cartesian product of data alternatives. Use one case example per meaningful cell,
+inventory the selectors available there, and treat all selector-based recursive
+calls as candidates until purpose selects which arguments progress together.
+
 Collision policy between `UserRole` and `ResourceState` may need the meaningful
 cross-product or a decision table. Write all relevant combinations explicitly;
-do not hide them in nested defaults.
+do not hide them in nested defaults. For three independent complex inputs the
+same reasoning becomes a conceptual three-dimensional space; first look for a
+better relation or decomposition before materializing the cube.
 
 The smell is not “two loops.” It is an unstated relationship between the input
 shapes.
@@ -234,8 +259,22 @@ temporal rule to `model`.
 
 ## Source Trace
 
-- [*How to Design Programs*, official living edition](https://htdp.org/2026-5-28/Book/index.html):
-  the recipes for atomic data, intervals, itemizations, structures,
-  self-referential and intertwined definitions, multiple complex inputs,
-  complex outputs, and world programs. The examples here are adapted to ordinary
-  product code and are not copied from the book.
+- Matthias Felleisen, Robert Bruce Findler, Matthew Flatt, and Shriram
+  Krishnamurthi, *How to Design Programs*, official living build 9.2.0.3,
+  released 2026-05-28 and audited 2026-05-28:
+  Chapter 4,
+  Chapter 5,
+  and Chapter 6
+  for intervals, itemizations, records, and mixed data;
+  Chapter 8,
+  Chapter 9,
+  and Chapter 10
+  for constructible self-reference and natural recursion;
+  Chapter 19
+  for mutually referential definitions and template families; and
+  Chapter 23
+  plus Chapter 24
+  for controlling, lockstep, and Cartesian multi-input design.
+- Purpose-only destructuring, product-language examples, explicit invariant
+  violation behavior, and repository diagnostics are Developer adaptations. The
+  source's initial structure templates inventory the full selector set.

package/skills/sketch/references/design-levels-and-boundaries.md

@@ -0,0 +1,133 @@
+# Design Levels And Boundaries
+
+Use this reference when a sketch must decide which vocabulary a caller may use,
+which owner controls a consequential choice, and which lower-level details may
+change independently. It is the common kernel for representation, process,
+state, generic-operation, and language routes; it does not contain their
+specialized construction methods.
+
+## Boundary Spine
+
+```text
+caller purpose and cases
+-> wished operations in caller language
+-> contract and admitted observers
+-> owner of policy/invariant/history
+-> hidden lower-level choice
+-> alternate implementation or counterexample
+```
+
+A boundary is real only when it hides a consequential choice and leaves a
+smaller truthful contract. A renamed mechanism is not a new level.
+
+## Write Levels Explicitly
+
+```text
+product level:
+  operations users or callers intend
+
+domain/service level:
+  concepts, laws, roles, and state transitions
+
+mechanism level:
+  storage fields, libraries, transport, threads, runtime instructions
+```
+
+Each level may depend on the vocabulary immediately below it. Higher levels must
+not inspect the representation that a lower owner promises to hide. Add a level
+only when it supplies meaningful primitives, combinations, or reusable laws.
+
+## Contract Before Shape
+
+For each wished operation state:
+
+```text
+caller-visible result and failure
+normal, boundary, and forbidden examples
+observers callers may rely on
+owner of validation, normalization, state, or ordering
+mechanism callers should stop knowing
+smallest replacement or falsifying check
+```
+
+Do not invent public selectors merely because a representation has fields. Expose
+only operations current caller purposes support. Conversely, a claimed boundary
+is false when callers still need raw layout to complete their work.
+
+## Environment And Assumptions
+
+Every boundary models an environment:
+
+```text
+environment: real participants and change pressure
+model: represented facets
+ignored facts: deliberately outside the contract
+interface: stable sense exposed to callers
+assumptions: environmental facts required for usefulness
+drift signal: evidence assumptions may no longer hold
+```
+
+Internal invariants can keep the model self-consistent; they cannot prevent the
+environment from changing. Public boundaries calcify, so mature them locally when
+participants co-evolve. Independent participants, purposes, deployment cycles, or
+replacement pressure justify stronger interfaces.
+
+## Select One Specialized Judgment
+
+| Unresolved question | Reference | Output |
+| --- | --- | --- |
+| representation independence and public laws | [Representation Barriers](representation-barriers.md) | public operations/laws, two representations, caller rewrite, and leak check |
+| closed composition or conventional interfaces | [Closure And Conventional Interfaces](closure-and-conventional-interfaces.md) | unit, closed operations, finalizers, and operational interface contract |
+| generated work, control, waits, capacity, resources, or effects | [Process Shape And Resources](process-shape-and-resources.md) | process trace, bounds, phase and completion ownership |
+| history, identity, mutation, state transition, event order, or logs | [State, History, And Order](state-history-and-order.md) | history owner, transition/order law, stale/duplicate policy |
+| additive representations and operation dispatch | [Generic Dispatch Systems](generic-dispatch-systems.md) | variant-operation matrix and conflict policy |
+| cross-representation operation and semantic loss | [Meaning-Preserving Conversions](meaning-preserving-conversions.md) | conversion graph and preserved/lost observers |
+| notation, grammar, evaluator, and language results | [Language Semantics](language-semantics.md) | expression boundary and evaluator/result contract |
+| interpreter/compiler lowering and optimization | [Runtime And Compilation](runtime-and-compilation.md) | execution convention, effects, guards, roots, and interoperation |
+| knowledge and participant ownership | [Responsibility And Collaboration](responsibility-and-collaboration.md) | responsibility and collaboration map |
+| shared caller roles across implementations | [Variation Roles](variation-roles.md) | role and substitution contract |
+| one domain type becoming another | [Type Transitions](type-transitions.md) | source/event/target and preserved-meaning contract |
+| variant selection and construction | [Selection And Creation](selection-and-creation.md) | selection owner and least-powerful creation boundary |
+
+Select several only when they answer independent questions. Do not load this
+common kernel as permission to absorb the specialized judgment.
+
+## Artifact
+
+```text
+Caller purpose and representative cases:
+Wished operations:
+Levels and dependency direction:
+Contract and observers:
+Owner:
+Hidden choice:
+Environment, ignored facts, assumptions, and drift:
+Alternate implementation or falsifier:
+Specialized handoff:
+```
+
+## Stop And Separation
+
+Stop when every dependency arrow uses a truthful vocabulary, each guarantee has
+one owner, and a lower-level choice can be varied or falsified without rewriting
+unrelated callers.
+
+Separate when the unresolved issue has its own output and stop check in the table
+above. Return to `model` when admitted meaning is disputed, and to
+`abstraction-review` only after the candidate surface exists.
+
+## Source Trace
+
+- Harold Abelson and Gerald Jay Sussman with Julie Sussman, *Structure and
+  Interpretation of Computer Programs*, Second Edition:
+  Section 1.1,
+  Section 1.2,
+  Section 1.3,
+  and Section 2.1
+  for wishful decomposition, levels of language, procedures as black boxes, data
+  abstraction, and representation laws.
+- Zachary Tellman, *Elements of Clojure*, Leanpub 2019-02-11:
+  Indirection, public-manuscript pp. 70-95, for environment/model/interface/
+  assumptions, participant pressure, interface collapse, and calcification.
+- Hillel Wayne, *Logic for Programmers*, v0.14.0:
+  Chapters 2-3 and 9-10 for ability/guarantee and observer-relative refinement.

package/skills/sketch/references/earned-abstraction.md

@@ -0,0 +1,75 @@
+# Earned Abstraction
+
+Use this reference when at least two correct completed designs with stable
+purposes and data models may share one common movement and variation-role set.
+
+## Align Completed Designs
+
+```text
+sum:      Empty -> 0;    Node(x, xs) -> x + sum(xs)
+allReady: Empty -> true; Node(x, xs) -> x.ready && allReady(xs)
+```
+
+Align roles:
+
+| Role | `sum` | `allReady` |
+| --- | --- | --- |
+| base | `0` | `true` |
+| item projection | identity | readiness |
+| combination | addition | conjunction |
+
+Only then is a candidate such as `fold(sequence, base, project, combine)` visible.
+The shared template locates a candidate; it does not approve it.
+
+## Stability And Migration
+
+Check:
+
+- roles have domain or process meaning rather than syntax-fragment names;
+- old designs become simple clients after migration;
+- one realistic transfer case fits without flags exposing internals;
+- evaluation order, effects, errors, numeric association, and resource shape are
+  preserved for declared observers;
+- the data interpretation is stable enough that difference is understood.
+
+An abstraction is not a single point of control until intended clients migrate.
+Stop at a candidate and route `abstraction-review` for promotion.
+
+## Artifact
+
+```text
+Completed concrete designs and purposes:
+Aligned common movement:
+Variation-role table:
+Candidate interface and caller examples:
+Process and observer obligations:
+Client migration boundary:
+Transfer case:
+Deferred or rejected abstraction:
+```
+
+## Stop And Separation
+
+Stop when completed designs align under stable roles, migrated clients are
+simple, and one transfer case fits without semantic drift. The result is a
+candidate, not approval.
+
+Return to `signal` when only horizontal similarity is visible, to `model` when
+data meaning is unstable, and to `abstraction-review` for keep/revise/split/
+reject/defer.
+
+## Source Trace
+
+- Matthias Felleisen et al., *How to Design Programs*, living build 9.2.0.3:
+  Chapter 14,
+  Chapter 15,
+  and Chapter 16
+  for completed examples, aligned roles, abstraction, and client use; Chapters
+  19-20 calibrate model stability before simplification.
+- Harold Abelson and Gerald Jay Sussman with Julie Sussman, *Structure and
+  Interpretation of Computer Programs*, Second Edition,
+  Section 1.3
+  for higher-order procedure roles.
+- Sandi Metz, Katrina Owen, and TJ Stankus, *99 Bottles of OOP*, Second Edition,
+  v2.2.2, Chapters 3-4, pp. 51-101, calibrates smallest difference, horizontal
+  movement, stable landings, and the stop before promotion.