GitHub AI Daily · 2026-10-22 (Thursday)

1. Today's picks (5)

1. git-ai — an open replication of Anthropic's internal Scion, "source control redesigned for agents"

Repo: https://github.com/feder-cr/git-ai ｜ ★916 ｜ Go ｜ created 10-15, still committing today

What happened
The author built an open implementation of Scion — the internal Anthropic version-control system described in the engineering post Redesigning source control, designed for "hundreds of agents reading and writing code at the same time" and never released. It diverges from Git in four places: clients stay online and fetch single objects and sparse trees on demand (graft clone / graft sparse); history queries are answered server-side and cached; changes land through compare-and-swap rather than a merge queue; every update is appended to a changeset log, with repository state kept in a consistent database plus object storage so it scales horizontally. Underneath it is still a standard Git repo, MIT licensed, and the server calls no models — the AI capability is vendor-neutral.

Today's commits are the PLAN10 series: reproducing the G1 metric on 296 freshly constructed Go conflicts, adding "with tests / without tests" control arms and Python plus TypeScript arms (TypeScript prepared, not yet run), together with a build check and SEM/BIND measurements.

Why it matters

• This is the first time "agent-native VCS" moves from a paper-style description to runnable code. With agents working in parallel the real bottleneck is not the model but Git's assumption — "a human clones once, works for hours, pushes once". Put fifty agents on the same branch and the merge queue collapses.
• It publishes how the benchmark was built (296 self-constructed conflicts plus control arms), which is far more credible than "we are N times faster", and it hands you a template for evaluating agent-collaboration infrastructure.
• Practical takeaway: if a team is moving to parallel agents, there is now a self-hostable reference; even without adopting it, "changeset log + CAS landing + every change attributed to a specific agent" can be lifted straight into an internal pipeline.

2. Tencent Hunyuan Hy-Memory — coding memory turned into a standalone dual-system cognitive engine (MemHub connects five coding tools)

Repo: https://github.com/Tencent-Hunyuan/Hy-Memory ｜ ★1,127 ｜ Python ｜ Apache-2.0

What happened
Hunyuan open-sourced a "production-grade dual-system cognitive memory engine" plus the Python SDK hy-memory, with three specialised memory pipelines: Chat uses layered long-term cognitive memory; Working uses a two-layer "facts + reusable experience" design; Coding tracks code evolution with a versioned diff-chain. It shipped 2.0.5.dev3 today and merged a run of SDK capabilities — semantic memory import, retrieving raw records through the existing search API, handling existing raw records (that PR was later reverted, a sign the interface is still converging).

The companion MemHub is a local-first desktop app plus CLI that funnels conversation history and coding traces from Claude Code, Cursor, Codex, OpenCode and Qwen Code, with user authorisation, into one governed local runtime and data directory — cross-application memory recall. On the model side it released FP8 and GGUF quantisations of Hy-Memory-30B-A3B.

Why it matters

• Memory used to be "a plugin bolted onto one harness" (see ai-memory in the 10-20 issue). Now a model vendor treats memory as its own product and its own model, and points it at the messiest data shape there is: coding traces. A diff-chain records how code evolved step by step instead of stuffing chat logs into a vector store.
• MemHub's positioning is the interesting part: it does not bind to one IDE but acts as a cross-harness memory middleware. Memory may follow the path LSP took — from everyone building their own to one shared layer.
• Directly relevant to medical and health products: a patient record, a follow-up history, a diet log are all diff-chain problems underneath (how did the metric move, why did the plan change), so the modelling approach transfers.

3. HasteHealth — an open-source FHIR server for AI-native health apps, with MCP and SMART on FHIR built in

Repo: https://github.com/HasteHealth/HasteHealth ｜ ★84 ｜ Rust ｜ Apache-2.0

What happened
One sentence: Epic / Oracle Health / HL7v2 in, FHIR R4, SQL-on-FHIR and MCP out. Clinical data is stored as FHIR R4 and served through a single API to front-end apps, analytics jobs and AI agents alike; OAuth2, SMART on FHIR and MCP are all built in. Written in Rust, self-hostable, with a BAA-backed hosted option. A single binary runs as server, worker or CLI, and docker compose up brings up the full stack (Postgres + server + worker + admin frontend).

