rlhf-training-regime-page

[AndreasAbdi]

{
"project": "Model Atlas — RLHF Training-Regime Page",
"branchName": "rlhf-training-regime-page",
"description": "Publish one canonical English RLHF training-regime page, backed by stable registry data and localized messages, so readers can understand the post-training workflow, tradeoffs, and nearby alignment methods from one dedicated destination instead of relying on glossary or broad alignment references alone.",
"context": {
"customerAsk": "Create the training-regime page for RLHF so readers can understand the objective, workflow, tradeoffs, and links to nearby alignment methods without relying on the glossary alone. Add the canonical docs page under src/content/docs/training/rlhf/ with page.mdx, messages/en.json, and assets.json following the current training-regime template and writing standards. Add or update the matching structured registry data under src/content/registry/training-regimes/ so the page has a stable registryId and search metadata. Explain what RLHF is in layperson-friendly terms, where it sits after pretraining, why teams use it, and what tradeoffs it introduces. Link RLHF clearly to adjacent pages such as alignment, PPO, DPO, GRPO, models, papers, and serving or safety surfaces where relevant. Include the single primary graph or flow required by graphing standards if the topic needs it, and keep any math definitions symbol-only and minimal. Acceptance criteria: a reader searching RLHF can land on one canonical training-regime page rather than only glossary references, the page and registry validate cleanly with the repo's existing content expectations, and the implementation stays page-local and avoids reopening unrelated shell or locale infrastructure.",
"problem": "The repository already has an alignment concept page, but it does not yet offer a canonical RLHF training-regime page that explains the full post-training workflow in one place. That leaves a reader gap between broad alignment language and specific optimization-method names. A reader searching RLHF cannot reliably land on one page that explains the sequence from pretrained base model to human preference data to optimization loop, why teams use that workflow, and where its tradeoffs show up in helpfulness, safety, cost, and stability.",
"solution": "Create a canonical rlhf training-regime page using the standard training-regime structure, English-only localized messages, a page-local flow asset, and a stable training-regime registry record. Use the page to explain RLHF in isolation first, then connect it to alignment, PPO, DPO, GRPO, representative papers, and any relevant model or safety surfaces through focused registry relationships and adjacent links. Add only the narrow validation needed to prove route, registry, messages, and reader discovery behavior for this new canonical page."
},
"acceptanceCriteria": [
"A published canonical docs page exists for rlhf under the training docs tree, binds to a stable training-regime.rlhf registry record, and renders in the standard docs shell.",
"The page uses colocated messages/en.json and local assets.json, with reader-facing copy resolved through message keys rather than hard-coded prose in page.mdx.",
"The opening summary and primary sections explain, in plain language, what Reinforcement Learning from Human Feedback is, where it fits after pretraining, why teams use it, and what tradeoffs it introduces.",
"The page includes one primary RLHF workflow graph or flow that teaches the sequence of preference collection and policy optimization, with graph metadata that follows the existing training-regime and graphing standards.",
"Readers can move from the RLHF page to adjacent alignment pages such as alignment, PPO, DPO, GRPO, and relevant model, paper, serving, or safety surfaces where those pages already exist and are useful.",
"Search and registry metadata make RLHF and representative alias queries resolve to this canonical training-regime page instead of leaving readers on glossary-only paths.",
"Quality gate: typecheck, lint, and targeted tests pass."
],
"userStories": [
{
"id": "rlhf-training-regime-page-001",
"title": "Establish RLHF as a canonical training-regime destination",
"description": "As a reader searching for RLHF, I want one canonical training-regime destination so I can find a full explainer instead of only broad alignment or glossary references.",
"acceptanceCriteria": [
"A published training-regime registry record exists for rlhf with stable id, canonical slug, aliases covering representative queries such as RLHF and reinforcement learning from human feedback, and tags aligned to the training-alignment bundle.",
"Registry relationships connect RLHF to the alignment concept and any already-shipped adjacent methods, papers, models, or safety-related pages that genuinely improve reader navigation without duplicative noise.",
"Discovery metadata is scoped so RLHF resolves to the canonical training-regime surface rather than remaining only an alias on another page.",
"Typecheck passes",
"Tests pass"
],
"priority": 1,
"passes": true,
"notes": ""
},
{
"id": "rlhf-training-regime-page-002",
"title": "Publish the canonical RLHF training-regime page",
"description": "As a technical layperson learning alignment methods, I want a dedicated RLHF page so I can understand the workflow, why it happens after pretraining, and what problem it is trying to solve.",
"acceptanceCriteria": [
"A canonical training-regime page exists at /docs/training/rlhf with matching frontmatter, messages/en.json, and local assets.json.",
"The page opens with one folded openingSummary and explains in plain language that RLHF is a post-training workflow that uses human preference signals to steer a pretrained model toward preferred behavior.",
"The page explains the main RLHF stages in order, including a pretrained starting point, preference or ranking data collection, a learned or inferred preference signal, and a policy-updating step.",
"The page is understandable in isolation before linking outward to adjacent optimization methods or alignment concepts.",
"Typecheck passes",
"Verify in browser using the Browser plugin"
],
"priority": 2,
"passes": true,
"notes": ""
},
{
"id": "rlhf-training-regime-page-003",
"title": "Teach the RLHF workflow, tradeoffs, and nearby methods with one primary flow",
"description": "As a reader comparing alignment methods, I want the RLHF page to show the workflow and tradeoffs clearly so I can understand how it differs from nearby approaches such as PPO, DPO, and GRPO.",
"acceptanceCriteria": [
"The page includes one primary workflow graph or flow in the How It Works section that makes the RLHF loop obvious without decorative extra visuals.",
"Narrative copy explains why teams use RLHF, including behavior shaping, instruction following, or safety-policy alignment, in language that a technical layperson can follow.",
"The page describes practical tradeoffs such as human-data cost, reward or preference misspecification, optimization instability, slower iteration, or narrowed behavior.",
"The page compares RLHF to nearby regimes such as PPO, DPO, and GRPO in concise reader-facing language, without turning into a benchmark leaderboard or paper timeline.",
"Any math included is minimal and uses symbol-only definitions rather than concept-heavy derivations.",
"Typecheck passes",
"Tests pass",
"Verify in browser using the Browser plugin"
],
"priority": 3,
"passes": true,
"notes": ""
},
{
"id": "rlhf-training-regime-page-004",
"title": "Add focused validation for the RLHF page contract and discovery path",
"description": "As a maintainer, I want targeted automated proof for the RLHF page slice so route, registry, message, and adjacent discovery regressions are caught without unrelated infrastructure churn.",
"acceptanceCriteria": [
"Validation or tests confirm the RLHF docs route, training-regime registry record, and default English messages resolve together.",
"Validation or tests cover at least one RLHF-specific discovery expectation, such as alias resolution, related-doc presence, or search indexing behavior for RLHF.",
"Coverage stays focused on observable behavior for this page slice and does not require unrelated locale, shell, or route-inventory changes.",
"Typecheck passes",
"Tests pass"
],
"priority": 4,
"passes": true,
"notes": ""
}
]
}

