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/TheCherno/Hazel 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 — Stale — last commit 2y ago

• 26+ active contributors
• Apache-2.0 licensed
• ⚠ Stale — last commit 2y ago
• ⚠ Concentrated ownership — top contributor handles 63% of recent commits
• ⚠ 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 TheCherno/Hazel repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/TheCherno/Hazel.

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

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

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

# 2. License matches what RepoPilot saw
(grep -qiE "^(Apache-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Apache-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is Apache-2.0" \\
  || miss "license drift — was Apache-2.0 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 "Hazel/src/Hazel.h" \\
  && ok "Hazel/src/Hazel.h" \\
  || miss "missing critical file: Hazel/src/Hazel.h"
test -f "Hazel/src/Hazel/Core/Application.h" \\
  && ok "Hazel/src/Hazel/Core/Application.h" \\
  || miss "missing critical file: Hazel/src/Hazel/Core/Application.h"
test -f "Hazel/src/Hazel/Core/Layer.h" \\
  && ok "Hazel/src/Hazel/Core/Layer.h" \\
  || miss "missing critical file: Hazel/src/Hazel/Core/Layer.h"
test -f "Hazel/src/Hazel/Renderer/Renderer.h" \\
  && ok "Hazel/src/Hazel/Renderer/Renderer.h" \\
  || miss "missing critical file: Hazel/src/Hazel/Renderer/Renderer.h"
test -f "Hazel/src/Hazel/Scene/Entity.h" \\
  && ok "Hazel/src/Hazel/Scene/Entity.h" \\
  || miss "missing critical file: Hazel/src/Hazel/Scene/Entity.h"

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

Hazel is a C++ 3D rendering engine with optional C# scripting support, designed primarily for Windows with Vulkan as the primary graphics backend. It provides layer-based application architecture, ECS-style scene management, and input handling—built explicitly as an educational tool taught through YouTube videos, not as a production-ready engine. Dual-language monorepo: Hazel/src/ contains the C++ engine core (Layer, Application, Event, Renderer, Scene systems), while Hazel-ScriptCore/Source/Hazel/ mirrors the API in C# for scripting. Build uses Lua-based Premake5 (Dependencies.lua, premake5.lua files) instead of CMake. Entrypoint via Hazel/src/Hazel/Core/EntryPoint.h.

Game engine enthusiasts, C++ developers learning renderer architecture, and viewers of TheCherno's YouTube engine development series who want to understand rendering pipelines, ECS design, and cross-language scripting integration (C++ engine + C# game logic).

Experimental / early-stage. The README explicitly states 'Currently not much is implemented' and the project prioritizes education over feature completeness. It's actively developed (YouTube-driven), but the public repo is intentionally simplified—a more advanced version exists in the private Hazel-dev repository accessible only to Patreon supporters. Not production-ready.

Standard open source risks apply.

Actively being documented in video form. Based on file structure, focus areas include: Layer and LayerStack abstractions (Layer.cpp/h), UUID system (UUID.cpp/h), FileSystem utilities (FileSystem.cpp/h), and C# scripting bridge (InternalCalls.cs, Entity.cs). No visible CI/CD setup in file list.

Check README for instructions.

Daily commands: No traditional 'dev server'. Compile via Visual Studio solution generated by Win-GenProjects.bat. To rebuild project files: run scripts/Win-GenProjects.bat. To test: open generated .sln in Visual Studio and build/run Sandbox project (typical game engine demo).

• Hazel/src/Hazel.h — Main engine header that exports the public API; every contributor must understand what the engine exposes
• Hazel/src/Hazel/Core/Application.h — Core application lifecycle and event loop management; foundational to all Hazel applications
• Hazel/src/Hazel/Core/Layer.h — Layer abstraction for modular game logic and systems; essential architectural pattern for engine users
• Hazel/src/Hazel/Renderer/Renderer.h — Renderer API abstraction and batching system; critical for graphics pipeline understanding
• Hazel/src/Hazel/Scene/Entity.h — Entity-Component-System (ECS) core; defines how scenes and game objects are composed
• Hazel/src/Hazel/Events/Event.h — Event system architecture used throughout the engine; required for input and application event handling
• Hazel/src/Hazel/Core/EntryPoint.h — Application entry point macro that bootstraps client applications; defines Hazel's main contract

Add a new Component type

1. Define the component struct in Hazel/src/Hazel/Scene/Components.h with data members (Hazel/src/Hazel/Scene/Components.h)
2. Create the C# wrapper in Hazel-ScriptCore/Source/Hazel/Scene/Components.cs if scripts need access (Hazel-ScriptCore/Source/Hazel/Scene/Components.cs)
3. Add serialization in Hazel/src/Hazel/Scene/SceneSerializer.cpp in the SerializeEntity and DeserializeEntity functions (Hazel/src/Hazel/Scene/SceneSerializer.cpp)
4. If rendering, handle in Hazel/src/Hazel/Renderer/Renderer2D.cpp or scene update logic (Hazel/src/Hazel/Scene/Scene.cpp)

Add a new Layer for game logic

1. Create a new class inheriting from Hazel::Layer in Hazel/src/Hazel/Core/Layer.h (Hazel/src/Hazel/Core/Layer.h)
2. Implement OnAttach(), OnDetach(), OnUpdate(Timestep), and OnEvent(Event&) callbacks (Hazel/src/Hazel/Core/Layer.h)
3. Push the layer onto the application's layer stack in Application constructor or during runtime (Hazel/src/Hazel/Core/Application.h)

Add a new Renderer feature (e.g., new primitive or effect)

1. Write a new shader in GLSL (or equivalent) and load via Hazel::Shader in Hazel/src/Hazel/Renderer/Shader.h (Hazel/src/Hazel/Renderer/Shader.h)
2. Add rendering function to Hazel/src/Hazel/Renderer/Renderer2D.h (e.g., DrawTriangle, DrawCircle) (Hazel/src/Hazel/Renderer/Renderer2D.h)
3. Implement the function in Hazel/src/Hazel/Renderer/Renderer2D.cpp using vertex buffers and draw calls (Hazel/src/Hazel/Renderer/Renderer2D.cpp)

Add a new Input event handler

1. Define event class in Hazel/src/Hazel/Events/KeyEvent.h or MouseEvent.h (Hazel/src/Hazel/Events/KeyEvent.h)
2. Create or extend layer's OnEvent() handler to call the event's Dispatch<EventType>() method (Hazel/src/Hazel/Core/Layer.h)
3. Bind handler lambda or function using

Vulkan SDK mandatory: Setup.bat will fail silently if Vulkan SDK is not installed; the script prompts for manual installation but does not auto-retry. Recursive clone required: git clone without --recursive will leave submodules empty, causing linker errors. Windows-only official support: PlatformDetection.h suggests cross-platform intent, but Setup.bat and Win-GenProjects.bat are Windows-only; Mac/Linux build is untested/unsupported currently. C# scripting not optional: Hazel-ScriptCore is a separate project built via separate premake5.lua; failure to build it will break engine's C# interop. No test suite visible: No CMakeLists indicating unit tests or CTest integration.

• Layer-based application architecture — Hazel's core organizational pattern (Layer.h, LayerStack.h); understanding how layers overlay and dispatch events is essential to extending the engine.
• Event-driven input handling — Events.h and ApplicationEvent.h define how keyboard/mouse input flows through the engine; critical for game logic and UI responsiveness.
• Entity Component System (ECS) — Scene/Components.cs and Entity.cs hint at an ECS-influenced design for game objects; understanding this pattern is key to building game logic in Hazel.
• Cross-language interop via P/Invoke — InternalCalls.cs marshals C++ engine state to C# scripts; understanding how memory, types, and pointers cross the C++/C# boundary is essential for extending scripting.
• Vulkan graphics pipeline — Hazel targets Vulkan (Setup.bat installs Vulkan SDK); understanding command buffers, synchronization, and rendering passes is required for renderer development.
• Lua-based build configuration (Premake5) — Dependencies.lua and premake5.lua drive the entire build system; modifying project structure requires editing these files, not traditional CMakeLists.txt.
• UUID-based entity identification — UUID.h/cpp provides stable entity identifiers across serialization; critical for scene persistence and networked gameplay.

• TheCherno/Hazel-dev — The private advanced version of Hazel with more features; mentioned in README as the source for code backported to this public repo.
• ocornut/imgui — Immediate-mode UI library commonly used in game engines for debug UI and editor tools; likely a dependency or future integration for Hazel editor.
• KhronosGroup/Vulkan-Samples — Canonical Vulkan examples; reference material for understanding the graphics API Hazel targets as its primary renderer.
• assimp/assimp — 3D model import library; likely a planned dependency for Hazel's 3D rendering pipeline once fully implemented.
• glfw/glfw — Cross-platform windowing library; probable low-level dependency for platform abstraction (hints at Mac/Linux future support despite Windows-only today).

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 unit tests for Physics2D.h and Math utilities

The Physics2D.h header exists but has no corresponding test suite. Given the importance of physics calculations in a game engine, comprehensive unit tests for 2D physics operations and the Math/Math.cpp utilities would catch regressions early and make the codebase more maintainable as contributors add features.

• [ ] Create Tests/Physics2D_Tests.cpp with test cases for common physics operations (collision detection, rigid body updates, etc.)
• [ ] Create Tests/Math_Tests.cpp with test cases for Math.cpp functions (vector operations, transformations, etc.)
• [ ] Integrate tests into the premake5.lua build system for both Hazel and Hazel-ScriptCore projects
• [ ] Add a GitHub Actions workflow (.github/workflows/tests.yml) to run tests on all PRs targeting Windows builds

Complete the CONTRIBUTING.md guide with build and development instructions

The README mentions running a configuration step but cuts off mid-sentence ('Run the...'). The .github/CONTRIBUTING.md file likely needs expansion with specific steps for setting up the Premake build system, configuring Visual Studio projects, and building Hazel-ScriptCore C# bindings.

• [ ] Complete the truncated README section with full Premake5 setup instructions
• [ ] Expand .github/CONTRIBUTING.md with: prerequisites (Visual Studio version, CMake/Premake version), step-by-step build instructions, how to run the engine, and debugging setup
• [ ] Document the build differences between Hazel (C++ core) and Hazel-ScriptCore (C# scripting layer)
• [ ] Add troubleshooting section for common Windows build issues

Add integration tests for Scene/Entity/Components system

The Scene architecture (Entity.cs, Components.cs in Hazel-ScriptCore and corresponding C++ code) is a critical subsystem but lacks visible test coverage. Integration tests would verify the C#/C++ interop through InternalCalls.cs and ensure the Entity Component System works correctly.

• [ ] Create Tests/Scene_Integration_Tests.cpp for C++ Entity creation, component attachment, and serialization
• [ ] Create Hazel-ScriptCore/Tests/EntityTests.cs for C# entity scripting and component access through InternalCalls
• [ ] Test serialization/deserialization paths (Hazel/src/Hazel/Project/ProjectSerializer.cpp) with multi-entity scenes
• [ ] Add a test scene file to Hazel/Assets/Scenes for regression testing during engine updates

• Add comprehensive platform detection tests: PlatformDetection.h exists but has no corresponding test file. Create Hazel/tests/PlatformDetectionTest.cpp to validate macro behavior on Windows, Linux, and Mac (future support).
• Document the Event dispatch pattern: Event.h uses CRTP but lacks in-code examples. Add a /docs/EventSystem.md walkthrough showing how to create a custom event, dispatch it, and handle it in a Layer.
• Implement missing KeyCode bindings for C# scripting: KeyCode.cs in Hazel-ScriptCore exists but likely has incomplete mappings. Audit it against KeyCodes.h in the C++ side and add missing bindings + tests in Hazel-ScriptCore/tests/.

The Hazel Engine repository shows a foundational security posture but has several areas requiring improvement. The primary concerns are: (1) opaque dependency management without visible scanning, (2) submodule supply chain risks without documented verification procedures, (3) absence of a security policy and responsible disclosure framework, and (4) platform-specific testing gaps. The codebase itself appears to be a C++ game engine with no obvious injection vulnerabilities or hardcoded secrets visible in the file structure. Recommendations include implementing dependency scanning, documenting submodule verification, creating a security policy, and expanding cross-platform testing.

• Medium · Recursive Git Submodule Cloning — README snippet and .gitmodules. The repository uses git submodules and requires recursive cloning. Submodules can introduce supply chain risks if not properly verified. The documentation instructs users to clone with --recursive flag without emphasizing the need to verify submodule sources. Fix: Document submodule verification procedures, consider using git submodule security scanning tools, and maintain a list of approved submodule sources.
• Medium · Incomplete Dependency Documentation — Dependencies.lua. The Dependencies.lua file is referenced but not provided in the analysis. Third-party dependency management is opaque, making it difficult to identify vulnerable dependencies or license issues. Fix: Provide complete dependency manifest, use dependency scanning tools (OWASP Dependency-Check, Snyk), and maintain a Software Bill of Materials (SBOM).
• Low · Platform-Specific Security Testing Gap — README snippet. Documentation states 'Hazel is officially untested on other development environments whilst we focus on a Windows build.' This creates a gap where security vulnerabilities specific to non-Windows platforms may not be identified. Fix: Establish cross-platform security testing procedures and document platform-specific security considerations.
• Low · Missing Security Policy — Repository root. No SECURITY.md or vulnerability disclosure policy found in the repository structure. This impedes responsible disclosure of security issues. Fix: Create a SECURITY.md file with responsible disclosure guidelines, contact information, and vulnerability reporting procedures.
• Low · Incomplete Getting Started Documentation — README. The README snippet cuts off during the 'Configuring the dependencies' section, leaving instructions incomplete. This could lead to improper setup and security misconfigurations. Fix: Complete and review all setup documentation for security best practices and clear instructions.

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.