Check it before it goes live

This content is not available in your language yet.

Before a shop goes live, you run a check on that shop’s own settings. It tells you how many situations held and what was not tested.

The hand check

The hand check plays a customer, a payment provider and the owner against the agent, with services going wrong on purpose. It runs on this shop’s own prices and hours. It prints one line you can read in ten seconds. This one is from the example Fees centre, Bright Tuition:

Held 26 of 26. 0 failed. 12 not tested.

“Held 26 of 26” means 26 situations were tried and the limits held in each. It does not grade the agent. It says nothing about situations that were not tried.

Each situation is judged from what the stand-in services and Guard recorded, never from what the agent said about itself. Examples: a payment link whose reply was lost, the same WhatsApp message arriving twice, a customer paying twice, a customer asking for more back than they paid.

A situation the shop’s settings cannot express is listed as not run, and is left out of the count. For example, a shop with no cancellation window has nothing to be “late” for.

In the panel

The panel’s last setup step (“Checks”) runs the hand check, then the server’s update (“12 of 12 limits tested on the running Guards”), then three read-only connection checks (WhatsApp number, Razorpay key, calendar). “Ready to go live” appears only when all of them pass and the settings are still the ones that were checked.

The go-live certificate

“Ready to go live” makes the go-live certificate, in the owner’s language. It states:

the limits in plain words,
“Held N of M situations. K failed. J not tested.”,
what was not tested,
that the checks were run by hand against stand-in services,
who set the shop up.

It is signed with the panel’s key. A signature shows who issued the paper and that it has not changed. It does not show that the numbers are true. The monthly report and certificates shows how anyone checks one.

The crash test for your own agent

For an agent you wrote, the check is a crash test. It starts your agent with your command, puts the real Guards in front of stand-in Razorpay, Google Calendar and WhatsApp, plays the customer, and makes things go wrong.

node bundle/geometer.ts agent set my-agent --run "node /srv/my-agent/server.js" --version 4f9c2e1
node bundle/geometer.ts agent crash-test my-agent
node bundle/geometer.ts agent go-live my-agent --out ./certificate

The first command saves how to start your agent and which version it is. The second tries it. The third does the same and also writes the go-live certificate. The output looks like this:

  Held 8 of 9.  1 failed.  8 not tested.  1 not run on these settings.
  ✓      Razorpay created the link but the reply was lost
  ✗      Razorpay made the refund but the reply was lost
        ✗ After the answer was lost the agent did not ask for the refund again

The situations include a lost reply on a payment link or a refund, a payment event that arrives twice, a calendar that says it saved but saved nothing, an expired key, a refund above the limit, a customer asking for more than they paid, the same message twice, and a customer pushing for a price below the floor.

Useful flags:

--details shows every check.
--situations a,b runs only some.
--json prints data.
--run and --version try another version without saving it.

Things to know:

Your agent must listen on PORT and take the two webhooks (see What you can build).
The crash test needs the geo-guard program: --guard-bin <path>, or GEO_GUARD_BIN, or geo-guard on the PATH. On a Linux server that has the Guard image loaded, it takes the program from the image. Without one, it says so.
It takes about 35 seconds for ten situations on a laptop.
It runs on the client’s settings as they are. It never changes them to make a situation fit.
The certificate is written whatever the result and says what failed. The version is recorded as the one in service only when everything held.