clickupfy-release

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Release do ClickUpfy

ClickUpfy版本发布

Conduza releases reproduzíveis sem criar tags ou alterar versões manualmente. O Release Please é a fonte da versão, do changelog, da tag e da GitHub Release. O GitHub Actions compila e publica os artefatos após a criação da release.

无需手动创建标签或修改版本，即可执行可复现的版本发布流程。Release Please是版本号、变更日志、标签及GitHub Release的来源。GitHub Actions会在版本发布创建后编译并发布制品。

Cobertura documental da release

版本发布文档覆盖要求

Confira se todo comando, parâmetro, ferramenta MCP e comportamento público da versão está explicado em

docs/user/

. O manual precisa detalhar entradas, saídas, permissões, efeitos persistentes, limitações da API e cinco exemplos diferentes por comando ou ferramenta. Leia também

docs/user/reading-order.txt

para confirmar que cada capítulo aparece uma vez no PDF e no EPUB.

Quando houver mudança documental, confirme

ebook/VERSION

, execute

npm run ebook

, execute

npm run ebook:verify

e publique os artefatos que o manifesto resultante declarar. Não libere versão cujo texto de ajuda tenha mudado sem a referência correspondente no manual.

请确认版本中的每个命令、参数、MCP工具及公开行为都已在

docs/user/

中说明。手册需详细描述输入、输出、权限、持久化影响、API限制，且每个命令或工具需提供5个不同示例。同时请阅读

docs/user/reading-order.txt

，确认每个章节在PDF和EPUB中仅出现一次。

当文档发生变更时，请确认

ebook/VERSION

，执行

npm run ebook

，运行

npm run ebook:verify

，并发布最终清单中声明的制品。若帮助文本发生变更但手册中未添加对应引用，请勿发布版本。

Antes de começar

前期准备

Trabalhe dentro do repositório independente
```
clickupfy/
```
.
Leia
```
RELEASING.md
```
e confira
```
git status --short
```
.
Preserve mudanças locais que não pertençam à release.
Execute
```
npm ci
```
quando as dependências ainda não estiverem instaladas.
Não crie uma tag nem edite a versão diretamente, salvo em uma recuperação explicitamente autorizada.

在独立仓库
```
clickupfy/
```
内开展工作。
阅读
```
RELEASING.md
```
并检查
```
git status --short
```
状态。
保留不属于本次版本发布的本地变更。
若依赖尚未安装，执行
```
npm ci
```
。
除非是明确授权的故障恢复场景，否则请勿直接创建标签或编辑版本号。

Preparar mudanças

准备变更内容

Use Conventional Commits. O Release Please determina a próxima versão pelo histórico desde a última release:

```
fix:
```
propõe patch;
```
feat:
```
propõe minor;
```
feat!:
```
ou
```
BREAKING CHANGE:
```
propõe major;
```
docs:
```
,
```
build:
```
,
```
ci:
```
e
```
refactor:
```
entram no changelog sem forçar uma versão maior que as mudanças funcionais presentes.

Antes de enviar as mudanças:

bash

npm run validar

O comando verifica tipos, testes, build, versões, manifesto, changelog e presença do workflow.

使用Conventional Commits规范。Release Please会根据上次版本发布后的提交历史确定下一个版本号：

```
fix:
```
提议补丁版本（patch）；
```
feat:
```
提议次版本（minor）；
```
feat!:
```
或
```
BREAKING CHANGE:
```
提议主版本（major）；
```
docs:
```
、
```
build:
```
、
```
ci:
```
及
```
refactor:
```
会被纳入变更日志，但不会强制提升版本号至高于现有功能性变更对应的版本。

推送变更前，请执行：

bash

npm run validar

该命令会检查类型、测试、构建、版本号、清单、变更日志及工作流是否存在。

Publicar uma release

发布版本

Faça push dos Conventional Commits para
```
main
```
.
Aguarde o workflow
```
Release
```
criar ou atualizar a Release PR.
Revise na PR a versão proposta e o
```
CHANGELOG.md
```
.
Faça merge da Release PR.
Acompanhe a mesma execução do workflow até estes resultados:
- tag imutável
```
vMAJOR.MINOR.PATCH
```
  ;
- GitHub Release;
- executáveis Linux x64, macOS x64, macOS arm64 e Windows x64;
- pacote
```
@promovaweb/clickupfy
```
  publicado no registry npm;
- o mesmo pacote npm em arquivo
```
.tgz
```
  na GitHub Release;
- ```
SHA256SUMS
```
  ;
