prefill-concept-page

[AndreasAbdi]

{
"project": "Model Atlas — Prefill Canonical Concept Page",
"branchName": "prefill-concept-page",
"description": "Publish one canonical English prefill concept page, backed by the existing registry record and localized messages, so readers can understand the first serving-stage prompt pass, distinguish it from decode, and navigate cleanly to adjacent cache, latency, and attention docs.",
"context": {
"customerAsk": "Customer ask alignment: refill the queue with another fresh, narrow generation-serving concept slice so the active worker count returns to the requested range without reusing already-claimed PR surfaces. Add the canonical English concept page for prefill, because readers need the missing broad explainer for the first serving stage before they can understand decode-time latency, KV cache reuse, and serving tradeoffs. Treat this as one narrow page-level slice on current main. Scope: create the canonical concept page, colocated messages/en.json, and any required assets.json, using the existing published concept.prefill record; classify the page correctly with the project docs; connect aliases, tags, and related links so the page bridges kv-cache, decode, prefill-decode-split, autoregressive-generation, time-to-first-token, attention, and grouped-query-attention; and add only the minimum focused validation/tests needed for the touched page and registry-backed discovery surfaces. The explanation should define prefill in layperson terms, show why the prompt-processing pass is different from token-by-token decoding, and explain what readers should expect it to dominate in latency discussions. Keep the slice English-only and avoid reopening localization infrastructure or unrelated transformer foundation families. Acceptance criteria: the prefill concept page exists as a canonical docs page on current main, resolves to the existing registry record, supports nearby discovery paths, and focused touched checks pass.",
"problem": "The repository already has the published concept.prefill registry record and a shipped prefill glossary page, plus nearby serving pages for kv-cache, decode, prefill-decode-split, autoregressive-generation, and time-to-first-token, but it still lacks the canonical broad concept page that explains prefill as the prompt-processing stage before token-by-token generation begins. Readers therefore have to infer the idea from a glossary-sized page and narrower latency or cache pages instead of landing on one plain-language bridge that explains why prompt length changes early latency so much and why decode-time tradeoffs are different.",
"solution": "Publish a canonical English /docs/concepts/prefill page using the standard concept-page contract, bind it to the existing concept.prefill registry record, make the concept route the clear canonical broad explainer instead of leaving glossary-only discovery as the main surface, connect the required aliases, tags, and related-doc paths to nearby serving and attention pages, and add only the focused validation needed to prove route, message, registry, and discovery integrity for this narrow slice."
},
"acceptanceCriteria": [
"A published canonical docs page exists for prefill under the concepts docs tree, with matching English messages and any required local assets.",
"Discovery surfaces treat the concept route as the canonical broad explainer for prefill and do not leave readers with competing glossary-only canonical targets for the same concept.",
"The page resolves cleanly to the existing concept.prefill discovery record and preserves accurate registry-backed discovery through aliases, tags, and related-doc relationships.",
"The page opens with one folded openingSummary, explains prefill in layperson terms, clearly distinguishes the full-prompt prefill pass from token-by-token decode, and explains why prompt-side work often dominates time-to-first-token discussions.",
"Readers can navigate between prefill, kv-cache, decode, prefill-decode-split, autoregressive-generation, time-to-first-token, attention, and grouped-query-attention through shipped nearby discovery surfaces with no broken or misleading links.",
"Focused validation covers the touched page contract plus the registry-backed related-doc, route, or search expectations needed for this slice, without broad unrelated test expansion.",
"The implementation stays English-only and does not reopen localization infrastructure, unrelated transformer-foundation-family pages, or broad taxonomy restructuring beyond what is required for this page to land cleanly.",
"Quality gate: make typecheck, make lint, and focused tests pass."
],
"userStories": [
{
"id": "prefill-concept-page-001",
"title": "Promote prefill to the canonical concept discovery surface",
"description": "As a reader searching for prefill, I want the existing concept.prefill record and route behavior to lead me to one canonical broad explainer so I do not have to piece the idea together from a glossary stub or narrower latency pages.",
"acceptanceCriteria": [
"The existing concept.prefill record remains the canonical backing record and is updated only as needed with aliases, related ids, tags, citations, or other controlled metadata that match a broad concept page.",
"Discovery surfaces expose /docs/concepts/prefill as the canonical broad explainer for prefill, and any retained glossary surface does not compete as the main canonical destination for the same concept.",
"Registry relationships connect the concept page to shipped nearby docs for kv-cache, decode, prefill-decode-split, autoregressive-generation, time-to-first-token, attention, and grouped-query-attention.",
"Discovery metadata distinguishes the broad prefill concept from neighboring serving-stage or latency pages without introducing duplicate canonical targets or broad taxonomy churn.",
"Typecheck passes",
"Tests pass"
],
"priority": 1,
"passes": true,
"notes": ""
},
{
"id": "prefill-concept-page-002",
"title": "Publish the canonical prefill concept page",
"description": "As a technical layperson learning about LLM serving, I want a dedicated prefill concept page so I can understand the prompt-processing stage before I dive into decode loops, cache reuse, or latency metrics.",
"acceptanceCriteria": [
"A canonical prefill docs page exists with matching frontmatter, messages/en.json, and any required local assets.json.",
"The page opens with one folded openingSummary and explains prefill in plain language before narrowing into inference-serving context.",
"The page clearly explains that prefill is the model pass that processes the entire existing prompt, builds the initial hidden-state and attention-side context needed for generation, and happens before the first generated token is emitted.",
"The page clearly explains that decode is different because it advances token by token after prefill rather than rereading the whole prompt as one initial stage.",
"The page clearly explains why readers should expect prefill to dominate time-to-first-token discussions as prompts get longer, without turning the page into a benchmark table or kernel-level tutorial.",
"Typecheck passes",
"Tests pass",
"Verify in browser using the Browser plugin"
],
"priority": 2,
"passes": true,
"notes": ""
},
{
"id": "prefill-concept-page-003",
"title": "Route readers between prefill and nearby serving and attention docs",
"description": "As a reader exploring serving tradeoffs, I want related docs, tags, and search surfaces to guide me into the broad prefill explainer and then onward to the right neighboring pages.",
"acceptanceCriteria": [
"Representative queries such as prefill, prompt processing, prompt pass, and first token latency return the canonical concept page as a direct relevant result rather than leaving readers only on narrower pages.",
"The concept page renders registry-backed related docs and tag surfaces that connect it to kv-cache, decode, prefill-decode-split, autoregressive-generation, time-to-first-token, attention, and grouped-query-attention.",
"At least one neighboring shipped page or discovery surface presents the new concept page as a navigable related destination so readers can reach it without typing the exact slug.",
"Browser-visible rendering shows the title, folded summary, tags, and related-doc links without broken links or missing-content placeholders.",
"Typecheck passes",
"Tests pass",
"Verify in browser using the Browser plugin"
],
"priority": 3,
"passes": true,
"notes": ""
},
{
"id": "prefill-concept-page-004",
"title": "Add focused validation for the prefill concept-page slice",
"description": "As a maintainer, I want targeted automated proof for the prefill concept-page slice so route, message, registry, and discovery regressions are caught without unrelated test expansion.",
"acceptanceCriteria": [
"Validation or tests confirm the /docs/concepts/prefill route, concept.prefill record, and default English messages resolve together.",
"Coverage asserts at least one page-specific discovery outcome and at least one page-specific related-link expectation for the new concept page.",
"Focused checks stay limited to touched content and discovery integrity rather than inventory snapshots, locale churn, or unrelated suite expansion.",
"Typecheck passes",
"Tests pass"
],
"priority": 4,
"passes": true,
"notes": ""
}
]
}

