#+title: Youdis Task Log 
#+updated: [2026-03-31 Tue 08:00]

* [X] 1.1.1: stabilize youdis core bot behavior (estimate 3 commits)
refactor the current `youdis.py` flow so authorization, download execution, and user feedback are correct and predictable without changing the product shape.  keep this narrowly scoped to correctness and maintainability; do not redesign into a queueing platform yet.  preserve archive-first behavior and dm status updates; do not add new infrastructure dependencies and prefer boring explicit state over clever concurrency.

** acceptance criteria
1. initialize and load `/config/users.json` safely in all cases
   - create parent dirs before touch/open
   - ensure `authorized_users` always has a valid default
   - normalize stored ids to a single type
2. fix command-path correctness for `/youtube`, `/adduser`, and `/removeuser`
   - authorized users can successfully invoke downloads
   - add/remove user commands persist changes correctly
   - remove broken/incomplete code paths
3. duplicate prevention relies on archive.txt

** pm notes

** evidence
- commit: 033d9dd
- tests: ~python3 -m py_compile ./youdis.py~
- datetime: [2026-03-31 Tue 13:28]

** notes
- store Discord user ids as strings in `users.json`
- duplicate prevention should continue to rely on `archive.txt`, not inferred hook errors

* [ ] 1.1.2: remove global mutable download state and define single-job semantics (estimate 2 commits)
eliminate shared mutable hook state and make concurrent behavior explicit, even if the initial policy is just "one active job at a time."  don't build a scheduler; ok if simplest outcome is single active job with clear busy message.  cancellation can be coarse if yt-dlp/process boundaries make graceful stop annoying

** acceptance criteria
1. improve runtime handling for downloads
   - replace brittle thread/join pattern with a simpler async-safe execution path
   - catch and report real yt-dlp failures
   - avoid misleading "already exists" error assumptions
2. progress reporting is isolated per request
   - no module-level mutable title state shared across jobs
   - hooks derive state from request-local context
3. active-job behavior is explicit
   - either reject a second request while busy or implement a minimal tracked active job
   - user-facing response explains current behavior
4. `/interrupt` is either implemented minimally or downgraded honestly
   - no fake command implying cancellation works when it does not
   - command behavior matches implementation

** evidence
- commit:
- tests:
- datetime:

** notes
- verify slash-command response patterns against the `interactions` library while touching runtime flow

* [ ] 1.1.3: move static yt-dlp behavior into config and shrink python surface area (estimate 2 commits)
shift stable downloader options into `default-yt-dlp.conf` so the bot code only handles dynamic inputs and orchestration.  optimize for inspectability and low-friction manual ops.  keep output naming durable enough for plex/plain-file use.  avoid duplicating config values across code and conf.

** acceptance criteria
1. separate static vs dynamic yt-dlp options cleanly
   - stable defaults live in `default-yt-dlp.conf`
   - python injects only request-specific/runtime values
2. preserve archive and output behavior
   - `archive.txt` remains the duplicate-prevention mechanism
   - output paths remain stable and browseable
3. document config ownership
   - clarify which settings belong in config vs code
   - make future yt-dlp tuning possible without major python edits

** evidence
- commit:
- tests:
- datetime:

** notes

* [ ] 1.1.4: simplify image/build/update workflow around manual ops (estimate 3 commits)
reduce repo cruft from the gitea-runner/nightly-update experiment and replace it with explicit manual update/rebuild mechanics.

** acceptance criteria
1. define a manual update path for yt-dlp and app image lifecycle
   - document or script manual `git pull`, rebuild, and redeploy
   - remove or quarantine brittle auto-update assumptions
2. review and simplify `update-ytdlp.sh`, workflow yaml, and weekly restart artifacts
   - keep only artifacts that serve the current manual-ops model
   - delete or mark deprecated anything tied to abandoned automation paths
3. retain unraid deployment viability
   - container can still be rebuilt and redeployed cleanly on jeeves
   - resulting flow is understandable without rereading old ci experiments

- pm note: weekly restart is presumed suspect until proven necessary

** evidence
- commit:
- tests:
- datetime:

** notes
- do not let runner/workflow complexity dominate a small bot
- prefer explicit version pinning or manual binary refresh over magical nightlies

* [ ] 1.1.5: clean up packaging/deployment artifacts for unraid consumption (estimate 2 commits)
make the dockerfile, run script, and unraid-ca template consistent with the refactored app so deployment is less of a ritual ordeal.

** acceptance criteria
1. align docker/runtime assumptions
   - paths like `/config` and `/downloads` are consistent across code, scripts, and container metadata
   - env vars are documented and validated
2. review deployment artifacts for drift
   - `dockerfile`, `run-youdis.sh`, and `unraid-ca-template.xml` reflect current behavior
   - remove stale references and dead assumptions
3. make fresh deployment understandable
   - a new deploy on unraid is possible without reconstructing tribal knowledge from old files

- pm note: this is packaging polish after core correctness, not before

** evidence
- commit:
- tests:
- datetime:

** notes
- keep container surface area small
- optimize for “future me can redeploy this without cursing past me too hard”