31 lines
1.8 KiB
Markdown
31 lines
1.8 KiB
Markdown
# Proposal
|
|
|
|
## Why
|
|
|
|
The behavioral baseline is now archived, but OpenSpec configuration still contains only the default schema and commented examples. Future changes need concise, durable project constraints and artifact guidance without repeatedly reconstructing decisions from conversation history or duplicating the twelve specifications.
|
|
|
|
## What Changes
|
|
|
|
- Keep `schema: spec-driven` and the repository-local planning root.
|
|
- Add a short English `context` capturing documentation ownership, English UI/artifacts, browser compatibility, established presentation conventions and the Firefox XPI release expectation.
|
|
- Add focused `rules` for proposal, design, specs and tasks; keep implementation guidance in the supported `operations.apply` and `operations.archive` sections.
|
|
- Provide the exact proposed YAML in the design for review before replacing `openspec/config.yaml` during apply.
|
|
- Validate configuration parsing and instruction delivery without changing extension behavior.
|
|
|
|
## Capabilities
|
|
|
|
### New Capabilities
|
|
|
|
None. This change configures development tooling rather than introducing product behavior.
|
|
|
|
### Modified Capabilities
|
|
|
|
None. The twelve existing capabilities remain unchanged. This tooling-only change declares `skip_specs: true`; no delta specification is required or generated.
|
|
|
|
## Impact
|
|
|
|
- Implementation target: `openspec/config.yaml` only, plus this change's completion records.
|
|
- OpenSpec agents receive project context, per-artifact rules and advisory apply/archive guidance.
|
|
- No source, browser permissions, API contracts, storage data, generated distributions, dependencies, version numbers or release history change.
|
|
- Out of scope: new workflows/schemas, external stores, runtime changes, releasing a version, generating an XPI now, or automatically applying/archiving future changes.
|