# Mono Skills — Knowledge History

Source: EJI-ICT/mono-skills (synced via `mono sync`). 12 session(s), newest first.

================================================================================
# gallery-apps: shrink grid thumbnails to 200x300
App: gallery-apps | Actor: YCEJ9999 | Date: 2026-07-02 16:10:03 | Status: completed
Topics: gallery, Picsum, thumbnail resolution, bandwidth, lightbox
Outcome: shipped — Changed thumbUrl default from 400x300 to 200x300 in src/datas/tables/gallery.ts. Updated the grid <img> intrinsic size to width=200 height=300 in src/pages/gallery/index.vue. Verified the 200x300 Picsum URL returns 200 (~9.8KB); largeUrl (lightbox) unaffected since it passes explicit dimensions.

## User requests
- Use a smaller thumbnail resolution for the gallery grid (like https://picsum.photos/200/300).

## Summary
# gallery-apps — smaller grid thumbnails (200×300)

## What changed
The gallery grid was requesting 400×300 renders per photo. Dropped the default to **200×300** so the
infinite-scroll grid downloads much lighter images (a 200×300 Picsum render is ~10 KB). The full-size
image in the lightbox is unaffected — it uses `largeUrl` (1200×800).

## Files
- **`src/datas/tables/gallery.ts`** — `thumbUrl` default dimensions changed `400×300 → 200×300`.
  `largeUrl(p, w, h)` still passes explicit dimensions, so it's unaffected.
- **`src/pages/gallery/index.vue`** — grid `<img>` intrinsic size updated `width="400" height="300"`
  → `width="200" height="300"` to match the served image (avoids layout-shift / wrong aspect hint).

## Notes for future sessions
- The grid uses `object-cover h-40`, so the CSS box is fixed regardless of the served resolution —
  shrinking `thumbUrl` only reduces bytes, it doesn't change the visible layout.
- Thumbnail vs. lightbox resolution are cleanly separated: `thumbUrl` (200×300, grid) and `largeUrl`
  (1200×800, lightbox) both wrap Picsum's `/id/{id}/{w}/{h}` form in `src/datas/tables/gallery.ts`.

## Decisions
- Keep the per-id Picsum URL, shrink only the dimensions — Kept the id-based Picsum form (/id/{id}/200/300) instead of the random-image form the user cited (https://picsum.photos/200/300). (Why: The random form returns a different photo each request; the grid must keep showing each photo's own image (and match the lightbox), so we only shrank the dimensions on the existing per-id URL.)
- Match the <img> intrinsic size to 200x300 — Updated the <img> width/height attributes to 200x300 alongside the URL change. (Why: The intrinsic-size attributes are an aspect-ratio/layout hint for the browser; leaving them at 400x300 while serving 200x300 would give a mismatched aspect hint.)

## Files changed
- src/datas/tables/gallery.ts [modified] — undefined
- src/pages/gallery/index.vue [modified] — undefined

## Commands
- mono skills check
- mono skills read --app gallery-apps --type knowledge
- curl https://picsum.photos/id/10/200/300

================================================================================
# gallery-apps: image-only lightbox on the Picsum gallery
App: gallery-apps | Actor: YCEJ9999 | Date: 2026-07-02 15:53:07 | Status: completed
Topics: image lightbox, gallery, Picsum, Vue Teleport overlay, VueUse keyboard + scroll lock, unplugin-vue-components auto-import
Outcome: shipped — Added src/components/GalleryLightbox.vue (Teleport overlay, keyboard nav, scroll lock). Added largeUrl() helper to src/datas/tables/gallery.ts (reuses thumbUrl). Wired lightbox into src/pages/gallery/index.vue via v-model:index and @click.prevent. vue-tsc clean for the changed files; Vite compiled all three modules (HTTP 200), VueUse auto-imports resolved.

## User requests
- Clicking a gallery thumbnail should open an image-only popup: a full-screen dark overlay with the large image centered, closable by backdrop click or Esc.
- Add caption (author + dimensions), prev/next navigation, and a source/full-res link.
- Run the Mono Skills read+save workflow around the task.

## Summary
# gallery-apps — image-only lightbox on the Picsum gallery

## What was built
Clicking a thumbnail on `/gallery` now opens an **image-only lightbox** instead of navigating away
to the Unsplash source page. The lightbox is a full-screen dark overlay (`bg-black/90`) with the
large image centered; it closes on backdrop click, the ✕ button, or **Esc**. It also carries minimal
overlaid chrome: a caption (author + `width×height`), prev/next navigation across the loaded photos
(on-screen arrows + **←/→** keys, hidden at the ends), and links to the source page (`p.url`) and
full-resolution image (`p.download_url`).

## Files
- **`src/components/GalleryLightbox.vue`** (new) — the lightbox. `<Teleport to="body">` + `v-if`,
  props `photos: PicsumPhoto[]` and `index: number | null` (`v-model:index`), emits `update:index` +
  `close`. Keyboard via VueUse `onKeyStroke` (Escape/ArrowLeft/ArrowRight, guarded to only act while
  open); background scroll frozen via `useScrollLock(document.body)` toggled by a `watch` on the open
  photo. Backdrop uses `@click.self="close"`; chrome/image wrapped with `@click.stop`.
- **`src/datas/tables/gallery.ts`** — added `largeUrl(p, w=1200, h=800)` that reuses `thumbUrl`'s
  `/id/{id}/{w}/{h}` form, so the lightbox serves a bounded image rather than the multi-MB original.
- **`src/pages/gallery/index.vue`** — added `activeIndex = ref<number|null>(null)`; the grid item
  keeps its `<a :href="p.url">` (right-click/no-JS still works) but intercepts left click with
  `@click.prevent="activeIndex = i"` (`v-for="(p, i) in store.photos"`); renders
  `<GalleryLightbox :photos="store.photos" v-model:index="activeIndex" @close="activeIndex = null" />`.

## Key facts for future sessions
- **`src/components/` is the `unplugin-vue-components` auto-import root** — components there register
  globally with no manual import in the page (verified: Vite injected the import automatically).
- **VueUse is auto-imported** project-wide (`onKeyStroke`, `useScrollLock`, `useIntersectionObserver`
  all resolve from `@vueuse/core` with no explicit import).
- `PicsumPhoto` already carries everything the lightbox needs (`author`, `width`, `height`, `url`,
  `download_url`) — no store changes were required; the lightbox pages through `store.photos`.
- `mono-modal` (`mono-helper/ui/modal`) exists and is the project's modal convention, but it always
  renders a padded card — not suitable for an edge-to-edge image-only lightbox (see decisions).
- Pre-existing unrelated typecheck error: `.mono/apps/mono-host/app/composables/use-utils.ts`
  references `import.meta.client` (Nuxt) → `TS2339` under this app's vue-tsc. Not caused here.

## Decisions
- Custom Teleport lightbox instead of mono-modal — Built a custom Teleport overlay component (GalleryLightbox.vue) instead of reusing the mono-modal web component. (Why: mono-modal always renders a padded modal card; the requested design is an edge-to-edge, image-only lightbox. A small dedicated Teleport overlay is cleaner and gives full control over backdrop, arrows, and caption. All needed behavior (keyboard, scroll-lock) is already available via auto-imported VueUse.)
- Keep the anchor, intercept left-click with @click.prevent — Kept the grid item as an <a :href="p.url"> but intercept the left click with @click.prevent to open the lightbox. (Why: Preserves right-click 'open in new tab', middle-click, and no-JS graceful degradation to the source page, while a normal left click opens the in-app lightbox.)
- Bounded 1200x800 largeUrl over the full original — Added a largeUrl() helper that reuses thumbUrl's /id/{id}/{w}/{h} form (1200x800) rather than loading p.download_url (the full original). (Why: Picsum originals are multi-megapixel/multi-MB; a bounded 1200x800 render is crisp enough for the lightbox and much faster. The full-res download_url is still offered as an explicit link.)
- Guard the global VueUse key handlers on open state — Registered global VueUse onKeyStroke handlers but guarded each to only act while a photo is open. (Why: The component is always mounted (rendered in the page), so the key listeners are always live; guarding on the open state prevents Esc/arrows from firing when the lightbox is closed.)

## Files changed
- src/components/GalleryLightbox.vue [added] — undefined
- src/datas/tables/gallery.ts [modified] — undefined
- src/pages/gallery/index.vue [modified] — undefined

## Commands
- mono skills check
- mono skills read --app gallery-apps --type knowledge
- mono skills search --app gallery-apps --query "gallery lightbox image popup"
- npx vue-tsc --noEmit
- npm run dev

## Validation
- Tests: not run
- Build: passed

================================================================================
# gallery-apps standalone app: Picsum infinite-scroll gallery
App: gallery-apps | Actor: YCEJ9999 | Date: 2026-06-29 07:00:00 | Status: completed
Topics: gallery, infinite-scroll, picsum, monoFetch, restful, cors, app-rename, mono-skills

## Summary
# gallery-apps — standalone Picsum infinite-scroll app

This app (`gallery-apps`, on the branch of the same name) is a Vue/Vite mono remote whose
single feature is an image gallery at `/gallery` that loads photos from the public Picsum
API with infinite scroll. It started as a gallery page added on the `memo-apps` branch, then
was split off into its own mono app: the memo feature was removed and the app was renamed
`my-memo` → `gallery-apps`.

## Feature stack (Rule 15)
- `mono.config.ts` — `name: 'gallery-apps'`; `Photos` restful endpoint
  (`https://picsum.photos/v2`) in `fetching.api`; menu = single `Gallery` entry.
- `src/datas/tables/gallery.ts` — `PicsumPhoto` type, `GALLERY_PAGE_SIZE = 30`,
  `thumbUrl(p, w, h)` (`/id/{id}/{w}/{h}`) so the grid loads thumbnails, not originals.
- `src/stores/use-gallery.ts` — `useGalleryGalleryApps` store (`photos / page / loading /
  hasMore / error`, `loadMore()` / `reset()`).
- `src/pages/gallery/index.vue` — thin page; responsive UnoCSS grid + a bottom sentinel
  watched by `useIntersectionObserver` (rootMargin 300px).

## Reusable gotchas
1. **`monoFetch` returns a bare array in `res.all`, not `res.data`.** `useNormalFetch`
   returns `{ data: responseData?.data, all: responseData, ... }`; Picsum returns a bare
   array, so read `res.all`. (For non-`{data}`-shaped REST responses, use `res.all`.)
2. **`monoFetch` + a public API can be CORS-blocked.** It always sends
   `Content-Type: application/json` (forces a preflight) and attaches `Authorization=[REDACTED]
   when a `MONO_tokenRefresh` cookie exists. Picsum's preflight allows `content-type` but NOT
   `authorization`, so an authenticated session would be blocked. The store tries `monoFetch`
   first (base URL via `monoRestBaseUrl('Photos')`) and falls back to native `fetch`.
3. **Renaming a mono app is cascading.** App id = `mono.config.ts` `name` → drives
   `@<name>/*` aliases, must match `package.json` `name`, and is the store-export/key suffix
   (Rule 8: `useGalleryMyMemo` → `useGalleryGalleryApps`, key `gallery-gallery-apps`). After
   editing the two name fields, run `mono prepare` to regenerate `.mono/tsconfig.json`
   aliases; restart Vite (delete `src/auto-imports.d.ts` first) so the auto-import dts
   re-scans cleanly — it merges rather than pruning deleted exports on a warm start.
4. **MONO Skills is app-scoped, immutable, no CLI delete.** `save` is skipped while the app
   uses a template-default name (incl. `mono-vue-remote`), so rename before saving. To move a
   session between apps, delete the files via the GitHub contents API and re-save under the
   new app id. (This session was moved my-memo → gallery-apps that way.)

## Verification
- `vue-tsc --noEmit` clean for app files (only the pre-existing host `import.meta.client`
  error remains); Vite dev serves `/gallery`, `/memo` is gone, auto-imports show only
  `useGalleryGalleryApps`; branch `gallery-apps` pushed to origin.

## Decisions
- Standalone gallery-apps on a new branch — Split the gallery into its own mono app (gallery-apps) on a new branch instead of keeping it on memo-apps. (Why: The gallery is unrelated to the memo app; a standalone app keeps concerns and skills history separate. Reusable: A 'new app' = new branch off the app with the full foundation + rename the app identity; main lacked the foundation so branching off it was not viable.)
- monoFetch (res.all) with a native-fetch CORS fallback — Fetch via monoFetch with a Photos restful config entry; read the array from res.all; native fetch fallback. (Why: mono-utils/fetching is the sanctioned layer; Picsum returns a bare array (lands in res.all) and rejects a CORS preflight carrying the Authorization header monoFetch attaches when a session cookie exists. Reusable: For public/no-auth third-party REST via monoFetch: read res.all, and guard for auth-header CORS rejection with a native fetch fallback (base URL from monoRestBaseUrl).)
- Bottom-sentinel infinite scroll via useIntersectionObserver — Infinite scroll via @vueuse/core useIntersectionObserver on a bottom sentinel (rootMargin 300px). (Why: Fits a grid + thin-page/store; stops when a page returns fewer than pageSize items. Reusable: Bottom-sentinel + useIntersectionObserver is the grid infinite-scroll pattern.)
- Rename the app via mono.config + package.json + mono prepare — Renamed app my-memo -> gallery-apps by editing mono.config name + package.json name, then mono prepare. (Why: App id drives @<name>/* aliases, package identity, and store-export/key suffix (Rule 8). Reusable: After a rename, run mono prepare to regen .mono/tsconfig aliases, and delete src/auto-imports.d.ts before restarting Vite so the auto-import dts re-scans cleanly (it does not prune deleted exports on a warm start).)
- Move a skills session across apps via the GitHub contents API — Moved this skills session from app my-memo to gallery-apps by deleting the 5 files via the GitHub contents API and re-saving. (Why: Skills sessions are app-scoped and immutable with no CLI delete; the session was first saved under the old app id. Reusable: To move a skills session between apps: GET each file's SHA and DELETE via the contents API (touch only that session folder), then mono skills save under the new app id.)

## Files changed
- mono.config.ts [modified] — name my-memo -> gallery-apps; Photos restful endpoint; menu reduced to Gallery
- package.json [modified] — name my-memo -> gallery-apps (must match mono.config name)
- src/datas/tables/gallery.ts [added] — PicsumPhoto type, GALLERY_PAGE_SIZE, thumbUrl helper
- src/stores/use-gallery.ts [added] — useGalleryGalleryApps store: loadMore() via monoFetch (res.all) + native fetch fallback
- src/pages/gallery/index.vue [added] — Gallery page: UnoCSS grid + useIntersectionObserver infinite scroll
- src/types/odata.d.ts [modified] — @my-memo -> @gallery-apps alias
- src/pages/memo/, src/stores/use-memo.ts, src/composables/use-memo-utils.ts, src/datas/tables/memo.ts, src/assets/memo-paper.css [deleted] — removed the entire memo feature

================================================================================
# Memo: mono-select type picker, mono-dropdown row-actions menu, sticky Aksi column
App: my-memo | Actor: YCEJ9999 | Date: 2026-06-21 16:00:00 | Status: completed
Topics: memo, mono-select, mono-dropdown, row-actions-menu, sticky-table-column, mono-ui, rule-13
Outcome: success — vite module transform + wiring grep /memo, page, store, datas transform 200 Page wires mono-select (type picker), mono-dropdown (row actions), actionMenuId/onTypeChange, memo-act, sticky right-0; the old .memo-type-toggle is gone UnoCSS generates i-mdi-dots-vertical Component APIs taken from the mono-helper vue/ demos (slot=main/body, :items.prop + key-value/display-value, $event.detail.modelValue)

## User requests
- Change the type option in the modal to use mono-select.
- Collapse the row action buttons into one menu icon that opens a dropdown of 3 items (Sematkan, Ubah, Hapus) so the action column stays minimal width.
- Make the Aksi column sticky.
- Add a Mono Skills entry.

## Summary
# Memo: `mono-select` type picker + `mono-dropdown` row actions + sticky Aksi column

Three table/form refinements on the typed-memo feature. The component APIs below were taken from the
**mono-helper `demos/*/vue/` examples** (the authoritative source — the llms doc only sketches them).

## `mono-select` (the type picker)
Replaced the segmented Teks/Checklist toggle with a select:
```html
<mono-select class="w-44" :items.prop="memoTypeOptions" key-value="value" display-value="label"
  :model-value.prop="store.input.type" @mno-change="store.onTypeChange($event)"></mono-select>
```
- `:items.prop` takes a plain `[{ value, label }]` array (DOM property, not attribute). `key-value` /
  `display-value` map which field is the value vs the label.
- The change event hands you the selected **value** at `$event.detail.modelValue`.
- `memoTypeOptions = memoTypes.map(t => ({ value: t, label: memoTypeLabel[t] }))` lives in `datas`
  (Rule 9). `store.onTypeChange(e)` reads `detail.modelValue` and calls the existing `setType(v)` so the
  content⇄items migration still runs.

## `mono-dropdown` (row actions menu)
Collapsed the 3 buttons (Sematkan/Ubah/Hapus) into one ⋮ icon that opens a menu — keeps the Aksi
column narrow:
```html
<mono-dropdown placement="bottom-end" :model-value.prop="store.actionMenuId === row.id"
  @mno-open="store.actionMenuId = row.id" @mno-close="store.actionMenuId = null">
  <mono-button slot="main" size="sm" variant="tonal"><span class="i-mdi-dots-vertical"></span></mono-button>
  <div slot="body" class="memo-actions"> …3 buttons… </div>
</mono-dropdown>
```
- **Slots:** `main` = the trigger, `body` = the panel. Default `trigger="click"`; built-in flip/shift.
- **Controlled single-open:** bind `model-value` to `actionMenuId === row.id` and sync via
  `mno-open`/`mno-close`. Each action button calls the store method **and** `closeActionMenu()`. This
  matters because **Sematkan re-sorts the row** (pinned-first) — an uncontrolled menu would linger on a
  row that just jumped. Only one row's menu is open at a time.
- The `body` items are plain light-DOM `<button class="memo-act">` (icon + label, hover, danger
  variant) styled in `memo-paper.css` — fully styleable, unlike a shadow-DOM menu.

## Sticky Aksi column
The table wrapper already has `overflow-x-auto`; with the extra Tipe column it can scroll. Pin the
action column to the right:
- header `<th>`: `sticky right-0 z-10 bg-gray-50 border-l border-gray-200`.
- each row `<td>`: `sticky right-0 z-10 bg-white border-l border-gray-100 memo-aksi`, where `.memo-aksi`
  adds a soft left shadow so it reads as a pinned column.
- The sticky cell needs an opaque background (to cover scrolled content), so the row `hover:bg-gray-50`
  doesn't tint it — the divider/shadow separates it instead.

## Rule 13
`mono-select` / `mono-dropdown` are used directly (they sit in the table/modal header, not on the
custom lined paper, so no native-CSS workaround is needed). Only the dropdown's light-DOM menu items
use page CSS.

## Files
- `src/datas/tables/memo.ts` (memoTypeOptions), `src/stores/use-memo.ts` (onTypeChange, actionMenuId,
  closeActionMenu), `src/pages/memo/index.vue`, `src/assets/memo-paper.css` (.memo-actions/.memo-act,
  .memo-aksi; removed the old .memo-type-toggle rules).

## Decisions
- Controlled single-open dropdown via actionMenuId — Bind mono-dropdown model-value to (actionMenuId === row.id), sync mno-open/mno-close, and close on every action. (Why: Sematkan re-sorts the row to the top (pinned-first); an uncontrolled menu would stay open over a row that jumped. Controlled state also guarantees only one row menu open at a time.)
- Light-DOM buttons in the dropdown body, styled in page CSS — The mono-dropdown `body` slot holds plain <button class='memo-act'> items, not a shadow-DOM menu component. (Why: Light-DOM items are fully styleable (hover, danger color, icon+label) and keep logic in the store; the dropdown only provides positioning/open-state.)
- Sticky Aksi column needs an opaque background — Sticky th/td use solid bg (bg-gray-50 / bg-white) + left border + soft shadow; the row hover tint doesn't reach the sticky cell. (Why: position:sticky cells must paint over horizontally-scrolled content, so they can't be transparent. The divider/shadow conveys the pinned column instead of the hover tint.)
- Component APIs sourced from the demos, not the llms doc — Used the mono-helper demos/*/vue/ examples for the exact mono-select / mono-dropdown slots, props, and event detail shape. (Why: The llms-full.txt only sketches these components; the vue demos are the authoritative, copy-pasteable usage (slot=main/body, :items.prop, $event.detail.modelValue).)

## Files changed
- src/datas/tables/memo.ts [modified] — Added memoTypeOptions ([{value,label}]) for the mono-select type picker
- src/stores/use-memo.ts [modified] — onTypeChange(e) -> setType(detail.modelValue); actionMenuId ref + closeActionMenu() (controlled single-open row menu); exported all
- src/pages/memo/index.vue [modified] — Type toggle -> mono-select; 3 action buttons -> one mono-dropdown menu (slot main/body, controlled); Aksi th/td made sticky right-0; imports mono-helper/ui/select + dropdown + memoTypeOptions
- src/assets/memo-paper.css [modified] — Added .memo-actions/.memo-act(.--danger) menu styles + .memo-aksi sticky shadow; removed unused .memo-type-toggle/.memo-type rules

## Commands
- pnpm dev
- curl /memo + page + store + datas (all 200)
- MONO_SKILLS=true MONO_SKILLS_GITHUB_TOKEN=[REDACTED] pnpm exec mono skills save --app my-memo --dir .mono/skills/pending/<id>

## Validation
- Tests: not run
- Build: passed

================================================================================
# Memo types: text | checklist (with checklist editor + .txt round-trip)
App: my-memo | Actor: YCEJ9999 | Date: 2026-06-21 14:00:00 | Status: completed
Topics: memo, memo-type, checklist, localStorage-migration, txt-round-trip, notebook-paper-ui, store-centric
Outcome: success — vite module transform + standalone round-trip test /memo, page, store, use-memo-utils.ts, datas all transform 200 UnoCSS generates i-mdi-format-list-checks / i-mdi-text / i-mdi-close Round-trip test passed: checklist serializes to 'Tipe: checklist' + '- [ ] '/'- [x] ' lines and parses back with item text + done state; text memos round-trip; text->checklist migration strips '1.'/'-' bullets

## User requests
- Give memos a type: text | checklist; the current memo is plain text.
- Checklist example: a shopping list — '5kg Tomato', '2kg apple' — with checkable items.
- Flag the type in the table (text | checklist).
- The form must show a checklist-style editor for checklist memos.
- Add a Mono Skills entry.

## Summary
# Memo types: `text` | `checklist`

Added a `type` to memos so a memo is either free **text** (the original) or a **checklist** of
checkable items (e.g. a shopping list: `5kg Tomato`, `2kg apple`). The table flags the type; the
notebook-paper form shows a checklist editor when the type is checklist. Fully backward-compatible
and round-trips through the existing `.txt` import/export.

## Data model (`src/datas/tables/memo.ts`)
- `type MemoType = 'text' | 'checklist'`; `interface ChecklistItem { text: string; done: boolean }`.
- `Memo` gains `type: MemoType` and `items: ChecklistItem[]` — text memos use `content`, checklist
  memos use `items` (kept mutually exclusive: on save, text → `items: []`, checklist → `content: ''`).
- `memoTypes` + `memoTypeLabel` (Teks/Checklist); a `{ field: 'type', caption: 'Tipe' }` table column.

## Backward compatibility (the important bit)
Memos saved before this feature have no `type`/`items`. `load()` runs a `normalize()` over every
record: `type ??= 'text'`, `items = Array.isArray(items) ? items : []`. So old localStorage data keeps
working — no migration step, no crashes on `m.items.some(...)`.

## Store logic (`src/stores/use-memo.ts`, Rule 15)
- `setType(t)` **migrates** between representations so the toggle "just works":
  - text → checklist: split non-empty `content` lines into items, stripping `1.` / `- ` / `*` bullets
    (`/^\s*(?:[-*]|\d+[.)])\s*/`).
  - checklist → text: join item texts back into lines.
- `addInputItem()` / `removeInputItem(i)` / `toggleInputItem(i)` edit `input.items`; item text uses
  plain `v-model` on `store.input.items[i].text`.
- `save()` canonicalizes by type and drops blank-text items. `filtered` also searches item text.
  `applyImported()` copies `type` + `items`. `exportMemo()` empty-guard also considers items.
- `checklistProgress(m) → { done, total }` for the table badge.

## `.txt` round-trip (`use-memo-utils.ts`)
The block gained a `Tipe: text|checklist` header. Checklist bodies serialize as **markdown
checkboxes**, one per line — exactly the user's list:
```
Tipe: checklist
----- ISI -----
- [ ] 5kg Tomato
- [x] 2kg apple
```
`parseMemos` reads `Tipe` (default `text`) and parses `^\s*-\s*\[( |x)\]\s?(.*)$` into items (done from
`x`); text memos keep `content`. Plain-text imports default to `type: 'text'`. A standalone test
confirmed full round-trip incl. done-state.

## UI (`src/pages/memo/index.vue` + `src/assets/memo-paper.css`)
- A **type toggle** (Teks | Checklist segmented pills) above the title; clicking calls `setType`.
- `type==='text'` → the existing lined textarea. `type==='checklist'` → a **checklist editor** on the
  ruled paper: each row = native checkbox (`accent-color: var(--memo-accent)`) + a borderless text
  input (Enter adds a new item) + a hover ✕ remove; a "+ Tambah item" button; done items get a
  strike-through. Table shows a type badge with progress (e.g. "Checklist · 1/2").
- **Rule 13 note:** native checkbox + input (styled in the page-local `memo-paper.css`), not
  `<mono-checkbox>` — the form is a custom notebook-paper surface where every field is native so it
  can sit on the ruled lines (shadow-DOM `mono-*` can't be styled into that). This is Rule 13's
  native-CSS-in-`src/assets` fallback, consistent with the title/content/category fields.

## Files
- `src/datas/tables/memo.ts`, `src/stores/use-memo.ts`, `src/composables/use-memo-utils.ts`,
  `src/pages/memo/index.vue`, `src/assets/memo-paper.css`.

## Decisions
- type + items[] on Memo (mutually exclusive bodies) — Added type: 'text'|'checklist' and items: ChecklistItem[]. On save, text → items:[], checklist → content:''. (Why: Keeps each type's body canonical and avoids stale data; the table/search/export branch on type cleanly.)
- Normalize old records on load (no migration step) — load() backfills type='text' and items=[] for any record missing them. (Why: Existing localStorage memos predate the feature; normalizing on read keeps them working and prevents undefined.items crashes.)
- Smart type-toggle migration — setType converts content lines ⇄ items (stripping 1./- bullets when going to checklist). (Why: The user's flow is 'list my checklist'; toggling should turn their typed lines into checkable items (and back), not lose data.)
- Markdown checkboxes in the .txt round-trip — Serialize checklist items as '- [ ]'/'- [x]' under a 'Tipe: checklist' header; parse them back. (Why: Human-readable, standard, and preserves done-state across export/import (and arbitrary .txt with such lines could be imported).)
- Native checkbox/input styled in memo-paper.css (Rule 13 fallback) — Did not use <mono-checkbox>; used native elements styled in the page-local CSS. (Why: The memo form is a custom notebook-paper surface; shadow-DOM mono-* can't be styled onto the ruled lines. Consistent with the existing native title/content/category fields; Rule 13 permits native CSS when components/UnoCSS can't express the styling.)

## Files changed
- src/datas/tables/memo.ts [modified] — MemoType + ChecklistItem; Memo gains type + items; memoTypes/memoTypeLabel; 'Tipe' table column
- src/stores/use-memo.ts [modified] — blank() type/items; load() normalize old records; setType migration; add/remove/toggle item; save canonicalize+trim; filtered searches items; applyImported copies type/items; exportMemo guard; checklistProgress
- src/composables/use-memo-utils.ts [modified] — Serialize 'Tipe' + checklist body as - [ ]/- [x]; parse type + items; plain-text fallback -> type text
- src/pages/memo/index.vue [modified] — Type toggle; conditional textarea vs checklist editor; table type badge + progress; import memoTypes/memoTypeLabel
- src/assets/memo-paper.css [modified] — memo-type-toggle; checklist rows on ruled lines (checkbox/input/remove, is-done strike); memo-add-item; small-screen flex-grow

## Commands
- pnpm dev
- curl /memo + page + store + utils + datas (all 200)
- node round-trip + migration test (all passed)
- MONO_SKILLS=true MONO_SKILLS_GITHUB_TOKEN=[REDACTED] pnpm exec mono skills save --app my-memo --dir .mono/skills/pending/<id>

## Validation
- Tests: not run
- Build: passed

================================================================================
# Move all memo page logic into the Pinia store (Rule 15)
App: my-memo | Actor: YCEJ9999 | Date: 2026-06-21 12:00:00 | Status: completed
Topics: memo, rule-15, pinia-store, thin-page, useFileSystemAccess-in-store, programmatic-file-input, refactor
Outcome: success — vite module transform + page-leftover grep /memo, page, store, and use-memo-utils.ts all transform 200 Page <script> is 22 lines (render-only); no fsa/useFileSystemAccess/fmtDate/val/fileInput left in the page Store now exposes exportMemo/importMemo/exportAll/importBatch/onSearch/inputAccent/fmtDate/yn/isSmallScreen + the private FSA helpers

## User requests
- Every possible logic should live in /stores; the page is too heavy.
- Create a Mono Skills entry.

## Summary
# Move all memo page logic into the Pinia store (Rule 15)

The `/memo` page had grown to ~160 lines of logic in `<script setup>` (file I/O, four
import/export actions, fallback handlers, two hidden `<input>` refs, `useMediaQuery`, formatters).
Rule 15 — **pages render, stores think, composables provide reusable helpers** — says that belongs
in the store. After the refactor the page `<script>` is **22 lines** (render-only) and
`use-memo.ts` owns everything.

## What moved into `src/stores/use-memo.ts`
- `useFileSystemAccess({ dataType: 'Text', … })` and `useMediaQuery('(max-width: 640px)')` — yes,
  VueUse composables run fine **inside a Pinia setup store** (it's an effect scope), and both are
  SSR-safe (they guard `window`/`document`), which matters for the Nuxt host's prod SSR.
- Actions: `exportMemo` / `importMemo` (prefill the form) / `exportAll` / `importBatch`.
- Private helpers that **dedupe the FSA-vs-fallback branching**: `readPickedText()` (open) and
  `saveText(text,name,okMsg)` (save), plus `applyImported(text)`.
- Render glue so the template stays declarative: `yn`, `fmtDate`, `onSearch(e)` (reads the
  `mono-input` CustomEvent), `clearSearch()`, and an `inputAccent` computed for the paper tint.

## The nice simplification: programmatic file-input fallback
The old page kept two hidden `<input type="file">` elements + refs + change handlers just for
non-Chromium import. In the store there's no template, so the fallback **creates the input in JS**:

```ts
function pickTextFile(): Promise<string | null> {
  return new Promise((resolve) => {
    const el = document.createElement('input')
    el.type = 'file'; el.accept = '.txt,text/plain'
    el.onchange = async () => { const f = el.files?.[0]; resolve(f ? await f.text() : null) }
    el.click() // cancel → no change event → promise stays pending (harmless)
  })
}
```
This removed both hidden inputs (and their refs/handlers) from the page entirely — fewer moving
parts, and all import paths funnel through one `readPickedText()`.

## Layering kept (per the user's choice)
Pure data transforms (`serializeMemo` / `serializeMemos` / `parseMemos` / `memoFileName` /
`backupFileName`) stay in the `use-memo-utils` composable — the store **consumes** it
(`const utils = useMemoUtilsMyMemo()`). So: page renders → store thinks → composable provides the
reusable helpers. Exactly Rule 15.

## Page after refactor
Script = side-effect `mono-helper/ui` imports + static-data imports (`memoCols`, `memoCategories`,
`memoCategoryAccent` — data, not logic) + `definePage` + `const store = useMemoMyMemo()` +
`onMounted(() => store.load())`. Every `@mno-click` / `@mno-input` calls a store method
(`store.exportAll()`, `store.onSearch($event)`, …); the modal sizing reads `store.isSmallScreen`;
the paper tint reads `store.inputAccent`.

## Gotcha
VueUse auto-imports (`useFileSystemAccess`, `useMediaQuery`) and the `useMemoUtilsMyMemo` composable
all resolve **inside the store file** — `unplugin-auto-import` scans `src/stores` too, same as it
already did for `useHelperMonoVue()`.

## Files
- `src/stores/use-memo.ts` — gained the FSA instance, the four file actions, the dedup helpers, and
  the render-glue (`onSearch`/`fmtDate`/`yn`/`inputAccent`/`isSmallScreen`).
- `src/pages/memo/index.vue` — reduced to render-only; removed the hidden inputs and all functions.
- `src/composables/use-memo-utils.ts` — unchanged (now consumed by the store).

## Decisions
- All orchestration/state/file-I/O lives in the store (Rule 15) — Moved FSA, the four import/export actions, fallbacks, useMediaQuery, and formatters from the page into use-memo.ts; the page only renders and calls store methods. (Why: Rule 15 (pages render, stores think) and the user's standing rule 'every possible logic on /stores'. Keeps logic reusable and the page declarative.)
- Pure serialize/parse stay in the use-memo-utils composable — Did NOT inline serialize/parse into the store; the store consumes useMemoUtilsMyMemo(). (Why: User chose to keep the helper layer. Rule 15 puts reusable pure helpers in a use-<name>-utils composable consumed by the store.)
- Programmatic <input> for the non-Chromium import fallback — Create the file input via document.createElement in the store instead of keeping hidden <input> elements + template refs in the page. (Why: The store has no template; building the input in JS removes two hidden inputs/refs/handlers from the page and funnels all imports through one readPickedText().)
- VueUse composables inside the Pinia store are fine — useFileSystemAccess / useMediaQuery are instantiated in the store setup. (Why: Pinia setup stores are an effect scope; both composables are SSR-safe (guard window/document), so they work in the Nuxt host (SSR) and the remote (SPA). Auto-import resolves them in src/stores too.)

## Files changed
- src/stores/use-memo.ts [modified] — Absorbed page logic: useFileSystemAccess + useMediaQuery instances; exportMemo/importMemo/exportAll/importBatch; private readPickedText/saveText/pickTextFile (programmatic input fallback) + applyImported; render glue yn/fmtDate/onSearch/clearSearch/inputAccent. Consumes useMemoUtilsMyMemo.
- src/pages/memo/index.vue [modified] — Reduced to render-only (~22-line script): static-data imports + store + onMounted(load). All handlers call store methods; removed the two hidden <input> fallback elements, fsa, formatters, and val.
- src/composables/use-memo-utils.ts [modified] — Pure serialize/parse helpers — now consumed by the store instead of the page (Rule 15 helper layer).

## Commands
- pnpm dev
- curl /memo + page + store + use-memo-utils.ts (all 200)
- MONO_SKILLS=true MONO_SKILLS_GITHUB_TOKEN=[REDACTED] pnpm exec mono skills save --app my-memo --dir .mono/skills/pending/<id>

## Validation
- Tests: not run
- Build: passed

================================================================================
# List-level export-all + batch-import, alongside per-memo modal import/export
App: my-memo | Actor: YCEJ9999 | Date: 2026-06-21 10:30:00 | Status: completed
Topics: memo, import-export, batch-import, useFileSystemAccess, two-input-fallback
Outcome: success — vite module transform + UnoCSS icon check /memo, page, store, and use-memo-utils.ts transform 200 Page exposes exportAll/importBatch/onBatchFile/batchInput; store re-exports importMemos; utils re-export serializeMemos/backupFileName UnoCSS generates i-mdi-database-import-outline and i-mdi-database-export-outline Multi-block serialize/parse round-trip was validated in an earlier session (2 memos, multiline)

## User requests
- Export ALL memos from the list to one .txt.
- Import a .txt and automatically add a batch of memos (like the original feature).
- Update Mono Skills.

## Summary
# List-level export-all + batch-import (alongside per-memo modal import/export)

The memo app now has **both** granularities of `.txt` I/O:
- **Per-memo (in the add/edit modal):** import a `.txt` to *prefill the form*; export the single
  open memo. (From `2026-06-21_memo-per-memo-import-export`.)
- **List-level (toolbar):** **Ekspor Semua** downloads every memo to one backup `.txt`; **Impor
  Batch** reads a `.txt` and **adds all the memos it contains** to the list at once.

This restores the original all-memos backup/restore and keeps the per-memo flow — they share the
same serialize/parse helpers and `useFileSystemAccess` instance.

## Key implementation point: two hidden fallback inputs
The page now triggers FSA `open()` for two different outcomes — *prefill the form* (per-memo) vs
*append a batch* (list). On non-Chromium browsers the fallback is a hidden `<input type=file>`, and
each path needs its **own** input + change handler, or a single shared input's `change` would route
to the wrong action:
- `fileInput` + `onFallbackFile` → `applyImported()` (writes `store.input`).
- `batchInput` + `onBatchFile` → `store.importMemos(parseMemos(text))` (appends to the list).
The Chromium FSA path can reuse the one `fsa` instance because each call `await`s and reads
`fsa.data.value` immediately, so there's no cross-talk.

## Helpers (restored / reused)
- `use-memo-utils.ts`: re-added `serializeMemos(memos)` (file header + one `===== MEMO =====`
  block per memo) and `backupFileName()`; `serializeMemo`/`memoFileName` (per-memo) and `parseMemos`
  stay. `parseMemos` already handles one-or-many blocks and a plain `.txt`, so a batch file, a
  single-memo file, or an arbitrary text file all import.
- `use-memo.ts`: re-added `importMemos(incoming): number` — append (merge) + persist + notif count;
  every imported memo got a fresh `crypto.randomUUID()` from `parseMemos`.
- `index.vue`: `exportAll()` / `importBatch()` / `onBatchFile()` + the two toolbar buttons
  (`i-mdi-database-export-outline`, `i-mdi-database-import-outline`) and the second hidden input.

## Files
- `src/composables/use-memo-utils.ts`, `src/stores/use-memo.ts`, `src/pages/memo/index.vue`.

## Decisions
- Keep both granularities (per-memo modal + list-level batch) — List toolbar gets Ekspor Semua / Impor Batch; the add/edit modal keeps per-memo Impor/Ekspor. (Why: User asked for the original all-memos export + batch import back, in addition to the per-memo modal flow. They share helpers, so both coexist cheaply.)
- Separate hidden file input per import action — fileInput+onFallbackFile (prefill form) and batchInput+onBatchFile (append batch) are distinct. (Why: On non-Chromium browsers the fallback is a hidden <input>; one shared input's change event can't distinguish 'fill the form' from 'add a batch', so each needs its own input + handler.)
- Batch import = merge with fresh uuids — importMemos appends; parseMemos assigns new crypto.randomUUID() to each. (Why: Merge avoids data loss; fresh ids prevent collisions when re-importing a backup exported from this same app.)

## Files changed
- src/composables/use-memo-utils.ts [modified] — Re-added serializeMemos(memos) (multi-block backup) + backupFileName(); kept serializeMemo/memoFileName/parseMemos
- src/stores/use-memo.ts [modified] — Re-added importMemos(incoming): number — batch append (merge) + persist + notif count; exported it
- src/pages/memo/index.vue [modified] — Added exportAll()/importBatch()/onBatchFile() + a SECOND hidden input (batchInput) so the batch fallback doesn't collide with the per-memo one; Ekspor Semua / Impor Batch toolbar buttons

## Commands
- pnpm dev
- curl /memo + page + store + use-memo-utils.ts (all 200)
- MONO_SKILLS=true MONO_SKILLS_GITHUB_TOKEN=[REDACTED] pnpm exec mono skills save --app my-memo --dir .mono/skills/pending/<id>

## Validation
- Tests: not run
- Build: passed

================================================================================
# Per-memo .txt import-into-form and single-memo export inside the add/edit modal
App: my-memo | Actor: YCEJ9999 | Date: 2026-06-21 09:00:00 | Status: completed
Topics: memo, import-export, useFileSystemAccess, form-prefill, ui-refactor, scope-correction
Outcome: success — vite module transform + wiring grep /memo, page, store, and use-memo-utils.ts transform 200 Page exposes exportMemo/importMemo/applyImported; utils export serializeMemo/parseMemos/memoFileName All all-memos remnants removed (backupOpen, exportBackup/importBackup, serializeMemos, store.importMemos, the dedicated backup modal + toolbar button)

## User requests
- Not an all-memos backup: when adding a memo, let the user import a .txt to FILL the form instead of typing.
- In the same add/edit modal, export the single memo being edited as a .txt.
- Update Mono Skills.

## Summary
# Per-memo `.txt` import-into-form + single-memo export (inside the add/edit modal)

Corrects the earlier "all-memos backup" design. The real requirement: when **adding** a memo the
user can **import a `.txt` to fill the form** (instead of typing), and from the **same add/edit
modal** they can **export the single memo** being edited as a `.txt`.

## Scope correction (the lesson)
"Downloadable .txt / backup" was first built as an **all-memos backup/restore** (toolbar, then a
dedicated modal). The user actually meant **per-memo, in the edit/add modal**: import fills the
open form; export downloads just the current memo. Removed the whole all-memos path:
`backupOpen` + the dedicated backup modal + the "Cadangan & Impor" toolbar button, the
`exportBackup`/`importBackup` functions, `serializeMemos`/`backupFileName` in utils, and the
`store.importMemos` action. Net code shrank.

## What it does now
- Two buttons in the **add/edit modal footer** (left of Batal/Simpan): **Impor .txt** and **Ekspor .txt**.
- **Import = prefill the form, not create.** `importMemo()` reads a `.txt` (via
  `useFileSystemAccess.open()` or the hidden-input fallback), parses the first memo, and writes its
  `title`/`content`/`category`/`pinned` onto `store.input`. The user reviews and then **Simpan** as
  usual (the store assigns id + timestamps on save). Importantly it sets the **form ref fields**,
  it does NOT push to the list.
- **Export = the current form memo.** `exportMemo()` serializes `store.input` (guard: needs a title
  or content) and saves via `saveAs({ suggestedName })`, falling back to a Blob/anchor download.
  Filename is a slug of the title: `memo-<slug>.txt`.

## Reused mechanics (unchanged from the FSA session)
- `useFileSystemAccess({ dataType: 'Text' })`; `isSupported`/`data` are refs (`.value`); guard
  `isSupported.value` with a Blob-download / hidden `<input type=file>` fallback; swallow the
  picker-cancel `AbortError`.
- Same human-readable round-trip block (`===== MEMO =====` header lines + `----- ISI -----` body),
  now emitted one block per file by `serializeMemo(memo)`; `parseMemos` is reused and also accepts a
  plain `.txt` (first line = title, rest = content), so importing an arbitrary text file works.

## Files
- `src/composables/use-memo-utils.ts` — replaced `serializeMemos`/`backupFileName` with
  `serializeMemo(memo)` + `memoFileName(memo)`; kept `parseMemos`.
- `src/stores/use-memo.ts` — removed `importMemos` (no longer needed; the page writes `store.input`).
- `src/pages/memo/index.vue` — `exportMemo()` / `importMemo()` / `applyImported()`; modal-footer
  buttons; removed the dedicated backup modal + toolbar button.

## Decisions
- Import PREFILLS the form, it does not create a memo — importMemo() parses the .txt and writes title/content/category/pinned onto store.input; the user then saves normally. (Why: User wanted to 'import instead of typing' while adding — so the file populates the open form and stays editable/reviewable before Simpan. Creation (id + timestamps) still happens in store.save().)
- Per-memo export from the edit/add modal, not an all-memos backup — exportMemo() serializes only store.input (the open memo) to memo-<title-slug>.txt. (Why: User corrected the earlier all-memos backup: they want to export the single memo being edited, from the same modal.)
- Removed the all-memos backup path entirely — Deleted the dedicated backup modal, the toolbar button, serializeMemos/backupFileName, and store.importMemos. (Why: It was a misinterpretation of 'backup'. Keeping dead code would confuse the next session; the per-memo design fully covers the actual need.)
- Kept the round-trip block format + parseMemos — serializeMemo emits one ===== MEMO ===== block; parseMemos is reused (handles one/many blocks and plain text). (Why: Preserves category/pinned/timestamps on re-import and still lets an arbitrary .txt import as a memo (first line = title).)

## Files changed
- src/composables/use-memo-utils.ts [modified] — Replaced serializeMemos/backupFileName with serializeMemo(memo) (single block) + memoFileName(memo) (title slug); kept parseMemos (reused for single import + plain-text)
- src/stores/use-memo.ts [modified] — Removed importMemos action (no longer used; the page prefills store.input directly)
- src/pages/memo/index.vue [modified] — Added exportMemo()/importMemo()/applyImported(); Impor .txt + Ekspor .txt buttons in the add/edit modal footer; import prefills the form fields; removed the all-memos backup modal, toolbar button, and exportBackup/importBackup

## Commands
- pnpm dev
- curl /memo + page + store + use-memo-utils.ts (all 200)
- MONO_SKILLS=true MONO_SKILLS_GITHUB_TOKEN=[REDACTED] pnpm exec mono skills save --app my-memo --dir .mono/skills/pending/<id>

## Validation
- Tests: not run
- Build: passed

================================================================================
# Move memo backup/import into a dedicated modal (follow-up to the FSA backup feature)
App: my-memo | Actor: YCEJ9999 | Date: 2026-06-21 00:15:00 | Status: completed
Topics: memo, backup-restore, ui-refactor, mono-modal, useFileSystemAccess, ux-grouping
Outcome: success — vite module transform + UnoCSS icon check /memo and the page module transform 200 One toolbar button (i-mdi-database-cog-outline, 'Cadangan & Impor') opens backupOpen; the two actions live inside the modal UnoCSS generates i-mdi-database-cog-outline, i-mdi-file-import, i-mdi-content-save-outline

## User requests
- Move the import + backup buttons out of the list toolbar and into a modal.
- Update Mono Skills.

## Summary
# Memo backup/import moved into a dedicated modal

Follow-up to `2026-06-20_memo-txt-backup-fsa`. The `useFileSystemAccess` backup/restore logic is
unchanged; only its **presentation** moved — out of the list toolbar and into its own modal.

## Change
- The list toolbar now has a **single** button — **"Cadangan & Impor"** (`i-mdi-database-cog-outline`)
  — that opens a dedicated `mono-modal` (`backupOpen` ref in the page).
- The modal body shows the memo count and **two action cards**: *Unduh cadangan* (calls
  `exportBackup()`) and *Impor .txt* (calls `importBackup()`); footer has *Tutup*.
- The modal **closes after a successful import** (both the FSA path and the fallback
  `<input type=file>` path set `backupOpen.value = false`), so the refreshed list is visible.
- It reuses the same responsive trick as the edit modal: `:width.prop`/`:height.prop = '100%'`
  when `useMediaQuery('(max-width: 640px)')`, so it's full-screen on phones.

## Why a dedicated modal (not the per-memo edit modal)
Backup/import operate on **all** memos, so they don't belong in the per-memo create/edit modal
(which is scoped to one memo). A separate "feature modal" keeps the list toolbar clean and groups
the two whole-list actions together. The underlying `useFileSystemAccess` + Blob/file-input
fallback + `AbortError`-on-cancel handling from the prior session all stayed the same.

## File
- `src/pages/memo/index.vue` — added `backupOpen` ref; replaced the two toolbar buttons with one
  opener; added the `mono-modal` with the two action cards; close-on-import. No change to
  `use-memo-utils.ts` or the store.

## Decisions
- Dedicated backup modal, not the per-memo edit modal — Put backup/import in their own 'Cadangan & Impor' modal opened by a single toolbar button, rather than inside the create/edit memo modal. (Why: Backup and import act on ALL memos; the edit modal is scoped to a single memo. A separate feature modal is the correct grouping and keeps the toolbar uncluttered.)
- Close the modal after a successful import — Set backupOpen = false after importMemos in both the useFileSystemAccess path and the fallback file-input handler. (Why: After importing, the user wants to see the updated list; leaving the modal open hides the result.)

## Files changed
- src/pages/memo/index.vue [modified] — Added backupOpen ref; replaced the two toolbar buttons with one 'Cadangan & Impor' opener; added a dedicated mono-modal with Unduh cadangan / Impor .txt action cards (responsive full-screen on small); close modal after successful import (FSA + fallback paths). FSA/serialize logic unchanged.

## Commands
- pnpm dev
- curl /memo + page module (200)
- MONO_SKILLS=true MONO_SKILLS_GITHUB_TOKEN=[REDACTED] pnpm exec mono skills save --app my-memo --dir .mono/skills/pending/<id>

## Validation
- Tests: not run
- Build: passed

================================================================================
# Memo .txt backup/restore with VueUse useFileSystemAccess
App: my-memo | Actor: YCEJ9999 | Date: 2026-06-20 23:30:00 | Status: completed
Topics: memo, backup-restore, useFileSystemAccess, vueuse, file-system-access-api, txt-serialization, browser-support-fallback, composable-helpers
Outcome: success — vite module transform + standalone round-trip test /memo, the page, the store, and use-memo-utils.ts all transform 200 UnoCSS generates i-mdi-file-import and i-mdi-content-save-outline Round-trip test passed: multiline content (incl. blank lines) preserved, timestamps/category/pinned restored, invalid category -> default, empty title skipped, plain .txt (no markers) -> one memo File-picker UI is Chromium-only and not clickable headless; logic guarded by fsa.isSupported with Blob/anchor + file-input fallback

## User requests
- Add a downloadable .txt backup of all memos, and import a .txt that recreates the memos.
- Use VueUse useFileSystemAccess.
- Write the finding to Mono Skills.

## Summary
# Memo `.txt` backup/restore with VueUse `useFileSystemAccess`

Add "download all memos to a `.txt`" and "import a `.txt`" to the localStorage memo app,
using the native file pickers via VueUse, with a fallback for non-Chromium browsers.

## `useFileSystemAccess` — the shape that works
Auto-imported from `@vueuse/core`. Create it once in `setup`, typed for text:

```ts
const fsa = useFileSystemAccess({
  dataType: 'Text',
  types: [{ description: 'Berkas teks', accept: { 'text/plain': ['.txt'] } }],
})
```
- **Save / download:** set the data, then open the save picker.
  ```ts
  fsa.data.value = text
  await fsa.saveAs({ suggestedName: 'memo-backup-2026-06-20.txt' })
  ```
- **Open / import:** `await fsa.open()` then read the populated ref.
  ```ts
  await fsa.open()
  const text = String(fsa.data.value ?? '')
  ```
- `fsa.isSupported` is a **computed ref** → check `fsa.isSupported.value`.
- `fsa.data` is a **ShallowRef** → `fsa.data.value`.

## Two gotchas
1. **Chromium-only.** `showSaveFilePicker` / `showOpenFilePicker` don't exist in Firefox/Safari,
   so `fsa.isSupported.value` is `false` there. Guard on it and fall back:
   - export → `URL.createObjectURL(new Blob([text], {type:'text/plain'}))` + a temporary
     `<a download>` click + `revokeObjectURL`.
   - import → a hidden `<input type="file" accept=".txt,text/plain">`; on change `await file.text()`.
     Reset `input.value = ''` afterward so re-selecting the same file fires `change` again.
2. **Cancelling the picker rejects with `AbortError`.** Wrap `saveAs()`/`open()` in try/catch and
   swallow `(e as DOMException).name === 'AbortError'` so a user cancel isn't reported as failure.

## Layering (mono Rules 8 / 15)
- **Pure serialize/parse** in a feature composable `src/composables/use-memo-utils.ts`, exported
  as one uniquely-named composable `useMemoUtilsMyMemo()` (auto-imported; Rule 8 unique name):
  `serializeMemos`, `parseMemos`, `backupFileName`.
- **Store** (`use-memo.ts`) gets `importMemos(incoming): number` — merge (append), `persist()`,
  notif the count. The parser assigns a **fresh `crypto.randomUUID()`** to every imported memo so a
  re-import can't collide ids.
- **Page** owns only the file I/O (FSA + fallback) and the toolbar buttons — it serializes
  `store.memos`, saves, or parses the opened text into `store.importMemos`.

## Round-trip `.txt` format (human-readable, full fidelity)
```
# Memo Backup — 2026-06-20  (2 memo)

===== MEMO =====
Judul: Belanja
Kategori: Pribadi
Disematkan: ya
Dibuat: 2026-06-19T10:00:00.000Z
Diperbarui: 2026-06-19T11:00:00.000Z
----- ISI -----
beli telur
beli susu
```
Parse = split on `===== MEMO =====` (drop the file-header chunk), read `Key: value` lines until
`----- ISI -----`, then the rest is content **verbatim** (multiline preserved). Robustness:
- invalid `Kategori` → falls back to the first category; `Disematkan` accepts ya/true/yes/1.
- a plain `.txt` with **no markers** → one memo (first non-empty line = title, rest = content),
  so arbitrary text files import too.
- Known limit (documented in code): content containing the literal marker lines isn't escaped.

A standalone round-trip test confirmed multiline+blank-line content, timestamps, pinned/category,
invalid-category fallback, empty-title skip, and plain-text import all behave.

## Files
- `src/composables/use-memo-utils.ts` (new) — serialize/parse + filename.
- `src/stores/use-memo.ts` — `importMemos(incoming)` merge action.
- `src/pages/memo/index.vue` — `useFileSystemAccess`, `exportBackup()`/`importBackup()`, the
  Blob/anchor + hidden-input fallbacks, and two toolbar buttons.

## Decisions
- useFileSystemAccess with isSupported guard + fallback — Primary path uses VueUse useFileSystemAccess (saveAs/open); when fsa.isSupported.value is false, fall back to Blob+anchor download and a hidden <input type=file>. (Why: The File System Access API is Chromium-only; the user asked for useFileSystemAccess but the app must still export/import in Firefox/Safari. One guard keeps both paths.)
- Readable round-trip .txt format, not JSON — Human-readable marker format (===== MEMO ===== header lines + ----- ISI ----- body); parser also accepts a plain .txt as a single memo. (Why: User chose readable text for a memo backup. Markers keep multiline content verbatim and round-trip every field; plain-text fallback lets any .txt import as a memo.)
- Merge on import with fresh uuids — importMemos appends; parseMemos assigns a new crypto.randomUUID() to every imported memo. (Why: User chose merge (no data loss). Fresh ids prevent collisions/overwrites when re-importing a backup that originated from this same app.)
- Layering: pure helpers in a composable, file I/O in the page — serialize/parse live in use-memo-utils.ts (useMemoUtilsMyMemo); the store gets importMemos; the page owns useFileSystemAccess + buttons. (Why: Rule 15 (feature helpers in use-<name>-utils) + Rule 8 (unique auto-imported names). Browser file pickers belong in the component setup, not the Pinia store.)

## Files changed
- src/composables/use-memo-utils.ts [added] — useMemoUtilsMyMemo(): serializeMemos / parseMemos (round-trip .txt + plain-text fallback, fresh uuids) / backupFileName
- src/stores/use-memo.ts [modified] — Added importMemos(incoming): number — merge/append + persist + notif count; exported it
- src/pages/memo/index.vue [modified] — useFileSystemAccess (dataType Text); exportBackup()/importBackup() with isSupported guard + Blob/anchor & hidden file-input fallback + AbortError swallow; Impor .txt / Unduh cadangan toolbar buttons

## Commands
- pnpm dev
- curl /memo, page, store, /src/composables/use-memo-utils.ts (all 200)
- node round-trip test of serialize/parse (all passed)
- MONO_SKILLS=true MONO_SKILLS_GITHUB_TOKEN=[REDACTED] pnpm exec mono skills save --app my-memo --dir .mono/skills/pending/<id>

## Validation
- Tests: not run
- Build: passed

================================================================================
# Notebook lined-paper UI for the Memo create/edit modal
App: my-memo | Actor: YCEJ9999 | Date: 2026-06-20 22:30:00 | Status: completed
Topics: memo, ui-styling, lined-paper-textarea, unocss, native-css-src-assets, rule-13-ui-priority, shadow-dom-limitation, css-variable-theming
Outcome: success — vite dev server + module transform + UnoCSS icon check GET /memo, the page module, and /src/assets/memo-paper.css all return 200 (no compile error) Compiled page references .memo-paper, .memo-paper__title/__content, memoCategoryAccent UnoCSS generates i-mdi-pin and i-mdi-pin-outline for the pushpin toggle No leftover mono-textarea / mono-switch references after the swap

## User requests
- The basic add/edit memo form is too plain — make the modal look like a real memo: a borderless 'blank' title and a lined notebook-paper writing area, with a pushpin and category tint.
- Write the finding to Mono Skills.

## Summary
# Notebook lined-paper UI for the Memo modal (mono-vue remote)

How to give a form a realistic "notebook paper" look inside a `mono-modal`, the right
way under Template Rule 13, and the one trick that makes text sit on the lines.

## Goal
The plain stacked Add/Edit memo form (mono-input + mono-textarea + select + mono-switch)
looked too basic. Turn the modal body into a sheet of ruled notebook paper: a borderless
"blank" title line, blue horizontal rules with the content resting on them, a red left
margin, a pushpin to pin, and the category tinting the page.

## Why native `<input>`/`<textarea>` here (Rule 13)
`mono-textarea` / `mono-input` are **shadow-DOM Lit web components** — you cannot paint a
ruled-line background onto the field inside their shadow root from outside. Rule 13's UI
priority is: mono component → its `.mono-*` CSS → UnoCSS → **native CSS in `src/assets/`,
imported only into the page that needs it**. A lined-paper field is exactly that last-resort
case, so the writing surface uses **native `<input>` + `<textarea>`** styled from a scoped
stylesheet. We still keep `mono-modal` (the popup shell) and `mono-button` (footer).

Native elements also simplify binding: plain `v-model="store.input.title"` on the reactive
store object — no need for the `mono-*` CustomEvent reader (`$event.detail.modelValue`). The
search box stays a `mono-input` and still uses that reader.

## The key trick — text that rests on the lines
A lined textarea = **`line-height` matched to a `repeating-linear-gradient`, with
`background-attachment: local`** so the rules scroll with the text:

```css
.memo-paper__content {
  --memo-line: 30px;                 /* MUST equal line-height */
  line-height: var(--memo-line);
  background-image: repeating-linear-gradient(
    to bottom,
    transparent 0,
    transparent calc(var(--memo-line) - 1px),
    #c9d6e8 calc(var(--memo-line) - 1px),
    #c9d6e8 var(--memo-line)
  );
  background-attachment: local;      /* rules scroll WITH the text, not fixed */
  border: none; outline: none; resize: vertical;
  background-color: transparent;
}
```
If the rules and text drift, adjust `--memo-line` and the field's top padding together — the
text baseline must land just above each gradient rule. `background-attachment: local` is what
keeps the rules aligned while the textarea scrolls.

## The rest of the sheet
- **Scope everything under a `.memo-paper` root class.** The stylesheet is a global `import`
  (`import '@my-memo/assets/memo-paper.css'`), so namespacing under one root prevents leakage
  into other pages / the federated example routes. Verified the list + other pages are unchanged.
- **Red margin** = `.memo-paper::before` absolute left rule at `--memo-margin` (44px); fields
  get `padding-left: calc(var(--memo-margin) + 12px)` to clear it.
- **Borderless title** = native `<input>` with `border: none; background: transparent`, a heavier
  `border-bottom`, bold + a handwriting font stack (`Segoe Print`/`Bradley Hand`/`Comic Sans MS`).
- **Pushpin** = an absolute top-right `<button>` toggling `store.input.pinned`; icon swaps
  `i-mdi-pin` ⇄ `i-mdi-pin-outline` (UnoCSS presetIcons / `@iconify/json` mdi), tilts + tints when pinned.
- **Category tint** = a single CSS variable `--memo-accent`, set inline from a
  `memoCategoryAccent: Record<string,string>` map kept in `src/datas/tables/memo.ts` (Rule 9).
  The paper root uses the *selected* category's accent (margin + pin); each category pill sets
  its own accent so the pill shows its color; the active pill fills with it.

## Files
- `src/assets/memo-paper.css` (new) — all paper styling, namespaced under `.memo-paper`.
- `src/datas/tables/memo.ts` — added `memoCategoryAccent` (static data in datas, Rule 9).
- `src/pages/memo/index.vue` — modal body swapped to the `.memo-paper` structure; dropped the
  now-unused `mono-helper/ui/textarea` + `mono-helper/ui/switch` imports; added the CSS import.

## Gotchas worth keeping
- `color-mix(in srgb, var(--memo-accent) 60%, #cbd2dd)` gives per-category pill/border tints
  from one accent var (modern browsers / Vite dev — fine here).
- Importing a plain `.css` file in an SFC injects it **globally** (not `<style scoped>`), so the
  root-class namespacing is what keeps it contained — that's the Rule 13-compliant pattern
  (file in `src/assets`, imported only by the one page).

## Decisions
- Native input/textarea for the lined paper, not mono-textarea — Built the writing surface from native <input>/<textarea> styled by a scoped src/assets stylesheet; kept mono-modal + mono-button. (Why: mono-textarea is a shadow-DOM web component — its internal field can't receive a ruled-line background from outside. Rule 13's last tier (native CSS in src/assets, imported only into the page) is the sanctioned path for this. Native elements also bind with plain v-model on the reactive store.)
- Lined effect via line-height-matched repeating-linear-gradient + background-attachment: local — One CSS var --memo-line drives both line-height and the gradient period; background-attachment: local keeps rules aligned while the textarea scrolls. (Why: This is the reliable way to make typed text rest on ruled lines that move with the content; mismatched line-height/gradient is what makes text drift off the lines.)
- Scope all paper CSS under a .memo-paper root class — Namespaced every selector under .memo-paper instead of using <style scoped> or global rules. (Why: A plain CSS import in an SFC is injected globally; with federated example routes also present, root-class namespacing prevents style leakage. Verified other pages and the memo list are unchanged.)
- Category accent as a single CSS variable from a datas map — memoCategoryAccent in src/datas/tables/memo.ts; set --memo-accent inline; margin, pin, and selected pill all read it. (Why: Keeps static data in datas (Rule 9) and themes the whole sheet from one variable, so adding a category is a one-line change.)

## Files changed
- src/assets/memo-paper.css [added] — Notebook lined-paper styling scoped under .memo-paper: ruled-line gradient textarea, red margin, borderless title, pushpin, category pills; tinted via --memo-accent
- src/datas/tables/memo.ts [modified] — Added memoCategoryAccent: Record<string,string> (per-category hex accents) — static data in datas (Rule 9)
- src/pages/memo/index.vue [modified] — Swapped modal body to native .memo-paper structure (v-model title/textarea, pushpin toggle, category pills); imported memo-paper.css + memoCategoryAccent; removed now-unused mono-helper/ui/textarea + /switch imports

## Commands
- pnpm dev
- curl /memo, /src/pages/memo/index.vue, /src/assets/memo-paper.css (all 200)
- MONO_SKILLS=true MONO_SKILLS_GITHUB_TOKEN=[REDACTED] pnpm exec mono skills save --app my-memo --dir .mono/skills/pending/<id>

## Validation
- Tests: not run
- Build: passed

================================================================================
# Memo CRUD page (localStorage) + renaming a mono-vue remote without breaking host federation
App: my-memo | Actor: YCEJ9999 | Date: 2026-06-20 19:00:00 | Status: completed
Topics: memo, localStorage-crud, vue-page, pinia-store, mono-helper-components, mono-skills-onboarding, app-rename, host-remote-federation, monoAlias
Outcome: success — vite dev server + module transform check + route table inspection After rename + adding the mono-vue base remote to apps[] + mono:sync, vite config loads and dev boots (ready in ~3.3s) GET /memo returned 200; /src/pages/memo/index.vue and /src/stores/use-memo.ts transformed by Vite with no error (200) typed-router.d.ts shows /memo plus federated example routes (/budget/alokasi, /master/user, /module-one/example) from the base remote Proven that renaming WITHOUT re-providing @mono-vue-root fails: 'Cannot find module @mono-vue-root/mono.config' at vite config load

## User requests
- Build a memo app with full CRUD persisted in localStorage, served at the /memo route.
- Add the resulting knowledge to Mono Skills (shared knowledge).
- Rename the app to my-memo (and update the host) so Skills save is not skipped.

## Summary
# Memo CRUD page (localStorage) + renaming a mono-vue remote without breaking host federation

Two reusable lessons from building `/memo` in the `mono-vue-remote` template:
a client-side CRUD pattern, and how to rename the remote app (needed so Mono
Skills will file history under a real name) without breaking the circular
host⇄remote federation.

## Part 1 — localStorage CRUD page (no backend, no OData)
The shipped `user` / `budget-alokasi` examples use `monoCreateFetcher` +
`monoDataGrid` (DevExtreme OData DataSource, server-side). For a **local,
backend-less** feature, keep the same **3-file convention** but swap the data layer:

- `src/datas/tables/memo.ts` — `Memo` interface, `MemoCol[]` columns,
  `memoSearchExpr`, `memoCategories`, `MEMO_STORAGE_KEY = 'my-memo:memos'`.
  Same shape as `user.ts` (default-export `{ index: colMemo }`).
- `src/stores/use-memo.ts` — Pinia `useMemoMyMemo` / `defineStore('memo-my-memo', ...)`.
  `load()` reads + `JSON.parse`s the key (try/catch → `[]`); private `persist()`
  does `localStorage.setItem`; `save()` create/update (`crypto.randomUUID()`,
  `new Date().toISOString()`), `remove(id)`, `togglePin(id)`, modal helpers; a
  `filtered` computed does client-side search over `memoSearchExpr` (pinned-first,
  then `updatedAt` desc). Reuse `useHelperMonoVue().notif` for toasts.
- `src/pages/memo/index.vue` — `definePage({ meta:{ layout:'home', title:'Memo' }})`,
  `onMounted(() => store.load())`. Single page; Add/Edit via `mono-modal`.

### mono-* web component binding
Pass objects as DOM props with `.prop` (`:model-value.prop`, `:checked.prop`,
`:dismissible.prop`). Read values from CustomEvents, not `v-model`:
`mono-input`/`mono-textarea` → `@mno-input`/`@mno-change` (value at
`$event.detail.modelValue`); `mono-switch` → `@mno-change` (prop `checked`);
`mono-modal` → `@mno-close`; `mono-button` → `@mno-click`. Helper:
`const val = e => e.detail?.modelValue`. For a plain string dropdown, a native
`<select v-model>` is simplest.

### Sidebar menu
In `mono.config.ts` `menu`, the host sidebar builds child links as
`joinUrl(item.url, child.url)`; a **childless** top-level item uses `item.url`
directly. So `{ title:'Memo', url:'/memo', icon:'i-mdi-note-text' }` routes to `/memo`.

## Part 2 — Renaming the remote (Mono Skills Template Rule 1) vs host federation
Mono Skills `save`/`retry` are **skipped while the app name is generic**
(`mono-vue`, `mono-host`, `mono-vue-remote`, `mono-vue-host`, `mono-nuxt-host`).
To file under a real name you must rename `name` in `mono.config.ts`. BUT there's
a **circular federation** that bites:

- The remote's config does `extends: [() => monoHostConfig]` (`@mono-host-root/mono.config`).
- The synced host config (`.mono/apps/mono-host/mono.config.ts`) does
  `import monoVueConfig from '@mono-vue-root/mono.config'` and `extends` it back.
- The `@<name>` / `@<name>-root` aliases are generated by `monoAlias()` from this
  repo's `name`. While `name: 'mono-vue'`, `@mono-vue-root` WAS the remote's own
  root, so the host's import resolved to the remote itself.

Rename `name` → `my-memo` and `monoAlias` now emits `@my-memo-root` and **drops
`@mono-vue-root`**. The synced host still imports `@mono-vue-root/mono.config`, so
vite config load fails before the server starts:
`Error: Cannot find module '@mono-vue-root/mono.config'` (thrown by jiti inside c12
while resolving the config). NOTE: `mono prepare` does NOT fix this — it is what
regenerates (and thus removes) the alias. `mono sync` re-pulls the host but it
still hardcodes `@mono-vue-root`.

### The fix that was used (both sides)
1. **This remote** `mono.config.ts`: set `name: 'my-memo'`, and **add the base
   remote to `apps[]`** so `@mono-vue-root` resolves again — now to a synced copy:
   ```ts
   apps: [
     { name: 'mono-host', url: '…/mono-nuxt-host/tree/main', type: 'nuxt', envToken: 'MONO_VUE_GITHUB_TOKEN' },
     { name: 'mono-vue',  url: '…/mono-vue-remote/tree/example-nuxt-host', type: 'vue', envToken: 'MONO_VUE_GITHUB_TOKEN' },
   ]
   ```
   `monoAlias` then emits `@mono-vue` / `@mono-vue-root` → `.mono/apps/mono-vue`.
2. **Host repo** (`mono-nuxt-host`): add a `my-memo` app entry pointing at the
   `memo-apps` branch (so the host federates this remote too).
3. Point this repo's own source imports at the new alias: `src/types/odata.d.ts`,
   `src/stores/use-memo.ts`, `src/pages/memo/index.vue` → `@my-memo/*`.
4. `pnpm mono:sync` (re-pull host + first-time download of the `mono-vue` base),
   then `pnpm mono:prepare`. Dev now boots.

### Trade-off (accepted here)
Adding `mono-vue` to `apps[]` **federates that branch's pages** — the app then
also serves `/budget/alokasi`, `/master/user`, `/module-one/example`, and the host
merges the `example-nuxt-host` config. The cleaner alternative is to repoint the
**host's** federation import from `@mono-vue-root` → `@my-memo-root` (and rename its
app entry), giving only `/memo` + host routes — but that needs the host edited and
re-synced. This session kept the base-remote federation.

### Skills save
Once `name` is non-generic, `mono skills save` works (no skip). `resolveAppId`
also honours an explicit `--app`, so `mono skills save --app my-memo` is robust.
Always run via the env wrapper: `pnpm run env:dev -- mono skills <...>`.

## Verify
`pnpm dev` → `http://localhost:2020/memo`: add a memo (persists across reload via
localStorage key `my-memo:memos`), edit (updates `updatedAt`), pin (sorts to top),
search (title/content/category), delete (stays gone after reload).

## Decisions
- localStorage store instead of OData DataSource — Persist memos in a reactive Pinia array synced to localStorage; client-side search/sort. (Why: The feature has no backend. The OData/monoDataGrid pattern from the user/budget examples needs a server; localStorage is the right data layer here.)
- Single-page modal CRUD instead of an [id] detail route — One /memo page; Add/Edit open a mono-modal form. (Why: localStorage needs no deep-linking, so a separate /memo/[id] route adds navigation cost without benefit.)
- Renamed app to my-memo (required for Mono Skills) and fixed federation by adding the base remote to apps[] — Set name: 'my-memo'. Renaming dropped the @mono-vue-root alias and broke the synced host config's `import '@mono-vue-root/mono.config'` (vite config load failed). Fixed by adding a mono-vue app entry (example-nuxt-host branch) to THIS repo's apps[] so monoAlias re-emits @mono-vue-root -> .mono/apps/mono-vue, plus adding a my-memo app entry on the host. Repointed src imports to @my-memo/*, ran mono:sync + mono:prepare. (Why: Mono Skills skips save for generic template names (Template Rule 1), so a real rename was needed. The circular host<->remote federation hardcodes @mono-vue-root; re-providing that alias via the base remote restores config loading without editing the host's federation import.)
- Kept the mono-vue base-remote federation (accepted trade-off) — Left mono-vue in apps[] rather than repointing the host's federation import to @my-memo-root. (Why: User chose the zero-extra-host-edit path. Trade-off: the app also federates the example branch's routes (/budget/alokasi, /master/user, /module-one/example) and merges that branch's config. The cleaner alternative (host import -> @my-memo-root, only /memo) was documented but not taken.)

## Files changed
- src/datas/tables/memo.ts [added] — Memo interface, MemoCol columns, memoSearchExpr, memoCategories, MEMO_STORAGE_KEY
- src/stores/use-memo.ts [added] — Pinia store useMemoMyMemo with localStorage CRUD + filtered computed + modal helpers; imports @my-memo/*
- src/pages/memo/index.vue [added] — /memo list + search + table + mono-modal create/edit form using mono-* components; imports @my-memo/*
- mono.config.ts [modified] — name 'mono-vue' -> 'my-memo'; added 'Memo' sidebar menu entry (/memo); added mono-vue base remote to apps[] so @mono-vue-root resolves after rename
- src/types/odata.d.ts [modified] — QDefault import alias @mono-vue/* -> @my-memo/*
- .mono/apps/mono-host/mono.config.ts [modified] — Host repo (mono-nuxt-host) gained a my-memo app entry; pulled via mono:sync. Host federation import still @mono-vue-root (resolved via the base remote).

## Commands
- pnpm mono:prepare
- pnpm mono:sync
- pnpm run env:dev -- vue-tsc --noEmit
- pnpm dev
- pnpm run env:dev -- mono skills check
- pnpm run env:dev -- mono skills save --app my-memo --dir .mono/skills/pending/<id>

## Validation
- Tests: not run
- Build: passed