# audit log 0.8.0 release notes

Version 0.8.0 adds managed manual transactions, optional event validation, operation diagnostics,
and SQL Server history queries. PostgreSQL remains the default provider. See the
[CHANGELOG](../../CHANGELOG.md), [Quick Start](../../README.md#quick-start), and
[feature guide](../product-quality.md) for installation and examples.

These notes describe the 0.8.0 source and package target. A version bump or dated changelog does
not establish npm publication; the release process verifies the registry artifact separately.

## New APIs and behavior

- `AuditService.withManualTransaction(client, callback, options?)` supplies a typed transaction
  and bound writer for manual events. Caught audit failures still prevent commit, started audit
  writes settle before completion, and writers reject after their callback ends. Existing
  `log(input, tx?)` remains available for caller-owned transactions.
- Opt-in `strictManualValidation` validates manual event inputs. `maxMetadataBytes` limits the
  final redacted metadata's JSON representation in UTF-8 bytes. Invalid inputs expose structured
  `AuditInputError` diagnostics before INSERT.
- `onAuditOperation` reports phase, outcome, and duration without event contents. Synchronous
  exceptions and rejected thenables from diagnostic observers are isolated from business writes.
  `getCapabilities()` reports configured provider support without a database request.
- SQL Server `query()` and `getById()` support explicit tenant-scoped reads, exact text filters,
  full-precision cursor timestamps, native ID ordering, and JSON/UTC normalization. Optional
  additive read indexes and read-only storage inspection help prepare history queries without
  increasing the runtime writer's privileges.

Both runnable Quick Starts pin 0.8.0. The PostgreSQL consumer runs its product-quality assertions
in packed and registry modes. SQL Server pre-publication verification uses the packed candidate;
its explicit registry mode is available after publication.

## Compatibility and upgrade

Existing manual logging and PostgreSQL automatic tracking contracts remain available. The new
manual validation options are opt-in; review the [API reference](../api-reference.md) before
enabling them for existing event payloads. The managed transaction helper is the option for
applications that need caught audit errors to prevent commit.

SQL Server automatic tracking, scan/export, retention, partitioning, GIN indexes, and rule
enforcement remain unsupported. Query APIs require an authorized reader with SELECT privileges;
an insert-only runtime does not gain read access automatically. See the
[SQL Server guide](../sql-server.md) for permissions, storage setup, and provider limits.

The supported runtime stays Node.js 22.23.4+ within 22.x or 24.22.1+ within 24.x. The pinned SQL
Server validation stack remains SQL Server 2025 with Prisma CLI/client/MSSQL adapter 7.10.0.
New additive read indexes are an explicit schema operation; upgrading npm does not install them.

## Validation scope

The 2026-10-26 implementation work includes local unit, type, PostgreSQL E2E, packed-consumer,
and SQL Server correctness verification. The repository records details in
`docs/2026-10-26-product-quality-plan.md`. Those results identify the code and environment tested;
they do not assert that the final 0.8.0 release commit has passed remote CI or been published.

Seven individual local PostgreSQL performance scenarios passed against published 0.7.1 with
unchanged limits: mean latency at most +10%, P95 at most +15%, and throughput at least −10%.
Automatic create used a predeclared controlled comparison across 32 fresh processes; its
one-sided 95% ratio bounds were +2.83% mean latency, +4.93% P95, and −2.75% throughput. The
other six scenarios passed both original formal runs. The
[benchmark guide](../benchmarks.md) explains the protocol and scope; the repository record
`docs/2026-10-26-performance-resolution.md` retains artifact identities and the original failure.
These measurements precede the 0.8.0 metadata bump and identify their candidate by integrity,
not by the new version number. They are neither a production SLO nor SQL Server performance evidence.

## Publication prerequisites

Standalone CI, packed documentation consumers and MSSQL preflight remain required for the package's
release validation. Optional soft-delete integration runs separately in the manually dispatched
`Ecosystem compatibility` workflow; it is not a dependency of CI or tag publishing.

The published PostgreSQL ecosystem fixture remains tenancy 0.15.0, audit-log 0.5.0, and
soft-delete 0.7.3. Candidate integration runs require an explicit exact published soft-delete
version rather than a default pin. Soft-delete 0.7.4 excludes audit-log 0.8.0 in its peer range,
so that combination remains unsupported. Strict peer and lifecycle validation must pass before
claiming a supported combined tuple; an unavailable compatible companion does not block the
standalone audit-log release. Do not bypass the peer check.

Follow the [0.8.0 verification and publication procedure](../maintaining.md#080-verification-and-publication)
for the final commit's standalone CI matrix, packed documentation consumer and MSSQL gate,
explicit publication, and registry verification. This version bump does not create a release tag
or publish a package.