@sema-agent/cli 1.0.13 → 1.0.14

package/npm-shrinkwrap.json

@@ -1,12 +1,12 @@
 {
   "name": "@sema-agent/cli",
-  "version": "1.0.13",
+  "version": "1.0.14",
   "lockfileVersion": 3,
   "requires": true,
   "packages": {
     "": {
       "name": "@sema-agent/cli",
-      "version": "1.0.13",
+      "version": "1.0.14",
       "license": "BUSL-1.1",
       "dependencies": {
         "@sema-agent/sdk": "0.0.53",
@@ -629,9 +629,9 @@
       }
     },
     "node_modules/@sema-agent/core": {
-      "version": "1.309.0",
-      "resolved": "https://registry.npmjs.org/@sema-agent/core/-/core-1.309.0.tgz",
-      "integrity": "sha512-xn97ll9ia9sdIYHloZCD2IMmMxFyMeEygPoXNpGdD5JNx/owpudZhae1NYQU9NR7yBvnRla7uZz4C841+mLMHw==",
+      "version": "1.312.0",
+      "resolved": "https://registry.npmjs.org/@sema-agent/core/-/core-1.312.0.tgz",
+      "integrity": "sha512-a50syYHBa3TT1FjqZCGwK2YH3gt6o4YiyamJYGwY4ABdwCaj8wGBJZmkQw48J+1XEDo7NL/rV5xtaNzxn656Gw==",
       "license": "BUSL-1.1",
       "dependencies": {
         "@modelcontextprotocol/sdk": "1.29.0",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sema-agent/cli",
-  "version": "1.0.13",
+  "version": "1.0.14",
   "description": "Sema — your own Claude Code-grade coding agent, in the terminal.",
   "license": "BUSL-1.1",
   "bin": {
@@ -25,10 +25,10 @@
     "@sema-agent/server": "1.218.0"
   },
   "overrides": {
-    "@sema-agent/core": "1.309.0",
+    "@sema-agent/core": "1.312.0",
     "@sema-agent/registry-core": "0.10.14"
   },
-  "semaEngineVersion": "server 1.218.0 / core 1.309.0 / registry-core 0.10.14",
+  "semaEngineVersion": "server 1.218.0 / core 1.312.0 / registry-core 0.10.14",
   "engines": {
     "node": ">=18"
   }

package/sema.js

@@ -107341,6 +107341,8 @@ var init_ink = __esm({
       // screen readers / screen magnifiers track it — so parking at the text
       // input's caret makes CJK input appear inline and lets a11y tools follow.
       cursorDeclaration = null;
+      /** sema 光标/IME:声明光标当前是否已 ?25h 显示(防每帧重复写显隐序)。 */
+      declaredCursorShown = false;
       // Main-screen: physical cursor position after the declared-cursor move,
       // tracked separately from frame.cursor (which must stay at content-bottom
       // for log-update's relative-move invariants). Alt-screen doesn't need
@@ -107627,6 +107629,10 @@ var init_ink = __esm({
                 });
               }
             }
+            if (!this.declaredCursorShown) {
+              optimized.push({ type: "stdout", content: "\x1B[?25h" });
+              this.declaredCursorShown = true;
+            }
             this.displayCursor = target;
           } else {
             if (parked !== null && !this.altScreenActive && !hasDiff) {
@@ -107639,6 +107645,10 @@ var init_ink = __esm({
                 });
               }
             }
+            if (this.declaredCursorShown) {
+              optimized.push({ type: "stdout", content: "\x1B[?25l" });
+              this.declaredCursorShown = false;
+            }
             this.displayCursor = null;
           }
         }
@@ -479518,8 +479528,8 @@ var init_sema_brand = __esm({
           "Slash-command gating wired to the fleet capability handshake"
         ]
       },
-      productVersion: "1.0.13",
-      announcement: "sema 1.0.13 \u2014 tool cards render faithfully again (CronCreate headers, skill results, full output behind ctrl+o), and scheduler writes are concurrency-safe across sessions and daemons"
+      productVersion: "1.0.14",
+      announcement: "sema 1.0.14 \u2014 CJK input method candidate windows now anchor to the input caret (the terminal cursor is shown while typing), and autonomous-loop wakeups resolve to real tick instructions instead of a literal sentinel"
     };
   }
 });
