DEV Community: Selçuk GÜRAL

What is Lonca? Version control for AI coding agents (Lonca series, part 0)

Selçuk GÜRAL — Sat, 14 Nov 2026 17:26:23 +0000

For a while now I have been working on Lonca, a version control system for AI agents. This post starts a series about it. Later posts will take its parts one at a time; this first one only gives the overall picture: what Lonca is, which problem it tries to solve, and how much of that it does today, in version 0.2.3.

I will try not to oversell it. I will write down what works, and also what does not exist yet.

Lonca in short: version control for AI agents

Lonca is a version control system for repositories where several AI agents and a few humans work at the same time. It is written in Rust and it is open source (Apache-2.0).

It does not try to replace Git. The content stays plain Git: you can push to GitHub, and your Git tools keep working. What changes is everything around it: who may do what, how work done at the same time is merged, and how every operation is recorded and checked.

The name comes from the craft guilds of the Ottoman bazaar, the lonca: written rules, masters, journeymen and apprentices, and an inspection before goods reach the market. That is Lonca's model too.

The problem it solves

Most days I run several coding agents on the same repository. The agents do their work well; the problem is the tooling around them. Git and platforms like GitHub assume that every writer is a person. With agents, that assumption breaks in three places:

Permissions. An agent works with my token, shows up in the history under my name, and has every right I have. Even when its task is to fix one function, it can force-push, delete a branch or change the CI files. Nothing stands in between.
Concurrency. Two agents working on the same file only find out about each other at merge time. Each is green on its own; together they are red.
Accountability. When something goes wrong, I can't answer the two questions that matter: what was this agent allowed to do, and did it do only that?

Lonca exists to answer these three.

How it works

The core idea is simple: agents never write to the repository directly, they propose. A single process on the machine, the Lonca daemon, is the repository's only writer. It decides every request, signs the decision, appends it to an operation log kept inside the repository (refs/lonca/oplog), and only then applies it.

Agents propose; the daemon, the only writer, decides, signs and records.

Four parts around the daemon

Four parts are built around that:

Capabilities, not accounts. Every agent works in a session, and the session gets narrow rights that expire: which paths it may touch, which operations it may run, size limits. Rights can only narrow when they are handed to sub-agents. Revoking a session revokes everything derived from it. Unknown operations, scopes and paths are refused.
Symbol leases and a structural merge queue. Agents lease the functions and types they edit, so several agents can work in parallel on different functions of the same file. When an agent proposes a change, it declares what it changed; Lonca computes what really changed with tree-sitter and refuses the proposal if the two don't match. The merge queue merges changes symbol by symbol and runs the build and tests in a sandbox with no network access; trunk moves only after that.
Taint. The tool the agent runs in (the harness; today that is Claude Code) reports every tool call to the daemon, and a proxy sees outbound connections. A session that reads outside content (a web page, an issue, another MCP server) counts as tainted: its changes need a human's approval, and it may not touch build scripts, CI or lock files at all. This is the structural answer to prompt injection.
A log anyone can replay. Every operation, whether allowed, denied or sent to a human, is in the log, and the log travels with the repository on git push. The log is append-only; an undo (lonca undo) is a new, compensating operation. The independent auditor, lonca-audit, replays every decision from the start, recomputes every merge, and catches a forged entry even when it is signed with the daemon's own key.

Human signatures, and no AI where integrity depends on it

Humans sign their own operations with their own keys. The key can live in the Mac's Secure Enclave or on a FIDO security key; then every approval needs Touch ID or a touch. An agent running as your user can't approve on your behalf.

There is no AI where integrity depends on it. The decision function decide(), the daemon and the auditor contain no AI, no network and no randomness. decide() is a pure function, and all of its inputs, time included, are in the log entry. Build and test results are recorded as evidence and never recomputed later. AI appears only as an optional advisor that helps a human during review, and it decides nothing.

Where it stands today

The current version is 0.2.3. Every phase of the design is implemented and tested. A log written by any 0.x release stays readable and auditable by every later release.

What it does today

Full support for Claude Code. I build Lonca against Claude Code and try it live before every release. The hooks and Lonca's MCP tools are ready as soon as a session starts.
Symbol-level work in 13 languages. Rust, Python, TypeScript/TSX, JavaScript, C#, Go, Java, Kotlin, C, C++, Ruby, PHP and Swift. Markdown, TOML, JSON and YAML files are split into sections; other files are leased whole.
macOS and Linux. Installed with Homebrew, install.sh or cargo install.
Tests. More than 1,800 tests, real sandbox and socket tests included. 45 acceptance criteria, run with the real binaries and real daemon processes, must pass before every release. Eight fuzz targets must also be green before every release.

Three levels of trust

How far you can trust what you see depends on how you run the agents. There are three levels:

Mode	How agents run	Going around the store	Setup
Cooperative	As your user	Not prevented, but detected (hash chain, auditor). Every change needs a human's approval.	None
Hardened	As your user; Claude Code's hooks and sandbox are locked	Prevented: the daemon is a separate system user	An install script run as root
Isolated	Inside a container or an OS sandbox	Prevented	Your own container runtime

What doesn't exist yet, or is limited