[AndreasAbdi]

Addressed prefill-concept-page-004 in commit d794077c.

What changed:

• Added a focused prefill validation in src/lib/content/prefill-concept.test.ts that loads published English docs pages and asserts /docs/concepts/prefill resolves with the expected registry id, folded summary messages, and nearby curated related-doc destinations.

Validation run:

• make typecheck
• make lint
• bun test src/lib/content/prefill-concept.test.ts src/tests/search/search-page-panel.test.tsx src/app/docs/docs-slug-renderer.test.tsx

[AndreasAbdi]

Addressed mergeability follow-up on current main in commit c51f833b.

What changed:

• Rebased the branch onto current origin/main and restored the canonical /docs/concepts/prefill bundle plus the nearby glossary, registry, and discovery test updates that were missing after replaying the older story commits.
• Adapted the local docs shell to the current opening-summary component contract so the canonical prefill concept route still renders the required folded summary on the rebased head.
• Updated stale inventory and related-doc assertions in nearby serving, architecture, tokenization, and attention-tag tests so they match the current published route graph on main while preserving the prefill concept behavior.

Validation run:

• make typecheck
• make lint
• make test

[AndreasAbdi]

BLOCKING

Project acceptance criteria

• PASS: A published canonical docs page exists for prefill under the concepts docs tree, with matching English messages and any required local assets. The PR adds src/content/docs/concepts/prefill/page.mdx, messages/en.json, and assets.json and publishes the concept route.
• PASS: Discovery surfaces treat the concept route as the canonical broad explainer for prefill and do not leave readers with competing glossary-only canonical targets for the same concept. src/content/docs/glossary/prefill/page.mdx is now draft, and touched route/search tests were updated to point at /docs/concepts/prefill.
• PASS: The page resolves cleanly to the existing concept.prefill discovery record and preserves accurate registry-backed discovery through aliases, tags, and related-doc relationships. The page binds registryId: concept.prefill, keeps serving-oriented aliases/tags, and renders curated/derived related docs.
• PASS: The page opens with one folded openingSummary, explains prefill in layperson terms, clearly distinguishes the full-prompt prefill pass from token-by-token decode, and explains why prompt-side work often dominates time-to-first-token discussions. The new page copy and renderer/test updates cover this, and browser QA on /docs/concepts/prefill showed the folded summary and the expected definition/contrast sections.
• PASS: Readers can navigate between prefill, kv-cache, decode, prefill-decode-split, autoregressive-generation, time-to-first-token, attention, and grouped-query-attention through shipped nearby discovery surfaces with no broken or misleading links. The concept page renders those links, and neighboring touched pages now point back to /docs/concepts/prefill.
• PASS: Focused validation covers the touched page contract plus the registry-backed related-doc, route, or search expectations needed for this slice, without broad unrelated test expansion. The added src/lib/content/prefill-concept.test.ts includes route/registry/message/search assertions, and the other touched tests are targeted expectation updates for the canonical-route move.
• PASS: The implementation stays English-only and does not reopen localization infrastructure, unrelated transformer-foundation-family pages, or broad taxonomy restructuring beyond what is required for this page to land cleanly. I did not see scope creep beyond the canonical-route promotion.
• PASS: Quality gate: make typecheck, make lint, and focused tests pass. Live CI is green on head c51f833b7b15e05b68f53cc26df0658e907fe914, and local make test passed.