- attestations de proveniência quando o repositório for público.

Não rode

git tag

nem

gh release create

no fluxo normal.

将符合Conventional Commits规范的提交推送到
```
main
```
分支。
等待
```
Release
```
工作流创建或更新版本发布PR。
在PR中审核提议的版本号及
```
CHANGELOG.md
```
。
合并该版本发布PR。
跟踪同一工作流的执行，直至完成以下结果：
- 不可变标签
```
vMAJOR.MINOR.PATCH
```
  ；
- GitHub Release；
- Linux x64、macOS x64、macOS arm64及Windows x64平台的可执行文件；
- 在npm registry发布
```
@promovaweb/clickupfy
```
  包；
- GitHub Release中包含同一份npm包的
```
.tgz
```
  文件；
- ```
SHA256SUMS
```
  校验文件；
- 当仓库为公开状态时，生成来源证明。

正常流程中请勿执行

git tag

或

gh release create

命令。

Validar localmente

本地验证

Valide a coerência da versão atual:

bash

npm run release:check
npm run release:check -- v0.1.0

O segundo comando só deve usar a tag correspondente à versão atual. Gere e teste o executável da plataforma local:

bash

npm run build:executable
./artifacts/clickupfy-v0.1.0-linux-x64/clickupfy --version

Adapte o nome do artefato à versão, plataforma e arquitetura exibidas pelo script.

验证当前版本的一致性：

bash

npm run release:check
npm run release:check -- v0.1.0

第二条命令仅应使用与当前版本对应的标签。生成并测试本地平台的可执行文件：

bash

npm run build:executable
./artifacts/clickupfy-v0.1.0-linux-x64/clickupfy --version

请根据脚本显示的版本、平台及架构调整制品名称。

Diagnosticar falhas

故障排查

Release PR ausente: confira os gatilhos do workflow, as permissões de Actions e se há Conventional Commits depois do
```
bootstrap-sha
```
ou da última tag.
CI não executou na Release PR: configure o secret opcional
```
RELEASE_PLEASE_TOKEN
```
, conforme
```
RELEASING.md
```
.
Release criada sem binários: reexecute os jobs falhos da mesma execução.
Publicação npm falhou: confirme o secret
```
NPM_TOKEN
```
e reexecute o job; o script ignora uma versão que já exista no registry.
Artefato inválido: reproduza com
```
npm ci
```
,
```
npm run validar
```
e
```
npm run build:executable
```
na plataforma afetada.
Versão divergente: não corrija somente um arquivo. Inspecione
```
package.json
```
,
```
package-lock.json
```
,
```
.release-please-manifest.json
```
,
```
CHANGELOG.md
```
e a tag.

缺少版本发布PR：检查工作流触发器、Actions权限，以及
```
bootstrap-sha
```
或上次标签之后是否有符合Conventional Commits规范的提交。
版本发布PR未执行CI：按照
```
RELEASING.md
```
配置可选密钥
```
RELEASE_PLEASE_TOKEN
```
。
版本发布已创建但无二进制文件：重新执行同一工作流中失败的任务。
npm发布失败：确认
```
NPM_TOKEN
```
密钥并重新执行任务；脚本会忽略registry中已存在的版本。
制品无效：在受影响平台上通过
```
npm ci
```
、
```
npm run validar
```
及
```
npm run build:executable
```
复现问题。
版本号不一致：请勿仅修改单个文件。检查
```
package.json
```
、
```
package-lock.json
```
、
```
.release-please-manifest.json
```
、
```
CHANGELOG.md
```
及标签。

Recuperar uma release

版本发布恢复

Não mova nem reutilize uma tag publicada. Para erro no código, envie um Conventional Commit corretivo e publique uma nova patch release. Para arquivo ausente ou job interrompido, reexecute o workflow no commit tagueado; o upload usa substituição idempotente para os nomes daquela mesma release.

Só use operações manuais do GitHub CLI quando a automação não puder ser recuperada e houver autorização explícita. Registre no handoff o motivo, a tag, os arquivos substituídos e as validações executadas.

请勿移动或复用已发布的标签。若代码存在错误，请提交符合Conventional Commits规范的修复提交并发布新的补丁版本。若缺少文件或任务中断，请在已打标签的提交上重新执行工作流；上传操作会对同一版本发布的文件名执行幂等替换。

仅当自动化无法恢复且获得明确授权时，才可使用GitHub CLI执行手动操作。请在交接记录中注明原因、标签、替换的文件及执行的验证操作。