f10 · ship

¿Qué hace f10 · ship?

Ejecutar esta habilidad es la autorización explícita del usuario para hacer push y abrir o actualizar el PR de esta tarea (el paso pr), satisfaciendo la regla global "nunca hacer push / abrir un PR a menos que se solicite" solo para ese PR, y para publicar el +reply de resolución, hacer push de las correcciones de resolución a ese PR, publicar el f10 review ack de la revisión y, para una revisión de CI en el flujo, su f10 review trigger (cuando la sección de Revisión declara un manual de cómo leer) y el f10 review settle de resolución, para una entrada de juez después de pr, hacer push de la integración del guardia de catch-up y sus propios cambios a ese PR y publicar su estado y comentario, y publicar el comentario de informe y estado de la ejecución en la tarea (Reportar de vuelta). Desplegar tiene su propia confirmación (el paso deploy).

Argumentos

• --help: sigue ${CLAUDE_PLUGIN_ROOT}/modes/help.md y detente; nada de lo siguiente aplica.
• --dry-run: sigue ${CLAUDE_PLUGIN_ROOT}/modes/dry-run.md en lugar de ejecutar cualquier cosa, y detente. Reporta qué pasos ejecutaría el resto del argumento.
• --driven: sigue ${CLAUDE_PLUGIN_ROOT}/modes/driven.md; todo lo siguiente aún se ejecuta.
• Un nombre de flujo como palabra (/f10:ship direct: fix typo …; f10 start --local envía /f10:ship local: <id>, --flow <name> envía <name>:), o nombrado en las propias palabras del usuario: ejecuta ese flujo. De lo contrario, el flujo que el flow_by_area del frontmatter asigna al área de la tarea (las áreas del resumen de obtención, si no, la línea Areas del plan), si no default. Dos áreas que mapean a diferentes flujos: gana el área del entregable, como para los Roles, y el resumen nombra la otra. El mapa de áreas es elección del proyecto, no tuya: nunca selecciones otro flujo por tu cuenta, aunque para trabajo pequeño puedas sugerir uno. Nombra el flujo que un área eligió, y el área, en una línea antes del primer paso.
• --pace <name>: ejecuta el flujo a ese ritmo solo para esta ejecución (Paces, abajo); sin él, el ritmo que registra la rama, si no, el pace: del proyecto o del usuario.
• <plan.md>: un archivo de plan; ejecuta el flujo con él.
• <task-id> (formato de id de proyecto / id / url), o un lote unido por + (ABC-1+ABC-2, claveado en el principal): sigue primero ${CLAUDE_PLUGIN_ROOT}/modes/forward.md, antes de cargar cualquier cosa; detente si redirige la tarea. De lo contrario, ejecuta el paso fetch, luego busca <storage root>/plans/<TASK-ID>.md (el principal de un lote) (busca en el directorio de planes si el nombre exacto falla). Encontrado: reutilízalo, nunca preguntes; una tarea con un archivo de plan nunca planifica de nuevo, y replanificar es /f10:plan <id> manualmente. Falta: bajo stale_after, fetch juzga una tarea antigua primero y puede terminar la ejecución bloqueada antes de cualquier plan o entrada de flujo (anyway en la dirección lo salta); luego ejecuta el paso plan cuando el flujo comienza con plan (con flow_by_area, start y drive dejan la planificación a ship); un flujo sin plan (abajo) nunca lo ejecuta, y el resumen de obtención se convierte en el plan en línea. Luego el flujo.
• <description>: texto libre; los pasos capture, fetch y plan, luego el flujo.
• Sin argumento (las banderas o una sola palabra de flujo cuentan como ninguno; una descripción es texto libre, arriba): una tarea ya en esta conversación (un plan recién guardado, una tarea obtenida), si no, la tarea de la rama, el id que f10 task current imprime. Di en una línea qué tarea tomaste y de dónde, luego ejecútala como <task-id>, incluido el modo de redirección, para que un plan guardado sea reutilizado. f10 task current sale con código distinto de cero: pide una tarea en una línea y espera (driven: una petición, según modes/driven.md).
• Texto adicional junto al asunto es dirección. resume at <entry> (enviado por f10 drive una vez que un catch-up resolvió la parada) inicia el flujo en esa entrada y cuenta las anteriores como hechas; (entry <n>) elige la n-ésima entrada del pipeline de la insignia donde el flujo la nombra dos veces. La insignia camina hasta ese lugar: después de pipeline, una llamada ejecuta set ship running en cada entrada antes de ella, en orden, luego en la entrada misma.

