fix(schema): make schema init --default actually set the default (#1709)

* fix(schema): make schema init --default actually set the default

--default wrote defaultSchema to openspec/config.yaml, but the config
loader only reads schema, so new changes kept using spec-driven while
the command reported success. Write the key that is read, and drop the
dead one a previous run may have left behind.

Fixes #1708

* fix(schema): preserve supported configs when setting default

* docs(schema): specify default config file handling

* docs(schema): protect default config migration

* fix(schema): make default initialization atomic

* fix(schema): hide init staging and backup dirs from discovery

`schema init` stages into `.init-staging-<rand>` and moves an existing
schema aside to `<name>.init-backup-<pid>-<ts>`, both inside the schemas
dir. `schema fork` already did this and the resolver filters its temp
names out of discovery; the init names were never added, so `listSchemas`
and `listSchemasWithInfo` surfaced them as real schemas -- in shell
completions, "available schemas" error lists, and change-metadata
validation.

The backup is the durable case: cleanup failure is deliberately tolerated
with a warning, so a blocked cleanup (or a crash mid-transaction) leaves a
permanent phantom schema behind.

Generalize the fork-only filter to cover both commands' staging and backup
names. Real schema names are kebab-case, so excluding these dot-bearing
names can never hide a legitimate schema.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

---------

Co-authored-by: Clay Good <hi@claygood.com>
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>

Author: 3 people

.changeset/quiet-schemas-rollback.md

@@ -0,0 +1,5 @@
+---
+"@fission-ai/openspec": patch
+---
+
+Make `schema init --default` validate and stage config changes before installing a schema, and roll back both files if either install fails. The staging and backup directories it creates are excluded from schema discovery, so they are never offered as real schemas.

docs-lab/Notes.md

@@ -76,10 +76,6 @@ the agent to consume it. Running `openspec update` should refresh them.
 
 Product issues found while verifying the schema system (all file refs current as of today):
 
-- `schema init --default` writes a `defaultSchema:` key to openspec/config.yaml that nothing
-  reads (schema.ts:961-978; readProjectConfig parses only schema/context/rules/operations/
-  references/store). The flag should write `schema:` or be removed. The docs now say to set
-  `schema:` by hand.
 - `schema init` next-steps output prints a command that doesn't exist in that form:
   "Use with: openspec new --schema <name>" (schema.ts:999); real syntax is
   `openspec new change <name> --schema <name>`.

docs-lab/reference/cli.md

@@ -1350,11 +1350,13 @@ With no `--description` and no `--artifacts` in an interactive terminal, init pr
 |---|---|
 | `--description <text>` | Schema description. Default: `Custom workflow schema for <name>`. |
 | `--artifacts <list>` | Comma-separated artifact IDs from `proposal`, `specs`, `design`, `tasks`. Default: all four. |
-| `--default` | Writes `defaultSchema` to `openspec/config.yaml`. Nothing reads that key. To make the schema the default, set `schema: <name>` there yourself. |
+| `--default` | Writes `schema: <name>` to the existing `openspec/config.yaml` or `openspec/config.yml`. Creates `openspec/config.yaml` if neither exists. New changes use this schema. |
 | `--no-default` | Skip the prompt about the default. |
 | `--force` | Overwrite an existing schema with the same name. |
 | `--json` | Print the result as JSON. |
 
+Schema creation and the `--default` config update are one operation. If OpenSpec cannot validate or write the config, it leaves both the config and any existing schema unchanged.
+
 **Output**
 
 ```

openspec/specs/schema-init-command/spec.md

@@ -50,16 +50,34 @@ The CLI SHALL offer to set the newly created schema as the project default.
 #### Scenario: Set as default interactively
 - **WHEN** user runs `openspec schema init my-workflow` in interactive mode
 - **AND** user confirms setting as default
-- **THEN** system updates `openspec/config.yaml` with `defaultSchema: my-workflow`
+- **THEN** system updates an existing `openspec/config.yaml` or `openspec/config.yml` in place with `schema: my-workflow`
+- **AND** removes the legacy `defaultSchema` key when updating an existing configuration
+- **AND** creates `openspec/config.yaml` when neither configuration file exists
 
 #### Scenario: Set as default via flag
 - **WHEN** user runs `openspec schema init my-workflow --default`
-- **THEN** system creates schema and updates `openspec/config.yaml` with `defaultSchema: my-workflow`
+- **THEN** system creates the schema and updates an existing `openspec/config.yaml` or `openspec/config.yml` in place with `schema: my-workflow`
+- **AND** removes the legacy `defaultSchema` key when updating an existing configuration
+- **AND** creates `openspec/config.yaml` when neither configuration file exists
 
 #### Scenario: Skip setting default
 - **WHEN** user runs `openspec schema init my-workflow --no-default`
 - **THEN** system creates schema without modifying `openspec/config.yaml`
 
+#### Scenario: Invalid config prevents schema creation
+- **GIVEN** `openspec/config.yaml` or `openspec/config.yml` is invalid YAML, is not a YAML object, is not a regular file, or is not writable
+- **WHEN** user runs `openspec schema init my-workflow --default`
+- **THEN** the command exits with a non-zero status
+- **AND** does not create `openspec/schemas/my-workflow/`
+- **AND** leaves the config byte-for-byte unchanged
+
+#### Scenario: Config failure preserves a schema during forced replacement
+- **GIVEN** `openspec/schemas/my-workflow/` already contains user-authored files
+- **AND** the project config cannot be validated or atomically replaced
+- **WHEN** user runs `openspec schema init my-workflow --force --default`
+- **THEN** the command exits with a non-zero status
+- **AND** restores the existing schema and config byte-for-byte
+
 ### Requirement: Schema init outputs JSON format
 The CLI SHALL support `--json` flag for machine-readable output.
 
@@ -92,4 +110,3 @@ The CLI SHALL validate all requested artifact IDs before replacing an existing p
 - **WHEN** the user runs `schema init` with `--force` and only valid artifact IDs
 - **THEN** the command replaces the existing schema with the newly generated schema
 - **AND** reports successful creation
-