Edición de sección de artículo de física

Edición de artículo de física — sección

Úselo para una sección completa de física de cualquier extensión, una nota técnica o cualquier pasaje de física de más de 12 oraciones tipográficas en LaTeX, Markdown o texto plano. Use physics-paper-editing directamente para pasajes más cortos que no sean de sección. El canon es physics-language-principles.

Todas las sesiones heredadas/versión-1 son registros históricos cerrados. Nunca las reanude ni cuente sus verificaciones para la finalización actual. Cada pase nuevo o repetido inicia una ronda de edición versión-2 con su propio identificador de ronda y una instantánea fuente; consulte disk-layout.md.

Orden de lectura

1. Antes de la primera respuesta al usuario, lea el runtime-contract.md y user-communication.md de la microhabilidad. Siga la política de comunicación antes de cada respuesta posterior al usuario.
2. Al reanudar, resuelva la ronda versión-2 activa a través de CURRENT, lea el session.md de esa ronda y luego cross-skill.md. Para los límites de automatización de reanudación, lea también automation.md.
3. Lea stages.md y disk-layout.md.
4. Antes de la edición de fragmentos, lea chunk-contract.md y la SKILL.md activa de la microhabilidad.
5. Lea scope-and-verifiers.md para la revisión de la Etapa B o E. Cuando el proyecto tenga un archivo de resoluciones, lea también rulings-file.md.
6. Antes de finalizar, lea test-checklist.md.

Diseño rector

La sección se organiza en torno a una columna vertebral física global y un libro mayor global de objetos antes de que se optimice la prosa local. Cada fragmento los hereda. Un fragmento no puede introducir una normalización competidora, una convención de factores, un símbolo duplicado o un ámbito alterado sin reconciliar el libro mayor global.

La fragmentación sigue siendo un mecanismo de atención y persistencia. Un editor de sección experimentado puede redactar fragmentos directamente; un editor económico o desconocido utiliza el andamio. Cada fragmento ordinario utiliza el contrato direct | reviewed de la microhabilidad. Una unidad segura para el formato fuente que no se puede dividir por debajo de 13 oraciones sigue siendo un fragmento de gran tamaño propiedad de la sección y utiliza el contrato revisado directamente en lugar de violar un límite de definición o ecuación.

Cada fragmento debe preservar la terminología y notación establecidas de la sección. El ensamblaje de fragmentos no puede introducir una nueva etiqueta recortada, un alias matemático o un nombre duplicado que estuviera ausente de la fuente y el contexto global a menos que names-and-symbols.md lo permita y se reconcilie deliberadamente.

Etapas

Etapa	Resultado
A	Ronda versión-2, fuente inmutable, intención de edición, cobertura de lenguaje, política de rol a modelo, ámbito de sección
B	Columna vertebral física de la sección, mapa de párrafos, libro mayor global de objetos, plan estructural
C	Fragmentos de argumento seguros para el formato fuente, normalmente de máximo 12 oraciones, con un mecanismo de respaldo para unidades de gran tamaño definido
D	Edición directa o revisada por fragmento; libro mayor global actualizado deliberadamente
E	Revisión formal y de coherencia física e de objetos a nivel de sección: como máximo dos rondas de revisores ciegos independientes, combinadas y resueltas

No lance un revisor por oración. Un fragmento revisado utiliza un revisor de oraciones de unidad completa y un revisor de terminología y notación, además de especialistas activados. No requiera un revisor para un fragmento directo de bajo riesgo. Reabra solo los intervalos que fallen un eje de calidad requerido.

En la primera respuesta al usuario, siga el runtime contract de la microhabilidad. Si existe una política de rol a modelo de proyecto o conversación vigente, indique su mapeo y continúe sin pedir confirmación. De lo contrario, pregunte y espere. Registre el mapeo activo en session.md y páselo a cada fragmento y a la revisión de toda la sección. Los fragmentos no vuelven a preguntar.

Cada ronda también declara language_coverage: selective | exhaustive. La cobertura selectiva audita las oraciones modificadas o diagnosticadas más la prosa a nivel de fragmento. La cobertura exhaustiva otorga a cada oración de cada fragmento actual un veredicto de lenguaje de la instantánea actual. No infiera cobertura exhaustiva meramente de la existencia de artefactos de fragmentos antiguos; pregunte cuando la cobertura solicitada sea ambigua. Detalle: language-coverage.md de la microhabilidad.

