No description
Kevin Adametz
a0ac32cf95
Die Klassifizierung aus dem Trockenlauf wird jetzt nach company_email_groups geschrieben — eine Zeile je Adresse, denn ob zusammengeführt werden darf, ist eine Eigenschaft der Adresse und nicht der Firma. Die Zusammenführung (1a.3) und die laufende Zuordnung neuer API-Meldungen (1a.4) lesen dort, statt den Trockenlauf jedes Mal neu zu rechnen. Die Logik liegt jetzt in CompanyAddressClassifier und wird von Bericht und Persistierung gleichermaßen benutzt. Beide müssen dieselbe Antwort geben — sonst zeigt der Bericht etwas anderes, als die Zusammenführung später tut. manual_classification übersteuert die berechnete Klasse und überlebt jede Neuberechnung. Nötig für Grenzfälle, die nur ein Mensch entscheiden kann: presse@pr4you.de ist eine echte Agentur, sieht in den Daten aber aus wie eine Wegwerfadresse. effectiveClassification() ist die einzige Stelle, die Abnehmer fragen dürfen. Eigene Tabelle statt Spalten auf companies: Die Tabelle trägt einen FULLTEXT-Index, jedes ADD COLUMN dort ist ein Rebuild. Die Zuordnung Firma → Gruppe ist ohnehin nur die normalisierte Adresse, und die eine Stelle, die festlegt, was "dieselbe Adresse" heißt, ist jetzt Company::emailKey(). E1 ist entschieden: Schwellwert 3, nach drei Live-Läufen. Bei 2 wird jede zweite Schreibweise zur "Agentur", bei 4 wandern echte Mehrkunden-Adressen in die Handarbeit. Konfiguriert in config/newsroom.php; Bericht und Klassifizierung lesen den Wert von dort. Die Ähnlichkeitsprüfung ist quadratisch und jetzt bei 25 Repräsentanten gedeckelt — ab da steht die Klasse fest, und yahoo@yahoo.com mit über 4000 Namen hätte sonst neun Millionen Levenshtein-Aufrufe gekostet. Laufzeit über den ganzen Bestand: 25 s → 3 s, Ergebnis unverändert. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| .agents/skills | ||
| .codex | ||
| .devcontainer | ||
| .github/workflows | ||
| _docs | ||
| app | ||
| bootstrap | ||
| config | ||
| database | ||
| dev | ||
| docs | ||
| lang | ||
| public | ||
| resources | ||
| routes | ||
| storage/debugbar | ||
| tests | ||
| .cursorrules | ||
| .editorconfig | ||
| .env.example | ||
| .gitattributes | ||
| .gitignore | ||
| .mcp.json | ||
| AGENTS.md | ||
| artisan | ||
| boost.json | ||
| CLAUDE.md | ||
| composer.json | ||
| composer.lock | ||
| docker-compose.yml | ||
| package-lock.json | ||
| package.json | ||
| phpstan-baseline.neon | ||
| phpstan.neon | ||
| phpunit.xml | ||
| pint.json | ||
| Readme.md | ||
| setup-new-asset-urls.sh | ||
| tailwind.portal.config.js | ||
| tailwind.web.config.js | ||
| vite | ||
| vite.config.js | ||
| vite.portal.config.js | ||
| vite.shared.js | ||
| vite.web.config.js | ||
Multi-Domain Laravel-Anwendung
Übersicht
Diese Laravel-Anwendung unterstützt verschiedene Domains mit unterschiedlichen Styles:
- Haupt-Website: https://pressekonto.test (lokal) / https://pressekonto.de (live) – Haupt-Portal Admin-Page
- APP_PRESSEECHO: https://presseecho.test
- APP_BUSINESSPORTAL: https://businessportal24.test
Installation
- Repository klonen
- Abhängigkeiten installieren:
composer install npm install - Umgebungsvariablen konfigurieren (siehe
.env.exampleundDOMAINS-CONFIG.md) - Laravel-Anwendung initialisieren:
php artisan key:generate php artisan migrate - Assets kompilieren:
npm run build npm run build:admin npm run build:web
Domain-Konfiguration
Die Domains werden über die .env-Datei konfiguriert. Für detaillierte Anweisungen siehe DOMAINS-CONFIG.md.
Lokaler Entwicklungsserver
php artisan serve
Asset-Kompilierung
Diese Anwendung verwendet Vite mit verschiedenen Konfigurationen:
- Hauptkompilierung:
npm run devodernpm run build - Admin-Assets:
npm run build:admin - Web-Assets:
npm run build:web
Domain-Simulation
Während der Entwicklung können Domains simuliert werden, ohne die Hosts-Datei zu bearbeiten:
- In der
.env-Datei:DEV_SIMULATE_DOMAIN=true - Gewünschte Domain angeben:
DEV_SIMULATED_DOMAIN=landing1.local
Favicons
Um Platzhalter-Favicons für alle konfigurierten Domains zu generieren:
php artisan domains:generate-favicons