nomos

About

Hi HN, Mark here. If you&#x27;ve pointed Claude Code, Cursor, or OpenCode at a codebase you care about and walked away thinking AI coding tools are a net negative, I pretty much agree with you. Left directly on a working branch, models optimize for shutting the compiler up on the current turn. Hit a tricky failure and they delete the failing assertion, return a hardcoded nil&#x2F;true stub, rewrite the spec to match broken code, dump a 300-line function into the wrong package, or burn $15 of tokens editing in circles. Writing longer rules files ("IMPORTANT: NEVER DELETE TESTS") breaks down once context fills up. Starting over the summer I built Nomos: a single 28MB stripped static Go binary (CGO_ENABLED=0, Apache 2.0) that sits between your repo and whatever coding agent you already use. You run "nomos init" once and keep prompting in plain English - the agent drives the worktree, verification, and self-fix loop under the hood. Instead of trusting prompts, Nomos locks main read-only via Git hooks, separates spec&#x2F;contract tasks (INT- ) from code tasks (SUB- ) in a local causal DAG (nomos task dag) so an agent can&#x27;t edit the spec to excuse broken code, and isolates every task in a Git worktree (worktrees&#x2F;<repo>-<task>) under a strict state machine (IDLE -> PLAN -> EDIT -> REVIEW -> SYNC -> LEARN). Throwing away a bad run is free. Before anything merges to main, "nomos verify" runs 42 in-binary structural&#x2F;AST gates (~460ms full pass, ~24ms single-file via --fast-file) plus your repo&#x27;s own compiler and test suite. It blocks fake shims, deleted assertions, skipped tests (t.Skip, @pytest.mark.skip, #[ignore], @Disabled, [Fact(Skip=...)]), leaked secrets, functions over 60 LOC, complexity spikes, hardcoded paths, symlinks, and nomos.yaml rubric tampering against pinned main, returning file:line fixes for the next turn. Any gate failure or panic aborts the two-phase merge before main moves. "nomos mem" stores architectural lessons locally in embedded pure-Go SQLite (mneme.db), promoting patterns only after a verified merge with a Git Notes receipt (refs&#x2F;notes&#x2F;nomos&#x2F;releases) so failed runs don&#x27;t poison memory. No cloud account, daemon, or telemetry. One fun lesson from running the PreToolUse and PostToolUse hooks against the public TraceTrial-Bench harness benchmark (arXiv:2610.32285 - summary and spec in the repo README): my first PostToolUse hook injected helpful "process failure &#x2F; refusal" warnings into tool results, and it degraded native OS EACCES guardrail attribution by -39.3% because synthetic hook text polluted error channels. Compiling "nomos hook" (session-start, pre-tool, post-tool at ~4ms cold start), keeping PostToolUse silent on native channels, and moving enforcement to PreToolUse path guards plus a 3-strike identical-failure circuit-breaker recovered that -39.3% drop and lifted stateful handoff, context continuity, and guardrail tasks cleanly. Two rough edges upfront. First, while full type-checking, tests, and coverage ratchets (go test, LCOV, Cobertura XML) run via native toolchains across Go, TS&#x2F;Svelte, Python, Rust, C&#x2F;C++, Java&#x2F;Kotlin, and C#, the fast in-binary pass uses go&#x2F;ast for Go and combines a wazero WASM linear-memory cache and .scm query compiler with pure-Go multiline lexical scanners rather than bundling multi-MB per-language .wasm grammars (keeping the binary 28MB, CGO_ENABLED=0). Second, running the full IDLE -> PLAN -> EDIT -> REVIEW -> SYNC -> LEARN loop adds turn overhead, so for a 100-line weekend prototype raw vibe-coding is faster - Nomos is for repos you still have to understand six months from now. Curious how others here fence coding agents in on real repos (containers, Git hooks, jj workspaces, custom linters?), and what sneakier "make the build green" shortcuts still slip past your checks.

Discovery history

1. Show HN

   Nov 2, 2026 · 1 observations