[bokelley]

T5 for #3504 (approved DX plan, section 2.1 and section 6.1 T5): the managed seller path. It stacks on #3551 (per-offering exclusions) → #3546 → #3545 → #3544 → #3543 → #3542 → #3534 and the rest of the #3504 stack. Review only feat(reporting): managed reporting-subscription block on the Reliable Reporting service. It targets main because CI runs only for PRs into main.

What a seller writes now

const lifecycle = createPrincipalLifecycle({ store, notifications, agentUrl, resolvePrincipal /* no reportingSubscriptions */ });
const service = createReliableReportingService({
  /* existing producer config */
  subscriptions: { principals: lifecycle, stateStore, maxAccounts: 500, configure },
});
const server = createAdcpServerFromPlatform(service.install(platform), { protocol: lifecycle.protocol });

What the service now owns

Duty (before: host)	Now
createPrincipalLifecycle({ reportingSubscriptions })	The service installs the section on the runtime (installReportingSubscriptions, internal)
Pass lifecycle.capabilities into capabilities.principal	install() fills it in when absent; capabilities reflects a section installed later
createReportingSubscriptionEngineV1 with 4 hooks	Built from principals, stateStore and the service's offerings and statusRetentionDays
listAuthorizedAccounts	Derived from the platform's accounts.list, read under the principal's identity. That identity is a non-secret snapshot of its last authenticated request (token, credentials and extra dropped), never a token. Override: accounts
listAccountBuys	Derived from sales.getMediaBuys (all statuses, paged). Overrides: buys, buyOfferings
resolveRevocationInstant	The observation time
listSubscriptionPrincipals	From the engine store's principal index across tenants. Tenants are recorded as principals are seen; override: tenants
resolvePrincipal (twice)	The principal runtime's own resolver. Override: resolvePrincipal
Wrap syncPrincipal to reconcile	Built-in trigger after a write that submits reporting_subscriptions (reconcileOnWrite, on by default). It never fails the write
Call engine.reconcile each period	runCycle sweeps every subscribed principal before planning
AggregateError from runCycle	Failures are returned in subscriptionPlanningFailures and passed to planningErrorHandler

Option names follow the Python SDK's SubscriptionOptions: maxAccounts, backfillOnRegrant, dimensions, accounts, buys, buyOfferings, configure, accountDeliveryConfigs, endAccountConfigs, isPeriodDelivered, resolvePrincipal, reconcileOnWrite, accountConfiguration, planningErrorHandler, bindManagedGeneration. A roster that can't be read is a PlatformConfigError coded SUBSCRIPTION_ROSTER_UNAVAILABLE. The advanced block with your own engine still works as before. @adcp/reporting-storage's production service accepts the managed block, and service.subscriptionWiring exposes the resolved wiring to it.

Deviations from the plan and from Python

• configure is required. Python reuses its producer resolver (account_context). The TypeScript resolver has no source settings to reuse, so there is nothing to derive from.
• principals is required. Python can also build the runtime from a principal store. The server-level principal: and storage options (section 2.1) arrive with T8's storage facade.
• isPeriodDelivered defaults to false, so withheld_period_count counts every withheld period. Reading it from the ledger is a follow-up.
• The sweep reconciles every subscribed principal each cycle. Python reconciles only when a boundary has passed; TS has no boundaryDue yet. Reconcile is idempotent, but each one reads the platform.
• The reference seller still uses the advanced composition. Rewriting it on the managed path is T13.
• Platform account timezones. The framework's rich Account has no timezone field, so the derived roster reads timezone when the platform's accounts.list items carry it. Without it, account_timezone offerings fail with COVERAGE_INPUT_INCOMPLETE.

Tests

test/lib/reporting-subscription-managed.test.js runs a real createAdcpServerFromPlatform dispatch:

• The section and both capabilities are installed.
• A sync_principal write reconciles from the derived roster and buys.
• runCycle plans and commits the subscription revision, and get_reporting_status shows subscription_coverage.
• A missing roster is recorded as SUBSCRIPTION_ROSTER_UNAVAILABLE both at the write and in the cycle, never thrown.
• Configuration mistakes are refused at construction.

File budget +4 (one dual-format module), with a comment.

Checks

npm run typecheck, lint:boundaries, check:package-size, Prettier, and 1,285 tests across reporting, principal, server-decisioning and packages/reporting-storage (PostgreSQL suites run in CI).

Refs #3504

🤖 Generated with Claude Code

[aao-secretariat]

Ladon verdict: Approve

Approve — managed subscriptions block reviewed, 2 medium findings, no blocking issues.

Checked: Scoped to the managed block (8997e1d..18a1c0e per author note; harness diff empty due to 36k-line API 406). managed.ts, service/index.ts, principal/runtime.ts, types.ts and reporting-storage wiring read clean on correctness: additive changes, minor changeset for both packages (appropriate per DR-0033), 248-line dispatch test present, roster-unavailable surfaced not thrown, capabilities getter and installReportingSubscriptions idempotent. No witness-not-translator, transport-client, or changeset-impact concerns.

Medium findings (non-blocking):

• src/lib/reporting/service/managed.ts:360 — Cycle cancellation not propagated into derived roster/buys reads (bounded by 30s withTimeout)
• src/lib/reporting/service/managed.ts:394 — authInfo snapshot stripped by denylist (fail-open) before durable persistence

Two medium findings, no critical/high, no escalation trigger (high_risk false, gated_paths false, no team gate). Below the 3-medium threshold for comment — falls through to approve (row 9).

Medium findings

• src/lib/reporting/service/managed.ts:360 — Cycle cancellation not propagated into derived roster/buys reads
• src/lib/reporting/service/managed.ts:394 — authInfo snapshot stripped by denylist before durable persistence

[aao-secretariat]

Ladon verdict: Approve

Approve — subsequent review, both prior Medium findings resolved.

This push responds to the prior approve run's two Medium findings on src/lib/reporting/service/managed.ts, and both are now addressed:

• Auth snapshot (was managed.ts:394) — moved from a denylist to an allowlist (SNAPSHOT_AUTH_FIELDS = {clientId, scopes, resource, expiresAt}). Identity-only, fail-closed: adopter-added secret keys can no longer leak into durable persistence. Correct shape.
• Cycle cancellation (was managed.ts:360) — an AbortSignal now threads through platformAccounts (single-page, throwIfAborted at entry) and platformBuys (checked at entry and inside the MAX_PAGES pagination loop), with options.accounts/options.buys fallbacks passing it through. Derived roster/buys reads now stop on cancellation.

Both fixes are backed by new tests (pre-aborted reconcile stops before derived reads; snapshot holds no token/apiKey). Changesets present. Reviewer surfaced no new findings.

No blocking findings, no medium findings in this run, high_risk false, gated_paths false, no author-team gate. Rows 1–8 do not fire → row 9 approve. Net improvement over prior pass.

The merge-base changed after approval.