Back to Details

publicar

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Publicar

发布

Leé 
blueprint/50-despliegue.md
y seguilo.
Antes de arrancar hay dos condiciones, y son distintas: una mira el disco y la otra mira lo que git entrega.
阅读
blueprint/50-despliegue.md
并按照其中步骤操作。
开始前有两个条件，二者有所不同：一个检查本地磁盘内容，另一个检查git提交的内容。

1 · La compuerta en 
pass

1 · 状态为
pass
的检查门

Corré 
/revisar
. Se despliega con 
pass
y con nada más.
fail
es obvio. 
parcial
no: el reporte no encontró nada, y eso es distinto de que no haya nada. Quiere decir que un chequeo que en este árbol tenía que correr no corrió —falta 
jsonschema
, falta el 
.venv
, falta una dependencia— y el que saltea siempre incluye 
contrato-control
, que es el control negativo de la validación entera. Con ese salteado, un reporte en verde no distingue "validé y está bien" de "no validé nada". Corré la compuerta con el 
.venv
del proyecto, mirá el motivo que imprime cada salteado y volvé cuando diga 
pass
.
运行
/revisar
。部署仅在状态为
pass
时进行，其他情况均不允许。
fail
的含义很明确。
parcial
则不然：报告未检测到任何内容，这与“没有内容”是两回事。它表示本应在当前代码树中运行的某项检查未执行——可能缺少
jsonschema
、
.venv
或某个依赖项——而跳过的检查始终包含
contrato-control
，即整个验证流程的反向控制项。由于存在这种跳过情况，绿色报告无法区分“已验证且正常”和“未进行任何验证”两种状态。请使用项目的
.venv
运行检查门，查看每次跳过操作输出的原因，直到状态显示为
pass
再继续。

2 · El índice de git trae el árbol entero

2 · git索引包含完整代码树

pass
dice que el árbol del disco está completo. No dice nada de lo que viaja. Las dos cuentas:
bash
git ls-files | wc -l                              # lo que entrega un git clone
git ls-files --others --exclude-standard | wc -l  # lo que está en el disco y no viaja
Corridas sobre el árbol donde se escribió esta skill, el 2026-08-14, dieron esto:
       9
      73
Nueve archivos versionados y setenta y tres afuera del índice: 
blueprint/
entero, las diez skills de 
.claude/
y su 
settings.json
, los tres de 
scripts/
—la compuerta incluida—, 
plantillas/
con el núcleo verbatim, 
pruebas/
, 
PINES.md
. Un clon de eso no puede construir nada, y la compuerta corrida sobre el disco da 
pass
igual, porque el disco sí está completo. Las dos cosas son ciertas a la vez, y por eso hay que preguntar las dos.
Estas dos cuentas miran el árbol entero. La compuerta mide lo mismo con otra vara, sólo sobre el núcleo: 52 archivos, 3 rastreados. Es el mismo agujero.
La condición es que la segunda cuenta dé cero. Todo lo que no está ignorado a propósito está en el índice. Lo ignorado a propósito tiene su motivo escrito al lado en 
.gitignore
: 
.env
y las claves, lo que escribe la construcción —
/agente/
, 
/panel/
, el 
Dockerfile
, el 
railway.json
—, 
/knowledge/
y 
/config/playbook-base.yaml
. Nada más.
Cuando no da cero, no se publica. En este orden:
  1. Mostrá la lista entera, sin recortar. Es exactamente lo que le falta al clon.
    bash
    git ls-files --others --exclude-standard
  2. Mirá que no haya un secreto adentro del índice.
    bash
    git ls-files | grep -E '(^|/)\.env|\.pem$|service-account'
    Si esto imprime algo, se para todo acá y no se publica nada. Hay una credencial versionada, y eso no se arregla con un commit más: hay que sacarla del historial y rotar la clave. Es el invariante 4, y es el único caso de esta sección donde el arreglo no es agregar archivos. Sin salida, seguí.
  3. Proponé el arreglo y esperá el sí. Ni 
    git add
    ni 
    git commit
    salen sin que quien publica los confirme.
    bash
    git add -A
git status --short
    El 
    status
    va entre el 
    add
    y el commit a propósito: es la última vez que se puede mirar qué quedó adentro. Si aparece algo que no esperabas —material que subiste a 
    knowledge/
    , un volcado de la base, una carpeta de otro autor—, el arreglo es 
    .gitignore
    y 
    git restore --staged
    , no el commit.
  4. Commiteá y volvé a contar. Con la segunda cuenta en cero, seguí con el despliegue.
Lo tocado y sin commitear no frena nada, y se dice igual. 
git status --porcelain
con líneas 
M
no impide desplegar —
railway up
sube el directorio, no el commit— pero deja el clon distinto del árbol que auditaste. Decí cuántos archivos son y dejá que decida quien publica.
Si el árbol no es un repo de git, esto no se puede verificar. Decilo con esas palabras y seguí: el despliegue anda igual, y lo que no hay es de dónde volver a sacar el kit.
La compuerta ya lo ve, y no lo frena. Sale adentro del chequeo 09, que queda en 
[ok]
con un aviso al lado:
  [ok      ] 09 gitignore-anclado  52 archivos del núcleo: 3 rastreados, 49 sin rastrear · 6 carpeta(s) y ruta(s)
      [aviso] gitignore/nucleo_sin_rastrear .gitignore:0   49 de 52 archivos del núcleo verbatim
      están **sin rastrear**: git no los tiene en el índice, así que hoy no salen en ningún clon.
