@mccaskie-labs/workbench-config 0.2.5 → 0.3.1

package/CHANGELOG.md

@@ -1,5 +1,17 @@
 # @mccaskie-labs/workbench-config
 
+## 0.3.1
+
+### Patch Changes
+
+- A new component, `availability` (workbench-availability: quotes, the bookings store and the tap-to-block calendar), with its client questions (what is booked, how it is booked in a day, event types, holidays, holds). The country manifest gains holidays (`holidaysFor`, `checkHolidays`) and the December probe `country.holidays`.
+
+## 0.3.0
+
+### Minor Changes
+
+- Every component now ships its client questions: email (which emails, where replies go, drafts of the wording), inbound email (which addresses, attachments), strings (other languages) and the database (what to store and who sees it). `OFFER_PENDING` is removed, and so is `delivery.when`: a component's `offer.when` says when its tool applies, and a manifest with neither `offer` nor `no_offer` fails the checks.
+
 ## 0.2.5
 
 ### Patch Changes

package/capabilities/availability.json

@@ -0,0 +1,263 @@
+{
+  "$schema": "./schema.json",
+  "format": 1,
+  "component": "availability",
+  "title": "Availability and pricing",
+  "summary": "workbench-availability answers \"is this date free, and what does it cost?\" for a bookable thing (a venue, a room, a photographer's day) from its calendar and its price rules, with the same answer every time and one plain line per rule applied. A store over the app's own database stops two bookings landing on one date, and a tap-to-block calendar lets the owner close dates from a phone. It runs in the app itself, with no Gateway call, no AI and no cost.",
+  "status": "built",
+  "delivery": {
+    "choice": "optional",
+    "intro": "Which dates are free and what each costs, worked out the same way every time, with a calendar the owner taps to block dates."
+  },
+  "surfaces": {
+    "package": [
+      "quote",
+      "createAvailability",
+      "availabilityMigration",
+      "calendarAction",
+      "checkSettings",
+      "stayClaims",
+      "staysClash",
+      "todayIn",
+      "AvailabilityError"
+    ]
+  },
+  "rules": [
+    {
+      "id": "availability.quote-is-fact",
+      "kind": "must",
+      "text": "Take every availability answer and price the app shows or sends from quote() (or createAvailability's quote), and pass its lines and explain on as facts. Never let AI work out a price or a free date, and never write a price into a page or prompt by hand.",
+      "enforced_by": "review",
+      "probe": "availability.quote"
+    },
+    {
+      "id": "availability.book-through-block",
+      "kind": "must",
+      "text": "Book, hold and block dates only through createAvailability's block(), which runs availability_block() in one transaction: never insert into availability_blocks directly, so the exclusion constraint and the hold expiry always apply.",
+      "enforced_by": "database",
+      "probe": "availability.store"
+    },
+    {
+      "id": "availability.calendar-days",
+      "kind": "must",
+      "text": "Treat dates as calendar days (YYYY-MM-DD) in the account's time zone: pass todayIn(timeZone) as today, never new Date() in UTC.",
+      "enforced_by": "types",
+      "probe": "availability.quote"
+    },
+    {
+      "id": "availability.no-names-in-notes",
+      "kind": "must_not",
+      "text": "Write a guest's name or phone number into a block's note: link the app's own booking in subject instead. The .ics feed carries neither.",
+      "enforced_by": "review",
+      "probe": "availability.store"
+    },
+    {
+      "id": "availability.public-gets-the-quote",
+      "kind": "must_not",
+      "text": "Let a public page or the anonymous key read availability_blocks: public pages get the finished quote from the server.",
+      "enforced_by": "database",
+      "probe": "availability.store"
+    },
+    {
+      "id": "availability.daily-cleanup",
+      "kind": "must",
+      "text": "Run createAvailability's cleanup() once a day from the app's cron with the service client, so lapsed holds show as expired and old blocks are deleted on time.",
+      "enforced_by": "review",
+      "probe": "availability.store"
+    },
+    {
+      "id": "availability.calendar-as-shipped",
+      "kind": "must",
+      "text": "Draw the owner's calendar with renderCalendar and CALENDAR_SCRIPT (under the page's nonce), and hand the posted body to calendarAction behind the owner's sign-in. Never hand-write the calendar's markup or script.",
+      "enforced_by": "review",
+      "probe": "availability.calendar"
+    }
+  ],
+  "examples": [
+    {
+      "id": "availability.example.quote",
+      "title": "Answer \"is 12 Dec free, and how much?\"",
+      "lang": "ts",
+      "probe": "availability.quote",
+      "code": "import { createAvailability } from '@mccaskie-labs/workbench-availability'\nimport settings from '../workbench/availability.json'\n\nconst av = createAvailability({ db: serviceClient, account: venue.id, settings, country: 'PH', timeZone: 'Asia/Manila' })\nconst q = await av.quote({ resource: 'villa-sol-pool', date: '2026-12-12', stay: 'day_use', guests: { min: 15, max: 15 }, eventType: 'birthday' })\n// q.available 'yes'; q.options[0].total { amount: '9500.00', currency: 'PHP' }; q.explain ['Weekend day use: ₱9,500 (rule r-weekend)', ...]"
+    },
+    {
+      "id": "availability.example.calendar",
+      "title": "The owner's tap-to-block calendar",
+      "lang": "ts",
+      "probe": "availability.calendar",
+      "code": "import { calendarAction } from '@mccaskie-labs/workbench-availability'\nimport { CALENDAR_SCRIPT, renderCalendar } from '@mccaskie-labs/workbench-availability/calendar'\n\nconst days = await av.month('villa-sol-pool', '2026-12')\nconst html = renderCalendar(days, t, { resource: 'villa-sol-pool', month: '2026-12', endpoint: '/owner/calendar', stays: [{ id: 'day_use', label: t('ui.stay.day_use')! }] })\n// The page adds <script nonce=...>${CALENDAR_SCRIPT}</script>; POST /owner/calendar (owner signed in):\nconst r = await calendarAction(av, await request.json())\nreturn Response.json(r.body, { status: r.status })"
+    }
+  ],
+  "probes": [
+    {
+      "id": "availability.quote",
+      "half": "runtime",
+      "expect": "pass",
+      "smoke": true,
+      "cost_hint_usd": 0,
+      "note": "In the Worker itself: quote() on the spec's HmPo example (Sat 12 Dec ₱9,500, Sat 19 Dec ₱10,925 with peak, 25 guests ₱10,250 over capacity, no guests a from price) and the alternatives when 19 Dec is booked; no database, no Gateway call"
+    },
+    {
+      "id": "availability.store",
+      "half": "runtime",
+      "expect": "pass",
+      "cost_hint_usd": 0,
+      "note": "Against the probe app's own database: two block(booked) calls for one night at once (one lands, one refused as clash), a lapsed hold quoted free and marked expired by cleanup(), another account's resource unreachable, then every probe block removed"
+    },
+    {
+      "id": "availability.calendar",
+      "half": "runtime",
+      "expect": "pass",
+      "cost_hint_usd": 0,
+      "note": "The probe page draws a month with renderCalendar and CALENDAR_SCRIPT: tap, Block day, Undo leaves no block; a change made offline shows \"1 change waiting\" and is sent on reconnect"
+    }
+  ],
+  "styles": {
+    "prefix": "wb-cal-"
+  },
+  "offer": {
+    "pattern": "settings",
+    "when": "The client takes bookings for something with dates: a venue, a room, a resort day pass, a photographer's or hire business's days, or wants prices that depend on the day, season, holiday, number of guests or kind of event, or wants a calendar to block dates.",
+    "say": "I'll set this up with Workbench availability, so every price and free date comes out the same way each time, explained line by line, and you get a calendar to block dates from your phone. Here's how a business like yours usually books; tell me what to change.",
+    "answers_file": "workbench/availability.json",
+    "answers_format": "`{ \"format\": 1, \"status\": \"draft\" | \"done\", \"what\": \"<the client's words>\", \"stay_types\": [{ \"id\", \"start\", \"end\", \"clashes\" }], \"event_types\": [...], \"currency\": \"PHP\", \"alternatives\": { \"count\": 3, \"within_days\": 21 }, \"hold_days\": 3, \"holidays\": \"weekend\" | \"weekday\" | \"separate\" }`. Every stay type clashes with itself; list each pair that can't share a date on both sides. Take `currency` from workbench/country.json. checkSettings() reads this file at startup and names every problem. Each account's resources, packages and price rules are data in the app's database (availability_resources, availability_packages, availability_price_rules), entered on the owner's pages, never in this file. Copy availabilityMigration into supabase/migrations with its down file, and CALENDAR_WORDS into the strings catalogue.",
+    "needs": ["country"],
+    "questions": [
+      {
+        "id": "availability.what",
+        "sets": "availability.what",
+        "ask": "What do people book?",
+        "style": "table",
+        "must_ask": true,
+        "other": {
+          "kind": "text",
+          "min": 3,
+          "max": 200,
+          "description": "In the client's words, such as \"a resort's pool and function hall\" or \"me, as a photographer, by the half or full day\"."
+        },
+        "note": "Only the client knows. Their answer names the resources (one per thing booked separately) and suggests the stay types to propose next."
+      },
+      {
+        "id": "availability.stays",
+        "sets": "availability.stay_types",
+        "ask": "Here are the usual ways it's booked in a day, with their hours and which can't share a date. Accept them, change some, or add or remove?",
+        "style": "table",
+        "must_ask": true,
+        "other": {
+          "kind": "list",
+          "min": 1,
+          "max": 10,
+          "description": "Each way it's booked, with its start and end time and the others it can't share a date with."
+        },
+        "note": "Propose from the client's answer to availability.what. A resort or venue: day use 08:00 to 17:00, night use 19:00 to 07:00, overnight 14:00 to 12:00 the next day (overnight clashes with both; day and night use don't clash with each other). A photographer or hire business: half day and full day, clashing with each other. One room or slot a day: a single stay type."
+      },
+      {
+        "id": "availability.events",
+        "sets": "availability.event_types",
+        "ask": "Should prices depend on the kind of event? Here is the usual list.",
+        "style": "cards",
+        "answers": [
+          {
+            "label": "Yes, use this list",
+            "value": "list",
+            "means": "Birthday, debut, wedding, baptism, reunion, team building, other: a rule can add a fee for some of them."
+          },
+          {
+            "label": "No, same price for all",
+            "value": "none",
+            "means": "No event types; the quote never asks for one."
+          },
+          {
+            "label": "Yes, with my own list",
+            "value": "own",
+            "means": "Type the kinds of event the business prices differently."
+          }
+        ],
+        "other": {
+          "kind": "list",
+          "min": 1,
+          "max": 20,
+          "description": "The kinds of event, each a short name."
+        },
+        "note": "Recommend the usual list for venues and resorts; \"none\" for most other businesses. Write ids in lower case with underscores (team_building)."
+      },
+      {
+        "id": "availability.holidays",
+        "sets": "availability.holidays",
+        "ask": "Should holidays be priced like weekends?",
+        "style": "cards",
+        "answers": [
+          {
+            "label": "Yes, like a weekend",
+            "value": "weekend",
+            "means": "A regular holiday or special non-working day on a weekday costs the weekend price."
+          },
+          {
+            "label": "No, by the day of the week",
+            "value": "weekday",
+            "means": "Holidays cost what their day of the week costs."
+          },
+          {
+            "label": "Set holiday prices separately",
+            "value": "separate",
+            "means": "Holidays get their own price rules, entered on the owner's pages."
+          }
+        ],
+        "other": {
+          "kind": "text",
+          "min": 3,
+          "max": 200,
+          "description": "How holidays should be priced, in the client's words."
+        },
+        "note": "Holidays come from workbench-country's yearly list (the Philippines' proclamation each year); a local fiesta goes in the availability_holidays table. Special working days (the EDSA anniversary) are never priced as holidays."
+      },
+      {
+        "id": "availability.holds",
+        "sets": "availability.hold_days",
+        "ask": "How long is a date held while waiting for a deposit?",
+        "style": "cards",
+        "answers": [
+          {
+            "label": "3 days",
+            "value": 3,
+            "means": "The date shows as held (H) for 3 days, then is free again unless marked booked."
+          },
+          {
+            "label": "1 day",
+            "value": 1
+          },
+          {
+            "label": "7 days",
+            "value": 7
+          },
+          {
+            "label": "No holds",
+            "value": 0,
+            "means": "A date is free until it is booked; nothing is held."
+          }
+        ],
+        "other": {
+          "kind": "whole",
+          "min": 0,
+          "max": 60,
+          "description": "Days, 0 to 60."
+        }
+      }
+    ],
+    "not_asked": [
+      {
+        "sets": "availability.prices",
+        "why": "Each account's prices, packages and rules change often, so they are data the owner enters on their own pages (or that onboarding reads from their rate card), not project settings."
+      },
+      {
+        "sets": "availability.alternatives",
+        "why": "Up to 3 nearest free dates within 21 days, same weekday first, suits every business so far; change it in the answers file if a client asks."
+      },
+      {
+        "sets": "availability.currency",
+        "why": "It is the country's own, from workbench/country.json."
+      }
+    ]
+  }
+}

