Recipe Edition
==============

Plan for the first community edition: a TiddlyWiki for storing, browsing,
and using personal recipes.  Scope, priorities, and open questions are
derived from the [prompt][pr] and the project-wide
[edition design criteria][ed], informed by prior discussion in the
[TiddlyTalk threads][t1] [(2)][t2] [(3)][t3] [(4)][t4].


Status
------

  * [x] Phase 1 — Prior-art review and design decisions
  * [x] Phase 2 — Empty-edition skeleton (namespace, palette, plugin bundle)
  * [x] Phase 3 — Recipe data model and authoring templates
  * [x] Phase 4 — Reading views (primary, split, step-by-step)
  * [x] Phase 5 — Discovery (search, tag filter, ingredient lookup)
  * [x] Phase 6 — Mobile and kitchen-use polish
  * [x] Phase 6a — Extended recipe content (About section, photo field)
  * [x] Phase 7 — Companion content collections and reset-to-empty affordance
  * [x] Phase 7a — Ingredient tiddlers
  * [x] Phase 7b — Edit templates (photo field UI)
  * [x] Phase 8 — In-edition documentation
  * [x] Phase 8a — Configurable supplemental fields
  * [x] Phase 8b — Recipe Box landing dashboard
  * [x] Phase 9 — Compatibility metadata and phone-home hooks
  * [x] Phase 10 — Dev scaffolding cleanup
  * [x] Phase 11 — Verification against design criteria
  * [x] Phase 11a — Sample-data hosting (GitHub Pages)
  * [x] Phase 12 — Tier 1 localization (UI string externalization)
  * [x] Phase 13 — Tier 2 localization scope review (deferred to v1.1+)
  * [ ] Phase 14 — Release 1.0


Goals and priorities
--------------------

The [edition design criteria][ed] are the umbrella.  Within them, the
recipe-specific priorities — paraphrased from the [prompt][pr], in
order — are:

  1. A recipe is extremely easy to read and follow while cooking.
  2. Recipes are searchable, browseable, and filterable — by title,
     category, and ingredient.
  3. Categories (tags) are easy to extend or replace.
  4. Recipes are easy to write.
  5. Works at mobile sizes (phone and tablet).
  6. A split view with ingredients and steps side-by-side,
     independently scrollable.
  7. A step-by-step view with the current step strongly emphasized in
     context.

These remain subordinate to the umbrella criteria — narrow scope,
works out of the box, self-documenting from within, and the
~1,000-word explainability ceiling.


Development approach
--------------------

Day-to-day work happens against a Node-based wiki at
[./editions/recipes/wiki/][sk], which makes individual tiddlers
editable on disk and dev-loop tight.  The skeleton already contains a
set of personal TiddlyWiki preferences (sidebar layout, default tabs,
title filters, animation duration, theme metrics, and so on); these
are a starting point, not a commitment, and will be pruned, replaced,
or kept on a case-by-case basis as the edition's own conventions
emerge.

The primary release artifact remains a single-file HTML build
produced from the same source.  Nothing in the edition should depend
on the Node-specific machinery (tiddlyweb, filesystem sync) for its
behavior.

Dev infrastructure (`package.json`, TiddlyWiki dependency, serve and
build scripts) was stood up in Phase 2.  Companion content
collections live under [./editions/recipes/samples/][samp].


Scope
-----


### In scope ###

  - An **empty** edition plus one or more companion JSON content
    collections.  A populated variant is produced by loading a
    collection into the empty edition.  First-pass collections are
    a US-customary sample and a metric sample; more may follow as
    l10n / i18n concerns develop.
  - Recipe tiddlers carrying: title, tags, ingredients, steps, source
    or URL, and optional servings and notes.
  - User-extensible tag-based categorization (Dessert, Main, Soup,
    …).
  - Ingredient links so "which recipes use cauliflower?" is trivial.
  - Three reading views: primary single-column, split
    ingredients/steps, step-by-step.
  - A new-recipe template with prefilled structure to make authoring
    easy.
  - In-edition documentation — what the edition does, its
    conventions, and how to extend it.
  - Single-file HTML as the release artifact, built from the
    Node-based dev wiki at [./editions/recipes/wiki/][sk].  No
    runtime dependence on tiddlyweb, filesystem sync, or other
    Node-only machinery.
  - Namespace `$:/community/recipes/` and palette-based theming
    (no hardcoded colors).


