docs(agent-ops): close late ledger review gaps - #109
Conversation
|
@codex review |
|
Warning Review limit reached
Next review available in: 54 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 751453b5ed
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
@codex review |
a9512f3 to
2c9cb0b
Compare
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 2c9cb0b770
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 2ae3b370c3
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: c879155e20
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
|
||
| `evidenceRevision` is required when `uri` is repository-relative and is normalized into `task_evidence.evidence_revision`; REST accepts the same field in the evidence request body. `takeover_task_lease` is exposed only to a validated user actor with `task.lease.takeover`, never to a shared-secret or agent-only context. | ||
|
|
||
| Handoff acknowledgement is recipient-scoped. For `to_actor_type = 'agent'` or `'user'`, the authenticated actor ID must equal `to_actor_id`. Only `pending -> acknowledged` or `pending -> declined` is accepted through the acknowledgement tool. A privileged human with `task.handoff.override` may perform the transition for recovery only when supplying the bounded `reason`; the event is named `handoff.acknowledgement_overridden` and never masquerades as recipient acceptance. |
There was a problem hiding this comment.
For user-addressed handoffs acknowledged through REST, this equality compares incompatible identities: creation persists the registry UUID, while the current REST actor context uses the JWT sub directly (backend/src/taskUtils.ts:14-20), with users.external_id being the field intended to hold that external subject. Unless those values coincidentally match, the intended authenticated recipient cannot acknowledge or decline the handoff; require REST actor construction to resolve the session subject to the active registry record before applying this check.
Useful? React with 👍 / 👎.
| ``` | ||
|
|
||
| Handoff creation resolves every evidence ID inside the transaction and supplies the route task ID to the join row. The composite foreign keys prevent cross-task and cross-project evidence attachment. Handoff text is bounded and user-visible. It contains a summary, next action, blocker, and evidence references—not a transcript or chain of thought. A pending handoff is coordination state, not proof that the recipient accepted ownership. | ||
| Handoff creation resolves every evidence ID inside the transaction and supplies the route task ID to the join row. It also resolves `to_actor_id` against the active user or agent registry for the declared type and rejects unknown, inactive, or type-mismatched recipients with `422 invalid_handoff_recipient`; display names or request-body claims are never persisted as identity. The composite foreign keys prevent cross-task and cross-project evidence attachment. Handoff text is bounded and user-visible. It contains a summary, next action, blocker, and evidence references—not a transcript or chain of thought. A pending handoff is coordination state, not proof that the recipient accepted ownership. |
There was a problem hiding this comment.
When an agent has active = true but status = 'disabled', this rule can still accept it because the registry models those fields independently (backend/src/db/schema.ts:107-117) and allows that combination through PATCH. Such a recipient should not receive actor credentials and therefore cannot acknowledge the persisted handoff; explicitly reject status = 'disabled' in addition to inactive records and cover this state in the recipient tests.
Useful? React with 👍 / 👎.
1 participant
Outcome
Closes five substantive Codex findings that arrived on merged PR #107 after its merge.
Contract fixes
Verification
Documentation contract only; no runtime enforcement or identity mechanism is claimed as delivered.