Give the desktop a nightly channel, the way the phone has one

ADR 0014 gave the phone a nightly and ADR 0013 rule 3 gave the desktop none, so
the two heads had different answers to the same question — how does somebody try
what is on main? — for no reason except the order the work happened in. This is
the desktop's answer: CI publishes a build from main on every push, and it
installs beside the release one rather than over it.

The phone gets its separation from the platform. Android refuses an update signed
by a different key, so its two channels cannot replace one another whatever
anybody does. Nothing refuses anything here: Velopack applies what its feed serves
and verifies no signature. So all of it is construction, and there are four
separations because each closes a different door.

A pack id each, so the two install in different directories and neither feed's
package can be applied to the other's install. A Velopack channel each —
win and win-nightly — so neither build ever reads the other's release index; the
name reaches the wire as releases.win-nightly.json, which is why the constant in
VelopackUpdateChannel and the argument in ci.yml have to agree or the channel
answers nothing forever with no error. A prerelease flag, so the release channel
cannot see the nightly even by accident. And a profile directory each, which is
the one that is easy to skip and would hurt most: the cache schema is migrated on
every launch, before unlock, so a shared profile means a nightly quietly upgrading
a database the release build then opens. Both are installed at once by design, so
that is an ordinary Tuesday rather than a corner case.

The prerelease flag turns out to be load-bearing across heads as well. The phone's
release channel reads releases/latest, which skips prereleases — so a desktop
nightly published as a stable release would become the newest release in this
repository and every phone on the release channel would start failing its check
against a release carrying no Android manifest.

Which build this is arrives as assembly metadata, the same mechanism and the same
reasoning as the Android head: the updater needs the string rather than a branch,
and a value baked into the assembly is one a crash report can be asked for. Three
things read it — the feed, the prerelease flag, and the profile — and one more
shows it: the titlebar says DodoSSH Nightly. Everything else that distinguishes
the two is somewhere nobody is looking while typing a passphrase into one of them.

The version needed a floor and it is applied to the whole build rather than to the
packaging. MinVer answers 0.0.0-alpha.0.N until the first v* tag and vpk refuses
anything below 0.0.1, so the job lifts the patch digit and keeps the height —
through MinVerVersionOverride, so the assemblies carry the same number the
installer does. Packing a version the assembly disagreed with would put one string
on the preferences screen and another in the feed, which is the screen somebody
reads when asked which nightly they are on.

Two things found by running it rather than reading it. -t:MinVer needs a restore
first, because the target arrives with the package and MSB4057 on a clean checkout
reads like a typo in the workflow rather than a missing restore; the release
script had the same gap and now restores before it reads. And vpk rejects an empty
--packVersion loudly, which is how a broken version handoff announces itself
rather than shipping a package called 1.0.0.

Rule 3 is untouched. The release channel still has no job, no token and no runner,
and the two channels cannot see each other. What a nightly costs is written where
somebody reads it before installing one: whoever can write a release here can put
a build on every nightly machine, which is fine for a build being tried and is not
fine for a build holding somebody's infrastructure credentials.

Verified by running the job's own steps against a clone in a Linux container:
DodoSSH.Desktop.Nightly-win-nightly-Setup.exe, and an index naming pack id
DodoSSH.Desktop.Nightly at 0.0.1-alpha.0.144. The upload itself is the one step
not exercised — it needs a real forge and a write token, and check 16.10 is what
walks the half no runner can.

src/DodoSSH.Client.App/App.axaml.cs

