Zero-to-map release journey

The 2026.1 release journey answers one end-to-end question: can an operator use AI-facing Honua surfaces to install the platform, configure services and geoprocessing, then create and save a map app without pretending that an agent performed the human publication gate?

The executable bundle lives at mcp/release/zero-to-map. It implements the seven stages from honua-release#123 D9.3:

  1. Run the control-plane Docker installer and verify API, MCP, and Console.
  2. Use the generated admin MCP surface to test a connection, import fixtures, publish layers, set access, and create a scoped key.
  3. Discover and execute the Esri-compatible Buffer task through MCP, poll its job/result resources to a retained artifact, prove the same task through the SDK's GPServer adapter, then run and poll the dataset-oriented MCP Buffer verb separately.
  4. Use Studio MCP tools to create a draft, add layers and the retained GP artifact, style and show it, set the view, add a chart/control/interaction, validate, and reopen the saved draft.
  5. Record publication intent while structurally requiring human confirmation.
  6. Import a Console receipt bound to the exact connection/service/layers, all three GP jobs and result identities, draft, real admin proposal, execution operation, audit correlation, and approved release candidate, including health and recovery checks.
  7. Require HTTP 200 from the stable approved share URL.

The GP story is deliberately dual-surface. honua_esri_gp_list_tasks, honua_esri_gp_describe_task, and honua_esri_gp_execute_task are the AI-facing Esri compatibility roster; the third tool is executed, then its honua://jobs/{id} and /results resources are joined before the gate passes. HonuaClient.geoprocessingRunner() separately drives the GPServer task with the same IJobRun lifecycle used elsewhere in the SDK. honua_buffer_features remains the native MCP dataset-reference verb. Honua's server owns the process catalog and translation; the journey does not invent external ArcGIS Server federation.

Contract mode is the default and is safe to run in CI. It validates the plan, records live execution as blocked, and skips dependent stages. Live mode is explicit (--execute --yes), preflights the complete MCP catalog before the first MCP mutation, blocks on missing deployment capabilities, and accepts a Console receipt only when its journey, resource, job, result, proposal, execution-operation, audit-correlation, candidate, and release identities match.

The catalog preflight verifies the base, analysis, and esri-gp server profiles independently and derives the expected total (432 + 6 + 3 = 441) instead of asserting one hardcoded number; it records the active profiles and the roster digests on the journey receipt. Enabling those profiles on a local candidate still depends on honua-server#3363/#3430/#3431: the server configuration key that turns them on is not yet published, so honua admin install local --profile gp-dev grants the Pro edition but cannot yet request the profiles. The Studio PublicationIntent is not mislabeled as the separate admin approval proposal.

The checked-in fixtures and simulated tests are contract evidence, not a live candidate recording. A release owner must retain the driver receipt, Console receipt hash, and the final URL response as the release evidence bundle.