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

Retire the completed clone traversal review

Browse Source
This commit is contained in:
Eric Rakestraw
2026-10-25 14:58:56 +00:00
parent 8dfaf44d1d
commit 5e12b2d360
6 changed files with 44 additions and 65 deletions
Download Patch File Download Diff File Expand all files Collapse all files

33
docs/roadmap/future.md
View File

@@ -83,36 +83,3 @@ evidence are preserved in Git history at `8e91a2b` under `docs/roadmap/`.
across loads without introducing aliasing?
- What cache lifetime and concurrency design would make schema reuse worthwhile
without excessive retained memory?
## 4. Clone traversal review
Status: deferred. Review typed configuration cloning after the projection and
schema consolidation work, when the resulting structure can inform the review.
This is future maintenance work, not a prerequisite for completing consolidation.
The complexity audit identified `valueOperation.clone` in
[clone.go](../../internal/engine/clone.go) as a candidate for cleanup. Much of its
size is straightforward type dispatch. Focused handlers may clarify allocation,
recursive copying, cycle tracking, secret-state handling, or text-codec
reconstruction, but extraction may also add indirection without making the code
easier to understand.
When this work is taken up, assess the traversal and record whether changes are
worthwhile; a conclusion that no refactor is needed is valid. Make focused
changes only where the maintenance benefit justifies the code movement. Keep
cloning's typed-copy semantics distinct from projection's document-building
semantics. Preserve detached values, nil/empty distinctions, physical inline
fields, cycle/depth checks, and unresolved versus validated secret handling.
Reuse existing ownership, codec, secret, and traversal tests, adding coverage for
consequential gaps. No performance improvement is assumed.
### Questions to resolve before implementation
- After projection and schema consolidation, which clone branches still mix
responsibilities enough to benefit from extraction?
- Would a proposed helper keep allocation, recursive copying, and cycle cleanup
easier to follow together, or merely move a short loop out of sight?
- Are any small shared operations semantically identical across traversals, or
would sharing require special cases that obscure their different purposes?
- Which ownership or special-value risks, if any, lack sufficient existing test
coverage for the proposed changes?