The app

What merging the four prototypes found

• Three of them each kept their own Events list, and the ids disagreed. e1 was "Late-summer supper club" in the money prototype and "Spring supper club" in the core-loop one. Merged onto one list of five, which is why an Event now has a venue and a budget and a loadout at the same time.
• The money prototype had fabricated venues. Three of them, invented so the Timezones screen had something to count, because the real Venue records lived in a different prototype. That screen was teaching something slightly false.
• Eight identifiers were defined twice. Four — dateLabel, emptyCard, fieldError, clearError — were byte-identical copies of the same helper. The rest were per-destination state pretending to be shared.
• Two different "event detail" screens exist and neither knew about the other. The core loop's shows guests, pax and attendance; money's shows budget, spend and profit. Open question: is that one screen with two sections, or two screens? Nothing forces the answer yet, and the merge is what made the question visible.
  Half answered 2026-08-13: the money plan — planned budget and expected revenue — now lives on the Event, and actual income, expense and profit stay on Money. What is still open is whether those actuals should also appear there.
• The Venues screen was wrong in three ways and was rewritten rather than ported: it hardcoded four timezones, counted events by matching the venue name as a string, and predated the enabled set. It is now where the timezone enabled set is actually consumed — the proof STORY-041 earns its keep.
• Equipment is now reachable from the Event, not only from Inventory. Packing for a night is something you do while looking at the night; going to Inventory and finding the event in a list is the long way round for the commoner case. Both entry points open the same panels — a second "take equipment" flow would drift from the first within a week. Now in STORY-029.
• Marking an item returned asked for its condition on one screen out of three. The loadout panel offered "any damage?"; the "still out" screen never did, and the Event's new section did not either. Two different causes, one lesson.
  The Event section had a hand-rolled copy of the assignment row — the exact drift this merge existed to remove, reintroduced while adding a feature. It now uses the canonical row.
  The "still out" screen had a subtler one: the list is "what has not come back", so a row stops qualifying the instant you tap it and vanishes, taking the unanswered question with it. Just-returned rows now linger until the follow-up is answered or dismissed, and the count excludes them. Found by marking the same item returned from three places and getting three different outcomes — which is only possible to try once the three places are in one prototype.

None of these were visible while the prototypes were separate. Each one looked internally consistent.

What the Calendar found