Story behavioral-assertion check

• PASS: prefill-concept-page-001 includes observable discovery behavior (/docs/concepts/prefill becomes the canonical target and neighboring discovery surfaces link to it).
• PASS: prefill-concept-page-002 includes observable page behavior (folded summary plus visible prefill/decode/TTFT explanation and browser verification).
• PASS: prefill-concept-page-003 includes observable search/navigation behavior (representative queries and rendered related/tag surfaces).
• PASS: prefill-concept-page-004 includes observable route/search/related-link validation, not only compile-time gates.

Docs-writing standard checklist

• PASS: 1. The page is understandable in isolation ...
• PASS: 2. The narrative body stays focused on the concept ...
• PASS: 3. The first sections explain both what the concept is and why it matters ...
• PASS: 4. The title and first narrative mention use the full name before acronyms or shorthand.
• PASS: 5. Each section has a distinct job ...
• PASS: 6. Mathematically heavy pages include the equations ... Not needed for this concept page.
• PASS: 7. Visually, structurally, or conceptually heavy pages include the best graph ... Not required here; the topic is explained clearly without a diagram.
• PASS: 8. Math sections keep concise symbol-only definitions ... No math sections were added.
• PASS: 9. Customer-facing copy contains no reader-shortcut callouts ...
• FAIL: 10. References and citations are present where factual claims need support, and every cited reference is correct. src/content/registry/concepts/prefill.json removes the prior citations and leaves citationIds: [], while the new page still makes factual serving claims about prefill dominating TTFT as prompts grow and about the initial KV-cache-building pass. Browser QA also shows an empty References section on /docs/concepts/prefill. Please restore accurate supporting citations for those claims or trim the unsupported claims and remove the empty references section.
• PASS: 11. Related docs, tags, and citations support discovery, but the page body does not depend on hand-held cross-page explanation ...
• PASS: 12. The copy is concise, direct, and conformant ...

General website standard checklist

