testing

2026-04-15 12:56:00 -06:00
parent ff3419a714
commit 63b6678e73
82 changed files with 14800 additions and 3310 deletions
@@ -0,0 +1,85 @@
+# Phase 1 Step 8l — Implementation Notes
+
+## Status
+
+Done (partial — `handle_spawn` migrated, other handlers kept on
+`&GlobalConfig` signatures).
+
+## Plan reference
+
+- Plan: `docs/PHASE-1-IMPLEMENTATION-PLAN.md`
+- Section: "Step 8l: Migrate `supervisor.rs` sub-agent spawning"
+
+## Summary
+
+Replaced `Config::use_agent(&child_config, ...)` in `handle_spawn`
+with a direct call to `Agent::init(&AppConfig, &AppState, ...)`,
+inlining the MCP reinit and agent state setup that `Config::use_agent`
+previously handled. The child `AppState` is constructed from the
+parent `GlobalConfig`'s data.
+
+All handler function signatures remain `&GlobalConfig` because they're
+called from `eval_tool_calls` → `ToolCall::eval(config)` which still
+passes `GlobalConfig`. Migrating the signatures requires migrating
+the entire tool evaluation chain first.
+
+## What was changed
+
+### Files modified (1 file)
+
+- **`src/function/supervisor.rs`** — `handle_spawn`:
+  - Builds `AppConfig` + `AppState` from parent `GlobalConfig`
+  - Calls `Agent::init(&app_config, &child_app_state, ...)` directly
+  - Inlines MCP reinit (take registry → reinit → append meta functions → put back)
+  - Inlines agent state setup (rag, agent, supervisor on child_config)
+  - Inlines session setup (`Config::use_session_safely` or `init_agent_shared_variables`)
+  - Added imports: `Agent`, `AppState`, `McpRegistry`, `Supervisor`
+
+## Key decisions
+
+### 1. Handler signatures unchanged
+
+All 12 handler functions still take `&GlobalConfig`. This is required
+because the call chain is: `eval_tool_calls(&GlobalConfig)` →
+`ToolCall::eval(&GlobalConfig)` → `handle_supervisor_tool(&GlobalConfig)`.
+Until `eval_tool_calls` is migrated (requires client module migration),
+the signatures must stay.
+
+### 2. Child still uses GlobalConfig for run_child_agent
+
+The child's chat loop (`run_child_agent`) still uses a `GlobalConfig`
+because `Input` and `eval_tool_calls` need it. The `Agent::init` call
+uses `&AppConfig` + `&AppState` (the new signature), but the agent's
+state is written back onto the child `GlobalConfig` for the chat loop.
+
+### 3. MCP reinit stays on child GlobalConfig
+
+The child agent's MCP servers are started via `McpRegistry::reinit`
+on the child `GlobalConfig`. This is necessary because the child's
+`eval_tool_calls` → MCP tool handlers read the MCP registry from
+the `GlobalConfig`. Using `McpFactory::acquire` would require the
+MCP tool handlers to read from a different source.
+
+## Verification
+
+- `cargo check` — clean, zero warnings
+- `cargo clippy` — clean
+- `cargo test` — 63 passed, 0 failed
+
+## What remains for supervisor.rs
+
+The handler signatures (`&GlobalConfig`) can only change after:
+1. `init_client` migrated to `&AppConfig` (Step 8j completion)
+2. Client structs migrated from `GlobalConfig`
+3. `eval_tool_calls` migrated to `&AppConfig` + `&mut RequestContext`
+4. `ToolCall::eval` migrated similarly
+5. All MCP tool handlers migrated to use `McpRuntime` instead of `McpRegistry`
+
+This is the "client chain migration" — a cross-cutting change that
+should be a dedicated effort.
+
+## References
+
+- Phase 1 plan: `docs/PHASE-1-IMPLEMENTATION-PLAN.md` — Step 8l
+- Step 8k notes: `docs/implementation/PHASE-1-STEP-8k-NOTES.md`
+- QA checklist: `docs/QA-CHECKLIST.md` — items 11, 12