Stores: วางแผนใน Repo ของตนเอง

เบต้า Stores, references, working context และ worksets เป็นฟีเจอร์ใหม่ ชื่อคำสั่ง, flags, รูปแบบไฟล์ และ JSON output อาจมีการเปลี่ยนแปลงระหว่างเวอร์ชันที่เผยแพร่ การสาธิตทั้งหมดด้านล่างได้ดำเนินการกับบิลด์ล่าสุด แต่ควรอ่านคู่มือนี้ซ้ำหลังจากอัปเดต

ปัญหาที่แก้ไข

OpenSpec โดยปกติจะอยู่ใน repo เดียวของโค้ด: โฟลเดอร์ openspec/ ที่อยู่ถัดจากโค้ดของคุณ เก็บ specs และการเปลี่ยนแปลงสำหรับ repo นั้น

สิ่งนี้จะใช้ไม่ได้เมื่อการวางแผนของคุณมีขนาดใหญ่กว่าหนึ่ง repo:

• งานของคุณครอบคลุมหลาย repos — ฟีเจอร์หนึ่งอาจกระทบ API server, web app และ shared library ควรให้โฟลเดอร์ openspec/ ของใครเก็บแผน?
• ทีมของคุณวางแผนก่อนที่โค้ดจะเกิดขึ้น หรือวางแผนสิ่งที่ไม่มีวันกลายเป็นโค้ดใน repo นี้
• ข้อกำหนดเป็นความรับผิดชอบของทีมหนึ่งและถูกใช้งานโดยทีมอื่น เวอร์ชัน wiki เบี่ยงเบนไป และ coding agent ของคุณก็ไม่สามารถอ่านมันได้อยู่แล้ว

Store คือคำตอบ: repo แยกต่างหากที่มีหน้าที่หลักคือการวางแผน มีโครงสร้าง openspec/ เหมือนที่คุณคุ้นเคยอยู่แล้ว — specs และ changes — พร้อมไฟล์ระบุตัวตนขนาดเล็ก คุณลงทะเบียนมันบนเครื่องของคุณครั้งเดียว โดยใช้ชื่อ จากนั้นคำสั่ง OpenSpec ปกติทุกคำสั่งสามารถทำงานใน store นั้นได้จากทุกที่

รูปร่างของโครงสร้าง

            team-plans  (ที่เก็บ: วางแผนใน repo ของตัวเอง)
            ├── .openspec-store/store.yaml     identity: "I am team-plans"
            └── openspec/
                ├── specs/      สิ่งที่ถูกต้องจริง
                └── changes/    สิ่งที่กำลังดำเนินการ
                      ▲
                      │ ลงทะเบียนบนแต่ละเครื่องด้วยชื่อ;
                      │ แชร์โดยการ push/cloning เหมือน repo ทั่วไป
        ┌─────────────┼─────────────┐
        │             │             │
    web-app       api-server     mobile-app
   (code repo)   (code repo)    (code repo)

มีกฎสองข้อที่ทำให้สิ่งนี้เรียบง่าย:

1. ที่เก็บคือ git repo ธรรมดา คุณ commit, push, pull และตรวจสอบมันเอง OpenSpec จะไม่ clone, sync หรือ push อะไรโดยอัตโนมัติ
2. การประกาศ ไม่ใช่กลไก Repo สามารถ ประกาศ ความสัมพันธ์กับ ที่เก็บได้ (แสดงด้านล่าง) การประกาศเปลี่ยนสิ่งที่ OpenSpec บอกคุณ — ไม่เปลี่ยนตำแหน่งที่คำสั่งของคุณทำงาน

ห้านาทีสู่ที่เก็บแรกของคุณ

สองคำสั่งพาคุณจากศูนย์ไปสู่การเปลี่ยนแปลงที่มีขอบเขตตามที่ตั้งค่าไว้:

openspec store setup team-plans --path ~/openspec/team-plans

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.

openspec new change add-login --store team-plans

