Skip to content
CAI
Software that uses CAICheck a score

youki-dev/youki

67.9

Adequate · 29 September 2026

39.4k

lines of production code

Rust

primary language

2

measurements over time

CAI band scale
CAI trend line
CAI lens gauges

What this system is

Youki is a Rust-based OCI-compliant container runtime designed to manage the full lifecycle of Linux containers, including creation, execution, checkpointing, and deletion. It provides low-level infrastructure for configuring cgroups (v1 and v2), applying seccomp and AppArmor security profiles, and managing root filesystems and network namespaces. The system also supports executing WebAssembly workloads via WASI-compatible runtimes and integrates with Kubernetes for node scheduling.

How it got here

2021 — libcontainer architecture and libcgroups refactoring

24 changes.

This period focused on restructuring the project by removing legacy source modules and replacing them with a modular, builder-based libcontainer architecture. Significant work involved refactoring libcgroups to support unified management across systemd, v1, and v2 backends, including new eBPF device filtering and rootless mode support. The main Youki runtime was also reorganized with improved CLI modularity, observability via tracing, and build-time version injection.

2022–2025 — OCI compliance and WebAssembly support

21 changes.

This period focused on expanding the runtime's capabilities to support WebAssembly workloads through dedicated executors and adding Kubernetes deployment tools. Significant effort was also directed toward ensuring strict OCI compliance by introducing a comprehensive integration test framework and validating behavior against standard runtime specifications.

Features

Add WASM sample program

A new sample program has been added to the tools/wasm-sample directory. This program demonstrates basic functionality by printing command-line arguments and environment variables, providing a reference implementation for WASM integration.

tools/wasm-sample · high confidence

Add cross-compilation support for musl and gnu targets via new Dockerfiles

Users can now cross-compile the project for musl-based and gnu-based Linux targets using the \cross\ toolchain. This change introduces \cross/Dockerfile.musl\ and \cross/Dockerfile.gnu\, which configure the necessary build environments, static libraries (such as libseccomp, libelf, and zlib), and compiler flags required for successful cross-compilation on these architectures.

cross · high confidence

Add native D-Bus client for systemd cgroup management

The libcgroups crate now includes a new native D-Bus implementation in \crates/libcgroups/src/systemd/dbus\_native\ that allows direct communication with systemd for cgroup operations without relying on an external D-Bus daemon. This module provides a \SystemdClient\ trait and a \DbusConnection\ struct that handles message serialization, authentication, and method calls (such as starting and stopping transient units). A key behavioral improvement is the addition of a fallback mechanism: if the standard system bus is unavailable, the client connects directly to the systemd private socket at \/run/systemd/private\, which enables rootless container execution in environments where \dbus-daemon\ is not installed (e.g., Kind nodes). The implementation also includes a 10-second receive timeout to prevent indefinite blocking during slow systemd responses.

_crates/libcgroups/src/systemd/dbus\native · high confidence

Added support for executing WebAssembly workloads via Wasmer, WasmEdge, and Wasmtime

Youki now includes dedicated executors for WebAssembly containers, allowing users to run Wasm workloads alongside traditional Linux containers. The new \workload\ module introduces \DefaultExecutor\ which dispatches to specific handlers based on OCI annotations (\run.oci.handler=wasm\ or \module.wasm.image/variant=compat\). When the \wasm-wasmer\, \wasm-wasmedge\, or \wasm-wasmtime\ features are enabled, Youki can execute \.wasm\ or \.wat\ modules using the respective runtime's WASI implementation, handling argument parsing, environment variables, and process exit codes appropriately.

crates/youki/src/workload · high confidence

Build-time version injection for git, Rust, and libseccomp

Youki now embeds its git commit SHA, the Rust compiler version, and the libseccomp library version directly into the binary at build time. This allows the \youki info\ command to report these specific version details to users, improving diagnostics and compatibility verification with tools like Moby.

crates/youki · high confidence

Implement cgroup v2 device filtering via eBPF

The libcgroups library now supports cgroup v2 device controller rules by generating and attaching an eBPF program. This new module translates OCI device allow/deny rules into eBPF bytecode, manages the loading and attachment of the program to the cgroup, and handles the cleanup of previously attached programs to ensure correct enforcement of device access policies.

crates/libcgroups/src/v2/devices · high confidence

Initial seccomp filter implementation with OCI runtime spec support

