úlet podle špatného plánu 18 hodin nostop speed 1,5x
CONTROL-ENFORCEMENT-001-R3: čistá a kriticky kontrolovaná obnova
Výchozí rozhodnutí
Současný dirty worktree zůstane beze změny jako QUARANTINED_CANDIDATE_SOURCE.
Nebude se přebírat cizí stale freeze ani předstírat jeho vlastník.
Nový čistý worktree vznikne na samostatné větvi z lokálního 65cb6d1, na který ukazuje i lokální origin/main.
Aktuální live stav GitHub remote je UNVERIFIED, protože přístup nyní selhal na chybějících credentials.
Žádný historický receipt se nepřepisuje.
...
Kritická acceptance
Každý normativní výrok musí mít stav TRUE_FINDING, FALSE_POSITIVE, UNVERIFIED nebo OUT_OF_SCOPE.
Autor nesmí být jediný reviewer své změny.
Povinné adversarial testy zahrnou konkurentní CAS, pády mezi zápisy, poškozený chain, clock jump, suspend/restart, PID reuse, stale lease, přímý zápis, změnu Git indexu, --no-verify, symlink/junction/hardlink a raw/secret v binary/archive.
Každý balík kontrolují minimálně dva nezávislí read-only kritici: kontrakt/bezpečnost a testy/provoz.
Otevřený potvrzený P0/P1 znamená BLOCKED.
PASS testů nikdy sám nevytváří vyšší enforcement úroveň ani ACCEPTED.
---------------------------
**Aktuální stav:**
implementace je technicky pokročilá, ale celý plán ještě není hotový ani `ACCEPTED`. Zůstává `REVIEW_REQUIRED`.
**Hotové / doložené**
- Čistý worktree a větev z commitu `65cb6d1`; původní dirty strom zůstal v karanténě.
- Implementované kandidátní řízení: lease, freeze, checkpoint chain, work packages, autorizované zápisy, transition/execution runner a owner session/agent.
- Uzavřeny dosavadní zdrojové P0/P1 v kontrolovaném rozsahu.
- Produkční completion cesta už není mockovaná a prochází všemi šesti režimy.
- Předchozí snapshot prošel:
- OwnerAgent `10/10`
- execution `24/24`
- PROCESS `12/12`
- FAST `184/184`
- FULL `213/213`
- compileall a diff-check bez chyby.
- Manifesty a exact SHA closure byly nezávisle ověřeny.
- Doplněna kontrola `RESULT_SEMANTICS` před čtením provenance.
**Právě se dokončuje**
- Test byl dále zpřesněn o:
- SHA a payload-hash každého ze šesti result receipts,
- důkaz čerstvých výsledků místo replaye,
- per-mode target marker.
- Na nových bytech už prošlo `10/10`, PROCESS `12/12` a FAST `184/184`.
- Aktuálně běží nový FULL gate; potom musí následovat compileall, diff-check a nové exact-byte review.
**Co ještě chybí**
1. Uzavřít nový FULL gate a nezávisle zkontrolovat poslední změněné byty.
2. Doložit spuštění skutečného canonical `ce002c_run_tests.py`; současný integrační test používá syntetický child runner. To je stále oracle/acceptance P1.
3. Vytvořit nový immutable `REVIEW_REQUIRED` successor package s konečnými SHA.
4. Vyřešit dlouho žijícího vlastníka lease. Jednorázový recovery CLI proces by okamžitě zemřel a znovu vytvořil stale lease.
5. Bezpečně invalidovat/reconcile starou lineage a vytvořit nový lease, freeze a checkpoint chain.
6. Teprve poté provést transition/execution.
7. Doložit Windows two-process, abrupt-parent, power-loss a fyzickou durability.
8. Dokončit vzdálenou GitHub ochranu a živě ověřit required checks, ruleset, force-push a admin bypass.
9. Následně provést selektivní migraci práce, acceptance, commit a push.
Nejdůležitější závěr:
**zdrojový kandidát už nevykazuje známý P0/P1, ale provozní autorita a acceptance ještě nejsou doložené.**
---------------------------
Pokud je cílem **funkční a ověřená aplikace**, nikoli vývoj obecného enforcement systému odolného proti svévolným zápisům, většinu plánu lze odložit.
**Co z plánu zachovat**
- **CE-000 částečně:** pracovat v čisté větvi/worktree z důvěryhodného commitu a původní dirty stav zachovat jako zálohu.
- Spustit baseline testy před přenosem změn.
- Přesně určit, které aplikační soubory se přenášejí.
- **CE-002 minimálně:** před commitem zkontrolovat diff, staged obsah, testy a secrets.
- **CE-004 zjednodušeně:** přenášet změny po malých funkčních balících a každý otestovat.
- Nezávislé code review pro aplikační chyby P0/P1.
- Běžné CI před merge/publikací.
**Co nyní není potřeba**
- Vlastní lease/freeze systém.
- Hashovaný checkpoint event chain a CAS pointery.
- Persistent owner-holder a recovery lineage.
- Kryptografické receipts pro každý zápis.
- Windows power-loss, PID reuse a crash-recovery matice.
- Job Object enforcement.
- GitHub admin-bypass a force-push dokazování nad rámec běžné branch protection.
- `OS_WRITE_ISOLATED`.
- Vlastní transition/execution control runtime.
Tyto mechanismy řeší důvěryhodnost řídicího systému, ne funkčnost 13F aplikace.
**Minimální cesta k funkční aplikaci**
1. Zastavit další rozšiřování control-plane kandidáta a uchovat ho jako `REVIEW_REQUIRED`.
2. Založit čistou aplikační větev z důvěryhodného commitu.
3. Přenést pouze relevantní aplikační změny z dirty stromu.
4. Implementovat jednotný exposure model pro 13F i non-13F data.
5. Zajistit, že každý relevantní accession skončí jako exposure nebo explicitní `UNKNOWN_POSITION_IMPACT`.
6. Upravit hlavní přehledy a grafy, aby non-13F exposure nebyla skrytá.
7. Doplnit NBIS regresi: `12,410,060` akcií a `5.60 %` musí být viditelné mimo samotnou 13D/13G tabulku.
8. Spustit regeneraci dat, audit, aplikační testy, HTML kontrolu a vizuální kontrolu běžící aplikace.
9. Zkontrolovat diff a secrets, vytvořit commit a projít běžným CI/code review.
**Praktický verdikt**
Pro funkční aplikaci postačuje:
`clean Git baseline → malé aplikační změny → cílené testy → širší regrese → datový audit → UI kontrola → code review → CI`
Současná control-enforcement práce je výrazně širší než tento cíl. Neměla by blokovat vývoj aplikace, pokud změny zůstanou oddělené v běžných Git větvích/worktrees a nejsou označeny jako bezpečnostně `ACCEPTED` bez odpovídajících důkazů.
----
Manager pokračoval v nadbytečném owner-holder řešení navzdory novému cíli funkční aplikace.
Doporučil jsem control-plane pozastavit jako REVIEW_REQUIRED a tým přeřadit na datový tok, NBIS/non-13F regresi a UI completeness.
--------------------------
**1. Má se plán měnit?**
Ano, ale pouze cíleně. Základní architekturu `CONTROL-ENFORCEMENT-001-R3` není potřeba nahrazovat.
**Co zůstává správně**
- Karanténa původního dirty worktree.
- Čistý successor worktree z přesně určeného commitu.
- Postup `CE-000 → CE-001 → CE-002 → CE-003 → CE-004`.
- Manager jako jediný integration/acceptance owner.
- Nezávislé read-only kontroly.
- Otevřený P0/P1 znamená `BLOCKED`.
- Test PASS není acceptance.
- Rozlišení lokální detekce, remote gate a skutečné OS izolace.
**Co je potřeba doplnit**
1. **Owner-session kontrakt do CE-002**
- Execution i transition musí ověřovat živý owner proces, přímého potomka, PID creation-time a process image.
- Produkční API nesmí přijímat volně dodaný PID nebo process identity.
- Současný transition runner stále nemá dostatečnou vazbu na skutečného volajícího. To je otevřený P1.
2. **Lease/session epoch**
- Všech šest prepublication výsledků musí patřit ke stejnému `epoch_id`, lease payloadu, bindingu a predecessor checkpointu.
- Renewal nebo expiry uprostřed epochy musí epochu ukončit a vyžádat nové výsledky.
- Tento proces dnes není normativně definovaný.
3. **Environment admission**
- Do plánu explicitně přidat immutable mapu `mode → expected_environment_sha256`.
- Producer i transition consumer musí ověřovat stejnou mapu.
- Poslední candidate implementace tuto dřívější P1 pravděpodobně uzavírá a SL1 ji staticky potvrdil, ale runtime receipts a celý gate ještě nejsou ověřené.
4. **Přesnější pojem „immutable“**
- Na lokální úrovni jde o content-addressed, canonical a tamper-detectable artefakty.
- Nejde o fyzickou neměnnost proti procesu se stejnými Windows právy. Ta vznikne až v `OS_WRITE_ISOLATED`.
5. **Neuvádět trvalé počty testů v hlavním plánu**
- Počty jako `18/18`, `25/25`, `12/12` patří do hash-bound candidate manifestu.
- Plán má vyžadovat přesný count a SHA aktuálního test-ID setu, nikoliv historické konstanty.
6. **Upřesnit recovery pořadí**
- Archivace starého lease.
- Terminální invalidace starého freeze/checkpoint lineage.
- Nový empty-allowlist bootstrap.
- Nový `STARTED`.
- Nový epoch a nové výsledky.
- Teprve potom authorization a transition.
**Verdikt**
Plán není potřeba přepracovat od začátku. Potřebuje revizi acceptance kontraktu CE-002 o owner-session, epochy, environment admission a přesnou definici lokální „immutability“. Dokud není uzavřen owner-session P1, stav zůstává `REVIEW_REQUIRED/BLOCKED`.
**2. Cíl plánu**
Cílem je vytvořit důvěryhodný proces změn, ve kterém:
- nelze tiše převzít dirty, stale nebo cizí práci;
- každý zápis má konkrétního vlastníka, bounded scope a ověřitelný původ;
- lease, freeze, checkpoint, test evidence a výsledné byty tvoří jeden kontrolovatelný řetězec;
- pád procesu, expiry, PID reuse nebo nejasný stav vede k blokaci a řízené obnově;
- žádný test, receipt ani reviewer nemůže sám vytvořit `ACCEPTED`;
- do čisté větve se přenášejí pouze malé, nezávisle prověřené balíky;
- lokální ochrana může později přejít na remote merge gates a skutečnou OS izolaci.
Nejde primárně o aplikační funkci. Je to bezpečnostní a integrační základ, který má zabránit falešně zelenému stavu a nedoloženým změnám při dalším vývoji projektu.
---------------------------------------------------------------------
Pracoval 19h 29m 53s
Windows operational balík je dokončen:
Přidán skutečný dvouprocesový hard-exit/reconciliation test.
Opraveny oba P1: strict boolean potvrzení a přesná vazba na předchozí PID/writer identity.
Nezávislé SENTlab 1/2 review: žádné zbývající P0/P1.
Runtime testy 15/15, celý OSR suite 538/538.
compileall a git diff --check: PASS.
Nový lokální commit:
Worktree je čistý.
Aktuální aplikace běží na http://127.0.0.1:8511/esu6-fop.
Správně hlásí POLICY_SETUP_REQUIRED, TCP_LISTENER_UNREACHABLE, HeatMap BLOCKED, OI 0/24.
Zbývají pouze vyšší provozní/OS limity: nezávislé potvrzení ukončení IBKR operace, orphan-event reconciliation a write-side junction/reparse containment. Offline kandidáta neblokují; ACCEPTED ani live OI/Volume tím nevzniká. Push nebyl opakován po předchozím bezpečnostním zamítnutí.
E2E test
