fix(planner): deploy-config instructions were cloud-only + legacy schema (#2392) - #2394
Merged
Conversation
…ema (#2392) The planner's always-loaded process doc (data/planner/process.md, "Record the Deploy stage's config") taught a deploy-config JSON example that was wrong three ways, and Claude follows the concrete example over the (correct) mode-aware prose in data/stages/deployment.json: 1. Legacy top-level schema (pre-#1421) — environments/pipeline/secrets/release hoisted above the services, not per-service. 2. Cloud-only — both example services were platform/workload; no mode:"local" example, so a local (CLI/desktop/library) build copied workload/host/build and never wrote localKind/buildTargets/artifact. 3. Wrong gate description — claimed the gate needs platform + release.strategy on every service; that's the cloud gate. serviceChecks() is mode-aware: local needs localKind + (buildTargets+artifact | publishRegistry+packageName), no platform/release. Result: a real project (a local Tauri app) stored {mode:"local", workload: "application"} with no localKind → serviceReady=false → deploymentDefined=false → the Deployment gate blocked permanently with no obvious cause. Rewrite the block: per-service, mode-aware, with BOTH a cloud and a local example, explicit mutual exclusivity, and a corrected mode-aware gate description. Both example services evaluate deploy-ready by the frontend's own serviceReady logic. Adds a regression test (planner/mod.rs) asserting the example covers both modes. Closes #2392
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The planner's always-loaded process doc (
data/planner/process.md, "Record the Deploy stage's config") taught a deploy-config JSON example that was wrong three ways, and Claude follows the concrete example over the (correct) mode-aware prose indata/stages/deployment.json:environments/pipeline/secrets/releasehoisted above the services, not per-service.platform/workload; nomode:"local"example, so a local (CLI/desktop/library) build copiedworkload/host/buildand never wrotelocalKind/buildTargets/artifact.platform+release.strategyon every service; that's the cloud gate.serviceChecks()is mode-aware.Observed: a real local Tauri project stored
{mode:"local", workload:"application"}with nolocalKind→serviceReady=false→deploymentDefined=false→ the Deployment gate blocked permanently with no obvious cause.Fix
Rewrote the block: per-service, mode-aware, with both a cloud and a local example, explicit mutual exclusivity, and a corrected mode-aware gate description. Both example services evaluate deploy-ready by the frontend's own
serviceReadylogic (verified). Adds a regression test (planner/mod.rs) asserting the example covers both modes.Closes #2392.
🤖 Generated with Claude Code