DEV Community: slawekluzny

How the Ledger Module Actually Works: SQLite, Regex, and Avoiding LLM Maths

slawekluzny — Tue, 13 Oct 2026 08:00:06 +0000

How the Ledger Module Actually Works: SQLite, Regex, and Avoiding LLM Maths

We built Kep's Ledger module with accountants in mind, but it's useful for anyone who needs to work with financial figures in documents without pasting them into a cloud chatbot. Here's the technical reality under the hood — no fluff, just the facts.

The Core Problem: LLMs Shouldn't Do the Adding Up

Language models are good at reading and explaining. They are not reliable calculators: ask one to total a column of figures from a document and it may well give you a confident, plausible and wrong number. For accounting work that's not a quirk, it's a liability.

So Ledger never asks the model to do the arithmetic. It runs two paths side by side:

Semantic RAG (retrieval-augmented generation) for questions about meaning — "explain this VAT treatment".
Deterministic SQL sums for the numbers themselves.

When a document is added to the Ledger module:

Extract the text (PDFs via pypdf, the same ingest path as every other module).
Parse amounts with a deliberately conservative regex — £1,234.56, GBP 1,234.56, 1,234.56 GBP — together with the line they appear on.
Store each amount as integer pence in its own SQLite table.

When you ask a question in a Ledger conversation, Kep sums those stored amounts in SQL — across the Ledger documents you're allowed to see — and hands the model a block like this alongside the retrieved text:

Computed totals (from 14 structured record(s), computed exactly — not by you):
- Sum: £7,407.36 GBP
- ...

The module's system prompt tells the model to treat that block as authoritative over any figure it reads out of the documents, while still explaining the numbers in plain language. The model reads and explains; SQL does the maths.

No Cloud, No Shared Anything

The security model is the same as the rest of Kep:

Physical isolation: each firm has its own machine running its own local model — no shared server, no shared GPU time, nothing wired between one client and another.
Strict ownership: even within a firm, one person can't see another's documents unless they're explicitly shared. The Ledger totals go through exactly the same visibility rule as chat and search (visible_document_ids()), so a sum can never include a colleague's private figures.

Ledger uses the same SQLite + sqlite-vec setup as everything else because:

It works fully offline.
Backup is copying one file — no database server to run.
There's nothing extra to install, secure or keep patched.

One Codebase, Modules Switched On by Licence

Every Kep install has the same code. Industry modules (Ledger, Clause and others) ship inert and are switched on by a licence grant from our licensing service — not by installing a different build. The registry lives in modules/base.py.

The one exception is Forge, our internal development module: it only registers itself when node_type == "internal_dev", so a client install never sees it at all.

The Takeaway

For regulated work, AI isn't about flashy demos — it's about numbers you can check and a system you can explain to an auditor. That's why the Ledger module:

relies on regex and integer arithmetic for figures,
never lets the model invent or recalculate a total,
keeps its data in a single local SQLite file on the firm's own machine.

It's not revolutionary. It just works without asking anyone to put blind faith in a black box — and for accountants, that's the whole point.

Footnotes for the especially pedantic

Yes, the regex won't catch every format. Anything it can't match confidently is left out of the totals rather than guessed — the figure is still there in the document for the model to quote and for you to check.
Amounts are stored as integer pence to avoid floating-point drift, and only formatted as pounds for display.
Today the totals cover all Ledger documents you can see. Filtering them by date or category ("expenses last quarter") is not built yet.

Kep is built by FixFlex Ltd, London. Try the online demo — a fictional firm, no sign-up — at kep.fixflex.co.uk.

How Sentinel Shares Threat Intelligence Across Your Servers

slawekluzny — Sun, 04 Oct 2026 21:16:07 +0000

How Sentinel Shares Threat Intelligence Across Your Servers

