Gill & Murry A4 ajánlat — tech spec áttekintés

Master summary — the gist in 30 seconds

TL;DRKész a terv, ami alapján egy új chat (Instance 3) megépíti a július 9-én kiküldendő A4-es magyar ajánlatot: checklist.md + 2 döntési napló + egy QA-skill, ami ellenőrzi a kész dokumentumot.

Bemenet: a lezárt szándék (HANDOFF) + a képernyő-tartalmi spec. Kimenet: egy végrehajtható munkalista (17 pipálandó pont), a csomag-/óraszámítás döntése, és egy Playwright-alapú ellenőrző, ami a kész HTML-t vizsgálja. Az építést NEM most csináltuk meg — azt a következő chat végzi a PROMPT_to_execute.md alapján.

Why this mattersA dokumentum egy jelentős beruházásra tett ajánlat: a hitelessége azon múlik, hogy az árak és órák nyilvánosan összeadódjanak, minden képernyő látsszon, és a július 31-i vállalás konkrét legyen. A checklist ezt gépiesen ellenőrizhetővé teszi, nem érzésre.

flowchart LR
  H[HANDOFF + tartalmi spec] --> C[checklist.md<br/>17 pont]
  H --> A[ADR 0001-0002<br/>döntések]
  C --> Q[gm-proposal-qa<br/>ellenőrző skill]
  C --> P[PROMPT_to_execute.md]
  P --> E[Instance 3<br/>megépíti az A4 HTML-t]
  Q --> E

1 · A fő döntés — 3 csomag, ami kijön az órákból

TL;DRGazdaságos 39ó=700e Ft · Ajánlott 50ó=900e Ft · Teljes 61ó=1,1M Ft — mind a közös core köré, 18 000 Ft/óra.

Egy őszinte óra-készlet, ami csomagonként pontosan az árra jön ki. A core (jelentkezés, PDF-motor, admin, kupon, e-aláírás, FAR-Excel, konverziómérés) minden szintben ott van; az Ajánlott +11 óra extrát ad (adószám-autofill, szerződés-előnézet, admin műszerfal, .ics, aláírás-emlékeztetők); a Teljes +11 órát (ügyfélkapu + videótár). Az értékelő aloldal külön óradíjas.

Why it mattersA HANDOFF fixálta az árakat, de nem az órabontást. A tét: NE látszódjon két ellentmondó összeg. A belső ~118 órás becslést tudatosan felülírja az AI-gyorsított, hatékonyságra árazott bontás — így az ügyfél saját kezűleg leellenőrizheti a matekot.

flowchart TB
  core[CORE 39ó = 700e Ft] --> aj[+11ó extra = 50ó / 900e Ft]
  aj --> tel[+11ó ügyfélkapu+videótár = 61ó / 1,1M Ft]
  ext[Értékelő aloldal 6-8ó<br/>külön óradíjas]

2 · Egy fontos felülírás — e-Szignó egyoldali aláírás

TL;DRA régi tartalmi spec Yousign/videós-regisztrációt mutat; a július 8-i megbeszélés ezt felülírta: csak Patrik ír alá digitálisan.

A kész folyamat: az e-Szignóval CSAK a G&M oldal ír alá, az aláírt PDF e-mailben megy a jelentkezőhöz, aki vagy digitálisan visszaír, vagy kinyomtatja/aláírja/szkenneli és a szerzodes@ címre küldi. A Yousign csak megnevezett tartalék. Az AES + időbélyeg jogilag elegendő (nem kell minősített aláírás).

Why it mattersHa az építő a régi specet követné, egy súrlódásos, minden aláírónak app-telepítést és videós azonosítást igénylő flow-t rajzolna — pont amit az ügyfél ügyvédje elvetett. A checklist J4 pontja explicit védi ezt.

flowchart LR
  P[Patrik e-Szignóval aláír] --> M[aláírt PDF e-mailben]
  M --> D{jelentkező}
  D -->|digitálisan| R[visszaír]
  D -->|papíron| S[nyomtat/szkennel<br/>szerzodes@]

3 · A checklist — 17 pont, 5 fürtben

TL;DRNyomtatás+nyelv (P) · nyitó (O) · drótvázak J1–J5 · árazás (PR) · garanciák/ütemezés (G) + prózaaudit (X1).

Minden pont: mit kell a kész doknak mutatnia + a forrás (melyik spec-szakasz) + hogyan ellenőrizzük (DOM-állítás + a QA-skill futtatása). Az építés fürtönként megy: megírod a képernyőket → egy render → a QA piros→zöldre vált → pipa.

Why it mattersStatikus dokumentumnál könnyű 'kész'-t mondani érzésre. A pontonkénti, gépiesen ellenőrizhető állítás megakadályozza a kihagyott képernyőt, a hibás árat vagy a bekúszó angol/matrica-maradványt.

flowchart TB
  P[P1-P3 A4+nyelv] --> O[O1-O2 nyitó]
  O --> J[J1-J5 drótvázak]
  J --> PR[PR1-PR3 árazás]
  PR --> G[G1-G3 garancia/ütem]
  G --> X[X1 prózaaudit]

4 · A QA-skill — a kész HTML-t vizsgálja, nem élő appot

TL;DRgm-proposal-qa: Playwright betölti az A4 HTML-t file:// URL-ről és pontonként ellenőrzi a teljességet + a nyomtatás-biztonságot + a matekot.

Nincs bejelentkezés, nincs adatbázis, nincs 'sentinel'-védelem — ezt a chain alap QA-motorjából tudatosan kivágtuk (ADR 0002), mert egy statikus fájlnál nincs mit védeni. A skill a szekciók meglétét, a 700e/900e/1,1M árakat, az órák összegét (39/50/61) és az ármátrix egyezését gépiesen ellenőrzi.

Why it mattersA böngészős vizuális QA (browser-qa-runner) a szépséget nézi, de nem adja össze az órákat. A load-bearing matek (óra × 18 000 = ár) gépi ellenőrzést kap, nem szemmértéket.

flowchart LR
  F[ajanlat.html file://] --> Q[gm-proposal-qa assert --check ID]
  Q --> R{PASS?}
  R -->|piros| Fix[javít + újrarender]
  R -->|zöld| T[pipa + Run log]

5 · Következő lépés — új chat építi meg

TL;DRNyiss egy ÚJ Claude Code chatet és illeszd be a plans/gm-proposal-a4/PROMPT_to_execute.md tartalmát.

Az Instance 3 először az execute_context.json-t olvassa, majd a checklist.md-t, és fürtről fürtre megépíti a docs/proposal-drafts/ajanlat-2026-07-09.html-t, minden pontot a QA-skillel zöldre hajtva. Két nyitott elem tudatosan halasztott (e-Szignó API-ár a Microsectől, FAR pontos oszlopok) — ezeket a doksi szövegesen kezeli, nem blokkolják az építést.

Why it mattersA friss kontextus olcsóbb és tisztább: az építő chat nem cipeli a tervezés zaját, csak a végrehajtható bundle-t. A HANDOFF/checklist a szerződés az instance-ok között, nem a chat-előzmény.

flowchart LR
  U[te: új chat] --> PR[PROMPT_to_execute.md]
  PR --> EC[execute_context.json]
  EC --> CL[checklist.md]
  CL --> HTML[ajanlat-2026-07-09.html]