LLL · communication board

Verification and Constraints

● IN PROGRESS

Proposal generator · two working variants · three lead-sidebar designs · execution authorized

Live owner: Proposal executor · implementation Run: kertujitok-proposal-20260927-v1 Updated: 27 September 2026

Goal and finish line

End goal: Let Péter create, reopen and settle a customer proposal in his familiar sheet-style interface while seeing and downloading the matching PDF immediately.

Done means: Two independently saved, fully working proposal UI variants live inside isolated staging copies of the client panel. Each has an Ajánlatok list/create screen and the familiar sheet editor with live cell-to-PDF highlighting, editable Pótmunka and settlement columns, two PDF layouts, dated payments and saved document history. One non-modal lead-sidebar design works in both proposal variants, and two alternative sidebar designs are separate interactive frontend prototypes. All published demos use synthetic data and bare URLs. Execution authorized by Matt on 27 September 2026.

0 / 25criteria verified

7deliverables

0open decisions

Rules that stay fixed

Proposal generator only now. Calendar redesign, global Folyamat redesign and universal sidebar rollout across unrelated panel views are deferred, not cancelled.
Keep the spreadsheet's look, terminology, column relationships and interaction. It is our custom app, not Excel, Google Sheets or an embedded spreadsheet service. Both UI variants preserve this.
Matt explicitly authorized one new Sol xhigh orchestrator, followed by calendar integration in a second sequential thread.

Proof standard: Behavior + saved-data readback + matching PDF artifacts + screenshot / independent description / comparison. Product proof is pending.

End goal system

Green = confirmed requirement · Pink = assumption · Dashed = open step. Confirmed requirements are not completed product tests.

flowchart TD
 L["<b>Ajánlatok</b><br/>Find or create the lead's proposal"]:::confirmed
 S["<b>Lead sidebar</b><br/>Edit contact details beside the workspace"]:::confirmed
 T["<b>Familiar custom sheet</b><br/>Quote rows + extra work + dated settlements"]:::confirmed
 P["<b>Live PDF preview</b><br/>Highlight matching cells and totals"]:::confirmed
 F["<b>Final or draft PDF</b><br/>Standard or landscape from the same data"]:::confirmed
 H["<b>Saved record and history</b><br/>Reopen work without rewriting old PDFs"]:::confirmed
 L --> T
 L <--> S
 S <--> T
 T --> P --> F
 T <--> H
 F --> H
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
 I["Inputs: contract, workbook, prototype"] --> B["Verified staging backup"] --> E["Implement A/B and sidebars"] --> V["Deployed journeys and PDFs"] --> Q["Independent screenshot QA"] --> D["Evidence and calendar handoff"]
 classDef underway fill:#E8F1FF,stroke:#1765BD,color:#174578;
 class E underway;

Confirmed scope and decisions

Proposal generator only now. Calendar redesign, global Folyamat redesign and universal sidebar rollout across unrelated panel views are deferred, not cancelled.
Keep the spreadsheet's look, terminology, column relationships and interaction. It is our custom app, not Excel, Google Sheets or an embedded spreadsheet service. Both UI variants preserve this.
One ongoing proposal record per lead. Do not introduce multiple-project, multi-property, team, invoice or automatic-email systems. Reopening a linked proposal must not create another.
Both variants retain cell hover/focus highlighting and click-to-pin in the PDF, editable extra-work rows, labor/material settlement stages and cumulative reconciliation. Do not split quote and settlements into separate editors.
No new login, token, VPN, IP restriction or security layer. Publish non-sensitive synthetic staging views at bare URLs. Do not expose production CRM or private source transcripts. Leave existing production systems unchanged.
Matt explicitly authorized one new Sol xhigh orchestrator, followed by calendar integration in a second sequential thread.

Q1-AVariant A and B use independent saved copies of identical test data.

Q2-A + sidebar correctionRetain one upcoming reminder per lead. A lead opens in a non-modal editable side panel. Provide three sidebar designs, with two allowed as standalone frontend prototypes.

Q3 + final scope correctionDo not invent extra project information for the PDF. Calendar work-period questions are deferred. Preserve the sheet's data and the specifically accepted settlement fields.

