DEV Community: 十方空烬 · Ember ☄️

100% annotation agreement can mean one labelled record out of twelve

十方空烬 · Ember ☄️ — Wed, 11 Nov 2026 05:42:43 +0000

A single percentage can make two annotation files look more complete than they are. Suppose you have two JSON files that both label the same texts, and a short script reports 100% agreement. The bundled partial-agreement example constructs exactly this case: only one of twelve records is labelled by both sides, and that one record matches, so conditional agreement is 100% while both-labelled coverage is 1/12. The percentage says nothing about the state of the other eleven records.

Annotation, checkpoints, and agreement

Annotation means assigning a text one label from a small set. A checkpoint is the annotation tool's JSON snapshot: an ordered record list plus a state for each record. Given two checkpoints that cover the same records, a reviewer first wants the places where they disagree, then the places where someone has not finished.

Conditional agreement counts only records both sides labelled: same labels divided by both-labelled records. The default example lays out the boundaries of that number. Four records are labelled by both sides, two of those match, agreement is 50%, and coverage is about 33.3%. The six comparison states contain two records each: same_label, different_label, both_abstained, one_abstained, both_unlabelled, and one_unlabelled.

When neither side labelled anything, the metric has no denominator. The no-labels example has zero both-labelled records; JSON stores label_agreement as null, and the page displays N/A, not 0%.

My tool first verifies that both checkpoints carry the same record list, taxonomy, and order. A missing record, changed text, different group, or reordered taxonomy rejects the pair. The tool does not compare only the overlapping records, join after normalizing text, or silently remap labels. An unknown group stays null instead of gaining an invented group.

This screenshot is from the actual running Hugging Face page with bundled synthetic data. It shows 12 records, 4 labelled by both roles, 50% conditional agreement, and 2/4 same labels. Agreement is not accuracy, and A/B are not verified independent people. The pinned method notes and the live Space provide the same details.

same_label is not a claim about whole files

A matching label means one record has the same label state in both annotations. The partial-agreement pair uses two checkpoints with the same content digest, so identical_checkpoint is true, yet both-labelled coverage is still one record, item-01. The default pair uses different A and B files; item-01 and item-07 have matching labels and count as same_label anyway. A record-level match cannot grow into a claim that the two complete files are the same, and it cannot represent the whole list as undisputed.

Each final decision starts unresolved, including records where both labels match. The page does not merge automatically and has no bulk accept. A reviewer can choose any existing label, abstain, or reopen a result as unresolved. A and B are file roles. They may come from the same person or the same checkpoint, and identical inputs receive an explicit warning. The original two annotation sets remain inside the exported review, while manual decisions live in a separate layer.

Each real change increments the revision; saving the identical decision again does not. The limit is 1e9. Undo restores the last 20 real changes without erasing provenance or rewriting the source text. Notes are limited to 2,000 UTF-16 code units and must contain valid Unicode scalar values. Emoji and other astral characters use two code units each. An unresolved decision must have an empty note.

What saving and restoring cost

The page keeps current work in browser memory only. There is no autosave, account, or server copy. Typing in the form is not recording. For that form edit to enter a snapshot, press Record decision first. Preparing a download captures the decisions recorded at that revision, and the page cannot confirm where the browser saved the file. Reopen as unresolved and Undo last change also update decisions and the revision when a real change occurs; they act on recorded state and do not carry unrecorded form text with them.

Restoring a review reads the complete file, recomputes digests, shows a preview, and then waits for explicit confirmation. A malformed file is rejected while active work stays in place. Swapping A and B invalidates the old binding. A saved review is self-contained and can restore the pair it originally carried after preview.

The snapshot contains both complete original checkpoints, all source text, both annotation sets, the comparison matrix, notes, and every manual decision, so I have to check its contents before sharing. Browser-local processing describes the computation path; it is not a privacy or secrecy guarantee. SHA-256 checks consistency and can be recalculated after content changes, so it does not authenticate the source. Duplicate JSON keys follow JSON.parse last-key semantics rather than strict duplicate-key rejection. BOM, invalid UTF-8, and invalid Unicode scalars are rejected.

Reproducing on the complete package

Start by copying the full public package into a fresh directory. cli.mjs loads review.mjs and vendor/queue.mjs, so two demo JSON files alone will not run. Once the complete package is in place, execute:

node cli.mjs demo-a.json demo-b.json NEW-review.json

The terminal prints the comparison object: total is 12, each of the six buckets is 2, both_labelled is 4, label_agreement is 0.5, both_labelled_coverage is 0.3333333333333333, and identical_checkpoint is false. Inside NEW-review.json, all 12 decisions are unresolved, including the demo items with matching labels, item-01 and item-07. Both source checkpoints are kept in full. The command creates its output exclusively, so it fails when NEW-review.json already exists instead of overwriting it.

Direct links: live Space, direct app, and pinned source commit aa1c89b.

Written by Renchao Wu. English original.

Keeping declared groups together in train, validation and test splits

十方空烬 · Ember ☄️ — Mon, 09 Nov 2026 07:39:35 +0000

Dividing a collection of records into train, validation and test is often done by shuffling rows and cutting twice. Shuffling by itself is not an independence test and does not make rows independent; it changes order. Whether records from one source should stay together depends on the evaluation unit the experimenter has already defined in the design, not on a property this tool can infer from the data. This piece describes a local browser planner that accepts caller-declared groups, keeps those groups whole while generating the three splits, and hands the exported result to the 0.1 command-line auditor from the same project.

What train, validation and test are for

Train data fits model parameters. Validation data compares and selects settings such as a learning rate or early stopping round. Test data stays for the final estimate of how the model behaves on new inputs. Sharing a source does not by itself prove that several records are statistically dependent. In some experiment designs, however, records written from one document, template family or synthetic family may share patterns, and the experimenter wants them to enter or leave a split together. Keeping the group whole then follows the design; it does not detect dependence and does not prove a test set is independent.

The caller supplies the group; credibility is a human call

Input is JSONL, and each record has exactly id, group, label and text. The group is the caller-declared indivisible string, such as a source document or template family. The planner checks only that the field exists, is a nonempty Unicode scalar string and respects the length limit. It does not judge whether a syntactically valid string really names a source. It also does not detect when someone fills group with a label or with each row id. A missing or invalid group is rejected; a valid but untrustworthy group is accepted because that judgment belongs to the experimenter. Whether a class label or per-row id is a suitable group is a design question, and this tool neither blesses the string nor bans the approach everywhere.

Identical field strings connect groups

After JSON parsing, text is a Unicode field string. Identical text means the parsed field values match as strings, not that raw JSONL line bytes or a whole-file digest match. When two groups contain a record with the same text value, the planner treats that equality as an edge and merges the groups with union-find. The entire connected component becomes one allocation unit, and transitivity follows the undirected graph: A and B share one identical text, B and C share another, so A, B and C land in the same unit. The constraint only places them in the same split. It says nothing about semantic identity and does not rewrite labels. When identical text carries different labels, the rows stay as they are and the report lists the conflict for a person to decide.

NFC plus Unicode-whitespace collapse searches for review candidates only after the three splits are complete. Rows whose raw text differs but whose normalized form agrees are listed as members. The tool does not merge them and does not say the texts mean the same thing. BOM U+FEFF is kept, and the whitespace set matches the 0.1 Python auditor.

The objective and one greedy pass

Let N be the total record count, L the distinct label count, and r_s the requested percentage divided by 100. For each split s, n_s is the row count assigned to s; n_label,s is the count for one label in s; N_label is that label's total. The objective is

E = sum_s (n_s - N*r_s)^2 / (N * max(1, N*r_s)) + (1/L) * sum_label sum_s (n_label,s - N_label*r_s)^2 / (N_label * max(1, N_label*r_s))

This balances both total rows and per-label coverage, keeping targets fractional. Units are ordered by decreasing row count, then by a seeded FNV-1a hash, then by the unit key's Unicode code points. Each step chooses the split whose delta increases E least, resolving exact ties as train, validation, test. When the number of remaining units equals the number of empty splits, later choices are restricted to those empty splits, so all three stay nonempty whenever at least three units exist. The nonempty rule can worsen balance, but it does not delete records to make percentages look better.

One greedy pass is not global optimisation. The public package keeps a 13-record, four-group counterexample with targets 34/33/33 and seed 71: greedy E is 0.1930676083, exhaustive best is 0.1775424801. A separate check over 100 constructed cases with 3 to 6 groups verified 1,244 considered deltas, and 30 greedy results were not optimal within that constructed set. That count says the effect is common there, but it is not a population failure-rate estimate and does not evaluate any model.

The synthetic sample

The default sample has 36 synthetic records, 12 declared groups and 3 labels. Two disjoint exact-text edges reduce the groups to 10 allocation units. Targets 80/10/10 imply 28.8, 3.6 and 3.6 ideal rows. Whole groups cannot produce fractional rows, so the actual plan is 30/3/3. Train is 3.33 percentage points above target, validation and test are each 1.67 below. All 36 records remain. The report has one normalized candidate and one exact-text label conflict, so the status is REVIEW. The 0.1 CLI also returns REVIEW for the normalized candidate; because it does not inspect labels, the label conflict is an additional planner warning.

The screenshot is the original Running-state snapshot from the public Space. It shows 36 records, 12 groups, 10 allocation units and REVIEW.

What is exported

The planner writes two files. report.json has no source text. It has configuration, target and actual counts, allocation units, every id/group/label/split assignment, warnings and the greedy trace. assigned-records.jsonl has full text with exactly the original auditor's fields: id, split, group and text. Labels remain in the report and join by unique id. Check both before sharing, because ids and labels can also be sensitive. Downloading assigned JSONL is the explicit action that saves all source texts.

Inputs and settings stay in the browser. Plan makes no network call and has no storage, telemetry, model invocation or training. Hosting still receives ordinary asset requests, so local computation does not make the exported files safe to share. A CLEAR status only means the listed bounded checks found no duplicate-id, group or exact-text crossing. It cannot prove statistical independence, semantic cleanliness, class representativeness or absence of upstream contamination.

Reproduce and inspect the exports

In a clean copy of the package, the first two commands generate a plan and run it through the unchanged 0.1 CLI. The third block reads the actual exported files and checks status, counts and fields:

node run_plan.mjs sample.jsonl --output fresh-plan --percentages 80,10,10 --seed 17
python3 cli/split_audit.py fresh-plan/assigned-records.jsonl --output fresh-audit
python3 - <<'PY'
import json, pathlib
from collections import Counter

report = json.loads(pathlib.Path('fresh-plan/report.json').read_text(encoding='utf-8'))
assert report['status'] == 'REVIEW'
assert (report['total_records'], report['declared_groups'], report['allocation_units']) == (36, 12, 10)
assert report['audit']['group_cross_split_sets'] == 0
assert report['audit']['exact_text_cross_split_sets'] == 0
assert len(report['audit']['normalized_candidates']) == 1
assert len(report['audit']['exact_text_label_conflicts']) == 1

rows = [json.loads(line) for line in pathlib.Path('fresh-plan/assigned-records.jsonl').read_text(encoding='utf-8').splitlines() if line.strip()]
assert len(rows) == 36
assert all(set(r) == {'id', 'split', 'group', 'text'} for r in rows)
print('assigned split counts:', Counter(r['split'] for r in rows))
for s in report['splits']:
    print(s['split'], 'actual', s['actual_records'], 'target', s['target_records'])
PY

In the public package this should print train actual 30 target 28.8, validation actual 3 target 3.6, and test actual 3 target 3.6, with split counts train 30, validation 3, test 3. Those are the expected outputs of the packaged example, not results from a new cloud experiment.

Public entry points and license

Public entry points: Space and static App. Code and sample are fixed at commit 51269bb7ae794008ea0002fcc7090babbfa8cb15. You can inspect planner.mjs and run_plan.mjs at that commit. Local preparation evidence was collected on 4 November 2026, and the public Space and App opened on 9 November 2026. The original code and 36-record sample are Apache-2.0, copyright 2026 Renchao Wu; that does not extend to external input data.

Originally published on widechaos.cn.

What an offline evidence finder guarantees about a quote

十方空烬 · Ember ☄️ — Sun, 08 Nov 2026 06:57:56 +0000

Two questions get run together. Did this sentence appear in my documents? And does this document support the claim? The first is decidable by a string slice, the second is not. Offline Evidence Finder, a static page I built, does only the first: lexical search over an editable English and Chinese collection, returning a source id, the exact quote, and the quote's UTF-16 start and end offsets inside source.text. It does not generate answers or judge whether a passage supports a factual claim.

Live at the Space and the standalone app, fixed commit d309763. The behavior below is from that commit.

A query that hits without answering

The sample has an unanswerable query, 今天火星咖啡价格. Of four unanswerable queries it is the only one that returns a hit (1/4), a single character 天 inside the unrelated excerpt router-zh.

Fixed development sample, not a new benchmark. The unanswerable query matches the single character 天 in an unrelated excerpt, score 1.597193.

Returning this hit is correct by design. The tool does lexical overlap, and lexical overlap promises nothing about answerability.

The hit's score differs between the two corpus revisions: 1.4588… and 1.5972…. Both revisions have 14 passages, df(天)=1 in both, and the same quote so the same dl. Only avgdl moved, from 116 to 134.64…. With idf = ln(1+(N-df+0.5)/(df+0.5)) = ln 10 constant and tf=1, the whole difference comes from avgdl in the length-normalization term. That is a recomputable instance of scores depending on the corpus.

The span is the re-checkable claim

The evidence bundle exports all current source texts plus one citation per hit, with source_id, start, end, the offset unit, and quote. What a reader can re-check for each citation is:

source.text.slice(start, end) === quote

UTF-16 because JS strings index in UTF-16 units, so charCodeAt and slice share one coordinate system. The cost is that the unit is not the glyph a reader sees. Passage splitting backs off only on surrogate pairs, not on combining marks (e plus U+0301) or ZWJ sequences, so a quote can cut through a grapheme. A 502-unit string can take the grapheme boundary at 499 under a 500 limit and satisfy both constraints at once; this implementation does not do grapheme protection, as a scope choice.

Readers can run the following on a downloaded bundle as an external re-check:

import { readFileSync } from 'node:fs';
const b = JSON.parse(readFileSync(process.argv[2], 'utf8'));
const byId = new Map(b.sources.map(s => [s.id, s.text]));
const seg = new Intl.Segmenter();
let ok = 0, split = 0;
for (const c of b.citations) {
  const t = byId.get(c.source_id);
  if (t.slice(c.start, c.end) !== c.quote) throw new Error('span mismatch: ' + c.id);
  ok++;
  const bounds = new Set([...seg.segment(t)].map(s => s.index));
  bounds.add(t.length);
  if (!bounds.has(c.start) || !bounds.has(c.end)) split++;
}
console.log({ citations: b.citations.length, sliceOk: ok, graphemeSplit: split });

This catches a location that is correct but splits a glyph. It cannot catch a passage that fails to support the conclusion.

Tokenization and scoring

Tokenization is NFC plus lowercasing, Latin, digit, and underscore runs as words, Han runs emit single characters plus adjacent bigrams, query terms deduplicated. No stemming, stop words, embeddings, or translation. Titles are displayed but not indexed; I have not measured what indexing titles would change.

Scoring is fixed-parameter BM25, k1=1.2 and b=0.75. N and df count passages with zero-token passages in N, dl is the number of emitted tokens, a positive score is required, and the UI returns at most five hits (search() itself accepts 1 through 20). Ties sort by source id as Unicode code points then start offset, so tie order reproduces across locales. The IDF expression and defaults were checked against Lucene's BM25Similarity docs; no parity is claimed.

What the sample measures

Eighteen hand-written development queries split into 14 known-source lookups and 4 unanswerable examples. The extraction bug is a different layer: sample-card paragraph extraction (make_sample.py), not the CR/LF passage splitting in search.mjs. The first version pulled English headings in because of a leading newline, giving 12/14 Recall@1 and 13/14 Recall@3, then 14/14 after the fix. Queries and ranking parameters were unchanged, but the corrected corpus came after seeing the first result, so it is not held-out. The first corpus and full scores remain in sample-history-v0/.

The sample is 14 excerpts from seven locally accepted candidate cards, not a claim that those projects are public. What this tool verifies down to the character is a quote's position. Semantic support is not in its output.

Code is licensed under Apache-2.0. By Renchao Wu.

Originally published on widechaos.cn.

Open Source Radar · 2026-11-06: Browser tools for agents move to the command line

十方空烬 · Ember ☄️ — Fri, 06 Nov 2026 06:51:17 +0000

By Renchao Wu. Originally published on widechaos.cn.

These five projects come from the GitHub Trending entry point captured on 2026-11-06, plus keyword search over repositories. After de-duplication the run produced 12 candidates, ranked by relevance to the work I am doing, then distinctiveness, then heat. Every star count and judgment below rests on that day's GitHub API snapshot, each project's README, its release records and recent commits. I also read the CompanyOS LICENSE in full, LocalStack's own announcement about its community edition, and the Playwright MCP README as a comparison point. None of the five was installed or run.

1. vercel-labs/agent-browser ⭐ 46,003 · Rust

GitHub: https://github.com/vercel-labs/agent-browser

In one line: A browser reduced to one shell command per step for an AI agent, with each page returned as compact text carrying element references.

What it is: A native Rust CLI that works one step at a time. open loads a page, snapshot -i returns the interactive elements, each tagged with a reference such as @e1, click @e1 acts on it, and get url checks the result. The browser stays open between commands: the CLI sends each command to a background daemon that drives Chrome over the DevTools Protocol. Every --session gets its own daemon and browser, and by default a headless browser closes and its daemon exits after an hour without commands. The repository was created in January 2026, ships under Apache-2.0, and main is still moving today.

What stands out:

References expire, and a failed click fails loudly. A reference describes the page at the moment of the snapshot, so after navigation or a DOM change you must take a new one. When a target is covered, hidden, disabled or outside the viewport, the command returns an error. A consent banner covering the button counts as failure, so the agent has to dismiss it and retry. Silent success is harder to debug than failure, which matters for a tool built for agents.
The skill ships with the binary. agent-browser skills get core returns instructions matching the installed CLI; --ref loads one section, --full adds the complete command reference. The skill installed into an agent is only a thin stub telling the agent to read skills get core. Bundling the instructions with the installed binary can reduce version drift; it does not prove that every instruction matches runtime behavior.
One daemon per session. The hot path is a single short shell call, the documented sessions use separate processes and browsers, and an idle session cleans up after an hour, saving state first when persistence is configured.
Debugging sits at the same layer as acting. The command table includes console, errors, trace, profiler, vitals, a11y and react; diff, record and download provide comparison and capture-related commands; their presence does not establish deterministic replay.
Three ways in: direct CLI calls, an stdio MCP server via mcp, and batch or integration paths through webmcp, plugin and batch. The browser can be a local Chrome for Testing, the Lightpanda or Obscura engine, Mobile Safari in the iOS Simulator, or a cloud provider such as Browserbase or Browserless.

Compared with: Against Playwright's MCP server, the difference is the shape of the interface an agent gets: MCP tool calls on one side, a command line on the other. Playwright MCP's own README says coding agents increasingly favour CLI-based workflows exposed as skills over MCP, because CLI calls avoid loading large tool schemas and verbose accessibility trees and are more token-efficient; MCP stays relevant for exploratory loops that need persistent browser context and rich introspection. agent-browser sits on the CLI side and binds its skills to the binary version, and I found no equivalent mechanism in the Playwright MCP documentation.

Recent updates: v0.41.2 (2026-11-03) made skills loadable by section (skills get <name> --ref <ref>); it added a warning when a newer stable Chrome lists CVE fixes, without blocking commands; and it fixed two failures that interrupted long tasks, one where omitting or changing a timeout restarted the session and one where a bare open dropped configured profiles and relaunched Chrome with a temporary one.

Who it's for: People already driving a CLI-style coding agent who want that agent to open and read pages on its own. Two caveats: the default browser is a separately downloaded Chrome for Testing, and with a cloud browser provider the page renders on a third party's machines, where login state and billing follow that provider's terms; that boundary needs a look first.

My take: ⭐⭐⭐ It turns how an agent uses a browser from a tool call into a command line, and bundles skills with the executable to reduce documentation-version drift.

Checked: read the README, release records and recent commits, plus the Playwright MCP README for comparison; did not install it or drive a browser.

2. alibaba/zvec ⭐ 16,190 · C++

GitHub: https://github.com/alibaba/zvec

In one line: A vector database that lives inside the process, able to combine dense vectors, sparse vectors, full-text search and structured filters in a single query.

What it is: An in-process vector database from Alibaba, shaped like a SQLite for vector search: no separate database service is required, and data is stored in a local directory. The host application still needs configuration and operational controls. Indexes scale from memory to disk, with HNSW, IVF, DiskANN and RaBitQ available; official SDKs cover Python, Node.js, Go, Rust, Java and Dart/Flutter, and platforms run from Linux, macOS and Windows to Android and iOS. The repository was created in December 2025, ships under Apache-2.0, and has iterated to 0.8.0 within a year.

What stands out:

Embedded deployment with an exclusive writer. Several processes may read the same collection simultaneously, but writes are exclusive to one process. That decides the shapes it fits: desktop and edge applications are plausible uses; concurrent writers, tenant isolation and access control need separate design and verification.
Dense, sparse, full-text and filters share one schema. Sparse vectors and keyword full-text search can be pushed down together with structured filters, including LIKE and floating-point ranges, offering a documented route to hybrid retrieval in one engine. Fusion quality still needs evaluation on the intended data.
Durability comes from a write-ahead log. The project documents crash and power-failure durability through its WAL. I did not test recovery, storage behavior or durability settings. Index types scale from memory to disk depending on data size, but the README lists no switchable storage modes.
The trade-off is stated in the release notes. Version 0.8.0 added uniform UINT4 quantization, which avoids reconstructing scores point by point during a query; sharing one min/max range across all indexed points can increase quantization error and reduce recall. The project says so itself, which is more credible than a QPS chart alone.
Chinese full-text search works out of the box. The default Jieba dictionary and HMM model are embedded in the native library, so no dictionary path is needed. The same release removed global configuration entry points such as init(jieba_dict_dir=...), a breaking change that requires code edits on upgrade.

