Promise registry

We compared this site against this code twice, and both times found the same thing. The product promised what did not exist.

The most expensive case was one word: support. It stood in every plan on the pricing table, and people were being asked to pay for it. There was no place anywhere for a request to land. No inbox, no queue, no screen.

Two more came out of the same reading. The fingerprint editor drew a coherent device on screen, then handed the profile a combination no real machine has. The pricing table promised bulk actions on profiles, and the dashboard had no such screen.

Nobody wrote those lines to deceive. That is what happens when sales copy and code drift apart and nothing in the build notices. So the drift was written down, and a program now watches it.

• Support in every plan

  Sold in all four plans, implemented nowhere. It now lives in apps/server/src/support/support.service.ts, with a stand at apps/server/test/поддержка.js.

• A machine that could not exist

  The editor showed a consistent device and issued an impossible one. The choice and the result are now judged by the same rules.

• Bulk actions on the price list

  Promised in the pricing table, absent from the dashboard the buyer actually opened.

The format is one line and nothing else fits into it. What is promised, where it is done, what guards it. A row that explains instead of pointing at a file cannot be checked by a program.

The middle column is a path you can open, not a folder and not the name of a subsystem. The right column is an executable stand: a file that runs code and turns red when the behaviour breaks.

The registry itself lives at docs/РЕЕСТР-ОБЕЩАНИЙ.md and is split into seven parts: engine and fingerprint, proxies and network, team and access, money, support, the app, the site.

1. 1

   Read the claim

   Take the row "The proxy covers all of the profile's traffic, not only https".

2. 2

   Open the file

   apps/desktop/src/lib/forkEngine.js is where that rule is written for the engine.

3. 3

   Run the stand

   apps/desktop/test/proxy-covers-https.js executes it and judges what actually leaves through the proxy.

4. 4

   Break it on purpose

   Narrow the rule back to https, run the stand again, watch it go red, then restore the code.

These are taken from the file without rewriting. Paths are relative to the repository root, and every one of them exists today.

The spread is deliberate. Engine, network, team, money, support, app, languages: in every part of the registry the rows have exactly this shape.

Engine and fingerprint

14

Proxies and network

11

Team and access

3

Money

12

Support

4

The app

21

The site

5

Seventy rows in total, counted from docs/РЕЕСТР-ОБЕЩАНИЙ.md.

Writing a registry is not enough. A document nobody executes rots within a month, and this one would rot faster than most, because it is exactly where inconvenient truths get quietly edited.

So the registry has its own stand. apps/web/test/реестр-обещаний.js parses the table out of the Markdown and makes seven assertions about it. It runs inside the site suite, along with everything else.

Four of those assertions are about existence. The file is there, the stand is there, no cell is empty, and the file and the stand are not the same path. A promise that guards itself is not guarded at all.

Three are harder. The parse must find at least thirty rows, so a broken parser cannot report an empty registry as a clean one. Every named stand must appear in its package's test command. And six words must survive in the registry: support, fingerprint, proxy, invitation, paid plan, prices.

• The registry parses, and it is not empty

  At least thirty rows, otherwise a broken parser would read as a clean registry.

• Every claim names a live file

  The path is resolved from the repository root and must exist on disk.

• Every claim names a live stand

  The same rule for the guard column.

• Every stand is really in the run

  The file name must appear in that package's test command, or the command must run the whole directory.

• The stand reaches the file it guards

  The hardest of the seven. It has its own section below.

• No empty cells, and file is not stand

  A promise cannot be its own proof.

• The most expensive promises are named

  Support, fingerprint, proxy, invitation, paid plan, prices. If one disappears, the stand fails and says which.

File alive, stand alive, run green, and the stand is watching something else entirely. That happened here, and nothing on the screen said so.

The row about automatic proxy rotation named proxy-rotation.js as its guard. That file exercises proxies.js. The rotation code itself, proxyRotate.js, was executed by no check in the repository. A claim on the storefront was living without proof.

So the stand now requires a guard to reach its file. It reads the guard's source, strips comments first, and demands that the file be named. Comments are stripped because a line saying "see proxyRotate.js" is not execution. That exact trick once kept an engine check green after the whole WebGL noise block had been cut out from under it.

Two exceptions exist and both are narrow. A stand under apps/server/test that spawns a real server exercises the server as a whole, and both signs are required, not one. A file under packages/shared is imported by package name, so naming @armanos/shared counts.

One more rule grew out of a self inflicted wound. The match used to accept a file name without its extension. For packages/shared/src/index.js that is the string "index", which appears inside any indexOf call. Roots that short are now refused outright: index, api, main, utils, types, config.

• By name

  The guard's source names the path, the file name, or a name root that is not too general to mean anything.

• By live server

  A stand under apps/server/test that itself spawns a real server exercises the whole server, including the named file.

• By package name

  Files under packages/shared are imported as @armanos/shared, so requiring the path would require what nobody writes.

A written check that no command calls creates the feeling that a place is covered. That feeling is worse than an empty place, because nobody goes back to look.

scripts/все-ли-проверки-в-прогоне.js runs first in the whole suite and executes no product code at all. It only compares the check files on disk against what the commands actually call.

It used to know four areas by heart, and there are seven. That blindness hid two real holes. The command line tool had a genuine stand with twenty nine checks that nobody had ever called. The JavaScript SDK, named on this site as an advantage, had a test command pointing at a file that had never existed for a single day.

Areas are now counted from the workspaces list, not remembered. The guard also refuses a command that names a missing file, and a glob that matches nothing. It checks that it is itself in the root command, because a guard nobody calls has the same disease.

