@reicek/neataptic-ts 0.1.26 → 0.1.27

package/.github/skills/trace-audit-reporting/references/trace-analysis-workflow.md

@@ -129,4 +129,4 @@ Good reasons to extend it:
 Poor reasons to extend it:
 
 - one-off formatting preference,
-- data that can already be inferred from the existing sections.
+- data that can already be inferred from the existing sections.

package/.github/skills/tracker-handoff/SKILL.md

@@ -12,8 +12,9 @@ Use this skill when work needs durable continuity in markdown tracker files.
 
 This skill is the canonical workflow for `.plans.md` and `.logs.md` structure in
 NeatapticTS. It owns the tracker status markers, compression rules for old work,
-and the required `Handoff query` section that makes WIP sessions safe to resume
-with a simple copy-paste prompt.
+the required `Handoff query` section that makes WIP sessions safe to resume
+with a simple copy-paste prompt, and the terminal closure rule for finished
+plans.
 
 Other skills may decide when a tracker should be updated, but they should defer
 the tracker shape itself to this skill instead of redefining status markers,
@@ -38,6 +39,22 @@ handoff layout, or history-compression rules ad hoc.
 - Use `.logs.md` for compressed done-state records and completed work that no
   longer needs active session guidance.
 
+### Completion Closure Rule
+
+When a workstream becomes fully complete, the final tracker step is always to
+close it deliberately.
+
+- Compress the completed `.plans.md` file into a short closed tracker that
+  preserves only the durable reopen-point context.
+- Add or update a same-boundary `.logs.md` file with the durable done-state
+  record.
+- Remove active-session scaffolding that no longer applies, especially stale
+  `Remaining gaps`, `Next step`, or `Handoff query` sections.
+- Do not preserve or emit a next-session handoff prompt on a fully closed plan
+  unless the user explicitly asks for reopen guidance.
+- If there is still a real next step from the plan's own context, the plan is
+  not closed yet and should stay active with a `Handoff query`.
+
 ### Status Markers
 
 Every durable tracker should use the same three states:
@@ -71,14 +88,17 @@ The section should:
 
 Preferred shape:
 
-```md
+````md
 ## Handoff query
 
 ```text
 Continue from the current repo state only. Do not rely on prior chat history.
 <workstream-specific continuation prompt>
 ```
-```
+````
+
+Closed `.plans.md` files should normally omit `Handoff query` because the plan
+has no in-context follow-up step left to hand off.
 
 ### Compression Rules
 
@@ -90,6 +110,13 @@ When a tracker grows too long:
 - remove repetitive validation transcripts once the result is captured,
 - prefer concise extent statements over narrative replay.
 
+When a plan reaches terminal `[DONE]` state:
+
+- compress the plan before considering the workstream finished,
+- add or refresh the same-boundary `.logs.md` audit record,
+- keep a short closed tracker focused on scope, final state, audit summary,
+  reopen conditions, and the audit-log pointer.
+
 Good completed note:
 
 - `[DONE] Runtime diagnostics moved to runtime chapter; Network now delegates DropConnect, dropout reset, and training-health readers.`
@@ -120,6 +147,18 @@ For most `.plans.md` files, prefer this shape:
 Not every plan needs every section, but active plans should remain compact,
 forward-looking, and resumable.
 
+## Recommended Closed Plan Shape
+
+For terminally closed `.plans.md` files, prefer this shape:
+
+1. `# <Workstream name>`
+2. `**Status:** [DONE]`
+3. `## Scope`
+4. `## Final state`
+5. `## Audit summary`
+6. `## Reopen conditions`
+7. `## Audit log`
+
 ## Recommended Log Shape
 
 For `.logs.md` files, prefer:
@@ -128,6 +167,8 @@ For `.logs.md` files, prefer:
 2. `**Status:** [DONE]` or `[WIP]` when still accumulating done-state records
 3. short done-state entries grouped by durable milestone
 4. no active TODO list unless the file is intentionally dual-purpose
+5. the same boundary as the closed `.plans.md` file whenever the workstream is
+  complete
 
 ## Guardrails
 
@@ -138,6 +179,10 @@ For `.logs.md` files, prefer:
 - Do not bury the next-session continuation prompt in prose.
 - Do not leave a `.plans.md` file without a `Handoff query` section when the
   workstream is still active.
