Was macht ein gutes Markdown-Plan-Dokument für ein Softwareentwicklungsprojekt aus? Was ist der Unterschied zwischen einem guten Plan und einem großartigen? Ich rede immer wieder darüber, wie ich über 85 % meiner Zeit und Energie in die Planungsphasen investiere. Was genau bedeutet das? Es ist schwer, das abstrakt zu erklären; man braucht ein greifbares Beispiel, um die Nuancen wirklich zu veranschaulichen. Deshalb dachte ich, ich teile ein gutes Beispiel von heute. Das beantwortet auch eine kürzliche Frage, die ich zu meinem Ansatz erhalten habe. Die Leute scheinen den Eindruck zu haben, dass man alles in seinem Projekt auf einmal erledigen muss. Und in meinem Ansatz ist das wahr, aber nur für Version 1! Wenn du entscheidest, dass du neue Funktionen hinzufügen oder ändern möchtest, wie die Dinge funktionieren, kannst du das natürlich tun, sobald du ein funktionierendes v1 hast. Und der Weg, wie du das machst, ist derselbe, wie du v1 erstellst, indem du zuerst einen super detaillierten Markdown-Plan erstellst und ihn dann in Beads umwandelst. Ich gebe dir ein Beispiel von Cass, meinem Coding Agent Session Search Programm, das ein ziemlich aufwendiges Rust-Programm ist, das automatisch alle deine vorherigen Sitzungsprotokolle von fast jedem Coding-Agenten erkennt, analysiert, speichert und indiziert. Es bietet eine sofortige "Suche während der Eingabe" mit weniger als 50 ms über all diese Protokolle und hat viele andere schöne Funktionen. Ich habe beschlossen, dass ich eine Funktion zu Cass hinzufügen möchte, die einer Funktion ähnelt, die ich bereits in MCP Agent Mail und in beads_viewer (bv) habe: die Möglichkeit, dein Setup als statische Website zu exportieren, die mit GitHub Pages bereitgestellt werden kann. Du kannst ein Beispiel für bv für dieses Projekt sehen, das das Endergebnis des Planungsprozesses ist, den ich in diesem Beitrag beschreiben werde: Diese Funktionalität macht es sehr schnell und einfach, die exportierte Website mit dem gh-Utility zu generieren und bereitzustellen. Die Website selbst besteht normalerweise aus einer SQLite-Datei und einer Menge TypeScript und WASM, die vollständig im Browser ausgeführt werden, aber mit sehr guter Leistung und schönen Funktionen und Styling, die du im gerade gegebenen Beispiel beobachten kannst. Nun, das Teilen von MCP Agent Mail-Nachrichten oder einer Menge von Beads ist eine Sache, aber das Teilen einer Menge von Sitzungsprotokollen von Coding-Agenten ist sehr unterschiedlich; diese Dinge sind oft voller sensibler Informationen, API-Schlüssel, Flüche/Beleidigungen (zumindest meine sind es!), und anderem Material, das du definitiv nicht der Welt aussetzen möchtest. Aber GitHub Pages, so schön sie auch ist, funktioniert nur für öffentliche Repos (übrigens unterstützen meine Tools auch Cloudflare-Seiten, aber GH Pages ist besser und einfacher für diesen Anwendungsfall). Wie geht man also mit diesen Problemen um? Die Antwort ist Verschlüsselung: Der Benutzer wählt zuerst aus, welche Coding-Agenten einbezogen werden sollen, welche Projektordner, den Zeitraum usw., und ein Bundle wird generiert (beachte, dass dieses Bundle im kanonischen Format vorliegt, in das Cass intern alle Coding-Agent-Nachrichten von ihren ursprünglichen nativen Formaten umwandelt) und dann gibt der Benutzer ein Passwort zur Verschlüsselung dieses Bundles an. Die Idee ist, dass, obwohl das Repo und die Webseite öffentlich sind, jeder außer dir und anderen, denen du das Passwort sagst, einfach ein Passwortfeld sehen wird und keine der Nachrichten lesen kann. ...