GitHub AI Daily · 2026-11-09 (Monday)

1. Today's picks (5)

1. open-mtor-atlas/atlas: an mTOR research database graded by what the evidence can carry — 400+ primary studies where every claim names its source, its measurement conditions, and the point where it stops holding

URL: https://github.com/open-mtor-atlas/atlas ｜ ★0 ｜ CC BY-4.0 (data) / MIT (code, dual-licensed) ｜ HTML

What happened

5 commits inside the window (11-08 10:43Z to 11-08 19:33Z), all data updates, running steadily at several increments a day. The README states the whole project's position in one line: "a curated, evidence-graded database of mTOR pathway research in which every claim carries its source, the conditions it was measured under, and the point where it stops holding." — every claim carries its provenance, its measurement conditions, and the point at which it stops holding.

• ⭐ Evidence is graded by study design, not by quality, and the README insists on this repeatedly: S = synthesis of human data (systematic review / meta-analysis), H = human study (clinical trial or observational), A = animal model, M = molecular / in-vitro (mechanistic), R = review. It says plainly that studies are "labelled by study design, not by quality, importance, or citation count" — "The code says what kind of claim a study can support, not how good it is."
• ⭐⭐ The grading scheme itself was changed once, and the reason is worth copying: the letter ladder was originally A–D, and was replaced in September 2026 by the current five tiers. The README gives the reason directly: "a lettered ladder reads as a quality grade, which it never was", and "the old bottom tier merged primary mechanistic work with narrative reviews — two different kinds of claim". The change was prompted by an external critique from a researcher in the field, and the README is explicit that the underlying data was not re-graded — only the labels shown to readers were.
• ⭐ The project states one counter-intuitive sentence out loud: "A mechanistic paper is not 'worse' than a trial."
• ⭐ Beyond the study corpus there are two more layers: a knowledge-graph view connecting genes, diseases and interventions, and an "open questions" layer — evidence gaps identified across the corpus, each paired with a proposed testable experiment.
• ⭐ AI-friendly access is complete: a read-only JSON API (no key required), an OpenAPI 3.1 specification, and an MCP server for AI assistants (source and install instructions under mcp/); the dataset itself carries a Zenodo DOI (10.5281/zenodo.22059963) for formal citation, plus one page gathering every identifier — bio.tools, FAIRsharing, GitHub, ORCID — with a ready-to-use citation.
• ⭐ The licensing is a clean dual licence: curated content and data (study records, evidence grades, curated prose, gap hypotheses, everything under atlas_data/ and the generated pages) are CC BY 4.0; source code (the Python generators, validation and verification scripts, site JavaScript) is MIT.

Why it matters

• ⭐⭐ This is very nearly the ruler my "4P Precision Nutrition Watch" public account is missing, and it has already been calibrated. When I write about mTOR, rapamycin or autophagy, the easiest mistake is to present "a mechanism at the cellular level" as "an effect in the human body" — and this project blocks that at the data layer with five letters: a reader seeing M knows it only holds in vitro, and only H tells them human data is behind it. Applied to my platform: every SNP judgement in GRPM and every mechanistic statement in an intervention report should carry an "evidence design type" label rather than an evidence-strength score.
• ⭐⭐ "The grading was changed because a lettered ladder reads like a quality grade" is a hard constraint on my own content system. I had previously designed an "evidence strength A/B/C" label scheme for my articles — which is exactly the design this project criticises. Grading by evidence type (cell experiment / animal / observational human / randomised trial / systematic review) is more honest than grading by strength, because the former only declares what kind of claim a study can support, while the latter implies a comparison across study types that does not hold. What I need to change is not the label but the axis it is graded on.
• ⭐⭐ The "evidence gap layer with testable experiment proposals" is the structure I should copy most urgently. My GRPM project has been stuck on one thing: a report can only say what is known, not what is still missing — because gaps have never been treated as first-class records. Listing the questions this report could not answer, and for each one naming the kind of study that would answer it, makes a report far more credible than ten more paragraphs of what is known. And it structurally defuses the hallucination problem: a gap is a schema field, so the model cannot invent one — it can only invent an answer, and an answer must attach to an existing piece of evidence.
• ⭐ "Every claim carries its measurement conditions" is precisely the link missing from my intervention-report storage checklist. The same sentence — "magnesium improves sleep" — means one thing in magnesium-deficient adults and something else entirely in people with normal serum magnesium. The conditions under which evidence holds must live in the same field as the data, not in a paragraph of prose.
• ⭐ Data under CC BY 4.0 plus code under MIT is a licensing structure I can build on directly — I do not even need to modify the code; pulling its study records into my content library as cross-references is legal as long as I attribute. It also ships both a JSON API and an MCP server, which means my article-topic tooling can plug it in as a controlled corpus source rather than scraping web pages.
• ⭐ Maintained independently by a high-school student and his father, with a Zenodo DOI, an OpenAPI spec and an MCP server — the signal value here is that a teenager can deliver "evidence grading + machine-readable interface + formal citation + dual licensing". By that standard, requiring the same of my own expert packages is not excessive.
• ⭐ Licensing note: of this issue's 121 entries, MIT and Apache-2.0 account for 93 and are safe to build on, while AGPL-3.0 (9) and GPL-3.0 (5) can be read but not copied, PolyForm Strict forbids commercial use entirely, and 4 are undeclared. mTOR Atlas's "data CC BY 4.0 / code MIT" is the cleanest licensing structure in this issue — this is what the right answer looks like when a one-person company picks a foundation.