Q4 correctionThe lead sidebar exposes editable lead information, original enquiry and own note, separate reminder/work-delivery dates, a persisted calendar-note visibility checkbox and a proposal property. Empty proposal means Create, which creates and opens the editor. Existing proposal means a link opening that same proposal.

Q5-BCreating a proposal for a new customer automatically creates the linked CRM contact.

Q6 correctionDo not add complexity for multiple unrelated jobs per customer.

Q7-AAllow clearly marked draft PDFs with unresolved prices. Final export requires pricing or explicit exclusion.

Q8-ASettlement materials include transport once, visibly labelled Anyag és szállítás.

Q9-AShow current quantities and a compact original-estimate to current-total summary. Earlier exported PDFs remain unchanged.

Q10-AStore dated payments under each settlement and calculate received totals and outstanding balances.

Assumptions and facts to verify

Reversible defaults

UI variant A uses a compact sheet-first workspace. Variant B changes list organization and workspace spacing/preview controls, not the familiar sheet template or accounting behavior.
The working sidebar is shared by both proposal variants. The two standalone sidebar alternatives have clearly labelled demo-only state, so they are not mistaken for saved CRM integrations.
The original-estimate baseline is captured on the first final quote export. Later exports create immutable document versions. This is a reversible product default, not a new approval workflow.
The calendar visibility preference and work-delivery date are persisted lead properties here. Their calendar rendering is deferred. Existing calendar/reminder behavior must not regress.
An explicitly excluded row is omitted from the final PDF and all included totals. A zero price is an explicit numeric value, not a substitute for an unknown price.
Each included regular or Pótmunka row uses quantity × labor unit rate, one row-level transport amount, and quantity × material unit rate. Store blank/unknown, explicit zero, not-applicable and excluded distinctly. Preserve existing unit rates when only quantity changes.
The historical fixture reproduces its selected/formula-populated rows explicitly. Rows with a unit rate but no source total are not permanently disabled: newly included rows use the normal formula. Do not silently turn source question marks into numeric zeros.
Before the first final quote export, the original-estimate comparison is labelled not yet captured. Draft exports never freeze the baseline. First final quote export captures row identities, quantities, rates and included totals once, including when reached from a settlement workflow. Subsequent edits never reset it.

Executor discovery, not extra approval gates

Before implementation, verify the current staging repository, branch, Worker routes and D1 bindings from current source/provider readback. Prior reports and local export folders are navigation evidence only.
Inventory existing staging proposal data and save a restorable backup before replacing Ajánlatok. Keep a task-owned route/config rollback. Removal means retiring the old UI, not silently purging stored records.
Verify every original sheet row/formula and the unexplained 180,000 Ft reference cell against the source workbook. Do not interpret that reference value as a payment or include it in new-proposal templates. Inventory non-row content across workbook and demonstrated template: customer/header fields, work-start/payment terms, Pótmunka wording and branding. Preserve verified content, resolve differences from the latest source precedence, and do not fabricate missing values.
Read the latest user prompt, annotations and inline rewrites immediately before launch. Record the check time and a zero-comment result when applicable. Material revisions return for review.

Authority and proof

After explicit Launch, the executor may inspect access/source, implement, migrate isolated staging data, run tests, publish both staging variants and the two sidebar prototype pages, and maintain this stable review board. Shared paid budget is USD 20 combined across proposal and calendar including all agents and services. No client messages, invoice issuance, production release, commercial commitments or irreversible data deletion. Use a verified restore path before replacing old staging behavior. Deployment proof includes anonymous fresh-client access and exact provider readback.

For each GUI criterion, save an actual screenshot after the named action for each applicable functional variant. A fresh independent gpt-6-luna high agent receives only that screenshot, describes what is visible, and the parent compares it with the criterion. Attach screenshot, description and comparison. Screenshots supplement behavior, arithmetic, persistence and PDF-byte checks. Leave any missing evidence unverified. Run the required Luna section screenshot/fix/fresh-QA cycle on deployed app pages. All product criteria remain unchecked in Prepare.

Work and proof

0 of 25 criteria are verified. Checkboxes indicate evidence, not reviewer approval.

