marcioaltoe/write-tasks

Aufgaben schreiben

Wandle docs/specs/<slug>/_prd.md (und _techspec.md, falls vorhanden) in den ausführbaren Aufgaben-Graphen um: eine task_NN.md pro Aufgabe plus _tasks.md, das Manifest, aus dem implement-task und der Roundfix-Daemon planen. Die Artefakte sind der Vertrag – eine neue Agenten-Sitzung muss eine Aufgaben-Datei aufnehmen und sie ohne weiteren Kontext als den Spezifikationsordner bauen können.

Licht-Ebenen-Planung

Eine Aufgabe mit complexity: low, die kein QA ist und keinen Govened Path deklariert, läuft auf der Licht-Ebene. Der Autor kann roundfix spec judge <slug> --stage tasks für einen beratenden Ebenen-Vorschlag ausführen, bevor der Planungs-Pull-Request zusammenführt; der Vorschlag steuert den Dispatch nicht.

Vorbedingungen

$ARGUMENTS benennt die Spezifikation. _prd.md muss existieren. Wenn _techspec.md bei einem Feature mit echter Architektur-Oberfläche fehlt, führe zuerst write-techspec aus und zerlege dann – das Erstellen des fehlenden Artefakts ist die Auflösung, niemals ein Grund, für die Erlaubnis anzuhalten. Bei autonomer Arbeit benötigt dies keine Bestätigung: Das Anweisen autonomer Arbeit autorisiert die gesamte Autorenkette für jede bereits in der genehmigten Warteschlange befindliche Spezifikation, gemäß docs/agents/autonomous-work.md. Frage nur nach Akzeptanz, wenn du explizit angewiesen wurdest, ohne eine Tech-Spezifikation zu zerlegen, und gleiche dies dann durch tiefere Codebasis-Erkundung vor der Zerlegung aus.

Projekt-Einschränkungs-Vorabprüfung

Führe diese Vorabprüfung durch, bevor du eine Aufteilung ableitest oder genehmigst:

