What happened
Since #3199 a user can arm a Goal from the ＋ menu. Arming deliberately starts nothing — the Goal waits for a Turn to take hold of it — but the Session context chip renders it exactly like a Goal that is driving itself: StatusDot gets goalRunningAriaLabel ("Autonomous goal running") and isPulsing, because the only states it distinguishes are paused and waiting (packages/ui/src/session-context-layer.tsx:136-146).
So between arming and the user's next Turn the chip pulses and says the Goal is running, while nothing runs and nothing will until the user sends a message.
How to reproduce
- Open a Session with no Goal.
- ＋ menu → 设定 Goal…, enter a condition, 开始.
- Do not send a message.
The Goal chip shows a pulsing dot labelled "Autonomous goal running". No Turn is admitted.
Expected
The chip should say the Goal is set and takes hold on the next Turn, and should not pulse as if work were in flight.
Why the UI cannot tell today
GoalProjection (packages/runtime-host/src/protocol/goal.ts:33) carries status and iterations, and neither answers the question. status: 'active' covers both an armed Goal waiting for its first Turn and a Goal between continuations. iterations: 0 covers both an armed Goal and a model-set Goal whose first Turn has not settled yet — and the latter is genuinely driving.
The Host does know. armedAt on GoalState is present exactly while a Goal is waiting to be driven, and isDrivingGoal in packages/core/src/goal.ts reads it. It is not on the wire.
Scope
One field on GoalProjection plus a copy string; the Host-side fact already exists. An optional field an older client ignores should not need a compatibility epoch, but that is worth confirming when the change is made.
Environment
- Maka commit: 57e08d8 (
main)
- Surface: Desktop
(Filed with Claude Code (Opus 5); the cited lines were read from main at 57e08d8.)
What happened
Since #3199 a user can arm a Goal from the ＋ menu. Arming deliberately starts nothing — the Goal waits for a Turn to take hold of it — but the Session context chip renders it exactly like a Goal that is driving itself:
StatusDotgetsgoalRunningAriaLabel("Autonomous goal running") andisPulsing, because the only states it distinguishes arepausedandwaiting(packages/ui/src/session-context-layer.tsx:136-146).So between arming and the user's next Turn the chip pulses and says the Goal is running, while nothing runs and nothing will until the user sends a message.
How to reproduce
The Goal chip shows a pulsing dot labelled "Autonomous goal running". No Turn is admitted.
Expected
The chip should say the Goal is set and takes hold on the next Turn, and should not pulse as if work were in flight.
Why the UI cannot tell today
GoalProjection(packages/runtime-host/src/protocol/goal.ts:33) carriesstatusanditerations, and neither answers the question.status: 'active'covers both an armed Goal waiting for its first Turn and a Goal between continuations.iterations: 0covers both an armed Goal and a model-set Goal whose first Turn has not settled yet — and the latter is genuinely driving.The Host does know.
armedAtonGoalStateis present exactly while a Goal is waiting to be driven, andisDrivingGoalinpackages/core/src/goal.tsreads it. It is not on the wire.Scope
One field on
GoalProjectionplus a copy string; the Host-side fact already exists. An optional field an older client ignores should not need a compatibility epoch, but that is worth confirming when the change is made.Environment
main)(Filed with Claude Code (Opus 5); the cited lines were read from
mainat 57e08d8.)