Transferring between engagements

The methodology runs one engagement at a time, but engagements are siblings: each is an instance — its own requirements, data, filled cockpit — and a later one often wants something an earlier one worked out (a station layout, a data shape, a fork pattern, a coverage convention). Moving it across is transfer, and it is never trivial. This is the discipline for doing it without corrupting either instance or the shared scaffold.

Be clear first about what cannot be “transferred” at all, because mistaking the shared layers for transferable material is the dominant failure here. The kernel and the shell are pinned, not copied between engagements — both cockpits consume them through one pinned _methodology submodule, exactly like brand → website/_brand (cockpit.md owns the five-layer Contract/Kernel/Shell/Template/Instance model and the pin-vs-copy rule). You never lift the shell out of one instance and paste it into another; you improve it at the producer, then both instances re-pin. The template is copied — once, at the start of an engagement, into <engagement>/site/ — and from then on it is that instance’s own. So a transfer is never “move the shell across.” What actually travels between two live instances is narrower: data-format patterns and station-renderer patterns — the conventions, not the pinned machinery.

A transfer is surgical, not a copy. Before moving anything, read the source instance’s code in detail and name exactly what you are transferring and what its blast radius is — which files, which data shapes, which assumptions travel with it. Most “just copy the feature” requests are a composition of parts with different owners; treat the move as an excision, not a paste. A station renderer pattern, for instance, drags its data shape and its dependence on ctx.kernel.*/ctx.forks.* accessors with it (cockpit.md) — name those before you lift it.

Don’t assume the direction, or what survives. When a capability — or parts of one — exists on both ends, you have a choice to make per axis, not a default to apply: whose design do we keep, whose data shape, whose client copy? (Copy is a shell layer, one of the three registers, not the data — model.md.) Surface each axis and decide it with the user. “Adopt the source instance’s everything” is not a rule — it was one engagement’s answer.

Compare the data, not just the formats. Part of the evaluation is laying the two instances’ data files and their contents side by side, surfacing every difference, checking each against the methodology’s current canon — the naming grammar and the schema, both owned by contract.md — and making the gap explicit before you reconcile it. Drift between siblings is invisible until you diff them; a transfer is when it surfaces. Make it congruent first, then move.

Substance is re-derived, never ported. The architectures, the forks, the archetypes, the verdict — these belong to the engagement that produced them, because each was derived from that mission and those requirements (process.md for the per-phase derivation). Ported substance is almost always wrong: a fork that resolved one engagement’s buy-vs-build tension says nothing about another’s. What travels is the form — the data-shape pattern, the station-renderer pattern — and the target’s substance is built fresh through its own Phases 1–4. If you find yourself copying a populated solutions.json or a filled fork across, stop: you are porting an answer.

Promote on judgment, not by counting. A pattern worked out in one engagement’s instance earns generalization when it generalizes — when you can see it has stopped being this client’s quirk and become a shape a sibling will genuinely reuse. Keep clearly client-specific things instance-local; promote a pattern to the shared template/ at the producer when your judgment says it is no longer case-specific (cockpit.md — the template is the copy-me scaffold, and improvements to the shared layers flow back to the producer, never sideways between instances). It is cheap to promote later, so when in doubt keep it local — a transfer between two siblings is just the natural moment to ask whether the pattern has earned the move. (There is no mechanical count; the old “rule of three” is retired — the discriminator is whether it generalizes, in your judgment.)

Plan the transfer as its own mini-engagement. A non-trivial transfer is not an ad-hoc edit: it has a research pass (read both codebases), a congruence pass (diff and reconcile the data against contract.md’s canon), independent workstreams, and sign-off gates — written down in advance, the same phase-gating discipline the methodology runs on (process.md). It may well execute as a dynamic workflow, but that only works because it was planned first. If you are about to “just port it,” stop and plan it.

Roadmap. This discipline currently lives as a reference. Once enough transfers confirm its shape that it clearly generalizes, it graduates to its own consumer-side skill (like methodology-feedback: monorepo-authored, not synced, because it touches engagement folders, the shared template, and the pins) — not a producer-side skill, so no new build pipeline is needed. Until then, it stays here.