Update to HZplan

{
  "description": "Make precise, usable, verified changes to an existing HZplan plan without dropping unrelated geometry, breaking circulation, or editing the wrong floor. Use when the user asks to move, resize, reconnect, rename, restyle, replace, or delete existing walls, openings, rooms, furniture, fixtures, finishes, illustrations, 3D assignments, or generated 3D assets. Do not use to construct a new plan from scratch; use hzplan-build-floor-plan instead.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 478
    },
    {
      "relative_path": "references/room-planning-basics.md",
      "size_in_bytes": 6448
    }
  ],
  "name": "hzplan-edit-floor-plan-safely",
  "skill_md_contents": "---\nname: hzplan-edit-floor-plan-safely\ndescription: Make precise, usable, verified changes to an existing HZplan plan without dropping unrelated geometry, breaking circulation, or editing the wrong floor. Use when the user asks to move, resize, reconnect, rename, restyle, replace, or delete existing walls, openings, rooms, furniture, fixtures, finishes, illustrations, 3D assignments, or generated 3D assets. Do not use to construct a new plan from scratch; use hzplan-build-floor-plan instead.\n---\n\n# Edit a HZplan floor plan safely\n\nInspect before writing, preserve stated invariants, and verify the solved result. The user's explicit instructions take precedence over this workflow.\n\n## Resolve the target\n\n1. Resolve the plan and storey before changing anything. Use `list_plans` or `get_plan` only when necessary, then call `get_storey_plan` for the target floor.\n2. Pass `storey_id` explicitly on every storey-scoped read and write, even when the server could infer it.\n3. Treat IDs returned by HZplan as authoritative. Never infer an entity's floor from its local ID.\n4. For object edits, call `get_object` when the current assertions or solved placement are not already present in the storey read.\n5. Resolve human descriptions such as \"bottom wall\" from `resolved_geometry`, compass side, dimensions, and adjacency. If more than one entity still matches, ask the user to disambiguate before writing.\n6. For geometry, attachment, opening, or surface-finish edits, call `get_authoring_guide` before writing. Skip it only when a dedicated simple tool's current schema fully defines the requested change.\n\n## Preserve the user's invariants\n\n1. Translate the request into a short list of targeted entities, requested changes, and properties that must remain fixed.\n2. Do not alter a fixed length, width, height, host, gap, or attachment unless the user requested it or the change is required for feasibility. Disclose any required collateral change before applying it.\n3. Use real millimetres directly. Never multiply or divide dimensions by the storey's informational scale factor.\n4. Avoid moving unrelated geometry to make a requested edit appear successful.\n\n## Protect spatial usability\n\n1. When choosing a new opening, room arrangement, or furniture position rather than applying exact user-supplied geometry, read `references/room-planning-basics.md` before writing.\n2. Preserve clear door openings and swings, continuous circulation, access to important windows, and working space in front of furniture, appliances, storage, and fixtures unless the user explicitly accepts a disclosed tradeoff.\n3. Treat the reference's dimensions and room patterns as conservative defaults, not proof of compliance. For an accessibility or regulatory request, use the applicable jurisdiction and user requirements and do not claim certification.\n4. If the requested edit cannot fit while preserving these conditions, report the conflict and ask which constraint may change rather than moving unrelated entities or creating an overlap.\n\n## Choose the narrowest write\n\n- Use `set_entity_assertions` to replace or add individual geometry assertions on an existing entity while preserving all other assertions.\n- Use `remove_entity_assertions` to remove specific assertion keys while preserving the remainder.\n- Use `set_entity_attributes` for passive metadata that must not affect the solver.\n- Use the dedicated object tools for height, feature side, illustration, and existing 3D-asset assignment.\n- Use `delete_object_3d_asset` only for an explicit request to remove a generated model. If HZplan reports that plans still reference it, identify those dependencies and ask before detaching them with `set_object_3d_asset`; never alter plans merely to make deletion succeed.\n- Use `upsert_entity` for creation or a deliberate full replacement only. Before replacing an existing entity, read it and resend every assertion that must survive; omitted assertions are removed.\n- Use `upsert_entities` for a related set of changes that should succeed or fail atomically. Pass the latest `content_version` as `expected_content_version` when available.\n- Use deletion tools only for an explicit deletion request. Read and report dependency blockers rather than deleting or relocating additional entities speculatively.\n\n## Apply and recover\n\n1. Prefer one coherent batch for coupled changes and small batches for visually sensitive iteration.\n2. Inspect every write result for the returned entity ID, complete assertions, any `normalized_anchors`, `resolved_geometry`, solver state, and content version.\n3. If a write conflicts with a newer content version, re-read the storey and remap the requested change before retrying. If an ID-less create has an uncertain outcome, re-read before retrying because a repeated call can create a duplicate.\n4. If the solver rejects a change, diagnose the contradictory or missing constraint and repair that cause. For attachment errors, use the valid pairings or exact replacement assertion returned by HZplan instead of guessing. Do not stack unrelated trial edits.\n5. Do not start `generate_object_3d` as part of an ordinary furniture edit. Use it only when explicitly requested and explain that generation may take several minutes.\n\n## Verify the result\n\n1. Re-read the affected storey after geometry changes.\n2. Use `render_storey_widget` when the change affects placement, size, orientation, openings, or room boundaries. Inspect door swings, passage continuity, window access, furniture use zones, and collisions.\n3. Compare the solved result with every requested invariant. For example, if the user fixed a wall at 1000 mm by 600 mm, verify both dimensions and both requested contacts.\n4. For room-access changes, call `get_plan_topology` and verify the expected connectivity.\n5. If verification reveals an unexpected result, explain it and correct the root constraint before claiming success.\n\n## Complete the handoff\n\nReport:\n\n- Which entities changed and on which storey.\n- The resulting solved dimensions or positions relevant to the request.\n- Whether solver and topology validation passed.\n- A plan or render link when available.\n- Any assumption, limitation, or follow-up that remains.\n\nNever claim that the edited plan is professionally certified or fully compliant with building regulations.\n"
}