Kertújítók · LLL contract

Verification and Constraints

READY FOR REVIEW

Excel-first proposals inside the existing client portal

Revision 127 September 20260 / 21 implementation criteria verified

Contract prepared. No redesign executor has been created, queued or launched. The earlier compact-header CSS is a local unpublished draft only.

Goal and finish line

End goal: Let Péter work in his familiar Excel-style table inside the existing client portal while edits save automatically and update a clear, branded PDF beside it.

Done means: One B-based proposal editor uses the existing portal header and hamburger, gives the spreadsheet most of the screen, keeps all proposal and settlement entry in the grid, saves edits automatically, and shows yellow cell-to-PDF impact highlights. The selected tabbed customer panel works across the existing portal. Every new PDF page uses the same smaller logo and green branding. Verified staging links, preserved data and rollback evidence accompany the result.

0 / 21criteria verified

6deliverables

Reviewcurrent step

Rules that stay fixed

Preserve source workbook/business meaning, current records, archived PDFs and live calendar work.
All proposal and settlement data entry stays in the table. No new product hierarchy or workflow.
No new access gate. Bare URLs with non-sensitive review content and existing isolated synthetic staging only.

Selected B proposal interface · Chosen tabbed-panel reference

Proof standard: Every GUI criterion requires an actual screenshot after its named test on the changed deployed interface, a fresh independent gpt-6-luna high description receiving the image without the expected result, and the executor’s comparison. Attach all three beside the criterion. GUI images supplement persistence, timing, arithmetic, PDF-byte and provider proof. Missing evidence stays unchecked. Use the required Luna section QA skill for changed deployed app surfaces, with genuine gpt-6-luna xhigh desktop/mobile workers and fresh verification after any repairs.

Keep the function, simplify the interface

The original workbook already contains settlement columns and paid/debt totals. The separate web accordions are unnecessary. Dated payments and requested amounts remain useful, with input moved into the grid.

Decision	Element	Reason
Keep	Quote, Pótmunka and settlement arithmetic	These belong together in the original Excel layout.
Keep, move into the table	Requested amounts and dated payments	Proposed retention based on historical Q10 and settlement acceptance: keep requested/received amounts and dated payment history in table-native cells, retire duplicate accordions. This placement is not a newly confirmed user choice.
Keep	Live PDF and yellow affected-region highlights	Explicitly retained by Matt.
Replace	Manual Save and tall dirty-state strip	Automatic server persistence with a compact truthful status.
Remove	Demo pages, test banner, collapse button and duplicate panels	No separate design playground in the working portal. Close remains.
Simplify	Summary, editor header and PDF controls	Keep useful amounts and export choices while giving the table its space back.
Apply globally	Tabbed customer panel	Latest specific annotation chooses the tabbed layout. The standalone demos are retired.

End goal system

Confirmed requirementProposed definitionPending step

Green describes the agreed target, not completed implementation.

