refactor(project): folders for streams and activities

content/en/docs/project/streams/fundamentals/_index.md

@@ -0,0 +1,4 @@
+---
+title: Fundamentals
+weight: 1
+---

content/en/docs/project/streams/fundamentals/cicd-definition/_index.md

@@ -0,0 +1,24 @@
+---
+title: Activity 'CI/CD Definition'
+linkTite: CI/CD Definition
+weight: 2
+---
+
+
+## Rationale
+
+In Gitops basierten Plattformen (Anm.: wie es zB. CNOE und Humanitec mit ArgoCD sind) trifft das klassische Verständnis von Pipelining mit finalem Pushing des fertigen Builds auf die Target-Plattform nicht mehr zu.
+
+D.h. in diesem fall is Argo CD = Continuous Delivery = Pulling des desired state auf die Target plattform. Eine pipeline hat hier keien Rechte mehr, single source of truth ist das 'Control-Git'. 
+
+D.h. es stellen sich zwei Fragen:
+1. Wie sieht der adaptierte Workflow aus, der die 'Single Source of Truth' im 'Control-Git' definiert? Was ist das gewünschte korrekte Wording? Was bedeuen CI und CD in diesem (neuen) Kontext ? Auf welchen Environmants laufen Steps (zB Funktionstest), die eben nicht mehr auf einer gitops-kontrollierten Stage laufen?
+2. Wie sieht der Workflow aus für 'Events', die nach dem CI/CD in die single source of truth einfliessen? ZB. abnahmen auf einer Abnahme Stage, oder Integrationsprobleme auf einer test Stage  
+
+## Aufgabe
+
+Es sollen existierende, typische Pipelines hergenommen werden und auf die oben skizzierten Fragestellungen hin untersucht und angepasst werden.
+In lokalen Demo-Systemen (mit oder ohne CNOE aufgesetzt) sollen die Pipeline entwürfe dummyhaft dargestellt werden und luffähig sein.
+Für den POC sollen Workflow-Systeme wie Dagger, Argo Workflow, Flux, Forgejo Actions zum Einsatz kommen. 
+
+

content/en/docs/project/streams/fundamentals/platform-definition/_index.md

@@ -0,0 +1,14 @@
+---
+title: Activity 'Platform Definition'
+linkTitle: Platform Definition
+weight: 1
+---
+
+### Rationale
+
+
+### Task
+
+
+
+