xpz-reader

Stars11

Forks3

UpdatedJune 25, 2026 at 03:38

Analyzes GeneXus XPZ/XML objects — identifies type, family, structure, and risk from raw XML input

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Source

GxBrasilNOficial

GxBrasilNOficial/GeneXus-XPZ-Skills

View GitHub Repository View Creator Repositories

Download

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

File Explorer

2 files

SKILL.md

readonly

xpz-reader

Interprets raw XML from GeneXus XPZ exports. Identifies object type, structural family, Part type mapping, and risk classification based on empirical evidence from a corpus of 7,219 real XMLs.

GUIDELINE

Read and classify GeneXus XML objects from XPZ packages. Answer only what the evidence supports. Always declare confidence level.

PATH RESOLUTION

This SKILL.md lives inside a skill subfolder under the repository root.
Resolve every ../arquivo.md reference relative to the directory of this SKILL.md, not relative to the current working directory.
In practice, ../ points to the shared methodological base in the parent directory of this skill folder.

TRIGGERS

Use this skill for:

User provides raw XML or XML fragment from a GeneXus XPZ export
User asks to identify an object type, family, or structure
User asks which Part types are present, expected, or missing
User asks about risk classification for a given object type
User asks to compare two XML structures or families
User asks what Object/@type value corresponds to a given GeneXus object

Do NOT use this skill for:

Generating or cloning XPZ objects (use xpz-builder)
Questions about GeneXus IDE behavior, build, or runtime execution beyond structural classification
Questions unrelated to GeneXus XPZ/XML structure
Locating or finding objects by name or type within the KB corpus (use xpz-index-triage first when a KbIntelligence index is available, to identify which XML to open)

RESPONSIBILITIES

