Builder-owned related Calendar creation (source example)

RelatedCalendarComposer.tsx shows a custom React layout using the public
@buildwithhq/ui adapters. It is source-only and is not a hosted template or a
published developer-kit revision. The host supplies an authenticated transport,
an explicit secured source selection, and a non-reused session epoch. Keep the
transport stable and rerender when the selected source or session changes.

The builder may place the controls in any React layout. This example uses an
expandable core.container and a separately placed create button. The existing
container gains disclosure-label and disclosure-state (open, closed, or empty
for always visible). Closing it leaves controls mounted; native invalid fields
open it so browser focus can reach them. Puck keeps the editing slot visible and
round trips these settings. No saved-page migration is required.

createRuntimeCalendarCreateDraft is one explicit event draft:
- prepare() reads /api/modules/calendar/capabilities and the shared secured
  /api/runtime/record-scope/create-roles choices, plus the existing native
  /api/runtime/fields/calendar definitions. A metadata failure blocks creation.
- submit(values, selection) requires an explicit Personal choice or an eligible
  DataRole with an explicit authorized location where required. No source-record
  scope is inherited. No owner, actor, app or organization identity is accepted
  through the values object.
- submit() calls POST /api/modules/calendar at most once per draft. The public
  counterpart already exists: POST /v1/apps/{saasAppId}/modules/calendar,
  modules.calendar.write. No new API route was added.
- A valid create receipt must identify distinct nonempty RecordId and EventId
  and a valid revision. The adapter then GETs the exact RecordId and verifies
  the EventId/current revision. receipt() survives a failed detail refresh;
  readCreated() retries only the read.
- A dispatched rejection, unreadable result, cancellation, or timeout never
  unlocks another POST. A null receipt is not proof that creation failed.
  Review current Calendar data before starting a genuinely different draft.
  Keep the draft instance stable; do not recreate it on every React render.

createRuntimeRelatedCalendarDraft adds explicit cross-module composition:
- The source is a persisted RecordId plus exact moduleKey. A secured graph read
  must return that same source and module. No route is derived from its label.
- submit() creates an independently scoped event; it does not create a link.
- link(relationKey) is a separate user action using an exact available type.
  It rereads the event and source graph, then uses the existing secured PUT
  /api/modules/record-graph/{recordId}/relations. The Developer API already has
  its public record-graph counterpart. Source/target action permissions remain
  server-enforced.
- At most one relationship PUT is dispatched per draft. A relationship denial
  or lost response never deletes/recreates the event. readLink() reconciles via
  reads only. A missing edge in a truncated graph is unknown, not absent.
- These are two explicit operations, not an atomic create-and-link transaction.
  The source selection cannot change the destination of an in-flight operation.

The example renders standard Calendar inputs in UTC, explicit visibility,
and individually placeable custom fields in a second expandable container.
useRuntimeCustomFields supplies values/update/collect, and
RuntimeCustomFieldControl renders one field with optional explicit formId and
disabled state. Builders can supply their own markup from the same metadata.
Calendar custom dates use the hook's fourth argument,
{ dateTimeMode: "unspecified" }, and the same dateTimeMode on each control.
They are exact timezone-unspecified SQL calendar values, separate from the
event's Start (UTC) and End (UTC). Defaults, edits and returned values retain
seconds and up to seven fractional digits. Never append Z or convert these
custom values through JavaScript Date. The controls reject invalid calendar
dates and zone-bearing input while retaining the user's text for correction.
The shared hook retains exact numeric values, keeps an explicit false answer,
and fences old callbacks when its source changes.
Keep it mounted per draft, or supply a distinct draftVersion for a new source,
including record/session changes even when their metadata and saved values match.
The reviewed runtime-definition procedure excludes hidden and protected fields.
The reader rejects any unexpected encrypted definition; generic controls never
replace the host's separately secured protected-field workflow. This metadata
read is not a protected-field inventory and never reveals protected values.
The underlying values type also supports recurrence and reminders; builders must
supply matching controls for those features. This is not complete Calendar coverage.
It deliberately provides no automatic retry, invented relationship type, native
page URL, permission, location or saved-record identity.

createRuntimeCustomFieldsReader uses the exact same parser as native forms,
filters hidden definitions, rejects ambiguous field keys/identities, and discards
late metadata after source/session changes or cancellation. It is an authenticated
tenant-runtime adapter. The existing public design/fields route has a different
administrative contract and must not be substituted for this runtime metadata
read. A public runtime-metadata counterpart is not established by this example.

Verification is recorded in the companion TD-55 evidence. Unit and synthetic
browser workflows do not establish routed-tenant acceptance. Release activation,
real tenant scopes/permissions and hosted installation remain under the owner's
release hold.
