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/Unity-Technologies/UnityCsReference 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.

WAIT — Slowing — last commit 7mo ago

• Last commit 7mo ago
• 2 active contributors
• Other licensed
• ⚠ Slowing — last commit 7mo ago
• ⚠ Small team — 2 contributors active in recent commits
• ⚠ Single-maintainer risk — top contributor 99% of recent commits
• ⚠ Non-standard license (Other) — review terms
• ⚠ No CI workflows detected
• ⚠ No test directory 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 Unity-Technologies/UnityCsReference repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/Unity-Technologies/UnityCsReference.

What it runs against: a local clone of Unity-Technologies/UnityCsReference — 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 Unity-Technologies/UnityCsReference | Confirms the artifact applies here, not a fork | | 2 | License is still Other | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 227 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of Unity-Technologies/UnityCsReference. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/Unity-Technologies/UnityCsReference.git
#   cd UnityCsReference
#
# 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 Unity-Technologies/UnityCsReference and re-run."
  exit 2
fi

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

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

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

# 4. Critical files exist
test -f "Editor/Mono/Animation/AnimationWindow/AnimationWindowState.cs" \\
  && ok "Editor/Mono/Animation/AnimationWindow/AnimationWindowState.cs" \\
  || miss "missing critical file: Editor/Mono/Animation/AnimationWindow/AnimationWindowState.cs"
test -f "Editor/Mono/Animation/AnimationWindow/CurveEditor.cs" \\
  && ok "Editor/Mono/Animation/AnimationWindow/CurveEditor.cs" \\
  || miss "missing critical file: Editor/Mono/Animation/AnimationWindow/CurveEditor.cs"
test -f "Editor/Mono/Animation/AnimationWindow/AnimationWindowHierarchy.cs" \\
  && ok "Editor/Mono/Animation/AnimationWindow/AnimationWindowHierarchy.cs" \\
  || miss "missing critical file: Editor/Mono/Animation/AnimationWindow/AnimationWindowHierarchy.cs"
test -f "Editor/Mono/Animation/AnimatorController.cs" \\
  && ok "Editor/Mono/Animation/AnimatorController.cs" \\
  || miss "missing critical file: Editor/Mono/Animation/AnimatorController.cs"
test -f "Editor/Mono/Animation/AnimationWindow/DopeSheetEditor.cs" \\
  && ok "Editor/Mono/Animation/AnimationWindow/DopeSheetEditor.cs" \\
  || miss "missing critical file: Editor/Mono/Animation/AnimationWindow/DopeSheetEditor.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 227 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~197d)"
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/Unity-Technologies/UnityCsReference"
  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).

UnityCsReference is the read-only C# reference source code for the Unity engine and editor (frozen at version 6000.2.0b4). It exposes the internal C# implementation of Unity's core systems—including 2D sprites, animation windows, build pipelines, accessibility settings, and incremental build infrastructure—allowing developers to understand how Unity's editor and runtime work under the hood without modifying it. Monolithic editor-focused structure: Editor/Mono/ is the main namespace containing subsystems (2D/, Animation/, Accessibility/, etc.), each with .bindings.cs files wrapping native C++ interop. Editor/IncrementalBuildPipeline/ contains build data schemas (BeeBuildProgramCommon.Data, PlayerBuildProgramLibrary.Data, ScriptCompilationBuildProgram.Data) with .gen.csproj files indicating code generation. The solution root is Projects/CSharp/UnityReferenceSource.sln.

Unity game developers, engine contributors, and technical researchers who need to understand Unity's internal C# implementation for debugging, learning architecture patterns, or referencing behavior. Specifically: developers fixing complex bugs by tracing into engine code, tool developers building custom editors, and studios needing to comprehend how animation, sprites, or build systems work internally.

This is a static reference snapshot, not an active development repository. It is frozen at Unity 6000.2.0b4 with no ongoing commits (as stated: 'not currently being updated beyond version 6.2.0b4'). It is production-grade code (shipped in Unity releases) but the repository itself is a read-only archive, so there is no traditional 'maturity' metric like CI status or active maintenance.

Major risk: this is a frozen snapshot that will not receive bug fixes or security updates—any issues found here are also in released Unity versions but won't be patched in this reference. Secondary risk: the license forbids modification or redistribution of the C# code, so contributors cannot fork or patch it; all fixes must go through Unity's commercial source license. No PR process exists ('We do not take pull requests at this time').

Nothing—this repository is explicitly frozen and not being updated. The README states: 'not currently being updated beyond version 6.2.0b4. Updates are planned to resume at a later date once internal validation processes are complete.' It is a static reference for Unity 6000.2.0b4 only.