Using OpenSpec root: team-plans (/Users/you/openspec/team-plans)
Created change 'add-login' at /Users/you/openspec/team-plans/openspec/changes/add-login/
Schema: spec-driven
Next: openspec status --change add-login --store team-plans

นั่นคือโมเดลทั้งหมด จากจุดนี้ วงจรชีวิตคือสิ่งที่คุณคุ้นเคย — status, instructions, validate, archive — พร้อม --store team-plans ในทุกคำสั่ง และคำแนะนำที่พิมพ์ออกมาก็จะรวม flag นั้นให้คุณแล้ว บรรทัด Using OpenSpec root: จะบอกคุณเสมอว่าคำสั่งนั้นกำลังทำงานอยู่ที่ใด

เรื่องเล่า: ทีมหนึ่ง, repo วางแผนหนึ่ง

ทีมเก็บ specs และการเปลี่ยนแปลงไว้ใน team-plans แทนที่จะกระจาย ไปทั่ว code repos

วันแรก (ใครก็ตามที่เป็นคนตั้งค่า):

openspec store setup team-plans --path ~/openspec/team-plans \
  --remote git@github.com:acme/team-plans.git
git -C ~/openspec/team-plans push -u origin main

การส่ง --remote จะบันทึก URL สำหรับ cloning ไว้ภายในไฟล์อัตลักษณ์ ของที่เก็บเอง (.openspec-store/store.yaml) ใน commit แรก ทุกครั้งที่ clone ในอนาคตจะถูกสร้างมาพร้อมกับความรู้เกี่ยวกับที่มาของมัน ดังนั้นการตรวจสอบ สุขภาพและข้อความข้อผิดพลาดจึงสามารถพิมพ์คำแนะนำการแก้ไขที่สมบูรณ์และ พร้อมวางสำหรับเพื่อนร่วมทีมที่ยังไม่มีข้อมูลนี้ได้

เพื่อนร่วมทีมทุกคน (ครั้งเดียวต่อเครื่อง):

git clone git@github.com:acme/team-plans.git ~/openspec/team-plans
openspec store register ~/openspec/team-plans

จากนั้นเป็นต้นมา ทุกคนทำงานใน repo วางแผนเดียวกันโดยใช้ชื่อ:

openspec status --store team-plans --change add-login
openspec show add-login --store team-plans

การแบ่งปันงานคือ git ตามเจตนา การเปลี่ยนแปลงที่คุณสร้างขึ้นจะมีอยู่เฉพาะ ในการ checkout ของคุณ จนกว่าคุณจะ commit และ push มัน — เหมือนกับโค้ด แผนจะมี branches, pull requests และการรีวิวฟรี เพราะที่เก็บคือ repo ธรรมดา

การเชื่อมต่อกับ code repos ของทีม Code repo ที่มีการวางแผนภายนอกทั้งหมด ต้องการบรรทัดเดียวเท่านั้น ใน openspec/config.yaml:

# web-app/openspec/config.yaml
store: team-plans

ตอนนี้ทุกคำสั่ง OpenSpec ที่รันภายใน web-app จะกระทำต่อ team-plans โดยไม่ต้องใช้ flag เลย:

cd ~/src/web-app
openspec status --change add-login

Using OpenSpec root: team-plans (/Users/you/openspec/team-plans)
...

ตัวชี้นี้เป็น fallback ไม่ใช่ override: --store ที่ระบุชัดเจนจะชนะเสมอ และหาก repo เติบโตจนมีโฟลเดอร์วางแผนของตัวเองจริงๆ โฟลเดอร์เหล่านั้นจะชนะ (พร้อมคำเตือนให้ลบตัวชี้ที่ล้าสมัยออก)

ค่าเริ่มต้นเดียวสำหรับทุก repo บนเครื่องของคุณ หากคุณทำงานข้าม code repos จำนวนมากที่วางแผนเข้าสู่ที่เก็บเดียวกัน ให้ตั้งค่าครั้งเดียวในระดับ global แทนที่จะเพิ่มบรรทัด store: ไปในแต่ละ repo:

