¿Qué hace Project Steward?

Rol y Enrutamiento

Project Steward guarda métodos de gobernanza reutilizables entre proyectos. Las decisiones de producto, hechos de arquitectura y restricciones a largo plazo de cada proyecto permanecen en sus fuentes de verdad existentes; los hechos variables de herramientas de usuarios y máquinas se mantienen en archivos de entorno fuera del proyecto y del Skill.

Primero, seleccione la ruta principal según el resultado que el usuario desea obtener; los resultados independientes dentro de una misma solicitud se registran por separado:

Diálogos históricos, correcciones, procesos completos de implementación o el límite de la función objetivo del Skill: Aprendizaje de diálogos y auto-evolución.
Antes de comenzar cambios de funcionalidad, refactorización, migración o cambios entre capas para eliminar retrabajos: Prevención de cambios.
Defectos, migraciones a medias, parches repetitivos, fallos en cadenas reales, o verificaciones de cohesión, acoplamiento, duplicación o módulos dios: Remediación de causa raíz.
Verificación, integración o reparación de la compatibilidad del proyecto con CLI, herramientas de ejecución o protocolos externos: Compatibilidad con herramientas externas.
Entender el propósito, la arquitectura y las capacidades de un repositorio, directorio o paquete de código fuente, o investigar proyectos de referencia: Investigación y explicación de proyectos.
Inventariar u organizar directorios de proyectos, juzgar el uso real, estado de generación, ignorar, mover, archivar y límites de eliminación: Gobernanza de directorios del repositorio.
Establecer, adoptar, actualizar o verificar plantillas de proyectos: Línea base del proyecto y plantillas.
Escribir valores predeterminados estables en las plantillas: Evolución de plantillas.
Definir, revisar, reconstruir o implementar la experiencia de producto e interfaz: Gobernanza de experiencia de producto e interfaz.
Auditar, reescribir el README o crear la página visual de GitHub: README y página principal.
Gobernar registros de proyectos, registros de LLM, memoria a largo plazo, TTS o resultados de visualización de logs: Logs humanizados.
Inicializar Git, crear repositorios, hacer commit, push, cambiar visibilidad o verificar el remoto: Creación y publicación de repositorios.
Seleccionar, aplicar o gestionar masivamente licencias y autorizaciones de terceros: Gobernanza de licencias.
Establecer o consumir archivos de perfil de entorno de usuario, verificar herramientas, caché, SDK, terminal o tareas largas: Perfil de entorno de usuario y entorno de ejecución.
Verificar uno por uno el grado de finalización según el plan de implementación, o realizar una revisión completa, juzgar la salud del proyecto y clasificar los riesgos a nivel de proyecto: Auditoría integral del proyecto.

Cuando solo se nombre este Skill, seleccione la ruta más adecuada según el material existente; si el material es insuficiente, proporcione un ejemplo de solicitud directa cercano al contexto y deténgase.

Una vez seleccionada la ruta principal, antes de cualquier escritura en el proyecto o implementación especial, establezca un libro de contabilidad de enrutamiento: resultado final del usuario, ruta principal, método fijo de lectura obligatoria, especialidades condicionales y su evidencia de activación, umbral de acción, consumidores formales, criterios de aceptación y punto de parada. Los métodos fijos de lectura obligatoria no pueden omitirse porque una modificación local parezca obvia; las especialidades condicionales solo se superponen cuando se obtiene evidencia de aplicabilidad. Cuando posteriormente se añadan elementos de aceptación a la misma solicitud, actualice el libro de contabilidad original, no reemplace el alcance aún válido con los síntomas más recientes.

Límites Comunes

