Source: served_context.md

Generated automatically from the published contract sources.

Source path: served_context.md.

Contract text

The Served Context — One Source, Three Forms

Purpose

This document defines the source for the service-contract forms required by API-L0-09: human documentation, MCP discovery, and the agent-consumable authoring bundle. The indexed Markdown and JSON files remain readable without a running server.

The index is schemas/served_context.json. A test in the platform's suite checks that the indexed files exist and that required schemas are included. This document owns the rules; the index lists the files.

The server derives MCP discovery and skills from the catalog and packages the indexed contracts in its authoring bundle. At the site render (the site render script, which the site publish and npm run site:render run; PLD-L0-69), the reference generator generates the human reference from those sources alongside the narrative manual, and tzdocs checks and renders the combined corpus. Source reproductions and code-derived registration metadata follow MCP-05 and CTX-03; skills follow CTX-04 and API-L0-10, and action payloads are in schemas/action_payloads.json.

Requirements are numbered CTX-nn.

The source

CTX-01 (decided): The one source is the contract set of this folder: each contract's rules in its requirements document, its enumeration or schema in schemas/, and the wire schemas joining at C2. The three served forms are generated from it and authored nowhere else. The index at schemas/served_context.json names what is served: a contract absent from the index is unserved, an index row naming a file that does not exist is a defect, and a schema on disk the index omits is one. The suite refuses both directions, so the index cannot quietly shrink or the source quietly grow past it.

The library's serving is indexed by the library catalog under library_catalog.md's rules (Q-239), and this statement's guarantee extends to it explicitly. A library entry absent from the catalog is unserved, a catalog row naming what does not exist is a defect, and the suite holds both directions there too.

CTX-02 (decided): Static readability is the floor: every indexed source is plain Markdown or JSON, readable from the repository or any copy of it with no server, no build, and no tool beyond a file reader. That floor is C1's exit made permanent rather than met once. The generated forms add addressing, packaging, and rendering; they add no contract content, and any build-registration metadata follows CTX-03, so a tool that reads the raw source early reads the same truth the served forms deliver later.

CTX-03 (decided): The three forms derive contract content from the indexed sources: human documentation renders it, discovery descriptions quote it (MCP-05), and the bundle packages it. No form independently authors contract facts. Correct a missing or incorrect contract fact in its owning source and regenerate the affected forms; correct a generator defect in the generator.

The human reference may also show registration status derived from the production code for the same build. Label it as build metadata, separate from the contract, and verify that it matches the default runtime dispatcher. Registration does not guarantee access for a particular caller or availability of a configured service; state those limits beside the status. Do not infer registration from the presence of a payload schema. This metadata exception does not permit a second authored capability list or additional contract facts.

CTX-04 (decided): The skills are served beside the bundle under the same rule: the set derives from the enumeration of actions — no hand-kept list — and each skill is generated from the capabilities it drives. A skill naming an action the contract lacks therefore fails generation rather than shipping a recipe for a capability that does not exist. Q-144's initial eleven are the seed the derivation is checked against, not a list the server carries.

CTX-05 (decided): Discovery's substance is the index: what a newly connected tool learns exists is what the index serves — the overview first, then the contracts by subject. Discovery therefore requires no prior knowledge of Turn Zero Cloud's vocabulary, because every term a listing uses is defined one indexed read away. The same reads arrive as MCP resources and as the observe tools CTX-07 defines; their catalog, text and visibility share one source.

CTX-06 (decided): The bundle carries the operating disciplines an agent must apply, the schema-evolution discipline first. That discipline comprises schema changes as migration files in the customer's repository, destructive changes flagged as such, the development command set — migrate, reset, seed, status, diff, snapshot — and production changes through the migration action (PLD-L0-56) with the version handshake (SVC-L0-11).

The library-first discipline is the second: before hand-building a capability, the agent lists the library (list_library), reads the candidate entry (read_library_entry), and takes it through the served skill (add-library-entry; update-library for a newer version) into the project's own folder (API-L0-14; SPM-L0-49). This discipline is the serving half of the kit's library-consulting promise (REG-26), followable by an agent connected to this surface alone. Where the agent holds no Turn Zero Blueprint registrar, the skill's kit-free ending is its proof: list_library with the vendored folder's manifest rows as installed (SPM-L0-49), every taken entry answered current (LC-06).