+- Do not mark a workstream `[DONE]` and stop before compressing the plan and
+  adding or updating the same-boundary `.logs.md` file.
+- Do not leave a stale `Handoff query` on a fully closed plan unless the user
+  explicitly wants reopen guidance.
 - Do not preserve detailed historical narration when compact coverage notes are
   enough to prevent re-exploration.
 - Do not rewrite generated README files just to record progress; use trackers.
@@ -150,4 +195,7 @@ A strong tracker update should report:
 - whether it is now `[PLANNED]`, `[WIP]`, or `[DONE]`,
 - what historical content was compressed,
 - what the new active frontier is,
-- whether a `Handoff query` section was added or refreshed.
+- whether a `Handoff query` section was added, refreshed, or intentionally
+  removed because the plan was terminally closed,
+- whether a same-boundary `.logs.md` file was added or refreshed.
+```

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@reicek/neataptic-ts",
-  "version": "0.1.26",
+  "version": "0.1.27",
   "description": "Architecture-free neural network library with genetic algorithm implementations",
   "main": "./dist/neataptic.js",
   "module": "./dist/neataptic.js",

package/plans/Flappy_Bird_Folder_Documentation_Pass.logs.md

@@ -0,0 +1,42 @@
+# Flappy Bird Folder Documentation Pass Log
+
+**Status:** [DONE]
+
+## Audit scope
+
+- Objective: raise the educational quality of the Flappy Bird folder README
+  openings without hand-editing generated README output.
+- The pass covered the root-to-leaf reading path across the example's trainer,
+  simulation, worker, and browser-entry documentation surfaces.
+
+## Durable milestones
+
+### [DONE] Folder inventory and route closure
+
+- Reviewed the tracked Flappy Bird README-owning folders explicitly rather than
+  treating the example as a single coarse documentation surface.
+- Closed the reading route from the example root through the system chapters so
+  a new reader can follow training, simulation, and browser playback flow.
+
+### [DONE] Source-owned intro remediation
+
+- Strengthened the chapter openings that needed better source-owned framing.
+- Corrected generated intro ownership with targeted `docs.order.json` controls
+  where a types shelf or weak facade was producing the wrong opening.
+
+### [DONE] Worker and browser-entry documentation alignment
+
+- Fixed worker-boundary and browser-entry framing so the generated docs better
+  explain host/runtime/message ownership instead of just listing symbols.
+
+## Controls and evidence
+
+- Generated README surfaces stayed read-only.
+- Source-affecting passes were validated with `npm run docs` and
+  `npx tsc --noEmit -p tsconfig.json`.
+
+## Reopen triggers
+
+- Flappy Bird chapter openings drift below the current educational-docs bar.
+- A changed or new boundary needs fresh intro-owner mapping.
+- Generated chapter ownership regresses and needs new ordering controls.

package/plans/Flappy_Bird_Folder_Documentation_Pass.md

@@ -2,116 +2,34 @@
 
 **Status:** [DONE]
 
-## Purpose
+## Scope
 
-Run a folder-focused documentation pass across every README-owning folder under
-`test/examples/flappy_bird` so the generated documentation reads like a guided
-tour of the example architecture rather than a sparse export inventory.
+- Educational-docs pass across the README-owning Flappy Bird example folders.
+- Source-first only: generated surfaces stayed read-only and intro ownership
+  was corrected in source files or `docs.order.json` controls.
 
-## Root
+## Final state
 
-- Split root: `test/examples/flappy_bird`
-- README inventory: 24 README-owning folders under the root
-- Nearest README reviewed: `test/examples/flappy_bird/README.md`
-- Parent README reviewed: `test/examples/README.md` if needed per step
-- Relevant plan: `plans/Interactive_Examples_and_Learning_Path.md`
+- The tracked Flappy Bird example folders were reviewed and the weak chapter
+  openings were strengthened from their source owners.
+- The documentation path from root example overview through trainer,
+  simulation, worker, and browser-entry chapters now reads coherently.
+- No active backlog remains in this workstream; this file is now a reopen point
+  for future Flappy Bird documentation drift only.
 
-## Durable Rules
+## Audit summary
 
-- Keep the README inventory explicit and visible in the todo list.
-- Keep exactly one active README or README-owning folder at a time.
-- Do not hand-edit generated subfolder README files; improve source JSDoc and
-  regenerate docs.
-- Keep compatibility facades documented as facades, not as implementation sinks.
-- Prefer educational JSDoc that explains what, why, invariants, defaults, and
-  performance tradeoffs when those details help a learner understand the example.
+- Source-affecting passes regenerated docs with `npm run docs`.
+- Source-affecting passes validated types with
+  `npx tsc --noEmit -p tsconfig.json`.
 
-## Target Shape
+## Reopen conditions
 
-- Each README-owning folder has source JSDoc rich enough to generate a useful
-  README without manual rescue edits.
-- Compatibility facades explain where deeper responsibilities live.
-- Browser, evaluation, simulation, worker, and trainer boundaries read like a
-  coherent architecture map when browsed top-down.
+- Flappy Bird README openings drift back below the current documentation bar.
+- A new Flappy Bird example boundary needs chapter-level intro ownership work.
+- Generated README ownership needs another `docs.order.json` correction.
 
-## Steps
+## Audit log
 
-- [x] Step 1: Tidy the root `test/examples/flappy_bird` surface and verify the
-      README inventory-driven workflow.
-- [x] Step 2: Tidy the worker and trainer-facing folders.
-- [x] Step 3: Tidy shared simulation, environment, constants, and evaluation
-      folders.
-- [x] Step 4: Tidy browser-entry and its nested README-owning folders one by one.
-- [x] Step 5: Regenerate docs, run focused validation, and record any durable
-      boundary notes that changed during the pass.
-
-## Step 1 Inventory
-
-- [x] `test/examples/flappy_bird`
-
-## Step 2 Inventory
-
-- [x] `test/examples/flappy_bird/trainer`
-- [x] `test/examples/flappy_bird/trainer/evaluation`
-- [x] `test/examples/flappy_bird/flappy-evolution-worker`
-
-## Step 3 Inventory
-
-- [x] `test/examples/flappy_bird/constants`
-- [x] `test/examples/flappy_bird/environment`
-- [x] `test/examples/flappy_bird/evaluation`
-- [x] `test/examples/flappy_bird/evaluation/rollout`
-- [x] `test/examples/flappy_bird/simulation-shared`
-- [x] `test/examples/flappy_bird/simulation-shared/observation`
-
-## Step 4 Inventory
-
-- [x] `test/examples/flappy_bird/browser-entry`
-- [x] `test/examples/flappy_bird/browser-entry/host`
-- [x] `test/examples/flappy_bird/browser-entry/host/resize`
-- [x] `test/examples/flappy_bird/browser-entry/network-view`
-- [x] `test/examples/flappy_bird/browser-entry/playback`
-- [x] `test/examples/flappy_bird/browser-entry/playback/background`
-- [x] `test/examples/flappy_bird/browser-entry/playback/background/ground-grid`
-- [x] `test/examples/flappy_bird/browser-entry/playback/frame-render`
-- [x] `test/examples/flappy_bird/browser-entry/playback/snapshot`
-- [x] `test/examples/flappy_bird/browser-entry/playback/trail`
-- [x] `test/examples/flappy_bird/browser-entry/playback/worker-channel`
-- [x] `test/examples/flappy_bird/browser-entry/runtime`
-- [x] `test/examples/flappy_bird/browser-entry/visualization`
-- [x] `test/examples/flappy_bird/browser-entry/worker-channel`
-
-## Latest Pass
-
-### Goals
-
-- Run a final pedagogical audit of the full Flappy Bird example.
-- Close the last remaining chapter-opening gap before finalizing the pass.
-
-### Progress
-
-- Re-audited the root, trainer, browser-entry, and worker-facing generated
-  READMEs against the guided-tour bar.
-- Found one remaining worker-boundary drift where the generated README opened on
-  a constant shelf instead of the worker entrypoint.
-- Added a file-level worker chapter intro and `docs.order.json` source mapping
-  so `flappy-evolution-worker/README.md` now opens on the worker boundary.
-- Ran `npx tsc --noEmit -p tsconfig.json` and `npm run docs` after the edits.
-- Re-read the regenerated worker README and confirmed the full 24-folder README
-  inventory now reads coherently top-down.
-- No durable boundary notes changed during the pass; the work stayed within the
-  existing module boundaries and documentation source map.
-
-### Decision
-
-- The Flappy Bird folder documentation pass is complete and now meets the
-  end-to-end pedagogical bar for the example.
-
-## Done Criteria
-
-- Every README-owning folder in the inventory has been handled explicitly.
-- Generated README content is educational and boundary-aware.
-- The todo list reflects completion folder by folder.
-- Docs regeneration succeeds after documentation-affecting changes.
-- A later session can resume from this plan and the todo list without prior chat
-  history.
+- Durable completion notes now live in
+  [Flappy_Bird_Folder_Documentation_Pass.logs.md](Flappy_Bird_Folder_Documentation_Pass.logs.md).

package/plans/README.md

@@ -13,6 +13,8 @@ Status convention:
 - Every roadmap-tracked plan file should expose a top-level status line immediately under the title.
 - Use the exact format `**Status:** [DONE]`, `**Status:** [WIP]`, or `**Status:** [PLANNED]`.
 - Keep that top-level status aligned with [plans/Roadmap.md](Roadmap.md), which is the authoritative source for cross-plan sequencing and active priority.
+- Completed plans should prefer a short closed tracker plus a same-boundary
+  `.logs.md` companion file for audit history and durable milestone evidence.
 - Detailed phase-local status notes can still appear deeper in a plan when they add useful implementation detail.
 
 Recommended reading order:
@@ -26,7 +28,7 @@ Recommended reading order:
 Selection guide:
 
 - `plans/analyze-trace-solid-split.plans.md`: completed trace-analyzer tooling split and reopen point for future script-boundary work.
-- `plans/architecture-solid-split.plans.md`: active architecture folderization and boundary-ownership cleanup across `src/architecture`.
+- `plans/architecture-solid-split.plans.md`: completed architecture folderization and docs follow-through baseline, kept as the reopen point for future facade-removal or ownership audits in `src/architecture`.
 - `plans/neat.plans.md`: core NEAT correctness, innovation tracking, crossover alignment, speciation invariants.
 - `plans/Roadmap.md`: dependency-aware execution order across all initiatives.
 - `plans/Architecture_Primitives_Node_Group_Layer.md`: first-class architecture-building primitives such as nodes, groups, and layers.
@@ -42,7 +44,8 @@ Selection guide:
 - `plans/Memory_Optimization.md`: scaling, memory layout, and strategies for very large networks.
 - `plans/methods-docs.plans.md`: completed educational-docs lane for `src/methods` and reopen point for methods documentation drift.
 - `plans/methods-solid-split.plans.md`: completed structural split lane for `src/methods` and reopen point for later refactors.
-- `plans/neat-docs.plans.md`: active educational-docs lane for NEAT surfaces and generated README quality.
+- `plans/neat-docs.plans.md`: completed educational-docs baseline for root-facing NEAT surfaces, kept as the reopen point for future README-opening drift or generator-ordering regressions.
+- `plans/readme-first-section-pass.plans.md`: completed repo-wide README-opening baseline across `src/` and `test/examples/`; use the matching `.logs.md` file for audit history and reopen the plan only if a changed boundary or new README surface reopens the lane.
 - `plans/neat-test-surface-repair.plans.md`: completed NEAT public test-surface repair baseline and reopen point for future compatibility regressions.
 - `plans/Network_Visualization_Export_Schema.md`: stable export schema for visualization and inspection tooling.
 - `plans/ONNX_EXPORT_PLAN.md`: ONNX export/import architecture and rollout phases.
@@ -73,6 +76,7 @@ Task-to-plan trigger phrases:
 - methods docs, methods README quality, educational-docs for methods: `plans/methods-docs.plans.md`
 - methods split, `src/methods` refactor, methods folderization: `plans/methods-solid-split.plans.md`
 - NEAT docs, generated README quality, NEAT documentation lane: `plans/neat-docs.plans.md`
+- README opening, first section, chapter intro quality, repo-wide README openings, `src` plus `test/examples` docs pass: `plans/readme-first-section-pass.plans.md`
 - NEAT test surface, public type compatibility, root facade repair: `plans/neat-test-surface-repair.plans.md`
 - explicit any, no-explicit-any, strict typing, src lint cleanup follow-up, reopen completed cleanup lane: `plans/src-no-explicit-any-cleanup.plans.md`
 - HTML docs renderer, sidebar, Mermaid validation, docs site tooling split: `plans/render-docs-html-solid-split.plans.md`

package/plans/Roadmap.md

@@ -19,15 +19,18 @@ Where it helps, this roadmap uses **lanes** (things that can proceed in parallel
 - `asciiMaze` SOLID split before ES2023 modernization [DONE]
 - `flappy_bird` reference demo split and documentation baseline [DONE]
 - Main app NEAT surface is already SOLID split [DONE]
-- Educational documentation and split follow-through lane [WIP]
+- Educational documentation and split follow-through lane [DONE]
   - [Flappy_Bird_Folder_Documentation_Pass.md](Flappy_Bird_Folder_Documentation_Pass.md) [DONE]
-  - [architecture-solid-split.plans.md](architecture-solid-split.plans.md) [WIP]
+  - [architecture-solid-split.plans.md](architecture-solid-split.plans.md) [DONE]
   - [methods-solid-split.plans.md](methods-solid-split.plans.md) [DONE]
   - [methods-docs.plans.md](methods-docs.plans.md) [DONE]
-  - [neat-docs.plans.md](neat-docs.plans.md) [WIP]
+  - [neat-docs.plans.md](neat-docs.plans.md) [DONE]
+  - [readme-first-section-pass.plans.md](readme-first-section-pass.plans.md) [DONE]
   - [utils-docs.plans.md](utils-docs.plans.md) [DONE]
   - Both demos are now solid split and the Flappy Bird documentation pass is complete enough to stop being a documentation blocker.
-  - The remaining structural polish in Phase 0 is the broader educational-docs lane outside methods, the architecture folderization pass, and the repository-wide modernization pass with their validation gate.
+  - The architecture split follow-through and the NEAT educational-docs lane are now also complete enough to stop being Phase 0 blockers.
+  - The repo-wide README first-section pass is now closed across the tracked README surfaces under `src/` and `test/examples/`.
+  - The remaining structural polish in Phase 0 is the repository-wide modernization pass plus its validation gate.
 - Supporting repair and docs-tooling stabilization lane [DONE]
   - [neat-test-surface-repair.plans.md](neat-test-surface-repair.plans.md) [DONE]
   - [asciiMaze-typescript-repair.plans.md](asciiMaze-typescript-repair.plans.md) [DONE]
@@ -162,7 +165,7 @@ This plan is large and can run as a **parallel lane** after Phase 1, but it shou
 
 ## Summary: Critical Path vs Parallel Lanes
 
-Current status: the project is still in **Phase 0**, with both demos solid split and documented, the example learnability pass now materially strengthened across `test/examples`, the Flappy Bird documentation pass now closed, the main app already solid split, the architecture split pass now active, the broader educational documentation lane still in progress outside Flappy Bird, the `src/` strict-typing cleanup now closed as a completed baseline, and repository-wide ES2023 modernization still remaining in the Phase 0 lane.
+Current status: the project is still in **Phase 0**, with both demos solid split and documented, the example learnability pass materially strengthened across `test/examples`, the Flappy Bird documentation pass now closed, the main app already solid split, the architecture split follow-through now closed, the broader educational documentation lane now closed including the repo-wide README first-section pass, the `src/` strict-typing cleanup now closed as a completed baseline, and repository-wide ES2023 modernization still remaining in the Phase 0 lane.
 
 - **Critical path:** Phase 0 → Phase 1 → Phase 2 → Phase 3 → Phase 4
 - **Parallel lane A (performance):** [Memory_Optimization.md](Memory_Optimization.md) Track 1 after Phase 1 stabilizes
@@ -180,52 +183,53 @@ than a roadmap-tracked plan file.
 ### Phase 0 inventory
 
 1. [Flappy_Bird_Folder_Documentation_Pass.md](Flappy_Bird_Folder_Documentation_Pass.md) [DONE]
-2. [architecture-solid-split.plans.md](architecture-solid-split.plans.md) [WIP]
+2. [architecture-solid-split.plans.md](architecture-solid-split.plans.md) [DONE]
 3. [methods-solid-split.plans.md](methods-solid-split.plans.md) [DONE]
 4. [methods-docs.plans.md](methods-docs.plans.md) [DONE]
-5. [neat-docs.plans.md](neat-docs.plans.md) [WIP]
-6. [utils-docs.plans.md](utils-docs.plans.md) [DONE]
-7. [neat-test-surface-repair.plans.md](neat-test-surface-repair.plans.md) [DONE]
-8. [asciiMaze-typescript-repair.plans.md](asciiMaze-typescript-repair.plans.md) [DONE]
-9. [generate-docs-solid-split.plans.md](generate-docs-solid-split.plans.md) [DONE]
-10. [render-docs-html-solid-split.plans.md](render-docs-html-solid-split.plans.md) [DONE]
-11. [analyze-trace-solid-split.plans.md](analyze-trace-solid-split.plans.md) [DONE]
-12. [src-no-explicit-any-cleanup.plans.md](src-no-explicit-any-cleanup.plans.md) [DONE]
-13. [ES2023 migration](ES2023%20migration) [PLANNED]
+5. [neat-docs.plans.md](neat-docs.plans.md) [DONE]
+6. [readme-first-section-pass.plans.md](readme-first-section-pass.plans.md) [DONE]
+7. [utils-docs.plans.md](utils-docs.plans.md) [DONE]
+8. [neat-test-surface-repair.plans.md](neat-test-surface-repair.plans.md) [DONE]
+9. [asciiMaze-typescript-repair.plans.md](asciiMaze-typescript-repair.plans.md) [DONE]
+10. [generate-docs-solid-split.plans.md](generate-docs-solid-split.plans.md) [DONE]
+11. [render-docs-html-solid-split.plans.md](render-docs-html-solid-split.plans.md) [DONE]
+12. [analyze-trace-solid-split.plans.md](analyze-trace-solid-split.plans.md) [DONE]
+13. [src-no-explicit-any-cleanup.plans.md](src-no-explicit-any-cleanup.plans.md) [DONE]
+14. [ES2023 migration](ES2023%20migration) [PLANNED]
 
 ### Phase 1 inventory
 
-14. [neat.plans.md](neat.plans.md) [PLANNED]
-15. [Stable_Activation_Ordering_and_Explicit_IO_Roles.md](Stable_Activation_Ordering_and_Explicit_IO_Roles.md) [PLANNED]
+15. [neat.plans.md](neat.plans.md) [PLANNED]
+16. [Stable_Activation_Ordering_and_Explicit_IO_Roles.md](Stable_Activation_Ordering_and_Explicit_IO_Roles.md) [PLANNED]
 
 ### Phase 2 inventory
 
-16. [Architecture_Primitives_Node_Group_Layer.md](Architecture_Primitives_Node_Group_Layer.md) [PLANNED]
-17. [Construct_From_Parts_Graph_Assembly.md](Construct_From_Parts_Graph_Assembly.md) [PLANNED]
-18. [Preconfigured_Architectures_MLP_LSTM_GRU_NARX.md](Preconfigured_Architectures_MLP_LSTM_GRU_NARX.md) [PLANNED]
+17. [Architecture_Primitives_Node_Group_Layer.md](Architecture_Primitives_Node_Group_Layer.md) [PLANNED]
+18. [Construct_From_Parts_Graph_Assembly.md](Construct_From_Parts_Graph_Assembly.md) [PLANNED]
+19. [Preconfigured_Architectures_MLP_LSTM_GRU_NARX.md](Preconfigured_Architectures_MLP_LSTM_GRU_NARX.md) [PLANNED]
 
 ### Phase 3 inventory
 
-19. [Browser_Build_and_CDN_Distribution.md](Browser_Build_and_CDN_Distribution.md) [PLANNED]
-20. [Interactive_Examples_and_Learning_Path.md](Interactive_Examples_and_Learning_Path.md) [PLANNED]
-21. [Network_Visualization_Export_Schema.md](Network_Visualization_Export_Schema.md) [PLANNED]
+20. [Browser_Build_and_CDN_Distribution.md](Browser_Build_and_CDN_Distribution.md) [PLANNED]
+21. [Interactive_Examples_and_Learning_Path.md](Interactive_Examples_and_Learning_Path.md) [PLANNED]
+22. [Network_Visualization_Export_Schema.md](Network_Visualization_Export_Schema.md) [PLANNED]
 
 ### Phase 4 inventory
 
-22. [Standalone_Inference_Export.md](Standalone_Inference_Export.md) [PLANNED]
-23. [Worker_Friendly_Network_Serialization_Fastpath.md](Worker_Friendly_Network_Serialization_Fastpath.md) [PLANNED]
-24. [Turnkey_Multithread_Evaluation_API.md](Turnkey_Multithread_Evaluation_API.md) [PLANNED]
-25. [Population_Save_Resume_and_Checkpointing.md](Population_Save_Resume_and_Checkpointing.md) [PLANNED]
-26. [Evolution_Training_Interoperability_Contracts.md](Evolution_Training_Interoperability_Contracts.md) [PLANNED]
+23. [Standalone_Inference_Export.md](Standalone_Inference_Export.md) [PLANNED]
+24. [Worker_Friendly_Network_Serialization_Fastpath.md](Worker_Friendly_Network_Serialization_Fastpath.md) [PLANNED]
+25. [Turnkey_Multithread_Evaluation_API.md](Turnkey_Multithread_Evaluation_API.md) [PLANNED]
+26. [Population_Save_Resume_and_Checkpointing.md](Population_Save_Resume_and_Checkpointing.md) [PLANNED]
+27. [Evolution_Training_Interoperability_Contracts.md](Evolution_Training_Interoperability_Contracts.md) [PLANNED]
 
 ### Phase 5 inventory
 
-27. [Memory_Optimization.md](Memory_Optimization.md) [WIP]
+28. [Memory_Optimization.md](Memory_Optimization.md) [WIP]
 
 ### Phase 6 inventory
 
-28. [ONNX_EXPORT_PLAN.md](ONNX_EXPORT_PLAN.md) [WIP]
+29. [ONNX_EXPORT_PLAN.md](ONNX_EXPORT_PLAN.md) [WIP]
 
 ### Phase 7 inventory
 
-29. [HyperEvoDevoMorphoNEAT.md](HyperEvoDevoMorphoNEAT.md) [PLANNED]
+30. [HyperEvoDevoMorphoNEAT.md](HyperEvoDevoMorphoNEAT.md) [PLANNED]

package/plans/analyze-trace-solid-split.logs.md

@@ -0,0 +1,35 @@
+# Analyze Trace SOLID Split Log
+
+**Status:** [DONE]
+
+## Audit scope
+
+- Objective: split the trace analyzer into a folder-owned subsystem while
+  preserving the trace-analysis command path and its reporting behavior.
+
+## Durable milestones
+
+### [DONE] Analyzer boundary split
+
+- Established stable ownership for constants, types, shared helpers, I/O,
+  analysis, and reporting under the analyzer folder.
+
+### [DONE] Orchestration clarification
+
+- Made the root flow clearer as resolve, load, analyze, and print so future
+  trace extensions land on a stable orchestration surface.
+
+### [DONE] Determinism follow-through
+
+- Added deterministic sort-tie handling so equal-duration sections produce
+  stable ordering across runs.
+
+## Controls and evidence
+
+- Validation used clean file diagnostics,
+  `npx tsc --noEmit -p tsconfig.docs.json`, and `npm run trace:analyze`.
+
+## Reopen triggers
+
+- Future analyzer features require deeper subfolder work.
+- Deterministic ordering or report output regresses.

package/plans/analyze-trace-solid-split.plans.md

@@ -4,63 +4,32 @@
 
 ## Scope
 
-- Folderize the trace analyzer into [scripts/analyze-trace](../scripts/analyze-trace) with a stable entrypoint at [scripts/analyze-trace/analyze-trace.ts](../scripts/analyze-trace/analyze-trace.ts).
-- Keep `npm run trace:analyze` stable by retargeting it to the folder-owned entrypoint instead of leaving a flat compatibility shim.
-- Improve JSDoc, naming clarity, and deterministic report assembly without changing the report's overall scope.
+- Folderize the trace-analyzer script into a stable subsystem while keeping
+  `npm run trace:analyze` behavior intact.
+- Leave the analyzer in a reopen-only state for future feature work.
 
-## Current state
+## Final state
 
-- Split root: `scripts/analyze-trace/`
-- README inventory for `scripts/`: none under `scripts/**/README.md`
-- Relevant plan: `n/a` (tooling-only trace analyzer tidy; no direct roadmap lane)
-- Stable entrypoint: `scripts/analyze-trace/analyze-trace.ts`
-- Landed folder files:
-  - `scripts/analyze-trace/analyze-trace.ts`
-  - `scripts/analyze-trace/analyze-trace.constants.ts`
-  - `scripts/analyze-trace/analyze-trace.types.ts`
-  - `scripts/analyze-trace/analyze-trace.shared.ts`
-  - `scripts/analyze-trace/analyze-trace.io.ts`
-  - `scripts/analyze-trace/analyze-trace.analysis.ts`
-  - `scripts/analyze-trace/analyze-trace.report.ts`
-- Closed issues in this step:
-  - CLI parsing, trace loading, analysis, shared helpers, and report rendering no longer live in one file,
-  - the split now uses a real folder boundary instead of scattering module files at the scripts root,
-  - deterministic sort tie-breaks now make equal-duration sections more stable across runs,
-  - the stable min/max timestamp scan remains single-pass for large traces.
+- The trace analyzer now has stable folder-owned boundaries for constants,
+  types, shared helpers, I/O, analysis, and reporting.
+- The orchestration flow is clearer and deterministic behavior was improved for
+  equal-duration sort ties.
+- No active backlog remains; this file is now a reopen point for future
+  analyzer extensions.
 
-## Coverage backlog
+## Audit summary
 
-### [DONE] Folder-owned analyzer split
+- Validation used `npx tsc --noEmit -p tsconfig.docs.json` and
+  `npm run trace:analyze`.
+- File diagnostics were kept clean through the split.
 
-- Moved the analyzer into [scripts/analyze-trace](../scripts/analyze-trace) and retargeted `npm run trace:analyze` to [scripts/analyze-trace/analyze-trace.ts](../scripts/analyze-trace/analyze-trace.ts).
-- Separated constants, contracts, shared utility helpers, CLI/file I/O, analysis passes, and text-report rendering inside the folder boundary.
-- Preserved the existing report sections while making the orchestration flow read as resolve -> load -> analyze -> print.
+## Reopen conditions
 
-### [DONE] Educational docs follow-up
+- New trace-analysis features outgrow the current structure.
+- Analyzer determinism or report ordering regresses.
+- Script-boundary work reopens the trace analyzer subsystem.
 
-- Added educational JSDoc to the folder-owned constants, contracts, helpers, and report surface so future trace-tooling changes can start from an intentional boundary map instead of a single oversized file.
+## Audit log
 
-## Validation
-
-- File diagnostics: clean for the touched `scripts/analyze-trace/*.ts` files.
-- `npx tsc --noEmit -p tsconfig.docs.json`
-- `npm run trace:analyze -- test/examples/flappy_bird/Trace-20260309T191949.json --top=5`
-
-## Immediate next steps
-
-- No further split work is queued for this boundary right now.
-- Future analyzer changes should continue inside `scripts/analyze-trace/` instead of re-growing a flat scripts-root boundary.
-
-## Handoff query
-
-```text
-Continue from the current repo state only. Do not rely on prior chat history.
-
-Use solid-split for #file:analyze-trace.
-Plan: plans/analyze-trace-solid-split.plans.md.
-Current boundary: scripts/analyze-trace/.
-Completed context: scripts has no local README surface, scripts/analyze-trace/analyze-trace.ts is the stable CLI entrypoint, and the analyzer now splits responsibilities across constants, types, shared helpers, CLI/file I/O, analysis, and report rendering inside one owned folder.
-Repo standard: direct-path migration with no compatibility shims by default, and the small-chapter mindset applies to scripts/tooling boundaries.
-Required validations: file diagnostics for touched files, npx tsc --noEmit -p tsconfig.docs.json, then npm run trace:analyze -- test/examples/flappy_bird/Trace-20260309T191949.json --top=5.
-Worktree caution: there may already be unrelated generated README drift elsewhere in the repo.
-```
+- Durable completion notes now live in
+  [analyze-trace-solid-split.logs.md](analyze-trace-solid-split.logs.md).

package/plans/architecture-solid-split.logs.md

@@ -0,0 +1,44 @@
+# Architecture Solid Split Log
+
+**Status:** [DONE]
+
+## Audit scope
+
+- Objective: convert the flat `src/architecture/` area into stable folder-owned
+  module boundaries and repair the generated chapter structure that depended on
+  those boundaries.
+
+## Durable milestones
+
+### [DONE] Root and family split baseline
+
+- Closed the split across the core architecture families, including the root
+  architecture surface plus the main node, connection, group, architect, and
+  network ownership boundaries.
+- Eliminated the dependency on a facade-dominated root README opening.
+
+### [DONE] Network and ONNX subchapter structure
+
+- Split deeper network and ONNX concerns into stable subchapters so future work
+  can extend them without returning to a flat-file architecture root.
+- Preserved public behavior while moving implementation and doc ownership into
+  the intended folders.
+
+### [DONE] Documentation ownership follow-through
+
+- Added and tuned `docs.order.json` controls so generated chapter openings come
+  from the right public owner files and chapter maps.
+- Closed the README-opening follow-through that the split exposed.
+
+## Controls and evidence
+
+- Validation after structural and doc-affecting edits used `npm run docs` and
+  `npx tsc --noEmit -p tsconfig.json`.
+- The final architecture root is now a durable baseline rather than an active
+  split frontier.
+
+## Reopen triggers
+
+- Future architecture changes reintroduce facade-heavy or oversized roots.
+- Public-import cleanup is intentionally resumed.
+- ONNX or network chapters need another structural split.