Skip to content

Conversation

@TabishB
Copy link
Contributor

@TabishB TabishB commented Jan 13, 2026

Summary

Adds a comprehensive guide addressing the silent data loss issue when multiple feature branches modify the same requirements during batch archiving workflows.

This guide provides:

  • Clear explanation of the requirement-level replacement issue with visual diagrams
  • Practical best practices for teams using weekly batch archiving
  • Archive ordering strategies to minimize conflicts
  • CodeRabbit configuration recommendations
  • OPSX workflow as a safer alternative
  • Roadmap context for upcoming Phase 1-3 improvements

Context

This documentation responds to a user question about best practices for managing concurrent changes that touch the same specifications. The issue is documented in openspec-parallel-merge-plan.md but wasn't easily discoverable for teams experiencing the problem.

Target Audience

Teams experiencing or concerned about:

  • Weekly batch archiving of multiple feature branches
  • Overlapping changes to the same capability/requirement
  • Code review tools (like CodeRabbit) not understanding OpenSpec semantics

Changes

  • New file: docs/versioning-and-archiving-guide.md
  • Includes ASCII diagrams for visual clarity
  • Links to existing technical documentation and roadmap
  • Provides actionable checklists and quick reference cards

Test Plan

  • Documentation renders correctly in markdown
  • Links to other docs are valid (relative paths)
  • ASCII diagrams display properly
  • Recommendations align with openspec-parallel-merge-plan.md

🤖 Generated with Claude Code

Summary by CodeRabbit

  • Documentation
    • Added a comprehensive versioning and archiving guide covering silent data-loss risks, recommended workflows, and conflict mitigation.
    • Describes an AI-driven merging workflow with quick-start steps, options (batch vs. sync-as-you-go), safety checks, and concrete multi-team merge examples.
    • Includes remediation guidance and manual strategies when the automated workflow cannot be used, plus a quick reference card and resources.

✏️ Tip: You can customize this high-level summary in your review settings.

Add comprehensive guide covering:
- Silent data loss issue when multiple branches modify same requirements
- Best practices for batch archiving workflow
- Archive ordering strategies to prevent conflicts
- CodeRabbit configuration recommendations
- OPSX workflow as safer alternative
- Roadmap for upcoming conflict resolution features

Addresses common pain points teams encounter with parallel development
and weekly batch archiving workflows.
@coderabbitai
Copy link
Contributor

coderabbitai bot commented Jan 13, 2026

📝 Walkthrough

Walkthrough

Adds a new documentation guide explaining OpenSpec versioning and archiving challenges, the OPSX AI-driven merging workflow, setup and usage instructions, workflow comparisons, examples, and remediation guidance for non-OPSX environments.

Changes

Cohort / File(s) Summary
Documentation: Versioning & Archiving Guide
docs/versioning-and-archiving-guide.md
New comprehensive guide describing OpenSpec versioning problems (silent data loss), OPSX AI-driven merging workflow, quick-start setup, workflow options (Friday batch vs sync-as-you-go), concrete multi-team merge examples, safety checks, remediation strategies, and a quick-reference card.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Possibly related PRs

Poem

🐰 I hop through branches, tidy and bright,
Folding lost lines back into the light.
I merge with a nibble, check twice by paw,
Guide in my pocket, no silent flaw.
thump 📜✨

