Dependency Watch

Dependency watch

Produce an advisory report about dependencies consumed by origin/dev. This workflow does not bump dependencies, build Telegram, create queue records, commit, push, open PRs, or apply backports. Those are separate implementation requests.

Snapshot and scope

Run from the repository root:

python3 .agents/skills/dependency-watch/scripts/watch.py snapshot

The helper fetches only origin/dev, resolves it once, and reads Git blobs at that exact commit without switching branches or touching working files. It prints the snapshot directory and report storage root. A failed fetch is a failed current check; do not present an older remote ref as freshly checked. --no-fetch is for offline testing only and marks its snapshot as unverified.

Read snapshot.json, candidates.json, and the relevant files in sources/. Candidates are navigation aids, not a complete parsed dependency inventory. Inspect the full union of prepare, Docker, Snap, Qt selection, workflow and package/lock files. Snapshot gitlinks and .gitmodules identify exact submodule revisions; inspect their dependency declarations recursively, especially CMake, WebRTC, codecs, and bundled image/font/compression/crypto libraries. Add newly discovered dependencies on every run; never restrict coverage to yesterday's list. Distinguish shipped libraries, system-provided components and build tools.

Read repository history at the snapshot commit to explain divergent pins and holds. Derive platform conditions from the recipes. A library disabled in one configuration can still be relevant on another platform. A source manifest does not establish what is installed or what already shipped to users.

Store research caches and reports in the helper's storage_root, inside Git's common directory. Read its previous latest.json and latest.md when present. Inspect external Git repositories through APIs or isolated caches there; do not fetch, checkout, or reset the user's prepared libraries or live submodules. Do not execute downloaded build scripts or import the prepare script to read it.

Release and advisory checks

For every dependency record its identity, upstream, current version/revision, manifest locations, platform/configuration, release scheme and supported series. Fetch official release/tag metadata and release notes; check security advisories independently, including advisories published since a release. Search vendor security pages and GHSA/OSV/CVE sources as appropriate; native C/C++ projects may not have package identifiers in advisory databases. Absence from a database is not evidence of safety. Cite primary sources and dates for actionable claims.

Use watch.py compare CURRENT CANDIDATE for ordinary three-component stable versions. It rejects prereleases and unsupported schemes as unknown; inspect upstream version policy for those instead of forcing SemVer on commit hashes, dates, Chromium milestones, OpenSSL legacy letters, or four-component versions. For 0.x, also assess compatibility from upstream notes. Compare all maintained release series we consume, not just the upstream API's single latest release.

Read release-trust.md before recommending any candidate. Track update urgency separately from the decision to update, backport, hold, skip, or track. A patch number sets a review priority; it does not establish release trust, compatibility, or readiness to adopt.

Rank findings as follows, subject to that assessment:

• Strong suggestion: a newer stable patch in a consumed series that passes the release assessment, or a confirmed applicable security fix missing from our pinned sources/patches with an assessed update/backport route. Known exploitation or exposed memory-safety flaws rank above routine patches.
• Weaker suggestion: a minor release, with concrete benefits and migration costs where known.
• Track only: a major release or upstream milestone gap without an identified applicable security fix. Track end-of-support dates; an unsupported consumed branch or security fix available only in a newer series can require urgent migration despite its version classification. A suspect replacement does not become acceptable merely because the current branch is unsupported.

An intentional hold does not hide patch releases or security findings. Show the reason for the hold beside the recommendation. Deduplicate the same dependency across recipes, preserving different platform series and patch revisions. For distro-provided packages, check the distribution's full package revision, security tracker and backports. Record artifact/package resolution as unknown when unavailable; an old upstream version alone does not prove vulnerability. Track Docker base images, mutable package installs and Snap runtime/content snaps as separate update/rebuild concerns even when no source pin changed.

Read forks.md when checking patched or copied upstreams; always apply it to tg_owt and tg_angle when present in the snapshot.