Ejecución

1. Ejecuta f10-load-project.sh primero, en cada llamada de esta habilidad, nombrando los pasos que necesita la entrada: capture fetch plan para una descripción, fetch plan para un id de tarea, ninguno para un archivo de plan. El flujo se declara en el project.md que imprime; uno sin plan carga plan pero nunca lo ejecuta.
2. Sigue esos pasos en el orden que da el apartado Argumentos.
3. Carga cada entrada de flujo justo antes de que se ejecute, en una llamada con su insignia: f10-state.sh set ship running <entry>; f10-load-project.sh <step>, y sigue el paso desde esa carga. Una entrada review carga review resolve, y una entrada pr carga pr handoff a menos que su dial handoff off esté configurado, porque el paso pr ejecuta el handoff; el guardia de catch-up (abajo) añade catchup a la carga de cada entrada que protege.

Flujos son los flows: del frontmatter, un nombre con sus entradas ordenadas, una lista o una cadena separada por espacios o flechas (plan judge implement cleanup:comments,prose pr review:ci deploy:staging); ninguno declarado es default: plan implement pr. f10 flow los lista y qué selecciona cada uno.

Paces ajustan el flujo elegido (docs/project-setup.md → Paces). Una vez elegido el flujo, ejecuta f10 flow <name> [--pace <name>], pasando --pace solo cuando el argumento lo dio, y ejecuta las entradas que imprime en su orden, nunca la lista del frontmatter. Imprime una entrada por línea. Una entrada marcada como skipped no se ejecuta: dilo en una línea, y déjala fuera del pipeline de la insignia. Los diales después de una entrada van a su paso con la entrada: rounds y depth a review, marker y handoff a pr; el effort de un juez aplica solo donde el juez genera un agente (--blind), cuyo perfil proviene de f10 agents judge, con --pace <name> cuando el argumento lo dio; un juez en línea se ejecuta en el perfil del agente de la tarea. Un plan inicial que el pace salta hace que la ejecución no tenga plan, como un flujo sin plan. Una línea finish significa que la ejecución termina en un PR abierto que el pace habría fusionado: ship nunca lo fusiona, y el Next: del informe nombra /f10:finish <id> --merge, a menos que drive finalice la tarea (modes/driven.md). Sin pace, la lista es el flujo declarado, con una revisión CI opcional (ci?) ya resuelta. Un f10 flow demasiado antiguo para aceptar un nombre falla en ello: ejecuta el flujo declarado, y di en una línea que el pace no se aplicó.

