Kertújítók · Calendar only · Integrated execution

Verification and Constraints

COMPLETE

Two working calendar variants. Three lead-sidebar designs. One clear scope.

Executor: Sol-6 · xhighRevision 727 September 2026

Complete: 22/22 calendar criteria and 25/25 original proposal outcomes verified on the repaired deployment. Independent desktop/mobile section reviews and 244 image-only observations are reconciled with the final behavioral suite.

Goal and finish line

End goal: Give Péter a simple, reliable calendar and editable lead sidebar inside his client panel, with two working calendar variants and three sidebar designs to compare.

Done means: Péter can plan reminders and multi-day work, recognize contacts from both notes, and edit all lead information without losing calendar context. Two independent existing staging variants retain the finished proposal generator. One shared sidebar is integrated across the panel and editor, with two enhanced standalone alternatives. Calendar, CRM, proposal create/open and PDF export work as one tested system.

22 / 22implementation criteria verified

6deliverables

0blocking user questions

Rules that stay fixed

Calendar-only scope. Keep proposal integration to the requested property, link and create action.
Keep the surrounding UI visible and editable when a lead sidebar opens.
Use bare public staging URLs with synthetic data. No new security layer. No production changes.
Independent A/B datasets. One integrated sidebar plus two standalone prototypes.

Proof standard: Every GUI test needs an actual post-change screenshot, an independent Luna High description without the expected result, and the orchestrator comparison. Save/reload/API checks prove behavior separately. Apply shared criteria to both working variants.

End goal system

ConfirmedAssumptionOpen fact / pending gate

flowchart TD
 A["<b>Client panel</b><br/>Calendar A or B<br/>Independent data"]:::confirmed --> B["<b>Click a day</b><br/>Find contact<br/>Choose event type"]:::confirmed
 B --> C["<b>Reminder</b><br/>One follow-up date"]:::confirmed
 B --> D["<b>Planned work</b><br/>Start, duration, weekends"]:::confirmed
 C --> E["<b>Calendar entries</b><br/>Both notes visible<br/>× hides notes"]:::confirmed
 D --> E
 E --> F["<b>Editable lead sidebar</b><br/>Background stays usable"]:::confirmed
 F --> G["<b>Saved lead data</b><br/>Reminder and work<br/>Separate properties"]:::confirmed
 G --> E
 F --> H["<b>Proposal property</b><br/>Open saved editor<br/>Or create proposal"]:::confirmed
 H --> I["<b>Proposal service</b><br/>Preserved behavior<br/>Final regression"]:::confirmed
 F --> J["<b>Small-screen dock</b><br/>Stacked workspaces<br/>Both remain usable"]:::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

ConfirmedAssumptionOpen fact / pending gate

flowchart LR
 A["<b>Verified proposal staging</b><br/>Two variants<br/>Shared lead sidebar"]:::confirmed --> C["<b>Refine integration</b><br/>Preserve criteria<br/>Use shared fields"]:::confirmed
 B["<b>Settled answers</b><br/>Simple calendar<br/>Three sidebar designs"]:::confirmed --> C
 C --> D["<b>Authorized execution</b><br/>Sequential scope<br/>Synthetic staging"]:::confirmed
 D --> E["<b>Sol-6 xhigh orchestrator</b><br/>Verify source<br/>Stage and rollback"]:::confirmed
 E --> F["<b>Build isolated variants</b><br/>Two apps<br/>Two sidebar prototypes"]:::confirmed
 F --> G["<b>Prove the behavior</b><br/>Persistence checks<br/>Screenshots and review"]:::confirmed
 G --> H["<b>Hosted comparison</b><br/>Verified links<br/>Evidence and limits"]:::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

Confirmed outcomes and scope

Confirmed decisions

Q1 A: independent variant data with identical synthetic starting fixtures.
Q2 A: one upcoming reminder per contact, reschedule rather than duplicate.
Latest sequential execution instruction: finish and verify the proposal first, then integrate this calendar into that completed panel.
Latest sidebar requirement: all lead business information editable in a nonmodal side panel, with the background still usable.
Annotation 1: show both notes on calendar cards, add × to hide them, and a sidebar checkbox to restore visibility.
Q4 override: shared sidebar; separate reminder/work properties; empty proposal property or existing link and secondary create action.
Q5 B is implemented: a new proposal customer becomes a CRM contact. Q6: no multi-project edge-case complexity.
Proposal C01–C25, including the familiar editable sheet, settlement, extra work and PDFs, is completed. Preserve and regression-test it during calendar integration.
Final source e4ae0ae is deployed on both isolated staging variants. All 22 calendar criteria and C01–C25 pass fresh verification.
Desktop/mobile post-repair section reviews and 244 independent Luna High image descriptions are complete.
Mobile stacked workspaces preserve background editing and reachable controls.
Both outboxes remain empty and all 98 pre-existing PDF hashes are unchanged.

Explicit assumptions

One planned work period per lead, consisting of start date, duration and weekend inclusion. No split phases, recurring work or capacity planner. This is a parent choice under the request for simplicity, not an interpretation of Q3, which concerned proposal/PDF data.
The work delivery date is the planned start selected on the calendar; show the computed finish alongside it. Do not introduce a second manually maintained due date.
For weekends excluded, duration counts Monday to Friday, start inclusive. A weekend start advances to Monday with a visible notice before save; public holidays are not special.
Checkbox label: Jegyzetek megjelenítése a naptárban. Default true for existing and new stage contacts. Both original enquiry and own note follow this one setting.
Two working calendar variants remain in scope from the prior request. Three sidebar variants means one integrated design plus two standalone alternatives, not six combinations.
One integrated design may use a docked stacked layout on narrow screens so background controls stay available.
Store reminder and planned-work dates as timezone-free YYYY-MM-DD calendar values. Europe/Budapest governs today/default day, but a stored date never shifts with the viewer timezone.

Remaining scope

No unresolved required outcome. Production variant selection and release remain outside this staging task.

Integration with the verified proposal generator

Reuse variant A at calendar-stage-20260923.cfd-staging.com/panel/ and variant B at kertujitok-proposal-b-20260927.clientsflowdigital.workers.dev/panel/. Keep B’s existing pvb_ namespace isolation. Add a matched synthetic calendar fixture set without resetting either existing dataset.
Reuse proposal-v2 LeadSidebar and its PATCH-only changed fields, version checks, preserved dirty drafts and explicit conflict recovery. Roll it out to all panel lead-card surfaces and extend both existing sidebar prototypes with the same calendar fields. Retest the proposal editor sidebar too.
Keep emlekezteto_datum as the independent one-reminder property. Extend work_delivery_date as the canonical planned start with additive duration and weekend fields, computed finish only. Existing single dates become one-day work periods without a shifted day. No competing date model or manually maintained second due date.
Keep message and belso_jegyzet separate and editable. One calendar_note_visible flag governs both note previews on reminder/work entries. Update the old own-note-only label to Jegyzetek megjelenítése a naptárban. Folyamat previews both notes regardless of this flag.
Reuse /panel/api/proposal-v2, the one-proposal-per-lead relation and /panel/proposals/?proposal=<id>. Creation uses a stable requestId across retries and navigates to the real editor. Existing proposals, identity, revision, first-final baseline, settlement/extra-work data and immutable PDF bytes survive integration.
The day-click creation popup is the compact scheduling entrypoint with search, two cards, work slider/weekends and editable notes. Opening an existing lead uses the shared nonmodal sidebar. Both save through the same lead model and refresh surrounding views without losing another lead’s draft.
Keep MAIL_MODE disabled and both outboxes empty. No production bindings. Deploy over the verified proposal assets, not an older calendar build. Capture current data and immutable PDF hashes before migration, verify after both deployments.
Final acceptance includes every original calendar criterion plus fresh integrated proposal regressions, actual browser journeys, final hosted source/provider readback, postdeployment section QA and blind screenshot evidence. Prior proposal evidence is a baseline, not proof of the new deployment.

