winter-super-cli 2026.5.24 → 2026.5.26

package/resources/local/codex/memories/rollout_summaries/2026-04-22T06-49-49-R8yZ-web_book_user_portal_and_lint_fixes.md

@@ -1,82 +0,0 @@
-thread_id: 019db3f3-c00e-7893-b04e-d47132138171
-updated_at: 2026-04-22T08:22:10+00:00
-rollout_path: C:\Users\PHUCANSOLUTIONS\.codex\sessions\2026\04\22\rollout-2026-04-22T13-49-49-019db3f3-c00e-7893-b04e-d47132138171.jsonl
-cwd: \\?\E:\dev\web-book
-
-# User-facing account portal was added, with booking-history and refund-request flows consolidated into a single `/tai-khoan` page, while the user separately asked to fix existing lint errors afterward.
-
-Rollout context: repo root `e:\dev\web-book\web-book-app`; app is a Next.js project with MongoDB-backed booking/refund forms and an admin dashboard at `/quan-ly-du-lieu`. The user wanted the refund-request and purchase-history experience to live inside a user page/portal rather than as separate standalone pages.
-
-## Task 1: Build a user portal for booking history + refund requests
-
-Outcome: success
-
-Preference signals:
-- the user asked to make “yêu cầu hoàn tiền và lịch sử mua vé làm phần đăng nhập cho user luôn quản lý trong trang user luôn” and to let refund requests “fetch ra cho chọn hoàn tiền hoặc gửi form yêu cầu hoàn tiền” -> the user wants a single user-facing portal, not separate scattered pages, and wants refund to be initiated either by selecting a prior booking or by submitting a manual request.
-- earlier in the rollout the user had already objected to role `user` being able to manage admin data; this reinforced that user-facing features should be separate from admin management, not mixed into `/quan-ly-du-lieu`.
-
-Key steps:
-- introduced a shared `src/lib/user-portal.ts` with:
-  - `web_book_user_session` cookie token creation/parsing,
-  - phone/reference normalization,
-  - booking/refund history queries from MongoDB,
-  - shared date/status formatting helpers.
-- created `/tai-khoan` as the main user portal page:
-  - login by phone number (and optional reference code if provided),
-  - session stored in a dedicated user cookie,
-  - fetches the user’s own booking history and refund history,
-  - allows choosing an existing booking to prefill and submit a refund request,
-  - also provides a manual refund form for tickets not found in history.
-- kept `/lich-su-mua-ve` and `/yeu-cau-hoan-tien` as redirect shims into `/tai-khoan` so old links still work.
-- updated booking/refund submit routes so redirects include a `ref` reference code in the query string, making later portal lookup possible.
-- updated navigation/footer/utility links to point to `/tai-khoan` instead of the old standalone pages.
-
-Failures and how to do differently:
-- the first implementation used separate public pages for history/refund; the user then asked to merge this into the user login area. Future similar changes should prefer a single portal page if the user asks for “trong trang user luôn”.
-- the old routes are now just redirect wrappers; if a future task needs a different UX, `/tai-khoan` should be treated as the canonical surface.
-
-Reusable knowledge:
-- `PUBLIC_SITE_URL`-based redirects on form submit now preserve a `ref` query parameter for booking/refund requests.
-- user portal session cookie name: `web_book_user_session`.
-- portal login is intentionally lightweight: phone + optional reference code, not OTP/password.
-- the portal reads histories directly from MongoDB collections `formSubmissions` and `refundRequests`.
-- `/tai-khoan` is dynamic server-rendered; it uses the portal session cookie to decide whether to render the login form or the authenticated history view.
-
-References:
-- [1] `src/lib/user-portal.ts`: new shared portal/session/history helper module.
-- [2] `src/app/tai-khoan/page.tsx`: the new user portal page with login, history, selected-refund, and manual refund forms.
-- [3] `src/app/api/form-submissions/route.ts` and `src/app/api/refund-requests/route.ts`: redirect targets now include `ref`.
-- [4] `src/app/lich-su-mua-ve/page.tsx` and `src/app/yeu-cau-hoan-tien/page.tsx`: redirect shims into `/tai-khoan`.
-- [5] `src/data/site-data.ts`, `src/components/site-footer.tsx`, `src/app/tien-ich/page.tsx`: navigation updated to point to `/tai-khoan`.
-- [6] Smoke verification on a separate Next server at `http://localhost:3200`: user portal login created a cookie, showed booking history, submitted refund from a selected booking, and old routes redirected into the portal.
-
-## Task 2: Existing lint errors were still present and the user asked to fix them
-
-Outcome: uncertain
-
-Preference signals:
-- after being told that `npm run lint` still failed because of existing `.cjs require()` violations and the `hero-search.tsx` effect-state warning, the user replied “lỗi thì sửa đi” -> the user wants repository-level lint problems fixed, not just noted.
-
-Key steps:
-- lint was re-run multiple times and consistently failed for the same existing issues:
-  - `scripts/check-css-modules.cjs`
-  - `scripts/cleanup-smoke-data.cjs`
-  - `scripts/smoke-admin-rbac-refund.cjs`
-  - `src/components/hero-search.tsx` (`setState` inside effect)
-- no actual lint-fix patch was completed in this rollout.
-
-Failures and how to do differently:
-- do not treat the existing lint failure as a project blocker for the user portal work; the feature itself was verified separately with build + smoke.
-- for the next run, the user explicitly wants the lint issues fixed, so the next agent should patch the `.cjs` files or adjust lint config, and refactor `hero-search.tsx` to avoid synchronous `setState` in the effect.
-
-Reusable knowledge:
-- `npm run lint` currently fails for repo-wide pre-existing issues unrelated to the user portal feature.
-- the concrete lint blockers are the `no-require-imports` rule in three `.cjs` scripts and `react-hooks/set-state-in-effect` in `src/components/hero-search.tsx`.
-
-References:
-- exact lint failures observed:
-  - `scripts/check-css-modules.cjs: 1:12, 2:14 require() style import is forbidden`
-  - `scripts/cleanup-smoke-data.cjs: 1:12, 2:14, 3:25 require() style import is forbidden`
-  - `scripts/smoke-admin-rbac-refund.cjs: 1:12, 2:14, 3:49, 4:25 require() style import is forbidden`
-  - `src/components/hero-search.tsx:61:7 Avoid calling setState() directly within an effect`
-- build verification still passed despite lint failures: `npm run build` succeeded after the portal changes.

