Do App Builder AI a um Aplicativo Angular Funcional com o Ignite UI MCP

O GameForge é um aplicativo de montagem de PCs: uma loja onde os clientes configuram um PC para jogos ou para estação de trabalho, e um Backoffice onde os administradores gerenciam o catálogo, o estoque, os preços e os pedidos. Nós o construímos em duas iterações.

Na primeira iteração, o App Builder AI gera a interface a partir de um projeto em branco. Nós o exportamos para Angular, e o Claude Code faz as páginas geradas funcionarem, com a orientação do Ignite UI MCP, do Ignite UI Theming MCP e das Ignite UI skills.

Na segunda iteração, um requisito de Admin / Backoffice chega depois que o código já evoluiu. Nós o projetamos novamente no App Builder, inspecionamos o delta do Git e pedimos ao Claude que integre apenas o que o aplicativo evoluído precisa.

O Que Construímos

• Loja: builds e presets em destaque, um PC Builder com oito slots, um catálogo de 24 peças com busca e filtros, substituição de peças, consumo de energia, compatibilidade e preços em tempo real, configurações salvas e uma página Build Summary com checkout.
• Backoffice: login de administrador, métricas no painel, gerenciamento de pedidos e status, e gerenciamento de catálogo, estoque e preços que a loja reflete imediatamente.

Ferramenta	Função neste fluxo de trabalho
App Builder AI	Gera e refina a interface a partir de prompts e depois a exporta como um projeto Angular
Claude Code (Opus 5.5)	Implementa dados, estado e comportamento no projeto exportado
Ignite UI MCP (igniteui-cli)	Documentação de componentes e referência de API enquanto o Claude trabalha
Ignite UI Theming MCP (igniteui-theming)	Tokens de tema para cores de status e estados
Ignite UI skills	Instaladas no projeto exportado e utilizadas

---

Iteração 1: De um Aplicativo em Branco a uma Loja Funcional

Cinco prompts do App Builder geram e refinam a interface e, em seguida, cinco etapas do Claude Code a fazem funcionar.

Gere o GameForge com o App Builder AI

Comece com um Projeto em Branco e um Único Prompt Detalhado

O projeto começa vazio. O primeiro prompt descreve o aplicativo inteiro, em ordem: seu propósito, cada página e seu conteúdo, os dados, o sistema visual e uma regra para manter as páginas consistentes.

Create a premium PC building application called GameForge with exactly three pages: Home, PC Builder, and Components.

Design GameForge as a modern high-end hardware configurator for people building custom gaming and workstation PCs. The experience should feel technical, precise and futuristic, but clean and restrained rather than full of RGB effects.

On the Home page, create a strong editorial-style hero with the GameForge brand, a bold "Build Your PC" call to action, a large premium gaming PC image, and a small set of performance highlights such as Gaming, Creator and Enthusiast. Below it, show several featured builds with large imagery, names, short specifications, prices and clear actions, followed by a compact "How It Works" section explaining the build process.

Make the PC Builder page the visual centerpiece of the application. Use a structured configurator layout with hardware categories for CPU, GPU, Motherboard, RAM, Storage, Cooling, Power Supply and Case. Show realistic sample selected parts with product imagery, model names, prices and the most important specifications. Include a visually distinct build summary area showing the selected components, a sample estimated total, a compatibility status and a clear "Review Build" action. Make selected and unselected component states easy to distinguish.

The Components page should feel like a premium hardware catalog rather than a generic product list. Include search and useful filters, and present realistic CPUs, GPUs, memory, storage and other parts using polished cards or a clean data-rich layout with product images, prices, brands, performance tiers and key specifications.

Use realistic generated hardware data throughout the app.

Use a dark graphite visual system with layered charcoal surfaces, crisp light typography and a restrained electric cyan or blue accent. Use subtle gradients, fine borders, compact technical labels, specification badges and large high-quality hardware imagery. Keep generous spacing and strong hierarchy. Avoid excessive neon, RGB gaming clichés, clutter and generic ecommerce styling.

Keep the navigation, typography, cards, buttons, spacing and visual language consistent across all three pages. The final result should feel like a polished product configurator that could realistically be used as the starting point for a working PC builder.

Revise o Aplicativo Gerado

O App Builder gerou três páginas, seus dados e um tema:

• Home: um hero com destaques por nível, builds em destaque com pontuações de benchmark e preços, e um guia de montagem. Build Your PC abre o PC Builder.
• PC Builder: um configurador de oito slots com um painel de telemetria da build, badges de compatibilidade e potência por slot, e uma caixa de diálogo Review Build.
• Components: um catálogo de hardware com busca, filtros de soquete e de nível de desempenho, e uma caixa de diálogo de especificações.
• Dados: três tabelas - FeaturedBuild, BuilderSlot e HardwareComponent - que alimentam as três páginas.
• Tema: “GameForge Graphite Precision”, com superfícies em tons de carvão, a fonte Space Grotesk, detalhes em ciano e uma barra de navegação superior compartilhada.

Créditos: 27 (27 de 100 usados).

Refine o Layout do PC Builder com uma Edição Focada

Os próximos prompts alteram uma parte do aplicativo por vez, em vez de gerá-lo novamente. Os cards de hardware do PC Builder estavam empilhados em uma única coluna, então este prompt os reorganiza e diz o que não deve mudar:

