Przejdź do treści
megapromotingPorozmawiajmy
Produkty Taskin

Organizarea muncii Dezvoltare & demonstrații

Co ustaliliśmy. Kto kontynuuje. Co dalej.

Taskin bada przekształcanie dyskusji i kontekstu projektu w zobowiązania, priorytety i kroki pracy. Celem jest zachowanie powiązania między zadaniem a rozmową, z której powstało.

  1. 1Discuție și context
  2. 2Sarcini propuse
  3. 3Angajamente confirmate
Schemă explicativă ·Taskin

Taskin

Od informacji do wykonanej pracy.

01

Context

Zbieramy odpowiednie autoryzowane źródła dla projektu.

02

Angajamente

Identyfikujemy decyzje i rzeczy do zrobienia do weryfikacji przez zespół.

03

Continuitate

Organizujemy odpowiedzialności i śledzenie potwierdzonych kroków.

Gdzie staje się przydatny.

Projekty

Odtwarzanie decyzji i priorytetów bez utraty kontekstu.

Întâlniri

Propozycje zadań z rozmów, sprawdzane przed użyciem.

Operațiuni

Kierunek koordynacji między ludźmi i agentami AI.

Funkcje i połączenia są w rozwoju. Nie zakładamy, że każda automatycznie wyodrębniona decyzja jest poprawna lub zatwierdzona.

Taskin w szczegółach

Co możesz zrobić z tym projektem.

Taskin to board pracy, który ma jedną cechę: nie czeka, aż wprowadzisz zadania. Czyta to, co już się wydarzyło — rozmowy, maile, kalendarz, wiadomości, commity, sesje pracy — i proponuje, co powinno zostać zrobione, wraz z dowodem, z którego wynika propozycja.

Rozróżnienie, które buduje, dotyczy tego, co zostało zaobserwowane, i tego, co zostało postanowione. Zadanie proponowane automatycznie nie staje się zobowiązaniem, dopóki osoba nie potwierdzi osoby odpowiedzialnej, terminu i sformułowania. Ta reguła nie jest obietnicą interfejsu, lecz ograniczeniem narzuconym w bazie danych: agent nie może zamknąć zadania, a każdy zapis, który je zamyka, musi zadeklarować, kto o to poprosił. Zapis bez nazwy jest odrzucany.

Używamy go na własny użytek. Prawie wszystko, co jest w nim interesujące, powstało dlatego, że brakowało nam czegoś konkretnego w działaniu własnej firmy, a komentarze w kodzie cytują rzeczywiste liczby z produkcji i incydenty z datą — w tym jeden, w którym codzienna rutyna milczała jedenaście dni z rzędu, bez wiedzy kogokolwiek.

01

Pełny board, a nie eksperyment

50 tras przez 49 stron: zespoły, cykle, projekty, zadania, inbox, roadmapa, plan dnia, klienci z kartą i historią, powtarzalne wydatki, fakturowanie, ewidencja czasu i sesje pracy, wyniki, wewnętrzny czat, administracja i członkowie. Baza ma 90 tabel, zbudowanych z 81 migracji.

02

Kolektor: 21 pętli, które przenoszą rzeczywistość na board

Rutyny uruchamiane na serwerze, a nie timery w procesie — bo timer ginie przy każdym redeploy. Każde uruchomienie przechodzi przez osłonę, która zapisuje dziennik i traktuje nawet odpowiedź HTTP 200 jako błąd, jeśli zawiera listę błędów, z alertem na Telegram. Osłona istnieje, ponieważ wcześniej komenda, która cicho kończyła się niepowodzeniem, zostawiła codzienny briefing martwy przez jedenaście dni.

03

Serwer MCP: ta sama kolejka dla ludzi i dla agentów

14 narzędzi przez HTTP — odczyt (lista, wyszukiwanie, moja kolejka, kolejka agentów, podsumowanie boardu, ludzie, agenci, projekty) i zapis (tworzenie, aktualizacja, przypisanie, przenoszenie, komentarz). Każdy token dostępu jest powiązany z realnym profilem, więc aktywność na boardzie odnotowuje, kto o nią poprosił. Agent AI i kolega pracują na tej samej liście, według tych samych zasad.

