Nukesor/pueue

Pueue is a cross-platform daemon and client system for managing and executing background tasks with support for grouping, prioritization, and dependency handling. It provides a secure, encrypted communication layer via TLS and Unix sockets, allowing users to enqueue, monitor, and control task execution through a flexible command-line interface. The system features advanced capabilities such as task callbacks, state compression, and comprehensive filtering, while ensuring robust process lifecycle management across Linux, macOS, and Windows.

17 changes.

This period focused on a comprehensive architectural rewrite of Pueue to version 4.0, introducing modular codebases, automatic TLS certificate management, and cross-platform service support for Windows, macOS, and Linux. The work also established robust integration testing infrastructure and ensured backward compatibility for state and configuration deserialization.

14 changes.

This period focused on refactoring the daemon's core architecture to improve cross-platform process management, state serialization, and network security. Concurrently, a comprehensive test suite was established, featuring extensive integration tests, snapshot assertions, and benchmarking to ensure reliability. The client-daemon communication protocol was also restructured to support enhanced task filtering and secure, granular interactions.

The library now includes a new blocking network layer in \pueue\_lib/src/network\_blocking/socket\ that handles client connections to the daemon. This implementation supports both Unix domain sockets (on non-Windows platforms) and TLS-encrypted TCP connections, utilizing \rustls\ for cryptographic operations. Users benefit from a unified interface for establishing secure or local connections, with platform-specific logic abstracted behind generic traits for listeners and streams.

_pueue\_lib/src/network\blocking/socket · high confidence

Users can now easily manage the pueue daemon on macOS via a new \pueued.plist\ launch agent file and on Linux via a \pueued.service\ systemd user unit. Additionally, a new Python helper script (\release\_artifact\_hashes.py\) has been added to the utils directory, allowing users to download and verify SHA256 checksums for all release artifacts.

utils · high confidence

The daemon's network module now includes logic to automatically generate self-signed TLS certificates (stored in the default \pueue\_dir/certs\ directory) if they are missing, ensuring secure encrypted communication out-of-the-box. This change introduces new files for certificate creation (\certificate.rs\) and TLS listener handling (\tls.rs\), replacing previous manual or external certificate management with an internal, automated setup that validates certificate existence and permissions upon startup.

pueue/src/daemon/network · high confidence

The daemon module has been reorganized into distinct components, introducing a new callback system that allows users to execute custom commands upon task completion using Handlebars templates with variables like task ID, result, and group counts. Additionally, Windows-specific functionality has been added, including a new CLI subcommand structure for managing the daemon as a Windows service (install, start, stop, uninstall) and logic to handle service lifecycle events like logon/logoff.

pueue/src/daemon · high confidence

The \pueue status\ command now supports a query language that allows users to filter, sort, and limit the displayed tasks. Users can specify which columns to show (e.g., \columns=id,status\), filter tasks by status, label, command, or datetime fields (e.g., \start\>2023-01-01\), order results by any column (e.g., \order\_by label desc\), and limit the output to the first or last N tasks (e.g., \first 10\). The table builder also intelligently shows additional columns like priority, dependencies, and enqueue time only when relevant data is present.

pueue/src/client/commands/state · high confidence

This change introduces the foundational project structure, including the initial commit, comprehensive README, CHANGELOG, and architecture documentation. It adds configuration files for development tooling such as \.taplo.toml\ for TOML formatting, \deny.toml\ for license and dependency auditing, and \Cross.toml\ for cross-compilation targets. The repository also establishes contribution guidelines via \AGENTS.md\ (and \CLAUDE.md\), a \Justfile\ for common development tasks, and updates \.gitignore\ to exclude build artifacts and OS-specific files.

(repo-wide) · high confidence

The library now provides a synchronous \BlockingClient\ alongside the existing async \Client\, allowing users to interact with the pueue daemon without requiring an async runtime. This is achieved by introducing a new \network\_blocking\ module that mirrors the async \network\ module, implementing blocking I/O for socket connections, TLS handshakes, and message serialization (CBOR). The network protocol logic has been refactored into shared \protocol\ modules for both async and blocking contexts, ensuring consistent behavior for connection settings, secret-based authorization, and version checking across both client types.

_pueue\lib/src/network · high confidence

The \pueue\ client and \pueued\ daemon are now built from new binary entry points (\pueue/src/bin/pueue.rs\ and \pueue/src/bin/pueued.rs\). The client now supports generating shell completion files for Bash, Elvish, Fish, PowerShell, Zsh, and Nushell via a new \Completions\ subcommand. The daemon adds Windows service management capabilities (install, uninstall, start, stop) and improves daemonization on Windows by properly detaching the process in background mode. Logging output is directed to stderr, and the default log level is set to warning.