• PASS: The change respects architecture and dependency boundaries. The route promotion stays within existing local-docs and registry/search patterns.
• PASS: Data flow and ownership are clear. Frontmatter/messages/registry responsibilities remain separated.
• PASS: Shared UI patterns are reused where appropriate. The page uses existing section, related-doc, tags, and citation components.
• PASS: Loading, empty, error, and success states are intentional. No new async UI surface was introduced by this PR.
• PASS: Accessibility, responsive behavior, localization, and browser support were considered. Automated tests cover the canonical route; browser QA confirmed the route renders on the local server.
• PASS: Test evidence matches the risk and user impact. CI plus local make test cover the canonical-route move, search ranking, and related discovery behavior.

Review rules

• FAIL: confirm appropriate tests and quality-check evidence is blocked by the docs-quality issue above, not by missing automation.
• FAIL: verify the change solves the stated problem without obvious regressions until the page ships with real supporting citations instead of an empty References section.

Manual QA note

• /docs/concepts/prefill rendered correctly in the browser with the folded summary, tags, and related links. I did not treat the local /search production-start failure as PR-specific review feedback because that run surfaced an unrelated registry schema error from src/content/registry/modules/absolute-positional-embeddings.json, while CI/search automation for this PR remained green.

Required fix

• Add correct citation support back to concept.prefill and make the page’s References section non-empty, or remove unsupported claims plus the empty References section so the page complies with the docs-writing standard.

[AndreasAbdi]

Addressed the blocking citations feedback in commit f8f2b63.

What changed:

• Restored real supporting references on concept.prefill by adding citation.attention-is-all-you-need, citation.brown-gpt-3, and citation.orca-serving-system to src/content/registry/concepts/prefill.json.
• Tightened the focused prefill slice test in src/lib/content/prefill-concept.test.ts to assert the concept record keeps those citation ids and that the rendered canonical page includes a populated citation list.

Why this resolves the blocker:

• The canonical /docs/concepts/prefill page no longer renders an empty References section.
• The page's serving and TTFT claims are now backed by shipped citation records in the workflow's required reference surface.

Validation run:

• make typecheck
• make lint
• bun run pretest
• bun test src/lib/content/prefill-concept.test.ts src/tests/search/search-page-panel.test.tsx src/app/docs/docs-slug-renderer.test.tsx

[AndreasAbdi]

Follow-up on rebased head 275d33b.

What changed after the citation fix:

• Rebased prefill-concept-page onto current origin/main to clear the PR's dirty mergeability state.
• Kept the prefill citation fix intact on the rebased head: concept.prefill still carries citation.attention-is-all-you-need, citation.brown-gpt-3, and citation.orca-serving-system, and the focused prefill page test still asserts a populated citation list.
• Made the smallest mergeability-only test cleanups needed on the rebased head by deduplicating stale conceptGroup assertions in the attention-tag tests so local typecheck and lint pass again.

Validation rerun on the rebased head:

• make typecheck
• make lint
• bun run pretest
• bun test src/lib/content/prefill-concept.test.ts src/tests/search/search-page-panel.test.tsx src/app/docs/docs-slug-renderer.test.tsx

Current PR state:

• PR head is now 275d33b.
• GitHub reports the PR as mergeable again and has started fresh CI on this head.

[AndreasAbdi]

Addressed the failing required test job on rebased head 5e49b0d.

What changed:

• Updated the attention-tag landing expectations in src/tests/content/attention-tag-landing.test.ts and src/lib/content/content-reconciliation-attention-tag.test.ts to match the current canonical concept ordering under the attention tag (/docs/concepts/kv-cache before /docs/concepts/prefill).
• Updated src/lib/content/kv-cache-concept.test.ts so KV-cache related-link assertions expect the promoted canonical prefill route /docs/concepts/prefill instead of the drafted glossary route.
• Updated src/lib/content/glossary-architecture-index.test.ts so glossary inventory checks use the current shipped glossary count after /docs/glossary/prefill was drafted during canonical-route promotion.

Why this resolves the blocker:

• The previous CI failure was stale test expectation drift on the rebased PR head, not a runtime regression in the published prefill page slice.
• The full suite now matches the current published route graph and shipped glossary inventory on main.

Validation rerun:

• bun run pretest
• Focused bun test slices for the failing glossary, attention-tag, and KV-cache expectations
• make typecheck
• make lint
• make test

[AndreasAbdi]

BLOCKING