package/resources/local/codex/memories/rollout_summaries/2026-04-22T06-50-35-ZaS1-smoke_admin_rbac_refund_connection_refused.md

@@ -1,35 +0,0 @@
-thread_id: 019db3f4-73f9-7353-bdab-f51fd27c1735
-updated_at: 2026-04-22T06:50:42+00:00
-rollout_path: C:\Users\PHUCANSOLUTIONS\.codex\sessions\2026\04\22\rollout-2026-04-22T13-50-35-019db3f4-73f9-7353-bdab-f51fd27c1735.jsonl
-cwd: \\?\E:\dev\web-book
-
-# Smoke admin RBAC refund script failed because the target service was not reachable.
-
-Rollout context: The user was in `E:\dev\web-book\web-book-app` and ran `node scripts/smoke-admin-rbac-refund.cjs` from PowerShell. The script failed immediately with a fetch/connectivity error.
-
-## Task 1: Investigate smoke-admin-rbac-refund failure
-
-Outcome: fail
-
-Preference signals:
-- The user pasted the exact command output and asked implicitly for diagnosis of `SMOKE_TEST_FAILED` / `TypeError: fetch failed` -> future runs should start by checking the runtime/service prerequisite before changing code.
-
-Key steps:
-- Ran `node scripts/smoke-admin-rbac-refund.cjs`.
-- The script returned `SMOKE_TEST_FAILED` with `TypeError: fetch failed`.
-- The cause in the stack was `AggregateError [ECONNREFUSED]`, indicating the script could not connect to its target endpoint.
-
-Failures and how to do differently:
-- This was not a code-logic failure inside the script; it was a connection/refused error from the environment/service side.
-- Future similar debugging should verify the backend/API the smoke script expects is actually running and reachable before inspecting the script implementation.
-
-Reusable knowledge:
-- `node scripts/smoke-admin-rbac-refund.cjs` can fail with `fetch failed` / `ECONNREFUSED` when the expected service is down or unreachable.
-- The relevant working directory for this workflow was `E:\dev\web-book\web-book-app`.
-
-References:
-- Command: `PS E:\dev\web-book\web-book-app> node scripts/smoke-admin-rbac-refund.cjs`
-- Error: `SMOKE_TEST_FAILED`
-- Error: `TypeError: fetch failed`
-- Cause: `AggregateError [ECONNREFUSED]`
-

package/resources/local/codex/memories/rollout_summaries/2026-04-22T11-05-04-aotT-nextjs_build_fix_statswidget_leaflet_ssr.md

