docs(gate): document agent-JWT API surface + gate auth_middleware drift#1856
Conversation
… drift The doc-gate is structural (fires on app/route/installer/catalog file add or remove), so behavior changes inside existing route files (the identity epic's canvas + doc-review scopes, per-project grant access) drifted the coordination doc without tripping it. Fixes: - agent-coordination.md now documents the full scoped agent-JWT surface (project_tasks, canvas_read/write, project_doc_review, a2a_send/receive) + the per-project grant model + how external agents onboard (consent / invite). - doc-gate.toml: new 'agent-api' rule so changes to auth_middleware.py require updating that doc (or a Docs-Reviewed trailer); add docs/agent-manual/index.md to the referenced-paths dead-link scan.
Qodo reviews are paused for this user.Troubleshooting steps vary by plan Learn more → On a Teams plan? Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center? |
|
Warning Review limit reached
Next review available in: 16 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. 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: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
![kilo-code-bot[bot]](https://avatars.githubusercontent.com/in/2193792?s=60&v=4){kind=small}
|
|
||
| [[rules]] | ||
| name = "agent-api" | ||
| when_changed = ["tinyagentos/auth_middleware.py"] |
There was a problem hiding this comment.
WARNING: This rule cannot fire on the change it targets — the gate only triggers on structural (add/delete) changes, not modifications.
check_doc_gate.py (lines 165-179) triggers a rule only when a matched path has git status A (added) or D (deleted), explicitly ignoring plain modifications (M) to keep the gate precise. auth_middleware.py already exists, so its allowlist edits will always be M and will never trigger this rule. The rule will only fire if auth_middleware.py is newly created or deleted — neither of which is the intended event ("the agent-token route allowlist changed").
This means the gate this PR claims to add (and that the doc text at agent-coordination.md:123 relies on) provides zero protection against allowlist edits. Either the gate engine needs a modification-aware trigger for this rule, or the claim that "the doc-gate enforces it" is incorrect. Recommend documenting the limitation, or extending the engine (e.g. a on_modify flag per rule) so this rule actually fires.
| - **project_tasks** (the kanban board): `GET /api/projects/{pid}/tasks`, | ||
| `.../tasks/ready`, `.../tasks/{id}`, `.../tasks/{id}/comments` (GET + POST), | ||
| `POST .../tasks/{id}/(claim|release|close|reopen)`, and | ||
| `GET /api/projects/tasks/{id}/context`. Granting project_tasks also makes the |
There was a problem hiding this comment.
SUGGESTION: Route path inconsistency — context uses a different project path shape than the other project_tasks routes.
Every other project_tasks route is documented as /api/projects/{pid}/tasks/... (lines 105-107), but this one is GET /api/projects/tasks/{id}/context — no {pid} segment, and the literal tasks sits directly under projects. This is likely a typo for /api/projects/{pid}/tasks/{id}/context. Even as documentation, an inconsistent path will mislead anyone wiring up or auditing an agent client. Verify against the actual route registration in tinyagentos/routes/ and align it.
Code Review SummaryStatus: 2 Issues Found | Recommendation: Address before merge Overview
Issue Details (click to expand)WARNING
SUGGESTION
Files Reviewed (2 files)
Fix these issues in Kilo Cloud Reviewed by hy3:free · Input: 71K · Output: 3K · Cached: 160.6K |
1 participant
The doc-gate is structural (app/route/installer/catalog file add-or-remove + dead-link invariants). It does NOT catch behavior/content drift inside existing files, so the identity epic's new agent scopes (canvas, doc-review, per-project grant access) drifted
agent-coordination.mdwhile the gate kept passing.agent-apirule so future changes toauth_middleware.py(the agent-token allowlist) require touching that doc or aDocs-Reviewed:trailer; addsdocs/agent-manual/index.mdto the dead-link scan.The remaining gap (a dedicated agent-manual Projects/Canvas page the invite onboarding kit links to) is folded into invite slice S2.