Why
specfact init and specfact init ide currently mutate user-owned project artifacts such as .vscode/settings.json without a first-class safety contract. Issue #487 showed that a setup run can wipe unrelated local configuration, forcing manual restore and repair. That is unacceptable for any tool writing into customer repositories.
What Changes
- introduce a core safe-write policy for project artifacts with declared ownership and mutation modes (
create_only, merge_structured, append_managed_block, explicit_replace)
- route init/setup file mutations through a shared helper instead of ad hoc overwrite logic
- preserve unrelated user configuration in partial-ownership files such as
.vscode/settings.json
- require backup/recovery metadata for lossy replacement paths
- add CI/static coverage that flags unsafe raw writes to protected user-project artifacts
- add regression fixtures proving existing user config survives init/setup flows
- coordinate paired runtime adoption in
specfact-cli-modules
Acceptance Criteria
Dependencies
Related Issues/PRs
Additional Context
This is intended as a prevention-by-design change, not a point fix for a single symptom.
OpenSpec Change Proposal: profile-04-safe-project-artifact-writes
Why
specfact initandspecfact init idecurrently mutate user-owned project artifacts such as.vscode/settings.jsonwithout a first-class safety contract. Issue #487 showed that a setup run can wipe unrelated local configuration, forcing manual restore and repair. That is unacceptable for any tool writing into customer repositories.What Changes
create_only,merge_structured,append_managed_block,explicit_replace).vscode/settings.jsonspecfact-cli-modulesAcceptance Criteria
.vscode/settings.jsonmerges only SpecFact-managed entries and preserves unrelated settingsDependencies
project-runtime-01-safe-artifact-write-policyRelated Issues/PRs
Additional Context
This is intended as a prevention-by-design change, not a point fix for a single symptom.
OpenSpec Change Proposal:
profile-04-safe-project-artifact-writes