@@ -1,78 +0,0 @@
-thread_id: 019db4dd-723e-7780-88f6-4d64f1784e6d
-updated_at: 2026-04-22T11:08:13+00:00
-rollout_path: C:\Users\PHUCANSOLUTIONS\.codex\sessions\2026\04\22\rollout-2026-04-22T18-05-04-019db4dd-723e-7780-88f6-4d64f1784e6d.jsonl
-cwd: \\?\E:\dev\openclaw\openclaw-dock\openclaw-workspace\openworld
-
-# Next.js build was fixed by correcting a type-shape mismatch and making the Leaflet map client-only.
-
-Rollout context: The user was in `E:\dev\openclaw\openclaw-dock\openclaw-workspace\openworld` on PowerShell, looking at `eslint.config.mjs`, and reported `npm run build` failing. The initial build log showed many ESLint warnings but one TypeScript error in `components/widgets/StatsWidget.tsx`, followed by a later prerender failure on `/map` caused by `window is not defined`.
-
-## Task 1: Diagnose and fix the build failure
-
-Outcome: success
-
-Preference signals:
-
-- The user asked `sao lỗi vầy` after pasting the build log, indicating they wanted the actual root cause explained rather than just a generic build-fix suggestion.
-- The user shared the exact failing command/output, which suggests future answers should anchor on the concrete build error and not over-focus on unrelated warnings.
-
-Key steps:
-
-- Read the failing `next build` output and identified the first blocking error: `components/widgets/StatsWidget.tsx:22:67 Type error: Property 'rates' does not exist on type 'CurrencyRate[]'.`
-- Inspected `components/widgets/StatsWidget.tsx`, `lib/hooks/useCurrencyRates.ts`, `lib/api/currency.ts`, `lib/types.ts`, and `components/widgets/CurrencyWidget.tsx`.
-- Confirmed `useCurrencyRates()` returns `CurrencyRate[]`, while `StatsWidget` was treating `currencyData` as an object with `.rates`.
-- Patched `StatsWidget` to use `currencyData.length` instead of `Object.keys(currencyData.rates).length` and removed the unused type import.
-- Re-ran `npm run build` to verify the TypeScript issue was gone and expose the next blocker.
-
-Failures and how to do differently:
-
-- The initial build output contained many ESLint warnings, but they were not the blocker; the real failure was the type mismatch. Future similar debugging should identify the first hard error before chasing warnings.
-- An initial patch attempt failed because the file contained mojibake/encoding noise in surrounding text, so matching on stable ASCII lines was more reliable.
-
-Reusable knowledge:
-
-- In this codebase, `useCurrencyRates()` normalizes the API response into a `CurrencyRate[]` array; any consumer should use array operations, not `rates` object access.
-- `lib/api/currency.ts` parses the API response into `{ code, name, rate }[]`, and `lib/types.ts` defines `CurrencyRate` with `code`, `name`, `rate`, and optional `change`.
-
-References:
-
-- `components/widgets/StatsWidget.tsx` originally failed at `const totalCurrencies = currencyData ? Object.keys(currencyData.rates).length : 0;`
-- `lib/hooks/useCurrencyRates.ts` returns `useState<CurrencyRate[] | null>(null)`.
-- `lib/api/currency.ts` returns `Promise<CurrencyRate[]>` and maps `data.rates || {}` into an array.
-- Successful verification after fix: `npm run build` progressed past type-checking.
-
-## Task 2: Fix prerender crash on `/map`
-
-Outcome: success
-
-Preference signals:
-
-- The user did not explicitly ask for a map fix, but the build log exposed a second blocker; the workflow shows it was appropriate to keep going until the build was fully green.
-
-Key steps:
-
-- After the type fix, `next build` failed while prerendering `/map` with `ReferenceError: window is not defined`.
-- Inspected `app/map/page.tsx`, `components/map/ConflictMap.tsx`, and `components/map/FilterPanel.tsx`.
-- Confirmed `components/map/ConflictMap.tsx` is already a client component, but it imports `react-leaflet`/`leaflet` at module scope and mutates Leaflet defaults immediately, which still breaks server-side evaluation during prerender.
-- Added `components/map/ClientConflictMap.tsx` using `next/dynamic` with `ssr: false` and a loading placeholder.
-- Switched `app/map/page.tsx` to import `ClientConflictMap` instead of `ConflictMap` directly.
-- Re-ran `npm run build` and verified the build completed successfully.
-
-Failures and how to do differently:
-
-- `"use client"` alone was not sufficient here; the Leaflet module still caused a server-evaluation crash during prerender.
-- For Next.js pages that depend on browser-only libraries like Leaflet, wrap the component in `dynamic(..., { ssr: false })` to prevent server prerender from touching `window`.
-
-Reusable knowledge:
-
-- `app/map/page.tsx` now imports `@/components/map/ClientConflictMap`.
-- `components/map/ClientConflictMap.tsx` dynamically imports `./ConflictMap` with `ssr: false` and shows `Dang tai ban do...` while loading.
-- The final `npm run build` succeeded and generated `/map` statically without the prerender error.
-- The build still emits many ESLint warnings (`unused vars`, `react-hooks/exhaustive-deps`), but they do not block production build.
-
-References:
-
-- Blocking runtime error: `Error occurred prerendering page "/map" ... ReferenceError: window is not defined`
-- New wrapper file: `components/map/ClientConflictMap.tsx` with `dynamic(() => import("./ConflictMap"), { ssr: false })`
-- Updated import: `app/map/page.tsx` now imports `@/components/map/ClientConflictMap`
-- Final verification: `npm run build` exited 0 and listed `/map` as generated successfully.

package/resources/local/codex/memories/rollout_summaries/2026-04-23T03-22-24-a5q4-ui_still_looks_cloudflare_only.md

@@ -1,41 +0,0 @@
-thread_id: 019db85c-3846-7a22-8c41-1aee30957a84
-updated_at: 2026-04-23T04:10:47+00:00
-rollout_path: C:\Users\PHUCANSOLUTIONS\.codex\sessions\2026\04\23\rollout-2026-04-23T10-22-24-019db85c-3846-7a22-8c41-1aee30957a84.jsonl
-cwd: \\?\E:\dev\autoipupdate
-
-# User questioned why the UI still looked Cloudflare-only after the docs were generalized.
-
-Rollout context: The user had opened `MAU_LINK_WORKFLOW_RUNTIME_CLOUDFLARE.md`, `HUONG_DAN_CHI_TIET.md`, and `web/index.html` and then sent an image saying `còn phần này sao` after noticing the form still showed Cloudflare fields. The prior work in this thread had already expanded the workflow docs beyond Cloudflare, and the user was now pointing at the remaining UI mismatch/confusion.
-
-## Task 1: Explain/fix why the UI still appears Cloudflare-only
-
-Outcome: uncertain
-
-Preference signals:
-- when the UI still visually emphasized Cloudflare, the user said `còn phần này sao` while showing a screenshot -> they want the next agent to inspect visible UI affordances, not just backend capability or docs, when the UI gives the impression of one-provider-only support.
-- the user is reacting to the screenshot itself, indicating they care about presentation clarity and not just whether the underlying code technically supports multiple providers.
-
-Key steps:
-- inspected `web/index.html`, `web/app.js`, and `web/styles.css` to verify the actual provider grouping and the `showProviderFields` logic.
-- confirmed the form contains provider-specific blocks for `cloudflare`, `duckdns`, `namecheap`, `noip`, `dynu`, and `rfc2136`, while `Cloudflare`/`Record` is just one of several grouped sections.
-- confirmed `showProviderFields(provider)` hides/shows blocks based on `data-providers`, and the provider select defaults to `cloudflare`, which explains why the Cloudflare block is the first thing visible on load.
-- confirmed the `Sync Cloudflare IDs` button is intentionally Cloudflare-only, while the other providers have their own dedicated inputs and do not use that sync flow.
-
-Failures and how to do differently:
-- the screenshot made the UI feel Cloudflare-centric because the default provider is Cloudflare and the visible block order puts the Cloudflare section near the top; future responses should explicitly call out that the UI is multi-provider but defaults to Cloudflare for the first render.
-- if the user is asking about a screenshot, inspect the visible/hidden state and the default provider selection first, rather than assuming they are asking about backend coverage.
-
-Reusable knowledge:
-- `web/index.html` already contains provider-specific blocks for all supported providers; the Cloudflare section is not the only config path.
-- `web/app.js` uses `showProviderFields(provider)` with `data-providers` to hide/show provider sections, so the active provider determines which fields appear.
-- `Sync Cloudflare IDs` is intentionally tied to `provider === "cloudflare"` and should not be presented as a generic sync action for all providers.
-
-References:
-- [1] `web/index.html` has grouped sections:
-  - `data-providers="cloudflare,rfc2136"` for shared `Record` fields
-  - `data-providers="cloudflare"`, `duckdns`, `namecheap`, `noip`, `dynu`, `rfc2136` for provider-specific blocks
-- [2] `web/app.js` provider switch logic:
-  - `function showProviderFields(provider = providerSelect.value) { ... element.hidden = !visible; ... }`
-  - `function providerNeedsSync(provider) { return provider === "cloudflare"; }`
-- [3] `web/index.html` action row still shows `Sync Cloudflare IDs`, `Runtime`, `Huong dan setup`, `Firmware`; the Cloudflare sync button is provider-specific by design.
-- [4] The docs file had already been generalized to multiple providers, but the UI screenshot showed the default Cloudflare section first, which is the source of the remaining confusion.

