Suggestion: Make the permission mode more visible in the input area

[CAMB-dev]

I'd like to suggest a small UI improvement for the permission selector in the input area.

Currently, the two permission modes are mainly represented by shield-style icons. Since the icons look quite similar, I think it could be easy to misread which permission mode is currently active at a glance.

I think it could be more intuitive if the current mode were shown more explicitly, for example with an icon + text label:

🛡️ Full access

[Astro-Han]

I think this identifies a real issue, and the code suggests it's slightly sharper than described: the composer footer renders the mode as an icon-only button (permission-mode-menu.tsx), and the two glyphs that are easiest to confuse — ShieldCheck and ShieldAlert — sit at opposite ends of the risk spectrum (ask/自动 vs bypass/完全权限). The mode name currently only appears in the tooltip, the aria-label, and the dropdown items, so accessibility is covered, but at-a-glance readability for sighted users isn't.

On the fix, I'd lean toward something smaller than an always-on icon + label for every mode, since composer footer space is tight and the mode is usually a safe default that doesn't need to shout. One concrete option: keep the icon-only button, but paint bypass in the danger color. The design tokens already support this — --destructive (red, documented for "errors, denied") or --warning (orange, documented for actions the user cannot undo, which matches 完全权限's "trusted tasks only" semantics), plus contrast-checked text variants. No new tokens, no layout change, no i18n width problem. And because ShieldAlert and ShieldCheck already differ in shape, color would be a second channel rather than the only signal — so this doesn't create a color-only accessibility concern.

The general principle: quiet when safe, unmistakable when dangerous. ask/explore stay on the standard color; only the state where a misread has consequences gets the loud treatment.

(Drafted with AI assistance; component and design-token claims verified against packages/ui and maka-tokens.css.)

中文版本

我觉得这指出了一个真问题，而且代码显示它比描述的还要更尖锐一点：composer 底栏把模式渲染成了纯图标按钮（permission-mode-menu.tsx），而最容易混淆的两个图标——ShieldCheck 和 ShieldAlert——恰好守在风险谱系的两端（ask/自动 vs bypass/完全权限）。模式名目前只出现在 tooltip、aria-label 和下拉菜单项里，所以无障碍覆盖到了，但明眼用户的一眼可读性没有。

关于修法，我倾向比"所有模式常驻图标+文字"更小的方案——composer 底栏空间有限，而且大多数时候模式处于安全默认值，不需要大声宣告。一个具体的选项：保留纯图标按钮，但给 bypass 上危险色。 设计 token 已经支持——--destructive（红色，文档注明用于"errors, denied"）或 --warning（橙色，语义是"用户无法撤销的操作"，和完全权限的"仅限可信任务"吻合），还有测过对比度的文字变体。零新 token、零布局变化、没有 i18n 宽度问题。而且因为 ShieldAlert 和 ShieldCheck 的字形本来就不同，颜色是第二信道而不是唯一信号——所以不会引入"仅靠颜色区分"的无障碍问题。

背后的原则：安全时安静，危险时醒目。ask/explore 保持标准色；只有误读会有后果的那个状态才用醒目处理。

（本评论由 AI 辅助起草；组件与设计 token 的论断均已对照 packages/ui 和 maka-tokens.css 核实。）