Decisions
Reminders, approvals, customers and contacts, and onboarding keep CentraKit's own tables and services because the matching better-supabase blocks model a different product.
ADR 0032 moves a domain onto its better-supabase block when the block can adopt the domain's tables. The block scout against better-supabase 0.21 found four domains where the block is not a storage layer for the same feature but a different product. Adopting those blocks would drop features the contracts expose today, or change what the feature does for users. No library gap list makes them fit without first changing the block's purpose, so they are recorded here as exceptions to ADR 0032, each with the library feature that would reopen the question.
CentraKit keeps its own tables, SQL and packages/supabase-<domain> services for these domains. The contracts in packages/<domain> stay as they are.
reminders block. agenda_item_reminders are alarm definitions on an event, per event and not per user, exported as VALARM in calendar feeds and imported from Google. agenda_collection_notification_reminders are a user's default alarms per calendar, with an all-day form. CentraKit never sends them; the user's calendar client fires them. The block is a per-user server-side sender: it would add CentraKit notifications on top of the calendar alarm and lose the per-calendar defaults and all-day anchors. Reopen when the calendar block stores alarms as event data (library item L15, with the subject-level reminder options of L19 if server delivery is ever wanted).approvals block. CentraKit edits approval policies at runtime per organization, with platform floors, conditions on the request and confirm or authorize modes, routes to any, all or sequential approvers, managers and delegations, and consumes an approval once against a fingerprint of the request. Leave, expenses, timesheets, AI tool calls and workflow gates depend on that through approval_id. The block compiles static policies from the config and reads the latest status. Reopen when the block has policies in a table (C3), quorum modes and richer approvers (C4) and consume-once approvals with a fingerprint (C5), the core of library item L20.contacts block. A customer is one account, a business or an individual, that tasks, quotes, invoices, orders and assets reference by customer_id. contact_profiles is deliberately cross-tenant and one-to-one with an auth user, so staff, portal users and customer contacts share one person record, and reachability is multi-valued in contact_methods. The block splits companies from tenant-scoped people with single email and phone columns. No library change is planned: the cross-tenant person record is a product choice, not a gap. Deals, hiring and leases already accept the customer subject.onboarding block. The block is a product-activation checklist completed by outbox events. CentraKit onboarding is HR journeys: templates, items with assignee roles and due dates relative to a start or end date, tasks and equipment requests created from items, and a preboarding token. The HR journeys stay on CentraKit storage. The block may later serve organization activation, the checklist a new organization works through, which is a separate feature. Converging HR journeys would need per-step rows with assignee and due date in the enrollments block (library item D20).bsb_audit triggers and PermDock policies as before.time-tracking block's timesheet approval needs the approvals decision above before time tracking can move.Last updated on