{"owner":"ReactiveX","repo":"rxjs","hasSkills":true,"totalSkillsCount":27,"totalTokensCount":41681,"categories":["anthropic-skill","root-instruction","plugin-manifest"],"hasMcp":false,"mcpConfig":null,"found":[".agents/skills/rxjs-next-migration/.rxjs-migrate-skill.json",".agents/skills/rxjs-next-migration/SKILL.md",".agents/skills/rxjs-next-migration/assets/migration-report.md",".agents/skills/rxjs-next-migration/references/assessment-and-contract.md",".agents/skills/rxjs-next-migration/references/engine-and-batches.md",".agents/skills/rxjs-next-migration/references/review-checklist.md",".agents/skills/rxjs-next-migration/references/test-migration.md",".agents/skills/rxjs-next-migration/references/verification-and-closeout.md","AGENTS.md","apps/rxjs.dev/tools/README.md","apps/rxjs.dev/tools/transforms/README.md","apps/rxjs.dev/tools/transforms/rxjs-decision-tree-generator/README.md","apps/rxjs.dev/tools/transforms/templates/README.md","packages/migrate/README.md","packages/migrate/docs/MIGRATION_QUALIFICATION.md","packages/migrate/docs/MIGRATION_TOOLING_DESIGN.md","packages/migrate/skill/SKILL.md","packages/observable-polyfill/README.md","packages/observable-polyfill/test/wpt/README.md","packages/rxjs/README.md","packages/rxjs/docs/API.md","packages/rxjs/docs/MIGRATION_EVIDENCE_LEDGER.md","packages/rxjs/docs/PRERELEASE_APPROVAL.md","packages/rxjs/docs/RELEASE_GATES.md","packages/rxjs/docs/SECURITY_ASSURANCE.md","packages/rxjs/docs/UNSUPPORTED_RXJS_7_SURFACES.md","packages/test/README.md"],"skills":{".agents/skills/rxjs-next-migration/.rxjs-migrate-skill.json":"{\n \"schemaVersion\": 1,\n \"packageName\": \"@rxjs/migrate\",\n \"packageVersion\": \"9.0.0-beta.0\",\n \"digestAlgorithm\": \"sha256\",\n \"digest\": \"2b5c6b52bc8060df40c48443cfb5ebb0d55da5687bb74806daf95ac4912594fa\",\n \"files\": [\n \"SKILL.md\",\n \"assets/migration-report.md\",\n \"references/assessment-and-contract.md\",\n \"references/engine-and-batches.md\",\n \"references/review-checklist.md\",\n \"references/test-migration.md\",\n \"references/verification-and-closeout.md\"\n ],\n \"installSchemaVersion\": 1,\n \"adapter\": \"agents\",\n \"compatibleHarnesses\": [\n \"codex\",\n \"cursor\"\n ],\n \"targetPath\": \".agents/skills/rxjs-next-migration\"\n}\n",".agents/skills/rxjs-next-migration/SKILL.md":"---\nname: rxjs-next-migration\ndescription: Migrate an RxJS 7 application, library, or test suite to RxJS Next through an agent-led workflow that establishes a green behavioral baseline, makes Observable lifecycle choices explicit, uses @rxjs/migrate only for bounded fixture-proved rewrites, repairs without weakening evidence, and records a versioned migration contract. Use for repository assessment, migration planning or execution, lifecycle review, TestScheduler conversion, or migration closeout.\n---\n\n# RxJS 7 to RxJS Next migration\n\nTreat this as reviewed project work, not a codemod run. The objective is an\nintentional RxJS Next contract backed by the project's own build and behavior\nevidence. A transformed file, a clean diff, or one passing test is not proof\nthat the migration is complete.\n\nWork through all eight stages in order. Re-enter an earlier stage whenever new\nevidence changes scope, coverage, or lifecycle intent. Keep the developer\ninvolved at every explicit pause.\n\n## Non-negotiable rules\n\n- Read and obey repository-local instructions before acting. Protect existing\n work and stay within the authorized repository and paths.\n- Establish the RxJS 7 baseline before changing dependencies or source.\n- Never infer platform sharing versus producer-per-direct-subscription behavior\n from syntax, filenames, operator names, or a currently passing output.\n- Use the installed engine's versioned registry and schemas as authority. Do\n not reconstruct capability mappings from this Skill or from memory.\n- Run the deterministic engine without writes first. A refusal is a successful\n safety outcome, not permission to improvise a mechanical rewrite.\n- Preserve the project's test framework by default. Select a framework adapter\n only when the developer asked for that separate conversion.\n- Do not weaken, skip, delete, or replace a behavioral expectation merely to\n make the migrated suite green.\n- Do not add RxJS 7 compatibility shims, string-named platform methods, local\n substitute operators, or runtime generators unless the developer separately\n authorizes that product work.\n- Keep changes in small coherent batches. Review and verify each batch before\n widening the scope.\n- Do not call a migration complete while a required command is unknown,\n unapproved, skipped, or red without an explicitly accepted blocker.\n\n## Working record\n\nCreate or locate a checked-in migration contract manifest and a concise\nhuman-readable report. Use the schema exported by the installed\n`@rxjs/migrate`; schema validity and migration readiness are separate checks.\nUse [assets/migration-report.md](assets/migration-report.md) for the report.\n\nFor every migration unit, preserve source locations and record:\n\n- its current RxJS 7 behavioral claim;\n- the target lifecycle selected by the developer;\n- its evidence classification and supporting tests;\n- approval state, diagnostics, and any intentional divergence; and\n- verification or a named blocker.\n\n## Stage 1: Establish authority and scope\n\n1. Locate repository instructions, package and workspace metadata, lockfiles,\n CI configuration, RxJS versions, build/test commands, and current working\n tree state.\n2. Identify the repository root, migration boundary, permitted writes,\n package manager, network policy, and candidate verification commands.\n3. Record the installed `@rxjs/migrate` version and canonical Skill digest.\n If the installed Skill does not match its package, stop and synchronize it\n before trusting these instructions.\n4. State the proposed read, write, dependency, and command scope before broad\n changes.\n\nPause for the developer if the target repository or allowed scope is unclear,\nexisting changes overlap the migration, or destructive, networked, external,\nor broader actions require new authority.\n\nExit only when the scope, allowed writes, package manager, and candidate gates\nare recorded.\n\n## Stage 2: Assess usage, lifecycle risk, and coverage\n\nInventory installed RxJS versions and import forms, then locate Observable\nconstruction, custom producers, Subjects, subscription ownership, repeated\nsubscriptions, retry/refresh/cache paths, schedulers and timing, test helpers,\ninterop inputs, cancellation, teardown, and error handling. Include direct and\ntransitive operator usage.\n\nFor each lifecycle-sensitive path, link exact source evidence and mark it as:\n\n- covered by an existing baseline;\n- requiring a characterization test;\n- explicitly unsupported; or\n- an uncovered risk the developer accepts.\n\nProduce a risk and coverage report before proposing rewrites. Read\n[references/assessment-and-contract.md](references/assessment-and-contract.md)\nfor the inventory and characterization protocol.\n\nExit only when every in-scope lifecycle-sensitive use has one recorded\ncoverage disposition. Missing coverage is not evidence that behavior is safe.\n\n## Stage 3: Establish the green RxJS 7 baseline\n\nRun the agreed build, type, lint, unit, integration, and behavior checks against\nthe unchanged RxJS 7 project. Record exact commands, environment facts, exit\ncodes, and concise results.\n\nAdd focused characterization tests where Stage 2 found material gaps. Protect\nobservable values, completion/error behavior, producer multiplicity,\ncancellation, abort reasons, teardown ordering, timing, and externally visible\nsubscription effects as applicable. Every characterization test must pass on\nRxJS 7 before migration begins.\n\nPause if a starting gate fails. Diagnose it and ask the developer whether to\nfix it first, narrow scope, or record it as an accepted pre-existing failure.\nNever silently reclassify it as a migration regression or ignore it.\n\nExit only with a green baseline or explicit approval for each named\npre-existing failure, plus green characterization tests.\n\n## Stage 4: Classify and approve the target contract\n\nDivide the scope into stable migration units. For each unit, record one target\nlifecycle using the values accepted by the installed manifest schema and one\nevidence classification. Use repository evidence and\n[references/assessment-and-contract.md](references/assessment-and-contract.md)\nto explain the choice.\n\nThe engine may identify risk but cannot choose lifecycle intent. `unresolved`\nis a stop state. Pause for the developer when either platform-shared behavior\nor producer-per-direct-subscription behavior is plausible, or when Subject\nsemantics, cancellation, scheduler ordering, error behavior, interop, or a\npublic behavior change is not proved.\n\nIntentional divergences require a concrete old claim, proposed Next claim,\nuser impact, evidence, and developer approval. Validate the manifest\nstructurally, then run the installed readiness assessment. Do not proceed with\na batch containing unresolved intent or required pending approval.\n\nExit only when the developer has approved every ambiguous choice and\nintentional divergence needed for the next batch.\n\n## Stage 5: Plan and dry-run bounded engine changes\n\nInspect the installed capability registry and select only entries whose\nversion, source form, arity, preconditions, and executable evidence match the\napproved unit. Do not infer support from a familiar name. Follow\n[references/engine-and-batches.md](references/engine-and-batches.md).\nWhen the batch contains RxJS 7 marble tests, also read\n[references/test-migration.md](references/test-migration.md).\n\nRun `rxjs-migrate` without `--write` using explicit provenance and, when\nrequired, the approved `cold` or `platform` mode. Preserve the current test\nframework unless a supported adapter was separately selected. Capture the\nversioned JSON report, changed paths, structured diagnostics, and exit code.\n\nPause when a diagnostic requires review or refuses a transform, when output\nwould escape authorized paths, when source does not match the capability\nevidence, or when batch size or semantic reach exceeds the reviewed scope.\nNever conceal unsupported segments inside a partially transformed pipeline.\n\nExit only after diagnostics and changed-file scope are reviewed and the\ndeveloper has approved any newly broadened batch.\n\n## Stage 6: Apply one small migration batch\n\nApply only the reviewed dry-run plan. Require an explicit write destination\ninside the authorized project and preserve source provenance. Do not overwrite\nexisting output without specific approval. Review the resulting diff before\nadditional edits.\n\nFormat through the project's normal tools. Ensure ordinary project-owned\nsource and direct test declarations remain; do not leave dynamic generators,\nhidden case registries, or compatibility assertion layers in the result.\n\nImmediately check parsing, the narrowest useful type boundary, and engine\nidempotence. Re-running the same transform must produce no new source change\nand stable diagnostics. If it does not, restore the affected batch to the\nreviewed starting point and report an engine defect.\n\nExit only when the batch parses, type-checks at its narrow boundary, is\nidempotent, and every diagnostic is resolved, carried forward, or escalated.\n\n## Stage 7: Build, test, diagnose, and repair\n\nRun focused characterization and migrated tests first, then the agreed project\ngates. Classify every failure as a migration defect, RxJS Next product gap,\nintentional divergence, environment/baseline issue, or still-unknown result.\nUse [references/verification-and-closeout.md](references/verification-and-closeout.md)\nfor the repair rules.\n\nRepair migration defects in a small batch and repeat the relevant gates. For a\nproduct gap, preserve the failing evidence and report it; do not disguise it\nwith a local replacement. For an intentional divergence, change an expectation\nonly after the manifest records approved new behavior and user impact.\n\nPause before any repair that changes public behavior, weakens evidence,\nexpands writes, changes dependencies beyond the reviewed plan, needs external\naccess, or introduces a compatibility layer.\n\nExit only when agreed gates pass or each remaining red result has a named,\nevidenced, explicitly accepted blocker.\n\n## Stage 8: Close out and hand off\n\nUpdate the contract manifest and report with exact source and target versions,\nengine version, capability-registry version, canonical Skill digest, baseline,\nunits, diagnostics, divergences, final commands/results, and blockers. Validate\nthe manifest with the installed schema and assess readiness separately.\n\nReview [references/review-checklist.md](references/review-checklist.md). Report:\n\n1. what behavior and lifecycle contract changed;\n2. what source and tests changed;\n3. the exact gates run and their results;\n4. migration defects repaired versus product gaps retained;\n5. approved divergences and environment limitations; and\n6. remaining blockers, owners, evidence, and acceptance.\n\nClaim completion only when readiness is `ready`, or\n`ready-with-accepted-blockers` when the developer intentionally chose that\noutcome. Otherwise hand off the migration as incomplete with the next concrete\ndecision or action.\n",".agents/skills/rxjs-next-migration/assets/migration-report.md":"# RxJS Next migration report\n\nThis report summarizes the machine-readable migration contract. The manifest\nvalidated by the installed `@rxjs/migrate` schema remains the authoritative\nstructured decision and evidence record.\n\n## Scope and authority\n\n- Repository:\n- Source revision:\n- Migration boundary:\n- Authorized write paths:\n- Package manager:\n- Network policy:\n- Existing changes protected:\n- Developer/approver:\n\n## Tool and dependency identity\n\n| Item | Version or digest | Evidence |\n| ---------------------- | ----------------- | -------- |\n| Source RxJS | | |\n| Target RxJS Next | | |\n| `@rxjs/migrate` engine | | |\n| Capability registry | | |\n| Canonical Skill | | |\n| Contract schema | | |\n\n## RxJS 7 baseline\n\n| Check ID | Command | Environment | Exit | Result | Accepted pre-existing failure |\n| -------- | ------- | ----------- | ---: | ------ | ----------------------------- |\n\n## Risk and coverage assessment\n\n| Finding | Source locations | Lifecycle/behavior risk | Coverage disposition | Evidence or approval |\n| ------- | ---------------- | ----------------------- | -------------------- | -------------------- |\n\n## Target contract units\n\n| Unit ID | Source locations | RxJS 7 claim | Target lifecycle | Evidence classification | Approval | Evidence |\n| ------- | ---------------- | ------------ | ---------------- | ----------------------- | -------- | -------- |\n\n## Migration batches\n\n| Batch | Scope | Dry-run report | Diagnostics reviewed | Write approved by | Changed files |\n| ----- | ----- | -------------- | -------------------- | ----------------- | ------------- |\n\n## Diagnostics\n\n| Diagnostic ID | File/span | Disposition | Classification | Required action | Resolution or owner |\n| ------------- | --------- | ----------- | -------------- | --------------- | ------------------- |\n\n## Intentional divergences\n\n| Units | Previous claim | Approved Next claim | User impact | Evidence | Approver/time/rationale |\n| ----- | -------------- | ------------------- | ----------- | -------- | ----------------------- |\n\n## Verification\n\n| Check ID | Command | Environment | Exit | Result | Summary |\n| -------- | ------- | ----------- | ---: | ------ | ------- |\n\n## Outcome classification\n\n### Migration defects repaired\n\n-\n\n### RxJS Next product gaps\n\n-\n\n### Environment or baseline limitations\n\n-\n\n## Accepted blockers\n\n| Owner | Affected units | Reason | Evidence | Prevented outcome | Acceptance |\n| ----- | -------------- | ------ | -------- | ----------------- | ---------- |\n\n## Readiness and handoff\n\n- Manifest schema validation:\n- Readiness assessment:\n- Remaining decisions:\n- Next action and owner:\n- Measured migration outcome and limitations:\n",".agents/skills/rxjs-next-migration/references/assessment-and-contract.md":"# Assessment, baseline, and target contract\n\nUse this reference during Stages 2 through 4. Collect evidence before asking\nthe developer to choose a target contract; ask only about intent the repository\ncannot prove.\n\n## Repository assessment\n\nRecord exact file locations and the commands or tests that exercise each\nfinding. Search application source, shared libraries, tests, configuration,\nfixtures, build tools, and framework glue for these themes:\n\n| Theme | Look for | Behavioral question |\n| --------------------- | ------------------------------------------------------------------ | ----------------------------------------------------------------- |\n| Construction | `new Observable`, `defer`, custom producers, wrappers | When is producer work created and restarted? |\n| Repeated subscription | retry, refresh, fan-out, cache invalidation, multiple consumers | Must consumers run independent work or share one active run? |\n| Subjects | current/replayed values, late subscribers, terminal state | What exists before observation and what must late observers see? |\n| Ownership | captured subscriptions, `unsubscribe`, component disposal | Who cancels, with what reason, and when does upstream stop? |\n| Teardown | multiple teardown callbacks, finalizers, resource release | Does observable order matter? |\n| Timing | schedulers, timers, animation, queue ordering, virtual time | Which host timing boundary preserves the claim? |\n| Errors | selector errors, observer callback errors, late errors | Where must the error be delivered or reported? |\n| Inputs | iterables, async iterables, promises, custom subscribables | Is the value accepted by the platform conversion boundary? |\n| Composition | pipeable operators, aliases, higher-order pipelines | Is a fixture-proved Symbol mapping available for this exact form? |\n| Testing | TestScheduler helpers, framework assertions, native/polyfill setup | Which claims are real behavior and which are harness machinery? |\n\nTrace imports and helper wrappers so transitive usage is not mistaken for\nabsence. Sampling is acceptable only when its limits are named and accepted.\n\n## Coverage disposition\n\nGive every lifecycle-sensitive finding exactly one disposition:\n\n- **Covered:** a named existing test proves the relevant behavior.\n- **Characterize:** add a focused RxJS 7 test before migration.\n- **Unsupported:** no accepted Next surface can preserve the required claim;\n retain evidence and record a product gap.\n- **Accepted uncovered risk:** the developer explicitly accepts proceeding\n without the missing evidence; record approver, time, rationale, and impact.\n\nRecommend characterization for repeated subscriptions, side effects, sharing,\nlate subscribers, cancellation, teardown, timing, errors, or public API behavior\nwhen current tests do not prove the outcome.\n\n## Characterization protocol\n\nAdd the narrowest test that proves an externally meaningful claim. Prefer\nassertions over values, completion/error, producer start count, concurrent and\nlate observations, cancellation ownership, abort reason, teardown order,\nvirtual or host timing, and visible side effects. Avoid locking in irrelevant\nRxJS 7 internals.\n\nRun the new test on the unchanged RxJS 7 dependency. Record the exact command\nand result. A characterization test added after dependency migration is not an\nRxJS 7 baseline unless it is separately demonstrated against the pinned source\nenvironment.\n\n## Lifecycle decision record\n\nUse only lifecycle values accepted by the installed contract-manifest schema.\nExplain each selection in behavioral language:\n\n- active platform producer shared and ref-counted while observers exist;\n- producer work created per direct subscription through an explicit Next API;\n- intentional hot Subject behavior;\n- no producer lifecycle applies;\n- required behavior is unsupported; or\n- intent remains unresolved.\n\nDo not use a blanket “hot” or “cold” label for a platform Observable. The first\nobserver starts an active producer, concurrent observers join it, the last\nobserver leaving tears it down, and a later observer can start a new run.\n\nFor every unit, record:\n\n1. stable ID and exact source spans;\n2. current RxJS 7 claim and evidence;\n3. selected target lifecycle;\n4. compatibility/evidence classification accepted by the installed schema;\n5. one or more target claims;\n6. approval status, approver, timestamp, and rationale when required; and\n7. related diagnostics, divergences, and blockers.\n\n## Mandatory developer pauses\n\nPause rather than infer when:\n\n- both independent and shared producer behavior are plausible;\n- repeated subscriptions may implement retry, refresh, cache, or fan-out;\n- Subject replay, terminal, or late-observer behavior is unproved;\n- cancellation ownership, abort reason, or teardown order could change;\n- scheduler removal could alter ordering;\n- a custom subscribable is outside the accepted conversion boundary;\n- a public claim changes or an expectation would need to change;\n- coverage is missing or the baseline is not green; or\n- a unit remains unresolved, unsupported without acceptance, or pending\n approval in the readiness assessment.\n\nThe engine's diagnostic can identify a pause condition, but only the developer\ncan approve lifecycle intent or an intentional divergence.\n",".agents/skills/rxjs-next-migration/references/engine-and-batches.md":"# Engine registry and migration batches\n\nUse this reference during Stages 5 and 6. `@rxjs/migrate` is a deterministic\nengine for a bounded syntax subset. It is not an autonomous repository\nmigration tool.\n\n## Consume installed contracts\n\nRead engine data from the project's installed package, not from a list copied\ninto a prompt, Skill, or harness adapter. The public API exports the default\ncapability registry, registry and manifest schemas, migration functions,\ncontract readiness assessment, and engine/schema versions.\n\nA local inspection can use the project's module runner with this shape:\n\n```js\nimport { assessMigrationContractReadiness, defaultCapabilityRegistry, migrationContractManifestSchema } from '@rxjs/migrate';\n\nfor (const capability of defaultCapabilityRegistry.capabilities) {\n // Review id, legacy/source name, target Symbol, adapter, arity,\n // preconditions, status, and fixture evidence for this exact package.\n}\n\nconst parsed = migrationContractManifestSchema.safeParse(manifest);\nif (parsed.success) {\n const readiness = assessMigrationContractReadiness(parsed.data, {\n expectedSkillDigest,\n });\n}\n```\n\nObtain `expectedSkillDigest` from the installed adapter's integrity check or\nthe Node-only `@rxjs/migrate/skill` API. Consult the installed TypeScript\ndeclarations for exact signatures. Refuse an incompatible custom registry\nrather than adapting it informally. A registry entry proves only the source\nforms, overloads, preconditions, and fixtures it names; it does not promise\ngeneral RxJS 7 compatibility.\n\n## Capability selection\n\nBefore selecting a transform, verify all of the following:\n\n- registry schema, registry version, and engine version match the installed\n package;\n- the source import binding is the one identified by the engine and is not\n shadowed or repurposed;\n- the call shape, arity, scheduler/result-selector form, and pipeline context\n satisfy every declared precondition;\n- the fixture evidence covers the intended mapping and evidence class; and\n- the migration unit already has an approved lifecycle contract.\n\nName similarity, a compatible TypeScript signature, or a green transformed\ntest is not a substitute for those checks.\n\n## Dry-run protocol\n\nInvoke the locally installed `rxjs-migrate` binary through the project's\npackage manager. Supply all required provenance. For example:\n\n```sh\nrxjs-migrate \\\n --source-root \\\n --source-repo \\\n --source-sha \\\n --mode \\\n --framework preserve \\\n \n```\n\nOmit `--mode` when the selected source does not require a lifecycle choice.\nNever let a directory name or wrapper select it implicitly. Use the package's\ndocumented framework adapter only for a separately approved framework change.\n\nWithout `--write`, the CLI returns a versioned JSON report and performs no\nwrites. Record its engine version, registry version, operation, file results,\nordered diagnostics, and exit status. The current CLI contract distinguishes\ncompleted, structured refusal, invalid arguments, and operational failure;\nread the installed package documentation for the exact numeric codes.\n\nReview every diagnostic, including source span, severity, disposition, refusal\nscope, classification, next action, and capability ID when present. A refused\nbatch must leave source and destination unchanged.\n\n## Write protocol\n\nAfter the dry run and changed paths are approved, repeat the same inputs with\nan explicit contained destination:\n\n```sh\nrxjs-migrate \\\n --source-root \\\n --source-repo \\\n --source-sha \\\n --mode \\\n --framework preserve \\\n --write --out-dir \\\n \n```\n\nThe engine plans the whole batch before writing and refuses lexical, canonical,\nor symlink path escape. Do not bypass containment or no-overwrite behavior with\nmanual bulk writes. If the reviewed destination is the current source tree,\nmake that scope and overwrite decision explicit and keep recovery possible.\n\nCompare the write report with the dry run byte for byte where contractual.\nInspect the diff for:\n\n- provenance and filenames;\n- exact Symbol imports and calls;\n- preserved unsupported source;\n- lifecycle helper selection;\n- awaited asynchronous test helpers;\n- framework preservation or the separately selected adapter;\n- retained assertions, errors, subscription claims, and local helpers; and\n- absence of hidden generators or compatibility layers.\n\nThen run the same transform again without writes. The second result must be\nunchanged with stable diagnostics. Any output or diagnostic drift is an engine\ndefect; stop the batch and preserve a reproduction.\n\n## Refusal and manual repair\n\nDo not turn refused syntax into claimed mechanical output by editing around the\ndiagnostic. Carry the finding into the contract and choose one of these paths:\n\n1. narrow the batch to independently safe units;\n2. add characterization, obtain a developer decision, and make a reviewed\n semantic edit outside the engine's claimed output;\n3. report an RxJS Next product gap; or\n4. preserve the source and accept a named blocker.\n\nManual work remains subject to the same baseline, lifecycle, review, and\nverification gates. It must not be described as fixture-proved engine output.\n",".agents/skills/rxjs-next-migration/references/review-checklist.md":"# Migration closeout checklist\n\n## Authority and provenance\n\n- Repository instructions, scope, allowed writes, package manager, and network\n policy were recorded before broad changes.\n- Existing work was protected and every changed file is within the authorized\n migration boundary.\n- Source repository/revision, RxJS versions, engine version, registry version,\n and canonical Skill digest are exact and reproducible.\n- The installed Skill content matches the installed `@rxjs/migrate` package.\n\n## Baseline and coverage\n\n- Agreed build, type, lint, test, and behavior gates were run on unchanged\n RxJS 7 source.\n- Every baseline failure is either fixed or explicitly recorded as pre-existing\n with developer acceptance.\n- Each lifecycle-sensitive path is linked to existing coverage,\n characterization, explicit unsupported status, or an accepted uncovered\n risk.\n- Characterization tests passed against RxJS 7 before dependency/source\n migration.\n\n## Target contract\n\n- Every unit has stable source locations, a behavioral claim, one target\n lifecycle, an evidence classification, and supporting evidence.\n- No required unit remains unresolved or pending approval.\n- Platform sharing and producer-per-direct-subscription behavior were selected\n intentionally rather than inferred from syntax.\n- Subjects, repeated subscriptions, cancellation, teardown, timing, errors,\n and input conversion were reviewed where applicable.\n- Every intentional divergence records old and new claims, user impact,\n evidence, approver, timestamp, and rationale.\n\n## Mechanical batches\n\n- Capability decisions came from the installed versioned registry; no copied\n operator list or name-only match was used.\n- Each engine operation ran dry first with exact provenance and an explicit\n lifecycle mode when required.\n- The dry-run scope, diagnostics, and changed paths were reviewed before write.\n- Refused or unsupported source remains visible and was not smuggled through a\n partial transform.\n- Writes stayed within the approved destination and did not overwrite local\n content without explicit approval.\n- Output preserves ordinary project-owned source, direct tests, assertions,\n and the selected framework.\n- Every applied transform is parseable, type-checkable at its narrow boundary,\n and idempotent with stable diagnostics.\n\n## Verification and handoff\n\n- Focused characterization/migrated tests and all agreed project gates were\n run with exact commands, environments, exit codes, and results.\n- Failures are classified as migration defects, product gaps, intentional\n divergences, baseline/environment issues, or unresolved—not relabeled for a\n green report.\n- No test was weakened, skipped, deleted, or replaced without explicit\n developer approval and a recorded contract change.\n- Schema validation and readiness assessment were both run; one is not being\n used as a substitute for the other.\n- All diagnostics are resolved, carried with an owner, or represented by an\n explicitly accepted blocker.\n- The final report states measured outcomes and limitations without claiming\n general automatic migration.\n",".agents/skills/rxjs-next-migration/references/test-migration.md":"# TestScheduler and marble-test migration\n\nUse this reference only for selected RxJS 7 `TestScheduler` or marble tests.\nPreserve behavioral evidence and the project's ordinary test conventions.\n\n## Preserve the outer framework\n\nKeep the project's `describe`, `it`, `test`, hooks, assertion library, spies,\nand configuration by default. Treat a requested framework change as a separate\nadapter over the same migrated test body. If the installed engine does not\nsupport the requested source/target pair, preserve the framework and report\nthe conversion as manual work rather than guessing globals or assertions.\n\nEmit direct, readable test declarations. Materialize selected parameterized\ncases when necessary; do not introduce a runtime loop, hidden registry,\ngenerated location shim, or generator warning.\n\n## Preserve provenance and claims\n\nRecord the source repository, exact revision, and source path for every\nmigrated file. State the old case's behavioral claim before editing it. Keep\ncase-level comments only where they explain a real lifecycle, scheduler,\ncancellation, or divergence decision.\n\nTreat analyzer fingerprints as duplicate candidates, never automatic deletion.\nConsolidate only when public API/overload, lifecycle, values, timing, completion,\nerrors, cancellation, subscription claim, and relevant type behavior all\nmatch. Retain links to every original case in the manifest/report.\n\n## Convert harness structure\n\nReplace a supported `TestScheduler.run(...)` wrapper with one direct `rxTest`\ncall. Remove a scheduler variable, constructor, matcher adapter, or setup hook\nonly when it has no other responsibility. Return or await the `Promise`\nfrom `rxTest` through the outer test.\n\nPreserve the meaning of supported helpers:\n\n- `cold()` represents producer-per-subscription evidence;\n- `hot()` represents a subject-like absolute timeline;\n- `observable()` represents the shared, ref-counted platform producer;\n- `expectObservable()` retains cancellation from the subscription marble;\n- `expectSubscriptions()` describes observer subscriptions for cold sources\n and producer activation windows for platform sources;\n- `time()` and `animate()` use the `@rxjs/test` virtual host boundary; and\n- `flush()` is asynchronous and must be awaited from an `async` callback.\n\nRefuse or manually classify direct scheduler state, methods used outside the\nsupported run callback, scheduler subclasses, implementation-only queue/frame\nassertions, or unsupported framework assertions. Do not erase them as obsolete\nwithout a reviewed evidence classification.\n\n## Convert composition through the registry\n\nFor each RxJS 7 pipeable call, look up the exact installed capability entry and\napply only its declared Symbol target, argument adapter, arity, preconditions,\nand fixture-proved source shape. Convert a supported sequence into successive\nexact-Symbol calls and import those Symbols from the declared modules.\n\nDo not copy a table of operator mappings into project guidance. Do not use a\nplatform string method because its description matches an RxJS 7 operator.\nPreserve unsupported overloads and mixed pipelines with their diagnostics.\n\nUse an ambient/global `Observable` when the accepted target contract requires\nplatform construction. Do not import the constructor from a polyfill merely to\nmake a test pass.\n\n## Review lifecycle and realms\n\nKeep a producer-per-subscription baseline visibly separate from platform\ncoverage. For the platform lifecycle, test first activation, concurrent join,\nlate observation, individual abort, final abort/teardown, and later restart as\napplicable.\n\nRun the same platform claim against fallback and native implementations where\nthe project supports both. Initialize each in an isolated process, worker,\nwindow, or iframe before importing RxJS extensions and tests. If the realm has\nno native `Observable`, record native mode as unavailable; never install the\nfallback and label the result native.\n\nRemove scheduler arguments only when the installed target capability and its\nfixtures prove a host-timed mapping that `rxTest` virtualizes. Preserve original\nerror values and ordinary non-marble assertions. If product behavior fails a\nfaithful migrated claim, retain the evidence as a product gap rather than\nchanging production code or weakening the expectation.\n",".agents/skills/rxjs-next-migration/references/verification-and-closeout.md":"# Verification, repair, and closeout\n\nUse this reference during Stages 7 and 8. Outcome evidence outranks source\nshape.\n\n## Verification ladder\n\nRun checks from narrowest to broadest so a failure remains diagnosable:\n\n1. parse and format the changed files;\n2. run focused type checks;\n3. run characterization and directly migrated tests;\n4. run the affected package or workspace build, type, lint, and test gates;\n5. run agreed integration, browser, native/polyfill, or repository-wide gates;\n6. repeat any command whose environment was changed during diagnosis.\n\nRecord the exact command, relevant environment facts, exit code, status, and a\nconcise summary. “Passed locally” without a command and environment is not a\nverification record.\n\nFor lifecycle-sensitive code, verify the contract actually selected:\n\n- producer activation count and restart;\n- concurrent and late observation;\n- individual and final cancellation;\n- abort reason and upstream closure;\n- Subject current/replay/terminal behavior;\n- teardown ordering;\n- time and scheduling order;\n- error delivery and late/unhandled error behavior; and\n- input conversion acceptance or explicit refusal.\n\n## Failure classification and response\n\n| Class | Meaning | Required response |\n| ---------------------- | -------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------- |\n| Migration defect | The edit broke syntax, types, test intent, mapping, or selected contract | Repair a small batch and rerun affected gates |\n| RxJS Next product gap | The accepted target surface cannot satisfy preserved evidence | Keep evidence visible; report the product gap |\n| Intentional divergence | Approved Next behavior differs from the RxJS 7 claim | Record old/new claims, impact, evidence, and approval before changing expectations |\n| Baseline/environment | The failure existed before migration or the required runtime/tool is unavailable | Preserve its original status and record the limitation or accepted failure |\n| Unknown | Evidence does not yet identify the cause | Investigate or pause; never relabel for convenience |\n\nAllowed repairs clarify or correct migrated code, strengthen characterization,\nor fix a demonstrated migration defect while preserving the approved contract.\n\nThe following require a developer pause:\n\n- deleting, skipping, quarantining, or weakening a test;\n- changing a public behavioral claim;\n- adding a local operator, scheduler, compatibility facade, or assertion shim;\n- changing platform behavior to imitate RxJS 7;\n- broad dependency or configuration changes beyond reviewed scope; or\n- accepting a red or unrun required gate.\n\n## Manifest closeout\n\nBuild the manifest against the exact schema exported by the installed package.\nAt minimum, record the schema and engine identity required by that version,\ncapability-registry version, canonical Skill digest, exact source and target\nRxJS versions, baseline checks, migration units, diagnostics, intentional\ndivergences, verification results, and blockers.\n\nStructural validity answers only “is this shaped correctly?” Run the separate\nreadiness assessment to detect unresolved lifecycle units, pending approvals,\nunresolved/refused diagnostics, unapproved divergences, missing or red gates,\nidentity mismatches, and unaccepted blockers.\n\nAn accepted blocker must name:\n\n- its owner and reason;\n- affected units;\n- supporting evidence;\n- the behavior, environment, or release claim it prevents; and\n- explicit developer acceptance.\n\nDo not use a blocker to hide an unexplained regression. A migration may close\nas `ready-with-accepted-blockers` only when the installed readiness assessment\nreturns that state and the human-readable report makes the limitations clear.\n\n## Final handoff\n\nUse the report asset to summarize:\n\n- scope and provenance;\n- installed engine, registry, Skill, source RxJS, and target RxJS identity;\n- RxJS 7 baseline and characterization evidence;\n- lifecycle decisions and approvals;\n- changed source and tests by coherent batch;\n- exact final commands and results;\n- diagnostics and how each was resolved or carried;\n- repaired migration defects;\n- remaining product gaps, divergences, and environment limits; and\n- blocker ownership and next actions.\n\nDo not report “automatic migration succeeded.” State the measured project\noutcome and its limits.\n","AGENTS.md":"# RxJS Next repository guidance\n\nThis branch is the foundation for a new platform-based generation of RxJS, with\nthe working name **RxJS Next** and a probable release name of **RxJS 9**. It is\nnot an incremental RxJS 7 implementation.\n\nBefore making changes, read these documents in order:\n\n1. `docs/rxjs-next/PROJECT_CHARTER.md`\n2. `docs/rxjs-next/ARCHITECTURE.md`\n3. `docs/rxjs-next/DECISIONS.md`\n4. `docs/rxjs-next/PROJECT_PLAN.md`\n5. `docs/rxjs-next/OPEN_QUESTIONS.md`\n6. `docs/rxjs-next/COMPATIBILITY.md` when changing APIs or behavior\n\n## Required working rules\n\n- Treat the current code as an exploratory implementation, not the completed\n architecture. Preserve the distinction between current behavior, accepted\n direction, and proposals.\n- Use the native web-platform `Observable` when it exists. A polyfill must not\n replace a conforming native implementation.\n- Add RxJS behavior to the platform constructor or its prototype through\n exported Symbols. Do not add string-named RxJS methods to the platform\n `Observable` surface.\n- Export corresponding RxJS Symbols even for operators that already have a\n platform string method, such as `map` and `filter`. Preserve both forms:\n `observable.map(project)` is the platform contract and\n `observable[map](project)` is the RxJS contract. The Symbol form may delegate\n or add functionality, but it must not replace the string method; document and\n test every intentional difference.\n- Preserve the collision isolation of exact Symbol keys: unrelated code using\n the same descriptive name must not be able to overwrite an RxJS extension.\n Do not introduce `Symbol.for` keys without an accepted namespacing and\n duplicate-install decision.\n- Keep platform semantics and RxJS 7 compatibility semantics in separate\n architectural layers. In particular, do not silently make the platform\n `Observable` behave like an RxJS 7 cold observable.\n- Use `AbortSignal` and the platform `Subscriber` lifecycle as the cancellation\n foundation for the platform layer.\n- Do not assume the old RxJS 7 tests can pass unchanged. Classify every migrated\n test according to the compatibility policy in `COMPATIBILITY.md`.\n- Do not revive removed RxJS 7 internals in the platform package to make a test\n pass. Put compatibility behavior behind an explicit compatibility boundary.\n- When implementing against the living Observable specification or Web\n Platform Tests, record the exact upstream revision used.\n- Preserve RxJS 7 history. The old implementation remains an important source\n of behavioral tests, migration knowledge, and compatibility requirements.\n\n## Project-plan discipline\n\n`docs/rxjs-next/PROJECT_PLAN.md` is the active execution queue. Work on the\nsingle item marked `NEXT` unless the user explicitly changes priorities or a\nsmall prerequisite is required. Keep exactly one `NEXT` item, update the\ncompletion evidence, and append a short session-log entry when completing a\nplan item.\n\n## Architecture-change discipline\n\nUpdate the documentation in the same change when code alters any of these:\n\n- package or import boundaries;\n- native-versus-polyfill selection;\n- Symbol identity or patch installation;\n- subscription sharing, ref counting, cancellation, or teardown;\n- subclass or realm behavior;\n- compatibility guarantees;\n- public exports;\n- test or conformance gates.\n\nRecord durable decisions in `docs/rxjs-next/DECISIONS.md`. Move unresolved\nquestions into or out of `docs/rxjs-next/OPEN_QUESTIONS.md` as evidence changes.\n\n## Verification\n\nRun the narrowest relevant tests and build/type checks. Record failures\nhonestly; do not treat a passing unit test as proof of platform conformance.\nThe current known baseline is documented in `ARCHITECTURE.md`.\n","apps/rxjs.dev/tools/README.md":"# AIO project tooling\n\nThis document gives an overview of the tools that we use to generate the content for the RxJS website.\n\nThe application that actually renders this content can be found in the `apps/rxjs.dev/src` folder.\nThe handwritten content can be found in the `apps/rxjs.dev/content` folder.\n\nEach subfolder in this `apps/rxjs.dev/tools/` folder contains a self-contained tool and its configuration. There is\na `README.md` file in each folder that describes the tool in more detail.\n\n## transforms\n\nAll the content that is rendered by the RxJS docs application, and some of its configuration files,\nare generated from source files by [Dgeni](https://github.com/angular/dgeni). Dgeni is a general\npurpose documentation generation tool.\n\nMarkdown files in `apps/rxjs.dev/content`, code comments in the core Angular source files and example\nfiles are processed and transformed into files that are consumed by the RxJS docs application.\n\nDgeni is configured by \"packages\", which contain services and processors. Some of these packages are\ninstalled as `node_modules` from the [dgeni-packages](https://github.com/angular/dgeni-packages) and\nsome are specific to the RxJS project.\n\nThe project specific packages are stored in the `apps/rxjs.dev/tools/transforms` folder. See the\n[README.md](transforms/README.md) for more details.\n","apps/rxjs.dev/tools/transforms/README.md":"# Overview\n\nAll the content that is rendered by the AIO application, and some of its configuration files, are\ngenerated from source files by [Dgeni](https://github.com/angular/dgeni). Dgeni is a general purpose\ndocumentation generation tool.\n\nMarkdown files in `/aio/content`, code comments in the core Angular source files and example files\nare processed and transformed into files that are consumed by the AIO application.\n\nDgeni is configured by \"packages\", which contain services and processors. Some of these packages are\ninstalled as `node_modules` from the [dgeni-packages](https://github.com/angular/dgeni-packages) and\nsome are specific to the AIO project.\n\nThe project specific packages are stored in this folder (`aio/tools/transforms`).\n\nIf you are an author and want to know how to generate the documentation, the steps are outlined in\nthe top level [README.md](../../README.md#guide-to-authoring).\n\n## Root packages\n\nTo run Dgeni, you must specify a root package, which acts as the entry point to the documentation\ngeneration.\nThis root package, in turn requires a number of other packages, some are defined locally in the\n`tools/transforms` folder, such as `tools/transforms/cheatsheet-package` and\n`tools/transforms/content-package`, etc. And some are brought in from the `dgeni-packages` node\nmodules, such as `jsdoc` and `nunjucks`.\n\n* The primary root package is defined in `tools/transforms/angular.io-package/index.js`. This package\nis used to run a full generation of all the documentation.\n* There are also root packages defined in `tools/transforms/authors-package/*-package.js`. These\npackages are used by the documentation authors when writing docs, since it allows them to run partial\ndoc generation, which is not complete but is faster for quickly seeing changes to the document that\nyou are working on.\n\n## Other packages\n\n* angular-base-package\n* angular-api-package\n* angular-content-package\n* content-package\n* links-package\n* post-process-package\n* remark-package\n* target-package\n\n## Templates\n\nAll the templates for the angular.io dgeni transformations are stored in the `tools/transforms/templates`\nfolder. See the [README](./templates/README.md).\n","apps/rxjs.dev/tools/transforms/rxjs-decision-tree-generator/README.md":"# Decision Tree Generator\n\n## Purpose\n\nManage a decision tree in YAML for choosing an operator and generate JSON to be consumed by the docs web app.\n\n## Goals\n\n- Port the first version of the decision-tree-widget into Angular\n- Flatten the JSON structure and make it easy to work with in the docs web app\n- Consume URI paths and other relevant from the docs generation task vai Dgeni\n- Keep the decision tree work scalable and easy to work with by keeping the linked list structure in the YAML tree\n\n## Prior Art\n\nVersion 1 was in the old docs site and used YAML, snabbdom, RxJS, and hyperscript-helpers. The YAML for version 1 version was ported into the new version with minor tweaks.\n\n## Tech\n\n- Node\n- TypeScript\n- TS-Node\n- Jest\n- YAML\n\n## Dependencies\n\nGenerating the JSON requires:\n\n- The decision tree YAML, located in `/src`\n- The generated `api-list.json`, which can be generated by running `pnpm run docs` at the root level of `apps/rxjs.dev`\n\n## Setup & Build\n\n```shell\npnpm install && pnpm run build\n```\n\n## Development\n\nAny changes to the YAML tree or any of the TypeScript scripts will generate a new JSON tree\n\n```shell\npnpm run watch\n```\n\n## Distribution\n\nAfter a `pnpm run build` the JSON is output to `apps/rxjs.dev/src/generated/app/decision-tree-data.json` to be consumed by the web application.\n\nThere's also an npm script at the root level of the `apps/rxjs.dev` to generate the JSON tree: `docs-decision-tree`.\n\n## Testing\n\nRun a watch task when writing tests\n\n```shell\npnpm run test:watch\n```\n\nFull test\n\n```shell\npnpm run test\n```\n\nRun coverage\n\n```shell\npnpm run test:coverage\npnpm run test:watch:coverage\n```\n\n## TODO\n\n- Consider moving this work into a Dgeni package so it can be generated in the same way the other doc information is generated\n","apps/rxjs.dev/tools/transforms/templates/README.md":"This folder contains the dgeni templates that are used to generate the API docs\n\nGenerally there is a template for each docType. Templates can extend and/or include\nother templates. Templates can also import macros from other template files.\n\n# Template inheritance\n\nWhen extending a template, parent must declare blocks that can be overridden by the\nchild. The template extension hierarchy looks like this (with declared blocks in parentheses):\n\n- layout/base.template.html (base)\n - module.template.html\n - layout/api-base.template.html (jumpNav, jumpNavLinks, whatItDoes, infoBar, securityConsiderations,\n deprecationNotes, howToUse, details)\n - class.template.html\n - directive.template.html\n - enum.template.html\n - var.template.html\n - const.template.html\n - let.template.html\n - decorator.template.html\n - function.template.html\n - interface.template.html\n - type-alias.template.html\n - pipe.template.html\n\n# Doc Properties\n\nIt is useful to know what properties are available on each doc type when working with the templates.\nThe `typescript` Dgeni package is now written in TypeScript and there is a class for each of the types of\nAPI document. See https://github.com/angular/dgeni-packages/tree/master/typescript/src/api-doc-types.\nThis is a good place to go to see what properties you can use in the templates.","packages/migrate/README.md":"# `@rxjs/migrate`\n\nDeterministic source-migration tools used by the RxJS 9 agent-first\nmigration workflow. The current well-tested path migrates RxJS 7\n`TestScheduler` marble specs from Mocha/Chai to ordinary Vitest specs that call\n`rxTest` directly. The engine is not a complete migration product and does not\nchoose lifecycle semantics; see\n[`docs/MIGRATION_TOOLING_DESIGN.md`](docs/MIGRATION_TOOLING_DESIGN.md).\n\nThe package separates two concerns:\n\n- RxJS semantics: `TestScheduler.run` to `rxTest`, pipeable operators to exact\n Symbol calls, and reviewed argument adapters.\n- Test framework syntax: an optional Mocha/Chai-to-Vitest adapter. Other\n source and target frameworks can supply the same small `FrameworkAdapter`\n interface, or preserve their existing framework unchanged.\n\nThe semantic transform also operates on production TypeScript containing\nRxJS 7 `pipe(...)` expressions. It does not require a test framework or a\n`TestScheduler` declaration.\n\n## CLI\n\nStart with a dry run:\n\n```sh\nnpx rxjs-migrate \\\n --source-root . \\\n --source-repo https://github.com/example/project \\\n --source-sha abc123 \\\n --mode cold \\\n --framework mocha-chai-vitest \\\n test/example-spec.ts\n```\n\nThe command writes nothing unless `--write --out-dir ` is present.\nWritten files are normal, locally named source files. They are meant to be\nreviewed, checked in, and maintained by the destination project; there is no\nruntime generator. Successful and refused batches are emitted as versioned\nJSON with the engine and capability-registry versions. Exit codes distinguish\nsuccess (`0`), a structured migration refusal (`1`), invalid arguments (`2`),\nand operational failure (`3`). A refused batch writes no files.\n\nUse `--framework preserve` for Jest, Node test runner, another target, or a\nframework migration handled by another tool. The JavaScript API accepts a\ncustom `FrameworkAdapter` when syntax conversion should happen in the same\npass.\n\n## JavaScript API\n\n```ts\nimport { defaultCapabilityRegistry, migrateTestSource, type FrameworkAdapter } from '@rxjs/migrate';\n\nconst result = migrateTestSource(source, {\n mode: 'cold',\n capabilityRegistry: defaultCapabilityRegistry,\n frameworkAdapter: myFrameworkAdapter satisfies FrameworkAdapter,\n provenance: {\n repository: 'https://github.com/example/project',\n sha: 'abc123',\n path: 'test/example-spec.ts',\n },\n});\n```\n\n`defaultCapabilityRegistry` is a versioned, fixture-backed contract, not a\nclaim of complete RxJS 7 compatibility. A custom registry must use the same\nschema and name the installed engine version; incompatible registries are\nrefused without changing source bytes. Unsupported constructs remain visible\nas diagnostics instead of being hidden behind compatibility helpers.\n\n## Mechanically supported subset\n\nThe default registry currently proves direct, unshadowed `pipe(...)` calls for\n`filter`, `map`, `takeUntil`, `bufferCount`, `concatMap`, `concatAll`,\n`switchAll`, `debounceTime`, `audit`, and `auditTime`, subject to each mapping's\npublished arity and overload preconditions. The registry is the authoritative\nmachine-readable list. Aliases are tracked, while shadowed bindings, mixed\nunsupported pipelines, scheduler overloads, malformed input, and unsupported\nframework assertions are refused or preserved with structured findings.\n\nThe package ships no MCP binary, export, or runtime dependency. D-046 keeps\nthe library and dry-run-first CLI as the only deterministic engine surfaces.\n\nThe representative agent-workflow matrix and its deliberately bounded claims\nare documented in\n[`docs/MIGRATION_QUALIFICATION.md`](docs/MIGRATION_QUALIFICATION.md).\nLive harness qualification is separate from deterministic engine correctness.\n\n## Contract and Skill integrity\n\n`parseMigrationContractManifest` validates the versioned migration decision\nrecord. `assessMigrationContractReadiness` separately reports unresolved\nlifecycle choices, approvals, diagnostics, verification, and blockers so\nschema validity is never mistaken for completion.\n\nThe Node-only `@rxjs/migrate/skill` subpath computes and verifies the canonical\nSkill's deterministic SHA-256 content descriptor and manages generated harness\ndiscovery copies without creating a second authored workflow.\n\nInstall the canonical Skill into a repository with the package command:\n\n```sh\nnpx rxjs-migrate-skill install --harness codex --project-root .\n```\n\nUse `--harness cursor` for Cursor; Codex and Cursor share the open\n`.agents/skills` placement. Use `--harness claude` for Claude Code's\n`.claude/skills` placement. The same command supports `check`, `update`, and\n`remove`. It refuses to overwrite or remove local modifications unless the\ndeveloper supplies `--force`, and each installed copy records its package\nversion and canonical digest in `.rxjs-migrate-skill.json`.\n\n## Review requirements\n\nEvery migrated test should contain a direct `await rxTest(...)` call. Choose\n`cold()` only for producer-per-subscription evidence; use `observable()` when\nthe test should exercise the constructor installed at\n`globalThis.Observable`. Review scheduler arguments, multiple observations,\nsharing, ref counting, cancellation, and restart behavior before accepting a\nmechanical migration.\n","packages/migrate/docs/MIGRATION_QUALIFICATION.md":"# RxJS Next migration workflow qualification\n\n## Status\n\nP0.M5 is complete. All four checked-in Codex/ChatGPT runs pass the pinned seed,\nbehavior, authority, artifact, and semantic outcome gates: three end in an\napproved completed migration and the weak-coverage/unsupported repository ends\nin its required safe stop. Per D-047, this P0 qualification is intentionally\nlimited to Codex/ChatGPT. It does not claim Claude Code or Cursor outcome\nqualification, cross-harness parity, or general automatic migration safety.\n\nP5.2 is also complete by closure audit. Its planned mechanical and semantic\napplication-validation outcome was already satisfied by the P0.M3 deterministic\nfixtures, P4.4 accepted contract fixtures, and P0.M5 four-repository outcome\nmatrix. The closure audit reruns those offline gates and maps them to the\npackage-local migration guide; it does not spend another live-model cycle or\nexpand the original qualification claim.\n\n## P5.2 guide-to-evidence map\n\n| Migration-guide step | Representative evidence |\n| --------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Establish a green RxJS 7 baseline | Four pinned seed repositories, framework-specific baseline commands, immutable dependency descriptors, and executable seed oracles |\n| Inventory affected surfaces and coverage gaps | Application/library scenarios spanning Vitest, Mocha, Jest, strong and weak coverage, scheduler, interop, Subject, sharing, and repeated-subscription behavior |\n| Select an explicit lifecycle contract | Cold-preserving, platform-shared, mixed, and unsupported contract manifests with developer-owned decision vectors |\n| Apply only proven mechanical changes | Versioned capability registry, exact transform fixtures, compilation, idempotence, structured diagnostics, and refusal-safe batch writes |\n| Review semantic boundaries | Held-out producer multiplicity, sharing/ref counting, cancellation, teardown, timing, errors, input conversion, Subject state, and restart assertions |\n| Finish green or stop safely | Three completed migrations pass target build and protected behavior; the weak unsupported repository stops before target installation or migration writes |\n\nThe checked-in P4.4 contract fixtures provide a smaller executable cross-check\nfor all four guide outcomes: `cold-preserving`, `platform-shared`,\n`subject-hot`, and `safe-stop`. A lifecycle-swap negative control prevents a\nsyntactically valid rewrite from being counted as a semantic success.\n\n## Evidence boundary\n\nThe qualification has two distinct lanes:\n\n- deterministic engine fixtures prove exact transforms, structured refusals,\n compilation, idempotence, behavior, path containment, and package contracts;\n- agent scenarios permit source variation but require the same behavioral,\n approval, diagnostic, test-integrity, and artifact gates.\n\nA passing engine fixture is not a passing agent migration. A plausible agent\nreport is not a passing run until its seed identity, chronology, commands,\nmanifest, protected tests, held-out behavior, and captured artifact digests\npass the offline grader.\n\nEach committed record has five hashed artifacts: the exact user prompt and\nfinal response retained as `conversation.md`, the contract manifest, patch,\ncommand results, and final report. The command-results artifact, patch, and\nrecorded observed-authority actions provide the reviewable command/tool\nevidence. Full host event streams were not retained for the first three runs,\nso the conversation artifact must not be described as a complete tool-call\ntranscript. The fourth run was repeated after authority controls were tightened;\nonly its passing record belongs to the closed matrix.\n\n## Representative repositories\n\nThe four immutable seed trees live under\n`packages/migrate/test/agent/fixtures`. Each pins RxJS `7.8.1`, its dependency\ndescriptor, a complete pnpm lockfile, runnable framework-specific baseline\ncommands, and the complete seed-tree digest.\n\n| Scenario | Layout | Framework | Coverage | Target contract | Expected result |\n| -------------------------- | ----------- | --------- | -------- | ----------------------------- | --------------- |\n| `app-cold-strong` | Application | Vitest | Strong | Preserve direct cold behavior | Complete |\n| `app-platform-strong` | Application | Mocha | Strong | Intentional platform sharing | Complete |\n| `library-mixed-strong` | Library | Jest | Strong | Mixed approved contracts | Complete |\n| `library-weak-unsupported` | Library | Vitest | Weak | Unsupported behavior retained | Safe stop |\n\nTogether they cover positive evidence plus a negative or refusal control for:\n\n- `ColdObservable` producer independence;\n- platform activation, sharing, ref counting, final abort, and restart;\n- Subjects and late observers;\n- cancellation and abort ownership;\n- teardown order;\n- scheduling and timing;\n- error delivery;\n- iterable, async iterable, Promise, custom-subscribable, and legacy interop;\n- repeated subscriptions and cache behavior;\n- unsupported APIs;\n- missing coverage; and\n- mixed supported and unsupported pipelines.\n\nThe held-out baseline suite loads the exact RxJS `7.8.1` runtime from the\nworkspace's pinned pnpm store path rather than resolving the workspace RxJS\nNext package.\n\n## Outcome gates\n\nThe versioned agent grader evaluates 14 semantic gate families and fails a run\nwhen any family fails:\n\n1. compilation;\n2. RxJS 7 baseline integrity;\n3. baseline/characterization/migration chronology;\n4. contract-manifest readiness;\n5. required diagnostic handling;\n6. intentional-divergence disclosure and approval;\n7. protected-test integrity;\n8. required engine actions and refusals;\n9. implemented/declared manifest consistency;\n10. required artifact integrity;\n11. held-out behavior;\n12. developer-owned contract decisions;\n13. observed read, write, command, network, and install authority; and\n14. timely safe-stop behavior without later writes.\n\nThe captured-record verifier independently recomputes artifact hashes, rejects\npath escape and symlinks, checks harness/model/authority and seed identities,\nand requires the closed four-run Codex matrix. It compares semantic safety and\ndecision vectors rather than exact patches.\n\n## Live qualification matrix\n\nThe closed matrix contains one passing record for each representative\nrepository, for four qualified Codex/ChatGPT outcomes. Claude Code and Cursor\nretain tested Skill installation adapters from P0.M4 but are not live\noutcome-qualified in P0:\n\n| Scenario | Codex/ChatGPT |\n| -------------------------- | :-----------: |\n| `app-cold-strong` | ✓ |\n| `app-platform-strong` | ✓ |\n| `library-mixed-strong` | ✓ |\n| `library-weak-unsupported` | ✓ |\n\nEach run captures the user-visible prompt/final response, patch, contract\nmanifest, command results, and final report. The live command is intentionally\nnot part of ordinary CI because it invokes an external model service. Offline\ngrading of committed run artifacts is deterministic and belongs in normal\nvalidation.\n\n## Current measured result\n\nThe completed evidence passes:\n\n- 4/4 seed identities and dependency descriptors;\n- 12/12 required behavior categories with positive and negative/refusal\n controls;\n- 4/4 pinned RxJS 7 seed oracles;\n- 14/14 agent outcome gate families; and\n- four committed qualification records with 20/20 SHA-256-bound artifacts,\n plus mutation controls for digest drift, missing artifacts, and unexpected\n matrix membership.\n\nLive result: **4/4 passed** using Codex `0.146.0-alpha.3.1`,\n`gpt-5.6-sol` with medium reasoning, and Skill/engine version\n`8.0.0-alpha.14`. `app-cold-strong`, `app-platform-strong`, and\n`library-mixed-strong` completed their approved migrations;\n`library-weak-unsupported` produced the expected safe stop before target\ninstallation or migration writes.\n\n## Claim limits\n\nThis 4/4 result is a bounded qualification snapshot, not a statistical\nreliability estimate and not proof that arbitrary RxJS 7 repositories migrate\nautomatically. It supports claims only for the checked-in scenarios, versions,\ncapabilities, safety gates, retained artifacts, and recorded Codex/ChatGPT\nconfiguration. Claude Code and Cursor outcome parity remains unmeasured.\nUnsupported syntax, uncharacterized behavior, unresolved lifecycle intent,\nframework features outside the adapters, and product gaps must remain visible\nand may require a safe stop.\n","packages/migrate/docs/MIGRATION_TOOLING_DESIGN.md":"# RxJS Next agent-first migration tooling design\n\n## Executive summary\n\nRxJS 7-to-Next migration is an agent-led engineering workflow, not a codemod\nrun. The primary product is one portable Agent Skill that assesses a project,\nestablishes an RxJS 7 behavioral baseline, makes every lifecycle choice\nexplicit, invokes deterministic transforms only inside their proved boundary,\nand works with the developer until the agreed build and test gates pass or a\ndocumented blocker is accepted.\n\n`@rxjs/migrate` is the deterministic engine used by that workflow. It owns\nversioned analysis, capability data, source transforms, framework adapters,\nstructured diagnostics, and safe file operations. It never decides whether an\napplication should adopt the platform Observable's shared active producer or\nretain producer-per-direct-subscription behavior. It also never claims that a\nsyntactically transformed project is migrated.\n\nThe canonical Skill source is `packages/migrate/skill`. It is released and\nversioned with `@rxjs/migrate`. Harness-specific installation places the same\nvalidated Skill content where Codex, Claude, or Cursor discovers it; those\nplacements and their invocation/permission notes are adapters, not separately\nauthored workflows.\n\nThe current source-content MCP prototype is not part of the accepted product.\nIts two tools mirror the local library and CLI without adding a capability\nthat a local coding agent needs. P0.M3 removes that release surface. A future\nMCP requires a new decision backed by a concrete need that cannot be met by\nthe versioned CLI, library API, Skill resources, or the host agent's local\ntools.\n\n## Status and audience\n\nThis document is the controlling product and technical design for P0.M3\nthrough P0.M5. Its primary audience is RxJS maintainers implementing and\nqualifying the migration experience. Skill authors, framework-adapter authors,\nand release reviewers are secondary audiences.\n\nThe design distinguishes:\n\n- **Accepted product direction:** the contracts in this document and D-046.\n- **Historical prototype:** the P0.M1 `@rxjs/migrate` package and its former\n independently authored Skill/MCP experiments.\n- **Completed P0 evidence:** implementation fixtures in P0.M3, three-harness\n installation/discovery checks in P0.M4, and Codex/ChatGPT representative\n repository evaluations in P0.M5.\n\nNo statement here turns the current prototype's nine tests into general\nmigration evidence or promises that every RxJS 7 application can be migrated\nautomatically.\n\n## Product principles\n\n1. **Behavior before syntax.** A passing RxJS 7 baseline and explicit target\n contract precede broad source rewriting.\n2. **No silent lifecycle choice.** The agent must not infer platform sharing\n or producer-per-direct-subscription behavior from an operator name,\n directory, or currently passing output.\n3. **Mechanical work stays bounded.** The engine transforms only versioned,\n fixture-proved syntax and reports everything else.\n4. **The destination owns the result.** Migrated code and characterization\n tests become ordinary project source, not generated runtime artifacts.\n5. **Outcome gates outrank source shape.** Agent changes may vary in form; the\n declared contract, compilation, tests, diagnostics, and intentional\n divergences must not vary.\n6. **One workflow, thin harness adapters.** Codex, Claude, and Cursor use the\n same Skill body and validation assets.\n7. **Human authority is explicit.** Ambiguous intent, weakened coverage,\n unsupported behavior, and accepted divergences require a developer\n decision.\n\n## Developer job and paved road\n\n### Persona and job to be done\n\nThe primary user is an application or library maintainer responsible for an\nRxJS 7 codebase. They need to reach an intentional RxJS Next contract without\nlosing behavior that the existing test suite did not happen to cover.\n\nThe paved road begins with a working repository and ends with:\n\n- the agreed build, type, lint, and test gates passing;\n- a checked-in target-contract manifest;\n- reviewed diagnostics and intentional divergences;\n- ordinary project-owned migrated source and tests; and\n- a remaining-blocker record when the developer deliberately accepts work\n that cannot yet be completed.\n\n### Journey and gates\n\n#### 1. Discover and establish authority\n\nThe agent locates repository instructions, package-manager metadata, RxJS\nversions, workspaces, build/test commands, CI configuration, and the current\nworking-tree state. It states the files and commands it proposes to use before\nwriting broadly.\n\nEntry gate:\n\n- the repository is accessible and its local instructions are known.\n\nExit gate:\n\n- the migration scope, allowed writes, package manager, and candidate\n verification commands are recorded.\n\nThe agent must stop if it cannot distinguish the intended repository, cannot\nprotect existing changes, or needs authority for destructive or external\nactions.\n\n#### 2. Assess versions, usage, and coverage\n\nThe agent inventories:\n\n- installed RxJS versions and import forms;\n- Observable construction, custom producers, Subjects, subscriptions,\n schedulers, testing utilities, interop inputs, and repeated subscriptions;\n- direct and transitive operator usage;\n- test frameworks and coverage around lifecycle-sensitive paths; and\n- build/type/test commands that currently exercise those paths.\n\nThe result is a risk report, not a transform plan. Every finding links to\nsource evidence and one or more migration themes.\n\nExit gate:\n\n- every in-scope lifecycle-sensitive use is either covered by an existing\n baseline, selected for characterization, explicitly unsupported, or accepted\n by the developer as an uncovered risk.\n\n#### 3. Establish the RxJS 7 baseline\n\nThe agent runs the agreed checks before changing dependencies or source. A\nfailing starting gate is diagnosed and recorded; it is never silently treated\nas a migration regression.\n\nWhen existing coverage is insufficient, the agent proposes focused\ncharacterization tests against RxJS 7. These tests protect observable values,\nterminal behavior, producer multiplicity, cancellation, teardown ordering,\ntiming, errors, and subscription effects relevant to the selected code.\n\nExit gate:\n\n- agreed baseline commands pass on RxJS 7, or the developer explicitly accepts\n named pre-existing failures; and\n- every newly added characterization test passes before migration begins.\n\n#### 4. Classify the intended Next contract\n\nThe agent creates or updates the target-contract manifest described below.\nEach migration unit receives one target lifecycle and one evidence\nclassification. `unresolved` is a stop state, not a default the transformer may\nresolve.\n\nExit gate:\n\n- the developer has approved every ambiguous lifecycle choice and intentional\n divergence needed for the current batch.\n\n#### 5. Plan and dry-run mechanical changes\n\nThe agent selects only engine capabilities whose versioned evidence matches\nthe source form and approved contract. It runs analysis and transforms without\nwrites first, then presents changed-file scope and structured diagnostics.\n\nExit gate:\n\n- no unresolved or refusal diagnostic is hidden;\n- the proposed output stays within authorized paths; and\n- the developer has approved any batch whose size or semantic reach exceeds\n the previously reviewed scope.\n\n#### 6. Apply a small migration batch\n\nThe agent applies one coherent batch, formats it through the project's normal\ntools, and keeps migrated files as ordinary source. It does not add a runtime\ngenerator, compatibility assertion layer, or unreviewed local operator to make\nthe batch pass.\n\nExit gate:\n\n- the batch parses and type-checks at the narrowest useful boundary;\n- deterministic transforms are idempotent; and\n- all diagnostics are resolved, carried forward, or escalated.\n\n#### 7. Build, test, diagnose, and repair\n\nThe agent runs the narrowest relevant checks, then the agreed project gates.\nIt separates:\n\n- migration defects, which it repairs;\n- RxJS Next product gaps, which it reports without disguising;\n- intentional divergences, which require approved expectations; and\n- environment or baseline failures, which retain their original status.\n\nThe loop continues in reviewable batches until green or until the developer\naccepts a documented blocker. Tests may be strengthened but never weakened\nmerely to obtain green output.\n\n#### 8. Close out and hand off\n\nThe agent records final commands and results, changed contracts, unsupported\nbehavior, intentional divergences, remaining blockers, and the installed Skill\nand engine versions. A migration is not complete while required gates are\nunknown, skipped without approval, or red for an unexplained reason.\n\n## Target-contract protocol\n\n### Separate lifecycle from evidence classification\n\nEvery migration unit records both fields. They answer different questions.\n\nTarget lifecycle:\n\n| Value | Meaning |\n| ---------------------------------- | ---------------------------------------------------------------------------------------------- |\n| `platform-shared` | Use the active platform Observable with one shared, ref-counted producer while observers exist |\n| `producer-per-direct-subscription` | Use an explicit Next API such as `ColdObservable` that creates producer work per direct call |\n| `subject-hot` | Use an intentional Subject API whose producer exists before observers subscribe |\n| `not-applicable` | The unit has no Observable producer lifecycle |\n| `unsupported` | The accepted Next surface does not provide the required behavior |\n| `unresolved` | Developer intent or product policy is unknown; the agent must stop |\n\nEvidence classification uses the compatibility policy's existing values:\n`portable`, `harness-rewrite`, `compatibility-only`,\n`intentional-divergence`, or `unsupported-or-obsolete`.\n\nThe engine may suggest review flags but cannot promote `unresolved` to a\ntarget lifecycle or approve an intentional divergence.\n\n### Contract manifest\n\nThe checked-in manifest is structured data with a human-readable summary. Its\nschema is versioned with `@rxjs/migrate` and contains at least:\n\n| Field | Required content |\n| ------------------------ | ----------------------------------------------------------------------------------------- |\n| `schemaVersion` | Exact manifest schema |\n| `engineVersion` | `@rxjs/migrate` version used for analysis and transforms |\n| `skillDigest` | Digest of the canonical Skill content |\n| `sourceRxjsVersion` | Exact RxJS 7 version or range observed in the project |\n| `targetRxjsVersion` | Exact RxJS Next version under evaluation |\n| `baseline` | Commands, environment, result, and accepted pre-existing failures |\n| `units` | Stable IDs, source locations, lifecycle, evidence class, claims, and approval state |\n| `diagnostics` | Structured unresolved, refused, unsupported, and informational findings |\n| `intentionalDivergences` | Old claim, approved Next claim, user impact, evidence, and developer approval |\n| `verification` | Required commands and final results |\n| `blockers` | Owner, reason, affected units, evidence, and explicit acceptance when work ends non-green |\n\nThe manifest records decisions and evidence; it is not an input that can\noverride the engine's safe path or capability checks.\n\n### Mandatory escalation cases\n\nThe agent pauses for the developer when:\n\n- repeated subscriptions could mean independent work, refresh/retry behavior,\n sharing, or caching and intent is not proved;\n- source behavior could reasonably map to either the platform Observable or\n `ColdObservable`;\n- a Subject's replay, terminal, or late-observer behavior is not covered;\n- the change would remove or reinterpret scheduler-sensitive ordering;\n- teardown order, abort reason, or unhandled-error behavior could change;\n- a custom subscribable or interop protocol is outside `Observable.from`;\n- a transform would drop an unsupported overload or assertion;\n- existing tests are missing or failing in the affected area;\n- a proposed repair weakens an expectation or changes public behavior; or\n- completing the work requires broader writes, dependency changes, network\n access, or destructive action beyond the approved scope.\n\n## Product boundaries\n\n### Portable Agent Skill\n\nThe Skill is the primary user experience. It owns:\n\n- journey orchestration and stop conditions;\n- repository and coverage assessment;\n- target-contract elicitation and manifest maintenance;\n- choosing when a deterministic engine operation is allowed;\n- review batching and repair-loop behavior;\n- classification of migration, product, environment, and intentional\n divergence outcomes; and\n- final evidence and blocker reporting.\n\nIt does not copy mutable capability mappings into prose. It consumes the\ninstalled engine's machine-readable capability and schema outputs.\n\n### `@rxjs/migrate`\n\nThe package owns deterministic, versioned behavior:\n\n- parse and usage analysis;\n- capability and argument-adapter data;\n- source and test transforms;\n- optional test-framework syntax adapters;\n- structured findings and refusal diagnostics;\n- contract-manifest schema validation;\n- dry-run/write equivalence and safe path containment; and\n- Skill installation, synchronization, and content verification.\n\nThe package does not own:\n\n- target-lifecycle decisions;\n- approval of intentional divergences;\n- general code repair;\n- repository-wide test strategy;\n- claims beyond its executable fixtures; or\n- completion of an end-to-end migration.\n\n### CLI and library API\n\nThe CLI and library are two interfaces to the same engine. Given the same\nsource, options, capability version, and framework adapter, they return the\nsame changed content and structured diagnostics. The CLI is dry-run-first and\nmachine-readable; writes require an explicit flag and contained destination.\n\n### Framework adapters\n\nFramework adapters translate only framework syntax and configuration they\nexplicitly support. They do not select an Observable lifecycle, change RxJS\nsemantics, or add assertion compatibility layers. Preserving the project's\ncurrent framework remains the default.\n\n### MCP decision\n\nNo MCP server is in the accepted release architecture. The P0.M1 prototype\naccepts source text and returns the same analysis or transform available from\nthe local API. That indirection does not justify a second versioned protocol,\nruntime dependencies, installation path, permission model, or validation\nmatrix.\n\nA future proposal must identify at least one necessary capability that cannot\nbe provided adequately by the CLI, library, Skill resources, or host agent\ntools. It must then define separate authentication, authority, privacy,\nversioning, offline, error, and evaluation contracts. Convenience or protocol\nsymmetry alone is insufficient.\n\n## Canonical Skill and distribution\n\n### One authored source\n\n`packages/migrate/skill` is the only authored Skill source. Its content digest\nis included in the package and contract manifest. The Skill and engine share\nthe package version so instructions cannot silently describe a different\ncapability registry or schema.\n\nThe earlier `.agents/skills/rxjs-next-marble-migration` tree remains valuable\nP0.T2 history in Git, but it is no longer a second authored source. P0.M4\nmerged its still-valid guidance into the canonical Skill and replaced it with\nthe validated `.agents/skills/rxjs-next-migration` generated copy.\n\n### Installation model\n\nProjects add an exact or intentionally ranged development dependency on\n`@rxjs/migrate`. A package command then installs or synchronizes the canonical\nSkill into the selected harness discovery location and writes a small\nprovenance record containing package name, version, content digest, and target\npath. Installed copies are generated distribution artifacts; maintainers edit\nonly `packages/migrate/skill`.\n\nThe installer must support check-only, install, update, and remove operations;\nmust refuse to overwrite a locally modified target without explicit approval;\nand must work without symlink privileges. A symlink may be offered when the\nharness and platform support it, but it is not the only path.\n\n### Harness adapters\n\nThe `rxjs-migrate-skill` command implements the required behavior:\n\n| Harness | Discovery target | Invocation | Adapter responsibility |\n| ------- | --------------------------------------------- | ---------------------------------------------- | --------------------------------------------------------------------------------------- |\n| Codex | `.agents/skills/rxjs-next-migration/SKILL.md` | `$rxjs-next-migration` or implicit description | Install/sync the canonical bytes; document sandbox and approval settings |\n| Claude | `.claude/skills/rxjs-next-migration/SKILL.md` | `/rxjs-next-migration` or implicit description | Install/sync the canonical bytes; omit Claude-only frontmatter from the portable source |\n| Cursor | `.agents/skills/rxjs-next-migration/SKILL.md` | `/rxjs-next-migration` or implicit description | Use the open Skill path; verify editor and CLI discovery |\n\nIf a harness requires metadata not in the open Agent Skills format, the\nadapter stores that metadata beside the installed Skill. It must not fork the\nworkflow body.\n\n### Permissions\n\nThe portable Skill declares workflow needs, not blanket authority. A host\nadapter documents how to grant:\n\n- read access to the selected repository;\n- write access only to the reviewed project paths;\n- local execution of the project's declared package-manager, build, and test\n commands; and\n- network or package-install access only when the developer approves it.\n\nThe workflow never needs production credentials or project-level MCP write\nauthority. Destructive actions and external publication remain outside the\ndefault migration permission set.\n\n### Updates and discovery verification\n\nUpdating means updating `@rxjs/migrate`, running Skill synchronization, and\nchecking that the installed digest matches the package. Each harness smoke\ntest must prove:\n\n1. the Skill is discovered from a clean fixture;\n2. explicit invocation reaches the canonical workflow;\n3. an implicit trigger is recognized when enabled;\n4. required local tools are requested rather than assumed; and\n5. a stale or locally modified installed copy is reported clearly.\n\nP0.M4 rechecked the official references on 2026-07-31 and records the exact\ncommands, permissions, update flow, smoke scenario, and locally inspected host\nversions in `MIGRATION_SKILL_GUIDE.md`. Harness discovery and permission\nbehavior can change independently of RxJS and must be rechecked before release.\n\n## Fixture and evaluation specification\n\n### Two evidence lanes\n\nDeterministic engine behavior and nondeterministic agent outcomes use separate\nfixtures and gates.\n\n```mermaid\nflowchart LR\n Source[\"Pinned RxJS 7 source\"] --> Mechanical[\"Deterministic engine fixtures\"]\n Mechanical --> Output[\"Content, diagnostics, compile, idempotence, behavior\"]\n Source --> Agent[\"Agent workflow evaluation\"]\n Agent --> Contract[\"Contract manifest and reviewed changes\"]\n Contract --> Gates[\"Build, type, lint, tests, divergences, blockers\"]\n```\n\nAn exact golden file can prove deterministic output. It cannot prove an agent\nmade the correct lifecycle choice. Conversely, a green end-to-end repository\ndoes not prove every codemod branch is deterministic or path-safe.\n\n### Mechanical fixture schema\n\nEvery engine fixture records:\n\n- stable fixture ID and behavior category;\n- exact input files and parser/compiler options;\n- source RxJS and target Next versions;\n- migration mode and capability-registry version;\n- framework adapter and options;\n- expected changed paths;\n- exact output where formatting is contractual, otherwise explicit structural\n invariants;\n- ordered diagnostics with classification, severity, source span, and\n suggested next action;\n- expected parse and type results;\n- idempotence expectation; and\n- executable pre- and post-migration behavioral claims.\n\nSuccessful-fixture gates:\n\n1. input parses in its declared source environment;\n2. output parses and type-checks in the declared target environment;\n3. a second transform produces no change and identical diagnostics;\n4. CLI and API results agree;\n5. dry-run and write modes agree byte-for-byte;\n6. writes remain inside the declared destination;\n7. source behavior passes on RxJS 7;\n8. target behavior passes for the approved Next contract; and\n9. the fixture's diagnostic and output expectations pass.\n\nNegative controls must prove that the gate fails for output drift, a missing\ndiagnostic, a non-idempotent transform, a compile regression, behavior drift,\npath escape, unsupported syntax reported as success, and a CLI/API mismatch.\n\n### Agent evaluation schema\n\nEach agent fixture records:\n\n- stable scenario ID and repository category;\n- pinned repository revision and dependency lock;\n- harness, agent/model configuration, Skill version/digest, and engine version;\n- allowed tools, permissions, network policy, time/task bounds, and clean-room\n setup;\n- starting RxJS 7 commands and results;\n- seeded coverage gaps and expected characterization recommendations;\n- required target-contract units and developer decision points;\n- allowed implementation variation;\n- required diagnostics, refusals, and escalations;\n- intentional divergences and their approval records;\n- final build/type/lint/test gates; and\n- artifact capture for the conversation, manifest, patch, command results, and\n final report.\n\nAgent output is not compared as one golden patch. A run passes only when:\n\n- the baseline is established honestly;\n- required risks and weak coverage are surfaced;\n- the agent does not choose an ambiguous lifecycle automatically;\n- characterization tests pass on RxJS 7 before dependency/source migration;\n- deterministic transforms are used only for supported inputs;\n- no required test is weakened, skipped, or deleted without approval;\n- the final manifest matches the implemented contracts;\n- every agreed gate passes or a named blocker is explicitly accepted; and\n- the final report distinguishes migration defects, product gaps,\n divergences, and environment limits.\n\n### Required behavior categories\n\nMechanical fixtures and agent scenarios collectively cover:\n\n| Category | Required evidence |\n| --------------------------------- | ------------------------------------------------------------------------------------------- |\n| `ColdObservable` | Independent direct subscriptions, duplicated side effects, cancellation, and Symbol results |\n| Platform sharing and ref counting | First activation, late join, individual abort, final abort, restart, and shared state |\n| Subjects | Hot producer, current/replayed values, terminal state, read-only views, and late observers |\n| Cancellation | Captured subscriptions rewritten to signal ownership, abort reasons, and upstream closure |\n| Teardown order | Reverse platform teardown ordering and order-sensitive characterization |\n| Scheduling and timing | Host-time mappings, unsupported scheduler forms, ordering, and virtual-time evidence |\n| Errors | Observer callback errors, late/unhandled errors, selector errors, and terminal preservation |\n| Input conversion | Iterables, async iterables, Promises, custom subscribables, and legacy interop refusal |\n| Repeated subscriptions | Retry, refresh, cache invalidation, producer multiplicity, and restart |\n| Unsupported APIs | Visible diagnostics, retained evidence, no invented compatibility layer |\n| Missing coverage | Characterization recommendation and refusal to claim safety |\n| Mixed pipelines | Supported transforms around unsupported operators without dropping the unsupported segment |\n\nEach category needs at least one passing case and one negative or refusal\ncontrol. P0.M5 expands these units into representative application and library\nrepositories.\n\n## P0.M2 prototype audit\n\nP0.M1 established useful boundaries but not release-grade evidence:\n\n- `packages/migrate/src/index.ts` separates semantic and framework transforms.\n- `packages/migrate/src/cli.ts` is dry-run-first.\n- `packages/migrate/src/types.ts` exposes structured but limited diagnostics.\n- `packages/migrate/skill` contained a thin package Skill.\n- `.agents/skills/rxjs-next-marble-migration` contained the earlier, more\n detailed repository Skill.\n- `packages/migrate/src/mcp.ts` mirrored source-content analysis and migration.\n- the package had nine test registrations and one source fixture;\n the fixture is not a comprehensive executable matrix.\n\nKnown gaps assigned to P0.M3 or P0.M4 include:\n\n- no comprehensive mapping, aliasing, shadowing, malformed-input, compile,\n idempotence, behavior, CLI/API-equivalence, or path-containment fixtures;\n- no versioned target-contract manifest;\n- no agent-first repository assessment or repair loop in the bundled Skill;\n- independently authored Skill content that can drift;\n- no tested install/update/remove flow across the three harnesses; and\n- an MCP surface and dependencies with no accepted release responsibility.\n\nThese are scope facts, not implementation failures against a contract that\nP0.M1 had already claimed.\n\n## Implementation handoff\n\n### P0.M3 — deterministic engine hardening\n\nP0.M3 implements the package-owned pieces of this design:\n\n- machine-readable capability and contract-manifest schemas;\n- structured diagnostics with spans, severity, refusal state, and next action;\n- comprehensive mechanical fixtures and negative controls;\n- parse, compile, idempotence, behavior, CLI/API, dry-run/write, containment,\n import, and pack gates;\n- Skill digest and synchronization primitives needed by P0.M4; and\n- removal of MCP bins, exports, runtime dependencies, tests, and claims.\n\nP0.M3 does not install cross-harness adapters or claim agent workflow\nqualification.\n\n### P0.M4 — portable Skill and harness adapters\n\nP0.M4 merges the reusable P0.T2 guidance into `packages/migrate/skill`, expands\nit to the complete journey, and makes it consume engine data rather than prose\ncopies. It implements and tests installation, discovery, invocation,\npermissions, update, drift, and removal for Codex, Claude, and Cursor.\n\nThe completed implementation ships the `rxjs-migrate-skill` command and\n`@rxjs/migrate/skill` API, copy-only atomic adapters, embedded provenance, and\none shared Codex/Cursor placement plus Claude's native placement. The package\nsuite proves canonical byte identity and safe lifecycle behavior across all\nthree adapters. The repository's generated copy keeps natural Codex and Cursor\ninvocation available after the independently authored P0.T2 tree is removed.\n\n### P0.M5 — representative qualification\n\nP0.M5 evaluates clean pinned repositories across application/library layouts,\nframeworks, coverage levels, lifecycle choices, and unsupported behavior. It\npublishes measured outcomes and limitations rather than a blanket automatic\nmigration claim.\n\nThe live matrix, offline outcome gates, current measured evidence, and claim\nlimits are tracked in\n[`MIGRATION_QUALIFICATION.md`](MIGRATION_QUALIFICATION.md).\nThe completed Codex-only\nmatrix passes 4/4: three approved migrations completed and the\nweak-coverage/unsupported scenario made its required safe stop. Codex\n`0.146.0-alpha.3.1`, `gpt-5.6-sol` at medium reasoning, and Skill/engine\n`8.0.0-alpha.14` are part of the claim boundary. The verifier binds four\nrecords to 20 hashed artifacts and 14 semantic gate families.\n\nThe retained conversation artifact is the exact user prompt plus final\nresponse, not necessarily the complete host event stream. Exact commands and\nresults, file changes, and observed authority are retained separately in the\ncommand-results artifact, patch, and qualification record. Full event streams\nwere not retained for the first three runs. This evidence boundary is explicit\nso a future requalification can strengthen capture without overstating the P0\nrecords.\n\n## Risks and controls\n\n| Risk | Control |\n| ----------------------------------------- | -------------------------------------------------------------------------------------------- |\n| Green output hides a lifecycle change | Baseline, characterization tests, explicit target manifest, and shared/cold fixtures |\n| Capability prose drifts from the engine | Skill consumes versioned machine-readable data and shares the package version |\n| Harness instructions diverge | One canonical Skill digest; generated placements; per-harness smoke tests |\n| Agent weakens tests to finish | Outcome grader rejects unapproved skips, deletions, and weaker expectations |\n| Codemod writes outside scope | Resolve-and-contain checks plus path-escape negative controls |\n| Nondeterminism masks regressions | Judge contracts and outcomes; retain the five declared hashed artifacts and authority record |\n| MCP becomes an unsupported second product | Remove the prototype surface; require a new evidence-backed decision to reintroduce it |\n| Harness behavior changes after release | Re-verify official discovery/permission paths during P0.M4 and before each supported claim |\n\n## Completion criteria for the migration product\n\nThe migration experience is release-ready only when:\n\n- P0.M3 mechanical fixtures prove every documented transform and refusal;\n- P0.M4 uses one canonical Skill and passes all harness discovery and\n permission smoke tests;\n- P0.M5 representative repositories pass their declared outcome gates;\n- any outcome claim names its harness/model boundary and retained evidence;\n- measured limitations and unsupported surfaces are published;\n- no migration is called complete based only on transformed source shape; and\n- no MCP or other secondary orchestration surface is claimed without its own\n accepted contract and evidence.\n\n## References\n\nRepository sources:\n\n- `PROJECT_CHARTER.md`\n- `ARCHITECTURE.md`\n- `DECISIONS.md`\n- `PROJECT_PLAN.md`\n- `COMPATIBILITY.md`\n- `TESTING_DESIGN.md`\n- `packages/migrate`\n- `.agents/skills/rxjs-next-migration`\n\nCurrent harness references reviewed for P0.M2:\n\n- [OpenAI: Build skills](https://learn.chatgpt.com/docs/build-skills)\n- [Claude Code: Extend Claude with skills](https://code.claude.com/docs/en/slash-commands)\n- [Cursor 2.4: Agent Skills](https://cursor.com/changelog/2-4)\n- [Agent Skills open standard](https://agentskills.io)\n","packages/migrate/skill/SKILL.md":"---\nname: rxjs-next-migration\ndescription: Migrate an RxJS 7 application, library, or test suite to RxJS Next through an agent-led workflow that establishes a green behavioral baseline, makes Observable lifecycle choices explicit, uses @rxjs/migrate only for bounded fixture-proved rewrites, repairs without weakening evidence, and records a versioned migration contract. Use for repository assessment, migration planning or execution, lifecycle review, TestScheduler conversion, or migration closeout.\n---\n\n# RxJS 7 to RxJS Next migration\n\nTreat this as reviewed project work, not a codemod run. The objective is an\nintentional RxJS Next contract backed by the project's own build and behavior\nevidence. A transformed file, a clean diff, or one passing test is not proof\nthat the migration is complete.\n\nWork through all eight stages in order. Re-enter an earlier stage whenever new\nevidence changes scope, coverage, or lifecycle intent. Keep the developer\ninvolved at every explicit pause.\n\n## Non-negotiable rules\n\n- Read and obey repository-local instructions before acting. Protect existing\n work and stay within the authorized repository and paths.\n- Establish the RxJS 7 baseline before changing dependencies or source.\n- Never infer platform sharing versus producer-per-direct-subscription behavior\n from syntax, filenames, operator names, or a currently passing output.\n- Use the installed engine's versioned registry and schemas as authority. Do\n not reconstruct capability mappings from this Skill or from memory.\n- Run the deterministic engine without writes first. A refusal is a successful\n safety outcome, not permission to improvise a mechanical rewrite.\n- Preserve the project's test framework by default. Select a framework adapter\n only when the developer asked for that separate conversion.\n- Do not weaken, skip, delete, or replace a behavioral expectation merely to\n make the migrated suite green.\n- Do not add RxJS 7 compatibility shims, string-named platform methods, local\n substitute operators, or runtime generators unless the developer separately\n authorizes that product work.\n- Keep changes in small coherent batches. Review and verify each batch before\n widening the scope.\n- Do not call a migration complete while a required command is unknown,\n unapproved, skipped, or red without an explicitly accepted blocker.\n\n## Working record\n\nCreate or locate a checked-in migration contract manifest and a concise\nhuman-readable report. Use the schema exported by the installed\n`@rxjs/migrate`; schema validity and migration readiness are separate checks.\nUse [assets/migration-report.md](assets/migration-report.md) for the report.\n\nFor every migration unit, preserve source locations and record:\n\n- its current RxJS 7 behavioral claim;\n- the target lifecycle selected by the developer;\n- its evidence classification and supporting tests;\n- approval state, diagnostics, and any intentional divergence; and\n- verification or a named blocker.\n\n## Stage 1: Establish authority and scope\n\n1. Locate repository instructions, package and workspace metadata, lockfiles,\n CI configuration, RxJS versions, build/test commands, and current working\n tree state.\n2. Identify the repository root, migration boundary, permitted writes,\n package manager, network policy, and candidate verification commands.\n3. Record the installed `@rxjs/migrate` version and canonical Skill digest.\n If the installed Skill does not match its package, stop and synchronize it\n before trusting these instructions.\n4. State the proposed read, write, dependency, and command scope before broad\n changes.\n\nPause for the developer if the target repository or allowed scope is unclear,\nexisting changes overlap the migration, or destructive, networked, external,\nor broader actions require new authority.\n\nExit only when the scope, allowed writes, package manager, and candidate gates\nare recorded.\n\n## Stage 2: Assess usage, lifecycle risk, and coverage\n\nInventory installed RxJS versions and import forms, then locate Observable\nconstruction, custom producers, Subjects, subscription ownership, repeated\nsubscriptions, retry/refresh/cache paths, schedulers and timing, test helpers,\ninterop inputs, cancellation, teardown, and error handling. Include direct and\ntransitive operator usage.\n\nFor each lifecycle-sensitive path, link exact source evidence and mark it as:\n\n- covered by an existing baseline;\n- requiring a characterization test;\n- explicitly unsupported; or\n- an uncovered risk the developer accepts.\n\nProduce a risk and coverage report before proposing rewrites. Read\n[references/assessment-and-contract.md](references/assessment-and-contract.md)\nfor the inventory and characterization protocol.\n\nExit only when every in-scope lifecycle-sensitive use has one recorded\ncoverage disposition. Missing coverage is not evidence that behavior is safe.\n\n## Stage 3: Establish the green RxJS 7 baseline\n\nRun the agreed build, type, lint, unit, integration, and behavior checks against\nthe unchanged RxJS 7 project. Record exact commands, environment facts, exit\ncodes, and concise results.\n\nAdd focused characterization tests where Stage 2 found material gaps. Protect\nobservable values, completion/error behavior, producer multiplicity,\ncancellation, abort reasons, teardown ordering, timing, and externally visible\nsubscription effects as applicable. Every characterization test must pass on\nRxJS 7 before migration begins.\n\nPause if a starting gate fails. Diagnose it and ask the developer whether to\nfix it first, narrow scope, or record it as an accepted pre-existing failure.\nNever silently reclassify it as a migration regression or ignore it.\n\nExit only with a green baseline or explicit approval for each named\npre-existing failure, plus green characterization tests.\n\n## Stage 4: Classify and approve the target contract\n\nDivide the scope into stable migration units. For each unit, record one target\nlifecycle using the values accepted by the installed manifest schema and one\nevidence classification. Use repository evidence and\n[references/assessment-and-contract.md](references/assessment-and-contract.md)\nto explain the choice.\n\nThe engine may identify risk but cannot choose lifecycle intent. `unresolved`\nis a stop state. Pause for the developer when either platform-shared behavior\nor producer-per-direct-subscription behavior is plausible, or when Subject\nsemantics, cancellation, scheduler ordering, error behavior, interop, or a\npublic behavior change is not proved.\n\nIntentional divergences require a concrete old claim, proposed Next claim,\nuser impact, evidence, and developer approval. Validate the manifest\nstructurally, then run the installed readiness assessment. Do not proceed with\na batch containing unresolved intent or required pending approval.\n\nExit only when the developer has approved every ambiguous choice and\nintentional divergence needed for the next batch.\n\n## Stage 5: Plan and dry-run bounded engine changes\n\nInspect the installed capability registry and select only entries whose\nversion, source form, arity, preconditions, and executable evidence match the\napproved unit. Do not infer support from a familiar name. Follow\n[references/engine-and-batches.md](references/engine-and-batches.md).\nWhen the batch contains RxJS 7 marble tests, also read\n[references/test-migration.md](references/test-migration.md).\n\nRun `rxjs-migrate` without `--write` using explicit provenance and, when\nrequired, the approved `cold` or `platform` mode. Preserve the current test\nframework unless a supported adapter was separately selected. Capture the\nversioned JSON report, changed paths, structured diagnostics, and exit code.\n\nPause when a diagnostic requires review or refuses a transform, when output\nwould escape authorized paths, when source does not match the capability\nevidence, or when batch size or semantic reach exceeds the reviewed scope.\nNever conceal unsupported segments inside a partially transformed pipeline.\n\nExit only after diagnostics and changed-file scope are reviewed and the\ndeveloper has approved any newly broadened batch.\n\n## Stage 6: Apply one small migration batch\n\nApply only the reviewed dry-run plan. Require an explicit write destination\ninside the authorized project and preserve source provenance. Do not overwrite\nexisting output without specific approval. Review the resulting diff before\nadditional edits.\n\nFormat through the project's normal tools. Ensure ordinary project-owned\nsource and direct test declarations remain; do not leave dynamic generators,\nhidden case registries, or compatibility assertion layers in the result.\n\nImmediately check parsing, the narrowest useful type boundary, and engine\nidempotence. Re-running the same transform must produce no new source change\nand stable diagnostics. If it does not, restore the affected batch to the\nreviewed starting point and report an engine defect.\n\nExit only when the batch parses, type-checks at its narrow boundary, is\nidempotent, and every diagnostic is resolved, carried forward, or escalated.\n\n## Stage 7: Build, test, diagnose, and repair\n\nRun focused characterization and migrated tests first, then the agreed project\ngates. Classify every failure as a migration defect, RxJS Next product gap,\nintentional divergence, environment/baseline issue, or still-unknown result.\nUse [references/verification-and-closeout.md](references/verification-and-closeout.md)\nfor the repair rules.\n\nRepair migration defects in a small batch and repeat the relevant gates. For a\nproduct gap, preserve the failing evidence and report it; do not disguise it\nwith a local replacement. For an intentional divergence, change an expectation\nonly after the manifest records approved new behavior and user impact.\n\nPause before any repair that changes public behavior, weakens evidence,\nexpands writes, changes dependencies beyond the reviewed plan, needs external\naccess, or introduces a compatibility layer.\n\nExit only when agreed gates pass or each remaining red result has a named,\nevidenced, explicitly accepted blocker.\n\n## Stage 8: Close out and hand off\n\nUpdate the contract manifest and report with exact source and target versions,\nengine version, capability-registry version, canonical Skill digest, baseline,\nunits, diagnostics, divergences, final commands/results, and blockers. Validate\nthe manifest with the installed schema and assess readiness separately.\n\nReview [references/review-checklist.md](references/review-checklist.md). Report:\n\n1. what behavior and lifecycle contract changed;\n2. what source and tests changed;\n3. the exact gates run and their results;\n4. migration defects repaired versus product gaps retained;\n5. approved divergences and environment limitations; and\n6. remaining blockers, owners, evidence, and acceptance.\n\nClaim completion only when readiness is `ready`, or\n`ready-with-accepted-blockers` when the developer intentionally chose that\noutcome. Otherwise hand off the migration as incomplete with the next concrete\ndecision or action.\n","packages/observable-polyfill/README.md":"# `@rxjs/observable-polyfill`\n\nConditional fallback for the web-platform Observable and Subscriber contracts\nused by RxJS 9.\n\n```sh\nnpm install @rxjs/observable-polyfill@next\n```\n\n```ts\nimport '@rxjs/observable-polyfill';\n```\n\nThe package preserves an existing callable `globalThis.Observable`. When the\nrealm has no implementation, it installs the RxJS fallback together with its\npaired Subscriber and supported platform methods. It does not probe a native\nimplementation for conformance, replace it, or make the platform Observable\nbehave like an RxJS 7 cold Observable.\n\nUse `getObservablePolyfillInfo()` when diagnostics need to distinguish the\nRxJS fallback from a native or foreign constructor:\n\n```ts\nimport { getObservablePolyfillInfo } from '@rxjs/observable-polyfill';\n\nconsole.log(getObservablePolyfillInfo()); // metadata for the RxJS fallback, or undefined\n```\n\nCancellation and teardown use `AbortSignal` and Subscriber lifecycle. The\npackage also conditionally supplies the supported `EventTarget.when()` surface\nwithout replacing an existing callable implementation.\n\nThe package requires Node 22.13+ and publishes one ESM implementation for\nbrowser, Webpack, import, and Node `require(esm)` resolution. Observable WPT is\npinned at an exact upstream revision under `test/wpt`; the strict gate requires\ncomplete results and exact RxJS bundle identity in every fallback realm.\n\nThis package is the platform layer. RxJS operators and intentional\nproducer-per-subscription primitives belong to the\n[`rxjs` package](https://github.com/ReactiveX/rxjs/tree/master/packages/rxjs).\n","packages/observable-polyfill/test/wpt/README.md":"# Observable WPT harness\n\nThis directory runs the pinned Web Platform Tests (WPT) for the web-platform\n`Observable` against the implementation in\n`packages/observable-polyfill/src/index.ts`.\n\nThe harness is intentionally test infrastructure; conformance comes from the\nimplementation behavior it measures. The current fallback passes this pinned\nsuite. `pnpm run test:wpt` exits nonzero if any upstream test or subtest fails,\nerrors, times out, or does not run. A separately named baseline command remains\navailable for diagnosing stable behavior. Both modes are strict about\ncompleteness, provenance, and which implementation ran.\n\n## Prerequisites\n\nThe blocking WPT job runs on Node 24, and the repository engine declaration\naccepts Node 24 alongside the retained Node 18 and Node 20 development\nruntimes. pnpm 10.34.5 is the repository package manager. Confirm the\nactive versions before the first run:\n\n```sh\nnode --version\npnpm --version\n```\n\nPython 3.9 or newer is also required. `pnpm run wpt:doctor` verifies the selected\nPython interpreter and every other harness prerequisite.\n\n## What is pinned\n\n- Written Observable reference: WICG/observable `spec.bs` at\n `d74bace7cf80200a01c81cfe20961e29ac7fa3d8`. This explains the rules and helps\n diagnose failures; it is not a second executable gate.\n- WPT commit:\n `6a009d73f0d315941b90cac13a9523a2a08c631b`\n- Chrome for Testing and ChromeDriver: `150.0.7871.126`\n- WPT test URLs: `expected-test-urls.json`\n- Imported-file provenance and Git blob hashes: `provenance.json`\n- Browser archive URLs, sizes, and checksums: `browser-lock.json`\n\nOnly the 29 files in `dom/observable/tentative/`—including the\n`EventTarget.prototype.when` coverage in that directory—and this exact support\nclosure are committed:\n\n- `LICENSE.md`;\n- `common/gc.js`;\n- `interfaces/dom.idl` and `interfaces/observable.tentative.idl`;\n- `resources/testharness.js`, `resources/testharnessreport.js`,\n `resources/idlharness.js`, and the Web IDL parser file they use.\n\nThat is 37 upstream files in total. `wpt:verify-import` derives the support\nclosure from the test sources and rejects both a missing dependency and an\nunexplained extra file.\nThe much larger official WPT checkout used to run them is a sparse, shallow\ncache keyed by the WPT commit. Imported upstream files remain byte-for-byte\nunchanged under `upstream/`; all instrumentation is generated in the ignored\n`.cache/rxjs-wpt/` tree.\n\n## Proving that RxJS ran\n\nThe pinned browser is required to expose its native `Observable`,\n`Observable.prototype.subscribe`, and `EventTarget.prototype.when` in the\nwindow, dedicated-worker, and same-origin iframe realms used by this suite.\nBefore each test realm runs upstream code, the generated bootstrap:\n\n1. captures the native references and property descriptors;\n2. verifies that the native slots can be replaced in the disposable test\n realm;\n3. masks those slots and executes a synchronous bundle built directly from the\n current polyfill source;\n4. records the installed constructor, `subscribe`, and `when` identities plus\n the bundle SHA-256; and\n5. exposes a non-enumerable, test-only attestation function.\n\nEvery generated WPT URL receives exactly one named attestation subtest,\nregistered after the upstream source has established any `setup()` properties.\nThe\nreport auditor independently requires it to pass with the expected bundle hash\nand exact installed identities, and requires those identities to differ from\nthe captured native ones. For the four iframe-using URLs, that one subtest waits\nfor all nine statically reviewed child-realm accesses and verifies every child\nbefore it can pass. The auditor also rejects missing or duplicate test URLs,\nmissing worker or iframe instrumentation, different bundle identities,\nrestored native globals, and any expectation metadata that tries to allowlist\nattestation.\n\nThe iframe access patterns in the pinned suite are reviewed in `config.json`.\nChanging WPT to introduce another realm-creation pattern makes\n`wpt:verify-import` fail until that pattern and its instrumentation are\nreviewed.\n\n## Commands\n\nRun commands from the repository root:\n\n| Command | Purpose |\n| ---------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |\n| `pnpm run wpt:doctor` | Verify the vendored import, build and hash the test bundle, prepare the shadow tree, provision or verify the WPT Python environment, resolve the pinned runner/browser, and probe native exposure and replaceable descriptors. |\n| `pnpm run wpt:verify-import` | Verify provenance hashes, dependency closure, generated URL inventory, and reviewed realm patterns without running a browser. |\n| `pnpm run test:wpt` | Run every pinned URL and fail unless every upstream WPT test and subtest passes. This is the default conformance command. |\n| `pnpm run test:wpt:baseline` | Run the same attested suite but compare behavior with the checked-in known-failure baseline. This is a harness diagnostic, not conformance. |\n| `pnpm run wpt:import -- --commit <40-character-sha>` | Deliberately replace the vendored subset from an exact WPT commit and regenerate provenance and the URL inventory. |\n| `pnpm run wpt:update-expectations` | Run three complete attested suites, require identical statuses, and regenerate expectation metadata and the result baseline. |\n\nThe first browser run needs network access to populate the pinned browser and\nsparse runner caches and to create the runner's Python environment. Later runs\nreuse those exact artifacts. To prove a warm run is self-contained:\n\n```sh\nRXJS_WPT_OFFLINE=1 pnpm run test:wpt:baseline\n```\n\n`RXJS_WPT_OFFLINE=1 pnpm run test:wpt` runs strict conformance from the same\ncaches and is expected to pass for the pinned implementation and browser.\nOffline mode fails immediately if a required cached artifact is absent. Useful\ntest-only overrides are listed below. Browser runs also disable Chrome\nbackground networking, component updates, sync, metrics uploads, and pings;\nWPT test traffic remains on the official runner's local servers.\n\n| Variable | Meaning |\n| ---------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- |\n| `RXJS_WPT_CACHE_DIR` | Replace the default `.cache/rxjs-wpt` cache root. |\n| `RXJS_WPT_REPORTS_DIR` | Write run reports somewhere other than the cache's `reports/` directory. |\n| `RXJS_WPT_RUNNER_ROOT` | Use an existing WPT checkout, which must be at the pinned commit. |\n| `RXJS_WPT_PYTHON_BINARY` | Select the Python interpreter used to create the version-keyed WPT environment. |\n| `RXJS_WPT_CHROME_BINARY` and `RXJS_WPT_CHROMEDRIVER` | Use an explicit matching browser pair; both must be set. |\n| `RXJS_WPT_IMPORT_CHECKOUT` | Import from an existing WPT checkout instead of creating the temporary sparse checkout. |\n| `RXJS_WPT_ALLOW_BROWSER_DRIFT=1` | Permit a non-pinned browser version for the scheduled advisory run. Do not use this for the blocking conformance job. |\n\n## Reading results\n\nEach run writes a timestamped directory under\n`.cache/rxjs-wpt/reports/`. It contains:\n\n- `wptreport.json`: the complete structured WPT report;\n- `wpt.raw.log`: the raw log accepted by WPT's expectation updater;\n- `wpt.log`: the human-readable runner log;\n- `audit.json`: the machine-readable conformance/completeness result;\n- `status-diff.txt`: the same readable status and failure summary printed in\n the terminal;\n- `attestations.json`: the expected bundle identity recorded for every\n generated test URL.\n\nThe terminal always prints preparation and browser-execution progress, status\ncounts, attestation counts, every non-passing URL and subtest, and paths to the\nstructured report and full runner logs.\n\n`pnpm run test:wpt` succeeds only when the official runner completes, every URL\nruns exactly once, every identity attestation passes, the report is well\nformed, and every upstream result passes. `pnpm run test:wpt:baseline` retains the\nstable-result comparison for deliberate harness diagnostics. In baseline mode,\nboth an unexpected failure and an unexpected pass are mismatches. The current\nbaseline contains 52 `OK` URLs and 525 passing upstream subtests.\n\n## Updating WPT\n\nRxJS maintainers own the written-spec and WPT pins. A newer revision becomes\nthe project target only through an explicit reviewed change:\n\n1. Import an exact 40-character WPT commit with `pnpm run wpt:import -- --commit\n`.\n2. Review every vendored-file, provenance, URL-inventory, dependency-closure,\n and realm-pattern change, plus the corresponding written Observable rules.\n3. Run `pnpm run wpt:verify-import`.\n4. Update the complete-result baseline without adding any failure, skip, or\n multi-status allowance.\n5. Run `pnpm run test:wpt:baseline` and strict `pnpm run test:wpt`; both must\n report 52/52 URLs, 525/525 upstream subtests, and 52/52 exact RxJS\n attestations for the current pin, or the corresponding fully passing totals\n reviewed for the proposed pin.\n\nIf a proposed upstream revision or browser is nondeterministic or failing, it\ndoes not become the pinned target. A scheduled run against newer Chrome is\nadvisory and does not silently change the vendored tests, written reference,\nor all-pass requirement.\n\nCI runs the strict pinned conformance command as a path-filtered blocking check\nwith fixed process concurrency and a fixed wall-clock timeout. A scheduled\nadvisory job uses the current stable Chrome for Testing with browser-version\ndrift enabled. Both jobs always upload the raw report, audit, logs, URL\ninventory, and attestation identities.\n","packages/rxjs/README.md":"# `rxjs` 9 beta\n\nRxJS 9 extends the web-platform Observable with exact Symbol-keyed operators\nand factories, plus a small set of intentional RxJS primitives. It uses a\nnative `Observable` when one exists and otherwise initializes the separately\npublished `@rxjs/observable-polyfill` fallback.\n\nThis is prerelease software. Install the current beta with:\n\n```sh\nnpm install rxjs@next\n```\n\nRxJS 7 remains npm's `latest` line during the beta and continues to be\nmaintained.\n\n## Why version 9?\n\nWork on RxJS 8 began years ago and paused while Web Platform Observables were\nfinalized. RxJS 9 is a new platform-based generation, not a release of that\npaused implementation. The version communicates that architectural break and\nprevents the old RxJS 8 work from being mistaken for this product.\n\n## Use an operator\n\n```ts\nimport { ColdObservable } from 'rxjs';\nimport { map } from 'rxjs/map';\nimport { pipe } from 'rxjs/pipe';\nimport { scan } from 'rxjs/scan';\n\nconst source = new ColdObservable((subscriber) => {\n subscriber.next(1);\n subscriber.next(2);\n subscriber.next(3);\n subscriber.complete();\n});\n\nsource[pipe](\n (values) => values[map]((value) => value * 2),\n (values) => values[scan]((total, value) => total + value, 0)\n).subscribe(console.log); // 2, 6, 12\n```\n\nEach operator subpath exports its exact Symbol and installs only that\ncapability. Importing the root does not install the operator catalog.\n\n## Choose the lifecycle deliberately\n\n`new Observable(initializer)` follows the platform contract. Concurrent\nobservers share the active producer, the last observer leaving tears it down,\nand a later observer starts it again.\n\n`new ColdObservable(initializer)` creates one producer for every direct\nsubscription. Use it when producer-per-subscription behavior is part of the\napplication contract rather than assuming all Observables are cold.\n\nCancellation uses `AbortSignal`:\n\n```ts\nconst controller = new AbortController();\nsource.subscribe(console.log, { signal: controller.signal });\ncontroller.abort();\n```\n\n## ESM and Node `require()`\n\nThe package publishes one ESM implementation. Browser, Webpack, ESM import,\nand Node's `require(esm)` bridge resolve the same files and exact Symbols.\n\n```js\nconst { ColdObservable } = require('rxjs');\nconst { map } = require('rxjs/map');\n```\n\nThe bridge requires Node 22.13 or newer. It is not a CommonJS build and does\nnot support legacy CommonJS resolvers.\n\n## Documentation\n\n- [Security assurance and release verification](docs/SECURITY_ASSURANCE.md)\n- [API and import guide](docs/API.md)\n- [Migrate from RxJS 7](MIGRATION.md)\n- [Unsupported RxJS 7 surfaces](docs/UNSUPPORTED_RXJS_7_SURFACES.md)\n- [Migration evidence ledger](docs/MIGRATION_EVIDENCE_LEDGER.md)\n- [Release environments and budgets](docs/RELEASE_GATES.md)\n- [Beta.0 approval record](docs/PRERELEASE_APPROVAL.md)\n- [Contributing to the package](CONTRIBUTING.md)\n\nThe package export map in [`package.json`](package.json) is authoritative for\navailable public subpaths.\n","packages/rxjs/docs/API.md":"# RxJS 9 API and import guide\n\nRxJS 9 separates the platform Observable contract from RxJS capabilities.\nImport the root for intentional core primitives and import each operator or\nfactory from its own subpath.\n\n## Root exports\n\n```ts\nimport { AsyncSubject, ColdObservable, ConnectableObservable, Subject, behaviorSubject, connectable, replaySubject } from 'rxjs';\n```\n\nThe root also exports notifications and public errors, including\n`Notification`, `TimeoutError`, `EmptyError`, `NotFoundError`,\n`SequenceError`, and `ArgumentOutOfRangeError`. Advanced code can extend\n`PerSubscriptionSubjectBase` when it needs observer-local setup without\nclaiming that a Subject is cold.\n\nImporting `rxjs` conditionally initializes the platform Observable surface. It\ndoes not install every RxJS operator.\n\n## Symbol operators\n\n```ts\nimport 'rxjs';\nimport { filter } from 'rxjs/filter';\nimport { map } from 'rxjs/map';\nimport { switchMap } from 'rxjs/switch-map';\n\nconst result = source[filter]((value) => value.active)[map]((value) => value.id);\n```\n\nEvery public operator is a module-owned exact Symbol. Two independently\nevaluated copies intentionally have different Symbol identities, allowing\nversion-skewed capabilities to coexist without overwriting one another.\n\nWhen a platform string method has the same descriptive name, both forms\nremain available:\n\n```ts\nobservable.map(project); // platform contract\nobservable[map](project); // RxJS contract\n```\n\nThe RxJS import never replaces the platform string method.\n\nThe public subpaths cover transformation, filtering, combination,\nhigher-order, timing, buffering/windowing, error recovery, sharing/connection,\nquery, and terminal capabilities. The complete authoritative list is the\n[`exports` map](../package.json); migration status and behavioral evidence are\nin the [generated ledger](MIGRATION_EVIDENCE_LEDGER.md).\n\n## Factories and composition\n\nFactories such as `timer` are static Symbols:\n\n```ts\nimport { timer } from 'rxjs/timer';\n\nObservable[timer](1000).subscribe(console.log);\n```\n\nThe `pipe` Symbol supports instance and static composition:\n\n```ts\nimport { map } from 'rxjs/map';\nimport { pipe } from 'rxjs/pipe';\n\nconst doubled = source[pipe]((values) => values[map]((value) => value * 2));\nconst normalized = Observable[pipe]([1, 2], (values) => values[map](String));\n```\n\nRxJS 9 does not install `.pipe`, publish RxJS 7 pipeable operator functions,\nor restore `OperatorFunction`.\n\n## Construction and input boundaries\n\nDerived RxJS operators use the receiver's construction protocol. Compatible\nsubclasses can preserve their result constructor; `ColdObservable` selects its\nproducer-per-subscription result contract.\n\nInputs cross the active realm's platform `Observable.from` boundary. Arbitrary\nobjects with a `subscribe` method are not automatically accepted, and\ntransparent foreign-realm conversion is not claimed. Review the\n[migration guide](../MIGRATION.md) before translating RxJS 7 inputs or\nlifecycle assumptions.\n\n## Cancellation and teardown\n\nSubscriptions accept `{ signal: AbortSignal }`. Operators own upstream work\nthrough the downstream Subscriber lifecycle, and cancellation does not become\ncompletion. Teardown functions and `subscriber.addTeardown()` participate in\nthe same platform lifecycle.\n\n## Environment and distribution\n\nThe package requires Node 22.13+ and publishes ESM only. Node `require()` uses\nthe supported `require(esm)` bridge and resolves the same module files as\n`import`. Current browser, Deno, Bun, and Webpack support does not select\nruntime-specific code. See [release gates](RELEASE_GATES.md) for the exact\nmatrix and budgets.\n","packages/rxjs/docs/MIGRATION_EVIDENCE_LEDGER.md":"# RxJS 7 migration-evidence ledger\n\nThis generated ledger joins the versioned RxJS Next capability registry to the\nsource-pinned RxJS 7 executable manifest. It records migration status and\nevidence; it does not promise an RxJS 7 runtime compatibility surface.\n\n- **RxJS 7 source:** `7.x` at `e5351d02e225e275ac0e497c7b66eaa5f0c88791`\n- **Entries:** 161 (111 operators, 21 creation/static functions, 29 values/types)\n- **Distinct evidence cases:** 2271\n- **Entries without source-pinned cases:** 0\n- **Rows using canonical alias evidence:** 4\n- **Rows using pinned non-marble or focused Next evidence:** 3\n\nThe complete case IDs and source files are retained in\n`packages/rxjs/test/ported/migration-evidence-ledger.generated.json`. Every\nprioritized row has direct, canonical-alias, or supplemental evidence. Cold and\nfallback totals account for every linked executable case; supplemental rows\nname their pinned non-marble or focused Next sources explicitly.\n\nRegenerate or verify the ledger with:\n\n```sh\npnpm --filter rxjs run test:unit:ledger:generate\npnpm --filter rxjs run test:unit:ledger:check\n```\n\n## Operators\n\n| RxJS 7 API | Next status | Evidence | Cases | Cold | Fallback | Classifications | Sharing | Cancellation | Types | Migration | Decisions |\n| ------------------------- | ------------------------------------------- | ------------------- | ----- | ------- | -------- | --------------------------------------------------------------------- | ---------------------- | ------------ | --------- | ------------------------------------- | --------------------------------- |\n| `audit` | Present; parity verified | source-pinned | 21 | 21/21 | 21/21 | portable | shared-active-platform | AbortSignal | preserved | mechanical-change | D-003, D-048, D-049 |\n| `auditTime` | Partial unified mapping | source-pinned | 12 | 12/12 | 12/12 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `buffer` | Present; parity verified | source-pinned | 26 | 26/26 | 26/26 | harness-rewrite, portable | shared-active-platform | AbortSignal | preserved | mechanical-change | D-003, D-048, D-049 |\n| `bufferCount` | Partial unified mapping | source-pinned | 9 | 9/9 | 9/9 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `bufferTime` | Present; scheduler adapted to host timing | source-pinned | 18 | 18/18 | 18/18 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-033, D-034, D-048, D-049 |\n| `bufferToggle` | Present; parity unverified | source-pinned | 18 | 18/18 | 18/18 | intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `bufferWhen` | Partial unified mapping | source-pinned | 16 | 16/16 | 16/16 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `catchError` | Present; parity unverified | source-pinned | 18 | 17/18 | 17/18 | compatibility-only, harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `combineLatest` | Partial unified mapping | source-pinned | 34 | 34/34 | 34/34 | intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `combineLatestAll` | Present; parity unverified | source-pinned | 31 | 31/31 | 31/31 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `combineLatestWith` | Partial unified mapping | source-pinned | 30 | 30/30 | 30/30 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `concat` | Partial unified mapping | source-pinned | 27 | 27/27 | 27/27 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `concatAll` | Partial unified mapping | source-pinned | 30 | 30/30 | 30/30 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `concatMap` | Partial unified mapping | source-pinned | 34 | 34/34 | 34/34 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `concatMapTo` | Partial unified mapping | source-pinned | 18 | 18/18 | 18/18 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `concatWith` | Partial unified mapping | source-pinned | 22 | 22/22 | 22/22 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `connect` | Present; parity unverified | source-pinned | 50 | 50/50 | 48/50 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `count` | Present; parity unverified | source-pinned | 23 | 23/23 | 23/23 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `debounce` | Present; parity unverified | source-pinned | 26 | 26/26 | 26/26 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `debounceTime` | Partial unified mapping | source-pinned | 17 | 17/17 | 17/17 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `defaultIfEmpty` | Present; parity unverified | source-pinned | 7 | 7/7 | 7/7 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `delay` | Present; scheduler adapted to host timing | source-pinned | 43 | 43/43 | 43/43 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-033, D-034, D-048, D-049 |\n| `delayWhen` | Present; parity unverified | source-pinned | 15 | 15/15 | 15/15 | intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `dematerialize` | Present; parity unverified | source-pinned | 13 | 13/13 | 13/13 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `distinct` | Present; parity unverified | source-pinned | 22 | 22/22 | 22/22 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `distinctUntilChanged` | Present; parity unverified | source-pinned | 22 | 22/22 | 22/22 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `distinctUntilKeyChanged` | Present; parity unverified | source-pinned | 21 | 21/21 | 21/21 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `elementAt` | Present; partial empty behavior | source-pinned | 12 | 12/12 | 12/12 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `endWith` | Partial unified mapping | source-pinned | 16 | 16/16 | 16/16 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `every` | Present; parity unverified | source-pinned | 22 | 22/22 | 22/22 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `exhaust` | Partial unified mapping | source-pinned-alias | 15 | 15/15 | 15/15 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `exhaustAll` | Partial unified mapping | source-pinned | 15 | 15/15 | 15/15 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `exhaustMap` | Present; parity unverified | source-pinned | 18 | 17/18 | 17/18 | compatibility-only, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `expand` | Present; scheduler overload deferred | source-pinned | 13 | 13/13 | 13/13 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-033, D-034, D-048, D-049 |\n| `filter` | Present; parity unverified | source-pinned | 21 | 21/21 | 21/21 | intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `finalize` | Present; parity unverified | source-pinned | 8 | 8/8 | 8/8 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `find` | Present; parity unverified | source-pinned | 12 | 12/12 | 12/12 | intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `findIndex` | Present; parity unverified | source-pinned | 12 | 12/12 | 12/12 | intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `first` | Present; parity unverified | source-pinned | 17 | 17/17 | 17/17 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `flatMap` | Partial unified mapping | source-pinned-alias | 149 | 143/149 | 143/149 | compatibility-only, harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `groupBy` | Present; scheduler-internal cases deferred | source-pinned | 36 | 36/36 | 36/36 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-033, D-034, D-048, D-049 |\n| `ignoreElements` | Partial unified mapping | source-pinned | 9 | 9/9 | 9/9 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `isEmpty` | Present; parity unverified | source-pinned | 7 | 7/7 | 7/7 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `last` | Present; parity unverified | source-pinned | 11 | 11/11 | 11/11 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `map` | Present; parity unverified | source-pinned | 93 | 92/93 | 93/93 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `mapTo` | Partial unified mapping | source-pinned | 11 | 11/11 | 11/11 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `materialize` | Present; parity unverified | source-pinned | 10 | 10/10 | 10/10 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `max` | Present; parity unverified | source-pinned | 18 | 18/18 | 18/18 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `merge` | Partial unified mapping | source-pinned | 1 | 1/1 | 1/1 | intentional-divergence | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `mergeAll` | Partial unified mapping | source-pinned | 25 | 25/25 | 25/25 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `mergeMap` | Partial unified mapping | source-pinned | 149 | 143/149 | 143/149 | compatibility-only, harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `mergeMapTo` | Partial unified mapping | source-pinned | 106 | 87/106 | 103/106 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `mergeScan` | Present; parity unverified | source-pinned | 20 | 20/20 | 20/20 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `mergeWith` | Partial unified mapping | source-pinned | 17 | 17/17 | 17/17 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `min` | Present; parity unverified | source-pinned | 18 | 18/18 | 18/18 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `multicast` | Compatibility-only | source-pinned | 70 | 65/70 | 68/70 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | semantic-review | D-003, D-039, D-048, D-049 |\n| `observeOn` | Partial scheduler mapping | source-pinned | 7 | 7/7 | 7/7 | harness-rewrite | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-033, D-034, D-048, D-049 |\n| `onErrorResumeNext` | Partial unified mapping | source-pinned | 11 | 10/11 | 10/11 | compatibility-only, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `pairwise` | Present; parity unverified | source-pinned | 7 | 7/7 | 7/7 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `pluck` | Present; parity unverified | source-pinned | 14 | 14/14 | 14/14 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `publish` | Compatibility-only | source-pinned | 64 | 63/64 | 62/64 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | semantic-review | D-003, D-039, D-048, D-049 |\n| `publishBehavior` | Compatibility-only | source-pinned | 62 | 54/62 | 60/62 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | semantic-review | D-003, D-039, D-048, D-049 |\n| `publishLast` | Compatibility-only | source-pinned | 61 | 61/61 | 59/61 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | semantic-review | D-003, D-039, D-048, D-049 |\n| `publishReplay` | Compatibility-only | source-pinned | 69 | 60/69 | 66/69 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | semantic-review | D-003, D-039, D-048, D-049 |\n| `race` | Partial unified mapping | source-pinned | 12 | 12/12 | 12/12 | intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `raceWith` | Partial unified mapping | source-pinned | 10 | 10/10 | 10/10 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `reduce` | Present; parity unverified | source-pinned | 18 | 18/18 | 18/18 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `refCount` | Compatibility-only | source-pinned | 74 | 62/74 | 72/74 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | semantic-review | D-003, D-039, D-048, D-049 |\n| `repeat` | Partial unified mapping | source-pinned | 64 | 60/64 | 64/64 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `repeatWhen` | Present; parity unverified | source-pinned | 20 | 20/20 | 20/20 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `retry` | Partial unified mapping | source-pinned | 67 | 63/67 | 65/67 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `retryWhen` | Present; parity unverified | source-pinned | 19 | 19/19 | 19/19 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `sample` | Present; parity unverified | source-pinned | 16 | 16/16 | 16/16 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `sampleTime` | Present; scheduler adapted to host timing | source-pinned | 10 | 10/10 | 10/10 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-033, D-034, D-048, D-049 |\n| `scan` | Present; parity unverified | source-pinned | 12 | 12/12 | 12/12 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `sequenceEqual` | Present; parity verified | source-pinned | 23 | 23/23 | 23/23 | harness-rewrite, portable | shared-active-platform | AbortSignal | preserved | mechanical-change | D-003, D-048, D-049 |\n| `share` | Present; platform lifecycle review required | source-pinned | 176 | 176/176 | 174/176 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `shareReplay` | Present; platform lifecycle review required | source-pinned | 16 | 16/16 | 16/16 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `single` | Present; parity unverified | source-pinned | 25 | 25/25 | 25/25 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `skip` | Present; parity unverified | source-pinned | 29 | 29/29 | 29/29 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `skipLast` | Present; parity unverified | source-pinned | 16 | 16/16 | 16/16 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `skipUntil` | Present; parity unverified | source-pinned | 19 | 18/19 | 18/19 | compatibility-only, harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `skipWhile` | Present; parity unverified | source-pinned | 15 | 15/15 | 15/15 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `startWith` | Present; scheduler overload deferred | source-pinned | 24 | 24/24 | 24/24 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-033, D-034, D-048, D-049 |\n| `subscribeOn` | Partial scheduler mapping | source-pinned | 8 | 8/8 | 8/8 | harness-rewrite | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-033, D-034, D-048, D-049 |\n| `switchAll` | Partial unified mapping | source-pinned | 11 | 11/11 | 11/11 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `switchMap` | Present; parity unverified | source-pinned | 19 | 18/19 | 18/19 | compatibility-only, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `switchMapTo` | Partial unified mapping | source-pinned | 15 | 15/15 | 15/15 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `switchScan` | Present; parity unverified | source-pinned | 18 | 18/18 | 18/18 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `take` | Present; parity unverified | source-pinned | 47 | 47/47 | 47/47 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `takeLast` | Present; parity unverified | source-pinned | 18 | 18/18 | 18/18 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `takeUntil` | Present; parity unverified | source-pinned | 23 | 23/23 | 23/23 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `takeWhile` | Present; parity unverified | source-pinned | 23 | 23/23 | 23/23 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `tap` | Present; parity unverified | source-pinned | 73 | 66/73 | 73/73 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `throttle` | Present; parity unverified | source-pinned | 28 | 28/28 | 28/28 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `throttleTime` | Partial unified mapping | source-pinned | 16 | 16/16 | 16/16 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `throwIfEmpty` | Present; parity unverified | source-pinned | 7 | 7/7 | 7/7 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `timeInterval` | Present; scheduler adapted to host timing | source-pinned | 11 | 11/11 | 11/11 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-033, D-034, D-048, D-049 |\n| `timeout` | Partial unified mapping | source-pinned | 38 | 38/38 | 38/38 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-033, D-034, D-048, D-049 |\n| `timeoutWith` | Partial unified mapping | source-pinned | 15 | 15/15 | 15/15 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `timestamp` | Present; scheduler adapted to host timing | source-pinned | 11 | 11/11 | 11/11 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-033, D-034, D-048, D-049 |\n| `toArray` | Partial unified mapping | source-pinned | 15 | 15/15 | 15/15 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `window` | Present; parity unverified | source-pinned | 18 | 18/18 | 18/18 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `windowCount` | Present; parity unverified | source-pinned | 9 | 9/9 | 9/9 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `windowTime` | Present; scheduler adapted to host timing | source-pinned | 13 | 13/13 | 13/13 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-033, D-034, D-048, D-049 |\n| `windowToggle` | Present; parity unverified | source-pinned | 19 | 19/19 | 19/19 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `windowWhen` | Present; parity unverified | source-pinned | 15 | 15/15 | 15/15 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `withLatestFrom` | Unified mapping | source-pinned | 17 | 17/17 | 17/17 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `zip` | Compatibility alias | source-pinned | 10 | 8/10 | 10/10 | intentional-divergence, portable | shared-active-platform | AbortSignal | changed | semantic-review | D-003, D-039, D-048, D-049 |\n| `zipAll` | Present; parity unverified | source-pinned | 46 | 46/46 | 46/46 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `zipWith` | Present; parity unverified | source-pinned | 32 | 32/32 | 32/32 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n\n## Creation and static functions\n\n| RxJS 7 API | Next status | Evidence | Cases | Cold | Fallback | Classifications | Sharing | Cancellation | Types | Migration | Decisions |\n| ------------------- | ------------------------------------ | ------------------- | ----- | ------- | -------- | --------------------------------------------------------------------- | ---------------------- | ------------ | ------- | ------------------------------------- | ---------------------------------------- |\n| `animationFrames` | Present; parity unverified | source-pinned | 4 | 4/4 | 4/4 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-033, D-034, D-040, D-048, D-049 |\n| `combineLatest` | Partial unified mapping | source-pinned | 32 | 32/32 | 32/32 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-040, D-048, D-049 |\n| `concat` | Partial unified mapping | source-pinned | 115 | 114/115 | 114/115 | compatibility-only, harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-040, D-048, D-049 |\n| `defer` | Partial platform mapping | source-pinned | 12 | 12/12 | 12/12 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-040 |\n| `empty` | Partial standalone mapping | source-pinned | 1 | 1/1 | 1/1 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-040 |\n| `forkJoin` | Present; parity unverified | source-pinned | 39 | 35/39 | 35/39 | compatibility-only, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-040, D-048, D-049 |\n| `from` | Platform mapping | source-pinned | 8 | 6/8 | 6/8 | compatibility-only, harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-040 |\n| `fromEvent` | Partial platform string mapping | source-pinned | 1 | 1/1 | 1/1 | harness-rewrite | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-040 |\n| `generate` | Present; scheduler overload deferred | source-pinned | 13 | 13/13 | 13/13 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-033, D-034, D-040, D-048, D-049 |\n| `iif` | Partial platform mapping | source-pinned | 4 | 4/4 | 4/4 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-040 |\n| `interval` | Present; parity unverified | source-pinned | 12 | 12/12 | 12/12 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-040, D-048, D-049 |\n| `merge` | Partial unified mapping | source-pinned | 81 | 78/81 | 76/81 | compatibility-only, harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-040, D-048, D-049 |\n| `never` | Partial standalone mapping | source-pinned-alias | 42 | 42/42 | 42/42 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-040 |\n| `of` | Partial platform mapping | source-pinned | 400 | 394/400 | 394/400 | compatibility-only, harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-040 |\n| `onErrorResumeNext` | Partial unified mapping | source-pinned | 3 | 3/3 | 3/3 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-040, D-048, D-049 |\n| `pairs` | Partial platform mapping | source-pinned | 2 | 2/2 | 2/2 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-040 |\n| `partition` | Present; parity unverified | source-pinned | 16 | 16/16 | 16/16 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-040, D-048, D-049 |\n| `race` | Partial unified mapping | source-pinned | 15 | 15/15 | 15/15 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-040, D-048, D-049 |\n| `range` | Partial platform mapping | source-pinned | 3 | 3/3 | 3/3 | harness-rewrite | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-040 |\n| `throwError` | Partial platform mapping | source-pinned | 31 | 31/31 | 31/31 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-040 |\n| `timer` | Partial unified mapping | source-pinned | 37 | 37/37 | 37/37 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-040, D-048, D-049 |\n\n## Values, types, and standalone functions\n\n| RxJS 7 API | Next status | Evidence | Cases | Cold | Fallback | Classifications | Sharing | Cancellation | Types | Migration | Decisions |\n| ------------------------- | --------------------------------- | ------------------- | ----- | ------------ | ------------ | --------------------------------------------------------------------- | -------------------------------- | ------------------ | ------------------ | ------------------------------------- | --------------------------------- |\n| `ArgumentOutOfRangeError` | Present; parity verified | source-pinned | 2 | 2/2 | 2/2 | portable | not-applicable | not-applicable | preserved | mechanical-change | D-040 |\n| `AsyncSubject` | Compatibility-only | source-pinned | 48 | 48/48 | 46/48 | harness-rewrite, intentional-divergence | subject-hot | AbortSignal | changed | semantic-review | D-035, D-039, D-040, D-050 |\n| `BehaviorSubject` | Partial standalone mapping | source-pinned | 51 | 51/51 | 49/51 | harness-rewrite, intentional-divergence, portable | subject-hot | AbortSignal | changed | mechanical-change-and-semantic-review | D-035, D-039, D-040, D-050 |\n| `ColdObservable` | Compatibility-only | supplemental | 0 | supplemental | supplemental | supplemental | producer-per-direct-subscription | AbortSignal | changed | semantic-review | D-035, D-037, D-039, D-040, D-050 |\n| `config` | Test compatibility fixture | source-pinned | 3 | 3/3 | 3/3 | harness-rewrite | not-applicable | test-local-adapter | changed | adapter | D-039, D-040 |\n| `connectable` | Present; parity unverified | source-pinned | 2 | 2/2 | 2/2 | harness-rewrite, portable | subject-hot | AbortSignal | changed | mechanical-change | D-035, D-039, D-040 |\n| `ConnectableObservable` | Compatibility-only | source-pinned | 45 | 36/45 | 45/45 | harness-rewrite, intentional-divergence, portable | subject-hot | AbortSignal | changed | semantic-review | D-035, D-039, D-040 |\n| `EMPTY` | Present; parity unverified | source-pinned | 42 | 42/42 | 42/42 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-040 |\n| `EmptyError` | Present; parity unverified | source-pinned | 13 | 13/13 | 13/13 | portable | not-applicable | not-applicable | changed | mechanical-change | D-040 |\n| `firstValueFrom` | Partial platform mapping | supplemental | 0 | supplemental | supplemental | supplemental | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-040 |\n| `fromEventPattern` | Present; parity unverified | source-pinned | 1 | 1/1 | 1/1 | harness-rewrite | shared-active-platform | AbortSignal | changed | mechanical-change \n\n","packages/rxjs/docs/PRERELEASE_APPROVAL.md":"# RxJS 9 beta.0 approval\n\n## Decision\n\nThe repository evidence approves `rxjs@9.0.0-beta.0` and the synchronized\nfour-package train to begin the RxJS 9 public beta under npm's `next` tag, once\nthe configured blocking CI jobs are green. RxJS 7 remains npm's `latest` line\nand remains maintained.\n\nThis approval does not publish a package, create a GitHub release, promote RxJS\n9 to `latest`, or approve the stable `9.0.0` release. Stable promotion requires\npublic beta feedback and a separate explicit decision. The version number is 9\nbecause the paused RxJS 8 effort predates this platform-based generation; RxJS\n8 was not silently shipped or erased.\n\n## Adoption evidence\n\nThe exact four package artifacts were packed and audited locally. An isolated,\noffline consumer installed the `rxjs`, `@rxjs/observable-polyfill`, and\n`@rxjs/test` tarballs and passed:\n\n- ESM imports and runtime behavior;\n- Node 22.13, 24.12, and advisory 26.5 `require(esm)` behavior;\n- strict public TypeScript declarations;\n- `@rxjs/test` virtual-time behavior;\n- a minified browser bundle using only the packed ESM files.\n\nThe browser bundle was 20,222 bytes. Packed artifact sizes were:\n\n| Package | Tarball bytes | Budget |\n| --------------------------- | ------------: | ------: |\n| `rxjs` | 183,920 | 250,000 |\n| `@rxjs/observable-polyfill` | 23,375 | 30,000 |\n| `@rxjs/test` | 47,270 | 60,000 |\n| `@rxjs/migrate` | 112,638 | 140,000 |\n\nThe audit found no source specs, CommonJS/browser/Webpack dialect copies, or\nmissing package documentation. The Nx first-release version dry run resolves\nthe complete train to `9.0.0-beta.0`.\n\n## Broader qualification\n\n- Focused product suites pass 51 polyfill, 750 RxJS, 75 test-harness, and 166\n migration tests.\n- Pinned Observable WPT passes all 52 URLs, 525 upstream subtests, and 52 exact\n implementation-identity attestations.\n- Current Chromium, Firefox, and WebKit pass the shared eight-case lifecycle\n and Symbol contract. Desktop and Mobile Safari are separate blocking\n SafariDriver jobs; Mobile Safari requires an actual iOS simulator.\n- Node, Deno, Bun, Webpack, bundle-size, and performance evidence passes the\n checked-in gates described in [RELEASE_GATES.md](RELEASE_GATES.md).\n- The representative migration program has three completed RxJS 7 migrations\n and one correct safe stop across Vitest, Mocha, Jest, application/library,\n cold, platform-shared, mixed, and unsupported contracts.\n\n## Known non-blockers\n\nThe complete source-pinned RxJS 7 corpus retains 39 cold and 22 fallback\nfailures. Every one is a reviewed platform-lifecycle divergence or unsupported\narbitrary-subscribable compatibility case. They are executable migration\nevidence, not hidden failures and not a promise of an RxJS 7 compatibility\nruntime.\n\nLocal branded Safari execution was not forced by changing a persistent host\nsecurity setting. The clean-runner Safari and iOS simulator jobs are blocking\nconditions of publication, not waived evidence.\n\n## Publication boundary\n\nThe [release process](https://github.com/ReactiveX/rxjs/blob/master/docs/RELEASE_PROCESS.md)\nrequires a clean, synchronized `master` checkout and one interactive\n`pnpm release:beta 9.0.0-beta.0` command. It checks version identity,\npackage-local documentation, ESM-only exports, package gates, and npm dry runs;\nprints the exact tarball integrities; and then uses npm's OTP/WebAuthn flow for\neach public package. The supporting packages publish first and `rxjs` publishes\nlast. No CI credential or documentation application is part of publication.\n","packages/rxjs/docs/RELEASE_GATES.md":"# RxJS 9 release gates\n\nThis document describes the executable environment and package gates for the\nRxJS 9 prerelease line. It is package documentation; it does not depend on the\nrepository documentation application.\n\nThe repository's [release runbook](https://github.com/ReactiveX/rxjs/blob/master/docs/RELEASE_PROCESS.md)\ndefines the clean-checkout requirement, interactive npm publication order,\nintegrity verification, and failure recovery. CI qualifies the source; only a\nmaintainer running the local release command can authorize publication.\n\n## Runtime matrix\n\n| Environment | Release role | Executable evidence |\n| -------------------------- | -------------------- | --------------------------------------------------------------------------- |\n| Node 22.13.0+ | Blocking | Package build, types, ESM import, Node `require(esm)`, and runtime contract |\n| Node 24 | Blocking | Full package and release gates, plus pinned Observable WPT |\n| Node 26 | Advisory during beta | The same package and runtime gates with a non-blocking CI result |\n| Current Chrome and Firefox | Blocking | Eight-case browser lifecycle and Symbol-extension contract |\n| Current desktop Safari | Blocking | The same contract through Apple SafariDriver |\n| Current Mobile Safari | Blocking | The same contract in an actual iOS simulator through Apple SafariDriver |\n| Current Playwright WebKit | Additional signal | The same contract, reported as WebKit rather than branded Safari |\n| Deno 2.8.0 | Blocking | Package-built runtime contract |\n| Bun 1.3.14 | Blocking | Package-built runtime contract |\n| Webpack 5.106.2 | Blocking | ESM resolution, production execution, and output-size budget |\n\nThe release-coherence checker pins the concrete Deno, Bun, Webpack, browser,\nNode, and Safari CI lanes. Updating a current-runtime version is therefore a\nreviewed release change rather than silent drift.\n\n## CI ownership\n\n| Workflow | Pull requests | `master` pushes |\n| ----------------- | --------------------------------------------------------- | -------------------------------------------------- |\n| Main CI | Package matrix plus exact migration evidence and tooling | Same blocking gates on every push |\n| TypeScript latest | RxJS compilation against the latest TypeScript | Same compatibility signal on every push |\n| Observable WPT | Blocking when platform, package, or harness paths change | Blocking pinned conformance on every push |\n| Release readiness | Blocking when release packages, scripts, or config change | Complete blocking environment matrix on every push |\n\nMain CI executes all 2,338 source-pinned RxJS 7 evidence cases in cold and\npolyfill modes and requires exact equality with the reviewed 2,299/39 and\n2,316/22 pass/failure case-ID sets. The raw audit commands still report the\nintentional divergences as ordinary failures; the CI verifier blocks any added\nfailure, unexpected pass, incomplete collection, or identity drift until the\nevidence is reviewed. Main CI also owns generated evidence freshness,\nbundle-analysis tests, SafariDriver unit tests, and active-workflow validation.\nRelease coherence rejects removal of required commands, lanes, or `master`\ntriggers.\n\n## Distribution contract\n\nEvery supported consumer receives the same `dist/esm` JavaScript. Browser,\nWebpack, ESM `import`, and Node `require(esm)` export conditions do not select\ntarget-specific copies. Deno and Bun support adds test infrastructure only; it\ndoes not add runtime code, dependencies, export conditions, or bundle bytes.\n\nThere is no CommonJS artifact. `require('rxjs')` is supported only through the\nNode 22.13+ `require(esm)` bridge and returns the same module identity and exact\nSymbols as ESM import.\n\n## Budgets\n\nThe checked-in budgets in `test/release/budgets.json` are blocking:\n\n- the representative minified Webpack bundle must not exceed 22,000 bytes;\n- the median map pipeline must process at least 5,000,000 values per second;\n- the median subscribe-and-abort loop must complete at least 30,000\n cancellations per second.\n- packed tarballs must stay under 250,000 bytes for `rxjs`, 30,000 bytes for\n the polyfill, 60,000 bytes for `@rxjs/test`, and 140,000 bytes for\n `@rxjs/migrate`.\n\nThe initial Node 24 evidence was 17,502 Webpack bytes, approximately 50.4\nmillion mapped values per second, and approximately 140,500 cancellations per\nsecond. The throughput floors deliberately leave substantial runner headroom;\nthe bundle ceiling leaves roughly 25% growth headroom while still catching a\nduplicate dialect or large accidental dependency.\n\nThe packed-adoption gate installs the local tarballs into an isolated consumer\nwith no registry access, then runs ESM, Node `require(esm)`, TypeScript, marble\ntesting, and a browser bundle. It also rejects source specs, duplicate output\ndialects, missing package documentation, and tarball-size regressions.\n\n## Commands\n\nFrom the repository root:\n\n```sh\npnpm run release:check\npnpm --filter rxjs run test:unit:audit:check\npnpm run test:bundle-analysis\npnpm run test:release:safari\npnpm run test:workflows\npnpm run test:release:runtime\npnpm run test:release:browsers\npnpm run test:release:safari\npnpm run test:release:webpack\npnpm run test:release:performance\npnpm run test:release:adoption\npnpm run test:wpt\n```\n\nDesktop and Mobile Safari execution is CI-owned because SafariDriver requires\nhost-level automation authorization. The Mobile Safari lane requests\n`platformName: iOS` and `safari:useSimulator: true`; Playwright WebKit is never\nsubstituted for that branded-browser gate.\n\nThe complete source-pinned RxJS 7 migration corpus is evidence, not a claim\nthat RxJS 9 implements every RxJS 7 behavior. Its reviewed intentional\ndivergences remain nonzero by design; the focused source suite, package gates,\nruntime matrix, and conformance suite are the blocking release checks.\n","packages/rxjs/docs/SECURITY_ASSURANCE.md":"# RxJS 9 security assurance\n\nRxJS 9 uses a deliberately small release boundary. This document describes\nthe evidence and trust assumptions; it does not promise that the software is\nfree of vulnerabilities.\n\n## What users can rely on\n\n- The `rxjs` runtime depends only on the RxJS-owned\n `@rxjs/observable-polyfill`; that package has no runtime dependencies.\n- Pull requests and every `master` push run the package, type, browser, Safari,\n Web Platform Test, bundler, performance, migration, dependency-review,\n CodeQL, and OSV checks described in [RELEASE_GATES.md](RELEASE_GATES.md).\n- npm publication is not available to GitHub Actions. The repository stores no\n npm publishing token and has no publishing workflow, trusted publisher, or\n release App.\n- A maintainer publishes from a clean local `master` checkout with\n `pnpm release:beta `. The command builds and tests, packs the four\n packages, prints SHA-512 integrities, and runs npm publication dry runs before\n asking for irreversible confirmation.\n- npm's interactive OTP/WebAuthn flow authorizes each package. Supporting\n packages publish first and `rxjs` publishes last.\n- The command verifies npm's registry integrity and `next` tag for all four\n packages and confirms that `rxjs@latest` remains on RxJS 7.\n- An interrupted command can skip an already-published package only when the\n registry integrity equals the freshly packed tarball.\n\n## One-maintainer reality\n\nRxJS currently has one active maintainer. The same person authors, reviews,\nmerges, and releases changes. Pull requests expose diffs and run mandatory\nchecks, but RxJS does not claim independent human approval. OpenSSF's\nCode-Review score is therefore accepted rather than manipulated with\nceremonial approvals.\n\nThe publication boundary trusts that maintainer's local machine and npm\nauthentication. Interactive WebAuthn, required CI, dry runs, ordered\npublication, and registry verification reduce common mistakes and credential\nrisks; they do not remove the risk of a compromised maintainer machine or npm\naccount. Recovery codes are kept offline. Package publishing access requires\ntwo-factor authentication and disallows automation tokens after each new\npackage record exists.\n\n## Verify a release\n\nAfter installing with a lockfile, verify npm registry signatures:\n\n```sh\nnpm audit signatures\n```\n\nInspect the registry integrity and channels directly:\n\n```sh\nnpm view rxjs@9.0.0-beta.0 dist.integrity\nnpm view rxjs@next version\nnpm view rxjs@latest version\n```\n\nThe release operator records all four integrity values and the immutable GitHub\nRelease URL in the project-plan session log.\n\n## Vulnerability evidence\n\nOSV scanning runs on pull requests, every `master` push, and weekly. Anything\nreachable from runtime, build, or test tooling must be fixed or removed. The\ninherited legacy documentation-application toolchain is excluded from RxJS 9\nand tracked separately; its time-bounded exceptions do not change the release\npackage scans.\n\nProperty-based tests exercise the Observable lifecycle state machine. Package\nand release-script tests cover synchronized versions, clean-checkout guards,\ninteractive credential restrictions, publication order, npm channels, and\nintegrity comparisons.\n\n## What this does not prove\n\nPassing tests does not prove that source is bug-free. A matching registry hash\nproves that npm received the local tarball; it does not prove that the local\nmachine or maintainer account was uncompromised. The initial manual publication\ndoes not provide npm's CI provenance attestation. These are accepted tradeoffs\nfor an understandable sole-maintainer process.\n\n## OpenSSF in context\n\n[![OpenSSF Scorecard](https://api.scorecard.dev/projects/github.com/ReactiveX/rxjs/badge)](https://scorecard.dev/viewer/?uri=github.com/ReactiveX/rxjs)\n\nOpenSSF Scorecard is a useful repository-hygiene signal, not a release gate or\nthe project's primary security claim. Users assessing a specific RxJS 9\nversion should prefer required-CI history, registry signatures, exact package\nintegrity, and the tagged source commit.\n","packages/rxjs/docs/UNSUPPORTED_RXJS_7_SURFACES.md":"# Unsupported RxJS 7 surfaces\n\nThis generated catalog records RxJS 7 public imports and behavioral protocols that RxJS Next does not preserve as compatibility APIs. It is migration guidance, not an emulation commitment. The source inventory is pinned to RxJS 7 `7.x` at `e5351d02e225e275ac0e497c7b66eaa5f0c88791`.\n\nRegenerate it with `pnpm --filter rxjs run test:unit:unsupported:generate`; the corresponding `--check` gate rejects a stale document, a source-pin mismatch, missing required categories, or unclassified scheduler-bearing capabilities.\n\n## Summary\n\n| Measure | Count |\n| -------------------- | ----: |\n| Catalog groups | 27 |\n| Named surfaces | 147 |\n| Manual Review groups | 5 |\n| Replace groups | 17 |\n| Unsupported groups | 5 |\n\n## Dispositions\n\n- **Replace:** a supported Next or platform destination exists, but its imports, types, or lifecycle may differ.\n- **Manual review:** no mechanical rewrite is safe without reviewing cancellation, sharing, timing, or ownership.\n- **Unsupported:** no accepted Next compatibility contract exists.\n- **Test only:** any adapter is limited to evidence infrastructure and must not become an application migration.\n- **Removed:** the surface has no replacement and should disappear.\n\n## Imports and package paths\n\n| RxJS 7 surface | Disposition | Migration direction | Why | Decisions |\n| ------------------------------------------------------------------------------------------------------------- | ------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ | ------------------- |\n| `rxjs/operators`
`root-imported operator functions`
`source.pipe(...)` | Replace | Import exact Symbols from rxjs/ and invoke source[symbol](...). Use rxjs/pipe only for deliberate Symbol composition. | RxJS Next does not publish the RxJS 7 pipeable-function or string-named .pipe surface. | D-003, D-039, D-050 |\n| `rxjs:Observable`
`rxjs:Subscriber` | Replace | Use the active realm's ambient Observable and Subscriber after @rxjs/observable-polyfill initialization when needed. | The platform owns these constructors; the rxjs root does not re-export compatibility classes for them. | D-039, D-040, D-041 |\n| `rxjs/testing`
`TestScheduler`
`VirtualTimeScheduler`
`VirtualAction` | Replace | Use @rxjs/test rxTest() and its explicit cold(), hot(), observable(), virtual host-time, and assertion helpers. | The public scheduler classes and manual TestScheduler mode are not part of the Next runtime or test contract. | D-012, D-033, D-039 |\n| `rxjs/ajax`
`rxjs/fetch`
`rxjs/webSocket`
`ajax`
`fromFetch`
`webSocket`
`WebSocketSubject` | Manual Review | Use platform fetch, XMLHttpRequest, WebSocket, EventTarget.when, or an application adapter selected for the required cancellation and sharing contract. | RxJS Next does not currently publish the RxJS 7 DOM specialty packages or their wrapper types. | D-039, D-040 |\n| `rxjs/internal/*`
`rxjs/src/*`
`unexported package paths` | Unsupported | Replace with an accepted public Next subpath or application-owned code after semantic review. | RxJS 7 internals are not preserved as public package contracts and must not be revived to satisfy migration tests. | D-039, D-040 |\n| `bindCallback`
`bindNodeCallback`
`scheduled`
`using`
`isObservable` | Manual Review | Wrap callback or resource ownership explicitly with Observable and AbortSignal; use platform conversion or capability-specific mappings where applicable. | No accepted public Next function preserves these RxJS 7 imports and complete overload contracts. | D-039, D-040, D-049 |\n| `ObjectUnsubscribedError`
`UnsubscriptionError` | Unsupported | Use platform error and AbortSignal reason handling or an application-owned aggregate error contract. | These errors belong to removed RxJS 7 Subscription and closed-Subject internals. | D-039, D-040 |\n\n## Types\n\n| RxJS 7 surface | Disposition | Migration direction | Why | Decisions |\n| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | ------------------- |\n| `UnaryFunction`
`OperatorFunction`
`MonoTypeOperatorFunction` | Replace | Use ordinary typed functions with exact Symbol invocation or rxjs/pipe composition. | RxJS Next does not publish the pipeable-operator type family. | D-039, D-050 |\n| `Subscription`
`SubscriptionLike`
`Unsubscribable`
`TeardownLogic` | Replace | Use AbortController, AbortSignal, SubscribeOptions, and Subscriber.addTeardown inside producers. | subscribe() returns undefined and cancellation is signal-owned; no Subscription facade is published. | D-039, D-041, D-049 |\n| `ObservableInput`
`ObservableLike`
`InteropObservable`
`Subscribable`
`SubscribableOrPromise`
`ReadableStreamLike` | Replace | Use the ambient ObservableValue/platform Observable.from input contract and review custom inputs manually. | The platform conversion boundary deliberately excludes arbitrary subscribables and legacy observable interop. | D-039, D-049 |\n| `NextObserver`
`ErrorObserver`
`CompletionObserver`
`PartialObserver`
`SubjectLike`
`Connectable` | Replace | Use ambient Observer/Subscriber shapes or the concrete intentional Subject/connectable APIs; define application protocols locally when needed. | These RxJS 7 helper interfaces are not a public Next import family. | D-035, D-039, D-040 |\n| `SchedulerLike`
`SchedulerAction`
`TimestampProvider` | Replace | Use host timing APIs, Date.now-compatible narrow providers where explicitly documented, and @rxjs/test virtual host time. | There is no general public scheduler abstraction in RxJS Next. | D-012, D-033, D-039 |\n| `FactoryOrValue`
`ObservedValueOf`
`ObservedValueUnionFromArray`
`ObservedValuesFromArray`
`ObservedValueTupleFromArray`
`ObservableInputTuple`
`Cons`
`Head`
`Tail`
`ValueFromArray`
`Falsy`
`TruthyTypesOf` | Unsupported | Use inference from the accepted Next API or application-owned utility types; do not deep-import RxJS internals. | These RxJS 7 implementation-facing inference helpers are not stable Next public types. | D-039, D-040 |\n| `GroupedObservable`
`Timestamp`
`TimeInterval` | Replace | Use the structural keyed group view, structural timestamp result, or TimeInterval exported by the exact rxjs/time-interval capability as applicable. | The RxJS 7 root type imports are not preserved even where a capability exposes an intentional structural or subpath-specific result. | D-003, D-039, D-040 |\n\n## Schedulers and scheduler overloads\n\n| RxJS 7 surface | Disposition | Migration direction | Why | Decisions |\n| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------- |\n| `asap`
`asapScheduler`
`async`
`asyncScheduler`
`queue`
`queueScheduler`
`animationFrame`
`animationFrameScheduler`
`Scheduler`
`VirtualTimeScheduler`
`VirtualAction` | Replace | Use virtualizable host timing and task APIs; use @rxjs/test for deterministic tests. | RxJS Next does not publish scheduler instances or scheduler classes. | D-012, D-033, D-039 |\n| `animationFrames`
`auditTime`
`bufferTime`
`concat`
`debounceTime`
`delay`
`empty`
`endWith`
`expand`
`from`
`generate`
`groupBy`
`interval`
`observeOn`
`pairs`
`publishReplay`
`range`
`sampleTime`
`scheduled`
`shareReplay`
`startWith`
`subscribeOn`
`throwError`
`throttleTime`
`timeInterval`
`timeout`
`timeoutWith`
`timer`
`timestamp`
`windowTime` | Manual Review | Remove only an explicitly classified scheduler overload and verify ordering with host-time behavior; otherwise retain the source and stop automation. | Current capabilities use host scheduling or narrow clock providers, and the port harness adapter is not a production SchedulerLike contract. | D-012, D-033, D-034, D-039 |\n\n## Interop protocols\n\n| RxJS 7 surface | Disposition | Migration direction | Why | Decisions |\n| ------------------------------------------------------------------------------------------------------------------------------- | ------------- | ---------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- | ------------------- |\n| `observable`
`Symbol.observable`
`@@observable`
`InteropObservable` | Unsupported | Expose a platform-supported ObservableValue category or wrap the source explicitly in the active realm. | Legacy observable interop is outside the accepted platform Observable.from contract. | D-039, D-049 |\n| `objects with subscribe()`
`lowerCaseO`
`asInteropObservable`
`custom Subscribable` | Manual Review | Write an explicit application adapter that owns cancellation and terminal behavior, or choose a supported platform input category. | The 15 executable compatibility-only failures deliberately preserve this unsupported input boundary. | D-039, D-049 |\n| `foreign-realm Observable`
`cross-window Observable`
`cross-worker Observable`
`borrowed symbols on unrelated objects` | Unsupported | Initialize each realm independently and bridge values through an explicit application protocol. | RxJS does not traverse realms or promise generic Symbol borrowing onto unrelated receivers. | D-041, D-048, D-049 |\n| `Observable.lift`
`source/operator fields`
`custom Operator` | Replace | Use exact Symbol composition and the versioned derived-construction protocol through supported public capabilities. | The RxJS 7 lift/source/operator protocol is removed and is not a public Next subclass hook. | D-037, D-039, D-049 |\n\n## Deprecated and removed aliases\n\n| RxJS 7 surface | Disposition | Migration direction | Why | Decisions |\n| --------------------------------------------------------------------------------------------------------------------------------- | ------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- | ------------------- |\n| `combineAll`
`exhaust`
`flatMap`
`pipeable partition` | Replace | Use combineLatestAll, exhaustMap(identity), mergeMap, or Observable[partition] respectively. | The deprecated RxJS 7 names are not public Next Symbol identities; migration uses their canonical accepted mappings. | D-003, D-039, D-049 |\n| `empty()`
`never()` | Replace | Use EMPTY and NEVER. | The deprecated creation functions are not retained as callable Next aliases. | D-039, D-040 |\n| `mapTo`
`concatMapTo`
`mergeMapTo`
`switchMapTo`
`pluck` | Replace | Use map with a constant or property projection, or the corresponding canonical flattening Symbol with an explicit projection. | Migration may preserve behavior through exact mappings, but the deprecated pipeable function/import shape is not supported. | D-003, D-039 |\n| `pipeable combineLatest`
`pipeable concat`
`pipeable merge`
`pipeable race`
`pipeable zip`
`onErrorResumeNextWith` | Replace | Use the accepted unified or With-form exact Symbol and its documented source-array/result-selector mapping. | Legacy pipeable aliases are migration inputs, not preserved function exports. | D-003, D-039, D-049 |\n| `multicast`
`publish`
`publishBehavior`
`publishLast`
`publishReplay`
`refCount` | Manual Review | Prefer share, shareReplay, connect, or connectable with an explicit connector/reset contract; exact legacy-named Symbols remain migration evidence, not a compatibility promise. | Producer sharing, replay, reset, and ref-count semantics require explicit lifecycle review. | D-035, D-039, D-049 |\n| `new BehaviorSubject(value)`
`new ReplaySubject(size, windowTime, scheduler)`
`ColdSubject` | Replace | Use behaviorSubject(value), replaySubject({ size, maxAge }), or the advanced PerSubscriptionSubjectBase only for a justified custom hot Subject. | D-050 stabilizes lowercase factories and removes the misleading ColdSubject name without aliases. | D-035, D-036, D-050 |\n| `eachValueFrom`
`bufferedValuesFrom` | Replace | Use one of iterateEachValue, iterateBufferedValues, iterateLatestValue, or iterateNextValue from its exact Symbol subpath. | The exploratory standalone helpers were removed so buffering and dropping policy stays explicit. | D-038, D-039 |\n\n## Review rule\n\nA migration tool may automate only a cataloged **replace** mapping whose target capability and contract are also present in the migration evidence ledger. It must stop with a structured diagnostic for **manual review**, **unsupported**, **test only**, or **removed** entries. Adding a compatibility runtime, scheduler abstraction, import alias, interop protocol, or deep-import bridge requires a new accepted architecture decision.\n","packages/test/README.md":"# `@rxjs/test`\n\nImplementation-neutral virtual-time and marble testing for RxJS 9 Observable\ncontracts.\n\n```sh\nnpm install --save-dev @rxjs/test@next rxjs@next\n```\n\n```ts\nimport 'rxjs';\nimport { rxTest } from '@rxjs/test';\nimport { map } from 'rxjs/map';\n\nawait rxTest(({ cold, expectObservable }) => {\n const source = cold('-a-b-|', { a: 1, b: 2 });\n expectObservable(source[map]((value) => value * 10)).toBe('-a-b-|', {\n a: 10,\n b: 20,\n });\n});\n```\n\nUse `cold()` only when the test deliberately needs one producer per direct\nsubscription. Use `observable()` when the contract should exercise the active\nplatform Observable constructor. The package never installs a platform\nObservable for the consumer; import `rxjs` or\n`@rxjs/observable-polyfill` first when the realm does not already provide one.\n\n`rxTest` supplies scheduled work, hot/cold/platform sources, Observable and\nsubscription expectations, explicit time plans, and configurable deep-equality\nassertions. Failures use `RxTestAssertionError` and include structured assertion\ninformation.\n\nThe package requires Node 22.13+, publishes ESM only, and declares an exact peer\non the matching RxJS 9 prerelease train. The\n[`rxjs` migration guide](https://github.com/ReactiveX/rxjs/blob/master/packages/rxjs/MIGRATION.md)\nexplains how to review lifecycle choices when translating RxJS 7\n`TestScheduler.run` tests.\n"},"files":{".agents/skills/rxjs-next-migration/.rxjs-migrate-skill.json":"{\n \"schemaVersion\": 1,\n \"packageName\": \"@rxjs/migrate\",\n \"packageVersion\": \"9.0.0-beta.0\",\n \"digestAlgorithm\": \"sha256\",\n \"digest\": \"2b5c6b52bc8060df40c48443cfb5ebb0d55da5687bb74806daf95ac4912594fa\",\n \"files\": [\n \"SKILL.md\",\n \"assets/migration-report.md\",\n \"references/assessment-and-contract.md\",\n \"references/engine-and-batches.md\",\n \"references/review-checklist.md\",\n \"references/test-migration.md\",\n \"references/verification-and-closeout.md\"\n ],\n \"installSchemaVersion\": 1,\n \"adapter\": \"agents\",\n \"compatibleHarnesses\": [\n \"codex\",\n \"cursor\"\n ],\n \"targetPath\": \".agents/skills/rxjs-next-migration\"\n}\n",".agents/skills/rxjs-next-migration/SKILL.md":"---\nname: rxjs-next-migration\ndescription: Migrate an RxJS 7 application, library, or test suite to RxJS Next through an agent-led workflow that establishes a green behavioral baseline, makes Observable lifecycle choices explicit, uses @rxjs/migrate only for bounded fixture-proved rewrites, repairs without weakening evidence, and records a versioned migration contract. Use for repository assessment, migration planning or execution, lifecycle review, TestScheduler conversion, or migration closeout.\n---\n\n# RxJS 7 to RxJS Next migration\n\nTreat this as reviewed project work, not a codemod run. The objective is an\nintentional RxJS Next contract backed by the project's own build and behavior\nevidence. A transformed file, a clean diff, or one passing test is not proof\nthat the migration is complete.\n\nWork through all eight stages in order. Re-enter an earlier stage whenever new\nevidence changes scope, coverage, or lifecycle intent. Keep the developer\ninvolved at every explicit pause.\n\n## Non-negotiable rules\n\n- Read and obey repository-local instructions before acting. Protect existing\n work and stay within the authorized repository and paths.\n- Establish the RxJS 7 baseline before changing dependencies or source.\n- Never infer platform sharing versus producer-per-direct-subscription behavior\n from syntax, filenames, operator names, or a currently passing output.\n- Use the installed engine's versioned registry and schemas as authority. Do\n not reconstruct capability mappings from this Skill or from memory.\n- Run the deterministic engine without writes first. A refusal is a successful\n safety outcome, not permission to improvise a mechanical rewrite.\n- Preserve the project's test framework by default. Select a framework adapter\n only when the developer asked for that separate conversion.\n- Do not weaken, skip, delete, or replace a behavioral expectation merely to\n make the migrated suite green.\n- Do not add RxJS 7 compatibility shims, string-named platform methods, local\n substitute operators, or runtime generators unless the developer separately\n authorizes that product work.\n- Keep changes in small coherent batches. Review and verify each batch before\n widening the scope.\n- Do not call a migration complete while a required command is unknown,\n unapproved, skipped, or red without an explicitly accepted blocker.\n\n## Working record\n\nCreate or locate a checked-in migration contract manifest and a concise\nhuman-readable report. Use the schema exported by the installed\n`@rxjs/migrate`; schema validity and migration readiness are separate checks.\nUse [assets/migration-report.md](assets/migration-report.md) for the report.\n\nFor every migration unit, preserve source locations and record:\n\n- its current RxJS 7 behavioral claim;\n- the target lifecycle selected by the developer;\n- its evidence classification and supporting tests;\n- approval state, diagnostics, and any intentional divergence; and\n- verification or a named blocker.\n\n## Stage 1: Establish authority and scope\n\n1. Locate repository instructions, package and workspace metadata, lockfiles,\n CI configuration, RxJS versions, build/test commands, and current working\n tree state.\n2. Identify the repository root, migration boundary, permitted writes,\n package manager, network policy, and candidate verification commands.\n3. Record the installed `@rxjs/migrate` version and canonical Skill digest.\n If the installed Skill does not match its package, stop and synchronize it\n before trusting these instructions.\n4. State the proposed read, write, dependency, and command scope before broad\n changes.\n\nPause for the developer if the target repository or allowed scope is unclear,\nexisting changes overlap the migration, or destructive, networked, external,\nor broader actions require new authority.\n\nExit only when the scope, allowed writes, package manager, and candidate gates\nare recorded.\n\n## Stage 2: Assess usage, lifecycle risk, and coverage\n\nInventory installed RxJS versions and import forms, then locate Observable\nconstruction, custom producers, Subjects, subscription ownership, repeated\nsubscriptions, retry/refresh/cache paths, schedulers and timing, test helpers,\ninterop inputs, cancellation, teardown, and error handling. Include direct and\ntransitive operator usage.\n\nFor each lifecycle-sensitive path, link exact source evidence and mark it as:\n\n- covered by an existing baseline;\n- requiring a characterization test;\n- explicitly unsupported; or\n- an uncovered risk the developer accepts.\n\nProduce a risk and coverage report before proposing rewrites. Read\n[references/assessment-and-contract.md](references/assessment-and-contract.md)\nfor the inventory and characterization protocol.\n\nExit only when every in-scope lifecycle-sensitive use has one recorded\ncoverage disposition. Missing coverage is not evidence that behavior is safe.\n\n## Stage 3: Establish the green RxJS 7 baseline\n\nRun the agreed build, type, lint, unit, integration, and behavior checks against\nthe unchanged RxJS 7 project. Record exact commands, environment facts, exit\ncodes, and concise results.\n\nAdd focused characterization tests where Stage 2 found material gaps. Protect\nobservable values, completion/error behavior, producer multiplicity,\ncancellation, abort reasons, teardown ordering, timing, and externally visible\nsubscription effects as applicable. Every characterization test must pass on\nRxJS 7 before migration begins.\n\nPause if a starting gate fails. Diagnose it and ask the developer whether to\nfix it first, narrow scope, or record it as an accepted pre-existing failure.\nNever silently reclassify it as a migration regression or ignore it.\n\nExit only with a green baseline or explicit approval for each named\npre-existing failure, plus green characterization tests.\n\n## Stage 4: Classify and approve the target contract\n\nDivide the scope into stable migration units. For each unit, record one target\nlifecycle using the values accepted by the installed manifest schema and one\nevidence classification. Use repository evidence and\n[references/assessment-and-contract.md](references/assessment-and-contract.md)\nto explain the choice.\n\nThe engine may identify risk but cannot choose lifecycle intent. `unresolved`\nis a stop state. Pause for the developer when either platform-shared behavior\nor producer-per-direct-subscription behavior is plausible, or when Subject\nsemantics, cancellation, scheduler ordering, error behavior, interop, or a\npublic behavior change is not proved.\n\nIntentional divergences require a concrete old claim, proposed Next claim,\nuser impact, evidence, and developer approval. Validate the manifest\nstructurally, then run the installed readiness assessment. Do not proceed with\na batch containing unresolved intent or required pending approval.\n\nExit only when the developer has approved every ambiguous choice and\nintentional divergence needed for the next batch.\n\n## Stage 5: Plan and dry-run bounded engine changes\n\nInspect the installed capability registry and select only entries whose\nversion, source form, arity, preconditions, and executable evidence match the\napproved unit. Do not infer support from a familiar name. Follow\n[references/engine-and-batches.md](references/engine-and-batches.md).\nWhen the batch contains RxJS 7 marble tests, also read\n[references/test-migration.md](references/test-migration.md).\n\nRun `rxjs-migrate` without `--write` using explicit provenance and, when\nrequired, the approved `cold` or `platform` mode. Preserve the current test\nframework unless a supported adapter was separately selected. Capture the\nversioned JSON report, changed paths, structured diagnostics, and exit code.\n\nPause when a diagnostic requires review or refuses a transform, when output\nwould escape authorized paths, when source does not match the capability\nevidence, or when batch size or semantic reach exceeds the reviewed scope.\nNever conceal unsupported segments inside a partially transformed pipeline.\n\nExit only after diagnostics and changed-file scope are reviewed and the\ndeveloper has approved any newly broadened batch.\n\n## Stage 6: Apply one small migration batch\n\nApply only the reviewed dry-run plan. Require an explicit write destination\ninside the authorized project and preserve source provenance. Do not overwrite\nexisting output without specific approval. Review the resulting diff before\nadditional edits.\n\nFormat through the project's normal tools. Ensure ordinary project-owned\nsource and direct test declarations remain; do not leave dynamic generators,\nhidden case registries, or compatibility assertion layers in the result.\n\nImmediately check parsing, the narrowest useful type boundary, and engine\nidempotence. Re-running the same transform must produce no new source change\nand stable diagnostics. If it does not, restore the affected batch to the\nreviewed starting point and report an engine defect.\n\nExit only when the batch parses, type-checks at its narrow boundary, is\nidempotent, and every diagnostic is resolved, carried forward, or escalated.\n\n## Stage 7: Build, test, diagnose, and repair\n\nRun focused characterization and migrated tests first, then the agreed project\ngates. Classify every failure as a migration defect, RxJS Next product gap,\nintentional divergence, environment/baseline issue, or still-unknown result.\nUse [references/verification-and-closeout.md](references/verification-and-closeout.md)\nfor the repair rules.\n\nRepair migration defects in a small batch and repeat the relevant gates. For a\nproduct gap, preserve the failing evidence and report it; do not disguise it\nwith a local replacement. For an intentional divergence, change an expectation\nonly after the manifest records approved new behavior and user impact.\n\nPause before any repair that changes public behavior, weakens evidence,\nexpands writes, changes dependencies beyond the reviewed plan, needs external\naccess, or introduces a compatibility layer.\n\nExit only when agreed gates pass or each remaining red result has a named,\nevidenced, explicitly accepted blocker.\n\n## Stage 8: Close out and hand off\n\nUpdate the contract manifest and report with exact source and target versions,\nengine version, capability-registry version, canonical Skill digest, baseline,\nunits, diagnostics, divergences, final commands/results, and blockers. Validate\nthe manifest with the installed schema and assess readiness separately.\n\nReview [references/review-checklist.md](references/review-checklist.md). Report:\n\n1. what behavior and lifecycle contract changed;\n2. what source and tests changed;\n3. the exact gates run and their results;\n4. migration defects repaired versus product gaps retained;\n5. approved divergences and environment limitations; and\n6. remaining blockers, owners, evidence, and acceptance.\n\nClaim completion only when readiness is `ready`, or\n`ready-with-accepted-blockers` when the developer intentionally chose that\noutcome. Otherwise hand off the migration as incomplete with the next concrete\ndecision or action.\n",".agents/skills/rxjs-next-migration/assets/migration-report.md":"# RxJS Next migration report\n\nThis report summarizes the machine-readable migration contract. The manifest\nvalidated by the installed `@rxjs/migrate` schema remains the authoritative\nstructured decision and evidence record.\n\n## Scope and authority\n\n- Repository:\n- Source revision:\n- Migration boundary:\n- Authorized write paths:\n- Package manager:\n- Network policy:\n- Existing changes protected:\n- Developer/approver:\n\n## Tool and dependency identity\n\n| Item | Version or digest | Evidence |\n| ---------------------- | ----------------- | -------- |\n| Source RxJS | | |\n| Target RxJS Next | | |\n| `@rxjs/migrate` engine | | |\n| Capability registry | | |\n| Canonical Skill | | |\n| Contract schema | | |\n\n## RxJS 7 baseline\n\n| Check ID | Command | Environment | Exit | Result | Accepted pre-existing failure |\n| -------- | ------- | ----------- | ---: | ------ | ----------------------------- |\n\n## Risk and coverage assessment\n\n| Finding | Source locations | Lifecycle/behavior risk | Coverage disposition | Evidence or approval |\n| ------- | ---------------- | ----------------------- | -------------------- | -------------------- |\n\n## Target contract units\n\n| Unit ID | Source locations | RxJS 7 claim | Target lifecycle | Evidence classification | Approval | Evidence |\n| ------- | ---------------- | ------------ | ---------------- | ----------------------- | -------- | -------- |\n\n## Migration batches\n\n| Batch | Scope | Dry-run report | Diagnostics reviewed | Write approved by | Changed files |\n| ----- | ----- | -------------- | -------------------- | ----------------- | ------------- |\n\n## Diagnostics\n\n| Diagnostic ID | File/span | Disposition | Classification | Required action | Resolution or owner |\n| ------------- | --------- | ----------- | -------------- | --------------- | ------------------- |\n\n## Intentional divergences\n\n| Units | Previous claim | Approved Next claim | User impact | Evidence | Approver/time/rationale |\n| ----- | -------------- | ------------------- | ----------- | -------- | ----------------------- |\n\n## Verification\n\n| Check ID | Command | Environment | Exit | Result | Summary |\n| -------- | ------- | ----------- | ---: | ------ | ------- |\n\n## Outcome classification\n\n### Migration defects repaired\n\n-\n\n### RxJS Next product gaps\n\n-\n\n### Environment or baseline limitations\n\n-\n\n## Accepted blockers\n\n| Owner | Affected units | Reason | Evidence | Prevented outcome | Acceptance |\n| ----- | -------------- | ------ | -------- | ----------------- | ---------- |\n\n## Readiness and handoff\n\n- Manifest schema validation:\n- Readiness assessment:\n- Remaining decisions:\n- Next action and owner:\n- Measured migration outcome and limitations:\n",".agents/skills/rxjs-next-migration/references/assessment-and-contract.md":"# Assessment, baseline, and target contract\n\nUse this reference during Stages 2 through 4. Collect evidence before asking\nthe developer to choose a target contract; ask only about intent the repository\ncannot prove.\n\n## Repository assessment\n\nRecord exact file locations and the commands or tests that exercise each\nfinding. Search application source, shared libraries, tests, configuration,\nfixtures, build tools, and framework glue for these themes:\n\n| Theme | Look for | Behavioral question |\n| --------------------- | ------------------------------------------------------------------ | ----------------------------------------------------------------- |\n| Construction | `new Observable`, `defer`, custom producers, wrappers | When is producer work created and restarted? |\n| Repeated subscription | retry, refresh, fan-out, cache invalidation, multiple consumers | Must consumers run independent work or share one active run? |\n| Subjects | current/replayed values, late subscribers, terminal state | What exists before observation and what must late observers see? |\n| Ownership | captured subscriptions, `unsubscribe`, component disposal | Who cancels, with what reason, and when does upstream stop? |\n| Teardown | multiple teardown callbacks, finalizers, resource release | Does observable order matter? |\n| Timing | schedulers, timers, animation, queue ordering, virtual time | Which host timing boundary preserves the claim? |\n| Errors | selector errors, observer callback errors, late errors | Where must the error be delivered or reported? |\n| Inputs | iterables, async iterables, promises, custom subscribables | Is the value accepted by the platform conversion boundary? |\n| Composition | pipeable operators, aliases, higher-order pipelines | Is a fixture-proved Symbol mapping available for this exact form? |\n| Testing | TestScheduler helpers, framework assertions, native/polyfill setup | Which claims are real behavior and which are harness machinery? |\n\nTrace imports and helper wrappers so transitive usage is not mistaken for\nabsence. Sampling is acceptable only when its limits are named and accepted.\n\n## Coverage disposition\n\nGive every lifecycle-sensitive finding exactly one disposition:\n\n- **Covered:** a named existing test proves the relevant behavior.\n- **Characterize:** add a focused RxJS 7 test before migration.\n- **Unsupported:** no accepted Next surface can preserve the required claim;\n retain evidence and record a product gap.\n- **Accepted uncovered risk:** the developer explicitly accepts proceeding\n without the missing evidence; record approver, time, rationale, and impact.\n\nRecommend characterization for repeated subscriptions, side effects, sharing,\nlate subscribers, cancellation, teardown, timing, errors, or public API behavior\nwhen current tests do not prove the outcome.\n\n## Characterization protocol\n\nAdd the narrowest test that proves an externally meaningful claim. Prefer\nassertions over values, completion/error, producer start count, concurrent and\nlate observations, cancellation ownership, abort reason, teardown order,\nvirtual or host timing, and visible side effects. Avoid locking in irrelevant\nRxJS 7 internals.\n\nRun the new test on the unchanged RxJS 7 dependency. Record the exact command\nand result. A characterization test added after dependency migration is not an\nRxJS 7 baseline unless it is separately demonstrated against the pinned source\nenvironment.\n\n## Lifecycle decision record\n\nUse only lifecycle values accepted by the installed contract-manifest schema.\nExplain each selection in behavioral language:\n\n- active platform producer shared and ref-counted while observers exist;\n- producer work created per direct subscription through an explicit Next API;\n- intentional hot Subject behavior;\n- no producer lifecycle applies;\n- required behavior is unsupported; or\n- intent remains unresolved.\n\nDo not use a blanket “hot” or “cold” label for a platform Observable. The first\nobserver starts an active producer, concurrent observers join it, the last\nobserver leaving tears it down, and a later observer can start a new run.\n\nFor every unit, record:\n\n1. stable ID and exact source spans;\n2. current RxJS 7 claim and evidence;\n3. selected target lifecycle;\n4. compatibility/evidence classification accepted by the installed schema;\n5. one or more target claims;\n6. approval status, approver, timestamp, and rationale when required; and\n7. related diagnostics, divergences, and blockers.\n\n## Mandatory developer pauses\n\nPause rather than infer when:\n\n- both independent and shared producer behavior are plausible;\n- repeated subscriptions may implement retry, refresh, cache, or fan-out;\n- Subject replay, terminal, or late-observer behavior is unproved;\n- cancellation ownership, abort reason, or teardown order could change;\n- scheduler removal could alter ordering;\n- a custom subscribable is outside the accepted conversion boundary;\n- a public claim changes or an expectation would need to change;\n- coverage is missing or the baseline is not green; or\n- a unit remains unresolved, unsupported without acceptance, or pending\n approval in the readiness assessment.\n\nThe engine's diagnostic can identify a pause condition, but only the developer\ncan approve lifecycle intent or an intentional divergence.\n",".agents/skills/rxjs-next-migration/references/engine-and-batches.md":"# Engine registry and migration batches\n\nUse this reference during Stages 5 and 6. `@rxjs/migrate` is a deterministic\nengine for a bounded syntax subset. It is not an autonomous repository\nmigration tool.\n\n## Consume installed contracts\n\nRead engine data from the project's installed package, not from a list copied\ninto a prompt, Skill, or harness adapter. The public API exports the default\ncapability registry, registry and manifest schemas, migration functions,\ncontract readiness assessment, and engine/schema versions.\n\nA local inspection can use the project's module runner with this shape:\n\n```js\nimport { assessMigrationContractReadiness, defaultCapabilityRegistry, migrationContractManifestSchema } from '@rxjs/migrate';\n\nfor (const capability of defaultCapabilityRegistry.capabilities) {\n // Review id, legacy/source name, target Symbol, adapter, arity,\n // preconditions, status, and fixture evidence for this exact package.\n}\n\nconst parsed = migrationContractManifestSchema.safeParse(manifest);\nif (parsed.success) {\n const readiness = assessMigrationContractReadiness(parsed.data, {\n expectedSkillDigest,\n });\n}\n```\n\nObtain `expectedSkillDigest` from the installed adapter's integrity check or\nthe Node-only `@rxjs/migrate/skill` API. Consult the installed TypeScript\ndeclarations for exact signatures. Refuse an incompatible custom registry\nrather than adapting it informally. A registry entry proves only the source\nforms, overloads, preconditions, and fixtures it names; it does not promise\ngeneral RxJS 7 compatibility.\n\n## Capability selection\n\nBefore selecting a transform, verify all of the following:\n\n- registry schema, registry version, and engine version match the installed\n package;\n- the source import binding is the one identified by the engine and is not\n shadowed or repurposed;\n- the call shape, arity, scheduler/result-selector form, and pipeline context\n satisfy every declared precondition;\n- the fixture evidence covers the intended mapping and evidence class; and\n- the migration unit already has an approved lifecycle contract.\n\nName similarity, a compatible TypeScript signature, or a green transformed\ntest is not a substitute for those checks.\n\n## Dry-run protocol\n\nInvoke the locally installed `rxjs-migrate` binary through the project's\npackage manager. Supply all required provenance. For example:\n\n```sh\nrxjs-migrate \\\n --source-root \\\n --source-repo \\\n --source-sha \\\n --mode \\\n --framework preserve \\\n \n```\n\nOmit `--mode` when the selected source does not require a lifecycle choice.\nNever let a directory name or wrapper select it implicitly. Use the package's\ndocumented framework adapter only for a separately approved framework change.\n\nWithout `--write`, the CLI returns a versioned JSON report and performs no\nwrites. Record its engine version, registry version, operation, file results,\nordered diagnostics, and exit status. The current CLI contract distinguishes\ncompleted, structured refusal, invalid arguments, and operational failure;\nread the installed package documentation for the exact numeric codes.\n\nReview every diagnostic, including source span, severity, disposition, refusal\nscope, classification, next action, and capability ID when present. A refused\nbatch must leave source and destination unchanged.\n\n## Write protocol\n\nAfter the dry run and changed paths are approved, repeat the same inputs with\nan explicit contained destination:\n\n```sh\nrxjs-migrate \\\n --source-root \\\n --source-repo \\\n --source-sha \\\n --mode \\\n --framework preserve \\\n --write --out-dir \\\n \n```\n\nThe engine plans the whole batch before writing and refuses lexical, canonical,\nor symlink path escape. Do not bypass containment or no-overwrite behavior with\nmanual bulk writes. If the reviewed destination is the current source tree,\nmake that scope and overwrite decision explicit and keep recovery possible.\n\nCompare the write report with the dry run byte for byte where contractual.\nInspect the diff for:\n\n- provenance and filenames;\n- exact Symbol imports and calls;\n- preserved unsupported source;\n- lifecycle helper selection;\n- awaited asynchronous test helpers;\n- framework preservation or the separately selected adapter;\n- retained assertions, errors, subscription claims, and local helpers; and\n- absence of hidden generators or compatibility layers.\n\nThen run the same transform again without writes. The second result must be\nunchanged with stable diagnostics. Any output or diagnostic drift is an engine\ndefect; stop the batch and preserve a reproduction.\n\n## Refusal and manual repair\n\nDo not turn refused syntax into claimed mechanical output by editing around the\ndiagnostic. Carry the finding into the contract and choose one of these paths:\n\n1. narrow the batch to independently safe units;\n2. add characterization, obtain a developer decision, and make a reviewed\n semantic edit outside the engine's claimed output;\n3. report an RxJS Next product gap; or\n4. preserve the source and accept a named blocker.\n\nManual work remains subject to the same baseline, lifecycle, review, and\nverification gates. It must not be described as fixture-proved engine output.\n",".agents/skills/rxjs-next-migration/references/review-checklist.md":"# Migration closeout checklist\n\n## Authority and provenance\n\n- Repository instructions, scope, allowed writes, package manager, and network\n policy were recorded before broad changes.\n- Existing work was protected and every changed file is within the authorized\n migration boundary.\n- Source repository/revision, RxJS versions, engine version, registry version,\n and canonical Skill digest are exact and reproducible.\n- The installed Skill content matches the installed `@rxjs/migrate` package.\n\n## Baseline and coverage\n\n- Agreed build, type, lint, test, and behavior gates were run on unchanged\n RxJS 7 source.\n- Every baseline failure is either fixed or explicitly recorded as pre-existing\n with developer acceptance.\n- Each lifecycle-sensitive path is linked to existing coverage,\n characterization, explicit unsupported status, or an accepted uncovered\n risk.\n- Characterization tests passed against RxJS 7 before dependency/source\n migration.\n\n## Target contract\n\n- Every unit has stable source locations, a behavioral claim, one target\n lifecycle, an evidence classification, and supporting evidence.\n- No required unit remains unresolved or pending approval.\n- Platform sharing and producer-per-direct-subscription behavior were selected\n intentionally rather than inferred from syntax.\n- Subjects, repeated subscriptions, cancellation, teardown, timing, errors,\n and input conversion were reviewed where applicable.\n- Every intentional divergence records old and new claims, user impact,\n evidence, approver, timestamp, and rationale.\n\n## Mechanical batches\n\n- Capability decisions came from the installed versioned registry; no copied\n operator list or name-only match was used.\n- Each engine operation ran dry first with exact provenance and an explicit\n lifecycle mode when required.\n- The dry-run scope, diagnostics, and changed paths were reviewed before write.\n- Refused or unsupported source remains visible and was not smuggled through a\n partial transform.\n- Writes stayed within the approved destination and did not overwrite local\n content without explicit approval.\n- Output preserves ordinary project-owned source, direct tests, assertions,\n and the selected framework.\n- Every applied transform is parseable, type-checkable at its narrow boundary,\n and idempotent with stable diagnostics.\n\n## Verification and handoff\n\n- Focused characterization/migrated tests and all agreed project gates were\n run with exact commands, environments, exit codes, and results.\n- Failures are classified as migration defects, product gaps, intentional\n divergences, baseline/environment issues, or unresolved—not relabeled for a\n green report.\n- No test was weakened, skipped, deleted, or replaced without explicit\n developer approval and a recorded contract change.\n- Schema validation and readiness assessment were both run; one is not being\n used as a substitute for the other.\n- All diagnostics are resolved, carried with an owner, or represented by an\n explicitly accepted blocker.\n- The final report states measured outcomes and limitations without claiming\n general automatic migration.\n",".agents/skills/rxjs-next-migration/references/test-migration.md":"# TestScheduler and marble-test migration\n\nUse this reference only for selected RxJS 7 `TestScheduler` or marble tests.\nPreserve behavioral evidence and the project's ordinary test conventions.\n\n## Preserve the outer framework\n\nKeep the project's `describe`, `it`, `test`, hooks, assertion library, spies,\nand configuration by default. Treat a requested framework change as a separate\nadapter over the same migrated test body. If the installed engine does not\nsupport the requested source/target pair, preserve the framework and report\nthe conversion as manual work rather than guessing globals or assertions.\n\nEmit direct, readable test declarations. Materialize selected parameterized\ncases when necessary; do not introduce a runtime loop, hidden registry,\ngenerated location shim, or generator warning.\n\n## Preserve provenance and claims\n\nRecord the source repository, exact revision, and source path for every\nmigrated file. State the old case's behavioral claim before editing it. Keep\ncase-level comments only where they explain a real lifecycle, scheduler,\ncancellation, or divergence decision.\n\nTreat analyzer fingerprints as duplicate candidates, never automatic deletion.\nConsolidate only when public API/overload, lifecycle, values, timing, completion,\nerrors, cancellation, subscription claim, and relevant type behavior all\nmatch. Retain links to every original case in the manifest/report.\n\n## Convert harness structure\n\nReplace a supported `TestScheduler.run(...)` wrapper with one direct `rxTest`\ncall. Remove a scheduler variable, constructor, matcher adapter, or setup hook\nonly when it has no other responsibility. Return or await the `Promise`\nfrom `rxTest` through the outer test.\n\nPreserve the meaning of supported helpers:\n\n- `cold()` represents producer-per-subscription evidence;\n- `hot()` represents a subject-like absolute timeline;\n- `observable()` represents the shared, ref-counted platform producer;\n- `expectObservable()` retains cancellation from the subscription marble;\n- `expectSubscriptions()` describes observer subscriptions for cold sources\n and producer activation windows for platform sources;\n- `time()` and `animate()` use the `@rxjs/test` virtual host boundary; and\n- `flush()` is asynchronous and must be awaited from an `async` callback.\n\nRefuse or manually classify direct scheduler state, methods used outside the\nsupported run callback, scheduler subclasses, implementation-only queue/frame\nassertions, or unsupported framework assertions. Do not erase them as obsolete\nwithout a reviewed evidence classification.\n\n## Convert composition through the registry\n\nFor each RxJS 7 pipeable call, look up the exact installed capability entry and\napply only its declared Symbol target, argument adapter, arity, preconditions,\nand fixture-proved source shape. Convert a supported sequence into successive\nexact-Symbol calls and import those Symbols from the declared modules.\n\nDo not copy a table of operator mappings into project guidance. Do not use a\nplatform string method because its description matches an RxJS 7 operator.\nPreserve unsupported overloads and mixed pipelines with their diagnostics.\n\nUse an ambient/global `Observable` when the accepted target contract requires\nplatform construction. Do not import the constructor from a polyfill merely to\nmake a test pass.\n\n## Review lifecycle and realms\n\nKeep a producer-per-subscription baseline visibly separate from platform\ncoverage. For the platform lifecycle, test first activation, concurrent join,\nlate observation, individual abort, final abort/teardown, and later restart as\napplicable.\n\nRun the same platform claim against fallback and native implementations where\nthe project supports both. Initialize each in an isolated process, worker,\nwindow, or iframe before importing RxJS extensions and tests. If the realm has\nno native `Observable`, record native mode as unavailable; never install the\nfallback and label the result native.\n\nRemove scheduler arguments only when the installed target capability and its\nfixtures prove a host-timed mapping that `rxTest` virtualizes. Preserve original\nerror values and ordinary non-marble assertions. If product behavior fails a\nfaithful migrated claim, retain the evidence as a product gap rather than\nchanging production code or weakening the expectation.\n",".agents/skills/rxjs-next-migration/references/verification-and-closeout.md":"# Verification, repair, and closeout\n\nUse this reference during Stages 7 and 8. Outcome evidence outranks source\nshape.\n\n## Verification ladder\n\nRun checks from narrowest to broadest so a failure remains diagnosable:\n\n1. parse and format the changed files;\n2. run focused type checks;\n3. run characterization and directly migrated tests;\n4. run the affected package or workspace build, type, lint, and test gates;\n5. run agreed integration, browser, native/polyfill, or repository-wide gates;\n6. repeat any command whose environment was changed during diagnosis.\n\nRecord the exact command, relevant environment facts, exit code, status, and a\nconcise summary. “Passed locally” without a command and environment is not a\nverification record.\n\nFor lifecycle-sensitive code, verify the contract actually selected:\n\n- producer activation count and restart;\n- concurrent and late observation;\n- individual and final cancellation;\n- abort reason and upstream closure;\n- Subject current/replay/terminal behavior;\n- teardown ordering;\n- time and scheduling order;\n- error delivery and late/unhandled error behavior; and\n- input conversion acceptance or explicit refusal.\n\n## Failure classification and response\n\n| Class | Meaning | Required response |\n| ---------------------- | -------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------- |\n| Migration defect | The edit broke syntax, types, test intent, mapping, or selected contract | Repair a small batch and rerun affected gates |\n| RxJS Next product gap | The accepted target surface cannot satisfy preserved evidence | Keep evidence visible; report the product gap |\n| Intentional divergence | Approved Next behavior differs from the RxJS 7 claim | Record old/new claims, impact, evidence, and approval before changing expectations |\n| Baseline/environment | The failure existed before migration or the required runtime/tool is unavailable | Preserve its original status and record the limitation or accepted failure |\n| Unknown | Evidence does not yet identify the cause | Investigate or pause; never relabel for convenience |\n\nAllowed repairs clarify or correct migrated code, strengthen characterization,\nor fix a demonstrated migration defect while preserving the approved contract.\n\nThe following require a developer pause:\n\n- deleting, skipping, quarantining, or weakening a test;\n- changing a public behavioral claim;\n- adding a local operator, scheduler, compatibility facade, or assertion shim;\n- changing platform behavior to imitate RxJS 7;\n- broad dependency or configuration changes beyond reviewed scope; or\n- accepting a red or unrun required gate.\n\n## Manifest closeout\n\nBuild the manifest against the exact schema exported by the installed package.\nAt minimum, record the schema and engine identity required by that version,\ncapability-registry version, canonical Skill digest, exact source and target\nRxJS versions, baseline checks, migration units, diagnostics, intentional\ndivergences, verification results, and blockers.\n\nStructural validity answers only “is this shaped correctly?” Run the separate\nreadiness assessment to detect unresolved lifecycle units, pending approvals,\nunresolved/refused diagnostics, unapproved divergences, missing or red gates,\nidentity mismatches, and unaccepted blockers.\n\nAn accepted blocker must name:\n\n- its owner and reason;\n- affected units;\n- supporting evidence;\n- the behavior, environment, or release claim it prevents; and\n- explicit developer acceptance.\n\nDo not use a blocker to hide an unexplained regression. A migration may close\nas `ready-with-accepted-blockers` only when the installed readiness assessment\nreturns that state and the human-readable report makes the limitations clear.\n\n## Final handoff\n\nUse the report asset to summarize:\n\n- scope and provenance;\n- installed engine, registry, Skill, source RxJS, and target RxJS identity;\n- RxJS 7 baseline and characterization evidence;\n- lifecycle decisions and approvals;\n- changed source and tests by coherent batch;\n- exact final commands and results;\n- diagnostics and how each was resolved or carried;\n- repaired migration defects;\n- remaining product gaps, divergences, and environment limits; and\n- blocker ownership and next actions.\n\nDo not report “automatic migration succeeded.” State the measured project\noutcome and its limits.\n","AGENTS.md":"# RxJS Next repository guidance\n\nThis branch is the foundation for a new platform-based generation of RxJS, with\nthe working name **RxJS Next** and a probable release name of **RxJS 9**. It is\nnot an incremental RxJS 7 implementation.\n\nBefore making changes, read these documents in order:\n\n1. `docs/rxjs-next/PROJECT_CHARTER.md`\n2. `docs/rxjs-next/ARCHITECTURE.md`\n3. `docs/rxjs-next/DECISIONS.md`\n4. `docs/rxjs-next/PROJECT_PLAN.md`\n5. `docs/rxjs-next/OPEN_QUESTIONS.md`\n6. `docs/rxjs-next/COMPATIBILITY.md` when changing APIs or behavior\n\n## Required working rules\n\n- Treat the current code as an exploratory implementation, not the completed\n architecture. Preserve the distinction between current behavior, accepted\n direction, and proposals.\n- Use the native web-platform `Observable` when it exists. A polyfill must not\n replace a conforming native implementation.\n- Add RxJS behavior to the platform constructor or its prototype through\n exported Symbols. Do not add string-named RxJS methods to the platform\n `Observable` surface.\n- Export corresponding RxJS Symbols even for operators that already have a\n platform string method, such as `map` and `filter`. Preserve both forms:\n `observable.map(project)` is the platform contract and\n `observable[map](project)` is the RxJS contract. The Symbol form may delegate\n or add functionality, but it must not replace the string method; document and\n test every intentional difference.\n- Preserve the collision isolation of exact Symbol keys: unrelated code using\n the same descriptive name must not be able to overwrite an RxJS extension.\n Do not introduce `Symbol.for` keys without an accepted namespacing and\n duplicate-install decision.\n- Keep platform semantics and RxJS 7 compatibility semantics in separate\n architectural layers. In particular, do not silently make the platform\n `Observable` behave like an RxJS 7 cold observable.\n- Use `AbortSignal` and the platform `Subscriber` lifecycle as the cancellation\n foundation for the platform layer.\n- Do not assume the old RxJS 7 tests can pass unchanged. Classify every migrated\n test according to the compatibility policy in `COMPATIBILITY.md`.\n- Do not revive removed RxJS 7 internals in the platform package to make a test\n pass. Put compatibility behavior behind an explicit compatibility boundary.\n- When implementing against the living Observable specification or Web\n Platform Tests, record the exact upstream revision used.\n- Preserve RxJS 7 history. The old implementation remains an important source\n of behavioral tests, migration knowledge, and compatibility requirements.\n\n## Project-plan discipline\n\n`docs/rxjs-next/PROJECT_PLAN.md` is the active execution queue. Work on the\nsingle item marked `NEXT` unless the user explicitly changes priorities or a\nsmall prerequisite is required. Keep exactly one `NEXT` item, update the\ncompletion evidence, and append a short session-log entry when completing a\nplan item.\n\n## Architecture-change discipline\n\nUpdate the documentation in the same change when code alters any of these:\n\n- package or import boundaries;\n- native-versus-polyfill selection;\n- Symbol identity or patch installation;\n- subscription sharing, ref counting, cancellation, or teardown;\n- subclass or realm behavior;\n- compatibility guarantees;\n- public exports;\n- test or conformance gates.\n\nRecord durable decisions in `docs/rxjs-next/DECISIONS.md`. Move unresolved\nquestions into or out of `docs/rxjs-next/OPEN_QUESTIONS.md` as evidence changes.\n\n## Verification\n\nRun the narrowest relevant tests and build/type checks. Record failures\nhonestly; do not treat a passing unit test as proof of platform conformance.\nThe current known baseline is documented in `ARCHITECTURE.md`.\n","apps/rxjs.dev/tools/README.md":"# AIO project tooling\n\nThis document gives an overview of the tools that we use to generate the content for the RxJS website.\n\nThe application that actually renders this content can be found in the `apps/rxjs.dev/src` folder.\nThe handwritten content can be found in the `apps/rxjs.dev/content` folder.\n\nEach subfolder in this `apps/rxjs.dev/tools/` folder contains a self-contained tool and its configuration. There is\na `README.md` file in each folder that describes the tool in more detail.\n\n## transforms\n\nAll the content that is rendered by the RxJS docs application, and some of its configuration files,\nare generated from source files by [Dgeni](https://github.com/angular/dgeni). Dgeni is a general\npurpose documentation generation tool.\n\nMarkdown files in `apps/rxjs.dev/content`, code comments in the core Angular source files and example\nfiles are processed and transformed into files that are consumed by the RxJS docs application.\n\nDgeni is configured by \"packages\", which contain services and processors. Some of these packages are\ninstalled as `node_modules` from the [dgeni-packages](https://github.com/angular/dgeni-packages) and\nsome are specific to the RxJS project.\n\nThe project specific packages are stored in the `apps/rxjs.dev/tools/transforms` folder. See the\n[README.md](transforms/README.md) for more details.\n","apps/rxjs.dev/tools/transforms/README.md":"# Overview\n\nAll the content that is rendered by the AIO application, and some of its configuration files, are\ngenerated from source files by [Dgeni](https://github.com/angular/dgeni). Dgeni is a general purpose\ndocumentation generation tool.\n\nMarkdown files in `/aio/content`, code comments in the core Angular source files and example files\nare processed and transformed into files that are consumed by the AIO application.\n\nDgeni is configured by \"packages\", which contain services and processors. Some of these packages are\ninstalled as `node_modules` from the [dgeni-packages](https://github.com/angular/dgeni-packages) and\nsome are specific to the AIO project.\n\nThe project specific packages are stored in this folder (`aio/tools/transforms`).\n\nIf you are an author and want to know how to generate the documentation, the steps are outlined in\nthe top level [README.md](../../README.md#guide-to-authoring).\n\n## Root packages\n\nTo run Dgeni, you must specify a root package, which acts as the entry point to the documentation\ngeneration.\nThis root package, in turn requires a number of other packages, some are defined locally in the\n`tools/transforms` folder, such as `tools/transforms/cheatsheet-package` and\n`tools/transforms/content-package`, etc. And some are brought in from the `dgeni-packages` node\nmodules, such as `jsdoc` and `nunjucks`.\n\n* The primary root package is defined in `tools/transforms/angular.io-package/index.js`. This package\nis used to run a full generation of all the documentation.\n* There are also root packages defined in `tools/transforms/authors-package/*-package.js`. These\npackages are used by the documentation authors when writing docs, since it allows them to run partial\ndoc generation, which is not complete but is faster for quickly seeing changes to the document that\nyou are working on.\n\n## Other packages\n\n* angular-base-package\n* angular-api-package\n* angular-content-package\n* content-package\n* links-package\n* post-process-package\n* remark-package\n* target-package\n\n## Templates\n\nAll the templates for the angular.io dgeni transformations are stored in the `tools/transforms/templates`\nfolder. See the [README](./templates/README.md).\n","apps/rxjs.dev/tools/transforms/rxjs-decision-tree-generator/README.md":"# Decision Tree Generator\n\n## Purpose\n\nManage a decision tree in YAML for choosing an operator and generate JSON to be consumed by the docs web app.\n\n## Goals\n\n- Port the first version of the decision-tree-widget into Angular\n- Flatten the JSON structure and make it easy to work with in the docs web app\n- Consume URI paths and other relevant from the docs generation task vai Dgeni\n- Keep the decision tree work scalable and easy to work with by keeping the linked list structure in the YAML tree\n\n## Prior Art\n\nVersion 1 was in the old docs site and used YAML, snabbdom, RxJS, and hyperscript-helpers. The YAML for version 1 version was ported into the new version with minor tweaks.\n\n## Tech\n\n- Node\n- TypeScript\n- TS-Node\n- Jest\n- YAML\n\n## Dependencies\n\nGenerating the JSON requires:\n\n- The decision tree YAML, located in `/src`\n- The generated `api-list.json`, which can be generated by running `pnpm run docs` at the root level of `apps/rxjs.dev`\n\n## Setup & Build\n\n```shell\npnpm install && pnpm run build\n```\n\n## Development\n\nAny changes to the YAML tree or any of the TypeScript scripts will generate a new JSON tree\n\n```shell\npnpm run watch\n```\n\n## Distribution\n\nAfter a `pnpm run build` the JSON is output to `apps/rxjs.dev/src/generated/app/decision-tree-data.json` to be consumed by the web application.\n\nThere's also an npm script at the root level of the `apps/rxjs.dev` to generate the JSON tree: `docs-decision-tree`.\n\n## Testing\n\nRun a watch task when writing tests\n\n```shell\npnpm run test:watch\n```\n\nFull test\n\n```shell\npnpm run test\n```\n\nRun coverage\n\n```shell\npnpm run test:coverage\npnpm run test:watch:coverage\n```\n\n## TODO\n\n- Consider moving this work into a Dgeni package so it can be generated in the same way the other doc information is generated\n","apps/rxjs.dev/tools/transforms/templates/README.md":"This folder contains the dgeni templates that are used to generate the API docs\n\nGenerally there is a template for each docType. Templates can extend and/or include\nother templates. Templates can also import macros from other template files.\n\n# Template inheritance\n\nWhen extending a template, parent must declare blocks that can be overridden by the\nchild. The template extension hierarchy looks like this (with declared blocks in parentheses):\n\n- layout/base.template.html (base)\n - module.template.html\n - layout/api-base.template.html (jumpNav, jumpNavLinks, whatItDoes, infoBar, securityConsiderations,\n deprecationNotes, howToUse, details)\n - class.template.html\n - directive.template.html\n - enum.template.html\n - var.template.html\n - const.template.html\n - let.template.html\n - decorator.template.html\n - function.template.html\n - interface.template.html\n - type-alias.template.html\n - pipe.template.html\n\n# Doc Properties\n\nIt is useful to know what properties are available on each doc type when working with the templates.\nThe `typescript` Dgeni package is now written in TypeScript and there is a class for each of the types of\nAPI document. See https://github.com/angular/dgeni-packages/tree/master/typescript/src/api-doc-types.\nThis is a good place to go to see what properties you can use in the templates.","packages/migrate/README.md":"# `@rxjs/migrate`\n\nDeterministic source-migration tools used by the RxJS 9 agent-first\nmigration workflow. The current well-tested path migrates RxJS 7\n`TestScheduler` marble specs from Mocha/Chai to ordinary Vitest specs that call\n`rxTest` directly. The engine is not a complete migration product and does not\nchoose lifecycle semantics; see\n[`docs/MIGRATION_TOOLING_DESIGN.md`](docs/MIGRATION_TOOLING_DESIGN.md).\n\nThe package separates two concerns:\n\n- RxJS semantics: `TestScheduler.run` to `rxTest`, pipeable operators to exact\n Symbol calls, and reviewed argument adapters.\n- Test framework syntax: an optional Mocha/Chai-to-Vitest adapter. Other\n source and target frameworks can supply the same small `FrameworkAdapter`\n interface, or preserve their existing framework unchanged.\n\nThe semantic transform also operates on production TypeScript containing\nRxJS 7 `pipe(...)` expressions. It does not require a test framework or a\n`TestScheduler` declaration.\n\n## CLI\n\nStart with a dry run:\n\n```sh\nnpx rxjs-migrate \\\n --source-root . \\\n --source-repo https://github.com/example/project \\\n --source-sha abc123 \\\n --mode cold \\\n --framework mocha-chai-vitest \\\n test/example-spec.ts\n```\n\nThe command writes nothing unless `--write --out-dir ` is present.\nWritten files are normal, locally named source files. They are meant to be\nreviewed, checked in, and maintained by the destination project; there is no\nruntime generator. Successful and refused batches are emitted as versioned\nJSON with the engine and capability-registry versions. Exit codes distinguish\nsuccess (`0`), a structured migration refusal (`1`), invalid arguments (`2`),\nand operational failure (`3`). A refused batch writes no files.\n\nUse `--framework preserve` for Jest, Node test runner, another target, or a\nframework migration handled by another tool. The JavaScript API accepts a\ncustom `FrameworkAdapter` when syntax conversion should happen in the same\npass.\n\n## JavaScript API\n\n```ts\nimport { defaultCapabilityRegistry, migrateTestSource, type FrameworkAdapter } from '@rxjs/migrate';\n\nconst result = migrateTestSource(source, {\n mode: 'cold',\n capabilityRegistry: defaultCapabilityRegistry,\n frameworkAdapter: myFrameworkAdapter satisfies FrameworkAdapter,\n provenance: {\n repository: 'https://github.com/example/project',\n sha: 'abc123',\n path: 'test/example-spec.ts',\n },\n});\n```\n\n`defaultCapabilityRegistry` is a versioned, fixture-backed contract, not a\nclaim of complete RxJS 7 compatibility. A custom registry must use the same\nschema and name the installed engine version; incompatible registries are\nrefused without changing source bytes. Unsupported constructs remain visible\nas diagnostics instead of being hidden behind compatibility helpers.\n\n## Mechanically supported subset\n\nThe default registry currently proves direct, unshadowed `pipe(...)` calls for\n`filter`, `map`, `takeUntil`, `bufferCount`, `concatMap`, `concatAll`,\n`switchAll`, `debounceTime`, `audit`, and `auditTime`, subject to each mapping's\npublished arity and overload preconditions. The registry is the authoritative\nmachine-readable list. Aliases are tracked, while shadowed bindings, mixed\nunsupported pipelines, scheduler overloads, malformed input, and unsupported\nframework assertions are refused or preserved with structured findings.\n\nThe package ships no MCP binary, export, or runtime dependency. D-046 keeps\nthe library and dry-run-first CLI as the only deterministic engine surfaces.\n\nThe representative agent-workflow matrix and its deliberately bounded claims\nare documented in\n[`docs/MIGRATION_QUALIFICATION.md`](docs/MIGRATION_QUALIFICATION.md).\nLive harness qualification is separate from deterministic engine correctness.\n\n## Contract and Skill integrity\n\n`parseMigrationContractManifest` validates the versioned migration decision\nrecord. `assessMigrationContractReadiness` separately reports unresolved\nlifecycle choices, approvals, diagnostics, verification, and blockers so\nschema validity is never mistaken for completion.\n\nThe Node-only `@rxjs/migrate/skill` subpath computes and verifies the canonical\nSkill's deterministic SHA-256 content descriptor and manages generated harness\ndiscovery copies without creating a second authored workflow.\n\nInstall the canonical Skill into a repository with the package command:\n\n```sh\nnpx rxjs-migrate-skill install --harness codex --project-root .\n```\n\nUse `--harness cursor` for Cursor; Codex and Cursor share the open\n`.agents/skills` placement. Use `--harness claude` for Claude Code's\n`.claude/skills` placement. The same command supports `check`, `update`, and\n`remove`. It refuses to overwrite or remove local modifications unless the\ndeveloper supplies `--force`, and each installed copy records its package\nversion and canonical digest in `.rxjs-migrate-skill.json`.\n\n## Review requirements\n\nEvery migrated test should contain a direct `await rxTest(...)` call. Choose\n`cold()` only for producer-per-subscription evidence; use `observable()` when\nthe test should exercise the constructor installed at\n`globalThis.Observable`. Review scheduler arguments, multiple observations,\nsharing, ref counting, cancellation, and restart behavior before accepting a\nmechanical migration.\n","packages/migrate/docs/MIGRATION_QUALIFICATION.md":"# RxJS Next migration workflow qualification\n\n## Status\n\nP0.M5 is complete. All four checked-in Codex/ChatGPT runs pass the pinned seed,\nbehavior, authority, artifact, and semantic outcome gates: three end in an\napproved completed migration and the weak-coverage/unsupported repository ends\nin its required safe stop. Per D-047, this P0 qualification is intentionally\nlimited to Codex/ChatGPT. It does not claim Claude Code or Cursor outcome\nqualification, cross-harness parity, or general automatic migration safety.\n\nP5.2 is also complete by closure audit. Its planned mechanical and semantic\napplication-validation outcome was already satisfied by the P0.M3 deterministic\nfixtures, P4.4 accepted contract fixtures, and P0.M5 four-repository outcome\nmatrix. The closure audit reruns those offline gates and maps them to the\npackage-local migration guide; it does not spend another live-model cycle or\nexpand the original qualification claim.\n\n## P5.2 guide-to-evidence map\n\n| Migration-guide step | Representative evidence |\n| --------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Establish a green RxJS 7 baseline | Four pinned seed repositories, framework-specific baseline commands, immutable dependency descriptors, and executable seed oracles |\n| Inventory affected surfaces and coverage gaps | Application/library scenarios spanning Vitest, Mocha, Jest, strong and weak coverage, scheduler, interop, Subject, sharing, and repeated-subscription behavior |\n| Select an explicit lifecycle contract | Cold-preserving, platform-shared, mixed, and unsupported contract manifests with developer-owned decision vectors |\n| Apply only proven mechanical changes | Versioned capability registry, exact transform fixtures, compilation, idempotence, structured diagnostics, and refusal-safe batch writes |\n| Review semantic boundaries | Held-out producer multiplicity, sharing/ref counting, cancellation, teardown, timing, errors, input conversion, Subject state, and restart assertions |\n| Finish green or stop safely | Three completed migrations pass target build and protected behavior; the weak unsupported repository stops before target installation or migration writes |\n\nThe checked-in P4.4 contract fixtures provide a smaller executable cross-check\nfor all four guide outcomes: `cold-preserving`, `platform-shared`,\n`subject-hot`, and `safe-stop`. A lifecycle-swap negative control prevents a\nsyntactically valid rewrite from being counted as a semantic success.\n\n## Evidence boundary\n\nThe qualification has two distinct lanes:\n\n- deterministic engine fixtures prove exact transforms, structured refusals,\n compilation, idempotence, behavior, path containment, and package contracts;\n- agent scenarios permit source variation but require the same behavioral,\n approval, diagnostic, test-integrity, and artifact gates.\n\nA passing engine fixture is not a passing agent migration. A plausible agent\nreport is not a passing run until its seed identity, chronology, commands,\nmanifest, protected tests, held-out behavior, and captured artifact digests\npass the offline grader.\n\nEach committed record has five hashed artifacts: the exact user prompt and\nfinal response retained as `conversation.md`, the contract manifest, patch,\ncommand results, and final report. The command-results artifact, patch, and\nrecorded observed-authority actions provide the reviewable command/tool\nevidence. Full host event streams were not retained for the first three runs,\nso the conversation artifact must not be described as a complete tool-call\ntranscript. The fourth run was repeated after authority controls were tightened;\nonly its passing record belongs to the closed matrix.\n\n## Representative repositories\n\nThe four immutable seed trees live under\n`packages/migrate/test/agent/fixtures`. Each pins RxJS `7.8.1`, its dependency\ndescriptor, a complete pnpm lockfile, runnable framework-specific baseline\ncommands, and the complete seed-tree digest.\n\n| Scenario | Layout | Framework | Coverage | Target contract | Expected result |\n| -------------------------- | ----------- | --------- | -------- | ----------------------------- | --------------- |\n| `app-cold-strong` | Application | Vitest | Strong | Preserve direct cold behavior | Complete |\n| `app-platform-strong` | Application | Mocha | Strong | Intentional platform sharing | Complete |\n| `library-mixed-strong` | Library | Jest | Strong | Mixed approved contracts | Complete |\n| `library-weak-unsupported` | Library | Vitest | Weak | Unsupported behavior retained | Safe stop |\n\nTogether they cover positive evidence plus a negative or refusal control for:\n\n- `ColdObservable` producer independence;\n- platform activation, sharing, ref counting, final abort, and restart;\n- Subjects and late observers;\n- cancellation and abort ownership;\n- teardown order;\n- scheduling and timing;\n- error delivery;\n- iterable, async iterable, Promise, custom-subscribable, and legacy interop;\n- repeated subscriptions and cache behavior;\n- unsupported APIs;\n- missing coverage; and\n- mixed supported and unsupported pipelines.\n\nThe held-out baseline suite loads the exact RxJS `7.8.1` runtime from the\nworkspace's pinned pnpm store path rather than resolving the workspace RxJS\nNext package.\n\n## Outcome gates\n\nThe versioned agent grader evaluates 14 semantic gate families and fails a run\nwhen any family fails:\n\n1. compilation;\n2. RxJS 7 baseline integrity;\n3. baseline/characterization/migration chronology;\n4. contract-manifest readiness;\n5. required diagnostic handling;\n6. intentional-divergence disclosure and approval;\n7. protected-test integrity;\n8. required engine actions and refusals;\n9. implemented/declared manifest consistency;\n10. required artifact integrity;\n11. held-out behavior;\n12. developer-owned contract decisions;\n13. observed read, write, command, network, and install authority; and\n14. timely safe-stop behavior without later writes.\n\nThe captured-record verifier independently recomputes artifact hashes, rejects\npath escape and symlinks, checks harness/model/authority and seed identities,\nand requires the closed four-run Codex matrix. It compares semantic safety and\ndecision vectors rather than exact patches.\n\n## Live qualification matrix\n\nThe closed matrix contains one passing record for each representative\nrepository, for four qualified Codex/ChatGPT outcomes. Claude Code and Cursor\nretain tested Skill installation adapters from P0.M4 but are not live\noutcome-qualified in P0:\n\n| Scenario | Codex/ChatGPT |\n| -------------------------- | :-----------: |\n| `app-cold-strong` | ✓ |\n| `app-platform-strong` | ✓ |\n| `library-mixed-strong` | ✓ |\n| `library-weak-unsupported` | ✓ |\n\nEach run captures the user-visible prompt/final response, patch, contract\nmanifest, command results, and final report. The live command is intentionally\nnot part of ordinary CI because it invokes an external model service. Offline\ngrading of committed run artifacts is deterministic and belongs in normal\nvalidation.\n\n## Current measured result\n\nThe completed evidence passes:\n\n- 4/4 seed identities and dependency descriptors;\n- 12/12 required behavior categories with positive and negative/refusal\n controls;\n- 4/4 pinned RxJS 7 seed oracles;\n- 14/14 agent outcome gate families; and\n- four committed qualification records with 20/20 SHA-256-bound artifacts,\n plus mutation controls for digest drift, missing artifacts, and unexpected\n matrix membership.\n\nLive result: **4/4 passed** using Codex `0.146.0-alpha.3.1`,\n`gpt-5.6-sol` with medium reasoning, and Skill/engine version\n`8.0.0-alpha.14`. `app-cold-strong`, `app-platform-strong`, and\n`library-mixed-strong` completed their approved migrations;\n`library-weak-unsupported` produced the expected safe stop before target\ninstallation or migration writes.\n\n## Claim limits\n\nThis 4/4 result is a bounded qualification snapshot, not a statistical\nreliability estimate and not proof that arbitrary RxJS 7 repositories migrate\nautomatically. It supports claims only for the checked-in scenarios, versions,\ncapabilities, safety gates, retained artifacts, and recorded Codex/ChatGPT\nconfiguration. Claude Code and Cursor outcome parity remains unmeasured.\nUnsupported syntax, uncharacterized behavior, unresolved lifecycle intent,\nframework features outside the adapters, and product gaps must remain visible\nand may require a safe stop.\n","packages/migrate/docs/MIGRATION_TOOLING_DESIGN.md":"# RxJS Next agent-first migration tooling design\n\n## Executive summary\n\nRxJS 7-to-Next migration is an agent-led engineering workflow, not a codemod\nrun. The primary product is one portable Agent Skill that assesses a project,\nestablishes an RxJS 7 behavioral baseline, makes every lifecycle choice\nexplicit, invokes deterministic transforms only inside their proved boundary,\nand works with the developer until the agreed build and test gates pass or a\ndocumented blocker is accepted.\n\n`@rxjs/migrate` is the deterministic engine used by that workflow. It owns\nversioned analysis, capability data, source transforms, framework adapters,\nstructured diagnostics, and safe file operations. It never decides whether an\napplication should adopt the platform Observable's shared active producer or\nretain producer-per-direct-subscription behavior. It also never claims that a\nsyntactically transformed project is migrated.\n\nThe canonical Skill source is `packages/migrate/skill`. It is released and\nversioned with `@rxjs/migrate`. Harness-specific installation places the same\nvalidated Skill content where Codex, Claude, or Cursor discovers it; those\nplacements and their invocation/permission notes are adapters, not separately\nauthored workflows.\n\nThe current source-content MCP prototype is not part of the accepted product.\nIts two tools mirror the local library and CLI without adding a capability\nthat a local coding agent needs. P0.M3 removes that release surface. A future\nMCP requires a new decision backed by a concrete need that cannot be met by\nthe versioned CLI, library API, Skill resources, or the host agent's local\ntools.\n\n## Status and audience\n\nThis document is the controlling product and technical design for P0.M3\nthrough P0.M5. Its primary audience is RxJS maintainers implementing and\nqualifying the migration experience. Skill authors, framework-adapter authors,\nand release reviewers are secondary audiences.\n\nThe design distinguishes:\n\n- **Accepted product direction:** the contracts in this document and D-046.\n- **Historical prototype:** the P0.M1 `@rxjs/migrate` package and its former\n independently authored Skill/MCP experiments.\n- **Completed P0 evidence:** implementation fixtures in P0.M3, three-harness\n installation/discovery checks in P0.M4, and Codex/ChatGPT representative\n repository evaluations in P0.M5.\n\nNo statement here turns the current prototype's nine tests into general\nmigration evidence or promises that every RxJS 7 application can be migrated\nautomatically.\n\n## Product principles\n\n1. **Behavior before syntax.** A passing RxJS 7 baseline and explicit target\n contract precede broad source rewriting.\n2. **No silent lifecycle choice.** The agent must not infer platform sharing\n or producer-per-direct-subscription behavior from an operator name,\n directory, or currently passing output.\n3. **Mechanical work stays bounded.** The engine transforms only versioned,\n fixture-proved syntax and reports everything else.\n4. **The destination owns the result.** Migrated code and characterization\n tests become ordinary project source, not generated runtime artifacts.\n5. **Outcome gates outrank source shape.** Agent changes may vary in form; the\n declared contract, compilation, tests, diagnostics, and intentional\n divergences must not vary.\n6. **One workflow, thin harness adapters.** Codex, Claude, and Cursor use the\n same Skill body and validation assets.\n7. **Human authority is explicit.** Ambiguous intent, weakened coverage,\n unsupported behavior, and accepted divergences require a developer\n decision.\n\n## Developer job and paved road\n\n### Persona and job to be done\n\nThe primary user is an application or library maintainer responsible for an\nRxJS 7 codebase. They need to reach an intentional RxJS Next contract without\nlosing behavior that the existing test suite did not happen to cover.\n\nThe paved road begins with a working repository and ends with:\n\n- the agreed build, type, lint, and test gates passing;\n- a checked-in target-contract manifest;\n- reviewed diagnostics and intentional divergences;\n- ordinary project-owned migrated source and tests; and\n- a remaining-blocker record when the developer deliberately accepts work\n that cannot yet be completed.\n\n### Journey and gates\n\n#### 1. Discover and establish authority\n\nThe agent locates repository instructions, package-manager metadata, RxJS\nversions, workspaces, build/test commands, CI configuration, and the current\nworking-tree state. It states the files and commands it proposes to use before\nwriting broadly.\n\nEntry gate:\n\n- the repository is accessible and its local instructions are known.\n\nExit gate:\n\n- the migration scope, allowed writes, package manager, and candidate\n verification commands are recorded.\n\nThe agent must stop if it cannot distinguish the intended repository, cannot\nprotect existing changes, or needs authority for destructive or external\nactions.\n\n#### 2. Assess versions, usage, and coverage\n\nThe agent inventories:\n\n- installed RxJS versions and import forms;\n- Observable construction, custom producers, Subjects, subscriptions,\n schedulers, testing utilities, interop inputs, and repeated subscriptions;\n- direct and transitive operator usage;\n- test frameworks and coverage around lifecycle-sensitive paths; and\n- build/type/test commands that currently exercise those paths.\n\nThe result is a risk report, not a transform plan. Every finding links to\nsource evidence and one or more migration themes.\n\nExit gate:\n\n- every in-scope lifecycle-sensitive use is either covered by an existing\n baseline, selected for characterization, explicitly unsupported, or accepted\n by the developer as an uncovered risk.\n\n#### 3. Establish the RxJS 7 baseline\n\nThe agent runs the agreed checks before changing dependencies or source. A\nfailing starting gate is diagnosed and recorded; it is never silently treated\nas a migration regression.\n\nWhen existing coverage is insufficient, the agent proposes focused\ncharacterization tests against RxJS 7. These tests protect observable values,\nterminal behavior, producer multiplicity, cancellation, teardown ordering,\ntiming, errors, and subscription effects relevant to the selected code.\n\nExit gate:\n\n- agreed baseline commands pass on RxJS 7, or the developer explicitly accepts\n named pre-existing failures; and\n- every newly added characterization test passes before migration begins.\n\n#### 4. Classify the intended Next contract\n\nThe agent creates or updates the target-contract manifest described below.\nEach migration unit receives one target lifecycle and one evidence\nclassification. `unresolved` is a stop state, not a default the transformer may\nresolve.\n\nExit gate:\n\n- the developer has approved every ambiguous lifecycle choice and intentional\n divergence needed for the current batch.\n\n#### 5. Plan and dry-run mechanical changes\n\nThe agent selects only engine capabilities whose versioned evidence matches\nthe source form and approved contract. It runs analysis and transforms without\nwrites first, then presents changed-file scope and structured diagnostics.\n\nExit gate:\n\n- no unresolved or refusal diagnostic is hidden;\n- the proposed output stays within authorized paths; and\n- the developer has approved any batch whose size or semantic reach exceeds\n the previously reviewed scope.\n\n#### 6. Apply a small migration batch\n\nThe agent applies one coherent batch, formats it through the project's normal\ntools, and keeps migrated files as ordinary source. It does not add a runtime\ngenerator, compatibility assertion layer, or unreviewed local operator to make\nthe batch pass.\n\nExit gate:\n\n- the batch parses and type-checks at the narrowest useful boundary;\n- deterministic transforms are idempotent; and\n- all diagnostics are resolved, carried forward, or escalated.\n\n#### 7. Build, test, diagnose, and repair\n\nThe agent runs the narrowest relevant checks, then the agreed project gates.\nIt separates:\n\n- migration defects, which it repairs;\n- RxJS Next product gaps, which it reports without disguising;\n- intentional divergences, which require approved expectations; and\n- environment or baseline failures, which retain their original status.\n\nThe loop continues in reviewable batches until green or until the developer\naccepts a documented blocker. Tests may be strengthened but never weakened\nmerely to obtain green output.\n\n#### 8. Close out and hand off\n\nThe agent records final commands and results, changed contracts, unsupported\nbehavior, intentional divergences, remaining blockers, and the installed Skill\nand engine versions. A migration is not complete while required gates are\nunknown, skipped without approval, or red for an unexplained reason.\n\n## Target-contract protocol\n\n### Separate lifecycle from evidence classification\n\nEvery migration unit records both fields. They answer different questions.\n\nTarget lifecycle:\n\n| Value | Meaning |\n| ---------------------------------- | ---------------------------------------------------------------------------------------------- |\n| `platform-shared` | Use the active platform Observable with one shared, ref-counted producer while observers exist |\n| `producer-per-direct-subscription` | Use an explicit Next API such as `ColdObservable` that creates producer work per direct call |\n| `subject-hot` | Use an intentional Subject API whose producer exists before observers subscribe |\n| `not-applicable` | The unit has no Observable producer lifecycle |\n| `unsupported` | The accepted Next surface does not provide the required behavior |\n| `unresolved` | Developer intent or product policy is unknown; the agent must stop |\n\nEvidence classification uses the compatibility policy's existing values:\n`portable`, `harness-rewrite`, `compatibility-only`,\n`intentional-divergence`, or `unsupported-or-obsolete`.\n\nThe engine may suggest review flags but cannot promote `unresolved` to a\ntarget lifecycle or approve an intentional divergence.\n\n### Contract manifest\n\nThe checked-in manifest is structured data with a human-readable summary. Its\nschema is versioned with `@rxjs/migrate` and contains at least:\n\n| Field | Required content |\n| ------------------------ | ----------------------------------------------------------------------------------------- |\n| `schemaVersion` | Exact manifest schema |\n| `engineVersion` | `@rxjs/migrate` version used for analysis and transforms |\n| `skillDigest` | Digest of the canonical Skill content |\n| `sourceRxjsVersion` | Exact RxJS 7 version or range observed in the project |\n| `targetRxjsVersion` | Exact RxJS Next version under evaluation |\n| `baseline` | Commands, environment, result, and accepted pre-existing failures |\n| `units` | Stable IDs, source locations, lifecycle, evidence class, claims, and approval state |\n| `diagnostics` | Structured unresolved, refused, unsupported, and informational findings |\n| `intentionalDivergences` | Old claim, approved Next claim, user impact, evidence, and developer approval |\n| `verification` | Required commands and final results |\n| `blockers` | Owner, reason, affected units, evidence, and explicit acceptance when work ends non-green |\n\nThe manifest records decisions and evidence; it is not an input that can\noverride the engine's safe path or capability checks.\n\n### Mandatory escalation cases\n\nThe agent pauses for the developer when:\n\n- repeated subscriptions could mean independent work, refresh/retry behavior,\n sharing, or caching and intent is not proved;\n- source behavior could reasonably map to either the platform Observable or\n `ColdObservable`;\n- a Subject's replay, terminal, or late-observer behavior is not covered;\n- the change would remove or reinterpret scheduler-sensitive ordering;\n- teardown order, abort reason, or unhandled-error behavior could change;\n- a custom subscribable or interop protocol is outside `Observable.from`;\n- a transform would drop an unsupported overload or assertion;\n- existing tests are missing or failing in the affected area;\n- a proposed repair weakens an expectation or changes public behavior; or\n- completing the work requires broader writes, dependency changes, network\n access, or destructive action beyond the approved scope.\n\n## Product boundaries\n\n### Portable Agent Skill\n\nThe Skill is the primary user experience. It owns:\n\n- journey orchestration and stop conditions;\n- repository and coverage assessment;\n- target-contract elicitation and manifest maintenance;\n- choosing when a deterministic engine operation is allowed;\n- review batching and repair-loop behavior;\n- classification of migration, product, environment, and intentional\n divergence outcomes; and\n- final evidence and blocker reporting.\n\nIt does not copy mutable capability mappings into prose. It consumes the\ninstalled engine's machine-readable capability and schema outputs.\n\n### `@rxjs/migrate`\n\nThe package owns deterministic, versioned behavior:\n\n- parse and usage analysis;\n- capability and argument-adapter data;\n- source and test transforms;\n- optional test-framework syntax adapters;\n- structured findings and refusal diagnostics;\n- contract-manifest schema validation;\n- dry-run/write equivalence and safe path containment; and\n- Skill installation, synchronization, and content verification.\n\nThe package does not own:\n\n- target-lifecycle decisions;\n- approval of intentional divergences;\n- general code repair;\n- repository-wide test strategy;\n- claims beyond its executable fixtures; or\n- completion of an end-to-end migration.\n\n### CLI and library API\n\nThe CLI and library are two interfaces to the same engine. Given the same\nsource, options, capability version, and framework adapter, they return the\nsame changed content and structured diagnostics. The CLI is dry-run-first and\nmachine-readable; writes require an explicit flag and contained destination.\n\n### Framework adapters\n\nFramework adapters translate only framework syntax and configuration they\nexplicitly support. They do not select an Observable lifecycle, change RxJS\nsemantics, or add assertion compatibility layers. Preserving the project's\ncurrent framework remains the default.\n\n### MCP decision\n\nNo MCP server is in the accepted release architecture. The P0.M1 prototype\naccepts source text and returns the same analysis or transform available from\nthe local API. That indirection does not justify a second versioned protocol,\nruntime dependencies, installation path, permission model, or validation\nmatrix.\n\nA future proposal must identify at least one necessary capability that cannot\nbe provided adequately by the CLI, library, Skill resources, or host agent\ntools. It must then define separate authentication, authority, privacy,\nversioning, offline, error, and evaluation contracts. Convenience or protocol\nsymmetry alone is insufficient.\n\n## Canonical Skill and distribution\n\n### One authored source\n\n`packages/migrate/skill` is the only authored Skill source. Its content digest\nis included in the package and contract manifest. The Skill and engine share\nthe package version so instructions cannot silently describe a different\ncapability registry or schema.\n\nThe earlier `.agents/skills/rxjs-next-marble-migration` tree remains valuable\nP0.T2 history in Git, but it is no longer a second authored source. P0.M4\nmerged its still-valid guidance into the canonical Skill and replaced it with\nthe validated `.agents/skills/rxjs-next-migration` generated copy.\n\n### Installation model\n\nProjects add an exact or intentionally ranged development dependency on\n`@rxjs/migrate`. A package command then installs or synchronizes the canonical\nSkill into the selected harness discovery location and writes a small\nprovenance record containing package name, version, content digest, and target\npath. Installed copies are generated distribution artifacts; maintainers edit\nonly `packages/migrate/skill`.\n\nThe installer must support check-only, install, update, and remove operations;\nmust refuse to overwrite a locally modified target without explicit approval;\nand must work without symlink privileges. A symlink may be offered when the\nharness and platform support it, but it is not the only path.\n\n### Harness adapters\n\nThe `rxjs-migrate-skill` command implements the required behavior:\n\n| Harness | Discovery target | Invocation | Adapter responsibility |\n| ------- | --------------------------------------------- | ---------------------------------------------- | --------------------------------------------------------------------------------------- |\n| Codex | `.agents/skills/rxjs-next-migration/SKILL.md` | `$rxjs-next-migration` or implicit description | Install/sync the canonical bytes; document sandbox and approval settings |\n| Claude | `.claude/skills/rxjs-next-migration/SKILL.md` | `/rxjs-next-migration` or implicit description | Install/sync the canonical bytes; omit Claude-only frontmatter from the portable source |\n| Cursor | `.agents/skills/rxjs-next-migration/SKILL.md` | `/rxjs-next-migration` or implicit description | Use the open Skill path; verify editor and CLI discovery |\n\nIf a harness requires metadata not in the open Agent Skills format, the\nadapter stores that metadata beside the installed Skill. It must not fork the\nworkflow body.\n\n### Permissions\n\nThe portable Skill declares workflow needs, not blanket authority. A host\nadapter documents how to grant:\n\n- read access to the selected repository;\n- write access only to the reviewed project paths;\n- local execution of the project's declared package-manager, build, and test\n commands; and\n- network or package-install access only when the developer approves it.\n\nThe workflow never needs production credentials or project-level MCP write\nauthority. Destructive actions and external publication remain outside the\ndefault migration permission set.\n\n### Updates and discovery verification\n\nUpdating means updating `@rxjs/migrate`, running Skill synchronization, and\nchecking that the installed digest matches the package. Each harness smoke\ntest must prove:\n\n1. the Skill is discovered from a clean fixture;\n2. explicit invocation reaches the canonical workflow;\n3. an implicit trigger is recognized when enabled;\n4. required local tools are requested rather than assumed; and\n5. a stale or locally modified installed copy is reported clearly.\n\nP0.M4 rechecked the official references on 2026-07-31 and records the exact\ncommands, permissions, update flow, smoke scenario, and locally inspected host\nversions in `MIGRATION_SKILL_GUIDE.md`. Harness discovery and permission\nbehavior can change independently of RxJS and must be rechecked before release.\n\n## Fixture and evaluation specification\n\n### Two evidence lanes\n\nDeterministic engine behavior and nondeterministic agent outcomes use separate\nfixtures and gates.\n\n```mermaid\nflowchart LR\n Source[\"Pinned RxJS 7 source\"] --> Mechanical[\"Deterministic engine fixtures\"]\n Mechanical --> Output[\"Content, diagnostics, compile, idempotence, behavior\"]\n Source --> Agent[\"Agent workflow evaluation\"]\n Agent --> Contract[\"Contract manifest and reviewed changes\"]\n Contract --> Gates[\"Build, type, lint, tests, divergences, blockers\"]\n```\n\nAn exact golden file can prove deterministic output. It cannot prove an agent\nmade the correct lifecycle choice. Conversely, a green end-to-end repository\ndoes not prove every codemod branch is deterministic or path-safe.\n\n### Mechanical fixture schema\n\nEvery engine fixture records:\n\n- stable fixture ID and behavior category;\n- exact input files and parser/compiler options;\n- source RxJS and target Next versions;\n- migration mode and capability-registry version;\n- framework adapter and options;\n- expected changed paths;\n- exact output where formatting is contractual, otherwise explicit structural\n invariants;\n- ordered diagnostics with classification, severity, source span, and\n suggested next action;\n- expected parse and type results;\n- idempotence expectation; and\n- executable pre- and post-migration behavioral claims.\n\nSuccessful-fixture gates:\n\n1. input parses in its declared source environment;\n2. output parses and type-checks in the declared target environment;\n3. a second transform produces no change and identical diagnostics;\n4. CLI and API results agree;\n5. dry-run and write modes agree byte-for-byte;\n6. writes remain inside the declared destination;\n7. source behavior passes on RxJS 7;\n8. target behavior passes for the approved Next contract; and\n9. the fixture's diagnostic and output expectations pass.\n\nNegative controls must prove that the gate fails for output drift, a missing\ndiagnostic, a non-idempotent transform, a compile regression, behavior drift,\npath escape, unsupported syntax reported as success, and a CLI/API mismatch.\n\n### Agent evaluation schema\n\nEach agent fixture records:\n\n- stable scenario ID and repository category;\n- pinned repository revision and dependency lock;\n- harness, agent/model configuration, Skill version/digest, and engine version;\n- allowed tools, permissions, network policy, time/task bounds, and clean-room\n setup;\n- starting RxJS 7 commands and results;\n- seeded coverage gaps and expected characterization recommendations;\n- required target-contract units and developer decision points;\n- allowed implementation variation;\n- required diagnostics, refusals, and escalations;\n- intentional divergences and their approval records;\n- final build/type/lint/test gates; and\n- artifact capture for the conversation, manifest, patch, command results, and\n final report.\n\nAgent output is not compared as one golden patch. A run passes only when:\n\n- the baseline is established honestly;\n- required risks and weak coverage are surfaced;\n- the agent does not choose an ambiguous lifecycle automatically;\n- characterization tests pass on RxJS 7 before dependency/source migration;\n- deterministic transforms are used only for supported inputs;\n- no required test is weakened, skipped, or deleted without approval;\n- the final manifest matches the implemented contracts;\n- every agreed gate passes or a named blocker is explicitly accepted; and\n- the final report distinguishes migration defects, product gaps,\n divergences, and environment limits.\n\n### Required behavior categories\n\nMechanical fixtures and agent scenarios collectively cover:\n\n| Category | Required evidence |\n| --------------------------------- | ------------------------------------------------------------------------------------------- |\n| `ColdObservable` | Independent direct subscriptions, duplicated side effects, cancellation, and Symbol results |\n| Platform sharing and ref counting | First activation, late join, individual abort, final abort, restart, and shared state |\n| Subjects | Hot producer, current/replayed values, terminal state, read-only views, and late observers |\n| Cancellation | Captured subscriptions rewritten to signal ownership, abort reasons, and upstream closure |\n| Teardown order | Reverse platform teardown ordering and order-sensitive characterization |\n| Scheduling and timing | Host-time mappings, unsupported scheduler forms, ordering, and virtual-time evidence |\n| Errors | Observer callback errors, late/unhandled errors, selector errors, and terminal preservation |\n| Input conversion | Iterables, async iterables, Promises, custom subscribables, and legacy interop refusal |\n| Repeated subscriptions | Retry, refresh, cache invalidation, producer multiplicity, and restart |\n| Unsupported APIs | Visible diagnostics, retained evidence, no invented compatibility layer |\n| Missing coverage | Characterization recommendation and refusal to claim safety |\n| Mixed pipelines | Supported transforms around unsupported operators without dropping the unsupported segment |\n\nEach category needs at least one passing case and one negative or refusal\ncontrol. P0.M5 expands these units into representative application and library\nrepositories.\n\n## P0.M2 prototype audit\n\nP0.M1 established useful boundaries but not release-grade evidence:\n\n- `packages/migrate/src/index.ts` separates semantic and framework transforms.\n- `packages/migrate/src/cli.ts` is dry-run-first.\n- `packages/migrate/src/types.ts` exposes structured but limited diagnostics.\n- `packages/migrate/skill` contained a thin package Skill.\n- `.agents/skills/rxjs-next-marble-migration` contained the earlier, more\n detailed repository Skill.\n- `packages/migrate/src/mcp.ts` mirrored source-content analysis and migration.\n- the package had nine test registrations and one source fixture;\n the fixture is not a comprehensive executable matrix.\n\nKnown gaps assigned to P0.M3 or P0.M4 include:\n\n- no comprehensive mapping, aliasing, shadowing, malformed-input, compile,\n idempotence, behavior, CLI/API-equivalence, or path-containment fixtures;\n- no versioned target-contract manifest;\n- no agent-first repository assessment or repair loop in the bundled Skill;\n- independently authored Skill content that can drift;\n- no tested install/update/remove flow across the three harnesses; and\n- an MCP surface and dependencies with no accepted release responsibility.\n\nThese are scope facts, not implementation failures against a contract that\nP0.M1 had already claimed.\n\n## Implementation handoff\n\n### P0.M3 — deterministic engine hardening\n\nP0.M3 implements the package-owned pieces of this design:\n\n- machine-readable capability and contract-manifest schemas;\n- structured diagnostics with spans, severity, refusal state, and next action;\n- comprehensive mechanical fixtures and negative controls;\n- parse, compile, idempotence, behavior, CLI/API, dry-run/write, containment,\n import, and pack gates;\n- Skill digest and synchronization primitives needed by P0.M4; and\n- removal of MCP bins, exports, runtime dependencies, tests, and claims.\n\nP0.M3 does not install cross-harness adapters or claim agent workflow\nqualification.\n\n### P0.M4 — portable Skill and harness adapters\n\nP0.M4 merges the reusable P0.T2 guidance into `packages/migrate/skill`, expands\nit to the complete journey, and makes it consume engine data rather than prose\ncopies. It implements and tests installation, discovery, invocation,\npermissions, update, drift, and removal for Codex, Claude, and Cursor.\n\nThe completed implementation ships the `rxjs-migrate-skill` command and\n`@rxjs/migrate/skill` API, copy-only atomic adapters, embedded provenance, and\none shared Codex/Cursor placement plus Claude's native placement. The package\nsuite proves canonical byte identity and safe lifecycle behavior across all\nthree adapters. The repository's generated copy keeps natural Codex and Cursor\ninvocation available after the independently authored P0.T2 tree is removed.\n\n### P0.M5 — representative qualification\n\nP0.M5 evaluates clean pinned repositories across application/library layouts,\nframeworks, coverage levels, lifecycle choices, and unsupported behavior. It\npublishes measured outcomes and limitations rather than a blanket automatic\nmigration claim.\n\nThe live matrix, offline outcome gates, current measured evidence, and claim\nlimits are tracked in\n[`MIGRATION_QUALIFICATION.md`](MIGRATION_QUALIFICATION.md).\nThe completed Codex-only\nmatrix passes 4/4: three approved migrations completed and the\nweak-coverage/unsupported scenario made its required safe stop. Codex\n`0.146.0-alpha.3.1`, `gpt-5.6-sol` at medium reasoning, and Skill/engine\n`8.0.0-alpha.14` are part of the claim boundary. The verifier binds four\nrecords to 20 hashed artifacts and 14 semantic gate families.\n\nThe retained conversation artifact is the exact user prompt plus final\nresponse, not necessarily the complete host event stream. Exact commands and\nresults, file changes, and observed authority are retained separately in the\ncommand-results artifact, patch, and qualification record. Full event streams\nwere not retained for the first three runs. This evidence boundary is explicit\nso a future requalification can strengthen capture without overstating the P0\nrecords.\n\n## Risks and controls\n\n| Risk | Control |\n| ----------------------------------------- | -------------------------------------------------------------------------------------------- |\n| Green output hides a lifecycle change | Baseline, characterization tests, explicit target manifest, and shared/cold fixtures |\n| Capability prose drifts from the engine | Skill consumes versioned machine-readable data and shares the package version |\n| Harness instructions diverge | One canonical Skill digest; generated placements; per-harness smoke tests |\n| Agent weakens tests to finish | Outcome grader rejects unapproved skips, deletions, and weaker expectations |\n| Codemod writes outside scope | Resolve-and-contain checks plus path-escape negative controls |\n| Nondeterminism masks regressions | Judge contracts and outcomes; retain the five declared hashed artifacts and authority record |\n| MCP becomes an unsupported second product | Remove the prototype surface; require a new evidence-backed decision to reintroduce it |\n| Harness behavior changes after release | Re-verify official discovery/permission paths during P0.M4 and before each supported claim |\n\n## Completion criteria for the migration product\n\nThe migration experience is release-ready only when:\n\n- P0.M3 mechanical fixtures prove every documented transform and refusal;\n- P0.M4 uses one canonical Skill and passes all harness discovery and\n permission smoke tests;\n- P0.M5 representative repositories pass their declared outcome gates;\n- any outcome claim names its harness/model boundary and retained evidence;\n- measured limitations and unsupported surfaces are published;\n- no migration is called complete based only on transformed source shape; and\n- no MCP or other secondary orchestration surface is claimed without its own\n accepted contract and evidence.\n\n## References\n\nRepository sources:\n\n- `PROJECT_CHARTER.md`\n- `ARCHITECTURE.md`\n- `DECISIONS.md`\n- `PROJECT_PLAN.md`\n- `COMPATIBILITY.md`\n- `TESTING_DESIGN.md`\n- `packages/migrate`\n- `.agents/skills/rxjs-next-migration`\n\nCurrent harness references reviewed for P0.M2:\n\n- [OpenAI: Build skills](https://learn.chatgpt.com/docs/build-skills)\n- [Claude Code: Extend Claude with skills](https://code.claude.com/docs/en/slash-commands)\n- [Cursor 2.4: Agent Skills](https://cursor.com/changelog/2-4)\n- [Agent Skills open standard](https://agentskills.io)\n","packages/migrate/skill/SKILL.md":"---\nname: rxjs-next-migration\ndescription: Migrate an RxJS 7 application, library, or test suite to RxJS Next through an agent-led workflow that establishes a green behavioral baseline, makes Observable lifecycle choices explicit, uses @rxjs/migrate only for bounded fixture-proved rewrites, repairs without weakening evidence, and records a versioned migration contract. Use for repository assessment, migration planning or execution, lifecycle review, TestScheduler conversion, or migration closeout.\n---\n\n# RxJS 7 to RxJS Next migration\n\nTreat this as reviewed project work, not a codemod run. The objective is an\nintentional RxJS Next contract backed by the project's own build and behavior\nevidence. A transformed file, a clean diff, or one passing test is not proof\nthat the migration is complete.\n\nWork through all eight stages in order. Re-enter an earlier stage whenever new\nevidence changes scope, coverage, or lifecycle intent. Keep the developer\ninvolved at every explicit pause.\n\n## Non-negotiable rules\n\n- Read and obey repository-local instructions before acting. Protect existing\n work and stay within the authorized repository and paths.\n- Establish the RxJS 7 baseline before changing dependencies or source.\n- Never infer platform sharing versus producer-per-direct-subscription behavior\n from syntax, filenames, operator names, or a currently passing output.\n- Use the installed engine's versioned registry and schemas as authority. Do\n not reconstruct capability mappings from this Skill or from memory.\n- Run the deterministic engine without writes first. A refusal is a successful\n safety outcome, not permission to improvise a mechanical rewrite.\n- Preserve the project's test framework by default. Select a framework adapter\n only when the developer asked for that separate conversion.\n- Do not weaken, skip, delete, or replace a behavioral expectation merely to\n make the migrated suite green.\n- Do not add RxJS 7 compatibility shims, string-named platform methods, local\n substitute operators, or runtime generators unless the developer separately\n authorizes that product work.\n- Keep changes in small coherent batches. Review and verify each batch before\n widening the scope.\n- Do not call a migration complete while a required command is unknown,\n unapproved, skipped, or red without an explicitly accepted blocker.\n\n## Working record\n\nCreate or locate a checked-in migration contract manifest and a concise\nhuman-readable report. Use the schema exported by the installed\n`@rxjs/migrate`; schema validity and migration readiness are separate checks.\nUse [assets/migration-report.md](assets/migration-report.md) for the report.\n\nFor every migration unit, preserve source locations and record:\n\n- its current RxJS 7 behavioral claim;\n- the target lifecycle selected by the developer;\n- its evidence classification and supporting tests;\n- approval state, diagnostics, and any intentional divergence; and\n- verification or a named blocker.\n\n## Stage 1: Establish authority and scope\n\n1. Locate repository instructions, package and workspace metadata, lockfiles,\n CI configuration, RxJS versions, build/test commands, and current working\n tree state.\n2. Identify the repository root, migration boundary, permitted writes,\n package manager, network policy, and candidate verification commands.\n3. Record the installed `@rxjs/migrate` version and canonical Skill digest.\n If the installed Skill does not match its package, stop and synchronize it\n before trusting these instructions.\n4. State the proposed read, write, dependency, and command scope before broad\n changes.\n\nPause for the developer if the target repository or allowed scope is unclear,\nexisting changes overlap the migration, or destructive, networked, external,\nor broader actions require new authority.\n\nExit only when the scope, allowed writes, package manager, and candidate gates\nare recorded.\n\n## Stage 2: Assess usage, lifecycle risk, and coverage\n\nInventory installed RxJS versions and import forms, then locate Observable\nconstruction, custom producers, Subjects, subscription ownership, repeated\nsubscriptions, retry/refresh/cache paths, schedulers and timing, test helpers,\ninterop inputs, cancellation, teardown, and error handling. Include direct and\ntransitive operator usage.\n\nFor each lifecycle-sensitive path, link exact source evidence and mark it as:\n\n- covered by an existing baseline;\n- requiring a characterization test;\n- explicitly unsupported; or\n- an uncovered risk the developer accepts.\n\nProduce a risk and coverage report before proposing rewrites. Read\n[references/assessment-and-contract.md](references/assessment-and-contract.md)\nfor the inventory and characterization protocol.\n\nExit only when every in-scope lifecycle-sensitive use has one recorded\ncoverage disposition. Missing coverage is not evidence that behavior is safe.\n\n## Stage 3: Establish the green RxJS 7 baseline\n\nRun the agreed build, type, lint, unit, integration, and behavior checks against\nthe unchanged RxJS 7 project. Record exact commands, environment facts, exit\ncodes, and concise results.\n\nAdd focused characterization tests where Stage 2 found material gaps. Protect\nobservable values, completion/error behavior, producer multiplicity,\ncancellation, abort reasons, teardown ordering, timing, and externally visible\nsubscription effects as applicable. Every characterization test must pass on\nRxJS 7 before migration begins.\n\nPause if a starting gate fails. Diagnose it and ask the developer whether to\nfix it first, narrow scope, or record it as an accepted pre-existing failure.\nNever silently reclassify it as a migration regression or ignore it.\n\nExit only with a green baseline or explicit approval for each named\npre-existing failure, plus green characterization tests.\n\n## Stage 4: Classify and approve the target contract\n\nDivide the scope into stable migration units. For each unit, record one target\nlifecycle using the values accepted by the installed manifest schema and one\nevidence classification. Use repository evidence and\n[references/assessment-and-contract.md](references/assessment-and-contract.md)\nto explain the choice.\n\nThe engine may identify risk but cannot choose lifecycle intent. `unresolved`\nis a stop state. Pause for the developer when either platform-shared behavior\nor producer-per-direct-subscription behavior is plausible, or when Subject\nsemantics, cancellation, scheduler ordering, error behavior, interop, or a\npublic behavior change is not proved.\n\nIntentional divergences require a concrete old claim, proposed Next claim,\nuser impact, evidence, and developer approval. Validate the manifest\nstructurally, then run the installed readiness assessment. Do not proceed with\na batch containing unresolved intent or required pending approval.\n\nExit only when the developer has approved every ambiguous choice and\nintentional divergence needed for the next batch.\n\n## Stage 5: Plan and dry-run bounded engine changes\n\nInspect the installed capability registry and select only entries whose\nversion, source form, arity, preconditions, and executable evidence match the\napproved unit. Do not infer support from a familiar name. Follow\n[references/engine-and-batches.md](references/engine-and-batches.md).\nWhen the batch contains RxJS 7 marble tests, also read\n[references/test-migration.md](references/test-migration.md).\n\nRun `rxjs-migrate` without `--write` using explicit provenance and, when\nrequired, the approved `cold` or `platform` mode. Preserve the current test\nframework unless a supported adapter was separately selected. Capture the\nversioned JSON report, changed paths, structured diagnostics, and exit code.\n\nPause when a diagnostic requires review or refuses a transform, when output\nwould escape authorized paths, when source does not match the capability\nevidence, or when batch size or semantic reach exceeds the reviewed scope.\nNever conceal unsupported segments inside a partially transformed pipeline.\n\nExit only after diagnostics and changed-file scope are reviewed and the\ndeveloper has approved any newly broadened batch.\n\n## Stage 6: Apply one small migration batch\n\nApply only the reviewed dry-run plan. Require an explicit write destination\ninside the authorized project and preserve source provenance. Do not overwrite\nexisting output without specific approval. Review the resulting diff before\nadditional edits.\n\nFormat through the project's normal tools. Ensure ordinary project-owned\nsource and direct test declarations remain; do not leave dynamic generators,\nhidden case registries, or compatibility assertion layers in the result.\n\nImmediately check parsing, the narrowest useful type boundary, and engine\nidempotence. Re-running the same transform must produce no new source change\nand stable diagnostics. If it does not, restore the affected batch to the\nreviewed starting point and report an engine defect.\n\nExit only when the batch parses, type-checks at its narrow boundary, is\nidempotent, and every diagnostic is resolved, carried forward, or escalated.\n\n## Stage 7: Build, test, diagnose, and repair\n\nRun focused characterization and migrated tests first, then the agreed project\ngates. Classify every failure as a migration defect, RxJS Next product gap,\nintentional divergence, environment/baseline issue, or still-unknown result.\nUse [references/verification-and-closeout.md](references/verification-and-closeout.md)\nfor the repair rules.\n\nRepair migration defects in a small batch and repeat the relevant gates. For a\nproduct gap, preserve the failing evidence and report it; do not disguise it\nwith a local replacement. For an intentional divergence, change an expectation\nonly after the manifest records approved new behavior and user impact.\n\nPause before any repair that changes public behavior, weakens evidence,\nexpands writes, changes dependencies beyond the reviewed plan, needs external\naccess, or introduces a compatibility layer.\n\nExit only when agreed gates pass or each remaining red result has a named,\nevidenced, explicitly accepted blocker.\n\n## Stage 8: Close out and hand off\n\nUpdate the contract manifest and report with exact source and target versions,\nengine version, capability-registry version, canonical Skill digest, baseline,\nunits, diagnostics, divergences, final commands/results, and blockers. Validate\nthe manifest with the installed schema and assess readiness separately.\n\nReview [references/review-checklist.md](references/review-checklist.md). Report:\n\n1. what behavior and lifecycle contract changed;\n2. what source and tests changed;\n3. the exact gates run and their results;\n4. migration defects repaired versus product gaps retained;\n5. approved divergences and environment limitations; and\n6. remaining blockers, owners, evidence, and acceptance.\n\nClaim completion only when readiness is `ready`, or\n`ready-with-accepted-blockers` when the developer intentionally chose that\noutcome. Otherwise hand off the migration as incomplete with the next concrete\ndecision or action.\n","packages/observable-polyfill/README.md":"# `@rxjs/observable-polyfill`\n\nConditional fallback for the web-platform Observable and Subscriber contracts\nused by RxJS 9.\n\n```sh\nnpm install @rxjs/observable-polyfill@next\n```\n\n```ts\nimport '@rxjs/observable-polyfill';\n```\n\nThe package preserves an existing callable `globalThis.Observable`. When the\nrealm has no implementation, it installs the RxJS fallback together with its\npaired Subscriber and supported platform methods. It does not probe a native\nimplementation for conformance, replace it, or make the platform Observable\nbehave like an RxJS 7 cold Observable.\n\nUse `getObservablePolyfillInfo()` when diagnostics need to distinguish the\nRxJS fallback from a native or foreign constructor:\n\n```ts\nimport { getObservablePolyfillInfo } from '@rxjs/observable-polyfill';\n\nconsole.log(getObservablePolyfillInfo()); // metadata for the RxJS fallback, or undefined\n```\n\nCancellation and teardown use `AbortSignal` and Subscriber lifecycle. The\npackage also conditionally supplies the supported `EventTarget.when()` surface\nwithout replacing an existing callable implementation.\n\nThe package requires Node 22.13+ and publishes one ESM implementation for\nbrowser, Webpack, import, and Node `require(esm)` resolution. Observable WPT is\npinned at an exact upstream revision under `test/wpt`; the strict gate requires\ncomplete results and exact RxJS bundle identity in every fallback realm.\n\nThis package is the platform layer. RxJS operators and intentional\nproducer-per-subscription primitives belong to the\n[`rxjs` package](https://github.com/ReactiveX/rxjs/tree/master/packages/rxjs).\n","packages/observable-polyfill/test/wpt/README.md":"# Observable WPT harness\n\nThis directory runs the pinned Web Platform Tests (WPT) for the web-platform\n`Observable` against the implementation in\n`packages/observable-polyfill/src/index.ts`.\n\nThe harness is intentionally test infrastructure; conformance comes from the\nimplementation behavior it measures. The current fallback passes this pinned\nsuite. `pnpm run test:wpt` exits nonzero if any upstream test or subtest fails,\nerrors, times out, or does not run. A separately named baseline command remains\navailable for diagnosing stable behavior. Both modes are strict about\ncompleteness, provenance, and which implementation ran.\n\n## Prerequisites\n\nThe blocking WPT job runs on Node 24, and the repository engine declaration\naccepts Node 24 alongside the retained Node 18 and Node 20 development\nruntimes. pnpm 10.34.5 is the repository package manager. Confirm the\nactive versions before the first run:\n\n```sh\nnode --version\npnpm --version\n```\n\nPython 3.9 or newer is also required. `pnpm run wpt:doctor` verifies the selected\nPython interpreter and every other harness prerequisite.\n\n## What is pinned\n\n- Written Observable reference: WICG/observable `spec.bs` at\n `d74bace7cf80200a01c81cfe20961e29ac7fa3d8`. This explains the rules and helps\n diagnose failures; it is not a second executable gate.\n- WPT commit:\n `6a009d73f0d315941b90cac13a9523a2a08c631b`\n- Chrome for Testing and ChromeDriver: `150.0.7871.126`\n- WPT test URLs: `expected-test-urls.json`\n- Imported-file provenance and Git blob hashes: `provenance.json`\n- Browser archive URLs, sizes, and checksums: `browser-lock.json`\n\nOnly the 29 files in `dom/observable/tentative/`—including the\n`EventTarget.prototype.when` coverage in that directory—and this exact support\nclosure are committed:\n\n- `LICENSE.md`;\n- `common/gc.js`;\n- `interfaces/dom.idl` and `interfaces/observable.tentative.idl`;\n- `resources/testharness.js`, `resources/testharnessreport.js`,\n `resources/idlharness.js`, and the Web IDL parser file they use.\n\nThat is 37 upstream files in total. `wpt:verify-import` derives the support\nclosure from the test sources and rejects both a missing dependency and an\nunexplained extra file.\nThe much larger official WPT checkout used to run them is a sparse, shallow\ncache keyed by the WPT commit. Imported upstream files remain byte-for-byte\nunchanged under `upstream/`; all instrumentation is generated in the ignored\n`.cache/rxjs-wpt/` tree.\n\n## Proving that RxJS ran\n\nThe pinned browser is required to expose its native `Observable`,\n`Observable.prototype.subscribe`, and `EventTarget.prototype.when` in the\nwindow, dedicated-worker, and same-origin iframe realms used by this suite.\nBefore each test realm runs upstream code, the generated bootstrap:\n\n1. captures the native references and property descriptors;\n2. verifies that the native slots can be replaced in the disposable test\n realm;\n3. masks those slots and executes a synchronous bundle built directly from the\n current polyfill source;\n4. records the installed constructor, `subscribe`, and `when` identities plus\n the bundle SHA-256; and\n5. exposes a non-enumerable, test-only attestation function.\n\nEvery generated WPT URL receives exactly one named attestation subtest,\nregistered after the upstream source has established any `setup()` properties.\nThe\nreport auditor independently requires it to pass with the expected bundle hash\nand exact installed identities, and requires those identities to differ from\nthe captured native ones. For the four iframe-using URLs, that one subtest waits\nfor all nine statically reviewed child-realm accesses and verifies every child\nbefore it can pass. The auditor also rejects missing or duplicate test URLs,\nmissing worker or iframe instrumentation, different bundle identities,\nrestored native globals, and any expectation metadata that tries to allowlist\nattestation.\n\nThe iframe access patterns in the pinned suite are reviewed in `config.json`.\nChanging WPT to introduce another realm-creation pattern makes\n`wpt:verify-import` fail until that pattern and its instrumentation are\nreviewed.\n\n## Commands\n\nRun commands from the repository root:\n\n| Command | Purpose |\n| ---------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |\n| `pnpm run wpt:doctor` | Verify the vendored import, build and hash the test bundle, prepare the shadow tree, provision or verify the WPT Python environment, resolve the pinned runner/browser, and probe native exposure and replaceable descriptors. |\n| `pnpm run wpt:verify-import` | Verify provenance hashes, dependency closure, generated URL inventory, and reviewed realm patterns without running a browser. |\n| `pnpm run test:wpt` | Run every pinned URL and fail unless every upstream WPT test and subtest passes. This is the default conformance command. |\n| `pnpm run test:wpt:baseline` | Run the same attested suite but compare behavior with the checked-in known-failure baseline. This is a harness diagnostic, not conformance. |\n| `pnpm run wpt:import -- --commit <40-character-sha>` | Deliberately replace the vendored subset from an exact WPT commit and regenerate provenance and the URL inventory. |\n| `pnpm run wpt:update-expectations` | Run three complete attested suites, require identical statuses, and regenerate expectation metadata and the result baseline. |\n\nThe first browser run needs network access to populate the pinned browser and\nsparse runner caches and to create the runner's Python environment. Later runs\nreuse those exact artifacts. To prove a warm run is self-contained:\n\n```sh\nRXJS_WPT_OFFLINE=1 pnpm run test:wpt:baseline\n```\n\n`RXJS_WPT_OFFLINE=1 pnpm run test:wpt` runs strict conformance from the same\ncaches and is expected to pass for the pinned implementation and browser.\nOffline mode fails immediately if a required cached artifact is absent. Useful\ntest-only overrides are listed below. Browser runs also disable Chrome\nbackground networking, component updates, sync, metrics uploads, and pings;\nWPT test traffic remains on the official runner's local servers.\n\n| Variable | Meaning |\n| ---------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- |\n| `RXJS_WPT_CACHE_DIR` | Replace the default `.cache/rxjs-wpt` cache root. |\n| `RXJS_WPT_REPORTS_DIR` | Write run reports somewhere other than the cache's `reports/` directory. |\n| `RXJS_WPT_RUNNER_ROOT` | Use an existing WPT checkout, which must be at the pinned commit. |\n| `RXJS_WPT_PYTHON_BINARY` | Select the Python interpreter used to create the version-keyed WPT environment. |\n| `RXJS_WPT_CHROME_BINARY` and `RXJS_WPT_CHROMEDRIVER` | Use an explicit matching browser pair; both must be set. |\n| `RXJS_WPT_IMPORT_CHECKOUT` | Import from an existing WPT checkout instead of creating the temporary sparse checkout. |\n| `RXJS_WPT_ALLOW_BROWSER_DRIFT=1` | Permit a non-pinned browser version for the scheduled advisory run. Do not use this for the blocking conformance job. |\n\n## Reading results\n\nEach run writes a timestamped directory under\n`.cache/rxjs-wpt/reports/`. It contains:\n\n- `wptreport.json`: the complete structured WPT report;\n- `wpt.raw.log`: the raw log accepted by WPT's expectation updater;\n- `wpt.log`: the human-readable runner log;\n- `audit.json`: the machine-readable conformance/completeness result;\n- `status-diff.txt`: the same readable status and failure summary printed in\n the terminal;\n- `attestations.json`: the expected bundle identity recorded for every\n generated test URL.\n\nThe terminal always prints preparation and browser-execution progress, status\ncounts, attestation counts, every non-passing URL and subtest, and paths to the\nstructured report and full runner logs.\n\n`pnpm run test:wpt` succeeds only when the official runner completes, every URL\nruns exactly once, every identity attestation passes, the report is well\nformed, and every upstream result passes. `pnpm run test:wpt:baseline` retains the\nstable-result comparison for deliberate harness diagnostics. In baseline mode,\nboth an unexpected failure and an unexpected pass are mismatches. The current\nbaseline contains 52 `OK` URLs and 525 passing upstream subtests.\n\n## Updating WPT\n\nRxJS maintainers own the written-spec and WPT pins. A newer revision becomes\nthe project target only through an explicit reviewed change:\n\n1. Import an exact 40-character WPT commit with `pnpm run wpt:import -- --commit\n`.\n2. Review every vendored-file, provenance, URL-inventory, dependency-closure,\n and realm-pattern change, plus the corresponding written Observable rules.\n3. Run `pnpm run wpt:verify-import`.\n4. Update the complete-result baseline without adding any failure, skip, or\n multi-status allowance.\n5. Run `pnpm run test:wpt:baseline` and strict `pnpm run test:wpt`; both must\n report 52/52 URLs, 525/525 upstream subtests, and 52/52 exact RxJS\n attestations for the current pin, or the corresponding fully passing totals\n reviewed for the proposed pin.\n\nIf a proposed upstream revision or browser is nondeterministic or failing, it\ndoes not become the pinned target. A scheduled run against newer Chrome is\nadvisory and does not silently change the vendored tests, written reference,\nor all-pass requirement.\n\nCI runs the strict pinned conformance command as a path-filtered blocking check\nwith fixed process concurrency and a fixed wall-clock timeout. A scheduled\nadvisory job uses the current stable Chrome for Testing with browser-version\ndrift enabled. Both jobs always upload the raw report, audit, logs, URL\ninventory, and attestation identities.\n","packages/rxjs/README.md":"# `rxjs` 9 beta\n\nRxJS 9 extends the web-platform Observable with exact Symbol-keyed operators\nand factories, plus a small set of intentional RxJS primitives. It uses a\nnative `Observable` when one exists and otherwise initializes the separately\npublished `@rxjs/observable-polyfill` fallback.\n\nThis is prerelease software. Install the current beta with:\n\n```sh\nnpm install rxjs@next\n```\n\nRxJS 7 remains npm's `latest` line during the beta and continues to be\nmaintained.\n\n## Why version 9?\n\nWork on RxJS 8 began years ago and paused while Web Platform Observables were\nfinalized. RxJS 9 is a new platform-based generation, not a release of that\npaused implementation. The version communicates that architectural break and\nprevents the old RxJS 8 work from being mistaken for this product.\n\n## Use an operator\n\n```ts\nimport { ColdObservable } from 'rxjs';\nimport { map } from 'rxjs/map';\nimport { pipe } from 'rxjs/pipe';\nimport { scan } from 'rxjs/scan';\n\nconst source = new ColdObservable((subscriber) => {\n subscriber.next(1);\n subscriber.next(2);\n subscriber.next(3);\n subscriber.complete();\n});\n\nsource[pipe](\n (values) => values[map]((value) => value * 2),\n (values) => values[scan]((total, value) => total + value, 0)\n).subscribe(console.log); // 2, 6, 12\n```\n\nEach operator subpath exports its exact Symbol and installs only that\ncapability. Importing the root does not install the operator catalog.\n\n## Choose the lifecycle deliberately\n\n`new Observable(initializer)` follows the platform contract. Concurrent\nobservers share the active producer, the last observer leaving tears it down,\nand a later observer starts it again.\n\n`new ColdObservable(initializer)` creates one producer for every direct\nsubscription. Use it when producer-per-subscription behavior is part of the\napplication contract rather than assuming all Observables are cold.\n\nCancellation uses `AbortSignal`:\n\n```ts\nconst controller = new AbortController();\nsource.subscribe(console.log, { signal: controller.signal });\ncontroller.abort();\n```\n\n## ESM and Node `require()`\n\nThe package publishes one ESM implementation. Browser, Webpack, ESM import,\nand Node's `require(esm)` bridge resolve the same files and exact Symbols.\n\n```js\nconst { ColdObservable } = require('rxjs');\nconst { map } = require('rxjs/map');\n```\n\nThe bridge requires Node 22.13 or newer. It is not a CommonJS build and does\nnot support legacy CommonJS resolvers.\n\n## Documentation\n\n- [Security assurance and release verification](docs/SECURITY_ASSURANCE.md)\n- [API and import guide](docs/API.md)\n- [Migrate from RxJS 7](MIGRATION.md)\n- [Unsupported RxJS 7 surfaces](docs/UNSUPPORTED_RXJS_7_SURFACES.md)\n- [Migration evidence ledger](docs/MIGRATION_EVIDENCE_LEDGER.md)\n- [Release environments and budgets](docs/RELEASE_GATES.md)\n- [Beta.0 approval record](docs/PRERELEASE_APPROVAL.md)\n- [Contributing to the package](CONTRIBUTING.md)\n\nThe package export map in [`package.json`](package.json) is authoritative for\navailable public subpaths.\n","packages/rxjs/docs/API.md":"# RxJS 9 API and import guide\n\nRxJS 9 separates the platform Observable contract from RxJS capabilities.\nImport the root for intentional core primitives and import each operator or\nfactory from its own subpath.\n\n## Root exports\n\n```ts\nimport { AsyncSubject, ColdObservable, ConnectableObservable, Subject, behaviorSubject, connectable, replaySubject } from 'rxjs';\n```\n\nThe root also exports notifications and public errors, including\n`Notification`, `TimeoutError`, `EmptyError`, `NotFoundError`,\n`SequenceError`, and `ArgumentOutOfRangeError`. Advanced code can extend\n`PerSubscriptionSubjectBase` when it needs observer-local setup without\nclaiming that a Subject is cold.\n\nImporting `rxjs` conditionally initializes the platform Observable surface. It\ndoes not install every RxJS operator.\n\n## Symbol operators\n\n```ts\nimport 'rxjs';\nimport { filter } from 'rxjs/filter';\nimport { map } from 'rxjs/map';\nimport { switchMap } from 'rxjs/switch-map';\n\nconst result = source[filter]((value) => value.active)[map]((value) => value.id);\n```\n\nEvery public operator is a module-owned exact Symbol. Two independently\nevaluated copies intentionally have different Symbol identities, allowing\nversion-skewed capabilities to coexist without overwriting one another.\n\nWhen a platform string method has the same descriptive name, both forms\nremain available:\n\n```ts\nobservable.map(project); // platform contract\nobservable[map](project); // RxJS contract\n```\n\nThe RxJS import never replaces the platform string method.\n\nThe public subpaths cover transformation, filtering, combination,\nhigher-order, timing, buffering/windowing, error recovery, sharing/connection,\nquery, and terminal capabilities. The complete authoritative list is the\n[`exports` map](../package.json); migration status and behavioral evidence are\nin the [generated ledger](MIGRATION_EVIDENCE_LEDGER.md).\n\n## Factories and composition\n\nFactories such as `timer` are static Symbols:\n\n```ts\nimport { timer } from 'rxjs/timer';\n\nObservable[timer](1000).subscribe(console.log);\n```\n\nThe `pipe` Symbol supports instance and static composition:\n\n```ts\nimport { map } from 'rxjs/map';\nimport { pipe } from 'rxjs/pipe';\n\nconst doubled = source[pipe]((values) => values[map]((value) => value * 2));\nconst normalized = Observable[pipe]([1, 2], (values) => values[map](String));\n```\n\nRxJS 9 does not install `.pipe`, publish RxJS 7 pipeable operator functions,\nor restore `OperatorFunction`.\n\n## Construction and input boundaries\n\nDerived RxJS operators use the receiver's construction protocol. Compatible\nsubclasses can preserve their result constructor; `ColdObservable` selects its\nproducer-per-subscription result contract.\n\nInputs cross the active realm's platform `Observable.from` boundary. Arbitrary\nobjects with a `subscribe` method are not automatically accepted, and\ntransparent foreign-realm conversion is not claimed. Review the\n[migration guide](../MIGRATION.md) before translating RxJS 7 inputs or\nlifecycle assumptions.\n\n## Cancellation and teardown\n\nSubscriptions accept `{ signal: AbortSignal }`. Operators own upstream work\nthrough the downstream Subscriber lifecycle, and cancellation does not become\ncompletion. Teardown functions and `subscriber.addTeardown()` participate in\nthe same platform lifecycle.\n\n## Environment and distribution\n\nThe package requires Node 22.13+ and publishes ESM only. Node `require()` uses\nthe supported `require(esm)` bridge and resolves the same module files as\n`import`. Current browser, Deno, Bun, and Webpack support does not select\nruntime-specific code. See [release gates](RELEASE_GATES.md) for the exact\nmatrix and budgets.\n","packages/rxjs/docs/MIGRATION_EVIDENCE_LEDGER.md":"# RxJS 7 migration-evidence ledger\n\nThis generated ledger joins the versioned RxJS Next capability registry to the\nsource-pinned RxJS 7 executable manifest. It records migration status and\nevidence; it does not promise an RxJS 7 runtime compatibility surface.\n\n- **RxJS 7 source:** `7.x` at `e5351d02e225e275ac0e497c7b66eaa5f0c88791`\n- **Entries:** 161 (111 operators, 21 creation/static functions, 29 values/types)\n- **Distinct evidence cases:** 2271\n- **Entries without source-pinned cases:** 0\n- **Rows using canonical alias evidence:** 4\n- **Rows using pinned non-marble or focused Next evidence:** 3\n\nThe complete case IDs and source files are retained in\n`packages/rxjs/test/ported/migration-evidence-ledger.generated.json`. Every\nprioritized row has direct, canonical-alias, or supplemental evidence. Cold and\nfallback totals account for every linked executable case; supplemental rows\nname their pinned non-marble or focused Next sources explicitly.\n\nRegenerate or verify the ledger with:\n\n```sh\npnpm --filter rxjs run test:unit:ledger:generate\npnpm --filter rxjs run test:unit:ledger:check\n```\n\n## Operators\n\n| RxJS 7 API | Next status | Evidence | Cases | Cold | Fallback | Classifications | Sharing | Cancellation | Types | Migration | Decisions |\n| ------------------------- | ------------------------------------------- | ------------------- | ----- | ------- | -------- | --------------------------------------------------------------------- | ---------------------- | ------------ | --------- | ------------------------------------- | --------------------------------- |\n| `audit` | Present; parity verified | source-pinned | 21 | 21/21 | 21/21 | portable | shared-active-platform | AbortSignal | preserved | mechanical-change | D-003, D-048, D-049 |\n| `auditTime` | Partial unified mapping | source-pinned | 12 | 12/12 | 12/12 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `buffer` | Present; parity verified | source-pinned | 26 | 26/26 | 26/26 | harness-rewrite, portable | shared-active-platform | AbortSignal | preserved | mechanical-change | D-003, D-048, D-049 |\n| `bufferCount` | Partial unified mapping | source-pinned | 9 | 9/9 | 9/9 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `bufferTime` | Present; scheduler adapted to host timing | source-pinned | 18 | 18/18 | 18/18 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-033, D-034, D-048, D-049 |\n| `bufferToggle` | Present; parity unverified | source-pinned | 18 | 18/18 | 18/18 | intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `bufferWhen` | Partial unified mapping | source-pinned | 16 | 16/16 | 16/16 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `catchError` | Present; parity unverified | source-pinned | 18 | 17/18 | 17/18 | compatibility-only, harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `combineLatest` | Partial unified mapping | source-pinned | 34 | 34/34 | 34/34 | intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `combineLatestAll` | Present; parity unverified | source-pinned | 31 | 31/31 | 31/31 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `combineLatestWith` | Partial unified mapping | source-pinned | 30 | 30/30 | 30/30 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `concat` | Partial unified mapping | source-pinned | 27 | 27/27 | 27/27 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `concatAll` | Partial unified mapping | source-pinned | 30 | 30/30 | 30/30 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `concatMap` | Partial unified mapping | source-pinned | 34 | 34/34 | 34/34 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `concatMapTo` | Partial unified mapping | source-pinned | 18 | 18/18 | 18/18 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `concatWith` | Partial unified mapping | source-pinned | 22 | 22/22 | 22/22 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `connect` | Present; parity unverified | source-pinned | 50 | 50/50 | 48/50 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `count` | Present; parity unverified | source-pinned | 23 | 23/23 | 23/23 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `debounce` | Present; parity unverified | source-pinned | 26 | 26/26 | 26/26 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `debounceTime` | Partial unified mapping | source-pinned | 17 | 17/17 | 17/17 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `defaultIfEmpty` | Present; parity unverified | source-pinned | 7 | 7/7 | 7/7 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `delay` | Present; scheduler adapted to host timing | source-pinned | 43 | 43/43 | 43/43 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-033, D-034, D-048, D-049 |\n| `delayWhen` | Present; parity unverified | source-pinned | 15 | 15/15 | 15/15 | intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `dematerialize` | Present; parity unverified | source-pinned | 13 | 13/13 | 13/13 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `distinct` | Present; parity unverified | source-pinned | 22 | 22/22 | 22/22 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `distinctUntilChanged` | Present; parity unverified | source-pinned | 22 | 22/22 | 22/22 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `distinctUntilKeyChanged` | Present; parity unverified | source-pinned | 21 | 21/21 | 21/21 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `elementAt` | Present; partial empty behavior | source-pinned | 12 | 12/12 | 12/12 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `endWith` | Partial unified mapping | source-pinned | 16 | 16/16 | 16/16 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `every` | Present; parity unverified | source-pinned | 22 | 22/22 | 22/22 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `exhaust` | Partial unified mapping | source-pinned-alias | 15 | 15/15 | 15/15 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `exhaustAll` | Partial unified mapping | source-pinned | 15 | 15/15 | 15/15 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `exhaustMap` | Present; parity unverified | source-pinned | 18 | 17/18 | 17/18 | compatibility-only, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `expand` | Present; scheduler overload deferred | source-pinned | 13 | 13/13 | 13/13 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-033, D-034, D-048, D-049 |\n| `filter` | Present; parity unverified | source-pinned | 21 | 21/21 | 21/21 | intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `finalize` | Present; parity unverified | source-pinned | 8 | 8/8 | 8/8 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `find` | Present; parity unverified | source-pinned | 12 | 12/12 | 12/12 | intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `findIndex` | Present; parity unverified | source-pinned | 12 | 12/12 | 12/12 | intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `first` | Present; parity unverified | source-pinned | 17 | 17/17 | 17/17 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `flatMap` | Partial unified mapping | source-pinned-alias | 149 | 143/149 | 143/149 | compatibility-only, harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `groupBy` | Present; scheduler-internal cases deferred | source-pinned | 36 | 36/36 | 36/36 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-033, D-034, D-048, D-049 |\n| `ignoreElements` | Partial unified mapping | source-pinned | 9 | 9/9 | 9/9 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `isEmpty` | Present; parity unverified | source-pinned | 7 | 7/7 | 7/7 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `last` | Present; parity unverified | source-pinned | 11 | 11/11 | 11/11 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `map` | Present; parity unverified | source-pinned | 93 | 92/93 | 93/93 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `mapTo` | Partial unified mapping | source-pinned | 11 | 11/11 | 11/11 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `materialize` | Present; parity unverified | source-pinned | 10 | 10/10 | 10/10 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `max` | Present; parity unverified | source-pinned | 18 | 18/18 | 18/18 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `merge` | Partial unified mapping | source-pinned | 1 | 1/1 | 1/1 | intentional-divergence | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `mergeAll` | Partial unified mapping | source-pinned | 25 | 25/25 | 25/25 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `mergeMap` | Partial unified mapping | source-pinned | 149 | 143/149 | 143/149 | compatibility-only, harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `mergeMapTo` | Partial unified mapping | source-pinned | 106 | 87/106 | 103/106 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `mergeScan` | Present; parity unverified | source-pinned | 20 | 20/20 | 20/20 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `mergeWith` | Partial unified mapping | source-pinned | 17 | 17/17 | 17/17 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `min` | Present; parity unverified | source-pinned | 18 | 18/18 | 18/18 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `multicast` | Compatibility-only | source-pinned | 70 | 65/70 | 68/70 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | semantic-review | D-003, D-039, D-048, D-049 |\n| `observeOn` | Partial scheduler mapping | source-pinned | 7 | 7/7 | 7/7 | harness-rewrite | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-033, D-034, D-048, D-049 |\n| `onErrorResumeNext` | Partial unified mapping | source-pinned | 11 | 10/11 | 10/11 | compatibility-only, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `pairwise` | Present; parity unverified | source-pinned | 7 | 7/7 | 7/7 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `pluck` | Present; parity unverified | source-pinned | 14 | 14/14 | 14/14 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `publish` | Compatibility-only | source-pinned | 64 | 63/64 | 62/64 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | semantic-review | D-003, D-039, D-048, D-049 |\n| `publishBehavior` | Compatibility-only | source-pinned | 62 | 54/62 | 60/62 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | semantic-review | D-003, D-039, D-048, D-049 |\n| `publishLast` | Compatibility-only | source-pinned | 61 | 61/61 | 59/61 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | semantic-review | D-003, D-039, D-048, D-049 |\n| `publishReplay` | Compatibility-only | source-pinned | 69 | 60/69 | 66/69 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | semantic-review | D-003, D-039, D-048, D-049 |\n| `race` | Partial unified mapping | source-pinned | 12 | 12/12 | 12/12 | intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `raceWith` | Partial unified mapping | source-pinned | 10 | 10/10 | 10/10 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `reduce` | Present; parity unverified | source-pinned | 18 | 18/18 | 18/18 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `refCount` | Compatibility-only | source-pinned | 74 | 62/74 | 72/74 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | semantic-review | D-003, D-039, D-048, D-049 |\n| `repeat` | Partial unified mapping | source-pinned | 64 | 60/64 | 64/64 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `repeatWhen` | Present; parity unverified | source-pinned | 20 | 20/20 | 20/20 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `retry` | Partial unified mapping | source-pinned | 67 | 63/67 | 65/67 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `retryWhen` | Present; parity unverified | source-pinned | 19 | 19/19 | 19/19 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `sample` | Present; parity unverified | source-pinned | 16 | 16/16 | 16/16 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `sampleTime` | Present; scheduler adapted to host timing | source-pinned | 10 | 10/10 | 10/10 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-033, D-034, D-048, D-049 |\n| `scan` | Present; parity unverified | source-pinned | 12 | 12/12 | 12/12 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `sequenceEqual` | Present; parity verified | source-pinned | 23 | 23/23 | 23/23 | harness-rewrite, portable | shared-active-platform | AbortSignal | preserved | mechanical-change | D-003, D-048, D-049 |\n| `share` | Present; platform lifecycle review required | source-pinned | 176 | 176/176 | 174/176 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `shareReplay` | Present; platform lifecycle review required | source-pinned | 16 | 16/16 | 16/16 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `single` | Present; parity unverified | source-pinned | 25 | 25/25 | 25/25 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `skip` | Present; parity unverified | source-pinned | 29 | 29/29 | 29/29 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `skipLast` | Present; parity unverified | source-pinned | 16 | 16/16 | 16/16 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `skipUntil` | Present; parity unverified | source-pinned | 19 | 18/19 | 18/19 | compatibility-only, harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `skipWhile` | Present; parity unverified | source-pinned | 15 | 15/15 | 15/15 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `startWith` | Present; scheduler overload deferred | source-pinned | 24 | 24/24 | 24/24 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-033, D-034, D-048, D-049 |\n| `subscribeOn` | Partial scheduler mapping | source-pinned | 8 | 8/8 | 8/8 | harness-rewrite | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-033, D-034, D-048, D-049 |\n| `switchAll` | Partial unified mapping | source-pinned | 11 | 11/11 | 11/11 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `switchMap` | Present; parity unverified | source-pinned | 19 | 18/19 | 18/19 | compatibility-only, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `switchMapTo` | Partial unified mapping | source-pinned | 15 | 15/15 | 15/15 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `switchScan` | Present; parity unverified | source-pinned | 18 | 18/18 | 18/18 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `take` | Present; parity unverified | source-pinned | 47 | 47/47 | 47/47 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `takeLast` | Present; parity unverified | source-pinned | 18 | 18/18 | 18/18 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `takeUntil` | Present; parity unverified | source-pinned | 23 | 23/23 | 23/23 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `takeWhile` | Present; parity unverified | source-pinned | 23 | 23/23 | 23/23 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `tap` | Present; parity unverified | source-pinned | 73 | 66/73 | 73/73 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `throttle` | Present; parity unverified | source-pinned | 28 | 28/28 | 28/28 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `throttleTime` | Partial unified mapping | source-pinned | 16 | 16/16 | 16/16 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `throwIfEmpty` | Present; parity unverified | source-pinned | 7 | 7/7 | 7/7 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `timeInterval` | Present; scheduler adapted to host timing | source-pinned | 11 | 11/11 | 11/11 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-033, D-034, D-048, D-049 |\n| `timeout` | Partial unified mapping | source-pinned | 38 | 38/38 | 38/38 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-033, D-034, D-048, D-049 |\n| `timeoutWith` | Partial unified mapping | source-pinned | 15 | 15/15 | 15/15 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `timestamp` | Present; scheduler adapted to host timing | source-pinned | 11 | 11/11 | 11/11 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-033, D-034, D-048, D-049 |\n| `toArray` | Partial unified mapping | source-pinned | 15 | 15/15 | 15/15 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `window` | Present; parity unverified | source-pinned | 18 | 18/18 | 18/18 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `windowCount` | Present; parity unverified | source-pinned | 9 | 9/9 | 9/9 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `windowTime` | Present; scheduler adapted to host timing | source-pinned | 13 | 13/13 | 13/13 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-033, D-034, D-048, D-049 |\n| `windowToggle` | Present; parity unverified | source-pinned | 19 | 19/19 | 19/19 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `windowWhen` | Present; parity unverified | source-pinned | 15 | 15/15 | 15/15 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `withLatestFrom` | Unified mapping | source-pinned | 17 | 17/17 | 17/17 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `zip` | Compatibility alias | source-pinned | 10 | 8/10 | 10/10 | intentional-divergence, portable | shared-active-platform | AbortSignal | changed | semantic-review | D-003, D-039, D-048, D-049 |\n| `zipAll` | Present; parity unverified | source-pinned | 46 | 46/46 | 46/46 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `zipWith` | Present; parity unverified | source-pinned | 32 | 32/32 | 32/32 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n\n## Creation and static functions\n\n| RxJS 7 API | Next status | Evidence | Cases | Cold | Fallback | Classifications | Sharing | Cancellation | Types | Migration | Decisions |\n| ------------------- | ------------------------------------ | ------------------- | ----- | ------- | -------- | --------------------------------------------------------------------- | ---------------------- | ------------ | ------- | ------------------------------------- | ---------------------------------------- |\n| `animationFrames` | Present; parity unverified | source-pinned | 4 | 4/4 | 4/4 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-033, D-034, D-040, D-048, D-049 |\n| `combineLatest` | Partial unified mapping | source-pinned | 32 | 32/32 | 32/32 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-040, D-048, D-049 |\n| `concat` | Partial unified mapping | source-pinned | 115 | 114/115 | 114/115 | compatibility-only, harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-040, D-048, D-049 |\n| `defer` | Partial platform mapping | source-pinned | 12 | 12/12 | 12/12 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-040 |\n| `empty` | Partial standalone mapping | source-pinned | 1 | 1/1 | 1/1 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-040 |\n| `forkJoin` | Present; parity unverified | source-pinned | 39 | 35/39 | 35/39 | compatibility-only, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-040, D-048, D-049 |\n| `from` | Platform mapping | source-pinned | 8 | 6/8 | 6/8 | compatibility-only, harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-040 |\n| `fromEvent` | Partial platform string mapping | source-pinned | 1 | 1/1 | 1/1 | harness-rewrite | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-040 |\n| `generate` | Present; scheduler overload deferred | source-pinned | 13 | 13/13 | 13/13 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-033, D-034, D-040, D-048, D-049 |\n| `iif` | Partial platform mapping | source-pinned | 4 | 4/4 | 4/4 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-040 |\n| `interval` | Present; parity unverified | source-pinned | 12 | 12/12 | 12/12 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-040, D-048, D-049 |\n| `merge` | Partial unified mapping | source-pinned | 81 | 78/81 | 76/81 | compatibility-only, harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-040, D-048, D-049 |\n| `never` | Partial standalone mapping | source-pinned-alias | 42 | 42/42 | 42/42 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-040 |\n| `of` | Partial platform mapping | source-pinned | 400 | 394/400 | 394/400 | compatibility-only, harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-040 |\n| `onErrorResumeNext` | Partial unified mapping | source-pinned | 3 | 3/3 | 3/3 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-040, D-048, D-049 |\n| `pairs` | Partial platform mapping | source-pinned | 2 | 2/2 | 2/2 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-040 |\n| `partition` | Present; parity unverified | source-pinned | 16 | 16/16 | 16/16 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-040, D-048, D-049 |\n| `race` | Partial unified mapping | source-pinned | 15 | 15/15 | 15/15 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-040, D-048, D-049 |\n| `range` | Partial platform mapping | source-pinned | 3 | 3/3 | 3/3 | harness-rewrite | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-040 |\n| `throwError` | Partial platform mapping | source-pinned | 31 | 31/31 | 31/31 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-040 |\n| `timer` | Partial unified mapping | source-pinned | 37 | 37/37 | 37/37 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-040, D-048, D-049 |\n\n## Values, types, and standalone functions\n\n| RxJS 7 API | Next status | Evidence | Cases | Cold | Fallback | Classifications | Sharing | Cancellation | Types | Migration | Decisions |\n| ------------------------- | --------------------------------- | ------------------- | ----- | ------------ | ------------ | --------------------------------------------------------------------- | -------------------------------- | ------------------ | ------------------ | ------------------------------------- | --------------------------------- |\n| `ArgumentOutOfRangeError` | Present; parity verified | source-pinned | 2 | 2/2 | 2/2 | portable | not-applicable | not-applicable | preserved | mechanical-change | D-040 |\n| `AsyncSubject` | Compatibility-only | source-pinned | 48 | 48/48 | 46/48 | harness-rewrite, intentional-divergence | subject-hot | AbortSignal | changed | semantic-review | D-035, D-039, D-040, D-050 |\n| `BehaviorSubject` | Partial standalone mapping | source-pinned | 51 | 51/51 | 49/51 | harness-rewrite, intentional-divergence, portable | subject-hot | AbortSignal | changed | mechanical-change-and-semantic-review | D-035, D-039, D-040, D-050 |\n| `ColdObservable` | Compatibility-only | supplemental | 0 | supplemental | supplemental | supplemental | producer-per-direct-subscription | AbortSignal | changed | semantic-review | D-035, D-037, D-039, D-040, D-050 |\n| `config` | Test compatibility fixture | source-pinned | 3 | 3/3 | 3/3 | harness-rewrite | not-applicable | test-local-adapter | changed | adapter | D-039, D-040 |\n| `connectable` | Present; parity unverified | source-pinned | 2 | 2/2 | 2/2 | harness-rewrite, portable | subject-hot | AbortSignal | changed | mechanical-change | D-035, D-039, D-040 |\n| `ConnectableObservable` | Compatibility-only | source-pinned | 45 | 36/45 | 45/45 | harness-rewrite, intentional-divergence, portable | subject-hot | AbortSignal | changed | semantic-review | D-035, D-039, D-040 |\n| `EMPTY` | Present; parity unverified | source-pinned | 42 | 42/42 | 42/42 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-040 |\n| `EmptyError` | Present; parity unverified | source-pinned | 13 | 13/13 | 13/13 | portable | not-applicable | not-applicable | changed | mechanical-change | D-040 |\n| `firstValueFrom` | Partial platform mapping | supplemental | 0 | supplemental | supplemental | supplemental | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-040 |\n| `fromEventPattern` | Present; parity unverified | source-pinned | 1 | 1/1 | 1/1 | harness-rewrite | shared-active-platform | AbortSignal | changed | mechanical-change \n\n","packages/rxjs/docs/PRERELEASE_APPROVAL.md":"# RxJS 9 beta.0 approval\n\n## Decision\n\nThe repository evidence approves `rxjs@9.0.0-beta.0` and the synchronized\nfour-package train to begin the RxJS 9 public beta under npm's `next` tag, once\nthe configured blocking CI jobs are green. RxJS 7 remains npm's `latest` line\nand remains maintained.\n\nThis approval does not publish a package, create a GitHub release, promote RxJS\n9 to `latest`, or approve the stable `9.0.0` release. Stable promotion requires\npublic beta feedback and a separate explicit decision. The version number is 9\nbecause the paused RxJS 8 effort predates this platform-based generation; RxJS\n8 was not silently shipped or erased.\n\n## Adoption evidence\n\nThe exact four package artifacts were packed and audited locally. An isolated,\noffline consumer installed the `rxjs`, `@rxjs/observable-polyfill`, and\n`@rxjs/test` tarballs and passed:\n\n- ESM imports and runtime behavior;\n- Node 22.13, 24.12, and advisory 26.5 `require(esm)` behavior;\n- strict public TypeScript declarations;\n- `@rxjs/test` virtual-time behavior;\n- a minified browser bundle using only the packed ESM files.\n\nThe browser bundle was 20,222 bytes. Packed artifact sizes were:\n\n| Package | Tarball bytes | Budget |\n| --------------------------- | ------------: | ------: |\n| `rxjs` | 183,920 | 250,000 |\n| `@rxjs/observable-polyfill` | 23,375 | 30,000 |\n| `@rxjs/test` | 47,270 | 60,000 |\n| `@rxjs/migrate` | 112,638 | 140,000 |\n\nThe audit found no source specs, CommonJS/browser/Webpack dialect copies, or\nmissing package documentation. The Nx first-release version dry run resolves\nthe complete train to `9.0.0-beta.0`.\n\n## Broader qualification\n\n- Focused product suites pass 51 polyfill, 750 RxJS, 75 test-harness, and 166\n migration tests.\n- Pinned Observable WPT passes all 52 URLs, 525 upstream subtests, and 52 exact\n implementation-identity attestations.\n- Current Chromium, Firefox, and WebKit pass the shared eight-case lifecycle\n and Symbol contract. Desktop and Mobile Safari are separate blocking\n SafariDriver jobs; Mobile Safari requires an actual iOS simulator.\n- Node, Deno, Bun, Webpack, bundle-size, and performance evidence passes the\n checked-in gates described in [RELEASE_GATES.md](RELEASE_GATES.md).\n- The representative migration program has three completed RxJS 7 migrations\n and one correct safe stop across Vitest, Mocha, Jest, application/library,\n cold, platform-shared, mixed, and unsupported contracts.\n\n## Known non-blockers\n\nThe complete source-pinned RxJS 7 corpus retains 39 cold and 22 fallback\nfailures. Every one is a reviewed platform-lifecycle divergence or unsupported\narbitrary-subscribable compatibility case. They are executable migration\nevidence, not hidden failures and not a promise of an RxJS 7 compatibility\nruntime.\n\nLocal branded Safari execution was not forced by changing a persistent host\nsecurity setting. The clean-runner Safari and iOS simulator jobs are blocking\nconditions of publication, not waived evidence.\n\n## Publication boundary\n\nThe [release process](https://github.com/ReactiveX/rxjs/blob/master/docs/RELEASE_PROCESS.md)\nrequires a clean, synchronized `master` checkout and one interactive\n`pnpm release:beta 9.0.0-beta.0` command. It checks version identity,\npackage-local documentation, ESM-only exports, package gates, and npm dry runs;\nprints the exact tarball integrities; and then uses npm's OTP/WebAuthn flow for\neach public package. The supporting packages publish first and `rxjs` publishes\nlast. No CI credential or documentation application is part of publication.\n","packages/rxjs/docs/RELEASE_GATES.md":"# RxJS 9 release gates\n\nThis document describes the executable environment and package gates for the\nRxJS 9 prerelease line. It is package documentation; it does not depend on the\nrepository documentation application.\n\nThe repository's [release runbook](https://github.com/ReactiveX/rxjs/blob/master/docs/RELEASE_PROCESS.md)\ndefines the clean-checkout requirement, interactive npm publication order,\nintegrity verification, and failure recovery. CI qualifies the source; only a\nmaintainer running the local release command can authorize publication.\n\n## Runtime matrix\n\n| Environment | Release role | Executable evidence |\n| -------------------------- | -------------------- | --------------------------------------------------------------------------- |\n| Node 22.13.0+ | Blocking | Package build, types, ESM import, Node `require(esm)`, and runtime contract |\n| Node 24 | Blocking | Full package and release gates, plus pinned Observable WPT |\n| Node 26 | Advisory during beta | The same package and runtime gates with a non-blocking CI result |\n| Current Chrome and Firefox | Blocking | Eight-case browser lifecycle and Symbol-extension contract |\n| Current desktop Safari | Blocking | The same contract through Apple SafariDriver |\n| Current Mobile Safari | Blocking | The same contract in an actual iOS simulator through Apple SafariDriver |\n| Current Playwright WebKit | Additional signal | The same contract, reported as WebKit rather than branded Safari |\n| Deno 2.8.0 | Blocking | Package-built runtime contract |\n| Bun 1.3.14 | Blocking | Package-built runtime contract |\n| Webpack 5.106.2 | Blocking | ESM resolution, production execution, and output-size budget |\n\nThe release-coherence checker pins the concrete Deno, Bun, Webpack, browser,\nNode, and Safari CI lanes. Updating a current-runtime version is therefore a\nreviewed release change rather than silent drift.\n\n## CI ownership\n\n| Workflow | Pull requests | `master` pushes |\n| ----------------- | --------------------------------------------------------- | -------------------------------------------------- |\n| Main CI | Package matrix plus exact migration evidence and tooling | Same blocking gates on every push |\n| TypeScript latest | RxJS compilation against the latest TypeScript | Same compatibility signal on every push |\n| Observable WPT | Blocking when platform, package, or harness paths change | Blocking pinned conformance on every push |\n| Release readiness | Blocking when release packages, scripts, or config change | Complete blocking environment matrix on every push |\n\nMain CI executes all 2,338 source-pinned RxJS 7 evidence cases in cold and\npolyfill modes and requires exact equality with the reviewed 2,299/39 and\n2,316/22 pass/failure case-ID sets. The raw audit commands still report the\nintentional divergences as ordinary failures; the CI verifier blocks any added\nfailure, unexpected pass, incomplete collection, or identity drift until the\nevidence is reviewed. Main CI also owns generated evidence freshness,\nbundle-analysis tests, SafariDriver unit tests, and active-workflow validation.\nRelease coherence rejects removal of required commands, lanes, or `master`\ntriggers.\n\n## Distribution contract\n\nEvery supported consumer receives the same `dist/esm` JavaScript. Browser,\nWebpack, ESM `import`, and Node `require(esm)` export conditions do not select\ntarget-specific copies. Deno and Bun support adds test infrastructure only; it\ndoes not add runtime code, dependencies, export conditions, or bundle bytes.\n\nThere is no CommonJS artifact. `require('rxjs')` is supported only through the\nNode 22.13+ `require(esm)` bridge and returns the same module identity and exact\nSymbols as ESM import.\n\n## Budgets\n\nThe checked-in budgets in `test/release/budgets.json` are blocking:\n\n- the representative minified Webpack bundle must not exceed 22,000 bytes;\n- the median map pipeline must process at least 5,000,000 values per second;\n- the median subscribe-and-abort loop must complete at least 30,000\n cancellations per second.\n- packed tarballs must stay under 250,000 bytes for `rxjs`, 30,000 bytes for\n the polyfill, 60,000 bytes for `@rxjs/test`, and 140,000 bytes for\n `@rxjs/migrate`.\n\nThe initial Node 24 evidence was 17,502 Webpack bytes, approximately 50.4\nmillion mapped values per second, and approximately 140,500 cancellations per\nsecond. The throughput floors deliberately leave substantial runner headroom;\nthe bundle ceiling leaves roughly 25% growth headroom while still catching a\nduplicate dialect or large accidental dependency.\n\nThe packed-adoption gate installs the local tarballs into an isolated consumer\nwith no registry access, then runs ESM, Node `require(esm)`, TypeScript, marble\ntesting, and a browser bundle. It also rejects source specs, duplicate output\ndialects, missing package documentation, and tarball-size regressions.\n\n## Commands\n\nFrom the repository root:\n\n```sh\npnpm run release:check\npnpm --filter rxjs run test:unit:audit:check\npnpm run test:bundle-analysis\npnpm run test:release:safari\npnpm run test:workflows\npnpm run test:release:runtime\npnpm run test:release:browsers\npnpm run test:release:safari\npnpm run test:release:webpack\npnpm run test:release:performance\npnpm run test:release:adoption\npnpm run test:wpt\n```\n\nDesktop and Mobile Safari execution is CI-owned because SafariDriver requires\nhost-level automation authorization. The Mobile Safari lane requests\n`platformName: iOS` and `safari:useSimulator: true`; Playwright WebKit is never\nsubstituted for that branded-browser gate.\n\nThe complete source-pinned RxJS 7 migration corpus is evidence, not a claim\nthat RxJS 9 implements every RxJS 7 behavior. Its reviewed intentional\ndivergences remain nonzero by design; the focused source suite, package gates,\nruntime matrix, and conformance suite are the blocking release checks.\n","packages/rxjs/docs/SECURITY_ASSURANCE.md":"# RxJS 9 security assurance\n\nRxJS 9 uses a deliberately small release boundary. This document describes\nthe evidence and trust assumptions; it does not promise that the software is\nfree of vulnerabilities.\n\n## What users can rely on\n\n- The `rxjs` runtime depends only on the RxJS-owned\n `@rxjs/observable-polyfill`; that package has no runtime dependencies.\n- Pull requests and every `master` push run the package, type, browser, Safari,\n Web Platform Test, bundler, performance, migration, dependency-review,\n CodeQL, and OSV checks described in [RELEASE_GATES.md](RELEASE_GATES.md).\n- npm publication is not available to GitHub Actions. The repository stores no\n npm publishing token and has no publishing workflow, trusted publisher, or\n release App.\n- A maintainer publishes from a clean local `master` checkout with\n `pnpm release:beta `. The command builds and tests, packs the four\n packages, prints SHA-512 integrities, and runs npm publication dry runs before\n asking for irreversible confirmation.\n- npm's interactive OTP/WebAuthn flow authorizes each package. Supporting\n packages publish first and `rxjs` publishes last.\n- The command verifies npm's registry integrity and `next` tag for all four\n packages and confirms that `rxjs@latest` remains on RxJS 7.\n- An interrupted command can skip an already-published package only when the\n registry integrity equals the freshly packed tarball.\n\n## One-maintainer reality\n\nRxJS currently has one active maintainer. The same person authors, reviews,\nmerges, and releases changes. Pull requests expose diffs and run mandatory\nchecks, but RxJS does not claim independent human approval. OpenSSF's\nCode-Review score is therefore accepted rather than manipulated with\nceremonial approvals.\n\nThe publication boundary trusts that maintainer's local machine and npm\nauthentication. Interactive WebAuthn, required CI, dry runs, ordered\npublication, and registry verification reduce common mistakes and credential\nrisks; they do not remove the risk of a compromised maintainer machine or npm\naccount. Recovery codes are kept offline. Package publishing access requires\ntwo-factor authentication and disallows automation tokens after each new\npackage record exists.\n\n## Verify a release\n\nAfter installing with a lockfile, verify npm registry signatures:\n\n```sh\nnpm audit signatures\n```\n\nInspect the registry integrity and channels directly:\n\n```sh\nnpm view rxjs@9.0.0-beta.0 dist.integrity\nnpm view rxjs@next version\nnpm view rxjs@latest version\n```\n\nThe release operator records all four integrity values and the immutable GitHub\nRelease URL in the project-plan session log.\n\n## Vulnerability evidence\n\nOSV scanning runs on pull requests, every `master` push, and weekly. Anything\nreachable from runtime, build, or test tooling must be fixed or removed. The\ninherited legacy documentation-application toolchain is excluded from RxJS 9\nand tracked separately; its time-bounded exceptions do not change the release\npackage scans.\n\nProperty-based tests exercise the Observable lifecycle state machine. Package\nand release-script tests cover synchronized versions, clean-checkout guards,\ninteractive credential restrictions, publication order, npm channels, and\nintegrity comparisons.\n\n## What this does not prove\n\nPassing tests does not prove that source is bug-free. A matching registry hash\nproves that npm received the local tarball; it does not prove that the local\nmachine or maintainer account was uncompromised. The initial manual publication\ndoes not provide npm's CI provenance attestation. These are accepted tradeoffs\nfor an understandable sole-maintainer process.\n\n## OpenSSF in context\n\n[![OpenSSF Scorecard](https://api.scorecard.dev/projects/github.com/ReactiveX/rxjs/badge)](https://scorecard.dev/viewer/?uri=github.com/ReactiveX/rxjs)\n\nOpenSSF Scorecard is a useful repository-hygiene signal, not a release gate or\nthe project's primary security claim. Users assessing a specific RxJS 9\nversion should prefer required-CI history, registry signatures, exact package\nintegrity, and the tagged source commit.\n","packages/rxjs/docs/UNSUPPORTED_RXJS_7_SURFACES.md":"# Unsupported RxJS 7 surfaces\n\nThis generated catalog records RxJS 7 public imports and behavioral protocols that RxJS Next does not preserve as compatibility APIs. It is migration guidance, not an emulation commitment. The source inventory is pinned to RxJS 7 `7.x` at `e5351d02e225e275ac0e497c7b66eaa5f0c88791`.\n\nRegenerate it with `pnpm --filter rxjs run test:unit:unsupported:generate`; the corresponding `--check` gate rejects a stale document, a source-pin mismatch, missing required categories, or unclassified scheduler-bearing capabilities.\n\n## Summary\n\n| Measure | Count |\n| -------------------- | ----: |\n| Catalog groups | 27 |\n| Named surfaces | 147 |\n| Manual Review groups | 5 |\n| Replace groups | 17 |\n| Unsupported groups | 5 |\n\n## Dispositions\n\n- **Replace:** a supported Next or platform destination exists, but its imports, types, or lifecycle may differ.\n- **Manual review:** no mechanical rewrite is safe without reviewing cancellation, sharing, timing, or ownership.\n- **Unsupported:** no accepted Next compatibility contract exists.\n- **Test only:** any adapter is limited to evidence infrastructure and must not become an application migration.\n- **Removed:** the surface has no replacement and should disappear.\n\n## Imports and package paths\n\n| RxJS 7 surface | Disposition | Migration direction | Why | Decisions |\n| ------------------------------------------------------------------------------------------------------------- | ------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ | ------------------- |\n| `rxjs/operators`
`root-imported operator functions`
`source.pipe(...)` | Replace | Import exact Symbols from rxjs/ and invoke source[symbol](...). Use rxjs/pipe only for deliberate Symbol composition. | RxJS Next does not publish the RxJS 7 pipeable-function or string-named .pipe surface. | D-003, D-039, D-050 |\n| `rxjs:Observable`
`rxjs:Subscriber` | Replace | Use the active realm's ambient Observable and Subscriber after @rxjs/observable-polyfill initialization when needed. | The platform owns these constructors; the rxjs root does not re-export compatibility classes for them. | D-039, D-040, D-041 |\n| `rxjs/testing`
`TestScheduler`
`VirtualTimeScheduler`
`VirtualAction` | Replace | Use @rxjs/test rxTest() and its explicit cold(), hot(), observable(), virtual host-time, and assertion helpers. | The public scheduler classes and manual TestScheduler mode are not part of the Next runtime or test contract. | D-012, D-033, D-039 |\n| `rxjs/ajax`
`rxjs/fetch`
`rxjs/webSocket`
`ajax`
`fromFetch`
`webSocket`
`WebSocketSubject` | Manual Review | Use platform fetch, XMLHttpRequest, WebSocket, EventTarget.when, or an application adapter selected for the required cancellation and sharing contract. | RxJS Next does not currently publish the RxJS 7 DOM specialty packages or their wrapper types. | D-039, D-040 |\n| `rxjs/internal/*`
`rxjs/src/*`
`unexported package paths` | Unsupported | Replace with an accepted public Next subpath or application-owned code after semantic review. | RxJS 7 internals are not preserved as public package contracts and must not be revived to satisfy migration tests. | D-039, D-040 |\n| `bindCallback`
`bindNodeCallback`
`scheduled`
`using`
`isObservable` | Manual Review | Wrap callback or resource ownership explicitly with Observable and AbortSignal; use platform conversion or capability-specific mappings where applicable. | No accepted public Next function preserves these RxJS 7 imports and complete overload contracts. | D-039, D-040, D-049 |\n| `ObjectUnsubscribedError`
`UnsubscriptionError` | Unsupported | Use platform error and AbortSignal reason handling or an application-owned aggregate error contract. | These errors belong to removed RxJS 7 Subscription and closed-Subject internals. | D-039, D-040 |\n\n## Types\n\n| RxJS 7 surface | Disposition | Migration direction | Why | Decisions |\n| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | ------------------- |\n| `UnaryFunction`
`OperatorFunction`
`MonoTypeOperatorFunction` | Replace | Use ordinary typed functions with exact Symbol invocation or rxjs/pipe composition. | RxJS Next does not publish the pipeable-operator type family. | D-039, D-050 |\n| `Subscription`
`SubscriptionLike`
`Unsubscribable`
`TeardownLogic` | Replace | Use AbortController, AbortSignal, SubscribeOptions, and Subscriber.addTeardown inside producers. | subscribe() returns undefined and cancellation is signal-owned; no Subscription facade is published. | D-039, D-041, D-049 |\n| `ObservableInput`
`ObservableLike`
`InteropObservable`
`Subscribable`
`SubscribableOrPromise`
`ReadableStreamLike` | Replace | Use the ambient ObservableValue/platform Observable.from input contract and review custom inputs manually. | The platform conversion boundary deliberately excludes arbitrary subscribables and legacy observable interop. | D-039, D-049 |\n| `NextObserver`
`ErrorObserver`
`CompletionObserver`
`PartialObserver`
`SubjectLike`
`Connectable` | Replace | Use ambient Observer/Subscriber shapes or the concrete intentional Subject/connectable APIs; define application protocols locally when needed. | These RxJS 7 helper interfaces are not a public Next import family. | D-035, D-039, D-040 |\n| `SchedulerLike`
`SchedulerAction`
`TimestampProvider` | Replace | Use host timing APIs, Date.now-compatible narrow providers where explicitly documented, and @rxjs/test virtual host time. | There is no general public scheduler abstraction in RxJS Next. | D-012, D-033, D-039 |\n| `FactoryOrValue`
`ObservedValueOf`
`ObservedValueUnionFromArray`
`ObservedValuesFromArray`
`ObservedValueTupleFromArray`
`ObservableInputTuple`
`Cons`
`Head`
`Tail`
`ValueFromArray`
`Falsy`
`TruthyTypesOf` | Unsupported | Use inference from the accepted Next API or application-owned utility types; do not deep-import RxJS internals. | These RxJS 7 implementation-facing inference helpers are not stable Next public types. | D-039, D-040 |\n| `GroupedObservable`
`Timestamp`
`TimeInterval` | Replace | Use the structural keyed group view, structural timestamp result, or TimeInterval exported by the exact rxjs/time-interval capability as applicable. | The RxJS 7 root type imports are not preserved even where a capability exposes an intentional structural or subpath-specific result. | D-003, D-039, D-040 |\n\n## Schedulers and scheduler overloads\n\n| RxJS 7 surface | Disposition | Migration direction | Why | Decisions |\n| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------- |\n| `asap`
`asapScheduler`
`async`
`asyncScheduler`
`queue`
`queueScheduler`
`animationFrame`
`animationFrameScheduler`
`Scheduler`
`VirtualTimeScheduler`
`VirtualAction` | Replace | Use virtualizable host timing and task APIs; use @rxjs/test for deterministic tests. | RxJS Next does not publish scheduler instances or scheduler classes. | D-012, D-033, D-039 |\n| `animationFrames`
`auditTime`
`bufferTime`
`concat`
`debounceTime`
`delay`
`empty`
`endWith`
`expand`
`from`
`generate`
`groupBy`
`interval`
`observeOn`
`pairs`
`publishReplay`
`range`
`sampleTime`
`scheduled`
`shareReplay`
`startWith`
`subscribeOn`
`throwError`
`throttleTime`
`timeInterval`
`timeout`
`timeoutWith`
`timer`
`timestamp`
`windowTime` | Manual Review | Remove only an explicitly classified scheduler overload and verify ordering with host-time behavior; otherwise retain the source and stop automation. | Current capabilities use host scheduling or narrow clock providers, and the port harness adapter is not a production SchedulerLike contract. | D-012, D-033, D-034, D-039 |\n\n## Interop protocols\n\n| RxJS 7 surface | Disposition | Migration direction | Why | Decisions |\n| ------------------------------------------------------------------------------------------------------------------------------- | ------------- | ---------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- | ------------------- |\n| `observable`
`Symbol.observable`
`@@observable`
`InteropObservable` | Unsupported | Expose a platform-supported ObservableValue category or wrap the source explicitly in the active realm. | Legacy observable interop is outside the accepted platform Observable.from contract. | D-039, D-049 |\n| `objects with subscribe()`
`lowerCaseO`
`asInteropObservable`
`custom Subscribable` | Manual Review | Write an explicit application adapter that owns cancellation and terminal behavior, or choose a supported platform input category. | The 15 executable compatibility-only failures deliberately preserve this unsupported input boundary. | D-039, D-049 |\n| `foreign-realm Observable`
`cross-window Observable`
`cross-worker Observable`
`borrowed symbols on unrelated objects` | Unsupported | Initialize each realm independently and bridge values through an explicit application protocol. | RxJS does not traverse realms or promise generic Symbol borrowing onto unrelated receivers. | D-041, D-048, D-049 |\n| `Observable.lift`
`source/operator fields`
`custom Operator` | Replace | Use exact Symbol composition and the versioned derived-construction protocol through supported public capabilities. | The RxJS 7 lift/source/operator protocol is removed and is not a public Next subclass hook. | D-037, D-039, D-049 |\n\n## Deprecated and removed aliases\n\n| RxJS 7 surface | Disposition | Migration direction | Why | Decisions |\n| --------------------------------------------------------------------------------------------------------------------------------- | ------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- | ------------------- |\n| `combineAll`
`exhaust`
`flatMap`
`pipeable partition` | Replace | Use combineLatestAll, exhaustMap(identity), mergeMap, or Observable[partition] respectively. | The deprecated RxJS 7 names are not public Next Symbol identities; migration uses their canonical accepted mappings. | D-003, D-039, D-049 |\n| `empty()`
`never()` | Replace | Use EMPTY and NEVER. | The deprecated creation functions are not retained as callable Next aliases. | D-039, D-040 |\n| `mapTo`
`concatMapTo`
`mergeMapTo`
`switchMapTo`
`pluck` | Replace | Use map with a constant or property projection, or the corresponding canonical flattening Symbol with an explicit projection. | Migration may preserve behavior through exact mappings, but the deprecated pipeable function/import shape is not supported. | D-003, D-039 |\n| `pipeable combineLatest`
`pipeable concat`
`pipeable merge`
`pipeable race`
`pipeable zip`
`onErrorResumeNextWith` | Replace | Use the accepted unified or With-form exact Symbol and its documented source-array/result-selector mapping. | Legacy pipeable aliases are migration inputs, not preserved function exports. | D-003, D-039, D-049 |\n| `multicast`
`publish`
`publishBehavior`
`publishLast`
`publishReplay`
`refCount` | Manual Review | Prefer share, shareReplay, connect, or connectable with an explicit connector/reset contract; exact legacy-named Symbols remain migration evidence, not a compatibility promise. | Producer sharing, replay, reset, and ref-count semantics require explicit lifecycle review. | D-035, D-039, D-049 |\n| `new BehaviorSubject(value)`
`new ReplaySubject(size, windowTime, scheduler)`
`ColdSubject` | Replace | Use behaviorSubject(value), replaySubject({ size, maxAge }), or the advanced PerSubscriptionSubjectBase only for a justified custom hot Subject. | D-050 stabilizes lowercase factories and removes the misleading ColdSubject name without aliases. | D-035, D-036, D-050 |\n| `eachValueFrom`
`bufferedValuesFrom` | Replace | Use one of iterateEachValue, iterateBufferedValues, iterateLatestValue, or iterateNextValue from its exact Symbol subpath. | The exploratory standalone helpers were removed so buffering and dropping policy stays explicit. | D-038, D-039 |\n\n## Review rule\n\nA migration tool may automate only a cataloged **replace** mapping whose target capability and contract are also present in the migration evidence ledger. It must stop with a structured diagnostic for **manual review**, **unsupported**, **test only**, or **removed** entries. Adding a compatibility runtime, scheduler abstraction, import alias, interop protocol, or deep-import bridge requires a new accepted architecture decision.\n","packages/test/README.md":"# `@rxjs/test`\n\nImplementation-neutral virtual-time and marble testing for RxJS 9 Observable\ncontracts.\n\n```sh\nnpm install --save-dev @rxjs/test@next rxjs@next\n```\n\n```ts\nimport 'rxjs';\nimport { rxTest } from '@rxjs/test';\nimport { map } from 'rxjs/map';\n\nawait rxTest(({ cold, expectObservable }) => {\n const source = cold('-a-b-|', { a: 1, b: 2 });\n expectObservable(source[map]((value) => value * 10)).toBe('-a-b-|', {\n a: 10,\n b: 20,\n });\n});\n```\n\nUse `cold()` only when the test deliberately needs one producer per direct\nsubscription. Use `observable()` when the contract should exercise the active\nplatform Observable constructor. The package never installs a platform\nObservable for the consumer; import `rxjs` or\n`@rxjs/observable-polyfill` first when the realm does not already provide one.\n\n`rxTest` supplies scheduled work, hot/cold/platform sources, Observable and\nsubscription expectations, explicit time plans, and configurable deep-equality\nassertions. Failures use `RxTestAssertionError` and include structured assertion\ninformation.\n\nThe package requires Node 22.13+, publishes ESM only, and declares an exact peer\non the matching RxJS 9 prerelease train. The\n[`rxjs` migration guide](https://github.com/ReactiveX/rxjs/blob/master/packages/rxjs/MIGRATION.md)\nexplains how to review lifecycle choices when translating RxJS 7\n`TestScheduler.run` tests.\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","rawUrl":"https://raw.githubusercontent.com/ReactiveX/rxjs/HEAD/AGENTS.md","title":"AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"# RxJS Next repository guidance\n\nThis branch is the foundation for a new platform-based generation of RxJS, with\nthe working name **RxJS Next** and a probable release name of **RxJS 9**. It is\nnot an incremental RxJS 7 implementation.\n\nBefore making changes, read these documents in order:\n\n1. `docs/rxjs-next/PROJECT_CHARTER.md`\n2. `docs/rxjs-next/ARCHITECTURE.md`\n3. `docs/rxjs-next/DECISIONS.md`\n4. `docs/rxjs-next/PROJECT_PLAN.md`\n5. `docs/rxjs-next/OPEN_QUESTIONS.md`\n6. `docs/rxjs-next/COMPATIBILITY.md` when changing APIs or behavior\n\n## Required working rules\n\n- Treat the current code as an exploratory implementation, not the completed\n architecture. Preserve the distinction between current behavior, accepted\n direction, and proposals.\n- Use the native web-platform `Observable` when it exists. A polyfill must not\n replace a conforming native implementation.\n- Add RxJS behavior to the platform constructor or its prototype through\n exported Symbols. Do not add string-named RxJS methods to the platform\n `Observable` surface.\n- Export corresponding RxJS Symbols even for operators that already have a\n platform string method, such as `map` and `filter`. Preserve both forms:\n `observable.map(project)` is the platform contract and\n `observable[map](project)` is the RxJS contract. The Symbol form may delegate\n or add functionality, but it must not replace the string method; document and\n test every intentional difference.\n- Preserve the collision isolation of exact Symbol keys: unrelated code using\n the same descriptive name must not be able to overwrite an RxJS extension.\n Do not introduce `Symbol.for` keys without an accepted namespacing and\n duplicate-install decision.\n- Keep platform semantics and RxJS 7 compatibility semantics in separate\n architectural layers. In particular, do not silently make the platform\n `Observable` behave like an RxJS 7 cold observable.\n- Use `AbortSignal` and the platform `Subscriber` lifecycle as the cancellation\n foundation for the platform layer.\n- Do not assume the old RxJS 7 tests can pass unchanged. Classify every migrated\n test according to the compatibility policy in `COMPATIBILITY.md`.\n- Do not revive removed RxJS 7 internals in the platform package to make a test\n pass. Put compatibility behavior behind an explicit compatibility boundary.\n- When implementing against the living Observable specification or Web\n Platform Tests, record the exact upstream revision used.\n- Preserve RxJS 7 history. The old implementation remains an important source\n of behavioral tests, migration knowledge, and compatibility requirements.\n\n## Project-plan discipline\n\n`docs/rxjs-next/PROJECT_PLAN.md` is the active execution queue. Work on the\nsingle item marked `NEXT` unless the user explicitly changes priorities or a\nsmall prerequisite is required. Keep exactly one `NEXT` item, update the\ncompletion evidence, and append a short session-log entry when completing a\nplan item.\n\n## Architecture-change discipline\n\nUpdate the documentation in the same change when code alters any of these:\n\n- package or import boundaries;\n- native-versus-polyfill selection;\n- Symbol identity or patch installation;\n- subscription sharing, ref counting, cancellation, or teardown;\n- subclass or realm behavior;\n- compatibility guarantees;\n- public exports;\n- test or conformance gates.\n\nRecord durable decisions in `docs/rxjs-next/DECISIONS.md`. Move unresolved\nquestions into or out of `docs/rxjs-next/OPEN_QUESTIONS.md` as evidence changes.\n\n## Verification\n\nRun the narrowest relevant tests and build/type checks. Record failures\nhonestly; do not treat a passing unit test as proof of platform conformance.\nThe current known baseline is documented in `ARCHITECTURE.md`.\n","isInternal":false,"tokens":818,"sizeBytes":3735},{"name":".rxjs-migrate-skill.json","path":".agents/skills/rxjs-next-migration/.rxjs-migrate-skill.json","rawUrl":"https://raw.githubusercontent.com/ReactiveX/rxjs/HEAD/.agents/skills/rxjs-next-migration/.rxjs-migrate-skill.json","title":"Rxjs-next-migration Skill","category":"anthropic-skill","format":"json","content":"{\n \"schemaVersion\": 1,\n \"packageName\": \"@rxjs/migrate\",\n \"packageVersion\": \"9.0.0-beta.0\",\n \"digestAlgorithm\": \"sha256\",\n \"digest\": \"2b5c6b52bc8060df40c48443cfb5ebb0d55da5687bb74806daf95ac4912594fa\",\n \"files\": [\n \"SKILL.md\",\n \"assets/migration-report.md\",\n \"references/assessment-and-contract.md\",\n \"references/engine-and-batches.md\",\n \"references/review-checklist.md\",\n \"references/test-migration.md\",\n \"references/verification-and-closeout.md\"\n ],\n \"installSchemaVersion\": 1,\n \"adapter\": \"agents\",\n \"compatibleHarnesses\": [\n \"codex\",\n \"cursor\"\n ],\n \"targetPath\": \".agents/skills/rxjs-next-migration\"\n}\n","frontmatter":{"schemaVersion":1,"packageName":"@rxjs/migrate","packageVersion":"9.0.0-beta.0","digestAlgorithm":"sha256","digest":"2b5c6b52bc8060df40c48443cfb5ebb0d55da5687bb74806daf95ac4912594fa","files":["SKILL.md","assets/migration-report.md","references/assessment-and-contract.md","references/engine-and-batches.md","references/review-checklist.md","references/test-migration.md","references/verification-and-closeout.md"],"installSchemaVersion":1,"adapter":"agents","compatibleHarnesses":["codex","cursor"],"targetPath":".agents/skills/rxjs-next-migration"},"isInternal":false,"tokens":201,"sizeBytes":643},{"name":"migration-report.md","path":".agents/skills/rxjs-next-migration/assets/migration-report.md","rawUrl":"https://raw.githubusercontent.com/ReactiveX/rxjs/HEAD/.agents/skills/rxjs-next-migration/assets/migration-report.md","title":"Assets Skill","category":"anthropic-skill","format":"markdown","content":"# RxJS Next migration report\n\nThis report summarizes the machine-readable migration contract. The manifest\nvalidated by the installed `@rxjs/migrate` schema remains the authoritative\nstructured decision and evidence record.\n\n## Scope and authority\n\n- Repository:\n- Source revision:\n- Migration boundary:\n- Authorized write paths:\n- Package manager:\n- Network policy:\n- Existing changes protected:\n- Developer/approver:\n\n## Tool and dependency identity\n\n| Item | Version or digest | Evidence |\n| ---------------------- | ----------------- | -------- |\n| Source RxJS | | |\n| Target RxJS Next | | |\n| `@rxjs/migrate` engine | | |\n| Capability registry | | |\n| Canonical Skill | | |\n| Contract schema | | |\n\n## RxJS 7 baseline\n\n| Check ID | Command | Environment | Exit | Result | Accepted pre-existing failure |\n| -------- | ------- | ----------- | ---: | ------ | ----------------------------- |\n\n## Risk and coverage assessment\n\n| Finding | Source locations | Lifecycle/behavior risk | Coverage disposition | Evidence or approval |\n| ------- | ---------------- | ----------------------- | -------------------- | -------------------- |\n\n## Target contract units\n\n| Unit ID | Source locations | RxJS 7 claim | Target lifecycle | Evidence classification | Approval | Evidence |\n| ------- | ---------------- | ------------ | ---------------- | ----------------------- | -------- | -------- |\n\n## Migration batches\n\n| Batch | Scope | Dry-run report | Diagnostics reviewed | Write approved by | Changed files |\n| ----- | ----- | -------------- | -------------------- | ----------------- | ------------- |\n\n## Diagnostics\n\n| Diagnostic ID | File/span | Disposition | Classification | Required action | Resolution or owner |\n| ------------- | --------- | ----------- | -------------- | --------------- | ------------------- |\n\n## Intentional divergences\n\n| Units | Previous claim | Approved Next claim | User impact | Evidence | Approver/time/rationale |\n| ----- | -------------- | ------------------- | ----------- | -------- | ----------------------- |\n\n## Verification\n\n| Check ID | Command | Environment | Exit | Result | Summary |\n| -------- | ------- | ----------- | ---: | ------ | ------- |\n\n## Outcome classification\n\n### Migration defects repaired\n\n-\n\n### RxJS Next product gaps\n\n-\n\n### Environment or baseline limitations\n\n-\n\n## Accepted blockers\n\n| Owner | Affected units | Reason | Evidence | Prevented outcome | Acceptance |\n| ----- | -------------- | ------ | -------- | ----------------- | ---------- |\n\n## Readiness and handoff\n\n- Manifest schema validation:\n- Readiness assessment:\n- Remaining decisions:\n- Next action and owner:\n- Measured migration outcome and limitations:\n","isInternal":false,"tokens":537,"sizeBytes":2899},{"name":"assessment-and-contract.md","path":".agents/skills/rxjs-next-migration/references/assessment-and-contract.md","rawUrl":"https://raw.githubusercontent.com/ReactiveX/rxjs/HEAD/.agents/skills/rxjs-next-migration/references/assessment-and-contract.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# Assessment, baseline, and target contract\n\nUse this reference during Stages 2 through 4. Collect evidence before asking\nthe developer to choose a target contract; ask only about intent the repository\ncannot prove.\n\n## Repository assessment\n\nRecord exact file locations and the commands or tests that exercise each\nfinding. Search application source, shared libraries, tests, configuration,\nfixtures, build tools, and framework glue for these themes:\n\n| Theme | Look for | Behavioral question |\n| --------------------- | ------------------------------------------------------------------ | ----------------------------------------------------------------- |\n| Construction | `new Observable`, `defer`, custom producers, wrappers | When is producer work created and restarted? |\n| Repeated subscription | retry, refresh, fan-out, cache invalidation, multiple consumers | Must consumers run independent work or share one active run? |\n| Subjects | current/replayed values, late subscribers, terminal state | What exists before observation and what must late observers see? |\n| Ownership | captured subscriptions, `unsubscribe`, component disposal | Who cancels, with what reason, and when does upstream stop? |\n| Teardown | multiple teardown callbacks, finalizers, resource release | Does observable order matter? |\n| Timing | schedulers, timers, animation, queue ordering, virtual time | Which host timing boundary preserves the claim? |\n| Errors | selector errors, observer callback errors, late errors | Where must the error be delivered or reported? |\n| Inputs | iterables, async iterables, promises, custom subscribables | Is the value accepted by the platform conversion boundary? |\n| Composition | pipeable operators, aliases, higher-order pipelines | Is a fixture-proved Symbol mapping available for this exact form? |\n| Testing | TestScheduler helpers, framework assertions, native/polyfill setup | Which claims are real behavior and which are harness machinery? |\n\nTrace imports and helper wrappers so transitive usage is not mistaken for\nabsence. Sampling is acceptable only when its limits are named and accepted.\n\n## Coverage disposition\n\nGive every lifecycle-sensitive finding exactly one disposition:\n\n- **Covered:** a named existing test proves the relevant behavior.\n- **Characterize:** add a focused RxJS 7 test before migration.\n- **Unsupported:** no accepted Next surface can preserve the required claim;\n retain evidence and record a product gap.\n- **Accepted uncovered risk:** the developer explicitly accepts proceeding\n without the missing evidence; record approver, time, rationale, and impact.\n\nRecommend characterization for repeated subscriptions, side effects, sharing,\nlate subscribers, cancellation, teardown, timing, errors, or public API behavior\nwhen current tests do not prove the outcome.\n\n## Characterization protocol\n\nAdd the narrowest test that proves an externally meaningful claim. Prefer\nassertions over values, completion/error, producer start count, concurrent and\nlate observations, cancellation ownership, abort reason, teardown order,\nvirtual or host timing, and visible side effects. Avoid locking in irrelevant\nRxJS 7 internals.\n\nRun the new test on the unchanged RxJS 7 dependency. Record the exact command\nand result. A characterization test added after dependency migration is not an\nRxJS 7 baseline unless it is separately demonstrated against the pinned source\nenvironment.\n\n## Lifecycle decision record\n\nUse only lifecycle values accepted by the installed contract-manifest schema.\nExplain each selection in behavioral language:\n\n- active platform producer shared and ref-counted while observers exist;\n- producer work created per direct subscription through an explicit Next API;\n- intentional hot Subject behavior;\n- no producer lifecycle applies;\n- required behavior is unsupported; or\n- intent remains unresolved.\n\nDo not use a blanket “hot” or “cold” label for a platform Observable. The first\nobserver starts an active producer, concurrent observers join it, the last\nobserver leaving tears it down, and a later observer can start a new run.\n\nFor every unit, record:\n\n1. stable ID and exact source spans;\n2. current RxJS 7 claim and evidence;\n3. selected target lifecycle;\n4. compatibility/evidence classification accepted by the installed schema;\n5. one or more target claims;\n6. approval status, approver, timestamp, and rationale when required; and\n7. related diagnostics, divergences, and blockers.\n\n## Mandatory developer pauses\n\nPause rather than infer when:\n\n- both independent and shared producer behavior are plausible;\n- repeated subscriptions may implement retry, refresh, cache, or fan-out;\n- Subject replay, terminal, or late-observer behavior is unproved;\n- cancellation ownership, abort reason, or teardown order could change;\n- scheduler removal could alter ordering;\n- a custom subscribable is outside the accepted conversion boundary;\n- a public claim changes or an expectation would need to change;\n- coverage is missing or the baseline is not green; or\n- a unit remains unresolved, unsupported without acceptance, or pending\n approval in the readiness assessment.\n\nThe engine's diagnostic can identify a pause condition, but only the developer\ncan approve lifecycle intent or an intentional divergence.\n","isInternal":false,"tokens":1032,"sizeBytes":5730},{"name":"engine-and-batches.md","path":".agents/skills/rxjs-next-migration/references/engine-and-batches.md","rawUrl":"https://raw.githubusercontent.com/ReactiveX/rxjs/HEAD/.agents/skills/rxjs-next-migration/references/engine-and-batches.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# Engine registry and migration batches\n\nUse this reference during Stages 5 and 6. `@rxjs/migrate` is a deterministic\nengine for a bounded syntax subset. It is not an autonomous repository\nmigration tool.\n\n## Consume installed contracts\n\nRead engine data from the project's installed package, not from a list copied\ninto a prompt, Skill, or harness adapter. The public API exports the default\ncapability registry, registry and manifest schemas, migration functions,\ncontract readiness assessment, and engine/schema versions.\n\nA local inspection can use the project's module runner with this shape:\n\n```js\nimport { assessMigrationContractReadiness, defaultCapabilityRegistry, migrationContractManifestSchema } from '@rxjs/migrate';\n\nfor (const capability of defaultCapabilityRegistry.capabilities) {\n // Review id, legacy/source name, target Symbol, adapter, arity,\n // preconditions, status, and fixture evidence for this exact package.\n}\n\nconst parsed = migrationContractManifestSchema.safeParse(manifest);\nif (parsed.success) {\n const readiness = assessMigrationContractReadiness(parsed.data, {\n expectedSkillDigest,\n });\n}\n```\n\nObtain `expectedSkillDigest` from the installed adapter's integrity check or\nthe Node-only `@rxjs/migrate/skill` API. Consult the installed TypeScript\ndeclarations for exact signatures. Refuse an incompatible custom registry\nrather than adapting it informally. A registry entry proves only the source\nforms, overloads, preconditions, and fixtures it names; it does not promise\ngeneral RxJS 7 compatibility.\n\n## Capability selection\n\nBefore selecting a transform, verify all of the following:\n\n- registry schema, registry version, and engine version match the installed\n package;\n- the source import binding is the one identified by the engine and is not\n shadowed or repurposed;\n- the call shape, arity, scheduler/result-selector form, and pipeline context\n satisfy every declared precondition;\n- the fixture evidence covers the intended mapping and evidence class; and\n- the migration unit already has an approved lifecycle contract.\n\nName similarity, a compatible TypeScript signature, or a green transformed\ntest is not a substitute for those checks.\n\n## Dry-run protocol\n\nInvoke the locally installed `rxjs-migrate` binary through the project's\npackage manager. Supply all required provenance. For example:\n\n```sh\nrxjs-migrate \\\n --source-root \\\n --source-repo \\\n --source-sha \\\n --mode \\\n --framework preserve \\\n \n```\n\nOmit `--mode` when the selected source does not require a lifecycle choice.\nNever let a directory name or wrapper select it implicitly. Use the package's\ndocumented framework adapter only for a separately approved framework change.\n\nWithout `--write`, the CLI returns a versioned JSON report and performs no\nwrites. Record its engine version, registry version, operation, file results,\nordered diagnostics, and exit status. The current CLI contract distinguishes\ncompleted, structured refusal, invalid arguments, and operational failure;\nread the installed package documentation for the exact numeric codes.\n\nReview every diagnostic, including source span, severity, disposition, refusal\nscope, classification, next action, and capability ID when present. A refused\nbatch must leave source and destination unchanged.\n\n## Write protocol\n\nAfter the dry run and changed paths are approved, repeat the same inputs with\nan explicit contained destination:\n\n```sh\nrxjs-migrate \\\n --source-root \\\n --source-repo \\\n --source-sha \\\n --mode \\\n --framework preserve \\\n --write --out-dir \\\n \n```\n\nThe engine plans the whole batch before writing and refuses lexical, canonical,\nor symlink path escape. Do not bypass containment or no-overwrite behavior with\nmanual bulk writes. If the reviewed destination is the current source tree,\nmake that scope and overwrite decision explicit and keep recovery possible.\n\nCompare the write report with the dry run byte for byte where contractual.\nInspect the diff for:\n\n- provenance and filenames;\n- exact Symbol imports and calls;\n- preserved unsupported source;\n- lifecycle helper selection;\n- awaited asynchronous test helpers;\n- framework preservation or the separately selected adapter;\n- retained assertions, errors, subscription claims, and local helpers; and\n- absence of hidden generators or compatibility layers.\n\nThen run the same transform again without writes. The second result must be\nunchanged with stable diagnostics. Any output or diagnostic drift is an engine\ndefect; stop the batch and preserve a reproduction.\n\n## Refusal and manual repair\n\nDo not turn refused syntax into claimed mechanical output by editing around the\ndiagnostic. Carry the finding into the contract and choose one of these paths:\n\n1. narrow the batch to independently safe units;\n2. add characterization, obtain a developer decision, and make a reviewed\n semantic edit outside the engine's claimed output;\n3. report an RxJS Next product gap; or\n4. preserve the source and accept a named blocker.\n\nManual work remains subject to the same baseline, lifecycle, review, and\nverification gates. It must not be described as fixture-proved engine output.\n","isInternal":false,"tokens":1090,"sizeBytes":5377},{"name":"review-checklist.md","path":".agents/skills/rxjs-next-migration/references/review-checklist.md","rawUrl":"https://raw.githubusercontent.com/ReactiveX/rxjs/HEAD/.agents/skills/rxjs-next-migration/references/review-checklist.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# Migration closeout checklist\n\n## Authority and provenance\n\n- Repository instructions, scope, allowed writes, package manager, and network\n policy were recorded before broad changes.\n- Existing work was protected and every changed file is within the authorized\n migration boundary.\n- Source repository/revision, RxJS versions, engine version, registry version,\n and canonical Skill digest are exact and reproducible.\n- The installed Skill content matches the installed `@rxjs/migrate` package.\n\n## Baseline and coverage\n\n- Agreed build, type, lint, test, and behavior gates were run on unchanged\n RxJS 7 source.\n- Every baseline failure is either fixed or explicitly recorded as pre-existing\n with developer acceptance.\n- Each lifecycle-sensitive path is linked to existing coverage,\n characterization, explicit unsupported status, or an accepted uncovered\n risk.\n- Characterization tests passed against RxJS 7 before dependency/source\n migration.\n\n## Target contract\n\n- Every unit has stable source locations, a behavioral claim, one target\n lifecycle, an evidence classification, and supporting evidence.\n- No required unit remains unresolved or pending approval.\n- Platform sharing and producer-per-direct-subscription behavior were selected\n intentionally rather than inferred from syntax.\n- Subjects, repeated subscriptions, cancellation, teardown, timing, errors,\n and input conversion were reviewed where applicable.\n- Every intentional divergence records old and new claims, user impact,\n evidence, approver, timestamp, and rationale.\n\n## Mechanical batches\n\n- Capability decisions came from the installed versioned registry; no copied\n operator list or name-only match was used.\n- Each engine operation ran dry first with exact provenance and an explicit\n lifecycle mode when required.\n- The dry-run scope, diagnostics, and changed paths were reviewed before write.\n- Refused or unsupported source remains visible and was not smuggled through a\n partial transform.\n- Writes stayed within the approved destination and did not overwrite local\n content without explicit approval.\n- Output preserves ordinary project-owned source, direct tests, assertions,\n and the selected framework.\n- Every applied transform is parseable, type-checkable at its narrow boundary,\n and idempotent with stable diagnostics.\n\n## Verification and handoff\n\n- Focused characterization/migrated tests and all agreed project gates were\n run with exact commands, environments, exit codes, and results.\n- Failures are classified as migration defects, product gaps, intentional\n divergences, baseline/environment issues, or unresolved—not relabeled for a\n green report.\n- No test was weakened, skipped, deleted, or replaced without explicit\n developer approval and a recorded contract change.\n- Schema validation and readiness assessment were both run; one is not being\n used as a substitute for the other.\n- All diagnostics are resolved, carried with an owner, or represented by an\n explicitly accepted blocker.\n- The final report states measured outcomes and limitations without claiming\n general automatic migration.\n","isInternal":false,"tokens":601,"sizeBytes":3126},{"name":"test-migration.md","path":".agents/skills/rxjs-next-migration/references/test-migration.md","rawUrl":"https://raw.githubusercontent.com/ReactiveX/rxjs/HEAD/.agents/skills/rxjs-next-migration/references/test-migration.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# TestScheduler and marble-test migration\n\nUse this reference only for selected RxJS 7 `TestScheduler` or marble tests.\nPreserve behavioral evidence and the project's ordinary test conventions.\n\n## Preserve the outer framework\n\nKeep the project's `describe`, `it`, `test`, hooks, assertion library, spies,\nand configuration by default. Treat a requested framework change as a separate\nadapter over the same migrated test body. If the installed engine does not\nsupport the requested source/target pair, preserve the framework and report\nthe conversion as manual work rather than guessing globals or assertions.\n\nEmit direct, readable test declarations. Materialize selected parameterized\ncases when necessary; do not introduce a runtime loop, hidden registry,\ngenerated location shim, or generator warning.\n\n## Preserve provenance and claims\n\nRecord the source repository, exact revision, and source path for every\nmigrated file. State the old case's behavioral claim before editing it. Keep\ncase-level comments only where they explain a real lifecycle, scheduler,\ncancellation, or divergence decision.\n\nTreat analyzer fingerprints as duplicate candidates, never automatic deletion.\nConsolidate only when public API/overload, lifecycle, values, timing, completion,\nerrors, cancellation, subscription claim, and relevant type behavior all\nmatch. Retain links to every original case in the manifest/report.\n\n## Convert harness structure\n\nReplace a supported `TestScheduler.run(...)` wrapper with one direct `rxTest`\ncall. Remove a scheduler variable, constructor, matcher adapter, or setup hook\nonly when it has no other responsibility. Return or await the `Promise`\nfrom `rxTest` through the outer test.\n\nPreserve the meaning of supported helpers:\n\n- `cold()` represents producer-per-subscription evidence;\n- `hot()` represents a subject-like absolute timeline;\n- `observable()` represents the shared, ref-counted platform producer;\n- `expectObservable()` retains cancellation from the subscription marble;\n- `expectSubscriptions()` describes observer subscriptions for cold sources\n and producer activation windows for platform sources;\n- `time()` and `animate()` use the `@rxjs/test` virtual host boundary; and\n- `flush()` is asynchronous and must be awaited from an `async` callback.\n\nRefuse or manually classify direct scheduler state, methods used outside the\nsupported run callback, scheduler subclasses, implementation-only queue/frame\nassertions, or unsupported framework assertions. Do not erase them as obsolete\nwithout a reviewed evidence classification.\n\n## Convert composition through the registry\n\nFor each RxJS 7 pipeable call, look up the exact installed capability entry and\napply only its declared Symbol target, argument adapter, arity, preconditions,\nand fixture-proved source shape. Convert a supported sequence into successive\nexact-Symbol calls and import those Symbols from the declared modules.\n\nDo not copy a table of operator mappings into project guidance. Do not use a\nplatform string method because its description matches an RxJS 7 operator.\nPreserve unsupported overloads and mixed pipelines with their diagnostics.\n\nUse an ambient/global `Observable` when the accepted target contract requires\nplatform construction. Do not import the constructor from a polyfill merely to\nmake a test pass.\n\n## Review lifecycle and realms\n\nKeep a producer-per-subscription baseline visibly separate from platform\ncoverage. For the platform lifecycle, test first activation, concurrent join,\nlate observation, individual abort, final abort/teardown, and later restart as\napplicable.\n\nRun the same platform claim against fallback and native implementations where\nthe project supports both. Initialize each in an isolated process, worker,\nwindow, or iframe before importing RxJS extensions and tests. If the realm has\nno native `Observable`, record native mode as unavailable; never install the\nfallback and label the result native.\n\nRemove scheduler arguments only when the installed target capability and its\nfixtures prove a host-timed mapping that `rxTest` virtualizes. Preserve original\nerror values and ordinary non-marble assertions. If product behavior fails a\nfaithful migrated claim, retain the evidence as a product gap rather than\nchanging production code or weakening the expectation.\n","isInternal":false,"tokens":827,"sizeBytes":4317},{"name":"verification-and-closeout.md","path":".agents/skills/rxjs-next-migration/references/verification-and-closeout.md","rawUrl":"https://raw.githubusercontent.com/ReactiveX/rxjs/HEAD/.agents/skills/rxjs-next-migration/references/verification-and-closeout.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# Verification, repair, and closeout\n\nUse this reference during Stages 7 and 8. Outcome evidence outranks source\nshape.\n\n## Verification ladder\n\nRun checks from narrowest to broadest so a failure remains diagnosable:\n\n1. parse and format the changed files;\n2. run focused type checks;\n3. run characterization and directly migrated tests;\n4. run the affected package or workspace build, type, lint, and test gates;\n5. run agreed integration, browser, native/polyfill, or repository-wide gates;\n6. repeat any command whose environment was changed during diagnosis.\n\nRecord the exact command, relevant environment facts, exit code, status, and a\nconcise summary. “Passed locally” without a command and environment is not a\nverification record.\n\nFor lifecycle-sensitive code, verify the contract actually selected:\n\n- producer activation count and restart;\n- concurrent and late observation;\n- individual and final cancellation;\n- abort reason and upstream closure;\n- Subject current/replay/terminal behavior;\n- teardown ordering;\n- time and scheduling order;\n- error delivery and late/unhandled error behavior; and\n- input conversion acceptance or explicit refusal.\n\n## Failure classification and response\n\n| Class | Meaning | Required response |\n| ---------------------- | -------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------- |\n| Migration defect | The edit broke syntax, types, test intent, mapping, or selected contract | Repair a small batch and rerun affected gates |\n| RxJS Next product gap | The accepted target surface cannot satisfy preserved evidence | Keep evidence visible; report the product gap |\n| Intentional divergence | Approved Next behavior differs from the RxJS 7 claim | Record old/new claims, impact, evidence, and approval before changing expectations |\n| Baseline/environment | The failure existed before migration or the required runtime/tool is unavailable | Preserve its original status and record the limitation or accepted failure |\n| Unknown | Evidence does not yet identify the cause | Investigate or pause; never relabel for convenience |\n\nAllowed repairs clarify or correct migrated code, strengthen characterization,\nor fix a demonstrated migration defect while preserving the approved contract.\n\nThe following require a developer pause:\n\n- deleting, skipping, quarantining, or weakening a test;\n- changing a public behavioral claim;\n- adding a local operator, scheduler, compatibility facade, or assertion shim;\n- changing platform behavior to imitate RxJS 7;\n- broad dependency or configuration changes beyond reviewed scope; or\n- accepting a red or unrun required gate.\n\n## Manifest closeout\n\nBuild the manifest against the exact schema exported by the installed package.\nAt minimum, record the schema and engine identity required by that version,\ncapability-registry version, canonical Skill digest, exact source and target\nRxJS versions, baseline checks, migration units, diagnostics, intentional\ndivergences, verification results, and blockers.\n\nStructural validity answers only “is this shaped correctly?” Run the separate\nreadiness assessment to detect unresolved lifecycle units, pending approvals,\nunresolved/refused diagnostics, unapproved divergences, missing or red gates,\nidentity mismatches, and unaccepted blockers.\n\nAn accepted blocker must name:\n\n- its owner and reason;\n- affected units;\n- supporting evidence;\n- the behavior, environment, or release claim it prevents; and\n- explicit developer acceptance.\n\nDo not use a blocker to hide an unexplained regression. A migration may close\nas `ready-with-accepted-blockers` only when the installed readiness assessment\nreturns that state and the human-readable report makes the limitations clear.\n\n## Final handoff\n\nUse the report asset to summarize:\n\n- scope and provenance;\n- installed engine, registry, Skill, source RxJS, and target RxJS identity;\n- RxJS 7 baseline and characterization evidence;\n- lifecycle decisions and approvals;\n- changed source and tests by coherent batch;\n- exact final commands and results;\n- diagnostics and how each was resolved or carried;\n- repaired migration defects;\n- remaining product gaps, divergences, and environment limits; and\n- blocker ownership and next actions.\n\nDo not report “automatic migration succeeded.” State the measured project\noutcome and its limits.\n","isInternal":false,"tokens":844,"sizeBytes":4815},{"name":"SKILL.md","path":".agents/skills/rxjs-next-migration/SKILL.md","rawUrl":"https://raw.githubusercontent.com/ReactiveX/rxjs/HEAD/.agents/skills/rxjs-next-migration/SKILL.md","title":"rxjs-next-migration","category":"anthropic-skill","format":"markdown","content":"---\nname: rxjs-next-migration\ndescription: Migrate an RxJS 7 application, library, or test suite to RxJS Next through an agent-led workflow that establishes a green behavioral baseline, makes Observable lifecycle choices explicit, uses @rxjs/migrate only for bounded fixture-proved rewrites, repairs without weakening evidence, and records a versioned migration contract. Use for repository assessment, migration planning or execution, lifecycle review, TestScheduler conversion, or migration closeout.\n---\n\n# RxJS 7 to RxJS Next migration\n\nTreat this as reviewed project work, not a codemod run. The objective is an\nintentional RxJS Next contract backed by the project's own build and behavior\nevidence. A transformed file, a clean diff, or one passing test is not proof\nthat the migration is complete.\n\nWork through all eight stages in order. Re-enter an earlier stage whenever new\nevidence changes scope, coverage, or lifecycle intent. Keep the developer\ninvolved at every explicit pause.\n\n## Non-negotiable rules\n\n- Read and obey repository-local instructions before acting. Protect existing\n work and stay within the authorized repository and paths.\n- Establish the RxJS 7 baseline before changing dependencies or source.\n- Never infer platform sharing versus producer-per-direct-subscription behavior\n from syntax, filenames, operator names, or a currently passing output.\n- Use the installed engine's versioned registry and schemas as authority. Do\n not reconstruct capability mappings from this Skill or from memory.\n- Run the deterministic engine without writes first. A refusal is a successful\n safety outcome, not permission to improvise a mechanical rewrite.\n- Preserve the project's test framework by default. Select a framework adapter\n only when the developer asked for that separate conversion.\n- Do not weaken, skip, delete, or replace a behavioral expectation merely to\n make the migrated suite green.\n- Do not add RxJS 7 compatibility shims, string-named platform methods, local\n substitute operators, or runtime generators unless the developer separately\n authorizes that product work.\n- Keep changes in small coherent batches. Review and verify each batch before\n widening the scope.\n- Do not call a migration complete while a required command is unknown,\n unapproved, skipped, or red without an explicitly accepted blocker.\n\n## Working record\n\nCreate or locate a checked-in migration contract manifest and a concise\nhuman-readable report. Use the schema exported by the installed\n`@rxjs/migrate`; schema validity and migration readiness are separate checks.\nUse [assets/migration-report.md](assets/migration-report.md) for the report.\n\nFor every migration unit, preserve source locations and record:\n\n- its current RxJS 7 behavioral claim;\n- the target lifecycle selected by the developer;\n- its evidence classification and supporting tests;\n- approval state, diagnostics, and any intentional divergence; and\n- verification or a named blocker.\n\n## Stage 1: Establish authority and scope\n\n1. Locate repository instructions, package and workspace metadata, lockfiles,\n CI configuration, RxJS versions, build/test commands, and current working\n tree state.\n2. Identify the repository root, migration boundary, permitted writes,\n package manager, network policy, and candidate verification commands.\n3. Record the installed `@rxjs/migrate` version and canonical Skill digest.\n If the installed Skill does not match its package, stop and synchronize it\n before trusting these instructions.\n4. State the proposed read, write, dependency, and command scope before broad\n changes.\n\nPause for the developer if the target repository or allowed scope is unclear,\nexisting changes overlap the migration, or destructive, networked, external,\nor broader actions require new authority.\n\nExit only when the scope, allowed writes, package manager, and candidate gates\nare recorded.\n\n## Stage 2: Assess usage, lifecycle risk, and coverage\n\nInventory installed RxJS versions and import forms, then locate Observable\nconstruction, custom producers, Subjects, subscription ownership, repeated\nsubscriptions, retry/refresh/cache paths, schedulers and timing, test helpers,\ninterop inputs, cancellation, teardown, and error handling. Include direct and\ntransitive operator usage.\n\nFor each lifecycle-sensitive path, link exact source evidence and mark it as:\n\n- covered by an existing baseline;\n- requiring a characterization test;\n- explicitly unsupported; or\n- an uncovered risk the developer accepts.\n\nProduce a risk and coverage report before proposing rewrites. Read\n[references/assessment-and-contract.md](references/assessment-and-contract.md)\nfor the inventory and characterization protocol.\n\nExit only when every in-scope lifecycle-sensitive use has one recorded\ncoverage disposition. Missing coverage is not evidence that behavior is safe.\n\n## Stage 3: Establish the green RxJS 7 baseline\n\nRun the agreed build, type, lint, unit, integration, and behavior checks against\nthe unchanged RxJS 7 project. Record exact commands, environment facts, exit\ncodes, and concise results.\n\nAdd focused characterization tests where Stage 2 found material gaps. Protect\nobservable values, completion/error behavior, producer multiplicity,\ncancellation, abort reasons, teardown ordering, timing, and externally visible\nsubscription effects as applicable. Every characterization test must pass on\nRxJS 7 before migration begins.\n\nPause if a starting gate fails. Diagnose it and ask the developer whether to\nfix it first, narrow scope, or record it as an accepted pre-existing failure.\nNever silently reclassify it as a migration regression or ignore it.\n\nExit only with a green baseline or explicit approval for each named\npre-existing failure, plus green characterization tests.\n\n## Stage 4: Classify and approve the target contract\n\nDivide the scope into stable migration units. For each unit, record one target\nlifecycle using the values accepted by the installed manifest schema and one\nevidence classification. Use repository evidence and\n[references/assessment-and-contract.md](references/assessment-and-contract.md)\nto explain the choice.\n\nThe engine may identify risk but cannot choose lifecycle intent. `unresolved`\nis a stop state. Pause for the developer when either platform-shared behavior\nor producer-per-direct-subscription behavior is plausible, or when Subject\nsemantics, cancellation, scheduler ordering, error behavior, interop, or a\npublic behavior change is not proved.\n\nIntentional divergences require a concrete old claim, proposed Next claim,\nuser impact, evidence, and developer approval. Validate the manifest\nstructurally, then run the installed readiness assessment. Do not proceed with\na batch containing unresolved intent or required pending approval.\n\nExit only when the developer has approved every ambiguous choice and\nintentional divergence needed for the next batch.\n\n## Stage 5: Plan and dry-run bounded engine changes\n\nInspect the installed capability registry and select only entries whose\nversion, source form, arity, preconditions, and executable evidence match the\napproved unit. Do not infer support from a familiar name. Follow\n[references/engine-and-batches.md](references/engine-and-batches.md).\nWhen the batch contains RxJS 7 marble tests, also read\n[references/test-migration.md](references/test-migration.md).\n\nRun `rxjs-migrate` without `--write` using explicit provenance and, when\nrequired, the approved `cold` or `platform` mode. Preserve the current test\nframework unless a supported adapter was separately selected. Capture the\nversioned JSON report, changed paths, structured diagnostics, and exit code.\n\nPause when a diagnostic requires review or refuses a transform, when output\nwould escape authorized paths, when source does not match the capability\nevidence, or when batch size or semantic reach exceeds the reviewed scope.\nNever conceal unsupported segments inside a partially transformed pipeline.\n\nExit only after diagnostics and changed-file scope are reviewed and the\ndeveloper has approved any newly broadened batch.\n\n## Stage 6: Apply one small migration batch\n\nApply only the reviewed dry-run plan. Require an explicit write destination\ninside the authorized project and preserve source provenance. Do not overwrite\nexisting output without specific approval. Review the resulting diff before\nadditional edits.\n\nFormat through the project's normal tools. Ensure ordinary project-owned\nsource and direct test declarations remain; do not leave dynamic generators,\nhidden case registries, or compatibility assertion layers in the result.\n\nImmediately check parsing, the narrowest useful type boundary, and engine\nidempotence. Re-running the same transform must produce no new source change\nand stable diagnostics. If it does not, restore the affected batch to the\nreviewed starting point and report an engine defect.\n\nExit only when the batch parses, type-checks at its narrow boundary, is\nidempotent, and every diagnostic is resolved, carried forward, or escalated.\n\n## Stage 7: Build, test, diagnose, and repair\n\nRun focused characterization and migrated tests first, then the agreed project\ngates. Classify every failure as a migration defect, RxJS Next product gap,\nintentional divergence, environment/baseline issue, or still-unknown result.\nUse [references/verification-and-closeout.md](references/verification-and-closeout.md)\nfor the repair rules.\n\nRepair migration defects in a small batch and repeat the relevant gates. For a\nproduct gap, preserve the failing evidence and report it; do not disguise it\nwith a local replacement. For an intentional divergence, change an expectation\nonly after the manifest records approved new behavior and user impact.\n\nPause before any repair that changes public behavior, weakens evidence,\nexpands writes, changes dependencies beyond the reviewed plan, needs external\naccess, or introduces a compatibility layer.\n\nExit only when agreed gates pass or each remaining red result has a named,\nevidenced, explicitly accepted blocker.\n\n## Stage 8: Close out and hand off\n\nUpdate the contract manifest and report with exact source and target versions,\nengine version, capability-registry version, canonical Skill digest, baseline,\nunits, diagnostics, divergences, final commands/results, and blockers. Validate\nthe manifest with the installed schema and assess readiness separately.\n\nReview [references/review-checklist.md](references/review-checklist.md). Report:\n\n1. what behavior and lifecycle contract changed;\n2. what source and tests changed;\n3. the exact gates run and their results;\n4. migration defects repaired versus product gaps retained;\n5. approved divergences and environment limitations; and\n6. remaining blockers, owners, evidence, and acceptance.\n\nClaim completion only when readiness is `ready`, or\n`ready-with-accepted-blockers` when the developer intentionally chose that\noutcome. Otherwise hand off the migration as incomplete with the next concrete\ndecision or action.\n","frontmatter":{"name":"rxjs-next-migration","description":"Migrate an RxJS 7 application, library, or test suite to RxJS Next through an agent-led workflow that establishes a green behavioral baseline, makes Observable lifecycle choices explicit, uses @rxjs/migrate only for bounded fixture-proved rewrites, repairs without weakening evidence, and records a versioned migration contract. Use for repository assessment, migration planning or execution, lifecycle review, TestScheduler conversion, or migration closeout."},"isInternal":false,"tokens":2167,"sizeBytes":11009},{"name":"MIGRATION_QUALIFICATION.md","path":"packages/migrate/docs/MIGRATION_QUALIFICATION.md","rawUrl":"https://raw.githubusercontent.com/ReactiveX/rxjs/HEAD/packages/migrate/docs/MIGRATION_QUALIFICATION.md","title":"Docs Skill","category":"anthropic-skill","format":"markdown","content":"# RxJS Next migration workflow qualification\n\n## Status\n\nP0.M5 is complete. All four checked-in Codex/ChatGPT runs pass the pinned seed,\nbehavior, authority, artifact, and semantic outcome gates: three end in an\napproved completed migration and the weak-coverage/unsupported repository ends\nin its required safe stop. Per D-047, this P0 qualification is intentionally\nlimited to Codex/ChatGPT. It does not claim Claude Code or Cursor outcome\nqualification, cross-harness parity, or general automatic migration safety.\n\nP5.2 is also complete by closure audit. Its planned mechanical and semantic\napplication-validation outcome was already satisfied by the P0.M3 deterministic\nfixtures, P4.4 accepted contract fixtures, and P0.M5 four-repository outcome\nmatrix. The closure audit reruns those offline gates and maps them to the\npackage-local migration guide; it does not spend another live-model cycle or\nexpand the original qualification claim.\n\n## P5.2 guide-to-evidence map\n\n| Migration-guide step | Representative evidence |\n| --------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Establish a green RxJS 7 baseline | Four pinned seed repositories, framework-specific baseline commands, immutable dependency descriptors, and executable seed oracles |\n| Inventory affected surfaces and coverage gaps | Application/library scenarios spanning Vitest, Mocha, Jest, strong and weak coverage, scheduler, interop, Subject, sharing, and repeated-subscription behavior |\n| Select an explicit lifecycle contract | Cold-preserving, platform-shared, mixed, and unsupported contract manifests with developer-owned decision vectors |\n| Apply only proven mechanical changes | Versioned capability registry, exact transform fixtures, compilation, idempotence, structured diagnostics, and refusal-safe batch writes |\n| Review semantic boundaries | Held-out producer multiplicity, sharing/ref counting, cancellation, teardown, timing, errors, input conversion, Subject state, and restart assertions |\n| Finish green or stop safely | Three completed migrations pass target build and protected behavior; the weak unsupported repository stops before target installation or migration writes |\n\nThe checked-in P4.4 contract fixtures provide a smaller executable cross-check\nfor all four guide outcomes: `cold-preserving`, `platform-shared`,\n`subject-hot`, and `safe-stop`. A lifecycle-swap negative control prevents a\nsyntactically valid rewrite from being counted as a semantic success.\n\n## Evidence boundary\n\nThe qualification has two distinct lanes:\n\n- deterministic engine fixtures prove exact transforms, structured refusals,\n compilation, idempotence, behavior, path containment, and package contracts;\n- agent scenarios permit source variation but require the same behavioral,\n approval, diagnostic, test-integrity, and artifact gates.\n\nA passing engine fixture is not a passing agent migration. A plausible agent\nreport is not a passing run until its seed identity, chronology, commands,\nmanifest, protected tests, held-out behavior, and captured artifact digests\npass the offline grader.\n\nEach committed record has five hashed artifacts: the exact user prompt and\nfinal response retained as `conversation.md`, the contract manifest, patch,\ncommand results, and final report. The command-results artifact, patch, and\nrecorded observed-authority actions provide the reviewable command/tool\nevidence. Full host event streams were not retained for the first three runs,\nso the conversation artifact must not be described as a complete tool-call\ntranscript. The fourth run was repeated after authority controls were tightened;\nonly its passing record belongs to the closed matrix.\n\n## Representative repositories\n\nThe four immutable seed trees live under\n`packages/migrate/test/agent/fixtures`. Each pins RxJS `7.8.1`, its dependency\ndescriptor, a complete pnpm lockfile, runnable framework-specific baseline\ncommands, and the complete seed-tree digest.\n\n| Scenario | Layout | Framework | Coverage | Target contract | Expected result |\n| -------------------------- | ----------- | --------- | -------- | ----------------------------- | --------------- |\n| `app-cold-strong` | Application | Vitest | Strong | Preserve direct cold behavior | Complete |\n| `app-platform-strong` | Application | Mocha | Strong | Intentional platform sharing | Complete |\n| `library-mixed-strong` | Library | Jest | Strong | Mixed approved contracts | Complete |\n| `library-weak-unsupported` | Library | Vitest | Weak | Unsupported behavior retained | Safe stop |\n\nTogether they cover positive evidence plus a negative or refusal control for:\n\n- `ColdObservable` producer independence;\n- platform activation, sharing, ref counting, final abort, and restart;\n- Subjects and late observers;\n- cancellation and abort ownership;\n- teardown order;\n- scheduling and timing;\n- error delivery;\n- iterable, async iterable, Promise, custom-subscribable, and legacy interop;\n- repeated subscriptions and cache behavior;\n- unsupported APIs;\n- missing coverage; and\n- mixed supported and unsupported pipelines.\n\nThe held-out baseline suite loads the exact RxJS `7.8.1` runtime from the\nworkspace's pinned pnpm store path rather than resolving the workspace RxJS\nNext package.\n\n## Outcome gates\n\nThe versioned agent grader evaluates 14 semantic gate families and fails a run\nwhen any family fails:\n\n1. compilation;\n2. RxJS 7 baseline integrity;\n3. baseline/characterization/migration chronology;\n4. contract-manifest readiness;\n5. required diagnostic handling;\n6. intentional-divergence disclosure and approval;\n7. protected-test integrity;\n8. required engine actions and refusals;\n9. implemented/declared manifest consistency;\n10. required artifact integrity;\n11. held-out behavior;\n12. developer-owned contract decisions;\n13. observed read, write, command, network, and install authority; and\n14. timely safe-stop behavior without later writes.\n\nThe captured-record verifier independently recomputes artifact hashes, rejects\npath escape and symlinks, checks harness/model/authority and seed identities,\nand requires the closed four-run Codex matrix. It compares semantic safety and\ndecision vectors rather than exact patches.\n\n## Live qualification matrix\n\nThe closed matrix contains one passing record for each representative\nrepository, for four qualified Codex/ChatGPT outcomes. Claude Code and Cursor\nretain tested Skill installation adapters from P0.M4 but are not live\noutcome-qualified in P0:\n\n| Scenario | Codex/ChatGPT |\n| -------------------------- | :-----------: |\n| `app-cold-strong` | ✓ |\n| `app-platform-strong` | ✓ |\n| `library-mixed-strong` | ✓ |\n| `library-weak-unsupported` | ✓ |\n\nEach run captures the user-visible prompt/final response, patch, contract\nmanifest, command results, and final report. The live command is intentionally\nnot part of ordinary CI because it invokes an external model service. Offline\ngrading of committed run artifacts is deterministic and belongs in normal\nvalidation.\n\n## Current measured result\n\nThe completed evidence passes:\n\n- 4/4 seed identities and dependency descriptors;\n- 12/12 required behavior categories with positive and negative/refusal\n controls;\n- 4/4 pinned RxJS 7 seed oracles;\n- 14/14 agent outcome gate families; and\n- four committed qualification records with 20/20 SHA-256-bound artifacts,\n plus mutation controls for digest drift, missing artifacts, and unexpected\n matrix membership.\n\nLive result: **4/4 passed** using Codex `0.146.0-alpha.3.1`,\n`gpt-5.6-sol` with medium reasoning, and Skill/engine version\n`8.0.0-alpha.14`. `app-cold-strong`, `app-platform-strong`, and\n`library-mixed-strong` completed their approved migrations;\n`library-weak-unsupported` produced the expected safe stop before target\ninstallation or migration writes.\n\n## Claim limits\n\nThis 4/4 result is a bounded qualification snapshot, not a statistical\nreliability estimate and not proof that arbitrary RxJS 7 repositories migrate\nautomatically. It supports claims only for the checked-in scenarios, versions,\ncapabilities, safety gates, retained artifacts, and recorded Codex/ChatGPT\nconfiguration. Claude Code and Cursor outcome parity remains unmeasured.\nUnsupported syntax, uncharacterized behavior, unresolved lifecycle intent,\nframework features outside the adapters, and product gaps must remain visible\nand may require a safe stop.\n","isInternal":false,"tokens":1751,"sizeBytes":9046},{"name":"MIGRATION_TOOLING_DESIGN.md","path":"packages/migrate/docs/MIGRATION_TOOLING_DESIGN.md","rawUrl":"https://raw.githubusercontent.com/ReactiveX/rxjs/HEAD/packages/migrate/docs/MIGRATION_TOOLING_DESIGN.md","title":"Docs Skill","category":"anthropic-skill","format":"markdown","content":"# RxJS Next agent-first migration tooling design\n\n## Executive summary\n\nRxJS 7-to-Next migration is an agent-led engineering workflow, not a codemod\nrun. The primary product is one portable Agent Skill that assesses a project,\nestablishes an RxJS 7 behavioral baseline, makes every lifecycle choice\nexplicit, invokes deterministic transforms only inside their proved boundary,\nand works with the developer until the agreed build and test gates pass or a\ndocumented blocker is accepted.\n\n`@rxjs/migrate` is the deterministic engine used by that workflow. It owns\nversioned analysis, capability data, source transforms, framework adapters,\nstructured diagnostics, and safe file operations. It never decides whether an\napplication should adopt the platform Observable's shared active producer or\nretain producer-per-direct-subscription behavior. It also never claims that a\nsyntactically transformed project is migrated.\n\nThe canonical Skill source is `packages/migrate/skill`. It is released and\nversioned with `@rxjs/migrate`. Harness-specific installation places the same\nvalidated Skill content where Codex, Claude, or Cursor discovers it; those\nplacements and their invocation/permission notes are adapters, not separately\nauthored workflows.\n\nThe current source-content MCP prototype is not part of the accepted product.\nIts two tools mirror the local library and CLI without adding a capability\nthat a local coding agent needs. P0.M3 removes that release surface. A future\nMCP requires a new decision backed by a concrete need that cannot be met by\nthe versioned CLI, library API, Skill resources, or the host agent's local\ntools.\n\n## Status and audience\n\nThis document is the controlling product and technical design for P0.M3\nthrough P0.M5. Its primary audience is RxJS maintainers implementing and\nqualifying the migration experience. Skill authors, framework-adapter authors,\nand release reviewers are secondary audiences.\n\nThe design distinguishes:\n\n- **Accepted product direction:** the contracts in this document and D-046.\n- **Historical prototype:** the P0.M1 `@rxjs/migrate` package and its former\n independently authored Skill/MCP experiments.\n- **Completed P0 evidence:** implementation fixtures in P0.M3, three-harness\n installation/discovery checks in P0.M4, and Codex/ChatGPT representative\n repository evaluations in P0.M5.\n\nNo statement here turns the current prototype's nine tests into general\nmigration evidence or promises that every RxJS 7 application can be migrated\nautomatically.\n\n## Product principles\n\n1. **Behavior before syntax.** A passing RxJS 7 baseline and explicit target\n contract precede broad source rewriting.\n2. **No silent lifecycle choice.** The agent must not infer platform sharing\n or producer-per-direct-subscription behavior from an operator name,\n directory, or currently passing output.\n3. **Mechanical work stays bounded.** The engine transforms only versioned,\n fixture-proved syntax and reports everything else.\n4. **The destination owns the result.** Migrated code and characterization\n tests become ordinary project source, not generated runtime artifacts.\n5. **Outcome gates outrank source shape.** Agent changes may vary in form; the\n declared contract, compilation, tests, diagnostics, and intentional\n divergences must not vary.\n6. **One workflow, thin harness adapters.** Codex, Claude, and Cursor use the\n same Skill body and validation assets.\n7. **Human authority is explicit.** Ambiguous intent, weakened coverage,\n unsupported behavior, and accepted divergences require a developer\n decision.\n\n## Developer job and paved road\n\n### Persona and job to be done\n\nThe primary user is an application or library maintainer responsible for an\nRxJS 7 codebase. They need to reach an intentional RxJS Next contract without\nlosing behavior that the existing test suite did not happen to cover.\n\nThe paved road begins with a working repository and ends with:\n\n- the agreed build, type, lint, and test gates passing;\n- a checked-in target-contract manifest;\n- reviewed diagnostics and intentional divergences;\n- ordinary project-owned migrated source and tests; and\n- a remaining-blocker record when the developer deliberately accepts work\n that cannot yet be completed.\n\n### Journey and gates\n\n#### 1. Discover and establish authority\n\nThe agent locates repository instructions, package-manager metadata, RxJS\nversions, workspaces, build/test commands, CI configuration, and the current\nworking-tree state. It states the files and commands it proposes to use before\nwriting broadly.\n\nEntry gate:\n\n- the repository is accessible and its local instructions are known.\n\nExit gate:\n\n- the migration scope, allowed writes, package manager, and candidate\n verification commands are recorded.\n\nThe agent must stop if it cannot distinguish the intended repository, cannot\nprotect existing changes, or needs authority for destructive or external\nactions.\n\n#### 2. Assess versions, usage, and coverage\n\nThe agent inventories:\n\n- installed RxJS versions and import forms;\n- Observable construction, custom producers, Subjects, subscriptions,\n schedulers, testing utilities, interop inputs, and repeated subscriptions;\n- direct and transitive operator usage;\n- test frameworks and coverage around lifecycle-sensitive paths; and\n- build/type/test commands that currently exercise those paths.\n\nThe result is a risk report, not a transform plan. Every finding links to\nsource evidence and one or more migration themes.\n\nExit gate:\n\n- every in-scope lifecycle-sensitive use is either covered by an existing\n baseline, selected for characterization, explicitly unsupported, or accepted\n by the developer as an uncovered risk.\n\n#### 3. Establish the RxJS 7 baseline\n\nThe agent runs the agreed checks before changing dependencies or source. A\nfailing starting gate is diagnosed and recorded; it is never silently treated\nas a migration regression.\n\nWhen existing coverage is insufficient, the agent proposes focused\ncharacterization tests against RxJS 7. These tests protect observable values,\nterminal behavior, producer multiplicity, cancellation, teardown ordering,\ntiming, errors, and subscription effects relevant to the selected code.\n\nExit gate:\n\n- agreed baseline commands pass on RxJS 7, or the developer explicitly accepts\n named pre-existing failures; and\n- every newly added characterization test passes before migration begins.\n\n#### 4. Classify the intended Next contract\n\nThe agent creates or updates the target-contract manifest described below.\nEach migration unit receives one target lifecycle and one evidence\nclassification. `unresolved` is a stop state, not a default the transformer may\nresolve.\n\nExit gate:\n\n- the developer has approved every ambiguous lifecycle choice and intentional\n divergence needed for the current batch.\n\n#### 5. Plan and dry-run mechanical changes\n\nThe agent selects only engine capabilities whose versioned evidence matches\nthe source form and approved contract. It runs analysis and transforms without\nwrites first, then presents changed-file scope and structured diagnostics.\n\nExit gate:\n\n- no unresolved or refusal diagnostic is hidden;\n- the proposed output stays within authorized paths; and\n- the developer has approved any batch whose size or semantic reach exceeds\n the previously reviewed scope.\n\n#### 6. Apply a small migration batch\n\nThe agent applies one coherent batch, formats it through the project's normal\ntools, and keeps migrated files as ordinary source. It does not add a runtime\ngenerator, compatibility assertion layer, or unreviewed local operator to make\nthe batch pass.\n\nExit gate:\n\n- the batch parses and type-checks at the narrowest useful boundary;\n- deterministic transforms are idempotent; and\n- all diagnostics are resolved, carried forward, or escalated.\n\n#### 7. Build, test, diagnose, and repair\n\nThe agent runs the narrowest relevant checks, then the agreed project gates.\nIt separates:\n\n- migration defects, which it repairs;\n- RxJS Next product gaps, which it reports without disguising;\n- intentional divergences, which require approved expectations; and\n- environment or baseline failures, which retain their original status.\n\nThe loop continues in reviewable batches until green or until the developer\naccepts a documented blocker. Tests may be strengthened but never weakened\nmerely to obtain green output.\n\n#### 8. Close out and hand off\n\nThe agent records final commands and results, changed contracts, unsupported\nbehavior, intentional divergences, remaining blockers, and the installed Skill\nand engine versions. A migration is not complete while required gates are\nunknown, skipped without approval, or red for an unexplained reason.\n\n## Target-contract protocol\n\n### Separate lifecycle from evidence classification\n\nEvery migration unit records both fields. They answer different questions.\n\nTarget lifecycle:\n\n| Value | Meaning |\n| ---------------------------------- | ---------------------------------------------------------------------------------------------- |\n| `platform-shared` | Use the active platform Observable with one shared, ref-counted producer while observers exist |\n| `producer-per-direct-subscription` | Use an explicit Next API such as `ColdObservable` that creates producer work per direct call |\n| `subject-hot` | Use an intentional Subject API whose producer exists before observers subscribe |\n| `not-applicable` | The unit has no Observable producer lifecycle |\n| `unsupported` | The accepted Next surface does not provide the required behavior |\n| `unresolved` | Developer intent or product policy is unknown; the agent must stop |\n\nEvidence classification uses the compatibility policy's existing values:\n`portable`, `harness-rewrite`, `compatibility-only`,\n`intentional-divergence`, or `unsupported-or-obsolete`.\n\nThe engine may suggest review flags but cannot promote `unresolved` to a\ntarget lifecycle or approve an intentional divergence.\n\n### Contract manifest\n\nThe checked-in manifest is structured data with a human-readable summary. Its\nschema is versioned with `@rxjs/migrate` and contains at least:\n\n| Field | Required content |\n| ------------------------ | ----------------------------------------------------------------------------------------- |\n| `schemaVersion` | Exact manifest schema |\n| `engineVersion` | `@rxjs/migrate` version used for analysis and transforms |\n| `skillDigest` | Digest of the canonical Skill content |\n| `sourceRxjsVersion` | Exact RxJS 7 version or range observed in the project |\n| `targetRxjsVersion` | Exact RxJS Next version under evaluation |\n| `baseline` | Commands, environment, result, and accepted pre-existing failures |\n| `units` | Stable IDs, source locations, lifecycle, evidence class, claims, and approval state |\n| `diagnostics` | Structured unresolved, refused, unsupported, and informational findings |\n| `intentionalDivergences` | Old claim, approved Next claim, user impact, evidence, and developer approval |\n| `verification` | Required commands and final results |\n| `blockers` | Owner, reason, affected units, evidence, and explicit acceptance when work ends non-green |\n\nThe manifest records decisions and evidence; it is not an input that can\noverride the engine's safe path or capability checks.\n\n### Mandatory escalation cases\n\nThe agent pauses for the developer when:\n\n- repeated subscriptions could mean independent work, refresh/retry behavior,\n sharing, or caching and intent is not proved;\n- source behavior could reasonably map to either the platform Observable or\n `ColdObservable`;\n- a Subject's replay, terminal, or late-observer behavior is not covered;\n- the change would remove or reinterpret scheduler-sensitive ordering;\n- teardown order, abort reason, or unhandled-error behavior could change;\n- a custom subscribable or interop protocol is outside `Observable.from`;\n- a transform would drop an unsupported overload or assertion;\n- existing tests are missing or failing in the affected area;\n- a proposed repair weakens an expectation or changes public behavior; or\n- completing the work requires broader writes, dependency changes, network\n access, or destructive action beyond the approved scope.\n\n## Product boundaries\n\n### Portable Agent Skill\n\nThe Skill is the primary user experience. It owns:\n\n- journey orchestration and stop conditions;\n- repository and coverage assessment;\n- target-contract elicitation and manifest maintenance;\n- choosing when a deterministic engine operation is allowed;\n- review batching and repair-loop behavior;\n- classification of migration, product, environment, and intentional\n divergence outcomes; and\n- final evidence and blocker reporting.\n\nIt does not copy mutable capability mappings into prose. It consumes the\ninstalled engine's machine-readable capability and schema outputs.\n\n### `@rxjs/migrate`\n\nThe package owns deterministic, versioned behavior:\n\n- parse and usage analysis;\n- capability and argument-adapter data;\n- source and test transforms;\n- optional test-framework syntax adapters;\n- structured findings and refusal diagnostics;\n- contract-manifest schema validation;\n- dry-run/write equivalence and safe path containment; and\n- Skill installation, synchronization, and content verification.\n\nThe package does not own:\n\n- target-lifecycle decisions;\n- approval of intentional divergences;\n- general code repair;\n- repository-wide test strategy;\n- claims beyond its executable fixtures; or\n- completion of an end-to-end migration.\n\n### CLI and library API\n\nThe CLI and library are two interfaces to the same engine. Given the same\nsource, options, capability version, and framework adapter, they return the\nsame changed content and structured diagnostics. The CLI is dry-run-first and\nmachine-readable; writes require an explicit flag and contained destination.\n\n### Framework adapters\n\nFramework adapters translate only framework syntax and configuration they\nexplicitly support. They do not select an Observable lifecycle, change RxJS\nsemantics, or add assertion compatibility layers. Preserving the project's\ncurrent framework remains the default.\n\n### MCP decision\n\nNo MCP server is in the accepted release architecture. The P0.M1 prototype\naccepts source text and returns the same analysis or transform available from\nthe local API. That indirection does not justify a second versioned protocol,\nruntime dependencies, installation path, permission model, or validation\nmatrix.\n\nA future proposal must identify at least one necessary capability that cannot\nbe provided adequately by the CLI, library, Skill resources, or host agent\ntools. It must then define separate authentication, authority, privacy,\nversioning, offline, error, and evaluation contracts. Convenience or protocol\nsymmetry alone is insufficient.\n\n## Canonical Skill and distribution\n\n### One authored source\n\n`packages/migrate/skill` is the only authored Skill source. Its content digest\nis included in the package and contract manifest. The Skill and engine share\nthe package version so instructions cannot silently describe a different\ncapability registry or schema.\n\nThe earlier `.agents/skills/rxjs-next-marble-migration` tree remains valuable\nP0.T2 history in Git, but it is no longer a second authored source. P0.M4\nmerged its still-valid guidance into the canonical Skill and replaced it with\nthe validated `.agents/skills/rxjs-next-migration` generated copy.\n\n### Installation model\n\nProjects add an exact or intentionally ranged development dependency on\n`@rxjs/migrate`. A package command then installs or synchronizes the canonical\nSkill into the selected harness discovery location and writes a small\nprovenance record containing package name, version, content digest, and target\npath. Installed copies are generated distribution artifacts; maintainers edit\nonly `packages/migrate/skill`.\n\nThe installer must support check-only, install, update, and remove operations;\nmust refuse to overwrite a locally modified target without explicit approval;\nand must work without symlink privileges. A symlink may be offered when the\nharness and platform support it, but it is not the only path.\n\n### Harness adapters\n\nThe `rxjs-migrate-skill` command implements the required behavior:\n\n| Harness | Discovery target | Invocation | Adapter responsibility |\n| ------- | --------------------------------------------- | ---------------------------------------------- | --------------------------------------------------------------------------------------- |\n| Codex | `.agents/skills/rxjs-next-migration/SKILL.md` | `$rxjs-next-migration` or implicit description | Install/sync the canonical bytes; document sandbox and approval settings |\n| Claude | `.claude/skills/rxjs-next-migration/SKILL.md` | `/rxjs-next-migration` or implicit description | Install/sync the canonical bytes; omit Claude-only frontmatter from the portable source |\n| Cursor | `.agents/skills/rxjs-next-migration/SKILL.md` | `/rxjs-next-migration` or implicit description | Use the open Skill path; verify editor and CLI discovery |\n\nIf a harness requires metadata not in the open Agent Skills format, the\nadapter stores that metadata beside the installed Skill. It must not fork the\nworkflow body.\n\n### Permissions\n\nThe portable Skill declares workflow needs, not blanket authority. A host\nadapter documents how to grant:\n\n- read access to the selected repository;\n- write access only to the reviewed project paths;\n- local execution of the project's declared package-manager, build, and test\n commands; and\n- network or package-install access only when the developer approves it.\n\nThe workflow never needs production credentials or project-level MCP write\nauthority. Destructive actions and external publication remain outside the\ndefault migration permission set.\n\n### Updates and discovery verification\n\nUpdating means updating `@rxjs/migrate`, running Skill synchronization, and\nchecking that the installed digest matches the package. Each harness smoke\ntest must prove:\n\n1. the Skill is discovered from a clean fixture;\n2. explicit invocation reaches the canonical workflow;\n3. an implicit trigger is recognized when enabled;\n4. required local tools are requested rather than assumed; and\n5. a stale or locally modified installed copy is reported clearly.\n\nP0.M4 rechecked the official references on 2026-07-31 and records the exact\ncommands, permissions, update flow, smoke scenario, and locally inspected host\nversions in `MIGRATION_SKILL_GUIDE.md`. Harness discovery and permission\nbehavior can change independently of RxJS and must be rechecked before release.\n\n## Fixture and evaluation specification\n\n### Two evidence lanes\n\nDeterministic engine behavior and nondeterministic agent outcomes use separate\nfixtures and gates.\n\n```mermaid\nflowchart LR\n Source[\"Pinned RxJS 7 source\"] --> Mechanical[\"Deterministic engine fixtures\"]\n Mechanical --> Output[\"Content, diagnostics, compile, idempotence, behavior\"]\n Source --> Agent[\"Agent workflow evaluation\"]\n Agent --> Contract[\"Contract manifest and reviewed changes\"]\n Contract --> Gates[\"Build, type, lint, tests, divergences, blockers\"]\n```\n\nAn exact golden file can prove deterministic output. It cannot prove an agent\nmade the correct lifecycle choice. Conversely, a green end-to-end repository\ndoes not prove every codemod branch is deterministic or path-safe.\n\n### Mechanical fixture schema\n\nEvery engine fixture records:\n\n- stable fixture ID and behavior category;\n- exact input files and parser/compiler options;\n- source RxJS and target Next versions;\n- migration mode and capability-registry version;\n- framework adapter and options;\n- expected changed paths;\n- exact output where formatting is contractual, otherwise explicit structural\n invariants;\n- ordered diagnostics with classification, severity, source span, and\n suggested next action;\n- expected parse and type results;\n- idempotence expectation; and\n- executable pre- and post-migration behavioral claims.\n\nSuccessful-fixture gates:\n\n1. input parses in its declared source environment;\n2. output parses and type-checks in the declared target environment;\n3. a second transform produces no change and identical diagnostics;\n4. CLI and API results agree;\n5. dry-run and write modes agree byte-for-byte;\n6. writes remain inside the declared destination;\n7. source behavior passes on RxJS 7;\n8. target behavior passes for the approved Next contract; and\n9. the fixture's diagnostic and output expectations pass.\n\nNegative controls must prove that the gate fails for output drift, a missing\ndiagnostic, a non-idempotent transform, a compile regression, behavior drift,\npath escape, unsupported syntax reported as success, and a CLI/API mismatch.\n\n### Agent evaluation schema\n\nEach agent fixture records:\n\n- stable scenario ID and repository category;\n- pinned repository revision and dependency lock;\n- harness, agent/model configuration, Skill version/digest, and engine version;\n- allowed tools, permissions, network policy, time/task bounds, and clean-room\n setup;\n- starting RxJS 7 commands and results;\n- seeded coverage gaps and expected characterization recommendations;\n- required target-contract units and developer decision points;\n- allowed implementation variation;\n- required diagnostics, refusals, and escalations;\n- intentional divergences and their approval records;\n- final build/type/lint/test gates; and\n- artifact capture for the conversation, manifest, patch, command results, and\n final report.\n\nAgent output is not compared as one golden patch. A run passes only when:\n\n- the baseline is established honestly;\n- required risks and weak coverage are surfaced;\n- the agent does not choose an ambiguous lifecycle automatically;\n- characterization tests pass on RxJS 7 before dependency/source migration;\n- deterministic transforms are used only for supported inputs;\n- no required test is weakened, skipped, or deleted without approval;\n- the final manifest matches the implemented contracts;\n- every agreed gate passes or a named blocker is explicitly accepted; and\n- the final report distinguishes migration defects, product gaps,\n divergences, and environment limits.\n\n### Required behavior categories\n\nMechanical fixtures and agent scenarios collectively cover:\n\n| Category | Required evidence |\n| --------------------------------- | ------------------------------------------------------------------------------------------- |\n| `ColdObservable` | Independent direct subscriptions, duplicated side effects, cancellation, and Symbol results |\n| Platform sharing and ref counting | First activation, late join, individual abort, final abort, restart, and shared state |\n| Subjects | Hot producer, current/replayed values, terminal state, read-only views, and late observers |\n| Cancellation | Captured subscriptions rewritten to signal ownership, abort reasons, and upstream closure |\n| Teardown order | Reverse platform teardown ordering and order-sensitive characterization |\n| Scheduling and timing | Host-time mappings, unsupported scheduler forms, ordering, and virtual-time evidence |\n| Errors | Observer callback errors, late/unhandled errors, selector errors, and terminal preservation |\n| Input conversion | Iterables, async iterables, Promises, custom subscribables, and legacy interop refusal |\n| Repeated subscriptions | Retry, refresh, cache invalidation, producer multiplicity, and restart |\n| Unsupported APIs | Visible diagnostics, retained evidence, no invented compatibility layer |\n| Missing coverage | Characterization recommendation and refusal to claim safety |\n| Mixed pipelines | Supported transforms around unsupported operators without dropping the unsupported segment |\n\nEach category needs at least one passing case and one negative or refusal\ncontrol. P0.M5 expands these units into representative application and library\nrepositories.\n\n## P0.M2 prototype audit\n\nP0.M1 established useful boundaries but not release-grade evidence:\n\n- `packages/migrate/src/index.ts` separates semantic and framework transforms.\n- `packages/migrate/src/cli.ts` is dry-run-first.\n- `packages/migrate/src/types.ts` exposes structured but limited diagnostics.\n- `packages/migrate/skill` contained a thin package Skill.\n- `.agents/skills/rxjs-next-marble-migration` contained the earlier, more\n detailed repository Skill.\n- `packages/migrate/src/mcp.ts` mirrored source-content analysis and migration.\n- the package had nine test registrations and one source fixture;\n the fixture is not a comprehensive executable matrix.\n\nKnown gaps assigned to P0.M3 or P0.M4 include:\n\n- no comprehensive mapping, aliasing, shadowing, malformed-input, compile,\n idempotence, behavior, CLI/API-equivalence, or path-containment fixtures;\n- no versioned target-contract manifest;\n- no agent-first repository assessment or repair loop in the bundled Skill;\n- independently authored Skill content that can drift;\n- no tested install/update/remove flow across the three harnesses; and\n- an MCP surface and dependencies with no accepted release responsibility.\n\nThese are scope facts, not implementation failures against a contract that\nP0.M1 had already claimed.\n\n## Implementation handoff\n\n### P0.M3 — deterministic engine hardening\n\nP0.M3 implements the package-owned pieces of this design:\n\n- machine-readable capability and contract-manifest schemas;\n- structured diagnostics with spans, severity, refusal state, and next action;\n- comprehensive mechanical fixtures and negative controls;\n- parse, compile, idempotence, behavior, CLI/API, dry-run/write, containment,\n import, and pack gates;\n- Skill digest and synchronization primitives needed by P0.M4; and\n- removal of MCP bins, exports, runtime dependencies, tests, and claims.\n\nP0.M3 does not install cross-harness adapters or claim agent workflow\nqualification.\n\n### P0.M4 — portable Skill and harness adapters\n\nP0.M4 merges the reusable P0.T2 guidance into `packages/migrate/skill`, expands\nit to the complete journey, and makes it consume engine data rather than prose\ncopies. It implements and tests installation, discovery, invocation,\npermissions, update, drift, and removal for Codex, Claude, and Cursor.\n\nThe completed implementation ships the `rxjs-migrate-skill` command and\n`@rxjs/migrate/skill` API, copy-only atomic adapters, embedded provenance, and\none shared Codex/Cursor placement plus Claude's native placement. The package\nsuite proves canonical byte identity and safe lifecycle behavior across all\nthree adapters. The repository's generated copy keeps natural Codex and Cursor\ninvocation available after the independently authored P0.T2 tree is removed.\n\n### P0.M5 — representative qualification\n\nP0.M5 evaluates clean pinned repositories across application/library layouts,\nframeworks, coverage levels, lifecycle choices, and unsupported behavior. It\npublishes measured outcomes and limitations rather than a blanket automatic\nmigration claim.\n\nThe live matrix, offline outcome gates, current measured evidence, and claim\nlimits are tracked in\n[`MIGRATION_QUALIFICATION.md`](MIGRATION_QUALIFICATION.md).\nThe completed Codex-only\nmatrix passes 4/4: three approved migrations completed and the\nweak-coverage/unsupported scenario made its required safe stop. Codex\n`0.146.0-alpha.3.1`, `gpt-5.6-sol` at medium reasoning, and Skill/engine\n`8.0.0-alpha.14` are part of the claim boundary. The verifier binds four\nrecords to 20 hashed artifacts and 14 semantic gate families.\n\nThe retained conversation artifact is the exact user prompt plus final\nresponse, not necessarily the complete host event stream. Exact commands and\nresults, file changes, and observed authority are retained separately in the\ncommand-results artifact, patch, and qualification record. Full event streams\nwere not retained for the first three runs. This evidence boundary is explicit\nso a future requalification can strengthen capture without overstating the P0\nrecords.\n\n## Risks and controls\n\n| Risk | Control |\n| ----------------------------------------- | -------------------------------------------------------------------------------------------- |\n| Green output hides a lifecycle change | Baseline, characterization tests, explicit target manifest, and shared/cold fixtures |\n| Capability prose drifts from the engine | Skill consumes versioned machine-readable data and shares the package version |\n| Harness instructions diverge | One canonical Skill digest; generated placements; per-harness smoke tests |\n| Agent weakens tests to finish | Outcome grader rejects unapproved skips, deletions, and weaker expectations |\n| Codemod writes outside scope | Resolve-and-contain checks plus path-escape negative controls |\n| Nondeterminism masks regressions | Judge contracts and outcomes; retain the five declared hashed artifacts and authority record |\n| MCP becomes an unsupported second product | Remove the prototype surface; require a new evidence-backed decision to reintroduce it |\n| Harness behavior changes after release | Re-verify official discovery/permission paths during P0.M4 and before each supported claim |\n\n## Completion criteria for the migration product\n\nThe migration experience is release-ready only when:\n\n- P0.M3 mechanical fixtures prove every documented transform and refusal;\n- P0.M4 uses one canonical Skill and passes all harness discovery and\n permission smoke tests;\n- P0.M5 representative repositories pass their declared outcome gates;\n- any outcome claim names its harness/model boundary and retained evidence;\n- measured limitations and unsupported surfaces are published;\n- no migration is called complete based only on transformed source shape; and\n- no MCP or other secondary orchestration surface is claimed without its own\n accepted contract and evidence.\n\n## References\n\nRepository sources:\n\n- `PROJECT_CHARTER.md`\n- `ARCHITECTURE.md`\n- `DECISIONS.md`\n- `PROJECT_PLAN.md`\n- `COMPATIBILITY.md`\n- `TESTING_DESIGN.md`\n- `packages/migrate`\n- `.agents/skills/rxjs-next-migration`\n\nCurrent harness references reviewed for P0.M2:\n\n- [OpenAI: Build skills](https://learn.chatgpt.com/docs/build-skills)\n- [Claude Code: Extend Claude with skills](https://code.claude.com/docs/en/slash-commands)\n- [Cursor 2.4: Agent Skills](https://cursor.com/changelog/2-4)\n- [Agent Skills open standard](https://agentskills.io)\n","isInternal":false,"tokens":6046,"sizeBytes":32004},{"name":"SKILL.md","path":"packages/migrate/skill/SKILL.md","rawUrl":"https://raw.githubusercontent.com/ReactiveX/rxjs/HEAD/packages/migrate/skill/SKILL.md","title":"rxjs-next-migration","category":"anthropic-skill","format":"markdown","content":"---\nname: rxjs-next-migration\ndescription: Migrate an RxJS 7 application, library, or test suite to RxJS Next through an agent-led workflow that establishes a green behavioral baseline, makes Observable lifecycle choices explicit, uses @rxjs/migrate only for bounded fixture-proved rewrites, repairs without weakening evidence, and records a versioned migration contract. Use for repository assessment, migration planning or execution, lifecycle review, TestScheduler conversion, or migration closeout.\n---\n\n# RxJS 7 to RxJS Next migration\n\nTreat this as reviewed project work, not a codemod run. The objective is an\nintentional RxJS Next contract backed by the project's own build and behavior\nevidence. A transformed file, a clean diff, or one passing test is not proof\nthat the migration is complete.\n\nWork through all eight stages in order. Re-enter an earlier stage whenever new\nevidence changes scope, coverage, or lifecycle intent. Keep the developer\ninvolved at every explicit pause.\n\n## Non-negotiable rules\n\n- Read and obey repository-local instructions before acting. Protect existing\n work and stay within the authorized repository and paths.\n- Establish the RxJS 7 baseline before changing dependencies or source.\n- Never infer platform sharing versus producer-per-direct-subscription behavior\n from syntax, filenames, operator names, or a currently passing output.\n- Use the installed engine's versioned registry and schemas as authority. Do\n not reconstruct capability mappings from this Skill or from memory.\n- Run the deterministic engine without writes first. A refusal is a successful\n safety outcome, not permission to improvise a mechanical rewrite.\n- Preserve the project's test framework by default. Select a framework adapter\n only when the developer asked for that separate conversion.\n- Do not weaken, skip, delete, or replace a behavioral expectation merely to\n make the migrated suite green.\n- Do not add RxJS 7 compatibility shims, string-named platform methods, local\n substitute operators, or runtime generators unless the developer separately\n authorizes that product work.\n- Keep changes in small coherent batches. Review and verify each batch before\n widening the scope.\n- Do not call a migration complete while a required command is unknown,\n unapproved, skipped, or red without an explicitly accepted blocker.\n\n## Working record\n\nCreate or locate a checked-in migration contract manifest and a concise\nhuman-readable report. Use the schema exported by the installed\n`@rxjs/migrate`; schema validity and migration readiness are separate checks.\nUse [assets/migration-report.md](assets/migration-report.md) for the report.\n\nFor every migration unit, preserve source locations and record:\n\n- its current RxJS 7 behavioral claim;\n- the target lifecycle selected by the developer;\n- its evidence classification and supporting tests;\n- approval state, diagnostics, and any intentional divergence; and\n- verification or a named blocker.\n\n## Stage 1: Establish authority and scope\n\n1. Locate repository instructions, package and workspace metadata, lockfiles,\n CI configuration, RxJS versions, build/test commands, and current working\n tree state.\n2. Identify the repository root, migration boundary, permitted writes,\n package manager, network policy, and candidate verification commands.\n3. Record the installed `@rxjs/migrate` version and canonical Skill digest.\n If the installed Skill does not match its package, stop and synchronize it\n before trusting these instructions.\n4. State the proposed read, write, dependency, and command scope before broad\n changes.\n\nPause for the developer if the target repository or allowed scope is unclear,\nexisting changes overlap the migration, or destructive, networked, external,\nor broader actions require new authority.\n\nExit only when the scope, allowed writes, package manager, and candidate gates\nare recorded.\n\n## Stage 2: Assess usage, lifecycle risk, and coverage\n\nInventory installed RxJS versions and import forms, then locate Observable\nconstruction, custom producers, Subjects, subscription ownership, repeated\nsubscriptions, retry/refresh/cache paths, schedulers and timing, test helpers,\ninterop inputs, cancellation, teardown, and error handling. Include direct and\ntransitive operator usage.\n\nFor each lifecycle-sensitive path, link exact source evidence and mark it as:\n\n- covered by an existing baseline;\n- requiring a characterization test;\n- explicitly unsupported; or\n- an uncovered risk the developer accepts.\n\nProduce a risk and coverage report before proposing rewrites. Read\n[references/assessment-and-contract.md](references/assessment-and-contract.md)\nfor the inventory and characterization protocol.\n\nExit only when every in-scope lifecycle-sensitive use has one recorded\ncoverage disposition. Missing coverage is not evidence that behavior is safe.\n\n## Stage 3: Establish the green RxJS 7 baseline\n\nRun the agreed build, type, lint, unit, integration, and behavior checks against\nthe unchanged RxJS 7 project. Record exact commands, environment facts, exit\ncodes, and concise results.\n\nAdd focused characterization tests where Stage 2 found material gaps. Protect\nobservable values, completion/error behavior, producer multiplicity,\ncancellation, abort reasons, teardown ordering, timing, and externally visible\nsubscription effects as applicable. Every characterization test must pass on\nRxJS 7 before migration begins.\n\nPause if a starting gate fails. Diagnose it and ask the developer whether to\nfix it first, narrow scope, or record it as an accepted pre-existing failure.\nNever silently reclassify it as a migration regression or ignore it.\n\nExit only with a green baseline or explicit approval for each named\npre-existing failure, plus green characterization tests.\n\n## Stage 4: Classify and approve the target contract\n\nDivide the scope into stable migration units. For each unit, record one target\nlifecycle using the values accepted by the installed manifest schema and one\nevidence classification. Use repository evidence and\n[references/assessment-and-contract.md](references/assessment-and-contract.md)\nto explain the choice.\n\nThe engine may identify risk but cannot choose lifecycle intent. `unresolved`\nis a stop state. Pause for the developer when either platform-shared behavior\nor producer-per-direct-subscription behavior is plausible, or when Subject\nsemantics, cancellation, scheduler ordering, error behavior, interop, or a\npublic behavior change is not proved.\n\nIntentional divergences require a concrete old claim, proposed Next claim,\nuser impact, evidence, and developer approval. Validate the manifest\nstructurally, then run the installed readiness assessment. Do not proceed with\na batch containing unresolved intent or required pending approval.\n\nExit only when the developer has approved every ambiguous choice and\nintentional divergence needed for the next batch.\n\n## Stage 5: Plan and dry-run bounded engine changes\n\nInspect the installed capability registry and select only entries whose\nversion, source form, arity, preconditions, and executable evidence match the\napproved unit. Do not infer support from a familiar name. Follow\n[references/engine-and-batches.md](references/engine-and-batches.md).\nWhen the batch contains RxJS 7 marble tests, also read\n[references/test-migration.md](references/test-migration.md).\n\nRun `rxjs-migrate` without `--write` using explicit provenance and, when\nrequired, the approved `cold` or `platform` mode. Preserve the current test\nframework unless a supported adapter was separately selected. Capture the\nversioned JSON report, changed paths, structured diagnostics, and exit code.\n\nPause when a diagnostic requires review or refuses a transform, when output\nwould escape authorized paths, when source does not match the capability\nevidence, or when batch size or semantic reach exceeds the reviewed scope.\nNever conceal unsupported segments inside a partially transformed pipeline.\n\nExit only after diagnostics and changed-file scope are reviewed and the\ndeveloper has approved any newly broadened batch.\n\n## Stage 6: Apply one small migration batch\n\nApply only the reviewed dry-run plan. Require an explicit write destination\ninside the authorized project and preserve source provenance. Do not overwrite\nexisting output without specific approval. Review the resulting diff before\nadditional edits.\n\nFormat through the project's normal tools. Ensure ordinary project-owned\nsource and direct test declarations remain; do not leave dynamic generators,\nhidden case registries, or compatibility assertion layers in the result.\n\nImmediately check parsing, the narrowest useful type boundary, and engine\nidempotence. Re-running the same transform must produce no new source change\nand stable diagnostics. If it does not, restore the affected batch to the\nreviewed starting point and report an engine defect.\n\nExit only when the batch parses, type-checks at its narrow boundary, is\nidempotent, and every diagnostic is resolved, carried forward, or escalated.\n\n## Stage 7: Build, test, diagnose, and repair\n\nRun focused characterization and migrated tests first, then the agreed project\ngates. Classify every failure as a migration defect, RxJS Next product gap,\nintentional divergence, environment/baseline issue, or still-unknown result.\nUse [references/verification-and-closeout.md](references/verification-and-closeout.md)\nfor the repair rules.\n\nRepair migration defects in a small batch and repeat the relevant gates. For a\nproduct gap, preserve the failing evidence and report it; do not disguise it\nwith a local replacement. For an intentional divergence, change an expectation\nonly after the manifest records approved new behavior and user impact.\n\nPause before any repair that changes public behavior, weakens evidence,\nexpands writes, changes dependencies beyond the reviewed plan, needs external\naccess, or introduces a compatibility layer.\n\nExit only when agreed gates pass or each remaining red result has a named,\nevidenced, explicitly accepted blocker.\n\n## Stage 8: Close out and hand off\n\nUpdate the contract manifest and report with exact source and target versions,\nengine version, capability-registry version, canonical Skill digest, baseline,\nunits, diagnostics, divergences, final commands/results, and blockers. Validate\nthe manifest with the installed schema and assess readiness separately.\n\nReview [references/review-checklist.md](references/review-checklist.md). Report:\n\n1. what behavior and lifecycle contract changed;\n2. what source and tests changed;\n3. the exact gates run and their results;\n4. migration defects repaired versus product gaps retained;\n5. approved divergences and environment limitations; and\n6. remaining blockers, owners, evidence, and acceptance.\n\nClaim completion only when readiness is `ready`, or\n`ready-with-accepted-blockers` when the developer intentionally chose that\noutcome. Otherwise hand off the migration as incomplete with the next concrete\ndecision or action.\n","frontmatter":{"name":"rxjs-next-migration","description":"Migrate an RxJS 7 application, library, or test suite to RxJS Next through an agent-led workflow that establishes a green behavioral baseline, makes Observable lifecycle choices explicit, uses @rxjs/migrate only for bounded fixture-proved rewrites, repairs without weakening evidence, and records a versioned migration contract. Use for repository assessment, migration planning or execution, lifecycle review, TestScheduler conversion, or migration closeout."},"isInternal":false,"tokens":2167,"sizeBytes":11009},{"name":"API.md","path":"packages/rxjs/docs/API.md","rawUrl":"https://raw.githubusercontent.com/ReactiveX/rxjs/HEAD/packages/rxjs/docs/API.md","title":"Docs Skill","category":"anthropic-skill","format":"markdown","content":"# RxJS 9 API and import guide\n\nRxJS 9 separates the platform Observable contract from RxJS capabilities.\nImport the root for intentional core primitives and import each operator or\nfactory from its own subpath.\n\n## Root exports\n\n```ts\nimport { AsyncSubject, ColdObservable, ConnectableObservable, Subject, behaviorSubject, connectable, replaySubject } from 'rxjs';\n```\n\nThe root also exports notifications and public errors, including\n`Notification`, `TimeoutError`, `EmptyError`, `NotFoundError`,\n`SequenceError`, and `ArgumentOutOfRangeError`. Advanced code can extend\n`PerSubscriptionSubjectBase` when it needs observer-local setup without\nclaiming that a Subject is cold.\n\nImporting `rxjs` conditionally initializes the platform Observable surface. It\ndoes not install every RxJS operator.\n\n## Symbol operators\n\n```ts\nimport 'rxjs';\nimport { filter } from 'rxjs/filter';\nimport { map } from 'rxjs/map';\nimport { switchMap } from 'rxjs/switch-map';\n\nconst result = source[filter]((value) => value.active)[map]((value) => value.id);\n```\n\nEvery public operator is a module-owned exact Symbol. Two independently\nevaluated copies intentionally have different Symbol identities, allowing\nversion-skewed capabilities to coexist without overwriting one another.\n\nWhen a platform string method has the same descriptive name, both forms\nremain available:\n\n```ts\nobservable.map(project); // platform contract\nobservable[map](project); // RxJS contract\n```\n\nThe RxJS import never replaces the platform string method.\n\nThe public subpaths cover transformation, filtering, combination,\nhigher-order, timing, buffering/windowing, error recovery, sharing/connection,\nquery, and terminal capabilities. The complete authoritative list is the\n[`exports` map](../package.json); migration status and behavioral evidence are\nin the [generated ledger](MIGRATION_EVIDENCE_LEDGER.md).\n\n## Factories and composition\n\nFactories such as `timer` are static Symbols:\n\n```ts\nimport { timer } from 'rxjs/timer';\n\nObservable[timer](1000).subscribe(console.log);\n```\n\nThe `pipe` Symbol supports instance and static composition:\n\n```ts\nimport { map } from 'rxjs/map';\nimport { pipe } from 'rxjs/pipe';\n\nconst doubled = source[pipe]((values) => values[map]((value) => value * 2));\nconst normalized = Observable[pipe]([1, 2], (values) => values[map](String));\n```\n\nRxJS 9 does not install `.pipe`, publish RxJS 7 pipeable operator functions,\nor restore `OperatorFunction`.\n\n## Construction and input boundaries\n\nDerived RxJS operators use the receiver's construction protocol. Compatible\nsubclasses can preserve their result constructor; `ColdObservable` selects its\nproducer-per-subscription result contract.\n\nInputs cross the active realm's platform `Observable.from` boundary. Arbitrary\nobjects with a `subscribe` method are not automatically accepted, and\ntransparent foreign-realm conversion is not claimed. Review the\n[migration guide](../MIGRATION.md) before translating RxJS 7 inputs or\nlifecycle assumptions.\n\n## Cancellation and teardown\n\nSubscriptions accept `{ signal: AbortSignal }`. Operators own upstream work\nthrough the downstream Subscriber lifecycle, and cancellation does not become\ncompletion. Teardown functions and `subscriber.addTeardown()` participate in\nthe same platform lifecycle.\n\n## Environment and distribution\n\nThe package requires Node 22.13+ and publishes ESM only. Node `require()` uses\nthe supported `require(esm)` bridge and resolves the same module files as\n`import`. Current browser, Deno, Bun, and Webpack support does not select\nruntime-specific code. See [release gates](RELEASE_GATES.md) for the exact\nmatrix and budgets.\n","isInternal":false,"tokens":783,"sizeBytes":3632},{"name":"MIGRATION_EVIDENCE_LEDGER.md","path":"packages/rxjs/docs/MIGRATION_EVIDENCE_LEDGER.md","rawUrl":"https://raw.githubusercontent.com/ReactiveX/rxjs/HEAD/packages/rxjs/docs/MIGRATION_EVIDENCE_LEDGER.md","title":"Docs Skill","category":"anthropic-skill","format":"markdown","content":"# RxJS 7 migration-evidence ledger\n\nThis generated ledger joins the versioned RxJS Next capability registry to the\nsource-pinned RxJS 7 executable manifest. It records migration status and\nevidence; it does not promise an RxJS 7 runtime compatibility surface.\n\n- **RxJS 7 source:** `7.x` at `e5351d02e225e275ac0e497c7b66eaa5f0c88791`\n- **Entries:** 161 (111 operators, 21 creation/static functions, 29 values/types)\n- **Distinct evidence cases:** 2271\n- **Entries without source-pinned cases:** 0\n- **Rows using canonical alias evidence:** 4\n- **Rows using pinned non-marble or focused Next evidence:** 3\n\nThe complete case IDs and source files are retained in\n`packages/rxjs/test/ported/migration-evidence-ledger.generated.json`. Every\nprioritized row has direct, canonical-alias, or supplemental evidence. Cold and\nfallback totals account for every linked executable case; supplemental rows\nname their pinned non-marble or focused Next sources explicitly.\n\nRegenerate or verify the ledger with:\n\n```sh\npnpm --filter rxjs run test:unit:ledger:generate\npnpm --filter rxjs run test:unit:ledger:check\n```\n\n## Operators\n\n| RxJS 7 API | Next status | Evidence | Cases | Cold | Fallback | Classifications | Sharing | Cancellation | Types | Migration | Decisions |\n| ------------------------- | ------------------------------------------- | ------------------- | ----- | ------- | -------- | --------------------------------------------------------------------- | ---------------------- | ------------ | --------- | ------------------------------------- | --------------------------------- |\n| `audit` | Present; parity verified | source-pinned | 21 | 21/21 | 21/21 | portable | shared-active-platform | AbortSignal | preserved | mechanical-change | D-003, D-048, D-049 |\n| `auditTime` | Partial unified mapping | source-pinned | 12 | 12/12 | 12/12 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `buffer` | Present; parity verified | source-pinned | 26 | 26/26 | 26/26 | harness-rewrite, portable | shared-active-platform | AbortSignal | preserved | mechanical-change | D-003, D-048, D-049 |\n| `bufferCount` | Partial unified mapping | source-pinned | 9 | 9/9 | 9/9 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `bufferTime` | Present; scheduler adapted to host timing | source-pinned | 18 | 18/18 | 18/18 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-033, D-034, D-048, D-049 |\n| `bufferToggle` | Present; parity unverified | source-pinned | 18 | 18/18 | 18/18 | intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `bufferWhen` | Partial unified mapping | source-pinned | 16 | 16/16 | 16/16 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `catchError` | Present; parity unverified | source-pinned | 18 | 17/18 | 17/18 | compatibility-only, harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `combineLatest` | Partial unified mapping | source-pinned | 34 | 34/34 | 34/34 | intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `combineLatestAll` | Present; parity unverified | source-pinned | 31 | 31/31 | 31/31 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `combineLatestWith` | Partial unified mapping | source-pinned | 30 | 30/30 | 30/30 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `concat` | Partial unified mapping | source-pinned | 27 | 27/27 | 27/27 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `concatAll` | Partial unified mapping | source-pinned | 30 | 30/30 | 30/30 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `concatMap` | Partial unified mapping | source-pinned | 34 | 34/34 | 34/34 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `concatMapTo` | Partial unified mapping | source-pinned | 18 | 18/18 | 18/18 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `concatWith` | Partial unified mapping | source-pinned | 22 | 22/22 | 22/22 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `connect` | Present; parity unverified | source-pinned | 50 | 50/50 | 48/50 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `count` | Present; parity unverified | source-pinned | 23 | 23/23 | 23/23 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `debounce` | Present; parity unverified | source-pinned | 26 | 26/26 | 26/26 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `debounceTime` | Partial unified mapping | source-pinned | 17 | 17/17 | 17/17 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `defaultIfEmpty` | Present; parity unverified | source-pinned | 7 | 7/7 | 7/7 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `delay` | Present; scheduler adapted to host timing | source-pinned | 43 | 43/43 | 43/43 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-033, D-034, D-048, D-049 |\n| `delayWhen` | Present; parity unverified | source-pinned | 15 | 15/15 | 15/15 | intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `dematerialize` | Present; parity unverified | source-pinned | 13 | 13/13 | 13/13 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `distinct` | Present; parity unverified | source-pinned | 22 | 22/22 | 22/22 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `distinctUntilChanged` | Present; parity unverified | source-pinned | 22 | 22/22 | 22/22 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `distinctUntilKeyChanged` | Present; parity unverified | source-pinned | 21 | 21/21 | 21/21 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `elementAt` | Present; partial empty behavior | source-pinned | 12 | 12/12 | 12/12 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `endWith` | Partial unified mapping | source-pinned | 16 | 16/16 | 16/16 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `every` | Present; parity unverified | source-pinned | 22 | 22/22 | 22/22 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `exhaust` | Partial unified mapping | source-pinned-alias | 15 | 15/15 | 15/15 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `exhaustAll` | Partial unified mapping | source-pinned | 15 | 15/15 | 15/15 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `exhaustMap` | Present; parity unverified | source-pinned | 18 | 17/18 | 17/18 | compatibility-only, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `expand` | Present; scheduler overload deferred | source-pinned | 13 | 13/13 | 13/13 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-033, D-034, D-048, D-049 |\n| `filter` | Present; parity unverified | source-pinned | 21 | 21/21 | 21/21 | intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `finalize` | Present; parity unverified | source-pinned | 8 | 8/8 | 8/8 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `find` | Present; parity unverified | source-pinned | 12 | 12/12 | 12/12 | intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `findIndex` | Present; parity unverified | source-pinned | 12 | 12/12 | 12/12 | intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `first` | Present; parity unverified | source-pinned | 17 | 17/17 | 17/17 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `flatMap` | Partial unified mapping | source-pinned-alias | 149 | 143/149 | 143/149 | compatibility-only, harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `groupBy` | Present; scheduler-internal cases deferred | source-pinned | 36 | 36/36 | 36/36 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-033, D-034, D-048, D-049 |\n| `ignoreElements` | Partial unified mapping | source-pinned | 9 | 9/9 | 9/9 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `isEmpty` | Present; parity unverified | source-pinned | 7 | 7/7 | 7/7 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `last` | Present; parity unverified | source-pinned | 11 | 11/11 | 11/11 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `map` | Present; parity unverified | source-pinned | 93 | 92/93 | 93/93 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `mapTo` | Partial unified mapping | source-pinned | 11 | 11/11 | 11/11 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `materialize` | Present; parity unverified | source-pinned | 10 | 10/10 | 10/10 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `max` | Present; parity unverified | source-pinned | 18 | 18/18 | 18/18 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `merge` | Partial unified mapping | source-pinned | 1 | 1/1 | 1/1 | intentional-divergence | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `mergeAll` | Partial unified mapping | source-pinned | 25 | 25/25 | 25/25 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `mergeMap` | Partial unified mapping | source-pinned | 149 | 143/149 | 143/149 | compatibility-only, harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `mergeMapTo` | Partial unified mapping | source-pinned | 106 | 87/106 | 103/106 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `mergeScan` | Present; parity unverified | source-pinned | 20 | 20/20 | 20/20 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `mergeWith` | Partial unified mapping | source-pinned | 17 | 17/17 | 17/17 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `min` | Present; parity unverified | source-pinned | 18 | 18/18 | 18/18 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `multicast` | Compatibility-only | source-pinned | 70 | 65/70 | 68/70 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | semantic-review | D-003, D-039, D-048, D-049 |\n| `observeOn` | Partial scheduler mapping | source-pinned | 7 | 7/7 | 7/7 | harness-rewrite | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-033, D-034, D-048, D-049 |\n| `onErrorResumeNext` | Partial unified mapping | source-pinned | 11 | 10/11 | 10/11 | compatibility-only, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `pairwise` | Present; parity unverified | source-pinned | 7 | 7/7 | 7/7 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `pluck` | Present; parity unverified | source-pinned | 14 | 14/14 | 14/14 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `publish` | Compatibility-only | source-pinned | 64 | 63/64 | 62/64 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | semantic-review | D-003, D-039, D-048, D-049 |\n| `publishBehavior` | Compatibility-only | source-pinned | 62 | 54/62 | 60/62 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | semantic-review | D-003, D-039, D-048, D-049 |\n| `publishLast` | Compatibility-only | source-pinned | 61 | 61/61 | 59/61 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | semantic-review | D-003, D-039, D-048, D-049 |\n| `publishReplay` | Compatibility-only | source-pinned | 69 | 60/69 | 66/69 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | semantic-review | D-003, D-039, D-048, D-049 |\n| `race` | Partial unified mapping | source-pinned | 12 | 12/12 | 12/12 | intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `raceWith` | Partial unified mapping | source-pinned | 10 | 10/10 | 10/10 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `reduce` | Present; parity unverified | source-pinned | 18 | 18/18 | 18/18 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `refCount` | Compatibility-only | source-pinned | 74 | 62/74 | 72/74 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | semantic-review | D-003, D-039, D-048, D-049 |\n| `repeat` | Partial unified mapping | source-pinned | 64 | 60/64 | 64/64 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `repeatWhen` | Present; parity unverified | source-pinned | 20 | 20/20 | 20/20 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `retry` | Partial unified mapping | source-pinned | 67 | 63/67 | 65/67 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `retryWhen` | Present; parity unverified | source-pinned | 19 | 19/19 | 19/19 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `sample` | Present; parity unverified | source-pinned | 16 | 16/16 | 16/16 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `sampleTime` | Present; scheduler adapted to host timing | source-pinned | 10 | 10/10 | 10/10 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-033, D-034, D-048, D-049 |\n| `scan` | Present; parity unverified | source-pinned | 12 | 12/12 | 12/12 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `sequenceEqual` | Present; parity verified | source-pinned | 23 | 23/23 | 23/23 | harness-rewrite, portable | shared-active-platform | AbortSignal | preserved | mechanical-change | D-003, D-048, D-049 |\n| `share` | Present; platform lifecycle review required | source-pinned | 176 | 176/176 | 174/176 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `shareReplay` | Present; platform lifecycle review required | source-pinned | 16 | 16/16 | 16/16 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `single` | Present; parity unverified | source-pinned | 25 | 25/25 | 25/25 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `skip` | Present; parity unverified | source-pinned | 29 | 29/29 | 29/29 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `skipLast` | Present; parity unverified | source-pinned | 16 | 16/16 | 16/16 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `skipUntil` | Present; parity unverified | source-pinned | 19 | 18/19 | 18/19 | compatibility-only, harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `skipWhile` | Present; parity unverified | source-pinned | 15 | 15/15 | 15/15 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `startWith` | Present; scheduler overload deferred | source-pinned | 24 | 24/24 | 24/24 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-033, D-034, D-048, D-049 |\n| `subscribeOn` | Partial scheduler mapping | source-pinned | 8 | 8/8 | 8/8 | harness-rewrite | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-033, D-034, D-048, D-049 |\n| `switchAll` | Partial unified mapping | source-pinned | 11 | 11/11 | 11/11 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `switchMap` | Present; parity unverified | source-pinned | 19 | 18/19 | 18/19 | compatibility-only, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `switchMapTo` | Partial unified mapping | source-pinned | 15 | 15/15 | 15/15 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `switchScan` | Present; parity unverified | source-pinned | 18 | 18/18 | 18/18 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `take` | Present; parity unverified | source-pinned | 47 | 47/47 | 47/47 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `takeLast` | Present; parity unverified | source-pinned | 18 | 18/18 | 18/18 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `takeUntil` | Present; parity unverified | source-pinned | 23 | 23/23 | 23/23 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `takeWhile` | Present; parity unverified | source-pinned | 23 | 23/23 | 23/23 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `tap` | Present; parity unverified | source-pinned | 73 | 66/73 | 73/73 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `throttle` | Present; parity unverified | source-pinned | 28 | 28/28 | 28/28 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `throttleTime` | Partial unified mapping | source-pinned | 16 | 16/16 | 16/16 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `throwIfEmpty` | Present; parity unverified | source-pinned | 7 | 7/7 | 7/7 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `timeInterval` | Present; scheduler adapted to host timing | source-pinned | 11 | 11/11 | 11/11 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-033, D-034, D-048, D-049 |\n| `timeout` | Partial unified mapping | source-pinned | 38 | 38/38 | 38/38 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-033, D-034, D-048, D-049 |\n| `timeoutWith` | Partial unified mapping | source-pinned | 15 | 15/15 | 15/15 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `timestamp` | Present; scheduler adapted to host timing | source-pinned | 11 | 11/11 | 11/11 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-033, D-034, D-048, D-049 |\n| `toArray` | Partial unified mapping | source-pinned | 15 | 15/15 | 15/15 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `window` | Present; parity unverified | source-pinned | 18 | 18/18 | 18/18 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `windowCount` | Present; parity unverified | source-pinned | 9 | 9/9 | 9/9 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `windowTime` | Present; scheduler adapted to host timing | source-pinned | 13 | 13/13 | 13/13 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-033, D-034, D-048, D-049 |\n| `windowToggle` | Present; parity unverified | source-pinned | 19 | 19/19 | 19/19 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `windowWhen` | Present; parity unverified | source-pinned | 15 | 15/15 | 15/15 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `withLatestFrom` | Unified mapping | source-pinned | 17 | 17/17 | 17/17 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `zip` | Compatibility alias | source-pinned | 10 | 8/10 | 10/10 | intentional-divergence, portable | shared-active-platform | AbortSignal | changed | semantic-review | D-003, D-039, D-048, D-049 |\n| `zipAll` | Present; parity unverified | source-pinned | 46 | 46/46 | 46/46 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `zipWith` | Present; parity unverified | source-pinned | 32 | 32/32 | 32/32 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n\n## Creation and static functions\n\n| RxJS 7 API | Next status | Evidence | Cases | Cold | Fallback | Classifications | Sharing | Cancellation | Types | Migration | Decisions |\n| ------------------- | ------------------------------------ | ------------------- | ----- | ------- | -------- | --------------------------------------------------------------------- | ---------------------- | ------------ | ------- | ------------------------------------- | ---------------------------------------- |\n| `animationFrames` | Present; parity unverified | source-pinned | 4 | 4/4 | 4/4 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-033, D-034, D-040, D-048, D-049 |\n| `combineLatest` | Partial unified mapping | source-pinned | 32 | 32/32 | 32/32 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-040, D-048, D-049 |\n| `concat` | Partial unified mapping | source-pinned | 115 | 114/115 | 114/115 | compatibility-only, harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-040, D-048, D-049 |\n| `defer` | Partial platform mapping | source-pinned | 12 | 12/12 | 12/12 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-040 |\n| `empty` | Partial standalone mapping | source-pinned | 1 | 1/1 | 1/1 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-040 |\n| `forkJoin` | Present; parity unverified | source-pinned | 39 | 35/39 | 35/39 | compatibility-only, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-040, D-048, D-049 |\n| `from` | Platform mapping | source-pinned | 8 | 6/8 | 6/8 | compatibility-only, harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-040 |\n| `fromEvent` | Partial platform string mapping | source-pinned | 1 | 1/1 | 1/1 | harness-rewrite | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-040 |\n| `generate` | Present; scheduler overload deferred | source-pinned | 13 | 13/13 | 13/13 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-033, D-034, D-040, D-048, D-049 |\n| `iif` | Partial platform mapping | source-pinned | 4 | 4/4 | 4/4 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-040 |\n| `interval` | Present; parity unverified | source-pinned | 12 | 12/12 | 12/12 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-040, D-048, D-049 |\n| `merge` | Partial unified mapping | source-pinned | 81 | 78/81 | 76/81 | compatibility-only, harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-040, D-048, D-049 |\n| `never` | Partial standalone mapping | source-pinned-alias | 42 | 42/42 | 42/42 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-040 |\n| `of` | Partial platform mapping | source-pinned | 400 | 394/400 | 394/400 | compatibility-only, harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-040 |\n| `onErrorResumeNext` | Partial unified mapping | source-pinned | 3 | 3/3 | 3/3 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-040, D-048, D-049 |\n| `pairs` | Partial platform mapping | source-pinned | 2 | 2/2 | 2/2 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-040 |\n| `partition` | Present; parity unverified | source-pinned | 16 | 16/16 | 16/16 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-040, D-048, D-049 |\n| `race` | Partial unified mapping | source-pinned | 15 | 15/15 | 15/15 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-040, D-048, D-049 |\n| `range` | Partial platform mapping | source-pinned | 3 | 3/3 | 3/3 | harness-rewrite | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-040 |\n| `throwError` | Partial platform mapping | source-pinned | 31 | 31/31 | 31/31 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-040 |\n| `timer` | Partial unified mapping | source-pinned | 37 | 37/37 | 37/37 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-040, D-048, D-049 |\n\n## Values, types, and standalone functions\n\n| RxJS 7 API | Next status | Evidence | Cases | Cold | Fallback | Classifications | Sharing | Cancellation | Types | Migration | Decisions |\n| ------------------------- | --------------------------------- | ------------------- | ----- | ------------ | ------------ | --------------------------------------------------------------------- | -------------------------------- | ------------------ | ------------------ | ------------------------------------- | --------------------------------- |\n| `ArgumentOutOfRangeError` | Present; parity verified | source-pinned | 2 | 2/2 | 2/2 | portable | not-applicable | not-applicable | preserved | mechanical-change | D-040 |\n| `AsyncSubject` | Compatibility-only | source-pinned | 48 | 48/48 | 46/48 | harness-rewrite, intentional-divergence | subject-hot | AbortSignal | changed | semantic-review | D-035, D-039, D-040, D-050 |\n| `BehaviorSubject` | Partial standalone mapping | source-pinned | 51 | 51/51 | 49/51 | harness-rewrite, intentional-divergence, portable | subject-hot | AbortSignal | changed | mechanical-change-and-semantic-review | D-035, D-039, D-040, D-050 |\n| `ColdObservable` | Compatibility-only | supplemental | 0 | supplemental | supplemental | supplemental | producer-per-direct-subscription | AbortSignal | changed | semantic-review | D-035, D-037, D-039, D-040, D-050 |\n| `config` | Test compatibility fixture | source-pinned | 3 | 3/3 | 3/3 | harness-rewrite | not-applicable | test-local-adapter | changed | adapter | D-039, D-040 |\n| `connectable` | Present; parity unverified | source-pinned | 2 | 2/2 | 2/2 | harness-rewrite, portable | subject-hot | AbortSignal | changed | mechanical-change | D-035, D-039, D-040 |\n| `ConnectableObservable` | Compatibility-only | source-pinned | 45 | 36/45 | 45/45 | harness-rewrite, intentional-divergence, portable | subject-hot | AbortSignal | changed | semantic-review | D-035, D-039, D-040 |\n| `EMPTY` | Present; parity unverified | source-pinned | 42 | 42/42 | 42/42 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-040 |\n| `EmptyError` | Present; parity unverified | source-pinned | 13 | 13/13 | 13/13 | portable | not-applicable | not-applicable | changed | mechanical-change | D-040 |\n| `firstValueFrom` | Partial platform mapping | supplemental | 0 | supplemental | supplemental | supplemental | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-040 |\n| `fromEventPattern` | Present; parity unverified | source-pinned | 1 | 1/1 | 1/1 | harness-rewrite | shared-active-platform | AbortSignal | changed | mechanical-change \n\n","isInternal":false,"tokens":10498,"sizeBytes":50030},{"name":"PRERELEASE_APPROVAL.md","path":"packages/rxjs/docs/PRERELEASE_APPROVAL.md","rawUrl":"https://raw.githubusercontent.com/ReactiveX/rxjs/HEAD/packages/rxjs/docs/PRERELEASE_APPROVAL.md","title":"Docs Skill","category":"anthropic-skill","format":"markdown","content":"# RxJS 9 beta.0 approval\n\n## Decision\n\nThe repository evidence approves `rxjs@9.0.0-beta.0` and the synchronized\nfour-package train to begin the RxJS 9 public beta under npm's `next` tag, once\nthe configured blocking CI jobs are green. RxJS 7 remains npm's `latest` line\nand remains maintained.\n\nThis approval does not publish a package, create a GitHub release, promote RxJS\n9 to `latest`, or approve the stable `9.0.0` release. Stable promotion requires\npublic beta feedback and a separate explicit decision. The version number is 9\nbecause the paused RxJS 8 effort predates this platform-based generation; RxJS\n8 was not silently shipped or erased.\n\n## Adoption evidence\n\nThe exact four package artifacts were packed and audited locally. An isolated,\noffline consumer installed the `rxjs`, `@rxjs/observable-polyfill`, and\n`@rxjs/test` tarballs and passed:\n\n- ESM imports and runtime behavior;\n- Node 22.13, 24.12, and advisory 26.5 `require(esm)` behavior;\n- strict public TypeScript declarations;\n- `@rxjs/test` virtual-time behavior;\n- a minified browser bundle using only the packed ESM files.\n\nThe browser bundle was 20,222 bytes. Packed artifact sizes were:\n\n| Package | Tarball bytes | Budget |\n| --------------------------- | ------------: | ------: |\n| `rxjs` | 183,920 | 250,000 |\n| `@rxjs/observable-polyfill` | 23,375 | 30,000 |\n| `@rxjs/test` | 47,270 | 60,000 |\n| `@rxjs/migrate` | 112,638 | 140,000 |\n\nThe audit found no source specs, CommonJS/browser/Webpack dialect copies, or\nmissing package documentation. The Nx first-release version dry run resolves\nthe complete train to `9.0.0-beta.0`.\n\n## Broader qualification\n\n- Focused product suites pass 51 polyfill, 750 RxJS, 75 test-harness, and 166\n migration tests.\n- Pinned Observable WPT passes all 52 URLs, 525 upstream subtests, and 52 exact\n implementation-identity attestations.\n- Current Chromium, Firefox, and WebKit pass the shared eight-case lifecycle\n and Symbol contract. Desktop and Mobile Safari are separate blocking\n SafariDriver jobs; Mobile Safari requires an actual iOS simulator.\n- Node, Deno, Bun, Webpack, bundle-size, and performance evidence passes the\n checked-in gates described in [RELEASE_GATES.md](RELEASE_GATES.md).\n- The representative migration program has three completed RxJS 7 migrations\n and one correct safe stop across Vitest, Mocha, Jest, application/library,\n cold, platform-shared, mixed, and unsupported contracts.\n\n## Known non-blockers\n\nThe complete source-pinned RxJS 7 corpus retains 39 cold and 22 fallback\nfailures. Every one is a reviewed platform-lifecycle divergence or unsupported\narbitrary-subscribable compatibility case. They are executable migration\nevidence, not hidden failures and not a promise of an RxJS 7 compatibility\nruntime.\n\nLocal branded Safari execution was not forced by changing a persistent host\nsecurity setting. The clean-runner Safari and iOS simulator jobs are blocking\nconditions of publication, not waived evidence.\n\n## Publication boundary\n\nThe [release process](https://github.com/ReactiveX/rxjs/blob/master/docs/RELEASE_PROCESS.md)\nrequires a clean, synchronized `master` checkout and one interactive\n`pnpm release:beta 9.0.0-beta.0` command. It checks version identity,\npackage-local documentation, ESM-only exports, package gates, and npm dry runs;\nprints the exact tarball integrities; and then uses npm's OTP/WebAuthn flow for\neach public package. The supporting packages publish first and `rxjs` publishes\nlast. No CI credential or documentation application is part of publication.\n","isInternal":false,"tokens":857,"sizeBytes":3640},{"name":"RELEASE_GATES.md","path":"packages/rxjs/docs/RELEASE_GATES.md","rawUrl":"https://raw.githubusercontent.com/ReactiveX/rxjs/HEAD/packages/rxjs/docs/RELEASE_GATES.md","title":"Docs Skill","category":"anthropic-skill","format":"markdown","content":"# RxJS 9 release gates\n\nThis document describes the executable environment and package gates for the\nRxJS 9 prerelease line. It is package documentation; it does not depend on the\nrepository documentation application.\n\nThe repository's [release runbook](https://github.com/ReactiveX/rxjs/blob/master/docs/RELEASE_PROCESS.md)\ndefines the clean-checkout requirement, interactive npm publication order,\nintegrity verification, and failure recovery. CI qualifies the source; only a\nmaintainer running the local release command can authorize publication.\n\n## Runtime matrix\n\n| Environment | Release role | Executable evidence |\n| -------------------------- | -------------------- | --------------------------------------------------------------------------- |\n| Node 22.13.0+ | Blocking | Package build, types, ESM import, Node `require(esm)`, and runtime contract |\n| Node 24 | Blocking | Full package and release gates, plus pinned Observable WPT |\n| Node 26 | Advisory during beta | The same package and runtime gates with a non-blocking CI result |\n| Current Chrome and Firefox | Blocking | Eight-case browser lifecycle and Symbol-extension contract |\n| Current desktop Safari | Blocking | The same contract through Apple SafariDriver |\n| Current Mobile Safari | Blocking | The same contract in an actual iOS simulator through Apple SafariDriver |\n| Current Playwright WebKit | Additional signal | The same contract, reported as WebKit rather than branded Safari |\n| Deno 2.8.0 | Blocking | Package-built runtime contract |\n| Bun 1.3.14 | Blocking | Package-built runtime contract |\n| Webpack 5.106.2 | Blocking | ESM resolution, production execution, and output-size budget |\n\nThe release-coherence checker pins the concrete Deno, Bun, Webpack, browser,\nNode, and Safari CI lanes. Updating a current-runtime version is therefore a\nreviewed release change rather than silent drift.\n\n## CI ownership\n\n| Workflow | Pull requests | `master` pushes |\n| ----------------- | --------------------------------------------------------- | -------------------------------------------------- |\n| Main CI | Package matrix plus exact migration evidence and tooling | Same blocking gates on every push |\n| TypeScript latest | RxJS compilation against the latest TypeScript | Same compatibility signal on every push |\n| Observable WPT | Blocking when platform, package, or harness paths change | Blocking pinned conformance on every push |\n| Release readiness | Blocking when release packages, scripts, or config change | Complete blocking environment matrix on every push |\n\nMain CI executes all 2,338 source-pinned RxJS 7 evidence cases in cold and\npolyfill modes and requires exact equality with the reviewed 2,299/39 and\n2,316/22 pass/failure case-ID sets. The raw audit commands still report the\nintentional divergences as ordinary failures; the CI verifier blocks any added\nfailure, unexpected pass, incomplete collection, or identity drift until the\nevidence is reviewed. Main CI also owns generated evidence freshness,\nbundle-analysis tests, SafariDriver unit tests, and active-workflow validation.\nRelease coherence rejects removal of required commands, lanes, or `master`\ntriggers.\n\n## Distribution contract\n\nEvery supported consumer receives the same `dist/esm` JavaScript. Browser,\nWebpack, ESM `import`, and Node `require(esm)` export conditions do not select\ntarget-specific copies. Deno and Bun support adds test infrastructure only; it\ndoes not add runtime code, dependencies, export conditions, or bundle bytes.\n\nThere is no CommonJS artifact. `require('rxjs')` is supported only through the\nNode 22.13+ `require(esm)` bridge and returns the same module identity and exact\nSymbols as ESM import.\n\n## Budgets\n\nThe checked-in budgets in `test/release/budgets.json` are blocking:\n\n- the representative minified Webpack bundle must not exceed 22,000 bytes;\n- the median map pipeline must process at least 5,000,000 values per second;\n- the median subscribe-and-abort loop must complete at least 30,000\n cancellations per second.\n- packed tarballs must stay under 250,000 bytes for `rxjs`, 30,000 bytes for\n the polyfill, 60,000 bytes for `@rxjs/test`, and 140,000 bytes for\n `@rxjs/migrate`.\n\nThe initial Node 24 evidence was 17,502 Webpack bytes, approximately 50.4\nmillion mapped values per second, and approximately 140,500 cancellations per\nsecond. The throughput floors deliberately leave substantial runner headroom;\nthe bundle ceiling leaves roughly 25% growth headroom while still catching a\nduplicate dialect or large accidental dependency.\n\nThe packed-adoption gate installs the local tarballs into an isolated consumer\nwith no registry access, then runs ESM, Node `require(esm)`, TypeScript, marble\ntesting, and a browser bundle. It also rejects source specs, duplicate output\ndialects, missing package documentation, and tarball-size regressions.\n\n## Commands\n\nFrom the repository root:\n\n```sh\npnpm run release:check\npnpm --filter rxjs run test:unit:audit:check\npnpm run test:bundle-analysis\npnpm run test:release:safari\npnpm run test:workflows\npnpm run test:release:runtime\npnpm run test:release:browsers\npnpm run test:release:safari\npnpm run test:release:webpack\npnpm run test:release:performance\npnpm run test:release:adoption\npnpm run test:wpt\n```\n\nDesktop and Mobile Safari execution is CI-owned because SafariDriver requires\nhost-level automation authorization. The Mobile Safari lane requests\n`platformName: iOS` and `safari:useSimulator: true`; Playwright WebKit is never\nsubstituted for that branded-browser gate.\n\nThe complete source-pinned RxJS 7 migration corpus is evidence, not a claim\nthat RxJS 9 implements every RxJS 7 behavior. Its reviewed intentional\ndivergences remain nonzero by design; the focused source suite, package gates,\nruntime matrix, and conformance suite are the blocking release checks.\n","isInternal":false,"tokens":1300,"sizeBytes":6461},{"name":"SECURITY_ASSURANCE.md","path":"packages/rxjs/docs/SECURITY_ASSURANCE.md","rawUrl":"https://raw.githubusercontent.com/ReactiveX/rxjs/HEAD/packages/rxjs/docs/SECURITY_ASSURANCE.md","title":"Docs Skill","category":"anthropic-skill","format":"markdown","content":"# RxJS 9 security assurance\n\nRxJS 9 uses a deliberately small release boundary. This document describes\nthe evidence and trust assumptions; it does not promise that the software is\nfree of vulnerabilities.\n\n## What users can rely on\n\n- The `rxjs` runtime depends only on the RxJS-owned\n `@rxjs/observable-polyfill`; that package has no runtime dependencies.\n- Pull requests and every `master` push run the package, type, browser, Safari,\n Web Platform Test, bundler, performance, migration, dependency-review,\n CodeQL, and OSV checks described in [RELEASE_GATES.md](RELEASE_GATES.md).\n- npm publication is not available to GitHub Actions. The repository stores no\n npm publishing token and has no publishing workflow, trusted publisher, or\n release App.\n- A maintainer publishes from a clean local `master` checkout with\n `pnpm release:beta `. The command builds and tests, packs the four\n packages, prints SHA-512 integrities, and runs npm publication dry runs before\n asking for irreversible confirmation.\n- npm's interactive OTP/WebAuthn flow authorizes each package. Supporting\n packages publish first and `rxjs` publishes last.\n- The command verifies npm's registry integrity and `next` tag for all four\n packages and confirms that `rxjs@latest` remains on RxJS 7.\n- An interrupted command can skip an already-published package only when the\n registry integrity equals the freshly packed tarball.\n\n## One-maintainer reality\n\nRxJS currently has one active maintainer. The same person authors, reviews,\nmerges, and releases changes. Pull requests expose diffs and run mandatory\nchecks, but RxJS does not claim independent human approval. OpenSSF's\nCode-Review score is therefore accepted rather than manipulated with\nceremonial approvals.\n\nThe publication boundary trusts that maintainer's local machine and npm\nauthentication. Interactive WebAuthn, required CI, dry runs, ordered\npublication, and registry verification reduce common mistakes and credential\nrisks; they do not remove the risk of a compromised maintainer machine or npm\naccount. Recovery codes are kept offline. Package publishing access requires\ntwo-factor authentication and disallows automation tokens after each new\npackage record exists.\n\n## Verify a release\n\nAfter installing with a lockfile, verify npm registry signatures:\n\n```sh\nnpm audit signatures\n```\n\nInspect the registry integrity and channels directly:\n\n```sh\nnpm view rxjs@9.0.0-beta.0 dist.integrity\nnpm view rxjs@next version\nnpm view rxjs@latest version\n```\n\nThe release operator records all four integrity values and the immutable GitHub\nRelease URL in the project-plan session log.\n\n## Vulnerability evidence\n\nOSV scanning runs on pull requests, every `master` push, and weekly. Anything\nreachable from runtime, build, or test tooling must be fixed or removed. The\ninherited legacy documentation-application toolchain is excluded from RxJS 9\nand tracked separately; its time-bounded exceptions do not change the release\npackage scans.\n\nProperty-based tests exercise the Observable lifecycle state machine. Package\nand release-script tests cover synchronized versions, clean-checkout guards,\ninteractive credential restrictions, publication order, npm channels, and\nintegrity comparisons.\n\n## What this does not prove\n\nPassing tests does not prove that source is bug-free. A matching registry hash\nproves that npm received the local tarball; it does not prove that the local\nmachine or maintainer account was uncompromised. The initial manual publication\ndoes not provide npm's CI provenance attestation. These are accepted tradeoffs\nfor an understandable sole-maintainer process.\n\n## OpenSSF in context\n\n[![OpenSSF Scorecard](https://api.scorecard.dev/projects/github.com/ReactiveX/rxjs/badge)](https://scorecard.dev/viewer/?uri=github.com/ReactiveX/rxjs)\n\nOpenSSF Scorecard is a useful repository-hygiene signal, not a release gate or\nthe project's primary security claim. Users assessing a specific RxJS 9\nversion should prefer required-CI history, registry signatures, exact package\nintegrity, and the tagged source commit.\n","isInternal":false,"tokens":877,"sizeBytes":4087},{"name":"UNSUPPORTED_RXJS_7_SURFACES.md","path":"packages/rxjs/docs/UNSUPPORTED_RXJS_7_SURFACES.md","rawUrl":"https://raw.githubusercontent.com/ReactiveX/rxjs/HEAD/packages/rxjs/docs/UNSUPPORTED_RXJS_7_SURFACES.md","title":"Docs Skill","category":"anthropic-skill","format":"markdown","content":"# Unsupported RxJS 7 surfaces\n\nThis generated catalog records RxJS 7 public imports and behavioral protocols that RxJS Next does not preserve as compatibility APIs. It is migration guidance, not an emulation commitment. The source inventory is pinned to RxJS 7 `7.x` at `e5351d02e225e275ac0e497c7b66eaa5f0c88791`.\n\nRegenerate it with `pnpm --filter rxjs run test:unit:unsupported:generate`; the corresponding `--check` gate rejects a stale document, a source-pin mismatch, missing required categories, or unclassified scheduler-bearing capabilities.\n\n## Summary\n\n| Measure | Count |\n| -------------------- | ----: |\n| Catalog groups | 27 |\n| Named surfaces | 147 |\n| Manual Review groups | 5 |\n| Replace groups | 17 |\n| Unsupported groups | 5 |\n\n## Dispositions\n\n- **Replace:** a supported Next or platform destination exists, but its imports, types, or lifecycle may differ.\n- **Manual review:** no mechanical rewrite is safe without reviewing cancellation, sharing, timing, or ownership.\n- **Unsupported:** no accepted Next compatibility contract exists.\n- **Test only:** any adapter is limited to evidence infrastructure and must not become an application migration.\n- **Removed:** the surface has no replacement and should disappear.\n\n## Imports and package paths\n\n| RxJS 7 surface | Disposition | Migration direction | Why | Decisions |\n| ------------------------------------------------------------------------------------------------------------- | ------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ | ------------------- |\n| `rxjs/operators`
`root-imported operator functions`
`source.pipe(...)` | Replace | Import exact Symbols from rxjs/ and invoke source[symbol](...). Use rxjs/pipe only for deliberate Symbol composition. | RxJS Next does not publish the RxJS 7 pipeable-function or string-named .pipe surface. | D-003, D-039, D-050 |\n| `rxjs:Observable`
`rxjs:Subscriber` | Replace | Use the active realm's ambient Observable and Subscriber after @rxjs/observable-polyfill initialization when needed. | The platform owns these constructors; the rxjs root does not re-export compatibility classes for them. | D-039, D-040, D-041 |\n| `rxjs/testing`
`TestScheduler`
`VirtualTimeScheduler`
`VirtualAction` | Replace | Use @rxjs/test rxTest() and its explicit cold(), hot(), observable(), virtual host-time, and assertion helpers. | The public scheduler classes and manual TestScheduler mode are not part of the Next runtime or test contract. | D-012, D-033, D-039 |\n| `rxjs/ajax`
`rxjs/fetch`
`rxjs/webSocket`
`ajax`
`fromFetch`
`webSocket`
`WebSocketSubject` | Manual Review | Use platform fetch, XMLHttpRequest, WebSocket, EventTarget.when, or an application adapter selected for the required cancellation and sharing contract. | RxJS Next does not currently publish the RxJS 7 DOM specialty packages or their wrapper types. | D-039, D-040 |\n| `rxjs/internal/*`
`rxjs/src/*`
`unexported package paths` | Unsupported | Replace with an accepted public Next subpath or application-owned code after semantic review. | RxJS 7 internals are not preserved as public package contracts and must not be revived to satisfy migration tests. | D-039, D-040 |\n| `bindCallback`
`bindNodeCallback`
`scheduled`
`using`
`isObservable` | Manual Review | Wrap callback or resource ownership explicitly with Observable and AbortSignal; use platform conversion or capability-specific mappings where applicable. | No accepted public Next function preserves these RxJS 7 imports and complete overload contracts. | D-039, D-040, D-049 |\n| `ObjectUnsubscribedError`
`UnsubscriptionError` | Unsupported | Use platform error and AbortSignal reason handling or an application-owned aggregate error contract. | These errors belong to removed RxJS 7 Subscription and closed-Subject internals. | D-039, D-040 |\n\n## Types\n\n| RxJS 7 surface | Disposition | Migration direction | Why | Decisions |\n| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | ------------------- |\n| `UnaryFunction`
`OperatorFunction`
`MonoTypeOperatorFunction` | Replace | Use ordinary typed functions with exact Symbol invocation or rxjs/pipe composition. | RxJS Next does not publish the pipeable-operator type family. | D-039, D-050 |\n| `Subscription`
`SubscriptionLike`
`Unsubscribable`
`TeardownLogic` | Replace | Use AbortController, AbortSignal, SubscribeOptions, and Subscriber.addTeardown inside producers. | subscribe() returns undefined and cancellation is signal-owned; no Subscription facade is published. | D-039, D-041, D-049 |\n| `ObservableInput`
`ObservableLike`
`InteropObservable`
`Subscribable`
`SubscribableOrPromise`
`ReadableStreamLike` | Replace | Use the ambient ObservableValue/platform Observable.from input contract and review custom inputs manually. | The platform conversion boundary deliberately excludes arbitrary subscribables and legacy observable interop. | D-039, D-049 |\n| `NextObserver`
`ErrorObserver`
`CompletionObserver`
`PartialObserver`
`SubjectLike`
`Connectable` | Replace | Use ambient Observer/Subscriber shapes or the concrete intentional Subject/connectable APIs; define application protocols locally when needed. | These RxJS 7 helper interfaces are not a public Next import family. | D-035, D-039, D-040 |\n| `SchedulerLike`
`SchedulerAction`
`TimestampProvider` | Replace | Use host timing APIs, Date.now-compatible narrow providers where explicitly documented, and @rxjs/test virtual host time. | There is no general public scheduler abstraction in RxJS Next. | D-012, D-033, D-039 |\n| `FactoryOrValue`
`ObservedValueOf`
`ObservedValueUnionFromArray`
`ObservedValuesFromArray`
`ObservedValueTupleFromArray`
`ObservableInputTuple`
`Cons`
`Head`
`Tail`
`ValueFromArray`
`Falsy`
`TruthyTypesOf` | Unsupported | Use inference from the accepted Next API or application-owned utility types; do not deep-import RxJS internals. | These RxJS 7 implementation-facing inference helpers are not stable Next public types. | D-039, D-040 |\n| `GroupedObservable`
`Timestamp`
`TimeInterval` | Replace | Use the structural keyed group view, structural timestamp result, or TimeInterval exported by the exact rxjs/time-interval capability as applicable. | The RxJS 7 root type imports are not preserved even where a capability exposes an intentional structural or subpath-specific result. | D-003, D-039, D-040 |\n\n## Schedulers and scheduler overloads\n\n| RxJS 7 surface | Disposition | Migration direction | Why | Decisions |\n| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------- |\n| `asap`
`asapScheduler`
`async`
`asyncScheduler`
`queue`
`queueScheduler`
`animationFrame`
`animationFrameScheduler`
`Scheduler`
`VirtualTimeScheduler`
`VirtualAction` | Replace | Use virtualizable host timing and task APIs; use @rxjs/test for deterministic tests. | RxJS Next does not publish scheduler instances or scheduler classes. | D-012, D-033, D-039 |\n| `animationFrames`
`auditTime`
`bufferTime`
`concat`
`debounceTime`
`delay`
`empty`
`endWith`
`expand`
`from`
`generate`
`groupBy`
`interval`
`observeOn`
`pairs`
`publishReplay`
`range`
`sampleTime`
`scheduled`
`shareReplay`
`startWith`
`subscribeOn`
`throwError`
`throttleTime`
`timeInterval`
`timeout`
`timeoutWith`
`timer`
`timestamp`
`windowTime` | Manual Review | Remove only an explicitly classified scheduler overload and verify ordering with host-time behavior; otherwise retain the source and stop automation. | Current capabilities use host scheduling or narrow clock providers, and the port harness adapter is not a production SchedulerLike contract. | D-012, D-033, D-034, D-039 |\n\n## Interop protocols\n\n| RxJS 7 surface | Disposition | Migration direction | Why | Decisions |\n| ------------------------------------------------------------------------------------------------------------------------------- | ------------- | ---------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- | ------------------- |\n| `observable`
`Symbol.observable`
`@@observable`
`InteropObservable` | Unsupported | Expose a platform-supported ObservableValue category or wrap the source explicitly in the active realm. | Legacy observable interop is outside the accepted platform Observable.from contract. | D-039, D-049 |\n| `objects with subscribe()`
`lowerCaseO`
`asInteropObservable`
`custom Subscribable` | Manual Review | Write an explicit application adapter that owns cancellation and terminal behavior, or choose a supported platform input category. | The 15 executable compatibility-only failures deliberately preserve this unsupported input boundary. | D-039, D-049 |\n| `foreign-realm Observable`
`cross-window Observable`
`cross-worker Observable`
`borrowed symbols on unrelated objects` | Unsupported | Initialize each realm independently and bridge values through an explicit application protocol. | RxJS does not traverse realms or promise generic Symbol borrowing onto unrelated receivers. | D-041, D-048, D-049 |\n| `Observable.lift`
`source/operator fields`
`custom Operator` | Replace | Use exact Symbol composition and the versioned derived-construction protocol through supported public capabilities. | The RxJS 7 lift/source/operator protocol is removed and is not a public Next subclass hook. | D-037, D-039, D-049 |\n\n## Deprecated and removed aliases\n\n| RxJS 7 surface | Disposition | Migration direction | Why | Decisions |\n| --------------------------------------------------------------------------------------------------------------------------------- | ------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- | ------------------- |\n| `combineAll`
`exhaust`
`flatMap`
`pipeable partition` | Replace | Use combineLatestAll, exhaustMap(identity), mergeMap, or Observable[partition] respectively. | The deprecated RxJS 7 names are not public Next Symbol identities; migration uses their canonical accepted mappings. | D-003, D-039, D-049 |\n| `empty()`
`never()` | Replace | Use EMPTY and NEVER. | The deprecated creation functions are not retained as callable Next aliases. | D-039, D-040 |\n| `mapTo`
`concatMapTo`
`mergeMapTo`
`switchMapTo`
`pluck` | Replace | Use map with a constant or property projection, or the corresponding canonical flattening Symbol with an explicit projection. | Migration may preserve behavior through exact mappings, but the deprecated pipeable function/import shape is not supported. | D-003, D-039 |\n| `pipeable combineLatest`
`pipeable concat`
`pipeable merge`
`pipeable race`
`pipeable zip`
`onErrorResumeNextWith` | Replace | Use the accepted unified or With-form exact Symbol and its documented source-array/result-selector mapping. | Legacy pipeable aliases are migration inputs, not preserved function exports. | D-003, D-039, D-049 |\n| `multicast`
`publish`
`publishBehavior`
`publishLast`
`publishReplay`
`refCount` | Manual Review | Prefer share, shareReplay, connect, or connectable with an explicit connector/reset contract; exact legacy-named Symbols remain migration evidence, not a compatibility promise. | Producer sharing, replay, reset, and ref-count semantics require explicit lifecycle review. | D-035, D-039, D-049 |\n| `new BehaviorSubject(value)`
`new ReplaySubject(size, windowTime, scheduler)`
`ColdSubject` | Replace | Use behaviorSubject(value), replaySubject({ size, maxAge }), or the advanced PerSubscriptionSubjectBase only for a justified custom hot Subject. | D-050 stabilizes lowercase factories and removes the misleading ColdSubject name without aliases. | D-035, D-036, D-050 |\n| `eachValueFrom`
`bufferedValuesFrom` | Replace | Use one of iterateEachValue, iterateBufferedValues, iterateLatestValue, or iterateNextValue from its exact Symbol subpath. | The exploratory standalone helpers were removed so buffering and dropping policy stays explicit. | D-038, D-039 |\n\n## Review rule\n\nA migration tool may automate only a cataloged **replace** mapping whose target capability and contract are also present in the migration evidence ledger. It must stop with a structured diagnostic for **manual review**, **unsupported**, **test only**, or **removed** entries. Adding a compatibility runtime, scheduler abstraction, import alias, interop protocol, or deep-import bridge requires a new accepted architecture decision.\n","isInternal":false,"tokens":3071,"sizeBytes":20640},{"name":"README.md","path":"apps/rxjs.dev/tools/README.md","rawUrl":"https://raw.githubusercontent.com/ReactiveX/rxjs/HEAD/apps/rxjs.dev/tools/README.md","title":"tools Documentation","category":"plugin-manifest","format":"markdown","content":"# AIO project tooling\n\nThis document gives an overview of the tools that we use to generate the content for the RxJS website.\n\nThe application that actually renders this content can be found in the `apps/rxjs.dev/src` folder.\nThe handwritten content can be found in the `apps/rxjs.dev/content` folder.\n\nEach subfolder in this `apps/rxjs.dev/tools/` folder contains a self-contained tool and its configuration. There is\na `README.md` file in each folder that describes the tool in more detail.\n\n## transforms\n\nAll the content that is rendered by the RxJS docs application, and some of its configuration files,\nare generated from source files by [Dgeni](https://github.com/angular/dgeni). Dgeni is a general\npurpose documentation generation tool.\n\nMarkdown files in `apps/rxjs.dev/content`, code comments in the core Angular source files and example\nfiles are processed and transformed into files that are consumed by the RxJS docs application.\n\nDgeni is configured by \"packages\", which contain services and processors. Some of these packages are\ninstalled as `node_modules` from the [dgeni-packages](https://github.com/angular/dgeni-packages) and\nsome are specific to the RxJS project.\n\nThe project specific packages are stored in the `apps/rxjs.dev/tools/transforms` folder. See the\n[README.md](transforms/README.md) for more details.\n","isInternal":false,"tokens":298,"sizeBytes":1335},{"name":"README.md","path":"apps/rxjs.dev/tools/transforms/README.md","rawUrl":"https://raw.githubusercontent.com/ReactiveX/rxjs/HEAD/apps/rxjs.dev/tools/transforms/README.md","title":"transforms Documentation","category":"plugin-manifest","format":"markdown","content":"# Overview\n\nAll the content that is rendered by the AIO application, and some of its configuration files, are\ngenerated from source files by [Dgeni](https://github.com/angular/dgeni). Dgeni is a general purpose\ndocumentation generation tool.\n\nMarkdown files in `/aio/content`, code comments in the core Angular source files and example files\nare processed and transformed into files that are consumed by the AIO application.\n\nDgeni is configured by \"packages\", which contain services and processors. Some of these packages are\ninstalled as `node_modules` from the [dgeni-packages](https://github.com/angular/dgeni-packages) and\nsome are specific to the AIO project.\n\nThe project specific packages are stored in this folder (`aio/tools/transforms`).\n\nIf you are an author and want to know how to generate the documentation, the steps are outlined in\nthe top level [README.md](../../README.md#guide-to-authoring).\n\n## Root packages\n\nTo run Dgeni, you must specify a root package, which acts as the entry point to the documentation\ngeneration.\nThis root package, in turn requires a number of other packages, some are defined locally in the\n`tools/transforms` folder, such as `tools/transforms/cheatsheet-package` and\n`tools/transforms/content-package`, etc. And some are brought in from the `dgeni-packages` node\nmodules, such as `jsdoc` and `nunjucks`.\n\n* The primary root package is defined in `tools/transforms/angular.io-package/index.js`. This package\nis used to run a full generation of all the documentation.\n* There are also root packages defined in `tools/transforms/authors-package/*-package.js`. These\npackages are used by the documentation authors when writing docs, since it allows them to run partial\ndoc generation, which is not complete but is faster for quickly seeing changes to the document that\nyou are working on.\n\n## Other packages\n\n* angular-base-package\n* angular-api-package\n* angular-content-package\n* content-package\n* links-package\n* post-process-package\n* remark-package\n* target-package\n\n## Templates\n\nAll the templates for the angular.io dgeni transformations are stored in the `tools/transforms/templates`\nfolder. See the [README](./templates/README.md).\n","isInternal":false,"tokens":483,"sizeBytes":2184},{"name":"README.md","path":"apps/rxjs.dev/tools/transforms/rxjs-decision-tree-generator/README.md","rawUrl":"https://raw.githubusercontent.com/ReactiveX/rxjs/HEAD/apps/rxjs.dev/tools/transforms/rxjs-decision-tree-generator/README.md","title":"rxjs-decision-tree-generator Documentation","category":"plugin-manifest","format":"markdown","content":"# Decision Tree Generator\n\n## Purpose\n\nManage a decision tree in YAML for choosing an operator and generate JSON to be consumed by the docs web app.\n\n## Goals\n\n- Port the first version of the decision-tree-widget into Angular\n- Flatten the JSON structure and make it easy to work with in the docs web app\n- Consume URI paths and other relevant from the docs generation task vai Dgeni\n- Keep the decision tree work scalable and easy to work with by keeping the linked list structure in the YAML tree\n\n## Prior Art\n\nVersion 1 was in the old docs site and used YAML, snabbdom, RxJS, and hyperscript-helpers. The YAML for version 1 version was ported into the new version with minor tweaks.\n\n## Tech\n\n- Node\n- TypeScript\n- TS-Node\n- Jest\n- YAML\n\n## Dependencies\n\nGenerating the JSON requires:\n\n- The decision tree YAML, located in `/src`\n- The generated `api-list.json`, which can be generated by running `pnpm run docs` at the root level of `apps/rxjs.dev`\n\n## Setup & Build\n\n```shell\npnpm install && pnpm run build\n```\n\n## Development\n\nAny changes to the YAML tree or any of the TypeScript scripts will generate a new JSON tree\n\n```shell\npnpm run watch\n```\n\n## Distribution\n\nAfter a `pnpm run build` the JSON is output to `apps/rxjs.dev/src/generated/app/decision-tree-data.json` to be consumed by the web application.\n\nThere's also an npm script at the root level of the `apps/rxjs.dev` to generate the JSON tree: `docs-decision-tree`.\n\n## Testing\n\nRun a watch task when writing tests\n\n```shell\npnpm run test:watch\n```\n\nFull test\n\n```shell\npnpm run test\n```\n\nRun coverage\n\n```shell\npnpm run test:coverage\npnpm run test:watch:coverage\n```\n\n## TODO\n\n- Consider moving this work into a Dgeni package so it can be generated in the same way the other doc information is generated\n","isInternal":false,"tokens":435,"sizeBytes":1774},{"name":"README.md","path":"apps/rxjs.dev/tools/transforms/templates/README.md","rawUrl":"https://raw.githubusercontent.com/ReactiveX/rxjs/HEAD/apps/rxjs.dev/tools/transforms/templates/README.md","title":"templates Documentation","category":"plugin-manifest","format":"markdown","content":"This folder contains the dgeni templates that are used to generate the API docs\n\nGenerally there is a template for each docType. Templates can extend and/or include\nother templates. Templates can also import macros from other template files.\n\n# Template inheritance\n\nWhen extending a template, parent must declare blocks that can be overridden by the\nchild. The template extension hierarchy looks like this (with declared blocks in parentheses):\n\n- layout/base.template.html (base)\n - module.template.html\n - layout/api-base.template.html (jumpNav, jumpNavLinks, whatItDoes, infoBar, securityConsiderations,\n deprecationNotes, howToUse, details)\n - class.template.html\n - directive.template.html\n - enum.template.html\n - var.template.html\n - const.template.html\n - let.template.html\n - decorator.template.html\n - function.template.html\n - interface.template.html\n - type-alias.template.html\n - pipe.template.html\n\n# Doc Properties\n\nIt is useful to know what properties are available on each doc type when working with the templates.\nThe `typescript` Dgeni package is now written in TypeScript and there is a class for each of the types of\nAPI document. See https://github.com/angular/dgeni-packages/tree/master/typescript/src/api-doc-types.\nThis is a good place to go to see what properties you can use in the templates.","isInternal":false,"tokens":290,"sizeBytes":1368},{"name":"README.md","path":"packages/migrate/README.md","rawUrl":"https://raw.githubusercontent.com/ReactiveX/rxjs/HEAD/packages/migrate/README.md","title":"migrate Documentation","category":"plugin-manifest","format":"markdown","content":"# `@rxjs/migrate`\n\nDeterministic source-migration tools used by the RxJS 9 agent-first\nmigration workflow. The current well-tested path migrates RxJS 7\n`TestScheduler` marble specs from Mocha/Chai to ordinary Vitest specs that call\n`rxTest` directly. The engine is not a complete migration product and does not\nchoose lifecycle semantics; see\n[`docs/MIGRATION_TOOLING_DESIGN.md`](docs/MIGRATION_TOOLING_DESIGN.md).\n\nThe package separates two concerns:\n\n- RxJS semantics: `TestScheduler.run` to `rxTest`, pipeable operators to exact\n Symbol calls, and reviewed argument adapters.\n- Test framework syntax: an optional Mocha/Chai-to-Vitest adapter. Other\n source and target frameworks can supply the same small `FrameworkAdapter`\n interface, or preserve their existing framework unchanged.\n\nThe semantic transform also operates on production TypeScript containing\nRxJS 7 `pipe(...)` expressions. It does not require a test framework or a\n`TestScheduler` declaration.\n\n## CLI\n\nStart with a dry run:\n\n```sh\nnpx rxjs-migrate \\\n --source-root . \\\n --source-repo https://github.com/example/project \\\n --source-sha abc123 \\\n --mode cold \\\n --framework mocha-chai-vitest \\\n test/example-spec.ts\n```\n\nThe command writes nothing unless `--write --out-dir ` is present.\nWritten files are normal, locally named source files. They are meant to be\nreviewed, checked in, and maintained by the destination project; there is no\nruntime generator. Successful and refused batches are emitted as versioned\nJSON with the engine and capability-registry versions. Exit codes distinguish\nsuccess (`0`), a structured migration refusal (`1`), invalid arguments (`2`),\nand operational failure (`3`). A refused batch writes no files.\n\nUse `--framework preserve` for Jest, Node test runner, another target, or a\nframework migration handled by another tool. The JavaScript API accepts a\ncustom `FrameworkAdapter` when syntax conversion should happen in the same\npass.\n\n## JavaScript API\n\n```ts\nimport { defaultCapabilityRegistry, migrateTestSource, type FrameworkAdapter } from '@rxjs/migrate';\n\nconst result = migrateTestSource(source, {\n mode: 'cold',\n capabilityRegistry: defaultCapabilityRegistry,\n frameworkAdapter: myFrameworkAdapter satisfies FrameworkAdapter,\n provenance: {\n repository: 'https://github.com/example/project',\n sha: 'abc123',\n path: 'test/example-spec.ts',\n },\n});\n```\n\n`defaultCapabilityRegistry` is a versioned, fixture-backed contract, not a\nclaim of complete RxJS 7 compatibility. A custom registry must use the same\nschema and name the installed engine version; incompatible registries are\nrefused without changing source bytes. Unsupported constructs remain visible\nas diagnostics instead of being hidden behind compatibility helpers.\n\n## Mechanically supported subset\n\nThe default registry currently proves direct, unshadowed `pipe(...)` calls for\n`filter`, `map`, `takeUntil`, `bufferCount`, `concatMap`, `concatAll`,\n`switchAll`, `debounceTime`, `audit`, and `auditTime`, subject to each mapping's\npublished arity and overload preconditions. The registry is the authoritative\nmachine-readable list. Aliases are tracked, while shadowed bindings, mixed\nunsupported pipelines, scheduler overloads, malformed input, and unsupported\nframework assertions are refused or preserved with structured findings.\n\nThe package ships no MCP binary, export, or runtime dependency. D-046 keeps\nthe library and dry-run-first CLI as the only deterministic engine surfaces.\n\nThe representative agent-workflow matrix and its deliberately bounded claims\nare documented in\n[`docs/MIGRATION_QUALIFICATION.md`](docs/MIGRATION_QUALIFICATION.md).\nLive harness qualification is separate from deterministic engine correctness.\n\n## Contract and Skill integrity\n\n`parseMigrationContractManifest` validates the versioned migration decision\nrecord. `assessMigrationContractReadiness` separately reports unresolved\nlifecycle choices, approvals, diagnostics, verification, and blockers so\nschema validity is never mistaken for completion.\n\nThe Node-only `@rxjs/migrate/skill` subpath computes and verifies the canonical\nSkill's deterministic SHA-256 content descriptor and manages generated harness\ndiscovery copies without creating a second authored workflow.\n\nInstall the canonical Skill into a repository with the package command:\n\n```sh\nnpx rxjs-migrate-skill install --harness codex --project-root .\n```\n\nUse `--harness cursor` for Cursor; Codex and Cursor share the open\n`.agents/skills` placement. Use `--harness claude` for Claude Code's\n`.claude/skills` placement. The same command supports `check`, `update`, and\n`remove`. It refuses to overwrite or remove local modifications unless the\ndeveloper supplies `--force`, and each installed copy records its package\nversion and canonical digest in `.rxjs-migrate-skill.json`.\n\n## Review requirements\n\nEvery migrated test should contain a direct `await rxTest(...)` call. Choose\n`cold()` only for producer-per-subscription evidence; use `observable()` when\nthe test should exercise the constructor installed at\n`globalThis.Observable`. Review scheduler arguments, multiple observations,\nsharing, ref counting, cancellation, and restart behavior before accepting a\nmechanical migration.\n","isInternal":false,"tokens":1113,"sizeBytes":5241},{"name":"README.md","path":"packages/observable-polyfill/README.md","rawUrl":"https://raw.githubusercontent.com/ReactiveX/rxjs/HEAD/packages/observable-polyfill/README.md","title":"observable-polyfill Documentation","category":"plugin-manifest","format":"markdown","content":"# `@rxjs/observable-polyfill`\n\nConditional fallback for the web-platform Observable and Subscriber contracts\nused by RxJS 9.\n\n```sh\nnpm install @rxjs/observable-polyfill@next\n```\n\n```ts\nimport '@rxjs/observable-polyfill';\n```\n\nThe package preserves an existing callable `globalThis.Observable`. When the\nrealm has no implementation, it installs the RxJS fallback together with its\npaired Subscriber and supported platform methods. It does not probe a native\nimplementation for conformance, replace it, or make the platform Observable\nbehave like an RxJS 7 cold Observable.\n\nUse `getObservablePolyfillInfo()` when diagnostics need to distinguish the\nRxJS fallback from a native or foreign constructor:\n\n```ts\nimport { getObservablePolyfillInfo } from '@rxjs/observable-polyfill';\n\nconsole.log(getObservablePolyfillInfo()); // metadata for the RxJS fallback, or undefined\n```\n\nCancellation and teardown use `AbortSignal` and Subscriber lifecycle. The\npackage also conditionally supplies the supported `EventTarget.when()` surface\nwithout replacing an existing callable implementation.\n\nThe package requires Node 22.13+ and publishes one ESM implementation for\nbrowser, Webpack, import, and Node `require(esm)` resolution. Observable WPT is\npinned at an exact upstream revision under `test/wpt`; the strict gate requires\ncomplete results and exact RxJS bundle identity in every fallback realm.\n\nThis package is the platform layer. RxJS operators and intentional\nproducer-per-subscription primitives belong to the\n[`rxjs` package](https://github.com/ReactiveX/rxjs/tree/master/packages/rxjs).\n","isInternal":false,"tokens":342,"sizeBytes":1589},{"name":"README.md","path":"packages/observable-polyfill/test/wpt/README.md","rawUrl":"https://raw.githubusercontent.com/ReactiveX/rxjs/HEAD/packages/observable-polyfill/test/wpt/README.md","title":"wpt Documentation","category":"plugin-manifest","format":"markdown","content":"# Observable WPT harness\n\nThis directory runs the pinned Web Platform Tests (WPT) for the web-platform\n`Observable` against the implementation in\n`packages/observable-polyfill/src/index.ts`.\n\nThe harness is intentionally test infrastructure; conformance comes from the\nimplementation behavior it measures. The current fallback passes this pinned\nsuite. `pnpm run test:wpt` exits nonzero if any upstream test or subtest fails,\nerrors, times out, or does not run. A separately named baseline command remains\navailable for diagnosing stable behavior. Both modes are strict about\ncompleteness, provenance, and which implementation ran.\n\n## Prerequisites\n\nThe blocking WPT job runs on Node 24, and the repository engine declaration\naccepts Node 24 alongside the retained Node 18 and Node 20 development\nruntimes. pnpm 10.34.5 is the repository package manager. Confirm the\nactive versions before the first run:\n\n```sh\nnode --version\npnpm --version\n```\n\nPython 3.9 or newer is also required. `pnpm run wpt:doctor` verifies the selected\nPython interpreter and every other harness prerequisite.\n\n## What is pinned\n\n- Written Observable reference: WICG/observable `spec.bs` at\n `d74bace7cf80200a01c81cfe20961e29ac7fa3d8`. This explains the rules and helps\n diagnose failures; it is not a second executable gate.\n- WPT commit:\n `6a009d73f0d315941b90cac13a9523a2a08c631b`\n- Chrome for Testing and ChromeDriver: `150.0.7871.126`\n- WPT test URLs: `expected-test-urls.json`\n- Imported-file provenance and Git blob hashes: `provenance.json`\n- Browser archive URLs, sizes, and checksums: `browser-lock.json`\n\nOnly the 29 files in `dom/observable/tentative/`—including the\n`EventTarget.prototype.when` coverage in that directory—and this exact support\nclosure are committed:\n\n- `LICENSE.md`;\n- `common/gc.js`;\n- `interfaces/dom.idl` and `interfaces/observable.tentative.idl`;\n- `resources/testharness.js`, `resources/testharnessreport.js`,\n `resources/idlharness.js`, and the Web IDL parser file they use.\n\nThat is 37 upstream files in total. `wpt:verify-import` derives the support\nclosure from the test sources and rejects both a missing dependency and an\nunexplained extra file.\nThe much larger official WPT checkout used to run them is a sparse, shallow\ncache keyed by the WPT commit. Imported upstream files remain byte-for-byte\nunchanged under `upstream/`; all instrumentation is generated in the ignored\n`.cache/rxjs-wpt/` tree.\n\n## Proving that RxJS ran\n\nThe pinned browser is required to expose its native `Observable`,\n`Observable.prototype.subscribe`, and `EventTarget.prototype.when` in the\nwindow, dedicated-worker, and same-origin iframe realms used by this suite.\nBefore each test realm runs upstream code, the generated bootstrap:\n\n1. captures the native references and property descriptors;\n2. verifies that the native slots can be replaced in the disposable test\n realm;\n3. masks those slots and executes a synchronous bundle built directly from the\n current polyfill source;\n4. records the installed constructor, `subscribe`, and `when` identities plus\n the bundle SHA-256; and\n5. exposes a non-enumerable, test-only attestation function.\n\nEvery generated WPT URL receives exactly one named attestation subtest,\nregistered after the upstream source has established any `setup()` properties.\nThe\nreport auditor independently requires it to pass with the expected bundle hash\nand exact installed identities, and requires those identities to differ from\nthe captured native ones. For the four iframe-using URLs, that one subtest waits\nfor all nine statically reviewed child-realm accesses and verifies every child\nbefore it can pass. The auditor also rejects missing or duplicate test URLs,\nmissing worker or iframe instrumentation, different bundle identities,\nrestored native globals, and any expectation metadata that tries to allowlist\nattestation.\n\nThe iframe access patterns in the pinned suite are reviewed in `config.json`.\nChanging WPT to introduce another realm-creation pattern makes\n`wpt:verify-import` fail until that pattern and its instrumentation are\nreviewed.\n\n## Commands\n\nRun commands from the repository root:\n\n| Command | Purpose |\n| ---------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |\n| `pnpm run wpt:doctor` | Verify the vendored import, build and hash the test bundle, prepare the shadow tree, provision or verify the WPT Python environment, resolve the pinned runner/browser, and probe native exposure and replaceable descriptors. |\n| `pnpm run wpt:verify-import` | Verify provenance hashes, dependency closure, generated URL inventory, and reviewed realm patterns without running a browser. |\n| `pnpm run test:wpt` | Run every pinned URL and fail unless every upstream WPT test and subtest passes. This is the default conformance command. |\n| `pnpm run test:wpt:baseline` | Run the same attested suite but compare behavior with the checked-in known-failure baseline. This is a harness diagnostic, not conformance. |\n| `pnpm run wpt:import -- --commit <40-character-sha>` | Deliberately replace the vendored subset from an exact WPT commit and regenerate provenance and the URL inventory. |\n| `pnpm run wpt:update-expectations` | Run three complete attested suites, require identical statuses, and regenerate expectation metadata and the result baseline. |\n\nThe first browser run needs network access to populate the pinned browser and\nsparse runner caches and to create the runner's Python environment. Later runs\nreuse those exact artifacts. To prove a warm run is self-contained:\n\n```sh\nRXJS_WPT_OFFLINE=1 pnpm run test:wpt:baseline\n```\n\n`RXJS_WPT_OFFLINE=1 pnpm run test:wpt` runs strict conformance from the same\ncaches and is expected to pass for the pinned implementation and browser.\nOffline mode fails immediately if a required cached artifact is absent. Useful\ntest-only overrides are listed below. Browser runs also disable Chrome\nbackground networking, component updates, sync, metrics uploads, and pings;\nWPT test traffic remains on the official runner's local servers.\n\n| Variable | Meaning |\n| ---------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- |\n| `RXJS_WPT_CACHE_DIR` | Replace the default `.cache/rxjs-wpt` cache root. |\n| `RXJS_WPT_REPORTS_DIR` | Write run reports somewhere other than the cache's `reports/` directory. |\n| `RXJS_WPT_RUNNER_ROOT` | Use an existing WPT checkout, which must be at the pinned commit. |\n| `RXJS_WPT_PYTHON_BINARY` | Select the Python interpreter used to create the version-keyed WPT environment. |\n| `RXJS_WPT_CHROME_BINARY` and `RXJS_WPT_CHROMEDRIVER` | Use an explicit matching browser pair; both must be set. |\n| `RXJS_WPT_IMPORT_CHECKOUT` | Import from an existing WPT checkout instead of creating the temporary sparse checkout. |\n| `RXJS_WPT_ALLOW_BROWSER_DRIFT=1` | Permit a non-pinned browser version for the scheduled advisory run. Do not use this for the blocking conformance job. |\n\n## Reading results\n\nEach run writes a timestamped directory under\n`.cache/rxjs-wpt/reports/`. It contains:\n\n- `wptreport.json`: the complete structured WPT report;\n- `wpt.raw.log`: the raw log accepted by WPT's expectation updater;\n- `wpt.log`: the human-readable runner log;\n- `audit.json`: the machine-readable conformance/completeness result;\n- `status-diff.txt`: the same readable status and failure summary printed in\n the terminal;\n- `attestations.json`: the expected bundle identity recorded for every\n generated test URL.\n\nThe terminal always prints preparation and browser-execution progress, status\ncounts, attestation counts, every non-passing URL and subtest, and paths to the\nstructured report and full runner logs.\n\n`pnpm run test:wpt` succeeds only when the official runner completes, every URL\nruns exactly once, every identity attestation passes, the report is well\nformed, and every upstream result passes. `pnpm run test:wpt:baseline` retains the\nstable-result comparison for deliberate harness diagnostics. In baseline mode,\nboth an unexpected failure and an unexpected pass are mismatches. The current\nbaseline contains 52 `OK` URLs and 525 passing upstream subtests.\n\n## Updating WPT\n\nRxJS maintainers own the written-spec and WPT pins. A newer revision becomes\nthe project target only through an explicit reviewed change:\n\n1. Import an exact 40-character WPT commit with `pnpm run wpt:import -- --commit\n`.\n2. Review every vendored-file, provenance, URL-inventory, dependency-closure,\n and realm-pattern change, plus the corresponding written Observable rules.\n3. Run `pnpm run wpt:verify-import`.\n4. Update the complete-result baseline without adding any failure, skip, or\n multi-status allowance.\n5. Run `pnpm run test:wpt:baseline` and strict `pnpm run test:wpt`; both must\n report 52/52 URLs, 525/525 upstream subtests, and 52/52 exact RxJS\n attestations for the current pin, or the corresponding fully passing totals\n reviewed for the proposed pin.\n\nIf a proposed upstream revision or browser is nondeterministic or failing, it\ndoes not become the pinned target. A scheduled run against newer Chrome is\nadvisory and does not silently change the vendored tests, written reference,\nor all-pass requirement.\n\nCI runs the strict pinned conformance command as a path-filtered blocking check\nwith fixed process concurrency and a fixed wall-clock timeout. A scheduled\nadvisory job uses the current stable Chrome for Testing with browser-version\ndrift enabled. Both jobs always upload the raw report, audit, logs, URL\ninventory, and attestation identities.\n","isInternal":false,"tokens":2196,"sizeBytes":11315},{"name":"README.md","path":"packages/rxjs/README.md","rawUrl":"https://raw.githubusercontent.com/ReactiveX/rxjs/HEAD/packages/rxjs/README.md","title":"rxjs Documentation","category":"plugin-manifest","format":"markdown","content":"# `rxjs` 9 beta\n\nRxJS 9 extends the web-platform Observable with exact Symbol-keyed operators\nand factories, plus a small set of intentional RxJS primitives. It uses a\nnative `Observable` when one exists and otherwise initializes the separately\npublished `@rxjs/observable-polyfill` fallback.\n\nThis is prerelease software. Install the current beta with:\n\n```sh\nnpm install rxjs@next\n```\n\nRxJS 7 remains npm's `latest` line during the beta and continues to be\nmaintained.\n\n## Why version 9?\n\nWork on RxJS 8 began years ago and paused while Web Platform Observables were\nfinalized. RxJS 9 is a new platform-based generation, not a release of that\npaused implementation. The version communicates that architectural break and\nprevents the old RxJS 8 work from being mistaken for this product.\n\n## Use an operator\n\n```ts\nimport { ColdObservable } from 'rxjs';\nimport { map } from 'rxjs/map';\nimport { pipe } from 'rxjs/pipe';\nimport { scan } from 'rxjs/scan';\n\nconst source = new ColdObservable((subscriber) => {\n subscriber.next(1);\n subscriber.next(2);\n subscriber.next(3);\n subscriber.complete();\n});\n\nsource[pipe](\n (values) => values[map]((value) => value * 2),\n (values) => values[scan]((total, value) => total + value, 0)\n).subscribe(console.log); // 2, 6, 12\n```\n\nEach operator subpath exports its exact Symbol and installs only that\ncapability. Importing the root does not install the operator catalog.\n\n## Choose the lifecycle deliberately\n\n`new Observable(initializer)` follows the platform contract. Concurrent\nobservers share the active producer, the last observer leaving tears it down,\nand a later observer starts it again.\n\n`new ColdObservable(initializer)` creates one producer for every direct\nsubscription. Use it when producer-per-subscription behavior is part of the\napplication contract rather than assuming all Observables are cold.\n\nCancellation uses `AbortSignal`:\n\n```ts\nconst controller = new AbortController();\nsource.subscribe(console.log, { signal: controller.signal });\ncontroller.abort();\n```\n\n## ESM and Node `require()`\n\nThe package publishes one ESM implementation. Browser, Webpack, ESM import,\nand Node's `require(esm)` bridge resolve the same files and exact Symbols.\n\n```js\nconst { ColdObservable } = require('rxjs');\nconst { map } = require('rxjs/map');\n```\n\nThe bridge requires Node 22.13 or newer. It is not a CommonJS build and does\nnot support legacy CommonJS resolvers.\n\n## Documentation\n\n- [Security assurance and release verification](docs/SECURITY_ASSURANCE.md)\n- [API and import guide](docs/API.md)\n- [Migrate from RxJS 7](MIGRATION.md)\n- [Unsupported RxJS 7 surfaces](docs/UNSUPPORTED_RXJS_7_SURFACES.md)\n- [Migration evidence ledger](docs/MIGRATION_EVIDENCE_LEDGER.md)\n- [Release environments and budgets](docs/RELEASE_GATES.md)\n- [Beta.0 approval record](docs/PRERELEASE_APPROVAL.md)\n- [Contributing to the package](CONTRIBUTING.md)\n\nThe package export map in [`package.json`](package.json) is authoritative for\navailable public subpaths.\n","isInternal":false,"tokens":714,"sizeBytes":3000},{"name":"README.md","path":"packages/test/README.md","rawUrl":"https://raw.githubusercontent.com/ReactiveX/rxjs/HEAD/packages/test/README.md","title":"test Documentation","category":"plugin-manifest","format":"markdown","content":"# `@rxjs/test`\n\nImplementation-neutral virtual-time and marble testing for RxJS 9 Observable\ncontracts.\n\n```sh\nnpm install --save-dev @rxjs/test@next rxjs@next\n```\n\n```ts\nimport 'rxjs';\nimport { rxTest } from '@rxjs/test';\nimport { map } from 'rxjs/map';\n\nawait rxTest(({ cold, expectObservable }) => {\n const source = cold('-a-b-|', { a: 1, b: 2 });\n expectObservable(source[map]((value) => value * 10)).toBe('-a-b-|', {\n a: 10,\n b: 20,\n });\n});\n```\n\nUse `cold()` only when the test deliberately needs one producer per direct\nsubscription. Use `observable()` when the contract should exercise the active\nplatform Observable constructor. The package never installs a platform\nObservable for the consumer; import `rxjs` or\n`@rxjs/observable-polyfill` first when the realm does not already provide one.\n\n`rxTest` supplies scheduled work, hot/cold/platform sources, Observable and\nsubscription expectations, explicit time plans, and configurable deep-equality\nassertions. Failures use `RxTestAssertionError` and include structured assertion\ninformation.\n\nThe package requires Node 22.13+, publishes ESM only, and declares an exact peer\non the matching RxJS 9 prerelease train. The\n[`rxjs` migration guide](https://github.com/ReactiveX/rxjs/blob/master/packages/rxjs/MIGRATION.md)\nexplains how to review lifecycle choices when translating RxJS 7\n`TestScheduler.run` tests.\n","isInternal":false,"tokens":343,"sizeBytes":1378}],"systemPromptSnippet":"\n\n# RxJS Next repository guidance\n\nThis branch is the foundation for a new platform-based generation of RxJS, with\nthe working name **RxJS Next** and a probable release name of **RxJS 9**. It is\nnot an incremental RxJS 7 implementation.\n\nBefore making changes, read these documents in order:\n\n1. `docs/rxjs-next/PROJECT_CHARTER.md`\n2. `docs/rxjs-next/ARCHITECTURE.md`\n3. `docs/rxjs-next/DECISIONS.md`\n4. `docs/rxjs-next/PROJECT_PLAN.md`\n5. `docs/rxjs-next/OPEN_QUESTIONS.md`\n6. `docs/rxjs-next/COMPATIBILITY.md` when changing APIs or behavior\n\n## Required working rules\n\n- Treat the current code as an exploratory implementation, not the completed\n architecture. Preserve the distinction between current behavior, accepted\n direction, and proposals.\n- Use the native web-platform `Observable` when it exists. A polyfill must not\n replace a conforming native implementation.\n- Add RxJS behavior to the platform constructor or its prototype through\n exported Symbols. Do not add string-named RxJS methods to the platform\n `Observable` surface.\n- Export corresponding RxJS Symbols even for operators that already have a\n platform string method, such as `map` and `filter`. Preserve both forms:\n `observable.map(project)` is the platform contract and\n `observable[map](project)` is the RxJS contract. The Symbol form may delegate\n or add functionality, but it must not replace the string method; document and\n test every intentional difference.\n- Preserve the collision isolation of exact Symbol keys: unrelated code using\n the same descriptive name must not be able to overwrite an RxJS extension.\n Do not introduce `Symbol.for` keys without an accepted namespacing and\n duplicate-install decision.\n- Keep platform semantics and RxJS 7 compatibility semantics in separate\n architectural layers. In particular, do not silently make the platform\n `Observable` behave like an RxJS 7 cold observable.\n- Use `AbortSignal` and the platform `Subscriber` lifecycle as the cancellation\n foundation for the platform layer.\n- Do not assume the old RxJS 7 tests can pass unchanged. Classify every migrated\n test according to the compatibility policy in `COMPATIBILITY.md`.\n- Do not revive removed RxJS 7 internals in the platform package to make a test\n pass. Put compatibility behavior behind an explicit compatibility boundary.\n- When implementing against the living Observable specification or Web\n Platform Tests, record the exact upstream revision used.\n- Preserve RxJS 7 history. The old implementation remains an important source\n of behavioral tests, migration knowledge, and compatibility requirements.\n\n## Project-plan discipline\n\n`docs/rxjs-next/PROJECT_PLAN.md` is the active execution queue. Work on the\nsingle item marked `NEXT` unless the user explicitly changes priorities or a\nsmall prerequisite is required. Keep exactly one `NEXT` item, update the\ncompletion evidence, and append a short session-log entry when completing a\nplan item.\n\n## Architecture-change discipline\n\nUpdate the documentation in the same change when code alters any of these:\n\n- package or import boundaries;\n- native-versus-polyfill selection;\n- Symbol identity or patch installation;\n- subscription sharing, ref counting, cancellation, or teardown;\n- subclass or realm behavior;\n- compatibility guarantees;\n- public exports;\n- test or conformance gates.\n\nRecord durable decisions in `docs/rxjs-next/DECISIONS.md`. Move unresolved\nquestions into or out of `docs/rxjs-next/OPEN_QUESTIONS.md` as evidence changes.\n\n## Verification\n\nRun the narrowest relevant tests and build/type checks. Record failures\nhonestly; do not treat a passing unit test as proof of platform conformance.\nThe current known baseline is documented in `ARCHITECTURE.md`.\n\n\n{\n \"schemaVersion\": 1,\n \"packageName\": \"@rxjs/migrate\",\n \"packageVersion\": \"9.0.0-beta.0\",\n \"digestAlgorithm\": \"sha256\",\n \"digest\": \"2b5c6b52bc8060df40c48443cfb5ebb0d55da5687bb74806daf95ac4912594fa\",\n \"files\": [\n \"SKILL.md\",\n \"assets/migration-report.md\",\n \"references/assessment-and-contract.md\",\n \"references/engine-and-batches.md\",\n \"references/review-checklist.md\",\n \"references/test-migration.md\",\n \"references/verification-and-closeout.md\"\n ],\n \"installSchemaVersion\": 1,\n \"adapter\": \"agents\",\n \"compatibleHarnesses\": [\n \"codex\",\n \"cursor\"\n ],\n \"targetPath\": \".agents/skills/rxjs-next-migration\"\n}\n\n\n# RxJS Next migration report\n\nThis report summarizes the machine-readable migration contract. The manifest\nvalidated by the installed `@rxjs/migrate` schema remains the authoritative\nstructured decision and evidence record.\n\n## Scope and authority\n\n- Repository:\n- Source revision:\n- Migration boundary:\n- Authorized write paths:\n- Package manager:\n- Network policy:\n- Existing changes protected:\n- Developer/approver:\n\n## Tool and dependency identity\n\n| Item | Version or digest | Evidence |\n| ---------------------- | ----------------- | -------- |\n| Source RxJS | | |\n| Target RxJS Next | | |\n| `@rxjs/migrate` engine | | |\n| Capability registry | | |\n| Canonical Skill | | |\n| Contract schema | | |\n\n## RxJS 7 baseline\n\n| Check ID | Command | Environment | Exit | Result | Accepted pre-existing failure |\n| -------- | ------- | ----------- | ---: | ------ | ----------------------------- |\n\n## Risk and coverage assessment\n\n| Finding | Source locations | Lifecycle/behavior risk | Coverage disposition | Evidence or approval |\n| ------- | ---------------- | ----------------------- | -------------------- | -------------------- |\n\n## Target contract units\n\n| Unit ID | Source locations | RxJS 7 claim | Target lifecycle | Evidence classification | Approval | Evidence |\n| ------- | ---------------- | ------------ | ---------------- | ----------------------- | -------- | -------- |\n\n## Migration batches\n\n| Batch | Scope | Dry-run report | Diagnostics reviewed | Write approved by | Changed files |\n| ----- | ----- | -------------- | -------------------- | ----------------- | ------------- |\n\n## Diagnostics\n\n| Diagnostic ID | File/span | Disposition | Classification | Required action | Resolution or owner |\n| ------------- | --------- | ----------- | -------------- | --------------- | ------------------- |\n\n## Intentional divergences\n\n| Units | Previous claim | Approved Next claim | User impact | Evidence | Approver/time/rationale |\n| ----- | -------------- | ------------------- | ----------- | -------- | ----------------------- |\n\n## Verification\n\n| Check ID | Command | Environment | Exit | Result | Summary |\n| -------- | ------- | ----------- | ---: | ------ | ------- |\n\n## Outcome classification\n\n### Migration defects repaired\n\n-\n\n### RxJS Next product gaps\n\n-\n\n### Environment or baseline limitations\n\n-\n\n## Accepted blockers\n\n| Owner | Affected units | Reason | Evidence | Prevented outcome | Acceptance |\n| ----- | -------------- | ------ | -------- | ----------------- | ---------- |\n\n## Readiness and handoff\n\n- Manifest schema validation:\n- Readiness assessment:\n- Remaining decisions:\n- Next action and owner:\n- Measured migration outcome and limitations:\n\n\n# Assessment, baseline, and target contract\n\nUse this reference during Stages 2 through 4. Collect evidence before asking\nthe developer to choose a target contract; ask only about intent the repository\ncannot prove.\n\n## Repository assessment\n\nRecord exact file locations and the commands or tests that exercise each\nfinding. Search application source, shared libraries, tests, configuration,\nfixtures, build tools, and framework glue for these themes:\n\n| Theme | Look for | Behavioral question |\n| --------------------- | ------------------------------------------------------------------ | ----------------------------------------------------------------- |\n| Construction | `new Observable`, `defer`, custom producers, wrappers | When is producer work created and restarted? |\n| Repeated subscription | retry, refresh, fan-out, cache invalidation, multiple consumers | Must consumers run independent work or share one active run? |\n| Subjects | current/replayed values, late subscribers, terminal state | What exists before observation and what must late observers see? |\n| Ownership | captured subscriptions, `unsubscribe`, component disposal | Who cancels, with what reason, and when does upstream stop? |\n| Teardown | multiple teardown callbacks, finalizers, resource release | Does observable order matter? |\n| Timing | schedulers, timers, animation, queue ordering, virtual time | Which host timing boundary preserves the claim? |\n| Errors | selector errors, observer callback errors, late errors | Where must the error be delivered or reported? |\n| Inputs | iterables, async iterables, promises, custom subscribables | Is the value accepted by the platform conversion boundary? |\n| Composition | pipeable operators, aliases, higher-order pipelines | Is a fixture-proved Symbol mapping available for this exact form? |\n| Testing | TestScheduler helpers, framework assertions, native/polyfill setup | Which claims are real behavior and which are harness machinery? |\n\nTrace imports and helper wrappers so transitive usage is not mistaken for\nabsence. Sampling is acceptable only when its limits are named and accepted.\n\n## Coverage disposition\n\nGive every lifecycle-sensitive finding exactly one disposition:\n\n- **Covered:** a named existing test proves the relevant behavior.\n- **Characterize:** add a focused RxJS 7 test before migration.\n- **Unsupported:** no accepted Next surface can preserve the required claim;\n retain evidence and record a product gap.\n- **Accepted uncovered risk:** the developer explicitly accepts proceeding\n without the missing evidence; record approver, time, rationale, and impact.\n\nRecommend characterization for repeated subscriptions, side effects, sharing,\nlate subscribers, cancellation, teardown, timing, errors, or public API behavior\nwhen current tests do not prove the outcome.\n\n## Characterization protocol\n\nAdd the narrowest test that proves an externally meaningful claim. Prefer\nassertions over values, completion/error, producer start count, concurrent and\nlate observations, cancellation ownership, abort reason, teardown order,\nvirtual or host timing, and visible side effects. Avoid locking in irrelevant\nRxJS 7 internals.\n\nRun the new test on the unchanged RxJS 7 dependency. Record the exact command\nand result. A characterization test added after dependency migration is not an\nRxJS 7 baseline unless it is separately demonstrated against the pinned source\nenvironment.\n\n## Lifecycle decision record\n\nUse only lifecycle values accepted by the installed contract-manifest schema.\nExplain each selection in behavioral language:\n\n- active platform producer shared and ref-counted while observers exist;\n- producer work created per direct subscription through an explicit Next API;\n- intentional hot Subject behavior;\n- no producer lifecycle applies;\n- required behavior is unsupported; or\n- intent remains unresolved.\n\nDo not use a blanket “hot” or “cold” label for a platform Observable. The first\nobserver starts an active producer, concurrent observers join it, the last\nobserver leaving tears it down, and a later observer can start a new run.\n\nFor every unit, record:\n\n1. stable ID and exact source spans;\n2. current RxJS 7 claim and evidence;\n3. selected target lifecycle;\n4. compatibility/evidence classification accepted by the installed schema;\n5. one or more target claims;\n6. approval status, approver, timestamp, and rationale when required; and\n7. related diagnostics, divergences, and blockers.\n\n## Mandatory developer pauses\n\nPause rather than infer when:\n\n- both independent and shared producer behavior are plausible;\n- repeated subscriptions may implement retry, refresh, cache, or fan-out;\n- Subject replay, terminal, or late-observer behavior is unproved;\n- cancellation ownership, abort reason, or teardown order could change;\n- scheduler removal could alter ordering;\n- a custom subscribable is outside the accepted conversion boundary;\n- a public claim changes or an expectation would need to change;\n- coverage is missing or the baseline is not green; or\n- a unit remains unresolved, unsupported without acceptance, or pending\n approval in the readiness assessment.\n\nThe engine's diagnostic can identify a pause condition, but only the developer\ncan approve lifecycle intent or an intentional divergence.\n\n\n# Engine registry and migration batches\n\nUse this reference during Stages 5 and 6. `@rxjs/migrate` is a deterministic\nengine for a bounded syntax subset. It is not an autonomous repository\nmigration tool.\n\n## Consume installed contracts\n\nRead engine data from the project's installed package, not from a list copied\ninto a prompt, Skill, or harness adapter. The public API exports the default\ncapability registry, registry and manifest schemas, migration functions,\ncontract readiness assessment, and engine/schema versions.\n\nA local inspection can use the project's module runner with this shape:\n\n```js\nimport { assessMigrationContractReadiness, defaultCapabilityRegistry, migrationContractManifestSchema } from '@rxjs/migrate';\n\nfor (const capability of defaultCapabilityRegistry.capabilities) {\n // Review id, legacy/source name, target Symbol, adapter, arity,\n // preconditions, status, and fixture evidence for this exact package.\n}\n\nconst parsed = migrationContractManifestSchema.safeParse(manifest);\nif (parsed.success) {\n const readiness = assessMigrationContractReadiness(parsed.data, {\n expectedSkillDigest,\n });\n}\n```\n\nObtain `expectedSkillDigest` from the installed adapter's integrity check or\nthe Node-only `@rxjs/migrate/skill` API. Consult the installed TypeScript\ndeclarations for exact signatures. Refuse an incompatible custom registry\nrather than adapting it informally. A registry entry proves only the source\nforms, overloads, preconditions, and fixtures it names; it does not promise\ngeneral RxJS 7 compatibility.\n\n## Capability selection\n\nBefore selecting a transform, verify all of the following:\n\n- registry schema, registry version, and engine version match the installed\n package;\n- the source import binding is the one identified by the engine and is not\n shadowed or repurposed;\n- the call shape, arity, scheduler/result-selector form, and pipeline context\n satisfy every declared precondition;\n- the fixture evidence covers the intended mapping and evidence class; and\n- the migration unit already has an approved lifecycle contract.\n\nName similarity, a compatible TypeScript signature, or a green transformed\ntest is not a substitute for those checks.\n\n## Dry-run protocol\n\nInvoke the locally installed `rxjs-migrate` binary through the project's\npackage manager. Supply all required provenance. For example:\n\n```sh\nrxjs-migrate \\\n --source-root \\\n --source-repo \\\n --source-sha \\\n --mode \\\n --framework preserve \\\n \n```\n\nOmit `--mode` when the selected source does not require a lifecycle choice.\nNever let a directory name or wrapper select it implicitly. Use the package's\ndocumented framework adapter only for a separately approved framework change.\n\nWithout `--write`, the CLI returns a versioned JSON report and performs no\nwrites. Record its engine version, registry version, operation, file results,\nordered diagnostics, and exit status. The current CLI contract distinguishes\ncompleted, structured refusal, invalid arguments, and operational failure;\nread the installed package documentation for the exact numeric codes.\n\nReview every diagnostic, including source span, severity, disposition, refusal\nscope, classification, next action, and capability ID when present. A refused\nbatch must leave source and destination unchanged.\n\n## Write protocol\n\nAfter the dry run and changed paths are approved, repeat the same inputs with\nan explicit contained destination:\n\n```sh\nrxjs-migrate \\\n --source-root \\\n --source-repo \\\n --source-sha \\\n --mode \\\n --framework preserve \\\n --write --out-dir \\\n \n```\n\nThe engine plans the whole batch before writing and refuses lexical, canonical,\nor symlink path escape. Do not bypass containment or no-overwrite behavior with\nmanual bulk writes. If the reviewed destination is the current source tree,\nmake that scope and overwrite decision explicit and keep recovery possible.\n\nCompare the write report with the dry run byte for byte where contractual.\nInspect the diff for:\n\n- provenance and filenames;\n- exact Symbol imports and calls;\n- preserved unsupported source;\n- lifecycle helper selection;\n- awaited asynchronous test helpers;\n- framework preservation or the separately selected adapter;\n- retained assertions, errors, subscription claims, and local helpers; and\n- absence of hidden generators or compatibility layers.\n\nThen run the same transform again without writes. The second result must be\nunchanged with stable diagnostics. Any output or diagnostic drift is an engine\ndefect; stop the batch and preserve a reproduction.\n\n## Refusal and manual repair\n\nDo not turn refused syntax into claimed mechanical output by editing around the\ndiagnostic. Carry the finding into the contract and choose one of these paths:\n\n1. narrow the batch to independently safe units;\n2. add characterization, obtain a developer decision, and make a reviewed\n semantic edit outside the engine's claimed output;\n3. report an RxJS Next product gap; or\n4. preserve the source and accept a named blocker.\n\nManual work remains subject to the same baseline, lifecycle, review, and\nverification gates. It must not be described as fixture-proved engine output.\n\n\n# Migration closeout checklist\n\n## Authority and provenance\n\n- Repository instructions, scope, allowed writes, package manager, and network\n policy were recorded before broad changes.\n- Existing work was protected and every changed file is within the authorized\n migration boundary.\n- Source repository/revision, RxJS versions, engine version, registry version,\n and canonical Skill digest are exact and reproducible.\n- The installed Skill content matches the installed `@rxjs/migrate` package.\n\n## Baseline and coverage\n\n- Agreed build, type, lint, test, and behavior gates were run on unchanged\n RxJS 7 source.\n- Every baseline failure is either fixed or explicitly recorded as pre-existing\n with developer acceptance.\n- Each lifecycle-sensitive path is linked to existing coverage,\n characterization, explicit unsupported status, or an accepted uncovered\n risk.\n- Characterization tests passed against RxJS 7 before dependency/source\n migration.\n\n## Target contract\n\n- Every unit has stable source locations, a behavioral claim, one target\n lifecycle, an evidence classification, and supporting evidence.\n- No required unit remains unresolved or pending approval.\n- Platform sharing and producer-per-direct-subscription behavior were selected\n intentionally rather than inferred from syntax.\n- Subjects, repeated subscriptions, cancellation, teardown, timing, errors,\n and input conversion were reviewed where applicable.\n- Every intentional divergence records old and new claims, user impact,\n evidence, approver, timestamp, and rationale.\n\n## Mechanical batches\n\n- Capability decisions came from the installed versioned registry; no copied\n operator list or name-only match was used.\n- Each engine operation ran dry first with exact provenance and an explicit\n lifecycle mode when required.\n- The dry-run scope, diagnostics, and changed paths were reviewed before write.\n- Refused or unsupported source remains visible and was not smuggled through a\n partial transform.\n- Writes stayed within the approved destination and did not overwrite local\n content without explicit approval.\n- Output preserves ordinary project-owned source, direct tests, assertions,\n and the selected framework.\n- Every applied transform is parseable, type-checkable at its narrow boundary,\n and idempotent with stable diagnostics.\n\n## Verification and handoff\n\n- Focused characterization/migrated tests and all agreed project gates were\n run with exact commands, environments, exit codes, and results.\n- Failures are classified as migration defects, product gaps, intentional\n divergences, baseline/environment issues, or unresolved—not relabeled for a\n green report.\n- No test was weakened, skipped, deleted, or replaced without explicit\n developer approval and a recorded contract change.\n- Schema validation and readiness assessment were both run; one is not being\n used as a substitute for the other.\n- All diagnostics are resolved, carried with an owner, or represented by an\n explicitly accepted blocker.\n- The final report states measured outcomes and limitations without claiming\n general automatic migration.\n\n\n# TestScheduler and marble-test migration\n\nUse this reference only for selected RxJS 7 `TestScheduler` or marble tests.\nPreserve behavioral evidence and the project's ordinary test conventions.\n\n## Preserve the outer framework\n\nKeep the project's `describe`, `it`, `test`, hooks, assertion library, spies,\nand configuration by default. Treat a requested framework change as a separate\nadapter over the same migrated test body. If the installed engine does not\nsupport the requested source/target pair, preserve the framework and report\nthe conversion as manual work rather than guessing globals or assertions.\n\nEmit direct, readable test declarations. Materialize selected parameterized\ncases when necessary; do not introduce a runtime loop, hidden registry,\ngenerated location shim, or generator warning.\n\n## Preserve provenance and claims\n\nRecord the source repository, exact revision, and source path for every\nmigrated file. State the old case's behavioral claim before editing it. Keep\ncase-level comments only where they explain a real lifecycle, scheduler,\ncancellation, or divergence decision.\n\nTreat analyzer fingerprints as duplicate candidates, never automatic deletion.\nConsolidate only when public API/overload, lifecycle, values, timing, completion,\nerrors, cancellation, subscription claim, and relevant type behavior all\nmatch. Retain links to every original case in the manifest/report.\n\n## Convert harness structure\n\nReplace a supported `TestScheduler.run(...)` wrapper with one direct `rxTest`\ncall. Remove a scheduler variable, constructor, matcher adapter, or setup hook\nonly when it has no other responsibility. Return or await the `Promise`\nfrom `rxTest` through the outer test.\n\nPreserve the meaning of supported helpers:\n\n- `cold()` represents producer-per-subscription evidence;\n- `hot()` represents a subject-like absolute timeline;\n- `observable()` represents the shared, ref-counted platform producer;\n- `expectObservable()` retains cancellation from the subscription marble;\n- `expectSubscriptions()` describes observer subscriptions for cold sources\n and producer activation windows for platform sources;\n- `time()` and `animate()` use the `@rxjs/test` virtual host boundary; and\n- `flush()` is asynchronous and must be awaited from an `async` callback.\n\nRefuse or manually classify direct scheduler state, methods used outside the\nsupported run callback, scheduler subclasses, implementation-only queue/frame\nassertions, or unsupported framework assertions. Do not erase them as obsolete\nwithout a reviewed evidence classification.\n\n## Convert composition through the registry\n\nFor each RxJS 7 pipeable call, look up the exact installed capability entry and\napply only its declared Symbol target, argument adapter, arity, preconditions,\nand fixture-proved source shape. Convert a supported sequence into successive\nexact-Symbol calls and import those Symbols from the declared modules.\n\nDo not copy a table of operator mappings into project guidance. Do not use a\nplatform string method because its description matches an RxJS 7 operator.\nPreserve unsupported overloads and mixed pipelines with their diagnostics.\n\nUse an ambient/global `Observable` when the accepted target contract requires\nplatform construction. Do not import the constructor from a polyfill merely to\nmake a test pass.\n\n## Review lifecycle and realms\n\nKeep a producer-per-subscription baseline visibly separate from platform\ncoverage. For the platform lifecycle, test first activation, concurrent join,\nlate observation, individual abort, final abort/teardown, and later restart as\napplicable.\n\nRun the same platform claim against fallback and native implementations where\nthe project supports both. Initialize each in an isolated process, worker,\nwindow, or iframe before importing RxJS extensions and tests. If the realm has\nno native `Observable`, record native mode as unavailable; never install the\nfallback and label the result native.\n\nRemove scheduler arguments only when the installed target capability and its\nfixtures prove a host-timed mapping that `rxTest` virtualizes. Preserve original\nerror values and ordinary non-marble assertions. If product behavior fails a\nfaithful migrated claim, retain the evidence as a product gap rather than\nchanging production code or weakening the expectation.\n\n\n# Verification, repair, and closeout\n\nUse this reference during Stages 7 and 8. Outcome evidence outranks source\nshape.\n\n## Verification ladder\n\nRun checks from narrowest to broadest so a failure remains diagnosable:\n\n1. parse and format the changed files;\n2. run focused type checks;\n3. run characterization and directly migrated tests;\n4. run the affected package or workspace build, type, lint, and test gates;\n5. run agreed integration, browser, native/polyfill, or repository-wide gates;\n6. repeat any command whose environment was changed during diagnosis.\n\nRecord the exact command, relevant environment facts, exit code, status, and a\nconcise summary. “Passed locally” without a command and environment is not a\nverification record.\n\nFor lifecycle-sensitive code, verify the contract actually selected:\n\n- producer activation count and restart;\n- concurrent and late observation;\n- individual and final cancellation;\n- abort reason and upstream closure;\n- Subject current/replay/terminal behavior;\n- teardown ordering;\n- time and scheduling order;\n- error delivery and late/unhandled error behavior; and\n- input conversion acceptance or explicit refusal.\n\n## Failure classification and response\n\n| Class | Meaning | Required response |\n| ---------------------- | -------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------- |\n| Migration defect | The edit broke syntax, types, test intent, mapping, or selected contract | Repair a small batch and rerun affected gates |\n| RxJS Next product gap | The accepted target surface cannot satisfy preserved evidence | Keep evidence visible; report the product gap |\n| Intentional divergence | Approved Next behavior differs from the RxJS 7 claim | Record old/new claims, impact, evidence, and approval before changing expectations |\n| Baseline/environment | The failure existed before migration or the required runtime/tool is unavailable | Preserve its original status and record the limitation or accepted failure |\n| Unknown | Evidence does not yet identify the cause | Investigate or pause; never relabel for convenience |\n\nAllowed repairs clarify or correct migrated code, strengthen characterization,\nor fix a demonstrated migration defect while preserving the approved contract.\n\nThe following require a developer pause:\n\n- deleting, skipping, quarantining, or weakening a test;\n- changing a public behavioral claim;\n- adding a local operator, scheduler, compatibility facade, or assertion shim;\n- changing platform behavior to imitate RxJS 7;\n- broad dependency or configuration changes beyond reviewed scope; or\n- accepting a red or unrun required gate.\n\n## Manifest closeout\n\nBuild the manifest against the exact schema exported by the installed package.\nAt minimum, record the schema and engine identity required by that version,\ncapability-registry version, canonical Skill digest, exact source and target\nRxJS versions, baseline checks, migration units, diagnostics, intentional\ndivergences, verification results, and blockers.\n\nStructural validity answers only “is this shaped correctly?” Run the separate\nreadiness assessment to detect unresolved lifecycle units, pending approvals,\nunresolved/refused diagnostics, unapproved divergences, missing or red gates,\nidentity mismatches, and unaccepted blockers.\n\nAn accepted blocker must name:\n\n- its owner and reason;\n- affected units;\n- supporting evidence;\n- the behavior, environment, or release claim it prevents; and\n- explicit developer acceptance.\n\nDo not use a blocker to hide an unexplained regression. A migration may close\nas `ready-with-accepted-blockers` only when the installed readiness assessment\nreturns that state and the human-readable report makes the limitations clear.\n\n## Final handoff\n\nUse the report asset to summarize:\n\n- scope and provenance;\n- installed engine, registry, Skill, source RxJS, and target RxJS identity;\n- RxJS 7 baseline and characterization evidence;\n- lifecycle decisions and approvals;\n- changed source and tests by coherent batch;\n- exact final commands and results;\n- diagnostics and how each was resolved or carried;\n- repaired migration defects;\n- remaining product gaps, divergences, and environment limits; and\n- blocker ownership and next actions.\n\nDo not report “automatic migration succeeded.” State the measured project\noutcome and its limits.\n\n\n---\nname: rxjs-next-migration\ndescription: Migrate an RxJS 7 application, library, or test suite to RxJS Next through an agent-led workflow that establishes a green behavioral baseline, makes Observable lifecycle choices explicit, uses @rxjs/migrate only for bounded fixture-proved rewrites, repairs without weakening evidence, and records a versioned migration contract. Use for repository assessment, migration planning or execution, lifecycle review, TestScheduler conversion, or migration closeout.\n---\n\n# RxJS 7 to RxJS Next migration\n\nTreat this as reviewed project work, not a codemod run. The objective is an\nintentional RxJS Next contract backed by the project's own build and behavior\nevidence. A transformed file, a clean diff, or one passing test is not proof\nthat the migration is complete.\n\nWork through all eight stages in order. Re-enter an earlier stage whenever new\nevidence changes scope, coverage, or lifecycle intent. Keep the developer\ninvolved at every explicit pause.\n\n## Non-negotiable rules\n\n- Read and obey repository-local instructions before acting. Protect existing\n work and stay within the authorized repository and paths.\n- Establish the RxJS 7 baseline before changing dependencies or source.\n- Never infer platform sharing versus producer-per-direct-subscription behavior\n from syntax, filenames, operator names, or a currently passing output.\n- Use the installed engine's versioned registry and schemas as authority. Do\n not reconstruct capability mappings from this Skill or from memory.\n- Run the deterministic engine without writes first. A refusal is a successful\n safety outcome, not permission to improvise a mechanical rewrite.\n- Preserve the project's test framework by default. Select a framework adapter\n only when the developer asked for that separate conversion.\n- Do not weaken, skip, delete, or replace a behavioral expectation merely to\n make the migrated suite green.\n- Do not add RxJS 7 compatibility shims, string-named platform methods, local\n substitute operators, or runtime generators unless the developer separately\n authorizes that product work.\n- Keep changes in small coherent batches. Review and verify each batch before\n widening the scope.\n- Do not call a migration complete while a required command is unknown,\n unapproved, skipped, or red without an explicitly accepted blocker.\n\n## Working record\n\nCreate or locate a checked-in migration contract manifest and a concise\nhuman-readable report. Use the schema exported by the installed\n`@rxjs/migrate`; schema validity and migration readiness are separate checks.\nUse [assets/migration-report.md](assets/migration-report.md) for the report.\n\nFor every migration unit, preserve source locations and record:\n\n- its current RxJS 7 behavioral claim;\n- the target lifecycle selected by the developer;\n- its evidence classification and supporting tests;\n- approval state, diagnostics, and any intentional divergence; and\n- verification or a named blocker.\n\n## Stage 1: Establish authority and scope\n\n1. Locate repository instructions, package and workspace metadata, lockfiles,\n CI configuration, RxJS versions, build/test commands, and current working\n tree state.\n2. Identify the repository root, migration boundary, permitted writes,\n package manager, network policy, and candidate verification commands.\n3. Record the installed `@rxjs/migrate` version and canonical Skill digest.\n If the installed Skill does not match its package, stop and synchronize it\n before trusting these instructions.\n4. State the proposed read, write, dependency, and command scope before broad\n changes.\n\nPause for the developer if the target repository or allowed scope is unclear,\nexisting changes overlap the migration, or destructive, networked, external,\nor broader actions require new authority.\n\nExit only when the scope, allowed writes, package manager, and candidate gates\nare recorded.\n\n## Stage 2: Assess usage, lifecycle risk, and coverage\n\nInventory installed RxJS versions and import forms, then locate Observable\nconstruction, custom producers, Subjects, subscription ownership, repeated\nsubscriptions, retry/refresh/cache paths, schedulers and timing, test helpers,\ninterop inputs, cancellation, teardown, and error handling. Include direct and\ntransitive operator usage.\n\nFor each lifecycle-sensitive path, link exact source evidence and mark it as:\n\n- covered by an existing baseline;\n- requiring a characterization test;\n- explicitly unsupported; or\n- an uncovered risk the developer accepts.\n\nProduce a risk and coverage report before proposing rewrites. Read\n[references/assessment-and-contract.md](references/assessment-and-contract.md)\nfor the inventory and characterization protocol.\n\nExit only when every in-scope lifecycle-sensitive use has one recorded\ncoverage disposition. Missing coverage is not evidence that behavior is safe.\n\n## Stage 3: Establish the green RxJS 7 baseline\n\nRun the agreed build, type, lint, unit, integration, and behavior checks against\nthe unchanged RxJS 7 project. Record exact commands, environment facts, exit\ncodes, and concise results.\n\nAdd focused characterization tests where Stage 2 found material gaps. Protect\nobservable values, completion/error behavior, producer multiplicity,\ncancellation, abort reasons, teardown ordering, timing, and externally visible\nsubscription effects as applicable. Every characterization test must pass on\nRxJS 7 before migration begins.\n\nPause if a starting gate fails. Diagnose it and ask the developer whether to\nfix it first, narrow scope, or record it as an accepted pre-existing failure.\nNever silently reclassify it as a migration regression or ignore it.\n\nExit only with a green baseline or explicit approval for each named\npre-existing failure, plus green characterization tests.\n\n## Stage 4: Classify and approve the target contract\n\nDivide the scope into stable migration units. For each unit, record one target\nlifecycle using the values accepted by the installed manifest schema and one\nevidence classification. Use repository evidence and\n[references/assessment-and-contract.md](references/assessment-and-contract.md)\nto explain the choice.\n\nThe engine may identify risk but cannot choose lifecycle intent. `unresolved`\nis a stop state. Pause for the developer when either platform-shared behavior\nor producer-per-direct-subscription behavior is plausible, or when Subject\nsemantics, cancellation, scheduler ordering, error behavior, interop, or a\npublic behavior change is not proved.\n\nIntentional divergences require a concrete old claim, proposed Next claim,\nuser impact, evidence, and developer approval. Validate the manifest\nstructurally, then run the installed readiness assessment. Do not proceed with\na batch containing unresolved intent or required pending approval.\n\nExit only when the developer has approved every ambiguous choice and\nintentional divergence needed for the next batch.\n\n## Stage 5: Plan and dry-run bounded engine changes\n\nInspect the installed capability registry and select only entries whose\nversion, source form, arity, preconditions, and executable evidence match the\napproved unit. Do not infer support from a familiar name. Follow\n[references/engine-and-batches.md](references/engine-and-batches.md).\nWhen the batch contains RxJS 7 marble tests, also read\n[references/test-migration.md](references/test-migration.md).\n\nRun `rxjs-migrate` without `--write` using explicit provenance and, when\nrequired, the approved `cold` or `platform` mode. Preserve the current test\nframework unless a supported adapter was separately selected. Capture the\nversioned JSON report, changed paths, structured diagnostics, and exit code.\n\nPause when a diagnostic requires review or refuses a transform, when output\nwould escape authorized paths, when source does not match the capability\nevidence, or when batch size or semantic reach exceeds the reviewed scope.\nNever conceal unsupported segments inside a partially transformed pipeline.\n\nExit only after diagnostics and changed-file scope are reviewed and the\ndeveloper has approved any newly broadened batch.\n\n## Stage 6: Apply one small migration batch\n\nApply only the reviewed dry-run plan. Require an explicit write destination\ninside the authorized project and preserve source provenance. Do not overwrite\nexisting output without specific approval. Review the resulting diff before\nadditional edits.\n\nFormat through the project's normal tools. Ensure ordinary project-owned\nsource and direct test declarations remain; do not leave dynamic generators,\nhidden case registries, or compatibility assertion layers in the result.\n\nImmediately check parsing, the narrowest useful type boundary, and engine\nidempotence. Re-running the same transform must produce no new source change\nand stable diagnostics. If it does not, restore the affected batch to the\nreviewed starting point and report an engine defect.\n\nExit only when the batch parses, type-checks at its narrow boundary, is\nidempotent, and every diagnostic is resolved, carried forward, or escalated.\n\n## Stage 7: Build, test, diagnose, and repair\n\nRun focused characterization and migrated tests first, then the agreed project\ngates. Classify every failure as a migration defect, RxJS Next product gap,\nintentional divergence, environment/baseline issue, or still-unknown result.\nUse [references/verification-and-closeout.md](references/verification-and-closeout.md)\nfor the repair rules.\n\nRepair migration defects in a small batch and repeat the relevant gates. For a\nproduct gap, preserve the failing evidence and report it; do not disguise it\nwith a local replacement. For an intentional divergence, change an expectation\nonly after the manifest records approved new behavior and user impact.\n\nPause before any repair that changes public behavior, weakens evidence,\nexpands writes, changes dependencies beyond the reviewed plan, needs external\naccess, or introduces a compatibility layer.\n\nExit only when agreed gates pass or each remaining red result has a named,\nevidenced, explicitly accepted blocker.\n\n## Stage 8: Close out and hand off\n\nUpdate the contract manifest and report with exact source and target versions,\nengine version, capability-registry version, canonical Skill digest, baseline,\nunits, diagnostics, divergences, final commands/results, and blockers. Validate\nthe manifest with the installed schema and assess readiness separately.\n\nReview [references/review-checklist.md](references/review-checklist.md). Report:\n\n1. what behavior and lifecycle contract changed;\n2. what source and tests changed;\n3. the exact gates run and their results;\n4. migration defects repaired versus product gaps retained;\n5. approved divergences and environment limitations; and\n6. remaining blockers, owners, evidence, and acceptance.\n\nClaim completion only when readiness is `ready`, or\n`ready-with-accepted-blockers` when the developer intentionally chose that\noutcome. Otherwise hand off the migration as incomplete with the next concrete\ndecision or action.\n\n\n# RxJS Next migration workflow qualification\n\n## Status\n\nP0.M5 is complete. All four checked-in Codex/ChatGPT runs pass the pinned seed,\nbehavior, authority, artifact, and semantic outcome gates: three end in an\napproved completed migration and the weak-coverage/unsupported repository ends\nin its required safe stop. Per D-047, this P0 qualification is intentionally\nlimited to Codex/ChatGPT. It does not claim Claude Code or Cursor outcome\nqualification, cross-harness parity, or general automatic migration safety.\n\nP5.2 is also complete by closure audit. Its planned mechanical and semantic\napplication-validation outcome was already satisfied by the P0.M3 deterministic\nfixtures, P4.4 accepted contract fixtures, and P0.M5 four-repository outcome\nmatrix. The closure audit reruns those offline gates and maps them to the\npackage-local migration guide; it does not spend another live-model cycle or\nexpand the original qualification claim.\n\n## P5.2 guide-to-evidence map\n\n| Migration-guide step | Representative evidence |\n| --------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Establish a green RxJS 7 baseline | Four pinned seed repositories, framework-specific baseline commands, immutable dependency descriptors, and executable seed oracles |\n| Inventory affected surfaces and coverage gaps | Application/library scenarios spanning Vitest, Mocha, Jest, strong and weak coverage, scheduler, interop, Subject, sharing, and repeated-subscription behavior |\n| Select an explicit lifecycle contract | Cold-preserving, platform-shared, mixed, and unsupported contract manifests with developer-owned decision vectors |\n| Apply only proven mechanical changes | Versioned capability registry, exact transform fixtures, compilation, idempotence, structured diagnostics, and refusal-safe batch writes |\n| Review semantic boundaries | Held-out producer multiplicity, sharing/ref counting, cancellation, teardown, timing, errors, input conversion, Subject state, and restart assertions |\n| Finish green or stop safely | Three completed migrations pass target build and protected behavior; the weak unsupported repository stops before target installation or migration writes |\n\nThe checked-in P4.4 contract fixtures provide a smaller executable cross-check\nfor all four guide outcomes: `cold-preserving`, `platform-shared`,\n`subject-hot`, and `safe-stop`. A lifecycle-swap negative control prevents a\nsyntactically valid rewrite from being counted as a semantic success.\n\n## Evidence boundary\n\nThe qualification has two distinct lanes:\n\n- deterministic engine fixtures prove exact transforms, structured refusals,\n compilation, idempotence, behavior, path containment, and package contracts;\n- agent scenarios permit source variation but require the same behavioral,\n approval, diagnostic, test-integrity, and artifact gates.\n\nA passing engine fixture is not a passing agent migration. A plausible agent\nreport is not a passing run until its seed identity, chronology, commands,\nmanifest, protected tests, held-out behavior, and captured artifact digests\npass the offline grader.\n\nEach committed record has five hashed artifacts: the exact user prompt and\nfinal response retained as `conversation.md`, the contract manifest, patch,\ncommand results, and final report. The command-results artifact, patch, and\nrecorded observed-authority actions provide the reviewable command/tool\nevidence. Full host event streams were not retained for the first three runs,\nso the conversation artifact must not be described as a complete tool-call\ntranscript. The fourth run was repeated after authority controls were tightened;\nonly its passing record belongs to the closed matrix.\n\n## Representative repositories\n\nThe four immutable seed trees live under\n`packages/migrate/test/agent/fixtures`. Each pins RxJS `7.8.1`, its dependency\ndescriptor, a complete pnpm lockfile, runnable framework-specific baseline\ncommands, and the complete seed-tree digest.\n\n| Scenario | Layout | Framework | Coverage | Target contract | Expected result |\n| -------------------------- | ----------- | --------- | -------- | ----------------------------- | --------------- |\n| `app-cold-strong` | Application | Vitest | Strong | Preserve direct cold behavior | Complete |\n| `app-platform-strong` | Application | Mocha | Strong | Intentional platform sharing | Complete |\n| `library-mixed-strong` | Library | Jest | Strong | Mixed approved contracts | Complete |\n| `library-weak-unsupported` | Library | Vitest | Weak | Unsupported behavior retained | Safe stop |\n\nTogether they cover positive evidence plus a negative or refusal control for:\n\n- `ColdObservable` producer independence;\n- platform activation, sharing, ref counting, final abort, and restart;\n- Subjects and late observers;\n- cancellation and abort ownership;\n- teardown order;\n- scheduling and timing;\n- error delivery;\n- iterable, async iterable, Promise, custom-subscribable, and legacy interop;\n- repeated subscriptions and cache behavior;\n- unsupported APIs;\n- missing coverage; and\n- mixed supported and unsupported pipelines.\n\nThe held-out baseline suite loads the exact RxJS `7.8.1` runtime from the\nworkspace's pinned pnpm store path rather than resolving the workspace RxJS\nNext package.\n\n## Outcome gates\n\nThe versioned agent grader evaluates 14 semantic gate families and fails a run\nwhen any family fails:\n\n1. compilation;\n2. RxJS 7 baseline integrity;\n3. baseline/characterization/migration chronology;\n4. contract-manifest readiness;\n5. required diagnostic handling;\n6. intentional-divergence disclosure and approval;\n7. protected-test integrity;\n8. required engine actions and refusals;\n9. implemented/declared manifest consistency;\n10. required artifact integrity;\n11. held-out behavior;\n12. developer-owned contract decisions;\n13. observed read, write, command, network, and install authority; and\n14. timely safe-stop behavior without later writes.\n\nThe captured-record verifier independently recomputes artifact hashes, rejects\npath escape and symlinks, checks harness/model/authority and seed identities,\nand requires the closed four-run Codex matrix. It compares semantic safety and\ndecision vectors rather than exact patches.\n\n## Live qualification matrix\n\nThe closed matrix contains one passing record for each representative\nrepository, for four qualified Codex/ChatGPT outcomes. Claude Code and Cursor\nretain tested Skill installation adapters from P0.M4 but are not live\noutcome-qualified in P0:\n\n| Scenario | Codex/ChatGPT |\n| -------------------------- | :-----------: |\n| `app-cold-strong` | ✓ |\n| `app-platform-strong` | ✓ |\n| `library-mixed-strong` | ✓ |\n| `library-weak-unsupported` | ✓ |\n\nEach run captures the user-visible prompt/final response, patch, contract\nmanifest, command results, and final report. The live command is intentionally\nnot part of ordinary CI because it invokes an external model service. Offline\ngrading of committed run artifacts is deterministic and belongs in normal\nvalidation.\n\n## Current measured result\n\nThe completed evidence passes:\n\n- 4/4 seed identities and dependency descriptors;\n- 12/12 required behavior categories with positive and negative/refusal\n controls;\n- 4/4 pinned RxJS 7 seed oracles;\n- 14/14 agent outcome gate families; and\n- four committed qualification records with 20/20 SHA-256-bound artifacts,\n plus mutation controls for digest drift, missing artifacts, and unexpected\n matrix membership.\n\nLive result: **4/4 passed** using Codex `0.146.0-alpha.3.1`,\n`gpt-5.6-sol` with medium reasoning, and Skill/engine version\n`8.0.0-alpha.14`. `app-cold-strong`, `app-platform-strong`, and\n`library-mixed-strong` completed their approved migrations;\n`library-weak-unsupported` produced the expected safe stop before target\ninstallation or migration writes.\n\n## Claim limits\n\nThis 4/4 result is a bounded qualification snapshot, not a statistical\nreliability estimate and not proof that arbitrary RxJS 7 repositories migrate\nautomatically. It supports claims only for the checked-in scenarios, versions,\ncapabilities, safety gates, retained artifacts, and recorded Codex/ChatGPT\nconfiguration. Claude Code and Cursor outcome parity remains unmeasured.\nUnsupported syntax, uncharacterized behavior, unresolved lifecycle intent,\nframework features outside the adapters, and product gaps must remain visible\nand may require a safe stop.\n\n\n# RxJS Next agent-first migration tooling design\n\n## Executive summary\n\nRxJS 7-to-Next migration is an agent-led engineering workflow, not a codemod\nrun. The primary product is one portable Agent Skill that assesses a project,\nestablishes an RxJS 7 behavioral baseline, makes every lifecycle choice\nexplicit, invokes deterministic transforms only inside their proved boundary,\nand works with the developer until the agreed build and test gates pass or a\ndocumented blocker is accepted.\n\n`@rxjs/migrate` is the deterministic engine used by that workflow. It owns\nversioned analysis, capability data, source transforms, framework adapters,\nstructured diagnostics, and safe file operations. It never decides whether an\napplication should adopt the platform Observable's shared active producer or\nretain producer-per-direct-subscription behavior. It also never claims that a\nsyntactically transformed project is migrated.\n\nThe canonical Skill source is `packages/migrate/skill`. It is released and\nversioned with `@rxjs/migrate`. Harness-specific installation places the same\nvalidated Skill content where Codex, Claude, or Cursor discovers it; those\nplacements and their invocation/permission notes are adapters, not separately\nauthored workflows.\n\nThe current source-content MCP prototype is not part of the accepted product.\nIts two tools mirror the local library and CLI without adding a capability\nthat a local coding agent needs. P0.M3 removes that release surface. A future\nMCP requires a new decision backed by a concrete need that cannot be met by\nthe versioned CLI, library API, Skill resources, or the host agent's local\ntools.\n\n## Status and audience\n\nThis document is the controlling product and technical design for P0.M3\nthrough P0.M5. Its primary audience is RxJS maintainers implementing and\nqualifying the migration experience. Skill authors, framework-adapter authors,\nand release reviewers are secondary audiences.\n\nThe design distinguishes:\n\n- **Accepted product direction:** the contracts in this document and D-046.\n- **Historical prototype:** the P0.M1 `@rxjs/migrate` package and its former\n independently authored Skill/MCP experiments.\n- **Completed P0 evidence:** implementation fixtures in P0.M3, three-harness\n installation/discovery checks in P0.M4, and Codex/ChatGPT representative\n repository evaluations in P0.M5.\n\nNo statement here turns the current prototype's nine tests into general\nmigration evidence or promises that every RxJS 7 application can be migrated\nautomatically.\n\n## Product principles\n\n1. **Behavior before syntax.** A passing RxJS 7 baseline and explicit target\n contract precede broad source rewriting.\n2. **No silent lifecycle choice.** The agent must not infer platform sharing\n or producer-per-direct-subscription behavior from an operator name,\n directory, or currently passing output.\n3. **Mechanical work stays bounded.** The engine transforms only versioned,\n fixture-proved syntax and reports everything else.\n4. **The destination owns the result.** Migrated code and characterization\n tests become ordinary project source, not generated runtime artifacts.\n5. **Outcome gates outrank source shape.** Agent changes may vary in form; the\n declared contract, compilation, tests, diagnostics, and intentional\n divergences must not vary.\n6. **One workflow, thin harness adapters.** Codex, Claude, and Cursor use the\n same Skill body and validation assets.\n7. **Human authority is explicit.** Ambiguous intent, weakened coverage,\n unsupported behavior, and accepted divergences require a developer\n decision.\n\n## Developer job and paved road\n\n### Persona and job to be done\n\nThe primary user is an application or library maintainer responsible for an\nRxJS 7 codebase. They need to reach an intentional RxJS Next contract without\nlosing behavior that the existing test suite did not happen to cover.\n\nThe paved road begins with a working repository and ends with:\n\n- the agreed build, type, lint, and test gates passing;\n- a checked-in target-contract manifest;\n- reviewed diagnostics and intentional divergences;\n- ordinary project-owned migrated source and tests; and\n- a remaining-blocker record when the developer deliberately accepts work\n that cannot yet be completed.\n\n### Journey and gates\n\n#### 1. Discover and establish authority\n\nThe agent locates repository instructions, package-manager metadata, RxJS\nversions, workspaces, build/test commands, CI configuration, and the current\nworking-tree state. It states the files and commands it proposes to use before\nwriting broadly.\n\nEntry gate:\n\n- the repository is accessible and its local instructions are known.\n\nExit gate:\n\n- the migration scope, allowed writes, package manager, and candidate\n verification commands are recorded.\n\nThe agent must stop if it cannot distinguish the intended repository, cannot\nprotect existing changes, or needs authority for destructive or external\nactions.\n\n#### 2. Assess versions, usage, and coverage\n\nThe agent inventories:\n\n- installed RxJS versions and import forms;\n- Observable construction, custom producers, Subjects, subscriptions,\n schedulers, testing utilities, interop inputs, and repeated subscriptions;\n- direct and transitive operator usage;\n- test frameworks and coverage around lifecycle-sensitive paths; and\n- build/type/test commands that currently exercise those paths.\n\nThe result is a risk report, not a transform plan. Every finding links to\nsource evidence and one or more migration themes.\n\nExit gate:\n\n- every in-scope lifecycle-sensitive use is either covered by an existing\n baseline, selected for characterization, explicitly unsupported, or accepted\n by the developer as an uncovered risk.\n\n#### 3. Establish the RxJS 7 baseline\n\nThe agent runs the agreed checks before changing dependencies or source. A\nfailing starting gate is diagnosed and recorded; it is never silently treated\nas a migration regression.\n\nWhen existing coverage is insufficient, the agent proposes focused\ncharacterization tests against RxJS 7. These tests protect observable values,\nterminal behavior, producer multiplicity, cancellation, teardown ordering,\ntiming, errors, and subscription effects relevant to the selected code.\n\nExit gate:\n\n- agreed baseline commands pass on RxJS 7, or the developer explicitly accepts\n named pre-existing failures; and\n- every newly added characterization test passes before migration begins.\n\n#### 4. Classify the intended Next contract\n\nThe agent creates or updates the target-contract manifest described below.\nEach migration unit receives one target lifecycle and one evidence\nclassification. `unresolved` is a stop state, not a default the transformer may\nresolve.\n\nExit gate:\n\n- the developer has approved every ambiguous lifecycle choice and intentional\n divergence needed for the current batch.\n\n#### 5. Plan and dry-run mechanical changes\n\nThe agent selects only engine capabilities whose versioned evidence matches\nthe source form and approved contract. It runs analysis and transforms without\nwrites first, then presents changed-file scope and structured diagnostics.\n\nExit gate:\n\n- no unresolved or refusal diagnostic is hidden;\n- the proposed output stays within authorized paths; and\n- the developer has approved any batch whose size or semantic reach exceeds\n the previously reviewed scope.\n\n#### 6. Apply a small migration batch\n\nThe agent applies one coherent batch, formats it through the project's normal\ntools, and keeps migrated files as ordinary source. It does not add a runtime\ngenerator, compatibility assertion layer, or unreviewed local operator to make\nthe batch pass.\n\nExit gate:\n\n- the batch parses and type-checks at the narrowest useful boundary;\n- deterministic transforms are idempotent; and\n- all diagnostics are resolved, carried forward, or escalated.\n\n#### 7. Build, test, diagnose, and repair\n\nThe agent runs the narrowest relevant checks, then the agreed project gates.\nIt separates:\n\n- migration defects, which it repairs;\n- RxJS Next product gaps, which it reports without disguising;\n- intentional divergences, which require approved expectations; and\n- environment or baseline failures, which retain their original status.\n\nThe loop continues in reviewable batches until green or until the developer\naccepts a documented blocker. Tests may be strengthened but never weakened\nmerely to obtain green output.\n\n#### 8. Close out and hand off\n\nThe agent records final commands and results, changed contracts, unsupported\nbehavior, intentional divergences, remaining blockers, and the installed Skill\nand engine versions. A migration is not complete while required gates are\nunknown, skipped without approval, or red for an unexplained reason.\n\n## Target-contract protocol\n\n### Separate lifecycle from evidence classification\n\nEvery migration unit records both fields. They answer different questions.\n\nTarget lifecycle:\n\n| Value | Meaning |\n| ---------------------------------- | ---------------------------------------------------------------------------------------------- |\n| `platform-shared` | Use the active platform Observable with one shared, ref-counted producer while observers exist |\n| `producer-per-direct-subscription` | Use an explicit Next API such as `ColdObservable` that creates producer work per direct call |\n| `subject-hot` | Use an intentional Subject API whose producer exists before observers subscribe |\n| `not-applicable` | The unit has no Observable producer lifecycle |\n| `unsupported` | The accepted Next surface does not provide the required behavior |\n| `unresolved` | Developer intent or product policy is unknown; the agent must stop |\n\nEvidence classification uses the compatibility policy's existing values:\n`portable`, `harness-rewrite`, `compatibility-only`,\n`intentional-divergence`, or `unsupported-or-obsolete`.\n\nThe engine may suggest review flags but cannot promote `unresolved` to a\ntarget lifecycle or approve an intentional divergence.\n\n### Contract manifest\n\nThe checked-in manifest is structured data with a human-readable summary. Its\nschema is versioned with `@rxjs/migrate` and contains at least:\n\n| Field | Required content |\n| ------------------------ | ----------------------------------------------------------------------------------------- |\n| `schemaVersion` | Exact manifest schema |\n| `engineVersion` | `@rxjs/migrate` version used for analysis and transforms |\n| `skillDigest` | Digest of the canonical Skill content |\n| `sourceRxjsVersion` | Exact RxJS 7 version or range observed in the project |\n| `targetRxjsVersion` | Exact RxJS Next version under evaluation |\n| `baseline` | Commands, environment, result, and accepted pre-existing failures |\n| `units` | Stable IDs, source locations, lifecycle, evidence class, claims, and approval state |\n| `diagnostics` | Structured unresolved, refused, unsupported, and informational findings |\n| `intentionalDivergences` | Old claim, approved Next claim, user impact, evidence, and developer approval |\n| `verification` | Required commands and final results |\n| `blockers` | Owner, reason, affected units, evidence, and explicit acceptance when work ends non-green |\n\nThe manifest records decisions and evidence; it is not an input that can\noverride the engine's safe path or capability checks.\n\n### Mandatory escalation cases\n\nThe agent pauses for the developer when:\n\n- repeated subscriptions could mean independent work, refresh/retry behavior,\n sharing, or caching and intent is not proved;\n- source behavior could reasonably map to either the platform Observable or\n `ColdObservable`;\n- a Subject's replay, terminal, or late-observer behavior is not covered;\n- the change would remove or reinterpret scheduler-sensitive ordering;\n- teardown order, abort reason, or unhandled-error behavior could change;\n- a custom subscribable or interop protocol is outside `Observable.from`;\n- a transform would drop an unsupported overload or assertion;\n- existing tests are missing or failing in the affected area;\n- a proposed repair weakens an expectation or changes public behavior; or\n- completing the work requires broader writes, dependency changes, network\n access, or destructive action beyond the approved scope.\n\n## Product boundaries\n\n### Portable Agent Skill\n\nThe Skill is the primary user experience. It owns:\n\n- journey orchestration and stop conditions;\n- repository and coverage assessment;\n- target-contract elicitation and manifest maintenance;\n- choosing when a deterministic engine operation is allowed;\n- review batching and repair-loop behavior;\n- classification of migration, product, environment, and intentional\n divergence outcomes; and\n- final evidence and blocker reporting.\n\nIt does not copy mutable capability mappings into prose. It consumes the\ninstalled engine's machine-readable capability and schema outputs.\n\n### `@rxjs/migrate`\n\nThe package owns deterministic, versioned behavior:\n\n- parse and usage analysis;\n- capability and argument-adapter data;\n- source and test transforms;\n- optional test-framework syntax adapters;\n- structured findings and refusal diagnostics;\n- contract-manifest schema validation;\n- dry-run/write equivalence and safe path containment; and\n- Skill installation, synchronization, and content verification.\n\nThe package does not own:\n\n- target-lifecycle decisions;\n- approval of intentional divergences;\n- general code repair;\n- repository-wide test strategy;\n- claims beyond its executable fixtures; or\n- completion of an end-to-end migration.\n\n### CLI and library API\n\nThe CLI and library are two interfaces to the same engine. Given the same\nsource, options, capability version, and framework adapter, they return the\nsame changed content and structured diagnostics. The CLI is dry-run-first and\nmachine-readable; writes require an explicit flag and contained destination.\n\n### Framework adapters\n\nFramework adapters translate only framework syntax and configuration they\nexplicitly support. They do not select an Observable lifecycle, change RxJS\nsemantics, or add assertion compatibility layers. Preserving the project's\ncurrent framework remains the default.\n\n### MCP decision\n\nNo MCP server is in the accepted release architecture. The P0.M1 prototype\naccepts source text and returns the same analysis or transform available from\nthe local API. That indirection does not justify a second versioned protocol,\nruntime dependencies, installation path, permission model, or validation\nmatrix.\n\nA future proposal must identify at least one necessary capability that cannot\nbe provided adequately by the CLI, library, Skill resources, or host agent\ntools. It must then define separate authentication, authority, privacy,\nversioning, offline, error, and evaluation contracts. Convenience or protocol\nsymmetry alone is insufficient.\n\n## Canonical Skill and distribution\n\n### One authored source\n\n`packages/migrate/skill` is the only authored Skill source. Its content digest\nis included in the package and contract manifest. The Skill and engine share\nthe package version so instructions cannot silently describe a different\ncapability registry or schema.\n\nThe earlier `.agents/skills/rxjs-next-marble-migration` tree remains valuable\nP0.T2 history in Git, but it is no longer a second authored source. P0.M4\nmerged its still-valid guidance into the canonical Skill and replaced it with\nthe validated `.agents/skills/rxjs-next-migration` generated copy.\n\n### Installation model\n\nProjects add an exact or intentionally ranged development dependency on\n`@rxjs/migrate`. A package command then installs or synchronizes the canonical\nSkill into the selected harness discovery location and writes a small\nprovenance record containing package name, version, content digest, and target\npath. Installed copies are generated distribution artifacts; maintainers edit\nonly `packages/migrate/skill`.\n\nThe installer must support check-only, install, update, and remove operations;\nmust refuse to overwrite a locally modified target without explicit approval;\nand must work without symlink privileges. A symlink may be offered when the\nharness and platform support it, but it is not the only path.\n\n### Harness adapters\n\nThe `rxjs-migrate-skill` command implements the required behavior:\n\n| Harness | Discovery target | Invocation | Adapter responsibility |\n| ------- | --------------------------------------------- | ---------------------------------------------- | --------------------------------------------------------------------------------------- |\n| Codex | `.agents/skills/rxjs-next-migration/SKILL.md` | `$rxjs-next-migration` or implicit description | Install/sync the canonical bytes; document sandbox and approval settings |\n| Claude | `.claude/skills/rxjs-next-migration/SKILL.md` | `/rxjs-next-migration` or implicit description | Install/sync the canonical bytes; omit Claude-only frontmatter from the portable source |\n| Cursor | `.agents/skills/rxjs-next-migration/SKILL.md` | `/rxjs-next-migration` or implicit description | Use the open Skill path; verify editor and CLI discovery |\n\nIf a harness requires metadata not in the open Agent Skills format, the\nadapter stores that metadata beside the installed Skill. It must not fork the\nworkflow body.\n\n### Permissions\n\nThe portable Skill declares workflow needs, not blanket authority. A host\nadapter documents how to grant:\n\n- read access to the selected repository;\n- write access only to the reviewed project paths;\n- local execution of the project's declared package-manager, build, and test\n commands; and\n- network or package-install access only when the developer approves it.\n\nThe workflow never needs production credentials or project-level MCP write\nauthority. Destructive actions and external publication remain outside the\ndefault migration permission set.\n\n### Updates and discovery verification\n\nUpdating means updating `@rxjs/migrate`, running Skill synchronization, and\nchecking that the installed digest matches the package. Each harness smoke\ntest must prove:\n\n1. the Skill is discovered from a clean fixture;\n2. explicit invocation reaches the canonical workflow;\n3. an implicit trigger is recognized when enabled;\n4. required local tools are requested rather than assumed; and\n5. a stale or locally modified installed copy is reported clearly.\n\nP0.M4 rechecked the official references on 2026-07-31 and records the exact\ncommands, permissions, update flow, smoke scenario, and locally inspected host\nversions in `MIGRATION_SKILL_GUIDE.md`. Harness discovery and permission\nbehavior can change independently of RxJS and must be rechecked before release.\n\n## Fixture and evaluation specification\n\n### Two evidence lanes\n\nDeterministic engine behavior and nondeterministic agent outcomes use separate\nfixtures and gates.\n\n```mermaid\nflowchart LR\n Source[\"Pinned RxJS 7 source\"] --> Mechanical[\"Deterministic engine fixtures\"]\n Mechanical --> Output[\"Content, diagnostics, compile, idempotence, behavior\"]\n Source --> Agent[\"Agent workflow evaluation\"]\n Agent --> Contract[\"Contract manifest and reviewed changes\"]\n Contract --> Gates[\"Build, type, lint, tests, divergences, blockers\"]\n```\n\nAn exact golden file can prove deterministic output. It cannot prove an agent\nmade the correct lifecycle choice. Conversely, a green end-to-end repository\ndoes not prove every codemod branch is deterministic or path-safe.\n\n### Mechanical fixture schema\n\nEvery engine fixture records:\n\n- stable fixture ID and behavior category;\n- exact input files and parser/compiler options;\n- source RxJS and target Next versions;\n- migration mode and capability-registry version;\n- framework adapter and options;\n- expected changed paths;\n- exact output where formatting is contractual, otherwise explicit structural\n invariants;\n- ordered diagnostics with classification, severity, source span, and\n suggested next action;\n- expected parse and type results;\n- idempotence expectation; and\n- executable pre- and post-migration behavioral claims.\n\nSuccessful-fixture gates:\n\n1. input parses in its declared source environment;\n2. output parses and type-checks in the declared target environment;\n3. a second transform produces no change and identical diagnostics;\n4. CLI and API results agree;\n5. dry-run and write modes agree byte-for-byte;\n6. writes remain inside the declared destination;\n7. source behavior passes on RxJS 7;\n8. target behavior passes for the approved Next contract; and\n9. the fixture's diagnostic and output expectations pass.\n\nNegative controls must prove that the gate fails for output drift, a missing\ndiagnostic, a non-idempotent transform, a compile regression, behavior drift,\npath escape, unsupported syntax reported as success, and a CLI/API mismatch.\n\n### Agent evaluation schema\n\nEach agent fixture records:\n\n- stable scenario ID and repository category;\n- pinned repository revision and dependency lock;\n- harness, agent/model configuration, Skill version/digest, and engine version;\n- allowed tools, permissions, network policy, time/task bounds, and clean-room\n setup;\n- starting RxJS 7 commands and results;\n- seeded coverage gaps and expected characterization recommendations;\n- required target-contract units and developer decision points;\n- allowed implementation variation;\n- required diagnostics, refusals, and escalations;\n- intentional divergences and their approval records;\n- final build/type/lint/test gates; and\n- artifact capture for the conversation, manifest, patch, command results, and\n final report.\n\nAgent output is not compared as one golden patch. A run passes only when:\n\n- the baseline is established honestly;\n- required risks and weak coverage are surfaced;\n- the agent does not choose an ambiguous lifecycle automatically;\n- characterization tests pass on RxJS 7 before dependency/source migration;\n- deterministic transforms are used only for supported inputs;\n- no required test is weakened, skipped, or deleted without approval;\n- the final manifest matches the implemented contracts;\n- every agreed gate passes or a named blocker is explicitly accepted; and\n- the final report distinguishes migration defects, product gaps,\n divergences, and environment limits.\n\n### Required behavior categories\n\nMechanical fixtures and agent scenarios collectively cover:\n\n| Category | Required evidence |\n| --------------------------------- | ------------------------------------------------------------------------------------------- |\n| `ColdObservable` | Independent direct subscriptions, duplicated side effects, cancellation, and Symbol results |\n| Platform sharing and ref counting | First activation, late join, individual abort, final abort, restart, and shared state |\n| Subjects | Hot producer, current/replayed values, terminal state, read-only views, and late observers |\n| Cancellation | Captured subscriptions rewritten to signal ownership, abort reasons, and upstream closure |\n| Teardown order | Reverse platform teardown ordering and order-sensitive characterization |\n| Scheduling and timing | Host-time mappings, unsupported scheduler forms, ordering, and virtual-time evidence |\n| Errors | Observer callback errors, late/unhandled errors, selector errors, and terminal preservation |\n| Input conversion | Iterables, async iterables, Promises, custom subscribables, and legacy interop refusal |\n| Repeated subscriptions | Retry, refresh, cache invalidation, producer multiplicity, and restart |\n| Unsupported APIs | Visible diagnostics, retained evidence, no invented compatibility layer |\n| Missing coverage | Characterization recommendation and refusal to claim safety |\n| Mixed pipelines | Supported transforms around unsupported operators without dropping the unsupported segment |\n\nEach category needs at least one passing case and one negative or refusal\ncontrol. P0.M5 expands these units into representative application and library\nrepositories.\n\n## P0.M2 prototype audit\n\nP0.M1 established useful boundaries but not release-grade evidence:\n\n- `packages/migrate/src/index.ts` separates semantic and framework transforms.\n- `packages/migrate/src/cli.ts` is dry-run-first.\n- `packages/migrate/src/types.ts` exposes structured but limited diagnostics.\n- `packages/migrate/skill` contained a thin package Skill.\n- `.agents/skills/rxjs-next-marble-migration` contained the earlier, more\n detailed repository Skill.\n- `packages/migrate/src/mcp.ts` mirrored source-content analysis and migration.\n- the package had nine test registrations and one source fixture;\n the fixture is not a comprehensive executable matrix.\n\nKnown gaps assigned to P0.M3 or P0.M4 include:\n\n- no comprehensive mapping, aliasing, shadowing, malformed-input, compile,\n idempotence, behavior, CLI/API-equivalence, or path-containment fixtures;\n- no versioned target-contract manifest;\n- no agent-first repository assessment or repair loop in the bundled Skill;\n- independently authored Skill content that can drift;\n- no tested install/update/remove flow across the three harnesses; and\n- an MCP surface and dependencies with no accepted release responsibility.\n\nThese are scope facts, not implementation failures against a contract that\nP0.M1 had already claimed.\n\n## Implementation handoff\n\n### P0.M3 — deterministic engine hardening\n\nP0.M3 implements the package-owned pieces of this design:\n\n- machine-readable capability and contract-manifest schemas;\n- structured diagnostics with spans, severity, refusal state, and next action;\n- comprehensive mechanical fixtures and negative controls;\n- parse, compile, idempotence, behavior, CLI/API, dry-run/write, containment,\n import, and pack gates;\n- Skill digest and synchronization primitives needed by P0.M4; and\n- removal of MCP bins, exports, runtime dependencies, tests, and claims.\n\nP0.M3 does not install cross-harness adapters or claim agent workflow\nqualification.\n\n### P0.M4 — portable Skill and harness adapters\n\nP0.M4 merges the reusable P0.T2 guidance into `packages/migrate/skill`, expands\nit to the complete journey, and makes it consume engine data rather than prose\ncopies. It implements and tests installation, discovery, invocation,\npermissions, update, drift, and removal for Codex, Claude, and Cursor.\n\nThe completed implementation ships the `rxjs-migrate-skill` command and\n`@rxjs/migrate/skill` API, copy-only atomic adapters, embedded provenance, and\none shared Codex/Cursor placement plus Claude's native placement. The package\nsuite proves canonical byte identity and safe lifecycle behavior across all\nthree adapters. The repository's generated copy keeps natural Codex and Cursor\ninvocation available after the independently authored P0.T2 tree is removed.\n\n### P0.M5 — representative qualification\n\nP0.M5 evaluates clean pinned repositories across application/library layouts,\nframeworks, coverage levels, lifecycle choices, and unsupported behavior. It\npublishes measured outcomes and limitations rather than a blanket automatic\nmigration claim.\n\nThe live matrix, offline outcome gates, current measured evidence, and claim\nlimits are tracked in\n[`MIGRATION_QUALIFICATION.md`](MIGRATION_QUALIFICATION.md).\nThe completed Codex-only\nmatrix passes 4/4: three approved migrations completed and the\nweak-coverage/unsupported scenario made its required safe stop. Codex\n`0.146.0-alpha.3.1`, `gpt-5.6-sol` at medium reasoning, and Skill/engine\n`8.0.0-alpha.14` are part of the claim boundary. The verifier binds four\nrecords to 20 hashed artifacts and 14 semantic gate families.\n\nThe retained conversation artifact is the exact user prompt plus final\nresponse, not necessarily the complete host event stream. Exact commands and\nresults, file changes, and observed authority are retained separately in the\ncommand-results artifact, patch, and qualification record. Full event streams\nwere not retained for the first three runs. This evidence boundary is explicit\nso a future requalification can strengthen capture without overstating the P0\nrecords.\n\n## Risks and controls\n\n| Risk | Control |\n| ----------------------------------------- | -------------------------------------------------------------------------------------------- |\n| Green output hides a lifecycle change | Baseline, characterization tests, explicit target manifest, and shared/cold fixtures |\n| Capability prose drifts from the engine | Skill consumes versioned machine-readable data and shares the package version |\n| Harness instructions diverge | One canonical Skill digest; generated placements; per-harness smoke tests |\n| Agent weakens tests to finish | Outcome grader rejects unapproved skips, deletions, and weaker expectations |\n| Codemod writes outside scope | Resolve-and-contain checks plus path-escape negative controls |\n| Nondeterminism masks regressions | Judge contracts and outcomes; retain the five declared hashed artifacts and authority record |\n| MCP becomes an unsupported second product | Remove the prototype surface; require a new evidence-backed decision to reintroduce it |\n| Harness behavior changes after release | Re-verify official discovery/permission paths during P0.M4 and before each supported claim |\n\n## Completion criteria for the migration product\n\nThe migration experience is release-ready only when:\n\n- P0.M3 mechanical fixtures prove every documented transform and refusal;\n- P0.M4 uses one canonical Skill and passes all harness discovery and\n permission smoke tests;\n- P0.M5 representative repositories pass their declared outcome gates;\n- any outcome claim names its harness/model boundary and retained evidence;\n- measured limitations and unsupported surfaces are published;\n- no migration is called complete based only on transformed source shape; and\n- no MCP or other secondary orchestration surface is claimed without its own\n accepted contract and evidence.\n\n## References\n\nRepository sources:\n\n- `PROJECT_CHARTER.md`\n- `ARCHITECTURE.md`\n- `DECISIONS.md`\n- `PROJECT_PLAN.md`\n- `COMPATIBILITY.md`\n- `TESTING_DESIGN.md`\n- `packages/migrate`\n- `.agents/skills/rxjs-next-migration`\n\nCurrent harness references reviewed for P0.M2:\n\n- [OpenAI: Build skills](https://learn.chatgpt.com/docs/build-skills)\n- [Claude Code: Extend Claude with skills](https://code.claude.com/docs/en/slash-commands)\n- [Cursor 2.4: Agent Skills](https://cursor.com/changelog/2-4)\n- [Agent Skills open standard](https://agentskills.io)\n\n\n---\nname: rxjs-next-migration\ndescription: Migrate an RxJS 7 application, library, or test suite to RxJS Next through an agent-led workflow that establishes a green behavioral baseline, makes Observable lifecycle choices explicit, uses @rxjs/migrate only for bounded fixture-proved rewrites, repairs without weakening evidence, and records a versioned migration contract. Use for repository assessment, migration planning or execution, lifecycle review, TestScheduler conversion, or migration closeout.\n---\n\n# RxJS 7 to RxJS Next migration\n\nTreat this as reviewed project work, not a codemod run. The objective is an\nintentional RxJS Next contract backed by the project's own build and behavior\nevidence. A transformed file, a clean diff, or one passing test is not proof\nthat the migration is complete.\n\nWork through all eight stages in order. Re-enter an earlier stage whenever new\nevidence changes scope, coverage, or lifecycle intent. Keep the developer\ninvolved at every explicit pause.\n\n## Non-negotiable rules\n\n- Read and obey repository-local instructions before acting. Protect existing\n work and stay within the authorized repository and paths.\n- Establish the RxJS 7 baseline before changing dependencies or source.\n- Never infer platform sharing versus producer-per-direct-subscription behavior\n from syntax, filenames, operator names, or a currently passing output.\n- Use the installed engine's versioned registry and schemas as authority. Do\n not reconstruct capability mappings from this Skill or from memory.\n- Run the deterministic engine without writes first. A refusal is a successful\n safety outcome, not permission to improvise a mechanical rewrite.\n- Preserve the project's test framework by default. Select a framework adapter\n only when the developer asked for that separate conversion.\n- Do not weaken, skip, delete, or replace a behavioral expectation merely to\n make the migrated suite green.\n- Do not add RxJS 7 compatibility shims, string-named platform methods, local\n substitute operators, or runtime generators unless the developer separately\n authorizes that product work.\n- Keep changes in small coherent batches. Review and verify each batch before\n widening the scope.\n- Do not call a migration complete while a required command is unknown,\n unapproved, skipped, or red without an explicitly accepted blocker.\n\n## Working record\n\nCreate or locate a checked-in migration contract manifest and a concise\nhuman-readable report. Use the schema exported by the installed\n`@rxjs/migrate`; schema validity and migration readiness are separate checks.\nUse [assets/migration-report.md](assets/migration-report.md) for the report.\n\nFor every migration unit, preserve source locations and record:\n\n- its current RxJS 7 behavioral claim;\n- the target lifecycle selected by the developer;\n- its evidence classification and supporting tests;\n- approval state, diagnostics, and any intentional divergence; and\n- verification or a named blocker.\n\n## Stage 1: Establish authority and scope\n\n1. Locate repository instructions, package and workspace metadata, lockfiles,\n CI configuration, RxJS versions, build/test commands, and current working\n tree state.\n2. Identify the repository root, migration boundary, permitted writes,\n package manager, network policy, and candidate verification commands.\n3. Record the installed `@rxjs/migrate` version and canonical Skill digest.\n If the installed Skill does not match its package, stop and synchronize it\n before trusting these instructions.\n4. State the proposed read, write, dependency, and command scope before broad\n changes.\n\nPause for the developer if the target repository or allowed scope is unclear,\nexisting changes overlap the migration, or destructive, networked, external,\nor broader actions require new authority.\n\nExit only when the scope, allowed writes, package manager, and candidate gates\nare recorded.\n\n## Stage 2: Assess usage, lifecycle risk, and coverage\n\nInventory installed RxJS versions and import forms, then locate Observable\nconstruction, custom producers, Subjects, subscription ownership, repeated\nsubscriptions, retry/refresh/cache paths, schedulers and timing, test helpers,\ninterop inputs, cancellation, teardown, and error handling. Include direct and\ntransitive operator usage.\n\nFor each lifecycle-sensitive path, link exact source evidence and mark it as:\n\n- covered by an existing baseline;\n- requiring a characterization test;\n- explicitly unsupported; or\n- an uncovered risk the developer accepts.\n\nProduce a risk and coverage report before proposing rewrites. Read\n[references/assessment-and-contract.md](references/assessment-and-contract.md)\nfor the inventory and characterization protocol.\n\nExit only when every in-scope lifecycle-sensitive use has one recorded\ncoverage disposition. Missing coverage is not evidence that behavior is safe.\n\n## Stage 3: Establish the green RxJS 7 baseline\n\nRun the agreed build, type, lint, unit, integration, and behavior checks against\nthe unchanged RxJS 7 project. Record exact commands, environment facts, exit\ncodes, and concise results.\n\nAdd focused characterization tests where Stage 2 found material gaps. Protect\nobservable values, completion/error behavior, producer multiplicity,\ncancellation, abort reasons, teardown ordering, timing, and externally visible\nsubscription effects as applicable. Every characterization test must pass on\nRxJS 7 before migration begins.\n\nPause if a starting gate fails. Diagnose it and ask the developer whether to\nfix it first, narrow scope, or record it as an accepted pre-existing failure.\nNever silently reclassify it as a migration regression or ignore it.\n\nExit only with a green baseline or explicit approval for each named\npre-existing failure, plus green characterization tests.\n\n## Stage 4: Classify and approve the target contract\n\nDivide the scope into stable migration units. For each unit, record one target\nlifecycle using the values accepted by the installed manifest schema and one\nevidence classification. Use repository evidence and\n[references/assessment-and-contract.md](references/assessment-and-contract.md)\nto explain the choice.\n\nThe engine may identify risk but cannot choose lifecycle intent. `unresolved`\nis a stop state. Pause for the developer when either platform-shared behavior\nor producer-per-direct-subscription behavior is plausible, or when Subject\nsemantics, cancellation, scheduler ordering, error behavior, interop, or a\npublic behavior change is not proved.\n\nIntentional divergences require a concrete old claim, proposed Next claim,\nuser impact, evidence, and developer approval. Validate the manifest\nstructurally, then run the installed readiness assessment. Do not proceed with\na batch containing unresolved intent or required pending approval.\n\nExit only when the developer has approved every ambiguous choice and\nintentional divergence needed for the next batch.\n\n## Stage 5: Plan and dry-run bounded engine changes\n\nInspect the installed capability registry and select only entries whose\nversion, source form, arity, preconditions, and executable evidence match the\napproved unit. Do not infer support from a familiar name. Follow\n[references/engine-and-batches.md](references/engine-and-batches.md).\nWhen the batch contains RxJS 7 marble tests, also read\n[references/test-migration.md](references/test-migration.md).\n\nRun `rxjs-migrate` without `--write` using explicit provenance and, when\nrequired, the approved `cold` or `platform` mode. Preserve the current test\nframework unless a supported adapter was separately selected. Capture the\nversioned JSON report, changed paths, structured diagnostics, and exit code.\n\nPause when a diagnostic requires review or refuses a transform, when output\nwould escape authorized paths, when source does not match the capability\nevidence, or when batch size or semantic reach exceeds the reviewed scope.\nNever conceal unsupported segments inside a partially transformed pipeline.\n\nExit only after diagnostics and changed-file scope are reviewed and the\ndeveloper has approved any newly broadened batch.\n\n## Stage 6: Apply one small migration batch\n\nApply only the reviewed dry-run plan. Require an explicit write destination\ninside the authorized project and preserve source provenance. Do not overwrite\nexisting output without specific approval. Review the resulting diff before\nadditional edits.\n\nFormat through the project's normal tools. Ensure ordinary project-owned\nsource and direct test declarations remain; do not leave dynamic generators,\nhidden case registries, or compatibility assertion layers in the result.\n\nImmediately check parsing, the narrowest useful type boundary, and engine\nidempotence. Re-running the same transform must produce no new source change\nand stable diagnostics. If it does not, restore the affected batch to the\nreviewed starting point and report an engine defect.\n\nExit only when the batch parses, type-checks at its narrow boundary, is\nidempotent, and every diagnostic is resolved, carried forward, or escalated.\n\n## Stage 7: Build, test, diagnose, and repair\n\nRun focused characterization and migrated tests first, then the agreed project\ngates. Classify every failure as a migration defect, RxJS Next product gap,\nintentional divergence, environment/baseline issue, or still-unknown result.\nUse [references/verification-and-closeout.md](references/verification-and-closeout.md)\nfor the repair rules.\n\nRepair migration defects in a small batch and repeat the relevant gates. For a\nproduct gap, preserve the failing evidence and report it; do not disguise it\nwith a local replacement. For an intentional divergence, change an expectation\nonly after the manifest records approved new behavior and user impact.\n\nPause before any repair that changes public behavior, weakens evidence,\nexpands writes, changes dependencies beyond the reviewed plan, needs external\naccess, or introduces a compatibility layer.\n\nExit only when agreed gates pass or each remaining red result has a named,\nevidenced, explicitly accepted blocker.\n\n## Stage 8: Close out and hand off\n\nUpdate the contract manifest and report with exact source and target versions,\nengine version, capability-registry version, canonical Skill digest, baseline,\nunits, diagnostics, divergences, final commands/results, and blockers. Validate\nthe manifest with the installed schema and assess readiness separately.\n\nReview [references/review-checklist.md](references/review-checklist.md). Report:\n\n1. what behavior and lifecycle contract changed;\n2. what source and tests changed;\n3. the exact gates run and their results;\n4. migration defects repaired versus product gaps retained;\n5. approved divergences and environment limitations; and\n6. remaining blockers, owners, evidence, and acceptance.\n\nClaim completion only when readiness is `ready`, or\n`ready-with-accepted-blockers` when the developer intentionally chose that\noutcome. Otherwise hand off the migration as incomplete with the next concrete\ndecision or action.\n\n\n# RxJS 9 API and import guide\n\nRxJS 9 separates the platform Observable contract from RxJS capabilities.\nImport the root for intentional core primitives and import each operator or\nfactory from its own subpath.\n\n## Root exports\n\n```ts\nimport { AsyncSubject, ColdObservable, ConnectableObservable, Subject, behaviorSubject, connectable, replaySubject } from 'rxjs';\n```\n\nThe root also exports notifications and public errors, including\n`Notification`, `TimeoutError`, `EmptyError`, `NotFoundError`,\n`SequenceError`, and `ArgumentOutOfRangeError`. Advanced code can extend\n`PerSubscriptionSubjectBase` when it needs observer-local setup without\nclaiming that a Subject is cold.\n\nImporting `rxjs` conditionally initializes the platform Observable surface. It\ndoes not install every RxJS operator.\n\n## Symbol operators\n\n```ts\nimport 'rxjs';\nimport { filter } from 'rxjs/filter';\nimport { map } from 'rxjs/map';\nimport { switchMap } from 'rxjs/switch-map';\n\nconst result = source[filter]((value) => value.active)[map]((value) => value.id);\n```\n\nEvery public operator is a module-owned exact Symbol. Two independently\nevaluated copies intentionally have different Symbol identities, allowing\nversion-skewed capabilities to coexist without overwriting one another.\n\nWhen a platform string method has the same descriptive name, both forms\nremain available:\n\n```ts\nobservable.map(project); // platform contract\nobservable[map](project); // RxJS contract\n```\n\nThe RxJS import never replaces the platform string method.\n\nThe public subpaths cover transformation, filtering, combination,\nhigher-order, timing, buffering/windowing, error recovery, sharing/connection,\nquery, and terminal capabilities. The complete authoritative list is the\n[`exports` map](../package.json); migration status and behavioral evidence are\nin the [generated ledger](MIGRATION_EVIDENCE_LEDGER.md).\n\n## Factories and composition\n\nFactories such as `timer` are static Symbols:\n\n```ts\nimport { timer } from 'rxjs/timer';\n\nObservable[timer](1000).subscribe(console.log);\n```\n\nThe `pipe` Symbol supports instance and static composition:\n\n```ts\nimport { map } from 'rxjs/map';\nimport { pipe } from 'rxjs/pipe';\n\nconst doubled = source[pipe]((values) => values[map]((value) => value * 2));\nconst normalized = Observable[pipe]([1, 2], (values) => values[map](String));\n```\n\nRxJS 9 does not install `.pipe`, publish RxJS 7 pipeable operator functions,\nor restore `OperatorFunction`.\n\n## Construction and input boundaries\n\nDerived RxJS operators use the receiver's construction protocol. Compatible\nsubclasses can preserve their result constructor; `ColdObservable` selects its\nproducer-per-subscription result contract.\n\nInputs cross the active realm's platform `Observable.from` boundary. Arbitrary\nobjects with a `subscribe` method are not automatically accepted, and\ntransparent foreign-realm conversion is not claimed. Review the\n[migration guide](../MIGRATION.md) before translating RxJS 7 inputs or\nlifecycle assumptions.\n\n## Cancellation and teardown\n\nSubscriptions accept `{ signal: AbortSignal }`. Operators own upstream work\nthrough the downstream Subscriber lifecycle, and cancellation does not become\ncompletion. Teardown functions and `subscriber.addTeardown()` participate in\nthe same platform lifecycle.\n\n## Environment and distribution\n\nThe package requires Node 22.13+ and publishes ESM only. Node `require()` uses\nthe supported `require(esm)` bridge and resolves the same module files as\n`import`. Current browser, Deno, Bun, and Webpack support does not select\nruntime-specific code. See [release gates](RELEASE_GATES.md) for the exact\nmatrix and budgets.\n\n\n# RxJS 7 migration-evidence ledger\n\nThis generated ledger joins the versioned RxJS Next capability registry to the\nsource-pinned RxJS 7 executable manifest. It records migration status and\nevidence; it does not promise an RxJS 7 runtime compatibility surface.\n\n- **RxJS 7 source:** `7.x` at `e5351d02e225e275ac0e497c7b66eaa5f0c88791`\n- **Entries:** 161 (111 operators, 21 creation/static functions, 29 values/types)\n- **Distinct evidence cases:** 2271\n- **Entries without source-pinned cases:** 0\n- **Rows using canonical alias evidence:** 4\n- **Rows using pinned non-marble or focused Next evidence:** 3\n\nThe complete case IDs and source files are retained in\n`packages/rxjs/test/ported/migration-evidence-ledger.generated.json`. Every\nprioritized row has direct, canonical-alias, or supplemental evidence. Cold and\nfallback totals account for every linked executable case; supplemental rows\nname their pinned non-marble or focused Next sources explicitly.\n\nRegenerate or verify the ledger with:\n\n```sh\npnpm --filter rxjs run test:unit:ledger:generate\npnpm --filter rxjs run test:unit:ledger:check\n```\n\n## Operators\n\n| RxJS 7 API | Next status | Evidence | Cases | Cold | Fallback | Classifications | Sharing | Cancellation | Types | Migration | Decisions |\n| ------------------------- | ------------------------------------------- | ------------------- | ----- | ------- | -------- | --------------------------------------------------------------------- | ---------------------- | ------------ | --------- | ------------------------------------- | --------------------------------- |\n| `audit` | Present; parity verified | source-pinned | 21 | 21/21 | 21/21 | portable | shared-active-platform | AbortSignal | preserved | mechanical-change | D-003, D-048, D-049 |\n| `auditTime` | Partial unified mapping | source-pinned | 12 | 12/12 | 12/12 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `buffer` | Present; parity verified | source-pinned | 26 | 26/26 | 26/26 | harness-rewrite, portable | shared-active-platform | AbortSignal | preserved | mechanical-change | D-003, D-048, D-049 |\n| `bufferCount` | Partial unified mapping | source-pinned | 9 | 9/9 | 9/9 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `bufferTime` | Present; scheduler adapted to host timing | source-pinned | 18 | 18/18 | 18/18 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-033, D-034, D-048, D-049 |\n| `bufferToggle` | Present; parity unverified | source-pinned | 18 | 18/18 | 18/18 | intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `bufferWhen` | Partial unified mapping | source-pinned | 16 | 16/16 | 16/16 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `catchError` | Present; parity unverified | source-pinned | 18 | 17/18 | 17/18 | compatibility-only, harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `combineLatest` | Partial unified mapping | source-pinned | 34 | 34/34 | 34/34 | intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `combineLatestAll` | Present; parity unverified | source-pinned | 31 | 31/31 | 31/31 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `combineLatestWith` | Partial unified mapping | source-pinned | 30 | 30/30 | 30/30 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `concat` | Partial unified mapping | source-pinned | 27 | 27/27 | 27/27 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `concatAll` | Partial unified mapping | source-pinned | 30 | 30/30 | 30/30 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `concatMap` | Partial unified mapping | source-pinned | 34 | 34/34 | 34/34 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `concatMapTo` | Partial unified mapping | source-pinned | 18 | 18/18 | 18/18 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `concatWith` | Partial unified mapping | source-pinned | 22 | 22/22 | 22/22 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `connect` | Present; parity unverified | source-pinned | 50 | 50/50 | 48/50 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `count` | Present; parity unverified | source-pinned | 23 | 23/23 | 23/23 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `debounce` | Present; parity unverified | source-pinned | 26 | 26/26 | 26/26 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `debounceTime` | Partial unified mapping | source-pinned | 17 | 17/17 | 17/17 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `defaultIfEmpty` | Present; parity unverified | source-pinned | 7 | 7/7 | 7/7 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `delay` | Present; scheduler adapted to host timing | source-pinned | 43 | 43/43 | 43/43 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-033, D-034, D-048, D-049 |\n| `delayWhen` | Present; parity unverified | source-pinned | 15 | 15/15 | 15/15 | intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `dematerialize` | Present; parity unverified | source-pinned | 13 | 13/13 | 13/13 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `distinct` | Present; parity unverified | source-pinned | 22 | 22/22 | 22/22 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `distinctUntilChanged` | Present; parity unverified | source-pinned | 22 | 22/22 | 22/22 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `distinctUntilKeyChanged` | Present; parity unverified | source-pinned | 21 | 21/21 | 21/21 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `elementAt` | Present; partial empty behavior | source-pinned | 12 | 12/12 | 12/12 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `endWith` | Partial unified mapping | source-pinned | 16 | 16/16 | 16/16 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `every` | Present; parity unverified | source-pinned | 22 | 22/22 | 22/22 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `exhaust` | Partial unified mapping | source-pinned-alias | 15 | 15/15 | 15/15 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `exhaustAll` | Partial unified mapping | source-pinned | 15 | 15/15 | 15/15 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `exhaustMap` | Present; parity unverified | source-pinned | 18 | 17/18 | 17/18 | compatibility-only, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `expand` | Present; scheduler overload deferred | source-pinned | 13 | 13/13 | 13/13 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-033, D-034, D-048, D-049 |\n| `filter` | Present; parity unverified | source-pinned | 21 | 21/21 | 21/21 | intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `finalize` | Present; parity unverified | source-pinned | 8 | 8/8 | 8/8 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `find` | Present; parity unverified | source-pinned | 12 | 12/12 | 12/12 | intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `findIndex` | Present; parity unverified | source-pinned | 12 | 12/12 | 12/12 | intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `first` | Present; parity unverified | source-pinned | 17 | 17/17 | 17/17 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `flatMap` | Partial unified mapping | source-pinned-alias | 149 | 143/149 | 143/149 | compatibility-only, harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `groupBy` | Present; scheduler-internal cases deferred | source-pinned | 36 | 36/36 | 36/36 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-033, D-034, D-048, D-049 |\n| `ignoreElements` | Partial unified mapping | source-pinned | 9 | 9/9 | 9/9 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `isEmpty` | Present; parity unverified | source-pinned | 7 | 7/7 | 7/7 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `last` | Present; parity unverified | source-pinned | 11 | 11/11 | 11/11 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `map` | Present; parity unverified | source-pinned | 93 | 92/93 | 93/93 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `mapTo` | Partial unified mapping | source-pinned | 11 | 11/11 | 11/11 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `materialize` | Present; parity unverified | source-pinned | 10 | 10/10 | 10/10 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `max` | Present; parity unverified | source-pinned | 18 | 18/18 | 18/18 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `merge` | Partial unified mapping | source-pinned | 1 | 1/1 | 1/1 | intentional-divergence | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `mergeAll` | Partial unified mapping | source-pinned | 25 | 25/25 | 25/25 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `mergeMap` | Partial unified mapping | source-pinned | 149 | 143/149 | 143/149 | compatibility-only, harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `mergeMapTo` | Partial unified mapping | source-pinned | 106 | 87/106 | 103/106 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `mergeScan` | Present; parity unverified | source-pinned | 20 | 20/20 | 20/20 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `mergeWith` | Partial unified mapping | source-pinned | 17 | 17/17 | 17/17 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `min` | Present; parity unverified | source-pinned | 18 | 18/18 | 18/18 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `multicast` | Compatibility-only | source-pinned | 70 | 65/70 | 68/70 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | semantic-review | D-003, D-039, D-048, D-049 |\n| `observeOn` | Partial scheduler mapping | source-pinned | 7 | 7/7 | 7/7 | harness-rewrite | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-033, D-034, D-048, D-049 |\n| `onErrorResumeNext` | Partial unified mapping | source-pinned | 11 | 10/11 | 10/11 | compatibility-only, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `pairwise` | Present; parity unverified | source-pinned | 7 | 7/7 | 7/7 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `pluck` | Present; parity unverified | source-pinned | 14 | 14/14 | 14/14 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `publish` | Compatibility-only | source-pinned | 64 | 63/64 | 62/64 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | semantic-review | D-003, D-039, D-048, D-049 |\n| `publishBehavior` | Compatibility-only | source-pinned | 62 | 54/62 | 60/62 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | semantic-review | D-003, D-039, D-048, D-049 |\n| `publishLast` | Compatibility-only | source-pinned | 61 | 61/61 | 59/61 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | semantic-review | D-003, D-039, D-048, D-049 |\n| `publishReplay` | Compatibility-only | source-pinned | 69 | 60/69 | 66/69 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | semantic-review | D-003, D-039, D-048, D-049 |\n| `race` | Partial unified mapping | source-pinned | 12 | 12/12 | 12/12 | intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `raceWith` | Partial unified mapping | source-pinned | 10 | 10/10 | 10/10 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `reduce` | Present; parity unverified | source-pinned | 18 | 18/18 | 18/18 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `refCount` | Compatibility-only | source-pinned | 74 | 62/74 | 72/74 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | semantic-review | D-003, D-039, D-048, D-049 |\n| `repeat` | Partial unified mapping | source-pinned | 64 | 60/64 | 64/64 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `repeatWhen` | Present; parity unverified | source-pinned | 20 | 20/20 | 20/20 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `retry` | Partial unified mapping | source-pinned | 67 | 63/67 | 65/67 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `retryWhen` | Present; parity unverified | source-pinned | 19 | 19/19 | 19/19 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `sample` | Present; parity unverified | source-pinned | 16 | 16/16 | 16/16 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `sampleTime` | Present; scheduler adapted to host timing | source-pinned | 10 | 10/10 | 10/10 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-033, D-034, D-048, D-049 |\n| `scan` | Present; parity unverified | source-pinned | 12 | 12/12 | 12/12 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `sequenceEqual` | Present; parity verified | source-pinned | 23 | 23/23 | 23/23 | harness-rewrite, portable | shared-active-platform | AbortSignal | preserved | mechanical-change | D-003, D-048, D-049 |\n| `share` | Present; platform lifecycle review required | source-pinned | 176 | 176/176 | 174/176 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `shareReplay` | Present; platform lifecycle review required | source-pinned | 16 | 16/16 | 16/16 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `single` | Present; parity unverified | source-pinned | 25 | 25/25 | 25/25 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `skip` | Present; parity unverified | source-pinned | 29 | 29/29 | 29/29 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `skipLast` | Present; parity unverified | source-pinned | 16 | 16/16 | 16/16 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `skipUntil` | Present; parity unverified | source-pinned | 19 | 18/19 | 18/19 | compatibility-only, harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `skipWhile` | Present; parity unverified | source-pinned | 15 | 15/15 | 15/15 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `startWith` | Present; scheduler overload deferred | source-pinned | 24 | 24/24 | 24/24 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-033, D-034, D-048, D-049 |\n| `subscribeOn` | Partial scheduler mapping | source-pinned | 8 | 8/8 | 8/8 | harness-rewrite | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-033, D-034, D-048, D-049 |\n| `switchAll` | Partial unified mapping | source-pinned | 11 | 11/11 | 11/11 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `switchMap` | Present; parity unverified | source-pinned | 19 | 18/19 | 18/19 | compatibility-only, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `switchMapTo` | Partial unified mapping | source-pinned | 15 | 15/15 | 15/15 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `switchScan` | Present; parity unverified | source-pinned | 18 | 18/18 | 18/18 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `take` | Present; parity unverified | source-pinned | 47 | 47/47 | 47/47 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `takeLast` | Present; parity unverified | source-pinned | 18 | 18/18 | 18/18 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `takeUntil` | Present; parity unverified | source-pinned | 23 | 23/23 | 23/23 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `takeWhile` | Present; parity unverified | source-pinned | 23 | 23/23 | 23/23 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `tap` | Present; parity unverified | source-pinned | 73 | 66/73 | 73/73 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `throttle` | Present; parity unverified | source-pinned | 28 | 28/28 | 28/28 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `throttleTime` | Partial unified mapping | source-pinned | 16 | 16/16 | 16/16 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `throwIfEmpty` | Present; parity unverified | source-pinned | 7 | 7/7 | 7/7 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `timeInterval` | Present; scheduler adapted to host timing | source-pinned | 11 | 11/11 | 11/11 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-033, D-034, D-048, D-049 |\n| `timeout` | Partial unified mapping | source-pinned | 38 | 38/38 | 38/38 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-033, D-034, D-048, D-049 |\n| `timeoutWith` | Partial unified mapping | source-pinned | 15 | 15/15 | 15/15 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `timestamp` | Present; scheduler adapted to host timing | source-pinned | 11 | 11/11 | 11/11 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-033, D-034, D-048, D-049 |\n| `toArray` | Partial unified mapping | source-pinned | 15 | 15/15 | 15/15 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-048, D-049 |\n| `window` | Present; parity unverified | source-pinned | 18 | 18/18 | 18/18 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `windowCount` | Present; parity unverified | source-pinned | 9 | 9/9 | 9/9 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `windowTime` | Present; scheduler adapted to host timing | source-pinned | 13 | 13/13 | 13/13 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-033, D-034, D-048, D-049 |\n| `windowToggle` | Present; parity unverified | source-pinned | 19 | 19/19 | 19/19 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `windowWhen` | Present; parity unverified | source-pinned | 15 | 15/15 | 15/15 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `withLatestFrom` | Unified mapping | source-pinned | 17 | 17/17 | 17/17 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `zip` | Compatibility alias | source-pinned | 10 | 8/10 | 10/10 | intentional-divergence, portable | shared-active-platform | AbortSignal | changed | semantic-review | D-003, D-039, D-048, D-049 |\n| `zipAll` | Present; parity unverified | source-pinned | 46 | 46/46 | 46/46 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n| `zipWith` | Present; parity unverified | source-pinned | 32 | 32/32 | 32/32 | portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-048, D-049 |\n\n## Creation and static functions\n\n| RxJS 7 API | Next status | Evidence | Cases | Cold | Fallback | Classifications | Sharing | Cancellation | Types | Migration | Decisions |\n| ------------------- | ------------------------------------ | ------------------- | ----- | ------- | -------- | --------------------------------------------------------------------- | ---------------------- | ------------ | ------- | ------------------------------------- | ---------------------------------------- |\n| `animationFrames` | Present; parity unverified | source-pinned | 4 | 4/4 | 4/4 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-033, D-034, D-040, D-048, D-049 |\n| `combineLatest` | Partial unified mapping | source-pinned | 32 | 32/32 | 32/32 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-040, D-048, D-049 |\n| `concat` | Partial unified mapping | source-pinned | 115 | 114/115 | 114/115 | compatibility-only, harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-040, D-048, D-049 |\n| `defer` | Partial platform mapping | source-pinned | 12 | 12/12 | 12/12 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-040 |\n| `empty` | Partial standalone mapping | source-pinned | 1 | 1/1 | 1/1 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-040 |\n| `forkJoin` | Present; parity unverified | source-pinned | 39 | 35/39 | 35/39 | compatibility-only, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-040, D-048, D-049 |\n| `from` | Platform mapping | source-pinned | 8 | 6/8 | 6/8 | compatibility-only, harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-040 |\n| `fromEvent` | Partial platform string mapping | source-pinned | 1 | 1/1 | 1/1 | harness-rewrite | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-040 |\n| `generate` | Present; scheduler overload deferred | source-pinned | 13 | 13/13 | 13/13 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-033, D-034, D-040, D-048, D-049 |\n| `iif` | Partial platform mapping | source-pinned | 4 | 4/4 | 4/4 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-040 |\n| `interval` | Present; parity unverified | source-pinned | 12 | 12/12 | 12/12 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-040, D-048, D-049 |\n| `merge` | Partial unified mapping | source-pinned | 81 | 78/81 | 76/81 | compatibility-only, harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-040, D-048, D-049 |\n| `never` | Partial standalone mapping | source-pinned-alias | 42 | 42/42 | 42/42 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-040 |\n| `of` | Partial platform mapping | source-pinned | 400 | 394/400 | 394/400 | compatibility-only, harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-040 |\n| `onErrorResumeNext` | Partial unified mapping | source-pinned | 3 | 3/3 | 3/3 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-040, D-048, D-049 |\n| `pairs` | Partial platform mapping | source-pinned | 2 | 2/2 | 2/2 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-040 |\n| `partition` | Present; parity unverified | source-pinned | 16 | 16/16 | 16/16 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-003, D-040, D-048, D-049 |\n| `race` | Partial unified mapping | source-pinned | 15 | 15/15 | 15/15 | portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-040, D-048, D-049 |\n| `range` | Partial platform mapping | source-pinned | 3 | 3/3 | 3/3 | harness-rewrite | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-040 |\n| `throwError` | Partial platform mapping | source-pinned | 31 | 31/31 | 31/31 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-040 |\n| `timer` | Partial unified mapping | source-pinned | 37 | 37/37 | 37/37 | harness-rewrite, portable | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-003, D-040, D-048, D-049 |\n\n## Values, types, and standalone functions\n\n| RxJS 7 API | Next status | Evidence | Cases | Cold | Fallback | Classifications | Sharing | Cancellation | Types | Migration | Decisions |\n| ------------------------- | --------------------------------- | ------------------- | ----- | ------------ | ------------ | --------------------------------------------------------------------- | -------------------------------- | ------------------ | ------------------ | ------------------------------------- | --------------------------------- |\n| `ArgumentOutOfRangeError` | Present; parity verified | source-pinned | 2 | 2/2 | 2/2 | portable | not-applicable | not-applicable | preserved | mechanical-change | D-040 |\n| `AsyncSubject` | Compatibility-only | source-pinned | 48 | 48/48 | 46/48 | harness-rewrite, intentional-divergence | subject-hot | AbortSignal | changed | semantic-review | D-035, D-039, D-040, D-050 |\n| `BehaviorSubject` | Partial standalone mapping | source-pinned | 51 | 51/51 | 49/51 | harness-rewrite, intentional-divergence, portable | subject-hot | AbortSignal | changed | mechanical-change-and-semantic-review | D-035, D-039, D-040, D-050 |\n| `ColdObservable` | Compatibility-only | supplemental | 0 | supplemental | supplemental | supplemental | producer-per-direct-subscription | AbortSignal | changed | semantic-review | D-035, D-037, D-039, D-040, D-050 |\n| `config` | Test compatibility fixture | source-pinned | 3 | 3/3 | 3/3 | harness-rewrite | not-applicable | test-local-adapter | changed | adapter | D-039, D-040 |\n| `connectable` | Present; parity unverified | source-pinned | 2 | 2/2 | 2/2 | harness-rewrite, portable | subject-hot | AbortSignal | changed | mechanical-change | D-035, D-039, D-040 |\n| `ConnectableObservable` | Compatibility-only | source-pinned | 45 | 36/45 | 45/45 | harness-rewrite, intentional-divergence, portable | subject-hot | AbortSignal | changed | semantic-review | D-035, D-039, D-040 |\n| `EMPTY` | Present; parity unverified | source-pinned | 42 | 42/42 | 42/42 | harness-rewrite, intentional-divergence, portable | shared-active-platform | AbortSignal | changed | mechanical-change | D-040 |\n| `EmptyError` | Present; parity unverified | source-pinned | 13 | 13/13 | 13/13 | portable | not-applicable | not-applicable | changed | mechanical-change | D-040 |\n| `firstValueFrom` | Partial platform mapping | supplemental | 0 | supplemental | supplemental | supplemental | shared-active-platform | AbortSignal | changed | mechanical-change-and-semantic-review | D-040 |\n| `fromEventPattern` | Present; parity unverified | source-pinned | 1 | 1/1 | 1/1 | harness-rewrite | shared-active-platform | AbortSignal | changed | mechanical-change \n\n\n\n\n# RxJS 9 beta.0 approval\n\n## Decision\n\nThe repository evidence approves `rxjs@9.0.0-beta.0` and the synchronized\nfour-package train to begin the RxJS 9 public beta under npm's `next` tag, once\nthe configured blocking CI jobs are green. RxJS 7 remains npm's `latest` line\nand remains maintained.\n\nThis approval does not publish a package, create a GitHub release, promote RxJS\n9 to `latest`, or approve the stable `9.0.0` release. Stable promotion requires\npublic beta feedback and a separate explicit decision. The version number is 9\nbecause the paused RxJS 8 effort predates this platform-based generation; RxJS\n8 was not silently shipped or erased.\n\n## Adoption evidence\n\nThe exact four package artifacts were packed and audited locally. An isolated,\noffline consumer installed the `rxjs`, `@rxjs/observable-polyfill`, and\n`@rxjs/test` tarballs and passed:\n\n- ESM imports and runtime behavior;\n- Node 22.13, 24.12, and advisory 26.5 `require(esm)` behavior;\n- strict public TypeScript declarations;\n- `@rxjs/test` virtual-time behavior;\n- a minified browser bundle using only the packed ESM files.\n\nThe browser bundle was 20,222 bytes. Packed artifact sizes were:\n\n| Package | Tarball bytes | Budget |\n| --------------------------- | ------------: | ------: |\n| `rxjs` | 183,920 | 250,000 |\n| `@rxjs/observable-polyfill` | 23,375 | 30,000 |\n| `@rxjs/test` | 47,270 | 60,000 |\n| `@rxjs/migrate` | 112,638 | 140,000 |\n\nThe audit found no source specs, CommonJS/browser/Webpack dialect copies, or\nmissing package documentation. The Nx first-release version dry run resolves\nthe complete train to `9.0.0-beta.0`.\n\n## Broader qualification\n\n- Focused product suites pass 51 polyfill, 750 RxJS, 75 test-harness, and 166\n migration tests.\n- Pinned Observable WPT passes all 52 URLs, 525 upstream subtests, and 52 exact\n implementation-identity attestations.\n- Current Chromium, Firefox, and WebKit pass the shared eight-case lifecycle\n and Symbol contract. Desktop and Mobile Safari are separate blocking\n SafariDriver jobs; Mobile Safari requires an actual iOS simulator.\n- Node, Deno, Bun, Webpack, bundle-size, and performance evidence passes the\n checked-in gates described in [RELEASE_GATES.md](RELEASE_GATES.md).\n- The representative migration program has three completed RxJS 7 migrations\n and one correct safe stop across Vitest, Mocha, Jest, application/library,\n cold, platform-shared, mixed, and unsupported contracts.\n\n## Known non-blockers\n\nThe complete source-pinned RxJS 7 corpus retains 39 cold and 22 fallback\nfailures. Every one is a reviewed platform-lifecycle divergence or unsupported\narbitrary-subscribable compatibility case. They are executable migration\nevidence, not hidden failures and not a promise of an RxJS 7 compatibility\nruntime.\n\nLocal branded Safari execution was not forced by changing a persistent host\nsecurity setting. The clean-runner Safari and iOS simulator jobs are blocking\nconditions of publication, not waived evidence.\n\n## Publication boundary\n\nThe [release process](https://github.com/ReactiveX/rxjs/blob/master/docs/RELEASE_PROCESS.md)\nrequires a clean, synchronized `master` checkout and one interactive\n`pnpm release:beta 9.0.0-beta.0` command. It checks version identity,\npackage-local documentation, ESM-only exports, package gates, and npm dry runs;\nprints the exact tarball integrities; and then uses npm's OTP/WebAuthn flow for\neach public package. The supporting packages publish first and `rxjs` publishes\nlast. No CI credential or documentation application is part of publication.\n\n\n# RxJS 9 release gates\n\nThis document describes the executable environment and package gates for the\nRxJS 9 prerelease line. It is package documentation; it does not depend on the\nrepository documentation application.\n\nThe repository's [release runbook](https://github.com/ReactiveX/rxjs/blob/master/docs/RELEASE_PROCESS.md)\ndefines the clean-checkout requirement, interactive npm publication order,\nintegrity verification, and failure recovery. CI qualifies the source; only a\nmaintainer running the local release command can authorize publication.\n\n## Runtime matrix\n\n| Environment | Release role | Executable evidence |\n| -------------------------- | -------------------- | --------------------------------------------------------------------------- |\n| Node 22.13.0+ | Blocking | Package build, types, ESM import, Node `require(esm)`, and runtime contract |\n| Node 24 | Blocking | Full package and release gates, plus pinned Observable WPT |\n| Node 26 | Advisory during beta | The same package and runtime gates with a non-blocking CI result |\n| Current Chrome and Firefox | Blocking | Eight-case browser lifecycle and Symbol-extension contract |\n| Current desktop Safari | Blocking | The same contract through Apple SafariDriver |\n| Current Mobile Safari | Blocking | The same contract in an actual iOS simulator through Apple SafariDriver |\n| Current Playwright WebKit | Additional signal | The same contract, reported as WebKit rather than branded Safari |\n| Deno 2.8.0 | Blocking | Package-built runtime contract |\n| Bun 1.3.14 | Blocking | Package-built runtime contract |\n| Webpack 5.106.2 | Blocking | ESM resolution, production execution, and output-size budget |\n\nThe release-coherence checker pins the concrete Deno, Bun, Webpack, browser,\nNode, and Safari CI lanes. Updating a current-runtime version is therefore a\nreviewed release change rather than silent drift.\n\n## CI ownership\n\n| Workflow | Pull requests | `master` pushes |\n| ----------------- | --------------------------------------------------------- | -------------------------------------------------- |\n| Main CI | Package matrix plus exact migration evidence and tooling | Same blocking gates on every push |\n| TypeScript latest | RxJS compilation against the latest TypeScript | Same compatibility signal on every push |\n| Observable WPT | Blocking when platform, package, or harness paths change | Blocking pinned conformance on every push |\n| Release readiness | Blocking when release packages, scripts, or config change | Complete blocking environment matrix on every push |\n\nMain CI executes all 2,338 source-pinned RxJS 7 evidence cases in cold and\npolyfill modes and requires exact equality with the reviewed 2,299/39 and\n2,316/22 pass/failure case-ID sets. The raw audit commands still report the\nintentional divergences as ordinary failures; the CI verifier blocks any added\nfailure, unexpected pass, incomplete collection, or identity drift until the\nevidence is reviewed. Main CI also owns generated evidence freshness,\nbundle-analysis tests, SafariDriver unit tests, and active-workflow validation.\nRelease coherence rejects removal of required commands, lanes, or `master`\ntriggers.\n\n## Distribution contract\n\nEvery supported consumer receives the same `dist/esm` JavaScript. Browser,\nWebpack, ESM `import`, and Node `require(esm)` export conditions do not select\ntarget-specific copies. Deno and Bun support adds test infrastructure only; it\ndoes not add runtime code, dependencies, export conditions, or bundle bytes.\n\nThere is no CommonJS artifact. `require('rxjs')` is supported only through the\nNode 22.13+ `require(esm)` bridge and returns the same module identity and exact\nSymbols as ESM import.\n\n## Budgets\n\nThe checked-in budgets in `test/release/budgets.json` are blocking:\n\n- the representative minified Webpack bundle must not exceed 22,000 bytes;\n- the median map pipeline must process at least 5,000,000 values per second;\n- the median subscribe-and-abort loop must complete at least 30,000\n cancellations per second.\n- packed tarballs must stay under 250,000 bytes for `rxjs`, 30,000 bytes for\n the polyfill, 60,000 bytes for `@rxjs/test`, and 140,000 bytes for\n `@rxjs/migrate`.\n\nThe initial Node 24 evidence was 17,502 Webpack bytes, approximately 50.4\nmillion mapped values per second, and approximately 140,500 cancellations per\nsecond. The throughput floors deliberately leave substantial runner headroom;\nthe bundle ceiling leaves roughly 25% growth headroom while still catching a\nduplicate dialect or large accidental dependency.\n\nThe packed-adoption gate installs the local tarballs into an isolated consumer\nwith no registry access, then runs ESM, Node `require(esm)`, TypeScript, marble\ntesting, and a browser bundle. It also rejects source specs, duplicate output\ndialects, missing package documentation, and tarball-size regressions.\n\n## Commands\n\nFrom the repository root:\n\n```sh\npnpm run release:check\npnpm --filter rxjs run test:unit:audit:check\npnpm run test:bundle-analysis\npnpm run test:release:safari\npnpm run test:workflows\npnpm run test:release:runtime\npnpm run test:release:browsers\npnpm run test:release:safari\npnpm run test:release:webpack\npnpm run test:release:performance\npnpm run test:release:adoption\npnpm run test:wpt\n```\n\nDesktop and Mobile Safari execution is CI-owned because SafariDriver requires\nhost-level automation authorization. The Mobile Safari lane requests\n`platformName: iOS` and `safari:useSimulator: true`; Playwright WebKit is never\nsubstituted for that branded-browser gate.\n\nThe complete source-pinned RxJS 7 migration corpus is evidence, not a claim\nthat RxJS 9 implements every RxJS 7 behavior. Its reviewed intentional\ndivergences remain nonzero by design; the focused source suite, package gates,\nruntime matrix, and conformance suite are the blocking release checks.\n\n\n# RxJS 9 security assurance\n\nRxJS 9 uses a deliberately small release boundary. This document describes\nthe evidence and trust assumptions; it does not promise that the software is\nfree of vulnerabilities.\n\n## What users can rely on\n\n- The `rxjs` runtime depends only on the RxJS-owned\n `@rxjs/observable-polyfill`; that package has no runtime dependencies.\n- Pull requests and every `master` push run the package, type, browser, Safari,\n Web Platform Test, bundler, performance, migration, dependency-review,\n CodeQL, and OSV checks described in [RELEASE_GATES.md](RELEASE_GATES.md).\n- npm publication is not available to GitHub Actions. The repository stores no\n npm publishing token and has no publishing workflow, trusted publisher, or\n release App.\n- A maintainer publishes from a clean local `master` checkout with\n `pnpm release:beta `. The command builds and tests, packs the four\n packages, prints SHA-512 integrities, and runs npm publication dry runs before\n asking for irreversible confirmation.\n- npm's interactive OTP/WebAuthn flow authorizes each package. Supporting\n packages publish first and `rxjs` publishes last.\n- The command verifies npm's registry integrity and `next` tag for all four\n packages and confirms that `rxjs@latest` remains on RxJS 7.\n- An interrupted command can skip an already-published package only when the\n registry integrity equals the freshly packed tarball.\n\n## One-maintainer reality\n\nRxJS currently has one active maintainer. The same person authors, reviews,\nmerges, and releases changes. Pull requests expose diffs and run mandatory\nchecks, but RxJS does not claim independent human approval. OpenSSF's\nCode-Review score is therefore accepted rather than manipulated with\nceremonial approvals.\n\nThe publication boundary trusts that maintainer's local machine and npm\nauthentication. Interactive WebAuthn, required CI, dry runs, ordered\npublication, and registry verification reduce common mistakes and credential\nrisks; they do not remove the risk of a compromised maintainer machine or npm\naccount. Recovery codes are kept offline. Package publishing access requires\ntwo-factor authentication and disallows automation tokens after each new\npackage record exists.\n\n## Verify a release\n\nAfter installing with a lockfile, verify npm registry signatures:\n\n```sh\nnpm audit signatures\n```\n\nInspect the registry integrity and channels directly:\n\n```sh\nnpm view rxjs@9.0.0-beta.0 dist.integrity\nnpm view rxjs@next version\nnpm view rxjs@latest version\n```\n\nThe release operator records all four integrity values and the immutable GitHub\nRelease URL in the project-plan session log.\n\n## Vulnerability evidence\n\nOSV scanning runs on pull requests, every `master` push, and weekly. Anything\nreachable from runtime, build, or test tooling must be fixed or removed. The\ninherited legacy documentation-application toolchain is excluded from RxJS 9\nand tracked separately; its time-bounded exceptions do not change the release\npackage scans.\n\nProperty-based tests exercise the Observable lifecycle state machine. Package\nand release-script tests cover synchronized versions, clean-checkout guards,\ninteractive credential restrictions, publication order, npm channels, and\nintegrity comparisons.\n\n## What this does not prove\n\nPassing tests does not prove that source is bug-free. A matching registry hash\nproves that npm received the local tarball; it does not prove that the local\nmachine or maintainer account was uncompromised. The initial manual publication\ndoes not provide npm's CI provenance attestation. These are accepted tradeoffs\nfor an understandable sole-maintainer process.\n\n## OpenSSF in context\n\n[![OpenSSF Scorecard](https://api.scorecard.dev/projects/github.com/ReactiveX/rxjs/badge)](https://scorecard.dev/viewer/?uri=github.com/ReactiveX/rxjs)\n\nOpenSSF Scorecard is a useful repository-hygiene signal, not a release gate or\nthe project's primary security claim. Users assessing a specific RxJS 9\nversion should prefer required-CI history, registry signatures, exact package\nintegrity, and the tagged source commit.\n\n\n# Unsupported RxJS 7 surfaces\n\nThis generated catalog records RxJS 7 public imports and behavioral protocols that RxJS Next does not preserve as compatibility APIs. It is migration guidance, not an emulation commitment. The source inventory is pinned to RxJS 7 `7.x` at `e5351d02e225e275ac0e497c7b66eaa5f0c88791`.\n\nRegenerate it with `pnpm --filter rxjs run test:unit:unsupported:generate`; the corresponding `--check` gate rejects a stale document, a source-pin mismatch, missing required categories, or unclassified scheduler-bearing capabilities.\n\n## Summary\n\n| Measure | Count |\n| -------------------- | ----: |\n| Catalog groups | 27 |\n| Named surfaces | 147 |\n| Manual Review groups | 5 |\n| Replace groups | 17 |\n| Unsupported groups | 5 |\n\n## Dispositions\n\n- **Replace:** a supported Next or platform destination exists, but its imports, types, or lifecycle may differ.\n- **Manual review:** no mechanical rewrite is safe without reviewing cancellation, sharing, timing, or ownership.\n- **Unsupported:** no accepted Next compatibility contract exists.\n- **Test only:** any adapter is limited to evidence infrastructure and must not become an application migration.\n- **Removed:** the surface has no replacement and should disappear.\n\n## Imports and package paths\n\n| RxJS 7 surface | Disposition | Migration direction | Why | Decisions |\n| ------------------------------------------------------------------------------------------------------------- | ------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ | ------------------- |\n| `rxjs/operators`
`root-imported operator functions`
`source.pipe(...)` | Replace | Import exact Symbols from rxjs/ and invoke source[symbol](...). Use rxjs/pipe only for deliberate Symbol composition. | RxJS Next does not publish the RxJS 7 pipeable-function or string-named .pipe surface. | D-003, D-039, D-050 |\n| `rxjs:Observable`
`rxjs:Subscriber` | Replace | Use the active realm's ambient Observable and Subscriber after @rxjs/observable-polyfill initialization when needed. | The platform owns these constructors; the rxjs root does not re-export compatibility classes for them. | D-039, D-040, D-041 |\n| `rxjs/testing`
`TestScheduler`
`VirtualTimeScheduler`
`VirtualAction` | Replace | Use @rxjs/test rxTest() and its explicit cold(), hot(), observable(), virtual host-time, and assertion helpers. | The public scheduler classes and manual TestScheduler mode are not part of the Next runtime or test contract. | D-012, D-033, D-039 |\n| `rxjs/ajax`
`rxjs/fetch`
`rxjs/webSocket`
`ajax`
`fromFetch`
`webSocket`
`WebSocketSubject` | Manual Review | Use platform fetch, XMLHttpRequest, WebSocket, EventTarget.when, or an application adapter selected for the required cancellation and sharing contract. | RxJS Next does not currently publish the RxJS 7 DOM specialty packages or their wrapper types. | D-039, D-040 |\n| `rxjs/internal/*`
`rxjs/src/*`
`unexported package paths` | Unsupported | Replace with an accepted public Next subpath or application-owned code after semantic review. | RxJS 7 internals are not preserved as public package contracts and must not be revived to satisfy migration tests. | D-039, D-040 |\n| `bindCallback`
`bindNodeCallback`
`scheduled`
`using`
`isObservable` | Manual Review | Wrap callback or resource ownership explicitly with Observable and AbortSignal; use platform conversion or capability-specific mappings where applicable. | No accepted public Next function preserves these RxJS 7 imports and complete overload contracts. | D-039, D-040, D-049 |\n| `ObjectUnsubscribedError`
`UnsubscriptionError` | Unsupported | Use platform error and AbortSignal reason handling or an application-owned aggregate error contract. | These errors belong to removed RxJS 7 Subscription and closed-Subject internals. | D-039, D-040 |\n\n## Types\n\n| RxJS 7 surface | Disposition | Migration direction | Why | Decisions |\n| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | ------------------- |\n| `UnaryFunction`
`OperatorFunction`
`MonoTypeOperatorFunction` | Replace | Use ordinary typed functions with exact Symbol invocation or rxjs/pipe composition. | RxJS Next does not publish the pipeable-operator type family. | D-039, D-050 |\n| `Subscription`
`SubscriptionLike`
`Unsubscribable`
`TeardownLogic` | Replace | Use AbortController, AbortSignal, SubscribeOptions, and Subscriber.addTeardown inside producers. | subscribe() returns undefined and cancellation is signal-owned; no Subscription facade is published. | D-039, D-041, D-049 |\n| `ObservableInput`
`ObservableLike`
`InteropObservable`
`Subscribable`
`SubscribableOrPromise`
`ReadableStreamLike` | Replace | Use the ambient ObservableValue/platform Observable.from input contract and review custom inputs manually. | The platform conversion boundary deliberately excludes arbitrary subscribables and legacy observable interop. | D-039, D-049 |\n| `NextObserver`
`ErrorObserver`
`CompletionObserver`
`PartialObserver`
`SubjectLike`
`Connectable` | Replace | Use ambient Observer/Subscriber shapes or the concrete intentional Subject/connectable APIs; define application protocols locally when needed. | These RxJS 7 helper interfaces are not a public Next import family. | D-035, D-039, D-040 |\n| `SchedulerLike`
`SchedulerAction`
`TimestampProvider` | Replace | Use host timing APIs, Date.now-compatible narrow providers where explicitly documented, and @rxjs/test virtual host time. | There is no general public scheduler abstraction in RxJS Next. | D-012, D-033, D-039 |\n| `FactoryOrValue`
`ObservedValueOf`
`ObservedValueUnionFromArray`
`ObservedValuesFromArray`
`ObservedValueTupleFromArray`
`ObservableInputTuple`
`Cons`
`Head`
`Tail`
`ValueFromArray`
`Falsy`
`TruthyTypesOf` | Unsupported | Use inference from the accepted Next API or application-owned utility types; do not deep-import RxJS internals. | These RxJS 7 implementation-facing inference helpers are not stable Next public types. | D-039, D-040 |\n| `GroupedObservable`
`Timestamp`
`TimeInterval` | Replace | Use the structural keyed group view, structural timestamp result, or TimeInterval exported by the exact rxjs/time-interval capability as applicable. | The RxJS 7 root type imports are not preserved even where a capability exposes an intentional structural or subpath-specific result. | D-003, D-039, D-040 |\n\n## Schedulers and scheduler overloads\n\n| RxJS 7 surface | Disposition | Migration direction | Why | Decisions |\n| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------- |\n| `asap`
`asapScheduler`
`async`
`asyncScheduler`
`queue`
`queueScheduler`
`animationFrame`
`animationFrameScheduler`
`Scheduler`
`VirtualTimeScheduler`
`VirtualAction` | Replace | Use virtualizable host timing and task APIs; use @rxjs/test for deterministic tests. | RxJS Next does not publish scheduler instances or scheduler classes. | D-012, D-033, D-039 |\n| `animationFrames`
`auditTime`
`bufferTime`
`concat`
`debounceTime`
`delay`
`empty`
`endWith`
`expand`
`from`
`generate`
`groupBy`
`interval`
`observeOn`
`pairs`
`publishReplay`
`range`
`sampleTime`
`scheduled`
`shareReplay`
`startWith`
`subscribeOn`
`throwError`
`throttleTime`
`timeInterval`
`timeout`
`timeoutWith`
`timer`
`timestamp`
`windowTime` | Manual Review | Remove only an explicitly classified scheduler overload and verify ordering with host-time behavior; otherwise retain the source and stop automation. | Current capabilities use host scheduling or narrow clock providers, and the port harness adapter is not a production SchedulerLike contract. | D-012, D-033, D-034, D-039 |\n\n## Interop protocols\n\n| RxJS 7 surface | Disposition | Migration direction | Why | Decisions |\n| ------------------------------------------------------------------------------------------------------------------------------- | ------------- | ---------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- | ------------------- |\n| `observable`
`Symbol.observable`
`@@observable`
`InteropObservable` | Unsupported | Expose a platform-supported ObservableValue category or wrap the source explicitly in the active realm. | Legacy observable interop is outside the accepted platform Observable.from contract. | D-039, D-049 |\n| `objects with subscribe()`
`lowerCaseO`
`asInteropObservable`
`custom Subscribable` | Manual Review | Write an explicit application adapter that owns cancellation and terminal behavior, or choose a supported platform input category. | The 15 executable compatibility-only failures deliberately preserve this unsupported input boundary. | D-039, D-049 |\n| `foreign-realm Observable`
`cross-window Observable`
`cross-worker Observable`
`borrowed symbols on unrelated objects` | Unsupported | Initialize each realm independently and bridge values through an explicit application protocol. | RxJS does not traverse realms or promise generic Symbol borrowing onto unrelated receivers. | D-041, D-048, D-049 |\n| `Observable.lift`
`source/operator fields`
`custom Operator` | Replace | Use exact Symbol composition and the versioned derived-construction protocol through supported public capabilities. | The RxJS 7 lift/source/operator protocol is removed and is not a public Next subclass hook. | D-037, D-039, D-049 |\n\n## Deprecated and removed aliases\n\n| RxJS 7 surface | Disposition | Migration direction | Why | Decisions |\n| --------------------------------------------------------------------------------------------------------------------------------- | ------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- | ------------------- |\n| `combineAll`
`exhaust`
`flatMap`
`pipeable partition` | Replace | Use combineLatestAll, exhaustMap(identity), mergeMap, or Observable[partition] respectively. | The deprecated RxJS 7 names are not public Next Symbol identities; migration uses their canonical accepted mappings. | D-003, D-039, D-049 |\n| `empty()`
`never()` | Replace | Use EMPTY and NEVER. | The deprecated creation functions are not retained as callable Next aliases. | D-039, D-040 |\n| `mapTo`
`concatMapTo`
`mergeMapTo`
`switchMapTo`
`pluck` | Replace | Use map with a constant or property projection, or the corresponding canonical flattening Symbol with an explicit projection. | Migration may preserve behavior through exact mappings, but the deprecated pipeable function/import shape is not supported. | D-003, D-039 |\n| `pipeable combineLatest`
`pipeable concat`
`pipeable merge`
`pipeable race`
`pipeable zip`
`onErrorResumeNextWith` | Replace | Use the accepted unified or With-form exact Symbol and its documented source-array/result-selector mapping. | Legacy pipeable aliases are migration inputs, not preserved function exports. | D-003, D-039, D-049 |\n| `multicast`
`publish`
`publishBehavior`
`publishLast`
`publishReplay`
`refCount` | Manual Review | Prefer share, shareReplay, connect, or connectable with an explicit connector/reset contract; exact legacy-named Symbols remain migration evidence, not a compatibility promise. | Producer sharing, replay, reset, and ref-count semantics require explicit lifecycle review. | D-035, D-039, D-049 |\n| `new BehaviorSubject(value)`
`new ReplaySubject(size, windowTime, scheduler)`
`ColdSubject` | Replace | Use behaviorSubject(value), replaySubject({ size, maxAge }), or the advanced PerSubscriptionSubjectBase only for a justified custom hot Subject. | D-050 stabilizes lowercase factories and removes the misleading ColdSubject name without aliases. | D-035, D-036, D-050 |\n| `eachValueFrom`
`bufferedValuesFrom` | Replace | Use one of iterateEachValue, iterateBufferedValues, iterateLatestValue, or iterateNextValue from its exact Symbol subpath. | The exploratory standalone helpers were removed so buffering and dropping policy stays explicit. | D-038, D-039 |\n\n## Review rule\n\nA migration tool may automate only a cataloged **replace** mapping whose target capability and contract are also present in the migration evidence ledger. It must stop with a structured diagnostic for **manual review**, **unsupported**, **test only**, or **removed** entries. Adding a compatibility runtime, scheduler abstraction, import alias, interop protocol, or deep-import bridge requires a new accepted architecture decision.\n\n\n# AIO project tooling\n\nThis document gives an overview of the tools that we use to generate the content for the RxJS website.\n\nThe application that actually renders this content can be found in the `apps/rxjs.dev/src` folder.\nThe handwritten content can be found in the `apps/rxjs.dev/content` folder.\n\nEach subfolder in this `apps/rxjs.dev/tools/` folder contains a self-contained tool and its configuration. There is\na `README.md` file in each folder that describes the tool in more detail.\n\n## transforms\n\nAll the content that is rendered by the RxJS docs application, and some of its configuration files,\nare generated from source files by [Dgeni](https://github.com/angular/dgeni). Dgeni is a general\npurpose documentation generation tool.\n\nMarkdown files in `apps/rxjs.dev/content`, code comments in the core Angular source files and example\nfiles are processed and transformed into files that are consumed by the RxJS docs application.\n\nDgeni is configured by \"packages\", which contain services and processors. Some of these packages are\ninstalled as `node_modules` from the [dgeni-packages](https://github.com/angular/dgeni-packages) and\nsome are specific to the RxJS project.\n\nThe project specific packages are stored in the `apps/rxjs.dev/tools/transforms` folder. See the\n[README.md](transforms/README.md) for more details.\n\n\n# Overview\n\nAll the content that is rendered by the AIO application, and some of its configuration files, are\ngenerated from source files by [Dgeni](https://github.com/angular/dgeni). Dgeni is a general purpose\ndocumentation generation tool.\n\nMarkdown files in `/aio/content`, code comments in the core Angular source files and example files\nare processed and transformed into files that are consumed by the AIO application.\n\nDgeni is configured by \"packages\", which contain services and processors. Some of these packages are\ninstalled as `node_modules` from the [dgeni-packages](https://github.com/angular/dgeni-packages) and\nsome are specific to the AIO project.\n\nThe project specific packages are stored in this folder (`aio/tools/transforms`).\n\nIf you are an author and want to know how to generate the documentation, the steps are outlined in\nthe top level [README.md](../../README.md#guide-to-authoring).\n\n## Root packages\n\nTo run Dgeni, you must specify a root package, which acts as the entry point to the documentation\ngeneration.\nThis root package, in turn requires a number of other packages, some are defined locally in the\n`tools/transforms` folder, such as `tools/transforms/cheatsheet-package` and\n`tools/transforms/content-package`, etc. And some are brought in from the `dgeni-packages` node\nmodules, such as `jsdoc` and `nunjucks`.\n\n* The primary root package is defined in `tools/transforms/angular.io-package/index.js`. This package\nis used to run a full generation of all the documentation.\n* There are also root packages defined in `tools/transforms/authors-package/*-package.js`. These\npackages are used by the documentation authors when writing docs, since it allows them to run partial\ndoc generation, which is not complete but is faster for quickly seeing changes to the document that\nyou are working on.\n\n## Other packages\n\n* angular-base-package\n* angular-api-package\n* angular-content-package\n* content-package\n* links-package\n* post-process-package\n* remark-package\n* target-package\n\n## Templates\n\nAll the templates for the angular.io dgeni transformations are stored in the `tools/transforms/templates`\nfolder. See the [README](./templates/README.md).\n\n\n# Decision Tree Generator\n\n## Purpose\n\nManage a decision tree in YAML for choosing an operator and generate JSON to be consumed by the docs web app.\n\n## Goals\n\n- Port the first version of the decision-tree-widget into Angular\n- Flatten the JSON structure and make it easy to work with in the docs web app\n- Consume URI paths and other relevant from the docs generation task vai Dgeni\n- Keep the decision tree work scalable and easy to work with by keeping the linked list structure in the YAML tree\n\n## Prior Art\n\nVersion 1 was in the old docs site and used YAML, snabbdom, RxJS, and hyperscript-helpers. The YAML for version 1 version was ported into the new version with minor tweaks.\n\n## Tech\n\n- Node\n- TypeScript\n- TS-Node\n- Jest\n- YAML\n\n## Dependencies\n\nGenerating the JSON requires:\n\n- The decision tree YAML, located in `/src`\n- The generated `api-list.json`, which can be generated by running `pnpm run docs` at the root level of `apps/rxjs.dev`\n\n## Setup & Build\n\n```shell\npnpm install && pnpm run build\n```\n\n## Development\n\nAny changes to the YAML tree or any of the TypeScript scripts will generate a new JSON tree\n\n```shell\npnpm run watch\n```\n\n## Distribution\n\nAfter a `pnpm run build` the JSON is output to `apps/rxjs.dev/src/generated/app/decision-tree-data.json` to be consumed by the web application.\n\nThere's also an npm script at the root level of the `apps/rxjs.dev` to generate the JSON tree: `docs-decision-tree`.\n\n## Testing\n\nRun a watch task when writing tests\n\n```shell\npnpm run test:watch\n```\n\nFull test\n\n```shell\npnpm run test\n```\n\nRun coverage\n\n```shell\npnpm run test:coverage\npnpm run test:watch:coverage\n```\n\n## TODO\n\n- Consider moving this work into a Dgeni package so it can be generated in the same way the other doc information is generated\n\n\nThis folder contains the dgeni templates that are used to generate the API docs\n\nGenerally there is a template for each docType. Templates can extend and/or include\nother templates. Templates can also import macros from other template files.\n\n# Template inheritance\n\nWhen extending a template, parent must declare blocks that can be overridden by the\nchild. The template extension hierarchy looks like this (with declared blocks in parentheses):\n\n- layout/base.template.html (base)\n - module.template.html\n - layout/api-base.template.html (jumpNav, jumpNavLinks, whatItDoes, infoBar, securityConsiderations,\n deprecationNotes, howToUse, details)\n - class.template.html\n - directive.template.html\n - enum.template.html\n - var.template.html\n - const.template.html\n - let.template.html\n - decorator.template.html\n - function.template.html\n - interface.template.html\n - type-alias.template.html\n - pipe.template.html\n\n# Doc Properties\n\nIt is useful to know what properties are available on each doc type when working with the templates.\nThe `typescript` Dgeni package is now written in TypeScript and there is a class for each of the types of\nAPI document. See https://github.com/angular/dgeni-packages/tree/master/typescript/src/api-doc-types.\nThis is a good place to go to see what properties you can use in the templates.\n\n\n# `@rxjs/migrate`\n\nDeterministic source-migration tools used by the RxJS 9 agent-first\nmigration workflow. The current well-tested path migrates RxJS 7\n`TestScheduler` marble specs from Mocha/Chai to ordinary Vitest specs that call\n`rxTest` directly. The engine is not a complete migration product and does not\nchoose lifecycle semantics; see\n[`docs/MIGRATION_TOOLING_DESIGN.md`](docs/MIGRATION_TOOLING_DESIGN.md).\n\nThe package separates two concerns:\n\n- RxJS semantics: `TestScheduler.run` to `rxTest`, pipeable operators to exact\n Symbol calls, and reviewed argument adapters.\n- Test framework syntax: an optional Mocha/Chai-to-Vitest adapter. Other\n source and target frameworks can supply the same small `FrameworkAdapter`\n interface, or preserve their existing framework unchanged.\n\nThe semantic transform also operates on production TypeScript containing\nRxJS 7 `pipe(...)` expressions. It does not require a test framework or a\n`TestScheduler` declaration.\n\n## CLI\n\nStart with a dry run:\n\n```sh\nnpx rxjs-migrate \\\n --source-root . \\\n --source-repo https://github.com/example/project \\\n --source-sha abc123 \\\n --mode cold \\\n --framework mocha-chai-vitest \\\n test/example-spec.ts\n```\n\nThe command writes nothing unless `--write --out-dir ` is present.\nWritten files are normal, locally named source files. They are meant to be\nreviewed, checked in, and maintained by the destination project; there is no\nruntime generator. Successful and refused batches are emitted as versioned\nJSON with the engine and capability-registry versions. Exit codes distinguish\nsuccess (`0`), a structured migration refusal (`1`), invalid arguments (`2`),\nand operational failure (`3`). A refused batch writes no files.\n\nUse `--framework preserve` for Jest, Node test runner, another target, or a\nframework migration handled by another tool. The JavaScript API accepts a\ncustom `FrameworkAdapter` when syntax conversion should happen in the same\npass.\n\n## JavaScript API\n\n```ts\nimport { defaultCapabilityRegistry, migrateTestSource, type FrameworkAdapter } from '@rxjs/migrate';\n\nconst result = migrateTestSource(source, {\n mode: 'cold',\n capabilityRegistry: defaultCapabilityRegistry,\n frameworkAdapter: myFrameworkAdapter satisfies FrameworkAdapter,\n provenance: {\n repository: 'https://github.com/example/project',\n sha: 'abc123',\n path: 'test/example-spec.ts',\n },\n});\n```\n\n`defaultCapabilityRegistry` is a versioned, fixture-backed contract, not a\nclaim of complete RxJS 7 compatibility. A custom registry must use the same\nschema and name the installed engine version; incompatible registries are\nrefused without changing source bytes. Unsupported constructs remain visible\nas diagnostics instead of being hidden behind compatibility helpers.\n\n## Mechanically supported subset\n\nThe default registry currently proves direct, unshadowed `pipe(...)` calls for\n`filter`, `map`, `takeUntil`, `bufferCount`, `concatMap`, `concatAll`,\n`switchAll`, `debounceTime`, `audit`, and `auditTime`, subject to each mapping's\npublished arity and overload preconditions. The registry is the authoritative\nmachine-readable list. Aliases are tracked, while shadowed bindings, mixed\nunsupported pipelines, scheduler overloads, malformed input, and unsupported\nframework assertions are refused or preserved with structured findings.\n\nThe package ships no MCP binary, export, or runtime dependency. D-046 keeps\nthe library and dry-run-first CLI as the only deterministic engine surfaces.\n\nThe representative agent-workflow matrix and its deliberately bounded claims\nare documented in\n[`docs/MIGRATION_QUALIFICATION.md`](docs/MIGRATION_QUALIFICATION.md).\nLive harness qualification is separate from deterministic engine correctness.\n\n## Contract and Skill integrity\n\n`parseMigrationContractManifest` validates the versioned migration decision\nrecord. `assessMigrationContractReadiness` separately reports unresolved\nlifecycle choices, approvals, diagnostics, verification, and blockers so\nschema validity is never mistaken for completion.\n\nThe Node-only `@rxjs/migrate/skill` subpath computes and verifies the canonical\nSkill's deterministic SHA-256 content descriptor and manages generated harness\ndiscovery copies without creating a second authored workflow.\n\nInstall the canonical Skill into a repository with the package command:\n\n```sh\nnpx rxjs-migrate-skill install --harness codex --project-root .\n```\n\nUse `--harness cursor` for Cursor; Codex and Cursor share the open\n`.agents/skills` placement. Use `--harness claude` for Claude Code's\n`.claude/skills` placement. The same command supports `check`, `update`, and\n`remove`. It refuses to overwrite or remove local modifications unless the\ndeveloper supplies `--force`, and each installed copy records its package\nversion and canonical digest in `.rxjs-migrate-skill.json`.\n\n## Review requirements\n\nEvery migrated test should contain a direct `await rxTest(...)` call. Choose\n`cold()` only for producer-per-subscription evidence; use `observable()` when\nthe test should exercise the constructor installed at\n`globalThis.Observable`. Review scheduler arguments, multiple observations,\nsharing, ref counting, cancellation, and restart behavior before accepting a\nmechanical migration.\n\n\n# `@rxjs/observable-polyfill`\n\nConditional fallback for the web-platform Observable and Subscriber contracts\nused by RxJS 9.\n\n```sh\nnpm install @rxjs/observable-polyfill@next\n```\n\n```ts\nimport '@rxjs/observable-polyfill';\n```\n\nThe package preserves an existing callable `globalThis.Observable`. When the\nrealm has no implementation, it installs the RxJS fallback together with its\npaired Subscriber and supported platform methods. It does not probe a native\nimplementation for conformance, replace it, or make the platform Observable\nbehave like an RxJS 7 cold Observable.\n\nUse `getObservablePolyfillInfo()` when diagnostics need to distinguish the\nRxJS fallback from a native or foreign constructor:\n\n```ts\nimport { getObservablePolyfillInfo } from '@rxjs/observable-polyfill';\n\nconsole.log(getObservablePolyfillInfo()); // metadata for the RxJS fallback, or undefined\n```\n\nCancellation and teardown use `AbortSignal` and Subscriber lifecycle. The\npackage also conditionally supplies the supported `EventTarget.when()` surface\nwithout replacing an existing callable implementation.\n\nThe package requires Node 22.13+ and publishes one ESM implementation for\nbrowser, Webpack, import, and Node `require(esm)` resolution. Observable WPT is\npinned at an exact upstream revision under `test/wpt`; the strict gate requires\ncomplete results and exact RxJS bundle identity in every fallback realm.\n\nThis package is the platform layer. RxJS operators and intentional\nproducer-per-subscription primitives belong to the\n[`rxjs` package](https://github.com/ReactiveX/rxjs/tree/master/packages/rxjs).\n\n\n# Observable WPT harness\n\nThis directory runs the pinned Web Platform Tests (WPT) for the web-platform\n`Observable` against the implementation in\n`packages/observable-polyfill/src/index.ts`.\n\nThe harness is intentionally test infrastructure; conformance comes from the\nimplementation behavior it measures. The current fallback passes this pinned\nsuite. `pnpm run test:wpt` exits nonzero if any upstream test or subtest fails,\nerrors, times out, or does not run. A separately named baseline command remains\navailable for diagnosing stable behavior. Both modes are strict about\ncompleteness, provenance, and which implementation ran.\n\n## Prerequisites\n\nThe blocking WPT job runs on Node 24, and the repository engine declaration\naccepts Node 24 alongside the retained Node 18 and Node 20 development\nruntimes. pnpm 10.34.5 is the repository package manager. Confirm the\nactive versions before the first run:\n\n```sh\nnode --version\npnpm --version\n```\n\nPython 3.9 or newer is also required. `pnpm run wpt:doctor` verifies the selected\nPython interpreter and every other harness prerequisite.\n\n## What is pinned\n\n- Written Observable reference: WICG/observable `spec.bs` at\n `d74bace7cf80200a01c81cfe20961e29ac7fa3d8`. This explains the rules and helps\n diagnose failures; it is not a second executable gate.\n- WPT commit:\n `6a009d73f0d315941b90cac13a9523a2a08c631b`\n- Chrome for Testing and ChromeDriver: `150.0.7871.126`\n- WPT test URLs: `expected-test-urls.json`\n- Imported-file provenance and Git blob hashes: `provenance.json`\n- Browser archive URLs, sizes, and checksums: `browser-lock.json`\n\nOnly the 29 files in `dom/observable/tentative/`—including the\n`EventTarget.prototype.when` coverage in that directory—and this exact support\nclosure are committed:\n\n- `LICENSE.md`;\n- `common/gc.js`;\n- `interfaces/dom.idl` and `interfaces/observable.tentative.idl`;\n- `resources/testharness.js`, `resources/testharnessreport.js`,\n `resources/idlharness.js`, and the Web IDL parser file they use.\n\nThat is 37 upstream files in total. `wpt:verify-import` derives the support\nclosure from the test sources and rejects both a missing dependency and an\nunexplained extra file.\nThe much larger official WPT checkout used to run them is a sparse, shallow\ncache keyed by the WPT commit. Imported upstream files remain byte-for-byte\nunchanged under `upstream/`; all instrumentation is generated in the ignored\n`.cache/rxjs-wpt/` tree.\n\n## Proving that RxJS ran\n\nThe pinned browser is required to expose its native `Observable`,\n`Observable.prototype.subscribe`, and `EventTarget.prototype.when` in the\nwindow, dedicated-worker, and same-origin iframe realms used by this suite.\nBefore each test realm runs upstream code, the generated bootstrap:\n\n1. captures the native references and property descriptors;\n2. verifies that the native slots can be replaced in the disposable test\n realm;\n3. masks those slots and executes a synchronous bundle built directly from the\n current polyfill source;\n4. records the installed constructor, `subscribe`, and `when` identities plus\n the bundle SHA-256; and\n5. exposes a non-enumerable, test-only attestation function.\n\nEvery generated WPT URL receives exactly one named attestation subtest,\nregistered after the upstream source has established any `setup()` properties.\nThe\nreport auditor independently requires it to pass with the expected bundle hash\nand exact installed identities, and requires those identities to differ from\nthe captured native ones. For the four iframe-using URLs, that one subtest waits\nfor all nine statically reviewed child-realm accesses and verifies every child\nbefore it can pass. The auditor also rejects missing or duplicate test URLs,\nmissing worker or iframe instrumentation, different bundle identities,\nrestored native globals, and any expectation metadata that tries to allowlist\nattestation.\n\nThe iframe access patterns in the pinned suite are reviewed in `config.json`.\nChanging WPT to introduce another realm-creation pattern makes\n`wpt:verify-import` fail until that pattern and its instrumentation are\nreviewed.\n\n## Commands\n\nRun commands from the repository root:\n\n| Command | Purpose |\n| ---------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |\n| `pnpm run wpt:doctor` | Verify the vendored import, build and hash the test bundle, prepare the shadow tree, provision or verify the WPT Python environment, resolve the pinned runner/browser, and probe native exposure and replaceable descriptors. |\n| `pnpm run wpt:verify-import` | Verify provenance hashes, dependency closure, generated URL inventory, and reviewed realm patterns without running a browser. |\n| `pnpm run test:wpt` | Run every pinned URL and fail unless every upstream WPT test and subtest passes. This is the default conformance command. |\n| `pnpm run test:wpt:baseline` | Run the same attested suite but compare behavior with the checked-in known-failure baseline. This is a harness diagnostic, not conformance. |\n| `pnpm run wpt:import -- --commit <40-character-sha>` | Deliberately replace the vendored subset from an exact WPT commit and regenerate provenance and the URL inventory. |\n| `pnpm run wpt:update-expectations` | Run three complete attested suites, require identical statuses, and regenerate expectation metadata and the result baseline. |\n\nThe first browser run needs network access to populate the pinned browser and\nsparse runner caches and to create the runner's Python environment. Later runs\nreuse those exact artifacts. To prove a warm run is self-contained:\n\n```sh\nRXJS_WPT_OFFLINE=1 pnpm run test:wpt:baseline\n```\n\n`RXJS_WPT_OFFLINE=1 pnpm run test:wpt` runs strict conformance from the same\ncaches and is expected to pass for the pinned implementation and browser.\nOffline mode fails immediately if a required cached artifact is absent. Useful\ntest-only overrides are listed below. Browser runs also disable Chrome\nbackground networking, component updates, sync, metrics uploads, and pings;\nWPT test traffic remains on the official runner's local servers.\n\n| Variable | Meaning |\n| ---------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- |\n| `RXJS_WPT_CACHE_DIR` | Replace the default `.cache/rxjs-wpt` cache root. |\n| `RXJS_WPT_REPORTS_DIR` | Write run reports somewhere other than the cache's `reports/` directory. |\n| `RXJS_WPT_RUNNER_ROOT` | Use an existing WPT checkout, which must be at the pinned commit. |\n| `RXJS_WPT_PYTHON_BINARY` | Select the Python interpreter used to create the version-keyed WPT environment. |\n| `RXJS_WPT_CHROME_BINARY` and `RXJS_WPT_CHROMEDRIVER` | Use an explicit matching browser pair; both must be set. |\n| `RXJS_WPT_IMPORT_CHECKOUT` | Import from an existing WPT checkout instead of creating the temporary sparse checkout. |\n| `RXJS_WPT_ALLOW_BROWSER_DRIFT=1` | Permit a non-pinned browser version for the scheduled advisory run. Do not use this for the blocking conformance job. |\n\n## Reading results\n\nEach run writes a timestamped directory under\n`.cache/rxjs-wpt/reports/`. It contains:\n\n- `wptreport.json`: the complete structured WPT report;\n- `wpt.raw.log`: the raw log accepted by WPT's expectation updater;\n- `wpt.log`: the human-readable runner log;\n- `audit.json`: the machine-readable conformance/completeness result;\n- `status-diff.txt`: the same readable status and failure summary printed in\n the terminal;\n- `attestations.json`: the expected bundle identity recorded for every\n generated test URL.\n\nThe terminal always prints preparation and browser-execution progress, status\ncounts, attestation counts, every non-passing URL and subtest, and paths to the\nstructured report and full runner logs.\n\n`pnpm run test:wpt` succeeds only when the official runner completes, every URL\nruns exactly once, every identity attestation passes, the report is well\nformed, and every upstream result passes. `pnpm run test:wpt:baseline` retains the\nstable-result comparison for deliberate harness diagnostics. In baseline mode,\nboth an unexpected failure and an unexpected pass are mismatches. The current\nbaseline contains 52 `OK` URLs and 525 passing upstream subtests.\n\n## Updating WPT\n\nRxJS maintainers own the written-spec and WPT pins. A newer revision becomes\nthe project target only through an explicit reviewed change:\n\n1. Import an exact 40-character WPT commit with `pnpm run wpt:import -- --commit\n`.\n2. Review every vendored-file, provenance, URL-inventory, dependency-closure,\n and realm-pattern change, plus the corresponding written Observable rules.\n3. Run `pnpm run wpt:verify-import`.\n4. Update the complete-result baseline without adding any failure, skip, or\n multi-status allowance.\n5. Run `pnpm run test:wpt:baseline` and strict `pnpm run test:wpt`; both must\n report 52/52 URLs, 525/525 upstream subtests, and 52/52 exact RxJS\n attestations for the current pin, or the corresponding fully passing totals\n reviewed for the proposed pin.\n\nIf a proposed upstream revision or browser is nondeterministic or failing, it\ndoes not become the pinned target. A scheduled run against newer Chrome is\nadvisory and does not silently change the vendored tests, written reference,\nor all-pass requirement.\n\nCI runs the strict pinned conformance command as a path-filtered blocking check\nwith fixed process concurrency and a fixed wall-clock timeout. A scheduled\nadvisory job uses the current stable Chrome for Testing with browser-version\ndrift enabled. Both jobs always upload the raw report, audit, logs, URL\ninventory, and attestation identities.\n\n\n# `rxjs` 9 beta\n\nRxJS 9 extends the web-platform Observable with exact Symbol-keyed operators\nand factories, plus a small set of intentional RxJS primitives. It uses a\nnative `Observable` when one exists and otherwise initializes the separately\npublished `@rxjs/observable-polyfill` fallback.\n\nThis is prerelease software. Install the current beta with:\n\n```sh\nnpm install rxjs@next\n```\n\nRxJS 7 remains npm's `latest` line during the beta and continues to be\nmaintained.\n\n## Why version 9?\n\nWork on RxJS 8 began years ago and paused while Web Platform Observables were\nfinalized. RxJS 9 is a new platform-based generation, not a release of that\npaused implementation. The version communicates that architectural break and\nprevents the old RxJS 8 work from being mistaken for this product.\n\n## Use an operator\n\n```ts\nimport { ColdObservable } from 'rxjs';\nimport { map } from 'rxjs/map';\nimport { pipe } from 'rxjs/pipe';\nimport { scan } from 'rxjs/scan';\n\nconst source = new ColdObservable((subscriber) => {\n subscriber.next(1);\n subscriber.next(2);\n subscriber.next(3);\n subscriber.complete();\n});\n\nsource[pipe](\n (values) => values[map]((value) => value * 2),\n (values) => values[scan]((total, value) => total + value, 0)\n).subscribe(console.log); // 2, 6, 12\n```\n\nEach operator subpath exports its exact Symbol and installs only that\ncapability. Importing the root does not install the operator catalog.\n\n## Choose the lifecycle deliberately\n\n`new Observable(initializer)` follows the platform contract. Concurrent\nobservers share the active producer, the last observer leaving tears it down,\nand a later observer starts it again.\n\n`new ColdObservable(initializer)` creates one producer for every direct\nsubscription. Use it when producer-per-subscription behavior is part of the\napplication contract rather than assuming all Observables are cold.\n\nCancellation uses `AbortSignal`:\n\n```ts\nconst controller = new AbortController();\nsource.subscribe(console.log, { signal: controller.signal });\ncontroller.abort();\n```\n\n## ESM and Node `require()`\n\nThe package publishes one ESM implementation. Browser, Webpack, ESM import,\nand Node's `require(esm)` bridge resolve the same files and exact Symbols.\n\n```js\nconst { ColdObservable } = require('rxjs');\nconst { map } = require('rxjs/map');\n```\n\nThe bridge requires Node 22.13 or newer. It is not a CommonJS build and does\nnot support legacy CommonJS resolvers.\n\n## Documentation\n\n- [Security assurance and release verification](docs/SECURITY_ASSURANCE.md)\n- [API and import guide](docs/API.md)\n- [Migrate from RxJS 7](MIGRATION.md)\n- [Unsupported RxJS 7 surfaces](docs/UNSUPPORTED_RXJS_7_SURFACES.md)\n- [Migration evidence ledger](docs/MIGRATION_EVIDENCE_LEDGER.md)\n- [Release environments and budgets](docs/RELEASE_GATES.md)\n- [Beta.0 approval record](docs/PRERELEASE_APPROVAL.md)\n- [Contributing to the package](CONTRIBUTING.md)\n\nThe package export map in [`package.json`](package.json) is authoritative for\navailable public subpaths.\n\n\n# `@rxjs/test`\n\nImplementation-neutral virtual-time and marble testing for RxJS 9 Observable\ncontracts.\n\n```sh\nnpm install --save-dev @rxjs/test@next rxjs@next\n```\n\n```ts\nimport 'rxjs';\nimport { rxTest } from '@rxjs/test';\nimport { map } from 'rxjs/map';\n\nawait rxTest(({ cold, expectObservable }) => {\n const source = cold('-a-b-|', { a: 1, b: 2 });\n expectObservable(source[map]((value) => value * 10)).toBe('-a-b-|', {\n a: 10,\n b: 20,\n });\n});\n```\n\nUse `cold()` only when the test deliberately needs one producer per direct\nsubscription. Use `observable()` when the contract should exercise the active\nplatform Observable constructor. The package never installs a platform\nObservable for the consumer; import `rxjs` or\n`@rxjs/observable-polyfill` first when the realm does not already provide one.\n\n`rxTest` supplies scheduled work, hot/cold/platform sources, Observable and\nsubscription expectations, explicit time plans, and configurable deep-equality\nassertions. Failures use `RxTestAssertionError` and include structured assertion\ninformation.\n\nThe package requires Node 22.13+, publishes ESM only, and declares an exact peer\non the matching RxJS 9 prerelease train. The\n[`rxjs` migration guide](https://github.com/ReactiveX/rxjs/blob/master/packages/rxjs/MIGRATION.md)\nexplains how to review lifecycle choices when translating RxJS 7\n`TestScheduler.run` tests.\n"}