ContractSpecContractSpec

Start with OSS

Back to changelog index

8.0.5

Aug 05, 2026 · 12 packages · 51 unique changes · 18 release entries

appsbundlesintegrationslibsmodulesBreaking changes

This release affects the integrations, sharedLibs, solutions familyies.

Run contractspec connect adoption resolve --family integrations to see how it impacts your project.

Release summaries

  • adaptive-opa-suite-experience

    Add a RoleMorph-safe adaptive OPA workspace, explicit tenant-scoped home mode, reusable planning primitives, guided setup, and truthful six-step booking.

    integrator

    OPA hosts can render three canonical modes, guided setup, and six booking steps while keeping authority and lifecycle decisions server-owned.

    maintainer

    Mode and action matrices, en/fr/es catalogs, tenant-scoped preference parsing, and public booking safety projections have deterministic tests.

  • companyos-seo-discovery

    Add least-privilege public-profile SEO generations and always-on CompanyOS sitemap, canonical metadata, robots, and LLM discovery surfaces.

    integrator

    Anonymous profile discovery exposes only handle, revision, publishedAt, and immutable pagination metadata. Existing public lookup remains unchanged.

    maintainer

    Reuse the managed CompanyOS database, migrate and refresh the projection, prove the transaction-local PostgreSQL roles, deploy API before web, then submit the healthy sitemap index.

  • g006-profile-backend

    Add provider-neutral profile operations and transactional draft, immutable publication, revoke, cache-outbox, and tenant-authoritative owned-booking readiness persistence.

    maintainer

    Maintainers gain generated opa.profile operation schemas, a 64,000-byte mutation cap, transactional profile persistence, and durable cache invalidation leasing.

    integrator

    Integrators can load, save, preview, reorder, publish, revoke, and publicly resolve tenant profiles while owned-live publication uses tenant-authoritative health.

  • google-calendar-topology-preferences

    Add opaque provider-enumerated Google Calendar topology materialization with CAS, audit preimages, and explicit Europe/Paris scheduling-preference persistence.

    integrator

    Admins can choose only calendars returned by Google and persist protected booking topology plus scheduling preferences without exposing raw provider identifiers or overwriting event types.

  • managed-companyos-booking-lifecycle-contracts

    Add provider-neutral public profile and durable booking lifecycle contracts while preserving v1 availability and confirmation compatibility.

    integrator

    Public booking clients can adopt explicit intent, status, cancel, reschedule, and protected approval contracts with opaque references.

    maintainer

    Calendar topology, sync freshness, notification ownership, and v1 compatibility requirements are now explicit release gates.

  • managed-companyos-google-meet-contracts

    Add provider-neutral Google Meet event configuration and least-privilege managed Google Calendar conference request/result normalization.

    integrator

    Profile event types can select google_meet while legacy payloads default to none; managed Google booking writes return a normalized conference status and expose only verified HTTPS meet.google.com video links.

    maintainer

    Known-ID create retries use one non-PII conference request ID per event, replacement events receive a distinct ID, and full updates preserve existing conference data with conferenceDataVersion=1.

  • managed-companyos-smart-meeting-durable-prepare

    Prepare durable, availability-aware smart meetings from an authenticated Managed CompanyOS surface while keeping every external effect approval-gated.

    customer

    Authorized users can prepare a localized smart-meeting agenda and availability-aware time proposals from desktop or mobile, with explicit approval and no-event-created states.

    integrator

    Session-derived tenant/workspace authority, Google availability refresh, tenant/RLS persistence, audit, and outbox composition are owned by the API host.

    maintainer

    The existing run-manual operation remains compatible; the new strict browser intent and redacted response DTOs are additive.

  • managed-companyos-smart-meeting-lifecycle

    Approve, schedule, monitor, cancel, and reschedule prepared smart meetings through the canonical fenced Google Calendar and Google Meet booking saga.

    customer

    Authorized approvers can schedule, monitor, cancel, and reschedule a prepared meeting from mobile or desktop and open Google Meet once ready.

    integrator

    The authenticated host joins smart-meeting proposals to the canonical booking saga while keeping topology and provider authority server-side.

    maintainer

    New lifecycle operation keys and protected smart-event metadata are additive; legacy public-booking payloads and operation identities remain compatible.

  • opa-os-static-safety

    Add a static safety gate and documentation for OPA OS provider-neutral release verification.

    maintainer

    Maintainers can run a repo-level OPA OS static safety check before release to prove the planning surfaces remain provider-neutral and credential-free.

    integrator

    Integrators get documented verification that OPA examples do not perform live calendar writes, client sends, provider calls, or production credential reads.

    agent

    Agents have a deterministic command for checking OPA approval-packet and external-effects-blocked invariants before claiming readiness.

  • opa-os-v0-1-implementation

    Implement OPA OS v0.1 local/manual planning, agenda, and booking proposal primitives.

    maintainer

    Maintainers get an additive OPA v0 entrypoint with provider-neutral schemas, action contract manifest, deterministic local functions with caller-supplied audit timestamps, fixture scenarios, markdown export, and audit payloads.

    integrator

    Integrators can generate local/manual day plans, agendas, and booking proposals while preserving human approval boundaries for external calendar or client-facing effects.

    agent

    Agents can propose OPA artifacts with confidence, assumptions, required approvals, source refs, risk summaries, and audit event payloads.

  • opa-production-runtime

    Ship the Organization Planning & Agenda (OPA) production runtime — additive operation/optimizer/ time/public-booking/governance/translation contracts, a new fail-closed execution runtime lib (authz, BYOK vault, RLS-proven opa_* persistence, outbox, scheduler), and OPA calendar/notification/ personalization bridges plus Microsoft Graph / CalDAV / ICS calendar providers.

    maintainer

    OPA production execution is additive: the v0 manual-loop primitives are unchanged. New OPA operation/event/model contracts, public-booking, optimizer, DST-safe time, governance, and translation surfaces sit in organization-planning-spec; the new organization-planning-runtime lib owns execution (buildOpaOps, fail-closed authz, BYOK crypto/vault, RLS-proven opa_* persistence, outbox, scheduler/optimizer worker, governance, observability, install kit) with no provider SDKs. The module gains a 12th calendar_execution adapter port; its manual-loop externalEffectsBlocked widened from literal true to boolean (behaviour-compatible, type-narrowing break only).

    integrator

    Build the OPA registry with buildOpaOps from organization-planning-runtime, bind the calendar_execution port via opa-calendar-bridge (over a provider-calendar implementation), wire notifications through opa-notification-bridge (inject email/SMS transports + a durable queue, feature-flag gated, fail-closed), and adapt per user/role via opa-personalization-bridge. Host mounting (REST/GraphQL/MCP + the public booking page) lives in app.organization-planning-host; the Subject -> HandlerCtx projection is a documented TODO until the identity-rbac/AuthOS wave.

    customer

    Operators can run OPA end to end — propose/agenda/booking, authorized calendar execution, a public booking page where anonymous visitors pick and confirm a slot, email/SMS confirmations and reminders, a continuous optimizer that adapts to learned preferences, and RGPD-compliant governance — rendered in fr/en. Live provider credentials are wired per deployment; every external effect is authorization + approval gated and fail-closed.

  • opa-profile-family-v2

    Replace the OPA profile family with owner-scoped v2 contracts, server-owned authority, product-scoped handles, exact versioned capabilities, and v2-only API and browser routes.

    maintainer

    Profile mutations no longer accept canonical topology, scheduling resources, provider authority, or calendar authority. The server derives owner scope from the verified session, preserves protected state, and rejects protected authority recursively.

  • opa-v2-authority-database-remediation

    Complete OPA v2 authority isolation and reconcile empty legacy OPA schemas to the canonical owner-scoped database shape through migration 0037.

    maintainer

    Authority is server-derived and recursively absent from browser payloads. Migration 0037 is explicit opt-in, locks all existing OPA tables before counting, and aborts on business data.

  • opa-v2-contract-catalog-correction

    Correct the breaking OPA v2 contract freeze for public booking confidentiality, canonical lifecycle events, typed handlers, and exact package exports.

    integrator

    Integrators must consume the root operations entrypoint, use the bounded public booking projection, and bind handlers from the named v2 spec registry.

    maintainer

    Maintainers get exact catalog, lifecycle, confidentiality, typing, and generated-export proofs without claiming downstream runtime completion.

  • opa-v2-contract-catalog-freeze

    Freeze the exact breaking OPA v2 operation and event catalog and remove the public v1 contract and compatibility surface.

    integrator

    Integrators must replace every OPA v1 operation/event identity and transport with an exact v2 catalog key and must bind concrete v2 handlers before mounting REST, GraphQL, or MCP surfaces.

    maintainer

    Maintainers get one tested 80-operation and 29-event compatibility surface with strict payloads, exact capabilities, and deterministic policy and lifecycle semantics.

  • opa-v2-production-closure

    Establish the breaking/no-v1 governance and reset/restore evidence contract required before OPA v2 production closure.

    maintainer

    OPA v2 is an intentional breaking migration with no supported v1 compatibility, dual-write, mixed-schema, downgrade, or in-place fallback lane. Reset and restore require redacted target, encrypted snapshot, schema manifest, external authorization, Connect, and isolated rehearsal evidence.

    integrator

    Integrators must migrate cleanly to v2 and preserve non-OPA CompanyOS and standalone Pactena boundaries; no v1 compatibility shim is supplied.

  • organization-planning-agenda-core

    Add Organization / Planning / Agenda core contracts for autonomous-company scheduling and planning.

    maintainer

    Maintainers get a provider-neutral contract package for availability, booking/routing, capacity, agenda blocks, schedule decisions, and orchestration handoff evidence.

    integrator

    Hosts can model booking, focus planning, habits, and project auto-plans without calendar provider writes or optimizer runtime coupling.

    agent

    Agents can produce reviewable schedule decisions with authority, policy, conflict, capacity, idempotency, replay, and approval evidence refs.

  • organization-planning-cross-module-core

    Organization/Planning/Agenda Phase 7 - Full Core Cross-Module Integration

    maintainer

    Cross-module contracts with PlanningModuleRef, PlanningModuleHandoff, PlanningAdapterPortObligation, OrganizationPlanningCrossModulePlan, PlanningCoreReadiness for developers, architects, contract-authors, module-authors, integration-authors, and ai-agents.

    integrator

    Pure projection helpers projectToCrossModulePlan and cross-module validation, async composition with adapter port execution composeOrganizationPlanningCore, typed adapter port interfaces for all 12 modules, and deterministic fake adapters for testing.