Identify Object/@type and map to known object category using 01-base-empirica-geral as the index plus 01a-catalogo-e-padroes-empiricos for the actual catalog
Map Part types present in input against observed frequencies and known patterns, using 01b-matriz-part-types-por-tipo when needed
Classify object family when applicable: WebPanel families in 04-webpanel-familias-e-templates, Transaction families in 05-transaction-familias-e-templates
For WebPanel, classify the review by functional block before fine analysis: layout, events, variables, serialized functional metadata, identity and container, or dependencies
For WebPanel, when a textual search finds a term inside <Source><![CDATA[<GxMultiForm..., classify that evidence as layout or serialized functional metadata, not as events; for event/code-behind questions, prefer scripts\Search-GeneXusXmlSourceBlock.ps1 -Block events over raw rg/grep
For WorkWithForWeb, classify the review by functional block before fine analysis: Transaction binding, Pattern structure and navigation, Actions, links and prompts, Attribute references and data contract, or Identity and container
For DataSelector, classify the review by functional block before fine analysis: Selection contract, Selection logic and conditions, Attribute and function dependencies, Navigation context, or Identity and container
For Panel, classify the review by functional block before fine analysis: Panel structure and layout, Serialized behavior and configuration, Pattern and parent coupling, External dependencies, or Identity and container
For Transaction, classify the review by functional block before fine analysis: Transaction structure, Attributes and attribute properties, Rules, Events, Execution context, or Identity and container
For Transaction, when the primary block is Attributes and attribute properties, classify each key="False" attribute in the Level by writability using the detection signals in order: isRedundant="True" in Level → extended-parent-fk (non-writable); Formula property in its Attribute XML → formula (non-writable); listed in a SubTypeGroup as mapped to a non-key Supertype attribute → extended-subtype-descriptive (non-writable); listed in a SubTypeGroup as mapped to a PK Supertype attribute → extended-subtype-key (writable); when no SubTypeGroup covers the attribute, apply the naked-FK test using the Transaction's Table XML: if the attribute appears in a Duplicate index of that Table XML → extended-fk-key (writable, FK column stored in this table); otherwise, identify direct FK entities as the Transactions whose own key="True" PK attribute matches a PK member or Duplicate-index column of this table — read each FK entity's Level and collect its key="False" attributes — if the candidate attribute appears in any of those collections → extended-fk-descriptive (non-writable); for transitive extension, repeat the FK-entity lookup recursively on those FK entities; only if the attribute is absent from all FK entities at all depths → own-physical (writable); declare the writability classification explicitly in the analysis output; never declare a Transaction's physical table as "only keys" without verifying that every key="False" attribute was classified and confirmed as non-writable
For Procedure, classify the review by functional block before fine analysis: Source, Rules/parm, Variables, Calls and dependencies, Identity and container, and Report layout when applicable
For Procedure, when the review touches any block that could motivate an edit by the caller, recommend reading the complete Source before proposing any change — especially when the object contains validation logic, print Cases, or variable declarations that may interact with the intended edit; partial Source reading is a known source of editing the wrong layer
For DataProvider, classify the review by functional block before fine analysis: Output structure, Source, Navigation context, Calls and dependencies, or Identity and container
For API, classify the review by functional block before fine analysis: Service contract, Events and orchestration, Calls and dependencies, Data contract, or Identity and container
For Table, classify the review by functional block before fine analysis: Primary key structure, Secondary indexes and embedded index members, Transaction coupling and physical context, or Identity and container
For ExternalObject, classify the review by functional block before fine analysis: External contract surface, Method signatures and parameter typing, Platform and native binding metadata, or Identity and container
For UserControl, classify the review by functional block before fine analysis: Control contract surface, Properties and event bindings, Runtime resources and external dependencies, or Identity and container
For SubTypeGroup, classify the review by functional block before fine analysis: Group definition and member structure, Subtype mappings and role assignments, Contextual usage contract, or Identity and container
For File, classify the review by functional block before fine analysis: File identity and declared surface, Binary or textual payload fidelity, References and consumption context, or Identity and container
For Dashboard, classify the review by functional block before fine analysis: Dashboard composition and layout, Widgets and data bindings, Navigation and interaction context, or Identity and container
For Stencil, classify the review by functional block before fine analysis: Stencil definition and structural surface, Parameters and configurable slots, Pattern or generation consumption context, or Identity and container
For DataStore, classify the review by functional block before fine analysis: Store definition and declared connection surface, Configuration parameters and runtime options, Model and consumption context, or Identity and container
For Generator, classify the review by functional block before fine analysis: Generator definition and declared surface, Generation options and technical parameters, Model and target-platform usage context, or Identity and container
For Language, classify the review by functional block before fine analysis: Language definition and declared surface, Localization parameters and technical options, Model and runtime usage context, or Identity and container
For Document, classify the review by functional block before fine analysis: Document identity and declared surface, Materialized content and payload fidelity, References and functional consumption context, or Identity and container
For DeploymentUnit, classify the review by functional block before fine analysis: Deployment unit definition and declared surface, Packaging parameters and technical options, Runtime or delivery context, or Identity and container
Treat any extra block opened after the first one as an adjacent block and open it only when there is explicit functional dependency with the primary block
Name every justified block transition in the analysis and handoff, instead of silently widening the scope
State the conclusion scope at the smallest functional level supported by evidence, including execution context when that distinction matters
For report Procedure, classify whether the case fits the documented simple coverage from 05b-procedure-relatorio-familias-e-templates, and treat sanitized coverage as materialization-ready only when the selected block is marked as molde pronto
Classify container identity from parentType using the GUIDs: 00000000-0000-0000-0000-000000000008 = Module/Folder (user-created container), c88fffcd-b6f8-0000-8fec-00b5497e2117 = PackagedModule, afa47377-41d5-4ae8-9755-6f53150aa361 = Root Module (virtual, no XML file in acervo), 00000000-0000-0000-0000-000000000006 = system Folder (Main Programs, ToBeDefined; never a valid parentType of packagable objects); never use the directory name in ObjetosDaKbEmXml as a type indicator — it varies across KBs
Assign risk level using 03-risco-e-decisao-por-tipo
Identify structural anomalies: unexpected Part types, missing recurring parts, malformed envelope
For report Procedure, classify anomalies by layer: Source, Rules, or layout Part c414ed00-8cc4-4f44-8820-4baf93547173
Identify identity anomalies involving fullyQualifiedName, name, parent, parentGuid, parentType, and moduleGuid
Treat object lookup in repository-backed workflows as type + name, never name alone
Confirm the real folder where the XML exists before citing, comparing, or using a local object as evidence
When citing a line from GeneXus XML, classify the cited fragment as effective Source, Rules/parm, XML metadata, call in caller, or signature in callee
When reading GeneXus variable declarations or variable metadata, classify ATTCUSTOMTYPE bc:<Transaction> together with AttCollection=True/False; never treat BC simple and BC collection as equivalent contracts
For SDTs used as parameter collections with boolean control flags, extract each flag name from the XML structure and recommend crosschecking its domain semantics against the Source of the Procedure or DataProvider that consumes it; do not infer meaning from the attribute name alone — similar names (ComSaldo, ComSaldoOuAembarcar) may encode different conditions depending on the consumer's Cases
When reading BC method calls in Source, classify the method family as operation, status/message, serialization/copy, or collection, and keep that classification separate from runtime semantics not directly proved by the XML
Declare confidence level for every conclusion: Direct evidence / Strong inference / Hypothesis
Never affirm import or build compatibility — structural analysis only
When the task depends on a local KB parallel folder structure, require that structure to be clarified or validated first via xpz-kb-parallel-setup
When the object analyzed is a WWP PatternInstance (WorkWithPlus*): flag as structural anomaly any duplicate nodes in <attribute>, <gridAttribute>, or <parameter>; parentGuid inconsistent with the object name; and references to attributes apparently absent from the current model — if the user intends to package or clone the object, encaminhar para xpz-builder
When the analysis is motivated by a GeneXus warning about an unknown provider, unknown item, designer, or extension metadata: classify the cited item before searching the XPZ/XML — (a) common exportable GeneXus object; (b) internal part or metadata; (c) designer or extension provider; (d) unknown type. If the XPZ/XML search returns no result and the item is not type (a), state only the limited conclusion: "not found in XPZ/XML" — never "does not exist in the KB". Refer to the conceptual boundary rule in 02-regras-operacionais-e-runtime.md section "Limite do XPZ/XML frente a providers e extensões GeneXus".
When the input is a legacy GeneXus 9 export envelope — a root <Object>/<Attribute> carrying dataSource="gx-legacy-export" and a <GxLegacyPayload> wrapper, with guid="" and (for orphans like Report/Menubar) type="gxlegacy/<Element>" — recognize it as materialized by the legacy sync engine (Sync-GeneXusXpzToXml.ps1): the real GX9 object content lives inside <GxLegacyPayload> as <GXObject><Element> by name (no type GUID). Route classification through 01k-registro-elementos-legados.md (equivalent reusing a modern type vs orphan under a gxlegacy/<Element> typeToken), not the modern type catalog; never treat type="gxlegacy/<Element>" as an unknown/invalid modern GUID, and never treat guid="" as a malformed envelope (legacy items carry no stable object GUID by design).

COMMUNICATION

Respond in the same language the user writes in
Lead with the classification result, then supporting evidence
Always state confidence level explicitly
Use concise language; avoid speculation beyond what the evidence supports
When certainty is low, say so before proceeding
NEVER invent Part type GUIDs or object attributes not observed in the corpus

STRUCTURE

Reference files and when to load them:

Reference	Load when
00-indice-da-base-genexus-xpz-xml.md	Always — absolute rules and envelope spec
01-base-empirica-geral.md	Entry point and routing across the empirical `01` series
01a-catalogo-e-padroes-empiricos.md	Identifying object type and reading the structural catalog
01k-registro-elementos-legados.md	Input is a legacy GeneXus 9 export envelope (`dataSource="gx-legacy-export"`, `<GxLegacyPayload>`, `type="gxlegacy/<Element>"`)
01b-matriz-part-types-por-tipo.md	Checking recurring `Part type` inventory by object type
01c-campos-estaveis-vs-variaveis.md	Checking which fields tend to remain stable or vary
01d-diffs-estruturais-por-tipo.md	Comparing structural density and per-type differences
03-risco-e-decisao-por-tipo.md	Risk classification for any object type
04-webpanel-familias-e-templates.md	Input contains WebPanel XML
05-transaction-familias-e-templates.md	Input contains Transaction XML
05b-procedure-relatorio-familias-e-templates.md	Input contains report `Procedure` XML
06-padroes-de-objeto-e-nomenclatura.md	User asks about naming conventions or object organization
09-inventario-e-rastreabilidade-publica.md	User asks about corpus history, validation trail, or inventory
`xpz-index-triage` skill	When a KbIntelligence index is available and the user needs to locate or confirm which object XML to open before structural analysis

WORKFLOW

Receive XML input or fragment from user
If the task depends on locating files in a local KB parallel folder structure and that structure is still undefined, ambiguous, or unvalidated → ABORT and use xpz-kb-parallel-setup first
Locate Object/@type attribute → use 01-base-empirica-geral to route and cross-reference against 01a-catalogo-e-padroes-empiricos; if the root element is <Attribute> (not <Object>), the type is Attribute — it uses a distinct envelope and has no Object/@type
Check 01b-matriz-part-types-por-tipo for the identified type: if 01b confirms the type uses no Parts (e.g. ThemeClass, ThemeColor, Generator, DataStore, Module/Folder), skip Part enumeration — absence of <Part> is expected for these types, not an anomaly; otherwise enumerate Part types present and compare against observed frequencies
Identify missing or unexpected Part types relative to the known structural pattern — this step is not applicable for types confirmed in 01b as using no Parts
Read container identity fields (fullyQualifiedName, name, parent, parentGuid, parentType, moduleGuid) and classify the container from parentType GUID — never from the directory name in ObjetosDaKbEmXml, which varies across KBs:
- 00000000-0000-0000-0000-000000000008 → Module/Folder (user-created container)
- c88fffcd-b6f8-0000-8fec-00b5497e2117 → PackagedModule
- afa47377-41d5-4ae8-9755-6f53150aa361 → Root Module (virtual; no XML file in acervo)
- 00000000-0000-0000-0000-000000000006 → system Folder (never a valid parentType of packagable objects)
- unresolved when parentType is absent or unknown
When the task depends on locating an object in a local GeneXus repository, confirm the object by type + name and verify the actual folder where the file exists before proceeding
Before citing a local line as evidence, classify the line role:
- effective Source of the current object
- Rules/parm or signature of the current object
- XML metadata or structural wrapper
- direct call site inside the caller object
- callee signature inside the called object
If variable metadata or declaration indicates ATTCUSTOMTYPE bc:<Transaction>, classify the variable as BC simple or BC collection using AttCollection=True/False before interpreting method calls
If the task cites BC methods in Source, classify each cited method by family:

operation: .Load(...), .Save(), .Delete(), .Check(), .Insert(), .Update()
status/message: .Success(), .Fail(), .GetMessages()
serialization/copy: .ToJson(), .FromJson(), .ToXml(), .FromXml(), .Clone()
collection: .Add(), .Item(), .Sort(), and .Insert() when the variable was confirmed as collection

If the conclusion is "object A calls object B", require evidence in A's effective Source or in explicit call metadata belonging to A; a parm(...) line in B is only callee signature evidence
If type is WebPanel → load 04-webpanel-familias-e-templates, classify family, and classify the primary review block before fine analysis:

events for user actions, refresh, start, load, procedural validation, and direct calls
layout for visual composition, control hierarchy, grid/tab/action structure, and visible bindings
variables for declaration contract, type coherence, and collection-vs-simple review
serialized functional metadata for Conditions, ControlWhere, ControlBaseTable, ControlOrder, ControlUnique, PATTERN_ELEMENT_CUSTOM_PROPERTIES, WebUserControlProperties, and pattern marks
identity and container for fullyQualifiedName, parent, parentGuid, parentType, and moduleGuid
dependencies for MasterPage, pattern links, user controls, and relevant external object references 12a. For WebPanel textual search in a local XML, do not treat a match in inline GxMultiForm layout as behavioral evidence; if the question is about calls, actions, validation, filters, or event flow, use scripts\Search-GeneXusXmlSourceBlock.ps1 -Block events or an equivalent structured extraction before citing the line

For WebPanel, open adjacent blocks only when there is explicit functional dependency with the primary block, and name that transition in the analysis
If type is WorkWithForWeb → classify the primary review block before fine analysis:

Transaction binding for parent, parentGuid, parentType, associated Transaction, structural coupling, and suspicion that the WW is attached to the wrong parent
Pattern structure and navigation for selection, tabs, view, filters, navigation, and functional organization inside the serialized pattern
Actions, links and prompts for actions, buttons, menu items, gxobject, links, prompts, and explicit openings of external objects from the WW
Attribute references and data contract for displayed attributes, attribute-based filters, columns, tabs depending on attributes, broken references, and the structural convention adbb33c9-0906-4971-833c-998de27e0676-NomeDoAtributo
Identity and container for fullyQualifiedName, name, guid, moduleGuid, container, and risk of confusing the target instance with another similar one

For WorkWithForWeb, open adjacent blocks only when there is explicit functional dependency with the primary block, name that transition in the analysis, and treat surrounding generated WebPanel or WorkWithPlus artifacts only as explicit external dependencies, never as canonical internal blocks of WorkWithForWeb
If type is DataSelector → classify the primary review block before fine analysis:

Selection contract for parameters, input signature, declarative selector variables, and the contract expected by the selector
Selection logic and conditions for Condition, filters, expressions, selection criteria, and the effective logic that decides the returned set
Attribute and function dependencies for referenced attributes, functions used in filters, broken names, unresolved references, and semantic dependencies that must really exist in the KB
Navigation context for implicit or explicit base, transactional/physical context, and the functional frame in which the selector operates
Identity and container for fullyQualifiedName, name, guid, parent, parentGuid, parentType, and moduleGuid

For DataSelector, open adjacent blocks only when there is explicit functional dependency with the primary block, name that transition in the analysis, and keep parameter contract, applied filter, and real KB dependency as separate layers until evidence supports joining them
If type is Panel → classify the primary review block before fine analysis:

Panel structure and layout for visual composition, controls, declarative organization, and the apparent functional shape of the panel
Serialized behavior and configuration for serialized behavior, persisted configuration, and functional metadata that cannot be reduced to visual decoration
Pattern and parent coupling for parent, parentGuid, parentType, moduleGuid, origin pattern, and the structural coupling that makes the panel depend on its context
External dependencies for external objects called, referenced, or needed to sustain the functional reading of the panel
Identity and container for fullyQualifiedName, name, guid, container, and structural classification of the object

For Panel, open adjacent blocks only when there is explicit functional dependency with the primary block, name that transition in the analysis, and keep the panel surface separate from the structural coupling around it until evidence supports joining them
If type is Transaction → load 05-transaction-familias-e-templates, classify family (F1–F6), and classify the primary review block before fine analysis:

Transaction structure for Level, key, DescriptionAttribute, structural shape, and transactional composition
Attributes and attribute properties for attributes, AttributeProperties, subtype linkage, and data-contract questions
Rules for declarative rules, obligation, and normative transaction behavior
Events for interface-driven behavior and flow via web editing
Execution context when the main ambiguity is the distinction between web editing and BC usage
Identity and container for fullyQualifiedName, parent, parentGuid, parentType, and moduleGuid

For Transaction, open adjacent blocks only when there is explicit functional dependency with the primary block, name that transition in the analysis, and state whether the conclusion applies via web editing, via BC, or remains unresolved across contexts
If type is DataProvider → classify the primary review block before fine analysis:

Output structure for collection vs simple, nested groups, node names, cardinality, and coherence of the promised return shape
Source for conditions, assignments, assembly logic, calculations, population of output nodes, and internal flow
Navigation context for implicit or declared base, For each, filters, base table, and navigation ambiguity
Calls and dependencies for SDT, Procedure, BC, Transaction, and immediate external dependencies needed to justify the conclusion
Identity and container for fullyQualifiedName, parent, parentGuid, parentType, and moduleGuid

For DataProvider, open adjacent blocks only when there is explicit functional dependency with the primary block, and name that transition in the analysis
If type is API → classify the primary review block before fine analysis:

Service contract for exposed method, endpoint, external signature, and published operation shape
Events and orchestration for .Before/.After, internal flow, validation, transformation, and orchestration behavior
Calls and dependencies for Procedure, SDT, Domain, Transaction, EXO, DataProvider, and immediate external dependencies needed to justify the conclusion
Data contract for input/output shape, type coherence, response structure, and mapping between contract and processed data
Identity and container for fullyQualifiedName, parent, parentGuid, parentType, and moduleGuid

For API, open adjacent blocks only when there is explicit functional dependency with the primary block, and name that transition in the analysis
If type is SDT → classify the primary review block before fine analysis:

Structure definition for Level, LevelInfo, item sequence, hierarchy, composition, and collection-vs-simple structural shape
Item typing and dependencies for idBasedOn, ATTCUSTOMTYPE, domain base, referenced SDT, and item-level semantic coherence
External serialization contract for ExternalName, ExternalNamespace, idXmlName, idXmlNamespace, soaptype, idCollectionItemName, and equivalent serialization metadata
Top-level type properties for properties declared on the SDT object itself, especially top-level typing or structural behavior that does not belong to one specific item
Identity and container for fullyQualifiedName, name, guid, parent, parentGuid, parentType, and moduleGuid

For SDT, open adjacent blocks only when there is explicit functional dependency with the primary block, name that transition in the analysis, and keep internal shape, item typing, and external serialization as separate layers until evidence supports joining them
If type is Theme → classify the primary review block before fine analysis:

Theme core definition for the theme baseline, central properties, object shape, and global theme definition
Class graph and references for the ThemeClass graph, internal class-to-class references, visual inheritance, and dependencies inside the theme class graph
Predefined types and style bindings for PredefinedTypes, Styles, and normative bindings between GeneXus visual types and the concrete ThemeClass/ThemeColor/ColorPalette/DesignSystem stack when that coupling is materialized in the theme
Visual simplification and override surface for controlled simplification, overrides, visual reduction, and removal of theme surface after the basic visual coupling has already been established
Identity and container for fullyQualifiedName, name, guid, parent, parentGuid, parentType, and moduleGuid

For Theme, open adjacent blocks only when there is explicit functional dependency with the primary block, name that transition in the analysis, keep theme baseline, class graph, normative bindings, and simplification layers separate until evidence supports joining them, and do not use simplification as a shortcut before class graph and normative bindings are sufficiently grounded
If type is ThemeClass → classify the primary review block before fine analysis:

Direct class surface for top-level Properties, concrete visual properties, direct object shape, and what the class declares without Part
Inheritance and parent linkage for parent, parentGuid, parentType, visual inheritance chain, base class, derived variants, and visual states such as hover
Theme applicability and internal classification for ThemeElementThemeTypes, ThemeElementInternalType, applicability scope, and internal thematic classification
Visual references and external dependencies for nominal references to colors, images, helper classes, and other external visual resources the class depends on
Identity and container for fullyQualifiedName, name, guid, and moduleGuid; do not collapse parent* here when evidence points to functional inheritance

For ThemeClass, open adjacent blocks only when there is explicit functional dependency with the primary block, name that transition in the analysis, and keep direct class surface, inheritance chain, applicability markers, and external visual dependencies separate until evidence supports joining them
If type is ThemeColor → classify the primary review block before fine analysis:

Color identity and naming for the logical color name, nominal identity, and expected thematic role
Direct color value surface for top-level Properties, serialized color value, direct object shape, and the concrete color definition without Part
Theme applicability and palette coupling for relation with Theme, ColorPalette, DesignSystem, applicability scope, and semantic fit inside the visual family
Visual references and usage dependencies for consumption by ThemeClass, Theme, styles, and other visual elements that depend on this color identity and value
Identity and container for fullyQualifiedName, name, guid, and moduleGuid

For ThemeColor, open adjacent blocks only when there is explicit functional dependency with the primary block, name that transition in the analysis, and keep nominal identity, direct value, thematic coupling, and visual usage dependencies separate until evidence supports joining them
If type is ColorPalette → classify the primary review block before fine analysis:

Palette identity and naming for the logical palette name, nominal identity, and expected thematic role
Palette composition and declared members for the palette's internal composition, declared items, direct object shape, and the functional list it materializes
Theme and design-system coupling for relation with Theme, DesignSystem, and architectural fit inside the broader visual layer
Color references and usage surface for relation with ThemeColor and visual consumers that depend on this palette
Identity and container for fullyQualifiedName, name, guid, and moduleGuid

For ColorPalette, open adjacent blocks only when there is explicit functional dependency with the primary block, name that transition in the analysis, and keep palette identity, declared composition, architectural coupling, and usage surface separate until evidence supports joining them
If type is DesignSystem → classify the primary review block before fine analysis:

System identity and naming for the logical system name, nominal identity, and expected architectural role
Design tokens and declared resources for tokens, declared resources, internal composition, and the functional shape the design system materializes
Theme and palette coupling for relation with Theme, ColorPalette, and architectural coupling across the visual layers
Visual rules and consumption surface for visual rules consumed by other layers and the practical surface where the system affects rendering
Identity and container for fullyQualifiedName, name, guid, and moduleGuid

For DesignSystem, open adjacent blocks only when there is explicit functional dependency with the primary block, name that transition in the analysis, and keep system identity, declared tokens/resources, theme-palette coupling, and consumption surface separate until evidence supports joining them
If type is PackagedModule → classify the primary review block before fine analysis:

Module identity and naming for the logical module name, nominal identity, and expected semantic role
Packaging boundary and declared members for the package boundary, declared members, internal composition, and the functional set the packaged module delimits
Parent and installation context for installation relation, structural parent, and hierarchical fit of the packaged module
Dependency and consumption surface for module dependencies and the way other layers or objects consume it
Identity and container for fullyQualifiedName, name, guid, and moduleGuid

For PackagedModule, open adjacent blocks only when there is explicit functional dependency with the primary block, name that transition in the analysis, and keep module identity, package boundary, installation context, and dependency-consumption surface separate until evidence supports joining them
If type is Image → classify the primary review block before fine analysis:

Image identity and naming for the logical image name, nominal identity, and expected semantic role of the resource
Image item set and declared variants for ImageItem, declared variants, internal composition, and the functional shape of the image resource
Binary payload and extraction fidelity for base64Binary, payload integrity, content preservation, and extraction-materialization fidelity
Theme and language references for ThemeReference, LanguageReference, and external presentation dependencies tied to the image
Identity and container for fullyQualifiedName, name, guid, and moduleGuid

For Image, open adjacent blocks only when there is explicit functional dependency with the primary block, name that transition in the analysis, and keep image identity, declared variants, binary payload, and theme-language references separate until evidence supports joining them
If type is Attribute → classify the primary review block before fine analysis:

Attribute core definition for top-level shape, central definition, and baseline attribute structure
Typing and base linkage for idBasedOn, base domain, declared type, and typed contract coherence
Semantic property references for ControlItemDescription, broken nominal references, and dependencies on other real attributes in the KB
Presentation and control semantics for functional presentation/control properties and serialized behavior that affect attribute usage
Identity and container for fullyQualifiedName, name, guid, parent, parentGuid, parentType, and moduleGuid

For Attribute, open adjacent blocks only when there is explicit functional dependency with the primary block, name that transition in the analysis, and keep baseline definition, typing, nominal references, and control/presentation semantics separate until evidence supports joining them
If type is PatternSettings → classify the primary review block before fine analysis:

Pattern registration and environment fit for pattern availability, environment compatibility, registration fit, and symptoms such as pattern not registered or was not changed
Internal pattern configuration for CDATA, persisted flags, internal declarative shape, and the pattern configuration stored in the object
Context and callable dependencies for ContextVariable, LoadProcedure, called procedures, and functional context required by the pattern
Security and auxiliary references for Security and other auxiliary references that the pattern needs outside its main context
Identity and container for fullyQualifiedName, name, guid, parent, parentGuid, parentType, and moduleGuid

For PatternSettings, open adjacent blocks only when there is explicit functional dependency with the primary block, name that transition in the analysis, and keep pattern registration, internal configuration, callable context, and auxiliary/security references separate until evidence supports joining them
If type is Folder → classify the primary review block before fine analysis:

Minimal structural shape for XML envelope, Object/@type, minimal structural shape, and baseline serialization
Parent and module context for parent, parentGuid, parentType, moduleGuid, and the folder's structural placement
IDE semantic reading for how the IDE/importer interprets the object, including Category as a UI label
Identity and naming semantics for naming ambiguity, displayed naming expectations, and the distinction between XML type and UI label
Identity and container for fullyQualifiedName, name, guid, and container-level structural identity

For Folder, open adjacent blocks only when there is explicit functional dependency with the primary block, name that transition in the analysis, and keep structural shape, parent/module context, IDE reading, and naming semantics separate until evidence supports joining them
If type is Domain → classify the primary review block before fine analysis:

Base type definition for base type, ATTCUSTOMTYPE when applicable, and the domain's primary typed contract
Limits and scalar constraints for length, precision, scale, flags, and scalar constraints
Enumerated values contract for IDEnumDefinedValues, value lists, descriptions, and enumerated contract coherence
Usage-facing semantic contract for how the domain is meant to be consumed by other objects, UI, or data contracts
Identity and container for fullyQualifiedName, name, guid, parent, parentGuid, parentType, and moduleGuid

For Domain, open adjacent blocks only when there is explicit functional dependency with the primary block, name that transition in the analysis, and keep base typing, scalar limits, enumerated contract, and usage-facing semantics separate until evidence supports joining them
If type is Table → classify the primary review block before fine analysis:

Primary key structure for primary key composition, structural order, key members, and the coherence of the table's main physical core
Secondary indexes and embedded index members for embedded indexes, index members, ordering, search coverage, and reading Index as internal structure of the Table
Transaction coupling and physical context for physical reassociation with the Transaction of the same name, structural context in the target, and contextual dependency that still exists even when named parent is absent
Identity and container for fullyQualifiedName, name, guid, parentGuid, moduleGuid, and the risk of reading the wrong Table in the wrong structural context

For Table, open adjacent blocks only when there is explicit functional dependency with the primary block, name that transition in the analysis, keep primary key, embedded indexes, and transaction-coupling/context layers separate until evidence supports joining them, and do not promote embedded Index to a separate top-level object in this reading
If type is ExternalObject → classify the primary review block before fine analysis:

External contract surface for exposed surface, external naming, published methods/properties, and the functional role of the wrapper
Method signatures and parameter typing for methods, parameters, return values, signature coherence, and typed dependencies such as SDT, domains, or helper types
Platform and native binding metadata for assembly, target library, platform metadata, native binding, and technical coupling specific to the ExternalObject
Identity and container for fullyQualifiedName, name, guid, parent, parentGuid, parentType, and moduleGuid

For ExternalObject, open adjacent blocks only when there is explicit functional dependency with the primary block, name that transition in the analysis, and keep exposed surface, typed signatures, and native-binding/platform metadata separate until evidence supports joining them
If type is UserControl → classify the primary review block before fine analysis:

Control contract surface for declared interface, exposed surface, the functional role of the control, and its general host-facing shape
Properties and event bindings for properties, events, parameters, and binding contract between the control and its host
Runtime resources and external dependencies for scripts, assets, auxiliary resources, technical dependencies, and execution-time coupling of the UserControl
Identity and container for fullyQualifiedName, name, guid, parent, parentGuid, parentType, and moduleGuid

For UserControl, open adjacent blocks only when there is explicit functional dependency with the primary block, name that transition in the analysis, and keep declared control contract, property/event bindings, and runtime-dependency layers separate until evidence supports joining them
If type is SubTypeGroup → classify the primary review block before fine analysis:

Group definition and member structure for group composition, declared members, structural shape, and grouping integrity
Subtype mappings and role assignments for supertype/subtype mapping, member roles, and internal subtype assignments
Contextual usage contract for how the group supports usage in Attribute, Transaction, and other consumer objects of the model
Identity and container for fullyQualifiedName, name, guid, parent, parentGuid, parentType, and moduleGuid

For SubTypeGroup, open adjacent blocks only when there is explicit functional dependency with the primary block, name that transition in the analysis, and keep group definition, subtype-role mapping, and contextual-usage layers separate until evidence supports joining them
If type is File → classify the primary review block before fine analysis:

File identity and declared surface for resource naming, declared extension/logical role, and top-level resource surface
Binary or textual payload fidelity for materialized content, payload integrity, byte/text preservation, and extraction fidelity
References and consumption context for external references, consumers of the file, runtime dependency, and usage context
Identity and container for fullyQualifiedName, name, guid, parent, parentGuid, parentType, and moduleGuid

For File, open adjacent blocks only when there is explicit functional dependency with the primary block, name that transition in the analysis, and keep resource identity/surface, payload, and consumption-context layers separate until evidence supports joining them
If type is Dashboard → classify the primary review block before fine analysis:

Dashboard composition and layout for sections, visual blocks, structural organization, and dashboard composition shape
Widgets and data bindings for widgets, components, data bindings, parameters, and the linkage between visible parts and their data providers
Navigation and interaction context for actions, links, drill-down, user interaction, and the dashboard's functional placement in the wider flow
Identity and container for fullyQualifiedName, name, guid, parent, parentGuid, parentType, and moduleGuid

For Dashboard, open adjacent blocks only when there is explicit functional dependency with the primary block, name that transition in the analysis, and keep composition, widget-binding, and navigation-interaction layers separate until evidence supports joining them
If type is Stencil → classify the primary review block before fine analysis:

Stencil definition and structural surface for artifact shape, declared composition, base structure, and structural surface of the stencil
Parameters and configurable slots for parameters, placeholders, variable slots, and configurable contract of the stencil
Pattern or generation consumption context for how the stencil is consumed by patterns, generation, or dependent flows
Identity and container for fullyQualifiedName, name, guid, parent, parentGuid, parentType, and moduleGuid

For Stencil, open adjacent blocks only when there is explicit functional dependency with the primary block, name that transition in the analysis, and keep structural definition, parameterization, and pattern/generation-consumption layers separate until evidence supports joining them
If type is DataStore → classify the primary review block before fine analysis:

Store definition and declared connection surface for declared store identity, primary connection surface, and the main shape of the definition
Configuration parameters and runtime options for parameters, flags, options, and runtime-operational configuration
Model and consumption context for how the store fits into the model, its runtime role, and consumption by dependent objects
Identity and container for fullyQualifiedName, name, guid, parent, parentGuid, parentType, and moduleGuid

For DataStore, open adjacent blocks only when there is explicit functional dependency with the primary block, name that transition in the analysis, and keep store definition, runtime configuration, and consumption-context layers separate until evidence supports joining them
If type is Generator → classify the primary review block before fine analysis:

Generator definition and declared surface for what the generator declares itself to be, its main role, and its structural surface
Generation options and technical parameters for parameters, flags, options, and technical generation behavior
Model and target-platform usage context for model fit, generation target, effective consumption, and role in the flow
Identity and container for fullyQualifiedName, name, guid, parent, parentGuid, parentType, and moduleGuid

For Generator, open adjacent blocks only when there is explicit functional dependency with the primary block, name that transition in the analysis, and keep declared surface, technical parameters, and usage-context layers separate until evidence supports joining them
If type is Language → classify the primary review block before fine analysis:

Language definition and declared surface for what the object declares itself to be, its main role, and its structural surface
Localization parameters and technical options for parameters, options, codes, flags, and technical localization behavior
Model and runtime usage context for model fit, effective consumption, runtime linkage, and functional role of the language
Identity and container for fullyQualifiedName, name, guid, parent, parentGuid, parentType, and moduleGuid

For Language, open adjacent blocks only when there is explicit functional dependency with the primary block, name that transition in the analysis, and keep declared surface, localization parameters, and usage-context layers separate until evidence supports joining them
If type is Document → classify the primary review block before fine analysis:

Document identity and declared surface for what the document declares itself to be, its main role, naming, and structural surface
Materialized content and payload fidelity for materialized content, payload integrity, text/byte preservation, and extraction fidelity
References and functional consumption context for consumers of the document, external links, functional dependency, and role in the wider flow
Identity and container for fullyQualifiedName, name, guid, parent, parentGuid, parentType, and moduleGuid

For Document, open adjacent blocks only when there is explicit functional dependency with the primary block, name that transition in the analysis, and keep declared surface, payload, and consumption-context layers separate until evidence supports joining them
If type is DeploymentUnit → classify the primary review block before fine analysis:

Deployment unit definition and declared surface for what the unit declares itself to be, its main role, and its structural surface
Packaging parameters and technical options for parameters, options, flags, and technical packaging or delivery behavior
Runtime or delivery context for flow fit, delivery target, effective consumption, and operational role
Identity and container for fullyQualifiedName, name, guid, parent, parentGuid, parentType, and moduleGuid

For DeploymentUnit, open adjacent blocks only when there is explicit functional dependency with the primary block, name that transition in the analysis, and keep declared surface, technical parameters, and delivery-context layers separate until evidence supports joining them
If type is Procedure → classify the primary review block before fine analysis:

Source for filters, flow, conditions, assignments, navigation, and calls made in the body
Rules/parm for signature, parameters, declarative contract, and rule-focused errors
Variables for existence, type, helper declarations, and collection-vs-simple coherence
Calls and dependencies for callee review, dependency chain, and proof of caller call-site
Identity and container for fullyQualifiedName, parent, parentGuid, parentType, and moduleGuid
Report layout only when the Procedure is a report and the symptoms involve Bands, PrintBlock, ReportLabel, ReportAttribute, or layout shape

For Procedure, open adjacent blocks only when there is explicit functional dependency with the primary block, and name that transition in the analysis
If type is report Procedure → load 05b-procedure-relatorio-familias-e-templates, classify family, and separate observed evidence into Source, Rules, and layout
For report Procedure, if the symptoms point to invalid control, printBlock, ReportLabel, or ReportAttribute, classify the primary suspicion as layout; if they point to parm(...) or missing ;, classify the primary suspicion as Rules; if they point to Header, Footer, For each, or Output_file, classify the primary suspicion as Source
For report Procedure, if the case still fits simple F2/F3 coverage with no repeated structural failure signal, report that sanitized canonical coverage is still available and label the basis as molde sanitizado; otherwise recommend escalation to comparable real XML explicitly
Assign risk level from 03-risco-e-decisao-por-tipo
Report result:

Object type and canonical name
Container classification (Folder, Module, or unresolved)
Structural family (if applicable)
For WebPanel, primary review block and any justified block transition used in the analysis
For WorkWithForWeb, primary review block and any justified block transition used in the analysis
For DataSelector, primary review block and any justified block transition used in the analysis
For Panel, primary review block and any justified block transition used in the analysis
For Transaction, primary review block and any justified block transition used in the analysis, plus explicit scope via web editing, via BC, or unresolved
For DataProvider, primary review block and any justified block transition used in the analysis
For API, primary review block and any justified block transition used in the analysis
For SDT, primary review block and any justified block transition used in the analysis
For Theme, primary review block and any justified block transition used in the analysis
For Attribute, primary review block and any justified block transition used in the analysis
For PatternSettings, primary review block and any justified block transition used in the analysis
For Folder, primary review block and any justified block transition used in the analysis
For Domain, primary review block and any justified block transition used in the analysis
For Table, primary review block and any justified block transition used in the analysis
For ExternalObject, primary review block and any justified block transition used in the analysis
For UserControl, primary review block and any justified block transition used in the analysis
For SubTypeGroup, primary review block and any justified block transition used in the analysis
For File, primary review block and any justified block transition used in the analysis
For Dashboard, primary review block and any justified block transition used in the analysis
For Stencil, primary review block and any justified block transition used in the analysis
For DataStore, primary review block and any justified block transition used in the analysis
For Generator, primary review block and any justified block transition used in the analysis
For Language, primary review block and any justified block transition used in the analysis
For Document, primary review block and any justified block transition used in the analysis
For DeploymentUnit, primary review block and any justified block transition used in the analysis
For Procedure, primary review block and any justified block transition used in the analysis
Risk level
Part types: present / expected / missing — or N/A if the type is confirmed in [01b] as using no Parts
For report Procedure, anomaly layer and escalation recommendation (sanitized canonical template still fits vs escalate to comparable real XML)
For report Procedure, basis used labeled as exactly one of: molde sanitizado, XML real da KB atual, XML real de outra KB, or hipótese
Identity fields: fullyQualifiedName, name, parent, parentGuid, parentType, moduleGuid
Confidence level for each conclusion
Any structural anomalies detected

QUALITY CHECKLIST

CONSTRAINTS

NEVER flag absence of <Part> as a structural anomaly for types confirmed in 01b-matriz-part-types-por-tipo as using no Parts (ThemeClass, ThemeColor, Generator, DataStore, Module/Folder)
NEVER invent a Part type GUID not observed in the empirical corpus
NEVER promote a Hypothesis to Strong Inference without new direct evidence
NEVER affirm import or build success — structural analysis only
ABORT analysis if XML is too malformed to identify Object/@type
When sample is small or type is rare, state it explicitly before concluding
When object lookup depends on a local repository, ABORT if the file was not confirmed in the folder implied by the validated object type
When repository-backed analysis depends on the KB parallel folder structure, ABORT if that structure was not clarified or validated first
NEVER present a parm(...) line from the called object's XML as the caller's call site
NEVER treat ATTCUSTOMTYPE bc:<Transaction> alone as enough to collapse BC simple and BC collection into the same contract
NEVER turn BC status/message methods such as .Success(), .Fail(), or .GetMessages() into a new functional operation without direct evidence beyond the cited line
NEVER infer runtime semantics for BC collection methods from name similarity alone; require the simple-vs-collection classification first
For WebPanel, NEVER jump from one functional block to another without explicit dependency rationale
For WorkWithForWeb, NEVER jump from one functional block to another without explicit dependency rationale, and NEVER treat surrounding generated WebPanel or WorkWithPlus artifacts as canonical internal blocks of the WW itself
For DataSelector, NEVER collapse parameter contract, applied filter, and real KB dependency into a single conclusion without explicit evidence joining those layers
For Panel, NEVER collapse the panel surface and the structural coupling around it into the same conclusion without explicit evidence joining those layers
For Transaction, NEVER collapse web editing and BC behavior into the same conclusion without explicit evidence
For DataProvider, NEVER treat output shape as proved only by dependency inventory, or navigation context as proved only by the return shape
For API, NEVER treat dependency inventory as enough to prove service contract, or service contract text as enough to prove the full orchestration chain
For Table, NEVER treat embedded Index as an independent top-level object in this review, and NEVER treat absence of named parent as proof that the Table has no contextual dependency
For ExternalObject, NEVER treat native-binding/platform metadata as enough to prove method signatures, or exposed surface text as enough to prove technical binding correctness
For UserControl, NEVER treat runtime dependency presence as enough to prove property/event binding correctness, or declared control surface as enough to prove runtime integration is complete
For SubTypeGroup, NEVER treat contextual usage in another object as enough to prove internal subtype-role mapping correctness, or internal group composition as enough to prove contextual usage is coherent
For File, NEVER treat declared resource identity/surface as enough to prove payload fidelity, or payload fidelity as enough to prove correct consumption context
For Dashboard, NEVER treat visual composition as enough to prove widget/data binding correctness, or widget/data binding as enough to prove navigation/interaction coherence
For Stencil, NEVER treat structural definition as enough to prove parameterization correctness, or consumption by pattern/generation as enough to prove internal stencil definition is coherent
For DataStore, NEVER treat declared connection surface as enough to prove runtime configuration correctness, or runtime configuration as enough to prove coherent consumption context in the model
For Generator, NEVER treat declared generator surface as enough to prove technical-parameter correctness, or technical parameters as enough to prove coherent target-platform usage context
For Language, NEVER treat declared language surface as enough to prove localization-parameter correctness, or localization parameters as enough to prove coherent model/runtime usage context
For Document, NEVER treat declared document surface as enough to prove payload fidelity, or payload fidelity as enough to prove coherent functional consumption context
For DeploymentUnit, NEVER treat declared deployment-unit surface as enough to prove packaging-parameter correctness, or technical parameters as enough to prove coherent delivery/runtime context
For Procedure, NEVER jump from one functional block to another without explicit dependency rationale
Absolute rules in 00-indice-da-base-genexus-xpz-xml.md take precedence over all heuristics

name	xpz-reader
description	Analyzes GeneXus XPZ/XML objects — identifies type, family, structure, and risk from raw XML input

xpz-reader

More from this repository

More from this repository

xpz-reader

GUIDELINE

PATH RESOLUTION

TRIGGERS

RESPONSIBILITIES

COMMUNICATION

STRUCTURE

WORKFLOW

QUALITY CHECKLIST

CONSTRAINTS

xpz-reader

GUIDELINE

PATH RESOLUTION

TRIGGERS

RESPONSIBILITIES

COMMUNICATION

STRUCTURE

WORKFLOW

QUALITY CHECKLIST

CONSTRAINTS