Kits

A kit is the unit that plugs into the platform: a separate service with its own schema in the shared PostgreSQL, its own manifest and its own ui.js. "Kit" is what it is called in the interface, in the licence and on the invoice; "module" is the mechanism by which it is attached — one thing, two words for two conversations.

The core knows nothing about any particular kit beyond its manifest: id, name, sections, job kinds, capabilities, resource kinds, metrics, and the limits it wants the licence to enforce. Everything a kit needs in the same way as every other kit — schedules, the job queue, secrets, storages and copies, rotation, the journal, metrics, alerts — it takes from the core rather than implementing itself. That is why a kit's specification is mostly about what its subject is different in, and why the most interesting part of each page below is what the kit refuses to do.

Kit	id	What it does	State
Network Map Kit	net	host discovery, port scanning, a map of the network	works, the map is in place
PostgreSQL Kit	postgresql	logical backups of PostgreSQL, encryption, rotation, verification by restoring	works
Nexus OSS Kit	nexus	image clean-up in Sonatype Nexus Repository OSS over its API	works

One kit per DBMS

There is one kit per database engine, not one "backups" kit for all of them. What engines really differ in — dump consistency, format, restore — is almost the whole content of such a kit. What they share — schedules, storages, rotation, copies, verification by restoring — belongs to the core and to the shared library libs/agdb, and is not duplicated in either. Adding a second engine cost a driver, a profile, a manifest and a screen.

What every kit does the same way

• Rights per kit. A user with no grant on a kit does not see it at all — not in the menu, not in lists, not in error messages.
• Jobs and schedules belong to the platform. A kit declares job kinds and how many may run in parallel (max_parallel); the queue, the schedules and the "what is running now" screen are the core's. A kit adds only the translation — the core knows {"rule_id": 7}, a person knows "the nightly rule on angry.team".
• Secrets belong to the platform. A kit names a secret; the value is handed out at the moment of use and the fact of use goes into the journal. No kit keeps a password of its own, and no API returns one.
• Copies are written by the kit and measured by the core. Bytes never go through the core (a download back to a person is the one exception, and it goes through the core precisely because the core holds the key). The core counts the copies, measures the free space, rotates by grandfather-father-son and never deletes the last verified-restorable copy.
• Metrics are declared, not pushed. A kit declares its metrics in the manifest and answers GET on its metrics endpoint; the core decides how often to ask, keeps the history and serves the same values on the dashboard, on /metrics (Prometheus) and on /api/monitoring (JSON).
• Reports are in words. Every run has one line saying what it did, written by the kit — the same line on the screen, in export and in an alert.
• Every field explains itself. Labels carry hints; the specification requires it (И8), and a tool counts how many elements do.
• Records are not translated. The interface and its refusals follow the user's language; what is recorded (journal lines, verdicts, report headlines) is written once and stays as written, because records are compared and searched.