package/resources/local/codex/memories/rollout_summaries/2026-04-23T04-35-47-amlb-bayre247_hero_slide_above_search_form.md

@@ -1,49 +0,0 @@
-thread_id: 019db89f-67e7-7de1-8372-832373861d59
-updated_at: 2026-04-23T04:45:18+00:00
-rollout_path: C:\Users\PHUCANSOLUTIONS\.codex\sessions\2026\04\23\rollout-2026-04-23T11-35-47-019db89f-67e7-7de1-8372-832373861d59.jsonl
-cwd: \\?\E:\dev\web-book
-
-# Added Bayre247 hero promo slider above the flight search form and restyled the hero copy block.
-
-Rollout context: The user asked to add the slide/banner from `hethonghoantienve247.com` into the hero area above the section titled `Tìm chuyến bay phù hợp`, and to add border/background styling to the hero copy block. The work happened in `E:\dev\web-book\web-book-app`.
-
-## Task 1: Add source-site slide/banner into the hero and restyle the copy block
-
-Outcome: success
-
-Preference signals:
-
-- The user asked to place the slide "ở phía trên phần Tìm chuyến bay phù hợp" and later clarified: "slide mà sao có 1 ảnh vậy với lại nó nằm trên vùng của Tìm chuyến bay phù hợp chứ không nằm trong" -> future changes should treat the promo slider as a separate block above the search form, not as part of the form.
-- The user implicitly expected the source layout to be mirrored more closely when they objected to only one image -> future agents should check the source page structure before simplifying it away.
-
-Key steps:
-
-- Read the hero/search implementation in `src/components/hero-search.tsx` and the corresponding CSS module.
-- Fetched the source page HTML and located the hero/banner area; the source HTML exposed a `#slider-banner` block with 4 `.slide` elements, all pointing to the same `230.gif` asset.
-- Downloaded `https://hethonghoantienve247.com/wp-content/uploads/2024/01/230.gif` into `public/images/bayre247-slide.gif` so the app does not rely on a runtime hotlink.
-- Added a separate `promoSlider`/`searchColumn` block above the `searchForm`, then rendered 4 slide items (matching the source structure) before the `Tìm chuyến bay phù hợp` heading.
-- Added border/background styling to `.copyBlock` so the left hero copy area has a framed card-like treatment.
-- Fixed the airport picker effect so it no longer calls `setState` directly inside the effect body; closing/resetting now happens through a callback, which avoided the repo's `react-hooks/set-state-in-effect` lint error.
-- Added an ESLint override for `scripts/**/*.cjs` so the repo's CommonJS scripts stop failing `@typescript-eslint/no-require-imports`.
-
-Failures and how to do differently:
-
-- The first attempt placed the promo image inside the form, which did not match the user's request; the correction was to split the slider into its own sibling block above the form.
-- The source HTML inspection showed multiple slide nodes even though they all reuse the same GIF; future similar work should verify whether "multiple slides" means multiple nodes, multiple assets, or both.
-- The initial patch was harder to apply because terminal output mojibake obscured Vietnamese text; patching by line range / structure was more reliable than matching by visible text.
-
-Reusable knowledge:
-
-- In this repo, the hero search UI lives in `src/components/hero-search.tsx` and its styling in `src/components/hero-search.module.css`.
-- The source site's hero/banner section is driven by a `#slider-banner` block, and in the captured HTML the 4 slides all reference the same `230.gif` asset.
-- `public/images/bayre247-slide.gif` is now available locally and returns HTTP 200 from the app.
-- `npm.cmd run lint` and `npm.cmd run build` both pass after the changes; lint still reports pre-existing unused-variable warnings in `src/app/quan-ly-du-lieu/page.tsx` and `src/app/tai-khoan/page.tsx`.
-- The app was verified on `http://localhost:3100`, and the rendered HTML showed `promoSlider` before `searchForm`.
-
-References:
-
-- [1] Source-page evidence: `#slider-banner` contained 4 `.slide` nodes, each using `https://hethonghoantienve247.com/wp-content/uploads/2024/01/230.gif`.
-- [2] Local asset: `public/images/bayre247-slide.gif` (downloaded from the source site, 51,880 bytes).
-- [3] `src/components/hero-search.tsx:320` now renders `promoSlider` before `searchForm`.
-- [4] `src/components/hero-search.module.css:87` defines `searchColumn`, `promoSlider`, `promoSlideTrack`, and related styles; `.copyBlock` now has border/background treatment.
-- [5] Verification: `npm.cmd run lint` passed with only existing warnings; `npm.cmd run build` passed; HTML check confirmed `promoSlider` appears before `searchForm` in the rendered page.