Clone the repository: git clone https://github.com/Unity-Technologies/UnityCsReference.git. No install step required—this is reference source code. Open the C# solution with Visual Studio: Projects/CSharp/UnityReferenceSource.sln. No build or runtime is provided; this is for reading and understanding code only.

Daily commands: This is reference-only source; there is no runtime to execute. Open in Visual Studio or Rider and browse/search code. IntelliSense will work once the solution is loaded. Use 'Go to Definition' to trace the .bindings.cs files into their interop declarations.

• Editor/Mono/Animation/AnimationWindow/AnimationWindowState.cs — Central state management for the Animation window; all animation editing operations depend on this to track current animation clip, time, selection, and recording state.
• Editor/Mono/Animation/AnimationWindow/CurveEditor.cs — Core curve interpolation and keyframe editing engine; handles the mathematical foundation for all animation curve manipulation in the editor.
• Editor/Mono/Animation/AnimationWindow/AnimationWindowHierarchy.cs — Manages the hierarchical tree of animatable properties; this is the primary UI layer for browsing and selecting what to animate.
• Editor/Mono/Animation/AnimatorController.cs — High-level controller for animator state machines and blend trees; essential for understanding how animations are organized and played back.
• Editor/Mono/Animation/AnimationWindow/DopeSheetEditor.cs — Dopesheet timeline rendering and interaction; primary UI for keyframe timeline editing and scrubbing through animations.
• Editor/Mono/Animation/AnimationWindow/IAnimationWindowController.cs — Interface contract that all animation window components implement; defines the abstraction layer for state communication.
• Editor/Mono/Animation/AnimationWindow/AnimationRecording.cs — Live animation recording from GameObject transforms; handles the runtime capture of property changes during playback.

Add a new curve type (e.g., for custom properties)

1. Create a new CurveRenderer subclass in Editor/Mono/Animation/AnimationWindow/CurveRenderer/ (e.g., CustomPropertyCurveRenderer.cs) that inherits from CurveRenderer.cs and implements DrawCurve() for your data type. (Editor/Mono/Animation/AnimationWindow/CurveRenderer/CurveRenderer.cs)
2. Register the new renderer in the CurveRenderer factory or dispatch logic, typically in DopeSheetEditor.cs or AnimationWindowCurve.cs, by checking the curve's target type. (Editor/Mono/Animation/AnimationWindow/DopeSheetEditor.cs)
3. If interpolation logic differs, add a handler in RotationCurveInterpolation.cs or create a new interpolation utility that mirrors its pattern. (Editor/Mono/Animation/AnimationWindow/RotationCurveInterpolation.cs)
4. Update AnimationWindowCurve.cs to instantiate and manage the new renderer type when constructing curve instances. (Editor/Mono/Animation/AnimationWindow/AnimationWindowCurve.cs)

Add a new animation window panel or tool (e.g., new sidebar or inspector)

1. Create a new class implementing IAnimationWindowControl in Editor/Mono/Animation/AnimationWindow/ to define your control's UI layout and input handlers. (Editor/Mono/Animation/AnimationWindow/IAnimationWindowControl.cs)
2. Register the panel in AnimationWindow.cs by creating a layout section and adding your control instance to the window's control list. (Editor/Mono/Animation/AnimationWindow/AnimationWindow.cs)
3. Subscribe to state changes in AnimationWindowState.cs (or implement IAnimationWindowController) to react to clip, time, and selection updates. (Editor/Mono/Animation/AnimationWindow/AnimationWindowState.cs)
4. Add styling constants to AnimationWindowStyles.cs for your new panel's colors, fonts, and spacing. (Editor/Mono/Animation/AnimationWindow/AnimationWindowStyles.cs)

Extend animation recording to capture custom component properties

1. Modify AnimationRecording.cs to detect your custom component type and extract property paths using reflection or a custom property provider. (Editor/Mono/Animation/AnimationWindow/AnimationRecording.cs)
2. Ensure the property bindings are registered via EditorCurveBinding.bindings.cs or extend the binding resolution logic in AnimationUtility.bindings.cs. (Editor/Mono/Animation/EditorCurveBinding.bindings.cs)
3. Add the custom component to the AddCurvesPopupHierarchyDataSource.cs so it appears as an option in the 'Add Property' menu. (Editor/Mono/Animation/AnimationWindow/AddCurvesPopupHierarchyDataSource.cs)
4. Test keyframe insertion by verifying AnimationWindowKeyframe.cs correctly reads and writes your property type's serialized values. (Editor/Mono/Animation/AnimationWindow/AnimationWindowKeyframe.cs)

Add a new state machine layer or transition rule to Animator

