Team section

The place your team takes its environment from. Instead of passing a file around over chat — which is what sharing a scenario does — the scenario lives in a catalogue and anyone adopts it when they need it.

The section only appears when a catalogue is configured. If you don’t see “Team” in the sidebar, nothing is missing from your installation: this project has no catalogue, and it is configured in aseptic.project.yml.

What you see

The list of what the team shares. Selecting an entry, the detail answers the two questions people ask before adopting anything:

• What it brings — how many services, how many mocks and how many start-up settings. If it only brings the scenario definition, it says so too.
• What is missing here — what this scenario needs and your machine doesn’t have yet: a database connection the package references, a credential with no value, a repository that isn’t in your workspace, or a micro registered on another branch.

That second list is the reason the detail exists. Adopting blindly and finding the gap when the scenario won’t start is exactly the time this saves.

Adopting

Adopt brings the scenario in and reconciles it with your catalogue without overwriting it: it is the same path as importing a file, with the same conflict policies.

When something is missing, the detail says so with the remedy alongside: which credential to define, which repository is still to be cloned, which branch each service was registered on. And if you would rather sort it out later, you can adopt anyway: the scenario lands in your catalogue and won’t start until you cover the gap, which beats not being able to bring it at all.

When the team changes it

Adopting leaves a thread: the scenario is annotated with the entry it came from and the exact version that was brought over. That is what lets the app say something it could not say before: this is no longer what the team shares.

In the list, every entry carries its state:

• Up to date — what is here is what the team publishes.
• Changed — someone republished it after it was adopted.
• (no mark) — it has not been brought to this machine yet.

Unmarked entries are the majority in a large catalogue, and that is why they carry no mark: if everything were marked, the one mark that asks for something would be lost among the rest.

Opening an entry that was already adopted, the detail adds What changes: which services differ from the ones here, and in which specific fields. And the button changes from Adopt to Update, because that is what it does: it rewrites the scenario that is already there, it does not leave a copy beside it. Adopting three times no longer produces “Payments QA”, “Payments QA (2)” and “Payments QA (3)”.

What gets compared is the content, so republishing the same thing does not count as a change. A warning that fires when nobody has touched anything soon stops being read, and with it the one that does matter.

If someone removes an entry from the catalogue, the scenario that came from it keeps working here — but the section says so at the top, rather than letting it vanish quietly: there is no longer anyone behind it who will update it.

Publishing

Share with the team… in a scenario’s own menu, or Publish a scenario… from the section header, makes it available to the whole team, with one line explaining what it is for. That line is what people will see in the list, so it is worth writing.

Your local start-up layer does not travel. The flags and variables you use to bring a micro up are yours and needn’t hold on someone else’s machine; what gets published is the scenario, its manifests and its mocks.

Withdrawing an entry removes it from the whole team’s catalogue, not just yours. That is why it asks for confirmation: you are not deleting something of your own.

The team key

When the catalogue is hosted, it is end-to-end encrypted: what the server stores are blobs the server cannot open. The key belongs to the team and never leaves its machines.

You generate it once — Generate a new key — and paste it on the other machines — Enter the team key. The app asks you to repeat it when saving, which is how it checks you really have copied it somewhere before moving on.

It is worth reading the warning next to the button and believing it: if the team loses the key, the catalogue cannot be recovered. There is no reset that helps, because nobody else has it. Its place is wherever the team keeps its other secrets.

A catalogue served over Git needs no key: there, access control is the repository’s own.

The same thing from the terminal

All of this exists in the CLI too, which is what lets you build the environment in a continuous integration job or on the machine of someone who just joined:

aseptic team list                     # what the team shares
aseptic team status                   # still what the team shares?
aseptic team adopt pagos-qa --apply   # bring it in and adopt it here
aseptic start "Pagos QA"

Without --apply, adopt only prints the plan and what is missing on this machine — the same list the section’s detail shows. Full detail in CLI commands.

What this is not

It is not a place to keep your micros’ code: repos are still repos. What gets shared is how they combine — which micros, in which mode, with which mocks and which dependencies resolved — which is precisely what doesn’t fit in a README and ends up being passed on by word of mouth.