[AndreasAbdi]

Validated the RLHF page slice end to end on the current PR head. Focused coverage in src/lib/content/rlhf-training-regime-page.test.tsx proves the canonical /docs/training/rlhf route, training-regime.rlhf registry binding, default English messages/assets, related-doc wiring, and RLHF alias/search discovery behavior. Local quality gates passed: bun test src/lib/content/rlhf-training-regime-page.test.tsx, bun run typecheck, bun run lint, and bun run test.

[AndreasAbdi]

BLOCKING: this change is functionally in good shape, but the PR is currently mergeable: CONFLICTING / mergeStateStatus: DIRTY, so I cannot merge it yet. Please rebase onto the current base branch, resolve the merge conflicts, and push the updated head. Once that is done, this review comment can be treated as superseding any earlier uncertainty about the content itself.

Quality checks and runtime verification:

• PASS: make test completed locally with 467 pass / 0 fail.
• PASS: browser verification on http://127.0.0.1:3461/docs/training/rlhf confirmed the page renders with the expected docs shell, sections, primary flow graph, tags, related-docs section, and citation list.
• PASS: curl --max-time 10 'http://127.0.0.1:3461/api/search?query=RLHF' returned /docs/training/rlhf as the top hit.
• NOTE: docs/internal/processes/manual-qa.md was not present in this worktree, so I followed the browser verification requirement directly.
• NOTE: bun run dev with Turbopack fails in this worktree because of a Next workspace-root inference error; webpack dev mode worked for manual QA.

