@joshuafolkken/kit 1.1229.0 → 1.1370.0

package/scripts/gh/git-gh-pr-rest.ts

@@ -1,18 +1,18 @@
 import { rest_comment_schema } from '#scripts/git/git-schemas'
 import {
 	parse_json_array_or_undefined,
-	parse_json_object_safe,
+	parse_json_object_or_undefined,
 } from '#scripts/git/parse-json-array'
 import { z } from 'zod'
 import { MERGED_STATE, to_gh_state } from './git-gh-rest-state'
 
 // The translation between one REST pull request (`repos/{owner}/{repo}/pulls/{N}`) and the JSON
-// shape `gh pr view --json <fields>` used to answer with.
+// shape `gh pr view --json <fields>` answers with.
 //
 // `gh pr view` goes through GraphQL, which a cloud session is answered 403 for while the REST
-// endpoint is served normally (joshuafolkken/kit#1022). The mapping lives here rather than beside
+// endpoint is served normally. The mapping lives here rather than beside
 // the requests because it is pure: given the response, it decides the answer with nothing else to
-// know — the same split `git-gh-issue-rest.ts` already makes (joshuafolkken/kit#1027).
+// know — the same split `git-gh-issue-rest.ts` already makes.
 
 // Only the fields the mapping itself reads are named; every other key passes through untouched.
 //
@@ -24,7 +24,7 @@ import { MERGED_STATE, to_gh_state } from './git-gh-rest-state'
 // `mergeable` and `mergeable_state` are served by the single-pull endpoint only — the listing omits
 // both — which is why the branch lookup resolves a number and the reads go back for the detail.
 // `repo.full_name` is what tells a fork's head from this repository's own — `head.ref` is a bare
-// branch name that says nothing about which repository holds it (joshuafolkken/kit#1029). Named once
+// branch name that says nothing about which repository holds it. Named once
 // because both sides of a pull request carry the same shape.
 const rest_repo_schema = z.looseObject({ full_name: z.string().optional() }).nullish()
 const rest_pull_side_schema = z.looseObject({ repo: rest_repo_schema })
@@ -42,14 +42,13 @@ const rest_pull_schema = z.looseObject({
 	mergeable_state: z.string().optional(),
 	// `sha` is the head commit, which is what both halves of the merge-gate rollup are keyed by —
 	// REST hangs the check runs and the status contexts off the commit rather than off the pull
-	// request (joshuafolkken/kit#1028).
+	// request.
 	head: z
 		.looseObject({ ref: z.string().optional(), sha: z.string().optional(), repo: rest_repo_schema })
 		.nullish(),
 	base: rest_pull_side_schema.nullish(),
 	// `node_id` is what the GraphQL auto-merge mutation addresses a pull request by, and `auto_merge`
-	// is `null` until auto-merge is enabled — both read by `git-gh-pr-auto-merge.ts`
-	// (joshuafolkken/kit#2497).
+	// is `null` until auto-merge is enabled — both read by `git-gh-pr-auto-merge.ts`.
 	node_id: z.string().optional(),
 	auto_merge: z.looseObject({}).nullish(),
 })
@@ -64,15 +63,14 @@ const OPEN_STATE = 'open'
 const EMPTY_BODY = ''
 
 function parse_rest_pull(rest_json: string): RestPull {
-	const parsed = parse_json_object_safe(rest_json, rest_pull_schema)
+	const parsed = parse_json_object_or_undefined(rest_json, rest_pull_schema)
 	if (parsed === undefined) throw new Error(NOT_A_PULL_MESSAGE)
 
 	return parsed
 }
 
 // A response that is not a listing must not degrade into an empty one: `pr_exists` reads an empty