• The timezone criterion is answered by the data model, not by code. STORY-014 warns that an Event at 00:30 must not land on the previous day. It cannot here: an Event's date is already the calendar day at its Venue — that is how it is stored, and the instant is built from it. So grouping by ev.date is grouping in the Venue's zone. The bug the criterion describes only appears if something converts an instant back to a day with toISOString. Written down because the obvious way to "handle timezones properly" here is to add the very conversion that breaks it.
• The agenda is the screen; the grid is a locator. Intended as the phone's answer to a 390px cell, it turned out to be the primary reading surface at every width — chips truncate to two or three words in a 1100px window with a sidebar, so even on desktop the grid tells you where and the list below tells you what. One list doing both jobs, rather than a phone screen with its own rules.
• The day count sat against the wrong day. Number at one edge of the cell and count at the other put the count hard against the next day's number, and at 390px it read as belonging to that day. Stacked instead. Invisible at desktop width, where the count is hidden entirely — found only by looking at the phone frame.
• Opening an Event from the Calendar returned you to Events. The same disorientation the loadout panel had, so it got the same fix, generalised: a view can now be told where "back" goes, exactly as a panel already could. A Task opened from a day returns to that day.
• Open question: Tasks with no due date. Undated Events have a rail beneath the grid, because an Idea has no date by definition and this screen claims to show everything. A Task with no due date is not a calendar item at all, so it appears nowhere here. Defensible — but it is the same argument, and it currently gets the opposite answer.
• The Event form was missing three fields its own story requires. Organisers, planned budget and expected revenue were all seeded and none could be entered — the figures were readable on the Money screens and settable nowhere, and the criterion that a negative budget is rejected had no field to reject. Added 2026-08-13. Two things fell out of it: the currency picker's enabled-set rule is now shared with the transaction form rather than copied, and the Organiser is plural — the glossary always said "the Member or Members", and the story's singular phrasing would have been built by accident.
• Then the money moved off the form onto the Event itself, as a Budget card between the guest list and Tasks. Putting it on the form was wrong and the prototype is what showed it: the form is where you go to correct a name, so a planning decision sitting behind an "Edit" button was hidden well enough to read as missing entirely — it was reported as missing by someone looking straight at it. Same argument that brought equipment onto the Event: you plan a night's budget while looking at the night. This settles half the open question above — the Event screen owns the money plan, while actual income, expense and profit stay on Money. Estimates belong to the thing being estimated; bookkeeping belongs to the books.
• An event money screen could not show a plan. It derived its currencies from the transactions on the event, so an Event with a budget and nothing spent yet — which is every event, right up until it happens — read "nothing recorded" and never showed its own figures. Invisible until the form could set a budget: every seeded event with one also had transactions, so the two sets were never different. The planning stage now shows the plan, with 0% spent.
• An empty workspace is now a starting state, and it found a lie on the first run. People had one empty card doing two jobs, so a contact book nobody had touched said "No match. Nobody matches that search" — to someone who had not searched for anything. Every other destination already splits those two. Split now, with the search box hidden when there is nothing to search. Reaching that state used to mean a hundred deletions, which is exactly why it had never been looked at.
• Turkish found three bugs that English could not. The search fold lowercased without a locale, so IŞIK could not find ışık — Turkish has two i's and they are different letters, which makes 'I'.toLowerCase() wrong here and right everywhere else. The calendar's month names, weekday names and first-day-of-week were computed once at load, so they stayed English after a language change — locale data, which no translation layer can reach. And the money parser's separators are locale-derived, so 1.234,50 is one thousand in Turkish and malformed in English: the same keystrokes have to mean two different numbers, and now do. None of these are visible with one language installed. ADR-0014.
• Every destination is now built, so the "not prototyped" screen has no instance. The mechanism stays: the next unbuilt destination is one built: false away, and deleting it would delete the thing that keeps a scope boundary visible on screen.

The two numbers

• Guests invited is how many invitations you are managing. People attending is how many bodies are in the room. Forty guests is routinely sixty-something people, and the two drive different decisions — so they are never merged into one figure.
• The count includes Confirmed and Attended. Both: someone who said yes and someone who turned up are equally a head, and the total must not collapse while rows move between the two.
• Invited and Cancelled stay visible but are excluded — you still need to see who has not replied and who dropped out.

What differs between the two

• Secondary surfaces. The event form and a person's record are one element with two homes: a full screen with a back button on the phone, a dialog over the page on desktop, where you would otherwise lose your place halfway down a guest list. Moved, never duplicated — so the two can never disagree about a field or a rule.
• The guest list. Phone stacks each guest into a row; desktop gets a real table with column headers. A table squeezed onto 390px is unreadable, and a stack of cards at 1100px throws away the comparison a table gives for free.
• Navigation is a drawer on the phone and a sidebar on desktop. Back appears before the menu button, and only where there is somewhere to go.

Try this

• New event with a name and nothing else — it saves as an Idea. Ideas are free and never count toward the plan limit.
• Set it straight to Confirmed. It works: no status requires any field. What appears instead is a prompt saying it is Confirmed without a date or a venue, with a button to add them. Guests can still be invited either way.
• The Free limit is the only thing that refuses a status change, and it is a billing rule — cancel or complete the other event and it goes through.
• A time with no date is refused; a date with no time is fine.
• Fill the guest list, then move somebody from Invited to Confirmed and watch both numbers change together.
• Click a guest's name. Their record opens — over the list on desktop, as a screen on the phone. Rename them and the guest list follows, because it never copied the name.
• Delete someone who is on a guest list: refused, and anonymising is offered. Every total survives it.
• Add the same person twice — the second attempt shows them marked Already invited rather than raising an error.
• Set a Pax to 0 or 2.5: refused. Set it to 60: allowed, with a warning — a real party of sixty exists.
• Search andric — it finds Andrić.

