GitHub AI Daily · 2026-10-28 (Wednesday)

1. Today's picks (5)

1. TencentCloudBase/CloudBase-AI-Toolkit: Tencent turns "cloud development backend" into a plugin, skill and MCP triple-decker for AI coding agents

URL: https://github.com/TencentCloudBase/CloudBase-AI-Toolkit ｜ ★1,152 ｜ MIT ｜ TypeScript — official Tencent Cloud CloudBase release providing cloud development backend capabilities to Claude Code / Cursor / CodeBuddy / DeepSeek Harness / OpenCode / Codex CLI agents

What happened

A project that only three days ago shifted its focus from documentation to runtime protection, and today's commits are all about writing safety and consistency into the agent's everyday operating path.

• All four of today's (10-28) commits are "error-prevention" in nature: syncing upstream cloudbase plugin skills, generating the cloudbase-intl connector package, docs(skills): 虚拟支付补入站通知验真与退款判定 (writing inbound-payment verification and refund adjudication for virtual payments into the skill documentation), and fix(mcp): 环境候选补齐 platform 类型，平台代建环境不再消失 (filling in the platform type for environment candidates so platform-provisioned environments stop vanishing).
• Supply-chain security moved from "guideline" to "executable policy": chore(supply-chain): fold npm security guide into AGENTS.md and drop specs exception folds the npm security guide into the agent instruction file and drops the exception carve-out; the same day adds a security policy, a vulnerability reporting form, and a "narrow the reporting channels" doc.
• The MCP service is production-grade in scale: 38 MCP tools with 482 passing cases in the full tool suite; the hosted remote connector uses Streamable HTTP + OAuth and has been submitted for platform review; tool descriptions and runtime messages support zh/en bilingual output.
• Capability coverage spans the whole backend chain: cloud development environment creation and switching, PostgreSQL/NoSQL queries and DDL, RLS policy inspection and editing, cloud storage read/write, cloud function and cloud hosting deployment, static hosting release, and controlled Tencent Cloud API invocation (service whitelist expanded to 57 products).

Why it matters

• This one lands directly on two things I am already doing. First, the backend for the WeChat mini program I am pushing is already on the CloudBase route (the cloudbase skill already carries web-development / postgresql / cloud-functions / auth-web / cloud-storage), and second, my local dsh (DeepSeek Harness) agent is running too. This repository refreshed all of dsh-plugin's skill sync paths, .cursor/rules, .claude-plugin, .codebuddy/skills in the same breath — it effectively shows me how a multi-agent ecosystem is laid out by someone else, which is far faster than reverse-engineering it myself.
• The significance of "虚拟支付补入站通知验真与退款判定" far exceeds the commit itself. In my GLP-1 Nutrition Companion V2, the "medication and discontinuation cascade adjudication" is exactly the kind of step that must be decided by deterministic rules rather than left to a model improvising. They wrote this into the skill documentation and paired it with MCP tooling, which means this path has already run in someone else's production environment — I can compare how they define the boundary instead of inventing it myself.
• "平台代建环境不再消失" is a lesson about agent memory. The environment candidate list was missing the platform type, so agents would drop platform-provisioned environments from the candidates and users would think the environment did not exist. I hit the same class of bug in version management of intervention reports on the 4P precision nutrition platform. Seeing how someone else patched that field is faster than debugging it myself.
• It also set a standard: new relational databases should prefer PostgreSQL, and the MySQL skill is retained only for existing environments. That is a ready-made decision input for my cloud storage choices.

2. itsoso/health-llm-driven: The Chinese-language community ships a real product for the "personal health OS" — digital health twin, safety guardian, action ranking, intervention cycle

URL: https://github.com/itsoso/health-llm-driven ｜ ★3 ｜ undeclared ｜ Python / FastAPI + Swift + Expo — an LLM-driven personal health management and execution system ("复元 Reva · Personal Health OS")

What happened

Only three stars, but this is the most complete open-source personal health management system I have seen in terms of product structure, and it is built by a Chinese team for people aged 35–55 with high work intensity and early metabolic risk — essentially my own target user.

