Docs · release note
0.1.0.43: the money that is not ours gets its extension points tested
A client hands over an advance for the crew to spend. Trident announces sixteen moments along the way that advance travels, so another extension can attach its own behaviour to any of them. Every one of the sixteen was written up in detail and not one had ever been listened to. They have tests now, and the tests found the awkward corner nobody would have known about until it bit.
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 625 passed, 0 failed, none skipped across 33 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
Nothing in the product changed. Not one line, not one field, not one permission. This build is seventeen new tests and the listener they need, and it takes the announcements Trident makes that are actually proven from six of 36 up to 22 of 36.
Why the advance was the group worth doing next
The build before this one proved the six charter state changes and said plainly that pricing, payments, invoicing and the advance were still nothing but a write-up. The advance is the largest of those groups and the one somebody is most likely to build on, for a simple reason: it is the only part of a charter where the money in question belongs to the client and not to you.
So it is where a broker wants their own approval step, or a feed into their own reporting, or a notification the moment a crew expense is refused. Sixteen announcements cover that path: an expense submitted, approved, rejected, reconciled against the bank one line at a time and once for the batch, a currency snapshot reviewed, an evidence exception waved through, an advance topped up or that top-up cancelled, and a statement drafted, issued or withdrawn.
All sixteen fired. Nobody had ever proved it, which means the documentation was the only thing vouching for them, and a document is not evidence.
What the seventeen tests hold
- It fires, and it fires once. Every test counts all sixteen announcements, not only the one it is interested in, so an announcement that goes off during the wrong operation fails the test written for the operation that behaved.
- It carries the saved record. The expense, the statement or the payment line arrives with the number and the state it has after the change is written, not the one it had going in.
- Two entries make two announcements. Not one, and not four. That sounds obvious until a batch operation is written.
- A refused operation is silent. Four of the seventeen exist only for this. Trident turns down a submission, a reconciliation with no deposit, an evidence exception with no reason and a top-up of nothing, and none of the four announces anything.
- Cancelling a top-up hands over something that no longer exists. The payment line is deleted and then announced, so a subscriber gets a copy of a row that is gone from the table. That is deliberate and it is now written down and tested. Anybody who assumed they could go and read that row would have found out at runtime.
A run that reported a pass while running nothing
This part was not planned and it matters more than the tests.
Every number on the status page comes from a run. On the way to this build, the thing that drives those runs reported success twice while measuring nothing useful: once against a stale copy of the tests belonging to the previous build, once against no tests at all. A suite with nothing in it has no failures, so it looks exactly like a pass.
A green figure over an empty run is worse than a red one, because it hides everything else. The run is now made to prove three things before its result counts: that the tests are installed, that they match the build being measured, and how many methods it actually counted. Pointed at nothing, it fails and says so. The figures published for this build come from a run held to that.
The same failure was caught and fixed once before, on 5 August 2026, and the fix covered every route into a test run except this one. That is the honest version: it was not a new problem, it was an old problem through a door nobody had checked.
What this does not cover
Fourteen of the 36 announcements are still unproven: the pricing, payment schedule and invoicing ones. If the moment you want to build on is one of those, ask before you build, because the write-up is the only thing standing behind it.
Nothing was added on the veto side either. None of the sixteen lets a subscriber cancel the operation or skip Trident's own validation, and that is deliberate.
Upgrade notes
Going from 0.1.0.26 to 0.1.0.43 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 and the charter state changes in the 0.1.0.42 note.
| Change | Effect on existing data |
|---|---|
| Seventeen 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 |
| Nothing else | No field, no table, no announcement and no behaviour changed. Upgrading from 0.1.0.42 migrates nothing and alters nothing you can see |
| Permission sets | None changed. Nothing in this build reads or writes anything it could not already reach |
What a tenant on 0.1.0.42 gains from this build is not a feature. It is that sixteen of the announcements it could already subscribe to are now known to work.
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:
- Fourteen of the 36 announcements are still unproven. Pricing, payment schedules and invoicing. Ask before building on one.
- 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].