The site manifest now holds its two whole-file page sources to a closed allowlist of the documentation and site-source roots, on the stated ground that a denylist of the git directory and the environment file leaves the gitignored local tier, the private record and every file a future contributor adds still reachable. The quote-type path fields did not get that treatment: identity.file, ui_strings, the deferred feature quote paths, the contributors policy file and the unresolved-reference baseline each pass the relative-path check and then only the git-directory refusal, so a committed manifest naming a dotenv file or a path under the gitignored local tier loads without complaint. The policy file is the one that renders: when its part is anything other than first-bullet, policyQuote renders the ENTIRE matched section of the named file, not one bullet, into the published contributors page, so a manifest pointing it at a local scratch file with a matching heading publishes that file verbatim to the public site. Verified by reading the five call sites and policyQuote. It matters because the manifest travels with a clone and the site is public, so the weaker gate is the one an unreviewed manifest edit reaches first, and the closed set was adopted next door precisely because a denylist cannot anticipate the next reachable file. Fix direction: put every path field the build reads through the same closed page-root set the whole-file sources use, or state per field why a wider set is safe there. Detector: a manifest whose contributors policy file names a path outside the page roots must be refused at load, while the committed manifest still loads.

The site manifest now holds its two whole-file page sources to a closed allowlist of the documentation and site-source roots, on the stated ground that a denylist of the git directory and the environment file leaves the gitignored local tier, the private record and every file a future contributor adds still reachable. The quote-type path fields did not get that treatment: identity.file, ui_strings, the deferred feature quote paths, the contributors policy file and the unresolved-reference baseline each pass the relative-path check and then only the git-directory refusal, so a committed manifest naming a dotenv file or a path under the gitignored local tier loads without complaint. The policy file is the one that renders: when its part is anything other than first-bullet, policyQuote renders the ENTIRE matched section of the named file, not one bullet, into the published contributors page, so a manifest pointing it at a local scratch file with a matching heading publishes that file verbatim to the public site. Verified by reading the five call sites and policyQuote. It matters because the manifest travels with a clone and the site is public, so the weaker gate is the one an unreviewed manifest edit reaches first, and the closed set was adopted next door precisely because a denylist cannot anticipate the next reachable file. Fix direction: put every path field the build reads through the same closed page-root set the whole-file sources use, or state per field why a wider set is safe there. Detector: a manifest whose contributors policy file names a path outside the page roots must be refused at load, while the committed manifest still loads.

Grounds

• pursued: closing each quote field to a stated set stops an unreviewed manifest edit reaching the gitignored local tier or a repository dotfile; it would be shown wrong by a legitimate composition source that no per-field set can name, which would surface as a manifest the repository cannot express rather than as a silent leak