The \libcontainer\ crate now includes a new \seccomp\ module that translates OCI runtime spec \LinuxSeccomp\ configurations into active Linux seccomp-BPF filters. This change introduces support for defining default actions (such as \SCMP\_ACT\_ERRNO\ with a configurable error code), specific syscall rules, and architecture mappings (including x86\_64, x32, and ARM variants). It also implements handling for seccomp filter flags like \SeccompFilterFlagWaitKillableRecv\ and \SeccompFilterFlagLog\, while enforcing safety constraints that prevent \SCMP\_ACT\_NOTIFY\ from being used as a default action or on the \write\ syscall to avoid container hangs. A fixture configuration file is added to support testing this new capability.

crates/libcontainer/src/seccomp · high confidence

Introduce default workload executor with validation and environment setup

The libcontainer workload module now includes a \DefaultExecutor\ that executes container processes using \execvp\ and validates that the specified executable exists in the \PATH\ and has correct permissions. The \Executor\ trait has been updated to include a \setup\_envs\ method, allowing executors to configure environment variables for the container process before it starts, and error types have been migrated to use \thiserror\ for clearer error reporting.

crates/libcontainer/src/workload · high confidence

Introduce experimental SELinux library and Lima-based development environment

This change adds a new experimental SELinux library in Rust under \experiment/selinux\, providing core functionality to manage SELinux contexts, including setting and retrieving file labels (with support for both regular files and symlinks via \set\_file\_label\ and \lset\_file\_label\), managing process labels, and handling socket security contexts. To facilitate development and testing on systems without native SELinux support, the project includes a Lima VM setup script (\lima-setup.sh\) that provisions a Fedora environment with the necessary SELinux tools and configurations, along with helper scripts to run tests and the application within that VM.

experiment/selinux · high confidence

Introduce experimental seccomp filter implementation

A new experimental Rust project under \experiment/seccomp\ has been added to implement seccomp BPF filters without relying on the \libseccomp\ C library. This location provides the core logic for generating BPF instructions (supporting x86\_64 and AArch64 architectures), handling seccomp notification file descriptors, and converting OCI runtime seccomp specifications into executable filter programs. The implementation includes unit tests for instruction generation and integration tests that validate the generated filters against standard OCI JSON fixtures.

experiment/seccomp · high confidence

Introduce standardized build, test, and release scripts

The scripts directory now provides a unified set of tools for building, testing, and releasing the project. The new build.sh script supports configurable release/debug modes, feature flags, and cross-compilation targets (including musl and arm64) via an optional cross-rs wrapper. A new contest.sh script runs OCI integration tests using the 'contest' tool, automatically selecting architecture-specific bundles. Additional scripts include cargo.sh for wrapping cargo/cross invocations, clean.sh for removing build artifacts, features\_test.sh for validating feature flag combinations, and release\_tag.sh for automating documentation updates during releases.

scripts · high confidence

New cgroup v2 controller implementations and manager

The \libcgroups::v2\ module now provides a complete set of controllers for managing cgroup v2 resources, including CPU, CPU set, IO, memory, PIDs, huge pages, and freezer states, along with a unified resource handler. The new \Manager\ struct orchestrates these controllers and introduces rootless mode support, allowing containers to run in environments where the cgroup hierarchy is read-only by gracefully handling permission errors during cgroup creation and process attachment.

crates/libcgroups/src/v2 · high confidence

New development and debugging helper scripts added to the hack directory

This change introduces four new shell and bpftrace scripts to the \hack/\ directory to support development workflows. \busctl.sh\ provides a dummy busctl command to simplify running specific systemd-related tests in containers without requiring a full dbus/systemd setup. \debug.bt\ is a bpftrace program for tracing syscalls (write, open, clone3, etc.) of the 'youki' process to aid in debugging. \set\_root\_login\_for\_vagrant.sh\ automates SSH configuration changes to enable root login for Vagrant environments. Finally, \stress\_cargo\_test.sh\ allows developers to repeatedly run \cargo test\ to identify flaky tests.

hack · high confidence

New examples for BPF device control and systemd IO limits

Added three new example programs to demonstrate libcgroups capabilities: \bpf.rs\ provides a CLI tool to query, attach, and detach BPF programs for cgroups v2 device controllers (requires the \cgroupsv2\_devices\ feature), \systemd\_io.rs\ demonstrates creating a systemd-managed cgroup with memory and block IO throttle limits, and \rules.json\ supplies sample OCI device rules used by the BPF example.