One machine. 0.x is for one developer with many agents. A team server is designed, not built.
One real user. The only real project running on Lonca today is imece, and that is my project too.
Other harnesses. Codex, Gemini CLI and OpenCode have profiles and run isolated under lonca run, but their hooks are not wired up yet. IDE agents are planned; any client that speaks MCP can use lonca mcp today.
The verifier's limits. Resource limits hold for each process; a build or test command's total disk, memory and (on macOS) process count are not bounded yet. So only verify commands you would run yourself. On Linux the sandbox needs bubblewrap.
Signature changes. When a function's signature changes, Lonca notices and asks for it to be declared, but it does not analyze the callers. Broken calls are caught by the tests in the merge queue.
Redaction is logical. When a leaked secret is redacted, the daemon no longer hands out its content, but the object is not yet purged from Git history.
Paths not yet exercised. Signing with a physical FIDO key has not been tried by the project yet. The AI advisor has only been tested against a fake API.

The full, current list is on Lonca's site, under Limitations.

Who it is for, and how to try it

Right now Lonca is version control for AI agents on one developer's machine. It is mostly for developers who run several coding agents on the same repository on their own machine and want to keep what those agents do under control. If you work with a single agent now and then, you probably don't need it; Git and a good code review are enough.

Install:

brew tap selcukgural/lonca && brew install lonca
# or: curl -fsSL https://selcukgural.github.io/lonca/install.sh | sh
# or: cargo install --locked lonca lonca-audit

First run:

lonca daemon &                       # the gatekeeper
lonca human keygen ayse              # or --secure-enclave, --security-key
lonca init demo --import ~/src/myproject
lonca session start --repo demo --agent claude --paths 'src/**' \
        --task T-142 --ttl 2h --workspace ~/ws/claude-1 --harness claude-code
lonca doctor                         # what a first run trips over
cd ~/ws/claude-1 && claude

From here the agent leases the symbols it edits and makes proposals. You see what is waiting with lonca pending, approve with lonca approve, undo with lonca undo when needed, and audit the log with lonca-audit verify. The step-by-step walk-through is in the quick start guide.

What comes next in the series

In the next posts I plan to explain each part on its own, together with why it was built that way:

One writer and a pure decide(): why there is no AI, network or randomness in the decision
Symbol leases and the structural merge: agents working in parallel on one file
Taint: content read from outside, and prompt injection
The operation log and lonca-audit: how you prove a decision afterwards
Human signatures: the Secure Enclave and FIDO keys
Lonca with Claude Code: a real working day

The order and the topics may change along the way. Every post of the series will be collected under the Lonca category.

One last note: I built Lonca with heavy help from Claude Code. The design and every decision are mine, and each one is written down with its reasons in docs/decisions.md.

The code is on GitHub, the documentation is on Lonca's site. Questions and ideas go to Discussions, bugs to issues.

This post was first published on my blog.

Kule, screen by screen: an AI agent's task from prompt to undo

Selçuk GÜRAL — Sun, 01 Nov 2026 16:16:48 +0000

Hi again. My first post about Kule was all CLI commands, and I kept wanting to show you the window instead. So this one is screenshots: one small task, from the prompt to the undo, with nothing cut out. That includes the two places where Kule stopped me.

Kule in one line: AI agents work on a copy of your folder, inside a sandbox, and nothing reaches the real folder until you review it and commit it.

How I took these screenshots

I'll say this first, so nothing below looks staged:

This is Kule's real window (0.2.0-preview.20) on Linux, running in a throwaway container on a virtual display. On macOS the window has its native title bar; the rest looks the same.
The project is a tiny Node CLI I made for this post, tiny-weather: four files and one git commit.
The agent is not a model. It's kule-test-agent, the scripted agent Kule's own tests use. It speaks the same protocol (ACP) as Claude Code or Codex, but it runs a list of steps I wrote. That way one run could show a question, an approval and a refusal, and I didn't have to put a real agent's login into a throwaway container. Everything around the agent is real: the copy, the sandbox, the proxy, the policy, the review, the commit and the undo.

The script asked the "agent" to add a --units option, write a test and a README section, bump the version and require Node 20 in package.json, add a git pre-commit hook that runs the tests, and then check that the forecast API answers. That's roughly what an eager agent might do if you asked it to "add Fahrenheit support and make sure the tests run before every commit".

1. The agent at work, and a question

Your tasks are on the left. While the agent works, the bottom panel (Live) shows each tool call on one line, the files it changed after the arrow, and its output under it. The bar at the bottom shows what the run is using: CPU, memory, disk and processes.

Then the agent tried to reach api.open-meteo.com. Package registries and the agent's own model API go through on their own; any other host waits for a person. So the connection is held, a card shows up, and the task moves under Needs you. The card tells you what approving means (a tunnel: Kule sees the host and port, not what's sent over it), which rule held it, and what happens if nobody answers: after 15 minutes the connection is refused and the agent carries on without it.

I pressed Deny. The agent's curl got a 403 from the proxy, and the run finished.

2. Review: what changed, and what the policy says

This is the screen I care about most. At the top is the ruling, and the rule behind each part of it:

package.json needs approval (manifests-and-lockfiles). It decides what gets installed and run, so a person looks at it.
The new git hook is denied (git-hooks). A hook runs on your next git commit, as you, so an agent doesn't get to add one.

Below the ruling, each file shows what changed inside it, by name: function format, variable SIGN, key engines, section Units. You can read what happened before you open a single file. Click a file to see it in Preview, as it is in the copy.

Something I want to be upfront about, because my own docs get it slightly wrong: while a denied change is in the pile, nothing gets committed. The window offers only Roll back, and kule commit --approve refuses too. Parts of the docs say denied changes are "held back" on a commit, which suggests the rest would go through. What Kule actually does is the stricter thing, but the docs, and a hint the CLI prints, should say so. That fix goes into the next preview.

3. Timeline: every step

Every tool call that changed something is a step. Go back here puts the copy back the way it was after that step. Fork from here starts a new task from that point, so you can try another direction without losing this one.

