feat(ops): add dual-tier worker timeout, deadlock detection, and workflow fixes

- Add timeout: 2700000 (45min) to Agent() call in phases.md Step 7
- Add timeout handling in Step 8 with flowctl fail for timed-out workers
- Add heartbeat instruction to worker Phase 5 (every 60s)
- Add deadlock detection in Step 3 with cause classification
- Add no-progress watchdog (stops after 2 unchanged waves)
- Add spec hash comparison at wave start with warning on mismatch
- Change approval timeout from silent skip to flowctl block

Task: fn-110-workflow-reliability-and-performance.5

Author: z23cc

agents/worker.md

@@ -89,7 +89,7 @@ SendMessage(to: "coordinator", summary: "Blocked: <TASK_ID>",
    ```
    - On `status: approved` → proceed with the edit.
    - On `status: rejected` → emit a `Blocked:` summary and skip the file.
-   - On timeout → note in completion evidence and continue with alternative approach.
+   - On timeout → mark task as blocked: `$FLOWCTL block <TASK_ID> "Approval timeout: requested access to <path>"` and continue with alternative approach.
 
    **Via SendMessage (non-Teams mode):**
    ```
@@ -192,6 +192,16 @@ For each entry returned, fetch its content and include verbatim in your context:
 ```
 These are lightweight narrative handoffs from earlier tasks in this epic — read them to understand what upstream work surprised the previous worker, what decisions they made, and what gotchas to watch for. Skip gracefully if the list is empty (new epic) or if `outputs.enabled` is false.
 
+**Spec hash verification (mid-wave protection):**
+If the coordinator passed a `SPEC_HASH` value in your prompt, compare it against the current spec:
+```bash
+CURRENT_HASH=$(echo "$(<FLOWCTL> cat <TASK_ID>)" | shasum -a 256 | cut -d' ' -f1)
+if [ "$CURRENT_HASH" != "$SPEC_HASH" ]; then
+  echo "Warning: spec for <TASK_ID> changed since wave start (hash mismatch)"
+fi
+```
+Continue execution but note the mismatch in evidence.
+
 Parse the spec carefully. Identify:
 - Acceptance criteria
 - Dependencies on other tasks
@@ -320,6 +330,12 @@ echo "BASE_COMMIT=$BASE_COMMIT"
 ```
 Save this - you'll pass it to impl-review so it only reviews THIS task's changes.
 
+**Heartbeat signaling:** Every 60 seconds during implementation, call:
+```bash
+$FLOWCTL heartbeat --task $TASK_ID
+```
+This signals liveness to the coordinator. The coordinator checks heartbeats every 3 minutes. If no heartbeat is received within that window, the worker is considered hung and may be terminated.
+
 ### Wave-Checkpoint-Wave Execution
 
 When a task touches **3+ files**, use the Wave pattern to parallelize file I/O. This achieves 3-4x speedup over sequential reads/edits.
@@ -376,7 +392,7 @@ If more files remain (tests, docs, config), repeat: parallel read → checkpoint
           message: "Access request for <TASK_ID>.\nFile: <path>\nReason: <why needed>\nCurrent owner: <task-id if known>")
         ```
      2. Wait for `status: approved`/`rejected` (API) or "Access granted:"/"Access denied:" (fallback)
-     3. If timeout, skip the file and note it in your completion evidence
+     3. If timeout, mark task as blocked: `$FLOWCTL block <TASK_ID> "Approval timeout: requested access to <path>"` and continue with alternative approach
      4. On rejected/denied, find an alternative approach that stays within your owned files
 
 **This is not optional.** Do not bypass this check even if you believe the lock system will catch violations. Self-enforcement is the primary guard; hooks are the backup.
@@ -719,7 +735,7 @@ If you catch yourself thinking any of these, stop and follow the correct action:
 | Thought | Reality |
 |---------|---------|
 | "I need to edit a file not in OWNED_FILES" | Create a `flowctl approval create --kind file_access` (or fallback "Need file access:" message) and WAIT. Do not edit. |
-| "The coordinator isn't responding" | `approval show --wait --timeout 600` blocks ≤10min; on fallback path wait 60s. If timeout, skip the file and note it in evidence. |
+| "The coordinator isn't responding" | `approval show --wait --timeout 600` blocks ≤10min; on fallback path wait 60s. If timeout, call `$FLOWCTL block <TASK_ID> "Approval timeout: requested access to <file>"` and continue with alternative approach. |
 | "I'll just edit it, the lock check will catch it" | Don't rely on hooks. Self-enforce OWNED_FILES. |
 | "TEAM_MODE doesn't matter for this task" | If TEAM_MODE=true is set, follow the protocol. Always. |
 | "It's a small edit, nobody will notice" | Ownership violations break parallel safety for everyone. |

skills/flow-code-work/phases.md

@@ -134,6 +134,34 @@ After restarts, find ready tasks normally:
 $FLOWCTL ready --epic <epic-id> --json
 ```
 
