Agentic Ventures Wiki

Tag 2 — Snapshot-Pipeline Prompt (Sonnet-Session)

4 Min. Lesezeit

Tag 2 — Snapshot-Pipeline Prompt

Diesen Block direkt in eine frische Sonnet-Session reinpasten. Vorher den CSV-Pfad eintragen.

=== VF Liquiditaets-Cockpit Phase 1 — Tag 2 Snapshot-Pipeline ===

## Rolle
Du bist Senior Full-Stack-Engineer mit AWS + TypeScript + Postgres + Lambda. Plus Domain-Wissen Cron-Routinen.

## Kontext — lies in dieser Reihenfolge
1. /Users/marvinkuehlmann/source/agentic-ventures/intern/projekte/vf-liquiditaets-cockpit/_index.md
2. /Users/marvinkuehlmann/source/agentic-ventures/intern/projekte/vf-liquiditaets-cockpit/plan.md (Tag 2)
3. Die Schema-CSV: [PFAD HIER EINSETZEN — Marvin schiebt die CSV per Drag-and-Drop in die Session ODER nennt den Pfad]
4. Falls vorhanden: ~/source/apps/av-cockpit/src/lib/finance-schema.ts (von Tag 1)
5. /Users/marvinkuehlmann/source/agentic-ventures/intern/capabilities/skills/routine-anlegen/SKILL.md
6. /Users/marvinkuehlmann/source/agentic-ventures/intern/capabilities/agents-platform.md

## Was Tag 1 ergeben hat
- CSV mit den Schemas aus Papierkram + TicketPay liegt vor (siehe Pfad oben)
- Tag-1-Status: siehe Update in _index.md / plan.md durch die Sonnet-Session von Tag 1

## Architektur-Decision vorab — bitte BESTAETIGEN bevor du baust

Im plan.md Tag-2 stand „finance_snapshots-Tabelle in av-production RDS". Das ist nicht zwingend die beste Variante. Vergleiche kurz mit Marvin und entscheide gemeinsam:

**Option A — S3-JSON-Snapshot (empfohlen fuer Phase 1):**
- Lambda schreibt aggregierten Snapshot als JSON-File nach `s3://av-vf-cockpit-snapshots/latest.json` + Historie unter `s3://.../snapshots/<timestamp>.json`
- av-cockpit liest das JSON build-time oder direkt aus S3
- Kein DB-Footprint, kein RDS-Kostenfaktor, einfacher AVV
- Trade-off: Aggregation passiert in Lambda statt in SQL — fuer einen einzelnen Tenant trivial

**Option B — RDS-Tabelle in av-production:**
- Wie urspruenglich im plan.md
- Nutzt vorhandenes RDS-Cluster (OWUI-Postgres)
- Cross-Tenant-Vermischung in einem DB (VF-Daten + OWUI-Daten) ist AVV-grenzwertig

**Option C — DynamoDB im av-production-Account:**
- Serverless, single-digit-Millisekunden-Reads
- Etwas komplexer aber DSGVO-sauberer als RDS-Vermischung
- Trade-off: JSON-Quoting noetig fuer geschachtelte Felder

Frag Marvin kurz: „A, B oder C — Default: A?" Wenn er „A" oder nicht aktiv widerspricht, nimm A.

## Deine Aufgabe — Tag 2 vom plan.md

### Schritt 1 — Schema aus CSV nach TypeScript
- CSV einlesen (Pfad siehe oben)
- TypeScript-Interfaces in `~/source/apps/av-cockpit/src/lib/finance-schema.ts` aktualisieren / anlegen
- Wenn die Tag-1-Datei existiert: Diff machen, nur fehlende Felder ergaenzen
- Jedes Interface hat Kommentar: Quell-Endpoint + Cron-Frequenz

