The guide

How Vespera works.

Four services, one account, and an assistant that can act inside all four. This page explains what each one does, how they are joined together, and exactly what the assistant is and is not allowed to do on your behalf.

01 The shape of the platform 02 Mirror, portfolios and CVs 03 Souk, shops and orders 04 Anchor, work and the assistant 05 What the assistant may touch 06 Writing and sending mail 07 The shared foundation

01

One account, four services, one foundation.

Vespera is not one product with four tabs. Each service is its own application with its own database tables, its own deploy and its own subdomain. What they share is the layer underneath: the same account, the same sign-in, the same AI gateway, the same media pipeline and the same design vocabulary.

That is what makes the assistant possible. Because Anchor talks to the same tables Mirror and Souk own, it can change a price or publish a portfolio without either service needing to expose a public API for it.

One Vespera account email, or Google sign-in Mirror Portfolios, CVs, project pages Published at a public address MIRROR.VSPERA.ME Souk Shops, products, orders Buyer and seller on one thread SOUK.VSPERA.ME Anchor Tasks, projects, notes, rooms The assistant, and mail ANCHOR.VSPERA.ME Atlas Study plans, whiteboard, guides Groups and projects ATLAS.VSPERA.ME Anchor writes into the others, through named actions Shared foundation Identity and sign-in · AI gateway · Media pipeline · Billing and plans · Design vocabulary
One account signs in everywhere. Anchor is the only service that writes into the others, and it does so through a fixed list of named actions rather than a general-purpose connection.

02 · Mirror

A portfolio that is designed, not filled in.

Mirror does not have templates you pick from. You give it what you have, a history, a list of projects, some images, a CV, and it produces a complete design specification for you: palette, type pairing, layout rhythm, section order, heading treatment. Two people in the same profession get two different sites.

The rule the generator follows is that structure follows content. A section exists only if there is something to put in it. Upload twenty photographs and nothing else and you get a gallery, not an empty "Experience" heading waiting to be filled.

What you have History, projects, images, a CV Analyser Reads what is actually there Layout engine Which sections, in what order Theme generator Palette, type, texture Blueprint One specification, unique to you Your site Editable, publishable Every stage has a deterministic fallback, so a model being slow or unavailable never leaves you with nothing.
The generated blueprint is a starting point, not a cage. Every section, every project and every design choice stays editable afterwards.
Portfolios
Sections for about, experience, education, skills, projects, galleries, files, links and contact. Sections you do not need are simply absent.
Project pages
Each project gets a page of its own with its own images, videos, files and outward links.
CV Studio
A CV built from the same content as the portfolio, so the two cannot drift apart.
Languages
A portfolio can carry several languages, with a default. The translation engine drafts them; you keep the edit.
Publishing
A public address per portfolio. Drafts stay private until you publish.
Its own domain
A portfolio can be published at a domain of its own, reading its content from Mirror as you edit it.

03 · Souk

A shop, and an order both sides can see.

Souk generates a storefront the same way Mirror generates a portfolio, then handles what comes after: a catalogue, stock, and orders that move through a sequence both the buyer and the seller are looking at.

Payment is declared, then confirmed. The buyer says they have paid; the seller confirms they have received it. Souk records both halves separately rather than pretending to know, because it is not a payment processor and should not claim to be one.

WITH THE SELLER pending → accepted → preparing → ready IN TRANSIT shipped → in transit → out for delivery DONE delivered → completed An order can close early declined · cancelled · disputed · refunded, each one recorded, none of them silent Payment, tracked separately pending → buyer declared → seller confirmed. Souk records what each side said; it does not take the money.
Thirteen states in total. The point of naming them all is that both sides always know which one an order is in, and none of the closing states happen quietly.
Storefront
Generated per seller, from the same design vocabulary Mirror uses, so it looks like part of the same platform without looking like the shop next door.
Products
Price, stock, visibility and featuring. Hiding a product keeps its history; deleting it would break the link from a past order back to the catalogue.
Orders
The lifecycle above, with the seller's board grouped by who is holding the goods.
Pages and leads
Landing pages that collect enquiries, which can be turned into a room in Anchor to work through.

04 · Anchor

Where the work is, and where the assistant lives.

Anchor is two things at once. It is a place to keep tasks, projects, notes and structured rooms of your own design. It is also the only service with hands: the assistant that can read across Mirror, Souk, Anchor and Atlas, and make changes in all four.

Asking it to "put the winter pieces on sale and add a task to photograph the new ones" is one sentence that becomes several changes in two different services. Everything below exists to make that safe.