Final proposal regression: 25 / 25

The original C01–C25 outcomes were tested again on the deployed calendar build. Expand any criterion to inspect its result and evidence.

C01 · PASS 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.

A/B screenshots show the existing panel shell and working proposal editor. Fresh anonymous HTTP and browser receipts independently prove no login/token redirect. Existing synthetic data and branding are retained.

Behavior / provider evidence: routes-A.json · routes-B.json · proposal-routes-A.json · proposal-routes-B.json · public-payload-audit.json

Actual screenshots: A · scenario-1-editor · B · scenario-1-editor

Independent blind descriptions: final-proposal-a: image-001.png · final-proposal-b: image-067.png

Orchestrator comparisons: C01 observation-to-requirement comparison · Exact image IDs, hashes and unedited observations

C02 · PASS 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.

Both variant editors retain distinct saved fixtures. Similar starting totals alone do not establish isolation. Interleaved proposal/sidebar writes, exact IDs and fresh calendar sessions establish separate A/B storage and the A-only marker.

Behavior / provider evidence: proposal-api.json · results.json

Actual screenshots: A · typing-current-preview · B · typing-current-preview

Independent blind descriptions: final-proposal-a: image-035.png · final-proposal-b: image-101.png

Orchestrator comparisons: C02 observation-to-requirement comparison · Exact image IDs, hashes and unedited observations

C03 · PASS 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.

This criterion is established by provider and recovery receipts: exact original Worker rollback versions, a rehearsed private SQL snapshot with 26 tables and integrity_check=ok, a recoverable public-asset archive, unchanged original records and 98 historical PDF hashes. No production target was modified.

Behavior / provider evidence: baseline.json · migration.json · final-audit.json

Orchestrator comparisons: C03 observation-to-requirement comparison · Exact image IDs, hashes and unedited observations

C04 · PASS 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.

The Test Garden editor displays the verified 374,500 Ft current total, draft/final state and saved-document controls. Sixteen real list-search/open journeys match the selected proposal ID and reload history. Full section QA covers the expanded history beyond the initial viewport.

Behavior / provider evidence: receipt.json · proposal-api.json

Actual screenshots: A · scenario-1-editor · B · scenario-1-editor

Independent blind descriptions: final-proposal-a: image-001.png · final-proposal-b: image-067.png

Orchestrator comparisons: C04 observation-to-requirement comparison · Exact image IDs, hashes and unedited observations

C05 · PASS 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.

Lost-response images show a retained new-customer form and explicit failure, followed by the same customer’s real zero-total editor. API, concurrent-retry and contact-commit recovery tests establish exactly one contact and proposal. Visible inactive priced template rows do not contribute to the zero total.

Behavior / provider evidence: receipt.json · proposal-contact-recovery.json · proposal-api.json

Actual screenshots: A · new-customer-lost-response · A · new-customer-recovered · B · new-customer-lost-response · B · new-customer-recovered

Independent blind descriptions: final-proposal-a: image-042.png, image-043.png · final-proposal-b: image-108.png, image-109.png

Orchestrator comparisons: C05 observation-to-requirement comparison · Exact image IDs, hashes and unedited observations

C06 · PASS 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.

The existing-customer scenario opens its 12,000 Ft proposal. Calendar screenshots show the empty property, creation/retry and subsequent real editor/link. Record linkage and stable requestId assertions establish create-once/reopen behavior.

Behavior / provider evidence: results.json · proposal-api.json · receipt.json

Actual screenshots: A · scenario-2-editor · B · scenario-2-editor

Independent blind descriptions: final-proposal-a: image-005.png · final-proposal-b: image-071.png

Orchestrator comparisons: C06 observation-to-requirement comparison · Exact image IDs, hashes and unedited observations

C07 · PASS 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.

Independent images read the 374,500 Ft workbook/PDF baseline. Source-cell fixtures and generated PDF text reconcile 191,000 labor + 25,000 transport + 158,500 materials. Excluded and unknown rows retain explicit semantics rather than contributing invented prices.

Behavior / provider evidence: receipt.json

Actual screenshots: A · scenario-1-editor · A · scenario-1-standard · A · scenario-1-landscape · B · scenario-1-editor · B · scenario-1-standard · B · scenario-1-landscape

Independent blind descriptions: final-proposal-a: image-001.png, image-003.png, image-004.png · final-proposal-b: image-067.png, image-069.png, image-070.png

Orchestrator comparisons: C07 observation-to-requirement comparison · Exact image IDs, hashes and unedited observations

C08 · PASS 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.

Edited worksheet quantities and matching PDF highlights are visible. Eight measured typing-to-current-preview samples took 531–575 ms. Hover/focus/pin/Escape, retained unit rates and once-only transport calculations pass independently. B image-101’s blind financial reading was checked against the actual frame: current 401,004, settled 0, unsettled 401,004, received 0, outstanding 0.

Behavior / provider evidence: receipt.json · receipt.json

Actual screenshots: A · scenario-3-highlight · A · scenario-3-standard · A · scenario-3-landscape · A · typing-current-preview · B · scenario-3-highlight · B · scenario-3-standard · B · scenario-3-landscape · B · typing-current-preview

Independent blind descriptions: final-proposal-a: image-010.png, image-011.png, image-012.png, image-035.png · final-proposal-b: image-076.png, image-077.png, image-078.png, image-101.png

Orchestrator comparisons: C08 observation-to-requirement comparison · Exact image IDs, hashes and unedited observations

C09 · PASS 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.

The row-addition scenario shows regular and Pótmunka entries in sheet and PDF. Saved row IDs, inclusion/removal/reinclusion, five added regular rows, three extra rows and retained exported history are asserted. A zero-total newly created editor may display excluded template prices without including them in arithmetic.

Behavior / provider evidence: receipt.json · receipt.json

Actual screenshots: A · scenario-5-editor · A · scenario-5-standard · A · scenario-5-landscape · B · scenario-5-editor · B · scenario-5-standard · B · scenario-5-landscape

Independent blind descriptions: final-proposal-a: image-017.png, image-019.png, image-020.png · final-proposal-b: image-083.png, image-085.png, image-086.png

Orchestrator comparisons: C09 observation-to-requirement comparison · Exact image IDs, hashes and unedited observations

C10 · PASS 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.

The unknown-price PDF visibly says it is a draft with incomplete totals and unresolved rows. Final export rejects unpriced included rows until priced or excluded. Both layouts’ downloaded files match the displayed preview, preserving draft/final semantics.

Behavior / provider evidence: receipt.json · receipt.json

Actual screenshots: A · scenario-4-editor · A · scenario-4-standard · A · scenario-4-landscape · B · scenario-4-editor · B · scenario-4-standard · B · scenario-4-landscape · A · scenario-4/unknown-standard-draft-1.png · A · scenario-4/unknown-standard-draft-2.png · B · scenario-4/unknown-standard-draft-1.png · B · scenario-4/unknown-standard-draft-2.png

Independent blind descriptions: final-proposal-a: image-013.png, image-015.png, image-016.png, image-044.png, image-045.png · final-proposal-b: image-079.png, image-081.png, image-082.png, image-110.png, image-111.png

Orchestrator comparisons: C10 observation-to-requirement comparison · Exact image IDs, hashes and unedited observations

C11 · PASS 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.

Settlement columns and summary distinguish current work, cumulative settled work and unsettled work. The independent 150/90/30/120/30 oracle reconciles both stages and row totals. Payments are checked separately so received money cannot change work allocation totals.

Behavior / provider evidence: receipt.json

