If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/dotnet/reactive shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across all four use cases

• Last commit 1d ago
• 21+ active contributors
• MIT licensed
• Tests present
• ⚠ Concentrated ownership — top contributor handles 72% of recent commits
• ⚠ No CI workflows detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live dotnet/reactive repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/dotnet/reactive.

What it runs against: a local clone of dotnet/reactive — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in dotnet/reactive | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 31 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of dotnet/reactive. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/dotnet/reactive.git
#   cd reactive
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of dotnet/reactive and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "dotnet/reactive(\\.git)?\\b" \\
  && ok "origin remote is dotnet/reactive" \\
  || miss "origin remote is not dotnet/reactive (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "AsyncRx.NET/System.Reactive.Async/IAsyncObservable.cs" \\
  && ok "AsyncRx.NET/System.Reactive.Async/IAsyncObservable.cs" \\
  || miss "missing critical file: AsyncRx.NET/System.Reactive.Async/IAsyncObservable.cs"
test -f "AsyncRx.NET/System.Reactive.Async/IAsyncObserver.cs" \\
  && ok "AsyncRx.NET/System.Reactive.Async/IAsyncObserver.cs" \\
  || miss "missing critical file: AsyncRx.NET/System.Reactive.Async/IAsyncObserver.cs"
test -f "AsyncRx.NET/System.Reactive.Async/AsyncObservable.cs" \\
  && ok "AsyncRx.NET/System.Reactive.Async/AsyncObservable.cs" \\
  || miss "missing critical file: AsyncRx.NET/System.Reactive.Async/AsyncObservable.cs"
test -f "AsyncRx.NET/System.Reactive.Async/AsyncObservableBase.cs" \\
  && ok "AsyncRx.NET/System.Reactive.Async/AsyncObservableBase.cs" \\
  || miss "missing critical file: AsyncRx.NET/System.Reactive.Async/AsyncObservableBase.cs"
test -f "AsyncRx.NET/System.Reactive.Async/Concurrency/IAsyncScheduler.cs" \\
  && ok "AsyncRx.NET/System.Reactive.Async/Concurrency/IAsyncScheduler.cs" \\
  || miss "missing critical file: AsyncRx.NET/System.Reactive.Async/Concurrency/IAsyncScheduler.cs"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 31 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~1d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/dotnet/reactive"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Reactive Extensions for .NET (Rx.NET) is a library for composable, event-driven programming using LINQ-style operators over asynchronous sequences. It provides implementations for both synchronous observables (System.Reactive in Rx.NET/) and async-first observables (System.Reactive.Async in AsyncRx.NET/), enabling developers to declaratively handle streams of events, asynchronous operations, and time-based data with first-class support for cancellation and scheduling. Monorepo with four independent library projects: Rx.NET/ contains synchronous reactive extensions; AsyncRx.NET/ contains async-first IAsyncObservable implementations with subdirectories for Concurrency/, Disposables/, Internal/, and Joins/; Ix.NET/ provides LINQ extensions; System.Linq.Async/ implements async LINQ operators. Each maintains its own .csproj and can be packaged independently to NuGet. Core abstractions (IAsyncObservable, IAsyncObserver) sit in AsyncRx.NET/System.Reactive.Async/ with concrete implementations in subdirectories.

Cloud-native developers and IoT applications engineers who need to process live event streams reliably; backend developers building reactive systems with async/await patterns; library authors who want to offer composable streaming APIs; teams modernizing legacy event-handling code to use functional composition instead of nested callbacks or imperative loops.

Highly mature: Rx.NET is production-ready with extensive LINQ operator coverage and 19M+ lines of C# code. AsyncRx.NET is explicitly marked as experimental preview but is actively developed. The repository has strong institutional backing (dotnet org on GitHub), comprehensive documentation including a free eBook (Introduction to Rx.NET 2nd Edition), and multiple stable NuGet packages with millions of downloads. This is not a hobby project—it's core infrastructure for reactive programming in the .NET ecosystem.