This comment supersedes the earlier clear-state comments. The prefill page itself is in good shape and CI is green on head 5e49b0dd1f1968c3e7a79e17e78b81f0089994b8, but the shared docs-shell change introduced a production regression on glossary routes.

Findings

• FAIL: src/app/docs/docs-slug-renderer.tsx:95-99 now renders DocsOpeningSummary for every non-system local docs page, which includes glossary pages. That breaks the repository’s explicit glossary contract that openingSummary stays in messages but must not render in glossary shell output. The existing convergence tests document that rule in src/lib/content/glossary-opening-convergence.test.tsx and src/lib/content/validate-generated-canonical-docs.test.ts. Manual QA on http://127.0.0.1:3456/docs/glossary/token confirmed the regression: the live route now renders a folded <details data-opening-summary="folded">…</details> block above the glossary article. Because src/app/docs/[[...slug]]/page.tsx and src/app/[locale]/docs/[[...slug]]/page.tsx both route through renderDocsSlugPage, this is on the real production path, not just a test helper. Please gate the new opening-summary shell rendering so glossary pages still omit it, and add route-level coverage for that shared renderer behavior.

Project acceptance criteria

• PASS: A published canonical docs page exists for prefill under the concepts docs tree, with matching English messages and any required local assets. The PR adds src/content/docs/concepts/prefill/page.mdx, messages/en.json, and assets.json.
• PASS: Discovery surfaces treat the concept route as the canonical broad explainer for prefill and do not leave readers with competing glossary-only canonical targets for the same concept. The glossary page is drafted and touched route/search expectations point to /docs/concepts/prefill.
• PASS: The page resolves cleanly to the existing concept.prefill discovery record and preserves accurate registry-backed discovery through aliases, tags, and related-doc relationships. The registry record, aliases, tags, and related ids line up with the new route.
• PASS: The page opens with one folded openingSummary, explains prefill in layperson terms, clearly distinguishes the full-prompt prefill pass from token-by-token decode, and explains why prompt-side work often dominates time-to-first-token discussions. Manual QA on /docs/concepts/prefill showed the folded summary and the expected explanation.
• PASS: Readers can navigate between prefill, kv-cache, decode, prefill-decode-split, autoregressive-generation, time-to-first-token, attention, and grouped-query-attention through shipped nearby discovery surfaces with no broken or misleading links. The canonical page and touched nearby pages expose those links.
• FAIL: Focused validation covers the touched page contract plus the registry-backed related-doc, route, or search expectations needed for this slice, without broad unrelated test expansion. The PR changed the shared docs route renderer, but the added validation did not cover the glossary-shell behavioral rule on that production path, so a real regression shipped undetected.
• PASS: The implementation stays English-only and does not reopen localization infrastructure, unrelated transformer-foundation-family pages, or broad taxonomy restructuring beyond what is required for this page to land cleanly. Scope stayed narrow.
• PASS: Quality gate: make typecheck, make lint, and focused tests pass. Required GitHub checks are green and local make test passed.

Story behavioral-assertion check

• PASS: prefill-concept-page-001 includes observable discovery behavior.
• PASS: prefill-concept-page-002 includes observable page behavior.
• PASS: prefill-concept-page-003 includes observable search/navigation behavior.
• PASS: prefill-concept-page-004 includes observable route/search/related-link validation, but the shared-renderer regression means the current coverage is still insufficient for this change.

Docs-writing standard checklist

• PASS: 1. The page is understandable in isolation ...
• PASS: 2. The narrative body stays focused on the concept ...
• PASS: 3. The first sections explain both what the concept is and why it matters ...
• PASS: 4. The title and first narrative mention use the full name before acronyms or shorthand.
• PASS: 5. Each section has a distinct job ...
• PASS: 6. Mathematically heavy pages include the equations ... Not required here.
• PASS: 7. Visually, structurally, or conceptually heavy pages include the best graph ... Not required for this page.
• PASS: 8. Math sections keep concise symbol-only definitions ... No math sections were added.
• PASS: 9. Customer-facing copy contains no reader-shortcut callouts ...
• PASS: 10. References and citations are present where factual claims need support, and every cited reference is correct.
• PASS: 11. Related docs, tags, and citations support discovery, but the page body does not depend on hand-held cross-page explanation ...
• PASS: 12. The copy is concise, direct, and conformant ...

General website standard checklist

