Ocena autonomii Koru ↔ Subactor ask — raport 2026-07-18

Data: 2026-07-18 Zakres: (A) weryfikacja publikacji domen przez subactor ask bez redeploy; (B) ocena implementacji Koru względem wytycznych „Werdykt” (transakcyjny workspace, bezpieczeństwo dirty tree, manifest, retry, promotion). Repozytoria: /home/tom/github/subactor, /home/tom/github/semcod/koru Metoda: inspekcja kodu + lekka weryfikacja filesystem (bez live apply / bez cutover DNS).

2. Werdykt skrótowy

Subactor ask działa jako founder CLI z poprawną ścieżką symlinku; pełny apply produkcyjny wymaga --execute --apply --yes, a zmiany step-catalog.json wymagają restartu hr-control. Publikacje logo, www i docs-stage na origin Plesk (200 przez curl --resolve) są potwierdzone; docs.subactor.com celowo bez apply. Koru częściowo spełnia wytyczne transakcyjnego patchowania: worktree, seed dirty, manifest drift, retry (max 1) i kody PatchOutcome są zaimplementowane w warstwie queue, ale ADR-005 pozostaje „Proposed”, promotion_mode=commit nie commituje po apply, a manifest nie jest trwale wiązany z każdym runem jak Subactor plan_hash. Most development_defect Subactor→Koru jest gotowy; Koru nie powinien dotykać Plesk/DNS — tylko naprawiać kod po błędach strukturalnych z ask.

3. Raport: subactor ask / publikacje domen (Part A)

3.1 CLI i środowisko

3.2 Semantyka flag ask

• --execute — approve planu + dry-run orchestratora; nie wykonuje apply produkcyjnego w trybie nieinteraktywnym.
• --apply — implikuje --execute oraz osobną autoryzację produkcji (grant + lease); wymagane razem z --yes / --non-interactive poza TTY.
• --execute --yes bez --apply — kończy na dry-run; apply pomijany (log: „apply pominięty decyzją użytkownika”).

Implementacja: platform/bin/subactor (cmd_ask, linie ~354–563).

3.3 step-catalog i hr-control

Po edycji platform/config/step-catalog.json usługa hr-control trzyma katalog kroków w pamięci. Wymagany restart:

cd /home/tom/github/subactor/platform
docker compose restart hr-control

Lekcja (logo): pierwszy apply logo trafił na /httpdocs zamiast /logo.subactor.com przez stale in-memory step-catalog; po restarcie hr-control pack logo-httpdocs-publish wiąże remote_path=/logo.subactor.com (intent pack, nie /httpdocs).

3.4 Intent packi — remote_path

Subdomena logo utworzona w Plesk; docroot ≠ /httpdocs.

3.5 Tabela wyników (2026-07-18)

DNS/Cloudflare: brak cutover dla logo (możliwy nadal GitHub Pages publicznie); testy origin używają --resolve na 217.160.250.222.

3.6 Działające komendy (lab, bez ponownego apply)

# Ścieżka CLI
readlink -f ~/.local/bin/subactor
cd /home/tom/github/subactor

# Dry-run (bez apply)
subactor ask "opublikuj logo na logo.subactor.com" --execute --yes

# Pełny łańcuch: dry-run → grant → apply (nieinteraktywnie)
subactor ask "opublikuj logo na logo.subactor.com" --execute --apply --yes

# Po zmianie step-catalog
cd platform && docker compose restart hr-control

# Origin probe (logo, bez publicznego DNS)
curl -k -sS -o /dev/null -w '%{http_code}\n' \
  --resolve logo.subactor.com:443:217.160.250.222 \
  https://logo.subactor.com/

# www / docs-stage (publiczne lub origin wg stanu DNS)
curl -sS -o /dev/null -w '%{http_code}\n' https://subactor.com/
curl -sS -o /dev/null -w '%{http_code}\n' https://docs-stage.subactor.com/

3.7 Lekcje operacyjne

