{"owner":"ReactiveX","repo":"rxjs","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md"],"files":{"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"}}