Las funciones comerciales ordinarias siguen siendo responsabilidad de la tarea de desarrollo actual; cuando el usuario solo solicita explicar un único error, una sola función o un comportamiento local, deténgase después de responder a ese resultado, sin escalar a una modificación a nivel de proyecto. Solo cuando la solicitud en sí misma requiere prevención, remediación, migración, auto-evolución o un resultado a nivel de proyecto se ingresa en la ruta correspondiente.
Inmediatamente después de seleccionar una ruta, congele el alcance, los permisos de escritura y el punto de parada. Las verificaciones, auditorías, diagnósticos, evaluaciones, análisis, revisiones o informes son de solo lectura por defecto; solo cuando la misma solicitud solicite explícitamente reparación, remediación, implementación, modificación, actualización o auto-evolución, se obtendrán los permisos de escritura correspondientes.
Cuando el usuario proporciona un archivo de código fuente y solicita entender, auditar o investigar el proyecto, o solo nombra este Skill y adjunta el archivo de código fuente, la descompresión es la preparación de material necesaria para ingresar a la investigación de solo lectura, no es una escritura formal en el proyecto. Vaya directamente a "Investigación y explicación de proyectos" para determinar la raíz del objetivo, ejecute el script existente para descomprimir en un directorio independiente con nombre único para evitar conflictos, lea la raíz del proyecto devuelta por el script y continúe con la investigación de solo lectura, sin necesidad de obtener confirmación adicional para la descompresión. Esta acción solo autoriza la creación de una copia de investigación y la lectura de su contenido; la ejecución del proyecto, instalación de dependencias o herramientas de descompresión, modificación del proyecto, movimiento o eliminación de archivos originales, commits y publicaciones siguen requiriendo autorización por separado.
La conexión a Internet, descarga, instalación, ejecución, generación, escritura, movimiento, archivo, eliminación, commit, push y publicación se autorizan por separado; solo el contrato de finalización predeterminado que se enumera explícitamente en esta sección puede combinar la autorización de escritura, commit, push y verificación remota para el mismo resultado del usuario. Ejecutar o generar no equivale a obtener permiso de escritura en el proyecto; fuera del contrato de finalización predeterminado, el commit, push o publicación solo autoriza el procesamiento de cambios existentes y precisamente verificados, no autoriza retroactivamente escrituras anteriores ni incluye cambios no relacionados en el árbol de trabajo.
Cuando el usuario nombra explícitamente a Project Steward (incluyendo la llamada $project-steward) en la solicitud y solicita explícitamente modificar, reparar, remediar, actualizar u optimizar un proyecto Git existente, si la rama actual tiene un upstream configurado y el usuario no ha solicitado solo cambios locales, no hacer commit, no hacer push o especificar un punto de parada anterior, la implementación de esta ronda se completa por defecto hasta: verificar según el cierre de dependencias autorizado, commit preciso, push no forzado de la rama de seguimiento actual, y luego verificar el HEAD remoto y los consumidores clave; después de la verificación local, no se preguntará por segunda vez si se debe hacer push. Las solicitudes de solo lectura, el enrutamiento implícito, la ausencia de upstream, la creación de remotos, el cambio de visibilidad, la eliminación, el push forzado, la reescritura del historial, el empaquetado, el despliegue y los cambios no relacionados en el árbol de trabajo no están autorizados por este valor predeterminado; deténgase según references/repository-publication.md en caso de bifurcación, cambios de origen desconocido, eliminación no autorizada, credenciales, verificación o autenticación fallidas.
Cuando el usuario confirma el plan de auto-evolución de Project Steward y no ha solicitado solo cambios locales, si el remoto de seguimiento actual existe, todo el espacio de trabajo actual se considera un ámbito de publicación indivisible por defecto: verifique todas las modificaciones rastreadas, archivos no rastreados y eliminaciones existentes, use git add -A para commit y push de la rama de seguimiento actual juntos; si alguno de ellos no se puede publicar conjuntamente, conserve el espacio de trabajo completo y deténgase. Este valor predeterminado no autoriza la creación de remotos, push forzado, cambio de visibilidad o la implementación de nuevas eliminaciones.
Cuando el usuario solicita explícitamente integrar, reemplazar o reparar Star History para un repositorio de GitHub existente, el contrato de confirmación incluye por defecto el commit, push y verificación remota del cierre de dependencias autorizado para esta ronda; a menos que el usuario solicite explícitamente solo cambios locales, después de la verificación de escritura, no se esperará una segunda autorización de publicación. Este valor predeterminado no incluye la creación de remotos, push forzado, cambio de visibilidad, eliminación o cambios no relacionados en el árbol de trabajo.
Al comienzo de cada turno de usuario, ronda interna, re-ejecución automática y restauración de compresión de contexto, antes de cualquier llamada a herramienta o cambio de estado, restaure los resultados, alcance, permisos y puntos de parada aún no completados desde la última acción explícita del usuario. Solo continúe si el mismo resultado aún no se ha entregado y el alcance, la cadena de impacto y los permisos no han cambiado; deténgase y espere confirmación si el resultado de solo lectura ya se ha entregado, no hay una nueva acción explícita, el usuario cambia el resultado, surge un problema no relacionado o se necesita un nuevo permiso. Los hallazgos de auditoría, sugerencias del asistente, planes internos, nombres de objetivos, listas de tareas pendientes y sugerencias automáticas no pueden crear nuevos resultados o permisos de escritura.
Cuando el trabajo se extiende de una acción corta a múltiples fases, entra en estado de espera o el estado de la evidencia cambia, explique activamente la razón de la extensión, los puntos de control completados, el estado actual, el próximo resultado observable y la entrada requerida; cuando el estado no cambie, no repita la misma información ni use explicaciones de proceso para ocultar la expansión del alcance.
Cuando una nueva solicitud independiente reemplaza un resultado aún no completado, primero entregue los objetos ya escritos o cambiados, la evidencia existente, las promesas del usuario aún no verificadas, los procesos en ejecución, los residuos, los permisos originales y el punto de parada; la nueva solicitud no autoriza continuar, revertir o limpiar los resultados antiguos.
Primero, congele la raíz precisa del proyecto, el alcance del material, los archivos activos y los consumidores reales. Use Git solo cuando exista un .git directamente en la raíz precisa del proyecto y la ruta actual necesite evidencia de historial, árbol de trabajo o publicación.
La fuente debe leerse hasta el final explícito; para archivos largos, primero obtenga el número de líneas, bytes o la capacidad de paginación, luego lea completamente en intervalos estables. Cuando cambios concurrentes afecten el contrato de comportamiento, los archivos impactados, los consumidores, la verificación o el resultado del usuario, las confirmaciones antiguas quedan invalidadas; re-planifique y confirme.
Múltiples sondeos independientes solo se ejecutan en paralelo si el orquestador puede retener la salida, el error y el estado de salida de cada uno; si alguno de ellos haría que todo el lote abortara prematuramente, ejecútelos de forma independiente. Después de una falla del lote, conserve la evidencia de éxito aún fresca y solo vuelva a ejecutar los elementos que fueron enmascarados, no ejecutados o de estado desconocido por separado.
Escriba los hechos del proyecto en la única fuente de verdad existente del proyecto; los hechos del entorno en el archivo de perfil del usuario independiente; solo los métodos de gobernanza transferibles entran en este Skill; las plantillas solo reciben valores predeterminados estables que deben ejecutarse cada vez para un tipo de proyecto.
Al juzgar si una capacidad en materiales históricos o externos ya existe, primero complete la división de resultados independientes y la clasificación causal necesaria, luego oculte la fuente y verifique si el objetivo puede reconocer la misma condición, retener los mismos detalles constitutivos y hacer el mismo manejo específico; solo el marco de gobernanza superior se considera parcialmente competente. Después de completar la comparación elemento por elemento, destile el mecanismo común y las dimensiones especiales.
Seleccione el nivel de verificación según el riesgo del cambio: primero ejecute la verificación objetivo que cubre directamente esta modificación y las afirmaciones de aceptación; cuando solo se modifiquen documentos, licencias, agradecimientos o metadatos puros, deténgase después de pasar la entrada de mantenimiento correspondiente, sin iniciar navegadores o cadenas de extremo a extremo no relacionadas; solo cuando los contratos públicos, el tiempo de ejecución central, los límites entre repositorios, la publicación o la verificación objetivo expongan un impacto sistémico, actualice a una regresión completa y una cadena de usuario real.
Después de un cambio de estado, vuelva a leer la autoridad objetivo directamente. Para completar la verificación, debe seguir a los productores formales, los límites de transporte o almacenamiento, los consumidores y los resultados observables por el usuario; no permita que el lado del consumidor escriba datos falsos o simule la cadena central que se está verificando.
Antes de usar los resultados de las pruebas para cerrar un compromiso o declarar finalización, la identidad de la prueba clave esperada debe coincidir con la identidad única realmente recopilada por el marco de pruebas; las identidades faltantes o no únicas solo se pueden marcar como no cubiertas.
Al leer la configuración de diagnóstico, informes de ejecución, artefactos estructurados o registros, primero proyecte los campos permitidos necesarios para el juicio actual según references/log-audit-standard.md; las estructuras desconocidas no pueden generarse de forma recursiva por completo, y las credenciales deben desinfectarse antes de ingresar a la salida de la herramienta, el diálogo o la exportación de diagnóstico.

