#+title: Task Log
#+updated: [2026-03-31 Tue 16:03]

* youdis v2 goals:
1. Separate backend from frontend
2. Offload auth
3. Ensure auto nightly builds
4. Default output format supports plex browsing youtube channels as "tv shows"
5. Facilitate multiple GUI inbounds: Discord, Zulip, XMPP

* [ ] 2.0.0: define architecture (2-4)
define the target architecture for a private backend yt-dlp worker with thin chat frontends
** pm notes:
- keep this iterative. the point is to choose the shape and seam, not prematurely implement infra. likely decisions include backend framework, request/status model, and how thin the discord shim should be.
- goal is simple, private, maintainable deployment
- avoid auth, queues, or persistence beyond clear & immediate needs

** Acceptance Criteria
1. document the target architecture at a high level
   - backend owns yt-dlp execution and job state
   - frontends own chat-specific UX
2. identify key decisions still open
   - backend choice
   - service seam/endpoints
   - status/progress model
3. capture enough structure to begin implementation
   - repo/component layout is sketched
   - next implementation task is unblocked

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

** notes
- first architecture draft captured in `docs/architecture-v2.org`

* [ ] 2.0.1: build backend yt-dlp worker (3)
create the minimal backend/service skeleton and establish a working yt-dlp baseline with clean hooks for future frontends
** pm notes
- foundation; don't need the full finished service here, just the basic shape plus enough real yt-dlp execution to validate the seam and build on it.
- keep single-job semantics
- prioritize inspectable behavior over polish

** Acceptance Criteria
1. create the backend/service skeleton
   - app/module layout exists
   - core request path is stubbed or minimally working
2. establish a working yt-dlp baseline
   - archive behavior is preserved
   - output path behavior is preserved or intentionally updated
   - use yt-dlp .conf and set reasonable default
3. expose basic hooks/interfaces for future frontends
   - submit/request path exists
   - status/progress hook exists
   - basic health/version visibility exists

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

** notes

* [ ] 2.0.2: update discord bot to use new backend (3)
update the discord bot into a thin frontend that talks to the backend and verify the flow end to end
** pm notes
- this is the first real frontend proof. once this works cleanly, zulip/xmpp should mostly be adapter work rather than downloader rewrites.
- keep discord logic thin; no auth
- do not duplicate yt-dlp behavior in the bot

** Acceptance Criteria
1. discord bot submits requests to backend
   - command/input handling works
   - acceptance/busy/failure responses are clear
2. discord bot relays useful backend status
   - progress reporting works at a basic level
   - completion/failure/skipped outcomes are surfaced
3. backend-discord flow is tested end to end
   - valid request path tested
   - busy or conflict behavior tested
   - failure path tested

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

** notes

* [ ] 2.0.3: remove deprecated discord-bot functionality (2)
delete or retire legacy bot behaviors that no longer fit once the backend split is in place
** pm notes
- only remove this after the new path works. this is cleanup, not pioneering work.
- favor deletion over compatibility shims
- keep operator controls only if still useful

** Acceptance Criteria
1. remove obsolete auth/user-management behavior
   - old user persistence and commands are removed
   - backend-facing flow no longer depends on them
2. remove obsolete downloader/runtime logic from bot
   - bot no longer owns yt-dlp execution
   - dead code paths are deleted
3. leave the bot in a coherent state
   - remaining commands reflect actual supported behavior
   - deprecated artifacts are clearly removed or marked

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

** notes

* [ ] 2.0.5: fix automation and build pipeline (3)
repair and simplify the build/update/deploy path so it matches the new backend-plus-frontend structure
** pm notes
- this should come after architecture and discord integration stabilize. no point polishing the pipeline for the wrong shape.
- optimize for simple manual ops first
- stop here after pipeline is sane
  
** Acceptance Criteria
1. align build artifacts with the new structure
   - docker/build scripts reflect current components
   - runtime assumptions are consistent
2. review old automation artifacts
   - stale runner/update/restart logic is removed or updated
   - manual update/rebuild flow is clear
3. confirm deployment path works
   - local or unraid deployment is validated
   - pipeline is understandable enough to maintain

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

** notes