The index names each discipline as a guide entry with the commands it must teach. The served guides now exist and distinguish available commands from planned migration and version-handshake behavior. Evaluation must establish that an agent can successfully follow these guides; the existence of guide text alone does not satisfy that obligation.

CTX-07: Tools-only discovery uses list_context, read_context and read_documentation, observe actions of platform_context recorded and metered by the ordinary dispatcher (MAPI-06). The list_context action answers the visible ordered catalog. Its entries are overview, service_contracts, manifest_schema, bundle, each deduplicated indexed source addressed as source:<relative indexed path>, guides as guide:<subject>, live and grant-listable skills as skill:<name>, each listable action's two wire shapes as payload:<action>, and two documentation entries per tree the connection's account may read. A paged skill's parts follow its entry as skill:<name>:<part>, listed under the same grant filter as the skill and read through read_context as any entry is (MCP-06).

A payload:<action> entry is one JSON document holding the contract version, the shared shapes that action's request and response reference, and the request and response, derived from schemas/action_payloads.json and hand-kept nowhere. A client therefore reads one action's shapes in one page at the configured maximum limit where they fit, and in two where they do not, instead of paging the whole file, the whole-file source row standing beside them. An entry whose shapes run past two pages, as read_platform_status's do, is paged as any long JSON entry is.

The documentation entries are docs:cloud, docs:blueprint and docs:tzdocs for each tree's index, and docs:cloud:full, docs:blueprint:full and docs:tzdocs:full for each tree's whole text (PLD-L0-69). A gated tree's two are listed to a holder of its product profile alone, the predicate ACB-L0-82 owns. Each documentation entry names read_documentation, its tree, its part, and its authentication requirement. The read_context action accepts an exact catalog content identifier, never an arbitrary path or URL. The read_documentation action accepts only those three tree names and, beside a name, or in its place where a page route names the tree or the call carries query, three optional members: part, page, and query.

The part member is index (the default), full, or outline. The outline is the index's page lines in the manifest's order, each followed by one indented line per heading of the page below its title with its anchor. The plane composes the outline from the tree's manifest docs.json (PLD-L0-69; tzdoc:TZD-L0-05), the index's own form untouched. The page member is a route the tree's manifest lists. It is given as the index prints it with or without its trailing slash, or without the base path with or without the slashes around the rest. The home page's route is the base path or /. A page read answers that page's Markdown copy from the served version, so the generated reference is read page by page as the index promises.

Where tree is absent, read_documentation takes the tree from the first segment of the page route when it names one of the three trees, each tree's base path being its name (PLD-L0-69). A page value beginning with the estate's public origin, which a completed answer's page carries (PLD-L0-85; MCP-12), loses it after the length bound has read the value as given, so that page passes in as it is. The call then runs as a call naming that tree runs, so a gated tree and a tree the served version lacks are refused as for a named tree. Its record names the tree read from the route as it names a given one. A call naming neither tree nor a page whose first segment names a tree refuses invalid_request naming the trees the connection may read, its record naming no tree, the bare page marker where a page was given.

A call carrying a query that holds a word and naming no tree is the exception. It is held to the rule that page and query exclude each other and any part but the default, and it searches every tree the connection may read (ACB-L0-82). Its lines stand in score order, ties in the trees' order, cloud, blueprint, then tzdocs, and then in manifest order. It skips a tree whose manifest or a listed page's copy the served version lacks, and refuses context_unavailable only where every tree it searches is so. It answers under docs::search: and the sixteen digits a query's identifier carries, and its record names docs::search, the tree's place empty in both, as a page refused for naming no tree records docs::page.

The query member is a few words, answering the pages whose title, headings, or text hold them. The query, lower-cased, splits on whitespace into words, each matched as a substring, so an error name stays one word. A page's score sums per word three where its title holds the word, two where a heading below its title does, and one where its Markdown copy does. Every page the manifest lists is scored, the generated reference included. A query that is one rule code (MCP-05), upper case, with or without its parentheses, is answered first a line naming the code and saying what a rule code is, then the pages holding the code.

The answer is one Markdown line per matching page in score order, ties in manifest order. Each line is - [title](route): and the page's first line holding any word, trimmed. The answer holds at most search_match_limit pages, and the query at most query_max_length characters; both bounds live in schemas/served_context.json beside the text limits. A query within that bound that holds no word, empty or whitespace alone, is read as if the call had left query out. The answer is an empty text with a total of zero where nothing matches. page and query exclude each other and any part but the default, a call naming two refused invalid_request naming the one to drop. A route the manifest does not list refuses context_not_found with the manifest's form in the detail. A served version lacking the manifest or the page refuses context_unavailable.

