base-layer/commandkit
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 2 Wiki Activity

Record alias tree decision and private refactoring analysis

Browse Source
This commit is contained in:
Eric Rakestraw
2026-11-07 14:52:56 +00:00
parent 485a27a662
commit c7f898e56e
2 changed files with 114 additions and 15 deletions
Download Patch File Download Diff File Expand all files Collapse all files

25
docs/roadmap/audit/catalog.md
View File

@@ -245,10 +245,17 @@ The source declarations contain only Θ(RD) tokens.
Traverse distinct source prefixes once and classify each once. For the audited
shape, this phase can become O(RD + D²).
**Decision:** design F14 and F15 together around shared source-prefix processing,
preferably reusing the existing alias source structure rather than adding parallel
indexes. The repeated preparation and help-time scan remain distinct findings.
The performance-testing decision under F13 applies to both.
**Decision:** implement F14 and F15 together using the existing alias resolver's
source-path tree. Add narrow internal read-only operations to enumerate distinct
nonempty proper prefixes for F14 and find strictly descendant alias sources for
F15. Retain the existing discovery classification and exclusions, applying them
once per candidate prefix.
Reuse the tree's routing-snapshot lifetime; do not introduce a parallel index or
a cross-invocation result cache. The repeated preparation and help-time scan
remain distinct findings. The [joint analysis](remediation-analysis.md#f14f15--joint-source-prefix-design)
records the accepted design. The performance-testing decision under F13 applies
to both; implementation remains pending.
**Original:** [02-efficiency E3](02-efficiency.md#e3--p3-discovery-context-preparation-rebuilds-shared-prefixes-repeatedly).
@@ -259,8 +266,14 @@ examinations and repeated copies even when there are no descendants. A valid
single-token alias chain produces Θ(A²) work to discover an empty alias section
on every such help request.
Query an immutable source-prefix index for strict descendants. The identified
discovery work becomes O(A) for that example; general cases still pay for
**Decision:** query the existing resolver tree for strict descendants through
the internal operation shared with F14's design. Continue visiting intermediate
resolution paths, resolving composed entered paths through the existing
resolver, and retaining canonical-target checks, suffix deduplication, and
output sorting. Root help may retain the complete catalog when all entries are
needed. No public API or CLI behavior change is selected.
The identified discovery work becomes O(A) for that example; general cases still pay for
matching candidates, resolution, and output sorting. Design this together with
F14 under the decisions recorded there and in F13.