Veredicto 
PASS
, salida 0. Un aviso no frena la compuerta: la frena esta sección. Si en tu kit ese hallazgo ya sale como error, mejor —
/revisar
te para antes y acá no hay nada que hacer—. Mientras salga como aviso, 
pass
no dice nada del índice.
pass
仅表示本地磁盘的代码树是完整的，但不代表提交的内容完整。请执行以下两个统计命令：
bash
git ls-files | wc -l                              # git clone会获取的文件数量
git ls-files --others --exclude-standard | wc -l  # 本地磁盘存在但未提交的文件数量
在编写本skill的代码树上运行这些命令（2026-08-14），结果如下：
       9
      73
9个已版本控制的文件，73个未纳入索引的文件：包括整个
blueprint/
目录、
.claude/
下的10个skill及其
settings.json
、
scripts/
下的3个文件（包括检查门）、包含核心代码的
plantillas/
目录、
pruebas/
目录、
PINES.md
。这样的代码克隆无法构建任何内容，而本地磁盘上运行的检查门仍会显示
pass
，因为本地磁盘内容是完整的。这两种情况同时存在，因此需要同时检查这两项。
这两个统计命令针对整个代码树。检查门则用另一种方式统计核心代码：52个文件中仅3个被追踪。问题本质相同。
要求是第二个统计结果为0。所有未被特意忽略的内容都必须纳入索引。被特意忽略的内容在
.gitignore
中有对应的说明：
.env
和密钥文件、构建生成的内容——
/agente/
、
/panel/
、
Dockerfile
、
railway.json
——、
/knowledge/
和
/config/playbook-base.yaml
。除此之外不得有其他未提交内容。
若第二个统计结果不为0，禁止发布。请按以下顺序操作：
  1. 完整列出所有未提交文件，不要截断。这正是克隆版本缺失的内容。
    bash
    git ls-files --others --exclude-standard
  2. 检查索引中是否包含机密文件。
    bash
    git ls-files | grep -E '(^|/)\.env|\.pem$|service-account'
    如果该命令输出内容，立即停止所有操作，禁止发布。这意味着存在已版本化的凭证，这种情况无法通过追加提交修复：必须从历史记录中移除该凭证并轮换密钥。这是第4项不变规则，也是本节中唯一不需要添加文件的修复场景。若没有输出，请继续。
  3. 提出修复方案并等待确认。未经发布者确认，不得执行
    git add
    或
    git commit
    。
    bash
    git add -A
git status --short
    在
    add
    和
    commit
    之间运行
    status
    是有意为之：这是最后一次查看纳入索引内容的机会。如果出现意外内容——例如上传到
    knowledge/
    的资料、数据库导出文件、其他作者的目录——修复方式是添加到
    .gitignore
    并执行
    git restore --staged
    ，而非直接提交。
  4. 提交并重新统计。当第二个统计结果为0时，继续部署流程。
已修改但未提交的内容不会阻止部署，但需明确告知。
git status --porcelain
显示的
M
行不会阻止部署——
railway up
会上传整个目录而非提交内容——但会导致克隆版本与你审核的代码树不一致。请告知文件数量，由发布者决定如何处理。
若代码树不是git仓库，则无法进行上述验证。请明确告知这一点并继续：部署仍可正常进行，但无法从版本库中重新获取工具包。
检查门已检测到该情况，但不会阻止流程。该情况会在09号检查中显示为
[ok]
并附带提示：
  [ok      ] 09 gitignore-anclado  52 archivos del núcleo: 3 rastreados, 49 sin rastrear · 6 carpeta(s) y ruta(s)
      [aviso] gitignore/nucleo_sin_rastrear .gitignore:0   49 de 52 archivos del núcleo verbatim
      están **sin rastrear**: git no los tiene en el índice, así que hoy no salen en ningún clon.
判定结果为
PASS
，退出码0。提示不会阻止检查门：但本节内容会阻止部署。如果你的工具包中该检测结果已显示为错误，那更好——
/revisar
会提前终止流程，无需进行本节操作。只要提示仍存在，
pass
就无法说明索引的完整性。

Después

后续步骤

Preguntá dónde: local o Railway. En Railway la base es Postgres, y 
asyncpg
tiene que estar fijado en 
PINES.md
. Con SQLite anda perfecto y no se nota, así que esto revienta recién en el primer despliegue, con un 
ModuleNotFoundError
que no nombra a nadie.
Después, el alta del webhook. Con 
meta
, la verificación es un GET que responde el 
hub.challenge
como texto plano, nunca como JSON. Con 
zernio
, el handler contesta 2xx en menos de 5 segundos o el evento vuelve, hasta siete veces.
Ninguna credencial se escribe desde acá. Los valores los pone quien instala, en 
.env
.
询问部署位置：本地或Railway。在Railway上使用Postgres数据库，必须在
PINES.md
中固定
asyncpg
版本。使用SQLite则完全正常，无任何影响，因此该问题只会在首次部署时暴露，表现为
ModuleNotFoundError
错误。
接下来是webhook注册。使用
meta
时，验证请求是GET请求，需以纯文本形式返回
hub.challenge
，绝不能以JSON形式返回。使用
zernio
时，处理器需在5秒内返回2xx状态码，否则事件会重复触发，最多七次。
此处不会写入任何凭证。相关值由安装者在
.env
中设置。