project-osmos

Resolve Lakehouse context.

• Preserve any workspace or Lakehouse names the user already supplied. Never discard supplied names and ask for a URL instead.
• For public production, use Microsoft Fabric Skills to resolve names to IDs:
  • When the Lakehouse name is known but its workspace is not, use search-consumption-cli with item type Lakehouse; use the returned item and workspace IDs.
  • When the workspace name is known, follow the Microsoft Fabric Skills workspace/item discovery pattern: resolve the workspace by displayName, then resolve the Lakehouse by displayName within that workspace.
  • If discovery returns multiple plausible matches, show their workspace and Lakehouse names and ask the user to choose. Never guess.
• Build the context choice from explicit user-supplied names first; otherwise use any service-validated workspace or Lakehouse context exposed by the local host.
• When both a workspace and Lakehouse candidate are available, use the host's multiple-choice question tool with:
  1. Use workspace <workspace_name>, Lakehouse <lakehouse_name>
  2. Use workspace <workspace_name> and choose a different Lakehouse
  3. Provide a Lakehouse URL
  4. Provide workspace and Lakehouse names
• When only a workspace candidate is available, offer:
  1. Use workspace <workspace_name> and choose a Lakehouse
  2. Provide a Lakehouse URL
  3. Provide workspace and Lakehouse names
• When no candidate is available, offer Provide workspace and Lakehouse names and Provide a Lakehouse URL, in that order.
• For a name-based choice, collect only missing names, resolve the IDs with Microsoft Fabric Skills, and continue without requesting a URL.
• When choosing a different Lakehouse in a known workspace, ask only for the Lakehouse name and resolve it with Microsoft Fabric Skills.
• If the user chooses Provide a Lakehouse URL, ask for the full URL and parse it with URL parsing.
• Never ask for workspace and Lakehouse IDs as separate startup fields.

Validate Lakehouse context. Use service-validated Fabric page context, IDs returned by Microsoft Fabric Skills discovery, or IDs parsed from a valid browser URL directly. Validate supplied portal URLs against URL parsing and the URL parser example before authentication or task creation (public URLs require supported HTTPS hosts). Ask for corrected input only when the selected method cannot resolve a workspace and Lakehouse or provides an invalid portal URL.

Resolve names and optional resource tenant. Use the current Azure CLI session by default. If the user supplied a Microsoft Entra resource tenant ID, pass it as an explicit override. Ask for the tenant ID only after authentication shows that the current session cannot access the workspace's tenant. Then resolve workspace_name, capacity_id (from the API capacityId field), and lakehouse_name using Authentication and route construction. Surface lookup failures; do not fall back to (unknown) or substitute GUIDs.

Collect the outcome. Reuse a supplied outcome verbatim. Otherwise ask What do you want to accomplish? After context resolution, ask one optional "Anything else I should know?" prompt. Use ask_user with the first choice "No, nothing else" and freeform enabled so the user can either skip quickly or type extra context. Keep the user's complete outcome and guidance verbatim. Never start from an unsubmitted draft; acceptance in the intake step is the authorization to create and start the task.

Run intake and compile the handoff contract. Follow Operational intake flow, Write and safety options, Output and reasoning options, and Intake reconciliation and handoff. Extract explicit requirements before applying task-type defaults, collect every dependent value, and block dispatch on unresolved conflicts. Compose the instruction with the verbatim ## User outcome first and a self-contained ## Execution plan immediately below it. Send the exact same composed instruction in PUT /{taskId} and the initial user message; never send bare option labels without their executable meanings. Keep generated operational text at 2,500 characters or fewer and the complete service instruction at 9,500 characters or fewer. Before PUT, run "${PYTHON_RUNNER[@]}" skills/project-osmos/scripts/check-instruction-length.py --path <instruction-file> --limit 9500. If the complete handoff does not fit, preserve it exactly using Oversized instruction fallback; never truncate, paraphrase, or ask the user to shorten it.

Authenticate and construct the task route. Resolve the SparkCore task host and MWC token with Authentication and route construction, using the optional resource tenant override when one was supplied.

Create and run one task. Use one generated task ID for any oversized-instruction upload, create, message, run, retries, and follow-ups. Follow Task lifecycle for endpoint shapes and response handling.

Launch the task view and print the run card.

• For every user, follow Task page URL construction and run scripts/launch-task-page.py with the environment, workspace, Lakehouse, and task IDs. No enrollment signal is required. Pass the available Fabric page/Lakehouse URL as --source-url; if none is available, production uses the canonical Fabric portal and a private environment must supply its trusted portal base URL. Print task_page_url as Task page and surface it as a clickable Fabric link in chat. The helper's JSON contains prompt-free structured telemetry for task creation, launch result, URL fallback, workspace, task, and environment.
• A browser launch result of failed or timed_out is non-fatal (opening is bounded to three seconds). Print the helper's warning and canonical URL; the remote task continues and bounded task monitoring must continue. --no-open reports not_attempted without a failure warning. Never substitute a local HTML path for the Fabric link.
• If the helper cannot build a URL (exit 2), print the error and task ID, leave task_page_url unset, set the run card's Task page value to Unavailable (URL validation failed), and continue bounded task monitoring anyway; never print an empty link or literal <task_page_url>. Correct the validated portal context and rerun the helper for the same task; never recreate it or guess a private portal host.

Use all listed rows rather than inventing a reduced summary.

Mediate follow-ups. Follow Task continuation. Continue the existing task; never create a replacement. Re-resolve the route and acquire fresh authentication as needed, then use scripts/post-user-message.py --output json.

Report from the task APIs. Follow Task monitoring. Fetch both GET /{taskId}/messages and GET /{taskId}, normalize status, relay unseen assistant messages, and quote service evidence instead of guessing. Include the Fabric task link when the user needs to view progress.