EGO-L-004 and EGO-L-006 should be false positives. I fixed all the other warnings as we agreed on Matrix. Thank you!

1. `this.destroyed` is a bad practice. Please remove that. 2. Please don't send unnecessary code. Something like `force_exit` shouldn't be wrapped with try-catch. and don't use `?.()` when it's obvious that the function exist. 3. Why are you checking for `pkexec`. Why not simply calling `pkexec`? - line 719 `src/network/networkMonitor.js` - line 152 `src/storage/storageMonitor.js` BTW, at some point this should be an app rather than GNOME Shell extension since it has too much spawn commands. The app can be a dependency for this extension and they can talk to each other with d-bus: [D-Bus Guide](https://gjs.guide/guides/gio/dbus.html)

1. Yeah, that was pretty useless too. I removed it. 2. There was a comment about those that got stripped in the tsc compilation. force_exit() is best-effort during cleanup: the subprocess may have already exited or been cancelled by the time teardown runs. We previously tried to avoid calling it by checking the process state first, but that proved unreliable: in some cases the subprocess looked already terminated while still leaving resources hanging unless force_exit() was called. The try/catch avoids turning this harmless cleanup race into noisy user-visible log exceptions, which some users had reported in some cases. About ?.(): since this is TypeScript source, in some places I have to use either ?. or !. to satisfy tsc nullability checks. I may not always have picked the best option between the two, but there are hundreds of occurrences in the codebase, so without a specific line it is impossible to know which one is considered unnecessary. If you mean in the `proc?.force_exit();` line, I have already changed it to `proc!.force_exit();` in the repo. 3. pkexec is not really being “checked” before every call; we resolve its path once and cache the result. By default we use the command available in PATH, but resolving it explicitly is important because on some distros/setups, assuming a plain pkexec call may not work reliably. If it cannot be found, preferences already warn about the missing dependency and suggest installing it. Since the related features are optional, this also keeps the extension usable for users who choose not to install pkexec or do not need elevated-privilege functionality. BTW, yes, the long-term idea is to have a companion app for the extension. That would be a better architecture for some of this, especially for privileged/system-level operations. However, the current principle is to keep the extension usable by as many people as possible, including users who do not want to install extra dependencies. That is why all external dependencies are treated as optional. Building and maintaining a companion app also takes a significant amount of time, and I work on this extension in my free time out of passion. Many users have told me Astra Monitor is one of the few things keeping them on GNOME, so I try to keep it as available and frictionless as possible, even for setups without additional dependencies. As a broader note, I hope we can keep the review process practical and balanced. GNOME Shell extensions are often maintained in limited free time, and even small requested changes can become expensive when they require revisiting edge cases that were already handled after user reports. I have also noticed that the review process seems to be getting more stricter recently, which I understand from a quality perspective. At the same time, some of the points above feel quite close to implementation-detail territory, even though there is practical reasoning behind them: they come from previous testing, user reports, and attempts to avoid regressions or noisy failures across different setups. For that reason, I would like to understand how much flexibility there is for these cases going forward. If similar implementation details can become blockers again in future submissions even when they are intentional and based on previous issues, the process can become quite difficult for maintainers. Having a clearer expectation would help keep future updates more predictable for everyone. I mean this as a constructive note rather than criticism, and I genuinely appreciate the work you do for the whole community.

1. Yeah, that was pretty useless too. I removed it. 2. There was a comment about those that got stripped in the tsc compilation. force_exit() is best-effort during cleanup: the subprocess may have already exited or been cancelled by the time teardown runs. We previously tried to avoid calling it by checking the process state first, but that proved unreliable: in some cases the subprocess looked already terminated while still leaving resources hanging unless force_exit() was called. The try/catch avoids turning this harmless cleanup race into noisy user-visible log exceptions, which some users had reported in some cases. About ?.(): since this is TypeScript source, in some places I have to use either ?. or !. to satisfy tsc nullability checks. I may not always have picked the best option between the two, but there are hundreds of occurrences in the codebase, so without a specific line it is impossible to know which one is considered unnecessary. If you mean in the `proc?.force_exit();` line, I have already changed it to `proc!.force_exit();` in the repo. 3. pkexec is not really being “checked” before every call; we resolve its path once and cache the result. By default we use the command available in PATH, but resolving it explicitly is important because on some distros/setups, assuming a plain pkexec call may not work reliably. If it cannot be found, preferences already warn about the missing dependency and suggest installing it. Since the related features are optional, this also keeps the extension usable for users who choose not to install pkexec or do not need elevated-privilege functionality. BTW, yes, the long-term idea is to have a companion app for the extension. That would be a better architecture for some of this, especially for privileged/system-level operations. However, the current principle is to keep the extension usable by as many people as possible, including users who do not want to install extra dependencies. That is why all external dependencies are treated as optional. Building and maintaining a companion app also takes a significant amount of time, and I work on this extension in my free time out of passion. Many users have told me Astra Monitor is one of the few things keeping them on GNOME, so I try to keep it as available and frictionless as possible, even for setups without additional dependencies. As a broader note, I hope we can keep the review process practical and balanced. GNOME Shell extensions are often maintained in limited free time, and even small requested changes can become expensive when they require revisiting edge cases that were already handled after user reports. I have also noticed that the review process seems to be getting more stricter recently, which I understand from a quality perspective. At the same time, some of the points above feel quite close to implementation-detail territory, even though there is practical reasoning behind them: they come from previous testing, user reports, and attempts to avoid regressions or noisy failures across different setups. For that reason, I would like to understand how much flexibility there is for these cases going forward. If similar implementation details can become blockers again in future submissions even when they are intentional and based on previous issues, the process can become quite difficult for maintainers. Having a clearer expectation would help keep future updates more predictable for everyone. I mean this as a constructive note rather than criticism, and I genuinely appreciate the work you do for the whole community.

Thanks! Approved. But please try not adding any new spawn commands for the future updates.