Project Overview / Roadmap

Radar-Kandidaten als Hypothesen und Arbeitsmaterial sichtbar machen.

Neue Kandidaten kontrolliert erfassen, mit Herkunft, Source Type und offener Beleglage.

Fit, Substanz, Productization, Faceless-Setup und Quellenbedarf strukturieren.

Zielgruppe, Problem, Nutzenhypothese, Format und Claim-Grenzen als Arbeitsstand ableiten.

Kleinste Prüfpfade, Signale, Gegen-Signale und Quellenbedarf planen, nichts ausführen.

Briefings für spätere Landingpage-, SEO/GEO-, Ad-, PDF-, Workshop- und Tool-Assets vorbereiten.

Kanal- und Publishing-Arbeitsstände planen, ohne Kampagne, Ads oder Veröffentlichung.

Lernsignal-Arbeitsstände strukturieren, ohne Monitoring, echte Daten oder automatische Entscheidung.

Quellenfamilien, Signalgrenzen, Adapter-Reihenfolge und Anti-AI-Slop-Regeln app-sichtbar entscheiden.

Manuelle Source Observations und Demo Source Packs mit Signaltyp, Ableitungsgrenzen, Missing Evidence und Candidate-Handoff-Brief sichtbar machen.

Geklärt: Source Packs sollen später persistent werden, aber Persistenz speichert Arbeitsstand, nicht Validierung.

Hybrid-Minimal-Struktur, manuell prüfbare DDL-Option, Redaction-Grenzen und Rollback-Hinweise vorbereitet, ohne DDL auszuführen.

Dominic hat die Source-Pack-DDL manuell in Neon ausgeführt, per SQL verifiziert und danach Staging-Smoke grün geprüft.

Drizzle-Schema, Row-/Domain-Typen, Runtime Guards, Mapper und read-only Service-Fundament vorbereitet; keine UI- oder CRUD-Persistenz.

Interne Read API, Detail API und Validate-Only-Payload-Prüfung vorbereitet; Write API und Manual UI folgten separat.

Entschieden: erste spaetere Writes sind nur Create Draft Source Pack und Add Source Observation; Delete, Handoff, Bulk und Adapter-Writes bleiben blockiert.

Interne Write API fuer create draft Source Pack und add source observation gebaut; Manual UI folgte separat, Delete, Bulk, Adapter-Write und Candidate-Handoff bleiben blockiert.

Gefuehrter Source-Pack-Workspace mit List, Validate Preview, Save Draft und Add Observation gebaut; ohne neue API, Delete, Handoff oder Candidate-Erzeugung.

Edit-/Archive-Decision umgesetzt: PATCH fuer Draft-Felder, Archive per Status und UI-Erweiterung ohne Delete, Handoff oder DB-Aenderung.

Evidence-Workspace geschaerft: Source-Pack-Liste, Detail-Read-Model, Boundary Panel, Archived State, Empty States und Feedback-Zustaende poliert.

Handoff Readiness, Preview und explizite manuelle Handoff Action gebaut; Offer-Radar-Candidate bleibt Hypothese ohne Bewertungs-, Reihenfolge-, Umsatz- oder Freigabe-Signal.

Source-Pack-Origin, Missing Evidence, Blocked Claims, Boundary Notes und Backlink im Offer Radar / Candidate-Intelligence-Kontext sichtbar weitergefuehrt.

Research-Follow-up mit Research Questions, Evidence Needed, Quellenfamilien, Blocked-Claim-Pruefpfaden und Follow-up-Boundaries aus Source-Pack-Handoff-Candidates sichtbar abgeleitet.

Follow-up-Vorschlaege werden kontrolliert per bestehender Research-Run-Intent-Struktur uebernommen; Intent bleibt geplanter Pruefpfad ohne Research-Ausfuehrung.

Research Execution als manuelle Pruefvorbereitung entschieden und Low-Ticket-Core-Offer, Order-Bump- und Upsell-Readiness sichtbar gemacht; kein Run, keine externe Recherche.

Core Low Ticket Offer, Order-Bump- und Upsell-Konzept aus Readiness, Evidence Gaps und Boundaries abgeleitet; bleibt Hypothese ohne Validierung oder Umsatzschaetzung.

Core-Offer-, Order-Bump- und Upsell-Testplan aus dem Ladder-Konzept abgeleitet; bleibt Hypothese ohne Launch, Umsatzschaetzung oder automatische Ausfuehrung.

Core-, Order-Bump- und Upsell-Asset-Briefs aus dem Testplan vorbereitet; bleibt Briefing-Arbeitsstand ohne fertige Assets, Publishing, Checkout oder Claim-Verstaerkung.

Dry-Test Briefs fuer Core Offer, Order Bump und Upsell aus Testplan und Asset Briefs vorbereitet; bleibt Seitenstruktur-Hypothese ohne Landingpage, Publishing, Checkout, Payment oder Umsatzschaetzung.

