typeclaw 0.15.1 → 0.15.2

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "typeclaw",
-  "version": "0.15.1",
+  "version": "0.15.2",
   "homepage": "https://github.com/typeclaw/typeclaw#readme",
   "bugs": {
     "url": "https://github.com/typeclaw/typeclaw/issues"

package/src/agent/tools/channel-reply.ts

@@ -71,11 +71,20 @@ export function createChannelReplyTool({
           },
         ),
       ),
+      continue: Type.Optional(
+        Type.Boolean({
+          description:
+            'Set `true` ONLY when this reply is a mid-turn status update (e.g. "working on it…") and you still have work to do THIS turn — fetching data, running a tool, spawning a subagent, then replying again. ' +
+            'A normal reply omits this: by default a successful reply ends the turn (no wasted follow-up LLM call). ' +
+            'Do not set it just to seem responsive; only when genuine multi-step work follows in the same turn.',
+        }),
+      ),
     }),
 
     async execute(_toolCallId, params) {
       const text = params.text
       const attachments = params.attachments
+      const keepTurnAlive = params.continue === true
       if ((text === undefined || text === '') && (attachments === undefined || attachments.length === 0)) {
         logger.warn(formatChannelToolFailure('channel_reply', 'missing text and attachments'))
         return {
@@ -130,7 +139,14 @@ export function createChannelReplyTool({
           ),
         )
       }
-      const details: { ok: boolean; error?: string } = result.ok ? { ok: true } : { ok: false, error: result.error }
+      // `continue` is read by the router's terminal hook (installChannelReplyTerminalHook),
+      // not by this tool — it suppresses the post-reply abort so a multi-step turn
+      // keeps going. Success-only: a denied reply never ran, so there is no turn to keep.
+      const details: { ok: boolean; error?: string; continue?: boolean } = result.ok
+        ? keepTurnAlive
+          ? { ok: true, continue: true }
+          : { ok: true }
+        : { ok: false, error: result.error }
       // Echo the delivered text back to the model. The adapter classifier
       // drops self-authored messages on the inbound path (`self_author`),
       // so the bot otherwise has ZERO visibility into what it just said —

package/src/channels/router.ts

@@ -1248,16 +1248,22 @@ export function createChannelRouter(options: CreateChannelRouterOptions): Channe
   // tools and `channel_send` must keep the follow-up so genuine multi-step turns
   // continue. A prior non-typeclaw `afterToolCall` (none today) would be
   // composed, not clobbered.
+  //
+  // `channel_reply({ continue: true })` is the explicit opt-out: a mid-turn
+  // status reply ("working on it…") that the model follows with more work this
+  // turn. The tool surfaces that intent as `details.continue === true`, and we
+  // keep the follow-up so the turn proceeds. The kimi 32k loop only recurs when
+  // the model genuinely has nothing left to say after a reply, which `continue`
+  // asserts is not the case; Layer 2's maxTokens cap still bounds any misuse.
   const installChannelReplyTerminalHook = (live: LiveSession): void => {
     const { agent } = live.session
     const prior = agent.afterToolCall
     agent.afterToolCall = async (context, signal) => {
       const result = prior ? await prior(context, signal) : undefined
-      const succeeded =
-        context.toolCall.name === 'channel_reply' &&
-        !context.isError &&
-        (context.result.details as { ok?: unknown } | undefined)?.ok === true
-      if (succeeded && agent.signal?.aborted !== true) {
+      const details = context.result.details as { ok?: unknown; continue?: unknown } | undefined
+      const succeeded = context.toolCall.name === 'channel_reply' && !context.isError && details?.ok === true
+      const keepTurnAlive = details?.continue === true
+      if (succeeded && !keepTurnAlive && agent.signal?.aborted !== true) {
         logger.info(`[channels] ${live.keyId} terminal_after_channel_reply`)
         agent.abort()
       }

package/src/skills/typeclaw-channel-github/SKILL.md

@@ -9,6 +9,10 @@ GitHub renders normal Markdown in issues, PRs, discussions, and review comments.
 - There is no typing indicator.
 - For PR review threads, keep `thread` set to reply in-place. Omit `thread` for a top-level PR/issue comment.
 
+## Mid-turn status replies need `continue: true`
+
+A successful `channel_reply` ends your turn by default — the runtime stops the model right after the reply lands. That is correct for a final answer, but it will **silently truncate** a turn that still has work to do. If you post a status line like "Reviewing now, I'll be back with findings" and then expect to keep working (fetch the diff, spawn the reviewer, post the review) in the **same** turn, you must call `channel_reply({ text: "…", continue: true })`. Without `continue: true`, the turn ends at that status reply and the review never runs. Reserve `continue: true` for genuine multi-step turns; the final reply that wraps up the turn omits it.
+
 ## Opening new issues and PRs
 
 The `gh` CLI is pre-authenticated via `GH_TOKEN` (injected by the adapter at startup). Use it to open new issues or PRs:
@@ -39,6 +43,8 @@ Why delegate: the `reviewer` subagent runs on the `deep` model profile, loads a
 
 2. **Spawn the `reviewer` subagent with the PR target.** Use `run_in_background: true` so you stay responsive while the deep model works. Pass the PR URL (or `owner/repo#N`) plus any context the requester gave you (focus areas, specific files, etc.) so the reviewer knows what the requester cares about.
 
+   If you post an "on it" acknowledgement before fetching the diff or spawning the reviewer, it **must** be `channel_reply({ text: "…", continue: true })` — a bare reply ends the turn and the review never starts (see "Mid-turn status replies need `continue: true`" above).
+
    The reviewer will fetch the diff itself (`gh pr diff`, `gh api /repos/.../pulls/<n>`), load the matching skill (`code-review` for a code PR; `general` for a mixed-format change), and return a `<review>` block.
 
 3. **Wait for the completion `<system-reminder>`,** then call `subagent_output({ task_id })` to read the reviewer's final assistant message. The structured payload looks like: