Plan recorded field normalization

docs/roadmap/field-normalization.md

@@ -160,39 +160,18 @@ the existing validation path. Do not add a promise of identical diagnostic
 wording, ordering, or internal callback timing. No YAML syntax or collection
 specification-version change is planned.
 
-## Implementation Stages
+## Acceptance And Documentation
 
-### 1. Adopt ConfigKit v1.1.0
+Adopt the released ConfigKit v1.1.0 module without a committed local replacement,
+with applicable attribution updated. The companion
+[implementation plan](implementation.md) owns sequencing and implementation steps.
 
-Update the released module dependency and sums, review applicable attribution,
-and run the existing suite against the release. Use the published module rather
-than a committed local replacement. Keep this dependency change separable from
-the normalization refactor so failures can be attributed clearly.
+Ordinary invalid resources should retain useful rejection rather than becoming
+unrecorded-mutation failures because a sibling field needed normalization.
+ConfigKit's conservative list audit does not justify new identity rules or a
+separate source audit.
 
-### 2. Move Existing Configuration Transformations
-
-Move backend, profile, and prompt transformations into recorded resolution,
-including the conditional queue default. Preserve the entry metadata consumed
-by presence-sensitive behavior. Update runtime construction to use the resolved
-configuration and remove redundant interpretation state.
-
-Keep domain validation on effective values. Account for ConfigKit's conservative
-audit of lists with invalid identities so an ordinary invalid resource does not
-accidentally become an unrecorded-mutation failure merely because a sibling
-field needed normalization. This calls for integration coverage, not additional
-identity rules or a separate source audit.
-
-### 3. Include Configured Message Fields
-
-Move configured role and cache-control normalization into the same lifecycle,
-recording nested fields individually. Reuse the domain normalizers that serve
-runtime messages. Simplify prompt materialization where work has become
-redundant, while retaining template compilation, content-file reading, and
-domain construction at their appropriate boundaries.
-
-### 4. Verify The Boundary And Update Documentation
-
-Add focused tests where behavior crosses the loading/inspection boundary:
+Focused boundary coverage should demonstrate:
 
 - Normalized effective values and explanations for representative backend,
   profile, prompt, and nested message fields at root and collection destinations.
@@ -206,13 +185,8 @@ Add focused tests where behavior crosses the loading/inspection boundary:
   hashes, and continued normalization of caller-appended messages.
 - Existing redaction, normalized-value diff behavior, and atomic list diffs.
 
-Use targeted integration cases instead of reproducing ConfigKit's correspondence
-test suite. Run the relevant configuration, inspection, and execution tests,
-then the ordinary repository checks for the completed change.
-
-Update the format reference, consumer inspection guidance, source-loading
-documentation, and affected GoDoc when behavior lands. Explain the inspection
-change and its limits in the release notes. Review architecture wording against
-the implemented callback flow without converting implementation details into
-new contracts. Retire this roadmap and its incoming catalog link once the work
-is complete.
+Coverage should target PromptKit integration rather than reproduce ConfigKit's
+correspondence test suite. The format reference, consumer inspection guidance,
+source-loading documentation, affected GoDoc, and release notes should describe
+the implemented inspection change and its limits. Architecture wording should
+reflect the callback flow without turning implementation details into contracts.