ultracode-statuslisted

# UltraCode Status ## Respect explicit Help precedence If the request explicitly invokes `$ultracode-help` or `ultracode-help`, do not inspect live state. Read `../ultracode-help/SKILL.md` and answer `status` as a read-only Help topic. Explain the current state so the user can decide whether to continue, redirect, pause, or stop. ## Stay read-only Do not write a status file, run a write-producing build or test, regenerate adapters, or change configuration. Reading collaboration state, plans, Git status, `.ultracode/config.json`, and `.ultracode/status.md` is allowed when available. Read `../ultracode/references/command-interface.md` and `../ultracode/references/control-and-status.md` completely. Read `../ultracode/references/swarm-protocol.md` when delegated jobs or findings exist. Read `../ultracode/references/feature-verification.md` when a durable feature verification plan exists or is referenced by the task. Status is the detailed diagnostic view; Flow is the concise live control view. When the user explicitly invokes `$ultracode-status`, stay in the detailed view. For an unqualified request for a fast active-work snapshot, prefer `$ultracode-flow`. Keep status for complete job history, files, findings, validation, persistence, and staleness analysis. ## Reconcile sources Use this precedence: 1. current live task and collaboration state; 2. current lead plan and known validation results; 3. persisted `.ultracode/status.md` snapshot; 4. repository history only wh