Actual screenshots: A · scenario-6-editor · A · scenario-6-standard · A · scenario-6-landscape · B · scenario-6-editor · B · scenario-6-standard · B · scenario-6-landscape

Independent blind descriptions: final-proposal-a: image-021.png, image-023.png, image-024.png · final-proposal-b: image-087.png, image-089.png, image-090.png

Orchestrator comparisons: C11 observation-to-requirement comparison · Exact image IDs, hashes and unedited observations

C12 · PASS 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.

The 25,000 Ft transport row appears once within material/transport amounts. Scenario arithmetic and PDF text check once-only allocation and grand totals, independently of quantity changes.

Behavior / provider evidence: receipt.json

Independent blind descriptions: final-proposal-a: image-003.png, image-024.png, image-046.png, image-047.png, image-048.png, image-049.png · final-proposal-b: image-069.png, image-090.png, image-112.png, image-113.png, image-114.png, image-115.png

Orchestrator comparisons: C12 observation-to-requirement comparison · Exact image IDs, hashes and unedited observations

C13 · PASS 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.

The dated-payment images show 508,000 Ft settled, 500,000 requested and received, and 8,000 outstanding, with separate 200,000 and 300,000 payments and dates. Read-only reopened captures have identical before/after proposal hashes. B image-094 belongs to another scenario: its 950,000 is requested money, not debt.

Behavior / provider evidence: receipt.json · proposal-api.json · receipt.json

Independent blind descriptions: final-proposal-a: image-046.png, image-047.png, image-048.png, image-049.png, image-056.png, image-057.png, image-058.png · final-proposal-b: image-112.png, image-113.png, image-114.png, image-115.png, image-122.png, image-123.png, image-124.png

Orchestrator comparisons: C13 observation-to-requirement comparison · Exact image IDs, hashes and unedited observations

C14 · PASS 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.

The five-stage scenario shows preserved linked rows, stages 4/5 and blank future entries. Both layouts retain all values. Representative full-size PDF pages receive independent visual inspection, while all 128 rendered pages receive automated content and word-bound checks.

Behavior / provider evidence: receipt.json · receipt.json

Independent blind descriptions: final-proposal-a: image-030.png, image-032.png, image-033.png, image-034.png, image-050.png, image-051.png, image-052.png, image-053.png, image-054.png, image-055.png · final-proposal-b: image-096.png, image-098.png, image-099.png, image-100.png, image-116.png, image-117.png, image-118.png, image-119.png, image-120.png, image-121.png

Orchestrator comparisons: C14 observation-to-requirement comparison · Exact image IDs, hashes and unedited observations

C15 · PASS 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.

The changed-quantity scenario shows 220→234 at the unchanged 6,000 unit rate plus Pótmunka, with an original-estimate/current-total comparison. A image-027’s blind quantity reading of 4 is an observation error: root inspection reads 234, also independently read in adjacent images. Original baseline and previously exported PDF bytes remain unchanged through reopen/export.

Behavior / provider evidence: receipt.json · final-audit.json

Actual screenshots: A · scenario-7-editor · A · scenario-7-standard · A · scenario-7-landscape · B · scenario-7-editor · B · scenario-7-standard · B · scenario-7-landscape

Independent blind descriptions: final-proposal-a: image-025.png, image-027.png, image-028.png · final-proposal-b: image-091.png, image-093.png, image-094.png

Orchestrator comparisons: C15 observation-to-requirement comparison · Exact image IDs, hashes and unedited observations

C16 · PASS 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.

Standard separates compact quote and settlement detail. Landscape arranges quote and settlement columns together. The source-verified customer/header, start/payment terms, extra-work wording and branding remain. Forty-four scenario PDFs and 32 GUI downloads cover both layouts. All 128 pages are retained, with representative full-size visual inspection and automated all-page bounds/content verification.

Behavior / provider evidence: receipt.json · receipt.json

Independent blind descriptions: final-proposal-a: image-003.png, image-004.png, image-034.png, image-050.png, image-051.png, image-052.png, image-053.png, image-054.png, image-055.png · final-proposal-b: image-069.png, image-070.png, image-100.png, image-116.png, image-117.png, image-118.png, image-119.png, image-120.png, image-121.png

Orchestrator comparisons: C16 observation-to-requirement comparison · Exact image IDs, hashes and unedited observations

C17 · PASS 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.

Preview and downloaded PDF totals and Hungarian text agree, with no exported interaction highlight. All 32 actual downloads have equal pre-click preview, downloaded-file, server-response and saved-document hashes. The independent parent rehash also confirms all 32.

Behavior / provider evidence: receipt.json · receipt.json

Actual screenshots: A · scenario-3-standard · A · scenario-3-landscape · B · scenario-3-standard · B · scenario-3-landscape

Independent blind descriptions: final-proposal-a: image-011.png, image-012.png · final-proposal-b: image-077.png, image-078.png

Orchestrator comparisons: C17 observation-to-requirement comparison · Exact image IDs, hashes and unedited observations

C18 · PASS 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.

The long five-stage fixture spans 16 Standard pages and five Landscape pages, retaining long text, headings, totals and every included row. B image-096’s 16 is a page count, not a row count: the fixture has 24 included rows. Representative first/middle/last pages are visually reviewed, and every page passes word-bound/content checks. Small embedded previews can be opened larger.

Behavior / provider evidence: receipt.json · receipt.json

Orchestrator comparisons: C18 observation-to-requirement comparison · Exact image IDs, hashes and unedited observations

C19 · PASS 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.

Proposal and CRM entrypoint images show the same shared contact sidebar, including editable business information and both note/date models. Full sidebar scroll inventories cover the bottom visibility and proposal fields plus source/history, avoiding claims based solely on cropped top frames.

Behavior / provider evidence: results.json · receipt.json · calendar-api.json

Actual screenshots: A · proposal-sidebar-desktop · B · proposal-sidebar-desktop

Independent blind descriptions: final-proposal-a: image-036.png · final-proposal-b: image-102.png

Orchestrator comparisons: C19 observation-to-requirement comparison · Exact image IDs, hashes and unedited observations

C20 · PASS 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.

Desktop and 390 px captures show the sheet and sidebar together. Mobile uses two scrollable stacked regions with accessible close/collapse/save controls. Live background edits, save/reopen and conflict tests prove reachability and preservation of unrelated fields. Apparent overlay in a still image does not establish modal behavior.

Behavior / provider evidence: results.json · receipt.json

Actual screenshots: A · proposal-sidebar-desktop · A · proposal-sidebar-mobile · A · sidebar-conflict · A · sidebar-conflict-recovered · B · proposal-sidebar-desktop · B · proposal-sidebar-mobile · B · sidebar-conflict · B · sidebar-conflict-recovered

Independent blind descriptions: final-proposal-a: image-036.png, image-037.png, image-040.png, image-041.png · final-proposal-b: image-102.png, image-103.png, image-106.png, image-107.png

Orchestrator comparisons: C20 observation-to-requirement comparison · Exact image IDs, hashes and unedited observations

C21 · PASS 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.

Both notes, reminder, planned start/duration/weekends and calendar visibility are visible in the shared sidebar and survive actual reload checks. Calendar reminder uniqueness and work separation remain intact. Targeted hide/reload/restore captures confirm the single visibility flag governs both notes.

Behavior / provider evidence: results.json · calendar-api.json · proposal-api.json

Actual screenshots: A · proposal-sidebar-desktop · A · sidebar-conflict-recovered · B · proposal-sidebar-desktop · B · sidebar-conflict-recovered

Independent blind descriptions: final-proposal-a: image-036.png, image-041.png · final-proposal-b: image-102.png, image-107.png

Orchestrator comparisons: C21 observation-to-requirement comparison · Exact image IDs, hashes and unedited observations

C22 · PASS 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.