package/capabilities/country.json

@@ -25,7 +25,11 @@
       "currencySymbol",
       "currencySymbolFrom",
       "WORLDWIDE",
-      "isWorldwide"
+      "isWorldwide",
+      "HOLIDAYS",
+      "holidaysFor",
+      "holidayOn",
+      "checkHolidays"
     ]
   },
   "rules": [
@@ -50,6 +54,13 @@
       "enforced_by": "types",
       "probe": "country.packs"
     },
+    {
+      "id": "country.holidays-from-proclamation",
+      "kind": "must",
+      "text": "Take public holidays from holidaysFor or holidayOn, never worked out or guessed: a year with no list returns undefined, and checkHolidays fails from 1 December until next year's list is in.",
+      "enforced_by": "review",
+      "probe": "country.holidays"
+    },
     {
       "id": "country.spelling-from-pack",
       "kind": "must",
@@ -82,6 +93,14 @@
       "expect": "pass",
       "cost_hint_usd": 0,
       "note": "Every pack's spelling is one the Gateway accepts (en-PH, en-AU, en-GB, en-US), checked against the ai manifest's spellings; no Gateway call"
+    },
+    {
+      "id": "country.holidays",
+      "half": "runtime",
+      "expect": "pass",
+      "smoke": true,
+      "cost_hint_usd": 0,
+      "note": "The December probe: checkHolidays for every country with a built-in list, on today in that country's time zone. Fails when this year's list is missing, and from 1 December when next year's is, so the list is added from the proclamation before January's prices need it"
     }
   ],
   "offer": {

package/capabilities/database.json

@@ -7,8 +7,7 @@
   "status": "built",
   "delivery": {
     "choice": "built_in",
-    "intro": "The app's own database, one for testing and one for the live site.",
-    "when": "The app needs to store or read data, or the client asks for a change to what is stored: a new table, column, rule or migration."
+    "intro": "The app's own database, one for testing and one for the live site."
   },
   "surfaces": {
     "package": [
@@ -237,5 +236,35 @@
       "cost_hint_usd": 0,
       "note": "On a project's staging: cf_turnstile_widget_create and the turnstile_sitekey and turnstile_secret sources; the sign-in page shows the check, /auth/code without a passed token sends no code, and with one it does"
     }
-  ]
+  ],
+  "offer": {
+    "pattern": "settings",
+    "when": "The app needs to store or read data, or the client asks for a change to what is stored: a new table, column, rule or migration.",
+    "say": "The app's data goes in its own Workbench database, one for testing and one for the live site. I'll propose what to store and who can see it, and change it with a migration you can undo.",
+    "answers_file": "workbench/database.json",
+    "answers_format": "`{ \"format\": 1, \"status\": \"draft\", \"tables\": [{ \"name\": \"orders\", \"row\": \"one order\", \"columns\": [{ \"name\": \"total\", \"kind\": \"money\", \"required\": true }], \"read\": \"own\", \"change\": \"own\" }] }`. Then write one migration (`supabase/migrations/<14 digits>_<name>.sql`) with its down file, turning on row-level security with one policy per answer, apply it on staging with Workbench Control (`sb_migration_apply`), and refresh `supabase/staging-columns.json`.",
+    "questions": [
+      {
+        "id": "database.tables",
+        "sets": "tables",
+        "ask": "What should the app store, and who can see and change it?",
+        "style": "table",
+        "note": "Propose the tables the request needs, each with what one row is, its columns (name, kind such as text, number, money, date, yes/no, a link to another table; and whether it is required), and who may read and who may change its rows: `own` (the person who made the row), `admins`, `signed_in` (anyone signed in) or `public` (anyone, read only). Recommend `own` for anything about a person. Show money as whole cents, never a fraction. The client accepts, removes or adds tables and columns."
+      }
+    ],
+    "not_asked": [
+      {
+        "sets": "keys",
+        "why": "The app reaches the database as the signed-in person (`dbAs`), so row-level security decides what each person sees; the template holds no secret key."
+      },
+      {
+        "sets": "hosting",
+        "why": "Each project has its own staging and production databases, made by Workbench Control in the region set for the install."
+      },
+      {
+        "sets": "sign_in_settings",
+        "why": "The database's sign-in settings follow the Workbench baseline (the workbench-sign-in skill)."
+      }
+    ]
+  }
 }

