DEV Community: ...

pledge: a fast double-entry ledger inside PostgreSQL, ready for Django

... — Thu, 12 Nov 2026 15:54:04 +0000

pledge is a double-entry ledger that runs inside PostgreSQL, with a Django package on top. If your app moves money, credits or points, it keeps the books for you:

Balanced by design. Every transfer writes two entries that sum to zero.
History built in. Each entry stores the running balance, so you can ask for any past balance.
Safe retries. Send your own transfer id; the same transfer twice is booked once.
Tamper-resistant. Ledger rows can't be deleted or edited; accounts are closed, never removed.
Fast. Written in Rust, one SQL statement per transfer or batch.

Django first

With django-pledge the ledger looks like ordinary Django models:

pip install django-pledge

INSTALLED_APPS = [..., "django_pledge"]

from decimal import Decimal
from django_pledge.models import Account, Transfer

cash = Account.objects.create(name="cash", currency="EUR")
alice = Account.objects.create(name="alice", currency="EUR", allow_negative_balance=False)

cash.transfer(alice, Decimal("10.00"))
Transfer.objects.bulk_create([
    Transfer(from_account=alice, to_account=cash, amount=Decimal("2.50")),
    Transfer(from_account=cash, to_account=alice, amount=1),
])  # one atomic batch, one statement

alice.refresh_from_db()
alice.balance          # Decimal('8.50')
alice.history()        # every entry, with its running balance

Overdraw Alice's account and you get a typed exception, NegativeBalanceNotAllowed, with the account id attached. Store a TransferId with your own record before you call the ledger, and a retry books nothing twice. Link your own models with a normal ForeignKey to pledge.Account.

Or plain SQL

Django is optional. Everything is a function in the pledge schema:

CREATE EXTENSION pledge;

SELECT id FROM pledge.create_account('bank', 'USD');
SELECT id FROM pledge.create_account('alice', 'USD', allow_negative_balance => false);

SELECT * FROM pledge.create_transfer('pla_…bank', 'pla_…alice', 100.00);

SELECT name, balance FROM pledge.accounts_view;
SELECT * FROM pledge.verify();   -- every check should say ok

Fast, and checked

pledge grew out of pgledger by pgr0ss, and we still benchmark against it:

pledge is about 1.5 times faster per transfer and about 2 times faster for batches. Speed only counts if the books stay straight, so pledge also passes a bank test where connections are killed mid-transfer, a model-based test, and a replay of a real bank's million transactions.

It's a young project, so the API may still change before 1.0. It runs on PostgreSQL 17 and 18.

Try it

Docs: https://pgpledge.github.io/pledge/
Tutorial, build a small currency exchange in Django: https://pgpledge.github.io/pledge/django/exchange/
Repository: https://github.com/pgpledge/pledge
PyPI: https://pypi.org/project/django-pledge/

Clone the repo and run just example to click through the exchange in your browser. Feedback and issues are very welcome.

tackline: Backseat driving for your coding agent.

... — Mon, 26 Oct 2026 08:23:51 +0000

Coding agents got good at writing code. Telling them exactly what to change is still clumsy, so I built a small tool for that part: tackline.

Most of my day with Claude Code isn't typing prompts from scratch. It's reading what the agent just did, spotting what's off, and sending it back for another pass. That loop is where the friction lives.

The problem: prompts full of paths and line numbers

You review a diff and see five things. The loop in the matcher should be an iterator chain. That helper already exists, use it. Don't touch the public function signature. And so on.

Then you turn those thoughts into a prompt. You copy a file path, look up the line numbers, paste a snippet so the agent knows which loop you mean, and write the instruction. Five times. By the third one, you're writing "also the thing in utils" and hoping the agent guesses right.

The information you need is all on your screen while you're reading the code. The prompt is just a worse copy of it, assembled by hand.

What tackline does

tackline is a terminal app that lets you point at code and write what the agent should do there. It turns all those notes into one prompt.

Run tackline (or tack) in a repository. It opens on the git diff if you have uncommitted changes, otherwise on a file browser.
Select a line or a block of code with V, v, Shift+arrows or the mouse, and press c.
Write the instruction and press Enter. Notes collect in a named session.
Press 3 to see the session, then y to copy it.