@@ -92,7 +92,10 @@ internal sealed partial class DodoSshApp : Application
 
     private static void Compose(IClassicDesktopStyleApplicationLifetime desktop)
     {
-        var paths = ClientPaths.Default;
+        // ForChannel rather than Default, so a nightly keeps its cache, outbox and device key somewhere
+        // the release build never opens. See ClientPaths.ForChannel for why sharing them is the failure
+        // worth spending a directory on.
+        var paths = ClientPaths.ForChannel(DesktopChannel.Name);
         var caches = ClientCacheFactory.ForFile(paths.CacheFile);
 
         // Known hosts live in the vault, so trust survives a restart and follows the user to every device.

src/DodoSSH.Client.App/DodoSSH.Client.App.csproj

@@ -42,6 +42,30 @@
     -->
     <ApplicationIcon>Assets/dodossh.ico</ApplicationIcon>
 
+    <!--
+      ============ WHICH CHANNEL THIS BUILD BELONGS TO ============
+
+      The same split the Android head has, for the same reason and with one difference worth stating up
+      front: Android gets separation for free, because the platform refuses an update signed by a
+      different key, so its two channels cannot replace one another whatever anybody does. Nothing
+      refuses anything here. Velopack applies what its feed serves, so the separation has to be built:
+      two pack ids, two Velopack channels, two feeds, and a profile directory each.
+
+      release — DodoSSH.Desktop, Velopack channel win, read from the newest non-prerelease release.
+                Cut from a v* tag by scripts/release-windows.ps1, by a person. See ADR 0013 rule 3.
+      nightly — DodoSSH.Desktop.Nightly, Velopack channel win-nightly, read from a prerelease release
+                CI replaces on every push to main.
+
+      Default release, so an unqualified `dotnet build` is the real application and the nightly is the
+      one you have to ask for.
+
+      What this property does *not* decide is the pack id or the title. Those are arguments to vpk and
+      live where the packaging happens — in ci.yml for the nightly and in the release script for the
+      release. Putting them here would suggest the build knows which package it will end up inside,
+      and it does not.
+    -->
+    <DodoChannel Condition="'$(DodoChannel)' == ''">release</DodoChannel>
+
     <!--
       False here, unlike every server project. The root Directory.Build.props sets it true because
       the API is container-hosted, UTC-only and has no business formatting anything for a human.
@@ -60,6 +84,16 @@
     <AvaloniaResource Include="Assets/dodossh.ico" />
   </ItemGroup>
 
+  <ItemGroup>
+    <!--
+      Which channel this build belongs to, carried in the assembly the same way the Android head carries
+      it. Metadata rather than a compile-time constant for the reason stated there: the updater needs the
+      string rather than a branch, and a value baked into the assembly is one a crash report can be asked
+      for. See DesktopChannel, which is the only thing that reads it.
+    -->
+    <AssemblyMetadata Include="DodoChannel" Value="$(DodoChannel)" />
+  </ItemGroup>
+
   <!--
     Two native symbol files, and they are the reason a self-contained publish weighed 227 MB.
 

src/DodoSSH.Client.App/Platform/DesktopChannel.cs

@@ -0,0 +1,66 @@
+using System.Reflection;
+
+namespace DodoSSH.Client.App.Platform;
+
+/// <summary>
+/// Which of the two desktop channels this build belongs to.
+/// </summary>
+/// <remarks>
+/// <para>
+/// The counterpart of the Android head's <c>DodoChannel</c> metadata, read the same way and for the same
+/// reasons. Three things depend on the answer and they are listed here rather than discovered one at a
+/// time: which Velopack channel the updater reads, whether that read considers prereleases, and which
+/// profile directory this copy keeps its cache and device key in.
+/// </para>
+/// <para>
+/// <b>Android gets this separation from the platform and this head has to build it.</b> Two Android
+/// channels cannot replace one another because the installer refuses a package signed by a different key.
+/// Nothing refuses anything on Windows: Velopack applies what its feed serves, without verifying a
+/// signature. So the two channels are kept apart by construction here — a pack id each, so they install
+/// in different directories; a Velopack channel each, so neither ever reads the other's release index; and
+/// a profile directory each, so a nightly cannot migrate the schema of a cache the release build is using.
+/// See <c>docs/adr/0013-desktop-distribution-and-updates.md</c> rule 9.
+/// </para>
+/// <para>
+/// Resolved once, at first use. The channel of a build does not change while it runs, and a value read
+/// per call site is one that eventually gets read differently in two places.
+/// </para>
+/// </remarks>
+internal static class DesktopChannel
+{
+    /// <summary>The build this channel is not: the one a person cuts from a tag.</summary>
+    internal const string Release = "release";
+
+    /// <summary>The build CI publishes from main, which installs beside the release one.</summary>
+    internal const string Nightly = "nightly";
+
+    /// <summary>
+    /// What this build says it is, defaulting to the release channel.
+    /// </summary>
+    /// <remarks>
+    /// The csproj always writes the metadata, so the fallback covers a build that reached here some other
+    /// way — an assembly loaded by a test host, a designer, a trimmed-down copy. <see cref="Release"/> is
+    /// the safe answer for all of them: it is what the value was before there were two channels, and every
+    /// consequence of being wrong about it is inert. A build that is not installed has no updater at all
+    /// (see <c>UpdateChannels.ForThisMachine</c>), and the profile directory it names is the one every
+    /// existing install already uses.
+    /// </remarks>
+    internal static string Name { get; } = Read();
+
+    /// <summary>Whether this build belongs to the nightly channel.</summary>
+    internal static bool IsNightly => string.Equals(Name, Nightly, StringComparison.Ordinal);
+
+    private static string Read()
+    {
+        var declared = typeof(DesktopChannel).Assembly
+            .GetCustomAttributes<AssemblyMetadataAttribute>()
+            .FirstOrDefault(attribute => string.Equals(attribute.Key, "DodoChannel", StringComparison.Ordinal))
+            ?.Value;
+
+        // Only the two the csproj declares are honoured. An unrecognised value is a build made by
+        // something nobody here wrote, and answering "release" to it is the same inert default as
+        // answering it to no value at all — rather than pointing an updater at a feed named by a string
+        // of unknown origin.
+        return string.Equals(declared, Nightly, StringComparison.Ordinal) ? Nightly : Release;
+    }
+}

src/DodoSSH.Client.App/Platform/VelopackUpdateChannel.cs

@@ -105,6 +105,25 @@ internal sealed class VelopackUpdateChannel : IUpdateChannel
     /// </remarks>
     private const string ReleaseChannel = "win";
 
+    /// <summary>
+    /// The nightly channel, which is a different name rather than the same one on a different tag.
+    /// </summary>
+    /// <remarks>
+    /// <para>
+    /// A contract with the <c>desktop nightly</c> job in <c>.github/workflows/ci.yml</c>, which passes
+    /// this word to both <c>vpk pack</c> and <c>vpk upload</c>. The name reaches the wire: Velopack
+    /// publishes its index as <c>releases.win-nightly.json</c> and looks for exactly that file, so a
+    /// disagreement between the two sides is a channel that answers nothing, forever, without an error.
+    /// </para>
+    /// <para>
+    /// <b>Two names rather than one name on two tags, and that is the part doing the work.</b> Both
+    /// channels are published to the same repository, so a client that read the other's index could be
+    /// offered a package built under a different pack id. Velopack would refuse it, but at the far end of
+    /// a download somebody watched. A channel each means neither ever sees the other's releases at all.
+    /// </para>
+    /// </remarks>
+    private const string NightlyChannel = "win-nightly";
+
     private readonly UpdateManager manager;
 
     /// <summary>
@@ -138,10 +157,34 @@ internal sealed class VelopackUpdateChannel : IUpdateChannel
     /// </remarks>
     public string CurrentVersion => ClientVersion.Current;
 
-    internal static UpdateManager CreateManager() =>
-        new(
-            new GiteaSource(RepositoryUrl, accessToken: null, prerelease: false),
-            new UpdateOptions { ExplicitChannel = ReleaseChannel });
+    /// <summary>
+    /// The updater for this build's channel.
+    /// </summary>
+    /// <remarks>
+    /// <para>
+    /// <b>The prerelease flag is the half Velopack cannot work out for itself.</b> The channel could be
+    /// left to the installed layout — Velopack records what a package was built with — but whether to
+    /// consider prereleases is a property of the feed rather than of the install, and it decides more
+    /// than it looks. The nightly is published as a prerelease deliberately: the Android head's release
+    /// channel reads <c>releases/latest</c>, which skips prereleases, so a desktop nightly published as a
+    /// stable release would become the newest release in this repository and the phone's release channel
+    /// would start finding no Android manifest on it. One flag here keeps the two heads out of each
+    /// other's way.
+    /// </para>
+    /// <para>
+    /// The release channel takes <c>false</c>, so it cannot see the nightly at all — which is the property
+    /// that matters most, because that is the direction where a mistake would put an unsigned CI build on
+    /// a machine somebody trusts with their credentials.
+    /// </para>
+    /// </remarks>
+    internal static UpdateManager CreateManager()
+    {
+        var nightly = DesktopChannel.IsNightly;
+
+        return new UpdateManager(
+            new GiteaSource(RepositoryUrl, accessToken: null, prerelease: nightly),
+            new UpdateOptions { ExplicitChannel = nightly ? NightlyChannel : ReleaseChannel });
+    }
 
     /// <inheritdoc />
     public async Task<AvailableUpdate?> CheckAsync(CancellationToken cancellationToken)

src/DodoSSH.Client.App/Program.cs

@@ -1,5 +1,6 @@
 using Avalonia;
 using Avalonia.Media;
+using DodoSSH.Client.App.Platform;
 using DodoSSH.Client.Session;
 using Velopack;
 
@@ -69,7 +70,12 @@ internal static class Program
             return;
         }
 