openspec config set defaultStore team-plans

ตอนนี้คำสั่งใดๆ ที่รันนอกรากของการวางแผน — และไม่มี --store และไม่มี ตัวชี้โปรเจกต์ — จะถูกแก้ไปยัง team-plans มันอยู่ในลำดับความสำคัญต่ำสุด ดังนั้น --store, รากท้องถิ่น และตัวชี้ store: ของโปรเจกต์ ยังคงชนะอยู่ แบนเนอร์รากและบล็อก JSON root จะรายงาน source: "global_default" พร้อม id ของที่เก็บ เพื่อให้คุณสามารถแยกแยะค่าเริ่มต้นระดับเครื่องออกจากตัวชี้ของ repo ได้ ชำระล้างมันด้วย openspec config unset defaultStore หาก id ไม่ได้ลงทะเบียน คำสั่งจะเกิด error และบอกให้คุณลงทะเบียนหรือลบค่าเริ่มต้น ที่ล้าสมัยออก

ตัวอย่าง: ฟีเจอร์หนึ่ง, code repos สองตัว

สมมติว่าการเปลี่ยนแปลง add-checkout-promo ส่งผลต่อทั้ง checkout-api และ checkout-web ทีมต้องการสัญญาผลิตภัณฑ์ร่วมกันหนึ่งรายการ ในขณะที่แต่ละ code repo ยังคงต้องการงานนำปฏิบัติของตัวเอง branch และการรีวิวของตัวเอง

ใช้สองชั้น:

1. เก็บพฤติกรรมร่วมกันไว้ใน team-plans
2. เก็บแผนการนำไปปฏิบัติในแต่ละ component repo และอ้างอิงถึงที่เก็บ ในฐานะบริบท upstream แบบอ่านอย่างเดียว

ขั้นแรก วางแผนสัญญาร่วมกันในที่เก็บ:

openspec new change add-checkout-promo --store team-plans
openspec status --change add-checkout-promo --store team-plans

ข้อเสนอและ specs ควรอธิบายพฤติกรรมที่ขอบเขตระหว่าง components — เช่น ฟิลด์โปรโมชั่นที่บริการส่งคืน และ frontend จัดการกับการชำระเงินที่ไม่ผ่าน อย่างไร รีวิวการเปลี่ยนแปลงนี้ใน repo ที่เก็บเหมือน branch และ pull request อื่นๆ ทั่วไป

บริบทที่การวางแผนเห็นคืออะไร?

การเลือกที่เก็บเปลี่ยน OpenSpec root; มันไม่ค้นหาหรืออ่าน code repos ทั้งหมด ที่ใช้ที่เก็บนั้น คำแนะนำของที่เก็บเห็น artifacts และบริบทที่กำหนดค่าไว้ใน ที่เก็บ มันเห็นโค้ดของ component ก็ต่อเมื่อโฟลเดอร์เหล่านั้นพร้อมใช้งาน ให้กับ agent หรือ editor และ agent อ่านพวกมัน

Workset เป็นวิธีที่สะดวกในการเปิดที่เก็บวางแผนและ code repos ทั้งคู่พร้อมกัน:

openspec workset create checkout-promo \
  --member ~/openspec/team-plans \
  --member ~/src/checkout-api \
  --member ~/src/checkout-web \
  --tool code
openspec workset open checkout-promo

สิ่งนี้ทำให้โฟลเดอร์มองเห็นได้ใน workspace IDE เดียวกัน มันไม่ได้คัดลอก บริบทแหล่งที่มาเข้าไปในที่เก็บ ไม่ได้เลือก repos ที่ได้รับผลกระทบ หรือมอบ สิทธิ์ให้ agent แก้ไขพวกมัน ใส่ข้อเท็จจริงข้าม component ที่คงทนไว้ใน specs ร่วมกัน; อย่าพึ่งพาผู้วางแผนให้จำแหล่งที่มาที่บังเอิญตรวจสอบ

การนำปฏิบัติเริ่มในแต่ละ repo ได้อย่างไร?

