GitHub AI Daily · 2026-10-30 (Friday)

1. Today's picks (5)

1. lightpanda-io/browser: The AI browser starts hiding passwords from the model — scrubbing credentials out of the context the model sees is one layer earlier than any runtime interception

URL: https://github.com/lightpanda-io/browser ｜ ★37,948 ｜ AGPL-3.0 ｜ A headless browser written from scratch in Zig for AI agents and automation (not a Chromium fork, not a WebKit patch), roughly 1/16 the memory and ~9x the speed of Chromium

What happened

This 37,948-star project posted 45 commits today, the highest commit density of any repository in this issue — and two of them address a problem I have been watching closely: what does the model actually "see"?

• agent: mask a literal login password in what the model is shown (12:43 today) — it does not mask the input field, it masks the literal password inside the page content that is shown to the model. Immediately after, at 13:50, agent: rebuild the masked /login line instead of searching it supplies the crucial engineering detail: after masking you must rebuild that line rather than search-and-replace it on the page — because the original DOM has already been broken, so searching it is guaranteed to fail.
• The same day also brought browser: give each Jev tool its own module, as search has (each Jev tool gets its own module instead of sharing search's implementation) plus two merges: #4067 (plumber v0.7.6) and #4165 (jev-fallback).
• The performance numbers are the real reason it can sit inside an agent's toolchain: on an AWS EC2 m5.large instance fetching 933 real web pages, peak memory for 100 pages was 123MB (headless Chrome: 2GB, about 1/16) and execution time was 5s (Chrome: 46s, about 9x faster). The README states plainly that it is "the headless browser built from scratch for AI agents" — it optimizes not for how fast a human sees a page, but for the marginal cost of each tool call an agent makes.
• License and form: AGPL-3.0, written in Zig, shipping nightly binaries (Homebrew / AUR / curl / Nix). Linux binaries link against glibc, so Alpine users must switch to a glibc-based base image.

Why it matters

• It moves "keys must not leak" from runtime to a layer earlier than runtime, and that earlier layer is one I had not considered. In the previous issue I recorded hashgraph-online/hol-guard blocking dangerous tool calls and key access while an agent is running — that is "the agent already has the tool, and we stop it from using it." Lightpanda solves an earlier problem: the password on that page should never have entered the model's input in the first place. When I wire model keys into the 4pwellness AI assistant, or route lab-report OCR imports through the nutrition platform, the real exposure window is exactly "a sensitive string gets rendered into the DOM, an agent reads it into context, and it goes out with the next request." "Rebuild the masked line instead of searching the original page" is an implementation detail worth copying — it means masking is not text post-processing but something that has to happen back inside the rendering pipeline.
• The 16x memory and 9x speed figures have a direct commercial implication for my one-person-company path with eight hours a week. What my minimum viable version needs to do is exactly "fetch → read → judge → produce a report," a tool-call-dense workload. If the browser cost per tool call is 16x Chromium's, the same machine budget buys one-sixteenth as many sessions. This is not a technology-preference question; it directly determines whether I can deliver a usable experience for a "certification hook + nutrition AI core" within my budget.
• It overlaps a concrete risk in the WeChat-group customer-service bot I am planning for 4pwellness. If the bot helps users look up nutrition plans, or runs a health-report parse against the mini-program backend, any screenshot or page-fetch action can pull tokens, user IDs and even ID numbers into context. With masking in place, the "fetch" step is something I can actually open up to an agent.
• One caveat: AGPL-3.0 means that if I ship it as part of a service, I have to take copyleft compliance seriously. For a one-person company, "can I use it" and "can I modify it and then keep it closed" are two different questions — I must settle that before I build, not after.

2. seancpc/MedAgent-EHR: Planner–Executor–Verifier plus two-phase writes put a clinical agent at ~88% on 300 MedAgentBench tasks, running entirely on a self-hosted local model

URL: https://github.com/seancpc/MedAgent-EHR ｜ ★0 ｜ MIT ｜ Python + Flask + MCP + HAPI FHIR R4, a self-hosted LLM clinical agent that vets itself before writing to the record

What happened

It has zero stars, but it is the most completely architected project in today's medical line and the only one publishing a reproducible benchmark score.

• The architecture is three-stage: clinical task → Planner (decompose into a plan) → Executor (ReAct loop: observe result → decide next step) ⇄ MCP tools ⇄ FHIR → Verifier (pre-write safety gate: approve → commit / reject → retry) → final answer. Planner / Executor / Verifier are all LLM-driven, with no fixed path and no fixed number of steps.
• Writes are two-phase: stage → commit — staged first, committed later, with a Verifier safety gate in between plus medical-code and dosage validation. The README's wording is "guarded by a safety gate before any write."
• The score is auditable: ~88% (259–263 / 300) on Stanford's MedAgentBench (300 tasks) using the official refsol grader, above the best published baseline of Claude 3.5 Sonnet v2 (69.67%). But the author adds the qualifier themselves — "this score reflects an agent system aligned to this benchmark, not a pure comparison of raw model capability" — and honestly flags that the nine stable task categories total 258/270, that task10 is a known output weakness of the deployed model, and reports the result as a range.
• The model is swappable: the default is a self-hosted Gemma-4-26B-A4B-it (also validated on Qwen3.6-35B-A3B), run as GGUF via llama.cpp, with no dependency on cloud LLM APIs; migrating from Qwen to Gemma-4 required almost no code change and kept the score nearly flat, which the author uses to argue the system is decoupled from any single model.
• 14 commits on 10-30, including Update README.md, Update baseline.svg and Update progress.en.svg (result and progress charts), plus one highly informative dependency-governance fix: fix(deps): pin mcp to >=1.27,<2 — mcp 2.x renamed core APIs (FastMCP, streamablehttp_client), breaking imports and failing CI test collection, so the version is simply pinned.
• The boundaries are stated soberly: MedAgentBench's test data and official grader are not distributed with the repository (copyright belongs to the original authors) and must be obtained separately; without the grader the runner still executes but scores only task1; the project's own code is MIT.

Why it matters

• "Two-phase writes plus a Verifier safety gate" is the same construct as the "pending-confirmation proposal" model I read in JuneYaooo/open-medical last issue — but implemented inside a real clinical system. When I implement the Mazdutide on/off medication cascade in GLP-1 Nutrition Companion V2, and when I persist intervention reports in the 4P supplement platform, I have been relying on validation logic I wrote myself in the application layer. They made it a native role inside the agent architecture and attached a public 88% benchmark — which means I can point at their architecture as a reference instead of having to argue for myself why a human confirmation gate must exist.
• "Self-hosted local model with no score loss" matters a great deal to me. I run Ollama qwen2.5:7b locally, and my recurring question is: if I move a clinical or nutrition agent entirely onto a small local model, how much do I lose? Their answer is: migrating from Qwen to Gemma-4 (even a different size class) needed almost no code changes and the score stayed flat — which says what determines agent performance is the Planner/Executor/Verifier structure and tool alignment, not the base model. For a one-person company on eight hours a week, that means I can safely spend money and effort on structure and deterministic assets rather than chasing a stronger model.
• "Pin mcp to >=1.27,<2 because 2.x renamed core APIs" is a free compatibility briefing. When I connect the 4pwellness MCP connector and build my own MCP server, I will eventually hit the same wall. Someone has already written the wall's location and the workaround into a commit message; I can copy the version range directly.
• I want to study their honesty about boundaries: scores given as ranges, the explicit note that this is not a pure model comparison, a clear statement that data and grader are not redistributed, and a list of unsupported items. This is exactly the "evidence first, zero AI hallucination" discipline I keep in my health content — writing "what this number cannot prove" right next to the number.

3. whiteravens20/diet-app: Nutrition math becomes a deterministic engine and AI drops to optional assistant — "it never invents nutrition facts" is a single sentence in the README

URL: https://github.com/whiteravens20/diet-app ｜ ★2 ｜ AGPL-3.0 ｜ TypeScript, a self-hostable diet and meal-planning platform with deterministic nutrition computation and BYOK AI

What happened

A young project (created 2026-05-22) with only two stars, but it draws the boundary around "AI generating nutrition plans" more clearly than most commercial products — and it faces almost exactly the same situation as 4P does.

• The product positioning line is itself the division of labor: "Diet App generates calorie-targeted meal plans, optimises ingredient reuse across a planning window, and produces consolidated shopping lists — all from a curated product database so every calorie and macro is deterministic and reproducible. AI is an optional assistant: it drafts recipes, suggests substitutions and weighs what the planner proposes; it never invents nutrition facts."
• The calorie engine is deterministic: BMR via the Mifflin-St Jeor formula, activity multipliers, weekly weight-loss targets constrained to 0.25–1.0 kg/wk, converted into a daily deficit and then limited to a quarter of maintenance, with no calculated target allowed below that floor, plus a manual override.
• AI drafts, then a validation layer recomputes: AI may only draft recipes from approved ingredients, and a validation layer then recomputes every number. Users can also write recipes by hand from the catalogue's ingredients (the engine works out what a serving holds), or import a schema.org document — but every line must correspond to a known ingredient in the catalogue with a quantity, every draft must be approved by a person, and the recipe must state its origin and license.
• The meal planner genuinely optimizes: a plan declares which packs it buys and how long those packs keep against what it uses of them, and a plan designed for cooking ahead cooks one dish for two days. A given day of a plan can be set apart (training day, rest day, skipped, a different meal count, its own target), and what that does to its meals is said before it is saved.
• Shopping lists are counted the way a person shops: eggs by the piece, bread by the slice, weights rounded up to 5 g, rows consuming whole packs; what the pantry already holds is subtracted, purchases beyond need flow back into the pantry, and exports come as PDF, spreadsheet, or plain text.
• 11 commits on 10-30, running along the line of "let food and meals carry their own picture" and "count diary entries into anything that fills a day of a plan": feat(web): show the pantry's banner with its food in the frame, feat(web): give the favourites a banner photo of their own, feat(web): give the diary's banner a photo of its own, feat(api): count the diary's entries in whatever fills a day of a plan.
• The boundaries are equally sober: a prominent WARNING at the top of the README — early development, not production ready, API and data model may change without notice, no security review performed, "self-host it to experiment, not for anything you depend on yet."

Why it matters

• Its point of divergence from my GLP-1 Nutrition Companion V2 is exactly the divergence I have to think through. I am currently built around 153 ingredient templates, 15 functional targets, early/late dual-cup plans and a formulation engine, with the model participating meaningfully. They go a different way: a governed packaged-food database plus deterministic computation, with the model only proposing and suggesting substitutions, and a validation layer recomputing every number. Put plainly: they completely separate "computing" from "telling." I already accepted this direction last issue with craft-b/formula-forge ("the model only proposes structure, the deterministic layer recomputes the numbers") — and now a second unrelated team arrives at the same place in a dietary setting. Two independent convergences are more persuasive than any argument.
• "No calculated target may fall below the floor" is the simplest and most effective guardrail I have seen. Whenever I design a fat-loss or muscle-gain plan I agonize over "what if the AI proposes an intake that is too low," and they close it with a single rule: the deficit is capped at a quarter of maintenance, and targets have a floor. This is not left to the model's discretion — it is written into the formula. I can lift this structure straight into the 4P intervention report.
• "Every draft needs human approval plus a validation layer that recomputes every number" is the workflow I have been trying to pin down in the 4P supplement platform. What I have been missing is a structured place where "who approved it, and at which layer" is persisted. They put the approval action before a recipe enters the library; I should put the same checkpoint before an intervention report is persisted.
• But their WARNING is exactly the trap I want to avoid: 2 stars, AGPL-3.0, no security review. So my use is as a design reference, not as a dependency — copy the formula constraints and the approval checkpoint, do not import their code. AGPL-3.0 is likewise reference-only for me.

4. CopilotKit/OpenBot: "Every action decided before it happens and recorded after" — AI coworkers get their own browser, their own logins and their own files, but only the tools you grant

URL: https://github.com/CopilotKit/OpenBot ｜ ★8,507 ｜ MIT ｜ TypeScript + AG-UI, a self-hosted "AI coworker" workspace where each coworker has its own browser, files and tool grants, with actions decided before and recorded after

What happened

This is #4 on today's GitHub trending (+707 stars today, Trendshift's #3 repository of the day), and its product definition sentence is a permission design.

• The core README paragraph: "Each coworker gets a real browser with its own logins, its own files, and only the tools you grant. Every action decided before it happens and recorded after." The delivery model is that any AG-UI agent (written on any framework or by hand) arrives as a coworker with a channel of its own; you watch it work on its own screen, take the wheel when it reaches something it should not do alone, and then hand it back.
• The positioning is extremely restrained: "A template, not a product. OpenBot is meant to be cloned and made your own. There is no hosted version to sign up for, and nothing here is published as a package to depend on: you take the repository, replace the example tenant package under examples/ with your own coworkers, channels and skills, and run it." It is explicitly labeled Beta, and under active development, with rough edges and bugs expected.
• Form factor is local-first: the README states "Everything below is written for a laptop," with .env.example pointing at running locally as the default path; the MCP marketplace, the Today panel, and desktop v0.6.0/v0.7.0 all moved forward on the same day.
• The substantive commit on 10-30 is Give Bots the whole standard catalog but four (#875) — "gave the bots the whole standard catalog but four." The tool surface was opened further today, keeping only four items withheld; the larger the tool catalogue, the harder "only the tools you grant" becomes to engineer.
• Alongside it: Add marketplace schema snapshot coverage (schema snapshot tests for the MCP marketplace) and Harden marketplace MCP client and add tests (hardening the marketplace MCP client with tests) — for a marketplace of agents, tool trust has to be backstopped by schema snapshots and tests.

Why it matters

• "Every action decided before it happens and recorded after" is the through-line that has recurred across the last two issues, written here for the first time as a product promise. I logged hol-guard's fail-closed behavior on 10-28, open-medical's pending-confirmation proposals on 10-28, and — further back — the principle that every "已优化" in an intervention report must have real computational traces behind it. Those three are actually one thing: every AI action should have a prior decision and a posterior trace. They implement it as an isolation model where each coworker gets its own browser, logins and files. "Isolation + prior authorization + posterior logging" is the three-part architecture I want to draw for the 4pwellness WeChat-group bot and the nutrition AI assistant.
• "Only the tools you grant" stings most because I have not built tool authorization at all yet. What my nutrition AI core is about to connect includes the ingredient library, lab indicators, the 40 SNPs from GRPM and Excel export — and if a user says "while you're at it, also do the export," I have no gate. Their approach is to grant the whole standard catalogue except four items and authorize per tool; when I need to tighten, the cost is added later. I should invert it: default to minimal authorization, open up item by item, and make "which tools this user may call in this conversation" an explicitly visible piece of state.
• "A template, not a product" is a positioning that suits a one-person company almost by design. There is no hosted tier and nothing to depend on as a package; the only delivery is: clone the repo and make it yours. When I build the certification-hook-plus-nutrition-AI-core, I was never planning a generic SaaS — and this kind of "template, not product" MIT project suits me as a base far better than closed-source SaaS (the permissive license is essential for someone who intends to modify; the two AGPL projects today are read-only for me).
• Beta status plus a tool catalogue that is still widening means it is trading breadth for real feedback. What I want to watch is whether the authorization model develops cracks as the catalogue grows — "granted too broadly, leading to overreach." That is exactly the class of problem I am most worried about when connecting the 4pwellness MCP connector, and I get to watch its evolution as a public sample.

5. nambok/mentedb: A database engine purpose-built for AI agent memory — not a wrapper around existing databases, but written from the ground up in Rust

URL: https://github.com/nambok/mentedb ｜ ★122 ｜ Apache-2.0 ｜ Rust, a database engine purpose-built for AI agent memory (WAL + HNSW vector index + knowledge graphs), cloud-hosted or self-hosted

What happened

Modest star count, but it addresses the specific question I have been trying to solve with existing tools: where should "persist every interaction to support self-evolving learning" actually live?

• The positioning is one sentence: "MenteDB is a purpose built database engine for AI agent memory. Not a wrapper around existing databases, but a ground up Rust storage engine that understands how AI/LLMs consume data." The name comes from the Spanish mente (mind, intellect).
• Two ways to run: Cloud (get an API key and let managed overnight maintenance run for you) or Self-host (cargo install mentedb-server or Docker, with nightly maintenance built in); plus runnable examples for every combination of cloud or self-hosted with Python, Node or Rust.
• The integration path is unusually direct for an AI tool builder: npx mentedb-mcp@latest setup claude-code (also cursor, copilot, claude) — it ships its own MCP server, so one command wires its memory into the coding agent I am already using.
• Two of its three commits today are a release and a storage-format hardening: chore: release v0.44.1 (a formal release) and fix(storage): refuse to open a directory migrated to the record format (refusing to open a directory already migrated to the new record format — a concrete defense against silently corrupting old data when formats evolve, stricter than "fail the migration"), plus an lz4_flex dependency bump.
• Three storage primitives: WAL (write-ahead log), HNSW (hierarchical navigable small world, for vector nearest-neighbour), and knowledge graphs — designed around how LLMs actually read and write data rather than around the relational model; published to npm, PyPI, crates.io and docs.rs.

Why it matters

• It offers me the layer I had been planning to write myself. In GLP-1 Nutrition Companion V2 I insist on "persist every interaction," but what I actually do today is dump interaction logs into SQLite — that is application logging, not agent memory. The difference: application logs record "what happened," while agent memory must "recall relevant past experience semantically." WAL + HNSW + knowledge graphs map exactly onto the three needs of reliable writes, semantic retrieval and structured relations.
• "Refuse to open a migrated directory" is the line I most want to copy from its data versioning. The 4P precision-nutrition platform has versioned intervention reports, tracked lab-indicator trends, and GRPM has a 40-SNP extraction pipeline — all of these data models will evolve. "If the format changed, refuse to open explicitly rather than read it best-effort" is far safer than "be as compatible as possible," because for health data, silently misreading one row is more dangerous than failing outright.
• It ships an MCP server and attaches to Claude Code / Cursor / Copilot in one command — this removes the first engineering hurdle for my "nutrition AI core." With only eight hours a week, anything that eliminates "writing my own memory layer plus my own MCP adapter" is a direct time saving. The first thing I do next week is run it against my own interaction logs and see whether it can replace my clumsy "log everything every time" approach.
• Apache-2.0 is far friendlier to my path. Compared with today's diet-app (AGPL-3.0) and lightpanda (AGPL-3.0), Apache-2.0 lets me modify and then provide closed-source — which is essential for something I intend to sell, like the certification hook plus nutrition AI core lightweight assistant. Treating the license as a first-class screening criterion is much cheaper than remediating after the fact.
• One honest caveat: 122 stars, Beta, and APIs may change between minor versions. So my stance is to treat it first as an interface-design reference — watching how it defines "what agent memory is" and what overnight maintenance actually maintains — rather than wiring it into a production path now. My minimum viable version cannot survive a data-layer rework.

2. Category roundup

① AI Coding / programming agents and skill ecosystems

② Medical / clinical research AI and agent skill libraries

③ Health management / nutrition and food AI

④ Model foundation and agent infrastructure

3. Trends today

• The most notable thing today is that "credentials must not enter the model's context" moved to a layer earlier than runtime interception. Last issue, hashgraph-online/hol-guard covered blocking dangerous tool calls and key access while an agent runs. Today, lightpanda-io/browser covers the password on that page never being rendered into the content the model sees, with the engineering detail that after masking you rebuild the line rather than searching the original page. Together the two form a complete security chain: first don't let the model see it, then don't let the model act. For the 4pwellness assistant and the nutrition AI core, I currently only have the second half.**

• The numbers a clinical AI project published today, and the way it qualified them, are worth reading repeatedly. seancpc/MedAgent-EHR reports ~88% (259–263/300) on Stanford's official MedAgentBench grader, above the published best baseline of 69.67% — and immediately adds that "this score reflects an agent system aligned to this benchmark, not a pure comparison of raw model capability," clearly flagging task10 as a known weakness of the deployed model and reporting a range. More importantly, it self-hosts Gemma-4 / Qwen3.6 via llama.cpp, and migrating between them required almost no code change with the score staying nearly flat — the conclusion being that what determines agent performance is the Planner/Executor/Verifier structure and tool alignment, not the base model. For someone running qwen2.5:7b locally like me, that is the most consequential line here: spend money and effort on structure and deterministic assets, and don't chase a stronger model.

• Nutrition projects are collectively doing the same thing: separating "computing" from "telling," and writing it into the product positioning sentence. whiteravens20/diet-app's README says outright that "AI is an optional assistant … it never invents nutrition facts," backed by a deterministic calorie engine (deficit capped at a quarter of maintenance, targets with a floor) and an "AI drafts → validation layer recomputes every number" flow; JlMoreno00/sabor uses MCP to turn a self-hosted Mealie into an "agent-ready kitchen" where syncing to Bring! requires a preview plus a digest confirmation; NMH1988/fitcoach-ai-assistant puts the human in the coach's seat with the agent behind. Add craft-b/formula-forge's "the model only proposes structure, the deterministic layer recomputes the numbers" from last issue, and four teams who have never met are converging on the same engineering principle across adjacent fields. For my tradeoffs this week the conclusion is unambiguous: build the deterministic assets first (governed ingredient library, formula constraints, approval checkpoints), then let the model fill in the rest.

• Agent permission boundaries are being pinched from both sides today. One side is CopilotKit/OpenBot: each coworker gets its own browser, its own logins, its own files, only the tools you grant, every action decided before and recorded after — and it opened its tool catalogue today to "the whole standard catalog but four," which means the larger the grant surface, the harder the gate is to hold. The other side is nolabs-ai/nono: pausing the PTY relay for network approval prompts and recording proxy audit events live. One is "how much to grant," the other is "the runtime must not bypass approval" — you need both, and doing only one is not enough. My nutrition AI core currently does neither.

• One negative signal worth not skipping: Microsoft's AutoGen is no longer maintained, while LangChain shipped 1.7.3 the same day. AutoGen's own commit titles from mid-October say "AutoGen is archived and no longer maintained," and on 10-28 it added an archive caution to its landing page; meanwhile LangChain released core 1.7.3 on 10-29. This is not news, but it is the answer narrowing to the question "which agent framework should I build my own on." The dsh (DeepSeek Harness) local framework I use this week, the WorkBuddy client, and the MCP ecosystem I plan to plug into — the space of dependable underlying dependencies is smaller than it was a year ago. That is an argument for putting effort into my own deterministic assets and business logic rather than betting on any one agent framework's long-term survival.

4. Repo index

Picks

• lightpanda-io/browser — https://github.com/lightpanda-io/browser
• seancpc/MedAgent-EHR — https://github.com/seancpc/MedAgent-EHR
• whiteravens20/diet-app — https://github.com/whiteravens20/diet-app
• CopilotKit/OpenBot — https://github.com/CopilotKit/OpenBot
• nambok/mentedb — https://github.com/nambok/mentedb

AI Coding

• https://github.com/anthropics/claude-code
• https://github.com/NanmiCoder/cc-haha
• https://github.com/milind-soni/OpenMausBot
• https://github.com/macro-inc/macro
• https://github.com/dotnet/skills
• https://github.com/gadievron/raptor
• https://github.com/zzet/gortex
• https://github.com/dyoshikawa/rulesync
• https://github.com/coleam00/skills
• https://github.com/griddynamics/rosetta
• https://github.com/TerminalSkills/skills
• https://github.com/Goldziher/ai-rulez
• https://github.com/andrewstellman/quality-playbook
• https://github.com/expo/skills

Medical / clinical research AI

• https://github.com/sunlabuiuc/PyHealth
• https://github.com/jamesrosing/your-procedure-is-denied
• https://github.com/MaSunKing/medical-research-agent-grpo
• https://github.com/heilashahidi/adversarial-openemr
• https://github.com/Nikhil0167/MedSynapse

Health / nutrition

• https://github.com/tahaygun/ai-calorie-tracker
• https://github.com/ivzxan/nutrisyai
• https://github.com/JlMoreno00/sabor
• https://github.com/NMH1988/fitcoach-ai-assistant
• https://github.com/sslugic/pulse
• https://github.com/ariefandw/saestu-pwa

Model foundation / agent infrastructure

• https://github.com/langchain-ai/langchain
• https://github.com/kortix-ai/suna
• https://github.com/opensandbox-group/OpenSandbox
• https://github.com/kyegomez/swarms
• https://github.com/Anil-matcha/open-duet
• https://github.com/ModelEngine-Group/nexent
• https://github.com/nolabs-ai/nono
• https://github.com/kubernetes-sigs/agent-sandbox
• https://github.com/microsoft/autogen
• https://github.com/NVIDIA/NeMo-Agent-Toolkit
• https://github.com/Agent-Field/agentfield
• https://github.com/rome-os/rome
• https://github.com/mindroom-ai/mindroom
• https://github.com/Antseed/antseed

This issue covers 44 projects in the category tables, all de-duplicated against previous issues. Star counts, licenses and commit times are based on GitHub API / default-branch records, as of 2026-10-30 21:00 Beijing time.