La cobertura selecciona oraciones, no principios. Cada oración dentro del ámbito recibe las 16 verificaciones de oración, y cada oración en texto recién redactado cuenta como modificada.

Persistencia

El trabajo de la sección normalmente se puede reanudar, por lo tanto, persista cada ronda versión-2, su texto de sección original inmutable y sus límites, el candidato actual, el resumen, la revisión del contexto y la revisión del libro mayor de objetos, el manifiesto de fragmentos, los hashes y los resultados de calidad en .physics-edit/ según lo especificado en disk-layout.md. Las rondas históricas siguen siendo evidencia inmutable y nunca satisfacen una ronda posterior.

Lenguaje orientado al usuario

Mantenga el vocabulario exacto de versión, ronda, instantánea, enrutamiento y estado en los registros persistentes, donde sea necesario para la corrección. En la conversación, siga la política de comunicación con el usuario compartida: describa lo que está sucediendo en lenguaje común y nunca presente una etiqueta interna sin explicar inmediatamente lo que significa para el texto del autor.

Puerta de cumplimiento

La contabilidad de una ronda es un programa, scripts/check_edit_round.py (ejecútelo con python3; no necesita paquetes; --root predetermina al nivel superior del repositorio git actual). Mantiene los veredictos por oración, emite paquetes de revisor con el hash del texto que muestran, registra los informes de los revisores y decide con check si la ronda se puede informar como lista. No llama a ningún LLM y no cambia el texto del manuscrito. La política de rol a modelo del proyecto en la raíz del repositorio es physics-edit-policy-<platform>.json para la plataforma anfitriona activa (por ejemplo, physics-edit-policy-antigravity.json en Antigravity o physics-edit-policy-claude.json en Claude Code, seleccionado automáticamente del entorno anfitrión o con --platform <platform>), con respaldo a physics-edit-policy.json; la habilidad no almacena ningún valor predeterminado, así que pregunte al propietario cuando falte y escriba la respuesta con policy set (o policy set --platform <platform>). Cuando el repositorio tenga project-vocabulary.json y la habilidad hermana physics-vocabulary esté instalada, check también escanea cada oración revisada, incluidos los subtítulos, en busca de los avoid_names de todo el registro (los comentarios, las etiquetas y las rutas no se leen). Un acierto bloquea la ronda hasta que la oración se corrija, o, cuando las palabras no nombran el concepto registrado, hasta que un waive --roles terminology registre por qué; entregue los aciertos al revisor de terminología del fragmento. Los paquetes para los revisores de oraciones y terminología también llevan todo el párrafo anterior al fragmento y el informe de asesoramiento de scripts/check_prose_patterns.py para el fragmento; los paquetes holísticos de la Etapa E llevan el informe de todo el texto. Los revisores confirman o descartan sus candidatos; el informe nunca bloquea una ronda por sí mismo. Cada paquete lleva las líneas del mapa de párrafos para su fragmento (Etapa E: todo el mapa). Cuando el repositorio tenga RULINGS.md, digest y stage-e merge lo imprimen una vez por ronda, para el agente que sopesa los hallazgos; digest --rulings lo imprime nuevamente después de una reanudación. Ningún paquete de revisor lo lleva.

Comandos: policy, init, chunks, rechunk, pending, prompt, record, digest, waive, stage-e, status, snapshot, defect, revision, gc, check (--help lista las opciones). Ejecútelos en los momentos siguientes. Debe significa que el programa rechaza el siguiente paso o check falla sin ello.