crates/libcgroups/examples · high confidence

New libcontainer modules for AppArmor, capabilities, and network address management

The libcontainer crate now includes dedicated modules for managing AppArmor profiles (apparmor.rs), handling Linux capability sets and privilege dropping (capabilities.rs), and managing network addresses via Netlink (network/address.rs, network/cidr.rs). These additions provide the underlying infrastructure for enforcing security profiles, adjusting process permissions, and configuring container network interfaces, alongside supporting modules for configuration persistence (config.rs), error handling (error.rs), and hook execution (hooks.rs).

crates/libcontainer/src · high confidence

New systemd-based cgroup manager implementation

The libcgroups crate now includes a new systemd manager that configures container cgroups via D-Bus instead of direct filesystem writes. This implementation introduces a modular controller architecture with dedicated modules for CPU, CPUSet, I/O, Memory, PIDs, and a unified resource controller, all coordinated by a central manager that handles unit creation, delegation boundaries, and sub-cgroup support.

crates/libcgroups/src/systemd · high confidence

New tools for Kubernetes deployment and WebAssembly testing

Added a new \youki-deploy\ toolset that provides a Dockerfile, installation script, and Kubernetes manifests (DaemonSet, RuntimeClass, RBAC) to automatically install Youki on KIND nodes, configure containerd, and label nodes as ready for scheduling. Also added a \wasm-sample\ directory containing a sample WebAssembly module and documentation for testing WebAssembly execution within containers.

tools · high confidence

Project initialization and repository structure setup

The repository has been initialized with the core project configuration files, including the Apache 2.0 license, a Rust toolchain specification (channel 1.96.0), and formatting standards. Build and development workflows are established via a \justfile\ and \Cross.toml\ for cross-compilation, while CI/CD and code quality are configured through \.codecov.yml\, \.typos.toml\, and \.tagpr\ for automated releases. The project also includes documentation standards (README, SECURITY.md, CODE-OF-CONDUCT.md), development environment setups (Vagrantfile, .gitignore), and integration with external test suites via git submodules for OCI runtime-tools and runc.

(repo-wide) · high confidence

Removals

Removed legacy container state management module

The \src/container\ module, which previously handled container state persistence and status tracking, has been removed. This deletion eliminates the legacy \Container\ struct, the \State\ serialization logic (including \state.json\ file I/O), and the \ContainerStatus\ enum with its transition rules (\can\_start\, \can\_kill\, \can\_delete\). Users relying on this internal state management layer will no longer have access to these specific APIs, as the functionality has been superseded by other parts of the system.

src/container · high confidence

Removed legacy process management modules (child, fork, init, message, parent)

The files src/process/child.rs, src/process/fork.rs, src/process/init.rs, src/process/message.rs, and src/process/parent.rs have been deleted. This removes the previous implementation of the process lifecycle, including the specific message types (ChildReady, InitReady), the mio-based pipe communication between parent/child/init processes, and the fork/clone logic that managed these states. Users should expect that the internal process orchestration mechanism has been replaced by a different implementation in the updated codebase.

src/process · high confidence

Removed legacy src modules

Deleted the following source files from the src directory: cond.rs, create.rs, lib.rs, logger.rs, main.rs, notify\_socket.rs, process.rs, rootfs.rs, signal.rs, spec.rs, start.rs, stdio.rs, tty.rs, and utils.rs.

src · high confidence

Architecture

Refactored container lifecycle into modular, builder-based implementation

The container management logic in libcontainer has been restructured from a monolithic design into a modular, builder-pattern architecture. The new \ContainerBuilder\ and \ContainerBuilderImpl\ structs provide a fluent API for configuring container properties (such as root paths, PIDs, and stdio) before instantiation. Container operations are now isolated into dedicated modules—\container\_start\, \container\_kill\, \container\_pause\, \container\_resume\, \container\_delete\, and \container\_checkpoint\—each implementing specific lifecycle methods on the \Container\ struct. This change improves code organization and maintainability while preserving the existing container runtime capabilities.

crates/libcontainer/src/container · high confidence

Behavioural changes

Centralized CLI argument definitions for container subcommands

