0.1.0.46: applying a pricing scheme announces itself

---

The short version

When a charter takes on a pricing scheme, Trident applies that scheme's behaviour: whether an advance provisioning allowance is required, and the defaults that follow from it. Until this build that was the one lifecycle moment other extensions could neither see nor influence. Now it is announced on both sides. Before the defaults are applied, a subscriber is told which charter and which scheme, and can declare it has handled the application itself, in which case Trident's own defaults stand aside. After the application, whoever handled it, a second announcement says it is done. Everything else on the charter behaves exactly as before.

---

What the build does

• The moment is announced, both sides of it. These are the 38th and 39th moments Trident announces to other extensions, and they close the last named hole in that surface: pricing was the one group with nothing behind it, first as missing proof, then, once measured, as a missing moment altogether.
• A subscriber can take the application over. The before-announcement carries the charter and the scheme's configuration, and a subscriber that declares the work handled stops Trident's defaults from running. The after-announcement still fires, so anything watching for completion sees it either way.
• A scheme Trident refuses to apply announces nothing. A charter on a scheme with no usable configuration fails exactly as it did before, with the same error, and no subscriber hears about an application that never began. The same holds when the configuration exists and is switched off.
• Clearing the advance requirement announces completion too. A scheme configured to clear the advance provisioning fields took an early way out of the application, which would have skipped the completion announcement on exactly the path a subscriber watching the advance cares about most. The tests for this build caught it and it is fixed: that path announces completion like every other.
• The pricing machinery can now be addressed from outside. The part of Trident that applies scheme behaviour was closed to other extensions altogether. It is now open, which is what makes subscribing to either announcement possible at all.

---

The tests

Five of the 662 methods are new in this build. One proves both announcements fire around a normal application, once each, carrying the charter and the scheme they promise to carry. One proves a subscriber that takes the application over really does stop Trident's defaults, and that completion is still announced. Two prove silence where silence is correct: a scheme with no configuration and a scheme whose configuration is switched off each announce nothing. And one pins the fix above: a scheme that clears the advance requirement still announces completion. Every method that existed before them passed unchanged.

---

What this deliberately does not do

The checks come before the announcement, on purpose. A subscriber cannot rescue an application Trident has already refused, because a charter that fails to price should fail the same way whether or not anything is listening.

Nothing else moved. No new field, no new page, no new permission, and the pricing scheme's configuration carries exactly what it carried before. What a scheme's configuration should carry beyond this is still an open question, and it stays open until real charters have been run through it.

---

Upgrade notes

Going from 0.1.0.26 to 0.1.0.46 runs everything the 0.1.0.26 note describes, the six builds in the 0.1.0.31 to 0.1.0.36 note, the charter agreement terms in the 0.1.0.37 note, the invoice language in the 0.1.0.38 note, the status history in the 0.1.0.39 note, the pricing scheme check in the 0.1.0.41 note, the charter state changes in the 0.1.0.42 note, the two proof builds in the 0.1.0.43 and 0.1.0.44 notes and the commission deduction in the 0.1.0.45 note.

This build itself changes no data and no schema. No field is added, no table changes shape, no permission set moves, and no upgrade step runs for it. A charter behaves identically before and after unless another extension subscribes to the new announcements, which is the point.

Take the backup you would take for any extension upgrade. After upgrading, confirm the four assignable permission sets are still assigned as intended: Trident Admin, Trident Ops, Trident Read and Trident API. The procedure is in the install runbook.

---

What still ships broken

The full register is on the known limitations page. What matters most alongside this particular change:

• The pricing announcements carry behaviour, not prices. A scheme's configuration decides advance provisioning conduct and defaults. Nothing in it is a charter fee, and a subscriber looking for one will not find it here.
• The commission deduction is never posted by Trident. A finance user reviews and posts it. If you wanted the whole path automated, the build stops one step short on purpose.
• Retained and invoiced commissions are not built. If your brokers are paid as suppliers, this is not that.
• The cruising area does nothing. It is stored and displayed and no rule anywhere consults it.
• The security deposit has no posting path. Trident records that money is held and that it went back. Moving it is a bank transaction you do outside Trident.
• Neither API page has a runtime test that repeats. Two HTTP runs have proved the platform agrees with the source, the second of them as a restricted user and driven by a script, and nothing re-fires either when a page changes.
• No live non-SUPER sign-off exists for all three UI personas in a controlled tenant on this build.
• The licence terms and the pilot agreement are unreviewed. Nothing gets signed until both come back from a lawyer.
• No telemetry reaches Marvera. If something is wrong on your install, tell me, because I will not find out on my own.
• Still not submittable to AppSource, for one remaining reason that has never affected a per-tenant pilot install. Debugging is enabled as a deliberate pilot-time setting.

---

This build has its package hashes written down, so whoever is eventually sent the file can check they were sent that one. They are on the install page. Writing the hashes down is not the same as shipping, and the sentence at the top of this page still stands. If something here is wrong or unclear, say so: [email protected].