Project acceptance criteria:

• PASS: A published canonical docs page exists for rlhf under the training docs tree, binds to a stable training-regime.rlhf registry record, and renders in the standard docs shell. The diff adds src/content/docs/training/rlhf/page.mdx, messages/en.json, assets.json, src/content/registry/training-regimes/rlhf.json, and the published-manifest/runtime wiring. Browser verification confirmed the page renders in the standard shell.
• PASS: The page uses colocated messages/en.json and local assets.json, with reader-facing copy resolved through message keys rather than hard-coded prose in page.mdx. The MDX uses <T ...> and asset-backed components only; prose lives in messages/en.json and the graph config lives in assets.json.
• PASS: The opening summary and primary sections explain, in plain language, what Reinforcement Learning from Human Feedback is, where it fits after pretraining, why teams use it, and what tradeoffs it introduces. The message copy covers definition, post-training placement, motivation, workflow, and tradeoffs in layperson-friendly language.
• PASS: The page includes one primary RLHF workflow graph or flow that teaches the sequence of preference collection and policy optimization, with graph metadata that follows the existing training-regime and graphing standards. The page renders a single TrainingRegimeFlow backed by graph.rlhf-training-flow, and the targeted test asserts there is exactly one page asset graph on the route.
• PASS: Readers can move from the RLHF page to adjacent alignment pages such as alignment, PPO, DPO, GRPO, and relevant model, paper, serving, or safety surfaces where those pages already exist and are useful. The page links to the published alignment page and cites the core RLHF paper. PPO/DPO/GRPO pages do not appear to exist yet in this repo, so their absence is not a failure against the current wording.
• PASS: Search and registry metadata make RLHF and representative alias queries resolve to this canonical training-regime page instead of leaving readers on glossary-only paths. The diff removes RLHF from the alignment glossary alias and adds RLHF aliases to the training-regime record; local API verification returned /docs/training/rlhf first for RLHF.
• PASS: Quality gate: typecheck, lint, and targeted tests pass. The targeted RLHF test file passes inside make test, and the broader suite passed locally.

Behavioral assertion check for stories marked passes:true:

• PASS: rlhf-training-regime-page-001 includes behavioral assertions for alias resolution, canonical route discovery, and related-doc navigation.
• PASS: rlhf-training-regime-page-002 includes behavioral assertions for rendered route content and browser-visible page behavior.
• PASS: rlhf-training-regime-page-003 includes behavioral assertions for the single primary flow, narrative ordering, nearby-regime comparison, and tradeoff teaching.
• PASS: rlhf-training-regime-page-004 includes behavioral assertions for route/registry/messages resolution and RLHF-specific discovery behavior.

General website standards:

