Operator-facing name for the brick (≥3 characters). Shown in MissionControl's Product Bricks list for identification.

Operator-facing description of what the brick does (≥3 characters).

Function role this brick plays in product logic. One of: 'context' (computes context data), 'feasibility' (returns errors/warnings), 'pricing' (returns line items), 'scheduling' (returns time slots). Determines the TypeScript signature payload is type-checked against.

TypeScript source code (as a string) implementing the brick.

The wrapper. The server wraps your payload to apply the function-type contract before type-checking:

const __brick: <FnType> = (
  <YOUR PAYLOAD>
);

Where <FnType> is ContextFunction / FeasibilityFunction / PricingFunction / ScheduleFunction depending on the brick's type. The wrapper expects a single TypeScript expression in the payload position — this is the most common foot-gun for new integrators:

• Trailing ; — (...) satisfies ScheduleFunction; produces ( ...; ) after wrapping, a parse error. Remove the final ;.
• Top-level const / let / var — const fn = ...; fn produces ( const fn = ...; fn ), also a parse error. Inline as an arrow expression instead.
• Missing satisfies <FnType> — usually fine because the wrapper's contextual type is enough, but extra parens / comma operators in the payload can block contextual flow. If the validator complains about implicit-any parameters, append satisfies <FnType> to the expression.

May be empty (prefill flow). Compile errors return HTTP 400 with internalCode: "BRICK_PAYLOAD_INVALID", a one-line plain-English hint when the payload matches one of the known foot-guns, and an array of details (line/column/message) for any remaining diagnostics. details is capped at 50 entries and is therefore not exhaustive: when the payload produced more diagnostics than that, detailsTotal carries the full count. Read detailsTotal rather than details.length to report how many problems were found.