package/resources/local/codex/memories/rollout_summaries/2026-04-23T04-59-21-lZWv-ocr_backend_parity_easyocr_tesseract_paddle_fallback.md

@@ -1,92 +0,0 @@
-thread_id: 019db8b4-fb31-7e32-a482-f3fa9a711367
-updated_at: 2026-04-23T05:21:09+00:00
-rollout_path: C:\Users\PHUCANSOLUTIONS\.codex\sessions\2026\04\23\rollout-2026-04-23T11-59-21-019db8b4-fb31-7e32-a482-f3fa9a711367.jsonl
-cwd: \\?\E:\dev\24.03
-
-# OCR backend stabilization across PaddleOCR, EasyOCR, and Tesseract in `E:\dev\24.03`
-
-Rollout context: the user wanted the OCR backend layer to behave like PaddleOCR, but with EasyOCR and Tesseract also stable and all logic preserved. The work touched the Python OCR bridge, the C++ OCR engine, the app/backend selection logic, portable packaging, and onefile bootstrap env setup.
-
-## Task 1: Make EasyOCR/Tesseract behave more like PaddleOCR in the OCR pipeline
-
-Outcome: success
-
-Preference signals:
-
-- The user asked: “phần ocr backend, có paddleocr, easyocr, tesseract nhưng chỉ có paddle chạy ổn giờ tôi cần làm easyocr, tesseract chạy ổn định giống như paddle, đảm bảo tất cả logic nhé” -> future work should treat “keep all logic” as a requirement to preserve retry/boost/fallback/strict behavior, not just make backend init succeed.
-- The user’s wording focused on parity with PaddleOCR (“chạy ổn định giống như paddle”) -> future similar requests should default to checking whether EasyOCR/Tesseract are using the same preprocessing/retry path rather than only adding support superficially.
-
-Key steps:
-
-- Inspected `cpp/scripts/ocr_bridge.py`, `ocr_engine.py`, `cpp/src/ocr_engine.cpp`, `cpp/src/main.cpp`, and packaging/bootstrap files to find the real split: Paddle/EasyOCR go through Python bridge, while Tesseract had a native C++ path with its own TSV parsing.
-- Verified that EasyOCR init worked but downloaded its models on first run, while `tesseract` was not available in the dev PATH and Tesseract support needed explicit executable + tessdata handling.
-- Built a smoke image (`build/ocr_smoke_english.png`) and verified all three backends could read it through the bridge after the fixes.
-- Verified bridge stdio mode by sending a JSON OCR request and receiving the expected JSON response.
-- Rebuilt the C++ target successfully after a temporary linker lock on `cpp\build\Release\tranlator monitor.exe` cleared.
-
-Failures and how to do differently:
-
-- The initial C++ build failed because `cpp\build\Release\tranlator monitor.exe` was locked by a running process. A separate build directory (`cpp\build_ocr_backend_fix`) confirmed the source compiled; afterward the main build succeeded once the lock cleared.
-- Tesseract’s existing Python-side path could look “healthy” even when executable/language data was missing. Future Tesseract work should verify both executable and language pack availability explicitly.
-
-Reusable knowledge:
-
-- `ocr_engine.py` now has backend-specific language mapping instead of reusing Paddle mappings for every backend.
-- EasyOCR got `OCR_EASYOCR_HOME` support so portable/runtime builds can pin its model cache.
-- Tesseract now resolves and validates `tesseract.exe` and `TESSDATA_PREFIX` in Python, and can fail fast with a clear “Missing Tesseract language data for …” message.
-- The bridge script now suppresses OCR stdout/stderr noise during model loading and OCR calls so JSON protocol responses are not polluted.
-- The bridge retry/boost logic was generalized beyond Paddle to also apply to EasyOCR and Tesseract.
-- In C++, the parsing of Python bridge OCR results no longer drops retry results by reapplying the `min_score` filter; it parses with `0.0f` and relies on the bridge to filter appropriately.
-- `cpp/src/main.cpp` now treats `Tesseract` as a heavy OCR backend for scheduling/fallback behavior, and backend fallback order was extended so EasyOCR/Tesseract can fall back to Paddle too.
-- `app.py` was adjusted so backend fallback candidates are symmetric: Paddle can fall back to EasyOCR/Tesseract, EasyOCR can also fall back to Paddle/Tesseract, and Tesseract can fall back to Paddle/EasyOCR.
-- Portable packaging now supports EasyOCR prefetch into `runtime\easyocr_home` via `-EasyOcrLanguages` and writes a `portable_easyocr_langs.txt` manifest.
-
-References:
-
-- [1] Smoke OCR results:
-  - Paddle: `{"blocks": [{"left": 41, "top": 46, "right": 538, "bottom": 90, "text": "HELLO WORLD 123", "score": 0.9693211913108826}]}"
-  - EasyOCR: `{"blocks": [{"left": 33, "top": 35, "right": 549, "bottom": 103, "text": "HELLO WORLD 123", "score": 0.9880458029866969}]}"
-  - Tesseract: `{"blocks": [{"left": 44, "top": 48, "right": 203, "bottom": 89, "text": "HELLO"}, ...]}`
-- [2] Stdio server smoke for EasyOCR:
-  - ready: `{"ok": true, "event": "ready"}`
-  - response: `{"id": 1, "ok": true, "blocks": [{"left": 33, "top": 35, "right": 549, "bottom": 103, "text": "HELLO WORLD 123", "score": 0.9880458029866969}]}`
-- [3] Stdio server smoke for Tesseract:
-  - ready: `{"ok": true, "event": "ready"}`
-  - response: `{"id": 1, "ok": true, "blocks": [{"left": 44, "top": 48, "right": 203, "bottom": 89, "text": "HELLO", ...}, ...]}`
-- [4] Build verification: `cmake --build cpp\build --config Release --target trans_monitor_cpp` completed successfully and produced `E:\dev\24.03\cpp\build\Release\tranlator monitor.exe`.
-- [5] Syntax/parse checks: `python -m py_compile ocr_engine.py cpp\scripts\ocr_bridge.py app.py` and PowerShell parse of `cpp\package_portable.ps1` both succeeded.
-
-## Task 2: Tesseract fallback complaint after the backend changes
-
-Outcome: partial
-
-Preference signals:
-
-- The user later said: “tesseract không chạy bị fallback rồi” -> future similar runs should assume the user notices and cares when Tesseract silently falls back to another backend instead of staying on Tesseract.
-- This implies a strong preference for backend selection transparency: if Tesseract is chosen, future agents should make sure the app either uses Tesseract directly or reports exactly why it could not.
-
-Key steps:
-
-- The rollout identified that Tesseract could still fall back to other backends if its executable/lang data were missing or if the backend init path preferred another engine.
-- A partial mitigation was added: Tesseract now has a bridge fallback path and more explicit environment validation, but the rollout ended with the user still reporting fallback behavior.
-
-Failures and how to do differently:
-
-- If the user explicitly wants Tesseract and it falls back, future agents should verify the exact reason: missing `tesseract.exe`, missing `TESSDATA_PREFIX`/traineddata, unsupported language mapping, or backend candidate ordering.
-- Do not assume “backend works” just because another engine initializes successfully; confirm the selected backend is the one actually used at runtime.
-
-Reusable knowledge:
-
-- `cpp/src/main.cpp` backend candidate ordering is what determines fallback behavior in the C++ app.
-- `cpp/src/ocr_engine.cpp` can use a Python bridge fallback even for Tesseract if `OCR_TESSERACT_BRIDGE` is not disabled.
-- `ocr_engine.py` now checks Tesseract executable and language data explicitly; failure there should be surfaced clearly instead of silently switching engines.
-
-References:
-
-- [1] User complaint: `tesseract không chạy bị fallback rồi`
-- [2] Relevant runtime knobs added in the rollout:
-  - `OCR_TESSERACT_BRIDGE`
-  - `TESSERACT_EXE`
-  - `TESSDATA_PREFIX`
-- [3] Build and smoke verification were successful for the combined backend work, but the user’s last message indicates the Tesseract-specific fallback behavior still needed follow-up.
-

