The hiring wizard — first verified task without opening a terminal

[Dygreens]

Part of #68. Sequenced last — this is assembly once #69, #70 and #71 exist.

Objective: Replace "register a session" with a hiring flow a non-technical owner can complete alone: what's the job → pick the role → grant access → set the level → first verified task.

Fits the north star: every step maps to a stored object amux already owns (mission, capability grant, tier). The wizard is a front-end over existing state, not a new agent loop.

The flow

1. "What do you need done?" — free text. e.g. "make sure every client payment matches an invoice."
2. Three candidate missions, at deliberately different scopes (see below).
3. Role preset — Bookkeeper / Analyst / Sales / Chief of Staff. A preset is a bundle: mission template + tool grants + output-format defaults.
4. Access — "they'll need Gmail and Excel." Delegates entirely to Capability-based permissions per session #59.
5. Level — Hire a level, not a model — intelligence tiers with an honest promotion path #70, with the cost/speed tradeoff shown before hiring.
6. First task, with an explicit success criterion, so the user sees a verified result rather than a chat log.

The riskiest step is #2, and it needs a specific fix

A non-technical user cannot evaluate whether a generated mission is achievable. Offered three, they will pick the most impressive-sounding one — reliably the least achievable — and then conclude the product doesn't work.

So the three options must vary along scope, stated plainly, not along phrasing:

• Narrow — one workflow, high success rate. Recommended.
• Medium — a few related workflows.
• Ambitious — flagged honestly as lower success rate today.

And every option ships with its success criterion ("you'll know it worked when…"), which becomes the board gate. A mission we cannot state a check for is one we should not offer.

Role presets are configuration, not roleplay

Per #68 and #46's "Explicitly NOT building": a preset resolves to mission template + tool grants + output defaults. It must not emit an instruction telling the model to act like a character. The user sees a job title; the system stores a config. If a PR in this issue adds a persona string to a system prompt, that PR is out of scope.

Depends on

• Mission as a first-class object (org → department → agent, with inheritance) #69 (mission object), Hire a level, not a model — intelligence tiers with an honest promotion path #70 (level), Capability-based permissions per session #59 (capability grants). Org-chart fleet view — see the company, not the session list #71 is the natural landing page after hiring.

Avoid

• Generating the mission with a model call where the user's own words would do (ethos rule 2 — spend model calls on judgment, not string manipulation). The scoping is judgment; the restatement is not.
• Any step that cannot be completed without a terminal. That is the entire point of the issue.

Metric

Time-to-first-verified-task for a user who has never opened a terminal. If the wizard completes and no verified task follows, the wizard failed regardless of completion rate.