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/stride3d/stride 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 today
• 3 active contributors
• MIT licensed
• CI configured
• Tests present
• ⚠ Small team — 3 contributors active in recent commits
• ⚠ Single-maintainer risk — top contributor 82% of recent commits

_{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 stride3d/stride repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/stride3d/stride.

What it runs against: a local clone of stride3d/stride — 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 stride3d/stride | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | 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 ≤ 30 days ago | Catches sudden abandonment since generation |

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "stride3d/stride(\\.git)?\\b" \\
  && ok "origin remote is stride3d/stride" \\
  || miss "origin remote is not stride3d/stride (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 master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "build/Stride.sln" \\
  && ok "build/Stride.sln" \\
  || miss "missing critical file: build/Stride.sln"
test -f ".github/workflows/main.yml" \\
  && ok ".github/workflows/main.yml" \\
  || miss "missing critical file: .github/workflows/main.yml"
test -f "build/Stride.build" \\
  && ok "build/Stride.build" \\
  || miss "missing critical file: build/Stride.build"
test -f ".github/copilot-instructions.md" \\
  && ok ".github/copilot-instructions.md" \\
  || miss "missing critical file: .github/copilot-instructions.md"
test -f ".github/CONTRIBUTING.md" \\
  && ok ".github/CONTRIBUTING.md" \\
  || miss "missing critical file: .github/CONTRIBUTING.md"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 30 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~0d)"
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/stride3d/stride"
  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).

Stride is a free, open-source C# game engine with cross-platform support (Windows, Linux, iOS, Android, VR) focused on realistic rendering and modularity. It ships with Game Studio, a visual editor for creating and managing game content, and compiles to native code via C++/HLSL for performance-critical graphics. Monorepo structure: sources/engine/ contains core C# engine (rendering, physics, I/O), sources/editor/ is the Game Studio IDE, samples/ has example games, build/ holds NuGet and build configuration. Assembly processor (C++) handles shader compilation and code generation; platform-specific backends in sources/engine/Xenko.Graphics for graphics API abstraction (D3D, Vulkan, OpenGL).

Game developers and studios building 3D games or VR applications in C#; graphics programmers working with HLSL shaders and real-time rendering; contributors extending the engine itself (the repo has CODEOWNERS and pull request templates indicating active community governance).

Production-ready and actively developed: extensive CI/CD pipeline across 40+ GitHub Actions workflows (build-windows-full, test-windows-game, build-ios, build-android), comprehensive test suites (test-samples-baselines, test-samples-screenshots), MIT licensed with backers listed. Community-driven with Discord (500k+ members) and funded tasks for contributors.

Standard open source risks apply.

Active cross-platform build work: workflows for Android (build-android.yml), iOS (build-ios.yml), Linux runtime (build-linux-runtime.yml), and VS package distribution. Recent focus on dependency updates (SPIRV-Cross, swiftshader) and screenshot/baseline testing for samples, indicating ongoing graphical and compatibility improvements.

git clone https://github.com/stride3d/stride.git cd stride

Windows: build/build.bat or build/build.ps1

Linux/Mac: build/build.sh

Read .github/CONTRIBUTING.md for detailed setup including Visual Studio/Rider requirements and NuGet restoration

Daily commands: After build.bat/build.sh completes: launch sources/editor/Stride.GameStudio (the visual editor) or run compiled game assemblies directly. For samples: see samples/ folder—each contains a .stride (project file) openable in Game Studio or compilable standalone.

• build/Stride.sln — Master solution file that orchestrates all platform builds (Windows, Linux, Android, iOS, UWP) — essential to understand the monorepo structure.
• .github/workflows/main.yml — Primary CI/CD pipeline defining build, test, and release workflows across all platforms — critical for understanding how code flows to production.
• build/Stride.build — MSBuild script containing core build logic, versioning, and multi-platform compilation orchestration for the entire engine.
• .github/copilot-instructions.md — Contributor guidelines and code style requirements specific to the Stride codebase — mandatory reading for consistent contributions.
• .github/CONTRIBUTING.md — Official contribution workflow, branch strategy, and pull request expectations for the Stride project.
• .editorconfig — Enforces consistent code formatting and style across C# files — foundational for code quality across 600 files.
• README.md — Project vision, feature overview, and quick-start links — establishes the engine's goals and cross-platform scope.

