Scoville Plan

Was macht Scoville Plan?

Bewahre die Projektausrichtung in überprüfbaren Repository-Dateien, ohne dass eine Planungs-CLI, ein MCP-Server, eine Datenbank, ein Journal oder ein verborgener Zustand erforderlich ist. Dieser Skill besitzt die Planungsdisziplin und die native Wartung von Plänen und Entscheidungen. Er zeichnet Entscheidungen auf, die Menschen bereits getroffen haben, und bewahrt eine materielle ungelöste Entscheidung als Vorschlag, bevor er um deren Lebenszyklus-Entscheidung bittet. Er verleiht abgeleiteten Entscheidungen keine Autorität und weist nicht nach, dass berichtete Arbeit tatsächlich stattgefunden hat.

Behalte die vollständige unterstützte format_version: 1 Funktionsoberfläche bei: schreibgeschützte Wiederherstellung, Einrichtung, Pläne, Arbeitseinheiten, Entscheidungen, Vorschläge, Lebenszyklus, Blocker, Beweise und enge Reparaturen. Verwende direkte native Bearbeitungen, ohne ein Projektwissensmerkmal zu entfernen oder neu zu interpretieren.

Bei explizitem Opt-out: Lese keine Referenzen, erstelle oder ändere keine Planungsdateien und mache keine vom Skill abgeleiteten Behauptungen. Wenn eine übergeordnete Projektanweisung dieses Plansystem erfordert, melde diesen genauen Konflikt. Ein gleichgeordneter Scoville-Opt-out schließt nur diesen gleichgeordneten aus.

Folge dem bestehenden Eigentümer

Löse Planungsanforderungen in dieser Reihenfolge:

1. System-, Sicherheits- und explizite Anweisungen für die aktuelle Anfrage;
2. Repository-Anweisungen und dessen bestehender kanonischer Planungsmechanismus;
3. ein vorhandenes unterstütztes natives Profil; und
4. die Standardeinstellungen dieses Skills für das, was sonst nicht spezifiziert ist.

Erstelle niemals einen zweiten Plan neben einem projekteigenen Plan. Wenn ein anderes dauerhaftes Planungssystem bereits den Zustand besitzt, verwende es und wende nur die Planungsqualitäts-Guardrails dieses Skills an, wo sie kompatibel sind. Ein Laufzeitplan ist ein wegwerfbarer Spiegel, niemals ein zweiter kanonischer Eigentümer.

Dieser Skill hat keine erforderliche ausführbare Abhängigkeit und ruft niemals eine Planungs-CLI auf. Sein gebündelter Python-Validator ist eine optionale, streng schreibgeschützte Strukturprüfung, niemals ein Schreibpfad. Beanspruche kein Locking, keine atomare Mehrdateien-Veröffentlichung, keine typisierte Mutationssicherheit oder semantischen Beweis. Verwende gewöhnliche, bereichsbezogene Dateiwerkzeuge und melde nur die tatsächlich durchgeführten Prüfungen.

Dieser Skill arbeitet unabhängig. Erfordere, installiere oder simuliere niemals Code, UI oder Scribe. Wenn ein gleichgeordneter Skill unabhängig anwendbar ist, komponiere nur dessen eigenen Implementierungs-, Schnittstellen- oder Formulierungsaspekt; seine Abwesenheit schwächt keine Planstruktur, keinen Lebenszyklus, keine Autorität und keine Beweisregeln.

Entscheide, ob eine dauerhafte Planung gerechtfertigt ist

Verwende einen Repository-Plan für mehrere abhängige Ergebnisse, materielle Abfolgen, Arbeit, die eine Unterbrechung oder Übergabe überstehen muss, oder einen verbindlichen Projektworkflow. Für eine kleine, umkehrbare Änderung implementiere und validiere direkt, es sei denn, das Projekt erfordert bereits eine verfolgte Arbeitseinheit.

Klassifiziere die Operation, bevor Details geladen werden:

Operation	Laden
Aktuelle Ausrichtung lesen oder Datensätze auflisten, ohne zu schreiben	read-only.md
Ein vollständig abwesendes Profil initialisieren	planning-granularity.md, native-plan-format.md, native-project-lifecycle.md und native-editing.md
Einen Plan erstellen oder umstrukturieren	planning-granularity.md, native-plan-format.md, native-project-lifecycle.md und native-editing.md
Eine Arbeitseinheit einfügen, verfeinern, verschieben, auswählen, blockieren, voranbringen oder entfernen	native-plan-format.md, native-work-items.md und native-editing.md
Eine explizite menschliche Entscheidung oder eine wesentliche mögliche Entscheidung aufzeichnen	native-decision-format.md, native-plan-format.md und native-editing.md
Einen explizit autorisierten Entscheidungsübergang anwenden	native-decision-format.md, native-plan-format.md und native-editing.md
Einen explizit autorisierten Annehmen-oder-Ablehnen-Batch anwenden	native-decision-format.md, native-decision-batches.md, native-plan-format.md und native-editing.md
Einen Plan aktivieren, abschließen oder stornieren	native-plan-format.md, native-project-lifecycle.md, native-work-items.md wenn sich die aktuelle Arbeit ändert, und native-editing.md
Native Planstruktur oder Lebenszyklus auditieren	native-plan-format.md; füge planning-granularity.md nur hinzu, wenn die Zerlegung beurteilt wird
Native Entscheidungsstruktur oder Lebenszyklus auditieren	native-decision-format.md
Nach nativen Schreibvorgängen validieren oder ein vollständiges unterstütztes Profil diagnostizieren	Führe die gebündelte Prüfung über profile-validation.md aus, lade dann nur die native Referenz, die für eine gemeldete Diagnose oder Korrektur benötigt wird

Lade keine Formatdetails für eine schreibgeschützte Statusantwort vor.

Wenn die Profilexistenz unbekannt ist, liste das Projektverzeichnis auf, bevor ein kanonischer Pfad gelesen wird. Wenn PROJECT_INDEX.md fehlt, versuche nicht, es zu lesen. Für einen explizit angeforderten neuen dauerhaften Plan behandle das aktuelle Arbeitsverzeichnis als Einrichtungsstamm, klassifiziere das vollständige Profil und initialisiere nur, wenn alle drei kanonischen Pfade vollständig abwesend sind. Wenn die Erstellung nicht angefordert wurde, melde, dass kein Profil existiert, anstatt implizit eines zu initialisieren. Bewahre ein partielles, fremdes, nicht unterstütztes oder absichtsungültiges Profil und stoppe.

Bewahre Autorität und Beweiskraft

• Erfinde niemals das Ziel, Nicht-Ziele, das Akzeptanzergebnis, den Blocker, die Abhängigkeit, den Beweis oder eine akzeptierte Lebenszyklusentscheidung. Behandle Implementierung, gewöhnliche Dokumentation, Quellcode, Stille und aktuelles Verhalten als Beweis, nicht als menschliche Autorisierung.
• Frage vor der Aktivierung, Stornierung, geändertem Umfang, schwächerer Akzeptanz, einem mehrdeutigen Nachfolger oder der Übernahme einer bloß möglichen materiellen Entscheidung.
• Wenn der Benutzer explizit eine Richtung auswählt, darum bittet, sie in den Projektregeln zu bewahren, oder eine anwendbare Projektanweisung unmissverständlich eine vom Menschen ausgewählte Richtung angibt, erstelle und akzeptiere die entsprechende Entscheidung, ohne erneut zu fragen. Verlinke jede betroffene veränderbare Arbeitseinheit.
• Wenn die Analyse nur eine mögliche materielle Entscheidung über Umfang, Architektur, öffentliches Verhalten, gespeicherte Daten, Sicherheit, Abhängigkeiten, Reversibilität, Akzeptanz, Migration oder Rollout aufdeckt, erstelle sie als proposed, verlinke jede betroffene veränderbare Arbeitseinheit, melde ihre Empfehlung, Alternativen, Kompromisse und praktische Auswirkungen und frage dann den Benutzer, sie zu akzeptieren, abzulehnen oder zu überarbeiten. Akzeptiere sie nicht vor dieser Antwort.
• Eine Anfrage, einen Vorschlag zu entwerfen, erstellt proposed. Eine klare Entscheidung, die angegebene Richtung aufzuzeichnen, autorisiert deren Akzeptanz. Lehne niemals eine Entscheidung ab, verwerfe sie oder ersetze sie ohne diese explizite Lebenszyklusentscheidung.
• Zu Beginn der Projektarbeit inventarisiere die Entscheidungs-Frontmatter, lese jeden Vorschlag, melde seine ID, seinen Titel, seine empfohlene Wahl und seine praktische Auswirkung und frage den Benutzer, ihn zu akzeptieren, abzulehnen oder zu überarbeiten. Wiederhole ungelöste Vorschläge bei der Übergabe. Nur abhängige Arbeit stoppt.
• Markiere eine Arbeitseinheit nur dann als done, nachdem du ihr Akzeptanzergebnis beobachtet und präzise Belege hinzugefügt hast. Eine Dateiformprüfung beweist nur die Struktur.
• Halte fehlgeschlagene oder partielle Arbeit auf in_progress, paused oder explizit blockiert.