Today's commits fill in FHIR query semantics: ne/eq for quantity, the lt/gt/le/ge prefixes, the eq prefix for Number, :missing modifiers across Token, Date, Reference and Quantity, and the FHIRPath toQuantity / convertsToQuantity functions.

Why it matters

• Earlier issues covered medical projects at the "skill library / guardrail / imaging agent" level. This one moves the bottom-most data layer, letting an agent speak FHIR directly over MCP instead of gluing REST by hand. Built-in MCP means clients like Claude or Cursor connect to hospital data with zero adaptation.
• The engineering trade-offs are worth copying: Rust, single binary, static linking, explicitly aimed at the reality that "hospital intranets cannot casually install Node or Python"; and compliance (BAA, SMART authorisation) treated as a product feature rather than a documentation appendix.
• The flip side: everything added today is FHIR Search edge semantics — which shows how far it still is from replacing a mature FHIR server. When evaluating, watch _include, _revinclude, versioning and bulk export.

4. ai-mammogram-triage — mammogram triage as an MCP service, with calibration numbers published honestly

Repo: https://github.com/avalderrama/ai-mammogram-triage ｜ ★1 (new, created 10-20) ｜ Python ｜ Apache-2.0

What happened
An MCP server that takes CC/MLO mammogram views and sorts each breast into BI-RADS 1-2 / 3 / 4-5 with a priority (high_priority / review / no_suspicious_findings). The pipeline: OCR-mask identifying text on the image (read text is neither returned nor logged) → verify it really is a mammogram and not ultrasound, MRI or a phone snapshot → classify with a global model at 512 and 1024, and when image height is ≥1500px add a 2048 patch model (more sensitive to calcification) producing heatmaps and up to three suspicious regions → merge same-side views only when the client explicitly passes sides → apply calibrated thresholds. Images are never persisted.

On the held-out half of the official VinDr-Mammo test split — the half not used for calibration — measured per breast: 87% of BI-RADS 4-5 cases land in high_priority or review, while only 6.5% of BI-RADS 1-2 cases are upgraded to high_priority; AUC 0.89; 1-3 seconds per image on CPU.

Today's commits: view-separator detection at arbitrary resolution, on-demand two-tier heatmaps, and automatic deployment of main behind a Cloudflare tunnel.

Why it matters

• It demonstrates the compliance posture for a medical imaging agent: de-identify before inference, verify modality before classifying, store nothing, and state plainly "research tool, not a medical device, not clinically validated". Those choices decide whether a project can enter a hospital far more than model accuracy does.
• The reporting convention is worth learning: metrics are per breast rather than per image, the calibration set and the held-out half are explicitly separated, and the 6.5% false-upgrade cost is written out. In medical AI, a good recall number is easy; publishing the price of it is what makes it credible.
• For our own work: this is a complete example of packaging specialty judgement as a tool an agent can call — input validation, a refusal path, and structured output kept separate from the natural-language summary (structuredContent is always English).

5. Two new routes in nutrition — vendor-official Agent Skills versus specialty measurement depth

Repos: https://github.com/edamam-llc/edamam-skills (★0, pushed since 10-16) ｜ https://github.com/ksullivan86/kidney-health (★1, committed today)

What happened

• edamam-skills: Edamam, a nutrition/food database vendor, packaged its capability as portable Agent Skills following the agentskills.io open standard. The same skills/ directory is simultaneously a Claude Code plugin marketplace and a Gemini CLI extension, with data served through its hosted MCP (mcp.edamam.com/mcp/food). The first skill is barcode lookup: enter or photograph a UPC/EAN and get calories, macros and the full nutrition panel. Credentials are written once into the local environment and never enter the conversation.
• kidney-health: a self-hosted diet log plus patient handbook aimed at chronic kidney disease with type 1 diabetes — measuring six dimensions (potassium, phosphorus, sodium, protein, fluid, carbohydrate), with meal plans, barcode scanning and an offline PWA. Still committing today.

Why it matters

• These two routes map exactly onto the fork nutrition products face: one is "the data vendor turns itself into a skill" — no app, it lives inside the user's agent and bills per API call; the other is "specialty measurement beyond generic nutrients" — potassium, phosphorus, fluid are blind spots for generic calorie apps, and they happen to be what CKD patients actually count every day.
• Be sceptical about the signal strength of the first route: edamam-skills has 0 stars and no substantive commits on main recently (the latest being a privacy-policy change on 10-16) — closer to a placeholder listing than a validated distribution channel. When judging vendor-official skills, separate "listed" from "actually installed".
• Business implication: in nutrition and health management, generic nutrient tables are a red ocean; specialty measurement (kidney, diabetes, pregnancy, oncology nutrition) is the moat. On distribution, plan for "being called by an agent" as a new entry point, not just shipping an app.

