@amaster.ai/employee-runtime-connector 0.1.1-beta.288 → 0.1.1-beta.289

package/dist/amaster-runtime-daemon.mjs

@@ -30087,9 +30087,9 @@ function runtimeAuthorizationText(context, mode, {
   ].join(" ") : "";
   const businessOutcomeTerminalContract = !suppressOrdinaryCompletionContract && businessOutcome.mode === "required" ? [
     pendingExecutionStages.length > 0 ? "When producer-owned deliverable requirements are satisfied and the exact current Delivery Manifest is ready when required, record final production evidence with update_parent status in_progress and end the run successfully. Independent review and approval requirements belong to the subsequent configured stages." : delivery.mode === "required" ? delegatedDelivery ? "When every acceptance criterion is satisfied and the exact delegated final-child Manifest and package review remain current, record only the root execution disposition with update_parent status in_progress and a concise evidence summary, then end the run successfully without creating or publishing another package." : "When every acceptance criterion is satisfied and the exact current Delivery Manifest is ready, record the final execution disposition with update_parent status in_progress and a concise evidence summary, then end the run successfully without creating a final review interaction." : "When every acceptance criterion is satisfied, record the final execution disposition with update_parent status in_progress and a concise evidence summary, then end the run successfully without creating a final review interaction.",
-    "The exact runtime_action_in_progress_server_owned rejection is the expected fail-before-effect receipt for this Server-owned handoff. After receiving it, do not retry update_parent with done or another status; end the run successfully so the Server terminal reconciler can take over.",
-    "A ready Delivery Manifest proves only that delivery evidence was registered; it is not Acceptance or an accepted Business Outcome. The expected runtime_action_in_progress_server_owned receipt likewise does not prove finalization. Unless an authoritative Server receipt already confirms acceptance and task completion, state that evidence was submitted and Server terminal validation is pending; do not claim the task is accepted or done. A pre-terminal outcome_not_clean result may reflect a still-running producer; preserve that result without declaring either final success or permanent failure, and do not poll or retry mutations to force closure.",
-    pendingExecutionStages.length > 0 ? "After successful production and terminal evidence validation, the Server must complete the remaining configured execution stages before applying the Business Outcome acceptance policy. Evidence-auto acceptance does not skip independent Review or Approval. Do not create a duplicate final confirmation interaction." : evidenceAutoAcceptance ? delivery.mode === "required" ? delegatedDelivery ? "Only after the run and command succeed does the Server validate the exact delegated final-child Manifest, accepted package review, and terminal Outcome evidence, auto-accept the Outcome, and finalize the issue as done atomically. This evidence-auto path does not create a Board review; report the actual Server-owned terminal disposition without implying a handoff." : "Only after the run and command succeed does the Server validate the exact current Delivery Manifest and terminal Outcome evidence, auto-accept the Outcome, and finalize the issue as done atomically. This evidence-auto path does not create a Board review; report the actual Server-owned terminal disposition without implying a handoff." : "Only after the run and command succeed does the Server validate the terminal Outcome evidence, auto-accept the Outcome, and finalize the issue as done atomically. This evidence-auto path does not create a Board review; report the actual Server-owned terminal disposition without implying a handoff." : delivery.mode === "required" ? delegatedDelivery ? "Only after the run and command succeed does the Server bind the exact delegated final-child Manifest, accepted package review, and terminal Outcome evidence, create the formal Board review before generic continuation handoff is evaluated, and move the issue to in_review. Board acceptance then finalizes the issue as done atomically." : "Only after the run and command succeed does the Server bind the exact current Delivery Manifest and terminal Outcome evidence, create the formal Board review before generic continuation handoff is evaluated, and move the issue to in_review. Board acceptance then finalizes the issue as done atomically." : "Only after the run and command succeed does the Server bind the terminal Outcome evidence, create the formal Board review before generic continuation handoff is evaluated, and move the issue to in_review. Board acceptance then finalizes the issue as done atomically."
+    "The exact runtime_action_in_progress_server_owned rejection is the expected fail-before-effect receipt for this Server-owned handoff. After receiving it, do not retry update_parent with done or another status; end the run successfully so the Server terminal reconciler can take over. An expected execution receipt does not require a separate user update; retain it in the execution record unless the user requested runtime diagnostics.",
+    "A ready Delivery Manifest proves only that delivery evidence was registered; it is not Acceptance or an accepted Business Outcome. The expected runtime_action_in_progress_server_owned receipt likewise does not prove finalization. Unless an authoritative Server receipt already confirms acceptance and task completion, tell the reader in their selected language what was delivered and that final confirmation is still pending; do not claim the task is accepted or done. Describe this practical outcome without copying internal protocol terminology into the reply unless the user requested those technical details. A pre-terminal outcome_not_clean result may reflect a still-running producer; preserve that result in the execution record without declaring either final success or permanent failure, and do not poll or retry mutations to force closure. Explain any actual unresolved effect on the deliverable in the reader's language rather than echoing the protocol status.",
+    pendingExecutionStages.length > 0 ? "After successful production and terminal evidence validation, the Server must complete the remaining configured execution stages before applying the Business Outcome acceptance policy. Evidence-auto acceptance does not skip independent Review or Approval. Do not create a duplicate final confirmation interaction." : evidenceAutoAcceptance ? delivery.mode === "required" ? delegatedDelivery ? "Only after the run and command succeed does the Server validate the exact delegated final-child Manifest, accepted package review, and terminal Outcome evidence, auto-accept the Outcome, and finalize the issue as done atomically. This evidence-auto path does not create a Board review; explain the observed delivery and confirmation status in the reader's selected language without implying that human review is required." : "Only after the run and command succeed does the Server validate the exact current Delivery Manifest and terminal Outcome evidence, auto-accept the Outcome, and finalize the issue as done atomically. This evidence-auto path does not create a Board review; explain the observed delivery and confirmation status in the reader's selected language without implying that human review is required." : "Only after the run and command succeed does the Server validate the terminal Outcome evidence, auto-accept the Outcome, and finalize the issue as done atomically. This evidence-auto path does not create a Board review; explain the observed delivery and confirmation status in the reader's selected language without implying that human review is required." : delivery.mode === "required" ? delegatedDelivery ? "Only after the run and command succeed does the Server bind the exact delegated final-child Manifest, accepted package review, and terminal Outcome evidence, create the formal Board review before generic continuation handoff is evaluated, and move the issue to in_review. Board acceptance then finalizes the issue as done atomically." : "Only after the run and command succeed does the Server bind the exact current Delivery Manifest and terminal Outcome evidence, create the formal Board review before generic continuation handoff is evaluated, and move the issue to in_review. Board acceptance then finalizes the issue as done atomically." : "Only after the run and command succeed does the Server bind the terminal Outcome evidence, create the formal Board review before generic continuation handoff is evaluated, and move the issue to in_review. Board acceptance then finalizes the issue as done atomically."
   ].join(" ") : "";
   const organizationCapabilityAllowed = asRecord(envelope.organizationCapability).allowed === true;
   const organizationMutationAuthorized = allowed.has("organization_mutation");
@@ -30117,7 +30117,8 @@ function runtimeAuthorizationText(context, mode, {
     businessOutcomeOwnershipContract,
     businessOutcomeTerminalContract,
     authorizationContract,
-    exactOrganizationReplay
+    exactOrganizationReplay,
+    completionContract || businessOutcomeOwnershipContract || businessOutcomeTerminalContract || authorizationContract || exactOrganizationReplay ? "Reader-facing handling: the runtime requirements above specify actions and evidence, not a script to narrate. Every assistant text block is immediately visible to the user, including text alongside tool calls; it is not a private execution log. After a routine tool result, make the next tool call directly. Send text only for a requested update, a meaningful change to the requested result, or a needed user action. A successful internal check or an expected protocol receipt is not such a change; do not echo it as a progress message. Write that update directly to the reader in the language selected by the User-Facing Response Contract. Keep exact control-plane identifiers in structured tool arguments and evidence records; link the readable deliverable title in user messages. Requested technical explanations still retain the exact domain identifiers needed by their reader." : ""
   ].filter(Boolean).join("\n");
 }
 function continuationPostconditionGapSection(context, input) {
@@ -33770,7 +33771,7 @@ function assertRequiredTaskAttachmentMaterialized(input, materialized) {
 }
 
 // src/amaster-runtime-daemon.mjs
-var CONNECTOR_VERSION = "0.1.1-beta.288";
+var CONNECTOR_VERSION = "0.1.1-beta.289";
 var CONNECTOR_CONTRACT_VERSION = "2026-06-04.v1";
 var daemonRequire = createRequire(import.meta.url);
 var MAX_CHECKPOINT_BYTES = 20 * 1024 * 1024;

package/dist/amaster-runtime.mjs

@@ -7,7 +7,7 @@ import { homedir, hostname } from "node:os";
 import { fileURLToPath } from "node:url";
 import { BUILD_SUPPORTED_CAPABILITIES } from "./amaster-runtime-daemon/capability-registry.mjs";
 
-const CONNECTOR_VERSION = "0.1.1-beta.288";
+const CONNECTOR_VERSION = "0.1.1-beta.289";
 
 const CONFIG_KEY_MAP = new Map([
   ["server_url", "AMASTER_EMPLOYEE_SERVER_URL"],

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@amaster.ai/employee-runtime-connector",
-  "version": "0.1.1-beta.288",
+  "version": "0.1.1-beta.289",
   "description": "MirrorX runtime connector CLI and daemon",
   "license": "MIT",
   "type": "module",