04

Rzeczywiste integracje, nazwane z imienia

Telegram, jako własny bot z ciągłym nasłuchem, w tym transkrypcją wiadomości głosowych. Cztery skrzynki mailowe (trzy Gmail i jedna Microsoft 365), czytane wyłącznie w trybie odczytu. Google Calendar. Połączenia telefoniczne przez trzon SIP, w tym przypominające połączenia inicjowane przez board. Obsidian. LinkedIn. Modele przechodzą przez własną bramę zgodną z OpenAI, a silnik wykonywania agentów korzysta z pętli narzędzi przez OpenRouter.

05

Reguła, której agenci nie mogą ominąć

„Agent nie zamyka zadania” to funkcja w bazie danych, a nie zdanie w opisie narzędzia. Trafiło tam, bo pierwsza wersja nie działała: identyfikowała aktora w sposób, który dla usługi automatycznej dawał pusty wynik, więc reguła nie miała zastosowania nigdzie. Teraz aktor jest rozstrzygany z trzech kolejnych źródeł i, jeśli nie da się go ustalić, żądanie jest odrzucane.

Dane i działanie

Co trafia do systemu. Co trzeba sprawdzić.

Izolacja na poziomie organizacji, weryfikowana na poziomie wiersza
Wszystkie 90 tabel ma włączony dostęp na poziomie wiersza, w ramach 171 polityk. Reguła wewnętrzna jest spisana i bez wyjątków: nowa tabela oznacza politykę dostępu dla niej. Hierarchia ról biegnie od Superadministratora do Administratora, Członka i Pracownika.
Źródła są odczytywane, nie pobierane
Skrzynki pocztowe są podłączone w trybie tylko do odczytu z założenia, a nie z konfiguracji. Sesje pracy i aktywność git są odczytywane z komputera osoby, a nie z serwera. To, co trafia na board, jest śladem z odsyłaczem do źródła, a nie kopią korespondencji.
Dane znajdują się na własnej infrastrukturze
Supabase hostowany przez nas na maszynie Azure, nie Supabase Cloud — Postgres, Kong, Auth, Realtime i Storage w Docker Compose. Adres bazy to ścieżka we własnej domenie. Migracje stosuje się ręcznie, celowo: nie istnieje automatyczny krok, który dotykałby schematu produkcyjnego.
Co widzi model językowy
Pętle, które streszczają, łączą i oceniają, wysyłają treść do modeli. Cztery z dziewięciu wewnętrznych pętli wyłączają się same, z wyraźnym komunikatem w dzienniku, gdy brakuje im poświadczenia — czyli brak klucza zatrzymuje przepływ, a nie sprawia, że działa połowicznie.

Od eksploracji do wdrożenia

Jak przygotowujemy projekt z Taskin.

01

Zaczynamy od jednego źródła i jednego projektu

Nie podłączamy wszystkiego. Jedno źródło — zwykle mail albo Telegram — i jeden rzeczywisty projekt, żeby na prawdziwych danych było widać, co proponuje system i jak dużo z tego jest użyteczne.

02

Porównujemy propozycje z rzeczywistymi decyzjami

Okres, w którym system proponuje, a zespół tylko potwierdza albo odrzuca, mówi, czy warto kontynuować. Odrzucona propozycja jest tak samo informatywna jak zaakceptowana.

03

Ustalamy reguły zamykania i przypisywania

Kto może co zamykać, co oznacza termin i co dzieje się z zadaniem bez odpowiedzialnej osoby. Tutaj decyduje się też, czy agenci mają prawo pisać na board i na jakich warunkach.

04

Instalujemy na uzgodnionej infrastrukturze

Dostawa odbywa się przez rsync na maszynę, nie kontener: interfejs jako statyczne katalogi serwowane przez nginx, kolektor i serwer MCP jako usługi systemd. Sprawdzenie stanu porównuje pakiet serwowany z zbudowanym i cofa wdrożenie, jeśli się nie zgadzają.

