Skip to content

PR history for both repos, with the diffs readable in place - #85

Merged
vijay-tylertech merged 1 commit into
mainfrom
feat/pr-history
Aug 29, 2026
Merged

vijay-tylertech merged 1 commit into
mainfrom
feat/pr-history

Conversation

@vijay-tylertech

Copy link
Copy Markdown
Contributor

Adds a collapsed History section under the open change requests on /prs, listing
merged requests from THIS flow in both the knowledge repo and Blueprint, each row
linking into the existing diff viewer rather than out to GitHub.

Provenance is the hard part, and the two repos have opposite problems: the
knowledge repo carries its own machinery work alongside review batches (81 of its
84 merged requests are machinery), and Blueprint is a shared docs repo with a lot
of unrelated traffic. So a request qualifies on EITHER of two markers:

  • the onetyler-review LABEL, applied at creation on both repos. Authoritative,
    and visible on GitHub itself rather than only through this tool.
  • the BRANCH PREFIX -- review/ and kb-review/. This covers the back-catalogue,
    since the label only exists from today. headRefName survives the branch being
    deleted at merge (verified on Professional register, compact: hints on screen, not documentation #84, whose branch 404s on the branches API while
    the PR record still reports its name), so it stays readable indefinitely.

Either alone was insufficient: label-only would have shipped an empty history,
prefix-only leaves nothing identifiable on GitHub.

Tagging is never fatal. Labelling Blueprint may exceed a contributor's rights, and
the prefix keeps the request in the history regardless -- so a failure is reported
and the request is not re-opened. The label is created lazily, when a request is
opened, so viewing a dashboard never writes to Blueprint.

Also, in the diff viewer:

  • ?full=1 lifts BOTH truncation caps, reached from the truncation notice itself.
    The caps stay on by default, but "open it on GitHub" was the only escape from
    them, which made them a dead end on exactly the large requests worth reading.
  • Refresh now carries repo and full. It did neither, so refreshing a Blueprint
    diff silently fetched the KNOWLEDGE request with the same number.
  • A merged request said "closed", which reads as abandoned. It now says merged,
    with the date and who merged it.

The three historical review batches (#18, #31, #47) were labelled by hand so the
label is authoritative from the start rather than only for future requests.

Verified: the filter picks exactly those 3 of 84 merged requests and no duplicates
when both markers match; both caps confirmed lifted by full=1 against forced
limits (12 lines/3 files on #18: 12 -> 323 lines, 3 -> 28 files); a bad Blueprint
number renders an error page rather than crashing; contrast green.

Claude-Session: https://claude.ai/code/session_01VVNYqGza2dFdeWFX7qXnwb

Adds a collapsed History section under the open change requests on /prs, listing
merged requests from THIS flow in both the knowledge repo and Blueprint, each row
linking into the existing diff viewer rather than out to GitHub.

Provenance is the hard part, and the two repos have opposite problems: the
knowledge repo carries its own machinery work alongside review batches (81 of its
84 merged requests are machinery), and Blueprint is a shared docs repo with a lot
of unrelated traffic. So a request qualifies on EITHER of two markers:

  * the `onetyler-review` LABEL, applied at creation on both repos. Authoritative,
    and visible on GitHub itself rather than only through this tool.
  * the BRANCH PREFIX -- `review/` and `kb-review/`. This covers the back-catalogue,
    since the label only exists from today. `headRefName` survives the branch being
    deleted at merge (verified on #84, whose branch 404s on the branches API while
    the PR record still reports its name), so it stays readable indefinitely.

Either alone was insufficient: label-only would have shipped an empty history,
prefix-only leaves nothing identifiable on GitHub.

Tagging is never fatal. Labelling Blueprint may exceed a contributor's rights, and
the prefix keeps the request in the history regardless -- so a failure is reported
and the request is not re-opened. The label is created lazily, when a request is
opened, so viewing a dashboard never writes to Blueprint.

Also, in the diff viewer:

  * `?full=1` lifts BOTH truncation caps, reached from the truncation notice itself.
    The caps stay on by default, but "open it on GitHub" was the only escape from
    them, which made them a dead end on exactly the large requests worth reading.
  * Refresh now carries `repo` and `full`. It did neither, so refreshing a Blueprint
    diff silently fetched the KNOWLEDGE request with the same number.
  * A merged request said "closed", which reads as abandoned. It now says merged,
    with the date and who merged it.

The three historical review batches (#18, #31, #47) were labelled by hand so the
label is authoritative from the start rather than only for future requests.

Verified: the filter picks exactly those 3 of 84 merged requests and no duplicates
when both markers match; both caps confirmed lifted by `full=1` against forced
limits (12 lines/3 files on #18: 12 -> 323 lines, 3 -> 28 files); a bad Blueprint
number renders an error page rather than crashing; contrast green.

Claude-Session: https://claude.ai/code/session_01VVNYqGza2dFdeWFX7qXnwb
@vijay-tylertech
vijay-tylertech requested a review from a team as a code owner August 29, 2026 16:32
@vijay-tylertech
vijay-tylertech merged commit e2aff10 into main Aug 29, 2026
1 check passed
@vijay-tylertech
vijay-tylertech deleted the feat/pr-history branch August 29, 2026 16:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant