UpStation

Showing 25 of 69 from the live probe.

• Get Guide

  Read this FIRST. The orientation/playbook: goals, the Discover→Defend phases, your role, the default flow, and the principles — enough context to self-direct from a brief to committed requirements. No auth.

• List Workloads

  The canonical discovery lanes (id, label, blurb, domain). Pick lane ids from here — do not invent them.

• Issue Fingerprint

  Mint a new lightweight account token (fingerprint). It IS the account — show it to the user and tell them to save it; pasting it into any future chat re-opens their projects.

• List Projects

  The fingerprint's saved projects — the re-access entry point for a fresh chat.

• Create Project

  Start a project from a one-paragraph brief. Parses suggested sites + workload lanes for you to confirm/edit. Owned by the fingerprint. Three ENTRY LEVELS (each an entry point, never a cage — levels can be added later): 'requirements' (default — full discovery interview), 'solution' (solution-first: design with no captured requirements, supply-footprint tiles), 'configuration' (configuration-first: configure one standalone product, no solution).

• Get Discovery Context

  Pull the interview guidance (helper + assume + default posture per field) for the given lanes. This GUIDES your own interview; it does not capture anything.

• Submit Transcript

  Append the raw interview transcript to the evidence trail, (re)summarize, and return the Analyze payload (summary + clarifications + unresolved hero). The transcript MUST be the full exchange — questions AND answers + your assumptions — verbatim, not a distilled answer list.

• Get Summary

  The current (or a pinned) Analyze payload: summary + clarifications + rollups.

• Review Worksheet Batch

  Brief conversational reply acknowledging a batch of requirement-worksheet answers and calling out any conflicts/contradictions they created (grounded in the current summary's clarifications). Call after submit_transcript.

• Commit To Design

  Crystallize a version: snapshot the trail + summary and extract requirements.json. The signal that Design may start. Sets status: locked.

• Branch Version

  Fork a new branch off a committed version for a change or a rollback (e.g. 'core count → 256', or 'roll back to v1'). The next submit_transcript appends the change → re-summarize; commit_to_design re-extracts — the new version continues the project-global counter (v4, v5, …) with this version as its base. The old version is retained.

• Get Project

  The full raw artifact for rehydration: meta + trail + summary + extraction + lineage.

• Add Site

  Add a site to the project's multi-site spine.

• Update Project Meta

  Global edits: rename, edit the brief, or set the confirmed workload lanes.

• Get State

  The server-owned FLOW STATE for a project: current stage, focus (what the stage is scoped to), gates (why the design phase is open/closed), and available_actions — the conversational verbs for this stage PLUS the principal-confirmed crystallization verbs (each with a label + requires_confirmation). Both surfaces render/navigate from this: the web draws its buttons from available_actions.crystallization; a direct agent learns which verbs it may call freely vs which need its human's confirmation.

• Set Focus

  Principal NAVIGATION: move the flow to a stage and/or focus a solution, component, or standalone design. Confirmation-free (navigation, not crystallization). The web calls it when the user clicks Requirements / a solution / Develop / a component; a direct agent calls it when its human says 'let's develop option B'. Validates gates — a design stage can't be entered before requirements are committed unless a solution-first option or standalone design exists (design-config is itself an entry level

• List Artifacts

  Enumerate a project's design + solution artifacts (the requirements lineage lives in get_project/list_projects). Optional kind filter.

• Create Design

  Create a resource-level design component (one resource type; may expose multiple capability roles). requirements_ref pins the locked requirements version it's built on; omit for a free-form/exploration design. The MODEL then authors the design: identity via put_design, configuration via author_design_config.

• Get Design Context

  The Design analog of get_discovery_context: the pinned requirements this component must satisfy, PLUS solution-time positioning — per-family design guide(s) (when-to-choose-X + sizing method) and a grounded candidate-product roster for the resource role, machine-derived from our extraction layer (compute + block-storage also carry the HCI ready-node roster — an HCI design is multi-role). Products MUST be picked from the served roster; roles without a guide yet fall back to model knowledge.

• Put Design

  Author/patch the design's IDENTITY (the model is the designer). Send the full design.json or just the keys you're changing; top-level keys shallow-merge. Set provides[] (role/fulfills/labels/serves/sizing), requires (shared-infra demands — structured net_ports rows), resolves_to (the chosen platform's extraction path, copied VERBATIM from candidate_products) + quantity, model/product_line, product (software-defined product key where applicable), site, captive_to, approach/config_rationale prose,

• Get Design

  Read a design's content (head branch, or a pinned branch/version). design_id is a dsn_* id — find a slot's in get_solution_context's roster (roster[].design_id); the sol_* solution id will not work.

• Lock Design

  Freeze the design as an immutable version a solution can compose.

• Branch Design

  Fork a new branch off a locked design version to iterate the SAME component (keeps its requirements basis).

• Retarget Design

  Point a design at a different requirements basis: forks a new branch off a locked version with new_requirements_ref swapped in (a newer requirements version, or — once the requirements-artifact split lands — a different requirements artifact). The old version is retained.

• Set Design Lever

  Update a single design-time sizing lever on a design (the user's 'massage' control beside a rollup tile). Mechanical user action, not a model decision. Recomputes the rollups and returns a `consequence` payload (which tiles moved).