パッケージレジストリ・拡張ストア・アプリストアなどで「利用実績が多い × 長期間更新されていない」を参入余地のシグナルとして数値逆引きする市場調査手法では、停滞シグナル単独で「放置された需要」と読むと誤検出する。停滞には「放置」と「完成」の2種類があり、区別は未解決の痛みの在庫で行う。

判断基準

• 参入余地と読んでよい停滞: 利用が多く、未解決 issue や不満レビュー（痛みの在庫）が積み上がっているのに更新が止まっているもの。需要側の要求が変化し続けているのに供給が追従していない状態。
• 参入余地でない停滞: 機能表面積が小さい純関数ユーティリティ（色空間変換のような数十行の写像など）が何年も更新されないケース。仕様が安定して「完成」しているだけで痛みの在庫がほぼゼロであり、利用者に置き換える理由が無い。
• 判定は「人気 × 停滞」の2軸に「痛みの在庫（未解決 issue 数・不満レビュー数）」と「機能表面積（対象の仕様・環境が動き続ける領域か）」を加えて行う。

落とし穴

• GitHub API が返す open issue 件数は open PR を含むため、痛みの在庫を系統的に過大評価する。停滞リポジトリほど未マージ PR が積もるので、issue 単体を数え直してから判断する。
• 利用数（ダウンロード数など）は CI 等の機械的トラフィックで水増しされるため、絶対値でなく相対比較と推移で読む。

検証方法

候補に挙げた停滞プレイヤーについて、直近1年でも issue 起票・不満レビューが継続しているか（需要側の要求変化が現在も起きているか）を確認する。起票が続いていれば放置、止まっていれば完成に近い。