Phase 6 of qwen_llama_grok_integration_20260606 ships the docs.
4 of 5 state tasks done (t6.3 CANCELLED per user directive:
'we can then doc this we're not archiving yet, if we have a follow up
track I need this one to stay up because there is still alot todo').
What shipped:
- t6.1: docs/guide_ai_client.md updated
- Overview mentions 8 providers (was 5)
- New 'Shared OpenAI-Compatible Helper' section: NormalizedResponse,
OpenAICompatibleRequest, send_openai_compatible, usage pattern
- Documents the Qwen adapter (src/qwen_adapter.py) and Llama
multi-backend state (3 backends; _get_llama_cost_tracking)
- Tests: 9 total (3 capabilities + 6 openai_compatible)
- t6.2: docs/guide_models.md updated
- PROVIDERS list: 5 -> 8 entries
- t6.4: conductor/tracks.md updated
- Status note on the qwen track entry: 50/79 tasks done;
Phase 6 in progress; NOT archiving; points to the follow-up
- t6.5: this checkpoint (active-with-follow-up, not archived)
- CANCELLED: t6.3 (no git mv to archive)
- CANCELLED: t6.4 'Recently Completed' move (track is active)
What was created in addition (not in the original Phase 6 plan):
- docs/reports/qwen_llama_grok_followup_audit_20260611.md
- Audit report explaining why a follow-up is needed
- 7 categories of gaps from the parent track
- The Tech Lead's 'footnote for now' failure mode (lessons learned)
- conductor/tracks/qwen_llama_grok_followup_20260611/
- 5-phase follow-up track: tool loop lift, PROVIDERS move,
UX adaptations 2-9, local-first + matrix v2,
Anthropic/Gemini/DeepSeek migration
- spec.md, state.toml, metadata.json, TODO.md
- Local-model-first priority per user feedback
- Wait for parent's Phase 6 to finish before starting (blocked_by)
Verification:
- 38/38 regression tests pass in batch
- No new audit script violations
- 4 new files in follow-up track: spec.md, state.toml,
metadata.json, TODO.md
- 1 new report: docs/reports/qwen_llama_grok_followup_audit_20260611.md
- 2 docs files updated: guide_ai_client.md, guide_models.md
The parent track remains ACTIVE (not archived) for the follow-up to
use as a reference. Per the user's 'there is still alot todo'.
Adds a status line to the qwen_llama_grok_integration_20260606 entry
in conductor/tracks.md noting that:
- Phases 1-5 are done; Phase 6 (docs) is in progress
- The track is NOT being archived (per user directive)
- A 5-phase follow-up track exists at
conductor/tracks/qwen_llama_grok_followup_20260611/
- An audit report is at docs/reports/qwen_llama_grok_followup_audit_20260611.md
- 50/79 tasks done; the remaining gaps are documented
Phase 6 t6.1 + t6.2 (no archive per user directive):
- docs/guide_ai_client.md: update Overview to mention 8 providers (was 5);
add 'Shared OpenAI-Compatible Helper' section explaining
src/openai_compatible.py (NormalizedResponse, OpenAICompatibleRequest,
send_openai_compatible, usage pattern); document the Qwen adapter
and Llama multi-backend.
- docs/guide_models.md: update PROVIDERS list to 8 entries (was 5).
- conductor/tracks.md: update the Qwen track entry to reflect
'50/79 tasks done; Phase 6 in progress; NOT archiving - has follow-up';
add detailed status note pointing to the follow-up track + audit
report.
- docs/reports/qwen_llama_grok_followup_audit_20260611.md: NEW report
explaining why a follow-up is needed (7 categories of gaps; the
Tech Lead's 'footnote for now' failure mode; the lessons learned).
- conductor/tracks/qwen_llama_grok_followup_20260611/: NEW follow-up
track setup (spec.md, state.toml, metadata.json, TODO.md).
5 phases: tool loop lift, PROVIDERS move, UX adaptations 2-9,
local-first + matrix v2, Anthropic/Gemini/DeepSeek migration.
Phase 6 t6.3 (git mv to archive) and t6.4 (mark Recently Completed)
are NOT applied per user directive: 'we can then doc this we're not
archiving yet, if we have a follow up track I need this one to stay
up because there is still alot todo'.
Phase 5 of qwen_llama_grok_integration_20260606 ships the foundation
for capability-driven UX. 4 of 6 state tasks done (t5.2 partial: 1 of 9
adaptations; t5.3 skipped; t5.5 cancelled: needs real API keys).
Shipped:
- t5.1: _get_active_capabilities() helper on App class
(src/gui_2.py:733) - reads the matrix for the active (provider, model)
pair; falls back to 'unregistered' VendorCapabilities if not found.
- t5.2 (partial): Adaptation 1 of 9 from spec §6 applied
- Screenshot button iff vision (render_files_and_media:3030)
- Pattern: caps = app._get_active_capabilities();
imgui.begin_disabled(not caps.<field>); ...UI...; imgui.end_disabled();
if not caps.<field>: imgui.same_line(); imgui.text_disabled('(reason)')
- t5.4: 38/38 regression batch passes
Skipped:
- t5.3: providers are exposed via centralized PROVIDERS in src/models.py
(already done in Phases 2 and 3); no per-provider gettable/callback
changes needed.
- t5.5: manual smoke test requires real API keys; user must do this
outside the agent context.
Deferred to follow-up (8 remaining UX adaptations):
- 2: Tools toggle iff tool_calling
- 3: Cache panel iff caching
- 4: Stream progress iff streaming
- 5: Fetch Models button iff model_discovery
- 6: Token budget max = context_window
- 7-9: Cost panel (3 cost_tracking states)
The pattern is established and the helper is in place. Each
remaining adaptation is a mechanical application of the same pattern
at its specific render site.
Verification: 38/38 regression tests pass.
After the end of Phase 5, only adaptation 1 of 9 from spec §6 was
applied (Screenshot button iff vision, render_files_and_media:3030).
The pattern is established; the remaining 8 are mechanical
applications of the same pattern at their respective render sites.
The follow-up track applies the wrapping at:
- tools toggle (tool_calling)
- cache panel (caching)
- stream progress (streaming)
- fetch models button (model_discovery)
- token budget max (context_window)
- cost panel (3 cost_tracking states: estimate / 'Free (local)' / '-')
The _get_active_capabilities() helper (t5.1) is already in place.
Phase 5 t5.2 partial: applied adaptation 1 from spec §6 to
render_files_and_media (src/gui_2.py:3030).
The 'Add Screenshots' button is now disabled when the active model's
capability matrix has vision=False. A tooltip-adjacent text_disabled
note shows '(vision not supported by <model>; attachments would be
ignored)' so the user knows WHY the button is disabled.
Pattern established for the remaining 8 adaptations (t5.2.2 through
t5.2.9 per spec §6):
caps = app._get_active_capabilities()
imgui.begin_disabled(not caps.<field>)
... UI ...
imgui.end_disabled()
if not caps.<field>:
imgui.same_line()
imgui.text_disabled('(reason)')
The remaining 8 adaptations (tools toggle, cache panel, stream
progress, fetch models, token budget, cost panel x3) are deferred to
a follow-up track. The pattern is established; the work is
mechanical application of it.
38/38 regression tests still pass; no behavioral change beyond the
adaptation 1 wrapping.
Phase 5 t5.1: the helper reads the capability matrix for the currently
active (provider, model) pair and returns the VendorCapabilities.
Falls back to an 'unregistered' VendorCapabilities if the pair is
not in the registry (e.g., a brand-new model name the user types in).
The 9 UX adaptations in spec §6 will call this helper to read the
capability flags (vision, tool_calling, caching, streaming, etc.)
and adapt the GUI accordingly.
Also fixed pre-existing indentation inconsistency in the App class
property methods (current_provider / current_model): the first
@property had 2-space indent but the body and subsequent def had
1-space indent (matching the project style). The mismatch was
latent; the new helper exposed it. Now uniform 1-space indent.
38/38 regression tests still pass; no behavioral change beyond the
helper addition.
As of end of Phase 4, only _send_minimax has a working tool-call loop.
Phase 3 (Grok, Llama) and Phase 2 (Qwen) entry points are single-shot;
they call send_openai_compatible once and return without executing
tool_calls. If the user notices 'tool execution doesn't work for
Qwen/Grok/Llama' after Phase 5 ships, the fix is to lift the tool
loop into a shared run_with_tool_loop() helper that wraps
send_openai_compatible. The 4 existing vendors (_send_anthropic /
_send_gemini / _send_gemini_cli / _send_deepseek) already have the
same inline duplication, so the lift would also help those.
This is a follow-up track, not in scope for qwen_llama_grok_integration_20260606.
Phase 4 t4.4: the wildcard entry 'minimax/*' was the only minimax
registration; this adds specific entries for the 4 fallback model
names returned by _list_minimax_models() at src/ai_client.py:2112
('MiniMax-M2.7', 'MiniMax-M2.5', 'MiniMax-M2.1', 'MiniMax-M2').
Each per-model entry mirrors the wildcard defaults (context_window=131072,
cost=0.20/0.20 per Mtok). Per-model entries let the matrix return
exact capability data for known models; the '*' wildcard still catches
new / future model names that aren't in the registry.
State [openai_compatible_models] minimax_models_refactored flag
flips to true (in the next state commit) -- this is the model-level
coverage the flag tracks.
The previous refactor (commit 344a66fc) dropped the tool-call loop
in _send_minimax. The original function executed tool calls when the
response had tool_calls; the refactor was single-shot. This is a real
behavior regression (tools stop working) even though the existing
tests don't catch it.
Restore the tool loop:
- For each round (up to MAX_TOOL_ROUNDS + 2), call send_openai_compatible
with tools=_get_deepseek_tools() and tool_choice='auto'
- If response has tool_calls: dispatch each via
_execute_tool_calls_concurrently (handles both async context and
sync via run_coroutine_threadsafe / asyncio.run), append each
result to _minimax_history with role='tool' and tool_call_id
- If no tool_calls: return the response text (with thinking tags for
reasoning models)
- The lock is acquired/released per iteration to avoid holding it
during the API call (which can take seconds)
Preserved:
- 10-arg signature
- _minimax_history_lock (now acquired per iteration)
- _repair_minimax_history
- discussion_history handling
- System + context message wrapping
- Reasoning content extraction (response.raw_response.choices[0].message
.reasoning_details[0].get('text', ''))
- <thinking> tags wrap on the final response
Dropped (still):
- extra_body={reasoning_split: True} (not supported by send_openai_compatible;
would be a Phase 5 adapter addition if minimax-reasoner models need it)
New line count: 75 lines (vs 41 single-shot, vs 231 pre-refactor).
Net effect: 231 -> 75 = 68% reduction; tool loop preserved.
Verification: 38/38 tests pass (no regressions).
Phase 3 of qwen_llama_grok_integration_20260606 ships Grok and Llama
provider support. 16 of 18 state tasks done (t3.4 and t3.15 cancelled:
no credentials_template.toml exists; t3.6 and t3.17 completed in
Phase 1's initial registry population).
Modules shipped:
- src/ai_client.py: state globals (_grok_*, _llama_* including _llama_base_url
and _llama_api_key), _ensure_grok_client() (OpenAI SDK with base_url
https://api.x.ai/v1), _ensure_llama_client() (OpenAI SDK with
configurable base_url + api_key for Ollama/OpenRouter/custom backends),
_send_grok() and _send_llama() (both 10-param signature matching
_send_minimax, both call send_openai_compatible), _list_grok_models()
and _list_llama_models() (return from capability registry),
_get_llama_cost_tracking() (the local-LLM signal: returns False when
base_url is localhost/127.0.0.1), 2 new branches in list_models(),
Grok + Llama state reset in reset_session()
- src/models.py: 'grok' and 'llama' added to PROVIDERS (centralized;
gui_2.py and app_controller.py import from this list)
- src/cost_tracker.py: 11 new regex pricing entries (3 Grok + 8 Llama)
Tests shipped:
- tests/test_grok_provider.py (28 lines, 2 tests)
- tests/test_llama_provider.py (68 lines, 6 tests)
- Total new tests this phase: 8 (all passing)
- Cumulative: 38 tests in batch (qwen + grok + llama + minimax + caps +
openai_compat + cost + no_top_level_sdk_imports)
Architectural correction (Grok-consulted 2026-06-11):
- Spec section 3.1.1 added: 'best API per vendor' principle
- Spec section 4.3 reverted from 'Native REST API' to 'OpenAI-Compatible'
per Grok's own confirmation: 'the OpenAI-compatible endpoint is
fully compatible and clean with no meaningful unique native surface
lost'
- Follow-up track B renamed: 'Llama Native APIs' (Ollama native +
Meta Llama API), not 'Native Vendor APIs' (no Grok native refactor
needed)
- v2 matrix field expansion documented (per Grok's recommendation):
audio, video, grounding, computer_use, local, reasoning,
web_search, x_search, code_execution, file_search, mcp_support,
structured_output
Deviations from plan (consistent with Phase 1 and Phase 2):
- Test signatures use 10-arg (real _send_minimax shape), not 12-arg
- PROVIDERS change is at src/models.py:56 (centralized), not in
gui_2.py and app_controller.py (which import from models)
- t3.4 and t3.15 (credentials template) skipped: no template file
exists; the user maintains their own credentials.toml directly
Phase 4 (MiniMax refactor) is now unblocked. The refactor replaces
~250 lines of inline OpenAI-compatible send logic in _send_minimax
with a thin wrapper around the shared send_openai_compatible helper
(per the spec §5.2 target: ~50 lines).
Side concerns for Phase 3:
1. PROVIDERS: src/models.py:56 now includes 'grok' and 'llama' alongside
the 6 existing vendors. Centralized registry; gui_2.py and
app_controller.py import from here. State tasks t3.5 and t3.16
were scoped to gui_2.py/app_controller.py but the actual change
is at the centralized registry, per the project's single-source-of-
truth pattern (per src/models.py module docstring and the Phase 5
audit script audit_no_models_config_io.py which enforces that
PROVIDERS lives in models.py).
2. cost_tracker.py: added 11 regex pricing entries (3 Grok + 8 Llama):
Grok (per xAI public pricing):
- grok-2: 2.00 / 10.00
- grok-2-vision: 2.00 / 10.00
- grok-beta: 5.00 / 15.00
Llama (per Grok's consultation: pricing varies by backend; registry
entries represent the most common case):
- llama-3.1-8b-instant: 0.05 / 0.08 (Groq)
- llama-3.1-70b-versatile: 0.59 / 0.79 (Groq)
- llama-3.1-405b-reasoning: 3.00 / 3.00 (OpenRouter avg)
- llama-3.2-1b-preview: 0.04 / 0.04
- llama-3.2-3b-preview: 0.06 / 0.06
- llama-3.2-11b-vision-preview: 0.18 / 0.18
- llama-3.2-90b-vision-preview: 0.90 / 0.90
- llama-3.3-70b-specdec: 0.59 / 0.79 (Groq)
(all per 1M tokens, USD; matches the structure of existing entries;
note: 'llama-3.1', 'llama-3.2', 'llama-3.3' are regex patterns to
allow future model variants in the same family.)
Spot check:
- estimate_cost('grok-2', 1000, 500) = 0.007 (= 0.002 + 0.005)
- estimate_cost('llama-3.3-70b-specdec', 1000, 500) = 0.000985
3. SKIPPED t3.4 and t3.15 (credentials templates): no
credentials_template.toml exists in the project (Phase 2 established
this). The user maintains their own credentials.toml directly.
4. t3.6 and t3.17 (Grok/Llama models in capability registry) were
completed in Phase 1's initial population of 22 entries
(commit 6be04bc). Grok has 4 entries (1 wildcard + 3 models);
Llama has 9 entries (1 wildcard + 8 models). Grok-2-vision has
vision=True; Llama 3.2-11b/90b vision variants have vision=True.
Verification: 38/38 tests pass in batch.
Grok's own recommendation (consulted 2026-06-11):
'xAI (Grok) | xAI official OpenAI-compatible (https://api.x.ai/v1) |
Fully compatible and clean. Supports Grok-2 + Grok-2-Vision. No
meaningful unique native surface lost by using the compatible
endpoint.'
This REVERSES the earlier 'xAI native' correction. The OpenAI-
compatible approach for Grok is the canonical full-featured path;
the implementation in Phase 3 (OpenAI SDK with base_url=https://api.x.ai/v1
+ send_openai_compatible helper) is correct as-is.
Updates to the spec:
1. §3.1.1: replaced the 'use xAI native' decision with the confirmed
per-vendor table. Qwen=Native, Grok=OpenAI-Compatible (per Grok's
own confirmation), MiniMax=OpenAI-Compatible, DeepSeek=OpenAI-
Compatible, Ollama=OpenAI-Compatible-in-v1 (native in v2),
Meta Llama API=Native (new 4th backend, follow-up), Gemini=Native
(follow-up), Anthropic=Native (follow-up). Also added Grok's
recommended v2 matrix field expansion: audio, video, grounding,
computer_use, local, reasoning/extended_thinking, web_search,
x_search, code_execution, file_search, mcp_support, structured_output.
2. §4.3: reverted from 'Grok via xAI (Native REST API)' back to
'Grok via xAI (OpenAI-Compatible) - confirmed 2026-06-11'. The
implementation does NOT need a native refactor; the OpenAI SDK
at https://api.x.ai/v1 is the canonical approach. Removed the
earlier 'caching: true' entry from the registry (since the
OpenAI-compat shim doesn't expose prompt_cache_key) and the
'no persistent client' state struct (back to the OpenAI SDK
pattern).
3. §13.1.B: renamed from 'Native Vendor APIs' to 'Llama Native APIs
(Ollama native + Meta Llama API)' and removed the Grok native
refactor item (Grok says OpenAI-compat is fine). Kept the Ollama
native + Meta Llama API items + matrix expansion. Clarified that
Grok tests do NOT need rewriting; only Llama tests get 2 more
(native Ollama, Meta Llama API).
Net effect: the Phase 3 work that just shipped (Grok+Llama Green
using OpenAI-compat shim) is CORRECT as-is. The implementation
matches Grok's actual recommendation. No code rollback needed.
Three additions to the spec, per the user's architectural correction
in this session:
1. NEW section 3.1.1: 'Architectural principle: Use the best API per
vendor' — explains why the OpenAI-compatible shim loses vendor-
specific features (xAI: prompt_cache_key, reasoning_effort, server-
side tools, cost_in_usd_ticks; Ollama: think param, images array,
thinking field, structured outputs) and states the principle:
'use each vendor's native SDK or REST API when one exists, falling
back to OpenAI-compatible only when no native option exists.'
Also notes that the capability matrix IS the aggregate tracker;
future native features go into the matrix, and the GUI filters
based on it (no per-vendor UI branches).
2. UPDATED section 4.3 (Grok): 'Grok via xAI (Native REST API)' — was
'OpenAI-Compatible'. Now specifies two native endpoints
(/v1/chat/completions and /v1/responses), the native features that
matter, the updated capability registry (caching=true for Grok
via prompt_cache_key), and a 'Phase 3 placeholder behavior' note
that this track's Phase 3 ships the OpenAI-compatible Grok as a
placeholder. The native refactor is deferred to follow-up B.
3. UPDATED section 13.1: added follow-up track B 'Native Vendor APIs
(post-OpenAI-compatible-placeholder)' which documents:
- Grok → xAI native REST
- Llama (Ollama) → native /api/chat
- Llama (Meta Llama API) → new 4th backend (deferred pending
verification of Meta's API spec; llama.developer.meta.com/docs/overview
returned 400 on fetch this session)
- Capability matrix expansion (web_search, x_search, code_execution,
file_search, mcp_support, reasoning_effort, structured_output)
- Test rewrites (mock requests.post instead of chat.completions.create)
This is a docs-only commit; no code changes. The Phase 3 Green work
continues with the OpenAI-compatible approach as planned in the
existing Red tests (t3.3 Grok + t3.14 Llama), and the follow-up track
B handles the native refactor when prioritized.
8 failing tests in 2 new files for the upcoming Grok and Llama
provider implementations.
Grok (tests/test_grok_provider.py, 2 tests):
1. test_send_grok_uses_xai_endpoint: _send_grok calls _ensure_grok_client
and uses an xAI client (base_url https://api.x.ai/v1)
2. test_grok_2_vision_supports_image: structural check that the
capability registry has vision=True for grok-2-vision (already
populated in Phase 1, so this test passes in Red phase; it is a
regression guard for the registry, not an implementation test)
Llama (tests/test_llama_provider.py, 6 tests):
1. test_send_llama_ollama_backend: _send_llama with localhost:11434
(Ollama) base URL
2. test_send_llama_openrouter_backend: _send_llama with OpenRouter URL
3. test_send_llama_custom_url: _send_llama with custom URL
(escape hatch for self-hosted)
4. test_llama_model_discovery_unions_ollama_and_openrouter: _list_llama_models
returns the 8 models from the capability registry
5. test_llama_3_2_vision_vision_capability: structural check for
llama-3.2-11b-vision-preview (passes in Red phase)
6. test_llama_local_backend_cost_tracking_false_for_ollama: the local-LLM
signal -- when base_url is localhost, _get_llama_cost_tracking()
returns False. This is the first test that exercises the local LLM
support that the capability matrix was designed for.
Both _reset_grok_state and _reset_llama_state fixtures use hasattr() to
be no-ops when the state doesn't exist (Red phase).
Test signatures use the real 10-arg _send_minimax signature, NOT the
plan's 12-arg with enable_tools / rag_engine.
Red phase: 6/8 tests fail (4 AttributeError on missing _send_*,
2 ImportError on missing _list_*/_get_*). 2/8 pass (registry structural
checks).
Next: Green phase - implement _send_grok + _ensure_grok_client +
_send_llama + _ensure_llama_client + _list_llama_models +
_get_llama_cost_tracking in src/ai_client.py.
Phase 2 of qwen_llama_grok_integration_20260606 ships Qwen support via
the Alibaba Cloud DashScope native SDK. 10 of 11 state tasks done
(t2.7 cancelled: no credentials_template.toml exists in the project;
t2.9 was completed in Phase 1's initial registry population).
Modules shipped:
- src/qwen_adapter.py (31 lines): build_dashscope_tools() (OpenAI shape
-> DashScope shape), classify_dashscope_error() (5 exception classes
-> ProviderError kinds: auth/network/quota)
- src/ai_client.py: state globals (_qwen_client, _qwen_history,
_qwen_history_lock, _qwen_region), _ensure_qwen_client() (sets
dashscope.base_http_api_url based on region: china vs international),
_dashscope_call() + _dashscope_exception_from_response() +
_extract_dashscope_tool_calls(), _send_qwen() (10-param signature
matching _send_minimax), _list_qwen_models()
- src/models.py: 'qwen' added to PROVIDERS (centralized; gui_2.py and
app_controller.py import from this list)
- src/cost_tracker.py: 7 Qwen pricing entries (regex-matched,
USD per 1M tokens)
Tests shipped: tests/test_qwen_provider.py (55 lines, 5 tests, all passing)
Total new tests this phase: 5
Total tests in new modules: 30 (qwen + minimax + capabilities +
openai_compatible + cost_tracker + no_top_level_sdk_imports)
Verification:
- 30/30 tests pass in batch
- No regressions
- 4/4 audit scripts pass (audit_main_thread_imports, audit_weak_types,
check_test_toml_paths, audit_no_models_config_io)
DashScope alignment (post-cleanup):
- Uses dashscope.common.error.AuthenticationError (real class in
1.25.21) instead of the non-existent InvalidApiKey
- Removed the InvalidApiKey -> AuthenticationError monkey-patch
- TimeoutException -> network (not rate_limit)
- ServiceUnavailableError -> network (not quota)
- _ensure_qwen_client sets base_http_api_url per region (china vs
international) per the latest DashScope API spec
Deviations from the plan:
- Test signature adapted from 12-param (plan) to 10-param (matching
real _send_minimax) -- the plan's enable_tools / rag_engine params
don't exist on _send_minimax
- PROVIDERS change is at src/models.py:56 (centralized), not in
gui_2.py and app_controller.py (which import from models)
- t2.7 (credentials template) skipped: no template file exists;
the user maintains their own credentials.toml directly
Phase 3 (Grok + Llama) is now unblocked. Local LLM support lands
in Phase 3 via Llama's Ollama backend (default base_url
http://localhost:11434/v1).
Side concerns for Phase 2:
1. PROVIDERS: src/models.py:56 now includes 'qwen' alongside the existing
5 vendors. The other 4 references to PROVIDERS in src/gui_2.py and
src/app_controller.py import from this centralized list, so this
one edit propagates everywhere. State task t2.8 was scoped to
'gui_2.py and app_controller.py' but the actual change is at the
centralized registry, per the project's single-source-of-truth
pattern (per src/models.py module docstring and the Phase 5 audit
script audit_no_models_config_io.py which enforces that PROVIDERS
lives in models.py).
2. cost_tracker.py: added 7 regex pricing entries for the Qwen models
shipped in Phase 1's vendor_capabilities.py:
- qwen-turbo: 0.05 / 0.10
- qwen-plus: 0.40 / 1.20
- qwen-max: 2.00 / 6.00
- qwen-long: 0.07 / 0.28
- qwen-vl-plus: 0.21 / 0.63
- qwen-vl-max: 0.50 / 1.50
- qwen-audio: 0.10 / 0.30
(all per 1M tokens, USD; matches the structure of existing entries)
Spot check: estimate_cost('qwen-max', 1000, 500) = 0.005 (= 0.002 + 0.003)
3. SKIPPED t2.7 (credentials template): no credentials_template.toml
exists in the project. The only credentials file is the active
credentials.toml which the user maintains directly with their own
API keys. The plan's assumption of a template file does not match
the project's actual structure. Documented in the commit log
rather than modifying the user's actual credentials.toml with a
placeholder key (which would be inconsistent with the rest of
that file's pattern of real keys). When the user obtains a
DashScope API key, they can add a [qwen] section directly.
4. t2.9 (Qwen models in capability registry) was completed in Phase 1's
initial population of 22 entries (commit 6be04bc). The 8 qwen
entries (1 wildcard + 7 specific models) are in src/vendor_capabilities.py.
Verification: 30/30 tests pass in batch
(test_qwen_provider, test_minimax_provider, test_ai_client_no_top_level_sdk_imports,
test_vendor_capabilities, test_openai_compatible, test_cost_tracker)
5 failing tests in tests/test_qwen_provider.py that establish the
core behaviors of the new Qwen (DashScope) provider:
1. test_send_qwen_routes_to_dashscope: _send_qwen calls _ensure_qwen_client
and _dashscope_call, returns the text from the DashScope response
2. test_qwen_vision_vl_model_accepts_image: when file_items contains an
image, the messages passed to _dashscope_call include the image ref
3. test_qwen_tool_format_translation: build_dashscope_tools converts
OpenAI-shaped tool dicts to DashScope shape (name/description/parameters
flat structure, not wrapped in function:)
4. test_qwen_error_classification: classify_dashscope_error maps
dashscope.common.error.InvalidApiKey -> ProviderError(kind='auth',
provider='qwen')
5. test_list_qwen_models_returns_hardcoded_registry: _list_qwen_models
returns the 7 Qwen models registered in src/vendor_capabilities.py
The autouse _reset_qwen_state fixture uses hasattr() so it is a no-op
when _qwen_client / _qwen_history do not exist (yet); this keeps the
fixture working in the Red phase.
All 5 tests fail:
- Tests 1, 2: AttributeError: src.ai_client has no _ensure_qwen_client /
_send_qwen / _dashscope_call
- Tests 3, 4: ModuleNotFoundError: No module named src.qwen_adapter
- Test 5: ImportError: cannot import name _list_qwen_models
Test signature adapted to match the real _send_minimax signature at
src/ai_client.py:2143-2148 (10 params, no enable_tools / rag_engine)
rather than the plan's 12-param signature.
Next: Green phase - implement src/qwen_adapter.py + src/ai_client.py
state + _ensure_qwen_client + _send_qwen + _list_qwen_models.
Green phase: src/openai_compatible.py now exists and all 6 Red-phase
tests in tests/test_openai_compatible.py pass.
Implementation (144 lines, 1-space indent, no comments):
Data structures:
- NormalizedResponse: frozen dataclass with text, tool_calls,
usage_input_tokens, usage_output_tokens, usage_cache_read_tokens,
usage_cache_creation_tokens, raw_response
- OpenAICompatibleRequest: regular dataclass with messages, model,
temperature=0.0, top_p=1.0, max_tokens=8192, tools=None,
tool_choice='auto', stream=False, stream_callback=None
Algorithms:
- send_openai_compatible(client, request, *, capabilities) -> NormalizedResponse
Dispatches to _send_blocking or _send_streaming based on request.stream.
Catches openai.OpenAIError and re-raises as classified ProviderError.
- _send_blocking: extracts message text + tool_calls, converts tool_calls
to dicts via _to_dict_tool_call, reads usage.prompt_tokens /
usage.completion_tokens (with int() coercion for MagicMock test compat).
- _send_streaming: iterates chunks, accumulates text parts, aggregates
tool_calls by index, fires stream_callback per text delta, reads
chunk.usage for final token counts.
- _classify_openai_compatible_error: maps RateLimitError -> 'rate_limit',
AuthenticationError/PermissionDeniedError -> 'auth', APIConnectionError
-> 'network', APIStatusError with 402/429/401-403/500-504 -> 'balance'/
'rate_limit'/'auth'/'network', BadRequestError -> 'quota', fallback
'unknown'. All use provider='openai_compatible'.
Fixed plan's code smell: removed the 'MagicMock_noop' forward-reference
class (defined after first use) and replaced with the cleaner Pythonic
pattern 'int(getattr(usage, prompt_tokens, 0) or 0)'. Real OpenAI SDK
always sets usage on responses; the defensive fallback was noise.
Function-level import of ProviderError inside _classify_openai_compatible_error
avoids any circular import risk.
6 failing tests in tests/test_openai_compatible.py that establish the
core behaviors of the new send_openai_compatible() shared helper:
1. test_send_non_streaming_returns_normalized_response: blocking call
returns text, empty tool_calls, and correct usage token counts
2. test_send_streaming_aggregates_chunks: streaming call aggregates
deltas into final text and fires stream_callback per chunk
3. test_tool_call_detection_in_response: tool_calls from the response
are converted to dicts with id/type/function/arguments fields
4. test_vision_multimodal_message: messages with multimodal content
(text + image_url) are passed through unchanged to the client
5. test_error_classification_429_to_rate_limit: RateLimitError from
openai SDK is caught and re-raised as ProviderError(kind='rate_limit')
6. test_normalized_response_is_frozen_dataclass: NormalizedResponse is
a frozen dataclass (FrozenInstanceError on attribute assignment)
All 6 tests fail with ModuleNotFoundError: No module named
'src.openai_compatible' (confirmed via pytest). The implementation file
will be created in the next commit (Green phase).
ProviderError confirmed importable from src.ai_client (no stub needed).
Green phase: src/vendor_capabilities.py now exists and all 3 Red-phase
tests in tests/test_vendor_capabilities.py pass.
Implementation:
- VendorCapabilities frozen dataclass with 12 fields (vendor, model, vision,
tool_calling, caching, streaming, model_discovery, context_window,
cost_tracking, cost_input_per_mtok, cost_output_per_mtok, notes)
- Module-level _REGISTRY dict keyed by (vendor, model)
- register() inserts/overwrites entries
- get_capabilities() returns specific entry if present, else vendor '*'
default, else raises KeyError with 'No capabilities registered' message
- list_models_for_vendor() returns sorted model names for a vendor
(excludes '*' wildcard)
Initial population (22 entries at module load):
- 1 minimax wildcard (cost: 0.20/0.20 per Mtok)
- 4 grok (1 wildcard + 3 models; grok-2-vision has vision=True)
- 9 llama (1 wildcard + 8 models; 11b/90b vision variants have vision=True)
- 8 qwen (1 wildcard + 7 models; qwen-vl-plus/max have vision=True;
qwen-audio has notes='Text-only in v1; audio input deferred')
The plan's Task 1.3 listed 22 entries but included one impossible entry
(vendor='minimax', model='grok-2-latest'). Omitted; 21 entries shipped.
Test fix: test_fallback_to_vendor_default previously used model name
'llama-3.3-70b-specdec' which IS in the registry, so the specific entry
was returned (with default cost_tracking=True), not the wildcard. Fixed
by changing to 'llama-3.3-future-unregistered' (not in registry, so
fallback fires correctly).
3 failing tests in tests/test_vendor_capabilities.py that establish the
core behaviors of the new VendorCapability matrix:
1. test_registry_lookup_known_model: registering and looking up a specific
(vendor, model) entry returns the registered entry
2. test_fallback_to_vendor_default: looking up an unregistered model returns
the vendor's '*' default entry
3. test_unknown_vendor_raises: looking up a vendor with no entries raises
KeyError with a 'No capabilities registered' message
All 3 tests fail with ModuleNotFoundError: No module named
'src.vendor_capabilities' (confirmed via pytest). The implementation file
will be created in the next commit (Green phase).
The autouse _clean_registry fixture snapshots src.vendor_capabilities._REGISTRY
before each test and restores it after, providing test isolation for the
module-level state.
Final report for the continuation session that started after the original 25-commit run closed. Covers:
Stats:
- 17 atomic continuation commits (db5ab0d9 -> 7d6dbbd3) plus 03056a4f for the closure summary itself
- 14 unique doc files modified
- 0 source files modified (continuation was docs-only)
- 11 source files read in full; ~20 outlined
- ~250 + lines, ~190 - lines across the doc edits
What was done (14 drift clusters with detailed before/after):
- guide_hot_reload.md: example registration + trigger_key claim
- guide_app_controller.md: filename typo + fictional hot_reload() method
- guide_gui_2.md: line 155 -> 285; reload() -> reload_all()
- guide_nerv_theme.md: 5 wrong hex values; render_nerv_fx fiction; [nerv] config fiction; 0.5 Hz -> 3.18 Hz; 1.5s pulse -> no decay
- guide_shaders_and_window.md: 3 fictional [nerv] config refs
- guide_command_palette.md: 11 -> 33 commands
- guide_mma.md: 5 algorithm drift points (has_cycle iterative, topological_sort Kahn's, tick no-promote, ConductorEngine.__init__ signature)
- guide_beads.md: dispatch line range
- guide_multi_agent_conductor.md: wholesale rewrite of pre-refactor architecture
- guide_tools.md: run_powershell signature (add patch_callback)
- guide_context_curation.md: FuzzyAnchor docstring (replace 'anchor_lines' with real field names)
- guide_simulations.md: CodeOutliner doc (add [ImGui Scope], return-type suffix, count guard)
- Readme.md: 3 line-level drift (45->46 MCP, 32->33 commands, shell_runner patch_callback)
- docs/Readme.md: file tree (24->27 guides with full alphabetical list)
- conductor/index.md: 23 -> 27 guides count
Drift patterns (6, refined from the 4 in the original handoff):
1. Thread counts
2. Line numbers
3. Removed-class claims
4. Schema fields
5. NEW: Architecture rotations (the most common in this continuation)
6. NEW: Hard-coded constants described as config keys
Bucket coverage status (final):
- A (theme) DONE
- B (logging) Partial - cost_tracker and log_pruner audited; no specific doc drift
- C (commands/palette) DONE
- D (file utilities) DONE - run_powershell + CodeOutliner + FuzzyAnchor
- E (runtime/imgui) DONE
- F (MMA orchestrator) DONE
- G (beads/vendor) Partial - beads_client read, vendor_state read, dispatch line ref fixed
- H/I done in original 25-commit run
Mixed-in user files caveat (49ac008a):
- 2 user-authored files swept in from the prior_session_sepia_20260610 track
- User aware and chose to leave the commit as-is
- Theme-track agent should treat those files as owned by that track
Verbiage lesson:
- 'fictional' is a value judgment, not a technical description
- Use 'predates the refactor' / 'stale' / 'no longer matches the source' instead
- Applied in 2 user-facing doc cleanups (guide_app_controller.md:59, guide_rag.md:322)
Recommendations for the theme-track agent:
- Read guide_themes.md:87 before touching the theme system
- Do NOT touch the guide_nerv_theme.md and guide_shaders_and_window.md updates from this session (re-verified against source)
- The theme_2.py:111 comment confirms the per-frame create-and-discard FX pattern
- Run all 4 audit scripts before committing any source code change
- The markdown_table.py spec is older than the source - check both
- The _lang_map reference in the older spec is a pre-refactor claim
Open follow-ups (none blocking):
- B/G finalization
- markdown_helper.py and markdown_table.py source verification (left for theme track)
- Test count verification (322 may drift)
- Doc freshness signal
12 atomic commits added after the original 25-commit run closed:
6 small drift fixes (db5ab0d9..28172135)
- guide_hot_reload.md: example registration + trigger_key claim
- guide_app_controller.md: src/hot_reload.py -> src/hot_reloader.py + hot_reload() method
- guide_gui_2.md: line 155 -> 285; reload() -> reload_all()
- guide_nerv_theme.md: 5 wrong hex values, stale apply_nerv body, stale
render_nerv_fx example, [nerv] config that was never wired, 0.5 Hz vs
actual 3.18 Hz flicker
- guide_shaders_and_window.md: 3 fictional [nerv] config refs
- guide_app_controller.md:68: self-referential io_pool docstring claim
1 mid-size fix (81e88241)
- guide_command_palette.md: command count 11 -> 33 (full source-derived
Action column for every @registry.register decorator in src/commands.py)
2 MMA rewrites (57143b7a, 394987f8, a49e5ffb, e0368174)
- guide_mma.md: has_cycle recursive -> iterative; topological_sort DFS ->
Kahn's; tick auto-promotion claim; ConductorEngine.__init__ missing
max_workers param
- guide_beads.md: bd_ tool dispatch line range
- guide_multi_agent_conductor.md: rewrote the TrackDAG and
ExecutionEngine/ConductorEngine/WorkerPool/mma_exec sections; the prior
doc predated the conductor_engine refactor and described a different
architecture (MultiAgentConductor class that doesn't exist, ExecutionMode
enum that doesn't exist, _dispatch_loop background thread that doesn't
exist, ThreadPoolExecutor-backed WorkerPool that is actually a
dict[str, Thread] + lock + semaphore)
2 verbiage cleanups
- replaced 'fictional' with neutral phrasing ('predates the refactor' /
'stale') in 2 places where the prior session had used it in user-facing
doc text. Going forward doc-drift commits use neutral language;
'fictional' was a value judgment on the doc and its author, not a
technical description.
Bucket coverage after continuation: A (theme), C (commands/palette), E
(runtime/imgui), F (MMA orchestrator) fully covered. B (logging) and G
(beads/vendor) partial. H/I (mcp_client/ai_client deep) done in original
25-commit run. Still untouched: D (8 file utilities), shaders.py / bg
shader.py, summary_cache.py.
Caveat for next agent (theme track): commit 49ac008a accidentally swept in
2 user-authored files from the parallel prior_session_sepia_20260610 work
(conductor/tracks/prior_session_sepia_20260610/plan.md and
docs/superpowers/plans/2026-06-10-prior-session-sepia.md). The user is
aware and chose to leave them in that commit. The next agent should treat
those files as owned by the prior_session_sepia_20260610 track and not
modify them from the theme-track context.
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.
The top-of-file docstring claimed 'logs/sessions/comms_<ts>.log' with
<ts> as a filename prefix. Actual: per-session subdir
'logs/sessions/<session_id>/' with plain filenames (comms.log,
toolcalls.log, apihooks.log, clicalls.log). The <ts>/session_id
is the PARENT DIR, not a filename prefix.
Per commit 73e1a36d (per-session subdirs), the per-session
directory is the unit of isolation. apihooks.log is a fourth
log file the old docstring omitted entirely.
Also added the new files (apihooks.log, outputs/ subdir) and
clarified the scripts/generated/ dual-write pattern.
Per IO_POOL_MAX_WORKERS = 8 (set in commit 4a338486 on 2026-06-06
to relieve contention during batched sims), the pool actually has
8 workers, not 4. The docstring was stale. Also added the SHAs
of the 4->8 bump for traceability.
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.
The Phase 6+ section had two duplicate '### Active' headers, which
made the chronology confusing. The user (paraphrased): preserve the
chronology of project progress, don't need full detail, follow the
previous restructure's lightweight pattern.
Changes:
- Add '### Recently Completed (2026-06-06 to 2026-06-10)' subsection
containing the 3 closed tracks (startup_speedup, test_batching_refactor,
test_infrastructure_hardening) with lightweight entries: per-phase
commit SHAs only, 1-line summary, link to spec/plan/state folder.
Trimmed the verbose per-sub-track commentary that was in the old
startup_speedup entry (the per-sub-track bullets for warmup, status
indicator, audit violations, post-shipping fixes are in the
archive's spec/plan, not the tracks.md).
- Remove the duplicate '### Active' header.
- Update section intro to reflect '3 recently completed, 4 in plan'
(was '2 already completed, 3 in plan').
- test_infrastructure_hardening entry now has phase commit SHAs
(5df22fa8, 67d0211e, 006bb114, b8fcd9d6, 33d5cac, 7b87bbf5,
84edb200, 719fe9a) instead of just the closing-report link.
Chronology is now visible at a glance; per-track full detail is
in the linked archive/ folder.
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.
These were authored at track start but missed by the final-state
commit. They are the brief 1-2 page design intent and executable
plan for the docs sync track. The closing report at
docs/reports/docs_sync_test_era_20260610.md summarizes the actual
17-commit execution.
- state.toml: status active->completed, all 25 tasks marked complete
with commit SHAs, all 4 phases checkpointed
- metadata.json: status active->shipped, 17-commit list, all 9
verification criteria flipped to DONE
- Structural Testing Contract (mirrors workflow.md)
- Isolated-Pass Verification Fallacy (Lesson 1, with link to the
test_infrastructure_hardening_batch_green_20260610 incident report
that motivated the rule)
- Audit Scripts as CI Gates (4 scripts: check_test_toml_paths,
audit_main_thread_imports, audit_weak_types, audit_no_models_config_io)
- Skip Markers Are Documentation, Not Avoidance (workflow.md policy)
Known Pitfalls (new subsection):
- HARD BAN: git checkout -- <file>, git restore, git reset
(per AGENTS.md Critical Anti-Patterns; destroyed user in-progress
edits twice on 2026-06-07; concrete 2026-06-10 incident:
mma_tier_usage_reset_fix regression)
Live_gui Test Fragility (2 new subsections):
- Anti-pattern: push_event + time.sleep(N) + assert is a race.
Fix: poll-until-state-visible with bounded retries. 5+ tests
affected in 2026-06-10 batch-green wave.
- Async setters need poll-for-state. mma_state_update and rag_*
setters dispatch to _pending_gui_tasks queue; the setter returns
before the GUI render loop processes the task. Assert immediately
= race. Fix: poll via get_value with bounded retry.
Lesson 5 from the 4-day test-hell saga. The chroma cache lives at
tests/artifacts/.slop_cache/chroma_<collection>/, NOT at the per-run
live_gui_workspace_<timestamp>/ subdir. The trailing-slash bug in
Path(active_project_path).parent places the cache one level higher
than expected.
RAG tests must pre-clean the cache to avoid persistent state from
prior batched runs. Documents the cleanup pattern (shutil.rmtree with
ignore_errors=True), the auto-recovery mechanism (_validate_collection_dim),
and 3 anti-patterns (assuming per-run, not cleaning, asserting on
first chunk in batched context).
New entry at the top of the Recently Shipped list, linking to the
archive/ folder. Includes:
- 314/314 green across all 11 tier batches
- FR1-FR5 summary
- 3 lineage tracks also archived
- The 4 unblocked tracks
- Link to the closing batch-green report
- Remove row 1 from Active Tracks table
- Update rows 2-5, 17: test_infrastructure_hardening_20260609 -> '(merged)'
- Mark test_infrastructure_hardening as [COMPLETE 2026-06-10] [archived]
- Update link to use archive/ instead of tracks/
- Add closing note: 314/314 tests green, lineage tracks also archived
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'
ed