Settled here

• No transition guards (EPIC-002 risk 1, resolved 2026-08-10). Every status is reachable from every other and nothing is required to change status. Real planning is not a state machine — an event gets confirmed on a phone call before a room is booked, and a tool that argues with that gets worked around. Missing detail is prompted, never blocked.
• Nothing deletes an event. Cancelled is the only exit, and it keeps the guests and the money attached.

Still unanswered

• Status is a native select per row. Correct and keyboard-operable, but two selects per row is visually heavy at forty guests. Worth a bespoke menu?
• Payment is a flag with no amount — deliberately, so one figure does not live in two places. Does the strip of counts tell you enough on the night?
• Should the guest list have its own filters, or is sorting by status enough?

The question this exists to answer

• The reference workbook tracked valuable kit on one sheet while its companion sheet — the one built to record what went where — held a header, a formula, and zero rows. The team designed the control and could not sustain it by hand.
• So EPIC-006's open question 4 is not about modelling: “if the flow is slower than a text message to a colleague, it fails the same way the sheet did.” That is only answerable by doing it.
• Hence the tap counter in the prototype toolbar. It counts every interaction inside the product — the toolbar itself is excluded — so the flows can be measured rather than argued about.

What it measured

Flow	Taps
Take three items to an event, from the item list	6
Pack down — mark a four-item loadout returned	1
Mark one item returned	1
Typing the same three item names into a message	~20

Three ticks plus event plus confirm is N + 3 for any loadout, and packing down is one. That clears the bar the epic set. The number to defend in review is the +3, not the ticks.

The decisions that make it fast

• Multi-select is the primary path, not a convenience. The whole row is the checkbox target, not a 16px box beside it.
• The selection bar is stuck to the bottom, not the top. On a phone held one-handed the bottom of the screen is the only part the thumb reaches without regripping — and this screen is used standing next to a van.
• Marking something returned is one tap. Capturing condition is offered afterwards, never required. Requiring it is precisely the friction that emptied the original sheet.
• Bulk return is grouped by event, because packing down happens all at once, not item by item.
• Returning is idempotent. A second tap changes nothing — a double-tap on a phone is normal, not an error.

Try this

• Tick three items, Take to an event, confirm. Watch the tap counter. Reset it and try the same loadout from Loadouts → open an event → Add equipment — that path costs one more tap, which is the argument for keeping the item-list entry point.
• Add an item that is already on the chosen loadout: it says so and skips it rather than erroring or duplicating. One assignment per item per event; quantity covers “more than one”.
• Take the Knife roll (marked Lost) to an event. It warns and allows it — you may simply have found it. Then mark it returned: that one asks what condition it came back in, because it cannot come home and stay Lost. Resolves EPIC-006 OQ3.
• Mark any healthy item returned. The condition follow-up appears, phrased as optional, with “Leave it as it is” beside it.
• Try to delete the Speaker: refused, because it is on a loadout. Marking it Lost is offered instead — the record stays, its cost stays in the history, and it can be found again.
• Press Bring everything back. “Nothing is out” reads as a good outcome, in the success tone — not as an error or an absence.
• Look at the two Induction hobs: same name, same cost, same purchase date, one Excellent and one Problematic. Two records, two ids. A quantity field on the item would lose that, which is the modelling decision STORY-028 turns on.
• Look at the Speaker: owner and holder differ. They are equal on almost every other row, which is exactly why the distinction is easy to collapse — and the case where they differ is the whole point of the module. EPIC-006 OQ1.
• The Coffee urn has no cost. It was a gift; cost is optional.
• The Serving ware cost is in JPY. Item cost is money and follows ADR-0005 exactly like a Transaction — same parser, same formatter, digit count from the currency.

Raised by building it — not yet in a story