1. Create a new layer definition in AnimatorController.cs by instantiating an AnimatorControllerLayer and configuring its StateMachine. (Editor/Mono/Animation/AnimatorController.cs)
2. Define transition conditions and state entry/exit logic in StateMachine.cs by creating transition objects with condition predicates. (Editor/Mono/Animation/StateMachine.cs)
3. If using blend trees, configure node weights and input thresholds in BlendTree.cs. (Editor/Mono/Animation/BlendTree.cs)
4. Validate your layer setup using MecanimUtilities.cs helper functions to ensure animator consistency. (Editor/Mono/Animation/MecanimUtilities.cs)

License restriction: Do not attempt to modify, fork, or redistribute this code—the reference-only license forbids it. Frozen snapshot: This repo will not receive updates or bug fixes; always check the latest Unity source license or bug reports for current versions. Solution path assumption: Code expects Projects/CSharp/UnityReferenceSource.sln to exist and be loadable; some .gen.csproj files may require code generation pre-steps not documented here. No CI/CD logs: There is no build status, test results, or deployment pipeline visible; this is a read-only archive. Interop patterns: All .bindings.cs files hide native C++ implementations; you cannot trace into them from C# alone—you need the full Unity C++/C# source license to see those.

• P/Invoke (Platform Invoke) — All .bindings.cs files in this repo use P/Invoke to call native C++ engine functions from C#; understanding this marshaling pattern is critical to grasping how Unity bridges managed and unmanaged code.
• Code Generation (.gen.csproj files) — Build data classes are generated from templates (*.gen.csproj), suggesting the repo uses T4 or similar tooling; understanding this helps navigate auto-generated vs. hand-written code.
• Incremental Build Pipelines (Bee) — The Editor/IncrementalBuildPipeline/ subsystem exposes Unity's Bee build system architecture; essential for understanding how scripts are compiled and assets are processed incrementally.
• MVC/MVP Architecture in Editor Subsystems — The Animation Window (AnimationWindow.cs, AnimationWindowControl.cs, AnimationWindowHierarchy.cs) demonstrates a mature model-view-controller separation; understanding this pattern is key to building custom editor tools.
• Editor Overlay and UI Layer Abstraction — Files like Editor/Mono/Animation/AnimationWindow/AnimEditorOverlay.cs show how Unity abstracts editor UI into overlays; useful for extending the editor without modifying core windows.
• Asset Importer Pattern — SpriteAtlasImporter.cs and similar .bindings.cs files show how Unity's asset import pipeline works; critical for understanding how custom importers are registered and called.
• Serialization and Inspector Binding — Inspector and animation window code hints at how serialized data is bound to UI (e.g., AnimationClipSettings.bindings.cs); understanding this is essential for building editor tools that respect Unity's serialization model.

• Unity-Technologies/UnityCsReference — This is the main repo itself—the C# reference source for the core engine and editor.
• Unity-Technologies/UnityEngineModules — Companion modules for specialized engine features (physics, UI, networking) that complement the core reference source.
• needle-mirror/UnityEngineAnalyzer — Roslyn-based code analyzer that works against Unity C# reference source to catch common performance and API misuse patterns.
• Unity-Technologies/UnityCsReference-Android — Platform-specific C# bindings and implementations for Android; demonstrates how the reference source is extended for target platforms.
• premake/premake5 — Not a Unity repo, but the build configuration language used in some Unity build setups; relevant for understanding how UnityCsReference.sln is generated.

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 AnimationWindow curve binding utilities

The AnimationWindow subsystem contains complex curve manipulation logic (CurveBindingUtility.cs, CurveEditor.cs, AnimationWindowCurve.cs) but no visible test files in the repository structure. Given the critical nature of animation editing and the complexity of curve binding resolution, adding unit tests would catch regressions and improve maintainability. This is particularly important since the repo is in reference-only mode and contributors cannot submit fixes directly.

• [ ] Create Editor/Tests/Animation/CurveBindingUtilityTests.cs to test binding resolution for various component types
• [ ] Create Editor/Tests/Animation/CurveEditorTests.cs to test curve manipulation, keyframe insertion, and deletion
• [ ] Create Editor/Tests/Animation/AnimationWindowCurveTests.cs to test curve evaluation and serialization
• [ ] Add test cases for edge cases: empty curves, single keyframe, infinite tangents, and path resolution with missing GameObjects

Add missing unit tests for 2D SpriteAtlas import and packing pipeline

The SpriteAtlas system (Editor/Mono/2D/SpriteAtlas/) contains critical asset import and packing logic (SpriteAtlasImporter.bindings.cs, EditorSpritePacking.bindings.cs) with no visible corresponding test files. The importer inspector and utility classes suggest complex dependency tracking and asset validation that needs test coverage to prevent silent failures.

