fix(web-react): keep router chat sandbox-free

[drewstone]

Summary

• keep @tangle-network/agent-app/web-react safe for Router-backed chat by restoring a dependency-light ChatComposer
• move WorkspaceTerminalPanel behind explicit @tangle-network/agent-app/web-react/terminal export
• document the Router chat, sandbox composer, and sandbox terminal split
• add a regression test that blocks sandbox-only UI from the default web-react entrypoint

Verification

• NODE_OPTIONS=--max-old-space-size=8192 pnpm run typecheck
• pnpm run test
• NODE_OPTIONS=--max-old-space-size=8192 pnpm run build
• node bundle check: dist/web-react/index.js has sandbox-ui=false, xterm=false, workspace-terminal=false

[tangletools]

✅ Auto-approved drewstone PR — 5f08fb20

This PR was opened by the trusted drewstone account.
The full PR reviewer audit still runs separately and will publish findings if it detects issues.

_{tangletools · auto-approval · reason: drewstone_author · 2026-07-01T01:12:45Z}

[tangletools]

🟡 Value Audit — sound-with-nits

Verdict	sound-with-nits
Concerns	2 (2 weak-concern)
Heuristic	0.0s
Duplication	0.0s
Interrogation	156.3s (2 bridge agents)
Total	156.3s

💰 Value — sound-with-nits

Restores a lightweight, sandbox-ui-free ChatComposer to @tangle-network/agent-app/web-react and moves sandbox terminal UI behind a new /web-react/terminal subpath, fixing the previous breaking change that forced sandbox-ui on every web-react consumer; coherent with the repo's engine/shell separation

• What it does: Replaces the AgentComposer wrapper in src/web-react/chat-composer.tsx with the original self-contained ChatComposer implementation (auto-resizing textarea, drag-and-drop attachments, Stop/Send toggle, Cmd/Ctrl+L focus, inline controls slot). Removes the WorkspaceTerminalPanel export from src/web-react/index.tsx and creates a new package.json + tsup entry for @tangle-network/agent-app/web-react/ter
• Goals it achieves: Keeps the default @tangle-network/agent-app/web-react surface dependency-light and safe for Router-backed chat/copilot apps that do not use the sandbox, so they do not pay the optional @tangle-network/sandbox-ui peer cost or break when it is absent. Preserves the sandbox-backed terminal and full AgentComposer behind explicit opt-in subpaths, matching the codebase's engine/shell separation and addi
• Assessment: Good on its merits. The previous commit (15da1cf) over-consolidated by making every web-react consumer depend on sandbox-ui just to get a chat input box; this change restores the correct split. The restored implementation is idiomatic for the package (Tailwind over shared tokens, inline SVG glyphs, no icon library) and the terminal subpath is the right seam for sandbox-only UI.
• Better / existing approach: none — this is the right approach. I checked the git history (src/web-react/chat-composer.tsx, src/web-react/index.tsx) and the prior standalone ChatComposer existed at 55e5ca7 before being replaced by the AgentComposer wrapper at 15da1cf. The alternative options are worse: keeping AgentComposer in /web-react forces sandbox-ui on router apps; dynamic-importing it would complicate SSR and still req
• Model: opencode/kimi-for-coding/k2p7
• Bridge attempts: 1

🎯 Usefulness — sound

Reverts a regression (#157) that made the router-safe web-react barrel transitively require sandbox-ui, and structurally isolates the xterm-backed terminal panel behind an explicit subpath — restoring a documented invariant.

• Integration: The restored ChatComposer has two live in-repo callers: src/assistant/AssistantPanel.tsx:16,499 (imports from ../web-react, renders it in the dock panel) and playground/src/routes/ComposerRoute.tsx (imports from @tangle-network/agent-app/web-react). The new ./web-react/terminal subpath has no in-repo caller beyond its own test, but agent-app is a framework consumed externally by creative-agent/gtm
• Fit with existing patterns: Fits the codebase grain precisely. AGENTS.md invariant #4 marks web-react as substrate-free (react peer only) and the module map defines it as 'shared chat-shell + observability components' with no sandbox-ui hard dep; #157 broke that by making ChatComposer delegate to sandbox-ui's AgentComposer (commit 15da1cf, BREAKING CHANGE pulling @xyflow/react, @tangle-network/brand, sandbox-ui peers). This
• Real-world viability: Holds up. The restored ChatComposer is the ~400-line implementation that shipped before #157, already proven with its own suite (chat-composer.test.tsx, 8 cases covering controlled/uncontrolled, streaming Stop, attach surface, IME composition, drag-depth tracking, auto-resize). Verified the barrel is genuinely sandbox-free post-change: src/web-react/index.tsx re-exports sandbox-terminal (pure Reac
• Model: opencode/zai-coding-plan/glm-5.2
• Bridge attempts: 1

💰 Value Audit

🟡 The default /web-react surface loses WorkspaceTerminalPanel, a breaking export move [proportion] ``

src/web-react/index.tsx no longer exports './workspace-terminal-panel' (it was exported there before this PR at line 29-30). Existing consumers importing it from @tangle-network/agent-app/web-react will break and must migrate to @tangle-network/agent-app/web-react/terminal. The move is architecturally justified (sandbox-only UI must not live on the default surface), but the commit could flag the break with a ! or note in the body since package.json exports are public API.

🟡 Regression test guards source imports but not the built bundle [maintenance] ``

tests/web-react/router-safe-entrypoint.test.ts only string-checks src/web-react/index.tsx and src/web-react/chat-composer.tsx. It is useful for catching accidental re-imports during development, but it does not prove the built dist/web-react/index.js is sandbox-free. The PR body documents a manual bundle check; consider adding a build-time test later if the manual check keeps recurring.

---

What this audit checks

It judges the change on its merits — not whether it was tasked out in an issue. Unticketed, fast-moving work is fine; the question is whether the change is good and whether a better or existing approach should be used instead.

Pass	What it asks
Heuristic	Vague title? Whitespace-only or cruft-bearing diff? (content signals only)
Duplication	Do added function/class names already exist elsewhere in the repo?
Value Audit	What does it do? What goal does it achieve? Is it good? Better architecture or already-exists?
Usefulness Audit	Does it integrate and fit? Will it hold up in real use and actually get used?

Findings are concerns, not blocks — the human reviewer decides what to do with them.

_{value-audit · 20260701T011710Z}