The builder's "Capacity" field and "0/15" counter don't say what they count #140

What happens

When an organizer edits a slot in the builder, the number they set is labelled Capacity, with a ∞ placeholder and no helper text (SlotEditor in src/components/build-wysiwyg/SlotEditor.tsx). The collapsed slot row then shows a bare counter like 0/15 (WysiwygSlot.tsx).

Organizers don't know what the number means. In user testing, one wasn't sure what the capacity setting was for. Another set 15, then stalled on "0/15", unsure whether 15 was a quantity of items or a number of people. This is in the core flow, so it hits almost every signup.

The rest of the product already uses one word for this, spots:

• Public page: the sign-up sheet's box is labelled "Spots", and rows say "2 left" (screen readers hear "2 of 4 spots left"), from capacityLabel in src/app/s/[slug]/slot-format.ts.
• Help: create-and-publish-a-signup explains "Each slot has one or more spots. A person can take one spot or several", then tells the organizer to type a number "In Capacity".

So the builder is the odd one out.

Already fixed since this was filed: the counter used to show a hard-coded 0. The builder page now loads real counts (loadCommittedBySlotForOrganizer, passed down as committedBySlot / taken), so that part is done (#376). Only the wording is left.

Fix, in outline

• Rename the field to "Spots" in SlotEditor: the visible label and its aria-label.
• Add one line of helper text under the input: "How many places people can take. Leave blank for no limit." Tie it to the input with aria-describedby so screen readers read it too.
• Placeholder: replace ∞ with "No limit", so a blank field says what it means.
• Counter on the collapsed row in WysiwygSlot:
  • a slot with a limit: "2 of 15 taken" instead of "2/15"
  • an unlimited slot: "4 taken" instead of "4/∞"
  • The organizer side counts spots taken, on purpose: organizers want to know how many signed up. The public page counts spots left (The slot list and the sign-up sheet count places in opposite directions #405). Don't change the public page.
• Keep the internal names (capacity, onSetCapacity, the DB column, the MCP tools' capacity argument) as they are. This is a wording change on screen only.

Watch for

• Help page: src/help/articles/create-and-publish-a-signup.tsx says "In Capacity, type how many spots this slot has". Change capacity: 'Capacity' in create-and-publish-a-signup.ui.ts to 'Spots', update the step text and the screenshot's alt text, and check the walkthrough tests/e2e/help/create-and-publish-a-signup.spec.ts still finds the field by its UI name. Re-take screenshots with pnpm help:screenshots. Follow .claude/skills/help-pages/SKILL.md.
• Tests that pin the old text: SlotEditor.test.tsx (getByLabelText('Capacity')), WysiwygSlot.test.tsx and BuildWysiwyg.test.tsx ('0/2', '4/∞', '3/3'). Update them to the new text; don't delete the cases.
• Row width on a phone: "12 of 15 taken" is longer than "12/15" and sits beside the slot's anchor and summary, which already truncate. Check a slot with a long first value at 390px wide: the counter must stay whole and the anchor should still show something.
• Editor width: the helper line sits under a narrow (w-20) input in a flex column. Let it wrap under the input rather than widening the editor grid.
• Let organizers set a per-person spot limit in the web app #315 (per-person spot limit) will add a "Spots per person" control later. It isn't blocked by this and doesn't block it, but this change sets the word it should reuse.
• Put a refused cell edit back in the builder, and stop text values at the field's length #544 (pending merge) touches one line of SlotEditor.tsx. Whichever lands second has a small merge.
• CHANGELOG: add a line, as other UX changes do.
• No trust-doc changes: nothing stored or sent changes.

Done when

• The builder's slot editor labels the field "Spots", shows the helper line and the "No limit" placeholder, and screen readers get the helper text.
• A collapsed slot row reads "N of M taken", or "N taken" for an unlimited slot.
• Component tests cover both counter forms and the new label.
• The help article, its UI list, walkthrough and screenshots match the screen.
• pnpm lint && pnpm typecheck && pnpm knip && pnpm test pass, and the help walkthrough passes.

From user-testing notes. Re-checked against main at ac4ef66: the hard-coded 0 is gone, the wording problem is still there, and the choices above were settled so it can be built. https://claude.ai/code/session_01HZGUDzm1zaihMLwRHJq8L3