Portfolio Hub

O portfolio-hub é um portfólio técnico estático publicado com Astro no GitHub Pages. Ele agrega projetos, documentação viva e changelogs de múltiplos repositórios em um único lugar, atualizado automaticamente via GitHub Actions.

A proposta central é simples: cada projeto continua dono do seu próprio código e da sua própria documentação, enquanto o hub centraliza a apresentação, o histórico de releases e a navegação.

O que o projeto resolve

Portfólios técnicos costumam sofrer com três problemas:

a lista de projetos fica desatualizada rapidamente;
a documentação fica espalhada entre vários repositórios sem ponto central;
o histórico de releases não aparece de forma consistente.

O portfolio-hub resolve isso com um modelo baseado em arquivos versionados no Git:

cada projeto é descrito por um arquivo JSON em projects/;
a documentação renderizada pelo hub fica em docs/<slug>/;
o changelog de cada projeto fica em changelogs/<slug>.md;
o site é gerado estaticamente e publicado no GitHub Pages;
repositórios externos atualizam docs e releases via repository_dispatch.

Estrutura do repositório

portfolio-hub/
├── projects/
│   └── meu-projeto.json          # metadados: versão, status, tags, repo_url
├── docs/
│   └── meu-projeto/
│       ├── README.md             # visão geral
│       ├── architecture.md       # arquitetura e decisões
│       └── usage.md              # operação e integração
├── changelogs/
│   └── meu-projeto.md            # histórico de releases
├── content/
│   └── blog/                     # posts do blog (Markdown)
└── src/
    ├── components/               # Nav, ProjectCard, BlogCard
    ├── layouts/                  # Layout global
    └── pages/                    # index, blog, projects/[slug]

Cada parte tem uma responsabilidade clara:

Caminho	Responsabilidade
`projects/*.json`	Metadados de listagem, versão e status
`docs/<slug>/`	Documentação técnica renderizada na página do projeto
`changelogs/<slug>.md`	Histórico de releases por projeto
`content/blog/`	Posts do blog em Markdown
`src/config.ts`	Configuração central do site (usuário, LinkedIn, nome)

Como um projeto aparece no site

Para um projeto ser exibido corretamente no hub, ele precisa de três blocos de informação:

1. Metadados (`projects/<slug>.json`)

{
  "name": "meu-projeto",
  "display_name": "Meu Projeto",
  "description": "Descrição curta do projeto.",
  "version": "1.2.0",
  "status": "active",
  "tags": ["astro", "docs", "gitops"],
  "repo_url": "https://github.com/MatheusAzevedoDev/meu-projeto",
  "docs_updated_at": "2026-04-21T00:00:00Z",
  "changelog_updated_at": "2026-04-21T00:00:00Z"
}

2. Documentação (`docs/<slug>/`)

Arquivos Markdown na pasta do projeto. Arquivos recomendados:

README.md — visão geral e quickstart
architecture.md — fluxos, diagramas e decisões
usage.md — setup, operação e integração
api.md — referência técnica (quando aplicável)

Cada documento pode definir title e icon via frontmatter:

---
title: Arquitetura
icon: layers
---

3. Changelog (`changelogs/<slug>.md`)

Histórico de releases no formato Keep a Changelog. Gerado automaticamente pelos projetos que usam o project-template.

Fluxos de atualização

Fluxo manual

Você edita diretamente os arquivos no repositório do hub e faz push. Adequado para manutenção pontual.

Fluxo automatizado via project-template

Projetos criados a partir do project-template enviam um repository_dispatch: project-update ao hub a cada merge em main. O hub atualiza metadados, docs e changelog automaticamente e dispara um novo deploy.

feature/foo → develop → main
                            └─▶ repository_dispatch: project-update
                                       └─▶ portfolio-hub atualizado
                                                  └─▶ GitHub Pages redeploy

Fluxo granular (update-docs / new-release)

Para repositórios que preferem separar a atualização de documentação da publicação de releases, o hub também aceita dois eventos distintos:

update-docs — sincroniza apenas docs/<slug>/ e docs_updated_at
new-release — atualiza version, changelog_updated_at e changelogs/<slug>.md

Status do projeto

O campo status comunica o momento de vida do projeto na homepage:

Status	Significado
`active`	Em uso, mantido ou pronto para demonstração
`wip`	Em desenvolvimento ativo
`archived`	Encerrado, legado ou mantido só como referência

Ícones por frontmatter

