OpenSpec

เวิร์กโฟลว์ ​

คู่มือนี้ครอบคลุมรูปแบบเวิร์กโฟลว์ทั่วไปสำหรับ OpenSpec และเมื่อใดควรใช้แต่ละรูปแบบ สำหรับการตั้งค่าพื้นฐาน ดู เริ่มต้นใช้งาน สำหรับอ้างอิงคำสั่ง ดู คำสั่ง

ปรัชญา: การกระทำ ไม่ใช่ขั้นตอน ​

เวิร์กโฟลว์แบบดั้งเดิมบังคับให้คุณผ่านขั้นตอนต่าง ๆ: วางแผน จากนั้นนำไปปฏิบัติ แล้วเสร็จ แต่การทำงานจริงไม่ได้เข้ากรอบอย่างชัดเจน

OPSX ใช้แนวทางที่แตกต่าง:

text
Traditional (phase-locked):

  PLANNING ────────► IMPLEMENTING ────────► DONE
      │                    │
      │   "Can't go back"  │
      └────────────────────┘

OPSX (fluid actions):

  proposal ──► specs ──► design ──► tasks ──► implement

หลักการสำคัญ:

  • การกระทำ ไม่ใช่ขั้นตอน - คำสั่งคือสิ่งที่คุณสามารถทำได้ ไม่ใช่ขั้นตอนที่คุณติดอยู่
  • การพึ่งพาคือตัวเปิดโอกาส - แสดงให้เห็นว่าอะไรเป็นไปได้ ไม่ใช่สิ่งที่ต้องทำต่อ

การปรับแต่ง: เวิร์กโฟลว์ของ OPSX ทำงานด้วย schemas ที่กำหนดลำดับของ artifacts ดู การปรับแต่ง สำหรับรายละเอียดการสร้าง schemas แบบกำหนดเอง

ภาพรวมของเวิร์กโฟลว์ ​

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

mermaid
flowchart TD
    Idea["Idea or problem"] --> Explore["/opsx:explore<br/>(optional)"]
    Idea --> Propose["/opsx:propose"]
    Explore --> Propose
    Propose --> Review{"Planning artifacts<br/>ready?"}
    Review -->|"Refine"| Update["/opsx:update"]
    Update --> Review
    Review -->|"Implement"| Apply["/opsx:apply"]
    Apply -->|"Plan changed"| Update
    Apply --> Archive["/opsx:archive"]
    Apply --> Verify["/opsx:verify<br/>(optional, custom selection)"]
    Apply --> Sync["/opsx:sync<br/>(optional before archive)"]
    Verify --> Verified{"Ready to archive?"}
    Verified -->|"Fix implementation"| Apply
    Verified -->|"Revise plan"| Update
    Verified -->|"Ready"| Sync
    Verified -->|"Ready"| Archive
    Sync --> Archive

ผู้ช่วย AI ขับเคลื่อนเวิร์กโฟลว์ ในขณะที่ CLI ให้การวางโครงสร้างที่กำหนดได้เอง สถานะ และคำแนะนำเกี่ยวกับอาร์ติแฟกต์:

mermaid
sequenceDiagram
    actor Human
    participant Assistant as AI assistant
    participant CLI as OpenSpec CLI
    participant Files as Planning and implementation files

    Human->>Assistant: /opsx:propose "change"
    Assistant->>CLI: openspec new change
    CLI->>Files: Scaffold change metadata
    Assistant->>CLI: Request status and artifact instructions
    CLI-->>Assistant: Build order, paths, and templates
    Assistant->>Files: Write schema-defined planning artifacts
    Assistant-->>Human: Present artifacts for review

    Human->>Assistant: /opsx:apply
    Assistant->>CLI: Request apply instructions
    CLI-->>Assistant: Context files and task state
    Assistant->>Files: Implement tasks and update checkboxes
    Assistant-->>Human: Report implementation status

    Human->>Assistant: /opsx:archive
    Assistant->>CLI: Request archive inputs and artifact status
    CLI-->>Assistant: Planning paths and artifact completion
    Assistant->>Files: Read task state and compare delta specs
    opt Delta specs exist
        Assistant-->>Human: Offer to sync before archiving
        alt Sync accepted
            Human->>Assistant: Confirm sync
            Assistant->>Files: Merge delta specs into main specs
        else Sync skipped
            Human->>Assistant: Archive without syncing
        end
    end
    Assistant->>Files: Move the change into the archive
    Assistant-->>Human: Report archive location and sync result

    Note over Human,CLI: CLI alternative: openspec archive change-name --yes skips confirmation prompts. It still validates, then applies any delta specs and archives

