Spec: Complete the review-driven Effect API Query 0.1.0 programme

Problem Statement

Application developers already have typed RPC and buffered HTTP utility trees, but the pre-release review reproduced failures at the boundaries between Effect contracts, streamed query data, TanStack cache identity, and the published type contract. A live query can lose an undefined emission; an independent stream interruption can lose its Cause; broad payload Schemas can appear payloadless; custom QueryClient hashing can split one logical query into multiple entries; retained stream policies can share incompatible histories; and the declared Query Core lower bound mishandles a null live value.

Developers also need complete, verified guidance for hydration, retries, optimistic writes, identity changes, persistence, events, and SSR. HTTP event streams and response metadata need deliberately designed cached views. Maintainers need native pnpm quarantine settings shared by dependency installations, useful performance guardrails, accurate support claims, and shipped agent instructions that match the completed package.

The initial release includes the agreed correctness, HTTP-view, serialization, compatibility, and integration work. Performance work covers small repeatable baselines and measured improvements. Example work strengthens the current applications and capabilities.

Solution

Complete one coherent pre-release programme on an integration branch created from current main. Preserve the existing RPC and HTTP capabilities, resolve the five adapter defects and the declared-peer compatibility failure, add typed HTTP streaming and opt-in buffered response metadata, and prove rich hydration and application cache workflows at the existing public seams.

Keep the package a lifecycle-neutral Effect-contract-to-TanStack Query adapter. Applications retain clients, runtimes, Scopes, credentials, persistence, transport policy, and domain orchestration. Use ordinary public-factory runtime tests, compiler fixtures, and the existing Vite React and TanStack Start examples to demonstrate behavior. Finish the shipped skill with TanStack Intent and the requested writing workflows, reconcile human documentation, and complete repository acceptance before the existing publication issue proceeds.

Every dependency installation obeys the configured strict seven-day pnpm policy. There are no release-age exclusions, exceptions, temporary overrides, missing-timestamp allowances, or alternate-installation bypasses.

User Stories

