ارزیاب خطر ارتقای وابستگی: تبدیل فهرستی از پکیجهای منسوخشده به یک طرح ارتقای رتبهبندیشده
چرا این پرامپت اهمیت دارد
Dependency debt compounds silently. Each deferred upgrade doesn't just add one more overdue package — it makes the eventual upgrade riskier, because more changes stack up between your current version and the one you'll be forced onto during a security incident or an end-of-life deadline. Teams that never explicitly prioritize upgrades don't avoid the work; they just do it later, under worse conditions, usually as an unplanned emergency instead of a scheduled sprint task.
ما از آن برای چه استفاده میکنیم
Your `npm outdated` output lists 34 packages behind, most flagged for major-version gaps. Your tech lead wants a prioritized upgrade plan before tomorrow's sprint planning, and you don't have time to read every changelog yourself.
پرامپت
Act as a senior engineer responsible for dependency management who has run upgrade cycles across dozens of production codebases and knows how deferred upgrades turn into emergency migrations. Context: Project type and stack: [e.g., "Node.js/TypeScript monorepo, ~200k LOC, deployed to production weekly"] Outdated dependencies: [PASTE THE LIST — package name, current version, latest version, e.g. from `npm outdated`, `pip list --outdated`, or `bundle outdated`] Changelog or release-notes excerpts, if you have them: [PASTE RELEVANT EXCERPTS, OR WRITE "NONE PROVIDED" FOR ANY PACKAGE] Team capacity this sprint: [e.g., "limited — can only take on 2-3 low-risk upgrades" or "dedicated tech-debt sprint, can absorb larger changes"] Task: For each dependency listed, assess: 1. How many major and minor versions behind it currently is 2. Its risk category — security-critical, breaking-change-heavy, or routine 3. A specific recommendation: upgrade now, schedule for next sprint, or defer (with a reason) Constraints: - Flag any dependency with a known CVE or security advisory as highest priority regardless of stated team capacity. - Clearly distinguish between "this WILL break something" (based on documented breaking changes you were given) and "this MIGHT break something" (no changelog provided, so assume moderate risk) — never present a guess with the same confidence as a documented fact. - The "upgrade now" shortlist must respect the stated team capacity — do not recommend more work than the team can realistically absorb this sprint. - If changelog excerpts weren't provided for a package, say so explicitly in your reasoning rather than inventing specific breaking changes. Output Format: 1. A ranked table: Package | Current → Latest | Risk Level | Recommendation | Reasoning 2. A "Do This Sprint" shortlist that respects the stated capacity 3. One clarifying question to ask before greenlighting the single riskiest upgrade on the list
نتیجه
| Package | Current → Latest | Risk Level | Recommendation | Reasoning |
|---|---|---|---|---|
| auth-token-lib | 2.3.1 → 2.3.9 | Security-Critical | Upgrade now | Changelog for 2.3.7 lists a fix for CVE-2026-31442, a token-validation bypass. This overrides capacity limits — security fixes are non-negotiable regardless of sprint load. |
| axios | 0.21.4 → 1.7.2 | Breaking-Change-Heavy | Schedule for next sprint | Major version jump (0.x → 1.x). Changelog confirms the default export pattern changed and several config options were renamed. This WILL require code changes across every file that imports axios directly — not a drop-in bump. |
| lodash | 4.17.15 → 4.17.21 | Routine | Upgrade now | Patch-only jump within the same minor version. No changelog excerpt was provided, but the version delta itself (patch-level only) makes breaking changes very unlikely. Low effort, safe to batch with the security fix above. |
| express | 4.17.1 → 4.19.2 | Routine | Upgrade now | Minor version bumps within Express 4.x have historically been backward-compatible. No changelog was provided for this specific range, so this is a moderate-confidence assessment, not a documented guarantee. |
| react | 17.0.2 → 18.3.1 | Breaking-Change-Heavy | Defer | Major version jump requiring the new root API (createRoot) and auditing all components for concurrent-rendering side effects. Given your stated capacity of 2-3 upgrades this sprint, this is too large to absorb alongside the security fix — defer to the dedicated tech-debt sprint. |
Do This Sprint (respecting stated capacity of 2-3 upgrades):
- auth-token-lib (security-critical, mandatory)
- lodash (near-zero risk, low effort)
- express (routine, moderate confidence)
Clarifying question before greenlighting axios 1.x: Do you have integration test coverage on every code path that calls axios directly, or only on the handful of endpoints your team remembers using it? A breaking-change-heavy upgrade is far riskier in code paths without test coverage, since you won't catch a broken call signature until it fails in production.
هر تیم مهندسی با انباشتی از وابستگیهای منسوخشده روبهرو میشود و تقریبا همه تیمها به همان روش نارضایتبخش با آن برخورد میکنند: شخصی نگاهی به خروجی میاندازد، حس عذاب وجدان کوتاهی پیدا میکند و سراغ کار روی قابلیتها میرود. مشکل کمبود آگاهی نیست، بلکه این است که تبدیل کردن فهرستی از بیش از سی پکیج به یک برنامه اولویتبندیشده واقعی، زمان زیادی میبرد و این زمان مستقیماً با انتشار محصول رقابت میکند. این پرامپت ساخته شده است تا آن کار تریاژ را در یک مرحله فشرده کند.
چرا این پرامپت به این شکل ساختار یافته است
محدودیتی که مدل را ملزم میکند هر CVE شناختهشده را، صرفنظر از ظرفیت اعلامشده تیم، بهطور خودکار دارای بالاترین اولویت بداند، به این دلیل وجود دارد که اصلاحات امنیتی تنها دستهای از کارهای مربوط به وابستگی هستند که در واقع اختیاری نیستند. پرامپتی که اجازه دهد «ظرفیت محدود» بهصورت بیصدا یک پچ امنیتی را از اولویت خارج کند، برای اتکا به شدت خطرناک خواهد بود؛ هدف اصلی از خودکارسازی این تریاژ این است که مطمئن شویم هیچ چیز مهمی از قلم نمیافتد، نه اینکه بهانهای راحت برای رد کردن آن فراهم شود.
تفاوت بین «این قطعاً چیزی را خراب خواهد کرد» و «این ممکن است چیزی را خراب کند» مهمترین محدودیت در کل پرامپت است و دلیل حضور آن این است که شایعترین حالت خرابی در برنامهریزیهای به کمک هوش مصنوعی، اعتماد کاذب است. مدلی که یک گزیده از تغییرات (changelog) را دریافت میکند که تغییر شکستهکننده در API را تأیید میکند، روی زمین محکمی قرار دارد. مدلی که از آن خواسته میشود حدس بزند آیا ارتقای نسخه بدون مستندات امن است یا خیر، کاری به طور بنیادین غیرقابلاعتمادتر انجام میدهد؛ و اگر هر دو با همان لحن مطمئن ارائه شوند، برنامه به شدت گمراهکننده میشود. وادار کردن مدل به مشخص کردن اینکه هر ارزیابی در کدام دسته قرار میگیرد به این معناست که دقیقاً میدانید به چه توصیههایی میتوانید در نگاه اول اعتماد کنید و کدامیک پیش از متعهد شدن به آنها، نیاز به بررسی پنج دقیقهای تغییرات دارند.
محدودیت ظرفیت همان چیزی است که این گزارش را از یک گزارش وابستگی عمومی به یک ابزار واقعی برنامهریزی اسپرینت تبدیل میکند. ارزیابی ریسکی که میزان کاری را که تیم شما واقعاً میتواند در این هفته جذب کند نادیده بگیرد، توصیهای برای یک تیم فرضی است، نه تیم شما. وادار کردن فهرست کوتاه «انجام این کار در این اسپرینت» به تبعیت از یک عدد ظرفیت مشخص به این معناست که خروجی چیزی است که میتوانید مستقیماً به برنامهریزی اسپرینت تحویل دهید، به جای اینکه خودتان آن را ترجمه کنید.
چرا فرمت جدول اهمیت دارد
استفاده از یک جدول رتبهبندیشده به جای یک متن روایی، عمدی است. تریاژ وابستگی در اساس یک کار مقایسهای است — شما چندین پکیج را در برابر یکدیگر میسنجید تا تصمیم بگیرید چه چیزی در ظرفیت محدود جای میگیرد — و یک جدول به شما اجازه میدهد به شکلی که یک فرمت پاراگراف به ازای هر پکیج اجازه نمیدهد، متن را اسکن کنید و ذهناً دوباره مرتبسازی کنید. سوال روشنکننده پایانی درباره پوشش تست به این دلیل وجود دارد که بزرگترین ریسک پنهان در هر ارتقای همراه با تغییرات ساختاری، خودِ تغییر نیست، بلکه این است که آیا در واقع متوجه میشوید اگر چیزی را خراب کند یا خیر؛ و این سوالی است که مدل میتواند از شما بخواهد به آن پاسخ دهید اما نمیتواند آن را روی پایگاه کد خودتان جواب دهد.
چگونه آن را تطبیق دهیم
برای یک پایگاه کد با دسترسی ضعیف به تغییرات (پکیجهای خصوصی، پروژههای متنباز رهاشده با یادداشتهای انتشار پراکنده)، انتظار داشته باشید که موارد بیشتری بهطور پیشفرض در دسته «ممکن است چیزی را خراب کند» قرار گیرند — این کارکرد صحیح پرامپت است، نه شکست آن. در چنین وضعیتی، ارزش دارد که خروجی را با یک بررسی سریع از مسائل گیتهاب هر پکیج برای گزارشهای باگ اخیر پیش از نهایی کردن برنامه اسپرینت ترکیب کنید.
برای تیمهایی که این کار را به جای هر اسپرینت، بهصورت فصلی انجام میدهند، چارچوب ظرفیت را از «این اسپرینت» به «این فصل» تغییر دهید و در نظر داشته باشید که درخواست پاس دوم کنید که پکیجها را بر اساس Framework زیربنایی مشترک گروهبندی کند (مثلاً «همه پکیجهای اکوسیستم React»)، زیرا ارتقاهای نسخه اصلی در یک Framework اصلی اغلب مجبورند پکیجهای مرتبط را نیز بهصورت هماهنگ بهروزرسانی کنند.