สองโหมด ​

เส้นทางด่วนเริ่มต้น (โปรไฟล์ core) ​

การติดตั้งใหม่จะใช้ค่าเริ่มต้นเป็น core ซึ่งให้:

  • /opsx:explore
  • /opsx:propose
  • /opsx:apply
  • /opsx:update
  • /opsx:sync
  • /opsx:archive

กระแสทั่วไป:

text
/opsx:explore ──► /opsx:propose ──► /opsx:apply ──► /opsx:sync ──► /opsx:archive
  (optional)

เริ่มต้นด้วยการสำรวจ (นิสัยที่ควรสร้าง) ​

/opsx:explore เป็นส่วนหนึ่งของโปรไฟล์เริ่มต้น ไม่ใช่ส่วนเสริมขั้นสูง เป็นการกระทำที่ควรทำเมื่อคุณมีปัญหาแต่ยังไม่มีแผน ซึ่งเมื่อทำงานร่วมกับผู้ช่วย AI ส่วนใหญ่แล้วจะเป็นเช่นนั้น

text
คุณ: /opsx:explore

AI:  คุณต้องการสำรวจอะไร?

คุณ: ผลการค้นหาของเราดูเก่า ฉันไม่แน่ใจว่าเป็นปัญหาแคช การจัดทำดัชนี หรือตัว query เอง

AI:  ให้ฉันดู... [อ่านบริการค้นหาและเลเยอร์แคช]
     มันเป็นดัชนี: มันสร้างใหม่เฉพาะตอนกลางคืน ดังนั้นการแก้ไขจึงไม่แสดงจนกว่าจะถึงวันถัดไป มีสองทางเลือก: สร้างใหม่เมื่อเขียน (ง่าย แต่โหลดมากขึ้น) หรือการทำให้แคช失效ด้วย TTL สั้น (มีส่วนที่เคลื่อนไหวมากขึ้น แต่โหลดน้อยลง) เนื่องจากปริมาณการเขียนของคุณต่ำ การสร้างใหม่เมื่อเขียนจึงเป็นวิธีที่สะอาดกว่า ต้องการกำหนดขอบเขตไหม?

คุณ: ใช่

คุณ: /opsx:propose rebuild-search-index-on-write

การสำรวจไม่สร้างอาร์ติแฟกต์และไม่เขียนโค้ด เป็นบทสนทนาที่ไม่มีค่าใช้จ่ายและไม่มีความเสี่ยง ซึ่งเปลี่ยนความกังวลที่คลุมเครือให้เป็นการเปลี่ยนแปลงที่แม่นยำ ดังนั้นข้อเสนอที่ตามมาจะคมชัด หากคุณรู้ชัดเจนแล้วว่าต้องการอะไร? ข้ามไปที่ /opsx:propose ได้เลย คู่มือฉบับเต็ม: สำรวจก่อน

เวิร์กโฟลว์แบบขยาย/เต็มรูปแบบ (การเลือกแบบกำหนดเอง) ​

หากคุณต้องการคำสั่งการวางโครงสร้างและการสร้างที่ชัดเจน (/opsx:new, /opsx:continue, /opsx:ff, /opsx:verify, /opsx:bulk-archive, /opsx:onboard) ให้เปิดใช้งานด้วย:

bash
openspec config profile
openspec update

รูปแบบเวิร์กโฟลว์ (โหมดขยาย) ​

ฟีเจอร์ด่วน ​

เมื่อคุณรู้ว่าต้องการสร้างอะไรและเพียงแค่ต้องดำเนินการ:

text
/opsx:new ──► /opsx:ff ──► /opsx:apply ──► /opsx:verify ──► /opsx:archive

ตัวอย่างบทสนทนา:

text
คุณ: /opsx:new add-logout-button

AI:  สร้าง openspec/changes/add-logout-button/
     พร้อมสร้าง: proposal