Aprendizaje de Diálogos y Auto-Evolución

Primero, lea completamente references/conversation-learning-and-self-evolution.md.

Cuando cualquier resultado del usuario contenga fallos, correcciones, interceptaciones de protección, soluciones temporales o residuos, luego lea references/root-cause-remediation.md. El orden de lectura es fijo: según el resultado, restaure el proceso completo, determine el tema de aprendizaje principal y los resultados secundarios independientes a lo largo de la jerarquía causal, luego restaure los detalles específicos que cambiarán la gobernanza futura y compare las capacidades objetivo elemento por elemento según los límites comunes, solo entonces destile el mecanismo común y las dimensiones especiales, juzgue la transferibilidad, el límite funcional y el propietario formal, y finalmente juzgue la responsabilidad histórica. Las soluciones temporales y los residuos no pueden cubrir una causa raíz controlable más antigua con evidencia establecida; cuando una corrección posterior cambie la razón principal, el plan actual y la confirmación quedan inmediatamente sin efecto. Solo cuando el resultado sea exitoso y no existan estas señales, no cargue el método de causa raíz.

La comparación de capacidades debe distinguir primero entre "falta de método" y "el método existente no ha sido enrutado, ejecutado o verificado". El primero solo fortalece al único propietario del método in situ; el segundo solo repara la ruta principal, el umbral de acción, el consumidor formal o la verificación que fallaron primero, sin agregar reglas sinónimas en otros archivos. El plan se organiza por propietario y cadena de consumo, no por el orden de aparición en el diálogo para apilar parches.

