The removable set is fixed the moment you know `k`: it's every method `k` can reach through the call graph, nothing more. The only real question is whether removing that whole block leaves a dangling call from a method that survives. My first instinct was to reason method-by-method — "can I drop this one?" — but removal here is all-or-nothing. Either every suspicious method goes or none do, so per-method logic tangles you up for nothing. I collect the reachable set once with a DFS from `k`, then ask a single yes/no question: does any edge cross from outside the set into it? If such an edge exists, some surviving caller would invoke a deleted method, so nothing gets removed and every method stays. Otherwise the reachable set is safe to cut and I return the rest. ### Worked example Take `n = 5`, `k = 0`, `invocations = [[1,2],[0,2],[0,1],[3,4]]`. A DFS from `0` reaches `1` and `2`, so the suspicious set is `{0,1,2}`. Now scan every edge for one crossing inward: `[1,2]` both inside, `[0,2]` both inside, `[0,1]` both inside, `[3,4]` both outside — none cross in. So `{0,1,2}` is safe to delete, and the answer is `[3,4]`. ### Complexity - Time `O(n + m)` — one DFS over the graph plus one linear scan of the `m` invocations. - Space `O(n + m)` — the adjacency list stores every edge, and the suspicious flags plus the stack are `O(n)`. ### Code (C++) ```cpp class Solution { public: vector remainingMethods(int n, int k, vector>& invocations) { vector> adj(n); for (auto& e : invocations) adj[e[0]].push_back(e[1]); vector sus(n, 0); vector stk = {k}; sus[k] = 1; while (!stk.empty()) { int u = stk.back(); stk.pop_back(); for (int v : adj[u]) if (!sus[v]) { sus[v] = 1; stk.push_back(v); } } for (auto& e : invocations) { if (!sus[e[0]] && sus[e[1]]) { vector res(n); for (int i = 0; i < n; i++) res[i] = i; return res; } } vector res; for (int i = 0; i < n; i++) if (!sus[i]) res.push_back(i); return res; } }; ``` ### One note The direction of the crossing edge is the whole trap. I only care about an edge running from an outside method into the suspicious set — a suspicious method calling outward is fine, because that outside target is not being deleted. Flip the check to `sus[e[0]] && !sus[e[1]]` and you would reject perfectly removable projects. When a graph problem hinges on "who depends on whom", write down which endpoint is the caller before you touch a line of code.