Context
Follow-up gap found while shipping #128 (closed). The "Config folder" setting (#130) and "Agent configs" view (#134) are both built and merged, but the New Fleet wizard (#132) never actually writes into that folder — only the S3 upload path is wired.
Why
deploy_provision_agent's response is {ok, cluster/context, namespace, name, image, digest, objects, action, services_applied} — no config_toml text. Generation happens server-side in studio-cp::generate_agent_config, inside the oab-mcp sidecar, and the rendered text is never sent back to the console. The console has nothing to write locally even if it wanted to.
Options (not decided — needs scoping)
- Add
config_toml to deploy_provision_agent's response, have the console write it locally itself (mirrors the pattern console already uses for other local file writes, e.g. the compose-library editor's old std::fs::write in src-tauri/src/compose.rs).
- Have the sidecar write the local file directly instead —
oab-mcp already runs as a local process on the same machine (spawned by Tauri), so it has filesystem access; would need the local Config folder path passed into the tool call (currently only known client-side, in localStorage).
Option 1 is probably simpler (no new "how does the sidecar learn the folder path" plumbing) but exposes secrets-bearing config.toml text over the Tauri IPC bridge to the console, which currently never sees raw secret values — worth Brett's input before picking.
🤖 Filed by Orca while closing out #128.
Context
Follow-up gap found while shipping #128 (closed). The "Config folder" setting (#130) and "Agent configs" view (#134) are both built and merged, but the New Fleet wizard (#132) never actually writes into that folder — only the S3 upload path is wired.
Why
deploy_provision_agent's response is{ok, cluster/context, namespace, name, image, digest, objects, action, services_applied}— noconfig_tomltext. Generation happens server-side instudio-cp::generate_agent_config, inside the oab-mcp sidecar, and the rendered text is never sent back to the console. The console has nothing to write locally even if it wanted to.Options (not decided — needs scoping)
config_tomltodeploy_provision_agent's response, have the console write it locally itself (mirrors the pattern console already uses for other local file writes, e.g. the compose-library editor's oldstd::fs::writeinsrc-tauri/src/compose.rs).oab-mcpalready runs as a local process on the same machine (spawned by Tauri), so it has filesystem access; would need the local Config folder path passed into the tool call (currently only known client-side, inlocalStorage).Option 1 is probably simpler (no new "how does the sidecar learn the folder path" plumbing) but exposes secrets-bearing config.toml text over the Tauri IPC bridge to the console, which currently never sees raw secret values — worth Brett's input before picking.
🤖 Filed by Orca while closing out #128.