1. Klassifiziere die Spezifikation. Eine Spezifikation unter dem aufgelösten Archivverzeichnis (docs/history/specs/ für das eingebaute docs/specs-Root, oder <spec-root>/_archived/ für ein externes oder nicht standardmäßiges Root), oder eine, die nachweislich abgeschlossen wurde, bevor dieser Vertrag angewendet wurde, ist eine abgeschlossene oder archivierte Legacy-Spezifikation. Lasse jedes Legacy-Artefakt byte-identisch: Fülle nicht nach, formatiere nicht neu, generiere nicht neu oder überschreibe es auf andere Weise.
2. Verlange für jede aktive, nicht archivierte und noch nicht abgeschlossene Spezifikation, dass das PRD und jede vorhandene TechSpec vollständige Abschnitte „Project Constraints“ enthalten. Jeder Abschnitt muss Identifier strategy, Authentication and HTTP, Active ADR obligations und Tooling authority als zutreffend oder nicht zutreffend mit einem Grund enthalten, und jede Zeile muss ihren wirksamen docs/agents/-Quellpfad angeben.
3. Wenn eines der aktiven Artefakte fehlt oder unvollständig ist, weigere dich, _tasks.md oder eine Aufgaben-Datei zu erstellen oder zu aktualisieren. Benenne jede fehlende Zeile, Grund oder Quellpfad und sende die Spezifikation zurück zum besitzenden Autoren-Skill.
4. Überprüfe die vorgeschlagenen Scheiben auf Erstellung, Bearbeitung, Umbenennung, Verschiebung oder Löschung von Repository-Tooling-Konfiguration, Skripten, Ignore-Dateien, Plugin-Deklarationen oder Versions-Pins. Solche Arbeit ist nur autorisiert, wenn das PRD und die vorhandene TechSpec die Autorisierung des Maintainers und die genauen begrenzten, repository-relativen Dateien, die sie abdeckt, aufzeichnen. Eine generische Implementierungsanfrage, Setup-Genehmigung oder Aufgaben-Zuweisung ist keine Autorisierung. Ohne sowohl die Autorisierung als auch die begrenzten Dateien verweigere die Zerlegung.
5. Löse den wirksamen Datensatz in <spec-root>/<slug>/_authorization.md für jede Tooling-Scheibe auf. Ein fehlender Datensatz, ein proposed-Datensatz oder ein Datensatz ohne Gewährungsdatum autorisiert nichts; verweigere die Zerlegung, bis eine wirksame Gewährung existiert. Eine neue oder erweiterte Gewährung muss in der Ziel-Abstammung landen, bevor der verbrauchende Squash-Delivery, also kann die Gewährung oder Änderung nicht in die Änderung eingefaltet werden, die sie autorisiert.
6. Kopiere die begrenzte Dateiliste in den Umfang und die Akzeptanzkriterien jeder autorisierten Tooling-Aufgabe. Die Aufgabe darf nur diese Pfade plus ihre eigene Aufgaben-Datei ändern; teile jede Arbeit, die eine andere Grenze benötigt.
7. Die operations-Liste des Datensatzes muss jede Delivery-Operation gewähren, die die Spezifikation verwenden wird. roundfix deliver start weigert sich mit einem Datensatz, dem implement, commit, push, pull_request oder merge fehlt; eine Spezifikation ohne Govened Path zeichnet paths: [] auf.
8. Ein Aufgaben-Commit behält eine unversionierte ausführbare Datei nur, wenn ihr genauer Pfad unter Dateien im Autorisierungsdatensatz der Spezifikation aufgeführt ist; jede andere unversionierte ausführbare Datei wird abgelehnt. Die Liste muss vor dem Lesen des Runs auf dem Delivery-Ziel sein. QA Report- und Batch-Commits behalten niemals eine unversionierte ausführbare Datei. Ein Repository mit core.fileMode false zeichnet die Datei als 100644 auf.

Abhängigkeiten bleiben nur von _tasks.md besessen; der Aufgabenstatus bleibt nur von jeder Aufgaben-Datei besessen. Die Vorabprüfung verschiebt keine der beiden Verantwortlichkeiten.

Code für ein anderes Betriebssystem wird überprüft, indem sein Nicht-Test-Code für dieses System gebaut wird, mit einem Beispiel wie GOOS=windows go build -buildvcs=false ./<package>, und niemals mit go vet, das auch für den Host geschriebene Tests kompiliert.

Eigentumsregeln (was lebt wo und warum)

