@rudderhq/agent-runtime-codex-local 0.2.0-canary.12 → 0.2.0-canary.14

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
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@rudderhq/agent-runtime-codex-local",
3
- "version": "0.2.0-canary.12",
3
+ "version": "0.2.0-canary.14",
4
4
  "license": "SEE LICENSE IN LICENSE",
5
5
  "homepage": "https://github.com/Undertone0809/rudder",
6
6
  "bugs": {
@@ -52,7 +52,7 @@
52
52
  "probe:quota": "pnpm exec tsx src/cli/quota-probe.ts --json"
53
53
  },
54
54
  "dependencies": {
55
- "@rudderhq/agent-runtime-utils": "0.2.0-canary.12",
55
+ "@rudderhq/agent-runtime-utils": "0.2.0-canary.14",
56
56
  "picocolors": "^1.1.1"
57
57
  },
58
58
  "devDependencies": {
@@ -88,9 +88,17 @@ For each linked issue:
88
88
  rudder agent inbox --json
89
89
  ```
90
90
 
91
- Work `in_progress` first, then `todo`. Skip `blocked` unless you can actually unblock it.
91
+ Inbox rows include a `relationship` field:
92
92
 
93
- If `RUDDER_TASK_ID` is set and the task is assigned to you, prioritize it first.
93
+ - `assignee`: execution work you own
94
+ - `reviewer`: review work where the issue is in `in_review`
95
+
96
+ Prioritize active close-out work first: reviewer rows with `status:
97
+ "in_review"`, then assignee `in_progress`, then assignee `todo`. Skip
98
+ `blocked` unless you can actually unblock it.
99
+
100
+ If `RUDDER_TASK_ID` is set and the task is assigned to you or names you as
101
+ reviewer, prioritize it first.
94
102
 
95
103
  **Step 4 — Mention-triggered wakes.** If `RUDDER_WAKE_COMMENT_ID` is set, read the relevant issue context before doing anything else on that task:
96
104
 
@@ -135,6 +143,35 @@ rudder issue comments list "<issue-id-or-identifier>" --after "<last-comment-id>
135
143
 
136
144
  Before exiting an active `todo` or `in_progress` issue run, leave exactly one clear close-out signal. Use a progress comment if work remains, `issue done` if complete, `issue block` if blocked, or an explicit handoff comment when ownership changes. Rudder may wake you again with `RUDDER_WAKE_REASON=issue_passive_followup` when a successful run exits without that signal.
137
145
 
146
+ Before exiting a reviewer run or an inbox row with `relationship: "reviewer"`,
147
+ leave exactly one structured reviewer decision. Do not rely on free-form
148
+ comments such as "reject" or "accepted" as the durable outcome:
149
+
150
+ - approve:
151
+
152
+ ```bash
153
+ rudder issue review "<issue-id-or-identifier>" --decision approve --comment "<markdown>" --json
154
+ ```
155
+
156
+ - request changes and return the issue to the assignee:
157
+
158
+ ```bash
159
+ rudder issue review "<issue-id-or-identifier>" --decision request_changes --comment "<markdown>" --json
160
+ ```
161
+
162
+ - keep the issue in review because specific evidence or follow-up is still
163
+ missing:
164
+
165
+ ```bash
166
+ rudder issue review "<issue-id-or-identifier>" --decision needs_followup --comment "<markdown>" --json
167
+ ```
168
+
169
+ - block the issue:
170
+
171
+ ```bash
172
+ rudder issue review "<issue-id-or-identifier>" --decision blocked --comment "<markdown>" --json
173
+ ```
174
+
138
175
  - progress-only update:
139
176
 
140
177
  ```bash
@@ -213,6 +250,11 @@ Planning rules:
213
250
  - Self-assign only on explicit @-mention handoff.
214
251
  - Always communicate before exit on active work, except blocked issues with no new context.
215
252
  - Treat `issue_passive_followup` as close-out governance, not a fresh assignment: inspect current state, then comment, finish, block, or hand off explicitly.
253
+ - Treat `issue_review_closeout_missing` as review close-out governance: inspect
254
+ current state, then record one structured review decision.
255
+ - A reviewer does not take over implementation unless explicitly asked.
256
+ - A reviewer request for changes must use `rudder issue review --decision
257
+ request_changes`, not only a reject comment.
216
258
  - If blocked, explicitly set the issue to `blocked` with a blocker comment before exit.
217
259
  - Never cancel cross-team tasks. Reassign upward with explanation.
218
260
  - Use `chainOfCommand` for escalation.
@@ -14,7 +14,7 @@ Stable CLI contract for agents using the bundled `rudder` skill. Prefer these co
14
14
  | Command | Description | Mutating | Org | Agent | Run ID |
15
15
  | --- | --- | --- | --- | --- | --- |
16
16
  | `rudder agent me` | Show the authenticated agent identity, budget, and chain of command. | no | no | no | no |
17
- | `rudder agent inbox` | List the compact assigned-work inbox for the authenticated agent. | no | no | no | no |
17
+ | `rudder agent inbox` | List the compact assignee and reviewer work inbox for the authenticated agent. | no | no | no | no |
18
18
  | `rudder agent capabilities` | List the stable Rudder agent command contract. | no | no | no | no |
19
19
  | `rudder agent skills sync <agent-id>` | Sync the desired enabled skill set for an agent. | yes | no | no | attached when available |
20
20
  | `rudder issue get <issue>` | Read a full issue by UUID or identifier. | no | no | no | no |
@@ -24,6 +24,7 @@ Stable CLI contract for agents using the bundled `rudder` skill. Prefer these co
24
24
  | `rudder issue comments list <issue>` | List issue comments, optionally only newer comments after a cursor. | no | no | no | no |
25
25
  | `rudder issue comments get <issue> <comment-id>` | Read one issue comment by id. | no | no | no | no |
26
26
  | `rudder issue update <issue> ...` | Apply generic issue updates when workflow commands are not enough. | yes | no | no | attached when available |
27
+ | `rudder issue review <issue> --decision <decision> --comment <text>` | Record a structured reviewer decision with a required comment. | yes | no | no | attached when available |
27
28
  | `rudder issue done <issue> --comment <text>` | Mark an issue done with a required completion comment. | yes | no | no | attached when available |
28
29
  | `rudder issue block <issue> --comment <text>` | Mark an issue blocked with a required blocker comment. | yes | no | no | attached when available |
29
30
  | `rudder issue release <issue>` | Release an issue back to todo and clear ownership. | yes | no | no | attached when available |
@@ -52,6 +53,17 @@ Before a successful `todo` or `in_progress` issue run exits, leave one close-out
52
53
 
53
54
  If `RUDDER_WAKE_REASON=issue_passive_followup`, the run is close-out governance for the same issue. Inspect current issue state first, then leave a progress comment, completion, blocker, or explicit handoff.
54
55
 
56
+ ## Reviewer Close-Out Signals
57
+
58
+ When the inbox row or wake context says `relationship: "reviewer"`, `role: "reviewer"`, or `wakeSource: "review"`, finish the review with one structured reviewer decision:
59
+
60
+ - approve: `rudder issue review <issue> --decision approve --comment <text>`
61
+ - request changes: `rudder issue review <issue> --decision request_changes --comment <text>`
62
+ - needs follow-up: `rudder issue review <issue> --decision needs_followup --comment <text>`
63
+ - blocked: `rudder issue review <issue> --decision blocked --comment <text>`
64
+
65
+ Do not rely on a free-form reject or accept comment as the review outcome. The structured decision is the durable close-out signal.
66
+
55
67
  ## Compatibility Commands
56
68
 
57
69
  - `rudder agent list --org-id <id>` — List agents for an organization.