คุณ: /opsx:ff

AI:  กำลังสร้างอาร์ติแฟกต์การวางแผนทั้งหมด...
     ✓ proposal.md
     ✓ specs/
     ✓ design.md
     ✓ tasks.md
     พร้อมสำหรับการนำไปใช้!

คุณ: /opsx:apply

AI:  กำลังทำงานตามงาน...
     ✓ เพิ่มปุ่มออกจากระบบในส่วนหัว
     ✓ ใช้การล้างเซสชัน
     ✓ เพิ่มกล่องโต้ตอบยืนยัน
     งานทั้งหมดเสร็จสมบูรณ์!

คุณ: /opsx:archive

AI:  ✓ รวม specs
     ✓ เก็บถาวรการเปลี่ยนแปลง

เหมาะสมที่สุดสำหรับ: ฟีเจอร์ขนาดเล็กถึงขนาดกลาง การแก้ไขข้อบกพร่อง การเปลี่ยนแปลงที่ตรงไปตรงมา

การสำรวจ ​

เมื่อข้อกำหนดไม่ชัดเจนหรือคุณจำเป็นต้องตรวจสอบก่อน:

text
/opsx:explore ──► /opsx:new ──► /opsx:continue ──► ... ──► /opsx:apply

ตัวอย่างบทสนทนา:

text
คุณ: /opsx:explore

AI:  คุณต้องการสำรวจอะไร?

คุณ: ฉันต้องการปรับปรุงประสิทธิภาพการโหลดหน้า แต่ไม่แน่ใจว่าปัญหาอยู่ที่ไหน

AI:  ให้ฉันช่วยตรวจสอบ...
     [วิเคราะห์ขนาด bundle ระบุ query ที่ช้า ตรวจสอบรูปแบบการ render ของ component]

     ฉันพบปัญหาหลักสามจุด:
     1. รูปภาพขนาดใหญ่ที่ไม่ได้ปรับให้เหมาะสม
     2. การดึงข้อมูลแบบซิงโครนัสใน ProductList
     3. การ re-render จากการเปลี่ยนแปลง context

     คุณต้องการจัดการกับปัญหาใดก่อน?

คุณ: มาจัดการกับปัญหาการดึงข้อมูลกัน

คุณ: /opsx:new optimize-product-list-fetching

AI:  สร้างการเปลี่ยนแปลงแล้ว พร้อมสร้าง: proposal

คุณ: /opsx:continue

AI:  กำลังสร้าง proposal จากการสำรวจของเรา...
     [เขียน proposal รวมข้อมูลเชิงลึกจากการตรวจสอบ]

     พร้อมสร้าง: specs, design
     คุณต้องการอันไหนต่อไป?

คุณ: /opsx:continue

AI:  กำลังสร้าง specs...

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

การเปลี่ยนแปลงแบบขนาน ​

ทำงานกับการเปลี่ยนแปลงหลายรายการพร้อมกัน:

text
Change A: /opsx:new ──► /opsx:ff ──► /opsx:apply (in progress)
                                         │
                                    context switch
                                         │
Change B: /opsx:new ──► /opsx:ff ──────► /opsx:apply

ตัวอย่างบทสนทนา:

text
คุณ: ฉันกำลังทำงานกับ add-dark-mode แต่ถูกดึงไปแก้บั๊ก

คุณ: /opsx:new fix-login-redirect

AI:  สร้าง openspec/changes/fix-login-redirect/

คุณ: /opsx:ff

AI:  ✓ สร้างอาร์ติแฟกต์การวางแผน

คุณ: /opsx:apply

AI:  กำลังทำงานกับ fix-login-redirect...
     [ดำเนินการแก้ไข]
     งานทั้งหมดเสร็จสมบูรณ์!

คุณ: /opsx:archive

AI:  ✓ เก็บถาวร fix-login-redirect

คุณ: กลับไปที่ dark mode กัน

คุณ: /opsx:apply add-dark-mode

AI:  ดำเนินการต่อ add-dark-mode...
     เริ่มจากงาน 2.3: อัปเดต Header...

เหมาะสมที่สุดสำหรับ: สตรีมงานแบบขนาน การขัดจังหวะเร่งด่วน การทำงานร่วมกันในทีม

เมื่อคุณมีการเปลี่ยนแปลงที่เสร็จสมบูรณ์หลายรายการ ให้ใช้ /opsx:bulk-archive:

text
คุณ: /opsx:bulk-archive

AI:  พบการเปลี่ยนแปลงที่เสร็จสมบูรณ์ 3 รายการ:
     - add-dark-mode (งานทั้งหมดเสร็จ)
     - fix-login-redirect (งานทั้งหมดเสร็จ)
     - update-footer (งานทั้งหมดเสร็จ)

     กำลังตรวจสอบความขัดแย้งของ spec...
     ⚠ add-dark-mode และ update-footer แตะต้อง specs/ui/ ทั้งคู่

     กำลังตรวจสอบ codebase เพื่อแก้ไข...
     การเปลี่ยนแปลงทั้งสองถูกนำไปใช้แล้ว จะใช้ตามลำดับเวลา

     เก็บถาวรทั้ง 3 การเปลี่ยนแปลงหรือไม่?

คุณ: ใช่

AI:  ✓ เก็บถาวร add-dark-mode
     ✓ เก็บถาวร fix-login-redirect
     ✓ เก็บถาวร update-footer
     รวม specs ตามลำดับ: add-dark-mode → update-footer

การเก็บถาวรแบบกลุ่มจะตรวจจับเมื่อการเปลี่ยนแปลงหลายรายการแตะต้อง spec เดียวกันและแก้ไขความขัดแย้งโดยตรวจสอบสิ่งที่ถูกนำไปใช้จริง

การทำให้การเปลี่ยนแปลงเสร็จสมบูรณ์ ​

กระแสการเสร็จสมบูรณ์ที่แนะนำ:

text
/opsx:apply ──► /opsx:verify ──► /opsx:archive
                    │                 │
              validates          prompts to sync
              implementation     if needed

ตรวจสอบ: ตรวจสอบงานของคุณ ​

/opsx:verify ตรวจสอบการนำไปใช้กับอาร์ติแฟกต์ของคุณในสามมิติ:

text
คุณ: /opsx:verify

AI:  กำลังตรวจสอบ add-auth...

     ความครบถ้วน
     ✓ งานทั้งหมด 12 งานใน tasks.md ถูกทำเครื่องหมาย
     ✓ ข้อกำหนดทั้งหมดใน specs มีโค้ดที่สอดคล้อง
     ⚠ ไม่ได้ทดสอบสถานการณ์ "หมดเวลาเซสชันหลังไม่มีการใช้งาน"

     ความถูกต้อง
     ✓ การนำไปใช้ตรงกับเจตนาของ spec
     ✓ จัดการกรณีขอบจากสถานการณ์แล้ว
     ✓ สถานะข้อผิดพลาดตรงกับคำจำกัดความใน spec

     ความสอดคล้อง
     ✓ การตัดสินใจในการออกแบบสะท้อนในโครงสร้างโค้ด
     ✓ หลักการตั้งชื่อสอดคล้องกับ design.md
     ⚠ การออกแบบกล่าวถึง "event-driven" แต่การนำไปใช้ใช้ polling

     สรุป
     ─────────────────────────────
     ปัญหาสำคัญ: 0
     คำเตือน: 2
     พร้อมเก็บถาวร: ใช่ (พร้อมคำเตือน)

     คำแนะนำ:
     1. เพิ่มการทดสอบสำหรับสถานการณ์หมดเวลาเซสชัน
     2. พิจารณาปรับโครงสร้างเป็น event-driven ตามที่ออกแบบ หรืออัปเดต design.md

สิ่งที่ตรวจสอบตรวจสอบ:

มิติสิ่งที่ตรวจสอบ
ความครบถ้วนงานทั้งหมดเสร็จ ข้อกำหนดทั้งหมดถูกนำไปใช้ สถานการณ์ครอบคลุม
ความถูกต้องการนำไปใช้ตรงกับเจตนาของ spec จัดการกรณีขอบ
ความสอดคล้องการตัดสินใจในการออกแบบสะท้อนในโค้ด รูปแบบสอดคล้อง

การตรวจสอบจะไม่บล็อกการเก็บถาวร แต่จะแสดงปัญหาที่คุณอาจต้องการจัดการก่อน