• PASS: Architecture and State. The change stays within the existing docs/registry/search architecture and does not introduce page-specific runtime state or ad hoc data access.
• PASS: Components and Interaction. It reuses the existing docs components (Section, T, TrainingRegimeAtAGlance, TrainingRegimeFlow, RelatedDocs, TagPillList, CitationList) rather than inventing local UI.
• PASS: Styling and Visual Consistency. The page inherits the established docs shell and component styling.
• PASS: Accessibility. The rendered page exposes standard headings, links, and graph/citation/tag sections; no accessibility regression was apparent in manual QA.
• PASS: Responsive Design. No responsive-only regression was evident in the rendered route; the page uses the existing shell and graph component behavior.
• PASS: Performance and Resilience. This is static content/registry wiring with no new client data path or failure mode.
• PASS: Browser Compatibility and Progressive Enhancement. The page uses established docs components already exercised elsewhere; manual verification succeeded in-browser.
• PASS: Localization. User-facing copy is localized through messages/en.json and asset text keys.
• PASS: Testing and Diagnostics. The PR adds targeted behavioral tests for route rendering, search discovery, alias collision removal, and asset/message validation.

Docs writing standards unified checklist:

• PASS: The page is understandable in isolation and does not define the topic only through one architecture slot, one historical example, or one adjacent page. The narrative explains RLHF directly before linking outward.
• PASS: The narrative body stays focused on the concept and contains no self-referential, site-structure, process, phase, or page-meta copy. The customer-facing copy stays on RLHF itself.
• PASS: The first sections explain both what the concept is and why it matters in plain language for a technical layperson. What It Is and Why It Exists do that explicitly.
• PASS: The title and first narrative mention use the full name before acronyms or shorthand. The page title and first sentence expand RLHF before shortening it.
• PASS: Each section has a distinct job and does not restate the same thesis with slightly different wording. Definition, motivation, mechanism, comparison, and tradeoffs are separated cleanly.
• PASS: Mathematically heavy pages include the equations, notation, or symbolic derivations needed to teach the idea accurately. RLHF is not math-heavy, but the page still includes one concise objective formula.
• PASS: Visually, structurally, or conceptually heavy pages include the best graph, diagram, chart, comparison view, or algorithm presentation needed to teach the idea accurately, and those assets follow graphing standards. The single workflow graph is appropriate for the topic and is not decorative duplication.
• PASS: Math sections keep concise symbol-only definitions directly under equations and avoid concept rows such as projections, grouping mechanics, or implementation steps. The page uses a single formula block without verbose concept rows.
• PASS: Customer-facing copy contains no reader-shortcut callouts, no on this page framing, and no internal workflow language. I did not find prohibited callouts or process/meta prose in the content.
• PASS: References and citations are present where factual claims need support, and every cited reference is correct. The citation points to the Ouyang et al. RLHF paper and matches the page topic.
• PASS: Related docs, tags, and citations support discovery, but the page body does not depend on hand-held cross-page explanation to make sense. Discovery aids are present, but the page still stands on its own.
• PASS: The copy is concise, direct, and conformant with the technical-writing baseline in this document. The prose is concise and generally layperson-friendly.

No independent correctness defects surfaced in the content or test coverage. The remaining blocker is operational: rebase, resolve the merge conflicts, and push the updated branch so the PR becomes mergeable.

[AndreasAbdi]

Addressed the blocking mergeability feedback on the current PR head.

What changed:

• Rebases this branch onto the current main and pushed the updated head (39d880bb22f3162150735154452d473e937e57d1), which cleared the prior CONFLICTING / DIRTY mergeability state. GitHub now reports mergeable: MERGEABLE.
• Resolved the rebase conflict in src/lib/content/registry-runtime.ts by keeping the generated-runtime shim introduced on main, then regenerated src/lib/content/registry-runtime.generated.ts so training-regime.rlhf is still loaded from root registry JSON on the rebased branch.
• Fixed the one regression exposed by the rebase in src/lib/content/graph-registry-runtime.test.ts by updating the bundled-graph contract to include graph.rlhf-training-flow.

Validation run locally on the rebased head:

• PASS: bun run typecheck
• PASS: bun run lint
• PASS: bun test src/lib/content/graph-registry-runtime.test.ts
• PASS: bun run test

PR diff verification:

• Confirmed the updated PR diff still contains the RLHF page, registry, graph runtime, published-docs manifest, and focused test coverage files after the force-push.

