GitHub AI Daily · 2026-11-10 (Tuesday)

1. Today's picks (5)

1. meta/astryx: Meta open-sources the design system it used internally for eight years, with 150+ components and fully open internals — the problem it solves is not looking good, but letting an agent read and modify a UI

URL: https://github.com/meta/astryx ｜ ★20,293 ｜ MIT ｜ TypeScript + React 19 + StyleX

What happened

152 commits in the window (running continuously from 11-09 into 11-10, still committing at 11-10 02:28Z), making it one of the highest-activity projects this issue; the main line is continued refinement of v0.7.11 (released 11-07). The README states the positioning in one sentence: "An open source design system that's fully customizable and built for how we build now: by people and the agents working alongside them." — note the second half: this is about an era where people and agents work side by side, so the design system has to work for both.

• ⭐⭐ Its central claim is "open internals," which is precisely where it diverges from most design systems: the README says explicitly "Open internals. Components are built to be composed at any level, not locked behind a closed top-level API." — components can be composed at any level rather than locked behind a closed top-level API. This matters enormously for agents: for an agent to change a UI, it has to be able to walk down the component tree to the specific layer that needs changing, rather than receiving a black-box switch like variant="primary".
• ⭐ The foundation is React 19 + StyleX, and every component ships pre-built CSS plus typed React components: the README says "You import pre-built CSS and use typed React components — no build plugin, no styling library to adopt" — no build plugin to install, and no existing styling system to adopt, which makes the adoption cost near zero for projects that already have a stylesheet.
• ⭐ Scale and provenance are stated concretely: it grew inside Meta over the last eight years, became the largest and most-used design system in the company, and powers 13,000+ apps; the open-source version ships 150+ accessible components, brand-level theming, dark mode, ready-to-ship templates, and a CLI.
• ⭐⭐ The in-window commits show exactly where "agents and people share the same tooling" lands in the details: docs(ChatLayout): a reply gets one right edge with contentWidth="100%"; Markdown keeps its 680px measure — a layout rule written for agents: a reply has exactly one right edge, and Markdown body copy keeps a 680px reading measure. fix(DropdownMenu): a finger's hold-slide-lift no longer flashes the focus outline on the menu button — no more focus-outline flash when a finger long-presses, slides and lifts. test(interaction-harness): a late hand-off reads the caught start and test(Lightbox): a coast landing frozen late fails by name — two interaction tests both named after a state that arrived late, and they fail by name rather than by line number.
• ⭐ Components can be "swizzled" (their internals replaced): the README notes that "when you need to go deeper, swizzle ejec…" — meaning that when you need to go a layer deeper, you can replace the internal implementation without forking the whole library.
• ⭐ It is still in Beta, but it already ships an npm package (@astryxdesign/core), a documentation site, Storybook and a sandbox playground, with a PRs-welcome badge and a Discord entry point.

Why it matters

• ⭐⭐ "Components composable at any level, not locked behind a closed top-level API" — this one directly fixes a recurring class of problem in my own 4P platform's frontend. My neteye system (port 8899, with an admin backend) uses page structures I wrote myself, and every new feature means copying and pasting another block of styles, so the whole thing will inevitably drift over time. "Open internals" means an agent changing a UI can find the exact layer to modify instead of patching around a black-box wrapper. For a one-person company, the property of "being safely modifiable by an agent" is itself a form of maintainability — that belongs in my selection criteria.
• ⭐⭐ "Markdown body copy keeps a 680px reading measure" is exactly the constraint I have been enforcing in my own publishing layout. I care deeply about mobile text readability (font size, layout), and 680px is a number written into the component contract, not "roughly speaking." "A design spec that pins a verifiable number is a hundred times more useful than one that says 'make it readable'" — when I build the report export pages and layout templates for the 4P platform, I should write key layout parameters as checkable constants the same way.
• ⭐⭐ The way the two interaction tests are named ("a state that arrived late", "a coast landing frozen late") is something I should copy straight into my own test conventions. In the 11-08 issue I recorded lights-out's test-proof gate — "a new test has to fail on the baseline." This issue's astryx supplies the other half: when it fails, it should report a named user scenario, not an assertion line number. Because line numbers shift as code moves, scenario names do not — three weeks later, when someone sees CI go red, what they need to know is which interaction broke, not that line 412 blew up.
• ⭐⭐ "Swizzle the internals without forking the whole upstream library" is both a licensing and an architectural decision. For someone with only eight hours a week this matters a lot: any customization that requires forking an entire upstream library is a maintenance debt I cannot afford. That belongs in my technical selection checklist.
• ⭐ "Eight years inside Meta, powering 13,000+ apps, 150+ accessible components" — these numbers mean it has been stress-tested by real engineering. I work on health and nutrition content, and what I fear most is a beautiful design that nobody actually uses; "powering 13,000+ apps" is hard evidence of adoption. And the components ship with accessibility support built in, which for a health product serving middle-aged and older users is a requirement rather than a nice-to-have.
• ⭐ MIT licensed and directly usable commercially. Of the 104 entries this issue, MIT and Apache-2.0 together account for 63 (61%), and astryx is the largest and cleanest-licensed among them — for a one-person company, "usable as a foundation as-is" is itself a selection reason.
• ⚠️ One caveat: it is still in Beta, so the API stability of 150+ components cannot be assumed. If I bring it into the 4P platform's production UI, I should try it on new pages first and pin the version.

