Architect layer
Sign-in
How a person gets into this project: which doors are open, who opens them, and what each door needs in order to work.
About
How signing in is arranged in this project and what decides which methods appear.
What this page controls. Which ways in your visitors see on the public sign-in page. The authorization layer itself always exists — you are enabling doors in it, not building a login.
What else can be a way in
The sign-in service is built on Auth.js (next-auth) 5.0.0-beta.31, and that substrate knows 104 providers. Three of them are wired here — they are marked green below. The rest exist and work; what they lack is the wiring: keys, a redirect address and a button on the sign-in page.
The list is a snapshot of the installed package taken on 2026-09-01 — the sign-in service lives beside this project rather than inside it, so the page cannot count them live.
Need one of these, or something not on the list? Write to Fractera support: admin@fractera.ai
Roles that already exist
Roles are not built for a project — they are already there. Fifteen names, and they split in two, because only one half is enforced by the substrate itself.
Three access tiers — these the substrate enforces
A guest is the absence of a session, a user is any signed-in person, and the architect is the owner of this deployment. The architect belongs to every protected group by construction: the owner of a server is never locked out of his own application — which is also why a screen that works for you may refuse everybody else.
Twelve more — the vocabulary your application gates on
These do not stop anyone by themselves: they are names your code and doors ask about. A page shows its data when the door asks for the role, not when the menu hides the link.
The guest role, and why it exists
Some things need to know WHO is doing them before the person is willing to say who they are: a cart being filled, a conversation with an AI assistant, a form half completed. Ask for an email first and you lose the person at the moment they were closest to staying.
So the sign-in service can issue a real session without asking for anything. It creates an account with the role `guest` and signs the visitor in — the cart and the chat get a stable identity from the first click, and the person notices nothing. Later, when they do sign in properly, the same session becomes theirs and what they collected stays.
This is already built and configured. Nothing has to be invented for it. What remains is to name the pages that should sign a visitor in automatically — say which ones, and they get it.
On localhost:3000 sign-in is ignored on purpose
Running the project on your own machine, you are always the architect: the session is issued without any check, with the email demo@local and the role architect. Since that role belongs to every protected group, every door in the application is open to you at once.
This is deliberate and it is what makes local work possible — otherwise you would have to sign in before every page you touch. The price is that a role gate cannot be TESTED here: everything works for everybody. To see what a manager or a guest actually sees, open the project on its own address, where the same code checks the session for real.