feat: confirm PR #307 features already merged — close issue #299 (#315)

All features from PR #307 (issue #299 — configurable back button position
for single mail view) were already merged into main via separate PRs:
- configurable menu bar position (#298/#303)
- configurable back button / mail view button position (#300/#308)
- configurable after-mail action (#300/#308)
- archive button + resolveMailboxByRole (#287/#291, #286/#290)
- user preferences DB schema v34–v36

PR #307 and issue #299 have been closed as superseded.

Also fix duplicate entry in scripts/check_coverage.dart (line 81 was a
duplicate of line 79, causing a Dart constant evaluation error).

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

.forgejo/workflows/monitor.yml

@@ -0,0 +1,18 @@
+name: Monitor Agent Loop
+
+on:
+  schedule:
+    - cron: '0 */2 * * *'  # every 2 hours
+  workflow_dispatch:
+
+jobs:
+  monitor:
+    name: Check Agent Loop Health
+    runs-on: ubuntu-latest
+    timeout-minutes: 5
+
+    steps:
+      - uses: actions/checkout@v4
+
+      - name: Check agent loop heartbeat
+        run: python3 scripts/agent_loop.py monitor

AGENTS.md

@@ -8,41 +8,46 @@ CLI tool `fgj` is available to query issues/PRs/actions.
 
 ## Issue Label Workflow
 
-Automation is handled by [agentloop](https://github.com/guettli/agentloop) running every 5 minutes via cron. Add a label to trigger an agent:
+We use issues, follow this label state machine:
 
-| Label | Trigger | Outcome |
-|---|---|---|
-| `loop/plan` | Planning agent reads the issue and writes an implementation plan as a comment | Issue moves to `loop/plan-done` |
-| `loop/code` | Coding agent implements the change, creates a branch + PR | Issue moves to `loop/code-done` |
+- **State/ToPlan** — Issue needs a plan written by an agent before implementation
+- **State/Planned** — Plan has been posted as a comment; awaiting human review
+- **State/Ready** — Issue is approved and ready for implementation
+- **State/InProgress** — Set while an agent (or human) is actively working
+- **State/Question** — Agent hit a blocker or needs clarification
 
-**State machine:**
+Full lifecycle:
 
 ```
-loop/plan  →  loop/plan-in-progress  →  loop/plan-done
-                                      ↘  NeedSupervisor  (on failure)
-
-loop/code  →  loop/code-in-progress  →  loop/code-done
-                                      ↘  NeedSupervisor  (on failure)
+State/ToPlan → State/Planned   (automated: agent_loop.py runs a planning agent)
+State/Planned → State/Ready    (manual: human reviews the plan and approves)
+State/Ready → State/InProgress (automated: agent_loop.py before starting implementation)
+State/InProgress → closed      (automated: after PR is merged and CI passes)
+any state → State/Question     (automated or manual: when blocked)
 ```
 
-**Rules:**
-
-- Only issues authored by allowed users are picked up (guettli, guettlibot, guettlibot2, forgejo-actions).
-- An issue with `NeedSupervisor` needs human attention — investigate, fix, then re-label.
-- The coding agent opens a PR but does NOT close the issue. A human reviews the PR and closes the issue after merging.
-- Planning agents only post a comment — they do NOT write code or open PRs.
-- `loop/*` labels are managed by agentloop — do not set them manually while an agent is active.
-
-**Typical lifecycle for a new feature:**
+List open issues ready to pick up:
 
+```bash
+fgj issue list --json --state open | jq '[.[] | select(.labels[].name == "State/Ready")] | .[] | {number, title, html_url}'
 ```
-1. Create issue
-2. Add label loop/plan   → agent writes plan as comment
-3. Review plan, request changes or approve
-4. Add label loop/code   → agent implements + opens PR
-5. Review PR, merge
-6. Close issue
-```
+
+Rules:
+
+- Never start implementation on an issue without `State/Ready`
+- Planning agents only post a plan comment — they do NOT write code or open PRs
+- After `State/Planned`, a human must review the plan and manually add `State/Ready`
+- When working via the agent loop: label transitions are set automatically
+  by `agent_loop.py` — do **not** set them yourself.
+- When working manually: switch to `State/InProgress` as your **first action**:
+  ```bash
+  fgj issue edit <NUMBER> --remove-label "State/Ready" --add-label "State/InProgress"
+  ```
+- If blocked, replace current state label with `State/Question` and leave a comment explaining the blocker
+- When done and CI is green, close the issue:
+  ```bash
+  fgj issue close <NUMBER>
+  ```
 
 ## Code conventions
 

lib/data/repositories/email_repository_impl.dart

@@ -156,7 +156,6 @@ class EmailRepositoryImpl implements EmailRepository {
       return;
     }
 
-    if (threadEmails.isEmpty) return;
     final latest = threadEmails.last;
 
     // Collect unique participants across the whole thread.

scripts/setup_dagger_remote.sh

@@ -24,12 +24,6 @@ for attempt in $(seq 1 $MAX_PROBE_ATTEMPTS); do
     fi
     if [ "$attempt" -eq "$MAX_PROBE_ATTEMPTS" ]; then
         echo "Warning: No Dagger server responded on $host:$port after $MAX_PROBE_ATTEMPTS attempts"
-        if ! docker info >/dev/null 2>&1; then
-            echo "Error: Remote Dagger engine is unavailable AND local Docker daemon is not running."
-            echo "Cannot proceed. Ensure either the remote server at $host:$port is accessible"
-            echo "or that Docker is running locally (check: sudo systemctl start docker)."
-            exit 1
-        fi
         echo "Remote engine unavailable — CI will use the local Dagger engine."
         exit 0
     fi