odoo-risk-overview

name	odoo-risk-overview
argument-hint	[module/upgrade scope]
description	Produce an executive-level Odoo risk dashboard - quantifying upgrade risk (deprecated API counts), change blast radius (how widely a field/method is depended on), and dependency health - into a one-page summary a CEO or CTO can act on, scoped to the active tenant profile + target version (confirm both if unstated). Use ANY time a manager, sponsor, or executive asks about Odoo system health, upgrade readiness, or "how risky is it to change X?". Pushy trigger: "give me a risk overview", "what's the upgrade risk", "is it safe to upgrade", "blast radius if we deprecate field X", "technical debt - give me numbers". Also fires on Vietnamese: "rủi ro nâng cấp", "nâng cấp có an toàn không". Trigger especially on a deadline or decision context ("board meeting", "before we commit budget", "RFP due"). When the user wants a per-line technical audit of deprecated APIs (not an executive summary), route to odoo-deprecation-audit. When they want module-by-module business inventory, route to odoo-customization-inventory

Role

CEO / CTO / Project Sponsor

Out of Scope

• Per-line deprecated API technical audit → use odoo-deprecation-audit
• Module-by-module business inventory → use odoo-customization-inventory
• Tactical override/extension guidance → use odoo-override-finding

MCP tools

Pick the right tool first. Odoo Semantic (the odoo-semantic-mcp server) is the INDEXED Odoo source-code knowledge graph: a pre-built graph + vector index of Odoo source across every indexed Odoo version (legacy through latest) and repos/editions, with inheritance, override, and cross-module impact already resolved. It gives AUTHORITATIVE STRUCTURAL facts about how Odoo source IS DEFINED, with no local checkout needed. Unique signature: indexed, cross-version, inheritance-resolved, whole-graph, checkout-free. It is a STATIC index with NO runtime/live data.

This is your PRIMARY, context-efficient source for Odoo source/structure questions - the Odoo codebase is huge and reading it directly burns context, so prefer Odoo Semantic first. Order of precedence: (1) Odoo Semantic available -> use it; (2) available but it lacks the specific detail -> THEN read the source (Read/Grep your checkout) to fill that gap; (3) unavailable -> read the source. Reading code is the FALLBACK, never the first move when Odoo Semantic can answer.

Do NOT use Odoo Semantic for:

• LIVE DATA / runtime - actual record values, search/read/write real records, executing a method, this instance's installed modules -> use a live Odoo MCP server (one exposing read_record/search_records/execute_method), NOT Odoo Semantic.

Look-live-but-static tools (return indexed source, never runtime data): model_inspect, module_inspect, entity_lookup, validate_domain, validate_depends, validate_relation. These tool names look like they query a live instance but return indexed source data only. If you need live records, Odoo Semantic is the wrong server.

Session bootstrap (call once at session start):

• set_active_profile(profile_name='<viindoo_profile from <SHARE_DIR>/context.md>') - Pin tenant profile for the session so subsequent calls scope to one customer profile.
• set_active_version(odoo_version='17.0') - Pin a CONCRETE Odoo version (sentinels like 'auto' are rejected; the call doubles as a cheap reachability probe; 24h idle TTL).

Primary tools:

• check_module_exists - Verify module availability, edition (CE/EE/Viindoo), and cross-version presence.
• find_deprecated_usage - Scan the indexed codebase for usages of deprecated API patterns.
• impact_analysis - Risk assessment of changing or removing a field, method, or model: blast radius, dependent modules, and downstream fields.
• model_inspect ★ - Superset inspection of an ORM model: enumerate or fully describe fields, methods, views, extenders, or a summary in one call.
• module_inspect ★ - Module-level architecture overview: manifest summary, models defined/extended, views, OWL components, QWeb templates, JS patches, module dependency chain, or test class list in one call.
• profile_inspect - Profile-level introspection discriminator (ADR-0028): inspect a tenant profile's composition in one call.

Context

Three risk dimensions for executives:

