Scoville Plan

¿Qué hace Scoville Plan?

Mantén la dirección del proyecto en archivos de repositorio revisables sin necesidad de una CLI de planificación, servidor MCP, base de datos, diario o estado oculto. Esta habilidad es dueña de la disciplina de planificación y del mantenimiento nativo de Planes y Decisiones. Registra las elecciones que los humanos ya han tomado y preserva una elección material no resuelta como una propuesta antes de solicitar su decisión de ciclo de vida. No otorga autoridad a elecciones inferidas ni demuestra que el trabajo reportado ocurrió.

Mantén la superficie de características completa de format_version: 1: recuperación de solo lectura, configuración, Planes, Elementos de Trabajo, Decisiones, propuestas, ciclo de vida, bloqueadores, evidencia y reparación limitada. Utiliza ediciones nativas directas sin eliminar o reinterpretar una característica de conocimiento del proyecto.

En caso de exclusión explícita, no leas referencias, crees o cambies archivos de planificación, ni hagas afirmaciones derivadas de la habilidad. Si una instrucción de proyecto de mayor prioridad requiere este sistema de Planes, reporta ese conflicto exacto. Una exclusión hermana de Scoville excluye solo a esa hermana.

Sigue al propietario existente

Resuelve los requisitos de planificación en este orden:

1. instrucciones del sistema, de seguridad y explícitas para la solicitud actual;
2. instrucciones del repositorio y su mecanismo de planificación canónico existente;
3. un perfil nativo compatible existente; y
4. los valores predeterminados de esta habilidad para lo que aún no está especificado.

Nunca crees un segundo plan junto a un plan propiedad del proyecto. Si otro sistema de planificación duradero ya es dueño del estado, úsalo y aplica solo los guardarraíles de calidad de planificación de esta habilidad donde sea compatible. Un plan en tiempo de ejecución es un espejo desechable, nunca un segundo propietario canónico.

Esta habilidad no tiene dependencia ejecutable obligatoria y nunca invoca una CLI de planificación. Su validador Python incluido es una comprobación estructural opcional estrictamente de solo lectura, nunca una ruta de escritura. No claims de bloqueo, publicación atómica de múltiples archivos, seguridad de mutación tipificada o prueba semántica. Usa herramientas de archivo con ámbito ordinario y reporta solo las comprobaciones realmente realizadas.

Esta habilidad funciona de forma independiente. Nunca requieras, instales o simules Code, UI o Scribe. Cuando una hermana es aplicable de forma independiente, compone solo su preocupación de implementación, interfaz o redacción propiedad; su ausencia no debilita la estructura del Plan, el ciclo de vida, la autoridad o las reglas de evidencia.

Decide si la planificación duradera está justificada

Usa un Plan de repositorio para múltiples resultados dependientes, secuenciación material, trabajo que debe sobrevivir a una interrupción o traspaso, o un flujo de trabajo de proyecto vinculante. Para un cambio pequeño y reversible, implementa y valida directamente a menos que el proyecto ya requiera un Elemento de Trabajo rastreado.

Clasifica la operación antes de cargar los detalles:

Operación	Cargar
Leer la dirección actual o listar registros sin escribir	read-only.md
Inicializar un perfil totalmente ausente	planning-granularity.md, native-plan-format.md, native-project-lifecycle.md, y native-editing.md
Crear o reestructurar un Plan	planning-granularity.md, native-plan-format.md, native-project-lifecycle.md, y native-editing.md
Insertar, refinar, mover, seleccionar, bloquear, avanzar o eliminar un Elemento de Trabajo	native-plan-format.md, native-work-items.md, y native-editing.md
Registrar una elección humana explícita o una Decisión posible material	native-decision-format.md, native-plan-format.md, y native-editing.md
Aplicar una transición de Decisión explícitamente autorizada	native-decision-format.md, native-plan-format.md, y native-editing.md
Aplicar un lote de aceptación o rechazo explícitamente autorizado	native-decision-format.md, native-decision-batches.md, native-plan-format.md, y native-editing.md
Activar, completar o cancelar un Plan	native-plan-format.md, native-project-lifecycle.md, native-work-items.md cuando el trabajo actual cambia, y native-editing.md
Auditar la estructura o el ciclo de vida del Plan nativo	native-plan-format.md; añade planning-granularity.md solo al juzgar la descomposición
Auditar la estructura o el ciclo de vida de la Decisión nativa	native-decision-format.md
Validar después de escrituras nativas o diagnosticar un perfil compatible completo	Ejecuta la comprobación incluida a través de profile-validation.md, luego carga solo la referencia nativa necesaria para un diagnóstico o corrección reportada

No precargues detalles de formato para una respuesta de estado de solo lectura.

Cuando se desconoce la existencia de un perfil, lista la raíz del proyecto antes de leer cualquier ruta canónica. Si PROJECT_INDEX.md está ausente, no intentes leerlo. Para un nuevo Plan duradero explícitamente solicitado, trata el espacio de trabajo actual como la raíz de configuración, clasifica el perfil completo e inicializa solo cuando las tres rutas canónicas estén totalmente ausentes. Si no se solicitó la creación, reporta que no existe ningún perfil en lugar de inicializar uno implícitamente. Preserva y detente en un perfil parcial, externo, no compatible o de intención inválida.