1. As a live-query consumer, I want an undefined emission represented as cacheable null, so that every emitted value can become the latest query data.
2. As an accumulated-stream consumer, I want undefined elements preserved inside the history, so that live normalization does not change my emitted sequence.
3. As a TypeScript consumer, I want the live query-data type to describe the normalized runtime value, so that typed cache reads remain truthful.
4. As a consumer of the minimum supported Query Core version, I want null live values handled correctly, so that the advertised peer range is reliable.
5. As an Effect consumer, I want independent stream interruptions preserved in the RPC execution error, so that I can inspect their complete Cause.
6. As a query consumer, I want cancellation to close iterators and release resources promptly, so that Cause preservation does not weaken cleanup.
7. As an RPC consumer, I want Unknown, Any, and void-containing payload declarations classified consistently with the runtime, so that valid input-bearing calls remain available.
8. As a consumer of a genuinely payloadless RPC, I want concise inputless builders, so that the payload correction retains the existing convenience.
9. As a consumer with a custom key encoder, I want its input type preserved across every builder, so that cache identity can represent broad or serviceful payloads safely.
10. As a QueryClient owner, I want my global and prefix hashing defaults respected, so that generated fetches and native cache helpers reach the same entry.
11. As a live-query observer, I want the first emission visible in the observed query, so that an open stream can become successful before completion.
12. As a streamed-query consumer, I want different retention bounds and refetch modes to have consistent identities, so that an incompatible cached history cannot satisfy my view.
13. As an application developer, I want root, branch, leaf, and operation prefixes retained, so that broad invalidation survives concrete-key changes.
14. As a maintainer, I want the seven-day dependency policy enforced in workspace and CI installations, so that dependency updates follow the project policy.
15. As a maintainer, I want publication timestamps checked strictly, so that a missing timestamp cannot silently admit a dependency.
16. As a maintainer, I want eligible Effect updates assessed as one coordinated runtime/testing/platform set, so that the exact supported versions are validated together.
17. As an RPC application owner, I want a cancelled full-buffer stream tested alongside another active call, so that shared transport interference is covered.
18. As a developer of a long-running stream UI, I want bounded history and live-value guidance, so that cache retention matches the workload.
19. As a stream consumer, I want transport buffering, retained history, and publication rate explained separately, so that I configure the right control.
20. As a high-rate stream consumer, I want an explicitly measured publication-batching option or decision, so that throughput work preserves delivery semantics.
21. As a query consumer, I want cancellation and failure flushing behavior defined, so that delayed publications do not write into an abandoned query.
22. As an HTTP consumer, I want accumulated and live SSE views derived from my HttpApi contract, so that HTTP event streams receive the same typed Query integration as RPC streams.
23. As an HTTP stream consumer, I want typed decoding requirements, failures, empty-stream behavior, and cleanup, so that streamed endpoints preserve the ready-client contract.
24. As an HTTP consumer, I want mixed buffered/streamed successes and header-wrapped successes handled deliberately, so that generated types never misrepresent an endpoint.
25. As an HTTP consumer, I want an opt-in buffered view of decoded data, status, and headers, so that ETag-aware applications can use response metadata safely.
26. As a cache consumer, I want metadata and ordinary decoded-data views separated, so that their different query-data shapes cannot collide.
27. As a developer consuming byte streams, I want their supported representation or limitation stated explicitly, so that downloads are not accidentally accumulated as SSE events.
28. As an application developer, I want a plain DTO hydration recipe, so that field-only applications can choose a simple representation.
29. As an application developer, I want paired Schema-aware data serializers, so that classes and rich values retain their intended representation after hydration.
30. As a browser developer, I want a reconstructed class method and rich value to remain usable after refetch, so that server and browser execution agree.
31. As a pagination developer, I want infinite pages and page parameters included in the serialization contract, so that hydration preserves pagination state.
32. As a stream developer, I want accumulated arrays and live values included in serialization, so that the selected query view remains hydratable.
33. As an application owner, I want residual serialization services supplied by my runtime, so that codec execution does not erase required services.
34. As an SSR developer, I want failed queries omitted unless I choose a safe error serializer, so that preserved Causes are not unintentionally rendered into a page.
35. As an SSR developer, I want the first successful stream snapshot captured without waiting for completion, so that open streams do not block rendering.
36. As an SSR developer, I want timeout, early abort, failure, cached-data, and cleanup behavior defined for snapshots, so that every outcome settles and releases resources.
37. As an SSR developer, I want browser reconnection to use independently owned resources, so that server cancellation does not dispose browser execution.
38. As an SSR developer, I want a supported production server-local ready-client recipe where available, so that local execution can avoid unnecessary network round trips.
39. As an application owner, I want request-local identity and services preserved during local execution, so that one request cannot affect another owner's cache.
40. As an application developer, I want complete typed failure-aware retry examples, so that domain, authentication, transport, defect, interruption, and runner failures receive deliberate policies.
41. As an application developer, I want synchronous key errors separated from execution retries, so that invalid input is handled at the correct stage.
42. As an application developer, I want observer, server, and imperative retry defaults explained, so that retries behave as intended.
43. As an application owner, I want TanStack and transport retries coordinated, so that attempts do not multiply accidentally.
44. As a stream developer, I want runner creation and stream-lifetime instrumentation distinguished, so that retries and spans cover the intended work.
45. As an application developer, I want mutation responses to seed exact typed cache entries, so that successful writes appear immediately.
46. As a user, I want optimistic writes and infinite-page updates reconciled safely, so that failed or overlapping writes do not erase newer results.
47. As a user switching accounts or tenants, I want old queries, streams, mutations, and private state handled deliberately, so that old-owner data cannot reach the new owner.
48. As an application developer, I want late mutation callbacks bound to their original owner, so that pending work cannot update a replacement cache.
49. As an application owner, I want safe identity to reflect result-changing permission or session generations, so that cache partitioning matches access and data semantics.
50. As an application owner, I want persisted data scoped by identity and schema/version busters, so that incompatible data is rejected during restoration.
51. As an application developer, I want explicit domain events and Reactivity keys mapped to query prefixes, so that related RPC and HTTP reads refresh together.
52. As an application developer, I want scoped event consumers with cleanup, coalescing, reconnect, and resume policies, so that owners do not accumulate duplicate subscriptions.
53. As an application developer, I want useful defaults, filters, and bridge ergonomics evaluated against working recipes, so that helpers remove real repetition while retaining native Query behavior.
54. As a framework developer, I want guidance for using generated Core-shaped options with additional Query adapters, so that I understand their reactive integration requirements.
55. As a browser or worker developer, I want framework-neutral ownership and execution guidance, so that I can use ready clients in the host I own.
56. As an HTTP application developer, I want a verified OpenAPI interoperability boundary, so that compatible external clients can consume the declared contract.
57. As an application owner, I want ready-client WebSocket and worker transport guidance, so that transport acquisition and disposal remain explicit.
58. As an application owner, I want a measured transport-batching decision distinct from backend request batching, so that aggregation is introduced only at the layer that owns it.
59. As a maintainer, I want small repeatable source workloads and compiler/build measurements, so that meaningful performance changes can be assessed.
60. As a maintainer, I want optimization changes justified by a measured workload, so that performance work retains canonical identity, validation, and resource semantics.
61. As an example user, I want focused scenarios in the existing Vite and Start applications, so that I can copy verified cache, identity, cancellation, and hydration patterns.
62. As an example user, I want the current cancellable-command behavior retained, so that interruption does not imply undoing completed domain work.
63. As a coding agent, I want the shipped skill updated through TanStack Intent with tracked sources and clear guidance, so that instructions match the installed package.
64. As a documentation reader, I want complete tutorials, recipes, references, explanations, and compatibility claims, so that the finished library can be used without reconstructing the review.
65. As a release maintainer, I want the initial 0.1.0 candidate to pass ordinary repository checks and native build validation, so that publication begins from a reviewed implementation.
66. As a release maintainer, I want the existing publication issue to own npm account setup and release verification, so that the programme does not create competing publication workflows.
67. As a contributor, I want tickets with genuine blocking relationships on one integration branch, so that independent work can proceed concurrently and dependent work starts from completed contracts.
68. As an HTTP consumer, I want the immutable captured-input requirement explained clearly, so that later mutation cannot make execution disagree with its frozen key.
69. As a maintainer, I want changed skill sources detected and justified reviews recorded, so that derived agent guidance stays current.
70. As a maintainer, I want repository Node access to use suitable Effect platform services, so that resource lifetime and errors follow the same model as the examples.

