Sari la conținut
megapromotingHai să discutăm
Produse Taskin

Organizarea muncii Dezvoltare & demonstrații

Ce am stabilit. Cine continuă. Ce urmează.

Taskin explorează transformarea discuțiilor și a contextului de proiect în angajamente, priorități și pași de lucru. Scopul este să păstreze legătura dintre o sarcină și conversația din care a apărut.

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

Taskin

De la informație la lucru făcut.

01

Context

Reunim sursele autorizate relevante pentru proiect.

02

Angajamente

Identificăm deciziile și lucrurile de făcut pentru verificarea de către echipă.

03

Continuitate

Organizăm responsabilitățile și urmărirea pașilor confirmați.

Unde devine util.

Proiecte

Reconstituirea deciziilor și a priorităților fără a pierde contextul.

Întâlniri

Propuneri de sarcini din discuții, revizuite înainte de utilizare.

Operațiuni

O direcție pentru coordonare între oameni și agenți AI.

Funcțiile și conexiunile sunt în dezvoltare. Nu presupunem că orice decizie extrasă automat este corectă sau aprobată.

Taskin în detaliu

Ce poți face cu acest proiect.

Taskin e un board de lucru care are o particularitate: nu așteaptă să-i introduci sarcinile. Citește ce s-a întâmplat deja — apeluri, mail, calendar, mesaje, commituri, sesiuni de lucru — și propune ce ar trebui făcut, împreună cu dovada din care a apărut propunerea.

Distincția pe care o construiește e între ce a fost observat și ce a fost decis. O sarcină propusă automat nu devine angajament până când un om confirmă responsabilul, termenul și formularea. Regula asta nu e o promisiune de interfață, ci o restricție impusă în baza de date: un agent nu poate închide o sarcină, iar orice scriere care închide una trebuie să declare cine a cerut-o. O scriere fără nume e refuzată.

Îl folosim pe noi înșine. Aproape tot ce e interesant în el a apărut pentru că ne-a lipsit ceva concret în operarea propriei firme, iar comentariile din cod citează numărători reale din producție și incidente cu dată — inclusiv unul în care o rutină zilnică a tăcut unsprezece zile la rând fără ca nimeni să afle.

01

Un board complet, nu un experiment

50 de rute peste 49 de pagini: echipe, cicluri, proiecte, sarcini, inbox, foaie de parcurs, planul zilei, clienți cu dosar și istoric, cheltuieli recurente, facturare, pontaj și sesiuni de lucru, performanțe, chat intern, administrare și membri. Baza are 90 de tabele, construite din 81 de migrări.

02

Colectorul: 21 de bucle care aduc realitatea pe board

Rutine programate pe server, nu temporizatoare în proces — pentru că un temporizator se pierde la fiecare redeploy. Fiecare rulare trece printr-un înveliș care scrie jurnal și tratează chiar și un răspuns HTTP 200 ca eșec dacă poartă o listă de erori, cu alertă pe Telegram. Învelișul există pentru că, înainte, o comandă care eșua silențios a lăsat briefingul zilnic mort unsprezece zile.

03

Server MCP: aceeași coadă pentru oameni și pentru agenți

14 unelte peste HTTP — citire (listare, căutare, coada mea, coada agenților, rezumat de board, oameni, agenți, proiecte) și scriere (creare, actualizare, atribuire, mutare, comentariu). Fiecare token de acces e legat de un profil real, deci activitatea pe board consemnează cine a cerut-o. Un agent AI și un coleg lucrează pe aceeași listă, cu aceleași reguli.

04

Integrări reale, numite pe nume

Telegram, ca bot propriu cu ascultare permanentă, inclusiv transcrierea mesajelor vocale. Patru căsuțe de mail (trei Gmail și una Microsoft 365), citite exclusiv în mod citire. Google Calendar. Apeluri telefonice, prin trunchi SIP, inclusiv apeluri de reamintire inițiate de board. Obsidian. LinkedIn. Modelele trec printr-un gateway propriu compatibil OpenAI, iar motorul de execuție al agenților folosește o buclă de unelte peste OpenRouter.

05

Regula pe care agenții nu o pot ocoli

„Un agent nu închide o sarcină” e o funcție în baza de date, nu o propoziție într-o descriere de unealtă. A ajuns acolo pentru că prima variantă nu funcționa: identifica actorul într-un fel care ieșea gol pentru un serviciu automat, deci regula nu se aplica nicăieri. Acum actorul se rezolvă din trei surse succesive și, dacă nu se poate stabili, cererea e refuzată.

Date și funcționare

Ce intră în sistem. Ce trebuie verificat.

