sini

Den 2: Ground-Up Rebuild on Stream Primitives

Den's fx-pipeline has grown to ~7,300 lines of pipeline infrastructure to coordinate a shared trampoline walk. Ned demonstrates that the same semantics can be expressed in ~277 lines using stream composition and a Cycle.js fixed-point. Rather than migrating Den's internals (carrying architectural debt), this spec proposes rebuilding the resolution engine from scratch on Ned's proven foundation, targeting ~1,000 lines of core implementation with full feature parity.

The user-facing API is an opportunity, not a constraint. Since the fx-pipeline branch hasn't shipped, we can fix known ergonomic issues rather than preserve them.

Goals

1. Feature parity with Den's fx-pipeline branch — all 8 test suites must be expressible
2. ~1,000 lines of resolution engine (vs ~7,300 today)

sini

Den 2: Incremental Delivery via Parallel Engines

Companion to Den 2: Ground-Up Rebuild and Stream Architecture Migration.

The rebuild spec proposes ~1,400 lines of stream-based resolution engine replacing ~7,300 lines of handler-based pipeline. This spec defines how to get there incrementally — no flag day, no regression window, rollback at every step.

Strategy: Parallel Engines

Both engines consume the same input (den.aspects, den.policies, den.hosts) and produce the same output (module lists for nixosSystem). They're interchangeable black boxes:

sini

Den Library Decomposition

Den's core systems — aspects, entities/schema, policies, pipes, and the fx pipeline — form a tightly coupled web where no pair is cleanly separable. This spec defines the component boundaries for decomposing den's internals into isolated libraries with clear responsibilities, unidirectional dependencies, and explicit contracts.

The goal is pre-migration extraction: identify and cut the library boundaries in the current codebase so that when the den2 stream rebuild happens, these components can be reused as-is and the rebuild scope shrinks.

Motivation

Den's nix/lib/ contains ~16,500 lines organized by implementation concern (handlers, pipeline, resolve, assemble-pipes) rather than by responsibility. The result is a coupling triangle:

sini

# nixos-module-graph.nix — Visualize the non-nixpkgs import tree of a NixOS configuration
#
# Reads evalModules.graph (available on every nixosSystem result since nixpkgs 24.05+),
# resolves nix store paths back to flake input names, filters out nixpkgs base modules,
# and renders the remaining user-defined + third-party module import tree as indented text.
#
# Usage:
#   nix eval --impure --raw --expr '(import /tmp/nixos-module-graph.nix { flakePath = toString /home/sini/Documents/repos/den-configs/slashfiles; host = "evo-x2"; })'
#
# Or edit the defaults below and run:

sini

Aspects Library Extraction

Extract den's aspect type system into a standalone library — a successor to flake-aspects with nested aspect support, built-in identity, unified module key typing, and schema extensibility. Developed inside den at nix/lib/aspects2/, later extracted to its own repo with flake-aspects' git history preserved.

Companion to: 2026-05-09-schema-lib-extraction-design.md (the schema library). The aspects library accepts schema extensions via a parameter; the schema library provides the extension mechanism. The two are independent but composable.

Goals

1. Standalone library — usable without den, drop-in upgrade from flake-aspects
2. Built-in identity — aspects are addressable by key (aspect-chain + name), computed from the type system

sini

Schema Library Extraction

Extract den's schema system into a standalone library — a generic typed record registry with extension points, strict mode, and identity hashing. Entities (hosts, users, homes) are schema instances, not a separate system.

Companion to: 2026-05-09-aspects-lib-extraction-design.md (the aspects library). The two libraries are independent but composable — den's schema extensions wire them together.

Goals

1. Standalone library — usable without den or aspects. Any Nix project needing a freeform-typed record registry with extension points can use it.
2. Kind registry — declare named record types (kinds), merge kind modules from multiple sources, build submodule types from them.

sini

den-schema: Standalone Schema Library

Standalone flake library extracting den's schema system into a generic typed record registry with extension points, strict-by-default validation, identity hashing, cross-instance references, introspection, and declarative methods.

Supersedes: 2026-05-09-schema-lib-extraction-design.md (earlier exploration). Companion to: 2026-05-09-aspects-lib-extraction-design.md (the aspects library). The two libraries are independent but composable — den's schema extensions wire them together.

Goals

1. Standalone flake library at ../den-schema — usable without den. Any Nix project needing a typed record registry with extension points can use it. Exposes both lib for programmatic use and flakeModules.default for flake-parts integration.
2. Kind registry — declare named record types (kinds), merge kind modules from multiple sources, build submodule types from them.

sini

Aspects Library Extraction (revised)

Extract den's aspect type system into a standalone library — a successor to flake-aspects with nested aspect support, built-in identity, unified module key typing, and schema extensibility. Developed inside den at nix/lib/aspects2/, later extracted to its own repo with flake-aspects' git history preserved.

Companion to: den-schema (github:sini/den-schema) — the standalone schema library. den-schema provides sidecar extraction, strict mode, identity hashing, methods, and instance registries. The aspects library adopts den-schema's sidecar extraction pattern for aspect-level metadata channels; the two libraries are independent but composable.

Revision history:

• v1 (2026-05-09): Two-branch freeform dispatch (aspectSubmodule + deferredModule)
• v2 (2026-05-10): Three-branch dispatch, adds parametricType. Theoretical — written before implementation.
• revised (2026-05-10): Post-implementation. Incorporates learnings from fixing the __contentValues wrapper leak i

sini

den-schema Feature Proposals

Inspired by analogous libraries in Haskell and other functional languages. den-schema is essentially an extensible record registry — a pattern with deep roots in the Haskell/ML ecosystem.

1. Validation Combinators

Inspiration: Haskell's validation / validated — accumulating errors rather than short-circuiting, composable validators.

The module system gives you per-field type checking for free, but cross-field constraints don't have a home. Right now consumers write assertions or mkIf hacks.

sini

Review: espdesign/nixos.den

Good config overall — well-structured aspects, clean separation of concerns. The warnings are harmless but there are a few real issues.

The Warnings

denful, resolved, id_hash, collisionPolicy — these are internal Den attributes that end up in config.flake due to the freeform type. They're cosmetic warnings from Nix, not errors. Every Den flake gets them. They don't affect builds.

Actual Issues