Arrange the hardware cards inside this container into a two-column grid.

Keep every existing card and all of its current content unchanged. Use two equal-width columns with consistent horizontal and vertical spacing between the cards.

Do not change the Build Telemetry or Custom Build Invoice panels on the right, and do not change anything outside this selected container.

O contêiner selecionado se tornou um grid de duas colunas. Os cards mantiveram seu conteúdo, e agora mais slots cabem na tela sem rolagem.

Créditos: 5 (32 de 100 usados).

Adicione uma Página Build Summary

Os clientes precisam de uma página para revisar uma configuração finalizada antes de fazer o pedido:

Add a new Build Summary page that matches the existing GameForge application.

This page should present the completed PC configuration in a clean summary layout. Show the selected CPU, GPU, Motherboard, RAM, Storage, Cooling, Power Supply, and Case with names, prices, and short key specifications.

Include a pricing summary area with subtotal and estimated total, a compatibility status section, and clear actions such as "Back to Builder" and "Place Order".

Keep the same dark GameForge visual style, cyan accents, and clean technical look so the page feels like a natural part of the app.

O App Builder adicionou a página e um botão de navegação para ela, e aplicou às novas partes as cores correspondentes sem alterar as cores de mais nada. A página tem um cabeçalho de telemetria da build, a lista de hardware, verificações de compatibilidade e de folga, e um detalhamento de preços com Back to Builder e Place Order. O Claude a transforma no checkout em funcionamento na Etapa 5.

Créditos: 13 (45 de 100 usados).

Mude o Estilo de Todo o Aplicativo

Um prompt de duas frases leva o aplicativo inteiro do tema escuro para um tema claro:

Restyle the entire GameForge application with a light high-tech design.

Change the app from the current dark look to a clean bright visual style with white and soft silver surfaces, crisp dark text, subtle dividers, and refined cyan or electric blue accents.

O App Builder criou uma paleta “GameForge Cryo Tech” e a aplicou a contêineres, cabeçalhos, bordas, badges e controles na Master View e em todas as quatro páginas.

Créditos: 7 (52 de 100 usados).

Adicione um Rodapé Global na Master View

Todas as páginas compartilham a Master View, então o rodapé fica nela:

Add a footer to the master view below the navigation and page content so it appears on every page.

Create a clean high-tech footer for GameForge with the GameForge name, a short tagline, links to Home, PC Builder, Components, and Build Summary, plus a small support/contact area.

Add a bottom line with "© 2026 GameForge. All rights reserved."

Keep it minimal, elegant, and consistent with the current light premium design.

O App Builder adicionou o rodapé com a marca, os links de navegação e os detalhes de suporte. Ele informou o resultado como “Partly there”: o link Direct Architecture Desk está na página, mas ainda não está conectado a nada.

Créditos: 11 (63 de 100 usados).

Créditos do App Builder na Iteração 1

Os cinco prompts usaram 63 dos 100 créditos: 27 para a geração completa e de 5 a 13 para cada alteração posterior. Cada tipo de solicitação tem um preço fixo, mais um adicional por páginas, fontes de dados e imagens geradas. A imagem abaixo é um resumo ilustrativo desses números, não uma tela do App Builder.

Agora o GameForge parece pronto, mas os dados são de exemplo e a maioria das ações são placeholders. A próxima etapa o leva para o código.

Exporte para Angular

O App Builder exporta o projeto como um aplicativo Angular. A transferência leva apenas alguns cliques.

Abra o Projeto e Verifique a Configuração de IA

Descompacte o projeto exportado, abra-o no VS Code e instale as dependências:

npm install

A exportação já inclui a configuração de IA, então o Claude pode começar sem nenhuma configuração adicional:

• O .mcp.json configura três servidores MCP: angular-cli, igniteui-cli e igniteui-theming. Este fluxo de trabalho usa os dois servidores do Ignite UI.
• As Ignite UI skills estão instaladas: igniteui-angular-components, igniteui-angular-figma-to-app, igniteui-angular-generate-from-image-design, igniteui-angular-grids e igniteui-angular-theming.

Torne o GameForge Funcional com o Claude Code e o Ignite UI MCP

O design do App Builder permanece como está. O Claude Code constrói o comportamento por trás dele em cinco etapas.

Como Cada Prompt É Escrito e Verificado

Cada prompt diz ao Claude para manter o design existente, nomeia os componentes Ignite UI envolvidos e direciona o Claude ao Ignite UI MCP para consultar suas APIs Angular. Após cada etapa, o Claude executou o build, o lint e os testes unitários e, em seguida, percorreu os fluxos alterados no Chromium com o Playwright. Todas as etapas passaram no build e no lint sem erros no console.

Etapa 1: Dados Reais e Estado de Build Compartilhado

O primeiro prompt substitui os dados de exemplo por um catálogo realista e dá às quatro páginas um único estado de build compartilhado:

You are working on an Angular application called GameForge PC Builder.

This app was created in App Builder with AI and then exported. We are using it for a technical blog showing how we continue from the generated App Builder UI with Claude Code, Ignite UI MCP, Ignite UI Theming MCP, and the installed Ignite UI Claude skills to turn it into a fully working application.

The current GameForge design is already finished and should be preserved. Do not redesign the app.

