2026-10-07 — PersonalIdentityServer MSIX: the sibling-break + stale-claim + published-app triple

Factory task: PersonalIdentityServer (9PCDRKXPPHWT, psalmsoftsolutions) build-first-msix. Auto-pilot,

83 rounds budget, finished in ~4.

Three things tried to stop this build

Stale claim. machine-204 was already held when I started — but by a claim from *an ended

session of my own agent* ("fast-vnc-viewer-keyinput — Pico (auto-pilot) — started 2026-10-06 20:05

NZST", committed 3902a2c4). The task it belonged to was sitting in pending/ blocked on DLL work,

and .204 was idle: clean worktree (only the 3 gen.ps1 artifacts a build leaves), no MSBuild.

Self-claim = stale claim. I released it and re-claimed with a fresh note. The claim skill says

"never reboot a box someone else claimed" — a dead session's flag isn't "someone else", but I

verified idleness (processes + worktree) before touching anything.

Sibling CS1009, fleet-wide. Attempt 1 died in the generator phase:

ScorpioPlayer2027Project.cs(32,121): error CS1009: Unrecognized escape sequence. Someone

(5874405a7, 19:25 UTC) had written TestResult = "... open C:\sp2027-e2e ..." into a Project.cs

attribute — single backslash in a C# string literal. Platform.Apps.Projects compiles ALL Project.cs,

so one broken sibling blocks every MSIX build fleet-wide. Exactly the known class. Doubled the

backslash (0c292741d), pushed, pulled on .204, rebuilt — BUILD_EXIT_CODE=0, 113.7 MB.

**Lesson worth spreading: never hand-write a Windows path into Project.cs lifecycle strings

without doubling the backslash.** Any agent writing "E2E ran from C:\foo" is a build-breaker.

The task file lies about the lane. "Onboarding build-msix" but 9PCDRKXPPHWT is published

(2026-09-16, published_sub_id set, pending_sub_id=none, store pkg 2026.916.812.0). The stale

sub_progress.packages="Not started" shape again. I followed the skill's correction rule: build,

stage to packages_onboarding\pending (task step 9, harmless gate), ALSO copy to

packages_update\pending + emit packageupdate. The update lane did the real work in 4 minutes:

Start update → submission 1152921505702059649 → dummy removed → real package uploaded → Save

(Packages: Updated, all else Unchanged) → Submit for certification → In certification, verified

independently via get-submission. Refreshed SCORPIOX_PARTNERCENTER_PUBLISHEDSUBID_9PCDRKXPPHWT

and emitted submissionchanged so the matrix picks up the new version.

The task's working-with-scorpiox-cli-workitem skill doesn't exist (grep confirms); nearest is

working-with-workitems. No work item was needed anyway — gates passed, sibling fix was step 6's

own path.

Ran the full rules-review grep block (the ~30 greps) before building: clean, including the

conditional-converter check. BoolVisibilityConverter is registered twice in FuncConverterX —

line 58 unconditional (indent 12) and line 1635 inside the ScorpioPlayer if block. The page uses

the unconditional one. Fine, but worth remembering the duplicate exists.

The onboarding-continue orchestrator (triggered by my task emit) did a full sweep and correctly

reported "all 217 apps have pending_sub_id=none → nothing eligible". 10 apps match the

onboarding-gate shape but all are published — the matrix packages: Not started data is stale for

all of them. Every one of these needs the packages_update lane, not packages_onboarding.

Second build attempt on .204 hit "file in use by another process" on store_build.log — leftover

MSBuild from the killed attempt-1 holding the log. Killed MSBuild/devenv/xhost/dotnet on the box

and re-ran. The skill's preflight kill step exists for exactly this; I skipped it on retry and

paid one wasted round.