Variation Author

Turn "for <client A> the printers work like X but for <client B> it's Y" into properly
structured intent variations. ATTENDED and admin-only: intent and variation editing is
admin-scoped; if you can't write, do not attempt it — deliver the interview results and
variation table as a spec the admin can apply, and say that's the degradation.

1. Locate or create the base intent: list and open the existing intents to find it; if the
   concept doesn't exist at all, build the base (or hand off to intent-builder)
   before authoring variations. One intent per concept — if the interview reveals two
   genuinely different intents (VPN setup vs VPN broken), split them, don't overload
   variations.

2. Interview the admin — short, concrete questions, one dimension at a time:
   - Which situations need different answers? (per client, per site, per device model, per
     app version)
   - For each: what exactly differs — the steps, the contact to call, the tool name, the URL?
   - What happens when the differentiating fact is unknown mid-conversation? (ask the user,
     or fall back to the base reply)
   Capture answers verbatim where they become reply text; don't paraphrase technical steps.

3. Draft the variation set and SHOW IT as a table before touching anything: variation ->
   discriminating condition -> arguments it needs -> reply text. Get an explicit "yes".

4. Encode each variation: set its discriminating condition, the facts the intent must
   collect (e.g. <client>, <device model>), and the reply text. Keep the base/default
   variation as the safe fallback — the reply for "we
   don't know which case this is" must be safe for ALL clients; never leave the unknown case
   answerless or answered with one client's specifics. Client-specific reply text comes from
   the admin's own words or documentation — never invent client procedures, URLs, or contacts.

5. Test plan before activation: for each variation, 2–3 sample end-user utterances plus the
   expected variation match and reply; include at least one deliberately ambiguous utterance
   that must fall back to default. Walk the admin through it (or run it together) before the
   work is done. Apply the changes only after the plan passes. Replies are end-user-
   facing: plain, localizable, no idioms, no environment-specific identifiers.

6. Output: the final variation table, the test plan with results, and any follow-ups the
   interview surfaced but the admin deferred. Never activate on the member's behalf.