cgithub.git/src, branch main

Read the pull request list from embedded JSON

2026-09-25T06:15:25Z

GitHub's pull request list no longer renders .js-issue-row rows server-side; the rows come from the repoPullsDashboardContentRoute payload instead. Co-Authored-By: Claude Opus 5.5

Show each repo nav item only if the GitHub page includes it

2026-09-25T06:15:02Z

Co-Authored-By: Claude Opus 5.5

Show issue and pull request status and labels in their lists

2026-09-25T05:43:53Z

Co-Authored-By: Claude Opus 5

Add issue details

2026-09-25T05:43:53Z

Co-Authored-By: Claude Opus 5

Add discussions

2026-09-25T05:43:53Z

Discussions are served from GitHub's older server-rendered HTML, with no embeddedData JSON to read, so the scraper walks the DOM the way the pull request and wiki code does. A discussion's timeline opens with its own post and continues with its comments, each carrying its replies nested inside it, which is where the recursion in _discussionComment.eta comes from. Categories, upvotes, and the answer a Q&A discussion is marked with all come along. Only what GitHub renders up front is shown: neither the next page of discussions nor the replies it hides behind a "Show N previous replies" button are fetched, so a comment says how many replies it is missing. Co-Authored-By: Claude Opus 5

Render the error page in the shared page shell

2026-09-10T18:58:18Z

error.eta carried its own copy of the HTML shell, so error pages missed the viewport meta tag, the build-commit footer, and the link to the original GitHub page. The renderer already passes githubUrl and buildCommit to every template, so the layout needs nothing new from app.ts. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01JZAT3YzYP85DihSvQbDKB6

Redirect /notifications instead of scraping it as an owner

2026-09-10T05:01:04Z

A signed-out request for github.com/notifications is bounced to a login page, so the owner route followed that redirect and left the visitor on /login. Hand the path over to GitHub before it reaches the route.

Serve GitHub's global search when it names one repository

2026-09-09T18:39:57Z

/search?q=repo:owner/name+...&type=code matched the /:owner route and rendered a profile page for an owner named "search", which GitHub 404s. It is the URL GitHub's own search box produces, so it arrives whenever a search is redirected here. A /search route now takes it: when the query carries a repo: qualifier and a type, it strips the qualifier and redirects to that repository's search route, which already maps issues and pull requests to pages we render and hands the rest to GitHub. Searches that name no single repository -- bare queries, org:/user: scopes, a missing type -- keep redirecting to github.com/search as they did before. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01GkGX6puS45xD5KzdV9tHEA

Split the page shell out of the repository layout

2026-09-05T01:49:59Z

layout.eta was two things at once: the HTML shell every page needs and the repository chrome around it. owner.eta, being the one page that is not about a repository, could use neither and carried its own copy of the shell, which had drifted -- its footer named no build commit and did not link to the original page on GitHub. The shell moves to views/layouts/base.eta, taking its title and any deferred scripts as layout data, and the chrome to views/layouts/repo.eta, a layout over it that adds the clone commands, nav, search box, and the "/" shortcut that focuses it. Repository pages point at repo.eta and render as before; owner.eta uses base.eta directly and so gains the footer it was missing. Templates now live in more than one directory, so scripts/build.ts walks views/ recursively and keys each template by its path underneath it. Names crossing a directory are written from the views root ("/layouts/base.eta"), the one form both Eta's filesystem resolver and the precompiled resolver in worker.ts agree on; siblings stay relative. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01Ba5p88cWtCq42vf3uweweL

Handle route errors in middleware

2026-09-04T03:28:52Z

Every page route wrapped its scrape in tryRender, which awaited the promise, rendered the template on success, and turned a failure into a redirect or an error page. Hono's onError does that mapping for all of them at once, so handlers now await their scrape inline and both wrappers are gone. Fragments under /api/ still fail as an empty body rather than a page; onError checks for them first, since a fragment turns a redirect into a 404 instead of following it. RedirectError becomes an abstract base with InternalRedirectError and ExternalRedirectError under it, so the handler dispatches on the type instead of sniffing the location for an https:// prefix. One behavior change: a thrown value that is not an Error no longer renders error.eta, because Hono only routes Error instances to onError. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01QERwoRJhuqMhKzzCUW4Skv