eric/ConfigKit
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Plan the ConfigKit consolidation sprint

Browse Source
This commit is contained in:
Eric Rakestraw
2026-10-25 12:14:01 +00:00
parent 8a99e61070
commit 8ab1568352
2 changed files with 643 additions and 31 deletions
Download Patch File Download Diff File Expand all files Collapse all files

41
docs/roadmap/consolidation.md
View File

@@ -1,9 +1,9 @@
# ConfigKit Consolidation Toward 1.0
Status: proposed scope and target state for review. This document recommends
refactors; it does not record implementation progress or authorize a release.
The scope questions are settled. Prepare the staged implementation plan after
reviewing this roadmap.
Status: selected target state; implementation pending. This document defines the
refactor's scope and rationale; it does not authorize a release. The scope
questions are settled. The [implementation plan](implementation.md) owns the
concrete steps, sequencing, and implementation progress.
## Purpose
@@ -281,9 +281,9 @@ the value, including retained underlay and inherited values. Use the acquired
source's canonical identity where available. Preserve containment failures,
source associations, deferred search bases, and terminal selected-file errors.
Implement this work alongside acquisition consolidation so the same callers are
not redesigned twice. The description is private; it does not replace the public
`FilesystemContext` or `ResourceContext` contracts.
Acquisition and context handling use the same private handoff rather than
maintaining parallel models for overlapping callers. The description does not
replace the public `FilesystemContext` or `ResourceContext` contracts.
### 3. Make Inheritance Combination Results Explicit
@@ -411,27 +411,6 @@ is otherwise ready. Future performance experiments remain in
[future.md](future.md#3-performance-experiments); no benchmark campaign was run
or is required to claim readability improvements.
## Recommended Work Order
This is dependency guidance for the later plan, not a commit-by-commit schedule:
1. Confirm the implementation baseline and settled scope; map
retained behavior to existing tests and record concrete coverage gaps.
2. Remove unused reverse inspection conversions and adjust their tests. This is
small and independently reviewable.
3. Normalize acquisition inputs and separate import-default ownership. Develop
the resolved-context handoff with those callers, preserving validation and
closure timing; then separate acquisition, item assembly, and evidence work.
4. Refactor inheritance around explicit preparation and combination results,
retaining completed correctness and algorithmic regressions.
5. Refactor projection and schema field assembly in separate reviewable changes.
6. Consolidate real facade adapters, finish consumer/internal navigation, and run
the applicable integration and ownership checks on the combined result.
Steps 4 and 5 have no necessary implementation dependency on each other. Keep
correctness fixes discovered during refactoring identifiable with their own
regression evidence rather than hiding behavior changes inside code movement.
## Validation And Completion
Use the [development guide](../development.md) and
@@ -477,9 +456,9 @@ Completion requires reviewable evidence that:
- Consumer guidance, contributor references, and internal documentation describe
the resulting implementation. Current contracts continue to own behavior.
Private type/helper names, final file splits, and exact stage boundaries belong
in the implementation plan. No open scope questions remain, and no additional
feature semantics are needed to carry out the recommended refactors.
The [implementation plan](implementation.md) defines private records, file owners,
and stage boundaries. No open scope questions remain, and no additional feature
semantics are needed to carry out the selected refactors.
## Settled Decisions