เมื่อไม่มี --store ที่ชัดเจนหรือราก openspec/ ที่ใกล้กว่ามาใช้ ตัวชี้ store: team-plans จะกำหนดเส้นทางคำสั่งไปยังที่เก็บนั้น มันไม่ได้แบ่งรายการ งานของที่เก็บเดียวตามไดเรกทอรีที่ invoke apply OpenSpec ในปัจจุบันไม่ กำหนดเส้นทางงานไปยัง repos

เมื่อแต่ละ component ต้องการวงจร apply/review ที่มีขอบเขตอิสระ ให้สร้าง OpenSpec root ท้องถิ่นและอ้างอิงถึงที่เก็บกลางแทนที่จะชี้ไปที่มัน:

# checkout-api/openspec/config.yaml (และเช่นเดียวกับใน checkout-web)
schema: spec-driven
references:
  - team-plans

หลังจากสัญญาร่วมได้รับการอนุมัติและพร้อมใช้งานใน specs หลักของที่เก็บแล้ว สร้างการเปลี่ยนแปลงขนาดเล็กในท้องถิ่นสำหรับส่วนประกอบนั้น:

cd ~/src/checkout-api
openspec new change implement-checkout-promo-api

cd ~/src/checkout-web
openspec new change implement-checkout-promo-ui

ดัชนีอ้างอิงในคำแนะนำของแต่ละ repo จะให้สรุป specs ของที่เก็บและคำสั่ง fetch ที่แน่นอน (openspec show ... --store team-plans) ข้อเสนอในท้องถิ่นแต่ละ ฉบับอ้างถึงสัญญาร่วมนี้ และงานของพวกมันอธิบายเฉพาะงานในส่วนประกอบนั้น จากนั้นรัน /opsx:apply ในแต่ละ repo แยกกัน; การแก้รากจะรักษา artifacts และการแก้ไขการนำปฏิบัติให้มีขอบเขตใน repo นั้น การเปลี่ยนแปลงบริการและ frontend ตอนนี้สามารถทดสอบ รีวิว merge และ archive ได้อย่างอิสระ

หากต้องเริ่มการนำปฏิบัติในขณะที่การเปลี่ยนแปลงของที่เก็บร่วมกันยังคงอยู่ ให้ fetch มันอย่างชัดเจนด้วย openspec show add-checkout-promo --store team-plans; ดัชนีอ้างอิงจะ列出 specs ของที่เก็บแบบ canonical ไม่ใช่การเปลี่ยนแปลงของที่เก็บที่กำลังใช้งาน รักษา branch ของที่เก็บและ branch ของ component ให้เชื่อมโยงกันในคำอธิบาย pull-request เพื่อให้ผู้รีวิวสามารถดูได้ว่าเวอร์ชันของสัญญาใดที่การนำปฏิบัติ แต่ละฉบับปฏิบัติตาม

เรื่องเล่า: ข้อกำหนดที่ข้ามเส้นของทีม

ทีมแพลตฟอร์มเป็นเจ้าของข้อกำหนด ทีมผลิตภัณฑ์สร้างตามข้อกำหนดเหล่านั้น ใน repo ของตัวเอง ด้วยการออกแบบของตัวเอง การอ้างอิงอธิบายความสัมพันธ์นั้น โดยไม่ย้ายงานของใคร

   platform-reqs (store)                 api-server (code repo)
   owned by the platform team            owned by a product team
   ┌──────────────────────────┐          ┌──────────────────────────┐
   │ openspec/specs/          │ ◀────────│ openspec/config.yaml     │
   │   payments/spec.md       │ reads    │   references:            │
   │   auth/spec.md           │          │     - platform-reqs      │
   │                          │          │ openspec/specs/          │
   │ openspec/changes/        │          │   (their own designs)    │
   │   platform work          │          │ openspec/changes/        │
   │                          │          │   (their own work)       │
   │                          │          └──────────────────────────┘
   └──────────────────────────┘

