pmarreck

Official Codex app on NixOS

packages/codex-app.nix packages OpenAI's official x86_64 Linux .deb without running its Debian maintainer scripts. The source is the immutable, version-specific APT-pool object for 26.810.41047, pinned by SHA-256.

The upstream payload contains Electron, native Node modules, static helpers, glibc and musl fallbacks, optional Qt shims, and a bundled executable whose ELF section table cannot be rewritten by patchelf. The package therefore runs the unchanged payload inside a Nix-built FHS environment. The host's APT sources,

pmarreck

---

description: "A skeptical, artifact-backed ledger of cases where Peter and AI agents produced a stronger result through iterative synthesis than either participant's starting approach could plausibly have produced alone." datetime: 2026-07-24T02:29:07-04:00 # America/New_York (EDT) tags: [peter, peter-marreck, evidence, evidence-ledger, human-agent-collaboration, human-ai-collaboration, collaborative-intelligence, ai-agents, llm-agents, synthesis, systems-thinking, architecture, empirical-reasoning, counterfactual, agent-wrangling, leadership, career, resume, case-study, jpeg2000, jp2, validation, conformance-testing, standards, differential-testing, oracle-design, evidence-adjudication, mfic, mechanically-falsifiable-independent-control, maker-checker, segregation-of-duties, publication-control, disclosure-control, privacy, cryptography, post-quantum-cryptography, pqc, shamir-secret-sharing, sss, key-recovery, offline-root, password-entropy, randompassdict, sigil, rash, ulam-flower, uzumaki, aedicule, co

pmarreck

Git Review CLI and Evidence Model Specification

Provisional executable: git-review, normally invoked as git review
Provisional storage file: codereviews.ndjson
Status: design draft for discussion
Schema target: v1
i18n phase: prepare
Primary design goal: answer, with inspectable evidence, who reviewed which code, at which immutable Git state, for what concerns, using what procedure, when, with what findings and independence—and identify code whose review evidence is absent, stale, invalidated, or inadequate for current policy.

1. Executive decision

pmarreck

IEEE-754: the numerical equivalent of asbestos in the walls

IEEE-754 is what happens when you take “close enough,” encode it in silicon, make it the default representation for “number,” and then act surprised when civilization starts comparing 0.30000000000000004 to 0.3 with the haunted stare of a man who has just found a raccoon in his type system.

Its first crime is the famous one:

0.1 + 0.2        => 0.30000000000000004
0.1 + 0.2 == 0.3 => false

pmarreck

Giving Claude Code a sense of time (rate-limited, low-noise)

A self-contained recipe. Read this one file and you can reproduce the whole mechanism from scratch — a human or another LLM, knowing nothing else.

---

1. The problem

An LLM agent has no clock. It only knows what is in its context window.

pmarreck

MFIC — Mechanically-Falsifiable Independent Control

A discipline for checks that can't be fooled by the same mistake that produced the work.

Abstract. When the author of a piece of work — an LLM, or a human moving fast — can be confidently and silently wrong, the usual defenses fail quietly: a test written from the same mistaken assumption as the code passes while the code is broken. MFIC is the class of check that escapes this trap, defined by four properties that must all hold at once. It is Mechanical (cases swept by machine, not hand-picked, so nothing is silently omitted), Falsifiable (each case genuinely bites when the work is wrong, on inputs you couldn't pre-arrange to pass), Independent (its verdict comes from the contract or the data — a source the producer doesn't control — which is segregation of duties restated for software), and a real Control (it holds the authority to block the bad outcome, not merely log it). This is the COSO / Sarbanes-Oxley model of internal co

pmarreck

Jujutsu (jj) Quick Reference (For Users and Agents)

For Git Users: The Mental-Model Shifts

The command-translation table below is necessary but not sufficient. A few git assumptions don't carry over — internalize these and the rest of jj stops looking weird.

1. No staging area. Your working copy IS a commit (the @ commit). Every jj command auto-snapshots it. There's no add step and no index. When done, jj commit -m finalizes it and opens a fresh empty one. To split changes (the git add -p workflow), commit everything and then jj split.

2. Commits have two IDs: change_id (stable) and commit_id (mutates). In git, rewriting (rebase, amend) creates brand-new SHAs and the originals fall into reflog. In jj, the change_id is a stable identity that persists through rewrites — only the commit_id (the Git SHA equivalent) changes. Bookmarks and references survive rebases/squashes by tracking the change_id. jj evolog shows every prior commit_id of one change_id.

pmarreck

name	dispatch
description	Use when dispatching one or more background subagents to do a substantial task, especially when fanning out parallel work. Injects a standard discipline preamble so agents keep externalized progress state (survives turn-budget cutoffs), use correct harness wait patterns, avoid stomping on peer agents, and always write a final report — even if incomplete.

Dispatch

Wraps subagent dispatch with a standard discipline preamble. The goal is that any agent you fan out, whether one or five, behaves predictably: it keeps state externalized, fails honestly, and leaves a trail even if cut off.

pmarreck

# Zig API Reference for 2025 (0.14.0 - 0.15.x)

Purpose: Quick reference for LLMs and developers writing fresh Zig code in 2025. Focus on "how to do things correctly now" rather than migration from old APIs.

Current Version: Zig 0.15.x (as of late 2025)

Sources:

• Zig 0.15.1 Release Notes
• Zig 0.14.0 Release Notes

pmarreck

Jujutsu (jj) Quick Reference

Basic Operations

Commits

# Update the description of the current change and create a new empty change on top
jj commit -m "Commit message"

# Edit the description of the current commit