developer_en.html
This document describes how developers should understand, extend, and maintain the MyAnythingList system.
Future developers should not need historical chat logs to understand how the system works.
Playlist text ↓ URL discovery ↓ Command parsing ↓ Tile model creation ↓ Thumbnail / QR resolution ↓ Grid rendering
The parser extracts valid URLs from any UTF-8 text.
Rules:# are comments.#_Command().
My research notes:
https://example.com/article
#_ReplaceThumbnailWithImage("cover.jpg")
Commands extend playlist behavior.
Examples:
#_ReplaceThumbnailWithImage("image.jpg")
#_LoadImage("panel.png")
#_LoadImageHideLinks("poster.png")
Commands apply to the most recent URL unless otherwise defined.
Runtime state is controlled by configuration variables.
Examples:Command thumbnail → Uploaded thumbnail → Platform thumbnail → Fallback imageRules:
The project aims to remain understandable to future developers and AI systems for decades.
Runtime-state rule: if a control affects live wall geometry or display composition, it should normally exist in three places at once: the control panel, window.MyAnythingListConfig, and GET/state URL handling. ViewScaleMode and SafeAreaProfile are now part of that rule.
Thumbnail/export rule: URL Art is treated as a thumbnail source. Engineers should not maintain a separate export layout model for URL Art. The live tile composition should be the source of truth, and export should preserve the same layer order and geometry.
QR isolation rule: the QR code must remain on a dedicated overlay layer above all thumbnail imagery. Under no circumstances may export or startup fallback code repurpose the QR as thumbnail content.
Document routing reminder: recent prompts added layout-fit controls, safe-area profiles, deterministic tile layering, and GET-addressable startup properties. Those changes belong primarily in requirements, architecture, developer, system, and thumbnail-system docs rather than being scattered across the whole corpus.