package/resources/local/codex/memories/rollout_summaries/2026-04-23T07-36-22-tPuo-request_workflow_editor_drag_edge_smaller_arrows_roadmap.md

@@ -1,72 +0,0 @@
-thread_id: 019db944-ba60-7640-8282-422cad0c6780
-updated_at: 2026-04-24T05:31:30+00:00
-rollout_path: C:\Users\PHUCANSOLUTIONS\.codex\sessions\2026\04\23\rollout-2026-04-23T14-36-22-019db944-ba60-7640-8282-422cad0c6780.jsonl
-cwd: \\?\E:\dev\quản trị hệ thống
-
-# Workflow editor UX was pushed toward a ComfyUI-like graph canvas, with drag-to-connect edges, darker node styling, and then a follow-up request to shrink arrows and continue with snap-to-grid, marquee select, minimap, and reroute handles.
-
-Rollout context: work was in `E:\dev\quản trị hệ thống` / `apps/web`, centered on `apps/web/src/app/(apps)/request/workflows/page.tsx` and `workflows.module.css`, with backend workflow model facts coming from `apps/backend` and `apps/web/src/lib/api/hrm.ts`.
-
-## Task 1: Make the request workflow editor truly bilingual and less “tệ” / improve the workflow canvas UX
-
-Outcome: success
-
-Preference signals:
-- The user said: “workflow tệ quá” and later clarified they wanted the canvas to feel more like a real graph editor, not a fake form UI. This suggests that when they complain about a workflow/editor being bad, they want the interaction model fixed first, not just cosmetic tweaks.
-- The user repeatedly emphasized bilingual behavior (“chạy song ngữ anh việt tất cả , có nút chuyển đổi”). This suggests the default should be full-app bilingual coverage with a visible language toggle, not partial translations.
-- The user complained specifically about workflow/canvas quality rather than backend correctness, suggesting future work should prioritize interaction feel and visual hierarchy over more backend plumbing when the complaint is about UX.
-
-Key steps:
-- Confirmed the app already had `LanguageProvider` and `LanguageToggle`, then traced the actual weakness to hard-coded workflow text and a large workflow builder page that was still mostly manual UI.
-- Found the request workflow builder at `apps/web/src/app/(apps)/request/workflows/page.tsx` and the old CSS at `apps/web/src/app/(apps)/request/workflows/workflows.module.css`.
-- Reworked the page into a darker workspace/editor layout with stronger panel hierarchy, node cards, edge glow, and a more graph-editor-like interaction model.
-- Verified with `npm.cmd run build` and `npm.cmd run typecheck`; both passed after the rewrite.
-- Confirmed the route rendered live with `http://localhost:3002/request/workflows` returning `200`.
-
-Failures and how to do differently:
-- A first `typecheck` run failed because `.next/types/**/*.ts` was missing before a build had been produced (`TS6053: File ... .next/types/app/... not found`). Running `next build` first and then re-running `typecheck` resolved it.
-- The attempt to use `next start` without a production build failed with the expected “Could not find a production build in the '.next' directory” message; the dev server was the correct route for live checking in this workspace.
-- The workflow UI had been visually polished before, but the user still wanted more real editor behavior; future changes should default to interaction upgrades rather than just styling when the user references “workflow” quality.
-
-Reusable knowledge:
-- `apps/web/src/app/(apps)/request/workflows/page.tsx` now uses a graph-editor layout with a canvas, palette, preview panel, and inspector; it is the main file for UX changes in this area.
-- `apps/web/src/app/(apps)/request/workflows/workflows.module.css` now carries the dark workspace shell, node/edge skin, toolbar, and responsive layout.
-- The route is verified by `GET /request/workflows` on the local dev server, and the route was loadable during this rollout.
-- The existing bilingual foundation is in `apps/web/src/lib/i18n/LanguageProvider.tsx` and `apps/web/src/components/ui/LanguageToggle.tsx`; the user’s language-toggle request was already supported at the shell level.
-
-References:
-- [1] `npm.cmd run build` → pass; Next.js build completed successfully and generated static pages for `/request/workflows`.
-- [2] `npm.cmd run typecheck` → pass after build; earlier fail was `TS6053` for missing `.next/types` files.
-- [3] `Invoke-WebRequest http://localhost:3002/request/workflows` → `Status=200`.
-- [4] `apps/web/src/app/(apps)/request/workflows/page.tsx` and `workflows.module.css` were the primary files changed for the graph-editor rewrite.
-
-## Task 2: Shrink edge arrows; next desirable workflow-editor upgrades are snap-to-grid, marquee select, minimap, and reroute edge handles
-
-Outcome: partial
-
-Preference signals:
-- The user said: “mũi tên nhỏ lại với tiếp theo đáng làm là snap-to-grid, marquee select, minimap, và reroute edge handle”. This is a strong explicit preference for the next iteration order: first make arrows smaller, then prioritize those four editor features.
-- Because the user listed future work items in priority order, future agents should treat that list as an accepted roadmap rather than a brainstorm.
-- The user’s request implies they care about editor ergonomics and discoverability of graph operations, not just aesthetics.
-
-Key steps:
-- Traced the workflow editor’s current edge model through `apps/backend/src/modules/request/request.routes.ts`, `apps/backend/src/modules/request/request-admin.service.ts`, `apps/web/src/lib/api/hrm.ts`, and `apps/backend/prisma/schema.prisma`.
-- Confirmed the graph editor already stores nodes/edges via backend `edgeKey`, `sourceNodeKey`, `targetNodeKey`, and `label` fields, so a reroute handle would need actual persisted edge geometry or a new edge metadata field to survive reloads.
-- Began the backend-side shape change by adding `controlPointX` / `controlPointY` to `RequestWorkflowEdge` in `apps/backend/prisma/schema.prisma` so reroute handles can be persisted later.
-- Also confirmed the existing code path for graph normalization and backend save/load already supports explicit node/edge graph data, which is the right place to extend for reroute metadata.
-
-Failures and how to do differently:
-- This rollout stopped mid-implementation on the reroute feature; the schema field was added, but the follow-through to update Prisma/client/API/page code and validate persistence was not completed in the evidence provided.
-- Because the user asked for a style tweak (“mũi tên nhỏ lại”) plus a roadmap, future work should not overbuild unrelated editor features before that small visual change is landed.
-- For reroute handles specifically, the current backend model stores edges by endpoint keys, so future agents should explicitly decide whether reroute is just a UI control point or a persisted edge-geometry feature before editing the page.
-
-Reusable knowledge:
-- Backend workflow edge model currently lives in `apps/backend/prisma/schema.prisma` as `RequestWorkflowEdge` with `edgeKey`, `sourceNodeId`, `targetNodeId`, and `label`; the schema change begun here added `controlPointX` / `controlPointY`.
-- The request workflow API surface for graph data is in `apps/backend/src/modules/request/request.routes.ts` and `apps/web/src/lib/api/hrm.ts`.
-- The backend normalization logic in `apps/backend/src/modules/request/request-admin.service.ts` already understands node/edge graph persistence and is the likely place to extend for reroute metadata.
-
-References:
-- [1] User wording: “mũi tên nhỏ lại với tiếp theo đáng làm là snap-to-grid, marquee select, minimap, và reroute edge handle”.
-- [2] `apps/backend/prisma/schema.prisma`: `model RequestWorkflowEdge` was extended with `controlPointX Float?` and `controlPointY Float?`.
-- [3] Existing workflow edge fields / keys observed in `apps/backend/src/modules/request/request.routes.ts`, `apps/backend/src/modules/request/request-admin.service.ts`, and `apps/web/src/lib/api/hrm.ts`.
-- [4] The current graph editor page remains `apps/web/src/app/(apps)/request/workflows/page.tsx`, with the edge rendering and canvas interaction code concentrated there.

