# Otevřené otázky po statické analýze ovladače CFL-605RT

## Rozhodnutí

`capture-required` (zúženo)

Obsah omezeného MGL proudu je staticky doložený a hloubkový rozbor uzavřel i dřívější mezery obsahu (FS/ZF → `ZF`, kvantování, jednosměrnost, stropy — viz `protocol-evidence.md` E20/E22/E38/E39). Delegace legacy monitoru neexistuje (E36). Ovladač 5.12.3 má oddělené cesty `CDeviceEtherData` (TCP/8002 → TCP/11110) a `CDeviceIDCut` (TCP/48153, `Register_Cutdata_Binary`); jejich chování se nepřenáší na legacy RAW TCP/11110.

Zbývají už jen dvě mezery **legacy** transportu, které uzavře jedině síťový záznam: přesný počet spojení a časování ukončení (Q01) a bajtová identita prvního proudu legacy cesty (Q02). Každou má uzavřít právě jedna minimální dvojice úloh proti budoucímu záznamovému TCP přijímači.

## Třídy otázek

| Třída | Význam | Otázky | Stav |
| --- | --- | --- | --- |
| A | blokuje bezpečné sestavení geometrie | Q04, Q05 | uzavřeno statickou analýzou |
| B | blokuje nastavení nástroje nebo řezných parametrů | Q06, Q07 | uzavřeno pro omezený POC statickou analýzou a explicitním profilem; spory rozsahů E20 a E22 zůstávají otevřené pro obecný profil |
| C | blokuje zahájení nebo ukončení TCP úlohy | Q01, Q02, Q03 | Q03 uzavřena; Q01 a Q02 zůstávají otevřené |
| D | neblokuje první samostatný POC řez | Q08, Q09, Q10 | zdokumentováno bez další analýzy |

## Uzavřené otázky A až C

| ID | Uzavřený závěr | Důkaz a omezení |
| --- | --- | --- |
| Q03 | Běžná větev `MODEL=11` končí `PUSP0;` a flush. | `MMKPLT.dll` SHA-256 `611da823f97b5f83afa94c28e8b705c61b7cce44d72ab14478a077e0c1029712`, `DrvSendPage` `0x6a909a9c`; platí bez rozšířeného posunu a podávání stránky. |
| Q04 | Pohyb bez řezu je `PU` + `PAx,y`; pohyb s řezem je `PD` + `PAx,y`. | Stejný modul, `0x6a911f38`, řetězce na `0x6a901c44`, `0x6a901c4c` a `0x6a901c50`. |
| Q05 | Bez rotace vede přímá soustava vlevo dole na kladné X doprava a Y nahoru; jednotka je explicitně 0,025 nebo 0,010 mm. | Stejný modul, `0x6a911f38`; S01 a S02. Host musí sám určit pravidlo kvantování. |
| Q06 | `SPn` vybírá panelově přiřazený slot 1 až 6. | Stejný modul, `0x6a9143b4`; S01. Obsluha musí potvrdit aktuální `PEN ASSIGN`. |
| Q07 | Profil řetězí `SP`, volitelně `VS`, `FS`/`ZF` a `ZO`; nula příkaz vynechá. | Stejný modul, `0x6a9143b4` a `0x6a914264`. POC používá celočíselnou rychlost 1 až 30 cm/s a tlak podle nástroje. |

## Blokující Q01 — životní cyklus systémového RAW TCP

**Co je známé:** S02 ručně volí systémový Standard TCP/IP Port Monitor, RAW a port 11110. Vlastní `MPMSERV_1.dll` má `OpenPortEx=NULL`, zapisuje do lokálního handle a síťovou cestu nerealizuje **ani nedeleguje** (žádný Winsock, žádný `LoadLibrary`/`GetProcAddress`, všech 194 nepřímých volání do vlastní IAT — E36). Aktuální ovladač 5.12.3 používá jiné app-vrstvové cesty; neudává počet spojení legacy RAW úlohy.

**Co chybí:** počet TCP spojení na spoolovací úlohu, případné opakované použití socketu, přiřazení posledního payloadu k úloze a okamžik FIN nebo RST.

**Jediná minimální dvojice úloh:**

- **A:** odeslat přes původní Windows cestu do záznamového přijímače jednu úlohu s jediným čtvercem 10 × 10 mm, jedním průchodem a pevným profilem;
- **B:** odeslat dvě bezprostředně po sobě jdoucí spoolovací úlohy se stejným čtvercem a stejným profilem.

Přijímač porovná počet přijatých spojení, první a poslední bajt každé úlohy a časování FIN/RST. Žádný jiný parametr se mezi A a B nemění.

## Blokující Q02 — handshake a první síťový bajt

**Co je známé:** Spoolovací payload začíná `IN;`. Vlastní `MPMSERV_1.dll` před zápisem nečte a data nemění. Tento modul však neobsluhuje systémový Standard TCP/IP Port Monitor. Ovladač 5.12.3 balí data do `Register_Cutdata_Binary`, ne do surového MGL. Z těchto důkazů nelze určit předehru legacy RAW proudu.

**Co chybí:** bajty před `IN;`, případné čtení nebo odpověď před prvním zápisem a hranice společné preambule.

**Jediná minimální dvojice úloh:**

