Repository navigation
emrg: the ios-app prompt template carries the build method and no product method #2617
Description
What was observed
emrg/server/ios_app_prompt.md is the app prompt a scheduled round reads. It covers the build thoroughly: preparation, credentials, the review-rejection gate, cross-round state, screenshot capture, the archive. Every one of those subjects has a section that owns it.
It covers the product not at all. A round reading the template end to end is told how to build, test, submit and record — and is told nothing about:
- which candidate to build, among several that would all pass the rejection gate;
- what the core loop of the app must contain before it can be called built;
- whether a design is agreed before code is written;
- in what order the screens are arranged;
- whether the gates that decide "done" come before or after the features;
- whether a submitted build reaches the person who asked for it;
- how a small app is found at all, given nobody is looking for it.
Measured on a live installation: its supplementary task configuration carried exactly that product method, block by block, while the template carried none of it. That supplementary text is not configuration — it is general method with no home in the template, filed by the installation because the installation had no other channel for it.
What the fix must satisfy
Add the product method to the template itself, as seven rules, each written into the section that already owns its subject, in the template's own voice and structure — no dates, no migration notes, no instance values, no text pasted from any installation's configuration:
| Section | Rule it acquires |
|---|---|
| §1.1 | Selection carries two gates of its own — evidence people pay, and a structural difference stated in one sentence — and a candidate failing either is replaced, not built. A product that gives a conclusion beats one that reports activity. |
| §3.1 | The product is written as the segments a user passes through, each marked have or missing; a missing segment outranks every new feature and every version number. |
| §3.2 | A static mockup is agreed screen by screen before implementation, and is the acceptance surface — every requirement visible, one concept per screen, the user's vocabulary, the default path is the product itself. |
| §3.3 | Screens are 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 before it is trusted; a rule only a comment claims is not a rule; a gate that fails open is not a gate. |
| §5.1 | 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 | At low install volume acquisition happens on the store page, which has one screenshot and one sentence to work with; installs are the only hard number. |
Each rule appears exactly once: a rule appended at the end of the file, or restated in a second section, is not the change asked for.
Acceptance
- The seven phrases are present in
emrg/server/ios_app_prompt.md, each under the section named above. - A test pins position, not just presence: a test in
tests/test_prompt_templates.pyasserts each phrase appears exactly once and inside its own section, so a rule deleted, duplicated, or moved to the wrong section reddens. Seen red once (a reworded rule) and green once (restored), so the direction is measured rather than assumed. - The full suite, the client import check and
python -m emrg --helppass.
Activity
argszero commentedon Oct 28, 2026
Handled by #2618