-        var folder = Path.Combine(ClientPaths.Default.DataDirectory, "WebView2");
+        // The same profile directory the rest of the application resolves, channel and all — a nightly
+        // pointing WebView2 at the release build's profile would put two browser profiles in one folder
+        // and hand the pair of them whichever process opened first.
+        var folder = Path.Combine(
+            ClientPaths.ForChannel(DesktopChannel.Name).DataDirectory,
+            "WebView2");
 
         try
         {

src/DodoSSH.Client.App/Views/TitleBar.axaml

@@ -37,7 +37,11 @@
           The product's name is the one string in this bar that is not machine-shaped, so v2 sets it in the
           sans face while the address, the account and the fingerprint beside it stay monospaced.
         -->
-        <TextBlock Text="DodoSSH" FontSize="14" FontWeight="SemiBold"
+        <!--
+          Named, because a nightly says so here. See the code-behind: the release build is what this
+          markup says and nothing changes for it.
+        -->
+        <TextBlock x:Name="ProductName" Text="DodoSSH" FontSize="14" FontWeight="SemiBold"
                    Foreground="{StaticResource Text}" VerticalAlignment="Center" />
         <!--
           The design puts an organisation here — "dodotech / platform". There are no organisations: the

src/DodoSSH.Client.App/Views/TitleBar.axaml.cs

@@ -1,6 +1,7 @@
 using Avalonia.Controls;
 using Avalonia.Input;
 using Avalonia.Interactivity;
+using DodoSSH.Client.App.Platform;
 
 namespace DodoSSH.Client.App.Views;
 
@@ -21,7 +22,24 @@ namespace DodoSSH.Client.App.Views;
 /// </remarks>
 internal sealed partial class TitleBar : UserControl
 {
-    public TitleBar() => InitializeComponent();
+    public TitleBar()
+    {
+        InitializeComponent();
+
+        // ◆ A nightly says which one it is, in the one place a person is always looking at.
+        //
+        // The two channels install side by side on purpose, so both windows are on screen at once, both
+        // are called DodoSSH, and both ask for a passphrase the same way. Everything else that
+        // distinguishes them — the Start menu entry, the install directory, the version on the
+        // preferences screen — is somewhere nobody is looking while typing into one of them.
+        //
+        // Set here rather than in the markup so the release build is exactly what the XAML says, and so
+        // the layout harness, which hosts this control directly, measures the shipping string.
+        if (DesktopChannel.IsNightly)
+        {
+            ProductName.Text = "DodoSSH Nightly";
+        }
+    }
 
     private Window? Host => TopLevel.GetTopLevel(this) as Window;