Cada documento pode definir seu ícone no frontmatter:

---
title: Como Usar
icon: terminal
---

Ícones disponíveis: home · layers · terminal · code · zap · file · book · changelog · clock · shield · database · settings · list · star · link · chart · package · github

Se icon não for informado, o sistema infere pelo nome do arquivo.

Suporte a Mermaid

A documentação aceita blocos mermaid para diagramas de fluxo, sequência e arquitetura:

```mermaid
flowchart LR
    Repo["Projeto"] --> Action["GitHub Actions"]
    Action --> Hub["portfolio-hub"]
    Hub --> Pages["GitHub Pages"]
```

Resumo operacional

Para adicionar ou manter um projeto no hub:

criar ou garantir que projects/<slug>.json existe;
manter docs/<slug>/ com arquivos organizados;
manter changelogs/<slug>.md com histórico legível;
usar status e tags de forma consistente;
usar icon nos documentos para personalizar a sidebar.

Próximos passos

Arquitetura — entenda os eventos, workflows e a organização interna do hub
Como Usar — configure projetos, documente e integre repositórios externos

Arquitetura

O portfolio-hub é um site estático que agrega metadados, documentação e changelogs de múltiplos projetos. Ele não executa os projetos, não tem backend em runtime e não depende de nenhuma API externa para montar o conteúdo principal — tudo parte de arquivos versionados no Git.

Visão geral

flowchart TB
    subgraph Projetos["Projetos externos"]
        PT["project-template"]
    end

    subgraph Hub["portfolio-hub — workflows"]
        PU["project-update.yml"]
        RD["receive-docs.yml"]
        RR["receive-release.yml"]
    end

    subgraph Files["Arquivos versionados"]
        META["projects/slug.json"]
        DOCS["docs/slug/"]
        CHANGELOGS["changelogs/slug.md"]
        BLOG["content/blog/"]
    end

    ASTRO["Astro build"]
    PAGES["GitHub Pages"]

    PT -->|"project-update"| PU
    PT -->|"update-docs"| RD
    PT -->|"new-release"| RR

    PU --> META
    PU --> DOCS
    PU --> CHANGELOGS
    RD --> DOCS
    RR --> META
    RR --> CHANGELOGS

    META --> ASTRO
    DOCS --> ASTRO
    CHANGELOGS --> ASTRO
    BLOG --> ASTRO

    ASTRO -->|"deploy.yml"| PAGES

Camadas principais

1. Metadados dos projetos

Cada projeto possui um arquivo em projects/<slug>.json que define o que é exibido nos cards e na página do projeto.

classDiagram
    class ProjectMetadata {
        +string name
        +string display_name
        +string description
        +string version
        +string status
        +string[] tags
        +string repo_url
        +string docs_updated_at
        +string changelog_updated_at
    }

Esse arquivo é criado automaticamente pelo workflow project-update.yml na primeira release de projetos integrados via project-template. Pode também ser criado manualmente para projetos que não usam automação.

2. Documentação por projeto

A pasta docs/<slug>/ contém os arquivos Markdown técnicos do projeto. Cada arquivo pode definir:

title via frontmatter — nome exibido na sidebar
icon via frontmatter — ícone da aba
diagramas Mermaid inline

Arquivos comuns: README.md, architecture.md, usage.md, api.md, security.md

3. Changelog por projeto

Cada projeto mantém um arquivo em changelogs/<slug>.md. Essa camada é separada da documentação intencionalmente:

documentação explica como o projeto funciona
changelog explica o que mudou entre versões

4. Blog

