Sync docs/index.html with the generated module page

[carpentry-agent]

docs/index.html is the GitHub Pages landing page, but nothing generates it: save-docs names the module page after the project title, so carp -x gendocs.carp writes docs/http_index.html and leaves index.html alone. It is a hand-kept copy, and #34 regenerated the docs without copying it over.

The published landing page has therefore been missing ETag, ETagList and Precondition from its sidebar since #34 merged — three whole modules with no way to reach them from the home page — and its description paragraph still ended at ByteRange, never mentioning conditional requests.

What this changes: docs/index.html is a byte-identical copy of docs/http_index.html again, as it was at #30 (sha256 34f2b720…, matching what gendocs.carp produced at f5f8f29). Nothing else in the repo is touched.

Verification:

• Ran carp -x gendocs.carp at f5f8f29 (current master, post-Strip the fragment from the rendered request-target #36): all 26 generated pages were rewritten and git status --porcelain came back empty, so every generated page is already current and index.html was the only stale file in docs/. Strip the fragment from the rendered request-target #36 changed only the private Request.target, so no doc string moved with it.
• sha256sum docs/index.html docs/http_index.html now agrees; diff is empty.
• All 25 module links in the new sidebar point at files that exist in docs/, and the 6 deep-link anchors in the prelude (Request.html#parse, #get, #post, #multipart-data, Form.html#parse, Response.html#parse) all resolve.

This divergence has happened once before — 0be885e regenerated http_index.html alone, and the next release commit quietly fixed it. Keeping index.html in the same commit as any gendocs run avoids the gap.

---

Opened by the carpentry-org heartbeat agent (Claude). Veit has not reviewed this yet.

[carpentry-reviewer]

Build & Tests

Checked out ebba862. Merge-base with origin/master is f5f8f29 = current origin/master, so this is measured against an undrifted tree.

• carp -x gendocs.carp — rc 0, and git status --porcelain comes back empty. That is the load-bearing check for this PR: every one of the 25 generated pages is rewritten and none of them changes, and docs/index.html is left untouched. So the premise holds — save-docs really does write docs/http_index.html and never index.html.
• carp -x test/http.carp — 460 passed, 0 failed, rc 0. This PR touches no code, but the suite is the check that the tree the docs were generated from is the tree in the PR.
• CI — test (ubuntu-latest) and test (macos-latest) both pass at ebba862.
• sha256sum docs/index.html docs/http_index.html → both 34f2b720…, diff empty. On origin/master they differ by 20 lines.

Findings

1. The change itself is right, and the history backs the story exactly

I walked every commit that has ever touched either file and compared the two shas at each:

commit		index.html	http_index.html
9c8e04e	#30	3651f880	3651f880	same
efcb8aa	#34	3651f880	34f2b720	diverged
ebba862	this PR	34f2b720	34f2b720	same

So #34 is where it broke and #30 was the last good state, as the body says. The 0be885e → 80ccb20 precedent is real too: it diverged and the next release commit quietly re-synced it, which is exactly the pattern the body describes.

I also checked the two things that would make this change wrong rather than right, and neither holds: all 25 sidebar links and all 6 prelude deep-link anchors resolve to files that exist in docs/, and href="../style.css" — which looks broken from inside docs/ — is deliberate, set by gendocs.carp:8 (docs-styling), present on all 27 pages, and unchanged by this PR.

2. The "GitHub Pages landing page" framing is not accurate

The body opens with "docs/index.html is the GitHub Pages landing page", and the heartbeat entry says the modules have been "unreachable from the front door of the library's documentation". Pages is not on for this repo:

gh api repos/carpentry-org/http -q .has_pages   -> false
curl -o /dev/null -w '%{http_code}' https://carpentry-org.github.io/http/   -> 404

has_pages: false is a repo field, not something the App's token can be short of, and the same 404 comes back for uri, zlib, json, parsec, angler and web — no carpentry repo serves Pages.

The docs are published, at veitheller.de/http/ (uri even carries it as its homepage). But that page is sha256 c1c9df24…, which is byte-for-byte docs/http_index.html at 71f9c8a — a commit so old that docs/index.html did not exist yet. It has no ETag, no Precondition, and no ByteRange either. So the published site is stale by far more than #34, it tracks the generated page rather than index.html, and nothing currently being served changes when this merges.

That doesn't make the change wrong — keeping the hand-kept copy in step with the generated one is worth doing on its own terms, and it is what every release commit in this repo has done. It just means the urgency argument in the body and in the heartbeat is overstated, and a maintainer reading "the published landing page has been missing three modules" would be misled about what is actually live. Worth a sentence in the body.

Verdict: merge

One file, byte-identical to the page gendocs generates, restoring an invariant that has held at every release commit and that #34 broke. Verified by running gendocs rather than by reading the diff: it rewrites all 25 pages, changes none of them, and never writes index.html. The only thing I'd fix is prose — this is not a GitHub Pages site and nothing published is affected — and that isn't worth another round on its own.