System

system_en.html

This document explains how the MyAnythingList system is deployed, hosted, archived, and maintained operationally.

Architecture describes how the software works internally. System describes how it runs in the real world.

1. Hosting Philosophy

The system is intentionally designed to run on simple infrastructure.

• Static hosting is preferred whenever possible.
• Complex server frameworks are avoided.
• CPU-heavy server processing should be minimized.
• Client-side logic performs most rendering.

2. Typical Hosting Architecture

Authoring VPS
      ↓
Build / Testing
      ↓
Static publish
      ↓
S3 or CDN hosting
      ↓
Public browsers / kiosks

• Authoring and mastering occur on a development VPS.
• Public content may be served from object storage.
• CDNs may be used for global distribution.

3. Documentation Tree

_docs/
   index-docs.html
   en/
      index_en.html
      requirements_en.html
      architecture_en.html
      system_en.html
      developer_en.html
      vision_en.html

• Each language has its own folder.
• Documents are directly browsable.
• File system transparency is intentional.

4. Multilingual Documentation

The documentation architecture is designed for translation.

• English documents act as the canonical source.
• Other languages mirror the same structure.
• Translations may be human or AI assisted.

_docs/
   en/
   es/
   fr/
   de/
   zh/

5. Static Deployment

The player itself is a static HTML + JavaScript application.

• No database is required.
• No backend runtime is required.
• Static hosting platforms can serve the entire application.

6. Logging

Usage can be monitored using normal web server logs.

• Apache access logs
• S3 access logs
• CDN request logs

• player usage
• playlist loading
• bot activity
• traffic sources

7. Daily Builds

Development builds may be archived in dated directories.

beta/
   _daily-builds/
      2026-03-11/
      2026-03-12/

8. Public Mirrors

The project is intentionally mirror-friendly.

• Static file trees can be mirrored easily.
• Documentation folders can be copied directly.
• S3 object trees can act as distributed mirrors.

9. Operational Goal

v09 Delta — Current Implementation Focus

• Correct Fit Width + Digital so it uses all available width.
• Repair Fit Everything so the full visible grid actually fits inside the usable viewport.
• Keep Fit Height behavior intact as the working reference.
• Ensure QR export remains present whenever QR is visible in the live tile.

Updated: 2026-03-12 v09

v10 Delta — Active Issues and Corrections

• v09 regression: startup QR positioning regressed after previously being corrected in an earlier build. The system must retain the fixed startup QR path across later iterations.
• Header text toggle: the Show Header Text control must repopulate and reveal the standardized header text instead of leaving the top area blank.
• Uploaded thumbnails: uploaded custom images must fit the panel logically and export consistently.
• URL art: URL art should scale into the readable thumbnail area more aggressively while remaining legible and visually larger than the smaller footer URL.

v11 Delta — Client Runtime Logging

In addition to normal server access logs, the player now maintains an in‑browser runtime log.

• The log records startup events, parsing, layout passes, QR placement, and export activity.
• Logs are stored in memory only and cleared on refresh.
• Users may open a log viewer and download logs for debugging.

v11 Delta — Common Tile Export Pipeline

• The runtime now treats tile selection and JPEG export as a shared pipeline. Selection updates visible tile focus first, then schedules a background JPEG preparation task for the selected tile.
• The download button is a front-end trigger for this pipeline. If JPEG output is already prepared it downloads immediately; otherwise the request remains queued until preparation completes and then downloads automatically.
• The startup-prearmed first tile remains a deliberate exception to the standard two-step activation rule.

Updated: 2026-05-06 v11

v12 Delta — Input-Acknowledgment Discipline

• The runtime should separate input acknowledgment from task completion. Acknowledgment happens first and immediately; processing, export, rendering, and download work proceed afterward.
• The app should treat button responsiveness as shell-level behavior, not as an optional property of individual features.
• Any button that waits to show feedback until after synchronous work, promise scheduling, rendering, or export preparation has already failed the intended behavior model.

Updated: 2026-05-06 v12

v13 Delta — Immediate Acknowledgment, Then Work

• The input pipeline should be modeled as pointer-down acknowledgment first, then immediate task start in the same interaction cycle once the acknowledgment state has been applied.
• The runtime must not delay job start until feedback animation completion, and it must not delay feedback while waiting on export, parsing, rendering, navigation, or download logic.
• Startup tile choice is fixed to tile 1 in the current system design. Any apparent randomization before an explicit shuffle feature exists is a regression.

Updated: 2026-05-06 v13