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.

Specification Routing Map

Updated: 2026-03-12 v06

Future sessions should not reread the full documentation corpus on every prompt. Instead they should maintain a high-level routing map of which topics belong in which documents and update only the affected files.

requirements_en.html — user-visible behavior, non-regression rules, startup correctness, WYSIWYG expectations, packaging requirements, and feature requirements.
architecture_en.html — structural rules, first-paint layout model, render pipeline strategy, state/config boundaries, and naming decisions.
system_en.html — active bugs, operational constraints, deployment/runtime behavior, and known issue tracking.
developer_en.html — workflow rules, documentation governance, delta bundle standards, session recovery rules, and spec-memory discipline.
index_en.html — documentation overview, document-purpose map, navigation expectations, and canonical-document-set explanation.
manuscript_en.html — personal/philosophical/user-authored material that is not a system requirement.

The goal is selective maintenance without forgetting earlier binding specifications. This routing shortcut is permitted only because the documentation itself is now expected to capture prior prompts accurately.

Spec Memory and Carry-Forward Rule

Explicit prior requirements from prompts and attached conversation artifacts remain binding until deprecated. Engineers and AI sessions must not require the user to restate already-captured startup, rendering, export, packaging, or navigation rules.