diff --git a/README.md b/README.md
index c1a7897..0373ea2 100644
--- a/README.md
+++ b/README.md
@@ -546,7 +546,12 @@ desktop job. Pins and import have no phone screen either, and importing an `~/.s
 on a phone at all. **VAULTS does have one**, behind MORE, and it is there for a reason the design could not
 have anticipated: a vault arrives without being asked for — somebody wraps its key to you — so the person
 it arrives for is at least as likely to be holding a phone as sitting at a desktop, and a membership
-visible only on a head they have not installed is a membership they cannot see.
+visible only on a head they have not installed is a membership they cannot see. **Somebody can be added to
+a vault from the phone too**, with the same box, the same role and the same sentence about what adding does
+not do — and if that phone can open the vault, it wraps the key in the same press. What the phone still
+does not draw is anything that takes access away: REMOVE and WITHDRAW KEY act on the first press, and an
+irreversible revocation under a thumb with its explanation in a tooltip nothing can show is the wrong
+trade.
 
 **Port forwarding is not built anywhere**, and the phone's More screen says so in a paragraph rather than
 leaving a gap. The v2 design draws a whole screen for it; nothing in the SSH layer forwards anything, so
diff --git a/docs/design-import-gaps.md b/docs/design-import-gaps.md
index b0c0258..6e3ab79 100644
--- a/docs/design-import-gaps.md
+++ b/docs/design-import-gaps.md
@@ -30,7 +30,8 @@ the chrome, hosts and terminals, file transfer, the vault, teams, and preference
 > SFTP and S3 are one screen over one `TransfersViewModel`, differing only in which picker they offer.
 >
 > **A sixth is behind MORE that v2 never drew: VAULTS.** It is the reverse case — a shipped screen the
-> design had no slot for — and it is on the phone because a vault arrives without being asked for.
+> design had no slot for — and it is on the phone because a vault arrives without being asked for, and
+> because somebody can be let into one from there.
 > Somebody wraps its key to you from their machine, and the person it arrives for is at least as likely to
 > be holding a phone as sitting at a desktop; a vault the server has just put somebody in, visible only on
 > a head they may not have installed, is a membership they cannot see. It runs over the same view model
diff --git a/docs/manual-checks.md b/docs/manual-checks.md
index 4720de2..630b734 100644
--- a/docs/manual-checks.md
+++ b/docs/manual-checks.md
@@ -1427,6 +1427,29 @@ instead — distinct from the "no account here" refusal in 12.1, because the two
 **Failure means:** the two refusals reading alike leaves somebody checking what they typed when the answer
 is that the person is already in.
 
+### 12.4 Somebody can be added from the phone, and the key goes with them · **needs a device and two accounts**
+
+On the phone: Settings → Vaults, choose a shared vault this account administers.
+
+**Pass:** under the members list there is an ADD SOMEBODY box, three role chips with MEMBER lit, an ADD
+button, and a paragraph saying that adding lets the server serve them and does not let them read anything.
+On a vault this account only belongs to, none of that is drawn at all — not greyed, absent.
+
+Type a colleague's address and press ADD, with the phone unlocked.
+
+**Pass:** they appear in the members list, and the status line says both halves — that they were added, and
+what happened to the key. On an unlocked phone that holds the vault key it says it shared it; the colleague
+syncs and the vault opens.
+
+Now lock the phone's keychain and add somebody else.
+
+**Pass:** it refuses to pretend. The membership is made and the line says the key could not be wrapped
+because this keychain is locked — which is a state somebody can act on, unlike silence.
+
+**Failure means:** a screen that adds somebody and says nothing about the key is implying the server can
+hand out access, which is the one claim this product exists to refuse. ADD drawn for a plain member is a
+button whose only outcome is a 403 from the server.
+
 ### 12.5 LAST ACTIVE is a real time, and a coarse one · **needs a couple of hours**
 
 Use one account and leave the other idle for two or three hours, then read the members table.
diff --git a/src/DodoSSH.Client.Android/Views/VaultsScreen.axaml b/src/DodoSSH.Client.Android/Views/VaultsScreen.axaml
index 87290d8..e2dd024 100644
--- a/src/DodoSSH.Client.Android/Views/VaultsScreen.axaml
+++ b/src/DodoSSH.Client.Android/Views/VaultsScreen.axaml
@@ -2,6 +2,7 @@
              xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
              xmlns:vm="using:DodoSSH.Client.Shell.ViewModels"
              xmlns:views="using:DodoSSH.Client.Android.Views"
+             xmlns:contracts="using:DodoSSH.Contracts"
              x:Class="DodoSSH.Client.Android.Views.VaultsScreen"
              x:DataType="vm:VaultsViewModel"
              Background="{StaticResource Canvas}">
@@ -45,11 +46,22 @@
     plainer reason: it decides who controls the vault, which is not a thing to do while walking. Nor is
     renaming, which is a keyboard on a screen that is otherwise all reading.
 
-    **ADD is not drawn either**, and it is the operation this screen least needs. It is an address typed
-    into a box, a directory lookup, a role picker, and a paragraph beside it saying what adding somebody
-    did *not* do — five controls for the one act on this screen that a colleague at a desktop is already
-    doing. Making a vault is here, because it is one field and because it is what a person carrying a
-    phone can usefully start.
+    ◆ **ADD is drawn, where it was not.** The argument against it was that it is an address typed into a
+    box, a directory lookup, a role picker and a paragraph saying what adding somebody did *not* do — five
+    controls for an act a colleague at a desktop is already performing. That was a cost argument and it was
+    wrong about who is holding what: the person who needs to let a colleague into a vault is often the one
+    away from their desk, and telling them to go and find one is the same answer this head exists to stop
+    giving. Making a vault was already here on exactly that reasoning.
+
+    What it costs is four rows under the members list rather than five controls, because three of them are
+    the role and are chips rather than a picker — the same chips the host editor wears for tags, so the
+    choice is visible without being opened. It is gated on being able to administer the vault, so on a
+    membership where the answer would be a refusal there is nothing to press.
+
+    **The paragraph comes with it and is not the optional part.** Adding somebody is a change to what the
+    server will serve and nothing else; the key still has to be wrapped from a machine that holds it, which
+    on this head is the bar below. A screen that offered the first and stayed quiet about the second would
+    be implying the server can hand out access, which is the one claim this product is built to refuse.
 
     **The key-holder list is not drawn.** It is a third list, and what the phone can answer about a vault
     is the more useful half of the same question and is on the vault's own row: whether *this* machine can
@@ -243,6 +255,64 @@
             <TextBlock Classes="body" Margin="18,10,18,0"
                        Text="Being in a vault is what lets the server hand somebody its rows. It is not what lets them read one: a vault key can only be wrapped by a machine that already holds it, which is what sharing below does." />
 
+            <!-- ============ ◆ adding somebody ============ -->
+            <!--
+              In the scrolling column rather than in the bar at the foot, and that is deliberate. The bar is
+              raised by choosing a *member* and is about that member; this is about the vault and is
+              available with nobody chosen at all, so putting it there would mean selecting somebody in
+              order to add somebody else.
+
+              Only for an admin or the owner. The server refuses anybody else and says so, but a box and a
+              button that exist to produce that refusal are worse than an absence — see
+              VaultsViewModel.CanAdministerSelected, which is the same gate the desktop uses.
+
+              The role is three chips rather than a ComboBox, matching the tag chips in the host editor: the
+              answer is one of three short words, and a picker would hide two of them behind a tap. Member
+              is the default because it is what adding a colleague almost always means; viewer would be
+              safer and would be the wrong default, since an interface whose default is wrong teaches people
+              to change it without reading it.
+            -->
+            <StackPanel IsVisible="{Binding CanAdministerSelected}" Spacing="8" Margin="18,18,18,0">
+
+              <TextBlock Classes="section" Text="ADD SOMEBODY" />
+
+              <TextBox Classes="field" Text="{Binding NewMemberEmail}"
+                       PlaceholderText="colleague@example.com" />
+
+              <TextBlock Classes="label" Text="THEY ARRIVE AS" Margin="0,2,0,0" />
+
+              <StackPanel Orientation="Horizontal" Spacing="6">
+                <Button Classes="chiptoggle" Classes.worn="{Binding AddsAsViewer}"
+                        Command="{Binding ChooseNewMemberRoleCommand}"
+                        CommandParameter="{x:Static contracts:TeamMemberRole.Viewer}">
+                  <TextBlock Classes="mono" FontSize="11.5" Text="VIEWER" />
+                </Button>
+                <Button Classes="chiptoggle" Classes.worn="{Binding AddsAsMember}"
+                        Command="{Binding ChooseNewMemberRoleCommand}"
+                        CommandParameter="{x:Static contracts:TeamMemberRole.Member}">
+                  <TextBlock Classes="mono" FontSize="11.5" Text="MEMBER" />
+                </Button>
+                <Button Classes="chiptoggle" Classes.worn="{Binding AddsAsAdmin}"
+                        Command="{Binding ChooseNewMemberRoleCommand}"
+                        CommandParameter="{x:Static contracts:TeamMemberRole.Admin}">
+                  <TextBlock Classes="mono" FontSize="11.5" Text="ADMIN" />
+                </Button>
+              </StackPanel>
+
+              <Button Classes="primary" Height="44" Content="ADD"
+                      Command="{Binding AddMemberCommand}" IsEnabled="{Binding !IsBusy}" />
+
+              <!--
+                The half of the act the server cannot perform, said before it happens rather than discovered
+                afterwards. Adding somebody from this phone wraps every vault key this phone can open to
+                them as part of the same command — so on an unlocked handset it is one press, and on a
+                locked one it is a membership and an owed key, which the status line then says.
+              -->
+              <TextBlock Classes="body"
+                         Text="Adding somebody lets the server serve them this vault. It does not let them read it: a vault key is wrapped by a machine that already holds one, so this phone does that too if it can open the vault. An account that has never signed in to this server cannot be added — ask them to sign in once first." />
+
+            </StackPanel>
+
           </StackPanel>
 
         </StackPanel>