D1 · Replace staging with two working variants

Provide fair, independently editable comparisons without changing production.

0 / 3

Show criteria, constraints and evidence

Preserve these constraints

Preserve unrelated panel modules and production routes/data. Never access or restore GAJA/GHL.
Replace the rejected staging Ajánlatok UI only after a verified recoverable backup. Use synthetic data and no added access gate.
The Ajánlatok entry at the user-requested calendar-stage-20260923.cfd-staging.com/panel/ must open functional variant A after retiring the old proposal interface. Variant B has its own independent staging URL. Preserve the rest of that existing panel.

Observable tests

C01. When the two variant bare URLs are opened in fresh unauthenticated browsers, then the existing-style client-panel shell and working Ajánlatok entry appear in both variants without a login or token.

Proof: Anonymous HTTP receipt, deployed URLs, provider bindings readback, desktop/mobile screenshots and independent descriptions. Before public deployment, inventory exposed routes/assets/APIs/documents and enumerate their staging records. Read back exact staging-only bindings and prove all exposed data is synthetic, including PDFs and exports; do not publish if production/private data remains reachable. This is data isolation and content verification, not a new access/security layer.

IN PROGRESS
predeployment-data-inventory.json
before-curl-http.json
Final deployed proof remains pending.

C02. When the Test Garden lead and proposal are edited and saved in variant A, then those changes survive a reload in A while the same starting records in variant B remain unchanged. When the edits are repeated in B and interleaved with A saves, then each variant retains its own distinct saved values and never overwrites the other.

Proof: Two-session save/reload journey, data readback and both variant screenshots.

IN PROGRESS
namespace-clone-rehearsal.json
namespace-provider-readback.json
migration-readback.json
Final deployed proof remains pending.

C03. When the executor compares pre-change backup and deployment receipts with the completed staging release, then the recovery artifact, exact restore procedure and unchanged production target appear in the private delivery report.

Proof: Backup checksum, restore rehearsal on disposable staging data, scoped diff and production binding/route comparison.

IN PROGRESS
backup-rehearsal.json
Final deployed proof remains pending.

D2 · List and reopen customer proposals

Make creation and continuation a short path from Ajánlatok or a lead.

0 / 3

Show criteria, constraints and evidence

Preserve these constraints

One ongoing proposal per lead. Do not build a project/property management hierarchy.
A PDF download is not proof of sending or payment. Preserve manual status control and no automatic email.

Observable tests

C04. When Péter searches Ajánlatok for Test Garden and opens its row, then the correct saved proposal opens with its current totals, draft/sent label and document history.

Proof: Search/reopen journey, saved-data readback and list/editor screenshots in A and B.

IN PROGRESS
ui-test-results.json
Both local variants passed the frontend journey. Final assembled/deployed evidence and independent screenshot triplets are pending.

C05. When Péter creates a proposal for a new synthetic customer and repeats the save after a simulated retry, then exactly one CRM contact and one linked proposal exist and the editor opens.

Proof: Create/retry behavior check, record-count readback and editor/sidebar screenshots. Inject a lost response after contact commit before successful proposal linkage, then retry and repeat/concurrently attempt creation in each variant; verify one linked contact/proposal and no orphan.

IN PROGRESS
ui-test-results.json
Both local variants passed the frontend journey. Final assembled/deployed evidence and independent screenshot triplets are pending.

C06. When Péter chooses an existing CRM contact with a proposal, then its proposal link reopens that record instead of creating a duplicate. When it has no proposal, Create makes and opens its first proposal.

Proof: Both branches tested, record IDs/counts and sidebar/editor screenshots.

IN PROGRESS
ui-test-results.json
Both local variants passed the frontend journey. Final assembled/deployed evidence and independent screenshot triplets are pending.

D3 · Preserve the familiar editable sheet

Let Péter type as before and immediately see the affected PDF content.

0 / 4

Show criteria, constraints and evidence

Preserve these constraints

Preserve original row relationships, Hungarian headings, units and calculations. Do not substitute cards or a wizard for the sheet.
No Google Sheets dependency or prototype-only two-row limit. Unknown values cannot silently become zero.

Observable tests

