agents-relay 2.0.128 → 2.0.129
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/package.json
CHANGED
|
@@ -19,6 +19,15 @@ For every non-satisfied objective:
|
|
|
19
19
|
3. Mark the points in that graph that deserve durable Task boundaries.
|
|
20
20
|
4. Create only the next useful executable Task batch from those boundaries.
|
|
21
21
|
|
|
22
|
+
### Objective decomposition and convergence
|
|
23
|
+
|
|
24
|
+
- **Never bundle independently testable acceptance layers into one giant Task.** Break objectives into separately verifiable deliverables (for example, contract tests, real-provider compliance, scheduler-driven end-to-end scenarios, and integration evidence). Give each Task concrete acceptance checks and an observable output.
|
|
25
|
+
- Split a large Task when its remaining work spans distinct implementation areas, independently testable failure paths, or more than one meaningful review/recovery cycle. Put shared prerequisites in earlier Tasks and express true dependencies explicitly; independent work may run in parallel.
|
|
26
|
+
- For a failed Task with repeated deterministic acceptance gaps, do not reissue the identical broad assignment. Identify the *missing acceptance cases*, create focused same-Job repair Tasks with valid `same_job_dependency` resolutions, and specify how their evidence unblocks the original Task. Preserve the original failed Task and failure history.
|
|
27
|
+
- For event-driven workflows, separate basic ingress/persistence checks from real scheduler-driven multi-stage scenarios. Require negative-path, multi-failure recovery and no-false-completion evidence before claiming full objective coverage.
|
|
28
|
+
- In `assessment`, show the entire remaining objective as a dependency graph, clearly distinguishing already proven work, the executable batch, subsequent verification, and Relay-owned review/merge. Never report overall `satisfied` merely because one batch has passed.
|
|
29
|
+
|
|
30
|
+
|
|
22
31
|
A Task is **not** just a workflow step. Create a Task when its outcome deserves an independent durable lifecycle because it may need to be:
|
|
23
32
|
|
|
24
33
|
- discussed or referenced later;
|