Private
Public Access
0
0

docs(workspace_profiles+app_controller): fix 3 unverified claims surfaced by re-audit

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.
This commit is contained in:
2026-06-10 20:40:14 -04:00
parent 144127009c
commit 3e0c7702ad
2 changed files with 3 additions and 3 deletions
+2 -2
View File
@@ -69,14 +69,14 @@ The actual `__init__` (`src/app_controller.py:778-836`) does the following:
5. **Warmup manager**`WarmupManager(self._io_pool, log_to_stderr=log_to_stderr)` with an on-complete callback to stamp `warmup_done_ts`. `defer_warmup=True` defers the actual `start_warmup()` call until the first frame is painted (the desktop GUI pattern; headless mode starts immediately).
6. **Various flags**`_warmup_started`, `_pending_fetch_provider`, `_defer_warmup`.
**Manager objects** (`preset_manager`, `persona_manager`, `context_preset_manager`, `tool_preset_manager`, `tool_bias_engine`, `history_manager`, `workspace_manager`, `rag_engine`) are **NOT created in `__init__`**. They are lazy attributes accessed via `__getattr__` and created on first reference (typically from `_load_active_project` at `src/app_controller.py:2150` or from `App._post_init` at `src/gui_2.py:3995`).
**Manager objects** (`preset_manager`, `persona_manager`, `context_preset_manager`, `tool_preset_manager`, `tool_bias_engine`, `history_manager`, `workspace_manager`, `rag_engine`) are **NOT created in `__init__`**. They are lazy attributes accessed via `__getattr__` and created on first reference (typically from `_load_active_project` at `src/app_controller.py:2150` or from `App._post_init` at `src/gui_2.py:492`).
**Hook API surface** is NOT populated by a `register_hooks` method. The actual flow:
1. `AppController._init_actions()` (called from `init_state` at `src/app_controller.py:1740`) populates `self._predefined_callbacks` and `self._gettable_fields` registries via module-level handler registration functions.
2. `src/api_hooks.py:HookHandler.do_GET` / `do_POST` reads from these registries to expose App methods as `/api/gui` `custom_callback` actions.
3. The `sloppy.py` CLI parses `--enable-test-hooks` and passes it to `HookServer` (a separate class, not the controller).
For the actual init flow, read `src/app_controller.py:778-836` (`__init__`), `:1606` (`_init_actions`), `:1740` (`init_state`), and `:2150` (`_load_active_project`).
For the actual init flow, read `src/app_controller.py:778-1212` (`__init__`; the long range is mostly `_post_init`-style wiring for the 12 locks, GUI health state, io_pool, warmup manager, and lazy manager defs), `:1606` (`_init_actions`), `:1740` (`init_state`), and `:2150` (`_load_active_project`).
This is the **only** bridge between the GUI's app methods and the external Hook API. If a method is not in `_predefined_callbacks`, external callers cannot invoke it.