Merge branch 'main' into claude/host-management-ui-plan-7f20ab

Seven files needed a hand. Most were two branches adding something in the same
place, but three were one branch changing what the other had moved or renamed,
and those are the ones worth reading.

The shell keeps both new fields and both constructor lines: the connection
recorder this branch built and the teams view model main did. Where main put a
teams load inside OnScreenChanged, it now sits beside the logs refresh rather
than inside RaiseSurfaceState — this branch extracted that notification block
and it is called from two properties, so a screen-specific side effect in there
would fire on every terminal switch as well.

Main gave four row types a vault id and a vault name, and this branch had moved
one of them — KnownHostRowViewModel — into its own file when the pinned keys
became a screen. Git resolved that as "deleted here, modified there" and took
the delete, which compiles as long as nobody looks: the moved copy still had
the two-argument constructor and the call site had grown to four. Carried over
by hand, along with the ordering the pins list now does on them.

The status line's quiet rule was the subtle one. Main extracted it into
IsWorthReporting; this branch had changed the same condition to read item
counts rather than raw ones, because every user action queues a log entry a
moment later and this machine reads its own entries back on the next pull. Take
main's structure and the merge builds, passes, and silently restores a bug this
branch existed partly to fix — every save's message overwritten a second after
it appears. The method now reads PulledItems and PushedItems, with the reason
in its remarks.

Two conflicts were prose that had gone stale rather than code. The keychain
screen's comment said team vaults are refused by the server's access service,
which was true when it was written and is not now; main's replacement stands,
in this branch's vocabulary. The design-gaps row for groups was claimed by both
— real host groups here, per-vault headings there — and they are different
things, so both rows stay and the difference is stated: a group is a shelf the
user chose, a vault is who can read the item.

One defect the tests found and the compiler could not. Generating a key opens
the same editor as pasting one, but not through NewKey — so it never set the
target vault main added, and a generated key was filed into whatever vault was
edited last, or none. Both key-generation tests failed on it. Fixed where the
editor opens, with the reason recorded there.

One gap is left deliberately and is written down rather than half-built. Hosts,
keys, credentials and pins are read across every vault this session holds a key
for; groups are read from the active vault alone, so a host a teammate filed
shows under UNGROUPED. Nothing is lost or misfiled — it is what the sidebar
already shows for a group that has been deleted — but closing it needs a vault
id on every group row for rename and delete, and a way to tell two vaults'
identically-named groups apart under a layout with one heading per group. Both
are worth doing and neither is a merge's business. It is in the remarks on
ReloadGroupsAsync and in docs/design-import-gaps.md.

