# Task Group: car-parts-comparator frontend architecture refactor scope: Behavior-preserving Angular frontend refactors in `/home/Messier82/projects/car-parts-comparator-poc`; use for root-component/template decomposition, feature ownership boundaries, regression-test relocation, and verification/commit follow-through. applies_to: cwd=/home/Messier82/projects/car-parts-comparator-poc; reuse_rule=safe for similar frontend-architecture follow-up work in this repo, but keep exact component lists, artifact hashes, and commit ids tied to the current checkout. ## Task 1: Audit frontend complexity and choose refactor boundaries ### rollout_summary_files - rollout_summaries/2026-07-18T18-02-07-JoMc-frontend_architecture_refactor_feature_components.md (cwd=/home/Messier82/projects/car-parts-comparator-poc, rollout_path=/home/Messier82/.codex/sessions/2026/07/18/rollout-2026-07-18T21-02-07-019f7664-888c-7102-9567-ebc90973ca44.jsonl, updated_at=2026-07-21T12:12:05+00:00, thread_id=019f7664-888c-7102-9567-ebc90973ca44, architecture audit established presentation-first refactor boundaries before edits) ### keywords - car-parts-comparator-poc, Angular, frontend architecture, app.html, app.ts, FRONTEND-ARCHITECTURE.md, presentation ownership, feature boundaries ## Task 2: Extract feature components and preserve behavior ### rollout_summary_files - rollout_summaries/2026-07-18T18-02-07-JoMc-frontend_architecture_refactor_feature_components.md (cwd=/home/Messier82/projects/car-parts-comparator-poc, rollout_path=/home/Messier82/.codex/sessions/2026/07/18/rollout-2026-07-18T21-02-07-019f7664-888c-7102-9567-ebc90973ca44.jsonl, updated_at=2026-07-21T12:12:05+00:00, thread_id=019f7664-888c-7102-9567-ebc90973ca44, extracted feature-owned Angular components while keeping behavior stable) ### keywords - SearchInputComponent, StoreProgressComponent, SearchResultsComponent, PurchasePlanComponent, DiagnosticsDialogComponent, SolveOverlayComponent, search-history.presentation.ts, tests/engine.test.ts, feature templates ## Task 3: Verify the refactor and commit it ### rollout_summary_files - rollout_summaries/2026-07-18T18-02-07-JoMc-frontend_architecture_refactor_feature_components.md (cwd=/home/Messier82/projects/car-parts-comparator-poc, rollout_path=/home/Messier82/.codex/sessions/2026/07/18/rollout-2026-07-18T21-02-07-019f7664-888c-7102-9567-ebc90973ca44.jsonl, updated_at=2026-07-21T12:12:05+00:00, thread_id=019f7664-888c-7102-9567-ebc90973ca44, passed frontend/desktop/android packaging checks and ended in a focused commit) ### keywords - npm run lint, npm test, npm run build:web, npm run typecheck, npm run smoke:desktop, npm run package:android:debug, aapt dump badging, adb devices, 48207af ## User preferences - When the user said: "I feel like it could to a lot of refactoring. Like, for example, app.html is large. So I want you to analyze the whole frontend and determine the places that need refactor and do it" -> start similar frontend refactors with a real architecture audit and boundary selection, not a cosmetic split or formatting pass. [Task 1] - When the user calls out a large root file such as `app.html` -> optimize for shrinking root-component/template ownership and moving UI into feature-owned boundaries instead of re-splitting already cohesive core services. [Task 1][Task 2] - When the user later says "commit" after a verified refactor -> finish the implementation with verification and a Git commit instead of stopping at a summary. [Task 1][Task 3] ## Reusable knowledge - `web/src/app/app.html` and `web/src/app/app.ts` were the real presentation bottlenecks; the core services/domain modules were already relatively cohesive and test-covered, so the highest-leverage refactor boundary was presentation ownership. [Task 1] - The extraction boundaries that worked were search/history, store progress, search results, purchase plan, diagnostics dialog, and solve overlay. `FRONTEND-ARCHITECTURE.md` is the durable source of truth for those ownership boundaries. [Task 1][Task 2] - The root `App` now acts as shell/coordinator while feature-owned components own transient UI state and templates; keep future template-structure tests aligned to the feature templates rather than the old monolithic shell. [Task 2] - Feature-specific presentation logic can move into small pure helpers plus deterministic tests, as shown by `web/src/app/features/search-input/search-history.presentation.ts` and `search-history.presentation.spec.ts`. [Task 2] - The verification path that worked for a large behavior-preserving frontend refactor was `npm run lint`, `npm test`, `npm run build:web`, `npm run typecheck`, `npm run smoke:desktop`, and `npm run package:android:debug`; `aapt dump badging` then confirmed APK metadata. [Task 3] - Desktop smoke still matters after Angular presentation extraction because it exercises the Electron shell geometry and persistence bridges, not just template compilation. [Task 3] ## Failures and how to do differently - Symptom: a frontend refactor stalls in the monolithic root component. Cause: editing begins before the actual ownership boundaries are measured. Fix: quantify the root surface area first and confirm whether the real problem is presentation ownership or domain cohesion. [Task 1] - Symptom: regression tests fail after component extraction. Cause: tests still point at the old root template owner. Fix: move the assertions to the new feature templates, such as `web/src/app/features/search-results/search-results.html` and `web/src/app/features/purchase-plan/purchase-plan.html`. [Task 2] - Symptom: Android verification looks complete after packaging. Cause: APK build success is treated as equivalent to live-device validation. Fix: keep `adb`/device execution separate from packaging success; in this environment, ADB daemon/device access may be unavailable even when the APK is valid. [Task 2][Task 3] # Task Group: car-parts-comparator diagnostics UI refinement and release follow-through scope: Hidden diagnostics/reporting affordances, retrievable failure evidence, rebuilds, and commit handoff in `/home/Messier82/projects/car-parts-comparator-poc`. applies_to: cwd=/home/Messier82/projects/car-parts-comparator-poc; reuse_rule=safe for similar diagnostics/reporting UI follow-up work in this repo, but keep the exact artifact outputs and commit ids tied to the current checkout. ## Task 1: Hide diagnostics UI and commit the refinement ### rollout_summary_files - rollout_summaries/2026-07-18T12-03-57-VlUt-autodoc_diagnostics_ui_hidden_and_committed.md (cwd=/home/Messier82/projects/car-parts-comparator-poc, rollout_path=/home/Messier82/.codex/sessions/2026/07/18/rollout-2026-07-18T15-03-57-019f751c-9dee-7e52-a4d2-6dddb1d7d6c9.jsonl, updated_at=2026-07-18T18:01:59+00:00, thread_id=019f751c-9dee-7e52-a4d2-6dddb1d7d6c9, diagnostics affordance was demoted to an icon-only contextual trigger and then committed) ### keywords - car-parts-comparator-poc, diagnostics, Diagnostika, Details, hidden UI, icon-only trigger, search-diagnostics.ts, cdcf21e, package:android:debug, package:win:portable ## User preferences - When the user said: "Now we need to refine the diagnostics feature. Right now its too apparent. It should be more hidden" -> default similar diagnostics/reporting UI to subtle, contextual controls instead of obvious labels or global links. [Task 1] - When the user later said "commit" -> finish the verified implementation with a Git commit instead of stopping at a summary. [Task 1] ## Reusable knowledge - The durable UI pattern here is no global diagnostics entry point: only a small muted info icon on store chips that actually have failure/check-required history. [Task 1] - Diagnostic evidence remains retrievable after a later successful retry, so the affordance can stay hidden without losing access to the session details. [Task 1] - The concrete implementation anchors are `web/src/app/app.html`, `web/src/app/app.ts`, `web/src/app/core/search.service.ts`, `web/src/app/core/strings.ts`, and `web/src/app/core/search-diagnostics.ts`. [Task 1] - The verification/build path used before the commit was `npm run test:web`, `npm run build:web`, `npm run lint`, `npm run typecheck`, `npm run package:android:debug`, and `npm run package:win:portable`. [Task 1] - The final commit for this refinement was `cdcf21e fix: harden store challenge handling and diagnostics`. [Task 1] ## Failures and how to do differently - Symptom: a diagnostics/reporting feature feels too obvious in the product UI. Cause: the first pass used a visible text link/global entry point. Fix: start with low-prominence, contextual affordances and only show them when there is actual diagnostic history to inspect. [Task 1] - Symptom: a hidden diagnostics affordance risks losing debuggability. Cause: the session/report retention model is coupled to the visible control. Fix: preserve retrievability in the service layer so the UI can stay subtle. [Task 1] - Symptom: the user asks for a commit but the worktree is left dirty. Cause: the run stops after describing the change. Fix: verify, rebuild the affected artifacts, then stage and commit. [Task 1] # Task Group: car-parts-comparator shell layout, glass header, and rebuilt installables scope: Shell/header layout fixes, visible glass-header styling, desktop smoke verification, and final package rebuilds in `/home/Messier82/projects/car-parts-comparator-poc`. applies_to: cwd=/home/Messier82/projects/car-parts-comparator-poc; reuse_rule=safe for similar shell-layout, sticky-header, and packaging follow-up work in this repo, but treat visual behavior as checkout-specific until rebuilt and reverified. ## Task 1: Fix desktop scrollbar/header overlap ### rollout_summary_files - rollout_summaries/2026-07-17T06-56-28-IFEt-car_parts_comparator_shell_glass_header_scrollbar_fix.md (cwd=/home/Messier82/projects/car-parts-comparator-poc, rollout_path=/home/Messier82/.codex/sessions/2026/07/17/rollout-2026-07-17T09-56-28-019f6edc-be38-74c0-87b9-6c7692d64e71.jsonl, updated_at=2026-07-17T12:52:17+00:00, thread_id=019f6edc-be38-74c0-87b9-6c7692d64e71, fixed the desktop shell scroll region and added smoke coverage) ### keywords - car-parts-comparator-poc, scrollbar, header, app-shell, app-content-scroll, desktop/main.ts, scrollLocked, overlay geometry, electron smoke ## Task 2: Add glass header, then correct ineffective transparency ### rollout_summary_files - rollout_summaries/2026-07-17T06-56-28-IFEt-car_parts_comparator_shell_glass_header_scrollbar_fix.md (cwd=/home/Messier82/projects/car-parts-comparator-poc, rollout_path=/home/Messier82/.codex/sessions/2026/07/17/rollout-2026-07-17T09-56-28-019f6edc-be38-74c0-87b9-6c7692d64e71.jsonl, updated_at=2026-07-17T12:52:17+00:00, thread_id=019f6edc-be38-74c0-87b9-6c7692d64e71, corrected a blur/opacity change that still looked opaque) ### keywords - glass header, backdrop-filter, opacity, color-mix, translucent header, still non transparent, headerBackground, headerBackdropFilter ## Task 3: Rebuild installables and commit the final UI fix ### rollout_summary_files - rollout_summaries/2026-07-17T06-56-28-IFEt-car_parts_comparator_shell_glass_header_scrollbar_fix.md (cwd=/home/Messier82/projects/car-parts-comparator-poc, rollout_path=/home/Messier82/.codex/sessions/2026/07/17/rollout-2026-07-17T09-56-28-019f6edc-be38-74c0-87b9-6c7692d64e71.jsonl, updated_at=2026-07-17T12:52:17+00:00, thread_id=019f6edc-be38-74c0-87b9-6c7692d64e71, rebuilt the Windows portable exe and Android apk after the corrected UI change) ### keywords - package:win:portable, package:android:debug, portable exe, android apk, 362a007, rebuilt artifacts, glass header, shell fix ## User preferences - When the user reports a shell bug like "main scrollbar goes under the header when the handler is up" and adds "worth checking others aswell" -> inspect the shared shell pattern across desktop first and then other host variants that reuse it, instead of assuming it is isolated to one surface. [Task 1] - When the user asks: "Let's add a opacity to header and a blur filter for a more modern look" -> default to a genuinely translucent blurred header treatment, not just an opaque color tweak. [Task 2] - When the user corrects a visual change with "still non transparent" -> do not trust a rebuild alone; verify that the effect is actually visible in runtime geometry/computed styles or a screenshot. [Task 2] - When the user says "commit" after the fix is ready -> finalize the rebuilt artifacts and commit the working tree instead of stopping at a patch summary. [Task 3] ## Reusable knowledge - The working shell fix was structural: make `.app-shell` a full-height relative container and move scrolling into `.app-content-scroll`; a sticky header on a page-owned scrollbar still lets the scrollbar travel behind the header. [Task 1] - Overlay/body lock behavior still belongs in `document.body.style.overflow`, but the final implementation routes it through a computed `scrollLocked` signal so shell scroll ownership stays consistent. [Task 1] - `desktop/main.ts` is a reliable verification hook for this shell: it can assert `headerBottom`, `contentTop`, `contentBottom`, `contentOverflowY`, overlay placement, header alpha, and `backdropFilter` after Electron boots. [Task 1][Task 2] - The visible glass header used `background-color: color-mix(in oklch, var(--card) 72%, transparent)` plus `backdrop-filter: blur(16px) saturate(1.3)`, but that only looks correct when content and the scrollbar track actually sit beneath the header. [Task 2] - After UI fixes of this kind, the successful packaging commands were `npm run package:win:portable` and `npm run package:android:debug`, with final artifacts at `release/Car-Parts-Comparator-0.1.3-portable-x64.exe` and `android/app/build/outputs/apk/debug/app-debug.apk`. [Task 3] ## Failures and how to do differently - Symptom: the scrollbar still runs under the header after a sticky-header change. Cause: the page still owns the scroll region. Fix: move scrolling into a dedicated content container such as `.app-content-scroll`. [Task 1] - Symptom: a glass/blur header looks unchanged or opaque. Cause: the layer behind it is flat/static, so the translucency has nothing visible to blend with. Fix: correct the layering/scroll relationship first, then verify computed style and actual visual effect. [Task 2] - Symptom: packaged artifacts do not match the final UX. Cause: packaging happened before the last visual correction. Fix: rebuild the deliverables after the user approves the final interaction/look. [Task 3] # Task Group: car-parts-comparator search-history spec-first feature workflow scope: Search-history functional spec, implementation, analytics removal, persistence contracts, and packaging/verification in `/home/Messier82/projects/car-parts-comparator-poc`. applies_to: cwd=/home/Messier82/projects/car-parts-comparator-poc; reuse_rule=safe for similar spec-first product work and cross-platform persistence features in this repo, but keep packaged artifact hashes and exact command outputs tied to the current checkout. ## Task 1: Functional specification for search history ### rollout_summary_files - rollout_summaries/2026-07-16T11-53-31-dBUY-search_history_spec_implementation_commit.md (cwd=/home/Messier82/projects/car-parts-comparator-poc, rollout_path=/home/Messier82/.codex/sessions/2026/07/16/rollout-2026-07-16T14-53-31-019f6ac6-58d0-75f0-a7b9-d9e0a7889bd8.jsonl, updated_at=2026-07-17T06:56:25+00:00, thread_id=019f6ac6-58d0-75f0-a7b9-d9e0a7889bd8, approved search-history spec before implementation) ### keywords - SEARCH-HISTORY-FUNCTIONAL-SPEC.md, search history, focus-driven history, input focus, Tab prefill, canonical deduplication, measurement removal, Meklēšanas vēsture ## Task 2: Implement, verify, and commit the feature ### rollout_summary_files - rollout_summaries/2026-07-16T11-53-31-dBUY-search_history_spec_implementation_commit.md (cwd=/home/Messier82/projects/car-parts-comparator-poc, rollout_path=/home/Messier82/.codex/sessions/2026/07/16/rollout-2026-07-16T14-53-31-019f6ac6-58d0-75f0-a7b9-d9e0a7889bd8.jsonl, updated_at=2026-07-17T06:56:25+00:00, thread_id=019f6ac6-58d0-75f0-a7b9-d9e0a7889bd8, shipped cross-platform persistence, removed measurement plumbing, rebuilt artifacts, and committed) ### keywords - /api/search-history, SQLite, Capacitor Preferences, Electron JSON storage, browser fallback, pending-change marker, measurement.ts, statsPage.ts, UTM removal, 522250c ## User preferences - For significant features, the user said: "I want to implement a feature. We shall start from the functional docs and only after finalizing those, proceeding." -> keep this repo’s feature work spec-first and do not start implementation before approval. [Task 1] - When a separate history control was proposed, the user corrected: "I think separate button to view history is unnecessary. In the industry, the history is shown on input focus" -> default search history to the conventional focus-driven autocomplete pattern, not a dedicated button/icon. [Task 1] - For keyboard interaction, the user said: "if keyboard was used to select the item, pressing tab will just prefill it" -> preserve Tab-as-prefill and Enter/click-as-search semantics in similar picker/history flows. [Task 1] - When analytics came up, the user asked "what measurement?" and then said "I think we can safely remove all of it. We don't really need it" -> do not preserve search/click measurement plumbing as a product requirement unless the user explicitly reintroduces it. [Task 1] - After the spec was approved, the user said: "Go ahead with the implementation" and later "Commit" -> once the contract is finalized, proceed straight through implementation, verification, packaging, and commit. [Task 2] ## Reusable knowledge - The approved spec is `SEARCH-HISTORY-FUNCTIONAL-SPEC.md`: 20 distinct canonical queries, most-recent-first ordering, focus-driven display, backend persistence plus browser fallback, and no separate measurement/analytics requirement. [Task 1] - The final UX is: focusing an empty search field opens history; typing closes it; clearing while focused reopens it; there is no separate history button; the input is not auto-focused on page load. [Task 1][Task 2] - Hosted web persistence uses SQLite-backed `/api/search-history`; desktop uses an atomic JSON file under `app.getPath("userData")`; Android uses Capacitor Preferences; browser mode keeps a local fallback store. [Task 2] - The durable sync behavior needed a pending-change marker so unsynchronized local deletes/adds survive restarts instead of being overwritten by stale backend state. [Task 2] - The measurement pipeline was removed entirely in this feature: `measurement.ts`, `statsPage.ts`, `/api/searches`, `/stats`, `sid` plumbing, and link-decoration / UTM code were deleted. [Task 2] - The verification set that mattered here was `npm test`, `npm run test:web`, `npm run typecheck`, `npm run lint`, `npm run build:web`, `npm run build:desktop`, `npm run build:android`, and `npm run check:engine-browser`, followed by final packaging with `npm run package:win:portable` and `npm run package:android:debug`. [Task 2] ## Failures and how to do differently - Symptom: the spec drifts toward a dedicated history action. Cause: the conventional focus-driven interaction was not settled early. Fix: ask up front whether history should open on input focus and whether any separate control is acceptable. [Task 1] - Symptom: keyboard selection behavior is unclear. Cause: Enter vs Tab semantics were underspecified. Fix: specify those semantics explicitly in the functional doc before implementation. [Task 1] - Symptom: packaged binaries have to be rebuilt late. Cause: artifacts were built before the final UX model was approved. Fix: hold packaging until after the interaction model is final. [Task 2] - Symptom: deleted history reappears after restart. Cause: stale backend state overwrites local removals. Fix: use a retry-safe pending-change marker for unsynchronized deletes as well as saves. [Task 2] # Task Group: car-parts-comparator Windows desktop challenge flow and walled-store timing scope: Windows desktop challenge-window loops, walled-store readiness checks, Trodo timing, and packaged desktop verification in `/home/Messier82/projects/car-parts-comparator-poc`. applies_to: cwd=/home/Messier82/projects/car-parts-comparator-poc; reuse_rule=safe for similar Electron desktop challenge/session bugs in this repo, but live store behavior and exact repro inputs remain time-sensitive. ## Task 1: Diagnose the Windows challenge-window loop and Trodo zero-result behavior ### rollout_summary_files - rollout_summaries/2026-07-16T09-05-41-dr8y-windows_challenge_flow_trodo_session_fix.md (cwd=/home/Messier82/projects/car-parts-comparator-poc, rollout_path=/home/Messier82/.codex/sessions/2026/07/16/rollout-2026-07-16T12-05-41-019f6a2c-b130-7a80-b133-70910579ae76.jsonl, updated_at=2026-07-16T11:35:42+00:00, thread_id=019f6a2c-b130-7a80-b133-70910579ae76, fixed the Windows desktop challenge loop and Trodo timing issue, then committed) ### keywords - Windows, Electron, challenge_required, BrowserWindow, backgroundThrottling, waitForSelector, Trodo, rd24, euautodalas, 34118831822, 51137497285, 396be13 ## User preferences - When platform evidence is ambiguous, the user corrected: "It wasnt android. It was windows. Why did you assume that it was Android? You should've asked" -> ask which platform is affected before making platform-specific edits. [Task 1] - When the repro was still vague, the user supplied `34118831822` and `51137497285` -> request the exact part numbers/query before deciding whether the issue is session timing, platform-specific, or store-specific. [Task 1] - After the fix worked, the user said "Commit this" -> once the packaged verification is clean, commit the result instead of stopping at explanation. [Task 1] ## Reusable knowledge - Desktop challenge/session handling for this repo lives in `desktop/electronBrowserHub.ts`; the durable fix was to trust rendered challenge markers and store-specific readiness, not a 403/navigation status alone. [Task 1] - For RD24 and EUAutodalas, `fetchPageHtml(..., { waitForSelector })` was the right safeguard so the app does not accept a rendered challenge shell before result cards actually exist. [Task 1] - Hidden Electron windows needed `backgroundThrottling: false` so challenge/session scripts continued while the window stayed hidden. [Task 1] - Trodo uses a JSON envelope; a valid no-result is still `[{"products":[]}]`, while malformed or transitional payloads should keep the verification window pending instead of being treated as a clean empty result. [Task 1] - The validation path that mattered here was `npm run build:desktop`, `npm test`, portable Windows packaging, and then live probes in the packaged app using the exact repro inputs. [Task 1] ## Failures and how to do differently - Symptom: the fix goes into the wrong platform codepath. Cause: ambiguous symptoms were assumed to be Android. Fix: ask the user which platform is failing before editing. [Task 1] - Symptom: the challenge window still loops after a first desktop fix. Cause: the browser re-navigates too aggressively and treats a transient loaded-looking state as cleared. Fix: rely on rendered markers, avoid the extra immediate navigation, and require stable readiness. [Task 1] - Symptom: Trodo shows false zero-result success after the challenge vanishes. Cause: the code treats challenge disappearance as enough, without a usable JSON response. Fix: keep Trodo pending until the actual JSON search payload is valid. [Task 1] - Symptom: packaging appears to finish but the portable `.exe` is missing or stale. Cause: the build was assumed complete before the artifact was fully written. Fix: verify the packaged artifact path after the packaging run finishes. [Task 1] # Task Group: car-parts-comparator Android app showcase, review fixes, and release hardening scope: Android solve-view showcase work, native UI polish, review-driven fixes, versioning hardening, clickout decoration boundaries, and final cleanup in `/home/Messier82/projects/car-parts-comparator-poc`. applies_to: cwd=/home/Messier82/projects/car-parts-comparator-poc; reuse_rule=safe for similar Android app UI/release workflow in this repo, but treat review file paths and APK metadata as rollout-specific evidence. ## Task 1: Challenge-view showcase build for Android ### rollout_summary_files - rollout_summaries/2026-07-15T07-24-28-NdSN-phase_g_android_showcase_review_hardening.md (cwd=/home/Messier82/projects/car-parts-comparator-poc, rollout_path=/home/Messier82/.codex/sessions/2026/07/15/rollout-2026-07-15T10-24-28-019f64a9-abaa-7262-8beb-13203e59d651.jsonl, updated_at=2026-07-16T07:19:43+00:00, thread_id=019f64a9-abaa-7262-8beb-13203e59d651, built and polished the Android challenge-view showcase) ### keywords - android, WebViewFetcherPlugin, solve view, showcase APK, dark mode, vector icon, ic_close.xml, solve_view_enter.xml, solve_view_exit.xml ## Task 2: Phase G review fixes and Android release hardening ### rollout_summary_files - rollout_summaries/2026-07-15T07-24-28-NdSN-phase_g_android_showcase_review_hardening.md (cwd=/home/Messier82/projects/car-parts-comparator-poc, rollout_path=/home/Messier82/.codex/sessions/2026/07/15/rollout-2026-07-15T10-24-28-019f64a9-abaa-7262-8beb-13203e59d651.jsonl, updated_at=2026-07-16T07:19:43+00:00, thread_id=019f64a9-abaa-7262-8beb-13203e59d651, fixed review findings, hardened Android versioning, and cleaned up artifacts before commit) ### keywords - phase-g-review, build.gradle, github.run_number, aapt dump badging, search.gateway, outbound decoration, carparts parser, 64f8e84, bugreport zip cleanup ## User preferences - When the user asked for "a build that opens the browser view for a challenge" with "a random store page" -> they wanted a visual showcase build rather than a hidden/internal harness. [Task 1] - When the user said the close button should be "black/dark grey" and later that the icon was "big, grey ... and blurry" -> default native solve chrome toward crisp vector assets and design-faithful colors, not tinted framework defaults. [Task 1] - When the user said "Keep in mind the dark mode" -> make Android UI polish theme-aware by default. [Task 1] - When the user asked for "nice modern animations" -> restrained native-feeling open/close motion is welcome when polishing this solve UI. [Task 1] - When the user later said "remove the force open" -> treat showcase-only auto-open plumbing as temporary and remove it from the normal build when asked. [Task 1] - When the user provided a review file path, they expected the findings checked against the real code and fixed rather than assumed away, and when they said "Commit" they wanted those fixes folded into one coherent commit. [Task 2] - When the user said "You can remove those" about bug-report ZIPs -> clean up generated artifacts after the rollout is complete. [Task 2] ## Reusable knowledge - The Android solve UI lives in `android/app/src/main/java/lv/carp/partscomparator/WebViewFetcherPlugin.java`; animation hooks are `android/app/src/main/res/anim/solve_view_enter.xml` and `solve_view_exit.xml`. [Task 1] - The crisp close button should use a vector asset such as `android/app/src/main/res/drawable/ic_close.xml`, not `android.R.drawable.ic_menu_close_clear_cancel`. [Task 1] - The normal debug APK build path used successfully here was `npm run package:android:debug`, producing `android/app/build/outputs/apk/debug/app-debug.apk`. [Task 1] - `web/src/app/core/search.gateway.ts` is the right boundary for native clickout decoration; decoration should happen in one layer only. [Task 2] - `android/app/build.gradle` now validates version strings and uses a monotonic CI override via `ANDROID_VERSION_CODE=${{ github.run_number }}`; `aapt dump badging android/app/build/outputs/apk/debug/app-debug.apk` was the verification used for `versionCode` and `versionName`. [Task 2] - `src/adapters/carparts.ts` now preserves offers whose rendered heading ends with the brand, using the canonical searched part number as fallback when the displayed part number is missing. [Task 2] ## Failures and how to do differently - Symptom: the close icon still looks low-quality after recoloring. Cause: a blurred framework asset is being tinted. Fix: replace the asset with a real vector icon instead of only changing tint. [Task 1] - Symptom: demo-only auto-open behavior leaks into the normal app. Cause: showcase plumbing was left in place after visual verification. Fix: remove force-open behavior once the user no longer wants the demo harness. [Task 1] - Symptom: review fixes miss real regressions. Cause: the review file was not checked against the actual code. Fix: inspect the review file, validate the findings in repo, then patch and retest. [Task 2] - Symptom: Android versioning becomes brittle or collision-prone. Cause: versionCode is derived too loosely from semver. Fix: fail fast on unsupported version shapes and keep CI on a monotonic override. [Task 2] - Symptom: outbound links get double-decorated or reserialized. Cause: both the gateway and the native layer decorate URLs. Fix: keep one canonical decoration layer and make all others pass-through only. [Task 2] # Task Group: car-parts-comparator purchase-plan and refresh audit workflow scope: Feature planning and implementation plus refresh/parsing audits in `/home/Messier82/projects/car-parts-comparator-poc`; use for `Pirkumu plāns` work, stale-offer UX, exact-refresh behavior, and cross-store availability normalization. applies_to: cwd=/home/Messier82/projects/car-parts-comparator-poc; reuse_rule=safe for similar feature and refresh-parsing work in this repo, but keep store-live behavior and challenge-gated verification tied to the current checkout and live store state. ## Task 1: Purchase-plan spec, implementation, and commit ### rollout_summary_files - rollout_summaries/2026-07-13T11-47-31-K7uO-purchase_plan_and_cross_store_refresh_audit.md (cwd=/home/Messier82/projects/car-parts-comparator-poc, rollout_path=/home/Messier82/.codex/sessions/2026/07/13/rollout-2026-07-13T14-47-31-019f5b4d-c79f-7172-96a4-80e10b3959e2.jsonl, updated_at=2026-07-14T13:08:28+00:00, thread_id=019f5b4d-c79f-7172-96a4-80e10b3959e2, approved spec-first feature rollout ending in committed implementation) ### keywords - car-parts-comparator-poc, Pirkumu plāns, purchase-plan, localStorage, PURCHASE-PLAN-FUNCTIONAL-SPEC.md, PURCHASE-PLAN-IMPLEMENTATION-PLAN.md, stale-data banner, directRefresh, deterministic part markers, b28f1f8283c833b28e01c619bbe0632a92acbc71 ## Task 2: Cross-store refresh false-positive audit and fix ### rollout_summary_files - rollout_summaries/2026-07-13T11-47-31-K7uO-purchase_plan_and_cross_store_refresh_audit.md (cwd=/home/Messier82/projects/car-parts-comparator-poc, rollout_path=/home/Messier82/.codex/sessions/2026/07/13/rollout-2026-07-13T14-47-31-019f5b4d-c79f-7172-96a4-80e10b3959e2.jsonl, updated_at=2026-07-14T13:08:28+00:00, thread_id=019f5b4d-c79f-7172-96a4-80e10b3959e2, cross-store live audit and normalization fix committed with the feature work) ### keywords - car-parts-comparator-poc, directRefresh, availability normalization, inStock, Handler.lv, IC24, noVNC, partsale, xparts, eoltas, carparts, trodo, rd24, euautodalas, autodoc, tests/directRefresh.test.ts ## User preferences - When adding a significant feature, the user said: "The plan is to write up a functional spec first and then implement it after it has been verified and finalized." -> keep feature work spec-first until the spec is approved. [Task 1] - For this feature family, the user said: "Name: Pirkumu plans is good." -> default to the Latvian `Pirkumu plāns` terminology instead of renaming it into generic cart language. [Task 1] - When the model of the feature was still drifting, the user clarified: "they are alternatives for consideration ... maybe one store will have other, cheaper products and the overall order will be larger which is preferrable" -> model one chosen offer per part requirement plus alternatives, not a flat cart of all offers. [Task 1] - For stale data UX, the user asked: "show a banner that the offers may be outdated with a button to refresh? What do you think?" -> prefer an explicit stale-data banner with manual refresh over auto-refresh-on-open for similar flows. [Task 1] - For result ordering, the user asked: "selectable out of all options" -> make store/order sorting selectable and persisted rather than fixed. [Task 1] - When a refresh bug surfaced in one store, the user corrected scope: "You need to test all the stores for such a case and see how it behaves and fix if needed" -> audit every enabled store for this bug class, not just the first failing one. [Task 2] - For refresh/parsing regressions, the user wanted the issue fixed rather than merely explained -> treat live verification plus regression coverage as required before closing similar work. [Task 2] ## Reusable knowledge - The approved purchase-plan feature is browser-persistent local storage under `car-parts-comparator.purchase-plan`, using versioned JSON and a chosen-offer-versus-alternative-candidate model. [Task 1] - The UI has two views of the same data: orders grouped by store and parts/alternatives grouped by requirement; only chosen offers count toward store subtotals and the grand total. [Task 1] - Refresh behavior is explicit/manual: show an "Offers may be outdated" banner when snapshots are old or unresolved, and bypass the ordinary 15-minute search-result cache only when running a direct refresh. [Task 1] - Matching-part markers are deterministic from part identity and should stay stable across reloads. [Task 1] - `availability` is display-only; change detection should compare structured stock state (`inStock`) and ignore wording, punctuation, rolling delivery dates, and disclaimer churn. [Task 2] - Handler.lv product pages are a marketplace of supplier rows, so exact-refresh must normalize the selected row, keep shipping date separate from availability, and avoid treating delivery-note-only changes as offer changes. [Task 2] - Unknown schema.org availability values should remain unknown rather than being forced to out-of-stock. [Task 2] - IC24 exact-refresh can require the warm resident browser/noVNC human-challenge path; live verification is still possible after the human solve, and search-to-refresh parity should be confirmed afterward. [Task 2] - Relevant implementation anchors for this rollout are `src/core/directRefresh.ts`, `web/src/app/core/purchase-plan.domain.ts`, `tests/directRefresh.test.ts`, `tests/handler.test.ts`, and `web/src/app/core/purchase-plan.domain.spec.ts`. [Task 1][Task 2] ## Failures and how to do differently - Symptom: the spec keeps changing because "keep both" is ambiguous. Cause: alternatives were not defined clearly as purchases vs comparison candidates. Fix: settle that semantics question before coding and keep the plan centered on part requirements with one chosen offer plus alternatives. [Task 1] - Symptom: the implementation drifts toward a standard cart. Cause: the chosen-offer/alternative model was flattened too early. Fix: preserve the requirement-first model in both the data shape and the UI. [Task 1] - Symptom: refresh fixes solve only one storefront. Cause: the first fix was scoped narrowly to Handler. Fix: convert the bug into a cross-store audit and apply store-specific normalization only where the generic structured-stock rule is insufficient. [Task 2] - Symptom: refresh shows false "changed" states when price and stock did not really change. Cause: raw availability text and delivery-note churn were treated as change signals. Fix: ignore display-only text churn and compare price plus structured stock state. [Task 2] - Symptom: unknown schema.org availability values degrade into false out-of-stock changes. Cause: unknown availability was normalized too aggressively. Fix: preserve unknown as unknown. [Task 2] - Symptom: combined browser probes skip or challenge stores. Cause: live storefront verification is uneven across a full matrix, especially with IC24. Fix: split probes per store and use recorded fixtures for exact-product URLs where needed. [Task 2] # Task Group: service-book Gradle Managed Device rendering defaults scope: Repo-specific default for managed-device rendering mode in `/home/Messier82/projects/service-book`; use when editing GMD commands, CI wiring, docs, or verification notes. applies_to: cwd=/home/Messier82/projects/service-book; reuse_rule=safe for similar Gradle Managed Device work in this repo; treat rendering exceptions as environment-specific and temporary unless the user explicitly asks for them. ## Task 1: Consolidate the current GMD rendering default, active ### rollout_summary_files - extensions/ad_hoc/notes/2026-05-27T04-06-22Z-service-book-gmd-hardware-rendering.md (cwd=/home/Messier82/projects/service-book, rollout_path=extension note, updated_at=2026-05-27T04:06:22Z, thread_id=n/a, authoritative ad-hoc note for the current managed-device rendering default) ### keywords - Gradle Managed Device, GMD, hardware rendering, swiftshader_indirect, service-book, CI wiring, verification notes ## Reusable knowledge - In `/home/Messier82/projects/service-book`, default any Gradle Managed Device run to hardware rendering when writing commands, docs, CI wiring, or verification guidance. [ad-hoc note] ## Failures and how to do differently - Symptom: a proposed GMD command or workflow defaults to `swiftshader_indirect` or another software renderer. Cause: stale assumptions or generic emulator guidance. Fix: switch the default back to hardware rendering and mention software rendering only as an explicit temporary fallback for environment limitations. [ad-hoc note]