The \liboci-cli\ crate now provides the definitive argument structures for all container management subcommands, including \checkpoint\, \create\, \delete\, \events\, \exec\, \features\, \info\, \kill\, \list\, \pause\, \ps\, \resume\, \run\, \spec\, \start\, \state\, and \update\. This change introduces specific flags such as \--all\ for the \kill\ command, \--resource\ for \update\, and various checkpoint options like \--tcp-skip-in-flight\ and \--manage-cgroups-mode\, while also defining global options like \--log\ and \--debug\. By consolidating these definitions, the crate ensures consistent command-line parsing across the application.

crates/liboci-cli/src · high confidence

Migrate Cargo configuration to TOML format with release stripping

The project has replaced the legacy \.cargo/config\ file with \.cargo/config.toml\. This change updates the build configuration to use the modern TOML format and introduces a new release profile setting that automatically strips symbols from the compiled binary, reducing its size.

.cargo · high confidence

New libcontainer rootfs implementation with device and mount handling

The \crates/libcontainer/src/rootfs\ module has been restructured into dedicated components (\device.rs\, \mount.rs\, \rootfs.rs\, \symlink.rs\, \utils.rs\) to manage container root filesystem preparation. This change introduces a new \Device\ component that creates device nodes (defaulting to mode 0666) and supports bind-mounting devices, while the \Mount\ component now parses OCI mount options into a \MountOptionConfig\ that supports recursive mount attributes (e.g., \rdonly\, \nosuid\) via \mount\_setattr\. The \RootFS\ orchestrator uses these components to set mount propagation, bind-mount the rootfs, and configure symlinks (such as \/dev/ptmx\ and \/proc/self/fd\), providing a more modular and spec-compliant rootfs setup process.

crates/libcontainer/src/rootfs · high confidence

Refactored cgroup v1 subsystems into a modular controller architecture

The cgroup v1 implementation has been restructured from a monolithic manager into a modular controller architecture. Each subsystem (CPU, Blkio, Memory, Devices, etc.) is now a distinct module implementing a common \Controller\ trait, which standardizes how resources are applied and how tasks are added to cgroups. This change introduces dedicated error types per subsystem using \thiserror\, improves error propagation, and adds support for specific features like CPU idle control and reserved hugepage limits, while the \Manager\ now orchestrates these controllers to handle subsystem availability and configuration application.

crates/libcgroups/src/v1 · high confidence

Refactored container process lifecycle and added CPU affinity support

The process management logic in libcontainer has been restructured into a three-stage model (main, intermediate, and init processes) communicating via dedicated channels, which improves error handling and allows the main process to manage the container lifecycle more robustly. This change introduces support for setting CPU affinity for exec (tenant) containers via the OCI spec's exec\_cpu\_affinity field, ensuring processes are pinned to specific CPUs. Additionally, the process cloning mechanism now implements a fallback from the clone3 syscall to the legacy clone syscall when clone3 is not supported by the kernel, and the intermediate process is now capable of launching init processes as siblings of the main process using CLONE\_PARENT to prevent re-parenting to the system init.

crates/libcontainer/src/process · high confidence

Refactored init process with new context and error handling

The container init process has been restructured to use a dedicated InitContext for managing initialization state and a comprehensive InitProcessError enum for better error reporting. This refactoring introduces support for Linux personality settings, allowing containers to specify their execution domain (e.g., Linux or Linux32). The change also improves mount handling by preserving flags during readonly remounts of the root filesystem and fixes duplicate mount entries during exec operations. Additionally, the init process now correctly handles duplicate additional GIDs and ensures proper hook execution order.

crates/libcontainer/src/process/init · high confidence

Refactored syscall layer with new Linux implementation and test mocks

The syscall handling in libcontainer has been restructured to use a new \Syscall\ trait interface, separating the actual Linux system call implementations (\linux.rs\) from a test helper mock (\test.rs\). This change introduces support for modern mount operations like \mount\_setattr\ with recursive attributes, \fsopen\/\fsconfig\/\fsmount\ for filesystem mounting, and \open\_tree\, while also adding support for Linux personality, memory policies, and I/O priority. The test infrastructure now uses a structured mock system that records arguments for syscalls like mount, chown, and capability setting, enabling more robust unit testing of container management logic.

crates/libcontainer/src/syscall · high confidence

Removed legacy devcontainer setup and test scripts

