Menu
Generates and clones GeneXus XPZ objects conservatively — validates structure, applies risk rules, serializes envelope
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.
Based on SOC occupation classification
Valida o estado de uma pasta paralela de KB GeneXus antes do push (rotina pré-push de pasta paralela), rodando o orquestrador de gates mecânicos local do repositório ativo; não é a rotina pré-push do repositório de skills (documento 13)
Prepara e valida a estrutura inicial da pasta paralela da KB para carga inicial, sync de XPZ, índice derivado e artefatos de importação
Skill para importação e exportação de XPZ via MSBuild, com execução sem interface gráfica, parâmetros explícitos, rastreabilidade e gates (pontos de liberação ou bloqueio) de segurança
Permite ao agente principal delegar tarefas menores, pedir segunda opinião ou conduzir revisão por pares/peer review de plano/design por painel multi-modelo via opencode, Codex, Claude Code (Opus 4.8), GitHub Copilot CLI ou Gemini CLI; ao receber "revisão por pares", carregar esta skill, perguntar revisores preferidos se não houver preferred-reviewers.json, não presumir assinatura externa e nunca rotular parecer solo como revisão por pares; acionamento sempre humano
Skill para validação de build pós-import via MSBuild, com execução sem interface gráfica, parâmetros explícitos, classificação de resultado e gates de segurança contra reorg não autorizada
Backup auditável para aplicar patch textual Git já aprovado no Codex, em um repositório alvo, quando a rota nativa apply_patch estiver indisponível, falhar antes de escrita local ou for solicitada explicitamente.
| name | xpz-builder |
| description | Generates and clones GeneXus XPZ objects conservatively — validates structure, applies risk rules, serializes envelope |
Generates GeneXus XML objects for XPZ packaging using conservative cloning from empirical templates. Applies risk rules, validates structure, and serializes the correct XPZ envelope. Does not affirm import or build success — that requires external IDE validation.
Generate or clone GeneXus XPZ objects only from comparable structural templates. Abort when a suitable template does not exist. Never invent structure.
If the flow depends on a KB parallel folder structure and that structure is not yet mounted or validated, stop and use xpz-kb-parallel-setup first.
SKILL.md lives inside a skill subfolder under the repository root.../arquivo.md reference relative to the directory of this SKILL.md, not relative to the current working directory.../ points to the shared methodological base in the parent directory of this skill folder.Use this skill for:
<ExportFile> envelopeDo NOT use this skill for:
xpz-reader)xpz-index-triage first when a KbIntelligence index is available)If the main need is to prepare or validate the initial folder structure around the KB before any packaging flow, use xpz-kb-parallel-setup.
responsibilities-by-type/ end-to-end before generating, editing, or packaging the XML, in addition to this SKILL.md. Satellites consolidate type-specific RESPONSIBILITIES and QUALITY CHECKLIST entries. Available satellites: responsibilities-by-type/transaction.md (Transaction), responsibilities-by-type/webpanel.md (WebPanel), responsibilities-by-type/panel.md (Panel, especialmente Panel SD), responsibilities-by-type/dataprovider.md (DataProvider), responsibilities-by-type/api.md (API; carrega também responsibilities-by-type/api-gam-runtime.md, a pré-condição de segurança GAM em runtime que bloqueia declarar "seguro" sem o smoke 2 fases), responsibilities-by-type/procedure.md (Procedure, incluindo simple report Procedure), responsibilities-by-type/workwithforweb.md (WorkWithForWeb).adjacent block and open it only when there is explicit functional dependency with the primary edit blockObject/@guid, parent*, moduleGuid, all recurring Part types<Objects> and packages that use <FilePath> to point to external XMLruntime, Import File Load, Import, and Specification as distinct validation layers; success in one does not authorize conclusions about the othersSource compatibility by methodology first: GeneXus semantic rules plus the XPZ trail and nexa; use KB corpus search only as fallback when the methodological base does not cover the casewell-formed XML from probably importable object before packaging; never treat XML parse success alone as enough when the object depends materially on SourceSource, run ..\scripts\Test-GeneXusSourceSanity.ps1 -InputPath <arquivo> before packaging; treat sourceSanityStatus=fail as a hard stop and warn as consultative conservative reviewrequested change, necessary auxiliary change, or extra unrequested change before packagingextra unrequested change, including metadata, reserialization, or known noise that is not strictly requiredlastUpdate timestamp by mechanical rule, not by literal guess: for a modified object use max(UtcNow + 60s, official-corpus lastUpdate + 60s) and then reread the saved XML to confirm the persisted valuelastUpdate only for objects that are intentionally reenviados sem mudanca as dependency or package-composition closurelastUpdate equal to or older than the official corpus as a blocking defect when the object was modified in the roundlastUpdate on a modified object, or arbitrary future values as invalid lastUpdate generationObjetosDaKbEmXml as official snapshot and read-only for agentsObjetosDaKbEmXml for a delta that has not yet returned by official KB re-export as an explicit process error, not as a mere operational detailObjetosDaKbEmXml does not affect the packaging output — the packaging motor reads from the front folder (ObjetosGeradosParaImportacaoNaKbNoGenexus/<Frente>/), never from the corpus; if the agent edits the corpus expecting the package to pick up that version, the package will use the stale version from the front; this is an anti-pattern that the 9-FD gate detects (see 02-regras-operacionais-e-runtime.md, anti-padrão "editar acervo esperando que o pacote pegue")ObjetosGeradosParaImportacaoNaKbNoGenexusObjetosGeradosParaImportacaoNaKbNoGenexus, preserve the source XML outside the approved functional delta; the default operation is surgical editing, not broad reconstruction or full-file reserializationCDATA, indentation, blank lines, node order, line endings, and inherited whitespace; do not introduce trailing spaces or tabs on new or modified linesgit diff --check is not authorization to clean the whole XML file. Mechanical protection is partial in this version: the 9-FD gate used by New-XpzImportPackage.ps1 detects strong removal of inherited trailing whitespace against a unique-GUID baseline; it does not detect newly introduced trailing whitespace and is not a complete whitespace, reindentation, or EOL detector. front-textual-fidelity-info is informational only when there was a unique-GUID baseline but comparable UTF-8 text reading/decoding failed. On textual blocking, rebuild via Copy-GeneXusAcervoToFront.ps1 with an explicit target (-ObjectList, -ObjectNames, or -ObjectGuids) and reapply only the functional delta; explicit targets may overwrite an already edited/newer front copy.ObjetosDaKbEmXml para a frente em ObjetosGeradosParaImportacaoNaKbNoGenexus e editar somente o delta funcional aprovado na cópia de trabalho; nunca editar ObjetosDaKbEmXml diretamente.Source, Rules ou CDATA longos. Essa ferramenta pode: (1) normalizar linhas em branco indentadas (tabs/espaços herdados) para quebra de linha pura; (2) tratar \n\t\t\t\t\n e \n\n como equivalentes na comparação, impedindo correção por novo Edit; (3) introduzir espaços ou tabs no fim de linha ou ampliar o diff para longe do trecho pretendido.scripts/Edit-GeneXusXmlSurgical.ps1 (modos Replace e InsertAfter, validação de âncora, bump automático de lastUpdate com escape -PreserveLastUpdate para dependência reenviada sem mudança, -DryRun e -AsJson). Quando o baseline oficial estiver disponível, passar -LastUpdateBaselinePath apontando para o XML em ObjetosDaKbEmXml. Exemplo copiável: examples/Edit-GeneXusXmlSurgical.example.ps1. Evitar script ad-hoc por frente ou a ferramenta Edit do harness como caminho principal.Write só para XML pequeno e montado programaticamente a partir da leitura raw da origem; para Procedure/WebPanel/Transaction com Source longo, tratar Write do arquivo completo como alto risco de churn e evitar como caminho padrão.scripts/Show-FileWhitespace.ps1 (modos whitespace ou mixed; -AsJson para agentes) conforme AGENTS.md na raiz do repositório ativo — no arquivo inteiro ou no intervalo de linhas do delta.Source + Variables em objeto existenteQuando o delta inserir código em Source/CDATA e também criar ou alterar variáveis, declarar explicitamente a transição de bloco Source -> Variables (ou events -> variables, conforme o tipo) como bloco adjacente justificado; não tratar a seção Variables como detalhe implícito do patch de código.
Antes de montar o patch, medir a política textual do XML-alvo: EOL real do arquivo, regra aplicável em .gitattributes do repositório da KB, presença de BOM e estilo dominante de indentação no trecho. Em KB real analisada, Source usava tabs e Variables usava espaços, mas isso é evidência de corpus, não licença para sobrescrever o estilo do arquivo-alvo.
Para inserir em Source, preferir scripts/Edit-GeneXusXmlSurgical.ps1 com âncora literal e -DryRun; o Replacement deve ser construído já com a quebra de linha e a indentação observadas no arquivo-alvo. O helper preserva o texto fora do delta e faz bump de lastUpdate, mas não inventa a indentação correta para o chamador.
Para apenas re-carimbar o lastUpdate de um XML da frente já editado (rodada 2+), sem copiar do acervo nem aplicar delta, usar scripts/Set-GeneXusXmlLastUpdate.ps1 (-InputPath, -BaselineXmlPath opcional, -DryRun, -AsJson): recalcula max(UtcNow + margem, baseline + margem) e grava in-place com backup e validação, em vez de busca-e-troca manual do atributo. Sem -BaselineXmlPath, o baseline é o próprio arquivo — suficiente para ficar acima do objeto vivo na KB, que preserva o lastUpdate importado como Modified Date; para garantir acima do acervo, apontar -BaselineXmlPath para o XML oficial em ObjetosDaKbEmXml.
Para criar variável, não montar um bloco rígido universal. Clonar primeiro uma variável comparável do próprio objeto; se não existir, procurar uma variável comparável em objeto do mesmo tipo e da mesma KB; só então recorrer a molde sanitizado. Preservar a indentação estrutural da seção Variables.
O corpus real mostra famílias de tipagem por idBasedOn=Domain:*, idBasedOn=Attribute:*, ATTCUSTOMTYPE=bas:*, sdt:*, exo:*, bc:*, ext:* e formas legadas sem idBasedOn/ATTCUSTOMTYPE. Portanto, validações amplas sobre todo o legado devem ser consultivas; checks bloqueantes devem focar as variáveis novas ou declaradas como tocadas no delta.
Depois de inserir ou alterar variáveis, executar scripts/Test-GeneXusObjectVariableDelta.ps1 -InputPath <xml> -VariableName <nomes> -AsJson para as variáveis novas/tocadas. Tratar status=fail como bloqueio antes do pacote; tratar status=warn como revisão conservadora explícita. Sem -VariableName, o script é varredura consultiva do objeto inteiro, não reprovação automática do legado.
Não validar ingenuamente todas as ocorrências de &X no Source contra <Variables>: o corpus contém entidades XML, variáveis especiais e formas geradas que produzem falsos positivos. Para pacote, validar as variáveis do delta e o trecho funcional tocado.
Alterar Source ou Variables no XML não altera lastUpdate por si só. O arquivo final modificado deve sair com lastUpdate calculado pelo helper ou por regra equivalente antes de empacotar; checksum defasado pode ser observado como ressalva, mas não substitui o gate de lastUpdate.
The set of standard KB parallel-folder subfolders (ObjetosDaKbEmXml, XpzExportadosPelaIDE, scripts, Temp, KbIntelligence, ObjetosGeradosParaImportacaoNaKbNoGenexus, PacotesGeradosParaImportacaoNaKbNoGenexus) and their recommended creation order are normative in the xpz-kb-parallel-setup skill — see xpz-kb-parallel-setup/SKILL.md. This builder assumes those names by default and falls back to xpz-kb-parallel-setup when alternative naming, structural ambiguity, or missing setup is detected.
If XpzExportadosPelaIDE does not exist yet, ask where the user wants to store exported .xpz files
If ObjetosDaKbEmXml does not exist yet, stop and treat the KB as not yet materialized
Use ObjetosGeradosParaImportacaoNaKbNoGenexus as the working area for locally generated or preserved XML
For each active front, create or reuse a dedicated subfolder under ObjetosGeradosParaImportacaoNaKbNoGenexus in the format NomeCurto_GUID_YYYYMMDD
Treat YYYYMMDD in that identifier as the creation date of the front, defined at the same moment the GUID is created; it is not the package date
Distinguish explicitly between same object and same front
Do NOT reuse front identity, short-name prefix, front GUID, front creation date, or package counter only because the target object is the same
Reuse the existing front subfolder only when the work is explicitly confirmed or directly evidenced as a continuation of that same front; do NOT create a second front folder for the same active front without explicit reason
Use PacotesGeradosParaImportacaoNaKbNoGenexus as the destination area for locally generated packages
Detect workspace contamination before packaging and abort when more than one plausible batch is active
Treat the workspace as contaminated when the active root of ObjetosGeradosParaImportacaoNaKbNoGenexus contains XMLs from different fronts, different target objects, superseded deltas, or unrelated older files that could be mistaken for the current batch
Build or validate a manifest for the candidate batch before packaging, treating the manifest first as structured output in the conversation
When an earlier round of the same front has already been validated, the next round should prefer a delta package with the new increment, not an unnecessarily large accumulated package
Reusing the same front does not authorize automatically re-packaging the whole active history of that front; the candidate batch for the current round must be reduced to the delta that is still needed
A phased front is a legitimate pattern when a GeneXus operational limitation makes a safe monolithic package impractical; in that case, splitting the delivery into sequential rounds is part of the methodology, not an ad hoc workaround
Classify the package intent explicitly before packaging as exactly one of:
pacote funcional = objetivo principal e alterar comportamento funcional esperadopacote experimental = objetivo principal e testar serialização, roundtrip IDE/XPZ, preservação textual, envelope ou comportamento metodológico do fluxopacote arquitetural = objetivo principal e reorganizar estrutura, dependências ou forma de implementação sem provar sozinho mudança funcionalpacote cirurgico = objetivo principal e corrigir falha localizada ou objeto pontual com delta mínimoTreat that package-intent classification as mandatory narrative context, not as optional labeling
Require a single primary intent per package; if the candidate batch mixes functional change, textual experiment, and architectural adjustment without clear separability, ABORT for confirmation or split the package plan before writing
For pacote experimental, describe the expected proof narrowly and do not imply functional validation unless an external IDE/import/specification step actually covered it
When the user already signals manual IDE import/testing, treat import_file.xml as the primary deliverable and generate it promptly instead of postponing packaging
Prefer import_file.xml as the operational package artifact for manual IDE import unless .xpz is explicitly required by the user or by a documented local flow
Do NOT generate .xpz as an extra artifact by default when import_file.xml already satisfies the intended manual IDE import flow
Name locally generated packages for IDE import using the preferred pattern NomeCurto_GUID_YYYYMMDD_nn.import_file.xml
In that package name, the front is identified only by the prefix NomeCurto_GUID_YYYYMMDD; nn is only the short package round for that front
For successive micro-adjustments in the same active front, keep the same front subfolder and the same package prefix NomeCurto_GUID_YYYYMMDD; advance only nn
Before writing NomeCurto_GUID_YYYYMMDD_nn.import_file.xml, run a deterministic collision gate in .ps1; do NOT leave this decision to ad hoc reasoning
Shared packaging helpers emit machine JSON on stdout by default and do not use -AsJson; update old local wrappers through xpz-kb-parallel-setup
When the recommended helper Build-GeneXusImportFileEnvelope.ps1 is used, the collision gate is embedded and runs before any byte is written; the file is materialized only when the gate returns JSON with status=ok
When the recommended helper Build-GeneXusImportFileEnvelope.ps1 is used, pass -AcervoPath <ObjetosDaKbEmXml>; before serializing the package, the helper always checks front-vs-acervo coherence: the lastUpdate gate and Object/@type drift by same guid. Declaring modified objects with -ModifiedObjectNames or -ModifiedObjectGuids lets it block lastUpdate older than the acervo, lastUpdate equal to the acervo for declared modified objects, and unjustified future timestamps. It still covers documentary coherence of lastUpdate and Object/@type under its current contract, but it does not cover strong global trim in this version.
When the target flow is headless MSBuild import (xpz-msbuild-import-export) and the object XML already exists in the parallel KB tree (ObjetosDaKbEmXml as read-only reference or ObjetosGeradosParaImportacaoNaKbNoGenexus as working copy), prefer assembling import_file.xml with a shared structured engine: Build-GeneXusImportFileEnvelope.ps1 for direct template-based assembly, or the safe wrapper New-XpzImportPackage.ps1 for front-based assembly from the parallel KB folder. Use a validated template (KMW, Source, ObjectsIdentityMapping from local precedent, or metadata such as kb-source-metadata.md per xpz-kb-parallel-setup for simple/minimal envelopes), then import that package — do not run a KB export only to obtain a .xpz "shell" to patch in parallel XML unless the user explicitly requests that path or confirms that envelope metadata cannot be obtained otherwise (if an exported .xpz is used anyway, xpz-msbuild-import-export requires a full pre-import object inventory)
For compact inspection of XML/XPZ without dumping large CDATA, use scripts\Extract-XpzObject.ps1, scripts\Get-GeneXusObjectSummary.ps1, and, for Panel shape checks, scripts\Compare-GeneXusPanelShape.ps1 before resorting to raw Select-String or broad rg output; when comparing Panel SD, observe at least actionEventCoverage, namedEventNames, standardEventNames, variableEventNames, and tapEventNames. For WebPanel, the same script exposes a webpanel block (tables with tableType, controls, buttons in both forms, events, and a coverage block); load responsibilities-by-type/webpanel.md before editing WebPanel layout or events. To add a button to a WebPanel, prefer scripts\Add-GeneXusButton.ps1 (inserts before or after a named leaf control in a Flex table via -BeforeControlName/-AfterControlName; fail-closed on populated Responsive) instead of hand-editing the CDATA.
If a textual search in the corpus returns multiple XML paths, list every match, state a recommended path with reason from user context, and confirm before opening one file; never default to the first tool result.
In the manual fallback path (textual envelope assembly without the helper), prefer a local wrapper such as Test-*KbPackageCollision.ps1, delegating to the shared engine scripts\Test-XpzPackageCollision.ps1
If the collision gate returns JSON with status=bloqueado or non-zero exit code, abort the write; do NOT silently overwrite that round
When there is an nn collision, the suggested next free nn must come from the collision gate output itself; do NOT auto-increment or write automatically with the suggested value
Keep PacotesGeradosParaImportacaoNaKbNoGenexus flat, without subfolders by front
Classify each active XML root as Object, Attribute, or unsupported before serializing the package
Validate UTF-8 without BOM hygiene on active XMLs before packaging
Validate textual delta fidelity on active XMLs before packaging: only the approved functional delta should appear in comparison against the source XML
Reread and apply local repository documentation (AGENTS.md, README.md, and equivalent project docs) before packaging whenever the target KB/repository defines specific functional review rules, contracts, or operational flow
Use local repository documentation as the mandatory specialization layer for KB-specific contracts and review chains, without promoting those local rules to the shared XPZ methodology
Keep general XPZ methodology separate from KB-specific architecture; flows such as WorkWithWeb -> action -> parm(...) -> For each may be mandatory in a given repository but are not universal GeneXus or XPZ rules
Ensure all GUIDs are syntactically valid (no text placeholders like "YOUR-GUID-HERE")
Validate XML structure before delivery
Declare confidence level and limitations explicitly at the end of every output
When generating an object for a small or new KB that has no comparable local XML: follow the resource ladder from 08-guia-para-agente-gpt.md; if reaching level 2 (best-effort attempt without commitment), declare explicitly which source sustains the generation (molde sanitizado, XML real da KB atual, XML real de KB externa inspecionada, or hipótese), signal the confidence level, and require validation before import; if the probability of success is assessed as low, present the options to the user and wait for a decision before generating
Keep WorkWithWeb noise that is already proven in this trail as non-functional in the manifest, especially Load Code in Selection and the affected View tabs; do not generalize this to unrelated WorkWithWeb cases
When declaring a variable as an SDT collection in any object type (API, WebPanel, Procedure, DataProvider): use AttCollection=True; NEVER use Collection=True or IsCollection=True — both are invalid and will be rejected; this applies to the variable's <Properties> block in the XML
Source delta and already covered by the methodological base, prefer = new(); do NOT accept unsupported cleanup forms such as SetEmpty() only by plausibility or analogyDateTime field, prefer direct comparison on the DateTime column: >= start and < next day after endToDate() over the column, as explicit navigation/performance riskwhere clauses instead of branching into unnecessary scenariosSource, prefer following that form as a weak readability heuristic, not as a hard methodological ruleWhen the candidate batch contains 2 or more distinct objects, run the Import Dependency Ordering gate (9-IDO) after all other object-level gates: detect structural dependencies between batch objects, assign each object to a topological layer, alert when ordering risk exists across 2 or more layers, and ABORT when circular dependencies are found
pacote funcional, pacote experimental, pacote arquitetural, or pacote cirurgicolastUpdate was confirmed, and the applicable local repository rules were reread and satisfied before packagingReference files and when to load them:
| Reference | Load when |
|---|---|
| 00-indice-da-base-genexus-xpz-xml.md | Always — absolute rules and envelope structure |
| 02-regras-operacionais-e-runtime.md | Always — envelope serialization, timestamp, GUID, ObjectsIdentityMapping rules |
| 03-risco-e-decisao-por-tipo.md | Always — risk level and abort conditions |
| 04-webpanel-familias-e-templates.md | Target is a WebPanel object |
| 05-transaction-familias-e-templates.md | Target is a Transaction object |
| 05b-procedure-relatorio-familias-e-templates.md | Target is a simple report Procedure, especially F2/F3 covered by molde pronto |
| 07-open-points-e-checklist.md | Edge cases, provisional decisions, or checklist for new templates |
| 08-guia-para-agente-gpt.md | Decision formula, precedence rules, materialization rules, refuse conditions |
| 01j-workwithweb-cdata-padroes.md | When editing CDATA of a WorkWithForWeb object — CDATA hierarchy, anchor rules, sanitized examples |
| 04b-ucw-gxcontroltype-reference.md | When the target is a WebPanel with UCW (<ucw gxControlType="...">) — gxControlType catalog, upload context table, event rules, SDT FileUploadData, AttCollection rule |
xpz-index-triage skill | When a KbIntelligence index is available and locating comparable corpus XMLs or confirming object existence is needed before opening XML files |
xpz-kb-parallel-setup firstObjetosDaKbEmXml = official snapshot, read-only for agentsXpzExportadosPelaIDE = input area where the user stores .xpz exported by the IDEObjetosGeradosParaImportacaoNaKbNoGenexus = working area for local XMLs to import manually, organized by front subfolder NomeCurto_GUID_YYYYMMDDPacotesGeradosParaImportacaoNaKbNoGenexus = output area for locally generated packages, kept flat without subfolders by frontObjetosGeradosParaImportacaoNaKbNoGenexus
3b. When the user goal is headless import via MSBuild and the delta XML already lives in the parallel folder, plan delivery as import_file.xml through Build-GeneXusImportFileEnvelope.ps1 (mandatory -AcervoPath <ObjetosDaKbEmXml>; front-vs-acervo coherence by lastUpdate and Object/@type; declare objects actually modified in the round via -ModifiedObjectNames or -ModifiedObjectGuids) or the front-based safe wrapper New-XpzImportPackage.ps1 flow (which also runs 9-FD textual fidelity, blocks strong removal of inherited trailing whitespace by unique-GUID baseline, and may emit informational front-textual-fidelity-info when there is a unique-GUID baseline but comparable UTF-8 text reading/decoding failed; partial protection, not a complete whitespace/reindentation/EOL detector) plus skill xpz-msbuild-import-export for execution + package inventory; do not default to KB export to manufacture a .xpz shell unless the user explicitly chooses that path or confirms envelope assembly is blocked
3c. For Panel, especially Panel SD, treat level id and layout id as an internally coherent pair. NEVER generate them as independent random GUIDs. Clone or preserve the pair from a comparable real template exported by the IDE from the same KB whenever possible; if the exact derivation rule is unknown, declare the risk and use a coherent template pair instead of isolated GUID substitution.
3d. When packaging a Panel, prefer a full comparable IDE-exported envelope through -TemplatePackagePath (accepted as .import_file.xml/XML or .xpz) so KMW, Source, Dependencies, Attributes when present, and ObjectsIdentityMapping come from a real package. If the package is generated from the minimal kb-source-metadata.md envelope, report that as a warning for Panel SD instead of implying equivalence with a full IDE envelope.
3e. For Panel SD with <action onClickEvent=...>, read the serialized behavior in detail/@events. Do not synthesize Event Controle.Tap without equivalent evidence in a comparable real Panel from the target KB; prefer a named Event 'Nome' whose quoted name matches the action onClickEvent.same front or new frontsame front only because the object is the sameNew-*KbFront.ps1) or the shared engine scripts\New-GeneXusXpzFront.ps1 is directly approved, prefer that atomic wrapper/engine to create or reuse the front folder, generate the front GUID, calculate YYYYMMDD, and return any extra GUIDs needed by the batchsame front vs new front decision above remains mandatoryNomeCurtoGUID generated when the front is openedYYYYMMDD = creation date of the front, defined together with the GUID; it is not the package dateObjetosGeradosParaImportacaoNaKbNoGenexus\NomeCurto_GUID_YYYYMMDD\round spec for this round; it is the committed delivery target before the workspace is inspectedobjetos-foco for any xpz-sync invoked in the same session for this frontFrontPrefix + nn in PacotesGeradosParaImportacaoNaKbNoGenexus:
Build-GeneXusImportFileEnvelope.ps1 (recommended path), pass mandatory -AcervoPath <ObjetosDaKbEmXml> and declare modified objects with -ModifiedObjectNames or -ModifiedObjectGuids; the collision gate is embedded: the helper runs Test-XpzPackageCollision.ps1 as its first action and aborts with zero bytes materialized when _nn is taken; the helper also blocks before writing when front-vs-acervo coherence fails by lastUpdate or by same guid with divergent Object/@type; this direct helper does not cover strong global trim in this version. For front-based assembly, use New-XpzImportPackage.ps1, whose 9-FD gate also blocks strong removal of inherited trailing whitespace by unique-GUID baseline and may emit informational front-textual-fidelity-info only when comparable UTF-8 text reading/decoding fails after such a baseline is found; in the direct-helper flow, no explicit pre-call to the wrapper is requiredSet-Content, rename, move, or overwrite of the package artifactTest-*KbPackageCollision.ps1 when the KB/repository publishes itscripts\Test-XpzPackageCollision.ps1-AsJson):
status=ok, reason=COLLISION_OK, exit 0status=bloqueado, reason=PACKAGE_ROUND_COLLISION, blockingReasons, nextFreeNN/nextFreeRound, exit 20status=bloqueado or non-zero exit code), ABORT packaging before any Set-Content, rename, move, or overwrite of the package artifactpacote funcionalpacote experimentalpacote arquiteturalpacote cirurgicopacote experimental, state the bounded proof target explicitly, such as serialização, roundtrip IDE/XPZ, preservação textual, or envelope/importaçãopacote experimental, do NOT narrate the package as if it already proved business behaviorArquivoMorto; do so only after explicit user approvalartifact of the current front and pre-existing parallel change:
requested change, necessary auxiliary change, or extra unrequested changeextra unrequested change explicitly before packaging; do NOT silently absorb it into the packageOBSOLETO_ or present a structured manifest in the conversation stating that package X was replaced by package Y; save that manifest as a local file only when local traceability is concretely needed
9-BC. BC dependency preflight gate — run before any packaging when the batch contains a Procedure:& ..\scripts\Test-GeneXusBCDependency.ps1 -FrontFolder <pasta-da-frente> -CorpusFolder <ObjetosDaKbEmXml> -AsJsonnot-applicable (no Procedure in the batch) → proceed normallypass (all BC dependencies resolved as info; Transactions exist as BC in the corpus) → proceed normallyalert (one or more warn findings) → present each warn finding to the user; require explicit confirmation to package the Procedure(s) and Transaction(s) together, or stage into two packages — package 1 with the Transaction(s), package 2 with the dependent Procedure(s)fail (any fail finding) → ABORT packaging; report each finding (procedureName, transactionName, code, location) and the corrective action implied by the code:
bc-isbc-false-batch / bc-isbc-property-absent-batch: correct the Transaction XML in the batch to set idISBUSINESSCOMPONENT=True before packagingbc-isbc-false-corpus / bc-isbc-property-absent-corpus: the Transaction exists in the official corpus but is not a Business Component; the bc: dependency cannot be satisfied without correcting and reimporting the Transaction firstbc-missing-everywhere: the Transaction is absent from both the batch and the official corpus; add it to the batch or confirm its existence in the target KB before packagingbc-sublevel-not-found-batch / bc-sublevel-not-found-corpus: the Transaction exists as BC, but the sublevel referenced by bc:<Transaction>.<Sublevel> is not present in its Levels; correct the BC reference or the Transaction structure before packagingfail finding remains unresolved
9-WW. WorkWithWeb Apply-mark preflight gate — run before any packaging when the batch contains a WorkWithForWeb object:& ..\scripts\Test-GeneXusWorkWithWebApply.ps1 -FrontFolder <pasta-da-frente> -CorpusFolder <ObjetosDaKbEmXml> -AsJsonbabfa2b2-... with explicit Apply property; Form B = Part a51ced48-... with <Data Pattern="..."> and linked Transaction in CDATA; Form B implicitly treats Apply as True), resolves the linked Transaction name (Property in Form A, <transaction transaction="<guid>-<name>" /> element in Form B), and verifies Apply:78cecefe-be7d-4980-86ce-8d6e91fba04b = True on that Transaction in the batch or in the corpus.not-applicable (no WorkWithForWeb in the batch) → proceed normallypass (only info findings: Apply:GUID=True confirmed in batch or corpus) → proceed normallyalert (one or more warn findings) → review each finding; for ww-form-a-apply-false confirm whether pattern disablement is intentional; for ww-applyguid-absent-corpus verify KB state preserves the pattern; for ww-applyguid-tx-missing document the gap before packagingfail (any fail finding) → ABORT packaging; the script reports each finding with code and the corrective action implied:
ww-no-form-detected: the XML is unrecognizable as a WorkWithForWeb in either expected form — structural errorww-form-a-apply-property-absent: add <Name>Apply</Name><Value>True</Value> to the Part babfa2b2-... before packagingww-linked-transaction-missing: the WorkWithForWeb does not expose the linked Transaction name in an extractable way — fix the source XMLww-applyguid-false-batch: the linked Transaction is in the batch but lacks Apply:78cecefe-...=True — add the property before packaginginfo findings for diagnostic context (ww-both-forms-detected for the rare case of coexistence, ww-applyguid-true-batch/ww-applyguid-true-corpus for confirmed cases). These do not require action.
9-TWS. Transaction Coherence preflight gate — run before any packaging when the batch contains a Transaction:& ..\scripts\Test-GeneXusTransactionCoherence.ps1 -InputPath <arquivo> -AsJson for each Transaction XML in the batchnot-applicable (object is not a Transaction or no Transaction found) → proceed normallyfail → ABORT: correct the structural issue (missing key in Level, DescriptionAttribute not found in Level, or WorkWithPlus DVelop screen code — Call("LoadWWPContext")/Call("<Trn>WW") — carried by a GenerateObject=False Transaction, finding wwp-screen-code-on-non-generated-transaction; see responsibilities-by-type/transaction.md) before packagingwarn → keep packaging blocked; each flagged finding must be reviewed and either corrected or explicitly justified before proceeding; accepted justifications must be recorded in the closing declarationpass → proceed to next gate
9-TXW. Transaction Writability gate — run before any packaging when the batch contains a Transaction whose delta involves Rules or Events with attribute assignments:schema_version>=2), you may use transaction-writable-attributes for triage before opening XMLs; packaging still requires Test-GeneXusTransactionWritability.ps1 unless Test-GeneXusKbIntelligenceWritabilityParity.ps1 has passed on that parallel KB folder& ..\scripts\Test-GeneXusTransactionWritability.ps1 -TransactionPath <transaction.xml> -CorpusFolder <ObjetosDaKbEmXml> -AsJson for each Transaction XML whose delta assigns attributes (PowerShell facade over GeneXusTransactionWritabilityCore.py)pass after classifying every (level, attribute) pair into levelAttributes with writable=true|false|null and a classification (key-attribute, extended-parent-fk, formula, extended-subtype-key, extended-subtype-descriptive, extended-fk-key, extended-fk-descriptive, own-physical, unclassified-attribute-not-found, unclassified-table-not-found)writable=false must be excluded from assignments in the delta; assigning to a non-writable attribute requires an explicit ABORT of the assignment before packagingwritable=null (any unclassified-* classification) means the corpus lookup did not resolve and the writability cannot be decided; resolve the corpus gap or document the limitation before assigning that attributefail by itself — the ABORT comes from the assignment policy above
9-PNW. Procedure New Writability gate — run before any packaging when the batch contains a Procedure whose Source contains New:& ..\scripts\Test-GeneXusNewWritableTargets.ps1 -FrontFolder <pasta-da-frente> -CorpusFolder <ObjetosDaKbEmXml> -AsJson (PowerShell facade; writability classification via GeneXusTransactionWritabilityCore.py batch)New/EndNew block, infers candidate Transaction targets from the assigned attribute set, and applies the same writability classifications used by 9-TXW.pass (only info findings) → proceed normallyalert (ambiguous target with all assigned attributes writable in more than one candidate) → confirm and record the intended base table before packagingfail (new-assignment-non-writable, new-assignment-unclassified, or new-target-unresolved) → ABORT packaging; remove the invalid assignment or prove the intended base table with a stronger local reference before re-runningNew only because it is visible, inferable, descriptive, formula-derived, or reachable through an extended table; the target must be physically assignable in the base table inferred for that New
9-PSM. Procedure Sub-pattern Mirroring gate (advisory) — run before any packaging when the batch contains a Procedure:& ..\scripts\Test-GeneXusProcedureSubPattern.ps1 -FrontFolder <pasta-da-frente> -CorpusFolder <ObjetosDaKbEmXml> -AsJsonnot-applicable (no Procedure in the batch) → proceed normallypass (only info findings: no pattern to mirror, Procedure new, or new Sub coherent with dominant pattern) → proceed normallyalert (one or more warn findings with code psm-new-sub-mixed-diverges) → present each alert to the user using the message from the script; the dominant pattern (iterationSub → unitSub) is in the finding's dominantPattern field; require the user to either confirm the divergence is intentional (justification recorded in the closing declaration) or restructure the new Sub to mirror the pattern before packagingfail and never ABORTs packaging by itself& ..\scripts\Test-GeneXusBatchDependencyOrdering.ps1 -FrontFolder <pasta-da-frente> -CorpusFolder <ObjetosDaKbEmXml> -AsJsonnot-applicable (fewer than 2 objects in the batch) → proceed normallypass (single layer — no in-batch dependency edges detected) → proceed normallyalert (warn finding ido-multiple-layers) → present the suggested staging (layers in the finding) to the user; require explicit confirmation or justification before proceeding with single-bundle packagingfail (fail finding ido-cycle-detected) → ABORT packaging: present the cycle (listed in the finding) to the user and require resolution before re-runningWorkWithForWeb objects, the script also emits an info finding with code ido-ww-detection-pending — the WorkWithForWeb → linked Transaction dependency detection is not yet wired into this script, even though the 9-WW gate itself now reads both structural forms. When this info finding is present and the batch mixes a WorkWithForWeb and its linked Transaction, the agent must verify ordering manually (read the linked Transaction from the WorkWithForWeb XML using the 9-WW form detection rules, then check whether that Transaction is in the batch) before packagingbc:<X> → Transaction X when X is in the batch; (b) Procedure A → Procedure B when A calls B in its Source and B is new in this delta (not in ObjetosDaKbEmXml). Procedure → Procedure detection is best-effort scan of Source — false positives may be filtered by user review
9-FD. Front-Acervo drift gate — run before any packaging when ObjetosDaKbEmXml exists as the official corpus:& ..\scripts\Test-GeneXusFrontAcervoDrift.ps1 -FrontFolder <pasta-da-frente> -AcervoFolder <ObjetosDaKbEmXml> -AsJsonnot-applicable (no Object XMLs in the front) → proceed normallypass (only info findings) → proceed normallyalert (one or more warn findings) → present each warn finding to the user; for front-equals-acervo confirm whether the lastUpdate was intentionally preserved (dependency re-sent without change) or needs updating; for lastupdate-unparseable resolve manually before packagingfail (any fail finding) → ABORT packaging; report each finding and the corrective action:
front-older-than-acervo: the XML in the front has an older lastUpdate than the corresponding XML in the official corpus — use Copy-GeneXusAcervoToFront.ps1 (& ..\scripts\Copy-GeneXusAcervoToFront.ps1 -FrontFolder <pasta-da-frente> -AcervoFolder <ObjetosDaKbEmXml>) to copy the newer version from the corpus to the front with automatic lastUpdate bump, or copy manually and bump the lastUpdate; for initial seed of an existing corpus object that is not yet in the front, call the same script with explicit -ObjectList, -ObjectNames or -ObjectGuids; after resolution, re-run the 9-FD gate to confirm the drift is cleared. Pre-requisite for any populate/seed: the front folder must already exist, opened by New-GeneXusXpzFront.ps1 (wrapper New-*KbFront.ps1, -ReuseIfExists to resume) — do not create it manually; Copy-GeneXusAcervoToFront.ps1 and the gates only populate/inspect an existing frontfront-object-type-drift: the front XML and official corpus XML have the same guid but different non-empty Object/@type after Trim() — ABORT and ask for a human decision. Do not auto-copy from the corpus or bump lastUpdate; first determine whether the correct object is the front XML, the corpus XML, or whether the generated/selected XML is contaminated. Public type-drift payload uses normalized objectGuid, matchBasis=guid, acervoPath, and message.front-textual-fidelity-trim-removal-churn: the front XML removed inherited trailing whitespace at strong scale against a unique-GUID baseline — ABORT, rebuild the front XML from the corpus with Copy-GeneXusAcervoToFront.ps1 using an explicit target (-ObjectList, -ObjectNames, or -ObjectGuids), reapply only the functional delta, and re-run 9-FD. Explicit targets may overwrite an already edited/newer front copy; use them deliberately, preferably with -DryRun. Public blocking payload includes classification, whitespaceTrimPairCount, functionalChangedLineEstimate, acervoLineCount, and thresholds. This is partial mechanical protection only; do not treat it as a complete whitespace, reindentation, or EOL detector.front-textual-fidelity-info: comparable UTF-8 text reading/decoding failed after a unique-GUID baseline was found — informational only; do not treat it as proof that whitespace fidelity was checked, and do not expect it for every case where textual comparison is skipped (for example, no baseline or ambiguous GUID). Public informational payload uses classification='not-applicable' and reason.front-object-type-drift-ambiguous-acervo: the same normalized guid appears in more than one corpus XML — informational only in Phase 1, with matchBasis=guid-ambiguous and non-empty candidateAcervoPaths; do not choose an official Object/@type arbitrarily.New-XpzImportPackage.ps1 (the front-based packaging wrapper), this gate always runs before the Python motor is invoked (fail-closed): -AcervoPath is optional and, when omitted, the canonical acervo <RepoRoot>/ObjetosDaKbEmXml is auto-resolved; with no acervo resolvable, packaging is blocked (the gate is never skipped by omission). The JSON field acervoResolvedBy reports explicit or convention. fail and alert both block automatic packaging, because warn findings require explicit acknowledgment or resolution before another packaging attemptObjetosDaKbEmXml); 9-FD compares front vs. corpus content, while 12 detects direct edits in the read-only corpusObjetosDaKbEmXml:ObjetosGeradosParaImportacaoNaKbNoGenexus, restore ObjetosDaKbEmXml to the official Git version, present a structured manifest of preserved items in the conversation, save it as a local file when incident traceability requires it, and ABORT packaging until the snapshot is saneObjetosGeradosParaImportacaoNaKbNoGenexusWebPanel, declare the primary edit block before touching the XML and use only the adjacent blocks required by explicit functional dependencyDataProvider, declare the primary edit block before touching the XML and use only the adjacent blocks required by explicit functional dependencyAPI, declare the primary edit block before touching the XML and use only the adjacent blocks required by explicit functional dependencyProcedure → use the canonical sanitized family from 05b-procedure-relatorio-familias-e-templates first when the case fits simple F2/F3 coverage and the selected block is marked as molde prontoProcedure, escalate to comparable real XML only when the request falls outside the documented simple family, when the initial attempt plus one short structural corrective attempt already failed, or when KB-local dialect/localism appearsProcedure, every output or handoff must label the basis used as exactly one of: molde sanitizado, XML real da KB atual, XML real de outra KB, or hipóteseObject/@parentType — never from the directory name in ObjetosDaKbEmXml, which varies across KBs. The canonical mapping of container GUIDs lives in scripts/gx-object-type-catalog.json (entries Folder for user-created containers, Module for GeneXus system/organizational containers, PackagedModule for installed modules, and RootModule for the virtual KB root that has no XML file in the acervo). Read the GUID from the corpus XML and look it up in the catalog; do NOT hardcode parentType GUIDs inline.Object/@guid (new GUID only for new objects, never reuse existing object's GUID)parent, parentGuid, parentType, moduleGuidfullyQualifiedName, name, parent, parentGuid, parentType, moduleGuidObject/@name, fullyQualifiedName, guid, Name property, Description, Source, Rules/parm, internal calls, dependencies, and ObjectsIdentityMappingfullyQualifiedName by concatenating parent + "." + nameparentType is 00000000-0000-0000-0000-000000000008 (Module/Folder), treat the container name as container only; it must appear in parent/parentGuid, not be promoted automatically into fullyQualifiedNameparentType is c88fffcd-b6f8-0000-8fec-00b5497e2117 (PackagedModule), allow module qualification in fullyQualifiedName only when comparable corpus objects of the same KB confirm that patternWebPanel, verify where each relevant property is actually persisted before editing: Conditions may live in its own Part, while ControlWhere, ControlBaseTable, ControlOrder, ControlUnique, PATTERN_ELEMENT_CUSTOM_PROPERTIES, and WebUserControlProperties often live inside serialized layout metadata; follow the operational rules in 02-regras-operacionais-e-runtimeWebPanel, treat serialized functional metadata as its own functional layer; do NOT collapse it into visual layout when planning or reviewing the deltaWebPanel, do NOT treat template defaults mentioning Conditions as proof that a real filter is materialized in the objectWebPanel, NEVER manually reconstruct serialized layout CDATA after truncated reading; extract the full block structurally or apply a surgical substitution on the full raw file while preserving the original serialized layout byte-for-byte outside the intended deltaWebPanel, name each justified block transition during review, for example events -> variables or layout -> serialized functional metadataWebPanel, if the current reasoning no longer needs a new block, stop expanding; do NOT reopen the whole object by reflexDataProvider, treat Output structure as its own functional layer; do NOT collapse return shape into a generic Source readingDataProvider, if the delta touches collection vs simple, nested groups, node names, or return cardinality, classify Output structure as the primary edit block unless explicit evidence points elsewhereDataProvider, if the delta depends on For each, base table, filters, or navigation ambiguity, open Navigation context only as an explicitly justified adjacent blockDataProvider, do NOT treat SDT, Procedure, BC, or Transaction dependency inventory by itself as proof of the output shapeDataProvider, name each justified block transition during review, for example Output structure -> Source or Source -> Navigation contextDataProvider, if the current reasoning no longer needs a new block, stop expanding; do NOT reopen the whole object by reflexAPI, treat Service contract and Data contract as their own functional layers; do NOT collapse endpoint contract, response shape, and internal orchestration into a generic code readingAPI, if the delta touches exposed method, endpoint, signature, published operation, input/output shape, or response structure, classify Service contract or Data contract as the primary edit block unless explicit evidence points elsewhereAPI, if the delta depends on .Before/.After, internal validation, transformation, or orchestration flow, open Events and orchestration only as an explicitly justified adjacent blockAPI, do NOT treat Procedure, SDT, Domain, Transaction, EXO, or DataProvider dependency inventory by itself as proof of the published contractAPI, name each justified block transition during review, for example Service contract -> Data contract or Events and orchestration -> Calls and dependenciesAPI, if the current reasoning no longer needs a new block, stop expanding; do NOT reopen the whole object by reflexSource, classify every new operator, function, conversion, and string/numeric pattern introduced by the changeSource construct must be anchored by layer-1 methodological evidence from this XPZ trail: explicit rule, sanitized example, or documented templateSource construct is still justified only by plausibility, generic GeneXus memory, or isolated local corpus evidence, rewrite it using documented patterns or ABORTSource, classify the result explicitly as well-formed XML and minimum Source sanity gate passed or failedSource sanity gate failed, ABORT packagingSource sanity checks from the repository only as advisory support; a pass does not prove import/build success& ..\scripts\Test-GeneXusSourceSanity.ps1 -InputPath .\Objeto.xmlxmlWellFormed=false -> ABORT before any packaging discussionsourceSanityStatus=fail -> ABORT packaging and correct structural balance first
fail also covers the type-aware finding procedural-in-conditions: a Procedure with a non-empty Conditions part is rejected because Procedure has no Conditions filter (predicates live in For Each ... Where) and code there triggers src0055 on import; WebPanel/Prompt/Selection List, where Conditions is a legitimate filter, and Data Selector, which has its own Conditions, stay outsourceSanityStatus=warn with probablyImportable=true -> keep packaging blocked until each warning is either rewritten to a documented conservative form or explicitly justified as residual risksourceSanityStatus=pass with xmlWellFormed=true -> proceed only to the next packaging gate; do NOT describe this as proof of import/build successSource is serialized inside CDATA, scan the saved block before packaging and ABORT if the literal code still contains XML entity spellings such as &, ", >, or < that should have remained raw code charactersProcedure, classify each edited fragment before serialization as Source, Rules, or layout and reject any cross-layer mixtureProcedure, load 05b-procedure-relatorio-familias-e-templates.md as a mandatory reference before generating from molde pronto; do NOT treat that read as optionalProcedure, verify coherence between layout PrintBlock names and each print printBlock... reference in SourceProcedure, if Source prints printBlockX, require a matching layout PrintBlock with coherent RPT_INTERNAL_NAME; if the pair is missing, ABORT before packagingProcedure, when cloning or adapting PrintBlock elements, verify that each RPT_INTERNAL_NAME value is unique across all sibling blocks in the layout Part; duplicate RPT_INTERNAL_NAME values across distinct blocks are a hard structural error — ABORT before packagingProcedure, treat the total layout width as a structural constant inherited from the source template or reference XML; do NOT invent or assume a default value — read it from the canonical template or cloned source; when the value is ambiguous, document the observed value explicitly in the packaging rationale before proceedingProcedure, if an import error points to invalid control, report block, or layout shape, inspect layout first before altering envelope<Objects> and package using <FilePath> to external XMLimport_file.xml as soon as the delta is materially ready instead of postponing package creationimport_file.xml as the primary package artifact for manual IDE import unless .xpz is explicitly required<ExportFile> with <KMW>, <Source>, <Objects>, <Dependencies>Source/@kb and Source/Version/@guid in valid GUID formatSource/@kb from the package or template must match that native KB. If it differs, treat the package as cross-KB, ABORT agent automation, and route the case to manual IDE evaluation per 02-regras-operacionais-e-runtime.md.lastUpdate according to the batch-role classification:modified in this round or reused unchanged for mandatory dependency closuremodified in this roundlastUpdate to max(UtcNow + 60s, official-corpus lastUpdate + 60s); when available, prefer a local wrapper such as Get-*KbLastUpdate.ps1 or the shared engine scripts\Get-GeneXusXpzLastUpdate.ps1 -BaselineXmlPath <xml-do-acervo> to capture that value in one atomic calllastUpdate from the official corpus XMLlastUpdate diverge → ABORTlastUpdate after every local write:lastUpdatelastUpdate must be strictly fresher than the official corpus baseline and normally use the 60-second freshness marginlastUpdate from the corpus XMLObject top-level → serialize under <Objects>Attribute top-level → serialize under <Attributes>Transaction, every attribute referenced by Level/Attribute must exist as top-level Attribute under <Attributes> when the package is meant to create or complete those attributes in the target KBDomain or any other object type under <Objects>Transaction:
<Objects> = the Transaction<Attributes> = at minimum the PK and the description/display attribute used by the Transaction<Dependencies> = only what the selected shape really requiresTransactionOrObject, when present in a comparable export, may be included as an auxiliary object in <Objects>, but it does NOT replace the mandatory top-level <Attributes> required by the TransactionNomeCurto_GUID_YYYYMMDD_nn.import_file.xmlNomeCurto must be short, human-readable, and semantically strongGUID and YYYYMMDD identify the front opening, not the package generation instantnn is only the short incremental round counter for that front, not semantic versioningNomeCurto_GUID_YYYYMMDD already has the same nn in PacotesGeradosParaImportacaoNaKbNoGenexusnn, ABORT instead of overwriting the existing filenn suggestion, but do NOT auto-increment or silently save under the suggested valueObjects count, Attributes count, included files list or summary, lastUpdate applied or preserved, generated package, superseded package when present, and risk/pending notesObjetosDaKbEmXml, package supersession that needs local traceability, explicit user request, or real need for future handoff outside the immediate conversationimport_file.xml, not only the source XML filesimport_file.xml assembly. Use scripts\Build-GeneXusImportFileEnvelope.ps1 for direct object XML inputs and a validated template package, with mandatory -AcervoPath <ObjetosDaKbEmXml> and -ModifiedObjectNames or -ModifiedObjectGuids for objects actually modified in the round; that helper clones KMW/Source/Dependencies/ObjectsIdentityMapping from the template, clones top-level Attributes from the template when no explicit -TopLevelAttributesXmlPaths were passed, embeds each object via ImportNode (which guarantees no inner <?xml ...?> is carried over), runs the deterministic collision gate (Test-XpzPackageCollision.ps1) before any write so a colliding _nn aborts the script with zero bytes materialized, checks front-vs-acervo coherence (lastUpdate and Object/@type by same guid) before serializing, and runs the envelope gate automatically before delivery; it does not cover strong global trim in this version. Use the safe wrapper scripts\New-XpzImportPackage.ps1 when the package source is a named front under ObjetosGeradosParaImportacaoNaKbNoGenexus; its 9-FD gate also blocks strong removal of inherited trailing whitespace by unique-GUID baseline and may emit informational front-textual-fidelity-info only when that baseline exists but comparable UTF-8 text reading/decoding failed, with partial protection only, not a complete whitespace/reindentation/EOL detector. Pass -TemplatePackagePath for mixed/complex packages so the front-based engine clones a comparable real envelope instead of relying on metadata-only minimal envelope, including top-level Attributes from the template when the front does not provide explicit Attribute roots. -TemplatePackagePath may point to .import_file.xml/XML or to a .xpz that contains an ExportFile XML.-TemplatePackagePath, ensure the chosen template is comparable to the current case: same KB origin, similar package nature (full vs surgical delta vs migration), and import-flow context aligned with current intent. Cloning from a non-comparable template can contaminate the new package with Dependencies and ObjectsIdentityMapping bindings from an unrelated context — that is a worse outcome than the metadata-derived minimal envelope. If a comparable template is not available, prefer the minimal envelope (omit -TemplatePackagePath) and accept the engine's envelope-minimo warning explicitly in the packaging rationale. When local evidence shows that the active import flow expects a full IDE-style ExportFile envelope, prefer a comparable IDE-exported template regardless of GeneXus major version; do not encode this as a GeneXus 16-only rule. When the parallel folder documents a known-good reference package path (e.g., in its local AGENTS.md), use that path as default candidate for -TemplatePackagePath; verify comparability before passing it.ObjetosGeradosParaImportacaoNaKbNoGenexus and PacotesGeradosParaImportacaoNaKbNoGenexus are agent-managed work areas, not user drop folders. If an example/reference/template XML appears inside the active front, including root-valid Object/Attribute XML explicitly marked as reference material, or if any unsupported XML appears there, ABORT packaging and move the reference outside the generated-objects area only with explicit user approval and traceability; do not silently ignore it.import_file.xml (string concatenation of object XMLs into the envelope) as a discouraged fallback subject to the NEVER constraint above (CONSTRAINTS): allowed only when both shared engines are demonstrably unusable AND the user has explicitly acknowledged the exception<OutputPath>.rejected.<A..Z> for forensic inspection; do NOT rename it back to the canonical *.import_file.xml to retry — fix the input and rerunscripts\Test-GeneXusImportFileEnvelope.ps1 -InputPath <package> after writing the final import_file.xml; the gate emits JSON by default. For Panel with a comparable package/object available, also pass -PanelReferencePath <template-or-object> so a confirmed level id/layout id pair is information rather than an unresolved warning. Treat não apto para prosseguir as a hard stop before delivery. Build-GeneXusImportFileEnvelope.ps1 already calls this canonical gate and passes its -TemplatePackagePath as the Panel reference; New-XpzImportPackage.ps1 performs its own internal envelope validation, so the canonical gate must still be run explicitly before delivery unless it has already been run after package assembly.Test-GeneXusImportFileEnvelope.ps1 returned apto para prosseguir, do not treat packaging as the end of the round: hand off to xpz-msbuild-import-export and execute Invoke-GeneXusXpzImport.ps1 per that skill (-StartWatcher and -MonitorLogPath mandatory). Envelope validation alone is not the final step..xpz or external package into the current front's import_file.xml without classifying each item as requested change, necessary auxiliary change, or extra unrequested change; any extra unrequested change blocks packaging until explicitly resolved with the user — do not silently absorb export bloat (platform modules and similar extras can trigger very long builds).