Plan sibling inheritance implementation

docs/roadmap/named-inheritance.md

@@ -1,7 +1,7 @@
 # Built-In Sibling Configuration Inheritance
 
 Status: agreed feature design; not implemented. This document defines the intended
-end state. A separate implementation plan will define execution steps.
+end state. The [implementation plan](implementation.md) defines execution steps.
 
 ## Purpose and priorities
 
@@ -275,9 +275,9 @@ output than the source declarations. Use representative chains, shared-base tree
 wide collections, and replacement cases to evaluate growth. Performance evidence
 is not a new release timing gate.
 
-Existing acquired-input accounting remains in force. The eventual implementation
-plan must define how expanded output and retained derivation fit existing decoded
-tree/history limits, including where expansion is checked. Avoid silently charging
+Existing acquired-input accounting remains in force. Expanded output and retained
+derivation respect existing decoded tree/history limits; the implementation plan
+defines accounting and check placement. Avoid silently charging
 one inherited value as a newly acquired source or inventing arbitrary entry/chain
 caps. Any necessary new public limit requires an explicit design decision.
 
@@ -302,7 +302,7 @@ A new ADR should record the selected inheritance architecture.
 Architecture/deferred-scope documentation must recognize
 the new structural responsibility; public API, configuration, consumer, and
 internal documentation should describe implemented behavior when it lands.
-Implementation sequencing belongs in a separate future plan. Reserving `extends`
+Implementation sequencing belongs in the implementation plan. Reserving `extends`
 changes behavior for applications that currently use it as ordinary data. Document
 that compatibility change and the required migration rather than describing this
 as a purely additive opt-in feature. Configurations without `extends` retain their