• The product loop is stated explicitly: checkup / wearables / symptoms / medication / supplements / behavior records → digital health twin (organize personal state and evidence) → safety check → action ranking → health schedule (assisted on Mobile / Watch / Mac) → execution records → review of results and trends → next round of actions. The long-term goal is a traceable "ledger of actions and outcomes": what was advised, what was actually executed, which results were verified, and what the limits of the evidence are.
• The safety guardian is a standalone agent, not a sentence in a prompt: it applies rule checks to vital signs, lab values, medication and supplement interactions, pharmacogenomics, blood glucose, symptoms, and training load; health-schedule ranking explicitly scores on five dimensions — executability, verifiability, confidence, execution cost, and safety level.
• All of today's (10-28) commits center on "publishing trustworthiness": docs(chat): record photo-reference safety review and release blockers (recording photo-reference safety review and release blockers), fix(chat): clarify supplement photo references and adopt guardian icon (clarifying supplement photo references and adopting the guardian icon), docs(release): record verified guardian icon and supplement delivery (recording the verified guardian icon and supplement delivery), fix(ota): preserve Store 282 native branding boundary, fix(release): bind completed credential and preserve recovery cwd.
• Technical foundation: backend FastAPI + PostgreSQL + Redis + Celery, agent execution on the official Pi runtime (Node.js) with Python handling model transport and health tool execution; Mobile on Expo/React Native, Watch and Mac on native Swift, plus a Next.js web app and an mcp-server/ directory.
• The boundaries are stated with restraint: no prescriptions, no autonomous dose adjustment, model answers never substitute for diagnosis, explicit uncertainty when evidence is weak, and high-risk paths routed through safety rules + human review + clinical follow-up; trend changes must be interpreted together with noise and missing data and cannot be treated as proof of causation.

Why it matters

• Its four-part structure maps almost one-to-one onto my GLP-1 Nutrition Companion V2 modules. I split mine into "ingredient templates + 15 functional targets + morning/evening dual-cup plans + Mazdutide medication/discontinuation cascade + lab indicator trend tracking"; it splits into "health twin + safety guardian + action ranking + intervention cycle". But it has two things I do not: execution cost and safety level as ranking dimensions, and a traceable ledger of actions and outcomes. That second one is exactly what I mean by "persist every interaction to support self-evolving learning" — it simply gives the idea a more engineering-grade name.
• On "supplement photo references", it has already stepped on the same landmines as I have. In a supplement intervention report, the riskiest chain by far is "user uploads a product photo → system identifies the ingredients → generates a dosage recommendation". It treats photo-reference safety review as a release blocker on its own and adds a "guardian icon" anti-misleading design for supplement delivery. In effect it has walked the path for me first.
• The line "cannot be treated as proof of causation" is worth more than any feature. All of my health content must carry evidence. If my system ever says "your markers improved because you took X", that is a different form of hallucination. It put that sentence in the product objectives rather than in an FAQ.
• The fact that it is "Chinese + mobile-first + multi-end" matters more than its three stars. What my one-person-company MVP lacks most is not algorithms but the multi-end + backend + data model skeleton — it lays out FastAPI + Postgres + Celery + Expo + Swift + Next.js + an MCP server in the open.

3. craft-b/formula-forge: A clinical nutrition formulation agent draws a hard boundary — the model may only propose structure, all nutrition numbers are recomputed by the deterministic layer

URL: https://github.com/craft-b/formula-forge ｜ ★0 ｜ MIT ｜ Python / FastAPI + LangGraph + Groq — a food formulation design system for clinical and institutional nutrition settings (renal, diabetes, high-protein, low-fat, vegan)

What happened

A brand-new project with zero stars, yet it draws the engineering boundary around "AI-generated nutrition plans" more clearly than most commercial products.