ทีมผลิตภัณฑ์ประกาศสิ่งที่มันดึงมาจาก ใน openspec/config.yaml ของ repo:

references:
  - platform-reqs

การอ้างอิงเป็นบริบทแบบอ่านอย่างเดียว Repo รักษา OpenSpec root ของตัวเองไว้; งานยังคงอยู่ที่นั่น สิ่งที่เปลี่ยนไป: openspec instructions ใน repo นั้น ตอนนี้รวมถึงดัชนีของ specs จากที่เก็บที่อ้างอิง — แต่ละอันมีสรุปหนึ่งบรรทัด และคำสั่ง fetch ที่แน่นอน (openspec show <spec-id> --type spec --store platform-reqs) Agent ที่ทำงานใน api-server สามารถค้นหาข้อกำหนด การชำระเงิน upstream อ้างอิงถึงมัน และเขียนการออกแบบระดับต่ำลงในรากของ repo เอง — โดยไม่มีใครต้องคัดลอกบริบทไปรอบๆ

การอ้างอิงสามารถพกแหล่งที่มาของการ clone มาด้วย เพื่อให้เพื่อนร่วมทีมที่ยัง ไม่มีที่เก็บได้รับคำแนะนำการแก้ไขที่สมบูรณ์แทนที่จะเป็นทางตัน:

references:
  - { id: platform-reqs, remote: "git@github.com:acme/platform-reqs.git" }

เมื่อคุณต้องการเปิดแผนและโค้ดพร้อมกัน ให้สร้าง workset สิ่งนี้เป็นส่วนตัว และชัดเจน: แต่ละคนเลือกโฟลเดอร์ที่พวกเขาทำงานด้วยจริงๆ บนเครื่องของตน ไม่มีอะไรเกี่ยวกับเส้นทาง checkout ท้องถิ่นเหล่านี้ที่ถูก commit เข้าไปใน repo วางแผนร่วมกัน

openspec workset create platform \
  --member ~/openspec/platform-reqs \
  --member ~/src/api-server \
  --member ~/src/web-app

คำถามสองข้อที่คุณสามารถถามได้เสมอ

"การตั้งค่าของฉันมีสุขภาพดีหรือไม่?" — openspec doctor ตรวจสอบรากปัจจุบัน และที่เก็บที่มันอ้างอิงถึง แบบอ่านอย่างเดียว พร้อมคำแนะนำการแก้ไขที่พร้อมวาง สำหรับแต่ละข้อค้นพบ:

Doctor

Root
  Location: /Users/you/src/api-server
  OpenSpec root: ok

References
  - platform-reqs: ok (/Users/you/openspec/platform-reqs)
  - design-system: Referenced store 'design-system' is not registered on this machine.
    Fix: git clone -- git@github.com:acme/design-system.git '/Users/you/openspec/design-system' && openspec store register '/Users/you/openspec/design-system' --id design-system

"ฉันกำลังทำงานกับอะไร?" — openspec context ประกอบชุดการทำงานจากการประกาศ ของ OpenSpec: รากและที่เก็บที่มันอ้างอิง

Working context for api-server (/Users/you/src/api-server)

OpenSpec root
  api-server  /Users/you/src/api-server

Referenced stores
  platform-reqs  /Users/you/openspec/platform-reqs
    Fetch: openspec show <spec-id> --type spec --store platform-reqs

ทั้งสองรองรับ --json สำหรับ agents openspec context --code-workspace <path> ยังเขียนไฟล์ workspace ของ VS Code ที่ประกอบด้วยชุดทั้งหมด — การเขียน เพียงอย่างเดียวที่คำสั่งนี้ทำ

Worksets: เปิดโฟลเดอร์ที่คุณทำงานร่วมกันซ้ำๆ

