fix: prevent nested .fusion/.fusion dir from PluginStore path bug

PluginStore's constructor treats its rootDir arg as a project root and
internally appends `.fusion` before opening the SQLite DB. Several CLI
call sites were passing the already-resolved `.fusion` directory,
producing a doubled `.fusion/.fusion/fusion.db` that the dashboard
process kept recreating on every project load.

Pass the project root instead so the DB lands in the canonical
`.fusion/fusion.db` alongside the rest of the project's state.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

docs/agents.md

@@ -311,12 +311,23 @@ fn agent mailbox AGENT-001
 
 When messaging tools are enabled for an agent, heartbeat runs check for unread mailbox messages during execution regardless of the trigger type. This ensures agents can see and respond to incoming messages without needing an explicit wake-on-message trigger.
 
+### Reply Linking Contract
+
+Mailbox replies use `message.metadata.replyTo.messageId` as the stable reply link.
+
+- `read_messages` includes each message ID in its human-readable output so agents can target a specific message.
+- `send_message` supports `reply_to_message_id`; when provided, the sent message is stored with `metadata.replyTo.messageId`.
+- Heartbeat prompts explicitly instruct agents to include `reply_to_message_id` when replying.
+
+The dashboard mailbox UI also uses the same metadata contract when users click **Reply**, so user and agent replies share one threading model.
+
 ### How It Works
 
-1. **Message Prefetch**: When `messageStore` is available, heartbeat runs fetch up to 10 unread inbox messages for the agent
-2. **Prompt Injection**: Pending messages are injected into the execution prompt with sender and timestamp information
-3. **Mark as Read**: After successful heartbeat completion, messages are marked as read
-4. **Failed Runs**: If the heartbeat execution fails, messages remain unread for retry on the next run
+1. **Message Prefetch**: When `messageStore` is available, heartbeat runs fetch up to 10 unread inbox messages for the agent.
+2. **Prompt Injection**: Pending messages are injected into the execution prompt with message ID, sender, and timestamp information.
+3. **Reply Guidance**: System instructions remind agents to reply with `reply_to_message_id` for linked threads.
+4. **Mark as Read**: After successful heartbeat completion, messages are marked as read.
+5. **Failed Runs**: If the heartbeat execution fails, messages remain unread for retry on the next run.
 
 ### Message Response Modes
 

docs/workflow-steps.md

@@ -104,18 +104,35 @@ The revision block replaces any prior revision instructions (no accumulation).
 
 Not all workflow failures are revision requests:
 
-- **Revision requested**: Implementation needs changes → routes back to executor
-- **Hard failure**: Unrecoverable issue → moves to `in-review` with `failed` status
+- **Revision requested**: Implementation needs changes → routes back to executor in-place while keeping the task in `in-progress`
+- **Hard failure**: Treated as remediable until retries are exhausted; the executor injects feedback and sends the task through `todo → in-progress` for a fresh remediation pass
 
-Use revision requests when the implementation is wrong but fixable. Use hard failures only for genuine blockers (e.g., required files are missing, test infrastructure is broken).
+#### Pre-merge hard failure remediation flow
+
+For pre-merge workflow hard failures, executor behavior is:
+
+1. Retry the failing check up to `MAX_WORKFLOW_STEP_RETRIES` within the same execution lifecycle
+2. On retry exhaustion, add a steering comment with failure details and inject a `Workflow Step Failure` section into `PROMPT.md`
+3. Reopen only the last implementation step (`pending`) so prior completed work remains preserved
+4. Schedule `todo → in-progress` after guard unwind, triggering a fresh executor remediation run
+
+Tasks are not parked in `in-review` for this remediable path unless additional terminal failures occur.
+
+#### Self-healing recovery for parked review tasks
+
+If a task is found in `in-review` with failed pre-merge workflow results and no active executor, self-healing can auto-revive it (bounded by `maxPostReviewFixes`) by replaying the same remediation send-back flow.
 
 ## Viewing Results
 
-Task detail modal includes a **Workflow** tab when workflow data exists.
+Workflow status is visible in multiple places:
 
-You can inspect:
+- **Task cards**: workflow checks are shown after normal implementation steps in the step list; each workflow row is labeled (`Workflow · Pre-merge` / `Workflow · Post-merge`) and progress counts include both implementation and workflow checks
+- **List view (desktop + mobile)**: progress labels/bars use the same unified step model as task cards
+- **Task detail modal**: includes a **Workflow** tab when workflow data exists
 
-- pass/fail/skipped status
+In the Workflow tab, you can inspect:
+
+- pass/fail/skipped/running status
 - outputs/findings
 - timing metadata