docs(pmoves-yt): reconcile yt-dlp currency claims against measured reality - #2793
Merged
Conversation
Contributor
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
github-actions
Bot
added
chit-aware
Contributor
🔏 CHIT-aware change — control-body routingThis PR touches a CHIT-aware service (ports 8086/8087/8103/8106/8113/9224 surface). Before a Control-Body ACK:
Advisory routing only — the blocking contract check is CHIT Contract. |
POWERFULMOVES
force-pushed
the
docs/ytdlp-currency-reconcile
branch
from
August 27, 2026 19:06
420b9f8 to
bc9bbb8
Compare
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 420b9f8f79
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
POWERFULMOVES
force-pushed
the
docs/ytdlp-currency-reconcile
branch
from
August 27, 2026 20:56
bc9bbb8 to
77b1ee2
Compare
Owner
Author
Branch-divergence finding — the fork-sync prerequisite is bigger than one mergeVerified from B850 while reviewing this PR. It refines §4's statement of what the fork-sync lane would have to do. The recorded pin is on an unmerged branch, and it is not the branch carrying the PMOVES work. And every substantive PMOVES.YT PR merged into the declared branch, not the pinned one:
So the two lines have diverged and neither is complete:
That is why this PR's table shows the pin five months ahead of the tracked branch on yt-dlp while the tracked branch is the one holding #4–#7. Consequence for the doc's §4. "Merge Consequence for One thing this validates. PR #4 — "make submodule authoritative" — establishes that the fork is meant to be authoritative rather than a shim. The README fix in this PR (pointing at Not blocking the merge. The doc leads with commands rather than numbers, which is what keeps it true; this is an addition to §4 rather than a correction to anything measured. |
POWERFULMOVES
added a commit
that referenced
this pull request
Aug 27, 2026
… paths, two yt-dlp builds Both fixes are Codex review findings on #2793. 1. The orphan framing was wrong, and the consequence is bigger than the wording. `pmoves/services/pmoves-yt/Dockerfile` is not inert: the GHCR matrix entry names it, `integrations-ghcr.yml` builds and PUSHES it (push: true, L691) as ghcr.io/powerfulmoves/pmoves-yt:pmoves-latest, and that image is what `docker-compose.integrations.images.yml:3` pins and `make -C pmoves up-yt-published` (Makefile:2582) starts. Its matrix entry sets "build_args": "", so it falls through to an unpinned `pip install "yt-dlp[default]"` — stock PyPI yt-dlp, carrying none of the 18 PMOVES fork commits (CHIT signing, thread-safe NATS publish, Phase-9C multi-client, SoundCloud fixes). So there are two documented deployment paths running two different yt-dlp builds, and the claim that runtime == the recorded gitlink "by construction" holds only on the local-build path. New § 1f states both paths side by side; § 2's consistency note is scoped to this node's local-build container (verified via docker inspect); § 3 and the bump workflow's own wording are corrected the same way; § 4 gains step 8, the published image's own lane. The published image's yt-dlp version is recorded as UNVERIFIED with the reason, not guessed: anon GHCR token exchange returns DENIED, an authenticated exchange and `docker pull` both return denied, and the packages REST API needs a read:packages scope this node's token lacks. `_known_orphans.yaml` is not wrong about membership — no compose `build:` stanza names the file, which is that registry's whole contract — but its reason line said "compose builds from the sibling PMOVES.YT submodule. Kept as the upstream source", which reads as inert. Amended to say what actually consumes it. Also fixed the README's claim that compose "builds from services/pmoves-yt when unset"; it builds ../PMOVES.YT. 2. The doc's own commands read the working checkout, in a section warning about exactly that. § 1a now captures PIN_SHA from `git ls-tree HEAD -- PMOVES.YT` and every later comparison uses it — the merge-base in the caveat and all three ahead/behind commands in § 1d, which previously used PMOVES.YT/HEAD. Measured on this node today: 26 of 75 submodules have a checkout that differs from the recorded pin. PMOVES.YT is not currently one of them, and the doc says so rather than letting that coincidence look like a guarantee. Verified: the rewritten § 1a commands run clean here (PIN_SHA=ebd39b7fc…, version 2026.07.04); `_known_orphans.yaml` parses (my first reason line contained a colon-space and broke it); `validate_dockerfile_paths.py` OK (93 dockerfiles, 82 referenced, 26 baseline); `yt-dlp-bump.yml` parses. Gitlink untouched. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FkwiW3VY1xWmahTAtVioxz
…ality (47c0c0d) on a change of `1 file changed, 1 insertion(+)` — one line appended to the hardening tracker. No pin moved. Anyone auditing "are we current on yt-dlp?" by reading git log titles got the wrong answer. yt-dlp is not a pip dependency here. It is the PMOVES.YT submodule, which is itself a yt-dlp fork, and the deployed image installs that fork from source. `yt-dlp-bump.yml` cannot bump it: it resolves the latest PyPI release, builds a throwaway image (push: false) from a Dockerfile the deployed stack does not use, and commits prose. It never writes a version into any file a build reads. Measured on B850 (2026-08-27), commands and output in the new doc: recorded gitlink PMOVES.YT ebd39b7fc7 -> yt-dlp 2026.07.04 running container 2026.07.04 (import + GET :8077/healthz) fork tracked branch 2026.02.04 (8d971cd18a) latest upstream release 2026.08.19 (3a08beaf03, dated 2026-08-19) channel-monitor 2024.10.7 (requirements.lock:1027) Two findings surfaced while measuring, both load-bearing for the fork-sync lane and neither previously written down: - The recorded gitlink is the tip of the UNMERGED branch feat/upstream-sync-2026.07, not of PMOVES.AI-Edition-Hardened, which .gitmodules declares. Hardened is at 2026.02.04, so `git submodule update --remote` would DOWNGRADE the running yt-dlp. - The bump workflow builds pmoves/services/pmoves-yt/Dockerfile, a known orphan (_known_orphans.yaml) that installs stock PyPI yt-dlp. Compose builds ../PMOVES.YT with pmoves_yt_service/Dockerfile. The weekly job validates a path production never takes. Changes: - New pmoves/docs/services/pmoves-yt/YTDLP_CURRENCY.md — leads with the commands (which do not rot), then dated measurements, then the gap stated for the fork-sync lane to plan from. Enrolled in living_docs_registry.yaml at P2/60d so its dated section rots visibly. - Tracker: the #2713 line is preserved verbatim and annotated in place — annotation, not rewrite. Preamble worded position-independently because the workflow prepends at line 1. - Corrected three currency claims that asserted what they could not know: "keeps the extractor lane current", the workflow-table description, and the Hardened-Summary runner label (read `self-hosted, vps`; the workflow has `runs-on: ubuntu-latest`). - Corrected the "built from services/pmoves-yt/Dockerfile" claim in Services and Integrations, and the same confusion in the service README. - Fixed the README's fork example: `POWERFULMOVES/yt-dlp.git@main` resolved via GitHub's rename redirect but `main` carries none of the PMOVES commits, so it silently installed a plain upstream mirror. - yt-dlp-bump.yml now says what it did. Subject, branch, tracker line and PR body all state that no pin moved. The emitted shell was dry-run verified with git/gh stubbed. Scope is reconciliation only. No gitlink moved; no env file touched; the PMOVES.YT tree is untouched. The upgrade is a separate lane needing its own claim and operator go-ahead, and section 4 of the new doc states what it would have to do. Village Rule CLAIM: AGNOTE4482PHI.t1.md, 2026-08-27T15:10:00Z, ACK::B850-CLAUDE::YTDLP-CURRENCY-RECONCILE-CLAIM::2026-08-27. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FkwiW3VY1xWmahTAtVioxz
… paths, two yt-dlp builds Both fixes are Codex review findings on #2793. 1. The orphan framing was wrong, and the consequence is bigger than the wording. `pmoves/services/pmoves-yt/Dockerfile` is not inert: the GHCR matrix entry names it, `integrations-ghcr.yml` builds and PUSHES it (push: true, L691) as ghcr.io/powerfulmoves/pmoves-yt:pmoves-latest, and that image is what `docker-compose.integrations.images.yml:3` pins and `make -C pmoves up-yt-published` (Makefile:2582) starts. Its matrix entry sets "build_args": "", so it falls through to an unpinned `pip install "yt-dlp[default]"` — stock PyPI yt-dlp, carrying none of the 18 PMOVES fork commits (CHIT signing, thread-safe NATS publish, Phase-9C multi-client, SoundCloud fixes). So there are two documented deployment paths running two different yt-dlp builds, and the claim that runtime == the recorded gitlink "by construction" holds only on the local-build path. New § 1f states both paths side by side; § 2's consistency note is scoped to this node's local-build container (verified via docker inspect); § 3 and the bump workflow's own wording are corrected the same way; § 4 gains step 8, the published image's own lane. The published image's yt-dlp version is recorded as UNVERIFIED with the reason, not guessed: anon GHCR token exchange returns DENIED, an authenticated exchange and `docker pull` both return denied, and the packages REST API needs a read:packages scope this node's token lacks. `_known_orphans.yaml` is not wrong about membership — no compose `build:` stanza names the file, which is that registry's whole contract — but its reason line said "compose builds from the sibling PMOVES.YT submodule. Kept as the upstream source", which reads as inert. Amended to say what actually consumes it. Also fixed the README's claim that compose "builds from services/pmoves-yt when unset"; it builds ../PMOVES.YT. 2. The doc's own commands read the working checkout, in a section warning about exactly that. § 1a now captures PIN_SHA from `git ls-tree HEAD -- PMOVES.YT` and every later comparison uses it — the merge-base in the caveat and all three ahead/behind commands in § 1d, which previously used PMOVES.YT/HEAD. Measured on this node today: 26 of 75 submodules have a checkout that differs from the recorded pin. PMOVES.YT is not currently one of them, and the doc says so rather than letting that coincidence look like a guarantee. Verified: the rewritten § 1a commands run clean here (PIN_SHA=ebd39b7fc…, version 2026.07.04); `_known_orphans.yaml` parses (my first reason line contained a colon-space and broke it); `validate_dockerfile_paths.py` OK (93 dockerfiles, 82 referenced, 26 baseline); `yt-dlp-bump.yml` parses. Gitlink untouched. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FkwiW3VY1xWmahTAtVioxz
POWERFULMOVES
force-pushed
the
docs/ytdlp-currency-reconcile
branch
from
August 28, 2026 01:02
f3f560c to
7d533bb
Compare
This was referenced Aug 28, 2026
POWERFULMOVES
added a commit
that referenced
this pull request
Aug 28, 2026
… yt-dlp builds (#2801) * docs(pmoves-yt): service runbook — two deployment paths run different yt-dlp builds The pmoves-yt lane had README.md and UPDATE_NOTES.md but no operations doc. This adds RUNBOOK.md: bring-up, health verification, the cookie chain, logs, failure triage by operator-visible symptom, and teardown. Every command was run on B850/Knuckles and its real output pasted; unverifiable claims are marked UNVERIFIED rather than written as plausible text. Leads with the discriminator, because it makes every other answer right or wrong: up-yt builds ../PMOVES.YT -> the fork's vendored yt-dlp up-yt-published ghcr.io/.../pmoves-yt -> built from the services/pmoves-yt shim, which pip installs STOCK yt-dlp[default] from PyPI Verification sharpened that in two ways: - The image name is a hint, not the fact. docker-compose.integrations.images.yml overrides only `image:`; the base `build: {context: ../PMOVES.YT}` survives the merge (confirmed via `docker compose config` on both chains). A node with the submodule checked out can run a locally-built fork image wearing the GHCR name. So: check the image for intent, /healthz's yt_dlp_version for fact. - RepoDigests does NOT discriminate build-vs-pull — this node's locally-built image carries one. Checked before documenting it. Two undocumented failure modes found while verifying, both "healthy but lying": - pmoves-yt here runs cookie-less: YT_COOKIES reads the base-compose placeholder darkxside.youtube.cookies.txt, that file does not exist, and no yt-cookies-vol is mounted. Reading YT_COOKIES is now the one-command wiring check. Note up-yt-published and up-yt-hardened are cookie-less as written — both use $(DC) and neither passes --profile yt-cookies. - yt-cookie-writer reports healthy with a dead NATS subscription: its healthcheck only asserts /tmp/healthy exists, touched once at first subscribe and never removed. Measured a DNS failure at 14:10:15Z behind a marker dated Aug 15, FailingStreak 0, RestartCount 0. Also documented: no down-yt Known Road exists, so teardown uses `docker compose ... stop` (the enforcer blocks only up|restart|down); the --remote submodule downgrade hazard with its reproduction; AMD -amd targets; and that `make seed-data` destroys pmoves_chunks_qwen3. Version/currency questions are deferred to YTDLP_CURRENCY.md (#2793), not restated here. No Makefile or compose file touched. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FkwiW3VY1xWmahTAtVioxz * docs(pmoves-yt): defer pin-reading to YTDLP_CURRENCY.md, flag the §1b refinement #2793 merged mid-session, so YTDLP_CURRENCY.md now exists on main. Two changes: - §2.1 duplicated its §1a (pin-reading mechanism). Compressed to the two commands an operator needs mid-incident plus a pointer, per 'link, do not restate'. - §1.2 refines its §1b rather than silently diverging. That section maps ghcr.io/... -> 'published image (stock PyPI yt-dlp)'. True for a genuinely pulled image, but not guaranteed by the name: the images overlay overrides only `image:`, leaving `build: {context: ../PMOVES.YT}` intact, so a node with the submodule checked out can build the fork and tag it with the GHCR name. Both docs agree on the conclusion — the running container wins. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FkwiW3VY1xWmahTAtVioxz * docs(pmoves-yt): the published image cannot start; fix four unrunnable recipes Codex review of #2801 flagged five claims. All five reproduced or refuted on B850 / Knuckles; every command below was executed and its output pasted. P1 — the published image is not "stock PyPI yt-dlp", it is unrunnable (§1.3). `/app/yt.py:9` does `parents[3]`, written for the repo layout; `WORKDIR /app` + `COPY . .` flattens those three levels, so `.parents` is length 2 and the import raises `IndexError: 3` before any shim fallback. Correcting the depth would not help: the GHCR build context excludes the repo-root `PMOVES.YT` submodule. Publishing is inherited — the matrix entry predates the shim by four months (#699 2026-02-23 vs #883 2026-03-12) and no Dockerfile revision ever used a layout where the shim resolved. CI cannot catch it (runtime import, not build) and nothing pulls it (the images overlay leaves `build:` intact, so up-yt-published rebuilds the fork under the GHCR name). Recorded as a docs finding plus follow-up issue #2802; no code change — this is a docs branch. P2 §2.2 — `git checkout -- PMOVES.YT` does not undo `--remote`. Verified on a throwaway two-repo fixture: it restores the gitlink `--remote` never moved and leaves the submodule HEAD downgraded (` M SUB` throughout). Replaced with `git submodule update --init --force`, with the plain-`--init` distinction shown (it aborts at exit 1 on local edits). P2 §5.4 — the `supabase-kong` diagnosis was wrong and would mask the real cause. `yt_oauth_flow.py::_supabase_url()` already rewrites that host to localhost; from the primary tree the target exits 0. The observed failure came from a linked worktree (untracked env files absent) falling through to an ambient `SUPA_REST_URL=http://host.docker.internal:...`, a Docker-Desktop-only name. Errno is the tell: -2 for that host vs -3 for supabase-kong. Replaced with an ordered triage list. P2 §6/§8 — refuted as stated, then fixed for the real defect. Compose selects by project label on running containers, so these work from any cwd with no compose file; the cookie pair resolves fine. The actual hazard is that unmatched names are skipped silently at exit 0 — which is exactly what happens to bgutil-pot-provider, unlabelled on this node. Added a coverage check and a direct `docker stop`/`docker logs` step for it. Also: §7 triage rows corrected, §9 item 1 reframed (registry access is the only open question; artifact behaviour is settled), and a fifth honest UNVERIFIED added for whether bgutil is Compose-unowned beyond this node. Refs #2802 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FkwiW3VY1xWmahTAtVioxz * docs(pmoves-yt): stop code-fence labels from parsing as headings Three `###`-prefixed labels inside the §2.2 verification fence rendered as code but were picked up by heading extraction. Switched to `---` prefixes. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FkwiW3VY1xWmahTAtVioxz --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
POWERFULMOVES
added a commit
that referenced
this pull request
Aug 28, 2026
…tro-claim #2806 Three b850-claude lanes (docs/ytdlp-currency-reconcile #2793, docs/pmoves-yt-runbook #2801, fix/pmoves-yt-published-image #2803) were merged but still parsed as open by claim-collision-pre.py's own open_claims_in(). One RELEASE for docs/pmoves-yt-runbook already existed at line 2289 but the parser never saw it close: that RELEASE's prose backticks an unrelated branch name (`feat/upstream-sync-2026.07`, cited only to describe the PMOVES.YT submodule's pin) which the lane-matching regex picks up, switching the release from "closes everything" to "closes only named lanes" — narrowing itself without the author intending it. Documented as a durable grammar trap and closed with a supplementary RELEASE row rather than editing historical entries or the hook. Also verified the #2803 republish more strongly than the merged PR claimed possible: the merge-triggered integrations-ghcr.yml run's "Verify pushed image starts (runtime gate)" step succeeded against the real GHCR digest (still unreachable via `docker manifest inspect`/`gh api` from this node, but CI's own gate is authoritative). Also surfaced a separate, pre-existing gap: the same run is red end-to-end from 42 unaddressed HIGH-severity Trivy CVE findings, unrelated to and not caused by #2803 (baselined against the prior merge's identical failure). Retroactively CLAIMs PR #2806 (open, in flight via a delegated delivery-agent) since it and its merged sibling #2805 were pushed with no register entry — the unclaimed-work failure the steward role exists to catch. Register conflict resolved as UNION: git diff origin/main --numstat shows 15 insertions, 0 deletions on this file. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FkwiW3VY1xWmahTAtVioxz
POWERFULMOVES
added a commit
that referenced
this pull request
Aug 28, 2026
…tro-claim #2806 (#2808) Three b850-claude lanes (docs/ytdlp-currency-reconcile #2793, docs/pmoves-yt-runbook #2801, fix/pmoves-yt-published-image #2803) were merged but still parsed as open by claim-collision-pre.py's own open_claims_in(). One RELEASE for docs/pmoves-yt-runbook already existed at line 2289 but the parser never saw it close: that RELEASE's prose backticks an unrelated branch name (`feat/upstream-sync-2026.07`, cited only to describe the PMOVES.YT submodule's pin) which the lane-matching regex picks up, switching the release from "closes everything" to "closes only named lanes" — narrowing itself without the author intending it. Documented as a durable grammar trap and closed with a supplementary RELEASE row rather than editing historical entries or the hook. Also verified the #2803 republish more strongly than the merged PR claimed possible: the merge-triggered integrations-ghcr.yml run's "Verify pushed image starts (runtime gate)" step succeeded against the real GHCR digest (still unreachable via `docker manifest inspect`/`gh api` from this node, but CI's own gate is authoritative). Also surfaced a separate, pre-existing gap: the same run is red end-to-end from 42 unaddressed HIGH-severity Trivy CVE findings, unrelated to and not caused by #2803 (baselined against the prior merge's identical failure). Retroactively CLAIMs PR #2806 (open, in flight via a delegated delivery-agent) since it and its merged sibling #2805 were pushed with no register entry — the unclaimed-work failure the steward role exists to catch. Register conflict resolved as UNION: git diff origin/main --numstat shows 15 insertions, 0 deletions on this file. Claude-Session: https://claude.ai/code/session_01FkwiW3VY1xWmahTAtVioxz Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
PR #2713 landed the subject
chore(pmoves-yt): bump yt-dlp to 2026.8.19(47c0c0d3b) on a change of1 file changed, 1 insertion(+)— a single line appended to the hardening tracker. Nothing was bumped. Anyone auditing "are we current on yt-dlp?" from git log titles got the wrong answer.yt-dlpis not a pip dependency in this repo. It is thePMOVES.YTsubmodule, which is itself a yt-dlp fork, and the deployed image installs that fork from source.yt-dlp-bump.ymlcannot bump it — it resolves the latest PyPI release, builds a throwaway image (push: false) from a Dockerfile the deployed stack does not use, and commits prose. It never writes a version into any file a build reads.Scope is reconciliation, not the upgrade. No gitlink moved, no env file touched, the
PMOVES.YTtree is untouched. The fork-sync is a separate lane needing its own claim and operator go-ahead; § 4 of the new doc states what it would have to do.Ground truth (measured on B850 / Knuckles, 2026-08-27)
PMOVES.YTebd39b7fc7507298c768fbf64826bd22265dffb0git ls-tree HEAD -- PMOVES.YTgit -C PMOVES.YT show <pin>:yt_dlp/version.pydocker exec pmoves-pmoves-yt-1 python -c "import yt_dlp; ..."andGET :8077/healthzPMOVES.AI-Edition-Hardenedversion.pyat8d971cd18a3a08beaf03, dated 2026-08-19)git ls-remote --tagsvsyt-dlp/yt-dlpchannel-monitor(separate consumer)requirements.lock:1027, confirmed in the built imageGap: 32 commits behind the
2026.08.19tag (44 behindupstream/master), 22 ahead of which 18 are non-merge PMOVES-authored — CHIT HMAC signing, thread-safe NATS publish, the Phase-9C multi-client chain, Data API v3 + Deno runtime, SoundCloud fixes, NATS/MinIO hardening, the CVE-2026-21441 urllib3 pin. Full evidence and commands are in the new doc.Two findings that were not written down anywhere
.gitmodulesdeclaresbranch = PMOVES.AI-Edition-Hardened, butebd39b7fcis the tip of the unmergedfeat/upstream-sync-2026.07. Hardened is at yt-dlp 2026.02.04 — sogit submodule update --remotewould downgrade the running extractor set. Merging that branch is a prerequisite for the fork-sync, not part of it.pmoves/services/pmoves-yt/Dockerfile— a known orphan (pmoves/configs/dockerfiles/_known_orphans.yaml) installing stock PyPI yt-dlp. Compose builds../PMOVES.YTwithpmoves_yt_service/Dockerfile, installing the fork from source.Changes
pmoves/docs/services/pmoves-yt/YTDLP_CURRENCY.md— leads with the commands (which do not rot), then dated measurements, then the gap stated as facts for the fork-sync lane. Enrolled inliving_docs_registry.yamlat P2 / 60d so its dated section rots visibly — a stale number there is the exact failure being corrected, so CI should be able to see it.yt-dlp-bump.ymlkeeps the extractor lane current on a weekly cadence", the workflow-table description, and the Hardened-Summary runner label (readself-hosted, vps; the workflow hasruns-on: ubuntu-latest).POWERFULMOVES/yt-dlp.git@mainstill resolved via GitHub's rename redirect, butmaincarries none of the PMOVES commits, so it silently installed a plain upstream mirror. NowPOWERFULMOVES/PMOVES.YT.git@PMOVES.AI-Edition-Hardened.yt-dlp-bump.ymlnow says what it did — subject, branch, tracker line and PR body all state that no pin moved.Verification
git/ghstubbed: exit 0, heredoc terminates,${VERSION}substitutes, tracker line and PR body render correctly.living_docs_registry.yamlparses and the new entry resolves.make -C pmoves docs-reconcile-checkreports the same 8 findings, sameError 1, with and without this branch (confirmed by stashing) — all pre-existing dashboard/SITREP drift, none related to this change and none caused by the new doc.yt_dlp/version.pyanddevscripts/update-version.py, which are intentionally paths inside the submodule/upstream.Village Rule
CLAIM appended to
pmoves/docs/AGENTS/AGNOTE4482PHI.t1.mdbefore editing —2026-08-27T15:10:00Z,ACK::B850-CLAUDE::YTDLP-CURRENCY-RECONCILE-CLAIM::2026-08-27. CHIT trail unsigned-local (nosign-trailmake target exists).Routed, not done here
PMOVES.YT/pmoves_yt_service/README.md:114carries the same false claim ("opens a PR with the latest yt-dlp"). It lives in the submodule — correcting it needs a submodule PR, and editing it here would move the gitlink. Left for the fork-sync lane.channel-monitorat yt-dlp 2024.10.7 is its own lane; a prior trail entry reports it returns 0 entries from flat playlist extraction while logging "No new videos".yt-dlp-bump.ymlshould arguably be renamed or made to open a real fork-sync PR. This PR only made it honest about what it currently does.🤖 Generated with Claude Code
https://claude.ai/code/session_01FkwiW3VY1xWmahTAtVioxz