The Reuse Ledger

"The best code Waystone ships is the code it didn't write, because a sibling already owns it well."

The Ecosystem Is the Library

Waystone starts every capability decision from a deliberate stance: the whole CWK ecosystem is its component and pattern library. Before writing anything new, it asks whether a sibling already owns this well. Pippa owns judgment. Rekindle owns prose editing. Recall owns media discovery. Lantern owns retrieval. The public site owns publishing. The default answer to "how should Waystone do X?" is often "it shouldn't — it should reuse the sibling that already does X, and spend its own effort on the travel-specific part only."

Adopt, Extract, Adapt, Invent

The reuse ledger is an explicit order of preference, and the order matters:

Adopt an existing canonical API or component when its ownership and semantics already match. Cheapest, best.
Extract a genuinely shared primitive when two siblings need the same thing and the source owner can stay explicit. More work, still shared.
Adapt a proven interaction or storage pattern when the domain semantics differ. You reuse the shape, not the code.
Invent only the remaining travel-specific gap. This is where Waystone's actual effort should go.

You walk down that list and stop at the first rung that fits. Inventing is the last resort, not the first instinct — and by the time you reach it, you have narrowed the thing you are inventing down to only what is genuinely new about travel.

Reuse Is Not Routing Data Through the Wrong Table

There is a false version of reuse worth naming: shoving Waystone's domain records into a sibling's existing storage because the table is already there. That is not reuse — it is ownership confusion. Real reuse carries forward the already-learned contract (the API, the pattern, the IDs) while keeping the canonical owner canonical. Reusing the site's date-slot grammar does not mean storing travel data in the public site's database; reusing a stream's interaction grammar does not mean routing breadcrumbs through the stream's tables. Reuse the shape and the interface; never borrow a home for data that belongs to you.

Code

Walk the ledger, stop at the first fit·text

need a capability?
  1. ADOPT   canonical API/component, semantics match?   -> use it
  2. EXTRACT shared primitive two siblings need?          -> extract it
  3. ADAPT   proven pattern, domain differs?              -> reuse the shape
  4. INVENT  only the travel-specific gap that's left     -> build it

# Example (Waystone's real ledger):
#   consultation runtime  -> ADOPT cwkPippa
#   date-slot grammar     -> ADAPT the site's YYYY-MM-DD-NN shape
#   prose editing         -> ADOPT Rekindle (Send/Pull)
#   retrieval             -> ADOPT Lantern as a corpus consumer
#   travel domain model   -> INVENT (this is the actual new part)

Exercise

Pick a feature you built (or want to build) from scratch. Walk it down the ledger: could you have Adopted something canonical, Extracted a shared piece, or Adapted a proven pattern — and how much would truly have been left to Invent? Most 'build it ourselves' decisions skip straight to Invent because nobody checked the first three rungs.

Hint

The reuse discipline fails at the top of the ledger, not the bottom — people jump to Invent without honestly asking whether rungs 1 through 3 fit. If you find that most of what you built already existed somewhere you own, you skipped the ledger. The gap worth inventing is usually much smaller than the feature.