comun/skills/roa-git-svn-commit/SKILL.md

name: roa-git-svn-commit description: Fluxul de commit si sincronizare pentru biblioteca partajata COMUN (SVN = sursa de adevar, git = oglinda), cu arbore de decizie pentru roa_sync, write-back, aprobare explicita si svn commit tintit, ca sa nu pierzi munca necomisa. Foloseste-l OBLIGATORIU cand utilizatorul spune "am terminat, dau commit", "vreau sa comit in COMUN", "comit ce am lucrat", "sincronizeaza cu SVN", "adu ce au facut altii", "ruleaza roa_sync", "de ce nu merge git pull in COMUN" sau cere orice commit/sincronizare care atinge COMUN. Regula centrala: pe main din COMUN scrie DOAR roa_sync, commit-urile se fac tintit pe fisierele aprobate (niciodata pe tot COMUN), iar git pull in COMUN este interzis. Nu improviza ordinea pasilor si nu rula roa_sync pe un tree murdar: distruge munca necomisa.

Commit si sincronizare in COMUN (SVN + git)

SVN = sursa de adevar. git = oglinda. Pe main din COMUN scrie doar roa_sync. Comenzile le rulezi tu; utilizatorul doar aproba - dar nimic nu se comite fara un "da" explicit de la el.

Cand se foloseste

• "am terminat, dau commit", "vreau sa comit in COMUN", "comit ce am lucrat";
• "sincronizeaza cu SVN", "adu ce au facut altii", "ruleaza roa_sync", "de ce am conflicte";
• intrarea intr-o sesiune de lucru in proiect (sync de inceput).

Nu se aplica altui repo decat COMUN + proiectul care il contine. Pentru editarea codului VFP (.vcx/.scx prin .vc2/.sc2) vezi skill-ul roa-vfp-text-edit.

Pasi

Arbore de decizie - opreste-te la primul caz care se potriveste.

1. Intri in proiect -> rulezi roa_sync.bat, fara sa intrebi, DOAR daca svn status si git status sunt curate. Daca nu sunt, intrebi intai (pot fi modificari nefinalizate ale altcuiva).
2. Ai editat .prg / .md / .ps1 / .sql (proiect sau COMUN) -> antetul la zi, testul rulat, diff-ul scris ca fisier in docs\.
3. Ai editat .vc2 / .sc2 -> txt2vcx.ps1 IMEDIAT, apoi verifici pe binar (reconversie intr-un cache temporar + comparatie; mtime nu dovedeste nimic). Text fara write-back = modificarea nu exista. Abia apoi antet / test / diff.
4. Ceri aprobarea, explicit si complet: lista fisierelor de comis + mesajul propus. Nu presupune "da" din tacere si nu amana pentru "mai tarziu" - el nu tine minte pasul, tu il tii.
5. A zis "da" -> rulezi tu svn commit tintit, doar fisierele aprobate: .prg sau .scx + .sct, niciodata .sc2. Niciodata tot COMUN (intra zgomotul de compilare VFP).
6. Imediat dupa -> roa_sync.bat. Raportezi revizia SVN si ce a intrat pe main.
7. A zis "nu" / cere modificari -> nu comiti, nu insisti, nu rulezi roa_sync. Lucrarea ramane necomisa pe disc si o raportezi asa la predarea contextului.

Cazuri

• Vrei sa-ti tii munca in git -> branch. In repo-ul proiectului: liber. In COMUN: claude/<subiect>, commit doar acolo, niciodata pe main.
• Ai terminat branch-ul -> proiect: merge in main, normal. COMUN: fara merge; dupa svn commit continutul ajunge pe main ca sync SVN rN, iar branch-ul se sterge (doar daca git diff main..branch e gol).
• Esti pe branch in COMUN si te bate gandul la roa_sync -> nu. roa_sync se ruleaza in exact doua momente: la intrarea in proiect si imediat dupa svn commit. Pe branch cu tree curat face checkout main fara sa intrebe (binarele raman de pe branch); pe branch murdar sare peste, dar svn update de la pasul 1 ruleaza oricum si poate aduce binare peste ce ai pe disc.
• Vrei svn update -> doar din stare curata, niciodata in mijlocul lucrului. Daca ai text .??2 editat fara write-back, fa intai write-back-ul.
• svn update a dat conflict -> opreste-te si raporteaza; binarele nu se rezolva manual.
• Dupa svn update git arata fisiere modificate -> e oglinda ramasa in urma, nu munca ta; nu le comite de mana, le ia roa_sync intr-un sync SVN rN.
• Vrei sa aduci ce au facut altii -> roa_sync.bat. Niciodata git pull: git poarta doar textele, nu binarele; un pull da .sc2 nou peste .scx/.sct vechi, VFP compileaza binarul, iar urmatorul git_sync sterge modificarea.
• Copie de COMUN ramasa in urma -> se aliniaza singura la primul roa_sync.bat rulat acolo.
• Predai contextul -> raporteaza explicit daca ai lasat text .??2 editat fara write-back (stare periculoasa).

Interzis

• git commit / git push / git merge pe main in COMUN.
• git pull in COMUN - aduce textele fara binare; se foloseste roa_sync.bat.
• git commit pe tot COMUN sau pe .sc2 - doar tintit, pe fisierele aprobate.
• Copierea unui fisier dintr-o copie de COMUN in alta - svn update il duce; copierea = intrare dubla.
• Write-back pe .fr2 / .mn2 / .lb2 / .pj2 - nesuportat; acolo se modifica in IDE.
• Commit fara un "da" explicit de la utilizator.

Criterii de acceptare si dovada

Fara dovada da/nu de mai jos, commit-ul/sincronizarea NU se raporteaza ca terminata. "Arata bine" nu e dovada.

1. Inainte de commit: git status --porcelain contine EXACT fisierele aprobate; nimic neasteptat stagiat.
2. Dupa svn commit: svn status curat pe fisierele tintite, iar revizia SVN este raportata.
3. Dupa commit: roa_sync.bat a rulat si raporteaza succes (exit 0, commit sync SVN rN pe main in COMUN, fara avertismente de conflict).
4. git status curat pe fisierele tintite in COMUN; branch-urile claude/* terminate sunt inchise, cele active raportate.
5. Verificarea se face inainte de svn commit: fara "da" explicit, commit-ul nu are loc (skill-ul nu comite din proprie initiativa).
6. Daca utilizatorul a zis "nu": dovada e absenta oricarei urme de commit sau sync in log.

Scripturi

• D:\ROA\ROAFACTURARE\roa_sync.bat (sau roa_sync.bat din radacina proiectului).
• D:\ROA\ROAFACTURARE\COMUN\scripts\roa_sync.ps1 - -ProjectRoot <root>, iar -GitOnly sare peste SVN si regenerarea textelor.
• D:\ROA\UTIL\foxbin2prg\txt2vcx.ps1 si git_sync.ps1 - doar daca ai atins binare.

Referinta (doar la nevoie)

• Doar daca ai nevoie de contextul complet, citeste COMUN\docs\fluxul_svn_git.md (cazuri, interdictii) pentru fluxul SVN + git.