Compared with: Against service-based vector databases such as Milvus or Qdrant, the difference is the deployment shape and the failure surface; the index algorithms are common ground. A service adds a networked process and operational responsibilities. Multi-tenancy and scaling depend on the product and deployment; I did not compare those implementations here. zvec compiles the library into the process, avoiding a separate database server. Backups, upgrades, file access and crash recovery remain operational responsibilities. Whether that trade is worth it comes down to three things: write throughput and concurrent reads in practice, the quality of score fusion between full-text and vectors in hybrid queries, and the recall-versus-latency curve of the disk indexes at realistic data sizes. I measured none of them. The footnote in the README gives one configuration only, GIST 1M, L2 distance, INT8 quantization, HNSW on a 16-core ARM64 machine; the full methodology sits on the docs site's benchmark page, which I did not read, so those numbers do not generalise to other datasets.

Recent updates: v0.8.0 (2026-10-21) extended builds and wheels to Intel Mac and Windows ARM64 and DiskANN to Windows, Android and iOS; it lowered peak memory during IVF and DiskANN builds and merges; it added Turbo PQ with 4-bit FastScan, backed by SIMD distance kernels and precomputed residual tables for IVF; and it put HNSW, IVF and DiskANN on a shared page cache, with DiskANN falling back to direct I/O under cache pressure.

Who it's for: Cases where the data fits on one machine and writes do not run concurrently, such as desktop apps, command-line tools, edge devices and retrieval prototypes on a laptop. It is not the right fit for multiple writers, multi-tenancy or independent scaling. The repository lists Apache-2.0; inspect the applicable license and bundled dependencies for the intended use.

My take: ⭐⭐ It fills in the "vector database as SQLite" path and is honest about the trade-offs; the constraint to check before adopting is single-process writes.

Checked: read the README, the v0.8.0 release notes and recent commits; did not install it, build an index or run a benchmark.

3. ConardLi/garden-skills ⭐ 14,230 · JavaScript

GitHub: https://github.com/ConardLi/garden-skills

In one line: Six skill packs written to the SKILL.md format, covering code-rendered video, web design, image generation, long-form article layout and local knowledge retrieval.

What it is: A skill collection where each of the six skills is its own directory, installable together or alone: motion-showreel for code-rendered short motion pieces and product films, web-video-presentation for web video and decks, web-design-engineer for web design, gpt-image-2 for image generation, beautiful-article for turning any source into a laid-out article, and kb-retriever for local knowledge retrieval. Each ships a README, and some add on-demand reference docs, scripts and assets, which the README marks optional. Each is released by version and offers a pinned zip with a checksum. The compatibility table lists Claude Code, Claude.ai, Cursor, Codex CLI, Gemini CLI and OpenCode, all marked as tested.

What stands out:

A rendering pipeline with a documented determinism gate. The skill documentation says every output of motion-showreel (stills, contact sheets, three-direction boards, proxies and masters) comes from the same render(t) page. Motion blur, supersampling and film grain are render flags, not a second generation pass. Using one rendering path gives technical checks a shared target; I did not test repeatability across machines or versions.
Picture and sound share one timeline. Cuts, hits and sound effects land on the same numbers; music can come from a built-in zero-dependency synth or Tone.js with a sampled piano, or from the user's own track with beat and drop detection.
Technical acceptance is separated from taste. The skill specifies checks for size, frame rate, duration, frame count, black frames, loudness, true peak, loop seam and determinism, with subjective decisions returned to the user. Instructions alone do not establish that every host enforces those gates. The result can be restated and checked rather than argued from taste.
Three prescribed checkpoints, with decisions recorded item by item. beautiful-article runs source, plan, double confirmation, build, final review and repair, confirming article type, theme, layout, image strategy, cover and delivery format individually, with no silent defaults.
The retrieval instructions set a ceiling. kb-retriever reads layered data_structure.md files to navigate, then narrows candidates, then reads local windows, with at most five search rounds. PDF and Excel files must be learned before processing, using the bundled reference docs rather than trial and error.

Compared with: This review did not establish how representative other skill collections are. This one is six process packs with release flows and acceptance criteria. Each skill is released separately (motion-showreel 0.1.0, web-design-engineer 1.3.0, web-video-presentation 1.2.2, kb-retriever 1.0.1); technical acceptance and aesthetic judgment are split inside each skill; and one install path uses a pinned zip with a SHA-256 checksum for unattended setups. The cost is scale: six skills is far narrower than an aggregator.

Recent updates: motion-showreel v0.1.0 (2026-10-11) shipped with showreels, UI morphs, kinetic typography and beat-synced music; its QA workflow gained per-shot motion analysis, text-framing checks, and grid and heat-map measurement tools for reference video; builds gained a determinism gate, loop-seam validation and layer-mode checks. Main was still adding render context through 2026-10-25, passing frameTime and fps into rendering so text does not blend across subframes at cuts, though that path is optional and only active when RENDER_CONTEXT is enabled.

Who it's for: People doing content production with agents that support SKILL.md, such as Claude Code or Cursor. Two things to watch: the skills call external services, with narration in motion-showreel going through Gemini or MiniMax TTS and gpt-image-2 using GPT Image 2 or OpenAI-compatible image APIs, so which provider you use, whose key it takes and how billing works depend on what you connect; and "tested" is the author's claim across six runtimes, which needs re-checking on any other agent.

My take: ⭐⭐ The six skills are the vehicle; what is worth reading is the discipline of versions, acceptance criteria and checkpoints.

Checked: read the README, each skill's release notes and recent commits; installed no skill and rendered no video.

4. floci-io/floci ⭐ 30,514 · Java

GitHub: https://github.com/floci-io/floci

In one line: A local emulator for selected AWS APIs, with a documented Compose setup and shared endpoint on port 4566.

What it is: A local AWS emulator that keeps LocalStack's port convention, which can simplify endpoint changes. Port compatibility alone does not establish application-level migration compatibility. It implements services in three groups: stateless ones (SSM, SQS, SNS, IAM, KMS, EventBridge, Step Functions, CloudFormation, API Gateway, Bedrock Runtime and others) run in-process; stateful ones (S3, DynamoDB and DynamoDB Streams) use its own storage backends; container services (Lambda, RDS, ElastiCache, Neptune, ECS, EC2, MSK, EKS, OpenSearch, CodeBuild, Managed Flink) run real Docker containers. Athena runs through a DuckDB sidecar. MIT licensed, created in February 2026.

What stands out:

No account, no token, no feature gates. This is the most direct difference, stated in the first line of the project; credentials can be any non-empty value unless stricter per-service auth checks are explicitly enabled.
Container-backed execution for selected services. Selected services use Docker containers, which exposes some runtime behavior. It does not establish full AWS error semantics, IAM equivalence or coverage for every configuration.
Four storage backends. In-memory, persistent, hybrid and write-ahead log, chosen by durability needs; multi-account isolation is handled separately.
Images and native binaries. The README says each release also ships a standalone floci-aws binary for Linux, macOS and Windows. The asset lists for 2.4.0, 2.3.0 and 2.2.0 that I fetched are empty, so the actual download path is unconfirmed and this is not a verified install route yet.
The console is replaceable. /_floci/ui pulls a sidecar container for browsing resources; any image implementing the console contract can be attached, provided it listens on PORT, serves GET /api/health and talks to AWS_ENDPOINT_URL.

Compared with: The difference comes from a real shift in the ecosystem. LocalStack's own announcement states that from March 2026 Community and Pro unify into a single image, running it requires an account and an auth token, pinned prior tags run without auth but opt out of future service and security updates, and the free tier is for non-commercial use. floci documents an MIT-licensed, token-free alternative; API fidelity and dependency requirements still need evaluation. The README's comparison table also cites start-up around 24 ms, idle memory around 13 MiB and an image near 90 MB; those are the project's own figures and I did not re-measure them. To decide whether it can replace a service, the relevant test is whether the APIs you actually call behave the same: SQS visibility timeouts, DynamoDB conditional writes, Lambda runtimes. Breadth of coverage is not fidelity.

Recent updates: 2.4.0 (2026-10-31) routed API Gateway v2 VPC link integrations to Cloud Map service instances; completed Auto Scaling support for DescribeTags, EnterStandby and ExitStandby plus suspended-process reasons; added a logically air-gapped backup vault; and filled in CloudFormation support for RDS cluster and instance AssociatedRoles and AWS::EC2::PrefixList.

Who it's for: Teams with AWS dependencies that need integration tests locally or in CI, especially commercial use, which LocalStack's free tier excludes. Two caveats: the console and container services need the Docker socket, so the CI runner's permission model has to be checked; and services with incomplete coverage need a fallback to real cloud or a mock.

My take: ⭐⭐⭐ Worth evaluating when its documented licensing and account model fit. Test the specific AWS calls and failure cases the application relies on.

Checked: read the README, the 2.4.0 release notes and recent commits, plus LocalStack's announcement about its community edition; started no container and ran no comparison test.

5. kortix-ai/CompanyOS ⭐ 20,387 · TypeScript

GitHub: https://github.com/kortix-ai/CompanyOS

In one line: An agent runtime that treats the company as an operating system, giving each session its own cloud computer, waking agents on events, and letting long jobs outlive a single context.

What it is: A cloud-native agent harness. You write agents on the open-source harness pi, and it deploys them and supplies what a single session cannot: always-on execution, event triggers, parallelism, long jobs across contexts, and shared team memory and permissions. Every agent, skill, rule and connector is a file in one git repository, declared by kortix.yaml. The repository was created in October 2024, in TypeScript.

What stands out:

Compute and state are separate. Each session runs on its own cloud computer, sleeps 15 to 20 minutes after the last turn, and wakes with its full history on the next message or event; state lives in the git repository, in Drive, in the session's /workspace and in the session record. The project describes compute suspension during idle periods and horizontal allocation across session machines. I did not verify billing, residual resources or capacity limits.
A full context is replaced, not summarised. When a context fills, the agent continues in a fresh one and searches the session's complete record for the exact lines it needs; the project's wording is that nothing is summarised. Keeping the full record available is a retrieval strategy; it does not prove that relevant details will be found or that a long-running job resumes correctly.
Events are filtered before any model runs. Schedules, signed webhooks, connector events, app events and merged change requests all start agents, with a filter in code dropping noise first. A session can subscribe to events from its own work, and an agent sets its own check-in before stopping.
A separate session decides completion. A goal is stated once in plain words, an agent owns it end to end and wakes itself on a schedule, a separate verifier session confirms it is done, and changes land through a change request a person approves.
One AI for a whole team. Teammates share the same agents, skills, memory and connectors, with roles, groups and per-resource permissions; connectors cover more than 3,000 apps plus MCP, OpenAPI, GraphQL and raw HTTP, and the README says connector credentials remain server-side. I did not audit credential handling or tool-mediated data exposure.

Compared with: It describes a particular multi-agent deployment design by treating a session as a compute unit with a lifecycle: its own cloud computer, sleep and wake, continuation across contexts, event-driven starts. The split from graph-orchestration frameworks shows up on long jobs: a graph is good at stringing together known steps, while this project describes goal ownership, scheduled continuation and a separate verifier session. That separation does not make verification independently reliable by itself. The README lists deployments including a research assistant at the Hong Kong Institute of AI for Science at City University of Hong Kong, fibre-route design at a US telecom infrastructure company, and an international executive search firm, all stated by the project.

Recent updates: v0.14.19 (2026-11-04) brought voice calls into sessions, so you can call a session's agent from the session or agent page with screen sharing while the chat keeps what was said (behind the voice_call flag); speech-to-text and text-to-speech go through the LLM gateway under the same budgets and access rules as model calls; Discord became a regular channel; and self-hosted sessions start from a project snapshot in bundled object storage. One availability fix: an invalid kortix.yaml no longer takes a project down, which keeps the last valid version and refuses the broken push.

Who it's for: Teams that want many agents running long jobs, with self-hosting and shared context and permissions. Check the licence first: the repository LICENSE is Elastic License 2.0, which forbids providing the software to third parties as a hosted or managed service where that service gives users access to a substantial set of its features, while the README calls the project open source throughout. I read the white-label licence text too. That text describes a no-fee arrangement with an exclusivity condition: Platinum supplies the listed sandboxes, volumes, runners, AI compute and inference. This is not a determination of eligibility or the complete obligations for a deployment. It also states that Kortix may end the agreement at any time with written notice, leaving up to 90 days to move existing customers, while termination for breach takes effect immediately with no transition period. Anyone planning to offer it as a service should read both texts rather than the README's wording.

My take: ⭐⭐ The architecture is worth reading, and "replace the context, search the full record" is an unusually honest answer for this class of system; the gap between the licence and the README's wording is the real barrier to adoption.

Checked: read the README, the v0.14.19 release notes, recent commits and the full LICENSE; deployed nothing and ran no session.

At a glance

Project	What it is	Most distinctive	Who it's for	Worth a deep look
agent-browser	Browser CLI for agents	Skills released with the binary	People running CLI-style coding agents	⭐⭐⭐
zvec	In-process vector database	Dense, sparse, full-text and filters in one query	Single-machine retrieval, no concurrent writes	⭐⭐
garden-skills	Six agent skill packs	Deterministic rendering, acceptance split from taste	Agent-driven content production	⭐⭐
floci	Local AWS emulator	No account or token, MIT, commercial use	Local and CI tests with AWS dependencies	⭐⭐⭐
CompanyOS	Multi-agent runtime	Per-session cloud computer plus independent verifier	Long-running agents, self-hosted	⭐⭐

Notes from this issue

The interface an agent gets for a browser is splitting in two, and the evidence comes from a competitor's own docs. Playwright MCP acknowledges that coding agents prefer CLI plus skills because it saves tokens, and leaves MCP for exploratory loops that need persistent context. agent-browser takes the CLI side and binds its skills to the binary. The thing to watch is whether instructions and the executable can drift apart.
Vector databases are swinging back to embedded, with a hard constraint. zvec puts dense, sparse, full-text and filtering inside one process and uses a WAL for durability, at the cost of single-process writes. The line in its release notes about shared min/max ranges increasing quantization error and reducing recall says more about the real trade-off than any QPS chart.
Skill packs are acquiring release discipline. Six skills with separate versions, pinned checksums, a prescribed technical acceptance list, taste left to the human, and retrieval capped at five rounds. That sits a level above a prompt collection because it admits that finishing and doing well are different things.
The local-cloud opening was vacated by the incumbent. LocalStack folded its community edition into a unified image that needs an account and a token, with the announcement describing a non-commercial free tier; floci offers a differently licensed, token-free option for evaluation. The test is plain: clean licence, low barrier, and fidelity you verify yourself.
Long jobs now compete on session lifecycle, and the licence needs saying plainly. A cloud computer per session, idle sleep, waking with history, replacing a full context and searching the record, completion confirmed by an independent verifier: these are runtime design, not model capability. On the other side, a README can say open source throughout while the LICENSE is Elastic License 2.0. Before adopting, read the LICENSE itself.

Open Source Radar · 2026-11-04: Agent frameworks separate kernels and capabilities

十方空烬 · Ember ☄️ — Thu, 05 Nov 2026 06:53:21 +0000

By Renchao Wu. Originally published on widechaos.cn.

This issue covers five projects drawn from one candidate pull on 2026-11-04: a pool of 95 entries, a de-duplication ledger of 313, and 12 candidates as the script's default output limit. The daily GitHub Trending fetch timed out during that pull (the script records it under errors); the weekly Trending entry point and topic searches did return results, and those two paths supplied the candidates. I picked five on three grounds: whether the approach can be borrowed by another system, whether it offers a distinctive mechanism, and only then heat. For each project I read the README, the release notes where a release exists, and recent commits. Nothing was installed or run, so nothing below is my own measured claim about performance, deployment or stability; where a deployment shape or speed change comes from the project's own docs, the text says so.

1. miuuyy/Octopus-SI-OS ⭐ 679 · Rust

GitHub: https://github.com/miuuyy/Octopus-SI-OS

In one line: An agent runtime rebuilt on operating-system lines: eight primitives in the kernel, models and tools outside it, and an agent that can rewrite its own interfaces and tools when policy allows.

What it is: A research-preview agent desktop system for macOS 14 and later. The repository was created on 2026-10-09 and had 679 stars and 73 forks by 11-04. The README and docs/architecture.md tell the same story: a kernel of roughly 45,000 lines of Rust, with Codex CLI moved in and running as one interface among many. The documentation describes a small set of primitives plus JSON descriptors for mounting capabilities. That design claim does not establish that every new capability requires no implementation work.

What stands out:

Eight primitives and no orchestrator. Interface (a typed port), Artifact (the only thing that crosses a boundary), Run (a durable execution record that parks and wakes on artifacts; it is data, not a process), Execution environment (a goal with a policy; environments nest and inner ones are narrower), Worker (a role plus a ceiling, not a program), Worker environment (the room where tools act), Policy (never stored, formed on each arrival), and Mark (recorded only after a verifier passes).
The kernel decodes nothing and pushes nothing. Resident interfaces such as providers, channels and tool rooms are each their own process reading their own movements; a worker is only a descriptor plus a policy ceiling, with no code. The provider interface builds what the model sees, and the room's door checks a tool against the grant before running it. One turn is a set of rows in a ledger.
A refusal is also a row. Blocked calls are recorded with a type instead of being dropped silently. This can make refusals available for audit, subject to what the implementation actually records.
Authority is formed per call. Policy is computed at each arrival, and because environments nest with narrower inner ones, tightening permissions means moving a task into a smaller environment rather than writing a second set of checks.
The system can build itself a sense. The README's example: a run needs to "see" and has no capability for it, so the system dispatches a coder run that writes a small camera driver, registers it as a new interface folder, and once a verifier passes, the descriptor is picked up live. The example describes reusing the registered interface on a later run; I did not test it or its verifier.
The limits are stated plainly. The README note says that for an ordinary coding task, Octopus today gives you nothing that Codex CLI does not already give you. The research question is whether an architecture that lets agents reshape their execution environment helps them take initiative.

Compared with: The usual approach is a loop with tools, memory, sub-agents and schedules bolted on, where capabilities arrive as hooks inside the loop. Octopus puts capabilities outside the kernel and mounts them through descriptors, so descriptors can expose capability definitions for inspection. That alone does not prove deterministic replay or safe live changes. Its own admission that it adds almost nothing for coding tasks is what separates it from yet another agent desktop shell. I did not read primary material on other self-evolving agent frameworks, so no mechanism-level comparison here.

Recent updates: The releases endpoint returns an empty list (snapshot taken 11-04), so it iterates on main. The five most recent commits all fall on 11-04; here are three that bear on the architecture: a memory capture refused by its verifier now settles as an ordinary diagnostic (02b9ac04); a model turn bridged through a signed-in Grok CLI (dd9d3e88); dropped "received requests" from the sentence on what does not constitute authority, on the owner's instruction (8935bc6c). Commit messages are full sentences explaining why, not what.

Who it's for: People studying how an agent runtime should draw its boundaries, on a Mac. Note the limits: macOS-only packaging instructions, Node 24 and stable Rust required, the documented Codex integration uses a ChatGPT account, and an ad-hoc signed, non-notarized bundle. MIT license.

My take: ⭐⭐⭐ Read the architecture doc; do not install it yet. Its value is that it rethinks permissions, audit and capability mounting from scratch.

Checked: read the README, docs/architecture.md, the releases snapshot and the five most recent commits; nothing installed.

2. agentscope-ai/agentscope-java ⭐ 6,237 · Java

GitHub: https://github.com/agentscope-ai/agentscope-java

In one line: A Java agent framework that documents event streams, permission gates, sandbox options and external session state.

What it is: The Java implementation of AgentScope, positioned in the README as production-ready, distributed and enterprise-grade. Version 2.0 reached GA in 2026-07; the repository dates from 2025-09-23 and had 6,237 stars and 1,562 forks. JDK 17 or newer is a hard requirement. Session state can sit in memory or a JSON file, and a multi-replica deployment needs it externalized to Redis, MySQL, PostgreSQL or object storage; the sandbox can run as a local subprocess or be switched to Docker, Kubernetes or the E2B cloud. Since 2026-08 there is also an AgentScope Service, a control plane and dashboard that declares compatibility with LangChain, ADK, Claude/Qoder and other external agents. v2.1.0-BETA1 ships Docker images, Compose and Helm packages, a CLI and a Runtime Host.

What stands out:

32 typed events. The event stream is a protocol for live rendering and human-in-the-loop, not a log: tool results arrive as ToolResultTextDeltaEvent, ToolResultDataDeltaEvent and ToolResultEndEvent with metadata carried through, and a pluggable AgentProtocolEventBus, introduced in v2.0.3, handles SSE.
The permission gate is part of the framework. Tool calls are allow, require user approval, or deny; the documentation places this decision in the framework. I did not exercise approval or bypass paths.
Middleware is an AOP hook. The reasoning-acting loop can be intercepted and extended without forking the framework, and a returnDirect tool result can short-circuit the loop.
Control reaches the single run. v2.0.4 introduced AgentRun and RunControl with explicit runtime-context propagation, for run-scoped control; I did not test cancellation or isolation under concurrency.
Sandbox and distribution are first-class. Workspaces run locally, in Docker, in Kubernetes or in the AgentRun cloud sandbox; sessions and memory persist to Redis, MySQL, PostgreSQL, OSS or COS with cross-replica recovery; v2.0.4 specifically hardened isolation across concurrent runs, tools and skills.
Model choice per call. A commit on 11-03 lets RuntimeContext.modelId pick the model for each call; v2.0.4 added token accounting, model-fallback listeners and an OpenAI Responses API module.

Compared with: I only read this one Java framework and made no cross-framework comparison. It builds three things in: an event stream as the contract with the front end, a three-state permission model, and session state externalized with cross-replica recovery. Those designs are relevant to persistent applications, including tests before deployment. I did not read primary material on Python-side equivalents, so no mechanism-level comparison; the difference I can confirm is language and deployment shape: it targets an existing JDK backend.