• The trust boundary is a single function: _resolve_formula() is the only path through which generated results reach the UI. The system accepts only three fields per formula line (ref, percentage, notes); every other nutrition field emitted by the model is discarded. The CandidateFormula type itself carries no nutrition fields and no overrun_pct.
• Parse failures are hard-rejected: an ingredient reference that cannot be resolved against the governed ingredient library is rejected outright, never silently substituted with a similar ingredient; if the total percentage deviates from 100% by no more than 40 percentage points, a bounded proportional repair is applied, otherwise it is rejected.
• One bounded repair attempt: after a first-time violation, the system regenerates at most once, with the repair prompt stating the measured value and limit for each violation; if it is still non-compliant, it is returned explicitly marked non-compliant — never disguised as a validated formula. _resolve_formula() is straight-line code with no loop, so a third generation is structurally impossible.
• The metrics are hard numbers: 34 governed ingredients, dataset version 2026.10.0 (USDA FDC Foundation Foods), 420 backend and domain tests, an 18-case golden compliance set, 100% schema validity, 100% compliance accuracy, 46 labeled briefs for routing evaluation, 100% intent routing accuracy, 100% rule-set activation accuracy.
• Today's (10-28) three commits clean up "chattiness": Stop the UI narrating a pipeline it cannot see, and the proxy failing silently (stop the UI from narrating a pipeline it cannot see, and fix silent proxy failure), Merge b3-verified: close B3, and stop three surfaces asserting what they cannot see (close B3 and stop three surfaces from asserting what they cannot see), Explain the wait on the Idea Stream, where a first visitor actually lands.

Why it matters

• "The model only proposes structure; numbers are recomputed by the deterministic layer" is the engineering version of the "mandatory evidence + zero AI hallucination" I have been insisting on. I implement it in GLP-1 Nutrition Companion V2 through "ingredient templates + rule engine + forbidden-supplement list"; it implements it through "governed ingredient library + pure-Python domain-layer computation + declarative JSON rule sets + one bounded repair". Two different paths to the same destination — and its verifiability is harder still: a compliance accuracy of 100% is the kind of number I could put straight into my own reports as persuasive evidence.
• The hard ceiling of "at most one repair" is smarter than "loop until it passes". My logic for supplement conflicts has always been "give one more chance with concrete violation feedback", but I never wrote it as a hard constraint. It guarantees "no third generation exists" through code shape — a straight-line function with no loop. Writing product principles into type definitions and function signatures rather than into a doc for people to remember is a move I can transplant wholesale.
• What strikes me most is that last commit: stop the UI from narrating what it cannot see. This is precisely the failure mode I keep guarding against — "AI sounds impressive but nothing actually ran". They treat "the interface must not claim things it has not verified" as a bug-level issue. That applies directly to the intervention report of the 4P supplement platform: every "已优化" or "建议调整为" in the report must be backed by a real computation trace.
• It treats "bounded ingredient library + versioned dataset" as a core asset, not an accessory. I have always treated my 4P precision nutrition ingredient library as a static lookup table. It treats it as a first-class citizen requiring a version number, periodic ETL, and manually curated functional attributes (PAC/POD, allergens, cost). That difference in positioning will determine the ongoing cost structure of my data maintenance.

4. hashgraph-online/hol-guard: The agent runtime finally gets its own "antivirus" — dangerous tools, secret exfiltration, prompt injection, malicious packages and MCP all blocked

URL: https://github.com/hashgraph-online/hol-guard ｜ ★1,002 ｜ Apache-2.0 ｜ Rust + Python — runtime protection for AI agents (blocking risky tool calls, secret access, prompt injection, malicious packages, MCP servers, plugins and skills)

What happened

Today's commit density here is the highest of any AI Coding project on the site today, and five of the eight commits are doing the same thing: freezing "who approved it, and at which scope" into verifiable state.

