sini

Override as graph position: a design for den#686

denful/den#686 asks, underneath the priority table it proposes, for a module's contents to be transitively mapped to override instead of conflict -- a recursive property of the submodule and everything under it, with no per-component lib.mkForce.

The useful version of that is not a declared override list. It is that precedence falls out of where a contribution sits in the graph, with an explicit relation available for the cases where position is wrong. Most of the machinery for this already exists in gen-view, which implements the resolution

sini

gen / den — Project Status

Date: 2026-08-27

Who this is for. You know Nix. You do not know this project. This report tells you what exists, what is decided, and what is left.

How to read the numbers. Every figure comes from a command run against the live repositories on the date above. No figure is copied from a document. Where a claim could not be checked, the report says so.

sini

Using a Third-Party NixOS-Style Builder (finix) with Den

Integrating third-party NixOS-style system builders—such as Finix—into a Den flake workspace requires understanding how Den manages module collection, builder invocation, and output attribute paths.

This tutorial provides a complete architectural guide and three practical integration patterns for wiring Finix hosts into a Den-managed fleet.

Revision note. The first version of this guide was not runnable end to end. Its finixSystem calls omitted the required lib argument, it assumed Finix declares the nixpkgs.* options Den emits, and it activated host aspects through a key Den ignores. Every code block below has now been evaluated against den c7ef3f1 and finix 78fd549; §6 builds a real finix-system.drv. The three corrections are called out inline as Correction 1/2/3.

---

sini

opkssh Storage Layout — Predicate PR Specification (rev 2)

Predicate for the refresh-daemon work (deliverable 0 in refresh_daemon_plan.md): XDG config-path support and non-clobbering key-file naming. Rev 2 folds in the adversarial review (verdict SOUND-WITH-FIXES) and the owner's I7 ruling.

Requirements

1. Existing ~/.opk/ configurations continue to work untouched. Any behavior change anywhere must be explicitly identified, never silent.

sini

Refresh Daemon — Delivery Plan

Companion to refresh_daemon_spec.md (the ratified design, 2026-08-20). All design forks from the earlier draft of this file are resolved; the decision log below records the rulings. Branch: feat/refresh-daemon, stacked on feat/agent-lifetime (PR 1 = openpubkey/opkssh#611).

Sequenced deliverables

0. Predicate PR — storage layout (own design discussion; not yet designed)

sini

OPKSSH Token Refresh Daemon — Design Specification

Successor to the draft reviewed in openpubkey/opkssh#606 (gist version). This revision is the ratified design; §2 lists every material change from that draft with rationale.

1. Overview

opkssh daemon is a standalone, user-started background process that owns OIDC authentication and token refresh end-to-end. When it is running, every opkssh login delegates to it: the daemon runs the OIDC flow, holds all secrets,

sini

Technical Specification: OPKSSH Token Refresh Daemon & ssh-agent Sync

Overview

This specification outlines the architecture for PR 2, building upon the configurable ssh-agent lifetime support introduced in PR 1.

The goal of PR 2 is to transform opkssh login --auto-refresh from a simple foreground sleep loop into a resilient, background-capable Token Refresh Daemon. The daemon automatically maintains active OIDC PK Tokens and keeps loaded certificates in ssh-agent synchronized without interrupting SSH connections.

---

sini

den-aware language server — gen libs + policy + native graphs (scoping)

Repo: den-server (LSP + MCP frontends) · den/gen (projection lib + node.query facet) · nixd (upstream reference) · Date: 2026-07-20 · Status: approved scoping design (gate ladder + consumer analysis; vehicle = one den-server with LSP + MCP frontends over a shared query engine, built MCP-first; Gate-2 spike decides viability + routing, not the vehicle)

Purpose

Scope the work and delivery order for extending Nix language tooling to understand den's gen libraries, policy system, and native (gen-graph) graphs. This is a scoping spec: it fixes the value ladder, the eval-model seam that governs it, the per-gate capability delta over vanilla nixd and over vanilla NixOS, and the vehicle decision

sini

D3 (revised): Pure-present presentation-backend registry

Status: design, approved for spec review Date: 2026-07-17 Supersedes the synthesis model of 2026-06-11-d3-presentation-backend-design.md (the enum + guarded-modules dispatch). The per-app-options threading, the ArgoCD option relocation + back-compat aliases, and the minimal Flux proof carry over unchanged; only the dispatch and synthesis mechanism is redesigned.

Branch: refactor/presentation-backend (PR arnarg/nixidy#104), now rebased onto the ready-to-merge #102 (build/ layout seam) at 8c3c6b0.

1. Motivation

sini

Announcing gen's pure-Nix module system

Draft — publishes after the current v1-trust roadmap lands. The module system, trust artifacts, and fleet measurements are real and green today; den's next-generation internals are the foundation-laid-for, not done-yet, and are phrased that way below. Numbers grounded in gen/BENCHMARKS.md, gen/VALIDATION.md, and gen/ci/README.md as of 2026-07-05.

The short version