package/capabilities/email-inbound.json

@@ -7,8 +7,7 @@
   "status": "built",
   "delivery": {
     "choice": "optional",
-    "intro": "Receiving email at the project's own addresses, for the app to act on.",
-    "when": "The client wants the app to receive email: replies to its messages, or an address such as hello@ that the app handles."
+    "intro": "Receiving email at the project's own addresses, for the app to act on."
   },
   "surfaces": {
     "tools": [
@@ -129,5 +128,50 @@
       "two_step": true,
       "note": "cf_email_routing_rule_delete returns a confirmation and changes nothing until Robert approves"
     }
-  ]
+  ],
+  "offer": {
+    "pattern": "switch_on",
+    "when": "The client wants the app to receive email: replies to its messages, or an address such as hello@ that the app handles.",
+    "say": "The project can already receive email with Workbench inbound email: each address goes straight to the app, which decides what to do with every message. I'll switch on the addresses you want.",
+    "answers_file": "workbench/email-inbound.json",
+    "answers_format": "`{ \"format\": 1, \"addresses\": [{ \"name\": \"hello\", \"does\": \"saves it as a message the admins see\" }] }`. Then set `INBOUND_EMAIL` to `\"on\"` in `wrangler.jsonc`, write `handleEmail` in `src/app.ts` to do what each address `does`, and make the addresses with Workbench Control: `cf_email_routing_enable`, then `cf_email_routing_rule_create` for each address on staging first (the capabilities guide below has the steps).",
+    "questions": [
+      {
+        "id": "email-inbound.addresses",
+        "sets": "addresses",
+        "ask": "Which addresses should the app receive, and what should it do with each message?",
+        "style": "table",
+        "note": "Propose the addresses the request needs, each with its name (the part before @, lower case: `hello`, `bookings`) and what the app does with a message, in the client's words: save it for the admins to read, add it to a booking, answer it automatically. One address, one job. Say plainly that the app reads the mail itself: nothing is forwarded to anyone's inbox."
+      },
+      {
+        "id": "email-inbound.attachments",
+        "sets": "attachments",
+        "ask": "What should happen to files attached to these emails?",
+        "style": "cards",
+        "answers": [
+          {
+            "label": "Leave them out",
+            "value": "drop",
+            "means": "The app keeps the words of each email, not its files. Nothing extra to store or check."
+          },
+          {
+            "label": "Keep them",
+            "value": "keep",
+            "means": "The app stores each file for the admins. Files can be large or unsafe, so keep only the types the job needs."
+          }
+        ],
+        "note": "With keep, ask which types (photos, PDFs) and store them outside the Worker, in file storage the app already has, or ask the owner before adding some; refuse other types with `reject`."
+      }
+    ],
+    "not_asked": [
+      {
+        "sets": "domain",
+        "why": "Addresses are on the project's own email domain: its staging name first, and the client's own domain once it is attached for production (`cf_zone_attach`)."
+      },
+      {
+        "sets": "forwarding",
+        "why": "Workbench never forwards mail outside the project or catches every address: each literal address goes to the app."
+      }
+    ]
+  }
 }

