@open-mercato/cli 0.9.0 → 0.9.1-develop.7462.1.94c09f158f

package/.turbo/turbo-build.log

@@ -46,6 +46,7 @@ Copied create-app/agentic/ → dist/agentic.staging/
 [module-facts] module registry unavailable (registryPath not provided); API route auth omitted for perspectives
 [module-facts] module registry unavailable (registryPath not provided); API route auth omitted for phone_calls
 [module-facts] module registry unavailable (registryPath not provided); API route auth omitted for planner
+Generated 75 module fact-sheets → dist/agentic.staging/guides/modules/
 [module-facts] module registry unavailable (registryPath not provided); API route auth omitted for portal
 [module-facts] module registry unavailable (registryPath not provided); API route auth omitted for progress
 [module-facts] module registry unavailable (registryPath not provided); API route auth omitted for push_notifications
@@ -64,12 +65,12 @@ Copied create-app/agentic/ → dist/agentic.staging/
 [module-facts] searchConfig entityId is not statically resolvable: /home/runner/work/open-mercato/open-mercato/packages/documents/src/modules/documents/search.ts:92
 [module-facts] module registry unavailable (registryPath not provided); API route auth omitted for agent_orchestrator
 [module-facts] module registry unavailable (registryPath not provided); API route auth omitted for record_locks
-Generated 74 module fact-sheets → dist/agentic.staging/guides/modules/
 [module-facts] module registry unavailable (registryPath not provided); API route auth omitted for security
 [module-facts] module registry unavailable (registryPath not provided); API route auth omitted for sso
 [module-facts] module registry unavailable (registryPath not provided); API route auth omitted for system_status_overlays
 [module-facts] module registry unavailable (registryPath not provided); API route auth omitted for events
 [module-facts] module registry unavailable (registryPath not provided); API route auth omitted for gateway_stripe
+[module-facts] module registry unavailable (registryPath not provided); API route auth omitted for gateway_tpay
 [module-facts] module registry unavailable (registryPath not provided); API route auth omitted for onboarding
 [module-facts] module registry unavailable (registryPath not provided); API route auth omitted for scheduler
 [module-facts] module registry unavailable (registryPath not provided); API route auth omitted for search
@@ -148,6 +149,7 @@ Generated 74 module fact-sheets → dist/agentic.staging/guides/modules/
 [module-facts] module registry unavailable (registryPath not provided); API route auth omitted for system_status_overlays
 [module-facts] module registry unavailable (registryPath not provided); API route auth omitted for events
 [module-facts] module registry unavailable (registryPath not provided); API route auth omitted for gateway_stripe
+[module-facts] module registry unavailable (registryPath not provided); API route auth omitted for gateway_tpay
 [module-facts] module registry unavailable (registryPath not provided); API route auth omitted for onboarding
 [module-facts] module registry unavailable (registryPath not provided); API route auth omitted for scheduler
 [module-facts] module registry unavailable (registryPath not provided); API route auth omitted for search

package/dist/agentic/guides/customers-calendar.md

