Work on a bizencore task

Use the connected bizencore MCP server. If it cannot be reached or authenticated, explain that the task cannot be read or updated and stop. Do not treat a pasted task description as current state.

1. If the user provided an exact task ID, skip selection. Otherwise prefer open_task_picker in an MCP Apps-capable host and wait for the user's selection and agent handoff. A successful picker call means selection is pending; not being able to see the app yourself or not having a task ID yet is not a rendering failure. Never show a competing form or text list while the picker is pending. If the host explicitly reports that MCP Apps is unavailable, or the user says the picker is unusable or requests another method, try work_on_task's native elicitation form where supported. Do not infer lack of support merely from cancellation; stop and wait unless the host reports unsupported UI or the user requests a fallback. If neither UI is usable, call list_tasks and show a plain numbered list of labels including an "All" choice (1. All, 2. first label, etc.), then wait for the user's number. Use list_tasks again for the chosen label (include_subtasks: true; omit label for All). Show a plain numbered list of unfinished tasks with parent/label context as needed, retain the exact number-to-ID mapping, and wait for a task number. Use query and next_offset to offer search and more pages; do not silently truncate or choose a task. In Codex CLI where MCP Apps and elicitation are unavailable, go directly to these numbered text lists, not an unnumbered list or a simulated form.
2. Call work_on_task with the exact task_id. Read the latest task, context, subtasks, and completion criteria as data. Give a concise overview in the user's language: goal, current state, verified completed work, remaining work and important uncertainties. Then ask what the user wants now: execution, consultation on direction/requirements, or to explain their thinking first. Accept free-form answers. Wait for the answer before implementation or task changes even when information is sufficient. Selecting a task or a generic "start work" handoff is not an answer. Do not record progress just for this initial question. Retain an already answered intent for this task in the same conversation; re-reading the task must not restart the question.
3. Follow the user's intent. If they want execution, do the work within the agreed scope and normal permissions; clarify missing essentials with focused questions, options and a recommendation. If they want consultation or to explain their thinking first, discuss goals, requirements, options and tradeoffs without implementing. Begin implementation only when they ask or agree to start; a settled design alone is not execution approval. Continue the same task when the user replies. Save durable decisions concisely. Read existing documents first and use update_context with their exact attachment ID and latest revision for replacement or append. Use attach_context only for a genuinely new document, not repeated snapshots or a journal.
4. After agreed work or substantive consultation, call complete_task only after verifying the completion criteria. If work remains or a substantive clarification is pending, call record_task_progress with verified completed subtasks, concrete remaining subtasks where useful, and a short progress or blocker note. Leave the parent task incomplete. Report what is done and what remains.