Conversation
…/auth.utils Both generators emitted @o3co/auth.utils and had their templates import createLogger / gracefulShutdown from it. That package treats pino as an optional peer and falls back to console, and the generator never emitted pino — so every generated instance has been logging bare `[name] …` console lines rather than NDJSON. Its gracefulShutdown also had no drain deadline (one stuck request meant SIGTERM never completed and SIGKILL cut the process mid-flight) and always exited zero. Each scaffold now carries src/logger.mts (pino, direct exact-pinned dependency; honours logging.level with LOG_LEVEL fallback; serialises `err`) and src/shutdown.mts (the contract auth.provider #290, auth.proxy #81 and auth.policy-verifier #210 adopted: bounded drain and cleanup, non-zero exit on a truncated drain, deferred exit so the last lines flush, `reason` naming what set the exit code). Both ship with tests that run under the instance's own `pnpm run test`. shutdown declares a structural Logger so the template does not depend on which upstream version the generator pins. The provider template reads logging.level defensively: the HOCON carries it but DplaaxAppConfig does not declare it, which the scaffold typecheck against the pinned module caught. Generator suites 97 / 110 (four new cases: no auth.utils emitted, pino emitted at a literal exact pin). Generated instances against the pinned develop module ref: typecheck clean, 18 / 26 tests. This was auth.utils' last consumer across the auth family. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
…e 0.3.x compat shim
Every workspace package now requires @o3co/auth.policy-verifier.{core,
builtins,server} ^0.8.1 and @o3co/auth-provider-{core,oauth} ^0.12.0 — the
versions published on 2026-09-06 — and the generators emit the same as exact
pins in DEFAULT_DEP_VERSIONS (0.8.1 / 0.12.0). Both generators move to 0.2.0
per create-app.md § 3.3 (defaults refresh in lockstep with a MINOR bump).
The lockfile no longer resolves 0.3.1 or 0.5.3 anywhere.
With the pin at the released API, the dual paths that kept 0.3.x loadable
are gone:
- policy-verifier-dplaax-module/collectors/context.mts (subjectClaims /
untrustedRequestFields, reaching readUntrustedRequestContext by
reflection) is deleted; the collectors read context.subject and call
readUntrustedRequestContext directly. Its three-case test goes with it;
the six collector/rule tests build CollectorContext in the current shape
(subject, marked requestContext, required signal). 50 cases remain: the
53 on develop minus exactly the 3 in the deleted file.
- The policy-verifier template and the integration test import
builtinKeyResolversModule instead of probing the server namespace for it,
and the template reads config.logging.level directly. The integration
test's `it.skipIf(!Reflect.has(server, "JWT_MODE_MIGRATION_MESSAGE"))`
guard is dropped — the export exists at 0.8.1 — so its two rows now run
(15 passed, up from 13).
The code had already crossed the intervening upstream BREAKING changes:
o3co/auth's provin-compatibility job builds this workspace against those
exact revisions. What changes here is that the released-0.3.x branch of
each dual path no longer exists to drift.
@o3co/ts.hocon stays at 0.1.5: its 0.1 → 1.x move is a separate migration.
Workspace gates: 550 tests across 7 workspaces, typecheck, lint, build.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Release merge from
develop, per the branch modelbranch-guardenforces (main only receivesdevelop,hotfix/*orrelease/*).What this promotes
a772a09— prepare Provin compositions for current auth APIs. The o3co auth packages moved on while these compositions stayed pinned to@o3co/auth.policy-verifier.{core,builtins}^0.3.1. Two documented breaking changes stood between:CollectorContext.payload: VerifierPayload→subject: SubjectAttributes(verifier #170)requestContextsealed behindreadUntrustedRequestContext(), so a collector has to name the trust level at the point of usepackages/policy-verifier-dplaax-module/src/collectors/context.mtsabsorbs both behindsubjectClaims()/untrustedRequestFields(), which keeps the released 0.3.x transports loadable while preferring the current core's trust-boundary accessor whenever it is present. The provider side needed no source changes — only the config surface the newer schema requires (readinessTimeoutMs,logging,audit.sink,oauth.revocation.*, and a DID-only composition declaringrevocation.{subject,accessToken} = "unsupported", which is a first-class value rather than a workaround).f12fb8f— refresh vulnerable transitive dependencies.Verification
Both commits landed on
developthrough their own reviewed PRs (#20 and its follow-up) with CI green.developis currently pinned asPROVIN_REVin the o3co/auth umbrella'smake test-provin, which builds these packages against candidate auth revisions.🤖 Generated with Claude Code