
You start a bounty Monday. Wednesday the charter revises. Are your terms still your terms?

The Nano Collective commits to 30 days notice on changes and applies them to new work only. Started under yesterday's terms, those terms hold.


A Nano Collective whitepaper merges. Easy to read that as 'we're building this.'

Merge only means the thinking is good enough to publish. Build is a separate Stage 3 gate, rationale on the page even for a yes. Deliberate departure from the old pattern.


The community fund holds $0. The $30 payout minimum is bigger than the pool. The Nano Collective publishes the empty ledger in its charter so a maintainer is straightforward about what is and isn't fundable today.


Most open source projects chain a maintainer to a repo until they burn out, then let them slip away in silence. The Nano Collective does the opposite: stepping back, going quiet, or rotating off is built in. The chair is borrowed, not owned.



Most get-md installs skip node-llama-cpp. Since v1.4.0 it's an optional peer, not a direct dep - so the ~95% who only need convertToMarkdown skip hundreds of MB of native binaries. Use the LLM path? A clear error points at the install command.


You paste a docs page through a converter and the Mermaid blocks vanish. get-md keeps the fences and recovers rendered SVGs back to source - on by default, no flag to remember.


Most sitemap crawlers trust whatever the index returns. Run one against a big ecommerce sitemap and you find out where the brakes are not. get-md ships with depth caps, URL caps, and glob filters built in. A runaway crawl is exactly the surprise it refuses to ship.


A PDF through a converter usually means a flag, or a per-format branch in your script. `cat doc.pdf | getmd` skips the negotiation. It sniffs the `%PDF` magic bytes and routes to the right extractor. One CLI for HTML, PDF, DOCX, Markdown. Less branching in the script.


Version 0 is a real state, not a missing field. In json-up, JSON without a version key reads as v0 - so legacy data runs every migration on first load. No special branch for the unversioned case, the upgrade path just starts at zero.



The discipline of writing both, even when only the schema changes, is what stops a 'just bump the version' edit from quietly corrupting old data. json-up makes the up function mandatory. The schema alone was never the migration.



"migration failed" in your logs tells you nothing. json-up throws ValidationError, MigrationError, VersionError - ValidationError carries the version and Zod issue path, so the log reads `settings.theme: invalid_enum_value`. The difference between fixing it and guessing.


Most migration chains make you pick sync or async on day one and rewrite if you change your mind. json-up's async builder accepts both: one step awaits a key, the next copies a field in plain JS. No split builders.



A skill that knows its own parts.

Nanocoder bundle skills ship a subagent, its tools, and a command under one skill.yaml. The agent auto-sees its sibling tools, and tools default to scoped - only that agent sees them.

One artifact. No cross-references to maintain.


Editor integrations shouldn't be bespoke. Nanocoder's ACP server speaks the same JSON-RPC protocol Gemini does, so any editor that implements it can host a session. Run nanocoder --acp, point your client at it, and your tools, modes, and history come with you when you switch.



A 1B model burns a quarter of its context window on the system prompt.

The nano tune profile shrinks nanocoder's prompt from ~500-700 tokens to 150-250, and drops find_files, list_directory, subagent delegation. Context freed for the code.


Paying a cloud model to read 40 files is a bad deal.

Nanocoder subagents can pin their own provider and model. Point one at Ollama, hand it a 3B, and codebase reads run in parallel on your machine. Only the answer comes back to your main conversation.



Two systems for one job was the bug.

/schedule wrote schedules.json. Skills already had a place for triggers, so cron moves onto a command's frontmatter or bundle manifest. The JSON file is dropped; the daemon fires it.

confirm: true opts a triggered run into plan mode.


Fine-tuning is the easy part. Getting llama.cpp to compile so you can actually run the model is the part that ends the project. nanotune export downloads pre-built binaries, fuses the LoRA, writes a GGUF. One command.


Validation loss climbing while training loss drops isn't progress. It's overfitting. Nanotune's training display shows both side by side, so you see the gap. The fix: cut iterations (150 to 100 to 75) or learning rate (5e-5 to 2e-5), and the next benchmark run reflects it.



A model with 99% accuracy can still break a coding agent.

Nanotune's benchmark report shows Total Latency, Time to First Token, Generation Time, tokens, and tokens/sec per test. The one that kills workflows is the model that stalls on first byte.



"Is this helpful" is not a feature you build. It is a model you point at criteria. Nanotune writes a judge config once; pass/fail on open-ended responses comes from criteria and passThreshold the model reads. No new code, just a config that names the judge.


A retrain that just adds more data usually adds the same blind spots.

Nanotune's benchmark report lists every missed test by id, so the next round writes examples for those exact cases. Each loop closes a named gap instead of guessing what the model still needs.



A privacy tool you route traffic through protects your IP. prompt-scrub isn't that. It rewrites the text of your prompts locally - emails, paths, secrets become `Email_1` - and never sees your headers, IP, or timing. Bring your own network layer if you need it.



A leaked token in your prompt is a 3am incident. A missed email is a bug. So prompt-scrub puts SecretDetector above Email, Url, and Path. If a URL carries a credential shape, the token wins and the URL is rewritten around it.


A custom identifier in your code is the one thing a regex won't catch. Generic terms on a code payload return noise, so prompt-scrub keeps CodeTellDetector off by default and a no-op. Pass codeTellTerms and it scans only your list, the way a private detector should behave.


A rule pack for prompt-scrub is just an npm package. Install it, list it under prompt-scrub.rulePacks, and your detector shows up in `prompt-scrub rules list` next to the built-ins, in priority order. No plugin runtime, no separate loader.


A default rule pack would have to be wrong about most codebases. Sentinel ships the format, authoring guide, and worked examples instead. Your pack knows your repo. Ours couldn't.


Four tiers, not three. Sentinel rates findings low, medium, high, critical, with confidence on a separate axis. A high-confidence "low" and a low-confidence "critical" both exist, and the gap between them is exactly where bad alerts live.


Dismiss a finding once and Sentinel never refiles it. The audit reads the false-positive label and drops it from future runs, so the noise you triaged on Tuesday doesn't reopen itself next Monday.


The first live Sentinel run files everything at once. Pick dry-run from workflow_dispatch first. You get the would-file, dedup-would-match, and below-threshold preview in the step summary, and your calibration happens before any issues hit a teammate's repo.
