Tworzenie botów dla Discord

Specyfikacja techniczna (opisany pełny funkcjonalność) Projekt AI Sales Agent do automatycznego wyszukiwania potencjalnych klientów, spersonalizowanej wysyłki email i przetwarzania leadów. Pierwotny biznes, pod który zbierany jest AI Agent, przeznaczony jest dla projektu „platforma dla budowniczych i sprzętu budowlanego w Niemczech i UE. Strona: https://prostobau.de/ Celem jest stworzenie w pełni autonomicznego systemu, który będzie mógł działać praktycznie bez mojego udziału i w razie potrzeby łatwo przełączać się na dowolną inną niszę biznesową. Ogólna architektura System powinien być modułowy. Każdy moduł powinien działać niezależnie. Na przykład: wyszukiwanie firm; analiza strony; wyszukiwanie email; generowanie wiadomości; wysyłka; przetwarzanie odpowiedzi; raporty. Jeśli zajdzie potrzeba zastąpienia Apify lub OpenAI inną usługą, powinno to odbywać się bez przepisywania całego systemu. Źródła wyszukiwania firm Na pierwszym etapie używać: Google Maps przez Apify. W przyszłości powinna być możliwość łatwego podłączenia: LinkedIn; Facebook; Gelbe Seiten; Yelp; jakiekolwiek inne źródła. Wyszukiwanie firm Każdego dnia system automatycznie pozyskuje około 100 nowych firm na podstawie zadanego zapytania wyszukiwania. Na przykład: Wynajem maszyn budowlanych Bawaria Firmy budowlane Norymberga Sucha zabudowa Monachium Wyszukiwanie powinno być w pełni konfigurowalne. Muszę mieć możliwość zmiany: niszy; kraju; regionu; języka; zapytania wyszukiwania; liczby firm. Bez pomocy programisty. Sprawdzanie duplikatów Przed przetwarzaniem firma jest sprawdzana pod kątem: domeny; email; telefonu; URL Google Maps; nazwa. Jedna firma nigdy nie powinna otrzymać pierwszej wiadomości dwa razy. Analiza strony Jeśli strona zostanie znaleziona, agent powinien: zbadać czym zajmuje się firma; jakie usługi świadczy; jakie towary sprzedaje; region działalności; dane kontaktowe; możliwe imię właściciela; email. Po analizie stworzyć krótkie opisanie firmy. Wyszukiwanie email Priorytet: osobiste adresy robocze → sprzedaż → dystrybucja → kontakt → info. Jeśli email nie istnieje — firmę pominąć. Generowanie wiadomości Przez OpenAI. Każda wiadomość powinna być indywidualna. Nie używać szablonowej zamiany pary słów. Wiadomość powinna uwzględniać zawartość strony. Styl: krótko przyjaźnie profesjonalnie bez presji bez wymyślonych faktów maksymalnie 120 słów. Sprawdzanie wiadomości Przed wysyłką wiadomość powinna być automatycznie sprawdzana. Jeśli wykryto: błędy; wymyślone informacje; zbyt długi tekst; słaba personalizacja, wiadomość powinna być stworzona na nowo. Wysyłka wiadomości Nie używać korporacyjnego emaila projektu. Stworzyć oddzielną nową domenę dla outbound email. Na przykład oddzielną podobną domenę. Stworzyć nowe skrzynki pocztowe. Skonfigurować: SPF DKIM DMARC Obowiązkowo zorganizować prawidłowe rozgrzewanie poczty. Po rozgrzewaniu przejść na około 100 nowych wiadomości dziennie. Wiadomości powinny być wysyłane stopniowo w ciągu dnia roboczego. Nie wszystkie jednocześnie. Follow-up Po 5 dniach od pierwszej wiadomości. Tylko jeśli: brak odpowiedzi; brak bounce; firma nie poprosiła o więcej niepisanie. Follow-up tylko jeden. Po drugiej wiadomości łańcuch się kończy. Przetwarzanie odpowiedzi System powinien automatycznie: czytać przychodzące wiadomości. Określać: zainteresowany; niezainteresowany; prośba o więcej niepisanie; automatyczna odpowiedź; wakacje; potrzebny ręczny odpowiedź. Po odpowiedzi automatycznie przerywać wszelkie dalsze wiadomości. Baza danych Przechowywać: firmy; strony; email; historię wiadomości; odpowiedzi; statusy; zapytania wyszukiwania; błędy; datę przetwarzania; follow-up. Dashboard Potrzebny wygodny interfejs webowy (desktop), a nie tylko n8n. Chcę widzieć: Strona główna czy agent działa; aktualny status; ile firm znaleziono; ile przetworzono; ile wysłano; ile odpowiedzi; ile błędów; ile follow-up; ile zainteresowanych. Firmy Tabela. Filtry. Wyszukiwanie. Historia. Zapytania wyszukiwania Dodaj Usuń Zmień Priorytet Region Kraj Liczba firm. Ustawienia Bez programisty powinny być zmieniane: model OpenAI; konto email; domena; liczba wiadomości; limity; język; szablon; czas wysyłki; liczba firm; termin follow-up; nisza biznesu. Logi Wszystkie błędy. Wszystkie działania. Historia pracy. Awaryjne zatrzymanie Duży przycisk STOP Po naciśnięciu: natychmiast przerywane są wyszukiwanie; generowanie; wysyłka; follow-up. Restart Jednym przyciskiem. Tryby pracy Testowy Wszystko wykonuje się oprócz wysyłki. Można sprawdzić wiadomości. Automatyczny Całkowicie autonomiczna praca. Skalowanie W przyszłości powinna być możliwość: dodania kilku kont email; kilku domen; kilku projektów; kilku nisz; kilku krajów; kilku języków. Bez całkowitej przeróbki systemu. Codzienny raport (zorganizować w wygodny sposób, albo przez email do właściciela, albo w telegramie przez bota) Na koniec dnia automatycznie otrzymywać: znaleziono firm; nowych; duplikatów; znaleziono email; wysłano wiadomości; follow-up; odpowiedzi; zainteresowanych; błędów. Bezpieczeństwo Wszystkie klucze API przechowywać bezpiecznie. Żadne klucze wewnątrz workflow. Dokumentacja Po zakończeniu projektu dostarczyć: instrukcję uruchomienia; instrukcję zmiany ustawień; opis architektury; eksport wszystkich workflow; dostęp do wszystkich usług. Ważne Projekt powinien być budowany nie tylko pod ProstoBau. Chcę otrzymać uniwersalną platformę do wyszukiwania klientów, którą w przyszłości można wykorzystać praktycznie dla każdego biznesu, po prostu zmieniając: niszę; zapytania wyszukiwania; szablony wiadomości; email; domena; kraj. Bez angażowania programisty.