• Abhängigkeiten leben nur im _tasks.md-Graphen. Niemals in Aufgaben-Dateien. Zwei Kopien einer Kante bedeuten, dass Graphen auseinanderdriften.
• Status lebt nur im Frontmatter jeder Aufgaben-Datei. _tasks.md besitzt die Topologie, nicht den Fortschritt – Planer lesen Aufgaben-Dateien für den Status neu ein.
• Aufgabentyp ist in jeder Aufgaben-Datei erforderlich. Verwende genau einen von backend, frontend, data, infra, docs, test, chore oder qa. Halte qa für das eindeutige, erstellte Terminal-Gate, das durch das qa:-Feld des Manifests benannt wird, reserviert. Der Implementierungsbefehl verwendet diesen Wert für das Routing und lehnt fehlende oder unbekannte Werte ab; lasse niemals einen Platzhalter oder leite den Typ später ab.
• Inhaltsreferenzen, niemals Duplikate. Aufgaben-Dateien verweisen auf PRD/TechSpec-Abschnitte mit Namen; eine Aufgabe, die die Spezifikation neu formuliert, wird beim ersten Mal veraltet, wenn die Spezifikation ergänzt wird. Verlinke eine übernommene Quelle an ihrem Pfad nach der Übernahme in der besitzenden Spezifikation mit einem Ziel relativ zu dieser Aufgaben-Datei, niemals an ihrem Provenienz-Pfad vor der Übernahme. Eine sekundäre Spezifikation verlinkt die Kopie des primären Besitzers und übernimmt nichts. Das Archiv des Besitzers führt eine Archiv-Neuverlinkung durch: Es befördert diese Kopie zu docs/references/ und schreibt die Links der sekundären Spezifikation neu, sodass die Quelle einen Besitzer behält und die sekundäre Spezifikation keine Kopie benötigt (ADR-0260, ADR-0083).
• Kontexteinträge sind beschriftete Pfade. Füge ## Context nur hinzu, wenn die Aufgabe spezifische Anweisungen oder Schnittstellenpfade über das Standard-Spezifikationsbündel hinaus benötigt. Verwende Aufzählungspunkte in der Form - instruction: <path>, - interface: <path>, - creates: <path> oder - deletes: <path>. Pfade müssen sauber, repository-relativ und eindeutig sein; eine Aufgabe darf höchstens 50 eindeutige Einträge deklarieren. Der Daemon reserviert diese Pfade, bevor er das 200-Pfade umfassende Spezifikationskontextbündel mit zuvor geänderten Dateien füllt.
• Deklarierte Bearbeitungen und Governed Paths sind explizit. Jeder Pfad, den eine Aufgabe bearbeitet, wird unter interface: oder creates: deklariert; jeder Pfad, den sie entfernt, wird nur unter deletes: deklariert, niemals unter interface: und niemals unter instruction:. Eine Aufgabe, die eine Datei liest, bevor sie sie entfernt, listet sie trotzdem einmal, unter deletes:. Ein Löschvorgang wird von -Prüfungen auf ungelöste Referenzen übersprungen und zählt in Umfangs-, Governed Path- und Wave-Kollisionsprüfungen. Der Daemon lehnt die Abrechnung vor der Verifizierung ab, wenn ein deklarierter Löschvorgang noch existiert, mit deletes: <path> still exists. Ein instruction:-Pfad ist schreibgeschützt und lässt niemals zwei Aufgaben kollidieren. Jede Aufgabe, die einen Befehl ändert, deklariert die eine Befehlsdatei, die sie ändert: .agents/skills/roundfix/references/<command>.md mit seinem Spiegel und docs/user-guide/commands/<command>.md, niemals das SKILL.md oder commands.md des Skills, es sei denn, sie ändert die Einstiegsdatei selbst. Zwei Aufgaben, die dieselbe Datei deklarieren, können keine Wave teilen, sodass Aufgaben, die verschiedene Befehle ändern, zusammen ausgeführt werden können und Aufgaben, die denselben Befehl ändern, eine Kante zwischen ihnen benötigen. deklarierter oder verifizierungsgelesener Governed Path muss in paths: der _authorization.md der Spezifikation und in beiden bounded files:-Zeilen erscheinen, oder das Authoring wird mit SC-TOOLING-UNDECLARED abgelehnt. Eine Aufgabe, die eine CLI-Oberfläche benennt, benennt ihr Skill oder ihre Anleitung selbst oder durch eine Aufgabe, von der sie abhängt; andernfalls wird sie mit SC-CLI-UNDOCUMENTED gemeldet.

Der Daemon zeichnet einen Pfad, den eine Aufgabe geändert hat, ohne ihn deklariert zu haben, beim Commit unter ## Recorded paths auf. Die QA-Umfangsprüfung zählt diesen aufgezeichneten Pfad als deklariert, und das Aufzeichnen legt eine Änderung offen und reserviert nichts. Das Deklarieren jedes vorhersehbaren Pfades bleibt die Regel.

