requirements_en.html
This document defines the canonical behavioral requirements for the MyAnythingList and MyAnythingGrid system. It is intended to be detailed enough that a future human or AI contributor can reconstruct the system without relying on chat history, private notes, or undocumented assumptions.
If any statement in future drafts conflicts with a newer confirmed requirement, the conflicting statement must be removed or rewritten. The goal is a living specification that supports lossless insertion of new information without preserving contradictions.
MyAnythingList converts any UTF-8 free-form text document into a valid URL playlist by extracting recognized URLs wherever they appear in the text.
This free-form parsing model is a foundational invariant of the project and must never be silently regressed into a stricter “one URL per line” design.
The parser scans input text and extracts valid URLs in order of discovery. That order defines the playlist order unless later behavior explicitly changes it.
Example: Today's research and media notes: Watch this: https://youtube.com/watch?v=ABC123 Then compare with: https://example.org/article Reminder: translate this later.
Any control, behavior, render operation, export option, or configuration state discussed in project conversations must become explicit documentation and must not remain implicit tribal knowledge. If a feature can be driven manually, the documentation set must eventually describe its scriptable and reproducible form as well.
Commands and arguments must be described using explicit, deterministic names rather than vague language such as “auto” when the resulting behavior is materially different. Every argument that changes render output, export output, QR behavior, URL-art behavior, language behavior, or control visibility must be documented with meaning, accepted values, and failure conditions.
Lines beginning with # are treated as comments and ignored by default.
A comment line may also contain a recognized command using the form:
#_CommandName(...)
These commands are not ordinary comments. They are part of the playlist language and must be parsed intentionally.
Unless the command explicitly defines standalone content, a command applies to the most recent URL above it.
https://example.com/page-a
#_ReplaceThumbnailWithImage("https://example.com/image-a.jpg")
https://example.com/page-b
#_ReplaceThumbnailWithImage("https://example.com/image-b.jpg")
The command surface is not limited to playlist parsing convenience. It is part of the canonical system interface. Anything that can be programmatically controlled must be documented in the standard scripting documents, including command names, functions, arguments, defaults, sequencing expectations, and constraints.
#_ReplaceThumbnailWithImage("https://example.com/image.jpg")
#_LoadImage("https://example.com/image.jpg")
#_LoadImageShowLinks("https://example.com/image.jpg")
#_LoadImageHideLinks("https://example.com/image.jpg")
Downloaded thumbnails must be rendered natively at the selected output size. The system must never flatten a live screen-resolution tile and upscale it for final output. This rule applies to image-backed thumbnails and to text-only URL-art thumbnails alike.
When no bitmap thumbnail exists, URL text art plus QR remains a first-class thumbnail mode. It must be treated as a basic use case executed at expert quality. Text-only tiles must remain sharply rendered at 4K and 8K, including URL art, pill text, footer text, and overlays.
If a bitmap source exists, the system must use the highest available source image. A low-resolution bitmap may limit bitmap detail, but it must not cause QR, text, pills, lines, or other generated overlays to become soft.
Tiles may obtain thumbnails from several sources.
| Priority | Thumbnail Source | Requirement |
|---|---|---|
| 1 | Command-defined thumbnail | Highest priority when explicitly set by playlist command. |
| 2 | Uploaded thumbnail | Applies to the intended tile only and must target the true thumbnail layer. |
| 3 | Platform-derived thumbnail | Used when available from services such as YouTube. |
| 4 | Generic fallback | Used when no specific image exists. |
The QR code must live on its own dedicated composition layer above background imagery or URL art. It must never be treated as background content and must never disappear in exported thumbnails when visible in the live composition.
Render and export completion must wait for QR readiness whenever QR is enabled and visible. A render path that completes before the QR source is ready is invalid.
If the QR is visible in the live tile, the exported tile must include the QR at corresponding position, scale, visibility, and layer order. Any omission is a hard failure.
Both live rendering and export rendering must use this same canonical ordering unless a later canonical document explicitly supersedes it.
The visual stack of a normal tile should remain logically separated.
Thumbnail or image layer → QR overlay → type pill → URL text / footer metadata
All user-facing controls, labels, and interface text must be fully localizable. Controls must be documented using canonical keys and not hardcoded only in English. This includes buttons, toggles, menu items, explanatory labels, errors, status text, and export UI.
The interface must remain stable under longer translations, mixed scripts, and right-to-left languages. English string length must never be assumed to define control width or overlay geometry.
Runtime startup behavior is determined through the startup configuration object and compatible GET variables.
Important variables include:
ShowControlsShowGearAutoHideGearShowQRShowTypesShowURLsShowHeaderTextShowFooterText| ShowControls | ShowGear | AutoHideGear | Required Result |
|---|---|---|---|
| true | true | false | Controls visible on startup. Gear visible because it is the way to close the controls. |
| false | true | true | Controls hidden on startup. Gear available and may auto-hide until needed. |
| false | true | false | Controls hidden on startup. Gear visible and persistent. |
| false | false | any | No visible control entry point. State can only be changed by source or GET parameters. |
The startup architecture separates runtime/state values from branding/template values.
window.MyAnythingListConfig contains real startup/runtime values and URL-mirror values.PageTitle, HeaderText, FooterText, ProjectSourceURL, and BUILD_FILE are separate top-level startup variables.PageTitle so the same file can remain index.html in generic deployments.mode:"cors" and credentials:"omit" when appropriate.The system must use one canonical composition model and render that model directly at export resolution. Export must not be a separate reconstruction path that manually reassembles a tile in a way that can drift from live rendering.
8K output quality is non-negotiable. The architecture must preserve super high-resolution thumbnail download in all available quality given source limitations. No shortcut that reduces final export fidelity is acceptable.
PNG is the default master-fidelity export path. If JPEG is offered, it must be an explicit quality mode rather than a hidden degradation loop. Automatic quality reduction to chase a file-size threshold must not run on the master-quality path.
CSS-pixel snapshots, viewport captures, or monitor-resolution copies are not valid export implementations.
No documented information may be removed, reduced, summarized, or replaced in a way that loses detail, intent, specificity, edge cases, examples, or coverage. Documents may be expanded, clarified, reorganized, or cross-linked, but not collapsed into shorter substitutes.
When a project conversation establishes a feature, behavior, requirement, command, argument, edge case, acceptance test, or failure condition, the relevant canonical documents must be updated so the information becomes part of the package. It must not remain only in chat history.
Future ChatGPT sessions and other automated documentation tools must operate under a no-loss constraint. Their job is to preserve and increase fidelity, not to streamline the package into smaller or more generic documents.
The canonical English documents are intended to become the stable source for translation into the most-used world languages and should therefore prioritize clarity and completeness over brevity.
Final additive requirement: the full documentation package must be capable of making the original human operator unnecessary for ongoing development. A competent open-source programmer should be able to reproduce the prior day’s work from the documents alone.
MyAnythingList must remain a flexible, transparent, multilingual, human-friendly system for turning ordinary text into useful media navigation surfaces. Any future development that quietly narrows this flexibility should be treated as a regression unless that change has been explicitly justified and documented.
Output_Resolution. The QR code must appear in the exported thumbnail whenever QR is visible in the live tile, and must be absent only when intentionally hidden.MyAnythingThumbnail_YYYY-MM-DD_HHMMSSAM_Resolution.ext, for example MyAnythingThumbnail_2026-03-11_125330PM_3840x2160.png.Updated: 2026-03-12 v09
8k.art/_docs/en.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.
Updated: 2026-03-12 v14