arbeitsplan-backendlisted

# Which backend runs it A spec that names a backend without a reason gets run in whichever one the session reaches for. That is how a run ends up forced into an agentic workflow by hand. This skill makes the choice from a frozen table and records which row made it, so the compiler can check it. ## Steps 1. **Read `references/backend-selection.md` in full, every time.** It holds the three backends, the ordered decision table, the closed `why` vocabulary and the refusals. Never answer from memory. 2. **Read the run's `workflow.json`** if a runId was given, or the user's description if not. You need three facts from it: does any phase write the shared tree, is the fan-out width fixed, and was anything under test edited in this session. 3. **Walk the decision table top to bottom.** The first matching row decides the backend. Collect every row that matches, not just the first, as `why` ids. 4. **Check the refusals** before answering. `workflow` with a `shared` writer is refused — say which phase and offer the fix: that phase returns its diff as data (`writes: worktree`) and `land_candidate.py` lands it in-session. `workflow` always carries `acknowledgedGaps: ["workflow-tool-unhooked"]`; say what that gap is. 5. **Emit the object** and validate it through the compiler, never by eye: ```bash python3 "${CLAUDE_PLUGIN_ROOT}/scripts/compile_spec.py" --spec analysis/arbeitsplan/<runId>/workflow.json ``` ## Rules - **Never pick `workflow` for a phas