Source snapshot bcc79fcc · Declared package version 12.0.4. This page combines the checked-in package guide and manifest; commands and runtime behavior were not executed in this review.
meeting-capture-session defines bounded capture creation, session state and transitions. Chunk limits and completion/retention invariants are explicit; provider/native capture remains host-authorized and independently qualified.
OPA production completion adds provider-neutral automation-policy/effect contracts and exact scenario/platform/provider/deployment acceptance receipts.
The existing /operations catalog also declares automation settings read/update with bounded default/ceiling changes and revision checks. Persistence semantics are defined by OPA_AUTOMATION_PERSISTENCE_CONTRACT.
OPA_COMPANYOS_ACCEPTANCE_REQUIREMENTS freezes CompanyOS's separate release profile without qualifying other hosts. Personal scheduling read/generate 3.1 adds optional persisted Work proposals; meeting artifact 2.1 adds optional generation provenance. Existing records remain readable. See
docs/opa-companyos-production-acceptance.md for the generated requirements.
Provider-neutral contracts for organization, planning, agenda, booking, capacity, and auto-scheduling decisions across autonomous-company verticals.
OPA v2 consumes OpaWorkPlanningProjection values from the canonical Work Graph. Work owns desired dates, estimates, priority, dependency identity, and revision; OPA owns actual placement, confidence, explanations, and calendar-write intent references. A placement is stale whenever its Work revision no longer matches.
toOpaWorkPlanningProjection derives prerequisite refs from canonical Work relationship edges (blocked_by and incoming blocks) and rejects any edge that crosses the Work object’s tenant, organization, or workspace scope.
OPA profile and booking v3 surfaces use the canonical
productRef + tenantRef + workspaceRef + ownerKind + ownerRef owner scope. The additive product namespace admits companyos, pactena, and hcircle so all three meeting-experience projections can retain the same authority tuple. The owner kind is explicitly individual, team, workspace, or
organization. Protected browser requests carry only a server-issued opaque
scopeRef in the exact scope:v1:<43 base64url characters> grammar; the host resolves that grant to current membership and permissions and never accepts client-selected tenant or organization authority. Handles are unique inside the product public-host namespace, and each owner may have at most one active profile. Cross-owner transfer is intentionally absent: clone into the destination owner, publish there, then revoke the source. Browser request DTOs never carry product, tenant, workspace, or owner authority: protected hosts derive it from authenticated context, while anonymous inputs contain only public handles or cursors. The profile family is exposed only as
opa.profile.*@3.0.0 through /api/v2/opa/profile/** and /api/v2/public/**; the former v1 contracts and cursor grammar are unsupported.
Public profile events support the { mode: "unavailable" }
destination only while inactive. This preserves honest service metadata before an approved hybrid URL or healthy owned-live topology exists; an active unavailable event fails validation.
Public profile event types also accept provider-neutral
conferenceMode: "none" | "google_meet" | "microsoft_teams". The field defaults to "none". Selecting a native conference mode declares intent only: publication and confirmation must still fail closed unless the runtime proves conference capability and durably records the provider outcome.
Public profile links accept https: pages and addressed mailto: links (OpaPublicProfileLinkUrlSchema). Optional kind: "link" | "social" places a link in the list or the header icon row; list links may carry a section
heading, shared by consecutive links, and a description. All three fields are optional, so links saved before them keep validating and render in one untitled section.
Owns
organization/team/member/resource/calendar refs;
availability, focus, meeting, blackout, buffer, no-meeting, privacy, and capacity policies;
cross-domain handoff refs to CompanyOS, CommunicationOS, jobs, integrations, assurance, growth, finance, and orchestration evidence;
cross-module types for OrganizationPlanningCrossModulePlan, module handoffs, and adapter-port obligations;
pure projection helpers for mapping packets to cross-module intent projections;
cross-module fixtures demonstrating end-to-end integration without provider writes.
local/manual OPA v0 functions for availability, day planning, agendas, booking proposals, markdown export, and audit payloads.
Does not own
live calendar/provider writes;
notification delivery;
payment collection;
workflow execution engines;
CompanyOS authority/work execution;
provider credentials, API keys, private URLs, or SDK imports.
Entrypoints
@lssm-tech/lib.organization-planning-spec — root barrel including the additive, provider-neutral Meeting Intelligence capability-matrix contract, bounded meeting-context source ports, consent-safe transcript normalization, strict content-free quality observations, and explicit off/shadow/pilot/live rollout controls. Rollout authority and cohort identity are server-derived; shadow mode can never authorize effects. Matrix contracts describe delivery truth; they do not authorize providers or qualify a product host.
@lssm-tech/lib.organization-planning-spec/meeting-intelligence-capability-matrix
— dedicated capability-matrix contract and validation entrypoint.
@lssm-tech/lib.organization-planning-spec/meeting-intelligence-capability-matrix-validation
— focused fail-closed structural and qualification validator.
@lssm-tech/lib.organization-planning-spec/fixtures — base fixtures
@lssm-tech/lib.organization-planning-spec/operations — exact OPA catalog: 125 operations, 29 events, strict models, lifecycle maps, and domain policies. Profile, owner-scope, event-type, link, resource, calendar, and protected booking operations are v3; unchanged families remain v2.
@lssm-tech/lib.organization-planning-spec/opa — OPA v0 local/manual primitives plus the adaptive managed-experience contract: the three canonical home modes, RoleMorph action boundaries, explainability records, setup steps, timeline projections, booking brand configuration, and the six-step public booking flow. These projections describe presentation and never grant runtime authority.
@lssm-tech/lib.organization-planning-spec/opa/* — individual OPA helper subpaths for schemas, contracts, fixtures, availability, planner, agenda, booking, markdown export, plus the production surfaces below
@lssm-tech/lib.organization-planning-spec/opa/time — DST-safe Europe/Paris
time helpers (timezone-correct slotting across spring/autumn transitions)
@lssm-tech/lib.organization-planning-spec/opa/public-booking — public booking v0 local availability and slot re-check helpers; this is not an OPA v2 transport contract
@lssm-tech/lib.organization-planning-spec/opa/rich-calendar — rich calendar view model
@lssm-tech/lib.organization-planning-spec/translations — en/fr/es i18n catalogs, keys, and messages for booking plus adaptive experience modes, action boundaries, explanations, and reset controls
@lssm-tech/lib.organization-planning-spec/projections — pure projection helpers
@lssm-tech/lib.organization-planning-spec/types — all type exports
@lssm-tech/lib.organization-planning-spec/work-proposal-publication —
WorkProposalPublicationSchema (owner/source-event scope refinements),
validateProposalContents (preference proof, input-digest match, 14-day window, unique placements, stale source revision) and the
WORK_PROPOSAL_PUBLICATION_CONTRACT invariants. Publication never commits placements or authorizes provider effects.
Production OPA surfaces
The /operations entrypoint freezes exactly 125 beta operations (116 protected and 9 anonymous) across profile, link, event type, calendar, resource, booking, smart meeting, recording, transcript, summary, decision, search, task, retention, audit, and repair, meeting intelligence, collaboration, sharing, and dispatch families. Breaking owner-scoped profile, booking, meeting-policy configuration, and collection-selection operations are @3.0.0; unchanged operations and all 29 events remain @2.0.0. No v1 operation, event, compatibility wrapper, alias, or transport is exported.
Active booking links expose the owner-scoped
opa.link.embed_origins_update@3.0.0 command. It replaces the complete allowlist under optimistic revision control. Values must be unique exact HTTPS origins without credentials, paths, queries, or fragments; an empty list disables embedding without rotating or revoking the hosted link.
All protected operations carry one exact capability at their operation version; the nine anonymous profile and booking operations carry no capability. REST routes use only /api/v2/opa/** or /api/v2/public/**. GraphQL fields replace dots and underscores with _ and end in _v2; MCP tools replace them with - and end in -v2.
Browser payloads reject owner, tenant, workspace, product, calendar, provider, credential, and OAuth authority recursively. Public link and exchange tokens remain allowed because they are bounded public grants, not host authority. Nested request and response models are strict, provider-neutral, and reject unknown keys.
The root contract also exports the written-first meeting operating model. It classifies proposed synchronous work by purpose, P0/P1/P2 severity, preparation, blockers, and asynchronous sufficiency, then validates one bounded format, timebox, agenda, pre-read lead, and mandatory output set.
Anonymous booking intent creation, status, cancel, and reschedule responses use one public-safe projection containing only bookingRef, state, and an optional paired start/end with optional timeZone. Provider refs, resource refs, event-type refs, private authority, attendee data, audit metadata, and nested private booking objects fail schema validation.
Each lifecycle event carries one canonical transition truth. For booking, smart meeting, recording, transcript, summary, decision, task, and repair events, the event envelope transition must exactly equal the payload from, to, action, and outcome; missing or contradictory copies are rejected. The exact initial state for each lifecycle family is also frozen by the event contract.
The catalog is contract-only. Declaring an operation does not install a handler or enable a provider effect. Hosts must bind concrete v2 handlers explicitly and must not retain a v1 registry or compatibility route. The
opaV2OperationSpecs registry preserves each named operation's input and output types so hosts can derive handler types without casts or duplicated DTOs.
OpaV2OperationHandler<Key, TCtx> and OpaV2HandlerRegistry<TCtx> take the host execution context as an explicit type parameter. The default is the kernel
DefaultOperationHandlerCtx from @lssm-tech/lib.contracts-runtime-kernel, so a handler that reads only kernel fields installs in any host;
@lssm-tech/lib.organization-planning-runtime binds the runtime-core
HandlerCtx. A handler bound to a host context cannot fill a registry slot for another context, and cross-key handler swaps stay rejected. The anonymous manage-status query validates a bounded manage session for read-only lifecycle recovery after a cancellation or reschedule mutation. The browser host supplies its booking and bearer authority from HttpOnly cookies; neither value is persisted in browser storage. Public cancellation is valid while approval, provider creation, or provider reconciliation is pending, so a one-use manage grant can preempt an in-flight calendar effect instead of allowing the booking to become confirmed afterward.
Only the root /operations package subpath is public; individual v2 source modules are internal and are absent from both source and generated publish exports.
Release promotion remains blocked until the separate G004b runtime and API migration binds real v2 handlers and passes downstream typecheck, tests, and build. This contract package does not claim that runtime closure.
OPA v3 replaces the profile family with opa.profile.*@3.0.0 draft-load, optimistic-save, preview, reorder, publish, revoke, and anonymous public-lookup operations. Drafts remain mutable while published projections are immutable. Draft topology health is informational only: owned-live publication ignores caller claims and fails closed unless current owner-authoritative runtime state proves connection, free/busy, known-ID write, and exactly one configured and permitted write calendar. Hybrid events accept approved HTTPS Calendly URLs. Mutation bodies are bounded to 64,000 UTF-8 bytes and expose the named
PAYLOAD_TOO_LARGE error. Each operation exposes a dedicated generated-compatible SchemaModel, and every HTTP boundary is a strict Zod schema. No v1 profile wrapper or legacy authority field remains.
SEO profile discovery uses the anonymous opa.profile.public_list@3.0.0 query at GET /api/v2/public/profiles. It exposes only handle, revision, and publishedAt in immutable generation pages. The input accepts only an optional durable cursor—never a client-selected limit—and the output uses fixed 10,000-item pages, with a partial final page, no trailing empty page, and an explicit zero-item page-0 DTO. Cursors are capped at 160 characters and freeze the public grammar v2.<digest>.<page>.<checksum>:
digest and checksum are 43-character unpadded base64url SHA-256 values, the page is canonical unsigned decimal, and the checksum is SHA-256 over the UTF-8 string v2.<digest>.<page>. This is a non-expiring public locator while its generation is retained, not a credential or authorization mechanism.
Compatibility: this is an intentional major break. All opa.profile.*@1.0.0
identities, transports, tenant-only inputs, and v1 cursors are unsupported. Runtime roles, persistence, API handlers, and web sitemap behavior remain owned by the runtime and application packages. A cursor may appear in an immutable public sitemap URL; preserve it byte-for-byte and never interpret it as authorization or owner identity.
Reviewed goal-planning loop
The additive opa.goal_plan.review, opa.goal_plan.get, and
opa.goal_plan.replan contracts bind company, enterprise, product, and operational goals to reviewed portfolios and deterministic replay evidence. Multi-company dependencies require explicit revocable grants; shared-service scope is typed; personal data enters only through expiring, revocation-checkable projection references.
Policy evaluation is provider-neutral: contracts retain opaque bundle/data references, digests, query names, decision evidence, and freshness windows without importing an OPA SDK or Rego runtime type. A policy may report satisfaction, advise, or deny. It always records
technicalAuthority: "not_granted"; only separate ContractSpec Connect authorization can permit a technical effect. Approved plans require human approval, and non-waivable constraints cannot be bypassed.
Compatibility: additive. Existing OPA v2 operation identities, transports, schemas, events, and v0 helper behavior are unchanged.
Personal scheduling v3
Six protected operations expose an owner-scoped personal time ledger: schedule read, focus create/update/cancel, plan generation, and conflict resolution. Inputs never carry tenant, workspace, calendar, provider, or user authority. Hosts derive those values from the authenticated context and persist a durable idempotent command before Google or another provider is called. Public outputs show opaque ledger references and synchronization state, never provider event identifiers or OAuth material.
OPA v0 local/manual loop
typescript
import {
computeAvailability,
exportOpaMarkdown,
generateAgenda,
generateDayPlan,
proposeBookingSlots,
} from '@lssm-tech/lib.organization-planning-spec/opa';
These helpers implement the spec-pack v0 loop. Availability, planning, and booking use one primary_policy in v0; multi-policy merge/routing remains a later adapter concern:
text
tasks + commitments + meetings + policies
-> plan / agenda / booking proposal
-> human review
-> markdown / Notion export from audited artifacts
-> audit event payload on generated proposals
External-facing booking or agenda artifacts are proposals only and include required approvals. The package does not write calendars, send client messages, or import provider SDKs.
Managed hosts may durably persist the manual-loop projection, audit, and outbox signal before returning pending_approval. That host responsibility does not broaden this spec package into provider execution.
The smart-meeting browser boundary also exports a strict readiness projection:
ready, partial, not_configured, or unavailable. These states prevent infrastructure failure from being represented as an ordinary setup gap while keeping tenant, workspace, and provider authority out of the browser contract.
The additive legacy smart-meeting shadow-probe contract freezes a host-only receipt input and a redacted diagnostic observation. It does not accept owner authority from browsers, persist identity, prove data parity, or change the legacy HTTP response shape.
Capture operations extend the existing OPA API with configuration, explicit consent grant/revoke, create/get, chunk append, and client transitions. Completion and failure are worker-only transitions; browser inputs cannot assert them. The host derives private recording ownership and never accepts a tenant selector.
OpaPersonalSchedulingAuthorizationSchema defines private persisted approval bindings for human scheduling continuations. Receipts contain session and authority identifiers/digests, never bearer credentials. A changed policy or authority invalidates the queued approval; historical applied effects survive.
Capture processing authorization binds the owner, recording, consent, exact media digest, pinned model and processing approval. Transcript ingestion carries optional processing provenance. Transcript persistence retains immutable encrypted revisions and deletion tombstones; recorded artifacts cannot be manufactured by AI drafting.
OpaCaptureProcessingJobSchema binds a durable job to its recording-scope approval and pinned processing configuration. Transcript get/review contracts are 2.1.0 with additive structured segments, source capture and processing provenance. Recording completion does not imply transcript review or permission to share.
Transcript review is version 3.0.0 and requires exact source identity/digest plus separate source/review revision fences. The response includes an optional review receipt and server-derived canReview. Approval metadata is not permission to execute follow-up; effects must independently reprove current authority.
Reviewed outcome source binding
Outcome analysis 3.0.0 requires the exact transcript reference, source digest and review revision. AI runtimes must load authorized reviewed content and reprove current generation policy. Generated outcomes remain private when their source is private, and remain pending review. Citation membership checks do not establish semantic accuracy. CompanyOS binds its persisted review source through the private owner view. Durable asynchronous generation, downstream source-bound actions and live quality qualification remain incomplete.
Derived outcome artifacts now retain reviewedSource identity/revision/digest evidence without transcript text. Current source reproof is required for approval, publication, dispatch planning/execution and delivery. A worker without loadReviewedTranscript fails closed for bound artifacts. Legacy artifacts without this metadata retain their existing behavior; their source provenance is not retroactively qualified. CompanyOS still needs its complete production effect worker and deletion propagation through derived artifacts.
Derived artifact and copied-context reads reprove their reviewed source. Generation from copied transcript context preserves its binding, including on cached responses. Private artifacts require an explicitly reviewed shared copy before issuing any recipient or public share; public token resolution excludes private revisions. Recognizable transcript-derived content without a source binding fails closed pending qualification. These access controls do not replace physical erasure, retention or backup deletion.
Correcting and reviewing outcome drafts
Artifact review 3.0.0 accepts optional editedContentMarkdown when approving. The request still binds the displayed artifact revision and original content digest; the receipt approves the corrected digest. Human edit metadata records the prior digest, actor and timestamp. Empty edits, edits combined with rejection/CRDT snapshots, and independent edits during open collaborative sessions are rejected. A retry key cannot approve a different payload.
The private draft cards expose edit, approve and needs-changes controls using server-derived canReviewOutcomes. Uncertain review responses retain the current draft for retry; access denial removes it. Approval does not send messages, publish links or create Work tasks. Actual edited-review PostgreSQL qualification, complete collaborative editing and downstream actions remain open.
Durable outcome processing
Analyze 3.1.0 accepts executionMode: background on its existing route. Repeating the exact request observes the same persisted job; processing responses carry processingJobRef, while completion returns the saved outcome. The private draft client selects background mode when the server advertises it and can stop polling without cancelling accepted work. Terminal failures remain failures.
Apply additive migration 0080, configure a dedicated companyos_outcome_dispatcher login, and enable OPA_OUTCOME_JOBS_ENABLED=1 only with approved pinned OPA_MEETING_AI_* EU processing. The every-minute /api/cron/opa-outcome-processing route requires CRON_SECRET. Runtime credentials must not be superuser, BYPASSRLS or a member of opa_migrator. The queue admits four global jobs and one per owner, bounds pending owner jobs at 25, retries at most five times and uses six-minute fenced leases. Current membership, module entitlement, intelligence policy, source consent/review and model binding are rechecked before generation and commit.
Outcome persistence and completion share a transaction; model calls are outside SQL. Queue rows contain references and authorization evidence, not transcript text or credentials. Model cost may repeat after a crash before commit. Terminal-job self-service repair, queue retention/deletion propagation, live model/provider qualification and production rollout remain open. No production activation is implied by the local tests.
Evidence-bound action proposals
Meeting prompt 2.0.0 requires structured actions for action-plan generation. Each proposal carries a title, optional description, explicit/uncertain classification and exact quotations tied to supplied citation references. Missing action output or unsupported quotes fails generation. Model output cannot supply owners or deadlines. Quote membership proves traceability, not semantic correctness.
Action-plan artifacts retain actionProposals, and their content digest covers prose and structured actions together. Artifact review 3.1.0 requires acknowledgeActions for a nonempty task list. Reviewers may edit titles/details while preserving verifiable source evidence. The private draft cards display proposed tasks, uncertainty and source quotes with an explicit approve-draft-and-tasks label. Prose-only or collaborative edits clear stale structured actions; edited structured input is revalidated against the current approved transcript.
This creates reviewed proposals, not Work commitments. Assignment, due dates, canonical Work projection, downstream delivery, deletion propagation and the live precision/recall benchmark remain open. Prompt-version changes invalidate incompatible queued generation bindings; never relabel old processing as using the new prompt.
Approved action to canonical Work
opa.task.project 3.0.0 projects one approved structured action through the existing task route. The request binds artifact revision/digest, approval receipt, action reference and selected workspace. It requires explicit workspace disclosure acknowledgment and confirmation for an uncertain proposal. The UI exposes this action only for approved task lists and server-derived projection permission.
Only the reviewed title and details are transferred; raw/private transcript text and source quotes are not copied into Work. Assignees and deadlines remain unset. Current outcome.commit policy, transcript review/consent and Work workspace write authority are rechecked. Work event/idempotency/outbox and the OPA projection receipt commit in one transaction. Repeated projection returns the existing Work object; a receipt represents committed task creation, not task completion or realtime projection convergence.
New owner capability manifests include opa.task.project; existing grants require an authorized update and are not silently widened. Legacy input-only projection clients must update to 3.0.0. CommunicationOS delivery, assignment/due-date controls, real-authority deployment qualification and full release gates remain open.
Native meeting mutation authority
OPA meeting workspace routes use bearer-only session verification whenever Authorization is present. Cookies and test-session headers are stripped before bearer verification; invalid tokens cannot borrow browser authority. Verified bearer POST requests need no fabricated Origin or CSRF. Browser POST requests retain exact origin and current session CSRF checks. Entitlements and current domain authority remain mandatory.
Only GET/POST are accepted, and mutation bodies are streaming-bounded to 1,100,000 bytes even without Content-Length. The CommunicationOS native-session exchange uses the same isolated bearer resolver. Route tests do not qualify signed native clients, MFA/deep links, capture permissions or app-store acceptance.
OpaLegacyMeetingBindingSchema defines host-verified immutable legacy/canonical identity bindings. It rejects diagnostic shadow references and records original evidence provenance. Identity evidence does not establish workflow parity or enable route cutover. Existing operation versions and booking links remain unchanged.
OpaMeetingGraphContextProjectionSchema declares explicit meeting/owner binding, context text, claim kind, sensitivity and uncertainty metadata for CompanyOS graph preparation. Routing metadata is not an ACL or sharing grant. Source adapters must verify all cited records and fragments, and generation must reprove the exact authorized snapshot before and after model execution.
Transcript review execution invariants cover shared web/native review clients, exact capture-bound private display and source/owner/review response checks. These additions do not change opa.transcript.review_decide 3.0.0 wire input or output. Native transcript approval remains distinct from generation, task projection and communication delivery.
Reviewed-outcome execution invariants now cover shared native/browser request identities, current private source-bound draft presentation, and meaningful generation completion. Empty or mismatched completion responses are not evidence of generated drafts. Existing analyze, artifact-list and artifact-review wire versions remain unchanged.
Work projection execution invariants require explicit client acknowledgments and meaningful matching Work object/event receipts across browser and native presentation. opa.task.project 3.0.0 wire input/output remains unchanged. Approved proposals, committed Work objects and delivered follow-ups are distinct states.
Capture webhook settlement reuses the immutable owner-scoped meeting idempotency ledger. SqlCaptureWebhookReceiptStore on the runtime ./database subpath accepts host-verified notification identity and a transaction-only apply callback. Current authority/provider binding is reproved before writes and commit, including replay; changed payload/capture binding conflicts. Receipt and domain writes commit together. Receipt storage contains digests and a content-free result. The host still owns signature verification, durable bot mapping and HTTP routing; external effects must use an outbox, never the callback transaction.
Bot capture bindings are distinct from reviewed recorder-source matches. SqlBotCaptureBindingStore on the runtime database subpath persists immutable encrypted capture/provider mappings and a reverse identity index in the existing meeting receipt ledger. A host-provided authenticated encryption port binds full owner scope and the binding digest. Binding confirmation must reprove actual capture/start intent and provider evidence; reads require current owner authority. Identity receipts never override capture consent, revocation or deletion. HTTP callback routing and the live bot host remain separate integration work.
createBoundBotWebhookSettlement composes encrypted bot identity with webhook receipts on one owner transaction. The host supplies a verified owner and deployment reference; the stored provider/bot/deployment mapping must match before current capture policy is reproved. resolveInTransaction avoids borrowing a second connection. Deployment-aware callback identities have separate receipt namespaces; legacy inputs preserve existing keys. Raw-signature verification, owner routing and domain lifecycle application remain host responsibilities.
Bot reconciliation uses additive migration 0084 and a coalescing owner-scoped request row. Verified callback intake defaults to enqueueing reconciliation in its receipt transaction, rather than applying delayed provider state. Workers claim three-minute leases, one active per owner, with five failed attempts and a retry delay. New notifications during a lease remain queued after completion; expired/replaced workers cannot settle. More notifications cannot revive an exhausted job. The provider-fetch worker, repair UI and deployment dispatcher still require integration; do not activate callback routes before migration and host wiring.
runBotReconciliation resolves the immutable bot binding under a current lease, fetches provider state outside SQL, then rechecks binding/lease before transactional apply. Hosts provide an adapter that rechecks effect authority immediately before provider access and a domain/outbox-only apply function. Unknown/mismatched observations fail; retries store a stable content-free error. Failed settlement is distinguished from confirmed lease fencing. Provider readiness does not prove media ingestion or final transcript quality. Production dispatcher, actual capture projection and deployed-provider binding remain required.
dispatchBotReconciliation runs one bounded owner cycle using an explicitly authorized due-page reader. Due rows are ordered by availability and capped at 100 (default 10); duplicates or over-budget pages are rejected. Candidate failures do not suppress later rows, and cancellation stops additional claims. This is not a global privileged dispatcher: production owner enumeration, periodic scheduling and provider/lifecycle bindings remain host-owned and unqualified until integrated.
Bot reconciliation admission is bounded per owner: at most 100 queued/leased captures and 10,000 retained capture rows. An owner admission lock prevents concurrent inserts from exceeding these bounds. Wakeups for existing queued/leased captures coalesce at capacity; idle activation needs a pending slot. Failed rows remain terminal and do not regain retries from webhook traffic. Retention/repair operators must manage exhausted retained capacity before further new captures are admitted. These application-path limits do not replace global tenant/service capacity qualification.
repairBotReconciliation is an explicit authorized reset for a failed job at its expected requested revision. It records operator, reason, prior attempt count and failure code in the immutable receipt ledger, enforces pending admission and reproves repair authority before commit. Exact retries return the original repair receipt without resetting later work. Callback admission never invokes repair. An operator-facing endpoint/UI and production repair authority must still be composed.
Confirmed bot bindings may retain the existing capture authorization context inside their encrypted payload. CompanyOS guardCompanyBotCapture requires this context, the bot capture enable flag, current background membership/policy digests, the exact active bot capture, unexpired retention, consent and current meeting access. It reuses the existing background authority resolver rather than browser session state. Legacy bindings without context remain readable identity evidence but cannot execute background bot work. Concrete dispatcher/provider wiring and cleanup authority remain separate integration requirements.
SqlBotDeploymentStore persists owner-scoped encrypted deployment configuration revisions in the existing immutable receipt ledger. Configuration contains HTTPS endpoints, managed/customer-operated mode, EU region, disabled/active/draining state and server secret references; no credential values. New deployments default disabled. Activation requires licensing/processing references and the host administration guard must verify their evidence. Writes use expected revisions and current operator authority; replay cannot overwrite later configuration. Operator UI, concrete secret-store binding, bot-start state enforcement and live deployment qualification remain open.
CompanyOS deployment resolution now permits existing-bot reads only for active or draining configurations. It captures the encrypted registry revision, lazily resolves the owner-scoped API secret, and rechecks configuration before secret access and again before HTTP dispatch. Disabling or rotating configuration invalidates pending reads. SqlBotDeploymentStore.readInTransaction reuses the effect-authority transaction without acquiring another connection. Administrative UI, concrete secret-store binding, bot starts, global scheduling and live provider qualification remain open.
Private meeting notes
CompanyOS exposes one private human-authored notes draft per meeting through additive opa.meeting_artifact.get_note and opa.meeting_artifact.save_note operations at GET/POST /api/v2/opa/smart-meetings/:meetingRef/notes. Existing meeting-work-session management permission authorizes this personal authoring surface; recording, transcript generation and model credentials are not prerequisites. Saves use expectedRevision (zero for creation), at most 100000 characters and a stable idempotency key. Notes remain live_notes/private_user/draft, persisted in the existing encrypted aggregate. Empty content clears the draft. Revision conflicts preserve the local draft and show the latest saved notes before an explicit choice to continue. Saving notes creates no Work task and sends no message.
Work planning accepts an additive completedWork snapshot of canonical Work references and aggregate revisions. Hosts must load it from the same authorized event replay as placement candidates. This lets completed prerequisites satisfy dependency constraints without inventing estimates, removing dependency references or placing completed objects. Duplicate and contradictory completion declarations fail closed.
Capture-session contract v1.1 documents source-bound client recovery: rehash acknowledged prefixes, preserve source/type/consent/policy and monotonic byte progress, and keep a stable finish identity across retries. Existing capture HTTP schemas remain unchanged.
Processing endpoint provenance
OpaProcessingEndpointSchema adds a canonical HTTPS origin and declared geography to transcript, generation and outcome-binding metadata. The new field is optional for historical records; absence is not regional qualification. New CompanyOS model effects require a matching explicit endpoint and geography covered by current processing approval. EU/EFTA is distinct from strict EU; storage placement, model availability, retention and control-plane processing remain independent evidence.
Recent private meetings are available through additive opa.meeting_workspace.recent (GET /api/v2/opa/private-meetings?expectedOwnerScopeDigest=...). Use the existing private creation-context digest; it prevents stale scope selection and grants no authority. The fixed latest-twenty view uses stored timestamps/readiness and optional 160-character canonical manual-note previews. Current authority is reproven before and after the encrypted owner read, and no caller scope or limit is accepted. CompanyOS renders snippets as plain text and reopens the existing meetingRef URL.
Gateway transit and inference
Outcome binding v1.2 and preparation execution v1.3 add explicit Gateway routing metadata. Provider inference may be pinned to EU while the Gateway endpoint is recorded with geography other; an independent transit approval, non-Mistral provider allowlist, zero-data-retention and no-training controls are mandatory. New Gateway provenance requires these fields. Historical Mistral records remain readable without qualifying new effects. No activation or regional qualification is granted by schema validation.
The canonical model binding implementation lives in meeting-model-binding.ts; existing outcome-module and root exports remain compatible. Preparation can reuse it without importing capture-job contracts. This extraction changes no serialized shape or execution authority.
Durable AI preparation requires a configured admission adapter before database or model work. Omission returns preparation_admission_required; manual generation remains available without model admission. CompanyOS already binds the SQL admission store. Existing stored artifacts and request records remain unchanged.
CompanyOS uses one processing-readiness predicate for the capture configuration view and new-session admission. New captures check readiness before insertion and before commit. Exact authorized create retries bypass new-session admission; existing media can still be uploaded and recovered under current consent, policy and source controls. An unavailable processor does not silently collect new recordings.
Gateway EU response evidence accepts both zone and specific endpoint scopes only when geoRegion is explicitly eu. A more specific EU endpoint is not a global fallback. Missing/global/non-EU evidence remains rejected; requested routing flags alone never prove the served geography. This does not grant private Gateway transit approval.
Explicit authorization policy_suggestion is available only for planning.propose under an effective suggest policy. The host must hold its durable fence, reprove authority/resource access and current policy, and recompute the proposal inputDigest. No command/approval/delegation evidence may be mixed into this intent. Legacy intents and all other actions retain their evidence requirements. Execution is restricted by the host to proposal persistence; it does not authorize placements, Work commits, capture, sharing or delivery.
Planner inputs optionally carry unscheduledWork for owner-selected pending items requiring an estimate. They retain Work revisions, appear as estimate_required, and never receive invented durations or placements. Existing callers default to an empty list.
Published browser conditions select the emitted browser artifacts alongside existing Node/Bun/type targets. Export keys and source behavior are preserved; this packaging metadata does not activate providers or grant execution authority.
Canonical automation policy resolution
The existing ./opa-automation-policy leaf exports resolveOpaAutomationPolicy. It owns the deterministic hierarchy/default/ceiling rules alongside their schemas and types. The resolver validates host-supplied ancestry and produces the same canonical digest input; a policy result is never an execution grant. Existing module and runtime authorization imports forward to this implementation. The package root retains its existing exports; use the policy leaf for the resolver.
Declared capabilities.
Lib Organization Planning Spec
Provider-neutral organization, planning, agenda, booking, and auto-scheduling contracts for autonomous-company operations.
Use it to
Adopt provider-neutral organization, planning, agenda, booking, and auto-scheduling contracts for autonomous-company operations
Requires
TypeScript
Choose another boundary when
The @lssm-tech/lib.organization-planning-spec package constraints do not match the target runtime or platform.
These are package-manifest entry points. Named symbols listed above come from the capability catalogue; this is not an exhaustive TypeScript symbol reference.
