The build has phases, so the API has phases

The framework exposes several context types because the build itself has several responsibilities.

That split is intentional. It keeps site code explicit while giving the engine enough structure to track dependencies and produce good diagnostics.

RouteSourceContext

RouteSourceContext exists before rendering.

Use it to answer questions like:

• which routes should exist?

• how many pages should a generated family contain?

• which taxonomies or indexes should be emitted?

This context is only used inside generated_routes(...).

RenderContext

RenderContext exists while rendering one already-known route.

Use it to:

• read collections and entries

• render markdown

• resolve assets

• inspect the route manifest

This context is used by page(...), collection_page(...), and the render half of generated_routes(...).

CollectionValidationContext

CollectionValidationContext exists after collections load and before the build succeeds.

Use it to:

• validate frontmatter semantically

• resolve entry references

• stop the build with source-aware diagnostics before rendering begins

Why not one giant context?

Because the phases are different jobs:

• route generation should not pretend it is rendering

• validation should fail as early as possible

• rendering should not secretly reshape the route set

Keeping those phases separate makes the public API easier to reason about and gives the incremental build system better dependency information.