Una entrada es un paso, o step:arg: un paso genérico más su superposición, o uno definido por el proyecto, el argumento pasado a él (review:local o review:ci establece el by de la revisión (quién revisa), review:host ejecuta la revisión local en la propia revisión de código del host, review:local+ci ejecuta ambas en una ronda y una resolución, review:local+ci? ejecuta solo la revisión de CI donde puede ejecutarse, y f10 flow <name> resuelve el ? antes de que ship vea la entrada, cleanup:<targets> los objetivos de limpieza, que siempre reciben el pase completo donde cleanup solo ejecuta uno ligero en un diff de menos de 200 líneas añadidas, deploy:<env> el entorno). La ejecución comienza en la entrada después de un plan inicial, que solo se ejecuta para una tarea sin archivo de plan. resolve nunca se nombra: una entrada review lo ejecuta. Una entrada judge juzga por posición: antes de implement el juez de plan (asunto plan <id>), cuyo veredicto amarillo revisa el archivo de plan en su lugar y no escribe código; después de él el juez de cambio, que construye los cambios de un veredicto amarillo él mismo, enrutado como el paso juez dice antes y después de pr. Una entrada pr abre el PR de la rama, o lo actualiza cuando uno está abierto, por lo que un flujo puede nombrar pr de nuevo después de revisión o juez para poner la descripción al día. Un flujo sin plan inicial es sin plan: no escribe un archivo de plan, y un plan breve en línea en el chat lo reemplaza a menos que exista uno guardado. Las claves antiguas (pipelines, planless, drive_chain) aún se leen, convertidas a flujos con una advertencia que nombra f10 init --migrate, y también la forma antigua de entrada review (local). La entrada de texto libre también salta capture y fetch, por lo que la ejecución no tiene id de tarea. Un id de tarea ejecuta fetch y mantiene la ejecución vinculada al id (insignia, informe, rama, directorio de revisión), y marca f10-state.sh set plan skipped una vez obtenido, a menos que reutilice un plan guardado (prior, abajo). Su plan en línea indica el tipo que fetch resolvió, con la reproducción de un error y su causa raíz, el invariante de una refactorización o la pregunta de un spike en una línea cada uno, y lista cualquier brecha en sus valores predeterminados. Con un id de tarea, el plan en línea también escribe la intención del cambio como lo hace el paso de plan (f10 lore add intent --change <change> -m <what and why>, docs/lore.md); una intención existente, o una adición fallida, es una línea en el informe, nunca un paso fallido. El envío es la última entrada de entrega (conventions/context.md → envío): sus filas son las que ese paso declara, las de un paso definido por el proyecto en su línea Shipment: de superposición; un judge, demo o handoff después de él añade filas, nunca las reemplaza. Una entrada demo sin nada que mostrar se salta en una línea (el paso demo), un final normal que no añade filas.

Un spike termina después de implementar, sea cual sea el flujo: un plan de Kind: spike responde una pregunta, y su código nunca sale de la máquina. No se ejecuta ningún paso después de implementar (sin cleanup, commit, push, pr, review, judge ni deploy); el envío es el informe del spike. El informe final termina con su cierre: f10 finish <id>, que archiva el plan y el informe, descarta el código del experimento y elimina el worktree, la rama y el workspace; --keep conserva el experimento, commiteado en una rama kept/. Un spike driven no necesita cierre en el informe: f10 drive lo cierra después de ship. En el checkout principal, descarta el código del experimento por las rutas que el informe nombre antes de f10 finish, que rechaza un checkout principal sucio. Su informe de vuelta (abajo) lleva la pregunta, la respuesta y la recomendación; nombra la ruta del informe del spike solo bajo visibility: public, ya que stealth mantiene las rutas de .f10/ fuera del rastreador. El tipo se conoce desde el plan, o el plan en línea de una ejecución sin plan, antes de que comience el flujo, por lo que la insignia declara f10-state.sh pipeline implement, y una ejecución en seco imprime el camino cortado en implementar.

El guardia de catch-up trae la base antes de tres tipos de entrada, como dice el paso catchup en Como guardia; bajo catchup: off nunca integra y su carga deja catchup fuera, pero la pregunta a continuación para una base sin código aún se ejecuta. Catch-up nunca es una entrada de flujo.

