youki-dev/youki
67.9
Adequate · 29 September 2026
39.4k
lines of production code
Rust
primary language
2
measurements over time
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.