Repository navigation
fix(delivery): a repository row is not a pull request - #6459
Open
vivekchand wants to merge 2 commits into
Open
vivekchand wants to merge 2 commits into
vivekchand wants to merge 2 commits into
Conversation
The Repositories view rendered `vivekchand/clawmetry #vivekchand/clawmetry` on every line, and the summary said "100 pull requests" over a table of repositories. query_delivery carries `kind` on the envelope, not on each row, so `!r.kind` was true for every row and every row was drawn in pull-request form, where the label is the repo followed by `#` and the ref. A repo row's ref IS its name. The label now follows the view's kind when the row carries none: a PR still reads `owner/name #number`, a repository reads its name, and a branch, commit or path reads its ref under its repository when that is a different string. The count chip names what the table lists. Found by looking at the rendered tab in a browser. Six rounds of fixes here were measured against the data, where this was invisible: the rows were right and only their rendering was wrong. 3 browser tests against the shipped template and app.js with synthetic fixtures; 2 are red against the released 0.12.927, and the third pins the pull-request label that a kind-aware change could quietly break. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
✅ Drift Bot (ClawMetry): no drift detectedDrift Bot analyzed the changed files against this project's blueprints and requirements and found no drift. |
|
![8090-software-factory[bot]](https://avatars.githubusercontent.com/in/1847834?s=60&v=4){kind=small}
| var label = (r.kind === 'pr' || !r.kind) | ||
| ? ((r.repo ? escHtml(r.repo) + ' ' : '') + '#' + escHtml(r.ref)) | ||
| : escHtml(r.ref); | ||
| // The row carries no kind of its own: query_delivery puts it on the |
There was a problem hiding this comment.
The blueprint specifies that each SessionArtifact model row should have a required 'kind' field (one of pr/repo/branch/commit/file), but the API implementation places 'kind' only on the response envelope, requiring rows to fall back to the view-level kind during rendering.
Contributor
Visual diffComparing No flagged differences (running with ALWAYS_POST=1).
Folder: f89a4b3fda85. Full PNGs also attached as a workflow artefact. Generated by visual-diff bot. Pixel diffs >1% flagged; eyeball the table before merging. This check is non-blocking — fail = bot bug, not a code problem. |
This branch has not been deployed
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 free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Why
Found by looking at the rendered tab in a browser, which is the one check six rounds of fixes to this tab had not done. The Repositories view showed:
and the summary above it read "100 pull requests" over a table of repositories.
One cause for both:
query_deliverycarrieskindon the envelope, not on each row, so the renderer's!r.kindtest was true for every row and every row was drawn in pull-request form, where the label is the repository followed by#and the reference. A repository row's reference is its name, so the name printed twice with a#wedged between.Every audit in this effort was run against the rows, and the rows were right. Only the rendering was wrong, which is why six rounds of data checks never saw it.
What
owner/name #numberVerified
3 browser tests against the shipped
templates/tabs/delivery.htmlandstatic/js/app.jswith synthetic fixtures, no live store and no user browser, following the existing_shared_chromiumpattern.test_a_repository_row_is_not_rendered_as_a_pull_request— red against released 0.12.927test_a_branch_row_shows_the_branch_and_no_hash— red against released 0.12.927test_a_pull_request_row_still_reads_repo_then_number— passes both ways on purpose: the half a kind-aware label could quietly breakAlso read in a real browser against the live node before and after: 100 rows rendered, 0 console errors, 0 page errors, and no
undefined,NaN,null,[object Object]or unescaped entity in any rendered cell.Limits
The renderer still has no per-row kind to trust, so a response mixing kinds in one list would label them all by the view. Nothing produces such a response today: the store is asked for one kind at a time.
Product record: https://factory.8090.ai/project/b415065f-ab2f-4f53-8864-0c009fd098cb/requirements/eedac1ad-764f-4f9c-bb00-f51c8d47618d
🤖 Generated with Claude Code