Synthetic upgrade register: one invented Node.js app, five components and a ranked path

What this example is

This is a synthetic worked example. The application, its owner and its package names are invented, and no register like this was produced for any customer. The vendor dates are real and were read on 11 October 2026, but the application's versions are made up to show how an inventory reads. It is an inspectable specification of what an inventory and plan would contain, not a delivery.

• The invented app, 'Harbour Rota', is a Node.js service with an Express web layer, one compiled package and a PostgreSQL database.
• Its tests are assumed to run: 212 pass and 3 fail on the current versions (invented numbers).
• Nothing here says what your own app's register would show.

The register

Each row names the component, the version in use, the vendor's published status with the day it was checked, and what the status means for the plan. One row is unknown on purpose: an inventory that cannot find a published date says so.

If the matrix is wider than the box, scroll horizontally to read every column. Keyboard: focus the matrix and use Left/Right.

component             | in use  | published status (checked 2026-10-11)         | note
Node.js               | 20.x    | end of life 2026-04-30                        | past
Express               | 4.x     | support page not read in this example         | unknown, to confirm
native-resize (invented) | 3.2  | no published policy found                     | unknown, owner to decide
PostgreSQL            | 14      | final release 2026-11-12                      | within six weeks
Baseline tests        | 212 pass, 3 fail | recorded before any change             | the 3 failures are the baseline

The ranked path

The plan orders the work by prerequisites and deadlines, not by which component sounds scarier. Moving the Node.js runtime comes first because it is past its end-of-life date, and because Express 5 needs Node.js 18 or newer. The compiled package is checked within that step. Express 4 to 5 follows as a separate step, since its changes are to routes and errors. The database sits outside our fixed jobs: PostgreSQL's policy says a major upgrade needs a dump and reload or pg_upgrade, so it is quoted separately, and the plan says its date is the earliest on the list.

• 1. Baseline: record the 212 passing and 3 failing tests as they are.
• 2. Node.js 20 to 24 LTS, including the compiled package: size medium.
• 3. Express 4 to 5, after the runtime: size small to medium.
• 4. PostgreSQL 14 to a supported major: outside the fixed jobs; quote separately, date first.

What a reviewer would check

Every row has a source link and a checked date or says that none exists. The ordering has no step that depends on a later one. The unknown rows are named, with who must resolve them. The baseline lists the three failing tests by name rather than hiding them. A plan that omits any of these should be sent back.

• Count the manifest entries and the register rows: they must agree.
• Follow any step's prerequisites to a step with none.
• The register states no security conclusion: it records published dates only.