• [ ] Create Editor/Tests/2D/SpriteAtlasImporterTests.cs to test import settings validation and asset loading
• [ ] Create Editor/Tests/2D/SpritePackingTests.cs to test atlas packing algorithm with various sprite configurations
• [ ] Create Editor/Tests/2D/TexturePlatformSettingsTests.cs to test platform-specific texture format resolution
• [ ] Add test cases for multi-platform builds, texture format fallbacks, and atlas size constraints

Refactor and add documentation for IncrementalBuildPipeline data serialization

The IncrementalBuildPipeline contains multiple auto-generated Data.cs files (BeeBuildProgramCommon.Data, PlayerBuildProgramLibrary.Data, ScriptCompilationBuildProgram.Data) with corresponding .gen.csproj files, suggesting code generation. However, there's no documentation explaining the serialization schema, versioning strategy, or how to safely modify these generated types. This creates maintenance burden and blocks contributors from safely extending the build system.

• [ ] Create Editor/IncrementalBuildPipeline/README.md documenting the data model, serialization format, and versioning strategy
• [ ] Add XML documentation comments to all Data.cs files explaining each field's purpose and serialization compatibility requirements
• [ ] Create a schema validation utility in Editor/IncrementalBuildPipeline/DataSchemaValidator.cs to prevent breaking changes to serialized data
• [ ] Document the relationship between .gen.csproj files and code generation, including how to regenerate Data.cs safely

• Document the .bindings.cs P/Invoke pattern: Create a guide explaining how Editor/Mono/2D/SpriteAtlas/EditorSpriteAtlas.bindings.cs calls native code, with examples of common marshaling scenarios (strings, arrays, callbacks). This would help newcomers understand the C#/C++ boundary.: low: No documentation exists explaining the interop pattern; many bindings files follow it but lack comments.
• Create a reference architecture diagram for the Animation Window subsystem: Map out how AnimationWindow.cs, AnimationWindowControl.cs, AnimationWindowHierarchy.cs, and AnimationWindowCurve.cs interact. Add to a wiki or doc file at Editor/Mono/Animation/AnimationWindow/README.md.: low: The AnimationWindow directory is rich with classes but lacks a high-level overview; a diagram would accelerate learning for custom animation tool builders.
• Annotate the build pipeline data flow: Add comments to Editor/IncrementalBuildPipeline/ showing how Data.cs files (BeeBuildProgramCommon.Data, PlayerBuildProgramLibrary.Data, ScriptCompilationBuildProgram.Data) flow into each other and interact with the Bee build system. Create a docs/BUILD_PIPELINE.md explaining the sequence.: medium: Three separate Data.cs files exist with .gen.csproj hints of code generation, but their relationships and purpose are opaque without this documentation.

The UnityCsReference codebase is primarily a reference implementation with an restrictive 'reference-only' license. The main security concerns are: (1) the repository is not being actively maintained beyond v6.2.0b4, creating potential exposure to unpatched vulnerabilities; (2) the reference-only license restriction could lead to compliance issues; (3) the presence of native binding files requires careful security review due to interop risks. No hardcoded secrets, obvious injection vulnerabilities, or exposed credentials were detected in the file structure. The codebase appears to be well-organized with standard Unity editor and runtime structure. Overall security posture is moderate due to maintenance status rather than inherent code vulnerabilities.

• Medium · Reference-Only License with Modification Restrictions — Repository root - License terms (Unity_Reference_Only_License). The codebase is distributed under a 'Reference Only License' that explicitly prohibits modification and redistribution of C# code. This creates a legal/compliance risk if developers accidentally modify and distribute this code, but also means the codebase is not intended for production use modifications. Fix: Ensure all developers understand the licensing restrictions. If modifications are needed, contact Unity sales for a commercial source code license. Implement code review processes to prevent unauthorized modifications.
• Medium · Outdated Repository Status — Repository root - README. The repository is not currently being updated beyond version 6.2.0b4, and updates are planned to resume at a later date. This means security patches and bug fixes may not be available, creating potential vulnerabilities in the codebase. Fix: Monitor the repository for updates. Consider implementing additional security reviews for this codebase. Do not use in production without appropriate security assessment and patching procedures. Track issue reports and security bulletins from Unity.
• Low · Bindings Files Complexity — Multiple locations: Editor/Mono/2D/**/*.bindings.cs, Editor/Mono/Animation/**/*.bindings.cs. Multiple .bindings.cs files are present throughout the codebase (e.g., Editor/Mono/2D, Editor/Mono/Animation). Bindings files often contain interop code with native libraries, which can introduce security risks if not properly validated, such as buffer overflows or incorrect type marshaling. Fix: Conduct thorough security review of all binding files, particularly around: parameter validation, buffer size checks, and proper marshaling of data types. Ensure all native interop code follows secure coding practices.

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.