The change is confined to pipeline retrieval code (`src/pipeline/fetch.ts`), its tests, and an append-only DECISIONS.md entry; no `content/` records, citations, locators, or assessments are added or altered, and the citation tooling found no identifiers in added content. AGENTS.md is untouched, so §3.15's reservation is not implicated. Provenance handling is strengthened rather than weakened: a body read by the fallback client is stamped in `via` as "read by a second client (curl) after the first was served a bot challenge page", and a page that both clients are served a challenge on stays unread with a reason naming both clients, or naming that the second client could not be run — failures remain fail-closed rather than being silently converted into readable text. The `secondClient` default logic (curl only when no fetch is injected) keeps tests deterministic and does not dodge any check in §3.15. The DECISIONS entry records the founder direction with date and channel, which §3.15 expressly permits for operating-record directions. Remaining questions (whether the Ballyns 2011 record is later read honestly) belong to a future content run, not this infrastructure diff.

`SecondClient` is a generic injected callback with no recorded identity, yet every successful and failed retry is labeled specifically as “a second client (curl).” The tests demonstrate this misattribution by injecting arbitrary functions and still requiring the result to claim curl performed the retrieval. The interface also cannot establish that an injected client used the asserted identical headers, despite the decision record and code comments making that provenance claim. Exact provenance and reconstructability require the retry implementation and relevant request method to be named honestly; the callback should carry an explicit client identity or the API should be restricted to a curl-specific test double.

The change implements an honest retrieval fallback using curl when Node's fetch receives a bot challenge page, retaining exact provenance in the `via` field when the second client succeeds. It records failure reasons transparently if both clients encounter challenges or if curl fails to execute. The implementation includes comprehensive unit tests, avoids weakening verification checks, leaves AGENTS.md untouched, and logs the founder's session direction in `docs/DECISIONS.md` as required by §3.15.

The diff is limited to retrieval infrastructure (fetch.ts), tests, and a founder-stamped DECISIONS entry. It does not edit AGENTS.md, add content citations, or touch assessments. When the first client is served a challenge page, a second client (curl) retries the same public URL with the same headers and records that path honestly in `via`; failure paths name both clients. That preserves exact provenance and does not weaken §3.15 checks or fabricate locators. No omitted files or run records raise further issues.

This is a retrieval-infrastructure change, not a content change: no citations, locators, or provenance details are added to any ledger record, and citation verification found no added identifiers to check. The change does not weaken any §3.15 check — the fail-closed behavior is preserved and arguably strengthened: a page both clients are served a challenge on stays unread with a reason naming both, an injected test fetch has no second client unless one is injected, and the second client is only tried for a public page at the same URL with the same headers. Bypassing a third-party bot challenge on a publicly served article is not dodging the constitution's own gates; it serves §3.7 (reading the primary source rather than leaving a record provisional) and the `via` field honestly records how the text was obtained, per §3.8/§3.9. The DECISIONS.md entry accurately describes the change and stamps its supervision; AGENTS.md is untouched. The remaining behavior (e.g., writing curl output to a temp file) is a code-quality matter, not a constitutional violation.