MyAnythingList Canonical English Docs
Freshness: 2026-03-12 v14 • Standard navigation header/footer • Every document should reveal freshness immediately at the very top and bottom.
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.
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.
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
The system should remain usable and understandable even on
simple infrastructure and inexpensive hosting.
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 Full Integration Additions — System Governance, Determinism, and Package Continuity
The system must be governable by documents, testable by automation, and maintainable by future contributors who were not present during the originating conversations.
Deterministic system expectations
- Given the same state, the same source inputs, the same language resources, and the same export target, the system should produce the same ordered composition plan and materially equivalent output.
- Timing-sensitive components such as QR generation must report readiness explicitly so export can wait for a valid render state rather than guessing.
- System defaults must be documented, not hidden. If the system uses a default output format, default language, or default control state, the docs must say so.
Documentation package continuity
- Each update cycle should create a new timestamped
doc_updates_YYYY-MM-DD_HHMMSS/_docs/en/ package.
- The package should also contain a
files/ subfolder with working reference materials from the current session so future sessions can recover context locally.
- Index navigation must be widened over time to include all documents that have current useful content, not just the original core pages.
System role of docs
- Conversation is a temporary design surface. Documentation is the durable system brain.
- When conversation and docs disagree, the durable path is to update docs immediately so the inconsistency disappears.
- The system is not considered fully specified until its commands, edge cases, and acceptance tests are documented.