Lumi/TODO.md

# TODO

This file tracks larger Lumi work that cannot safely be completed in one pass. Keep pending work under the relevant category and move completed items to the Done section with a short note.

## OKF Knowledge System

- Add `knowledge/core`, `knowledge/plugins`, `knowledge/community`, and `knowledge/corrections` directories with documented ownership rules.
- Implement OKF Markdown/frontmatter parsing with stable IDs, scopes, status, priority, tags, generated/editable flags, and timestamps.
- Generate fixed core/plugin OKF from routes, commands, schemas, plugin metadata, README docs, and defaults.
- Add admin-editable community OKF for community names, owner/admin names, bot name, currency, items, roles, lore, links, moderation rules, command rules, and local terminology.
- Add corrections OKF files created only through admin review.
- Implement safe placeholder resolution for core/plugin OKF references such as `{{community.currency.primary_name}}`.
- Preserve source metadata for every retrieved OKF chunk: path, id, heading, score, and excerpt.

## OKF Retrieval and Indexing

- Implement or adapt an OKF indexer that chunks Markdown by heading.
- Re-index only changed OKF files when possible.
- Enforce retrieval priority: active corrections, community OKF, plugin OKF, core OKF.
- Add retrieval boosts for corrections.
- Ensure missing placeholders never crash context injection.

## Feedback Loop

- Add thumbs up/down controls to Lumi chat answers.
- Store feedback payloads with rating, prompt, response, retrieved context, optional comment, model/provider, timestamp, and review status.
- Show an optional comment field for thumbs down and keep thumbs up lightweight.
- Ensure feedback never directly modifies OKF.

## Admin Feedback Review

- Add an admin feedback review page or section.
- Show prompt, response, rating, comment, retrieved OKF sources, model/provider, and timestamp for each feedback item.
- Add review actions: reviewed/no action, good, bad retrieval, bad response, missing knowledge, archive/delete.
- Add correction creation UI with title, tags, affected topic/file, and Markdown body.
- Save approved corrections as OKF files and re-index after save.
- Add links from feedback rows to generated correction files.

## Storage and Preservation

- Store feedback queue, review status, source context snapshots, and correction links in SQLite or existing app storage.
- Keep community OKF, corrections OKF, feedback/review data, and source metadata preserved across updates.
- Ensure generated OKF is reproducible and not accidentally overwritten by admin edits.

## Homepage Hero Embed Requirements

- Continue improving service-specific "why unavailable" messages where external providers expose enough signal.

### Discord Server Widget Hero

- Add optional Discord invite-to-server-ID lookup support if Discord server IDs are not known.

### Twitch Stream Hero

- Support additional configured parent domains for alternate hostnames.
- Support stream-only and stream-with-chat layouts.
- Respect Twitch minimum player size requirements.
- If live-only mode is enabled, check live status or gracefully hide/fallback when offline.
- Show a clear admin warning when the Twitch embed fails due to missing or incorrect parent domain.
- Add admin helper text explaining that Twitch embeds require the site domain to be allowed as a parent domain.

### YouTube Live Hero

- Support YouTube live video URLs, raw video IDs, and optional channel-based live lookup.
- For static live heroes, extract and use the provided live video ID.
- For automatic channel live detection, require YouTube API configuration.
- Cache live lookup results to avoid excessive API calls.
- Support optional live-only mode.
- Support optional YouTube live chat only when a valid live video ID exists.
- Support autoplay and muted settings.
- If live-only mode is enabled and no active stream is found, skip the hero or show fallback content.
- Show fallback/error states for private, removed, age-restricted, embedding-disabled, unavailable, or not-yet-live videos.
- Add admin helper text explaining that YouTube Live requires either a live video link or API-based channel lookup.

### YouTube Video Hero

- Show fallback/error states for private, removed, age-restricted, unavailable, or embedding-disabled videos.
- Detect embedding-disabled videos before save when a YouTube API key or another reliable server-side signal is available.

### External Embedded Content Hero

- Support generic external iframe embeds only for sites that explicitly allow embedding.
- Detect or gracefully handle sites that block embedding through `X-Frame-Options` or CSP `frame-ancestors`.
- Show an admin warning when an external site refuses to be embedded.

### Hero Embed Admin UX

