First: what does “post a manifest” mean?

Preview

This tutorial starts with two employees and two shifts, then grows the example into an installable retail-scheduling problem type with skills, availability, hours, preferences, a generated Python client, a manifest-driven user interface, solution visualization, and typed diagnostics.

Every solver request follows the same boundary:

validated manifest + explicit problem records
        -> admitted decision model
        -> solver policy
        -> solution + certificate, or a typed refusal

The examples use the source contracts in helixor-solvers, the REST API in helixor-solver-server, and the generated-client conventions in helixor-sdk-gen. The rendered tutorial is served at /tutorial beside the REST API’s /docs, /openapi.json, and /q/openapi endpoints.

There is deliberately no generic POST /api/v1/manifests endpoint. A manifest has different ownership and lifetime depending on what you are doing:

Goal	What you send	Endpoint or mechanism	Lifetime
Try a manifest while developing it	The manifest inside `options.manifest`, plus the problem records	`POST /api/v1/solve/{problem_type}`	One solve request; no shared catalog state
Install a reusable problem type	A versioned solver-pack archive containing the manifest and its supporting config artifacts	Required product contract: upload, admit, and activate a solver pack	Immutable installed version; verify it through `GET /api/v1/manifests`
Ship a built-in native problem type	A packaged manifest, an existing or new engine policy, demo data, response enrichment, and tests	Build and deploy the solver packages	The deployed release
Save a user’s private draft in the Solver UX	An editable user-manifest record	Intended `/api/v1/user-manifests` CRUD surface	User or tenant scoped

Important

The last row is not a usable persistence contract in the current solver server. The UX contains client code for create, clone, update, and delete, but the server currently exposes only a stubbed list response. Until that gap is closed, use inline manifests for drafts and extension packs for reusable installed types. Do not mistake a browser-local draft for an installed solver capability.

Important

The reusable-pack row is also the required product experience, not an endpoint that exists today. The current POST /api/v1/extensions/register accepts a descriptor containing server-resolvable file references; it does not upload the referenced artifacts. That is suitable for an administrator wiring an already-mounted catalog, but it is not a developer installation API. The missing upload/admission boundary is specified in Milestone 8.