Planner5D: Plan, Build, Create

View saved version →

---
name: planner5d-ai-render
description: Generate or refine a photorealistic AI image from a native Planner 5D scene screenshot while preserving geometry, materials and visible lighting. Use the editor's quoted screenshot-to-AI workflow.
---

# Planner 5D AI rendering

Open the intended project through the app's navigation, then read `editorGetContext` and `getWebMcpGuide` help for `editorSubmitRender`. The live request schema defines preparation, generation and status recovery.

For the person's specific furniture, first complete `planner5d-model-import` and verify its native placement, real scale and readiness. For PDF/plan → AI render, complete `planner5d-floorplan-recheck` and the requested furnishing before capture. Reuse the existing project and verify the source before rendering; do not silently substitute a catalog lookalike. If a furnished interior is requested, an empty plan does not fulfill it. An explicit architecture-only/render-only brief preserves that narrower scope. When comparing product/finish variants, preserve verified geometry and a consistent source camera unless the person asks for different views.

1. Choose the view with native 3D preview/camera controls and inspect the actual image. Ensure needed models and materials are loaded. For camera information, request `includeCamera:true` only when the editor is already in 3D.
2. Prepare the screenshot-based AI request with the actual expected project hash and a stable request ID. Preparation persists native pixels and returns the signed price/quote; it does not submit conventional scene geometry to the server renderer.
3. Describe the requested appearance using source evidence. Preserve wall/opening locations, furniture proportions, dark material texture, glass/mirror behavior and visible structural features. Describe enabled lighting and its observed positions; do not invent extra fixtures or alter the layout to improve a picture.
4. Generate only under the user's authorized credit budget, passing the prepared quote and explicit maximum credits required by the live schema. Native permissions and billing decide eligibility and charges.
5. Follow the existing generation through status using its returned identity. Check completion, saved output, visual fidelity and the accessible image. A retry must recover the previous request before creating another charged generation.

Use native screenshots/previews for source verification. Keep credentials, signed upload/download tokens and one-use login tickets out of user-facing output. Return the verified render and project link, with any visible fidelity differences. An AI image does not certify room measurements or a construction drawing.

Referenced files: 1

View saved version →

---
name: planner5d-floorplan-recheck
description: Recognize, recreate or audit Planner5D floor plans from plan drawings/images, PDF/CAD, or measured scan geometry. Compare source dimensions, rooms, walls and openings, then make native corrections while preserving valid work. Use for recognition quality and measured source-plan fidelity, not ordinary interior/facade photographs without a plan.
metadata:
  version: "0.1.9"
---

# Planner5D floorplan recheck

For a Planner 5D MCP App, use the server relay described in `planner5d-native-app` and invoke native `goToEditorProject` through `change_planner5d` to open the verified target. Read the live editor context after navigation. The ordinary browser route and the app route use the same native operations and measurement contracts.

For an already-recognized project, start with comparison; do not upload the source again. Honor read-only/manual-construction requests. Read [recognition and recovery](references/recognition.md) only for submission/recovery, and [geometry correction](references/geometry-correction.md) only for a measured geometry defect.

**Removal gate:** do not call `remove` unless actual `selected` is nonempty and matches the intended source-absent IDs exactly. A wanted window/door in that set means stop before removal. `editorClearSelection` clears focus; it does **not** ungroup objects. Never replace a wanted original opening with a catalog substitute to repair this mistake.

## Establish source and target

Inspect the source. Record page/floor, scale, labeled lengths and their **basis** (inner span, wall path, exterior span, opening width), room functions, access and openings. Keep measurements, visual estimates and defaults distinct. Identify plan pages/floor order in multipage PDFs; do not silently omit floors. Missing scale blocks exact length claims, not useful topology review.

Use all assigned sources and the user's requested contents: an item omitted from one plan view may be supported by another photo or by the furnishing brief. `Ns` can also be a roof, stair or other architectural catalog component. Do not delete every `Ns` merely because the plan drawing is unfurnished.

