Skill GRAFT + Astra: ISSO É ABSOLUTAMENTE INSANO!

Autoria: AICodeKing · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: /GRAFT Skill + Astra: THIS IS ABSOLUTELY CRAZY! · Canal: AICodeKing · 10:56 · Assistir no YouTube

Tópicos: Agentes de IA, Engenharia de software com IA, Ferramentas de desenvolvimento com IA

Resumo

O vídeo demonstra como o projeto open source Graph constrói um grafo estrutural do código que um agent pode consultar para entender relações entre arquivos e funções. Usando Verdant e um serviço de documentos de exemplo, o apresentador mostra como localizar uma falha de permissões: o serviço de exportação não chamava a função que verifica a permissão de exportar. Depois de corrigir o código, o grafo é atualizado e os nove testes passam. O vídeo também explica limitações da análise estática, custos e diferenças entre a camada estrutural e a camada opcional com resumos gerados por IA.

Pontos-chave

A camada estrutural do Graph analisa o código com Tree-sitter e permite consultas sem uma chave de provedor de IA.
O grafo registra elementos como funções, imports e conexões entre partes do código.
No exemplo, um usuário com permissão de leitura conseguia exportar um documento, embora a política exigisse permissão de editor ou proprietário.
A função de verificação de permissão de exportação existia, mas o serviço de exportação não a chamava.
O agent corrigiu o problema usando a função de permissão existente, sem alterar os testes.
O Graph atualizou o grafo após detectar uma alteração no arquivo, antes de uma nova compilação manual.
Após a correção, os nove testes passaram; leitores ainda podiam ler documentos, mas não exportá-los.
O grafo ajuda a localizar relações no código, mas não prova, por si só, que a implementação está correta.
Os resultados de economia de tokens são estimativas; o exemplo do vídeo não reproduz o benchmark controlado dos mantenedores.

Capítulos

Início	Capítulo	Resumo
00:02	O que é o Graph e como funciona	O apresentador explica como o grafo estrutural registra elementos e relações do código, e diferencia essa camada da opção com resumos gerados por IA.
03:08	Instalação e reprodução da falha	A demonstração instala o Graft, apresenta o serviço de documentos e confirma que usuários com permissão de leitura conseguem exportar indevidamente.
06:17	Rastreamento das chamadas e correção	As consultas mostram que o serviço não chama a verificação de permissão de exportação, levando à correção e à atualização automática do grafo.
09:24	Limitações, custos e conclusão	O vídeo ressalta limites da análise estática e das estimativas de tokens, comenta preços do Verdant e recomenda testar o Graph no próprio projeto.

Citações

Estamos usando a camada estrutural nesta demonstração. — 01:34

A função auxiliar pode estar correta enquanto o recurso que a usa continua com defeito. — 06:49

Um grafo que mostra a nova chamada não prova, por si só, que a implementação está correta. — 08:21

Este pequeno passo a passo verifica os comandos e o fluxo de correção do bug. Ele não reproduz aquele benchmark. — 09:54

Conceitos e entidades

Graph (ferramenta): Projeto open source demonstrado no vídeo, que cria um grafo de código consultável por agents.
Graft (ferramenta): Nome usado para a CLI e os comandos de construção e consulta do grafo no exemplo.
Verdant (ferramenta): Ambiente usado para executar o agent, rodar comandos, revisar alterações e acompanhar testes.
Tree-sitter (ferramenta): Ferramenta usada pela camada estrutural para analisar a estrutura do código.
MCP (conceito): Protocolo mencionado como outra forma de integrar o Graph, embora a demonstração use a CLI.
@nanonets/graph (repo): Pacote indicado para instalar o Graph rapidamente com npx.
Node.js (ferramenta): Ambiente de execução cuja versão 20 ou superior é exigida pela versão do Graft testada.

Tradução completa (pt-BR)

00:02 [música] Oi, bem-vindos a mais um vídeo. Se vocês usam agents de programação com IA, provavelmente já viram isto acontecer. Vocês abrem um projeto, pedem uma pequena correção, e o agent passa os minutos seguintes procurando arquivos, lendo imports e tentando entender como tudo se conecta. Depois, começam outra tarefa, e ele refaz boa parte desse trabalho. Hoje quero mostrar um projeto open source chamado Graph, que tenta tornar esse processo mais eficiente. Ele cria um grafo de código que o agent pode consultar para ter um ponto de partida melhor

