<?xml version="1.0" encoding="UTF-8"?>
<!--
  Sobre's sitemap INDEX. It names files; it never names pages.

  This is the address in robots.txt and the one submitted to Search Console, so
  it is the only sitemap URL anybody outside this repo should have to know.

  ⚠️ AN INDEX AND A URLSET CANNOT BE MIXED IN ONE DOCUMENT, WHICH IS WHY THE
  SEVEN STATIC PAGES MOVED OUT. <sitemapindex> takes <sitemap> children and
  <urlset> takes <url> children; there is no document that is both. Until
  2026-09-02 this file WAS the urlset, and the seven pages now live in
  sitemap-pages.xml unchanged. Adding a <url> back here does not extend the
  index — it invalidates it, and a crawler drops the whole file rather than the
  offending entry.

  THE TWO HALVES HAVE DIFFERENT WRITERS, AND THAT IS THE WHOLE REASON THERE ARE
  TWO. sitemap-pages.xml is hand-maintained here and shipped by the deleting
  `aws s3 sync dist/`. sitemap-blog.xml is written to the same bucket by the
  backend when a post publishes, on a schedule this repo does not control.
  One key with two writers is a race the deploy always wins and never reports:
  the sync would overwrite the blog's URLs with the static seven, succeed, and
  say nothing. Both deploy workflows exclude `blog/*` and `sitemap-blog.xml`
  from that deletion for exactly that reason; the excludes landed before the
  feature.

  ⚠️ THE SYNC'S DELETE FLAG IS DESCRIBED HERE AND NEVER SPELLED, AND THAT IS NOT
  A STYLE CHOICE. Its two leading hyphens are a double hyphen, XML forbids one
  inside a comment, and there is no escape for it — an entity is not expanded in
  comment text, so the only legal way to write the flag is not to. Search Console
  read this file as a PARSING ERROR with zero discovered pages until 2026-09-03
  for exactly that reason, and a parser rejects the whole document rather than
  the comment. Restoring the literal flag re-breaks every URL below it.
  `src/sitemapXml.test.ts` fails on it before a deploy can.

  ⚠️ sitemap-blog.xml IS NOT SHIPPED BY THIS REPO, AND IT DOES NOT 404 — IT
  ANSWERS 200 WITH THE APP SHELL. This paragraph said "WILL 404" until
  2026-09-03 and that was never true on this distribution. The bucket is private
  behind an OAC so an absent key is a 403, and a distribution-wide custom error
  response rewrites that to /index.html at 200. robots.txt in this same directory
  has said so all along, naming 207-Prod-ForgeBudget-Web-S3-CloudFront.tf.

  The difference is not pedantic. A 404 child is a child Search Console reports
  as unreachable and moves past; an HTML child is a child it reports as a PARSING
  ERROR, which is the same words it uses for a malformed index and sends the next
  reader to the wrong file. Fixing it is a CloudFront change in
  erp/terraform-jomietech-base, tracked in the orchestrator's docs/TODO.md, and
  the ordering is: the behaviour, then the backend publishes, then this entry
  starts resolving.

  Do NOT "fix" it here by deleting the entry — the next publish would then be
  invisible, which is the failure this index exists to prevent.

  NO <lastmod>, for the reason sitemap-pages.xml gives at length: a date nobody
  maintains is worse than an absent one, because it tells a crawler the file is
  fresh and stops being believed the first time it is wrong. The blog's own
  entries carry real dates, written by the process that knows them.

  THE APEX, NEVER www. Both sobre.ph and www.sobre.ph serve this app, so the two
  are duplicates by construction and the apex is the canonical form here, in the
  runtime <link rel="canonical">, and in the marketing copy.
-->
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <!-- The seven hand-maintained pages: what the product is, where to sign up,
       the two legal documents, account deletion, contact, and where to install. -->
  <sitemap>
    <loc>https://sobre.ph/sitemap-pages.xml</loc>
  </sitemap>

  <!-- Every published article, in every language it was actually written in.
       Generated by the backend; see BlogSitemap.java. -->
  <sitemap>
    <loc>https://sobre.ph/sitemap-blog.xml</loc>
  </sitemap>
</sitemapindex>