Qualitative Publishing Readiness fuer Core Offer, Order Bump und Upsell aus Dry-Test Brief, Asset Briefs und offenen Evidenzgrenzen abgeleitet; bleibt interne Vorbereitung ohne Publishing, Checkout oder Payment.

Produktoberflaeche auf Workspace, Offer Radar, Source Packs, Research Cases und Project Overview gewichtet; technische Foundation-Seiten bleiben erreichbar, aber sekundaer.

Dashboard und Offer Radar von erklaerender Doku-Flaeche zu kompakter Workbench mit aktiver Arbeit, Candidate Board, Quick Access und kompakten Boundaries geschaerft.

Dashboard und Offer Radar als echte App-Surface neu gewichtet: Command Center, Candidate Board, Quick Actions und System-Foundations als sekundaere Referenz statt dominanter Doku-Flaechen.

A-Z-Beta-Workflow, Hauptscreens, Clickflows, Datenbedarf, Hintergrundanalysen, Outputs, Review-Gates, Qualitaetshuerden und fehlende Beta-Module definiert; keine Implementierung.

A-Z-Screen-Architecture, App-vs-System-Trennung, Screen States, Clickflows, UX-Regeln und statisches Read-only Screen Model definiert; keine UI-, API- oder Fachlogik-Aenderung.

Aktuell verfuegbare und bisher genutzte Codex-Skills, MCPs, Connectoren, Agent-Faehigkeiten und Loop-Readiness geprueft; Ergebnis: kontrollierte Makrotasks sind moeglich, autonomer Loop braucht zuerst ein Operating Model.

Projektlokale Arbeitsregeln, Loop-State, Agentrollen, Tool-Routing, Stop-Regeln, Build-/Smoke-Gates, Workitems und Loop Charter definiert; keine aktive Automation, keine Skills/MCPs installiert.

Problem Tree, Folgeprobleme, Root Cause Hypothesis, Solution Blockers, Belief Shift, Salesline Hypothesis, Claim Boundaries und Offer Implications als read-only Foundation definiert; keine Copy, keine UI, keine API, keine Persistenz.

Marketing Knowledge als kontrollierten Playbook-Layer fuer Buying Psychology, Offer Framing, Landingpage, Checkout, Order Bump, Upsell, Paid Ads, Organic, Creative Angles, Proof Reality, Rights Boundaries und Channel-Specific Depth entschieden; keine Assets, keine Copy, keine Knowledge-Datenbank.

Format fuer konkrete spaetere Marketing-Playbook-Einheiten mit Typen, Status, Source-/Rights-Notes, Evidence Requirements, Review-Gates, Claim Boundaries, Workflow-Kompatibilitaet, Versionierung und Anwendungsgrenzen definiert; keine Dokumente importiert und keine Assets erzeugt.

Entscheiden, wie echte Marketingdokumente, Kursnotizen, Frameworks oder Expertenmaterialien spaeter sicher aufgenommen, rechtegeprueft, transformiert und intern in Playbook-Strukturen ueberfuehrt werden duerfen; noch kein Import, Parsing oder echtes Playbook.

Ein erstes manuelles Template fuer spaetere Source Intake Records definieren, damit Dominic Herkunft, Rechte, Allowed/Blocked Use, Transformation Notes, Proof Reality und Decision Gates sicher erfassen kann; keine echten Quellen, kein Import, keine DB und keine UI.

Einen sicheren Drafting-Rahmen definieren, der spaeter gepruefte manuelle Source-Intake-Notizen in Playbook Drafts ueberfuehren kann, ohne Copy, Proof, externe Nutzung oder active_internal-Freigabe zu behaupten.

Review-&-Activation-Preconditions, Gates, Outcomes, active_internal Boundaries und Deactivation/Deprecation-Regeln definiert; keine echten Playbooks, keine UI, keine API, keine DB und keine externe Nutzung.

Rein synthetisches Flow-Beispiel fuer Source Intake, Rights Review, Transformation Notes, Playbook Draft und Review Gates definiert; kein echtes Material, kein echter Claim und kein active_internal Playbook.

End-to-End-Policy fuer Manual Source Intake, Rights Review, Transformation Notes, Playbook Draft, Review, active_internal und Deactivation/Deprecation dokumentiert; blockiert Rights-, Proof-, Copy/IP-, Generic-Marketing- und External-Use-Risiken.

Architektur fuer Opportunity-Hypothesen, Source Observations, Background Research, Research Queue, Staleness, Evidence Gaps, Opportunity Cards und Human Review Gates definiert; keine echten Daten, Adapter, Scheduler, Rankings, Scores oder Fake-Evidence.

