Uh oh!
There was an error while loading. Please reload this page.
docs(kanban): the header names a Status option the board does not have - #362
Merged
Merged
Conversation
set-pr-status.yml's header said the non-draft card moves to "In review". That option was renamed "In review" -> "Code review" in #20 (7dbaabf) and no longer exists on the board -- verified against the live Status field, whose options are Backlog, North Stars, Ready, In progress, Code review, On dev, Staging (agent review), FR on staging, Ready for prod, Prod, Done, Cancelled. The code has been correct throughout: the job writes `status_name=Code review` (:108), and the same header already says "the SAME event that puts a card in `Code review`" thirty lines further down. So the file disagreed with itself, and the wrong half is the part a reader meets first. Comment-only. No workflow logic, no behaviour change. Swept the repo for the same phrasing; this was the only board reference. Two other matches are deliberately left alone: repo-inventory.yml:635 uses "while this PR was in review" to mean review as an activity, which is correct English and not a column name, and standards-sync-selftest.py:428 is a Python `in` operator, not the phrase. make check: 95 passed 0 failed, 29 passed 0 failed, EXIT=0.
saadqbal
approved these changes
Aug 27, 2026
saadqbal
left a comment
Collaborator
There was a problem hiding this comment.
Checked rather than taken: the code writes status_name=Code review at line 108, so the header comment was the only thing still saying In review. Reading the live Status options before editing rather than trusting the rename in #20 is the right instinct for exactly this kind of fix — a comment corrected from memory can be wrong twice.
Green, one line, no behaviour. 👍
Uh oh!
There was an error while loading. Please reload this page.
LukasWodka added a commit
that referenced
this pull request
Aug 28, 2026
…end#2731) (#370) * ci(set-status): add the missing card instead of losing the race (backend#2731) set-status and add-to-kanban fire on the same pull_request event and start together. set-status polled 5 x 5s for the card and failed when it was not there; add-to-kanban frequently won seconds later, so the card ended CORRECT and the check ended RED. On .github#362 the board was already in the exact state set-status would have written -- the job did its work and reported failure anyway, which is the shape that teaches people to merge past red. The old comment held the retry budget at 5 x 5s deliberately, to measure how often the race is lost rather than guess a window. That measurement arrived (#361 and #362, both within seconds), so this ends the race instead of widening the window: the job already holds a token with organization-projects: write, and addProjectV2ItemById is idempotent, so it adds the card itself when it is absent. add-to-kanban does exactly one thing -- an actions/add-to-project step -- so there is nothing to duplicate. Still fail-closed: an unresolvable PR node, or an add that returns no item id, goes red exactly as before. Only "not yet" stops reporting as "missing". Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * test(set-status): cover the card fallback, and mutate both halves (backend#2731) Nothing covered set-pr-status.yml_s status-write block. The closing-ref suite already owns assertions about that file, so the four new checks live there. Scope stated in the file rather than implied: these read the workflow SOURCE, so they cannot prove the fallback works against the real API -- and this repo_s own caller pins @main, so the PR that lands the fix does not exercise it either. What they catch is the regression that matters: deleting the fallback, or softening the refusal back to a pass. Both are registered as WORKFLOW_MUTATIONS, per that list_s own note that rule 5 does not exempt a guard for living in YAML. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.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.
Comment-only fix in
.github/workflows/set-pr-status.yml. No workflow logic touched, no behaviour change.The drift
In reviewwas renamed toCode reviewin #20 (7dbaabf). Derived rather than assumed — I read the live Status field's options before editing:In reviewis not among them.Code reviewis.The file disagreed with itself
The code has been right the whole time —
:108writesstatus_name=Code review— and the same header already says "the SAME event that puts a card inCode review" thirty lines below the stale line. So the only wrong statement was the one a reader meets first, which is the half that matters: a header is what someone skims before trusting the job.Sweep
Checked the whole repo for the same phrasing. This was the only board-column reference. Two other matches are deliberately left alone, because they do not name a column:
repo-inventory.yml:635scripts/tests/standards-sync-selftest.py:428sync.SYNC_REVIEWER in reviewer_edit[0]— a Pythoninoperator, not the phraseChecks
One observation, not fixed here
The repo has a
Written Status names exist…check that validates the Status names the workflows write. It would not have caught this, because the stale name was in a comment. That is the gap that let a renamed column sit in the header for the whole life of the rename — worth knowing, but building a comment-scanning guard is a bigger change than this PR should carry, and I did not want to smuggle it in behind a docs fix.No ticket filed: the drift is one line and now gone, so a ticket would outlive the fix. Raising it here rather than opening a card for a closed issue.
Note
Low Risk
Documentation-only change in a workflow comment; no runtime or CI behavior is affected.
Overview
Updates a comment-only line in
set-pr-status.ymlso the header matches the kanban Status option the workflow already writes (Code review), replacing the stale label In review after the board column rename.No job logic, triggers, or
status_namevalues change—only the skim-first header comment is corrected so it agrees with the code and the rest of the file.Reviewed by Cursor Bugbot for commit c63dceb. Bugbot is set up for automated code reviews on this repo. Configure here.