Docs · release note
0.1.0.44: every announcement Trident makes is now proven
The two builds before this one proved 22 of the 36 moments Trident announces to other extensions. This one proves the last fourteen: payment schedules, invoice payment state, document links, the three built lists, the commercial log and the APA settlement document. Subscribing turned out to be the first time anybody learned what two of them actually do, and a third group that three documents described does not exist at all.
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 642 passed, 0 failed, none skipped across 34 test codeunits on the morning 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 from 22 of 36 proven to all 36. Where a test disagreed with the write-up, the write-up was corrected. No assertion was relaxed to make a page true.
Why these fourteen were last, and why they still mattered
The charter state changes went first because everything hangs off them, and the advance went second because it is the client's money. What remained was the connective tissue: the payment schedule a charter is billed on, the sync that keeps a payment line's paid state honest against the ledger, the links that tie a charter to its documents, the three lists Trident builds for closeout, evidence and readiness, the commercial log, and the settlement document that ends an advance.
Every one of the fourteen was published and written up in detail, and none had ever been listened to by anything. So the parameter tables described intent, not behaviour. The gap the three builds close is not that the announcements were broken. It is that nobody knew.
What the seventeen tests hold
- It fires, and it fires once. Every test counts all fourteen announcements, not only the one it is interested in, so an announcement going off during the wrong operation fails the test written for the operation that behaved.
- Both ends of a change are announced. Posting or staling a document link announces before and after, carrying the status left and the status reached. Marking a payment line paid announces before, after, and the promotion itself, once each, on the same line.
- A built list announces every row. The closeout checklist, the evidence timeline and the readiness list each announce once per row, and the count has to match the rows built.
- A refused operation is silent. A commercial log call that errors announces nothing.
- The two vetoes do what they do, on the record. One announcement lets a subscriber take over the paid-state sync outright and hand back its own count. Another lets a subscriber waive the protection on a payment line Trident would refuse to delete. Both are now pinned by a test instead of a sentence.
Three things the write-up had wrong
This is the part of the build worth reading. A green count says the announcements work. These three say why a test is worth more than a description.
The delete veto waives a protection, it does not replace the delete. The write-up said a subscriber vetoing a payment line's deletion takes over the delete behaviour. What actually sits behind that announcement is a guard refusing to delete a locked or processed line, so the veto removes the protection and the line goes. A partner reading the old sentence would have built the opposite of what they meant. The test asserts the truth and the write-up now says it in those words.
The announcement made when a payment line is created cannot carry the line's number. The platform assigns that number after the moment the announcement fires, so every subscriber reads zero, however the line was created. The first version of the test asserted the real number and went red, which is how this was found. The write-up now carries the trap: anyone who needs the number has to re-read the record.
There is no pricing announcement. Three documents described the remaining unproven group as pricing, payment schedules and invoicing. Applying a pricing scheme's defaults announces nothing, before or after. Nothing was unproven there because nothing exists there. That is now written down as a gap in the surface instead of a gap in the evidence, and adding the announcement is a product change this build does not make.
What this does not cover
The announcements are proven to fire, to fire once, and to carry what they promise. That is a statement about the extension surface, not about the features underneath it, and every limitation on the known limitations page survives this build untouched.
And the surface being fully proven does not make it complete. The pricing moment a partner might reasonably expect is not thin or untested. It is absent, and the correction above is where that is recorded.
Upgrade notes
Going from 0.1.0.26 to 0.1.0.44 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 and the advance announcements in the 0.1.0.43 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.43 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.43 gains from this build is not a feature. It is that every announcement it could already subscribe to is now known to work, and that two descriptions it might have been building from said the wrong thing and no longer do.
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:
- There is no pricing announcement at all. A partner who wants to attach to a scheme's defaults being applied has nowhere to stand. That is a missing seam, not a missing test.
- 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].