Aromba — Features

Everything Aromba does for developers and vibe coders, grouped by the moment in their life where it helps. Each line is one feature; most are one chore or one assistant flow. Phase assignment is done in Claude Code; the ones marked ★ are already in phases 1–3 elsewhere in the docs. Most features here ship as skills, not as core.

1. “I deployed and I’m scared”

Pre-deploy check: disk, memory, pending migrations, certificate — “go” or “stop, here’s why”.
Snapshot before any change, with a “roll back” button in the receipt.
Post-deploy watch: 10 minutes of elevated attention; if error rate rises, message now, not in the morning.
Canary ping: after deploy, open the site’s main pages and report what’s alive.
Server changelog: what actually changed after a deploy (packages, ports, processes, configs).

2. “The site is down and I’m panicking”

★ “What happened” in one tap: diagnosis across the common causes, fix on a button. The common causes are the five of PLAN 3.11’s bench: a service that failed, a port already taken, a filesystem that is full, a certificate that expired, a container restarting in a loop. Full means any filesystem that holds real files, not only the root’s — a data or Docker volume that fills up takes the site down and leaves / looking healthy, which is how a caretaker misses it.
Morning postmortem: one paragraph — what fell, why, what was done — forwardable to a client.
Repeat-failure detection: “api-worker died 3 times this week, always 03:10 — that’s cron job X”.
“Keep it afloat” mode: the assistant may restart one named service on its own overnight, with a report.
Status page for clients: status.<yourdomain> with green/red dots, zero setup.

3. “I’m not a sysadmin and don’t want to be”

★ Standard stack in one question: “prepare this server for Next.js + Postgres” → nginx, certbot, Docker, firewall, backups.
Domain and HTTPS: “attach example.com” — checks DNS, gets the certificate, waits, reports.
Explain first: any script or command → “what this will do, in plain words” before it runs.
“Is it set up right?” audit: firewall, key-only ssh, auto-updates, backups, swap, log rotation. Score and fixes.
“Did you know” cards, one line a day for the first week.
Error translator: paste a stack trace → plain explanation and where to look.

4. “I work with Claude Code”

Night task: leave a prompt, Aromba runs Claude Code on the server overnight, morning brings a branch and a report.
server.md for Claude Code: a file Aromba keeps fresh (what’s installed, ports, services, where logs are) so Claude Code stops guessing.
Deploy from chat: “ship main” → pull, build, restart, post-deploy check.
Logs from the phone: “show api errors from the last hour” instead of ssh.
Tests overnight on the server, results in the morning.
“What Claude Code did”: files and services changed since yesterday.

5. “Money and resources”

Plan advice: 8% used → you’re overpaying; memory tight three nights → time to grow.
Who eats disk: by folder and project, not by device.
Forecast: “disk full in 11 days at this rate”.
AI spend: what the assistant cost this week, on which questions.
Forgotten resources: containers with no traffic for a month, domains pointing nowhere, cron jobs with no owner.

6. “Backups everyone forgets”

★ Database dumps kept locally, sent off-server on request.
Weekly restore test into a temporary database: “backup is readable”.
.env and config backup with a passphrase — often the only copy is on the server.
“Last backup was 9 days ago” as an alert, not a report line.
Restore from chat: “bring the database back to yesterday morning” — with confirmation.

7. “Several projects on one server”

Project inventory: what’s installed, what’s alive, what’s dead, which repos have unpushed commits.
Freeze a project: stop, archive, free the port and space, one button — and unfreeze.
Ports and conflicts: “3000 is taken by project X since May”.
Certificates across all domains in one table with dates.

8. “Security I keep ignoring”

Leaked secrets in repos or logs: found a key in code → tell.
Suspicious login: new IP, new key in authorized_keys, new sudo user — immediately.
Exposed ports that shouldn’t be (database on 0.0.0.0).
Outdated packages with known vulnerabilities — list and a button.

“Server week” card as an image — space freed, uptime, alerts — for social.
Export and move: aromba export → on a new server aromba import.
Your chores as one link: “install my Next.js set” (see Community below).

10. Small and alive

Ask the server by voice from the phone: “how are you?” — short answer. ✅ in, with the voice skill (13-skills.md §5, PLAN D144): whisper on the server, the transcript quoted back, and then the answer a typed question gets. The answer comes back as text, not speech — an answer you can reread and scroll is the right shape on a phone, and speaking it would need a second model and a second download for nothing.
Receipt style: Dry, Warm, Captain — user’s choice (see 10-voice.md).
Server diary: once a month, three paragraphs of what happened to it.
The day’s plan: the morning receipt lists what Aromba will do today and when; the next one says what ran as planned and what didn’t.

11. Chore builder