AsyncRx.NET carries explicit experimental risk and API surface may change before stabilization. The monorepo structure (four separate libraries: Rx.NET, AsyncRx.NET, Ix.NET, System.Linq.Async) introduces coordination complexity for cross-library changes. Legacy burden exists from maintaining backward compatibility with older Rx.NET code. No visible commit recency or GitHub issues backlog in provided data, so maintenance velocity is unclear—verify before shipping.

Unable to determine from provided data. The file list shows AsyncRx.NET includes an ADR (Architecture Decision Record) at AsyncRx.NET/Documentation/adr/0001-package-unification.md suggesting recent architectural discussions about package strategy. Playground/ and ApiCompare/ utilities suggest active development and API evolution work. Check GitHub Actions in .github/ and recent git log to see CI/CD and commit patterns.

Clone: git clone https://github.com/dotnet/reactive.git. For AsyncRx.NET: cd AsyncRx.NET && dotnet build AsyncRx.NET.sln. For Rx.NET: cd Rx.NET && dotnet build. Use .editorconfig for code style. The Playground/ project (AsyncRx.NET/Playground/Playground.csproj) is a good entry point for experimentation.

Daily commands: cd AsyncRx.NET && dotnet run --project Playground/Playground.csproj for interactive exploration. Or dotnet build AsyncRx.NET.sln to build all libraries. See Rx.NET/ for synchronous Rx examples.

• AsyncRx.NET/System.Reactive.Async/IAsyncObservable.cs — Core async observable abstraction that defines the primary contract for all async reactive sequences; all operators and consumers depend on this interface.
• AsyncRx.NET/System.Reactive.Async/IAsyncObserver.cs — Core async observer abstraction that all subscribers must implement; essential for understanding how data flows to consumers.
• AsyncRx.NET/System.Reactive.Async/AsyncObservable.cs — Primary entry point and factory class for creating async observable sequences; most extension methods and factory patterns are defined here.
• AsyncRx.NET/System.Reactive.Async/AsyncObservableBase.cs — Base class for custom async observable implementations; establishes the subscription pattern and error handling conventions.
• AsyncRx.NET/System.Reactive.Async/Concurrency/IAsyncScheduler.cs — Concurrency abstraction for async scheduling; critical for understanding how operators coordinate execution across different threading contexts.
• AsyncRx.NET/System.Reactive.Async/Disposables/AsyncDisposable.cs — Resource management pattern for async operations; foundational for cleanup and cancellation semantics throughout the library.

Add a New LINQ Operator

1. Create operator class in AsyncRx.NET/System.Reactive.Async/Linq/Operators/ that implements IAsyncObservable<TResult> (AsyncRx.NET/System.Reactive.Async/Linq/Operators/YourOperator.cs)
2. Override Subscribe method to return an IAsyncDisposable and wire up source observable subscriptions (AsyncRx.NET/System.Reactive.Async/Linq/Operators/YourOperator.cs)
3. Add extension method to AsyncObservable.cs LINQ class to expose operator to consumers (AsyncRx.NET/System.Reactive.Async/Linq/AsyncObservable.cs)
4. Implement inner observer class inheriting AsyncObserverBase to handle OnNextAsync, OnErrorAsync, OnCompleteAsync (AsyncRx.NET/System.Reactive.Async/Linq/Operators/YourOperator.cs)

Add a New Async Scheduler

1. Create scheduler class inheriting from AsyncSchedulerBase in AsyncRx.NET/System.Reactive.Async/Concurrency/ (AsyncRx.NET/System.Reactive.Async/Concurrency/YourAsyncScheduler.cs)
2. Implement ScheduleAsync method to schedule work on your execution context (thread pool, UI thread, etc.) (AsyncRx.NET/System.Reactive.Async/Concurrency/YourAsyncScheduler.cs)
3. Optionally override Clock property if you need custom timing behavior (AsyncRx.NET/System.Reactive.Async/Concurrency/YourAsyncScheduler.cs)
4. Register scheduler in static factory class if needed for easy access via AsyncScheduler or similar (AsyncRx.NET/System.Reactive.Async/Concurrency/IAsyncScheduler.cs)

