agents-relay 1.0.122 → 1.0.124

package/dist/reconciler.js

@@ -56,7 +56,7 @@ For a direct non-sandbox local worker, use NEO_EVENTS_EMIT when the caller provi
 As your FIRST execution action, before reading files, editing code, running commands, or doing other work,
 you MUST publish exactly one canonical task.started event for this exact Job/Task.
 
-You MAY publish progress events while working.
+${task.adapter === 'chatgpt' ? `Because ChatGPT execution continues asynchronously after the submit process exits, you MUST keep reporting liveness while the task is active. Publish meaningful progress/milestone events when there is real progress to report. If no meaningful milestone has been published for 30 seconds during active work, publish a non-terminal task.heartbeat event with status running, visibility orchestrator, this exact source.id, and a concise description of the current operation. Continue heartbeats after each further 30 seconds of active silence until a terminal task event is published. Do not invent percentage progress.` : `You MAY publish progress events while working. For long silent active work, follow the events-bus heartbeat policy.`}
 Before returning or allowing the worker process to exit, you MUST publish exactly one canonical terminal event:
 - task.completed only after the declared output is durable;
 - task.failed for implementation, tool, command, test, patch, commit, push, runtime, or other execution failure that prevents completion;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "agents-relay",
-  "version": "1.0.122",
+  "version": "1.0.124",
   "description": "Durable async agent jobs coordinated through GitHub pull requests",
   "type": "module",
   "bin": {

package/skills/agents-relay/contracts/orchestrator-workflows.md

@@ -6,17 +6,6 @@ Before `job create`, the orchestrator converts the relevant discussion into a st
 
 This contract defines orchestrator-owned exception workflows that sit above normal Agents Relay task/job execution.
 
-## Hotfix workflow
-
-A hotfix is a fast path for a live blocking problem:
-
-1. The current active orchestrator thread patches the live/runtime target directly.
-2. It immediately reproduces the failure and verifies the fix against the live runtime.
-3. Once verified, the same logical fix is applied to canonical `main`, tested, committed, and pushed.
-4. The orchestrator completes the normal post-merge/publish reconciliation and cleanup.
-
-Do not create a blocking job/PR before fixing the live runtime. Keep the hotfix minimal and do not leave the live patch as the only durable implementation.
-
 ## P0 / self job workflow
 
 A **P0 job** (alias: **self job**) is executed directly by the current active orchestrator thread:

package/skills/agents-relay/contracts/task-job-contract.md

@@ -73,7 +73,7 @@ Every worker task has one of three story sizes:
 
 Relay derives the overall execution timeout from `storySize`. If `routing.reasoning` is `high`, Relay doubles the overall execution timeout. Other reasoning levels do not change it.
 
-Raw `timeoutMs` is a compatibility/debug/hotfix override, not the normal task-production interface.
+Raw `timeoutMs` is a compatibility/debug override, not the normal task-production interface.
 
 ## Task readiness states
 
@@ -107,7 +107,7 @@ Blocker resolution is generation-safe and idempotent: Relay retries a dependent
 
 ## Worker lifecycle
 
-Relay owns process lifecycle. Workers own semantic task lifecycle. A worker must publish canonical `task.started` as its first execution action, then exactly one of `task.completed`, `task.failed`, `task.blocked`, or `task.cancelled`. Process launch/exit events do not substitute for worker semantic events.
+Relay owns process lifecycle. Workers own semantic task lifecycle. A worker must publish canonical `task.started` as its first execution action, then exactly one of `task.completed`, `task.failed`, `task.blocked`, or `task.cancelled`. Process launch/exit events do not substitute for worker semantic events. Because the ChatGPT worker continues asynchronously after its submit process exits, its managed execution prompt must also require the shared events-bus liveness rule: publish meaningful progress when available, and publish non-terminal `task.heartbeat` after each 30 seconds of otherwise silent active work until a terminal task event is emitted.
 
 Relay allocates the durable `executionId` before launching model-backed work and gives that worker one exact event source identity: `job/<job-id>/task/<task-id>/execution/<execution-id>`. Every semantic lifecycle event from that execution must copy the identity verbatim in `source.id`. Relay correlates model-worker lifecycle only by this execution identity; `source.agent`, `source.component`, provider/adapter names, and `data.worker_owned` are diagnostic/legacy metadata and MUST NOT authorize or correlate lifecycle state. A retry receives a new execution identity, so events from an older execution are ignored.