[Bug] Keep decision adaptations when the Builder deploys

[wilsonwu]

Closes #4534

Purpose

Deploying from the Builder removed adaptations from every decision, even without edits. The Builder deploys DSL-compiled routing in replace mode. The DSL cannot express adaptations, and mergeDSLOwnedNodes replaced routing and recipes with the compiled nodes. Those decisions then fell back to mode: apply, so Router Learning started to act on routes that were set to bypass or observe it.

This change touches only the dashboard backend:

• New preserveBaseDecisionAdaptations (deploy_policy_preservation.go):
  • Before the DSL-owned sections are replaced or merged, it copies each base decision's adaptations into the compiled decision with the same name.
  • Inside recipes it matches the recipe by name first, so identically named decisions in different recipes never share policy.
  • A value already in the compiled fragment wins.
• mergeDSLOwnedNodes calls it in both deploy modes. Merge mode also replaces a supplied decisions or recipes list as a whole, so DSL-compiled fragments lost adaptations there too.
• This is the rule dsl.MergeRoutingIntoBase already applies for sr-dsl compile --base.

Owner: Developer Experience & Ecosystem Workgroup (dashboard).

Test Plan

• go test ./handlers -run 'TestMergeDeployPayload|TestDeploy' in dashboard/backend. New tests:
  • TestMergeDeployPayloadKeepsBaseDecisionAdaptations, in replace and merge mode:
    • top-level and recipe-scoped decisions keep their adaptations
    • a new decision and a new recipe do not inherit any
    • an explicit value in the fragment wins
  • TestMergeDeployPayloadReplaceKeepsMaintainedDecisionAdaptations:
    • runs the Builder's path (parse, decompile, compile, emit, replace deploy)
    • configs: config/config.yaml, the agent recipe, and both built-in mom-v1 configs
    • compares every decision's adaptations with the original
• make dashboard-check
• make check CHANGED_FILES="<the 3 changed files>"
• Manual run without Docker: Go backend on :8700 and Vite on :3001.
  • Load the config, click Deploy without edits, check the Config Diff, click Deploy Now, and read the written config.yaml.
  • Configs: the default config, the agent recipe and the built-in mom-v1 recipe.
  • Each config was checked on main and on this branch.

Test Result

• The new tests fail on main (all 4 maintained configs, and both modes of the unit test) and pass here. All deploy handler tests pass.

• make dashboard-check and make check pass.

• Manual, main → this fix:

  Scenario	main	this fix
  Default config, Deploy preview: decisions with adaptations	4 → 0	4 → 4
  agent recipe, Deploy Now: decisions with adaptations in the written config	2 → 0	2 → 2
  Built-in mom-v1 (recipe-scoped), Deploy Now: written config	16 → 0	16 → 16
  Changes in the Deploy preview (default / agent / mom-v1)	44 / 11 / 28	40 / 9 / 14

• The remaining preview changes are other DSL round-trip differences, such as list order and fields the DSL does not carry. This PR does not change them.

• With the default config, Deploy Now fails validation on main and here for a separate reason. The DSL round trip adds the static_business_route candidate iteration model to modelRefs, and its LoRA business-adapter is not declared in modelCards. A config merged by sr-dsl compile --base fails the same validation.

• A renamed decision does not keep the old name's adaptations, as with sr-dsl compile --base.

• I did not run the optional dashboard E2E profile locally because it needs a kind cluster. CI selects it.

Before fix:

After fix:

---

Semantic Router PR Checklist

• PR title begins with exactly one bracketed category, such as [Feature], [Bug], [Docs], [Test], [Research], [Community], or [CI/Build]
• The title does not stack prefixes such as [Router][Docs]; affected modules belong in labels and the PR body
• The PR links an accepted issue with exactly one owner: one wg/* label for project work or owner/maintainers for repository governance
• Commits in this PR are signed off with git commit -s
• The Purpose, Test Plan, and Test Result sections reflect the actual scope, commands, and blockers for this change

See CONTRIBUTING.md for the full contributor workflow and commit guidance.

[Xunzhuo]

Thanks for preserving decision adaptations across Builder deploys. The new round-trip test includes an archived v0.4 config that the current parser rejects before checking adaptations; please use a compatible fixture and rerun the Dashboard suite.

[Xunzhuo]

Thanks for updating the fixture. The maintained-config round trips and Dashboard suite now pass, including preserving decision adaptations across both deploy modes.

[mergify]

Queued — the merge queue status continues in this comment ↓.

[mergify]

Merge Queue Status

🛑 Queue command has been cancelled

[mergify]

Merge Queue Status

🛑 Queue command has been cancelled

[mergify]

Merge Queue Status

🛑 Queue command has been cancelled

[mergify]

Merge Queue Status

• ✅ Entered queue — 2026-10-10 12:55 UTC · Rule: default · triggered by @wilsonwu with the merge queue checkbox
• 🚫 Left the queue — 2026-10-10 12:58 UTC · at a23f230b880574fb0a95a0272ee2b6fd7b74495b

This pull request spent 3 minutes 37 seconds in the queue, with no time running CI.

Reason

Pull request #4535 has been dequeued

Pull request from fork cannot be queued. This pull request comes from a fork, and Mergify needs the author's permission to update its branch.

The author needs to enable "Allow edits from maintainers" on this pull request.

Hint

You should look at the reason for the failure and decide if the pull request needs to be fixed or if you want to requeue it.
If you do update this pull request, it will automatically be requeued once the queue conditions match again.
If you think this was a flaky issue instead, you can requeue the pull request, without updating it, by posting a @mergifyio queue comment.

Tick the box to put this pull request back in the merge queue (same as @mergifyio queue).

• Requeue this pull request