package/capabilities/email.json

@@ -7,8 +7,7 @@
   "status": "built",
   "delivery": {
     "choice": "built_in",
-    "intro": "The emails the app sends, such as confirmations, receipts and sign-in codes.",
-    "when": "The app needs to send an email: a confirmation, receipt, notification, invitation or sign-in code."
+    "intro": "The emails the app sends, such as confirmations, receipts and sign-in codes."
   },
   "surfaces": {
     "gateway": ["POST /v1/email/send"],
@@ -71,5 +70,70 @@
   ],
   "styles": {
     "prefix": "wb-email-"
+  },
+  "offer": {
+    "pattern": "settings",
+    "when": "The app needs to send an email: a confirmation, receipt, notification, invitation or sign-in code.",
+    "say": "I'll send these with Workbench email, which sends from the app's own address in your brand, with no email key in the app. The sign-in codes are already there; I'll add yours beside them.",
+    "answers_file": "workbench/email.json",
+    "answers_format": "`{ \"format\": 1, \"status\": \"draft\", \"reply_to\": null, \"emails\": [{ \"id\": \"order_confirmed\", \"when\": \"a customer sends an order\", \"to\": \"the customer\", \"parts\": [\"heading\", \"paragraph\", \"button\"], \"link_changes_something\": false }] }`. Declare each email in `src/lib/emails.ts` with `defineEmails` (stream `transactional`, shell `account`, `decidedBy` naming this answers file), put its words in the strings under `email.<id>.<key>`, and send it with `mailerFor(env)` and an `idempotencyKey` whenever a retry could repeat it.",
+    "questions": [
+      {
+        "id": "email.emails",
+        "sets": "emails",
+        "ask": "Which emails should the app send?",
+        "style": "table",
+        "note": "Propose the emails the request needs, each with an id (snake_case: `order_confirmed`), when it is sent, who gets it, its parts in order (heading, paragraphs, a button and its link, small print) and whether its link changes something (then the link lands on a confirmation page first). Only emails a person's own action or account causes: receipts, confirmations, notices. The client accepts, removes or adds. The wording is drafted afterwards, one email at a time."
+      },
+      {
+        "id": "email.reply-to",
+        "sets": "reply_to",
+        "ask": "Where should a reply to these emails go?",
+        "style": "cards",
+        "answers": [
+          {
+            "label": "Nowhere",
+            "value": null,
+            "means": "The emails come from an address that isn't read. Say so in the small print, with where to get help instead."
+          },
+          {
+            "label": "To the app",
+            "value": "app",
+            "means": "Replies go to an address the app reads itself (Workbench inbound email)."
+          }
+        ],
+        "other": {
+          "kind": "text",
+          "min": 6,
+          "max": 254,
+          "description": "An email address someone at the business reads."
+        },
+        "must_ask": true,
+        "note": "A typed address goes in each send as `replyTo`; check it looks like an email address. With the app, the workbench-email-inbound skill sets up the address."
+      }
+    ],
+    "not_asked": [
+      {
+        "sets": "sender",
+        "why": "Emails come from the project's own sending address (`FROM` in `src/lib/email.ts`) on its own domain, which Workbench Control sets up."
+      },
+      {
+        "sets": "marketing",
+        "why": "Only transactional email exists: newsletters and other bulk mail are refused until Workbench has a sender for them, so offer none."
+      },
+      {
+        "sets": "look",
+        "why": "Emails take the brand's name, colour and logo, and the project's `project.css` (see Restyling)."
+      }
+    ],
+    "drafts": {
+      "of": "wording for one email",
+      "surface": "ai",
+      "alias": "claude-default",
+      "count": 3,
+      "max_rounds": 3,
+      "job": "ai.drafts",
+      "command": "npx workbench-ai drafts text email_<id> --about \"<what the email is for, who gets it and its parts>\""
+    }
   }
 }