Posts em content/blog/*.md com frontmatter YAML. O nome do arquivo define a URL (content/blog/meu-post.md → /blog/meu-post).

5. Renderização

O Astro lê todos os arquivos no build e gera HTML estático. Não há fetch de dados em runtime.

Página	Arquivo
Homepage com projetos e filtros	`src/pages/index.astro`
Página de projeto com docs e changelog	`src/pages/projects/[slug].astro`
Listagem do blog	`src/pages/blog/index.astro`
Post individual	`src/pages/blog/[slug].astro`
Navbar compartilhada	`src/components/Nav.astro`
Shell global e tokens CSS	`src/layouts/Layout.astro`

Workflows do hub

deploy.yml

Dispara em todo push para main (inclusive via workflow_dispatch). Executa dois jobs em sequência: build (Astro) e deploy (GitHub Pages).

flowchart LR
    A["push em main"] --> B["build - npm run build"]
    B --> C["upload artifact"]
    C --> D["deploy - GitHub Pages"]

changelog.yml

Dispara em push para main, ignorando mudanças em CHANGELOG.md, docs/, content/ e projects/. Gera o CHANGELOG.md do próprio hub com conventional-changelog e commita com [skip ci].

project-update.yml

Dispara via repository_dispatch: project-update. Usado pelo project-template após cada release.

O que faz:

Cria ou atualiza projects/<slug>.json com versão, descrição, tags e repo_url
Preserva status existente (default active na criação)
Busca CHANGELOG.md do repositório → changelogs/<slug>.md
Busca docs/README.md, docs/architecture.md, docs/usage.md → docs/<slug>/
Commita e faz push com PORTFOLIO_TOKEN (dispara o deploy)

sequenceDiagram
    participant Repo as Projeto externo
    participant Hub as portfolio-hub
    participant Pages as GitHub Pages

    Repo->>Hub: repository_dispatch: project-update
    Hub->>Hub: atualiza projects/slug.json
    Hub->>Repo: GET CHANGELOG.md
    Hub->>Repo: GET docs/README.md
    Hub->>Repo: GET docs/architecture.md
    Hub->>Repo: GET docs/usage.md
    Hub->>Hub: commit e push
    Hub->>Pages: deploy.yml dispara automaticamente

receive-docs.yml

Dispara via repository_dispatch: update-docs. Para repositórios que atualizam documentação independentemente de releases.

O que faz:

Lista todos os arquivos em docs/ no commit especificado
Baixa cada arquivo → docs/<slug>/
Atualiza docs_updated_at em projects/<slug>.json
Commita e faz push

Payload esperado:

{
  "project": "nome-do-projeto",
  "repo_url": "https://github.com/org/repo",
  "commit_sha": "abc123def",
  "updated_at": "2026-04-21T10:00:00Z"
}

receive-release.yml

Dispara via repository_dispatch: new-release. Para repositórios com processo de release próprio.

O que faz:

Atualiza projects/<slug>.json com nova versão, preservando docs_updated_at e tags existentes
Busca CHANGELOG.md do repositório (fallback: body da última release no GitHub)
Commita e faz push

Payload esperado:

{
  "project": "nome-do-projeto",
  "display_name": "Nome Exibido",
  "version": "1.2.0",
  "description": "Descrição do projeto",
  "repo_url": "https://github.com/org/repo",
  "updated_at": "2026-04-21T10:00:00Z"
}

Workflows do project-template

Projetos criados a partir do project-template têm três workflows próprios:

flowchart LR
    F["feature/ ou bug/"] -->|"push - ci.yml"| D["develop"]
    D -->|"merge - promote.yml"| M["main"]
    M -->|"merge - release.yml"| R["vX.Y.Z + release"]
    R -->|"project-update dispatch"| H["portfolio-hub"]
    H -->|"deploy.yml"| P["GitHub Pages"]

Workflow	Gatilho	Função
`ci.yml`	push em `feature/` ou `bug/`	Abre PR automático para `develop`
`promote.yml`	push em `develop`	Abre PR automático para `main`
`release.yml`	push em `main`	Bump de versão, changelog, tag, release, notifica hub

release.yml — lógica de bump

Commits contêm	Bump	Exemplo
`tipo!:` ou `BREAKING CHANGE`	major	`1.2.0 -> 2.0.0`
`feat:`	minor	`1.2.0 -> 1.3.0`
qualquer outro	patch	`1.2.0 -> 1.2.1`

Mudanças apenas em docs/ não disparam bump — o release.yml detecta isso e encerra sem criar tag.

Fluxo de build

flowchart LR
    A["projects/slug.json"] --> D["Astro build"]
    B["docs/slug/"] --> D
    C["changelogs/slug.md"] --> D
    E["content/blog/"] --> D
    D --> F["HTML estático"]
    F --> G["GitHub Pages"]

Decisões arquiteturais

O hub como agregador, não runtime

O portfolio-hub centraliza apresentação, documentação e changelog. Cada projeto pode usar qualquer stack ou estratégia de deploy — o hub não sabe nem precisa saber como o projeto roda.

Separação entre docs e releases

Existem dois tipos de atualização com naturezas distintas:

Tipo	Objetivo	Atualiza
`update-docs`	Conteúdo técnico evoluiu	`docs/<slug>/`, `docs_updated_at`
`new-release`	Nova versão publicada	`version`, `changelog`, `changelog_updated_at`
`project-update`	Tudo de uma vez (usado pelo template)	Todos os campos

Git como fonte de verdade

Toda atualização passa por um commit no repositório do hub. Isso garante:

histórico auditável de todas as mudanças
rollback trivial via git revert
revisão em pull requests antes de ir ao ar
nenhum estado externo para gerenciar

PORTFOLIO_TOKEN como ponte entre repositórios

O token permite que projetos externos façam push de conteúdo para o hub. Armazenado como secret da organização MatheusAzevedoDev, é herdado por todos os repositórios sem configuração individual.

Sistema visual

A interface foi construída para leitura técnica:

tipografia: Syne (display/headings), DM Sans (corpo), JetBrains Mono (código)
tokens CSS em custom properties (--fg-1, --accent, --border, etc.)
navbar compartilhada via componente Nav.astro
cards com filtros por tag e status na homepage
sidebar de documentação gerada a partir dos arquivos em docs/<slug>/
renderização de Markdown com suporte nativo a Mermaid
âncoras automáticas em todos os headings para navegação por índice

Escalabilidade

Adicionar um novo projeto ao hub requer apenas:

um JSON em projects/
uma pasta em docs/
um arquivo em changelogs/

O restante da renderização é reaproveitado automaticamente. O modelo funciona para qualquer número de projetos sem mudança de código.

Setup Guide — Portfolio Hub

Referência completa para configurar o site, publicar posts, integrar projetos e entender os fluxos de automação.

1. Configuração inicial do site

Edite src/config.ts:

export const SITE_CONFIG = {
  githubUser: 'seu-usuario',
  linkedinUrl: 'https://linkedin.com/in/seu-perfil',
  repoName: 'portfolio-hub',
  siteName: 'Seu Nome',
  siteDescription: 'Descrição do site para SEO',
};

Esse arquivo alimenta a navbar (botões GitHub e LinkedIn), o título das páginas e os metadados de SEO.

2. Adicionando posts no blog

Posts ficam em content/blog/ como arquivos Markdown com frontmatter YAML.

Criando um post

Crie content/blog/meu-post.md. O nome do arquivo vira a URL: /blog/meu-post.

---
title: Título do Post
description: Um parágrafo descrevendo o assunto — aparece na listagem e no SEO.
date: 2026-04-21
tags: [Go, GitOps, Backend]
featured: true
---

Conteúdo do post em Markdown aqui.

Campos do frontmatter

Campo	Obrigatório	Descrição
`title`	sim	Título exibido na listagem e no post
`description`	não	Subtítulo/resumo — aparece na listagem
`date`	sim	Data no formato `YYYY-MM-DD` — define a ordenação
`tags`	não	Array de tags — ativa o filtro na listagem
`featured`	não	`true` exibe o post como destaque no topo

Apenas um post deve ter featured: true. Se nenhum tiver, o post mais recente é destacado automaticamente.

Formatação suportada

O conteúdo aceita Markdown padrão e blocos de código com sintaxe destacada:

## Título de seção

Parágrafo com **negrito**, _itálico_ e `código inline`.

```go
func main() {
    fmt.Println("hello")
}
```

> Blockquote para citações ou notas.

Para diagramas, use blocos mermaid:

```mermaid
graph LR
    A[Input] --> B[Processamento] --> C[Output]
```

Publicando

git add content/blog/meu-post.md
git commit -m "docs: add post sobre meu tema"
git push

O GitHub Actions faz o deploy automaticamente após o push em main.

3. Integrando um novo projeto

Passo 1 — Criar o repositório a partir do template

Acesse MatheusAzevedoDev/project-template e clique em Use this template → Create a new repository.

O novo repositório já vem com:

CI que abre PR automático para develop em branches feature/ e bug/
Workflow que abre PR automático de develop para main
Release automática com bump de versão, changelog e notificação ao portfolio-hub
Commitlint + Husky para validação local de commits
Estrutura de documentação em docs/

Passo 2 — Configurar o `PORTFOLIO_TOKEN`

O token já está configurado como secret da organização MatheusAzevedoDev e é herdado automaticamente por todos os repositórios criados dentro dela. Nenhuma ação extra é necessária.

Se o repositório for criado fora da organização, adicione o secret manualmente em Settings → Secrets and variables → Actions → New repository secret com o nome PORTFOLIO_TOKEN.

Passo 3 — Clonar e instalar

git clone https://github.com/MatheusAzevedoDev/seu-projeto
cd seu-projeto
npm install

O npm install ativa o Husky automaticamente via script prepare.

Passo 4 — (Opcional) Pré-registrar no portfolio-hub

O arquivo projects/seu-projeto.json é criado automaticamente pelo workflow project-update.yml na primeira release. Você pode criá-lo manualmente se quiser definir o status ou aparecer no hub antes da primeira release:

{
  "name": "seu-projeto",
  "display_name": "Seu Projeto",
  "description": "Descrição breve e impactante",
  "version": "0.1.0",
  "tags": ["Go", "Node", "Docker"],
  "repo_url": "https://github.com/MatheusAzevedoDev/seu-projeto",
  "status": "wip",
  "docs_updated_at": "",
  "changelog_updated_at": ""
}

Status válidos: active | wip | archived

git checkout -b feat/add-seu-projeto
git add projects/seu-projeto.json
git commit -m "feat: add seu-projeto"
git push origin feat/add-seu-projeto
# abra o PR para main

4. Fluxo de desenvolvimento nos projetos

Todo projeto criado a partir do template segue este fluxo:

feature/foo  ou  bug/foo
       │
       │  push → CI verifica o código
       │          PR automático aberto para develop
       ▼
    develop
       │
       │  merge → PR automático aberto para main
       ▼
     main  (produção)
       │
       │  merge → bump de versão detectado pelos commits
       │          CHANGELOG.md gerado
       │          tag vX.Y.Z criada
       │          release publicada no GitHub
       │          portfolio-hub notificado via repository_dispatch
       ▼
  portfolio-hub atualizado e redeploy automático

Sempre trabalhe em branches com prefixo feature/ ou bug/. A branch develop é criada automaticamente pelo CI na primeira vez que uma dessas branches recebe um push.

5. Conventional Commits

Todos os projetos usam o padrão Conventional Commits.

git commit -m "feat: adiciona endpoint de autenticação"
git commit -m "fix: corrige timeout na conexão com o banco"
git commit -m "feat(auth): adiciona refresh token"
git commit -m "fix(api): retorno 404 incorreto na rota /users"

Tipos reconhecidos

Tipo	Aparece no changelog	Quando usar
`feat`	sim — Features	Nova funcionalidade
`fix`	sim — Bug Fixes	Correção de bug
`perf`	sim — Performance	Melhoria de performance
`docs`	não	Somente documentação
`refactor`	não	Refatoração sem mudança funcional
`test`	não	Testes
`chore`	não	Build, dependências, CI

O escopo entre parênteses é opcional. Use o Commitizen para um assistente interativo:

npm run commit

6. Como o changelog e as releases funcionam

A cada merge em main, o CI detecta o tipo de bump analisando os commits desde a última tag:

Commits contêm	Bump	Exemplo
`tipo!:` ou `BREAKING CHANGE`	major	`1.2.0 → 2.0.0`
`feat:`	minor	`1.2.0 → 1.3.0`
qualquer outro	patch	`1.2.0 → 1.2.1`

Após o bump, o CI automaticamente:

Atualiza a versão no package.json
Regenera o CHANGELOG.md completo
Commita, cria a tag vX.Y.Z e faz push
Publica a release no GitHub com o changelog
Envia um repository_dispatch: project-update ao portfolio-hub

O portfolio-hub recebe o evento e atualiza projects/seu-projeto.json, docs/seu-projeto/ e changelogs/seu-projeto.md automaticamente, disparando um novo deploy.

Mudanças apenas em docs/ ou CHANGELOG.md não disparam o CI de release — sem risco de loop ou sobrescrita.

Gerando o changelog localmente

# Desde o último tag
npm run changelog

# Regenera o arquivo inteiro do zero
npm run changelog:all

Editando manualmente

Para ajustar descrições ou remover ruído, edite e commite somente o CHANGELOG.md:

code CHANGELOG.md
git add CHANGELOG.md
git commit -m "docs: ajusta changelog"
git push

Criando a primeira release (v1.0.0)

Por padrão o projeto começa na versão 0.1.0. Para marcar como 1.0.0, crie a tag manualmente antes do primeiro merge em main:

git tag v1.0.0
git push --tags

A partir daí o CI usa essa tag como base para os bumps automáticos.

7. Referência dos workflows do hub

O portfolio-hub aceita três eventos via repository_dispatch. O project-template usa o project-update (tudo em um). Os outros dois permitem granularidade para repos que preferem separar docs de releases.

`project-update` — tudo em um

Usado pelo project-template. Atualiza metadados, busca docs e changelog em uma única chamada.

Payload:

{
  "event_type": "project-update",
  "client_payload": {
    "project": "nome-do-projeto",
    "display_name": "Nome Exibido",
    "version": "1.2.0",
    "description": "Descrição do projeto",
    "tags": ["Go", "Docker"],
    "repo": "MatheusAzevedoDev/nome-do-projeto"
  }
}

`update-docs` — somente documentação

Ideal para repositórios que atualizam docs com frequência independentemente de releases.

Payload:

{
  "event_type": "update-docs",
  "client_payload": {
    "project": "nome-do-projeto",
    "repo_url": "https://github.com/MatheusAzevedoDev/nome-do-projeto",
    "commit_sha": "abc123",
    "updated_at": "2026-04-21T10:00:00Z"
  }
}

O hub busca todos os arquivos de docs/ no commit especificado e atualiza docs/nome-do-projeto/ e o campo docs_updated_at.

`new-release` — somente release

Ideal para repositórios com processo de release próprio.

Payload:

{
  "event_type": "new-release",
  "client_payload": {
    "project": "nome-do-projeto",
    "display_name": "Nome Exibido",
    "version": "1.2.0",
    "description": "Descrição do projeto",
    "repo_url": "https://github.com/MatheusAzevedoDev/nome-do-projeto",
    "updated_at": "2026-04-21T10:00:00Z"
  }
}

O hub atualiza projects/nome-do-projeto.json e busca o CHANGELOG.md do repositório (ou usa o body da release como fallback).

Checklist — novo projeto

Repo criado a partir do project-template
npm install rodado localmente
Secret PORTFOLIO_TOKEN verificado (herdado da org ou configurado manualmente)
docs/README.md preenchido com visão geral do projeto
docs/architecture.md preenchido com decisões de design
Primeiro commit em uma branch feature/ mergeado até main
Verificar se projects/seu-projeto.json foi criado automaticamente no hub

Referências: Conventional Commits · Semantic Versioning · Keep a Changelog

docs: 21 de abr. de 2026 release: 21 de abr. de 2026

Portfolio Hub

O que o projeto resolve

Estrutura do repositório

Como um projeto aparece no site

1. Metadados (projects/<slug>.json)

2. Documentação (docs/<slug>/)

3. Changelog (changelogs/<slug>.md)

Fluxos de atualização

Fluxo manual

Fluxo automatizado via project-template

Fluxo granular (update-docs / new-release)

Status do projeto

Ícones por frontmatter

Suporte a Mermaid

Resumo operacional

Próximos passos

Arquitetura

Visão geral

Camadas principais

1. Metadados dos projetos

2. Documentação por projeto

3. Changelog por projeto

4. Blog

5. Renderização

Workflows do hub

deploy.yml

changelog.yml

project-update.yml

receive-docs.yml

receive-release.yml

Workflows do project-template

release.yml — lógica de bump

Fluxo de build

Decisões arquiteturais

O hub como agregador, não runtime

Separação entre docs e releases

Git como fonte de verdade

PORTFOLIO_TOKEN como ponte entre repositórios

Sistema visual

Escalabilidade

Setup Guide — Portfolio Hub

Índice

1. Configuração inicial do site

2. Adicionando posts no blog

Criando um post

Campos do frontmatter

Formatação suportada

Publicando

3. Integrando um novo projeto

Passo 1 — Criar o repositório a partir do template

Passo 2 — Configurar o PORTFOLIO_TOKEN

Passo 3 — Clonar e instalar

Passo 4 — (Opcional) Pré-registrar no portfolio-hub

4. Fluxo de desenvolvimento nos projetos

5. Conventional Commits

Tipos reconhecidos

6. Como o changelog e as releases funcionam

Gerando o changelog localmente

Editando manualmente

Criando a primeira release (v1.0.0)

7. Referência dos workflows do hub

project-update — tudo em um

update-docs — somente documentação

new-release — somente release

Checklist — novo projeto

Changelog

[1.0.0] - 2026-04-21

Adicionado

Segurança

Infraestrutura

1. Metadados (`projects/<slug>.json`)

2. Documentação (`docs/<slug>/`)

3. Changelog (`changelogs/<slug>.md`)

Passo 2 — Configurar o `PORTFOLIO_TOKEN`

`project-update` — tudo em um

`update-docs` — somente documentação

`new-release` — somente release