- Show “why unavailable” information in the admin UI when a hero cannot render.

## Update Page UX Improvements

- Add async in-place checks for the older `/admin` and `/admin/settings` update buttons, matching `/admin/updates`.
- Continue simplifying advanced update terminology without hiding recovery-critical detail.

## Homepage Hero System

- Improve handling of live-only Twitch heroes and live-state detection.
- Add explicit Discord invite-to-widget guidance or lookup support if Discord server IDs are not known.

## Homepage Hero UX Improvements

- Review all homepage builder forms for non-technical usability.
- Add tooltips and inline explanations where appropriate.

## UI Text and Button Language

- Review all button labels, field labels, headings, helper text, warnings, empty states, and confirmation dialogs across Lumi.
- Replace technical/internal wording with clearer user-facing wording where possible.
- Keep AI-related wording precise enough for admins to understand model, provider, context, retrieval, embeddings, feedback, corrections, and OKF behavior.
- Review the update pages and simplify labels such as `Check plugin`, `Apply safe target`, and `Disable for recovery`.
- Prefer clear action labels such as `Check for updates`, `Update plugin`, `Use recommended version`, `Disable temporarily`, and `Start recovery mode`.
- Add short helper text below advanced or risky update actions explaining what will happen.
- Replace implementation-focused wording with task-focused wording wherever practical.
- Avoid exposing Git, branch, commit, target, repository, cache, migration, or rollback terms unless the user needs them.
- When technical terms are unavoidable, add short tooltips or inline explanations.
- Standardize common action wording across all pages: save, update, check, review, restore, disable, enable, archive, delete, retry, import, export, cancel, and confirm.
- Ensure destructive or system-changing actions have clear confirmation text.
- Ensure error messages explain both what went wrong and what the admin can try next.
- Review plugin management, core settings, update pages, homepage management, OKF management, feedback review, and AI configuration for inconsistent wording.
- Split highly technical pages into simple and advanced sections where practical.
- Hide rarely needed expert controls behind expandable advanced sections.
- Add examples for fields that expect URLs, model names, provider names, paths, selectors, or structured values.
- Ensure labels and helper text are suitable for non-technical admins without removing important admin-level specificity.
- Review localization/translation keys if present so simplified wording remains consistent across languages.

## Core Feedback System

First implementation pass completed 2026-06-18. Remaining feedback work is mainly optional screenshot capture/storage, richer duplicate detection, date/plugin/area admin filters, issue creation, OKF correction conversion, and deeper attachment/DOM snapshot handling. Keep the detailed checklist below as the remaining reference for hardening and follow-up passes.

- Implement a general core feedback system available to logged-in users only.
- Add a persistent feedback entry point somewhere logical in the UI.
- Add `/feedback` under the Community navbar section for logged-in users.
- Add `/admin/feedback` as the admin review entry point.
- Ensure the feedback system is core-level functionality and can cover any area, scope, feature, page, plugin, or UI element.
- Keep the AI Improvement Center separate from this system; it should continue handling AI reply quality feedback.
- Add a `wrong tool` classification to the AI Improvement Center for cases where the AI used the wrong tool, action, integration, or capability.

### Feedback Categories and Scope

- Use generic feedback categories based on issue type rather than feature-specific categories.
- Suggested categories:
  - bug
  - confusing wording
  - broken interaction
  - visual/layout issue
  - accessibility issue
  - missing feature
  - improvement suggestion
  - performance issue
  - permission/access issue
  - unexpected behavior
  - other
- Allow feedback to target:
  - the whole page
  - a specific clicked UI element
  - the current feature/page
  - a plugin
  - a broad system area
  - other/custom scope
- Encourage users to submit one feedback item per issue.
- Add helper text explaining that small, specific feedback reports are preferred over broad combined reports.

### Feedback Submission UI

- Add a feedback modal for creating feedback.
- The modal should be accessible from the persistent feedback button and from the custom context menu.
- Require logged-in user identity for all feedback submissions.
- Allow the user to enter:
  - short summary/title
  - category
  - severity/priority
  - scope/target
  - detailed description
  - optional steps to reproduce
  - optional expected behavior
  - optional actual behavior
- Support severity/priority values such as:
  - minor
  - confusing
  - broken
  - urgent
  - security/sensitive
  - suggestion