2. github/squad: GitHub itself ships a "human-led AI development team" — it puts each team member's charter (job description) into repo files, so governance and code live in the same git

URL: https://github.com/github/squad ｜ ★3,372 ｜ MIT ｜ TypeScript

What happened

23 commits in the window (11-09 into 11-10), with the main line being the v2.0.0-preview.4 release (11-09 19:04Z). The README states the positioning in one sentence: "Human-led AI agent teams for any project. One command. A team that helps you move faster with your code."

• ⭐⭐ The most important design claim is its explicit denial that this is a chatbot wearing hats: "It's not a chatbot wearing hats. Each team member runs in its own context, reads only its own knowledge, and writes back what it learned so the work stays inspectable." — each team member runs in its own context, reads only its own knowledge, and writes back what it learned, so the work stays inspectable.
• ⭐⭐ It writes "humans are not replaced" as a product position rather than a disclaimer: the README gives it its own section, "Responsible AI stance — Squad is built to amplify a human operator with GitHub Copilot, not to remove humans from the loop," and reinforces it in the body: "People stay accountable for priorities, approvals, and final changes." — people always remain accountable for priorities, approvals and final changes.
• ⭐⭐ The single largest commit this window pushes that line one step further: feat(claude): Claude projection v2: member subagents, skills, governance hooks, watch preset (#2450) — four keywords in one commit: member subagents, skills, governance hooks, watch preset. In other words, it does not merely do multi-agent collaboration; it has begun to put governance onto agent teams.
• ⭐ One more in-window commit is worth noting: docs(claude): align Claude Code spec, docs and matrix with the code; add host projection regression guards (#2445) — "align spec, docs and matrix with the code," plus regression guards to enforce it. This is exactly the lesson I recorded in the 11-09 issue: when documentation and implementation disagree, there must be a test that goes red to adjudicate who is right.
• ⭐ Team members are entities with charters (job descriptions): the README says Squad will "propose a team — each member named from a persistent thematic cast," and that squad init --preset default hands you a complete team with members, charters and routing rules. The team configuration is written into your repository as files — the verification step is literally checking that .squad/team.md was created.
• ⭐ Team configuration lives in your repo as files: .squad/decisions/decisions.md carries decision records (one v2.0.0-preview.4 changelog entry removes a stale gitattributes rule left on that file). Distribution covers npm, Homebrew, WinGet and standalone archives, and the standalone install bundles Node.js, so it does not require npm registry access.
• ⭐ It is already packaged for use by other frameworks: the README mentions a .NET-side Squad.Agents.AI NuGet package, letting a Squad team be called as a single Microsoft Agent Framework agent.

Why it matters

• ⭐⭐ "Each member in its own context, reading only its own knowledge, writing back what it learned" — this treats the biggest hazard in my expert-package system: context bleed. In the 11-09 issue I recorded sprag's bug where a 1M-context model borrows the window reported by another session, and told myself to audit global state. Squad's answer is more thorough than adding locks: it is to architecturally ensure each member simply cannot see the others' material. Applied to my 4P platform (Flask + SQLite, multiple sessions), if intervention-plan generation, evidence validation and report rendering share one context package, that is effectively letting every session share one brain — whereas squad's approach is: split them, each reads only what it should.
• ⭐⭐ "People always remain accountable for priorities, approvals and final changes" is the same proposition as the red line I drew for myself. I explicitly forbid claiming any medical credential in any content, not out of moral fastidiousness but because a one-person company cannot bear that liability. squad writes the same judgement into its product positioning: governance is not a disclaimer bolted on at the end, it is the default answer to the question of who is responsible. Every intervention report my 4P platform emits should carry an explicit "a human is responsible" field rather than relying on a footer disclaimer.
• ⭐⭐⭐ "Member subagents + skills + governance hooks" appearing together in one commit is the strongest signal yet for what I do with expert packages (expert-manager). My current expert-package QA process is "let the model grade itself," whereas squad's approach is to make governance into hooks, into inheritable rules, into checks that go red. This is the official version of the same road I recorded in the 11-08 issue with samd-starter-kit's 16 workflow gates — and now GitHub itself is walking it. Next issue I should look specifically at what its governance hooks actually look like.
• ⭐⭐ "Align spec, docs and matrix with the code + regression guards" is the cheapest and most copyable item in this commit. The four things I listed for myself in the 11-09 issue (evidence-type labels, source-text location ranges, rule validation timestamps, staleness scanning) are all currently mere conventions, and conventions rot without guards. squad's approach is to add a regression test that adjudicates who is right when docs and code diverge. I can move this directly into my content pipeline: every WeChat article spec should have a test too.
• ⭐⭐ The shape of "team members are charter files" is highly suggestive for me. A charter = job description + permitted read scope + output format. My four algorithms (P4 local recommend.py / DINGXIANG / JINGYAN) are currently just a paragraph of prose; writing them as charter files with explicit permitted-read scope would let agents know what each one may touch.
• ⭐ The install path covers all platforms and the standalone install bundles Node.js with no npm registry access** — a real requirement for "make it run on the customer's machine," though a one-person company like mine does not need it yet.
• ⭐ MIT licensed and directly usable commercially.

3. wld007/dsh-medical-anonymizer: a "bulk medical-record de-identification" plugin for DeepSeek Harness — rules run first, the model reviews blind, and anything unresolved is never silently accepted, with an audit report for every batch

URL: https://github.com/wld007/dsh-medical-anonymizer ｜ ★5 ｜ MIT ｜ JavaScript

What happened

47 commits in the window (11-09 into 11-10), with v0.8.0 released. The README states the positioning in one sentence: "DeepSeek Harness plugin for bulk de-identification of medical record text and tables. It detects direct identifiers, replaces them with stable pseudonyms, keeps the file structure unchanged, and outputs an audit report plus a reversible mapping store."

• ⭐⭐ Its five design principles are each worth copying on their own: structure is naturally preserved ("the model only annotates the text; the plugin locates the exact spans and replaces only those spans. Row counts, CSV columns, JSON keys and non-text Excel cells do not change"), rules first, model optional ("ID card checksum validation, phone and email patterns, tagged fields, and column-name/key-name strategies all run without a model; the model round is used to raise recall on free text and to double-check the result"), a bounded repair loop ("findings from the review round flow back into the detection stage, constrained by a round cap. Unresolved items are marked for manual review rather than being silently accepted"), local first ("no telemetry. The plugin only talks to the OpenAI-compatible endpoint you configure; point it at a local runtime and the data never leaves the machine"), and auditable output ("per-file entity statistics, structure validation, residual issues, a manual review checklist, and a mapping store that uniquely holds the original values. The report does not print identifier originals").
• ⭐⭐ One layer of the validation is a "model blind review": the README says "model blind review (not told the detection results; the verification model can be configured separately)" — the reviewing model does not know what the detection output looked like, so it hunts independently for leaks rather than retracing the detection model's reasoning. After that come a rule rescan, an original-value residue check and a structural comparison; "residuals reported by the verifier are re-judged by the detection model, and disagreements enter manual review" — disagreements are not settled by internal model voting but escalated to a human.
• ⭐⭐ Its coverage is far broader than the word "medical record" suggests: beyond .txt, .md, .csv, .json and .xlsx, it handles .zip archives (including nested ones) and DICOM images (metadata only); encoded content inside fields is unpacked layer by layer: base64, gzip, URL encoding, \u escapes, HTML entities, HTML/XML, nested JSON, HL7, and what cannot be unpacked (images, PDF, binaries, unknown encodings) goes to manual review and is not delivered until that review is done.
• ⭐⭐ The identifier coverage is modeled on the actual headers used by Chinese hospitals: direct identifiers include names, doctor and staff names, national ID numbers, phone, email, address, medical record number, inpatient number, outpatient visit number, social security number, bank card number and hospital name; the column-name and key-name strategies directly cover Chinese headers such as xingming (name), shenfenzhenghao (ID number), dianhua (phone) and zhuzhi (address), plus in-hospital system keys like PTT_NM, ID_CRD_NO, CTCT_TEL_NO, CURR_ADDR*, *_DCT_NM, MDC_ORG_NM, PID and INHOS_NO; record keys such as PRM_KEY/RCD_NO are masked as record identifiers. Names, ID numbers, phone numbers, patient_<number>, zyh_<inpatient number> and mzh_<outpatient number> appearing in file and directory names are replaced with pseudonyms consistent with the body text.
• ⭐ Pseudonyms are generated stably by value and by type: for example alias-9F3A2C (a pseudonym for a name) and credential-1F0B67 (a pseudonym for an ID), so that the same value yields the same pseudonym across files and batches that share an output root — cross-file comparable, and the type is still legible.
• ⭐⭐ The in-window commit log is itself a complete sample of self-audit and self-correction: Fix 12 high-severity leaks found in code review — twelve high-severity leaks fixed in one pass from a code review; followed by Fix remaining medium and low findings from code review to wrap up; and before that Cross-check detail tab: every blind-review finding with context, reasons, outcome and human verdict — every blind-review finding carries context, reasons, outcome and the human's verdict; plus Model table: failure rate above context (failure rate displayed above context) and C3 cross-check: full layout placeholder before data (a complete layout placeholder is laid out before data is filled in).
• ⭐⭐ It has one line of self-positioning that is exceptionally well put: "This is a data processing tool, not a compliance certification. Before publishing any output, review it against applicable law and your organization's policies." — the tool does not take on compliance responsibility for you; it only guarantees it does not get the job wrong.
• ⭐ The local-first commitment is concrete: the plugin never calls the built-in cloud model, using only the OpenAI-compatible endpoint you configure (the README gives Ollama at http://127.0.0.1:11434/v1 as an example); model calls are uncapped, with multi-file concurrency, automatic grouping when there are many files, cancellation, and the ability to undo a batch's newly added mappings.

Why it matters

• ⭐⭐⭐ I run DeepSeek Harness on this machine, so this is directly usable rather than something merely worth noting. My records plainly state that a local dsh v0.1.0-rc.6 runs for native agent development — and this plugin fills exactly the gap I have been missing in the dsh ecosystem: sanitizing real medical text. The GRPM reports, Ji Min's baseline health-check data, and the observed indicators from the Bai-Shi project — once any of this needs to go to a model, de-identification is not optional.
• ⭐⭐⭐ "Unresolved items are marked for manual review rather than silently accepted" — this lands precisely on the current state of my platform. In the 11-08 issue I recorded assay's line: "a tool returning success is only the provider's assertion, never proof." This plugin is the engineering form of the same idea: de-identification is not "it ran to completion," it is "every item has an account." Applied to my OCR pipeline: fields that cannot be recognized or that fall below the confidence threshold should enter a manual review queue, rather than being filled with defaults and written into the report alongside everything else.
• ⭐⭐⭐ "Model blind review (not told the detection results)" is the single most valuable design element here. It turns "AI checking AI" from a formality into an independent re-check. In the 11-09 issue I recorded bmlib's retraction-status states and the Cochrane nine-domain assessment, whose essence is not letting the same model stamp its own homework. Blind review is the same principle in a different form: bring in a model that does not know the earlier conclusion and have it look again. And every self-check in my 4P platform today is done by the same model inside the same context — which structurally makes it incapable of finding its own systematic errors.
• ⭐⭐ "Disagreements are not settled by internal model voting but escalated to a human" is the only defensible triage rule in the medical chain. When the detection model and the review model disagree, letting them vote or asking one of them to "think again" merely hides the uncertainty. Escalating to a human costs labor, but the cost lands in the right place.
• ⭐⭐ "The report does not print identifier originals, but a separate mapping store uniquely holds them" is a deliberate separation. An audit report must be able to be handed to a third party, while the mapping store must be tightly protected — mix the two and the report can no longer leave your building. Applied to my platform: the intervention report is an export for the client, the mapping store is an internal asset, and the two must sit behind different permission boundaries.
• ⭐⭐ "Structure is naturally preserved" solves a long-standing problem in my OCR pipeline: whether extraction destroys the original structure. The README explicitly guarantees that row counts, CSV columns, JSON keys and non-text Excel cells do not change — which means a document processed by AI remains parseable downstream by the same tools. If my lab-report OCR also pursued this property (parse results aligned with the original file structure), I would gain the guarantee that a processed result can still be recomputed.
• ⭐⭐⭐ Its header and key-name list is "the real headers used by Chinese hospitals," and that list is itself ready-made input for my 4P platform's lab-OCR rule table. PTT_NM, ID_CRD_NO, CTCT_TEL_NO, INHOS_NO, mzh_<outpatient number>, zyh_<inpatient number> — these are the fields I have to handle in real records, and it has already listed them all. I can treat it as a requirements checklist and compare it against my own rule table to see what I missed.
• ⭐ MIT licensed and directly usable commercially; at ★5 it is clearly a new, early-stage project — which is both a chance to copy the design and a responsibility to audit the code myself.
• ⚠️ It emphasizes itself that this is not a compliance certification — and that attitude is something I should adopt: any tool of mine should state in its output that it does not constitute a compliance conclusion.

4. liliang-cn/cortexdb: agent memory as "a knowledge graph plus ontology constraints plus traceable reasoning inside one SQLite file," and it connects to Claude Code, Codex, DeepSeek Harness and Obsidian alike

URL: https://github.com/liliang-cn/cortexdb ｜ ★478 ｜ MIT ｜ Go

What happened

8 commits in the window (11-09 into 11-10), with the main line being consecutive v2.148.1 / v2.148.2 releases. The README states the positioning in one sentence: "AI memory and a knowledge graph in one SQLite file. Pure Go, no service to run, works without an embedding model."

• ⭐⭐ "Works without an embedding model" is an engineering choice that gets underrated. No embedding model means no dependency on any embedding service, no cost, no GPU — and retrieval is deterministic (not "similar" but "matched"). For a memory layer that AI agents will use, the uncertainty that semantic similarity introduces is sometimes a burden rather than a feature.
• ⭐⭐ Its three memory mechanisms are layered: the README describes the plugin giving Claude Code and Codex a global brain at ~/.cortexdb/cortexdb.db, with /remember, /recall and an automatic recall hook; "a session starts with an index of what the brain knows about its project, an agent about to open a file is told what happened to it before" — an agent about to open a file is told what happened to that file before, before it acts. One commit draws this boundary more finely: chore(release): v2.148.2 — a background task finishing no longer triggers a recall together with fix(recall): don't recall for a background task's notification — a background task finishing no longer triggers a recall, because that is not a person asking a question.
• ⭐⭐⭐ The ontology layer is the part most worth my attention: three consecutive in-window commits all touch it — feat(ontology): an object type's aliases resolve on write and on read (an object type's aliases resolve on both write and read), fix(ontology): activating a vocabulary moves no name-keyed entity (activating a vocabulary moves no name-keyed entity), and feat(liveview): every client's recall reaches the open page as it happens (every client's recall reaches the open page as it happens). "Aliases resolve on write and on read" means different names for the same thing are the same thing inside the system.
• ⭐⭐ "Planned recall" is the most product-like piece in this issue: the README says "Before the brain is searched, haiku turns each prompt into keywords in Chinese and English, aliases, entity names and a retrieval mode. A bare 'ok' or 'go ahead' searches nothing." — "ok" or "go ahead" searches nothing; the band above the prompt shows what was recalled, and you can expand it to see the plan and every hit. The hide lasts until the next recall, and /cortexdb-show brings a hidden one back. This turns "why did the agent think of that" from a black box into a visible plan.
• ⭐⭐⭐ The integration surface is what concerns me most: the README's install table lists Claude Code (/plugin marketplace add liliang-cn/cortexdb), Codex, DeepSeek Harness (dsh plugin --profile web add "github:liliang-cn/cortexdb#semver:^2&path:/plugins/dsh-cortexdb-memory"), Obsidian (unzip cortexdb-obsidian.zip into <vault>/.obsidian/plugins/), a shared-brain server (cortexdb-grpc), and Rust / Python / Node clients. "Point several agents or machines at one cortexdb-grpc and they share the same memory and graph."
• ⭐ The privacy boundary is written into the usage instructions: "a session's durable facts are captured with <private> text and credentials kept out" — text marked <private> is captured, while credential-type information is excluded.
• ⭐ There is a self-diagnostic tool: cortexdb-mcp --doctor --self-test (v2.119.0+), so you can check a broken install or unreachable brain before hitting a wall.

Why it matters

• ⭐⭐⭐ It supports DeepSeek Harness and Obsidian at the same time — and I use both of them locally. I have a self-built personal knowledge base (an Obsidian vault), and I have been using dsh for native agent development. "Agent memory + Obsidian knowledge graph + dsh" are three things that currently have nothing to do with each other on my machine, and this project wires all three into one SQLite file. This is the closest I have come to "the thing I wanted already exists."
• ⭐⭐⭐ "Ontology constraints" are exactly the missing piece in my GRPM report system, and the shape it offers is more precise than anything I had imagined. "Aliases resolve on write and on read" — mapped onto my case: "omega-3," "Omega 3," "eicosapentaenoic acid" and "EPA+DHA" must all point to one single record, otherwise a judgement about the same SNP gets counted twice and the report ends up containing two mutually contradictory sets of conclusions. And "activating a vocabulary moves no name-keyed entity" is the more important half: it guarantees that updating the terminology system does not silently rewrite historical conclusions. This is the same problem I framed in the 11-09 issue as "add a last-validated timestamp and a target-exists flag to every rule" — two solutions to one problem: one tags the rules, the other makes the data structure itself incapable of drifting.
• ⭐⭐ "No embedding model" treats a performance and cost problem I actually have in the 4P platform. My platform is a Flask + SQLite single-machine deployment, so if the memory layer depends on an embedding model, that means either running another model service or paying an API latency and cost on every memory retrieval. Deterministic recall with zero extra dependencies is a choice that removes an entire line of operations for someone working eight hours a week.
• ⭐⭐ "A background task finishing no longer triggers a recall" is the correct answer to the state-bleed bug I recorded in the 11-09 issue. My conclusion there was "go back and audit global state"; what cortexdb offers is a finer answer: not auditing state, but adding a precondition to recall — if no person is asking, do not recall. This rule is directly usable.
• ⭐⭐ "'ok' or 'go ahead' does not trigger a search" looks minor but is extremely practical. A large share of my publishing workflow is back-and-forth consisting of exactly "continue," "next" and "approved" — and if every such reply triggered a full retrieval and recall, both tokens and latency would be pure waste. And behind it sits a more general principle: the trigger for recall should be "this input carries new information," not "someone sent a message."
• ⭐⭐ "A visible recall plan, with every hit expandable" is what AI explainability looks like at the memory layer. In the 11-08 issue I recorded assay's four-level declarations (verified / self_reported / inferred / absent), whose essence is letting the reader know where a conclusion came from and how strong it is. If "why the agent thought of that" is not visible, the memory layer becomes an unauditable black box — and I already confirmed in the 11-09 issue, via bmlib and mTOR Atlas, that unauditable conclusions cannot support evidence-based content.
• ⭐ "<private> marking plus credential exclusion" is a privacy-by-default for the memory layer. This points the same way as the "token × person × category" triple authorization and machine-readable notice disclaimer I recorded for OwnHealth in the 11-08 issue: sensitive information should be excluded by default through architecture, rather than relying on every call site to be careful.
• ⭐ MIT licensed and commercially usable; pure Go, a single binary, no service to run — deployment cost is essentially zero.

5. eunomia-bpf/bpf-benchmark: performance benchmarks for AI agents at the eBPF level — and it treats "reproducible artifact evaluation of a paper" as a formal engineering discipline

URL: https://github.com/eunomia-bpf/bpf-benchmark ｜ ★26 ｜ MIT ｜ C / Lean 4 / LLVM

What happened

685 commits in the window (running continuously from 11-09 into 11-10), the highest commit count of any project this issue, with the main line being the release of the ATC 2026 artifact evaluation (atc26-ae-1). The README states the positioning in one sentence: "AI Agent eBPF optimization benchmark and framework."

• ⭐⭐⭐ It does something I had not realized could be done "formally": turn an already-accepted ACM ATC '26 paper into an artifact that third parties can independently evaluate. The README says **"Artifact evaluation (ATC 2026): evaluator instructions for the accepted paper BPF-Ext: Safely Extending the eBPF Compilation Pipeline with Native Operations live in docs/atc26-artifact-evaluation.md," and "Zenodo holds the immutable archival backup" (DOI 10.5281/zenodo.22907396) — the paper itself lives elsewhere; the repository holds the evaluation instructions, and the archived artifact lives immutably on Zenodo.**
• ⭐⭐ Every part of the paper has an explicit home in the repository, as the README's mapping table shows: BPF-Ext kernel support (verifier lowering and restore, x86-64 and arm64 JIT) in a branch of vendor/linux-framework; Kinsn operations in the kernel module directory; the compile-time recognizer and bytecode optimizer in a separate LLVM branch; "Lean 4 proofs that each operation's native code matches its proof sequence" in kinsn/lean/; microbenchmarks (12 derived from production programs, 15 synthetic, plus 2 baselines) in micro/programs/; and the paper's data and figures archived separately.
• ⭐⭐ The acceptance criteria for the artifact evaluation are written as a checkable list: the README lists what this tag includes — "complete no-VM static and formal validation paths" (complete static and formal validation paths requiring no VM), "hash-bound formal proof evidence" (hash-bound formal proof evidence), and "fresh successful Katran KVM smoke evidence." "Hash-bound" is the key phrase: proof evidence bound to a hash, so swapped evidence is detectable.
• ⭐⭐⭐ The in-window commits show exactly how much work evaluating a paper artifact actually is: Publish complete helper-call native payloads for four application sources (publishing complete helper-call native payloads for four application sources), Record the prepared helper-call image and frozen workload identities (recording the prepared image and frozen workload identities), Separate large and small B compile pools in the grouped resident census, Run the grouped resident census with four three-CPU workers, Restore the concurrent census change preserved by the application result publication, Identify the expanded probe-read path in the Tetragon historical installation drop, Record Tetragon and OTel completed requests with the historical installation drop. "Frozen workload identities" is the precondition for comparability.
• ⭐⭐ Its measurement target is the eBPF overhead of AI agents — in other words, when an agent is asked to monitor and optimize system call paths, this benchmark measures exactly what that costs.
• ⭐ The accompanying documentation is written for evaluators, not for readers — docs/atc26-artifact-evaluation.md is the entry point, and the README explicitly says "Start with this GitHub guide."

Why it matters

• ⭐⭐⭐ "Turning an accepted paper into an artifact that third parties can independently evaluate" is itself more worth remembering than the project. In the 11-08 issue I recorded bmlib's rule that every part of a PICO must be supported by the paper's own quoted text, and in the 11-09 issue I recorded mTOR Atlas's Zenodo DOI and evidence grading — both issues were about evidence you can turn back and look at. This issue pushes it to the limit: rather than grading conclusions, it makes the entire research process into a set of artifacts that others can independently run and judge. For my GRPM report credibility this is a complete path: data (immutable archival on Zenodo) → decision rules (a grading scheme) → artifact (reproducible evaluation instructions).
• ⭐⭐⭐ "Hash-bound formal proof evidence" is an engineering specification I can lift directly. If the data and conclusions cited in every evidence-based article on my WeChat account were bound to a hash and archived on Zenodo, then "which version of the data does this article cite" would remain permanently checkable. That is far stronger than writing "data current as of November 2026" at the end. Concretely for my 4P platform: every input-data snapshot behind an intervention report should carry a hash traceable back to the original version.
• ⭐⭐⭐ "Frozen workload identities" is the precondition for comparability, and it fixes a mistake I keep making. When I compare content performance, I often say "this version is better than the last" — but if the two versions do not share identical inputs, parameters and evaluation criteria, the comparison is invalid. Frozen workload identities means: fix the subject under test, number it, freeze it, then run. The same rule should govern my WeChat A/B tests and my platform's before/after comparisons.
• ⭐⭐ "Complete no-VM static and formal validation paths" means the validation path itself was designed, rather than "it ran, so it passed." In the 11-08 issue I recorded lights-out's test-proof gate — "a new test has to fail on the baseline." This issue is the academic version of the same idea: the validation path must be independent of the thing being validated.**
• ⭐⭐ "Evaluator instructions" and "reader documentation" written separately is a documentation layering I should learn. My WeChat articles are written for readers; but if I want peers to be able to verify the effectiveness of my intervention reports, I need a separate document written specifically for evaluators — mixed together, neither audience can read it properly.
• ⭐ It measures "what it costs for an agent to do system-level monitoring and optimization" — and that perspective reminds me of something: the more capable the agent, the more infrastructure bills need to be measured. Every model call in my 4P platform is a cost, and to this day I have no benchmark for "how much does a given workflow cost." Building benchmarks matters exactly as much as being benchmarked.
• ⚠️ A licensing and threshold caveat: this project is MIT and freely usable; but the kernel portion, the LLVM branch and the Lean 4 proofs are spread across multiple repositories and branches — fully reproducing it means pulling each one in per the README's mapping table, which is real engineering effort, not a clone away. I should treat it as a methodological reference rather than a component I can depend on directly.

2. Category roundup

① AI Coding / programming 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 systems are now being required to be independently verifiable, and this issue pushes verification to three depths that have never been touched before: artifact level, hash level and blind-review level. bpf-benchmark turns an already-accepted ACM ATC '26 paper into an artifact that third parties can independently evaluate, and requires proof evidence to be hash-bound with workloads frozen by identity; dsh-medical-anonymizer has the review model not know the detection results and requires disagreements to be escalated to a human rather than settled by internal model voting; cortexdb lays the recall plan and every single hit out in the open for inspection. Three projects with completely non-overlapping technology stacks each independently did the same thing: replace "I say I am right" with "an uninformed third party judges." This is the fourth stage of the thread I recorded across the 11-08 issue (assay: evidence packs recomputable offline), the 11-09 issue (bmlib: every part of a PICO supported by the paper's own text) and mTOR Atlas (evidence graded by study design): the earlier issues pushed the requirement down into "the structure of evidence," and this issue pushes it down into "the independence of verification." Concretely for me: every self-check in my 4P platform today is done by the same model inside the same context, which structurally makes it incapable of finding its own systematic errors — "blind review" is the one term I most need to take away from this issue.