flowchart TD P["Existing client portal
Same header and hamburger"]:::confirmed --> T["Excel-style table
Proposal and settlement input"]:::confirmed P --> C["Tabbed customer panel
Shared across portal views"]:::confirmed T --> S["Automatic saving
Saved after server receipt"]:::confirmed C --> S T --> V["Live PDF preview
Small logo, green branding"]:::confirmed T -. Hover or focus .-> H["Yellow impact highlights
Show changed text and totals"]:::confirmed H --> V V --> X["Explicit PDF download
Keep previous PDF versions"]:::confirmed S -. Network or conflicting edit .-> R["Recover the edit
Keep input, show the issue"]:::confirmed classDef confirmed fill:#E8F5E9,stroke:#2E7D32,color:#173B25 classDef assumption fill:#FCE4EC,stroke:#C2185B,color:#5B1430 classDef open fill:#FFFFFF,stroke:#94A3B8,color:#475569,stroke-dasharray:5 5

Route to the end state

flowchart LR E["Original Excel
Verified source"]:::confirmed --> RV["Review contract
Confirm the goal"]:::open B["B and portal
Working base"]:::confirmed --> RV RV --> L["Later Launch
Sol Medium"]:::open L --> I["Integrate
Grid and panel"]:::open I --> Q["Verify
Edits and PDFs"]:::open Q -->|Pass| D["Staging ready
Proof and URLs"]:::open Q -->|Mismatch| F["Fix and retest
Repeat the proof"]:::open F --> Q classDef confirmed fill:#E8F5E9,stroke:#2E7D32,color:#173B25 classDef assumption fill:#FCE4EC,stroke:#C2185B,color:#5B1430 classDef open fill:#FFFFFF,stroke:#94A3B8,color:#475569,stroke-dasharray:5 5

Confirmed, proposed and open

Confirmed

Variant B is the proposal basis. Existing portal header and hamburger must be reused.
The original Excel is the main visual and interaction authority. Quote and settlements stay together.
Real-time edits, durable autosave and yellow PDF impact highlighting are required.
The latest specific annotation selects the tabbed customer panel globally. Standalone prototypes are unnecessary.
Original workbook A1:P37 and SHA256 have been verified directly. Separate web settlement panels are an implementation choice, not source structure.

Proposed definitions

Global rollout covers every contact-panel entrypoint in the existing Cloudflare staging portal. Production promotion is a separate later release, preserving the prior boundary.
Compact screen geometry intentionally adapts the workbook’s tall print rows and font sizes while preserving its logical grid and familiar styling. The viewport, visibility, readable-text, toolbar-height and latency numbers below are proposed acceptance limits, not verbatim user numbers or proven fit.
Keep dated payments, requested-versus-received distinction, draft/final exports and historical PDF integrity. Simplify their UI instead of deleting useful accepted behavior.

Review and discovery

Proposed default fit at 1251×1174 and 1440×900: all original columns, at least 34 of 37 source rows including every nonblank business row and bottom paid/debt totals, table at least 65% of workspace width, text≥11px and adjacent PDF≥260px. Compact print-to-screen geometry must be documented. Coexistence is not yet verified: a measured failed fit remains unchecked with the exact tradeoff, never silently relaxed.
A and B currently have different calendar revisions. Refresh provider/source readback and coordinate the latest integration at Launch. This is an execution discovery step, not an extra approval request.

Work and proof

Open each deliverable for acceptance tests

Unify the client portal

Make proposals and customer details feel like one familiar portal.

0 / 3

Criteria, constraints and evidence

D1.1. When Ajánlatok is opened through the existing portal hamburger and through a direct saved proposal URL, then the same portal header/menu and correct active destination appear in the proposal list and editor, with working return navigation.

Required proof

Desktop/mobile route journey and screenshots of portal, menu, list and editor. Compare to the existing shell.

Actual deployed screenshot: pending
Independent Luna High image description: pending
Executor comparison with this criterion: pending

UNVERIFIED · evidence has not been produced.

D1.2. When the same synthetic contact is opened from new leads, pipeline, calendar, archive, the proposal list and the proposal editor, then the chosen Kapcsolat / Jegyzet / Dátumok tabbed panel appears with the same saved values in all six entrypoints.

Required proof

Six entrypoint journeys, tab screenshots and server readback for each field group. Restore/archive only test-owned records.

Actual deployed screenshot: pending
Independent Luna High image description: pending
Executor comparison with this criterion: pending

UNVERIFIED · evidence has not been produced.

D1.3. When a contact panel is opened and closed at desktop and 390px mobile widths, then Bezárás returns space to the underlying view, the background remains usable while open, and no Összecsukás/Kibontás control or standalone design-demo navigation appears.

Required proof

Open/close screenshots, keyboard focus and background-interaction checks. The two old demo URLs redirect to the real portal contact/proposal entry instead of a demo.

Actual deployed screenshot: pending
Independent Luna High image description: pending
Executor comparison with this criterion: pending

UNVERIFIED · evidence has not been produced.

Constraints

Use the existing portal header, hamburger, logo and navigation behavior. Do not invent a separate application shell or new portal product.
Preserve existing CRM/calendar fields, original enquiry, own note, reminders, work-period dates, calendar visibility, archive behavior, source metadata and linked-proposal identity.
The tabbed prototype supplies layout only. The deployed panel must use actual shared CRM persistence. Retire demo navigation/routes without deleting saved customer data.

Restore the Excel working surface

Péter enters proposal and settlement data in one familiar grid.

0 / 4

Criteria, constraints and evidence

D2.1. When the verified original workbook fixture is opened in the B-based editor, then its quote columns A:H, three settlement pairs K:P, Pótmunka section and paid/debt totals appear in the source order and familiar grid styling, with every source row/column accounted for in a comparison artifact. Every material difference must be resolved or identified as the explicit compact screen adaptation, with no unexplained logical/business difference.

Required proof

Source workbook hash and cell/style map, original reference render, actual editor screenshot and side-by-side differences. Any intentional extension is labelled in the comparison. Include a compact source-row/column mapping and disposition of every difference. The ambiguous source M5 180,000 Ft stays unmapped, is not treated as a payment and is not copied into new proposals.

Actual deployed screenshot: pending
Independent Luna High image description: pending
Executor comparison with this criterion: pending

UNVERIFIED · evidence has not been produced.

D2.2. When that fixture is opened at 1251×1174 and 1440×900 CSS pixels at 100% browser zoom, then the default table occupies at least 65% of workspace width, all A:P columns and at least 34 of 37 source rows are visible at once, including every nonblank business row, Pótmunka and paid/debt totals. An adjacent PDF preview of at least 260px remains visible and table text is at least 11px. Only blank spacer rows may be compacted out of the row count; no business content is hidden or cropped to pass.

Required proof

Actual viewport screenshots and measured table/workspace rectangles, source-row coverage, font sizes and PDF width, plus source-to-screen comparison for readable labels, values and wrapping. Compact geometry may reduce print whitespace, not omit required content. These proposed near-full-fit limits are not verified feasibility claims. Failure remains unchecked with measured tradeoff; no silent waiver or additional design-approval phase.

Actual deployed screenshot: pending
Independent Luna High image description: pending
Executor comparison with this criterion: pending

UNVERIFIED · evidence has not been produced.

D2.3. When quantity, labor rate, transport, material rate, one extra-work row, a fourth/fifth settlement, a requested amount and two dated payments are edited, then each edit is made through the table, resulting totals appear there, and no settlement accordion or separate settlement editor is needed.

Required proof

Actual table-input journey, screenshots after each meaningful state and model/API checks. Payment dates/amounts and any already-existing notes remain accessible in the grid. Stage4/5 preservation is grounded in historical C14, not new scope.

Actual deployed screenshot: pending
Independent Luna High image description: pending
Executor comparison with this criterion: pending

UNVERIFIED · evidence has not been produced.

D2.4. When Tab, Shift+Tab, Enter, arrow navigation where applicable and multi-cell paste are used on a small two-row numeric range, then cell focus/editing follows the familiar spreadsheet flow, supported paste lands in the intended cells, and totals update without corrupting adjacent text or formulas.

Required proof

Keyboard/paste interaction recording, resulting grid screenshot and exact saved values. Preserve read-only calculated cells and Hungarian numeric input.

Actual deployed screenshot: pending
Independent Luna High image description: pending
Executor comparison with this criterion: pending

UNVERIFIED · evidence has not been produced.

Constraints

Use the actual Munka1 A1:P37 workbook and original visual reference, not the current distorted web grid as the authority. Preserve column relationships, grouping, terms, Pótmunka and calculation meaning. Preserve logical order, labels, groupings, formulas and familiar styling, while explicitly adapting print-oriented row heights and font sizes to compact screen geometry. This is not literal pixel parity.
Keep all proposal/settlement input in table cells. Remove separate settlement accordions and duplicate forms. Keep requested versus received amounts and dated-payment history through compact table-native rows/cells. Preserve existing payment notes if present, but do not add a new required note field. The retained dated-payment UI is a proposal grounded in historical Q10.
Do not hide required columns/rows or reduce text to unreadable size to claim a fit. No Excel/Sheets embed, external spreadsheet dependency, project hierarchy, invoicing or added business workflow.

Save edits as they happen

Typing updates durable data and the PDF without a manual-save routine.

0 / 4

Criteria, constraints and evidence

D3.1. When five ordinary proposal edits and no-Save edits in each editable shared customer-panel field group are made on a healthy connection, then proposal-relevant table/PDF content reflects the latest input within one second and each change reaches server-confirmed Mentve within two seconds. Contact details, original enquiry, own note, reminders, work dates and calendar visibility survive panel/tab or contact switching and a fresh session. Internal CRM notes remain absent from customer PDF preview and exports.

Required proof

Repeat each edit class three times, record every preview/ack latency on a documented online, unthrottled test connection, and attach exact API readback plus fresh-session screenshots. Use a distinctive internal-note sentinel and assert absence in extracted preview/download PDF text. Timing applies to editable supported fields, not a fabricated edit to read-only metadata; failures remain visible rather than averaged away.

Actual deployed screenshot: pending
Independent Luna High image description: pending
Executor comparison with this criterion: pending

UNVERIFIED · evidence has not been produced.

D3.2. When typing continues during a delayed save, a different proposal/contact is opened, and the first record is reopened, then the latest edits appear under the correct record and neither save response overwrites later typing or the other record.

Required proof

Controlled delayed-response test, server readback for both record IDs and reopened screenshots.

Actual deployed screenshot: pending
Independent Luna High image description: pending
Executor comparison with this criterion: pending

UNVERIFIED · evidence has not been produced.

D3.3. When the network drops during an edit and the page is reloaded, then the unsynced value remains recoverable with a compact accurate pending/error state. When connectivity returns, then saving resumes and the acknowledged value appears after another fresh reload.

Required proof

Offline/reload/reconnect test with server readback and screenshots for pending and saved states. No data loss or false Mentve.

Actual deployed screenshot: pending
Independent Luna High image description: pending
Executor comparison with this criterion: pending

UNVERIFIED · evidence has not been produced.

D3.4. When two sessions change different fields, then both changes survive. When they change the same field or an invalid value is typed, then the affected cell or compact recovery control exposes the conflict/error and preserves both relevant values without a silent overwrite. When the user chooses a conflict resolution and corrects invalid input through the affected cell or compact recovery control, then the chosen valid value is acknowledged and survives a fresh session, with the earlier typed value recoverable until resolved and no silent blank-to-zero conversion.

Required proof

Two-session conflict and invalid-input tests, field-level comparison/readback and actual recovery screenshots. Normal use must not require clicking a Save button. Exercise an actual choose/retry/correct path and verify resolved values through a new session and server readback.

Actual deployed screenshot: pending
Independent Luna High image description: pending
Executor comparison with this criterion: pending

UNVERIFIED · evidence has not been produced.

Constraints

Server acknowledgement is required before showing Mentve. Local recovery drafts must not be labelled saved. Preserve valid intermediate typing and never silently turn blank/unknown into zero.
Keep proposal/contact identities, versions, server-owned baselines and document history. Serialize saves per record, retain newer edits during in-flight saves and prevent cross-contact or cross-proposal writes.
Autosave applies to proposal cells and the shared customer panel throughout the portal. Do not expand this into a rewrite of unrelated blog or marketing settings. Autosaving data does not create/export/send a final PDF.

Keep PDF feedback immediate

Retain the useful yellow mapping with a quieter preview toolbar.

0 / 4

Criteria, constraints and evidence

D4.1. When quantity, unit rate, transport, customer details, terms and a settlement/payment cell are hovered or keyboard-focused, then the matching PDF text and all affected totals highlight in yellow, including affected later pages. Clicking pins the map and Escape clears it.

Required proof

Mapping assertions and actual screenshots of input cell plus every affected PDF region. Test standard and landscape with a multipage fixture.

Actual deployed screenshot: pending
Independent Luna High image description: pending
Executor comparison with this criterion: pending

UNVERIFIED · evidence has not been produced.

D4.2. When several edits are typed quickly and a PDF render is delayed, then the preview and highlights finally correspond to the newest data, no stale render replaces it, and the unchanged selection stays meaningful.

Required proof

Controlled stale-render test, revision/region comparison and final screenshot.

Actual deployed screenshot: pending
Independent Luna High image description: pending
Executor comparison with this criterion: pending

UNVERIFIED · evidence has not been produced.

D4.3. When the proposal opens, then a compact aligned PDF toolbar shows the primary download action, the test-data banner and design-variant label are absent, and a compact summary/save indicator replaces the large status and metric strips.

Required proof

Desktop/mobile screenshots and layout measurements: proposed desktop editor identity row at most 60px, summary at most 36px, default PDF toolbar at most 48px. Necessary errors may expand temporarily.

Actual deployed screenshot: pending
Independent Luna High image description: pending
Executor comparison with this criterion: pending

UNVERIFIED · evidence has not been produced.

D4.4. When the displayed current PDF is downloaded, then the displayed bytes match the downloaded and stored artifact, the selected orientation/draft state is respected, a final export with unresolved included prices is clearly unavailable, and historical PDFs remain byte-identical.

Required proof

Pre-click/display/download/server SHA256 equality, unknown-price case and archive hash comparison, plus screenshots.

Actual deployed screenshot: pending
Independent Luna High image description: pending
Executor comparison with this criterion: pending

UNVERIFIED · evidence has not been produced.

Constraints

Preserve yellow hover/focus impact marks, click-to-pin, Escape-to-clear and affected-page tracking. Preview overlays must never appear in a downloaded PDF.
Keep the existing standard/landscape capability and meaningful draft/final choice, but tuck secondary controls into a compact predictable control area. No second manual data editor beside the table.
Only offer a current valid download. Keep first-final-export baseline semantics, immutable historical documents and explicit distinction between saving data and exporting a PDF.

Brand every PDF page consistently

Every page looks like the same Kertújítók document.

0 / 2

Criteria, constraints and evidence

D5.1. When a three-or-more-page proposal is rendered in standard and landscape layouts, then every page has the same compact logo/header treatment and consistent logo-derived green table/section styling, including continuation and terms pages.

Required proof

All-page PDF renders, sampled palette/logo dimensions and fresh independent image descriptions for every page.

Actual deployed screenshot: pending
Independent Luna High image description: pending
Executor comparison with this criterion: pending

UNVERIFIED · evidence has not been produced.

D5.2. When long descriptions, accented Hungarian text and five settlement stages force page breaks, then repeated table headings, rows, totals and footers remain readable, with no overlap, clipped text or header collisions and no missing content.

Required proof

All-page renders, PDF text/content/bounds checks and per-page screenshots.

Actual deployed screenshot: pending
Independent Luna High image description: pending
Executor comparison with this criterion: pending

UNVERIFIED · evidence has not been produced.

Constraints

Use the existing approved logo and its green shades with neutral text/paper. Preserve yellow only as the editor impact overlay. No unrelated blue palette or fabricated contact/commercial details.
Apply the same smaller-logo header and coherent typography to every page, including terms and continuation pages. Preserve source content, Hungarian accents, totals and readable pagination.
Regenerate only new previews/exports. Never repaint or overwrite previously stored PDFs.

Deliver one verified integrated experience

Ship the selected B-based proposal design inside the existing staging portal, with proof and recovery.

0 / 4

Criteria, constraints and evidence

D6.1. When the original fixture is recalculated after the redesign, then the grid and PDF show 374,500 Ft total, made of 191,000 Ft labor, 25,000 Ft transport and 158,500 Ft materials. Changing only quantity preserves rates, transport is counted once, excluded/unknown/zero remain distinct, and settlement/requested/received/debt values reconcile. The unmapped M5 180,000 Ft never becomes a payment or copied new-proposal value.

Required proof

Independent original workbook comparison and targeted model/API/GUI/PDF tests, plus resulting table/PDF screenshots.

Actual deployed screenshot: pending
Independent Luna High image description: pending
Executor comparison with this criterion: pending

UNVERIFIED · evidence has not been produced.

D6.2. When the integrated staging URLs are opened from fresh unauthenticated clients after deployment, then the selected B-based proposal interface and real tabbed customer panel work without a token/login redirect, with saved A/B data still isolated and the latest calendar behavior retained.

Required proof

Provider source/version/binding readback, anonymous HTTP checks, six-entrypoint smoke tests, A/B data isolation and desktop/mobile postdeployment screenshots. Deploy shared portal changes to both existing staging copies from their respective current sources. Before public staging deployment, inventory exposed routes/API responses, assets, records and PDFs against the exact staging-only bindings and verify all exposed customer data/documents are synthetic, using provider/data readback and anonymous samples. This preserves the historical synthetic-data boundary without adding an access gate. B is the sole proposal design basis, not a new A/B comparison: apply required shared integration to both existing staging copies while retaining each current calendar delta.

Actual deployed screenshot: pending
Independent Luna High image description: pending
Executor comparison with this criterion: pending

UNVERIFIED · evidence has not been produced.

D6.3. When old records and PDFs are compared before and after deployment, then unchanged records/documents retain their exact content and the task report provides the source commit, rollback version, preserved delta, deployed links and evidence for every passed criterion.

Required proof

Narrow backups and restore rehearsal, original-record and PDF hashes, changelog, scoped diff and completed evidence board. No completion claim for missing evidence.

UNVERIFIED · evidence has not been produced.

D6.4. When a new synthetic customer proposal is created with a lost-response retry, an existing linked proposal is reopened, regular/Pótmunka rows are added and removed, and settlement stages4/5 are added, then exactly one contact and linked proposal exist, reopening retains its ID, stable row links and totals survive, and unrelated dated-payment history remains intact.

Required proof

Existing historical C05/C06/C09/C14 regression journey: exact record IDs/counts, model/API arithmetic and payment readback, fresh reload and actual grid screenshots. Use existing supported actions, no new workflow.

Actual deployed screenshot: pending
Independent Luna High image description: pending
Executor comparison with this criterion: pending

UNVERIFIED · evidence has not been produced.

Constraints

This run prepares a contract only. Implementation starts after a later explicit Launch. At execution, use the existing Cloudflare staging boundaries and the B proposal as the selected design. No new A/B proposal alternatives or standalone design demos.
Apply the shared tabbed customer panel globally to portal entrypoints. Preserve each staging variant’s calendar behavior/data, including the newest A quick-entry refinement, by coordinating current source and deployment ownership. Do not deploy an old snapshot over concurrent changes.
No production release, GAJA/GHL access, client sending, irreversible deletion, new security layer or commercial commitment. Preserve existing data/terms/amounts and the user’s unsaved browser tab. Bare review/staging URLs only, public artifacts contain no credentials or private source data.
Existing account, D1 and R2 bindings remain the authority. Fresh readback and a verified narrow rollback are required. Do not reset databases or regenerate unrelated marketing assets.

Authority and review gate

Prepare now: read sources, refine the contract, publish/open this review board. No application deployment or executor launch. After a later explicit Launch: one Sol Medium executor may implement the listed shared portal/proposal changes, test synthetic records, deploy both existing isolated staging copies, keep this board updated and make narrow reversible recovery changes. Up to USD15 aggregate external spend for this task unless Matt explicitly approves more. No client messages, production release, binding commitments or irreversible deletion.

Current item: Matt reviews this contract. A later explicit Launch starts implementation under the LLL skill. No executor has been created or queued.

Parent ↔ child messages

Meaningful handoffs only

PARENT · Contract preparation27 September 2026

The latest feedback supersedes the standalone prototype/demo and manual-save design. Existing data and useful calculation behavior stay. The header-only draft has not been deployed.

No executor message yet. Preparation reviewers do not implement the product.

Parent read set and recoveryAvailable after Launch

Executor will maintain a deliverable list, main-prompts list, session identity and this board. At completion or stall, the parent reads the clean gist and those small files.

Recovery state: not started. Resume point: review the contract, reconcile comments, then a later explicit Launch.