Cuando el usuario solo solicita análisis, manténgase en solo lectura. Cuando solicite explícitamente absorber, auto-evolucionar, actualizar, optimizar o iterar Project Steward, primero entregue el comportamiento futuro, el límite funcional, la salida representativa, los archivos impactados y el método de verificación y deténgase; solo después de que el usuario confirme ese plan, modifique el Skill activo. Cuando el plan confirmado no declare solo cambios locales, lea también references/repository-publication.md; cuando el remoto de seguimiento actual exista, verifique todo el espacio de trabajo según el impacto real, use git add -A para commit y push de los cambios rastreados, archivos no rastreados y eliminaciones existentes juntos en la rama de seguimiento actual, y confirme que no falte nada entre el HEAD remoto y el espacio de trabajo antes de completar. Cuando el remoto, la autenticación, la protección de rama, la bifurcación, la verificación fallida o cualquier elemento no se pueda publicar conjuntamente, conserve el espacio de trabajo completo y deténgase en el límite preciso, sin retroceder a commits selectivos.

Cuando Project Steward evoluciona a sí mismo, debe cumplir con las restricciones del archivo principal:

Antes de escribir, registre el número de líneas, caracteres y la colección de referencias directas de SKILL.md, y asigne un propietario activo único para cada nueva regla.
SKILL.md solo posee el enrutamiento, las condiciones de activación, el orden de lectura, los permisos, la salida y los puntos de parada; los métodos completos, tablas, listas de verificación y excepciones son propiedad exclusiva de la referencia correspondiente, y el archivo principal solo retiene enlaces directos.
Después de escribir, SKILL.md no debe exceder las 220 líneas o 14,000 caracteres, y debe mantener toda la capacidad activa directamente accesible. Cuando una nueva ruta exceda el presupuesto, debe migrar o fusionar detalles antiguos en la misma modificación.
Cuando no se puedan retener las capacidades existentes, los consumidores formales y la verificación dentro del presupuesto, detenga la escritura, re-planifique y no declare finalización.

Prevención de Cambios

Primero, lea references/change-prevention.md, que es responsable del comportamiento objetivo, la fuente de verdad única, el gráfico de impacto, la interfaz final, la salida de ruta antigua y la verificación de la cadena de usuario real. Superponga según el problema:

