Escaneie onde o código está.

A CLI lê os seus repositórios em um notebook ou no CI, encontra as rotas, as chamadas, as filas e os modelos e envia só o grafo resultante para o seu workspace. É o mesmo scanner que o nosso runner hospedado usa, então os dois chegam ao mesmo resultado. Em um pull request, ela diz o que a mudança quebra.

$ npm install -g kuuhaku
$ kuuhaku login --token <token from the app>
$ kuuhaku scan ~/work/company --push
$ kuuhaku check ~/work/company

Instalação

O npm é o melhor caminho: um comando em qualquer sistema com Node 18 ou mais recente, e as atualizações vêm com npm update -g.

npm install -g kuuhaku

npx kuuhaku scan . --push

kuuhaku.exe scan C:\work --push

docker run --rm -v "$PWD:/code:ro" \
  -e KUUHAKU_TOKEN kuuhaku/cli \
  scan /code --push

brew install kuuhaku
scoop install kuuhaku

Conecte uma máquina

1. Pegue o token de push do workspace.

   No app, na página da CLI ou em Configurações, Varredura. O token só pode enviar grafos para esse workspace e aparece uma única vez.

2. Faça login pelo terminal.

   Uma vez por máquina. O token fica guardado em ~/.kuuhaku, legível só pelo seu usuário.

   $ kuuhaku login --token <token> --api https://api.your-domain

3. Escaneie e envie.

   Aponte para uma pasta de repositórios ou para um architecture.yaml. A máquina aparece na página da CLI do workspace com o sistema, a versão e o último envio.

   $ kuuhaku scan ~/work/company --push

Comandos

No CI

Escaneie a cada push na main. Salve o token como o secret KUUHAKU_TOKEN do repositório; o job aparece como uma máquina, com o nome do repositório.

name: Kuuhaku
on:
  push:
    branches: [main]
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 400
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - run: npx kuuhaku scan . --push --api https://api.your-domain
        env:
          KUUHAKU_TOKEN: ${{ secrets.KUUHAKU_TOKEN }}

Verifique cada pull request. O job falha quando a mudança quebra quem chama, e o relatório vai para o pull request como um comentário que a próxima execução atualiza. Nada é enviado, então nenhum token é necessário.

name: Kuuhaku check
on: pull_request
permissions:
  contents: read
  pull-requests: write
jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - run: npx kuuhaku check . --base origin/${{ github.base_ref }} --markdown check.md
      - if: always() && hashFiles('check.md') != ''
        run: gh pr comment ${{ github.event.pull_request.number }} --edit-last --body-file check.md || gh pr comment ${{ github.event.pull_request.number }} --body-file check.md
        env:
          GH_TOKEN: ${{ github.token }}

No Bitbucket Pipelines, busque antes a branch de destino, já que um pipeline só clona a própria: git fetch origin "+refs/heads/$BITBUCKET_PR_DESTINATION_BRANCH:refs/remotes/origin/$BITBUCKET_PR_DESTINATION_BRANCH", depois npx kuuhaku check . --base origin/$BITBUCKET_PR_DESTINATION_BRANCH. Um workspace com vários repositórios precisa dos outros clonados ao lado do que mudou; eles só são lidos.

O que sai da máquina

O graph.json e mais nada. Você pode abri-lo antes de enviar: kuuhaku scan sem --push grava o arquivo e para.