Set tolerance from user requirements and source precision; a label rounded to 0.1 m is not centimeter-exact. Keep a compact ledger: source reference, expected value/basis, object IDs, observed value/method/basis, units and tolerance. Use the [ledger reference and optional arithmetic helper](references/measurement-ledger.md) for complex comparisons; do not reread an already-loaded entrypoint.

Start with `editorGetContext({})`: bind the project hash, floor, permissions and revision. Omit `includeCamera` in 2D. Read `getWebMcpGuide` once; request help only for unfamiliar registered tools, at most eight names per call. Follow live schemas, without guessed tools or private-state fallbacks.

## Measure before diagnosing

1. List the complete scoped inventory with `editorListObjects` (up to 100 per page). `Room`, `Wall` and `Point` are structure; `Door` and `Window` are openings; `Ns` denotes catalog models such as furniture or curtains, and `Pr` denotes primitives. Inspect and classify every `Ns`/`Pr` against the source before claiming no additions. Empty names or unloaded bounds do not mean absent objects. Batch related IDs in `editorInspectObjects`, `fields:["geometry","properties"]` (up to 50 IDs). Retain original opening IDs, catalogs, positions, dimensions and attachments. Read `data` only for missing required fields.
2. Read wall properties whose `property` is `length`, including their returned `units`, paired with wall paths. **`editorGetSceneMeasurements` supplies flooring areas/counts, not room width/depth.** Repeating it cannot supply a missing length. Context/outline bounds are path evidence.
3. Confirm the length's basis from native geometry and flooring area, with 2D dimensions when available; do not label `length` as a path measurement merely because it belongs to a wall. For a verified rectangle, cover both opposing side chains on each axis, summing contiguous collinear segments. Compare `widthCm × depthCm / 10000` with native `flooringArea`: agreement within measurement rounding, together with both opposing reported lengths being materially smaller than their measured paths (beyond native rounding), corroborates the inline/usable basis. Record this method; 2D labels are additional evidence, not mandatory when the cross-check is decisive. Missing labels alone do not mean the returned length is a path measurement or require repeated previews. Area alone or an irregular/clipped floor cannot establish width/depth. Do not require four wall records.
4. Compare matching bases/units only. Source inner spans versus path bounds means **insufficient measurement evidence**: inspect native wall measurements before judging size. Do not rescale or report a mismatch from an unresolved basis.

Check floor/room functions, shared boundaries, entrance-to-room connections and source-supported opening positions, widths, directions/heights. When repositioning an opening, `offsetCm` is its center's distance along the inspected wall path; centered means half that path length, not half its usable interior `length` or a near-edge gap. Preserve the opening ID and inspect the applied center and aperture ends. In default 2D, X grows right and Y downward; a 3D orbit does not redefine north/south. Room-owned walls at a shared boundary are not by themselves erroneous duplicates.

## Correct only demonstrated differences

When dimensions/topology match, preserve geometry; correct only wrong functions/names and unwanted additions. Set inspected editable keys with string values. Room titles use `customName` when exposed, not `name`. A native room-type label may already satisfy the source; skip redundant custom titles unless exact wording matters. One rejected key does not prove naming is unsupported.

Finish this sequence for one saved `targetId` before selecting another group. Reuse returned IDs verbatim; an invalid ID is not evidence that a different object disappeared.

1. `editorSelectObject(targetId)` → `editorGetSelectionActions()`. Compare returned `selected` with the intended removal IDs, not just the requested ID.
2. If a wanted companion is selected, call `editorRunSelectionAction({action:"ungroup"})` only when available, then **reselect that same `targetId`** and read selection/actions again. Checking another curtain/window group cannot establish whether this ungroup succeeded.
3. Call `editorRunSelectionAction({action:"remove"})` only after the removal gate passes. If ungrouping is unavailable or the selection still includes a wanted object, leave it intact and report the blocker.
4. Verify this target is gone and its original opening is intact, then advance to the next target. If a mistake required Undo, verify restoration and change the failed selection procedure before retrying. Clearing selection and repeating the same group removal is not a recovery.

