Delnavazan Platform
Canonical Core foundation for Delnavazan. No Amelia or provider integration.
Install
No release zip yet. The repository archive installs, but the folder name will carry the branch suffix and updates will not flow:
wp plugin install https://github.com/mr-m13/delnavazan-platform/archive/refs/heads/main.zipDelnavazan Platform is the incremental, internally controlled foundation for moving academy authority away from architectural dependence on Amelia without disrupting the live academy. It owns durable business identity and canonical state; external systems reference that state through explicit service boundaries.
Safety warning: Source completion never authorises deployment, production changes, Amelia writes/removal, payment activity, external communication or authority cutover.
Current status
| Item | State |
|---|---|
| Authoritative main | Phase 2A.2-R1 implementation merge at f9df3bfb0fda79fba7dee916c4687464ee67d480 (Schema 25 / R1 complete), with the R1 and R2 candidates materialised on top at 559b1736621c9ed32e41dd2b785dd0f040dcb647 |
| Platform / schema | 0.1.0 / 31 candidate |
| Migrations | 001–031 candidate; latest 031_portal_facing_services_principal_authorization |
| Latest merged slice | Phase 2A.2-R1 — Commercial Purchase, Funding & Current-Term Capacity Authority (Schema 25; merged / closed) |
| Previous merged slice | Phase 2A.2-Q — Post-Intro Continuation & Slot Reservation Authority (Schema 24) |
| Previous Platform candidate | Phase 2A.2-U — Finance, Payability, Effective-Dated Teacher Rates, Statements & Audited Corrections (Schema 30; awaiting independent review) |
| Base Platform candidate | Phase 2A.2-T — Provider-Neutral Payment Execution Seam & Stripe Adapter (Schema 29 / migrations 028_payment_execution_seam_provider_adapter and 029_payment_event_decision_claim_authority / build phase2a2t-payment-execution-seam-stripe-adapter-20260925.14; correction round 14 applied, awaiting independent review — implements the round-14 contract docs/PHASE-2A-2T-PAYMENT-EXECUTION-SEAM-STRIPE-ADAPTER-CONTRACT.md, additive on top of the V candidate. Correction round 10 closes the two blocking findings of the review of 5d8c379f92cef13baf0a818850661fcb7658509a: the per-event decision claim is now 029_payment_event_decision_claim_authority's own additive repair, scheduled and verified before the schema option may advance to 29, so a database that already completed the fifteen-table 028 is migrated instead of failing closed on a table no migration would create; and the claim's lease is now the bounded window the owner re-proves and renews before every R1/R2 work unit, so an expired generation stops before the work instead of resuming into it after a successor completed the decision. Correction round 11 closes the one blocking finding of the review of d60544a7c30231ec82b887b8238561b4c46dfce0: the R1/R2 work unit is now fenced for the duration of its work — at the connection's statement boundary, from inside the unit's own transaction, before every statement it runs — so the claim row is held for the whole transaction a unit runs in, a take-over can no longer interleave with a unit, and a unit whose window closed mid-transaction is rolled back by its own R1/R2 service instead of completing a mutation it had already started; the stale generation releases the claim it appended nothing to and the next generation completes the event's decision. Correction round 12 closes the one blocking finding of the review of 09c4134381ba31c8332a0561bec96c9cbd5238e9: the decision append is now bounded by the claim's window — the fenced claimed → settled transition requires the owner's own live slot and an unexpired lease_expires_at as well as its generation and token — so a lease that lapses after the final R1/R2 work unit publishes nothing and the owner releases the live claim it appended nothing to and converges. Correction round 13 closes the one blocking finding of the review of e92a62747b82f8a37838f886a1034eb770f65e37: that window is judged at the instant the transition itself runs, from one database-time expression that fences the predicate and stamps the settlement alike, and the transition takes no instant parameter at all — so a hook callback on the append seam, or any delay before the statement acquires the claim row's lock, can never settle a window that has already closed. Correction round 14 closes the one blocking finding of the review of 057acaeea06bf8d0c2eef2f3039c66295988a3d9 / tree 1c5545c585e49b46b2f7608d89965f07bf3dd3a5: because UTC_TIMESTAMP() is evaluated once at query start, the append's window verdict is now taken by a transition that already holds the claim row — a fenced locking read takes the row lock and the wait, where the wait decides nothing, and only the conditional claimed → settled update that runs afterwards judges the window — so an append queued behind another transaction's lock of that row until the lease lapsed settles nothing and appends nothing, and the new twenty-fourth concurrency mode append_blocked_on_claim_row proves exactly that. Round 9's closures are retained: a durable per-event decision claim makes an event that owes a decision recoverable and makes a pending-decision retry exactly-once (the loser performs no work and converges), the §9.2 HTTPS requirement now honours a configured, allowlisted proxy header without ever trusting a client's own, and an OPTIONS delivery — which WordPress answers before normal route dispatch, so no receipt was written — is now intercepted ahead of WordPress's own handler and receipted method_not_allowed with its exact raw body. Its §17 runtime, webhook, migration, secret, corruption, failure and twenty-four-mode concurrency suites have not been executed: PHP and the disposable runtime are unavailable in the implementation environment.) |
| Previous Platform candidate | Phase 2A.2-V — Provider-Neutral Google Calendar & Meet Integration (Schema 27; five correction rounds applied, awaiting independent review) |
| Earlier Platform candidate | Phase 2A.2-R2 — Renewal, Next-Term, Recurring Enrolment/Collection, Recovery, Lapse & Refund Authority (Schema 26; correction rounds 1–6 applied, awaiting independent review) |
| Active Platform candidate | Phase 2A.2-W — Portal-facing services, principal resolution, object-level authorization and purpose-bound signed public capabilities (Schema 31 / migration 031_portal_facing_services_principal_authorization / build phase2a2w-portal-facing-services-20260926.1; additive candidate, public actions disabled by default, absence delegation deferred pending the Phase-P owner seam, awaiting independent review) |
| Next boundary | Independent review of the Phase 2A.2-W candidate and its outstanding runtime evidence. No live credential, provider traffic, production data, live charge, refund, notification delivery, payout, Theme change, deployment or production cutover is authorised |
Read the continuity record before beginning work. It records exact SHAs, the locked Booking Request → Proposal → Acceptance → Conversion hierarchy, Theme/staging state, commercial facts and the current execution posture.
Architectural direction
The canonical business concepts are Teacher, Student, Instrument, Course, Enrolment, Term and Lesson. Lesson is the later operational centre for attendance, scheduling, finance, notifications and provider integrations. Provider identifiers are mappings, not business identity.
The completed coordination path is deliberately layered:
Booking Request → Coordination Case → Candidate Teacher → Availability Assent
→ Proposal Family → Teacher-specific Option → immutable Proposal Version
→ Provisional Acceptance → Final Acceptance / Accepted Service Arrangement
→ canonical Enrolment conversion → M0 current Enrolment → Teacher Assignment → canonical Term → canonical Lesson authorityProposal is not acceptance. Acceptance is not conversion authority. Conversion creates one Student + Course Enrolment and does not create Teacher Assignment. Current Teacher authority belongs to the separate Assignment aggregate. Phase L owns canonical Term creation/lifecycle authority. M0 makes the Enrolment lifecycle graph operational; Phase M makes canonical Lesson issuance and its bounded terminal lifecycle authoritative only.
Repository rule
Platform development is incremental and bounded. New work requires an explicit phase contract, migrations are versioned/retry-safe, and business-critical changes require focused source/runtime/concurrency validation. Do not add new Amelia coupling, public authority, payment, notification, calendar or provider behaviour without explicit approval.