POC de pagamento dividido: referência rápida do tutorial

Esta página resume como é organizada a série de tutoriais de prova de conceito de pagamento fracionado. Ele mapeia cada arquivo de prompt de origem numerado para sua página publicada do Experience League, lista uma ordem de seção sugerida para os leitores e coleta notas para os autores e mantenedores.

Referência arquivo a arquivo

Criar uma POC de pagamento dividido: Ferramentas de IA e App Builder

Rótulo do Source: 00_TUTORIAL_OVERVIEW.md (visão geral conceitual; a série publicada abre com esta página.)

Finalidade: Introdução e orientação para o tutorial.

Por que é necessário: oferece aos desenvolvedores o “por que” antes do “como”. Explica o que eles vão construir, quem é o público-alvo e criticamente — o que eles devem personalizar se o site for diferente de uma instalação limpa da Luma. Also serves as the table of contents for the rest of the series.

Uso do tutorial: Abrindo seção. Define o contexto antes de qualquer etapa técnica.

POC de pagamento dividido: decisões de arquitetura e design

Propósito: explicação detalhada de cada decisão arquitetônica na PoC.

Why it’s needed: The single most common point of confusion when working with this PoC is understanding why something is in PHP versus App Builder. Sem esse contexto, os desenvolvedores tentam mover itens que não podem ser movidos (como a aplicação de crédito da loja) e falham. This document pre-empts those failures with clear reasoning.

Principais tópicos abordados:

Uso do tutorial: seção “Arquitetura” ou “Como funciona”. Pode ser ignorado por desenvolvedores experientes do Commerce, mas é essencial para os recém-chegados do App Builder.

POC de pagamento dividido: pré-requisitos e configuração de ambiente

Finalidade: Conclua a lista de verificação de pré-impressão antes que qualquer código seja gravado ou que os prompts sejam executados.

Por que é necessário: a fase de instalação tem a maior taxa de falha nos tutoriais. Este documento garante que o administrador do Commerce esteja configurado corretamente (título CQO exato, crédito de armazenamento ativado, cliente de teste tem saldo, integração criada), que o projeto do App Builder tenha Eventos de E/S e que o provedor de eventos do Commerce esteja conectado, e que o ambiente local tenha as versões certas.

Itens de ênfase:

Uso do tutorial: “Pré-requisitos” ou seção “Introdução”. Deve ser concluído interativamente — não apenas lido.

POC de pagamento dividido: referência de variáveis de ambiente

Propósito: Todas as variáveis de ambiente para todos os três componentes em um único local.

Por que é necessário: as mesmas quatro credenciais do OAuth aparecem em três arquivos diferentes com nomes de variáveis diferentes (COMMERCE_* versus COMMERCE_INTEGRATION_*). Ter uma única referência impede a depuração “por que isso não está funcionando”, em que um conjunto de credenciais tem um erro de digitação.

Componentes abrangidos:

Uso do tutorial: Barra lateral de referência ou seção “Configuração”. Também usado como um complemento para os prompts de build.

POC de pagamento dividido: prompt de IA do módulo Commerce

Propósito: Prompt completo de IA independente para gerar todo o módulo PHP Client_SplitPayment.

Por que é necessário: este é o artefato de compilação primário da IA para o lado do PHP. Ele é escrito para que um desenvolvedor sem experiência em PHP possa entregá-lo ao Cursor (com Claude) e obter um módulo de trabalho. Cada arquivo é especificado, cada contrato comportamental é definido, as notas de implementação críticas são incluídas e os comandos para habilitar o módulo posteriormente são fornecidos.

Cobertura:

Uso do tutorial: seção “Criar o módulo Commerce”. O prompt em si é o artefato — os desenvolvedores o copiam em sua ferramenta de IA e a executam.

POC de pagamento dividido: prompt da IA do App Builder orchestrator

Propósito: Concluir prompt de IA independente para gerar o aplicativo do App Builder split-payment-orchestrator.

Por que é necessário: as quatro ações do App Builder (payment-orchestrator, payment-accept, payment-decline, demo-dashboard) são o núcleo da história “o que saiu do PHP”. Esse prompt gera todos eles com especificações comportamentais completas, estrutura app.config.yaml correta e a configuração de registro do evento.

Cobertura:

Uso do tutorial: seção “Criar o aplicativo do App Builder”. Companheiro para o prompt do módulo Commerce.

POC de pagamento dividido: prompt da IA de extensão da interface do Experience Cloud

Propósito: Prompt de IA para gerar a extensão opcional SDK da interface do usuário do administrador do Experience Cloud.

Por que é necessário: O painel de demonstração no prompt do orquestrador é intencionalmente áspero; é uma prova de conceito, não uma produção. Esta seção mostra aos desenvolvedores a próxima etapa: incorporar o painel de pagamento dividido ao Commerce Admin Shell usando a interface de usuário de administração do SDK. Ele estava faltando inteiramente dos prompts originais.

Cobertura:

Uso do tutorial: seção opcional “Indo além” ou “Caminho de produção”. Pode ser ignorado se o tutorial se concentrar somente na PoC.

POC de pagamento dividido: guia de teste e verificação

Propósito: guia de teste passo a passo que cobre cada componente na ordem de verificação correta.

Por que é necessário: construir os componentes é metade do trabalho. Os desenvolvedores precisam de um caminho de verificação claro, que comece no nível mais baixo (colunas de banco de dados, pontos de extremidade REST) e vá para o fluxo completo. Os prompts originais tinham uma lista de verificação de configuração, mas nenhum fluxo de teste explícito.

Cobertura:

Uso do tutorial: seção “Teste” ou “Verificação”. Também é importante como referência para a solução de problemas.

POC de pagamento dividido: próximas etapas após a prova de conceito

Propósito: Roteiro para transformar a POC em padrões prontos para produção.

Por que é necessário: um tutorial PoC corre o risco de deixar os desenvolvedores com um “e agora?” sentimento. Este documento mapeia os avanços naturais da demonstração à produção: substituição do painel de demonstração por uma extensão do Experience Cloud, conexão de um ERP real, adição de uma API Mesh, expansão do fluxo de trabalho do App Builder e lista de verificação de implantação de produção.

Conteúdo da chave:

Uso do tutorial: seção de fechamento “Próximas etapas”. Também útil como iniciador de conversação para definir o escopo de um projeto real.

Seções de tutorial sugeridas

Com base nesses arquivos, uma estrutura típica para leitores é:

Observações importantes para autores tutoriais

Na premissa do tema Luma: Cada prompt de compilação gera um código para uma instalação limpa do Luma. O tutorial deve indicar isso claramente na parte superior — os desenvolvedores com check-outs personalizados precisarão adaptar os caminhos de injeção do LayoutProcessorPlugin e possivelmente a configuração RequireJS. A introdução da série e os prompts de build incluem chamadas de personalização para isso.

No módulo PHP: o tutorial explicitamente não fornece o código PHP como um download de copiar e colar. O prompt de IA gera. Isso é intencional — ensina o padrão de uso da IA para criar extensões do Commerce, não apenas copiar e colar chapas padrão. No entanto, o código gerado quando solicitado em um ambiente limpo deve corresponder exatamente ao código de trabalho no app/code/Client/SplitPayment/.

No limite de $100: Este é um valor PoC embutido em código. O tutorial deve observar que as lojas reais desejarão configurar isso por meio da configuração de administração do Commerce, em vez de uma constante de tempo de compilação.

Dependência de crédito da loja: O fluxo de pagamento dividido conforme compilado requer Magento_CustomerBalance (o módulo de crédito da loja nativa).

Related split payment POC resources