Certify Fastly memory and separate-stack fit #73

Acceptance Criteria

• Establish the actual compiled application's stack requirement across initialization, admitted depth, errors and cancellation and compare it with the published separate-stack allowance.
• Prove primary memory fit with policy headroom and target-applicable observations at the original workload. Missing stack/host facts remain nonpassing.

Blocking And Review Gates

• Blocked by: #46, #47, #48, #50.
• External blockers: Remaining Fastly SDK/decoder, ingress, allocator and handoff contracts, as enumerated by #50. The published separate-stack allowance is already known; application-required stack proof remains part of this issue.

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: M7-R0 design/plan, ISSUES.md resource rows and schema qualification record.

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.

Discovered Catalog Acceptance

• Bind the actual Fastly artifact, ABI, SDK/features/configuration and separate-stack/memory facts to every discovered implemented identity/alias. Reconcile complete-catalog reports and exact positive execution coverage independently.
• Execute the complete implemented set across bounded batches, preserving privacy, invalid-parameter refusal, original deadlines, cancellation and overload boundaries. The linked Trusted Server Fastly artifact in Link the bridge into an actual Trusted Server artifact #76 additionally needs combined ownership accounting; standalone fit is not that evidence.

Source Contracts

• Approved roadmap
• Product vision
• Issue ledger and qualification limitations
• Schema qualification record

Resource Proof Responsibilities

Responsible roles: Fastly SDK/provider maintainers supply remaining ingress, allocator, codec and handoff contracts; SDK maintainers supply recorder/config-key, backend identity-cache and task/queue/teardown storage contracts; Auctioneer Fastly qualification maintainers prove the application's actual primary-memory and stack requirements.

Known SDK components at a7d7fd0f2face027e3810ed67e80f6341fcf68b6: 128,000,000 primary bytes, a separate 1,000,000-byte stack allowance, and one inbound request per execution. These published facts are unchanged from the earlier 598f0a2a baseline; the adapter's src/lib.rs is byte-identical between those revisions. The published stack allowance is not a missing external fact and is not proof that the application fits it.

Next verification action: prove the linked application's stack across initialization, admitted depth, errors and cancellation; bind the actual memory, recorder/configuration-key set and backend-cache populations and release points, including observation handles surviving callback exit. Reconcile these with the existing C/I/V, auxiliary and codec components without changing workload limits or claiming provider-added framing is covered by application header caps.

Source: approved shared resource ownership contract, delivered for review in #162. This records responsibility and the next verification action, not completed proof, target qualification, changed workload limits or permission to close this issue.

Current SDK Wake And Registration Ownership

PR #162 pins EdgeZero a7d7fd0f2face027e3810ed67e80f6341fcf68b6. Its Fastly batch scheduler captures an Arc<AtomicBool> wake-request flag; progress observation also owns a wake flag and creates Arc-backed SourceWake wrappers retaining a cloned parent waker. Sources may retain registrations beyond the immediate polling call, so one current waker per batch is not a proven simultaneous-storage bound.

Responsible external role: Fastly SDK maintainers provide the actual flag, wrapper, cloned-parent and retained-registration allocation/population/lifetime contract. Responsible application role: Auctioneer Fastly qualification maintainers map that contract to existing funded owners; #50 coordinates the cross-issue record.

Next verification action: enumerate scheduler and progress flags separately, count source-waker creations and overlapping registrations across repeated observations, replacement, completed-but-retained bodies, cancellation, callback exit and final scope/driver teardown. Bind the actual guest layout and allocator/host storage, distinguish shared Arc backing from cloned handles, and reconcile each simultaneous owner against the unchanged budget. These are unproved SDK-bookkeeping obligations, not new payload charges or completed certificates.

The published platform metadata is current at that pin. No limit, ceiling, equation, project field, dependency or target-readiness claim changes here.