🚥 Pre-merge checks | ✅ 3
✅ Passed checks (3 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title directly and accurately summarizes the main change: adding a new documentation guide about versioning and archiving best practices.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.


🧹 Recent nitpick comments
docs/versioning-and-archiving-guide.md (2)

103-103: Convert bold emphasis to proper heading.

This line uses bold emphasis instead of a heading tag. For better document structure and accessibility, use a proper heading level.

♻️ Proposed fix
-**Option 1: Friday Batch (Keeps Your Current Rhythm)**
+#### Option 1: Friday Batch (Keeps Your Current Rhythm)

129-129: Convert bold emphasis to proper heading.

Same issue as line 103 - use a proper heading tag instead of bold emphasis.

♻️ Proposed fix
-**Option 2: Sync-as-you-go (Even Safer)**
+#### Option 2: Sync-as-you-go (Even Safer)
📜 Recent review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 33d8b9d and e5cd35a.

📒 Files selected for processing (1)
  • docs/versioning-and-archiving-guide.md
🧰 Additional context used
🧠 Learnings (7)
📓 Common learnings
Learnt from: CR
Repo: Fission-AI/OpenSpec PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-11-25T01:08:02.839Z
Learning: Use `@/openspec/AGENTS.md` to learn how to create and apply change proposals, spec format and conventions, and project structure and guidelines
📚 Learning: 2025-11-25T01:08:02.839Z
Learnt from: CR
Repo: Fission-AI/OpenSpec PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-11-25T01:08:02.839Z
Learning: Use `@/openspec/AGENTS.md` to learn how to create and apply change proposals, spec format and conventions, and project structure and guidelines

Applied to files:

  • docs/versioning-and-archiving-guide.md
📚 Learning: 2025-11-25T01:08:19.004Z
Learnt from: CR
Repo: Fission-AI/OpenSpec PR: 0
File: openspec/AGENTS.md:0-0
Timestamp: 2025-11-25T01:08:19.004Z
Learning: Applies to openspec/changes/**/specs/**/spec.md : Use `## ADDED Requirements` for new orthogonal capabilities that can stand alone; use `## MODIFIED Requirements` for behavior changes of existing requirements

Applied to files:

  • docs/versioning-and-archiving-guide.md
📚 Learning: 2025-11-25T01:08:19.004Z
Learnt from: CR
Repo: Fission-AI/OpenSpec PR: 0
File: openspec/AGENTS.md:0-0
Timestamp: 2025-11-25T01:08:19.004Z
Learning: Create `design.md` only when needed: cross-cutting changes, new external dependencies, significant data model changes, security/performance complexity, or pre-coding ambiguity

Applied to files:

  • docs/versioning-and-archiving-guide.md
📚 Learning: 2025-11-25T01:08:02.839Z
Learnt from: CR
Repo: Fission-AI/OpenSpec PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-11-25T01:08:02.839Z
Learning: Always open `@/openspec/AGENTS.md` when the request mentions planning or proposals (words like proposal, spec, change, plan), introduces new capabilities, breaking changes, architecture shifts, or performance/security work, or sounds ambiguous and needs the authoritative spec before coding

Applied to files:

  • docs/versioning-and-archiving-guide.md
📚 Learning: 2025-11-25T01:08:19.004Z
Learnt from: CR
Repo: Fission-AI/OpenSpec PR: 0
File: openspec/AGENTS.md:0-0
Timestamp: 2025-11-25T01:08:19.004Z
Learning: Use `openspec archive <change-id> --skip-specs --yes` for tooling-only changes

Applied to files:

  • docs/versioning-and-archiving-guide.md
📚 Learning: 2025-11-25T01:08:19.004Z
Learnt from: CR
Repo: Fission-AI/OpenSpec PR: 0
File: openspec/AGENTS.md:0-0
Timestamp: 2025-11-25T01:08:19.004Z
Learning: Check `openspec/project.md` for project conventions before creating specs

Applied to files:

  • docs/versioning-and-archiving-guide.md
🪛 markdownlint-cli2 (0.18.1)
docs/versioning-and-archiving-guide.md

9-9: Fenced code blocks should have a language specified

(MD040, fenced-code-language)


34-34: Fenced code blocks should have a language specified

(MD040, fenced-code-language)


57-57: Fenced code blocks should have a language specified

(MD040, fenced-code-language)


73-73: Fenced code blocks should have a language specified

(MD040, fenced-code-language)


103-103: Emphasis used instead of a heading

(MD036, no-emphasis-as-heading)


105-105: Fenced code blocks should have a language specified

(MD040, fenced-code-language)


129-129: Emphasis used instead of a heading

(MD036, no-emphasis-as-heading)


131-131: Fenced code blocks should have a language specified

(MD040, fenced-code-language)


155-155: Fenced code blocks should have a language specified

(MD040, fenced-code-language)


185-185: Fenced code blocks should have a language specified

(MD040, fenced-code-language)


199-199: Fenced code blocks should have a language specified

(MD040, fenced-code-language)


209-209: Fenced code blocks should have a language specified

(MD040, fenced-code-language)


249-249: Fenced code blocks should have a language specified

(MD040, fenced-code-language)


278-278: Fenced code blocks should have a language specified

(MD040, fenced-code-language)


293-293: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

🔇 Additional comments (3)
docs/versioning-and-archiving-guide.md (3)

73-97: Excellent example demonstrating the OPSX solution.

The authentication conflict scenario clearly shows how OPSX preserves changes from both branches, contrasting well with the problem statement in lines 9-28.


1-329: Well-structured and comprehensive guide.

The document effectively explains a complex problem with clear diagrams, provides a modern solution (OPSX), includes practical examples, offers manual fallbacks, and delivers actionable next steps. The flow from problem to solution to action plan is logical and user-friendly.


180-180: No issues found.

The openspec artifact-experimental-setup command is valid and exists in the codebase. It's implemented in src/commands/artifact-workflow.ts, properly registered in the CLI, and correctly documented. The related OPSX workflow commands (/opsx:sync, /opsx:archive, /opsx:new, /opsx:ff, /opsx:apply, /opsx:explore) are all defined with specifications.


Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

🧹 Nitpick comments (1)
docs/versioning-and-archiving-guide.md (1)

91-91: Consider using a heading instead of bold text.

For better document structure and accessibility, convert the bold text to a level 3 heading.

📝 Proposed fix
-**Recommendation: Exclude spec files**
+### Recommendation: Exclude spec files
📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 36078b1 and 33d8b9d.

📒 Files selected for processing (1)
  • docs/versioning-and-archiving-guide.md
🧰 Additional context used
🧠 Learnings (10)
📓 Common learnings
Learnt from: CR
Repo: Fission-AI/OpenSpec PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-11-25T01:08:02.839Z
Learning: Use `@/openspec/AGENTS.md` to learn how to create and apply change proposals, spec format and conventions, and project structure and guidelines
Learnt from: CR
Repo: Fission-AI/OpenSpec PR: 0
File: openspec/AGENTS.md:0-0
Timestamp: 2025-11-25T01:08:19.004Z
Learning: Applies to openspec/changes/*/proposal.md : Ensure `proposal.md` includes sections: Why (1-2 sentences), What Changes (bullet list with breaking change markers), and Impact (affected specs and code)
Learnt from: CR
Repo: Fission-AI/OpenSpec PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-11-25T01:08:02.839Z
Learning: Always open `@/openspec/AGENTS.md` when the request mentions planning or proposals (words like proposal, spec, change, plan), introduces new capabilities, breaking changes, architecture shifts, or performance/security work, or sounds ambiguous and needs the authoritative spec before coding
Learnt from: CR
Repo: Fission-AI/OpenSpec PR: 0
File: openspec/AGENTS.md:0-0
Timestamp: 2025-11-25T01:08:19.004Z
Learning: Check `openspec/project.md` for project conventions before creating specs
📚 Learning: 2025-11-25T01:08:02.839Z
Learnt from: CR
Repo: Fission-AI/OpenSpec PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-11-25T01:08:02.839Z
Learning: Use `@/openspec/AGENTS.md` to learn how to create and apply change proposals, spec format and conventions, and project structure and guidelines

Applied to files:

  • docs/versioning-and-archiving-guide.md
📚 Learning: 2025-11-25T01:08:19.004Z
Learnt from: CR
Repo: Fission-AI/OpenSpec PR: 0
File: openspec/AGENTS.md:0-0
Timestamp: 2025-11-25T01:08:19.004Z
Learning: Applies to openspec/changes/*/proposal.md : Ensure `proposal.md` includes sections: Why (1-2 sentences), What Changes (bullet list with breaking change markers), and Impact (affected specs and code)

Applied to files:

  • docs/versioning-and-archiving-guide.md
📚 Learning: 2025-11-25T01:08:19.004Z
Learnt from: CR
Repo: Fission-AI/OpenSpec PR: 0
File: openspec/AGENTS.md:0-0
Timestamp: 2025-11-25T01:08:19.004Z
Learning: Use `openspec archive <change-id> --skip-specs --yes` for tooling-only changes

Applied to files:

  • docs/versioning-and-archiving-guide.md
📚 Learning: 2025-11-25T01:08:02.839Z
Learnt from: CR
Repo: Fission-AI/OpenSpec PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-11-25T01:08:02.839Z
Learning: Always open `@/openspec/AGENTS.md` when the request mentions planning or proposals (words like proposal, spec, change, plan), introduces new capabilities, breaking changes, architecture shifts, or performance/security work, or sounds ambiguous and needs the authoritative spec before coding

Applied to files:

  • docs/versioning-and-archiving-guide.md
📚 Learning: 2025-11-25T01:08:19.004Z
Learnt from: CR
Repo: Fission-AI/OpenSpec PR: 0
File: openspec/AGENTS.md:0-0
Timestamp: 2025-11-25T01:08:19.004Z
Learning: Create `design.md` only when needed: cross-cutting changes, new external dependencies, significant data model changes, security/performance complexity, or pre-coding ambiguity

Applied to files:

  • docs/versioning-and-archiving-guide.md
📚 Learning: 2025-11-25T01:08:19.004Z
Learnt from: CR
Repo: Fission-AI/OpenSpec PR: 0
File: openspec/AGENTS.md:0-0
Timestamp: 2025-11-25T01:08:19.004Z
Learning: Applies to openspec/changes/**/specs/**/spec.md : Use `## ADDED|MODIFIED|REMOVED|RENAMED Requirements` headers in spec delta files

Applied to files:

  • docs/versioning-and-archiving-guide.md
📚 Learning: 2025-11-25T01:08:19.004Z
Learnt from: CR
Repo: Fission-AI/OpenSpec PR: 0
File: openspec/AGENTS.md:0-0
Timestamp: 2025-11-25T01:08:19.004Z
Learning: Applies to openspec/changes/**/*.md : Scaffold proposal using `proposal.md`, `tasks.md`, optional `design.md`, and delta specs under `openspec/changes/<id>/`

Applied to files:

  • docs/versioning-and-archiving-guide.md
📚 Learning: 2025-11-25T01:08:19.004Z
Learnt from: CR
Repo: Fission-AI/OpenSpec PR: 0
File: openspec/AGENTS.md:0-0
Timestamp: 2025-11-25T01:08:19.004Z
Learning: Applies to openspec/changes/**/specs/**/spec.md : Use `## ADDED Requirements` for new orthogonal capabilities that can stand alone; use `## MODIFIED Requirements` for behavior changes of existing requirements

Applied to files:

  • docs/versioning-and-archiving-guide.md
📚 Learning: 2025-11-25T01:08:19.004Z
Learnt from: CR
Repo: Fission-AI/OpenSpec PR: 0
File: openspec/AGENTS.md:0-0
Timestamp: 2025-11-25T01:08:19.004Z
Learning: Check `openspec/project.md` for project conventions before creating specs

Applied to files:

  • docs/versioning-and-archiving-guide.md
🪛 markdownlint-cli2 (0.18.1)
docs/versioning-and-archiving-guide.md

7-7: Fenced code blocks should have a language specified

(MD040, fenced-code-language)


32-32: Fenced code blocks should have a language specified

(MD040, fenced-code-language)


61-61: Fenced code blocks should have a language specified

(MD040, fenced-code-language)


91-91: Emphasis used instead of a heading

(MD036, no-emphasis-as-heading)


111-111: Fenced code blocks should have a language specified

(MD040, fenced-code-language)


128-128: Fenced code blocks should have a language specified

(MD040, fenced-code-language)


148-148: Fenced code blocks should have a language specified

(MD040, fenced-code-language)


164-164: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

🔇 Additional comments (1)
docs/versioning-and-archiving-guide.md (1)

194-195: Linked documentation files are present and accessible.

Both referenced documentation files exist in the repository:

  • openspec-parallel-merge-plan.md exists at the repository root
  • docs/experimental-workflow.md exists in the docs directory

The relative links are correctly formed.

Significantly expanded the versioning/archiving guide to better
address user concerns about parallel development conflicts:

- Added TL;DR with jump link to solution
- Expanded OPSX section from 8 lines to ~120 lines
- Added step-by-step authentication conflict example
- Added three-team concrete example showing all merge scenarios
- Added two workflow options (Friday batch vs sync-as-you-go)
- Added "What cases does this handle" section
- Updated quick reference card to lead with OPSX
- Restructured flow: Problem → OPSX Solution → Manual fallback
- Moved manual practices to "If You Can't Use OPSX Yet" section

The guide now clearly positions OPSX as the solution with
actionable examples instead of being buried as a light mention.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants