# Phase 12: Polish & Audit - Context

**Gathered:** 2026-02-08
**Status:** Ready for planning

<domain>
## Phase Boundary

Clear Unraid update badges after bot-initiated container updates, verify environment configuration documentation, fix remaining tech debt (curl timeout), and complete deferred Phase 11 UAT tests (Update All via text command and inline keyboard button).

</domain>

<decisions>
## Implementation Decisions

### Unraid badge clearing
- Unraid UI shows "update available" badge that persists after bot updates a container
- Badge persists until user manually applies the update through Unraid UI
- When user applies through Unraid UI after bot already pulled the image, it completes fast (just recreates container — image already cached)
- Root cause unknown: Unraid likely has its own update tracking mechanism (not just image digest comparison) that needs to be notified
- **Research needed:** Investigate how Unraid tracks container update state internally (XML files, database, API) and whether the bot can clear/notify it after a successful update
- The bot's image pull IS working correctly — Unraid just doesn't know about it

### Claude's Discretion
- Environment config documentation approach (TELEGRAM_USERID, TELEGRAM_BOT_TOKEN clarity)
- Curl --max-time flag consolidation strategy
- Phase 11 deferred UAT test execution approach (Update All text command + inline keyboard)

</decisions>

<specifics>
## Specific Ideas

- The ideal outcome: after bot updates a container, Unraid UI immediately reflects the container is up-to-date (no manual re-apply needed)
- If Unraid can't be notified programmatically, document the limitation and consider a workaround (e.g., trigger Unraid's "Check for Updates" scan after bot update)

</specifics>

<deferred>
## Deferred Ideas

None — discussion stayed within phase scope

</deferred>

---

*Phase: 12-polish-audit*
*Context gathered: 2026-02-08*