• Antes de implementar, solo donde f10 start --after o f10 finish registró una base en la rama (f10-after-branch o f10-landed); f10 pr catchup --guard implement imprime method: skip de lo contrario. Una base sin código aún es la línea code: none del guardia, la regla que f10 drive libera a los dependientes, para una base mantenida localmente o solo en origin. Antes de integrar, pregunta una vez (AskUserQuestion) esperar, o proceder con la suposición del plan. Esperar termina la ejecución bloqueada (f10-state.sh set ship blocked implement, un note nombrando la tarea base). Proceder construye contra el plan de la tarea base según lo registra el archivo de plan, sin alternativa si está ausente. Driven, no se pregunta nada y ship nunca procede: f10-state.sh set ship blocked implement; f10-state.sh wait <base-id>; f10-state.sh note "esperando en <base-id>: su rama aún no tiene código" "vuelve a ejecutar ship una vez que <base-id> haga commit; f10 drive lo hace por sí mismo", luego el informe. f10 drive mantiene la tarea como waiting on <base-id> y envía ship de nuevo, resume at implement, una vez que la base haga commit; otras tareas siguen moviéndose.
• Antes de cada entrada pr, la primera y cada actualización: f10 pr catchup --guard pr primero, que obtiene y verifica la ascendencia; solo cuando su method es merge, rebase o onto, haz commit de lo que el árbol contiene como lo haría el paso pr (conventions/context.md → Commits, --step implement) e integra, para que el push lo lleve. skip o none deja el commit a pr y su adaptador.
• Antes de un juez de cambio (un judge después de implement; el juez de plan no tiene código): con trabajo no commiteado en el árbol (implementar deja su trabajo sin commit, por lo que implement judge pr siempre tiene algo), saltarlo en una línea: ese juez ve la rama en su base antigua, y un guardia de entrada pr posterior, cuando el flujo tiene uno, trae la base antes de que el código salga. Después de una entrada pr, haz push de la integración, nunca forzando, para que la cabeza del PR sea el código juzgado y el estado del juez caiga en él.

El guardia se ejecuta bajo la entrada que protege, en la carga de esa entrada (catchup pr) e insignia. Un fallo es set ship failed <entry>, o partial una vez que la ejecución dejó algo durable, el propio commit del guardia o un PR abierto (conventions/failure.md regla 7), su fila state nombrando ese commit y su note nombrando catchup y /f10:catchup. El guardia marca la rama antes de fallar (el paso catchup), y f10 drive alcanza una rama marcada por sí mismo, de nuevo cada vez que la base se mueve, luego solicita ship de nuevo en esta entrada; se detiene, nombrando los archivos, cuando un catch-up no cambió nada, la base no se ha movido, o los mismos archivos entran en conflicto dos veces seguidas. El next de una ejecución driven es run /f10:catchup --driven in the worktree, then rerun the drive: la reejecución solicita ship de nuevo en esta entrada.

Ejecuta las entradas del flujo en el orden declarado, cada una desde su propia carga. Un plan escrito en esta ejecución no necesita reconfirmación. Una entrada judge enruta la ejecución por su veredicto: el juez de plan como dice la ruta del paso juez antes de pr, sus cambios fusionados en el archivo de plan para que implement los construya; el juez de cambio de manera diferente antes y después de una entrada pr (el paso juez). Los cambios de un juez de cambio, antes o después de pr, se fusionan en el plan y son construidos por la propia ruta del paso juez (Construyendo los cambios), nunca por una reejecución de implement.

Insignia (conventions/report.md): f10-state.sh pipeline <entry>... una vez seleccionado el flujo, cada entrada después de plan como el flujo la nombra, un argumento cada una (pipeline judge implement cleanup pr review:local judge pr), que también declara la última como final; f10-state.sh set ship running <entry> antes de cada entrada, nombrada como el flujo la nombra, en la llamada que la carga; f10-state.sh set ship done después de la última. Un plan de una ejecución anterior (archivo de plan, o reusado con prior): la insignia se construye sobre esa ejecución, y f10-state.sh pipeline añade entradas nuevas después de las ya hechas.

Reportar de vuelta al final: f10-state.sh set ship report; f10-load-project.sh report; sigue el paso Reportar de vuelta.