ADR 0309: Repository question files are governed content

Status: accepted; extends the merge-base policy authority of ADR 0294

Inline checkpoint questions keep ordinary policy visible in discern.toml, but a substantial rubric can make the table harder to read and maintain. Some projects also keep review prose in a repository document. Treating a question string that happens to end in .md as a path would make short prose ambiguous. Reading the candidate worktree would let a branch rewrite the obligation that judges that same branch.

A file reference also creates a serving problem. A reviewer should not need to leave a refusal, CI result, Proof, or variance decision to discover what the question asked. A repository path can control where prose is authored without becoming a deferred review dependency.

A checkpoint question file is governed repository content. Its path and bytes resolve from the same merge-base Git tree as the table that names it.

• question_file is an explicit source. A project-authored checkpoint sets exactly one of question and question_file. A built-in inherits its shipped question when both are absent and may override it with exactly one. No filename inference exists.
• The path uses the canonical portable project-relative file validator and stays outside .git. The governing reader accepts only a regular Git blob, decodes UTF-8 fatally, retains authored line endings, and admits at most 65,536 bytes. It does not read a filesystem path or follow a symlink.
• Resolution produces one ordinary ResolvedCheckpoint.question. Downstream trigger, open-question, declaration, report, acceptance, and Proof code do not carry a second question type.
• The normalized source path and resolved content enter the definition hash. A candidate edit cannot change its own obligation. A governing path or content change received through discern update reopens the question. An unrelated merge-base move does not.
• Live config loading validates the current tracked file strictly. Historical file or source failures drop the affected checkpoint with typed evidence and do not suppress valid siblings.
• reference is presentation metadata for either source. It is never loaded or executed. Review surfaces show it separately and still include the complete resolved question.
• Repository privacy is the only privacy boundary. Resolved questions and references can appear in terminal output, MCP context, CI logs, Proof, and landing review, so neither may contain secrets.

• A project can keep a long question readable and versioned in Markdown without creating a branch-local self-exemption.
• Review remains self-contained even when authorship moves to a file.
• A source path, blob type, encoding, and byte limit become part of the live authoring contract. Historical violations remain visible as durable fail-open evidence.
• Files outside the repository, URLs as content, environment expansion, encrypted or vault-backed sources, submodules, and remote transports remain unsupported.

• Interpret a Markdown-looking question as a path. Rejected because prose and filenames would share an ambiguous field.
• Read the candidate worktree file. Rejected because the branch could rewrite its own obligation, and filesystem symlinks would widen the authority boundary.
• Render only “see file”. Rejected because CI, Proof, MCP, and landing review would no longer carry the question being judged.
• Load reference content. Rejected because a pointer is useful without creating another content authority or transport contract.