Docs · release note
0.1.0.42: the extension points get tested, and two missing ones get built
Trident announces a charter's state changes so another extension can attach its own behaviour to them. Two of the six announced nothing, which anybody building on the middle of a charter's life would have discovered at runtime and not before. Both announce now. The larger problem was quieter: the whole set was documented and nothing proved a single one of them fired.
What this build is
A package that exists is not a release. This one was built, tested and hashed, and it has not gone out to a pilot yet. Nothing earlier went out to a pilot either, so the first build a pilot receives will already have all of this in it.
The whole suite ran against it and came back 608 passed, 0 failed, none skipped across 32 test codeunits on the night of 13 August 2026. Run evidence is generated per machine and is not published. Ask and you get the raw result file.
The short version
A charter moves through six state changes: confirmed, started, invoiced, completed, closed, cancelled. Four of them told other extensions they had happened. Started and invoiced did not, and now do. Eight new tests hold all six to firing once, handing over the charter exactly as it was saved, and saying nothing at all when Trident refuses the change.
Why this was worth a build
If you want Trident to do something it does not do, there are two routes. Integrate with it from outside over the API, or extend it from inside by attaching your own code to the moments Trident announces. The second route is the cheaper one and it is the one the documentation invites, with 36 announcements written up, each with a code sample.
None of the 36 had a single test behind it. The document was the only evidence any of them fired, and a document is not evidence. Worse, two of the six charter state changes were genuinely silent. Somebody could have read the write-up, wired up confirmation and completion, watched both work, wired up the two in the middle on the same assumption, and found nothing happening with no error and nothing to read.
That is the kind of gap that costs a partner a day and costs Marvera the credibility of every other page like it.
What the eight tests hold
- It fires. One announcement per state change, which is the assertion that did not exist for any of the 36 before this build.
- It fires once. Each test counts every announcement Trident makes, not only the one it is interested in, so a change that announces itself twice, or announces the wrong thing, fails the test written for the change that did behave.
- It hands over the saved charter. The charter arrives with the number and the state it has after the change is written, not the state it had going in.
- It carries where the charter came from. Invoicing and cancelling both hand over the state the charter left, because a subscriber that has to reverse or reconcile something needs to know, and the charter itself no longer says.
- A refused change is silent. Two of the eight exist only for this. Trident turns down a start on a draft charter and turns down invoicing a charter already invoiced, and neither refusal announces anything.
What this does not cover
Six of the 36 announcements are now proven. The other 30, on pricing, payments, invoicing and the APA, are documented and have nothing behind them. That is a smaller version of the same gap and it is worth naming here instead of leaving it implied by a green number.
Nothing was added on the veto side either. None of the six lets a subscriber cancel the state change or skip Trident's own validation, and that is deliberate. The two places in Trident where an extension is allowed to take over are a payment line deletion and an invoice payment sync, both of them decisions a customer might legitimately make differently. Skipping a charter's validation is not on that list.
Upgrade notes
Going from 0.1.0.26 to 0.1.0.42 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 and the pricing scheme check in the 0.1.0.41 note.
| Change | Effect on existing data |
|---|---|
| Two state changes start announcing themselves | Nothing stored, nothing migrated. No extension can be listening to an announcement that did not exist until this build, so nothing installed changes behaviour |
| Eight new tests | None of it ships to you. The tests live in a separate package that belongs in the build environment and never on your tenant |
| Permission sets | None changed. Nothing in this build reads or writes anything it could not already reach |
One thing worth knowing if you write a subscriber. It runs inside the charter's own transaction, so an error thrown in your code rolls the state change back with it. That is useful when you mean it and expensive when you do not.
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, and this build closes none of it. What matters most alongside this particular change:
- Thirty of the 36 announcements are still unproven. If the one you need is not a charter state change, the write-up is the only thing vouching for it. Ask before building on it.
- The broker commission is still half a feature. A charter states what is owed and there is no way to pay it from Trident.
- 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].