The integrated sidebar, tabbed prototype and ledger prototype have distinct arrangements. Both standalone pages label their edits and proposal actions as demo-only. Desktop/mobile interaction receipts prove expand/collapse, editing and background use. Partly scrolled date fields are covered by complete date-state and section captures.

Behavior / provider evidence: results.json · results.json

Actual screenshots: A · proposal-sidebar-desktop · A · proposal-sidebar-mobile · B · proposal-sidebar-desktop · B · proposal-sidebar-mobile · A · contact-background · A · date-notice · A · notes · A · mobile-background-sidebar · A · contact-background · A · date-notice · A · notes · A · mobile-background-sidebar · B · contact-background · B · date-notice · B · notes · B · mobile-background-sidebar · B · contact-background · B · date-notice · B · notes · B · mobile-background-sidebar

Independent blind descriptions: final-proposal-a: image-036.png, image-037.png, image-063.png, image-064.png, image-066.png, image-065.png, image-059.png, image-060.png, image-062.png, image-061.png · final-proposal-b: image-102.png, image-103.png, image-129.png, image-130.png, image-132.png, image-131.png, image-125.png, image-126.png, image-128.png, image-127.png

Orchestrator comparisons: C22 observation-to-requirement comparison · Exact image IDs, hashes and unedited observations

C23 · PASS 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.

Network-failure and real version-conflict images show clear unsaved status and recovery actions, followed by recovered state. Typed drafts remain present, and unrelated fields merge without silent overwrite. Full section QA covers notices and actions beyond a cropped viewport.

Behavior / provider evidence: receipt.json · results.json

Actual screenshots: A · proposal-save-failure · A · proposal-conflict · A · sidebar-conflict · A · sidebar-conflict-recovered · B · proposal-save-failure · B · proposal-conflict · B · sidebar-conflict · B · sidebar-conflict-recovered

Independent blind descriptions: final-proposal-a: image-038.png, image-039.png, image-040.png, image-041.png · final-proposal-b: image-104.png, image-105.png, image-106.png, image-107.png

Orchestrator comparisons: C23 observation-to-requirement comparison · Exact image IDs, hashes and unedited observations

C24 · PASS 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.

Eight scenarios per final deployed variant pass 920 assertions with 44 generated PDFs and 128 retained page renders. The changed-quantity/Pótmunka scenario first distinguishes unsettled work from outstanding money, then finishes with current = settled = received and both residuals zero. This is test arithmetic, not a forced payment gate.

Behavior / provider evidence: receipt.json · receipt.json

Orchestrator comparisons: C24 observation-to-requirement comparison · Exact image IDs, hashes and unedited observations

C25 · PASS 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.

Fresh Luna High agents describe all 244 final-build neutral images without expected results. Exact ordered IDs and source hashes are validated. Each visual criterion combines its actual image, unedited observation and root comparison. Separate post-repair desktop/mobile section reviews and explicit discrepancy notes close visual coverage without reusing prior-release acceptance.

Behavior / provider evidence: final-map.json · agent-launches.json

Orchestrator comparisons: C25 observation-to-requirement comparison · Exact image IDs, hashes and unedited observations

Working surfaces and evidence

Calendar A · Calendar B · Tabbed sidebar prototype · Ledger sidebar prototype

Deployed application source e4ae0aea693866642f283f3fe29d48aaaa4bf315. A Worker 3efe3760-cd64-4d1e-86a0-bfce234a73a9. B Worker 0ef9032e-f19d-4245-9f11-da146540d6ae. All 98 original PDFs retain their hashes. Exact recovery and final evidence are linked below. No production changes or paid external calls.

Source, Worker versions and exact recovery · All 47 final comparisons · Desktop section review · Mobile section review · Actual review models

Work and proof

Boxes reflect actual final-build acceptance evidence

Publish two working calendar variants

Compare two distinct, equally functional experiences inside the existing panel.

4 / 4 passed

Show criteria, constraints and evidence

D1-1 When each variant URL is opened in a fresh unauthenticated browser, then the same added synthetic calendar fixture set and a working Naptár tab replacing Emlékeztetők appear in the existing client panel, with earlier variant-specific data preserved.

Required evidence: Anonymous HTTP response and postdeployment screenshots for both URLs, including shared navigation.

A image-133 shows the existing panel and month grid. B has the corresponding shell and chronological calendar. The same Demo fixtures are visible. Anonymous route receipts and the 31-check final audit establish bare access and preservation of earlier records, which screenshots alone cannot prove.

Behavior / provider evidence: Actual A/B calendar browser journeys · 110 calendar API checks · Original records and98 PDF hashes · Final Luna xhigh desktop section review · Final Luna xhigh mobile section review

Actual screenshots: A · D1-1-shell-D1-2-month · B · D1-1-shell-D1-2-month

Independent blind descriptions: final-calendar-a: image-133.png · final-calendar-b: image-182.png

Orchestrator comparisons: D1-1 observation-to-requirement comparison · Exact image IDs, hashes and unedited observations

D1-2 When the same fixture is opened in variants A and B, then two visibly different calendar UI arrangements appear with the same core controls and business rules.

Required evidence: Side-by-side screenshots and a short explanation of the meaningful UX difference. Changing colors alone does not pass.

A uses a seven-column day grid. B uses a compact period overview and chronological day groups. Their navigation, event-type controls and date model match. The difference is arrangement and density, not merely color.

Actual screenshots: A · D1-1-shell-D1-2-month · B · D1-1-shell-D1-2-month

Independent blind descriptions: final-calendar-a: image-133.png · final-calendar-b: image-182.png

Orchestrator comparisons: D1-2 observation-to-requirement comparison · Exact image IDs, hashes and unedited observations

D1-3 When a synthetic lead note is saved in A and both variants are reloaded in fresh sessions, then the changed note appears only in A and the original appears in B.

Required evidence: Independent persisted readback plus screenshots after reload in both variants.

The fresh-session A image-181 contains the explicit A-only note marker. The corresponding B capture is image-230. Real save/reload assertions independently compare both records, proving the marker stayed in A rather than inferring isolation from similar screens.

Actual screenshots: A · D1-3-fresh-session-isolation · B · D1-3-fresh-session-isolation

Independent blind descriptions: final-calendar-a: image-181.png · final-calendar-b: image-230.png

Orchestrator comparisons: D1-3 observation-to-requirement comparison · Exact image IDs, hashes and unedited observations

D1-4 When month and week views are selected around 1 October 2026, then date-only entries appear on their correct local dates in both calendar views without hourly scheduling controls. The same stored dates remain on the same numbered days in Europe/Budapest and America/Los_Angeles browser timezone settings.

Required evidence: Month/week screenshots and deterministic date calculations around month boundaries. Cross-timezone browser check using a negative UTC offset to expose accidental instant conversion.

The month and boundary-week observations identify October 1 and September 28–October 4 / October 5–11 without hourly controls. The harness records Europe/Budapest and America/Los_Angeles contexts. Date-unit and API assertions prove identical YYYY-MM-DD placement in both zones.

Actual screenshots: A · D1-4-budapest-month · A · D1-4-budapest-boundary-week · A · D1-4-budapest-following-week · A · D1-4-los-angeles-month · A · D1-4-los-angeles-boundary-week · A · D1-4-los-angeles-following-week · B · D1-4-budapest-month · B · D1-4-budapest-boundary-week · B · D1-4-budapest-following-week · B · D1-4-los-angeles-month · B · D1-4-los-angeles-boundary-week · B · D1-4-los-angeles-following-week

Independent blind descriptions: final-calendar-a: image-134.png, image-135.png, image-136.png, image-137.png, image-138.png, image-139.png · final-calendar-b: image-183.png, image-184.png, image-185.png, image-186.png, image-187.png, image-188.png