Every read requires the same identity as the trees' documentation resources (PLD-L0-69). Every read answers under the same paging, stamps, and response shape as the index, the page and the query each paged within their own text, a page read's first chunk alone adding headings. A signed-in connection naming a gated tree its account may not read is refused as a handler violation, invalid_request, its detail naming the trees that connection may read (ACB-L0-82). The catalog lists two documentation entries per tree and no page, outline, or query. Their identifiers are read_documentation's alone, stamped as any text is: docs:<tree>:outline, docs:<tree>:page:<slug>, the slug empty for the home page, and docs:<tree>:search:<the first sixteen hexadecimal digits of the SHA-256 of the query's lower-cased words joined by one space>.

A page read's first chunk, where more follows, answers headings ahead of text where the page holds a heading of depth 2 or deeper outside a fenced code block. Each entry is one such heading's text and the code-point offset where its line starts in the served copy, in the page's order. A page holding more than 40 such headings lists those of depth 2 alone, and answers no headings where it holds none of that depth. Each offset is a place where a chunk can start, so a read naming it with that chunk's stamp starts at the heading's line. The continuation names query for a passage's words, and headings for a section where the chunk answers them. A later chunk, and a page one answer holds whole, carry no headings.

The headings member lists at most headings_limit entries, the first in the page's order, counted after the fall to depth 2. Each entry's text holds at most heading_max_length code points, a longer text cut on a code-point boundary. Both bounds live in schemas/served_context.json beside the text limits. Where either bound cuts the list, the continuation says the list is cut, in a sentence no longer than the one it replaces, and still names query.

Resources, prompts and readers use the same content readers: a fully reconstructed tool result is the same UTF-8 text. Visibility and authorization are recomputed on every call, including continuation; a prior stamp grants no access. The bundle retains its existing anonymous complete source catalog. A tree the served site version lacks (PLD-L0-69), or a missing indexed file, refuses context_unavailable (503), an unknown or unavailable-to-this-view content identifier refuses context_not_found (404), and a changed continuation refuses context_changed (409). Pagination bounds live in schemas/served_context.json: catalog pages have a fixed positive entry limit; text pages have a positive default and maximum measured in Unicode code points. Requests use a safe nonnegative integer offset, default zero, and an optional SHA-256 stamp; text reads may supply an integer limit from one through the configured maximum.

The read_documentation, read_context, and read_library_entry actions begin and end a chunk where a reader can stop: a line start outside a fenced code block, a block's opening line, or the line start after its close. A block longer than the limit also holds the last line start within the limit of its opening line and of each such place. A line longer than the limit, or a text with no line end, holds a place at each limit's length from its start.

In a JSON entry, a line start inside a member of the first or second depth shorter than half the limit is no such place. A member runs from the start of the line holding its name to the start of the line after the one holding its value's end. Its depth is the number of braces and brackets open around its name. Where members sharing a line would leave more than the limit between two places, the last line start within the limit of the place before is one. A JSON entry is a read_context entry served as application/json, or a read_library_entry file whose path ends .json and whose content is text, that parses as JSON.

A chunk begins at the last such place at or before the offset asked and ends at the last one within the limit past that offset. Chunks followed by next_offset under one limit hold at most the limit, and chunks asked at every multiple of the limit join with no gap or overlap. Each answer's offset names where its text starts, a chunk asked at another offset re-reading less than one limit before it.

HTTP GET normalizes only canonical unsigned decimal query strings; JSON and MCP use integers. Handler violations refuse invalid_request; MCP schema violations retain the protocol’s own error shape. Offset greater than zero requires a stamp. Any supplied stamp must match the complete current visible catalog or rendered text, hashed as UTF-8; an offset past the end refuses. Responses name stamp, offset, total and next_offset (null at the end), beside entries or id, mime_type and text, with headings on a page read's first chunk alone. A read_context or read_documentation answer holding less than the whole text also names continuation, ahead of text and outside it: in words, the characters read and the next offset or the last chunk. The catalog stamp hashes its complete ordered JSON entries; text stamps hash the complete text before paging. IDs are bounded by the configured length and are allowlisted map keys, not input to path resolution.