2. hherb/bmlib: turning "can this paper be trusted" into programmable infrastructure — a four-state retraction verdict, Cochrane nine-domain risk of bias, and a PICO where every part is backed by the paper's own quoted passages

URL: https://github.com/hherb/bmlib ｜ ★2 ｜ AGPL-3.0 ｜ Python + Rust

What happened

26 commits inside the window (11-08 11:33Z to 11-08 20:30Z), whose thread is plugging holes in secret handling and cross-language consistency. The two newest commits make one concrete thing very clear: fix(secrets): #686's review — refuse another account's Windows credential, and require the interop t... and fix(secrets): one keychain item from both languages on every platform (#686) — the same secret must be one keychain entry from both the Python and Rust implementations, on every platform, and another account's Windows credential must be refused rather than used. On the same day there is also fix(agents): #717's review — pin the system prompts across languages, and say when a retry carries t... — the system prompts are pinned across the two languages, and a retry says what it is carrying.

• ⭐ It turns "the plumbing every biomedical literature tool would otherwise rewrite" into a shared library, covering ingestion and lookup (PubMed, bioRxiv/medRxiv and OpenAlex synced with dedup by DOI/PMID; one paper reachable by PMID, DOI, PMC ID or preprint accession), retractions (Retraction Watch lookup and one four-state verdict: retracted / concern / clear / unchecked), full text (tiered retrieval via Europe PMC, Unpaywall and DOI, JATS XML parsing, PDF and HTML conversion, and one canonical text per paper with retrieval chunks), and embedding (snowflake-arctic-embed-l-v2.0 in process, with a per-paper vector store).
• ⭐⭐ The assessment layer is the hardest part of this line: tiered study-quality assessment up to a Cochrane nine-domain risk of bias; PICO extraction whose every part is backed by the paper's own quoted passages; and transparency and bias analysis over five public APIs.
• ⭐ The LLM layer is more thorough than most: a unified client for Anthropic, OpenAI, Ollama, DeepSeek, Mistral, Gemini and OpenAI-compatible servers, with streaming, tool calling, reasoning traces, context-window handling, JSON repair and chunking.
• ⭐ Two languages that are a real port rather than a rewrite: the Python package bmlib and the Rust crate bmlib ship in the same release (0.12.0 / 0.3.0), and the Rust side adds UniFFI bindings for Swift and Kotlin mobile apps.
• ⭐ Infrastructure is handled too: citation formatting, a database layer over SQLite and PostgreSQL, prompt templates, and API keys in the OS keychain rather than in config files.

Why it matters