Orchestrator comparisons: D1-4 observation-to-requirement comparison · Exact image IDs, hashes and unedited observations

Constraints

✕ Use the two existing independent staging datasets, preserving all saved synthetic leads, proposals and documents. Add the same synthetic calendar fixtures to each namespace without reset or copying real contact details.
✕ Preserve the panel identity, navigation and unrelated behavior. Replace the Emlékeztetők tab with Naptár and remove the duplicate calendar navigation entry.
✕ No production release, new security gate, Google Calendar sync, appointment times, recurrence or multi-project system.

Executor update: All 4 criteria verified against final deployed source e4ae0ae, fresh behavior receipts, independent visual evidence and the linked root comparisons.

Create reminders and planned work

Choose a contact on the calendar and place the two kinds of dates independently.

5 / 5 passed

Show criteria, constraints and evidence

D2-1 When an empty day is clicked and a name fragment is entered, then a searchable contact dropdown, the two event-type cards, and both notes for the selected contact appear in the creation popup.

Required evidence: Screenshot before and after contact selection, including a no-match state.

Empty-day, no-match and selected-contact images expose search, the reminder/work cards and both note fields. The no-match state has no selected contact and cannot save. Full-section QA covers the popup header and lower controls beyond a single viewport.

Actual screenshots: A · D2-1-empty-day-popup · A · D2-1-no-match · A · D2-1-selected-both-notes · B · D2-1-empty-day-popup · B · D2-1-no-match · B · D2-1-selected-both-notes

Independent blind descriptions: final-calendar-a: image-142.png, image-143.png, image-144.png · final-calendar-b: image-191.png, image-192.png, image-193.png

Orchestrator comparisons: D2-1 observation-to-requirement comparison · Exact image IDs, hashes and unedited observations

D2-2 When a reminder is saved for Demo Anna on 30 September and then moved to 2 October, then exactly one reminder appears on 2 October and the separate work dates remain unchanged after reload.

Required evidence: Screenshot, persisted record readback and reminder count assertion.

The reminder notice says the existing September 30 reminder will be rescheduled. The subsequent calendar state shows October 2. The live browser count and record readback establish exactly one reminder and unchanged separate work fields.

Actual screenshots: A · D2-2-reminder-september-30 · A · D2-2-reschedule-notice · A · D2-2-single-reminder-after-reload · A · D2-complete-reminder-work-preserved · B · D2-2-reminder-september-30 · B · D2-2-reschedule-notice · B · D2-2-single-reminder-after-reload · B · D2-complete-reminder-work-preserved

Independent blind descriptions: final-calendar-a: image-145.png, image-146.png, image-147.png, image-175.png · final-calendar-b: image-194.png, image-195.png, image-196.png, image-224.png

Orchestrator comparisons: D2-2 observation-to-requirement comparison · Exact image IDs, hashes and unedited observations

D2-3 When planned work for Demo Anna starts Friday 2 October 2026 for three days with weekends excluded, then the displayed finish is Tuesday 6 October and work occupies Friday, Monday and Tuesday; enabling weekends changes the finish to Sunday 4 October. Moving the duration slider updates the planned duration and computed finish before save.

Required evidence: Popup and calendar screenshots for both settings, persisted readback and date-unit tests. Nonworking weekend days must not imply booked labor.

A images-148 and 150 read October 2→6 with weekends excluded and October 2→4 with weekends included. Calendar cards and corresponding B states agree. Slider interaction, weekday occupancy and persisted duration are independently asserted, so Saturday/Sunday do not imply booked work when excluded.

Actual screenshots: A · D2-3-three-days-exclude-preview · A · D2-3-exclude-persisted · A · D2-3-three-days-include-preview · A · D2-3-include-persisted · A · D2-5-weekend-normalization-before-save · B · D2-3-three-days-exclude-preview · B · D2-3-exclude-persisted · B · D2-3-three-days-include-preview · B · D2-3-include-persisted · B · D2-5-weekend-normalization-before-save

Independent blind descriptions: final-calendar-a: image-148.png, image-149.png, image-150.png, image-151.png, image-152.png · final-calendar-b: image-197.png, image-198.png, image-199.png, image-200.png, image-201.png

Orchestrator comparisons: D2-3 observation-to-requirement comparison · Exact image IDs, hashes and unedited observations

D2-4 When two contacts have overlapping work periods crossing a week or month boundary, then both remain distinguishable and individually openable in the calendar without overwriting each other.

Required evidence: Postdeployment screenshots on both sides of the boundary and record readback.

Boundary views and the opened Anna/Béla sidebars show separately identifiable overlapping contacts. Browser actions open each exact lead ID and compare their stored periods after reload, proving neither overwrote the other.

Actual screenshots: A · D1-4-budapest-month · A · D1-4-budapest-boundary-week · A · D1-4-budapest-following-week · A · D2-4-overlap-open-anna · A · D2-4-overlap-open-bela · B · D1-4-budapest-month · B · D1-4-budapest-boundary-week · B · D1-4-budapest-following-week · B · D2-4-overlap-open-anna · B · D2-4-overlap-open-bela

Independent blind descriptions: final-calendar-a: image-134.png, image-135.png, image-136.png, image-140.png, image-141.png · final-calendar-b: image-183.png, image-184.png, image-185.png, image-189.png, image-190.png

Orchestrator comparisons: D2-4 observation-to-requirement comparison · Exact image IDs, hashes and unedited observations

D2-5 When existing work dates are edited through the popup or sidebar, then start/duration changes follow the weekend setting and persist after reload while the reminder stays unchanged. A failed save preserves the input and reports failure without showing false success.

Required evidence: Before/after screenshots and persisted date assertions, plus failed-save recovery. Drag/resize is optional, not a completion gate.

Weekend normalization is visible before save: Saturday October 3 moves to Monday October 5. Edited durations and computed finishes match date tests. Failure images retain entered notes and report failed save. The additional 390 px failure captures establish reachable recovery controls; aborted requests did not modify records.

Actual screenshots: A · D2-5-weekend-normalization-before-save · A · D2-5-failed-save-preserves-input · A · D2-5-sidebar-normalization · A · D2-complete-reminder-work-preserved · B · D2-5-weekend-normalization-before-save · B · D2-5-failed-save-preserves-input · B · D2-5-sidebar-normalization · B · D2-complete-reminder-work-preserved · A · planner-failed-save-preserved-draft · B · planner-failed-save-preserved-draft

Independent blind descriptions: final-calendar-a: image-152.png, image-153.png, image-170.png, image-175.png · final-calendar-b: image-201.png, image-202.png, image-219.png, image-224.png, image-235.png, image-242.png

Orchestrator comparisons: D2-5 observation-to-requirement comparison · Exact image IDs, hashes and unedited observations

Constraints

✕ Keep one active reminder and one planned work period per lead. New reminder/work choices explicitly reschedule the existing value rather than silently duplicating it.
✕ Keep one day-click popup with a searchable CRM dropdown and two selectable cards: Emlékeztető and Tervezett munka. Work selection reveals the expected-duration slider and weekend inclusion checkbox.
✕ Preserve existing reminder completion, reschedule and archive/restore semantics. Do not conflate reminder status with work progress.

Executor update: All 5 criteria verified against final deployed source e4ae0ae, fresh behavior receipts, independent visual evidence and the linked root comparisons.

Edit leads in a nonmodal sidebar

Keep the surrounding panel usable while every editable business field is available.

4 / 4 passed

Show criteria, constraints and evidence

D3-1 When a lead card is opened from each panel surface, then the same identifiable lead appears in the integrated sidebar with contact information, original enquiry, own note, status, reminder, work dates, note-visibility checkbox at the bottom of the sidebar and proposal property.

Required evidence: Screenshot per surface and field inventory matched to the current CRM schema.

