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 08:19 UTC-generated 2026-07-13 08:19 UTC
Total
9
In flight
5
Complete
4
Retired
0
In flight
active initiatives; readiness read off the indicator dashboard, not a dateADR-0021 migration initiative scope and execution plan
In flightIn progress
Coordination tools context awarePhase 1 verified complete 2026-05-25: sguild-tools/server.mjs resolves the coordination checkout from SGUILD_COORDINATION_CHECKOUT (commit f16241ce), node --check and module-load clean, non-breaking; per-workspace activation follows as MCP configs adopt the variable in phase 2→coordination_commit, coordination_run_indexer, and coordination_freshness_check in sguild-tools resolve the target checkout from the calling workspace context
Phase 1, ADR-0021 action items 1 and 2: the single-MCP-server tool surface made checkout-aware so it can serve per-domain coordination clones
CI index generation livePhase 1 verified complete 2026-05-25: .github/workflows/ci.yml commits regenerated INDEX.md and _views/ back on default-branch push (commit f16241ce); the workflow run is green after the install-step Prisma-env fix (commit 55bca5d4)→CI regenerates INDEX.md and _views/ on every push to the coordination repo and fails on stale or malformed state
Phase 1, ADR-0021 action item 4 (CI part): CI established as a working writer of the generated artifacts before they are untracked
PER domain coordination clones8 of 8 complete 2026-05-26 under the ADR-0023 satisfaction criterion (per-workspace clone exists on disk, the workspace's spaces.json entry mounts it, and the domain's AGENTS.md references resolve under that mount), with Platform satisfied under the shared-steward shape ADR-0023 names: finance, portfolio, revenue, coaching, growth, sales, delivery (delivery joined 2026-05-26 per 2026-05-26-delivery-adr-0023-agents-md-repoint-complete), plus platform-as-steward closing the 8th slot. Phase 3 is OPEN as of 2026-05-26 per the execution plan; see 2026-05-26-platform-adr-0021-phase-3-open on this thread for the Phase 3 scoping (retire the standalone coordination MCP, retire the *_remove_git_lock tools, sequence the ADR-0023 platform-tools rename, and ship the ADR-0024 prong 2 clone-arg work)→8 of 8 domains on an isolated per-workspace coordination clone with MCP client config pointing at sguild-tools only
Phase 2, ADR-0021 action item 5: each domain workspace holds its own coordination clone, no two agents sharing one .git
Generated artifacts ci ownedPhase 2 Platform slice complete 2026-05-25: INDEX.md and _views/ added to coordination .gitignore and removed from the index with git rm --cached, .github/workflows/ci.yml force-adds and commits them as the sole writer, scripts/auto-commit.mjs no longer runs the indexer with the coordination_auto_commit tool description updated to match, and coordination/AGENTS.md plus platform/AGENTS.md are updated off the standalone coordination MCP; see 2026-05-25-platform-adr-0021-phase-2-platform-slice→INDEX.md and _views/ untracked from domain clones via .gitignore plus git rm --cached, and coordination_auto_commit no longer runs the indexer
Phase 2, ADR-0021 action item 4 (remainder): CI is the sole writer of the generated artifacts once it is confirmed working
Standalone coordination mcp retiredretired 2026-05-26 in commit d68258bf: coordination/mcp/README.md and coordination/mcp/server.mjs deleted (1386 lines removed), and the mcp npm script dropped from coordination/package.json; sguild-tools is now the sole MCP surface for coordination operations per ADR-0021 Decision 1. The precondition ADR-0023 named (.git isolation via per-workspace clones, 8 of 8 on per-domain-coordination-clones) is satisfied. Operators still running an MCP session against the pre-retirement server.mjs must restart for the standalone MCP tools to disappear from their client; the standalone MCP's binary is now gone from the repo so any client config pointing at coordination/mcp/server.mjs will fail to spawn→the standalone coordination MCP is retired and sguild-tools is the sole MCP server for coordination operations
Phase 3, ADR-0021 action item 1 (final part): retired once all domains are on isolated clones and off the standalone MCP
Remove git lock tools retiredretired 2026-05-26 in commit 8d5ffa26: the six per-domain *_remove_git_lock entries from PER_DOMAIN_COMMANDS and coordination_remove_git_lock from DOMAIN_SPECIFIC_COMMANDS are removed from sguild-tools/server.mjs; with per-workspace clones in place (per-domain-coordination-clones indicator at 8 of 8) the cross-process contention class those tools mitigated is gone by construction, and the coordination-clone-scoped tools' inline .git/index.lock clearing in their runner scripts (step 2 of coord-surgical-commit.mjs and peer) covers the remaining single-workspace edge case; the host-side scripts/remove-git-lock.mjs runner stays as the operator recovery utility, invoked directly with `node scripts/remove-git-lock.mjs [<clone>]`. Operators still running an MCP session against the pre-retirement server.mjs must restart for the tools to disappear from the surface→the *_remove_git_lock tools are retired
Phase 3, ADR-0021 action item 3: retired only after the shared checkout is gone, since index contention is real while any shared checkout with concurrent writers exists
Sales close-orchestration initiative scope under no-rocks no-dates
In flightIn progress
Scheduling consumer module presentscaffolded 2026-05-16 per 2026-05-16-sales-scheduling-consumer-module-scaffolded: modules/scheduling/ with dto/schema/repo/service/actions/routes/index, lib/delivery/lesson-hold-client.ts wrapping all four §4 endpoints with snake/camel boundary and discriminated outcome unions, /api/scheduling/lesson-holds/* mounted, /admin/scheduling/test debug page; 23 new tests pass; not yet called from operator workflow, eligibility + reservation upstream steps still at 0% on their own indicators→modules/scheduling/ (or equivalent) exists in the Sales repo following the per-domain module pattern, with dto/schema/repo/service/routes and a hold-create call shape against contracts/sales-scheduling-surface §4.1
Structural presence of the Sales consumer module for the sales-scheduling-surface contract; the first observable signal that the close-orchestration build has actually picked up rather than being deferred indefinitely
Eligibility by description call site livescaffolded 2026-05-16 per 2026-05-16-sales-eligibility-consumer-module-scaffolded: modules/eligibility/ with dto/schema/repo/service/actions/routes/index, lib/coaching/eligibility-client.ts wrapping §4.2.2 with snake/camel boundary and discriminated outcome union, /api/eligibility/by-description mounted, /admin/eligibility/test debug page, service-layer console log carries asOf + projectionAsOf per the validation file; 15 new tests pass; not yet called from operator workflow, stale-projection orchestration waits on the reservation consumer indicator→Sales calls Coaching's coach-availability §4.2.2 eligibility-by-description endpoint from the offer-construction seam with as_of from each response logged per coach-availability validation/sales-offer-construction.md
Operationalizes the existing coach-availability validation obligation on Sales (as_of logging per response) and provides the upstream evidence the offer-construction audit shape persists; this is where the eligibility set acted on becomes observable
Reservation request call site livescaffolded 2026-05-16 against INFERRED endpoint shape per 2026-05-16-sales-reservation-consumer-scaffolded-with-contract-gap: modules/reservation/ with dto/schema/repo/service/actions/routes/index, lib/revenue/reservation-client.ts wrapping POST /api/v1/reservations with snake/camel boundary and discriminated outcome union, /api/reservations mounted, /admin/reservations/test debug page; 13 new tests pass; placeholder shape pending Revenue contract addendum + lock-state vocabulary reconciliation requested on the close-orchestration thread→Sales calls Revenue's credit-reservation-lock surface to obtain a crr_ in requested state before any hold-create call, with the producer-transactional-guarantee shape on Sales' service-layer call sites per ADR-0009
Second of the four canonical close-path steps from contracts/sales-scheduling-surface §6.6; Revenue's surface is the upstream of Delivery's hold-create and gates the canonical retry pattern (release-and-reserve-fresh on HTTP 409) per the 2026-05-07 close-orchestration confirm
First hold create call in production0%; producer surface unbuilt on Delivery's side per 2026-05-16-delivery-sales-scheduling-surface-build-state-observation, Delivery's producer-side scoping commitment is the gating dependency→Sales' offer-construction path calls Delivery's sales-scheduling-surface §4.1 hold-create endpoint in production with at least one organization, returns 201, lock advances requested -> held, and delivery.lesson-hold.created lands on the dispatcher; equivalent sandbox/fixture-mode conformance test against validation/sales-close-orchestration.md and validation/lock-state-machine-conformance.md passing as the staging signal
End-to-end booking flow signal; the indicator that closes the close-orchestration pilot's structural readiness criterion. Stays at 0% until both the Sales consumer build AND Delivery's producer surface are callable in the same environment
Offer construction audit shape persistedscaffolded 2026-05-16: modules/workbench-sources/ exports insertOfferConstructionAuditEvent (typed OfferConstructionAuditInput interface) that writes a V1 AuditEvent with fixed eventKey sales.offer.constructed and source close-orchestration, structured metadata captures decisionAt + projectionAsOf + requestShape + selectedCoachId + selectedWindow + eligibilitySet + notes per the eligibility-thread agreed shape; summary auto-generated from coach+window; 1 new test in workbench-sources.repo.test.ts asserts the persisted shape; not yet called from operator workflow, orchestration call site lands when the reservation-request + first-hold-create indicators advance→Sales persists decision-time, projection-as-of (from each coach-availability response), request shape, selected coach/window when present, and the eligibility set acted on for the final pre-reservation eligibility read; audit rows queryable from a Sales-owned table or audit_event stream
The instrumentation shape from the closed eligibility thread (2026-05-15-delivery-eligibility-consumer-surface-positions); this indicator is the trailing-indicator home for the commitment that retired from the cross-domain ledger. Sales-owned source record for any future cross-consumer comparison report against Delivery's parallel assignment-seam audit
Platform data access model initiative scope
In flightNot started
Consumer cutovernot started: growth-warehouse-api reads source-side today; Platform has filed the cutover ask (2026-05-18-platform-growth-mart-consumer-cutover-ask)→known warehouse consumers re-pointed onto their gold section, with growth-warehouse-api migrated to read the gold growth section on a bumped contract version
Migration of warehouse consumers off the flat warehouse onto consumer-scoped gold sections
Source to silver driftnot started: no silver tier to check yet→per-warehouse source-to-silver drift below threshold across all five faces
Ongoing-correctness signal; the warehouse:check-style drift check between bronze and silver per warehouse
In progress
Consumer firewall enforcedlive: lib/mart/auth.ts requireMartAuth enforces MART_API_KEY_<SECTION> bearer auth on every section route using constant-time comparison; each section key is independent so a compromised credential does not expose other sections; health/schema/changelog/corrections use MART_API_KEY_HEALTH→per-section access scoping enforced so each of the 7 consumers reads only its own section
Structural consumer isolation; the API-tagging firewall that keeps a decoupled domain from being biased by data outside its domain
Blocked
Gold mart section coverage7 of 7 sections live: growth, sales, delivery, coaching, revenue (operational); finance, portfolio (cross-domain aggregate; groupings return null:upstream_unavailable until derived store ships); all sections gated on section-scoped MART_API_KEY_<SECTION> bearer auth→7 of 7 gold mart sections live over silver (5 operational sections re-tiered from existing models, finance and portfolio built across silver)
Coverage of the gold application-service-layer mart sections
Done
Silver conform coverage5 of 5 silver faces live as dbt views (warehouse-silver v1.1.0): growth.touchpoint, sales.lead, delivery.lesson+attendance, coaching.coach+lesson_booking, revenue.recognition+credit_ledger+order+credit_reservation; all production-scoped, person_id resolved per domain→5 of 5 silver conforming faces live as dbt views over bronze, each resolving grain to canonical person_id and passing conform checks, stable observation window
Coverage of the silver conforming tier across the five per-domain warehouses (growth, sales, delivery, coaching, revenue)
Identity geography spine livelive: zip_service_area populated (Oahu + Dallas lesson sites), OrgMarket seeded for active (org, market) pairs, PersonTenancy market_id backfill complete, GET /api/org-markets live; spine tables are the join surface for gold section attribution→conformed identity and geography spine live in silver (Person dimension plus the Org to Market to Service Area to Lesson Site hierarchy), every silver face joining to it for the key
The shared conformed reference dimension sourced from Platform's identity database that silver faces join to for person_id and gold sections join to for Person and geography attributes
Delivery 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
Coaching files a paired-region initiative covering the Postgres migration and the Sales scheduling integration
In flightNot started
Sales deep link handoff livenot started; deep-link emission and Sales-side receiver land alongside the calendar-roster-app-shipped indicator and the Sales close-orchestration consumer build→At least one successful close-orchestration round-trip per week in production using a (lead_id, service_area_id, coach_id, window_start, window_end) deep-link emitted from Coaching's app calendar view in sales mode
Cross-domain consumer indicator for the Sales-mode deep-link path agreed on the 2026-05-16 acceptance thread; gated on both Coaching's app shipping the deep-link emission and Sales' close-orchestration flow exposing the receiving URL
In progress
Airtable callers zero0 callers of lib/airtable in production code paths (app/, modules/, lib/)→0 callers of lib/airtable.ts in production code paths in both Oahu and Dallas buildsstable 59drefreshed 58d ago
Static count of files importing lib/airtable.ts in Coaching's production code paths excluding scripts/ migration helpers; module deletable without breaking the build is the substantive end-state
Airtable import ci guardrail activeactive: scripts/guardrail-airtable-imports.mjs wired via pretest -> lint:airtable-imports→CI fails on any production-path import of lib/airtable.tsstable 59drefreshed 58d ago
Operationalizes airtable-callers-zero so a post-stabilization regression cannot land silently; a code-grep CI gate that fails on any module under modules/, app/, or lib/ (excluding lib/airtable.ts itself and scripts/migrate-coach-*) importing from lib/airtable.ts
Calendar roster app shippedv1 + projection-state + nav + summary + service-areas + coverage-heatmap + dashboard + CSV export + sub-day NowLine + full Coaching-mode editing (profile, templates, exceptions, materialize) serving: coaching/app/operator/{layout.tsx (OperatorNav: Dashboard/Calendar/Roster/Service Areas/Coverage with shared OperatorTabId), page.tsx (redirects), dashboard/page.tsx, calendar/page.tsx (NowLine divider), roster/page.tsx + roster/export/route.ts, service-areas/page.tsx + service-areas/[serviceAreaId]/page.tsx + service-areas/export/route.ts, coverage-heatmap/page.tsx, coach/[coachId]/page.tsx (Coaching-mode embeds CoachProfileEditForm + AvailabilityTemplatesPanel + AvailabilityExceptionsPanel + MaterializeAvailabilityCard, all posting to the existing modules/ops/actions server actions with returnTo back to the operator detail; LegacyOpsBridge reduced to a small "Coaching Ops home remains available during parity-and-retire" link), _components/SummaryMetricRow.tsx} all wired against modules/operator-app (mode parsing, default filter sets, deep-link emission, projection-state lookup, mode-aware summary metrics, service-area aggregation, per-day coverage breakdown, cross-area heatmap builder, coach-status rollup, RFC-4180 CSV serializer, splitWindowsAtNow, formatNowLineLabel); typecheck clean, 83 tests passing across 10 files; visual regression equivalence remains the separate calendar-mode-parity indicator→Coaching operator app under coaching/app/operator/ serves calendar, roster, and per-coach detail routes in production across all three modes (?mode=coaching, ?mode=sales, ?mode=delivery) with mode-default filter sets implemented per the 2026-05-16 acceptance memo
Production-route presence and mode-coverage check for the calendar-and-roster operator app accepted on 2026-05-16-coaching-calendar-roster-app-acceptance; clears when the single-app shape at coaching/app/operator/{calendar,roster,coach/[coachId]} serves all three modes and the URL-parameter mechanism is wired
Blocked
Supply ops ui retiredfunctional parity reached: profile editing, weekly templates, exceptions, and materialize-availability all migrated to /operator/coach/[coachId] in Coaching mode posting to the existing updateCoachOpsAction / createAvailabilityTemplateAction / createAvailabilityExceptionAction / materializeCoachAvailabilityAction; the legacy /?tab=supply surface still serves for parity-window observation but no edits live exclusively there anymore. Retirement (404 or redirect) gated on operator-confirmed parity observation window→Standalone Supply Ops UI URL returns 404 or redirects to the calendar-and-roster app's Coaching mode
Operationalizes the Supply Ops UI absorption named in 2026-05-16-coaching-calendar-roster-app-acceptance §Coaching's own operator mode; Coaching-internal retirement step that clears once Coaching mode reaches functional parity with the existing surface
Coach day planner migration landedmigration shape locked per 2026-05-16-delivery-coach-day-planner-migration-followup and 2026-05-16-coaching-coach-day-planner-migration-answers; Coaching now consumes Delivery's §4.3 wildcard read in delivery mode and renders real lesson blocks; awaiting Delivery's cutover re-declaration once Coaching's calendar-mode-parity indicator clears→Delivery's existing /coach-day-planner URL 302-redirects to coaching.sguildswim.com/operator/calendar?mode=delivery&date=<YYYY-MM-DD> for the first 30 days then promotes to 301, with the broader lesson-list scope served via the §4.3 lock_state=[*] (or equivalent) extension per 2026-05-16-coaching-coach-day-planner-migration-answers
Cross-domain handoff indicator for the Coach Day Planner migration; clears when the cutover lands and Delivery's planner URL stops serving the Delivery-side implementation
Done
Availability projection freshnessobservation window open 2026-05-16 after Platform Phase 3 docs shipped in 2026-05-16-platform-dispatcher-phase-3-docs-shipped; subscriber live since 2026-05-09 per 2026-05-15-coaching-projection-cutover-shipped; local inbox path smoke-verified end-to-end 2026-05-13 (HMAC, dedup, projection write) per 2026-05-13-coaching-dispatcher-inbox-live; production observability against projection event-to-projection lag in place→p95 lag <= 5s in BOTH regions, observed stable for two consecutive weeksstable 58drefreshed 58d ago
p95 event-to-projection lag of Coaching's lock-aware availability projection against Revenue's authoritative lock state, evaluated independently in Oahu (org recAbU7cdF25zx3Qe) and Dallas (org receu2hzz85FkloBt); single-region freshness does not satisfy
Eligibility read consistencyobservation window open 2026-05-16 after Platform Phase 3 docs shipped in 2026-05-16-platform-dispatcher-phase-3-docs-shipped; cut-over executed per 2026-05-15-coaching-projection-cutover-shipped; reads now served from the lock-aware projection rather than the interim sync-query→Sales offer-construction reads and Delivery assignment reads agree on same-lesson eligibility within freshness window in BOTH regions for two consecutive weeksstable 58drefreshed 58d ago
Same-lesson eligibility-read consistency between Sales' offer-construction path and Delivery's assignment path against coach-availability §4.1, §4.2.1, §4.2.2; cross-domain agreement is the leading Coaching quality bar per domains/coaching.md
Regional cutover stagger0 days; cutover is a single code-level event covering both region tenants per 2026-05-15-coaching-projection-cutover-shipped; structurally below the 14-day kill threshold→<= 14 days between Oahu and Dallas production cutovers
Time delta between the dates Oahu and Dallas regions independently flip from interim sync-query to projection-based reads in production; stagger > 14 days is a kill trigger that reopens the initiative pair per the records' killCriteria field
Identity v1 shippedcompleted: Identity v1 and v1.1 are shipped per 2026-05-02-platform-identity-v1-1-shipped and 2026-05-23-platform-initiative-scope; Coach Externals are reframed to Platform per ADR-0010 and Platform exposes PersonExternal reverse lookup plus forward listing at GET /api/identity/v1/person/{person_id}/externals→Identity Contract v1 status accepted with the canonical Person facts surface live
Cross-domain dependency surfacing Coaching's Coach Externals reframe per ADR-0010; Coach provider externals route through Platform's person_externals table via GET /api/identity/v1/person/{person_id}/externals; the original Coaching scoping commit named this dependency in prose, this indicator makes it visible to consumers reading the /initiatives view
Calendar mode paritycompleted: visual regression equivalence evidence and the Oahu/Dallas operator smoke reports passed; lesson rendering consumes Delivery's sales-scheduling-surface §4.3 wildcard read with lock_state=* in delivery mode and renders scheduled, requested, held, confirmed, consumed, and released lesson blocks grouped by coach and day; primitives landed (recurring-overlay toggle, NowLine, date-navigator, search, URL-param preservation, accessibility, empty-state polish); no functional regressions reported in the two-region smoke pass→Visual regression tests against Coaching's app in delivery mode pass for the existing planner's daily-driver test cases (single-coach, multi-coach, recurring-overlay-on/off, search-active, date-navigator positions across the next 30 days in Oahu and Dallas rosters), the four primitives (recurring-overlay toggle, NowLine, date-navigator, search) behave equivalently to the existing planner, and two daily-driver operators (one per region) complete a full operational day on the new app with no functional regressions reported
Functional-parity indicator for the delivery-mode-specific render against the existing Delivery Coach Day Planner per 2026-05-16-coaching-coach-day-planner-migration-answers; Delivery's eventual cutover commitment can structurally gate on this indicator being at target
Complete
every indicator at target for a stable observation windowPlatform initiative scope under the no-rocks no-dates shift
CompleteDone
CL-PLT-0002 cutover coveragecompleted: Revenue confirms migration complete per 2026-05-16-revenue-per-cluster-handoff-consolidated (all ten Revenue module repos on Prisma after 2026-05-15 Airtable cutover; charge-resolution.pg.ts reads client_external_identity_bridges per ADR-0010; card-externals identity reads flipped through Identity v1.1). Platform foundation (89 Persons, 23 PersonTenancies, 23 Square PersonExternal rows, 3 active Guardians) plus Sales, Growth, Delivery, and Revenue all observed downstream→100% of legacy Clients/Students/Client Profiles/Student Profiles migrated to canonical Person + Guardian + Tenancy Junction with shim layer retired, stable observation windowstable 58drefreshed 58d ago
CL-PLT-0002 cutover progress; canonical Person stack populated from legacy backings, downstream consumers (Sales' X-1 reads, Revenue's consumer-side re-points, Growth's lead_intake.person_id resolution path) all flipped to canonical reads
trend:Platform-owned four-table import landed from the operator's 2026-05-07 exports: 32 Client/Student rows resolve to Persons, 23 Client Profile tenancies upserted, 3 active Guardian relationships retained, 9 Student Profiles inventoried; downstream consumer flips and stable observation still open→observation harness added in Platform commit 43b53cc; npm run cl-plt:observe reports Platform foundation complete (93 Persons, 23 PersonTenancies, 3 active Guardians), Sales observed (IDENTITY_DEV_STUB=false, 48 Person-attached Leads), Growth observed (17 intake.captured v2 events, 15 personId-backfilled lead_intake rows), Delivery and Revenue not yet observed in their own schemas; indicator remains in progress→in progress: Platform foundation now includes 89 Persons, 23 PersonTenancies, 23 Square PersonExternal rows, and 3 active Guardians; Sales and Growth are observed, Delivery participant backfill auditability is at target, and Platform supplied Revenue's full Client Profile plus Client External bridge map on 2026-05-14; remaining signal is downstream stable observation after Revenue consumes the bridge map→completed: Revenue confirms migration complete per 2026-05-16-revenue-per-cluster-handoff-consolidated (all ten Revenue module repos on Prisma after 2026-05-15 Airtable cutover; charge-resolution.pg.ts reads client_external_identity_bridges per ADR-0010; card-externals identity reads flipped through Identity v1.1). Platform foundation (89 Persons, 23 PersonTenancies, 23 Square PersonExternal rows, 3 active Guardians) plus Sales, Growth, Delivery, and Revenue all observed downstream
Growth touchpoint dbt model livecompleted: growth.touchpoint relation exists with 136 rows; intake.captured v2 events=16; visitor_id rows=10; confidence direct=16, visitor_id_stitch=1, cross_device_stitch=0, unattributed=119; natural same-visitor stitching observed, cross-device natural test deferred to 2026-05-07-platform-growth-cross-device-stitch-natural-test-deferred→model live in warehouse with v2 traffic flowing and confidence-tagged stitching working (direct, visitor_id_stitch, cross_device_stitch, unattributed)refreshed 67d ago
Warehouse semantic-layer dbt model for growth.touchpoint per 2026-05-01-platform-growth-attribution-stitching-shape; closes Platform's conditional commitment to Growth
trend:worker runbook and smoke check added; npm run growth-intakes:smoke verifies Growth intake.captured v2, Platform intake.matched, and Growth personId backfill agree after a web-form submission→rollback fixture npm run warehouse:test:visitor-stitch proves the live growth.touchpoint model can classify a same-visitor unmatched touchpoint as visitor_id_stitch; initiative remains in progress until naturally observed visitor_id_stitch traffic appears→cross-device stitch rule added using Growth subscriber bridge evidence; rollback fixture npm run warehouse:test:cross-device-stitch proves the live growth.touchpoint model can classify a bridged different-visitor touchpoint as cross_device_stitch; initiative remains in progress until naturally observed visitor_id_stitch and cross_device_stitch traffic appear→completed: natural same-visitor stitch observed in growth.touchpoint (visitor_id_stitch_rows=1) with web-form v2 traffic and Platform intake matcher working; natural cross-device stitch testing deferred to open memo 2026-05-07-platform-growth-cross-device-stitch-natural-test-deferred because subscriber bridge traffic is not currently present
Intake captured v2 schema registeredcompleted: contracts/identity/schema/payloads/intake.captured-v2.json registered in event-types-registry→v2 payload schema entry in event-types-registry, available for Growth's producer to validate againststable 67drefreshed 67d ago
intake.captured v2 schema registry entry per 2026-05-01-platform-growth-subscriber-promotion-confirmed; few hours of Platform work, naturally lands just before Growth's v2 producer flip
Dispatcher sdk phase 3completed: Platform commit bb46b0a adds dispatcher observability hooks, Phase 3 metrics docs, Coaching cutover guide, and Revenue/Coaching reference implementations→docs published, observability hooks live (per-event-type publish-count, per-(consumer, event_type) consume-count, dedup-hit-rate, dead-letter-rate, end-to-end-latency), Coaching cut-over migration guide written, reference implementations for Revenue lock-state-machine emit and Coaching availability-projection subscriberstable 67drefreshed 67d ago
Dispatcher SDK Phase 3 deliverables; Phase 2 transport already live, Phase 3 is the ergonomics layer (docs and observability) plus migration guide
Auth consumer surface readycompleted: AUTH_DEV_STUB flipped off in Sales; auth consumer SDK returning operator-tenant-roles from a real session against the production-facing path→production-ready consumer SDK path that returns operator-tenant-roles from a real session, Sales' AUTH_DEV_STUB flipped off and stablestable 58drefreshed 58d ago
Auth consumer surface readiness check; Sales' initiative has the corresponding AUTH_DEV_STUB-off indicator, this is the Platform-side mirror of the same handshake
trend:completed: AUTH_DEV_STUB=false in Sales and Sales auth bootstrap smoke passed with a real signed-in session→completed: AUTH_DEV_STUB=false in Sales production path and Sales auth bootstrap smoke passed with a real signed-in session; local .env values are not authoritative for this production-facing indicator→in progress: AUTH_DEV_STUB=true in ../sales/.env→completed: AUTH_DEV_STUB flipped off in Sales; auth consumer SDK returning operator-tenant-roles from a real session against the production-facing path
Markets ownership decisionfiled: 2026-05-23-platform-markets-ownership-position→position filed on the Markets-ownership thread; Delivery's Service-Area-routing-chain piece unblockedstable 70drefreshed 58d ago
Markets-ownership decision filed; Delivery's chain piece is unblocked by Platform's position memo.
Growth initiative scope under the no-rocks no-dates shift
CompleteDone
Lead intake postgres coverage100% on both write paths (website form + Meta lead-ads webhook); Airtable write path retired from production code→100% on both write paths, stable observation window
Share of lead_intake writes on Postgres versus Airtable across the website /api/lead-intakes path and the Meta lead-ads webhook path; initiative completion on this axis when the Airtable write side is dropped from the production code path
Intake captured v2 coverage5 of 5 recent intake.captured events at v2 with visitor_id (100.0%, last 7d)→100% with visitor_id populated, stable observation windowstable 58drefreshed 58d ago
Share of intake.captured events emitted at schema_version 2 with visitor_id populated; v1 retires when this stays at 100% and Platform's growth.touchpoint dbt model has v2 traffic to scaffold against
Sales initiative scope under the no-rocks no-dates shift
CompleteIn progress
Dispatcher dev stub offfalse (DISPATCHER_DEV_STUB=false in ../sales/.env)→DISPATCHER_DEV_STUB unset in production with clean lead.* emit through the real bus, stable observation windowstable 58drefreshed 58d ago
DISPATCHER_DEV_STUB env flag state in production plus producer-transactional-guarantee shape on lead.* emits; flip is Sales-internal code work since Phase 2 has shipped
trend:false (DISPATCHER_DEV_STUB=false in ../sales/.env)→completed: DISPATCHER_DEV_STUB=false and readiness smoke inserted a real dispatcher lead.created event→completed: DISPATCHER_DEV_STUB=false and readiness smoke inserted a real dispatcher lead.created event on 2026-05-07→false (DISPATCHER_DEV_STUB=false in ../sales/.env)
Auth dev stub offtrue (AUTH_DEV_STUB=true in ../sales/.env)→AUTH_DEV_STUB unset in production with operator-tenant-roles resolved through real auth sessions, stable observation windowstable 58drefreshed 58d ago
AUTH_DEV_STUB env flag state in production plus auth-resolution health; Platform bootstrap now returns tenant_id and Sales maps Platform owner/admin to the existing sales-ops-admin gate without creating new Platform role vocabulary
trend:false (AUTH_DEV_STUB=false in ../sales/.env)→completed: AUTH_DEV_STUB=false and auth bootstrap smoke passed with a real signed-in session→completed: AUTH_DEV_STUB=false and auth bootstrap smoke passed with a real signed-in session on 2026-05-07; local .env values are not authoritative for this production-facing indicator→true (AUTH_DEV_STUB=true in ../sales/.env)
Operator postgres opt in coverage0% (no operators)→100% of in-cadence operators on the new Sales appstable 58drefreshed 58d ago
Per-operator cadencePostgresReadsOptIn flag coverage; tracks the C-4 cohort rollout, opted-in operators use the new Sales app while opted-out operators continue using the legacy Airtable interface directly
trend:0% (no operators)→100% (1/1)→completed: 100% (1/1)→0% (no operators)
Airtable dev stub offfalse (AIRTABLE_DEV_STUB=false in ../sales/.env)→AIRTABLE_DEV_STUB unset in production with Airtable read paths gated behind canonical Postgres surfaces, stable observation windowstable 58drefreshed 58d ago
AIRTABLE_DEV_STUB env flag state in production; the stub gates Airtable reads while Sales' modules cut over to Postgres; flips off as the cadence runtime, lead pipeline, and Lead inbox fully retire their Airtable read paths
trend:false (AIRTABLE_DEV_STUB=false in ../sales/.env)→completed: AIRTABLE_DEV_STUB=false, operator-facing Sales app reads are Postgres-backed, and remaining Airtable usage is drift/mirror/migration tooling→completed: AIRTABLE_DEV_STUB=false, operator-facing Sales app reads are Postgres-backed, and remaining Airtable usage is drift/mirror/migration tooling on 2026-05-07→false (AIRTABLE_DEV_STUB=false in ../sales/.env)
Identity dev stub offfalse (IDENTITY_DEV_STUB=false in ../sales/.env)→IDENTITY_DEV_STUB unset in production with Person reads through the canonical Identity contract surface, stable observation windowstable 58drefreshed 58d ago
IDENTITY_DEV_STUB env flag state in production; the stub returns synthetic Person resolution while Sales' Lead-to-Person attachment via intake.matched and X-1 consumer-side reads cut over to canonical Identity v1.1; flips off when X-1 lands
trend:false (IDENTITY_DEV_STUB=false in ../sales/.env; readiness smoke passed against real Person-by-id and adult comms-routing)→completed: IDENTITY_DEV_STUB=false and readiness smoke passed against real Person-by-id plus adult comms-routing→completed: IDENTITY_DEV_STUB=false and readiness smoke passed against real Person-by-id plus adult comms-routing on 2026-05-07→false (IDENTITY_DEV_STUB=false in ../sales/.env)
Done
Cadence state drift ratecompleted: 0% drift (49 processed, 0 with drift after Airtable mirror backfill and readback patch on 2026-05-07)→zero drift over a stable observation windowrefreshed 67d ago
Postgres-Airtable cadence-state drift rate from the hourly drift-check script (C-6 in 2026-05-14-sales-cadence-runtime-cutover-design); precondition for retiring the Airtable write side
trend:0% drift (49 processed, 0 with drift after Airtable mirror backfill and readback patch)→completed: 0% drift (49 processed, 0 with drift after Airtable mirror backfill and readback patch)
Customer handoff emit healthcompleted: Sales subscriber transport, payload-composite dedup, close-handler feature flag, transactional first-lock emit, and handoff audit are ready; Revenue answered on 2026-05-07 that no new Sales work is requested→Sales-side customer.handoff readiness complete; Revenue canonical producer traffic observation tracked outside the Sales migration initiativestable 67drefreshed 67d ago
Sales-owned customer.handoff readiness for the migration initiative; Revenue canonical producer observation no longer gates Sales migration completion and is tracked in Revenue's cutover lane
trend:in progress: Sales emit ON; no canonical Revenue customer.handoff traffic observed in this window (since=2026-05-06T04:53:04.586Z, tenant=tnt_sguild, revenue=0, sales=0, firstLocks=0)→completed: Sales subscriber, payload-composite dedup, close-handler feature flag, and handoff audit are ready; Revenue reply requested in 2026-05-07-sales-revenue-customer-handoff-producer-observation-ask→completed: Sales subscriber transport, payload-composite dedup, close-handler feature flag, transactional first-lock emit, and handoff audit are ready; Revenue answered on 2026-05-07 that no new Sales work is requested
Revenue 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