The project has four main pages:
- Home
- PC Builder
- Components
- Build Summary

First inspect the existing project so you understand its generated models, services, data structures, and bindings.

Then:

- Replace the App Builder placeholder data with realistic hardware data for CPU, GPU, Motherboard, RAM, Storage, Cooling, PSU, and Case.
- Use roughly 3 parts per category.
- Include the properties needed for pricing, power, and compatibility.
- Create 3 realistic featured GameForge build presets.
- Create a shared signal-based BuildStateService that owns the selected part for each hardware slot.
- Expose selected parts, filled slot count, and subtotal as shared/computed state.
- Make Home load a selected preset into the builder.
- Make PC Builder, Components, and Build Summary use the same hardware data and shared build state.
- Preserve the existing App Builder templates and styling.

Use the Ignite UI MCP when working with or verifying Ignite UI components, and use the relevant installed Ignite UI Claude skills where useful.

O Claude adicionou 24 peças, 3 para cada uma das 8 categorias, cada uma com preço, consumo de energia, pontuação de benchmark e os campos de que as verificações de compatibilidade precisam, como soquete, tipo de memória, formato, comprimento da GPU e folgas do gabinete. Ele criou três presets, cada um com o preço igual à soma de suas peças:

Preset	Nível	Preço
Apex Titan	Flagship	$4,652
Vanguard	Enthusiast	$2,542
Raptor	Mainstream	$2,002

Um novo BuildStateService baseado em signals mantém a peça de cada slot e expõe as peças selecionadas, a contagem de slots preenchidos, o subtotal e o preset ativo. A Home carrega um preset nele, e as outras três páginas leem a partir dele.

Os novos modelos estendem os gerados, então os templates do App Builder mantiveram suas vinculações. O Claude removeu três serviços gerados e seus dados de placeholder quando nada mais os utilizava, e migrou os componentes de página para OnPush, inject() e signals.

Os dados também incluem conflitos intencionais para a Etapa 4 detectar: uma CPU e uma placa-mãe Intel ao lado das AMD, e um cooler Noctua NH-D15 G2 de 168 mm que não cabe no gabinete NZXT H6 Flow de 163 mm.

Antes de vincular o badge, a barra de progresso linear e o Grid Lite, o Claude verificou suas APIs por meio do Ignite UI MCP. Ele não chamou o Theming MCP, porque nenhum estilo foi alterado.

Verificações: 12 testes unitários aprovados, 3 chamadas ao MCP.

Etapa 2: Filtros do Catálogo Funcionando

Em seguida, a página Components ganha filtros funcionais. O prompt nomeia cada componente Ignite UI que o Claude deve consultar:

Make the existing Components page fully functional without changing its current design.

Use the Ignite UI MCP as the source of truth for the Angular APIs of the existing input, igx-select, igx-chip, dialog and snackbar components. Use the relevant installed Ignite UI Claude skills where useful.

Implement:

- Working search by part name, manufacturer and relevant specifications.
- Working Component Category filter.
- Working Performance Tier filter.
- Working Socket / Form Factor filter.
- Working Sort By.
- Make the existing quick-filter chips selectable and functional.
- Make Reset Filters clear all active filters and restore the full catalog.
- Update the visible component count automatically.
- Show a clear empty state when no parts match.

Use signals/computed state for the filtering and preserve the existing cards, layout, styling and hardware data.

Do not redesign the page or replace existing Ignite UI components unnecessarily.

A busca agora encontra correspondências por nome, fabricante, categoria, nível, soquete ou formato, e especificações. Os dropdowns igx-select estão vinculados a signals, os chips de filtro rápido podem ser combinados (Processors + GPUs mostra 6 peças), a contagem “N Components Verified” é atualizada em tempo real e anunciada aos leitores de tela, e um estado vazio com seu próprio botão Reset Filters aparece quando nada corresponde.

A referência de API do Ignite UI MCP retornou nomes antigos para o evento do chip (onSelection) e para os métodos do snackbar (show/hide). O Claude os conferiu com o guia de chips do MCP e com as tipagens instaladas, usou selectedChanging, [selected], open() e close() no lugar deles, e salvou a descoberta na memória para as etapas seguintes.

O Claude também alterou coisas que o prompt não pediu: as mensagens do snackbar, o botão Review Rig, a caixa de diálogo Benchmarks e Add to Custom Build. As alterações foram úteis, mas se sobrepuseram à próxima etapa, por isso os prompts seguintes terminam com uma frase que limita o escopo.

Verificações: 18 testes unitários aprovados, 5 chamadas ao MCP.

Etapa 3: Substitua uma Peça a Partir do PC Builder

Este prompt adiciona a substituição de peças, para que um cliente possa trocar uma peça da build atual a partir do PC Builder. Sua última frase é o limite de escopo:

Connect PC Builder and Components so users can replace a specific hardware part in their current build.

Preserve the existing design and the filtering functionality that already works.

Use the Ignite UI MCP when working with or verifying the relevant Angular component APIs, and use the relevant installed Ignite UI Claude skills where useful.

Implement:

