guwapi notes: notițe de proiect pe care Claude le ține la zi, cu dovezi din Git

Notițele de proiect rămân în urmă dintr-un motiv banal. Munca se face în Git și în conversații, iar notițele sunt un al doilea loc pe care trebuie să-ți aduci aminte să-l actualizezi. Ale mele erau mereu cu o zi în urma codului. Așa că aplicația pe care mi-am făcut-o pentru proiectele de clienți, guwapi notes, nu mai așteaptă să scriu eu actualizarea. Claude citește ce s-a schimbat cu adevărat, mută la verificare notițele terminate și propune restul, fiecare schimbare cu commit-ul sau pull request-ul care o dovedește. Eu aprob pe telefon, dintr-o atingere.

Despre asta e pagina: cum se actualizează singură o notiță, ce are voie Claude să facă și ce nu, și ce nu pleacă niciodată de pe telefon. Caietul din jur, cu statusuri, editor și widgeturi, vine după, pentru că e partea pe care o are orice aplicație de notițe. Filmul de sus arată toată aplicația într-un minut.

Cum se actualizează singură o notiță

Să zicem că tocmai am dat merge unui pull request care repară pagina de întrebări frecvente de pe site-ul unui client. Înainte deschideam notițele, căutam nota potrivită, îi schimbam statusul și scriam ce s-a făcut, dacă îmi aminteam. Acum scriu în Claude /notite și numele proiectului, iar restul se întâmplă așa. În film, chatul e animat; tot ce e pe telefon e înregistrare reală, pe un proiect real de client:

1. Claude citește notițele proiectului. Doar cât îi permite nivelul de acces al folderului, și nimic din folderele pe care le țin private.
2. Verifică munca propriu-zisă. Commit-urile, pull request-urile și fișierele din repo-ul de cod al proiectului, sau ce i-am spus în conversație.
3. Mută statusurile. O notiță terminată ajunge la De verificat, niciodată la Gata. Gata hotărăsc eu, după ce verific.
4. Propune restul. Un rând de adăugat într-o notiță, un pas de bifat, un pas pe care nu l-a scris nimeni (un link stricat pomenit într-un pull request, de exemplu) sau o notiță nouă. Fiecare propunere are dovada ei.
5. Accept sau resping pe telefon. Propunerile așteaptă la Claude propune. Dacă accept, se scriu în notiță, cu data și linkul spre dovadă; dacă resping, dispar. Până atunci, textul notiței nu se schimbă deloc.

Rezultatul e o notiță care se citește ca jurnalul proiectului: Actualizare · 5 nov · Claude, ce s-a făcut și Dovadă: commit 8f92b80, un link care deschide commit-ul.

Fără dovadă, nu propune

Totul se sprijină pe o singură regulă, scrisă în repo, unde Claude o citește înainte de orice schimbare: dacă nu poate arăta unde s-a întâmplat ceva, nu propune. Dovada e ceva ce pot deschide și verifica în câteva secunde: un commit, un pull request, un fișier și un rând, o rulare de teste sau un citat din conversația noastră, cu data. Când nu are așa ceva, Claude mă întreabă, nu ghicește.

Limitele sunt la fel de stricte. Claude nu marchează nimic drept gata în locul meu, nu modifică direct textul unei notițe și nu creează, nu șterge și nu redenumește fișiere în repo-ul de notițe. Poate muta statusuri și etichete, și doar după ce îi spun „da” în conversație; tot restul vine ca propunere.

Ce pleacă de pe telefon

notițe sincronizate dintr-un folder până nu-i alegi nivelul

0

niveluri de acces, pe fiecare folder, moștenite de subfoldere

4

commit la fiecare sincronizare, într-un repo privat al tău

1

Fiecare folder pornește ca Privat: nu se sincronizează nimic din el, iar Claude nici nu știe că există. Nivelul îl ridici pe fiecare folder, iar subfolderele îl moștenesc, dacă nu le pui altul.

Nivel	Ce vede Claude	Ce poate face Claude
Privat	Nimic. Folderul nu apare în repo.	Nimic.
Status	Titlurile, statusurile și etichetele.	Mută statusuri și etichete.
Status + jurnal	La fel, plus un jurnal de actualizări cu dată.	Propune actualizări și notițe noi, cu dovadă.
Complet	Notița întreagă.	Propune și bife sau pași noi, pe care îi aprobi tu.