Calendar, new-lead, pipeline, search, archive and proposal-entry screenshots show the shared sidebar for the selected contact. Full-height section captures cover editable business fields, both notes, source/history, separate reminder/work fields, the bottom visibility checkbox and real proposal property.

Actual screenshots: A · D2-4-overlap-open-anna · A · D2-4-overlap-open-bela · A · D3-1-calendar-sidebar · A · D3-1-new-lead-sidebar · A · D3-1-pipeline-sidebar · A · D3-1-search-result-sidebar · A · D3-1-archive-sidebar · A · D3-1-archive-restored · B · D2-4-overlap-open-anna · B · D2-4-overlap-open-bela · B · D3-1-calendar-sidebar · B · D3-1-new-lead-sidebar · B · D3-1-pipeline-sidebar · B · D3-1-search-result-sidebar · B · D3-1-archive-sidebar · B · D3-1-archive-restored

Independent blind descriptions: final-calendar-a: image-140.png, image-141.png, image-158.png, image-159.png, image-160.png, image-161.png, image-162.png, image-163.png · final-calendar-b: image-189.png, image-190.png, image-207.png, image-208.png, image-209.png, image-210.png, image-211.png, image-212.png

Orchestrator comparisons: D3-1 observation-to-requirement comparison · Exact image IDs, hashes and unedited observations

D3-2 When a note or original enquiry is edited in the sidebar and saved, then the updated value appears on the corresponding contact card and in a fresh session while source/history information remains recoverable.

Required evidence: Sidebar/card screenshots and backend readback after reload.

Edited notes appear in the card and fresh sidebar, with source/history retained. A image-175 also shows the edited original enquiry when the earlier viewport frames place it below the fold. Persisted field comparisons establish both note values independently of the screenshot crop.

Actual screenshots: A · D3-2-source-and-history · A · D3-2-updated-card · A · D3-2-fresh-session-notes · B · D3-2-source-and-history · B · D3-2-updated-card · B · D3-2-fresh-session-notes · Additional visible field evidence

Independent blind descriptions: final-calendar-a: image-164.png, image-165.png, image-166.png, image-175.png · final-calendar-b: image-213.png, image-214.png, image-215.png

Orchestrator comparisons: D3-2 observation-to-requirement comparison · Exact image IDs, hashes and unedited observations

D3-3 When the sidebar is open and another calendar day, card or Folyamat control is used, then the underlying UI responds without closing the sidebar first, and switching leads does not silently lose or apply unsaved changes to the wrong lead.

Required evidence: Interaction test plus screenshots with background and sidebar visible, including a failed-save case.

The sidebar and background planner coexist, and the behavioral run edits background controls without closing the sidebar. Failed-save and version-conflict states preserve drafts and expose recovery. A historical frame includes a four-second archive toast; a fresh read-only capture after its natural expiry closes that visibility gap without altering the app.

Actual screenshots: A · D3-3-sidebar-and-background-planner · A · D3-3-sidebar-failed-save · A · D3-3-real-version-conflict · A · D3-5-mobile-live-background-and-sidebar · B · D3-3-sidebar-and-background-planner · B · D3-3-sidebar-failed-save · B · D3-3-real-version-conflict · B · D3-5-mobile-live-background-and-sidebar · A · sidebar-failed-save-status · A · sidebar-failed-save-draft · B · sidebar-failed-save-status · B · sidebar-failed-save-draft

Independent blind descriptions: final-calendar-a: image-167.png, image-168.png, image-169.png, image-171.png · final-calendar-b: image-216.png, image-217.png, image-218.png, image-220.png, image-236.png, image-237.png, image-243.png, image-244.png

Orchestrator comparisons: D3-3 observation-to-requirement comparison · Exact image IDs, hashes and unedited observations

D3-5 When the panel is used at desktop width and 390 px width with the sidebar open, then the contact details and surrounding context remain reachable, visible and editable without clipped save/close controls.

Required evidence: Actual desktop and narrow screenshots with keyboard/touch interaction checks. A stacked dock on narrow screens is allowed, a blocking overlay is not.

Full desktop and 390 px section inventories show reachable save/close controls and separate scrollable background/sidebar regions. A mobile frame alone can resemble an overlay; actual background editing, collapse and independent scroll assertions establish the allowed stacked workspace. Long sheets and pipeline columns intentionally scroll horizontally on phones.

Actual screenshots: A · D3-1-calendar-sidebar · A · D3-5-mobile-live-background-and-sidebar · B · D3-1-calendar-sidebar · B · D3-5-mobile-live-background-and-sidebar · A · notes-visible-before-hide · A · notes-hidden-after-reload · A · hidden-notes-sidebar-and-restore-control · A · notes-restored-after-reload · A · planner-failed-save-preserved-draft · A · sidebar-failed-save-status · A · sidebar-failed-save-draft · B · notes-visible-before-hide · B · notes-hidden-after-reload · B · hidden-notes-sidebar-and-restore-control · B · notes-restored-after-reload · B · planner-failed-save-preserved-draft · B · sidebar-failed-save-status · B · sidebar-failed-save-draft

Independent blind descriptions: final-calendar-a: image-158.png, image-171.png · final-calendar-b: image-207.png, image-220.png, image-231.png, image-232.png, image-233.png, image-234.png, image-235.png, image-236.png, image-237.png, image-238.png, image-239.png, image-240.png, image-241.png, image-242.png, image-243.png, image-244.png

Orchestrator comparisons: D3-5 observation-to-requirement comparison · Exact image IDs, hashes and unedited observations

Constraints

✕ Apply one integrated sidebar design to every lead-card surface in both calendar variants: Új leadek, Naptár, Folyamat, Archívum, search results and any additional discovered contact-card view.
✕ Do not add a blocking backdrop, focus trap or full-screen takeover. The surrounding UI stays visible and editable while the sidebar is open.
✕ Expose all editable lead business data, including original enquiry and own note, separate reminder date, planned work start/duration/weekends, calendar-note visibility and proposal property. System IDs/history remain visible where relevant but are not falsified by free editing.
✕ Preserve any existing revision/conflict protection, but do not introduce a separate multi-session conflict subsystem as a new requirement. Ordinary failed-save and unsaved-edit recovery remain required.

Executor update: All 4 criteria verified against final deployed source e4ae0ae, fresh behavior receipts, independent visual evidence and the linked root comparisons.

Show notes and proposal actions

Make each lead recognizable and connect its existing proposal without rebuilding the generator.

3 / 3 passed

Show criteria, constraints and evidence

D4-1 When a lead with both notes appears on reminder and work cards, then both note previews are visible; clicking × hides them on all that lead’s calendar cards, and checking the sidebar visibility box restores them after reload.

Required evidence: Before/hide/reload/restore screenshots and per-lead persisted flag readback. × must not inadvertently open the sidebar.

Broad month frames sometimes place Anna below the viewport. The targeted A/B mobile sequences therefore show the same lead with both notes, after × and reload, with the unchecked restore control, and restored after reload. Persisted false/true flags and unchanged business fields support the visible transitions. The × action does not open the sidebar.

Actual screenshots: A · D4-1-both-notes-visible · A · D4-1-hidden-after-reload · A · D4-1-restored-after-reload · B · D4-1-both-notes-visible · B · D4-1-hidden-after-reload · B · D4-1-restored-after-reload · A · notes-visible-before-hide · A · notes-hidden-after-reload · A · hidden-notes-sidebar-and-restore-control · A · notes-restored-after-reload · B · notes-visible-before-hide · B · notes-hidden-after-reload · B · hidden-notes-sidebar-and-restore-control · B · notes-restored-after-reload

