OpenRig Library UI 组装指南:/specs 路由、Spec Review 流程与设计系统指针 人工智能AI Agent多智能体Agent 编排代码智能体CLI【免费下载链接】openrigMulti-agent harness that runs Claude Code and Codex together as one system项目地址https://gitcode.com/GitHub_Trending/op/openrig点击查看免费下载OpenRig 是运行 Claude Code 与 Codex 于一体的多 Agent 编排系统其 UI 中的 Library/specs路由负责统一呈现 specs、applications、context packs、agent specs、agent images、plugins 与 skills 七类可复用资产。本文以docs/as-built/ui/library-specs-and-design-system.md为骨架结合packages/ui/src/components/specs/、packages/daemon/src/domain/spec-review-service.ts、packages/daemon/src/domain/spec-library-service.ts、packages/cli/src/commands/specs.ts与docs/DESIGN.md的源码实现讲清 Library 页面的组件构成、spec review / spec library / live identity 三条数据流、可复用的 UI 图元清单以及设计系统规范的去向读完即可在 UI、daemon、CLI 三层之间定位任一 Library 能力的实现与调用链。1. Library / specs 表面组件与路由Library 目的地保持/specs作为路由产品标签为 Library。从路由注册文件 packages/ui/src/routes.tsx 可以看到完整的路由族/specs—— Library 主页面SpecsLibraryPage/specs/applications—— Applications 独立入口/specs/skills、/specs/skills/$skillToken、/specs/skills/$skillToken/file/$fileToken—— Skills 索引、详情与文件子路由/specs/plugins、/plugins/$pluginId—— Plugins 索引与详情/specs/rig、/specs/agent、/specs/library/$entryId—— Spec 审查表单与 Library 条目详情/specs/$specKind/$specName—— 兼容旧路由命中时重定向到/specs/library/$entryId组件全部位于 packages/ui/src/components/specs/与 as-built 文档逐一对齐组件职责SpecsLibraryPage.tsx/specsLibrary 主页面统一列表All / Apps / Rigs / Agents服务化条目渲染为APPSpecsTable.tsx/SpecsTreeView.tsx列表视图 Explorer 树视图SkillsIndexPage.tsx/SkillDetailPage.tsx基于文件夹的 Skills 索引与详情PluginsIndexPage.tsx/PluginDetailPage.tsx/AgentPluginsList.tsxPlugin 相关表面1.1 主页面分区SpecsLibraryPage通过五个 hooks 并行拉取数据useSpecLibrary、useContextPackLibrary、useAgentImageLibrary、useLibrarySkills、usePlugins然后按类别拆成区块渲染Rig Specs / Agent Specs / Applications来自同一个 spec library 数据源按kindrig/agent与hasServices标志分流——kind rig hasServices的条目进入 Applications无服务的 rig 留在 Rig Specskind workflow进入 Workflow Specs。Context Packs / Agent Images独立数据源Agent Images 行内会显示v{version}、~{tokens} tok、forks: N、used: Xm ago等元信息区块头部聚合徽章形如3 images · 128 MB字节格式化逻辑见SpecsLibraryPage.tsx中的formatBytes。Plugins / Skills两类作为全宽单列区块放在 spec 网格下方原因是它们行数波动比 spec 类别更大。Skills 行显示N files计数Plugins 行带ToolMark图标。一个值得注意的诊断细节当 workflow YAML 无法解析时specRow会生成status: error的诊断行——该行不可导航meta 位置内联展示 parser/validator 报错信息操作者可以在原地修复文件SpecsLibraryPage.tsx中LibraryRow的status error分支。工具栏动作来自TOOLBAR_ACTIONS常量 Add spec→/specs/rig、Import→/import、Discover→/search、Create rig→/specs/rig、Generate workflow→/specs/agent。1.2 Skills 树与详情页交互Skill 树把每个 skill 视为一个文件夹对应SkillsIndexPage的排序列表与SpecsTreeView的树形展示。点击 skill 打开详情路由默认大小写不敏感地定位skill.md通过共享的FileViewer在工作区中央渲染——没有第二个页内文件浏览器文件导航属于 Explorer 树。SkillDetailPage的实现印证了这一点它复用 daemon 的/api/skills/:id/files/list与文件读取接口左侧是带面包屑的目录树右侧是查看器。首次加载且无fileToken时自动以/^skill\.md$/i匹配skill.md作为默认文件TEXT_LIKE_EXTENSIONS集合覆盖了.md/.mdx/.txt/.log/.yaml/.yml/.json/.js/.tsx/.py/.sh/.css/.html等文本类型Markdown 走MarkdownViewer其余文本走SyntaxHighlight超出截断阈值时顶部会出现琥珀色截断提示条。Drift-noteplugin 原语是0.3.1的功能git 祖先证据v0.3.0缺失、v0.3.1存在。不要把/specs/plugins、/plugins/$pluginId路由或这些 plugin 组件回溯归因到 0.3.0。ui.md早于 0.3.x对 plugins 没有任何叙述——这些表面是根据源码与 slice-00 0.3.0-GT seam 编写的并非迁移而来。2. Spec review / library / live-identity 数据流这三条 daemon 支撑的数据流喂给 Library UI对应architecture.md§6 的 Spec review and spec library flow 与 Live identity / specs UI flow。2.1 Raw YAML 审查/api/specs/review/rig与/api/specs/review/agentUI/CLI 把 YAML POST 给/api/specs/review/rig或/api/specs/review/agent由SpecReviewService解析、校验并返回结构化审查模型。路由实现在 packages/daemon/src/routes/spec-review.ts请求体为{ yaml: string; sourceState?: draft | file_preview | library_item }缺yaml返回 400校验失败返回{ errors: string[] }400其他异常返回 500。核心逻辑在 packages/daemon/src/domain/spec-review-service.tsRigSpecreviewRigSpec先用RigSpecCodec.parse做 YAML 解析再按是否含顶层pods数组分流为 pod-aware新格式或 legacy旧格式两类审查。pod-aware 格式会提取 pods、membersagent_ref/runtime/profile、pod 内与跨 pod edges并推导图数据——节点 id 采用{podId}.{memberId}限定runtime terminal的节点归类为infrastructure其余为agent。若存在services.kind compose还会提取compose_file、project_name、down_policy、wait_for与surfacesurls/commands元数据。AgentSpecreviewAgentSpec走parseAgentSpecvalidateAgentSpecprofiles 以 map 形式展开为数组resources 按skills/guidance/plugins/subagents抽取路径plugins 条目取id作为人可读句柄操作者识别 openrig-core 而非一长串绝对路径startup 提取files含required标志与actions。校验失败统一抛出SpecReviewError携带错误列表。UI 侧通过RigSpecDisplay/AgentSpecDisplay渲染这些审查模型——同一组图元同时用于草稿预览、library 审查与运行时完整详情这是 同一数据模型贯穿三态 的关键设计。2.2 文件系统级 librarySpecLibraryServicepackages/daemon/src/domain/spec-library-service.ts 扫描 builtin 用户根目录根目录packages/daemon/specsbuiltin、~/.openrig/specs用户、legacy 回退~/.rigged/specs。每个 YAML 通过classifySpec先试 rig 后试 agent均失败则跳过rig 且含services对象的条目标记hasServicesworkflow 条目单独来自workflow_specsSQLite 缓存由路由层setWorkflowEntries一次性替换投影不参与 YAML 扫描。条目 id 为sha256(sourceType:relativePath)的前 16 位builtin 根只索引rigs/**/rig.yaml与**/agent.yamlshouldIndexRelativePath用户根全量收录。扫描跳过噪声目录.worktrees、node_modules、.git、dist、build、.turbo、.next——其中.worktrees条目专门堵住 worktree 内 conveyor.yaml 滑入 library 缓存导致rig specs show conveyor歧义匹配 的 UX 缺陷。/api/specs/library提供 list/get/review/syncremove/rename仅对user_file类型开放builtin 只读。2.3 CLI 镜像rig specs ls/show/preview/add/syncpackages/cli/src/commands/specs.ts 实现了与 UI 对等的 CLI 表面rig specs ls—— 列出 library 中的 rigs、agents、workflows 与 managed apps。rig specs show nameOrId—— 展示指定 spec 详情。rig specs preview nameOrId—— 预览审查模型。rig specs add path—— 安装单个 YAML spec 或整个 spec 目录。安装时严格执行安全约束requireRegularFile与assertTreeHasNoSymlinks拒绝 symlink目录安装要求内含rig.yaml/rig.yml/agent.yaml/agent.yml之一作为根 spec。rig specs sync—— 同步扫描。rig up/rig bootstrap在解析其他 source kind 之前优先解析 library 名称保证名称解析的优先级契约。2.4 Live identity运行时优先的右侧抽屉Explorer/图选择打开共享右侧抽屉运行时优先的节点详情live identity、peers、有向边、transcript 辅助、紧凑 spec 摘要。Open Full Details导航到中心工作区的/rigs/$rigId/nodes/$logicalId。3. UI 图元清单对照源码修订Drift-fixui.md的 Design PrimitivesL75–107遗漏了ProjectPill。docs/DESIGN.mdL195 列了它且在 HEAD 确认为真实导出packages/ui/src/components/project/ProjectMetaPrimitives.tsx 第 199 行export function ProjectPill。以下清单以源码为准不采信两份文档的列表。Vellum/basecomponents/ui/VellumCard、VellumSheet、RegistrationMarks、StatusPip、SectionHeader、EmptyState、Button、Tabs、Table、表单控件外加rig-stamp.tsx的RigStamp——HEAD 存在但不在ui.md列表中。Graphicscomponents/graphics/RuntimeMark.tsxRuntimeMark、RuntimeBadge、ToolMark、ToolBadge、ActorMark、OperatorMoodMark归一化逻辑在lib/runtime-brand.tslib/tool-brand.ts。Library 各区块行首的ToolMark toolskill即来自此套件。Project metadatacomponents/project/ProjectMetaPrimitives.tsxProjectPill:199、EventBadge:227、QueueStateBadge:231、TagPill:277、ActorChip:286、DateChip:306、FlowChips:318、ProofThumbnailGrid:337、ProofPacketHeader:383外加源码中存在的QueueCountIcon/StatusDot不在 ui.md/DESIGN.md 图元列表。ViewersFileViewercomponents/drawer-viewers/FileViewer.tsx、MarkdownViewercomponents/markdown/MarkdownViewer.tsx、ProofImageViewer、SessionPreviewPanecomponents/preview/。4. 设计系统指针docs/DESIGN.mdQ1非副本OpenRig 规范的视觉/设计系统位于仓库根目录的docs/DESIGN.md不在docs/as-built/下。Q1 已批准DESIGN.md 保留在根目录、逐字节不变本模块只做指针而不复制其内容。DESIGN.md 是以下规范的唯一来源表面语言Vellum Paper持久产品表面白色半透明填充bg-white/25–bg-white/40、backdrop-blur-[8px]、1px 描边、仅纸卡硬阴影、四角方形与 Black Glass临时预览浮层如bg-stone-950/65终端 popover 与截图/证明浮层无硬阴影、无 1px vellum 边框。颜色令牌packages/ui/src/globals.css定义、packages/ui/tailwind.config.ts暴露。Paper 栈--background: 47 20% 97%#faf9f5 起、Ink 栈--on-surface: 120 8% 19%#2e342e、技术线稿--secondary: 213 15% 39%、状态色success/warning/tertiary/error与边框--outline/--outline-variant。规则结构性边框优先用outline-variantstone-900 边框只留给重要卡片边缘、激活 tab 与硬战术强调禁止为每个功能造一套一次性配色。排版font-bodyInter正文、font-headlineSpace Grotesk标题/盖章标题、font-monoJetBrains Mono标签、ID、队列状态、技术元数据、终端预览。产品标签用大写 mono tracking-[0.10em]左右正文用句子大小写代码标识符尽量转成人可读标签而非原样展示。布局48px 图标 rail桌面 Explorer 侧栏 中心工作区 右侧抽屉 preview 栈。层级作用域Topology 为 host → rig → pod → seatProject 为 workspace → mission → slice。图元清单、Graphics 系统、交互/动效/无障碍/do-and-do-not 规则见 DESIGN.md 全文。对账说明DESIGN.md 的图元清单已对照packages/ui/src/components/独立验证——它点名的每一类图元Vellum、Graphics、Project-metadata、Topology、Preview在 HEAD 都解析到真实导出。DESIGN.md 准确且无 slice-00 数字漂移因此原样引用。不要在此重复其内容视觉规范请直接阅读docs/DESIGN.md。5. 从 Library 表面追溯到底层的四层调用链把前三节串起来一个 Library 条目的完整链路是持久化/发现层SpecLibraryService.scan()遍历 builtin 与用户根classifySpec逐文件调SpecReviewService判定 rig/agent 类型并生成结构化审查模型。API 层spec-library.tslist/get/review/sync workflow 条目刷新与spec-review.tsrig/agent 审查两个 Hono 路由挂在 daemon 上。CLI 层rig specs ls/show/preview/add/sync通过DaemonClient调用上述 APIadd负责把本地 YAML 安装进用户根~/.openrig/specs后触发重新扫描。UI 层SpecsLibraryPage等组件经 hooksuseSpecLibrary、useLibrarySkills、usePlugins等消费 API用SectionHeader/ToolMark/EmptyState/FileViewer等图元渲染成 Vellum 风格的 Library 表面。同一条审查模型RigSpecReview/AgentSpecReview在 draft previewsourceState: draft、library reviewsourceState: library_item与 live 详情三处复用正是 spec-review → spec-library → live-identity 三条数据流共享同一套渲染原语的原因。延伸阅读docs/DESIGN.md —— 规范视觉/设计系统规范指针勿复制。docs/as-built/ui/shell-and-routing.md ——/specs路由族 shell drawer。docs/as-built/architecture/agent-spec-and-startup.md —— review 流程背后的 spec 解析/解析契约。docs/as-built/architecture/plugin-agent-image-context-pack.md —— plugins/agent-image/context-pack Library 表面背后的 0.3.1 内容层。源码根目录packages/ui/src/components/specs/、packages/daemon/src/domain/spec-review-service.ts、packages/daemon/src/domain/spec-library-service.ts、packages/cli/src/commands/specs.ts、packages/ui/src/routes.tsx。赞分享人工智能AI Agent多智能体Agent 编排代码智能体CLI【免费下载链接】openrigMulti-agent harness that runs Claude Code and Codex together as one system项目地址https://gitcode.com/GitHub_Trending/op/openrig点击查看免费下载相关推荐Flowable 引擎入门实战指南从命令行应用到 REST API 快速上手Flowable 引擎入门实战指南从命令行应用到 REST API 快速上手 本指南完整讲解 Flowable 工作流引擎的入门路径先在纯 Java SE人工智能AI Agent多智能体Agent 编排代码智能体CLIPOLAR-14B-v0.2韩国AI新星14亿参数韩语大模型完全解析POLAR 14B v0.2韩国AI新星14亿参数韩语大模型完全解析 POLAR 14B v0.2是由韩国Plateer公司AI实验室开发的韩语大语言模型Solidity开发者必备工具Surya describe命令快速分析合约结构Solidity开发者必备工具Surya describe命令快速分析合约结构 Surya是一款专为Solidity智能合约系统设计的实用工具提供了多种可视上一篇swagger-codegen 生成的 Java 客户端 Pet 模型全解析字段、枚举与代码生成原理下一篇Rails Action Cable 新版本变更解读Configuration 迁移、订阅拒绝语义、Server 抽象层重构与 Origin 校验修复创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考