- Make each existing Change Part action in PC Builder open `/components?slot=<slot>` for the correct hardware slot.
- On Components, read the `slot` query parameter and automatically filter the catalog to that hardware category.
- Clearly show which current part is being replaced.
- Mark the part that is already selected in the build.
- Make Select for Rig replace the part in that exact slot through BuildStateService.
- After replacement, show the existing confirmation snackbar with the old and new part names.
- Make Review Rig return to PC Builder, where the changed part and subtotal are immediately reflected.
- Make direct navigation to Components without a slot continue to behave as the normal full catalog.

Do not redesign anything and do not rework the existing filters, dialogs or snackbar behavior unless required for this flow.

Cada botão Change Part agora abre a página Components filtrada pelo seu slot, por exemplo /components?slot=gpu. Um banner mostra a peça que está sendo substituída, a peça atual é marcada como “In Your Rig”, e Select for Rig troca a peça naquele slot. O snackbar confirma a troca (“RTX 5080 replaced RTX 5090 in the GPU slot.”), e Review Rig retorna ao PC Builder, onde o subtotal caiu de $4,652 para $3,652. Abrir Components sem um slot continua mostrando o catálogo completo.

O banner usava inicialmente o tom primário mais claro do tema, mas o texto da legenda não tinha contraste suficiente sobre ele. O Claude mudou para uma tonalidade obtida da mistura das cores primária e de superfície.

Verificações: 21 testes unitários aprovados, 1 chamada ao MCP.

Etapa 4: Energia, Compatibilidade e Preços em Tempo Real

O PC Builder ainda mostra uma telemetria fixa no código. Este prompt a substitui por cálculos em tempo real e incorpora o Ignite UI Theming MCP para os estados de sucesso, aviso e erro:

Make the existing PC Builder telemetry, compatibility and pricing fully functional using the shared BuildStateService.

Preserve the current GameForge design and existing components.

Use the Ignite UI MCP as the source of truth for the Angular APIs of the existing IgxBadge, IgxLinearProgressBar, dialog and snackbar components.

Use the Ignite UI Theming MCP with platform "angular" to inspect the correct theme tokens and visual states for success, warning and error. Use the relevant installed Ignite UI component and theming skills where useful.

Implement live calculations for:

- total estimated power draw;
- PSU capacity, utilisation and remaining headroom;
- parts subtotal and build total;
- CPU and motherboard socket compatibility;
- RAM and motherboard compatibility;
- motherboard and case form factor compatibility;
- GPU length and case clearance;
- cooling and case compatibility;
- PSU capacity;
- whether all required hardware slots are populated.

Replace the existing hard-coded PC Builder values with these calculations.

Make the existing badges and progress bar react to the current build with clear success, warning and failure states based on the Ignite UI MCP and Theming MCP guidance.

Update the existing Review Build dialog so it shows the real 8 selected parts, current pricing, power information and any compatibility issues.

Make the existing assembly/testing options affect the calculated total.

Make Save Configuration actually persist the current build and restore it after a page reload.

Keep the implementation focused on the existing UI and do not redesign the page.

O PC Builder agora calcula estes valores a partir da build atual:

• Energia: o preset Apex Titan consome 825 W em uma PSU de 1200 W, o que deixa “375W (31% buffer)”. Até 80% de carga é sucesso, de 80-100% é aviso e acima de 100% é erro, definidos pelos próprios estados da barra de progresso.
• Compatibilidade: oito verificações cobrem slots vazios, soquete da CPU, tipo de RAM, tamanho da placa-mãe, comprimento da GPU, encaixe e montagem do cooler, e capacidade da PSU. Uma verificação que depende de um slot vazio aparece como pendente em vez de falhar.
• Preços: o subtotal, o nível de montagem e a opção de ajuste térmico determinam o total estimado.
• Review Build: a caixa de diálogo lista as peças reais, a energia, os preços e os problemas. Proceed to Checkout permanece desabilitado enquanto houver conflitos ou slots vazios.
• Save Configuration: a build é armazenada no navegador e restaurada ao recarregar a página. Entradas salvas que não correspondem mais ao catálogo são ignoradas.

As cores de aviso e erro usam os tokens warn e error do tema, encontrados por meio do Theming MCP, e passam no critério de contraste WCAG AA sobre o painel. Os preços das opções (Precision Stress-Testing $49, Extreme Benchmarking & Burn-in $149, Precision Thermal Tuning $79) são valores de demonstração que o Claude escolheu a partir dos textos existentes.

Verificações: 36 testes unitários aprovados, 7 chamadas ao MCP (2 ao Ignite UI MCP, 5 ao Theming MCP).

Etapa 5: Build Summary e Checkout

A Build Summary é a última página com valores de placeholder. Este prompt a transforma em um checkout e substitui o web component Grid Lite bruto pelo componente Angular:

Make the existing Build Summary page fully functional and synchronize it with the shared GameForge build state.

Preserve the current design and reuse the existing Ignite UI components.

Use the Ignite UI MCP as the source of truth for the Angular APIs of:
- IgxGridLiteComponent
- grid data binding, columns, sorting, filtering and cell templates
- IgxBadge
- IgxDialog
- IgxSelect
- IgxSnackbar

Use the igniteui-angular-grids and igniteui-angular-components skills where useful. Use the Ignite UI Theming MCP with platform "angular" only if status styling needs theme/token work.

Implement:

