Skip to content
C.W.K.
Stream
Lesson 05 of 05 · published

The Ninety Percent That Was Plumbing

~14 min · boundaries, judgment, composer, seams

Level 0Loose Parts
0 XP0/41 lessons0/13 achievements
0/100 XP to next level100 XP to go0% complete

The Example That Was a Measurement

The previous lesson listed the composer and the record card as out — domain-toned all the way through, written down as intentional divergence so nobody would re-propose them every quarter. That sentence was true the day it was written. It was a measurement, not a vow.

A later census found the composer chrome at roughly ninety percent identical across the apps that had one: device-draft slots, a textarea and its submit key, paste-to-attach, a staged-media strip, the honesty of queued and failed states. The remaining ten percent was real domain — Ask flows that reach into the draft, an opaque extra slot for an app's own state, the acceptance policy for what may be attached. Those ten percent are why the original ruling said out. They are also why the ruling, read as a vow, would have frozen a wrong example.

The membership test does not change. The measurement did. When a written example and a new measurement disagree, you re-run the question. You do not defend the example.

Promote the Chrome, Leave the Ten Percent as Seams

The ninety percent is plumbing. It does not know what a crumb, a brief, or a journal entry is. It knows a draft, a textarea, and an outcome. That is the same test that admitted the identifier minter. The composer moved.

The ten percent did not move into flags. That is the failure the previous lesson named: a module comes in because it is mostly generic, the rest becomes an enum of apps, and the kit has learned what applications are. The ten percent moved into seams the app fills — an extra slot the kit stores and returns without reading, a submit handler the app owns, a region above the textarea for the rows only one app has, an Ask action that reaches the draft through a ref rather than through a kit-shaped model of asking.

The record card stayed out. Looking alike is still not the test. A card that renders a journey, a reading, or a passage knows what the app is about. Chrome that authors a body does not, once the body is just text and attachments. Two surfaces that travel together in the UI can fall on opposite sides of the line. That is the point of asking per module, not per screen.

A written example is a measurement with a date on it. Intentional divergence is a ruling about today's facts, not a fence around tomorrow's. Re-run the question when the facts move. If the answer flips, record the flip the way you recorded the first ruling — or the next session will treat the old example as doctrine and the new measurement as heresy.

The Same Shape, One Axis Over

The queue kernel in the previous lesson was admitted as plumbing, with domain-toned bodies left in each workshop. That split was re-measured too. Two generic workshops had no such craft: after the app name was substituted, their routes and verbs were copies of each other, with three drifts that meant nothing. Those bodies moved into the kit as a layer on top of the kernel, because the membership test — asked again — returned a different answer for those workshops than it had for the ones whose validation knows what a quest or a vault is.

Not every workshop moved. The ones with craft kept it. The test did not become "queues are now a framework." It became "this pair had no craft, and the copies were lying about it." Same question, narrower subject, new date. The composer and the generic workshops are one lesson: the line is live. The previous lesson taught you to ask. This one teaches you to ask again.

Code

The same test, after the measurement moved·text
THEN (the list in the previous lesson)
  composer + record card: OUT, intentional divergence.
  queue kernel: IN, domain bodies stay in each workshop.

MEASUREMENT
  composer chrome: ~90% identical (draft, textarea, attach, honesty).
  composer Ask / extra / acceptance: the 10%, still domain.
  record card: still domain-toned. Still out.
  two generic workshops' routes and verbs: copies after name
  substitution, three drifts for nothing.

NOW
  composer chrome: IN, through seams — extra is opaque,
    onSubmit is the app's, Ask reaches the draft via a ref.
  record card: still OUT. Looking alike was never the test.
  generic-workshop bodies: IN, as a layer over the kernel.
  domain workshops: still own their validation. The kernel
    did not grow a quest.

THE FAILURE THIS AVOIDS
  if app == "travel":  showPlaceRows()
  if app == "journal": showDateRows()
  if app == "brief":   showJudgeSlots()
  # the kit has learned what applications are.

THE SEAM THAT PASSES
  composer.beforeTextarea = app.rows      # app knows
  composer.extra          = app.project   # kit stores, does not read
  composer.onSubmit       = app.submit    # app owns the payload

External links

Exercise

Find a shared-looking UI pair in your system that was ruled 'too domain-toned to extract' — a composer and a card, a form and a preview, an inbox and a detail. Split the pair. For each half, re-run: does this need to know what the app is about? If one half flips, write the seams that would keep the other half out, as names, before you move any code.
Hint
Start from the fields, not from the screen. A textarea is usually plumbing. The thing that decides what the textarea is about is usually not.

Progress

Progress is local-only — sign in to sync across devices.
Spotted a bug or have feedback on this page?Report an Issue

Comments 0

🔔 Reply notifications (sign in)
Sign inPlease sign in to comment.

No comments yet — be the first.