Spec: Stale Control Plane Stable Baseline

Initial Situation

Stable scaffold baselines are published as GitHub releases. The CLI also asks the Harness control plane for typed stable baseline metadata before falling back to GitHub release discovery. Issue 49 shows that the control-plane response can drift from the latest published stable baseline.

Issue

dp update --baseline stable --refresh-baseline --yes returned the stale control-plane stable baseline 2026.06.23-scoped-review-phases while the published stable baseline was 2026.06.23-scaffold-detection-guidance. Disabling the control plane made the same command discover the newer GitHub stable baseline. Later, default dp update --baseline stable --check --json could still accept the same stale control-plane pointer when the latest published GitHub stable was 2026.06.29-frontend-imagegen-skills. Stable resolution should not require --refresh-baseline or a disabled control plane to notice the canonical published stable baseline.

Solution

For normal stable resolution and stable refresh resolution, verify the control-plane result against the published stable release path before accepting it when that release source is reachable. When that published stable source resolves a different baseline, use the published stable baseline.

Non-Goals

• Reconcile /Users/stefan/Desktop/repos/traevolution-app scaffold changes.
• Publish a new npm or baseline release.
• Remove bundled fallback.
• Redesign the control-plane registry contract.

Acceptance Criteria

• Regression tests prove stale or different control-plane stable metadata plus a published stable release resolves to the published stable baseline.
• Existing bundled fallback and offline behavior still pass.
• dp update --baseline stable --refresh-baseline --yes and default stable update/check resolution have code-backed freshness behavior, not a manual DP_DISABLE_BUNDLED_CONTROL_PLANE_URL workaround.
• Docs and debt artifacts link the issue, fix, and validation evidence.