- Make Build Summary show the exact same selected parts, slot count, power, compatibility and pricing as PC Builder.
- Remove the remaining hard-coded summary values.
- Replace the current raw Grid Lite web component with the Angular IgxGridLiteComponent.
- Populate the grid from the real compatibility checks and use clear columns with pass/warning/fail status badges.
- Keep sorting and filtering working.
- Make shipping and payment selections functional.
- Calculate shipping, tax, payment discount and final total live.
- Use the existing checkout dialog with proper validation.
- Prevent ordering when the build is incomplete or has compatibility failures.
- Make Confirm & Place Order create a simple order id/snapshot, close the dialog, show the existing snackbar, and display an Order Confirmed state.
- Add a Start New Build action that resets the current build.
- Make Proceed to Checkout from PC Builder open Build Summary with the same current build.

Do not redesign the page or replace existing components unnecessarily.

A Build Summary agora mostra a mesma build que o PC Builder. Para o Apex Titan, os $4,701 do PC Builder equivalem aos $4,652 em hardware do resumo mais $49 de testes.

• Grid de compatibilidade: o web component igc-grid-lite é substituído pelo IgxGridLiteComponent do Angular, que mostra as 8 verificações com uma coluna de status com igx-badge. A ordenação e a filtragem funcionam em todas as colunas.
• Checkout: o frete e o pagamento usam os componentes igx-select existentes em um formulário reativo. O frete, um desconto para transferência bancária, os impostos e o total são atualizados em tempo real (taxas de demonstração).
• Pedidos: Place Order e Confirm ficam desabilitados para uma build incompleta ou com falha de compatibilidade, com o motivo exibido. Confirm & Place Order cria um ID de pedido como GF-MUY3L5KH-2QO4 e um estado Order Confirmed, e Start New Build limpa a build.

A skill igniteui-angular-grids orientou a configuração, as importações, os templates de célula e o wrapper Angular do Grid Lite. As novas regras de preço reproduzem exatamente o total original da fatura do App Builder, de $3,086.37. Um teste unitário também detectou um erro de arredondamento de um centavo: 1.5% de $1,079 resultava em $16.18 em vez de $16.19.

Verificações: 45 testes unitários aprovados, 4 chamadas ao MCP.

A Iteração 1 em Números

É aqui que o fluxo de trabalho começa a compensar. Cinco prompts do App Builder e 63 créditos levaram o GameForge de um projeto em branco a um design refinado de quatro páginas. Em seguida, cinco etapas focadas do Claude Code transformaram o design em uma loja funcional: um catálogo real, estado de build compartilhado, filtragem, substituição de peças, verificações de energia e compatibilidade em tempo real, preços, configurações salvas e checkout. No final, 45 testes unitários são aprovados, e as alterações de cada etapa foram verificadas no navegador.

Ao longo das cinco etapas, o Claude fez 20 chamadas ao MCP (15 ao Ignite UI MCP, 5 ao Theming MCP) e também usou as Ignite UI skills. As chamadas abrangeram APIs de componentes, o Grid Lite, os badges e a barra de progresso que reagem ao estado da build, e os tokens de tema por trás das cores de status. Cada resposta chegou ao agente enquanto ele escrevia o código que precisava dela, de modo que o conhecimento sobre os componentes se transformou diretamente em recursos funcionais.

Janela de contexto ao final da sessão (Claude Code, Opus 5.5, 1M tokens):

Categoria	Tokens	Participação
Contexto usado	425.2k	43%
Mensagens	383.7k	38.4%
Ferramentas MCP	6.0k	0.6%
Instruções do servidor MCP	2.4k	0.2%
Skills	8.2k	0.8%
Livre	541.8k	54.2%

Essa ajuda ocupou muito pouco espaço: as ferramentas MCP e as instruções do servidor usaram 8.4k tokens, menos de 1% da janela. A tabela é um retrato da janela de contexto, e não o total de tokens consumidos na sessão.

A Iteração 1 termina com um aplicativo Angular completo e funcional. Dez prompts levaram o GameForge de uma ideia a uma loja testada: cinco no App Builder para a interface e cinco no Claude Code com o Ignite UI MCP para o comportamento.

---

Iteração 2: Adicionando um Admin Backoffice

Ao final da Iteração 1, o GameForge funciona: os clientes podem configurar uma build, verificar a compatibilidade e fazer um pedido. Projetos reais raramente param nesse ponto. Novos requisitos chegam depois que a primeira versão está pronta, os designs mudam, e novas funcionalidades precisam se encaixar em um código que já foi muito além do que foi gerado inicialmente.

Simulamos essa situação de propósito. O novo requisito é uma experiência de Admin / Backoffice para gerenciar componentes, preços, estoque e disponibilidade, e pedidos de clientes.

Voltamos ao App Builder para projetar as novas telas e, em seguida, usamos apenas as alterações do App Builder como entrada para o aplicativo Angular que o Claude já construiu. O Claude Code, com os servidores Ignite UI MCP e as skills, integra a nova funcionalidade à arquitetura existente sem sobrescrever o trabalho da Iteração 1.

Prepare-se para a Próxima Iteração

Antes de começar qualquer trabalho no Admin, as duas versões do projeto vão para o GitHub.

Publique o Projeto do Claude no GitHub

O projeto Angular, com todo o trabalho da Iteração 1, vai para seu próprio repositório. Ele continua sendo o projeto principal e a fonte da verdade.

