Skip to content

fix: chat token/secret visibility bug + ACP token field (studio#132/#136) - #137

Merged
brettchien merged 2 commits into
mainfrom
fix/chat-field-visibility-and-acp-token-136
Aug 29, 2026
Merged

fix: chat token/secret visibility bug + ACP token field (studio#132/#136)#137
brettchien merged 2 commits into
mainfrom
fix/chat-field-visibility-and-acp-token-136

Conversation

@brettchien

Copy link
Copy Markdown
Contributor

Summary

Two things Brett caught live-testing the wizard (screenshot: "Bot token" + "Channel secret" both showing with Chat platform set to "— none —").

Bug: hidden chat token/secret fields stayed visible

.compose-form label { display: flex; ... } has higher specificity ((0,1,1)) than the UA stylesheet's [hidden] { display: none } ((0,1,0)), so toggling .hidden on #deploy-chat-token-wrap/#deploy-chat-secret-wrap (both <label> elements inside .compose-form) did nothing. Same CSS gotcha already hit once in studio#83's implementation — missed again here since this environment can't render the app to catch it (only live testing does). Added .compose-form label[hidden] { display: none } to force the override, plus the identical fix for .deploy-identity label[hidden] (the k8s "new namespace" field has the same latent bug — not confirmed live, but same root cause, fixed proactively rather than waiting to get caught separately).

Feature: ACP token field + Generate button

Brett: "when ACP is enabled, need a field for acp token, and we should provide a token generator button." Previously the ACP auth key was always silently auto-generated server-side (uuid v4) with no way for the operator to see or choose it ahead of deploy.

  • console: new "ACP token" field + Generate button (client-side crypto.randomUUID(), same shape the server generates), visible only while Enable ACP is checked+enabled — reuses the same show/hide-on-toggle pattern the chat platform fields already use, via a new applyAcpMode() helper.
  • studio-cp: AgentWizardInput gained acp_token: Option<String>. provision_acp_auth_secret/provision_acp_auth_k8s_secret now take a token: Option<&str> — use it if the caller supplied one, else generate as before (backward compatible: the compose-library path still always passes None). build_default_manifest/build_default_k8s_manifest thread it through; all 4 call sites updated.
  • oab-mcp: deploy_provision_agent's schema gained acp_token (optional).
  • src-tauri: bridge command threads the new param through.

Verification

  • npm run typecheck clean, npm test 100/100 passing, npm run build succeeds.
  • Rust side not locally compiled — same pre-existing aws-sdk-ec2 OOM limitation as every other Rust change this week.
  • Worth Brett re-testing the exact scenario from the screenshot (Chat platform = none) plus the new ACP token field/Generate button once merged.

Note: independent of #136 (local-config-folder-write PR, still open) — touches the same invoke(...) args block in deploy.ts, so whichever merges second may need a quick rebase.

🤖 Generated with Claude Code

…(studio#132/#136)

Two things Brett caught live-testing the wizard (screenshot: Bot token +
Channel secret both showing with Chat platform = "— none —").

## Bug: hidden chat token/secret fields stayed visible

`.compose-form label { display: flex; ... }` has higher specificity
((0,1,1)) than the UA stylesheet's `[hidden] { display: none }` ((0,1,0)),
so toggling `.hidden` on `#deploy-chat-token-wrap`/`#deploy-chat-secret-wrap`
(both <label> elements inside .compose-form) did nothing — same CSS
gotcha already hit once in studio#83's implementation (see that memory),
missed again here since this sandbox can't render the app to catch it.
Added `.compose-form label[hidden] { display: none }` to force the
override, plus the same fix for `.deploy-identity label[hidden]` (the k8s
"new namespace" field has the identical latent bug, unconfirmed live but
same root cause — fixed proactively).

## Feature: ACP token field + Generate button

Brett: "when ACP is enabled, need a field for acp token, and we should
provide a token generator button." Previously the ACP auth key was always
silently auto-generated server-side (uuid v4) with no way for the operator
to see or choose it ahead of deploy.

- console: new "ACP token" field + Generate button (client-side
  crypto.randomUUID(), same shape the server generates), visible only
  while Enable ACP is checked+enabled (reuses the same show/hide-on-toggle
  pattern as the chat platform fields, via a new applyAcpMode() helper).
- studio-cp: AgentWizardInput gained acp_token: Option<String>.
  provision_acp_auth_secret/provision_acp_auth_k8s_secret now take a
  token: Option<&str> — use it if the caller supplied one, else generate
  as before (backward compatible: the compose-library path still always
  passes None). build_default_manifest/build_default_k8s_manifest thread
  it through; all 4 call sites updated.
- oab-mcp: deploy_provision_agent's schema gained acp_token (optional).
- src-tauri: bridge command threads the new param through.

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.
…lity-and-acp-token-136

# Conflicts:
#	console/src/deploy.ts
#	crates/oab-mcp/src/lib.rs
#	src-tauri/src/lib.rs
@brettchien
brettchien merged commit f8fb7bf into main Aug 29, 2026
2 checks passed
@brettchien
brettchien deleted the fix/chat-field-visibility-and-acp-token-136 branch August 29, 2026 14:08
brettchien added a commit that referenced this pull request Aug 29, 2026
…tudio#128) (#138)

Brett's live-testing report: switching vendor didn't visibly update the
Image tag field, and there was no way to enter a full custom image URL.

The old implementation silently mutated one text input's `.value` on
vendor change — easy to miss, and offered no structured way to pick
"give me a full custom URL" vs. "use what GHCR resolved".

Replaces the free-text `<input id="deploy-image">` with:
- `<select id="deploy-image-select">`, rebuilt from scratch on every
  vendor change from `resolve_vendor_image_tags`'s Stable/Beta results
  (option value = the real resolved tag, label shows which is which).
  Rebuilding the whole list (not mutating one value) makes the change
  visually obvious.
- A trailing "Custom…" option that reveals a `deploy-image-custom-wrap`
  text field (same `[hidden]` CSS-specificity fix pattern as #137) for
  pasting a full image URL.

`currentImage()` resolves whichever is actually selected; the deploy
submit handler now calls it instead of reading the old input directly.

Verification: npm run typecheck / test (100/100) / build all clean.
Rust/Tauri/MCP untouched — this is a pure console-side change.

Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant