mirror of
https://github.com/nearai/ironclaw.git
synced 2026-09-03 08:06:01 +08:00
0476a3d8e9
* fix(gateway): label Settings extension button Setup vs Reconfigure by auth state Closes nearai/ironclaw#2235. Extracted from #2375. The Settings → Extensions card fallback branch unconditionally labeled the action button "Reconfigure", so users opening the settings for a chat-installed channel saw "Reconfigure" even though credentials had never been entered — and clicking it opened the credential popup, matching the QA repro on the 2026-04-09 bug bash. Pick the label from `ext.authenticated`: "Setup" when no credentials are on file, "Reconfigure" once they are. `setup_required` / `installed` keep the legacy label because the inline setup form below already provides the same action — preserves the no-duplicate-setup invariant guarded by `test_wasm_channel_setup_states`. Tests: - `test_extensions_list_reports_authenticated_after_setup_submit` drives POST setup-submit → GET list and asserts `authenticated` flips on the wire (the field the JS branch reads). - `test_settings_extensions_labels.py` (Playwright) covers both label states, the no-duplicate-setup invariant, and that clicking Reconfigure on an authenticated channel does not fire /activate. Does not touch `classify_wasm_channel_activation` (keeps the `has_paired` axis the #1921 truth-table tests guard) or introduce an `owner_bound` wire field. Co-Authored-By: Nige <G7CNF@users.noreply.github.com> Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(gateway): use ext.reconfigure i18n key consistently (PR #2709 review) Address gemini-code-assist review on #2709: the `inlineSetupCoversIt` branch was the sole remaining caller of `extensions.reconfigure`. All other Reconfigure buttons in this file already use `ext.reconfigure` (lines 177, 218, 354). Both keys resolve to the same string in en/ko/ zh-CN locales, so this is a no-op for users — it removes the odd key out and aligns with the project's `extensions.*` → `ext.*` migration. Declined the paired suggestion to swap `var` → `const`: the surrounding wasm-channel branch consistently uses `var` (lines 309/311/317/325), and partial modernization inside the same conditional is worse than matching the existing style. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(gateway): drop 'installed' from inlineSetupCoversIt + fix Playwright mock (PR #2709 review) Copilot review on #2709 flagged two real bugs: 1. `inlineSetupCoversIt` treated `fallbackStatus === 'installed'` as if an inline setup form was present, but the inline form only renders when effective status is `setup_required` (see `loadInlineChannelSetup` branch at line 380). A production `installed` wire shape (`activation_status='installed'`, `onboarding_state=null` — `derive_onboarding` only emits non-null for `Pairing`) therefore kept the `Reconfigure` label with no inline form, which is exactly the #2235 QA repro. Drop `installed` from the conditional. 2. `test_reconfigure_click_does_not_send_auth_event` mocked the setup-fetch with empty `secrets`/`fields`, which makes `showConfigureModal` short-circuit with a `noConfigNeeded` toast and never render `.configure-modal`. The wait-for would have timed out on first CI run. Return a non-empty `secrets` array so `renderConfigureModal` actually fires. Also adds `test_fallback_button_says_setup_on_production_installed_wire_shape` — pins the exact #2235 wire shape (activation_status='installed', onboarding_state=null) so this class of bug has a named regression test going forward. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * refactor: reuse `status` and drop redundant presence assert (PR #2709 review) Copilot second-round review on #2709: - extensions.js: `fallbackStatus` recomputed the expression already stored in `status` at line 309. Reuse `status` directly; drop the one-use `inlineSetupCoversIt` alias while we are here — the `status === 'setup_required'` branch is short enough to read inline. - features/extensions/mod.rs: the `telegram.get("authenticated").is_some()` assertion is redundant with the preceding `assert_eq!(..., true)` — a missing field indexes to `Value::Null` and trips the equality check. Folded the "must stay on the wire" rationale into the equality assertion's message so the diagnostic still documents why the field matters. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Nige <G7CNF@users.noreply.github.com> Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>