新闻详情

新闻详情

首页 / 资讯中心 / 详情

如何用 OpenSpec Store 建立跨仓库的独立规划仓库?

发布时间:2026/9/9 18:57:40来源:尧图网络
如何用 OpenSpec Store 建立跨仓库的独立规划仓库?
如何用 OpenSpec Store 建立跨仓库的独立规划仓库【免费下载链接】OpenSpecSpec-driven development (SDD) for AI coding assistants.项目地址: https://gitcode.com/GitHub_Trending/op/OpenSpec如果你的规划横跨多个代码仓库——一个功能同时改 API 服务、Web 前端和共享库——OpenSpec 默认的「每个仓库一个openspec/目录」模式就装不下这份规划specs 和 changes 不知道该放进谁的仓库。OpenSpec 的 Store 功能把规划移到一个独立仓库里这个仓库只负责规划结构与普通项目里的openspec/相同再靠一个身份文件声明自己是哪个 store。你把它在本机按名字注册一次之后status、new change、validate、archive等常规命令都可以从任意目录对它操作。适用前提OpenSpec 已通过npm install -g fission-ai/openspeclatest安装。Stores 目前处于 Beta 阶段命令名、参数和文件格式可能在后续版本中变化升级后建议重读 Stores 使用指南 和 CLI 参考。Store 仓库长什么样一个 store 仓库包含两样东西team-plans (store) ├── .openspec-store/store.yaml 身份文件声明这个仓库是哪个 store └── openspec/ ├── specs/ 已确认的行为what is true └── changes/ 进行中的变更what is in motion两条规则决定了它与代码仓库的协作方式Store 就是一个普通 git 仓库。commit、push、pull、review 都由你自己完成OpenSpec 永远不会替你 clone、pull 或 push。声明而不改变行为。代码仓库可以在配置里声明自己与 store 的关系声明只改变 OpenSpec 能告诉你什么不改变命令作用在哪里。第一步创建一个 store由一个人比如团队里的你执行一次即可。非交互式写法是显式传入 id 和路径openspec store setup team-plans --path ~/openspec/team-plans--path指定 store 在本机的位置文档中给出的建议位置是~/openspec/id。如果希望每个 clone 出来的人都自动知道该从哪拉取可以在创建时记录规范远端地址openspec store setup team-plans --path ~/openspec/team-plans \ --remote gitgithub.com:acme/team-plans.git--remote会把 clone URL 写入 store 自己的身份文件.openspec-store/store.yaml并进入初始提交之后健康检查和错误提示就能给出完整、可直接粘贴的修复命令。执行成功后文档展示的示例输出如下Store ready: team-plans Location: /Users/you/openspec/team-plans OpenSpec root: ready Registry: registered Next: run normal OpenSpec commands against this store, for example: openspec new change change-id --store team-plans Share this store by committing and pushing it like any Git repo.这是文档示例你的Location会显示自己机器上的实际路径。此时本机注册表已记录该 store注册表只存在于本机。另外两个可选参数--no-init-git跳过所有 Git 动作不 init、不做初始提交--json输出 JSON供脚本和 agent 使用非交互运行必须同时传 store id 和--path。第二步把 store 发布到 git 主机setup 完成后按文档给出的两种做法之一把它推送到团队的 git 主机方式一创建时已传--remote身份文件里已记录远端只需推送git -C ~/openspec/team-plans push -u origin main方式二未传--remote先手动关联远端再推送cd ~/openspec/team-plans git remote add origin gitgithub.com:acme/team-plans.git git push -u origin main前提是 git 主机上已存在一个空的team-plans仓库。第三步团队成员加入 store每位队友在每台机器上执行一次git clone gitgithub.com:acme/team-plans.git ~/openspec/team-plans openspec store register ~/openspec/team-plansstore register只是告诉本机这个 store 在哪里。store 的名字早已提交在仓库内的.openspec-store/store.yaml中所以只有 clone 出来的副本需要这一步setup 时创建者的副本已被自动注册。注册成功时文档示例输出为Store registered: team-plans Location: /Users/you/openspec/team-plans OpenSpec root: ready Registry: registered如果某个文件夹下想以不同 id 注册可以加--id id该参数默认取 store 元数据或文件夹名。验证 store 是否可用在任意目录下按名字引用 storeopenspec status --store team-plans文档示例输出Using OpenSpec root: team-plans (/Users/you/openspec/team-plans) No active changes. Create one with: openspec new change name --store team-plans判断标准就是开头那行Using OpenSpec root:——它告诉你命令实际作用在哪个 root 上。之后整个生命周期与平时完全一致status、instructions、validate、archive每条命令带上--store team-plans且每条输出中的下一步提示都自带该参数。还可以用以下只读命令确认本机状态openspec store list # 列出本机已注册的 store openspec doctor # 检查当前 root 及其引用的 store发现问题给出可粘贴的修复命令 openspec context # 列出当前目录实际工作的 root 与被引用 storedoctor与context均支持--json。让代码仓库连接到这个 store建好 store 后代码仓库有三种接入方式按你的组织形式选择。store-only仓库不再保留自己的规划仓库的openspec/config.yaml只写一行# web-app/openspec/config.yaml store: team-plans此后在该仓库内执行的所有 OpenSpec 命令都不需要任何参数就直接作用于team-planscd ~/src/web-app openspec status --change add-login注意这是回退指针而非覆盖显式--store永远优先如果仓库后来长出了真实的specs/或changes/文件夹那些文件夹会生效并附带提示你移除过时的指针行。没有这行配置时在 store-only 项目里跑普通命令OpenSpec 会报错并列出本机已注册的 store 供选择。这行配置应提交进仓库队友 clone 后仍需在自己机器上完成第三步的 register否则 OpenSpec 会报错并提示注册。references仓库保留自己的规划只读引用 store适合「平台团队拥有需求、产品团队各自在自己仓库里设计实现」的场景。在仓库的openspec/config.yaml里声明references: - team-plans引用是只读上下文工作仍然留在仓库自己的openspec/root 里改变的只是openspec instructions的输出——其中会附带被引用 store 的 specs 索引每条含一行摘要和精确的获取命令openspec show spec-id --type spec --store team-plans。引用也可以携带 clone 来源让没有该 store 的队友从doctor得到一条完整的修复命令references: - { id: team-plans, remote: gitgithub.com:acme/team-plans.git }defaultStore一台机器上所有仓库的默认值如果你在多个代码仓库间工作、它们都规划进同一个 store可以设一次机器级默认省得每个仓库都加store:行openspec config set defaultStore team-plans它处于解析优先级最底层--store、本地 root、项目store:指针都仍优先于它。root banner 和 JSON 的root块会用source: global_default标出这是机器级默认。撤销用openspec config unset defaultStore。若该 id 未注册命令会报错并提示你注册或清除这个过时的默认值。汇总一下 OpenSpec 决定命令作用位置的完整顺序1. --store id 显式指定 → 该 store 2. 最近的 openspec/ 从 cwd 向上找到的真实规划 root → 当前仓库 3. store: 指针 config.yaml 声明了 store → 该 store 4. defaultStore 全局配置的机器默认 → 该 store 5. 以上都没有 本机注册过 store → 报错并给选择提示 没有注册过 → 当前目录传统行为一个跨两仓库的完整例子假设add-checkout-promo同时改checkout-api和checkout-web团队要一份共享的产品契约同时各仓库保留自己的实现任务、分支和 review。文档给出的做法是两层共享行为放进 store各组件仓库各自建立本地 change 并把 store 作为只读上游引用即上文的references:。先在 store 里规划共享契约openspec new change add-checkout-promo --store team-plans openspec status --change add-checkout-promo --store team-plans提案和 specs 描述的是组件边界的对外行为。然后在各组件仓库里建小的本地 change如implement-checkout-promo-api、implement-checkout-promo-ui每个本地提案引用共享契约任务只写本组件的工作再各自执行/opsx:apply——root 解析保证产物和实现编辑都限定在本仓库内两个组件的变更可以独立测试、review、合并、归档。两个边界选择 store 只改变 OpenSpec root不会自动发现或读取使用该 store 的每个代码仓库OpenSpec 目前也不按调用目录拆分任务路由到仓库。如果共享契约还在 store 中处于 active 状态需要显式用openspec show add-checkout-promo --store team-plans获取——references 索引列出的是 store 里已确认的 canonical specs不含 active 的 store changes。常见问题与限制Beta 形态本指南涉及的命令名、flags、文件格式、JSON 键都可能跨版本变化升级后重读文档。每个 store id 每台机器只允许一个 checkout用同一 id 注册第二个 checkout 会失败提示先执行openspec store unregister id。store remove id则会连同删除本地文件夹交互式终端会先展示要删的确切路径脚本和 JSON 调用方必须传--yes确认文件夹内没有匹配的 store 元数据时 OpenSpec 拒绝删除。设计上永不同步OpenSpec 不 clone、不 pull、不 push。过时的 checkout 会一直显示过时的 specs直到你自己 pullreferences 是从磁盘上的内容实时索引的。新建 store 可能缺少空文件夹openspec/changes/、openspec/specs/、openspec/changes/archive/在 beta 期间可以暂时不存在等常规命令为它们创建文件时自然出现。指针仓库永远是指针openspec/config.yaml里声明了store: id的 config-only 仓库被视为外部化规划不会被注册为 store checkout想把它转成本地 root先删掉store:行再执行openspec initinit 在声明存在时会拒绝脚手架。部分命令保持本地行为init、update、templates、schemas和openspec schema子命令只作用于当前目录不接受--store。机器级状态不共享store 注册表和 worksets 都是本机配置你的机器布局永远不会被提交进共享规划仓库。注册表位于data dir/openspec/stores/registry.yaml其中data dir在 macOS/Linux 上是~/.local/share/openspec设置了$XDG_DATA_HOME时为$XDG_DATA_HOME/openspecWindows 上是%LOCALAPPDATA%\openspec。如果产物出现在了意外位置跑一次openspec doctor它只读地检查当前 root 和引用的 stores并为每条发现打印一条可粘贴的修复命令。完整的命令与 JSON 输出形态可继续查阅 CLI 参考 和 Stores 指南。【免费下载链接】OpenSpecSpec-driven development (SDD) for AI coding assistants.项目地址: https://gitcode.com/GitHub_Trending/op/OpenSpec创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
网站建设高端定制企业官网
RELATED

