Motir

Type: verification · Executor: human · NO PR — marked done on the user's confirmation, with the readings pasted onto the card.

This card is the FIRST act of this story, and it reads a running application rather than this repository. MOTIR-3909 has merged and deployed; MOTIR-4012 set the legal-document manifest on the moooon cloud deployment before that merge, so the value was already in place when the reader arrived. What nobody has yet observed is that the two met — that the deployed lib/legal/documents.ts reads that manifest, and that the re-consent gate holds a person over it.

⚠️ Why this is not MOTIR-4012's step 5, and why it is not inside MOTIR-3909

MOTIR-4012 sets a value and reads it back from the PLATFORM (fly secrets list). That needs no merge: an environment variable is inert until something reads it, so setting it before the reader deploys is exactly right and is what makes MOTIR-3909 inert on arrival.

Confirming the gate is LIVE is a different reading, of a different system, at a different time. It reads the deployed APPLICATION, and the deployment is what MOTIR-3909's own merge produces. A card asserting it cannot sit inside MOTIR-3909: completing a container cascades done onto every child, so that merge would close this card without anybody performing it — green, unverified, and indistinguishable from a card someone ran (plan-rules/core.md gate 14(c)/(d); plan-rules/kind-container.md).

⚠️ Written as a HYPOTHESIS, because this card's subject is out of the agent's reach

Everything below about the deployment's state is a claim nobody can verify from the repository (plan-rules/type-manual.md). A verified-no-change exit is a legitimate outcome: if the readings differ from what this card expects, STOP, write up the deviation, and name the sibling cards that assumed it — do not improvise around it. What this card observes is what decides whether the deletion card is safe to run.

The steps

1. Confirm the release carries the manifest reader. Read the deployment's own release surface for the release built from the commit that merged MOTIR-3909, and fly secrets list -a <the motir-core app> for the manifest variable's presence and digest. A fly.toml in the repository is a claim about the deployment, not a reading of it. Both readings are pasted on the card.
2. Confirm the manifest is what the application is READING, not merely what the platform holds. If the deployment offers a health, preflight or diagnostic surface that reports on legal configuration, read it and paste it — and treat a not applicable on a cloud deployment as a red flag rather than a pass, since that arm exists for self-hosted builds.
3. Drive the hold. Sign in on app.motir.co as a reader whose accepted version is materially behind the manifest's, and confirm: you are held at /re-consent; each outstanding row links to the configured motir.co/legal/<slug> URL and that URL returns the document; Agree and continue returns you to where you were going; and a second page load is not held.
4. Drive the un-held case. Sign in as a reader who is up to date and confirm a signed-in page load is not held. An always-held gate and a never-held gate fail differently and both are wrong.
5. Confirm a fresh sign-up records an acceptance. Sign up a new account and confirm acceptance rows were written, and that their versions equal the manifest's — not merely that rows exist. Zero rows is the exact silent failure this whole story is about: recordAcceptance carries an explicit "NO EMPTY-SET GUARD HERE, DELIBERATELY", so an unread manifest writes nothing and throws nothing.
6. Open each of the seven configured URLs and confirm the document renders on the brand host, one line each on the card.

Boundary

• It writes no code and opens no pull request.
• It does not SET the manifest. MOTIR-4012 did, inside MOTIR-3909, before that story merged. If this card finds the variable absent, that is a deviation to report — not a value to set here.
• It does not delete anything. The deletion card is blocked_by this one, so the fallback outlives the doubt.
• It does not touch a self-hosted deployment. Unconfigured is the correct state for one, and this card says nothing about it.

Acceptance criteria

• The release carrying the manifest reader is named on the card, read from the deployment's own release surface, and fly secrets list -a <app> output showing the manifest variable is pasted beside it.
• A signed-in reader materially behind was HELD at /re-consent, and the card records: the row set, each row's href, that Agree and continue returned the reader to their destination, and that the next load was not held.
• A reader who is up to date was NOT held, recorded separately — so the card evidences both directions of the gate rather than only the one that fires.
• A fresh sign-up recorded acceptance rows, and their versions are quoted against the manifest's, shown equal. A row count alone does not discharge this.
• Each of the seven configured URLs was opened and returned its document — one line each.
• Every reading above is pasted on this card as OUTPUT, not summarised: the evidence is what the deletion card is waiting on.
• If any reading differed from this card's premise, the card closes as verified-no-change with what was found instead, and the sibling cards that assumed it are named.

Context refs

• motir-core/lib/legal/documents.ts — the manifest reader whose deployed behaviour this observes
• motir-core/lib/legal/consent.ts — RECONSENT_DOCUMENT_SLUGS and the materiality rule the hold implements
• motir-core/lib/legal/reconsentGate.ts — isMotirCloud(); this deployment is the one where the gate runs
• motir-core/lib/services/legalAcceptanceService.ts — recordAcceptance's deliberate empty-set arm, which is what makes the failure silent
• motir-core/docs/decisions/application-hosting.md — the Fly shape this card's premise comes from
• MOTIR-4012 — set the value this card confirms is being read; ordered against by the story edge, not a leaf edge
• MOTIR-4007 — the reader whose deployed behaviour this observes; ordered against by the story edge

Advisory dispositions

• Any reference advisory naming MOTIR-4012 or MOTIR-4007: NOT an owed leaf edge. Both sit in MOTIR-3909, and this story is blocked_by that story — readiness.blockedByAncestor holds every leaf here until it is done, so a leaf edge would be a cross-parent edge that core.md gate 7 forbids and that buys nothing (plan-rules/phase-skeleton.md, never reach across a parent to sequence).
• This card's real precondition is not a work item at all — it is a DEPLOY of MOTIR-3909's merge. core.md gate 14(d) says to name that in the card's own words rather than lean on the ready set, and step 1 is where it is named: the earliest legal start is when the release built from MOTIR-3909's merge commit is running.