Implementation Decisions

Scope, installation policy, and ownership

• This programme extends the existing delivery baseline recorded in GitHub issue Spec: Build effect-api-query 0.1.0 #1. Completed work stays closed and remains regression prior art. The new programme spec and its child tickets own the new scope; existing publication issue Publish and verify effect-api-query 0.1.0 #19 retains external publication ownership.
• Use one integration branch based on current main. Ticket branches/worktrees begin from the integration tip, merge that tip before completion, and integrate through reviewed merges. No implementation is committed directly to main by this workflow.
• Enforce the existing strict seven-day pnpm release-age policy for every registry dependency installation in the workspace, examples, CI, optional tools, and subsequent external release verification. Missing publication times fail closed. Preserve lifecycle-script permissions and frozen CI lockfiles. Existing version-resolution overrides may remain when they do not bypass release-age or build-script policy.
• Native workspace settings own release-age enforcement, including strict timestamp handling and disabling lockfile trust. Dedicated policy scripts, helpers, static checks, tasks, guidance, and a separate policy ticket are excluded.
• Amend the quarantine ADR to remove its exact-version exception allowance. Audit currently eligible compatible dependency changes; retain supported installed versions when no eligible change is justified. Effect updates remain coordinated across runtime/testing/platform packages and preserve the exact peer.
• Native build and pack tools own distribution creation and package validation. The existing release workflow retains artifact creation and publication handoff. Independent registry consumption requires native pnpm eligibility and remains with publication issue Publish and verify effect-api-query 0.1.0 #19.
• Dependencies used by two or more workspace packages use the central pnpm catalog and catalog: references. Single-use dependencies may retain package-local exact versions. Deliberately different minimum/current compatibility versions remain separate.
• Prepare the initial 0.1.0 version without changelog entries or Changesets during this unpublished programme.
• The package has never been released. Breaking API and implementation changes are allowed when they improve the design. Document the current first-release contract; omit migration guides and backward-compatibility work for unreleased builds.
• Add no meta comments, implementation notes, or implementation comments in source, configuration, tests, documentation, or tracker updates. Preserve essential compiler assertions and existing untouched comments. Keep README and site additions concise and useful for application tasks.
• Under repository docs/, add or amend concise architectural ADRs only, using writing-for-agents. Record the decision, rationale, and lasting consequences; keep API matrices, proof details, measurements, commands, and implementation/process notes out of ADRs. Final README and apps/docs updates remain included. Keep transient handoffs outside the repository.
• Preserve one root ESM package, named exports, ES2022, side-effect-free packaging, exact Effect peer, external Query Core peer, canonical key payloads, eager frozen utility trees, and application-owned ready clients/runners. Add framework dependencies only when an existing application or public contract genuinely requires them.
• Use suitable public Effect equivalents for direct Node access in retained repository tooling, tests, and examples. Preserve native primitives where no equivalent keeps the required behavior, such as module resolution, strict assertions, or raw protocol probes. Preserve synchronous compiler hooks and measured workload semantics; keep Vite+ tasks and native pnpm installation unchanged.
• Keep code contracts authoritative for behavior, tickets authoritative for slice acceptance/blockers, and repository configuration authoritative for task names and exact versions. Reference affected ADRs by decision identifier and record amendments before contradictory behavior lands.

