Plan discovery and facade boundary refactoring
This commit is contained in:
File diff suppressed because it is too large
Load Diff
@@ -1,6 +1,6 @@
|
|||||||
# Import Discovery And Facade Boundary Simplification
|
# 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`.
|
Baseline: `80cf23e7102fca2c5d7c7621e75f930a1ef1ecad`.
|
||||||
|
|
||||||
This roadmap brings together the two refactors deferred until after the audit
|
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
|
The goal is clearer responsibility and ownership with fewer redundant internal
|
||||||
representations. Both changes preserve the public API and configuration model.
|
representations. Both changes preserve the public API and configuration model.
|
||||||
They are independent work areas within one maintenance effort, not a new loading
|
They are independent work areas within one maintenance effort, not a new loading
|
||||||
workflow. A subsequent implementation plan will own concrete edits, stages,
|
workflow. The [implementation plan](implementation.md) owns concrete edits,
|
||||||
validation commands, and execution progress.
|
stages, validation commands, and execution progress.
|
||||||
|
|
||||||
## Baseline And Targeted End State
|
## 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
|
to maintain. Reduced copying is useful but does not establish an end-to-end
|
||||||
performance guarantee.
|
performance guarantee.
|
||||||
|
|
||||||
## Implementation And Documentation Work
|
## Documentation Ownership
|
||||||
|
|
||||||
The later plan should identify the glob extraction boundary and map the defaults
|
Internal documentation describes the resulting discovery and transport
|
||||||
and placement ownership handoffs against current callers before changing them.
|
boundaries once implemented. Public declarations continue to own the existing
|
||||||
The two refactors can be implemented and reviewed independently; neither needs
|
snapshot and type contracts; this effort selects no new public behavior.
|
||||||
the other to land. Retire replaced private representations and helpers together
|
The corresponding C03/F07 future-work entries serve as navigation to this
|
||||||
with their callers rather than adding a second production path.
|
roadmap rather than parallel target or progress inventories. Unrelated future
|
||||||
|
candidates remain separate. The implementation plan owns the documentation
|
||||||
Update internal documentation when the resulting boundaries land. Public
|
updates and retirement of replaced private representations and helpers.
|
||||||
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.
|
|
||||||
|
|
||||||
## Validation And Completion
|
## Validation And Completion
|
||||||
|
|
||||||
|
|||||||
Reference in New Issue
Block a user