Foundational Dotabase Provisioning

Description

Foundational Dotabase Provisioning creates and additively reconciles Memory Bank, Conversations, Artifacts, and HUMAN.md for each tenant.

Typed definitions describe the required schemas, views, behaviors, and starter elements. Provisioning checks the tenant for each foundation and creates what is absent through normal Dotabase services. Later reconciliation compares supported seeded structure and adds missing pieces without treating tenant-authored rows or edits as disposable seed data.

User Story

As a new customer, I receive a functioning core workspace immediately without manually creating system databases. My tenant setup invokes provisioning with my company and actor identity. The driver ensures the four registered foundations exist and can be called again safely after upgrades. I walk away with the core knowledge surfaces ready for use, while any content I later add remains mine during additive reconciliation.

Extension Surface

Fixed core: the four-member registry and provisioning semantics are platform-owned.

packages/dotabases/src/seed/registry.ts holds the fixed roster and typed definitions. Composition code may invoke provisioning, but a tenant cannot redefine which databases count as platform foundations or opt into destructive reconciliation behavior.

Capabilities & Limits

• Capability: Executes the scoped workflow described above through the cited live implementation paths.
• Capability: Preserves typed validation and applicable tenant, schema, lifecycle, or service boundaries.
• Limit: Reconciliation is additive and protects tenant content; it does not destructively force every historical row back to seed state. The feature can create missing foundations, repair supported schema additions, and reconcile views, behavior bindings, or widgets declared by the seed definitions. It cannot erase tenant changes merely because they differ from a newer seed, nor can it provision arbitrary marketplace databases. Conflicts requiring judgment remain outside the additive contract.

Implementation Map

• packages/dotabases/src/seed/registry.ts
• packages/dotabases/src/seed/provision.ts
• packages/dotabases/src/seed/reconcile.ts

Related Features

Creates Dotabase Workspaces and uses the same typed-definition discipline as Dotabase Templates.

Operationally, these relationships preserve a clear ownership boundary around Foundational Dotabase Provisioning. Neighboring features can invoke, supply, or consume its results, but `packages/dotabases/src/seed/registry.ts` remains the grounded implementation authority for this capability. That distinction prevents the catalog claim from widening into adjacent rendering, transport, or governance work. Teams can therefore combine the feature with the named dependencies while still diagnosing configuration, validation, and lifecycle behavior at the package boundary that owns it.