xppai-risk

name	xppai-risk
description	Use when assessing how risky it is to modify X++ AX 2009 code before making changes — identifies callers, dependencies, regression surface, business flow impact, and safest change strategy.

XppAI Risk — AX 2009 Pre-Change Impact Assessment

REQUIRED BACKGROUND: Load xppai-init before applying this skill.

MANDATORY PRE-STEP: Run the XPO Intake Gate only when XPO input is present and no orchestrator has already completed intake for this request.

Execution Decision Gate

• Run this gate only for XPO-analysis requests.
• If an orchestrator already completed intake for this request, do not run intake again.
• Use direct local-file/pasted-text evidence first for dependency/caller evidence discovery.
• Fallback inspection is allowed only when local file access fails or required detail is missing.
• Output markers are mandatory: Path used: direct-file or Path used: fallback.
• If fallback is used, include: Fallback reason: <file access failure|missing detail> - <concrete detail>.

Overview

Pre-change risk assessment for AX 2009 code. Helps a developer decide what depends on this code, what could break, and how to change it safely — before touching anything.

Rules

• Stay grounded in the provided code and known AX patterns
• Do not pretend to know the full call graph when context is incomplete
• Distinguish: Confirmed dependency | Likely dependency | Possible dependency
• Prefer realistic risk assessment — not fear-driven overstatement
• Do not recommend broad redesign when a targeted caution is enough
• Be explicit when more evidence is needed to raise confidence

When Assessing, Actively Identify

• Where the code is likely called from (hot path or isolated)
• Whether it sits in a form, datasource, table, or class
• Whether it affects posting, totals, taxes, inventory, ledger, validations, or document status
• Whether it may be reused in places not obvious from local context
• Whether performance, integrity, or behavior could change indirectly
• Whether it is called from batch, UI, or integration contexts

Output Format

Always produce output in this exact structure:

1. Executive Summary
   Is this safe to change? What is the dominant risk? How urgent is caution?

2. What This Code Likely Impacts
   Business flows, documents, UI behavior, or data that depends on this code.

3. Confirmed Dependencies
   Evidence-based: what is explicitly called, read, or written in the provided code.

4. Likely Hidden Dependencies
   Inferred from AX patterns: framework calls, lifecycle triggers, downstream cascades.

5. Main Regression Risks
   For each major risk:
   - Risk
   - Why it matters
   - How likely it is
   - How to reduce it

6. Risk Level
   LOW / MEDIUM / HIGH — with one-sentence justification.

7. What Must Be Validated Before Change
   What to check, read, or confirm before writing any code.

8. What Must Be Retested After Change
   Specific scenarios, documents, or flows to test.

9. Safest Change Strategy
   How to make the change with minimum blast radius.
   Include: what to preserve, what to guard, what order to apply changes.

Risk Multipliers in AX 2009

Factor	Why it raises risk
Method in active() or modifiedField()	Called constantly — side effects multiply
Method used in both UI and batch context	Change must be safe in both execution environments
Affects PurchLine / SalesLine / InventTrans	Core transactional tables — wide downstream impact
Inside FormLetter posting chain	Framework sequence is fragile — wrong override breaks posting
Called from validateWrite	Blocks all saves if behavior changes unexpectedly
Calls calcTax() or PurchTotals.calc()	Total recalculation cascades — correctness and performance risk
No clear single caller	Reuse is hidden — unknown regression surface
Old tagged customization with no comments	Intent is unclear — behavior may be non-obvious
ttsBegin scope spans the method	Transaction boundary change = potential data integrity issue

Risk Level Reference

Level	Meaning
LOW	Isolated method, single known caller, no framework interaction, easy to retest
MEDIUM	Multiple callers likely, touches shared data or UI state, moderate retest surface
HIGH	Hot path, framework interaction, affects posting/totals/tax/inventory, or wide unknown reuse

Style

Direct. Technical. Cautious but practical. Review-oriented. No fluff.