nichoth nichoth

## gist:dcfe7289b2da8557c8ea67ec9ebe0cc1
---
name: lum-execute
polytoken:
  tools:
    - ask_user_question
    - file_read
    - file_edit_search_replace
    - file_write
    - glob
    - grep

## gist:00759ce09357948fdedb33a666fc7476
---
name: code-review
description: Review a pull request (or the current branch) with TWO parallel reviewer subagents on gpt-5.5(high) — a standard reviewer and an adversarial reviewer. Merge their findings only after both return; deliver an in-chat summary always and post to the PR only with consent. When reviewing your own branch, iterate on the feedback and re-invoke until no findings remain.
disable-model-invocation: false
tags:
  - productivity
polytoken: true
---

# Code Review

## CODEX.md

      
              5 files
            
          
              0 forks
            
          
                0 comments
              
            
              0 stars
            
          
                nichoth
                / CODEX.md
            
            
              Created
              May 30, 2026 23:00
                — forked from DMontgomery40/CODEX.md
            
              
                Ralph audit loop: Codex CLI read-only code audit runner
              
          
    Ralph Audit Agent Instructions (OpenAI Codex)


Safety Notice (Customize)

If this codebase is production, handles money, or touches sensitive data: treat this audit loop as a high-risk operation. Run with least privilege, avoid exporting long-lived credentials in your shell, and keep the agent in read-only mode.


## conformance testing
# Conformance suites: what they are, when they help, how to build one

A conformance suite is a third axis of testing — distinct from unit tests
and integration tests. Where unit tests prove that a function does what
its body says, and integration tests prove that subsystems compose, a
conformance suite proves that **what the public API claims it does
matches what it actually does, against an external ground truth**.

This document explains the pattern, when it earns its keep, and how to
set one up. The case study is ferrotorch (a pure-Rust PyTorch

## method.md

      
              1 file
            
          
              0 forks
            
          
                0 comments
              
            
              0 stars
            
          
                nichoth
                / method.md
            
            
              Created
              April 7, 2026 18:07
                — forked from dollspace-gay/method.md
            
              
                Verification-Driven Development (VDD) via Iterative Adversarial Refinement
              
          
    Verification-Driven Development (VDD)

Methodology: Iterative Adversarial Refinement

Overview

Verification-Driven Development (VDD) is a high-integrity software engineering framework designed to eliminate "code slop" and logic gaps through a generative adversarial loop. Unlike traditional development cycles that rely on passive code reviews, VDD utilizes a specialized multi-model orchestration where a Builder AI and an Adversarial AI are placed in a high-friction feedback loop, mediated by a human developer and a granular tracking system.
I. The VDD Toolchain


## index.html
<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8" />
    <title>Automerge (Vanilla JS, Unbundled) Demo</title>
    <meta name="viewport" content="width=device-width, initial-scale=1" />
  </head>
  <body>
    <script type="module">
      // The ?bundle-deps here is very dodgy...

## signals.html
<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <title>Signals</title>
  </head>
  <body>
    <button id="decrement">
      -

## modular-css-performance.md

      
              1 file
            
          
              0 forks
            
          
                0 comments
              
            
              0 stars
            
          
                nichoth
                / modular-css-performance.md
            
            
              Created
              June 27, 2025 00:48
                — forked from cferdinandi/modular-css-performance.md
            
          
    This week, I wrote about using the CSS @import rule to modularize CSS, and some performance challenges with that approach.
tl;dr: the issue isn't the @import rule itself, but that files under 1kb often end up the same size or even bigger when gzipped, so you get no compression benefits.
I ran a few additional tests, and wanted to share the data I found.
Current Setup


40 modular CSS files
All imported from a single kelp.css file hosted on JSDelivr


## accordion-group.css
accordion-group {
	background-color: #f7f7f7;
	border-radius: 0.25em;
	display: block;
	margin-block-end: 1.5em;
	padding: 0.5em 1em;
	width: 100%;
}

accordion-group [accordion-trigger] {

## demo.ts
import Database from 'better-sqlite3';
import { createDatabaseClient } from './proxy.ts';

// 1) Create an in-memory DB and your table(s).
const db = new Database(':memory:');
db.exec(`
  CREATE TABLE users (
    id TEXT PRIMARY KEY,
    data JSON
  );
	---
	name: lum-execute
	polytoken:
	tools:
	- ask_user_question
	- file_read
	- file_edit_search_replace
	- file_write
	- glob
	- grep
	---
	name: code-review
	description: Review a pull request (or the current branch) with TWO parallel reviewer subagents on gpt-5.5(high) — a standard reviewer and an adversarial reviewer. Merge their findings only after both return; deliver an in-chat summary always and post to the PR only with consent. When reviewing your own branch, iterate on the feedback and re-invoke until no findings remain.
	disable-model-invocation: false
	tags:
	- productivity
	polytoken: true
	---

	# Code Review
	# Conformance suites: what they are, when they help, how to build one

	A conformance suite is a third axis of testing — distinct from unit tests
	and integration tests. Where unit tests prove that a function does what
	its body says, and integration tests prove that subsystems compose, a
	conformance suite proves that **what the public API claims it does
	matches what it actually does, against an external ground truth**.

	This document explains the pattern, when it earns its keep, and how to
	set one up. The case study is ferrotorch (a pure-Rust PyTorch
	<!DOCTYPE html>
	<html>
	<head>
	<meta charset="utf-8" />
	<title>Automerge (Vanilla JS, Unbundled) Demo</title>
	<meta name="viewport" content="width=device-width, initial-scale=1" />
	</head>
	<body>
	<script type="module">
	// The ?bundle-deps here is very dodgy...
	<!DOCTYPE html>
	<html lang="en">
	<head>
	<meta charset="UTF-8">
	<meta name="viewport" content="width=device-width, initial-scale=1">
	<title>Signals</title>
	</head>
	<body>
	<button id="decrement">
	-
	accordion-group {
	background-color: #f7f7f7;
	border-radius: 0.25em;
	display: block;
	margin-block-end: 1.5em;
	padding: 0.5em 1em;
	width: 100%;
	}

	accordion-group [accordion-trigger] {
	import Database from 'better-sqlite3';
	import { createDatabaseClient } from './proxy.ts';

	// 1) Create an in-memory DB and your table(s).
	const db = new Database(':memory:');
	db.exec(`
	CREATE TABLE users (
	id TEXT PRIMARY KEY,
	data JSON
	);