Add pipeline inheritance coverage and guidance

docs/config.md

@@ -91,6 +91,42 @@ append a pipeline's `steps` sequence. An overlay replaces sequences as defined
 by ConfigKit, so changing an individual ordered binding requires supplying the
 whole replacement sequence.
 
+## Sibling Inheritance
+
+ConfigKit v0.5.0 supports native `extends` composition in mappings. A directive
+names exactly one immediate sibling in the same mapping; it is not a path or a
+cross-scope lookup. Imports, the selected overlay, and explicit overrides are
+composed before inheritance, which runs before typed decoding and normal
+Notarius validation. Every definition, including a parent and definitions not
+selected for a run, remains subject to ordinary validation.
+
+Child mappings recursively overlay parent mappings. A child sequence, scalar,
+or null replaces the inherited value. This makes pipeline inheritance useful
+for reusing a complete pipeline while replacing whole ordered lists:
+
+~~~yaml
+pipelines:
+  production:
+    input: {module: seriatim}
+    llm_profile: dnd-extraction
+    # Other complete pipeline settings and ordered steps...
+  development:
+    extends: production
+    structured_output_repair_attempts: 0
+~~~
+
+Pipeline names are siblings within `pipelines`; nested mappings such as named
+artifact lanes also have their own sibling namespace. Step entries are a
+sequence, so a step cannot extend another step. Replacing `steps` or a validator
+chain supplies the complete replacement sequence; entries are not appended or
+merged by identifier.
+
+`extends` is now a reserved key in every input mapping, including dynamic
+module options and named maps. Existing ordinary data or entry names using that
+key must be renamed along with any consumer that reads them. Configuration
+overlays, pipeline inheritance, and PromptKit profile `base_profile`
+inheritance are separate mechanisms.
+
 ## PromptKit Profiles
 
 The optional **promptkit** object selects one source of profile definitions and