-// listing as "this branch has no pull request", and `git-pr.ts` answers that by opening a second one
-// (joshuafolkken/kit#950 is the same misread on the issue side).
+// listing as "this branch has no pull request", and `git-pr.ts` answers that by opening another.
 function parse_rest_pulls(rest_json: string): Array<RestPull> {
 	const parsed = parse_json_array_or_undefined(rest_json, rest_pull_schema)
 	if (parsed === undefined) throw new Error(NOT_A_PULL_LISTING_MESSAGE)
@@ -80,7 +78,7 @@ function parse_rest_pulls(rest_json: string): Array<RestPull> {
 	return parsed
 }
 
-// Which pull request a branch name means. `gh pr view <branch>` preferred the open one and fell back
+// Which pull request a branch name means. `gh pr view <branch>` prefers the open one and falls back
 // to the most recent, and the difference is reachable in this repository's own flow: `git-pr.ts`
 // opens a *second* pull request on a branch whose first one merged, so a lookup that answered
 // "newest first, whatever its state" would still be right there while "the first row" alone would
@@ -93,7 +91,7 @@ function select_pull(pulls: ReadonlyArray<RestPull>): RestPull | undefined {
 // REST reports a merge as a field beside the state rather than as a state, and both spellings of it
 // are accepted: the single-pull endpoint carries `merged`, the listing carries only `merged_at`.
 //
-// Exported since joshuafolkken/kit#1077, because `pr_merge` asks the same question directly: a merge
+// Exported because `pr_merge` asks the same question directly: a merge
 // request that failed after the merge landed is settled by reading the pull request back, and the
 // merge-or-not verdict must be the one `to_pr_state` already uses rather than a second spelling of it.
 function is_merged(pull: RestPull): boolean {
@@ -112,7 +110,7 @@ function to_pr_state(pull: RestPull): string | undefined {
 // `gh pr checkout` reached a fork's head through `refs/pull/<N>/head`, which a plain
 // `git fetch origin <branch>` cannot: the fetch either fails outright, or — where `origin` happens to
 // carry a branch of the same name — succeeds on an unrelated branch. Both halves are read out of the
-// one response, so the test costs no second request (joshuafolkken/kit#1029).
+// one response, so the test costs no second request.
 function to_repo_name(side: RestPullSide | null | undefined): string | undefined {
 	return side?.repo?.full_name
 }
@@ -125,19 +123,18 @@ function is_same_repository_head(pull: RestPull): boolean {
 
 // The three fields `gh pr view --json mergeable,mergeStateStatus,state` answered with.
 //
-// `mergeable` was a GraphQL enum (`MERGEABLE` / `CONFLICTING` / `UNKNOWN`) and is a nullable boolean
-// in REST; `pr_info_schema` accepts both, so the boolean passes through as it arrives — including
-// the JSON null GitHub sends while it is still computing.
+// `mergeable` is a GraphQL enum (`MERGEABLE` / `CONFLICTING` / `UNKNOWN`) and a nullable boolean in
+// REST; `pr_info_schema` accepts both, so the boolean passes through as it arrives — including the
+// JSON null GitHub sends while it is still computing.
 //
-// **Nothing reads `mergeable` any more** (joshuafolkken/kit#1232 removed `git-conflict.ts`, its only
-// reader, and the conflict verdict comes off `mergeStateStatus` in `git-pr-checks-eval.ts` now). It
-// stays because this function's contract is *the shape `gh pr view --json …` answered with*, not
-// the subset today's callers happen to read — trimming a wire shape to its current readers is what
-// makes the next one look for a field the mapping silently dropped.
+// **Nothing reads `mergeable`** — the conflict verdict comes off `mergeStateStatus` in
+// `git-pr-checks-eval.ts`. It stays because this function's contract is *the shape
+// `gh pr view --json …` answers with*, not the subset today's callers happen to read — trimming a
+// wire shape to its current readers is what makes the next one look for a field the mapping
+// silently dropped.
 //
-// `mergeStateStatus` is upper-cased because that is how `gh` spelled it, and because the merge-gate
-// snapshot in `git-pr-checks-eval.ts` compares strictly against that spelling
-// (joshuafolkken/kit#1028 converts the snapshot itself).
+// `mergeStateStatus` is upper-cased because that is how `gh` spells it, and because the merge-gate
+// snapshot in `git-pr-checks-eval.ts` compares strictly against that spelling.
 function to_pr_info(pull: RestPull): Record<string, unknown> {
 	return {
 		mergeable: pull.mergeable,
@@ -148,7 +145,7 @@ function to_pr_info(pull: RestPull): Record<string, unknown> {
 
 // The conversation comments in the shape `gh pr view --json comments` answered with. A listing that
 // will not parse throws rather than answering an empty one — `git-pr-ai-review.ts` reads an empty
-// listing as "no reviewer left a finding" and merges (joshuafolkken/kit#973).
+// listing as "no reviewer left a finding" and merges.
 function to_pr_comments(rest_json: string): Array<Record<string, unknown>> {
 	const parsed = parse_json_array_or_undefined(rest_json, rest_comment_schema)
 	if (parsed === undefined) throw new Error(NOT_A_COMMENT_LISTING_MESSAGE)

package/scripts/gh/git-gh-pr-review.ts

@@ -5,7 +5,7 @@ import { z } from 'zod'
 //
 // **REST has no field for it.** `repos/{owner}/{repo}/pulls/{N}/reviews` answers every review ever
 // submitted, so the one value `gh pr view --json reviewDecision` gave has to be folded out of that
-// listing (joshuafolkken/kit#1028).
+// listing.
 //
 // The only consumer is `is_review_blocked` in `git-pr-checks-eval.ts`, which asks one question: is
 // `CHANGES_REQUESTED` standing? `APPROVED` and the empty string are therefore interchangeable to the
@@ -41,7 +41,7 @@ type RestReview = z.infer<typeof rest_review_schema>
 const NOT_A_REVIEW_LISTING = 'gh api answered something other than a review listing'
 
 // A listing that will not parse throws rather than answering "nobody requested changes" — the
-// merge-gate direction of joshuafolkken/kit#973 again.
+// an unread answer must never let the merge gate pass.
 function parse_rest_reviews(reviews_json: string): Array<RestReview> {
 	const parsed = parse_json_array_or_undefined(reviews_json, rest_review_schema)
 	if (parsed === undefined) throw new Error(NOT_A_REVIEW_LISTING)

package/scripts/gh/git-gh-pr-rollup.ts

@@ -7,7 +7,7 @@ import { z } from 'zod'
 // `gh` answered a single `statusCheckRollup` whose elements were of two kinds; REST splits them
 // across `commits/{sha}/check-runs` (`status` / `conclusion` / `name`) and `commits/{sha}/status`
 // (`state` / `context`). The merge is pure — given the two responses it decides the answer with
-// nothing else to know — so it lives here rather than beside the requests (joshuafolkken/kit#1028).
+// nothing else to know — so it lives here rather than beside the requests.
 
 // `__typename` is what `git-pr-checks-parse.ts` distinguishes the two kinds by, and only the status
 // contexts carry it: the parser's default branch is the check run, so a check run needs no marker
@@ -45,7 +45,7 @@ const NOT_A_STATUS_LISTING = 'gh api answered something other than a commit stat
 // A response that will not parse throws rather than degrading to an empty rollup. The direction is
 // what makes it worth the throw: an empty rollup reads as "this pull request has no checks", and
 // `git-pr-followup.ts` treats that as a reason to stop watching rather than as a failure — so a rate
-// limit would arrive as a pull request nothing was ever required to pass (joshuafolkken/kit#973).
+// limit would arrive as a pull request nothing was ever required to pass.
 function read_pages<T>(raw_json: string, schema: z.ZodType<T>, message: string): Array<T> {
 	const pages = parse_json_array_or_undefined(raw_json, schema)
 	if (pages === undefined) throw new Error(message)
@@ -85,9 +85,9 @@ function read_rank(run: RollupElement): RunRank | undefined {
 // *within* a suite (a re-run job lands in the suite it re-runs), so what is left is one run per
 // suite. Across suites GitHub takes the one from the newer suite: PR #2717's cancelled suite was the
 // older one and GitHub read the pull request `CLEAN`, while PR #2698's cancelled suite was the newer
-// one and GitHub held it `BLOCKED`. Ranking by run id alone (joshuafolkken/kit#2644) picked #2698's
+// one and GitHub held it `BLOCKED`. Ranking by run id alone picked #2698's
 // older, successful suite — its jobs had queued later — so `followup` read green beside a `BLOCKED`
-// pull request and waited out its whole budget (joshuafolkken/kit#2700).
+// pull request and waited out its whole budget.
 function is_ranked_above(candidate: RunRank, current: RunRank): boolean {
 	if (candidate.suite !== current.suite) return candidate.suite > current.suite
 

package/scripts/gh/git-gh-pr-snapshot.ts

@@ -9,11 +9,10 @@ import { to_gh_state } from './git-gh-rest-state'
 // The merge gate's pull request state snapshot, rebuilt from REST.
 //
 // `gh pr view --json mergeStateStatus,reviewDecision,statusCheckRollup` is answered 403 in a cloud
-// session (joshuafolkken/kit#1022), and all three fields are GraphQL-only: one has no REST
+// session, and all three fields are GraphQL-only: one has no REST
 // counterpart at all, one is spelled differently, and one is two endpoints that `gh` merged.
 // `pnpm josh followup` decides a pull request is green from this value, so a mistake here
-// ships as a merge no gate ever cleared rather than as a command that stops working
-// (joshuafolkken/kit#1028).
+// ships as a merge no gate ever cleared rather than as a command that stops working.
 //
 // The answer stays the JSON string `parse_pr_state_snapshot` already parses. Nothing downstream —
 // `git-pr-checks-parse.ts`, `git-pr-checks-eval.ts`, `git-pr-followup.ts` — changes.
@@ -59,18 +58,17 @@ async function read_status_check_rollup(commit_sha: string): Promise<Array<objec
 }
 
 // The review history, folded into GraphQL's `reviewDecision`. One request, and the only one of the
-// four the merge gate does not need on every poll — see `is_review_decision_decisive`
-// (joshuafolkken/kit#1043).
+// four the merge gate does not need on every poll — see `is_review_decision_decisive`.
 async function pr_get_review_decision(pr_number: number): Promise<string> {
 	const path = git_gh_api_path.pull_reviews_api_path(String(pr_number))
 
 	return git_gh_pr_review.to_review_decision(await read_array_pages(path))
 }
 
-// `mergeStateStatus` is upper-cased because that is the spelling `gh` used and the spelling
+// `mergeStateStatus` is upper-cased because that is the spelling `gh` uses and the spelling
 // `git-pr-checks-eval.ts` compares strictly against: `MERGE_STATE_CLEAN` never matches a lower-case
-// `clean`, which would also take every pull request out of the kit#753 escape hatch keyed on
-// `UNSTABLE`. The rule is shared with `to_pr_info` rather than written twice.
+// `clean`, which would also take every pull request out of the CodeRabbit non-blocking exemption
+// keyed on `UNSTABLE`. The rule is shared with `to_pr_info` rather than written twice.
 async function build_checks_fields(pull: RestPull): Promise<Record<string, unknown>> {
 	return {
 		statusCheckRollup: await read_status_check_rollup(read_head_sha(pull)),
@@ -93,7 +91,7 @@ async function resolve_pull(branch_name: string): Promise<ResolvedPull> {
 
 // Everything the snapshot carries except the review decision: three requests rather than four.
 // `pr_number` travels with it so a caller that then *does* want the review decision needs no second
-// resolution (joshuafolkken/kit#1043).
+// resolution.
 interface PrChecksSnapshot {
 	pr_number: number
 	snapshot_json: string
@@ -112,7 +110,7 @@ async function pr_get_checks_snapshot(branch_name: string): Promise<PrChecksSnap
 // **This is the definition the two halves above must compose to.** The merge gate reads them
 // separately so it can skip the review listing on a poll that cannot conclude anything, but the
 // three-field value `gh pr view --json …` answered with is still one thing, and it is asserted here
-// rather than reassembled inside a test (joshuafolkken/kit#1043).
+// rather than reassembled inside a test.
 async function pr_get_state_snapshot(branch_name: string): Promise<string> {
 	const { pr_number, pull } = await resolve_pull(branch_name)
 	const [fields, review_decision] = await Promise.all([

package/scripts/gh/git-gh-pr.ts

@@ -13,16 +13,16 @@ import { git_gh_pr_snapshot } from './git-gh-pr-snapshot'
 // The pull-request writes, through REST.
 //
 // `gh pr create` / `comment` / `merge` / `checkout` all go through GraphQL, which a cloud session is
-// answered 403 for while the REST endpoints are served normally (joshuafolkken/kit#1022). The reads
-// converted first — the ones `gh pr view` served in `git-gh-pr-read.ts` (joshuafolkken/kit#1027) and
-// the merge gate's snapshot in `git-gh-pr-snapshot.ts` (joshuafolkken/kit#1028) — and these are the
+// answered 403 for while the REST endpoints are served normally. The reads
+// converted first — the ones `gh pr view` served in `git-gh-pr-read.ts` and
+// the merge gate's snapshot in `git-gh-pr-snapshot.ts` — and these are the
 // last four calls, plus the one whose API use the epic left unconfirmed.
 //
 // **Every path here was measured against the live API before it was written**, on a throwaway pull
 // request opened between two throwaway branches so that neither `main` nor any real pull request was
 // touched. Two of the four did not behave as reading the documentation would suggest: see
 // `pr_create` for the duplicate-head response. The other, `pr_checkout`, is gone with its one caller,
-// `sync-dependabot-pins` (joshuafolkken/kit#2887).
+// `sync-dependabot-pins`.
 //
 // `pr_checks` — a `gh pr checks <branch>` wrapper — is gone rather than converted. Nothing called it:
 // the merge gate reads the rollup out of the snapshot and `git-pr-checks-watch.ts` runs the watching
@@ -41,7 +41,7 @@ const MERGE_COMMIT_METHOD = 'merge'
 // least idempotent request the layer makes, so the failure the shared 60-second budget produces is
 // the expensive one: a merge that landed while the request was already being abandoned. Three
 // minutes lowers how often that happens without leaving the request unbounded — the recovery below
-// is what actually removes the failure mode, and this only makes it rarer (joshuafolkken/kit#1077).
+// is what actually removes the failure mode, and this only makes it rarer.
 const MERGE_REQUEST_TIMEOUT_MS = 180_000
 // What a failed merge whose outcome could not be read back is reported as. Deliberately neither
 // "merged" nor "not merged": nobody read it.
@@ -102,7 +102,7 @@ async function pr_ensure_classification(
 // `{"message":"Validation Failed","errors":[{"resource":"PullRequest","code":"custom","message":"A
 // pull request already exists for <owner>:<branch>."}]}` — which `gh` writes to **stdout**, putting
 // only `gh: Validation Failed (HTTP 422)` on stderr. The body reaches the thrown Error because
-// `to_gh_error` appends stdout (joshuafolkken/kit#1029); the `already exists` match itself is
+// `to_gh_error` appends stdout; the `already exists` match itself is
 // unchanged, because both wordings contain it and the 422 carries no machine-readable code for the
 // case (`"code":"custom"`).
 async function post_pull_request(title: string, body: string): Promise<string> {
@@ -152,8 +152,8 @@ async function pr_comment(branch_name: string, body: string): Promise<string> {
 
 // Replaces the body of the branch's open pull request. `git -y` opens a pull request once, so a
 // body supplied on a later run — the live-execution evidence `followup` gates the merge on
-// (joshuafolkken/kit#2446) — reaches an already-open one only through this write. The remembered
-// detail read holds the old body, so it is cleared first (joshuafolkken/kit#3263).
+// — reaches an already-open one only through this write. The remembered
+// detail read holds the old body, so it is cleared first.
 async function pr_update_body(branch_name: string, body: string): Promise<void> {
 	const pr_number = await require_pr_number(branch_name)
 
@@ -165,7 +165,7 @@ async function pr_update_body(branch_name: string, body: string): Promise<void>
 	})
 }
 
-// A merge moves the remembered detail read's state, so it is cleared first (joshuafolkken/kit#3263).
+// A merge moves the remembered detail read's state, so it is cleared first.
 async function put_merge(pr_number: number): Promise<void> {
 	forget_pr_numbers()
 	await git_gh_exec.exec_gh_api({
@@ -177,7 +177,7 @@ async function put_merge(pr_number: number): Promise<void> {
 }
 
 // `undefined` is "nobody read it", kept apart from the `false` that means "the pull request is not
-// merged". Folding the two is the misread joshuafolkken/kit#925 / #950 / #973 / #1048 all refuse.
+// merged". Folding the two would report an unread state as a settled answer.
 async function read_merge_state(pr_number: number): Promise<boolean | undefined> {
 	try {
 		return git_gh_pr_rest.is_merged(await read_pull(pr_number))
@@ -222,13 +222,13 @@ async function has_merge_landed(pr_number: number, merge_error: unknown): Promis
 	throw new Error(MERGE_UNCONFIRMED_MESSAGE, { cause: merge_error })
 }
 
-// **The least idempotent write in this layer, made re-entrant** (joshuafolkken/kit#1077).
+// **The least idempotent write in this layer, made re-entrant**.
 //
-// The request carries a budget like everything else since joshuafolkken/kit#1065, and a merge that
-// lands server-side but overruns it used to throw: `followup` then skipped its completion
-// notification and the epic auto-close, and a re-run answered 405 on a pull request that was already
-// merged. The budget did not create that — before it the same request hung forever, with no
-// notification either and no end to the run — it only turned a silent hang into a loud failure.
+// The request carries a budget like everything else, and a merge that lands server-side but overruns
+// it throws: on its own that would make `followup` skip its completion notification and the epic
+// auto-close, and a re-run answer 405 on a pull request that is already merged. The budget does not
+// create that — without it the same request hangs forever, with no notification either and no end to
+// the run — it only turns a silent hang into a loud failure.
 //
 // **A failed merge request is not proof the merge did not happen**, so the pull request's own state
 // settles it: merged, and this returns as if the request had succeeded, which is what lets

package/scripts/gh/git-gh-reachability.ts

@@ -1,20 +1,19 @@
 // Whether GitHub answered at all — the question a failed read has to ask before it calls itself a
-// structural failure (joshuafolkken/kit#1663).
+// structural failure.
 //
-// **The question is now asked of the failed request itself, not of a later one**
-// (joshuafolkken/kit#1690). `probe()` used to fire one request at `rate_limit` after the reads were
-// over and the answer otherwise final; a connection that dropped for a few hundred milliseconds
-// failed a read at t=0 and answered that probe `reachable`, so the run kept the verdict the probe
-// gave it rather than the one the read had. What remains here is the classification — status to
-// retryable-or-not — which `git-gh-issue-read.ts` applies to the status the failed request carried
-// on its own error document.
+// **The question is asked of the failed request itself, not of a later one.** A probe fired at
+// `rate_limit` after the reads are over would misread a connection that dropped for a few hundred
+// milliseconds: it fails a read at t=0 and answers the probe `reachable`, so the run would keep the
+// verdict the probe gave it rather than the one the read had. What lives here is the
+// classification — status to retryable-or-not — which `git-gh-issue-read.ts` applies to the status
+// the failed request carried on its own error document.
 //
 // A dropped connection, a name that would not resolve, a rate limit and a 5xx are **retryable**: the
 // same request a moment later can succeed, and nothing about the repository has to change first. A
 // 404 or a 401 is not — the issue is absent or the credentials are wrong, and asking again answers
-// the same. Callers that cannot tell the two apart have to choose one meaning for both, and
-// joshuafolkken/kit#1663 measured what that costs: an unattended run reported thirteen runnable
-// issues as an unresolvable dependency graph because DNS hiccuped once.
+// the same. Callers that cannot tell the two apart have to choose one meaning for both, and the
+// cost is concrete: an unattended run can report thirteen runnable issues as an unresolvable
+// dependency graph because DNS hiccuped once.
 //
 // **It classifies by status code and not by gh's wording**, which is the same argument
 // `issue_view_json_classified` records for separating 404 from the rest: a message is prose that can
@@ -25,7 +24,7 @@
 // **403 is deliberately not retryable.** GitHub does spell some secondary rate limits that way, but
 // it is equally how a SAML-SSO-unauthorized token, an IP allowlist and an org policy each answer —
 // all permanent, and all diagnosed correctly by the `gh auth status` advice the unusable-graph
-// report already carries. Reading one of those as a connection problem would be this Issue's own
+// report already carries. Reading one of those as a connection problem would be the same
 // misdirection pointed the other way, so the ambiguous status is left with the permanent meaning and
 // only the unambiguous ones — 429, 5xx, and no answer at all — are treated as worth asking again.
 const RATE_LIMITED_STATUS = 429

package/scripts/gh/git-gh-repo.ts

@@ -6,13 +6,12 @@ import { git_gh_helpers } from './git-gh-helpers'
 //
 // Read through REST rather than `gh repo view --json nameWithOwner`: the `gh <noun> <verb>` form
 // goes through GraphQL, which a cloud session is refused outright (403), so this read answered
-// `undefined` there and every caller needing the name inherited that answer
-// (joshuafolkken/kit#1023).
+// `undefined` there and every caller needing the name inherited that answer.
 //
 // The pull-request reads no longer go through it at all: they address `repos/{owner}/{repo}` and
 // name the head filter's owner as `{owner}` too, which `gh api` expands inside a query string as
 // readily as inside a path. That keeps six branch-keyed reads from gaining a second way to fail, and
-// it is what makes `pr_get_review_comments` REST end to end (joshuafolkken/kit#1027). The remaining
+// it is what makes `pr_get_review_comments` REST end to end. The remaining
 // caller is the completion notification, which puts the name in its Telegram body.
 //
 // The failure contract is unchanged: `undefined` when the read fails, for a caller that has nothing

package/scripts/gh/git-gh-rest-state.ts

@@ -4,7 +4,7 @@
 // answered `OPEN` / `CLOSED` / `MERGED` and every reader downstream compares against that spelling.
 // Two endpoints have to recompose the third value from different fields — the issue endpoint from
 // `pull_request.merged_at`, the pulls endpoint from `merged` — so the rule they share is named here
-// rather than in either of them (joshuafolkken/kit#1027).
+// rather than in either of them.
 const MERGED_STATE = 'MERGED'
 
 function to_gh_state(state: string | undefined): string | undefined {

package/scripts/gh/git-pr-ai-review.ts

@@ -16,7 +16,7 @@ interface AiReviewPullComment {
 }
 
 // `undefined` when the answer was not a listing at all. `parse_json_array_safe` returned `[]` for
-// that, which this gate reads as "no reviewer left a finding" (joshuafolkken/kit#973).
+// that, which this gate reads as "no reviewer left a finding".
 function parse_ai_review_comments(
 	raw_json: string | undefined,
 ): Array<AiReviewPullComment> | undefined {
@@ -39,8 +39,9 @@ function format_ai_review_finding(finding: ClassifiedFinding): string {
 	return `- ${finding.author_login}: ${finding.summary}${suffix}`
 }
 
-// Temporary (kit#753): CodeRabbit findings are surfaced as console info and audit notes for the
-// completion notification instead of blocking the merge. Revert together with kit#752.
+// Temporary: CodeRabbit findings are surfaced as console info and audit notes for the
+// completion notification instead of blocking the merge. Revert together with the rest of the
+// temporary CodeRabbit non-blocking policy.
 function log_info_findings(infos: ReadonlyArray<ClassifiedFinding>): Array<string> {
 	if (infos.length === 0) return []
 
@@ -111,8 +112,8 @@ async function handle_blockers(input: {
 
 // A gate that could not be read is not a gate that passed. An unreadable listing is handled exactly
 // like an unresolved finding — the same `confirmation` Telegram, the same non-zero exit — because
-// what it means is the same: nobody has confirmed the reviewers had nothing to say
-// (joshuafolkken/kit#973). An ignore reason still gets past it, for the same reason it gets past a
+// what it means is the same: nobody has confirmed the reviewers had nothing to say.
+// An ignore reason still gets past it, for the same reason it gets past a
 // real finding: the person has looked.
 const UNREADABLE_COMMENTS_BODY =
 	'The AI reviewer comments could not be read, so no finding could be ruled out.\n' +

package/scripts/gh/git-pr-checks-eval.ts

@@ -7,14 +7,14 @@ import {
 } from './git-pr-checks-parse'
 
 // cspell:words coderabbit
-// Temporary (kit#753): CodeRabbit is excluded from the default required checks so slow or
+// Temporary: CodeRabbit is excluded from the default required checks so slow or
 // rate-limited CodeRabbit reviews never block the merge gate. Re-add it via JOSH_REQUIRED_CHECKS
-// to restore the old behavior. Revert once the fresh-context review subagent (kit#752) replaces it.
+// to restore the old behavior. Revert once the fresh-context review subagent replaces it.
 const DEFAULT_REQUIRED_CHECKS = ['SonarQube']
 // The single source of the check name every CodeRabbit exemption is keyed on — the merge gate's
 // `is_unstable_only_from_coderabbit`, the look-ahead's `is_awaited_check`, and the fixtures the two
 // are tested from. A second literal spelling of it anywhere is how one of them silently stops
-// matching after CodeRabbit renames its context (joshuafolkken/kit#1217).
+// matching after CodeRabbit renames its context.
 const CODERABBIT_CHECK_NAME = 'CodeRabbit'
 const REQUIRED_CHECKS_ENV_VAR = 'JOSH_REQUIRED_CHECKS'
 
@@ -73,19 +73,17 @@ function is_review_blocked(review_decision: string | undefined): boolean {
 	return review_decision === REVIEW_CHANGES_REQUESTED
 }
 
-// **A conflicting pull request ends the wait instead of polling through it**
-// (joshuafolkken/kit#1232). `DIRTY` is not CLEAN, so it used to answer `pending` and run the whole
-// 32-minute budget out on a state that resolves only when a person rebases — ending in a timeout
-// that named no cause. This is also where the conflict diagnosis `pnpm josh git` used to carry
-// landed: that command read `mergeStateStatus` after its own two-minute watch, and now returns as
-// soon as the pull request is open, so the first poll here is what reports a conflict — about ten
-// seconds against that two minutes.
+// **A conflicting pull request ends the wait instead of polling through it**.
+// `DIRTY` is not CLEAN, so it would otherwise answer `pending` and run the whole 32-minute budget
+// out on a state that resolves only when a person rebases — ending in a timeout that names no cause.
+// `pnpm josh git` returns as soon as the pull request is open, so the first poll here is what
+// reports a conflict.
 //
 // **`BLOCKED` is deliberately not here.** GitHub reports it while a required check is merely queued,
-// which is every healthy pull request for its first seconds. The old reader treated it as a conflict
-// safely only because it ran after the checks had settled; there is no equivalent moment on this
-// path, and a green-but-`BLOCKED` pull request (branch protection requiring a review, which this
-// repository does not set) therefore reaches the timeout rather than a named failure.
+// which is every healthy pull request for its first seconds. Treating it as a conflict is safe only
+// after the checks have settled; there is no such moment on this path, and a green-but-`BLOCKED`
+// pull request (branch protection requiring a review, which this repository does not set)
+// therefore reaches the timeout rather than a named failure.
 function is_merge_conflict(merge_state_status: string | undefined): boolean {
 	return merge_state_status === MERGE_STATE_DIRTY
 }
@@ -121,8 +119,8 @@ function is_coderabbit_check(check_name: string): boolean {
 	return is_required_match(check_name, CODERABBIT_CHECK_NAME)
 }
 
-// Temporary (kit#753): a pending or failing CodeRabbit check makes GitHub report UNSTABLE even
-// though CodeRabbit is no longer required. Accept that state only when CodeRabbit checks are the
+// Temporary: a pending or failing CodeRabbit check makes GitHub report UNSTABLE even
+// though CodeRabbit is not required. Accept that state only when CodeRabbit checks are the
 // sole non-passing ones — any other non-passing check keeps the gate strict.
 function is_unstable_only_from_coderabbit(snapshot: PrStateSnapshot): boolean {
 	if (snapshot.merge_state_status !== MERGE_STATE_UNSTABLE) return false
@@ -136,16 +134,16 @@ function is_required_check(check_name: string): boolean {
 	return REQUIRED_CHECKS.some((required) => is_required_match(check_name, required))
 }
 
-// A failing job outside the required list used to decide nothing: GitHub reports the pull request as
-// UNSTABLE rather than failed, so `evaluate_pr_state` answered `pending` and the wait ran out its
-// whole 32-minute budget before ending in a timeout that never named the cause
-// (joshuafolkken/kit#990). Any failed check therefore ends the wait now — except CodeRabbit's, which
-// kit#753 keeps non-blocking end to end, unless a project has put it back on the required list via
+// A failing job outside the required list does not fail the pull request on GitHub: it reports
+// UNSTABLE, so `evaluate_pr_state` alone would answer `pending` and the wait would run out its whole
+// 32-minute budget before ending in a timeout that never names the cause. Any failed check
+// therefore ends the wait — except CodeRabbit's, which the temporary CodeRabbit non-blocking policy
+// keeps non-blocking end to end, unless a project has put it back on the required list via
 // `JOSH_REQUIRED_CHECKS`. This only makes the gate report sooner: nothing here can produce
 // `success`, so no failing check gains a path to a merge. What counts as failed is whatever the
 // parser records as `fail` — `cancelled` and `timed_out` among them — which is the rule the required
-// list has always followed; the cost is that a job cancelled and re-run by hand is no longer picked
-// up by a wait already in progress, and `followup` has to be run again.
+// list follows; the cost is that a job cancelled and re-run by hand is not picked up by a wait
+// already in progress, and `followup` has to be run again.
 function is_blocking_failure(check: RollupCheck): boolean {
 	if (check.status !== CHECK_STATUS_FAIL) return false
 
@@ -163,7 +161,7 @@ function is_mergeable_state(snapshot: PrStateSnapshot): boolean {
 }
 
 // The wait's own error text: naming the checks that failed is what turns a red `followup` into
-// something actionable without opening the pull request (joshuafolkken/kit#990).
+// something actionable without opening the pull request.
 function collect_failure_reasons(snapshot: PrStateSnapshot): Array<string> {
 	const reasons: Array<string> = []
 	if (is_merge_conflict(snapshot.merge_state_status)) reasons.push(FAILURE_REASON_CONFLICT)
@@ -204,7 +202,7 @@ function evaluate_pr_state(snapshot: PrStateSnapshot): PrEvaluation {
 // `failure` without one is a poll that ends the wait, and both need it — `success` because a standing
 // change request must demote it, `failure` because `describe_pr_failure` names the reasons and
 // dropping "review requested changes" from a message that also lists failed checks loses half the
-// diagnosis (joshuafolkken/kit#1043).
+// diagnosis.
 //
 // **This is a freshness rule, not a cache.** Nothing is remembered between polls, which is the one
 // shape that would be wrong here — a stale non-blocking decision is exactly the direction that ships
@@ -212,7 +210,7 @@ function evaluate_pr_state(snapshot: PrStateSnapshot): PrEvaluation {
 // read in that same poll.
 //
 // **What it costs, stated rather than glossed.** A change request standing on a pull request whose
-// checks never settle used to end the wait on the first poll with `review requested changes`; it now
+// checks never settle does not end the wait on the first poll with `review requested changes`; it
 // runs the budget out and ends with the wait's own timeout, which names no cause. That run was red
 // either way — the trade only ever moves a red result later, never a green one earlier — but the
 // diagnosis is genuinely worse in that one case.
@@ -220,9 +218,9 @@ function is_review_decision_decisive(snapshot: PrStateSnapshot): boolean {
 	return evaluate_pr_state(snapshot) !== 'pending'
 }
 
-// **Whether GitHub's auto-merge can never fire on this pull request** (joshuafolkken/kit#2497). This is
-// narrower than the merge gate's `failure`: the gate also fails a red check outside the required list
-// (joshuafolkken/kit#990), but auto-merge waits only on the required ones, so such a pull request still
+// **Whether GitHub's auto-merge can never fire on this pull request**. This is
+// narrower than the merge gate's `failure`: the gate also fails a red check outside the required list,
+// but auto-merge waits only on the required ones, so such a pull request still
 // lands — reading it as blocked would call a landing flush stuck.
 function is_auto_merge_blocked(snapshot: PrStateSnapshot): boolean {
 	const failed_required = snapshot.rollup.filter(
@@ -238,7 +236,7 @@ function is_auto_merge_blocked(snapshot: PrStateSnapshot): boolean {
 	)
 }
 
-// A failed wait whose cause is a merge conflict (joshuafolkken/kit#3221), so `followup` names its last
+// A failed wait whose cause is a merge conflict, so `followup` names its last
 // lap `conflict` rather than `interrupted` and the cause is read from the stage block, not looked up.
 class PrConflictError extends Error {
 	override name = 'PrConflictError'

package/scripts/gh/git-pr-checks-parse.ts

@@ -7,20 +7,19 @@ const CHECK_STATUS_FAIL = 'fail'
 const CHECK_STATUS_MISSING = 'missing'
 
 // GitHub reports a job whose `if:` condition was false as COMPLETED with conclusion `skipped`, and
-// counts it as satisfied for branch protection — PR #792 reached CLEAN while three such jobs sat in
-// its rollup. Recording them as `fail` therefore disagreed with GitHub itself, and it disabled the
-// kit#753 escape hatch: `is_unstable_only_from_coderabbit` opens the gate only when every
-// non-passing check is CodeRabbit's, so kit's own conditional jobs (`auto-merge`, `E2E`,
-// `Notify Auto Tag`) kept a slow review blocking the merge until the wait loop timed out. The bug
-// was invisible on fast reviews, where CLEAN short-circuits the predicate — it could only surface on
-// the exact path kit#753 exists to protect.
+// counts it as satisfied for branch protection — a pull request reaches CLEAN with such jobs in its
+// rollup. Recording them as `fail` would disagree with GitHub itself, and it would disable the
+// CodeRabbit non-blocking exemption: `is_unstable_only_from_coderabbit` opens the gate only when
+// every non-passing check is CodeRabbit's, so kit's own conditional jobs (`auto-merge`, `E2E`,
+// `Notify Auto Tag`) would keep a slow review blocking the merge until the wait loop timed out. That
+// is invisible on fast reviews, where CLEAN short-circuits the predicate — it surfaces only on the
+// exact path the exemption exists to protect.
 //
-// `neutral` is here for the same reason `skipped` is, and joshuafolkken/kit#990 is what made leaving
-// it out untenable. GitHub's own rollup counts a neutral conclusion as satisfied, so such a pull
-// request reports CLEAN and merges in the UI — reading it as `fail` disagreed with GitHub exactly as
-// `skipped` did. Until kit#990 that disagreement was survivable, because a non-required failure only
-// left the state pending; now it ends the wait outright, so a bot that emits `neutral` to say it has
-// nothing to report would kill a `followup` on a pull request GitHub considers mergeable.
+// `neutral` is here for the same reason `skipped` is. GitHub's own rollup counts a neutral
+// conclusion as satisfied, so such a pull request reports CLEAN and merges in the UI — reading it as
+// `fail` would disagree with GitHub exactly as `skipped` would. Because a non-required failure ends
+// the wait outright, a bot that emits `neutral` to say it has nothing to report would kill a
+// `followup` on a pull request GitHub considers mergeable.
 // `action_required` and `stale` stay out on purpose: GitHub does not count either as satisfied, and
 // a wrongly-blocked run costs one re-run of `followup` while a wrongly-passed one ships code no gate
 // ever cleared.
@@ -53,9 +52,8 @@ function read_string(value: unknown): string | undefined {
 }
 
 // `EXPECTED` is GitHub's state for a required status context that has not been posted yet, so it is
-// a check still to come rather than one that failed. Reading it as `fail` only delayed the merge
-// until joshuafolkken/kit#990; it would now end the wait on the first poll of a run that is still
-// legitimately progressing — the premature red exit kit#851 was filed to remove.
+// a check still to come rather than one that failed. Reading it as `fail` would end the wait on the
+// first poll of a run that is still legitimately progressing — a premature red exit.
 const PENDING_STATUS_STATES = new Set(['pending', 'expected'])
 
 function parse_status_context(item: RollupItemData): string {