Docs Index Requirements Architecture Developer System Thumbnail System Playlist Format Editor Guide Quickstart Printing Streams Vision Manuscript

Canonical docs package: 2026-03-12 v03 • Updated from prompt-defined packaging rule • Last curated: 2026-03-12

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.

Canonical Packaging State

Each relevant prompt must update the docs package as a tracked system output, not just the application.
The current package root for this iteration is 2026-03-12/.
The current canonical docs folder is canonical-docs-2026-03-12-v03/.
The current paired beta artifact is index_beta_2026-03-12-v03.html.
Versioned zip packages must unpack without overwriting prior iteration folders.

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.

A major design goal is that a media wall can be deployed using only static files on inexpensive hosting.

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.

Examples:

Apache access logs
S3 access logs
CDN request logs

These logs allow operators to see:

player usage
playlist loading
bot activity
traffic sources

7. Daily Builds

Development builds may be archived in dated directories.

Example:

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

These builds provide transparency into development progress.

Daily build review should feed back into the canonical docs. When a live bug or visual mismatch is discovered in beta, the related spec and operations docs should be updated during the same working cycle so the issue is not lost in transient discussion.

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.

8.5 Current Visual/Startup Issues to Track

The March 12 working set identifies a startup QR positioning bug and a URL-art/export mismatch that should be treated as active tracked issues until resolved in code.

On startup, QR placement may appear incorrect before later settling into the correct tile-relative position.
Downloaded URL-art imagery may diverge from the live WYSIWYG composition.
The intended behavior is full-URL best-fit visibility within the tile whenever practical, with clipping reserved for extreme cases.

9. Operational Goal

The system should remain usable and understandable even on simple infrastructure and inexpensive hosting.