The page value as given is bounded by the same configured length. The identifier a page or a query answers under is the plane's own composition, no input and not re-bounded. The page's copy is read at the path the manifest's matched entry names and never at one built from the caller's string. Records name as their subject the catalog, the exact content ID, or the documentation tree with its part, its page route (the bare marker docs:<tree>:page for a page refused as invalid), or, for a query, the bare marker docs:<tree>:search. A record never names a query's words, which are the caller's own and are recorded nowhere. Records retain the actual credential and application attribution. No personalized global cache or server-held cursor is introduced.

CTX-08: A served document names the product by its approved public name and holds no repository path. Being served is what makes a document a public surface (azure:AZD-08). Every source the index names, a contract document or a guide, names the product Turn Zero Cloud and never by a code name or an internal product name. Every text file in the closure of a published library entry of any kind does the same. Those text files include a package's documents, its compiled modules, and the declarations beside them, a system vocabulary's documents, sheets, and code, and the library's own requirements documents (LC-04; system:FTR-L0-26; system:FTR-L0-94; system:FTR-L0-101; system:FTR-L0-106).

A file of code in a closure is held as a document is, because a consumer's agent learns a package from the comments and declarations of the copy vendored into the consumer's own project. A font's binary files and an image are not text and are outside this statement.

A source the index names holds no path into the repository that produced it. A path to a document the platform serves is written as that document's served title. A path to a document the platform does not serve is written as a plain description of what that document states. A path to a test, a script, a source file, a build output, an infrastructure file, an example, or a plan is dropped, because a customer holds none of them. A wire path, a path in the customer's own project, a path inside a published entry's own closure, and a member of the index itself are not repository paths.

For a published entry's own documents the no-path rule is system:FTR-L0-93's, with a Sources section exempt as history. A comment in an entry's code holds no repository path on any line, and names a module of the platform by what it is, without an address. The documentation suite, the served-surface suite, and the library project's suite hold each served kind to this statement; the identifier half of the public-name rule is MCP-05's, under which a detail may close on a rule code.

This list covers simple inline Markdown links. It does not resolve reference-style links or bare requirement identifiers. The exact source below preserves those references.

  • route — not published as a source in this reference.

Exact source Markdown

---
document: served_context
prefix: CTX
---

# The Served Context — One Source, Three Forms

## Purpose

This document defines the source for the service-contract forms required by API-L0-09: human documentation, MCP discovery, and the agent-consumable authoring bundle. The indexed Markdown and JSON files remain readable without a running server.

The index is `schemas/served_context.json`. A test in the platform's suite checks that the indexed files exist and that required schemas are included. This document owns the rules; the index lists the files.

The server derives MCP discovery and skills from the catalog and packages the indexed contracts in its authoring bundle. At the site render (the site render script, which the site publish and `npm run site:render` run; PLD-L0-69), the reference generator generates the human reference from those sources alongside the narrative manual, and tzdocs checks and renders the combined corpus. Source reproductions and code-derived registration metadata follow MCP-05 and CTX-03; skills follow CTX-04 and API-L0-10, and action payloads are in `schemas/action_payloads.json`.

Requirements are numbered CTX-nn.

## The source

CTX-01 (decided): The one source is the contract set of this folder: each contract's rules in its requirements document, its enumeration or schema in `schemas/`, and the wire schemas joining at C2. The three served forms are generated from it and authored nowhere else. The index at `schemas/served_context.json` names what is served: a contract absent from the index is unserved, an index row naming a file that does not exist is a defect, and a schema on disk the index omits is one. The suite refuses both directions, so the index cannot quietly shrink or the source quietly grow past it.

The library's serving is indexed by the library catalog under `library_catalog.md`'s rules (Q-239), and this statement's guarantee extends to it explicitly. A library entry absent from the catalog is unserved, a catalog row naming what does not exist is a defect, and the suite holds both directions there too.

CTX-02 (decided): Static readability is the floor: every indexed source is plain Markdown or JSON, readable from the repository or any copy of it with no server, no build, and no tool beyond a file reader. That floor is C1's exit made permanent rather than met once. The generated forms add addressing, packaging, and rendering; they add no contract content, and any build-registration metadata follows CTX-03, so a tool that reads the raw source early reads the same truth the served forms deliver later.

CTX-03 (decided): The three forms derive contract content from the indexed sources: human documentation renders it, discovery descriptions quote it (MCP-05), and the bundle packages it. No form independently authors contract facts. Correct a missing or incorrect contract fact in its owning source and regenerate the affected forms; correct a generator defect in the generator.

