The ios-app template never says how a platform capability question is answered

What was observed

emrg/server/ios_app_prompt.md is the prompt an ios-app task renders every round: 364 lines covering research, rejection risk, inception, implementation, submission and tracking. It is thorough about method — measure the content before promising it, write the gate that fails first, one change per version, coverage and occurrence are two numbers.

It is silent on the one question that decides whether a direction is buildable at all: how the task is to find out what the platform can do. A search of the template for official doc, documentation, developer.apple, deployment target, minimum os/minimum ios/minimum version, CI and downgrade returns zero for every one of them.

Where it was observed

Measured on master 6f233a51, against the same installation's extra_prompt for the ios-app-task record: that block carries this subject as general method, stated without any path, account or private datum — a platform capability is checked against the platform's own documentation rather than from memory; a development machine's limit is not the user device's; "cannot build here" is not "cannot be done", so CI is asked and its cost is not asserted; a dependency that raises the minimum OS version is a product decision for the host; and a degraded workaround for the core is not the core.

Of the fifteen concepts that block and the template share, fourteen are already in the template. This is the fifteenth, which is why it reads as a template gap rather than an installation preference.

What the fix must satisfy

1. The rules are stated in the section that owns the subject — Phase 3, where the inception record fixes a direction's shape and the build plan is written — not appended at the end of the file.
2. Written in the template's own voice and structure: bold lead-in per bullet, no dates, no history, no migration note, no reference to the installation the observation came from.
3. Each rule says what a round does instead, so a reader can act on it: ask the documentation, ask CI, take the minimum-OS cost to the host with the numbers, ask the feasibility question again rather than ship a downgrade.
4. A test pins the section, bounded at both ends, so a later edit that deletes it or moves it out fails rather than passing on a wider region.