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.

v14 Delta — Educational Mission, Transparency, and Misuse Resistance

MyAnythingList is a public educational system intended to help ethical, curious, and globally diverse people learn how information can be structured, inspected, rendered, and shared. The project should favor transparency, inspectability, multilingual access, and source-aware communication over black-box presentation.

• Open documentation, visible runtime logs, and educational commentary in code are intentional safeguards.
• The system should encourage understanding, attribution, and critical inspection rather than manipulative opacity.
• Language support should treat world language communities equitably, including both LTR and RTL interfaces.
• The project should be designed so good-faith users can learn it quickly and adapt it responsibly.
• No documentation update should erase the project’s educational and civilizational purpose.

Updated: 2026-03-12 v14

2026-03-17 Conversation Additions

2026-03-17 Additive Expansion: This section formalizes the project as a self-sufficient, globally deployable, append-only specification system. Nothing below removes or weakens the original system guidance; it extends it.

A. Canonical System Contract

The system contract now explicitly includes rendering, export, scripting, localization, verification, and documentation preservation. A build is not considered complete if it only renders tiles; it must also be explainable, reproducible, testable, and maintainable by later contributors without private author memory.

• Canonical docs define expected behavior.
• Application code implements that behavior.
• Acceptance tests verify that implementation still matches the docs.
• Failure-condition docs define what counts as regression.
• Release checklist governs publication discipline.

B. Preservation / No-Loss Rule

No previously documented information may be removed, shortened, summarized, or replaced by a lower-detail version. The documentation system is append-only unless there is a precisely justified correction of factual error. This rule exists because earlier AI passes compressed the docs and thereby lost coverage. That must never happen again.

• New behavior is added to existing documents in topic-appropriate locations.
• New standard documents may be added when a major topic deserves a dedicated home.
• Updates must preserve original filenames and package structure unless a deliberate package migration is itself documented.
• File-size decreases are treated as warning signs of potential information loss.

C. World-Scale Education Deployment Rule

The system is explicitly intended for schools worldwide. Therefore localization, multilingual legibility, script support, and robust documentation are no longer optional niceties. A system that works only for English-speaking developers or only for one UI width is not system-complete.

• All controls and labels must be localizable.
• LTR and RTL languages must be supported structurally, not cosmetically.
• Text rendering quality rules apply across scripts, not only Latin text.
• Documentation must remain understandable to future open-source contributors globally.

D. Scripting and Automation Contract

The system now includes a documented scripting surface. Programmatic control is part of the canonical system because reproducibility requires a stable way to set state, render, and export without relying on manual clicking. Scripting commands must map cleanly onto canonical state rather than bypassing it.

• Commands and functions belong in commands-and-functions_en.html.
• Argument semantics belong in the scripting interface documentation and in developer/system references.
• Scripted behavior must obey the same rendering, export, localization, and preservation rules as the UI path.

E. Verification Layer

The package now assumes a verification layer consisting of acceptance tests, failure conditions, golden render cases, and release-checklist controls. These documents exist so later contributors can detect regressions such as missing QR, blurred text at 8K, layout drift between live and export, broken multilingual labels, or documentation shrinkage.