Two Catalogs That Never Touch

"Both sides have a thing called 'macros.' That shared word is a trap, not a reason to merge them."

Two Lists That Look Alike

Flint keeps a list of macros — name, prompt template, chord, vault mode — in a local file it owns. The borrowed brain also has a catalog of its own utility operations, for its own surfaces. They look like the same concept, and that resemblance is exactly where a coupling wants to sneak in: 'they're both macro lists, why not share them, or sync them, or let one reference the other by id?' The answer is that they serve different owners and touching them together undoes the remake.

The Coupling the Remake Removed

The predecessor tool tangled the client's operations with the server's — the two were one intermixed system, and changing one meant reasoning about the other. Pulling them apart was a deliberate goal of the remake, not an accident of it. So Flint's catalog and the brain's catalog are independent by design: Flint renders and sends its own prompts (the apply-free contract from the last lesson is what makes this possible), and never calls a brain-side macro by id. The two lists can grow, shrink, and change on completely separate schedules.

FLINT'S CATALOG (local)        BRAIN'S CATALOG (its own)
----------------------        -------------------------
owned by Flint                owned by the brain
rendered into free prompts    used by the brain's surfaces
change freely                 change freely
         \                              /
          \___ never share an id ______/
              never sync
              never reference by id

Neither Owns the Other

Independence means no direction of control. Flint doesn't manage the brain's macros, and the brain doesn't push macros to Flint. If you edit a Flint macro, nothing on the brain changes; if the brain's catalog is reorganized, Flint doesn't notice. That's the whole benefit: two people (or two future selves) can work on the two lists without stepping on each other, because there is no shared state to step on.

When two similar things have different owners, keep them separate — even at the cost of some duplication. The instinct to unify anything that looks alike (a strong 'don't repeat yourself' reflex) is wrong when the two things are owned by different parts of the system. Merging them creates a coupling that outlives the small duplication you saved. Shared shape is not shared ownership; let ownership, not resemblance, decide what gets merged.

Removing this exact coupling was the point of the remake. The old tool's client-server tangle is the thing Flint's independence is a cure for. So when a future change tempts you to 'just let Flint reuse the brain's macros to avoid duplicating them,' recognize it as the disease coming back, and decline. The duplication is cheap; the coupling is the expensive thing you already paid to remove.

Code

Flint's catalog is local and self-owned·swift

// Flint persists its own macros in its own local file. The brain never
// writes here, and Flint never reads the brain's catalog.
struct MacroStore {
    private(set) var macros: [FlintMacro]

    func save() throws {
        let data = try JSONEncoder().encode(macros)
        try data.write(to: localMacrosFile)   // Flint's own data folder
    }
    // There is no sync(), no fetchFromBrain(), no shared id space.
    // Independence is enforced by the ABSENCE of those methods.
}

Exercise

A teammate proposes: 'Both Flint and the brain store macros; let's make one canonical macro store and have both read from it to avoid duplication.' Argue the case against, using the specific coupling it would reintroduce. Then describe the one thing that resemblance is allowed to justify (shared code) versus the thing it must not (shared ownership).

Hint

A canonical store re-couples the two systems: editing a macro for one silently changes the other, and neither can evolve independently — precisely the tangle the remake removed. Resemblance can justify sharing a data *type* or rendering *code* (pure, ownerless helpers), but never a shared, mutable *catalog* that both sides own, because that reintroduces the control coupling the independence exists to prevent.

Two Catalogs That Never Touch

Two Lists That Look Alike

The Coupling the Remake Removed

Neither Owns the Other

Code

External links

Exercise

Progress

Comments 0