DeepSeek Harness: update_goal failures, stale revision

DeepSeek Harness (DSH)'s goal mechanism is an "autonomous rounds" chain, and when it breaks it is not a crash but idling: when the model completes a goal it carries along parameters that apply only to editing, so update_goal reports objective and max_goal_rounds are valid only with action edit every time; after the revision expires the model retries forever with the old value, always hitting stale goal ref; and while the main agent is plainly waiting for a subagent, goal keeps nagging it, even pushing it to cancel the in-flight subagent. These three symptoms belong to three different pieces of judgement logic: asymmetric parameter validation (a text empty string is treated as not provided, a round value fails as soon as it is non-zero), version comparison with CAS semantics (a wrong id and an expired revision share one error code), and a drivability check that looks only at idle, not why it is idle (during a continuable subagent, the parent genuinely "has no visible task") (#9566, #8955, #9429).

DSH plugin asymmetric parameter validation: don't carry edit-only fields when completing a goal

The one-line conclusion: the validation uses two standards — text parameters treat an empty string as "not provided" and let it pass, while round parameters fail as soon as they are non-zero; when the model writes back the round cap returned by get_goal as-is, it hits the error 100% of the time. The error text is objective and max_goal_rounds are valid only with action edit (#9566).

DSH plugin criterion: why it is "almost certain to hit"

Per the reporter's observation and another user's session statistics (magnitude given in the thread: 38 failures out of 64 calls across 123 sessions, with 14/14 sessions failing at least once; the 26 successes were all max_goal_rounds: 0) (#9566):

1. When completing a goal, the model tends to "fill in every field it knows", especially the round cap it just got from get_goal;
2. The validation for the round field only judges "non-zero fails", so writing a legal value back as-is becomes the source of the error instead;
3. The error does not give the correct form, so the model cannot self-correct from it and retries repeatedly (#9566).

DSH plugin four steps to handle it

1. Confirm the criterion: the error text alone is enough; if switching to max_goal_rounds: 0 or simply dropping the field succeeds, this is the case (#9566).
2. Add a project-level prompt rule (currently the most effective approach): require the model not to carry objective and max_goal_rounds in non-edit actions; set the round cap only in edit actions (#9566).
3. Verify: rerun the same completion action, expecting success in one try with no more of that error (#9566).
4. Upstream direction: have non-edit actions ignore these two fields, or change the error to "give the correct form" — the thread states both are fix directions (#9566).

DSH plugin stale goal ref: this is a CAS comparison, not "the goal does not exist"

The one-line conclusion: the id and revision in the error must match exactly to be accepted; a wrong id and an expired revision share the same error code, so you cannot tell which it is from the error itself — and the correct self-healing path is "read the current value from the error and resend it". The symptom is update_goal hitting stale goal ref "…" revision N; current is "…" revision M 100% of the time, with the model retrying forever with the old value without self-healing (#8955).

DSH plugin mechanism: two design defects compounded

Per the community's line-by-line source review (#8955):

1. A compare, not a lookup: the pre-update check is a comparison rather than a lookup, so a wrong id and an expired revision fall to the same error code GOAL_STALE_REVISION;
2. max_goal_rounds: 0 is silently treated as "not passed": this makes the error point at a field unrelated to the real cause, misleading the model further.

DSH plugin five steps to handle it

1. Confirm the criterion: the error contains two revisions (submitted vs current); if the model submits the same old value every time, this is the case (#8955).
2. Teach the model to copy the current value and self-heal: read current is "…" revision M out of the error and resend it verbatim once, which succeeds — this is the shortest path (#8955).
3. Add a project-level hard rule: call get_goal before each update to get the exact id and revision, then change it; writing it into the rules is more reliable than trusting the model (#8955).
4. A middleware approach: the thread gives a prototype — use a post-execute hook to rewrite this error into the next action (returning with block), turning the "error" into a "self-healing instruction" (#8955).
5. Verify: rerun the multi-round updates for the same goal, expecting no more consecutive staleness (#8955).

DSH plugin mindless nagging: the check looks only at idle, not why it is idle

The one-line conclusion: the drivability check judges only "is the main agent idle", not "is it idle because it dispatched work"; while a continuable subagent runs, the main agent is idle throughout and has no task entry visible to the parent, so it is judged "drivable" and nagged continuously — in severe cases forcing the main agent to cancel the in-flight subagent. (#9429) If the subagent being nagged about is one dispatched after Agent Teams is mounted, control and reclamation run into the separate "tools replaced by the Team build, addressed by roster name" family — see DeepSeek Harness: duplicate list_agents, stuck subagents.

DSH plugin mechanism and the difference between three dispatch modes

Per the community's line-by-line source review: the readyToDrive predicate judges only agent.status === 'idle'; and a "continuable" subagent produces no task entry visible to the parent while it runs (the thread compares another implementation: the correct approach should wait for the subagent too) (#9429).

1. Foreground one-shot: the parent can see "a task is running" and is not misjudged as idle;
2. Background one-shot: it also has a visible task;
3. Continuable form: no visible task — this is the exposure point (#9429).

DSH plugins five steps to handle it

1. Confirm the criterion: goal rounds keep producing nagging while waiting for a subagent, meaningless content is stuffed into the context, and actions like "suggest canceling the in-flight subagent" even appear (#9429).
2. Workaround one (when continuation is not needed): change the subagent to a one-shot dispatch, so the parent can see the task running and the nagging naturally decreases (#9429).
3. Workaround two (when the continuation ability must be kept): install the community guard plugin @argszero/cordis-plugin-goal-progress-guard, which fixes the task invocation contract and uses subagent start/end events to maintain an in-flight count (#9429):

npm i @argszero/cordis-plugin-goal-progress-guard

4. Verify: run the "dispatch subagent + wait" goal round again, expecting no more nagging or cancellation suggestions (#9429).
5. Upstream fix point: add the predicate "is it idle because it dispatched work" to the drivability check (#9429).

DSH plugin troubleshooting notes

Goal-style "idling" problems have a common trait: the error text often points at the wrong field (stale points at the revision, valid only with action edit points at the rounds), so think from "why are the values out of sync", not from the literal error. Eight points:

1. stale is a CAS comparison failure, not "the goal is gone" (#8955).
2. Copying the current value out of the error is the fastest self-healing: current is … is the correct value to submit (#8955).
3. Write "fetch then change" as a hard rule, more reliable than relying on the model's memory (#8955).
4. max_goal_rounds: 0 is treated as not passed, which manufactures an error unrelated to the real cause (#8955).
5. Do not carry round parameters in non-edit actions: the shortest path to sidestep the asymmetric validation (#9566).
6. An error that cannot self-correct is a design gap: when you see "the model retrying the same action repeatedly", first suspect that the error is missing the correct form (#9566).
7. For nagging problems, look at the dispatch mode first: the continuable form is the exposure point (#9429).
8. State the fix status honestly: all three are unfixed in the version discussed; normalizing empty-string/zero values, giving the correct form in the error, and adding a predicate to the drivability check are all core-side changes, so the user side can only rely on prompt rules and community plugins.

Goal-style autonomous-round problems often require confirming the "plugins and config" layer first when troubleshooting. Instead of typing commands everywhere to infer it, use a visual marketplace like DSH Plugin Hub: the installed list, install/uninstall history, and system logs sit in one panel, so you can see the environment clearly before acting.

Source: Discussion #9566, Discussion #8955, Discussion #9429.