Skip to content

Review the pinned Trusted Server local-provider contract #34

Closed

Description

@aram356

Acceptance Criteria

  • Pin the actual host revision/interface, deployment target and required bidder set; decide ownership, config/consent/UID sources, results, errors, cancellation and resources. Do not assume a native Trusted Server runtime exists or treat native-only bidder definitions as guest-routable.
  • Coordinate existing Trusted Server #1336 and Trusted Server #1484 where applicable; determine actual selected-target dependencies instead of duplicating their work or assuming both block every embedding path.

Blocking And Review Gates

  • No direct internal issue prerequisite identified; this does not mean Ready or approved for implementation.

Use native blocked-by/blocking links for unconditional issue relationships. Conditional target gates are not universal blockers; link only the selected applicable path after its contract is frozen.

Shared Acceptance Requirements

Every implementation issue ships its own unit/conformance, failure, resource and privacy tests. A later integration issue does not postpone those checks. New untrusted decoders include generated hostile-input controls; changed hot paths include repeatable measurements. Use the existing engine, host services, validated config/push path and EdgeZero handler registration. Preserve privacy, authorization, cookie integrity, HTTPS/SSRF protections, deadlines, exact sent coverage, authoritative bidder/alias attribution and bounded work/storage. Standalone and embedded behavior share policy rather than fork implementations.

No issue may claim a missing capability from metadata import, compilation, observed allocations, a signed cookie, or a different artifact's old evidence. New public/configuration behavior requires its reviewed design before execution. No workload reduction, raised ceiling or replacement budget equation is implied. Bodies and evidence must not publish credentials, identifiers, raw consent, private provider addresses or customer configuration.

Technical Ownership

Sources: roadmap section 7, vision and the existing shared engine/host interfaces.

Approved Integration Contract

PR #152 merged the specification and delivery plan at 9b83deaa680ad8e867169db3b4ebb195b8a1b33c. Their shared requirements apply: whole-catalog reports with verified skipped: not_implemented rows, positive qualification of every implemented identity/alias on all four adapters, existing build discovery and the qualified common native_only retirement. The first Trusted Server host remains Fastly display; Trusted Server #1505 coordinates host-owned work. The planning merge is not implementation or qualification evidence and changes no workload limit, resource ceiling or configuration mechanism.

Contract Closeout

The approved documents cover both existing acceptance criteria: immutable host/engine/SDK revisions, the Fastly host target, discovery-based whole-catalog reporting and four-adapter qualification, ownership, one runtime policy, consent/UID sources, typed selection/targeting, errors, original deadlines, cancellation and combined resources. Trusted Server #1336 is related protocol modularity, not a prerequisite for the entire Fastly path; #1484 concerns Cloudflare/Spin host collection and does not block the selected Fastly host. Existing Trusted Server #1505 is the coordination owner.

#51 owns shared preparation/services/results; #46/#47 own common discovery/schema qualification; #72-#75 own adapter fit; #88-#90 own actual guest schema/registry serving; #76 owns the linked Fastly host. Downstream delivery remains open. This contract issue is closed only after its reconciliation is accepted, not merely because the planning PR merged.

Source Contracts

Activity

  1. added theissue type on Nov 3, 2026
  2. added this to the 202611 milestone on Nov 3, 2026
  3. self-assigned this
    on Nov 3, 2026
  4. aram356 commented on Nov 6, 2026

    @aram356
    CollaboratorAuthor

    The spec and plan are merged into main through PR #152, commit 9b83deaa680ad8e867169db3b4ebb195b8a1b33c.

    The accepted direction is whole-catalog reporting, explicit unimplemented skips, qualification of implemented bidders/aliases across all four Auctioneer adapters, and a Fastly-first Trusted Server display integration. Existing build discovery is reused; flag/schema-selection retirement and actual integration remain implementation work.

    The reviewer accepted/resolved the finding, all 25 checks passed on the reviewed head, and the maintainer explicitly authorized the documented formal-approval exception. The merged tree is identical to that reviewed/tested head. This issue stays open; delivery continues through separately reviewed implementation PRs using this plan commit. No bidder qualification, runtime flag removal or production integration is claimed by this planning merge.

  5. aram356 commented on Nov 6, 2026

    @aram356
    CollaboratorAuthor

    Contract closeout accepted and merged through PR #153 into main at 87e329fe88f3a1c15a4d298d026607971b3065ee.

    Both #34 acceptance criteria are delivered by the approved source-pinned contract and reconciled ownership/dependencies. The reviewer accepted/resolved the only finding, all 25 current-head checks passed, and the maintainer explicitly authorized a separate head-specific exception to formal independent approval in the merge authorization record. No CI check or finding was waived, and no self-approval or administrative bypass was used.

    The merged tree is byte-identical to reviewed/tested head 0a74f05c76ba1d3f3d89a869929f5f05faf9490b; the merge commit is present on the default branch. This issue closed automatically on integration.

    This completes the contract/decomposition only. #51, common schema qualification, per-adapter fit/serving, #76's linked Fastly host and Trusted Server #1505 remain separate delivery work. No downstream implementation, resource qualification or production integration is claimed by this closeout.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions