Story: Provisioners from the shell — analysis and design

Today a system can only be provisioned through the Qt wizards: the system provisioner (bootstrap admin, base system, initial tenant), the tenant provisioner (bundles, data sources, parties) and the party provisioner (counterparties, reports, activation). The end goal is to run all of this from ores.shell, driven by an org-mode tangled script library with an end-to-end provisioning script.

This story is the analysis and design phase only: walk every wizard page and map its inputs and backend calls onto the existing shell command surface (capability coverage, not a 1-1 UI mapping — see * Decisions); brainstorm what the provisioning interaction should feel like in the medium of ores-shell; and decide the implementation approach. The decision task scoped the follow-up work into two stories: Implement ores-shell provisioning commands and Provisioning script library.

• Every page of all three provisioner wizards is mapped: fields, defaults, validation, backend NATS messages, and the existing shell command that covers it or the explicitly identified gap.
• The ores-shell provisioning interface has been brainstormed in the medium's own terms, with candidate command surfaces compared and a recommendation made.
• Implementation decisions are recorded in * Decisions and the follow-up implementation story/stories are scoped from the backlog capture with right-sized tasks.
• The shell is usable from the Qt UI (fixed-width font fix), so the designed interaction can actually be exercised.

• No 1-1 wizard-to-shell mapping. The shell does not replicate the wizard UI. The wizard pages define the required capability coverage — every input and backend effect must be reachable — but the command surface should be designed for the medium of ores-shell: think about what makes the interaction smoother there (sensible defaults, one command spanning what the GUI splits across several pages, flags instead of sequential prompts, scriptability first). Where the shell medium suggests a better interaction shape than the wizard's, prefer it.
• Interface design. Porcelain + plumbing surface; positional required arguments with optional --flags; load is stop-on-error with --continue-on-error; provision party takes an explicit UUID or exact full name (no session party state). Full design in the brainstorm task's Result.
• Shell bootstrap verified. It sends only create_initial_admin_request (iam.v1.bootstrap.create-admin); the tenant_id/name in its response is the system tenant context. iam.v1.bootstrap.provision-tenant is genuinely uncovered — provision system adds it.
• Script library home. projects/ores.shell/scripts/ — org sources and tangled .ores co-located with the component that runs them; the emacs batch tangle is a CMake target of ores.shell.
• Two implementation stories. Implement ores-shell provisioning commands (C++: infrastructure, plumbing, porcelain; 7 tasks) and Provisioning script library (org library, provision_all, tangle target, manual; 4 tasks; depends on the first). The manual task is re-homed to the latter.
• Party-name lock-step accepted. The e2e script hard-codes the party full name, pinned by the synthetic seed; the manual will show parties list --status Inactive for operators on other datasets.
• Continuation lines deferred. One command per line in .ores scripts; revisit only if real scripts become unreadable.

• Implementation of the provisioning commands, the script library, the end-to-end script, and the tangle build — scoped into the Implement ores-shell provisioning commands and Provisioning script library stories.
• Changes to the Qt wizards themselves; they remain the interactive path.
• Interactive, wizard-style guided prompting inside the shell — the target is scripted/command-line provisioning.