przeprogramowani
b0c789af70
* docs(10xdevs4-cli-access): record membership gates and bootstrap context (p1) Add canonical access plan, accepted decisions and supporting context. Record phase 1 verification, Toolkit revision and remaining evidence gaps. * docs(10xdevs4-cli-access): record course access gates and scoped review (p2) Update canonical Progress, change status, evidence and implementation review. Record Toolkit revisions, inherited typecheck limitation and phase 3 prerequisites. * docs(10xdevs4-cli-access): persist reviewed revisions and phase 3 boundary Record final reviewed Toolkit and CLI context revisions. Persist Progress attribution and unresolved W04/W05/W08 prerequisites. Keep phases 3–6, phase 7 and Manual criteria open. * docs(10xdevs4-cli-access): record squash-safe source prerequisite Record PR #30, verified gates, permanent-pin lessons and the remaining merge dependency. Keep phase 3 and all manual rollout criteria pending. * docs(10xdevs4-cli-access): record source prerequisite review Record independent review of PR #30 and verified CI evidence. Keep the master pin and delivery phase completion pending. * docs(10xdevs4-cli-access): distinguish candidate checks from final master pins Record passing pre-merge v4 checks and defer workflow suspension. Keep the final v3 maintenance pin dependent on the resulting master SHA. * feat: prepare v4 course delivery and protected project sync Capture the reviewed implementation and manual rehearsal for draft PR review. Master source prerequisites, full clean verification and coordinated Windows CI remain open; production rollout is separate. * fix: keep paid CI evidence private and converge cumulative sync * docs: record merged source prerequisite and passing clean gate * fix: preserve generated API type line endings on Windows --------- Co-authored-by: Claude <noreply@anthropic.com>
3.7 KiB
10xDevs 4 — pierwsze wydanie: dostęp i dostarczanie
Aktualizacja: 2026-09-12. Plan · Rekord akceptacji · Podział prac · Dowody do zebrania
Uczestnik mający tylko v4 ma się zalogować i pobrać pierwszy tydzień bez podawania edycji. Nowy projekt z dostępem do obu kursów wybierze dostępne v4. Istniejący projekt v3 zachowa edycję i sposób pracy również po zakupie v4.
To pierwsza z dwóch zmian. Druga — migracja projektów — pozwoli świadomie przenieść istniejący projekt, zachować niedostępne jeszcze skille v3 i wymieniać je później przez sync. Każda zmiana może wymagać PR-ów w CLI i toolkit. Jedno miejsce postępu na zmianę znajduje się w jej planie w repo CLI; toolkit zawiera odnośniki i swój zakres.
Co obejmuje pierwsze wydanie
Toolkit naprawi zachowanie grantów, dopuści logowanie v4-only i sprawdzi uprawnienia na każdej trasie treści. Formalna specyfikacja programu będzie określała oczekiwaną zawartość lekcji; automatyczna walidacja porówna ją z definicjami i wynikowymi paczkami EN/PL. Dokładna zawartość nadal wymaga dowodu zgodności z kursem.
CLI będzie wybierał edycję według kolejności: jawny wybór → edycja istniejącego projektu → rekomendacja API. Poprawimy propagowanie wybranego kursu do manifestów, bezpieczne usuwanie plików oraz podglądy, które obecnie mogą zmieniać konfigurację. Zwykły get/sync nie będzie przełączał edycji projektu. Do czasu drugiego wydania v4 można rozpocząć w osobnym katalogu.
V3 zachowuje obecne obiekty R2. Cutoff sprzed v4 będzie bazą źródeł dla jawnych poprawek utrzymaniowych; wybór commita nie oznacza nadpisania obecnej publikacji. Testujemy osobno stary CLI z nowym backendem i nowy CLI na istniejącym projekcie v3. Użytkownik tylko v3 nie musi migrować ani dodawać flag.
Jak trafiają do użytkownika nowe skille
Wersja źródła wynika z kolejności SHA pliku → SHA całej paczki skilla → domyślna wersja kursu. Pin paczki obejmuje SKILL.md, references, skrypty i pozostałe pliki. V4 domyślnie bierze latest rozwiązane raz do konkretnego SHA podczas budowania. CLI pobiera gotową publikację, nie repozytorium Git.
Każde wydanie v4 ma własny niezmienny katalog w R2 i manifest hashy. Get/sync wybiera jedno wydanie na całą operację. CI buduje i sprawdza wynik; operator ręcznie promuje dokładnie to wydanie. Latest nie oznacza automatycznej promocji. Jedna ścieżka CI obsługuje promocję i rollback; warunkowy zapis current musi zostać dowiedziony na faktycznym publisherze. Nie dodajemy GC ani kanałów wydań.
Pierwsza zmiana dostarcza też podpisany format mapy migracji, który może jeszcze nie mieć wpisów. Druga dołoży sprawdzone mapowanie i lokalną operację migracji. Nie dopisujemy mapy do już opublikowanego niezmiennego wydania.
Kolejność i warunki wydania
- Naprawa tożsamości/grantów oraz autoryzacja i discovery.
- Specyfikacja treści, źródła i publisher v4 z ochroną v3.
- Wybór edycji w CLI i bezpieczeństwo zwykłych aktualizacji.
- Lokalne E2E na konkretnych kandydatach obu repo, testy kompatybilności v3, Linux/Windows i review implementacji.
- Zatrzymanie starych publisherów i snapshot v3; zabezpieczony Worker; zweryfikowane treści i ręczna promocja; próba kont; publikacja CLI.
Nie wdrożono kodu. Po fetch z 2026-09-12 mastery nadal wskazują CLI f89f195 i toolkit da989a6. Najważniejsze niezamknięte dowody: finalny cutoff v3, faktyczna zawartość programu, pełny snapshot v3 oraz warunkowa promocja przez rzeczywistą ścieżkę publikacji. Każdy ma przypisany etap w evidence.md; brak dowodu nie jest zaliczeniem kryterium.