C07. When the original workbook fixture is loaded, then the sheet and PDF show the verified 374,500 Ft baseline, comprising 191,000 Ft labor, 25,000 Ft transport and 158,500 Ft materials, with source-excluded and unknown rows explicitly accounted for.

Proof: Workbook-to-model comparison, arithmetic report, extracted PDF text and sheet/PDF screenshots. Verify source fixture before treating baseline as authoritative. Record source row/formula mapping and included/excluded/unknown status. Source cached totals are 191,000 + 25,000 + 158,500 = 374,500 Ft; M5 is an unmapped 180,000 value outside the summed settlement rows. Its meaning is unverified, so do not count it as a payment or carry it into new proposals without another cited source establishing its meaning.

IN PROGRESS
pdf-receipts.json
page-bounds.json
Local implementation evidence only. First-final baseline semantics corrected afterward. Final deployed arithmetic, PDFs and independent screenshot triplets are pending.

C08. When a quantity, unit price, description or unit is edited in the baseline fixture, then dependent totals and the current PDF update without a page reload within two seconds after typing stops. Hover/focus highlights the related PDF content, click pins it and Escape clears it. A quantity-only change preserves its existing unit rates. Transport stays a row amount and is not multiplied by quantity.

Proof: Input-to-preview journey including dependent totals, timing receipt and highlighted/unhighlighted screenshots in both variants.

IN PROGRESS
ui-test-results.json
Both local variants passed the frontend journey. Final assembled/deployed evidence and independent screenshot triplets are pending.

C09. When Péter removes an unwanted template row and adds five regular rows plus three Pótmunka rows, then every included row is editable, saved and represented in the matching PDF and settlement matrix. Re-including a previously unused priced template row calculates it normally, and removal/exclusion never erases prior exported documents or silently drops recorded settlement/payment history.

Proof: Add/remove/save/reload journey, stable row mapping, extracted PDF content and screenshots.

IN PROGRESS
ui-test-results.json
Both local variants passed the frontend journey. Final assembled/deployed evidence and independent screenshot triplets are pending.

C10. When a price remains unknown and Péter exports a draft, then a clearly marked draft with an incomplete-total indication appears. When final export is attempted, then the unresolved rows are identified until priced or explicitly excluded.

Proof: Draft/final branch tests and downloaded PDF text/render screenshots. Verify excluded rows are omitted from final included totals.

IN PROGRESS
ui-test-results.json
Both local variants passed the frontend journey. Final assembled/deployed evidence and independent screenshot triplets are pending.

D4 · Reconcile extra work and settlements

Keep quoted work, performed work and money received distinct in the same sheet.

0 / 5

Show criteria, constraints and evidence

Preserve these constraints

Use dated settlement stages with labor and Anyag és szállítás columns. Count transport exactly once, with no new invoice/tax system.
Keep quote, Pótmunka and settlement in one editor. Never force received money to equal the initial estimate or mark requested money as paid.

Observable tests

C11. When Péter enters work-item labor and material/transport allocations into settlement stages 1 and 2, then stage totals, cumulative settled totals and remaining unsettled work appear consistently in the sheet and PDF.

Proof: Golden arithmetic fixture, row-to-stage reconciliation and sheet/PDF screenshots, including partially settled items. Independent oracle: one included row has quantity 2, labor unit rate 50, material unit rate 20 and row transport 10, total 150. Stage 1 labor 60 plus Anyag és szállítás 30 (20 material + 10 transport) totals 90. Stage 2 labor 20 plus material 10 totals 30. Cumulative settled is 120, remaining unsettled is 30 (labor 20 + material 10). Requested amounts and received payments do not alter these work-value totals.

C12. When a 25,000 Ft transport amount is included in a settlement, then Anyag és szállítás includes that amount once and the grand total does not double count it.

Proof: Explicit labor/material/transport fixture and category/grand-total assertions plus PDF screenshot.

C13. When 508,000 Ft of work is settled, 500,000 Ft requested and payments of 200,000 Ft and 300,000 Ft are recorded on two dates, then the stage shows 500,000 Ft received, 8,000 Ft outstanding and both dated payments after reload.

