Oliver Kieselbach 14a67ef5af Time attribution shows the OOBE quality update as Windows Update and the wait after its restart as Waiting for sign-in (D-314) ...

TimeAttributionCalculator v4 cuts two segments out of the phase partition:
os_update from the OobeNDUP page start whose visit holds update evidence
(a servicing step or a name only an update in progress writes) to the last
update evidence before the user is back; awaiting_sign_in from there to the
first evidence of the user, only after a restart. Both replace the phase
span they overlap; without evidence the partition is v3's. OsUpdates names
the KBs and restarts. Reboot gaps no longer start or end on the clock-sync
row logged at boot. The sweep recomputes the last 30 days.

Aggregates carry eight segments; the session lane and Fleet Health show
"Windows Update" (cyan) and "Waiting for sign-in" (sky) with the KBs and
restarts in legend and tooltip; MCP get_time_attribution description;
manifest and wire types regenerated.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

2026-10-02 22:55:45 +02:00

..

Agent

OOBE update page: fields from event properties in every display language, page start and stop never capped, no duplicates after a restart

2026-10-02 22:55:39 +02:00

Backend

Time attribution shows the OOBE quality update as Windows Update and the wait after its restart as Waiting for sign-in (D-314)

2026-10-02 22:55:45 +02:00

McpServer

Time attribution shows the OOBE quality update as Windows Update and the wait after its restart as Waiting for sign-in (D-314)

2026-10-02 22:55:45 +02:00

Shared

Time attribution shows the OOBE quality update as Windows Update and the wait after its restart as Waiting for sign-in (D-314)

2026-10-02 22:55:45 +02:00

Web

Time attribution shows the OOBE quality update as Windows Update and the wait after its restart as Waiting for sign-in (D-314)

2026-10-02 22:55:45 +02:00