แยกจากทั้งหมดที่กล่าวมาข้างต้น: ส่วนใหญ่แล้วผู้ใช้จะเปิดโฟลเดอร์เดียวกันจำนวนไม่กี่โฟลเดอร์ร่วมกันในทุกเซสชัน — เช่น โฟลเดอร์แผนงาน (planning repo) ร่วมกับโค้ดรีโพสิทอรีอีกสองหรือสามตัว Workset คือมุมมองส่วนบุคคลที่มีชื่อเฉพาะสำหรับสิ่งนั้น ซึ่งสามารถเปิดใหม่ได้ด้วยคำสั่งเดียวในเครื่องมือที่คุณเลือกใช้

  workset "platform"                 openspec workset open platform
  ├── team-plans   ~/openspec/team-plans         │
  ├── api-server   ~/src/api-server              ▼
  └── web-app      ~/src/web-app       ทั้งสามโฟลเดอร์เปิดในเครื่องมือของคุณ

openspec workset create platform \
  --member ~/openspec/team-plans --member ~/src/api-server \
  --tool code
openspec workset list

platform  (เปิดใน VS Code)
  team-plans  /Users/you/openspec/team-plans
  api-server  /Users/you/src/api-server

openspec workset open platform จะเรียกใช้เครื่องมือที่บันทึกไว้: ตัวแก้ไขข้อความ (editors) เช่น VS Code หรือ Cursor จะเปิดหน้าต่างเดียวพร้อมสมาชิกทุกตัวและเสร็จสิ้น โดยสมาชิกแรกจะเป็นหลัก คุณสามารถเปลี่ยนเครื่องมือได้ทุกเมื่อด้วย --tool <id>

Worksets ไม่ได้ถูกออกแบบให้เป็นสถานะร่วม (shared state) พวกเขาอยู่บนเครื่องของคุณเท่านั้น ไม่มีการ commit และไม่ได้ระบุอะไรเกี่ยวกับงาน — พวกมันเพียงบันทึกว่าคุณชอบเปิดโฟลเดอร์ใดร่วมกัน การลบ workset หนึ่งจะไม่ส่งผลกระทบต่อโฟลเดอร์สมาชิกใดๆ เครื่องมือใหม่ๆ เป็นการกำหนดค่า ไม่ใช่โค้ด: สิ่งใดๆ ที่สามารถเรียกใช้ได้ผ่านไฟล์ workspace หรือแฟลกการแนบโฟลเดอร์ต่อโฟลเดอร์ สามารถเพิ่มภายใต้คีย์ openers ในการกำหนดค่าระดับระบบ (openspec config edit) ได้

วิธีการที่คำสั่งตัดสินใจว่าจะดำเนินการที่ไหน

คำสั่งปกติทุกคำสั่งจะหา root ของมันในรูปแบบเดียวกัน ตามลำดับนี้:

1. --store <id>          คุณระบุชัดเจน           → store นั้น
2. nearest openspec/     มี root การวางแผนจริงที่นี่ → รีโพสิทอรีนี้
   (เดินขึ้นจาก cwd)
3. store: pointer        config.yaml ประกาศ store → store นั้น
4. defaultStore          กำหนดค่าระดับระบบตั้งค่าเครื่อง → store นั้น
                         ค่าเริ่มต้น
5. ไม่มีข้อใดข้างต้น     มี stores ที่ลงทะเบียนบนเครื่องนี้ → ข้อผิดพลาดพร้อม
                         หรือไม่?                      คำแนะนำในการเลือก
                         ไม่มี stores ที่ลงทะเบียน?      → ไดเรกทอรีปัจจุบัน
                                                          (พฤติกรรมคลาสสิก)

บรรทัด Using OpenSpec root: (และบล็อก root ในผลลัพธ์ --json) บอกคุณว่าอยู่ในกรณีใด

ข้อจำกัดที่ทราบ