There is one honest exception, and it declares itself. A measurement that opens eight real browsers has no place in a run that must work on any machine. Such a file carries a line saying it is a measurement and why, with at least twenty characters of reason, and the guard prints every one of them by name at the end. A silent exception list rots. A printed one gets re-read.

• A check on disk that no command calls

  Named in the failure, with the area it belongs to.

• A command that calls a file which does not exist

  The SDK case: the path was dead from day one and looked like coverage.

• A glob that matches nothing

  An empty pattern runs zero files and reports green.

• An area missing from the root command

  Then "everything is green" means green for part of the tree.

• A check written after the summary line

  It runs, it prints, and its result is not counted. Guarded separately by apps/desktop/test/checks-really-run.js.

The home page states how many automated checks exist. A number like that is easy to type and easy to forget once it stops being true.

So it is computed. apps/web/scripts/сосчитать-проверки.js runs the three suites, counts the ok lines, and writes apps/web/measured.json. The page imports that file and nothing else.

A red run writes nothing. If a suite fails, the script names it and exits before the write. Otherwise the front page would carry a number produced by a broken suite. apps/web/test/proof-strip.js asserts that the exit stands before the write in the source, not merely in intent.

Two numbers come straight from code rather than from counting lines. The fingerprint reading count is obtained by building a fingerprint and asking the audit module how many readings it expects. The language count is the number of dictionary files on disk. The guard derives both again and compares.

Prices and quotas never take this path at all. The pricing table imports PLANS, TEAM_SEAT_PRICE and EXTRA_PROFILE_PRICE from packages/shared, the same package the desktop app uses to decide what your subscription allows. The download page takes the free plan's profile count from the plan itself. Nobody types 2, 3 or 200 into a page.

Automated checks

2233

server

440

desktop app

1602

site

191

Fingerprint readings

25

Languages in the app and on the site

22

The contents of apps/web/measured.json. Recount with node scripts/сосчитать-проверки.js from apps/web.

A green check that cannot go red is worth nothing. So the method is fixed and it is boring. Break the behaviour in the product code, the way it actually breaks. Run the check. Watch it go red for the right reason. Restore, and watch it go green.

This is not ceremony. It finds real defects. The server answered "not enough rights" to an invalid key, which told an attacker the key had been recognised. A convenience for the local machine opened the whole local network. Login passwords were sitting in a file in clear text.

It also exposes bad work of my own. Three of my defect returns were themselves no good: one hit a line that could never run, one broke a different fingerprint generation, one broke the parser instead of the behaviour. Before you trust red or green, make sure you broke the right thing in the right way.

A neighbouring trap has its own guard. Checks written below a stand's summary line do run and do print, but their result is not counted. The file exits green with a failure on the screen. apps/desktop/test/checks-really-run.js reads every stand and refuses that shape.

1. 1

   Break it

   Return the defect to the product file, in the way it actually occurred.

2. 2

   Run the stand

   It must go red, and the message must name the real cause.

3. 3

   Read the message

   A stand that goes red for the wrong reason proves nothing.

4. 4

   Restore

   Put the code back and confirm the green again.

The registry is not only a list of things that work. It carries, in full, the two places where measurement failed.

WebGPU on Windows. Acceptance of the Windows engine returned "not accepted" on one stand out of five. The rented machine has no graphics card, and Chromium then turns the WebGPU capability off at the hardware information level, before any provider is chosen. Across six launch variants navigator.gpu was absent entirely. The patch covering pixel reads through WebGPU is therefore unverified on Windows, and this site claims nothing about it.

Speech synthesis voices on Linux. The first note here blamed a stripped component updater, and it was wrong. Six measurements gave the real answer. Chromium keeps the system speech path behind a launch flag that real Chrome does not set, and real Chrome on Linux reports zero voices too. With the flag on, the count is 13363, which no living machine produces. So our zero equals the platform norm, and the acceptance check was corrected to ask an unseeded engine instead.

Both entries name their logs. The Windows measurements are in docs/замеры/webgpu-windows-04-09.log and docs/замеры/gpu-status-windows-04-09.log. The verdict and the acceptance journal are in docs/замеры/приёмка-windows-02-09.json and the matching .log. The rented machine can be deleted without losing the verdict.

The registry is also a list of what is not sold. If a thing has no row, it is not a claim, and you should not plan around it.

Card payment. The billing code is written against a card processor and stays inert until keys are supplied. With no key the service never builds a client and answers that payments are not configured. A processor has not been chosen yet, so nothing here promises a checkout button that charges a card today.

Code signing and notarization. The macOS target already runs with hardened runtime and entitlements, which is what notarization needs, and the Windows target carries a publisher name. Neither is signed. The signing identity and the Apple credentials are left blank so unsigned local builds still succeed. Until certificates exist, the first launch shows the operating system's own warning.

Legal documents. There is no offer document and no refund policy. They are needed to accept money, not to run the app, and a payment processor will require them at connection time.

Proxy resale. The proxy store is a curated directory of providers plus an order intent. Creating an order takes no payment and calls no provider. What the registry does guard here is the honesty of one badge: "our provider" lights only where automatic delivery actually works, and that list is empty today.

• Card payment

  Wired against a processor, inert without keys. apps/server/src/billing/stripe.service.ts.

• Code signing and notarization

  Hardened runtime and entitlements are set, no certificate is. apps/desktop/electron-builder.yml.

• Terms and refund policy

  Not written. Required for accepting money, not for running the app.

• Proxy resale

  An order is a recorded intent: no payment, no provider call. apps/server/src/proxy-store/proxy-store.service.ts.