Wymagana jest разработка lokalnego skryptu Python do automatycznego wypełniania Google Arkuszy danymi z wewnętrznego serwisu firmy. Główna logika: 1. Połączyć się z Google Arkuszem. 2. Znaleźć wiersze, w których wypełniony jest ID, ale brakuje dwóch docelowych wartości. 3. Sformułować link według szablonu: https://internal-service.example/item/{ID} 4. Uzyskać dwie wartości (przez API, jeśli istnieje, w przeciwnym razie przez Playwright). 5. Zapisz wartości z powrotem do Google Arkusza. 6. Oznaczyć wiersz jako przetworzony. 7. Kontynuować przetwarzanie kolejnych wierszy. Wymagania: • Python • Google Sheets API • Priorytetowe użycie oficjalnego API • W przypadku braku API — Playwright • Bez OCR, rozpoznawania ekranu i współrzędnych myszy • Poufne dane nie powinny trafiać do logów • Konfiguracja przez .env • Tryb testowy (bez zapisu do arkusza) • Nie przetwarzać już wypełnionych wierszy • Zbiorowe zapisywanie zmian w Google Sheets • Poprawne przetwarzanie błędów i ponownych prób Wymagane do dostarczenia: - kod źródłowy; - requirements.txt; - przykład .env.example; - instrukcja instalacji; - instrukcja uruchamiania; - krótki opis architektury. Przed rozpoczęciem realizacji proszę: 1. Zaproponować architekturę. 2. Wymienić niezbędne dostępności. 3. Zadać pytania wyjaśniające. 4. Podać koszt, terminy i orientacyjną liczbę godzin.