Halte verhaltensvollständige Arbeitseinheiten

• Halte höchstens eine Arbeitseinheit in_progress, gleichgesetzt mit current_item. Dies schränkt die gleichzeitige Ausführung ein; es beschränkt einen Plan nicht auf eine Arbeitseinheit insgesamt.
• Teile unabhängig fortsetzbare Ergebnisse mit unterschiedlichen Akzeptanzgrenzen, Abhängigkeiten, Eigentümern oder Rollout-Zeitplänen in separate Arbeitseinheiten auf.
• Bewahre die Implementierungsreihenfolge innerhalb optionaler Schritte. Tests, Überprüfungen, Dokumentation und Freigabeprüfungen gehören in die Akzeptanz oder den Beweis, es sei denn, unabhängig angeforderte Liefergegenstände benötigen ihr eigenes fortsetzbares Ergebnis.
• Ändere erstellte Inhalte oder die Reihenfolge nur, während ein Element todo ist. Nachdem es begonnen hat, bewahre seinen Ausgangsansatz und aktualisiere nur den Live-Zustand.
• Halte Next action gleich der ersten konkreten Aktion, die noch nicht ausgeführt wurde. Sobald eine Implementierung existiert, bringe sie zur nächsten nicht beobachteten Prüfung, zum nächsten Build, Browser-Check, Review oder zur nächsten eigentümergeführten Verifikation.
• Wähle neue aktuelle Arbeit nur, wenn ihre Abhängigkeiten erledigt sind und der Nachfolger explizit ist. Verwende complete_and_advance nur, wenn der Abschluss und der genaue Ersatzstart beide als ein vorbereitetes Ergebnis gültig sind.
• Wenn die letzte tatsächliche Arbeit abgeschlossen ist, schließe ihre Arbeitseinheit und den Plan ab und setze den Projektindex auf Leerlauf. Erfinde niemals einen Nachfolger, nur um ihn aktiv zu halten.

Arbeite nativ und eng

Bestätige vor dem Schreiben das Projektverzeichnis, das unterstützte Format, den aktiven Plan, die aktuelle Arbeitseinheit, die betroffenen Bytes, das beobachtbare Ergebnis und den Akzeptanzbeweis. Verwende kontextgebundene Patches und bewahre nicht zusammenhängende Arbeit. Bereite eine vollständige Änderung über mehrere Dateien vor, bevor du ein Mitglied anwendest, während du anerkennst, dass direkte Bearbeitungen nicht atomar sind.

Nach dem Schreiben:

1. lies jede geänderte kanonische Datei erneut;
2. inspiziere die vollständige bereichsbezogene Diff;
3. überprüfe Index-Eigentum, Anzahl der aktiven Pläne, Status des aktuellen Elements, Schlüsselreihenfolge der Arbeitseinheiten, Abhängigkeitsreihenfolge und -zyklen, Entscheidungs- und Planreferenzen, Blocker, Lebenszyklusfelder, Beweise und Next action;
4. führe den gebündelten optionalen Validator über profile-validation.md aus, wenn sein Skript und Python bereits verfügbar sind, andernfalls führe die bereichsbezogene manuelle Inspektion durch und melde sie; und
5. zeichne nur den beobachteten Akzeptanzbeweis auf.

Stoppe bei nicht unterstütztem Format, gleichzeitigen Änderungen, mehrdeutiger Lebenszyklusautorität, ungültigem Zustand, dessen Reparatur die Absicht ändern würde, oder einem partiellen Mehrdateien-Übergang. Überschreibe das Problem nicht in scheinbare Gültigkeit.

Melde den dauerhaften Zustand

Führe mit dem Ergebnis des aktuellen Plans. Nenne geänderte kanonische Dateien, aktive und blockierte Arbeit, beobachtete Prüfungen, aufgezeichnete Beweise, ungelöste materielle Entscheidungen und die nächste konkrete Aktion. Unterscheide native Strukturinspektion von verhaltensorientierter Verifikation. Erzähle keine routinemäßigen Dateioperationen.