Pytania, które warto wyjaśnić.

To produkt ukończony czy demonstracja?

Działa w produkcji i jest tablicą, na której prowadzimy firmę. Liczby: 566 commitów, ostatni 4 września 2026; 81 migracji, które tworzą 90 tabel; 171 polityk dostępu na poziomie wiersza; 563 automatyczne przypadki testowe w 38 plikach; 21 zaplanowanych rutyn na serwerze plus 9 pętli w procesie; 14 narzędzi MCP; 35 endpointów na kolektorze. Czym nie jest: usługą samoobsługową. Nie ma przycisku, którym zespół z zewnątrz mógłby uruchomić to samodzielnie — to się instaluje.

Czy automatycznie decyduje, kto pracuje?

Nie, a ograniczenie jest w bazie danych, nie w interfejsie. Funkcja typu straż blokuje agentowi zamknięcie zadania, a każdy zapis zamykający coś musi zadeklarować aktora; jeśli aktora nie da się ustalić, żądanie jest odrzucane. Warto też powiedzieć, dlaczego reguła wygląda tak, a nie inaczej: pierwsza wersja identyfikowała aktora przez funkcję, która zwracała pusty wynik dla usługi automatycznej, więc nie działało to nigdzie. Własny audyt to wykrył, a migracja, która to naprawiła, wyjaśnia w komentarzu dokładnie, co nie działało.

Z czym konkretnie się łączy?

Realnie, z kodem i z rutyną zaplanowaną: Telegram (własny bot, stałe nasłuchiwanie, transkrypcja wiadomości głosowych), cztery skrzynki mailowe — trzy Gmail i jedna Microsoft 365 — tylko do odczytu, Google Calendar, połączenia telefoniczne przez trunk SIP, Obsidian, LinkedIn, a także sesje pracy i aktywność git odczytywane z komputera osoby. Modele przechodzą przez własną bramę zgodną z OpenAI; silnik wykonawczy agentów działa na OpenRouter. Czego NIE jest połączone, mimo że nasza strona integracji to pokazuje: Slack, GitHub, Jira, Notion, Figma, Zapier, Dropbox, Google Drive, Microsoft Teams, GitLab, Outlook. Sprawdziliśmy w kodzie i nie ma ani jednej linii dla żadnego z nich. Ta strona to siatka marketingowa i trzeba ją poprawić.

Czy istnieje integracja WhatsApp?

Nie, mimo nazwy jednego ekranu w aplikacji. Ten ekran to w rzeczywistości parowanie urządzenia przez kod QR, w stylu, do którego ludzie są przyzwyczajeni z WhatsApp Web — stąd ta nazwa. Nie ma żadnego wywołania do jakiegokolwiek API WhatsApp. Więcej: ten przepływ jest nieużywany, a jego tabele są puste, co stwierdza sama migracja, która zweryfikowała ich uprawnienia.

Jak jest z bezpieczeństwem, poza deklaracjami?

Użyteczne nie jest to, że mamy polityki dostępu, tylko to, że znaleźliśmy luki i naprawiliśmy je po jednej, a każda migracja wyjaśnia, co nie działało. Własny audyt z sierpnia wykrył, że wszystkie trzy straże dla agentów były nieaktywne. Inna straż okazała się fail-open — sprawdzenie było pomijane całkowicie, a nie odrzucane — i została odwrócona tak, by failować zamknięciem. Trzeci problem był subtelny i ogólny: w Postgres nowa funkcja jest domyślnie wykonywalna przez wszystkich, więc jawne przyznanie praw niczego nie zawężało; sprawdzono na produkcji, że anonimowy klucz trafiał do treści funkcji, po czym cofnięto domyślne prawo. Na poziomie repozytorium straż odrzuca bezpośrednie wypchnięcia na główną gałąź i blokuje pliki sekretów, ponieważ prywatne repozytorium na koncie osobistym nie może mieć ochrony gałęzi z GitHub.

Co nie jest gotowe?