#	Momento	Ejecutar
1	Inicio de una ronda	policy show (si falta: pregunte al propietario, luego policy set), init, complete el resumen, el mapa de párrafos y el libro mayor, check	debe: política, init; debería: check (solo el resumen, el mapa de párrafos, el libro mayor y las certificaciones deben estar abiertos)
2	Reanudar en una nueva sesión o después de la compactación	status, pending, digest --rulings, check	debe. status lista los paquetes emitidos pero no registrados: regístrelos o elimínelos antes de lanzar otros nuevos
3	Una viñeta se divide, fusiona, mueve o agrega	rechunk, chunks	debe. Un fragmento con al menos la mitad de sus oraciones ya revisadas conserva su id
4	Después de cada lote de edición, una vez que se completa la verificación del canon del propio editor	record --role editor_closure, luego digest (ningún hallazgo aceptado puede quedar sin aplicar), pending, prompt	debe: el cierre (prompt se niega sin él). Un FIX que decida no aplicar: waive --reason
5	Lanzar un revisor	el modelo y el esfuerzo que prompt imprime	debe
6	Un resultado de revisor	record --packet pNNN --report FILE --model M --effort E	debe. Hace cumplir el modelo y el esfuerzo, la revisión y un veredicto para cada oración dentro del ámbito. Las oraciones que cambiaron desde que se emitió el paquete se informan, no se rechazan: sus veredictos simplemente ya no coinciden
7	Una revisión de oración con aciertos de principio FIX	prompt --role specialist --principles ... antes de la reparación	debe (la puerta debe un especialista por acierto)
8	Se registra un lote	pending, digest; decida cada story_check, luego edite bajo la fila 4	debería
9	Nada pendiente en un fragmento	prompt --scope close para el revisor de oraciones y el de terminología, luego reparaciones por las filas 4 a 8	debe: check necesita una revisión de cierre por rol, excepto para un fragmento que la cobertura selectiva deja sin cambios
10	Después de la última edición	snapshot	debe (check falla hasta que la instantánea sea igual al texto vivo)
11	Antes de la Etapa E	check no muestra ninguna línea que comience con un id de fragmento	debe: `prompt --role holistic
12	Una ronda de la Etapa E (como máximo dos)	prompt --role holistic y --role formal una vez por revisor (3 por rol en la ronda 1, 2 en la ronda 2; el programa rechaza más), cada uno lanzado como un nuevo agente que solo obtiene la línea impresa; record --packet para cada uno; stage-e merge; `stage-e rule --cluster K.. --as applied	waived
13	Una resolución del propietario, una reparación de la Etapa E o un movimiento entre fragmentos	defect rule si se registró un defecto; pending para el radio de explosión; actualice el archivo de resoluciones (rulings-file.md); revision --yes solo si la columna vertebral, el libro mayor o las convenciones contra las que juzgan los revisores cambiaron	debe para defect rule. Un incremento imprime y descarta cada veredicto actual y rechaza los paquetes que aún están fuera. Una edición del libro mayor, el resumen o reviewer-context.md sin un incremento solo se advierte cuando se registra un paquete
14	Antes de cada informe al propietario	check; cite su última línea; termine con "Desviaciones de la habilidad:"	debe
15	Al final de una ronda, o cuando se le pregunte sobre el uso del disco	gc	debería. Enumera las rondas pasadas de retención y no elimina nada; gc --compact elimina el grueso de las rondas vencidas (informes sin procesar, paquetes, mapas de oraciones, instantáneas) y solo con el acuerdo del propietario

Finalización

Una sección está lista solo cuando todos los fragmentos están integrados, cada resultado requerido coincide con las instantáneas actuales del fragmento y la sección, la cobertura de lenguaje declarada está completa, ningún eje de calidad requerido de un fragmento es FIX o USER_DECISION, y la Etapa E está resuelta: como máximo dos rondas de revisores ciegos independientes, cada clúster obligatorio aplicado o renunciado (ninguno abierto, ninguno diferido al propietario). La independencia de verificación se registra por separado de la calidad del contenido.

Un defecto científico en la fuente del autor que la tarea solicitada no autorizó ya a reparar sigue la regla en quality-contract.md: regístrelo con defect add, continúe trabajando en los fragmentos que no dependan de él y deje la ronda needs_user hasta que el autor resuelva. No convierta el defecto en una limitación al momento de la finalización.

Habilidades relacionadas

• physics-paper-workflow — receta maestra y mapa de etapas a lo largo del artículo
• physics-paper-outline — esquematización, fórmula de Introducción de 4 párrafos y límite entre texto principal y apéndice
• physics-paper-framing — resúmenes, párrafos de resumen y alineación de Conclusión ↔ Introducción
• physics-language-principles — canon de redacción y revisión
• physics-paper-editing — pasajes de máximo 12 oraciones y cada fragmento
• physics-paper-author-read — respuesta a las ediciones y comentarios al margen del propio autor; su lenguaje pasa por esta habilidad

Fuera del alcance

• Pasajes que no sean de sección de máximo 12 oraciones
• Inventar significado físico faltante
• Tratar los límites de los fragmentos como permiso para redefinir objetos globales localmente
• Reanudar o reactivar una sesión heredada/versión-1