feat(docs): point a lost agent somewhere useful from the 404 - #12599
Open
jd wants to merge 7 commits into
Open
Conversation
This was referenced Aug 28, 2026
Member
Author
|
This pull request is part of a Mergify stack:
|
Contributor
Merge Protections🟠 1 of 6 protections blocking · waiting on 🤖 CI
🟠 🤖 Continuous IntegrationWaiting for
Waiting checks:
|
jd
force-pushed
the
devs/jd/agentic-readiness/point-lost-agent-somewhere-useful-404--bb77d582
branch
from
August 28, 2026 13:33
4e0375e to
af4b8b8
Compare
Member
Author
Revision history
|
There was a problem hiding this comment.
Pull request overview
Improves the 404 page to provide “next steps” for automated agents (and humans) by adding a small, machine-readable recovery navigation section alongside the existing search and home link.
Changes:
- Add a “Where to look next” recovery
<nav>with links to index,llms.txt, sitemap, API reference, and OpenAPI. - Add scoped CSS styles for the recovery section on the 404 page.
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
jd
force-pushed
the
devs/jd/agentic-readiness/point-lost-agent-somewhere-useful-404--bb77d582
branch
from
August 28, 2026 13:38
af4b8b8 to
12b683f
Compare
jd
marked this pull request as ready for review
August 28, 2026 14:09
jd
force-pushed
the
devs/jd/agentic-readiness/point-lost-agent-somewhere-useful-404--bb77d582
branch
from
August 28, 2026 14:37
12b683f to
26f0c28
Compare
`getOgImageUrl` strips the leading and trailing slashes off the pathname to build the image filename. For the homepage that pathname is `/`, so stripping left an empty string and the lookup missed — every docs page had an OpenGraph image and the homepage shipped `<meta property="og:image">` with no content. The homepage's collection id is `index`, which is what `getStaticPaths` names its image, so fall back to that when the slug comes out empty. Covered by a regression test that fails against the old expression. The generated-image set comes from the content collection and needs the Astro build pipeline, so the test stubs it and exercises the derivation, which is the half that was wrong. Change-Id: Ifb9a23ea2caa20d28489a4f21363d85ed5e3342c
Docset cards rendered their title as `h4`. Almost every grid sits directly under an `##`, so the outline jumped h2 to h4 — including on the homepage, whose whole body is the "Products" grid. Screen readers and anything parsing the document outline read that as a missing level. Default the card heading to `h3` and make it a prop, because one grid does belong at h4: the "Components" grid in `ci-insights.mdx` is nested under an `### Components`, where h3 would make the cards siblings of their own section heading instead of children. Change-Id: Ie01f4c2b03f1f2b7f798ae89b056135a5b00800e
The Mergify OpenAPI 3.1 document is already deployed — it is what the API Reference pages are generated from — but only at `/api-schemas.json`, a filename that exists nowhere outside this repository. Every OpenAPI client, SDK generator and crawler probes `/openapi.json`, so nothing finds it and the docs read as a site with no API at all. Serve the same bytes at `/openapi.json`. The route does not transform the document: the spec is synced from the engine repository, and two spellings of it that could disagree would be worse than one obscure path. Alongside it, three other entry points that were undiscoverable: - `<link rel="service-desc">` in every page head, the IANA relation for "the description of this site's API" (RFC 8631), plus one for `llms.txt`. - `robots.txt` had no `Sitemap:` line, so crawlers had to guess `sitemap-index.xml` rather than be told. - `/developers` is the path people and tools guess for a developer portal and was a 404; it now redirects to the API reference. Change-Id: I1b625f960363c8427d5282c052fee74111bf07fa
Every page already ships its Markdown source at `<path>.md`, which is what the "View as Markdown" button and `llms.txt` link to. But the convention agents reach for first is to request the page's own URL with `Accept: text/markdown` (https://acceptmarkdown.com), and that returned HTML. The site is a static build, so a Cloudflare Pages middleware is the only layer that sees request headers. It rewrites to the `.md` twin when Markdown is asked for, answers 404s in the format that was requested, and merges `Accept` into `Vary` on both variants — without it a CDN would hand whichever variant it cached first to everyone, which is the failure this is most likely to produce in production and the least likely to be noticed. The `Vary` goes on `304` responses too, since those are exactly the ones a cache is about to act on. Markdown is served only when `text/markdown` is named explicitly and not outranked by `text/html`. Browsers send `text/html,...,*/*;q=0.8`, so honouring wildcards would serve raw Markdown to every human visitor; the tests pin the real Chrome and Firefox Accept headers against that. HTML is served as the fallback only on a `404` from the `.md` route, not on anything that is merely not `ok`: `304 Not Modified` is the normal answer to a client revalidating Markdown it already holds, and treating it as a missing page answered it with HTML. Three things about adding a root `_middleware` needed care, all three verified against the real Pages runtime with `wrangler pages dev dist`: Cloudflare documents that `_redirects` are not applied to requests served by Functions, and this repository has 99 of them. `next()` does still route through the asset server, so every redirect, the `_headers` rules, the `.md` routes and the static 404 behave exactly as before. `next()` is called with an explicit request everywhere. A bare `next()` is documented as forwarding the original request, but once the middleware has asked for the Markdown twin the runtime forwards *that* request again — so `/api` and `/cli`, which are built from `src/pages/` and have no `.md`, were answered with the Markdown 404 instead of their own HTML. The test double refuses a call with no request so this cannot come back. A root middleware otherwise turns every request into a Worker invocation, assets included — roughly thirty per page view, none of which can be negotiated. `_routes.json` excludes the bundle, the search index, the OpenGraph images and the static files by name, so only page requests reach the Function. Also ignore `.wrangler/` — running the Pages runtime locally drops generated bundles there, and eslint linted them. Change-Id: I52f9d2a1c70248b1406412129a633cc3bee219de
`llms.txt` was a page index and nothing else: an agent could see every URL we publish and still not know whether Mergify was the right tool for the task in front of it, or how to call it. Add two sections above the index. "When to use Mergify" names the jobs concretely — keeping main green, merging at volume without the CI bill, diagnosing CI, flaky tests, merge requirements GitHub cannot express, stacked PRs — and, just as usefully, says what is out of scope. GitHub only, no other code host; GitLab appears solely as a source of CI results. That one line saves an agent from planning an integration that does not exist, which is worth more than another paragraph of capabilities. "For agents" points at the machine-readable surfaces: the `.md` twin of every page and the `Accept: text/markdown` equivalent, the OpenAPI document with its base URL and auth scheme, the sitemap, the `.mergify.yml` JSON Schema, and how to install the CLI. That last one because naming a CLI without an install path leaves an agent exactly where it started; the paths are the Homebrew tap, the install script and the Windows release zip, per /cli/usage. Change-Id: I03f7b473ced0969e850d78b48758e1849535062f
jd
force-pushed
the
devs/jd/agentic-readiness/point-lost-agent-somewhere-useful-404--bb77d582
branch
from
August 28, 2026 15:09
26f0c28 to
db22260
Compare
The docs carried no structured data, so who publishes them, how to contact Mergify and what product they document were all inferable only from prose. Search engines and assistants both use JSON-LD for that entity resolution. Emit one `@graph` per page: an Organization node with the registered address, support and sales contact points and the canonical social profiles; a SoftwareApplication node for the product; and either a WebSite node on the homepage or a TechArticle node for the page itself. The Organization is declared once and referenced by `@id` from the others rather than repeated. Every value is taken from something already published: the footer's social links, the addresses used across the docs, the pricing page. Nothing is asserted that a reader cannot check against a page, which is the whole point of publishing it. `<` is escaped to the JSON unicode escape for it in the serialized graph. Page titles and descriptions come from frontmatter in this repository, so nothing hostile is expected there, but `JSON.stringify` leaves `</script>` intact and inlining it would end the tag early. Change-Id: Idd84bc050695e27d6d8a361538e2ef89da8dd32e
The 404 offered a search box and a link home. That works for a person; an agent that followed a dead link gets a page with nothing machine-readable on it, and a 404 is the one page where it has no other context to work from. Add a short recovery list: the documentation index, `llms.txt`, the sitemap, the API reference and the OpenAPI document — plus a note that appending `.md` to any URL, or sending `Accept: text/markdown`, returns the Markdown source. Useful to a human who mistyped a URL too. Change-Id: Ibb77d5829360bfb5b6ae4b1768362c860f5670d8
jd
force-pushed
the
devs/jd/agentic-readiness/point-lost-agent-somewhere-useful-404--bb77d582
branch
from
August 31, 2026 13:40
db22260 to
2e2b86a
Compare
Base automatically changed from
devs/jd/agentic-readiness/describe-site-schema-org-json-ld--dd84bc05
to
main
September 9, 2026 08:20
kozlek
approved these changes
Sep 9, 2026
AlexandreGaubert
approved these changes
Sep 9, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The 404 offered a search box and a link home. That works for a person; an
agent that followed a dead link gets a page with nothing machine-readable on
it, and a 404 is the one page where it has no other context to work from.
Add a short recovery list: the documentation index,
llms.txt, the sitemap,the API reference and the OpenAPI document — plus a note that appending
.mdto any URL, or sending
Accept: text/markdown, returns the Markdown source.Useful to a human who mistyped a URL too.