- Pre-fill feedback scope based on the current page or clicked element when available.
- Allow users to change the auto-detected scope before submitting.
- Show clear confirmation after feedback is submitted.

### Site-Wide Custom Context Menu

- Replace the standard browser right-click context menu across Lumi with a custom site-wide context menu.
- Include the following actions:
  - Back
  - Forward
  - Copy
  - Cut
  - Paste
  - Link to here
  - Hard reload
  - Feedback
- Ensure context menu actions respect browser permissions and limitations.
- Ensure copy, cut, and paste only appear or work where appropriate.
- Implement “Link to here” by creating a URL to the current page and, when possible, the clicked element or section.
- Implement “Hard reload” as a cache-bypassing reload comparable to a developer hard refresh where possible.
- Add the Feedback action to open the feedback modal with the clicked element as the target.
- Preserve keyboard accessibility and provide fallback behavior if custom context menu features are unavailable in a browser.

### Element-Targeted Feedback

- When feedback is opened from the context menu, capture the clicked element as the feedback target.
- Store safe metadata about the clicked element, such as:
  - selector or generated stable path
  - element tag
  - visible text snippet
  - aria-label/title/role when available
  - nearest form label or heading
  - page URL
  - page title
  - viewport size
- Do not store sensitive field values from passwords, tokens, secrets, or private inputs.
- Allow users to choose whether feedback is about the clicked element, the whole page, the current feature, a plugin, or another scope.
- Highlight the selected target while the feedback modal is open when practical.
- Remove the highlight when the modal closes.

### Optional Screenshot Support

- Add optional browser-generated screenshot support.
- Screenshots must be opt-in by the submitting user.
- Do not require screenshots for feedback submission.
- Support full-page screenshots where technically possible.
- Support cropped/section-only screenshots where technically possible.
- Temporarily hide feedback buttons, feedback modals, context menus, and feedback overlays while capturing screenshots.
- Restore hidden feedback UI immediately after capture.
- Store screenshots only when explicitly attached by the user.
- Clearly warn users not to include sensitive information in screenshots.
- Allow users to remove an attached screenshot before submitting.

### Optional Diagnostic Data

- Automatically attach basic non-sensitive context:
  - user ID
  - current URL
  - page title
  - timestamp
  - selected scope
  - target metadata if element-targeted
- Make browser/user agent and screenshot/DOM snapshot optional opt-in fields.
- If DOM snapshot support is added, sanitize it before storage.
- Do not capture sensitive form values, passwords, tokens, secrets, private messages, or hidden data.
- Clearly label optional diagnostic data so users understand what they are submitting.

### Feedback Visibility for Users

- On `/feedback`, show logged-in users a general list of current and past feedback that has not been deleted.
- Public/general feedback list should only show basic non-identifying information:
  - summary
  - category
  - general scope
  - status
  - created date
  - last updated date
- Do not expose submitter identity in the general feedback list.
- Allow users to see their own feedback in detail.
- Make it easy to distinguish the current user’s own feedback from general feedback.
- Consider a separate “My feedback” section or a clear badge/label in the shared list.
- Allow users to add comments to their own feedback when follow-up is needed.
- Allow users to see admin replies that are visible to the submitter.

### User Feedback Notifications

- Add per-user feedback notification badges.
- Show a green badge/sphere with the number of the user’s feedback items solved since they last opened the feedback center.
- Show a red badge/sphere with the number of the user’s feedback items marked as needing more context.
- Show a grey badge/sphere with the number of the user’s feedback items marked as declined, rejected, duplicate, won’t fix, not planned, or otherwise not being worked on.
- Reset or update badge counts when the user opens the feedback center and views the relevant items.
- Ensure notification badges only reflect the logged-in user’s own feedback.

### Feedback Statuses

- Support feedback statuses such as:
  - new
  - reviewed
  - accepted
  - planned
  - in progress
  - fixed
  - solved
  - needs more context
  - duplicate
  - rejected
  - not planned
  - won’t fix
  - archived
  - deleted
- Allow admins to change status from the admin review UI.
- Store status history with timestamps and actor information.
- Show user-friendly status names and explanations on `/feedback`.

### Replies, Comments, and Work Notes

