Lanzamiento de OxideTerm

Publicar un lanzamiento de OxideTerm a través de la automatización del repositorio. Trata la ejecución completada de la interfaz gráfica por parte del usuario como la puerta de lanzamiento y no ejecutes pruebas de Cargo por defecto.

Entrada requerida para el lanzamiento

Resuelve estos valores antes de realizar cambios de lanzamiento:

Versión objetivo.
Canal objetivo: stable, beta o gpui-preview.
Confirmación explícita de que el usuario ejecutó la aplicación GUI y aprobó la publicación.
Nivel de detalle de las notas de lanzamiento cuando el usuario solicite explícitamente minimal, medium o detailed; de lo contrario, usa detailed.

Infiera el canal solo cuando la versión no sea ambigua. Pregunta antes de publicar si falta la aprobación GUI. Preparar un registro de cambios o un ensayo seco no requiere aprobación.

Contrato del canal

Canal	Versión	Etiqueta	Registro de cambios	Notas base
Stable	`X.Y.Z`	`vX.Y.Z`	`.github/release-notes/stable-changelog.md`	`.github/release-notes/stable.md`
Beta	`X.Y.Z-beta.N`	`vX.Y.Z-beta.N`	`.github/release-notes/beta-changelog.md`	`.github/release-notes/beta.md`
Vista previa GPUI	`X.Y.Z-gpui-preview.N`	`gpui-vX.Y.Z-gpui-preview.N`	`.github/release-notes/gpui-preview-changelog.md`	`.github/release-notes/gpui-preview.md`

No inventes otro prefijo de etiqueta. El flujo de trabajo nativo del paquete recibe la etiqueta existente a través de su entrada de envío release_tag y selecciona las notas de lanzamiento de esa etiqueta.

Flujo de trabajo

1. Inspeccionar el estado del repositorio

Trabaja desde la raíz del repositorio de OxideTerm. Lee AGENTS.md, luego inspecciona:

git status --short --branch
git remote -v
git log -10 --oneline --decorate

Obtén el remoto de publicación y las etiquetas antes de decidir que una etiqueta está disponible:

git fetch origin --tags

Confirma que la rama no está detrás o divergida de su upstream, e inspecciona la etiqueta objetivo local y remotamente:

git rev-list --left-right --count HEAD...@{upstream}
git tag --list <tag>
git ls-remote --tags origin refs/tags/<tag> refs/tags/<tag>^{}

Conserva los cambios no relacionados del usuario. Detente si el alcance del lanzamiento previsto no puede separarse de manera segura o la rama ha divergido. Para un lanzamiento ordinario, detente cuando la etiqueta objetivo exista. Solo mueve una etiqueta existente a través del procedimiento explícito de recuperación de lanzamiento cancelado a continuación.

2. Establecer el rango del registro de cambios

Ejecuta el asistente incluido antes de escribir el registro de cambios:

python3 .agents/skills/oxideterm-release/scripts/release_context.py \
  --repo . --channel <channel> --version <version>

Prefiere la etiqueta anterior alcanzable del mismo canal como línea base:

Stable se compara con la etiqueta stable anterior.
Beta se compara con la etiqueta beta anterior.
La vista previa GPUI se compara con la etiqueta de vista previa GPUI anterior.

Para el primer lanzamiento en un canal, usa la etiqueta de lanzamiento alcanzable más nueva de cualquiera de los tres canales como línea base de arranque. Usa el commit raíz solo cuando el repositorio no tenga una etiqueta de lanzamiento alcanzable anterior. Esto mantiene un primer registro de cambios beta o de vista previa limitado al trabajo desde el lanzamiento anterior real en lugar de resumir todo el repositorio.

El asistente imprime el rango exacto, los commits y el resumen de diferencias. También inspecciona los cambios reales, incluidos los cambios no comprometidos previstos:

git diff <previous-tag>..HEAD
git diff
git diff --cached

