E.11.PFP:4.3 - Keep one practical-entry set and two visible forms
Start the Readme body with ## Practical entries. The product maintains one declaration for every selectable example and assigns each key exactly one public form: ordinary practical entry or Practical-Use Card. Each declared key occurs once, at H3 for an ordinary entry or at H4 for a card. A compact locator may precede or follow these examples, but it is a finding aid rather than another editable entry set.
The Readme says plainly that its entries are selected examples, not a catalogue or coverage boundary. It tells the reader to bring the actual question and to use the product’s index, direct patterns, or another finding aid when no example fits. Tell readers that they can ask an assisting agent for explanations and comments in ordinary language, without the framework’s specialist vocabulary. For example: “Explain this and give me your comments in ordinary language, without framework jargon.” Clear wording is the default under F.19; the request helps the assistant adapt its wording to the reader.
The selected examples should make two uses visible without implying that every question belongs to either displayed case:
- an ordinary entry shows how one direct pattern or one bounded direct route can answer a comparatively simple difficulty without a mantra; and
- a Practical-Use Card shows a recurring complex difficulty whose useful answer spans several direct pattern contributions and whose long dependency is easier to retain with a mantra.
The First useful result or blocker value gives the result of the action the entry supports, or a condition preventing that action. When several actions could be meant, name the relevant action in the value.
Use this ordinary-entry form:
### <ordinary-entry key> — <plain title>
- **Situation:** <recognizable working situation>
- **Question:** <practical question>
- **First useful result or blocker:** <smallest useful result of the named action, or the condition preventing that action>
- **Start with:** <direct PatternID or bounded plausible set>
- **Stop or return:** <ordinary stop, wrong-turn return, or reopen condition>
When the product selects at least one card, place all selected cards under one group:
### Practical-Use Cards
<plain statement that these are selected examples of extended cross-pattern use, not a catalogue or prescribed workflow>
#### <card key> — <plain title>
- **Situation:** <recognizable recurring difficulty>
- **Question:** <practical question>
- **First useful result or blocker:** <smallest useful result of the named action, or the condition preventing that action>
- **Mantra:** <plain repeatable wording that retains the cross-pattern dependency>
- **Start with:** <direct PatternIDs or bounded route>
- **Stop or return:** <ordinary stop, wrong-turn return, or reopen condition>
##### Expansion for <card key>
<optional explanation only>
### Practical-Use Cards is a group inside the one Practical entries set, not another front door or selectable key. Omit the group when the product selects no cards. The card’s canonical structural field is Mantra; its value begins directly with the repeatable wording and needs no Local/Long prefix. A local reminder for one direct pattern or bounded result may remain in that pattern, an ordinary entry, or other teaching material, but it does not by itself select the richer card form. E.11 owns this content decision.
Every selectable ordinary entry and card shares one product-wide semantic-key namespace. The product declaration assigns each key one form, so a key cannot occur as both H3 and H4. An H5 expansion repeats its enclosing card key only to attach optional explanation; it is not another selectable occurrence. A card has zero or one expansion. Its compact portion ends after Stop or return; the expansion ends at the next H4-or-higher heading or the end of the group. The expansion may explain branch choices, examples, or exact result support, but cannot contain another H4 card or H5 expansion.
The product-language application declares one deterministic reading-burden measure and two maxima: one for the mantra and one for the complete compact card. The measure must suit the publication language; whitespace counting is suitable only where it meaningfully measures reading burden. The maxima protect scanability and recall. They are not targets, proof of reader value, a fixed card count, or authority to delete a choice-changing distinction. Content that a compact card cannot carry truthfully returns to the direct patterns or, only when first choice needs it, the same-key expansion.
Applying this grammar does not select a card, prove that the examples cover the product, or show that every cited pattern is needed in a particular case. E.11 defines the direct-entry/card comparison, cross-pattern mnemonic-gain test, and non-exhaustive discoverability purpose. The product-specific E.4 pattern declares its selected example keys, forms, reading-burden measure, and two limits. A validator consumes those values and checks structure; it does not decide content value.
Use First useful result or blocker for this field in new entries. In existing publications, First useful result or honest blocker identifies the same field, with the same value and position; including both labels in one entry repeats the field.
This profile keeps structural field keys in canonical English. A translation may translate surrounding prose and values and may add a human-readable gloss, but it does not silently replace or reorder the field keys. A translated structural-key profile needs a separately selected recovery and checking rule. Test translated and low-tool publications with actual readers and navigation tools rather than treating English parser success as accessibility evidence.