เก็บถาวร: ทำให้การเปลี่ยนแปลงเสร็จสิ้น ​

/opsx:archive เสร็จสิ้นการเปลี่ยนแปลงและย้ายไปยังที่เก็บถาวร:

text
คุณ: /opsx:archive

AI:  กำลังเก็บถาวร add-auth...

     สถานะอาร์ติแฟกต์:
     ✓ proposal.md มีอยู่
     ✓ specs/ มีอยู่
     ✓ design.md มีอยู่
     ✓ tasks.md มีอยู่ (งาน 12/12 เสร็จสมบูรณ์)

     Delta specs: ยังไม่ได้ซิงค์กับ main
     → คุณต้องการซิงค์ตอนนี้หรือไม่?

คุณ: ใช่

AI:  ✓ ซิงค์ specs ไปยัง openspec/specs/auth/spec.md
     ✓ ย้ายไปยัง openspec/changes/archive/2025-01-24-add-auth/

     การเปลี่ยนแปลงถูกเก็บถาวรเรียบร้อยแล้ว

การเก็บถาวรจะแจ้งเตือนหาก specs ยังไม่ได้ซิงค์ มันจะไม่บล็อกงานที่ไม่สมบูรณ์ แต่จะเตือนคุณ

เมื่อใดควรใช้อะไร ​

/opsx:ff กับ /opsx:continue ​

สถานการณ์ใช้
ข้อกำหนดชัดเจน พร้อมสร้าง/opsx:ff
กำลังสำรวจ ต้องการตรวจสอบแต่ละขั้นตอน/opsx:continue
ต้องการปรับปรุง proposal ก่อน specs/opsx:continue
กดดันเรื่องเวลา ต้องการเคลื่อนที่เร็ว/opsx:ff
การเปลี่ยนแปลงที่ซับซ้อน ต้องการควบคุม/opsx:continue

กฎง่าย ๆ: หากคุณสามารถอธิบายขอบเขตทั้งหมดล่วงหน้าได้ ใช้ /opsx:ff หากคุณกำลังค้นพบระหว่างทาง ใช้ /opsx:continue

เมื่อใดควรอัปเดตกับเริ่มใหม่ ​

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

อัปเดตการเปลี่ยนแปลงที่มีอยู่เมื่อ:

  • เจตนาเดียวกัน การดำเนินการที่ปรับปรุงแล้ว
  • ขอบเขตแคบลง (MVP ก่อน ที่เหลือทีหลัง)
  • การแก้ไขที่ขับเคลื่อนด้วยการเรียนรู้ (codebase ไม่ตรงกับที่คาดหวัง)
  • การปรับการออกแบบตามการค้นพบจากการนำไปใช้

เริ่มการเปลี่ยนแปลงใหม่เมื่อ:

  • เจตนาเปลี่ยนไปอย่างพื้นฐาน
  • ขอบเขตขยายไปเป็นงานที่แตกต่างอย่างสิ้นเชิง
  • การเปลี่ยนแปลงเดิมสามารถทำเครื่องหมาย "เสร็จ" ได้อย่างอิสระ
  • การแก้ไขเพิ่มเติมจะทำให้สับสนมากกว่าชัดเจน
text
                     ┌─────────────────────────────────────┐
                     │     งานเดียวกันหรือไม่?              │
                     └──────────────┬──────────────────────┘
                                    │
                 ┌──────────────────┼──────────────────┐
                 │                  │                  │
                 ▼                  ▼                  ▼
          เจตนาเดียวกัน?    ทับซ้อน > 50%?    การเปลี่ยนแปลงเดิม
          ปัญหาเดียวกัน?    ขอบเขตเดียวกัน?   เสร็จได้โดยไม่ต้อง
                 │                  │          เปลี่ยนแปลงเหล่านี้?
                 │                  │                  │
       ┌────────┴────────┐  ┌──────┴──────┐   ┌───────┴───────┐
       │                 │  │             │   │               │
      ใช่                ไม่ ใช่          ไม่  ไม่              ใช่
       │                 │  │             │   │               │
       ▼                 ▼  ▼             ▼   ▼               ▼
    อัปเดต            ใหม่ อัปเดต       ใหม่ อัปเดต          ใหม่

