Problem
Current sync and status behavior are too optimistic when the active warehouse does not match the local lock state. A model can report successful sync while the warehouse table is missing, and status can still show stale local publish history without telling the user that it belongs to a different warehouse context.
We want a lightweight user flow, not a destructive default. That means sync should be a cheap reconcile/check step, but it must be explicit about warehouse divergence.
Goal
Make dbp model sync and dbp status warehouse-aware and introduce a clear destructive-reconcile flow only when needed.
Proposed behavior
dbp status
- Resolve state from the active warehouse binding.
- Show remote presence explicitly, for example: present / missing / unreachable.
- Avoid presenting stale local publish history as current warehouse truth.
dbp model sync
- Preserve local non-destructive working state by default.
- Refresh warehouse-derived state for the active binding.
- If the warehouse is empty or significantly diverged, report that clearly instead of implying full reconciliation.
- Prompt for destructive local wipe only when the difference is unresolvable automatically.
Prompting rule
Prompt only when sync would destroy local state or discard cached history for the active binding. Do not prompt for normal warehouse refreshes.
Acceptance criteria
dbp status distinguishes local cached state from current warehouse state, or shows only the active binding state if the model data is fully scoped.
dbp model sync surfaces remote absence or divergence in its human-readable output.
- Destructive reconciliation is explicit and confirmed by the user.
- Non-destructive sync remains the default lightweight path.
- Docs for sync/status explain the divergence behavior at a high level.
Problem
Current sync and status behavior are too optimistic when the active warehouse does not match the local lock state. A model can report successful sync while the warehouse table is missing, and status can still show stale local publish history without telling the user that it belongs to a different warehouse context.
We want a lightweight user flow, not a destructive default. That means sync should be a cheap reconcile/check step, but it must be explicit about warehouse divergence.
Goal
Make
dbp model syncanddbp statuswarehouse-aware and introduce a clear destructive-reconcile flow only when needed.Proposed behavior
dbp statusdbp model syncPrompting rule
Prompt only when sync would destroy local state or discard cached history for the active binding. Do not prompt for normal warehouse refreshes.
Acceptance criteria
dbp statusdistinguishes local cached state from current warehouse state, or shows only the active binding state if the model data is fully scoped.dbp model syncsurfaces remote absence or divergence in its human-readable output.