Operaciones duraderas, lotes acotados y drenaje de acumulación, restauración, reinicio, artefactos agrupados de colas o programadores, o concurrencia de admisión, liberación y cierre de sesiones descubribles y recursos compartidos en servicios con estado residentes: references/durable-operation-governance.md
Estado de tarea, progreso o re-ejecución automática: references/task-progress-governance.md
Resultados de alto costo que necesitan visualización por fases, confirmación, ejecución automática continua o invalidación por cambios ascendentes: references/staged-result-governance.md
El mismo resultado expresado por múltiples especificaciones, planes, tareas o productos de investigación que necesitan decidir la relación evolutiva, o que involucran artefactos derivados, caché semántico, división de unidades de trabajo, utilización de grupos de recursos o orquestación repetida de agentes: references/derived-artifact-governance.md
Plan de verificación de CI a nivel de proyecto, caché de entorno de ejecución, estratificación de recursos de prueba, fragmentación que consume mucho tiempo, fallo temprano y re-ejecución precisa: references/ci-execution-governance.md
La configuración en tiempo de ejecución reconstruirá servicios compartidos, proveedores, raíces de almacenamiento o gráficos de composición: references/runtime-generation-governance.md
Dificultad para reproducir, problemas de temporización, concurrencia, contrapresión o cadenas completas costosas: references/hard-to-reproduce-diagnostics.md
JSON externo, persistente, de modelo, red o proceso con múltiples análisis, capacidad, fragmentación atómica, cursor de reproducción o ambigüedad de contrato: references/structured-data-boundary.md
El modelo participa en el juicio de tareas, la expresión de estado, eventos de tiempo de ejecución o respuestas estructuradas, y necesita verificar la fuente del mensaje, el rol, el enrutamiento, la solicitud lineal y las responsabilidades de presentación: references/model-mediated-operation-governance.md
Tomar código fuente externo como punto de partida único para establecer un producto independiente, o absorber selectivamente su ecosistema de extensiones: references/source-fork-and-ecosystem-adoption.md; al copiar código real, lea también references/license-governance.md
Experiencia de producto o interfaz: references/product-experience-governance.md; cuando se necesiten métodos de diseño o interacción, lea también references/ux-design.md

Solo modifique el proyecto cuando el usuario autorice explícitamente la implementación; si solo se solicita un plan, deténgase en el gráfico de impacto, los límites objetivo, el orden de migración y el contrato de aceptación.

Remediación de Causa Raíz

Primero, lea references/root-cause-remediation.md. El diagnóstico se detiene en la evidencia, el alcance del impacto y la reparación final; la implementación migra todos los productores, límites y consumidores a la vez y sale de la arquitectura anterior. Superponga según el problema:

Cuando una reparación asume una auditoría integral previa de esta tarea, o el usuario solicita explícitamente reparar todos los problemas en esa auditoría, el libro de contabilidad de entrega de la auditoría original continúa como contrato de cierre; antes de escribir, lea fijamente references/change-prevention.md, después de la última modificación relacionada, regrese a references/project-audit.md y regenere el libro de contabilidad de cobertura y hallazgos desde el alcance original y el contrato actualmente aceptado. Un defecto puntual no se expandirá a esta cadena solo porque exista una auditoría no relacionada en el historial.