Izolare pe organizație, verificată la nivel de rând
Toate cele 90 de tabele au acces la nivel de rând activat, sub 171 de politici. Regula internă e scrisă și fără excepții: un tabel nou înseamnă politică de acces pe el. Ierarhia de roluri merge de la Super Admin la Admin, Membru și Angajat.
Sursele se citesc, nu se preiau
Căsuțele de mail sunt conectate în mod citire prin proiectare, nu din configurare. Sesiunile de lucru și activitatea git se citesc de pe calculatorul persoanei, nu de pe server. Ce ajunge pe board e o urmă, cu legătură înapoi la sursă, nu o copie a corespondenței.
Datele stau pe infrastructură proprie
Supabase găzduit de noi pe o mașină Azure, nu Supabase Cloud — Postgres, Kong, Auth, Realtime și Storage în Docker Compose. Adresa bazei e o cale pe propriul domeniu. Migrările se aplică manual, deliberat: nu există pas automat care să atingă schema de producție.
Ce vede un model de limbaj
Buclele care rezumă, leagă și judecă trimit conținut către modele. Patru dintre cele nouă bucle interne se dezactivează singure, cu mesaj explicit în jurnal, când le lipsește credențialul — deci absența unei chei oprește fluxul, nu îl face să ruleze pe jumătate.

De la explorare la implementare

Cum pregătim un proiect cu Taskin.

01

Pornim de la o singură sursă și un singur proiect

Nu conectăm tot. O sursă — de obicei mailul sau Telegram — și un proiect real, ca să se vadă pe date adevărate ce propune sistemul și cât din ce propune e util.

02

Comparăm propunerile cu deciziile reale

Perioada în care sistemul propune și echipa doar confirmă sau respinge e cea care spune dacă merită continuat. O propunere respinsă e la fel de informativă ca una acceptată.

03

Așezăm regulile de închidere și de atribuire

Cine poate închide ce, ce înseamnă un termen și ce se întâmplă cu o sarcină fără responsabil. Aici se decide și dacă agenții au voie să scrie pe board, și în ce condiții.

04

Instalăm pe infrastructura convenită

Livrarea e prin rsync către o mașină, nu container: interfața ca directoare statice servite de nginx, colectorul și serverul MCP ca servicii systemd. Verificarea de sănătate compară pachetul servit cu cel construit și derulează înapoi dacă nu se potrivesc.

Întrebări care merită clarificate.

E un produs finalizat sau o demonstrație?

Rulează în producție și e board-ul pe care ne conducem firma. Cifrele: 566 de commituri, ultimul pe 4 septembrie 2026; 81 de migrări care construiesc 90 de tabele; 171 de politici de acces la nivel de rând; 563 de cazuri de test automate în 38 de fișiere; 21 de rutine programate pe server plus 9 bucle în proces; 14 unelte MCP; 35 de endpointuri pe colector. Ce nu e: un serviciu cu autoservire. Nu există un buton prin care o echipă din afară să-l pornească singură — se instalează.

Decide automat cine lucrează?

Nu, și restricția e în baza de date, nu în interfață. O funcție de tip gardă împiedică un agent să închidă o sarcină, iar orice scriere care închide una trebuie să declare actorul; dacă actorul nu poate fi stabilit, cererea e refuzată. Merită spus și de ce regula arată așa: prima variantă identifica actorul printr-o funcție care întorcea gol pentru un serviciu automat, deci nu se aplica nicăieri. Un audit propriu a găsit-o, iar migrarea care a reparat-o explică în comentariu exact ce nu funcționa.

Cu ce se conectează, concret?

Real, cu cod și cu rutină programată: Telegram (bot propriu, ascultare permanentă, transcrierea mesajelor vocale), patru căsuțe de mail — trei Gmail și una Microsoft 365 — citite doar, Google Calendar, apeluri telefonice prin trunchi SIP, Obsidian, LinkedIn, plus sesiuni de lucru și activitate git citite de pe calculatorul persoanei. Modelele trec printr-un gateway propriu compatibil OpenAI; motorul de execuție al agenților merge pe OpenRouter. Ce NU e conectat, deși pagina noastră de integrări le afișează: Slack, GitHub, Jira, Notion, Figma, Zapier, Dropbox, Google Drive, Microsoft Teams, GitLab, Outlook. Am căutat în cod și nu există nicio linie pentru niciunul. Pagina aceea e o grilă de marketing și trebuie corectată.

Există integrare WhatsApp?