Independent blind descriptions: final-calendar-a: image-154.png, image-155.png, image-157.png · final-calendar-b: image-203.png, image-204.png, image-206.png, image-231.png, image-232.png, image-233.png, image-234.png, image-238.png, image-239.png, image-240.png, image-241.png

Orchestrator comparisons: D4-1 observation-to-requirement comparison · Exact image IDs, hashes and unedited observations

D4-2 When Folyamat opens without expanding cards, then both note previews and consistent readable action buttons appear; opening a card reveals full editable text in the shared sidebar.

Required evidence: Collapsed-card and sidebar screenshots with long, empty and multiline notes.

Collapsed Folyamat cards expose original enquiry and own note independently of calendar visibility. Long multiline and empty-note states remain readable, with full text editable in the sidebar. Repeated text is the intentional stress fixture, not a duplicated save. The blind sum of only visible pipeline columns is partial: other stages are reachable by horizontal scrolling and are covered in the full section inventory.

Actual screenshots: A · D4-2-pipeline-ignores-calendar-hide · A · D4-2-long-multiline-previews · A · D4-2-full-long-note-editor · A · D4-2-empty-note-previews · B · D4-2-pipeline-ignores-calendar-hide · B · D4-2-long-multiline-previews · B · D4-2-full-long-note-editor · B · D4-2-empty-note-previews

Independent blind descriptions: final-calendar-a: image-156.png, image-172.png, image-173.png, image-174.png · final-calendar-b: image-205.png, image-221.png, image-222.png, image-223.png

Orchestrator comparisons: D4-2 observation-to-requirement comparison · Exact image IDs, hashes and unedited observations

D4-3 When a lead without a proposal is opened, then its proposal property is empty and a secondary create button creates one through the existing service, links it to the lead and navigates to the actual editor; later openings show the proposal link instead.

Required evidence: End-to-end create/open screenshots, real record linkage, stable-request retry and repeat-click/reload assertions in both variants. Resolve integration failures using the verified proposal service. No simulated or dead-link success.

The empty proposal property and secondary creation action lead through a recoverable lost-response state into the actual proposal editor. The existing-link state reopens that same record. Durable requestId and record-count assertions prove one real linked proposal despite retries.

Actual screenshots: A · D4-3-empty-property-create-action · A · D4-3-lost-response-retry · A · D6-4-actual-linked-editor · A · D4-3-existing-proposal-reopened · B · D4-3-empty-property-create-action · B · D4-3-lost-response-retry · B · D6-4-actual-linked-editor · B · D4-3-existing-proposal-reopened · Additional visible field evidence

Independent blind descriptions: final-calendar-a: image-176.png, image-177.png, image-178.png, image-180.png, image-164.png · final-calendar-b: image-225.png, image-226.png, image-227.png, image-229.png

Orchestrator comparisons: D4-3 observation-to-requirement comparison · Exact image IDs, hashes and unedited observations

Constraints

✕ Calendar notes default to visible. The card × hides note fields only, never removes the event or contact. One saved per-lead setting controls both reminder and work entries.
✕ Folyamat always previews both original enquiry and Saját jegyzet by default, typically three lines each. The calendar visibility setting must not hide Folyamat notes.
✕ The proposal generator, settlement and PDF features are now implemented and accepted. Reuse their actual service and editor, preserve their behavior and immutable documents, and fix any integration regression. Do not replace the generator or leave an avoidable dependency as BLOCKED.

Executor update: All 3 criteria verified against final deployed source e4ae0ae, fresh behavior receipts, independent visual evidence and the linked root comparisons.

Compare three lead-sidebar designs

Keep one design operational and offer two additional interactive frontend alternatives.

2 / 2 passed

Show criteria, constraints and evidence

D5-1 When the three sidebar design links are opened, then three genuinely distinct arrangements of the same lead information appear: one integrated with staging persistence, and two labelled standalone frontend prototypes.

Required evidence: Three review URLs, screenshot comparison and a concise description of the design tradeoffs.

The integrated sidebar groups real contact fields in one persisted panel. The standalone tabs prototype divides fields into tabs. The ledger prototype uses a table-like record. All are visibly distinct, and the two alternatives explicitly label local demo behavior.

Actual screenshots: A · tabs · contact-background · A · tabs · date-notice · A · tabs · notes · A · tabs · mobile-background-sidebar · A · ledger · contact-background · A · ledger · date-notice · A · ledger · notes · A · ledger · mobile-background-sidebar · B · tabs · contact-background · B · tabs · date-notice · B · tabs · notes · B · tabs · mobile-background-sidebar · B · ledger · contact-background · B · ledger · date-notice · B · ledger · notes · B · ledger · mobile-background-sidebar · A · Integrated persistent sidebar · B · Integrated persistent sidebar

Independent blind descriptions: final-proposal-a: image-063.png, image-064.png, image-066.png, image-065.png, image-059.png, image-060.png, image-062.png, image-061.png · final-proposal-b: image-129.png, image-130.png, image-132.png, image-131.png, image-125.png, image-126.png, image-128.png, image-127.png · final-calendar-a: image-158.png · final-calendar-b: image-207.png

Orchestrator comparisons: D5-1 observation-to-requirement comparison · Exact image IDs, hashes and unedited observations

D5-2 When fields and background controls are exercised in each sidebar design, then edits, hide/show notes and panel navigation respond; only the two standalone designs may use clearly labelled simulated proposal actions.

Required evidence: Interaction evidence and screenshots on desktop and narrow screens for all three.

Desktop and mobile prototype captures show editable contact fields, date normalization, both notes and accessible background worksheet controls. Actual browser interactions verify local save/collapse/navigation for each alternative. The integrated design uses the tested staging API rather than simulated persistence.

Orchestrator comparisons: D5-2 observation-to-requirement comparison · Exact image IDs, hashes and unedited observations

Constraints

✕ One integrated design is shared across both working calendar variants. Two additional standalone frontend-only prototypes may use synthetic local state and must visibly identify themselves as prototypes.
✕ All three show the same fields and preserve nonmodal background interaction. Different layouts must not introduce different data meanings, hidden mandatory fields or extra workflow steps. Keep the note-visibility checkbox at the bottom in all three designs.
✕ Extend the already completed integrated, tabbed and ledger sidebar designs. Preserve their design identity and enhance work-period fields, rather than inventing three additional competing implementations.

Executor update: All 2 criteria verified against final deployed source e4ae0ae, fresh behavior receipts, independent visual evidence and the linked root comparisons.

Prove the hosted calendar workflow

Deliver usable links with precise evidence and a practical rollback.

4 / 4 passed

Show criteria, constraints and evidence

D6-1 When each final app/prototype URL is checked from an unauthenticated client, then it loads successfully with no token/login redirect, and the review index links to the assembled review surfaces.

Required evidence: HTTP/provider readback, review-host index check and postdeployment screenshots.

Fresh unauthenticated route checks return the A/B app and both prototype pages without login or token redirects. Screenshot inventories show their rendered surfaces. The final review index exposes those links alongside source, provider and recovery receipts.

Behavior / provider evidence: Actual A/B calendar browser journeys · 110 calendar API checks · Original records and98 PDF hashes · Exact deployed build and verified recovery · Final Luna xhigh desktop section review · Final Luna xhigh mobile section review

Actual screenshots: A · Anonymous calendar shell · A · tabs prototype · A · ledger prototype · B · Anonymous calendar shell · B · tabs prototype · B · ledger prototype

Independent blind descriptions: final-calendar-a: image-133.png · final-proposal-a: image-063.png, image-059.png · final-calendar-b: image-182.png · final-proposal-b: image-129.png, image-125.png

Orchestrator comparisons: D6-1 observation-to-requirement comparison · Exact image IDs, hashes and unedited observations

