manual_slop/docs/reports/proposed_new_tracks_20260608.md

Proposed New Tracks — 2026-06-08

Source: End-of-session assessment in docs/reports/session_synthesis_20260608.md §8 Date: 2026-06-08 Status: Recommendation; user decides

The verdict. Of all the work surfaced in this session, 2 new tracks are worth devising. Both are sub-tracks of work already represented, not net-new initiatives. This document gives the spec-ready detail for each, in case you want to commit them as real tracks in a future session.

---

1. manual_ux_validation_20260608_PLACEHOLDER

Why this exists: The ASCII-sketch UX workflow (docs/reports/ascii_sketch_ux_workflow_20260608.md) is a tool without a track. The workflow needs:

• A sub-spec inside the existing manual_ux_validation_20260302 track (which is currently spec ✓, plan ✓, no metadata, in the backlog)
• At least one panel redesigned using the workflow
• 5 open questions resolved (vocabulary preference, comparison policy, storage location, tooling, frequency)

Why it's not net-new: manual_ux_validation_20260302 exists. This is a new approach to that track's work, not a new initiative.

Effort: Small. ~1-3 phases as an addendum to manual_ux_validation_20260302. The hard work is doing the UX review, not writing the spec.

Domain: Application. The UX workflow produces design contracts that drive the Application's GUI.

Sub-spec structure (proposed):

# Appendix to manual_ux_validation_20260302
# Added 2026-06-08

[approach]
# Replace the existing "review UX" approach with the ASCII-sketch workflow
# documented in docs/reports/ascii_sketch_ux_workflow_20260608.md
method = "ASCII-sketch + MiniMax understand_image verification"
vocabulary = "[I], ===>, o==>, [B], [M], [S], [Q], [N], --"  # 6 primitives + 7 modifiers
first_target = "Discussion Hub per-entry panel"  # gui_2.py:3770
source_of_truth = "docs/guide_discussions.md §Per-Entry Operations (A1-A7 matrix)"

[open_questions]
# These need the user's decision before the workflow becomes a track
vocabulary_preference = "TBD"           # §2 vs box-drawing vs Markdown tables
comparison_policy = "TBD"            # always vs proportional vs only-on-mismatch
storage_location = "TBD"            # spec appendix vs conductor/designs/ vs docs/designs/
tooling = "TBD"                      # manual vs scaffold-render vs ASCII-vs-screenshot diff
frequency = "TBD"                    # every change vs only new panels vs only-on-request

[inputs_to_resolve]
# All 5 must be answered before Phase 1 of this addendum can start
# Once answered, the addendum becomes executable