The second thread, and the one that stings most for how I personally work: this issue produced three projects that treat "knowledge rots" as an engineering fact, and each gives a concrete form to that rot. cortexdb's ontology layer stipulates that "activating a vocabulary moves no name-keyed entity" — a terminology upgrade cannot silently rewrite historical conclusions; bpf-benchmark stipulates that the subject under test must carry frozen identities, otherwise a comparison is invalid; dsh-medical-anonymizer stipulates that unresolved items go to manual review rather than being silently accepted. All three share a point: they each refuse to let a default state quietly change a conclusion. My situation is precisely the opposite: my WeChat article archive, GRPM's SNP decision rules, the 4P platform's intervention-plan templates and the prompts in my expert packages all keep growing, and none of them has ever been marked "outdated," nor has any been marked "the conditions under which it applies have changed." The thing to do right away is still the same one, but this year it can be done harder: add three fields to every rule entering the content and report production chain — "last validated at," "does the target still exist," and "alias set" — then let a weekly task pick out what has gone stale. The third field is what cortexdb taught me this issue: "omega-3" and "EPA+DHA" have to be one single record in the system, otherwise my report will carry two mutually contradictory sets of conclusions.

The third thread: licensing now shows a set of samples I should watch closely — "expressing a business model through license terms" is becoming the norm, and it is starting to stratify. verifywise swapped BSL 1.1 for a custom VCEL 1.0 (free for personal use, schools, public sector bodies and non-commercial research; companies may evaluate free for 60 days, after which commercial use requires a separate license); kody-hq uses FSL-1.1-ALv2 (source available, but it becomes non-open-source at a certain point); margince and bike4mind use BUSL 1.1; and saltylvn/dialed-kitchen and marcnester/glycofy-api are simply proprietary. These five samples fall into three tiers: genuinely open source (MIT/Apache, directly usable commercially), source-available but not open source (BUSL/FSL, limited by time or scenario), and not open at all (proprietary). For a one-person company these three tiers mean three different things: the third tier is entirely off the table (you cannot even read it); the second tier can be read and studied for design, but must never become a dependency of my product; only the first tier is a real selection candidate. Of the 104 entries this issue, MIT and Apache-2.0 together account for 63 (61%), and the 6 AGPL-3.0 and 3 GPL-3.0 entries are readable but not copyable, the 2 PolyForm entries forbid even commercial use, and the 20 unstated ones must be checked — this three-tier list should go straight into the first line of my selection document, and I should read that line before doing anything else.

