TRIDENT by Marvera

Docs · release note

0.1.0.39: the status history stops being anonymous

Every line in a charter's status history read the same way. This charter went from one status to another, at this time, by this person, for reasons nobody wrote down. Cancelling a charter has always demanded a typed reason, and the history sitting next to that cancellation said nothing about it. It now carries the reason and where the change came from.

packaged 13 August 2026 · not released

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 595 passed, 0 failed, none skipped across 31 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

The status history gains two columns: the reason given for the change, and where the change came from. Cancelling a charter fills both, because a cancellation is the one status change that already makes somebody type a reason and refuses to proceed without one. Every other way a status moves says so plainly instead of guessing.


Why this was worth a build

The reason typed at cancellation was never lost. It went onto the commercial trail, which is the record an accountant reads. The status history is the record an operator reads, and it sat right next to that trail repeating the same four facts for every line, none of which was the interesting one.

So somebody reviewing a charter six months later could see that it was cancelled and could not see why without opening a second list and matching entries by time. That is the kind of gap that only shows up when a charter is in dispute, which is the worst moment to find it.


A change that cannot name itself says so

Only cancellation fills the reason today. Everything else writes Unspecified and leaves the reason blank. That is the intended result, not a gap waiting to be filled in quietly.

The alternative was to have an unlabelled change default to the value that means a person did it through the screen. That would have been convenient and it would have been a small lie in an audit record, told by the software and not by anyone using it. A blank that admits it is blank is worth more to a reviewer than a plausible-looking answer.

Two of the four new tests exist only to prove that a reason set for one change never leaks onto the next one. A reason attached to the wrong line is worse for whoever is reading the history than no reason at all.


The evidence timeline shows both

The charter evidence timeline already gathers what happened to a charter into one ordered view. Both new columns flow into it, so the reason appears in the place somebody looks when they are trying to reconstruct a charter, not only on the history list itself.


What is not in this

  • Nothing is backfilled. Status history written before this build stays as it was, with no reason and no origin. Inventing a reason for a change nobody recorded would defeat the point of recording them.
  • No new way to type a reason. Cancellation already asked for one. No other status change gained a prompt, and adding prompts everywhere would be a decision about how operators work, which is not one to make from a keyboard.
  • Nothing new on the API. The two API pages are unchanged.

Upgrade notes

Going from 0.1.0.26 to 0.1.0.39 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 and the invoice language in the 0.1.0.38 note.

What 0.1.0.39 does to an upgrade
ChangeEffect on existing data
Two columns on the status historyAdded empty. Existing lines keep what they had, which is nothing, and no upgrade code walks them
The two columns on screenThey appear on the status history list and in the evidence timeline. Nothing was moved or removed to make room
Permission setsNone changed. Nothing in this build reads or writes anything it could not already reach

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:

  • Only cancellation names itself. Every other status change is recorded as unspecified, so the history tells you a reason exists where one was typed and stays silent everywhere else.
  • 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].