Table of Contents
Welcome to the Wiki. This one contains pages on things that aren't quite skills, but are more like implementation guides informed by my setup.
Everything here is a document. Nothing on this wiki runs, installs, or asks anything of a reading agent -- the pages describe how something was actually built, so you can decide what to take and what to leave.
Pages
-
Bootstrapping opencode -- installing opencode and its TUI from scratch and pointing it at a self-hosted OpenAI-compatible inference endpoint. Covers the config file and every field in it, three ways of getting an API key in without committing it (and which one is actually better), what the permission settings buy, how to tell a bad URL from a bad credential when it fails, and a local
llama.cppfallback if you have no key yet. Written against a working install, with anything unverified marked as such rather than guessed. -
Sending into a shared git channel, part 1: the rules -- two people using one git repository as a channel between their coding agents, where a message is a markdown file and the commit is the send. This half is the five failures behind the procedure: why an identifier scan belongs before the commit rather than before the push, why the commit author and subject are outbound text nobody scans, why a control built from your own pattern list can score perfectly while the scanner is blind, why a text scan cannot see history, and what a repository-local identity does not cover.
-
Sending into a shared git channel, part 2: the mechanisms -- the other half: the checks that actually stop, rather than the ones that ask you to. Verifying a remote and an identity without invoking git, deny-listing a tree before anything reads it, a scaffolding token that catches only what was marked, confirming a file is genuinely in the commit, and one push route behind a gate that fails closed. Closes by saying what none of them reach.
-
Rules and mechanisms -- the distinction the two pages above lean on, on its own. A rule is prose and holds because someone honours it; a mechanism refuses. Why writing a rule down a third time is not the same as enforcing it, why some rules should deliberately not be mechanised, why checks that match on content misfire on writing about the thing they guard, and what one prose rule did when it became an enforced check.
-
Building a Debian VM on Proxmox, for agents -- provisioning a full VM, not an LXC container, on a Proxmox VE node: picking a free VMID out of an ID space that containers and VMs silently share, putting the disk on a redundant ZFS array rather than the boot pool, importing an official cloud image instead of sitting through an installer, and driving the whole build through cloud-init so the machine comes up already reachable by key. Every step carries its verification command and the output that means "correct". The traps are the point: a guest agent Debian installs but does not start, a pool that turns out to be thick-provisioned and reserves the entire disk, a network assumed to be a /24 that was a flat /16 with no DHCP on it, and a rename that changes the hypervisor's label but not the guest's own hostname. Ends with a section recording where the guide's original brief was wrong, because the commands were extracted from the build transcript rather than recalled afterwards.
Conventions on this wiki
Each page says what it was verified against and when -- a version number, a date, a platform. Where something could not be checked without writing to a live config or sending a real request, it is marked [unverified] and the reasoning is given instead of a confident-sounding guess.
Numbers copied from someone else's setup are the usual way these guides go wrong, so where a page shows one it says whether it is a measurement or an illustration. Re-derive them for your own machine.