agents-relay 2.0.104 → 2.0.105

package/dist/planner.js

@@ -392,7 +392,7 @@ export function validatePlannerResolutionMaterialization(existing, specs) {
     const owned = unresolved.filter(task => task.resolution && ['active', 'waiting'].includes(task.resolution.state));
     const uncovered = unresolved.filter(task => !resolvedIds.has(task.id) && !owned.some(candidate => candidate.id === task.id));
     if (uncovered.length > 0 && specs.length > 0)
-        throw new Error(`Planner cannot create sibling replacement work while unresolved Task(s) lack a graph resolution: ${uncovered.map(task => task.id).join(', ')}`);
+        throw new Error(`Planner cannot create sibling replacement work while unresolved Task(s) lack a graph resolution: ${uncovered.map(task => task.id).join(', ')}. Correct next_tasks by adding resolution: {"path":"same_job_dependency","targetTaskId":"<unresolved original task id>","rootCause":"<evidence>","solution":"<how new task resolves original>"} to each relevant recovery Task. The targetTaskId must refer to the FAILED/BLOCKED original, not the new Task. Do not bypass this check or mark work satisfied without evidence.`);
 }
 export function parsePlannerOutput(output) {
     const trimmed = output.trim();

package/package.json

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

package/skills/agents-relay/agents/planner.agent.md

@@ -87,6 +87,9 @@ Do not create separate Tasks merely for "analyze", "format", "call tool", "check
 - If satisfied, return `objective_status: "satisfied"` and `next_tasks: []`.
 - Otherwise return only the next useful executable batch from the graph-derived Task boundaries.
 - Do not repeat completed work or recreate an existing Task unless replacement work is explicitly needed.
+- **Resolution is mandatory for replacement work:** before returning any `next_tasks`, inspect every existing `FAILED` or `BLOCKED` work Task. If it lacks an active/waiting `resolution` and the proposed batch creates related/sibling work, explicitly cover it with a valid `resolution` on the new recovery Task. For a same-Job recovery child, use `"resolution":{"path":"same_job_dependency","targetTaskId":"<existing failed/blocked task ID>","rootCause":"<confirmed cause or stated uncertainty>","solution":"<how the new task resolves the original>"}`. `targetTaskId` identifies the **existing unresolved Task**, not the new Task. Keep the recovered work semantically under the original artifact's subtree. Do not invent a resolution or silently cancel unrelated failed work.
+- **On `retry_feedback`:** treat the feedback as Relay's authoritative validation error for the previous output in this **same Plan**. Correct the JSON proposal and all uncovered resolution targets; do not replay the same sibling Tasks unchanged. Preserve the intent and evidence already found, and return one fully corrected result. If no safe resolution can be justified, do not invent a successful outcome.
+
 - Prefer independently verifiable Tasks with stable IDs, but do not split work solely to make Tasks smaller.
 - When a Task depends on mutable repository or product state, distinguish a frozen evidence target from the current execution head. A SHA may freeze that Task's own review/source evidence, but do not copy an upstream SHA into a dependent release, deploy, publication, or other follow-on Task unless the objective explicitly requires that same frozen target. After dependencies complete, downstream Tasks must resolve and verify the current durable Job/PR head before acting.
 - When fresh UI, browser, store, runtime, or visual evidence is material to the Task outcome, say so explicitly in the Task input and require evidence from the real current state. Existing screenshots, prepared assets, or prior observations are not substitutes for fresh evidence unless the objective explicitly allows reuse.