Project defaults and onboarding

Choose starting formats and ask useful setup questions.

Typed shared inputs

The optional projectInputs array declares up to 32 shared input contracts using key, type, semantic, required and description, plus the usual optional schema, accepted meanings, source policy, default, sensitivity, freshness, cardinality, batching and numeric limits. Keys are unique lowercase identifiers up to 64 characters. For example:

{"projectInputs":[{"key":"brand_tone","type":"text","semantic":"brand_tone","required":true,"description":"How the brand should sound","sources":["default","user"],"default":"Clear and friendly"}]}

Defaults must validate against their contracts and permit the default source. Credential-sensitive defaults are rejected. New projects initialize these values in typed context with Project Type provenance; matching Block inputs must allow project sources. Existing values are never overwritten by initialization. Other equally ranked ready project values take precedence over these fallback records unless a source preference explicitly selects the default. The composer and connected preview use the defaults too; explicit sample values, settings and connections remain authoritative. Freshness limits produce expiring context values. These contracts grant no permissions or execution authority.

Native controls can inspect or replace the declarations. The visual setup editor can add shared information from project-capable Block requirements, preserving their types, meanings and schemas, then edit descriptions, required flags and defaults. Advanced contract editing handles custom declarations and complex values. Edits stay local until Apply shared inputs; validation is shared with native edits. Missing values do not create an upfront questionnaire. The next local recipe/JavaScript Block can request a uniquely matching shared input through the existing reviewed-answer flow. The declaration controls user/Chat sources; both its contract and the consuming Block's contract must accept the answer. Saved answers carry workflow provenance and source revisions, and permitted Blocks can reuse them. Ambiguous declarations are not chosen automatically. The existing saved-answer editor can update reviewed shared answers and newly initialized defaults against an unchanged declaration and a current permitted consumer. Edits require the current revision, remove default fallback priority, and mark dependent results stale. Credential-sensitive and dependency-derived records are not exposed in this editor. Older unsigned defaults are preserved without being silently enrolled in editing. Richer value pickers and hosted-Block collection remain unfinished. Existing releases are not rewritten.

Connected previews accept shared sample answers at context.sharedInputs, keyed by the declared shared-input key. The preview form uses the existing typed-answer dialogs; complex values can use the sample context JSON. Samples must satisfy their declarations and permit user answers; credential-sensitive samples are rejected. They replace matching template defaults only in the preview registry, and matching consumers must still allow project sources. Explicit Step inputs and connected results retain precedence. Sample answers are never saved into the Project Type or a real project. Existing sample digests and server rehearsal replay include the whole context, so shared samples follow the same verification path. This does not simulate trusted connections or allow missing hosted results.

A Project Type can declare project defaults and up to eight setup questions. These are optional additions to the schema-1 Project Type contract; they do not replace protected Chat, configure provider credentials or start production work.

{
  "defaults": {"aspectRatio": "9:16", "brief": "Create a short product launch video."},
  "onboarding": [
    {"id": "product", "label": "What is the product?", "type": "text", "required": true},
    {"id": "audience", "label": "Who is it for?", "type": "textarea"},
    {"id": "tone", "label": "Tone", "type": "select", "options": ["Clear and direct", "Playful"], "default": "Clear and direct"}
  ]
}

Merge these fields into an existing valid Project Type with schemaVersion, id, version, name, description and its enabled stages. This fragment is not a standalone package.

defaults.aspectRatio accepts 16:9, 9:16 or 1:1; defaults.brief is at most 4,000 characters. Question IDs are unique lowercase identifiers up to 40 characters. Labels are at most 120 characters. Text and textarea answers are at most 1,000 characters. A select question declares 2–12 unique options of at most 120 characters; its default must match an option. required is optional and boolean.

The Project Type Builder exposes these fields under Project defaults & starting questions. Using the Project Type opens one project setup dialog. The host records the chosen project name and format, and retains the brief plus labeled answers in the existing project's production context (bible.extraInfo). Script Writer receives this brief. Answers are project data, not edits to a marketplace release or its version identity; they are not published or sent to acquisition analytics. Read Blueprint/project context only through the permissions already documented by the SDK.

The empty Project Type starter is an editable draft. Add an enabled Block before validation, runtime execution, or publication; empty drafts are never installable releases.