Use current revisions, stable operation keys and terminal business results; preserve partial IDs. Reuse measurements after name/type/decor-only edits when geometry preservation agrees. Inspect affected objects after correction and perform one final scoped check. Avoid full-document/measurement/preview loops without a new discrepancy. For persistent errors, revise the diagnosis or report a blocker.

## Verify and deliver

Capture 2D/3D with `editorGetScenePreview({view:"2d",scope:{kind:"floor"},maxImageBytes:1000000})` and the corresponding 3D call. Default width is 768, maximum 1024. Inspect actual image blocks, not serialized base64. The preview switches view and waits for readiness; wait separately only for reported pending IDs, in the required view. Use a smaller relevant scope for unreadable details.

Run scoped `editorValidateScene`; retain inherited warnings when geometry otherwise matches. A clean structure result does not certify circulation, door swing, wall clearance or exact mesh contact. State checked and unresolved constraints. Finish the shell before cosmetics/furnishing.

Return the project link (using the native result URL or the connected Planner origin with the verified project hash), source-versus-actual measurements with basis/tolerance, corrections, inventory counts, preservation checks and blockers. Normal autosave suffices for routine edits; idle is not a server receipt. Reload for requested persistence tests. Test Undo/Redo when geometry/history recovery needs it, checking neighbors and attachments. Keep credentials and signed access tokens out of links/results.

For plan import followed by furnishing or an AI render, continue from this verified native project: use `planner5d-webmcp` for the requested room design, `planner5d-model-import` for specific real furniture, then `planner5d-ai-render` for the completed source scene. Return the requested final image and editable project; recognition alone does not finish that combined brief.

Referenced files: 5

View saved version →

---
name: planner5d-model-import
description: Import the user's furniture or custom 3D models from product photos, product links or model files into Planner 5D. Use for testing whether specific furniture fits, showing it in the user's interior, replacing an existing item or comparing furniture variants in a native project. Do not use for standalone illustrations or image edits that explicitly exclude a native project.
---

# Planner 5D model import and furniture fit

Use the person's actual product or owned model. Preserve its identity and real dimensions while producing the requested editable layout, measured fit assessment or scene-based AI render.

## Choose the outcome and source

- For an already imported item, inspect `listUserModels` and reuse its owned hash. A similar catalog sofa is not the person's sofa. Use a catalog alternative or simplified proxy only when that matches the request or the person accepts the approximation.
- A question with enough supplied measurements may need only a preliminary fit calculation. Do not require AI model generation for arithmetic or import/place objects in an explicitly read-only assessment.
- Furniture/product photos are object sources. Room photos guide interior reconstruction; floor-plan PDFs/images guide recognition and measured room geometry. Select the route from the requested outcome, not the file extension or the presence of furniture in a picture. An imported 3D mesh is an asset, not an editable native room plan.

Use the connected app or requested browser's registered native tools. In the app, follow `planner5d-native-app` to reuse the selected panel before opening one, discover with `get_planner5d_tools`, and execute tools through `read_planner5d` / `change_planner5d` using current panel/document IDs and stable operation IDs. Read `getWebMcpGuide` once and request the live `importUserModels`, `listUserModels` and placement schemas. Import actions, including capabilities/inspection, use the write wrapper when their annotation is not read-only. Refresh discovery/document ID after navigation. The native model `requestId` recovers its background jobs; the outer MCP `operation_id` identifies one exact call and input.

## Import and recover the owned model

Already-ready owned models and read-only dimensional assessments skip new import. When importing or configuring an asset, `importUserModels` takes a JSON-string `request`. Begin with `{"action":"capabilities"}` to read supported extensions, native byte limits and account access. Choose the source the person actually supplied:

