@indigoai-us/hq-cli 5.103.9 → 5.103.10
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,18 @@
|
|
|
2
2
|
|
|
3
3
|
## [Unreleased]
|
|
4
4
|
|
|
5
|
+
## [5.103.10] — 2026-08-20
|
|
6
|
+
|
|
7
|
+
### Fixed
|
|
8
|
+
|
|
9
|
+
- The checkpoint stop-gate's already-replied branch no longer leaves a dangling
|
|
10
|
+
filler line under the reply. "Add no further text" was being satisfied with a
|
|
11
|
+
meta-note (`(reply already delivered above - turn complete)`) instead of
|
|
12
|
+
silence, which is the same visible-noise defect as repeating the reply. Both
|
|
13
|
+
the gate reason and the `hq core checkpoint` reminder now rule out the
|
|
14
|
+
sign-off / acknowledgement / meta-comment class by name and state that
|
|
15
|
+
emitting nothing is the correct finished state.
|
|
16
|
+
|
|
5
17
|
## [5.103.9] — 2026-08-20
|
|
6
18
|
|
|
7
19
|
### 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, then STOP - emit zero characters after the command. Ending a turn on a tool call with no trailing text is correct and expected here: it renders as the reply you already wrote followed by a collapsed checkpoint row. Do NOT append a sign-off, an acknowledgement, a status line, or any meta-note about the checkpoint itself - a dangling line such as "(reply already delivered above - turn complete)" is visible noise stuck under your reply, the same defect as repeating the reply. Silence is the finished state:\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,8 +60,11 @@ 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
|
-
"
|
|
63
|
+
"already delivered it earlier this turn, end the turn now WITHOUT repeating it and " +
|
|
64
|
+
"WITHOUT any closing note — no sign-off, no acknowledgement, no meta-comment about " +
|
|
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.";
|
|
65
68
|
function printResult(line) {
|
|
66
69
|
process.stdout.write(`${line}\n`);
|
|
67
70
|
}
|