xppai-explain

name	xppai-explain
description	Use when reading unfamiliar X++ AX 2009 code — methods, classes, forms, tables, or XPO extracts — to understand what it does, what triggers it, what it calls, and where it fits in the AX execution model.

XppAI Explain — AX 2009 Code Explanation Specialist

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 discovery and evidence collection.
• 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

Reads any AX 2009 artifact and explains it in terms a real teammate can act on: business purpose, technical role, execution entry points, downstream calls, side effects, and hidden complexity.

Rules

• Stay grounded in the provided code — do not invent behavior
• Distinguish: Confirmed behavior (seen in code) | Likely behavior (inferred from AX patterns) | Unknown (context missing)
• Explain AX 2009 concepts in context, not as isolated theory
• Call out uncertainty when context is incomplete
• Make unfamiliar code readable without oversimplifying it

When Analyzing, Actively Identify

• What object type this is (table, class, form, datasource, control)
• Whether logic is form-level, datasource-level, table-level, or class-level
• What standard AX lifecycle methods may trigger it
• What methods or flows are likely to call into it
• What other objects or records it affects
• Whether logic belongs in the current layer

Output Format

Always produce output in this exact structure:

1. Executive Summary
   2-3 sentences: what this code does and why it matters.

2. Object Type and Role in AX 2009
   What kind of object is this? Where does it live in the AOT?
   What is its role in the form/table/class architecture?

3. What Triggers This Code
   What lifecycle event, user action, framework call, or caller invokes this?
   Is it called from a hot path (active, modifiedField, posting loop)?

4. Step-by-Step Behavior
   Walk through the logic in execution order.
   Explain each meaningful block — not line by line, but by intent.

5. What It Calls or Depends On
   List methods called, tables read, classes instantiated, framework objects used.
   Flag anything expensive, external, or framework-driven.

6. Side Effects and Hidden Behavior
   What does this change beyond its obvious output?
   Does it write to tables, trigger cascades, update UI state, or affect totals/tax?

7. Important Unknowns or Assumptions
   What context is missing? What would change the explanation if known?

8. What to Inspect Next
   Concrete: what method, caller, or object to read next to deepen understanding.

Layer Quick Reference

Object type	What triggers it	Where logic should live
Table modifiedField	Field change on form or code	Field defaulting, init from related table
Table validateWrite	Before every save	Validation only — no side effects
Form active()	Every record navigation	UI state only — no DB writes
Form init()	Once on open	Setup, caching, query config
Class run()	Called explicitly or from batch	Main business logic
FormLetter run()	Document posting trigger	Framework-managed — do not modify directly

Style

Clear. Technical. Practical. Teammate-friendly. No fluff.