Verify-then-fix: #2320 promote-PR's 20 unaddressed bot findings on current dev (headline: project_notes scope binding, CR-Critical)

[jaylfc]

CARD TITLE (intent, not commit subject): Verify-then-fix: #2320 promote-PR's 20 unaddressed bot findings on current dev (headline: project_notes scope binding, CR-Critical)

Autonomous build of board card tsk-iup5rd.

Files:
.../tsk-iup5rd-project-notes-scope-binding.md | 2 +
tests/test_project_notes_bug.py | 86 ++++++++++++++++++++++
tinyagentos/routes/agent_auth_requests.py | 2 +-
3 files changed, 89 insertions(+), 1 deletion(-)

[coderabbitai]

Warning

Review limit reached

@jaylfc, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 13 minutes

Limit details: You’ve used all 2 included reviews currently available under your plan.

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 @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

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 configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: bbf4644e-d6c7-45fc-b05e-6b5a90024404

📥 Commits

Reviewing files that changed from the base of the PR and between 1a2bdb2 and 19168c3.

📒 Files selected for processing (3)

• changelog.d/tsk-iup5rd-project-notes-scope-binding.md
• tests/test_project_notes_bug.py
• tinyagentos/routes/agent_auth_requests.py

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[gitar-bot]

Important

You are using the Gitar free plan. Upgrade to unlock code review, CI analysis, auto-apply, custom automations, and more.

_Gitar

[jaylfc]

nemotron-super review

VERDICT: No blocking issues found
No blocking issues found.

Automated first-pass review by the nemotron-super lane. The lead still reviews before merge.

[qodo-code-review]

ⓘ Qodo reviews are paused because your trial has ended. Ask your workspace admin to add credits to resume reviews. Manage billing

[kilo-code-bot]

WARNING: Adding project_notes to _PROJECT_SCOPES introduces a project-binding requirement but the membership-creation logic below does not handle it

With this change, granting project_notes (with a valid project_id) now passes the 400 guard at line 435 (needs_project = bool(set(granted_scopes) & _PROJECT_SCOPES)). However, the add_member call at line 617 only fires for "project_tasks" or canvas scopes — the agent receives a project-bound grant without being added to project_members. The same gap exists at line 715 in add_agent_to_project. The result: an agent holds a project-scoped credential for project_notes but has no membership row, inconsistent with project_tasks and the other _PROJECT_SCOPES members. Fix: include project_notes (and project_lists, which shares the same gap) in the membership condition at lines 617 and 715.

---

Reply with @kilocode-bot fix it to have Kilo Code address this issue.

[kilo-code-bot]

Code Review Summary

Status: 1 Issue Found | Recommendation: Address before merge

Overview

Severity	Count
WARNING	1

Issue Details (click to expand)

WARNING

File	Line	Issue
tinyagentos/routes/agent_auth_requests.py	219	Adding project_notes to _PROJECT_SCOPES creates a project-binding guard but add_member at line 617 only fires for project_tasks/canvas scopes — agents granted project_notes with a valid project_id receive a project-bound grant without a project_members row. Same gap at line 715 in add_agent_to_project.

Files Reviewed (3 files)

• changelog.d/tsk-iup5rd-project-notes-scope-binding.md
• tests/test_project_notes_bug.py
• tinyagentos/routes/agent_auth_requests.py - 1 issue

Fix these issues in Kilo Cloud

---

_{Reviewed by step-3.7-flash · Input: 50.1K · Output: 9K · Cached: 350.2K}

[jaylfc]

Lead review — HELD, closing. Superseded by board card tsk-rbblkf (BASE: exec/tsk-iup5rd).

The core fix is right and will be carried forward: project_notes belongs in _PROJECT_SCOPES (approval could previously mint an unbound grant), and the new 400-on-unbound-approve test is red-provable. But the PR cannot merge as-is:

1. Real CI red — the _PROJECT_SCOPES pin test was not updated. tests/test_agent_scope_requests.py::test_project_scope_set_is_a_single_definition pins the set's exact contents precisely so a change to it is a conscious act; the set changed, the pin didn't. Reproduced on this head: FAILED … test_project_scope_set_is_a_single_definition, rc=1 (measured directly). The other 5 red shards are fail-fast cancellation victims (conclusion=cancelled, no failed steps) — only this one failure is real.
2. doc-gate red is legitimate: an API route module and agent-facing behaviour changed (approval now requires a project binding for project_notes), so docs/agent-coordination.md needs a real edit, not a trailer.
3. Card contract unmet: tsk-iup5rd required a disposition for all 20 findings from the release: promote dev to master (v1.0.0-beta.47) #2320 audit list — commits red-first for confirmed ones, one-line evidence notes in the PR body for stale ones. This PR addresses 1 of 20 with no disposition notes.
4. False premise in the test docstring: it claims an unbound grant made notes "usable cross-project". It did not — check_agent_scope_for_project (agent_token_auth.py:205) only authorizes a grant whose project_id equals the requested project, and the middleware exposes agents only the four project-bound notes routes. An unbound grant authorized nothing; the real defect was minting an inert grant. The record must say what the fix actually cures.

Bot findings adjudicated: Kilo WARNING declined — project_notes grants creating no project_members row matches the existing convention (project_lists and the files scopes are in _PROJECT_SCOPES and also skip add_member); notes authorization is grant-gated only and never reads project_members, verified in agent_token_auth.py:205-245. nemotron: no blocking issues. CodeRabbit: rate-limit stub only (bot-review-gate red is that mechanism working as designed).