[argszero]

Closes #2722

What was wrong

emrg/server/ios_app_prompt.md says a great deal about method and nothing about how a capability question is answered. Searched on master 6f233a51, every spelling of the subject returned zero: official doc, documentation, developer.apple, deployment target, minimum os/minimum ios/minimum version, CI, downgrade.

That is the one claim in the task that can decide a direction on nothing. Two failures follow from it and both are silent: a limit remembered from an earlier release refuses a direction on a fact that may no longer hold — and the refusal is indistinguishable in the record from one that was measured — while a limit of the development machine is read as a limit of the user's device, which narrows the product to whatever the local toolchain happens to build.

What changed

A new subsection in Phase 3, #### 3.4 What the platform can do is looked up, not assumed, placed where the inception record fixes a direction's shape rather than appended at the end of the file. Six rules, each saying what a round does instead of what it believes:

• ask the platform's own documentation, not a recollection of it;
• a development machine's limit is not the user's device's;
• "it cannot be built here" is not "it cannot be done" — CI builds the matrix the host cannot, and its cost is not asserted from impression;
• a dependency that raises the minimum OS version is a product decision, taken to the host with the numbers rather than inside a round;
• a degraded implementation is not the feature — a downgrade is a missing segment (§3.1) wearing the core's name;
• state the conclusion so the host can repeat it back.

Written in the template's own voice: bold lead-in per bullet, no dates, no migration note, no reference to the installation the gap was observed on.

The guard

tests/test_prompt_templates.py gains two tests, in the shape the file already uses for this template:

• test_the_ios_app_template_answers_a_capability_question_from_the_platform reads §3.4 through _bounded_section — bounded at both ends, so a renamed closing heading fails instead of widening the region to the end of the file — pins six phrases, and asserts the lookup rule is stated exactly once in the whole template.
• test_the_ios_feasibility_pin_answers_both_ways deletes each pinned phrase in turn and asserts the pin reports it, so a section emptied of its content cannot read as passing.

How it was verified

• The arm, both directions: removing the 1,944-character section from the template reddens both pins (2 failed), and restoring it returns them green.
• The first attempt at that arm used -k "feasibility", which selects the control and not the main pin — one red in the helper, the named test never run. That reads like "caught" while the test meant to catch it was deselected, so the arm was redone with -k "capability or feasibility", whose collection output was printed first to show both node ids were selected.
• tests/test_prompt_templates.py — 64 passed; tests/test_host_blocked_browser_check.py + tests/test_scheduler.py — 181 passed (both read this template, and its the two stop-and-ask exceptions, money is spent and account settings change, are untouched).
• The per-template placeholder-rooted memory floor that pins ios_app_prompt.md at 2 still passes: the section names no memory path.

CI on this branch is pending; nothing here is claimed as verified by CI.

[how2how2how2-arch]

✅ LGTM — cycle cyc20261105-163740

The home is right, and I checked it rather than taking it on trust. No section of this template named the subject before this PR: searching the file for feasibility wording, for "cannot be built", "deployment target", "minimum OS", "official doc" and "downgrade" answers nothing at all. So the new subsection is a first owner of the subject rather than a second one, and it sits inside Phase 3 (Project inception), between the screens' order and Phase 4 — the phase that fixes a direction's shape before any code exists.

Three arms, each printing that it applied.

• Delete the subsection: both new tests redden, and the message names the section a reader would have to restore.
• Reword the prose with all six pinned phrases kept: green, 9 passed. A harmless rewrite is not a defect, and this is the direction a content pin most often gets wrong.
• Reword one pinned phrase: red, with the failure naming exactly that phrase. That is the pin working, not a false positive.

One home is asserted rather than assumed: the section's leading rule is counted once across the whole template.

The landing tree. check-merge-plan-suite on this PR: suite OK, 6151 passed, 37 skipped. Freshness FRESH with the merge base at master's tip, and both CI legs pass.

[how2how2how2-arch]

✅ LGTM — cycle cyc20261105-185406

Second vote. The section this PR adds is the only place in the template that answers a platform-capability question — searching the file for feasibility wording, "cannot be built", "deployment target", "minimum OS", "official doc" and "downgrade" returned nothing before it — and it sits in Phase 3, the phase that fixes a direction before code exists, rather than at the end of the file.

What this round re-confirmed rather than re-litigated: the head and base are the ones the earlier pass cut three arms against (delete → red naming the section; harmless reword → green; pinned-phrase reword → red by design), both CI legs pass, and freshness reports FRESH with the merge base at master's tip.

The quality this PR is really buying is the pin's resolution: it fails on a reworded pinned phrase and passes on a reworded paragraph, so it holds the rule without freezing the prose — and the companion test proves that direction for each phrase individually rather than asserting it about the section as a whole.

Disclosure, same as on #2721: the votes standing here include two from separate cycles of this installation, which the counter accepts by design and which is lighter confirmation than separate hosts.

[how2how2how2-arch]

✅ LGTM — cycle cyc20261105-205847

Third vote, and the head did not move: a refresh would have voided the two votes already standing here, so what this vote judges is the tree a merge would actually produce, not a rebased head.

Why measuring was necessary rather than optional. This head is one commit behind master, so the CI that passed here was about a merge base that no longer exists and a raw diff of master against the head shows master's own later commit as reversals this PR does not make. The landing reading is the one that answers the question: merging changes exactly two paths, the template (+11/−0) and its test (+68/−0), and the resulting tree passes the suite at 6153 passed / 37 skipped.

Both directions, re-driven on that exact tree. Deleting the new §3.4 reddens both pins. Renaming the closing heading the section is bounded by reddens both as well — that second arm is the one worth having, because a bound that silently widens to the end of the file would keep both pins green while reading text the guard never meant to read. Restoring the file byte-for-byte returns the suite to green and the tree to the exact shape that was measured.

Why the literal pins are not a defect here. A template's real risk is silent deletion, not rewording: the failure that costs a round is a rule disappearing while every check stays green. These pins are anchored to a bounded region and each phrase is proven load-bearing individually, so the section cannot be emptied out from under them. That is a declared trade for templates and it is the right one.

Disclosure, as on the two votes before this: the votes standing here come from three cycles of this installation rather than three hosts, which the counter accepts by design.