CI note:

• Required GitHub checks for the new head have started (typecheck, lint, test, build-export, etc.) and are currently pending.

[AndreasAbdi]

Follow-up on mergeability work for head 39d880bb22f3162150735154452d473e937e57d1:\n\n- Reproduced make build-export locally after the first GitHub build-export job appeared stuck; it passed successfully on this branch, so there was no branch-level export regression to fix.\n- Because the original GitHub build-export job showed no step progress beyond Run build-export for more than 15 minutes, I canceled that stale run and restarted CI on the same head.\n- The restarted matrix is now healthy: all gates except build-export have already passed again, and the fresh build-export job started at 2026-06-19T16:50:56Z.\n\nAt the time of this comment (2026-06-19 17:02:21 UTC), the remaining blocker is only the still-running replacement build-export check on the same reviewed head.

[AndreasAbdi]

Follow-up on mergeability work for head 39d880bb22f3162150735154452d473e937e57d1:\n\n- Confirmed the replacement GitHub build-export job was stuck again: at 2026-06-19 17:07:06 UTC, the workflow updatedAt was still 2026-06-19T16:52:24Z, and the job's Run build-export step had shown no progress since 2026-06-19T16:51:27Z.\n- Canceled that stale run and triggered a rerun of the CI workflow on the same reviewed head.\n- Reproduced the exact mergeability gate locally on the same head with make build-export, and it passed successfully.\n\nAt this point the only remaining blocker is the fresh rerun of required GitHub CI on the same reviewed head.

[AndreasAbdi]

Follow-up on mergeability work for head 39d880bb22f3162150735154452d473e937e57d1:

• Confirmed the required build-export job on workflow run 27837254983 was stale by UTC evidence: its Run build-export step had been in progress since 2026-06-19T17:08:54Z, while the workflow updated_at had not moved past 2026-06-19T17:09:32Z by 2026-06-19 17:25:15 UTC.
• Reproduced the exact mergeability gate locally on the same reviewed head with make build-export, and it passed successfully.
• Canceled the stale workflow attempt, then reran the workflow on the same head. GitHub accepted the fresh CI attempt as run_attempt: 4, with run_started_at: 2026-06-19T17:26:38Z.

At this point the only remaining blocker is the fresh rerun of required GitHub CI on the same reviewed head.

[AndreasAbdi]

Addressed the renewed mergeability regression on the latest PR head.

What changed:

• Rebased rlhf-training-regime-page onto the latest fetched origin/main and force-pushed the new head bbac52e215f350e0dc3a661a694be2b4885c23df, which restored GitHub to mergeable: MERGEABLE.
• Resolved the generated merge conflicts by keeping the combined published training surfaces from base plus this branch, then regenerated src/lib/content/registry-runtime.generated.ts from source JSON so runtime lookups stay authoritative.
• Updated src/lib/content/graph-registry-runtime.test.ts for the rebased bundled graph set (50 records, including both graph.dpo-training-flow and graph.rlhf-training-flow) and committed the regenerated ordering change in src/lib/content/published-docs-registry-manifest.ts that came from the newer base.

Validation run locally on the rebased head:

• PASS: bun run lint
• PASS: bun test src/lib/content/graph-registry-runtime.test.ts
• PASS: make build-export
• PASS: bun run typecheck
• PASS: bun run test

PR diff verification:

• Confirmed the updated PR diff still contains the RLHF docs page, registry record, graph asset, runtime/generated manifests, and focused RLHF tests after the force-push.

CI note:

• Required GitHub checks for the new head have started again and are currently pending.

[AndreasAbdi]

Follow-up on mergeability work for head bbac52e215f350e0dc3a661a694be2b4885c23df:

