Przejdź do treści
megapromotingPorozmawiajmy
Produkty Taskin

Organizacja pracy Rozwój i demonstracje

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. 1Dyskusja i kontekst
  2. 2Sarcini propuse
  3. 3Angajamente confirmate
Schemat objaśniający ·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

Ciągłość

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

Gdzie staje się przydatny.

Projekty

Odtwarzanie decyzji i priorytetów bez utraty kontekstu.

Spotkania

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

Operacje

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.

Co jest potrzebne:Źródło musi być faktycznie podłączone, z autoryzowanym dostępem, i musi istnieć zgoda zespołu co do tego, co oznacza przypisane zadanie. System nie zakłada niczyjej zgody.

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.

Omów pilotaż

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