dotnet build, dotnet test and dotnet format --verify-no-changes are all clean:
1282 tests, including the end-to-end suite against real containers.
This commit is contained in:
2026-07-31 20:44:39 +02:00
49 changed files with 6889 additions and 149 deletions
+90 -6
View File
@@ -26,6 +26,25 @@ public sealed record ConflictNotice(
IReadOnlyList<ConflictDetailEntry> Fields,
DateTimeOffset DetectedAt);
/// <summary>One vault's outcome from a pass over all of them.</summary>
/// <param name="VaultId">The vault.</param>
/// <param name="Name">Its display name, so a message about it can name it.</param>
/// <param name="Report">What the pass did, when it completed.</param>
/// <param name="Failure">
/// Why it did not, when it failed. Carried rather than thrown so one unreachable team vault cannot
/// leave the others unsynced — and reported rather than swallowed, because a vault that silently
/// stopped syncing is the worst of the three outcomes.
/// </param>
public sealed record VaultSyncReport(
Guid VaultId,
string Name,
SyncReport? Report,
Exception? Failure)
{
/// <summary>Whether this vault synced.</summary>
public bool Succeeded => Report is not null;
}
/// <summary>
/// An unlocked vault: the keys are in memory, the cache is open, and the hosts are readable.
/// </summary>
@@ -41,7 +60,7 @@ public sealed record ConflictNotice(
/// perfectly usable with no network at all and syncing is the occasional thing that needs one.
/// </para>
/// </remarks>
public sealed class VaultSession : IAsyncDisposable
public sealed partial class VaultSession : IAsyncDisposable
{
private readonly UserSecretBundle bundle;
private readonly LocalCacheProtector protector;
@@ -111,11 +130,28 @@ public sealed class VaultSession : IAsyncDisposable
public StoredUnlockMaterial Profile { get; }
/// <summary>Every vault this user can reach, readable or not.</summary>
public IReadOnlyList<StoredVault> Vaults { get; }
/// <remarks>
/// Re-read rather than fixed at unlock: a vault a teammate shares arrives mid-session, and one
/// whose grant is withdrawn stops being readable mid-session too. <see cref="RefreshVaultsAsync"/>
/// is what moves it, and it is the only thing that does.
/// </remarks>
public IReadOnlyList<StoredVault> Vaults { get; private set; }
/// <summary>The vault the interface is showing. The personal one, for now.</summary>
/// <summary>
/// The vault new items are created in.
/// </summary>
/// <remarks>
/// One vault is the write target, not the read set — reading spans every vault the keyring opened.
/// It stays the first readable one, which is the personal vault whenever there is one, because an
/// application that silently filed a new host into a team's vault because that was the last thing
/// selected would be the wrong default in the one direction that is hard to undo.
/// </remarks>
public Guid ActiveVaultId { get; }
/// <summary>Every vault this session actually holds a key for.</summary>
public IEnumerable<StoredVault> ReadableVaults =>
Vaults.Where(vault => keyring.CanRead(vault.VaultId));
/// <summary>Hosts, decrypted, with unpushed local changes laid over them.</summary>
public HostRepository Hosts { get; }
@@ -232,10 +268,14 @@ public sealed class VaultSession : IAsyncDisposable
return SignIn.ForgetAsync(cancellationToken);
}
/// <summary>Runs one synchronisation pass over the active vault.</summary>
/// <summary>Runs one synchronisation pass over one vault.</summary>
/// <param name="api">The transport. Supplied per call because a session outlives any one connection.</param>
/// <param name="vaultId">The vault to sync.</param>
/// <param name="cancellationToken">Cancellation token.</param>
public Task<SyncReport> SyncAsync(ISyncApi api, CancellationToken cancellationToken)
public Task<SyncReport> SyncAsync(
ISyncApi api,
Guid vaultId,
CancellationToken cancellationToken)
{
ObjectDisposedException.ThrowIf(disposed, this);
ArgumentNullException.ThrowIfNull(api);
@@ -243,7 +283,51 @@ public sealed class VaultSession : IAsyncDisposable
var engine = new SyncEngine(
api, Items, Outbox, SyncState, Conflicts, keyring, clock, options);
return engine.SyncAsync(ActiveVaultId, cancellationToken);
return engine.SyncAsync(vaultId, cancellationToken);
}
/// <summary>
/// Runs one synchronisation pass over every vault this session can read.
/// </summary>
/// <returns>One report per vault, in the order they were synced.</returns>
/// <remarks>
/// <para>
/// Sequential rather than concurrent. Each vault has its own cursor and its own outbox, so nothing
/// forces the order — but a client that opened one connection per vault would multiply its request
/// rate by the number of teams somebody is in, against a server the same person is also using
/// interactively. Vaults are few and passes are cheap.
/// </para>
/// <para>
/// A vault that throws does not stop the rest. One team's vault being unreachable — a revoked grant
/// noticed mid-pass, a server-side fault — is not a reason to leave the personal vault unsynced,
/// and the failure is reported per vault rather than as one exception naming none of them.
/// </para>
/// </remarks>
public async Task<IReadOnlyList<VaultSyncReport>> SyncAllAsync(
ISyncApi api,
CancellationToken cancellationToken)
{
ObjectDisposedException.ThrowIf(disposed, this);
ArgumentNullException.ThrowIfNull(api);
var reports = new List<VaultSyncReport>();
foreach (var vault in ReadableVaults.ToList())
{
try
{
var report = await SyncAsync(api, vault.VaultId, cancellationToken)
.ConfigureAwait(false);
reports.Add(new VaultSyncReport(vault.VaultId, vault.Name, report, null));
}
catch (Exception exception) when (exception is not OperationCanceledException)
{
reports.Add(new VaultSyncReport(vault.VaultId, vault.Name, null, exception));
}
}
return reports;
}
/// <summary>