
Merging a whitepaper is not the same as approving it. The Nano Collective runs a 30-day public review on every proposal, then a separate, dated Stage 3 call with rationale attached, even on a yes. The merge opens the door. The decision is its own act.


You close a ticket on a Nano Collective repo and go looking for the bounty. The pot is empty today. The plumbing is real: fiscal host, ring-fenced community fund, public ledger. The volume is not. Saying so is the commitment, and the page is the proof.



A Nano Collective whitepaper has no gatekeeper. The proposer is a frontmatter field anyone can amend and keep going. 60 days of silence and the doc moves to Paused, an honest label, not a hiding place.



The hard part of contributing is knowing what you signed up for. The Nano Collective's Economics Charter is plain language, versioned, dated, and predates the fund. New financial terms apply to new work only. The contribution model is in the file, not in someone's head.



One button can't fix four inputs.

A fence in source is a string. An SVG on GitHub is a DOM crawl. A PDF diagram is a vision problem. A model-emitted diagram is a parse risk.

`get-md` ships four Mermaid paths because the input decides which applies.


A PDF beyond page 10 isn't a document to an LLM. It's a context bomb. `get-md` renders only the first 10 pages for vision and keeps the rest as text. The cap is the feature.



You fetched the docs page and every diagram came back as flat text. get-md's recoverMermaid pass hunts the source first: sibling scripts, data-code on the wrapper, hidden templates. Only when none of those exist does it fall back to SVG accessibility text, behind a strict guard.



Your mermaid fence came back with backslashes in front of every backtick.

Not a render bug. get-md assumed your string was HTML and escaped the fences.

Pass `inputType: "markdown"` and they pass through. The CLI reads `.md` from the extension; the library can't.


Stop trusting that your up() returned what the next version expects. In json-up, each migration carries its own Zod schema and it runs against the output of every up() before the next step sees it. Drift fails at the version it broke, not three later.



`migrate()` threw. The stack says "Error" and nothing about which version or why. json-up splits it: ValidationError for schema drift, MigrationError carries the original cause, VersionError for bad ordering. Catch the right one and the fix is one line.



Most migration libraries feel like a framework to learn. json-up is two builders, two runners, three error types. The whole public surface fits on one screen and that is the point.



A migration run with versions out of order or duplicated should not return partial state. Silent drift is worse than a stack trace. json-up throws VersionError on bad config so you find the bug on day one, not in production six months later.



Your 3B local model isn't bad. Its context is just stuffed with instructions about itself. nanocoder's `/tune` nano profile trims the system prompt to 150-250 tokens so the model spends context on your request, not on reading about itself.



Five config fields, every model swap. None of them right by default. nanocoder's auto profile picks minimal up to 15B and nano under 4B, so the prompt stops trailing the hardware.



A 20-provider CLI is only useful if your code stays your code. nanocoder phones nothing home: no usage beacon, no crash report, no model-call audit trail. Pick the provider, run the local server, and the only network traffic is the request you sent.



Fine-tuned 7B fails the agent loop not because it's small, but because it emits broken tool calls. Nanocoder ships native, XML, and JSON paths, plus repair on both fallbacks, so the parser bends instead of your turn ending. Your model finishes the job.



A slash command should fire when work happens, not when you remember to type it. nanocoder Skills subscribe to file events or cron schedules, so the trigger is the trigger.


200 lines of training YAML and half the flags don't exist in the version you have. nanotune ships init, data add, train, export, and benchmark as guided prompts, so the config is what you type, not what you paste.


Two benchmark runs differ and you blame the sampler. Default temperature 0 and a fixed seed make that variance a real change in the model, not a mood swing. nanotune benchmark pins both so the diff tells the truth.


An LLM judge is a model with opinions. `nanotune judge test` sends a known pair and prints the scores, criteria breakdown, and reasoning. Run it once before you trust it on a real benchmark.



Most fine-tuning tutorials assume a cloud GPU at the other end of the command. Nanotune ships for Apple Silicon + MLX first, llama.cpp second, with cloud as one option in the menu. The default matches the laptop you actually fine-tune on.



Fine-tune drifting toward overfit or underfit? nanotune train takes --fine-tune-type lora, dora, or full, plus --lora-rank, --lora-alpha, --lora-dropout, --batch-size. Validated against the schema before the run, so the bad number fails fast and names which knob to turn.



Raise --min-confidence and the output looks clean. But "clean" and "had nothing to clean" look identical. prompt-scrub always reports what the threshold suppressed, even when nothing survived, so a filtered run never goes quiet.


"Private AI" tools rarely say what they actually protect. prompt-scrub's threat model does: wins (secrets, identifiers), partial wins (provider-side profile building), out of scope (style fingerprinting, semantic leakage, the network). Naming the limits is the design.



A vendor key matches at 0.99. A capitalised word matches at 0.50. prompt-scrub prints the score of every entity, so you set the threshold with data, not vibes. `inspect` first, then `--min-confidence`.



Pick `--min-confidence` blind and you'll drop a real key or keep a false one. prompt-scrub's `inspect` lists every entity with its score and the detector that flagged it, so you can see exactly what a given threshold would cut before you commit. One run, then scrub.


Most SAST ships a ruleset you didn't choose and a backlog of findings you don't trust. Sentinel alpha ships zero rule packs. You write the one for the code you actually ship, which is the only pack that's allowed to grade that code.


Hosted scanners are strong on common stacks and blind to yours. Manual audits are right for a launch and too expensive weekly. Sentinel exists for the middle: a cheap, continuous loop where you write the rules for the code you actually ship.


First Sentinel dispatch files everything above threshold. There's no summary-only warm-up. Before it goes live, trigger dry-run from workflow_dispatch. The preview shows what would file, what dedup catches, what sits under threshold. Tune from that, not from a noisy tracker.



4-6 today, 5-5 tomorrow, same issue. Sentinel alpha's dedup hash covers rule, file, and category, and deliberately not the line range. An LLM that drifts through the file still hashes to one tracker entry, not two ghosts.