Going back to a step doesn't touch .git, though, so for the hook I used a terminal.

4. A terminal in the same sandbox

The bottom panel also has terminals, and they run in the task's sandbox, just like the agent. Here ls shows the copy. The home folder's ~/.ssh (I put a dummy key there), the folder with other projects, and another project's .env are all refused. curl to a host the policy doesn't let through gets the same 403. git status shows the agent's changes, because the copy is a full working copy, .git included.

From here I removed the hook with rm .git/hooks/pre-commit. That's a change in the copy too, so Review judged it again.

5. Approve and commit

With the hook gone, the ruling is Waits for your approval and the button says Approve and commit. If you tick Don't ask again in this folder, Kule first shows what that would have let through, then remembers it for this folder.

My first click didn't work:

I still had the terminal open on the copy, so Kule wouldn't commit. Fair enough. I closed the terminal and clicked again.

Commit 1 shows up in the Timeline with what it applied. The real folder now has the changes, and no hook.

6. Undo

Undo takes two clicks: the first one turns red and asks again. It puts back what the commit replaced, from the checkpoint Kule kept. Afterwards I checked the real folder: git status was clean and package.json was back at 0.1.0.

What these screenshots don't show

A real model. With Claude Code, Codex or Gemini you'd also see the agent's own messages and thinking, and what the run cost in the task header (the header here says "nothing spent yet").
Refusals listed on Linux. Linux doesn't tell Kule what the sandbox refused; the command just gets a permission error, and the run ends with a line that says so. macOS reports them, and Kule lists them in Live and the Timeline.
Windows. Windows 11 has had release files for a few previews now, but I've only tested it in an ARM64 virtual machine, not on a real x64 PC yet. It's the least tested of the three.
A finished product. It's still a preview, and screens will keep changing.

What changed since my last post

I last wrote about 0.2.0-preview.14; the latest is 0.2.0-preview.20. The biggest changes:

A task's commands read only what's granted: the copy, the system, your toolchains, and folders you add with kule tools add. The rest of your home simply isn't there for them. That's what you see in the terminal screenshot.
Windows 11 builds, with the limits above.
19 security advisories published so far, each one after its fix had shipped.
Mutation testing (cargo-mutants) runs in CI on every change, on macOS and Linux, on top of the tests that run on real processes and the real filesystem.

Try it, and tell me what got in your way

Download: releases page
Docs (English and Turkish), with a page for every screen above: kulehq.github.io/kule
Testing guide, if you'd like to help: kulehq.github.io/kule/docs/testing
Code: github.com/kulehq/kule · Apache-2.0 · Rust

If a screen confused you, or a card asked too often, tell me here or in an issue. If you find a way past one of the boundaries, please report it privately as SECURITY.md explains, not in public.

If this kind of walk-through is useful, I'd like the next one to be about the policy: how Kule decides what passes, what waits and what's denied, and how to write your own rules. Tell me which screen you'd like to see up close.

Thanks for reading. 🙏

Kule needs testers: run AI agents on a copy of your folder, then tell me what broke

Selçuk GÜRAL — Mon, 26 Oct 2026 20:09:26 +0000

Last week I wrote about Kule, the open-source tool I'm building. Your comments turned into real changes, so this time I'd like to ask for something more specific: try Kule on your own computer, and tell me what happened.

Kule in one paragraph

Kule is a control room for AI agents that work on your folders. You point an agent (Claude Code, Codex, Gemini, or any agent that speaks ACP) at a folder. Kule gives it a copy-on-write copy of that folder inside an OS sandbox, looks at what every command really changed, and lets nothing reach the real folder until a policy, or you, says so. Every commit can be undone. It has a CLI and a desktop app, it's written in Rust, and it's Apache-2.0.

What changed since the first post

That post covered 0.2.0-preview.1. The latest is 0.2.0-preview.14. Some of the bigger changes:

The default policy is an allow-list now. Files of a kind known not to run by themselves, or of a kind your project already tracks, pass on their own. Everything else waits for you, scripts and hidden files included.
Nothing an agent writes reaches your home. Agents keep their settings, history and transcripts in a home of their own inside Kule.
A task's commands can't read your other projects, or where apps keep their settings, sign-ins and data, beyond what toolchains and shells need.
Your terminals run in the task's sandbox too, not just the agent.
Kule tells you what it cut, ended or refused, where you're working: in the command's output, the terminal, and the app's Live view.
Releases are built on pinned images and can't be changed once they're published. Each one comes with checksums, a build provenance attestation and an SBOM.
15 security advisories are published so far. Each one went out after its fix had shipped.

Some of these came straight from comments on the first post:

