@useshifu/coding-harness 0.3.29 → 0.3.31

package/bin/source-review.js

@@ -120,7 +120,7 @@ function openCodeSources(selection, rows, scheduled = false) {
 }
 
 function sourcePacket(selection, records, scheduled) {
-  const adapters = { codex: codexSources, claude_code: claudeSources, opencode: openCodeSources };
+  const adapters = { codex: codexSources, claude_code: claudeSources, opencode: openCodeSources, cursor: require("./cursor-sessions.js").sources };
   if (scheduled && selection.toTurn > completedSourceTurn(selection, records)) throw new Error("The selected original range includes an unfinished turn. Nothing was synced.");
   const { turnCount, sources } = adapters[selection.harness](selection, records, scheduled);
   if (selection.toTurn > turnCount) throw new Error("The selected original turns are unavailable locally. Nothing was reconstructed or synced.");
@@ -142,6 +142,7 @@ function scheduledSourcePacket(selection, records) {
 // A later human message closes its predecessor. The trailing human turn needs
 // explicit terminal metadata; age and intermediate text never close it.
 function completedSourceTurn(selection, records) {
+  if (selection.harness === "cursor") return require("./cursor-sessions.js").completedTurn(records);
   let turnCount = 0;
   let closed = false;
   if (selection.harness === "codex") {
@@ -198,4 +199,29 @@ function completedSourceTurn(selection, records) {
   return Math.max(0, turnCount - (closed ? 0 : 1));
 }
 
-module.exports = { selectedSourcePacket, scheduledSourcePacket, completedSourceTurn };
+function continuitySourcePacket(selection, records, minimumTurn = 1) {
+  const packet = scheduledSourcePacket(selection, records);
+  let first = Math.max(1, selection.fromTurn - 6, minimumTurn);
+  const adapters = { codex: codexSources, claude_code: claudeSources, opencode: openCodeSources, cursor: require("./cursor-sessions.js").sources };
+  const references = first < selection.fromTurn
+    ? adapters[selection.harness]({ ...selection, fromTurn: first, toTurn: selection.fromTurn - 1 }, records, true).sources : [];
+  const originalFirst = first;
+  let referenceSources = references;
+  function oversized() {
+    return Buffer.byteLength(JSON.stringify(referenceSources)) > 64 * 1024 ||
+      packet.sources.length + referenceSources.length > MAX_SOURCE_MESSAGES ||
+      Buffer.byteLength(JSON.stringify({ ...packet, referenceSources })) + 512 > MAX_PACKET_BYTES;
+  }
+  while (referenceSources.length && oversized()) {
+    first = referenceSources[0].turn + 1;
+    referenceSources = references.filter((source) => source.turn >= first);
+  }
+  return { ...packet, referenceSources, referenceCoverage: {
+    fromTurn: referenceSources.length ? referenceSources[0].turn : selection.fromTurn,
+    toTurn: selection.fromTurn - 1,
+    limited: first > Math.max(1, selection.fromTurn - 6) || minimumTurn > Math.max(1, selection.fromTurn - 6),
+    droppedTurns: Math.max(0, first - originalFirst),
+  } };
+}
+
+module.exports = { selectedSourcePacket, scheduledSourcePacket, continuitySourcePacket, completedSourceTurn };

package/bin/v5-payload.js

@@ -76,7 +76,7 @@ function itemReferences(value, count, maximum, field, index, target) {
 
 function preparedPayload(packet, output) {
   exactObject(output, ["title", "summary", "decisions", "verification", "evidence"]);
-  if (!packet || !["codex", "claude_code", "opencode"].includes(packet.harness) || typeof packet.sessionRef !== "string" ||
+  if (!packet || !["codex", "claude_code", "opencode", "cursor"].includes(packet.harness) || typeof packet.sessionRef !== "string" ||
       !Number.isInteger(packet.fromTurn) || !Number.isInteger(packet.toTurn) || packet.fromTurn < 1 || packet.toTurn < packet.fromTurn ||
       packet.toTurn > 1_000_000 || packet.toTurn - packet.fromTurn >= 12 || !Array.isArray(packet.sources)) {
     throw new Error("The selected source packet has invalid trusted metadata.");

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@useshifu/coding-harness",
-  "version": "0.3.29",
+  "version": "0.3.31",
   "description": "Scheduled, redacted coding-harness activity sync for Shifu",
   "bin": {
     "coding-harness": "bin/shifu-harness.js",

package/skills/shifu-context/SKILL.md

@@ -12,7 +12,7 @@ Before first connection or MCP personalization, ask for any choices that are not
 When asked to connect Shifu context, run:
 
 ```sh
-npx --yes @useshifu/coding-harness@0.3.29 mcp-setup --harness codex
+npx --yes @useshifu/coding-harness@0.3.30 mcp-setup --harness codex
 ```
 
 MCP setup verifies the connection and tools, saves the choices and installs instructions; it does not sync sessions or upload the selected history. History selection governs eligible work for subsequent sync. Do not start sync as part of this setup unless the user separately asks for it. If a saved connection exists, reuse its key and do not run `connect` again.

package/skills/shifu-sync/SKILL.md

@@ -117,7 +117,7 @@ For an explicit sync request, first read `status` to determine the saved approva
 
 Use `kind: "activity"` for general harness work; it does not require a technical scope. Evidence may be empty when the reviewed source contains no durable context. Never invent impact, ownership, verification, or outcomes. A requested check, assistant proposal, or reported result must retain that status even when it is useful context.
 
-Make each supported item useful for later recall: retain the described action, feature or project purpose, specific problem, approach, and reported verification or outcome with its status and ownership intact. Preserve supported technologies, design patterns, configuration choices, and measured results; these are useful work details, not identifiers to redact. A descriptive project label such as "payment reconciliation service" is useful; synthesize it from the work's purpose instead of copying a raw project label that might contain a company or person's name. Preserve supported decisions and their rationale, accepted and rejected tradeoffs, lessons, and observed outcomes. Keep proposals explicitly labeled as proposals; do not turn an agent suggestion into a user-adopted decision or infer personal ownership. Use statements, per-item work context, linked decisions and verification, and permitted source metadata. Keep distinct facts separate, including two fixes in one feature that addressed different problems. Omit names of companies and people, customer details, proprietary identifiers, paths, code snippets, credentials, and unsupported impact. If a detail cannot be safely described, keep the supported parts. Prefer a summary that names the main distinct work items over a generic count alone.
+Make each supported item useful for later recall: retain the described action, feature or project purpose, specific problem, approach, and reported verification or outcome with its status and ownership intact. Preserve supported technologies, design patterns, configuration choices, and measured results; these are useful work details, not identifiers to redact. A descriptive project label such as "payment reconciliation service" is useful; synthesize it from the work's purpose instead of copying a raw project label that might contain a company or person's name. Preserve supported decisions and their rationale, accepted and rejected tradeoffs, lessons, and observed outcomes. Keep proposals explicitly labeled as proposals; do not turn an agent suggestion into a user-adopted decision or infer personal ownership. Use statements, per-item work context, linked decisions and verification, and permitted source metadata. Keep distinct facts separate, including two fixes in one feature that addressed different problems. Preserve the code-permitted public technology labels Turbopuffer, PostgreSQL, Go, TypeScript, React and Node.js when grounded and relevant. This does not authorize confidential customer or employer relationships. Omit other company and person names, customer details, proprietary identifiers, paths, code snippets, credentials, and unsupported impact. If a detail cannot be safely described, keep the supported parts. Prefer a summary that names the main distinct work items over a generic count alone.
 
 ```json
 {
@@ -157,3 +157,9 @@ Only when the user explicitly asks to force-sync, add `--force` to `sessions` wi
 Re-review each returned range with `review --harness codex --session-ref <sessionRef> --force --from-turn <fromTurn> --to-turn <toTurn>` and the same window (or `--all` for explicitly selected backfill/count selection). No prior sync ID is required. Read the returned final notes semantically and synthesize meaningful, attributable work evidence; do not use `payloadForSegment` or its unattended keyword projection for force sync. Completed work remains supported when the note uses Markdown such as `**Implemented**` or names a technique in inline code such as `Rust`. Retain supported technologies, design patterns, the problem, approach, and verified result while redacting names and sensitive identifiers. Never send an empty evidence list or a title-only replacement. If the notes support no work items, report that range as not replaced and leave its existing work and checkpoints untouched. Keep the returned reference and range unchanged and include `force: true` in the prepared payload. Send with `sync --harness codex --force` (plus `--approved` only after manual approval). If accepted ranges changed and partially overlap the selection, stop and re-discover/re-review the complete ranges instead of guessing boundaries.
 
 Force sync creates missing ranges or replaces existing exact ranges, preserves sync history, and never resets or lowers checkpoints. Automatic retries preserve the accepted result even if another force sync finishes meanwhile. A new invocation is a new explicit force request. Existing AI Profile observations stay unchanged. Do not add force to scheduled sync, approval queues, or file sync. Existing conversations keep their context; start a new chat in Shifu to use the latest work context.
+
+## Continuity preparation and review holds
+
+Scheduled preparation and pending review use bounded original lookback, code-bound entity placeholders and a separate local continuity outbox. Never add continuity fields to a v5 payload or rewrite a frozen queued body. `status` separates preparation, base receipt and companion attachment. A base receipt does not establish successful continuity attachment. Missing server capability leaves the frozen metadata pending. Do not guess a target sync from turn ranges.
+
+A preparation hold survives restarts and stops after two native attempts for unchanged input. Inspect its code-owned reason. Genuine neutral empties stay valid; never create filler evidence to clear a hold. A specific authorized retry of an unqueued held range can use `retry-preparation --harness codex --session-ref <opaque-session> --from-turn <original-start>`; this cannot replay accepted history or regenerate frozen transport. Replacing the key or API endpoint quarantines old checkpoints, queues, local entity dictionaries and continuity metadata. An interrupted replacement holds sync until connect resumes with the same selected connection. Do not upload, display or copy the raw-name dictionary into chat.