| Source | Native import route |
| --- | --- |
| Attached product photo or small supported model file | `file` with the real filename and raw base64, within `inlineMaxBytes`. |
| Public product image URL | `image` with its URL and optional name. |
| Product/store page | `link` with the product URL. |
| Public 3D-file URL | `file_url` with its URL and native filename. |
| Large local 3D file | `prepare_upload` with filename and byte size; upload to the returned signed PUT destination with its headers, then import `uploaded_model` using the returned asset token. |

Do not pass a local/sandbox path as a public image URL or publish a private attachment to make this route work. Keep signed destinations and asset tokens private. Native subscription, credit, ownership and file checks remain authoritative.

Submit an import request with `action:"import"`, a stable `requestId` and a `sources` array whose source IDs are unique. `waitMs` is a bounded observation wait, not the job's lifetime. Keep the page open through upload/admission until the receipt contains a submitted model hash. Accepted server conversion can then continue after navigation or closure.

Recover with `{"action":"status","requestId":"stable-key"}`, including after reload; an observation error/deadline does not cancel conversion. Reuse identical input and requestId after uncertainty. For an unknown admission inspect the owned model list before deciding whether any new submission is necessary. Preserve submitted items in a partial batch and do not repeat them under another key.

For an import receipt, ready means the item is `submitted`, its model is `finished`, and no observation error remains. A completed tool operation, upload acknowledgement or thumbnail is insufficient. If `model.status` requires review/setup, use `{"action":"inspect","modelHash":"..."}` and the returned complete native configuration. When needed, submit a `configure` source with that hash/configuration and a new requestId for this deliberate configured copy; the original is preserved. Do not invent missing configuration fields. Failed or unresolved models remain unfinished. Native import configuration uses centimeters for size/position and Blender ZXY Euler radians for rotation; editor floor heading uses degrees. Read the returned configuration rather than guessing axes, pivot or units.

## Place the product and answer “will it fit?”

Open the intended project and bind to `editorGetContext`: project hash, floor, room, permissions and revision. If the room comes from a supplied plan, recognize/create its native geometry and compare the dimensions/openings first using `planner5d-floorplan-recheck`. For a room photograph use `planner5d-webmcp` reconstruction guidance and label unmeasured geometry as assumed.

Import alone does not place furniture. Insert the ready result through `editorPlaceCatalogItems` with `catalogId:"user_model/<hash>"`, retaining returned object IDs. Set its intended native position and pose, then obtain ready 3D geometry and inspect actual applied properties and transformed bounds.

Use measured/product-specification width, depth, height and intended operating pose as the physical truth. Photo-generated models can have arbitrary scale or inaccurate shape. Correct the imported proxy's units/scale to those real dimensions through returned native configuration or editable object properties; verify the applied values. Never reduce the real product's dimensions just to make it fit. Missing decisive measurements block an exact fit verdict, but can still allow a labeled visual concept.

For clearances and evidence coverage read [furniture fit evidence](references/fit-evidence.md). Compare loaded geometry with actual usable room boundaries, nearby furniture and the requested minimum passage. Run scoped `editorValidateScene` and inspect the actual 2D/3D views. Keep footprint, passage, height, door operation and delivery-route checks separate; a generated picture does not prove any of them.

## Show the furniture in the person's interior

For “how will this furniture look here?”, finish the native placement and requested finishes, then use `planner5d-ai-render` on that scene when available; otherwise follow the live `editorSubmitRender` preparation/generation/status guide. Compose and inspect a free source preview with the imported model loaded before preparing the quote. Render within the authorized budget and recover the same generation after uncertainty. Return the actual completed image together with the editable project; a technical preview is not an AI render. Compare the result with the source scene and product reference, noting visible differences rather than promising exact product reproduction from AI-generated geometry.

Common complete workflows are:

- Product photo/link/model + measured room → owned model → native placement → fit verdict and limiting clearance.
- Product source + existing interior → native placement/materials → reviewed source camera → AI render.
- PDF/plan image + furnishing brief → recognized and checked native plan → imported or catalog furniture as requested → AI render.
- Replace an existing item → inspect its identity and neighbors → place/verify the replacement → remove only the verified obsolete object using the exact-selection gate.
- Compare furniture or finish variants → reuse the owned model and verified room geometry, retain each option's dimensions, and keep the camera consistent for requested renders. Do not change both geometry and appearance without distinguishing those choices.