ตัวอย่าง: "เพิ่มโหมดมืด"

  • "ต้องรองรับธีมที่กำหนดเองด้วย" → การเปลี่ยนแปลงใหม่ (ขอบเขตขยาย)
  • "การตรวจจับการตั้งค่าระบบยากกว่าที่คาด" → อัปเดต (เจตนาเดียวกัน)
  • "ส่ง toggle ก่อน แล้วค่อยเพิ่มการตั้งค่า" → อัปเดตแล้วเก็บถาวร แล้วสร้างการเปลี่ยนแปลงใหม่

แนวปฏิบัติที่ดีที่สุด ​

ทำให้การเปลี่ยนแปลงมีจุดเน้น ​

หนึ่งหน่วยงานเชิงตรรกะต่อการเปลี่ยนแปลงหนึ่งครั้ง หากคุณกำลังทำ "เพิ่มคุณสมบัติ X และยังปรับโครงสร้าง Y" ให้พิจารณาแยกเป็นการเปลี่ยนแปลงสองครั้ง

เหตุผลที่สำคัญ:

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

ใช้ /opsx:explore สำหรับข้อกำหนดที่ไม่ชัดเจน ​

ก่อนที่จะมุ่งมั่นกับการเปลี่ยนแปลง ให้สำรวจพื้นที่ปัญหาก่อน:

text
You: /opsx:explore

AI:  What would you like to explore?

You: How should we handle rate limiting for our API?

AI:  Let me investigate your current setup and options...
     [Researches codebase, considers patterns]

     I see three approaches we could take:
     1. Middleware-based (simple, per-endpoint)
     2. Redis-backed (scalable, shared state)
     3. Token bucket per user (fair, complex)

     Your current stack suggests #1 or #2. What's your scale?

การสำรวจช่วยให้ความคิดชัดเจนก่อนที่คุณจะสร้าง artifacts

ตรวจสอบก่อนเก็บถาวร ​

ใช้ /opsx:verify เพื่อตรวจสอบว่าการใช้งานตรงกับ artifacts:

text
You: /opsx:verify

AI:  Verifying add-dark-mode...

     ✓ All tasks in tasks.md are checked
     ✓ Requirements in specs have corresponding code
     ✓ Design decisions are reflected in implementation

     Ready to archive!

จับความไม่ตรงกันได้ก่อนที่คุณจะปิดการเปลี่ยนแปลง

ตั้งชื่อการเปลี่ยนแปลงให้ชัดเจน ​

ชื่อที่ดีทำให้ openspec list มีประโยชน์:

text
Good:                          Avoid:
add-dark-mode                  feature-1
fix-login-redirect             update
optimize-product-query         changes
implement-2fa                  wip

อ้างอิงคำสั่งอย่างย่อ ​

สำหรับรายละเอียดและตัวเลือกคำสั่งทั้งหมด ดูที่ Commands

CommandPurposeWhen to Use
/opsx:proposeสร้างการเปลี่ยนแปลง + วางแผน artifactsเส้นทางเริ่มต้นที่รวดเร็ว (core profile)
/opsx:exploreคิดผ่านไอเดียกับ AIเริ่มที่นี่เมื่อไม่แน่ใจ: ข้อกำหนดไม่ชัดเจน, การสืบสวน, การเปรียบเทียบตัวเลือก
/opsx:newเริ่มโครงสร้างการเปลี่ยนแปลงโหมดขยาย, ควบคุม artifacts อย่างชัดเจน
/opsx:continueสร้าง artifact ถัดไปโหมดขยาย, สร้าง artifacts ทีละขั้นตอน
/opsx:ffสร้าง artifacts การวางแผนทั้งหมดโหมดขยาย, ขอบเขตชัดเจน
/opsx:applyปฏิบัติงานพร้อมที่จะเขียนโค้ด
/opsx:verifyตรวจสอบการใช้งานโหมดขยาย, ก่อนเก็บถาวร
/opsx:syncรวม delta specsโหมดขยาย, ไม่บังคับ
/opsx:archiveเสร็จสิ้นการเปลี่ยนแปลงงานทั้งหมดเสร็จสิ้น
/opsx:bulk-archiveเก็บถาวรการเปลี่ยนแปลงหลายรายการโหมดขยาย, ทำงานขนาน

ขั้นตอนถัดไป ​