finalized v2 architecture for 2.0.1
This commit is contained in:
276
pm/tasks-v2.org
276
pm/tasks-v2.org
@@ -1,139 +1,139 @@
|
||||
#+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:
|
||||
|
||||
#+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
|
||||
- first architecture draft captured in `docs/architecture-v2.md`
|
||||
|
||||
* [ ] 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
|
||||
|
||||
Reference in New Issue
Block a user