Proof: Payment create/edit/remove/reload tests, arithmetic readback and PDF/sidebar screenshots.

C14. When three settlement stages already exist and Péter adds stages 4 and 5, then the new columns keep all row links and totals, and both PDF layouts remain readable with future/unfilled entries visibly blank.

Proof: Five-stage fixture, pagination/render inspection and corresponding editor screenshots.

C15. When original quantity 220 becomes actual quantity 234 and a Pótmunka row is added, then the current totals and compact original-estimate to current-total summary update while an earlier exported PDF keeps its original bytes. The comparison uses the original captured row quantities and rates, not a baseline overwritten during reopening or export.

Proof: Before/after arithmetic, old PDF SHA-256 comparison, current PDF extraction and rendered screenshots. Use an originally quoted 6,000 Ft unit-rate fixture and verify a quantity-only edit leaves that rate unchanged in both PDF layouts. Manual rate edits remain available.

D5 · Export both matching PDF layouts

Give Péter a readable customer document directly from the current sheet.

0 / 3

Show criteria, constraints and evidence

Preserve these constraints

Both functional UI variants offer both PDF layouts. The UI alternatives are not substitutes for the PDF layout selector.
PDF content comes from sheet fields and explicitly accepted summary/payment fields only. Do not include internal CRM notes or hover overlays in customer PDFs.

Observable tests

C16. When Standard is selected, then one PDF contains the compact quote with settlement/Pótmunka detail on following pages. When Landscape is selected, then the quote and dated settlement columns appear together with clear separation. Both layouts retain source-verified customer/header fields, work-start/payment terms, Pótmunka explanatory text and existing branding, without inventing absent values or new fields.

Proof: Both downloaded PDF files per variant, text extraction and all-page render screenshots. Compare the workbook and demonstrated template content inventory against each PDF layout.

C17. When the currently displayed preview is downloaded after an edit, then the PDF file represents the same current document revision, with correct Hungarian glyphs, totals and no highlighting overlays.

Proof: Preview/download revision and byte/hash linkage, extracted text assertions and PDF rendering.

C18. When long descriptions, five settlement stages and enough work rows to span several pages are entered, then readable headings, totals and all included rows appear without clipping or missing pages in both PDF layouts.

Proof: Long-content fixtures and all-page PDF screenshots, with inspection of first, middle and last pages.

D6 · Open three usable lead sidebars

Keep lead information at hand without blocking the proposal workspace.

0 / 4

Show criteria, constraints and evidence

Preserve these constraints

One sidebar design is integrated and persisted in both proposal variants. Two alternatives may be standalone interactive HTML prototypes clearly marked as demo-only.
Opening a sidebar must not apply a modal backdrop, lock scrolling or make the remaining UI inert. Broader unrelated-panel rollout and calendar rendering remain deferred.

Observable tests

C19. When a lead is opened from any lead-card/contact entry point in the proposal flow, then a side panel shows editable lead business information, original enquiry, own note, reminder date, work-delivery date, calendar-note visibility and proposal property.

Proof: Field inventory versus actual lead schema, click/open screenshots in A and B, save/reload readback. Generated technical IDs may be displayed read-only.

IN PROGRESS
ui-test-results.json
Both local variants passed the frontend journey. Final assembled/deployed evidence and independent screenshot triplets are pending.

C20. When the integrated sidebar is open at desktop and 390 px viewport widths and Péter edits a sheet cell or uses the list behind it, then the underlying UI remains visible and interactive and both sets of edits survive saving/reopening without overwriting unrelated fields. On narrow screens, use a resize/collapse or split workspace rather than a modal takeover.

Proof: Simultaneous sidebar/sheet interaction, stale-save recovery test and desktop/narrow-viewport screenshots.

IN PROGRESS
ui-test-results.json
Both local variants passed the frontend journey. Final assembled/deployed evidence and independent screenshot triplets are pending.

C21. When Péter edits either note, the reminder date, work-delivery date or calendar-note checkbox and reloads, then the same values appear in the integrated sidebar and the existing CRM fields retain their intended meanings.

