Uh oh!
There was an error while loading. Please reload this page.
fix: v0.2 migration blockers — queue fields, status endpoint, move auth, claim behavior - #99
Merged
Merged
Conversation
Contributor
✅ Automated recommendation: APPROVE Analysis engine: anthropic/MiniMax-M2.7@https://litellm.jory.dev/v1 (anthropic) PR Review: v0.2 Migration BlockersSummaryThis PR addresses v0.2 migration blockers for the Saffron agent, implementing 5 distinct changes across 10 files with comprehensive test coverage. Change-by-Change Findings1. Queue Endpoint Enhancement ( |
| Standard | Status | Notes |
|---|---|---|
Bearer auth (MISSION_CONTROL_AGENT_TOKEN) | ✅ | All mutation endpoints require token |
| AuditLog for state changes | ✅ | Both move and status endpoints write audit entries |
| Proper HTTP status codes | ✅ | 200, 400, 401, 404, 500 correctly used |
Error handling (error instanceof Error) | ✅ | Used in catch blocks |
| No agent-specific names in docs | ✅ | Uses generic agent/* patterns |
Label conventions (status/*) | ✅ | Uses status/backlog, status/in-progress, etc. |
| PR-fix ordering preserved | ✅ | PR-fix items returned first |
Linked Issue Fit
No linked issue context available. The PR body references "Issue #98" but no linked issue details were provided. The PR self-describes addressing 5 migration blockers, and all 5 are implemented:
- ✅ Queue includes
issueIdandrepoFullName - ✅ New
POST /api/issues/statusendpoint - ✅
POST /api/issues/moverequires auth - ✅ Claim behavior clarified (assignment only)
- ✅ Worker migration docs updated
Evidence Provider Findings
No evidence providers configured.
Tool Harness Findings
Tool harness ran with 0 planned/executed requests — no external calls were made.
Unknowns / Needs Verification
Token scoping: The status and move endpoints accept the same
MISSION_CONTROL_AGENT_TOKENfor all agents. No per-agent scoping is implemented. This appears intentional based on existing patterns.Documentation mismatch potential: The
docs/agent-workflow.mdfile contains a reference to claim "optionally moves it tostatus/in-progress" (line 86). This may need updating to reflect the new behavior, though this file was not modified in this PR.Breaking change notice: The removal of auto
status/in-progressfrom claim is a behavior change. The migration docs address this, but existing workers may need updates before deploying this change.
Validation Results
From PR description:
- ✅
npm ci - ✅
npx prisma generate - ✅
npm run lint - ✅
npm run typecheck - ✅
npm run test(352/352 passing) - ✅
npm run build
Recommendation
Approve. The PR correctly implements all 5 described migration blockers with comprehensive test coverage (352 tests passing). Code follows repository conventions, implements proper auth, writes audit logs, and maintains label conventions. The migration documentation accurately reflects the new behavior.
…th, claim behavior - GET /api/agents/[agentName]/queue now returns issueId, repoFullName, and type:'issue' on issue items - PR-fix items remain first in the queue response - Added POST /api/issues/status with bearer auth for explicit status transitions - Replaces existing status/* labels with requested status - Updates GitHub labels, Prisma cache, and writes AuditLog - Accepts agentName/actor as optional actor field - Added MISSION_CONTROL_AGENT_TOKEN bearer auth to POST /api/issues/move - Deprecated in favor of new /api/issues/status for workers - Actor defaults to 'agent', can be overridden via body.actor - Claim no longer auto-transitions to status/in-progress - Claim only assigns agent/* label; status transitions are explicit via /status - Updated worker-cron-prompt-migration.md with correct API payloads - Documents new /api/issues/status endpoint - Clarifies claim behavior (assign-only, explicit status) - Fixes incorrect move payload example (shows oldLabels/newLabels) - All 352 tests pass
joryirvingforce-pushed
the
fix/issue-98-migration-v02
branch
from
May 17, 2026 21:22
49a919d to
80f3e19CompareUh oh!
There was an error while loading. Please reload this page.
4 tasks
joryirving added a commit
that referenced
this pull request
Aug 5, 2026
… on them (#709) * fix(pr-followup): skip informational bot comments instead of blocking on them The comment path ingested every non-author comment on a bot PR as REVIEW_FEEDBACK, so a CI bot posting a size-diff table became a work item: classifyFeedback finds no actionable pattern in markdown, defaults to needs_human, and the PR sits BLOCKED on a human forever. Observed on misospace/llmkube-images#114 — a MERGEABLE, unreviewed PR blocked since 2026-08-04 by an app-size-diff comment reporting +0 B (+0%). Same cause on #46 and #99. The queue read 9 NEEDS_HUMAN items when only informational noise and already-merged PRs were behind them. Gate the comment descriptor on a new isInformationalComment(): sticky comment markers (the sticky-pull-request-comment convention embeds one so the action can update in place, which makes it a structural signal rather than a prose guess) plus dispatch's own pr-fix-blocked notice. An ai-pr-reviewer comment stays ingestible even when it carries a marker — it ships structured findings and is genuine review feedback. Does not address the stale-item half of the same symptom (#692): items already queued when their PR merges are still never reaped. Signed-off-by: Jory Irving <jory.irving@users.noreply.github.com> * fix(test): import vi in pr-followup-ingestion tests The informational-comment tests use vi.restoreAllMocks(); vitest globals make that work at runtime, so the suite passed while tsc and next build failed on TS2304. Signed-off-by: Jory Irving <jory.irving@users.noreply.github.com> --------- Signed-off-by: Jory Irving <jory.irving@users.noreply.github.com> Co-authored-by: Jory Irving <jory.irving@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes all v0.2 migration blockers so Saffron can safely migrate. Addresses 5 problems identified in Issue #98.
Changes
1. Queue now includes
issueIdandrepoFullNameGET /api/agents/[agentName]/queueissue items now include:type: "issue"(PR-fix items keeptype: "pr-review-fix")issueId— the Prisma Issue IDrepoFullName— e.g."org/repo"2. New
POST /api/issues/statusendpointMISSION_CONTROL_AGENT_TOKEN){ issueId, repoFullName, issueNumber, status, agentName?, actor? }status/*labels with the requested statusbacklog,in-progress,in-review,done3.
POST /api/issues/movenow requires bearer auth/api/issues/statusendpoint for status transitionsactorfield in body (defaults to"agent")4. Claim behavior clarified and implemented
agent/*label, does NOT change statusPOST /api/issues/status5. Worker migration docs updated
/api/issues/movepayload (now showsoldLabels/newLabels)/api/issues/statusendpointTests
All 352 tests pass, including:
issueId,repoFullName, andtype: "issue"/api/issues/moverequires bearer authstatus/in-progressValidation
npm ci✅npx prisma generate✅npm run lint✅npm run typecheck✅npm run test✅ (352/352 passing)npm run build✅