Add Support for a New Graphics Backend (e.g., Metal on macOS)

1. Create a new platform-specific solution filter in build/Stride.macOS.slnf to include Metal graphics projects. (build/Stride.sln)
2. Add a new workflow file .github/workflows/build-macos.yml mirroring the pattern from Android/iOS builds. (.github/workflows/build-android.yml)
3. Update .github/workflows/main.yml to trigger the new macOS workflow on pull requests and merges. (.github/workflows/main.yml)
4. Add backend-specific test configuration in build/ (e.g., GameTests-Metal.runsettings). (build/GameTests-GPU.runsettings)
5. Update CONTRIBUTING.md with platform-specific build instructions for macOS developers. (.github/CONTRIBUTING.md)

Add a New Native Library Dependency (e.g., Physics Engine Binding)

1. Create a new .nuspec file under build/deps/ following the pattern of SpirvCross or SwiftShader. (build/deps/spirv-cross/Stride.Dependencies.SpirvCross.nuspec)
2. Add a GitHub Actions workflow (e.g., .github/workflows/dep-physics-engine.yml) to build and package the native library. (.github/workflows/dep-spirv-cross.yml)
3. Reference the new dependency in solution filters and MSBuild properties within build/Stride.build. (build/Stride.build)
4. Update the NuGet feed configuration in build/.nuget/NuGet.Config if using a custom package source. (build/.nuget/NuGet.Config)

Enable GPU Tests for a New Platform

1. Create a platform-specific test runsettings file (e.g., build/GameTests-Linux-GPU.runsettings) configuring display resolution and GPU detection. (build/GameTests-GPU.runsettings)
2. Add a corresponding test workflow (e.g., .github/workflows/test-linux-game.yml) that sets up display and GPU drivers. (.github/workflows/test-linux-game.yml)
3. Add custom GitHub Actions helpers in .github/actions/ (e.g., set-display-resolution) to manage headless/virtual display setup. (.github/actions/set-display-resolution/action.yml)
4. Integrate the new test workflow into main.yml with conditional triggers based on platform or code changes. (.github/workflows/main.yml)

Update Build & Release Pipeline for a Major Version Bump

1. Modify version properties in build/Stride.build (AssemblyVersion, FileVersion, InformationalVersion). (build/Stride.build)
2. Update build/Stride.sln.rn.xml with release notes for the new version. (build/Stride.sln.rn.xml)
3. Adjust signing certificate paths in build/sign/.store/ if code signing credentials have changed. (build/sign/.gitignore)
4. Trigger manual release workflow .github/workflows/release.yml with updated version tag. (.github/workflows/release.yml)
5. Update README.md with links to new release artifacts and download instructions. (README.md)

• C# & .NET 6/8 — Cross-platform runtime enabling single codebase deployment to Windows, Linux, macOS, Android, iOS, UWP with IL2CPP AOT compilation where needed.
• Vulkan, DirectX 12, OpenGL ES — Multiple graphics backends abstracted through Stride's shader language (SDSL) allow portability; SPIR-V-Cross + SwiftShader provide software fallbacks.
• MSBuild + solution filters — Platform-specific .slnf files reduce build times and cognitive load by exposing only relevant projects per target (Android, iOS, Linux, Windows).
• GitHub Actions with custom actions — Declarative CI/CD with reusable actions (.github/actions/) for display setup, DPI scaling, GPU detection eliminates script duplication

Native dependencies required: build scripts download and compile SPIRV-Tools, SwiftShader, FreeType—first build is slow (~30+ min). Platform-specific: shader compilation uses assembly processor (C++)—changes to shader paths break many workflows. Monorepo lock-in: AssemblyProcessor ties shader compilation to engine version; upgrading engine without regenerating assets causes link errors. NuGet restoration: must complete successfully or build fails silently—run nuget restore explicitly if dotnet restore hangs. GPU-required for tests: screenshot/baseline tests use GPU rendering—CI uses VDD (virtual display driver) on Windows, requires Xvfb on Linux.

