Nexhorizons-Public/claude-regelwerk
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
5e0577a871667880313de1c2c4714bbc1f66d4c9
claude-regelwerk/AI/Regelwerk/projekte.md
T
Pascal MichelandClaude Opus 5 c064c729ed Regelwerk, Agenten, Skills und Werkzeuge veröffentlichen 
Erster Stand des öffentlichen Ausschnitts aus dem Vault. Die .gitignore
arbeitet als Positivliste: ausgeschlossen ist alles, eingeschlossen nur,
was ausdrücklich wieder aufgenommen wird. Notizen, Projekte, Finanzen,
das Sitzungsgedächtnis und settings.local.json bleiben damit außen vor.

Der Kundenname in AI/Regelwerk/seo.md ist durch eine neutrale
Bezeichnung ersetzt; die Regeln selbst sind unverändert.

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-09-17 22:38:15 +02:00

3.4 KiB
Raw Blame History

type, title, status, summary, tags, created, updated
type title status summary tags created updated
resource Projekte-Regeln reference Projekt-Tag mit Ableitungsregel, README als Einstieg, Verbindung zum Themen-Seed, Administrator-Anleitung und Dump-Ordner für Projekte in Code Projekte und Security - Compliance Projekte.
regelwerk
projekte
2026-08-03 2026-09-13

Projekte-Regeln

Gilt beim Anlegen oder Bearbeiten eines Projekts unter /Code Projekte oder /Security - Compliance Projekte.

  1. Projekte sollen alle Dokumente jeweils einen Tag erhalten. Beispiel: "RootCA - EnterpriseCA" soll #rootca-enterpriseca erhalten. Für alle Projekte umsetzen.

    Ableitung des Tags aus dem Ordnernamen (nachgetragen und freigegeben am 2026-09-05): Präfix active - oder inactive - weg, Kleinschreibung, ä→ae, ö→oe, ü→ue, ß→ss, dann " - " und übrige Leerzeichen zu -. So wird „Linux Härtung Rocky Linux - KS" zu #linux-haertung-rocky-linux-ks. Der Grund für die Festlegung: Das Cockpit-Projekt ordnet Sessions über genau diesen Tag den Projekten zu, und bis hierher stand nur das eine Beispiel. Der Bestand hält sich nicht überall daran; die Sessions von „Linux Härtung Rocky Debian Ubuntu - After Install" tragen #linux-haertung-after-install. Wer einen abweichenden Tag bewusst behält, trägt ihn als Feld projekt_tag in das Frontmatter des Projekt-README ein; das Cockpit liest genau dieses Feld und zeigt dann „(aus README)" (ergänzt am 2026-09-05, freigegeben am 2026-09-06).

  2. Für jedes Projekt soll eine kurze Administrator-Anleitung erstellt werden und im jeweiligen Projektordner abgelegt werden. Ausnahme (2026-09-13): Enthält das README selbst Einrichtung und Bedienung, darf es die Anleitung ersetzen. Im Oberseed steht dann „README als Anleitung", damit niemand eine fehlende Datei sucht.

  3. Das README ist der Einstieg. Der Oberseed verlinkt je Projekt das README.md, nicht eine Anleitung oder ein Design-Dokument. Beim nächsten Anfassen des README ergänzt du Links auf todo.md, tasks/lessons.md, CHANGELOG.md (falls vorhanden) und die Administrator-Anleitung. Das sind Dateien an festen Orten. Stände, Dumps und Plan-Tasks gehören nicht in diese Liste, sonst driftet sie.

  4. Projekt und Themenwissen verbinden. Gibt es im IT Workspace einen Themenordner zum selben Gegenstand, bekommt dessen Seed eine Zeile „Zugehöriges Projekt" mit Link aufs README. Die Oberseed-Zeile des Projekts nennt umgekehrt den Seed. Vault-Links bleiben außerhalb des Projekt-Repos: Das README geht nach Gitea, wo Wikilinks nur Text sind. Die Verbindung in Richtung Seed steht deshalb im Oberseed, nicht im README.

  5. Dump-Ordner heißen AI/secondbrain/<projekt-tag>-memory/, mit dem Tag aus Regel 1. Vier ältere Ordner tragen noch den Ordnernamen mit Präfix. Sie werden nicht umbenannt, weil Pfade im Harness-Gedächtnis und in Projektdateien darauf zeigen.

  6. Referenzprojekte, die nur Volltexte tragen (unter Security - Compliance), haben keinen Hub. Der Oberseed verlinkt den Volltext direkt. Das Ordnerpräfix active - ist der Projektstatus, status: reference in der Datei der Dokumentstatus. Das ist kein Widerspruch.

Referenzen

Reference in new issue View Git Blame Copy Permalink