Initiatives
What each team is shipping, tracked by indicators rather than dates. An initiative is done when every indicator reaches its target and holds steady — no calendar commitments. Click Read full memo on any card for the operator-level scope.
Live - fetched 2026-07-13 09:18 UTC-generated 2026-07-13 09:18 UTC
Total
1
In flight
1
Complete
0
Retired
0
In flight
active initiatives; readiness read off the indicator dashboard, not a dateDelivery migration and Sales scheduling surface integration
In flightIn progress
Lock ledger drift rateprisma:error Invalid prisma.migrationCohortState.findMany() invocation - The table delivery.migration_cohort_state does not exist in the current database; post-Phase-4 audit pending (delivery=airtable/available, ledger=revenue-ledger/unavailable); ledger_reason=--dry-run skips Revenue ledger surface read; delivery snapshot: requested=0 held=0 confirmed=0 consumed=0 released=0→zero drift over a stable observation windowrefreshed 58d ago
Lock-to-ledger reconciliation drift between Delivery's reservation_lock state and Revenue's credit ledger; Delivery quality-bar target is zero, any nonzero value triggers a P1 investigation per the Delivery domain memo
trend:post-Phase-4: audit pending (delivery=airtable/available, ledger=revenue-ledger/unavailable); ledger_reason=--dry-run skips Revenue ledger surface read; delivery snapshot: requested=0 held=0 confirmed=0 consumed=0 released=0→at target for current nonempty Phase 4 cohort: audit-locks --source=postgres returned drift=0 (missing_in_revenue=0 state_or_amount_mismatch=0 ledger_footprint_mismatch=0) at as_of=2026-05-14T23:44:56.089Z with Delivery snapshot requested=4 held=2 confirmed=0 consumed=4 released=10→fetcher error: prisma.migrationCohortState.findMany failed because delivery.migration_cohort_state is not present in the current env DB; last good value post-Phase-4 unchanged→prisma:error Invalid prisma.migrationCohortState.findMany() invocation - The table delivery.migration_cohort_state does not exist in the current database; post-Phase-4: audit pending (delivery=airtable/available, ledger=revenue-ledger/unavailable); ledger_reason=--dry-run skips Revenue ledger surface read; delivery snapshot: requested=0 held=0 confirmed=0 consumed=0 released=0
ON time lesson start ratebaseline not capturable as defined: scripts/capture-operational-baselines.mjs was implemented to capture from Airtable and Postgres, but the Lesson source carries only the scheduled Start At, with no actual-start timestamp to compare against. Capturing this baseline requires adding an actual-start field to the Lesson capture (a source-data change, not a script change); tracked in delivery docs/migration-state-2026-05-14.md→no regression versus 4-week pre-migration baseline
Operational quality-bar metric from the Delivery domain memo; the migration must not regress on-time lesson-start during or after cutover
Attendance reconciliation accuracybaseline captured: scripts/capture-operational-baselines.mjs computes the metric from both sources and reports 6/6 = 100% over a trailing-52-week window, with Airtable and Postgres in exact agreement (the 4-week window is empty only because the dataset is sparse). attendance cohort flipped for Oahu and Dallas on 2026-05-15 after a clean drift-check:attendance; reads are now Postgres-backed for both orgs→no regression versus 4-week pre-migration baselinerefreshed 59d ago
Operational quality-bar metric from the Delivery domain memo; the migration must not regress attendance reconciliation accuracy during or after cutover
Dallas cutover lagat target: every cohort flipped for Oahu and Dallas within minutes of each other (lesson_site and lesson_site_config 2026-05-14 04:52, reservation_lock 2026-05-14 23:47, participant/lesson/attendance 2026-05-15 02:36-02:45); the Dallas-vs-Oahu lag is effectively zero, well within the 5-business-day bound→Dallas cutover lands within 5 business days of Oahu cutover
Time gap between Oahu and Dallas migration cutover; the parallel-region setup means the two should not diverge for long once the Oahu pattern lands
Phase 0 cohort state and audit scaffold landedat target: MigrationCohortState and LessonSite models in prisma/schema.prisma, migrations 20260513061000_phase_0_migration_cohort_state and 20260513061100_phase_1_lesson_site applied, lib/migration-cohort/ service + tests present, scripts/audit-locks.mjs rewritten with real Airtable reads + Revenue lock-state API caller + three-bucket drift comparator + as_of capture, npm run audit:locks -- --dry-run returns delivery=airtable/available→migration_cohort_state table applied in Delivery Postgres schema (model in schema.prisma plus a generated migration in prisma/migrations/) and scripts/audit-locks.mjs in place with real Airtable Credit Reservations reads wired against operator AIRTABLE_OPERATIONS_TOKEN credentials, dry-run reporting delivery=airtable/available
Phase 0 standalone deliverables under Delivery's control; flips green now that the Phase 0 migration applied and the audit-locks scaffold has real Airtable reads
Audit locks end to end runnableat target for current nonempty cohort: audit-locks --source=postgres returned as_of=2026-05-14T23:44:56.089Z and zero in all three drift buckets; guarded cutover script added and reservation_lock cohort flipped for Oahu and Dallas→scripts/audit-locks.mjs runs end-to-end without --dry-run against Revenue's authoritative lock-state read API per the 2026-05-02-revenue-lock-state-api-surface-spec, returning a real as_of and a three-bucket drift report; the precondition for any Phase 4 reservation_lock cutoverstable 59drefreshed 59d ago
End-to-end audit-locks runnability; gates Phase 4 reservation_lock cutover under the Delivery quality bar; clears in lockstep with Revenue's revenue-lock-state-read-api-availability indicator advancing to target
trend:in progress: Delivery added the Postgres reservation_lock reader and backfilled 20 nonempty reservation rows, then reached Revenue's legacy-id map path with canonical org mapping plus a valid Platform-minted Revenue-audience service JWT. The remaining blocker is Revenue mapping population: legacy-id map reports all 20 Airtable Credit Reservation ids missing, so no crr_ ids are returned yet→in progress: nonempty audit runs end to end and returns as_of=2026-05-14T22:59:01.612Z, but it is red: missing_in_revenue=20, state_or_amount_mismatch=0, ledger_footprint_mismatch=0. Delivery asked Revenue to inspect why the mapped crr_* cohort is absent from lock-states for the same org and lesson scope→gated on 2026-05-23-revenue-postgres-initiative-scope:revenue-lock-state-read-api-availability: in progress: Platform supplied the remaining person map, and Revenue imported the full 20-row lock-state cohort with 20/20 legacy reservation mappings populated and 0 skipped; status counts are reserved=4, locked=2, consumed=4, released=10; remaining readiness signal is Delivery re-running audit:locks against the full nonempty cohort→at target for current nonempty cohort: audit-locks --source=postgres returned as_of=2026-05-14T23:44:56.089Z and zero in all three drift buckets; guarded cutover script added and reservation_lock cohort flipped for Oahu and Dallas
Participant backfill auditabilityat target: Oahu migrated 8 in-scope Participant rows and Dallas migrated 1 in-scope Participant row after Platform's CL-PLT-0002 commit; drift-check:participant returned drift=0, only-in-airtable=0, only-in-postgres=0, skipped=0 for both orgs→100% of Phase 2 migrated Participant rows resolvable to source Airtable record, resolved person_id, organization_id, and resolution path
Per Platform's 2026-05-12 ack on the migration mechanism design; keeps the Participant backfill audit trail at the Person boundary so any later identity investigation stays in Platform's lane without making Delivery depend on a new Identity contract
Coaching eligibility smoke read per orgtarget: Delivery added scripts/smoke-coaching-eligibility.mjs and read source Lesson cohorts against Coaching production at https://coaching.sguildswim.com/api/v1/coaching/v1/eligibility/by-description on 2026-05-14; Oahu lesson recZ2nI25Dfjstqm1 returned as_of=2026-05-14T11:42:18.676Z, Dallas lesson rec3g8qQeeZ3kVRKF returned as_of=2026-05-14T11:42:18.901Z, both with org-isolated by-description reads→smoke read against Coaching's eligibility path completed (with as_of and Delivery lesson source cohort recorded) for every production organization before its Phase 3 lesson cutover flipstable 59drefreshed 59d ago
Per Coaching's 2026-05-12 ack on the migration mechanism design; operational evidence that the per-org cohort cut respects coach-availability §7.5 org isolation across the stagger
Airtable touchpoint coveragemanifest published and guardrail landed: delivery docs/airtable-cutoff-manifest.md enumerates every Airtable touchpoint across /app /modules /lib /scripts with a disposition for each, and scripts/audit-locks.mjs gained a --guardrail mode (npm run audit:airtable-guardrail) that fails on any unexpected Airtable import in production code paths. The remaining Delivery-owned write touchpoint (lesson outcome writes) was re-pointed Postgres-first in the outcome write-side change; what is left is out-of-scope Revenue/Platform-owned reads and shared lib/airtable infra that retires at Phase 6. Guardrail still needs wiring into a CI step (no CI pipeline exists yet)→cutoff manifest published enumerating every Airtable touchpoint in Delivery's /app, /modules, /lib, /scripts with disposition (cut, re-pointed at canonical Postgres, retired with the upstream feature, or moved to the post-cutover archive-read path), plus extended audit-locks.mjs guardrail failing CI on any unexpected Airtable client import in production code paths
Audit-and-cut surface across the seven Delivery-named tables (lock state machine, lessons, lesson attendances, coach assignment, lesson sites, service areas, customer tracking) plus the coach-day planner re-pointing; the manifest is the artifact that makes the aggregate zero-Airtable-reliance claim auditable post-cutover, the extended guardrail is the manifest's coverage discipline made executable
Blocked
Sales scheduling surface availabilityv1.0.0 published with all three peer-domain acks filed (Revenue closed, Coaching responded with v1.1 tighter-endpoint flag, Sales closed with close-orchestration confirm); awaiting first Sales call site in production→contract published, at least one Sales call site live in production, no observed bypass of the lock state machine
The Sales-callable scheduling integration surface that lets Sales create/inspect/cancel lesson holdings against Coaching's eligible-coach set and lesson-site availability without bypassing Delivery's lock state machine; tracked from contract bump through first Sales consumer through audit-clean state
Done
Lock migration cutover coverageat target: reservation_lock cut over for Oahu and Dallas on 2026-05-14 (20 rows, drift-check:reservation-lock drift=0); on 2026-05-15 the participant, lesson, and attendance cohorts also flipped for both orgs after clean drift-checks (participant 8/1, lesson 22/18, attendance 5/1 rows compared, zero drift), and lesson_site/lesson_site_config flipped 2026-05-14. migration_cohort_state shows all eleven rows cutOver=true, so 100% of the migrated tables are on the canonical Delivery schema for both live orgs→100% of in-flight reservation locks on the new Delivery repo schemarefreshed 59d ago
Share of in-flight reservation_lock rows that have been migrated from the legacy store into the canonical Delivery repo schema (per ADR-0006 owner-of-record); read off the migration_cohort_state table once Phase 0 of the migration mechanism design lands
trend:Phase 4 schema and backfill landed: 20 in-scope reservation_lock rows migrated to Delivery Postgres (9 Oahu, 11 Dallas) with drift-check:reservation-lock returning drift=0 for both orgs; cohort cutover remains unflipped until audit-locks proves the nonempty crr_ comparison against Revenue→target for current cohort: 20 in-scope reservation_lock rows migrated to Delivery Postgres (9 Oahu, 11 Dallas), drift-check:reservation-lock returned drift=0 for both orgs, and migration_cohort_state now has reservation_lock cutOver=true for Oahu at 2026-05-14T23:47:46.669Z and Dallas at 2026-05-14T23:47:46.838Z
Customer stage row countat target: Delivery live query on 2026-05-16 reports 6 CustomerStage rows and 6 active rows for org_01900000-0000-7000-8000-000000000001; stage defaults are seeded and the workbench reads the row-driven configuration→6 active default stages present for the production org, with no duplicate active stage keys
Readiness of the customer-row workbench stage spine; protects the operator queue from missing or duplicate stage configuration after the CRM split
Customer stage admin edits per weekinitial value 0 observed operator edits/week; admin surface is live at /admin/workbench/stages and changes reflect on /workbench on the next page load→tracked weekly; expected initial value is 0 until an admin intentionally changes stage policy
Operational use of the stage editor; nonzero values mean stage policy is being tuned through the admin surface rather than code deploys
Audit event coveragestructural target met: all 24 action definitions resolve through scripts/audit-actions.mjs with no orphaned command keys, and operator mutation forms invoke delivery-surface before domain writes; live event count is 0 before real operator traffic→100% of registry-mediated customer, lesson, lock, attendance, coach, and messaging mutations write DeliveryAuditEvent
Coverage of the audit substrate for the Customer Workbench and related operator surfaces
Markets ownership shape resolvedfiled: 2026-05-23-platform-markets-ownership-position→position filed on 2026-05-23-delivery-markets-ownership-question; Delivery's Service-Area-routing-chain piece unblockedstable 61drefreshed 58d ago
Open Delivery-to-Platform handshake on Markets ownership shape (Platform-lead, joint-with-Delivery, or migrate Markets later); the five-table cutover proceeds independently, only the Service-Area-routing-chain leg waits on this