Manuelle Seed-Struktur fuer Opportunity-Hypothesen definiert: Seed Identity, Target/Problem, Source/Signal Planning, Channel/Brand, Offer/Product Direction, Boundaries, Next Step, Blocker und synthetisches Beispiel; keine echten Opportunities, keine externe Recherche, keine UI, keine API, keine DB, keine Automation und keine Scores.

Manual Seed, Source Pack Draft Vorbereitung, Research Case Draft Vorbereitung, Candidate Challenge Preparation, Problem & Salesline Preparation und naechsten A-Z Step als zusammenhaengenden read-only Backbone definiert; keine echten Handoffs, keine echten Candidates, keine UI, keine API, keine DB und keine Automation.

Opportunity Workspace als spaeteren manuellen Arbeitsraum mit Stages, States, Actions, Panels, Clickflows, Preview-only/Disabled Actions, Runtime Boundaries und UI-Anforderungen definiert; keine UI, keine API, keine DB, keine echte Runtime und keine Daten.

Statische interne Route /internal/opportunity-workspace mit synthetischem Scenario, Boundary Strip, Seed Summary, Evidence Gaps, Blocked Claims, CTA-State-Matrix und Smoke-Markern gebaut; keine DB, API, Persistenz, echten Daten oder Writes.

V2 Light Premium als neue App-Richtung umgesetzt, Screen-Komposition getrennt und sichtbare UI auf Human-First-Sprache korrigiert: Dashboard nur Feed/Radar/Ideen-Modal, Pruefung nur Detail/Wizard/Decision Rail; keine API, DB, Persistenz, echten Daten oder Writes.

Den neuen V2-Prototyp visuell pruefen: Desktop/Mobile-Screenshots fuer getrennten Human-First-Feed und Pruefungs-Screen, Ideen-Modal, Wizard, Decision Rail, Phase Previews, Chip-System und gesperrte Aktionen vor echter Ausfuehrung, Speicherung oder echten Opportunity-Daten.

Produktstruktur, Module, Templates, SOPs, Deliverables, Nicht-Lieferumfang, Delivery-Risiko und QA aus Offer Concept und Salesline ableiten; kein verkaufbares Versprechen ohne lieferbaren Scope.

Meta, TikTok, YouTube, Google, LinkedIn/X, Organic Social und SEO/GEO als eigene Research-, Challenge-, Brand-Fit-, Claim-, Production- und Measurement-Prozesse definiert; keine kanalunabhaengigen Marketingempfehlungen, keine echten Daten und keine Assets.

Erst nach Screen-Architecture-Foundation umsetzen: produktive App-Flaechen scharf priorisieren und System-/Foundation-Seiten aus der direkten Nutzerstrecke herausnehmen.

Bleibt relevant, wird aber erst nach dem Beta-Masterplan wieder eingeordnet: entscheiden, ob und wie aus Readiness und Briefs erste interne Asset-Drafts entstehen duerfen, ohne fertige Assets, externe Nutzung, Checkout oder Payment zu bauen.

Manuelle Execution-Checklisten erst nach Low-Ticket-Ladder-Konzept schaerfen; keine automatische Recherche.

Ersten externen Adapter erst nach Research-Run-Execution-Entscheidung vorbereiten.

Keyword- und Search-Signale erst mit echten Quellen und klarer Quellenpflicht.

Community-Signale nur mit sauberer Herkunft, Zitiergrenzen und Review-Logik.

SERP-, Wettbewerbs- und Preisanker-Daten erst nach Quellenentscheidung.

Nur mit echten Inputs wie Suchvolumen, CPC, Preisankern und belegten Annahmen.

Assets erst nach Claim-Prüfung, Quellenlage und menschlicher Freigabe erzeugen.

Echte Veröffentlichungen erst nach Quellen-, Claim-, Tracking- und Freigabeentscheidung.

Echte Datenrückführung erst nach echten Tests und Einwilligungs-/Trackingklärung.

Keine automatische Entscheidung; echte Signale brauchen Review und Datenmodell-Entscheidung.

Manuelle Research Cases anlegen und verwalten.

Snapshot-Inhalte manuell bearbeiten und prüfen.

Manuelle Dry-Test-Arbeitsstände mit Wahrheitsebene.

Interne Gesprächsleitfäden ohne Outreach- oder Sales-Ausführung.

Notizen erfassen und als Review-Basis sichtbar machen.

Vorbereitete Ergänzungen prüfen und manuell übernehmen.

Parked, damit der Main Path nicht in Research-Governance abdriftet.

Repository, Deployment-Flow und Staging-Ziel stehen.

DB-Erreichbarkeit wird über bestehende Systemchecks geprüft.

Staging-Smoke prüft zentrale Main-Path- und Manual-Flows.

Produktnähere UI, Vision Dashboard und Main-Path-Orientierung.