D6-2 When the final GUI evidence is submitted for each criterion, then its screenshot, an independent Luna High description made without the expected result, and the orchestrator comparison are attached to that criterion on this board. Complete the required luna-visual-qa-section-screehoshots inventory, section/viewport screenshots, fixes and fresh QA loop, with actual post-fix deployed screenshots before related visual criteria pass.

Required evidence: Evidence inventory keyed by criterion ID, actual screenshot references, blind description and comparison. Missing evidence leaves the box unchecked. Include full section/viewport/state coverage tables, retained defect and repair rounds, actual model/effort receipts, and any unroutable required model or inaccessible section as UNVERIFIED rather than passed.

Each GUI criterion is linked to exact source screenshots, SHA-256 matched neutral image IDs, untouched independent Luna High observations and this orchestrator comparison. Separate Luna xhigh desktop/mobile section reviews retain the original defects, repair evidence and final coverage. Viewport crops and isolated reading errors are reconciled explicitly rather than treated as automatic passes.

Behavior / provider evidence: Actual A/B calendar browser journeys · 110 calendar API checks · Original records and98 PDF hashes · Final neutral image-to-source map · Actual reviewer model and effort launches · Final Luna xhigh desktop section review · Final Luna xhigh mobile section review

Orchestrator comparisons: D6-2 observation-to-requirement comparison · Exact image IDs, hashes and unedited observations

D6-3 When the task closes, then the updated board shows the exact tested URLs, passed/total counts, remaining limitations, source revision, isolated stage bindings and the verified recovery/restore instructions.

Required evidence: Final board, provider receipt, rollback backup verification and compact completion report.

The completion board records 22 calendar outcomes and the fresh C01–C25 matrix, exact A/B URLs, deployed e4ae0ae source and Worker versions, isolated bindings, old/current asset hashes and tested recovery instructions. The source documentation commit is distinguished from deployed application bytes. Only the implicit favicon request and phone horizontal-scroll tradeoffs remain as nonblocking limits.

Orchestrator comparisons: D6-3 observation-to-requirement comparison · Exact image IDs, hashes and unedited observations

D6-4 After the final calendar deployment in A and B, calendar → CRM sidebar → existing/create proposal → familiar sheet and live PDF → calendar navigation works on the same lead. Reminder/work/notes edits persist across these surfaces, variants remain independent, and earlier proposal documents download with their original hashes.

Required evidence: Fresh deployed route/API/PDF scenario regressions using the proposal handoff commands, both-layout pre-click preview/download byte matches, hover/focus/pin/Escape and typing-to-preview checks, sidebar draft/conflict and 390 px background editing, before/after immutable PDF hashes, empty outbox and provider/build readback. Preserve all C01–C25 outcomes, not only this smoke journey.

The calendar→sidebar→create/open proposal→familiar sheet/live PDF→calendar journey returns to the same lead in both variants. The final 11-stage suite includes 110 calendar API checks, 101 proposal API checks, 24 recovery checks, 920 PDF assertions, 138 proposal-browser checks and 27 calendar interaction groups. All 32 downloads match pre-click previews and server bytes. The 31-check audit preserves original records and all 98 historical PDFs, with empty outboxes.

Behavior / provider evidence: Actual A/B calendar browser journeys · 110 calendar API checks · Original records and98 PDF hashes · Final neutral image-to-source map · Actual reviewer model and effort launches · Original proposal C01–C25 regression matrix · Final Luna xhigh desktop section review · Final Luna xhigh mobile section review

Actual screenshots: A · D6-4-actual-linked-editor · A · D6-4-editor-to-calendar-same-lead · A · D4-3-existing-proposal-reopened · B · D6-4-actual-linked-editor · B · D6-4-editor-to-calendar-same-lead · B · D4-3-existing-proposal-reopened

Independent blind descriptions: final-calendar-a: image-178.png, image-179.png, image-180.png · final-calendar-b: image-227.png, image-228.png, image-229.png

Orchestrator comparisons: D6-4 observation-to-requirement comparison · Exact image IDs, hashes and unedited observations

Constraints

✕ Every published review/app surface must use a bare stable URL with no added login, review token, VPN or IP gate. Public pages contain synthetic data and sanitized evidence only.
✕ Preserve unrelated work and production. Verify the target repo, active writers, stage bindings and a narrow rollback before changing existing staging.
✕ Keep this board current. No criterion passes on intention, a green job or screenshots alone. Do not send anything to Péter.

Executor update: All 4 criteria verified against final deployed source e4ae0ae, fresh behavior receipts, independent visual evidence and the linked root comparisons.

Authority and launch boundary

Matt explicitly authorized sequential proposal then calendar execution. Proposal C01–C25 is independently accepted. Implement, migrate synthetic staging, test, publish and recover autonomously. No additional Launch or review gate. USD20 combined across preparation, both phases and descendants, with USD1 reserved and USD19 remaining. No production/marketing/GAJA/GHL, client or lead messages, or added security layer. Preserve the completed proposal generator.

Matt’s sequential execution authorization was fulfilled by the sole calendar orchestrator. Implementation, deployment and final staging verification are complete. No further executor launch is pending.

The explicit user model choice overrides the skill default: gpt-6-sol, reasoning effort xhigh. Do not silently replace it. The implementation orchestrator owns its worker choices, source integration and final proof.

Parent ↔ child messages

Parent · integration readyRefined contract

Proposal C01–C25 accepted. Calendar retains its original outcomes and now shares the actual proposal API, fields, sidebar and A/B datasets. The × note action and checkbox share one persistent lead setting.

The sole calendar executor owns implementation and final evidence. The completed proposal executor no longer writes.

Source basis and read set

Latest user answers take precedence over historical plans. Private transcripts, prompts and source paths stay in the local handoff. Sanitized verification receipts are linked above.

Current user answers and annotation govern this revision. Earlier task gist and both full Wispr transcripts are supporting evidence only.
Current stage browser read: separate Emlékeztetők and Naptár entries; collapsed Folyamat cards hide notes; Ajánlatok did not navigate during read-only check.
Source check: existing lead model has one reminder date and current own-note field; no persisted work-period model. Provider bindings must be reread before writes.
Sequential execution authority: Matt’s overnight parent request, proposal before calendar, Sol xhigh, 20-minute then hourly checkpoints.
Parent independently accepted all 25 proposal criteria, rehashed 80 primary images and 20 retained GUI PDFs, inspected deployed evidence and actual screenshots. Proposal implementation 1e48a549af22324e485e00a01f2bf745bb9d7053, final documentation 7a6320141798e26bcdfca14c5fe6d9501fff3836.
Calendar review annotations fetched immediately before refinement: zero comments or inline rewrites. Existing criterion IDs and outcomes retained.

Current calendar staging · Verified proposal evidence

After launch the executor maintains: deliverable list, main prompts used, and session identifier. The parent reads these and a completion gist, not routine tool transcripts.

Open decisions and recovery

No further user answer is required. Preserve one work period per lead and the nonmodal narrow-screen sidebar behavior.

The completed proposal service is the integration baseline. Recover implementation or access failures autonomously within the authorized staging scope. A genuine unresolved essential failure stays unverified.

Limits: Monday–Friday workdays use the explicit weekend switch, without public-holiday rules. Standalone alternatives save locally. Wide phone sheets and pipeline columns scroll horizontally. The implicit favicon request returns 404. PDF visual review uses representative full-size pages, while all 128 pages pass automated content and word-bound checks.

Recovery: restore the recorded previous A/B Worker versions while retaining additive D1 data. Exact source, snapshot and validation receipts are linked in the execution handoff.

Preparation review coverage

Astra coordination and all three independent reviews completed: Sol scope review, Luna failure-mode review, and Luna official-source review. Useful simplifications were incorporated. This reviews the contract, not a built application.

The board and comment layer were checked separately. Calendar execution evidence is recorded above. Preparation review alone never passes an application criterion.