The development container configuration has been updated by removing the previous shell scripts used for initializing the environment, setting up test dependencies, and running validation tests. Specifically, init.sh, setup\_test.sh, and test.sh have been deleted, indicating a shift away from the previous Docker/Youki-based local development workflow.

.devcontainer/scripts · high confidence

Stub implementations for cgroup managers return compile-time errors

The libcgroups library now includes stub manager implementations for systemd, cgroup v1, and cgroup v2. When these specific cgroup features are not enabled at compile time, any attempt to manage tasks (add, apply, remove, freeze, get stats, or list PIDs) will immediately fail with a clear error indicating that the required cgroup feature was not enabled during compilation, rather than failing at runtime with generic errors.

crates/libcgroups/src/stub · high confidence

Youki CLI commands are restructured into individual modules

The command-line interface implementation in \crates/youki/src/commands\ has been refactored from a monolithic structure into separate, dedicated modules for each subcommand (e.g., \checkpoint.rs\, \create.rs\, \exec.rs\, \info.rs\, \kill.rs\, \list.rs\, \pause.rs\, \ps.rs\, \resume.rs\, \run.rs\, \spec\_json.rs\, \start.rs\, \state.rs\, \update.rs\). This change introduces new files for previously implicit or combined logic, such as \completion.rs\ for shell completion generation and \foreground.rs\ to handle PTY bridging and terminal resizing for foreground \run\ and \exec\ operations. The \mod.rs\ file now explicitly exports these modules and centralizes shared utilities like \load\_container\ and \create\_cgroup\_manager\. This modularization improves code organization and maintainability without altering the external CLI behavior.

crates/youki/src/commands · high confidence

Youki runtime restructured with new CLI options and observability layer

The main entry point and configuration logic have been reorganized to support new user-facing features and improved logging. Users can now enable logging to systemd-journald via the new \--systemd-log\ flag and control the verbosity using the \--log-level\ option (defaulting to 'error' in release builds). The runtime now supports shell completion generation via the \completion\ subcommand and exposes a new \info\ subcommand to display version and commit details. Internally, the codebase has migrated to the \tracing\ ecosystem for observability, allowing logs to be formatted as either text or JSON and written to files or stderr, while command-line argument structures have been moved to the \liboci-cli\ crate to improve modularity.

crates/youki/src · high confidence

libcgroups library refactored with unified manager and PSI stats

The libcgroups crate has been refactored to provide a unified \AnyCgroupManager\ that abstracts over systemd, v1, and v2 implementations, allowing callers to handle cgroup operations without knowing the underlying backend. This change introduces rootless mode support for cgroup v2 via a new \with\_rootless\ configuration method on the manager. Additionally, the stats module now includes Pressure Stall Information (PSI) data in CPU, memory, and block I/O statistics, and error handling has been standardized using the \thiserror\ crate for more descriptive error messages.

crates/libcgroups/src · high confidence

Test coverage

Add initial rootless Podman integration tests; Added Docker-in-Docker e2e test for youki runtime; Added integration test runner 'contest' with extensive OCI compliance coverage; Added runc integration test suite; Added runtime test harness for OCI spec validation; Added test utility modules for cgroups, networking, and container lifecycle; Added tests for OCI runtime-tools integration; Added tests for container process sibling spawning; Expanded contest test coverage for cgroups v2, container lifecycle, and exec operations; New internal test framework for contest infrastructure.

Dependencies

2047 commits updating dependencies (14 manifests)

A dependency / build maintenance change in (dependencies) — 2047 commits (24 fixs), 14 files.

(dependencies) · high confidence · unverified

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

How this codebase got here

Score

  • CAI 67 → 68 (+0.5)
  • Rubric changed (rubric-2026.09.9 → rubric-2026.09.17) — scores are not directly comparable.

Lenses

  • Code Health 88 → 88 (+0.2)
  • Architecture 77 → 77 (-0.2)
  • Maturity 80 → 80 (+0.1)
  • Readiness 71 → 69 (-1.9)
  • Security 57 → 61 (+3.8)

Resolved (9)

  • Documentation: no installation or build instructions (README.md)
  • Documentation: no licence statement (README.md)
  • Documentation: no usage examples (README.md)
  • Hotspot: crates/libcontainer/src/rootfs/utils.rs (crates/libcontainer/src/rootfs/utils.rs)
  • Hotspot: crates/libcontainer/src/syscall/linux.rs (crates/libcontainer/src/syscall/linux.rs)
  • Hotspot: crates/libcontainer/src/validator.rs (crates/libcontainer/src/validator.rs)
  • Off-boarding risk: anonymized user #1
  • TodoComment (tests/contest/contest/src/tests/checkpoint_restore/mod.rs)
  • TodoComment (tests/contest/contest/src/tests/checkpoint_restore/mod.rs)