• Today (10-28): feat(guard): preview a redacted source export from the Workspaces tab (preview a redacted source export from the workspaces tab), refactor(approvals): settle an approval's scope and persistence in one resident ask (settle an approval's scope and persistence in one resident ask), refactor(supply-chain): settle a package review from the resident's verdict (settle a package review from the resident's verdict), refactor(codex): walk a Codex hook source's inventory in the resident (walk a Codex hook source's inventory in the resident), fix(runtime): watch mode keeps the known-vulnerable runtime finding over an earlier warning (watch mode keeps the known-vulnerable runtime finding instead of an earlier warning), feat(dashboard): load commands for command-line tools Guard has only seen in use, fix(command): read npm's report verbs as the reads they are, fix(command): create a branch at a start point without asking.
• Six risk classes are covered: dangerous tools and commands (including shell, workspace sandbox, cd paths, tool permissions); secret and credential access (masking Bearer tokens, API keys, X-Api-Key, X-Auth-Token, --password, --api-key before persisting tool-call notifications); prompt injection (prompt policy, approval context, submission hook); malicious packages and supply chain (manifest dependency resolution, lockfile consistency, version conflicts, validating bundle signatures before offline installation, rejecting bundles that are unsigned, expired, or rolled back); MCP (provider catalog, tool permissions, URL safety, persistent subprocess lifecycle); plugins and skills (publisher trust binding, command descriptors, approval rules).
• The core engineering principle is fail closed: when the native runtime cannot reach a trustworthy decision it will not automatically degrade to allow. Policy decisions have scope granularity (global / harness / artifact / family); local one-shot approvals use integrity material and atomic consumption to prevent replay.
• Multi-harness integration: Claude Code, Codex, Copilot, Grok, Oh My Pi, Pi, OMP; distribution forms include the CLI, a GitHub Action, a Claude Code plugin, a devcontainer feature, a dashboard, and Kubernetes (k0s / k0rdent) deployment examples.

Why it matters

• "Fail closed" is the default value I most want to copy into my AI assistant products. For the 4pwellness MCP connector and the nutrition AI assistant, should the default be "if no risk is detected, treat it as passed"? No. The default should be "if it cannot be confirmed, block and escalate to a human" — that default decides whether my product draws complaints in its first week after launch.
• The concept of "scope of approval" is precisely the piece I am missing in the 4P precision nutrition thousand-pioneer project. My persistent worry is that "one authorization gets reused indefinitely". They split scope into global / harness / artifact / family, then implement one-shot authorization with integrity material and atomic consumption so it can only be spent once — this is exactly the "authorization boundary" I have wanted but never found the right way to express.
• The concrete list of secret-masking fields can be copied directly. When I wire model credentials into an AI assistant, the risk that tokens land in logs — or surface in error messages where the agent reads them and passes them back to the model — is real. They enumerate these field names one by one; I can simply follow suit.
• It also shows something else: agent security is shifting from "scanning repositories" to "intercepting at runtime". NVIDIA's SkillSpector scans skill packages before installation; hol-guard governs every tool call while running. The two gates do not conflict — they are standard kit. For my one-person-company product ("certification hook + nutrition AI core"), neither should be cut.

5. JuneYaooo/open-medical: An open-source desktop agent for doctors — three-tier evidence provenance, and AI archive edits as proposals pending confirmation

URL: https://github.com/JuneYaooo/open-medical ｜ ★11 ｜ MIT ｜ TypeScript / Electron + Node.js + SQLite — an open-source desktop agent for doctors (macOS / Windows)

What happened

This is the most thoroughly designed medical project of the day, and its treatment of "evidence provenance" and "human–machine division of labor" is worth reading line by line.

• Three-tier evidence layering: treatment review is organized as knowledge → literature → web evidence tiers; knowledge-base hits can be traced to source line numbers; materials retain author or institution, year, source link, and version; knowledge graph, mind map, and flow chart nodes all trace back to source text; when no basis can be extracted, relationships are not auto-filled. Literature search supports PubMed and Europe PMC, and evidence tasks can prepare PICO and search strategies.
• AI edits to archives go through proposals: "AI updates to archives are presented as proposals pending confirmation, and written only after the doctor checks them"; same-day conflicting data is retained for review, and values with different units are never merged into one trend; lab result imports retain item, date, value, unit, and provenance.
• 14 clinical task templates cover the full admission workflow, tidying medical records, extracting labs, reconciling medication data, drafting records, medication safety checks, plain-language patient education, lab report interpretation, discharge summary drafts, shift handover notes, clinical decision flow charts (Mermaid, preserving node provenance), adverse reaction screening (supporting preparation of a Naranjo assessment), case report writing (CARE framework), and preparing evidence searches. Of these, medication safety checks rely on a limited set of built-in rules, and lab report interpretation uses the reference ranges printed on the report itself.
• Follow-up runs through WeChat: enterprise WeChat or personal WeChat channels are supported, with the flow "AI drafts → doctor confirms and sends → replies are organized per item → confirmation is archived"; the knowledge-base bot only cites materials explicitly cleared for external use.
• Today (10-28): Improve clinical evidence review and overview recovery. On 10-27, six commits: Document evidence-based clinical interface development rules, Improve clinical overview hierarchy and reading contrast, Complete lab, source export and verifiable backup recovery workflows, Improve case context, follow-up linkage and source reading, Clarify task context, model connection status and patient intake, chore: release desktop 1.0.30.
• Local-first, but candid about the edges: patient and message data live in local SQLite (~/.open-medical-workbench/medical.sqlite, the database itself is not encrypted), while model credentials are encrypted in a local credential vault; it explicitly admits that "local-first" does not mean materials stay on the machine when a cloud model is used; and it lists what it does not support — multi-user permission systems, institution-level audit, HIS/EMR/FHIR integration, institution-grade deployment acceptance.