Proof: Read/write/readback plus existing reminder smoke checks, screenshot of all saved properties. No claim of new calendar behavior. Explicitly reschedule a synthetic lead with an existing upcoming reminder and verify exactly one upcoming reminder remains at the new date.

IN PROGRESS
ui-test-results.json
Both local variants passed the frontend journey. Final assembled/deployed evidence and independent screenshot triplets are pending.

C22. When the three sidebar design links are opened, then three distinct usable arrangements appear, each demonstrating expand/collapse, editable fields and non-blocking interaction. Two standalone pages clearly state that edits are demo-only.

Proof: Three anonymous URLs, interaction results and screenshots for each design, with production versus demo persistence labels.

IN PROGRESS
ui-test-results.json
Both local variants passed the frontend journey. Final assembled/deployed evidence and independent screenshot triplets are pending.

D7 · Prove persistence and recoverable editing

Prevent apparently saved edits, lost work and false completion.

0 / 3

Show criteria, constraints and evidence

Preserve these constraints

Do not overwrite newer changes silently or lose a dirty edit when switching leads. Provide understandable save/error/retry behavior.
No criterion is passed solely from a screenshot, a green status marker or an executor claim. Preserve missing-proof labels.

Observable tests

C23. When a save fails or another session changes the same proposal, then the user sees a clear unsaved/conflict state with a recoverable path and their typed values are not silently lost.

Proof: Injected failure and two-session conflict scenarios, persistence readback and failure/recovery screenshots.

IN PROGRESS
ui-test-results.json
Both local variants passed the frontend journey. Final assembled/deployed evidence and independent screenshot triplets are pending.

C24. When eight varied end-to-end scenarios are run on each final deployed variant, then a matrix records create/link, reopen, cell highlighting, unknown prices, Pótmunka, partial payments, changed quantities and long five-stage PDFs with exact artifact links. One scenario finishes changed actual quantities and Pótmunka across stages with current final value = cumulative settled value = cumulative received money and both unsettled work and outstanding money zero; its unfinished step shows both residuals separately. This tests arithmetic and display, not a forced payment or completion gate.

Proof: Per-variant scenario matrix, fresh deployed screenshots, all corresponding downloaded PDFs, arithmetic/content results and remaining limitations.

IN PROGRESS
Implementation and local checks complete; deployed behavior and independent screenshot triplets pending.

C25. When each GUI test's screenshot is described by a fresh independent Luna High agent without its expected result, then the screenshot, description and parent's criterion comparison appear together on this board before its checkbox is marked passed.

Proof: Evidence triplets per applicable GUI criterion and URL/state. Missing triplets remain unchecked.

PENDING

Parent ↔ child messages

PARENT · PREPARE27 September 2026

The user narrowed this run to the proposal generator and requested LLL. Review this contract. Matt has now explicitly authorized execution.

Implementation in progress in an isolated source worktree. The live staging shell and calendar match the snapshot byte for byte. Complete SQL and Worker backups saved, SQLite restore rehearsal passed. All 12 existing staging leads are synthetic and the image bucket is empty. Separate A/B table copies avoid the account database quota while preserving existing resources. Model/PDF, API and frontend workers are active. No product criterion is passed yet.

Review and next action

Inspect the scope, assumptions and seven deliverable cards. Use the comment toolbar for corrections. Execution is authorized. Parent will check once after 20 minutes, then at 60-minute intervals.

Latest user authority supersedes the default launch/model rule: execute with one Sol xhigh orchestrator, then integrate the calendar through a second sequential orchestrator. No additional review gate.

Prelaunch annotations were empty. Execution is authorized and underway. No new business question is pending.

Inputs and private handoff

Highlighted proposal reference Existing isolated panel staging

The executor brief contains the exact local sources, transcript gists, workbook and provider discovery steps. Private transcripts and contact data are not published on this board. After launch the private read set holds the deliverable list, main prompts and session identity.

Recovery state

Recovery and deployment evidence

0consecutive stalls

Not startedrecovery state

Review boardresume point

Last stall / completion note: Implementation started. Existing calendar staging preserved at source commit 4a1874e. No product criterion passed yet.

Parent action: Execution is authorized. Parent reviews at its scheduled checkpoint. Continue implementation and evidence collection.