MyAnythingList Canonical English Docs

Freshness: 2026-03-12 v10 • Standard navigation header/footer • Every document should reveal freshness immediately at the very top and bottom.

Docs Index Requirements Architecture Developer System Thumbnail System

English Docs Index Choose Language Browse Folder

Developer Guide

developer_en.html

This document describes how developers should understand, extend, and maintain the MyAnythingList system.

1. Development Philosophy

Preserve simplicity.
Preserve human-readable text.
Prefer transparent behavior over hidden logic.
Document decisions clearly.

Future developers should not need historical chat logs to understand how the system works.

2. Core System Components

Playlist text
   ↓
URL discovery
   ↓
Command parsing
   ↓
Tile model creation
   ↓
Thumbnail / QR resolution
   ↓
Grid rendering

3. Playlist Parser

The parser extracts valid URLs from any UTF-8 text.

Rules:

URLs may appear anywhere in text.
Lines beginning with # are comments.
Commands use the syntax #_Command().

Example:

My research notes:

https://example.com/article

#_ReplaceThumbnailWithImage("cover.jpg")

4. Command System

Commands extend playlist behavior.

Examples:

#_ReplaceThumbnailWithImage("image.jpg")
#_LoadImage("panel.png")
#_LoadImageHideLinks("poster.png")

Commands apply to the most recent URL unless otherwise defined.

5. UI State Architecture

Runtime state is controlled by configuration variables.

Examples:

ShowControls
ShowGear
AutoHideGear
ShowQR
ShowTypes
ShowURLs

These values may be set through:

startup configuration
URL parameters
UI interaction

6. Thumbnail System

Thumbnail sources are prioritized:

Command thumbnail
→ Uploaded thumbnail
→ Platform thumbnail
→ Fallback image

Rules:

QR images must never replace thumbnails.
Uploaded images must affect only the intended tile.

7. Contribution Guidelines

Preserve existing behavior unless explicitly redesigned.
Update documentation when behavior changes.
Favor readability over cleverness.

8. Long-Term Goal

The project aims to remain understandable to future developers and AI systems for decades.

v09 Delta — Implementation Routing and Export Details

Future sessions should not reread the full corpus every turn. Keep a high-level routing map of which document owns each type of rule and update only the affected docs. For the build, ViewScaleMode and SafeAreaProfile are first-class runtime settings that belong in window.MyAnythingListConfig and should also be GET-addressable. Exported thumbnails must capture the final composited tile canvas and use informative filenames such as MyAnythingThumbnail_2026-03-12_041552PM_3840x2160.png.

Updated: 2026-03-12 v09

v10 Delta — Latest-Build Discipline and Packaging Boundaries

Always build from the latest version. A new iteration may not start from an older build when a newer build already contains fixes or clarified runtime behavior. This rule prevents regressions such as the return of previously corrected QR startup behavior.

Canonical docs folders are meant to copy directly into 8k.art/_docs/en without stowaway files. Progress logs belong at the root of the iteration package beside the app build and handoff file, not inside the canonical docs folder.

All documentation pages must share the standard navigation header/footer and the same high-visibility freshness timestamp treatment at the top and bottom so anyone opening any page immediately knows how current it is.

v11 Delta — Always‑On Logging and Educational Code Commentary

The application now includes a client‑side runtime logging system designed to aid debugging and future development transparency.

Logging is always enabled and stored in memory.
A “View Logs” panel allows inspection, search, and download of logs.
Logs reset automatically on page refresh.
Major subsystems should include paragraph‑level comments explaining purpose and design.

v11 Delta — Unified Selection / JPEG Export Logic

Do not implement ad hoc per-button export code. Tile selection, background JPEG preparation, and download-button fulfillment are one shared pathway.
When modifying tile interaction, preserve the startup pre-arm exception for tile 1.
When changing export state inputs such as output resolution or visibility toggles, invalidate stale prepared JPEG assumptions and allow the selected tile to prepare an updated JPEG.

Updated: 2026-05-06 v11

v12 Delta — One Global Button Feedback System

All button press acknowledgment must come from one shared implementation path so every button responds with the same timing, style, and restoration behavior.
Do not attach bespoke button-feedback logic to individual buttons except when absolutely required for semantics; feedback itself belongs to the shared button layer.
The shared feedback layer should acknowledge at pointer-down or the earliest equivalent user-input phase, while actual work continues afterward.
Feedback styling should avoid width changes, label expansion, or layout shift. Favor border, glow, pulse, shadow, or similarly calming non-resizing motion.
Educational deployments matter: teachers and students must be able to trust that a button press has registered immediately, even when the requested action takes longer to complete.

Updated: 2026-05-06 v12

v13 Delta — One Press Pipeline, No Duplicate Predecessors

All button feedback must originate from one shared pointer-down implementation. Remove duplicate legacy CSS states and JavaScript predecessors that try to perform the same acknowledgment elsewhere.
After the shared feedback state is applied, action-specific code may begin immediately. Do not serialize work behind animation completion timers.
Until shuffle is intentionally implemented, preserve deterministic startup selection on tile 1 and treat any random startup focus as a bug.

Updated: 2026-05-06 v13