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.

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.

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

My research notes:

https://example.com/article

#_ReplaceThumbnailWithImage("cover.jpg")

4. Command System

Commands extend playlist behavior.

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

5. UI State Architecture

Runtime state is controlled by configuration variables.

• ShowControls
• ShowGear
• AutoHideGear
• ShowQR
• ShowTypes
• ShowURLs

• startup configuration
• URL parameters
• UI interaction

6. Thumbnail System

Command thumbnail
→ Uploaded thumbnail
→ Platform thumbnail
→ Fallback image

• 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

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.

v15 Delta — Daily Build Naming Rule

Going forward, the canonical daily development-build HTML filename format is index_beta_YYYY-MM-DD-vNN.html. Example: index_beta_2026-03-21-v01.html.

• index_beta identifies the dated working build.
• YYYY-MM-DD is the calendar date of that iteration.
• vNN is the intra-day sequence number, beginning with v01 for the first saved build of the day.
• index.html may still be published as the live alias, but handoffs, regression work, and archive folders should preserve the dated filename.

This naming rule exists so humans and AI systems can reason about chronology, compare builds safely, and avoid editing an ambiguous unlabeled file when several variants exist.

Updated: 2026-03-21 v15

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-21 v15