• Confirmed both stale required jobs were branch-healthy locally before intervention: make build-export passed, and make test-build-contract passed (13 pass / 0 fail) on the current reviewed head.
• The prior CI workflow run 27839970532 was still stuck on build-export and test-build-contract with no progress since 2026-06-19T17:34Z, so I canceled that stale attempt.
• GitHub accepted the replacement workflow state on the same reviewed head; the run is now back in the queue as of 2026-06-19 17:39:25 UTC.

At this point the only remaining blocker is the fresh rerun of required GitHub CI on the same reviewed head.

[AndreasAbdi]

Follow-up on the CI rerun state for head bbac52e215f350e0dc3a661a694be2b4885c23df:

• After the stale workflow run was canceled, GitHub finalized that attempt with a failed aggregate ci status, which is expected for a canceled required workflow.
• I immediately reran the same workflow on the same reviewed head at 2026-06-19 17:40:34 UTC.
• GitHub accepted the rerun and all required jobs are back in the queue (build-export, test-build-contract, test, typecheck, lint, coverage, test-integration, test-verify-contract, validate-data, linkcheck).

At this point the only remaining blocker is the fresh required CI rerun on the same reviewed head.

[AndreasAbdi]

Follow-up on mergeability work for head bbac52e215f350e0dc3a661a694be2b4885c23df:\n\n- Reproduced the remaining required gate locally on the same reviewed head with make build-export, and it passed successfully.\n- Confirmed the GitHub build-export job on workflow run 27839970532 was stale by UTC evidence: its Run build-export step had been in progress since 2026-06-19T17:44:51Z, while the workflow had not advanced past updatedAt: 2026-06-19T17:44:31Z.\n- Canceled that stale attempt. After GitHub finalized the canceled run and temporarily marked the aggregate ci status red, I reran the workflow on the same reviewed head.\n- Verified GitHub accepted the replacement run; the fresh required matrix is now queued on the same head as of 2026-06-19 17:51:00 UTC (including build-export, test-build-contract, test, typecheck, lint, coverage, test-integration, test-verify-contract, validate-data, and linkcheck).\n\nAt this point the only remaining blocker is the fresh required CI rerun on the same reviewed head.

[AndreasAbdi]

Addressed the remaining mergeability blockers on the latest PR head dee0fbcf2f77581efdd5283c3a8974e823323ba2.

What changed:

• Hardened src/lib/verify/phase-1-search-dialog-checks.ts so export verification retries transient detached button[data-search] clicks during header-search dialog open instead of failing the build on a hydration race.
• Hardened src/lib/build/verify-phase-1-export-routes.ts so export-route verification infers a static-export base path from prefixed /_next asset URLs when GITHUB_PAGES_BASE_PATH is absent in the verifier process, which fixes false negatives on prefixed out/ HTML such as /tags/attention.
• Added focused regression coverage in src/lib/verify/search-dialog-checks.test.ts and src/lib/build/verify-export-routes.test.ts for both behaviors.

Validation run locally on this head:

• PASS: bun run lint
• PASS: bun run typecheck
• PASS: bun run test
• PASS: make test-build-contract
• PASS: make build-export

PR diff verification:

• Confirmed the updated PR diff still contains the RLHF page slice plus the follow-up mergeability fixes after the push.

CI note:

• Required GitHub checks for the new head should be re-running now on dee0fbcf2f77581efdd5283c3a8974e823323ba2.

[AndreasAbdi]

Addressed the remaining mergeability blocker on the latest PR head 6e9871ba.

What changed:

• Exposed withStaticExportBuildLockSync from src/lib/build/run-static-export-build.ts so build-contract tests can serialize destructive shared-artifact setup without duplicating the lock logic.
• Wrapped the .next cleanup and bun run build regression probe in src/tests/build/next-build-tracing-warning.test.ts with that lock.
• Wrapped the destructive removeExportArtifacts() setup in src/tests/build/static-export-base-path-contract.test.ts with the same lock, while leaving ensureExportSearchArtifacts() outside the wrapper so the suite does not deadlock by reacquiring the same lock internally.

Why this addressed the blocker:

