Skip to main content

Start With Studio

Studio is the authoring and review product for ANIP projects.

For the detailed application guide, start with Studio Overview. This page is the short local-start path.

Use it when you want to:

  • Create or inspect an ANIP project.
  • Load source documents.
  • Draft Product Design and Developer Design.
  • Generate a Developer Definition.
  • Publish a package to Registry.
  • Export or import starter templates.
  • Browse showcase projects in read-only mode.

Studio is not the runtime authority. The Developer Definition and Registry package are the artifacts that generators, verifiers, and consumers should trust.

Run Studio Locally​

git clone https://github.com/anip-protocol/anip.git
cd anip/studio
docker compose up --build

Open:

http://127.0.0.1:8080

By default, STUDIO_SEED_SHOWCASES=1, so Studio starts with seeded projects you can inspect.

Run Read-Only Demo Mode​

Read-only mode is the public demo posture:

STUDIO_READ_ONLY=1 STUDIO_SEED_SHOWCASES=1 docker compose up --build

In read-only mode, Studio allows browsing but blocks mutation:

  • Project creation.
  • Document edits.
  • Assistant runs.
  • Package publication.
  • Template publication.
  • Registry mutation.

The Studio Project Flow​

The standard Studio flow is:

source documents
  -> Product Design
  -> locked Product baseline
  -> Developer Design
  -> Developer Definition
  -> Registry package
  -> generated service
  -> verification evidence

The important rule: generation and verification consume the Developer Definition or Registry package, not hidden Studio state.

What To Inspect In A Project​

Open a seeded or newly created project and inspect:

  • Source documents.
  • Product Design.
  • Developer Design.
  • Developer Definition.
  • Diagnostics and coverage status.
  • Registry publication status.
  • Contract signature.
  • Template export/import surfaces.
  • Generated handoff artifacts.

Do not treat generated code as the first source of truth. In ANIP, reviewed definitions are the truth and generated code is an implementation of them.

What Good Looks Like​

A release-quality Studio project should have:

  • Locked Product Design baseline.
  • Developer Design coverage for Product Design items.
  • No unresolved diagnostics blocking package generation.
  • Clear capability IDs.
  • Explicit input-resolution behavior.
  • Approval paths for write-adjacent or risky behavior.
  • Denial, restriction, clarification, recovery, and audit behavior.
  • Package lineage and contract signature.
  • Portable source/project links.
  • No secrets or machine-local paths in package metadata.

AI Authoring Modes​

Studio has three authoring modes:

ModeUse when
Manual ModeYou want deterministic page-by-page editing and exact control.
Guided ModeYou want AI help while accepting, rejecting, or revising each section.
Autopilot ModeYou want Studio to complete the project draft from reviewed source context.

The mode changes how the project is authored, not what the release must prove. All modes should converge on the same locked Product baseline, saved Developer Definition, readiness diagnostics, package material, and validation evidence.

Autopilot requires enough source evidence. Product docs are usually enough to draft Product Design. Developer Design needs developer evidence such as input contracts, input-resolution behavior, runtime governance, composition, backend bindings, and verification expectations. If that evidence is missing, Studio should stop or ask questions instead of inventing contract truth.

The assistant is not the trust boundary. The generated contract, validation diagnostics, approval state, and Registry package are the trust boundary.

Smoke Studio​

From the repository root:

studio/scripts/smoke-compose.sh

The smoke resets the database, starts read-only seeded compose, checks API/UI reachability, verifies seeded projects, verifies representative mutation guards, and tears down.

Next Steps​