New (14)

  • Ambiguous naming for configuration application. CgroupManager.apply takes a high-level ControllerOpt struct, while Devices.apply_devices takes a raw device list. The verb 'apply' is used for both, but the semantic scope differs significantly (general controller config vs. specific device cgroup rules).
  • Dependency hygiene PARTLY measured — Cargo dependencies read, dependency currency not (crates.io unreachable)
  • End-of-life runtime: Rust 1.96
  • Inconsistent naming for single vs. batch operations. CgroupManager uses add_task (singular) but provides no batch equivalent, while Emulator provides both add_rule (singular) and add_rules (batch). This creates an inconsistent pattern for collection-based mutations across the cgroup module.
  • Low cohesion: ContainerBuilder (LCOM4 9) (crates/libcontainer/src/container/builder.rs)
  • Low cohesion: SELinux (LCOM4 16) (experiment/selinux/src/selinux.rs)
  • Medium vulnerability: RUSTSEC-2026-0285 (Cargo.lock)
  • Medium vulnerability: RUSTSEC-2026-0316 (Cargo.lock)
  • Off the main sequence: libcgroups
  • Off the main sequence: liboci-cli
  • Off-boarding risk: anonymized user #1
  • Projects may be oversized for their cohesion
  • Redundant functionality between instance method and free function. CgroupManager.get_all_pids retrieves PIDs for the manager's cgroup, while common.get_all_pids takes a path. Since CgroupManager already exposes the path (via cgroup_path in CgroupConfig or internal state), the free function duplicates the capability of the instance method for a specific path.
  • TodoComment (tests/contest/contest/src/tests/checkpoint_restore/mod.rs)

Changes since last survey

  • 17 commits — 14 feature/other, 3 fixes

By area

  • tests/contest — 10 commits
  • (root) — 3 commits
  • (repo) — 2 commits
  • .github/workflows — 1 commit
  • crates/libcontainer — 1 commit

Notable commits

  • fix: fix(contest): mask /sys/firmware instead of /proc/acpi in mount_test (#3742)
  • fix: fix(contest): skip memory_policy tests that need NUMA (#3739)
  • fix: fix(contest): skip rsvd hugetlb test when hugetlb is unavailable (#3734)
  • change: Merge pull request #3748 from youki-dev/dependabot/cargo/patch-8f8f13f3a4
  • change: Merge pull request #3759 from youki-dev/dependabot/cargo/patch-d3036c01b2
  • change: chore(deps): bump rand from 0.10.2 to 0.10.3 in the patch group
  • change: chore(deps): bump thiserror from 2.0.20 to 2.0.21 in the patch group
  • change: chore(deps): bump uuid from 1.26.0 to 1.26.1 in the patch group (#3728)
  • change: ci: run contest integration tests on aarch64 (#3738)
  • change: feat: implement OCI per-mount propagation options (#3699)
  • change: harden mount source (#3745)
  • change: refact: utility function for check whether the cgroup v2 interface file exists (#3737)
  • change: refactor(contest): extract run_container_with_console helper into test_utils (#3693)
  • change: refactor: extract can_run into a helper utility for cgroups v2 tests (#3736)
  • change: remove cgroupv1 test (#3727)
  • change: test(contest): add cgroup v2 memory integration tests (#3725)
  • change: test(contest): add cgroup v2 pids integration tests (#3741)

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

Survey your own repository

youki-dev/youki was measured the same way every project in this corpus was: the same rubric, at a pinned commit, with the result published in full. Point a surveyor at a repository you know and see whether you agree with it.

About this page

  • The score is its most recent published measurement, taken on 29 September 2026 at a pinned commit. It is not a live figure and does not change until the project is measured again.
  • Measured at commit 31b2dc2b115ca6868c140165dca6d0b33ed81e3a — the exact code this score is about.
  • Scored under rubric-2026.09.17 — the same rubric and the same method as every other entry in this index.
  • Measured by watchdog.canine.dev using codehealth-analyzer preprod-705631bb727e.