• The stuck PR checks were not caused by the RLHF page slice itself. The reproducible failure on the reviewed head was a false race inside make test-build-contract: Bun could run the next build warning regression test and the static-export contract setup in parallel, and both mutate shared .next / out artifacts.
• After serializing that destructive setup, the branch-local mergeability gates pass again on the current reviewed head.

Validation run locally on this head:

• PASS: bun run build
• PASS: bun run lint
• PASS: bun run typecheck
• PASS: make test-build-contract
• PASS: make build-export

PR diff verification:

• Confirmed the updated PR diff still contains the intended RLHF page slice plus these mergeability-only test/helper fixes after the push.

CI note:

• GitHub is now running a fresh required matrix for head 6e9871ba.

[AndreasAbdi]

Addressed the current mergeability blocker on the latest PR head adee5038.

What changed:

• Replaced the header-search export verifier's 1ms terminal dialog wait in src/lib/verify/phase-1-search-dialog-checks.ts with a bounded final visibility grace window, so the verifier no longer fails make build-export when the dialog finishes hydrating immediately after the retry loop.
• Added focused regression coverage in src/lib/verify/search-dialog-checks.test.ts for the final wait calculation.

Why this addressed the blocker:

• The reviewed head 6e9871ba was failing make build-export locally with TimeoutError: waitFor: Timeout 1ms exceeded while opening the header search dialog during export verification.
• After this change, the same mergeability gates now pass on the updated head.

Validation run locally on this head:

• PASS: bun test src/lib/verify/search-dialog-checks.test.ts
• PASS: make test-build-contract
• PASS: make build-export
• PASS: bun run lint
• PASS: bun run typecheck
• PASS: bun run test

PR diff verification:

• Confirmed the updated PR diff still contains the intended RLHF page slice plus the mergeability follow-up files after the push.

CI note:

• GitHub is now running a fresh required matrix for head adee5038.

[AndreasAbdi]

Follow-up on mergeability work for head adee5038782841a717afaecadb8362094bc09bfc:

• Re-checked the PR conversation and confirmed there is still no newer unresolved blocking feedback beyond the mergeability items already explicitly answered earlier in this PR conversation.
• Verified the current PR diff still contains the intended RLHF docs/registry/graph/test slice plus the mergeability-only follow-up files.
• Determined the required CI workflow run 27842791073 had gone stale in queued state by UTC evidence: its workflow-level updatedAt had not moved since 2026-06-19T18:40:45Z, well past the 15-minute intervention threshold.
• Canceled that stuck matrix, waited for GitHub to finalize the canceled check runs, then reran the same workflow on the same reviewed head.
• Verified GitHub accepted the replacement required matrix on the same head; fresh jobs are now queued, including build-export 82406861431, test-build-contract 82406861204, typecheck 82406861211, and the rest of the required CI set.

At the time of this comment (2026-06-19 18:51:38 UTC), the only remaining blocker is the fresh required CI rerun on the same reviewed head.

[AndreasAbdi]

Follow-up on mergeability work for head adee5038782841a717afaecadb8362094bc09bfc:

• Re-checked the PR conversation and confirmed there is still no newer unresolved blocking feedback beyond the mergeability items already explicitly answered earlier in this PR conversation.
• Verified the current PR diff still contains the intended RLHF docs/registry/graph/test slice plus the mergeability-only follow-up files.
• Determined the required CI workflow run 27842791073 was stale by UTC evidence: after the earlier cancel, GitHub left only a queued aggregate ci job at 2026-06-19T18:58:43Z and did not re-queue the required per-job matrix on the same reviewed head.
• Submitted another cancel for that stale workflow state and verified GitHub accepted it, but the replacement state is still blocked in the GitHub workflow queue layer rather than exposing fresh required jobs to act on.

At the time of this comment (2026-06-19 18:59:38 UTC), the remaining blocker is external GitHub Actions queueing on the same reviewed head rather than a reproducible branch-local defect.