• PASS: The change respects architecture and dependency boundaries.
• PASS: Data flow and ownership are clear.
• PASS: Shared UI patterns are reused where appropriate.
• FAIL: Loading, empty, error, and success states are intentional. Not because of async state handling, but because the shared renderer now applies the new summary state to a content kind that is explicitly supposed to omit it.
• PASS: Accessibility, responsive behavior, localization, and browser support were considered.
• FAIL: Test evidence matches the risk and user impact of the change. A shared route-renderer change needed route-level regression coverage for glossary shell behavior and did not get it.

Review rules

• PASS: review correctness before style or preference
• FAIL: verify the change solves the stated problem without obvious regressions The prefill work landed, but glossary pages regressed on the live route shell.
• PASS: check architecture and dependency fit
• PASS: evaluate readability and maintainability
• FAIL: confirm appropriate tests and quality-check evidence because the added tests missed the shared-renderer regression.
• PASS: treat hallucinated APIs, stale patterns, hidden side effects, and subtle edge cases in AI-authored code as high-risk review targets

Quality-check evidence

• PASS: gh pr view --json ... / gh pr checks show all required checks completed successfully on head 5e49b0dd1f1968c3e7a79e17e78b81f0089994b8.
• PASS: local make test passed.
• PASS: Manual QA on /docs/concepts/prefill confirmed the canonical page renders its folded summary, references, and nearby links.
• FAIL: Manual QA on /docs/glossary/token exposed the glossary opening-summary regression described above.

Required fix

• Restrict the new DocsOpeningSummary shell rendering so glossary pages continue to omit rendered opening summaries.
• Add route-level coverage through renderDocsSlugPage (or the route shell it powers) proving glossary pages do not render the opening-summary block while concept pages such as /docs/concepts/prefill still do.

[AndreasAbdi]

Addressed the latest blocking shared-renderer feedback in commit c30d618.

What changed:

• Restricted DocsOpeningSummary in src/app/docs/docs-slug-renderer.tsx so glossary routes no longer render the folded opening-summary shell block, while canonical concept routes such as /docs/concepts/prefill still do.
• Added route-level coverage in src/app/docs/docs-slug-renderer.test.tsx that proves both sides of the contract on the real shared renderer path: /docs/concepts/prefill renders one folded opening summary, and /docs/glossary/token renders none.

Why this resolves the blocker:

• The production glossary route shell no longer regresses by showing an opening-summary block that glossary pages are explicitly required to keep out of rendered output.
• The shared-renderer change is now covered with the missing negative-control route assertion, so this regression is caught at the route level instead of only in page-local tests.

Validation rerun:

• bun run pretest
• bun test src/app/docs/docs-slug-renderer.test.tsx src/lib/content/prefill-concept.test.ts
• make typecheck
• make lint
• make test

Browser verification on http://127.0.0.1:3476:

• /docs/concepts/prefill renders exactly one folded opening summary.
• /docs/glossary/token renders no folded opening summary and no Opening summary label.

[AndreasAbdi]

CLEARING REVIEW

This comment supersedes the earlier BLOCKING renderer feedback. On current head c30d618aca07f1ebff2a0a27a483a10746640ddf, I did not find any remaining blocking issues.

Project acceptance criteria

• PASS: A published canonical docs page exists for prefill under the concepts docs tree, with matching English messages and any required local assets. The PR ships src/content/docs/concepts/prefill/page.mdx, messages/en.json, and assets.json for the canonical concept route.
• PASS: Discovery surfaces treat the concept route as the canonical broad explainer for prefill and do not leave readers with competing glossary-only canonical targets for the same concept. /docs/glossary/prefill is drafted, touched search/index expectations point to /docs/concepts/prefill, and published-page discovery excludes the glossary route.
• PASS: The page resolves cleanly to the existing concept.prefill discovery record and preserves accurate registry-backed discovery through aliases, tags, and related-doc relationships. concept.prefill remains the backing record, keeps the serving aliases/tags, and the page renders curated plus derived related-doc groups from that registry data.
• PASS: The page opens with one folded openingSummary, explains prefill in layperson terms, clearly distinguishes the full-prompt prefill pass from token-by-token decode, and explains why prompt-side work often dominates time-to-first-token discussions. Browser QA on http://127.0.0.1:3476/docs/concepts/prefill showed exactly one folded opening summary plus the expected definition, decode contrast, and TTFT explanation.
• PASS: Readers can navigate between prefill, kv-cache, decode, prefill-decode-split, autoregressive-generation, time-to-first-token, attention, and grouped-query-attention through shipped nearby discovery surfaces with no broken or misleading links. The canonical page renders those nearby links and touched neighboring docs/search surfaces route back to /docs/concepts/prefill.
• PASS: Focused validation covers the touched page contract plus the registry-backed related-doc, route, or search expectations needed for this slice, without broad unrelated test expansion. src/lib/content/prefill-concept.test.ts, src/app/docs/docs-slug-renderer.test.tsx, and the touched search/discovery tests cover route, registry, citations, search ranking, and the glossary negative-control renderer behavior.
• PASS: The implementation stays English-only and does not reopen localization infrastructure, unrelated transformer-foundation-family pages, or broad taxonomy restructuring beyond what is required for this page to land cleanly. Scope stayed narrow to the canonical page, registry metadata, route promotion, and dependent discovery assertions.
• PASS: Quality gate: make typecheck, make lint, and focused tests pass. Live required GitHub checks are green on c30d618, and local make test passed.