The human reference may also show registration status derived from the production code for the same build. Label it as build metadata, separate from the contract, and verify that it matches the default runtime dispatcher. Registration does not guarantee access for a particular caller or availability of a configured service; state those limits beside the status. Do not infer registration from the presence of a payload schema. This metadata exception does not permit a second authored capability list or additional contract facts.

CTX-04 (decided): The skills are served beside the bundle under the same rule: the set derives from the enumeration of actions — no hand-kept list — and each skill is generated from the capabilities it drives. A skill naming an action the contract lacks therefore fails generation rather than shipping a recipe for a capability that does not exist. Q-144's initial eleven are the seed the derivation is checked against, not a list the server carries.

CTX-05 (decided): Discovery's substance is the index: what a newly connected tool learns exists is what the index serves — the overview first, then the contracts by subject. Discovery therefore requires no prior knowledge of Turn Zero Cloud's vocabulary, because every term a listing uses is defined one indexed read away. The same reads arrive as MCP resources and as the observe tools CTX-07 defines; their catalog, text and visibility share one source.

CTX-06 (decided): The bundle carries the operating disciplines an agent must apply, the schema-evolution discipline first. That discipline comprises schema changes as migration files in the customer's repository, destructive changes flagged as such, the development command set — migrate, reset, seed, status, diff, snapshot — and production changes through the migration action (PLD-L0-56) with the version handshake (SVC-L0-11).

The library-first discipline is the second: before hand-building a capability, the agent lists the library (`list_library`), reads the candidate entry (`read_library_entry`), and takes it through the served skill (`add-library-entry`; `update-library` for a newer version) into the project's own folder (API-L0-14; SPM-L0-49). This discipline is the serving half of the kit's library-consulting promise (REG-26), followable by an agent connected to this surface alone. Where the agent holds no Turn Zero Blueprint registrar, the skill's kit-free ending is its proof: `list_library` with the vendored folder's manifest rows as `installed` (SPM-L0-49), every taken entry answered `current` (LC-06).

The index names each discipline as a guide entry with the commands it must teach. The served guides now exist and distinguish available commands from planned migration and version-handshake behavior. Evaluation must establish that an agent can successfully follow these guides; the existence of guide text alone does not satisfy that obligation.

CTX-07: Tools-only discovery uses list_context, read_context and read_documentation, observe actions of platform_context recorded and metered by the ordinary dispatcher (MAPI-06). The list_context action answers the visible ordered catalog. Its entries are overview, service_contracts, manifest_schema, bundle, each deduplicated indexed source addressed as source:<relative indexed path>, guides as guide:<subject>, live and grant-listable skills as skill:<name>, each listable action's two wire shapes as payload:<action>, and two documentation entries per tree the connection's account may read. A paged skill's parts follow its entry as skill:<name>:<part>, listed under the same grant filter as the skill and read through read_context as any entry is (MCP-06).

A payload:<action> entry is one JSON document holding the contract version, the shared shapes that action's request and response reference, and the request and response, derived from schemas/action_payloads.json and hand-kept nowhere. A client therefore reads one action's shapes in one page at the configured maximum limit where they fit, and in two where they do not, instead of paging the whole file, the whole-file source row standing beside them. An entry whose shapes run past two pages, as read_platform_status's do, is paged as any long JSON entry is.

The documentation entries are docs:cloud, docs:blueprint and docs:tzdocs for each tree's index, and docs:cloud:full, docs:blueprint:full and docs:tzdocs:full for each tree's whole text (PLD-L0-69). A gated tree's two are listed to a holder of its product profile alone, the predicate ACB-L0-82 owns. Each documentation entry names read_documentation, its tree, its part, and its authentication requirement. The read_context action accepts an exact catalog content identifier, never an arbitrary path or URL. The read_documentation action accepts only those three tree names and, beside a name, or in its place where a `page` route names the tree or the call carries `query`, three optional members: `part`, `page`, and `query`.

The `part` member is `index` (the default), `full`, or `outline`. The outline is the index's page lines in the manifest's order, each followed by one indented line per heading of the page below its title with its anchor. The plane composes the outline from the tree's manifest `docs.json` (PLD-L0-69; tzdoc:TZD-L0-05), the index's own form untouched. The `page` member is a route the tree's manifest lists. It is given as the index prints it with or without its trailing slash, or without the base path with or without the slashes around the rest. The home page's route is the base path or `/`. A `page` read answers that page's Markdown copy from the served version, so the generated reference is read page by page as the index promises.