Correctness and cache identity

• Live query data normalizes successful undefined emissions to null. The public data type applies the same normalization. Accumulated stream elements and mutation data retain their current values. Amend the query-data definition and the live/normalization decisions.
• Raise Query Core's minimum to the verified fixed version at or above 5.103.1, subject to the install policy. The public peer declaration and ordinary null/undefined regression tests describe the supported contract; no separately installed peer matrix is required.
• Only an actual payloadless declaration is inputless. Constructor-input assignability to void is not the classification rule. Broad Schemas and unions remain payload-bearing; canonical JSON restrictions and custom-encoder requirements continue to apply independently.
• Preserve complete failed-Exit Causes for stream-originated failures, including interruption-only failures when TanStack did not request cancellation. Preserve native TanStack cancellation/reversion and Effect iterator finalization.
• QueryClient owns hashing through its global and prefix defaults. Generated options own keys and execution functions, do not inject a competing hash, and do not accept a per-call explicit hash that would make native key-only helpers inconsistent. Canonical frozen key values remain unchanged by this ownership decision. Amend ADR 0004 and the published option contract.
• Concrete accumulated-stream identity includes normalized retention bound and refetch mode. Missing bounds mean unlimited retention; missing refetch mode means reset. Explicit defaults and omitted defaults produce equivalent keys. Extend exact key builders to accept the same policy as options while retaining DataTags and all broad prefixes.
• Captured inputs remain immutable caller-owned values. Explain this prominently; do not silently freeze or generically clone arbitrary decoded classes, binary values, or resource-bearing values. Query-stable RPC payload construction and deterministic infinite mappers remain required.

Streams and HTTP views

