<?xml version="1.0" encoding="UTF-8"?>
<!--
  FOUR URLs, and that is the whole site. The landing itself is a single page: the locale switch,
  the waitlist form and the referral link (/?ref=<code>) are all states of it, not separate
  documents, and listing a referral URL here would publish somebody's code to a crawler.

  The other three are the legal documents (F-7 / R-18, 2026-08-27; the talent terms re-versioned
  on 2026-09-05, which is why there are two of them). They are listed because
  robots.txt on this origin says `Allow: /` to everybody: a document that is crawlable and absent
  from the sitemap is a document we have decided to publish and then declined to announce, and the
  privacy notice in particular is the first artefact counsel, an investor checklist, the NPC and
  any ad network ask for. They are STATIC FILES in apps/landing/public/, which Vite copies into
  dist/ verbatim — no transform, no hashing — so the paths below are exactly the paths that ship.

  The talent terms carry their version in their NAME, deliberately. That string is what
  apps/portal/src/talent-register.tsx records into the append-only `consent_events` table for every
  talent who ticks the box, and a consent row has to name a document that was actually shown. A
  replacement publishes under a NEW version string and gets its own <loc> here; the superseded one
  does not move, because the records that name it do not move either.
  apps/landing/test/legal-documents.test.ts pins the file name against the recorded string.

  THAT IS WHY BOTH TALENT-TERMS FILES ARE BELOW. `talent-terms-2026-09.html` is the document the
  form records today (review 2026-09-05, C220: the 2026-08 text said the payout rail was switched
  off, and it has been manual in production since 2026-08-31). `talent-terms-2026-08.html` stays
  listed and stays crawlable — it is the document every consent row written before 2026-09-05
  names, it carries a supersession line pointing at the new one, and delisting it would leave those
  records pointing at a URL a reader cannot find.

  <lastmod> is a claim about the PAGE, not about this file, so it moves when that page changes in
  a way a reader would notice — not on every deploy. A lastmod that is always today is a lastmod
  nobody believes, and Google says so out loud.

  THAT RULE NOW HAS A DETECTOR, because for two revisions it had none: the privacy notice was
  materially rewritten twice under a frozen <lastmod>2026-08-27 and every test in the suite stayed
  green, since the only assertion over this file was that the <loc>s were present (review C156).
  apps/landing/test/legal-documents.test.ts reads each listed DOCUMENT's own version line — the
  `first published … · revised …` serial each one carries, which §11 of the notice requires to move
  when the notice materially changes — and fails when the entry below sits behind it. It reads the
  document rather than git because CI checks out shallow, where every file's "last commit" is HEAD.
  Two things stay outside it, and are the editor's job here: a reader-visible change that does not
  touch a serial line, and `/`, which publishes no version line at all.

  2026-09-07 moved two entries. `/` had stood at its publication date while the landing's copy
  changed underneath it — the barkada panel now states the confirmation the waitlist ranking counts
  (C269), the derby caption no longer offers a live watch (C274), and the scoreboard's provenance
  line no longer claims every prize comes from an advertiser (C271). privacy.html moved with its
  own revision: sections 3.4 and 10 and the Tagalog summary no longer tell a data subject that the
  contact address they are being sent to does not exist (C149).

  NO <changefreq> AND NO <priority>. Google's own sitemap documentation says it ignores both.
  A file that states things nothing reads still has to be kept true by whoever edits it next,
  which is a cost with no buyer.

  The origin is absolute here for the same reason it is in robots.txt — the sitemap protocol
  requires <loc> to be a full URL, and a sitemap's URLs must share the origin it is served from.
  Move this and robots.txt together, or a crawler reads a sitemap that describes another site.
-->
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://lechonliga.com/</loc>
    <lastmod>2026-09-07</lastmod>
  </url>
  <url>
    <loc>https://lechonliga.com/privacy.html</loc>
    <lastmod>2026-09-07</lastmod>
  </url>
  <url>
    <loc>https://lechonliga.com/talent-terms-2026-09.html</loc>
    <lastmod>2026-09-05</lastmod>
  </url>
  <url>
    <loc>https://lechonliga.com/talent-terms-2026-08.html</loc>
    <lastmod>2026-09-05</lastmod>
  </url>
</urlset>