No derives las notas de lanzamiento solo de los asuntos de los commits. Lee las diferencias significativas de implementación y las diferencias visibles para el usuario. Excluye los incrementos de versión mecánicos, las ediciones de registro de cambios, los cambios de solo formato y los detalles internos que no tienen impacto en el lanzamiento.

Resolver solicitudes de extracción y contribuyentes

Para cada canal de lanzamiento, mapea los cambios en el rango exacto de lanzamiento a sus solicitudes de extracción originales antes de redactar las notas. La lista de commits del asistente excluye los commits de fusión; inspecciona el historial de fusiones y las asociaciones de commit a PR de GitHub también para que las fusiones de merge, squash y rebase reciban atribución:

git log --format='%H %s' <previous-tag>..<target-ref>
gh api --paginate repos/<owner>/<repo>/commits/<commit-sha>/pulls \
  --jq '.[] | {number, title, url: .html_url, author: .user.login, merged_at, merge_commit_sha}'
gh pr view <number> --repo <owner>/<repo> \
  --json number,title,url,author,mergedAt,mergeCommit,commits

Mantén un mapeo de trabajo del número, URL, inicio de sesión del autor y contribución real de cada PR incluido. Deduplica los PR devueltos para múltiples commits. Confirma la inclusión contra el historial y las diferencias objetivo; las fechas de fusión por sí solas no establecen el alcance del lanzamiento. Verifica la procedencia original del PR para los cambios cherry-picked. Los cambios completamente revertidos no deben presentarse como funciones enviadas.

Usa el autor del PR, no la persona o bot que lo fusionó. Para agradecimientos a contribuyentes, excluye a los mantenedores confirmados del proyecto y cuentas de bot; no asumas que un contribuyente humano es un mantenedor simplemente porque GitHub los etiqueta como COLLABORATOR o MEMBER. Mantén el crédito por el trabajo de PR externo cuando el mantenedor realizó correcciones de seguimiento. Un número de problema referenciado no es evidencia de un PR o su autor. Si la búsqueda de GitHub falla, mantén la atribución no resuelta en notas de trabajo y resuélvela antes de finalizar las notas de lanzamiento; no interpretes la falla de búsqueda como que no hay contribuciones.

3. Escribir el registro de cambios del canal

Inserta ## <version> como la entrada más nueva en el registro de cambios seleccionado. El encabezado debe coincidir exactamente con la versión porque .github/scripts/compose_release_notes.py lo usa para localizar la entrada. El encabezado es un límite de extracción, no necesariamente parte del cuerpo del lanzamiento publicado.

Escribe cada entrada de versión como dos bloques de idioma completos en este orden (chino primero, inglés segundo). El compositor agrega enlaces de salto de idioma en la parte superior de las notas de lanzamiento bilingües para cada canal:

## <version>

### 中文

<Resumen y secciones en chino>

### English

<Resumen y secciones en inglés>

Mantén ambos bloques estructuralmente alineados: deben describir los mismos resultados, limitaciones, estado de validación y requisitos de actualización en el mismo orden. Traduce para obtener un lenguaje natural de notas de lanzamiento en lugar de palabra por palabra, y mantén los nombres de productos, comandos, nombres de archivos y nombres de protocolo sin cambios cuando la traducción reduciría la precisión. No mezcles inglés y chino en el mismo punto. Usa tiempo pasado conciso orientado al usuario en inglés y redacción de acción completada concisa en chino. Mantén cada párrafo de resumen de apertura de cada idioma en una línea física para que el editor de GitHub Release no muestre una rotura artificial. Combina commits relacionados en un resultado y evita volcados de títulos de commits sin procesar, trivialidades de implementación, afirmaciones de rendimiento no respaldadas y afirmaciones que no fueron verificadas. Usa un emoji moderado y semánticamente relevante en cada encabezado de sección principal de lanzamiento estable en ambos bloques; no decores cada punto ni mezcles múltiples estilos de emoji dentro de una sección.

