# 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:

```json
{"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.

```json
{
  "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.