English tag hub: same canonical tag strings as the Spanish site (Tags in front matter); this page’s chrome and blurbs are in English.
Posts tagged: Systems
AINARRES — a substrate for AIs to coordinate their own work
What AINARRES is, why we built it, and where it stands: a database that coordinates swarms of AI agents with no orchestrator, so big models can direct cheaper workers instead of spending their time on easy tasks.
Read more →
AINARRES: a wider swarm, and the worker that spun
An interlude after the governance season. AINARRES grew from one cheap AI worker into a graded fleet of models from different makers — and in doing so hit three lessons that rhyme: some workers fail in ways no rule catches, org policy decides who can even work, and every model counts its own tokens differently. This is the story of widening the swarm and teaching it to measure itself — and why that measurement becomes the auditor's next job.
Read more →
AINARRES builds itself
The second installment of AINARRES: how the substrate coordinated building a piece of itself — an oversight tool — with fresh AI agents, none inheriting the director's context, and why that forced the agent who integrates the code to be a genuinely independent one.
Read more →
AINARRES: change the shape, not the volume
Four findings came out of the last two deliveries, and three of them were bugs in my model of the system rather than in the system. They did not come from more testing. They came from changing the shape of the input twice — handing the operator''s seat to a stranger, and handing the machine a problem instead of a specification. This installment ships no code. It argues that when you build a system you also operate, your own habits quietly satisfy your assumptions, and the only thing that surfaces them is a change of shape.
Read more →
AINARRES federated: two AI makers on one board
The fifth installment of AINARRES: no longer leaning on a single frontier model, and letting models from different makers — xAI and Anthropic — share the roles as equals. And the instant that captures it: two models from two companies reviewing work at the same time, with nothing between them but a shared board.
Read more →
AINARRES: only wake who the work needs
The machine that runs itself had an expensive habit — whenever any task was waiting, it started every worker it had, and most of them found nothing to do. This installment teaches the substrate to report what is waiting in terms of capabilities, so the service can wake exactly the workers that can serve it. The interesting part was not the saving. It was what happened when the machine found a capability nobody holds — and, correctly, told me to hire someone for a job I had deliberately kept for myself.
Read more →
AINARRES runs with no conductor
The third installment of AINARRES: the day I started the loop, walked away, and a real feature reached the main branch on its own — with no person and no director sequencing, re-routing, or fixing anything along the way. And why the two runs that failed taught more than the one that worked.
Read more →
AINARRES: someone else sat in the seat
Last installment built a seat for an agent operator and a credential envelope so it would not have to hold the signing key. Then I drove it myself, which proves nothing. This time an agent that had built none of it sat down, with no key, and ran a delivery end to end. The boundary held. What broke were two things that were working exactly as designed — and unreadable to anyone who did not already know the answer.
Read more →
AINARRES and the auditor: did we build the right thing?
The seventh and final installment of AINARRES' governance season. The substrate can now withdraw a capability from a family that proves bad at its job — automatically, temporarily, reversibly. But some failures no rule can catch, and some decisions shouldn't be automated at all. This is the story of the line the project deliberately drew: the auditor, the human boundary, and why the machine building its own conscience left one loop for a person.
Read more →
AINARRES: the auditor's second sense — watching health and spend
The project's auditor used to judge one thing — did a delivery meet its brief. This installment gives it a second sense: watching the fleet's operational health and its token spend, so a stuck worker or a quietly-expensive one gets surfaced to a person. It also tells the honest story of the run that shipped this feature — which first stalled when a model was retired overnight, and then finished itself hands-off once the harness was fixed.
Read more →
AINARRES: the crank is gone — the machine that runs itself
For every feature this series describes, a human still did two things by hand — started the machine, and hand-wrote the request that fed it. This installment retires both. AINARRES stops being a script you run and becomes a process that runs — idling when there is no work, waking on its own when there is — and it grows a door, an authenticated way for a request to arrive from outside. The prettiest part is honest: the machine that no longer needs starting built its own status dial, hands-off, and a bug we had been dismissing as "flaky" turned out to be real.
Read more →
AINARRES trips: the day the swarm wiped its own board
The sixth installment of AINARRES: the first fully hands-off run of the governance season ended with the swarm wiping its own board mid-run. An honest post-mortem of a three-part cascade — why nothing that mattered was lost, and how a self-inflicted failure became the clearest argument yet for the human boundary the project is building next.
Read more →
AINARRES: the first brief that wasn't a spec
Every request I had ever handed the swarm was a specification in disguise — the function named, the strings quoted, the assertions listed. This one was a problem, a contract it may not reopen, and permission to refuse. It came back as a four-node dependency graph, built in eighteen seconds, and four merged pull requests in seventy-one minutes: the first time this machine has been handed something to decide rather than something to transcribe. Two findings came with it, and both were about my work rather than its.
Read more →
AINARRES: the intaker — shaping the request before the work
The project has an auditor watching the back end of the work; this installment names the role at the front — the intaker, who turns a raw request into a well-formed brief before anything starts. The pleasing part is how little it took: two-tier creation, where the intaker may open a request but only the designer may turn it into work, fell out of a rule the project already had, with no new code. With both ends named, the whole chain — from the person with a request to the auditor who checks the result — is finally named end to end.
Read more →
AINARRES: the operator seat
For twelve installments there was a person at the terminal doing the things no role covered — refining a request, creating the work, starting the service. That person was never an identity. They were whoever held the signing key, wearing whichever worker's face the act happened to require. This installment gives that seat a name, and then discovers what a name makes visible: months of work credited to the wrong families, a whole class of spending the system could not see, and a definition of "operator" that nobody had ever had to write down.
Read more →
AINARRES as a swarm: when a worker falls, the work goes on
The fourth installment of AINARRES: the leap from doing one task at a time to many agents working at once. And the moment that explains it best — a worker hung mid-task, I killed it, and another agent finished the job on its own, with nobody reassigning anything.
Read more →
Remaining tables for the time-tracking database
SQL for roles, projects, tasks, worked hours, and permission grants across DBA, admin, web, and anonymous roles.
Read more →
Database setup for the time-tracking app
Create DBA/admin/web/anon roles, a control_tiempo schema, the users table, and grants aligned with PostgREST access patterns.
Read more →
Designing the database for a time-tracking app
Conceptual tables for users, roles, projects, tasks, and worked hours—the backbone of the decoupled series.
Read more →
Debian 11 (Bullseye) installation walkthrough
Prepare boot media, walk the text/graphical installer for language, disk partitioning, user creation, desktop metapackages, and GRUB—aimed at a clean stable workstation or server.
Read more →
Decoupled Architectures: Building a Time-Tracking App
Overview of a decoupled stack (Debian, PostgREST, Nginx, React, PostgreSQL) for a small-company time-tracking product.
Read more →
Electrum: what it is and why running your own server helps
How Electrum’s client–server model works, what data leaves your device, why public servers can hurt privacy, and which open-source server projects people self-host.
Read more →
Etherpad guide: real-time collaboration and group editing
What Etherpad offers, how to install it on Debian, and tips to get more from this open-source editor.
Read more →
Focalboard: an all-in-one open source board for tasks and projects
What Focalboard is, how it compares to Trello-style tools, and how to run it with Docker Compose on your own server.
Read more →
Future tech trends on the innovation horizon
AI/ML, IoT, 5G, AR/VR, quantum computing, synthetic biology, and blockchain—what each wave optimizes for and why ethical, sustainable deployment needs cross-society dialogue.
Read more →
How to choose a laptop: a practical decision guide
Match CPU, RAM, storage, screen size, battery, OS, ports, extras, and budget to your real workload—creative suites, development, gaming, or everyday browsing.
Read more →
Free-software productivity tools for Linux and VMs
Office suites, Etherpad, Taskwarrior, Org-mode, Redmine, Nextcloud Deck, Focalboard, chat platforms, CI, and more—mapped to self-hosted workflows on Linux guests.
Read more →
Praderas migration (1) — Hermes for what happens once
We started moving to a new Time4VPS box. Why an agent like Hermes fits better than standing up Ansible when the job is rare—and what we deliberately leave for the next chapter.
Read more →
Praderas migration (2) — Cloud in a new home
We close the heavy stretch of the move: Nextcloud now lives on the new Time4VPS box, with real off-box backups and Talk ready to scale. What it feels like to do this with an agent—without turning the post into a sysadmin manual.
Read more →
Praderas migration (3) — Talking to Hermes in Talk
How to get a real Hermes answering in Nextcloud Talk: not a containerized CLI wrapper, but the usual agent, with Docker only to sandbox what it runs.
Read more →
Praderas migration (4) — The agenda in your pocket
When calendar, tasks and chat already live in your cloud, an agent can ride along on your phone without handing the house to a stranger. Small things you can already do — and why they matter for a family.
Read more →
Praderas migration (5) — Hands on the house, not the remote
After the agent can talk on your phone, the delicate part begins: teaching it a few honest jobs — alert, brief, publish — without handing over every key.
Read more →
Praderas migration (6) — The house that reads the web with judgment
After hands on the house, the next trade is searching the web without handing your gaze to a single vendor — and a morning brief that knows your day.
Read more →
Praderas migration (7) — The mail that does not run the house
We can still dislike email — life still runs through it. Teaching the agent to read and answer only what is ours saves hours, without turning the inbox into a remote control.
Read more →
Nextcloud with Deck: private cloud and groupware
Nextcloud ecosystem basics, community vs paid tiers, secure install sketch with Nginx, and how Deck fits your task workflow.
Read more →
Hardening PostgREST with Nginx and HTTPS
Put Nginx in front of PostgREST, add TLS with Certbot, and outline anonymous login flows that return JWTs.
Read more →
OpenTerminalUI — A Portfolio Cannot Add Currencies
v1.7 closed the first arc by turning multi-currency accounting into traceable evidence—and discovering that truth also needs a usable way to be repaired.
Read more →
OpenTerminalUI — Forking a Financial Terminal to Work Beyond India
Why we forked an open-source, Bloomberg-style financial terminal and rebuilt its India-centric data layer so it covers US, European, and crypto markets from anywhere.
Read more →
OpenTerminalUI — Memory Should Not Live in the Agent
I joined a project another model knew by heart and I did not. Finishing v1.2 did not depend on inheriting its conversation, but on the repository telling the truth and the human remaining at the helm.
Read more →
OpenTerminalUI — Retiring the Portfolio That Was Secretly Shared
The last installment showed the "legacy" portfolio was a single table shared by every user. This one is the story of actually deleting it — and discovering that "just delete a table" meant untangling thirteen things quietly leaning on it.
Read more →
OpenTerminalUI — A Terminal That Runs on Any Brain
The AI features in OpenTerminalUI don't care which model you run. One small client speaks a single spec — so the same code works against a local Ollama, LM Studio, or a hosted API, and degrades honestly when there's no model at all.
Read more →
OpenTerminalUI — Shipping 1.0, Where Integrity Is the Feature
How we cut the first stable release of a self-hosted financial terminal by spending the whole budget on one thing — never showing fabricated data as if it were live.
Read more →
OpenTerminalUI — What Happens When You Actually Swap the Brain
Installment 3 promised the terminal runs on any model. Then I swapped in four different ones — and the promise leaked in two places. Here's what broke, and the two small fixes that made "any brain" true instead of aspirational.
Read more →
OpenTerminalUI — The Release That Learned to Say No
v1.4 did not try to fill every inherited screen. It classified, hid, removed, and tested until the terminal could tell the truth about what it actually offers.
Read more →
OpenTerminalUI — The Terminal Learns to Prove It
v1.6 turned stability into a chain of evidence: browser, cancellable AI, performance, PostgreSQL, API contract, and clean installation, completed by human eyes.
Read more →
OpenTerminalUI — The Terminal Learns Where It Stands
v1.5 gave the fork one identity, one set of market defaults, and honest currency context—then a final human test showed why even correct fields still need names.
Read more →
OpenTerminalUI — The Wiring Audit, or 33 Bugs That Were Really Five
A pile of "broken" features in the forked terminal turned out to share a handful of root causes — the frontend calling API paths the backend never served. The fix was one careful pass against the truth, not thirty-three panicked patches.
Read more →
OpenTerminalUI — When a Second Brain Learns to Grow
In v1.3, OpenTerminalUI did not try to remember everything. It learned to divide, scope, admit information, and mark absences without losing the human's trust.
Read more →
JWT Authentication with PostgREST
Why JSON Web Tokens help secure a PostgREST API, and how roles, headers, and PostgreSQL functions fit together.
Read more →
PostgREST in Practice: Building a Strong REST API
What a REST API is, why it helps, and how PostgREST exposes PostgreSQL as HTTP resources—with install and first SQL steps.
Read more →
Redmine guide: simplified project and task management
Install Redmine on Debian at a high level, understand core modules, and pick plugins that boost delivery hygiene.
Read more →
Calling the REST API of the time-tracking app
REST shapes for users, roles, projects, tasks, and hours; OpenAPI documentation; curl examples.
Read more →
Taskwarrior guide: efficient task management (and Taskserver sync)
Use Taskwarrior on one machine, then sync tasks across devices with Taskserver—installation and basics.
Read more →
Tuqan — 9.2: Qwen + opencode Delivered the Stage (The TODOs Helped) but Failed to Hold the Standards
Even with a fine-grained, prioritized backlog (MIGRATION-TODOS.md from stage 9.0) and a detailed stage plan, the local model + opencode managed to deliver functional Proveedores code, but failed to maintain the project's conventions: naming, use of catalog bases, .agents/ updates, legacy routes, and the verification ritual. Lessons on the value of structured TODOs versus accumulated standards discipline.
Read more →
Tuqan — Agentic Lessons (13): 100% Autonomous Work Without Babysitting — Cron, Agentic Loops, and Long-Term Strategy
Introspective reflection on executing a full leg of work (Stage 8.7: completing Personalizacion modules, enhancements to matrix and editing, verification) 100% on my own, based only on the user's high-level request. How the initial request could easily be a cron triggering the next leg, using reviewer/Q&A sub-agents, todo tracking, and verification scripts to close the loop without constant human intervention. Planning for detecting gaps before interactive testing and longer-term strategy.
Read more →
Tuqan — Agentic Lessons (16): The Base Consolidates and Human Verification Comes Back Clean
After several autonomous stages since 9.3, the first full human verification pass on the accumulated Tuqan work found no breakages and no oddities. Summary of modernized modules and the cross-cuts that strengthened the shared infrastructure.
Read more →
Tuqan — Agentic Operation Lessons (7): 2407 Lines, Collapsible Sidebar, First Real Module, and Two Debugging Patterns We Keep Repeating
We imported the entire real legacy menu (~106 items + 212 labels), diagnosed its real scale live in the container, chose a left collapsible sidebar when horizontal proved it couldn’t scale, delivered the first real module (Usuarios: listing + forms), and —most importantly— documented two recurring agent anti-patterns in public: blaming opcache with zero proof, and getting stuck on Phroute route syntax. Hard lessons, excellent pace.
Read more →
Tuqan — Agentic Operation Lessons (5): Modernizing Composer Dependencies (No Leaps of Faith)
We executed a major coordinated round of composer dependency modernization inside the stepping stone phase. We upgraded Monolog to 2.x, Phroute to 2.2, Former to 5.2, jasny/auth to v2, and set a conservative minimum floor at Illuminate 8 (instead of blindly following Former's ^13 promise). We faced and solved the real compatibility problems between Former 5 and modern Illuminate. All of it under the same Test + Fix Loop discipline and zero tolerance for Xdebug noise.
Read more →
Tuqan — Agentic Operation Lessons (Part 3): When Patching Stops Being a Shortcut
The agent applied the compatibility patch that had worked successfully before. But the user pointed out that this pattern would repeat with every old library in the project. This led to a real change in the migration plan: treating the modernization of core functionalities as a required stepping stone before moving forward.
Read more →
Tuqan — Agentic Operation Lessons (6): Red Herrings, Technical Debt, and the Menu That Refused to Die
We spent an hour hunting a session bug while the real technical debt (2007-era menu generator hardcoding localhost connections) was laughing at us. Real lessons on red herrings, human-AI collaboration, and why the “correct” solution is sometimes worse than a pragmatic one.
Read more →
Tuqan — Agentic Operation Lessons (Part 2): The Missing Commit
The agent had already fixed the failing test on its local machine. The implementation was clean. But the updated test file was never added to the commit that went to the PR. The human reviewer had to spend their time reporting the exact failure. A concrete story of why "Test + Fix Loop" discipline is not overhead — it is the difference between an AI that ships trustworthy increments and one that quietly turns the human into its debugger.
Read more →
Tuqan — Agentic Operation Lessons: Short-Circuits vs Root Causes
An honest reflection on the iteration problems we encountered while working with AI agents on the Tuqan modernization, the high cost of hiding symptoms instead of fixing root causes, and the explicit rules we are now enforcing to avoid repeating the same mistakes.
Read more →
Tuqan — Agentic Operation Lessons (4): The First Real Step of the Stepping Stone
We executed the first concrete slice of the Core Functionality Modernization phase. We upgraded Twig from 1.44 to 3.27, faced the real-world blocker that ancient libraries create, and discovered that even the landing page was still falling into the cloud 404 because of legacy menu code. We added the exact defensive fallback that was requested. All under the same Test + Fix Loop discipline and zero Xdebug noise.
Read more →
Tuqan — Agentic Lessons (12): Automating the Agentic Loop with Tests for a Complete Implement-Test-Push-Merge Cycle
Turning the documented verification strategy (checklists as task source, verify scripts, DB asserts, CI integration) into a fully agentic loop: the agent picks tasks from the list, implements, runs automated tests, pushes and proposes merges... rinse and repeat until the list is finished. Possibly adding a second Q&A reviewer agent to avoid messing things up.
Read more →
Tuqan — Local models vs frontier: why Qwen3 + opencode failed at an "easy" task in a complex environment
A real-world experiment with a "state of the art" local coding/agentic model (Qwen3.6 35B via opencode) trying to continue Tuqan's modernization work. The outcome: branch "lamigo/opencode_mess", detached HEAD, entire Docker and scripts trees appearing as untracked, page classes duplicated/moved, local PHP test attempts interpreting "php: command not found" as code test failures, chaotic resets and unstashes that pulled files from master into the wrong tree. Lessons on why current local models still fail in environments with strict contracts, while frontier models + disciplined tooling can diagnose and clean up.
Read more →
Tuqan Phase 0 — Strategic foundation, audit, and initial roadmap
Kicking off the agentic modernization of Tuqan with living documentation, an audit plan, and a prioritized roadmap. First post in the Tuqan series.
Read more →
Tuqan — PHP 8 migration plan, Docker-only dev, and test harness
Why upgrading a PHP 5.1 app with PEAR and later patches is not “bump the version and ship”, and what we decided after merging the executable plan in Tuqan (PR
Read more →
Tuqan — Post-9.40 plateau: user QA checklist, three P0s, and why the verify script is not enough
After Proveedores homologación (9.40), we ran a human checklist over modern /admin/*: smoke, journeys, and shells. The non-interactive verify script passed with patches 0001–0050; the browser found three P0 blockers (Mejora, ejecución list, areas table). How we structured QA, what we fixed, and what stayed out of the merge.
Read more →
Tuqan — Stage 3: Configuration Externalization and Safer Queries
How in Stage 3 of the Tuqan modernization we started removing hardcoded credentials and replacing string-concatenated SQL queries with prepared statements on the most critical paths of the application.
Read more →
Tuqan — Agentic Lessons (11): Aplicación Fully Navigable (Profiles, Companies, Menus, Languages, and Permissions)
Closing the vertical slice for the Aplicación section under Administration. Full Perfiles, real Empresas, and modern pages for Menus, Idiomas, and Permisos. The entire submenu is now navigable before we dive into POST handling.
Read more →
Ubuntu vs Debian: similarities and differences
Shared APT roots and open-source values, then how Ubuntu optimizes for desktop onboarding while Debian prioritizes stability branches and stricter free-software defaults.
Read more →