package/capabilities/schema.json

@@ -35,7 +35,8 @@
         "strings",
         "ui",
         "forms",
-        "sign-in"
+        "sign-in",
+        "availability"
       ]
     },
     "title": {
@@ -430,7 +431,8 @@
           "strings",
           "ui",
           "forms",
-          "sign-in"
+          "sign-in",
+          "availability"
         ]
       }
     },
@@ -745,10 +747,6 @@
           "type": "string",
           "minLength": 1,
           "maxLength": 160
-        },
-        "when": {
-          "type": "string",
-          "minLength": 1
         }
       },
       "required": [

package/capabilities/strings.json

@@ -7,8 +7,7 @@
   "status": "built",
   "delivery": {
     "choice": "built_in",
-    "intro": "The words on the app's screens and in its emails, kept in one place for each language.",
-    "when": "The client wants to add or change wording on a page or in an email, or asks about showing the app in another language."
+    "intro": "The words on the app's screens and in its emails, kept in one place for each language."
   },
   "surfaces": {
     "package": [
@@ -132,5 +131,49 @@
       "cost_hint_usd": 0,
       "note": "The app's own checkStrings run passes in its tests, and npx workbench-strings check passes in CI"
     }
-  ]
+  ],
+  "offer": {
+    "pattern": "project",
+    "when": "The client wants to add or change wording on a page or in an email, or asks about showing the app in another language.",
+    "say": "Every word the app shows is kept in one place with Workbench strings, so changing wording never means hunting through code, and other languages can be added later.",
+    "answers_file": "workbench/strings.json",
+    "answers_format": "`{ \"format\": 1, \"languages\": [\"en-AU\"], \"later\": [\"fil\"] }`: the language the site is written in first, and any the client wants later. New wording goes into `strings/strings.<base>.json` with one key per sentence, and `npm run check:strings` checks it.",
+    "questions": [
+      {
+        "id": "strings.languages",
+        "sets": "languages",
+        "ask": "Does the site need to be in any language besides English?",
+        "style": "cards",
+        "answers": [
+          {
+            "label": "English only",
+            "value": "none",
+            "means": "Every page and email is in English."
+          },
+          {
+            "label": "Another language later",
+            "value": "later",
+            "means": "English now. The words are kept so a translation can be added, checked by a native speaker, without changing the code."
+          }
+        ],
+        "other": {
+          "kind": "text",
+          "min": 2,
+          "max": 120,
+          "description": "The languages, such as Filipino or Spanish."
+        },
+        "note": "Translations come with a Workbench tool that isn't built yet: record the languages under `later`, keep every word in the catalogue, and tell the client a translation goes live only once a named native speaker has checked it."
+      }
+    ],
+    "not_asked": [
+      {
+        "sets": "base",
+        "why": "The site is written first in English, in the readers' spelling from the country answers, so it isn't asked again."
+      },
+      {
+        "sets": "wording",
+        "why": "Wording is content, not a setting: the client says what they want in their own words, or asks for drafts (the workbench-ai skill), and it goes into the catalogue."
+      }
+    ]
+  }
 }