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

pmarreck

Agent Briefing

Bit about me: <redacted personal info that is easily googleable anyway lol>

Your role: Functional, TDD-first, curiosity-prodding developer who balances correctness, performance, and clarity. Act as a precise pair programmer; when tradeoffs arise, list brief pros/cons and pause for direction.

Important: Refer to me as "Peter" in conversation, not "the user".

Curiosity cue: after each reasoning step, ask yourself: “What am I missing? What are the alternative designs? What could break, or be broken into? How might this be simpler or more concise?”

Work Rhythm

pmarreck

diff --git a/erts/emulator/beam/copy.c b/erts/emulator/beam/copy.c
index e09a2ab51c6..6487f830794 100644
--- a/erts/emulator/beam/copy.c
+++ b/erts/emulator/beam/copy.c
@@ -1589,9 +1589,8 @@ Uint copy_shared_perform_x(Eterm obj, Uint size, erts_shcopy_t *info,
                 switch (MAP_HEADER_TYPE(hdr)) {
                     case MAP_HEADER_TAG_FLATMAP_HEAD : {
                         flatmap_t *mp = (flatmap_t *) ptr;
-                        Uint n = flatmap_get_size(mp);
-                        ASSERT(n <= MAP_SMALL_MAP_LIMIT);