@@ -482453,8 +482463,8 @@ var require_sema_brand = __commonJS({
           "Slash-command gating wired to the fleet capability handshake"
         ]
       },
-      productVersion: "1.0.13",
-      announcement: "sema 1.0.13 \u2014 tool cards render faithfully again (CronCreate headers, skill results, full output behind ctrl+o), and scheduler writes are concurrency-safe across sessions and daemons"
+      productVersion: "1.0.14",
+      announcement: "sema 1.0.14 \u2014 CJK input method candidate windows now anchor to the input caret (the terminal cursor is shown while typing), and autonomous-loop wakeups resolve to real tick instructions instead of a literal sentinel"
     };
   }
 });
@@ -556862,6 +556872,98 @@ var init_fs_write_gate_policy = __esm({
   }
 });
 
+// node_modules/@sema-agent/core/dist/tools/loop-tick.js
+function pushNotificationAppendix(persistentVariant) {
+  const r = persistentVariant ? "newly blocked on a decision you won't make alone, you're ending the loop" : "newly blocked on a decision you won't make alone, third straight tick with nothing to do, you're ending the loop";
+  return `
+
+Use PushNotification when the loop can't move further without the user, or when something landed that they'd want to act on now: ${r}, or a major update arrived (CI went red, a review changes the plan). Progress you made yourself isn't a trigger \u2014 the transcript covers that. One ping per state, not per tick.`;
+}
+function cronTick(push) {
+  return `# Autonomous loop tick
+
+Run the autonomous check using the loop instructions established earlier in this conversation. If you cannot find them, treat this as a no-op tick. The recurring cron will fire the next tick automatically \u2014 do not call ${SCHEDULE_WAKEUP_TOOL_NAME} from this tick.${push}`;
+}
+function dynamicTick(push) {
+  return `# Autonomous loop tick (dynamic pacing)
+
+Run the autonomous check using the loop instructions established earlier in this conversation. If you cannot find them, treat this as a no-op tick.
+
+You scheduled this tick via the ${SCHEDULE_WAKEUP_TOOL_NAME} tool (not a recurring cron). To keep the loop alive, call ${SCHEDULE_WAKEUP_TOOL_NAME} again at the end of this turn with \`prompt\` set to the literal sentinel \`${AUTONOMOUS_LOOP_DYNAMIC_SENTINEL}\` \u2014 otherwise the loop ends after this tick.${DYNAMIC_APPENDIX}${push}`;
+}
+function resolveAutonomousLoopPrompt(prompt, opts) {
+  if (prompt !== AUTONOMOUS_LOOP_SENTINEL && prompt !== AUTONOMOUS_LOOP_DYNAMIC_SENTINEL)
+    return null;
+  const persistent = opts?.persistentVariant === true;
+  const push = opts?.pushNotification === true ? pushNotificationAppendix(persistent) : "";
+  const tick = prompt === AUTONOMOUS_LOOP_DYNAMIC_SENTINEL ? dynamicTick(push) : cronTick(push);
+  if (opts?.firstTick !== true)
+    return tick;
+  const preamble = persistent ? AUTONOMOUS_LOOP_PREAMBLE_PERSISTENT : AUTONOMOUS_LOOP_PREAMBLE;
+  return `${preamble}
+
+---
+
+${tick}`;
+}
+var AUTONOMOUS_LOOP_PREAMBLE, AUTONOMOUS_LOOP_PREAMBLE_PERSISTENT, DYNAMIC_APPENDIX;
+var init_loop_tick = __esm({
+  "node_modules/@sema-agent/core/dist/tools/loop-tick.js"() {
+    init_scheduler_tools();
+    AUTONOMOUS_LOOP_PREAMBLE = `# Autonomous loop check
+
+You're being invoked on a timer while the user is away or occupied. The point is to keep work moving forward without the user driving every step \u2014 finishing things they started, maintaining PRs they're building, catching problems before they come back to find them. You're a steward, not an initiator. The user set you loose on their work, and the value you provide comes from reliably advancing things they've already set in motion, not from finding new things to do.
+
+The key tension to navigate: the user trusts you enough to run autonomously, but that trust is easily lost. Acting on what the conversation already established is safe and valuable. Inventing new work or making irreversible changes without clear authorization erodes trust fast. When you're unsure whether something falls into "continuing established work" or "inventing new work," lean toward the former only when the transcript provides clear evidence the user wanted it done. If you find yourself reaching for justifications about why a push is probably fine, that's a signal to wait.
+
+## What to act on
+
+The current conversation is your highest-signal source \u2014 re-read the transcript above, since everything there is something the user was actively engaged with. The strongest signal is an in-progress PR you've been building together: review comments to address and resolve, failing CI checks to diagnose (and re-enqueue if they're flakes), merge conflicts to fix. The goal is to get the PR into a state where it's ready to merge pending only human review \u2014 the user shouldn't come back to find a PR blocked on things you could have handled. After that, look for unfinished implementation where the last exchange left something half-done, and explicit "I'll also..." or "next I'll..." commitments the conversation made and didn't honor. Weaker but still real: dangling questions you could now answer, verification steps that were skipped, edge cases that were mentioned but not handled, and natural continuations that don't require new decisions.
+
+If you find anything in this category, act on it \u2014 actually do the work, don't describe what could be done. Run the tests, don't say "you could run the tests." The whole point of autonomous operation is that work gets done while the user is away.
+
+When the conversation transcript has nothing left, the current branch's pull/merge request on the user's SCM is the next-best place to look. This is maintenance work \u2014 valuable, but lower priority than continuing the user's active work. Find the PR/MR for the current branch via the SCM's CLI, then check three things: CI status, unresolved review threads, and whether the branch has fallen behind the base. For failing CI, pull the failing job's logs and diagnose before acting \u2014 flaky-shaped failures (timeout, runner died, transient network) can be re-enqueued; real failures need a reproduction and a minimal fix. For unresolved review threads, fetch the comment, address the feedback, push, and resolve the thread via, for example, the GitHub GraphQL \`resolveReviewThread\` mutation (or the equivalent for whichever SCM the project uses). Before pushing anything, check whether someone else has pushed to the branch while you were working \u2014 if so, rebase (don't merge) to keep history clean.
+
+When CI is green, threads are clear, and there's idle time, sweeping the branch for issues is a good use of that time \u2014 bug-hunt or simplification passes catch problems before reviewers do, saving everyone a round-trip.
+
+If everything is genuinely quiet \u2014 no conversation work, no PR maintenance \u2014 say so in one sentence and stop. No summary of what you checked, no list of what you might do later. The user will see your message in the transcript when they come back; three consecutive "nothing to do" results means you should scale back to a quick CI check and stop, not narrate.
+
+## Repeated invocations
+
+If you see earlier autonomous checks in this conversation, adjust your scope accordingly. If a previous check left a question the user hasn't answered, the cost of acting depends on reversibility: for reversible actions (local edits, running tests), make your best call and proceed; for irreversible ones (pushing, deleting, sending), keep waiting \u2014 the cost of acting wrongly on something irreversible is much higher than the cost of waiting one more cycle. If three or more consecutive checks have found nothing actionable, things are quiet \u2014 do one quick CI/threads check and stop in a single line. Repeated "nothing to do" messages clutter the transcript and waste the user's attention when they come back to review.
+
+Read and analyze freely \u2014 understanding the state of things has no blast radius. Make edits and run tests when you're confident they continue established work. Commit and push only when you're clearly continuing something the user authorized, or when the work pattern makes the intent obvious \u2014 like fixing CI on a PR you've been building together.
+`;
+    AUTONOMOUS_LOOP_PREAMBLE_PERSISTENT = `# Autonomous loop check
+
+You're being invoked on a timer while the user is away or occupied. The point is to keep work moving forward without the user driving every step \u2014 finishing things they started, maintaining PRs they're building, catching problems before they come back to find them, and following through on the *spirit* of the task they gave you, not just its literal scope. The user set you loose on their work, and the value you provide comes from reliably advancing things they've already set in motion.
+
+The key tension to navigate: the user trusts you enough to run autonomously, but that trust is easily lost. Acting on what the conversation already established is safe and valuable. For irreversible actions (push, delete, send), require clear authorization in the transcript or use a reversible alternative (a draft, a local commit, a queued message). For reversible actions (edits, tests, drafts, exploration), bias toward acting \u2014 the cost of an unneeded local edit is near zero, and the cost of a stalled loop is high. When you're unsure whether something falls into "continuing established work" or "inventing new work," lean toward continuing whenever the transcript gives you any reasonable thread to pull on.
+
+## What to act on
+
+The current conversation is your highest-signal source \u2014 re-read the transcript above, since everything there is something the user was actively engaged with. The strongest signal is an in-progress PR you've been building together: review comments to address and resolve, failing CI checks to diagnose (and re-enqueue if they're flakes), merge conflicts to fix. The goal is to get the PR into a state where it's ready to merge pending only human review \u2014 the user shouldn't come back to find a PR blocked on things you could have handled. After that, look for unfinished implementation where the last exchange left something half-done, and explicit "I'll also..." or "next I'll..." commitments the conversation made and didn't honor. Weaker but still real: dangling questions you could now answer, verification steps that were skipped, edge cases that were mentioned but not handled, and natural continuations that don't require new decisions.
+
+If you find anything in this category, act on it \u2014 actually do the work, don't describe what could be done. Run the tests, don't say "you could run the tests." The whole point of autonomous operation is that work gets done while the user is away.
+
+When the conversation transcript has nothing left, the current branch's pull/merge request on the user's SCM is the next-best place to look. This is maintenance work \u2014 valuable, but lower priority than continuing the user's active work. Find the PR/MR for the current branch via the SCM's CLI, then check three things: CI status, unresolved review threads, and whether the branch has fallen behind the base. For failing CI, pull the failing job's logs and diagnose before acting \u2014 flaky-shaped failures (timeout, runner died, transient network) can be re-enqueued; real failures need a reproduction and a minimal fix. For unresolved review threads, fetch the comment, address the feedback, push, and resolve the thread via, for example, the GitHub GraphQL \`resolveReviewThread\` mutation (or the equivalent for whichever SCM the project uses). Before pushing anything, check whether someone else has pushed to the branch while you were working \u2014 if so, rebase (don't merge) to keep history clean.
+
+When CI is green, threads are clear, and there's idle time, sweeping the branch for issues is a good use of that time \u2014 bug-hunt or simplification passes catch problems before reviewers do, saving everyone a round-trip.
+
+If everything is genuinely quiet \u2014 no conversation work, no PR maintenance \u2014 say so in one sentence and keep the loop alive. Before stopping, broaden once: re-read the original task framing, check whether earlier ticks deferred anything ("I'll wait for X"), and look at sibling PRs/branches the user owns. Persistence is the point of autonomous mode. Only stop if the original task is provably complete or the user said to stop. (Pacing \u2014 how long to wait before the next tick \u2014 is handled by the per-mode reminder appended to this preamble; don't try to manage delay from here.)
+
+## Repeated invocations
+
+If you see earlier autonomous checks in this conversation, adjust your scope accordingly. If a previous check left a question the user hasn't answered, the cost of acting depends on reversibility: for reversible actions (local edits, running tests), make your best call and proceed; for irreversible ones (pushing, deleting, sending), keep waiting \u2014 the cost of acting wrongly on something irreversible is much higher than the cost of waiting one more cycle. If three or more consecutive checks have found nothing actionable, broaden scope once before considering stopping \u2014 re-read the original task, check sibling work, look for verification or polish steps that were skipped. A loop that quits the moment work goes quiet is less useful than one that waits.
+
+Read and analyze freely \u2014 understanding the state of things has no blast radius. Make edits and run tests when you're confident they continue established work. Commit and push only when you're clearly continuing something the user authorized, or when the work pattern makes the intent obvious \u2014 like fixing CI on a PR you've been building together.
+`;
+    DYNAMIC_APPENDIX = `
+
+If a Monitor is armed (check TaskList), keep \`delaySeconds\` at 1200\u20131800s \u2014 the Monitor is the wake signal and this is only the fallback heartbeat. If you were woken by a \`<task-notification>\`, handle the event before deciding whether to re-arm. To stop the loop, call ${SCHEDULE_WAKEUP_TOOL_NAME} with \`stop: true\` and TaskStop the monitor (use TaskList to find its task ID if no longer in context).`;
+  }
+});
+
 // node_modules/@sema-agent/core/dist/core/permission-rules.js
 var init_permission_rules = __esm({
   "node_modules/@sema-agent/core/dist/core/permission-rules.js"() {
@@ -557231,6 +557333,7 @@ var init_dist9 = __esm({
     init_background_shell();
     init_scheduler();
     init_scheduler_tools();
+    init_loop_tick();
     init_tighten_task_spec();
     init_tool_policy();
     init_auto_mode();
@@ -607564,8 +607667,8 @@ function _temp161() {
 var import_compiler_runtime316, import_react313, SETTINGS_ERRORS_NOTIFICATION_KEY;
 var init_useSettingsErrors = __esm({
   "build-src/src/hooks/notifs/useSettingsErrors.tsx"() {
-    import_compiler_runtime316 = __toESM(require_compiler_runtime(), 1);
-    import_react313 = __toESM(require_react(), 1);
+    import_compiler_runtime316 = __toESM(require_compiler_runtime());
+    import_react313 = __toESM(require_react());
     init_notifications();
     init_state();
     init_allErrors();
@@ -653687,7 +653790,7 @@ Auth: unix socket -R \u2192 local proxy`, "info");
         pendingHookMessages
       }, renderAndRun);
     }
-  }).version("sema 1.0.13", "-v, --version", "Output the version number");
+  }).version("sema 1.0.14", "-v, --version", "Output the version number");
   program2.option("-w, --worktree [name]", "Create a new git worktree for this session (optionally specify a name)");
   program2.option("--tmux", "Create a tmux session for the worktree (requires --worktree). Uses iTerm2 native panes when available; use --tmux=classic for traditional tmux.");
   if (canUserConfigureAdvisor()) {
@@ -657618,8 +657721,18 @@ function effectiveFirePrompt(fire) {
     substituted: true
   };
 }
+function makeSentinelResolver() {
+  const ticked = /* @__PURE__ */ new Set();
+  return (prompt, recordId) => {
+    const firstTick = !ticked.has(recordId);
+    const resolved = resolveAutonomousLoopPrompt(prompt, { firstTick });
+    if (resolved !== null) ticked.add(recordId);
+    return resolved ?? prompt;
+  };
+}
 var init_firePrompt = __esm({
   "build-src/src/sema/scheduler/firePrompt.ts"() {
+    init_dist9();
   }
 });
 
@@ -657858,8 +657971,10 @@ function wireSchedulerSessionLifecycle(opts = {}) {
   };
 }
 function submitViaQueue(onWarn) {
+  const resolveSentinel = makeSentinelResolver();
   return async (fire) => {
-    const { prompt, substituted } = effectiveFirePrompt(fire);
+    const { prompt: rawPrompt, substituted } = effectiveFirePrompt(fire);
+    const prompt = resolveSentinel(rawPrompt, fire.recordId);
     if (substituted) {
       onWarn?.(`scheduler: record ${fire.recordId} fired with an EMPTY prompt \u2014 substituted a placeholder (never inject empty user content)`);
     }