Deprecations

  • - All OPA v1 operation specs, event specs, transports, aliases, public-confirm compatibility wrappers, and legacy repair operations are removed from the supported source and distribution export surfaces without a compatibility lane. Downstream runtime consumers must migrate during G004b.
  • - Direct ./operations/* package subpaths and every OPA v1 booking compatibility identity remain unsupported. Only ./operations is a public v2 entrypoint.
  • - OPA v1 runtime/schema compatibility, dual-write, mixed-schema operation, downgrade, and in-place fallback are unsupported for the v2 production closure.
  • - Remove the opa.profile.draft_load, preview, draft_save, reorder, publish, revoke, public_lookup, and public_list operation identities at 1.0.0; use the same operation keys at version 2.0.0.

Migration guide

  • Apply the profile SEO role split

    Required

    Profile SEO reuses the managed CompanyOS database while reader and builder operations assume separate transaction-local NOINHERIT roles.

    1. Reuse LSSM_STUDIO_DATABASE_URL for the managed CompanyOS API and profile SEO; no SEO-specific database or connection variables are required.
    2. Run the existing governed companyos:db:migrate:live lifecycle and retain its approval and backup/checkpoint evidence.
    3. Run bun --cwd packages/apps/api-application-monolith run profile-seo:postgres-conformance.
    4. Verify readiness, deploy web with API_ORIGIN, fetch every sitemap child, then submit the index in Search Console.

  • Apply tracked Google topology app migration 0017

    Required

    Add protected provider mappings, versioned preferences, topology audit, and connection versioning.

    When: Before enabling Google Calendar topology selection in any environment.

    1. Capture a database backup/checkpoint receipt and current redacted row counts.
    2. Apply tracked app migration 0017 transactionally after immutable computed migration 0013.
    3. Verify provider mappings remain server-only and topology versions start at zero for existing connections.
    4. Exercise one versioned save and stale-version rejection in Preview before Production promotion.

  • Scope Google scheduling preferences to an active workspace

    Required

    Apply API migration 0031_smart_meeting_workspace_calendar.sql. Existing tenant-only calendar preference rows remain preserved and fail closed until an authorized workspace topology save binds them.

    When: Before enabling smart-meeting preparation in a multi-workspace tenant.

    1. Apply the API migration ledger through version 0031.
    2. Re-save each legacy Google calendar topology from its authorized workspace.
    3. Verify readiness independently for every active workspace.

  • Add canonical booking linkage to persisted smart meetings

    Required

    Apply API migration 0032_smart_meeting_booking_lifecycle.sql. Existing proposals remain unlinked and valid; new links are nullable, tenant-scoped, unique, and idempotent.

    When: Before enabling smart-meeting approval, status, cancel, or reschedule.

    1. Apply the API migration ledger through version 0032.
    2. Verify migration 0031 active-workspace calendar bindings remain current.
    3. Verify proposal-to-booking uniqueness and RLS in the target PostgreSQL database.

  • Migrate profile persistence to owner scope

    Required

    Key profiles by the full owner tuple and handles by product plus handle.

    When: Before serving v2 profile traffic.

    1. Persist productRef, tenantRef, workspaceRef, and userRef on canonical profile topology.
    2. Enforce one canonical owner tuple per profile aggregate.
    3. Enforce handle uniqueness by productRef and handle across all owners.

  • Migrate API routes and SEO cursors

    Required

    Replace v1 profile routes and durable public-list cursors with their v2 forms.

    When: Before deploying v2 web and API applications.

    1. Replace /api/companyos/profile/** with /api/v2/opa/profile/**.
    2. Replace /api/public/profile/** and /api/public/profiles/** with /api/v2/public/profiles/**.
    3. Regenerate sitemap generations because v1 public-list cursors are not accepted by v2.

  • Grant versioned profile capabilities

    Required

    Replace unversioned profile grants with the exact v2 capability metadata.

    When: Before enabling v2 profile operations.

    1. Grant opa.profile.read@2.0.0 for draft, preview, public lookup, and public list reads as applicable.
    2. Grant opa.profile.manage@2.0.0 for draft save and reorder.
    3. Grant opa.profile.publish@2.0.0 and opa.profile.revoke@2.0.0 for lifecycle mutations.

  • Apply the OPA v2 canonical migration

    Required

    Reconcile an absent or exactly empty legacy OPA schema to the owner-scoped v2 shape.

    When: Before serving OPA v2 profile or booking traffic.

    1. Capture and validate the pre-migration 0001 through 0036 evidence ledger.
    2. Confirm all 31 governed OPA tables are absent or contain no business rows.
    3. Complete owner-tuple propagation for every runtime path before enabling 0037.
    4. Explicitly include migration 0037; its advisory and ACCESS EXCLUSIVE locks close concurrent-write deletion races.
    5. Do not reset a live or non-empty schema.
    6. Capture the after_v2_migration manifest with the exact 0001 through 0037 ledger.

  • Consume the corrected OPA v2 contract boundary

    Required

    Replace private public-booking outputs and untyped or internal imports.

    When: Before binding or publishing OPA v2 runtime and API surfaces.

    1. Import v2 contracts and handler types only from the root operations entrypoint.
    2. Return only bookingRef, state, and the optional paired start/end/timeZone projection from anonymous booking mutation and status handlers.
    3. Emit one transition truth whose event envelope exactly matches lifecycle payload from, to, action, and outcome.
    4. Complete G004b runtime and API migration before release promotion.

  • Replace v1 contract imports and host bindings

    Required

    Move consumers to the exact OPA v2 operation and event keys and install only handlers whose concrete v2 behavior and authority derivation exist.

    When: Before publishing or mounting any OPA operation surface from this major release.

    1. Import the v2 catalog and events from the operations entrypoint.
    2. Replace v1 REST, GraphQL, and MCP names with the generated v2 transport names.
    3. Derive owner scope, provider identifiers, credentials, and OAuth authority server-side.
    4. Remove v1 registry installation, compatibility aliases, and legacy public-confirm routes.
    5. Keep unimplemented v2 operations unavailable; do not install placeholder or no-op handlers.

  • Approve the clean OPA v2 reset and restore boundary

    Required

    Complete the external authorization and evidence packet before any reset.

    When: Before applying an OPA v2 migration to a target that contains OPA v1 objects or data.

    1. Validate a redacted target fingerprint and before-schema manifest against the G001 schemas.
    2. Bind the canonical target protocol, host, port, SSL mode, database, principal, and provider identity to a signed digest observed independently twice.
    3. Create and independently verify an encrypted snapshot receipt.
    4. Validate reset authorization and complete an isolated, non-live all-pass restore rehearsal with distinct operators and provider effects disabled.
    5. Obtain named data-owner, database-owner, security, release, reset-operator, and restore-verifier authority.
    6. Obtain fresh ContractSpec Connect plan, verify, review, and replay evidence.
    7. Preserve all non-OPA CompanyOS objects and exclude the standalone Pactena boundary.

Upgrade steps

  • Keep adaptive presentation below authority and policy

    manual

    Resolve server authority and RoleMorph before applying presentation preferences or accepted suggestions.

    Packages: @lssm-tech/lib.organization-planning-spec, @lssm-tech/lib.design-system, @lssm-tech/bundle.managed-companyos, @lssm-tech/app.web-application-monolith

    1. Persist only explicit user choices; never persist the adaptive result.
    2. Keep auditor surfaces read-only and AI externally binding actions blocked.
    3. Suppress unsafe availability and preserve distinct booking outcomes.

  • Deploy and verify the sitemap index

    assisted

    The sitemap shape changes from a URL set to an index and has an explicit static-only degraded state.

    Packages: @lssm-tech/lib.organization-planning-spec, @lssm-tech/lib.organization-planning-runtime, @lssm-tech/app.api-application-monolith, @lssm-tech/app.web-application-monolith, @lssm-tech/app.cli-contractspec

    1. Treat /sitemap.xml as a sitemap index rather than a URL set.
    2. Monitor X-Sitemap-Status and do not declare rollout complete while it is degraded.
    3. Verify every linked child before Search Console submission.

  • Adopt the durable public booking lifecycle contracts

    assisted

    Keep existing v1 clients unchanged while new asynchronous clients adopt intent, status, and manage operations explicitly.

    Packages: @lssm-tech/lib.organization-planning-spec

    1. Review the booking compatibility runbook before wiring runtime handlers.
    2. Keep all provider identifiers internal and serialize only validated public aliases.

  • Apply the additive conference migration before enabling Meet event types

    manual

    Managed Meet publication requires migration 0028 and the provider-effect worker deployment to move together.

    Packages: @lssm-tech/lib.organization-planning-spec, @lssm-tech/integration.provider-calendar, @lssm-tech/integration.opa-calendar-bridge, @lssm-tech/lib.organization-planning-runtime, @lssm-tech/app.api-application-monolith

    1. Apply migration 0028 before publishing an event type with google_meet.
    2. Deploy the API/provider-effect worker with the same release.
    3. Qualify ready, pending, failed, ambiguous, cancel, and reschedule against the target Google Workspace tenant.

  • Qualify the production planning and Google Workspace composition

    manual

    Keep the UI in an explicit degraded or unavailable state unless the OPA store and active-workspace calendar connection are current, and retain approval gates for every calendar write.

    Packages: @lssm-tech/lib.organization-planning-spec, @lssm-tech/lib.organization-planning-runtime, @lssm-tech/app.api-application-monolith, @lssm-tech/bundle.managed-companyos, @lssm-tech/app.web-application-monolith

    1. Verify the canonical OPA migrations and tenant RLS in the target database.
    2. Apply migration 0031 and re-save legacy Google topology per active workspace.
    3. Qualify Google OAuth, CalendarList topology, free/busy refresh, and token custody.
    4. Verify operations-manager, founder-approver, and enterprise-admin access.
    5. Keep provider creation and Google Meet dispatch behind the approved booking lifecycle.

  • Qualify the canonical Google provider-effect lifecycle

    manual

    Keep production activation gated until the existing booking worker, Google Workspace topology, OAuth custody, and ambiguity recovery are qualified for each target organization.

    Packages: @lssm-tech/lib.organization-planning-spec, @lssm-tech/lib.organization-planning-runtime, @lssm-tech/app.api-application-monolith, @lssm-tech/bundle.managed-companyos, @lssm-tech/app.web-application-monolith

    1. Verify enterprise-admin and founder-approver mutations and operations-manager read-only monitoring.
    2. Qualify selected-slot freshness and active-workspace write-calendar derivation.
    3. Qualify known-ID Google Calendar creation and optional Google Meet readiness.
    4. Exercise cancel, replacement create, old-event cancel, compensation, and operator repair.
    5. Confirm the web flow uses explicit status refresh and no automatic polling.

  • Run the OPA OS static safety gate before release promotion

    assisted

    Use `bun run opa-os:safety` with the existing OPA tests/typechecks when touching OPA spec, runtime, examples, or release capsules.

    Packages: @lssm-tech/lib.organization-planning-spec, @lssm-tech/module.organization-planning, @lssm-tech/example.organization-planning-agenda

    1. Keep live provider adapters, raw credentials, production writes, and client-message sends out of the deterministic OPA surfaces. No live calendar/provider adapters and no client message sending or calendar writes belong in this release lane.
    2. Keep future provider integrations in separate approval-gated lanes with redacted credential references.
    3. Preserve `externalEffectsBlocked: true` and approval-packet persistence until a reviewed adapter lane explicitly changes the boundary.

  • Use the OPA v0 local/manual entrypoint

    assisted

    Import from @lssm-tech/lib.organization-planning-spec/opa for availability, day planning, agenda, booking proposal, markdown export, and audit payload helpers.

    Packages: @lssm-tech/lib.organization-planning-spec

    1. Keep external booking and agenda sharing behind human approval.
    2. Use local fixture objects first; do not wire provider calendar writes through this package.
    3. Export markdown for Notion/manual review before adding integrations.

  • Adopt the additive OPA operation/optimizer/governance contracts

    assisted

    Wire the new OPA operation/event/model, public-booking, optimizer, time, governance, and translation surfaces from organization-planning-spec; the v0 manual-loop primitives are unchanged.

    Packages: @lssm-tech/lib.organization-planning-spec, @lssm-tech/lib.organization-planning-runtime, @lssm-tech/module.organization-planning, @lssm-tech/integration.opa-calendar-bridge, @lssm-tech/integration.opa-notification-bridge, @lssm-tech/integration.opa-personalization-bridge, @lssm-tech/integration.provider-calendar

    1. Adopt the new contracts from `@lssm-tech/lib.organization-planning-spec/operations` and the `@lssm-tech/lib.organization-planning-spec/opa/*` production subpaths; leave the v0 helpers as-is.
    2. Keep timezone arithmetic in `/opa/time` (DST-safe Europe/Paris) and user-facing copy in `/translations`; do not inline either in handlers.
    3. If you consumed the manual-loop result, note `externalEffectsBlocked` is now `boolean` (computed from `isOpaExecutionAllowed`), not the literal `true`.

  • Build the OPA runtime and bind the execution ports

    assisted

    Use createOpaRuntime (the install-kit drop-in) to assemble the registry with all deps, or buildOpaOps directly; bind the calendar/notification/personalization adapter ports through the OPA bridges, keeping provider SDKs and secrets in integrations.

    Packages: @lssm-tech/lib.organization-planning-spec, @lssm-tech/lib.organization-planning-runtime, @lssm-tech/module.organization-planning, @lssm-tech/integration.opa-calendar-bridge, @lssm-tech/integration.opa-notification-bridge, @lssm-tech/integration.opa-personalization-bridge, @lssm-tech/integration.provider-calendar

    1. Prefer the drop-in `createOpaRuntime(config)` from `@lssm-tech/lib.organization-planning-runtime/install`: one call assembles `buildOpaOps` with all OPA deps and fail-closed production defaults, returning `{ registry, deps, runManualLoop, runManualLoopDetailed }` plus `opaHandlerCtx`. `localDefaults: true` is DEMO/LOCAL only.
    2. For lower-level control, build the registry with `buildOpaOps(deps)` directly; reach the node-only `opa_*` persistence via the `./database` subpath, never the root barrel.
    3. Bind `calendar_execution` with `@lssm-tech/integration.opa-calendar-bridge` over a `@lssm-tech/integration.provider-calendar` implementation (Google / Microsoft Graph / CalDAV / read-only ICS feed).
    4. Wire notifications via `@lssm-tech/integration.opa-notification-bridge`: inject email/SMS transports and a durable job queue, keep `OPA_NOTIFY_EMAIL`/`OPA_NOTIFY_SMS` default-off, and let the host own recipient/PII derivation.
    5. Adapt per user/role with `@lssm-tech/integration.opa-personalization-bridge`; behaviour signals stay PII-minimised and RoleMorph/ACL is fail-closed.

  • Mount the OPA host surfaces and public booking page

    manual

    Expose the OPA registry on REST/GraphQL/MCP and serve the public booking page, projecting the authenticated Subject onto HandlerCtx (fail-closed).

    Packages: @lssm-tech/lib.organization-planning-spec, @lssm-tech/lib.organization-planning-runtime, @lssm-tech/module.organization-planning, @lssm-tech/integration.opa-calendar-bridge, @lssm-tech/integration.opa-notification-bridge, @lssm-tech/integration.opa-personalization-bridge, @lssm-tech/integration.provider-calendar

    1. Follow `app.organization-planning-host`: `createOpaRestHandler`, `createOpaGraphqlBuilder`, `mountOpaMcp`, and the `app/book/[link]` public booking page backed by the public-confirm op.
    2. Supply a real `ctxFactory`/`toolCtx` that projects the authenticated Subject; the placeholder projection is a documented TODO until the identity-rbac/AuthOS authz wave.
    3. Wire live provider credentials per deployment/vertical; the bridges inject transports and never hold secrets.

  • Regenerate release and llms surfaces

    auto

    Rebuild release capsules and generated package documentation from source.

    Packages: @lssm-tech/lib.organization-planning-spec, @lssm-tech/lib.organization-planning-runtime, @lssm-tech/app.api-application-monolith, @lssm-tech/app.web-application-monolith

    1. Run bun run release:build.
    2. Run bun run --cwd packages/apps/web-landing llms:generate.

  • Regenerate release surfaces

    auto

    Rebuild release and llms artifacts from the paired source capsule.

    Packages: @lssm-tech/lib.organization-planning-spec, @lssm-tech/lib.organization-planning-runtime, @lssm-tech/app.api-application-monolith, @lssm-tech/app.web-application-monolith

    1. Run bun run release:build.
    2. Run bun run --cwd packages/apps/web-landing llms:generate.

  • Regenerate agent-facing package guidance

    auto

    Rebuild package and full llms guides from the corrected package README.

    Packages: @lssm-tech/lib.organization-planning-spec

    1. Run bun run --cwd packages/apps/web-landing llms:generate.

  • Verify the exact OPA v2 contract surface

    manual

    Run the focused catalog, behavior, event, and export-surface proofs.

    Packages: @lssm-tech/lib.organization-planning-spec

    1. Run the package tests, typecheck, lint, and build listed below.
    2. Complete the downstream G004b runtime and CompanyOS migration before release promotion.

  • Promote only a clean OPA v2 schema and runtime

    manual

    Apply the approved OPA-only reset, migrate cleanly to v2, and release only after independent evidence review.

    Packages: @lssm-tech/lib.organization-planning-spec, @lssm-tech/lib.organization-planning-runtime, @lssm-tech/module.organization-planning, @lssm-tech/app.api-application-monolith

    1. Follow docs/runbooks/opa-v2-reset-restore.md and stop on every listed mismatch or missing approval.
    2. Do not run v1 and v2 against the same schema and do not claim production closure from documentation readiness alone.

  • Model scheduling and planning through provider-neutral refs

    assisted

    Use organization-planning packets for availability, booking/routing, focus capacity, agenda blocks, and auto-plan decisions before provider adapters execute.

    Packages: @lssm-tech/lib.organization-planning-spec

    1. Reference CompanyOS authority and policy gates rather than copying work ownership into calendar records.
    2. Reference orchestration workflow, step, idempotency, checkpoint, and replay evidence for cross-domain handoffs.
    3. Keep live calendar writes, notification delivery, payments, credentials, and optimizer runtimes outside this package.

  • Explore cross-module planning features

    auto

    New subpaths available for cross-module features including projections, fixtures, composition, adapter ports, and fake adapters.

    Packages: @lssm-tech/lib.organization-planning-spec, @lssm-tech/module.organization-planning

    1. Review the new cross-module contracts in lib.organization-planning-spec.
    2. Explore the three flagship cross-module fixtures (revenue booking, capacity reschedule, builder delivery).
    3. Use the async composition helpers for adapter port execution.
    4. Leverage deterministic fake adapters for testing without provider SDKs.

Unique release changes

  • - Expose the OPA registry on REST/GraphQL/MCP and serve the public booking page, projecting the authenticated Subject onto HandlerCtx (fail-closed).

    7 packages · 7 occurrences

  • - Ship the Organization Planning & Agenda (OPA) production runtime — additive operation/optimizer/ time/public-booking/governance/translation contracts, a new fail-closed execution runtime lib (authz, BYOK vault, RLS-proven opa_* persistence, outbox, scheduler), and OPA calendar/notification/ personalization bridges plus Microsoft Graph / CalDAV / ICS calendar providers.

    7 packages · 7 occurrences

  • - Use createOpaRuntime (the install-kit drop-in) to assemble the registry with all deps, or buildOpaOps directly; bind the calendar/notification/personalization adapter ports through the OPA bridges, keeping provider SDKs and secrets in integrations.

    7 packages · 7 occurrences

  • - Wire the new OPA operation/event/model, public-booking, optimizer, time, governance, and translation surfaces from organization-planning-spec; the v0 manual-loop primitives are unchanged.

    7 packages · 7 occurrences

  • - Add least-privilege public-profile SEO generations and always-on CompanyOS sitemap, canonical metadata, robots, and LLM discovery surfaces.

    5 packages · 5 occurrences

  • - Add provider-neutral Google Meet event configuration and least-privilege managed Google Calendar conference request/result normalization.

    5 packages · 5 occurrences

  • - Apply API migration 0031_smart_meeting_workspace_calendar.sql. Existing tenant-only calendar preference rows remain preserved and fail closed until an authorized workspace topology save binds them.

    5 packages · 5 occurrences

  • - Apply API migration 0032_smart_meeting_booking_lifecycle.sql. Existing proposals remain unlinked and valid; new links are nullable, tenant-scoped, unique, and idempotent.

    5 packages · 5 occurrences

  • - Approve, schedule, monitor, cancel, and reschedule prepared smart meetings through the canonical fenced Google Calendar and Google Meet booking saga.

    5 packages · 5 occurrences

  • - Keep production activation gated until the existing booking worker, Google Workspace topology, OAuth custody, and ambiguity recovery are qualified for each target organization.

    5 packages · 5 occurrences

  • - Keep the UI in an explicit degraded or unavailable state unless the OPA store and active-workspace calendar connection are current, and retain approval gates for every calendar write.

    5 packages · 5 occurrences

  • - Managed Meet publication requires migration 0028 and the provider-effect worker deployment to move together.

    5 packages · 5 occurrences

  • - Prepare durable, availability-aware smart meetings from an authenticated Managed CompanyOS surface while keeping every external effect approval-gated.

    5 packages · 5 occurrences

  • - Profile SEO reuses the managed CompanyOS database while reader and builder operations assume separate transaction-local NOINHERIT roles.

    5 packages · 5 occurrences

  • - The sitemap shape changes from a URL set to an index and has an explicit static-only degraded state.

    5 packages · 5 occurrences

  • - Add a RoleMorph-safe adaptive OPA workspace, explicit tenant-scoped home mode, reusable planning primitives, guided setup, and truthful six-step booking.

    4 packages · 4 occurrences

  • - Add opaque provider-enumerated Google Calendar topology materialization with CAS, audit preimages, and explicit Europe/Paris scheduling-preference persistence.

    4 packages · 4 occurrences

  • - Add protected provider mappings, versioned preferences, topology audit, and connection versioning.

    4 packages · 4 occurrences

  • - Apply the approved OPA-only reset, migrate cleanly to v2, and release only after independent evidence review.

    4 packages · 4 occurrences

  • - Complete OPA v2 authority isolation and reconcile empty legacy OPA schemas to the canonical owner-scoped database shape through migration 0037.

    4 packages · 4 occurrences

  • - Complete the external authorization and evidence packet before any reset.

    4 packages · 4 occurrences

  • - Establish the breaking/no-v1 governance and reset/restore evidence contract required before OPA v2 production closure.

    4 packages · 4 occurrences

  • - Key profiles by the full owner tuple and handles by product plus handle.

    4 packages · 4 occurrences

  • - OPA v1 runtime/schema compatibility, dual-write, mixed-schema operation, downgrade, and in-place fallback are unsupported for the v2 production closure.

    4 packages · 4 occurrences

  • - Rebuild release and llms artifacts from the paired source capsule.

    4 packages · 4 occurrences

  • - Rebuild release capsules and generated package documentation from source.

    4 packages · 4 occurrences

  • - Reconcile an absent or exactly empty legacy OPA schema to the owner-scoped v2 shape.

    4 packages · 4 occurrences

  • - Remove the opa.profile.draft_load, preview, draft_save, reorder, publish, revoke, public_lookup, and public_list operation identities at 1.0.0; use the same operation keys at version 2.0.0.

    4 packages · 4 occurrences

  • - Replace the OPA profile family with owner-scoped v2 contracts, server-owned authority, product-scoped handles, exact versioned capabilities, and v2-only API and browser routes.

    4 packages · 4 occurrences

  • - Replace unversioned profile grants with the exact v2 capability metadata.

    4 packages · 4 occurrences

  • - Replace v1 profile routes and durable public-list cursors with their v2 forms.

    4 packages · 4 occurrences

  • - Resolve server authority and RoleMorph before applying presentation preferences or accepted suggestions.

    4 packages · 4 occurrences

  • - Add a static safety gate and documentation for OPA OS provider-neutral release verification.

    2 packages · 2 occurrences

  • - Add provider-neutral profile operations and transactional draft, immutable publication, revoke, cache-outbox, and tenant-authoritative owned-booking readiness persistence.

    2 packages · 2 occurrences

  • - New subpaths available for cross-module features including projections, fixtures, composition, adapter ports, and fake adapters.

    2 packages · 2 occurrences

  • - Organization/Planning/Agenda Phase 7 - Full Core Cross-Module Integration

    2 packages · 2 occurrences

  • - Use `bun run opa-os:safety` with the existing OPA tests/typechecks when touching OPA spec, runtime, examples, or release capsules.

    2 packages · 2 occurrences

  • - Add Organization / Planning / Agenda core contracts for autonomous-company scheduling and planning.

    1 packages · 1 occurrences

  • - Add provider-neutral public profile and durable booking lifecycle contracts while preserving v1 availability and confirmation compatibility.

    1 packages · 1 occurrences

  • - All OPA v1 operation specs, event specs, transports, aliases, public-confirm compatibility wrappers, and legacy repair operations are removed from the supported source and distribution export surfaces without a compatibility lane. Downstream runtime consumers must migrate during G004b.

    1 packages · 1 occurrences

  • - Correct the breaking OPA v2 contract freeze for public booking confidentiality, canonical lifecycle events, typed handlers, and exact package exports.

    1 packages · 1 occurrences

  • - Direct ./operations/* package subpaths and every OPA v1 booking compatibility identity remain unsupported. Only ./operations is a public v2 entrypoint.

    1 packages · 1 occurrences

  • - Freeze the exact breaking OPA v2 operation and event catalog and remove the public v1 contract and compatibility surface.

    1 packages · 1 occurrences

  • - Implement OPA OS v0.1 local/manual planning, agenda, and booking proposal primitives.

    1 packages · 1 occurrences

  • - Import from @lssm-tech/lib.organization-planning-spec/opa for availability, day planning, agenda, booking proposal, markdown export, and audit payload helpers.

    1 packages · 1 occurrences

  • - Keep existing v1 clients unchanged while new asynchronous clients adopt intent, status, and manage operations explicitly.

    1 packages · 1 occurrences

  • - Move consumers to the exact OPA v2 operation and event keys and install only handlers whose concrete v2 behavior and authority derivation exist.

    1 packages · 1 occurrences

  • - Rebuild package and full llms guides from the corrected package README.

    1 packages · 1 occurrences

  • - Replace private public-booking outputs and untyped or internal imports.

    1 packages · 1 occurrences

  • - Run the focused catalog, behavior, event, and export-surface proofs.

    1 packages · 1 occurrences

  • - Use organization-planning packets for availability, booking/routing, focus capacity, agenda blocks, and auto-plan decisions before provider adapters execute.

    1 packages · 1 occurrences

Impacted packages

  • @lssm-tech/app.api-application-monolith

    Layer: apps · 4 changes

  • @lssm-tech/app.cli-contractspec

    Layer: apps · 3 changes

  • @lssm-tech/app.web-application-monolith

    Layer: apps · 3 changes

  • @lssm-tech/bundle.managed-companyos

    Layer: bundles · 3 changes

  • @lssm-tech/integration.opa-calendar-bridge

    Layer: integrations · 4 changes

  • @lssm-tech/integration.opa-notification-bridge

    Layer: integrations · 4 changes

  • @lssm-tech/integration.opa-personalization-bridge

    Layer: integrations · 4 changes

  • @lssm-tech/integration.provider-calendar

    Layer: integrations · 4 changes

  • @lssm-tech/lib.design-system

    Layer: libs · 2 changes

  • @lssm-tech/lib.organization-planning-runtime

    Layer: libs · 4 changes

  • @lssm-tech/lib.organization-planning-spec

    Layer: libs · 2 changes

  • @lssm-tech/module.organization-planning

    Layer: modules · 2 changes