engineer-graphlisted

# Engineer Graph Use the `graph-engineer` MCP tools to turn the refined user request into a safe execution graph. The runtime owns scheduling and permissions; model nodes own reasoning and bounded task execution. ## Workflow 1. Preserve intent with Prompt Refiner. 2. When the user is verifying an install or upgrade, call `get_runtime_info` first. Do not start a graph while it reports `reload_required` or `invalid_manifest`; reload or reinstall the host and verify `current`. 3. Call `plan_graph`. Use `plan_only` when the user asked to inspect or design a plan. 4. Call `validate_graph` before executing a graph supplied or edited by a model. 5. Use direct execution for a small focused request. Use a graph for independent work items, multiple evidence sources, cross-checking, or staged implementation. 6. Use `run_graph` only for short graphs. For multi-agent or potentially long graphs, call `start_graph`, retain its job ID, and poll `get_graph_run` until it reaches a terminal state. 7. Use the narrowest autonomy level that can complete the task. 8. If the result is `needs_confirmation`, show the exact gated action and wait. Never approve a gate on the user's behalf. MCP cannot approve gates; the user continues explicitly through the CLI. 9. Report the final status, verifier outcome, repair rounds, and audit path. ## Invariants - Never add objectives, permissions, credentials, or external actions. - Never bypass validation, budgets, or a human gate. - Never turn a gr