• ⭐⭐ "Every part of the PICO must be backed by the paper's own quoted passages" is precisely the hard constraint my evidence-based public-account content has been missing. When I write that a nutrient affects a marker, the AI hands me a neatly structured PICO — but the passage it quotes is often one my source never contained, and I put it in precisely because it looked well-formed. bmlib makes "every quote must be text from the paper" a code-level constraint: if the original passage cannot be located, the PICO does not exist. Applied to my pipeline: every AI extraction must carry the character span and sentence where it was located in the source, and without that it must not enter the report — the same line as assay's "a tool returning success is the provider's assertion, never proof" from the 11-08 issue, but with a more concrete implementation shape.
• ⭐⭐ The four-state retraction verdict (retracted / concern / clear / unchecked) is the layer of evidence work that most deserves to exist in my workflow and least does. I never check whether a paper I cite has been retracted — and a retracted paper cited by my public account shows no anomaly to the reader. bmlib makes this step an automatic field at ingestion, not an ad-hoc check before publishing. The "unchecked" tier is especially honest: it admits "I looked and found nothing", rather than defaulting to "fine".
• ⭐⭐ Making Cochrane nine-domain risk of bias a first-class library means something beyond medicine. The value of a nine-domain assessment is not that it yields a score; it is that it splits "how might this study be fooling me" into nine separately answerable questions. Applied to my GRPM reports and intervention plans: an SNP-to-phenotype association should have its own nine-item checklist (sample size, reproducibility, effect size, confounding control, publication bias, cross-ancestry consistency and so on), with each item marked assessed / not assessed / not applicable rather than collapsed into one overall verdict. This is the same thread as Calibrate's 2×2 dependency matrix and assay's refusal to output a single score from the 11-02 issue — but the nine domains are a list the medical community has already validated, and I should adopt it rather than invent my own matrix.
• ⭐ "Pinning the system prompts across the two languages" is a direct warning for my multi-model content pipeline. My public-account content runs on several models (WorkBuddy on this machine already has a single OpenRouter key covering the whole family), and the same prompt set drifts across models and versions. bmlib's answer is to pin the prompt text in code, and to say what a retry carries. That is the exact inverse of what I recorded on 11-07 — "an answer that is wrong and you do not react to looks like a clean run": a retry must leave a trace.
• ⭐ "Secrets live in the OS keychain, and the Python and Rust sides must resolve to the same entry" is a rule I can adopt directly. My 4P platform is Flask + SQLite and the GRPM report pipeline calls several model providers — API keys are currently scattered across environment variables and config files. "A credential accessed from several modules or languages must be one keychain entry, and another account's credential must be refused rather than overwritten" is a rule worth copying verbatim.
• ⭐ "Reasoning traces as a first-class output" is a capability I simply do not have today. Every model call I make keeps only the final answer and discards the intermediate reasoning — so when a conclusion goes wrong, I cannot tell whether retrieval, reasoning or citation was at fault. bmlib makes reasoning traces a retrievable artefact, which is enormously valuable for the review and compliance side of content production.
• ⚠️ The licensing is a hard wall: AGPL-3.0. I can read its design and copy its thinking, but I cannot make it a dependency of my own product unless that product is also AGPL. What should be carried over is the "structured evidence" specification, not the code — "every PICO part needs a source passage", "four retraction states" and "the nine-domain checklist" are specifications I can implement myself; bmlib's code is best read as a reference implementation.

3. ccch1mneyyy/dsh-Go: putting DeepSeek Harness in your pocket — it runs locally on the phone and can remote-control your computer, and it lets you talk over the agent mid-answer

URL: https://github.com/ccch1mneyyy/dsh-Go ｜ ★16,248 ｜ AGPL-3.0 ｜ Dart

What happened

310 commits inside the window (still running at 11-09 00:29Z to 11-09 02:23Z), making it one of the highest-activity projects in this issue; the thread is the 1.0.14 release. The README states the position in one line: "The Android client for DeepSeek Harness: run it directly on the phone, and remote-control the DSH on your computer." — run it locally on the phone and remote-control the DSH on your machine.

• ⭐⭐ "Interrupting mid-answer, with the process folded away automatically" is the interaction design worth watching this issue: you can talk over the agent while it is answering, and queued messages can be sent immediately; the process collapses into a single line when it finishes. Together these solve a very specific pain: once a long task starts, you can neither change the requirement nor see what happened in between. Being able to interrupt mid-run is the single most missing piece of agent interaction today.
• ⭐ "Runs locally, and can also remote-control the computer" is two forms rather than a choice: a built-in Linux environment, no root and no Termux; the DSH on your computer can also be switched to and continued. The README adds that it can switch with the official web version in one click, stay on the same conversation, and open on the same one next time.
• ⭐ Process visibility is implemented as a pet rather than a log panel: two desk companions (Deepy and the whale girl) type while working, celebrate when done, and raise a hand when they are waiting for your confirmation, and can follow you to the desktop via "show outside the app". The README's line — "it types while you work, does a flip when it is done, and raises a hand when it is waiting for you to confirm" — turns "waiting for user confirmation" into a visible signal. That is the same problem lights-out solved on 11-08 ("the last step always needs one human GO"), but with a lighter answer.
• ⭐ The commits show the engineering rhythm: the newest is Merge pull request #788 from ccch1mneyyy/release/1.0.14, preceded by docs(changelog): 1.0.14 ships with the whale companion and chore(release): 1.0.14; before that, phone: replay trace, main event end-gate and navigation materials (Pro 3435) and (Pro 3434) — "replay trace" means the phone can replay an execution trace, and the "event end-gate" is an explicit event-termination condition.
• ⭐ Distribution is compliant and unobstructed: APKs come from GitHub Releases or the official download page, arm64 for common phones; the README volunteers the destructive consequence up front: "If an earlier test build with a different signature is already installed, it cannot be overwritten in place — the old version must be uninstalled first; uninstalling clears the conversations, the Linux environment and the settings."
• ⭐ The README contains one frank admission about priorities: "The more Stars I get, the faster I get the ports done, hehe" — the author states outright that stars determine how fast the iOS and HarmonyOS ports arrive, laying the ordering out in the open.