相关资讯

更多精彩内容,欢迎继续阅读

较早相关资讯

最新相关资讯

专科生AI论文写作工具实测:10款神器助你从初稿到降重一次搞定 2026/9/9 19:30:46

专科生AI论文写作工具实测:10款神器助你从初稿到降重一次搞定

开头部分我先说明一下,这篇文章的受众非常明确:正在写专科毕业论文、毕业设计、或者在准备专升本/自考论文的同学。专科生的论文体量和深度跟本科、研究生不一样,核心诉求是“快速成稿、格式达标、文献够用、查重过关”,不需要跟学…

阅读更多 →
SpringBoot+Vue居家办公系统毕设项目:功能解析与部署指南 2026/9/9 19:30:46

SpringBoot+Vue居家办公系统毕设项目:功能解析与部署指南

毕设季总能看到一个现象:宿舍楼里几个计算机专业的同学,白天跑招聘、晚上开会写文档,到了交中期检查的前一周才开始疯狂找能跑的源码。我不是说临时抱佛脚是对的,但如果你正处在"需要一个完整全栈项目作为毕业设计或课程设计…

阅读更多 →
Spring Bean生命周期详解:从实例化到销毁的完整流程与最佳实践 2026/9/9 19:30:46

Spring Bean生命周期详解:从实例化到销毁的完整流程与最佳实践