Para un lanzamiento de fork, cada bloque de idioma debe separar claramente los cambios heredados del upstream oficial de OxideTerm de los cambios implementados por el fork. Usa encabezados localizados explícitos equivalentes a Upstream changes / 上游更新 y Fork-specific changes / Fork 自有更新; los encabezados de subsistema pueden anidarse debajo de ellos cuando el nivel de detalle seleccionado lo justifique. Clasifica el trabajo oficial fusionado o cherry-picked como upstream independientemente del autor del commit, y clasifica el comportamiento exclusivo del fork de publicación como específico del fork. Cuando un fork modifica una función del upstream, describe la capacidad heredada bajo upstream y el delta material del fork bajo cambios específicos del fork. Si alguna categoría no tiene cambios en el rango de lanzamiento, indícalo explícitamente en lugar de omitir la categoría. Nunca permitas que un resumen o punto combinado implique que el fork creó trabajo del upstream.

Referencias de PR y agradecimientos a contribuyentes

Sigue el patrón de atribución en NyaTerm v1.2.12: referencias de PR junto a los cambios que introdujeron, más una sección dedicada de contribuyentes. Deriva las entradas reales del rango de lanzamiento de OxideTerm.

Agrega números de PR vinculados a cada elemento de nota de lanzamiento introducido a través de un PR, incluidos los PR de mantenedores. Usa （PR [#<number>](<pr-url>)） en chino y (PR [#<number>](<pr-url>)) en inglés. Coloca la referencia al final del punto o párrafo de función relevante, en lugar de solo en la lista de contribuyentes o el enlace completo del registro de cambios. Mantén los enlaces de problemas distintos de los enlaces de PR. Los commits directos no tienen un número de PR inventado.
Cuando varios PR contribuyeron a un elemento agrupado, incluye todos los números de PR relevantes una vez en ese elemento. Atribuye solo el resultado respaldado por cada PR; separa un cambio de seguimiento independiente de un mantenedor cuando la agrupación acreditaría al autor incorrecto. Para PR de otro repositorio, califica la etiqueta del enlace con owner/repo#number.
Siempre que el lanzamiento incluya contribuciones de PR externas, agrega #### 👥 贡献者 dentro del bloque en chino y #### 👥 Contributors dentro del bloque en inglés, después de las secciones de cambios y antes de las notas de actualización cuando estén presentes. Agradece a cada autor de PR externo cuya contribución esté incluida en este lanzamiento, incluidos los contribuyentes recurrentes y los contribuyentes de documentación, traducción, compilación o empaquetado cuyo trabajo puede no justificar un punto de función independiente.
Enumera cada autor una vez por bloque de idioma usando su @login verificado de GitHub, una breve descripción de su contribución y números de PR vinculados. Coincide los autores y las referencias de PR en ambos idiomas. Un agradecimiento genérico o la tira de avatar automática de GitHub no reemplazan estas entradas. Si identificas contribuyentes por primera vez, verifica las contribuciones previas al repositorio; una lista de New Contributors complementa la sección completa de agradecimientos.
Aplica la atribución en cada nivel de detalle y en cada canal. Si el rango verificado no contiene ninguna contribución de PR externa, omite la sección de contribuyentes en lugar de agregar un encabezado vacío. Un PR fuera del rango de lanzamiento no se acredita como una nueva contribución a esta versión.

Ejemplos de entradas de contribuyentes (reemplaza los marcadores de posición con datos de lanzamiento verificados):

#### 👥 贡献者

感谢以下外部贡献者参与本次更新：

- @<login>：<具体贡献>（PR [#<number>](<pr-url>)）。

#### 👥 Contributors

Thank you to the external contributors to this release:

- @<login>: <specific contribution> (PR [#<number>](<pr-url>)).

Coloca las dos secciones de ejemplo en sus respectivos bloques de idioma, no juntas como una tercera sección bilingüe.

Nivel de detalle de las notas de lanzamiento

Usa el mismo nivel para los bloques en inglés y chino. Los niveles controlan la cobertura y la agrupación, no un recuento obligatorio de palabras. Nunca omitas un cambio disruptivo, un límite de seguridad, un requisito de actualización, una limitación conocida o un problema de compatibilidad material solo para cumplir con un nivel más corto.

Nivel	Densidad requerida
`minimal`	Úsalo solo cuando el usuario lo solicite explícitamente. Escribe un resumen breve seguido de aproximadamente 2 a 5 puntos de resultado altamente consolidados, con como máximo uno o dos encabezados cuando mejoren materialmente el escaneo. Cubre solo los cambios definitorios visibles para el usuario y las advertencias requeridas.
`medium`	Úsalo solo cuando el usuario lo solicite explícitamente. Escribe un resumen, un pequeño número de secciones útiles y puntos agrupados que cubran las características principales, correcciones y resultados de seguridad o compatibilidad. Consolida los flujos de trabajo de soporte relacionados en lugar de enumerar cada uno por separado.
`detailed`	Predeterminado a menos que el usuario elija explícitamente otro nivel. Organiza las notas por subsistema o flujo de trabajo significativo y da a cada capacidad distinta visible para el usuario, cambio de comportamiento, corrección de compatibilidad, limitación compatible y resultado de rendimiento o validación verificado suficiente espacio para ser entendido sin leer el diff. Incluye flujos de trabajo de soporte cuando afecten materialmente cómo los usuarios entienden o usan el cambio, pero no agregues relleno cuando un lanzamiento tenga pocos cambios reales.

Trata los niveles como guía de cobertura y agrupación, no como plantillas fijas. Determina primero el delta factual completo, luego consolídelo al nivel seleccionado. Si el usuario dice solo "escribe las notas de lanzamiento" o "prepara el lanzamiento", usa detailed.

Aplica énfasis específico del canal:

Stable: Resume el delta completo desde la etiqueta stable anterior. En cada bloque de idioma, comienza con un breve resumen de lanzamiento, luego usa solo secciones útiles como #### ✨ Highlights / #### ✨ 重点更新, #### 🛠️ Fixes / #### 🛠️ 修复, #### 🔒 Security / #### 🔒 安全, o #### 🧰 Release Maintenance / #### 🧰 发布维护. Enfatiza el comportamiento visible para el usuario y la compatibilidad. El cuerpo compuesto de GitHub Release debe comenzar con navegación [中文](#中文) | [English](#english), seguido del bloque completo ### 中文 y luego el bloque ### English coincidente. Omite tanto un encabezado principal del producto como # OxideTerm 2.0 como un encabezado de versión repetido como ## 2.0.7. Luego coloca ## 📥 Download for your system, consejos de instalación y enlaces después de ambos bloques de idioma.
Beta: Resume el delta desde la etiqueta beta anterior en bloques completos en inglés y chino. Indica qué se acerca a estable, qué cambió y qué flujos de trabajo necesitan validación. Menciona limitaciones conocidas solo cuando sean compatibles con el diff o el contexto del problema, e inclúyelas en ambos idiomas.
Vista previa GPUI: Resume el delta desde la etiqueta de vista previa GPUI anterior en bloques completos en inglés y chino. Concéntrate en el trabajo de IU/tiempo de ejecución nativo recién comprobable, paridad, bordes ásperos y objetivos de prueba concretos. Aplica el nivel de detalle seleccionado mientras mantienes la escritura orientada a pruebas en lugar de convertir las notas de vista previa en marketing de lanzamiento estable.

Si no hay una etiqueta anterior para ese canal, indica qué etiqueta de lanzamiento anterior se usó como línea base de arranque.

4. Ejecutar el script de versión del repositorio

Siempre usa el script del repositorio; nunca edites manualmente la versión del espacio de trabajo o el archivo de bloqueo:

python3 scripts/release/bump_version.py <version>

Esto valida SemVer, actualiza [workspace.package] y actualiza Cargo.lock sin conexión. Las insignias de README muestran el último lanzamiento de GitHub automáticamente y no necesitan ediciones de versión.

5. Realizar validación ligera del lanzamiento

No ejecutes cargo test

AnalyseDeCircuit/oxideterm

¿Qué es oxideterm?

Preguntar en tu IA favorita

Documentación