00:33 quando precisa entender o projeto. Para este vídeo, eu instalei e usei a ferramenta pelo Verdant. Preparei um pequeno serviço de documentos com um bug de permissões, executei os testes e pedi ao Verdant que investigasse usando Graph. Então temos um exemplo concreto para analisar, junto com os comandos e as saídas que vocês podem reproduzir. Vamos começar. Primeiro, o que o Graft realmente faz? Ele lê o código-fonte e registra elementos como funções, imports e as conexões entre eles. Vocês podem perguntar onde algo está implementado, ver as funções disponíveis em

01:03 um arquivo ou rastrear quais partes do projeto chamam uma função específica. Essas informações são úteis porque uma tarefa de programação geralmente envolve mais do que encontrar uma palavra correspondente. Se eu alterar uma função de permissões, também quero saber quais serviços a usam. E, se um serviço se comporta incorretamente, quero seguir o caminho que levou a esse comportamento. O Graft tem duas camadas, e essa distinção é importante. A compilação básica usa tree sitter para analisar a estrutura do código. Vocês podem criar o grafo e executar as consultas que estamos usando hoje

01:34 sem fornecer ao Graph uma chave de provedor de IA. Há também uma compilação profunda opcional, que adiciona resumos escritos por IA e nós de conceitos, usando o provedor de modelo configurado. Portanto, pode haver custos de API, dependendo do provedor escolhido. Nesta demonstração, estamos usando a camada estrutural. Todos os resultados que vocês verão aqui funcionam sem essa chamada adicional ao modelo. O projeto usa a licença MIT, e o grafo estrutural não exige um servidor de banco de dados separado. Os arquivos gerados ficam dentro de uma pasta graft no projeto.

02:05 A compilação também adiciona essa pasta ao git ignore, porque ela pode ser recriada a partir do código. Então, a configuração básica é bem acessível, mas as consultas gratuitas do Graft não tornam gratuito o próprio agent de programação. Se o agent ou o modelo cobra pelo uso, esses custos continuam valendo. Mantenham esses dois custos separados. Agora estou com o Verdant aberto aqui. O fluxo básico é abrir uma pasta de projeto, criar uma tarefa e descrever o que vocês querem que o agent faça. Ele pode inspecionar arquivos, editar o código e executar comandos no terminal, com o progresso e os resultados exibidos na tarefa. Também há um seletor de modelo e há

02:37 o modo de planejamento, para quando vocês quiserem definir uma abordagem antes da implementação. Neste exemplo, os requisitos já estão claros. Então, vou passar ao agent uma investigação específica para realizar. O Verdant também oferece visualizações dos arquivos e resumos das alterações. Assim, depois que o agent edita algo, vocês podem conferir o que mudou. Também há um recurso de revisão de código. E, para trabalhos maiores, o gerenciador pode dividir um objetivo em subtarefas e coordenar os workers. Uma coisa a ter em mente é que as tarefas no mesmo workspace compartilham os arquivos. Criar outra tarefa não significa automaticamente que cada edição ficará isolada. Para este passo a passo, abri uma pasta de demonstração separada, o que

03:08 mantém o exemplo fácil de acompanhar. No momento, o Graph não tem uma entrada específica para o Verdant no instalador de integrações. O que estamos fazendo aqui é pedir ao Verdant que execute a CLI do Graph. O Verdant também oferece suporte a MCP, e o Graph tem um servidor MCP, mas a integração que testei de fato para este vídeo é o fluxo pela linha de comando. Primeiro, pedi ao Verdant que verificasse a versão do Node e instalasse o Graft localmente. A versão que testei é a 0.18.0, e ela exige o Node 20 ou mais recente. Minha máquina estava usando o Node 22. Para uma

03:40 configuração rápida na máquina de vocês, podem usar npx com o pacote @nanonets/graph. Para a gravação, fixei a versão e instalei a ferramenta em uma pasta separada de ferramentas, para podermos repetir o mesmo exemplo. Incluí os comandos exatos nas notas complementares. Depois de instalar, podemos executar graft build dentro do repositório de código. Não é preciso informar uma chave de provedor nesta etapa. Também desativei a telemetria opcional nos comandos da demonstração. Agora, vamos ver o exemplo. Este é um pequeno serviço de documentos com proprietários, editores, visualizadores e usuários sem relação com o documento. Um visualizador deve poder

