Skip to main content

Services and logins

One table lists every outside service and every login-gated website the system touches. For each one, it says how to connect. It never says whether the system is signed in right now. That is checked live.

Where you see it​

The owner mostly does not. The table is for the agent. The rule is simple: check the table before opening any site that has a login.

The owner sees the result when the agent says "I can get into your supplier portal" instead of "I think that site blocks me."

What happens, step by step​

  1. The agent needs to check an order on a supplier's website.
  2. It looks up the supplier's row in the table.
  3. The row says how to connect: an API key (a password for programs) by name, or which saved browser profile to use.
  4. The row does not say "signed in: yes." The agent checks that on the machine itself, right now.
  5. If the site blocks the agent, it climbs the ladder below, one rung at a time.
  6. If this is a brand new service, the agent runs the add-new-service skill. That skill writes the table row in the same step, even if the login fails.

The blocked-site ladder​

When a site refuses the agent, it tries these in order and stops at the first one that works:

  1. Check the table. Maybe there is already a known way in.
  2. Skip the browser. Try an official API, a ready-made command-line tool, or a data service.
  3. Use the machine's residential address (an internet address that looks like a normal home), if it has one.
  4. Do a real login through the add-new-service skill.
  5. Last, ask the owner to help: a tap, a one-time code, or typing a password themselves.

What powers it​

PartWhat it does
Resources/Services/INDEX.mdThe one table. One row per service: type, how to connect, which profile, which address.
Resources/Services/<name>.mdA detail page, only for services with real quirks. Most rows need none.
login-playbooks.mdStep-by-step login notes per site.
add-new-serviceThe built-in skill for connecting anything new.

Websites the owner runs are rows in the same table. A site earns a row only if it has its own domain and a deploy. The row gives the code repo's name, never where it sits on a disk.

Why it works this way​

"Is this site signed in?" is a fact about one machine at one moment. Written in a file, it goes stale the instant it is saved. So the table records only the how, and the machine answers the whether.

This came from a real mix-up. The box once told the owner that a social site blocked its address. In fact, it had a logged-in profile and an address bought for exactly that site. It had guessed instead of checking. The rule now is: never call a site blocked or logged out without checking the machine first.

One address per client box

Each client box that needs one gets its own residential address. It is bought on that client's own card, in that client's own area, before the first login on that box. Only the browser profiles set up to use it go through it. Others connect directly.

Two rules follow from that:

  • Set the address before the first login. Switching addresses after a session exists looks like a stolen account to big social sites, and they end the session.
  • Two client boxes never share one address. Platforms link accounts that share an address. If one account gets banned, the other can go down with it.

The actual keys, account names, and addresses in the real table are private. This page describes only how the table works.

Connected to​