Preserva autoridad y evidencia

• Nunca inventes el Objetivo, los No objetivos, el resultado de aceptación, el bloqueador, la dependencia, la evidencia o una elección de ciclo de vida aceptada. Trata la implementación, la documentación ordinaria, el código fuente, el silencio y el comportamiento actual como evidencia, no como autorización humana.
• Pregunta antes de la activación, cancelación, cambio de alcance, aceptación más débil, un sucesor ambiguo o la adopción de una elección material meramente posible.
• Cuando el usuario selecciona explícitamente una dirección, solicita preservarla en reglas del proyecto, o una instrucción aplicable del proyecto indica inequívocamente una dirección seleccionada por humanos, crea y acepta la Decisión correspondiente sin preguntar de nuevo. Vincula cada Elemento de Trabajo mutable afectado.
• Cuando el análisis solo revela una Decisión posible material sobre el alcance, la arquitectura, el comportamiento público, los datos almacenados, la seguridad, las dependencias, la reversibilidad, la aceptación, la migración o la implementación, créala como proposed, vincula cada Elemento de Trabajo mutable afectado, reporta su recomendación, alternativas, compensaciones y efecto práctico, luego pide al usuario que la acepte, rechace o revise. No la aceptes antes de esa respuesta.
• Una solicitud para redactar una propuesta crea proposed. Una elección clara de registrar la dirección indicada autoriza su aceptación. Nunca rechaces, deprecas o supersedas una Decisión sin esa elección explícita de ciclo de vida.
• Al inicio del trabajo del proyecto, inventaria el frontmatter de las Decisiones, lee cada propuesta, reporta su ID, título, elección recomendada y efecto práctico, y pide al usuario que la acepte, rechace o revise. Repite las propuestas no resueltas en el traspaso. Solo se detiene el trabajo dependiente.
• Marca un Elemento de Trabajo como done solo después de observar su resultado de Aceptación y añadir evidencia concisa. Una comprobación de forma de archivo solo prueba la estructura.
• Mantén el trabajo fallido o parcial como in_progress, paused o explícitamente bloqueado.

Mantén Elementos de Trabajo completos en comportamiento

• Mantén como máximo un Elemento de Trabajo in_progress, igual a current_item. Esto limita la ejecución concurrente; no limita un Plan a un solo Elemento de Trabajo en total.
• Divide los resultados reanudables de forma independiente con límites de aceptación distintos, dependencias, propietarios o tiempos de implementación en Elementos de Trabajo separados.
• Mantén el orden de implementación dentro de Pasos opcionales. Las pruebas, revisiones, documentación y comprobaciones de lanzamiento pertenecen a Aceptación o Evidencia a menos que los entregables solicitados de forma independiente necesiten su propio resultado reanudable.
• Cambia el contenido o el orden creado solo mientras un elemento está todo. Después de que comience, preserva su enfoque inicial y actualiza solo el estado vivo.
• Mantén Next action igual a la primera acción concreta aún no realizada. Una vez que existe la implementación, avanza a la siguiente prueba no observada, compilación, verificación del navegador, revisión o verificación propiedad del evaluador.
• Selecciona nuevo trabajo actual solo cuando sus dependencias estén completas y el sucesor sea explícito. Usa complete_and_advance solo cuando la finalización y el reemplazo exacto de inicio sean ambos válidos como un resultado preparado.
• Cuando el trabajo real final se complete, completa su Elemento de Trabajo y Plan y establece el índice del proyecto en inactivo. Nunca inventes un sucesor solo para mantenerlo activo.

Trabaja de forma nativa y estrecha

Antes de escribir, confirma la raíz del proyecto, el formato compatible, el Plan activo, el Elemento de Trabajo actual, los bytes afectados, el resultado observable y la evidencia de aceptación. Usa parches limitados al contexto y preserva el trabajo no relacionado. Prepara un cambio completo de varios archivos antes de aplicar cualquier miembro, reconociendo que las ediciones directas no son atómicas.

Después de escribir:

1. vuelve a leer cada archivo canónico cambiado;
2. inspecciona el diff de alcance completo;
3. verifica la propiedad del índice, el recuento de Planes activos, el estado del elemento actual, el orden de las claves de los Elementos de Trabajo, el orden y los ciclos de dependencia, las referencias de Decisión y Plan, los bloqueadores, los campos del ciclo de vida, la Evidencia y Next action;
4. ejecuta el validador opcional incluido a través de profile-validation.md cuando su script y Python ya estén disponibles, de lo contrario, realiza y reporta la inspección manual de alcance; y
5. registra solo la evidencia de aceptación observada.

Detente en formato no compatible, cambios concurrentes, autoridad de ciclo de vida ambigua, estado inválido cuya reparación alteraría la intención, o una transición parcial de varios archivos. No sobrescribas el problema para que parezca válido.

Reporta el estado duradero

Lidera con el resultado actual del Plan. Nombra los archivos canónicos cambiados, el trabajo activo y bloqueado, las comprobaciones observadas, la evidencia registrada, las elecciones materiales no resueltas y la siguiente acción concreta. Distingue la inspección estructural nativa de la verificación de comportamiento. No narres operaciones de archivo rutinarias.