First sketch (proposed in the ASCII-sketch report, ready for the user's critique):

+------------------------------------------------------------------+
| [+/-] Entry #3   [Role: AI       v]  [Edit]   @2026-06-08T12:34  |  <- header
|                                                       in:120 out:340
|       in:120  out:340                                       |
+------------------------------------------------------------------+
|                                                                  |
|  [thinking trace: <click to expand>]                             |  <- thinking
|  "I think the right approach is to split the parser              |     body
|   into two phases..."                                           |
|                                                                  |
|  ---collapsed: rest of 8,200 chars---                           |
+------------------------------------------------------------------+
| [Ins]  [Del]  [Branch]  I noticed that foo.py:42 uses an...     |  <- footer
+------------------------------------------------------------------+

The user's next move: critique this sketch. The critique becomes the second iteration. We converge in 1-3 rounds.

Why the Discussion Hub per-entry panel: 23 distinct operations (the A1-A7 matrix), user has strong opinions per the nagent_review corrections, ImGui-regular layout maps well to ASCII, the existing guide_discussions.md is the source-of-truth spec.

Verification protocol: when the design converges, render the actual GUI (in dev mode with the changes applied) and use MiniMax understand_image to compare the screenshot to the ASCII sketch. Flag any deltas. This is the only verification — ASCII + verify-screenshot is the workflow.

---

2. chunkification_optimization_20260608_PLACEHOLDER

Why this exists: The user's chunk-ideation archive (May 2026, 5 Discord messages + images) + Reece's Xar + Muratori's ECS archetype tables collectively describe a specific optimization pattern: replace realloc-style growable buffers with chunk-based data structures. This is not a future-track candidate in the existing 10 (nagent_review/decisions.md); it's a new concrete track.

Why it's not net-new: the user's chunk-ideation is the source; Reece's Xar is the reference implementation; Manual Slop's comms.log is the target. The idea is the user's own. The implementation is the new part.

Effort: Medium. ~2-3 phases:

1. Audit current growable buffers and pick the highest-value target
2. Implement chunkification for that one
3. Document the pattern in a code_styleguides entry so future code follows it

Domain: Both. The Application's comms.log is the primary target; the Meta-Tooling's mma_exec.py logs are secondary.

Sub-spec structure (proposed):

# Track: Chunkification Optimization
# Owner: Tier 2 Tech Lead
# Priority: Medium (data-grounded; the user's own chunk-ideation is the source)

[meta]
source = "User's chunk-ideation archive (docs/ideation/ed_chunk_data_structures_20260523.md)"
reference = "Andrew Reece's Xar (docs/transcripts/i-h95QIGchY_assuming_as_much_as_possible_andrewreece.txt §56:42)"
target = "Manual Slop's append-heavy, time-ordered data structures"

[approach]
# Identify the highest-value growable buffer in src/ and replace it
# with a chunk-based structure. The replacement must:
# - Use Reece's Xar pattern (8-byte header, power-of-2 chunks, bitwise divmod)
# - Use the user's chunking pattern (leverage ECS archetype tables where applicable)
# - Preserve the user's principle: "the user must always decide a fixed size heuristic"
# - Be backward-compatible at the API level (callers don't change)

[phase_1_audit]
# Survey src/ for append-heavy, read-heavy, time-ordered-or-uniform-shape data:
#   - comms.log (app_controller.py:716; JSON-L ring buffer, time-ordered)
#   - summary_cache.json (file_cache.py; hash-keyed, LRU eviction)
#   - log_registry (log_registry.py; append + prune)
#   - per-session screenshot lists (screenshot panels in gui_2.py)
#   - per-discussion entry lists (already in the 23-op matrix)
#   - per-ticket state in MMA (multi_agent_conductor.py)
# Pick the highest-value target. Tie-breaker: hottest path in render_main_interface.
files_to_audit = [
    "src/app_controller.py",
    "src/file_cache.py",
    "src/log_registry.py",
    "src/gui_2.py",
    "src/multi_agent_conductor.py",
    "src/aggregate.py",
]

[phase_2_implement]
# For the chosen target, implement the chunkification:
# - Add src/chunked_array.py (or use existing Xar-like libraries; check deps)
# - Replace the target's backing storage with the new structure
# - Add tests: grow patterns, random access, edge cases (empty, full, etc.)
# - Profile before/after with the existing src/performance_monitor.py
# - Verify the user's "wasted memory" objection is bounded (last-chunk waste only)

[phase_3_document]
# Add a code_styleguides entry: conductor/code_styleguides/chunked_data_structures.md
# - The 6 objections + rebuttals from the user's archive
# - The Xar 8-byte header pattern (Reece)
# - The "you must always decide a fixed size heuristic" rule
# - The chunkification-candidate fingerprint (uniform data, hot path, large N)
# Wire the styleguide into the existing static-CI gates

First target (recommended): the comms.log ring buffer in app_controller.py:716 (_comms_log: List[Dict[str, Any]]). Reasons:

• Events are append-heavy, read-heavy for the recent tail
• Timestamps are already sorted (per Reece's Q&A — his use case is the same shape)
• Long sessions hit reallocation spikes (the same spikes Muratori describes in the Big OOPs talk as "the CPU is just tanking")
• The change is contained — _comms_log is referenced from a few specific sites; no deep call-graph refactor
• The performance impact is measurable via src/performance_monitor.py (the existing infrastructure)

Why the comms.log is better than the user's "TArray in UE" framing: Manual Slop's comms.log is smaller and more focused than the user's UE example. It's a single function-local concern, not a framework-level data structure. The chunkification is a small, contained change with measurable before/after performance.

Why not the summary_cache (file_cache.py)? It's already hash-keyed and LRU-evicted; the chunkification benefit is smaller. It's a good second target but not the first.

Why not the per-discussion entry list (app.disc_entries)? It's already covered by the existing 23-operation matrix and the nagent_review takeaways. The user has consciously designed the abstraction layer. Don't disturb it.

Verification: use src/performance_monitor.py to measure comms.append_time and comms.random_access_time before and after. The user's prediction is that append time becomes O(1) amortized (no reallocation spikes) and random access stays O(1) (bitwise divmod on power-of-2 chunks).

The user's principle to preserve: "the user must always decide a fixed size heuristic." Don't make the chunk size magic-number or hard-coded. Make it a constructor argument with a sensible default. The user can override at instantiation time.

---

3. The non-recommendations (so you know what I'm not suggesting)

• "nagent_review part 2" — complete; nothing new to add
• "computational_shapes_ssdl" as a track — belongs as a styleguide, not a track
• "transcript_pipeline" — over-engineering; the 5 transcripts are committed artifacts
• "ECS migration of tickets" — implicit in the upcoming 4 tracks
• "data-oriented rewrite of ai_client" — coordinated across the 4 tracks
• "Manual Slop port to Odin/Jai" — out of scope, near-term
• "public_api_migration_20260606" — already planned as a follow-up in data_oriented_error_handling_20260606
• "Xar-specific data structure" — the Xar is the reference implementation, not a Manual Slop feature; if we use the pattern, we don't import the Xar

---

4. What I'd recommend

Promote track #1 (manual_ux_validation_20260608_PLACEHOLDER) and track #2 (chunkification_optimization_20260608_PLACEHOLDER) to real tracks in the next session. Both are small enough to write the spec/plan in one sitting, and both have concrete first targets.

If you only have appetite for one: #2 is more directly impactful (the comms.log is on the hot path of every AI message lifecycle; the chunkification is a measurable performance win). #1 is more meta (it changes how you do future work, not the work itself).

Or: wait until the 4 major tracks ship and run code_path_audit_20260607 first. The audit's chunkification-candidates heuristic (added to the spec in this session) will automatically surface the comms.log as a candidate. At that point, track #2 becomes a follow-on of the audit, not a separate initiative. That's the cleaner sequence.

My recommendation if I had to pick one: do #1 (the ASCII-sketch workflow) now, because it shapes how you do the next 5 tracks. Then when the 4 major tracks ship and the audit runs, the chunkification-candidates heuristic + your chunk-ideation + Reece's Xar come together naturally into track #2.

---

End of proposed-track document. Pick this up when the user is ready to commit these to real tracks.