• “Still out” and “packed for later” are not the same thing. STORY-030 says the screen lists every unreturned assignment. Read literally that files next month's loadout under things to chase. The prototype splits them: kit for an event that has already happened is out; kit for one that has not is a packing list, and the tab's count excludes it. STORY-030 needs this distinction written in.
• There is no record of when kit physically left. Days-out is computed from the event date, which is the only date available — so an item loaded into the van three days early reads as out for three fewer days than it was. Good enough, and worth stating rather than discovering.
• Quantity is on the assignment but not on the item, per STORY-029. The Chafing dish set × 4 is the only honest use of it — an item record that genuinely represents a set. Is “× 4” on an assignment worth the confusion it invites against STORY-028's one-record-per-object rule?
• Nothing links an item to the Transaction that bought it. Both hold a cost, and they will drift. Explicitly out of scope in STORY-028, but the two modules now both exist in prototype and the duplication is visible.

Two bugs worth recording

Presenting a second panel over a first deleted the first from the document. The panel-in-two-homes pattern moves one element between a phone view and the dialog. Presenting swapped the modal slot's contents with replaceChildren(), which does not put the displaced panel anywhere — it drops it. Opening a loadout and then “Add equipment” therefore destroyed the loadout panel, and the next lookup inside it returned null. That is a crash on the one path the whole module is built around. Presenting now returns the current panel to its own home first.

dialog.close() does not fire its close event synchronously — the event is queued. So “dismiss this panel, then immediately present the next one” (which is what confirming a loadout does) races: by the time the queued handler runs, it restores the new panel to its off-screen home and the dialog goes blank. A programmatic dismiss now marks its own close as handled; Escape and the backdrop still fall through, which is the case the handler exists for. The same dismiss/present pattern is in money-flow/ and core-loop/ — it does not currently trigger there, but it is the same latent bug, and the fix should travel with the shell when it is extracted.

Components this found

• Selectable row — whole-row checkbox target with title, meta and a trailing badge. Used by the item list and both pickers.
• Selection bar — bottom-sticky, count on the left, actions on the right, stacking to full-width buttons on a phone.
• Group heading with a bulk action — accent edge, title, meta, and the action pushed to the end.

Tasks — what building it settled

• Journal is not in this product. Decided 2026-08-12, before any of this was built. It is a capability in the reference workbook and dropping it is a deliberate departure, recorded in EPIC-005 and in the epics README rather than left as a silent gap.
• Overdue is the viewer's day. The glossary said the viewer's; the epic and both stories said the Organisation's. One line against three, and the glossary won — a due date is a fact about a person's day, where an event time is a fact about a place. The cost is that two Members in different zones can disagree by one day, and that is accepted.
• One select per row, not two. The guest list left this open — "two selects per row is visually heavy at forty guests". Status changes inline because STORY-026 asks for it; priority is a badge, editable in the panel, because it is set once and rarely revised. At the prototype's density — five to six visible rows — it reads distinctly lighter than the guest list's two selects plus a pax input. But the guest list's question was specifically about forty rows, and this seed never tries forty: suggestive, not settled. Nothing here argues against carrying it to the guest list; it just has not been tried at that count.
• The default hides work nobody owns yet. "Mine and unfinished" hides "Renew the public liability cover" — High priority, Open, one day overdue, assigned to Jo Anderson. An overdue High-priority item is invisible on the default screen purely because it belongs to someone else. The trade cuts both ways: the default exists so nobody reads forty rows to find their own work. Whether it needs a nudge toward unassigned or overdue-but-not-mine work is open — see "Raised by building it" below, which already notes nothing surfaces unowned work.

Try this

• Open Tasks. The overdue row is first and says how late it is in words — the colour is the third signal, not the only one.
• The task due today is not overdue. That boundary is the whole timezone decision.
• Set a due date eighteen months out: warned, not refused, and the button becomes "Save it anyway".
• Set a due date before the start date: refused.
• Open an Event. Its tasks are there, above Equipment, and repeat no event name on their rows. "Add a task" opens the same panel with the event filled in — dismissing returns to the event, not to Tasks. The same task renders identically in both places.
• Switch View as Member. Nothing on this screen changes: Tasks are not an Owner-only capability, and if anything moves, that is a bug.
• Measured with the tap counter: creating a task is 3 taps (New task, click the description field, Save); an inline status change is 1 tap. Two caveats about the counter itself, both pre-existing: it counts the space bar, so a multi-word description inflates the number; and a native <select> popup is drawn outside the page, so picking the option fires no page pointerdown — a status change is two physical actions but registers one.