1. Trzy bramki apply: --apply, signed grant (plan_hash + jti), env kill switches (AUTONOMY_MUTATIONS_ENABLED, PLESK_SYNC_APPLY).
2. Pack SSOT ≠ runtime cache — restart hr-control po sync step-catalog.
3. Logo ≠ httpdocs — osobny docroot subdomeny; błąd ścieżki = błąd konfiguracji, nie transportu.
4. docs.subactor.com — świadomie poza apply (PR9 / DNS HITL); staging na docs-stage.

4. Ocena Koru względem założeń (checklist)

Legenda: ✅ spełnione · ⚠️ częściowo · ❌ brak / niezgodne

Przepływ patch (skrót)

LLM stdout → extract_unified_diff (diff_repair)
  → [artifact?] zapis .koru/runs/
  → [worktree?] staging_worktree + seed dirty files
  → baseline verify → git apply --check → apply → verify
  → [branch?] commit_worktree na koru/run-<id>
  → [apply?] manifest_drift → git apply na main checkout
  → cleanup worktree (finally)
Retry (≤1): patch_retry.apply_patch_with_retry → manifest pin → build_retry_prompt

5. Czy wskazówki z Werdyktu są nadal aktualne?

Status: częściowo aktualne, częściowo zrealizowane w kodzie, częściowo superseded przez dokument planu.

Wniosek: Werdykt nie jest przestarzały jako lista P0 bezpieczeństwa, ale implementacja queue wyprzedziła status ADR. Kolejne PR-y powinny: Accept ADR-005, trwały manifest, dokończyć commit, spiąć z Subactor development_defect.

6. Synergia Koru ↔ Subactor ask

Jak powinno działać (docelowe)

subactor ask "…" [--execute [--apply --yes]]
  → intent pack + AQL + dry-run + plan_hash
  → [apply] grant + verify origin
  → błąd strukturalny (invalid_runner_response, plan_hash_mismatch jako bug, capability_unimplemented w kodzie)
      → development_defect (fingerprint dedupe)
      → kolejka Koru `development`
      → Koru patch_mode (worktree, 1–2 pliki, regression test)
      → subactor-improvement resolve → resume PLF-xxx (dry-run + grant + Y/n)
  → błąd operacyjny (dns_mismatch, apply_grant_*, credential_*)
      → HITL, NIE kolejka development

Co już jest

• Klasyfikacja: orchestrator/src/development-defect.mjs (STRUCTURAL_DEFECT_CODES vs OPERATIONAL_BOUNDARY_CODES).
• EQL bridge: eql/src/integrations/koru/failure-bridge.ts.
• Koru config: subactor/docs/koru.yaml — queue development, jawny zakaz prod mutation.
• CLI hook: record_improvement_failure w platform/bin/subactor.

Czego brakuje pod subactor ask

1. Automatyczny fingerprint dla typowych awarii ask (np. stale step-catalog → ticket na platform/config/step-catalog.json + test sync).
2. Korelacja plan_hash ↔ Koru manifest_hash w evidence development ticket.
3. Szablon ticketu „repair ask capability plan” z acceptance_tests wskazującymi na subactor ask "…" --execute --yes (dry-run green).
4. Zero coupling Koru → Plesk URI / SFTP — tylko kod subactor/orchestrator/connectors.

Koru może wspierać użytkownika ask, o ile ogranicza się do naprawy planów i kodu, nie do „wolnego deployu”.

7. Rekomendowana kolejność prac (P0 / P1 / P2)

P0 — wspólny bezpieczeństwo i spójność

P1 — pilot użytkownika ask

P2 — dojrzałość architektury

8. Świadomie poza zakresem

• Publiczny DNS cutover (logo, docs.prod) i Cloudflare.
• Live apply przez ten raport (brak redeploy / brak subactor ask --apply).
• Koru bezpośrednio na Plesk (SFTP, sync, grant bypass).
• Szeroki refactor autonomous.py / vdisplay hotspot w jednym tickecie.
• Commit tego raportu do git (dokument lokalny unless requested).

Załącznik: pliki kluczowe