Pentru munca confidențială mai e o opțiune, Ascunde titlurile. În repo ajung atunci doar coduri ca ABC-12 și foldere fără nume, iar titlurile reale rămân pe telefon, care face legătura cu codurile. Claude poate spune în continuare „ABC-12 e terminată, uite commit-ul”, fără să afle vreodată despre ce e vorba în ABC-12.

Cum funcționează sincronizarea

Dedesubt e Git simplu. Aplicația ține un repo GitHub privat, cu câte un fișier Markdown mic pentru fiecare notiță (titlu, status, etichete și doar cât permite nivelul folderului), un CLAUDE.md cu regulile de mai sus și o schemă cu statusurile și etichetele valide. Claude citește și scrie în repo cu uneltele lui obișnuite, iar aplicația se sincronizează cu el când o deschizi, când tragi în jos și la câteva secunde după o schimbare.

Fiecare sincronizare e un singur commit, făcut prin Git Data API de la GitHub. Fișierele sunt comparate după hash, ca notițele neschimbate să nu fie rescrise. Dacă telefonul și Claude au schimbat aceeași notiță, statusul și etichetele se combină în trei părți (three-way merge), ca să nu se piardă modificarea nimănui, iar notița arată cine a mutat-o: ✦ Claude · În lucru → De verificat. Tokenul GitHub are acces doar la acel repo și stă în Keychain-ul iPhone-ului; nu mai e afișat după salvare și nu ajunge în niciun fișier.

Așa arată pe telefon, de aproape: un proiect care își numără singur progresul, o notiță terminată cu dovada ei și celelalte bucăți pe care le găsești mai jos.

Caietul de dedesubt

Nimic din toate astea n-ar ajuta dacă notițele n-ar fi organizate cum e organizată munca cu clienții. În guwapi notes clientul e un folder, proiectul e un folder în el, iar fiecare notiță poate avea unul din cinci statusuri: De făcut, În lucru, De verificat, Problemă și Gata.

Gruparea pe status e esențială: o listă după dată îți spune la ce ai lucrat ultima dată, una pe statusuri îți spune ce ține proiectul pe loc. Filmul ăsta urmărește un client nou de la început, de la folder și nivelul lui de acces până la un proiect care și-a numărat singur progresul:

Scris, import, scanare

Notițele rareori încep într-o aplicație nouă, așa că importul primește Markdown, text simplu, RTF, HTML și PDF, un fișier sau un folder întreg cu subfolderele lui. Un vault de Obsidian intră așa cum e. PDF-urile își păstrează structura: titlurile sunt recunoscute după mărimea fontului, listele rămân liste, tabelele cu două coloane devin rânduri, iar imaginile ajung unde erau. Din cameră, Scanează document citește textul tipărit sau scris de mână direct pe telefon, cu Vision de la Apple, reface paragrafele și marchează rândurile de care nu e sigur, ca să le verifici.

Restul e ce te-ai aștepta să găsești, ținut la minimum. Cinci șabloane (meeting, brief de client, checklist de deploy, raport de bug, idee rapidă) și orice notiță salvată ca șablonul tău. Etichete alese dintr-o listă, ca să nu ajungi cu trei feluri de a scrie urgent. O culoare pe notiță, lizibilă și în modul luminos, și în cel întunecat. Remindere care deschid chiar notița și o ordine pe care o aranjezi de mână când nici data, nici statusul nu sunt ce vrei.

Pe ecranul de blocare

Cum e construită

Interfața e în SwiftUI, cu un text view din UIKit sub editor, pentru text formatat adevărat. Widgeturile folosesc WidgetKit, iar butonul de pe ecranul de blocare App Intents; datele le împart cu aplicația printr-un App Group. Recunoașterea textului rulează pe telefon, cu Vision, importul PDF folosește PDFKit, iar reminderele sunt notificări locale: fără server și fără cont. Fiecare buton are etichetă VoiceOver și o zonă de atingere de 44 de puncte, iar setarea Reducere mișcare e respectată.

Și e făcută fără Mac. Proiectul e generat cu XcodeGen și compilat pe un runner macOS din GitHub Actions, iar eu o instalez cu un Apple ID gratuit, prin SideStore. Semnătura gratuită ține șapte zile, așa că aplicația arată cât mai are, te anunță cu o zi și cu trei ore înainte să expire, iar în ultima zi îți dă un buton care deschide SideStore, ca s-o reîmprospătezi.

Întrebări frecvente