Verify normal autosave; for a requested persistence/E2E check use a fresh load and compare the imported model reference, dimensions and placement. Return the source/owned-model identity, project link, requested fit/render outcome and concrete unresolved checks. Distinguish import readiness, native scene correctness, saved persistence and AI-image fidelity.

Referenced files: 2

View saved version →

---
name: planner5d-native-app
description: Use the Planner 5D app in ChatGPT or Codex for native projects, spaces, design, recognition, furnishing, model imports, furniture fit, AI Studio images/videos, specifications, quotes, project documents and exports. Route a task to its native workspace and tools before editing.
---

# Planner 5D native app

Complete the requested work in the connected Planner 5D account through these server MCP tools:

1. Reuse the selected Planner 5D app or the panel already associated with this chat. If app context supplies a public `panel_id`, begin with that ID; do not call the opener merely because this is the first question. Call `open_planner5d` only when no Planner panel is selected or open, or the user requests a new one. Retain the panel ID for follow-up work.
2. Call `get_planner5d_tools` with that ID. A ready response provides `document_id` and the active native tool index. For actual input schemas, request one to eight `tool_names`.
3. Execute native reads with `read_planner5d`; execute navigation and changes with `change_planner5d`. Both accept `panel_id` and an `invocation` containing `operation_id`, `document_id`, `tool_name`, and `arguments`. The arguments must match that native tool's live schema.
4. Give each logical call a unique `operation_id`; reuse the exact ID and input to recover an uncertain response. Never create another ID just to replay an unconfirmed mutation.
5. Refresh discovery after navigation. Do not use the old document ID for the destination page. If discovery is still `connecting`, allow the selected panel to finish loading and retry discovery. If a visible selected panel is reported `closed`, refresh its app context or use its in-place reconnect control when available. Report a connection failure if recovery is unavailable; do not silently open a replacement window or switch to an unrelated browser tab.

Read `getWebMcpGuide` once through `read_planner5d`, then request the needed tool descriptions and schemas. The browser executes the original native operations; the MCP server transports requests and receipts. Do not call app-only delivery or session-renewal helpers, inspect private launch metadata, or substitute private application APIs.

## Choose the workspace

- Keep navigation available in the app: `goToSpaces`, `goToEditor`, `goToEditorProject`, and `goToPurchase` expose their native destinations. A navigation result schedules a page change; refresh capabilities and confirm the destination before dependent work.
- For a new home, design the shell and room access graph, create an editable project with `projectCreateScene`, and open its returned project hash. `goToEditor` followed by `editorCreateScene` is the native editor alternative. Existing projects start with their identity, revision and permissions from `editorGetContext`.
- Editor geometry tools become available after an editor is loaded. Spaces, documents, models, AI Studio and collaboration have their own mounted native providers. Navigate to the required provider rather than concluding the entire product lacks the capability.
- Native account, ownership, subscription and credit checks still apply. A denied action is not a reason to call a private application API or use another account.

## Use the relevant instructions

- Home and room design, catalog/furnishing, kitchens, measured fit, materials and reference-photo reconstruction: use `planner5d-webmcp` and its relevant references.
- The person's furniture from a product photo/link or 3D file, owned-model reuse, measured fit and showing that product in an interior: use `planner5d-model-import`.
- Image/PDF/CAD plan recognition and measured source comparison: use `planner5d-floorplan-recheck`.
- Photorealistic screenshot-based image generation: use `planner5d-ai-render`.
- Space/project organization, documents, imports, sharing, comments, quotes/specifications and native CAD/PDF exports: read [workspace operations](references/workspace.md) and discover the live provider.
- Image/video creation, reference edits and visual content in a Planner AI Studio sheet, including work beyond home design: read [AI Studio](references/ai-studio.md). Scene-based photoreal images use `planner5d-ai-render`.

