Proposal: /career-ops update command with diff preview and compatibility check

[FReptar0]

Problem

The current update flow (update-system.mjs check → user says yes → apply) works but is a blind operation. Users don't see:

1. What changed between their version and the new one — which modes were modified, what scripts changed, whether the scoring system evolved
2. Whether the update affects their customizations — if _shared.md archetypes were renamed or the scoring system changed, their _profile.md references might become stale
3. What's new — new modes, new scripts, new capabilities that the update introduces

This is especially relevant now that career-ops is growing fast (new language modes, ATS normalization, interview-prep mode, liveness checker, etc.). Users who customized heavily need confidence that an update won't break their workflow.

Proposal

Add a /career-ops update subcommand that orchestrates the existing update-system.mjs with visibility:

Step 1 — Check

Same as today: node update-system.mjs check. No change to the script.

Step 2 — Show what changed

Before applying, fetch upstream and show a categorized diff summary:

Update available: v1.2.0 → v1.3.0

Changes summary:
- Modes: 4 files changed (oferta.md, _shared.md, scan.md, pdf.md)
- Scripts: 2 files changed (generate-pdf.mjs, normalize-statuses.mjs)
- Dashboard: 1 file changed
- New: modes/interview-prep.md, check-liveness.mjs

Your personal files (CV, profile, tracker, reports) will NOT be touched.

Users can ask for details on any specific file.

Step 3 — Compatibility check

Read-only analysis of potential impacts:

• If _shared.md archetypes changed → warn that _profile.md references might be stale
• If scoring system changed → note that future scores may differ slightly
• If new modes were added → highlight them

Step 4 — Confirm and apply

User confirms → node update-system.mjs apply → node doctor.mjs → offer to fix stale _profile.md references (with explicit consent only).

Step 5 — Rollback

/career-ops update rollback → node update-system.mjs rollback. Same as today but accessible as a subcommand.

Design decisions

• Does NOT modify update-system.mjs — orchestrates it as-is
• Purely additive — new mode file (modes/update.md) + routing entry
• Never touches User Layer files except with explicit confirmation for _profile.md compatibility fixes
• 3 files total: modes/update.md (new), SKILL.md (add routing), CLAUDE.md (add to modes table)

Status

I have a working implementation in my fork (feature/update-command branch) that passes test-all.mjs (57/57). Not submitting a PR until we discuss the approach here — learned from my earlier contributions that architectural additions benefit from alignment first.

Questions for discussion:

1. Does this scope feel right, or would you prefer a simpler version (e.g., just the diff preview without compatibility checking)?
2. Should the compatibility check also look at portals.yml for changes to portals.example.yml format?
3. Any concerns about the mode reading _profile.md during the compatibility check (read-only, never writes without consent)?