Why it matters

• "AI updates presented as proposals pending confirmation, written only after the doctor checks them" is the product version of every principle I apply to health content production. On the 4P supplement platform's intervention report I have always insisted on "write to the database only after user confirmation" — but I never had a word like "proposal" for it. A proposal inherently carries a diff, a withdrawal path, and an audit trail, and this is the correct way to turn "mandatory evidence" from a slogan into a data structure.
• Its three-tier evidence model with traceability to source line numbers directly fills the external benchmark my GRPM system has been missing. The hardest problem in evaluating the quality of my own generated nutrition advice is "what do I use as the ground truth". When a system can point every conclusion back to a source line, I can borrow its structure as the regression-test baseline for my own — far more reliable than writing my own rubric.
• The way it discloses its own boundaries is worth learning. It plainly states that the database is unencrypted, that local-first does not mean data never leaves the machine, that the DRG tool is a demo rule set unusable for actual insurance settlement, and that AI clinical validity has not been validated and cannot replace a doctor's judgment. This is not weakness — it is declaring compliance risk in advance. For a product that must handle real users' health data, this candor builds more trust than any additional feature.
• The "doctor confirms → sends → organizes replies per item → archives" WeChat chain is nearly identical to my planned 4pwellness WeChat group service bot. The only difference is vertical: theirs is clinical follow-up, mine is nutrition and supplement guidance. This is the first time I have seen an open-source implementation that bakes "a human confirms before reaching out to the user" into the product flow — worth reading its boundary handling line by line.

2. Category roundup

① AI Coding / Coding Agents & Skill Ecosystem

② Medical / Clinical Research AI & Agent Skill Libraries

③ Health Management / Nutrition & Food AI

④ Model Foundations & Agent Infrastructure

3. Trends today

