Pinned Post

OpenSpec UI: ein Live-Dashboard für deine Specs

Bild
OpenSpec UI: ein Live-Dashboard für deine Specs Wer mit einem KI-Agenten und OpenSpec arbeitet, kennt das Bild. Im Projekt wächst ein Verzeichnis openspec/ heran: Changes mit proposal.md , design.md , tasks.md und ihren Delta-Specs, daneben die kanonischen Specs der einzelnen Capabilities. Die Absicht hinter dem Code steht damit endlich geschrieben, statt sich in ihm zu verstecken. Nur verteilt sie sich über Dutzende Markdown-Dateien, und der Editor zeigt eben Dateien. Was er nicht zeigt, ist der Zustand. Woran arbeitet der Agent gerade? Welcher Task ist der nächste offene? Und was hat sich verändert, während ich zehn Minuten woanders hingeschaut habe? Genau diese Lücke füllt OpenSpec UI , ein kleines Phoenix-LiveView-Dashboard, das lokal neben deinem Projekt läuft und den OpenSpec-Workspace im Browser zeigt — live, während gearbeitet wird. Der Code liegt offen auf GitLab: https://gitlab.com/public_elixir/openspec_ui Ein Blick statt Datei-Hopping Du startest den Server, gibst d...
Kommentar veröffentlichen

Kommentare

Kommentar veröffentlichen

Beliebte Posts aus diesem Blog

Splitting an ML model and a web app across two BEAM nodes — the technical blueprint

Bild
The web app (Phoenix + Postgres) runs in production on a small Linux box with no GPU. The embedding model ( intfloat/multilingual-e5-base , ~278 MB, XLM-RoBERTa backbone, EXLA-compiled) wants compute that isn't there. That compute lives in a MacBook Pro. Goal: offload only the heavy inference to the Mac, keep everything else on the server — and the calling code shouldn't know where the math happens. The usual answer would be a second service with a gRPC/REST API, serialization, service discovery, timeouts, retries, and a second deployment artifact. On the BEAM, "another machine" is a platform primitive instead. What it takes isn't new infrastructure, but a clean split of one codebase into two releases and three node roles. The mental model: one codebase, two releases, three roles There is exactly one codebase (an umbrella project) and no second language. The only thing that varies is what a started node brings up . A single environment variable, FINANCE_ROLE ,...
Read more »

Jido in Practice: Agents in Elixir as Composable Actions

Bild
At Fiatbitcoin, around two dozen small agents run in the background. They fetch prices, read the mempool, score news, compute tax deadlines, send alerts. In the beginning these were all just GenServers and Oban jobs, each built a little differently. That works, but it gets messy fast: every job has its own input and output, its own way of reporting errors, its own idea of what “done” means. Jido is a framework for exactly this kind of work. It hands you a small set of clearly defined building blocks that let you assemble agents from small, testable units. I use it in version 2.1. This article is a tour through real code from the project, and the question behind it stays the same throughout: where does Jido pull its weight, and where does it not. If you don’t write Elixir, a few words up front. A module is a collection of functions. {:ok, value} and {:error, reason} are the usual way to return success or failure, a tagged pair. A GenServer is a lightweight, long-lived process wit...
Read more »

A Foundation Model in the BEAM: On-Chain Anomalies with Google TimesFM in Elixir

Bild
At Fiatbitcoin a worker collects metrics from our own Bitcoin node every ten minutes: mempool size, number of waiting transactions, fee rates, hashrate, difficulty. Over time that builds a decent time series, one row per measurement in a table. At some point the obvious question comes up: when is one of these values actually unusual? When is a note or a push worth it, and when is it simply Tuesday evening? The cheap answer is a fixed threshold. Mempool above 200,000 transactions, alarm. The problem with that shows after a week: the mempool breathes in a daily and weekly rhythm. Sunday evening is reliably fuller than Tuesday morning, fees pick up at certain times. A flat threshold flags every predictable peak as an anomaly and stays silent on an untypical spike that happens to stay under the line. What you actually want is a band that knows the normal rhythm, and an alarm only when a value breaks out of that band. First the simple way The honest entry point into something like thi...
Read more »