[Kontynuacja 2026-09-16] Zabezpieczyć routing repozytoriów i wiarygodność synchronizacji GitHub

[tom-sapletta-com]

Cel następnej sesji — 16.09.2026

Zabezpieczyć routing repozytoriów i wiarygodność synchronizacji GitHub.

Zweryfikowany punkt startowy

• Repozytorium docelowe: semcod/planfile; powiązanie sprawdzone przez remote Git i GitHub API.
• Snapshot lokalnego HEAD: 40dbf7164fdebf62247c8609e838fa8941749492; gałąź fix/generator-analysis-passthrough.
• Checkouty: /home/tom/github/semcod/planfile.
• Opis repozytorium: SDLC automation platform - strategic project management with CI/CD integration and automated bug-fix loops.
• Otwarte issues do sprawdzenia przed implementacją: Kontynuacja 2026-09-15: sync GitHub wiąże nowy ticket z cudzym issue o tym samym lokalnym ID #91, Kontynuacja 2026-09-15: konflikt #78 (override git-ancestry) i przyczyna Locked tests na main #90, [EXT-06] Make project-scoped GitHub handoff sync observable and fail closed #89, [Kontynuacja 2026-09-15] Potwierdzona publikacja Issues: jawne repo, bledy synchronizacji i readback #88. Nie tworzyć ponownie już realizowanego zakresu.

Kolejne kroki i kryteria odbioru

• Potwierdzony audytem błąd: auto_discover() idzie do rodziców ponad granicę zagnieżdżonego repo Git. Siedem checkoutów pod C2004 odziedziczyło maskservice/c2004 mimo innego origin.
• Dodać deterministyczne przypisanie repozytorium oraz zatrzymanie/diagnostykę przy niezgodności origin z integrations.github.repo. Testować submoduły i osobne checkouty.
• ticket create domyślnie zapisuje tylko lokalnie; --sync obejmuje kwalifikujący się backlog. Dodać ograniczenie synchronizacji do konkretnych ticket IDs i czytelne repo docelowe w planie.
• sync_to_external łapie wyjątki per ticket i kontynuuje. Zapewnić niezerowy kod zakończenia oraz trwały raport częściowego błędu zamiast pozornego sukcesu CLI.
• Zweryfikować trwałe mapowanie lokalny ticket → GitHub repo/issue/url/marker, ponowną synchronizację bez duplikatu i zdalny odczyt po zapisie.
• Używać tej kolejki jako canary: wszystkie issues tej kontynuacji mają powstać przez Planfile, nie przez gh issue create.
• Zapisać faktyczny wynik, testy, commit/PR lub uzasadniony no-change; zweryfikować synchronizację statusu Planfile z tym issue.

Zasady wznowienia

Przed edycją ponownie odczytać stan Git, AGENTS.md i właściwy ticket-lifecycle/Wellmanifest. Ten issue jest backlogiem do kontynuacji, nie potwierdzeniem testów ani niezależnym approval. Zachować niepowiązane zmiany, operacyjne bazy i ograniczenia sprzętu.

Utworzenie i publikacja: Planfile CLI 0.1.124; kolejka audytu planfile-continuation-20260915. Zapis lokalny sam w sobie nie oznacza utworzenia issue — wymagany jest zdalny odczyt repo/number/title/markera.

Reprodukcja potwierdzona 15.09.2026

• Zainstalowany CLI: 0.1.124, kod a00ccbe9c1d06193d3331b9e0ec8ab14a6922bdb.
• Wywołano rzeczywisty Planfile.auto_discover dla 7 checkoutów, podmieniając wyłącznie konstruktor na odczytowy rejestrator, aby nie modyfikować ich plików. Wszystkie rozwiązały się do rodzica C2004.
• Uruchomiono rzeczywisty command sync github --direction to przez Typer CliRunner z backendem rzucającym syntetyczny wyjątek. Zero połączeń sieciowych; wynik: exit_code=0, komunikat completed successfully, widoczny Failed to sync, pusty remote_reference.
• Oddzielny test rzeczywistej publikacji i powtórnej synchronizacji maskservice/update zachował jeden issue fix(store): preserve ticket ids from journal history #148 oraz marker Planfile. Problemy dotyczą więc wiarygodności wyniku/routingu, nie całkowitego braku możliwości publikacji.

Dowody lokalne: ~/.local/state/planfile-continuation-20260915/{routing-canary.json,failure-canary.json,idempotency-receipt.json}.