Nu, în ciuda numelui unui ecran din aplicație. Ecranul respectiv e de fapt împerecherea unui dispozitiv prin cod QR, în stilul cu care lumea e obișnuită de la WhatsApp Web — de acolo vine numele. Nu există niciun apel către vreun API WhatsApp. Mai mult: fluxul acela e nefolosit, iar tabelele lui sunt goale, lucru pe care îl constată chiar migrarea care le-a revizuit permisiunile.

Cum e cu securitatea, dincolo de declarații?

Partea utilă nu e că avem politici de acces, ci că le-am găsit găurile și le-am reparat una câte una, fiecare migrare explicând ce nu funcționa. Un audit propriu din august a descoperit că toate cele trei garduri pentru agenți erau inerte. O altă gardă se dovedise fail-open — verificarea era sărită complet, nu respinsă — și a fost inversată să eșueze închis. A treia problemă era subtilă și generală: în Postgres o funcție nouă e executabilă implicit de toată lumea, deci acordarea explicită de drepturi nu restrângea nimic; s-a verificat pe producție că o cheie anonimă ajungea în corpul funcției, apoi s-a revocat dreptul implicit. La nivel de depozit, o gardă respinge împingerile directe pe ramura principală și blochează fișierele de secrete, pentru că un depozit privat pe cont personal nu poate avea protecție de ramură din partea GitHub.

Ce nu e terminat?

Trei lucruri pe care preferăm să le spunem. Tipurile generate pentru baza de date sunt vechi din ianuarie și conțin tabele dintr-un proiect complet nereferitor, ceea ce a forțat 101 conversii de tip forțate în 26 de fișiere — funcționează, dar pierde verificarea la compilare exact acolo unde ar folosi. Verificatorul de stil raportează 161 de erori moștenite și nu blochează livrarea. Și 36 de teste sunt sărite în integrarea continuă pentru că au nevoie de o cheie de model care nu există acolo. Niciunul nu oprește produsul; toate trei sunt datorie reală.

Cum se instalează și cât de sigură e livrarea?

Prin rsync, nu container: interfața ajunge într-un director static servit de nginx, colectorul și serverul MCP rulează ca servicii systemd. Integrarea continuă rulează testele și construiește; livrarea pornește doar dacă acelea au trecut pe ramura principală, printr-un executor propriu care are voie să ruleze exact două scripturi și nimic altceva. Fiecare acțiune externă din pipeline e fixată pe amprenta ei completă, nu pe o etichetă, după compromiterea unei acțiuni populare în martie 2026. Verificarea de sănătate citește ce pachet referă pagina servită și derulează înapoi dacă nu e cel proaspăt — regulă scrisă după un incident real din 3 septembrie 2026. Migrările de bază de date rămân manuale, deliberat.

Exemplu ilustrativ

O discuție telefonică devine o sarcină cu dovadă atașată

Un scenariu de utilizare, fără date de client sau rezultate comerciale atribuite.

Situația inițială

Un apel se termină cu o promisiune. Nimeni nu o scrie nicăieri, iar peste o săptămână nimeni nu-și amintește nici ce s-a promis, nici cui.

Cum lucrează

Apelul intră pe board printr-o rutină programată, ca urmă cu legătură înapoi la sursă. O buclă îl leagă de dosarul clientului potrivit și propune o sarcină cu responsabil și termen. Propunerea rămâne propunere: gardul din baza de date nu permite unui agent să o închidă, iar scrierea care ar închide-o trebuie să declare cine a cerut-o.

Rezultatul

Sarcina apare cu contextul din care a rezultat atașat, astfel încât un coleg care nu a fost în apel poate înțelege ce trebuie făcut fără să reconstruiască discuția. Un om confirmă responsabilul, termenul și formularea — sau respinge propunerea, ceea ce e la fel de informativ.

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.

Posibilități de colaborare

Taskin, în contextul organizației tale.

Fluxuri interne și informație

Conectarea surselor autorizate, organizarea informației și revizuirea acțiunilor de către echipă, cu acces separat pe roluri.

Companii private

Definim un pilot în jurul unui proces real: utilizatori, date, integrări, costuri și criterii de acceptare. Extinderea urmează după evaluarea rezultatului.

Instituții și companii de stat

Stabilim cerințele de accesibilitate, găzduire, protecție a datelor și interoperabilitate. Orice conexiune cu servicii AGE sau STISC necesită validarea eligibilității, accesului și aprobărilor.

Acestea sunt scenarii de adaptare, nu declarații despre contracte sau parteneriate existente. Funcțiile propuse se confirmă în domeniul de lucru al proiectului.

Discută un pilot

Parte dintr-un ecosistem.

Ce ai vrea să funcționeze mai bine?

Povestește-ne despre procesul tău. Împreună stabilim ce merită construit, ce putem conecta și cum verificăm rezultatul.

Hai să discutăm