04:12 ler um documento compartilhado, mas exportá-lo como arquivo CSV deve exigir que o usuário seja editor ou proprietário. Essas são as regras do nosso aplicativo de exemplo. Outro produto poderia escolher uma política de exportação diferente. A ideia é ver se o código segue a política que definimos de fato. Vamos executar os testes de referência. Temos nove testes: oito passam e um falha. O teste que falha diz que um visualizador não pode exportar um documento compartilhado, mas o handler retorna o status 200 em vez de 403. E, se executarmos o exemplo diretamente, vemos a mesma coisa. O visualizador consegue ler, como

04:43 esperado. O visualizador não consegue editar, também como esperado. Mas consegue exportar o documento, que é o bug que inserimos neste exemplo. Gosto de usar um exemplo pequeno assim porque dá para acompanhar o caminho inteiro. São dados sintéticos, e estamos chamando os route handlers localmente. Não há uma conta de produção nem um serviço em deploy envolvidos. Agora, no primeiro exemplo com o Graft, vamos entender a base de código. O Verdant executa graft build, que produz 29 nós e 66 arestas a partir de nove arquivos JavaScript, incluindo os testes. Esses números são

05:15 deste exemplo minúsculo, então não são um benchmark de escalabilidade. Em seguida, executamos graft map para obter uma visão geral e perguntamos onde as permissões de exportação de documentos são verificadas. Adicionamos a flag d-source. Assim, os resultados incluem o código relevante junto com a localização dos arquivos. Certo. O primeiro resultado é a função de exportação de documentos. O próximo é o helper de permissão de exportação. Também recebemos o route handler de exportação e a função que carrega um documento para um usuário. É um conjunto útil de arquivos para essa pergunta. Podemos ver que a função de exportação busca o documento e imediatamente

05:46 o transforma em CSV. Também podemos ver um helper separado que permite que proprietários e editores exportem. O Graph está retornando o código-fonte relevante. O Verdant continua responsável por ler esse código e avaliar se o comportamento está correto. A própria consulta é uma recuperação determinística. Então, não estamos pagando por outro modelo só para produzir esses resultados de busca. Também há o comando skeleton. Executamos esse comando no arquivo de permissões, e ele lista as assinaturas das funções que verificam o papel do usuário em relação a um documento: permissão de leitura, permissão de edição e permissão de exportação. Isso oferece uma visão geral rápida da API dos arquivos

06:17 sem despejar o corpo de cada função na conversa. Agora, no segundo exemplo, vamos seguir os chamadores. Perguntamos ao Graph quais partes do projeto chamam a função de exportação de documentos, com profundidade dois. Ele mostra o route handler e, em seguida, as conexões com a demonstração e os testes. Depois fazemos a mesma pergunta sobre o helper de permissão de exportação. E aqui está a pista útil. A saída aponta para os testes, mas não há nenhuma chamada do serviço de exportação. Portanto, a política existe, e há até um teste que a verifica diretamente. Mas o fluxo de exportação real

06:49 nunca a usa. É por isso que testar apenas um helper não basta. O helper pode estar correto enquanto o recurso que o usa continua com defeito. Se seguirmos o código-fonte, o serviço de exportação carrega o documento por meio de uma função que verifica o acesso de leitura. O visualizador passa nessa verificação porque tem permissão para ler. Em seguida, o serviço de exportação cria o CSV sem verificar a permissão mais restrita de exportação. Isso explica tanto o teste que falha quanto a conexão ausente no grafo. Então, temos algo concreto para o agent corrigir. Agora peço ao Verdant que aplique a política de exportação existente

07:20 dentro do serviço de exportação. A alteração é pequena. Importar o helper de permissões. Importar o tipo de erro e rejeitar a solicitação se o usuário não puder exportar. Mantemos exatamente como estão os testes existentes. E aqui está o terceiro exemplo, que considero bastante útil. Depois da edição, executamos graph check antes de reconstruir qualquer coisa. Ele informa que o grafo está desatualizado e identifica que o serviço de exportação foi alterado. Em seguida, fazemos a mesma consulta ao Graft, sem executar manualmente outra compilação. A saída diz que o grafo foi atualizado porque um arquivo mudou, e o trecho do código-fonte agora inclui a nova permissão