• รูปแบบเบต้า. ทุกอย่างในหน้านี้อาจเปลี่ยนแปลงระหว่างเวอร์ชัน — ชื่อ, แฟลก, รูปแบบไฟล์, คีย์ JSON
• การ checkout หนึ่งต่อ store id ต่อเครื่อง. การลงทะเบียนการ checkout ครั้งที่สองภายใต้ id เดียวกันจะล้มเหลวพร้อมคำแนะนำให้ใช้ store unregister ก่อน
• ไม่มีการซิงค์เลย — โดยตั้งใจ. OpenSpec ไม่ทำการ clone, pull หรือ push การ checkout ที่ล้าสมัยจะแสดง specs ที่ล้าสมัยจนกว่า คุณ จะ pull; การอ้างอิงจะถูกอินเด็กซ์แบบเรียลไทม์จากสิ่งที่อยู่บนดิสก์
• โฟลเดอร์วางแผนว่างอาจไม่มีอยู่. Store ใหม่อาจยังไม่มี openspec/changes/, openspec/specs/, หรือ openspec/changes/archive/ ใน Git นั่นได้รับการยอมรับในช่วงเบต้า; โฟลเดอร์เหล่านี้จะปรากฏเมื่อคำสั่งปกติสร้างไฟล์สำหรับพวกเขา
• รีโพสิทอรีพอยน์เตอร์ยังคงเป็นพอยน์เตอร์. รีโพสิทอรีที่กำหนดค่าเพียงอย่างเดียวซึ่ง openspec/config.yaml ประกาศ store: <id> ถือเป็นการวางแผนภายนอก ไม่ใช่การ checkout store เพื่อลงทะเบียน ลบบรรทัด store: ออกก่อนหากคุณต้องการแปลงรีโพสิทอรีนั้นให้เป็น root store ท้องถิ่นโดยเจตนา
• บางคำสั่งยังคงอยู่ที่เดิม. templates และรูปนามธรรมที่เลิกใช้งานแล้ว (openspec change show, ...) ดำเนินการกับไดเรกทอรีปัจจุบันเท่านั้น — ไม่มี --store schemas ปฏิบัติตามลำดับความสำคัญของการเลือก root แบบมาตรฐานและยอมรับ --store <id> ในขณะที่คงรูปร่างอาร์เรย์ JSON ที่สำเร็จไว้เหมือนเดิม
• สถานะต่อเครื่องคือต่อเครื่อง. Registry ของ store และ worksets เป็นการตั้งค่าท้องถิ่น ไม่มีข้อมูลเกี่ยวกับการจัดเรียงเครื่องของคุณจะถูก commit ไปยังการวางแผนร่วมกัน
• สไตล์การเรียกใช้สองแบบสำหรับ worksets. เครื่องมือที่ไม่สามารถเรียกใช้ด้วยไฟล์ workspace หรือแฟลกการแนบโฟลเดอร์ต่อโฟลเดอร์ไม่สามารถเพิ่มเป็น opener ได้
• Agent JSON มีการแบ่งกรณีตัวพิมพ์ที่ทราบ (คีย์ตระกูล store เป็น snake_case, ตระกูล workflow เป็น camelCase) เอกสารไว้ใน agent contract; การรวมให้เป็นหนึ่งเดียวถูกระงับไว้จนถึงเวอร์ชันที่ออกอย่างเป็นทางการ

ตำแหน่งของสิ่งต่างๆ

สิ่งที่	อยู่ที่ไหน	แชร์ได้ไหม?
การวางแผนของ store	<store>/openspec/ (specs, changes)	ใช่ — commit และ push มัน
อัตลักษณ์ของ store	<store>/.openspec-store/store.yaml	ใช่ — commit พร้อม store
Registry ของ store	<data dir>/openspec/stores/registry.yaml	ไม่ — เฉพาะเครื่องนี้
Worksets	<data dir>/openspec/worksets/	ไม่ — เฉพาะเครื่องนี้

<data dir> คือ ~/.local/share/openspec บน macOS และ Linux (หรือ $XDG_DATA_HOME/openspec เมื่อตั้งค่า) และ %LOCALAPPDATA%\openspec บน Windows

อ้างอิง

แฟลกและรูปร่าง JSON ที่แน่นอนสำหรับคำสั่งทุกคำสั่งในหน้านี้: CLI reference (Stores, Doctor, Working context, Personal worksets) และ agent contract