…e/GooseResponseForm

fix(tools): fix write registry

- Add origin validation to get-mcp-ui-proxy-url IPC handler
- Only allow trusted renderer processes (file:// or dev server) to access proxy URL
- Log and reject requests from untrusted origins
- Addresses security review item #1

feat: add ANTHROPIC_MAX_TOKENS env variable to configure max token limit

This fixes the Fork Session issues where users experienced lag and missing
messages. The problem was that auto-submit fired immediately after the
forked session loaded, before users could see the conversation history.

Root Cause:
When a user clicked "Fork Session", the flow was:
1. Backend creates forked session with conversation history
2. Frontend navigates to new session
3. Session loads with messages
4. Auto-submit IMMEDIATELY fires with edited message
5. User never sees the forked conversation history
6. Creates perception of lag and "messages gone"

The Fix:
- Remove auto-submit behavior for forked sessions
- Allow users to see the full conversation history
- Users can manually review and decide when to submit

Changes:
- Modified useAutoSubmit.ts to detect forked sessions
  (shouldStartAgent + initialMessage + messages.length > 0)
- Mark as handled to prevent fallthrough to resume scenario
- Clear initialMessage to prevent memory leaks

Benefits:
- Users see the forked conversation immediately
- No race conditions or timing issues
- Clear user intent before submission
- Consistent with fork UX expectations

Related: Bug aaif-goose#1 from fork session investigation

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Signed-off-by: Bright Zheng <bright@squareup.com>

This fixes the Fork Session issues where messages appeared to be gone or
the session seemed to update the existing one. The root cause was a race
condition where auto-submit fired before the forked conversation loaded.

Root Causes Fixed:
1. Auto-submit fired immediately, before messages loaded
2. Backend wasn't passed explicit conversation, potentially using stale data
3. User never saw the forked conversation history before it was modified

The Fix (Two Parts):

Part 1: Wait for Messages to Load (useAutoSubmit.ts)
- Check messages.length > 0 before auto-submitting for forked sessions
- This ensures the conversation history is loaded and visible
- If messages haven't loaded, return and wait for next render
- Once loaded, auto-submit fires with the edited message

Part 2: Pass conversation_so_far Explicitly (useChatStream.ts)
- When handleSubmit is called with existing messages, pass conversation_so_far
- This ensures backend uses the correct conversation state
- Prevents backend from loading potentially stale session data
- Fixes both fork and edit-in-place scenarios

Expected Behavior After Fix:
1. User clicks "Fork Session" with edited message
2. Backend creates forked session with conversation history
3. Frontend loads session, displays conversation history
4. Auto-submit waits until messages.length > 0
5. Auto-submit fires with edited message + explicit conversation
6. Backend processes with correct conversation context
7. New response streams back
8. User sees: [history] + [edited message] + [new response]

This maintains the expected automatic behavior while fixing the race
condition and ensuring data consistency.

Fixes both Bug aaif-goose#1 and Bug aaif-goose#2 from fork session investigation

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Signed-off-by: Bright Zheng <bright@squareup.com>

Implement a first-class provider for Tanzu AI Services, enabling
enterprise-managed LLM access through Cloud Foundry service bindings
with an OpenAI-compatible API.

- Add TanzuAIServicesProvider using OpenAiCompatibleProvider
- Support single-model and multi-model credential formats
- Support VCAP_SERVICES auto-detection for Cloud Foundry
- Implement config_url model discovery and capability filtering
- Register as Builtin provider in init.rs
- Add 14 unit tests and 10 integration tests (wiremock)
- Update providers.md documentation

Closes aaif-goose#1, aaif-goose#2, aaif-goose#3, aaif-goose#4, aaif-goose#5, aaif-goose#6, aaif-goose#7, aaif-goose#8, aaif-goose#12, aaif-goose#16

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

…torm-performance

Add feedback data for performance issue insights

…/prototypes/devtools-hub-poc/lodash-4.17.23

Bump lodash from 4.17.21 to 4.17.23 in /research/prototypes/devtools-hub-poc

Dev 2

Problem:
Inline code text rendered as nearly invisible light grey (#cbd1d6) on white
background in the light theme. Contrast ratio was 1.54:1 — far below the
WCAG 2.1 AA minimum of 4.5:1.

Root cause:
1. The base .bg-inline-code class used --color-neutral-200 (#cbd1d6), a color
   designed for dark backgrounds, with no light/dark theme differentiation.
2. The accent color override used parent-specific selectors (p > code, li > code)
   which failed in many common contexts:
   - Inline code inside <strong> (bold text)
   - Inline code inside <em> (italic text)
   - Inline code inside <td>/<th> (table cells)
   - Inline code inside <a> (links)
   - Any other nesting beyond direct child of <p> or <li>

Fix:
- Apply the accessible accent color directly on the base .bg-inline-code class
  so it works in ALL contexts (tables, headings, bold, italic, links, etc.)
- Light theme: #c2410c (4.78:1 contrast ✅ AA) with subtle #f4f6f7 background.
- Dark theme: #ff7235 (4.51:1 contrast ✅ AA) with #32353b background.
- Removed the parent-specific selectors entirely — no longer needed since the
  base class now carries the correct color everywhere.

---
Session Context:
- User noticed the poor contrast from a real session where Goose output included
  inline code inside bold text in numbered lists AND inside table cells.
- Key insight aaif-goose#1: the direct-child selector (>) was the initial trigger — inline
  code nested inside <strong> within list items never matched the orange override.
- Key insight aaif-goose#2: even after fixing the direct-child issue with descendant
  selectors, inline code in table cells (<td>) was still grey because only
  p/li ancestors were in the selector. The correct fix is to put the accessible
  color on the base class itself.
- The user is running Goose installed via Homebrew; there is no user-facing
  config to customize theme colors, so this requires a source code fix or PR.
- User plans to file this as a public issue/discussion on the Goose project.
- We verified contrast ratios programmatically against WCAG 2.1 AA/AAA standards.
- User confirmed the patched version looks correct after testing locally.
- Branch: jramnani-1.33.1 (based on release 1.33.1 patch)
- Next steps: User may submit this as a PR or issue upstream with screenshots.

Problem:
Inline code text rendered as nearly invisible light grey (#cbd1d6) on white
background in the light theme. Contrast ratio was 1.54:1 — far below the
WCAG 2.1 AA minimum of 4.5:1.

Root cause:
1. The base .bg-inline-code class used --color-neutral-200 (#cbd1d6), a color
   designed for dark backgrounds, with no light/dark theme differentiation.
2. The accent color override used parent-specific selectors (p > code, li > code)
   which failed in many common contexts:
   - Inline code inside <strong> (bold text)
   - Inline code inside <em> (italic text)
   - Inline code inside <td>/<th> (table cells)
   - Inline code inside <a> (links)
   - Any other nesting beyond direct child of <p> or <li>

Fix:
- Apply the accessible accent color directly on the base .bg-inline-code class
  so it works in ALL contexts (tables, headings, bold, italic, links, etc.)
- Light theme: #c2410c (4.78:1 contrast ✅ AA) with subtle #f4f6f7 background.
- Dark theme: #ff7235 (4.51:1 contrast ✅ AA) with #32353b background.
- Removed the parent-specific selectors entirely — no longer needed since the
  base class now carries the correct color everywhere.

---
Session Context:
- User noticed the poor contrast from a real session where Goose output included
  inline code inside bold text in numbered lists AND inside table cells.
- Key insight aaif-goose#1: the direct-child selector (>) was the initial trigger — inline
  code nested inside <strong> within list items never matched the orange override.
- Key insight aaif-goose#2: even after fixing the direct-child issue with descendant
  selectors, inline code in table cells (<td>) was still grey because only
  p/li ancestors were in the selector. The correct fix is to put the accessible
  color on the base class itself.
- The user is running Goose installed via Homebrew; there is no user-facing
  config to customize theme colors, so this requires a source code fix or PR.
- User plans to file this as a public issue/discussion on the Goose project.
- We verified contrast ratios programmatically against WCAG 2.1 AA/AAA standards.
- User confirmed the patched version looks correct after testing locally.
- Branch: jramnani-1.33.1 (based on release 1.33.1 patch)
- Next steps: User may submit this as a PR or issue upstream with screenshots.

Problem:
Inline code text rendered as nearly invisible light grey (#cbd1d6) on white
background in the light theme. Contrast ratio was 1.54:1 — far below the
WCAG 2.1 AA minimum of 4.5:1.

Root cause:
1. The base .bg-inline-code class used --color-neutral-200 (#cbd1d6), a color
   designed for dark backgrounds, with no light/dark theme differentiation.
2. The accent color override used parent-specific selectors (p > code, li > code)
   which failed in many common contexts:
   - Inline code inside <strong> (bold text)
   - Inline code inside <em> (italic text)
   - Inline code inside <td>/<th> (table cells)
   - Inline code inside <a> (links)
   - Any other nesting beyond direct child of <p> or <li>

Fix:
- Apply the accessible accent color directly on the base .bg-inline-code class
  so it works in ALL contexts (tables, headings, bold, italic, links, etc.)
- Light theme: #c2410c (4.78:1 contrast ✅ AA) with subtle #f4f6f7 background.
- Dark theme: #ff7235 (4.51:1 contrast ✅ AA) with #32353b background.
- Removed the parent-specific selectors entirely — no longer needed since the
  base class now carries the correct color everywhere.

---
Session Context:
- User noticed the poor contrast from a real session where Goose output included
  inline code inside bold text in numbered lists AND inside table cells.
- Key insight aaif-goose#1: the direct-child selector (>) was the initial trigger — inline
  code nested inside <strong> within list items never matched the orange override.
- Key insight aaif-goose#2: even after fixing the direct-child issue with descendant
  selectors, inline code in table cells (<td>) was still grey because only
  p/li ancestors were in the selector. The correct fix is to put the accessible
  color on the base class itself.
- The user is running Goose installed via Homebrew; there is no user-facing
  config to customize theme colors, so this requires a source code fix or PR.
- User plans to file this as a public issue/discussion on the Goose project.
- We verified contrast ratios programmatically against WCAG 2.1 AA/AAA standards.
- User confirmed the patched version looks correct after testing locally.
- Branch: jramnani-1.33.1 (based on release 1.33.1 patch)
- Next steps: User may submit this as a PR or issue upstream with screenshots.