Let a vault be shared from the phone, not only read there

This screen's own comment argued ADD out: an address typed into a box, a
directory lookup, a role picker and a paragraph saying what adding somebody did
not do, 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 somebody into a vault is often the one away from their desk, and
answering them with "go and find a desktop" is the thing this head exists to stop
doing. Making a vault was already here on exactly that reasoning.

Nothing shared changed — AddMemberCommand, the role and the chips are the same
members the desktop binds — so what this is, is markup and the argument it
reverses. Four rows under the members list: the box, three role chips rather than
a picker because the answer is one of three short words, ADD, and the paragraph.
Gated on being able to administer the vault, so a plain member sees nothing
rather than a button whose only outcome is a 403.

The paragraph is not the optional part. Adding somebody changes what the server
will serve and nothing else; the key is still wrapped by a machine that holds one
— which on an unlocked phone is this one, in the same press. A screen that
offered the first and stayed quiet about the second would imply the server can
hand out access, which is the single claim this product is built to refuse.

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 no touch screen can show is the wrong trade —
which is the line this file already drew and this does not move.

Check 12.4 walks it, including the locked-keychain case: the membership is made
and the line says the key could not be wrapped, which is a state somebody can act
on rather than silence.

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

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

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.

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
+    ◆ **ADD is drawn, where it was not.** The argument against it was that it is an address typed into a
-    into a box, a directory lookup, a role picker, and a paragraph beside it saying what adding somebody
+    box, a directory lookup, a role picker and a paragraph saying what adding somebody did *not* do — five
-    did *not* do — five controls for the one act on this screen that a colleague at a desktop is already
+    controls for an act a colleague at a desktop is already performing. That was a cost argument and it was
-    doing. Making a vault is here, because it is one field and because it is what a person carrying a
+    wrong about who is holding what: the person who needs to let a colleague into a vault is often the one
-    phone can usefully start.
+    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>