Use the host's normal file and external-information tools for user-requested supporting research or arithmetic. Geometry, object placement, native history and project saving remain Planner operations. Copilot chat IDs, DPL, Modal design runtimes and private renderer state are not extension interfaces.

For a combined request, carry the result between workflows: imported/recognized plan → source comparison → requested furniture/model placement and fit → composed native scene → AI render. A request to show a product in the person's interior includes the final scene-based image when requested; do not stop at an uploaded model or imported empty plan.

## Finish the actual request

For a requested Planner design, create and verify an editable native project. A standalone concept PDF or generated picture is not a substitute for that project. Supplementary files are appropriate when requested or exported from the verified native result.

Keep stable operation IDs, inspect partial outcomes, and recover uncertain writes before retrying. Verify the requested rooms, connections, dimensions and outputs, then return the actual project and accessible native artifacts. Do not claim an accepted job is a completed render, imported model or downloaded drawing.

Referenced files: 3

View saved version →

---
name: planner5d-webmcp
description: Build, furnish, edit, or assess native Planner5D homes from briefs, measurements, floor plans, furniture/model sources or interior/exterior reference pictures. Use for room and house design, furniture fit, showing the user's furniture in their interior, plan-to-AI-render workflows, and verified project handoff through the Planner 5D app or browser WebMCP. Keep observed, measured and proposed details distinct.
metadata:
  version: "0.2.5"
---

# Planner5D WebMCP

Create a project the person can continue editing normally. Optimize for a correct, usable result and bounded tool traffic.

## Choose the input route

- A floorplan drawing or a photograph of a floorplan can use recognition followed by source comparison. A real room/facade photo or a perspective render is not a floorplan: do not submit it to floorplan recognition.
- For the person's specific furniture from a photo, product link or 3D file, use `planner5d-model-import` to reuse/import the actual item before placing or testing it. Preserve real product dimensions; a catalog lookalike needs an accepted approximation. A read-only dimensional question need not generate or place a model.
- For interior/exterior pictures, mixed photo/plan references, or style recreation, read [picture-based reconstruction](references/picture-reconstruction.md) before geometry writes. Known dimensions control geometry; photographs control only the features they actually show. A precise hidden layout or scale cannot be recovered from one unmeasured photograph.
- For a simple dimensioned layout, a measured coordinate brief, or an explicit manual request, native construction can be more direct than recognition. For scanned/complex plans use the [floorplan handoff](references/floorplan-handoff.md). Identify the intended model/pages in a brochure; do not recognize a whole mixed product page as one floorplan.

## Connect and choose the workflow

In a Planner 5D MCP App, follow `planner5d-native-app`: discover with `get_planner5d_tools`, then wrap native reads/actions in `read_planner5d` or `change_planner5d` with the current panel/document IDs and a stable operation ID. Open the existing Planner app once and wait for the authenticated native tools. Navigation remains available across pages: `goToEditor`, `goToEditorProject`, and `goToSpaces`. For a new design from Spaces, use `projectCreateScene` and then `goToEditorProject` with the returned hash, or enter the editor with `goToEditor` and use `editorCreateScene`. After navigation, refresh the tool list and require `editorGetContext` to identify the intended editable project before scene writes. Missing editor tools in Spaces means the editor has not been opened; it is not a reason to replace the requested Planner project with a local PDF. If the host cannot discover tools after the app connects, report that exact integration blocker and preserve the brief.


