124 lines
5.7 KiB
Org Mode
124 lines
5.7 KiB
Org Mode
#+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
|
|
|
|
* [X] 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: 667b06f
|
|
- tests: ~python3 -m py_compile /home/user/proj/youdis/youdis.py~
|
|
- datetime: [2026-03-31 Tue 14:00]
|
|
|
|
** 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”
|