
"Will this get built?" was the question a merged whitepaper never answered. A merged draft read like a quiet commitment. At the Nano Collective, merge just means the thinking is worth publishing and a 30-day review opens. Build approval is a separate gate, recorded on the page.


"Will the project get built?" There is no honest answer to that for 5 stages. The Nano Collective runs every idea through Spark, a whitepaper draft, 30 days of public review, build approval by the core team, then ship. The output of each step is recorded, including the no.


A whitepaper stops showing on the docs site once it's no longer in motion - shipped, paused, declined, or superseded. The file gets deleted after an archive window, git history keeps the record. The section doesn't accumulate clutter.


A misconfigured include glob shouldn't drain a week's LLM budget. get-md's sitemap walker caps at 10,000 URLs by default and stops collecting when it hits the cap, so a bad pattern fails fast instead of exhausting memory or API spend.



A chunk that reads only "Run npm install" is a chunk that's lost at retrieval. get-md's chunkMarkdown tracks the heading trail and prepends `Docs > Setup > Install` by default, so a deep-section chunk still tells the model where it came from.



You already have the XML in hand. Branch on <urlset> vs <sitemapindex>, or trust the parser? You do not have to. get-md's parseSitemapXml inspects the root and returns `{ type, entries }` either way, so one code path handles both shapes.


Sitemap crawls drift when the allow-list grows faster than your eye. Cast a wide net first, then carve the holes. get-md applies `include` before `exclude`, with the same `*` / `**` / `?` glob syntax for both. One config file, top to bottom, no regex.


Generic "validation failed" is useless. json-up's ValidationError ships the Zod issues array, so `error.issues.map(i => i.path.join('.') + ': ' + i.message)` prints which field broke at which version, no guesswork.



A failed `migrate()` looks like a runtime bug. Often it is the config: empty array, unsorted, duplicate. `json-up` makes the split clean: VersionError = fix the migrations list, MigrationError = your `up()` threw, ValidationError = output did not match schema.



Most libs slap Promise.resolve() on their sync function and call it async. json-up does the opposite. migrateAsync() exists because up() bodies genuinely await (key generation, I/O), so it isn't a wrapper, it's the real path. The three error types stay identical either way.



Two Zods in one lockfile, and your migrations validate against a version your app has never seen. json-up declares it as a peer, so the schema on your data is the same one your app already audits.


A schedule the daemon doesn't read is a job living in your head. nanocoder drops /schedule and schedules.json, moves cron into subscribe blocks on the skill, fired by the per-project daemon. Leftover schedules.json prints a warning instead of silently no-op'ing.



A project convention nobody decided is a turn that obeys it anyway. nanocoder's /memory propose flags assistant proposals with `Possible assistant position reversal` when the turn reads like concession to pressure - so a stylistic preference doesn't get mistaken for a rule.


Most checkpointer hooks store a patch, not the file. So a font or compiled binary - gone on revert. nanocoder's /checkpoint captures each file's full bytes, and skips its own .nanocoder/ tree so checkpoints never snapshot each other. Restore is exact, not reconstructed.



Two thresholds, one config flag. nanocoder's auto profile reads the model id: under 4B params gets the 5-tool nano profile and a 150-250 token prompt, up to 15B gets the 8-tool minimal profile. Above that, full surface, no flag needed. The prompt stops trailing the hardware.



A typo in a CLI flag should be loud, not silent. nanotune benchmark rejects --temperature, --seed, and --samples when they can't be parsed, so --samples 5x fails naming the flag instead of running with a default you never set.



500 examples, one scoring change to test. nanotune keeps the judge in `.nanotune/judge.json`, schema-validated and versioned with the run dir. Three fields to swap. Same scoring on every pass through the dataset, and every change shows up in the diff.



Model size doesn't pick your fine-tune regime: a 1.5B can land in LoRA, DoRA, or Full depending on the dataset. nanotune treats it as a first-class knob (training.fineTuneType, or --fine-tune-type), not a wizard guess.


A pass rate from one draw hides the truth. nanotune `--samples 5` runs each test five times, records pass rate and variance per test, and passes on the majority. Each sample uses `seed + sample_index`, so runs stay reproducible while the samples differ.


A detector that hides its misses can lose a secret. prompt-scrub scores every finding 0.0-1.0 and names the rule that fired, then filters on `minConfidence` before collision resolution runs, so a discarded span never masks the higher-score one sitting inside it.



A privacy tool that writes to disk by default sounds wrong. prompt-scrub does it anyway: each session is one JSON file in the OS config dir, so the same email gets the same placeholder on the next run. Files prune themselves after 7 days idle.



A prompt with PII at 0.85 and one with nothing in it. With prompt-scrub scrub --min-confidence 0.9, both look identical, and the first is now a leak. Under-redaction is the dangerous direction, so a filtered run always prints what the threshold dropped, even when nothing survived


A leaked App private key is a revoke-the-app day, not a rotate-the-secret day. `roster` (alpha) holds it in memory and pipes it to `gh secret set` on stdin: no file, no argv, no process table. A failed write means generating a new key from the App settings page.

The rule that blocks a staff App from merging its own PR is Roster (alpha)'s `review_gate`, and it ships off. Flip it on in `org.yaml`: `roster doctor` fails any repo without an approving review; `roster hire --apply` writes the `roster: review before merge` ruleset.


Zero. That's how many credentials the roster framework ever holds.

Your Staff App key, Public App key, agent credential, and `gh` token stay as repo secrets or on your machine. The CLI and portal shell out to your `gh`, so the codebase has nothing to leak.



Gate a `mention` caller on `author` and the agent's own edit to the pinned status issue wakes another run that edits it again. Forever. Roster (alpha) keys the check on `github.event.sender.login` - whoever performed the action, not whoever wrote the thing it acted on.



"Did not look" and "looked and found nothing" land in the same column on the issue list. Sentinel (alpha) splits them: a file not read this run is held, miss counter unchanged; a file read and clean is aged, one step closer to auto-resolution.


Same file, three rule strings: sql/string-concat, sql/string-concatenation, sql/string-concat-user-input. Put the rule in the dedup hash and the finding files three times. Sentinel (alpha) stamps the hash from the validated pack and the file path, not the model's transcription.


A "high" on weak evidence reads like a false alarm and eats the day. Sentinel (alpha) keeps severity to four tiers - low, medium, high, critical - critical reserved for exploitable paths. Confidence is its own axis, so a rule pack tells the model when to lower it, not guess.



A finding your model won't stop flagging isn't worth debating one issue at a time. Sentinel (alpha) suppresses at three levels, lightest first: a label (sentinel:false-positive, accepted, or wontfix), a repo `sentinel.yaml`, or `do not flag` in the rule pack. Pick the smallest.
