# 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):**

```toml
# 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):**

```toml
# 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.*