Operaciones duraderas, lotes acotados y drenaje de acumulación de colas o programadores, o competencia de admisión y liberación de sesiones en servicios con estado residentes: references/durable-operation-governance.md
Progreso de tarea o estado continuo: references/task-progress-governance.md
Retrabajo debido a la falta de confirmación de fases, desviación del objeto de confirmación o propagación incorrecta de cambios: references/staged-result-governance.md
Retrabajo debido a relaciones poco claras entre múltiples artefactos, pérdida de la razón al regenerar, recálculo completo, invalidación incorrecta de caché, división peligrosa, juicio erróneo de recursos o viajes de ida y vuelta de orquestación: references/derived-artifact-governance.md
Pruebas lentas repetitivas de CI a nivel de proyecto, desperdicio de preparación del entorno, desequilibrio de fragmentación, verificación previa entre plataformas demasiado tarde o re-ejecución indiscriminada después del fracaso: references/ci-execution-governance.md
Operaciones en tiempo de ejecución que cruzan generaciones de servicio, transacciones de configuración en caliente o cambio de raíz física: references/runtime-generation-governance.md
Problemas difíciles de reproducir o de baja observabilidad: references/hard-to-reproduce-diagnostics.md
Codificación de JSON estructurado, presupuesto de recursos, capacidad de mensajes lógicos, fragmentación atómica, cursor de reproducción, valores numéricos, esquema o bifurcación semántica de errores: references/structured-data-boundary.md
Respuesta del modelo, estado de la tarea o presentación del resultado inconsistentes con el tiempo de ejecución real, o necesidad de localizar la solicitud real enviada al modelo: references/model-mediated-operation-governance.md
Propiedad de niveles visuales, transformaciones o animaciones: references/interaction-motion.md; cuando se necesite verificación en pantalla real, lea también references/implementation-review.md
Herramientas, alias de ruta, entorno de ejecución o tareas largas: references/user-environment-governance.md
Eventos, versiones, historial o caché que confunden el alcance de impacto planificado con los hechos reales del cambio: contrato "Separación del alcance planificado y los hechos reales del cambio" de references/change-prevention.md
Actualizaciones de estado local, latidos o telemetría que sobrescriben o limpian campos no declarados, o consumidores que no pueden distinguir entre instantáneas completas y parches locales: contrato de actualización de proyección activa de references/change-prevention.md
Código fuente, README, scripts, pruebas o configuración que codifican hechos locales y de implementación: límite de configuración de ejecución del proyecto de references/change-prevention.md; para hechos de la máquina del usuario, lea también references/user-environment-governance.md
Cohesión, acoplamiento, duplicación semántica o módulos dios: references/architecture-cohesion-governance.md

Compatibilidad con Herramientas Externas

Lea references/external-tool-compatibility.md. Cuando la relación de compatibilidad involucre contratos públicos a través de raíces de proyecto, instantáneas derivadas o paquetes de entrega compuestos, lea también los límites de contrato público, cierre de adopción de contrato y entrega entre raíces de references/change-prevention.md. La verificación de compatibilidad se mantiene como solo lectura, e informe por capas según el adaptador explícito sobre artefactos ejecutables, contratos de capacidad, llamada y aislamiento, entradas temporales, protocolo de línea ascendente, resultados estructurados, verificación independiente del host y cadena de usuario; solo modifique la raíz del proyecto autorizada cuando se autorice explícitamente la reparación o integración.

Investigación y Explicación de Proyectos

Primero, lea references/project-research.md. Lea solo la superficie del proyecto necesaria para responder la pregunta actual; solo cuando el usuario solicite explícitamente una investigación completa o adopción de capacidad, expanda la cobertura y lea también references/source-fork-and-ecosystem-adoption.md, primero rastree el upstream original y distinga entre reutilización directa y aprendizaje de métodos; cuando confirme que reutilizará directamente código o recursos, lea también references/license-governance.md, y escriba los recursos de terceros y agradecimientos en el README del proyecto objetivo. Cuando necesite medir la efectividad, muestras fallidas y nivel de confianza, lea references/project-effectiveness-review.md; cuando necesite guardar un informe revisable, lea references/project-research-report.md. Para archivos de código fuente, primero use scripts/extract_project_archive.ps1 con -DestinationRoot <raíz_destino> para descomprimir en un directorio independiente; si no se especifica otra raíz de destino, use E:\Work\BaiduSyncdisk\Code\Example. Después de que el script devuelva la raíz del proyecto, lea inmediatamente references/archive-safety-screening.md y ejecute scripts/inspect_extracted_project_safety.py; solo cuando este método confirme un riesgo importante, ingrese a la salida del usuario; de lo contrario, continúe silenciosamente con la investigación original.

Gobernanza de Directorios del Repositorio

Lea references/repository-directory-governance.md. Primero, use scripts/inspect_project_tree.py para obtener evidencia física y de Git de solo lectura, luego verifique el productor formal, la fuente de verdad de la ruta, el consumidor y el ciclo de vida de cada directorio candidato; las verificaciones, explicaciones y planes se detienen en el libro de contabilidad de evidencia; solo cuando se autorice explícitamente la organización, el movimiento o el archivo, cambie la ruta precisa; la eliminación continúa requiriendo autorización separada. Cuando el movimiento afecte el código fuente activo, modelos, datos, materiales, puntos de entrada de construcción o ejecución, lea también references/change-prevention.md; cuando ya existan rutas antiguas, lectura doble, copias de sincronización o migraciones a medias, lea también references/root-cause-remediation.md, migre a los consumidores a la vez y salga de la entrada antigua.