Ein Test-Helfer, -Attrappe, -Fixture oder -Goldener Wert, den zwei Aufgaben jeweils ändern können, ist ein vorhersehbarer Pfad. Deklariere ihn unter interface: in jeder Aufgabe, die ihn ändern könnte, damit roundfix spec check --strict SC-WAVE-KOLLISION meldet, während die Spezifikation noch erstellt wird, und die needs-Kante, die es benennt, diese Aufgaben in Reihe ausführt. Das Aufzeichnen reserviert nichts, und eine abgeschlossene Aufgabe kollidiert niemals: Der Abrechnungs-Commit einer Aufgabe ist nur Kollisionsnachweis, während eine der beiden Aufgaben nicht abgeschlossen ist, z.B. eine Aufgabe, die zu pending wiedereröffnet wurde, sodass zwei Aufgaben einer Wave, die beide nach dem Ändern derselben undeklarierten Datei abgeschlossen werden, niemals abgelehnt werden. Das Deklarieren der Datei ist der einzige Schutz.

Skills-Aufgaben für geänderte Verhaltensoberflächen

Lese die Skill-Abdeckungskarte des Repositorys unter docs/references/skill-coverage.json, wenn sie existiert. Füge für jede abgedeckte Verhaltensoberfläche, deren Quelle eine Nicht-QA-Aufgabe unter interface:, creates: oder deletes: deklariert, eine Nicht-QA-Skills-Aufgabe ein, die eine ihrer abdeckenden Skill-Dateien unter interface: oder creates: deklariert. SC-SKILLS-UNTASKED meldet eine Oberfläche ohne solche Aufgabe.

Wenn die Änderung keinen Skill-Text benötigt, zeichne - unchanged: <surface id> — <reason> im optionalen ## Skills-Abschnitt des PRDs auf und füge eine Nicht-QA-Aufgabe ein, die die Karte unter interface: oder creates: deklariert, um die Abdeckungsprüfung aufzuzeichnen. Der Eintrag allein entschuldigt die Oberfläche nicht. SC-SKILLS-MALFORMED meldet einen Eintrag anderer Form, eine unbekannte Oberfläche oder einen leeren Grund. Beide Regeln beginnen mit dem Commit, der die Karte hinzugefügt hat; Repositorys ohne eine überspringen sie.

Eine Nicht-QA-Aufgabe, die eine Markdown-Seite unter docs/user-guide/ unter interface:, creates: oder deletes: deklariert, muss auch docs/references/behavior-surfaces.json unter interface: oder creates: deklarieren und den -record-skill-coverage-Schritt in einer Anforderung benennen. Eine andere Aufgabe kann sie nicht abdecken: Die Abrechnung der Anleitungsaufgabe selbst überprüft ihren Fingerabdruck. Die _authorization.md-Einschränkungen der Spezifikation dürfen diesen Datensatz niemals verbieten. SC-SURFACE-RECORD-UNTASKED meldet eine der beiden Lücken von der Aufgabenphase, ohne Horizont, in Repositorys, die den Datensatz haben.

Zerlegungsregeln

Code für ein anderes Betriebssystem wird überprüft, indem sein Nicht-Test-Code für dieses System gebaut wird, mit einem Beispiel wie GOOS=windows go build -buildvcs=false ./<package>, und niemals mit go vet, das auch für den Host geschriebene Tests kompiliert.

• Vertikale Scheiben. Jede Aufgabe liefert einen schmalen, aber vollständigen Pfad durch jede Ebene, die sie berührt, demonstrierbar oder überprüfbar für sich allein – eine Tracer Bullet, keine Ebene („alle Schemata“ ist eine falsche Aufgabe; „abgelaufene Importe wiederholen und ihren Status anzeigen“ ist eine richtige).

• Vorab-Umgestaltung zuerst. Wenn eine Scheibe die Vorbereitung des Bodens benötigt, mache dies zu ihrer eigenen führenden Aufgabe: Mache die Änderung einfach, dann mache die einfache Änderung.

