Dependency auto-heal (a broken package is repaired, then the check runs once more)
Sometimes an interrupted install leaves a package on disk present but broken: the folder is there and a file inside it is missing. A check then dies with a "cannot find module" error naming a path into that folder — which looks like your code broke, and is not. Omniscio recognises that state, repairs the one package named in the failure, and runs the check again. If the tear was the only problem the check now passes; if it was a real failure you get the real failure back, unchanged.
What it is
The checks Omniscio runs for a branch — the build, the tests, the lint run — work against a folder of dependencies on your computer. Occasionally that folder is left torn by an interrupted install.
Dependency auto-heal treats a torn package as a repairable state rather than a failure. It reads the broken package's name out of the failure message, removes that one package and fetches it again, then retries the check once.
Where to find it
There is nothing to switch on and no screen to open — it is automatic. You meet it in the checks the app runs for a branch, and in the single log line it writes when it repairs something: the check failed naming the torn package, repaired it, and retried once.
On the app's own side, when a cloud feature cannot start because a local dependency is corrupted, you meet it as one inbox card that tells you to reinstall.
How it behaves
- It only runs after a failure. A check that passes is byte-for-byte the same as before; the repair never runs on a green check.
- It names the package from the failure itself, rather than from a fixed list, so any torn package can be caught.
- It repairs only what it named. That package's folder is removed and reinstalled, so the missing file really comes back.
- It retries exactly once. There is a hard one-retry cap: never a loop, and never a hidden error.
- A genuine failure is returned untouched. The repair must not mask a real problem, so a failure that is not a tear reads exactly as it always did.
- It fails closed. If the repair does not complete, the original failure stands and the app points you at the full repair command instead of pretending nothing changed.
- It stands down on bulk problems. Only packages the lockfile pins are repaired, and several packages reported missing at once is treated as a broader install problem rather than a single tear.
- A check the watchdog killed is a timeout, not a tear, so it is never retried.
- Off with one switch.
AMC_DISABLE_DEP_HEAL=1turns the heal off; the corrupted-dependency card is raised at most once per session.
Related
- Dev Pipeline Maintenance — the daily housekeeping skills that ride with the Dev Pipeline
- Crash recovery — recovering from a broken state after an interrupted run
- App is already running, or frozen — restarting a stuck copy safely
Last verified 2026-10-26