agents-relay 1.0.47 → 1.0.48
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
|
@@ -0,0 +1,14 @@
|
|
|
1
|
+
# Agents Relay Orchestrator Workflows
|
|
2
|
+
|
|
3
|
+
This contract defines orchestrator-owned exception workflows that sit above normal Agents Relay task/job execution.
|
|
4
|
+
|
|
5
|
+
## Hotfix workflow
|
|
6
|
+
|
|
7
|
+
A hotfix is a fast path for a live blocking problem:
|
|
8
|
+
|
|
9
|
+
1. The current active orchestrator thread patches the live/runtime target directly.
|
|
10
|
+
2. It immediately reproduces the failure and verifies the fix against the live runtime.
|
|
11
|
+
3. Once verified, the same logical fix is applied to canonical `main`, tested, committed, and pushed.
|
|
12
|
+
4. The orchestrator completes the normal post-merge/publish reconciliation and cleanup.
|
|
13
|
+
|
|
14
|
+
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.
|
|
@@ -40,17 +40,6 @@ A normal task never merges a PR. After all non-superseded work gates pass, Relay
|
|
|
40
40
|
|
|
41
41
|
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.
|
|
42
42
|
|
|
43
|
-
## Hotfix workflow
|
|
44
|
-
|
|
45
|
-
A hotfix is an orchestrator-owned fast path for a live blocking problem:
|
|
46
|
-
|
|
47
|
-
1. The current active orchestrator thread patches the live/runtime target directly.
|
|
48
|
-
2. It immediately reproduces the failure and verifies the fix against the live runtime.
|
|
49
|
-
3. Once verified, the same logical fix is applied to canonical `main`, tested, committed, and pushed.
|
|
50
|
-
4. The orchestrator completes the normal post-merge/publish reconciliation and cleanup.
|
|
51
|
-
|
|
52
|
-
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.
|
|
53
|
-
|
|
54
43
|
## P0 / self job workflow
|
|
55
44
|
|
|
56
45
|
A **P0 job** (alias: **self job**) is executed directly by the current active orchestrator thread:
|