
You don't need a track record to ship a project at the Nano Collective. Open an issue on the docs repo today; that's Stage 0. If the whitepaper holds up through 30 days of public review, the build gets approved.


Waiting 30 days for review on code that's already running is friction without signal. The Nano Collective runs the public window at 14 days when a project is already shipping, because reviewers can read working code and the verdict arrives faster.



Restating shared terms in every README is how the collective drifts. The Nano Collective keeps four canonical pages, Charter, Support, Community, Brand, so projects link instead of paraphrasing. One place to edit, every doc stays in sync.



0 CLAs at the Nano Collective. Every project ships MIT, the contributor keeps the copyright, and no future board can relicense their work. The licence you sign today is the licence that ships tomorrow. That is the deal solo maintainers are betting on.


Tools that need an API key to read your file aren't local-first. `get-md` with `useLLM: true` and no `llm` block falls back to a local ReaderLM-v2, so structured-markdown extraction works with no key, no telemetry, no upload. Privacy is a default, not a setting.



A JSON array from a CLI looks great in the README and breaks the moment you try to pipe it. One element, one line, one `jq` filter - that's the shape Unix was built around. `get-md --batch --json` writes one result per line, so it lands straight in `jq` without a wrapper script.



A docs site with 50,000 URLs in its sitemap shouldn't take down your disk on a Tuesday. `get-md --sitemap` ships with `--include`, `--exclude`, and a hard 10,000 URL cap, so a sitemap crawl is a bounded archive by default, not an unbounded scrape you find out about at 3am.



A crawl can finish and still leave you guessing which pages failed. get-md fixes that with `--manifest`: the JSON sidecar records each URL's status, and points successful results to their output files. It is the audit trail that makes an extraction run inspectable.



One schema should own the whole contract. json-up's Zod schema does: it validates each migration's output at runtime and infers the TS types end-to-end, so the type you read is the shape you actually get.



A schema bump that rewrites your store loses records that don't fit the new shape. Tip: keep the old shape, add a step. json-up's migrate() walks _version forward through your chain, each up() running on the previous step's output, so v3 records come back upgraded, not rebuilt.



Most migration chains hand you an `any` between steps. `json-up`'s builder doesn't: each `.add()` returns a new instance typed from the previous step's output. v1's schema becomes v2's input type. The chain carries the contract, in TS.



String matching `err.message` to decide what to do is how you write a bug that ships. `json-up` throws three named classes instead: ValidationError (names the field), MissingKeyError, TypeMismatchError. Branch on cause in catch, not on prose.



A coding agent that can spawn itself isn't autonomous, it's a recursion hazard. nanocoder ships with `nanocoder.disabledTools: ["agent"]` so the loop has a hard stop and the work stays flat.



A slash command shouldn't need a separate install. In nanocoder it's one `.md` in `.nanocoder/commands/`. Restart, it appears under `/`. Bundle with a subagent and tool as `.nanocoder/skills/<name>/`: one folder, `skill.yaml` plus `commands/`. Commit the folder.



Most "plan mode" is the model promising to behave. `--mode plan` in Nanocoder strips write tools from the system prompt and blocks them at the policy layer. Read-only by construction, not by etiquette. A shipping CLI that refuses writes by design is the stance worth having.



`/schedule create|add|start` and `schedules.json` are gone. The nanocoder scheduler used to be its own subsystem because subscriptions didn't exist yet. Now `subscribe: schedule.cron` on a command frontmatter fires through the same daemon. A subsystem became a frontmatter key.



Most file-tree search only filters what's expanded. A fuzzy match five directories down stays invisible until you drill to it. Nanocoder's /explorer filters the cwd recursively, so the deep hit surfaces without the walk. Nested search in a TUI is something IDEs still get wrong.



One fine-tuning command should own every regime. Nanotune's train exposes LoRA, DoRA, and full FT through a single --method flag, so the question you answer at the CLI is "which trade-off", not "which tool".


142ms to first token on reply 20, same as reply 1. nanotune chat starts one llama-server once and keeps it warm, so the model never cold-starts mid-conversation.


Most fine-tunes are debugged at hour three of a six-hour run. Nanotune's `train --dry-run` validates the config against the same rules as a real run, then exits. Zero GPU-seconds spent finding out your `--lora-rank` was a typo.


A six-hour fine-tune dies at hour five if the laptop sleeps. Nanotune saves checkpoints every --save-every steps and picks training back up from the last one with --resume. The cloud default restarts the run on the same failure. Posture decides which one you actually finish.



3 local providers, 0 bytes leaving the box. nanotune's llm-judge accepts Ollama, a local llama.cpp server, or LM Studio as the judging model, so an eval step over your training data never leaks to a hosted API. Privacy is a floor, not a flag.


A custom detector should install like any other dep, not through a plugin loader. prompt-scrub rule packs are plain npm packages: three export shapes (default array, named `detectors`, or `default.detectors`), resolved by Node like everything else in your tree.


Your session map has no value if it dies with the tab. prompt-scrub stores it as JSON in ~/.config/prompt-scrub/sessions/ on Linux, the OS-standard config dir, so placeholders survive reboots and machine moves. Persistence is what makes it a session.


Most redaction tools are one-way: once the original is replaced, it's gone. prompt-scrub's scrub and rehydrate are engineered as exact inverses, so the same session restores the original text across many turns. Reversibility is what makes it safe to automate.


A redaction tool that picks what to redact on first run has already lost. prompt-scrub ships every detector disabled and asks for an explicit `--enable-detector` flag. Quiet start, deliberate posture.



Nothing worse than installing a security tool and waking up to 200 filed issues you didn't ask for. Sentinel ships with no rule packs of its own. The starter `sentinel.yaml` is scaffolded but inert. Opt in by editing one file.



The audit ran on every file. Nothing filed. Sentinel's severity_threshold is the gate: findings below it live in the run summary, not in your issue tracker. One knob, one line of YAML, the dial between a quiet inbox and a busy one.



One rule, two file locations, same identity. Sentinel rule packs are hashed by their body content, not the line anchors inside the source. Move the rule, rename the file, the cache key stays put.


Find a different set of "critical" issues every Monday morning, and your auditor is the wrong tool for the job. Sentinel pins `--provider` and `--model` per `init`, so the model grading today's scan is the one re-grading tomorrow's.