1. Upgrade risk - deprecated API count that will break when upgrading.
2. Change blast radius - places affected when a key field/model is modified.
3. Dependency health - custom modules depending on features that may disappear.

Risk levels: Low (0-2 deprecated APIs, no high-impact fields, all deps stable) / Medium (3-10 deprecated APIs, or 1-2 high-impact fields) / High (10+ deprecated APIs, or critical business field with wide blast radius - requires dedicated migration project).

Version era multiplier: within same era (e.g. v16→v17) = Low; cross-era (e.g. v12→v16) = Medium; OpenERP to modern (v8/v9→v12+) = Very High.

Distribution note: modules with consistent naming (e.g. viin_*) are distribution-maintained - flag separately; their risk is generally lower than truly custom modules.

Data priority: MCP tool results are ground truth for deprecated API counts and blast radius. Training knowledge is for interpreting business impact and recommending remediation.

Instructions

Steps 1, 2, and 3 are fully independent - fire them simultaneously.

Round 0 - Pin version + profile + enumerate scope: set_active_version(...) + set_active_profile(...), then profile_inspect(method='modules', name=<profile>, odoo_version='<version>') to auto-enumerate in-scope modules from the index.

Round 1 - Parallel: Call find_deprecated_usage + impact_analysis (on highest-usage custom fields known from context) + check_module_exists (for all custom module dependencies) simultaneously.

Round 2 - Parallel: Call model_inspect(model=…, method='fields', odoo_version='<version>') on heavily customized models from Round 1. Simultaneously call module_inspect(name=<name>, method='summary', odoo_version='<version>') for each custom module - surfaces JS patch counts, view counts, and models defined/extended. If hotspot models are already known from context, include model_inspect in Round 1 to reduce to a single round.

Focus impact_analysis on fields with high used_by counts. Count BREAKING vs WARN severity from find_deprecated_usage. Synthesize into a concise executive table - minimal prose, let the table carry data. Close with a one-sentence recommended action tied to the highest-risk item.

Standalone-first fallback

When OSM unreachable, follow ${CLAUDE_PLUGIN_ROOT}/snippets/disk-fallback-protocol.md:

• Tier 2 (disk): find . -maxdepth 3 -name "__manifest__.py" to discover modules, Read each manifest for classification clues, and grep for deprecated patterns (@api.multi, _columns, osv.osv, web.Widget) directly in source. Build the risk overview without asking the user.
• Tier 3 (training): If no readable source available, produce a heuristic estimate and label OSM unavailable - ungrounded with caveat "deprecated API + blast radius not yet scanned - verify with detailed audit when OSM is online".

Output format

## Odoo Customization Risk Overview

**Assessment date:** <date>
**Current Odoo version:** <version>
**Target upgrade version:** <version or "Not specified">
**Modules assessed:** <N>

| Module | Type | Deprecated APIs | JS patches | Views | High-impact fields | Upgrade risk | Priority |
|--------|------|:---------------:|:----------:|:-----:|:------------------:|:------------:|:--------:|
| ...    | Custom/Distribution | ... | ... | ... | ... | Low/Med/High | 1/2/3 |

### Key findings
- <finding 1 - most important risk with module name>
- <finding 2>
- <finding 3>

### Risk summary by category
- **Upgrade risk (deprecated APIs):** <Low/Med/High> - <N> BREAKING issues across <N> modules
- **Change blast radius:** <Low/Med/High> - <field/method> affects <N> downstream points
- **Dependency health:** <Low/Med/High> - <N> dependencies unverified in target version

### Version migration complexity
<Low/Medium/High/Very High> - <rationale based on era and version gap>

### Recommended action
<One concrete, specific sentence: "Prioritize migration of `module_x` before the v17 upgrade window
because it has N breaking changes in core method Y.">

Examples: ${CLAUDE_PLUGIN_ROOT}/skills/odoo-risk-overview/references/examples.md

Continuation Contract

When you finish, append a Continuation Contract block per ${CLAUDE_PLUGIN_ROOT}/snippets/continuation-contract.md (status / produced / next). Additive output for the run-harness - it does not change anything produced above.