What you paste into your agent looks like this:

# Search speedup

1. `src/matcher.rs:3-7`
   ```rs
       for item in items {
           if item.contains(query) {
               out.push(item.clone());
           }
       }
   ```
   replace the loop with an iterator chain

Every note carries its file, its lines and the code as it is right now. The agent doesn't have to guess which loop you meant, and you never typed a path.

Before you copy, the Session view shows every note with its code in prompt order. You can reorder, edit or drop notes before the agent sees them.

Notes follow the code

Steering an agent happens in rounds: you note things, the agent edits the files, you look again and note more. Line numbers break the moment the agent touches a file.

So each note remembers the code it was attached to, not just its line numbers. When lines are inserted above it, or the code moves within the file, the note moves with it. If the code is gone entirely, the note is marked stale and left out of the prompt, with a warning so you know.

Sessions are saved as you go, in readable JSON files in the repo. Close the app, come back tomorrow, and your notes are still there.

In the editor, noted code is tinted, with a marker in the gutter. You can see at a glance what you've already flagged, and press Enter on a noted line to read the whole note.

Works with any agent

The output is plain Markdown, so tackline doesn't care which agent you use. Press y to copy it, or hand it over from the shell:

Agent	Hand over the prompt
Claude Code	`tackline export \
Codex	{% raw %}`codex exec "$(tackline export)"`
opencode	`opencode run "$(tackline export)"`
aider	`aider --message "$(tackline export)"`
Cursor	paste it into the chat, or `agent -p "$(tackline export)"`

For Claude Code there's an extra: a small skill file turns your active session into a /tackline slash command, so the agent reads your notes itself.

And if you'd rather click than learn keys, tackline serve opens the same tool in your browser, on localhost only, working on the same files.

Steering, not reviewing

I first tried code review tools for this, and they didn't fit. Review tools are built around verdicts: approve, request changes, resolve the thread. That's the wrong shape for working with an agent.

A tackline note is an instruction. "Make this async." "Use this helper instead." "This is the pattern to follow." "Don't touch this signature." Some notes are about code the agent wrote, others point at existing code it should read first. Together they're a brief, not a review.

That's also why it works before a task, not only after one. Browse a codebase, pin the places that matter, and give the agent a prompt that already knows where to look. If you work on a fork, tackline --base upstream/main shows only your changes, so you can annotate exactly what differs.

Try it

tackline is free and MIT licensed, with prebuilt binaries for macOS, Linux and Windows. No Rust needed:

# macOS and Linux
curl --proto '=https' --tlsv1.2 -LsSf https://github.com/terminalkitten/tackline/releases/latest/download/tackline-installer.sh | sh

# Homebrew
brew tap terminalkitten/tackline https://github.com/terminalkitten/tackline
brew install terminalkitten/tackline/tackline

# Windows (PowerShell)
powershell -ExecutionPolicy Bypass -c "irm https://github.com/terminalkitten/tackline/releases/latest/download/tackline-installer.ps1 | iex"

# With Rust
cargo install tackline

Then run tack in any repository, select some code and press c.

Docs: terminalkitten.github.io/tackline
Code: github.com/terminalkitten/tackline
Crate: crates.io/crates/tackline

It's a young project, so I'd love to hear how you steer your agents and what's missing. Open an issue, or tell me where it got in your way.

dokk: a tiny docs generator I built for my own Python libraries

... — Mon, 19 Oct 2026 20:30:26 +0000

I maintain a handful of small Python libraries. None of them is big, but every one of them needs documentation: how to install it, a quick start, a few guides, the options. And every time, setting up the docs took longer than it should.

Why I built it

The tools I tried are good, but none of them fit a small library:

Sphinx is powerful and made for large projects. For a library with ten pages, I spent more time on conf.py, extensions and reStructuredText than on the docs themselves.
MkDocs comes closest, and most projects use it with Material for MkDocs. It is a great, complete theme, but this one is personal: the Material look never did it for me. I wanted something quieter and cleaner.
Docusaurus, Starlight and VitePress produce beautiful sites, but they bring a JavaScript toolchain into a Python project, just for the docs.

What I wanted was simple: pip install one thing, write Markdown in a docs/ folder, push, and get a site that looks good and has search and dark mode, without assembling anything. I also wanted a tool small enough that I could read all of it.

That became dokk.

It is about 2,000 lines of Python code. You give it a folder of Markdown and it writes plain HTML: a sidebar from your folders, search, dark mode, code highlighting and a set of components, all at build time. There are no plugins to choose and nothing to configure before the first page works.

It is deliberately not everything. dokk does not generate API docs from docstrings, and there is no plugin system. If you need those, Sphinx and MkDocs are still the right tools. If you want good-looking docs for a small project in ten minutes, read on.

Tutorial: docs for a small library

We will add docs to a small, made-up library called slugkit, which turns text into URL slugs. Use your own project instead: the steps are the same.

1. Install dokk

pip install "dokk[serve,search]"

serve adds the dev server with live reload, search adds full-text search (Pagefind). Both are optional; plain pip install dokk builds sites without them.

2. Create the site

In the root of your repository:

dokk init

This creates four things:

dokk.toml                      title and settings
docs/index.md                  the home page
.gitignore                     .dokk/ added (the build output)
.github/workflows/docs.yml     publishes the site to GitHub Pages

init never overwrites your files; an existing .gitignore only gets the .dokk/ line added.

3. Start writing

dokk serve

Open http://127.0.0.1:8002/ and edit docs/index.md. The page reloads every time you save.

4. Add pages and folders

Every .md file is a page, and every folder becomes a group in the sidebar. For slugkit:

docs/
  index.md
  getting-started/
    index.md
  guides/
    unicode.md
  reference/
    api.md

A page's title comes from its first # Heading, or from front matter, where you can also set its place in the sidebar:

---
title: "Getting started"
sidebar:
  order: 1
---

Links between pages are plain relative Markdown links, such as [the guides](../guides/unicode.md). dokk turns them into the right URLs, and tells you when one is broken.

5. Use components

Components are short Markdown blocks, so your docs stay readable on GitHub and in any editor. The getting-started page of slugkit uses three of them:

::install[slugkit]

:::steps
1. Install slugkit.
2. Import it: `from slugkit import slugify`.
3. Call `slugify("Hello World")`.
:::

:::tip
Next, read the [guides](../guides/unicode.md).
:::

::install shows the pip, uv and poetry commands as tabs, and remembers which one the reader picked across the whole site. There are also tabs, cards, callouts, file trees, badges, images, and components for AI projects such as model cards, chats and tool schemas. The components guide shows them all.

6. Check before you publish

dokk check

This builds the site and reports broken links, missing anchors and pages without a title, each with the file it is in. It is also the first step of the GitHub workflow, so a broken link never reaches your live docs.

7. Configure the site

dokk.toml needs only a title. A few more lines make it yours:

title = "slugkit"
site_url = "https://you.github.io/slugkit/"

[theme]
color = "blue"

[links]
github = "https://github.com/you/slugkit"
edit_url = "https://github.com/you/slugkit/edit/main/docs/{path}"

site_url gives you a sitemap and correct links on GitHub Pages. color picks one of the shadcn/ui accent colors; try them all on the theme showcase. The links add a GitHub icon in the header and an "Edit this page" link under every page.

8. Publish

Push to GitHub, then go to Settings → Pages and set Source to GitHub Actions. The workflow from dokk init builds the site on every push to main and publishes it. That's it: your docs are live.

Optional: keep your Markdown tidy

dokk format formats every page, so lists, tables and spacing look the same everywhere. It knows dokk's Markdown, so your components, front matter and tables stay intact:

pip install "dokk[format]"
dokk format

dokk format --check changes nothing and fails when a page is not formatted, which makes it a good fit for CI or a pre-commit hook. Under the hood it is mdformat with mdformat-directives, a plugin I wrote alongside dokk.

What you get

A sidebar from your folders, or arranged by hand in dokk.toml.
Search, dark mode and code highlighting, with no JavaScript framework.
Plain HTML with every asset bundled: no CDN, no tracking. It works on any static host.
A Markdown copy of every page and an optional llms.txt, so AI tools can read your docs too.
Fast builds: a thousand pages in about a second and a half.