Kertújítók · Calendar only · LLL prepare

Verification and Constraints

READY FOR REVIEW

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

Executor after Launch: Sol-6 · xhighRevision 227 September 2026

Review the goal and assumptions below. No implementation executor has been created. This board is the deliverable for this preparation stage.

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 their notes, and edit lead information without losing calendar context. Two isolated staging variants persist independently. One sidebar design is integrated in both variants, and two additional designs are interactive standalone frontend prototypes. The proposal property uses the existing editor boundary only.

0 / 21implementation 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, independent data"]:::confirmed --> B["<b>Click a day</b><br/>Search contact and 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 shown, × hides them"]:::confirmed
 D --> E
 E --> F["<b>Editable lead sidebar</b><br/>Background stays usable"]:::confirmed
 F --> G["<b>Saved lead data</b><br/>Separate reminder and work properties"]:::confirmed
 G --> E
 F --> H["<b>Proposal property</b><br/>Existing editor link or create action"]:::confirmed
 H --> I["<b>Existing proposal service</b><br/>Verify usable integration contract"]:::open
 F --> J["<b>Small-screen dock</b><br/>Stacked context remains usable"]:::assumption
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>Current staging</b><br/>Two date views and hidden notes"]:::confirmed --> C["<b>Review this contract</b><br/>Resolve comments and changes"]:::confirmed
 B["<b>Settled answers</b><br/>Simple calendar and three sidebars"]:::confirmed --> C
 C --> D["<b>Explicit Launch</b><br/>Later user message required"]:::open
 D --> E["<b>Sol-6 xhigh orchestrator</b><br/>Verify source, stage and rollback"]:::confirmed
 E --> F["<b>Build isolated variants</b><br/>Two apps and two sidebar prototypes"]:::confirmed
 F --> G["<b>Prove the behavior</b><br/>Persistence, screenshots, blind review"]:::confirmed
 G --> H["<b>Hosted comparison</b><br/>Verified links and truthful 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, assumed and still to verify

Confirmed decisions

Q1 A: independent variant data with identical synthetic starting fixtures.
Q2 A: one upcoming reminder per contact, reschedule rather than duplicate.
Latest scope correction: calendar only; preserve the familiar proposal sheet requirement for later, not this build.
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 retained for future proposal work: new proposal customers become CRM contacts. Q6: do not add multi-project edge-case complexity.
Q7 A, Q8 A, Q9 A and Q10 A are settled but parked with the proposal generator; do not implement their PDF/settlement work now.

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.

Open implementation facts

Before implementation: resolve the actual current Cloudflare source checkout, stage deployment revision and writer ownership. The chat worktree is a dated detached checkout, not assumed to be the live source.
Verify the existing proposal create/link/editor contract in the requested stage. Repair only the integration entrypoint if feasible; a generator dependency that cannot be used is a named incomplete criterion, not authorization for a rebuild.
Choose the two calendar visual treatments and two alternate sidebar layouts during implementation. These are reversible design choices, not unanswered business questions.

Work and proof

All boxes remain unchecked until implementation evidence exists

Publish two working calendar variants

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

0 / 4 passed

Show criteria, constraints and evidence

D1-1 When each variant URL is opened in a fresh unauthenticated browser, then the same synthetic contact set and a working Naptár tab replacing Emlékeztetők appear in the client panel.

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

Screenshot: pending · Blind Luna High description: pending · Orchestrator comparison: pending

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.

Screenshot: pending · Blind Luna High description: pending · Orchestrator comparison: pending

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.

Screenshot: pending · Blind Luna High description: pending · Orchestrator comparison: pending

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.

Screenshot: pending · Blind Luna High description: pending · Orchestrator comparison: pending

Constraints

✕ Use independent, persistent staging datasets seeded with the same synthetic contacts. Never copy real contact details or production records onto public URLs.
✕ 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: Not started. Add actual progress and proof here after Launch.

Create reminders and planned work

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

0 / 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.

Screenshot: pending · Blind Luna High description: pending · Orchestrator comparison: pending

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.

Screenshot: pending · Blind Luna High description: pending · Orchestrator comparison: pending

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.

Screenshot: pending · Blind Luna High description: pending · Orchestrator comparison: pending

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.

Screenshot: pending · Blind Luna High description: pending · Orchestrator comparison: pending

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.

Screenshot: pending · Blind Luna High description: pending · Orchestrator comparison: pending

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: Not started. Add actual progress and proof here after Launch.

Edit leads in a nonmodal sidebar

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

0 / 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.

Screenshot: pending · Blind Luna High description: pending · Orchestrator comparison: pending

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.

Screenshot: pending · Blind Luna High description: pending · Orchestrator comparison: pending

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.

Screenshot: pending · Blind Luna High description: pending · Orchestrator comparison: pending

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.

Screenshot: pending · Blind Luna High description: pending · Orchestrator comparison: pending

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: Not started. Add actual progress and proof here after Launch.

Show notes and proposal actions

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

0 / 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.

Screenshot: pending · Blind Luna High description: pending · Orchestrator comparison: pending

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.

Screenshot: pending · Blind Luna High description: pending · Orchestrator comparison: pending

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, record linkage and repeat-click/reload assertions. If the existing service cannot support this, mark this criterion BLOCKED and identify the exact missing contract rather than claim completion.

Screenshot: pending · Blind Luna High description: pending · Orchestrator comparison: pending

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.
✕ Proposal generator replacement, settlement calculations and PDF redesign are deferred. Reuse the existing proposal service/editor if viable; never fake a saved proposal, use a dead link, or silently expand into rebuilding it.

Executor update: Not started. Add actual progress and proof here after Launch.

Compare three lead-sidebar designs

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

0 / 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.

Screenshot: pending · Blind Luna High description: pending · Orchestrator comparison: pending

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.

Screenshot: pending · Blind Luna High description: pending · Orchestrator comparison: pending

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.

Executor update: Not started. Add actual progress and proof here after Launch.

Prove the hosted calendar workflow

Deliver usable links with precise evidence and a practical rollback.

0 / 3 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.

Screenshot: pending · Blind Luna High description: pending · Orchestrator comparison: pending

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.

Evidence artifact / readback: pending

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.

Evidence artifact / readback: pending

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: Not started. Add actual progress and proof here after Launch.

Authority and launch boundary

PREPARE ONLY now. After a later explicit Launch: implement, migrate isolated staging data, run tests, publish stage/prototype URLs and maintain this board. No production changes, client sends or proposal-generator rebuild. Paid spend at most USD 15 across this task.

This is a review contract, not an active execution run. Review the published board, then send a later explicit Launch. Before creating exactly one Sol-6 xhigh orchestrator, read the latest prompt and this board’s comments/inline rewrites, record the check including zero comments, apply material feedback and republish for review.

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 · scope locked for reviewRefined contract

Calendar-only contract prepared from current answers. Proposal rebuild is deferred. The × note action and checkbox share one persistent lead setting.

No executor exists yet. Internal contract reviews are not implementation launches.

Source basis and read set

Latest user answers take precedence over historical plans. Private transcripts, prompts, review receipts and source paths stay in the local handoff.

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.

Current calendar staging · Deferred proposal reference

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 to prepare this board. Review the pink assumptions, especially one work period per lead and the narrow-screen sidebar behavior.

A broken existing proposal service blocks only its integration criterion. It does not justify a fake success or rebuilding the generator. Finish independent calendar work and report the exact dependency.

Resume point: review this board, reconcile comments, then await a later explicit Launch. Current state: preparation complete, implementation not started.

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. Application implementation has not started, and no application criterion is marked passed.