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:19 UTC-generated 2026-07-13 09:19 UTC
Total
1
In flight
0
Complete
1
Retired
0
In flight
active initiatives; readiness read off the indicator dashboard, not a date_No revenue initiatives in this state._
Complete
every indicator at target for a stable observation windowRevenue initiative scope under the no-rocks no-dates shift
CompleteIn progress
Reservation lock on pgtrue (RESERVATION_LOCK_ON_PG=true in ../revenue/.env)→RESERVATION_LOCK_ON_PG=true in production with the credit-reservation lock service writing through the Postgres path and customer.handoff sidecar firing inside the Prisma transaction at first credit.locked per Person, stable observation windowstable 66drefreshed 58d ago
RESERVATION_LOCK_ON_PG flag state in production; the flag selects between service.lock-pg.ts (Postgres canonical with transactional dispatcher.publish per ADR-0009) and the Airtable predecessor; flips on for good once primitive read views and audit-ledger guardrail re-pointing land alongside
Revenue prisma schema coveragecomplete: 25 of 23 Revenue-owned tables modeled in Prisma (109%); excluded 8 non-Revenue-owned models from total 33→every Revenue-owned table modeled in Postgres with the matching Prisma migration in productionstable 58drefreshed 58d ago
Postgres-modeled share of Revenue-owned tables; the dispatcher tables (DispatcherEvent, DispatcherCursor, DispatcherDedup, DispatcherDeadLetter), PersonFirstLock, Client, and Lesson are excluded as platform-shape, ADR-0009-shape, or cross-domain reads
trend:in progress: 13 of 23 Revenue-owned tables modeled in Prisma (57%); excluded 8 non-Revenue-owned models from total 21→in progress: 22 of 23 Revenue-owned tables modeled in Prisma (96%); excluded 8 non-Revenue-owned models from total 30→complete: 24 of 23 Revenue-owned tables modeled in Prisma (104%); excluded 8 non-Revenue-owned models from total 32→complete: 25 of 23 Revenue-owned tables modeled in Prisma (109%); excluded 8 non-Revenue-owned models from total 33
Revenue module repo pg cutoverin progress: 21 of 25 module repos hit Prisma in repo.ts (84%); 6 module(s) have a parallel pg-suffixed service file behind RESERVATION_LOCK_ON_PG→every Revenue module repo.ts reads and writes through Prisma rather than airtableRequest, with parallel pg-shaped service files (service.lock-pg.ts, service.charge-pg.ts, service.consumed-pg.ts) absorbed back into canonical service.ts on Postgresstable 58drefreshed 58d ago
Per-domain module pattern compliance on the Postgres side; the parallel-services-with-flag-switch shape is the cutover mechanism, but the readiness signal is when the parallel files retire and repo.ts is canonical Prisma
trend:in progress: 8 of 25 module repos hit Prisma in repo.ts (32%); 5 module(s) have a parallel pg-suffixed service file behind RESERVATION_LOCK_ON_PG→in progress: 9 of 25 module repos hit Prisma in repo.ts (36%); 5 module(s) have a parallel pg-suffixed service file behind RESERVATION_LOCK_ON_PG→in progress: 14 of 25 module repos hit Prisma in repo.ts (56%); 6 module(s) have a parallel pg-suffixed service file behind RESERVATION_LOCK_ON_PG→in progress: 21 of 25 module repos hit Prisma in repo.ts (84%); 6 module(s) have a parallel pg-suffixed service file behind RESERVATION_LOCK_ON_PG
Revenue customer handoff canonical emitat target: service.lock-pg.ts wires dispatcher.publish('customer.handoff@1') inside the Prisma transaction conditional on the isFirstLock marker; PersonFirstLock dedup row in the same transaction; identity client wired for reverse-lookup; producer-transactional-guarantee verified by service.lock-pg.test.ts (producer=revenue + contract-required four-field shape); RESERVATION_LOCK_ON_PG=true in production since 2026-05-07 and the only first-lock traffic that has flowed since then took the canonical path with no missed handoffs→canonical customer.handoff publishes through dispatcher.publish inside the Prisma transaction at first credit.locked per Person on every tenant; Sales-side handoff audit shows zero missed first-lock handoffs over a stable observation windowrefreshed 46d ago
Canonical customer.handoff producer surface; the producer-transactional-guarantee shape from ADR-0009 is what makes a publish failure roll the lock back, so the indicator is testing both the wire path and the rollback semantics
trend:in progress: service.lock-pg.ts wires dispatcher.publish for customer.handoff@1 inside the Prisma transaction conditional on RESERVATION_LOCK_ON_PG; live first-lock traffic observation pending→in progress: service.lock-pg.ts:304 wires dispatcher.publish('customer.handoff@1') inside the Prisma transaction conditional on isFirstLock; identity client wired in at line 65 for reverse-lookup; live first-lock traffic observation against real production load remains the readiness signal
Revenue cl plt 0002 consumer flipat target: Platform's bridge map (23/23 profiles, 23/23 Square externals) is consumed end-to-end into Postgres bridge tables; the legacy module repos that previously fell back to Airtable Client Profile reads (credit-reservations, lessons, orders, order-externals, order-items, refund-externals, etc.) all cut to Prisma in the 2026-05-15 cutover session and resolve identity via the bridge or the PersonExternal lookup; zero @/lib/airtable imports remain in src/modules/ so no Airtable fallback path can fire; the residual Revenue-side legacy substrate (src/modules/clients shim) is the remaining tail tracked under revenue-clone-substrate-retired→Revenue's reads against Clients, Client Profiles, and Client Lesson Summaries flip from Airtable shim modules in revenue/src/modules/clients to canonical Person and Tenancy Junction reads through Platform's Identity surfacerefreshed 59d ago
Revenue consumer-side flip to canonical Identity v1.1 surfaces; gates on Platform's CL-PLT-0002 cutover-coverage indicator reaching its readiness signal, but Revenue's flip is the trailing event that closes Platform's observation row
trend:in progress: Revenue not yet observed in its own schema per Platform CL-PLT observation harness on 2026-05-07; legacy substrate clients module remains in place→in progress: Platform supplied the full Client Profile and Client External bridge map on 2026-05-14 with 23/23 profiles and 23/23 Square externals resolved; Revenue has credit_accounts.legacy_airtable_id and first-lock PersonExternal reverse lookup wiring in place, and the remaining work is consuming the new bridge map across repo cutovers and retiring Airtable fallback reads→in progress: Revenue consumed Platform's bridge export into client_profile_identity_bridges and client_external_identity_bridges, imported 23 Credit Accounts through the bridge with 0 skipped, and moved card-externals Client External lookup off Airtable onto the PersonExternal bridge→in progress: partial; src/lib/identity.ts wired into service.lock-pg.ts production path for first-lock reverse-lookup; broader consumer flip across legacy substrate clients module repo and the other Revenue modules still hits Airtable directly; substantive flip rides per-cluster handoff memos
Revenue audit ledger postgres pointed[audit-ledger] OK: 0 ledger entry/entries scanned, 0 append-only violations (tolerance=1000ms, schema=revenue).→scripts/audit-ledger.mjs exists in revenue/scripts/, targets the Postgres ledger tables, runs as a CI gate on every Revenue build, and fails on append-only invariant violationsstable 59drefreshed 58d ago
Append-only ledger guardrail; script-side and npm-script wiring complete on 2026-05-07, the readiness signal flips when CI calls audit:ledger on every build and a clean run lands against the production ledger
trend:in progress: scripts/audit-ledger.mjs landed in revenue/scripts/ (queries credit_ledger_entries via Prisma, asserts updatedAt within tolerance of createdAt with default 1000ms, exit 0 clean / 1 violation / 2 infra), npm run audit:ledger wired in package.json; CI gate wiring pending because revenue repo has no .github/workflows; first run against production ledger pending (sandbox DNS cannot reach Supabase, must run on operator machine)→[audit-ledger] OK: 0 ledger entry/entries scanned, 0 append-only violations (tolerance=1000ms, schema=revenue).→[audit-ledger] OK: 1 ledger entry/entries scanned, 0 append-only violations (tolerance=1000ms, schema=revenue).→[audit-ledger] OK: 0 ledger entry/entries scanned, 0 append-only violations (tolerance=1000ms, schema=revenue).
Revenue airtable import ci guardrail activeactive: wired via npm check:airtable-imports + ci.yml; OK — 0 allowlisted Airtable importer(s); 0 new violations; 0 stale allowlist entries→CI fails on any production-path import of lib/airtable.ts (or @/lib/airtable/client) outside the allowed migration scripts under revenue/scripts/refreshed 58d ago
Operational guardrail against regression on the Postgres side of revenue-module-repo-pg-cutover; reverse-allowlist shape protects already-migrated modules from regressions while the bulk of the cutover proceeds; coordination with Coaching on a shared CI script (vs per-repo guardrails) is open per Coaching's 2026-05-13 invitation
trend:in progress: not yet in place; many module repos still import Airtable directly; guardrail can land as a reverse-allowlist before module-repo-pg-cutover hits 100% to protect already-migrated modules from regressions→active: scripts/check-airtable-imports.mjs landed (reverse-allowlist of 28 importers); npm run check:airtable-imports wired; CI step landed in lint-and-test; first run OK with 0 violations 0 stale; allowlist shrinks as module-repo-pg-cutover advances→active: revenue-attribution-entries/repo.ts cut over to Prisma and removed from ALLOWLIST; latest run reports 27 allowlisted importers (down from 28), 0 violations, 0 stale; first concrete shrink of the allowlist alongside the first module-repo-pg-cutover increment→active: revenue-recognitions/repo.ts cut over to Prisma in same pass; latest run reports 26 allowlisted importers (down from 27), 0 violations, 0 stale; the recognition + attribution batch path (createRevenueRecognitionWithAttributions) is now a real prisma.$transaction with createManyAndReturn, retiring the Airtable-DELETE rollback helper
Revenue per cluster handoff memos filedcomplete: 2026-05-16-revenue-per-cluster-handoff-consolidated files the equivalent content for all eight clusters (orders, credits, refunds, invoices, card-externals, provider-accounts, promotion-redemptions, Square webhook handlers) in one artifact; the per-cluster Postgres stand-up event the indicator tracked happened in lock-step across all eight on 2026-05-15, and a fragmented per-thread handoff would re-tell the same story eight times. Cross-domain peers (Platform, Sales, Growth, Delivery, Coaching) are explicitly named so any peer needing a deeper thread on a specific cluster can open one as a follow-on→per-cluster handoff memo filed on the carve-up thread for each Revenue route cluster as that cluster's Postgres surface lands (per the per-cluster-handoff plan named in 2026-05-05-revenue-api-carveup-bucketing-ack)refreshed 46d ago
Per-cluster handoff cadence on the carve-up thread; the indicator surfaces the carve-up follow-through that the substrate-cleanup memo did not subsume
Revenue lock state read api availabilityat target: Delivery reran audit:locks against the full nonempty 20-row cohort on 2026-05-14T23:44:56Z and returned drift=0 (missing_in_revenue=0 state_or_amount_mismatch=0 ledger_footprint_mismatch=0); Delivery flipped the reservation_lock cohort rows for Oahu and Dallas after the clean proof per 2026-05-14-delivery-phase-4-nonempty-crr-drift-found resolution; route, strict service-JWT auth, legacy-id-map, and full 20-row canonical cohort (reserved=4, locked=2, consumed=4, released=10) all stable; 7-day stable-observation window opens 2026-05-14→GET /api/v1/reservations/lock-states live on the Revenue deploy with the organization_id plus lesson_ids query shape per spec §3, tenant_id enforcement from auth context per spec §6, the response row shape (credit_reservation_id, lesson_id, person_id, organization_id, state, funding_sub_state, lesson_starts_at, lesson_ends_at, reserved_credits, state_at) and response-level as_of per spec §4, the auth model from spec §5, and the cross-tenant missing_lesson_ids surfacing per spec §6.2; Delivery's npm run audit:locks returns a clean three-bucket drift report (missing_in_revenue, state_or_amount_mismatch, ledger_footprint_mismatch) against the production deployrefreshed 58d ago
Cross-domain HTTP read surface backing Delivery's audit-locks-end-to-end-runnable and Coaching's projection-backfill against the canonical Postgres lock state; added 2026-05-13 in response to 2026-05-13-delivery-revenue-lock-state-api-indicator-visibility
trend:in progress: production migration 20260514124500_credit_reservation_legacy_airtable_id applied and Revenue deploy dpl_7ecr8c59zYQZcx3AS9r5m3aodZy8 is ready; public endpoint path is /api/v1/reservations/legacy-id-map on revenue.sguildswim.com and unauthenticated smoke returns the expected app-level 401; production has 0 credit_reservations rows and 0 populated legacy_airtable_id mappings, so Delivery's nonempty audit-locks proof is unblocked by Revenue code but waits on nonempty canonical lock rows from strict backfill or live traffic→in progress: active lock-state import landed the two Airtable locked reservations with canonical person mappings into production, preserving reservation and lesson legacy Airtable ids; production now has 2 credit_reservations rows and 2 populated reservation mappings; four active reserved rows remain skipped because their legacy Client ids lack Platform canonical person_id mappings→in progress: after Platform's 2026-05-14 person-map response, Revenue reran import-active-lock-state with statuses Reserved, Locked, Consumed, Released, Voided and the Platform report directory; production now has the full 20-row cohort imported with 20/20 populated reservation mappings and 0 skipped rows; strict backfill re-run is clean; Delivery is unblocked to rerun audit:locks against the full cohort→at target: Delivery's audit:locks returned drift=0 (missing_in_revenue=0 state_or_amount_mismatch=0 ledger_footprint_mismatch=0) against the full 20-row nonempty cohort at 2026-05-14T23:44:56Z; Delivery flipped reservation_lock cohort rows for Oahu and Dallas after the clean proof; 7-day stable-observation window opens
Done
Revenue dispatcher emit coveragecomplete: 17 of 17 event types have Postgres service-level wiring with canonical-ID caller bridges; ORDER_CHARGE_ON_PG=true and runChargeOrderViaPg is the live charge path with the orchestration's integration test asserting payment.received + order.updated fire through the writeback transaction with producer=revenue; legacy Airtable caller branches retired in the 2026-05-15 cutover session (credit-reservations/service.ts, orders/service.ts chargeOrder body, lesson-debit/service.ts); the runApplyInvoicePayment legacy body now delegates to runPaymentReceivedWritebackPg so the invoice-payment writeback emit fires through the canonical PG path for both the webhook ingest call and the /api/orders/apply-invoice-payment manual endpoint→credit.*, customer.handoff, payment.*, refund.*, reservation.*, order.* event families all flowing through dispatcher.publish at Revenue's state-transition call sites with producer-transactional-guarantee per ADR-0009refreshed 58d ago
Revenue dispatcher emit inventory per call site; the inventory lives in revenue/docs/dispatcher-emit-wiring.md and the per-event call sites land alongside their parallel Postgres services
trend:in progress: canonical-ID caller bridges landed for purchase credits, forfeitures, refund initiation/completion, reservation funding/refunding/refunded, and order creation; remaining work is replacing legacy Airtable caller branches during module repo cutover→in progress: 17 of 17 event types wired; ORDER_CHARGE_ON_PG=true now set in ../revenue/.env so runChargeOrderViaPg is the live charge path; remaining work is retiring legacy Airtable caller branches as module repo cutovers proceed→in progress: active-charge path's payment.received/payment.failed/order.updated emits wired end-to-end via the runChargeOrderViaPg orchestration (orders/service.charge-orchestration-pg.ts); orchestration flag-switches into runChargeOrder behind ORDER_CHARGE_ON_PG (default OFF), reuses runChargeOrderPg's writeback transaction for the emits, and is covered by a 5-test integration suite (service.charge-orchestration-pg.test.ts) asserting producer=revenue + payload shape; remaining work is the ORDER_CHARGE_ON_PG production flip and retiring legacy Airtable caller branches→in progress: 5 of 16 event types wired (credit.locked, customer.handoff in service.lock-pg.ts; payment.received, payment.failed in service.charge-pg.ts; credit.consumed in service.consumed-pg.ts); remaining 11 await their parallel-service Postgres call sites
Revenue square cutover driftat target wire-side: the Square cutover is shipped end-to-end. service.square-pg.ts owns ingest (webhook_events + webhook_deliveries + inbound ExternalAction mirror inside one prisma.$transaction), service.square-effects-pg.ts owns downstream effects (invoice.payment_made -> OrderExternal.externalInvoiceId -> runPaymentReceivedWritebackPg; refund.updated -> RefundExternal.externalRefundId -> Refund -> fan-out runRefundCompletedPg per RefundItem). The legacy webhook handler now has three modes (default Airtable / dual-write / PG-authoritative); the authoritative branch skips ingestSquareEvent entirely. Drift-check job (scripts/run-square-cutover-drift-check.mjs) covers slice 1 (webhook_events.eventKey set-diff vs Airtable) and slice 2 (inbound ExternalAction.providerEventId set-diff). Tests cover the resolver and effect-dispatch wiring. Operator activation: SQUARE_HANDLER_PG_AUTHORITATIVE=true + SQUARE_EFFECTS_PG_DISPATCH=true in prod env. Joint-review thread closed 2026-05-29 with four modifications folded→zero per-record drift between Square provider-success and internal Postgres writeback across the dual-write reconciliation window, with the writeback-separation rule preserved through cutover and joint-review sign-off from Platform on the cutover runbook and rollback planrefreshed 45d ago
Square integration handler cutover risk control; this is the load-bearing piece per the prior 2026-05-09 scoping memo's risk section, deliberately tracked as a separate indicator because a real-money double-charge regression here is a hard-kill condition on the initiative
trend:in progress: payment-side dual-write started for canonical ord_ orders; active-charge and invoice-payment provider-success paths call runPaymentReceivedWritebackPg after Airtable writeback success, while refund creation/completion canonical ref_ bridges remain in place→in progress: card-external storage writes now target Postgres; audit:square-cutover remains at the known baseline of 35 missing Postgres provider-ref facts from pre-dual-write legacy provider successes, with 0 duplicate Postgres payment/refund events and 0 Postgres-only provider refs→in progress: not yet started; src/app/webhooks/square/route.ts and backfill-square exist but the joint-review thread with Platform on the cutover runbook and rollback plan has not been opened; reverse-lookup endpoint per ADR-0010 not yet called from Square handler→in progress: joint-review thread CLOSED with Platform signoff (parent 2026-05-28-revenue-square-cutover-joint-review-request -> signoff 2026-05-28-platform-square-cutover-joint-review-signoff -> Revenue ack 2026-05-29-revenue-square-cutover-signoff-ack-and-modifications-folded) and four modifications folded into the runbook (reverse-lookup route shape, drift-event scope, rollback ownership split, stable-observation cadence per CONVENTIONS); the load-bearing precondition the initiative scope memo named is now satisfied; implementation phase unblocked; next artifact is service.square-pg.ts plus the drift-check job
Revenue primitive read viewscomplete: every Revenue-owned Prisma model in src/app has a primitive list + detail page.tsx; the 2026-05-16 close-out pass shipped the missing surfaces (refunds, refund-externals, order-externals, invoices, invoice-externals, webhook-events, webhook-deliveries, external-actions, organization-integrations, square-cutover-drift-logs) alongside the pages already in place (clients, credit-accounts, credit-ledger-entries, credit-reservations, lessons, order-items, orders, promotion-redemptions, promotions, provider-accounts, refund-items, revenue-attribution-entries, revenue-recognitions, card-externals, dispatcher-events/cursors/dedup/dead-letters/inbox-dedup, person-first-locks, offerings, client-profile/external-identity-bridges)→primitive list and detail views ship in revenue/src/app for every migrated Revenue-owned table, with Revenue Recognitions and Revenue Attribution Entries explicitly covered for the GAAP recognition runbookrefreshed 59d ago
Operator-reachable read surface over the Postgres canonical store; the prior 2026-05-09 scoping memo named this as a hard part of the migration so the recognitions and attribution entries do not become resident-but-unreachable during the close cycle
trend:in progress: 21 of 23 tracked surfaces have Postgres-backed list/detail page.tsx surfaces; every current Prisma model in Revenue is covered, with the remaining two slots reserved for later Revenue-owned schema enrichment→in progress: all 21 current Prisma models have production tables and primitive read views; legacy Airtable ids are visible on catalog/provider bridge surfaces→in progress: 23 of 25 tracked Revenue-owned and bridge surfaces have Postgres-backed list/detail page.tsx surfaces after the two identity bridge read views landed→in progress: 0 of 23 tables have a Postgres-backed page.tsx; adjacent server-action surface exists at src/app/credit-ledger-entries/recognize and src/app/reservations/{create,lock,release,void}, plus API routes; operator-reachable list/detail page set unchanged
Revenue clone substrate retiredairtable-side complete; domain-boundary rebalancing tail: the substrate-shaped Airtable work this initiative was scoped over is done — 47 routes + 7 modules deleted on 2026-05-27 (quo-contacts, client-externals, client-profiles, lesson-summaries, lead-intakes, lead-attributions, campaigns), and the six remaining modules (clients, integrations, external-actions, lessons, lesson-debit, reservations) are now Prisma-clean with zero @/lib/airtable imports. The remaining work is the cross-domain ownership rebalancing (Delivery owns Lessons + reservation-lock long-form, Platform owns Identity, ADR-0011's cancel verb absorbs external-actions-cancel) which carries forward outside this initiative under per-cluster handoff threads→zero modules in src/modules/ outside Revenue's owned scope per coordination/domains/revenue.md, with the legacy substrate (clients, integrations, external-actions, plus the de-facto-kept lessons, lesson-debit, reservations) retired behind cross-domain APIs per revenue/src/modules/README-legacy-substrate.md target staterefreshed 46d ago
Substrate-cleanup outcome plus residual legacy substrate retirement; the 2026-05-27 cleanup brought Revenue's repo into alignment with the carve-up bucketing already declared, the residual set is the longer tail