Archived delta files duplicate spec content that git history already stores

Context

We manage a spec corpus with OpenSpec 1.13.1. The corpus now holds 263 specs, about 30k lines. The openspec/changes/archive/ folder holds 316 archived changes with 1,715 markdown files and about 93k lines.

The numbers

Part	Size
Live specs (openspec/specs/)	29,564 lines
Archived delta spec files (archive/*/specs/*/spec.md, 764 files)	49,005 lines
Archived proposals, designs, tasks	44,358 lines

The archived delta files alone hold more lines than the whole live corpus. After some months of normal use, the archive is about three times the size of the specs that it describes.

The problem

A delta file is a patch. After openspec archive applies the patch to the main specs, the delta has no further role:

1. The main spec holds the current truth.
2. Git history holds the timeline: what changed, when, and in which commit.

But the archive keeps the delta text forever. The same requirement bodies are then stored twice in git: once in the main-spec commit and once in the archive commit. Teams that commit openspec/ get pure duplication, and the duplication grows with every change.

This also costs tools and contributors. Analysis tools must skip archive/**, or they count every requirement twice. New contributors can mistake an archived delta for current truth.

The question

What is the intended long-term role of archived delta files? We see three policies:

1. Keep everything (current behavior). The archive grows without limit.
2. Prune delta spec files at archive time, and keep proposals, designs, and tasks as the durable record of intent and rationale. A flag like openspec archive --prune-deltas, or a config option, would do this.
3. Document a squash policy for teams whose openspec/ folder lives in git, so that teams delete old archives themselves.

Option 2 keeps the part that git cannot reconstruct (the why: proposals and designs) and drops the part that git already stores better (the what: requirement diffs). We think option 2 fits repos that commit openspec/ to git. Option 3 covers the rest.