• The most memorable item today is Tencent Cloud formally establishing "cloud development backend" as an agent ecosystem slot. CloudBase-AI-Toolkit ships 38 MCP tools and 482 passing test cases, a hosted remote connector on Streamable HTTP + OAuth already submitted for review, Cursor Plugin 0.2.1, and five distribution formats refreshed in step (.codebuddy/skills, .cursor/rules, .claude-plugin, dsh-plugin). This is not a feature update; it is an ecosystem-position announcement: the cloud backend is no longer something agents guess at through APIs — it actively grows skills and MCP endpoints. In the same week, HKUDS/AutoSwarm orchestrates Codex, Claude Code, DeepSeek Harness, Muse, Grok and WorkBuddy together, while OrchestratorInc orchestrates 30+ coding agents. All three point the same way — "unifying multiple harnesses" is turning from a personal trick into a standard engineering move.
• The trust boundary around AI-generated health plans was pinned from both sides today. formula-forge tightens it on the model side: accept three fields only, recompute nutrition numbers in the deterministic layer, hard-reject parse failures, at most one repair, 420 tests and 100% compliance accuracy. open-medical tightens it on the clinician side: three-tier evidence layering, AI updates as proposals pending confirmation, no auto-filling relationships when no basis can be extracted, and an explicit list of what is not supported. The two projects have 0 and 11 stars respectively, yet what they define — "the model proposes, the rules adjudicate, the human confirms" — is exactly the three-part structure I have already written into the 4P supplement platform's intervention report, for which I had never found a reference implementation.
• The center of gravity in agent runtime security is moving from "scanning install packages" to "every single tool call". NVIDIA/SkillSpector scans skill packages before installation; hol-guard governs dangerous tools, secret exfiltration, prompt injection, malicious packages and MCP while running. Today's commits freeze approval scope into global / harness / artifact / family layers, implement one-shot approvals with integrity material and atomic consumption, and make fail closed the default. This connects directly to the previous issue's observation that "the next battlefield for agent systems is state and permissions" — except now permissions have concrete tiers and a default-deny semantic.
• Health projects are collectively learning one thing: do not say "what I computed" as "what I verified". formula-forge stops the UI from narrating a pipeline it cannot see; open-medical admits the database is unencrypted, that local-first does not mean data never leaves the machine, and that DRG is a demo rule set; itsoso treats photo-reference safety review as a release blocker; BrooklynD23 specifically handles phrasings like "RAG-TIMEOUT-GROUNDED answered" and "open gates stay open" in its doc batches. Four different teams, on the same day, across four different projects, doing the same easily-overlooked thing: writing "what was not achieved" into the product instead of hiding it. For health content, this "visibility of self-imposed limits" is closer to professionalism than any feature.
• Three low-profile projects point at another way to build a nutrition AI core: do not chase model capability, chase deterministic assets. formula-forge achieves 100% compliance accuracy with 34 governed ingredients, versioned USDA FDC ETL, and declarative JSON rule sets; forma splits work across trainer, nutritionist, pantry chef and medical-safety reviewer roles rather than one omnipotent agent; itsoso runs rule checks specifically for medication and supplement interactions, pharmacogenomics and training load. The shared idea: let the model handle what people cannot write rules for, and hand what must be computed exactly to code. For a one-person-company path with eight hours a week, this is the most realistic architecture — build small, hard deterministic asset libraries first, then let the model fill in the rest.

4. Repo index

Picks

• TencentCloudBase/CloudBase-AI-Toolkit — https://github.com/TencentCloudBase/CloudBase-AI-Toolkit
• itsoso/health-llm-driven — https://github.com/itsoso/health-llm-driven
• craft-b/formula-forge — https://github.com/craft-b/formula-forge
• hashgraph-online/hol-guard — https://github.com/hashgraph-online/hol-guard
• JuneYaooo/open-medical — https://github.com/JuneYaooo/open-medical

AI Coding

• https://github.com/OrchestratorInc/agent-orchestrator
• https://github.com/HKUDS/AutoSwarm
• https://github.com/superdesigndev/treg
• https://github.com/elayadesign/ai-design-skills
• https://github.com/NVIDIA/SkillSpector
• https://github.com/nightly-labs/openbot
• https://github.com/ZHangZHengEric/Sage
• https://github.com/useLexora/Lexora
• https://github.com/ChesterRa/cccc
• https://github.com/Cotal-AI/Cotal
• https://github.com/Undertone0809/rudder
• https://github.com/jmagly/aiwg
• https://github.com/Blave-TW/blave-agent
• https://github.com/NanmiCoder/open-image-prompts

Medical / Clinical Research AI

• https://github.com/Deng-GuiFeng/LPSGM
• https://github.com/jkelleman/health-biometrics-biotech-agentic-system
• https://github.com/organicoder42/openclawresearch
• https://github.com/tridaai/blueprint-agentcore-pharmacovigilance

Health / Nutrition

• https://github.com/lhzin2129-wq/forge-nutrition-clients
• https://github.com/BrooklynD23/HealthCentral
• https://github.com/CraftedByMehathab/meTune-app
• https://github.com/VoMinhKhoii/Kallo
• https://github.com/Manvith-d/forma
• https://github.com/im-tnyx/tio-world

Model Foundation / Agent Infrastructure

• https://github.com/paradigmxyz/centaur
• https://github.com/ongridio/ongrid
• https://github.com/Azure/agent-landing-zone
• https://github.com/bex-co/bex
• https://github.com/brycewang-stanford/StatsPAI
• https://github.com/NVIDIA/auto-ontology

This issue covers 35 projects in the category tables, all de-duplicated against prior issues. Star counts, licenses and commit dates follow GitHub API and default-branch records as of 2026-10-28 12:00 (Beijing time).