07:51 Certo. Se pedirmos novamente os callers do helper de permissão de exportação, agora a função de exportação do documento aparece. Assim, conseguimos ver a conexão que estava faltando antes da correção. Uma verificação de atualização posterior informa que o grafo está atualizado. Isso é importante quando um agent faz várias alterações em uma sessão. Você quer que a próxima consulta dele reflita o código atualizado. Nesta execução, isso funcionou com uma edição ainda não commitada. Também repeti a sequência em uma cópia temporária separada para verificar. Agora, vamos executar os testes novamente. Os nove passam. O visualizador

08:21 recebe um erro 403 ao tentar exportar. Enquanto isso, o editor ainda consegue exportar, e o visualizador também continua podendo ler o documento. Então, mantivemos o acesso de leitura pretendido. Isso é ótimo. O grafo nos ajudou a encontrar e inspecionar a conexão relevante, e os testes verificaram o comportamento resultante. Eu ainda manteria as duas partes desse workflow. Um grafo que mostra a nova chamada não prova, por si só, que a implementação está correta. O Graph também tem uma visualização interativa. Exportei o grafo do código e abri dentro do painel do navegador do Verden. Você pode alternar entre o grafo

08:52 e uma visualização em tópicos dos arquivos. Selecione uma função e inspecione de quais elementos ela depende e quais dependem dela. Incluí as exportações de antes e depois com os exemplos. Agora, há algumas limitações que vale ter em mente. A análise estática tem limites, especialmente com comportamento dinâmico, e o nível de suporte do grafo varia entre linguagens. O grafo fornece contexto útil, mas você ainda precisa inspecionar o código quando o resultado é ambíguo. A atualização automática que testamos atualiza a estrutura. Ela não regenera resumos de IA pagos toda vez que você faz uma pergunta. Se uma atualização falhar, o Graph pode recorrer ao grafo existente. Portanto, preste atenção aos avisos.

09:24 E, se você quiser a camada profunda, confira se ela realmente foi executada com o provider configurado. Um comando bem-sucedido, por si só, não prova que esses resumos foram gerados. Você também verá estimativas de economia de tokens em algumas saídas do Graph. Elas comparam o contexto retornado com a leitura integral dos arquivos abrangidos. São estimativas e não provam que nossa sessão completa no Verdant tenha usado essa porcentagem a menos de tokens. Os mantenedores relatam separadamente 42% menos tokens e 60% menos tempo no benchmark controlado deles. Esses são os resultados deles. Este breve passo a passo verifica os comandos

09:54 e o workflow de correção do bug. Ele não reproduz aquele benchmark nem comprova um aumento de velocidade em relação ao uso exclusivo do Verdant. Quanto aos preços do Verdant, as opções mensais atuais começam em US$ 5 para o plano Light. O Starter custa US$ 19, o Pro, US$ 59, e o Max, US$ 179. A página de preços também lista 100 créditos gratuitos, válidos por 7 dias, para novos usuários. Confira os limites atuais e os custos dos modelos ao escolher um plano. Pessoalmente, acho que vale a pena experimentar o Graph quando seu agent precisa entender repetidamente

10:25 as relações entre diferentes partes de uma codebase. Você pode começar com um grafo estrutural, usar algumas consultas direcionadas e ver se os resultados ajudam no seu projeto antes de configurar a camada profunda opcional. E o Verdant nos oferece um lugar conveniente para executar esse workflow, inspecionar a saída, revisar as alterações e manter os testes junto da tarefa. O exemplo completo inclui a versão original que falhava, a versão corrigida, as exportações do grafo e um script de replay que executa a sequência em uma cópia temporária. No geral, é bem legal. Enfim, me conte o que você achou nos comentários.

10:56 [música] Se você gostou deste vídeo, considere fazer uma doação pela opção Super Thanks ou se tornar membro clicando no botão [música] Seja membro. Além disso, deixe seu gostei neste vídeo e inscreva-se no meu canal. Vejo você no próximo. Até lá, tchau. [música] >> [música]

Transcrição original

[00:02] [music] Hi, welcome to another video. So, if you use AI coding agents, you have probably seen this happen. You open a project, ask for a small fix, and the agent spends the next few minutes searching files, reading imports, and figuring out how everything connects. Then, you start another task, and it does a lot of that work again. Today I want to show you an open source project called Graph that tries to make that process more efficient. It builds a code graph that your agent can query so it has a better

