2026-10-06 — PersonalNuGetServer MSIX build & staging

Factory task: build first (well, latest) msixupload for Personal NuGet Server (9N0BQQ66022P,

psalmsoftsolutions profile) and stage it to the onboarding shelf.

What happened

• Claimed machine-204 (featureflags), preflight: git checkout -- . + git pull + killed

devenv/MSBuild/xhost. Checkout was already at f91019299 (origin/main head).

• Ran the full rules-review grep block on PersonalNuGetServerPage* before building — clean.

Two command x:Binds without Mode= are fine (fleet-wide convention, OneTime is correct for

commands). BoolToColorConverter_LimeGreen-Gray verified unconditional in FuncConverterX

(line 1760). TCP debug port 19250 unique. keywords.txt clean in all 14 languages.

• build-msix.ps1 PersonalNuGetServer → BUILD_EXIT_CODE=0 on attempt 1. 111.6 MB,

identity 4863AmazingNetwork.PersonalNuGetServer, version 2026.820.642.0 (matches matrix

pkg_ver — onboarding shape keeps the version as-is).

• MSBuild took ~25 min wall clock including the xhost XAML pass and the ffmpeg-pause guard on .3.

I polled the log a LOT during this (a bit too much — the machine was fine, just slow).

• Released the box immediately after the build finished.
• Staged to C:\packages_onboarding\pending\, recorded

SCORPIOX_PLATFORM_LASTBUILTCOMMIT_9N0BQQ66022P=f91019299, emitted onboardingchanged.

The published-app shape again

9N0BQQ66022P is already published with no pending submission, so the onboarding orchestrator

correctly refused to move the package ("no app has a pending submission"). Same shape as

PersonalHostsEditor / AICocktailsMaster / FastHexEditor. Copied the package to

C:\packages_update\pending\ and emitted packageupdate — the update lane is the one that

actually moves it. The orchestrator picked it up within a minute (moved to uploading\,

dispatched the DOM worker).

The one wrinkle

The DOM worker sat on login.microsoftonline.com "Sign in" for 30+ minutes, polling with

growing sleeps but never entering credentials. This is the same stale-ESTSAUTHPERSISTENT root

cause already tracked in WI #8905 — commented there instead of raising a duplicate. The package

is safe in uploading\ (workers never re-process, files never get lost in that state).

Lesson: the "success" of my task is build+stage+record+emit+release. Whether the DOM chain

finishes is a different lane with its own orchestrators and keep-it-going machinery. Don't burn

an hour polling a worker whose stall is a known, already-tracked infra bug — record the WI

comment and hand it over.