The fourth thread: an architectural signal I had underestimated — the agent memory layer is moving back from "vector similarity" toward "deterministic graphs." cortexdb states plainly "works without an embedding model," putting the knowledge graph, ontology constraints and traceable reasoning into one SQLite file; openaugi takes the same road (one SQLite file, one MCP server, turning a personal knowledge base into a searchable, traversable graph); uteke is a single offline Rust binary, with recall@5 of 98.2% on LongMemEval-S. Three independent choices of "no embedding model," all pointing at the same judgement: the uncertainty that semantic similarity introduces is a burden rather than a feature in scenarios that require reproducibility and auditability. This has a direct cost implication for me — my 4P platform is a single-machine Flask + SQLite deployment, so if the memory layer depends on an embedding model, that means either running another model service or paying an API latency and cost on every memory retrieval. And more valuable than that is the recall rule that comes attached: "'ok' or 'go ahead' does not trigger a search," and "a background task finishing no longer triggers a recall" — together these amount to a rule I can write straight into my pipeline: the trigger for recall should be "this input carries new information," not "someone sent a message."

The fifth thread, a direct note to Gordon: the thing most worth taking away from this issue is not any single project, but four assertions I could act on tonight. First, astryx's "components composable at any level, not locked behind a closed top-level API" — this is the engineering form of the property "safely modifiable by an agent," and for a one-person company, maintainability equals agent-maintainability. Second, astryx writing layout as a verifiable number (680px for Markdown body copy) and reporting test failures as named scenarios rather than line numbers — this supplies the other half of the test-proof gate I recorded in the 11-08 issue: it must not only go red, it must go red in a way people can read. Third, squad's "align spec, docs and matrix with the code + regression guards" — the four things I listed for myself (evidence-type labels, source-text location ranges, rule validation timestamps, staleness scanning) are currently mere conventions, and conventions rot without guards; squad's approach is to add a test that goes red to adjudicate who is right. Fourth, bpf-benchmark's "hash-bound evidence + frozen workload identities + a separate document for evaluators" — these three correspond to the complete path for GRPM report credibility: archived data, the precondition for comparison, and evaluation instructions a peer can run independently. Concretely, only five things need doing: ① three fields on every rule (validation time, target existence, alias set); ② key layout parameters written as constants; ③ test failures reported as named scenarios; ④ a hash on every intervention report's input snapshot; ⑤ content specs paired with a test that goes red. None of the five requires a new framework — just five fields, a few constants and one scheduled task.