[00:33] starting point when it needs to understand your project. And for this video I actually installed it and used it through Verdant. I prepared a small document service with a permissions bug ran the tests and asked Verdant to investigate it using Graph. So we have a concrete example to look at along with the commands and outputs you can reproduce yourself. So let’s get right into it. First, what does graft actually do? It reads the source code and records things like functions, imports, and the connections between them. You can ask where something is implemented, look at

[01:03] a files available functions, or trace which parts of the project call a particular function. That information is useful because a coding task usually involves more than finding one matching word. If I change a permissions function, I also want to know which services use it. And if a service behaves incorrectly, I want to follow the path that led to that behavior. Now, graft has two layers and this is an important distinction. The basic build uses tree sitter to analyze code structure. You can build the graph and run the queries we are using today

[01:34] without giving graph an AI provider key. There is also an optional deep build which adds AI written summaries and concept nodes that uses your configured model provider. So there can be API costs depending on the provider you choose. We are using the structural layer in this demo. All the results you will see here work without that additional model call. The project is MIT licensed and the structural graph does not require a separate database server. It keeps its generated files inside a graft folder in your project.

[02:05] The build also adds that folder to git ignore because you can regenerate it from the code. So the basic setup is quite approachable, but free graft queries do not make the coding agent itself free. If your agent or model has usage charges, those still apply. Keep those two costs separate. Now I have Verdant open here. The basic workflow is to open a project folder, create a task, and describe what you want the agent to do. It can inspect files, edit the code, and run terminal commands with the progress and results shown in the task. You also have a model selector and there

[02:37] is plan mode when you want to work through an approach before implementation. For this example, the requirements are already clear. So I’m giving the agent a specific investigation to carry out. Verdant also gives you file views and change summaries. So once the agent edits something, you can inspect what changed. There is a code review feature as well. And for larger work, its manager can break a goal into subtasks and coordinate workers. One thing to keep in mind is that tasks in the same workspace share the files. Creating another task does not automatically mean every edit is isolated. For this walkthrough, I opened a dedicated demo folder which

[03:08] keeps the example easy to follow. Now, Graph does not currently have a dedicated Verdant entry in its integration installer. What we are doing here is asking Verdant to run the Graph CLI. Verdant also supports MCP and Graph has an MCP server, but the integration I actually tested for this video is the command line workflow. First, I asked Verdant to check the node version and install graft locally. The version I tested is 0.18.0 and it requires node 20 or newer. My machine was running node 22. For a quick

[03:40] setup on your own machine, you can use npx with the at nanonets/graph package. For the recording, I pinned the version and installed it in a separate tooling folder so we can repeat the same example. I have put the exact commands in the companion notes. Once that is installed, we can run graft build inside the code repository. There is no provider key to enter for this part. I also disabled optional telemetry for the demo commands. Now let’s look at the example. This is a small document service with owners, editors, viewers, and unrelated users. A viewer should be

[04:12] able to read a shared document, but exporting it as a CSV file should require an editor or owner. These are rules for our sample app. A different product could choose a different export policy. The point is to see whether the code follows the policy we have actually defined. So let’s run the baseline tests. We have nine tests, eight pass and one fails. The failing test says a viewer cannot export a shared document but the handler returns status 200 instead of 403. And if we run the example directly, we can see the same thing. The viewer can read, which is

[04:43] expected. The viewer cannot edit, which is also expected. But the viewer can export the document, which is the bug we put into this fixture. I like using a small example like this because you can follow the entire path. It is synthetic data and we are calling the route handlers locally. There is no production account or deployed service involved. Now for the first graft example, let’s understand the codebase. Verdant runs graft build and it produces 29 nodes and 66 edges from nine JavaScript files including the tests. Those numbers are

[05:15] from this tiny fixture so they are not a scalability benchmark. Then we run graft map to get an overview and ask where document export permissions are checked. We add the d- source flag. So the results include the relevant code alongside the file locations. Okay. The first result is the export document function. The next result is the export permission helper. We also get the export route handler and the function that loads a document for a user. That is a useful collection of files for this question. We can see the export function fetching the document and immediately