Trzy rzeczy, o których wolimy mówić wprost. Wygenerowane typy dla bazy danych są stare od stycznia i zawierają tabele z całkowicie niepowiązanego projektu, co wymusiło 101 wymuszonych konwersji typów w 26 plikach — działa, ale traci sprawdzanie w czasie kompilacji dokładnie tam, gdzie by się przydało. Sprawdzacz stylu zgłasza 161 odziedziczonych błędów i nie blokuje dostawy. I 36 testów jest pomijanych w ciągłej integracji, bo potrzebują klucza modelu, którego tam nie ma. Żadne z nich nie zatrzymuje produktu; wszystkie trzy to realny dług.

Jak się to instaluje i jak bezpieczna jest dostawa?

Przez rsync, nie kontener: interfejs trafia do statycznego katalogu serwowanego przez nginx, kolektor i serwer MCP działają jako usługi systemd. Ciągła integracja uruchamia testy i buduje; dostawa startuje tylko wtedy, gdy te przeszły na głównej gałęzi, przez własny executor, który ma prawo uruchamiać dokładnie dwa skrypty i nic więcej. Każde zewnętrzne działanie w pipeline jest przypięte do pełnego odcisku, nie do etykiety, po kompromitacji popularnej akcji w marcu 2026. Sprawdzenie stanu odczytuje, do jakiego pakietu odwołuje się serwowany panel, i cofa wdrożenie, jeśli nie jest najnowszy — reguła napisana po rzeczywistym incydencie z 3 września 2026. Migracje bazy danych pozostają ręczne, celowo.

Przykład ilustracyjny

Rozmowa telefoniczna staje się zadaniem z dołączonym dowodem

Scenariusz użycia, bez danych klienta ani przypisanych wyników handlowych.

Sytuacja początkowa

Połączenie kończy się obietnicą. Nikt nigdzie jej nie zapisuje, a po tygodniu nikt nie pamięta ani co obiecano, ani komu.

Jak to działa

Połączenie trafia na board przez zaplanowaną rutynę, jako ślad z linkiem z powrotem do źródła. Pętla łączy je z właściwą kartą klienta i proponuje zadanie z odpowiedzialną osobą i terminem. Propozycja pozostaje propozycją: straż w bazie danych nie pozwala agentowi jej zamknąć, a zapis, który miałby ją zamknąć, musi zadeklarować, kto ją zlecił.

Rezultatul

Zadanie pojawia się z dołączonym kontekstem, z którego wynikło, tak aby osoba z zespołu, której nie było na rozmowie, mogła zrozumieć, co należy zrobić, bez odtwarzania dyskusji. Człowiek potwierdza osobę odpowiedzialną, termin i sformułowanie — albo odrzuca propozycję, co jest równie informacyjne.

Ce este necesar:Sursa trebuie conectată efectiv, cu acces autorizat, și trebuie să existe un acord al echipei asupra a ce înseamnă o sarcină atribuită. Sistemul nu presupune consimțământul nimănui.

Możliwości współpracy

Taskin, w kontekście Twojej organizacji.

Wewnętrzne przepływy i informacje

Łączenie autoryzowanych źródeł, porządkowanie informacji i weryfikacja działań przez zespół, z osobnym dostępem według ról.

Firmy prywatne

Definiujemy pilotaż wokół realnego procesu: użytkownicy, dane, integracje, koszty i kryteria akceptacji. Rozszerzenie następuje po ocenie wyniku.

Instytucje i spółki państwowe

Ustalamy wymagania dotyczące dostępności, hostingu, ochrony danych i interoperacyjności. Każde połączenie z usługami AGE lub STISC wymaga walidacji kwalifikowalności, dostępu i zatwierdzeń.

To są scenariusze adaptacji, a nie oświadczenia o istniejących umowach lub partnerstwach. Proponowane funkcje są potwierdzane w zakresie pracy projektu.

Discută un pilot

Część ekosystemu.

Co chcesz, żeby działało lepiej?

Opowiedz nam o swoim procesie. Wspólnie ustalimy, co warto zbudować, co da się połączyć i jak sprawdzimy wynik.

Porozmawiajmy