@indigoai-us/hq-cli 5.103.10 → 5.103.11
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/CHANGELOG.md
CHANGED
|
@@ -2,6 +2,21 @@
|
|
|
2
2
|
|
|
3
3
|
## [Unreleased]
|
|
4
4
|
|
|
5
|
+
## [5.103.11] — 2026-08-20
|
|
6
|
+
|
|
7
|
+
### Reverted
|
|
8
|
+
|
|
9
|
+
- Reverted the 5.103.10 stop-gate anti-filler wording (#419). Demanding that an
|
|
10
|
+
agent "emit zero characters" after the checkpoint moved the noise instead of
|
|
11
|
+
removing it: agents that had stopped appending a meta-note began emitting a
|
|
12
|
+
bare `<br>` — markup they took to render as nothing — so the dangling line
|
|
13
|
+
under the reply survived in a third form. Each tightening only selects the
|
|
14
|
+
next-smallest token, so the wording lever is abandoned here and the branch
|
|
15
|
+
returns to its 5.103.9 text. The underlying conflict is structural: the gate
|
|
16
|
+
asks for silence at the one moment a model is least able to produce it, and
|
|
17
|
+
it only asks because it blocks AFTER a reply is already delivered. Fixing
|
|
18
|
+
that properly means not blocking in the already-replied case at all.
|
|
19
|
+
|
|
5
20
|
## [5.103.10] — 2026-08-20
|
|
6
21
|
|
|
7
22
|
### Fixed
|
|
@@ -390,7 +390,7 @@ set -uo pipefail
|
|
|
390
390
|
# which case we are in, so say exactly one thing.
|
|
391
391
|
flags_spec=' hq core checkpoint --session-id %s --trigger stop-gate --summary "<what changed, in one line>" [--file <path>] [--decision "<choice and why>"] [--learning "<reusable rule>"] [--next "<outstanding step>"]\n\nOnly --summary is required, and the repeatable flags are what the sibling uses to enrich the record, distil policies and update the indexes — a bare summary gives it almost nothing to work with. Write them as machine record, not prose for the user, and pass each one that genuinely applies:\n --file every path you created or modified this turn\n --decision a choice you made that a reader would otherwise have to reverse-engineer\n --learning a rule that changes how someone acts next time, not a restatement of what just happened\n --next work that is genuinely still outstanding\nOmit a flag rather than padding it: an empty or invented learning is worse than none.\n\nIf this turn only read or inspected things and changed no state, the correct call instead is:\n\n hq core checkpoint --session-id %s --idle'
|
|
392
392
|
if [ "$replied" = 1 ]; then
|
|
393
|
-
reason="$(printf 'This turn changed something, so it needs an end-of-turn checkpoint before it can end.\n\nYour user-facing reply is ALREADY delivered — the message you just wrote is visible to the user. Do NOT send it again, in full or summarized: repeating it double-messages the user, which is exactly the bug this gate guards against.\n\nTHE SIBLING (a background maintenance agent) reads only the checkpoint payload, never your chat reply — anything it needs must go into the flags.\n\nRun the checkpoint now as the FINAL action of the turn
|
|
393
|
+
reason="$(printf 'This turn changed something, so it needs an end-of-turn checkpoint before it can end.\n\nYour user-facing reply is ALREADY delivered — the message you just wrote is visible to the user. Do NOT send it again, in full or summarized: repeating it double-messages the user, which is exactly the bug this gate guards against.\n\nTHE SIBLING (a background maintenance agent) reads only the checkpoint payload, never your chat reply — anything it needs must go into the flags.\n\nRun the checkpoint now as the FINAL action of the turn and end the turn immediately after it, adding no further text:\n\n'"$flags_spec" "$session_id" "$session_id")"
|
|
394
394
|
else
|
|
395
395
|
reason="$(printf 'This turn changed something, so it needs an end-of-turn checkpoint. Two different audiences are involved — do not conflate them:\n\n1. THE USER reads your normal chat reply. You have not sent one yet this turn — everything you owe them (results, links, answers, status, decisions) must go into it. The checkpoint is invisible to them and does NOT count as having replied.\n2. THE SIBLING (a background maintenance agent) reads the checkpoint payload. It never sees your chat reply, so anything it needs must go into the flags.\n\nORDER: run the checkpoint FIRST, then deliver your complete user-facing reply as the FINAL text of the turn — final-position text is the one placement every host renders in full. Every link, URL, instruction, command, and decision the user needs must appear in that final message.\n\n'"$flags_spec" "$session_id" "$session_id")"
|
|
396
396
|
fi
|
|
@@ -60,11 +60,8 @@ export const CHECKPOINT_REPLY_REMINDER = "checkpoint: REMINDER — this checkpoi
|
|
|
60
60
|
"and it does NOT count as your reply. If this turn's substance (results, findings, " +
|
|
61
61
|
"decisions, state changes, anything awaiting their input) has NOT yet been delivered to " +
|
|
62
62
|
"the user, write your user-facing reply now as the FINAL text of the turn. If you " +
|
|
63
|
-
"already delivered it earlier this turn, end the turn now WITHOUT repeating it
|
|
64
|
-
"
|
|
65
|
-
"this checkpoint. The user has already seen that message; both repeating it and " +
|
|
66
|
-
"appending a dangling note leave visible noise under it. Emitting no further text at " +
|
|
67
|
-
"all is the correct, finished state.";
|
|
63
|
+
"already delivered it earlier this turn, end the turn now WITHOUT repeating it — the " +
|
|
64
|
+
"user has already seen that message, and repeating it double-messages them.";
|
|
68
65
|
function printResult(line) {
|
|
69
66
|
process.stdout.write(`${line}\n`);
|
|
70
67
|
}
|