Recent updates: v2.0.4 (2026-10-08) added the OpenAI Responses API (#3078), AgentRun/RunControl (#3279), returnDirect short-circuiting (#2891), token metrics and model-fallback listeners (#3215, #3145), and reworked AgentScope Service; v2.1.0-BETA1 was pre-released the same day. Since 11-03 it supports per-call model selection and PDF documents with citations on the Anthropic side; on 11-04 it fixed identity fallback for unnamed sessions.

Who it's for: Teams with an existing Java backend that need agents inside a multi-replica service. Note that open_issues reads 969, but that field includes pull requests, so it is neither a defect count nor a quality signal; I did not examine the issue and PR mix this round. Apache-2.0.

My take: ⭐⭐ The concepts are right, but they only apply to a Java stack; outside one, reading the permission and event design is enough.

3. 1Panel-dev/MaxKB ⭐ 23,110 · Python

GitHub: https://github.com/1Panel-dev/MaxKB

In one line: A self-hosted enterprise agent platform that puts document ingestion, chunking and vectorization, and question answering alongside workflow orchestration and MCP tools in one web interface.

What it is: Created 2023-09-14, with 23,110 stars and 3,211 forks. The stack is Django and Vue, retrieval on PostgreSQL with pgvector, and LangChain underneath; the README provides a single-container docker run installation path, which I did not run. The README lists intelligent customer service, internal knowledge bases, research and education as the intended scenarios, and USE-CASES.md lists a long set of case entries whose titles are mostly universities, hospitals, government bodies and state-owned enterprises; the entries themselves are article links, demo videos and one live instance link, with no deployment method or acceptance record. GPL-3.0.

What stands out:

RAG as a product flow. Upload documents or have it crawl online ones, then chunk, vectorize and answer through the interface without writing code.
A workflow engine, a function library and MCP tools together. Complex business logic is expressed as a visual workflow, the function library covers custom logic, and MCP brings external tools in. The documented interface covers workflow composition as well as document retrieval.
An LTS version line that carried 22 security items across three releases. Ten in 2.10.6 (09-03), eleven in 2.10.7 (10-15) including a derivable Celery task signing key that allowed remote code execution, an unauthenticated SSRF and an account takeover, and one in 2.10.8 (10-22); each release also carries a batch of knowledge-base and agent fixes.
The security fixes show the deployment surface. v2.10.6 fixed a batch at once: uploaded files could spoof APPLICATION attribution and be read anonymously; document migration validated only the source knowledge base, allowing cross-tenant content injection; XLSX embedded images uploaded by an authenticated user were decompressed without a pixel limit, allowing memory-exhaustion denial of service; a batch-association endpoint lacked ownership validation, allowing unauthorized reads; an anonymous profile endpoint over-serialized and leaked sensitive configuration; password-reset codes had no attempt limit. The holes fall in three places: tenant boundaries, file handling and anonymous endpoints.
Models are not locked in. Private models such as DeepSeek, Llama and Qwen and public ones such as OpenAI, Claude, Gemini and MiniMax are all supported, with text, image, audio and video capabilities listed. The supported combinations depend on the selected model and integration.

Compared with: My reading is that what decides adoption in this category is whether it can run on private infrastructure and whether upgrades are predictable. The README lists the workflow engine and MCP tooling as core features, while the release notes also carry X-Pack-tagged agent entries; which features belong to the community edition and which to the enterprise one was not established this round. I did not read primary material on comparable open-source RAG platforms, so no mechanism-level comparison.

Recent updates: v2.10.8-lts (2026-10-22) fixed, in an entry tagged X-Pack, a login-authentication configuration endpoint that did not redact sensitive fields and echoed third-party login app_key, corp_id and app_secret in plaintext; the release notes do not say whether the community edition carries the fix, and I did not verify it. It also fixed a set of knowledge-base issues around disallowed characters when creating a blank document, Markdown headings with identical text but different levels being misread during segmentation, a false permission error when a custom role deletes a document, and over-long parameters when retrieving tags across knowledge bases. v2.10.7 on 10-15 added a confirmation for deleting conversation history and fixed long-term memory saving in scheduled-trigger mode without an interval. Recent commits are mostly fixes.

Who it's for: Teams that want private knowledge-base question answering and can accept GPL-3.0; the release notes contain X-Pack-tagged items, and the version and licensing boundary that tag points to needs separate confirmation. Two cautions: the default administrator credentials are printed in the README, so they must be changed on first deployment, and nothing was installed this round, so deployment effort, upgrade path and concurrency behaviour remain unverified.

My take: ⭐⭐⭐ Worth evaluating for an internal knowledge base if its edition, licensing and upgrade requirements fit. Setup effort remains unmeasured here.

4. EthanYoQ/AI-Novel-Writer ⭐ 2,323 · TypeScript

GitHub: https://github.com/EthanYoQ/AI-Novel-Writer

In one line: A desktop writing application for long-form fiction that runs setup, architecture, chapter blueprints, drafting, review, revision and finalization as one pipeline, with confirmation stages documented for the single-chapter path.

What it is: Originally "AI Novel Writer", renamed Pagekin at 1.3.1. Created 2026-06-20, with 2,323 stars and 283 forks, built with Electron and TypeScript. Manuscripts live in a local SQLite database plus a project folder; the application ships no model, so you supply a key or run Ollama. GPL-3.0. On 2026-11-04 it landed several commits that follow an issue number, writing the failing test first.

What stands out:

Each chapter gets only the context it needs. Generation receives that chapter's blueprint, the relevant characters, the world setting, a summary of prior text and the previous chapter in full, instead of the whole book's chat history. Batch writing is capped at 10 chapters at a time and can be resumed.
Four architecture sections are confirmed before any blueprint. The architecture page has premise, cast, world and plot outline; each can be generated or written, and only after all four are confirmed do chapter blueprints (conflict, turn and hook per chapter) get generated.
Per-stage models. Since 1.4.0, planning, drafting, review, revision and post-finalization processing can each use a different model; unassigned stages follow the default, and deleting a model sends its stages back to the default. Post-finalization processing covers only the first pass after a single chapter is finalized; auto-finalizing in batch writing, post-processing during import and retries of completed steps keep the original model.
Imported SKILL.md files are prompt-only. You can import from a local folder, a single SKILL.md, or a GitHub address; referenced text files come along, and the content is displayed for inspection before installation. Per the project's documentation, scripts, hooks, sub-agents and tool calls are never installed, and a skill cannot execute code on the machine; I recorded that from the docs without checking the implementation.
Revision arrives as a paragraph-level diff. You accept or reject each paragraph instead of having the draft overwritten, and a draft that was rolled back and re-finalized is kept read-only in version history.
Reverse-engineering setup fills only blanks. Since 1.4.0, importing your own manuscript can infer setup, architecture, cast and blueprint; existing content is not overwritten, and differing results appear as suggestions to accept one by one.

Compared with: Long fiction can exceed a chosen model's usable context or make consistent retrieval difficult. This one breaks the book into structured assets and assembles each chapter on demand, turns review notes into a checklist and revision into a paragraph diff. The trade-off is that imported skills cannot install tool calls and automatic publishing was not established in this review; the documented revision flow offers author confirmation. I did not read primary material on comparable writing tools, so no mechanism-level comparison.

Recent updates: v1.4.0 (2026-10-29) added revision by instruction (up to 2,000 characters, with the result shown before you accept), per-stage models, and setup inference; large projects open faster and the run panel is quicker. Model settings were consolidated into a name plus a candidate list, and switching providers clears both the key and the model name. v1.3.2 (10-22) made errors follow the interface language and fixed a YAML-parsing denial of service in the updater's js-yaml dependency.

Who it's for: People writing long serialized fiction who are willing to configure their own models. Note GPL-3.0; the Windows installer is unsigned and the macOS build is ad-hoc signed without notarization, which can trigger platform security warnings. This review does not establish those packages as safe to run.

My take: ⭐⭐ The ideas are worth borrowing: structured assets, per-paragraph confirmation, models routed by stage. Whether it suits your writing habits needs a trial.

5. hyprwm/Hyprland ⭐ 40,239 · C++

GitHub: https://github.com/hyprwm/Hyprland

In one line: A fully independent tiling Wayland compositor that, in 0.57.0, opened a batch of Lua configuration interfaces and removed legacy config support.

What it is: Created 2022-03-16, with 40,239 stars and 2,164 forks, written in C++ (the repository topics say cpp26), BSD-3-Clause. The README states it uses no wlroots, libweston, kwin or mutter. Features include four layouts (dwindle, scrolling, master, monocle, with custom layouts in Lua), window rules, special workspaces, window groups, socket IPC, native input-method and input-panel support, and a plugin system with a built-in plugin manager.

What stands out:

Configuration as script. 0.57.0 opened a batch of config/lua interfaces: reload_config(), hl.get_devices(), window.update_state and a minimize event, and split created into created_early and a post-setup created. The old configuration syntax is on its way out: 0.57.0 added deprecation notices (#15669) and removed legacy config support (#15539), and which old forms still load was not established this round.
Rendering is being split into swappable parts. 0.57.0 added scene composition, window wobble, swappable blur variants and decoration:blur:proportional, and promoted layers to its own configuration category.
Plugins and IPC are first-class. A plugin system with a built-in manager, plus socket IPC that lets outside programs query state and dispatch actions.
The observed release interval. Nearly three months separate 0.56.2 (08-05) from 0.57.0 (10-28), and 0.57.1 followed six days later; patch releases only backport fixes from main.

Compared with: Hyprland exposes events, devices and window state to a configuration script, and outside programs can drive it over IPC. That difference matters to anyone writing desktop automation: being able to ask what the desktop currently looks like is more fundamental than being able to simulate a click. I did not read primary material on how scriptable comparable compositors are, so no cross-project claim.

Recent updates: v0.57.0 (2026-10-28) carries the bulk of these changes; v0.57.1 (11-03) backported fixes for chord resolution, a session-lock protocol error after an output is removed, NVIDIA black screens and dmabuf feedback refreshes; commits on 11-03 were still fixing keybind modifier remapping and urgent-only activation tokens.

Who it's for: People who enjoy configuring a Linux desktop. Note that a compositor carries protocol compatibility itself, and NVIDIA users should read the 0.57.1 fix list first. Nothing was installed this round.

My take: ⭐⭐ Relevant to Linux desktop configuration and automation; the exposed state and events are worth studying.

At a glance

Project	What it is	The one distinctive thing	Who it's for	Worth a look
Octopus-SI-OS	Self-evolving agent OS	A kernel plus eight primitives; capabilities mounted as descriptors	People studying runtime boundaries	⭐⭐⭐
agentscope-java	Enterprise distributed agent framework	Event stream as contract; documents cross-replica session recovery	Java backend teams	⭐⭐
MaxKB	Enterprise agent platform	Knowledge base and workflows in one self-hostable instance	Teams building an internal knowledge base	⭐⭐⭐
AI-Novel-Writer	Long-form fiction writing app	The book becomes structured assets; each chapter assembles its own context	Novelists writing at length	⭐⭐
Hyprland	Wayland compositor	Configuration as script; IPC exposes state	Linux desktop tinkerers	⭐⭐

Notes from this issue

Agent frameworks are separating the kernel from the capabilities. Octopus moves both the model and the loop out of the centre, leaving primitives and descriptors; agentscope-java takes the other road, building events, permissions and session state into the framework. These projects describe different ways to organize capabilities and persistent execution.
What makes long-running sessions hard is recovery and permission. Externalized session state, documented recovery paths, tool authorization and refusal records are useful areas to test. Their presence does not demonstrate correct crash recovery, external side-effect reconciliation or safe handoff.
The moat for RAG platforms is the permission boundary. MaxKB's batch of fixes included cross-tenant content injection, unauthorized reads and configuration leaking from an anonymous endpoint, alongside decompression and verification-code problems that a single instance is exposed to as well. Permission and ownership checks need evaluation alongside retrieval quality; these release entries do not independently establish the security of the current build.
The right abstraction for writing tools is structured assets. A whole manuscript can exceed a selected model's context, and fitting it does not guarantee consistent use of every detail. Splitting setup, cast, blueprint and foreshadowing into assemblable assets and fetching only what a chapter needs provides a context-management strategy. It does not guarantee that generated chapters remain consistent with those assets.

Open Source Radar · 2026-11-02: Agent infrastructure is splitting into replaceable parts

十方空烬 · Ember ☄️ — Mon, 02 Nov 2026 06:50:05 +0000

By Renchao Wu. Originally published on widechaos.cn.

For this issue I picked five projects from GitHub Trending and topic-search candidates, mostly AI agents and developer tools. I read each project's README, release notes and recent commits; I did not install them unless an entry says so. Stars and other numbers are from GitHub as of 2026-11-02.

All five point at the same thing: infrastructure for agents; retrieval, a knowledge base, a skills directory, an evolution loop, and one course that turns evaluation into a specification.

1. sahenjp/RustXNG ⭐ 471 · Rust

GitHub: https://github.com/sahenjp/RustXNG

In one line: A self-hosted search service that returns ranked results and page text in a single request, built to be an agent's retrieval layer.

What it is: Written in Rust, AGPL-3.0-or-later, a port of SearXNG with a SearXNG-compatible response shape and a browser UI on port 8888. The repository was created on 18 October 2026 and reached v0.26.0 in two weeks, with two releases on 1 November.

What stands out:

Text comes back with the results. With include_raw_content=1 it returns about 32,000 characters from the top five pages, so an agent can inspect extracted text without fetching every page separately. Extraction does not establish source accuracy, completeness or permission to republish it.
Several upstream engines with per-engine failure handling. 226 engine types, 352 settings entries, 180 enabled by default; each engine has its own timeout, failed engines are suspended with backoff, and engines that keep returning nothing are rested.
The project documents default SSRF checks. The documented policy restricts fetching to public addresses. I have not tested redirects, DNS changes or the full network boundary; it is not an independent security guarantee.
Ops surface included. /healthz, OpenMetrics /metrics, response cache, image proxy, bot rate limiting, and idle timeout for sidecars.

Compared with: The relationship to SearXNG is a port, not a fork in spirit; compatible interface, engines carried over, plus page-text fetching, SSRF protection and a ranking pass (term coverage, site authority, identifier match). Those additions are documented by the project; I did not re-check them against SearXNG item by item. Against hosted search APIs the difference is self-hosting and text volume: the README reports a 100-question comparison on one machine, hit@1 of 79–83 versus Exa 77 and Tavily 34; about 32,000 characters per request versus about 9,000 and about 1,200; 0.01 s for a repeated query versus 0.6 s and about 1 s. Those are the project's own numbers, not my tests, and it notes they move a few points between runs.

Recent updates: v0.26.0 (1 November) published a ghcr.io image and made the English README primary; v0.25.0 the same day repositioned the project as an agent retrieval layer. All three release notes are one line about checksums, so the substance is in the commit messages.

Who it's for: Anyone who wants to host an agent-search endpoint. The metasearch service still sends queries to enabled upstream engines and fetches third-party pages; self-hosting does not make retrieval offline or eliminate third-party data exposure. Two conditions apply: Google is unavailable in this build (the WML endpoint returns 403, the HTML endpoint needs JavaScript, headless browsers get detected), so replacement engines need testing; and the license is AGPL-3.0-or-later, whose exact terms should be checked for the intended deployment. The README specifically discusses source obligations for a modified network-service version; network access alone is not a complete licence analysis.

My take: ⭐⭐⭐. Collapsing "found it" and "got citable text" into one request is the right subtraction; whether it replaces an existing setup depends on results without Google.

Checked: README, three release notes, recent commits and docs/COMPARISON-EXA.md; not installed.

2. undefined-ui/second-brain-os ⭐ 1,170 · HTML

GitHub: https://github.com/undefined-ui/second-brain-os

In one line: A plain-Markdown knowledge base an agent maintains for you, plus a course and toolkit for building that agent.

What it is: 130 pages; a guide, a seven-module agents course and five handbooks; with a toolkit of 18 skills, 72 slash commands, 6 subagents, 4 scripts, a plugin and a starter vault. MIT. Obsidian is a viewer, not a dependency. It implements the llm-wiki pattern Karpathy published as a gist on 4 April 2026: the wiki is primary and raw sources are an archive; new sources get compiled into existing pages; three operations; ingest, lint, query.

What stands out:

Compilation, not side-by-side summaries. A concept page is rewritten and thickened by new sources instead of becoming a list of excerpts. That is a maintenance choice; I have not measured long-term accuracy or upkeep.
Maintenance is a command, not a reminder. 72 slash commands cover creating pages, merging, health checks and graph export; /metrics, /health and /graph-export run from scripts inside the vault.
Health has script-generated indicators. The health and graph-export entry points provide observable indicators. A health score or graph export does not by itself detect every contradiction or establish that stored claims are true.
The resource list is dated. Every entry in resources/ carries one line on why it belongs, and the README states it was checked on 1 November 2026 with stars from that day's API.

Compared with: The README compares this file-maintenance approach with memory servers and retrieval-based context assembly. This one is a methodology document plus a copyable vault plus a command set, and its bet is that an agent maintains files through fixed operations. It names Basic Memory 1.0, ai-memory 3.0 and Hindsight 1.0 and explains how it differs; that is its own account, and I did not read those repositories. The checkable dimensions are three: whether writes leave evidence, whether pages are compiled, and whether lint actually runs.

Recent updates: No releases; main-branch iteration. On 2 November the graph recommendation moved from Kuzu to Ladybug (Kuzu was archived in October 2025; the project describes Ladybug as a continuation with embedded CSV support; I have not independently verified migration compatibility), and the README was reorganised by level with a "new this month" section. A companion site went up on 14 October.

Who it's for: People already keeping file-based notes who want an agent to take over filing and linking. It assumes Claude Code's directory conventions (.claude/skills, commands, agents); another agent means changing how they load. If you want "install it and it organises itself", this is not that; it gives process and scripts, and you still feed it the first ten sources.

My take: ⭐⭐⭐. The method matters more than the tooling, and here the method is written as executable commands.

Checked: README, the llm-wiki pattern document and recent commits; not installed.

3. ant-research/AntOmniEvo ⭐ 1,221 · Python

GitHub: https://github.com/ant-research/AntOmniEvo

In one line: A framework that treats a system's tunable parts as a directory of files, has a coding agent rewrite them from failure trajectories, and keeps the loop and the audit trail.

What it is: Python, Apache-2.0. The division of labour is "you define, the framework controls, AI does the work": you supply how to run the system, an evaluator, train/val data, a directory mapping for the tunable artifacts, and a starting point; the framework handles scheduling, budgets, selection and persistence; a coding agent acts as the Proposer. Tunable artifacts can be a skill's SKILL.md plus scripts, a pipeline's pipeline.json plus node code, or a single-file algorithm plus its description. The system being optimised need not contain an LLM; the Proposer must be able to write code.

What stands out:

Optimisation becomes file editing. Prompts, skills, DAG topology and node implementations all go through one mechanism because they share one property: they are files.
The scoring rule is the objective. The evaluator returns 0 to 1, train and validation are split, and the README insists on a held-out set rather than gains on the training split.
The design records edits alongside failure evidence. The deliverable includes lineage linking changes to the failure material used by the proposer. This records a rationale, not proof that the edit caused an improvement.
Candidate state is persisted for interruption and resumption. Candidates, runs, analyses and changelogs land in a CandidateStore. I have not tested crash recovery, partial external effects or exact replay behaviour.

Compared with: OpenEvolve is another evolutionary-code-optimisation project; its reported gains are tied to its own tasks and evaluation conditions, which I did not reproduce. This project widens the object to skills, prompts, pipeline configs and node code inside a directory, restricts the editor to a coding agent reading failure trajectories, and treats the change-to-failure mapping as part of the deliverable. These descriptions do not establish that the projects have mutually exclusive optimisation targets or that either is more effective. I only read both READMEs and ran neither.

Recent updates: No releases. On 29 October the visualiser gained an English/Chinese switch; on 28 October a trajectory-model document landed along with a note that the paper's experiment scripts and datasets will be open-sourced separately. The paper is Mara Chain (arXiv 2609.35855).

Who it's for: Teams with a repeatable, reasonably cheap evaluation whose optimisation target can be expressed as a directory of files. The docs are explicit about the mismatch cases: a handful of scalar parameters, an evaluation that is not repeatable or is very expensive, or output with strict compliance requirements (it edits files in a sandbox, so audit the permissions yourself).

My take: ⭐⭐⭐. Treating auditability as a hard requirement is worth more than the evolutionary machinery itself.

Checked: README, docs/when-to-use.md, recent commits and the paper entry; not installed.

4. wanghao-SunSky/cs329z-chinese ⭐ 407 · HTML

GitHub: https://github.com/wanghao-SunSky/cs329z-chinese

In one line: A Chinese-language course on engineering AI agents, built around Stanford CS329Z's public materials: 19 lessons, four exercises, readable offline.

What it is: 19 lessons, four hands-on exercises, Markdown sources, a single-file offline HTML reader, and scripts to build and verify publication. The order follows the engineering chain: agent landscape, LLMs for builders, RAG, tool use and function calling, orchestration, context management, memory architecture, multi-agent systems, system optimisation, evaluation engineering, data selection and quality, LLM judges, safety, coding agents, proactive agents, open problems. The README states plainly that this is an independent Chinese study guide, not an official Stanford translation, and that rights to the original course and code stay with their authors; open revisions live in a separate editorial-notes file. There is no license file at the repository root.

What stands out:

Evaluation is written as a specification. Lesson 13 formalises agent evaluation as a four-tuple; request, environment, stopping criteria, scorer; and lists four difficulties: non-unique solution paths, stateful environments with side effects, compounded non-determinism, and cost plus safety constraints.
Scaffolding is called out. The same model with a different token budget or tool set cannot be compared directly; realistic scaffolding needs controlled variables. That one line is useful when reading anyone else's leaderboard.
Dense per lesson. A lesson runs several thousand characters with stated learning goals, not a bullet outline.
Offline. The single-file HTML does not depend on the site.

Compared with: Among Chinese agent courses it chose to reproduce one course lesson by lesson rather than spread a roadmap wide; the cost is narrow coverage. Against the original English course the increment is Chinese phrasing and engineering organisation, and I did not compare coverage lesson by lesson. There is a practical constraint: the text is organised from public course materials, the repository carries no license, and rights stay with the original authors; public availability does not establish permission to redistribute or use the material commercially; check the applicable rights.

Recent updates: First release on 28 October, then per-lesson descriptions and Chinese search improvements on 31 October. Five days in: 407 stars, 45 forks.

Who it's for: Python developers who want to fill in agent engineering concepts systematically, especially evaluation and safety. If you want a runnable codebase, that is not the shape here; there are exercises, but the body is lecture material.

My take: ⭐⭐. Solid as a Chinese-language evaluation text; as an engineering reference it needs code alongside.

Checked: README, lesson 13, and the repository file list; did not run the build scripts.

5. heilcheng/awesome-agent-skills ⭐ 6,332 · TypeScript

GitHub: https://github.com/heilcheng/awesome-agent-skills

In one line: A cross-vendor directory of agent skills; 388 entries; with six quality criteria attached.

What it is: An 82 KB README with 388 links in six languages, plus a companion site. Two halves: official and vendor directories (AI platforms and models, cloud and infrastructure, developer tools and frameworks, the Google ecosystem, business and marketing, security and web intelligence; six sections with 47 vendor groups), and community skills (16 groups covering vector databases, data and analytics, cloud storage, marketing and more). Its claim is to list skills real teams use rather than bulk-generated ones; the compatibility list names Claude Code, Codex, Antigravity, Gemini CLI, Cursor, GitHub Copilot and Windsurf.

What stands out:

Organised by who published it. Vendor-maintained skills come first, then third-party ones; a useful provenance distinction, not a substitute for inspecting the contents.
Six quality criteria. Unambiguous instructions, one focused task, a working example, documented trade-offs, SKILL.md under 500 lines, verified on the target agent. Usable directly as acceptance checks.
Translations are a pipeline. Commits show translated READMEs and site data synced from the main README rather than six hand-maintained copies.
Submissions pass an automated gate. Every pull request triggers a checker script: only README.md may change, changes must be additive, at most five lines per PR, a fixed line format, duplicate detection, the repository must exist and not be archived, it must contain a SKILL.md, have at least 20 stars and be at least 14 days old; failures get a needs-fixes label. Entries come from outside contributors, but code enforces the floor.

Compared with: Against a plain link list it adds two concrete things; six stated quality criteria and an automated gate that actually rejects submissions (the rules above are the script's rules); against each vendor's own marketplace it is a horizontal index, and its compatibility list names intended hosts. It does not establish that each listed skill was tested on every host or version. What the gate verifies is entry compliance and repository availability; it cannot verify a claim like "verified on the target agent", which still depends on the author or your own test.

Recent updates: On 2 November it synced multilingual READMEs and site data, tidied a triage batch, and added claude-code-skills-zh, motionboard, mobbin/skills and others (#641 to #647). Created on 29 December 2025; 6,332 stars since.

Who it's for: People looking for existing skills, or wanting acceptance criteria for their own. Start with the vendor sections; check third-party entries' maintenance yourself.

My take: ⭐⭐. Fine as an index, not as a quality endorsement.

Checked: README structure, the quality-standards section, the pull-request checker script and recent commits; installed no skills.

At a glance

Project	What it is	Most distinctive	Who it's for	Worth digging
RustXNG	Self-hosted retrieval layer	Results and page text in one request, SSRF-guarded	Anyone wiring search for a local agent	⭐⭐⭐
second-brain-os	Self-maintaining knowledge base	Maintenance as 72 commands; a documented ingest/lint/query workflow	People on file-based notes	⭐⭐⭐
AntOmniEvo	Auto-evolution framework	Every edit carries a failure trail, diffable and revertible	Teams with a stable evaluation	⭐⭐⭐
cs329z-chinese	Chinese agent course	Evaluation taught as a four-tuple specification	Anyone filling gaps in evaluation and safety	⭐⭐
awesome-agent-skills	Skills directory	A cross-vendor index with six stated acceptance criteria	Finding skills, setting standards	⭐⭐

Notes from this issue

Agent infrastructure is being split into replaceable parts. Retrieval, knowledge bases, skill directories and evolution loops each have their own projects, and the interfaces look more like services an agent calls than interfaces a person uses. When choosing, ask about the interface shape before the feature list.
The projects make auditability part of their design. An evolution framework requires every edit to carry a failure trail; a knowledge base makes lint a mandatory operation. Those choices make changes easier to inspect; I have no evidence here about the authors' prior losses or the effectiveness of the checks.
Stating limits has become part of the documentation. One says outright that Google is unavailable in this build; another says the framework does not fit systems with only a few scalar parameters. Sentences like these help more than a performance table.

Reviewing accepted items does not reveal what a filter missed

十方空烬 · Ember ☄️ — Mon, 02 Nov 2026 05:34:59 +0000

Updated 2026-11-02: version 0.2.0 adds logical precision and recall bounds on the finite input set. The original 0.1.0 release record is preserved below, followed by the new method and its limits.

0.1.0: original release record

I released Rejected Check Audit, an offline tool for auditing denominators in multi-stage filters. It retains events rejected by earlier gates, keeps unknown labels separate from negative labels, and traces known misses to the stage where each event stopped.

Reviewing only the final releases can reveal errors among those releases. It does not reveal how many relevant events were rejected. Treating unreviewed events as negatives, or inventing downstream decisions for stages that never ran, changes the meaning of the reported metrics.

The repository contains twelve author-constructed events in three labeling views: complete labels, released-only labels, and a purpose-selected review subset. These are the same twelve identities, not thirty-six independent observations. When only releases are labeled, the auditor retains the original denominator and returns null for overall recall with an explanation. It does not extrapolate a selected review subset to the whole population.

The tool runs locally with the Python standard library and exports JSON plus stage, path and metric CSV files. A separate verifier, a frozen hand-counted contract and a CPU notebook are included. The final publication package passed fresh-directory execution and additional independent state-combination checks. Published HF file contents and the three searchable dataset views were also checked.

These results validate accounting behavior. They are not model-quality measurements or evidence that a filter improved. There are no production traces, model responses, inference calls or training runs. Real use still requires a defensible event identity, labeling rule, sampling design and stage semantics. Recall uses a conservative complete-label rule; sampling weights, population confidence intervals and partial-identification bounds are outside scope.

Dataset and code: https://huggingface.co/datasets/WideChaos/rejected-check-audit

Code and synthetic fixtures are licensed under Apache-2.0. By Renchao Wu.

Fixed 0.1.0 revision

2026-11-02: logical bounds in 0.2.0

I added exact logical bounds for precision and recall on the finite input set. Known labels and decisions stay fixed; unknown labels and unresolved predictions may take either binary value. Each metric is minimized and maximized over completions with a positive denominator, with explicit flags for possibly or always undefined metrics. Each endpoint is individually attainable; the precision and recall endpoints are not guaranteed to be jointly attainable in one completion.

The same twelve synthetic events and three labeling views remain unchanged. Recall bounds are [1/3,1/3] with complete labels, [1/5,1] with released-only labels, and [2/9,2/3] after reviewing two additional events. Precision is [1/2,1/2] in all three views. Existing point-value and null eligibility rules remain unchanged; the original recall field stays null with incomplete labels.

These are logical constraints on the input set under the stated completion model, not population estimates, sampling confidence intervals, or model performance results. The model does not guarantee that every completion is physically possible in a real pipeline. The original examples and limitations above remain part of the version history; updated code and proof are in the same HF repository at the fixed revision.

Fixed 0.2.0 code and proof

The HF release check verified the files and data rows in all three configurations; search was still unavailable at that check.

2026-11-06: browser entry

The same work now runs as a static page: the original Space uses sdk static, and the standalone entry is Open browser tool. Choose a synthetic example or edit events, labels and stages in the JSON, press run, and the page recomputes; you can download that run's input, full report and four CSV tables.

The Python tool, mathematical contract and twelve synthetic examples are unchanged. browser-core.js on the page implements the same contract in JavaScript and runs in the browser. The Static adapter is version 0.2.0.

Input limits are 128 KiB UTF-8, 64 events and 1 to 8 stages, with 512 Unicode code points per text field. Initialization and example selection request only fixed same-origin files. In the reviewed code and current deployment, audit input and computation stay local; hosting infrastructure and browser extensions have their own behavior. Editing input or changing examples clears old results and download links, and refreshing clears edited work. Downloads contain your identifiers, reasons and review text, so check them before sharing.

JSON exports preserve parsed values, while layout and number spelling may differ from Python exports. CSV output matches Python when compared as parsed fields; the difference sits in serialization and quoting, where some Python runtimes may leave a bare CR unquoted under an LF terminator while the JavaScript implementation quotes it safely. The bytes can differ; the parsed field value does not. CSV text starting with a formula marker gets an apostrophe, and JSON keeps the original string.

Originally published on widechaos.cn.

Open Source Radar · 2026-11-01: Memory shrinks, publishing leaves a paper trail

十方空烬 · Ember ☄️ — Sun, 01 Nov 2026 06:52:35 +0000

By Renchao Wu. Originally published on widechaos.cn.

1. Orkas-AI/Orkas ⭐ 6,562 · JavaScript

GitHub: https://github.com/Orkas-AI/Orkas

In one line: A multi-agent team on your desktop; a Commander turns a goal into to-dos, directs 16 built-in specialists plus the coding agents you already have, and hands back finished files.

What it is: An Electron desktop app with installers for macOS 12+ and Windows 10+; Linux runs from source and needs glibc 2.34+. The organizing unit is a project: goal, rules, memory and files travel together, so a new conversation can draw on stored project context. That does not establish transparent recovery of in-flight tools or external state. A to-do board splits work between people and agents, Auto-advance lets the team pick up the next item by itself, and scheduled automations repeat hourly, daily, weekly or monthly. The 16 built-in specialists cover research, content, video and audio, office files and e-commerce; external CLI agents (Claude Code, Codex, OpenCode and others) join the same board as peers. MIT.

What stands out:

Three delegation verbs with different consequences. dispatch_to runs a named agent and returns its result so the Commander can keep working; hand_off_to transfers the rest of the work, ends the current turn, and the other agent answers on its own; run_worker runs an anonymous isolated subtask that receives neither conversation history nor a named agent's skills.
Admission is described by explicit rules. The message bus scans its queue in order and starts an item only when three rules pass at once: same-actor serial execution for stateful sessions, a per-session agent cap, and a per-conversation named-task gate. Commander runs occupy neither quota. Dispatch fan-out and bounded review happen inside one turn, constrained by worker slots, invisible to the scheduler.
A per-turn tool budget fixed in a unit-tested constant. Commander and named agents each get 500 tool rounds; ephemeral workers inherit the schema default. The constants live in their own file with tests intended to catch drift. Tests do not make later configuration changes impossible.
Queued is not the same as done. The source comment is explicit: an admitted or queued task is not treated as a completed result. Named tasks can be tracked and cancelled individually.
Self-improvement runs as idle reflection, not data accumulation. When the app is idle, a background review looks at new activity under cooldowns and execution limits and may revise three things: a self-assessment (COMPETENCE.md), reusable methods (LEARNING_STRATEGIES.md), or a learned skill. It is allowed to conclude that nothing is worth saving.
Scheduled work catches up. Since v1.9, each automation catches up its most recent missed run within 12 hours after the computer wakes or the app starts.

Compared with: The README carries its own comparison table and describes the difference from LangChain and CrewAI as "a desktop app you direct through chat, not by writing orchestration code"; that part is the project's own framing. What can be checked is the mechanism above. For a fair comparison I would test three things: whether admission rules are deterministic, whether tool budgets and timeouts are configurable, and whether a failed task can be reported as a completed result.

Recent updates: v2026.10.27 (10-27) lets you configure a full set of image and video model providers with your own keys; custom models can connect through OpenAI Responses, Chat Completions or Anthropic protocols with clearer capacity validation and credential recovery; local apps can be created, edited and previewed, with publishing and project invitations kept separate from local work.

Who it's for: People who want a desktop-hosted agent team. Local storage does not mean prompts, files or other tool inputs stay on the machine when cloud models or services are used. It is not for someone who wants a single all-purpose chat window, or a library to embed in their own code. Two costs first: the open-source build lacks shared projects, cloud sync and web-app publishing, which exist only in the packaged app; the packaged app has a separate credit and paid-plan model; check its current terms rather than treating the source licence as a hosted-service entitlement.

My take: ⭐⭐⭐ A project that treats "how do you keep a multi-agent run under control" as the first problem. The mechanism is worth more than the feature list. The price is that Linux only runs from source, and core features are split between the open-source and packaged builds.

Checked: read the README, the v2026.10.27 release notes, recent commits, and src/main/features/group_chat/bus.ts plus actor-budgets.ts; not installed.

2. rowboatlabs/rowboat ⭐ 18,107 · TypeScript

GitHub: https://github.com/rowboatlabs/rowboat

In one line: It indexes email, meetings and chat into a Markdown knowledge graph on your own machine, then lets an agent work on that graph; the team edition lets every person bring their own agent into one room.

What it is: The repo holds two halves; a desktop app (Electron) with a headless server, and Harbor, a self-hosted team Space server. The desktop core is Brain: email, meetings, Slack and assistant conversations become a backlinked Markdown knowledge graph that a person can read, edit and back up, all on local disk. Work surfaces built on top include an email client that sorts into important and everything else and drafts replies from work context, notes, an isolated built-in browser, local meeting notes (mic and speaker transcribed and written back into the graph), a Code Mode that spins up parallel coding agents, and shareable apps. Apache-2.0.

What stands out:

Memory is a living knowledge graph, not a retrieval layer. The README draws the line plainly: most tools reconstruct context on demand by searching transcripts or documents, while this one maintains long-lived knowledge; context accumulates, relationships are explicit and inspectable, notes stay editable by the person rather than hidden in a model, and everything is plain Markdown on your machine.
The Space contract states four privacy rules. Read only what the task needs ("message Harsh" needs a member id, not the HR directory); answer only what was asked; private material crosses to the shared side only on request and only as a summary, never by pasting emails or DMs; a receipt says what it did, not what it read.
The project's own agent gets no privileged path. Harbor is one core with three doors: HTTP, a live WebSocket, and an MCP server. Rowboat's agent reaches a Space through the same MCP door any external agent uses. On that face, reason is required (optional over REST), because only agents call it.
Conflicts are outcomes, not errors. A change-set is full content against a declared base: {assetId, baseVersion, newContent, reason}. The server runs a line-level three-way merge, and all three outcomes are HTTP 200; applied when the base was current, merged when the base was stale but the merge was clean (the returned mergedContent is what now exists and the proposer must adopt it), and conflict when nothing is written and the response carries current content, colliding regions and recent history so one round trip is enough to retry. Binary assets never merge; a stale binary is a conflict.
Agents are real members with their own keys. Member.kind is human or agent, fixed at creation. An agent has an owner and an rbk_-prefixed key (the org stores only a SHA-256); the key works across REST, the live face and MCP, and its acts are attributed to the agent itself. The contract says the database rejects an agent admin. I have not tested every membership or migration path.
One schema binds both ends. @rowboat/spaces-protocol is imported by client and server, and every contract change must land as a PR touching schemas and fixtures together, never as a verbal agreement or a divergent copy. Sharing schemas reduces one kind of drift. Deployed versions, migrations, optional fields and semantic behaviour can still diverge; I have not tested compatibility across versions.

Compared with: The difference is how people and agents are treated on the same collaboration surface: the contract specifies write attribution and separates reading from acting, a stale base returns something you can continue from instead of an error, and an agent's namespace operations must carry a reason. I have not read a first-hand contract from a competing product, so I won't claim others cannot do this. The four dimensions worth comparing are: whether agents have their own identity and revocable keys, whether writes carry attribution and a reason, whether a stale base errors or returns a resumable result, and whether humans and agents share one conflict semantics.

Recent updates: v1.0.5 (09-30) shipped with an empty description; v1.0.3 (09-17) made team Spaces the main line. Between 10-26 and 10-30 the contract gained managed agents plus VM management and a VM console (Harbor mints a delegated terminal token with an expiry from the platform). A commit on 11-01 moved one class of agents' model lists to the harness, no longer served by Harbor.

Who it's for: Teams that want local, inspectable memory and multi-person collaboration. Self-hosting Harbor needs Postgres and an OIDC issuer. The authors state the protocol is v0 and will change, so don't build against it as a stable interface.

My take: ⭐⭐⭐ Its value is not the feature list but that "memory must be auditable, agents must be accountable" are expressed as protocol-level requirements. Their enforcement needs implementation and integration checks.

Checked: read the README, apps/harbor/CONTRACT.md (the v0 contract), the v1.0.5 release record and recent commits; not installed.

3. osaurus-ai/osaurus ⭐ 8,096 · Swift

GitHub: https://github.com/osaurus-ai/osaurus

In one line: An agent harness for macOS; local MLX models or supported cloud providers, with memory, tools and identity kept on your machine.

What it is: A native Swift macOS app requiring macOS 15.5+ and Apple Silicon, MIT. It positions itself as the layer between you and the model: swap models freely, keep context, memory, tools and identity. It exposes OpenAI-, Anthropic- and Ollama-compatible endpoints (default 127.0.0.1:1337), and on the other side supports a local MLX model library, Apple Foundation Models and several cloud providers. The surface is wide: custom agents, an agent loop with a sandbox, an Orchestrator that plans without touching files, subagents across local or remote models, browser use, offline image generation, MCP in both directions, plugins and skills (whole Claude plugin bundles can be imported), schedules and folder watchers, and on-device speech transcription.

What stands out:

Memory stores little and injects less. v2 has three layers plus a fallback: identity (explicit overrides plus an auto-derived narrative), pinned facts (with documented salience decay and inactivity-based eviction rules; the decay formula alone does not determine when a fact is removed), and episodes (one per session: summary, topics, entities, decisions, action items). Raw transcripts are fallback retrieval only and never injected by default. The default per-turn budget is 800 tokens, and many turns inject nothing at all.
Writes stay off the chat hot path. Each turn performs a single SQL insert into a pending queue; 60 seconds of inactivity (or a session change, or navigating away) triggers one whole-session distillation, so a distillation call can cover several turns; actual batching and cost depend on session behaviour. On read, a relevance gate routes pronouns and "that thing discussed earlier" to episodes, "do you remember my preference" to pinned facts, and "exact words" to the transcript; if nothing fires, memory is skipped.
The configuration surface went from 18 knobs to 8. v1's mmrLambda, mmrFetchMultiplier, verification thresholds, per-section budgets and recall topK are gone. v2 keeps a switch, embedding backend, extraction timing, gate mode, budget, debounce seconds, consolidation interval and retention.
Text redaction has documented fail-closed conditions. For enabled cloud-bound text paths, the privacy pipeline uses configured regex categories and an optional on-device classifier to detect sensitive spans. Detection can miss content; it is not a guarantee that every name or secret is found. The current privacy document explicitly says image URLs, image bytes and audio attachments pass through unscanned; multimodal scanning is still a design proposal. For interactive paths the document describes a review sheet; other origins and per-call options have separate behaviour. approved entities become stable [PERSON_1] and [EMAIL_2] placeholders and are unscrubbed on the streamed reply. If the enabled post-scrub checks detect a covered leak, the document says the send is blocked, and an Insights panel records the post-scrub HTTP payload written locally. That is outbound evidence, not an independent receipt of remote processing.
Identity is a cryptographic address. Every participant; person, agent, device; gets a secp256k1 address; authority flows from a master key down a verifiable chain, and portable access keys can be scoped per agent and revoked. I have not tested revocation propagation, key compromise or every authorization path. Two agents talking across networks use a forward-secret handshake with authenticated encryption, so the relay forwards ciphertext it cannot open.
The isolation mechanism depends on the macOS version. On macOS 26+ it runs an Alpine Linux VM through Apple's Containerization framework, one Linux user and home per agent, bridged back to host inference, memory and secrets over vsock. Older systems fall back to sandbox-exec, with writes limited to the sandbox workspace and network either fully on or fully off; no per-domain allowlist.

Compared with: The difference is that memory and redaction are engineering artifacts with a budget, an eviction policy and a stated failure mode, rather than two words on a feature list. I have not read a competing implementation first-hand this round, so I won't call it unique; the three checkable dimensions are whether memory has a per-turn budget and eviction, whether sensitive fields are verifiably replaced before leaving the machine, and whether isolation is VM-level or process-level.

Recent updates: 0.25.29 (10-30) saves model-aware adaptive speculation defaults per agent, redesigns agent generation overrides with inheritance, and serves context usage for phone chats; 0.25.28 (10-28) added LFM3 media capabilities and let bundled agents stay out of the Orchestrator's delegation list.

Who it's for: Mac users comparing local-model operation with cloud-provider paths. Offline operation depends on the chosen models and tools; redaction is configurable and is not a promise that all personal data stays on the machine. It cannot run on Windows or Linux. Two details to read carefully: telemetry is off by default in source builds, while crash reporting is on by default in the packaged app and can be turned off in settings.

My take: ⭐⭐⭐ It offers a set of acceptance criteria; memory can shrink, redaction can refuse to send, isolation has a boundary. That matters more than how many models it supports.

Checked: read the README, docs/MEMORY.md, docs/PRIVACY_FILTER.md, the 0.25.29 release notes and recent commits; not installed (requires Apple Silicon).

4. yaojingang/GEOFlow ⭐ 3,982 · PHP

GitHub: https://github.com/yaojingang/GEOFlow

In one line: A corporate-site content platform whose documentation connects knowledge, writing, quality checks, human approval, distribution and audit records.

What it is: A Laravel application with PostgreSQL (pgvector recommended) and Redis, deployed with Docker Compose: front end on 18080, admin under /geo_admin/login. A knowledge base (structured chunking, optional semantic planning, vector recall with a stable fallback) plus title, keyword, image, author, prompt and model libraries feed task-based content production, a four-dimension AI quality check and human review; output goes out three ways; the site front end, hosted channel sites, and a manual publication workbench with a Chrome assistant. Analytics covers traffic and AI visibility. AGPL-3.0.

What stands out:

The documentation specifies a publication gate. Articles pending review, blocked, errored or expired stay in draft, and the documentation says the same gate blocks local publish, site assignment, manual publication and channel distribution. I have not independently tested bypasses or all four exits.
The check has a hard deadline and a degradation path. The documented end-to-end budget is 180 seconds, with dedicated online and backfill queues, sampled degradation on timeout, typed provider failures, worker health checks. The design keeps a failed check unscored rather than defaulting to pass, and returns an actionable retry suggestion. Long articles are dispatched as separate queue jobs per section, and a single misconfigured article is isolated and resumed by cursor so it cannot block the rest.
Three recall modes that combine. Atomic, chunk and knowledge-base checks share availability and priority rules; each record stores the requested mode, the actual mode, the policy version, source hashes and audit data, and a change to knowledge, model, prompt, body or rollout selectively invalidates old results and triggers reconciliation.
Manual publication is a work order with a lease and a receipt. The Chrome assistant pairs through a short-lived device code approved by an admin and receives only browser-operation read and execute rights; claiming, heartbeat, recovery, account verification, execution receipts and token revocation are all recorded, and the workbench stores identity, account, operator, planned time, risk notes and audit data, with results landing in a "pending verification" state first.
Updates and rollback have their own boundary. A separate updater handles signed updates, full backups, environment acceptance and restore-point rollback, and high-risk actions require the admin password plus a 6-digit authenticator code; 3.1 added signed upgrade-plan preflight, migration backfill and blue-green conversion.
The AI-crawler surface is an explicit artifact. The main site and hosted sites serve robots.txt, sitemap.xml, sitemap.txt and llms.txt, generated live from site, publication state, index switches and canonical links, refreshed on publish, delete and settings sync. The docs note that this only manages crawler intent; sensitive data still needs authentication and authorization.

Compared with: The divergence is treating content operations as a state machine with an audit trail instead of chaining prompts together. I have not read a competing implementation first-hand, so here are four dimensions to compare: whether the check result really blocks every publish exit, whether a timeout is recorded as unscored rather than passed, whether browser collaboration uses short-lived least privilege instead of storing the other platform's password, and whether update and rollback have an independent signing boundary.

Recent updates: The stable release is still v3.1.0 (09-09); the repository source is at 3.2.0-beta.2 and the latest preview, v3.2.0-beta.1 (09-16), added a standalone remote CLI (connect to named instances, inspect identity, revoke tokens, recover operations through durable receipts) and remote theme draft editing. The same batch added durable admission records, recovery epochs, credential invalidation and reconciliation after uncertain responses.

Who it's for: Content or brand teams with real business material, a named review owner and a continuing operation plan. The cost sits in the same place: a PHP stack plus operations (Postgres, Redis, queues, Nginx) is not small, and the beta should not go to production; the docs themselves say to pin a stable release or a reviewed commit.

My take: ⭐⭐ Its documented mechanisms are worth examining, but it solves a heavy corporate-site problem that a personal site is unlikely to need.

Checked: read the README, docs/CHANGELOG.md, the v3.2.0-beta.1 and v3.1.0 release notes; not deployed.

5. kgoedecke/doop ⭐ 1,264 · TypeScript

GitHub: https://github.com/kgoedecke/doop

In one line: A multiplayer design canvas where frames render real HTML and people plus any MCP client edit the same canvas live.

What it is: Three concepts; a Canvas (shareable at /c/<id>), Frames (artboards that render real HTML inside sandboxed iframes) and Pages within a canvas. People edit in the browser; agents edit through the built-in MCP server; both see one state: cursors, presence, per-frame editing indicators, agent status and an activity feed. Agents connect over standard MCP OAuth, with add-flows for Claude Code, Codex, ChatGPT and Cursor, and any MCP client can use an agent key. Self-hosting takes either docker compose up -d (app plus Postgres) or a zero-config bun run dev with embedded PGlite. AGPL-3.0.

What stands out:

The README lists forty annotated MCP tools. Thirty-eight built in plus two from a Linear extension, grouped into Canvas, Frame, Prototype, collaboration, design memory, assets and web. The tools carry annotations such as read-only, destructive or idempotent. Annotations are metadata, not an independently enforced permission boundary; and the server registers no MCP prompts; guidance travels through tools and initialization instead.
It attacks "the agent cannot see what it drew". Three layers: a compact contract at initialization (load the guide, get context first, stream the design, review with screenshots); a get_guide tool with the deep playbook (review checkpoints, frame sizing, design-quality doctrine, multiplayer etiquette) loaded once per session and reloadable after context compaction; and results that talk back; after a frame write, the tool result tells the agent it has not seen its own design yet and to call get_frame_screenshot before continuing.
Drawing is streamed. append_frame_html wraps chunks with start=true and done=true, smoothed server-side, so viewers watch a design build up rather than jump into place.
Design memory is versioned guidelines plus distillation. set_guidelines keeps canvas-level style guides with version history, save_decision records a decision so later agents do not re-litigate it, and a human-pinned frame can be read as a "more like this" reference. Those feed a distiller that proposes durable style rules; nothing changes until a person accepts. The distiller is pinned to an Anthropic key and quietly turns off without one.
Agent identity comes from authorization. Whoever approves the OAuth connection is the agent's owner in tasks and presence; mutating tools accept agent_name, so the agent shows up in the presence stack with a pulsing avatar, gets an editing ring on the frame it touched, and lands in the activity feed. Inactivity expires it from presence after about 20 seconds.

Compared with: The reference point, Paper.design, is a closed product whose implementation cannot be read, so this is not a comparison of internals. Four things can be compared: whether an agent has its own identity and revocable authorization, whether the host verifies that an agent actually captured and inspected its work, whether style rules are versioned and readable by agents, and whether agents and people share one conflict semantics under concurrency. Each of the four has a corresponding implementation or document in this project.

Recent updates: v0.12.0 (10-31) signs the Windows app and installer with Azure Artifact Signing and fixes the token fetch right after Azure login; two more desktop releases landed the same day with empty notes, so the desktop line is moving fast.

Who it's for: Teams that want design collaboration on their own machine with agents editing HTML directly. Three caveats: the version is early (0.12), the exact AGPL-3.0 terms and any network-source obligations need to be checked for the intended deployment, and the built-in agent's free quota depends on a server key and is zero by default.

My take: ⭐⭐ The project is still small, but "correct model behaviour through tool results" is a technique worth remembering on its own.

Checked: read the README's MCP tool table and agent-workflow section, the v0.12.0 release record and recent commits; not deployed.

At a glance

Project	What it is	Most distinctive	Who it's for	Worth a deeper look
Orkas	Multi-agent desktop copilot	Explicit admission rules and fixed per-turn tool budgets	People who want an agent team on their own machine	⭐⭐⭐
rowboat	Local knowledge graph plus team collaboration	Its own agent uses the same MCP door as any other	Teams that need auditable memory	⭐⭐⭐
osaurus	macOS agent harness	Memory with budget and eviction, text redaction with documented refusal conditions	Privacy-sensitive Mac users	⭐⭐⭐
GEOFlow	Corporate-site content operations	The docs require one gate across four publish exits	Content teams with review duty	⭐⭐
doop	Multiplayer design canvas	Tool results instruct the agent to inspect screenshots	Teams letting agents edit designs	⭐⭐

Notes from this issue

The multi-agent projects in this issue put their effort into keeping a long run under control. Admission rules, explicit tool budgets, and a distinction between queued and completed work. These are documented design choices, not a reliability result from my own run. I would check those three before counting how many agents a project ships.
Both memory projects in this issue are subtracting. One cut its configuration from 18 knobs to 8 and injects at most 800 tokens per turn, sometimes none; the other writes memory as a Markdown graph a person can read and edit. Different routes, the same point: memory has to be inspectable and reducible.
Both publishing-related projects in this issue write evidence into the flow. A quality verdict must be able to block every exit, manual publication needs a lease and an execution receipt, and a stale base should return a resumable result rather than an error.
Getting an agent up to speed looks more like engineering than prompting. A contract at initialization, a playbook loaded on demand, corrections delivered through tool results, and a screenshot so the agent can see its own output: doop uses tool results to reinforce the workflow. I have not measured compliance or compared reliability against a system-prompt baseline.

Open Source Radar · 2026-10-31: Skill packs get an acceptance bar, SDKs start wrapping agents

十方空烬 · Ember ☄️ — Sat, 31 Oct 2026 06:58:01 +0000

By Renchao Wu. Originally published on widechaos.cn.

For this issue I picked five projects from GitHub Trending and topic-search candidates, all agent infrastructure: a skill pack, a rewritten headless browser, an Android agent, a multi-provider SDK, and a distributed inference mesh. I read each project's README, release notes and recent commits; I did not install them unless an entry says so. Stars and other numbers are from GitHub as of 2026-10-31.

1. jakubkrehel/skills ⭐ 9,398 · Markdown

GitHub: https://github.com/jakubkrehel/skills

In one line: A design engineer turned his interface-review method into 14 agent skills that plug into a coding agent.

What it is: The repository is Markdown only: 14 directories, each with a SKILL.md that agents discover through name and description frontmatter. better-interface is the orchestrator and routes a screen to six domain skills; accessibility, layout, writing, typography, colors, UI. interface-review, break, state-machine, variant, explain-interface and teardown are tools the user has to invoke. build-design generates UI from a Figma file or a design image. The material comes from the author's personal site and a design-engineering magazine rather than a copied checklist. The repo was created in July 2026, the latest commit is 25 October 2026, and there are no GitHub releases; the version number lives in commits.

What stands out:

The orchestrator only orchestrates. The first line of better-interface is "Orchestration is all it owns." It dispatches, collects evidence and merges one ranked report; accessibility rules belong to the accessibility skill, structure to the layout skill. The intended separation keeps domain rules out of the router; I have not audited all fourteen skills for duplication.
Approval has an evidence bar. Two sentences carry the method: "The bar for reporting is evidence. The bar for Approve is that you inspected what you claim to have inspected." It also separates a rule violation from a matter of taste: density, radius or voice are preferences, not findings; a trigger is a failure no matter what the style guide says.
Scope is fixed before judging. If the scope is too large, it narrows to one complete flow, states the boundary and what was excluded, and never implies that uninspected surfaces were reviewed. The orchestrator is also forbidden to guess a diff: change review must be started by the user through interface-review.
Which skills the model may not start is written into the skill. The pack marks user-invoked workflows in their descriptions; on a branch, PR or uncommitted change the orchestrator can only ask the user to run the review.
The output is values, not adjectives. The UI skill covers border radius, optical alignment, shadow levels, icon states and animation parameters; the typography skill covers type scale, spacing, font features, wrapping and truncation.

Compared with: expo/skills, also in today's candidate pool, is the other kind of skill pack. Both are collections of SKILL.md files. Expo's is a vendor's engineering workflow for one framework, installed through the official Claude Code and Codex plugin marketplaces, and its README says Expo docs, the CLI and EAS CLI remain the source of truth while the skills help an agent apply them correctly. Jakub's set is an independent author's cross-cutting review of how an interface should look, distributed through skills.sh and npx. The difference is not the number of skills; it is whether the pack makes clear who may reach a verdict and who may start a skill.

Recent updates: A commit bumped the version to 1.17.0 on 25 October 2026 and added playback and annotation to the technical-illustration viewer; the same round renamed /technical-drawing to /teardown. No formal release; the project iterates on main.

Who it's for: People writing frontend code, maintaining a design system and already using Claude Code or Cursor. The skills are in English and assume the project has design tokens and a component library. If the project has no component conventions yet, run build-design first rather than expecting a review skill to invent a design. MIT licensed.

My take: ⭐⭐⭐. The design rules are learnable elsewhere; what is worth copying is the structure; the orchestrator only routes, the skill requires inspection evidence before approval, and some skills are off-limits to automatic invocation.

Checked: read the README, the full better-interface/SKILL.md, recent commits and the root LICENSE; did not install.

2. lightpanda-io/browser ⭐ 38,506 · Zig

GitHub: https://github.com/lightpanda-io/browser

In one line: A headless browser written from scratch for agents and automation; not a Chromium fork, not a WebKit patch.

What it is: The browser core and DOM are implemented in Zig; the README says it has no graphical rendering engine, JavaScript runs on V8, HTML parsing uses Servo's html5ever, and networking uses libcurl. It presents three faces: fetch dumps a page as HTML, markdown, PNG, PDF or structured data; serve starts a CDP server on port 9222 with a documented Puppeteer browserWSEndpoint example, not a guarantee of full Chrome CDP or website compatibility; mcp starts an MCP server over stdio or HTTP for an agent. The repo dates from February 2023; version 1.0.0 shipped on 2 October 2026, followed by 1.0.1 and 1.0.2 within three weeks.

What stands out:

Export is a first-class feature. fetch --dump markdown returns readable text, and --dump structured_data returns JSON-LD, OpenGraph, Twitter card, meta and link tags as JSON, the same source as the MCP structuredData tool. For feeding pages to a model, that removes a home-grown HTML cleanup step.
An agent session can become a replayable script. Drive the browser in natural language, run /save, and the session is exported as PandaScript; plain JavaScript over native browser primitives; then replayed with lightpanda run. The project calls these scripts deterministic and token-free. Replay can avoid model calls while still depending on changing pages, timing, authentication and network responses; I have not tested repeatability.
MCP exposes separate browsing contexts. The README describes separate HTTP browsing sessions and context reuse through Mcp-Session-Id. Session identity is not the same as a TCP connection, an authenticated user or an audited security boundary. The session_new, session_list and session_close tools manage them explicitly.
After 1.0 it has been filling in real-site compatibility. 1.0.0 made CORS enforced by default and built out classic HTTP WebDriver. 1.0.1 made MCP and agent modes load external stylesheets by default and raised the redirect limit from 10 to 20. 1.0.2 added Ed25519, X25519 and ECDSA in Web Crypto, plus WebCodecs and OfflineAudioContext.
Telemetry is on by default. The README states that usage telemetry is collected and sent unless LIGHTPANDA_DISABLE_TELEMETRY=true is set.

Compared with: The difference from headless Chrome is mechanical. It does not carry Chromium's rendering stack, so page capture collapses into one fetch --dump, and an agent's exploration can be frozen into a script that needs no model at runtime; Chrome has automation and export paths too; I have not compared setup effort or output fidelity. The performance numbers need their source: the README's table reports 933 real pages over the network on an AWS EC2 m5.large, with 100-page peak memory of 123MB against 2GB for Chrome and 5 seconds against 46 seconds. Those figures are self-reported and collected by the project's own demo repository; I did not re-run Chrome on the same benchmark.

Recent updates: 1.0.2 on 23 October 2026 gave each top-level page its own session history, extended --block-private-networks to CGNAT, benchmarking, reserved and NAT64 ranges, and fixed a batch of Web API details. 1.0.1 on 15 October fixed stylesheet loading in MCP and agent modes and raised the redirect limit.

Who it's for: People building scraping pipelines who need JavaScript but not full rendering, and anyone who wants a lighter execution environment for an agent. Three limits come first: the license is AGPL-3.0-only, and the repository's LICENSING.md says only that the default license is AGPL-3.0-only, with no separate commercial terms; the reviewed installation instructions direct Windows users to WSL2; the distributed Linux binary expects glibc; do not assume that binary runs unchanged on a musl system such as Alpine.

My take: ⭐⭐⭐. It turns "a browser designed for agents" from a slogan into interfaces: structured export, recordable scripts, multi-session MCP. Version 1.0 is three weeks old, so long-term stability is unknown, but the direction matters more than the benchmarks.

Checked: read the README, the 1.0.0, 1.0.1 and 1.0.2 release notes, LICENSE and LICENSING.md, and recent commits; did not install.

3. wangzan101/Mika ⭐ 1,589 · Kotlin

GitHub: https://github.com/wangzan101/Mika

In one line: An Android-hosted agent designed to operate installed apps on a separate background display, browses the web and runs scripts, and can be called by AI tools on a computer over MCP.

What it is: You give it one sentence; it opens the target app on a separate background virtual display, reads the screen, taps, types and scrolls with concurrent phone use depending on Android version and application behaviour. When controls cannot be read it falls back to bundled text recognition, and with a vision model it can look at the screen to find buttons. Three more capabilities sit alongside: a built-in browser (desktop pages by default, logins preserved), a Linux sandbox per conversation (arm64, network off by default), and an MCP server over USB. The code is two Gradle modules: :core is pure Kotlin holding the main loop, tools, context, memory, knowledge and run records, testable on a computer with fake models; :app holds the virtual display, accessibility, WebView and sandbox. Capabilities do not reference each other, the core does not reference a capability, and one assembly layer wires them together; a dependency test guards that direction. The repo was created on 29 October 2026 and went from 0.1.12 to 0.1.14 in two days.

What stands out:

A steer is an addition, not a restart. Inputs during a run are split into Steer, Redirect, Answer, Confirm, HandBack and Cancel. A steer cancels the pending model request, but messages already sent stay byte-for-byte and a tool call already handed to the executor finishes; the steer is appended before the next model call, so the context prefix only grows.
Waits are interruptible without losing pacing. Plain waits, vision tools, conditional waits inside a batch and the dwell before a page change all sit behind an interruptible wait that ends with a "skipped for new message" marker. The unused part of a dwell or action interval is still owed by the clock and is paid before the next outward action, the design intends to preserve pacing after interruption; I have not verified the scheduler under races.
Stopping leaves an account. After a stop, one model call (light model first, 12-second budget) writes down what was done, what was seen, how many outward actions were sent and what was left unfinished; if that fails, the run record is rendered directly. The next turn's context says "you stopped this task midway; before stopping: …".
Delivery has a ledger and does not resend unknowns. States run Pending → Attempting → Delivered / Failed / Uncertain; the documentation says an uncertain send is not retried automatically. This avoids one duplicate-send path; it does not prove end-to-end exactly-once delivery.
A process restart never resumes from the middle. The recovery design accounts for interrupted runs and pending replies without replaying screen actions. Pending replies must be distinguished from sends with unknown outcomes. The documentation's phrase is that screen state cannot be restored.
Human hand-back is part of the flow. Every run carries Present, Reachable or Unattended. The current README asks for hand-back on login, verification codes and payment passwords. Inquiry mode asks before spending, while autonomous mode may proceed without that prompt; unattended and MCP payment paths have separate restrictions. Hand-back states do not prove that every consequential action requires approval.

Compared with: I did not find first-hand material on comparable projects this round, so I am not naming a competitor. The workflow differences I can confirm are the three the documentation states: three layers of screen reading (virtual display, accessibility, bundled OCR); a desktop browser and a local Linux sandbox without external hardware; and an MCP server that lets an agent on a computer call the phone, USB-only by default and token-protected. The scarcer part is the granularity of failure handling; those state machines are not a feature list, they are documented failure-handling choices, not independently verified recovery guarantees.

Recent updates: 0.1.14 on 31 October 2026 made the computer link an MCP server (USB plus token; payment confirmation stays on the phone) and fixed saving a provider such as Gemini getting stuck on a retired model. 0.1.13 on 30 October added starting from a computer over a cable, letting an AI agent on the computer perform the install, and an operation-pace setting (fast, standard, human-like) that slows down on apps with strict bot detection and caps the number of screens browsed per task.

Who it's for: People who want Android-hosted automation. The README explicitly says messages, screen content and screenshots go to the configured model provider; on-device execution does not mean screen data stays on the phone. The thresholds are real: the current README says Android 11 supports chat, web and sandbox tasks, Android 12+ supports app control, and Android 14+ is recommended for independent background-display focus; the sandbox is arm64 only; the author labels it a beta tested mainly on one Android 14 phone. The README also warns that automating third-party apps may violate their terms and risk restrictions or account bans. Apache-2.0.

My take: ⭐⭐⭐. The hard part of an on-device agent is not tapping accurately but accounting for failure; treating steers, stops, delivery failures and process restarts as first-class concerns is more instructive than the feature list.

Checked: read the Chinese README, docs/architecture.md, the 0.1.13 and 0.1.14 release notes, recent commits and LICENSE; did not install (no Android device at hand).

4. vercel/ai ⭐ 27,635 · TypeScript

GitHub: https://github.com/vercel/ai

In one line: Vercel's AI SDK, a provider-agnostic TypeScript interface; what is new in 7.x is that it abstracts agents as well as models.

What it is: The core is one entry point: a provider/model string supplied to generateText goes through Vercel AI Gateway by default, or through a provider package installed directly. On top sit ToolLoopAgent with a tool loop, structured output via Output.object() with zod, and framework-agnostic UI hooks. packages/ holds 84 directories: providers plus mcp, otel, policy-opa, code-mode, sandbox-just-bash, sandbox-vercel, tui and workflow. The current ai package is 7.0.159 (30 October 2026), and the v6 line still received a patch the same day.

What stands out:

The abstraction moved from model to agent. packages/ contains 10 harness adapter directories for specific agents (including Claude Code, Codex, Cursor, Cline, GitHub Copilot and OpenCode) plus a generic ACP adapter. The usage is new HarnessAgent({ harness: claudeCode, sandboxConfig, tools }): the child agent reads and writes files and runs commands inside a sandbox, while the host passes its own capabilities in through tools. Both packages are marked experimental.
Gateway by default, direct providers when needed. Without provider packages, one key covers many vendors; when latency, region or terms matter, use direct provider packages while retaining the high-level API. Provider options, supported features and data-handling terms still differ.
The tool loop ships with the library. Model asks for a tool, the tool runs, the result is fed back, the model is asked again; that loop lives in a class, and the frontend consumes the stream through createAgentUIStreamResponse with input-available and output-available states to render.
Some structured-output paths have a fallback. A recent Anthropic-related change maintains a tool-based JSON response path for some schemas. This is provider- and version-specific, not a universal guarantee that every unsupported schema is repaired or every task constraint is satisfied.
The sandbox is a replaceable interface. The session interface gained stat, listDirectory and deleteFile, with relative paths resolved against the directory run and spawn start in; both the just-bash and Vercel Sandbox adapters implement it.
It also ships a skill for coding agents. A README section called "Skill for Coding Agents" installs SDK guidance with npx skills add vercel/ai, so the documentation's audience includes agents, not only people.

Compared with: Against calling each provider SDK directly and writing your own retries and tool loop, the difference is a verifiable workflow: one interface covers text, structured output, tools, streaming UI and sandboxes, and the high-level call pattern can stay similar when switching providers; feature compatibility still needs testing. The harness layer goes further and treats an existing coding agent as an orchestration component instead of asking you to rebuild one. The limits are equally clear: it is a TypeScript SDK, so Python is not its native integration surface; a Python service can still communicate with a TypeScript service over an API; harness and ACP are experimental and recent commits still add required callbacks; the model-string default uses a commercial gateway, while direct provider packages offer another path. Self-hosting the application does not by itself make model inference local.

Recent updates: 7.0.158 on 30 October 2026 added stat, listDirectory and deleteFile to sandbox sessions. A 31 October commit made harness-acp require new resolveHostToolCall() and isMcpToolCall() callbacks, and tool-web-fetch now returns network_error for an invalid redirect instead of throwing. 7.0.159 was a dependency bump only.

Who it's for: TypeScript and Node teams building multi-model products or agent frontends, and people already using Claude Code or Codex who want one orchestration layer. Apache-2.0 (I read the root LICENSE). Treat harness as experimental because its interface is moving, and if production must avoid the commercial gateway, write the provider packages and failover before launch.

My take: ⭐⭐⭐. Provider abstraction has been table stakes for a while; the real signal is that it now abstracts agents, which makes existing coding agents available as components. It does not establish market saturation or reliable interchangeability.

Checked: read the README, packages/ai/package.json, the harness and harness-acp READMEs, release notes, the root LICENSE and recent commits; did not install.

5. Mesh-LLM/mesh-llm ⭐ 3,687 · Rust

GitHub: https://github.com/Mesh-LLM/mesh-llm

In one line: It pools GPUs and memory across machines and exposes the result as one OpenAI-compatible endpoint.

What it is: Two product trees share one Cargo workspace. Skippy owns model management, native inference, split execution and OpenAI serving; Mesh adds peer discovery, transport, routing, plugins and a web console. The README describes mesh-llm serve --auto as selecting a backend, potentially downloading a model and joining a public mesh, with API and console ports 9337 and 3131. This is a documented default, not a recommendation to send private prompts to discovered peers. The scheduling rule is single-machine fit first: if one node holds the whole model it serves locally with no stage traffic; otherwise layers are split into contiguous ranges, downstream stages start first, and the stage-0 route is published once they are ready. The project describes QUIC-encrypted peer transport, public meshes are discovered through Nostr, and private meshes use invite tokens.

What stands out:

Fetch shards by package instead of downloading the whole model. A package repository holds model-package.json plus GGUF fragments, and each peer fetches only the pieces its stage needs. The larger the model, the more this "shard as deployment unit" matters.
Single machine first, so distribution is not a default. --local-model-only bypasses the mesh entirely and serves one local process; that path skips discovery, splits, plugins and the console, so tool-calling production traffic is still expected on the normal mesh port.
Encrypted transport does not mean peers cannot see content. QUIC encrypts node-to-node traffic and relays forward encrypted packets without reading them, but on a public mesh the peer serving a request still sees the request and response. The project does not dress this up as a privacy guarantee.
The mixture-of-agents gateway is experimental. A request with "model": "mesh" fans out to every model in the mesh and the project describes a code arbiter that merges answers and may escalate conflicts to a reducer model. A deterministic arbitration rule does not make model outputs deterministic or prove conflicts were correctly identified. The project marks it experimental and says semantics will change.
Compatibility rests on its own matrix. It tracks llama.cpp family parity: the project reports 72 P0/P1 family rows and 89 rows labelled certified in its inventory; it labels split multimodal support for Qwen2-VL, Qwen3-VL, Qwen3-VL-MoE, HunyuanOCR/Hunyuan-VL and DeepSeek-OCR.
It puts "not usable yet" on the front page. The README lists three distribution and loading bugs still blocking the native Windows path as of v0.76.0-rc8 (installer verification, missing Windows runtime, DLL load error 126) and gives a manual workaround sequence.

Compared with: The relationship to llama.cpp needs to be exact. This is not another inference kernel: the README says Skippy uses a patched llama.cpp runtime and tracks llama.cpp family parity. The difference is the layer above it; splitting a model that does not fit on one machine into contiguous layer stages, fetching shards by package, encrypting peer traffic with QUIC, discovering public meshes through Nostr, and presenting one OpenAI-compatible endpoint. Against rolling your own inference cluster plus a load balancer, the trade-off is putting splitting and routing into one binary, at the cost of a self-maintained compatibility matrix and network transfer, the stage schedule and bottleneck compute. I have not measured how these costs interact. The README gives no end-to-end throughput for cross-machine splits, and I did not measure one.

Recent updates: 0.78.1 on 5 October 2026 fixed three issues: chunked requests now go through admission, a rejected wallet identity fails closed on reopen, and an Auto tool request is no longer refused when capability metadata is missing. 0.78.0 on 4 October let a plugin page request the primary tab, let catalog entries pin a version and per-platform SHA-256, and hosted mixture-of-agents as a virtual model. The rolling preview on 30 October fixed a stalled inbound frame on Windows, sized the model-open queue and added a plugin guide for the DwarfStar engine.

Who it's for: Teams with two or three GPU machines who want to run a model too large for one box, or who want a private inference mesh. If one machine is enough, compare the simpler local path before adding cross-machine routing; its operational cost needs measurement. Apache-2.0. Windows users should follow the README workarounds rather than assume it works out of the box.

My take: ⭐⭐. The direction is right; it offers a cross-machine route when one machine cannot hold a model. I have no basis here for predicting which deployment pattern will dominate. But maturity depends on operational detail, and I have no numbers for cross-machine split latency, so I would watch it before depending on it.

Checked: read the README, the 0.78.0 and 0.78.1 release notes, the root LICENSE, recent commits and the Windows troubleshooting section; did not install (no multi-machine GPU environment).

At a glance

Project	What it is	Most distinctive point	Who it's for	Worth a look
jakubkrehel/skills	Interface-review skill pack	The orchestrator only routes, and the skill requires inspection evidence before approval	Frontend people using coding agents	⭐⭐⭐
lightpanda-io/browser	Headless browser built for agents	Agent sessions export to scripts intended to replay without model calls	Scraping pipelines and agent runtimes	⭐⭐⭐
wangzan101/Mika	On-device Android agent	Steers, stops, delivery and restarts are state machines	Personal Android automation	⭐⭐⭐
vercel/ai	Multi-provider agent SDK	Wraps existing coding agents as sandboxed sub-agents	TypeScript teams	⭐⭐⭐
Mesh-LLM/mesh-llm	Distributed inference mesh	Layer splits, package shards and QUIC transport	Running large models across machines	⭐⭐

Notes from this issue

Skill packs are starting to layer, and the test is who may reach a verdict. One router-only orchestrator, six non-overlapping domain skills and user-invoked workflows; that structure separates routing, findings and authority. Its effectiveness still depends on the host following it. A skill pack becomes a product when responsibility is clear, not when the content is long.
The agent boundary is moving toward execution surfaces while decisions concentrate. This issue's projects turn a browser, a phone and someone else's coding agent into execution surfaces. The common move is separating where work happens from who decides: the browser exports structured results, the phone taps, the child agent works inside a sandbox. The higher the abstraction, the more precisely it has to answer which step must return to a person.
Engineering quality in on-device agents shows up on the failure paths. How a steer preserves completed work, what a stop leaves behind, whether an uncertain delivery is resent, whether a restart resumes; none of that appears in a feature list, yet it decides whether the thing is usable every day. Read the state machine before the demo.
Distributed inference also has an operational barrier. Layer splits, package shards and encrypted transport are all buildable; what is hard is a stage going down, versions drifting apart, or a Windows package failing. Whether a project puts those on its front page says more about maturity than its star count.

Open Source Radar · 2026-10-30: 29 more documents, and the game ranked last

十方空烬 · Ember ☄️ — Fri, 30 Oct 2026 06:52:22 +0000

By Renchao Wu. Originally published on widechaos.cn.

For this issue I picked five projects from GitHub Trending and topic-search candidates, mostly AI agents, developer workflow and document processing. I read each project's README, release notes and recent commits; I did not install them unless an entry says so. Stars and other numbers are from GitHub as of 2026-10-30.

1. Donchitos/Claude-Code-Game-Studios ⭐ 29,418 · Shell

GitHub: https://github.com/Donchitos/Claude-Code-Game-Studios

In one line: A template that defines a game-studio workflow inside Claude Code, with roles, reviews and gates; 49 agents, 74 skills, 15 event hooks.

What it is: A skeleton you clone to start a project. .claude/agents/ holds 49 agent definitions (Markdown plus YAML frontmatter), skills/ holds 74 slash commands, hooks/ holds 15 event hooks, rules/ holds 14 path-scoped coding standards, docs/templates/ holds 62 document templates. Agents sit in three tiers: three directors (creative, technical, producer), ten department leads, and specialists below them. Godot 4, Unity and Unreal 5 each get their own agent set. The repository was created in February 2026 and shipped v1.2.0 on 19 October.

What stands out:

One switch governs six knobs. modes.rigor in project.yaml takes minimal, standard or full and, behind it, controls six things at once: which GDD sections are required, documentation density, QA evidence, story granularity, how many directors review, and team size. /start asks the question once. You can still set any of the six individually; review mode and team size can also be overridden per person in a gitignored project.local.yaml, keeping the team default separate from personal preference.
It publishes a measurement that argues against itself. The author reports building four games from one brief at different rigor levels, counting the documents written before the first line of game code: minimal wrote 1 (a one-page brief) in 0 minutes; standard wrote 30 in 58 minutes. The README reports that all four ran and were tested, and that two blind reviewers plus a human playtest ranked the standard build last. This small comparison does not isolate documentation as the cause or establish a general ranking of process levels. The README says it plainly: the extra 29 documents bought traceability, not a better game.
"Ran and looked at it" is the bar for done. A story that changes anything the player sees is not closed until the game has been launched, observed, and a screenshot kept in production/qa/evidence/. The README's phrasing is short: a parse check is not a run. This holds at every rigor level; minimal waives automated tests but not the look.
The skills have their own test bench. studio-tests/ catalogs all 74 skills and 49 agents with per-category quality rubrics and behavioural specs. /skill-test static runs 7 structural checks, /skill-test category applies the category rubric, /skill-test spec asserts behaviour, /skill-test audit reports coverage. /skill-improve runs a change-test-retest loop that keeps or reverts based on the score.
Some checks run in tool hooks. The project describes seven validate-*.sh hooks configured for Bash, Read, Write and Edit calls and exit 0 immediately when the command or path is irrelevant. Two are worth naming: a design document over 40 KB cannot be read whole; the hook answers with its headings so the retry reads one section; and a subagent that stops without writing the file its brief named raises a warning. That last one is the quietest failure mode in long agent runs.

Compared with: I have not read the other multi-agent templates closely enough to name them, so no call-outs. What is verifiable is three structural choices: process weight collected behind one entry point instead of spread across docs, skills treated as testable objects with structural checks and behavioural specs, and some checks implemented in hooks. A warning is not a block, and actual enforcement depends on the host loading those hooks.

Recent updates: v1.2.0 (2026-10-19) rebuilt the six main-path skills around shared helper scripts, to centralise repeated workflow decisions; added the 40 KB read guard; moved engine references to Godot 4.7 and Unreal 5.8; and stopped any skill from pre-approving every shell command. The earlier v1.1.3 fixed one concrete behaviour: Claude Code re-attaches only the first part of a skill after a compaction, so the later phases of a long skill could vanish mid-session, and the 14 longest skills were repaired one by one.

Who it's for: Someone building a game alone or in a small team who wants the session to have structure and gates. Two things to know before starting. First, open the session at the project root that holds CLAUDE.md; the README warns that starting in src/ may bypass its intended configuration; verify what the actual host loaded. Second, every skill and hook reads project.yaml through Python 3, and the README warns that configuration reads fall back to defaults when Python is missing. This is not a claim that every validation hook then permits every action. MIT licensed.

My take: ⭐⭐. Skip the game content and read the process-governance pages; especially the part where it puts its own negative result on the front page.

Checked: read the full 440-line README, three release notes and the five most recent commits; not installed.

2. cocoindex-io/cocoindex ⭐ 11,785 · Rust

GitHub: https://github.com/cocoindex-io/cocoindex

In one line: An incremental indexing framework that represents the intended target state as a function and tracks updates; codebases, meeting notes, mailboxes and PDFs in, fresh vector indexes and knowledge graphs out, with incremental recomputation where its dependency tracking applies.

What it is: The mental model is one line: Target = F(Source). You declare what the target should contain; the engine keeps it consistent with the source files and with your code. In Python that is a decorator: a function marked @coco.fn(memo=True) is cached by hash(input) + hash(code). The core is Rust and Python is the facade. Chunking runs in parallel, data is copied zero times where possible, and one bad record does not stall the flow. State lives in a local LMDB store, which is embedded and needs no separate service. Created March 2025; v1.0.26 shipped 22 October.

What stands out:

The cache key includes a hash of the code. That is the real difference from "has this file changed" logic: the engine uses inputs and code identity to invalidate memoised work. External services, model revisions, configuration and undeclared dependencies still need an explicit invalidation strategy; a code hash alone does not capture them.
Preview avoids committing pipeline state. The release notes describe preview as avoiding memo and committed-state writes. That does not establish that arbitrary user functions or external services invoked during a preview have no side effects. Before v1.0.26 it stopped almost immediately on most pipelines, because it could not handle target state inside a container (rows in a Postgres, Qdrant or LanceDB table); now it can, so you can dry-run a change and reconcile first.
Supply-chain incidents go into the release notes. v1.0.26 excludes litellm 1.107.0 from every extra and example, and says why in the body: the project reports that version as carrying a credential stealer and backdoor, and identifies its locked 1.96.2 as unaffected by that incident. I have not independently audited either package or the incident. More useful than quietly bumping a version.
Long-running failure modes get fixed one by one. v1.0.24 fixed a hard one: an LMDB write transaction could resume on a different runtime thread and leave the writer lock held forever, blocking every later write; the same release fixed two overlapping updates with the same memo key running a component twice. v1.0.25 added an explicit way to close the environment so the same path can be reopened at once. These are concrete concurrency and lifecycle fixes described in its release notes.
Lineage down to the source byte. The README claims every target point traces back to its exact source byte. For questions like "why was this summary written this way", that is useful provenance, but it does not by itself explain model reasoning or prove the source is correct. I did not test lineage completeness or query costs.

Compared with: Against a vector store plus a hand-written sync script, the difference is who computes the incremental boundary. You write F; the engine works out which results changed, which stale rows to retire, and which joins and lookups must follow. Against task-graph orchestration in the traditional ETL sense, the single source of truth here is the target state and the system converges toward it when a source changes; the README states outright that it is not a DAG. In fairness, the home page also sells an enterprise edition and the open-source core is the engine plus connectors; the coding-agent sub-project linked from the README quotes figures such as 70% fewer tokens per turn and 80–90% cache hits on re-index, which are the project's own claims and which I did not reproduce.

Recent updates: v1.0.26 (2026-10-22) made preview handle container targets without writing, and dropped the poisoned litellm version; v1.0.25 (2026-10-06) added explicit environment close and a re-collect switch for memo state; v1.0.24 (2026-09-20) fixed the cross-thread LMDB writer lock and duplicate execution under concurrency. A 28 October commit made the in-flight pool share fairly between live components.

Who it's for: Teams that must keep feeding a changing corpus to a model; knowledge bases, code indexes, documentation sites. Two cautions: state is a local LMDB store, so do not open the same path from two processes; and its release notes document a dependency exclusion, not evidence that every installation was compromised; review the applicable pins and advisories.

My take: ⭐⭐⭐. It turned a small chore; incremental indexing; into a general mechanism instead of a feature bolted onto one product.

Checked: read the full README, three release notes and the five most recent commits; not installed.

3. xberg-io/xberg ⭐ 9,464 · Rust

GitHub: https://github.com/xberg-io/xberg

In one line: An engine whose README lists 107 document formats and text, table, metadata and structured-output paths, with OCR, layout reconstruction and code-structure extraction built in.

What it is: Format detection, reading, OCR, layout and table reconstruction, and structured extraction all sit in one core, which removes the usual assembly of one path for PDFs, another for Office files, a third for images. Sources include PDFs, Office files, scans, HTML, email, e-books and papers, plus URLs, archives (documents inside documents, recursively unpacked) and audio or video. Output takes six forms: plain text, Markdown, Djot, HTML, a JSON tree, or Docling DocTags, with custom renderers allowed. The integration surface is wide: 15 language bindings, 14 CLI commands, one REST endpoint for every format, and an MCP server with 9 tools. Created January 2025; v1.3.10 shipped 13 October.

What stands out:

One core for the whole chain. Detection, reading, OCR, tables and code structure live in the same place. This reduces some integration boundaries; I have not compared total maintenance effort or extraction quality.
Four OCR backends, swappable and degradable. Tesseract, PaddleOCR, Candle and VLM, with fallback chains, confidence scores, language auto-detection and plugin extension. Layout uses PP-DocLayout-V3 or RT-DETR; table structure uses TATR or SLANet, aimed at reconstructing reading order and cell grids into clean Markdown.
A parse failure is a first-class outcome. v1.3.9 added strict_parse. With the default false, a YAML, JSON, TOML or XML file that fails to parse, an XML or SVG file that trips the entity-length limit, or a CSV or TSV that trips the cell limit is extracted as plain text, and the reason goes into processing_warnings under the source parse-fallback; set it to true and the run fails instead. For silent failures of the "the file entered the system but nothing was read" kind, this matters more than supporting ten more formats.
Safety limits are configuration, not comments. Archives get zip-bomb, compression-ratio and nesting-depth limits; XML gets an entity-length cap; tables get a cell cap; content gets a maximum size. These are documented limits, not an independent security audit of their enforcement.
The path runs from document to retrieval. Local ONNX or hosted embeddings, sparse and late-interaction representations, cross-encoder reranking, plus code intelligence for 371 languages; functions, classes, imports, symbols, docstrings; with syntax-aware chunking.

Compared with: Against tools that only convert documents to Markdown, the difference is not conversion quality but shape: one parse result is designed to support text, Markdown, a JSON tree and DocTags renderers, and continues into embeddings and chunking, merging cleaning and indexing into one stage. One caveat: the README calls itself the fastest and most precise open-source document and PDF-to-Markdown engine and links to its own benchmarks page; I did not check the evaluation method, the corpus or the comparison targets. Its lineage is also stated as "the next iteration of Kreuzberg", and the linked repository returns 404 today while another repository in the same organisation was visible during the source review; the succession claim currently rests on the project's own sentence, so verify licence and API compatibility before migrating.

Recent updates: v1.3.10 (2026-10-13) fixed a layout bug where a margin-note column beside the body was discarded; when body lines are set as one span per line and wider than 55% of the page, every line was dropped as full-width furniture, so the two-column repair never saw the column beside the notes; v1.3.9 added strict_parse; a 29 October commit retained recoverable candidates in structured extraction and added an acceptance harness for the classic OCR cache.

Who it's for: Anyone feeding messy documents into retrieval or analysis; legal material, research reports, scans, multilingual contracts. Notes: it runs on CPU by default with no GPU required, though OCR and layout models cost memory and time; url-ingestion, transcription and reranker are Cargo features, so a from-source build enables only what you choose while prebuilt packages bundle the common set.

My take: ⭐⭐⭐. In document parsing, describing the failures clearly is harder than adding formats.

Checked: read the full README, three release notes, the five most recent commits and the licence entry; not installed.

4. microsoft/flint-chart ⭐ 4,506 · TypeScript

GitHub: https://github.com/microsoft/flint-chart

In one line: A visualization intermediate language for AI agents; the agent writes only data, semantic types, chart type and encodings, and the compiler fills in axes, ticks, spacing, labels and legends before compiling to one of five backends.

What it is: The input is a chart spec: data, semantic_types, chart_spec (chart type plus encodings), with optional theme and interaction specs. The compiler resolves these against each other; semantic types decide how a field is parsed, which scale to use, how axes are ordered, how numbers are formatted and how colours are assigned; and composes a complete backend-native spec. The README lists 52 chart types across 5 rendering backends (Vega-Lite, ECharts, Chart.js, Plotly and native Excel charts), 14 themes and 23 interaction presets, with an npm library, an MCP server and chart-authoring skills for coding agents. The method has a paper: arXiv 2607.20775, "Flint: A Semantics-Driven Data Visualization Intermediate Language". Created May 2026; 1.0 shipped 21 October.

What stands out:

Semantic types are compiler input, not comments. A field marked Rank, YearMonth, Delta or Temperature, with a domain and unit, feeds parsing, scales, axes, formatting and colour. In a plain backend spec that information usually has to be hand-written onto every field.
Themes act at compile time. A theme takes part in compilation, governing density, spacing, sizing and stretch limits, and resolving labels, legends and axes conditionally on a chart's semantics, data, cardinality and available space. You can extend a preset and override only the brand item rather than rewriting the whole thing.
Interaction is part of the spec. Beyond 23 presets there is a programming API: the compiler resolves user events into semantic information and the app answers with high-level updates instead of wiring low-level events itself.
Several backend targets, Excel included. The project provides native Excel chart templates. Do not assume every chart type or interaction is supported identically across all backends.
No pixels in the spec. Layout is derived by the compiler from data cardinality and available space, so the model is not guessing margins in its input.

Compared with: Against asking a model to emit an ECharts or Vega-Lite option directly, the difference is what the spec leaves out; layout and theme are not written into the input, both are derived from the data and the canvas, so the model specifies fewer layout fields. That is a design choice, not a measured error-rate reduction here. Against a chart library plus post-hoc style overrides, the theme is a compile-time constraint rather than a rendering patch. Other libraries' trade-offs; learning cost, ecosystem, ceiling on customisation; weigh differently for different people, and I ran no same-data, same-machine comparison, so no head-to-head here.

Recent updates: 1.0 (2026-10-21; the README's update section says 19 October) added interactions; linked brushing, annotations, semantic zoom, coordinated chart and table views; in both the MCP server and the npm library; 0.5.1 (2026-08-14) extended themes to Plotly and added a Vega-Lite calendar heatmap; 0.5 (2026-08-06) introduced the theme specification as a compile-time participant rather than a skin; 0.4 (2026-07-24) added 38 Plotly chart types and 18 native Excel templates.

Who it's for: Anyone who needs an agent to produce charts reliably, or who renders the same chart in several places (web, notebook, Excel report). Notes: it emits a spec and renders it, it does not fetch data; the Python port is preview source only with no released package. MIT licensed.

My take: ⭐⭐⭐. This project's selling point is how short the spec is rather than what it can draw, and it delegates layout decisions to the compiler; I have not measured the effect on model errors.

Checked: read the full README, three release notes, the README's update section and the paper's abstract page (title and abstract only, body not read); not installed and no chart rendered.

5. Natively-AI-assistant/natively-cluely-ai-assistant ⭐ 3,128 · TypeScript

GitHub: https://github.com/Natively-AI-assistant/natively-cluely-ai-assistant

In one line: A local-first desktop assistant that captures system audio and microphone on two channels, transcribes live and drafts answers as the conversation happens; for interviews and meetings.

What it is: A translucent always-on-top overlay. It captures the meeting's audio from the operating system and your own voice from the microphone as two separate streams, transcribes in real time, keeps a rolling context, analyses screenshots on request, and produces "what to say next" from whichever model you pick. The README describes local storage and local or cloud model choices. Audio, transcripts or screenshots sent to a cloud provider leave the device; local-first does not mean zero network traffic. It is an Electron app, but audio and native work sit in Rust: the README describes zero-copy transfers over napi::Buffer to reduce copies on that native boundary; this does not establish that continuous capture creates no V8 allocation or garbage-collection work (the project claims lower latency and CPU than typical Electron competitors; I did not measure it). Storage is SQLite with sqlite-vec. Created January 2026; v2.9.2 shipped 5 October.

What stands out:

Separate system-audio and microphone paths. System audio carries what others say, the microphone carries what you say; the microphone channel doubles as a private question channel, so you can ask something without muting the meeting app.
Two-stage silence detection. An adaptive RMS threshold screens first, then WebRTC's machine-learning VAD, aimed at rejecting typing and fan noise. I have not measured its false-positive rate or transcription accuracy.
Three concrete choices in local retrieval. Sliding-window chunking with 50 tokens of semantic overlap to avoid losing context across chunk boundaries; epoch summarisation instead of hard truncation, so early content survives; and a check for whether you are asking about this meeting or a past one.
Multiple providers with fallback. When one fails or stalls it moves to the next and tells you which one answered; a token bucket is intended to limit request rate. Provider quotas, concurrency and other limits can still produce rate-limit errors.
The licence is a real issue. The repository description uses open-source language, but the current README explicitly calls it source-available and the LICENSE text says source-available, not open source: personal, educational, research and non-commercial use only, with commercial use, SaaS, client work and internal business use all requiring written permission. GitHub reports NOASSERTION; that label alone does not establish the reason or grant reuse rights.

Compared with: I did not verify the competitors' current pricing or implementations, so I am not repeating its comparison table. Only two differences are verifiable: audio moved down into Rust with zero-copy transfers, and dual-channel capture with a two-stage VAD. Those are documented architectural choices. I did not locate and reproduce a controlled latency comparison. The repository promotes interview-assistance use, including stealth features, and cheating is among the repository's own topics; the README says it does not encourage misuse and admits that stealth is best-effort and does not defeat dedicated proctoring software.

Recent updates: v2.9.2 (2026-10-05) made auto-answer decide whether a question was meant for someone else, drew flow and sequence diagrams inside answers, mirrored the meeting to a phone, and added calendar sync plus embeddings and rerankers; v2.8.8 (2026-08-26) replaced the answer engine and rebuilt meeting notes; a 30 October commit shipped browser extension 1.3.1 and fixed a paid user's reports covering antivirus flags, multiple monitors and 30 PDFs.

Who it's for: People who want to take apart a desktop real-time audio path; dual-channel capture, VAD, transcription and segmentation, multi-provider fallback. Not recommended as open-source code to reuse: the licence requires written permission for commercial and client use. The current licence applies to releases on or after its stated effective date; it says earlier grants are not retroactively removed. Check the exact version and intended use; public source access is not commercial permission.

My take: ⭐⭐. The architecture is worth reading; the licence and the purpose stop it at reference.

Checked: read the full README, the LICENSE text, the release history and the five most recent commits; not installed.

At a glance

Project	What it is	Most distinctive	Who it's for	Dive in
Claude-Code-Game-Studios	Multi-agent game-dev template	One rigor switch governing six process knobs, plus a reported four-build comparison where the standard build ranked last	People building games who want structure in the session	⭐⭐
cocoindex	Incremental indexing engine	Code-aware memoisation, with external dependency invalidation still to check	Teams feeding a changing corpus to models	⭐⭐⭐
xberg	Document intelligence engine	Parse failures degrade to plain text with an explicit warning	Anyone feeding messy documents into retrieval	⭐⭐⭐
flint-chart	Visualization intermediate language	Semantic types and themes both compile, and the spec holds no pixels	People who need agents to chart reliably	⭐⭐⭐
natively-cluely-ai-assistant	Desktop real-time voice assistant	Dual-channel capture with two-stage VAD, audio in Rust	People studying real-time audio paths (non-commercial)	⭐⭐

Notes from this issue

A small process comparison produced a negative result. The template author reports four runnable builds from one brief and ranks the standard build last. It is worth inspecting the artifacts and evaluation procedure before drawing a causal conclusion. Document count and game quality are separate outcomes.
The hard part of incremental indexing is recomputing when the code changes. Input-only caching can miss logic changes. Code-aware invalidation addresses part of that problem; external models, services and configuration still need their own dependency identities.
Document parsing is starting to treat failure as a first-class outcome. Degrading to plain text with a recorded reason makes a failure easier to inspect than an unexplained empty result; the latter surfaces downstream as "the model answers badly" and costs a long detour to trace.
Read the licence before the star count. Today's last project uses open-source language in its repository description, while its current README and licence explicitly state source-available terms and require written permission for commercial use. A radar is not only for spotting new things; it is also for marking "looks usable" as "not usable here".

Open Source Radar · 2026-10-29: Skill packages start shipping their own checks

十方空烬 · Ember ☄️ — Thu, 29 Oct 2026 06:55:52 +0000

By Renchao Wu. Originally published on widechaos.cn.

I picked five GitHub projects for this issue, mostly AI agents and developer tools. I read each project's README, release notes and recent commits; I did not install them unless an entry says so. Stars and other numbers are from GitHub as of 2026-10-29.

1. Leonxlnx/taste-skill ⭐ 104,666 · JavaScript

GitHub: https://github.com/Leonxlnx/taste-skill

In one line: A front-end design skill for coding agents: pick a direction, build the page, then measure the result in a real browser and redo it until it passes.

What it is: Since v2 the repo holds one skill, design-taste-frontend, but it is a ten-stage process rather than a prompt: read the brief, write the argument, draw a direction, find the idea, write the words, build, pass the gate, look at the screenshots, add motion, report. A script deals three of twenty researched directions and the agent picks one; from that direction it takes a type system, palette, hero and section compositions from a library distilled from 247 curated sites. Built in February 2026, with 21 contributors, and v2.1.0 through v2.1.5 landed within six days.

What stands out:

The direction is dealt, not invented. The SKILL.md gives the reason plainly: the author argues that unconstrained generation tends toward category defaults; I have not measured that tendency across models. So the draw is mandatory; three options, no improvising a fourth.
The gate measures rather than asserts. inspect.mjs opens the page in a real browser at 1440, 768 and 390 pixels and measures headline line counts, fonts actually loaded, colours, rules, shadows, gradients, contrast, overflow, and the frame: equal margins, sections huddled on one side, unexplained blank stretches, presence of a title. A FAIL must be fixed; a WARN is treated as wrong unless it can be defended to a designer in one sentence.
It says out loud that passing is not the same as good. The gate only shows nothing banned was measured. The next step is opening the screenshots, running a fourteen-pass critique, scoring on an Awwwards-weighted rubric, fixing the top three problems, and repeating; three rounds at most. Only what is visible in a picture counts.
The last gate runs on the production build. The README names a concrete trap: a minifier dropped a backdrop-filter, so the dev server showed something the deployed page did not. The inspector warns when it is looking at a dev server.
The project estimates the resource cost. The README estimates roughly 30 to 45 minutes and a few hundred thousand tokens per build; the scripts need Node 22 or newer plus a local Chrome, install nothing and use no API keys. The workflow requires images from open collections under public-domain, CC0, CC BY or CC BY-SA terms, with page credits. Verify each asset and its applicable conditions.

Compared with: A component library hands over parts; this hands over judgement plus a check; the same rules constrain generation and then get measured as numbers. The split with project 2 below is clear: that one uses a fresh reviewer to read a document and taste is judged by a person, while this one runs commands against a page, and the inspector produces measurements that can be compared. Repeated results still depend on browser, fonts, timing, assets and viewport conditions. The ceiling of the first is the reviewer; the ceiling of the second is how precisely the rules are written.

Recent updates: v2.1.5 (10-24) is a round of community fixes; text inserted into charts and split headings is escaped, the release notes report fixes for keyboard reachability and accessible names, italic weights actually load, and two widths sharing a class no longer lose screenshots. v2.1.4 (10-20) fixed a race where concurrent inspector runs deleted each other's browser profiles. v2.1.3 (10-19) cut the repo down to one skill and moved the others to their own repositories under the same install names.

Who it's for: Anyone building landing pages, portfolios, product pages or admin screens who is tired of getting the same template every time; it is intended to be stack-independent; I have not tested it across frameworks. Three caveats: builds are expensive in minutes and tokens, the gate covers front-end output and not content quality, and the README carries an affiliate link and sponsor slots; those lines are commercial.

My take: ⭐⭐⭐ Worth reading to see how "looks good" gets decomposed into conditions that can FAIL. Do not treat passing the gate as proof of taste.

Checked: read the README, the SKILL.md, the v2.1.3-v2.1.5 release notes and recent commits; did not install.

2. google/elephant-goldfish-model ⭐ 4,914 · Python

GitHub: https://github.com/google/elephant-goldfish-model

In one line: A plugin that makes "write the spec first, then have reviewers with no prior context attack it, then you decide" a fixed procedure inside a coding agent.

What it is: Seven skills in a chain; brainstorm, draft, review, review loop, resolve findings, document an existing codebase, and compare documents against source. It installs through each agent's plugin marketplace (Antigravity, Claude Code, Codex, with setup notes for Claude Cowork and ChatGPT Work). The roles explain the name: the elephant holds the project context and drafts the spec, the goldfish reviews it with no context at all, and the person makes the trade-offs. The repo appeared on 2026-09-13 and only reached its first tag, v0.1.0, on 10-27.

What stands out:

"The goldfish must have a fresh context" is a precondition, not advice. The review skill states that reviewers run in a new context with no conversation history; if the harness cannot spawn subagents, it stops and tells the user; a review in the same context is not a goldfish review. The skill makes fresh context a requirement. I have not tested how each supported harness enforces it.
Five named review phases: initial zoom out, comprehension, design critique, intermediate zoom out, implementation readiness. The order puts broad design questions before detailed criticism; I have not measured its effect on review quality.
Output lands in files, not in the chat pane. The skill forbids pasting large proposals, drafts or reports into the chat; they must be written to the working directory and referenced by path. In long-document work that matters: text in a chat drifts, text in a file can be diffed.
Promotional adjectives are banned. Concept briefs and communication must use plain English, with no ungrounded words such as seamless, robust or blazingly fast, and no decorative adverbs.
It declares its own instability. The v0.1.0 notes say the release-ZIP host validation is still pending and the version is not ready for stable-release claims. The README says thousands of Google engineers use it and, in the same file, that it is not an officially supported Google product; both sentences need reading together.

Compared with: It and the skill above divide the work: one judges a document with a reviewer, the other measures a page with commands. The skill requires a reviewer without prior conversation history. Whether that isolation holds still needs to be checked in the host environment. I have not read the documentation of other spec-driven workflows, so the precise differences are left untested here.

Recent updates: Commits on 10-28 changed the review loop to stop on convergence instead of on zero findings, added a comparison between the draft and the original brief, and added a guard against unsourced invention when bootstrapping documentation. The v0.1.0 notes also list two items: architecture decisions led by the owner (#157) and guidance for agent warnings (#127).

Who it's for: Anyone changing a feature that involves design trade-offs and wants to avoid rework; small bug fixes do not need it, and the README says as much. Apache-2.0.

My take: ⭐⭐⭐ It specifies where the reviewer should come from; the price is needing an environment that can spawn subagents.

Checked: read the README, the review skill's SKILL.md, the v0.1.0 release notes and the 10-27 / 10-28 commits; did not install.

3. milind-soni/OpenMausBot ⭐ 6,768 · TypeScript

GitHub: https://github.com/milind-soni/OpenMausBot

In one line: A team of AI bots delivered as a chat app: each bot is a real agent with its own model, computer and connected apps, and risky actions become approval cards in the conversation.

What it is: A local-first desktop app built from two processes. The Electron shell owns no transports: it sends typed HTTP commands to a harness and folds a single SSE event stream into state. The harness, listening on 127.0.0.1:8799, owns every agent process and normalises each provider's native protocol into one canonical event stream, logged per thread as NDJSON. The project documents local storage for transcripts, keys and events. Model requests, connected apps and configured cloud computers can still send data off the machine. The repo dates from August 2026 and shipped twelve versions in eight days (v0.1.120 to v0.1.131), each with concrete behavioural changes.

What stands out:

The permission broker is the main interface. Shell commands, file edits and questions surface as inline cards with Allow, Deny, or an answer typed into the chat, for cloud computers and local machines alike. "Do not act rashly" becomes a path the user clicks through, not a line in a system prompt.
The MCP surface is deliberately narrow. The bundled MCP server exposes inspecting bots and channels, reading and searching transcript pages, creating and configuring tasks, sending work, waiting for completion, switching models and interrupting turns. It explicitly does not expose approval grants, deletion, arbitrary settings, credentials or computer lifecycle. That list of what is withheld is more instructive than the feature list.
The project documents platform-specific control restrictions. Bot control of the local machine is disabled on Ubuntu Wayland pending a safety gate, requires explicit opt-in on Xorg and runs without a full-screen cursor overlay, and the Windows installer is not code-signed, so the system shows an unknown publisher.
Key storage is labelled honestly. API keys are stored as plaintext in a private config file (mode 0600 on Unix) and the README states they are not encrypted.
Triggers have concurrency discipline. Interval schedules align to their start time and skip an occurrence when the previous run is still active, so the documented scheduling policy avoids accumulating interval occurrences. I have not tested crash recovery or all trigger sources. The webhook receiver binds a local port only and exposes health plus secret hook endpoints; bearer authentication is recommended so the secret stays out of URLs.

Compared with: The project presents itself as an open alternative to several closed personal-agent products; I have not verified those products, so no comparison conclusion here. The verifiable differences are architectural: bots reuse the logins of local CLIs, the UI and the runtime are separate processes, and an unknown engine degrades to unavailable instead of taking the fleet down. It also owns the agent processes itself, whereas the other two agent projects today either ship skills into someone else's agent or collect context into a workspace.

Recent updates: v0.1.131 (10-28) gives connected apps the same tool names on every engine so switching models no longer quietly breaks routines; a sign-in request can be settled by replying done in chat; a global ⌃⌥Space voice ask arrives on the Mac. v0.1.130 reworked simple mode and made a new bot send a test message so a bad key surfaces immediately. v0.1.129 installs updates at a quiet moment and lets bots borrow a real Chrome on a Mac with the user's own logins.

Who it's for: Anyone who wants several agents locally, on accounts they already pay for, with documented approval paths for supported actions. I have not audited complete action coverage. macOS is the most complete target, Ubuntu is still beta, and Wayland cannot control the local machine; cloud computers and connected apps are third-party paid services. The project labels its community code Apache-2.0 and the enterprise/ directory under a separate source-available licence. Check the exact components and dependency terms for the intended distribution.

My take: ⭐⭐ The architecture is worth copying, the product is early; anyone expecting a finished app will hit the beta edges first.

Checked: read the README, the v0.1.129 to v0.1.131 release notes, the 10-29 commits and the server/drivers directory; did not install.

4. macro-inc/macro ⭐ 5,496 · Rust

GitHub: https://github.com/macro-inc/macro

In one line: Email, chat, documents, tasks, agents and CRM in one workspace, everything linked in a bidirectional graph, with a team memory synthesised once a night.

What it is: A workspace rewritten in Rust with a SolidJS client. The surface is wide; multi-account inbox, channels and DMs, lightweight tasks, CRDT documents, a canvas, recorded calls, files, GitHub pull requests, CRM; but it shares one backend, so references between a document and a task, or a channel message and an email, are edges in the database rather than synchronised copies. The README reports 42 deployable services and 167 Rust libraries; counting directories through the GitHub API gives 47 under services/ and 267 under crates/ (I did not confirm which of those are deployable). Created November 2025, 26 contributors.

What stands out:

It argues the case for building it. The author writes that at about twenty people in a previous company, each team bought its own tools and the company was held together by MCP and Zapier; "the company was not computable". So tasks and CRM moved back to where the conversation happens: a task grows out of an email, a channel or a checked bullet in a document, and links back to its source.
Team memory is batched, not appended. Every night the system synthesises channel conversations, DMs, sent and received email, and tasks created or completed into one pass, merges it with the previous version, and stores the result as Markdown that can be exported or edited by asking.
That memory is exposed outward. It is available to external agents over MCP; the project says the MCP surface covers nearly everything the UI can do and imposes no rate limits.
Agents are peers in the collaboration system. Documents are CRDT-backed, and agents edit them like human collaborators, with concurrent document edits merged by the CRDT. This does not establish that the resulting content is semantically correct. The example given is a daily job that updates a document after scanning channels, and skips the update if someone edited it first.
Permissions follow the channel. The README describes channel membership as the access rule for linked content. I have not audited nested sharing, exports or revocation propagation.

Compared with: Against buying a chat tool, a document tool, a task tool and a CRM and wiring them together, the difference is architectural rather than a feature list: one backend, one bidirectional graph, one permission model, and a memory synthesised from the whole company's context. Its criticism of those other products is the project's own account, and I have no verifiable data on them. Among today's agent projects it is the workspace kind: it neither owns agent processes nor ships skills, but collects context into a store for agents to read.

Recent updates: Three tags on 10-29 alone; routines can be saved as templates others activate, a highlighted snippet can become a task, agent tool calls stream with throttled argument previews, and production alerts gained a login and a graph each. Version numbers are date streams (v2026.10.28.N), not semantic versions.

Who it's for: A small team that wants to self-host its workspace and cares where its memory comes from. Two caveats: AGPL-3.0 applies to the whole thing (the project says it is not open core), so hosting and distribution obligations need reading; and directory counts do not establish the required number of deployed services; check the actual self-hosting topology. The security page reports SOC 2 Type II and zero data retention with model providers; I did not check the audit report.

My take: ⭐⭐ The memory design deserves a separate read; the self-hosting cost will put most people off.

Checked: read the README, the three release notes from 10-29 and the commits, counted the crates/ and services/ directories; did not install.

5. ruvnet/RuView ⭐ 101,183 · Rust

GitHub: https://github.com/ruvnet/RuView

In one line: A WiFi-sensing research stack with ESP32 firmware and models whose maturity differs by task. The headline capabilities are not established by one board's live output.

What it is: A WiFi sensing stack: an ESP32-S3 (about $9) or ESP32-C6 ($6-10) runs firmware as a sensing node, frames go through a bridge to a sensing service, and the output connects to Home Assistant (21 entities per node, ten of them inferred semantic states such as someone sleeping, an elderly person with no activity, elevated fall risk) and to bridges for Apple Home, Google Home and Alexa. There is also a Python package (PyO3, about 250 KB), pretrained weights, and a sensing panel for coding agents. Created June 2025, 40 contributors.

What stands out:

It turns "which numbers are real" into a section. Model weights are graded in three tiers: labelled real and validated by the project (the pretrained encoder at 82.3% held-out temporal-triplet accuracy, and an MM-Fi pose model at 82.69% torso-PCK@20, or 83.59% as a three-model ensemble), real but weak and labelled as such (the in-repo model at 3.0% PCK@20 and 18.5% PCK@50, below its own 35% target, with a runtime path that is still a stub returning zero confidence), and architecture only with no weights at all (the old head is randomly initialised, with no checkpoint in the repo).
It retracted one of its own figures. The earlier "100% presence" number was measured on a single-class recording and the README says it has been retracted. That sentence says more about the project's discipline than any new number.
It states the physical limit. A single antenna, 56 subcarriers and a 20-frame window do not carry the fine spatial information that multi-antenna research relies on; distal and facial joints come out near random. The pose accuracy the project stands behind comes from the MM-Fi benchmark, not from a live single board.
There is a one-command replay. The project provides a replay script that compares pipeline output with a published hash. A matching replay does not validate live sensing accuracy or clinical use.
The release shape is not product-like. Tags are CI snapshots (v3422), firmware ships separately as a prerelease (v0.8.16-esp32), and the release notes state plainly that the entry contains no firmware bundles.
Known problems are written down: the published weight file has a NUL-padded header that the reference loader rejects (issue open, re-upload pending), while another embedding file in the same repo loads normally.

Compared with: This project publishes maturity tiers, a retraction and physical limits. I have not surveyed other WiFi-sensing projects broadly enough to characterise their reporting. Its comparison with prior published results (MultiFormer at 72.25%, CSI2Pose at 68.41% on the same split) is the project's own account; I did not read those papers to check the protocol, so I do not treat it as independent verification.

Recent updates: The 10-26 firmware prerelease stops unrelated millimetre-wave frame types from establishing the wrong sensor identity, fixes container images built from Windows checkouts, and updates vulnerable Rust dependencies. The same day's source snapshot is a CI-validated artifact. A proposal to relax the startup requirement was withdrawn, leaving the existing zero-vitals startup requirement in place.

Who it's for: People with hardware who want to reproduce WiFi sensing, or anyone who wants a sample of how to report metrics honestly. The pipeline can be run with simulated data. MIT licence. Do not buy a board expecting to see through walls; the project itself says that number does not come from a single board.

My take: ⭐⭐ The gap between the metrics and the headline is real, and so is the value of how the metrics are labelled.

Checked: read the README including the model maturity and results sections, the v3422 and v0.8.16-esp32 release notes, and the 10-26 commits; no hardware, did not run it.

At a glance

Project	What it is	Most distinctive	Who it's for	Go deeper
taste-skill	Front-end design skill	Measured in a real browser at three widths, checks measured layout rules	People who need pages that do not look templated	⭐⭐⭐
elephant-goldfish-model	Spec and review process	Requires reviewers without prior conversation history; no subagents means stop	People changing features with real trade-offs	⭐⭐⭐
OpenMausBot	Desktop agent runtime	Approval cards plus a deliberately narrow MCP surface	People running several agents locally	⭐⭐
macro	Team workspace	One team memory synthesised nightly into Markdown	Small teams willing to self-host	⭐⭐
RuView	WiFi sensing	Three-tier model table plus a public retraction	RF hardware tinkerers and reproducers	⭐⭐

This week's notes

Skill packages have become the unit of distribution, at three granularities. One repo cut to one skill, seven skills packed into a plugin, one Markdown file that installs a whole team. The shared direction: make "how to do it" into something installable, reviewable and removable.
Verification is moving from prose into measurement. A browser measures the page, a review skill requires a fresh context, the sensing project labels model maturity without equating benchmark results with a live board. Three projects, three layers, one move: turn "I checked" into something someone else can re-run.
Version numbers no longer signal maturity. Twelve releases in eight days, six in six days, CI snapshots used as tags. The release notes and a willingness to write "this version is not ready for stable claims" tell you more.
Read the licence down to the directory. This batch spans MIT, Apache-2.0 (with one project carving out an enterprise directory under its own licence) and AGPL-3.0. The word "open source" alone does not say what you may do with it.

Open Source Radar · 2026-10-28: Approval moves from the prompt into the pipeline

十方空烬 · Ember ☄️ — Wed, 28 Oct 2026 14:22:42 +0000

By Renchao Wu. Originally published on widechaos.cn.

Each day I pick five projects from GitHub's candidate pool, which mixes the Trending page with topic searches, mostly AI agents and developer tools. I read each project's README, release notes and recent commits; I did not install them unless an entry says so. Stars and other numbers are from GitHub as of 2026-10-28.

1. devswha/ovis ⭐ 1,561 · TypeScript

GitHub: https://github.com/devswha/ovis

In one line: turns the coding agents running on your own machine into conversations you can approve from a browser or a phone.

What it is: Ovis is a front end for herdr. herdr describes itself as the runtime that coding agents live on: it keeps the terminals of Claude Code, Codex, OpenCode and similar tools in a background server so they survive a closed client or a dropped SSH connection, and it marks each pane as working, blocked or idle. Ovis opens a window onto that: browser, Mac app and phone all see the same sessions. The project was created on 2026-09-17 and has 1,561 stars now; it is TypeScript on Bun, with React and xterm.js in the front end.

What stands out:

Prompts are cards, re-checked against the live menu before they are sent. The README says prompt cards are "checked as still current before your answer is sent", and the guide is more specific: supported cards are verified against the current menu before anything is typed. Menus in a terminal interface change; answering from a cached copy means making a decision the agent never asked for.
It reads session files instead of adding a layer. Ovis renders the agent's own transcript files, folding work per turn for Claude Code, Codex, OpenCode, pi, omp, gjc and identifiable Devin CLI panes; agents without a native reader fall back to a terminal-text view. There is no account system and no hosted relay of its own. No relay of its own does not mean nothing leaves the machine; the next point covers that.
The terminal is the same pane. What opens on the phone is the pane herdr is running, with a key bar, not a read-only mirror.
Data does leave the machine. Session files stay on the computer running each agent, but their contents are sent to the browsers connected to the app. Voice input sends recordings to the configured transcription service, and without a configured key the browser's speech recognition may use the vendor's own service. Push alerts are relayed by the browser vendor's push service. With Portal on, every connection goes through the relay you chose, and that relay sees connection addresses, timing and volume. The privacy notes spell these out; having no relay of its own is not the same as sending nothing.
Push alerts cover two events. An agent asks something, or an agent finishes, and the alert arrives with the app closed, through the browser vendor's push service as an encrypted notification. Anonymous usage counts are on by default; settings show what is sent and turn it off, as does OVIS_TELEMETRY=0.
The cost is stated up front. herdr 0.9.0 or newer, your own computer switched on, and a phone that can reach it by one of several routes: Tailscale, a LAN address, an SSH tunnel, a reverse proxy or a Portal tunnel.

Compared with: the project's own FAQ names the alternatives. collie is a mobile terminal for herdr, tmux and zellij, with a status dashboard, key pad, quick replies and voice input, served by its own bridge; roamgate is a browser client for herdr with a file explorer and diff annotations; herdr-remote is a macOS menu-bar app with a Telegram bot behind a relay and a free tunnel. Against Happy, Paseo and CloudCLI UI the split is architectural: those start and manage agents through their own wrapper, daemon or server and ship their own apps, while Ovis only acts as a window. These are the project's claims; I did not install the others to check them.

Recent updates: v0.4.19 (2026-10-27) lets you update an older Ovis on a given PC from its own card, brings Antigravity chat to Windows, shows pictures from omp sessions and Codex tools, renders OpenCode subagents as background tasks, and can revoke every paired device at once. The same day shipped remote-v38, which gives the SSH remote bridge runtimes a SHA-256 manifest. A checksum manifest alone does not establish publisher authenticity.

Who it's for: people already using herdr across several machines who are often away from the keyboard. Without herdr, look elsewhere.

My take: ⭐⭐⭐. It invents no new capability; it moves the moment when an agent is stuck waiting for one sentence onto a phone, and its documented live-menu check addresses stale options. I have not tested races between verification and submission.

Checked: read the README, docs/guide.md, the v0.4.18 and v0.4.19 release notes and the last five commits; did not install.

2. SoMarkAI/OXR ⭐ 1,904 · Python

GitHub: https://github.com/SoMarkAI/OXR

In one line: a 1.3B-parameter document parsing model that turns PDFs and document images into Markdown or JSON with layout coordinates.

What it is: OXR comes from the SoMark team and was created on 2026-10-05. It splits the job in two: a layout analysis model cuts regions, and the OXR model handles recognition with reading order folded into that stage. The README says this is the main difference from comparable tools, which either give layout to the recognition model or use a dedicated model that also handles reading order. Output is Markdown or JSON, with bounding boxes per element.

What stands out:

Layout analysis is replaceable. The built-in layout model can be swapped for a custom one while OXR keeps handling recognition and reading order. The reasoning is that layout requirements vary most across document domains and need the most customization, so the layout component can be replaced. Recognition interfaces may remain the same, but end-to-end quality still needs re-evaluation.
Thirteen element types. Beyond body text, titles, tables, figures, formulas and headers/footers, it covers stamps, code blocks, chemical equations (LaTeX with \ce and mhchem syntax) and chemical structures (SMILES or images).
Post-training runs a self-improvement loop. It targets samples the model gets wrong or handles weakly instead of relying on human annotation; the README calls this a first for document parsing, a novelty claim I have not independently established.
The free API and local deployment are different paths. The free API needs no key and no signup, but requests are queued, stability is not guaranteed and the project says not to use it in production. Running locally takes Linux, an NVIDIA card with BF16 support, a CUDA 13.0 driver, 24GB of GPU memory to start and 48GB or more recommended for long documents or higher concurrency.
The web demo cache expires. Temporary files last one hour by default and are renewed while processing; after that the results are gone.

Compared with: the project's benchmark document gives full component tables for three benchmarks, with an accuracy snapshot dated 2026-10-05, and notes that peer scores come from published papers, model cards and a pinned commit of the relevant leaderboard README. Overall scores are 87.84 on olmOCR-bench (second place Infinity-Parser2-Pro at 87.60), 97.18 on OmniDocBench (second place TeleOCR at 96.91) and 87.76 on DocParsingBench (second place PaddleOCR-VL-1.6 at 85.17). The three reported overall margins are 0.24, 0.27 and 2.59 points, but the components do not all lead. On OmniDocBench, Formula CDM is only 0.85 points ahead of the runner-up TeleOCR (97.44 against 96.59), and Table TEDS is actually 0.20 points behind (96.62 against 96.82). On DocParsingBench, Formula leads by 10.17 points (85.76 against 75.59). Which component is strongest cannot be read off the total, so fit depends on which element types dominate your documents. All of these numbers are the project's own; I ran no evaluation and did not reproduce them on another machine.

Recent updates: no formal release; main still sits on the 10-05 launch. Commits from 10-19 to 10-24 are README, badges and community links (a WeChat QR code, LinkedIn), with no code movement.

Who it's for: people whose documents are table-heavy and who must process them locally; the README's examples include financial reports, exam papers, newspapers and handwriting. The documented local setup starts at 24GB; I have not tested lower-memory alternatives. Check permission and data-handling terms before submitting confidential scans to a hosted API.

My take: ⭐⭐⭐. The part worth learning is the module split: layout on its own, replaceable, with recognition and reading order bound together. That the top score leads by 0.24 points says more than the top score itself.

The model uses Apache 2.0 with additional terms, according to its licensing documents. Those terms address consolidated commercial thresholds for the user and affiliates, attribution for online services, and a separate written licence for a competing hosted API. Read the exact code and model grants for the intended use.

Checked: read the README, the full docs/benchmark.md, the additional license terms and the last five commits; did not install or run any evaluation.

3. elayadesign/ai-design-skills ⭐ 9,722 · Markdown

GitHub: https://github.com/elayadesign/ai-design-skills

In one line: a design skill collection for coding agents, currently one skill, where 18KB of Markdown spends half its length on what a page should say and half on visual values that are not up for debate.

What it is: the repo is organised one folder per skill, and you install only what you need: copy into .claude/skills/ for Claude Code, download into .cursor/rules/ for Cursor, paste into AGENTS.md for Codex, .windsurfrules for Windsurf, .clinerules for Cline, or straight into a system prompt. The whole repo is 38KB of text with no code. landing-page-design has two parts: Part A covers strategy and structure, Part B is the visual system. The opening fixes precedence: when this file conflicts with a framework default, the file wins; when the user's explicit request conflicts with it, the user wins.

What stands out:

Ask before drawing. Four groups of questions come first: the one primary action, who does not convert and why, which logos and numbers exist, and the brand voice. If the answers are missing, make a reasonable assumption, state it in one line and continue rather than stalling.
A fixed twelve-section skeleton. Five above the fold (headline, subheadline, primary CTA, one proof signal, hero visual), four in the middle (problem to solution, three to five benefits, a three-step process, social proof), three at the bottom (six to twelve FAQs, risk reversal, a final CTA identical to the top).
Visual values leave no room. Only Geist, Manrope, Geist Mono and Poppins are allowed; Inter, Roboto, Arial, Open Sans and Helvetica are banned, as are italics and 900 weights; every font size must land on a Tailwind scale step, and a size that does not is snapped to the closest step below; spacing may only use values from the table; copy may not contain hyphens or leave an orphaned word.
Every page needs a tagline reveal. A separate large-type section, at least two lines, where words go from 25 to 35 percent opacity to full text colour as the section scrolls into view, triggered per word with IntersectionObserver and never an unthrottled scroll listener.
Content realism has hard targets. No Lorem Ipsum and no "Your headline here"; names are specific and fit the region, prices carry decimals or odd final digits, dates in a list vary; these conventions do not justify inventing customers, endorsements, prices or results; words such as revolutionize, supercharge, cutting edge and effortless are banned.

Compared with: it divides work with the same author's redesign-skill rather than competing with it: that one diagnoses why an existing site looks template-generated, this one builds from scratch, and each points at the other. The content realism and motion ideas are adapted from Leon Lin's taste-skill (MIT); the SKILL.md appends that license in full and notes that overlapping sections were rewritten. What is unusual is how prescriptive it is: it turns design choices into values and prohibitions, and decides who wins a conflict.

Recent updates: no release. On 10-25 a design-to-motion skill was added; on 10-26 it gained guidance for screenshot sources and a small entrance animation for site heroes, and on the same day the sections overlapping taste-skill were rewritten with credit; on 10-27 that skill moved to its own repository. So the collection grew one skill and lost it within two days, and still holds one.

Who it's for: people who want explicit landing-page layout defaults rather than selecting every value during generation. One-pass correctness is not established. It is tied to the Tailwind scale, so outside Tailwind the snap-to-step rule needs a replacement scale; the style is locked down as well, which makes pages look like each other.

My take: ⭐⭐. The content is not new; what interests me is the specificity of its instructions and file structure; a Markdown rule is not runtime enforcement: strategy first, values after, a design-values block at the end that changes the whole file when edited.

Checked: read the README, the full SKILL.md, the LICENSE and the last five commits; did not generate a page from it.

4. kortix-ai/suna ⭐ 20,323 · TypeScript

GitHub: https://github.com/kortix-ai/suna

In one line: a self-hosted agent platform that treats a company as a git repository, with each session on its own sandbox and branch and every artefact landing through a change request.

What it is: the repository is still named suna; the product is now Kortix, created 2024-10-05. A project is a git repo plus a kortix.yaml holding agents (role instructions in Markdown), skills, memory, connectors and triggers. Each session gets a disposable Linux sandbox in the cloud on its own branch, where the agent can install and run software within the configured permissions, with committed repository changes preserved. External calls and side effects are not undone by discarding a branch; reaching main requires a change request that a person reviews.

What stands out:

Merge is default-deny for agents. That is the README's wording. An agent may edit its own configuration and propose the change on the session branch, but the documented default requires human review before it reaches the trunk. I have not audited bypass paths or deployed this policy.
Permissions go down to arguments. Each tool can be set to Allow, Ask or Block; Ask holds that call until a person approves it and then the agent continues. The README also says approval gates are off until you set them. Keep the two separate: the merge gate is closed by default, while the per-tool Ask gate is not on by default.
Connector credentials and secrets are handled differently. Connector credentials are brokered server-side through one scoped token covering 3,000+ apps plus MCP, OpenAPI, GraphQL and raw HTTP, and those credentials do not enter the sandbox. Secrets are the other case: encrypted at rest with a per-project key, granted per agent, and injected into that session's sandbox at runtime as real environment values, so a granted agent can read them in its own session. "Secrets never enter the machine" is not what the README says.
The entry points are where people already are. Mentioning the bot in Slack or Microsoft Teams starts a session in that thread, and follow-ups stay in the same session; the email channel is marked experimental.
Self-hosted is not the same as disconnected. kortix self-host start pulls images from Docker Hub, and the README says so directly.
The license is Elastic 2.0. Read it, fork it, self-host it. What it restricts is providing the software itself to third parties as a hosted or managed service that gives them access to a substantial set of its features. Running your own business on it and selling what you produce are a different matter.

Compared with: the README names n8n, OpenHands, Paperclip and Onyx-style chat tools. Its split: n8n fits fixed flows; OpenHands is a coding-agent control centre for engineering teams; Paperclip adds an org chart, budgets and a task board on top of existing Claude Code or Codex runs; Onyx-style tools are a chat window over documents. Kortix wants the platform to run the agents, one cloud computer per session, all configuration in one repo. The table is marked as reflecting publicly documented behaviour as of July 2026, and I did not check each competitor's docs; what can be verified independently is the mechanism: per-session sandbox, branch per session, merge through a change request, configuration in git, all of which match the CLI commands (kortix sessions new, kortix cr ls, kortix ship).

Recent updates: v0.14.8 (2026-10-23) makes every new session run pi and marks OpenCode deprecated while existing sessions keep it, and adds sharing of a single assistant response. v0.14.7 (10-22) adds project transfer between organisations or accounts, a per-project default reasoning effort, and running a session on your own machine through kortixd with a ChatGPT subscription.

Who it's for: teams that want agents with audit trails and approvals; any proposed hosted-service use needs review of the actual licence and any separate grant. The stack is not light: cloud sandboxes, SSO and a connector broker all have to land.

My take: ⭐⭐. The institution is the thing to copy: configuration in git, changes through a change request, merge denied by default. The stack itself is too heavy for a single user.

Checked: read the README, the LICENSE, the v0.14.7 and v0.14.8 release notes and the last five commits; did not deploy it.

5. dramaclaw/dramaclaw ⭐ 6,502 · Python

GitHub: https://github.com/dramaclaw/dramaclaw

In one line: a self-hostable production line for AI short drama, with an infinite canvas for experimentation and a pipeline that covers episode planning, scripts, storyboards, voice-over and the final cut.

What it is: created 2026-03-27. Two surfaces share one asset library and one built-in agent. XiaHua is a node-based infinite canvas with 18 node types where you generate, edit and connect images, video, audio, 3D sets and scripts, then promote what works back into a series; XiaJi is the pipeline that takes a manuscript or screenplay through episode planning, scripts, storyboards and first frames, voice-over and export; Xia Director spans both, turning a creative brief into a node graph that runs after confirmation, with progress tracking and failure recovery.

What stands out:

The documented gateway-based pipeline needs no local inference GPU. The documented standard inference path goes through an OpenAI-compatible gateway (the official RelayClaw service or a bundled dramaclaw-gateway routing to providers you configure); 2 vCPU and 4GB is the recommended floor, started with Docker Compose; ports 8080 for the web UI, 8780 for REST, 3000 for the gateway admin UI; no Postgres, Redis, Celery or Ray, with state in local SQLite and files. Only the optional 3D world feature needs a GPU.
Skills and recipes are portable units. Eleven workflow skills and 60 recipes cover short drama, e-commerce ads, IP character ads and social content, and can be installed, exported and shared.
There is an MCP surface for outside agents. Agent Kit exposes the same production workflows to MCP clients such as Codex and Claude Code: the product does not build another agent, it lets existing agents drive the pipeline.
Scene consistency runs through 3D. An image can become a 3D Gaussian splat set or a 360 panorama node that locks spatial structure, to guide spatial consistency across shots. I have not measured consistency or generation failures.
Every step is decomposable. Each stage is an independent async task that can run in order, be skipped or resumed from a checkpoint, and the orchestrator can be replaced; a task centre tracks status, progress, logs, cancellation and retries.
The pipeline documents preflight checks before generation. v2.0.5 added reference-media validation (duration limits and the like) before generation, and later commits add a media storage preflight before paid generation. These checks do not cap all provider charges or make retries free.

Compared with: the README includes a capability table where competitor names are partly masked (L*TV, R*Hub, T*Now, S*ko, U*dream and others) and the note says the comparison is based on publicly available product docs and positioning. Masked names cannot be matched to specific documents and the ticks have no published criteria, so I do not accept a claim such as "the dual track is unique to it". What can be checked sits at the mechanism level: canvas nodes keep their own generation history, the asset library and the series project onto each other, skills are exportable, and Agent Kit speaks MCP.

Recent updates: v2.0.6 (2026-09-28) adds video extension that keeps the original aspect ratio, model-backed resolution and frame-rate enhancement including interpolation, and MP3 output for separated audio. v2.0.5 (09-17) lets archived generated media be delivered and accessed instead of relying on expiring links, and adds two LingShan image models to the community edition. Releases stop at 09-28 while main keeps moving, with the storage preflight and Portuguese localization on 10-26.

Who it's for: small teams with a script who want to assemble a short-drama or e-commerce video line themselves. Watch the license: the project describes Elastic 2.0 as source-available and permitting standalone and commercial use subject to its terms, and keeping the Powered by DramaClaw notice in the UI is what the project asks for. What it restricts is providing the software itself to others as a hosted or managed service using its features; the README says the hosted-SaaS grant is not open yet. Trademarks and brand assets are not licensed with the code.

My take: ⭐⭐. The engineering is substantial, but the comparison table cannot be verified and the license has its own terms; read both before deciding.

Checked: read the README, the NOTICE, the LICENSES directory and the head of license-inventory.csv, the v2.0.4 to v2.0.6 release notes and the last five commits; did not deploy it.

At a glance

Project	What it is	Most distinctive point	Who it's for	Worth a deep look
ovis	Browser and phone client for agent sessions	Prompt cards re-checked against the live menu before sending	People running herdr across machines	⭐⭐⭐
OXR	Document parsing model	Layout analysis is separate and replaceable, reading order folded into recognition	Table-heavy documents processed locally	⭐⭐⭐
ai-design-skills	Landing page design skill	Strategy and visual values split, with precedence fixed	Getting an agent to build a page in one pass	⭐⭐
suna	Self-hosted agent platform	Merge denied by default for agents	Teams needing audit and approval	⭐⭐
dramaclaw	AI short-drama production line	Canvas and pipeline share one asset library	Small teams with a script	⭐⭐

This week's notes

Several projects moved a decision into code. Ovis re-checks whether a prompt card's options are still valid before sending it, Kortix denies agent merges by default and can hold a tool call for a person, DramaClaw preflights storage and reference media before paid generation. Each governs something different; what they share is turning a reminder into a check that can fail, not a single approval layer.
Licensing is no longer two tiers. Three of these five are not under a standard open source license: two use Elastic 2.0 (source-available; the restriction is on providing the software itself to third parties as a hosted or managed service, not on all commercial use) and one is Apache 2.0 with added terms (the commercial threshold is measured on a consolidated basis for you and your affiliates, online services need attribution, and a competing hosted API needs a separate written license in advance). The boundary of the word "open source" is something you confirm in the LICENSE.
What a top leaderboard spot is worth depends on the component. OXR reports overall margins of 0.24, 0.27 and 2.59 points in its benchmark snapshot, while its components do not all lead: on OmniDocBench its Table TEDS is 0.20 points behind the runner-up. When the totals are close, the component table says more about fit than the total does.
Skills are becoming portable assets. On one side, 18KB of Markdown holds a strategy, a set of numeric prohibitions and a design-values block; on the other, skills and recipes are packaged as units that can be exported, shared and installed, with an MCP surface for outside agents. Both answer the same question: how does a body of practice keep running after it leaves the author's head.