Raised by building it — not yet in a story

• A third section on the Event screen makes an old question harder to defer. The merge already found two "event detail" screens that did not know about each other — guests and attendance in one, budget and profit in the other. Tasks is now a third. Whether that is one screen with three sections or several screens is still open, and nothing here forces it.
• Nothing surfaces unassigned or unowned work. Every Task has exactly one assignee by design, so "nobody has picked this up" is not expressible. STORY-026's default makes it invisible as well.

What differs between the two

• Navigation. Seven destinations is past what a phone tab bar holds, so the phone gets a drawer behind the menu button. Desktop shows the same list as a persistent sidebar — hiding navigation where there is room to show it costs discovery. Same destinations either way.
• Filtering. Phone gets one toggle, “show completed and cancelled”. Desktop gets multi-select status, venue, relative date range, and sort. Same data and same results — only the controls differ.
• Primary actions go full width on phone, inline on desktop.
• The auth card is the same component at both sizes — it is max-inline-size, so it simply fills a narrow screen.

Try this

• Add sample events (top bar) seeds four events across every status, so the filters and the default view do something visible.
• Note the phone shows 2 of 4 and desktop 4 of 4 — the phone hides completed and cancelled by default.
• Event times show the venue’s zone, with yours alongside only when it differs.

Still unanswered

• The empty workspace is the highest-churn screen. Does “No events yet” give you enough to act on?
• The Free limit appears on a second event. Helpful, or nagging?
• Request to join ends in a waiting state that grants nothing. Clear, or a dead end?

The three figures

• Per-event profit attributes costs to events. Business profit sums everything. Any cost belonging to no particular event lands in the second and not the first, and the two drift apart by exactly that amount, silently. That is the state the reference workbook was in.
• The fix is not to force attribution — Overhead is real. The fix is to show it as a line, so the arithmetic is visible: attributed + overhead = organisation.
• The identity is checked on every render. If it ever failed, the summary withholds all three figures and says so, rather than showing one that is plausible and wrong. Press Break the identity in the prototype toolbar to see that state.
• It holds per currency. Nothing is ever summed across currencies and no exchange rate is applied.

The amount field

• Every amount here is an integer of minor units plus a currency code. Parsing goes string → integer and formatting goes integer → string → Intl. There is no point in the file where a fractional quantity exists to be rounded.
• Decimal places come from the currency. The seed data is EUR (2 digits) and JPY (0) deliberately. Switch the currency on a typed amount and watch 12.50 become invalid rather than silently becoming ¥13.
• Separators come from your locale, not from a guessed regex. The hint under the field shows what your browser thinks 1234.5 looks like.
• Direction carries the sign, so the amount is always positive and a typed minus is refused with an explanation rather than quietly absorbed.

Telling the currencies apart

• The real risk with per-currency figures is not ugliness, it is a reader carrying the EUR total in their head three inches down the page and reading it against JPY. A muted “In EUR” heading is nowhere near enough separation for that.
• So on Dashboard and Summary there is a currency deck: one currency at a time, in a card that names it in 28px with its full name beside it, stepped through with prev/next arrows and a “1 of 2” count.
• The usual objection to a carousel is that it hides things people never find. The answer here is that each control carries that currency's headline total — JPY ¥83,000 on the dashboard, its reconciled organisation profit on the summary. You can see that JPY exists and roughly what it holds without switching to it. It never auto-advances, and arrow keys work.
• The choice follows you between the two tabs. Switching from Dashboard to Summary must never silently put you in a different currency.
• Where two currencies genuinely do belong on one screen — the transactions strip, an event with costs in two — they stay side by side, but the divider gains an accent edge and full text weight instead of being a grey line.
• It scales: a third currency is a third chip, and the strip scrolls.