Why it matters

• ⭐⭐ I have dsh (DeepSeek Harness v0.1.0-rc.6) on this machine, so this line is directly usable. I have treated it as a local native-agent development framework, but it only runs in a terminal — which means I have to be at the computer. dsh-Go turns that into "run it locally on the phone and remote-control the computer", which means I can dispatch a task to the home machine by typing one line from outside. Compare that with how I actually work today: when I think of something to change in the 4P platform on the spur of the moment, I have to wait until I am back at the desk — and in a one-person company that latency is a real cost.
• ⭐⭐ "You can interrupt mid-answer" deserves a note on its own. My entire interaction with coding agents today is turn-based: send one instruction, wait, read the result. The moment the direction changes while I am waiting, my only option is to let it finish and throw the work away. On a project with 310 commits, that is a dozen wasted minutes. "Queue plus send-now" turns turn-taking into an interruptible pipeline, and that interaction shape holds for any long-running agent — including the batch jobs in my 4P platform that run a full intervention plan end to end.
• ⭐⭐ "It raises a hand when it is waiting for you" is turning a blocking wait into perceivable idle time. My current problem is that the agent is waiting on a confirmation I cannot see, so I dare not walk away. A companion that raises a hand is a green light meaning "it is my turn now". The entertainment wrapper is incidental; what matters is the pattern underneath — mapping an agent's internal state to a signal that does not interrupt you but that you can read at a glance. For the rhythm of a one-person company, that is worth far more than the animation.
• ⭐ "Replay Trace" points at something I am doing but have not finished. Every intervention-plan generation in my platform records its inputs and outputs, but no execution trace — so "how did this conclusion arrive" cannot be reviewed afterwards. The phone already replays traces; my server side should have them first.
• ⭐ On licensing: AGPL-3.0 makes this the least directly reusable of this issue's highest-starred picks. It has 16k stars, extraordinary activity and exactly the shape I want, but AGPL means that if I ship it as part of my product, my product must be open source. The conclusion is clear: install it and use it (running locally and remote-controlling my own machine involve no distribution), but do not embed it in the 4P platform I intend to sell. Put the other way round, its design ideas — the interrupt queue, the state companion, trace replay, cross-form session continuity — all four can be implemented by me.
• ⭐ One more signal: the DSH ecosystem keeps appearing — besides this one and the FeatherHunter/dsh-mattpocock-skills-deck I recorded on 11-02, this issue brings sixtysevenlf/dsh-blender-plugin (DSH × Blender direct plugin, 15 model tools), omdsh-dev/dsh-mnemon (composable context layer for DeepSeek Harness) and FuRongJun-1999/dsh-memory (white-box AGI architecture). Four different teams shipped dsh extensions within the same month — dsh has become an agent runtime with a real ecosystem, and it is the one installed on my machine.

4. vostride/agent-qa: a QA agent that improves itself — it writes experience into reviewable files in your repository, and openly admits that "clean run rate" is a fundamentally flawed metric

URL: https://github.com/vostride/agent-qa ｜ ★847 ｜ FSL-1.1-ALv2 ｜ TypeScript

What happened

33 commits inside the window, a dense batch on 11-08, whose thread is a set of fixes numbered fix(467) covering agent and skill installation, uninstallation and configuration handling. The README's one-line positioning: "Your AI QA engineer, with memory. Describe a user journey in plain language. agent-qa tests it on web, Android or iOS and keeps the evidence."