Most server security tools work alone. Each machine bans the attackers it sees, and the next machine has to learn about the same attacker from scratch. Sentinel's approach is to let every protected server learn from the others. Here's how that works, and what Sentinel does (and deliberately doesn't do) automatically.

The building blocks on each server

Sentinel's security autopilot integrates with three tools that do the actual blocking on every server: Fail2Ban (jail management), CrowdSec (threat intelligence and an HTTP guard) and UFW (firewall rule monitoring).

On top of that, Sentinel detects which services are running and automatically installs Fail2Ban jails for them: sshd, nginx, caddy, apache and mysqld. For MySQL, that means failed logins are caught by a dedicated mysqld jail instead of being left unprotected.

Cross-Fleet IP Reputation: one server's attacker is every server's attacker

This is where the fleet comes in:

Each server reports the IPs it has banned to Queen, Sentinel's central server.
Queen correlates those reports every hour, over the last 7 days, and publishes known attackers as IP-reputation entries.
On their next sync with Queen, the other servers in your fleet ban those IPs too, before they've tried anything there.

So an IP that hammers SSH on Server A gets blocked on Server B without Server B having to see a single failed login. Cross-Fleet IP Reputation is part of the Enterprise tier ($149/month, up to 10 servers).

What stays a human decision

Some actions are powerful enough that Sentinel leaves them to you:

Subnet bans. Sentinel does not automatically block whole ranges. If you decide a /24 or /16 needs banning, an admin can do it in Fail2Ban through the AI Chat tool ban_subnet (Enterprise), as a manual, operator-approved action.
HTTP floods are handled by the Rate Limiting / Active Shield feature (Pro and above), not by the uptime monitor.

Beyond attacks: certificates

Not every risk is an attacker knocking on the door. Sentinel also monitors SSL certificates and alerts you before they expire, so a forgotten renewal doesn't turn into downtime.

Sentinel AI is available in three tiers:

Basic: Free for 1 production server.
Pro: $49/month for up to 5 servers.
Enterprise: $149/month for up to 10 servers, with AI Chat, AI Healer and Cross-Fleet IP Reputation.

Sign up at sentinel-ai.info/pricing to receive a personalised one-line install command (installation takes about 2–4 minutes).

Built by FixFlex Ltd, a London-based AI and web studio.

How AI Became My Dev Team (And Why I Still Make The Decisions)

slawekluzny — Sun, 04 Oct 2026 18:48:23 +0000

How AI Became My Dev Team (And Why I Still Make The Decisions)

I run a construction company in West London. I also build software: a classifieds platform, a server-security tool, a couple of content tools. I am not a programmer in the way people usually mean it. I can't write most of that code from memory, and I've stopped pretending that I need to.

My working rule fits on one line: I imagine, describe, verify. AI codes. I decide.

This post is about what that actually looks like day to day: where AI genuinely does the work, and where I refuse to let it.

Where it started: paying for code I couldn't read

My first attempt at software was the usual one. I bought a ready-made classifieds script and hired freelancers to customise it. Then more freelancers, when the first ones disappeared or delivered something that half-worked.

The problem wasn't that they were bad people. The problem was that I couldn't judge their work. If you can't read code, a clean, maintainable feature and a duct-taped one look exactly the same: a button that does what it's supposed to do, until the day it doesn't.

That's the trap AI could easily recreate. If I just accept whatever it writes, I'm back where I started, only faster.

The rewrite: fast to build, slow to finish

The clearest example is 24ad.info, the classifieds platform. It started life on a Laravel codebase inherited from freelancers, one I never fully understood. Since February 2026 it runs on a stack rebuilt with Claude Code: React 19 on the front end, Express and tRPC on the back end, MySQL underneath.

I'd like to tell you the rewrite was a heroic all-nighter that fixed everything. It wasn't. The honest version is more useful:

The rewrite itself was fast. Describing what a page or an API should do, and having working code minutes later, really does collapse the time between idea and result.
The polishing took much longer. Edge cases, translations, payments, the small things real users hit. Some gaps and small bugs are still being fixed today.

That second point is the part most "I built X with AI" stories leave out. AI makes the first 80% cheap. The last 20% still needs someone who cares whether it's right.

Describing, not dictating

What changed my results wasn't a better model. It was learning to describe things properly:

What exists now. "Listings are created on a country subdomain, and the currency is set from that country."
What needs to exist. "The price field should be pre-filled, but always editable."
How I'll know it works. "On the Polish subdomain a new listing shows PLN, and changing it by hand sticks."

Vague requests get confident, plausible, wrong answers. Specific ones get code I can actually check.

The verification habit

"Verify" is the part of the rule that does the real work, so it gets its own tools:

Project memory. Every project I work on has a plain-Markdown map of what's done, what failed and what's next, so an AI session starts from facts, not guesses. Something marked verified doesn't get silently redone; something marked failed doesn't get quietly suggested again. I open-sourced it as Project Brain.
Fact-checking my own content. Even the articles on this blog go through a check. When a draft makes a claim about one of my products, a Claude Code instance running on that product's own server checks it against the real code and data before anything is published. That's not hypothetical: it has caught drafts confidently describing features and incidents that never existed. Those got cut.
A human publishes. Nothing ships to a live site, and no article goes out, without me deciding it should.

Where I keep AI on a short leash

Some decisions stay mine, every time:

What to build, and why. AI is excellent at "how". It has no idea what my users actually struggle with on a Tuesday morning.
Anything involving money or customer data. Payments, licences, personal data: these are the places I slow down most and check hardest before anything goes live.
When "technically correct" is still wrong. AI sometimes proposes a solution that works and still feels off: too clever, too heavy, solving a problem I don't have. Learning to say "no, simpler" was one of the most valuable skills I picked up.

What this actually adds up to

AI didn't replace a development team for me. It made it possible to have one at all: a collaborator that writes most of the code, explains it when I ask why, and never gets tired of my questions.

But the responsibility didn't move. If something breaks on 24ad.info at 3am, it's still my name on it. That's exactly why I still make the decisions.

Built by FixFlex Ltd, West London. If you're a non-technical founder wondering whether you can build real products this way: you can. Just don't skip the "verify" part.

Why Kep Runs Entirely on Ollama: The Architecture Behind Local-Only AI for Regulated Industries

slawekluzny — Sat, 03 Oct 2026 09:02:30 +0000

Why Kep Runs Entirely on Ollama: The Architecture Behind Local-Only AI for Regulated Industries

Kep is a private AI assistant for law firms and accountants that runs on a dedicated machine in the client's own office. Every architectural decision behind it follows from one rule: a client install only ever talks to a model running in the room it's sitting in. Here's how that rule shapes the code.

The Core Design Constraint

This isn't a philosophical stance against cloud AI. It's a response to the position regulated firms are in:

They answer to clients, insurers and auditors who increasingly ask one question about any AI tool: where do our documents go?
"To a third-party model provider, under a data-processing agreement" is a defensible answer — but it is still a promise, not an architecture.
Accounting work needs exact figures. "Approximately" isn't an acceptable answer when the numbers end up in a tax return.

So the rule is enforced in code, not in a policy document. In llm/__init__.py:

class CloudBackendNotAllowed(RuntimeError):
    pass


def _effective_provider() -> str:
    provider = settings.llm_provider
    if provider in ("claude", "openrouter") and settings.node_type != "internal_dev":
        raise CloudBackendNotAllowed(
            f"node_type={settings.node_type!r} may not use provider={provider!r}. "
            "Only node_type='internal_dev' may use a cloud LLM backend."
        )
    return provider

The default node_type is kep_node — anything installed at a client. A client machine that is misconfigured to point at a cloud provider doesn't quietly fall back to it; it refuses to start generating.

The one place a cloud model is allowed is an internal instance — which is exactly what our public online demo is. It runs a fictional law firm on a cloud model so anyone can try Kep from a browser, and it says so in a banner on every page. A real Kep never does.

The Hardware Reality

One dedicated machine per client solves three problems at once:

Problem	Cloud Approach	Kep Approach
Data residency	Multi-region deployment, data-processing agreements	Physical hardware inside the client's own office
Audit trail	Logs scattered across providers	A single SQLite file the client can back up themselves
Performance ceiling	Per-seat API quotas	One client = one entire machine's resources

The Ollama-only rule closes two doors: documents can't leak through a provider's SDK, and a model can't change behaviour mid-contract because a provider updated it. New models ship as a signed package installed on-site; the machine verifies the signature before applying it. The only network traffic is a small outbound health-and-licence check — never documents, questions or answers.

How Retrieval Actually Works

Most RAG systems trust the model to decide which documents it should even look at. For legal work that's not good enough: retrieval itself has to be scoped by ownership, before the model ever gets involved.

The query is embedded locally.
sqlite-vec searches only documents the requester owns or has been explicitly given access to (visible_document_ids() in brain/retrieve.py).
Only that already-filtered result set is handed to the model.

The model can't leak a colleague's private document because it never receives it. test_documents.py covers this from the outside — for example, a document one user uploads is invisible to another user unless it's explicitly shared.

Ledger's Dirty Secret

The accounting module deliberately doesn't trust the model with arithmetic. When a document is ingested:

A conservative regex extracts amounts (£1,234.56, GBP 1,234.56, 1,234.56 GBP) with their line items. Anything it can't match with confidence is simply not extracted, rather than guessed.
Amounts are stored as integer pence in their own SQLite table — no floating-point drift.
A chat query gets the semantic RAG results and a deterministic block summed in SQL, scoped by the same ownership rule as everything else:

Computed totals (from 14 structured record(s), computed exactly — not by you):
- Sum: £7,407.36 GBP
- ...

The module's system prompt tells the model to treat that block as authoritative over any figure it reads out of retrieved text.

The Single-Process Bottleneck

Running Flask in production with a single worker sounds unusual until you consider the actual shape of the load: one firm, one machine, not a thousand paralegals hammering it at once. The semaphore that queues LLM generation in api/chat.py is process-local, so it only means something in a single process — which is why the service is configured as gunicorn with --workers 1 --threads N, on purpose. Chat streaming reuses the SSE pattern we'd already proven in Sentinel, which is part of why the stack is Flask rather than FastAPI.

What We Had to Sacrifice

Instant model updates — a signed on-site package means models change on a maintenance schedule, not the moment a new one drops. For a firm that needs the tool to behave the same way next month, that's a feature.
Frontier-level raw capability — local open models are very good, but the biggest cloud models still lead. In our own small test (one sample contract with 12 planted problems) the model Kep runs found 11 and the cloud model we compared it with found 10 — one test, not a benchmark.
Scale illusions — this doesn't scale horizontally by design. Each new client is another machine.
Interface polish — the web UI and the Word/Excel panel are the product for now; a native menu-bar app and voice input aren't built yet.

None of that is an accident. It's the direct cost of the one rule everything else follows.

Kep is built by FixFlex Ltd, London. Read the non-technical story in Why we built an AI that never touches the cloud, or try the online demo — a fictional law firm, no sign-up — at kep.fixflex.co.uk.

Inside BreathTime’s Flagship Petition: A Global Day of Breath, Once a Month

slawekluzny — Thu, 24 Sep 2026 00:12:48 +0000

Inside BreathTime’s Flagship Petition: A Global Day of Breath, Once a Month

This morning, I opened BreathTime’s admin panel to check on the platform’s first major petition: BreathTime – globalny dzień oddechu dla naszej planety (BreathTime — a global day of breath for our planet). It’s an ambitious idea. Once a month, on the second Sunday, pause and let the planet breathe.

At the time of writing, it has 8 signatures. The goal? 1,000. A modest start, sure, but this isn’t just another petition. It’s a test of BreathTime’s core philosophy: cooperation over disruption, grassroots action over top-down regulation.

The Problem

If you’ve followed climate activism over the past decade, you’ll have noticed a growing tension. Governments struggle to implement meaningful policies fast enough. Corporations face pressure to decarbonise but are often accused of greenwashing. And activists? They’re increasingly resorting to disruptive tactics — blocking roads, targeting art, staging dramatic protests — to draw attention to the crisis.

Those tactics work in one sense: they get headlines. But they also polarise. For every supporter they win, they likely alienate someone else. Worse, they often fail to translate visibility into concrete action.

Meanwhile, the clock is ticking.

The Proposal

Enter BreathTime’s flagship petition. It’s not another emissions-trading scheme or complex regulation. It’s a simple, grassroots idea: once a month, pause.

The asks are straightforward:

Pause commercial flights.
Reduce combustion-vehicle traffic (promote public transport and cycling instead).
Reduce industrial production (except in critical sectors) and use the pause for maintenance and modernisation.

But the petition goes beyond just a list of asks. It frames itself as a constructive alternative to disruptive protest.

No blocking roads. No vandalising art. No aggressive demonstrations. Instead, the focus is on organising local educational events, joint environmental actions, and building ecological awareness.

Why Cooperation Over Disruption?

The petition’s positioning is deliberate. It’s not anti-activism. It’s anti-disruption. The idea is to channel activist energy into organising BreathTime-day events and dialogue with authorities and businesses.

For governments, the pitch is pragmatic:

Economically sensible: No new costly infrastructure required. Potential healthcare savings from cleaner air.
Socially acceptable: Shared action instead of new taxes or fines.
Politically low-risk: No protests against new taxes. Positive image from supporting a grassroots initiative.
Easy to implement: Simple rules that can scale gradually.

For businesses, the argument is equally practical. A global day of breath isn’t about shutting down industries permanently. It’s about using the pause for maintenance and modernisation — a chance to prepare for a greener future without the pressure of daily production.

For individuals, it’s an opportunity to participate in something concrete and community-driven. Sign the petition. Share the idea. Get involved locally. Become an ambassador.

The Platform

BreathTime, the platform, is an early-stage product. Version 0.2.2, to be exact. It’s not a social media site or a general news platform. It’s a place for civic petitions and social initiatives — a space where ideas like the global day of breath can take root.

Technically, it’s built on Next.js 16 (App Router) with TypeScript. The homepage features a Three.js-animated 3D globe: yellow dots represent registered users by IP geolocation, green shows the current logged-in user, and red marks guests. The UI supports 52 languages, with interface strings AI-translated via OpenRouter/GPT-4o mini — that translation layer covers labels and buttons only, not blog post content.

There’s also an e-book library (PDF/EPUB/MOBI), in-app notifications, a user dashboard, and admin panels for managing users, petitions, proposals, e-books, and languages.

Hosting-wise, it runs on a separate VPS from ArticlePilot itself, with PM2 cluster (2 processes, port 3006), Caddy reverse proxy, and auto SSL.

The Challenges

Of course, the petition isn’t perfect. Some will argue that once a month isn’t enough. Others will point out the logistical challenges of pausing commercial flights or reducing industrial production.

But that’s the beauty of BreathTime’s approach. It’s a starting point, not a final solution. The goal isn’t to solve climate change overnight. It’s to create a framework for collective action — a structure where individuals, businesses, and governments can work together towards a shared goal.

The Future

As of today, the petition has 8 signatures. The road to 1,000 will be long. But every signature is a vote for cooperation over disruption, for dialogue over confrontation.

If you’re reading this, I encourage you to sign the petition. Share it with friends. Organise an event in your community. Become an ambassador.

The global day of breath might not solve climate change. But it’s a step in the right direction — and a reminder that sometimes, the simplest ideas can have the biggest impact.

BreathTime is an early-stage platform for civic petitions and social initiatives.

Building a Multilingual AI-Powered Classifieds Platform

slawekluzny — Sat, 15 Aug 2026 23:26:04 +0000

Building a Multilingual AI-Powered Classifieds Platform

This morning, I woke up to a notification from 24ad.info about a bug in the payments flow. It reminded me of the journey this platform has taken since its inception — from a simple idea to a fully-fledged AI-powered classifieds system. Let’s dive into the technical details and lessons learned along the way.

The Problem: Making Classifieds Effortless

Classifieds platforms have been around forever, but they’re often clunky. Users spend forever writing descriptions, picking categories, and setting prices. What if we could automate all of that? That’s the core idea behind 24ad.info: upload a photo, and let AI handle the rest.

The Tech Stack

Here’s what powers 24ad.info:

Frontend: React 19 with Vite for blazing-fast builds, Tailwind CSS for utility-first styling, and shadcn/ui for polished components. Routing is handled by wouter, and tRPC v11 manages the API communication.
Backend: Node.js with Express for the server, tRPC v11 for type-safe API endpoints, and Drizzle ORM for database interactions.
Database: MySQL, hosted on managed internal infrastructure (exact host name withheld), handles everything from user data to post metadata.
AI: OpenRouter provides access to models like Google Gemini 2.5 Flash for vision tasks and Gemini 2.0 Flash for text tasks (translations, graphics prompts).
Auth: Google OAuth and email/password authentication (JWT-based) keep things secure.
Payments: Stripe handles checkout and webhooks for premium listings and packages.
Web Server: Caddy v2 manages wildcard subdomains, HSTS, and compression (zstd+gzip).

The AI Features

The AI-powered features are the heart of 24ad.info:

Photo Analysis: Upload a photo, and OpenRouter’s Google Gemini 2.5 Flash model analyzes it to recognize the item, assess its condition, and suggest a price. This is the first step in automating the listing process.
Category Classification: The AI matches the item to the most relevant category. If the category is inactive, it reactivates it instead of creating a duplicate — keeping the catalog clean.
Description Generation: SEO-optimized descriptions are generated automatically, saving users time and improving search visibility.
Smart Pricing: Based on market data and the photo analysis, the AI suggests a competitive price.
Package Translation: For listings that span multiple countries, the AI translates the title and description.

These features collectively automate the listing process.

The Payment Bug

One of the more embarrassing bugs we encountered was in the payments flow. After a successful Stripe payment, the promotion or package wasn’t being applied to the post. The verifyCheckoutSession endpoint marked the payment as completed but never called applyPackageToPost. This meant users paid for premium features but didn’t get them.

The fix, shipped in v1.4.4 on 2026-05-20, was straightforward: we added the applyPackageToPost step to the checkout verification flow. We also added an admin bypass to manually activate packages for testing purposes. Lesson learned: always test edge cases thoroughly, especially when money is involved.

Search and Location

Searching for listings is a core feature of any classifieds platform. Here’s how we handle it:

Keyword Search: Full-text search across titles and descriptions.
Category Filters: Narrow results by category and custom fields.
Price Range: Filter by minimum and maximum price.
Location: Search by city or postcode, with a radius slider (1-100 km) for nearby listings.

The location search is powered by a single-pass SQL query that resolves city names or postcodes to city IDs. A separate radius-search procedure finds nearby cities by distance. There’s no multi-step funnel or full-text fallback — keeping the search fast and efficient.

Image Optimization

All image uploads are converted to WebP on the fly using sharp (quality 82, effort 4). This reduces file sizes significantly. The v1.4.2 update batch-converted existing images to WebP, ensuring consistency across the platform.

Infrastructure and Scaling

Caddy v2 handles the web server duties, including wildcard subdomains, HSTS, and compression. The encode zstd gzip directive ensures all responses are compressed, regardless of file type or size.

Behind the scenes, PM2 manages four Node.js instances for load balancing. The /api/system-health endpoint checks five items (globe_js, uploads_dir, env_forge_url, env_forge_key, database); the earlier eight-point description existed only in v1.4.1 changelog notes before the implementation was simplified.

The API Architecture

The backend is built around a single unified tRPC API composed of 24 domain routers (posts, admin, payments, search, AI, etc.). The admin dashboard primarily interacts with the dedicated admin router, ensuring separation of concerns and easier maintenance.

Version 1.4.4: Streamlining Post Creation

The latest update (v1.4.4, shipped 2026-05-20) streamlined the post-creation process:

Country Selector Removed: The country is now auto-detected from the subdomain (e.g., pl.24ad.info → Poland).
Currency Auto-Selection: The currency is auto-selected from the subdomain on form load.
Category Filters: Labels and options are now translated using values from the database’s translations field.

While basic currency auto-detection existed since v1.1-1.2, this update made it fully subdomain-driven.

Lessons Learned

Building 24ad.info has been a journey filled with technical challenges and valuable lessons:

Test Payment Flows Thoroughly: Small oversights can lead to significant issues when money is involved.
AI is a Double-Edged Sword: While AI automates many tasks, it requires careful tuning and monitoring to ensure accuracy.
Compression Matters: Converting all images to WebP improved performance without requiring complex configurations.
Architecture is Key: A well-structured API architecture (like tRPC’s domain routers) simplifies maintenance and scalability.

What’s Next?

We’re constantly iterating on 24ad.info, with plans to improve the AI models, expand language support, and enhance the user experience. If you’re interested in following our journey, check out the live site at https://24ad.info.

Building in public isn’t always glamorous — bugs happen, features fail — but the transparency and community feedback make it all worthwhile. Here’s to the next chapter in the 24ad.info story.

Why Your Database Needs an Autopilot (And How to Install One in 60 Seconds)

slawekluzny — Sat, 15 Aug 2026 23:22:35 +0000

Why Your Database Needs an Autopilot (And How to Install One)

Sentinel AI was born from the frustration of manually firefighting problems that could be prevented. Here's how it works under the hood.

The Silent Killers of Database Performance

Every production server can suffer from performance issues. Traditional monitoring tools alert you after these problems cause pain. Sentinel takes a different approach.

How the Autopilot Works

Sentinel can automatically detect issues, analyze affected queries, create missing indexes, and log the action with before/after plans. All without waking anyone up. Here's the technical breakdown:

The Analysis Engine

Slow Query Mining

Parses slow query logs and uses real EXPLAIN plans.
Pathology Detection

Flags relevant query patterns and resource issues.
Safety Checks

Before any automatic index creation, relevant system conditions are verified.

The Security Layer

While optimizing databases, Sentinel also handles:

Automated IP blocking via Fail2Ban and CrowdSec integration
Attack correlation across server fleets (Enterprise tier)
SSL expiry monitoring with proper TLS handshake checks

Installation

Installation typically takes 2-4 minutes (venv setup + pip dependencies). For Linux-based operating systems:

curl -sSL https://sentinel-ai.info/install.sh | sudo bash

This installs Sentinel and starts the web UI.

The Pro tier starts from $49/month for up to 5 servers and unlocks automated index creation and cross-server security sync. Enterprise costs $149/month for up to 10 servers and adds the AI Chat interface and Cross-Fleet IP Reputation.

What to Expect After Deployment

Performance metrics are established and slow queries are analyzed. Automatic optimizations are applied and security patterns are identified. Optimization history becomes visible in the dashboard.

The Unfair Advantage

Servers running Sentinel see recurring issues addressed proactively.

Try the free Basic tier for 1 production server on one production server - no credit card required. It might just change how you think about server management.

How 24ad.info's AI Classifieds Actually Works Under the Hood

slawekluzny — Sat, 15 Aug 2026 23:19:45 +0000

How 24ad.info's AI Classifieds Actually Works Under the Hood

This morning I woke up to a support ticket that read: "Your AI suggested I sell my sofa for £3.50 – is this a bug or are you running a charity?" Fair question. Let's peel back the layers on how 24ad.info's AI-powered classifieds actually functions when you upload that photo of your old iPhone.

The Vision Pipeline: From Pixels to Price

When you drag-and-drop an image onto our post creation form, here's what happens before the form auto-fills:

Image Analysis: We pipe your image through OpenRouter's Gemini 2.5 Flash (not the 2.0 version mentioned in some docs – that's text-only). This gives us:
- Object identification ("iPhone 12, 64GB, good condition")
- Context clues (a phone on a desk suggests "for sale", while one in a repair shop suggests "services offered")
- Visible wear/defects (scratches, cracked screen)
Market Positioning: The AI cross-references the identified item with:
- Recent similar listings in your country
- Age-based depreciation curves
- Local demand signals (search volume for "iPhone 12" in your region)
Price Suggestion: This is where the £3.50 sofa incident occurred. The system:
- Takes the median price of comparable items
- Applies a nudge discount to encourage faster sales
- Caps absurd outliers (hence why you'll never see £0.01 suggestions)

// Simplified price suggestion logic (from server/routers/ai.ts)
const suggestPrice = (item: DetectedItem, country: string) => {
  const comparables = await findSimilarListings(item, country);
  const medianPrice = calculateMedian(comparables);
  return applyPsychologicalPricing(
    medianPrice * 0.85, // Encourages pricing slightly under market
    country
  );
};

The key lesson? Always review the AI's work – it's optimized for quick listing, not perfect pricing.

The Payment Bug That Cost Us Refunds

In our Stripe integration, we hit a textbook "assumption failure":

The Flow:
- User pays for a "Premium" listing package
- Stripe Checkout completes
- Our verifyCheckoutSession marks payment as complete... and stopped there
The Missing Step:

   // Pre-fix logic (simplified)
   const handlePaymentSuccess = async (sessionId) => {
     await markPaymentCompleted(sessionId); 
     // applyPackageToPost() WASN'T CALLED HERE
   };

The Fallout:
- Users paid for features they didn't receive
- Our support inbox exploded with "Where's my premium badge?"
- Manual refunds + package activations took developer time to resolve

The fix shipped in v1.4.4 was embarrassingly simple – a single function call added to the verification flow. Now we have end-to-end tests mocking this exact scenario.

Location Search: One SQL Query to Rule Them All

Unlike platforms that layer full-text search with post-filtering, our location handling is brutally simple:

// Location search (from server/db-search.ts)
const posts = await getPostsNearbyAdvanced(...); // bounding-box + Haversine in JS

Key decisions:

No Fuzzy Location: You're either searching in "London" or within a radius of a point – no magic "near me" expansion
Single-Pass Query: Avoids the common pitfall of:
- First find matching text
- Then filter by location
- Then re-sort by relevance
Postcode Exactitude: UK postcodes (e.g., "SW1A 1AA") resolve to precision via an exact-match lookup against an indexed varchar(20) postcode column on the cities table

The Deployment Script That Saved Our Translations

Early on, we nuked all German/French translations during a routine deploy. The culprit?

rsync --delete ./dist /var/www/24ad.info/  # DELETED locales/ folder

Now, deploy_prod.sh enforces:

rsync --exclude "locales" ...

And we have a pre-deploy checklist:

Verify enabled-languages.json exists on server
Confirm no --delete flag without --exclude
Test on dev.24ad.info first

Why tRPC's Router Composition Matters

Our API structure avoids the "mega-router" anti-pattern:

// How we compose routers (server/routers/index.ts)
const appRouter = createTRPCRouter({
  admin: adminRouter,       // Dashboard ops
  posts: postsRouter,       // CRUD operations
  ai: aiRouter,             // Vision/translation
  payments: paymentsRouter, // Stripe flows
  search: searchRouter,     // Location-aware
  // ...19 more
});

// Client-side usage remains clean:
const { data } = trpc.posts.getById.useQuery({ id });

This gives us:

Clear boundaries (admin routes never mix with public ones)
Separate middleware stacks
Easier code splitting if needed later

What's Next

The current roadmap includes:

AI-generated listing quality scores
Automated repricing suggestions for stale posts
Bulk image analysis for multi-photo uploads

But for now, the system works – even if it occasionally thinks your designer sofa belongs at a car boot sale.

[Edit: The £3.50 sofa was actually a cushion. The user cropped the image poorly. Lesson learned – we now detect item scale better.]

How We Fixed the Silent Payment Bug That Cost Us Real Money

slawekluzny — Sun, 19 Jul 2026 22:47:33 +0000

How We Fixed the Silent Payment Bug That Cost Us Real Money

This morning I was reviewing Stripe logs when I noticed something odd—successfully paid "Premium Listing" purchases where the posts never actually got premium status. Our users were paying, but the promised visibility boost wasn't happening. Oops.

The Bug That Lived in Production for Approximately 13-19 Days

The issue was straightforward, yet nasty:

User pays for a premium listing package via Stripe Checkout
Client-side completes the payment flow
Backend marks payment as completed in our database
Critical step missing: The actual package benefits (featuredUntil/highlightedUntil timestamps) never got applied to the post

We discovered this when a user emailed saying "I paid £4.99 but my post looks the same."

The Anatomy of the Failure

Our payment flow had two parallel paths:

Admin Bypass Path (Working)

// Working admin flow
await markPaymentCompleted(paymentId);
await applyPackageToPost(postId, packageType); // ✅

Stripe Checkout Path (Broken)

// Broken production flow until v1.4.4
await markPaymentCompleted(paymentId); // ❌ Stopped here
// applyPackageToPost() was never called

The missing line was a classic copy-paste omission—we'd abstracted the package application logic but forgot to call it in the Stripe verification path.

The Fix (v1.4.4)

We patched it with surgical precision:

Added applyPackageToPost() to the checkout verification flow
Made the admin bypass use the same unified function
Added transaction wrapping to ensure atomic updates

// Fixed in v1.4.4
const verified = await verifyCheckoutSession(sessionId);
if (verified) {
  await db.transaction(async (tx) => {
    await markPaymentCompleted(paymentId, tx);
    await applyPackageToPost(postId, packageType, tx); // ✅ Now called
  });
}

Key details:

Uses Drizzle ORM transactions
Same function handles both Stripe and admin flows
Logs package application separately for auditing

Why This Hurt More Than Typical Bugs

Silent failure - No errors in logs, payments showed as "completed"
Delayed detection - Users assumed premium features were subtle
Reputation risk - Paying customers weren't getting what they paid for

Lessons Learned

Payment flows need dual verification

We now:
- Log package application separately from payment completion
- Have a nightly job checking for paid-but-unapplied packages
Transactional boundaries matter

The fix wrapped everything in a DB transaction—no more partial updates.
Admin tools should use the same paths as users

The admin bypass worked because it called the full flow. The Stripe path didn't.
Monitor what you monetize

We added Stripe webhook logging and dashboard monitoring for:
- Payments completed vs packages applied (tracked via checkout session IDs)
- Time delta between payment and feature activation (logged in checkout verification flow)

The Stack That Caught It

Our monitoring eventually flagged the issue through user reports and internal checks.

The Stripe webhook handler is a stub. Package activation happens in the verify-checkout-session flow.

Current Architecture (Post-Fix)

graph TD
    A[Stripe Checkout] -->|Session ID| B(verifyCheckoutSession)
    B --> C{Valid?}
    C -->|Yes| D[markPaymentCompleted]
    D --> E[applyPackageToPost]
    E --> F[Update post.featuredUntil]
    C -->|No| G[Log failed verification]
    H[Admin Bypass] --> E

Key improvements:

Single code path for both flows
Transactional integrity
Audit logging at each step

If We Had to Do It Again

We'd:

Write the failing test first - No test covered the post-payment state
Monitor payment-to-feature latency - Would've caught it within hours
Add feature toggle checks - Verify premium posts actually appear differently

The fix shipped in v1.4.4. Since then, zero reported issues—and our premium purchase conversion rate increased. Turns out people buy more when the features actually work. Who knew?

The Memory Problem Nobody Talks About in AI Coding Assistants

slawekluzny — Thu, 09 Jul 2026 20:19:35 +0000

The Memory Problem Nobody Talks About in AI Coding Assistants

This morning, I watched Claude Code confidently propose a FastAPI solution for a Node.js project. Again. It's not Claude's fault - it's working exactly as designed, with the memory span of a goldfish between sessions. Here's what's really happening under the hood.

The Context Amnesia Problem

Every new session with an AI coding assistant follows the same painful pattern:

You paste your architecture diagram (again)
You explain your stack choices (again)
You recap yesterday's progress (again)
You re-explain why that caching approach failed (again)

The brutal truth? These tools have no persistent memory. That "session memory" feature? It's just a transcript summary that degrades over time. By the next session, your carefully explained architecture becomes "the system uses some backend components."

Why This Isn't Just a Token Problem

Most discussions focus on context window sizes, but that misses the real issue:

Multi-project contamination: Your FastAPI project's details leak into your Node.js work
Version drift: Yesterday's "working solution" becomes today's "maybe we should try..."
Decision amnesia: Rejected approaches resurface like bad pennies

How Project Memory Actually Works (When It Works)

The working solution isn't revolutionary - it's boringly simple:

A structured knowledge map: Not a blob of text, but a navigable hierarchy
Status tracking: ✓ verified vs ✗ failed vs ⚠ in-progress
Decision logging: Why we chose X and rejected Y
Delta loading: Only what changed since last time

The magic happens in the mundane details:

.project-brain/
  index.md          # The map
  projects/
    api/
      caching.md    # ✓ verified
      auth.md       # ⚠ WIP
  _decisions.md     # > Chose FastAPI over Flask because...

What This Fixes That Session Memory Can't

Cross-project isolation: No more Node.js suggestions in your Python repo
Version awareness: The AI knows when something was superseded
Trust signaling: Human-verified vs AI-inferred markers
Staleness detection: Review topics past their review date before using

The validator catches subtle but critical errors:

Conflicting tech claims (Redis vs Memcached in same project)
Stale credentials
Misfiled project details

The Real Workflow Difference

Before:

# User: "Add rate limiting"
# AI: "Let's use Redis!" 
# (despite Postgres being the documented choice)

After:

# AI: "Project specifies Postgres - using pg_cron 
# as implemented in caching.md (✓ verified)"

That's the difference between an assistant that fights your system and one that works with it.

Implementation Truths

Zero runtime dependencies: Just Python 3's stdlib
Plain Markdown: No proprietary formats
Git-friendly: The entire brain is diffable
Tool-agnostic: Works with any file-reading agent

The install is deliberately boring:

git clone https://github.com/OoneBreath/claude-code-project-brain.git
cd claude-code-project-brain
./install.sh

Why This Isn't Just Another Note-Taking System

The key differentiators:

Agent-first design: Structured for programmatic consumption
Status primitives: Not just notes - verified decisions
Conflict detection: Hard tech incompatibility checks
Tiered loading: Recent projects HOT, older ones COLD

It's the difference between a notebook and an aircraft maintenance log.

The Unsexy Truth About AI Assistants

The biggest productivity gains don't come from fancier models - they come from fixing the mundane plumbing issues like persistent context. Project Brain isn't glamorous, but it solves the actual problem developers face daily: stopping the endless re-explanation cycle and finally getting back to coding.

277,000 Attacks Blocked — Here's What the Data Shows

slawekluzny — Fri, 19 Jun 2026 10:12:14 +0000

303,970 Attacks Blocked — Here's What the Data Shows

Category: Threat Intelligence

Tags: threat intelligence, fail2ban, attack data, VPS security

This morning, Sentinel's audit dashboard ticked over to 303,970 total blocked attacks (single server lifetime counter).

That's not a crisis. That's Tuesday.

If your Linux VPS is exposed to the internet, this is baseline background radiation. The question isn't whether you're being attacked — you are. The question is whether you can see it happening.

The Raw Numbers

303,970 total attacks blocked
5 primary origin countries
99.2% block success rate
7,002 peak single day
~450 average daily per server

These aren't alarm-bell numbers. They're normal. Here's what they actually mean.

Where Attacks Come From

The geographic breakdown was predictable but revealing:

China (42%) – Bulk SSH brute-force attempts, mostly automated scripts hammering port 22.
Russia (31%) – Similar pattern, but with more variation in target ports (MySQL, Redis, and HTTP admin panels).
United States (12%) – Almost entirely commercial VPN exit nodes and hosting providers. Attackers renting "clean" infrastructure to bypass IP reputation filters.
Germany (9%) – Same as US, plus a surprising number of compromised IoT devices.
Netherlands (6%) – Overwhelmingly Tor exit nodes and rented datacenter IPs.

The key insight? Shared blocklists are reactive, not proactive. By the time an IP shows up in CrowdSec or Fail2Ban community lists, attackers have already cycled to fresh infrastructure.

The Daily Attack Pattern

Sentinel's hourly logs show two clear attack windows:

02:00–05:00 UTC – Peak automated scanning. When your sysadmin is asleep.
14:00–17:00 UTC – Correlates with Southeast Asian business hours (likely cron jobs).

If your SSH keys aren’t locked down or your Fail2Ban settings are too lenient, the problem surfaces at 3am — not during your working hours.

The 0.8% That Got Through

Of the ~2,200 attempts that bypassed perimeter defenses:

78% hit application-layer rate limits (e.g., WordPress login throttling)
21% reached login forms but failed authentication
0.1% (3 incidents) triggered high-severity alerts — all caught by Sentinel’s real-time monitoring

The audit trail showed exactly why these slipped through:

Overly generous maxretry settings (e.g., allowing 10 attempts before banning)
IP rotation within a subnet (avoiding single-IP thresholds until we added CIDR blocks)

What This Means for Your Server

Blocking 303,970 attacks is table stakes. The real value is visibility:

Know which 303,970
Know from where
Know when and how

Without this data, you’re either:

Flying blind (assuming "no alerts = no attacks"), or
Overreacting (e.g., banning entire countries unnecessarily)

Sentinel’s Audit dashboard surfaces this in real time. You’ll see:

Emerging attack patterns before they escalate
Whether your defenses are properly tuned
A clean audit trail for clients or compliance

How Sentinel Handles It

Here’s what happens under the hood when an attack hits a Sentinel-monitored server:

Real-time detection – Fail2Ban + CrowdSec + custom rules.
Automatic subnet blocking – If an IP from /24 is malicious, the whole range gets banned.
Cross-fleet sync – Blocked IPs are shared with other Sentinel servers via Queen.
AI analysis – Claude AI reviews logs to suggest tighter rules.

Try It Yourself

Basic tier: Free for 1 server (install in 60 seconds)
Pro tier: $49/month for 5 servers (adds automated DB optimizations)
Enterprise: $149/month for 10 servers (AI Chat, fleet-wide threat intel)

This isn’t about fearmongering. It’s about acknowledging reality — and having the tools to handle it.

Footnotes:

Data source: Sentinel Audit dashboard, live production servers
Last updated: June 2026
servers monitored: 3 production servers
OS breakdown: 100% Ubuntu 24.04 across all 3 servers (no Debian/RHEL)
Full dataset available to Enterprise users via Queen API

Why I Built a Self-Healing Server Agent (And Why It's Not Magic)

slawekluzny — Fri, 19 Jun 2026 10:07:28 +0000

Why I Built a Self-Healing Server Agent (And Why It's Not Magic)

Sentinel can detect and contain suspicious activity while surfacing database performance issues without requiring human intervention.

This is what happens when you stop treating servers like pets and start treating them like cattle with PhDs.

The Problem That Started It All

The post-mortem on recurring production issues revealed two uncomfortable truths:

Monitoring tools lie by omission - They'll happily show you green status lights while your database quietly suffocates from unoptimized queries
Alert fatigue is real - When everything is "urgent", nothing is

Traditional monitoring gives you dashboards. What you actually need is a system that:

Understands normal behavior for YOUR stack
Can distinguish between "interesting" and "critical"
Takes safe actions without human hand-holding

How Sentinel Actually Works (Without the Hype)

The Monitoring Layer That Doesn't Sleep

Sentinel's monitoring isn't revolutionary—it's just thorough where others aren't:

Process watching via direct systemd integration (not just PID checks)
SSL monitoring that actually performs TLS handshakes (not just date checks)
Database analysis that reads slow logs AND EXPLAIN plans
Attack detection correlating Fail2Ban, CrowdSec and UFW

When it detects failed SSH attempts from an IP, it blocks that IP at the firewall level.

The Database Autopilot That Earns Its Keep

Here's what our MySQL optimization pipeline looks like today:

Slow query analysis - Identifies queries taking above a configurable threshold
EXPLAIN plan review - Flags full table scans, temp tables, bad joins
Index suggestion - Proposes specific multi-column indexes with expected impact
Safe application - Automatically creates indexes marked high confidence

The Security Model That Fights Back

Most security tools are museum curators—they catalog attacks after they happen. Sentinel operates more like a bouncer with photographic memory:

IP reputation sharing - Banned IPs sync to our central "Queen" server
Behavioral blocking - Detects probing patterns before full attacks launch
Automatic containment - Isolates compromised services without killing entire boxes

The Architecture Choices That Made It Possible

Why Python + Flask Instead of Go

We get asked this constantly. For a monitoring tool, Go seems obvious—but we chose Python because:

SQLAlchemy gives us ORM flexibility across SQLite (state) and monitored DBs
APScheduler handles background jobs without k8s complexity
Prototyping speed mattered more than raw performance initially

The Queen-Sentinel Protocol

Every Sentinel node phones home to Queen with:

Aggregated metrics (never raw logs)
New security signatures
Anonymized query patterns

Queen responds with:

Updated threat intelligence
Cross-fleet performance recommendations
Safe action approvals (for Enterprise tier)

This keeps bandwidth minimal while enabling fleet-wide learning.

Pricing That Doesn't Require an MBA to Understand

Tier	Servers	Price/Mo	Key Features
Basic	1	Free	Monitoring, security alerts
Pro	5	$49	DB autopilot, email alerts
Enterprise	10	$149	AI chat, cross-server IP blocking

The economics are simple:

Pro pays for itself if it prevents engineer time
Enterprise makes sense when managing multiple production workloads

Installation

Enter your email at sentinel-ai.info to receive the Queen-vault installer. This:

Creates /opt/sentinel with isolated Python env
Sets up systemd services
Installs Fail2Ban filters (if missing)
Surfaces the admin-UI access URL

No Docker. No k8s manifests. Just a binary watchdog that works.

The Road Ahead

PostgreSQL query analysis is now generally available. The philosophy remains unchanged: your servers should defend, heal and optimize themselves. Because at 3 AM, you'd rather be sleeping than debugging PHP-FPM.

Try Sentinel free on one server—no credit card required. The worst that can happen is you'll stop getting paged for problems that fix themselves.