TESWA — ONE PHONE, ONE ACCOUNT · THE PLAN · 2026-07-29
You decided a phone number is either a person or a company, never both. Before writing a line of code, a 12-agent sweep read the whole codebase — the site, the server functions, the phone app, the security rules and production itself — to find every place that depends on the model being replaced. This page is what it found, what it will cost, and the order it has to happen in.
739
places it touches
109
get DELETED
304
high risk
8
phases, 1 irreversible
That 109 is the good number: this change removes more machinery than it adds. The full list, with a file and a line for every row, is in the repo at plan/identity/inventory.json — that file is the contract, not this page.
One phone number = one account. Individual or business. Never both.
| Individual | Business | |
|---|---|---|
| Worlds | all of them — a car and a flat from one account | ONE, fixed at approval, forever |
| Pays by | باقات — priced per world | اشتراك — its own world tiers only |
| Can post | in any world | in its own world only |
| Appears in | — | its own world directory only |
A person lives in both worlds. A company sells one thing.
THE MOST IMPORTANT THING HERE
The account STAYS exactly where it lives today — users/{uid}/accounts/{type} — and keeps the same id. The new rule is enforced as «a second account document may never be created», NOT as «rebuild the database». Everything follows from that.
YOU SHOULD KNOW THIS BEFORE WE START
B3Deleting the switch OPENS a money gate instead of closing it
The refusal that stops a business buying an individual package works by reading the very field phase 3 removes — and if that field is simply gone, the check does not refuse, it ALLOWS. Two more money doors have no account check at all and can be called straight over the internet without the site. All three are repointed at the start of phase 3, before anything is deleted, and the gate proves each one still refuses.
AND THESE WERE BLOCKING — THEY ARE NOT ANY MORE
THE PLAN CHANGED — HERE IS WHY
I rated the first version 7 out of 10 and told you the phase coverage was unverified. So it got verified: three independent readers checked every row against the phases, and their whole job was to find what I had missed. They each found the SAME thing from a different angle — the plan was missing work, and two steps were in an order that would have broken the live site.
WORK THAT WAS SIMPLY MISSING
ORDERING THAT WOULD HAVE BROKEN THE LIVE SITE
Each one ships on its own and leaves the site working. The one step that cannot be undone is LAST — everything before it is proved on throwaway accounts we create on the live site.
Be able to put everything back, know every account that exists, clean the data the rule cannot be enforced on, and switch off the buttons that could destroy money while we work.
estimate: done
IT DOES NOT PASS UNTIL
A snapshot from today restores identical; no uid holds two accounts; every account holder has a phone; every business carries its world; the destructive actions and the seeders that would undo it are all disabled.
reading the gate result…
Make the rule real at the database, not just in the interface: a phone can never open a second account, and a business can never change its world after approval.
estimate: 1-2 days
IT DOES NOT PASS UNTIL
On the test database a second account is REFUSED and a world change is REFUSED, while every shape a real seller writes today still passes — including a business whose world was only just filled in.
the gate is not written yet — so nothing here claims this phase passed
The whole site stops asking «which of my two accounts is active» and asks «what is this account». The switcher and the add-a-second-account path are deleted. An individual posting in both worlds is finished here too.
estimate: 3-4 days
IT DOES NOT PASS UNTIL
No server code reads the old switch anywhere; three BRAND-NEW accounts on the live site — a person, a showroom, an office — each publish a real ad that lands with the right owner, the right payment channel and on the right public page; the person publishes in BOTH worlds and each world spends its own coins.
the gate is not written yet — so nothing here claims this phase passed
A car showroom can only post, buy and be priced in cars. A property office only in property. No exceptions, including the doors that can be called without the site.
estimate: 1-2 days
IT DOES NOT PASS UNTIL
The car business is REFUSED a property plan and the office is refused a car plan on every money door — including the two callable straight over the internet — and the office's plan name and limits show real numbers instead of the zeros they show today.
the gate is not written yet — so nothing here claims this phase passed
The five demo showrooms nobody can sign into, the twenty ghost account paths a nightly job keeps recreating, and the database indexes nothing needs any more.
estimate: 1 day
IT DOES NOT PASS UNTIL
Zero ghost paths after the nightly job runs, every remaining account is one a real person can sign into, and nothing on the site broke when the unused indexes were dropped.
the gate is not written yet — so nothing here claims this phase passed
These were on the critical path in the first version. They are real work and worth doing — but the model is true without them, so holding the whole project behind them was my mistake, not a requirement.
Seller vocabulary polish56 sites
Making every seller badge, link and share button agree about showroom-vs-person. Worth doing, but the model is true without it — and the one piece that is actually BROKEN today (your «معرض» filter returning nothing) is being fixed now, on its own, not held behind this.
Admin tooling70 sites
The users list becoming one row per person, per-world revenue, the wallet desk reaching the property purse. Exactly ONE row of it is required for the model — approving a business must record its world — and that one moved into phase 3. The rest is dashboard comfort, and the dashboard has no login on production yet.
Stamping the type into the login token13 sites
You said yes to this, and it IS stronger — the security rules would enforce the account type themselves instead of trusting the browser. But I owe you the honest version I did not give before: the model works without it. Nothing in your five goals needs it. It is hardening, so it waits until the model is live.
The phone app is not on this list because it is not part of Teswa. Teswa is a website. A new app gets built later, from the site.
The sweep raised 77 questions. Most were the same question asked by different readers, and most were answered by the decision above. These six are the ones that actually change the work. My recommendation is marked — pick it or overrule it.
+965 99255194 is a car showroom AND a person. +965 50000000 is a property office AND a person. Under the new rule each keeps ONE.
why it matters: The losing side's ads change owner type. For your showroom that is about 28 ads.
An individual can now post in BOTH worlds. Today there are two separate purses — car coins and property coins.
why it matters: It decides whether a free car coin can be spent on a flat.
Those are buyer tools. A showroom is a seller — but its staff still browse.
why it matters: It decides what happens to the buyer data sitting on the side that gets retired.
Both sides hold favourites and view history. One listing is currently favourited TWICE by the same person, which inflates its public counter.
why it matters: View history hard-deletes past 50 rows on the next page view, so the merge has to trim deliberately or it silently loses the wrong ones.
Today the security rules cannot tell a dealer from a person — the type is in a document they cannot cheaply read. Putting it in the login token makes it enforceable and unforgeable.
why it matters: It is the difference between the rule being a convention and being a lock. We already do exactly this for admins.
A showroom page is teswa.net/showroom/IWvheUWl6XTTO7HaaN8qca9uivJ3 today. It could be /showroom/najoom-cars.
why it matters: This plan no longer needs to touch those links at all — so doing it now is a CHOICE, not a requirement. Bundling it back in re-adds the redirect risk we just removed.