UnigramDev/Unigram/develop • 73fcda9 • 1 files, +26/-4
crash-triage: close the crash group when the PR merges

Merging is what marks a crash fixed, so the loop now ends by closing the
group rather than leaving it to be done by hand.

Because the group hash cannot appear in the PR, the pr-number -> group-hash
mapping has to be recorded locally when the PR is opened, or the link is lost
as soon as the PR is the only artefact left.

Also records the PR-watching gotcha found this session: gh posts comments
under the user's own account, so a watcher cannot use author to tell the
agent's comments from the user's, and unfiltered it reads its own words back
as instructions. Agent comments carry an HTML-comment marker and the watcher
skips them.

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

UnigramDev/Unigram/develop • 4caca6d • 1 files, +17/-0
crash-triage: verify the mechanism instead of inferring it

A rejected PR's worth of lesson. The autocomplete crash was diagnosed as a
recycled container carrying the previous item type's template, a story that
fitted the stack and was never checked. The actual cause was
AutocompleteTemplateSelector returning CommandTemplate for both UserCommand
and QuickReplyShortcut, so the tree never matched what the code-behind read —
one file would have shown it, and it was never opened.

Requires naming and opening the file that would confirm a hypothesis before
writing code, and adds two checks that would have caught this one:

- Does the crash frequency match the story? A race is intermittent; a
mismatched template fails every time that path runs. Rare-but-deterministic
contradicts a race.
- For a visual-tree mismatch, read the DataTemplateSelector before blaming
recycling. Guarding the symptom there turns a crash into a silently blank
row and leaves the real bug in place.

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

UnigramDev/Unigram/develop • e66dbd0 • 1 files, +14/-0
crash-triage: don't construct singletons to silence a null

Second rejected PR, same root habit as the first: fixing the symptom at the
call site without establishing who owns the state.

InitializeFrame was patched to build a WindowContext when Current was null.
WindowContext's constructor assigns the thread-static _current, and
OnWindowCreated constructs one on its own schedule, so the patch produced two:
the later assignment wins and the frame attached to the first is silently
discarded. That is worse than the NullReferenceException it removed, because
it corrupts startup state instead of aborting it.

Adds two rules:

- Before constructing anything to make a null go away, grep every construction
site and work out the ordering. If it is a not-yet-initialised singleton,
creating one here means two exist and one loses.
- When the missing state is a race, neither inventing it nor returning early
is the fix — returning leaves the feature silently dead, which is the same
trap as guarding a template mismatch. Carrying the input forward until the
state arrives is a sequencing decision about startup: propose it, don't
guess at it.

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

UnigramDev/Unigram/develop • ecb532a • 1 files, +2/-2
Fix MediaDeviceList release

#unigram