Test deltas alongside spec deltas

[Patodo]

I have already implemented test deltas with a custom schema. For every delta spec.md, the schema creates a matching test.md in the same capability directory:

openspec/changes/<change>/specs/<capability>/
├── spec.md
└── test.md

The relevant part of the schema looks like this:

- id: specs
  generates: specs/**/spec.md

- id: test-plan
  generates: specs/**/test.md
  requires:
    - specs

test.md mirrors the delta, requirement, and scenario headings from spec.md. Instead of repeating the scenario description, it records the corresponding test-code changes.

For example:

<!-- spec.md -->

## ADDED Requirements

### Requirement: CSV export

#### Scenario: Export a report as CSV

- **WHEN** the user exports a report as CSV
- **THEN** the downloaded file contains the report data

## REMOVED Requirements

### Requirement: XML export

#### Scenario: Export a report as XML

- **WHEN** the user exports a report as XML
- **THEN** an XML file is generated

<!-- test.md -->

## ADDED Requirements

### Requirement: CSV export

#### Scenario: Export a report as CSV

- [ADD] Add `exports a report as CSV` to `tests/report-export.test.ts`.
- [ADD] Verify the generated headers and rows.

## REMOVED Requirements

### Requirement: XML export

#### Scenario: Export a report as XML

- [REMOVE] Delete `exports a report as XML`.
- [REMOVE] Delete XML-only fixtures.

For a removed scenario, the test delta removes the old tests. It does not add a permanent negative test whose only purpose is to prove that the removed behavior or code no longer exists.

This works in my custom schema, but I am not sure whether it matches OpenSpec’s intended design.

The concepts documentation defines artifacts as documents within a change. At the same time, the specs/ subtree has special meaning: it contains delta specs that are parsed and merged into the main openspec/specs/ source of truth during sync or archive.

That makes the boundary unclear:

• Is changes/<change>/specs/ intended to be an extensible artifact space?
• Is using generates: specs/**/test.md an intended custom-schema use case?
• Can different schema artifacts own different file patterns inside specs/?
• Can a schema declare that spec.md is synced while test.md is only preserved with the archived change?
• Or should non-spec companion artifacts always live outside specs/, even when they map one-to-one to its requirements and scenarios?

I am trying to understand whether custom schemas are expected to support companion deltas alongside spec deltas, or whether specs/ is deliberately reserved for OpenSpec’s built-in specification model.

This seems related to #666 and #829, but the narrower question here is whether specs/ is intended to be a schema-managed artifact space.