fact-check git:20261012.687766cA

Immutable. This exact content never changes and is served at /api/v1/blob/9183c021e5c60af4.

---
name: fact-check
description: Re-check stated facts about the App Store, Google Play and app tools against the current official pages, update each fact's status and date, fix broken source links, and report what changed. Works on a project's rules file and docs, or on The Last Mile's own traps and facts (one topic or all of them). Use when the user says "check the facts", "is this still true", "re-verify the traps", "store rules changed", or before a store submission.
---

# Fact check

Facts about stores and tools go stale quietly. This skill re-reads the official page
behind each fact and records what it found, so every status means what it says.

## Pick the target

- **Inside a user's project:** the facts their rules file and docs state about the
  stores and their tools (fees, tester counts, target API levels, review guidelines,
  console steps). Ask which files if it is not obvious. Only check statements that
  claim an outside rule or number; skip the project's own decisions.
- **In The Last Mile repo or a fork:** `skills/ship/references/traps.md` and
  `skills/ship/references/facts.md`. The user may name one topic ("Google Play
  testing", "account deletion") or ask for everything.

List the entries you will check and how many there are before starting.

## Status meanings

Use the same three statuses as the traps reference:

- **Checked YYYY-MM-DD (official page opened and read):** the page was opened today
  and a sentence on it supports the entry.
- **From experience:** it happened to a real app, but no official page states it.
- **Needs a human:** the answer sits behind a console login no automation can read.

In `facts.md` the status lives in the **Last checked** column: a date means Checked,
otherwise write "From experience" or "Needs a human".

## Check each entry

1. **Open the source page.** Fetch the page itself. A search snippet or summary is
   not enough. If the page will not load (blocked, login wall, timeout), use these
   in order and say which one you used:
   - **The Last Mile's saved copy.** A weekly job saves a text copy of every page the
     ship references cite. Read `sources/index.json` in The Last Mile
     (`https://raw.githubusercontent.com/namedtoaster/the-last-mile/main/sources/index.json`,
     or the local clone), find the URL, and read its `file` from the same place.
     GitHub is reachable from cloud sessions by default, so this needs no settings.
     The copy counts as the page opened on its `fetched` date: set **Checked
     <fetched date> (saved copy of the official page)**. If `fetched` is more than a
     month old or the entry has an `error`, say so.
   - Another route to the same page: a different fetch tool, or the page in another
     language on the same official site.
   - A search with results limited to the official domain. That is a lead: an entry
     read only this way is **Not yet checked**, per `CONTRIBUTING.md`.
   If all of these fail, leave the status as it was. If the block comes from the
   session's network rules, name the host in one line at the end of the report, as
   an optional fix; never make the user change settings to get an answer.
2. **Find the supporting sentence.** Quote it word for word in your notes. If the
   entry has no source, search the official docs (Apple, Google, Expo, the tool's own
   site) for one. Blogs, forums and other repos are leads, never sources.
3. **Decide:**
   - The page supports the entry: set **Checked** with today's date.
   - The page contradicts it: write the corrected wording, show the old and new text
     with the quoted sentence, and wait for the user to agree before changing it.
   - No official page states it: keep or set **From experience**.
   - It sits behind a console login: set **Needs a human**, with what to look for.
4. **Fix the link.** If the link is broken or redirects, replace it with the current
   official URL. Point it at the exact rule: use the anchor for the guideline section
   (for example `#5.1.1v`) or the specific help article, not a home page. Open the
   new link to confirm it lands on the rule.

## Hard rules

- Never upgrade a status from memory. Checked needs a page opened today.
- Never set a date on an entry you did not open.
- Do not soften an entry that the page contradicts; correct it or flag it.
- Change only the status, date, link and, once agreed, the wording. Keep each
  entry's shape (see `CONTRIBUTING.md`, "Adding a trap", in The Last Mile).
- Plain words in any wording you write. No long dashes.

## Report

Reply in chat with a short table, one row per entry checked:

| Entry | Old status | New status | What changed |
| --- | --- | --- | --- |
| Testers for a new personal account | Checked 2026-07-02 | Checked 2026-10-11 | Nothing |
| Account deletion in the app | Checked 2026-07-02 | Checked 2026-10-11 | Link now points at the guideline anchor |

Then:

- Proposed rewrites, each with the old text, the new text and the quoted sentence.
- Pages that would not load, and entries marked **Needs a human**, so the user knows
  what is still unconfirmed.
- The edits made, as a list of files.

Keep it short. Rows where nothing changed can be grouped into one line if there are
many.

## When to run it

- **Before a submission:** the ship skill should run this on the traps that apply to
  the release (iOS, Android, or both) before preparing the submission.
- **When a rule seems to have moved:** a rejection names a guideline the traps do not
  match, or the user hears a store rule changed.
- **When a saved copy changes:** the weekly snapshot job
  (`.github/workflows/snapshot-sources.yml`) commits every page whose text changed.
  A changed page means the traps citing it need this check. A full scheduled
  re-check that updates the traps on its own does not exist yet.

## Done when

Every entry in scope has been opened or reported as not loadable, every status and
date in the files matches what was found today, and the user has seen the table.