4. Repo index

https://github.com/meta/astryx
https://github.com/github/squad
https://github.com/e2b-dev/runtime
https://github.com/elvisun/newsjack
https://github.com/okou-ai/okou
https://github.com/dondai44423/donsetch
https://github.com/kody-hq/kody
https://github.com/josssphzhou/poki
https://github.com/reacher-z/awesome-cua
https://github.com/askalf/dario
https://github.com/ikalus1988/misakanet
https://github.com/liliang-cn/cortexdb
https://github.com/nicosuave/memex
https://github.com/yangheng95/opencorvus
https://github.com/codecoradev/uteke
https://github.com/vstorm-co/agenticos
https://github.com/openjiuwen-ai/agent-studio
https://github.com/fullsend-ai/fullsend
https://github.com/bitsofchris/openaugi
https://github.com/awebai/aweb
https://github.com/sleep2agi/agent-network
https://github.com/poe-platform/poe-code
https://github.com/bike4mind/bike4mind
https://github.com/hivecommons/hive
https://github.com/flisk-sh/flisk
https://github.com/vite-hub/vitehub
https://github.com/eunomia-bpf/bpf-benchmark
https://github.com/margince/margince
https://github.com/constellation-works/orbit
https://github.com/verifywise-ai/verifywise
https://github.com/kaapana/kaapana
https://github.com/abinauv/dental-erp
https://github.com/wld007/dsh-medical-anonymizer
https://github.com/ehojune/bioinfo-team-3d
https://github.com/yao-care/jptxgnn
https://github.com/yao-care/nztxgnn
https://github.com/yao-care/notxgnn
https://github.com/pmanko/openclinai.org
https://github.com/jagnyesh/researchflow
https://github.com/jjjy9/medix-agent-swarm
https://github.com/dnarram/clinical-research-compliance-assistant
https://github.com/alaskantuna/catatmd
https://github.com/bmartinez-stgo/clinical-ai-platform
https://github.com/healthkey-ai/cdew
https://github.com/kienhaminh/triadcare
https://github.com/hamzacakmakk/med-os
https://github.com/timothywisdom/rag-medical-triage-demo
https://github.com/emranyaseen-alsabry/brain-tumor-mri-classification
https://github.com/arjunafransesco/cardiovascular-disease-prognosis
https://github.com/yuhi113/iron-pump-log
https://github.com/01helfy/fit-forge-ops
https://github.com/merran-app/merran
https://github.com/pivisyyy/pivis-health
https://github.com/cliftonz/tandoor-recipe-mcp
https://github.com/orellbuehler/bissbilanz
https://github.com/quantcli/crono-export-cli
https://github.com/dravr-ai/dravr-platform
https://github.com/saltylvn/wellness-tracker
https://github.com/saltylvn/dialed-kitchen
https://github.com/jmuci/chefai
https://github.com/mariomounir1/aura
https://github.com/ark07yad/nutritrack
https://github.com/cyoren/datalyst
https://github.com/chariot-ventures/dietary-supplement-analysis
https://github.com/zeroindex-x636a06/intake
https://github.com/bouadeikheireddine/ascendlab
https://github.com/intellifit/food_link
https://github.com/karthik-v-kumar/clinical-trial-delta
https://github.com/thcborges/dieta-ai
https://github.com/nassim-assassi/protein-source-helper
https://github.com/supportlik/victus
https://github.com/bikash-20/nutrivision-ai
https://github.com/d96moe/ha-nutrition
https://github.com/pete0585/functional-medicine-directory
https://github.com/sabian98/bender
https://github.com/marcnester/glycofy-api
https://github.com/alexcho783/evidence-desk
https://github.com/nikossakell/pyramid
https://github.com/mdaminsadik/nutriai
https://github.com/yansecos/nuragut-2026-aigeo-benchmarks
https://github.com/milvus-io/milvus
https://github.com/tencent/ncnn
https://github.com/huggingface/peft
https://github.com/google/gvisor
https://github.com/firecrawl/firecrawl-mcp-server
https://github.com/volcano-sh/volcano
https://github.com/unslothai/notebooks
https://github.com/pytorch/executorch
https://github.com/michaelfeil/infinity
https://github.com/qualcomm/aimet
https://github.com/syv-ai/hyperqwen
https://github.com/matrixorigin/matrixone
https://github.com/sgl-project/sglang-omni
https://github.com/1catai/1cat-vllm
https://github.com/carverauto/serviceradar
https://github.com/oborchers/fast_sentence_embeddings
https://github.com/zolotukhin/zinc
https://github.com/lablup/mlxcel
https://github.com/nvidia/tensorrt-model-connect
https://github.com/leenhawk/gproxy
https://github.com/amd-agi/hyperloom
https://github.com/pie-project/pie
https://github.com/joakimpalm-zen/xyntetik-runner
https://github.com/Bojieli/opentallas