- Allow admins to reply to feedback.
- Allow submitters to comment on their own feedback.
- Allow admins to add private internal work notes that are not visible to normal users.
- Allow admins to mark feedback as “needs more context”.
- When feedback is marked “needs more context”, notify the submitter through the red feedback badge.
- Allow the submitter to add additional context/comments after the request.
- Distinguish clearly between public/admin replies, submitter comments, and private admin work notes.

### Admin Feedback Review

- Add `/admin/feedback` for admin feedback review.
- Admins should be able to view full feedback details, including:
  - submitter
  - summary
  - description
  - category
  - severity
  - scope
  - target metadata
  - current URL
  - browser/user agent if submitted
  - screenshot if submitted
  - DOM snapshot if submitted
  - comments/replies
  - work notes
  - status history
- Add filters for:
  - status
  - category
  - severity
  - scope
  - plugin/area
  - submitter
  - date
  - needs admin action
- Add sorting by newest, oldest, severity, status, and last activity.
- Add admin actions:
  - change status
  - assign category
  - change severity
  - reply to submitter
  - add internal work note
  - request more context
  - mark duplicate
  - archive
  - delete
  - convert to TODO
  - convert to issue
  - convert to OKF correction where relevant
  - link to existing TODO/issue/correction

### TODO and Issue Conversion

- Allow admins to convert feedback into a TODO entry.
- Support injecting generated TODO entries into `TODO.md`.
- Preserve the existing TODO format when injecting new entries.
- Allow admins to edit the generated TODO text before saving.
- Add enough context to generated TODO items to be useful for later Codex work.
- Allow admins to convert feedback into a GitHub/Gitea issue if configured.
- Allow admins to link feedback to manually created TODOs or issues.
- Store links between feedback items and generated TODOs/issues.
- Do not automatically create TODOs or issues without admin confirmation.

### OKF and AI Improvement Integration

- Keep this feedback system separate from AI reply feedback.
- Do not use this feedback system to rate individual AI replies.
- Use the AI Improvement Center for AI answer quality, wrong answers, bad context, and correction review.
- Add `wrong tool` as a classification in the AI Improvement Center.
- Allow core feedback to cover AI features, AI UI, AI configuration, and AI workflow problems.
- Allow admins to convert relevant core feedback into OKF corrections only when the feedback concerns documentation, feature behavior, terminology, or community/system knowledge.
- Do not automatically modify OKF based on general feedback.

### Rate Limits and Abuse Prevention

- Add moderate rate limits for feedback submissions.
- Rate limits should prevent spam without blocking normal use.
- Encourage one feedback item per issue.
- Add validation to prevent empty or extremely vague feedback.
- Add optional duplicate detection based on similar title, scope, and page.
- If similar existing feedback exists, suggest adding a comment or upvote/support instead of creating a duplicate.
- Allow admins to delete or archive abusive/spam feedback.

### Data Storage and Preservation

- Store feedback data in SQLite or the existing app storage system.
- Store screenshots and optional attachments in a protected feedback uploads/storage directory.
- Preserve feedback data across repo updates, ZIP updates, migrations, and recovery operations.
- Include feedback data in the protected user-data list for backups and update preservation.
- Never overwrite feedback data during core/plugin updates.
- Include feedback data in backup/restore planning.
- Store enough metadata for auditability:
  - created_at
  - updated_at
  - submitter_id
  - assigned_admin_id if used
  - status history
  - comments/replies
  - linked TODOs/issues/corrections

### Privacy and Safety

- Do not expose submitter identity in the general feedback list.
- Only admins should see submitter identity and full diagnostic details.
- Users should only see full detail for their own feedback.
- Sanitize all submitted HTML/text before rendering.
- Avoid capturing sensitive form values.
- Make optional diagnostic capture transparent to users.
- Add admin controls for deleting sensitive feedback, screenshots, or diagnostic data.
- Ensure permissions are enforced server-side, not only in the UI.

### Acceptance Criteria

