A-TownChain-Okosystems · ShivaCoreDev · Sep 17, 2026 · Sep 17, 2026 · Sep 17, 2026 · Sep 17, 2026
diff --git a/.github/workflows/franchise-factory.yml b/.github/workflows/franchise-factory.yml
@@ -0,0 +1,30 @@
+name: Franchise Factory Quality Gates
+
+on:
+  push:
+    branches: [main]
+  pull_request:
+    paths:
+      - 'franchise_factory/**'
+      - '.github/workflows/franchise-factory.yml'
+
+permissions:
+  contents: read
+
+jobs:
+  franchise-factory:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v7
+      - uses: actions/setup-python@v6
+        with:
+          python-version: '3.11'
+      - name: Install Franchise Factory
+        working-directory: franchise_factory
+        run: python -m pip install -e '.[dev]'
+      - name: Ruff
+        working-directory: franchise_factory
+        run: ruff check gff tests
+      - name: Pytest
+        working-directory: franchise_factory
+        run: pytest -q
diff --git a/README.md b/README.md
@@ -12,16 +12,14 @@ ownership:
   organization: A-TownChain-Okosystems
 technology:
   primary_language: Rust
-governance:
-  security_class: S1
-  criticality: low
+  secondary_language: Python
 -->
 
 # ATC Genesis Engine
 
 [![ATC-COMPLIANCE](https://img.shields.io/badge/ATC-COMPLIANCE-v1.0-green)](./AGENTS.md)
 
-> General-purpose, modulare Game-Engine für ECS, Weltensimulation, Rendering, Physik, Audio, Animation, Networking, AI und Editor-Workflows.
+> General-purpose, modulare Game-Engine für ECS, Weltensimulation, Rendering, Physik, Audio, Animation, Networking, AI, Editor und Franchise-Production-Workflows.
 
 **Project:** `genesis-engine`  
 **Organization:** `A-TownChain-Okosystems`  
@@ -31,35 +29,41 @@ governance:
 
 ## Overview
 
-Genesis Engine ist die **general-purpose Game-Development-Plattform** des A-TownChain-Ökosystems. Die Engine stellt wiederverwendbare Runtime-, Simulations-, Tooling- und SDK-Funktionen bereit. `genesis-chronicles` ist ein unabhängiger Consumer/Flagship-Titel und keine technische Voraussetzung für die Engine.
-
-Die kanonische Cargo-Workspace-Struktur besteht aus den folgenden Modulen:
-
-| Modul | Verantwortung |
-|---|---|
-| `atc-genesis-animation` | Animation und Animationslaufzeit |
-| `atc-genesis-assets` | Asset-Verträge, Ressourcen und Content-Pipeline-Basis |
-| `atc-genesis-audio` | Audio-Runtime und Audio-Abstraktionen |
-| `atc-genesis-ecs` | Entity Component System und World/ECS-Bridge |
-| `atc-genesis-physics` | Physik-Abstraktion und Simulation |
-| `atc-genesis-platform` | Gemeinsame Primitive und Backend-Interfaces |
-| `atc-genesis-renderer` | Rendering-Abstraktion |
-| `atc-genesis-ui` | UI-Abstraktionen |
-| `atc-genesis-sdk` | Öffentliche Engine-/SDK-Schnittstellen |
-| `atc-genesis-ai` | AI-Integration |
-| `atc-genesis-network` | Networking und Replikation |
-| `atc-genesis-build` | Build- und Packaging-Funktionen |
-| `atc-genesis-tools` | Entwickler- und Engine-Tools |
-| `atc-genesis-cli` | Kommandozeilenwerkzeuge |
-| `atc-genesis-editor` | Editor-Funktionen |
-| `atc-genesis-input` | Input-Abstraktionen |
-| `atc-genesis-world` | Welt- und Chunk-Simulation |
-| `atc-genesis-gameplay` | Generische Gameplay-Systeme |
-| `atc-genesis-runtime` | Runtime-Orchestrierung und Subsystem-Lifecycle |
-
-Der **kanonische Runtime-Kern** ist damit `atc-genesis-runtime`. Ein Cargo-Paket `atc-genesis-engine` ist aktuell **kein Workspace-Mitglied**. Historische Dateien unter `modules/atc-genesis-engine/` dürfen nicht mit dem aktuellen Rust-Workspace verwechselt werden und müssen bei der weiteren Migration separat behandelt werden.
-
-Die Engine befindet sich im Rebuild und ist **nicht als Production-Ready oder finaler Releasezustand** zu verstehen.
+Genesis Engine ist die **general-purpose Game-Development-Plattform** des A-TownChain-Ökosystems. Die Engine stellt wiederverwendbare Runtime-, Simulations-, Tooling-, SDK- und Produktionsfunktionen bereit. `genesis-chronicles` ist ein unabhängiger Consumer/Flagship-Titel und keine technische Voraussetzung für die Engine.
+
+Die kanonische Cargo-Workspace-Struktur umfasst Runtime-, Simulation-, Rendering-, AI-, Networking-, Editor-, Build- und SDK-Module. Zusätzlich ist die **Genesis Franchise Factory** als integrierter Produktionssubsystem-Bereich unter `franchise_factory/` Bestandteil dieses Repositories.
+
+## Genesis Franchise Factory
+
+Die Franchise Factory ist jetzt im Genesis-Engine-Repository verankert und umfasst die vollständige Orchestrierungsbasis:
+
+- 17 AI-Produktions-Workflows
+- Franchise Core / AD-20 Pipeline
+- DAO-Modell / ATC-9900
+- Lifecycle Manager / AD-43
+- Typed Artifact + Provenance/Evidence Contracts
+- Game Factory Dependency Graph mit Build, QA und LiveOps
+- Python-Referenzimplementierung und integrierte Regressionstests
+- eigene Python-Quality-Gates in GitHub Actions
+
+```text
+franchise_factory/
+├── gff/
+│   ├── core.py
+│   ├── dao.py
+│   ├── lifecycle.py
+│   ├── spec_loader.py
+│   ├── workflows.py
+│   ├── artifacts.py
+│   └── game_factory.py
+├── tests/
+├── specs/
+└── docs/
+```
+
+Die Factory sitzt innerhalb der Engine-Plattform, ohne `genesis-chronicles` zur technischen Abhängigkeit zu machen. Provider, externe Side Effects und Chain-/VM-Anbindungen bleiben explizite Integrationsgrenzen und werden nicht als implementiert ausgegeben, solange keine Evidence vorliegt.
+
+Weitere Details: [`franchise_factory/README.md`](franchise_factory/README.md).
 
 ## Purpose
 
@@ -74,6 +78,7 @@ Genesis Engine ist für die generische Laufzeit- und Simulationsinfrastruktur de
 - AI- und Networking-Integration
 - Editor- und Entwicklerwerkzeuge
 - SDK- und Build-/Packaging-Infrastruktur
+- Franchise- und Game-Production-Orchestrierung über die integrierte Franchise Factory
 
 Spielspezifische Logik gehört in das jeweilige Spiel-Repository. Generische Features werden nur über den vorgesehenen Feature-Promotion-Prozess in die Engine übernommen.
 
@@ -93,31 +98,8 @@ AI / Network / Renderer / UI
      Runtime
        ↓
  Editor / Tools / CLI / Build / SDK
-```
-
-Die tatsächlichen Cargo-Abhängigkeiten sind maßgeblich; diese Darstellung ist ein Architekturmodell und ersetzt keine `Cargo.toml`-Definition.
-
-### Runtime data flow
-
-```text
-Input
-  ↓
-Fixed Simulation Tick
-  ├── ECS
-  ├── Gameplay
-  ├── Physics
-  ├── Animation
-  ├── AI
-  └── World / Streaming
-  ↓
-Authoritative State
-  ├── Network replication
-  ├── Audio
-  └── Render preparation
-          ↓
-       Renderer
-          ↓
-       Present
+       ↓
+ Franchise Factory / Production Orchestration
 ```
 
 ### Ecosystem Boundary
@@ -131,31 +113,23 @@ ATCLang / ATC-VM / A-TownChain
               │
               ▼
        Genesis Engine
-              │
-              ▼
-     Genesis Chronicles / Games
+        ┌─────┴─────┐
+        │           │
+ Franchise      Runtime/Editor
+ Factory             │
+        │            ▼
+        └──────► Games / Franchises
 ```
 
 Die Engine ist keine Blockchain, kein Kernel und kein Ersatz für ATC-VM oder ShivaCore. Chain-seitige Zustandsübergänge und Contracts bleiben an der vorgesehenen Chain-/VM-Grenze.
 
 ## Determinism
 
-Deterministische Simulation ist ein explizites Engine-Ziel. Für deterministische Pfade müssen insbesondere folgende Bereiche kontrolliert werden:
-
-- ECS-Iteration und Systemreihenfolge
-- RNG und Seeds
-- Gameplay-State
-- Physik
-- Welt-/Chunk-Streaming
-- Netzwerk-Ticks
-- Serialisierung
-- Replay-/State-Verification
-
-Ungeordnete Datenstrukturen dürfen auf einem deterministischen Simulationspfad nicht unkontrolliert die Ausführungsreihenfolge bestimmen.
+Deterministische Simulation ist ein explizites Engine-Ziel. Für deterministische Pfade müssen ECS-Iteration, RNG/Seeds, Gameplay-State, Physik, Streaming, Netzwerk-Ticks, Serialisierung und Replay/State-Verification kontrolliert werden.
 
 ## AI Boundary
 
-Externe oder asynchrone AI darf den deterministischen Simulationszustand nicht direkt verändern. Der Zielpfad ist:
+Externe oder asynchrone AI darf den deterministischen Simulationszustand nicht direkt verändern:
 
 ```text
 AI Inference
@@ -167,10 +141,12 @@ Deterministic Simulation
 State Change
 ```
 
+Die Franchise Factory folgt demselben Prinzip: Workflows sind provider-neutral; AI-Provider und externe Aktionen werden über injizierte Executor-Grenzen angeschlossen.
+
 ## Requirements
 
 - Rust >= 1.75 / Cargo
-- Python >= 3.11 für vorhandenes Tooling und historische Sync-Skripte
+- Python >= 3.11 für Franchise-Factory-Tooling und vorhandenes Tooling
 - Git >= 2.30
 
 ## Installation
@@ -179,6 +155,9 @@ State Change
 git clone https://github.com/A-TownChain-Okosystems/genesis-engine.git
 cd genesis-engine
 cargo build --workspace
+cd franchise_factory
+python -m pip install -e '.[dev]'
+pytest -q
 ```
 
 ## Testing
@@ -189,108 +168,37 @@ cargo check --workspace --all-targets
 cargo test --workspace --all-targets
 cargo clippy --workspace --all-targets -- -D warnings
 cargo doc --workspace --no-deps
-```
 
-Security-/Dependency-Prüfungen und Engine-spezifische Gates laufen zusätzlich über GitHub Actions.
+cd franchise_factory
+ruff check gff tests
+pytest -q
+```
 
 Testergebnisse sind Evidence. Ein erfolgreicher Testlauf bedeutet nicht automatisch `AUDITED` oder `PRODUCTION_READY`.
 
-## Development
-
-Entwicklung erfolgt nach den geltenden A-TownChain-Governance- und Repository-Standards. Commits müssen dem Conventional-Commit-Modell entsprechen.
-
-Vor größeren Änderungen sind mindestens `STATUS.md`, `AGENT_MANIFEST.md`, `ARCHITECTURE.md`, `ROADMAP.md` und die relevanten Governance-Dokumente zu prüfen.
-
-## Security
-
-Security Issues dürfen nicht öffentlich über GitHub Issues gemeldet werden. Sicherheitslücken sind über den offiziellen Security-Reporting-Prozess in `SECURITY.md` zu melden.
-
-**Security class:** S1  
-**Criticality:** low
-
-## Audit
-
-Der laufende Engineering-Audit wird in folgenden Dateien dokumentiert:
-
-- `docs/ENGINEERING_AUDIT.md` — Audit-Baseline und Evidenzstatus
-- `docs/ENGINEERING_AUDIT_FINDINGS.md` — Finding Registry und Remediation-Status
-
-Definition of Done für Findings:
-
-```text
-Finding
-  → Root Cause
-  → Fix
-  → Regression Test
-  → CI Verification
-  → Audit Evidence
-  → CLOSED
-```
-
 ## Documentation
 
 - `ARCHITECTURE.md` — technische Architektur
 - `STATUS.md` — aktueller Projektstatus
 - `ROADMAP.md` — Entwicklungs-Roadmap
+- `franchise_factory/README.md` — integrierte Franchise Factory
+- `franchise_factory/gff/` — Factory Runtime/Orchestration
 - `docs/ENGINEERING_AUDIT.md` — Audit-Baseline
 - `docs/ENGINEERING_AUDIT_FINDINGS.md` — Findings
-- `docs/specs/GEN-PROD-001-PRODUCT-STRATEGY.md` — Produktstrategie
-- `docs/REPOSITORY_STANDARD.md` — Repository-Standard
-- `a-townchain-os-docs` — zentrale Ökosystem-Dokumentation
 
 ## Governance
 
-Das Repository folgt dem A-TownChain-Governance-Modell. Architektur- und Governance-Entscheidungen müssen über die vorgesehenen Entscheidungs- und Review-Prozesse erfolgen.
-
-Canonical Standard-IDs werden ausschließlich über die Standards Registry und den dafür definierten Governance-Prozess vergeben. Die aktuelle Taxonomie verwendet Family-scoped IDs der Form `ATC-STD-Fxx-yyy`; bestehende Legacy-IDs bleiben historisch erhalten und werden nicht stillschweigend umnummeriert.
-
-## Standards & Compliance
-
-| Standard | Version | Verwendung |
-|---|---:|---|
-| ATC-STD-000 | 1.3.0 | Governance Root |
-| ATC-STD-README-001 | 1.0.0 | README-Struktur und Metadaten |
-| ATC-STD-MD-001 | 1.0.0 | Markdown-Konformität |
-| ATC-STD-201 | 1.0.1 | Repository Governance |
-| ATC-STD-202 | 1.2.0 | Repository/Entwicklungsanforderungen |
-| ATC-STD-203 | 1.0.1 | Security und Release Gates |
-
-Die Tabelle dokumentiert relevante Standards; sie ist keine pauschale Behauptung, dass dieses Entwicklungs-Repository bereits `PRODUCTION_READY` ist.
-
-## Roadmap
-
-Siehe:
-
-- `ROADMAP.md`
-- `STATUS.md`
-- zentrale Roadmap in `a-townchain-os-docs`
-- GitHub Issues & Projects
-
-## Contributing
-
-Beiträge erfolgen über den definierten ATC-Governance-Prozess. Vor einem Merge müssen die für die Änderung relevanten Tests und Validatoren erfolgreich ausgeführt werden.
+Das Repository folgt dem A-TownChain-Governance-Modell und den geltenden ATC-Standards. Änderungen an Factory-, Engine-, Chain- oder VM-Grenzen müssen nachvollziehbar dokumentiert und durch Tests/Evidence belegt werden.
 
 ## License
 
 Apache-2.0 — A-TownChain-Okosystems. Details siehe [`LICENSE`](LICENSE).
 
-## Maintainers
-
-**Organization:** A-TownChain-Okosystems  
-**Maintainers:** ShivaCoreDev, aurora-superagent
-
-## Repository Metadata
-
-Maschinenlesbar: siehe HTML-Metadaten-Block im Header gemäß ATC-STD-README-001 §14.  
-**Registry-ID:** `ATC-REPO-GAME-001`
-
 ## AI Agent Instructions
 
-Für KI-Agenten:
-
 1. Lies `STATUS.md`, `AGENT_MANIFEST.md`, `ARCHITECTURE.md` und `ROADMAP.md` vor größeren Änderungen.
 2. Beachte die geltenden ATC-Standards und Repository-Governance.
 3. Verwende Conventional Commits.
-4. Führe nach Änderungen mindestens `cargo fmt --all -- --check`, `cargo check --workspace --all-targets`, `cargo test --workspace --all-targets` und `cargo clippy --workspace --all-targets -- -D warnings` aus.
+4. Führe Engine- und Franchise-Factory-Tests aus.
 5. Trenne deklarierte Zustände, Testergebnisse und Governance-Evidence strikt voneinander.
 6. Verändere keine Chain-/VM-Grenzen, um Engine-Funktionalität zu implementieren.
diff --git a/franchise_factory/README.md b/franchise_factory/README.md
@@ -0,0 +1,49 @@
+# Genesis Franchise Factory
+
+The Franchise Factory is now an integrated production subsystem of `genesis-engine`.
+
+## Boundary
+
+```text
+Franchise Factory
+  ├─ 17 AI production workflows
+  ├─ Game Factory dependency graph
+  ├─ Artifact + provenance contracts
+  ├─ Franchise core pipeline
+  ├─ DAO model
+  └─ Lifecycle Manager
+          │
+          ▼
+Genesis Engine Runtime / Build / Editor / SDK
+          │
+          ▼
+Games and franchises
+```
+
+`genesis-chronicles` remains an independent consumer/flagship title and is not a dependency of this subsystem.
+
+## Components
+
+- `gff/core.py` — AD-20 franchise registry and pipeline orchestration
+- `gff/dao.py` — ATC-9900 franchise DAO model
+- `gff/lifecycle.py` — AD-43 lifecycle state machine
+- `gff/spec_loader.py` — canonical `.atc` descriptor loader
+- `gff/workflows.py` — 17 provider-neutral AI factory workflows
+- `gff/artifacts.py` — typed artifact/provenance/evidence contracts
+- `gff/game_factory.py` — deterministic Game Factory dependency graph
+
+## Game Factory
+
+The Game Factory models Concept, World, Lore, Character, Creature, Combat, Quest, Level, Item, Weapon, Animation, AI NPC, Audio, VFX, Economy, Multiplayer, Build, Testing and LiveOps as typed production stages.
+
+The graph fails closed on missing producers and dependency cycles and exposes a deterministic topological order.
+
+## AI boundary
+
+The workflow engine does not call an AI provider directly. Model providers, credentials and external side effects are supplied through injected executors. This preserves deterministic orchestration and keeps provider concerns outside the core.
+
+## Engine integration
+
+The subsystem is located under `franchise_factory/` rather than being made a Rust workspace member. This preserves the existing Python reference implementation while making the Franchise Factory part of the Genesis Engine repository and CI/documentation surface.
+
+Production adapters to engine runtime systems, GCL/ATC-VM and external providers remain explicit integration boundaries and must be backed by implementation evidence before being marked production-ready.