pueue/src/bin · high confidence

The daemon's network message handling logic has been reorganized from a monolithic structure into distinct, single-responsibility modules (add, clean, edit, enqueue, env, group, kill, log, parallel, pause, remove, reset, restart, send, start, stash, switch). This change improves code maintainability and clarity by isolating the handling logic for each specific client request type into its own file, while the central dispatcher in mod.rs routes incoming requests to the appropriate handler.

_pueue/src/daemon/network/message\handler · high confidence

The client command logic has been reorganized from a monolithic structure into individual, dedicated modules (e.g., \add.rs\, \edit.rs\, \follow.rs\, \log/mod.rs\). This change introduces specific capabilities such as TOML-based task editing in the \edit\ command, JSON log output support in the \log\ command, and an immediate \--follow\ flag for the \add\ command, while standardizing how all subcommands interact with the daemon via the new Request/Response protocol.

pueue/src/client/commands · high confidence

The daemon's internal state handling has been restructured to separate persistent state from runtime process management. A new \InternalState\ struct now wraps the core \State\ (containing tasks, groups, and settings) and explicitly excludes child process handles, which are instead managed by a new \Children\ module. This module introduces a \BTreeMap\-based worker pool structure to track child processes by group and worker ID, providing specific methods for managing active tasks and finding free worker slots. This separation ensures that runtime-only data (like process handles) is not serialized to disk, while the persistent state remains clean and serializable.

_pueue/src/daemon/internal\state · high confidence

The daemon's network socket layer has been restructured to include platform-specific implementations (Unix and Windows) that enforce stricter security and stability controls. A 10-second timeout is now applied to the client authentication handshake to prevent Denial of Service (DoS) attacks via incomplete TLS handshakes or stalled connections. Additionally, the secret authentication payload is limited to 4MB to prevent Out-of-Memory (OOM) issues, and invalid secret attempts are handled with a fixed delay to prevent timing side-channel attacks, while ensuring the secret payload itself is never logged to avoid log injection.

pueue/src/daemon/network/socket · high confidence

The pueue\_lib crate has been restructured into a modular library with dedicated modules for error handling, settings, state, tasks, and logging. This change introduces configurable Unix socket permissions, a new PUEUE\_CONFIG\_PATH environment variable to override the config file location, and support for editing tasks in TOML mode. It also adds a priority field to tasks, enables state file compression, and improves error reporting by displaying unexpected but valid payloads.

_pueue\lib/src · high confidence

The client interface has been restructured into dedicated modules (cli, commands, style) with a new \cli.rs\ defining the command-line argument parser using Clap v4. This change introduces support for dark mode in the terminal output, allowing the client to adapt its color scheme based on user settings, and adds new flags such as \--immediate\ and \--follow\ for the \add\ command, as well as \--all\ and \--group\ for the \stash\ and \enqueue\ subcommands.

pueue/src/client · high confidence

The network layer in pueue\_lib has been restructured to use a new socket module that abstracts connection logic behind platform-specific implementations (Unix and Windows). This change introduces a generic Listener and Stream trait system, allowing the daemon to handle both Unix domain sockets and TLS-encrypted TCP connections uniformly. For users, this means more robust and maintainable network communication, with explicit support for configuring TLS certificates via the settings module and improved error handling during connection establishment. The implementation defers expensive TLS handshake operations to separate tasks to prevent blocking the accept loop, enhancing responsiveness for concurrent clients.

_pueue\lib/src/network/socket · high confidence

The daemon's process management logic has been restructured from a monolithic handler into distinct, modular components (finish, kill, pause, spawn, start) within the \process\_handler\ module. This change introduces a new \LockedState\ for internal state management and replaces the previous \command-group\ mechanism with \process-wrap\ for cross-platform process group handling (using POSIX process groups on Unix and Job Objects on Windows). Users benefit from more robust task lifecycle management, including improved handling of unexpected task states during finishing, the ability to force-start stashed tasks, and a fix for a stack-overflow issue that could occur during daemon shutdown.

_pueue/src/daemon/process\handler · high confidence

The \pueue\_lib\ message module has been reorganized into distinct \request.rs\ and \response.rs\ files, introducing a comprehensive set of new request types (such as \EditRequest\, \EditRestore\, and \EditedTasks\) and response structures (including \AddedTaskResponse\ and \TaskLogResponse\). This change establishes a more granular and explicit API for client-daemon interactions, supporting enhanced task editing workflows, detailed log streaming, and improved security by hiding sensitive environment variables in debug output.

