[Feature]: Capture non-blocking human wishes without interrupting agent delivery

[huangruiteng]

Preflight

• I searched existing issues, discussions, and contributor tasks for this request.
• This request and its attachments contain no credentials or private/internal material.

Request origin

Observed need in a real workflow.

Problem or unmet outcome

LoopX distinguishes blocking user_gate todos from non-blocking user_action todos and can continue independent work around a scoped gate. However, agents do not have an exact low-noise way to preserve optional human leverage discovered while the selected task continues.

The current choices are all lossy: promote the opportunity into a false gate, create an ordinary user action that may notify immediately, turn it into agent work with the wrong owner, or leave it in chat and lose it. Heartbeat guidance already asks agents to retain high-value losing candidates, but the todo writer, interaction projection, and compact packet do not define a non-blocking wishlist sidecar.

Use case

After completing and validating the selected work, an agent notices one evidence-backed opportunity where human input has comparative advantage—for example, a preference that could improve a later slice, an optional introduction, or review of one concrete assumption. The selected action does not depend on that input and the agent has independent work it may continue.

The agent should be able to capture zero or one such wish after primary validation, settle the normal turn unchanged, and continue the main flow. The wish should appear later in a bounded status/review lane or piggyback on an already-visible material result. It must not create a standalone notification.

Proposed outcome

Define a typed human-attention model:

• gate: existing task_class=user_gate, exact blocking/authority semantics;
• request: existing task_class=user_action, current non-blocking notice behavior;
• wish: task_class=user_action human_attention_kind=wish, optional and non-notifying.

The smallest useful implementation should:

1. validate human_attention_kind=request|wish and a stable public-safe wish_key;
2. provide one bounded, evidence-required todo writer with per-turn and active-item caps plus deduplication;
3. project wishlist_items separately from blocking counts and immediate user notifications;
4. add an exact 0..1, post-validation, non-interrupting capture rule to generated heartbeat prompts and the loopx-project skill;
5. expose a signed compact optional-sidecar hint without adding it to required next_cli_actions;
6. prove quota, selected work, authority, spend, scheduler, and DONT_NOTIFY invariance.

A draft RFC is being proposed at docs/architecture/rfcs/human-attention-wishlist-v0.md with a Chinese semantic mirror.

LoopX area

Control plane (goals, todos, quota, scheduler, registry, runtime).

Alternatives considered

• Add a new user_wish task class: too broad for v0; storage and lifecycle already match non-blocking user actions.
• Use an action_kind naming convention: prose/substrings must not become routing truth.
• Keep wishes only in todo suggest: the surface is intentionally read-only and requires later promotion.
• Write every opportunity as an agent todo: misstates ownership and pollutes the runnable frontier.
• Prompt-only guidance: drifts across hosts without a typed writer, projection, and signed compact hint.

Scope and non-goals

In scope:

• typed wish metadata over canonical user todos;
• bounded authoring, deduplication, projection, heartbeat/skill hints, and compact packet parity;
• public-safe evidence and multi-agent binding;
• strict invariants that wishes do not grant authority or affect execution.

Out of scope:

• a new task store, capability, scheduler, or quota lane;
• automatic protected-action approval;
• mandatory wish generation;
• dashboard redesign, external sink support, acceptance metrics, or auto-promotion before real usage evidence exists.

Contribution

• I may be able to help design, implement, document, or validate this request.

[huangruiteng]

RFC proposal opened in #3180. The issue remains open to track the smallest implementation slice and validation portfolio.

[huangruiteng]

Maintainer re-triage: the problem statement is useful, but this should stay at the discussion/RFC level for now. We do not yet have enough repeated usage evidence to justify adding wish metadata, a dedicated writer, a separate projection, prompt hints, and a signed sidecar across the control plane.

The current default remains: use user_gate only for blocking authority, use user_action for a genuinely useful non-blocking request, and otherwise avoid creating a new user-facing item.

Please do not start an implementation from this issue yet. We can revisit it after concrete workflows show that valuable optional human input is repeatedly lost or that ordinary user_action notifications are too noisy, then derive the smallest contract from that evidence.