The way custom chores get made without writing code. Two stages: find, then build. Reachable as /build <what you need> and from the dashboard.

Stage 1 — find

The user describes the problem in plain words: “memory fills up at night and the site is slow in the morning.”
Under a handful of words is not a description, and Aromba asks for one before spending a turn on it.
It looks at what this server already has — mine/, core/ and the installed skills are all in the card the assistant reads — and matches by the problem, not by the name: each chore’s name, touches, params and colour are there. Then at the catalog’s skills that are not installed here, one line each (PLAN D223): most of what people ask for is a chore that exists, tested and signed, in a skill this server has not installed. The community hub arrives with the hub itself.
Found something here: the chore, why it fits, what it touches and that it is off — with [Turn it on] and [Leave it]. The tap is the same toggle /chores has. Most of what people ask for is already here and switched off, and turning one on beats writing a second.
Found it in the catalog: the skill, why it fits, and what /skills <n> shows — what it may do, its chores, its weight, whether it asks for the PIN — with [Install] and [Later]. The tap is the same install /skills has; nothing installs itself.

Stage 2 — build

Only when nothing here does it. The assistant writes the whole chore and the owner reads it before any button exists.

It writes to a brief (PLAN D234), as a page is written to one: the header’s rules; what a chore says — findings, one receipt line, an alert with the number beside it; the cage it runs in — only touches writable, ps and /proc its own, /run hidden, the server’s network reachable; the questions it may put to the Warden in asks, from the Warden’s own list; its memory, the last run’s result as PREV_*; and how it fails — a watcher that cannot read what it watches says so and exits 0, since two failed runs turn a chore off. Each line is one a bench of the programming cases found a model missing.

The message carries what the eight-step checklist used to ask one step at a time — the goal in a line, when it runs, what it touches, and the file itself, header and all — and two buttons: [Save it] and [Not this]. One review of everything beats eight messages in a chat, and nothing in the checklist was a consent the owner does not give here (PLAN D132).

What keeps a written chore honest is not the order it was written in; it is what the Warden will take. A chore saved this way is red, off, author: mine, in mine/, with a header that parses, a name that can only be a file there, and at most 16 KB. Anything else is refused with the reason — to the model when it can still put it right, to the owner when it cannot. Saving changes nothing on the server: the chore is off until its owner turns it on, running it then asks what every red chore asks, its touches cage it like any other, and lowering its colour is the PIN’s (05 §2, 05 §7). The first run is /run <name>, which is the dry-run pair every chore gets — the dry run is not a step of the builder, it is what running a chore already is.

After a week of clean runs the bot asks once: “‘Memory at night’ ran 7 times without errors. Share it?” — with the hub it shares to, which is section 12’s and phase 5’s.

A chore turned on from stage 1 can be adjusted with /chores <n> set <param> <value>.

12. Community

Private by default, always. Nothing leaves the server unless the user shares.
aromba share <chore> or the share button → link aro.mba/c/<id>. Before publishing, Aromba strips paths, hostnames, domains and usernames from the file and turns them into params.
Receiving side: aromba chore add aro.mba/c/<id> shows touches and the code, installs as red.
Hub at aro.mba: search, “installed N times”, “clean runs on N servers” (servers report only ok / failed, anonymously, opt-in). Authors can bundle chores into a set: “my Next.js set”.
Review: a chore with history and no reports gets a “verified” mark and can be promoted to yellow or green by a maintainer. Promotion is manual, always.
Reporting: one tap “this chore did something wrong” on the receipt line; the hub shows it to the author and to maintainers.

13. “I have a demo at three”

Aromba’s own calendar — everything the user keeps in it, work and the rest of life, beside what Aromba itself will do — and their existing calendar brought into it once they connect one (PLAN D107, D108; connecting is the calendar skill, 13-skills.md, D101). Each line is a setting: on for the user’s own items, and for a connected calendar off until they turn it on.