• Use Effect's ready-client stream support and existing shared Query construction. Keep transport parsing, queues, reconnection primitives, and resource ownership in Effect/the application. Add a private common consumption seam only when a concrete HTTP feature needs it; do not export adapter registration or a stream engine.
• Design and implement HTTP SSE accumulated and live views for unambiguously streaming successes. Use a focused prototype to settle header-wrapped stream representation and supported success alternatives before implementation. Runtime and compile-time projection agree. Mixed buffered/streamed success declarations retain omission until an explicit discriminated contract is proven and recorded; their presence never yields falsely buffered types. Header-wrapped support requires an explicit decoded-header/chunk representation; a Stream or platform response never becomes cache data.
• SSE decoder controls are separate from decoded HTTP request input and custom key-encoder input. The design slice identifies controls that change emitted data and includes their normalized view semantics in cache identity; transport-only controls remain application-owned where they do not change that representation.
• HTTP stream operations infer chunk data, declared/client/decoding failures, and residual services. Their adapter errors retain HTTP declaration metadata and complete Causes. They forward abort, finalize iterators, preserve empty-live behavior, and use distinct operation/view identities with the same retention rules as RPC.
• Add an opt-in buffered metadata view containing decoded data and immutable plain status/header metadata. It has separate query identity and preserves existing declared decoded header wrappers. Platform Response/HttpClientResponse objects and open bodies do not become cached query data.
• Raw byte streaming is evaluated separately from event streaming. A supported cached representation requires an explicit lifetime, retention policy, and useful data contract; an evidence-backed limitation is an acceptable design outcome and is reflected in the capability reference.
• Establish small realistic stream measurements before adding publication controls. Preserve immediate first-emission success for open live/accumulated streams except the documented replace-refetch semantics. If batching demonstrates benefit, expose explicit count/time publication policy, preserve accumulated emission order, flush successful completion, and define pre-failure publication by refetch mode. Abort discards unpublished work and clears timers rather than writing after cancellation; native cancellation/reversion remains authoritative. Replace refetch publishes only a successful completed replacement.
• Every publication policy that changes the cached view has a consistent identity/ownership contract. Rate limiting and intentional loss remain explicit application Stream transformations. Preserve the unlimited-retention default and immutable published arrays.

Hydration and SSR

• Provide both plain DTO and paired encode/decode recipes. A decoded domain value has the same intended representation after dehydration, hydration, and subsequent browser refetch. Structural cloning alone is described accurately and is not treated as class reconstruction.
• Cover unary values, normalized null, accumulated arrays, live latest values, infinite pages, and multiple HTTP success Schemas. Preserve undefined elements in accumulated arrays through hydration; only live undefined values normalize to null. Infinite page parameters have an explicit caller policy/codec because result Schemas do not define their representation.
• Residual encoding/decoding services remain caller-owned. TanStack synchronous serialization callbacks are used only for genuinely synchronous codecs; serviceful/effectful work uses an explicit application-owned preparation/runner stage. A focused design proof must demonstrate that async encoding completes before publishing the dehydrated snapshot and async decoding completes before hydration in the existing Start integration. Effects and Promises never become query data. Do not hide asynchronous work in a synchronous callback or encode ordinary query results merely to make transport easier.
• Failed queries remain omitted by default. Error/Cause hydration requires an explicit application-safe serializer; complete Causes remain untouched in execution errors.
• Consolidate the existing first-snapshot pattern with a framework-neutral contract for cached data, fresh fetches, timeout, abort before the first emission, terminal failure, exact-query cancellation, and listener/iterator cleanup. Support browser reconnection through independently owned ready clients. A public helper is adopted only when the recipes demonstrate reusable behavior beyond trivial native forwarding.
• Establish production server-local execution through supported ready-client APIs where the pinned version permits it. Prove request identity/services/isolation and absence of network calls. Test-only constructors are not production APIs. If the exact upstream public surface cannot supply the requested seam safely, record the evidence and expose an accurate ready-client recipe/limitation rather than introducing package-owned client construction or bypassing a ready client's contract.