• ⭐⭐ "Memory is not a black box in a database but reviewable files in your repository": memidex remembers facts and working procedures as reviewable files in your repository, so every piece of memory can be opened by a human, diffed in git, and reviewed in a pull request. The README also gives two mechanisms: self-improvement validates lessons learned from runs, retires stale knowledge, and uses your feedback to correct mistakes.
• ⭐⭐ It writes down the fundamental flaw in its own field: "Expect bugs" is one of the README's own notes. More telling is how it handles contributed knowledge — the demo has a separate Knowledge tab where you can see which knowledge a run actually retrieved, and trace each piece of knowledge back to the steps that used it.
• ⭐ The benchmark numbers are stated hard: #1 on AndroidWorld with 100% pass@1 (116/116 tasks); #1 on AppControlBench with 99.6% completion (114.5/115 points). The README explicitly notes that both used gpt-6-sol with memory and self-improvement switched off, and that AppControlBench gives half credit for partial completion. Benchmark, model, switches and scoring rule are all disclosed — which is itself a credibility signal.
• ⭐ Evidence is archived, not printed: in the demo, a deliberately planted bug — a cart showing $29 instead of $53 — is caught with the failed step and its screenshot side by side; the CLI output reports one test passed, one failed, and eight of nine steps passing.
• ⭐ The fix sequence in the window reveals what dirty work it handles: .mcp.json and .codex/config.toml must be read and written as carefully as AGENTS.md; removing agent-qa's .mcp.json entry keeps the person's comments; a reinstall names each edited file of a dropped skill that it removes; an empty folder that cannot be removed is named in a note, not reported as its file; an install with no agent writes no manifest, and uninstall removes one that lists no agent.

Why it matters

• ⭐⭐ "Experience is written as reviewable files in the repository" is exactly the missing link in my expert-package quality process when I batch-produce expert packages with WorkBuddy's expert-manager skill. My current review leans on the model grading itself — which is precisely the weakness hermes-fledge addressed on 11-06 ("take the scoring away from the model"). agent-qa's answer is plainer and more reliable: memory is files in the repository, so it is naturally diffable, reviewable and blameable. Applied to my own work: the quality record of an expert package — which prompt variants passed, which were rejected, and on what grounds — should be a set of files in the repo, not a paragraph inside a model output.
• ⭐⭐ "Validating lessons from runs and retiring stale knowledge" maps directly onto the riskiest part of my expert-package iteration. I recorded on 11-04 that changing one line of a description took Kimi's pass rate from 78% to 98% — but that also means stale lessons keep living in the package, with nobody knowing they should retire. "Retire stale knowledge" should become a fixed step in publishing an expert package: every lesson carries a last-verified timestamp, and anything past its threshold is automatically demoted to pending review.
• ⭐⭐ "Tracing knowledge back to the steps that used it" is the hard metric of evaluation quality. What I do today is look at a pass rate — but the 11-07 issue's navigator already identified the fundamental flaw in that metric: an answer that is wrong and you do not react to looks like a clean run. agent-qa's answer is to make "why this knowledge was applied" a fact you can click open. Applied to my platform: every rule written into an intervention report must be able to answer "on what grounds was it applied this time".
• ⭐ "Disclosing the benchmark, the model, the switches and the scoring rule" applies directly to my content production. When I cite "some benchmark score" in an article, I never say what configuration produced it. agent-qa's README states: which model was used, whether memory was on, whether self-improvement was on, and whether partial completion earns half credit — all four, every time. That should become the fixed four-part kit whenever I quote an evaluation result.
• ⭐⭐ The batch of fix(467) commits is, in theme, almost entirely about "do not lose the person's things": removing the .mcp.json entry keeps the user's comments; a reinstall lists every edited file it removes; an install with no agent writes no manifest. This is the same line as the "read-back verification" I recorded on 11-07, but from a different angle — read-back verification governs whether what you wrote is correct; this batch governs whether you destroyed anything of someone else's while doing it. My 4P platform needs the same three-part kit when it changes plans, baselines or user records: back up first, then change, then produce a list.
• ⚠️ Licensing is FSL-1.1-ALv2, not MIT. The Functional Source License allows use, modification and self-hosting, but requires conversion to Apache-2.0 (the ALv2 additional licence) once you provide the software as a service at a certain scale. For a one-person company that sits between AGPL and MIT — if it becomes a product, the conversion terms must be checked before launch.

5. trailhq/Trail-Code: one shared "map of the code plus what the team has learned" for every coding agent — 46% fewer tool calls across 162 runs, and SWE-bench Verified up from 54% to 66%

URL: https://github.com/trailhq/Trail-Code ｜ ★11,150 ｜ MIT ｜ TypeScript

What happened

14 commits inside the window (11-08 11:05Z to 11-08 12:02Z), whose thread is making Trail work in Claude Desktop and Codex as well, and giving the "what the team has learned" layer some substance. The README's one-liner: "The self-learning context layer for coding agents." (Previously called graft; the code-map portion keeps the graft name and every graft command still works.)