The day: /today — Aromba’s night, the user’s events and to-dos, and what a connected calendar holds, in one list, in time order, in the user’s own hour. /add tomorrow 15:00 demo adds an event, /add fri renew domain a to-do, /add 22:00 vitamins whatever else the day has.
Reminders, for what the user asks to be reminded of: “In 30 minutes: Standup, 11:00–11:30.” They never wait for anything and are never late: one that missed its moment is dropped and counted, not sent after the event began.
The day twice: the plan in the morning receipt, and in the evening — 21:00 by default — what was done of it, what moves to tomorrow, and what Aromba will do tonight.
Demo check: 30 minutes before an event the user marked (demo, launch, release: their words), a check of the server: disk, services, errors in the last hour, certificates when a watcher knows them. “Ready”, or “not ready, here’s why”, with the fix on a button.
Quiet during marked events: scheduled chores, updates and restarts, the questions Aromba starts itself, and messages that are not critical wait until the event ends. A critical alert and the fix offered with it, the demo check, and anything the user taps never wait.
Asks when there’s time: a red chore or a reboot that needs a tap is offered for the next free slot, not in the middle of a call.
Add to calendar: an item the user added, and anything Aromba plans or foresees — a maintenance window, an update, a certificate or domain expiring, “disk full in 11 days” — comes with a button that opens the user’s calendar with the event filled in (Google and Outlook on the web; an .ics file for the rest), with their usual reminder.
“When can we reboot this week?” — free slots that fit both the calendar and the server’s quiet hours (the assistant).
What an event is: the assistant knows the titles of the user’s own items; for a connected calendar, only with “Calendar titles” on — turned on at the server, never from the chat — and then of the events that count, not only their times.

14. “It’s a service, and it must not go quiet”

What one real project asked for (PLAN D110). A service in a container, a database it reads, a node it fetches from, an edge in front: the shape of most of what these users run. Each line is what Aromba watches or offers, and none of it needs the project’s code.

The service’s own log: errors per hour against its usual rate, and the newest ones quoted — a containerised project says what is wrong in its log, not in the journal.
Is it answering: one URL of its own, from this server, with the status and how long it took; two failures in a row is an alert, not the first.
What it depends on: the database, the queue, the node it fetches from — reachable, and answering a cheap question. A service that is up while its database is not is the alert nobody gets today.
Is the data still moving: the newest row, file or partition older than it should be. For a project that ingests, a stalled feed looks healthy from the outside — this is the line that catches it. ✅ for files: the data skill’s freshness watcher, hourly, on the paths you name; a row or a partition waits for the database skills.
Killed for memory: which container the kernel killed, and when it started happening. ✅ before it happens, for any process: the leaks skill’s watcher, hourly — six hours of steady growth at a rate that ends the available memory within a day (PLAN D232).
Restart loops, stopped containers, and a container whose log has filled the disk.
What Docker leaves behind: dangling images and a build cache nobody uses, cleaned at night past a gigabyte (PLAN D230). ✅ the docker-clean skill, red and with the PIN at install, on the Warden’s two prune commands.
What a container was started without: no memory limit, no health check, no log rotation. Not an alert — a line in the weekly card with the one command that fixes it. ✅ for the memory limit and the health check: the docker skill’s settings watcher, daily, said in the receipt only when the list changes, with the docker update line for the first of them. Log rotation is in a container’s own configuration, which the Warden’s read-only list does not open.
After a deploy: ten minutes of watching the error rate against the hour before, and a “roll back?” button if it doubles.
The edge in front: certificate dates, 5xx rate, and a config test before any reload.
Growth: which table or partition is eating the disk, and when it runs out at this rate. ✅ for folders: the data skill’s growth watcher, daily, measuring the paths you name against its own measurement of yesterday; per table waits for the database skills.
The jobs on a timer: a cron job that failed, and the one you name that did not run when it should have — the scraper that stopped at 03:00 and the backup that has not happened since Tuesday say nothing to anybody (PLAN D227). ✅ the cron skill’s watcher, hourly, over cron’s own log in the journal: failures of the last hour by exit status, and, for the job named, when it last started against how often it should.

15. “My product has a brain and no hands”

What the owner decided on 2026-09-26 (PLAN D207, D210). A product on the same machine — a coach, a tracker, anything with people and their data — knows what one of its people wants, and cannot make it: a board in their own colours, a report for a coach, a chart of a symptom. Aromba makes it, once, and keeps it; the next person who wants the same thing gets it in seconds for a fraction of a cent. The contract is 15-instruments.md.

The product serves five endpoints on loopback, and the owner names it once at a root terminal: aromba intake add <name> <address>. ✅
The firefighter: a product’s report of an error one of its users met is answered to that user and to its team, by the owner’s rule, with the screen described only when masked and needed (PLAN D279).
A job is the product’s own words for what one person wants, a schema of the settings they may choose, and a made-up example of the data. Aromba never sees a person’s data, and never reads a token sent beside a job. ✅
The library first: an exact repeat is answered with no model at all; otherwise the cheap model reads the job against the nearest instruments and answers from one, with this person’s settings. ✅
Only when nothing fits does the stronger model write a new page — self-contained, loading nothing and sending nothing, checked in code — and the owner sees the page itself, as a file in the chat, before approving it. ✅
/instruments: the library by product, the most used first, and what waits for the owner. ✅
Every job keeps what it cost and how long it took, and the product is told the cost. ✅
A library of instruments one product has proved, shipped signed to every server that serves such a product — the catalog’s shape for cases. Later.