Kernel Hardening — Milestone 3 Defect Closure and Migration Tracking

This release closes two blocking defects introduced by Milestone 3 and establishes the migration tracking infrastructure required for pre-flight baseline verification in all future kernel migrations.

Defect A — Invalid Default on Organisation VAT Scheme (Breaking)

The organisation VAT scheme column carried a default value that the Milestone 3 validity constraint rejects. Any new organisation registration that did not explicitly supply a VAT scheme would fail at the database boundary with a constraint violation — a silent insert-path defect introduced at the point of adding the constraint.

Fix: The default is removed entirely. The service layer must supply an explicit VAT scheme on every organisation creation. This aligns with the kernel principle that financial columns must not carry silent defaults — no fallback, no assumption.

Breaking change: Any code path that omits VAT scheme on organisation creation now fails at the database boundary. All such paths must supply an explicit value.

Enforcement: Default removed — migration 072. Class M (database constraint rejects any non-permitted value; removal of the default forces explicit supply at the service boundary).

Defect B — VAT Sign Enforcement (Class O → Class M)

Invoice line VAT sign alignment — the rule that VAT must carry the same sign as net — was previously enforced only by the arithmetic behaviour of the canonical reduction function. Correct by construction, but not independently verified by the database. A bug in the function, a direct update, or any future code path bypassing the function could silently produce a sign-inverted VAT value with no database-level rejection.

A dedicated database constraint now enforces sign alignment independently. Any row where VAT carries the opposite sign to a non-zero net value is a fatal database exception — regardless of how the row was written.

The constraint permits zero VAT against non-zero net values (exempt, zero-rated, outside-scope). Sign enforcement applies only where both net and VAT are non-zero.

Enforcement: Database CHECK constraint — migration 072. Class M. Two independent layers now cover VAT sign: the reduction identity constraint (enforces exact computed value) and the sign constraint (enforces directional alignment independently). The sign constraint provides a lightweight invariant that remains valid even if the canonical reduction function or its constraint were altered in a future migration.

Migration Tracking Infrastructure

Prior to this release, SpeyBooks had no mechanical record of which migrations had been applied to production. Pre-flight baseline checks in kernel migrations had no table to query, making sequencing verification impossible at the database layer.

Migration 073 introduces a dedicated migration tracking table recording the unique migration filename and apply timestamp for every migration. All previously applied migrations are backfilled with approximate timestamps derived from file modification history. Operational scripts — rollback scripts, verification scripts, test data scripts — are explicitly excluded from the record.

Each migration filename is unique and may appear only once in the table. Migration records are append-only. Existing rows must never be updated or deleted. The table represents the historical execution log of the schema and is authoritative for migration baseline verification. The migration record is inserted as the final step before transaction commit, ensuring the record exists only for migrations that committed successfully.

From this point forward, every migration self-records on commit, and pre-flight checks can mechanically verify the expected baseline before making any changes.

A future enhancement (planned, not yet implemented) will add a checksum column recording the cryptographic hash of the migration file contents at apply time. This will allow detection of post-apply edits or tampering with migration files — a common silent corruption vector in long-lived systems.

Threat Closure

Verification Record

Apply order (migration 073 must precede 072 — 073 creates the tracking table):

Migration 073 post-commit:
  47 migration records inserted (46 backfill + 1 self-record) ✓
  Milestone 3 monetary migration present in record ✓
  Defect closure migration present in record ✓

Migration 072 pre-flight:
  PF-1  Baseline confirmed: tracking table present (migration 073 applied first)
  PF-2  Invalid VAT scheme default confirmed present
  PF-3  VAT scheme validity constraint confirmed present (from migration 071)
  PF-4  VAT sign constraint confirmed absent (not yet applied)
  PF-5  Zero sign-violation rows confirmed

Migration 072 post-commit:
  V1    VAT scheme column default removed ✓
  V2    VAT sign constraint present and validated ✓
  V3    VAT sign constraint definition matches expected expression ✓
        (verified via constraint definition query)