@company-semantics/contracts 87.0.0 → 88.0.1

package/src/root-exports/agent-runtime.ts

@@ -0,0 +1,213 @@
+/**
+ * Package root exports — Agent Runtime
+ *
+ * MCP tool discovery, message parts, execution kinds, Ralph, internal admin
+ * and rate-limit vocabulary.
+ *
+ * A slice of the `@company-semantics/contracts` root entry, moved here verbatim
+ * from `src/index.ts`, which re-exports it with `export *`. Each list is the
+ * exact subset of its domain the root exposes. Import from the package root,
+ * never from this file.
+ */
+
+// MCP tool discovery types
+// @see company-semantics-backend/src/interfaces/mcp/ for implementation
+export type {
+  ToolCategory,
+  ToolVisibility,
+  ToolInvocationMode,
+  ToolEffectClass,
+  MCPToolDescriptor,
+  ToolDiscoveryResponse,
+  ToolListMessagePart,
+  ToolListDataPart,
+  // Tool domain taxonomy (PRD-00265)
+  ToolDomain,
+  ToolIntegration,
+  ToolIntent,
+  ToolStability,
+  ToolComplexity,
+  // Resource flow types (PRD-00265)
+  ResourceType,
+  // Capability graph types (PRD-00265 types, PRD-00268 implementation)
+  CapabilityGraph,
+  CapabilityGraphEdge,
+  ToolWorkflow,
+} from "../mcp/index";
+
+export { buildCapabilityGraph } from "../mcp/index";
+
+// Message part types and builder functions
+// @see ADR-2026-01-022 for design rationale
+export type {
+  TextPart,
+  ToolListPart,
+  StatusPanelPart,
+  StatusPanelEntry,
+  ChartPart,
+  ChartDataPoint,
+  TablePart,
+  ConfirmationPart,
+  SurfacePart,
+  AssistantMessagePart,
+  PartBuilderState,
+  AddPartResult,
+  // Preview types (Phase 3)
+  PreviewArtifactKind,
+  IntegrationProvider,
+  IntegrationKey,
+  IntegrationArtifactContent,
+  PreviewArtifact,
+  PreviewData,
+  PreviewPart,
+  PreviewDataPart,
+  // Confirmation types (Phase 4)
+  ConfirmationChoice,
+  ConfirmationRiskLevel,
+  ConfirmationData,
+  ConfirmationResponseData,
+  ConfirmationDataPart,
+  // Interactive task surface types (editable surfaces)
+  InteractiveTaskKind,
+  CandidateSource,
+  InteractiveFieldType,
+  InteractiveFieldDescriptor,
+  InteractiveTaskSubject,
+  InteractiveTaskDestination,
+  InteractiveTaskData,
+  InteractiveTaskPart,
+  InteractiveTaskDataPart,
+  StructureReviewData,
+  StructureReviewPart,
+  StructureReviewDataPart,
+  // Discussion hand-back signal (not a surface, data-discussion-handback)
+  DiscussionHandbackData,
+  DiscussionHandbackPart,
+  DiscussionHandbackDataPart,
+  // Suggested replies surface types (non-governed chips, PRD-00958)
+  SuggestedReply,
+  SuggestedRepliesData,
+  SuggestedRepliesPart,
+  SuggestedRepliesDataPart,
+  // Workflow progress surface types (non-governed anchor, data-workflow-progress, PRD-00976)
+  WorkflowProgressData,
+  WorkflowProgressPart,
+  WorkflowProgressDataPart,
+  // Execution result types (Phase 5)
+  ExecutionArtifactStatus,
+  ExecutionResultSummary,
+  ExecutionUndoCapability,
+  ExecutionResultData,
+  ExecutionResultPart,
+  ExecutionResultDataPart,
+  // Undo result types (PRD-00203)
+  UndoResultData,
+  UndoResultDataPart,
+  // Message lifecycle types (Phase 1 streaming)
+  // @see ADR-CONT-027 for design rationale
+  StreamPhase,
+  MessageLifecycleEventType,
+  MessageLifecycleEvent,
+  MessageStartEvent,
+  MessageDeltaEvent,
+  MessageCompleteEvent,
+  ToolResultRenderClass,
+  ToolResultPart,
+  MessageStartDataPart,
+  MessageDeltaDataPart,
+  MessageCompleteDataPart,
+} from "../message-parts/index";
+
+export {
+  isTextPart,
+  isSurfacePart,
+  createPartBuilder,
+  addText,
+  addSurface,
+  addPart,
+  buildParts,
+  getDroppedCount,
+  WireSurfaceBuilder,
+  CONFIRMATION_LABELS,
+  getConfirmationLabel,
+  DISCUSSION_HANDBACK_PART_TYPE,
+} from "../message-parts/index";
+
+// Generic review anchor (input-request-is-the-generic-review-anchor)
+// data-input-request is governed like structure-review, which stays frozen and
+// readable forever. See ../message-parts/input-request.ts.
+export type {
+  InputRequestPart,
+  InputRequestDataPart,
+} from "../message-parts/index";
+export { isInputRequestDataPartShape } from "../message-parts/index";
+
+// Execution kind types and registry
+// @see ADR-CONT-029 for design rationale
+export type {
+  ExecutionKind,
+  ExecutionState,
+  ExecutionEventType,
+  ISO8601Timestamp,
+  IconName,
+  ExecutionDomain,
+  ExecutionKindDefinition,
+  // Projection contracts
+  ExecutionTarget,
+  ExecutionInitiator,
+  ExecutionStatus,
+  ExecutionSummary,
+  TimelineStatus,
+  TimelineIcon,
+  TimelineUIEvent,
+} from "../execution/index";
+
+export {
+  EXECUTION_KINDS,
+  getExecutionKindDefinition,
+  isValidExecutionKind,
+  EXECUTION_EVENT_TYPES,
+  isExecutionEventType,
+} from "../execution/index";
+
+// Ralph autonomous coding loop types
+// @see company-semantics-control/docs/ralph.md for usage
+export type {
+  // PRD types
+  AllowedRepo,
+  RalphPRDCategory,
+  RalphPRDPriority,
+  RalphPRDItem,
+  RalphPRD,
+  // PRD v2.0 schema extensions
+  RalphAgentContract,
+  RalphFailurePolicy,
+  RalphScope,
+  RalphMeta,
+  RalphAcceptanceCriteria,
+  RalphReferenceImplementation,
+  RalphInteractionFlow,
+  RalphCapabilities,
+  RalphSuccessCriteria,
+  RalphCommitPolicy,
+  // Progress types
+  RalphIteration,
+  RalphMode,
+  RalphProgress,
+} from "../ralph/index";
+
+// Ralph constants (cross-repo support)
+export { REPO_PRECEDENCE } from "../ralph/index";
+
+// Internal admin types (cross-org control plane)
+// @see PRD-00113 for design rationale
+export type {
+  InternalAdminCapability,
+  InternalAdminContext,
+  RequestContext,
+} from "../internal-admin";
+
+// Rate limit domain types
+// @see PRD-00013 for contracts integration
+export type { RateLimitConfig, RateLimitResult } from "../rate-limit/index";
+export { RateLimitTier } from "../rate-limit/index";

package/src/root-exports/collaboration.ts

@@ -0,0 +1,247 @@
+/**
+ * Package root exports — Collaboration
+ *
+ * The comment wire contract (anchors, interpretation, construction, receipts)
+ * and the chat domain.
+ *
+ * A slice of the `@company-semantics/contracts` root entry, moved here verbatim
+ * from `src/index.ts`, which re-exports it with `export *`. Each list is the
+ * exact subset of its domain the root exposes. Import from the package root,
+ * never from this file.
+ */
+
+// Comment wire contract — where a thread hangs (the anchor union), what a
+// thread and its comments look like on the wire, and who a comment may name.
+// The anchor is the single most load-bearing shape in this package: the backend
+// validates it and then stores opaque jsonb it never interprets, so app/
+// contracts drift on it has NO server-side tripwire and mis-places comments
+// silently. Response vocabulary only — request bodies stay backend-side.
+// See src/comments/README.md.
+//
+// The anchor SIZE BOUNDS are published alongside the shape, because the client
+// that composes an anchor and the schema that accepts it are the two halves of
+// that same driftable agreement: a constructor capturing more context than the
+// boundary accepts loses a comment after it was written. Note ANCHOR_CONTEXT_CHARS
+// (capture) and ANCHOR_AFFIX_MAX_CHARS (accept) differ ON PURPOSE.
+// @see ADR-CONTRACTS-116, ADR-CONT-029
+export {
+  ANCHOR_AFFIX_MAX_CHARS,
+  ANCHOR_CONTEXT_CHARS,
+  COMMENT_ANCHOR_TYPES,
+  COMMENT_SUBJECT_TYPES,
+  COMMENT_THREAD_KINDS,
+  COMMENT_THREAD_STATUSES,
+  QUOTE_MAX_CHARS,
+  RELATIVE_POSITION_MAX_CHARS,
+  SUGGESTION_OPS,
+  SUGGESTION_STATUSES,
+} from "../comments/index";
+
+// The anchor's INTERPRETATION, published beside its shape (ADR-CONTRACTS-127).
+// The schema said what an anchor looks like; these say what it MEANS. Both
+// halves have to be published for the same reason: the writing client and the
+// resolving client agree with no server-side arbiter between them, so a second
+// description of "where does this anchor land" mis-places comments with nothing
+// anywhere throwing. `resolveAnchorFromText` is total, pure and text-only — the
+// Yjs relative-position rung stays in consumers, which compose it on top.
+export {
+  contextAfter,
+  contextBefore,
+  contextsMatchAt,
+  findSoleOccurrence,
+  resolveAnchorFromText,
+} from "../comments/index";
+
+export type { AnchorResolution, Occurrence } from "../comments/index";
+
+// The two questions asked BEFORE the body is written (ADR-CONTRACTS-127).
+// `anchorStillReads` is a SECOND assertion, independent of the ladder — the
+// applier must not trust the finder — and `plannedEdit` derives the mutation
+// from the canonical payload rather than a caller's restatement of it. Both are
+// total functions of their arguments, which is exactly what makes them liftable
+// out of a browser applier: no Y.Text, no clock, no lease.
+export { anchorStillReads, plannedEdit } from "../comments/index";
+
+export type { PlannedEdit } from "../comments/index";
+
+// The CONSTRUCTION half of the same contract (ADR-CONTRACTS-127). Publishing
+// anchor → text while leaving text → anchor browser-only would be half an
+// extraction: the side that COMPOSES an anchor decides how much context to
+// capture and what counts as a quote, and a second description of that is the
+// same silent-drift hazard the resolver was published to end. Both constructors
+// validate through `CommentAnchorSchema` before returning and refuse — `null` —
+// rather than truncate, because an anchor the route boundary rejects is a
+// comment lost after it was composed. The relative-position pair is NOT
+// produced here; a consumer holding a `Y.Text` merges it onto the result.
+export {
+  createTextAnchorFromRange,
+  createTextInsertionAnchorAt,
+} from "../comments/index";
+
+export type { TextRange } from "../comments/index";
+
+// The application receipt — the durable proof that an accepted suggestion's
+// edit ALREADY LANDED IN THE BODY (ADR-CONTRACTS-127). It travels in the same
+// CRDT transaction as the edit, so either both survived or neither did, which
+// is what closes the window between the write and the acknowledgment. The MAP
+// KEY is the load-bearing part: a receipt written under any other name lands in
+// a map nobody reads while the reader watches a map nobody writes, and nothing
+// anywhere throws — the same no-arbiter hazard as the anchor, now that a second
+// implementation is about to write receipts too. Published with a PARSER,
+// because these values arrive from a peer through a CRDT that has no schema of
+// its own: a row that is not three well-typed fields is dropped, never
+// surfaced. The receipt lives BESIDE the body and must never reach the markdown
+// source, an export, or the content hash.
+export {
+  SUGGESTION_RECEIPTS_MAP,
+  SuggestionReceiptSchema,
+  readSuggestionReceipt,
+} from "../comments/index";
+
+export type { SuggestionReceipt } from "../comments/index";
+
+export {
+  AGENT_OUTCOME_REASONS,
+  AgentOutcomeSchema,
+  CommentAnchorSchema,
+  CommentAnchorTypeSchema,
+  CommentMentionSchema,
+  CommentSchema,
+  CommentSubjectTypeSchema,
+  CommentThreadListResponseSchema,
+  CommentThreadSchema,
+  CommentThreadStatusSchema,
+  CommentThreadSummarySchema,
+  MentionableCandidateSchema,
+  MentionableResponseSchema,
+  SuggestionSchema,
+  ThreadOriginSchema,
+} from "../comments/index";
+
+export type {
+  AgentOutcome,
+  CommentAnchor,
+  CommentAnchorType,
+  CommentMention,
+  CommentProjection,
+  CommentSubjectType,
+  CommentThread,
+  CommentThreadKind,
+  CommentThreadListResponse,
+  CommentThreadStatus,
+  CommentThreadSummary,
+  MentionableCandidate,
+  MentionableResponse,
+  Suggestion,
+  SuggestionOp,
+  SuggestionStatus,
+  ThreadOrigin,
+} from "../comments/index";
+
+// Chat domain types
+// @see PRD-00142 for share chat design rationale
+export type {
+  ChatSummary,
+  // Chat lifecycle types
+  TitleSource,
+  ChatListFilters,
+  ChatSummaryExtended,
+  TitleGenerationRequest,
+  TitleGenerationResponse,
+  // Event system types
+  BaseEvent,
+  InvalidationReason,
+  ChatChangedField,
+  // Domain events (carry full state)
+  ChatCreatedEvent,
+  ChatUpdatedEvent,
+  ChatDeletedEvent,
+  ChatDomainEvent,
+  // Invalidation events (staleness signals)
+  InvalidateChatEvent,
+  InvalidateChatListEvent,
+  ChatInvalidationEvent,
+  // SSE event unions
+  ChatSseEvent,
+  // Runtime profile types (PRD-00229)
+  ChatRuntimeProfile,
+  ChatRuntimeProfileInfo,
+  // Proactive chat wire vocabulary (ADR-CONTRACTS-142): how a chat was born,
+  // the occurrence-to-chat resolution states, and the recognized form of the
+  // wire-lenient `proactiveKind` string
+  ChatOrigin,
+  ProactiveChatResolution,
+  RecognizedProactiveKind,
+  // Page context (PRD-00969, ADR-CONTRACTS-153): where the reader is, as
+  // identifiers. Never content, never free text.
+  ChatDiscussionScope,
+  ChatPageContext,
+  // Chat mentions (ADR-CONTRACTS-160): a turn's mention rows are keyed on a
+  // PrincipalRef, so the agent is nameable on the chat surface too, and the
+  // composer's candidate list reuses the comments candidate shape.
+  ChatMessageMention,
+  ChatMentionableResponse,
+  // Multi-party chat (ADR-CONTRACTS-164): a chat is a room with a membership.
+  // Participation, not an ACL entity — two roles, one owner, and the agent is
+  // mentionable but never a member.
+  ChatParticipantRole,
+  ChatGrantableRole,
+  AddChatParticipantRequest,
+  UpdateChatParticipantRequest,
+  ChatParticipant,
+  ChatParticipantsResponse,
+  // Chat continuity (chat-continuity-wire-vocabulary): the subject a chat
+  // belongs to, its generation, and the lineage back to its predecessor.
+  ConversationSubjectKind,
+  ChatContinuationReason,
+  ChatContinuity,
+  // Launch resolution: the disposition the read-only resolve reports, the
+  // start-fresh response, and the launch-target-superseded 409 body.
+  LaunchDisposition,
+  ResolveLaunchResponse,
+  StartFreshChatResponse,
+  LaunchTargetSuperseded,
+} from "../chat/index";
+
+export {
+  CHAT_RUNTIME_PROFILES,
+  DEFAULT_CHAT_RUNTIME_PROFILE,
+  // Page context: the request-side schema and the closed vocabularies behind
+  // its `view`, `scope` and `entity.type` fields.
+  ChatDiscussionScopeSchema,
+  ChatPageContextSchema,
+  CHAT_DISCUSSION_REQUEST_TYPES,
+  CHAT_PAGE_VIEWS,
+  CHAT_PAGE_SCOPES,
+  CHAT_PAGE_ENTITY_TYPES,
+  // `proactiveKind` is a bare string on the wire so a new kind cannot make an
+  // older client reject the whole chat list; this is the ONE place it becomes
+  // a ProactiveEventKind. See src/chat/proactive-kind.ts.
+  recognizeProactiveKind,
+  // Chat mentions: the mention row a turn carries, and the composer's
+  // candidate envelope (items are `MentionableCandidateSchema`, imported from
+  // comments rather than restated).
+  ChatMessageMentionSchema,
+  ChatMentionableResponseSchema,
+  // Multi-party chat: the role vocabulary, one participant row, and the list
+  // envelope for GET /api/chats/:chatId/participants.
+  ChatParticipantRoleSchema,
+  ChatGrantableRoleSchema,
+  ChatParticipantSchema,
+  ChatParticipantsResponseSchema,
+  // Chat continuity: the closed subject-kind and continuation-reason
+  // vocabularies, and the lineage object on the chat detail.
+  CONVERSATION_SUBJECT_KINDS,
+  ConversationSubjectKindSchema,
+  CHAT_CONTINUATION_REASONS,
+  ChatContinuationReasonSchema,
+  ChatContinuitySchema,
+  // Launch resolution: the closed disposition vocabulary, the resolve and
+  // start-fresh responses, and the 409 code + body for a superseded target.
+  LAUNCH_DISPOSITIONS,
+  LaunchDispositionSchema,
+  ResolveLaunchResponseSchema,
+  StartFreshChatResponseSchema,
+  LAUNCH_TARGET_SUPERSEDED_CODE,
+  LaunchTargetSupersededSchema,
+} from "../chat/index";

package/src/root-exports/delivery.ts

@@ -0,0 +1,218 @@
+/**
+ * Package root exports — Delivery
+ *
+ * Notifications, action items, the user-scoped push envelope, the durable
+ * in-app inbox, proactive delivery and analysis workflows.
+ *
+ * A slice of the `@company-semantics/contracts` root entry, moved here verbatim
+ * from `src/index.ts`, which re-exports it with `export *`. Each list is the
+ * exact subset of its domain the root exposes. Import from the package root,
+ * never from this file.
+ */
+
+// Notification domain types
+// Replaces the Email* vocabulary (ADR-CONT-034), which was deleted with
+// `@company-semantics/contracts/email` — email is now one channel, not the shape
+// of the layer. The render layer itself (content model, renderers,
+// renderToChannel) stays on the `/notifications` subpath; the root carries the
+// vocabulary, as it did for email.
+// @see ADR-CONTRACTS-086 for the multi-channel render layer
+// @see ADR-CONTRACTS-085 for the definition + registry
+export type {
+  NotificationKind,
+  NotificationPayloads,
+  NotificationDefinition,
+  NotificationDefinitions,
+} from "../notifications/index";
+
+export {
+  NOTIFICATION_DEFINITIONS,
+  getNotificationKindDefinition,
+  isValidNotificationKind,
+} from "../notifications/index";
+
+// Action-item domain types — things awaiting a user's DECISION, derived from
+// each domain's own pending rows rather than stored. Deliberately a separate
+// vocabulary from NotificationKind above: that one names events that get SENT,
+// this one names standing state. See src/action-items/README.md.
+// @see ADR-CONT-104
+export {
+  ACTION_ITEM_KINDS,
+  ACTION_ITEM_TARGET_TYPES,
+} from "../action-items/index";
+
+export {
+  ActionItemKindSchema,
+  ActionItemListResponseSchema,
+  ActionItemSchema,
+  ActionItemTargetSchema,
+  ActionItemTargetTypeSchema,
+} from "../action-items/index";
+
+export type {
+  ActionItem,
+  ActionItemKind,
+  ActionItemListResponse,
+  ActionItemTarget,
+  ActionItemTargetType,
+} from "../action-items/index";
+
+// User-scoped push envelope — the frames any domain may put on ONE
+// authenticated user's connection without owning a route or an SSE union of its
+// own. A THIRD vocabulary alongside the two above, and deliberately unlike
+// both: a notification LEAVES the building, an action item is STANDING state,
+// and a user event is a single unreplayable instant meaning "your cache is
+// stale". This stream is a wake-up channel, NOT an ordered event log — no frame
+// carries an SSE `id:` and nothing durable may be hung off it.
+// See src/user-events/README.md.
+export {
+  MAX_INVALIDATION_KEYS,
+  USER_EVENT_RESYNC_REASONS,
+} from "../user-events/index";
+
+export {
+  ResourceInvalidatedEventSchema,
+  UserEventBaseSchema,
+  UserEventConnectedSchema,
+  UserEventResyncReasonSchema,
+  UserEventResyncSchema,
+  UserSseEventSchema,
+} from "../user-events/index";
+
+export type {
+  NotificationCreatedEvent,
+  ResourceInvalidatedEvent,
+  UserEventConnected,
+  UserEventResync,
+  UserEventResyncReason,
+  UserSseEvent,
+} from "../user-events/index";
+
+// Durable in-app inbox + the merged feed that renders it
+// (user-notification-inbox-and-merged-feed). The
+// THIRD vocabulary beside NotificationKind and ActionItemKind: a notification
+// leaves the building, an action item is standing state you can resolve, and
+// one of these is a stored fact you can only look at. Rows hold identifiers
+// only — every prose field is rendered at read time under the reader's CURRENT
+// authority, which is what keeps a stale row from leaking anything.
+// See src/user-notifications/README.md.
+export { USER_NOTIFICATION_KINDS } from "../user-notifications/index";
+
+export {
+  FeedItemSchema,
+  FeedListResponseSchema,
+  FeedMarkReadRequestSchema,
+  UserNotificationKindSchema,
+  UserNotificationSchema,
+} from "../user-notifications/index";
+
+export type {
+  FeedItem,
+  FeedListResponse,
+  FeedMarkReadRequest,
+  UserNotification,
+  UserNotificationKind,
+} from "../user-notifications/index";
+
+// Each inbox kind's declared lifecycle — condition, supersession, resolution,
+// retention (notification-lifecycle-is-declared-per-kind) — and the one
+// function that turns a kind + domain ref into its condition/supersession keys.
+export {
+  conditionKeyOf,
+  NOTIFICATION_ATTENTION_ON_SUPERSEDE,
+  NOTIFICATION_LIFECYCLE,
+  NOTIFICATION_RESOLUTION_AUDIENCES,
+  NOTIFICATION_RETENTION_CLASSES,
+  NotificationConditionKeyError,
+  notificationKeysOf,
+} from "../user-notifications/index";
+
+export type {
+  NotificationAttentionOnSupersede,
+  NotificationCondition,
+  NotificationKeys,
+  NotificationLifecycle,
+  NotificationResolution,
+  NotificationResolutionAudience,
+  NotificationRetention,
+} from "../user-notifications/index";
+
+// The feed's views, selectors (explicit ids, or a view as of `asOf`) and verb
+// wire — read / unread / delete / restore — for the caller's inbox rows.
+export {
+  FEED_SELECTOR_MAX_IDS,
+  FEED_VIEWS,
+  FeedDeleteRequestSchema,
+  FeedDeleteResponseSchema,
+  FeedMarkUnreadRequestSchema,
+  FeedMutationResponseSchema,
+  FeedRestoreRequestSchema,
+  FeedRestoreResponseSchema,
+  FeedSelectorSchema,
+  FeedViewSchema,
+} from "../user-notifications/index";
+
+export type {
+  FeedDeleteRequest,
+  FeedDeleteResponse,
+  FeedMarkUnreadRequest,
+  FeedMutationResponse,
+  FeedRestoreRequest,
+  FeedRestoreResponse,
+  FeedSelector,
+  FeedView,
+} from "../user-notifications/index";
+
+// Proactive delivery — how the system speaks first (ADR-CONTRACTS-142). A
+// COMPOSER above the three notification vocabularies, not a fourth peer: the
+// presentation class is a TOTAL FUNCTION from class to surfaces
+// (CLASS_SURFACES, checked in both directions by the compiler), and a kind
+// carries its class plus the IDS each surface needs — which banner, which chat
+// template, which inbox kind — never the surface booleans. The born-read rule
+// is stated once (bornRead) so the backend imports it rather than re-deriving
+// it per call site. Pushed-chat prose lives here too (PROACTIVE_CHAT_COMPOSERS,
+// total over the templates): the backend hands a composer facts and writes what
+// comes back, FROZEN into the transcript — so a composer may only interpolate
+// facts the recipient was entitled to at compose time. See src/proactive/README.md.
+export {
+  PROACTIVE_PRESENTATION_CLASSES,
+  CLASS_SURFACES,
+  bornRead,
+  ORG_SYSTEM_EVENT_TYPES,
+  PROACTIVE_CHAT_TEMPLATES,
+  PROACTIVE_EVENT_KIND_IDS,
+  PROACTIVE_RECIPIENT_REASONS,
+  PROACTIVE_PROJECTIONS,
+  PROACTIVE_EVENT_KINDS,
+  PROACTIVE_CHAT_MAX_REPLIES,
+  PROACTIVE_CHAT_COMPOSERS,
+} from "../proactive/index";
+
+export type {
+  ProactivePresentationClass,
+  BadgeCarrier,
+  ClassSurfacePlan,
+  OrgSystemEventType,
+  ProactiveChatTemplate,
+  ProactiveEventKind,
+  ProactiveEventId,
+  ProactiveRecipientReason,
+  ProactiveProjection,
+  ProactiveEventDefinition,
+  OrgBecameSharedFacts,
+  MorningBriefFacts,
+  ProactiveChatFacts,
+  ProactiveChatComposer,
+  ProactiveChatMessage,
+} from "../proactive/index";
+
+// Analysis workflows — the registered types a durable long-running analysis
+// can be (PRD-00976). The workflow primitive itself is domain-agnostic; its
+// TYPE is the one place a domain names itself, and that name is a public wire
+// discriminator carried on the workflow row, in the data-workflow-progress
+// chat part and by the generic projection read. Namespaced `<domain>/<flow>`
+// so domains cannot collide, and a CLOSED const array so the discriminator is
+// validated and handled exhaustively. See src/workflows/README.md.
+export { ANALYSIS_WORKFLOW_TYPES, isWorkflowType } from "../workflows/index";
+
+export type { WorkflowType } from "../workflows/index";