Create a Source Observable from External Event

1. Create source class inheriting from AsyncObservableBase in AsyncRx.NET/System.Reactive.Async/Internal/ (AsyncRx.NET/System.Reactive.Async/Internal/YourEventSource.cs)
2. Override SubscribeAsync to attach to event handlers and wrap them with AsyncObserver (AsyncRx.NET/System.Reactive.Async/Internal/YourEventSource.cs)
3. Return AsyncDisposable that detaches event handlers on disposal (AsyncRx.NET/System.Reactive.Async/Internal/YourEventSource.cs)
4. Add factory method to AsyncObservable.cs (FromEvent, FromEventPattern, or custom) for public access (AsyncRx.NET/System.Reactive.Async/Linq/Operators/FromEvent.cs)

• async/await with ValueTask — Provides efficient async composition with minimal allocations for synchronous completions; matches modern .NET async patterns
• IAsyncDisposable for resource cleanup — Properly integrates with async cleanup semantics; prevents resource leaks in async subscription chains
• Scheduler abstraction over raw Task scheduling — Enables flexible control over execution context (UI thread, thread pool, synchronous) for testability and composition
• Template T4 generation for overloaded operators — Avoids manual duplication of strongly-typed operator variants (CombineLatest, Average, etc.) with different arities

• Async-first model with ValueTask<T> instead of Task<T>

  • Why: Reduces allocations for synchronous scenarios and hot paths
  • Consequence: Slightly more complex code and APIs; not directly compatible with older Task-based patterns

• Separate IAsyncObservable from IObservable (synchronous Rx)

  • Why: Allows deep async/await integration without blocking sync observable implementations
  • Consequence: Operators cannot be transparently shared; duplicate LINQ operators needed for both models

• Subscriber-driven scheduling (push model) with optional schedulers

  • Why: Maintains Rx push semantics while supporting async work distribution
  • Consequence: Backpressure handling is implicit in async/await; explicit buffering required for unconstrained async sources

