Bundle editor scope is unclear; support per-workspace override state

[bradleat]

Problem

The current "Edit Bundle Config" workflow is launched from a workspace context, but the saved onboarding state is mostly project-shared. This creates a mental-model mismatch and can cause accidental cross-workspace changes.

Users reasonably assume:

• If they edit bundle values from a workspace row, changes are workspace-local.
• "Bundle config" might refer to editing bundle.json itself.

Today neither is true.

Current behavior

1) Bundle definition source is workspace-aware

The editor uses the workspace's effective bundle definition:

• workspace .gitspace/bundle.json first
• base repo fallback if workspace has no bundle

2) Applied values/secrets are project-shared

Saved state is currently project-scoped:

• input values -> ProjectConfig.bundleValues
• secret key list -> ProjectConfig.bundleSecretKeys
• confirm/check history -> ProjectConfig.bundleConfirmHistory

Secret values are stored in project secrets storage (project blob), keyed by projectName + configKey.

3) Per-workspace state exists, but only as metadata

bundleWorkspaceState tracks scope/hash/requirements metadata, but not per-workspace value overrides.

UX problems

1. Workspace entry point implies workspace-local edits
   The label "Edit Bundle Config" from a workspace row strongly suggests local scope.

2. Cross-workspace side effects are implicit
   Editing workspace A can change effective runtime values for workspace B when keys overlap.

3. Terminology is ambiguous
   "Bundle config" sounds like editing bundle.json (definition), but we are editing applied onboarding state.

4. Missing scope transparency in UI/CLI
   We do not clearly show:

   • bundle source (workspace vs base)
   • save scope (project shared vs workspace override)

5. Confirm/check status can feel global unexpectedly
   Confirm history is keyed by step fingerprint, so a passed check can suppress prompts across workspaces with matching steps.

Desired behavior

Introduce layered applied state:

• Project defaults (shared baseline)
• Optional per-workspace overrides
• Effective runtime resolution: workspace override > project default

This should apply to:

• input values
• secret values/set-state
• confirm/check results

UX expectations

• Users can tell whether they are editing shared defaults or workspace overrides.
• Workspace-scoped edits can be isolated to one workspace.
• Inherited vs overridden state is visible.
• Resetting an override falls back to project default.
• Labels/copy distinguish:
  • bundle definition (bundle.json)
  • applied values/secrets/check state

Suggested UI copy improvements (short-term)

Even before full override support:

• Rename "Edit Bundle Config" -> "Edit Bundle Values" (or "Edit Applied Bundle Values").
• Show bundle source in flow header: Workspace bundle / Base bundle.
• Show save scope in flow header and success messages.
• Add warnings when change impacts project-shared state.

Acceptance criteria (for full fix)

• Data model supports project defaults + workspace overrides for applied state
• Runtime script env uses effective values with workspace precedence
• CLI and TUI/Web expose scope explicitly and consistently
• Users can set, view, and unset workspace override values/secrets
• Users can view inherited values and reset to default
• Confirm/check history supports scoped override semantics
• Existing project-shared state migrates cleanly to defaults without data loss

Why this matters

This is a trust and safety issue in day-to-day workflow management. Workspace-level actions should not silently behave as global edits without explicit signal.

[bradleat]

Related PRs

• PR Bundle refresh + per-worktree scripts + secrets consolidation #21 — Bundle refresh + per-worktree scripts + secrets consolidation (MERGED): Added bundle refresh detection/command with workspace-preferred bundle.json and TUI support. Introduced the pattern of workspace-preferred bundle resolution (workspace .gitspace/bundle.json first, base repo fallback) that this issue builds on. The per-workspace bundle source distinction is the foundation needed before layered applied state can be added.
  Bundle refresh + per-worktree scripts + secrets consolidation #21

• PR feat: opencode agent sessions with notification system and session persistence #71 — feat: add opencode agent sessions and bundle integration scaffolding (OPEN): Adds bundle onboarding integration steps and first-pass runtime integration prep. While focused on OpenCode agent sessions, it touches the bundle onboarding/requirement flows that this issue's acceptance criteria depend on working correctly under the new scoped model.
  feat: opencode agent sessions with notification system and session persistence #71

Note: As of the time of this comment, no PR has been opened that directly implements the layered applied state (project defaults + per-workspace overrides for input values, secrets, and confirm/check history) described in the acceptance criteria for this issue.

[bradleat]

Related: #92 puts bundle onboarding state under and project/workspace config under . The layered override model described here (project defaults + workspace overrides) maps cleanly to that ownership structure.