@@ -0,0 +1,57 @@
+# Customers calendar event types
+
+Use this guide after `.ai/guides/modules/customers/index.md` when adding, removing, or modifying calendar event types. Calendar behavior belongs to Customers and app-owned contributions. Keep framework packages read-only; generic CrudForm, InjectionSpot, widget loading, and module overrides must remain independent of calendar business rules.
+
+## Exact reference implementation
+
+- [Customers definitions, schemas, and registry operations](../../node_modules/@open-mercato/core/src/modules/customers/calendar-event-types.ts)
+- [Customers server catalog resolution](../../node_modules/@open-mercato/core/src/modules/customers/lib/calendar/eventTypeResolver.ts)
+- [Customers editor](../../node_modules/@open-mercato/core/src/modules/customers/components/calendar/CalendarEventEditor.tsx)
+- [Example adds Visit and optionally patches Meeting](../../src/modules/example/widgets/injection/calendar-visit/widget.ts)
+- [Example injection bindings](../../src/modules/example/widgets/injection-table.ts)
+- [Example Visit lifecycle widget](../../src/modules/example/widgets/injection/visit-availability/widget.ts)
+- [Example optional availability checks](../../src/modules/example/lib/visitAvailability.ts)
+- [Example Visit panel and dependency warnings](../../src/modules/example/components/VisitPanel.tsx)
+- [Example server validation](../../src/modules/example/commands/interceptors.ts)
+- [Example server availability guard](../../src/modules/example/lib/visitAvailabilityGuard.ts)
+- [Example server DI registration](../../src/modules/example/di.ts)
+
+The shipped example is disabled by default. Read and adapt its connected files into your own `src/modules/<id>/`; enable your own module in `src/modules.ts`. Do not modify the canonical teaching example merely to customize an app.
+
+## Add a type
+
+Export an ordinary injection widget typed as `CalendarEventTypeWidget` from `@open-mercato/core/modules/customers/calendar-event-types`. Include stable `metadata.id`, `Widget: () => null`, and `eventTypes: [definition]`. Bind the widget to `calendar:customers.event-types` in your module's `widgets/injection-table.ts`. Use the example's injection-table shape; retain enabled-module and feature gates.
+
+A definition has a stable lowercase `key`, fallback `label`, translated `labelKey`, optional `icon`, `color`, `panelKey`, and a complete `behavior`. Set `schemaVersion: 1`, a supported `baseKind`, `selectable`, `order`, every `fields` switch, and `customFieldsetIds`. The `baseKind` selects the existing Customers persistence behavior; a new type does not require a duplicate customer event entity. Visit uses `baseKind: 'event'` and `panelKey: 'example.visit'`. Keep validation, custom fields, and panel selection inside the owning business module.
+
+An empty `customFieldsetIds` preserves unrestricted legacy custom fields; it does not hide every field. Supply a non-empty list to restrict the editor to those fieldsets. Preserve shipped field behavior when adapting a definition, including `endTime: true` for Call and Task.
+
+## Remove, replace, or patch a type
+
+In your own app module, use `eventTypeOverrides: { note: null }` to remove a type from the selectable catalog. This is an app-owned customization; it is not part of the shipped Example declaration. A non-null override supplies a complete replacement definition accepted by the Customers schema. For a targeted modification, add an `eventTypePatches` entry with `targetEventTypeKey`, then explicit operations such as `replaceLabelKey`, `replaceFields`, `replaceSelectable`, `replaceCustomFieldsetIds`, `appendCustomFieldsetIds`, or `deleteCustomFieldsetIds`. The example changes Meeting's translated label with `replaceLabelKey`. The shipped example preserves all six baseline types with either flag value. Only its Meeting patch is an opt-in demonstration controlled by `OM_EXAMPLE_CALENDAR_DEMO_OVERRIDES`; the default is false. Visit sets `adminConfigurable: false`, so its extension behavior remains code-owned.
+
+Removing a type is a catalog tombstone, not deletion of existing activities or tasks. Preserve historical fallback when opening records whose type is tombstoned, unknown, or contributed by a disabled module. Test existing records as well as the create selector, and do not silently migrate their stable type keys.
+
+For server-owned programmatic contributions, resolve Customers' `calendarEventTypeRegistry` through DI. Its `upsert`, `replace`, `patch`, `remove`, and `removeSource` operations carry provenance; follow the exact installed signatures and keep source cleanup deterministic. The example's `di.ts` softly resolves this service and registers the same widget definitions and patches for API and worker execution. Follow that module registrar when adapting the client declaration: registering a browser widget alone does not register server contributions. Keep dependency resolution optional and do not add a global calendar dispatcher or calendar properties to shared override or widget metadata contracts.
+
+## Optional staff and resources
+
+Staff and resources are optional integrations. Do not statically import their entities or implementations into an app module that must work without those packages. Resolve optional services or query by scoped entity IDs only after confirming the module is enabled. If staff or resources are unavailable, show a translated warning, skip only their unavailable checks, and keep the Visit panel and ordinary Customers calendar operational. An installed and enabled dependency still enforces its normal authorization, scope, and availability validation. A denied or failed check must not be treated as a missing module.
+
+Visit reports each selected staff member or resource by display name and distinguishes missing schedules or intervals outside working hours from an existing booking (`example.calendar.visitAvailability.booked`). Booking checks include overlapping Customers interactions of every event type, including recurrence occurrences, in the authorized tenant and organization. Use half-open intervals: touching boundaries do not overlap. Canceled and deleted interactions do not reserve subjects. On edit, pass the validated current `excludeInteractionId` to preview; the command guard excludes that same existing interaction automatically, while retaining other collisions. Preview and rejected writes return the blocked subject names and reason keys without disclosing other event titles or IDs. Booking reads and recurrence expansion are bounded; failed, incomplete, or unsupported booking checks fail closed rather than reporting an available subject. These guards protect Visit scheduling against bookings from any type; they do not impose Visit rules on other event-type writes.
+
+The availability widget must gate its handlers to Visit itself; UI visibility alone does not gate mutation hooks. Keep matching server validation in API/command interceptors so direct calls enforce the same rules. Preserve tenant/organization scope, optimistic locking, guarded mutations, and the read/save/reload round trip.
+
+## Event timezones and recurring availability
+
+Every calendar event editor exposes an IANA timezone selector. Keep its `timezone` in form values when wrapping the standard panel; use the Customers wall-time helpers to convert its local date/time into the `scheduledAt` instant. The API accepts optional nullable `timezone`, validates explicit IANA names, and returns it on reads. Persist the chosen zone and restore it on edit. Legacy records with a null zone retain browser-local interpretation. Weekly event recurrence with an explicit zone preserves the event-local wall time across daylight-saving changes; reject nonexistent local times rather than shifting them silently. When a local time occurs twice during a fall-back transition, conversion chooses the earlier instant.
+
+The Visit example wraps the original Customers panel, preserving its datepicker, time selects, recipient/resource pickers, and two-column layout. Add availability feedback around `Original`; do not duplicate the editor fields or import its private components. The preview must convert values in the selected event timezone, independently of the browser timezone, and match the server's persisted interval.
+
+Planner timezone interpretation is explicit: Visit calls `plannerAvailabilityService.getMergedAvailabilityWindows` with `respectTimezone: true` and `weeklyScheduleTemplate: true`. The second option applies only to unbounded weekly schedules. Staff/resource weekly editors store the next matching weekday as `DTSTART`; treat that date as a weekday/time anchor rather than an effective start date. For example, a Tuesday 09:00–13:00 Warsaw template anchored on October 6 also covers September 29, 09:15–12:00 Warsaw. Preserve one-off date overrides and count-bounded recurrence start dates. Existing callers that omit these options retain their previous UTC/DTSTART semantics.
+
+Availability reads translate an auth `userId` to the active staff member `id` before querying planner `subjectType: 'member'`; these IDs are different. Scope checks to the interaction or parent customer's authorized organization, not merely the selected UI organization. A title-only edit need not revalidate its saved assignments; changing the interval or subjects must run the fresh check.
+
+## Validation
+
+Run `yarn generate` after adding injection files, then the smallest relevant typecheck and tests. Cover add/replace/patch/remove order, translated labels, custom fieldsets, historical fallback, Visit-only hooks, direct API validation, disabled staff, disabled resources, both absent, and enabled-but-denied dependencies, staff/resource weekly and one-off availability, selected-zone round trips, daylight-saving recurrence, and title-only edits after schedule removal. The harness regression is `OMH-238`; shared components and installed package files are outside the app's writable scope.

package/dist/agentic/guides/extensions.md

@@ -22,6 +22,8 @@ Add every other match too: `backend-ui` + `om-backend-ui-design` when authoring,
 
 ## Mechanism Selector
 
+For Customers calendar event types, follow the [Customers calendar guide](customers-calendar.md) and its exact app example links. It owns add/remove/patch behavior and optional staff/resources coupling.
+
 | Goal | Mechanism | App module file |
 |---|---|---|
 | Add computed/read data | Response enricher | `data/enrichers.ts` |