• Graphics API Abstraction Layer (D3D11, Vulkan, OpenGL) — Stride's core strength: sources/engine/Xenko.Graphics/ abstracts platform-specific rendering so a single game runs on Windows, Linux, iOS. Understanding IGraphicsDevice is critical for graphics work.
• Entity-Component-System (ECS) Architecture — Stride uses a lightweight ECS pattern (entities contain components, scripts add behavior) instead of inheritance-heavy game objects; unfamiliar to Unity developers, essential for writing efficient game code.
• SPIR-V and Shader Compilation Pipeline — Stride compiles HLSL → SPIR-V → platform-specific bytecode (via spirv-cross, spirv-tools, spirv-to-dxil); understanding this prevents shader-compilation errors and enables cross-platform shader debugging.
• Asset Serialization (YAML with Custom Schema) — All game assets (.stride files) serialize to YAML via Xenko.Core.Serialization; deserializing corrupted assets is a common bug; key for asset pipeline work.
• Ahead-of-Time (AOT) Compilation and IL2CPP — Stride compiles C# to native code for iOS/Android (via IL2CPP or NativeAOT); reflection and dynamic code generation must be declared; critical constraint for mobile/console work.
• Cross-Platform Project Structure and Build Matrix — Stride targets 6+ platforms; CI matrix in .github/workflows/main.yml ensures builds on Windows, Linux, macOS, Android, iOS. Changes must not break any platform—requires testing discipline.
• Assembly Processor (Code Generation) — Custom C++ tool post-processes compiled assemblies to inject graphics/serialization code; modifications here affect entire engine; very high-risk change area.

• Unity/UnityCsReference — Competitor C# game engine; study rendering pipeline and ECS if evaluating design patterns
• godotengine/godot — Open-source game engine alternative (C++, GDScript); cross-reference if porting games or comparing architecture decisions
• MonoGame/MonoGame — Another C# game framework; lighter-weight predecessor to Stride; useful for understanding lower-level graphics abstractions
• stride3d/stride-docs — Official Stride documentation repository; parallel to engine; sync when adding public API features
• stride3d/stride-samples — Curated example games and demos for Stride; test engine changes here before releasing

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 GitHub Action workflow for automated dependency updates (SPIRV, FreeType, SwiftShader)

The repo has individual workflows for building dependencies (dep-freetype.yml, dep-lavapipe.yml, dep-spirv-cross.yml, dep-spirv-to-dxil.yml, dep-spirv-tools.yml, dep-swiftshader.yml) but no unified workflow to check for upstream updates or trigger rebuilds on schedule. This prevents stale dependencies and security vulnerabilities from accumulating unnoticed.

• [ ] Create .github/workflows/check-dependency-updates.yml that runs on schedule (weekly)
• [ ] Add logic to check upstream tags/releases for: SPIRV-Tools, SPIRV-Cross, FreeType, SwiftShader, Lavapipe
• [ ] Generate automated PR or issue when new versions are detected
• [ ] Reference existing dep-*.yml workflows in the new workflow for consistency

Add integration test workflow for Android build pipeline (complement build-android.yml)

build-android.yml exists for building, but there's no dedicated test workflow (like test-windows-game.yml and test-linux-game.yml) for validating Android runtime behavior, APK loading, or platform-specific rendering. This leaves Android as a blind spot in CI validation.

• [ ] Create .github/workflows/test-android-game.yml following the pattern of test-windows-game.yml and test-linux-game.yml
• [ ] Add emulator setup steps (Android Virtual Device or physical device via cloud service)
• [ ] Run Stride game samples and verify rendering output/screenshots match baselines
• [ ] Integrate with existing test-samples-screenshots.yml baseline comparison logic

Add documentation for platform-specific build requirements in .github/CONTRIBUTING.md

CONTRIBUTING.md exists but the repo has complex multi-platform requirements (Windows full/runtime, Linux, iOS, Android, UWP). The file structure shows .vsconfig and multiple .bat build scripts (Stride.AllPlatforms.bat, Stride.Android.TestApks.proj) but contributors lack a clear guide mapping which build file to use for their target platform.

