Where the testing actually stands

Why there is no pass rate on this page

There is a large automated suite and this page used to carry a headline figure from it. That figure has been taken down, and the reason is worth stating precisely rather than glossing.

The last complete run was on 31 July 2026. Every stack trace in that log names test app 0.1.0.20, while the tests in source are at 0.1.0.27. The commit that took them there is called Make AL test fixtures self-resetting on a populated tenant, and the largest single group of failures in that run were duplicate-key inserts — precisely the class of failure that commit was written to eliminate. The run therefore measured an old copy of the tests against the current product, and its result describes neither.

So the honest position is that the suite as it stands has not been run end to end. A figure I have not stood up is worth less to you than this paragraph, and the only thing that would make it worth quoting is the run itself.

What is not in question

What Trident adds to your Sales documents

Everything else Trident installs is new and self-contained. These fourteen objects are the exception: they add Trident's fields and actions to Business Central's own sales invoice and credit memo, which is how an invoice raised from a charter stays a normal invoice your finance team already knows how to work with.

What has to happen before a number goes back here

One full run of the current suite against the current build, on a machine that can compile it. The laptop this was written on now runs an endpoint security policy that denies the compiler access to its own libraries, and working around a security control is not something I will do. The work moves to my own machine, and the figure returns to this page when the run behind it is real.

---

Proven, with evidence on disk

Multi-blocker closeout evaluation

The workbench checklist used to case on a single cascade enum, so a charter blocked on billing reported invoice posting and payment collection as Not Applicable even when a draft invoice and an unpaid posted invoice both existed. The three billing rows are now computed from facts, mirroring how the APA rows already worked, and an APA Statement row was added. A charter now reports every simultaneous blocker.

Live non-SUPER persona proof

Three container users, each holding exactly one persona permission set and no SUPER, were driven through the running product on 31 July 2026 at build 0.1.0.7. Fourteen screenshots and a manifest are held under artifacts/uat-runs/20260731-live-persona-proof-0.1.0.7. It is not yet stamped against the paid-pilot evidence gate because the readiness script is blocked by endpoint security policy on the machine that has to run it.

Seven permission defects the proof found

Running the product as a real restricted user, rather than asserting about permission sets in a test, surfaced defects that no unit test had caught. Each was fixed and re-proven.

Package boundary

The shipping app and the test app are separate. A static gate asserts zero Subtype = Test objects in src/, and the package inventory is checked on every release-candidate run. What a customer installs cannot contain a test, a fixture or the demo seed.

---

Under test now

• Publish-as-upgrade rehearsal from a clean tenant. Upgrade code has been exercised against my own CRONUS, which is unrepresentatively test-heavy. Proving it against a tenant that holds ordinary charter data is the last structural thing between here and a pilot install.
• A full run of the current suite on a machine that can compile the build, which is the run described at the top of this page and the thing standing between here and a published pass rate.
• Stamping the executed persona proof against the paid-pilot evidence gate, which needs the readiness script to run on a machine where endpoint policy permits it.

---

No automated coverage yet

Listed because a reviewer should know where the gaps are, not because they are hidden.

• Payment reversal, unapplication and mixed application. The one acceptance criterion with no tests behind it at all. If your charters routinely see credit notes or one payment applied across several invoices, this is the area to hammer during a pilot.
• API page shape. The bound promote action has five tests; the shapes of charterContexts and apaExpenseImports themselves are only covered by live OData runs, not by an automated assertion.
• Evidence integrity. Origin stamping assertions, review-entry immutability negatives and cue drill-down truth are implemented but not yet asserted automatically.
• A static permission gate. Nothing yet checks each persona's declared permissions against what its codeunits actually read and write. Today that correspondence is proven by the live persona run, which is manual.

---

Documentation, now written

This section listed three unwritten documents until 31 July 2026. All three exist, and so does a fourth that was not on the list.

• Install runbook — upload, permission sets, setup, how to verify it landed, what an upgrade does to existing data, and how to take it out.
• Known limitations — what Trident does not do, what no automated test covers, and what has to change before anyone pays.
• API integration guide — the two published pages, the promote action and its four outcomes, and the permissions a service account needs.
• Release note 0.1.0.26 — what changed since April, the six upgrade steps that touch existing data, and the known issues that ship with the build.

The release note is the fourth, added the same day. It is the first one written for someone outside this project to read, and every build from here gets one. The pilot agreement is drafted but unreviewed, and it goes to a lawyer with the licence terms rather than being used as it stands — the commercial position says what that means for anyone thinking about signing.

---

Deliberately out of scope

These are not roadmap items. They are things Trident will not become, listed so nobody plans around them.

• Crew rostering, maintenance scheduling, itinerary planning, an owner portal, or a CRM.
• Dashboards that summarise numbers the charter list already shows.
• Any public API surface that exists to make testing easier rather than to serve a real integration.

---

Before a commercial release, not before a pilot

• allowDebugging is true and must be false for a commercial build. It is deliberately on so a pilot can be debugged.
• The legacy APA category bridge enum has to be retired, which needs a migration batch of its own.
• A real continuous-integration pipeline that compiles and tests on every change. Today that is a local script and my discipline.
• The EULA is a plain-language template and is labelled as such. It needs a lawyer before anyone signs it. A review brief has been prepared for a Dutch IT/IP lawyer, and one error it found is already flagged on the terms themselves: the establishment clause named the wrong country and the governing-law clause still names Portuguese law. Establishment is corrected; the law and forum clause waits for the lawyer rather than being quietly rewritten.

---

If this page is what you needed

Then you are the kind of reader I wrote it for, and the useful next step is to install it and try to break it. How to get it, or write to [email protected] and say what you would want to test first.