- Use the connected Planner 5D app tools or the requested browser tab and its public WebMCP tools. Read `getWebMcpGuide` once, then request help for only the relevant registered tool names, at most eight per call. The live schemas take precedence over examples here. Tool availability differs between Spaces, login, and the loaded editor.
- In an opened editor, start with `editorGetContext({})`: bind the task to the exact project hash, floor, `canEdit`, and revision. Request `includeCamera:true` only when already in 3D and the camera is needed. Replace captured handles after navigation or a registration change. Do not bypass a missing tool with private editor state or an application API mutation.
- Reuse the signed-in account. If login is required, use the normal login flow and the authorized mailbox for its current OTP. Do not adopt a staging identity, test card, or credential from a guide for production.
- The separate `planner5d-floorplan-recheck` skill provides the full measured comparison/correction procedure when installed. If absent, follow the floorplan handoff reference without treating a finished recognition as proof of fidelity.
- Recognition accepts supported 2D plan images/PDF/CAD, not arbitrary 3D scan files or segment lists. For measured scan geometry, derive a native room plan from the supplied coordinates and topology; use a supplied 2D plan for recognition only when that route matches the request.
- For a new design, plan its shell and access before calling `projectCreateScene` from Spaces, or `editorCreateScene` from an editor. No starter project is necessary. Extend an existing scene with native room tools; do not replace its document merely to add a room.

## Build editable rooms and walls

Read [room construction](references/room-construction.md) when constructing, correcting **or assessing** room dimensions, walls or opening fit. Its measurement and fit checks also apply to read-only audits.

Use native rooms with their visible perimeter walls for ordinary enclosed spaces. Reserve partitions for actual independent walls, half walls, or explicitly requested scan geometry. Do not make hidden-wall floor polygons plus a second set of partitions as a shortcut for a normally editable home. Preserve special constructions that the existing design actually needs.

In the default 2D plan view, X increases to the right and Y increases downward: top is smaller Y, bottom is larger Y. Map any source north arrow or front facade explicitly; screen top is not necessarily geographic north. Use this frame consistently for room placement and for deciding which walls are shared versus exterior. A 3D camera orbit does not change world coordinates. Confirm the arrangement in the 2D view before placing openings.

Keep one coordinate plan for all floors and shared boundaries. Position APIs use **world X/Y centimeters**, with Z vertical; native property values use their returned `units`. Read creation's translation and actual outlines before placing anything. For room lengths, inspect walls with `fields:["geometry","properties"]`: `editorGetSceneMeasurements` supplies areas/counts, not clear spans. Establish whether the native `length` is an interior or path measurement before comparing it with the brief.

Make an access graph: entrance → hall/living → each enclosed room, using actual openings. Adjacency alone does not give access. Attach a shared-wall opening once with a discovered `wallId`. Its offset locates the opening **center along the wall path**, not its near edge: for a centered opening use half the inspected path length, not half the usable wall `length`, and do not subtract half the opening width. Check its center and full model extents against corners in 2D/3D. Frame/model bounds do not establish a clear aperture width; an exact opening-width claim needs matching evidence. Multiple room-owned wall records can represent a legitimate shared wall.

## Generate kitchens

For a complete kitchen layout, use `editorKitchen` when advertised. Discover its schema, call `{"action":"capabilities"}` through its JSON-string `request`, then generate with the current project hash, scene revision, a stable requestId and the actual roomId. Use returned configuration/model capabilities for wall runs, required functions, connected corners and rows. Do not replace this workflow with a preassembled catalog kitchen or manual cabinet placement; those routes require an explicit request for particular catalog objects or an accepted approximation when the generator is unavailable.

Inspect the nested calculation and application results. A completed operation with `no_solution` or a partial application is not a finished kitchen. Existing furniture reserves obstacle intervals: for a requested replacement, remove only the verified obsolete kitchen objects with the exact-selection gate, then calculate again with a new requestId for the changed scene. Preserve valid openings and unrelated furniture. Verify the applied module IDs, functional requirements, remaining gaps and 2D/3D result before claiming success.

## Work efficiently