• [ ] Expand .github/CONTRIBUTING.md with a 'Build Setup by Platform' section
• [ ] Document when to use: build/Stride.AllPlatforms.bat vs build/Stride.Runtime.slnf vs build/Stride.Android.slnf vs build/Stride.Linux.bat
• [ ] Link to .vsconfig requirements and pre-requisite tools (NuGet, Visual Studio workloads, Android SDK versions)
• [ ] Add quick-reference table showing which workflow file (build-*.yml) each platform uses in CI

• Add documentation for Xenko.Physics API surface: sources/engine/Xenko.Physics/ exists but has minimal XML docs; junior contributor can add <summary> tags to public classes/methods without complex logic changes
• Port missing GLSL shader examples to samples/: Engine supports OpenGL but most samples use D3D; adding cross-platform shader samples improves accessibility and exercises graphics abstraction
• Add unit tests for asset deserialization in Xenko.Core.Serialization: Critical code path (YAML asset loading) has gaps in test coverage; write edge-case tests for malformed YAML and missing asset references

The Stride game engine repository demonstrates reasonable security practices with proper use of GitHub workflows and contribution guidelines. However, key security concerns include potential exposure of build signing credentials and certificates in version control, incomplete dependency vulnerability assessment due to missing manifest files, and multi-platform build complexity that may introduce inconsistent security configurations. The codebase lacks visible secrets in filenames and structure, but sensitive build artifacts require immediate attention. No obvious injection vulnerabilities or hardcoded credentials detected in the provided file structure, though static analysis of actual source code is needed for comprehensive assessment.

• Medium · Potential Secrets in Build Configuration — build/sign/.store/, build/advancedinstaller-*.aic. The build directory contains signing configuration files (.store/sign) and Advanced Installer configuration files (advancedinstaller-signed.aic, advancedinstaller-unsigned.aic) that may contain sensitive credentials, certificates, or signing keys. These should not be committed to version control. Fix: Move sensitive build artifacts and signing credentials to a secure secrets management system. Add these paths to .gitignore and use environment variables or secure CI/CD secrets for signing operations.
• Medium · NuGet Configuration Exposure — build/.nuget/NuGet.Config. The NuGet.Config file in build/.nuget/ may contain package source credentials or authentication tokens that could be exposed if the repository is compromised. Fix: Audit NuGet.Config for any hardcoded credentials. Use NuGet credential providers or environment variables for authentication instead. Consider using a private NuGet feed with proper access controls.
• Low · Incomplete Dependency Information — Root and source directories. No package dependency manifest files (package.json, packages.config, .csproj, etc.) were provided for analysis. Cannot assess for known vulnerable dependencies in the codebase. Fix: Provide complete dependency files (*.csproj, packages.config, paket.dependencies) for vulnerability scanning. Implement automated dependency checking in CI/CD pipeline using tools like Dependabot or WhiteSource.
• Low · Multiple Build Configurations — build/ directory with multiple .bat, .slnf files. The presence of platform-specific build scripts (Stride.Android.bat, Stride.Linux.bat, Stride.UWP.bat, etc.) and solution filters suggests complex build configurations that may have inconsistent security settings across platforms. Fix: Document security requirements for each platform build. Implement security checks in CI/CD for all platform-specific builds. Ensure consistent security configurations across Android, iOS, Linux, UWP, and Windows builds.
• Low · GitHub Actions Workflow Exposure — .github/workflows/. Multiple GitHub Actions workflows exist for building, testing, and releasing software. These workflows should be reviewed for secure secret management and least privilege principles. Fix: Review all workflow files for: hardcoded credentials, overly permissive permissions, secure use of secrets, dependency pinning, and use of trusted actions only. Implement workflow security scanning and consider using OIDC for cloud provider authentication.
• Low · Public Repository with Native Dependencies — build/deps/, .github/workflows/dep-*.yml. The project includes native dependencies (spirv-cross, swiftshader, freetype, lavapipe, spirv-tools, spirv-to-dxil) built in CI/CD. Supply chain attacks targeting these dependencies could affect all users. Fix: Implement dependency verification using checksums/signatures. Pin specific versions of dependencies. Monitor for security advisories in native libraries. Consider using Software Bill of Materials (SBOM) for transparency.

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.