The dashboard

• A bento grid: the chart takes two columns and two rows, the lead figures take two, the rest take one. It collapses to two columns and then to one, and the spans collapse with it.
• One chart per currency: profit by event. The reader's job is "which nights made money and which lost it", which is polarity — so it is a diverging bar either side of a zero baseline, not five bars all starting from the left edge. Blue and red rather than green and red: they read as opposite without being the one pair red-green colour blindness collapses.
• Colour is never the signal. The side of the baseline carries the sign, every bar is labelled with its own value outside the mark, and a loss is worded. Nothing is lost in greyscale. Each bar is a button that opens that event, and its accessible name carries income, expense and profit in full.
• Budget utilisation is a meter, not a chart — a single ratio against a limit. The track runs to whichever is larger, the limit or the actual, so the JPY overrun shows as length rather than as a bar that has simply stopped.
• Every chart has a table twin — “Show as a table”. The tooltip enhances; it is never the only way to reach a value.
• What is deliberately not charted. Income, expense and profit are three headline numbers, and three headline numbers are a stat tile each — a grouped bar of them would be a chart of nothing. There is no time series either: no date range is in scope, and a trend line over five events would be an invention.

What differs between the two

• Secondary surfaces. The transaction form and an event's money panel are one element with two homes: a full screen with a back button on the phone, a dialog over the page on desktop. Moved, never duplicated.
• The transaction list. Phone stacks each row; desktop gets a real table with column headers, because comparing amounts down a column is the whole job.
• Filtering. Phone gets one control — direction, or overhead only. Desktop gets direction, event, currency and category. Same data, same results.
• The chart's labels. On desktop the event name sits beside its bar; on a phone a 9rem name column would leave the plot about 60px, which is not a chart, so the name moves above the bar and the track takes the full width. The comparison the chart exists for survives — only the layout changes.
• Navigation is a drawer on the phone and a sidebar on desktop, with the same eight destinations as the signup prototype.

Try this

• Record an expense of 0. Refused — a zero row reads as unfinished, and allowing it makes "unfinished" and "genuinely zero" indistinguishable (EPIC-004 OQ2).
• Type -40. Refused, and the message points at the direction control rather than just saying "invalid".
• Enter 12.505 in EUR. Refused rather than rounded — nothing you typed is silently discarded.
• Type 12.50, then switch the currency to JPY. It goes invalid immediately, with the reason.
• Switch Money out to Money in with a category chosen. The category clears and says why — a category belongs to one direction.
• Leave Attributed to an event as Overhead. It saves without complaint, then appears on the Summary tab as its own line.
• On Summary, open See the transactions behind it. Overhead is never an unexplained lump — and one of the rows is income, because nothing requires an unattributed receipt to be a cost.
• On Dashboard, read every basis line. Average profit says over how many events and which are excluded; Budget utilisation names its denominator.
• Press Force a tie. Most profitable shows both events, not an arbitrary first.
• Press Empty it. Counts read zero, no average is attempted, and budget utilisation reads Not set — never 0%.
• Open Tokyo pop-up from the dashboard, then Late-summer supper club. The second has spend in two currencies against a budget in one.
• Delete a category that is in use: refused, with the count. Add ingredients as an expense category: refused as a duplicate of Ingredients. Add it as an income category: allowed — the rule is per direction.

Nothing here is gated

• The workspace is on Free and sees every figure. pricing.md is explicit: no feature gating at launch — financial reporting, inventory, multi-currency and export are all on Free. You pay for scale, not for capability.
• What Free limits is active Events (1), seats (1) and contacts (100). None of those are consumed by anything on these screens, so no limit prompt belongs here.
• The entitlement seam still exists (STORY-033) — a capability is a yes/no lookup that currently answers yes on every tier, so gating something later is a row in the plan catalogue rather than a refactor. It is just never answered no today, and the UI must not pretend otherwise.