Where `tree` is absent, read_documentation takes the tree from the first segment of the `page` route when it names one of the three trees, each tree's base path being its name (PLD-L0-69). A `page` value beginning with the estate's public origin, which a completed answer's `page` carries (PLD-L0-85; MCP-12), loses it after the length bound has read the value as given, so that `page` passes in as it is. The call then runs as a call naming that tree runs, so a gated tree and a tree the served version lacks are refused as for a named tree. Its record names the tree read from the route as it names a given one. A call naming neither `tree` nor a `page` whose first segment names a tree refuses invalid_request naming the trees the connection may read, its record naming no tree, the bare page marker where a `page` was given.

A call carrying a `query` that holds a word and naming no tree is the exception. It is held to the rule that `page` and `query` exclude each other and any `part` but the default, and it searches every tree the connection may read (ACB-L0-82). Its lines stand in score order, ties in the trees' order, cloud, blueprint, then tzdocs, and then in manifest order. It skips a tree whose manifest or a listed page's copy the served version lacks, and refuses context_unavailable only where every tree it searches is so. It answers under docs::search: and the sixteen digits a query's identifier carries, and its record names docs::search, the tree's place empty in both, as a page refused for naming no tree records docs::page.

The `query` member is a few words, answering the pages whose title, headings, or text hold them. The query, lower-cased, splits on whitespace into words, each matched as a substring, so an error name stays one word. A page's score sums per word three where its title holds the word, two where a heading below its title does, and one where its Markdown copy does. Every page the manifest lists is scored, the generated reference included. A query that is one rule code (MCP-05), upper case, with or without its parentheses, is answered first a line naming the code and saying what a rule code is, then the pages holding the code.

The answer is one Markdown line per matching page in score order, ties in manifest order. Each line is `- [title](route): ` and the page's first line holding any word, trimmed. The answer holds at most `search_match_limit` pages, and the query at most `query_max_length` characters; both bounds live in schemas/served_context.json beside the text limits. A query within that bound that holds no word, empty or whitespace alone, is read as if the call had left `query` out. The answer is an empty text with a total of zero where nothing matches. `page` and `query` exclude each other and any `part` but the default, a call naming two refused invalid_request naming the one to drop. A route the manifest does not list refuses context_not_found with the manifest's form in the detail. A served version lacking the manifest or the page refuses context_unavailable.

Every read requires the same identity as the trees' documentation resources (PLD-L0-69). Every read answers under the same paging, stamps, and response shape as the index, the page and the query each paged within their own text, a `page` read's first chunk alone adding `headings`. A signed-in connection naming a gated tree its account may not read is refused as a handler violation, invalid_request, its detail naming the trees that connection may read (ACB-L0-82). The catalog lists two documentation entries per tree and no page, outline, or query. Their identifiers are read_documentation's alone, stamped as any text is: docs:<tree>:outline, docs:<tree>:page:<slug>, the slug empty for the home page, and docs:<tree>:search:<the first sixteen hexadecimal digits of the SHA-256 of the query's lower-cased words joined by one space>.

A `page` read's first chunk, where more follows, answers `headings` ahead of `text` where the page holds a heading of depth 2 or deeper outside a fenced code block. Each entry is one such heading's text and the code-point offset where its line starts in the served copy, in the page's order. A page holding more than 40 such headings lists those of depth 2 alone, and answers no `headings` where it holds none of that depth. Each offset is a place where a chunk can start, so a read naming it with that chunk's stamp starts at the heading's line. The continuation names `query` for a passage's words, and `headings` for a section where the chunk answers them. A later chunk, and a page one answer holds whole, carry no `headings`.

The `headings` member lists at most `headings_limit` entries, the first in the page's order, counted after the fall to depth 2. Each entry's text holds at most `heading_max_length` code points, a longer text cut on a code-point boundary. Both bounds live in schemas/served_context.json beside the text limits. Where either bound cuts the list, the continuation says the list is cut, in a sentence no longer than the one it replaces, and still names `query`.