### Out of scope — futures list ###

Rejected as premature in [thread 8742][t3]; parked here so we don't
re-litigate mid-build.

  - Parsing quantities into separate fields.
  - Unit conversion (metric ↔ imperial, °C ↔ °F).
  - Inventory tracking or pantry matching.
  - Shopping-list integration.
  - Recipe-clipping / web import.
  - Meal planning or scheduling.
  - Full i18n (RTL, locale-sensitive numbers, plural rules), per
    [edition design criteria][ed].
  - Extended-functionality plugin suggestions ("install X for these
    benefits"), per [edition design criteria][ed].
  - Ingredient cross-highlighting in step-by-step mode — when a step
    is active, ingredients it mentions are highlighted in the
    ingredients panel.  Requires matching ingredient names against
    free-form step text; interesting but non-trivial.


Key design decisions
--------------------

Resolved in Phase 1; captured in the [recipe design note][rd].

  - **Ingredient representation** — inline wiki links in an
    `!! Ingredients` section.
  - **Step representation** — numbered list under an `!! Steps`
    section.
  - **Plugin bundle** — [Relink][rl] for release; Node-sync plugins
    stay dev-only.  [Auto Complete][ac] (tiddler-title suggestions while
    authoring) is also bundled.  uni-link was evaluated and removed: it
    intercepts `[[...]]` syntax but does not resolve plain links to
    canonical tiddlers — `[[garlic]]` still navigates to the missing
    `garlic` tiddler rather than `Garlic`.  Case variants are handled
    instead by the `aliases` field on canonical ingredient tiddlers
    combined with the ingredient view template and AutoComplete steering
    authors toward canonical names at write time.
  - **Locale approach** — no locale logic in the edition; variation
    happens through content collections.
  - **Sample-content isolation** — every demo tiddler carries a
    `demo: yes` field (not a tag, to keep the tag UI clean).


Phases
------


### Phase 1 — Prior art and design decisions ###

  - Review [Przepisy][pz] (lowercase-ingredient linking) and
    [Maple][mp] (drag-and-drop meal planning — mostly as a reference
    for what we *don't* do).
  - Scan any other recipe wikis the community has cited.
  - Resolve every item under **Open decisions**.  Record each
    resolution as a short architecture note under
    [.meta/architecture/][arch].


### Phase 2 — Empty-edition skeleton ###

  - Stand up the dev infrastructure: a project `package.json` with
    TiddlyWiki pinned as a dependency and simple scripts for
    serving the Node wiki and producing the single-file HTML build.
  - Adopt the existing skeleton at [./editions/recipes/wiki/][sk] as
    the working directory for the edition source.
  - Audit the personal-preference tiddlers already present —
    sidebar layout, default tabs, title filters, theme metrics, and
    the like.  For each: keep as edition default, replace with an
    edition-specific choice, or drop.  Record the result.
  - Wire the `$:/community/recipes/` namespace and a palette-only
    theming rule.
  - Add the plugins chosen in Phase 1 and record pinned versions in
    a single manifest tiddler.
  - Confirm the single-file HTML build works and has no runtime
    dependence on Node-only machinery.


### Phase 3 — Data model and authoring ###

  - Recipe tiddler type or tag plus field conventions, per Phase 1
    decisions.
  - New-recipe template with prefilled structure and inline hints.
  - Source/URL field rendered as a link wherever the recipe is
    displayed.


### Phase 4 — Reading views ###

  - Primary readable view — typography tuned for reading while
    cooking.
  - Split view — ingredients and steps side-by-side, independently
    scrollable.
  - Step-by-step view — current step strongly emphasized, with
    visible but de-emphasized context above and below.  Exact visual
    treatment to be chosen during build; the property is
    "see both context and current status at a glance."


### Phase 5 — Discovery ###

  - Browse by tag (category).
  - Free-text search across titles and bodies.
  - Refine the current browse set with a further term or tag.
  - Ingredient-driven lookup — "recipes using X."


### Phase 6 — Mobile and kitchen use ###

  - Responsive layout for phone and tablet.
  - Cooking-mode font sizing that stays legible at arm's length.
  - In cooking mode: hide the tiddler subheader (date, tags) and tag
    bar so only the recipe content and controls are visible.
  - Sticky step-nav footer — pinned to the bottom of the viewport,
    at minimum on phones, ideally everywhere.
  - Hide other buttons besides "Exit cook mode" button when in cook mode.


### Phase 6a — Extended recipe content ###

  - Add `!! About` as an optional free-text section to the data model
    and new-recipe template (with an inline hint explaining its purpose).
    Content may include prose, inline images, serving suggestions, etc.
  - Add a `photo` field to the data model — a tiddler title reference to
    an attached image.  Template renders it if present; exact placement and
    sizing to be decided during build.
  - Render `!! About` (and `photo` if present) as a full-width block above
    the ingredient/step split in the normal reading view.  Both are hidden
    in cooking mode.
  - Document the optional supplemental fields (`servings`, `oven-temp`,
    `photo`, and any others users may add) in the new-recipe template
    hints and in the in-edition documentation.


### Phase 7 — Companion collections and reset ###

  - Produced a US-customary companion JSON collection
    (`editions/recipes/samples/recipe-tiddlers-us.json`) — 31
    real recipes sourced from TheMealDB, each with an `!! About`
    section and an attached photo.  A metric-units collection is
    deferred to a future pass.
  - Added `$:/community/recipes/ui/RemoveDemoContent` — a
    checkbox UI tiddler that lets users selectively delete demo
    recipes, ingredients (with independent photo toggles per row),
    and categories before they start.  A header checkbox per column
    selects or clears the whole column at once.  The tiddler is
    linked conditionally from Overview (hidden once no demo content
    with `field:demo[yes]` remains) and auto-closes after the
    deletion runs.


### Phase 7a — Ingredient tiddlers ###

Ingredient tiddlers currently exist only implicitly — a wiki link in a recipe
body creates an empty tiddler.  Phase 7a gives them structure: an enriched
view, optional photos, an aliasing mechanism, and sample data for the most
common ingredients in the US collection.


#### Progress ####

  - [x] Ingredient sample data — `ingredient-tiddlers.json` with 31 ingredients,
        extended descriptions, and Unsplash photos (7 inline at w=1000; 24
        `_canonical_uri`)
  - [x] `Ingredient` tag tiddler in `wiki/tiddlers/` — caption "Ingredients",
        lists tagged tiddlers via `<<list-links>>`
  - [x] Photo normalization — recipe photo tiddlers use TheMealDB `_canonical_uri`
        (5 inline); `photographer`/`photo-source` fields on all photo tiddlers;
        `photourl` removed from recipe content tiddlers
  - [x] AutoComplete plugin installed; uni-link installed then removed (see
        Aliasing section below for rationale)
  - [x] `aliases` fields added to ingredient tiddlers covering common case
        and plural variants
  - [x] Ingredient view template — `ViewTemplate/ingredient-body` (photo +
        description) and `ViewTemplate/ingredient` (alias notice + "Used in:"
        list)


#### Ingredient identification ####

Ingredient tiddlers carry the user-visible `Ingredient` tag (already present
on the `Salt` sample tiddler).  The tag is intentionally not system-namespaced
so it can appear in the tag browser as a discoverable category.  The
new-recipe template hint will note that ingredient tiddlers can be "promoted"
by adding the `Ingredient` tag.

#### View template ####

The existing `$:/community/recipes/ui/ViewTemplate/ingredient` tiddler already
shows a "Used in:" list for any tiddler that appears as a backlink from a
Recipe-tagged tiddler.  Phase 7a extends it:

  - When the current tiddler has the `Ingredient` tag, render any attached
    photo (via a `photo` field, same pattern as recipe photos) and the
    tiddler body as a description above the "Used in:" list.
  - When the current tiddler has an `alias-of` field, render a short notice
    ("Also known as…") linking to the canonical ingredient, then transclude
    the canonical's description and photo.  Suppress the "Used in:" list on
    the alias — it appears on the canonical instead.

#### Aliasing ####

Canonical ingredient tiddlers carry an `aliases` field listing common lowercase
and plural forms (e.g., `Garlic` has `aliases: garlic`).  The ingredient view
template uses `contains:aliases` to detect when a missing tiddler is an alias
and shows "Alias of [canonical]" plus the canonical's "Used in:" backlinks.
The missing-tiddler hint is suppressed for alias tiddlers so the view template
content is the only thing shown.

uni-link was evaluated for transparent link resolution (`[[garlic]]` →
`Garlic`) but does not provide that: plain `[[...]]` links still navigate to
the exact title typed.  It was removed.  AutoComplete steers authors toward
canonical names at write time, which is the primary mitigation.

#### Sample data normalisation ####

The US recipe collection has 22 case-collision pairs (e.g., `Garlic` vs.
`garlic`) and one three-way collision (`vegetable oil` / `Vegetable oil` /
`Vegetable Oil`).  The approach:

  - Canonical ingredient tiddlers carry an `aliases` field listing the
    case variants found in the recipe bodies.
  - Missing tiddlers matching an alias show "Alias of [canonical]" and
    the canonical's "Used in:" list rather than the standard missing-tiddler
    hint.
  - Recipe bodies are not edited; the variant links remain as-is and open
    their (missing) tiddler, which redirects the reader to the canonical.

#### Ingredient sample data ####

Done.  31 canonical ingredient tiddlers in `editions/recipes/samples/ingredient-tiddlers.json`.
Each carries `tags: Ingredient`, `demo: yes`, an extended prose description,
a `photo` field, and a paired `Name (photo)` tiddler.  7 photo tiddlers are
inline (w=1000 JPEG from Unsplash); 24 use `_canonical_uri`.  All photo
tiddlers carry `photographer` and `photo-source` fields.

Add a small number of illustrative aliases from the sample data —
`Bicarbonate of Soda` → `Baking Soda`, `Rapeseed Oil` → `Vegetable Oil`,
`Icing Sugar` → `Powdered Sugar` — to exercise the aliasing view.


### Phase 7b — Edit templates (photo field UI) ###

The default TiddlyWiki edit view has no awareness of the `photo` field.
Users must drop an image into the wiki, note the resulting tiddler title,
and type it into the field editor manually.  Phase 7b replaces that friction
with a dedicated photo section in the edit view for both Recipe and Ingredient
tiddlers.


#### Scope ####

Two edit-template tiddlers — one filtered to `tag[Recipe]`, one to
`tag[Ingredient]` — each tagged `$:/tags/EditTemplate` and positioned above
the body editor with `list-before`.  The body editor and all other default
edit controls are unchanged.

The `!! About` section already allows inline images (`[img[...]]`) anywhere
in its prose; Phase 7b does not touch that.  It deals only with the canonical
`photo` field — the single header image that the recipe and ingredient view
templates already know how to display.


#### Photo section behaviour ####

When `photo` field **is set**:

  - Render the photo at a modest preview size.
  - Offer a "Remove photo" button that clears the `photo` field (does not
    delete the image tiddler).

When `photo` field **is not set**, offer two paths side-by-side:

  - **Embed** — a drop-zone (or `<$browse>` file-picker) that accepts an
    image file, creates a new tiddler titled `<<currentTiddler>> (photo)`,
    and sets `photo` to that title.  The image data is stored in the wiki.
  - **Link** — a text input for an external URL.  Accepting the URL creates
    the same stub tiddler (`<<currentTiddler>> (photo)`) with a
    `_canonical_uri` field containing the URL and no body, then sets `photo`
    to that title.  TiddlyWiki renders `_canonical_uri` images without
    embedding the data.

In both cases the resulting `photo` tiddler title is shown beneath the
preview so the user can see what was created; a "Change photo" button resets
to the unset state.


#### Open design question ####

Whether the embed and link paths should be combined into a single
interaction (e.g., paste-or-drop) or kept visually separate is left to
implementation.  Both must remain accessible without leaving the edit view.


### Phase 8 — In-edition documentation ###

  - "About this edition" — what it is and how to use it.
  - "Conventions" — tags, fields, namespace, where to theme.
  - "Extending" — how to add categories, customize templates, bring
    in additional plugins.
  - Document platform limits (e.g., screen-wake behavior) that the
    edition can't solve from inside a wiki.
  - Total prose within the ~1,000-word ceiling from the
    [edition design criteria][ed].

After this phase the docs are part of the contract: subsequent phases
that change user-visible behaviour must update the relevant section in
the same commit.


### Phase 8a — Configurable supplemental fields ###

Recipe tiddlers can carry supplemental fields beyond the core data
model — `source`, `servings`, `prep-time`, `cook-time`,
`oven-temp`, `yield`, and others users may invent.  Current handling is ad-hoc (`source` rendered specially, the
rest invisible unless the user opens edit view).  Phase 8a replaces
that with an explicit registry, so the recipe view template renders
only fields the user has registered.

This phase also serves as the first community-edition example of
edition-level configuration.  The Control Panel tab pattern is the
reusable shared piece; what appears on the tab stays
edition-specific.  No shared module is extracted here — the recipe
edition implements it locally; other editions emulate the pattern
when a second use case appears.


#### Registry shape ####

Each registered field is its own config tiddler tagged
`$:/tags/community/recipes/extra-field`, typically named
`$:/community/recipes/extra-fields/<field-name>` (convention, not
required).  Each carries:

  - `field-name` — the field name on the recipe tiddler
  - `caption` — the human-readable label
  - `placeholder` — optional example value shown as the input's
    placeholder text in edit mode (see Scope)
  - text body — wikitext template for rendering the value; empty
    falls back to the default procedure


#### Render contract ####

When the metadata strip transcludes a config tiddler's text,
`<<currentTiddler>>` is set to the recipe and `<<field-value>>` to
the value of that field on the recipe.  This lets templates be
field-name-agnostic (`<<toHoursAndMinutes>>` works for any
time-bearing field regardless of its name) and lets complex cases
reach back to the recipe via `{{!!some-other-field}}`.

Default rendering is a single shared procedure
`<<extra-field-default>>` that echoes `<<field-value>>`; always
called when the text body is blank, so the pipeline is single-path.
The strip wraps each row with the caption.

`<<field-value>>` invokes TW's macrocall semantics, so values are
rendered as wikitext rather than literal text.  This lets users type
`<<deg F>>` in `oven-temp` and have it render as `°F` — useful for
characters that are hard to type on many keyboards.  Per-field
templates that want literal output can opt out with
`<$text text=<<field-value>>/>`.

Helper procedures (e.g., `toHoursAndMinutes`, plus an oven-temp
formatter if useful) live under `$:/community/recipes/procedures/`
so the Control Panel can list them alongside registered fields.

Ordering follows standard TW tag-list semantics: a `list` field on
the registry tag tiddler plus `list-before` / `list-after` on
individual config tiddlers.

Core fields (`photo`, `tags`, body sections) stay outside the
registry — they have their own rendering paths.


#### Scope ####

  - Registry tag tiddler, default procedure, and helper procedures.
  - Helper procedures: `toHoursAndMinutes` (for the time-bearing fields, parsing
    values like `40`, `90`, or `1h 30m`) and `deg` (`<<deg>>` / `<<deg F>>` /
    `<<deg C>>`, for the degree symbol that's hard to type on many keyboards).
    Both live under `$:/community/recipes/procedures/`.
  - Default registered field set covering 8–10 commonly-used fields, starting
    with `source`, `servings`, `prep-time`, `cook-time`, `oven-temp`, `yield`,
    with the rest chosen during implementation (candidates: `total-time`,
    `difficulty`, `notes`, `serving-size`).
  - Recipe view template renders a metadata strip transcluding each registered
    field's config tiddler with the contract above.
  - **Field-name discoverability** — override
    `$:/config/EditMode/fieldname-filter` so the edit-view's field-add
    autocomplete pulls registered field names directly into its primary
    suggestion list, alongside field names already in use on user
    tiddlers.  Works on any TW version and needs no temp tiddler or
    sync mechanism — the override's filter re-evaluates reactively from
    the registry.  (A Background Actions / temp-tiddler approach was
    considered first but would only place names in the secondary
    suggestion list, so we skipped it.)
  - **Placeholder hints** — each config tiddler may carry an optional
    `placeholder` field showing example values (e.g., `350<<deg F>>` for
    `oven-temp`, `40 minutes -or- 1 h 30 m` for `prep-time`). A single
    `$:/tags/FieldEditorFilter` cascade entry routes any field whose name
    matches a registered config to a custom editor that surfaces the placeholder
    as the input's placeholder text.
  - New-recipe template mentions the registry; may optionally prefill
    placeholder lines for the most-used fields.
  - Control Panel tab listing registered fields with add / edit / remove
    affordances.
  - **Suppress the `photo` row from the standard edit-mode field list
    and field-add dropdown.**  The Phase 7b photo edit form is the
    only affordance the user should see; the raw `photo` field
    showing up alongside it is a duplicate.  An attempted fix using
    `$:/config/EditTemplateFields/Visibility/photo` (`hide`) had no
    effect when first tried — needs a closer look at TW core's
    `tf.config-filter` lookup semantics, and the field-add dropdown
    uses a separate filter that doesn't honour the visibility
    config.  If we can't find a clean way, leave the duplicate in
    place rather than hacking around it.


#### Demo data ####

The sample recipes in `recipe-tiddlers-us.json` are refreshed to
exercise the registry — recipes carry varied combinations of the
registered fields, from none to all, distributed across the 31
samples so the metadata strip is visible in many different shapes.


#### Docs ####

The About tiddler's "Conventions" and "Extending" sections gain a
brief mention of the registry and where to manage it, per the
docs-upkeep contract from Phase 8.


### Phase 8b — Recipe Box landing dashboard ###

A configurable landing view named "Recipe Box" composed of card
tiddlers, intended to replace `TableOfContents` in
`$:/DefaultTiddlers` (`Tidbits: About` stays as the second default).
The four shipped cards cover a category-level expandable TOC,
content-tag pills, favorites, and most-used ingredients.  Users add,
reorder, or remove cards by creating or editing tiddlers tagged for
the dashboard.


#### Card model ####

Each card is a tiddler tagged
`$:/tags/community/recipes/recipe-box-card` carrying:

  - `caption` — header text (falls back to the tiddler title)
  - text body — wikitext content rendered inside the card

Cards order via standard TW `list` (on the tag tiddler) and
`list-before` / `list-after` (on individual cards).  The container
iterates the tag and wraps each card in a `<section>` with the
caption as the header.


#### Initial cards ####

  - **Categories** — selective-expandable TOC rooted at the
    `Category`-tagged tiddlers (Main, Side, Dessert, Salad,
    Breakfast); expands to show recipes within each.

  - **Tags** — pills via the built-in `<<tag>>` macro from the
    filter `[tag[Recipe]tags[]] -Recipe -Favorite -[tag[Category]]`,
    sorted by frequency of use across recipes.

  - **Favorites** — link list from `[tag[Recipe]tag[Favorite]]`.

  - **Popular Ingredients** — pills via `<<tag>>` from
    `[tag[Ingredient]]`, sorted by recipe-backlink count descending,
    limited to roughly 12.


#### Layout ####

CSS Grid: `repeat(auto-fit, minmax(280px, 1fr))` with a small gap.
Cards have variable height; the browser flows columns automatically
from one (mobile) to four-plus (wide) without a media-query ladder.
Source order — Favorites, Categories, Popular Ingredients, Tags —
governs both single-column and multi-column reads.  No max-height or
internal scroll for now; revisit only if a card runs away.


#### Empty states ####

When a card filter returns no items, render a one-line hint in place
of the empty body — e.g., *"Mark a recipe Favorite to see it here"*
for Favorites, *"Add an Ingredient-tagged tiddler to see it here"*
for Popular Ingredients.  The hint serves as inline documentation on
the empty edition.


#### Default-tiddler swap ####

`$:/DefaultTiddlers` currently opens `TableOfContents` and
`Tidbits: About`.  Phase 8b replaces `TableOfContents` with
`Recipe Box`.  Phase 10's stale entry for `$__DefaultTiddlers.tid` is
settled by this swap.


#### Docs ####

Documenting "How to add a card" is deferred until the pattern proves
out.  Once it does, the docs land in About's Extending section or a
dedicated tiddler — see Phase 8b's docs-upkeep follow-up.


### Phase 9 — Compatibility metadata ###

  - Record tested-against TW core versions and bundled-plugin
    versions in a machine-readable tiddler.
  - Determine the minimum TW core version the edition supports and
    record it.  Phase 8a's discoverability override side-stepped the
    5.4.0 Background Actions dependency we'd originally anticipated,
    so the floor is now whichever core version we actually rely on
    in practice — confirm during this phase rather than guessing.
  - Stub the phone-home check described in the
    [edition design criteria][ed] so the (future) editions tool has
    something to consume.  Do not build the editions tool here.


### Phase 10 — Dev scaffolding cleanup ###

Items committed for development convenience that must be reviewed or
removed before release.  Each entry notes its dev role and the
intended release state.

  - `$__DefaultTiddlers.tid` — currently opens `TableOfContents` +
    `Tidbits: About`; Phase 8b replaces `TableOfContents` with
    `Recipe Box`.  No further action here.
  - `$__StoryList.tid` — committed empty; confirm it stays empty in
    the release build.
  - `$__config_DefaultSidebarTab.tid` — currently `TableOfContents`
    (a personal preference); decide on the release default.
  - `$__config_DefaultMoreSidebarTab.tid` — currently `System` (dev
    convenience); remove or change to a user-friendly default.
  - `Some Recipe.tid` (had `demo: yes` field) — removed; confirmed
    absent from the empty release artifact.


### Phase 11 — Verification ###

  - Walk the [edition design criteria][ed] and confirm every bullet
    is either met or consciously deferred, with the deferral noted.
  - Cross-browser and mobile spot checks.
  - Empirically verify the recorded `min-tw-core` (currently 5.3.0,
    set by static analysis in Phase 9) by building and smoke-testing
    against that version; flip
    `$:/community/recipes/compatibility/tw-core` `min-version-verified`
    to `yes`.  Empirical testing was deferred from Phase 9 because the
    corporate npm registry quarantines all 5.3.x releases.


### Phase 11a — Sample-data hosting (GitHub Pages) ###

The empty edition's [[Tidbits: Edition Contents]] currently points at
a placeholder URL.  This phase stands up GitHub Pages from this repo
so the link resolves to real JSON, ahead of the eventual
community-editions site (envisioned at a subdomain such as
`editions.tiddlywiki.com`).  Forum reviewers also gain a stable URL
for the latest build that updates on `git push`.


#### Scope ####

  - Publish from `/docs` on `main`.  Initial layout is recipe-only,
    nested under `docs/recipes/` so multi-edition expansion is an
    overlay rather than a rearrangement.
  - New config tiddler `$:/community/recipes/config/sample-data-url`
    holds the URL; [[Tidbits: Edition Contents]] transcludes it
    instead of hardcoding.  This decouples the in-edition reference
    from the host, enabling a future phone-home response (or manual
    override) to deliver an updated URL without re-shipping the empty
    edition.
  - Postbuild step copies `editions/recipes/wiki/output/*.html` and
    `editions/recipes/samples/*.json` into `docs/recipes/` on every
    build.  Script is recipe-specific for now; a multi-edition
    wrapper is a follow-up when a second edition appears.
  - [[Tidbits: Edition Contents]] copy updates to reflect that the
    link is real but the host is provisional ("temporary location;
    the editions site will eventually move it").
  - Optional minimal `docs/index.html` linking to the recipe edition
    builds and sample collections.  Skip if it gets in the way — the
    JSON URLs resolve directly without a directory index.


#### Manual steps (outside the build) ####

  - GitHub repo settings → Pages → Source = `main` branch, `/docs`
    folder.  One-time action; record the resulting URL in the config
    tiddler.
  - Decide final sample-collection filename(s) at the same time
    (existing `recipe-tiddlers-us.json` may be renamed for
    public-facing clarity).


#### Out of scope ####

  - Multi-edition `docs/` organization beyond the recipe-only first
    pass.
  - Phone-home delivery of an updated sample-data URL — the config
    tiddler shape enables this; actual wiring is post-1.0.
  - Custom-domain / subdomain configuration.


Effect on Phase 14: the "resolve sample-data download URL" bullet
is satisfied here; Phase 14 needs only a final smoke test that the
URL still resolves.


### Phase 12 — Tier 1 localization ###

Meet edition-design criterion #7 ("localization-friendly: no
hardcoded UI strings or colors") by externalizing the in-template
strings into a single language namespace.  Translators override
language tiddlers, not templates.

Out of scope and deferred to Tier 2: tag-name configurability and
section-heading parsing parameterization (both addressed in Phase
13).  Out of scope and deferred per the [edition design criteria][ed]:
RTL, locale-sensitive numbers, plural rules ("Tier 3").


#### Scope ####

  - Audit pass enumerating every hardcoded UI string in templates,
    buttons, view templates, edit templates, ConfigPanel tabs,
    RemoveDemoContent UI, Recipe Box card empty-state hints, and
    the "All Recipes" filter UI.  Expected: 60–100 keys.
  - Adopt a single namespace (proposed
    `$:/community/recipes/language/<key>`) and the TW `<<lingo>>`
    macro for all string references.
  - Replace every hardcoded string with a macro call.  English
    defaults live under the namespace; overrides are user
    tiddlers with the same title.
  - Add a "Translating Tidbits" subsection to one of the Tidbits
    docs tiddlers explaining what's overridable and what's
    English-by-policy in this tier (tag names; recipe-body section
    headings).
  - Ship one example translation pack as a JSON collection
    alongside the recipe and ingredient samples — covers UI strings
    only, not sample recipe/ingredient content.


### Phase 13 — Tier 2 localization scope review ###

Decision-grade scope estimate for making the load-bearing English
keywords (tag names; recipe-body section headings) translatable.
Output is a written scope note plus a decision: include in 1.0 as
inserted Phase 13.1, or defer to post-1.0.

The criterion is fully met by Tier 1 alone.  Tier 2 is a quality
upgrade — French-edition users would see properly-translated tag
captions and edit recipes with section headings in their language.


#### Outcome ####

**Deferred to post-1.0.**  Full inventory, risk analysis, and
handoff are recorded in
[004-tier2-localization-scope.md][t2].  Headline numbers:

  - ~57 `tag[…]` filter-literal occurrences across 15 source
    files (~35 unique sites after collapsing same-filter pairs)
  - 2 `tags="Recipe"` action-attribute sites
  - 8 `splitregexp[!! …]` section-heading occurrences across 2
    files
  - 5 hardcoded category tag tiddlers per locale
    (Breakfast/Main/Salad/Side/Dessert)
  - 1 awkward AutoComplete trigger filter that may not honour
    transclusions

Tier 1 fully meets criterion #7 (verified in
[003-recipe-edition-verification.md][vf]); v1.1+ picks up Tier 2
with the scope note as design input.  No Phase 13.1 inserted.


#### Activities ####

  - **Tag-name inventory** — count all hardcoded
    `tag[Recipe]` / `tag[Ingredient]` / `tag[Category]` /
    `tag[Favorite]` filter literals across the edition.  The
    existing [`$:/community/recipes/config/RecipeTag`][rt] wires
    only the ViewTemplate and TiddlerIcon cascades; everywhere
    else uses literals (Recipe Box cards, view templates, button
    actions, RemoveDemoContent, the "All Recipes" list, sidebar
    tag tiddlers).  Estimate touch count and difficulty of
    dereferencing each through a config tiddler.
  - **Section-heading inventory** — define
    `$:/community/recipes/config/section-headings` (or similar)
    holding `about`, `ingredients`, `steps` strings; identify
    every consumer (recipe-body view template's splitter, the
    new-recipe template's prefilled headings, any docs that
    reference the literal strings).
  - **Risk surfaces** — Relink behaviour when tag names are
    renamed post-install; AutoComplete trigger filters that may
    be locked to specific tag literals; sample-content alignment
    for translated content collections (e.g., the empty edition's
    `Breakfast` / `Main` / `Salad` / `Side` / `Dessert` category
    tag tiddlers need locale-appropriate counterparts in any
    localized content collection); migration path for wikis
    populated in English before switching language.
  - **Decision** — record outcome in this plan: insert
    Phase 13.1 with implementation tasks, or move Tier 2 to a
    post-1.0 phase and document the handoff.


### Phase 14 — Release 1.0 ###

  - Smoke-test that the sample-data URL set in Phase 11a still
    resolves.
  - Final docs sweep (any deferred copy fixes; word-count target).
  - Bump `$:/community/recipes/version` and `package.json` to
    1.0.0.
  - Final smoke test against current TW core and against the
    recorded `min-tw-core` floor.
  - Tag and publish both artifacts (`tidbits_empty.html`,
    `tidbits.html`) plus the example translation pack from
    Phase 12.


  [ac]:   https://evidentlycube.github.io/TW5-PluginShowcase/#Auto%20Complete
  [arch]: ../architecture/
  [ed]:   ../architecture/001-edition-design.md
  [mp]:   https://maple.tiddlyhost.com/
  [pr]:   ../prompts/002-recipe-edition
  [pz]:   https://przepisy.tiddlyhost.com/
  [rd]:   ../architecture/002-recipe-design.md
  [rl]:   https://flibbles.github.io/tw5-relink/
  [rt]:   ../../editions/recipes/wiki/tiddlers/$__community_recipes_config_RecipeTag.tid
  [samp]: ../../editions/recipes/samples/
  [sk]:   ../../editions/recipes/wiki/
  [t2]:   ../architecture/004-tier2-localization-scope.md
  [vf]:   ../architecture/003-recipe-edition-verification.md
  [t1]:   https://talk.tiddlywiki.org/t/8593
  [t2]:   https://talk.tiddlywiki.org/t/8618
  [t3]:   https://talk.tiddlywiki.org/t/8742
  [t4]:   https://talk.tiddlywiki.org/t/8743