You ask for something In ordinary words A batch is proposed Only from a fixed list of actions The guard reads the batch All of it, before any of it runs Judged on blast radius, not intent It runs Or it is refused The limits, per instruction At most 25 changes · at most 3 of them deletions · at most 20 creations A deletion must name its target: "delete everything" is refused outright Every executed change writes down what it replaced The previous value is captured before the new one is written, so "the assistant changed my prices" is always answerable, and an undo has something to restore. Ownership is enforced inside the database query, not checked in code around it.
The risk being defended against is not a malicious model. It is one ambiguous sentence fanning out into fifty deletions, so the rule is about how much a single instruction may change.
REFUSALS ARE EXPLAINED

You are told why

A refused instruction returns a plain explanation and says how many attempts remain, rather than failing quietly or doing part of the job.

REPEATED OVERREACH

Writing can be suspended

After three refusals the account loses assistant write access until an admin clears it. Reading, and the rest of Vespera, keep working.

NO ESCAPE HATCH

There is no "run anything"

If a capability is not on the list, the assistant cannot do it. A model that invents an action name gets an error, not a surprising side effect.

Tasks and projects
The ordinary kind, with statuses, grouped under projects.
Notes
Free text the assistant can read and add to.
Rooms
Structured collections you define: your own fields, your own layout, from a set of presets. Useful for anything that is a list of things with properties.
Memory
The assistant keeps what you tell it to keep about how you work and how you want to be addressed, and forgets on request.
Scout
Searches for opportunities against your profile and files what it finds.

05

Exactly what the assistant may touch.

This is the whole surface. Each item is a named action with a declared signature; there is nothing else it can reach, in any service.

IN MIRROR

Portfolios

Create and delete a portfolio. Edit its title, tagline, theme and details. Add, edit, reorder and remove sections. Create projects. Publish and unpublish.

IN SOUK

Shops and orders

Create a shop and edit its details and policies. Create products, change price and stock, feature, hide, activate and delete them. Move an order along, and list leads.

IN ANCHOR

Work

Create, edit and delete tasks and projects. Add notes. Create rooms, define their fields, and add, edit or remove items in them. Record a mood. Remember and forget.

Three things are true of every one of them. Ownership is enforced inside the database statement, so a bug in the calling code cannot reach another account's row: the query simply matches nothing. The previous value is recorded before the change. And the guard has already read the entire batch before the first action runs.

Some order steps cannot be walked back. Declining, cancelling and refunding return goods to the shelf, close the order and tell the buyer it is over. Those count against the deletion limit even though they are not deletions, because counting action names alone would let a batch of thirty refunds through.

06

Writing a hundred letters, one at a time.

Anchor can take a list of contacts and write a real letter to each one. Not one letter merged with fifty names: one model request per recipient, so each is written for the person receiving it, drawing on what you said about them.

Import a list Nothing saved until you have checked it Review the rows Name, address, country, language, your notes One request per letter Several written at once A rate limit is waited out, not treated as a failure PROGRESS IS LIVE You choose what goes out Read them, edit them, select them. There is no "send all". Nothing is written until you ask, and nothing is sent until you have picked the ones to send.
Progress is read from the letters themselves rather than from a counter, so it stays correct if you reload the page or open it somewhere else while a batch is running.
Language
Per recipient, or matched to their country. A French practice gets a French letter.
Signature
An HTML signature with a link to your Mirror portfolio, or your Souk shop when the letter is an offer of services rather than an application.
Sending
Through your own connected Gmail account, so replies come to you and the mail is genuinely from you.
From Telegram
Progress and counts can be read from the bot, which tells you once when a batch has finished writing.

07

What all four stand on.

Identity
One account and one sign-in for every service, by email or through Google. Moving between services does not ask you to sign in again.
The AI gateway
Every service asks for intelligence through the same layer, and every stage has a deterministic fallback. A model being slow, refusing, or unavailable degrades what you get; it does not break the page.
Your own model key
You may bring your own provider key. It is encrypted before it is stored, and it is used only for your own requests.
Media
Images and video are uploaded straight from your browser to the media host with a signature from Vespera. The file never passes through our API, and the signing secret never reaches your browser.
Design vocabulary
Palettes, type pairings, textures and frames are shared between Mirror and Souk, which is why a generated shop and a generated portfolio look related without looking the same.
Billing
A subscription per service, or one bundle covering all of them. The bundle satisfies every service, and the higher tier wins where both apply.

Google access is narrow and revocable. Signing in with Google asks only for who you are. Sending mail is a separate authorisation you grant later, and only if you want the outreach feature. Either can be withdrawn from your Google account without affecting the other.