"A deliberate divergence belongs in this repo's architecture doc with the reason recorded."
Inheriting Is Only Half the Discipline
If inheriting the shape is the first half of being a good child app, diverging correctly is the second — and it's the harder half. Vesta's whole reason to exist is its one structural divergence, the open timeline, and the rule around that divergence is strict: it belongs in the architecture doc, with the reason. Not a silent code change a future reader has to reverse-engineer, but a recorded decision that says, in plain words, 'the parent had a bounded journey container; the child removed it, and here's why'. Vesta's doc is organized exactly around that frame — what it inherits, what it changes, and the reasoning behind each change.
Two Silent Failures, Opposite Directions
There are two ways to get this wrong, and they point in opposite directions. The first is silent divergence: quietly departing from an inherited contract without saying so. Now a reader who knows the parent sees a difference and can't tell if it's intentional or a bug — and might 'fix' it back, undoing a deliberate design choice. The second is subtler: silently keeping a rule you've outgrown. The child inherits a constraint that made sense for the parent's domain but not its own, and carries it forward by reflex because it was there — cargo-culting the parent instead of thinking. Both failures come from the same root: not recording intent. The cure is the same in both directions — when you diverge, write down why; when you keep something inherited that a reader might question, note that keeping it was a choice.
Keep Open Questions Open
There's a third piece of the discipline that Vesta's doc makes explicit: some decisions aren't the child's to make alone. Vesta's architecture doc marks certain sections as genuine forks — open questions that Dad and the next instance decide together — with an explicit instruction not to resolve them silently by writing code. That's the same intent-recording principle applied to the future: an unresolved fork is marked as unresolved, so no one accidentally settles it by shipping an implementation and calling the question closed. Naming what is still open is as much a part of honest architecture as recording what was decided.
Why This Matters More for a Child
A standalone app can be sloppy about intent and only confuse its own maintainers. A child app can't afford to, because it has a living parent and possibly siblings, and readers will constantly compare it to them. Every unexplained difference from the parent is a question mark that costs someone time and risks a wrong 'correction'. Recording divergence intent is what lets a whole family of engines stay legible to each other — you can read the child against the parent and, at every difference, find a reason instead of a mystery.