2. Category roundup

A. AI coding / coding agents & skill ecosystem (8)

Status notes (already covered, not expanded): stablyai/orca (★101k, still top of Trending), headroomlabs-ai/headroom, akitaonrails/ai-memory, cloudflare/security-audit-skill, DietrichGebert/ponytail are all still on Trending with no substantive new capability today.

B. Medical / clinical research AI & scientific agents (7)

C. Health management / nutrition & food AI (7)

D. Model stack & agent infrastructure (6)

3. Trends today

1. The bottleneck has moved from the model to the collaboration protocol. The three hottest AI coding projects today — git-ai (source control), reason-network (agent-to-agent messaging), kandev/harp (observability and scheduling for dozens of sessions) — none of them is a model. All three solve "when many agents work at once, how does the human not drown and how does the code not collide". That is a clear shift from "a stronger single agent" to "an operating system for agent teams".
2. Memory is splitting into three layers: engine, model, middleware. Hy-Memory ships an engine (SDK), a model (30B-A3B in FP8/GGUF) and middleware (MemHub across five coding tools); MemT-1.0 pushes memory into the base model itself (66× less KV storage). Last issue it was "a plugin for a harness"; this issue it is "memory as independent infrastructure".
3. The competitive front in medical AI has dropped to the data-semantics layer. Everything HasteHealth added today is FHIR Search quantity prefixes, :missing modifiers and FHIRPath functions — dull edge semantics that decide whether an agent can actually retrieve the right lab value. Meanwhile the marginal value of "yet another medical Q&A bot" is falling fast.
4. Compliance is a code path, not a document. ai-mammogram-triage writes "de-identify first, verify modality first, never store the image, keep a refusal path" into the pipeline; Medical-Harness forbids inventing sources when retrieval fails. This kind of hard-coded self-restraint is becoming the entry ticket for medical and health projects, far more effective than a disclaimer in the README.
5. Separate "vendor-official skill listed" from "actually installed". Edamam's move is directionally right, but 0 stars and no substantive recent commits on main make it look like a placeholder. When choosing, look at install counts, issue activity and commit history — not at "supports Claude Code".
6. Domestic compute is entering the default list of open-source inference stacks. DeepInfer lists Huawei Ascend 950 next to NVIDIA SM100 as supported hardware, a rare statement six months ago.

4. Repo index

Picks

• git-ai — https://github.com/feder-cr/git-ai
• Hy-Memory — https://github.com/Tencent-Hunyuan/Hy-Memory
• HasteHealth — https://github.com/HasteHealth/HasteHealth
• ai-mammogram-triage — https://github.com/avalderrama/ai-mammogram-triage
• edamam-skills — https://github.com/edamam-llc/edamam-skills
• kidney-health — https://github.com/ksullivan86/kidney-health

AI coding

• https://github.com/kdlbs/kandev
• https://github.com/reason-machines/reason-network
• https://github.com/dominikmartn/harp
• https://github.com/LinklyAI/best-skills
• https://github.com/aicodeking/leanrea
• https://github.com/SrIruma/repoctx

Medical / research

• https://github.com/ompathak2004/Medical-Harness
• https://github.com/MIRA-Intelligence/mira
• https://github.com/aipoch/open-science
• https://github.com/EvidenceMD-INC/evidencemd-mcp
• https://github.com/carlos-emr/carlos

Health / nutrition

• https://github.com/Townzc/liftcut-tracker
• https://github.com/itspaulai/vitapulse
• https://github.com/SatoSakula/MoveBench
• https://github.com/nopara73/LongevityWorldCup
• https://github.com/nutrifit-health/nutrifit-widgets

Stack / infrastructure

• https://github.com/deepseek-ai/DeepInfer
• https://github.com/eagle-hq/EAGLE-4
• https://github.com/NVIDIA/flare-local-inference
• https://github.com/MemTensor/MemT-1.0
• https://github.com/openai/php2shell-checker

27 projects across the four categories this issue (open-science counted in both B and D), all de-duplicated against earlier issues. Stars and commit times as of 2026-10-22 09:00 UTC+8.