An approval card now says whether Kule looks inside the connection you're approving (#27).
I measured which tools send Encrypted Client Hello before deciding how Kule treats it (#34).
Holding a git push apart from fetches is next (#50).

Thank you to everyone who asked those questions.

What I'm asking for

I wrote a short testing guide with six scenarios. Each takes 5 to 20 minutes, and you can pick any of them:

Install and check. Does the install guide hold up on your machine?
The loop, without an agent. Make a task, change the copy, review, commit, undo. No network or agent needed.
The app, with an agent. Your first task in the desktop app, from prompt to commit.
Your own work. Ask an agent for something you'd ask it anyway, and see whether Kule gets in the way.
Your own setup. This is where I need help most (more on that below).
The boundaries. Try to get past them, and report what you find privately.

At the end of each one, there's only one question: what happened that you didn't expect? A confusing step, a policy that asks too often, a tool that breaks inside the sandbox, a slow copy: all of it is useful. "Everything worked" is useful too.

Setups I can't test myself

Kule is tested on a handful of machines. If yours is one of these, a short report is worth a lot:

a Linux distribution other than Ubuntu, or Ubuntu 24.04 with its user namespace restriction;
a file system other than APFS, Btrfs or XFS;
a large repository or a monorepo;
an Intel Mac;
an ACP agent other than Claude Code, Codex and Gemini.

Before you start

macOS 13+ and Linux x86_64 only. Windows support is in progress, but it's not ready for testing yet.
The macOS app isn't notarized. It's signed ad hoc, so macOS will refuse to open it the first time. The install guide shows how to check the download and open the app.
Start with a test folder, or with a project whose work is all committed and pushed. Kule doesn't touch your folder until you commit, but it's still a preview.
Agents use your own accounts, so a run spends your own quota or API credit, the same as it would without Kule.

How to report

Open an issue at github.com/kulehq/kule/issues/new/choose and pick one of the forms: Bug report, Test report or Idea or change. Questions are welcome in Discussions, or right here in the comments.

Issues are public, so please leave out API keys, tokens, private paths and anything else you wouldn't publish. The forms remind you.

If you find a way past one of Kule's boundaries, please don't post it publicly. Report it privately, as SECURITY.md explains. The fix is made in private and released first, and the advisory credits you unless you'd rather it didn't.

What happens next

I read every report. A fix ships in the next preview, and its issue says which one. The CHANGELOG lists what each preview changed.

Testing guide: kulehq.github.io/kule/docs/testing
Download: releases page
Code: github.com/kulehq/kule

Thanks for reading, and thanks in advance to anyone who gives it 15 minutes. 🙏

I built Kule: AI agents work on a copy of your folder, and you decide what comes back

Selçuk GÜRAL — Wed, 21 Oct 2026 09:10:54 +0000

Hi, I'm Selçuk. I've been building an open-source tool called Kule, and its first preview release is out. I'd like to tell you what it does, why I built it, and what it can't do yet.

The short version: Kule is a control room for AI agents that work on your folders. You point an agent (Claude Code, Codex, Gemini, or any agent that speaks ACP) at a folder. Kule gives it a copy-on-write copy of that folder inside a sandbox, looks at what every command really changed, and lets nothing reach the real folder until a policy, or you, says so. Every commit can be undone.

("Kule" means tower in Turkish. Think control tower.)

The problem I kept running into

Coding agents are good now, good enough that we let them run commands. When an agent runs a command, it runs as you: your files, your ~/.ssh and ~/.aws, your ~/.zshrc, your network, your API keys.

Most agents ask before they run something, but they ask about the command text: "Run npm install?" You can't tell from that text what a postinstall script, a Python one-liner or a build script will actually touch. So after the twentieth prompt you start clicking "yes" without reading, or you switch on the mode that stops asking. And if a file the agent reads contains a prompt injection, the agent is on the attacker's side, and all that's left is what you approve.

I wanted something else: let the agent work freely, somewhere nothing it does is real until I've seen it.

The loop

Kule has one loop, in the CLI and in the desktop app:

make a task → give the agent a prompt → watch → review → commit or roll back.

Here it is without an agent, on a scratch folder:

mkdir -p ~/kule-demo && echo "hello" > ~/kule-demo/notes.md

kule new ~/kule-demo                                    # prints a task id, e.g. 1a2b3c4d
kule exec 1a2b3c4d -- sh -c 'echo "more" >> notes.md'  # runs in the copy, in the sandbox
kule status 1a2b3c4d                                    # what changed, and the policy's verdict
kule commit 1a2b3c4d                                    # apply it, keeping a checkpoint
kule undo 1a2b3c4d                                      # put the folder back

And with an agent:

kule run 1a2b3c4d --agent claude-code "Turn notes.md into a checklist"
kule steps 1a2b3c4d     # every tool call the agent made, and what it changed
kule commit 1a2b3c4d    # or: kule rollback 1a2b3c4d

The desktop app (Tauri) does the same thing with a live stream, an approval inbox, a review screen and a timeline. A small daemon keeps runs going when the window is closed.

What's actually between the agent and your stuff

Your folder. The agent works in a copy-on-write copy: an APFS clone on macOS, a reflink on Btrfs/XFS. Its changes reach the real folder only through a commit, and every commit keeps a checkpoint, so kule undo really puts things back. The history of commits and undos is signed and hash-chained.

Your computer. Every command runs in the OS sandbox: Seatbelt on macOS, Landlock + seccomp + namespaces on Linux. It can write only to the copy and its own temp folders. ~/.ssh, ~/.aws, your Documents and the projects next to the folder are hidden. If the sandbox can't be set up, the command doesn't run. Kule never quietly falls back to "no sandbox".

What gets in. This is the part I care about most. Kule doesn't judge the command; it judges the effects. After a run, it compares the copy with your folder: files created, modified, deleted or moved, git branches moved, hooks added. Then a Cedar policy gives each effect a verdict: pass, ask or deny.

With the default ("balanced") policy:

ordinary edits to source, notes, documents and data pass;
manifests and lockfiles, CI files, editor settings, agent instructions (CLAUDE.md, AGENTS.md, .mcp.json…), git config changes, history rewrites and mass deletes wait for you;
git hooks are denied, because they would run on your next git command, as you.

So a harmless-looking command that rewrites package.json still waits for you, and a scary-looking rm -rf that only touches the copy changes nothing real. When something waits, Kule tells you which rule stopped it:

policy: waits for approval
  package.json · waits for approval (manifests-and-lockfiles)

There's also a "careful" policy where every change waits. You can write your own, and a repository can add refusals of its own, but never loosen yours.

Your network. Every connection goes through the task's proxy. Package registries pass, the agent reaches its own model API while it runs, and anything else waits for your answer. Every connection is logged.

Your secrets. The agent sees a placeholder, never the key. The proxy puts the real value into requests going to the hosts you named, and nowhere else.

Your home. A write to ~/.zshrc, ~/.gitconfig or ~/.config lands in the task's home layer with a diff for you to review. It doesn't touch your real home.

Your wallet and your machine. Cost budgets per task, per group and per day (with a notice at 80%), CPU/memory/disk/time limits per run, and a Stop button.

Not only for code

Kule works on any folder. The review shows what changed inside a file (functions and methods, Markdown sections, JSON/YAML keys), before-and-after pictures, and previews for CSV, Excel and Word. If you let an agent tidy your notes, rename photos or clean up a data folder, the same loop applies.

Two tasks can work on the same folder. A file both of them changed merges method by method, and only the parts that were changed twice conflict.

The honest part: what it can't do (yet)

I'd rather you hear this from me than find out after an hour of setup:

It's a preview (0.2.0-preview.1). Things will change between previews.
macOS 13+ and Linux x86_64 only. Windows is planned, not started.
The macOS app isn't notarized. It's signed ad hoc, so Gatekeeper will complain the first time. Every release file comes with SHA256SUMS, a build provenance attestation and an SBOM, and the install guide shows how to check them and open the app.
Linux has some requirements. On ext4 the copy is a full copy, not a clone. The sandbox needs Landlock (Linux 6.2+, 6.7+ for network rules) and unprivileged user namespaces, which Ubuntu 24.04 restricts by default. Kule tells you what's missing and won't run an agent with weaker isolation unless you choose that knowingly.
The proxy doesn't do HTTP/2 or WebSockets yet. Clients fall back to HTTP/1.1. A few tools on macOS have certificate quirks; the Platforms page lists them all.
Kule doesn't make the agent right. It makes the agent's mistakes cheap and visible. You still review, and Kule's job is to make that review short and honest.
It's built by one person. I take security seriously (every boundary has a test that fails without it, on real processes and the real filesystem, no mocks), but one person can still miss things. That's part of why it's open.

Try it

Download: releases page (universal .dmg, .deb, .rpm, and the CLI alone as .tar.gz)
Or build from source:

  git clone https://github.com/kulehq/kule && cd kule
  cargo build --release -p kule -p kule-desktop

Docs (English and Turkish), with a quick start, a page for every command and a three-minute video tour: kulehq.github.io/kule
Code: github.com/kulehq/kule · Apache-2.0 · written in Rust

What would help me most

Try it on a real folder and tell me where it got in your way. A policy that asks too often, a confusing screen, a tool that breaks inside the sandbox: that's exactly the feedback I'm looking for. Open an issue, or just reply here.

If you find a way through one of the boundaries, please don't post it publicly. Report it privately as SECURITY.md explains. I'll be grateful, and I'll fix it.

And if Kule ends up keeping your folders safe and you'd like to help it keep going, there's GitHub Sponsors. That's completely optional. A star, an issue or a "this worked for me" means a lot too.

Thanks for reading. 🙏

Stop running your whole .NET test suite on every pull request

Selçuk GÜRAL — Fri, 16 Oct 2026 18:30:36 +0000

Every .NET codebase I have worked on hits the same wall sooner or later. The test suite grows, CI goes from three minutes to twenty, and every pull request pays the full price, even a one-line rename deep inside a helper class.

Splitting the suite or buying bigger runners helps for a while. But most of those tests could never have noticed the change in the first place. They run anyway because nothing tells CI which ones matter.

So I built TestDetta: a .NET tool and GitHub Action that reads your diff and runs only the test classes that can observe it. It follows one rule throughout: when it cannot be sure, it runs more tests, never fewer. A missed test is a bug. An extra test only costs CI time.

This post covers how it works, how to try it in a few minutes, and how to check that it holds up on your own code before you trust it.

A real example

Here is a real change to OpenTelemetry .NET: a local variable renamed inside one method. It changes no behaviour, but a normal pipeline still runs all 30 test projects and 274 test classes.

TestDetta works it out like this:

Projects: 2 of 30 test projects are affected. The other 28 are not even built.
Symbols: 1 member changed, WarnIfConfigFileEnvVarDiffers.
Coverage map: 8 test classes ran that method on main.
Result: 8 of 274 classes run, 266 are skipped.

Those 8 classes are exactly the ones that fail when that method is broken. Recorded test time went from 5 m 59 s to 22.4 s.

Try it in two minutes

TestDetta is a .NET tool (it runs on the .NET 10 SDK; your projects can target older frameworks):

dotnet tool install --global TestDetta

Ask what your branch affects, and why:

td affected --base origin/main

See the dotnet test commands it would run, without running anything:

td test --base origin/main --dry-run

And run only the affected tests:

td test --base origin/main

The output looks like this:

$ td test --base origin/main
TestDetta 0.2.2 · 1 changed file · 2 affected test projects
Tests to run
┌──────────────────┬──────────┬─────────┬──────────────────────────────────────────────────────────┐
│ Test project     │ Run      │ Classes │ Why                                                      │
├──────────────────┼──────────┼─────────┼──────────────────────────────────────────────────────────┤
│ tests/Shop.Tests │ filtered │  3 / 41 │ 3 of 41 test class(es) run or reference the changed code │
│ tests/Api.Tests  │ skipped  │  0 / 12 │ no test class runs or references the changed code        │
└──────────────────┴──────────┴─────────┴──────────────────────────────────────────────────────────┘
  tests/Shop.Tests → 3 classes
    Shop.Tests.CartTests
    Shop.Tests.CheckoutTests
    Shop.Tests.OrderTests

Without a coverage map, TestDetta decides by tracing names through your source. For sharper selection, record a map once on your default branch:

td record

This runs every test with coverage and writes one map per test project to .testdetta/coverage (add .testdetta/ to your .gitignore).

Need machine-readable output? td affected --format json gives you the selection for your own scripts, --format paths lists the test projects, and --format commands prints the dotnet test commands.

How it decides

Each step narrows the selection only when it has evidence. Otherwise it falls back to something wider.

Projects. Changed files are mapped to their projects and followed through ProjectReferences. Build-wide files such as Directory.Build.props, global.json or .editorconfig affect every project below them.
Symbols. For C#, Visual Basic and F# files, the old and new syntax trees are compared (Roslyn for C# and VB). Comment and whitespace edits select nothing. Otherwise TestDetta knows exactly which types and members changed.
Coverage. A map of which test class ran which method, recorded at the base commit, gives the test classes for changed methods, properties and constructors directly.
Names. What coverage cannot see, such as new code, fields and constants, is traced through the source by name until it reaches test classes or code the map knows.
Fallbacks. When a change cannot be traced, the whole test project runs. That covers non-code files the build uses (appsettings.json, .csproj, .resx), global usings, assembly attributes, and types a framework discovers through reflection (controllers, message handlers, EF configurations).

There is one more safety net: if a filter matches no test at all, TestDetta treats that as its own bug and runs the project again without the filter.

A few details took a lot of work to get right:

Maps don't have to be fresh. The best map is one recorded at your branch's merge base. A map up to 50 commits older still works: TestDetta also selects the classes that ran anything changed in between that could reach your change.
Source generators are handled. Generated code is read from the PDBs during recording. When a change reaches a generator in your repository, TestDetta builds the test projects that use it and compares what is generated, framework by framework.
#if code is not missed. C# files are parsed with each target framework's real preprocessor symbols, and with every symbol their #ifs name.
Your test configuration is respected. Your own --filter, run settings and runner arguments are combined with TestDetta's class filter, so it only ever narrows your runs.

In GitHub Actions

The usual setup records a map on every push to main and runs only the affected tests on pull requests:

on:
  push:
    branches: [main]
  pull_request:

permissions:
  contents: read
  actions: read # lets pull requests find the newest coverage map in the Actions cache

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7 # pin to a commit SHA
        with:
          fetch-depth: 0 # TestDetta compares with the merge base
          persist-credentials: false

      - uses: actions/setup-dotnet@v6 # pin to a commit SHA
        with:
          global-json-file: global.json

      # Full test run of main, which also records the coverage map
      - if: github.event_name == 'push'
        uses: TestDetta/action@a2f55a8252840a367f2f7a9ebd6733de3ebfb2f5 # v0.2.2
        with:
          mode: record

      # Pull requests run only what the change can affect
      - if: github.event_name == 'pull_request'
        uses: TestDetta/action@a2f55a8252840a367f2f7a9ebd6733de3ebfb2f5 # v0.2.2
        with:
          mode: test
          dotnet-test-args: --logger trx

Maps live in the Actions cache, keyed by commit, and pull requests read the map of their merge base. Every run writes a job summary explaining what ran and why.

Not on GitHub? GitLab CI, Azure DevOps, Jenkins and Bitbucket use the same two commands (td record and td test) with a folder of per-commit maps on a shared disk or object storage (--maps-dir).

Don't trust it, check it

A tool that decides which tests to skip has to earn your trust on your own codebase, not on a marketing page. TestDetta ships two ways to check it, and neither needs a license:

Shadow mode (td test --shadow, or mode: shadow in the action) keeps running your full suite and compares the result with what the selection would have run. When a test fails outside the selection, it reruns that class to tell a real miss from a flaky or pre-existing failure. Run it for a couple of weeks of normal pull requests and you have evidence from your own code.

Audit (td audit, or mode: audit) doesn't wait for real failures. It breaks your code on purpose, one member at a time with IL mutants in a copy of the working tree, runs every test that can see each change, and reports any failing class the selection left out. It also reports the 95% upper bound of the miss rate. Your sources and build output are only read.

How it is tested

I run the same check at scale on 53 open-source .NET repositories, including Polly, Newtonsoft.Json, AutoMapper, Serilog, Markdig, Refit, Autofac, NodaTime, FastEndpoints, FluentValidation and OpenTelemetry. Members are changed one at a time, and every test class that fails must be one TestDetta selected.

From the latest round (2026-10-13 to 2026-10-15):

3,071 changes broke at least one test.
5 misses, each a documented limitation (more on those below). Earlier real misses were fixed, each with a regression test that fails without the fix.
The median repository ran 35% of its test classes per change. In 20 of the 53 repositories it was a quarter or less, and Polly got down to 3%.

To be upfront: some repositories gain much less. Mapperly ran 97% and AutoMapper 86%, because nearly every test there goes through the same central code paths. If most of your tests touch everything, test impact analysis can't save much, and the evaluation shows that honestly.

Limitations

TestDetta is static and coverage-based analysis, not magic. Here is what it can't fully see:

Code that runs once per process (static constructors, lazy singletons, EF model building) is credited to the first test class that triggers it. TestDetta traces changes to such code by name instead, but a cache you wrote by hand (a Dictionary checked with TryGetValue) can still hide its users.
Reflection and dynamic loading are only partly visible. Types a framework discovers this way run their whole test project.
F# signature files (.fsi) are not analysed, so a change to one runs its project's dependents.
Tests skipped while recording have no coverage, for example a missing Docker daemon. Record where your tests actually run.

The full list is on the Limitations page. My recommendation: keep running the full suite on your default branch. Recording does that anyway, so anything a selection could ever hide is still caught before release.

What's supported

Test frameworks: xUnit v2, xUnit v3, NUnit, MSTest and TUnit
Runners: VSTest and Microsoft.Testing.Platform (read from global.json)
Languages: C#, Visual Basic and F#
CI: GitHub Actions, GitLab CI, Azure DevOps, Jenkins, Bitbucket and on-premises setups

Privacy and licensing

None of your code leaves your CI. Analysis, coverage maps and test results stay on your machines. The only network call is an optional license renewal, at most once a day, that sends the license and nothing else.

TestDetta is free for public repositories on GitHub Actions and GitLab CI, with every feature and no sign-up. It detects public repositories from the CI itself. Private repositories need a paid license, with a 30-day free trial that needs no card. A license problem never fails your build: without a valid license, every test simply runs, as it did before TestDetta.

Anka: Designing a Minimal HTTP Server for Native AOT, Its Architecture, and Intentional Constraints

Selçuk GÜRAL — Fri, 01 May 2026 16:48:33 +0000

In modern backend systems, being “fast” alone is no longer enough. How quickly your service responds to the first request, how little memory it consumes at startup, and how predictably it behaves are now just as important as raw throughput. Especially in serverless, short-lived container, edge worker, and bursty internal service scenarios, the real problem is often not steady-state throughput, but cold start performance, startup allocations, and operational simplicity.

Anka approaches this problem from the opposite direction of the traditional ASP.NET Core model: no middleware pipeline, no built-in routing, no TLS, no HTTP/2. Instead, it provides a Native AOT-friendly, HTTP/1.x-focused, allocation-conscious HTTP server core built on .NET 8+. The goal is straightforward: once the process starts, begin listening on the socket within milliseconds and keep the connection/request lifecycle as deterministic as possible.

The Problem

The traditional .NET web stack is extremely powerful, but that power comes with a cost. Middleware chains, reflection-heavy surfaces, dynamic extensibility, broad protocol support, and JIT warmup all introduce significant overhead on the cold-start path. If your actual requirement is simply:

“Open a socket, parse HTTP/1.1, execute a handler, and write the response,”

then the general-purpose framework model can become unnecessarily expensive.

The core question Anka focuses on is:

If we do not need a full-featured web framework, but only a fast-starting, low-memory, Native AOT-compatible HTTP listener, what should the minimum architecture look like?

The answer becomes visible in the performance characteristics as well. In measured environments, Anka reaches a time-to-ready of approximately 2.3 ms, startup allocations around 124.5 KB, and a steady-state RSS of roughly 15 MB. Kestrel, by comparison, offers a much broader feature set, but carries a heavier cold-start and memory profile. Interestingly, throughput differences are not dramatic; Anka’s real advantage is not raw requests-per-second, but startup cost and footprint.

Architecture: Minimal Layers, Maximum Control

Anka’s architecture is intentionally narrow:

Server.StartAsync()
-> parallel accept loops
-> Connection.RunAsync() (one task per TCP connection)
-> SocketReceiver.ReceiveAsync()
-> HttpParser
-> RequestHandler(request, response, ct)
-> HttpResponseWriter.WriteAsync()

The important aspect of this flow is that there is very little abstraction. Request processing starts directly at the socket layer and ends directly at the socket layer.

Server: The Acceptance Layer

The server opens the listening socket, configures the backlog, and runs multiple parallel accept loops instead of a single accept loop. This may sound like a small detail, but under burst traffic it prevents a single accept loop from serializing connection acceptance.

Additionally, the minimum thread pool size is increased to reduce thread injection latency during initial load. This may look like benchmark tuning, but in reality it is an operational decision intended to make cold-path behavior more deterministic.

Connection: The Real Unit of Execution

A Connection task is created for each TCP connection. This object:

rents a pooled receive buffer,
acquires a pooled HttpRequest,
creates a connection-scoped HttpResponseWriter,
reads and parses data from the socket,
invokes the request handler,
and if keep-alive is enabled, continues with the next request using the same resources.

The critical idea here is resource ownership at the connection level rather than the request level. This minimizes repetitive buffer rental and return operations across keep-alive requests.

SocketReceiver: Async I/O with Allocation Discipline

Instead of using the more convenient Socket.ReceiveAsync(Memory) APIs, Anka uses SocketAsyncEventArgs together with IValueTaskSource.

This is not micro-optimization for its own sake. The goal is to avoid state machine overhead and additional allocations when socket reads complete synchronously.

In loopback or LAN scenarios, data is often already available in the kernel buffer. In those cases, the receive operation completes synchronously and the system proceeds with almost direct function-call overhead. If data is not available, the OS I/O completion thread finishes the operation, while continuations are posted back to the thread pool using RunContinuationsAsynchronously = true.

The result: I/O threads are not blocked by request-processing work.

HttpParser: Single-Pass Parsing

The parser’s real value is not merely that it parses HTTP, but that it does so in a single pass using pooled buffers.

It performs:

request line parsing,
path/query separation,
lowercase normalization of header names during ingestion,
inline Content-Length tracking,
request body reading when necessary,
chunked request body decoding and reassembly into req.Body,
keep-alive decision calculation during parsing.

This approach provides two important benefits:

No second header scan is required.
The HttpRequest passed to the handler is already in a usable, near zero-copy state.

HttpResponseWriter: Not a Framework, Just Wire Format

The response layer follows the same philosophy. HttpResponseWriter constructs the HTTP response header block inside a pooled buffer, inlines small bodies into the same buffer whenever possible, and writes directly through Socket.SendAsync().

Another important design choice here is the absence of chunked response encoding. All responses use Content-Length.

This constraint simplifies the response pipeline significantly and narrows the execution path for AOT and low-allocation goals.

Core Design Decisions

A Single RequestHandler Delegate

Anka has no middleware chain. There is only one RequestHandler.

This is a deliberate form of radical simplification.

Benefits

shorter call chains,
fewer abstraction layers,
lower dispatch overhead,
a cleaner surface for Native AOT.

Costs

cross-cutting concerns must be implemented manually,
routing, authentication, logging, and metrics are not framework-managed.

This is not an “incomplete framework”; it is a primitive-oriented design.

No Built-in Routing

Path dispatching is left entirely to user code. A simple switch statement is considered sufficient for many scenarios.

At first glance this may appear primitive, but routing costs are not limited to path matching itself. Routing systems also bring metadata graphs, endpoint conventions, and large API surfaces. Anka rejects that cost upfront.

Lowercasing Header Names During Ingestion

Instead of performing case-insensitive lookups repeatedly, header names are normalized during parsing. This allows lookups to use straightforward SequenceEqual comparisons.

It may seem like a small design detail, but on the hot path it reduces both branching and processing overhead.

Reusing HttpRequest and Buffers Across Connections

The HttpRequest.ResetForReuse() approach avoids discarding request objects after every request. The same object is reused throughout the connection lifetime.

This becomes especially effective under keep-alive workloads, because steady-state allocation reductions often come not from huge optimizations, but from many small, systematic reuse decisions.

Small CAS-Based Request Pool

The HttpRequestPool is lock-free and intentionally small.

The goal is not theoretical “infinite pooling,” but a practical, cache-friendly, low-overhead reuse mechanism. If all slots are occupied, objects are simply discarded.

This is another important engineering decision: trying to pool everything can sometimes become more expensive than not pooling at all.

Trade-offs: What This Architecture Gains — and Intentionally Gives Up

One of Anka’s strengths is that it clearly communicates what it is not.

Decision	Benefit	Cost
No middleware	Shorter hot path, fewer abstractions	Developers handle cross-cutting concerns
No built-in routing	Lower startup cost, simpler model	Reduced ergonomics in large APIs
HTTP/1.x only	Narrower execution path, simpler AOT surface	No modern protocol features
No built-in TLS	Keeps the core minimal	Reverse proxy becomes mandatory
No chunked responses	Simpler response writer	Limited streaming ergonomics
Raw socket approach	Full control over allocations and behavior	Higher maintenance burden

The most important trade-off is this:

Anka does not exist to replace Kestrel. It exists to occupy a different optimization point.

If you need HTTP/2, TLS termination, middleware ecosystems, advanced hosting integrations, or rich observability plugins, then Kestrel is probably still the correct answer.

But if your priority is low footprint, rapid readiness, and a highly controlled request path, Anka becomes compelling.

The Strongest Part of This Design: Predictability, Not Performance

In my opinion, the real value here is not just “0 B allocations” or “2.3 ms startup.”

The real value is how easy it becomes to mentally model the system:

one task per connection,
connection-scoped buffers,
parse → handle → write pipeline,
very few failure states,
limited protocol surface.

Architecturally, systems like this become valuable not because of benchmark presentations, but because of operational clarity. You know exactly what the system does, what it does not do, where behavior changes under load, and where costs are paid.

Example Use Cases

Serverless or Short-Lived Container APIs

If cold start is critical and the endpoint surface is small, Anka’s minimal startup overhead becomes a major advantage.

Sidecar / Internal Control Plane Endpoints

For health checks, readiness probes, metrics gateways, or simple control APIs, a full framework is often unnecessary.

Edge Compute and Appliance Deployments

Low RSS and Native AOT compatibility matter significantly in resource-constrained environments.

Benchmarking and Protocol Research

Anka provides a clean environment for teams that want to observe HTTP pipeline behavior without framework noise.

Narrowly Scoped, High-Control Services

It is well suited for single-purpose webhook receivers, internal callback endpoints, or lightweight ingestion services.

When I Would Not Use It

Personally, I would avoid this architecture for:

large general-purpose product APIs developed by big teams,
applications requiring rich middleware ecosystems,
systems where streaming, TLS, or HTTP/2 are first-class requirements,
organizations where framework integrations matter more than low-level control.

Because what you gain here is not “freedom.”

It is control.

And control always comes with increased engineering responsibility.

Conclusion

The most accurate technical summary of Anka is this:

It is not an HTTP server that gains performance by adding optimizations on top of features; it gains simplicity and predictability by deliberately reducing scope.

Native AOT compatibility, low startup allocations, connection-scoped resource management, single-pass parsing, and direct socket writing all serve the same goal:

a small, fast-starting, understandable request pipeline.

This approach is not for everyone — and it is not trying to be.

From an experienced backend engineering perspective, its most mature characteristic is precisely this: it defines the problem narrowly, optimizes aggressively for that problem, and consciously leaves everything else outside the boundary.

And often, that is a far more valuable engineering decision than building a system that tries to do everything.

Originally published in Turkish on my personal blog:

https://selcukgural.com/2026/04/17/anka-native-aot-icin-minimal-http-sunucusu-tasarlamak-ankanin-mimarisi-ve-bilincli-kisitlari/