dark-factorylisted

# dark-factory Decided work goes in; a worker builds it in an isolated worktree and opens a pull request. Nobody signs off in between. The user's moment is the pull request, or auto-merge where the project has it on. You submit, read, answer, and report. The scripts live in `~/.claude/skills/dark-factory/scripts/`, called `$DF` below, and reach the server wherever `FACTORY_BASE` points (a Tailscale network works well for this, but any reachable URL does). ## Rules 1. **The scripts own every request.** When one cannot do what you need, say so. 2. **The user approves.** `pre_approved: true` means they saw the spec; the submit section says exactly when that is true. 3. **Report outcomes faithfully.** Show what the factory said, failures included. A spec reaches the public pull request body close to verbatim: write `the user`, never a person's name, a machine's name, or house vocabulary. 4. **Restart the server yourself, never the worker.** Your infra repo's `factory-restart` script restarts `factory-server` on the factory host and waits for `/healthz`; `--status` reports without restarting. The worker spawns Claude Code, which reads the login Keychain, and an SSH session cannot reach it, so a worker that is down is the user's to start from a terminal on the factory host itself. Restarting is not deploying: the binary there is whatever was last installed, and a merge does not change it. A `factory-deploy` script builds the merged server from the local checkout and installs