feat(bearings): link ticket ids and PRs on every board list - #5722
Open
adithya321 wants to merge 2 commits into
Open
adithya321 wants to merge 2 commits into
adithya321 wants to merge 2 commits into
Conversation
Board rows and Captain's Call cards accept optional https pr_url and ticket_url fields plus a ticket label. The validator refuses anything that is not an https URL, and the template renders each supplied URL as a new-tab link without assuming any tracker or forge host.
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.
Intent
On the /bearings lavish fleet board, an annotation on an Underway row whose title leads with a tracker ticket id asked: "can we hyperlink the ticket id to the issue tracker? similarly for github PRs in these lists". Follow-up question asked: should firstmate make ticket ids link to the tracker and PRs link to GitHub in every board list; answer: yes.
Today the board template (.agents/skills/bearings/assets/board-template.html) links a PR only on merge cards and Recently Landed rows (pr_url), renders no PR link on Underway or Charted Next rows, and never links a ticket id anywhere.
make sure no data from the employer whose board prompted this (company, repos, people, ticket ids, PR URLs, tracker workspace) goes to the firstmate repo PR
What Changed
ticket, or "ticket" if no label is given) and a PR link (#<number>) on every Underway, Recently Landed, and Charted Next row, plus every Captain's Call item. Before this, PR links appeared only on merge cards and landed rows, and ticket ids were never linked. Links open in a new tab and render only forhttps://URLs taken from the payload. No tracker or forge host is hardcoded.bin/fm-bearings-board.shaccepts optionalpr_url,ticket_url, andticketfields on all four item types. It refuses a non-https or malformed URL and an emptyticketlabel. The payload contract comment documents the new fields.SKILL.mdtells the composer to fillpr_url,ticket_url, andticketonly when the task records already hold them, and never to guess or construct a URL. The render harness and the board/render tests cover the new links and the validation rules, using only placeholder data.🤖 Generated with Claude Code
Risk Assessment
✅ Low: The change adds optional ticket and PR link fields. The validator accepts only https URLs, and the template builds each link from the payload with no hardcoded host, adding a new-tab anchor that has rel=noopener. The fix round now puts ticket links before PR links on every card and row, and the test data holds only placeholder values (ABC-, tracker.example, forge.example), with no employer data.
Testing
First I ran the existing board render test. It passed, including the new check that every list links tickets and PRs. Then I ran the real
fm-bearings-board.sh buildin a throwaway lab home on a fictional payload and loaded the built board in Chromium. Every card and row placed the ticket link before the PR link, used the payload URL, opened it in a new tab with rel=noopener, and labelled PRs with their number (a trailing slash was handled). A ticket with no label showed as "ticket", and the row with no URLs showed no links. The build refused all five malformed-link payloads and left the existing board byte-identical. The employer-data check was a static scan of the diff and commits, not a live run, so it is recorded as untested; the scan found only placeholder hosts (tracker.example, forge.example) and ABC-* ids. lavish-axi was replaced with a stub so the operator's shared Lavish server was never touched. That stub only arms the session and does not change what the board renders. I captured screenshot evidence, and the lab was fully torn down.Evidence: Fictional lab payload used for the build
Source: Fictional lab payload used for the build
Evidence: Lab build transcript
Source: Lab build transcript
Evidence: Malformed link payloads refused, board unchanged
Source: Malformed link payloads refused, board unchanged
Evidence: Employer-data leak scan of the diff and commits
Source: Employer-data leak scan of the diff and commits
Evidence: Render test output
Source: Render test output
Evidence: Links rendered in the browser (DOM query summary)
Pipeline
Updates from git push no-mistakes
✅ **intent** - passed
✅ No issues found.
✅ **Rebase** - passed
✅ No issues found.
🔧 **Review** - 1 issue found → auto-fixed ✅
.agents/skills/bearings/assets/board-template.html:522- Captain's Call cards show the two links in different orders: merge cards put the PR link before the ticket link (board-template.html:522-525), while decision cards put the ticket first (board-template.html:532-533). Rows always put the ticket first (appendRowLinks, :450-454). The two card branches also repeat the same link-append code. Building one list in a single order, e.g. [ticketLink(...), link(... pr_url ...)], after the type branch would make the order consistent and remove the repetition. The test at tests/fm-bearings-board-render.test.sh (the calls[] href expectation) would need its merge-card order changed to match. This only affects display order.🔧 Fix applied.
✅ Re-checked - no issues remain.
✅ **Test** - passed
✅ No issues found.
bash tests/fm-bearings-board-render.test.sh(existing render test: builds throughfm-bearings-board.sh buildand renders under the DOM harness, including the ticket/PR link test with the ticket-then-PR order)Made a throwaway lab home withbin/fm-lab-home.sh create, then ran a realbin/fm-bearings-board.sh buildon a fictional payload: 2 Captain's Call cards (one merge, one decision), 2 Underway rows (one linked, one with no links), 1 Recently Landed row with a trailing-slash PR URL, and 1 Charted Next row with a ticket URL but no labelServed the built bearings-board.html on 127.0.0.1 and loaded it in Playwright Chromium; collected every <a> element (section, text, href, target, rel) with a DOM query and took a full-page screenshotAdversarial: ranbuildwith ticket_url=javascript:alert(1), an http:// ticket_url, an ftp:// pr_url, an emptyticketlabel and a numeric ticket_url; checked that each exits 1 and that the existing board's SHA is unchangedLeak scan: case-insensitive grep ofgit diff f54aa00 HEADand the commit messages for employer identifiers, plus a list of every URL and ticket-shaped id in the added linesTeardown: stopped the http server and the lab listener, then ranrm -rfon the lab and on .playwright-mcp✅ **Document** - passed
✅ No issues found.
✅ **Lint** - passed
✅ No issues found.
✅ **Push** - passed
✅ No issues found.