OpenSpec Brownfield Baseline

Use this when a user wants to adopt OpenSpec in the middle of an existing software project and needs to create trustworthy baseline specs from the current implementation.

Goal

Create openspec/specs/ as a current-state source of truth for the parts of the system that matter now, without blindly canonizing accidental behavior, bugs, or implementation details. After the baseline exists, all future work should flow through openspec/changes/.

Core principles

• openspec/specs/ is the current source of truth for system behavior.
• Focus on behavior contracts, not internal implementation details.
• Reverse-engineered specs are drafts until reviewed by a human.
• Start with high-change or high-risk domains first; do not try to spec the whole repository unless explicitly asked.
• Prefer domain boundaries based on user-visible capabilities, not folder layout.

When to use this

• A project already has substantial implementation but no OpenSpec baseline.