B2B Customer Portal

Deployment

• A v* tag releases only if it matches the version number and points at a commit on main; offline tests run before the build.
• Migrations run before the service starts, under a separate migration login. They only add, never drop, because a rollback reverts the code, not the schema.
• A health monitor outside the app checks every five minutes; releases open a maintenance window so they don't raise false alarms.

Network

• The app listens only on loopback behind a reverse proxy. Admin and debug paths return 404 at the proxy, and the app checks permissions on them too, so both layers block them.
• HTTPS is required: the session cookie is Secure, and a non-Secure setting fails at startup.
• Opening the database port to the internet was proposed and rejected.

Verification

• Every custom CI check was tested against a planted violation, which turned up three checks that could never have failed.
• CI confirms the tests actually ran: no silent skips, and "0 tests, exit 0" doesn't pass.
• CI never touches the live ERP; everything runs against fixtures.

Writes

• Every ERP write takes two steps: the first request is forced to dry-run and shows exactly what would be sent. The idempotency key is the portal's own order number.
• Going live is a separate manual step that a release never turns on.
• The ERP is written first, and the local copy updates only after it succeeds; the local mirror tables are read-only, enforced by separate database logins.

Record-keeping

• The decision log is append-only: an overturned decision stays, with a note. By the log's own account, the table of rejected alternatives is the part that matters most.
• Each risk is paired with the check that guards it. Some passages in the docs were wrong for weeks; once that came to light they were kept, with a note on what was wrong, instead of being quietly fixed.