Application cache workflows and compatibility

• Complete native retry/retry-delay recipes with tagged failure inspection, domain/authentication/transport distinctions, defects, interruptions, runner rejections, synchronous preparation errors, and observer/server/imperative defaults. Coordinate TanStack attempt policy with Effect/transport schedules. A Cause helper needs useful typed behavior beyond existing Effect functions.
• Use generated concrete keys and captured QueryClient owners for mutation-response seeding, optimistic writes, snapshots, rollback, settlement, and infinite-page reconciliation. Demonstrate overlapping writes without older callbacks/refetches overwriting newer results.
• Use the existing applications for demonstrative owner/tenant switches, without adding an authentication system. Include permission/session-generation identity when it changes returned data; use safe identities rather than bearer credentials. Cancel old queries/streams, handle pending mutations explicitly, clear private cache/persisted state, and isolate late callbacks.
• Persistence remains an application integration with identity-scoped storage and a schema/version buster. Demonstrate rejection of incompatible restored data in the existing application and ordinary tests; add no core persistence/session manager.
• Domain-event and Effect Reactivity recipes map explicit safe domain keys to exact/prefix invalidation. Consumers register/unregister in an application-owned Scope, have one subscriber per owner, coalesce explicitly, and define event identity, duplication, reconnect/resume, durable cursor, and schema responsibilities. Explain that in-memory Reactivity alone is not cross-process delivery. Use live full snapshots or bounded histories and explain replace-refetch visibility.
• Prefer native QueryClient/prefix defaults and explicit filters. Evaluate narrow typed defaults, partial filters, and a supplied-stream invalidation bridge against completed recipes. Export only helpers with demonstrated reusable value, truthful custom-encoder semantics, ordinary type/runtime evidence, and necessary ADR amendments. A completed documented decision against a redundant helper satisfies the investigation.
• Provide Vue, Solid, Svelte, and Angular guidance for generated Core-shaped options and adapter-specific reactive wrapping. Add framework exports only if a real incompatibility is demonstrated. Provide framework-neutral browser/worker ownership recipes. Dedicated installed-framework consumers, certification matrices, and packed Window/Worker hosts are excluded.
• Explain OpenAPI interoperability through method/path, request layout, declared errors, multipart, and SSE contracts while preserving native Effect factory boundaries. Retain useful ordinary protocol evidence and recipes; a generated external-client installation fixture is not an acceptance gate.
• Provide ready-client WebSocket/worker transport recipes with observable acquisition, execution, interruption/finalization, and disposal. Assess transport batching with a small request-overhead measurement and an explicit decision distinct from backend RequestResolver batching and Query cache publication batching; retain transport ownership in Effect/the application.

Baselines, existing examples, skill, and documentation

• Record small repeatable key/options and stream workloads with advisory compiler/build measurements using fixed repository fixtures and the existing toolchain. Include both adapters and distinguish adapter cost from peer-inclusive output where useful. Introduce optimization only for a measured relevant workload, preserving validation, immutable keys, weak/bounded retention, and resource semantics. Broader editor-latency investigation remains deferred.
• Broad JIT/AOT, compiler rewrites, speculative memoization, additional documentation tools, and new browser-platform packages are deferred. Existing baselines are improved without building a general benchmarking framework or adding arbitrary timing thresholds.
• The example block strengthens current Vite/Start user, pagination, mutation, failure, stream, hydration, cancellation, and cancellable-command scenarios. The standalone Node server uses Effect Node platform APIs for hosting and runtime. Focused ordinary regression cases cover behavior without new showcase applications, domain systems, providers, telemetry infrastructure, or example dependencies. Explain runner creation versus stream consumption with existing Context/runner fixtures.
• Individual feature slices include the minimum contract documentation needed to keep their behavior understandable. After feature/example contracts settle, update the shipped skill using installed TanStack Intent plus skill-creator, writing-for-agents, and writing-clearly-and-concisely. Use Intent’s library-maintainer workflow and shared planning records: register authoritative sources, synchronize metadata, validate the skill, review source changes, record justified owned outcomes, and run the native maintainer check. Preserve unrelated maintenance work. Keep the same authoritative skill independently installable through the Skills CLI and document its separate update/version behavior.
• Reconcile final human tutorials, how-to guides, references, explanations, capability matrix, glossary, and ADRs. Then resynchronize tracked skill sources and validate owned guidance, reference resolution, compiled snippets, and documentation consistency through native Intent and existing repository tasks. Correct Effect/oRPC positioning and state support limits precisely.

