Document freshness: 2026-03-12 • v05

This iteration adds a documentation routing rule: future sessions should keep a high-level mental map of what kinds of material belong in which documents, and only reopen and modify the affected documents rather than rereading the full corpus every turn.

Developer Guide

Last updated: 2026-03-12 v04

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.

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

Startup rendering order

Developers should optimize initial work in this order: visible tile shell, visible QR and text geometry, visible thumbnail or URL art, then off-screen work. A visible tile may continue improving after first paint, but it should never begin in an obviously wrong state.

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

URL art implementation discipline

• Treat the live URL-art tile as canonical. Export code should reuse the same measurements and line-fitting logic wherever possible.
• Do not let export rendering drift into a separate approximate typography system.
• When the footer URL is visible, do not sink the main URL art underneath it; reserve the footer band and fit the main text into the remaining tile area.
• When URL length is within normal bounds, scale text to show the full URL exactly inside the tile.

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

• Every materially relevant prompt must produce a documentation update in the same iteration.
• Missing an explicit prior requirement from the conversation or attached handoff artifacts is a spec-tracking failure.
• When in doubt, search the handoff materials and previously updated docs before assuming a rule does not exist.

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

Documentation routing map

Future sessions do not need to reread every documentation file on every prompt. Instead, they should keep a stable high-level map of document purpose and route each new requirement only to the affected documents.

• requirements_en.html records binding user-facing behavior, non-regression rules, startup expectations, export fidelity, and UI requirements.
• architecture_en.html records structural decisions, rendering model rules, startup ordering, and configuration boundaries.
• system_en.html tracks operational behavior, current bugs, known issues, and active implementation deltas.
• developer_en.html records workflow rules, documentation governance, packaging conventions, and implementation discipline for future humans and AIs.
• index_en.html explains what each document is for and acts as the navigation layer for the corpus.
• manuscript_en.html receives personal, philosophical, literary, and mission-oriented material that does not belong in the engineering spec.

Selective update rule

When a new prompt introduces a relevant requirement, the assistant should identify the correct document category first, then update only those documents that are actually affected. This avoids unnecessary rereading while preserving full prompt capture in the knowledge base.

The assistant should still maintain continuity with prior requirements, but full-document rereading is not required when the document-purpose map already makes the correct destination clear.

8. Long-Term Goal