• Charakterisiere externe Oberflächen während des Authorings. Wenn eine Spezifikation eine externe Oberfläche wie einen Adapter, Vertrag oder eine Datenbank kreuzt, erstelle eine Charakterisierungsaufgabe, die aufzeichnet, was die reale Grenze tut, nicht was eine Attrappe tut, damit eine nicht unterstützte Prämisse fehlschlägt, während die Spezifikation noch erstellt wird, und nicht am QA-Gate.

  Liste es in needs auf, nicht nur früher in der Datei. Jede Aufgabe, deren Prämisse von der Charakterisierung abhängt, benennt diese Aufgabe in ihrem needs-Eintrag in _tasks.md. Ausführungswellen werden allein aus needs gebaut, sodass eine Aufgabe, die nur später im Manifest erscheint, in derselben Welle wie die Charakterisierung, von der sie abhängt, ausgeführt werden kann und eine Grenze liest, die noch niemand charakterisiert hat. Dateireihenfolge ist keine Abhängigkeit.

  Eine Charakterisierungsaufgabe berührt eine reale Grenze, also binde sie explizit. Ihre Datei gibt das Ziel an, das sie erreichen wird, mit Namen. Sie liest eher, als dass sie schreibt, oder läuft gegen eine isolierte Instanz, die die Aufgabe selbst erstellt und entfernt; sie charakterisiert niemals standardmäßig gegen gemeinsamen oder Produktionszustand. Sie verwendet Anmeldeinformationen, die auf dieses Ziel beschränkt sind und nicht weiter, respektiert den Abbruch und räumt auf, was sie erstellt hat, selbst wenn sie fehlschlägt. Eine Charakterisierung, die schreiben muss, erfordert, dass dieses Schreiben in der Aufgabe autorisiert wird, wie jede andere irreversible Aktion – das Aufzeichnen, was eine Grenze tut, ist keine Befugnis, sie zu ändern.

  Ihre Verifizierung behauptet den Datensatz, niemals die Grenze. Der Daemon führt die deklarierten ## Verification-Befehle einer Aufgabe wörtlich über die Shell aus, einmal gegen den unveränderten Baum, bevor die Agentenrunde existiert, und erneut bei der Abrechnung. Nichts in diesem Pfad liest die obigen Grenzen: Sie beschränken den Agenten, und der Daemon ist nicht der Agent. Eine Verifizierung, die die reale Oberfläche erreicht, erreicht sie daher unbegrenzt, zweimal, einschließlich bevor irgendeine Arbeit erledigt wurde. Verifiziere die Charakterisierung, die die Aufgabe aufgezeichnet hat – ihre Form, ihre Anwesenheit, was nachgelagerte Aufgaben lesen werden – und lasse den Grenzaufruf in der Agentenrunde, wo das deklarierte Ziel, die Isolation, die Anmeldeinformationen und die Schreibautorisierung der Aufgabe gelten. Dies ist die Hermetizitätsregel, die diese Befehle bereits tragen, ausgesprochen, wo die Versuchung, sie zu brechen, am stärksten ist: Eine lebende externe Oberfläche ist Umgebungszustand, und ein Befehl, der von einer abhängt, ist nicht hermetisch.

• Bemessen für eine frische Sitzung. Eine Aufgabe, die ein Agent in einer einzigen Sitzung mit einem frischen Kontext abschließen kann. Mehr als ~7 Unteraufgaben oder Dateien bedeuten, teile sie auf.

• Tests eingebettet, niemals getrennt. Die Akzeptanzkriterien jeder Aufgabe enthalten ihre eigenen Tests; eine nachlaufende „schreibe die Tests“-Aufgabe bedeutet, dass die früheren Aufgaben niemals erledigt waren.

• Unabhängig implementierbar. Sobald ihre needs abgeschlossen sind, darf eine Aufgabe keine andere unfertige Arbeit erfordern – das ermöglicht die parallele Ausführung über Arbeitsbäume hinweg später.

• Verifizierung muss hermetisch, portabel, wirkungsbeweisend und vom Daemon verwaltet sein. Die ## Verification-Befehle jeder Aufgabe müssen in einem frischen Arbeitsbaum mit on erfüllbar sein

…

[Gekürzt für Übersetzung]