Release acceptance and handoff

• Prepare a real initial 0.1.0 candidate under the accepted pre-1.0 policy without changelog entries or Changesets. The current compatibility reference identifies the supported Effect and Query Core versions, normalized query data, and cache identity.
• Validate the initial versioned candidate through repository quality, strict Effect diagnostics, runtime tests, API compiler fixtures, native build/package linting, existing application builds, documentation, shipped guidance, and Chromium/Firefox/WebKit application/site checks. Native release actions retain artifact creation and publication routing; custom archive checks and build-byte comparisons are excluded.
• The new final integration-acceptance ticket transitively gates every new programme slice and becomes a native blocker of existing publication issue Publish and verify effect-api-query 0.1.0 #19. Do not create a competing publication ticket or rewrite/close historical parent issues.
• External npm name ownership, trusted publisher, bootstrap credential removal, main-only CI publication, registry/provenance, deployed documentation, and independent registry consumption remain issue Publish and verify effect-api-query 0.1.0 #19. Registry-consumer installation obeys the native pnpm policy, including the published package. This programme prepares and accepts the implementation without performing publication.

Testing Decisions

• Primary seams: ordinary public-factory runtime tests with real QueryClient behavior and official ready-client support, plus strict compile-time fixtures for the public declaration contract. Keep shared/private adapter modules private. Extend existing test seams without creating temporary library installation projects or another general testing harness.
• Use runtime tests only for behavior that can fail at runtime: emitted/cache values, hashing entry counts, native reads/writes, policy identity, Cause preservation, cancellation/finalization, serialization, ownership races, invalidation, and observable transport behavior.
• Use ordinary compile-time fixtures for payload classification, input/key/encoder signatures, DataTags, normalized live data, HTTP views/errors/services, native options, select/initialData, skipToken, and pagination. Check them explicitly with the repository compiler and the already supported TypeScript 5.9 compiler against the workspace dependency set. Avoid runtime assertions of guarantees enforced by types.
• Correctness cases include null and undefined-only/value-then-undefined streams, accumulated undefined elements, interruption-only/mixed Causes, custom global/prefix hashes, one cache entry and first-value visibility, normalized equivalent stream policies, wide/narrow histories, and genuine/broad payload declarations.
• Use official in-process ready clients for most execution tests. Prove server-local absence of network calls through public request instrumentation. Reserve real protocol/transport tests for socket behavior, abort delivery, and shared receive-loop interference.
• Extend existing Start rendering/hydration/navigation/request-isolation tests and existing Vite/Start browser scenarios for user-visible workflows. Assert domain representation, request counts, callbacks, cache ownership, and cleanup; avoid arbitrary sleeps or private implementation assertions.
• Serialization verifies a class method and a rich scalar/binary value across hydration and refetch, all documented query shapes, explicit page-parameter policy, residual services, and default failed-query omission. Snapshot tests cover success, fresh/cached policy, timeout, early abort, failure, and cleanup.
• Meaningful test prior art is the current public-factory, real QueryClient, official Effect test-client, API compiler, request-isolation, SSR hydration, application/browser, native skill, and docs-example suites. Focused additions reuse those seams and avoid duplicating application tests.
• Dependency installation uses native strict pnpm workspace configuration. Release-age enforcement is pnpm’s responsibility; add no bespoke policy checker or static guard. Validate the supported installed set or an audited compatible eligible update.
• Verify Effect platform conversions through retained tooling commands, ordinary runtime transports, compiler fixtures, and application/site checks. Preserve command output and exit failures, module resolution, synchronous compiler hooks, scoped cleanup, benchmark workloads, and monotonic timing. Add runtime cases only for uncovered observable behavior.
• Source workloads record fixed fixture/toolchain context and useful sizes or compiler counts. Timing remains advisory without a controlled runner. Broad benchmark expansion requires a measured unresolved concern; no installed measurement runner or compatibility matrix is required.
• Final acceptance requires complete ordinary checks, native build validation, maintained shipped instructions, the application/site browser matrix, and the existing release workflow handoff. Temporary library-consumer installations, dedicated packed hosts, archive inventories/digests, and repeated build equality are excluded. Post-publication deployed-documentation verification remains with the existing human-owned publication issue.