SpringBean的生命周期这个问题,我从刚学Spring就被面试官问过,工作几年后又因为线上启动变慢、AOP代理不生效这些怪问题,回头认真把生命周期重新盘了一遍。说句大实话,它绝对不只是用来应付八股问答的知识,而是把IoC容…

阅读更多 →
Redis分布式核心技术与工程实践:从主从复制到集群高可用 2026/9/9 19:30:46

Redis分布式核心技术与工程实践:从主从复制到集群高可用

1. 单机撑不住之后:分布式到底在解决什么问题我印象特别深,第一次真正被分布式系统“逼到墙角”,是在负责一个用户积分系统的深夜。当时单机MySQL加单机Redis的架构已经跑了快两年,某天活动运营突然上线了一个签到裂变玩法&#x…

阅读更多 →
React三阶段通关指南:新面试题与踩坑记录全整理 2026/9/9 19:30:45

React三阶段通关指南:新面试题与踩坑记录全整理

前端三阶段里,React 这关到底怎么过?我把新增面试题和踩坑记录一次整理完了 如果你是正在培训机构学前端、刚好走到第三阶段 React 的朋友,或者你已经在用 React 写项目但总感觉自己面试时说不清楚原理,那这篇内容应该能帮上忙。…

阅读更多 →
frp 如何把 INI 配置迁移到 TOML、YAML 或 JSON 格式 2026/9/9 19:27:45

frp 如何把 INI 配置迁移到 TOML、YAML 或 JSON 格式

frp 如何把 INI 配置迁移到 TOML、YAML 或 JSON 格式 【免费下载链接】frp A fast reverse proxy to help you expose a local server behind a NAT or firewall to the internet. 项目地址: https://gitcode.com/GitHub_Trending/fr/frp frp 从 v0.52.0 起支持 TOML、Y…

阅读更多 →

今日资讯

本周资讯

本月资讯

看完文章仍有疑问?

联系尧图顾问,获取一对一建站咨询

立即免费咨询 📞 400-888-8888
📞