/** * `BriefInstanceRecipe` — the declarative definition of a Sitecore * Content Operations *brief instance* (the unit of work — a populated * brief built against a `BriefType` schema). * * Companion to `BriefTypeRecipeSchema` (this file's sibling `schema.ts`, * which models the schema template). Brief instances reference their * type by stable codename (`briefTypeName`) rather than UUID, exactly as * a `campaign` recipe references nothing by id and identifies itself by * `name`. See docs/recipe-sync-architecture.md. * * The schema captures the fields `createBrief` / `updateBrief` accept * on the Brief API — `name`, `briefTypeName`, `locale`, `status`, * `isTemplate`, and the per-field `fields` map. Sub-resources (tasks, * comments, references, contributors, external mappings) are returned * by the read endpoints but are not part of the brief write surface, * so they stay out of the recipe. */ import { z } from "zod"; /** * Brief workflow status — the values the Brief API accepts on a write. * Mirrors the `BriefStatus` wire type in `../api/schema.ts`; surfacing * the literal set here means the model reads the enum directly off the * recipe schema (and bad values fail at parse-time, not push-time). * * `InReview` is the wire form for the "In Review" UI label. */ export declare const BriefInstanceStatusSchema: z.ZodEnum<{ Canceled: "Canceled"; Draft: "Draft"; InReview: "InReview"; Approved: "Approved"; Archived: "Archived"; }>; /** * Field values on a brief instance, keyed by `BriefField.name`. The * per-field shape varies by field `type` on the brief's type (RichText * values are ProseMirror docs; DateTime is an ISO string; Timeline and * Budget carry their own object shape). The shape is left as * `z.unknown()` so any field type round-trips losslessly between * `recipe pull` and `recipe push` without the recipe schema chasing * the per-field encoding. Validation is deferred to the server. */ export declare const BriefInstanceFieldsSchema: z.ZodDefault>; /** * One milestone on a brief's evaluation timeline — a workflow gate the * brief progresses through (concept review, draft delivered, final * approved, paid-media live, etc.). * * Distinct from the `Timeline` brief-type field type (single * start/end schedule). Milestones are universal across all brief * types: every brief has an evaluation timeline regardless of its * type-level field configuration. * * **Sitecore round-trip caveat**: the Brief API doesn't currently * expose a native milestone-array surface. scai's `briefInstanceKind` * does NOT serialize this field into the Sitecore push body, and * `briefInstanceKind.readCurrent` does NOT read it back. Milestones * round-trip cleanly between recipe push and recipe pull of the same * recipe file (via the schema's structural identity) but get lost on * Sitecore round-trips. When the Brief API exposes a milestone field * (or we pick an encoding inside `fields`), the writer will fill it * in and the projection will read it. */ export declare const BriefMilestoneSchema: z.ZodObject<{ name: z.ZodString; dueDate: z.ZodOptional; status: z.ZodOptional>; description: z.ZodOptional; completedAt: z.ZodOptional; }, z.core.$strip>; /** * One to-do on a brief. The Brief API exposes a minimal task surface — * the persisted record carries only `title`, `status` (locked to * `Pending` on create), and `assignees`. Probing TestDemo 2026-06-03 * confirmed that `description`, `body`, `dueDate`, and `DueOn` are * silently dropped by the server, so they're not in the recipe. * * Round-trip: `apply` POSTs each todo to `/api/brief/v1/tasks` after * the brief is created/updated. The pull projection lists tasks * filtered by `BriefId` and rebuilds the array from response order. */ export declare const BriefTodoSchema: z.ZodObject<{ title: z.ZodString; assigneeIds: z.ZodOptional>; }, z.core.$strip>; /** * One comment on a brief. The Brief API stores comments with an * impersonated `author` (the Auth0 sub passed in `authorId`) while * `createdBy` independently captures the calling client — letting * automation post on behalf of named users (CSM, Designer, Legal, * etc.) without conflating the audit trail. * * `text` accepts a plain string OR a ProseMirror doc node; the * server persists either as a RichText envelope. The seed * generator emits ProseMirror so formatting (bold, links, lists) * survives the round-trip into the brief's comment thread. */ export declare const BriefCommentSchema: z.ZodObject<{ text: z.ZodUnion]>; authorId: z.ZodString; }, z.core.$strip>; /** * Cross-resource reference attached to a brief. Sitecore Brief API * persists these in the `references` array on a read; verified * 2026-06-03 that `PUT /api/brief/v1/briefs/{id}` with a `references` * field on the body accepts the same shape and persists it. * * The most common use is linking a brief to its parent Orchestrate * project (campaign) — `relatedSystem: "co"`, `relatedType: "Project"`, * `id: `. Other related-system slugs (e.g. `xmcloud`) * appear on read but their write semantics are unverified. */ export declare const BriefExternalReferenceSchema: z.ZodObject<{ type: z.ZodLiteral<"ExternalLink">; relatedSystem: z.ZodString; relatedType: z.ZodOptional>; id: z.ZodString; }, z.core.$strip>; /** The full brief-instance recipe. */ export declare const BriefInstanceRecipeSchema: z.ZodObject<{ handle: z.ZodOptional; sitecoreId: z.ZodOptional; name: z.ZodString; briefTypeName: z.ZodString; locale: z.ZodOptional; status: z.ZodOptional>; isTemplate: z.ZodOptional; fields: z.ZodDefault>; evaluationTimeline: z.ZodOptional; status: z.ZodOptional>; description: z.ZodOptional; completedAt: z.ZodOptional; }, z.core.$strip>>>; todos: z.ZodOptional>; }, z.core.$strip>>>; comments: z.ZodOptional]>; authorId: z.ZodString; }, z.core.$strip>>>; references: z.ZodOptional; relatedSystem: z.ZodString; relatedType: z.ZodOptional>; id: z.ZodString; }, z.core.$strip>>>; campaignHandle: z.ZodOptional; storyId: z.ZodOptional; campaignSitecoreId: z.ZodOptional; }, z.core.$strip>; /** A validated brief-instance recipe. */ export type BriefInstanceRecipe = z.infer;