0.1.0.26 — enforced personas, deeper APA, and an integration surface

---

What actually changed

Three things changed the shape of the product between April and now.

Persona access stopped being a static permission-set grant and became something the product enforces when a page opens and again when a mutating action runs — and then every gap in it was found by running the build as a real non-SUPER user rather than by reading the sets.

APA grew the parts a charter operator actually settles on: a versioned final statement, append-only review history, live funding status, receipts and credits, and a currency snapshot that survives a rate change.

And a controlled API arrived, so an expense feed can stage rows and promote them without anyone being given a user licence and a login.

The test objects also left the shipped package. The production extension now contains no test, demo or support object at all; those live in a separate test app a customer never installs.

---

Added

Charter closeout

A Closeout Workbench with a checklist that reports every blocker at once rather than the first one it finds, and a role-centre cue for charters that are blocked from closing.

A commercial evidence trail

Register and entry tables that log lifecycle transitions, APA reconciliation and settlement, each entry carrying an origin, a reason comment and a correlation id. Both pages are read-only, and no assignable permission set grants direct write on either table. A charter evidence timeline sits alongside them, with drill-downs to the source record behind each event.

APA settlement, deepened

• Versioned final statements. Settlement and closeout derive from the issued statement rather than from a running total.
• Append-only review history, plus a baseline entry written by upgrade for every APA entry that predates it.
• Live funding status and controlled top-ups, with a reachable cancel path for a top-up that should not have been raised.
• Credits and receipt evidence, and an evidence state that flips to Attached when a receipt attachment exists.
• Currency conversion snapshots, charter-currency settlement truth, and a reviewed-resolution path for a snapshot frozen against a stale rate.

Charter preparation and contract readiness

A derived preparation status gates charter confirmation on customer, active vessel, valid dates, payment template, required APA bank and signed contract evidence, and reports every outstanding blocker at once instead of one field error. Contract reference, signed flag, and who signed it and when are stored on the charter.

A granular setup readiness check

Eleven checks, each with an action that opens the page that fixes it, replacing a single ready-or-not flag.

Two API pages behind a dedicated persona

charterContexts is read-only. apaExpenseImports stages rows and exposes a bound promote action that rejects duplicates by external id and records validation failures with error detail. The API guide covers the contract and its four outcomes.

Underneath

• Publisher events at several finance transitions, for partners extending rather than integrating.
• An access guard that enforces persona access at page open and at every mutating action.
• A separate test app, and a headless in-container test runner that needs neither the host PowerShell module nor a browser.
• The pilot documentation set: install runbook, known limitations, API guide, a support process, a security disclosure route, a trademark clearance record, a licence review brief for a Dutch lawyer, and an unreviewed pilot agreement draft.

---

Changed

• APA expense categories are table-driven and configurable. The category code is operational truth and the description is persisted as a snapshot. The old fixed enum is still written to entries as a compatibility bridge.
• Mutating actions are hidden from personas that cannot run them, rather than shown and then refused. A live run as a non-SUPER user found this; it was fixed and reproven.
• Each persona was granted the standard Business Central tables it actually reads and writes in its own context — found by running the build, not by reading the permission sets. Ops gained the writes its own actions need and the direct reads charter invoicing performs. The API persona gained indirect letters on APA ledger entries, then direct reads on General Ledger Setup and Currency Exchange Rate; that last one was invisible to the live call because the API user also held a base licence, and only a permissions-mocked test found it.
• Finance review ends its dead ends. Charters blocked on a required APA statement or a currency review now lead to a blocked outcome and a real document target, and count as finance review work.
• Support and security route to real addresses, replacing placeholders, and the shipped manifest points at this site.
• The finance cockpit caption was demoted to what it is — a launchpad.

---

Fixed

• Double billing, in both directions. Direct invoicing ignored an existing payment schedule and schedule invoicing ignored an existing direct invoice, so one charter could be billed twice. A third hole sat behind both: nothing rewrote the direct invoice reference after posting, so once the draft was posted the reference self-healed to blank and allowed a second direct invoice.
• Role-centre cues reported one set of records and opened another. Seven cues always rendered zero because their values were computed where the platform discards them. Eight drill-downs opened unfiltered lists. Both now match the cue's own definition.
• The second open of the role centre could throw "The record in table Trident Cue already exists". The activities part read an unkeyed record, always missed, and inserted; the table's insert trigger then forced the primary key, leaving an orphan blank-key row beside the real one. The table now owns initialisation and reads by the singleton key. An upgrade step removes the orphan rows an affected tenant already holds.
• Cancelling a charter no longer logs an empty reason — a reason is required.
• The APA category description snapshot survives status transitions, where it had previously been overwritten.
• Payment schedules are held to the charter's currency.
• Submitted APA entries can no longer be deleted, and negative charter amounts and guest counts are rejected.
• The payment schedule list gained the actions its FactBox already had, including invoicing a charter as the Ops persona.
• Document links and APA history are protected through indirect permissions rather than direct grants.
• A published test figure was withdrawn. A pass-and-fail count was recorded in the internal handoff and reached this site without ever having been measured. It was corrected in the repository, taken down from the site, and replaced by the rule at the top of this page.

---

Upgrade notes

Upgrading from any earlier Trident build runs the upgrade codeunit once per company. It is safe to re-run. Six steps touch existing data.

Four of those walk every APA ledger entry in the company. On a first install there are none and the upgrade is instant. Take the backup you would take for any extension upgrade.

The permission sets changed across this span. After upgrading, confirm the four assignable sets are still assigned as intended — Trident Admin, Trident Ops, Trident Read and Trident API. The full procedure is in the install runbook.

---

Known issues

The full register is on the known limitations page. The items that matter most to anyone installing this build:

• Payment reversal and unapplication have no test coverage. One test filters on the unapplied flag; none performs an unapplication and then asserts what the paid state and closeout readiness do afterwards. This sits directly under the paid-invoice truth closeout derives from.
• Neither API page has a test. The codeunit behind expense import staging is well covered; the page shape is not. Renaming a field on either page would break an integration and pass every test in the repository. Integrations must re-read the import status after calling promote, because the action reports success unconditionally.
• Permission sets are held against a committed contract, but the contract only records what is there today. A grant that changes fails the build. A grant that was already too broad when the contract was written stays, and is found by review rather than by CI.
• Live non-SUPER sign-off evidence does not yet exist for all three UI personas in a controlled tenant.
• The licence terms and the pilot agreement are both unreviewed, and the pilot agreement's governing-law clause is deliberately empty. Nothing is 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.
• Not submittable to AppSource as it stands, for two reasons that do not affect a per-tenant pilot install.
• Debugging is enabled in this build. A deliberate pilot-time setting, not an oversight.

---

Earlier release notes live in the private repository and cover pre-alpha builds nobody outside this project ran. This is the first one written for someone else to read. If something here is wrong or unclear, say so — [email protected].