[argszero]

Closes #2617

What changed

emrg/server/ios_app_prompt.md gains the product method it was missing: seven subsections, each written into the section that already owns its subject, in the template's own voice — no dates, no migration notes, no instance values, no text taken from any installation's configuration.

§	New subsection	What it establishes
1.1	Two gates, and a candidate that fails either is replaced	Selection needs evidence that people pay (what the nearest apps charge, how many ratings they carry) and a structural difference stated in one sentence. Passing the rejection gate is not graduation: an app nobody rejects can still be one nobody pays for. A product that gives a conclusion beats one that reports activity.
3.1	The loop, segment by segment	The product is the four or five segments a user passes through, each marked have or missing. A loop with a missing segment ships a verdict without its result, so the gap outranks every feature and every version number.
3.2	The design is agreed before the code	A static mockup, confirmed screen by screen, precedes implementation and is the acceptance surface. One concept per screen, the user's vocabulary, and the default path is the product — never a questionnaire, a calibration or a sign-in as the way in.
3.3	The order of the screens	Ordered by the order a user uses them, not the order the code is organised in. Content is not hidden behind a switch.
4.1	Gates before features, and each gate is seen red	Write the gate that fails first; a rule only a comment claims is not a rule; watch a gate refuse something before trusting it; a gate that fails open is not a gate.
5.1	Every version ships to the host's hands	Every version goes to TestFlight; the build is opened and looked at before it is reported; one change at a time; a better build does not wait for a review.
5.2	The store page is where a small app is found	At low install volume the store page has one screenshot and one sentence; everything the copy claims is shown by a build that exists; installs are the only hard number.

Nothing was appended at the end of the file and nothing is stated twice: each rule lives under the heading whose subject it is.

Why

A round reading the template end to end was told how to build, test, submit and record, and was told nothing about what to build, in what order to show it, or whether the build ever reached the person who asked. That method existed only in one installation's supplementary task configuration, which is not where general method belongs.

The guard

tests/test_prompt_templates.py::test_the_ios_template_carries_the_product_method_it_was_missing pins position, not just presence — the same shape the promote_prompt.md guard already uses in that file. For each of the seven phrases it asserts the phrase occurs exactly once and occurs inside its own section, so a rule that is deleted, duplicated, or moved to the wrong section reddens.

Direction measured, not assumed: with the committed tree, rewording the TestFlight rule (Every version goes to TestFlight → Every version reaches the host) reddened exactly one test and left 53 passed; restoring from the commit returned 54 passed.

Verification on the pushed tree

• uv run --no-sync pytest tests/ -q — 5968 passed, 36 skipped (253.59 s)
• uv run --no-sync python -c "from emrg.client.app import run_client" — OK
• uv run --no-sync python -m emrg --help — OK
• CI on this head: pending; this reading says nothing about it.

[argszero]

✅ LGTM — read at head 6f61e82 against the issue it closes: the seven rules sit in their own sections with nothing appended and nothing stated twice, and the new test pins position rather than presence (each phrase exactly once, inside its own section), which is what the issue asked for. CI on this head passed both legs (test 3m39s, test-windows 4m48s, run 40661378449) — cycle cyc20261028-171004

[argszero]

✅ LGTM — read on the landing tree 6680de02, because the head no longer carries master (behind_by=1): check-merge-plan-suite.py 2618 passes on that tree with 5969 passed, 37 skipped in 262.96s, and the change itself is what the issue asked for — the seven product rules sit each in its own section with nothing appended at the end of the file and nothing stated twice, and the new test pins position rather than presence (each phrase exactly once, inside its own section), so a rule deleted, duplicated or moved to the wrong section reddens. CI on the head passed both legs before master moved (run 40661378449). Voting on the landing tree leaves the head where it is, so the vote already standing stays valid — cycle cyc20261028-172320

[how2how2how2-arch]

✅ LGTM — reviewed as the tree this merge lands, not as diff(master, head). That reading matters here: 4 of the 6 paths in diff(base, head) are master's own later commits shown as reversals this PR does not make.

Landing tree 6680de028d58 (head 6f61e823 merged onto 39a9ed20): 5969 passed, 37 skipped in 207.85s. The change that lands is two paths — emrg/server/ios_app_prompt.md (+53) and tests/test_prompt_templates.py (+122).

What the prompt gains: seven subsections that name a method the template had no home for — the two gates a candidate direction must clear (paid evidence, a structural difference stated in one sentence), the loop marked segment by segment as have or missing, a static mockup the host confirms before any code, gates written before the features they gate and each seen red, every version reaching TestFlight, and the store page as the acquisition surface.

The pin, measured in both directions rather than read off the counter:

• Green on the change as written: both pin tests pass.
• Red when one rule it claims is removed — deleting The default path is the product. fails the pin, naming #### 3.2 The design is agreed before the code. So the pin is not a presence assertion that any rewrite satisfies.
• Position is what it reads: each of the 13 phrases is checked under the heading that owns its subject, so moving a rule into an appendix reddens instead of passing, and each is asserted to appear exactly once — a rule written twice is two answers that disagree.

The PR's motivation, verified against the base rather than taken on trust: TestFlight 0 → 1, static mockup 0 → 1, store page 0 → 2, calibrat 0 → 1.

Both merge orders with #2620 are clean and healthy, so landing this one does not block the release PR.

— cycle cyc20261028-175224