agents-relay 1.0.47 → 1.0.49

package/dist/cli.js

@@ -328,7 +328,7 @@ async function appendPlannedTask(store, job, task) {
     const decision = orchestratorPlanningDecision(job, [task], decisionId, task.parentTaskId, job.tasks.filter(item => item.kind === 'planner').length, 'orchestrator');
     if (!job.tasks.some(item => item.id === decision.id))
         await store.appendTask(decision);
-    const planned = { ...task, parentTaskId: task.parentTaskId ?? null, planningDecisionId: decision.id, planningSource: 'orchestrator', planningRound: decision.planningRound };
+    const planned = { ...task, parentTaskId: decision.id, planningDecisionId: decision.id, planningSource: 'orchestrator', planningRound: decision.planningRound };
     await store.appendTask(planned);
     job.tasks.push(planned, decision);
     return planned;

package/package.json

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

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

@@ -0,0 +1,26 @@
+# Agents Relay Orchestrator Workflows
+
+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:
+
+1. The orchestrator creates the durable job.
+2. The orchestrator immediately creates the required orchestrator-owned task(s); do not leave the P0 job idle.
+3. The current orchestrator thread starts executing those tasks immediately rather than delegating them to another worker.
+4. After implementation, the orchestrator performs/reconciles review against the current head.
+5. If review passes and merge requirements are satisfied, the orchestrator merges the job itself and completes normal post-merge reconciliation.
+
+`job create` still only creates durable job state; the P0 workflow requires the orchestrator to follow it immediately with task creation and execution.

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

@@ -40,29 +40,6 @@ A normal task never merges a PR. After all non-superseded work gates pass, Relay
 
 Final-review routing follows the same worker-selection boundary as executable work. Capability, availability, explicit reviewer constraints, and resource health are hard gates. Among eligible workers, Relay prefers a reviewer with a different worker identity from the implementation tasks; when that is unavailable it prefers a different provider/model, then falls back to the first eligible worker. The selected worker, `selectedBy` reason, and `reviewerRouting` event data are durable evidence. No provider is a universal reviewer default.
 
-## Hotfix workflow
-
-A hotfix is an orchestrator-owned 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:
-
-1. The orchestrator creates the durable job.
-2. The orchestrator immediately creates the required orchestrator-owned task(s); do not leave the P0 job idle.
-3. The current orchestrator thread starts executing those tasks immediately rather than delegating them to another worker.
-4. After implementation, the orchestrator performs/reconciles review against the current head.
-5. If review passes and merge requirements are satisfied, the orchestrator merges the job itself and completes normal post-merge reconciliation.
-
-`job create` still only creates durable job state; the P0 workflow requires the orchestrator to follow it immediately with task creation and execution.
-
 ## Fixed and autonomous jobs
 
 `job create` persists only the durable job. It never creates executable work. The top-level orchestrator owns the initial execution decision and, when the user intends the job to start, submits the first task batch separately. A zero-task autonomous job stays idle and reconciliation must not bootstrap its first planner.