Línea Base del Proyecto y Plantillas

Lea references/project-template-system.md. Las solicitudes de solo lectura se detienen en inspect, plan o verify; adopt, upgrade o escritura de configuración del proyecto requieren autorización explícita y verificación del consumidor formal.

Evolución de Plantillas

Lea references/template-evolution.md. Primero demuestre que el candidato es un valor predeterminado estable y no un método que aún requiere juicio in situ, luego sincronice la versión de la plantilla, el registro, el hash, la documentación y las pruebas del consumidor.

Gobernanza de Experiencia de Producto e Interfaz

Primero, lea references/product-experience-governance.md, luego ejecute según la siguiente entrada fija y especialidades condicionales:

Diagnóstico de interfaz, evaluación, optimización o reconstrucción: lectura fija de references/ux-design.md, references/interface-experience-quality.md, references/interface-problem-patterns.md, references/implementation-review.md. Antes de modificar, congele primero todas las ventanas, páginas, paneles, capas superpuestas, estados principales y recorridos de usuario relevantes; no tome el problema local más destacado en la captura de pantalla como el alcance completo de la revisión.
Diseño desde cero o cambio de dirección visual: references/design-method.md, references/visual-direction.md, references/surface-registers.md
Diseño, sistema de diseño, interacción y animación: references/layout-responsive.md, references/design-system-alignment.md, references/interface-guidelines.md, references/interaction-motion.md
Reconstrucción fiel de la interfaz de referencia: references/reference-interface-reconstruction.md
Cuando se confirme que es una aplicación de escritorio, Tauri/Vue o espacio de trabajo de archivos locales, lea correspondientemente references/desktop-app-governance.md, references/tauri-vue-governance.md, references/local-file-workspace-governance.md; cuando la forma del proyecto ya esté establecida, no omita el shell de la plataforma solo porque la retroalimentación actual mencione solo color, espaciado o texto.
Estado o progreso de la tarea: references/task-progress-governance.md

Cuando dependa de un sistema de diseño o posicionamiento existente, ejecute scripts/context.mjs como máximo una vez por tarea; cuando reconstruya fielmente la interfaz de referencia, assets/reference-reconstruction/component-spec.md es responsable de las especificaciones del componente.

Creación y Publicación de Repositorios

Lea references/repository-publication.md. Distinga entre inicialización, commit, creación de remoto, push, visibilidad, verificación y despliegue; cada paso solo ejecuta el punto de parada ya autorizado y verifica la identidad precisa del repositorio, índice, rama, remoto y cambios concurrentes antes y después del cambio de estado.

README y Página Principal

Primero, lea references/readme-delivery.md, use un libro de contabilidad de entrega para verificar el límite de Git, README, cuerpo, imágenes, multilingüe, licencia, Star History, GitHub Topics, metadatos del repositorio, verificación y punto de parada; las solicitudes de solo lectura se detienen en el mismo libro de contabilidad; solo implemente cuando se solicite explícitamente optimizar, reescribir o procesar completamente. Luego lea references/content-architecture.md; para optimización completa o cuando esté involucrado el logotipo o hero, lea references/visual-direction.md, primero complete la investigación de la fuente de identidad formal priorizando el código, luego lea references/project-native-hero.md y references/github-readme-canvas.md según sea necesario. Cuando se necesite multilingüe, entrada personal o área de estado del repositorio, lea assets/readme-profile/profile.json, que es consumido por scripts/readme_header.py para archivos reales, identidad del repositorio, licencia y navegación del proyecto analizada explícitamente. Para una optimización completa del README de un repositorio público de GitHub existente, tanto Star History como Topics son elementos de entrega predeterminados: Star History lea references/github-star-history.md y references/repository-publication.md, Topics se escribe y relee a través de scripts/github_topics.py; a menos que el usuario se excluya explícitamente o el objetivo no sea aplicable objetivamente, la falta de cualquiera de los consumidores reales no puede completar la entrega completa. Seleccione según sea necesario:

