feat: "Agent configs" view, local Config folder only (studio#128) - #134
Merged
Conversation
…ly (studio#128) Last item on #128's runbook. New Debug drawer tab, next to the existing Activity/MCP/Config ones — lists agent names under the local "Config folder" (#130) that have a config.toml, and shows the selected one's content read-only. Deliberately local-filesystem-only, no S3 (Brett: "forget about s3 now"): list_local_agent_configs/read_local_agent_config are plain std::fs calls in src-tauri, no sidecar/MCP tool involved at all, unlike everything else added this batch — the local folder is Studio's own mirror the New Fleet wizard writes alongside its S3 upload (still to be wired — the wizard itself doesn't write here yet, this PR is just the read side), not a read-through to the S3 source of truth. Whatever an admin agent (or the wizard, once wired) writes into the same folder shows up on the next Refresh / tab switch — reading a directory needs no separate sync mechanism. Agent names render via DOM construction (createElement + textContent), not innerHTML string concatenation — they come from local directory listings, not worth trusting as HTML even though the risk is low (Studio itself controls what gets written there today). Verification: npm run typecheck clean, npm test 100/100 passing, npm run build succeeds. Rust side not locally compiled — same pre-existing limitation as every other Rust change this week, though this one is lower risk than most (plain std::fs, no new dependency, no capability grant needed — custom commands aren't plugin-gated the way tauri-plugin-dialog was in #130). Ref #128 — this closes out the runbook's item list (the wizard→folder write side is a natural follow-up once someone needs it, not blocking).
brettchien
added a commit
that referenced
this pull request
Aug 29, 2026
…35) (#136) Closes the gap #134 flagged: the wizard generated config.toml server-side but never wrote it into the operator's local Config folder (#130), so the "Agent configs" view (#134) had nothing to show until something else populated the folder by hand. Brett's explicit ordering: "Wizard should write to local first, write to s3 if needed." That ordering can only actually be guaranteed inside the sidecar (oab-mcp) — provision_agent/provision_agent_k8s are what do the S3 upload, so writing the local copy there, before the upload, is a real sequencing guarantee. Having the console write a local copy *after* receiving the tool's response back would mean S3 had already happened first no matter what, the opposite of what was asked — and was the implementation this session's own earlier #135 write-up had assumed by default, corrected here after asking Brett directly rather than guessing. - studio-cp: new write_local_agent_config() — <folder>/<name>/config.toml, written from generate_agent_config()'s raw output *before* inject_pre_seed_hook mutates a copy for the S3/bundle path (the S3 zip URI hook injects is meaningless for a local reference copy). Both provision_agent and provision_agent_k8s gained a local_config_folder: Option<&str> parameter; write happens unconditionally whenever the caller passes one, hard-fails the whole deploy on a write error (folder set = a real requirement, not best-effort) rather than silently proceeding without the copy it promised. - oab-mcp: deploy_provision_agent's schema gained local_config_folder (optional). - src-tauri: bridge command threads the new param through. - console: deploy.ts reads the same oab-studio.configFolder localStorage key the Config-folder setting (#130) already uses and sends it along. This also resolves the mechanism question #135's own write-up had left open (send config_toml back to console vs. have the sidecar write directly) — the ordering requirement settles it: only the sidecar-writes approach can guarantee local-before-S3, so no config.toml text (which could contain secret *references*, if not raw values) needs to cross the Tauri IPC bridge back to the console at all. Ref #135.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Last item on #128's runbook. New Debug drawer tab ("Agent configs"), next to Activity/MCP/Config — lists agent names under the local "Config folder" (#130) that have a
config.toml, and shows the selected one's content read-only.The Config folder setting's own copy (#130) says the New Fleet wizard "mirrors each agent's generated config.toml into" this folder — but #132 (the wizard rewrite) only wired the S3 upload path via
deploy_provision_agent, which returns{ok, cluster, namespace, name, image, digest, objects, action, services_applied}— noconfig_tomltext, since generation happens server-side in the sidecar and the console never sees the rendered text. This PR is the read side only. The folder starts empty until something (a future wizard update returning the text, or the backend writing it directly since oab-mcp already runs locally, or an admin agent) actually populates it. Flagging this explicitly rather than implying the loop is closed — didn't want to further balloon this batch by redesigning the provisioning response shape too, that's a real but separate follow-up.Change
list_local_agent_configs/read_local_agent_config— plainstd::fscalls, no sidecar/MCP tool involved at all (unlike everything else in this batch). No new capability grant needed either — custom commands aren't plugin-gated the waytauri-plugin-dialogwas in feat(console,src-tauri): local "Config folder" setting (studio#128) #130.createElement/textContent, notinnerHTML— they come from local directory listings, not worth trusting as HTML even though Studio itself controls what's written there today (once something writes there).Verification
npm run typecheckclean,npm test100/100 passing,npm run buildsucceeds.std::fs, no new dependency, no capability grant).<folder>/<test-agent>/config.tomlby hand once merged, just to confirm the read/list/display path itself works.Ref #128 — closes out the runbook's item list (the wizard-write gap above is flagged as a real, separate follow-up, not silently left implied-done).
🤖 Generated with Claude Code