@granular-software/sdk 0.4.34 → 0.4.36

package/dist/agent-harness.js

@@ -941,12 +941,11 @@ function buildContinuationInstruction(resultPreview) {
     "Continue the same user request using the latest structured session state.",
     "Take only the minimum next step that directly helps the user.",
     "Use the active tasks, decisions, prompts, and heap references as the source of truth instead of replaying old work.",
-    "If the user names a concrete record that is not already in the heap, fetch it from the graph instead of replying that it is not in context.",
+    "If the user names a concrete record that is not already in the heap, resolve it from the graph before saying it is missing: try a broad search, then a small set of normalized/fuzzy variants or a paged scan when the domain supports it.",
+    "If the request needs all matching records, use iterate(...) or page until hasMore is false. A single list(...) or page(...) call is only one page.",
     "If this request clearly spans multiple steps and there are no active tasks yet, create 2-4 short user-visible tasks now.",
     "Reuse any existing taskId and decisionId values exactly as they appear in AGENT LOOP STATE.",
-    "Use ask_user with type input for open-ended preferences or missing text. Use type choice only for a short explicit shortlist.",
-    "Do not ask for confirmation in plain text. Use loop.confirm(...) when approval is needed.",
-    "Await loop.ask_user(...) and loop.confirm(...). Those helpers pause the current job and resume it after the user answers.",
+    "When progress depends on the user's choice, missing detail, or approval, use loop.ask_user(...) or loop.confirm(...) so the job pauses and resumes through the live workflow.",
     "After a resumed ask_user or confirm call, continue the same job and perform the newly authorized action when the answer is sufficient. Do not stop with placeholder text like 'I'm ready to do it next.'",
     "If you ask the user a new question in this job, do not also close the loop in the same job.",
     "Write the smallest straightforward code for the current step. Avoid defensive fallback branches for hypothetical states that are not currently true.",
@@ -1134,12 +1133,13 @@ ${loopBlock}
 - Continue from the latest structured state. Treat WORKFLOW SNAPSHOT, EXECUTION CHECKPOINT, RECENT REFERENTS, SESSION HEAP, and AGENT LOOP STATE as the working memory for this request.
 - Use CAPABILITY SNAPSHOT to choose the next step, then use DOMAIN REFERENCE for exact signatures and query shapes.
 - Take the minimum next step that directly helps the user. Avoid duplicate work, speculative cleanup, or extra fetching that is not needed yet.
-- If the user names a record that is not already in the heap, fetch it from the graph instead of saying it is not in context.
-- Treat user-provided names as human references, not exact keys. If one strong partial match exists, use it. If several plausible matches exist, ask the user to choose.
 - Use RECENT REFERENTS to resolve follow-up references across turns, such as "that invoice", "that customer", "those products", or "the other one".
+- Treat user-provided names, numbers, and labels as human references, not exact keys. Resolve them with code: check recent referents/heap first, then query the graph with the broadest supported \`search\` or \`filter\`, then retry with a few normalized/fuzzy/prefix variants when the first pass is empty or ambiguous. Only say a record does not exist after a reasonable lookup across the relevant class.
+- If one strong match exists, use it. If several plausible matches remain, use \`loop.ask_user({ type: 'choice', ... })\` with the grounded candidates instead of guessing.
 - If the request has more than one reasonable interpretation, ask the user to clarify instead of guessing.
 - For comparisons, rankings, selections, or summaries, first identify the rule you are using. If that rule is not clear from the user request and DOMAIN REFERENCE, ask the user before choosing anything.
 - When the ranking, comparison, or selection rule is unclear, the minimum next step is the clarification itself. Do not run a placeholder query for a provisional winner before asking.
+- If a user request matches both a domain type/effect and a loop helper, prioritize the domain type/effect. For example, if DOMAIN REFERENCE contains a \`Task\` class and the user asks to create a task, create the domain task record; do not call \`loop.create_task(...)\` unless you are only tracking your own workflow.
 - Reuse exact \`taskId\`, \`decisionId\`, and \`closureId\` values from AGENT LOOP STATE. Never invent or rewrite them.
 - If the request is ambiguous or clearly multi-step, create 2-4 short user-visible tasks and keep them updated as the workflow advances.
 - Use \`loop.ask_user({ type: 'choice', options: [...] })\` when you have a short, grounded shortlist the user can choose from. Otherwise use \`type: 'input'\`.
@@ -1150,6 +1150,14 @@ ${loopBlock}
 - Use \`loop.open_decision(...)\` to persist grounded candidates, \`loop.close_decision(...)\` to resolve one, and \`loop.close_loop(...)\` when the workflow is completed, canceled, or blocked.
 - If you ask a new question in the current job, do not also close the loop in that same job.
 
+\u2500\u2500\u2500 LOOP HELPER REFERENCE \u2500\u2500\u2500
+- \`loop.ask_user(...)\`: pause the current job for missing input; use \`type: 'choice'\` only for a short grounded shortlist.
+- \`loop.confirm(...)\`: pause for yes/no approval before a consequential action, then branch on the returned boolean.
+- \`loop.open_decision(...)\`: save explicit candidates that later jobs can revisit; each candidate needs an \`id\`.
+- \`loop.close_decision(...)\`: resolve an open decision with a stored \`selectedId\` and optional rationale.
+- \`loop.create_task(...)\`, \`loop.update_task(...)\`, \`loop.complete_task(...)\`: keep a short resumable task list for the agent's workflow; these are not domain \`Task\` records.
+- \`loop.close_loop(...)\`: record the workflow outcome when it is completed, canceled, or blocked.
+
 \u2500\u2500\u2500 CODE RULES \u2500\u2500\u2500
 - Import from \`./sandbox-tools\`.
 - If you use \`heap\`, \`loop\`, \`agent_text_message\`, or \`agent_heap_objects\`, import them explicitly from \`./sandbox-tools\`.
@@ -1159,6 +1167,7 @@ ${loopBlock}
 - Use \`ClassName.get({ path })\` only for known graph paths when you want a direct graph fetch.
 - Use \`ClassName.count()\` for totals, \`ClassName.page({ page, perPage, saveAs })\` when you need \`items\` plus \`totalCount\` or \`hasMore\`, \`ClassName.list({ page, perPage, saveAs })\` for one page of records, and \`ClassName.iterate({ perPage, maxItems })\` for large scans.
 - \`perPage\` defaults to \`100\` and is capped at \`100\`.
+- A single \`list(...)\` or \`page(...)\` call never proves there are no more records. For "all", "every", exports, broad scans, or exhaustive searches, use \`iterate(...)\` when available or loop \`page(...)\` until \`hasMore\` is false.
 - Push \`filter\`, \`search\`, and \`sort\` into graph queries instead of fetching a page and processing it locally.
 - A property appearing on a record does not make it valid in \`filter\` or \`sort\`; only use fields and operators that are explicitly exposed in DOMAIN REFERENCE.
 - Choose \`sort.field\` verbatim from the sortable fields listed in DOMAIN REFERENCE. Do not sort by relationship names, related-record collections, counts, totals, or other derived metrics unless they are explicitly listed as sortable.