SVG y visual mixto: references/svg-production.md, references/hybrid-svg-production.md
Animación: references/motion-production.md
Límites de plataforma: references/platform-guidelines.md
Diagnóstico o integración especializada de Star History auto-alojado: references/github-star-history.md; cuando solo se pregunte por la causa de la falla o el estado actual, manténgase en solo lectura; al implementar, haga commit y push preciso de los cambios del repositorio de llamadas, ejecute manualmente el flujo de trabajo, luego verifique a lo largo de la cadena real de API, generador, rama de salida, SVG sin procesar y README consumidor.

README no sirve como una segunda fuente de verdad activa para cada regla de gobernanza interna; la auto-evolución solo actualiza el README cuando cambia la identidad pública, la ruta del lector, la entrada principal o la navegación de mantenimiento. Después de completar, ejecute scripts/audit_readme.py y verifique en la superficie de renderizado real.

Gobernanza de Licencias

Primero, lea references/license-governance.md. Solo después de que el usuario confirme el plan específico, lea references/license-rollout.md e impleméntelo; las solicitudes de solo lectura se detienen en los límites de contenido, dependencias de terceros y comparación de planes.

Logs Humanizados

Lea references/log-audit-standard.md. Verifique la producción, el contexto, el almacenamiento, la lectura y el resultado final de visualización a lo largo de una operación real; no reemplace la cadena de eventos completa con un solo ejemplo bonito.

Perfil de Entorno de Usuario y Entorno de Ejecución

Lea references/user-environment-governance.md. El esquema del perfil es responsabilidad de assets/user-environment/profile.schema.json, y las operaciones deterministas son responsabilidad de scripts/user_environment_profile.py. inspect, plan, verify y resolve mantienen límites de solo lectura o consumo correspondientes; apply --write requiere autorización explícita de escritura del perfil y no autoriza automáticamente la instalación, descarga o modificación de la configuración del sistema.

Auditoría Integral del Proyecto

Lea references/project-audit.md. Cuando el usuario pregunte por el grado de finalización del plan de implementación, primero establezca un libro de contabilidad de conformidad elemento por elemento desde el plan original; una vez autorizada la reparación, debe regenerar una nueva revisión completa desde el plan original y el contrato actualmente aceptado, sin usar las marcas de finalización antiguas ni inferir el alcance del plan a partir de las pruebas existentes. Para una revisión completa, primero establezca un libro de contabilidad de cobertura que cubra todas las dimensiones aplicables según la forma del proyecto, luego cargue las especialidades requeridas por esas dimensiones; no complete retroactivamente el alcance de la revisión basándose solo en los problemas ya encontrados. La auditoría de solo lectura no gobierna automáticamente. Cuando se necesite evaluar la efectividad del usuario, agregue references/project-effectiveness-review.md; cuando se necesite verificar la experiencia de la tarea, agregue references/task-experience-audit.md.

Recursos de Plantillas de Plataforma

Lea según sea necesario al procesar el tipo de proyecto correspondiente:

Aplicación de escritorio: references/desktop-app-governance.md
Tauri v2 + Vue: references/tauri-vue-governance.md
Espacio de trabajo de archivos locales: references/local-file-workspace-governance.md

Estos recursos son métodos activos, no significan que el proyecto ya haya adoptado la plantilla; solo el .project-steward/project.json leído explícitamente por un consumidor formal constituye el estado de la plantilla del proyecto.

Salida y Finalización

Primero dé la conclusión en la salida, luego explique el alcance, la evidencia, los elementos desconocidos y la siguiente acción. El análisis no debe escribirse como si ya se hubiera implementado; la verificación estructural no debe escribirse como si se hubiera establecido una cadena de usuario real; la verificación del comportamiento de la tarea actual no debe escribirse como si se hubiera probado un arranque en frío independiente.

Cuando haya un gráfico de impacto, incluya al menos el productor, el límite de transporte o almacenamiento, el consumidor, el resultado final del usuario, la fuente de verdad única, la condición de salida de la ruta antigua y la entrada de aceptación. Cuando estén involucrados múltiples resultados históricos, informe la razón principal, el mecanismo de éxito, la brecha de capacidad, el propietario formal y el nivel de verificación de cada uno.

Solo informe finalización cuando la ruta activa, el método correspondiente, el consumidor formal, las pruebas deterministas y la cadena de usuario real autorizada para esta ronda sean todos consistentes.

Project Steward

¿Qué es Project Steward?

Preguntar en tu IA favorita

Documentación