fix(aeon-update): don't silently delete a currently-enabled skill retired upstream

[Svector-anu]

What

aeon-update's 3-way classifier CLEAN-DELETEs any skills/<name>/ path that upstream removed and the operator never modified locally (S6), but never checks whether <name> is still enabled: true in the operator's own aeon.yml. A PR from this skill could delete an actively-scheduled skill's directory while aeon.yml still references it, and nothing in the PR review surfaces that — the break only shows up later, when validate-config.js's skill-refs check (or the skill's own next scheduled run) fails.

Why

Hit this for real doing a manual upstream sync on a live instance: the recent restructure (#647) retired verdikta-hunter, x402-monitor, and fear-divergence, all three enabled and unmodified locally, which meant a plain git merge upstream/main silently deleted their directories while aeon.yml still had them scheduled. Had to manually cross-reference every clean-deleted skill against the live config to catch it before merging.

Fix

Downgrade this specific case (removed upstream + unmodified locally + enabled: true in current aeon.yml) to a CONFLICT instead of a CLEAN-DELETE, with a new reason enabled-skill-removed-upstream. The skill directory stays untouched, and the PR body gets its own loud section for this case instead of it disappearing into "Applied cleanly":

### ⚠️ Currently-enabled skills removed upstream
For each CONFLICT with reason `enabled-skill-removed-upstream` (S6):
- `verdikta-hunter` — enabled in your `aeon.yml`, deleted upstream in {commit(s)}. **Not deleted here** so nothing breaks. Pick one: keep it as a fork-only skill going forward (nothing else to do), or disable it in `aeon.yml` to match upstream's current default set.

Also handled the resolve-tracking side: PENDING conflicts normally resolve by comparing local vs. the upstream HEAD blob, but this reason has no HEAD blob (the path is deleted upstream) — added the correct resolution rule (resolved once the operator disables the skill, or upstream re-adds a path of that name).

Scope

Docs-only change to skills/aeon-update/SKILL.md — no code, no schema, no frontmatter changes. check-skill-categories.sh passes; frontmatter untouched.

Provenance

AI provider/model: anthropic / claude-sonnet-5
Client / agent tooling: Claude Code, direct interactive session (not a Slop/measured skill run — this is the aeonfun/aeon repo itself, not an elizaOS contribution-program project)

[Svector-anu]

@aaronjmars while you're looking at this one — separate from the fix itself, I wanted to flag that I'd be interested in helping out with devex/DevRel if there's room for it, informal or otherwise.

quick track record, not a pitch on potential:

• this PR — found a real gap in aeon-update: it silently deletes a currently-enabled skill's directory if upstream retires it, no warning anywhere in the review flow. fix + repro above.
• hunter-22: bounty discovery with a one-tap audit handoff to vuln-scanner #864 — designed and shipped hunter-22 (bounty discovery → one-tap vuln-scanner handoff), merged
• vuln-scanner: fuzz targets a repo already ships (cargo-fuzz) #863 / vuln-scanner: stage cargo-fuzz toolchain + widen sandbox grant #868 — cargo-fuzz toolchain staging + sandbox grant for vuln-scanner, merged

what I'd bring: I already run the "run it hard, find what breaks, fix it, ship it" loop on my own instance daily, and I'm happy to keep doing that publicly — writeups, threads, walking other devs through setup — pointed at whatever's the current priority (skill-ecosystem growth looks like the focus from the last few weeks of commits).

no pressure to respond here specifically, just wanted it on your radar. happy to talk whenever works.

[aaronjmars]

Thanks for this — the actual skills/aeon-update/SKILL.md change is solid. The S6 downgrade to enabled-skill-removed-upstream (instead of a silent CLEAN-DELETE), the S8 resolve rule for entries with no HEAD blob, and the new S9 PR-body section all fit the skill's existing step structure and idioms. Worth landing.

The blocker is the branch itself, not the change. The PR body says "docs-only, one file, no code/schema/frontmatter," but the diff is 132 files, +18,277 −92 — it looks like the branch was cut from a live instance clone, so it's dragging that instance's whole divergence on top of the one doc edit:

• Instance-only skill dirs canon doesn't have (fear-divergence, verdikta-hunter, x402-monitor)
• Run-scratch leaks (.mcp.json, .vuln-probe.sh, .pending-notify-*.md, .pvr-payload.json, cg_*.json, dexs.json, fees.json)
• ~30 apps/dashboard/outputs/*.json, plus memory/logs/*, memory/skill-health/*, and leaked memory/pending-disclosures/* drafts
• Instance config drift: STRATEGY.md, aeon.yml, catalog/*, docs/status.md

That pollution is also what's turning CI red — none of it is your SKILL.md change:

• verify: fear-divergence / verdikta-hunter / x402-monitor have no eyebrowlock.json entry (they only exist on your instance)
• test: catalog/packs.json reports 78 skills but the README caption says 75 (your instance catalog)

Could you re-cut the branch off clean canon main with only skills/aeon-update/SKILL.md? Something like:

git fetch origin
git checkout -b fix/aeon-update-warn-enabled-skill-removal-v2 origin/main
git checkout <current-branch> -- skills/aeon-update/SKILL.md
git commit -m "fix(aeon-update): don't silently delete a currently-enabled skill retired upstream"

Then force-push (or open a fresh PR). Once it's that single file, CI should go green and this is a merge. Thanks!

[Svector-anu]

Confirmed the diff — re-cut off clean main per your recipe, verified git diff --stat upstream/main <branch> shows only skills/aeon-update/SKILL.md (1 file, +8/−2) before pushing. Opened #874 with just that commit. Closing this one.