Resources, prompts and readers use the same content readers: a fully reconstructed tool result is the same UTF-8 text. Visibility and authorization are recomputed on every call, including continuation; a prior stamp grants no access. The bundle retains its existing anonymous complete source catalog. A tree the served site version lacks (PLD-L0-69), or a missing indexed file, refuses context_unavailable (503), an unknown or unavailable-to-this-view content identifier refuses context_not_found (404), and a changed continuation refuses context_changed (409). Pagination bounds live in schemas/served_context.json: catalog pages have a fixed positive entry limit; text pages have a positive default and maximum measured in Unicode code points. Requests use a safe nonnegative integer offset, default zero, and an optional SHA-256 stamp; text reads may supply an integer limit from one through the configured maximum.

The read_documentation, read_context, and read_library_entry actions begin and end a chunk where a reader can stop: a line start outside a fenced code block, a block's opening line, or the line start after its close. A block longer than the limit also holds the last line start within the limit of its opening line and of each such place. A line longer than the limit, or a text with no line end, holds a place at each limit's length from its start.

In a JSON entry, a line start inside a member of the first or second depth shorter than half the limit is no such place. A member runs from the start of the line holding its name to the start of the line after the one holding its value's end. Its depth is the number of braces and brackets open around its name. Where members sharing a line would leave more than the limit between two places, the last line start within the limit of the place before is one. A JSON entry is a read_context entry served as application/json, or a read_library_entry file whose path ends .json and whose content is text, that parses as JSON.

A chunk begins at the last such place at or before the offset asked and ends at the last one within the limit past that offset. Chunks followed by next_offset under one limit hold at most the limit, and chunks asked at every multiple of the limit join with no gap or overlap. Each answer's offset names where its text starts, a chunk asked at another offset re-reading less than one limit before it.

HTTP GET normalizes only canonical unsigned decimal query strings; JSON and MCP use integers. Handler violations refuse invalid_request; MCP schema violations retain the protocol’s own error shape. Offset greater than zero requires a stamp. Any supplied stamp must match the complete current visible catalog or rendered text, hashed as UTF-8; an offset past the end refuses. Responses name stamp, offset, total and next_offset (null at the end), beside entries or id, mime_type and text, with `headings` on a `page` read's first chunk alone. A read_context or read_documentation answer holding less than the whole text also names continuation, ahead of text and outside it: in words, the characters read and the next offset or the last chunk. The catalog stamp hashes its complete ordered JSON entries; text stamps hash the complete text before paging. IDs are bounded by the configured length and are allowlisted map keys, not input to path resolution.

The `page` value as given is bounded by the same configured length. The identifier a page or a query answers under is the plane's own composition, no input and not re-bounded. The page's copy is read at the path the manifest's matched entry names and never at one built from the caller's string. Records name as their subject the catalog, the exact content ID, or the documentation tree with its part, its page route (the bare marker docs:<tree>:page for a page refused as invalid), or, for a query, the bare marker docs:<tree>:search. A record never names a query's words, which are the caller's own and are recorded nowhere. Records retain the actual credential and application attribution. No personalized global cache or server-held cursor is introduced.

CTX-08: **A served document names the product by its approved public name and holds no repository path.** Being served is what makes a document a public surface (azure:AZD-08). Every source the index names, a contract document or a guide, names the product Turn Zero Cloud and never by a code name or an internal product name. Every text file in the closure of a published library entry of any kind does the same. Those text files include a package's documents, its compiled modules, and the declarations beside them, a system vocabulary's documents, sheets, and code, and the library's own requirements documents (LC-04; system:FTR-L0-26; system:FTR-L0-94; system:FTR-L0-101; system:FTR-L0-106).

A file of code in a closure is held as a document is, because a consumer's agent learns a package from the comments and declarations of the copy vendored into the consumer's own project. A font's binary files and an image are not text and are outside this statement.

A source the index names holds no path into the repository that produced it. A path to a document the platform serves is written as that document's served title. A path to a document the platform does not serve is written as a plain description of what that document states. A path to a test, a script, a source file, a build output, an infrastructure file, an example, or a plan is dropped, because a customer holds none of them. A wire path, a path in the customer's own project, a path inside a published entry's own closure, and a member of the index itself are not repository paths.

For a published entry's own documents the no-path rule is system:FTR-L0-93's, with a Sources section exempt as history. A comment in an entry's code holds no repository path on any line, and names a module of the platform by what it is, without an address. The documentation suite, the served-surface suite, and the library project's suite hold each served kind to this statement; the identifier half of the public-name rule is MCP-05's, under which a detail may close on a rule code.