
Sponsorship buys you a logo on the supporters page. Not the roadmap. Not who gets paid. The Nano Collective puts that rule in writing and enforces it across every channel.


A month of whitepaper writing is a lot to lose to a one-paragraph redirect. Before you draft one for the Nano Collective, open a docs issue first, or message Discord. You'll find a co-author, or catch the collision early.


A whitepaper with a proposer who goes quiet doesn't die quietly. After 60 days idle, the Nano Collective moves its status to Paused, an honest label, not a deletion. Anyone can pick it up. Reactivating it later is welcome, not a clean-up job.



30 USD is the minimum balance before Open Source Collective will process a contributor expense. It is an OSC platform requirement, not a Nano Collective cap. Check it before doing the work, or risk an unpaid invoice.



Your diagram was right there in the source. Then HTML-to-Markdown happened, and it's gone.

get-md keeps Mermaid four ways: preserve a fence, recover source from a rendered SVG, reconstruct from a PDF via vision, or validate every fence. Pick the one that fits the input.


The default crawl sees a sitemap and recurses forever. get-md shipped the kill switch: --max-urls caps a run at 10,000, --max-depth at 3. Hard limits the "the spec is just a suggestion" default forgets.



Buffer the whole batch and you OOM before the last URL resolves. get-md's convertBatch yields as each page completes, not in input order, so a 1000-URL run streams to disk the moment it's ready. Memory stays flat at the worker cap.


<100ms with Turndown, 5-10 seconds with the local ReaderLM-v2 path. get-md gives you both, and the choice between them is the engineering call: speed for batch and CI, structure for the single conversion you actually read. Don't pick by default.



A migration chain is only as trustworthy as the step you're on. Every up() output gets Zod-validated, so the fail surfaces at v3, not buried under v9.

That's what json-up does: its ValidationError carries the version it failed at, so the bug is localised, not piled at the end.



Your data already tracks a version under whatever name you picked. `json-up` does not ask you to rename it. Pass key: "version" (or "schemaVersion", or anything else) to migrate() and the library reads yours, not its own.


Your old JSON already has a version: 0.

json-up treats any document missing a `_version` as v0 and runs every prior migration in sequence on first read. Drop the file in and the migrations walk it forward, no pre-edit, no wrapper, no rewrite of legacy data first.



One async up() flips the whole chain. json-up gives you two builders: createMigrations() stays sync, createAsyncMigrations() awaits each step. Pay the async tax only where it earns it.



Nanocoder will never have a paid tier. Not "not yet", not "free for now". It's structural: no investor return, no upsell, no plan B behind the roadmap. MIT licence and the Nano Collective economics charter shape the project, not a marketing promise.


The old scheduler lived inside the TUI. Close the terminal and file watches stopped, cron stopped, triggered runs shared whatever mode the TUI was in. nanocoder daemon exists because event-driven work can't ride on a foreground process.


One tool keeps pulling the model back, even after you've said no. Add it to `nanocoder.disabledTools` in `agents.config.json` and the model treats it as if it never existed: zero prompts, no subagent fallback, no profile opt-out. One entry, permanent silence.


Seven local model servers show up as first-class providers in nanocoder: Ollama, llama.cpp, llama-swap, LM Studio, LocalAI, MLX, vLLM. Local coding is a built-in assumption now, not the power-user escape hatch.



Your CI fires an unattended agent, it dies on a stuck loop, exit non-zero, no usable output, morning lost to a stack trace. nanocoder is built headless-first: the agent loop produces a final answer at completion, so CI gets something it can act on instead of a crash to debug.


Fine-tuning doesn't need a GPU cluster. Nanotune ships for Apple Silicon with MLX, wraps the tooling, and treats a 0.5B to 1.5B model on a MacBook as the default path, not a workaround.


Fine-tuning has too many knobs to guess from zero. Nanotune ships a starting recipe: 150 iterations, learning rate 5e-5, batch size 4. A known-good default for 0.5B-1.5B models on 100-500 examples, so you tune from a real baseline instead of vibes.


A fine-tune without feedback is just training in the dark. Nanotune's loop is train, benchmark, read the failures, add examples for those cases, then train again. The next run starts with a named gap instead of a guess.



A benchmark that scores on vibes is worse than no benchmark. After `nanotune judge configure`, run `nanotune judge test` and watch what it actually returns. Scores, criteria breakdown, reasoning for a known prompt. One verification step before a pass rate is worth trusting.


Your configured iterations are a guess. The loss curve is the answer. Nanotune plots training vs validation and calls out the moment they diverge, so you stop when the model is ready, not when the script says so.


Secrets don't only arrive in the prompt. They arrive in the next turn, inside the ls, git log, and cat results the agent reads back. That's why prompt-scrub runs on every message, not just the user one. Tool results are where the leaks accumulate.


When the model invents a placeholder that isn't in the session map, prompt-scrub doesn't crash and doesn't silently rewrite. The string passes through verbatim, a warning lands on stderr. A hallucinated Secret_2 reaches the user as the literal text "Secret_2". Fail visibly.



Your agent reads `ls /Users/me/work` and the next turn has your full path tree. Same for `cat deploy.yml`. prompt-scrub scrubs every message, user prompt and tool result, so the LLM sees `Path_1` instead of `/Users/me/work`.



A sloppy detector is worse than no detector. prompt-scrub ships NameDetector and CodeTellDetector off by default: a false positive rewrites your code mid-flight, a missed detection just doesn't help. Opt in only when you know the false-positive cost on your own config.


Most scanners hand you a ruleset on day one. Sentinel ships with none. A pack written for one stack lies to the next, so the owner of the code is the right author.


Three layers of suppression, three different jobs. Sentinel deduplicates by content hash by default, lets you label a one-off finding to dismiss it, and reserves a per-repo sentinel.yaml for systematic noise. Pick the lightest layer that solves it.



An LLM audit will get things wrong. Sentinel designs for that instead of around it: every finding carries honest confidence, the same issue dedups by content hash so it never files twice, and one close keeps it closed for good.



Closing an LLM-audit issue because the model misread the code, then finding the same finding re-filed next run. Label the close with sentinel:false-positive. Sentinel reads the label, the finding's stable identity stays in the dedup store, and the issue stays closed.