- Logged-in users can submit general feedback from a persistent UI entry point.
- Logged-in users can submit targeted feedback from the custom right-click context menu.
- Right-click context menu includes Back, Forward, Copy, Cut, Paste, Link to here, Hard reload, and Feedback.
- Feedback modal can target the whole page, clicked element, current feature/page, plugin, broad system area, or custom scope.
- Users can optionally attach browser-generated screenshots while feedback UI is hidden during capture.
- `/feedback` appears under the Community navbar section for logged-in users.
- `/feedback` shows general non-identifying feedback summaries and detailed feedback for the current user’s own submissions.
- Users see per-user notification badges for solved, needs-context, and not-worked-on feedback.
- Admins can review and manage feedback at `/admin/feedback`.
- Admins can reply, add work notes, request more context, change statuses, and convert feedback to TODOs/issues/corrections.
- Feedback data is preserved across updates and included in protected user data.
- AI reply feedback remains handled by the AI Improvement Center, with an added `wrong tool` classification.

## Done

- 2026-06-18: Added a core feedback system first pass on `experimental-feedback-system`: SQLite feedback entries/comments/status history/view state, logged-in `/feedback`, admin `/admin/feedback`, persistent feedback modal, site-wide custom context menu with element-targeted feedback, per-user notification badges, admin replies/work notes/status changes/TODO conversion, and AI Improvement Center `wrong_tool_usage` confirmed present.
- 2026-06-17: Added Economy cleanup for fallback-name artifact users such as `SammyCat-2`, merging them into matching real platform users and making Economy stats tolerate missing/mid-migration tables; bumped Economy Framework to v0.2.9.
- 2026-06-17: Fixed update metadata for renamed Economy plugins so legacy installed rows are folded into canonical `economy-*` plugin update rows instead of appearing as separate installs; bumped core to v0.1.8.
- 2026-06-17: Renamed all remaining Economy internals from the old misspelled IDs/paths/tables to `economy-*`, added startup migration for legacy plugin rows, settings, command usage IDs, tables, uploads, asset paths, old URLs, and bumped core/plugin patch versions.
- 2026-06-17: Fixed user-facing Economy spelling, restored `/stats/{username}` Compare toggling, linked Top commands run leaderboard entries to `/commands`, and bumped core/plugin patch versions.
- 2026-06-17: Fixed custom command Edit buttons and `/commands` Copy Link / expand buttons with delegated handlers, clipboard fallback, and v0.1.5 patch bump.
- 2026-06-17: Fixed repo-based core updates deleting `data/update-cache/repo` during apply, added a verification guard, and bumped core package version to v0.1.4.
- 2026-06-17: Bumped core package version to v0.1.3.
- 2026-06-17: Completed homepage hero embed pass for Discord widgets, YouTube video playback options, external embed fallback/sandbox controls, admin validation, platform-specific fields, and Test preview behavior.
- 2026-06-17: Fixed core update snapshots for large ZIP-origin installs by replacing the full-install ZIP backup with a filesystem snapshot directory, avoiding the 2 GiB ZIP limit for large preserved files such as local AI models.
- 2026-06-17: Completed `/admin/updates` UX pass: viewport-fixed dismissible notifications, auto-dismiss for non-critical results, async core/plugin check actions without page refresh or scroll jumps, in-place update-card data refresh, loading states, and collapsed advanced Manual ZIP fallback below repo update containers.
- 2026-06-17: Completed homepage hero reliability pass: server-side hero validation before save, admin-visible validation errors, home-page fallback message for broken legacy heroes, automatic YouTube/Twitch/Discord embed derivation, correct Twitch parent host at render time, and image/embed conflict handling.
- 2026-06-17: Completed homepage hero builder UX pass: friendlier labels, contextual help text, normal URL paste support, automatic embed filling, per-row readiness messages, and test preview support.
- 2026-06-17: Fixed homepage links to support local Lumi paths such as `/commands`, and made unavailable live-only heroes fall through to lower-priority heroes instead of blocking the homepage.
- 2026-06-17: Completed update-page wording cleanup for common actions such as check, update, restore previous version, disable temporarily, and ZIP rollback wording.
- 2026-06-17: Added permanent repo-update architecture for ZIP-origin installs using `data/update-cache/repo`, non-live-git metadata checks, snapshot-copy apply, update-state recording, and preservation of user-owned paths.
- 2026-06-17: Separated Lumi AI `tool_info.json` tools from normal plugin update rows and rendered tools under the `lumi_ai` plugin row.