• Backpressure/demand-driven flow control (relies on async/await to naturally throttle)
• Transactional consistency across multiple observable sequences
• Real-time scheduling guarantees (best-effort scheduler dispatch

AsyncRx.NET is explicitly experimental—API contracts may break before reaching stable release. The library uses async/await extensively but internally queues operations (see AsyncQueueLockAsyncObserver); naive subscription patterns can deadlock if not careful with SynchronizationContext. StrongNaming via ReactiveX.snk is present but not all consumers may expect it—can cause loader issues in some deployment scenarios. The monorepo structure means a breaking change to core abstractions (IAsyncObservable) requires coordinated updates across all four libraries. No obvious breaking-change policy documented in provided files.

• Observer Pattern (Dual of Iterable) — The fundamental design pattern of Rx: instead of pulling data from sequences, you push data to observers; IAsyncObservable is the push-based dual of IAsyncEnumerable, and understanding this inversion is key to writing correct subscriptions
• Async/Await with ValueTask — AsyncRx extensively uses ValueTask instead of Task to reduce allocations in hot paths; understanding when to use ValueTask vs Task is critical for writing performant operators and schedulers in this library
• Scheduler Abstraction (Time & Concurrency Control) — Rx's scheduler system (IAsyncScheduler in AsyncRx) abstracts away the threading/task pool underneath, enabling both deterministic testing and flexible production concurrency; this is what allows operators like Delay, Throttle, and CombineLatest to work across different execution contexts
• Backpressure & Serialization (AsyncQueueLockAsyncObserver) — ReactiveX sources can emit faster than observers can consume; AsyncRx handles this via queuing (not the backpressure negotiation found in Reactive Streams); understanding how AsyncQueueLockAsyncObserver serializes concurrent OnNextAsync calls prevents race conditions
• Composition Over Inheritance (AsyncObservableBase, AsyncObserverBase) — AsyncRx provides base classes for custom operators and observers; the pattern of overriding protected async methods in these bases is the idiomatic way to extend the library without fighting the async machinery
• Disposable Pattern & Resource Management (IAsyncDisposable) — Subscriptions in Rx are resources; AsyncRx's disposable hierarchy (CompositeAsyncDisposable, SerialAsyncDisposable, RefCountAsyncDisposable) ensures cleanup of subscriptions, timers, and concurrent work; leaking disposables causes resource exhaustion in long-running streams
• SynchronizationContext-Aware Scheduling — UI frameworks (WPF, WinForms, Blazor) use SynchronizationContext to marshal work to the UI thread; SynchronizationContextAsyncScheduler in Rx automatically captures and restores context, preventing cross-thread access violations in UI-heavy applications

• reactivex/rxjs — JavaScript implementation of Reactive Extensions with identical operator semantics and design philosophy; useful for understanding RxX cross-platform patterns and comparing API design decisions
• reactivex/rxjava — Java implementation of Reactive Extensions; mature reference implementation for scheduler design and backpressure handling strategies that inform Rx.NET evolution
• dotnet/runtime — The underlying .NET runtime and async/await infrastructure; understanding Task, ValueTask, IAsyncEnumerable implementation in runtime is necessary for advanced AsyncRx.NET work
• dotnet/corefx — Base class library that AsyncRx.NET targets; changes to SynchronizationContext, Task scheduling, or IAsyncDisposable semantics may require corresponding AsyncRx updates

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive unit tests for AsyncRx.NET Disposables

The AsyncRx.NET/System.Reactive.Async/Disposables/ directory contains 7 disposable implementations (AsyncDisposable, CancellationAsyncDisposable, CompositeAsyncDisposable, RefCountAsyncDisposable, SerialAsyncDisposable, SingleAssignmentAsyncDisposable, StableCompositeAsyncDisposable) but there's no visible test project in the file structure. These are critical infrastructure components handling resource cleanup in async contexts, and comprehensive tests would ensure reliability and prevent regressions as the experimental AsyncRx.NET library matures.

• [ ] Create AsyncRx.NET/System.Reactive.Async.Tests/ directory structure
• [ ] Add unit tests for each Disposables/*.cs file covering normal disposal, multiple disposal attempts, and async cleanup scenarios
• [ ] Test CompositeAsyncDisposable and StableCompositeAsyncDisposable with concurrent disposal patterns
• [ ] Integrate tests into AsyncRx.NET.sln and CI pipeline
• [ ] Ensure tests cover both synchronous and asynchronous disposal patterns

Implement missing AsyncObservable LINQ operators with tests

The file structure shows AsyncRx.NET/System.Reactive.Async/Linq/Operators/ contains only 3 operators (Aggregate.cs, All.cs, Amb.cs) visible, but a complete Rx implementation should have dozens of standard operators (Where, Select, SelectMany, Merge, Zip, etc.). The ADR document at AsyncRx.NET/Documentation/adr/0001-package-unification.md suggests this is a deliberate design, but critical operators are missing. Adding commonly-used operators with comprehensive tests would significantly increase the library's utility.

• [ ] Review Rx.NET/Source/System.Reactive/Linq/Observable to identify priority operators missing from AsyncRx
• [ ] Implement high-priority operators (Where, Select, SelectMany, Merge, Zip, CombineLatest) in AsyncRx.NET/System.Reactive.Async/Linq/Operators/
• [ ] Follow existing AsyncObservable patterns from Aggregate.cs and All.cs
• [ ] Add corresponding unit tests in test project
• [ ] Update API comparison tool at AsyncRx.NET/ApiCompare/ to track operator coverage

Generate and test AsyncPattern and AsyncPlan generic overloads

The AsyncRx.NET/System.Reactive.Async/Joins/ directory contains .tt (T4 template) files (AsyncPattern.Generated.tt, AsyncPlan.Generated.tt, ActiveAsyncPlan.Generated.tt) that should generate multiple generic overloads for join patterns. However, there's no indication these templates are being properly executed or that the generated code is being tested. This is blocking pattern-matching and join operations in AsyncRx, which are essential for complex event composition scenarios.

• [ ] Verify .tt template files in AsyncRx.NET/Joins/ are configured to run during build in Directory.build.props
• [ ] Ensure AsyncPattern.Generated.cs, AsyncPlan.Generated.cs, and ActiveAsyncPlan.Generated.cs are properly generated with all required generic overloads (T1-T16 or similar)
• [ ] Add unit tests for join operations using AsyncPattern and AsyncPlan in the test project
• [ ] Test join scenarios with multiple async sequences to ensure correctness
• [ ] Document the template generation process in AsyncRx.NET/Documentation/

• Add async unit tests for AsyncObservableExtensions.cs operators—the file appears to contain many LINQ operators but test coverage is not visible in the file list; pick one operator (e.g., SelectMany) and write comprehensive unit tests covering normal flow, error propagation, and cancellation
• Document the difference between IAsyncObservable<T> and IObservable<T> with a side-by-side code example in Rx.NET/Documentation or README—critical for new users to understand when to use which, but not visible in current docs structure
• Implement missing scheduler documentation in AsyncRx.NET/Concurrency/—the IAsyncScheduler abstraction exists but there is no guide explaining TaskPoolAsyncScheduler vs ImmediateAsyncScheduler vs SynchronizationContextAsyncScheduler use cases; add inline examples showing when to use each

The codebase demonstrates reasonable security practices with Dependabot configuration enabled for automated dependency management. However, there is a critical concern regarding the presence of a strong name key file (ReactiveX.snk) in version control, which should be removed immediately. The main security risks are related to key management and visibility of generated code. The repository lacks explicit security policy documentation but shows good structural practices with GitHub issue and PR templates. Overall security posture is moderate-to-good for an open-source library, with room for improvement in secure key management and security policy documentation.

• Medium · Strong Name Key File Exposed in Repository — AsyncRx.NET/ReactiveX.snk. The file 'AsyncRx.NET/ReactiveX.snk' is a strong name key file that should not be committed to version control. Strong name keys are cryptographic keys used for assembly signing and should be kept secure. If this is a private key, it could be used to forge assemblies. Fix: Remove the .snk file from the repository immediately. Store strong name keys securely outside version control (e.g., in a secure key management system). Update git history to remove all traces of this file using 'git filter-branch' or similar tools.
• Low · Potential Information Disclosure via Template T4 Files — AsyncRx.NET/System.Reactive.Async/Linq/Operators/*.Generated.tt. Multiple T4 template files (.tt files) are present in the repository (e.g., 'Average.Generated.tt', 'CombineLatest.Generated.tt'). While not inherently dangerous, T4 templates generate code at compile time and their output files (.Generated.cs) should be reviewed to ensure they don't contain hardcoded secrets or sensitive information. Fix: Review generated .cs files from T4 templates to ensure no sensitive data is included. Consider adding generated files to .gitignore and regenerating them during build. Document the code generation process.
• Low · Missing Security-Related GitHub Configuration — .github/. The repository contains GitHub configuration files (.github/ISSUE_TEMPLATE, .github/PULL_REQUEST_TEMPLATE.md) but no evidence of security policy file (SECURITY.md) or security-related branch protection rules visible in the provided structure. Fix: Create a SECURITY.md file documenting the security vulnerability reporting process. Implement branch protection rules requiring code reviews and CI checks before merge. Consider enabling security scanning via GitHub's security features.
• Low · Dependency Management Not Visible — *.csproj, packages.config, or Directory.Packages.props files. The analysis shows file structure but the dependency files (package references, project file contents showing PackageReference entries) were not provided. This makes it impossible to assess whether the project uses outdated or vulnerable NuGet packages. Fix: Provide dependency files for security scanning. Implement automated dependency scanning using tools like 'dotnet outdated', GitHub's Dependabot (already configured at .github/dependabot.yml), or OWASP Dependency-Check. Regularly update dependencies and address security advisories.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.