[05:46] turning it into CSV. We can also see a separate helper that permits owners and editors to export. Graph is returning relevant source here. Verdant is still responsible for reading that source and reasoning about whether the behavior is correct. The query itself is deterministic retrieval. So we are not paying another model just to produce these search results. There is also the skeleton command. We run it on the permissions file and it lists the function signatures for checking a document’s role. Read permission, edit permission, and export permission. That gives us a quick overview of the files

[06:17] API without dumping every function body into the conversation. Now for the second example, let’s follow the callers. We ask graph which parts of the project call the export document function with a depth of two. It shows the route handler and then the connections to the demo and test. Then we ask the same thing about the export permission helper. And here is the useful clue. The output points to the tests, but there is no call from the export service. So the policy exists and there is even a test checking that policy directly. But the actual export

[06:49] path never uses it. This is why testing a helper alone is not enough. The helper can be correct while the feature using it is still broken. If we follow the source, the export service loads the document through a function that checks read access. A viewer passes that check because viewers are allowed to read. The export service then creates the CSV without checking the stricter export permission. That explains both the failing test and the missing connection in the graph. So we have something concrete for the agent to fix. Now I ask Verdant to enforce the existing export

[07:20] policy inside the export service. The change is small. Import the permission helper. Import the error type and reject the request if the user cannot export. We keep the existing tests exactly as they are. And here is the third example which I think is quite useful. After the edit, we run graph check before rebuilding anything. It reports that the graph is stale and identifies the export service has changed. Then we run the same graft question again without manually running another build. The output says it refreshed the graph because one file changed and the source excerpt now includes the new permission

[07:51] check. If we ask for the callers of the export permission helper again, the export document function now appears. So we can see the connection that was missing before the fix. A subsequent freshness check reports that the graph is current. This matters when an agent is making several changes in a session. You want its next query to reflect the updated code. In this run, that worked with an uncommitted edit. And I also repeated the sequence in a separate temporary copy to verify it. Now, let’s run the tests again. All nine pass. The viewer

[08:21] gets 403 when trying to export. While the editor can still export successfully, the viewer can still read the document, too. So, we have kept the intended read access. So, that’s great. The graph helped us find and inspect the relevant connection and the tests verified the resulting behavior. I would still keep both parts of that workflow. A graph showing the new call does not by itself prove the implementation is correct. Graph also has an interactive visualization. I exported the code graph and opened it inside Verden’s browser panel. You can switch between the graph

[08:52] and a file outline. Select a function and inspect what it depends on and what depends on it. I have included both the before and after exports with the examples. Now there are a few limitations to keep in mind. Static analysis has limits especially with dynamic behavior and graph’s language support varies in depth. The graph is useful context but you still need to inspect the code when the result is ambiguous. The automatic refresh we tested update structure. It does not regenerate paid AI summaries every time you ask a question. If a refresh fails, graph can fall back to the existing graph. So pay attention to its notices.

[09:24] And if you want the deep layer, make sure it actually ran with your configured provider. A successful command alone does not prove those summaries were generated. You will also see token- saving estimates in some graph outputs. Those compare the returned context with reading the covered files in full. They are estimates and they do not prove that our complete Verdant session used that percentage fewer tokens. The maintainers separately report 42% fewer tokens and 60% less time in their controlled benchmark. Those are their results. This small walk through verifies the commands

[09:54] and the bug fix workflow. It does not reproduce that benchmark or establish a speed up over using Verdant alone. For Verdant’s pricing, the current monthly options start at $5 for light. Starter is $19, pro is $59, and max is $179. The pricing page also lists 100 free credits valid for 7 days for new users. Check the current limits and model costs when you choose a plan. Personally, I think Graph is worth trying when your agent repeatedly needs to understand

[10:25] relationships across a codebase. You can start with a structural graph, use a few targeted queries, and see whether the results help on your actual project before setting up the optional deep layer. And Verdant gives us a convenient place to run that workflow, inspect the output, review the changes, and keep the tests alongside the task. The complete example includes the original failing version, the fixed version, the graph exports, and a replay script that runs the sequence in a temporary copy. Overall, it’s pretty cool. Anyway, let me know your thoughts in the comments.

[10:56] [music] If you like this video, consider donating through the super thanks option or becoming a member by clicking the [music] join button. Also, give this video a thumbs up and subscribe to my channel. I’ll see you in the next one. Until then, bye. [music] >> [music]