- Keep a compact map of semantic labels → returned IDs, target hash, current revision, and unfinished operations. Keep full results locally; return only decision-relevant fields and emit image blocks separately.
- Prefer scoped inspection over repeated full documents. `editorListObjects` pages at up to 100 items; inspect up to 50 IDs together. Set only returned editable property keys and string values; room naming uses `customName` when exposed, not guessed `name`. Native room-type labels may already satisfy the brief.
- Batch catalog searches by role and compare shortlisted assets in one contact sheet. Pick geometry and function before finish. For exact products preserve supplied dimensions; read actual applied sizes and account limits.
- Use `editorAddRooms` for up to five related room additions and `editorPlaceCatalogItems` for up to 25 placements. Omit `roomType` until an ID is known from `editorListRoomTypes`; room names are not type IDs. Use `editorUpdateObjects` for coherent edits with a current revision. Serialize mutations; do not fetch the entire scene between each item.
- Inspect a completed receipt before polling. If running, wait on its operation with the documented terminal wait. Inspect the nested business result: completed + partial is not full success. Retain inserted IDs and reconcile them; never repeat a whole partially completed batch under a fresh request key.
- Send only changes needed for the requested state. Do not rewrite a correct thickness, heading or size to repair a different measurement: a setter can clamp a value that creation already preserved. Diagnose the measurement basis and edit the actual discrepancy. `headingDegrees` is floor heading; 3D `aZ` is tilt. If native heading requires 2D, switch view and correct the existing object through the supported heading tool. Do not retry an access denial or weaken checks.
- Selection may expand to a group. Do not call `remove` unless `editorGetSelectionActions.selected` is nonempty and matches the intended removal IDs exactly. Use an available native `ungroup`, reselect the **same saved target ID** and recheck selection before removing it; finish that target before switching groups. Clearing selection does not ungroup. If the gate cannot be satisfied, leave the group intact and report the blocker; do not delete and recreate wanted companions.

## Verify and finish

For measured or reference-led work, keep a compact acceptance record: requested target and basis, observed value, evidence, and passed/failed/unverified status. At shell and final checkpoints, act on each discrepancy: correct it through a supported operation or retain the concrete blocker. Do not explain away a mismatch as a different measurement basis without evidence establishing that basis. Build the handoff from all unresolved defining checks, not just the last defect noticed; a green native validator cannot override a failed source check.

At shell and final milestones, run scoped `editorValidateScene` and inspect useful 2D/3D views. Start previews with `editorGetScenePreview({view:"2d",scope:{kind:"floor"},maxImageBytes:1000000})`, then the corresponding 3D view. Default width is 768, maximum 1024. Inspect actual image blocks and readiness, not serialized base64. A preview switches view and performs a bounded readiness wait; wait separately only for reported pending IDs, with 3D active for `ready3d`. For unreadable detail, use a relevant smaller scope. Repeat views/checks only to resolve a change or missing evidence.

A clean structure result does not check intended door connections, circulation, door swing, wall clearance or exact mesh contact. After a local change, inspect the affected region and retain unresolved warnings.

For a numeric furniture-clearance claim, read [fit evidence](references/fit-evidence.md). After the 3D preview is ready, inspect the relevant furniture again with `fields:["geometry","properties"]`; a previous response with `bounds:null` or `model_3d_required` cannot support measured gaps. Record the gaps from those loaded bounds and the established interior boundary. Report the requested minimum and limiting side, without an invented maximum/range. If the evidence is missing, say the clearance is unverified.

Moving a room carries its contents: re-read their coordinates before subsequent moves. When repairing geometry/history, verify Undo/Redo on the actual room, walls, and members, then leave the intended final state.

Use normal autosave. `persistence.state=idle` with `serverAcknowledgement=not_checked` is not a save receipt. For a requested persistence test, verify a fresh load in a second tab after autosave and record what survived. Routine edits do not need repeated reloads.

Return the project link (using the native result URL or the connected Planner origin with the verified project hash), requested outcome, measured checks, and concrete unresolved issues. Keep credential-bearing URLs and signed access tokens out of reports. Skills cannot repair a renderer or native command defect; retain a minimal reproduction when one blocks the requested result.

If the brief asks how furniture looks in this interior or asks for a render after plan import, continue from the verified furnished scene through `planner5d-ai-render`. Use the same project and imported product, inspect the composed source view, and return the completed render with the editable project. Keep measured fit and image fidelity as separate outcomes.

Referenced files: 5