[Feature Request] System-level enforcement for "promise-to-action" binding in Manager responses

### Bug Description

We identified a reliability gap in HiClaw's Manager agent during long-running tasks.

The core issue is that the Manager can make semantic execution promises such as:

- "我现在开始处理"
- "我去做"
- "我现在直接启动"
- "I'm starting now"
- "I'll execute this task"

but the system does not enforce that these promises are bound to actual execution evidence.

In practice, the Manager may claim that a task has started, while no real execution artifact exists:

- no task_id
- no state_file
- no runner call
- no Worker assignment
- no background process
- no session key
- no pid
- no timeout_at
- no result_path or error_path

This creates four major pain points for long-running work:

1. Task may not actually start

The Manager says it will start, but no tool call, task state, Worker assignment, or background process is created.

2. No progress feedback during execution

During long-running tasks, the admin cannot tell whether the Manager is working, stuck, failed, disconnected, waiting for a tool, or silently doing nothing.

3. Task can get stuck without recovery

Tool calls, background scripts, sub-sessions, Worker handoffs, or review phases may get stuck. The Manager may remain silent or repeatedly hit the same error.

4. Task may finish without final feedback

Even if a background task or Worker task completes, the Manager may fail to proactively report the result to the admin.

We attempted several local workaround mechanisms:

- runner scripts
- state files
- check-active-tasks.sh summary checker
- HEARTBEAT add-ons
- cron-based watchdogs
- P0/P1 test drills
- Worker-chain drill
- promise-action binding documentation

These local mechanisms improve observability after a task is truly started, but they cannot prevent the Manager from making an execution promise without starting anything.

This appears to be an architectural limitation:

> Tool calling is currently a soft constraint.
> The model can choose not to call tools even after claiming that it will.

Expected behavior:

When Manager responses contain execution semantics such as:

- 启动
- 开始
- 执行
- 我去做
- starting
- running
- executing
- I'll start
- I'll run

the system should require corresponding execution evidence, such as:

- task_id
- state_file path
- runner PID
- Worker assignment
- session key
- background process
- timeout_at
- result_path / error_path

If no evidence exists, the system should block, warn, or flag the response.

Suggested solutions:

1. Pre-response hook

Add a pre-response interceptor that scans outgoing Manager messages for execution semantics and requires corresponding task evidence before allowing the response.

2. Built-in task runner command

Provide an atomic command such as:

```bash
openclaw task start --title "..." --timeout 30m
```

This should automatically generate task_id, status, timeout_at, result_path, error_path, heartbeat integration, and admin-visible state.

3. Auto-failure state on tool error

When tool calls fail or timeout, automatically write state=failed, record the error, notify Manager/admin, and prevent silent stalls.

4. Heartbeat enhancement

Extend heartbeat/watchdog to scan recent conversation history for promised task starts, then cross-reference with active_tasks, task state files, running processes, Worker assignments, or sub-session records.

If a promise exists but no task instance exists, flag it as:

```text
promised_but_not_started
```

Priority: High

This affects trust in Manager's execution guarantees and requires manual admin supervision, which defeats the purpose of autonomous agents and long-running task delegation.
```

### Steps to Reproduce

1. Admin assigns a long-running task to the Manager.

2. Manager replies with an execution promise, for example:

```text
我现在直接启动，你可以观察我是否按证据汇报。
```

3. Wait several minutes, for example 7+ minutes.

4. Observe that no execution evidence is created:

- no task_id
- no state_file
- no runner call
- no Worker assignment
- no background process
- no session key
- no pid
- no timeout_at
- no result_path or error_path

5. Admin manually follows up and asks for progress.

6. Manager admits that no actual tool call or task start happened.

Actual result:

The Manager made a promise to start execution, but nothing was actually started.

Expected result:

The system should either:

- require the Manager to create a task instance before claiming execution;
- block the response;
- warn the Manager/admin;
- or mark the state as promised_but_not_started.
```

### AI Analysis

_No response_

### Relevant Logs

```shell

```

### Component

Manager Agent

### Version / Commit

dev (hiclaw version returns controller=dev, kubeMode=embedded); OpenClaw 2026. 4.14