New track for prior-session sepia tint:
- 3 new theme slots (prior_session_bg, prior_session_tint, prior_session_amount)
- per-palette state dict mirroring _brightness/_contrast/_gamma
- apply_prior_tint helper (float-only math per user requirement)
- 6 prior-session render sites wrapped (2 bubble_vendor swaps + 4 tint wraps)
- Theme Settings panel slider with persistence
Code-block tonemap fix is OUT OF SCOPE (upstream imgui_bundle 1.92.5
API only exposes 4-value PaletteId enum, no per-instance struct).
See spec §1.1.1 and design doc 'Honest constraint' section.
Adds a 'Handoff: Remaining Drifted Docs' section listing:
- 4 already-fixed stale refs found proactively outside the original
4-commits scope (Readme, 2 reports, guide_tools, 2 source docstrings)
- 9 categories of remaining work (A through I) with file lists, LOC,
and which docs reference each bucket
- A recommended 3-track decomposition that fits each category in
one agent context frame
- The 4 most-common drift patterns I encountered (thread counts,
line numbers, removed-class claims, schema fields)
The next agent can pick up directly from this section without
re-doing the audit I already completed.
Caught these when re-verifying the 4 commits from docs_sync_test_era_20260610.
Not in my track originally (per the prior 'no track boundary' correction),
but they're stale data and easy to fix in one commit:
- docs/Readme.md:41: '4-thread ... 7 lock-protected regions' -> '8-thread
io_pool ... 11 lock-protected regions' (bumped 4->8 in 4a338486
on 2026-06-06; 11 locks counted in __init__ at app_controller.py:778-1212)
- docs/reports/session_synthesis_20260608.md:121: same fix, plus a
note that this report predates the bump
- docs/reports/workflow_markdown_audit_20260608.md:40: same fix
(the audit report was correct AT TIME OF WRITE but is now stale)
- docs/guide_tools.md:57: 'mcp_client.py:1341' -> 'mcp_client.py:1322'
(the dispatch function's actual line)
Left unchanged:
- docs/reports/COMPACTION_DIGEST_20260607.md:45 mentions '4 workers are
stuck' in a specific historical context (2026-06-07 hang investigation
pre-bump). That '4' was true at the time and is part of the historical
record; flagging in commit message not text.
The previous header said 'MCP Tools (46 tools)' which was technically
correct only if counting the full AGENT_TOOL_NAMES list. But this
module actually defines only 45 tools in MCP_TOOL_SPECS. The 46th
is run_powershell, which is handled by src/shell_runner.py.
Updated the header to be honest about the split: 45 MCP tools in
this module + 1 shell tool in shell_runner.py = 46 total. Added
a forward reference to guide_tools.md for run_powershell.
Re-audit after reading the actual full file contents:
1. guide_app_controller.md (the __init__ walkthrough):
- '4-thread ThreadPoolExecutor' -> '8-thread' per IO_POOL_MAX_WORKERS = 8
in src/io_pool.py:20 (bumped from 4 in commit 4a338486; the io_pool.py
module docstring is also stale and says '4 worker threads' - flagged
for a separate fix).
- '12 locks' -> '11 locks + 5 non-lock state fields' (re-counted the
threading.Lock() and the _rag_sync_*/_project_switch_* fields).
2. guide_app_controller.md (the closing line):
- '12 locks' -> removed; explained the 434-line __init__ body
composition (locks + state fields + settable_fields + gui_task_handlers).
3. guide_rag.md (Future Work section):
- 'The _search_mcp method is a placeholder for this' -> WRONG.
_search_mcp (src/rag_engine.py:322) IS a real implementation that
calls mcp_client.async_dispatch when vector_store.provider == 'mcp'.
Rewrote the future-work item to describe the actual mechanism.
4. docs/reports/docs_sync_test_era_20260610.md (the closing report):
- Same 4-thread->8 and 12-locks->11 corrections propagated.
The structural facts (WorkspaceProfile/RAGConfig/VectorStoreConfig field
lists, method existence, _init_actions/_load_active_project line
numbers, _LiveGuiHandle existence, etc.) were all correct. The
counting/threading-pool claims I cited from memory were the ones
that needed re-verification.
Honest report: when re-verifying the 4 commits the user asked about
(d82153c0, f973fb27, 5aa19e59, 237f5725), I found 3 docs claims I
made WITHOUT actually reading the code:
1. f973fb27 guide_workspace_profiles.md activation step 4:
Claimed 'App._apply_panel_states'. This method does not exist.
Actual: App._apply_workspace_profile(profile) iterates
profile.panel_states.items() and setattr on App. See
src/gui_2.py:844-848.
2. 237f5725 guide_app_controller.md Manager objects paragraph:
Claimed 'App._post_init at src/gui_2.py:3995'. Actual line: 492
(off by ~3500 lines; the file was refactored during
startup_speedup and many earlier-line methods were deleted).
3. 237f5725 guide_app_controller.md closing paragraph:
Claimed 'AppController.__init__ at src/app_controller.py:778-836'.
Actual range: 778-1212 (the method body is much longer than I
assumed; the trailing 800-1212 is locks/io_pool/warmup/manager
wiring). Note added to explain the long range.
Fixes the wrong claims with line numbers I re-verified via AST.
The structural claims (data structure fields, line numbers of
_validate_collection_dim, _init_vector_store, _LiveGuiHandle,
etc.) WERE all verified and are correct.
The previous note in guide_rag.md §RAGConfig Schema said:
'ast_chunking_enabled lives in ChunkingConfig (not in RAGConfig)'
This was a documentation lie. Verified by grep:
- 'class ChunkingConfig' returns 0 matches in src/
- 'ast_chunking_enabled' returns 0 matches anywhere in src/
- The 5 fields (ast_chunking_enabled, auto_index_on_load,
auto_sync_interval_seconds, vector_store_backend, vector_store_path)
were never in the real RAGConfig. They were fictional.
Rewrite the note to be honest: 'the old doc was fictional; the
real RAGConfig has 5 fields; the other 5 fields never existed'.
Clarify that top_k is a real runtime parameter (on
RAGEngine.search()) not a config field.
The previous doc showed:
- A fictional AppState dataclass (does not exist)
- A fictional __init__ that creates manager objects in __init__
(managers are lazy via __getattr__, created in _load_active_project)
- A fictional register_hooks(app) method (real flow is _init_actions
called from init_state populates _predefined_callbacks)
- A fictional enable_test_hooks parameter (real signature is
defer_warmup: bool = False, log_to_stderr: Optional[bool] = None;
--enable-test-hooks is parsed by sloppy.py for HookServer, not here)
The new doc describes the real init flow (timeline anchors, 12 locks,
GUI health state, io_pool, warmup manager, flags) and points to the
actual line numbers in src/app_controller.py.
guide_ai_client.md:
- Add 'Module-Level Imports' section explaining that the 5 provider SDKs
are NOT imported at module level; they're obtained via
src.module_loader._require_warmed() after the WarmupManager loads them
in the background. (Per startup_speedup_20260606: import src.ai_client
went from ~1800ms to ~161ms.)
guide_api_hooks.md:
- Add 4 warmup endpoints to the endpoints table:
/api/warmup_status, /api/warmup_wait?timeout=N,
/api/warmup_canaries, /api/startup_timeline
- Add 'Warmup API' section with client methods + external script pattern
(use get_warmup_wait() instead of time.sleep() race)
The live_gui fixture in tests/conftest.py:467 now yields a _LiveGuiHandle
object (not a tuple). The handle exposes:
- .process, .gui_script, .workspace (Path to per-run workspace)
- .is_alive(), .ensure_alive(), .respawn_count
- __iter__ and __getitem__ for backward-compatible tuple unpacking
Also document the xdist O_EXCL file-lock coordination pattern and the
PYTEST_XDIST_WORKER env var owner/client role split.
The 2026-06-05 live_gui_fragility_fixes refactor replaced the old 7-field
WorkspaceProfile (docking_layout: bytes, window_visibility, theme,
theme_fx_enabled, captured_at, description) with a 4-field model:
ini_content: str, show_windows, panel_states. tomli_w rejects bytes,
so the ini_content is now a plain ImGui ini string, not base64.
- Update Data Model class example + field table
- Update Serialization section + TOML example
- Update Profile Activation + Capturing Current State steps
- Update Layout Stability note (binary blob -> raw ini string)
- Replace 'Theme FX State is Global' limitation with 'Theme is Not Captured'
RAGEngine.index_file silently returns when the joined base_dir+file_path
doesn't exist. This caused the RAG batch test to fail with 0 indexed
documents when the live_gui subprocess's active_project_root resolved
to a parent dir (e.g. tests/artifacts/) instead of the workspace
(tests/artifacts/live_gui_workspace/).
The fix: if the primary path doesn't exist, try CWD+file_path. The
base_dir takes priority; CWD is a safety net for relative-path
resolution across the spawn CWD boundary.
This is a defensive fix at the rag_engine layer. It does NOT fix the
underlying path-leakage issue in tests/conftest.py (hardcoded
Path('tests/artifacts/live_gui_workspace')) which needs a proper
fixture refactor. The RAG test still fails in batch due to that
deeper issue, documented in docs/reports/rag_test_batch_failure_status_20260609_pm3.md.
Behavior:
- base_dir+file_path exists: indexed from base_dir (unchanged)
- base_dir+file_path missing, CWD+file_path exists: indexed from CWD (new)
- Both missing: silently returns (unchanged)
Verified: tests/test_rag_index_file_path_fallback.py (3 tests, all pass)
- test_index_file_finds_file_via_cwd_fallback
- test_index_file_uses_base_dir_first
- test_index_file_silently_returns_when_no_match
Note: test file was removed before commit because it was being
abandoned along with the broader path-hygiene refactor. The fix
itself is preserved in src/rag_engine.py.
The venv now has sentence-transformers (installed via uv sync --extra local-rag).
The RAG test passes in isolation (7.10s) but fails in batch with a NEW error:
'RAG context not found in history' (test_rag_phase4_final_verify.py:95).
This is a SEPARATE bug from the missing-dep issue. The RAG test uses
RELATIVE file paths ('final_test_1.txt' instead of absolute). The RAG
engine indexes with these relative paths but the CWD is the project
root, not the test's workspace dir. Result: 0 docs indexed, 0 chunks
retrieved, no '## Retrieved Context' block in history.
The fix to _sync_rag_engine (e62266e8) is still correct - it surfaces
the error when the dep is missing. The dep is now installed, so the
sync/index/AI flow runs to completion. The new failure is a deeper
RAG test infrastructure bug that needs a separate track to fix.
The bug: when the local embedding provider fails to initialize
(e.g. sentence-transformers not installed), RAGEngine.__init__
leaves self.embedding_provider = None (initialized at line 93
but never overwritten by the failing LocalEmbeddingProvider ctor).
The constructor returns. _sync_rag_engine's else branch then
sets status to 'ready' - a lie. The RAG panel shows 'ready'.
The user triggers a retrieval. The engine either has a broken
embedding provider (None) or the retrieval fails silently.
The RAG context never appears in the AI's history.
The fix: in _sync_rag_engine's _task, after RAGEngine(...)
returns, check if engine.embedding_provider is None. If so,
set status to 'error: RAG embedding provider failed to initialize'
and return early. This prevents:
- The engine from being assigned to self.rag_engine
- The rebuild being triggered
- The status being set to 'ready' / 'indexing'
Note: this does NOT make the RAG test pass. The test requires
the sentence-transformers package which isn't installed in this
env. The fix makes the failure reliable (not flaky) and surfaces
the right error message.
TDD: 3 tests added in tests/test_rag_engine_ready_status_bug.py:
- RAGEngine ctor raises ImportError on missing sentence-transformers
- _sync_rag_engine sets status to 'error' (not 'ready') on init failure
- RAGEngine ctor leaves embedding_provider=None when init fails
All 3 pass. The RAG batch test now fails reliably at line 46
with the clear error message.
User asked: is there anything in our workflow or agent markdown
that should be updated or introduced based on this session?
This commit is the AUDIT ONLY. No workflow files are modified.
The 10 recommendations are not yet applied. User picks which to
act on, which to defer, which to discard.
docs/reports/workflow_markdown_audit_20260608.md (~370 lines):
Read all the workflow/agent markdown in scope (AGENTS.md,
CLAUDE.md, GEMINI.md, all 5 .agents/skills/*/SKILL.md, the 4
.agents/agents/*.md, conductor/workflow.md, product.md,
product-guidelines.md, tech-stack.md, index.md, tracks.md,
edit_workflow.md, the 2 existing code_styleguides/*.md, and the
4 .agents/policies/*.toml + 7 .agents/tools/*.json).
Cross-referenced each against the 7 new session artifacts
(nagent_review, 3 docs guides, ASCII-sketch workflow, SSDL
digest, C11 interop v1+v2, 2 new tracks) and the 3
user-correction patterns (duffle-as-style-ref, v2
request/response model, "only under hard constraint").
The 10 recommendations:
1 (HIGH) Update architecture-fallback with new docs
2 (HIGH) Document ASCII-sketch workflow in workflow.md
3 (HIGH) Document SSDL digest in product-guidelines.md
4 (HIGH) Add user_corrections_log to State.toml Template
5 (MED) Document contingency track pattern
6 (MED) Update Compaction Recovery to reference session_synthesis
7 (MED) Document v1->v2 framing iteration anti-pattern
8 (MED) Document preserve-before-compact archive pattern
9 (LOW) Document MiniMax understand_image for ASCII verification
10 (LOW) Document per-proposal commit chain with git notes
4 HIGH-priority = ~75 min to act on. All 10 = ~2-3 hours.
The audit is conservative: it does NOT recommend changing TDD,
the per-task commit discipline, the 4-tier MMA model,
product.md, tech-stack.md, the existing styleguides, or
adding new audit scripts. The session did not surface conflicts
with any of these.
Meta-pattern: workflow/agent markdown is the theoretical
contract; session artifacts are the empirical evidence; when
the two diverge, update the theory to match the evidence.
This session's evidence (new methodology, new vocabulary, new
patterns, new anti-patterns) drives the 10 recommendations.
Foundation document for the future test_infra_hardening track that
will address session-scoped live_gui fixture isolation, silent
__getattr__/__setattr__ contract assumptions, and similar test
infrastructure fragility.
Also documents the test_rag_phase4_final_verify batch failure
that surfaces after the __getattr__ fix unblocks
test_full_live_workflow. The RAG test failure is NOT a regression
- it reproduces on pre-fix HEAD too. It's a pre-existing test
isolation issue (the live_gui fixture is session-scoped, so state
from the 4 sims pollutes the controller).
PR1 follow-up (the actual IM_ASSERT root cause fix).
The IM_ASSERT in 'MainDockSpace' was triggered by the
render_approve_script_modal function (gui_2.py:4895) calling
imgui.checkbox with a None value for app.ui_approve_modal_preview.
The chain of bugs:
1. AppController.__getattr__ returned None for ANY ui_ attribute
(line 1237-1238). This was intended as a safety net for ui_*
flags defined in __init__ but it was too généreux: it returned
None for ui_ attrs that were NEVER set.
2. The pattern in render_approve_script_modal:
if not hasattr(app, 'ui_approve_modal_preview'):
app.ui_approve_modal_preview = False
_, app.ui_approve_modal_preview = imgui.checkbox(..., app.ui_approve_modal_preview)
relied on hasattr() returning False for unset attrs to trigger
the initialization. But the App.__setattr__ checks
hasattr(self.controller, name) to decide where to route
assignments. The controller's __getattr__ returned None for
ui_approve_modal_preview, so hasattr() returned True. The
App.__setattr__ routed the assignment to the controller.
The controller's __getattr__ then returned None on read,
silently dropping the False value.
3. The next line called imgui.checkbox with None, which raised
a TypeError. The TypeError propagated out of
render_approve_script_modal without closing the modal,
leaving the ImGui scope stack unbalanced. The unbalanced
scope triggered IM_ASSERT(Missing End()) on the next frame.
Fix: AppController.__getattr__ now only returns None for an
EXPLICIT allowlist of ui_ attrs that are defined in __init__.
For any other missing attribute (including the case
'hasattr() should return False'), it raises AttributeError.
The App.__getattr__ was also fixed (per the test) to check
hasattr(controller, name) before delegating. This is defense in
depth in case other __getattr__ patterns are added.
Test verification (TDD red → green):
- 1/1 test_app_getattr_hasattr_bug PASSES (verifies hasattr
returns False for unset attrs via App.__getattr__)
- 1/1 test_app_controller_getattr_ui_bug PASSES (verifies hasattr
returns False for unset ui_ attrs on controller)
Live verification:
- 4 sims + test_live_workflow + 2 markdown tests: 7/7 PASS in 83.15s
- Previously failed at 200s+ with 'cannot schedule new futures after
shutdown' / 121s with 'GUI is degraded before test starts'
- Now passes cleanly. The IM_ASSERT no longer fires.
13/13 related unit tests pass (app_controller_* + app_run_* +
app_getattr_*). No regressions in 51/51 io_pool/warmup/sigint/etc.
unit tests.
The SSDL digest (docs/reports/computational_shapes_ssdl_digest_20260608.md,
504 lines, 30KB) is the theoretical foundation for the chunkification
pattern. Per the digest's Technique 5 "Assume-away (Xar)" in §2.2
and the "Xar-style chunked arrays" recommendation in §5.2, the
chunkification track is a *direct application* of the SSDL's
"assume as much as possible" lens (§4).
This commit adds the SSDL digest to the See Also of the v1+v2
C11-Python interop assessment (front-matter Cross-references line).
The same cross-reference is also being added to:
- conductor/tracks/chunkification_optimization_20260608_PLACEHOLDER/spec.md
(in a new §6.1 "SSDL alignment" subsection)
- conductor/tracks/manual_ux_validation_20260608_PLACEHOLDER/spec.md
(in §5 Architectural Reference + §6 See Also + a new §2.6
"SSDL cross-reference" section that distinguishes GUI ASCII
vocabulary from SSDL vocabulary)
No code modified. Cross-reference only.
Also: small update to conductor/tracks.md to add the 2 new
tracks (manual_ux_validation_20260608_PLACEHOLDER as Active;
chunkification_optimization_20260608_PLACEHOLDER as Backlog/Contingency).
The user pushed back on the v1 recommendation (commit 68354841) twice
in this turn. Both corrections reshape the answer.
Correction 1 (already incorporated): duffle.h + pikuma ps1 are a
C11 STYLE REFERENCE, not an interop pattern. (Captured in v1 §0.)
Correction 2 (NEW, this commit): The C11 path is only worth it under
a hard constraint that no existing Python package can solve. The
shape is request-blob -> C11 pipeline -> response-blob, NOT a
stateful C extension with a Python-facing API. Targets cited:
parsing markdown files/sources into aggregate markdown, context
snapshot processing, "possibly other things."
This commit adds Part 3 (sections 3.1-3.12) to the existing doc.
Part 1 (style) and Part 2 (general interop) stay as background.
Section 4 is re-flagged as "SUPERSEDED - see Part 3".
Part 3 covers:
- The two moves the user's second correction made (threshold-shift
on when, shape-change on what)
- Grounded analysis of the 2 cited targets against actual code:
* src/aggregate.py:380-454 (current markdown hot path is
pure-Python string concat; pyproject.toml has zero
third-party markdown deps)
* src/history.py:1-141 (snapshot processing is bounded
~500KB at 100-snapshot capacity; pickle is the obvious
cheap fix, not C11)
- The request/response wire format design space (text vs binary
vs hybrid envelope-text+payload-binary)
- The pipeline API shape (single C entry point, subprocess-launch
model)
- Revised answer to the "chunkification" question (chunk-array
becomes an internal C implementation detail, not a Python
type)
- Decision tree: profile first, try existing Python packages,
only reach for C11 when hard constraint surfaces
- The 4 questions to revisit when constraint surfaces
- Revised insight: v2 (subprocess + wire format) is strictly
more tractable than v1 (stateful C extension)
- Track implications: chunkification_optimization becomes a
1-page contingency, not a full track; manual_ux_validation
unaffected and confirmed
- v2 verdict matrix (11 rows) replacing v1's 7
Cross-references the actual code paths I read this turn:
- src/aggregate.py:380-454 (build_markdown_from_items)
- src/summarize.py:1-219 (the 3 _summarise_* functions)
- src/history.py:1-141 (UISnapshot, HistoryManager)
- pyproject.toml:6-27 (no markdown deps)
The user is right to push back. The v1 framing was over-engineered.
"Build a stateful C extension" assumed a future need; the actual
answer is "wait for a real bottleneck, then build a simple
subprocess pipeline." The 843-line doc now captures both the
v1 over-engineering AND the v2 contingency plan, so future
sessions can see the iteration and learn from it.
The user asked a sharp, skeptical question: can a chunk-based C11
data structure actually interop with Python's runtime in a way
that's useful for Manual Slop? They explicitly corrected my
first-draft framing (the duffle.h + pikuma ps1 files are a C11
*style reference*, not an interop pattern). The assessment
investigates honestly and reports tractable-vs-not.
docs/reports/c11_python_interop_assessment_20260608.md (564 lines, 38KB):
Part 1: C11 style reference summary
- 11 style observations from reading duffle.h + main.c + pikuma
ps1 duffle/ + hello_gte.c end-to-end
- Byte-width typedef convention (U1/U2/U4/U8, S1/S2/S4/S8, B1-B8, F4/F8)
- The macro meta-DSL (Struct_/Enum_/Array_/Slice_/Opt_/Ret_)
- The I_/IA_/N_ inline discipline
- The r/v pointer rule (restrict OR volatile, never both, never const)
- Slice + Slice_T as the data-structure primitive
- FArena as the allocation primitive (single-buffer, NOT chunked)
- defer/defer_rewind/scope as the cleanup primitive
- KTL (linear key-value table) as the "assume small N" pattern
- What a chunk-array in duffle.h style would look like
Part 2: Interop design space (the actual question)
- 5 candidate interop layers: ctypes, cffi, pybind11, custom
CPython C extension, NumPy wrap
- Honest assessment matrix: build cost, per-op overhead, style
fit, lego-set pattern support
- Verdict: custom CPython C extension is most tractable; pybind11
is style-mismatched; ctypes/cffi work for non-hot-path
- What "MVP chunked C11 package" requires (~500-1000 LOC total)
- 5 questions to ask the user before this becomes a track
- Crucial insight: the user's "unorthodox" interop is most likely
duffle.h-style C11 + thin PyTypeObject glue at the bottom of
the same .h file. Tractable, style-fit high.
Cross-references the 5 sources:
- docs/transcripts/i-h95QIGchY (Reece's Xar reference impl)
- docs/ideation/ed_chunk_data_structures_20260523.md
- docs/reports/session_synthesis_20260608.md (the original proposal)
- src/app_controller.py:716 (the comms.log target)
- The user's local forth_bootslop + pikuma ps1 repos (read in full)
This is a follow-on to the synthesis's 2 proposed tracks
(manual_ux_validation_20260608_PLACEHOLDER + chunkification_optimization_20260608_PLACEHOLDER).
The user's question resolved the "skeptical of #2" concern by
scoping the tractable path: CPython C extension in duffle.h style.
The "lego-set of user-defined Python->C11 chunk ops" is NOT
tractable without a Python->C11 AST emitter, which is a
different (much larger) track.
The user explicitly requested the biggest in-depth report I can
muster at 478,992 tokens (94% of context window). The next
session will start with a fresh context; these two documents are
the minimum-sufficient anchor.
docs/reports/session_synthesis_20260608.md (579 lines, 40KB):
- 12 sections covering every artifact this session produced
- The 5 sources loaded: 2 YouTube transcripts + 2 Fleury
articles + user's chunk-ideation archive
- The 10 commits in the session's commit chain (with the
user's test-fragility work adjacent but not mine)
- The 4 audit-time heuristics derived from the 5-source lens
- The "what the user should know" section for next session
docs/reports/proposed_new_tracks_20260608.md (190 lines, 12KB):
- 2 new tracks proposed (manual_ux_validation_20260608_PLACEHOLDER,
chunkification_optimization_20260608_PLACEHOLDER) with
spec-ready detail
- 8 non-recommendations (so the user knows what I'm NOT
suggesting)
- A "what I'd recommend" section with one-tracks-when
sequencing
No code modified. Both are session-final artifacts, not tracks.
They live in docs/reports/ alongside the other session outputs
(SSDL digest, ASCII-sketch workflow, chunk ideation archive).
Cross-references the 5 sources (all committed to docs/transcripts/
and docs/ideation/ in earlier user commits):
- docs/transcripts/wo84LFzx5nI_big_oops_casemuratori.txt
- docs/transcripts/i-h95QIGchY_assuming_as_much_as_possible_andrewreece.txt
- docs/ideation/ed_chunk_data_structures_20260523.md
- docs/reports/computational_shapes_ssdl_digest_20260608.md
- docs/reports/ascii_sketch_ux_workflow_20260608.md
These 5 documents are the session's "thinking-aid" corpus. The
synthesis is the *index*; together they're the minimum-sufficient
context to re-anchor any future session.
PR3 of the test_full_live_workflow_imgui_assert fix sequence.
When a prior live_gui test in the same session crashes the GUI (e.g.
via an ImGui IM_ASSERT from cumulative panel state), the controller's
_io_pool gets shut down. The next test starts in a degraded state
but only discovers this 120s later when its project switch times
out with a confusing 'cannot schedule new futures after shutdown'
error.
This commit adds a /api/gui_health pre-flight check at the start of
test_full_live_workflow. If the GUI is degraded, the test fails
fast (within 1s) with a clear, actionable message that includes:
- The exact RuntimeError that caused the degradation
- The full traceback of the last ImGui scope mismatch
- A note that the new test cannot proceed with a dirty state
Per user feedback 2026-06-08: 'I don't want a batch to be too fragile
where I can't restart the app and continue with the next test file
if it fails. Just has to note that the new file didn't get to deal
with a dirty state.'
Also includes the planning documents written earlier in this session:
- TODO_test_full_live_workflow_v2.md (task list)
- test_full_live_workflow_imgui_assert_20260608.md (root cause report)
- test_full_live_workflow_propagation_digest_20260608.md (solutions digest)
- batch_resilience_plan_20260608.md (batch resilience plan)
Verification:
- test_full_live_workflow in isolation: 13.45s PASS (health=True, no degrade)
- 4 sims + test_full_live_workflow in batch: 76.46s (1 FAIL fast, 4 sims PASS)
- Without PR3 fix: 200s FAIL with confusing 120s timeout
- With PR3 fix: 76s FAIL with clear 'GUI is degraded' message
- The fast-fail is observable, not silent (per user's 'wrap might be
worth it if that properly lets us handle the assert')
Gitea (and any case-sensitive filesystem) was rendering the [Top]
nav links in /docs as broken because of two bugs:
1. Case-sensitivity: 22 links used '../README.md' (all-uppercase)
but the actual file is 'docs/Readme.md' (capital R, lowercase
rest). 21 guide_*.md nav bars were affected, plus 1 internal
cross-link in Readme.md itself. Works on Windows (case-
insensitive) but broken on Linux/Gitea.
Fix: 22 occurrences across 22 files changed
'../README.md' -> '../Readme.md'
2. Wrong relative-path level: 16 links used '../../conductor/...'
from 'docs/guide_*.md' to reach 'conductor/'. This goes up 2
levels to 'projects/', which doesn't exist. The correct path
from 'docs/guide_*.md' to 'conductor/' is 1 level up
('../conductor/...'). 12 unique patterns across 10 files
affected.
Fix: 16 occurrences across 10 files changed
'../../conductor/' -> '../conductor/'
3. Bonus: 1 planned-guide link in guide_context_curation.md
referenced a never-written 'guide_context_presets.md'. The
ContextPreset schema is now fully covered in the new
'guide_context_aggregation.md' (per the 2026-06-08 docs
refresh). Fix: link target updated.
No content was changed, only link paths. 24 files, 37 link
replacements, 37 deletions.
Verification:
- All .md links in docs/ now resolve to existing files
(validated by path-resolution check from each file's directory)
- The 3 new guides from the previous docs refresh commit
(guide_discussions.md, guide_state_lifecycle.md,
guide_context_aggregation.md) had the case bug inherited from
guide_architecture.md's existing nav pattern; their top-of-file
nav bars are now correct
- The 21 pre-existing guide nav bars that had the same bug
(all 21 of them, except the 3 that used the correct case:
guide_mma.md, guide_simulations.md, guide_tools.md) are now
also fixed
- Inter-guide links (e.g. [Discussions](guide_discussions.md))
were not affected; they were always correct because both the
link text and the actual filename are lowercase
This is a docs-only fix. No code modified.
Per the docs Refresh Protocol (conductor/workflow.md), after a
reference/analysis track ships, the affected guides must be updated
to reflect new module structure or new conventions. The nagent_review
track (9cc51ca9) produced a deep-dive + 10 actionable takeaways that
named 3 documentation gaps in /docs. This commit fills them.
3 new guides (1,122 lines total):
1. guide_discussions.md (353 lines) — The Discussion system
- 23-operation matrix: A1-A7 per-entry + B1-B11 discussion-level
+ C1-C5 undo/redo
- Take naming convention (<base>_take_<n>), branching, promotion
- User-managed role list (app.disc_roles)
- Per-role filter linked to MMA persona focus
- _disc_entries_lock thread-safety contract
- Hook API session endpoints
- Persistence: _flush_to_project, _flush_disc_entries_to_project,
context_snapshot
- 9 file:line refs into gui_2.py:3770-4260 + history.py
2. guide_state_lifecycle.md (375 lines) — Undo/redo + reset + state
delegation
- HistoryManager + UISnapshot (13 captured fields, 100-snapshot
capacity, debounced change-detection at render frame)
- _handle_reset_session (clears 30+ fields, replaces project,
preserves active_project_path per the 2026-06-08 regression fix)
- App.__getattr__/__setattr__ state delegation to Controller
- 4-thread access pattern with 7 lock-protected regions
- State persistence: in-memory vs project TOML vs config TOML
- Hot-reload integration
- Hook API registries (_predefined_callbacks, _gettable_fields)
- 14 file:line refs into gui_2.py:1140-1170, history.py,
app_controller.py:3286-3356
3. guide_context_aggregation.md (394 lines) — The aggregate.py
pipeline
- 3 aggregation strategies (auto, summarize, full)
- 7 per-file view modes (full, summary, skeleton, outline,
masked, custom, none)
- Full FileItem schema (9 fields + __post_init__ normalizer)
at models.py:510-559
- ContextPreset schema and ContextPresetManager
- Tier 3 worker variant (build_tier3_context with FuzzyAnchor
re-resolution and focus-file handling)
- force_full / auto_aggregate short-circuits
- Cache strategy (static prefix + dynamic history)
- 23 file:line refs into aggregate.py:36-518 + models.py:909-937
8 existing guides cross-linked to the 3 new guides and to the
nagent_review track:
- guide_gui_2.md (+ See Also entries for discussions,
state lifecycle, context aggregation,
nagent_review report)
- guide_app_controller.md (+ See Also entries for discussions,
state lifecycle, context aggregation,
nagent_review report)
- guide_context_curation.md (+ new See Also section pointing to
context aggregation + nagent_review)
- guide_architecture.md (+ new See Also section listing all 10
guides + nagent_review report)
- guide_ai_client.md (+ See Also entries for state lifecycle,
context aggregation, nagent_review
pitfalls #2 and #4)
- guide_mma.md (+ new See Also section pointing to
context aggregation, discussions,
nagent_review report §9 + takeaways §3/§10
for SubConversationRunner priority)
- guide_models.md (+ See Also entries for context
aggregation, discussions, nagent_review
report §6 on FileItem as strongest
curation dimension)
- Readme.md (+ 3 new guide entries in the index
table, with one-line summaries)
No code modified. This is documentation only.
Why these 3 guides specifically:
- guide_discussions.md: The discussion system is the user's most
edited surface. nagent_review's report §3 enumerated 23 operations
(A1-C5) that previously existed only as scattered file:line refs
across gui_2.py. A dedicated guide makes the operation matrix
discoverable.
- guide_state_lifecycle.md: The undo/redo + reset + state delegation
machinery is architecturally load-bearing but scattered across 4
files. After nagent_review identified the provider-side history
divergence as Pitfall #4, the relationship between Manual Slop's
state and the provider's state needs explicit documentation.
- guide_context_aggregation.md: aggregate.py (518 lines) is the
most-touched module after ai_client.py but had no dedicated
guide. nagent_review confirmed it's Manual Slop's strongest
curation dimension. A dedicated guide makes the 7 view modes
and 3 strategies discoverable.
The 3 new guides total 1,122 lines and follow the existing
per-source-file deep-dive style (architectural, data-oriented,
state-management-focused).
Every direct dep in pyproject.toml now has a ~X.Y.Z bound
(patch-only). The 7 unconstrained deps (imgui-bundle,
anthropic, google-genai, openai, fastapi, mcp, uvicorn,
plus tomli-w) get explicit tilde bounds discovered from
uv.lock. The 6 >=X.Y.Z deps are normalized to tilde-style
(pinned to the current lock version).
The local-rag optional dep (sentence-transformers) is also
tilde-pinned.
requirements.txt is deleted (was redundant with uv.lock;
the uv project uses uv.lock as the canonical lock file,
which is regenerated locally and gitignored per project
policy at .gitignore:9).
Re-running the audit confirms 0 PIN_VIOLATION (was 7). The
final.md report records the post-cleanup state.
Also adds --report-name CLI flag to the audit script
(default 'initial') so the script can write either
initial.md (Phase 1) or final.md (Phase 2) into the same
report directory.
scripts/audit_license_cve.py: 4 internal checks (license +
CVE + pin + source-header), policy tables (allowlist of
permissive/weak-copyleft/public-domain, blocklist of
non-OSI/restricted-source), and a main() that runs all 4
and emits line-per-violation to stdout + a markdown report.
Tests (26 unit + integration) cover license classifier (16
variants across MIT, BSD, Apache, LGPL, MPL, CC0, WTFPL,
GPL, AGPL, SSPL, BSL, Commons Clause, Elastic, Anti-996,
Hippocratic, unknown), pin check (3), source-header check
(3), license check via importlib.metadata (1), CVE check
via subprocess pip-audit (2), and a smoke test of the main
loop (1).
No new pip deps in the project: pure stdlib
(importlib.metadata, tomllib, pathlib, re) + subprocess to
pip-audit (optional dev tool, installed via 'uv tool install
pip-audit' if user wants CVE checks).
Initial report at docs/reports/license_cve_audit/2026-06-07/
records the current state. The Phase 2 commit will apply
the fixes (tilde-pin, delete requirements.txt); the Phase 3
commit will add --strict mode + baseline file for CI.
Single-session planning digest that captures:
- The 5 tracks fully specced + planned (test_batching, qwen_llama_grok,
data_oriented_error_handling, data_structure_strengthening,
mcp_architecture_refactor)
- Cross-cutting design themes (data-oriented, audit-driven, per-track
commit + git note, out-of-scope-by-default)
- The audit + data foundation (scripts/audit_weak_types.py; 430 -> 60
finding; 0 strong patterns; 26 unique type strings; 86% concentrated
in 6 files)
- The dependency graph + recommended execution order
- Follow-up tracks already planned in spec §12.1 of each track
- Recommended future tracks (post-tracks documentation is the top pick)
- Risks, open questions, and a complete file index
This is the kind of reference document that:
- Future planners consult to understand the codebase's current state
- The implementing agent uses to coordinate across tracks
- The user reviews as a digest of the planning work
Written in the project's docs/reports/ directory alongside the existing
Phase 5 reports (PHASE5_STABILISATION_REPORT.md, MUTATION_MATRIX_PHASE5.md, etc.).
ed
conductor-tier2