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

Plan discovery and facade boundary refactoring

Browse Source
This commit is contained in:
Eric Rakestraw
2026-10-26 00:03:02 +00:00
parent bb5540b62e
commit b1d89810ca
2 changed files with 277 additions and 1158 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1408
docs/roadmap/implementation.md
View File

File diff suppressed because it is too large Load Diff

27
docs/roadmap/internal-boundaries.md
View File

@@ -1,6 +1,6 @@
# Import Discovery And Facade Boundary Simplification
Status: target defined; staged implementation planning pending.
Status: target defined; execution is tracked in the [implementation plan](implementation.md).
Baseline: `80cf23e7102fca2c5d7c7621e75f930a1ef1ecad`.
This roadmap brings together the two refactors deferred until after the audit
@@ -13,8 +13,8 @@ entries and the [consolidated audit](audit.md).
The goal is clearer responsibility and ownership with fewer redundant internal
representations. Both changes preserve the public API and configuration model.
They are independent work areas within one maintenance effort, not a new loading
workflow. A subsequent implementation plan will own concrete edits, stages,
validation commands, and execution progress.
workflow. The [implementation plan](implementation.md) owns concrete edits,
stages, validation commands, and execution progress.
## Baseline And Targeted End State
@@ -145,20 +145,15 @@ The intended benefit is fewer concepts, field mappings, and construction paths
to maintain. Reduced copying is useful but does not establish an end-to-end
performance guarantee.
## Implementation And Documentation Work
## Documentation Ownership
The later plan should identify the glob extraction boundary and map the defaults
and placement ownership handoffs against current callers before changing them.
The two refactors can be implemented and reviewed independently; neither needs
the other to land. Retire replaced private representations and helpers together
with their callers rather than adding a second production path.
Update internal documentation when the resulting boundaries land. Public
declaration wording needs changes only if required to keep its existing
ownership description accurate; this effort does not select new public behavior.
Replace the corresponding C03/F07 candidate detail in `future.md` with a pointer
to the active work when the planning records are reorganized, avoiding parallel
target or progress inventories. Leave the unrelated future candidates alone.
Internal documentation describes the resulting discovery and transport
boundaries once implemented. Public declarations continue to own the existing
snapshot and type contracts; this effort selects no new public behavior.
The corresponding C03/F07 future-work entries serve as navigation to this
roadmap rather than parallel target or progress inventories. Unrelated future
candidates remain separate. The implementation plan owns the documentation
updates and retirement of replaced private representations and helpers.
## Validation And Completion