Pascal MichelandClaude Opus 5
246af19683
- .vault-tools/plan-kopie/LIESMICH.md - .vault-tools/plan-kopie/rot_nachweis.py - .vault-tools/trading-plattform-pruefung/LIESMICH.md - .vault-tools/trading-plattform-pruefung/dienste_stand.sh - .vault-tools/trading-plattform-pruefung/ha_einrichten.py - .vault-tools/trading-plattform-pruefung/hole_kerzen.py - .vault-tools/trading-plattform-pruefung/neustart_echtlauf.py - .vault-tools/trading-plattform-pruefung/ntfy_lesen.py - .vault-tools/trading-plattform-pruefung/pause_echtlauf.py - .vault-tools/trading-plattform-pruefung/wiederanlauf_probe.ps1 - AI/Regelwerk/codeworkflow.md - AI/Regelwerk/projekte.md - … und 2 weitere Erzeugt vom PostToolUse-Hook .vault-tools/auto-push/auto_push.py. Co-Authored-By: Claude Opus 5 <[email protected]>
32 lines
4.1 KiB
Markdown
32 lines
4.1 KiB
Markdown
---
|
|
type: resource
|
|
title: "Projekte-Regeln"
|
|
status: reference
|
|
summary: "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."
|
|
tags: [regelwerk, projekte]
|
|
created: 2026-08-03
|
|
updated: 2026-09-20
|
|
---
|
|
|
|
# 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.
|
|
7. **Wiederkehrende Arbeit im Projekt wird ein Playbook** (angeordnet am 2026-09-20). Steht in einem Projekt etwas immer wieder an (Monatsbericht, Rezertifizierung, Update-Runde), wird daraus ein Skill nach [[AI/Regelwerk/wiederkehrende-jobs|wiederkehrende-jobs.md]]: erst das Interview, dann die SKILL.md. Und jedes Projektergebnis, das Pascal abnimmt, bekommt vorher die „Fertig heißt“-Zeilen aus Abschnitt 3 derselben Datei — je Check bestanden oder nicht, mit Beleg, dazu das, was nicht prüfbar war. Das gilt auch für Dokumente unter Security - Compliance, nicht nur für Code.
|
|
|
|
## Referenzen
|
|
|
|
- [[CLAUDE|↑ Claude.md (Stamm)]]
|
|
- [[Code Projekte/_MOC-Code-Projekte|Code Projekte (Oberseed)]]
|
|
- [[Security - Compliance Projekte/_MOC-Security-Compliance|Security - Compliance Projekte (Oberseed)]]
|
|
- [[AI/Regelwerk/frontmatter|frontmatter.md]]: README-Frontmatter (`type: project`)
|
|
- [[AI/Regelwerk/wiederkehrende-jobs|wiederkehrende-jobs.md]]: Playbook, „Fertig heißt“, Ablage
|