Metawork.Studio — MetaBot

Metawork.Studio · MetaBot

MetaBot ist das Webprodukt auf metawork.studio/bot — ein Pipedrive Setup- und Konfigurationsassistent. Es führt das Onboarding-Interview durch, führt Besucher durch Setup- und Designentscheidungen und treibt die Methodik voran, die Pipedrive für Kunden tatsächlich nutzbar macht (Pipelines, benutzerdefinierte Felder, Automatisierungen, Lead-Capture, Post-Sales-Übergabe).

MetaBot ist das Webprodukt unter metawork.studio/bot — ein Pipedrive Einrichtungs- und Konfigurationsassistent. Er führt das Onboarding-Interview durch, begleitet Besucher durch Einrichtungs- und Designentscheidungen und treibt die Methodik voran, die Pipedrive für Kunden tatsächlich nutzbar macht (Pipelines, benutzerdefinierte Felder, Automatisierungen, Lead-Erfassung, Post-Sales-Übergabe).

Es ist die konzeptionelle Ebene: Workflows, Entscheidungspfade, der Safety Envelope, die Pipedrive-vs-HubSpot-Rubrik, die Make Boundary, der Affiliate Flow und die Handoff-CTAs an Nikolai und das Team.

Für Pipedrive API-Operationen ruft MetaBot **MetaPipe** auf — ein separates MCP, das sichere Pipedrive-Tools bereitstellt (Lesen + sichere Schreibvorgänge, kein DELETE). MetaPipe wird unabhängig entwickelt und gewartet (siehe Projects/Metawork.Studio/MetaPipe).

┌──────────────────────────────────────────────┐
│ MetaBot (web product)                        │
│ • metawork.studio/bot                        │
│ • Onboarding interview (7 questions)         │
│ • Setup + design workflows                   │
│ • Pipedrive vs HubSpot decision rubric       │
│ • Safety envelope (4-bucket model)           │
│ • Make/Zapier boundary rules                 │
│ • Affiliate links + MWS handoff CTAs         │
└─────────────────┬────────────────────────────┘
                  │ uses tools from
                  ▼
┌──────────────────────────────────────────────┐
│ MetaPipe (MCP)                               │
│ • Pipedrive read tools (deals/persons/orgs/…)│
│ • Pipedrive safe writes                      │
│ • help_delete_* (returns instructions, never │
│   calls DELETE)                              │
│ • Internal-test first, customer-facing later │
└──────────────────────────────────────────────┘

Wo sich die Dinge befinden

Bereich	Repo / Pfad
MetaBot Spezifikationen (kanonisch)	`gitlab.com/metawork/metabot` → `docs/`
MetaBot Website (Next.js, geplant)	`gitlab.com/metawork/metabot` → `web/` (nicht gestartet)
Entwurf für verkaufte Skill (pausiert, siehe Handoff unten)	`gitlab.com/metawork/metabot` → `skill/`
MetaPipe MCP	separates Repo (parallel entwickelt)
Lizenzserver (geparkt)	`gitlab.com/metawork/mws-license-server`

Aktueller Stand (2026-05-08)

M1 Spezifikationen: ✅ alle festgelegt — Safety Envelope, Stuck-Moment Taxonomie, Make Boundary, Anti-Extraktionsrichtlinie, Onboarding-Interview
M2 verkaufte Skill: 🅿️ zurückgestellt. Der Skill-Entwurf (skill/SKILL.md) ist im Repo; die Lizenzierungsebene ist pausiert — siehe _handoffs/2026-05-08-metabot-licensing-paused.md für den vollständigen Status und die Schritte zur Wiederaufnahme
M3 Web-Bot: ⏳ nicht gestartet. Dies ist die aktive Priorität, sobald MetaPipe testbar ist
M4 Stuck Detection + Lead Capture: ⏳ hängt von M3 ab
M5 Make Handoff: ⏳ hängt von M3 ab
M6 Launch: ⏳ hängt von M3-M5 ab

Lesereihenfolge

gitlab.com/metawork/metabot → docs/handoff.md — vollständiger Projektstatus
docs/two-variants.md — muss angesichts des MetaBot/MetaPipe-Schwenks überarbeitet werden, ist aber immer noch der richtige Einstiegspunkt für den architektonischen Rahmen
docs/billing-and-licensing.md — Preisgestaltung + Lizenzentscheidungen (pausiert, später fortsetzen)
docs/safety-envelope-matrix.md — das 4-Bucket-Betriebsmodell (Allow / Confirm / Blueprint-only / Block)
docs/onboarding-interview.md — die 7-Fragen-Aufnahme
docs/stuck-moment-taxonomy.md — wann an Nikolai übergeben werden soll
docs/make-boundary-rules.md — Cross-System Automatisierungs-Handoff

Unverhandelbares (gilt für jede Session zu MetaBot oder MetaPipe)

v2 Pipedrive API bevorzugt, v1 nur, wenn v2 nicht abdeckt
Schließe immer gewonnene + verlorene Deals in Deal-Abfragen ein — niemals nur status=open
Zähle vor/nach jeder Bulk-Operation — unverhandelbar, hat echten Datenverlust verhindert
Lösche niemals eine Phase, ohne Deals vorher zu verschieben (dies ist eine Block-Bucket-Operation für den Bot)
Label-Updates erfordern Fetch-First-Merge — rohes PATCH auf label_ids ist die Überschreibfalle
Immer "Metawork Studio" vollständig (niemals nur "Metawork")
"Nikolai und das Team" für die Handoff-Sprache
Pipedrive Premier Partner, HubSpot Solutions Partner, Make Partner — Referenzen, die es wert sind, genannt zu werden, wenn relevant