Out of Scope

• Broad compiler optimization research, Schema JIT/AOT activation, speculative memoization, type-system rewrites, and a general benchmark infrastructure project.
• New showcase applications, AI providers, SQL/database systems, durable workflow/cluster engines, Atom comparison demos, or telemetry infrastructure/dependencies in the existing-example block.
• Any dependency-age exemption, temporary override, missing-time allowance, alternate installer bypass, or workaround that weakens the configured seven-day policy.
• Package-owned clients, runtimes, Scopes, authentication/session management, persistence orchestration, automatic mutation-to-read inference, or a second authoritative cache.
• Universal retryability classifiers, automatic error/Cause sanitization or hydration, generic cloning/freezing of caller inputs, nondeterministic query mappers, or bypassing ready-client payload construction.
• A new server/middleware/plugin framework, generic Standard Schema replacement of native factories, automatic transport batching in the utility tree, or server-side rollback guarantees from query abort.
• CommonJS, widened Effect peers, separate published adapters/core, public internal registration, subpath exports without demonstrated need, new hooks/providers, or direct call builders duplicating ready clients.
• Rewriting completed issue history, renaming the package/repository again, a new publication ticket, publishing a placeholder version, publishing from a developer machine/integration branch, or automatic main merge during specification work.
• Custom package/archive inventories, digest or byte-equivalence gates, temporary installed library consumers, peer/compiler/framework installation matrices, and dedicated packed browser/worker hosts.

Further Notes

• Source: the complete portable review dated October 9, 2026, audited at commit 64cf8ad, plus the subsequent conversation decisions. The consolidated corrections govern older appendix claims: captured HTTP input mutation is a caller constraint, the lower-bound live-null failure is reproduced, and inexpensive canonical hashing does not settle hash ownership.
• Existing baseline spec: Spec: Build effect-api-query 0.1.0 #1. Existing publication owner: Publish and verify effect-api-query 0.1.0 #19. This programme deliberately expands earlier HTTP-stream/framework deferrals and supersedes the historical release-age exception permission for all current work.
• Current baseline is stable Effect 4, with unstable transport APIs and an exact peer. Prepare the initial package version as 0.1.0. Resolve eligible versions from the real repository/registry metadata at execution time.
• Design slices are required only where exact upstream support or a new view contract must be proven. Each returns a bounded decision artifact and executable evidence that directly informs its dependent implementation slices. When supported public APIs cannot provide a requested behavior, record the evidence and document the limitation. Keep internal upstream APIs outside the supported contract.
• Each ticket is a narrow complete behavioral slice with genuine native blocking relationships, clear completion criteria, and public-seam evidence. Publication of the spec/ticket graph follows the user review required by to-spec and to-tickets; implementation follows through implement-spec.
• The agreed testing seams are ordinary public-factory runtime tests and API compiler fixtures, with existing protocol/application/browser seams for behavior they alone can prove. No public test-only seam is proposed.