- **A — tichý server:** server přijme spojení, neodešle žádný bajt ani FIN/RST, průběžně čte klientská data a ponechá oba směry spojení otevřené nejméně 35 s od `accept`;
- **B — kontrolní EOF:** server přijme spojení a okamžitě zavolá `shutdown(SHUT_WR)`. Neodešle žádný aplikační bajt, dál čte klientská data a ponechá čtecí směr otevřený nejméně 35 s od `accept`.

Oba běhy musí použít tentýž neměnný RAW payload s jedním čtvercem 10 × 10 mm, jedním průchodem, jednotkou 0,025 mm a stejným profilem včetně `SP`. Příprava testu musí před oběma běhy zaznamenat jeho délku a SHA-256. Jedinou proměnnou je serverové `shutdown(SHUT_WR)` v běhu B.

Hodnota 35 s je observační deadline pro první klientský bajt. Vychází z nejvyššího dokumentovaného `CLOSE TIME` stroje 30 s a pětisekundové rezervy. Nejde o známý ani odvozený timeout Windows. Server po přijetí prvního bajtu zaznamená monotónní čas od `accept`, celý klientský stream, jeho délku a SHA-256 a události FIN/RST. Běh B používá TCP EOF pouze jako kontrolní reakci; neháda žádný proprietární opkód ani odpověď plotru.

Mock server nevidí interní volání `recv` klienta. Absence provozu do deadline proto nedokazuje, že klient nic nečetl. Určuje pouze níže uvedenou rozhodovací hranici.

V tabulce značí `b_X` první klientský bajt, `t_X` monotónní čas od `accept`, `S_X` celý klientský stream, `L_X` jeho délku a `H_X` jeho SHA-256 pro běh X.

| První bajt a čas A | První bajt a čas B | Identita streamu A/B | Závěr |
| --- | --- | --- | --- |
| `b_A=0x49` (`I`), `t_A≤35 s`, prefix `IN;` | `b_B=0x49` (`I`), `t_B≤35 s`, prefix `IN;` | `S_A=S_B`; záznam potvrzuje také `L_A=L_B` a `H_A=H_B` | Q02 je pro omezený POC uzavřená: před payloadem není povinná aplikační odpověď serveru a první klientský stream začíná `IN;`. |
| `b_A=0x49`, `t_A≤35 s`, prefix `IN;` | `b_B=0x49`, `t_B≤35 s`, prefix `IN;` | `S_A≠S_B`, bez ohledu na délku nebo hash | Q02 zůstává blokující. EOF změnil cestu za prvním prefixem. Dalším nejmenším důkazem je skutečný síťový záznam s konkrétní odpovědí zařízení. |
| `b_A` dorazí v `t_A≤35 s` | `b_B` dorazí v `t_B≤35 s` | Nejméně jeden z proudů `S_A`, `S_B` nezačíná `IN;`; zaznamenají se `L_A`, `L_B`, `H_A` a `H_B` | Q02 zůstává blokující. Pozorovaný prefix nelze bez skutečného záznamu připsat handshake ani payloadu. |
| `b_A=∅`; žádné `t_A` do 35 s | `b_B` dorazí po kontrolním EOF v `t_B≤35 s` | `S_A=∅`; `L_B` a `H_B` jsou libovolné | Q02 zůstává blokující. Klient reaguje na EOF, ale skutečná očekávaná odpověď není známá. Dalším nejmenším důkazem je skutečný záznam nebo doložená konkrétní odpověď. |
| `b_A` dorazí v `t_A≤35 s` | `b_B=∅`; žádné `t_B` do 35 s nebo se klient odpojí před daty | `S_B=∅` nebo `S_A≠S_B` | Q02 zůstává blokující. Kontrolní EOF změnil chování klienta; tichý běh sám nestačí k potvrzení stabilní transportní cesty. |
| `b_A=∅`; žádné `t_A` do 35 s, klient může čekat nebo se odpojit | `b_B=∅`; žádné `t_B` do 35 s, klient může čekat nebo se odpojit | `S_A=S_B=∅` | Q02 zůstává blokující. Výsledek nedokazuje absenci interního čtení ani timeout Windows. Dalším nejmenším důkazem je skutečný síťový záznam. |
| Běh A nemá úspěšný `accept` nebo skončí chybou infrastruktury; `b_A` a `t_A` nejsou hodnotitelné | Libovolný výsledek; totéž platí symetricky pro chybu B | Nehodnotitelné | Dvojice je neplatná a Q02 se nemění; nejprve se opraví testovací prostředí bez změny payloadu nebo serverové varianty. |

První bajt přijatý až po 35 s se pro rozhodnutí počítá jako nedoručený v deadline. Server jej přesto zaznamená s časem, ale Q02 zůstane otevřená.

## Neblokující třída D

| ID | Otevřená otázka | Omezení prvního POC |
| --- | --- | --- |
| Q08 | Hostitelská realizace více průchodů a řazení kontur. | Host pošle každou konturu jednou; panelové `SORTING=OFF`. |
| Q09 | Odpovědi zařízení, `OH`, SNMP a chybové rámce systémové RAW cesty. | POC neposílá dotaz a nesmí čekat na stavovou odpověď. Vlastní `ReadPort` vrací nula bajtů, což systémovou cestu nedokládá. |
| Q10 | Hostitelské spuštění detekce registračních značek. | První POC je samostatný řez bez značek. |

Po uzavření Q01 a Q02 lze navrhnout jediný omezený encoder a odesílatel. Tato etapa nevytváří přijímač, encoder ani síťový mock.