references/openspec这个项目是我常用的openspec工具，我现在要构建一个openspecui的项目，目的是通过webui来提供更好的视觉展示。
- 请你阅读openspec的源代码，分析其工作原理，分析其cli的功能.
- 构建出openspecui这个cli工具，默认行为是启动一个http服务，作用将openspec可视化，参考
openspec view+show的效果- 使用shadcnui
- 内置AI-Provider，来使用AI进行协作，AI-Provider有两种：
- ACP-Provider，使用ACP协议来连接Gemini、Codex、Claude、iFLow这些CoderCliAgent工具。默认使用iFlow
- API-Provider，使用OpenAI的ChatCompactionAPI协议来进行连接。默认使用provider.json中的openaiv1的配置来进行连接
- 如果可以，把API-Provider也封装成ACP-Provider，这样我们统一面向ACP来进行开发后续的AI功能
- 可视化的
openspec init功能 - 可视化的
openspec archive/validate/spec等等功能，可以完全等同于openspec的功能 - AI-Provider 可以用来满足各种互动需求：
- 比如修改openspec的文件
- 提供review模式，可以通过评论来快速修改spec
- 这里可以滑动选择一段文本进行评论，或者可以评论某一行
- 可以评论一整份spec
- 每一个评论都有一个NoId，可以通过
#{NoId}来互相关联 - 完成评论后，进行提交，会生成一份新的spec文件，用户可以接受也可以拒绝也可以重新生成
- 接受后可以继续迭代
- 迭代更新spec的过程中，这些文件不会立刻被清除，而是会被放到一个临时文件夹，作为“历史记录”，在界面上可以查看这份文件的历史，可以被AI追溯。
- 一切都是“文件”，所有程序的状态都和“本地文件”进行强关联
- AI-Provider可以通过了解文件来了解整个openspecui的程序状态，可以通过修改文件来改变webui的界面内容。这些规则都在内置的提示词中
- 比如进行界面上的中英文翻译（openspec的文件默认是英文，可以翻译来显示中英双语）
- 比如修改openspec的文件
请充分利用monorepo的规范，梳理我们的仓库。 特别是一些关键的功能，作为一个子仓库，进行独立的单元测试。 逐步验证通过后，再最终搭建出我们的webui。 最后再将webui打包到我们的cli中。
我提醒你一下，iflow和gemini都原生支持ACP：--experimental-acp
Claude Code则是有Zed团队提供的ACP适配：https://github.com/zed-industries/claude-code-acp
OpenAI Codex也是有对应的ACP适配：https://github.com/zed-industries/codex-acp
proxy后端的端口是findPort得来的，前端就不能绑定死端口。甚至应该足够灵活，可以自适应。 可以这样考虑，一方面是vite.config中配置proxy，使得能直接访问api接口。（当然这是我自以为是前后端的端口是同时用一个的情况下） 同时还接收通过urlSearchParams来修改源头。
另外，因为我们用了websocket，以及我们的这个服务是绑定某个dir的。 所以我们应该在界面上展示当前的live状态，以及显示目前的dirPath。 在title部分，也应该显示dirName，这样同时开多个实例的时候，好辨别
Dashboard 的 Recent Specs / Active Changes, 或者 Specifications 的列表, 我觉得都应该和 Active Changes 显示 Title(spec-title) + SubTitle(spec-id)
已经很不错了，但是这个 typography 的样式有点颜色上的问题： 首先是Project的两个md渲染好像和其它spec的渲染不是很一致，你是不是用了两套方案？
比如Project中的pre-code在亮色模式下，颜色居然接近白色，不是黑色，所以看不清楚字。 还有Project的渲染没有适配暗色模式。
Spec中的渲染，只要className有prose，在暗色模式下就是字体发黑，感觉没有适配暗色模式。
另外，我们是不是应该顺便引入代码高亮库，我建议使用shiki
内容加入目录导航功能：
- Project页面的加入导航功能，悬浮在滚动视图内，要考虑导航条目过多可能也存在滚动。
- 目录要跟随页面一起高亮滚动（实现方案后续我会仔细给你提示词）。
- 目录导航可以展开收起，在移动端，这条目默认可以收起来
- 注意 spec 页面的 Requirements ，每一个 Requirement 都是一个卡片，这里目录如何做，你得思考一下。
- Change 页面的 Tasks，现在是全部挤在一起的，只是在右边显示了主题。我们现在有了目录，它们应该根据主题进行拆分。这更我们的目录设计也更加搭配。所以这里可能界面和交互上都需要做一定的重新设计与改进。
# Task
我需要为一个 Markdown 文章渲染页面实现“目录跟随内容滚动高亮”的功能。
请使用纯 CSS 方案（无需 JS IntersectionObserver），基于 `view-timeline` 和 `timeline-scope` 实现。
# Requirements
1. **HTML 结构要求**：
- 在 `<body>` (或共同父级) 上声明 `timeline-scope`，包含所有章节的变量名（如 `--s1, --s2...`）。
- 在 Markdown 内容的 `h2` 或 `section` 标签上，通过内联样式注入 `view-timeline-name: --sX`。
- 在目录 `<a>` 标签上，通过内联样式注入 CSS 变量 `--target: --sX`。
2. **CSS 核心逻辑（关键）**：
- 必须解决“长内容阅读时高亮消失”的问题。
- **Animation Range**：请使用 `animation-range: cover 0% cover 100%`。这表示只要章节在视口中（哪怕只有一部分），动画就处于播放状态。
- **Keyframes 设置**：请使用“平顶梯形”曲线，而不是钟形曲线。
- 0% (不可见): 默认样式
- 1% (刚进入): 高亮样式 (active)
- 99% (快离开): 高亮样式 (active)
- 100% (完全离开): 默认样式
- 这样设置是为了确保章节在视口中间阅读时，目录链接始终保持高亮，不会因为滚动进度变化而褪色。
# DEMO
```html
<!DOCTYPE html>
<html lang="zh-CN">
<head>
<meta charset="UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<title>Markdown ToC Highlight (Fixed)</title>
<style>
:root {
--w-sidebar: 240px;
--c-active: #2563eb; /* 高亮色：蓝色 */
--c-text: #64748b; /* 默认色：灰色 */
--c-bg-active: #eff6ff; /* 高亮背景 */
}
body {
margin: 0;
display: grid;
grid-template-columns: var(--w-sidebar) 1fr;
height: 100vh;
font-family:
system-ui,
-apple-system,
sans-serif;
overflow: hidden; /* 锁定 body，让 main 滚动 */
}
/* =========================================
1. 侧边栏 (目录)
========================================= */
aside {
border-right: 1px solid #e2e8f0;
padding: 20px;
overflow-y: auto;
background: #f8fafc;
}
.toc-link {
display: block;
padding: 8px 12px;
margin-bottom: 4px;
text-decoration: none;
color: var(--c-text);
border-radius: 6px;
font-size: 0.95rem;
border-left: 3px solid transparent;
transition: all 0.2s; /* 仅用于 hover 效果，不要干扰 animation */
}
/*
★ 核心动画逻辑 ★
*/
@keyframes activate-link {
/* 0% - 刚进入视口前：默认状态 */
0% {
color: var(--c-text);
background-color: transparent;
border-left-color: transparent;
font-weight: 400;
}
/* 1% - 只要有一点点进入视口：立即高亮 */
/* 保持高亮状态一直到 99% */
1%,
99% {
color: var(--c-active);
background-color: var(--c-bg-active);
border-left-color: var(--c-active);
font-weight: 600;
}
/* 100% - 完全离开视口：回到默认 */
100% {
color: var(--c-text);
background-color: transparent;
border-left-color: transparent;
font-weight: 400;
}
}
.toc-link {
/* 绑定时间轴：使用 HTML 中定义的变量 */
animation-timeline: var(--target);
/* 引用上面的动画 */
animation-name: activate-link;
/* 关键配置 1：both 确保动画状态跟随滚动位置 */
animation-fill-mode: both;
/* 关键配置 2：cover 范围
cover 0% = 元素头部刚进入视口底部
cover 100% = 元素尾部刚离开视口顶部
配合 1%-99% 的关键帧，实现“只要在屏即高亮” */
animation-range: cover 0% cover 100%;
}
/* =========================================
2. 主内容区域 (Markdown)
========================================= */
main {
padding: 40px 60px;
overflow-y: auto;
scroll-behavior: smooth;
}
/* 模拟 Markdown 生成的 Section 容器 */
section {
margin-bottom: 100px;
padding-top: 20px;
}
h2 {
border-bottom: 1px solid #eee;
padding-bottom: 10px;
}
p {
line-height: 1.8;
color: #334155;
margin-bottom: 20px;
}
/* 占位符，模拟长文 */
.spacer {
height: 80vh;
background: repeating-linear-gradient(45deg, #f1f5f9, #f1f5f9 10px, #fff 10px, #fff 20px);
border-radius: 8px;
}
</style>
</head>
<!--
★ STEP 1: 在共同父级声明 timeline-scope
渲染器需要收集所有 ID 并填在这里
-->
<body style="timeline-scope: --s-intro, --s-install, --s-usage, --s-api;">
<aside>
<h3>Project Docs</h3>
<nav>
<!--
★ STEP 2: 目录链接绑定目标
style="--target: --[ID]"
-->
<a href="#intro" class="toc-link" style="--target: --s-intro">1. Introduction</a>
<a href="#install" class="toc-link" style="--target: --s-install">2. Installation</a>
<a href="#usage" class="toc-link" style="--target: --s-usage">3. Basic Usage</a>
<a href="#api" class="toc-link" style="--target: --s-api">4. API Reference</a>
</nav>
</aside>
<main>
<h1>Documentation</h1>
<p>Scroll down to see the magic.</p>
<!--
★ STEP 3: 内容章节声明时间轴名字
style="view-timeline-name: --[ID]"
注意：建议把 ID 加在 section 容器上，而不是 h2 上，这样高亮范围更准确（包含正文）。
-->
<section id="intro" style="view-timeline-name: --s-intro">
<h2>1. Introduction</h2>
<p>Start reading this section. Watch the sidebar.</p>
<div class="spacer">Markdown Content Area...</div>
</section>
<section id="install" style="view-timeline-name: --s-install">
<h2>2. Installation</h2>
<p>As you scroll past the previous section, the highlight switches instantly.</p>
<div class="spacer">npm install ...</div>
</section>
<section id="usage" style="view-timeline-name: --s-usage">
<h2>3. Basic Usage</h2>
<p>Even if you stay in the middle of this huge section, the link remains active.</p>
<div class="spacer">import { ... } from ...</div>
</section>
<section id="api" style="view-timeline-name: --s-api">
<h2>4. API Reference</h2>
<p>Final section.</p>
<div class="spacer">API details...</div>
<div style="height: 200px;">End of page</div>
</section>
</main>
</body>
</html>
```- 我们必须和官方的cli保持一致
- 现在的界面上的“Archive按钮”，底层是调用
openspec archive吗？ - 界面上的“Initialize OpenSpec按钮”，底层是调用
openspec init吗？
- 现在的界面上的“Archive按钮”，底层是调用
- 我们所有的接口都用上订阅模式了吗？这点很重要，我们整个应用都应该是实时更新的。
不能简单的流式，但确实需要存在交互，或者说，archive和init这两个命令可能没必要流式，这里的关键在于:
我们要参考 openspec init --help 和 openspec archive --help 的打印结果，来在界面上呈现一些内容。
这里有两种方案，一种是直接拦截openspec init的命令，呈现出一个终端界面到前端，在前端使用键盘来完成工作。
一种是直接参考openspec init做一套存前端的交互，组合成最终openspec init --tools=A,B,C这样无交互式命令来执行。
我个人的建议是直接做一套前端，跟最新版的openspec的具体实现进行强关联。我们把自己假设成官方团队来维护这个ui工具。
关于配置文件，有两种方案，一种是存储在前端，一种是文件化，存储在磁盘。我建议后者，因为我们底层使用了file watch来实现了整个系统的响应式更新。 所以我觉得可以复用这个底层，让配置文件也能实时更新。 也就是说，我们整个系统的订阅模式，完全基于文件/文件夹的订阅来做到自动推送更新，这应该是非常优雅的架构。我不知道你是不是按我想的这样做，还是僵硬地去一个个接口去实现订阅更新？ 我的意思是说，比如我们实现一个普通的函数并在普通的trpc中使用：
async function getConfig() {
return (await fs.readFileOrNull(configPath)) ?? defaultConfig
}
getConfig: tProcedure.query(() => getConfig())现在要做成响应式，只需要这样做：
async function getConfig() {
// fsProvider 是 watcher-fs/fs/pool-fs 等等都统一抽象，取决于用户是否开启监听模式，或者是否轮询模式等
return (await fsProvider.readFileOrNull(configPath)) ?? defaultConfig
}
getConfig: tProcedure.subscription(async function* () {
const effect = fsEffect(() => getConfig())
try {
yield* effect.stream()
} finally {
effect.stop()
}
/// 这里理论上代码还能再简化
})这里的思路，其实就是signal/effect的思路，在单次调用中，我们将过程路径说依赖到的文件/文件夹全部收集起来，然后进行监听。 只要有变动，那么就进行推送。 如果WebSocket断开，那么就释放这些监听：这里同一个文件夹/文件的监听可以共享，一个监听的引用为0的时候，就释放。
还有，要实现这些功能，最关键的技术是AsyncContext这个技术，它可以实现一个异步上下文隐形传递上下文对象。从而实现文件监听的依赖收集，这点非常重要！ 是我们响应式监听能否成功的关键。我以前做过简单的技术实现，你可以参考 /Users/kzf/Dev/GitHub/jixo/packages/dev/src/reactive-fs/reactive-fs.ts
对于测试,我们可能需要做一份专门的spec,因为这次改攻动非常重要,特别是涉及到我们的内核,是我们项目代码质量飞跃的关键,所以必须附带完整的测试
界面上嗅探cli是否可用的时候，要先进入pending状态，然后再显示“不可用”或者“成功获得的版本号”。
嗅探直接使用openspec --version
如果嗅探到没有全局的openspec命令，界面上应该提供一个全局安装的按钮，点击就弹出终端的对话框。如果安装完成，那么就重新嗅探cli是否可以用。
每次嗅探的结果将会影响后续cli：也就是说用户如果自己卸载了cli，那么只要重新进入settings页面，页面会重新发起cli的嗅探，结果会变更，那么后续cli也能正确使用。
如果用户没有主动配置，那么界面上的input就不该有值，我们嗅探出来的默认值只能作为placeholder来显示
关于shell:true的使用。我觉得我们应该默认避免，虽然我们允许了自定义cli，导致你觉得应该使用shell:true，但这反而会为后续的使用带来很多不一致性的问题。
我个人的建议是：我们自己默认的两种模式：openspec和npx @fission-ai/openspec，本质其实是["openspec"]和["npx","@fission-ai/openspec"],其实完全可以使用shell:false。
而对于用户自定义的cli，我们默认用最简单的方式去处理：用正则匹配的方式来拆分成数组，然而shell-parser其实是一件复杂的事情，因此难免我们这种解析会出错，因此我们存在第二种方式，就是自定义JSON-Array。我们只需要判断自定义cli的开头是不是[，如果是就进入JSON-Array的解析方式。这样用户就可以通过自定义Array的方式来传递可靠的自定义cli。
现在我对Change进行Archive之后，会出现问题:
我们的对Archive本来应该在Dialog中显示我们的终端打印，然后成功后，Dialog继续现实终端打印，并且提示用户Archive已经成功。并且我们的路由自动跳转到archive页面。
然而现在路由没变，界面上现实着：“Change not found”；同时我们的Arcihive的Dialog也消失不见了，导致我们连终端打印也看不到了。
我们现在界面上有一个全局安装cli的按钮，目前只会在全局openspec不存在的时候会可用。也应该发生npx @fission-ai/openspec --version的版本号高于本地的时候，那么这时候界面上应该提示用户更新，同时全局安装的cli按钮也可用。
init底层逻辑依赖的文件夹检测存在问题，目前你的逻辑是按照是否存在再去监听，因为你觉得递归监听会导致性能问题。但这会导致如果我init生成了文件夹，你之前的的路基，这个新的文件夹是不会去设置监听的，因为你看不到它的出现。
我建议我们应该一劳永逸引入 @parcel/watcher ，让我们用最符合直觉的方式来监听我们的一整个项目目录，同时性能还能提高！代码也能进一步简化，质量和性能也能进一步提高。
要注意，我们使用tsdown在做编译，@parcel/watcher是二进制项目，所以应该被exclude，从而确保安装我们 openspecui 的时候 @parcel/watcher 也被作为依赖被安装。
基于parcel/watcher的监听机制中，我刚才做了这样的事情：
我首先初始化了 example：pnpm example:setup 然后启动了我们的ui： pnpm dev --dir example
接着最关键的来了，我清理了example目录，然后重新生成了example目录：
pnpm example:clean && pnpm example:setup
接着我发现对于example的文件夹监听就失效了。我需要重启pnpm dev --dir example才能恢复正常。
调查一下这是parcel/watcher的bug还是我们自己的bug，如果是parcel/watcher的bug，有什么规避方案吗？或者有什么本办法吗？
不确定你基于projectDir的删除检测是否可靠，但是我可以给你一个非常朴素的检测建议，就是轮询： 具体工作流程是这样的：
- 首先我们有一个3s的debunce，它会被我们的 parcel/watcher 发出的事件重置时间计时
- 如果事件陷入了沉默，那么我们就要尝试性地临时生成再删除一个临时文件
- 如果事件还是没有发出，我们就假设认为parcel/watcher实例实效了，那么就重新创建watcher实例ß
这个检查文件，你觉得要不要用我们的配置文件做？ 好处是不会产生冗余的文件，缺点是一个文件的职责有点冗余。 而且模式要改成只改变文件最后的变更时间但不变更内容（fs.utimesSync，我不知道只修改时间，watcher能否监听到它的变化，应该可以吧）。 但这就意味着，openspecui在启动并发现projectDir被init好了，那么我们就得在openspec文件夹中去初始化好我们的配置文件，即便它是无配置模式。
你觉得这个方案怎么样？
等一下，我突然想到一个方案：我们如果只是utimesSync我们的projectDir这个文件夹呢？这不是最符合直觉的吗？ 我们还得测试验证： 创建testDir目录->创建A文件->监听testDir目录->删除testDir目录->再次创建testDir目录和A文件->修改A文件->watcher没有收到事件->修改testDir的时间->watcher也没有收到事件。
虽然我们监听了一整个projectDir，但其实我们只是监听特定的几个文件或者文件夹的变更。 我们能否配置这些特点定的文件或者文件夹来提升我们监听的性能。
在移动端的模式下，顶部不要单调显示 OpenSpec，而是应该显示当前的 dirName（就是dirPath的最后一段）
在设置界面，API Server URL 这里的placeholder没有客观显示“默认的api-server-url”
我发现Changes页面，是proposal.md+tasks.md，其它文件你好像就忽略了， 请你仔细阅读 openspec[./references] 的源码了解 Change 的结构
如果你想通实际的案例进一步了解确认Change 的结构，
你可以看一下 /Users/kzf/Dev/GitHub/chain-services/openspec/changes/add-rwa-org-team-exchange-performance 这个文件夹的结构。
我的要求：
- 在 changes 页面中，合理地展示一项 Change 的内容
- 一个changes下面可能有多个specs吗？如果是的话，要考虑一下二级路由？如果不是的话，是不是一个 Tabs 就能解决展示的问题？
- 要更新一下我们的setup-example.ts。
- 如果这个 Change 的文件夹下面有其它的非 spec 的标准，在Tabs中，新增一个 Folder-Tab， 可以列出这个 Change 的文件夹的所有文件。在这个页面中，将是一个mini的code-editor，右边是文件列表，左边是monaco editor
- 所有新增或者修改的功能，底层一定是响应式的接口，可以实时变更的。参考现有的接口标准来进行开发。
- Tab-Folder
- Folder/Overview结构请你参考我们的ToC组件，它基于容器查询，在桌面端和移动端都有良好的体验。
- 除了要考虑移动端设计，还需要考虑文件可能过多，溢出列表的问题，因此你可以充分参考markdown-viewer的组件设计
- Folder自身没必要做 border 样式，专注于内容的样式就好，否则组件搭配在一起，会出现很多层border，体验会大大下降
- 打开Folder，然后切换到别的Tab，再切回Folder，会报错：
InstantiationService has been disposed Change Files的文件列表的顺序存在问题，是一个低级错误，请你审查并修复
- Folder/Overview结构请你参考我们的ToC组件，它基于容器查询，在桌面端和移动端都有良好的体验。
- Tab-Overview
- Affected Specs中的内容是不是重复出现了，我看到它重复展示了两个
rwa-org-team-exchange-performance。 - Affected Specs列表中的 Suffix:
ADDED，这个是什么意义？还有其它的状态值吗？ - Overview混合了多个md文件，但是ToC只显示了一层内容。md文件的ToC应该混入Overview的ToC。
- Affected Specs中的内容是不是重复出现了，我看到它重复展示了两个
因为Change Files的宽度有限，因此要考虑加入横向滚动。
path-marquee需要改进一下，它居然耦合的copy功能。 因此path-marquee要先拆分成两部分：
- path-marquee 要改名成 text-marquee，专注于内容的展示
- 新增一个 copy-button，可以展示“可复制”的小图标，以及复制成功的状态与交互。 将这两个组件组合在一起，替换现有的path-marquee组件
我发现project.tsx是自己维护了Tabs的逻辑，为什么不用我们统一封装的tabs组件，它有什么特殊需求吗？ 还有什么地方也是存在这样的特殊性？ 你有什么建议吗？
Change详情页面的顶部的header，使用容器查询来优化样式：在空间比较不够的时候，Archive按钮简化成只有Icon，不显示文字。
我们整个网站的是面向开发者的，因此默认使用monospace 字体。请你给我一些字体上的建议，我想对于到导航相关的字体（和openspec品牌相关的）使用像素字体。你有什么建议吗？
请你帮我优化字体，默认使用google font字体。 注意，我们整个架构是编译成静态文件，然后通过server服务来启动前端的。 我的要求是，如果识别到用户的第一语言使用的是中文，那么将html只的google-fonts-cdn换成中文源。 我比如说：
<link rel="preconnect" href="https://fonts.googleapis.com" />
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin />
<link
href="https://fonts.googleapis.com/css2?family=Roboto:ital,wght@0,100..900;1,100..900&display=swap"
rel="stylesheet"
/>这里的fonts.googleapis.com和fonts.gstatic.com统一改成fonts.googleapis.cn和fonts.gstatic.cn
- 右边的Files列表中，文件和文件夹没有按照正确地关系进行嵌套。比如说
spec.md应该嵌套在rwa-org-team-exchange-performance文件夹下，但是结果却跑到task.md文件下嵌套着。 - FolderEditorViewer 组件外层有一个空的div包裹着，导致h-full没有生效。
- 在Editor的最上方，最好显示完整的路径（vscode面包屑的那种效果）
你确实修复了问题，但是这不是我想看到的结果，因为现在你实在change-overfiew中自己完全实现了一套markdown-viewer的逻辑。 我的目的是让MarkdownViewer易用，所以MarkdownViewer在参数设计上就存在多种重载的可能。 因此我们的重点是：为什么MarkdownViewer无法满足你直接使用达成我们最终的目的？ 如何设计MarkdownViewer才能满足我们的这种自定义构建内容的需求？
不要急着写代码，说说你能想到的架构设计
我的建议是，做好单层的 MarkdownViewer，使用TocContext来做到多层嵌套。 比如说：
interface MarkdownViewerProps {
markdown: string | MarkdownViewerBuilder
}
{
/*自动去获取上下文的 TocContext，如果没有会自动创建，内部调用MarkdownContext组件的时候，会返回这个markdown内容的tocItems，然后插入到TocContext中 */
}
;<MarkdownViewer
markdown={({ H1, H2, Section }) => {
return (
<>
<H1>S1</H1>
{/*Section 会自动将内容的toc层级+1*/}
<Section>
{/*获取到 TocContext，并将渲染的内容注入给TocContext*/}
<MarkdownViewer markdown={'# markdown1'}></MarkdownViewer>
</Section>
<H2>S2</H2>
<Section>
<MarkdownViewer markdown={'## markdown2'}></MarkdownViewer>
</Section>
</>
)
}}
></MarkdownViewer>很好，接下来，我需要你将这个核心的 editor 视图独立成一个独立的组件 code-editor.tsx 来维护。
CodeEditor的统一逻辑是，非preview模式下，这些修饰全部关闭，而原始的行内容要完整展示，同时原本被隐藏起来的符号，统一是淡色的。
使用ViewTransition来配置我们的动画吧。
页面切换的时候，顶部总有一个Loading的文字，在页面内容出来的时候它在淡出，停影响观感的，特别是我们是本地webui项目，不是挂在网络上的，所以这个Loading的文字虽然有意义，但是要考虑一下如何优化？
Loading文字的问题是：它现在是和我们的内容做交叉过渡的是吧。这里的问题是，在交叉过渡的时候，很正常Loading淡化并下移动；页面内内容渐显然后向上移动。但是最终动画完成后，Loading又突然显示出来。和我们的页面内容层叠在一起，我试着加上 animation-fill-mode:forwards ，但是没有效果，我觉得是ViewTransition的配置导致的问题。
很好，果然是ViewTranstion的问题。大部分的页面都正常了，我还顺便修复了project页面Loading问题，它的Loading不该卸载TabContent中。 另外，Loading的出现除了考虑数据的网络加载，还要考虑页面渲染可能比较慢（因为我们要动态解析md，或者初始化编辑器，可能会比较卡），所以这方面还要考虑。
还有，我们的二级页面，也要考虑Loading的效果
change-header虽然做了容器查询的响应式，但是需要更进一步：字体的大小也应该随着容器伸缩而缩放。
我在调用archive的时候，前端收到的终端打印：
openspec archive -y add-2fa
Proposal warnings in proposal.md (non-blocking):
⚠ Requirement must have at least one scenario
⚠ Requirement must have at least one scenario
Validation errors in change delta specs:
✗ MODIFIED "Email And Password Login" must include at least one scenario
Validation failed. Please fix the errors before archiving.
To skip validation (not recommended), use --no-validate flag.
Process exited with code 0
虽然进程返回exit code 0,但是这里我们需要做一些额外的解析：“Validation errors”
我能想到的方案有两种，一种是执行之前调用一次openspec validate add-2fa，还有一种是直接解析处理openspec archive -y add-2fa。
我的建议是调用openspec validate add-2fa，因为它有更加完整的 stderr，exitCode也是相对标准的:1
在此之前还有一个问题，就是我明明archive没有成功，但是我们自己居然自己推测出最终archive的文件夹，然后做了去跳转。我觉得这个有点不合理。
- 要么基于文件夹的变更检查，检测到刚才archive文件夹多了一个文件夹，并且这个文件夹的id符合 yyyy-mm-dd-{id} 的规范，说明我们archive完成了，这时候跳转的按钮才能亮起。
- 要么基于archive的stdout打印，去做判断.这是我强制移动后的结果打印：
❯ openspec archive add-2fa --no-validate -y ⚠️ WARNING: Skipping validation may archive invalid specs. [2025-12-02T10:34:59.277Z] Validation skipped for change: add-2fa Affected files: openspec/changes/add-2fa Task status: 0/6 tasks Warning: 6 incomplete task(s) found. Continuing due to --yes flag. Specs to update: auth: update user: update Applying changes to openspec/specs/auth/spec.md: + 1 added ~ 1 modified Applying changes to openspec/specs/user/spec.md: + 1 added Totals: + 2, ~ 1, - 0, → 0 Specs updated successfully. Change 'add-2fa' archived as '2025-12-02-add-2fa'.
你觉得什么方案最好？
这个错误信息，得显示在我们统一的终端里面。但是你可以配置一个红色边框来代表最终的执行结果 exitCode!=0。因为这些内容本来就是来自终端。 这个validate终端的位置也应该和archive终端的位置一样，甚至可以用同一个终端窗口来模拟显示多次执行的内容打印。
对了你这个终端，是一个统一的组件吗？
还有，记得，我们的内容是放在一个Dialog里面的，这里面有Header/Body/Footer三段结果，你要确保整体不能超过溢出屏幕，比如 max-height:86vh。
如果超出高度，那边Body应该要能滚动
这个终端渲染应该是独立的通用组件，我们Dialog也应该是独立的通用组件。 然后才是把它们组合在一起。