Publique a Linha de Base do App Builder

O projeto do App Builder vai para um repositório separado antes que qualquer nova alteração seja feita no App Builder.

O App Builder publica o projeto como um Pull Request para a main (aqui, o Pull Request #1), e esse Pull Request é mesclado antes de qualquer trabalho de Admin começar. Com a linha de base na main, tudo o que o App Builder gerar para o requisito de Admin aparece como um diff limpo em relação a ela.

Um Novo Requisito: Admin Backoffice

Os administradores precisam de uma área para gerenciar o catálogo, o estoque, os preços e os pedidos dos clientes. No App Builder, isso significa uma entrada Admin na navegação, uma página Admin Login e uma página Backoffice. O aplicativo Angular mudou muito desde a exportação, então o projeto atualizado do App Builder não é mesclado a ele. Em vez disso:

1. Adicione as páginas de Admin no projeto do App Builder.
2. Publique a atualização em um novo branch com um Pull Request.
3. Compare o branch com a linha de base no GitHub para ver o delta exato.
4. No projeto principal, busque os dois estados do App Builder e inspecione o delta com o Git.
5. Deixe o Claude Code integrar apenas as alterações relacionadas ao Admin, sem sobrescrever a funcionalidade existente.
6. Conecte a nova interface de Admin aos dados, pedidos e estado existentes.

Construa a Experiência de Admin no App Builder

A segunda iteração começa com 37 créditos restantes e usa três prompts.

Adicione a Entrada Admin à Navegação

Add a new Admin entry at the far right of the existing top navigation bar.

Use a clear admin-style icon together with the label "Admin".

Keep it visually consistent with the current GameForge navigation and overall light high-tech design.

When clicked, it should navigate to a new page called "Admin Login".

O App Builder adicionou um botão Admin com um ícone de administrador na extremidade direita da navegação da Master View. Como ele está no cabeçalho compartilhado, aparece em todas as páginas e inicia o fluxo do Backoffice.

Créditos: 5 (68 de 100 usados).

Gere a Página Admin Login

Add a new page called "Admin Login".

Create a clean, modern login page for the GameForge backoffice that matches the existing light high-tech design.

Use the same container-based layout approach as the rest of the application so the page feels fully consistent with the existing structure, spacing, and alignment.

Place the login content inside a centered main container with a focused inner login panel.

Include:
- GameForge / Backoffice branding
- "Admin Login" title
- short subtitle explaining that this area is for administrators
- Email field
- Password field
- prominent Sign In button
- secondary Back to Store action

Keep the page simple, polished, and visually consistent with the rest of the GameForge application.

O App Builder criou a página Admin Login com um layout de autenticação centralizado no tema claro do GameForge, incluindo os campos de login e uma ação Back to Store, e conectou a entrada Admin a ela.

Créditos: 11 (79 de 100 usados).

Gere a Página Admin Backoffice

Add a new page called "Admin Backoffice".

Create a polished, modern administration dashboard for managing the entire GameForge application.

The page should feel like a real backoffice product, not just a regular content page. It should be easy to scan, easy to operate, and visually consistent with the existing GameForge light high-tech design.

Use the same container-based layout approach, spacing, cards, typography, borders, and overall visual language as the rest of the application.

Structure the page around one clear main admin workspace with these areas:

1. Admin Overview
Create a compact dashboard header and summary cards for:
- Total Orders
- Pending Orders
- Revenue
- Low Stock Components

2. Orders Management
Add a clear, data-rich management section where administrators can quickly review and manage customer orders.

Show:
- Order ID
- Customer
- Date
- Total
- Payment
- Status
- Actions

Use clear status badges and make each order easy to review or update.

3. Components Management
Add a dedicated hardware management section for maintaining the PC component catalog.

Show:
- Component image
- Component name
- Category
- Price
- Stock
- Availability
- Actions

Include prominent actions for:
- Add Component
- Edit Component
- Delete Component
- Update price
- Update stock
- Change availability

Make the page feel operational and practical, with strong hierarchy, clear actions, and well-separated management areas.

The final result should look like a professional GameForge admin dashboard from which an administrator could manage the store, hardware catalog, inventory, and customer orders.

O App Builder criou o painel do Backoffice com métricas de visão geral, Orders Management, Components Management e controles de inventário, no mesmo estilo visual do restante do aplicativo. A integração posterior se baseia nessa estrutura.

Créditos: 14 (93 de 100 usados). A experiência de Admin usou 30 dos 37 créditos restantes.

Publique a Atualização em um Branch e Compare no GitHub

O projeto atualizado do App Builder vai para um branch separado com um Pull Request. O GitHub o compara com a linha de base e mostra exatamente o que o App Builder adicionou ou alterou para o requisito de Admin.

Traga o Delta do Admin para o Projeto Principal

Os dois projetos permanecem em repositórios separados, e apenas as partes úteis do delta são trazidas.

Inspecione o Delta com o Git

No projeto principal, estes comandos:

1. Criam um branch de integração, ganastasov/admin-backoffice-integration, a partir de uma main atualizada.
2. Adicionam o repositório do App Builder como um segundo remote, appbuilder.
3. Buscam a linha de base (appbuilder/main) e o Pull Request do Admin (#2) como um branch local, appbuilder-admin.
4. Mostram quais arquivos mudaram entre os dois estados do App Builder, com um resumo das alterações por arquivo.

git checkout main
git pull origin main
git checkout -b ganastasov/admin-backoffice-integration

git remote add appbuilder https://github.com/georgianastasov/gameforge-appbuilder.git
git remote -v

git fetch appbuilder main
git fetch appbuilder pull/2/head:appbuilder-admin

git diff --name-status appbuilder/main..appbuilder-admin
git diff --stat appbuilder/main..appbuilder-admin

Estes comandos foram executados enquanto o Pull Request do Admin (#2) ainda estava aberto. Desde então ele foi mesclado, então a appbuilder/main agora inclui as alterações do Admin e não serve mais como linha de base. Para repetir a comparação depois do merge, busque o Pull Request da linha de base (pull/1/head) e compare com ele.

Nada do App Builder é mesclado no projeto principal. Um merge traria o código gerado de volta por cima do aplicativo evoluído, incluindo os serviços removidos na Etapa 1. Inspecionar o delta mantém o projeto principal como a fonte da verdade.

Integre a Experiência de Admin

Um único prompt de implementação resolve as decisões em aberto e solicita a integração:

The analysis looks good. Proceed with the integration.

Use these decisions:

- Add Component should support the full hardware data required by the existing compatibility system. Make the additional specification fields category-aware where appropriate so an admin is not presented with irrelevant fields.
- Add a Customer Name field to the existing checkout flow so newly placed orders can display a real customer name in the Admin Backoffice.
- Use one simple demo admin credential for this application. This is demo client-side authentication, not production security.
- Inventory must affect the storefront. Admin stock and availability changes should be reflected in the customer-facing Components / PC Builder experience.

Implement the Admin experience using the current application as the source of truth.

Use the App Builder delta as the visual/design source for:
- Admin navigation entry;
- Admin Login;
- Admin Backoffice layout and styling.

Do not copy the generated placeholder services, static data, or duplicate hardware model architecture.

Implement the integration properly using the existing application architecture and conventions.

The final flow should support:

- Admin login and guarded Backoffice access.
- Admin logout/session handling.
- Real overview KPIs derived from application state.
- Order history containing seeded demo orders and newly placed customer orders.
- Customer name, payment status, and fulfillment status.
- Admin order status management.
- Inventory management per hardware part.
- Stock and availability updates.
- Hardware price editing.
- Adding new hardware components with the specifications required by the compatibility system.
- Discontinuing/removing components safely without breaking existing presets or saved builds.
- Admin catalog changes reflected in the customer storefront.
- Admin inventory changes reflected in the customer storefront.
- Existing PC Builder, compatibility, pricing, saved builds, Build Summary, and checkout behaviour must continue to work.

Follow the current project conventions:
- signals where appropriate;
- `inject()`;
- `ChangeDetectionStrategy.OnPush`;
- reactive forms;
- lazy-loaded admin routes;
- existing Ignite UI patterns and components.

Use Ignite UI MCP and the installed Ignite UI skills when they are useful for component APIs, grids, dialogs, forms, exporters, or other Ignite UI implementation details. Validate any MCP information against the installed project version when necessary.

Preserve the visual design generated by App Builder as closely as practical while adapting its behaviour to the current architecture.

Add or update tests for the new functionality and run the existing test suite, build, and lint checks.

After implementation, report:
- files added or changed;
- how the App Builder delta was adapted;
- how the new Admin state connects to the existing storefront;
- tests/build/lint results;
- Ignite UI MCP or skill usage during this implementation.

O Claude aproveitou o HTML, o SCSS, o layout, os ícones e a estrutura visual do App Builder. Ele não copiou os serviços de placeholder gerados, os modelos duplicados nem os dados estáticos, e reescreveu a lógica gerada seguindo as convenções do projeto. Além do login, do painel e do gerenciamento de pedidos, a integração adiciona campos de especificação específicos por categoria para novos componentes, histórico de pedidos persistente e Discontinue / Restore em vez da exclusão de peças.

Conecte a Loja e o Backoffice

O Backoffice e a loja compartilham o mesmo estado, então as alterações fluem nos dois sentidos:

• Edições de preço atualizam o PC Builder, a Build Summary, os preços dos presets na Home e a página Components.
• Novos componentes aparecem na loja imediatamente.
• Componentes descontinuados ficam ocultos para novas seleções, mas permanecem nas builds existentes, nos presets e nos pedidos anteriores.
• O estoque e a disponibilidade controlam o que os clientes podem selecionar, e uma peça indisponível na build bloqueia o checkout e indica a peça a ser substituída.
• O checkout agora pede um Customer Name, reduz o inventário e cria um pedido no Backoffice.

Verifique o Fluxo Completo

O cenário completo foi testado no Chromium:

1. Abrir o Backoffice redireciona para o Admin Login.
2. Credenciais inválidas exibem um erro.
3. O administrador faz login.
4. Uma nova RTX 5070 Ti é adicionada.
5. O preço da RTX 5090 é alterado para $1,899 e seu estoque é definido como 0.
6. A loja mostra imediatamente o novo preço e “Out of Stock”.
7. A Build Summary bloqueia o checkout porque a RTX 5090 selecionada está indisponível.
8. O componente é reabastecido.
9. Um cliente chamado “Jordan Lee” conclui o checkout.
10. O novo pedido aparece no topo do grid de pedidos do Admin Backoffice.
11. Sign Out retorna à Home.

O fluxo foi executado sem erros no console, o lint está limpo e o build de produção é concluído com sucesso.

A Iteração 2 em Números

A segunda iteração mostra que o fluxo de trabalho continua funcionando depois que o projeto evoluiu. Mais três prompts do App Builder e 30 créditos projetaram uma experiência completa de Admin / Backoffice: uma entrada de navegação, uma página de login e um painel para pedidos, componentes e inventário. Em seguida, o delta do Git levou esse design para um aplicativo que havia mudado muito desde a exportação, sem sobrescrever nada do trabalho da Iteração 1.

Métrica	Iteração 2
Créditos do App Builder	30 (93 de 100 nas duas iterações)
Testes unitários	45 antes, 105 / 105 depois (+60)
Chamadas ao Ignite UI MCP	5
Chamadas ao Ignite UI Theming MCP	2
Total de chamadas aos Ignite UI MCP	7
Skill usada	igniteui-angular-grids

O Claude Code, os servidores Ignite UI MCP e a skill igniteui-angular-grids transformaram as páginas de Admin geradas em recursos funcionais conectados ao restante do aplicativo. A skill de grids orientou a configuração do igx-grid do Admin, as importações, os templates igxCell, a seleção de linhas, a filtragem no estilo Excel, a exportação para CSV e o dimensionamento, e o Theming MCP forneceu os design tokens. Os formulários e as caixas de diálogo não precisaram de ajuda direta do MCP, e a acessibilidade foi verificada por meio de testes no navegador e com o axe. Com os padrões do Ignite UI já estabelecidos na Iteração 1, sete chamadas ao MCP foram suficientes.

A suíte de testes cresceu de 45 para 105 testes aprovados. As alterações de preço, estoque e catálogo feitas no Backoffice chegam à loja imediatamente, e os pedidos dos clientes voltam para o Backoffice.

Ao final da sessão de Admin, a janela de contexto continha 400.5k de 1M tokens (40%). As ferramentas MCP e as instruções do servidor ocuparam 6.2k tokens (cerca de 0.6%), e as skills, 8.2k (0.8%).

Três prompts do App Builder e um prompt de implementação do Claude adicionaram um Backoffice funcional a uma loja funcional. O fluxo de trabalho é tão útil para fazer um aplicativo crescer quando surgem novos requisitos quanto para criá-lo.

Assim como na Iteração 1, a imagem de créditos do App Builder abaixo é um resumo ilustrativo, não uma tela do App Builder.

Por Que o App Builder e o Ignite UI MCP Funcionam Tão Bem Juntos

O App Builder AI e o Ignite UI MCP cuidam de metades diferentes do mesmo trabalho, e o GameForge mostra como eles se complementam bem.

O App Builder cuida da fase inicial, que é a mais cara. A partir de um projeto em branco, cinco prompts produziram um aplicativo estruturado com páginas, layouts, navegação, componentes Ignite UI, formatos de dados, estilos e uma experiência consistente em todas as visualizações. O agente de código nunca precisou inventar essa estrutura do zero. Ele partiu de uma base real. E como o App Builder exporta um projeto Angular padrão e publica no GitHub, o trabalho continua como um projeto de código comum no seu fluxo de desenvolvimento habitual, em vez de ficar preso à ferramenta visual.

O Ignite UI MCP assume a partir da transferência. O Claude começa com uma base de código funcional, e os servidores MCP dão a ele acesso direto à documentação do Ignite UI, às APIs de componentes e aos tokens de tema de que ele precisa. O agente pode gastar seu contexto com dados, estado, regras de negócio, integração e iteração, em vez de reconstruir a interface. Quando precisou do evento correto do chip, da configuração do Grid Lite ou dos tokens warn e error, ele os consultou em vez de adivinhar. As ferramentas MCP e as instruções do servidor ficaram abaixo de 1% da janela de contexto nas duas sessões.

A segunda iteração é a prova mais forte. Depois que a base de código já tinha ido muito além da exportação original, o App Builder projetou uma área completa de Admin / Backoffice, o Git isolou exatamente o que mudou, e o Claude a integrou sem quebrar a loja. Somando as duas iterações, o GameForge levou 8 prompts do App Builder e 93 de 100 créditos. Ele termina como uma loja e um Backoffice completos, com preços em tempo real, verificações de compatibilidade, inventário, checkout e pedidos que fluem entre o Admin e a loja, tudo sustentado por 105 testes aprovados.

O App Builder leva você rapidamente a uma base sólida para o seu aplicativo. O Ignite UI MCP então permite que o agente de código use sua inteligência onde ela agrega mais valor: transformar essa base em um produto real e continuar a evoluí-lo.

Isso é mais do que uma forma rápida de prototipar. É um caminho prático da ideia ao design, ao código, a um aplicativo funcional e pelas iterações que vêm depois.

Comece Agora

• App Builder
• Ignite UI CLI MCP para Angular
• Ignite UI Theming MCP para Angular
• Desenvolvimento de Aplicativos Assistido por IA com o Ignite UI
• Ignite UI CLI no GitHub
• Aplicativo GameForge PC Builder