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

Plan the audit remediation sprint

Browse Source
This commit is contained in:
Eric Rakestraw
2026-10-25 20:52:11 +00:00
parent 4a5316b7fc
commit 7889ebddfb
2 changed files with 955 additions and 51 deletions
Download Patch File Download Diff File Expand all files Collapse all files

82
docs/roadmap/roadmap.md
View File

@@ -1,23 +1,22 @@
# Audit Remediation Roadmap
Status: scope settled; implementation has not begun.
Status: target accepted; execution is tracked in the [implementation plan](implementation.md).
Prepared: 2026-10-25. Planning baseline: `e1e94ee`.
This roadmap describes the target state and dependency order for the 29 entries
This roadmap describes the target state and related work for the 29 entries
selected in the [consolidated audit review](audit.md#settled-scope-decisions).
It is intended for maintainers preparing the implementation plan.
It is intended for maintainers reviewing the remediation's scope and architecture.
## Document Ownership
- [audit.md](audit.md) owns finding IDs, original evidence, detailed remedies and
acceptance cases, and the settled scope decisions. Its evidence has not been
independently reproduced by writing this roadmap.
- This document owns the combined target state, work areas, and high-level
dependencies. Finding IDs below provide traceability without repeating the
full audit inventory.
- The subsequent implementation plan will own concrete stages, edits, validation
commands, and execution progress. It should carry the selected IDs through to
completion evidence.
- This document owns the combined target state, work areas, and design intent.
Finding IDs below provide traceability without repeating the full audit inventory.
- The [implementation plan](implementation.md) owns concrete stages, private
implementation choices, edits, validation commands, and execution progress.
It carries the selected IDs through to completion evidence.
The [configuration contract](../config.md), public Go declarations, and
[architecture policy](../policy/architecture.md) remain the owners of behavior
@@ -79,9 +78,9 @@ check after the reservation does not address the reported failure. This work
does not introduce a general heap limit or reject large containers independently
of existing budgets.
Once failed construction is safe, memoize completed successful dynamic-type
eligibility checks within the value operation. Keep failure diagnostics specific
to their current path and distinguish completed results from traversal visits.
Dynamic-type eligibility reuse depends on safe descriptor construction and retains
completed successful checks within the value operation. Keep failure diagnostics
specific to their current path and distinguish completed results from traversal visits.
This removes repeated descriptor-graph walks without a cross-load cache.
### 2. Callback, Filesystem, And Dependency Lifetimes
@@ -170,7 +169,7 @@ actual composition boundary explicitly. Retire the parallel test-only import
parser and route relevant fixtures through the active directive parser or the
appropriate declaration boundary, retaining malformed-input coverage.
Then clarify active acquisition and coordinator handoffs around cohesive tasks:
Clarify active acquisition and coordinator handoffs around cohesive tasks:
parsed-input directive/version handling, standalone placement, and repeated tier
application/projection. Use explicit inputs and results consistent with existing
state owners. Extracting helpers that continue to share surrounding mutable state
@@ -226,61 +225,42 @@ ownership, and lifecycle behavior. Preserve distinct integration risks and
reader-byte snapshot coverage. Existing coverage percentages or a desired test
count are not acceptance criteria for this work.
## General Implementation Order
## Implementation Plan
Begin with a focused implementation plan that maps each selected ID to its owning
change and validation. Establish regression evidence alongside fixes, using the
audit's bounded cases. Prioritize reported defects; small prerequisite cleanups
may accompany them, and broader refactoring must not hold up a consequential fix.
| Order or dependency | Reason |
| --- | --- |
| Repair dynamic descriptor construction (A02) before successful eligibility reuse (A05). | Reuse must not amplify partial descriptor state. |
| Address callback state and owned-root cleanup (B01/B02) with separate acceptance checks. | They can proceed together or independently, but both lifetimes need protection. |
| Strengthen directory error/handle assertions with C01; remediate C02 independently of deferred glob extraction. | Tests must expose the lost failure phase, and the availability fix needs no broader traversal refactor. |
| Remove unused history copies (D02/D03) and clarify retained combination evidence (D04) before finalizing complete history accounting (D01). | Account for the graph actually retained, while keeping all required evidence. These changes may be delivered together. |
| Establish collection-policy state/evidence ownership (E03) before or together with localized retirement and copying changes (E01/E02). | Efficiency changes depend on knowing which state can be read, changed, and retained. Preserve separate behavioral and scaling acceptance cases. |
| Remove the eager test-only protocol and parallel parser (F01/F03) before or alongside active acquisition extraction (F02). | Refactor the production protocol and migrate tests to it without carrying redundant paths forward. |
| Establish replacement public coverage (F09 and relevant F12 cases) before deleting disconnected clone tests and facade scaffolding (F04/F12). | Cleanup should preserve useful protection while removing incidental assertions. |
| Complete integration review after the affected owners settle. | Check agreement among final values, metadata, replay, diagnostics, and resource accounting across the changed boundaries. |
These are dependency constraints, not barriers requiring every work area to finish
before another starts. Independent traversal fixes, local lookup improvements,
and bounded helper/member cleanup can proceed as their owners are ready. Coordinate
changes that touch the same state: A01 with schema-path member cleanup, D04 with
history and collection evidence, and acquisition cleanup with version and resource
lifetime handling.
The [implementation plan](implementation.md) defines the sequential, Luna-scoped
stages and their dependencies, including coordinated changes to descriptor state,
history ownership/accounting, collection policy, acquisition, and replacement
public coverage. It also owns validation commands and the complete finding-to-stage
map. The audit remains the owner of original evidence and detailed acceptance cases.
## Validation And Completion
Use the audit's detailed acceptance cases and the [testing policy](../policy/testing.md)
to prepare focused validation. For fatal or hanging regressions, use bounded
Validation follows the audit's detailed acceptance cases and the
[testing policy](../policy/testing.md). For fatal or hanging regressions, use bounded
subprocesses; for budget cases, use small controlled limits. For symlink expansion
and repeated lookup work, prefer bounded operation evidence and algorithm review
over timing thresholds. Use real filesystem fixtures where filesystem semantics
matter and narrow fault injection for read/close failures. State platform limits.
Run the applicable development checks from the [development guide](../development.md)
as implementation proceeds, including appropriate race coverage for changed
ownership and lifetime boundaries. Existing audit results are baseline evidence,
not validation of the eventual changes. No performance benchmark campaign is
Applicable development checks come from the [development guide](../development.md),
including appropriate race coverage for changed ownership and lifetime boundaries.
The implementation plan owns their execution. Existing audit results are baseline
evidence, not validation of the eventual changes. No performance benchmark campaign is
required by this roadmap, and no new benchmark results are claimed.
Completion means all 29 selected findings have implementation and acceptance
evidence, the affected public behavior remains consistent with its contracts,
and canonical internal documentation describes the resulting owners. Carry
status in the audit until the implementation plan takes over execution tracking;
avoid maintaining duplicate progress inventories. Retire completed planning
records under the normal documentation lifecycle.
and canonical internal documentation describes the resulting owners. The
implementation plan owns execution status without duplicate progress inventories.
Retire completed planning records under the normal documentation lifecycle.
## Scope Boundaries And Decision Status
All three audit scope questions are settled. No significant architectural or
product decision remains open for this roadmap. Private choices such as staging
versus rollback, index representation, or helper signatures belong in the
implementation plan and review, subject to the acceptance cases above. If that
work exposes a need to change a public contract, bring the specific decision back
for review rather than treating it as an implicit part of remediation.
product decision remains open for this roadmap. The implementation plan records
private design choices and sequencing, subject to the acceptance cases above.
If that work exposes a need to change a public contract, bring the specific
decision back for review rather than treating it as an implicit part of remediation.
The glob preparation refactor (C03) and wider facade transport simplification
(F07) remain the first two entries in [future.md](future.md), for consideration