DEV Community: Michal Žídek

AgentWave: policy-validated assistant suggestions for Go backends

Michal Žídek — Sun, 11 Oct 2026 20:37:05 +0000

I maintain AgentWave, an MIT-licensed Go project for adding an assistant to admin panels, CRMs, dashboards, and internal tools.

The interface is small: send a request and the current screen route, then receive one action suggestion that passes a configured policy. Your application decides whether to show or apply it.

The request flow

Your application's backend sends a request over a private Unix socket.
AgentWave creates a job and asks its Codex CLI backend for a suggestion.
The result must match the policy. A result outside the policy becomes a failed job.
Your backend retrieves the result. Any action still goes through your application's permission checks.

A browser cannot connect to the Unix socket directly. Your backend acts as the proxy and supplies the actor ID from its own user or session context.

A small policy example

This example comes from the repository's README:

{
  "actions": ["help", "navigate", "lookup"],
  "modules": ["none", "home", "contacts", "deals", "reports"],
  "routePrefix": "/admin",
  "queryActions": {
    "lookup": "contacts"
  }
}

For example, an admin panel can ask where to find a contact from /admin/contacts. The assistant can return a lookup suggestion. The host application decides how to handle it.

The HTTP interface has three routes: GET /healthz, POST /jobs, and GET /job. Job submission returns a working status; the client polls until the job is ready or failed.

What you need

The Go module has no external dependencies. The generation backend requires the Codex CLI, configured model access, and any authentication that access requires. The MIT license covers AgentWave's code; it does not provide free model access.

The repository includes local setup instructions, Docker and Compose examples, and a backend proxy example. Policy validation is one layer of the integration; keep authentication and authorization in your application.

Source code and setup instructions

Feedback on the policy format, job API, and integration examples is welcome. My other Go project, NSFW Sherlock, provides a self-hosted image moderation API.

Prepared with AI assistance from the project's public documentation.

NSFW Sherlock: a self-hosted image moderation API in Go

Michal Žídek — Sun, 11 Oct 2026 19:16:35 +0000

I maintain NSFW Sherlock, an open-source image moderation API written in Go. It uses ONNX Runtime and offers HTTP and gRPC interfaces.

You send an image to your own instance and get structured classification results. The service classifies photos and anime, detects explicit regions, and can use Tesseract OCR to check text in images.

Try the CPU Docker image

docker run -e APP_ENV=web -p 127.0.0.1:4000:4000 m1chl/nsfw-sherlock
curl http://localhost:4000/ping

The image includes the models and OCR support, with Linux amd64 and arm64 builds. Binding the port to 127.0.0.1 keeps this first test local to your machine.

Image requests use JSON:

{"base64":"<base64-encoded image>","filename":"image.jpg"}

Endpoint	Result
`POST /pic/check`	Image and text flags
`POST /pic/labels`	Classification probabilities
`POST /pic/analyze`	Verdict, model scores, detected regions, and timing

For gRPC, start with APP_ENV=grpc. The protobuf definition describes its methods.

Profiles and limits

The balanced profile is the default. fast uses lighter models for part of the pipeline, while max uses a larger region detector. compat keeps the legacy five-label classifier. The README lists the exact models and settings.

The current backend is ONNX Runtime; older references to TensorFlow do not describe the current engine.

Classification is probabilistic. Scores and model details help applications make their own decisions; they do not guarantee every image will be classified correctly.

NVIDIA CUDA and AMD MIGraphX configuration are documented, but GPU inference has not yet been verified on physical NVIDIA or AMD hardware. The CPU container is the starting point shown here.

The code is AGPL-3.0. Upstream model licenses remain separate.

Source, setup, and API documentation · Docker image

I'd welcome feedback on API integration and which response format is useful in your application. Please do not put private images in public issues.

Prepared with AI assistance from the project's public documentation.

Rust-a-Log: filter recent errors in a large log, then keep watching

Michal Žídek — Sun, 11 Oct 2026 19:14:19 +0000

I maintain Rust-a-Log, a small command-line log viewer written in Rust. It reads recent records, filters them, and follows new writes.

The useful detail is where the line count applies. If you ask for the last 20 errors or warnings, it finds 20 matching records, rather than taking the last 20 lines and discarding everything else.

Try the current source

With Rust installed:

cargo install --git https://github.com/M1chlCZ/Rust-a-Log --locked
rual app.log -e -w -n 20

This shows the last 20 errors or warnings and follows new records. Press Ctrl+C to stop.

For a one-time search:

rual app.log -g timeout --ignore-case --once

You can combine the two:

rual app.log -e -g database -n 5 --once

This prints the last five error records that also contain database. The text filter is literal, not a regular expression.

Why scan backwards?

When you only need recent records, reading the entire file first does unnecessary work. Rust-a-Log scans backwards in 64 KiB blocks until it finds enough matching records. Its memory use depends on the longest record and a small buffer, rather than the total file size.

A rare filter can still require scanning the whole file. There is no search index or cache.

A few limits to know

Input must be a regular, seekable text file. Stdin, compressed logs, and multiline event grouping are not supported.
Level filters recognise bracketed labels such as [ERROR], [WARN], and [INFO].
Linux and macOS can reopen a renamed or replaced log. On Windows, rename rotation requires restarting the viewer.
Following uses polling, so a file that is truncated and regrown between checks can lose records.

The README covers the full behaviour and includes an example screenshot. The project is free and MIT-licensed.

I'd welcome feedback on the log formats you use and which filtering or rotation cases are awkward with your current tools. Reproducible examples are especially useful.

This post was prepared with AI assistance from the project's public documentation.