Shared Scaffold Model

The shared scaffold model is the small schema/type boundary for scaffold-domain data that both CLI and API need.

packages/scaffold owns this boundary.

Owns

• Baseline channel and source values
• Baseline manifest metadata
• Artifact kind and artifact metadata
• Baseline provenance
• Pack and catalog entry primitives
• Required-tool contract
• Neutral ContextPlan schemas
• Versioned harness capability matrices with exactly one row per contribution family
• Projection outcomes that retain actions, warnings, omissions, and failures independently

Outside This Boundary

• CLI filesystem writing, terminal UI, repo detection, prompt rendering, or local update behavior.
• Context compilation, harness adapters, native target selection, and filesystem application.
• API auth, blob storage, or persistence.
• HTTP wire schemas, which stay in packages/contract.

Invariants

• The package imports no sibling apps or package runtime code.
• It exports stable schemas/types, not execution behavior.
• apps/cli and apps/api compose it at the app layer; packages/contract owns HTTP wire schemas independently.
• Neutral context rejects harness targets and materialization fields.
• Capability matrices cover skills, scoped prompts, subagent templates, lifecycle hooks, and tool configuration exactly once.
• Projection failures never erase warnings, omissions, or successful independent actions.

Why It Exists

Baseline manifests, artifact metadata, provenance, pack entries, required tools, neutral context, and projection outcomes need stable shared meanings. Keeping those model primitives in one package lets app code share durable terms without moving compilation, adaptation, or writing behavior into a library package.

See Compile and Project Repository Context for the runtime flow and Harness Capability Projection for the support contract.