IDE i wytwarzanie oprogramowania¶

Cel¶

Moduł coding prowadzi cały kontrolowany cykl: analiza repozytorium, reprodukcja, hipotezy, candidate patch, testy, diff, review i osobna promocja. Może integrować się z IDE, ale kanoniczny stan pracy znajduje się w repozytorium i Execution Fabric, nie w pamięci okna edytora.

Karta modułu Coding¶

Pole	Kontrakt
Odpowiedzialności	code search, plan, worktree, typed edit, tests, static/security gates, review evidence, promotion proposal.
Wejścia	repo ID, issue/spec, base commit, manifested paths, test policy, constraints.
Wyjścia	candidate commit, diff hash, test receipts, risk notes, artifact builds, rollback plan.
Zależności	Repository Guard, coding model, IDE adapter, test tools, Tool Registry, Audit.
Uprawnienia	read repo, write candidate, registered tests; main/push/tag/install/deploy osobno.
Autonomia	może iterować w kandydacie i testować; brak autonomicznej promocji lub rozszerzenia manifestu.
Walidacja	syntax, lint/type, unit/integration/e2e, security, diff scope, warnings, deterministic gates.
Awaria	main bez zmian, candidate zachowany, przerwanie testu, cleanup tylko po osobnej polityce.

Analiza przed zmianą¶

Agent zaczyna od instrukcji repozytorium, manifestu, architektury, testów i logów. Formułuje kilka hipotez oraz testy rozróżniające. Nie wdraża pierwszego intuicyjnego patcha bez reprodukcji, jeżeli reprodukcja jest możliwa. Ostrzeżenia są analizowane; nie są wyciszane kosmetycznie bez uzasadnienia.

Worktree i candidate¶

Repository Guard weryfikuje clean main, expected branch i base commit, tworzy unikatowy worktree, zapisuje real path oraz Git common dir i attested state. Agent otrzymuje worktree_id, nie zaufaną ścieżkę. Każda operacja resolve'uje path, odrzuca absolute, .., reparse/symlink escape, .git, common metadata, runtime roots i protected paths.

flowchart LR
    I["Issue/spec"] --> A["Analiza + reprodukcja"]
    A --> W["Attested worktree"]
    W --> P["Typed patch"]
    P --> T["Static + tests"]
    T --> D["Diff + evidence"]
    D --> R["Independent review"]
    R --> F["Freeze candidate"]
    F --> X["Osobny promotion approval"]
    X --> M["Promotion tool"]

Main jest read-only dla zwykłych narzędzi. Candidate jest zamrażany przed review. Nowa edycja zmienia commit/diff hash i unieważnia approvals. Promotion principal ponownie sprawdza aktualny main, candidate, testy i exact diff. Nie używa force/amend ani broad staging. Push, tag i publikacja release są dalszymi osobnymi operacjami.

IDE¶

IDE adapter może otwierać plik, wskazywać symbol, pokazywać diagnostics i stosować zatwierdzony patch, ale nie jest ogólnym kanałem klawiatury. Preferowane są Language Server Protocol, parsery AST i API edytora. Visual automation służy tylko do funkcji bez API i zatrzymuje się przy nieoczekiwanym oknie, focus lub layoucie.

Testy¶

Każde narzędzie testowe jest zarejestrowanym profilem z komendą stałą po stronie adaptera, dozwolonymi parametrami, timeoutem, resources i output parserem. Agent nie przesyła dowolnej komendy. Testy nie dotykają produkcji, sekretów ani zabronionych ścieżek. Warnings-as-errors, strict UTF-8, brak artefaktów runtime w Git i secret scan są standardowymi bramkami.

Warstwy obejmują unit, schema/property, DB/concurrency, integration, restart/crash, adversarial paths, e2e i visual QA. Test źródłowego stringa może uzupełniać, ale nie zastępuje wykonania realnego interfejsu.

Przykładowe polecenia¶

„Znajdź przyczynę wyścigu, przygotuj minimalny patch i test wieloprocesowy.”
„Dodaj endpoint według tego kontraktu w kandydacie; nie instaluj zależności.”
„Porównaj dwie implementacje na benchmarku i wyjaśnij trade-offy.”
„Przygotuj release notes z exact diff, ale nie commituj, nie taguj i nie publikuj.”

Pełny przebieg¶

Zgłoszenie dotyczy podwójnego wykonania joba. Agent analizuje state machine i testy, proponuje hipotezy: process-local lock, nieatomowy update lub stale token. W izolowanej bazie uruchamia test dwóch procesów. Reprodukuje dwóch zwycięzców. Candidate patch zmienia przejście na jeden atomowy SQL predicate, a test powtarza race wiele razy. Następnie uruchamia regresję, restart i migration tests. Review pokazuje diff, dowód reprodukcji przed/po i ryzyka. Promocja nie jest częścią tego joba.

Walidacja wyniku¶

Sukces oznacza spełnione acceptance criteria, brak niezamierzonych zmian, wszystkie wymagane gates, wyjaśnione ostrzeżenia i reprodukcję naprawionego problemu. Dla funkcji bezpieczeństwowej wymagany jest test negatywny i concurrency/restart tam, gdzie dotyczy. Pokrycie linii nie jest samodzielnym dowodem jakości.

Błędy, ryzyka i awaria¶

Ryzyka to prompt injection w repo, złośliwy test, dependency install, modyfikacja main przez absolutną ścieżkę, ukrycie błędu mockiem i pętla patchy. Instrukcje w kodzie są niezaufane wobec polityki. Narzędzia mają stałe profile. Po dwóch–trzech nieskutecznych hipotezach agent podsumowuje dowody i zmienia metodę albo eskaluje.

Awaria workera pozostawia main nietknięty. Worktree zostaje zachowany do review; lease wygasa, a test otrzymuje receipt. Niepewne artefakty są oznaczone. Cleanup worktree jest osobnym, recoverable workflow, a nie automatyczną konsekwencją błędu.