[Fix] Environment updates delete unrelated settings when agents revise setup

.changeset/preserve-environment-config-updates.md

@@ -0,0 +1,6 @@
+---
+"@roomote/cloud-agents": patch
+"@roomote/worker": patch
+---
+
+Preserve unrelated environment settings when an agent revises an existing environment definition, and clarify that update calls replace the full definition.

apps/worker/src/mcp/roomote-mcp-server/index.ts

@@ -1127,7 +1127,7 @@ roomoteMcpServer.registerTool(
         .string()
         .optional()
         .describe(
-          'Environment definition as a YAML or JSON string. Must satisfy EnvironmentConfig (e.g., include name and repositories). Required for "create" and "update".',
+          'Complete environment definition as a YAML or JSON string. Must satisfy EnvironmentConfig (e.g., include name and repositories). Required for "create" and "update". An update replaces the full definition: start from the current definition and preserve every field that is not intentionally changing.',
         ),
       environmentId: z
         .string()

packages/cloud-agents/src/server/workflows/skills/standard/environment-setup/SKILL.md

@@ -27,6 +27,7 @@ You are an expert Roomote environment analyst. Analyze the already-checked-out r
           <action>Treat repository context as:
 - Repository: `<exact-provided-repository-identifier>`
 - Default branch: `<default-branch>`</action>
+          <action>When revising an existing environment, treat the complete current environment definition supplied in the trusted task context as the baseline. Repository evidence may justify targeted changes, but it does not replace or supersede unrelated persisted configuration.</action>
         </actions>
         <validation>The repository target and branch baseline are explicit before config drafting starts.</validation>
       </step>
@@ -88,6 +89,7 @@ You are an expert Roomote environment analyst. Analyze the already-checked-out r
         <description>Create the smallest valid Roomote environment YAML from static evidence.</description>
         <actions>
           <action>Produce exactly one initial YAML config.</action>
+          <action>For an existing environment, start from its complete current definition and apply only the requested or validation-backed changes. Preserve every unrelated field verbatim, especially `agentInstructions`, `skills`, `manualSkills`, environment variables, MCP servers, services, Docker projects, ports, and setup commands. The update API replaces the full definition, so an omitted field is a deletion; never regenerate an existing definition from repository evidence alone.</action>
           <action>Copy each task-provided repository identifier verbatim into its matching `repositories[].repository` field. In particular, preserve all three `organization/project/repository` segments for Azure DevOps repositories.</action>
           <action>Use repository default branch unless strong evidence indicates a different branch.</action>
           <action>Assume the repositories listed in the environment already exist in the workspace; do not add repository clone commands or other duplicate checkout steps.</action>
@@ -369,7 +371,7 @@ You are an expert Roomote environment analyst. Analyze the already-checked-out r
 <rule>In Slack-started setup tasks, send a concise `send_chat_reply` message with `purpose` set to `progress` naming the required keys and what they unblock, but do not include the secure `/setup` link yourself because the platform automatically accompanies the request with that secure-entry link after `request_environment_variables` succeeds.</rule>
 <rule>In non-web surfaces, ask only for local environment variable additions in the current task, and provide exact variable names and exact actions.</rule>
 <rule>For apps with a required human-facing localhost surface, create or update the environment only after startup and loopback reachability are successful enough to proceed, including validation of `initialUrl` through non-browser evidence. For backend services and libraries without such a surface, successful install and canonical tests may be sufficient only when omitted credentials affect optional integrations or external runtime capabilities rather than a required local runtime; do not require unrelated external credentials merely to exercise a broader runtime path.</rule>
-<rule>When the task explicitly identifies an existing environment to revise, update that environment instead of creating a duplicate.</rule>
+<rule>When the task explicitly identifies an existing environment to revise, update that environment instead of creating a duplicate. Use its complete current definition as the update baseline and preserve every field outside the requested or evidence-backed change; never submit a newly derived partial replacement.</rule>
 <rule>After successful environment persistence, use the Roomote MCP tool `mcp__roomote__manage_tasks` to launch a lightweight verification task against the created or updated environment and monitor it yourself instead of leaving verification as an implicit manual next step.</rule>
 <rule>Before launching that verification task, call the Roomote MCP tool `mcp__roomote__manage_tasks` with `action: "list_environments"` so the environment target is grounded in current Roomote data and you can copy the exact returned `environmentId`.</rule>
 <rule>When the verification task launch succeeds, treat the `notifyOnSettle` settle notification as the primary completion signal and monitor the task with the Roomote MCP tool `mcp__roomote__manage_tasks` using `action: "get_summary"` only as a fallback, spacing fallback checks roughly 60-90 seconds apart with one blocking `sleep` per wait. Use that per-task summary surface as the source of truth for task status and surfaced startup failures.</rule>