• ⭐⭐ The quantified result is the hardest set of numbers I have seen since 11-08: across 162 runs, tool calls down 46%, uncached input tokens down 42%, time down 60%; on 50 real SWE-bench Verified issues, the baseline solved 27 (54%) and the code map solved 33 (66%). The README closes with the direct comparison: "One graph, every agent, up to 4x tokens saved."
• ⭐ "The code map" and "what the team has learned" are explicitly two separate layers: the former is a code index (every function and who calls it, so the agent can see what a change would break), the latter is what you, your agents and your team have learned and decided. The former comes from "your code, read on your machine"; the latter from "your conversations, as you work".
• ⭐⭐ "Flagging a learning that names code which is gone" is the key move of this issue's commits: Flag learnings that name code that's gone (#731) — if a team lesson points at code that no longer exists, the lesson is flagged. This is the plainest and most effective handling of stale knowledge: it does not delete it, it makes it visible.
• ⭐⭐ "Telling you who made a decision before you change the code" is its most distinctive feature: the README's comparison table says that without Trail "the agent undoes a teammate's decision, because it never knew that decision existed", while with it trail check flags it before the PR, quoting who decided it and why. A second entry covers the case where the agent says right after editing that a teammate's open branch changed the same code, and whether the two clash.
• ⭐ Another commit worth noting: Let one developer use trail just for themselves (#750) — letting one person use Trail just for themselves, without imposing it on the team. That is an honest product decision: collaboration layers become drag when a team has no shared consensus.
• ⭐ The integration surface is widening: Make trail work in Claude Desktop and Codex (#733) in this window shows it serves coding agents beyond the terminal.

Why it matters

• ⭐⭐ "SWE-bench Verified from 54% to 66%" is the most convincing evidence about a context layer I have seen in two years. The comparable projects I recorded — skill-diet's token cuts, sprag's 72.6% bill reduction — all optimise cost, and only this one gives cost (tool calls −46%, tokens −42%, time −60%) and outcome (+12 points of pass rate) together. Cases where cost and quality improve together are rare — they show that giving an agent better context is not trading quality for money but winning on both.
• ⭐⭐ "A learning that points at code which no longer exists gets flagged" can become a fixed health check on my expert packages and prompts. My prompt library already contains entries that reference specific code paths or specific fields — and when the code changes, those entries silently stop working, with no one telling me. The corresponding action: before an expert package or prompt template is used, run a reference-validity check that flags entries pointing at things that no longer exist. The cost is near zero (a grep, or a schema validation), and it blocks an entire class of failures that "look like they are working but have been running off the rails for a long time".
• ⭐⭐ "Quoting who decided it and why" is exactly the thing my platform does not have. When my intervention report is written to the database it records "conclusion + basis", but not "who set this basis and what the reasoning was at the time" — so whoever changes the rule later cannot know why the old rule existed and can only override it or route around it. Git blame is the code world's answer, and my platform needs the same thing.
• ⭐⭐ "Telling me that another branch changed the same place right after it edited the code" applies to me even though I work alone. My "no teammates" status does not mean I have no concurrency: the 4P platform, the GLP-1 nutrition companion, the GRPM reports and the public-account content library all share some underlying conventions (ingredient dictionaries, marker definitions, report templates). A warning, delivered before a change lands, that another project is touching the same area should become a fixed check across my four projects.
• ⭐⭐ "Letting one person use Trail just for themselves" fits my situation exactly. I have previously recorded risks like "any npm package may carry a suspicious postinstall script" and "installing something means executing third-party code". Trail offers the right posture: use it for yourself first, and do not push it onto a team that does not exist yet.
• ⭐ MIT licensed, readable, modifiable and commercially usable — in contrast to vostride/agent-qa's FSL-1.1-ALv2 and ccch1mneyyy/dsh-Go's AGPL-3.0, Trail-Code has the cleanest licence of this issue's three agent-infrastructure picks. The shape "self-learning context layer" is one I can safely start building on under MIT.

2. Category roundup

① AI Coding / coding agents and the skill ecosystem

② Medical and clinical research AI and agent skill libraries

③ Health management, nutrition and food AI

④ Model foundations and agent infrastructure

3. Trends today

The clearest thread in this issue is that AI-generated artefacts are now systematically required to substantiate themselves — and this time the requirement reached three different layers: the conditions under which evidence holds, the replayability of execution, and the traceability of change. mTOR Atlas requires every claim to carry its measurement conditions and its failure boundary, and grades research by the type of conclusion the evidence can support rather than by quality; bmlib requires every PICO part to be backed by the paper's own quoted passages and turns retraction status into a four-state field; agent-qa stores knowledge as diffable files in the repository and keeps evidence for every run; Trail-Code flags learnings that point at code which no longer exists. Four teams from four different technology stacks, on the same day, independently did the same thing: make "what the AI said" and "what the AI did" both reviewable by a third party. This is the third stage of the same thread I recorded with assay (evidence packages recomputable offline) and lights-out (eight gates) on 11-08: the first two issues pushed the requirement down into the runtime; this issue pushes it down into the structure of the evidence itself.

The second thread, and the one that stings most for me, is that two projects this issue treat knowledge as something that rots — and both ship a concrete decay detector. agent-qa explicitly says it validates lessons from runs and retires stale knowledge; Trail-Code explicitly has a commit that flags learnings naming code that has gone. Two independent paths to the same judgement: knowledge without an expiry marker will eventually lie. And my current situation is precisely "knowledge only grows": my public-account article archive, GRPM's SNP judgement rules, the 4P platform's intervention-plan templates and the prompts inside my expert packages all keep expanding, and not one has ever been marked as expired. The single thing to do first is this: give every rule entering my content and report pipeline two fields — a last-verified time and whether what it points at still exists — and let a weekly task pick out the failures.

The third thread: this issue produced a licensing sample worth watching closely — using licence terms to express a business model. mTOR Atlas licences data CC BY 4.0 and code MIT, on the reasoning that the data should be citable and re-workable while the code only needs to be auditable; novu licences everything outside enterprise/packages as MIT and the rest under its own proprietary terms, using a directory boundary to draw the line between the open-source and commercial editions. Neither is "picked a licence at random" — both write "who I want to be able to use this, and how" into the licence structure. For a one-person company this suggests something very practical: my public-account content library can go CC BY 4.0 (attribution is enough for it to spread), while the 4P platform's code should stay closed-source and commercial — the same content, two sets of terms, declared separately. Of this issue's 121 entries, MIT and Apache-2.0 account for 93 (77%), but there are still AGPL-3.0 (9), GPL-3.0 (5), one PolyForm Strict (research and non-commercial only), one FSL-1.1-ALv2 (commercial use needs a separate agreement) and 4 undeclared — this list belongs on the first line of any foundation-selection document, and it should be read before the work starts, not after.

The fourth thread, a note to myself: the most valuable thing in this issue is not any single project but three assertions I can act on tonight. First, mTOR Atlas's "grade evidence by study design, not by quality" and its self-criticism that "a lettered ladder reads like a quality grade" — this directly shows that the "evidence strength A/B/C" label scheme I designed for my articles is graded on the wrong axis, and it should be re-cut as a type axis (cell / animal / observational human / randomised trial / systematic review) rather than a strength axis. Second, bmlib's three rules — "every PICO part needs a source passage", "four retraction states", "Cochrane nine domains" — are the ruler my GRPM reports and evidence-based articles are missing, and the medical community has already standardised it, so I should not invent my own. Third, agent-qa's "knowledge as reviewable files in the repository" and Trail-Code's "flag learnings that point at code which is gone" — together these are what my expert-package review process should look like: not asking the model to grade itself, but making every lesson a diffable, blameable record in the repo that can be marked expired. Concretely, four things to do: ① replace strength labels with evidence-type labels; ② attach the source span to every extraction; ③ give every rule a "last-verified time + does its target still exist" pair of fields; ④ run a weekly expiry scan. None of the four needs a new framework — four fields and a scheduled task.

4. Repo index

https://github.com/Yeachan-Heo/oh-my-claudecode
https://github.com/slopus/happy
https://github.com/manaflow-ai/cmux
https://github.com/Yeachan-Heo/oh-my-codex
https://github.com/ccch1mneyyy/dsh-Go
https://github.com/PDFMathTranslate/PDFMathTranslate
https://github.com/YishenTu/claudian
https://github.com/gastownhall/beads
https://github.com/github/gh-aw
https://github.com/unoplatform/uno
https://github.com/yamadashy/repomix
https://github.com/KKKKhazix/AIHOT
https://github.com/h4ckf0r0day/obscura
https://github.com/vitali87/code-graph-rag
https://github.com/trailhq/Trail-Code
https://github.com/heydamir/unslop
https://github.com/emcie-co/parlant
https://github.com/stanfordnlp/dspy
https://github.com/udecode/plate
https://github.com/SenteLabsAI/OpenExecutive
https://github.com/phuryn/pm-skills
https://github.com/EveryInc/compound-engineering-plugin
https://github.com/leejet/stable-diffusion.cpp
https://github.com/wshobson/agents
https://github.com/AlexsJones/llmfit
https://github.com/browser-use/browser-harness
https://github.com/steipete/CodexBar
https://github.com/KKKKhazix/khazix-skills
https://github.com/Orkas-AI/Orkas
https://github.com/max-sixty/worktrunk
https://github.com/Kuddev/pebrel
https://github.com/IvanMurzak/Unity-MCP
https://github.com/compozy/compozy
https://github.com/sixtysevenlf/dsh-blender-plugin
https://github.com/the-open-engine/zeroshot
https://github.com/andyrewlee/awesome-agent-orchestrators
https://github.com/daymade/claude-code-skills
https://github.com/oceanbase/powercontext
https://github.com/AI-in-Health/MedLLMsPracticalGuide
https://github.com/general-molecular-simulations/so3lr
https://github.com/BRAINSia/BRAINSTools
https://github.com/yakew7/Fair-Code
https://github.com/yorkeccak/bio
https://github.com/WeixiangYAN/ClinicalLab
https://github.com/anthony-maio/mnemos
https://github.com/dentalpin/dentalpin
https://github.com/mlp6/Embedded-Medical-Devices
https://github.com/gaofeng21cn/med-autoscience
https://github.com/evangauer/openvpm
https://github.com/burlakovmb/NOWA-Bio-Inspired-AI
https://github.com/baeseongsu/awesome-machine-learning-for-healthcare
https://github.com/forever-healthy/AI4L
https://github.com/Opening-Science/twin-llm
https://github.com/lexthirteen-ai/orinyx-mcp
https://github.com/HeartWise-AI/ai-writing-skills
https://github.com/hherb/bmlib
https://github.com/chengwang96/Awesome-World-Models-for-Healthcare
https://github.com/ali-119/LatentHealth
https://github.com/Sahil-Bulbule/CANCER-PREDICTOR
https://github.com/pjerra/tortoise-trials
https://github.com/drexthealpha/Knos
https://github.com/FerroHEALTH/FerroTERM
https://github.com/FerroHEALTH/FerroBRIDGE
https://github.com/JunjieCao-tech/meta-analysis-of-large-language-models-for-diagnostic-cancer-imaging
https://github.com/unibio-intelligence/biomedmcp
https://github.com/OraFabric/medical-ontology-mcp-examples
https://github.com/lewpgs/migros-mcp
https://github.com/mona-hrt/mona
https://github.com/hms-homelab/hms-cpap
https://github.com/wanshuiyin/SuperARIS
https://github.com/AnuragRoy485/hazir
https://github.com/stethoscope-js/stethoscope
https://github.com/JellyPlugins/jellyfin-helper
https://github.com/xuzerui6/MoveMate
https://github.com/galihru/facemind
https://github.com/blopa/musclog-app
https://github.com/galihru/MentalHealth
https://github.com/patrickhaahr/openhome
https://github.com/fatheus97/mealbot
https://github.com/JamesNolan17/healthy-wealthy
https://github.com/david-dabert/workout-vision
https://github.com/ai-cfia/nachet
https://github.com/MrF1ow/foodable
https://github.com/botkin-health/Botkin
https://github.com/open-mtor-atlas/atlas
https://github.com/ching-0405/DietlPlanner
https://github.com/garrytan/gbrain
https://github.com/anomalyco/models.dev
https://github.com/openobserve/openobserve
https://github.com/decolua/9router
https://github.com/cocoindex-io/cocoindex
https://github.com/AstrBotDevs/AstrBot
https://github.com/xberg-io/xberg
https://github.com/mlflow/mlflow
https://github.com/novuhq/novu
https://github.com/ray-project/ray
https://github.com/pipeshub-ai/pipeshub-ai
https://github.com/labring/FastGPT
https://github.com/agno-agi/agno
https://github.com/crmne/ruby_llm
https://github.com/magnitudedev/magnitude
https://github.com/run-llama/llama_index
https://github.com/eosphoros-ai/DB-GPT
https://github.com/microsoft/onnxruntime
https://github.com/ruvnet/RuVector
https://github.com/dagucloud/dagu
https://github.com/xorbitsai/inference
https://github.com/pytorch/torchtitan
https://github.com/bytechefhq/bytechef
https://github.com/leemysw/yovoice
https://github.com/IncarnaMind/IncarnaMind
https://github.com/jesdga95/basalt
https://github.com/dsx-ai-factory/run-ai
https://github.com/vostride/agent-qa
https://github.com/FuRongJun-1999/dsh-memory
https://github.com/omdsh-dev/dsh-mnemon
https://github.com/code-yeongyu/lazycodex
https://github.com/polyaxon/polyaxon
https://github.com/vshulcz/deja-vu
https://github.com/AVIDS2/memorix
https://github.com/kitfunso/hippo-memory