### Schritt 2 — Snapshot-Aggregations-Logik
- File: `~/source/apps/av-cockpit/src/lib/build-snapshot.ts`
- Pure TypeScript-Funktion `buildSnapshot(papierkramClient, ticketpayClient): Promise<FinanceSnapshot>`
- Macht die MCP-Calls aus Tag-1-Discovery (Monatsabschluss letzte 3 Monate, offene Posten, Bank-Transactions, Events + Bilanz)
- Aggregiert zu einem FinanceSnapshot-Objekt mit allen drei Cockpit-Bloecken
- Liest Forecast-Annahmen aus `~/source/apps/av-cockpit/src/data/vf-forecast-assumptions.json`
- Initial einfache Forecast-Logik: Burn-Rate-Trend + bekannte Faelligkeiten + Event-Erwartungen
- Testbar via direkter Aufruf, ohne Lambda-Wrapper

### Schritt 3 — Cron-Routine im agents-platform
- Nutze den `routine-anlegen`-Skill: `/routine-anlegen`
- Brief in 6 Fragen: Name `vf-finance-snapshot`, Schedule `0 */4 * * *` (alle 4h), Tenant `vf`, Action: ruft buildSnapshot() auf und persistiert via gewaehlte Architektur (Option A/B/C)
- Skill generiert CDK-Stack, Code, Vault-Doku
- Deploy nach av-production
- Smoke-Test: erster echter Run, Log-Check ob alle MCP-Calls erfolgreich sind

### Schritt 4 — Output verifizieren
- Pruefe ob der Snapshot tatsaechlich in S3/RDS/DynamoDB ankommt
- KEINEN echten Inhalt im Chat zeigen — nur Schema + Counts + Erfolgs-Bestaetigung
- Beispiel-Check fuer Marvin: „Snapshot enthaelt X Bank-Accounts, Y offene Posten, Z upcoming Events. Bank-Saldo summiert: gerundet auf 100 EUR = ZZZ EUR. Faellt das ungefaehr in dein Bauchgefuehl?"

### Schritt 5 — plan.md updaten
- Tag-2-Checkboxen abhaken
- Falls Architektur-Decision A/B/C: dokumentieren welche gewaehlt wurde und warum
- Falls Quirks aufgetaucht (z.B. MCP-Timeout, Daten-Lueck): festhalten

## Output am Ende
- finance-schema.ts (aktualisiert, in av-cockpit-Repo)
- build-snapshot.ts (neu, in av-cockpit-Repo)
- CDK-Stack der neuen Routine `vf-finance-snapshot` in agents-platform
- Cron-Routine deployed und laeuft
- Erster Snapshot in S3 (oder gewaehlter Speicher)
- _index.md + plan.md updates

## Datenschutz-Constraints
- Keine vollstaendigen Bank-Transaktionen oder Kunden-Namen im Chat. Nur Aggregate.
- finance-snapshots in einem fuer VF dedizierten Storage (S3-Bucket-Name enthaelt `vf`).
- IAM: Lambda-Role hat nur die noetigen MCP-Permissions, nicht alle av-production-Berechtigungen.
- Verschluesselung im Speicher: KMS-Standard, kein Plain-Text.

## Skill
- `/routine-anlegen` fuer den Cron-Job
- `/work` als uebergeordneter Build-Modus
- Bei Architektur-Entscheidung Postgres-Schema oder Forecast-Algorithmus: `/plan` als Sub-Skill, kurz

## Nicht in Scope fuer Tag 2
- Cockpit-UI bauen (Tag 3)
- Forecast-Annahmen-UI (Tag 4-5)
- Multi-Tenant-Logik

=== Ende ===

Vor dem Aufruf

  1. CSV-Pfad einsetzen (aus Tag-1-Output) — meist im av-cockpit-Repo oder im Download-Folder
  2. Frische Sonnet-Session starten (Claude Code oder opencode mit business/coding-Agent)
  3. Block kopieren, einfuegen

Erwartetes Ergebnis am Ende des Tags

  • Lambda-Cron vf-finance-snapshot deployed, laeuft alle 4h
  • Erster Snapshot im gewaehlten Storage abgelegt (Empfehlung: S3-JSON)
  • TypeScript-Funktion buildSnapshot() aufrufbar fuer Tag-3-Cockpit-Render

Graphansicht

Backlinks