Settled here

• Overhead is a separate line, never apportioned across events (EPIC-004 OQ1, resolved 2026-08-10). Every figure stays traceable to rows.
• Zero amounts are refused (EPIC-004 OQ2, resolved 2026-08-10).
• A broken identity is a hard failure, not a caveat. The figures are withheld.
• Every figure states its basis in the UI. A bare number on a dashboard is how a wrong one survives for months.

Raised by building it — not yet in a story

• "Most profitable event" cannot rank across currencies. STORY-024 treats it as one metric; with a EUR event and a JPY event there is no honest single winner without a rate. The prototype shows one per currency. This needs a line in STORY-024.
• An event's budget is one amount in one currency; its spend need not be. Late-summer supper club has EUR and JPY costs against a EUR budget, so its JPY utilisation reads "not set for JPY". STORY-022 does not cover this case.
• STORY-024 lists charts as out of scope. This prototype has one, and it earns its place — it is what makes "most profitable event" and the spread the average sits in legible at a glance. If the chart stays, the story's scope needs amending; if the story is right, the chart comes out. Not decided here.
• Where does the dashboard live? It sits as a tab under Money here to avoid inventing a ninth navigation destination. Its three event-count tiles are not really "money", so the placement is a question, not a decision.
• Editing and deleting a transaction need an actor and timestamp (STORY-020). Nothing in the UI shows that trail yet — is it a per-row history, or an organisation-level audit screen?

Settled by clicking it — now in STORY-041

• The Member hard stop stays. Enabling is Owner-only and there is no inline escape, so a Member who needs an un-enabled currency is stopped twice — they cannot add it, and cannot reach the screen that would. STORY-013 states the opposite principle for venues: that sending someone to settings mid-task loses what they were writing. Walked as a Member here and kept anyway — the everyday list staying genuinely short is worth more than the rare mid-task block. Press “View as Member” to see what was judged.
• Renamed zones needed a small alias map — and it is not the committed list i18n.md forbids. supportedValuesOf('timeZone') lists only one half of each IANA backward pair, and which half is version-dependent: this browser has Asia/Calcutta and not Asia/Kolkata; a newer one reverses it. So “Kolkata” found nothing. Matching the zone's long name does not help either — that is “India Standard Time”.
  Fixed with ~14 pairs applied in both directions, and the row now shows the current city name with the identifier beside it: heading a Kolkata search with “Calcutta” makes a user doubt they found the right place. Try kolkata, calcutta, kyiv, kiev, yangon. The map is presentation only — the stored value is always the runtime's own identifier, and every zone stays selectable whether or not it appears in it.

Components this found

• Figure — label, value, and basis. Used by every tile, every total, and every reconciliation row. The most reused thing in the flow and the one most worth promoting into design/components/.
• Money input — amount plus currency as one control, with currency-derived precision. STORY-020 calls it "the highest-risk field in the product".
• Segmented radio group — real radios in a fieldset, used for Direction here and reusable wherever a choice is binary and worth showing both sides of.
• Diverging bar and meter — the two chart forms this product actually needs. Both are plain HTML and CSS with no library, and both are theme-aware because every value is a token.
• Currency deck — the switcher plus its card. Its one real idea is that the controls carry each option's headline figure, so nothing is hidden by being off-screen. Reusable anywhere one of several parallel sets of figures must be read without being confused for another.

Two chart-spec deviations, on purpose

• No 48px hero figure. The type ladder tops out at 36px and design.md rejects off-scale values, so the lead tiles use 28px and the emphasis comes from the grid instead. Rules outrank a skill.
• The meter's unfilled track is the neutral sunken surface, not a lighter step of the fill's own hue. There is no light accent step among the semantic tokens, and reaching into the private palette is forbidden.

Both mark colours were measured, not eyeballed: --color-accent is 4.62:1 light / 7.13:1 dark against the card, --color-danger 5.44 / 7.48, and the zero baseline in --color-border-strong 3.23 / 3.01 — all clear of the 3:1 floor for a meaningful boundary.