W ramach podnoszenia poziomu cyberbezpieczeństwa naszej infrastruktury musimy zrezygnować z praktyki przechowywania „wiecznych” i statycznych kluczy API, haseł oraz tokenów integracji w plikach konfiguracyjnych (.env, appsettings.json, config.yaml) naszych mikroserwisów. Cel biznesowy: Stworzyć jednolity, zabezpieczony punkt przechowywania danych poufnych (sekretów) z mechanizmem ich automatycznego aktualizowania (rotacji) w systemach zewnętrznych według harmonogramu. Inne nasze usługi będą żądać aktualnych tokenów „na żywo” przez API, co zminimalizuje szkody w przypadku kompromitacji któregokolwiek z komponentów systemu.Model bezpieczeństwa i szyfrowanie (Crypto Core) W bazie danych żaden sekret nie powinien być przechowywany w postaci jawnej. Podczas uruchamiania aplikacji do zmiennych środowiskowych przekazywany jest Klucz główny (Master Key). Jeśli klucz jest nieobecny lub ma nieprawidłową długość, usługa powinna zakończyć działanie na etapie inicjalizacji z zrozumiałym błędem w logach. Każdy sekret jest szyfrowany przed zapisaniem w bazie danych z użyciem tego Klucza głównego. Przy żądaniu — jest deszyfrowany w pamięci i zwracany w treści odpowiedzi.Audyt-logowanie (Audit Trail) Każda akcja z sekretami (tworzenie, odczyt przez usługę, udana lub nieudana rotacja) powinna być zapisywana w oddzielnym pliku logów audit.log (lub w oddzielnej tabeli w bazie danych). Ścisły zakaz: W audyt-logu kategorycznie zabrania się zapisywania samych wartości sekretów (ani w postaci jawnej, ani w postaci zaszyfrowanej).

Potrzebny specjalista do pisania parserów, który będzie w stanie obejść CLOUDFRAME. Parsowanie produktów odbywa się z witryn z autoryzacją. Jest 10+ donorów o różnym stopniu trudności, z różnym poziomem ochrony. Parsowanie produktów odbywa się z witryn z autoryzacją. Parsuje dane do gotowej bazy danych Mysql + zdjęcia na serwer. Należy napisać parser zgodnie z zadaniami opisanymi w specyfikacji technicznej i dostosować dane do istniejącej bazy danych, aby zapewnić pełną funkcjonalność na stronie. Specyfikacja techniczna oraz przykład donora na żądanie. Nie rozważamy parserów desktopowych ani C#.

Bot do lustrzenia pozycji na Binance Futures (Python) Potrzebny bot, który odczytuje moje pozycje na Hyperliquid (publiczne API) oraz Bitget Futures (mój klucz tylko do odczytu) i proporcjonalnie powtarza je na moim Binance USDT-M Futures przez API. Logika: otwieranie, zwiększanie, częściowe zamykanie, pełne zamykanie — wszystko lustrzane z konfigurowalnym współczynnikiem rozmiaru. Polling co 5–10 sek. Obowiązkowa poprawna obsługa częściowych zamknięć i uśrednień. Wymagania: powiadomienia w Telegramie o transakcjach i błędach; konfiguracja (pary, współczynnik, limity); wdrożenie na moim VPS + instrukcja; kod źródłowy przekazywany mi. Klucze wprowadzam sam. Etapy: 1) Hyperliquid→Binance, test na małych kwotach; 2) Bitget→Binance. Płatność przez safe etapowo. W odpowiedzi podaj doświadczenie z API giełd i jak obsłużysz częściowe zamknięcie 30% pozycji liderem