Stale Control Plane Stable Baseline

Initial Debt

Issue 49 reported that dp update --baseline stable --refresh-baseline --yes accepted stale stable metadata from the bundled production control plane. The CLI resolved 2026.06.23-scoped-review-phases even though the published stable baseline and local stable cache had 2026.06.23-scaffold-detection-guidance. Disabling the control-plane URL forced GitHub fallback and found the newer stable baseline.

Why It Matters

Stable update/check resolution is expected to track the latest published stable baseline when that source is reachable. If mismatched control-plane metadata wins without checking the published stable release source, the command can report no drift and leave a consumer repository on the wrong generated guidance.

Proposed Resolution

Stable resolution must verify control-plane metadata against the published stable release path before accepting it when that release source is reachable. If the published stable release path resolves a different baseline, the CLI must use that published stable baseline instead of the control-plane result.

Resolution

apps/cli/src/baseline/resolve.ts now checks the latest published stable release tag when stable resolution has materialized a control-plane baseline. If that tag names a different stable version, the resolver materializes and returns the published stable baseline instead of the stale control-plane result. This applies to both default stable resolution and --refresh-baseline.

Acceptance Checks

• Regression tests: stale or different control-plane stable metadata plus a published stable release resolves to the published release for refresh and default stable resolution.
• Existing offline, bundled fallback, and control-plane unavailable behavior remains intact.
• Operator docs explain that stable resolution does not trust mismatched control-plane metadata when GitHub stable proves the published baseline.
• Issue 49 is synced with validation evidence and ready to close.

Validation

• bun --cwd apps/cli test src/baseline/resolve.test.ts
• bun --cwd apps/cli test src/baseline/resolve.test.ts src/update/run.test.ts
• bun -e 'import { resolveBaseline } from "./apps/cli/src/baseline/resolve.ts"; ...' resolved baseline/stable/2026.06.23-scaffold-detection-guidance.
• bun run apps/cli/src/index.ts update --check --baseline stable --refresh-baseline --json exited 1 for existing scaffold managed-file drift; resolver evidence above proves the stable freshness path.
• bun run check
• git diff --check

Closeout

Resolved for issue 49 by adding regression coverage, fixing stable freshness resolution for refresh and default stable paths, documenting the operator behavior, syncing the GitHub issue with evidence, and closing the issue. Traevolution scaffold reconciliation remains out of scope. The API endpoint is still deployment-env pinned; removing that second stable pointer is separate backend/publishing work.