+**Deadlock detection:** If ready tasks = 0 AND no tasks are in_progress, check for stalled state:
+
+```bash
+TASKS_JSON=$($FLOWCTL tasks --epic <epic-id> --json)
+FAILED=$(echo "$TASKS_JSON" | jq '[.[] | select(.status=="failed")] | length')
+BLOCKED=$(echo "$TASKS_JSON" | jq '[.[] | select(.status=="blocked")] | length')
+TODO_WITH_DEPS=$(echo "$TASKS_JSON" | jq '[.[] | select(.status=="todo" and (.dependencies | length > 0))] | length')
+```
+
+Classify the stall:
+- If `FAILED > 0`: "Epic stalled: $FAILED tasks failed, blocking downstream. Consider restart or skip."
+- If `BLOCKED > 0`: "Epic stalled: $BLOCKED tasks blocked. Check block reasons."
+- If all remaining are `todo` with unmet deps: "Possible circular dependency. Run `$FLOWCTL validate --epic <epic-id>`."
+
+Stop the wave loop in any of these cases.
+
+**No-progress watchdog:** Track `completed_count` at the start of each wave:
+
+```bash
+COMPLETED_COUNT=$(echo "$TASKS_JSON" | jq '[.[] | select(.status=="done")] | length')
+```
+
+If `completed_count` is unchanged after 2 consecutive waves:
+```
+"No progress detected across 2 waves. Stopping."
+```
+Stop the wave loop.
+
 Collect ALL ready tasks (no unresolved dependencies). If no ready tasks, check for completion review gate (see Step 10 below).
 
 ### Step 4. Readiness Check
@@ -144,6 +172,18 @@ Before starting, validate each task spec is implementation-ready:
 $FLOWCTL cat <task-id>
 ```
 
+**Spec hash snapshot (mid-wave protection):**
+
+Record a content hash for each task spec at wave start:
+```bash
+SPEC_HASH_<task-id>=$(echo "$($FLOWCTL cat <task-id>)" | shasum -a 256 | cut -d' ' -f1)
+```
+Workers compare this hash during re-anchor (Phase 2). If the spec changed since wave start, log:
+```
+"Warning: spec for <task-id> changed since wave start (hash mismatch)"
+```
+Continue execution but note the mismatch in evidence.
+
 **Check these fields exist and are non-empty:**
 - `## Description` — what to build (not just a title)
 - `## Acceptance` — at least one testable `- [ ]` criterion
@@ -238,6 +278,7 @@ Agent({
   team_name: "flow-<epic-id>",
   isolation: "worktree",
   run_in_background: true,
+  timeout: 2700000,
   prompt: "$WORKER_PROMPT
 
     TASK_ID: <task-id>
@@ -263,6 +304,12 @@ Spawn ALL ready task workers in a SINGLE message with multiple Agent tool calls.
 
 Wait for all workers to complete.
 
+**Worker timeout handling:** If a worker times out (exceeds the 45-minute ceiling):
+```bash
+$FLOWCTL fail <task-id> "Worker timeout after 45min"
+```
+This triggers the retry logic in the task lifecycle (`up_for_retry` if retries remaining). Log the timeout and continue processing other workers in the wave.
+
 **Merge-back** (after all workers return):
 
 ```bash