Motir

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

The registry card makes motir-core read its legal documents from configuration, and the hosted deployment has none. Until somebody sets it, app.motir.co records no acceptances at sign-up and holds nobody at /re-consent — silently, because every empty-set arm in that path is a deliberate, documented []. This card is what closes that window, and the deletion card is blocked_by it so the fallback is not removed before the replacement exists.

⚠️ RE-SCOPED 2026-09-01 — this card SETS the manifest; CONFIRMING the gate is live left

Step 5 and its criteria moved to the live-gate confirmation, the first card of the deletion story. Steps 1–4 stay here, and so does this card.

The discriminator is what each half READS. Setting a value and reading it back with fly secrets list reads the PLATFORM, needs no merge, and is inert: an environment variable nothing consumes yet changes nothing. Confirming the gate holds a person reads the DEPLOYED APPLICATION, and that deployment is what MOTIR-3909's own merge produces — so a card asserting it cannot sit inside MOTIR-3909, where completing the container would cascade done onto it, green and unperformed (plan-rules/core.md gate 14(c)/(d); plan-rules/kind-container.md).

Why this half stays here rather than travelling with the other one. This card is what makes MOTIR-3909 inert on arrival. Its pull request does not open until this card is done (run.md's parent-run step 6 — a manual child un-landed keeps the parent PR shut), so the manifest is already set when the reader deploys. Move it downstream and the story merges into a window in which app.motir.co reads an unset manifest, records no acceptances at sign-up and holds nobody at /re-consent — silently, for however long it takes somebody to run one command.

This card is now dischargeable BEFORE anything merges, which is the point: nothing in steps 1–4 waits on a pull request.

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

Everything below about the deployment's CURRENT state is a claim nobody can verify from the repository (plan-rules/type-manual.md). It is EXPECTED that motir-core is deployed as a Fly application and that its configuration is set with fly secrets, because docs/decisions/application-hosting.md records the Fly shape and the repository's own tooling talks to fly. Step 1 is to check that, and a verified-no-change exit is a legitimate outcome of this card.

The steps

1. CHECK the premise. fly apps list, then fly secrets list -a <the motir-core app> — confirm the application, confirm the configuration mechanism, and confirm the manifest variable is currently ABSENT. If any of that is not as described, stop and report rather than improvising: what this card sets is what decides whether a legal gate runs.
2. Compose the manifest for the moooon cloud deployment, per the shape the decision card records. Seven entries, with slug, title, version, effectiveDate and url taken from the documents as they stand in motir-marketing — not from memory, and not from motir-core, whose copies are about to be deleted.
   • The version values must match the published documents EXACTLY. A version that is behind what is published makes the gate ask nobody; one that is ahead holds every signed-in person at /re-consent. Copy them from the files.
   • The url values must RESOLVE. The render card sits in MOTIR-3932, which this whole story is blocked_by, so it is done before this card starts and motir.co/legal/<slug> exists for all seven — open each one before pasting it in.
3. Set it, and know that set is not live: fly secrets set triggers a rolling update, --stage defers it to the next deploy. Do not use --stage here, or deploy afterwards and say so on the card.
4. READ IT BACK FROM THE PLATFORM. fly secrets list -a <app> for the variable's presence and digest, and the deployment's own health or release surface for the release that carries it. A fly.toml in the repository is a claim about the deployment, not a reading of it — the readback is the evidence.
5. Confirm the gate is LIVE, not merely configured… MOVED 2026-09-01 to the live-gate confirmation, which reads the deployed application after MOTIR-3909 has merged and deployed. It is kept struck rather than deleted because a reader meeting this card mid-run needs to know the confirmation is owed by somebody, not dropped.

Boundary

• It writes no code and opens no pull request.
• It does not publish the documents. The render card does, in MOTIR-3932, and this card only points at what it published.
• It does not touch a self-hosted deployment. Unconfigured is the correct state for one.
• It does not decide the manifest's SHAPE — the decision card does; this supplies the values.
• It does not CONFIRM the gate is live. the live-gate confirmation does, in the deletion story, after MOTIR-3909 has deployed. This card sets the value and evidences it from the platform; nobody can observe it being READ until the reader is running.

Acceptance criteria

• Step 1's readings are pasted on the card: the application name, the configuration mechanism, and the confirmation that the manifest variable was absent beforehand.
• The manifest carries all seven documents, and each version is quoted on the card beside the version in the corresponding file in motir-marketing, showing them equal.
• Each of the seven url values was opened and returned the document — recorded on the card, one line each.
• The value is set WITHOUT --stage, or a deploy follows and is named.
• A platform readback is pasted on the card — fly secrets list -a <app> showing the variable, and the release that carries it — not a screenshot of a config file and not a repository path.
• A signed-in page load on app.motir.co is confirmed not held, and a fresh sign-up is confirmed to record an acceptance. MOVED to the live-gate confirmation (2026-09-01) — it reads the deployed application, which this card cannot.
• This card is done BEFORE MOTIR-3909's pull request opens. That is what makes the story inert on arrival, and run.md's parent-run step 6 enforces it: the parent PR does not open while a manual child is un-landed.
• If the premise in step 1 turned out to be wrong, 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/docs/decisions/application-hosting.md — the Fly shape this card's premise comes from
• motir-core/lib/legal/documents.ts — the reader whose input this is, after the registry card
• motir-core/lib/legal/reconsentGate.ts — isMotirCloud(); this deployment is the one where the gate runs
• motir-core/lib/services/legalAcceptanceService.ts — what an empty manifest makes into a no-op
• motir-marketing/content/legal/ — where the seven version values and seven URLs are read from
• the decision card — the manifest's shape
• the render card — publishes the URLs this points at, in MOTIR-3932; ordered against by the story edge, not a leaf edge
• the live-gate confirmation — the other half of this card, in the deletion story; it confirms the value set here is what the running application reads
• the deletion card, re-filed into the deletion story on 2026-09-01 — it is now blocked_by the live-gate confirmation rather than by this card, so the fallback outlives the DOUBT and not merely the setting

Advisory dispositions

• The remaining reference advisories name cards this one's Boundary excludes. A boundary exists to say a deliverable is somebody else's, and naming the owner is what makes the exclusion checkable — so the reference is deliberate and no edge is owed.