Choose menus for desktop, mobile or app

Use the menu-layout workflow when changing which menu definitions appear on a device and which template presents them. Menu structure, shared item names/URLs, and logo/login options have separate tools listed in the Reference index. Examples are illustrative inputs.

Read the intended device

Select a channel through the directory guide or the bound hosted resource, then call design_menu_layout_get:

{"channelCode":"selected-channel-code","device":"W"}

Use W for desktop web, M for mobile web, or A for app. Inspect the current layout, revision, template capabilities and menu candidates. The selected channel needs a current credential and OWNER/DELEGATEE account and selected-channel roles; the HTTP workflow uses the configured general API origin.

Match the request against each returned template's displayName, consoleLabel, description, appearance and secondaryMenu. For centered desktop text with the console 1400px option, match primaryMenuAlignment:"center" and widthPreset:"1400px"; do not guess from managementName or Fix. The corresponding W1_0006 is usable only when returned.

Get returns the latest 50 menu candidates. Preserve an existing ID in its same slot even if it is missing from those candidates. Do not move an unlisted ID to the other slot or infer that the menu does not exist. The adapter can bind omitted menu ownership to the verified request channel; explicit foreign/null/malformed ownership remains an error. Stop on a response-contract error instead of inventing a layout.

Specify the full desired layout

Call design_menu_layout_apply with the same channel/device revision. Every request must explicitly supply the template and both slots. The following template has no Secondary slot, so null is required:

{
  "requestId":"example-desktop-layout-001",
  "channelCode":"selected-channel-code",
  "device":"W",
  "expectedRevision":"0000000000000000000000000000000000000000000000000000000000000000",
  "menuTemplateType":"W1_0001",
  "primaryMenuId":101,
  "secondaryMenuId":null,
  "dryRun":true
}

Replace all placeholders with current returned values and an available template. This example also clears any previous Secondary connection; use it only when that is intended. To change only a template while retaining two menus, choose an available template with secondary support and explicitly preserve both current IDs. Menu IDs and menu-item IDs are different.

A new dry run returns a body plan with no task or write. Inspect it, then preserve its ID and business inputs and set dryRun:false for the intended publication. A repeated dry run for an existing job returns saved progress rather than a fresh plan. Dry-run results do not provide enough route context in this revision and report unavailable navigation, with no home substitute.

Verify and recover

The workflow rereads, checks the revision and choices, sends at most one update during that attempt if necessary, then rereads the layout. MENU_DESIGN_APPLIED with confirmed menu_design_read establishes observed stored connections. There is no changed flag.

For partial or uncertain results, inspect the original task using task_status:

{"taskId":"example-desktop-layout-001","taskType":"menu-design"}

To continue the original operation, use the same pair with task_resume. A definitely rejected write can be retried from prepared state after its cause is resolved. An uncertain sent write is read back first and is not repeated while its outcome is unknown. A read failure after sending is not proof that the layout stayed unchanged; do not bypass recovery by replacing the request ID.

Completed apply/resume responses are historical. Call get for current layout state. Repeat the whole read/plan/apply sequence with a separate request ID for another device; one device's completion does not imply all devices changed. Revisions provide conflict detection, not an atomic lock or automatic rollback.

Keep actual-dev reads, actual-dev writes/recovery, browser rendering, actual LLM selection and deployed hosted behavior as separate evidence.

Reference index · Layout get · Layout apply · Common results

Saved plan replay

An existing matching task's dryRun returns historical saved plan/progress, historical:true, replayed:true and false current verification. It has no current console/action link and does not read present business state, repeat effects or change the journal. Saved phase/progress and existingPhase aliases remain where applicable. Follow nextStep for a current observation; retain the original task ID for uncertain-outcome recovery. A new task keeps normal fresh-plan validation.

nextStep: design_menu_layout_get retains the original channel and W/M/A device; saved layout body does not validate current candidates.

Saved record identity

Existing apply or dry-run calls and task status/resume require both the saved task ID and saved input requestId to match the requested ID. A mismatching or malformed saved identity returns TASK_STATE_UNVERIFIED before workflow context or business-state reads. Preserve the original record for inspection; do not rename/edit it, try its embedded ID or create a replacement request to bypass the error. The workflow does not repair or resend the record. Valid matching records keep their existing recovery behavior.