Move workspace config from .opencode/openwork.json to .openwork/openwork.json with safe migration

[benjaminshafii]

Problem

OpenWork currently stores its workspace-specific config in .opencode/openwork.json.

That mixes OpenWork-owned state into the OpenCode config area and makes it too easy for workspace template/export logic to accidentally treat OpenWork runtime/config state as generic .opencode content.

We should move OpenWork's primary workspace config location to .openwork/openwork.json and make that the canonical path going forward.

Core requirement

We need a very strong guarantee that this does not mess up existing users.

That means the migration work cannot just change the read/write path and hope for the best. We need an explicit compatibility and migration strategy.

Proposed direction

• Make .openwork/openwork.json the canonical OpenWork workspace config path.
• Continue reading the legacy .opencode/openwork.json during a compatibility window.
• Add a migration command / migration path that copies existing config forward safely.
• Prefer copy-then-verify over move/delete for the initial migration flow.
• Avoid destroying or silently mutating the old file until we are confident the new path is stable.

Required behavior

• On read:
  • If .openwork/openwork.json exists, use it as source of truth.
  • If only .opencode/openwork.json exists, read it as legacy config and surface a migration path.
• On write:
  • New writes should target .openwork/openwork.json.
• Migration:
  • Provide an explicit migration command or equivalent server/app action that copies the legacy config to .openwork/openwork.json.
  • Preserve contents exactly where possible.
  • Be idempotent.
  • Never overwrite a newer .openwork/openwork.json with stale legacy data.
  • Make failure states obvious and recoverable.
• Export/import/template flows:
  • Keep including OpenWork workspace config as a first-class portable surface.
  • Update any logic that currently assumes .opencode/openwork.json.
• File watching / reload / workspace boot:
  • Update all path references so OpenWork behavior remains stable.
• Docs:
  • Update architecture/product/docs to reflect the new canonical location and the compatibility behavior.

Safety constraints

• No destructive migration on first run.
• No silent data loss.
• No case where a user upgrades and suddenly appears to have “lost” their workspace config.
• If both files exist, define deterministic precedence and log/debug that clearly.
• Include a rollback story.

Suggested acceptance criteria

• Existing workspaces with only .opencode/openwork.json still load correctly.
• New workspaces are created with .openwork/openwork.json.
• A migration path copies legacy config to .openwork/openwork.json without data loss.
• Export/import/share flows still include the OpenWork workspace config correctly.
• Tests cover:
  • legacy-only workspace
  • new-path-only workspace
  • both files present
  • migration idempotency
  • failure/retry behavior

Context

The main reason for this issue is to guarantee we are not accidentally screwing users by mixing OpenWork-owned config into broader .opencode handling, while also guaranteeing that existing workspaces continue to behave correctly during and after the transition.