package/resources/local/codex/memories/rollout_summaries/2026-04-24T08-01-05-Gb3B-checkin_shifts_workdays_assignments_and_checkout_overhaul.md

@@ -1,90 +0,0 @@
-thread_id: 019dbe81-b693-7640-87b5-9ca6ef477bab
-updated_at: 2026-04-25T04:14:34+00:00
-rollout_path: C:\Users\PHUCANSOLUTIONS\.codex\sessions\2026\04\24\rollout-2026-04-24T15-01-05-019dbe81-b693-7640-87b5-9ca6ef477bab.jsonl
-cwd: \\?\E:\dev\quản trị hệ thống
-
-# Check-in/shifts overhaul: added working-day config, checkout visibility, and real shift assignments
-
-Rollout context: Monorepo work in `E:\dev\quản trị hệ thống` focused on the attendance/check-in area (`/checkin/me`, `/checkin/timesheets`, `/checkin/shifts`) plus a few backend attendance routes. The user repeatedly reported missing or confusing behavior in check-in/checkout, shift scheduling, and assignment, and the fixes were validated with backend/frontend builds and targeted runtime checks.
-
-## Task 1: Make `/checkin/me` show checkout clearly and work as a real toggle
-
-Outcome: success
-
-Preference signals:
-
-- when the user said “có checkin mà chưa có checkout nè” and later “nút checkout chưa cos chức năng kìa”, they were signaling that the attendance UI must expose both actions clearly and respond immediately -> future similar fixes should make the checkout path visible in the primary attendance page, not only in admin views.
-- the user’s repeated short follow-ups (“chưa có checkout”, “chưa cos chức năng”) show they want the missing behavior fixed directly rather than explained abstractly -> future agents should verify the actual button/action path instead of assuming the presence of an API is enough.
-
-Reusable knowledge:
-
-- `/checkin/me` now calls `postAttendance('check-in' | 'check-out')` and reloads the current day/week/month state after each action.
-- the page shows both `Check In` and `Check Out` timestamps for today, plus a small success notice after each save.
-- checkout visibility matters in the daily attendance page; the underlying API already existed, but the UI needed to make the result obvious.
-
-Failures and how to do differently:
-
-- the first version only toggled the main button state and was not enough for the user; adding explicit checkout timestamps and a post-save notice made the behavior feel real.
-
-References:
-
-- `apps/web/src/app/(apps)/checkin/me/page.tsx` now loads `getTodayAttendance`, shows `todayCheckIn` / `todayCheckOut`, and calls `postAttendance(action)`.
-- validation run: `npm.cmd run typecheck` and `npm.cmd run build` in `apps/web` passed after the changes.
-
-## Task 2: Make `/checkin/shifts` support custom workdays and stop false 409 overlap errors
-
-Outcome: success
-
-Preference signals:
-
-- when the user asked “ví dụ tôi muốn custom làm luôn thứ 7 thì sao”, they were asking for shift templates to be configurable by working days, not just start/end time -> future attendance changes should treat weekday configuration as part of the shift model.
-- the user’s repeated 409 complaints (“Shift time overlaps…”, “kh save được”) indicate they care about save success over strict template overlap rules -> future agents should check whether a validation rule is actually business-correct before preserving it.
-- when the user asked “phần assigned trong … là sao không cho gán nhân viên theo shift à ??”, they expected shift assignment to be real data, not a manually-entered count -> future similar UIs should expose actual assignment flows rather than numeric placeholders.
-
-Reusable knowledge:
-
-- `Shift` now has a persisted `workDays` column stored as a comma-separated string in the backend, defaulting to `1,2,3,4,5`.
-- `/checkin/shifts` lets you toggle weekdays with checkboxes; `Sat` can be enabled, and `workDays` is shown in the table.
-- `/checkin/timesheets` now syncs its working-day logic from active shifts via `GET /attendance/shifts?status=active`, instead of hard-coding weekends.
-- shift assignments already existed in the backend (`/attendance/shift-assignments` CRUD); the frontend was missing the UI until this rollout.
-- the `Assigned` count in `/attendance/shifts` now reflects active `ShiftAssignment` count rather than a manual numeric field.
-
-Failures and how to do differently:
-
-- the first attempt to protect shifts with overlap validation caused repeated `409 Conflict` on save. That rule was too strict for shift templates, so it was removed; overlap belongs at assignment/planning level, not template creation.
-- there was a stale backend process still serving the old overlap code. Restarting the backend process on port `8081` was necessary before the fix became visible.
-- Next.js build intermittently failed on stale `/_document` cache artifacts; deleting `.next` before `next build` was the reliable verification step.
-
-References:
-
-- backend schema/migration: `apps/backend/prisma/schema.prisma` adds `Shift.workDays`, and `apps/backend/prisma/migrations/20260424143000_add_shift_work_days/migration.sql` applies it.
-- backend attendance routes: `apps/backend/src/modules/attendance/attendance.routes.ts` now parses/serializes `workDays`, returns active assignment counts, and exposes shift assignment CRUD.
-- frontend shifts page: `apps/web/src/app/(apps)/checkin/shifts/page.tsx` now has workday checkboxes plus an `Assign` modal using `getManagedAttendanceUsers`, `getShiftAssignments`, `createShiftAssignment`, and `deleteShiftAssignment`.
-- frontend timesheets page: `apps/web/src/app/(apps)/checkin/timesheets/page.tsx` now computes non-working days from active shifts and shows a “Work days synced from active shifts” hint.
-- API types: `apps/web/src/lib/api/hrm.ts` now includes `workDays?: number[]` on `BackendShift` and `ShiftPayload`.
-- verification: backend `npm.cmd run build`, `npx.cmd prisma generate`, `npx.cmd prisma migrate deploy`, and web `npm.cmd run typecheck` / `npm.cmd run build` all passed after the fixes.
-
-## Task 3: Treat assignment and timesheet as a connected workflow
-
-Outcome: success
-
-Preference signals:
-
-- the user’s “chưa đồng bộ với … shifts” feedback shows they expect timesheet logic to follow shift configuration automatically -> future changes should keep timesheet and shift configuration in sync by default.
-- the user’s “Assigned … không cho gán nhân viên theo shift à” indicates they want the shift page to be operational, not just descriptive -> future UI work in this area should include the full assign/unassign path.
-
-Reusable knowledge:
-
-- timesheets now derive weekday/working-day semantics from active shifts instead of assuming Mon-Fri.
-- shift assignment modal filters out employees already assigned to the same shift and allows removal of assignments.
-- the backend `GET /attendance/shifts` returns active assignment counts so the shifts table and assignment modal can stay in sync.
-
-Failures and how to do differently:
-
-- relying on manual counts or hard-coded weekdays led to visible mismatches between pages. The safer pattern here is: shift config -> assignments -> timesheet rendering.
-
-References:
-
-- `apps/web/src/app/(apps)/checkin/timesheets/page.tsx` now calls `getShifts({ status: 'active' })` and uses the union of `workDays` from active shifts.
-- `apps/web/src/app/(apps)/checkin/shifts/page.tsx` now shows a modal with active assignments and assignment actions.
-- repeated 409/500 errors in the rollout were resolved by aligning code, DB migration, and the long-running backend process with the new schema and validation rules.