_pueue\lib/src/message · high confidence

The pueue source code has been reorganized into distinct modules for aliasing, formatting, and tracing, replacing the previous flat structure. This change introduces a new aliasing system that reads command shortcuts from a YAML configuration file and applies them to user inputs, and a formatting module that dynamically selects date/time display formats based on whether an event occurred today. Additionally, the logging infrastructure has been updated to use \tracing-subscriber\ with configurable verbosity levels and optional pretty-printing, improving how users view debug and error information in the console.

pueue/src · high confidence

The process helper module has been restructured to provide a unified interface for managing child processes across Linux, macOS, FreeBSD, NetBSD, and Windows. Platform-specific logic for checking process existence and handling signals is now isolated in dedicated files (e.g., \linux.rs\, \apple.rs\, \windows.rs\), while shared Unix signal handling and Windows thread suspension/resume logic are implemented in \unix.rs\ and \windows.rs\ respectively. This change ensures that pause, resume, and kill actions are handled correctly on each operating system, with Windows using thread suspension for pause/resume and Unix systems using standard signals, all exposed through a consistent \ProcessAction\ enum and helper functions.

_pueue/src/process\helper · high confidence

Added benchmarks for state saving performance; Added integration tests for client subcommands and features; Added integration tests for daemon state restoration and socket communication; Added snapshot and template tests for client output formatting; Added test helper factories for groups and tasks; Added test suite structure for Unix environments; Added tests for backward compatibility of settings and state deserialization; Comprehensive integration test suite for daemon task management; New test helper infrastructure for daemon and client tests; New test helper infrastructure for snapshot and template-based assertions; Restructured client test module organization.

Pueue has been updated to version 4.0.4, adopting the Rust 2024 edition and requiring a minimum Rust version of 1.88. The project now uses Cargo workspace inheritance for shared configuration and dependencies, including updates to core libraries such as clap (4.6), tokio (1.53), rustls (0.23), and crossterm (0.29). The pueue\_lib component has also been updated to version 0.31.1, aligning with these dependency changes.

(dependencies) · high confidence

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

• CAI 69 → 72 (+3.8)
• Rubric changed (rubric-2026.09.9 → rubric-2026.09.18) — scores are not directly comparable.

• Code Health 95 → 95 (+0.0)
• Architecture 99 → 89 (-9.4)
• Maturity 68 → 68 (+0.0)
• Readiness 79 → 71 (-8.0)
• Security 57 → 71 (+14.0)
• Performance 89 (new)

• Documentation: no installation or build instructions (README.md)
• Documentation: no usage examples (README.md)

• Ambiguous configuration loading semantics. read implies loading from a specific file path, while load_profile implies selecting a named profile from the current configuration context. It is unclear if load_profile modifies the current instance or returns a new one, and how it interacts with read. The naming suggests two different ways to achieve similar 'get config' goals.
• Dependency hygiene PARTLY measured — Cargo dependencies read, dependency currency not (crates.io unreachable)
• Inconsistent return types for accessor methods. Most path accessors return PathBuf directly, but unix_socket_path returns Result. This forces inconsistent error handling in client code when accessing configuration paths, despite all being derived from the same Shared settings struct.
• Inconsistent typing for the label field. It is PathBuf in requests and editable tasks, but String in the core Task domain model. Labels are typically human-readable strings, not file paths.
• Inconsistent typing for the same semantic field priority. AddRequest uses PathBuf while Task, EditableTask, and TaskToRestart use i32. This is a clear data type inconsistency that will cause serialization/deserialization errors or logical bugs.
• Inverted test pyramid
• Medium vulnerability: RUSTSEC-2026-0285 (Cargo.lock)
• Off the main sequence: pueue-lib
• Projects may be oversized for their cohesion
• Semantic type mismatch: enqueue_at is typed as PathBuf but semantically represents a timestamp or datetime for scheduling. Using PathBuf for time-based scheduling is confusing and likely incorrect, suggesting a copy-paste error from file path fields.
• While path is consistently PathBuf, the semantic meaning varies. In AddRequest, it likely means 'working directory', but in Task, it is stored as path. This is less of an inconsistency and more of a naming ambiguity, but combined with the other type errors, it highlights a lack of strict domain modeling. However, since the types match, this is not a strict API inconsistency in signature, but the previous points are critical.

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

Nukesor/pueue 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.