Story behavioral-assertion check

• PASS: prefill-concept-page-001 includes observable discovery behavior: the canonical route is /docs/concepts/prefill, and nearby discovery surfaces link to it.
• PASS: prefill-concept-page-002 includes observable page behavior: folded summary, visible prefill/decode distinction, and browser verification.
• PASS: prefill-concept-page-003 includes observable search and navigation behavior: canonical search ranking plus rendered related/tag/link surfaces.
• PASS: prefill-concept-page-004 includes observable route/search/related-link assertions rather than compile-only checks.

Docs-writing standard checklist

• PASS: 1. The page is understandable in isolation ...
• PASS: 2. The narrative body stays focused on the concept ...
• PASS: 3. The first sections explain both what the concept is and why it matters ...
• PASS: 4. The title and first narrative mention use the full name before acronyms or shorthand.
• PASS: 5. Each section has a distinct job ...
• PASS: 6. Mathematically heavy pages include the equations ... Not required for this concept page.
• PASS: 7. Visually, structurally, or conceptually heavy pages include the best graph ... Not required here; the page remains understandable without a teaching diagram.
• PASS: 8. Math sections keep concise symbol-only definitions ... No math section was added.
• PASS: 9. Customer-facing copy contains no reader-shortcut callouts ...
• PASS: 10. References and citations are present where factual claims need support, and every cited reference is correct. Browser QA showed a populated References section with the expected citations.
• PASS: 11. Related docs, tags, and citations support discovery, but the page body does not depend on hand-held cross-page explanation ...
• PASS: 12. The copy is concise, direct, and conformant ...

General website standard checklist

• PASS: The change respects architecture and dependency boundaries.
• PASS: Data flow and ownership are clear.
• PASS: Shared UI patterns are reused where appropriate.
• PASS: Loading, empty, error, and success states are intentional. The earlier glossary-summary regression is fixed; glossary routes again omit the shared folded-summary shell block.
• PASS: Accessibility, responsive behavior, localization, and browser support were considered. Route-level tests cover the shared renderer behavior, and browser QA confirmed the concept and glossary routes on the running app.
• PASS: Test evidence matches the risk and user impact of the change. The added tests exercise the shared renderer seam, canonical-route discovery, and search ranking behavior.

Review rules

• PASS: review correctness before style or preference
• PASS: verify the change solves the stated problem without obvious regressions
• PASS: check architecture and dependency fit
• PASS: evaluate readability and maintainability
• PASS: confirm appropriate tests and quality-check evidence
• PASS: treat hallucinated APIs, stale patterns, hidden side effects, and subtle edge cases in AI-authored code as high-risk review targets

Quality-check evidence

• PASS: gh pr view --json ... and gh pr checks show all required checks completed successfully on head c30d618aca07f1ebff2a0a27a483a10746640ddf.
• PASS: local make test passed.
• PASS: production-path browser QA on http://127.0.0.1:3476/docs/concepts/prefill showed one folded opening summary, populated tags, nearby links, and three references.
• PASS: production-path browser QA on http://127.0.0.1:3476/docs/glossary/token showed zero folded opening-summary blocks and no Opening summary label, clearing the earlier shared-renderer blocker.
• NOTE: docs/internal/processes/manual-qa.md was not present in this worktree, so I used the live built app plus route-level browser assertions as the manual QA fallback.

No blocking issues remain. This PR is ready to merge.