_MyAnythingList / _MyAnythingGrid · Requirements

This document is a living specification for the AnythingList / AnythingGrid system: an ethical, decentralized, cognitively compassionate 8K / 4K video wall and interactive media navigator. It is intended for engineers, designers, educators, researchers, and future collaborators working on DEFINE.COM, 8K.ART, 8K.GALLERY, 8K.PRESS, and related open content ecosystems.

Last updated: December 7, 2025 – 02:11 AM PST (Ken local time)

Human Context, Ethical Foundation & Cognitive Imperative

1. A personal origin story that reveals a universal problem

This project does not begin in a lab, a venture pitch, or a boardroom. It begins in a living room with an 82-year-old woman living with temporal lobe encephalomalacia — a neurological condition stemming from childhood encephalitis following a government-mandated vaccination. This condition has progressively damaged the temporal lobes, which are crucial for spatial memory, semantic processing, and navigation.

Over decades, she has developed astonishing compensatory abilities. She cannot reliably form new spatial maps. She cannot remember where “Home” or “Back” live on a new remote control. But she can perceive truthfulness, integrity, and authenticity in content with a level of nuance that many neurologically “intact” people never reach. Her mind is different, not “less.”

She loves TV nature shows, scientific programming, and people who tell the truth according to her own highly refined moral and intuitive framework. For her, and millions like her, media is not entertainment wallpaper — it is a lifeline, a source of meaning, and a therapeutic cognitive scaffold.

2. How cable UX punishes cognitive diversity

For years, she navigated Comcast/Xfinity using the X1 voice remote. Through repetition, she built procedural “muscle memory” even as spatial memory failed. She could say what she wanted, and the device would comply. Then Comcast imposed an arbitrary, non-technical restriction: she could no longer pause her DVR for more than five minutes.

This was not a limitation of hardware or networks. It was a business decision designed to keep ad impressions up and remote control in the hands of the cable company, not the viewer. When the family attempted to cancel cable, they encountered a deliberately tangled bureaucracy of agents, departments, and scripted “retention” workflows.

For a cognitively impaired user, this is not just inconvenient — it is cruel. The system is optimized to exhaust human patience and cognitive resources, not support them.

3. Modern media as a cognitively hostile environment

What happened in that living room is a microcosm of a broader pattern in mass media:

• Interfaces are designed for addiction and engagement, not clarity.
• Remotes and menus change arbitrarily, breaking years of learned muscle memory.
• Smart TVs are engineered to never fully turn off, behaving like digital telescreens.
• DVR and streaming controls are rigged to force involuntary ad exposure.
• Recommendation algorithms amplify outrage and ideology over truth.
• Cancellation processes are labyrinths designed to trap people, especially seniors.

These are not accidents or “edge cases.” They are the predictable outcomes of a media ecosystem whose primary metric is revenue, not truth, autonomy, or mental health.

4. A scientific and cognitive perspective

From a neuroscience perspective:

• Temporal lobe damage and encephalomalacia can severely impair spatial memory and navigation while sparing or even sharpening intuitive, ethical, and pattern-recognition abilities.
• UX patterns that rely heavily on spatial placement, icon-only controls, and fast re-layouts create an environment that is actively hostile to users with temporal or hippocampal impairments.
• Voice interfaces, consistent layouts, and large stable landmarks are profoundly helpful, yet corporate UX rarely fully commits to these accessibility patterns.

In other words: the modern media interface is optimized for healthy, attention-rich, spatially capable, ad-tolerant brains. It is hostile to everyone else.

5. The mission: a decentralized, ethical, cognitively compassionate navigator

AnythingList / AnythingGrid exists as a deliberate countermeasure to this ecosystem. Its mission is:

• To remove media navigation power from monopolistic cable/streaming companies.
• To give citizens their own universal, device-independent, browser-based navigator.
• To honor neurological diversity and cognitive impairment as core design drivers, not edge cases.
• To promote truth, science, nature, ethics, and critical thinking over propaganda and clickbait.
• To expose the “under-the-hood” realities of interactive TV and advertising, not hide them.

This is not just a UI project. It is an ethical, cognitive, and political statement about who should control the global media experience: ordinary people, scientists, educators, healers, and ethical thinkers, not corporate boards and opaque algorithms.

6. The role of 8K.ART, 8K.GALLERY, 8K.PRESS

The domains 8K.ART, 8K.GALLERY, and 8K.PRESS are part of this same mission. They are intended as:

• Creative Commons–friendly hubs for high-resolution educational and artistic content.
• Platforms where AI-assisted art and knowledge serve humans, not extract from them.
• Spaces for truth-based journalism, science communication, and nature storytelling.

The AnythingGrid video wall is one of the primary tools that will display, navigate, and democratize this content.

7. A note on revenue and advertising ethics

The project recognizes the need for revenue to sustain infrastructure, development, and global access. However, it rejects involuntary, manipulative ad models outright.

Ads in AnythingGrid must:

• Appear only as explicit media items in the playlist (e.g., near the bottom).
• Require intentional selection by the viewer — never interrupt other content.
• Be clearly labeled as promotional, educational, or sponsorship streams.
• Never be inserted “in the middle” of user-selected content without consent.

This is a hard ethical requirement. Any future monetization model must preserve viewer autonomy and respect cognitive and emotional safety.

8. Your mother as the north star use case

The founder’s mother is not an edge case; she is the north star. Her specific cognitive profile — impaired spatial memory, rich intuitive ethics, deep love for nature and truth — defines the interface constraints and the project’s priorities.

If a future design choice makes the system harder for her to use, that choice is wrong. If a future language decision makes branding less emotionally clear for her, that decision must be reexamined. If a future ad model would confuse or manipulate her, it is prohibited.

This is not sentimentality. It is an applied accessibility and ethics standard grounded in cognitive science and lived experience.

High-Level System Goals

• Decentralized & local-first: The system must work in a home-server context without central cloud dependence, especially for translation and content control.
• Browser-based & device-agnostic: Runs anywhere a modern browser runs: tablets, PCs, smart TVs with browsers, HDMI sticks, etc.
• Ethical & transparent: No dark patterns, no hidden recommendations, no involuntary ads.
• Multilingual at scale: Able to support dozens to hundreds of languages using local or user-owned AI translation.
• Cognitively compassionate: Minimal redraws, stable layouts, readable fonts, safe color usage, and accessible spatial design.
• Creator-friendly: Easy for content creators to define playlists, thumbnails, QR overlays, and channel metadata.
• Extensible: Designed so that future engineers and AI collaborators can safely add languages, features, and integrations without breaking core ethics.

Core Non-Negotiable Design Rules

1. Single configuration object directly under </head>

All controllable defaults (sliders, toggles, dropdowns, modes, aspect ratio, TV/computer mode, language) must be defined in a single JavaScript object directly under </head> in the HTML. No other script is allowed to introduce hard-coded defaults.

window.MyAnythingListConfig = {
  Mode: "computer",              // "computer" or "tv"
  Immersive: false,              // if true, hide controls even on desktop
  GRID: 2,                       // default grid density (2 means roomy, 3 more dense, etc.)
  Aspect_Ratio: "16x9",          // "16x9", "9x16", etc., but no surprise values
  Output_Resolution: "3840x2160",// visible in resolution dropdown
  QR_X: 100,                     // default QR horizontal position (relative units)
  QR_Y: 100,                     // default QR vertical position
  QR_SIZE: 50,                   // default QR size
  TVModeShowBrandingText: false, // TV mode should normally hide branding
  defaultLanguage: "en"          // starting language; must be valid in language list
};

• URL query parameters (e.g., ?GRID=3&QR_Y=80) may override these values at boot time, but do not create new defaults elsewhere.
• If a label in the UI reads GRID, then the variable must be exactly GRID and the GET parameter must also be GRID (case-insensitive).

2. Build stamp for developers / hobbyists

The app must expose a small, subtle build stamp in computer mode so that developers know what version they are running.

window.MyAnythingListBuild = {
  version: "v0.9.0",                // semantic version or date-based tag
  builtUtc: "2025-12-06T05:30:00Z",
  builtPst: "2025-12-05 21:30 PST"
};

The UI prints this in fine print in the footer (computer mode only), e.g.:

build v0.9.0 – 2025-12-06T05:30:00Z / 2025-12-05 21:30 PST

3. No visible redraws or mode “flashes” at startup

• The app must start directly in the configured Mode ("computer" or "tv") without drawing one mode first and then resizing/redrawing into the other.
• There must be no “gear on left → gear on right → rewrap branding” flicker visible to the user.
• Layout decisions (e.g., where the gear and branding live) should be resolved before first paint when possible, or at least hidden until stable.

4. No involuntary advertisements, ever

• Ads must exist only as intentionally accessible playlist entries — never as forced pre-rolls, mid-rolls, or overlays inside other content.
• The system must never insert ads into user URLs without explicit, revocable consent.
• Any future monetization must preserve the “ads as voluntary streams” model.

5. Local-first, zero-knowledge translation and content handling

• Translation of branding, footer, README, and requirements should happen on the user’s home server or device using their own API key, not a central public server.
• The system backend must not permanently store or log user-specific private content beyond what is necessary for local caching.
• Architectures that route content or translations through centralized infrastructure are strongly discouraged and should be clearly marked as “non-compliant with full decentralization goals.”

Architecture & Directory Structure (Conceptual)

The system is designed to run in two primary environments:

• Home-server / LAN deployment (IIS, Apache, nginx, etc.)
• Simple static hosting (for demos and public examples)

A typical home-server layout might look like:

/home-server/
  /spec/
    _MyAnythingListRequirements.html
    _MyAnythingListRequirements.es.html  (generated)
  /playlists/
    _MyAnythingList.txt          (default)
    _MyAnythingList.es.txt       (localized)
  /lang/
    /branding/
      en.html
      es.html
      ...
    /footer/
      en.html
      es.html
      ...
    /readme/
      en.html
      es.html
      ...
    /requirements/
      en.html
      es.html
      ...
  /tools/
    translate.php                (local only, uses private API key)
  _MyAnythingList.html           (app)
  _MyAnythingListREADME.html     (optional standalone README)

The exact directory structure can vary, but the separation of concerns should remain: app, spec, language fragments, and playlists.

UI / UX Requirements

1. Top bar: branding, controls, and gear/R/i icons

• The top bar contains:
  • Branding line (long, color-coded HTML string).
  • Control row (aspect ratio, resolution, grid slider, language select, etc.).
  • Right-aligned control cluster: gear, Requirements (R), README (i).
• Branding text must wrap cleanly around the buttons with about 10px padding on left and bottom, never leaving large dead margins and never overlapping the icons.
• The gear position (left/right) should be determined before the user sees anything — no “gear jumping” after initial render.

2. TV mode vs computer mode

• Computer mode: full controls visible; branding text visible; build stamp visible; modals usable.
• TV mode: minimal or zero UI chrome; focus on thumbnails and content; branding text only if TVModeShowBrandingText = true.
• Mode changes must be smooth but not flashy; no unnecessary animations that could overstimulate or confuse cognitively sensitive users.

3. Tooltips & control feedback

• Slider tooltips should appear above the thumb (e.g., 0.75" above on touch devices), clearly visible even when the user’s finger covers the control.
• Tooltips must disappear immediately when the user releases, blurs, or leaves the control. No “stuck” tooltips.
• Tooltip styling should be legible everywhere: sufficient contrast, optional subtle border, and never blending into branding text behind it.

4. Pointer / hover behavior

• The cursor should change to a hand when over any clickable media tile, button, or link.
• Non-interactive text uses the default cursor; this helps differentiate content from controls for cognitively vulnerable users.

5. Symmetry and safe areas

• The wall must have visually consistent safe margins top/bottom and left/right so that thumbnails are never clipped at the bottom or sides.
• Thumbnails must sit within a safe frame so that QR overlays, borders, and labels do not fall outside viewable areas at any grid size.

Multilingual System & Language Indicators

1. Language selector behavior

• The language dropdown contains all languages the system can reasonably support (potentially very large).
• Languages where all required fragments (branding, footer, README, requirements) exist locally are shown with a green checkmark ✓.
• Languages that do not yet have local fragments but are translatable are shown with a seedling 🌱 icon, indicating “ready to grow.”
• Selecting a 🌱 language may:
  • Trigger a local translation flow using the user’s API key (if configured), or
  • Show a gentle prompt explaining that translations can be generated from home tools.

2. Branding & footer HTML fragments

Branding and footer text are stored as small HTML fragments per language. For example, the English brand line:

<span class='blue'>DEFINE.COM</span> · <span class='gold'>8K</span> & <span class='gold'>4K</span>
<span class='gold'>VIDEO WALLS</span> & <span class='gold'>STREAM FEEDS</span> FOR <span class='gold'>HOME</span>,
<span class='blue'>BUSINESS</span>, <span class='green'>EDUCATION</span>, <span class='green'>DIGITAL</span>
<span class='gold'>THEATERS</span> & <span class='gold'>HEALTH CARE</span> · ...

The Spanish version must preserve the same span structure and colors, changing only the inner text:

<span class='blue'>DEFINE.COM</span> · <span class='gold'>8K</span> y <span class='gold'>4K</span>
<span class='gold'>MUROS DE VIDEO</span> y <span class='gold'>FLUJOS</span> PARA <span class='gold'>HOGAR</span>,
<span class='blue'>NEGOCIOS</span>, <span class='green'>EDUCACIÓN</span>, ...

• Color is part of the semantic meaning; translators must never strip or scramble span classes.
• Emotionally charged words (e.g., CORRUPTION) must remain red in all languages.

3. README and Requirements modals

• The “i” button opens a modal README in the current language (loaded from /lang/readme/<lang>.html).
• The “R” button opens the requirements document in an iframe:
  • English: /_MyAnythingListRequirements.html
  • Spanish: /_MyAnythingListRequirements.es.html
  • Other languages: consistent naming (e.g., _MyAnythingListRequirements.<lang>.html).

Grid, Thumbnails, Aspect Ratio & Safe Zones

1. Aspect ratio rules

• Each tile’s outer container has a fixed aspect-ratio determined by Aspect_Ratio (e.g., 16:9 or 9:16). No “hidden” aspect ratios should be introduced without explicit configuration.
• The thumbnail image uses object-fit: contain so the entire source thumbnail is always visible and never cropped.
• Extra space appears as symmetric letterboxing or pillarboxing inside the tile.

2. Safe inner padding

• Each tile has a small inner margin (e.g., 4px) so that QR overlays and labels are never flush against the extreme edges where they might be cut off on certain displays.
• At all grid sizes, thumbnails must remain fully visible with equal padding top and bottom and left and right within each tile, subject to aspect-ratio constraints.

3. Grid density (GRID)

• GRID controls how many tiles appear simultaneously. Lower values = fewer, larger tiles; higher values = more, smaller tiles.
• Default GRID is 2 (roomy, very readable), but the slider allows adjusting up/down for different environments (e.g., living room vs control room vs wall of monitors).

Playlists & Media Sources

1. Basic playlist format

• The simplest playlist is a plain text file: _MyAnythingList.txt, one URL per line, with # for comments.
• The app attempts to load a local ./_MyAnythingList.txt first, then may optionally fall back to a known public version for demos.
• A deployment MAY also specify a default playlist location in JavaScript configuration, such as MyAnythingListConfig.Playlist_URL. This is treated as the instance’s “home” playlist URL and is consulted after any runtime AnythingListURL parameter, and before falling back to the local _MyAnythingList.txt or remote demo list.

2. Derived thumbnails

• For YouTube URLs, the app can derive thumbnail URLs from the video ID for efficient display.
• For arbitrary URLs, the system may fall back to placeholder images or eventually support metadata scraping (subject to ethical constraints).

3. URL Extraction Rules for _MyAnythingList.txt

• If a line begins with #, it is a comment-only line. All URLs present in that line MUST be ignored by the playlist loader.
• If a line does not begin with #, the loader MUST scan that line and extract every valid URL that appears anywhere in the text, regardless of surrounding words, punctuation, or descriptive commentary.
• Multiple URLs MAY appear on the same non-comment line. All such URLs MUST be included as distinct playlist entries in the order they appear.
• Bare youtube.com/… and youtu.be/… links MUST be normalized to https://youtube.com/… or https://youtu.be/… respectively before further classification (e.g., thumbnail derivation).
• A line MUST NOT be discarded simply because it mixes natural-language storytelling with URLs. As long as the line does not begin with #, every syntactically valid URL within it is considered intentional and MUST be treated as part of the playlist.

# This is a comment-only line; the YouTube URL here is ignored.
# https://www.youtube.com/watch?v=EXAMPLE123

I might talk about one video like https://youtu.be/ABC123 and then another on the same line at
youtube.com/watch?v=XYZ789 while telling a story about why they matter.

This prose-heavy line has only one URL: https://www.youtube.com/watch?v=ONLYONE

2. URL-based playlist override (AnythingListURL)

• The app MAY accept a playlist location via a URL query parameter named AnythingListURL. This allows users to test their own playlists through a shared deployment (for example, https://example.org/wall.html?AnythingListURL=…).
• When present, AnythingListURL is treated as the highest-priority source for the playlist text. The loader MUST attempt to fetch this URL first, before falling back to _MyAnythingList.txt or any built-in defaults.
• If the override URL fails to load (network error, non-2xx status, or invalid response), the app MUST log a warning and gracefully fall back to the normal local/remote playlist loading behavior.
• The resource referenced by AnythingListURL SHOULD be a UTF‑8 plain text file formatted the same way as _MyAnythingList.txt: natural-language lines with URLs anywhere on non-# lines, where every syntactically valid URL becomes a candidate feed entry.
• Operators of public instances SHOULD document the presence of this parameter and MAY impose external constraints (such as CORS, size limits, or rate limits) to protect their servers from abuse.

Translation, Home-Server Automation & Local-First AI

1. Home-based translation engine

A household may run a small translation tool (e.g., in PHP, Python, or Node) on a private IIS or other local server using the homeowner’s ChatGPT API key. This engine:

• Reads English branding/footer/README/requirements fragments.
• Requests translations for selected languages from ChatGPT.
• Preserves all HTML structure and color spans exactly.
• Writes localized fragments to /lang/... directories.
• Optionally packages them as a downloadable ZIP.

2. Privacy and zero-knowledge backend

• The translation tool must not send arbitrary private user content anywhere; it should focus on public-facing branding and documentation text.
• API keys are stored locally and never embedded in public HTML or shared repositories.
• The local translation tool may log token usage and errors, but should avoid long-term logging of raw text.

Ethical Advertising Model

• Ads exist only as intentional playlist entries or “channels,” never as forced insertions.
• Users must scroll to or explicitly select ads; no automatic mid-content interruptions.
• Ads may be educational, product-based, or service-based, but must be clearly labeled.
• Ad content should respect the same ethical and cognitive standards as all other content.

Developer / AI Collaborator Guidelines

• Do not introduce new global state when you can extend window.MyAnythingListConfig.
• Do not hard-code defaults far away from the configuration block.
• Do not reformat or minify branding/footer HTML; keep it human-editable.
• When adding new languages, mirror color spans and emotional semantics carefully.
• Test with seniors, neurodivergent users, and people who dislike surprise UI changes.
• Remember: if it confuses or disadvantages the founder’s mother, reconsider the design.

Playlist Editor Modal & Source Transparency

1. Modal size and behavior

• The playlist editor opens in a centered modal overlay with a visibility toggle only (no navigation away from the wall).
• The modal MUST occupy approximately 80% of the viewport height (height: 80vh, max-height: 80vh) on all devices.
• The textarea inside the modal grows/shrinks to fill the remaining vertical space so that large playlists are comfortably visible.
• Closing the modal via “Cancel” must not change the current wall; closing via “Save & Rebuild Wall” MUST re-parse the current editor text and rebuild tiles from that text.

2. Data-only, never embedded playlist content

• Non‑negotiable rule: the HTML / JavaScript bundle MUST NOT embed an actual production playlist as a long string literal. The constant DEFAULT_FEED_TEXT is reserved for empty or tiny demo content only and MUST be shipped as an empty string in production builds.
• All real playlists MUST be data-driven:
  • First from a local _MyAnythingList.txt file in the same directory as beta.html / index.html (or equivalent),
  • Then from a remote fallback URL such as https://define.com/_MyAnythingList.txt,
  • With an optional override via URL query parameter AnythingListURL= (see Appendix D).
• When running under file:// where browsers block automatic local fetches, the app may optionally prompt the user with a standard file picker to select a local text file, but it MUST NOT silently revert to a hidden embedded playlist.

3. URL parsing with natural-language explainers

• Each non-comment line in the playlist file may contain:
  • A bare URL (e.g. a YouTube watch URL, playlist URL, or any HTTP/S web resource), or
  • A URL followed by human-readable commentary, e.g. https://www.youtube.com/watch?v=5l9wEGpwqDU (Player's Unlimited).
• Lines starting with # are treated as pure comments and ignored for URL extraction.
• The parser must extract one or more URLs from each non-comment line using a robust URL regex and ignore surrounding English text.
• YouTube URLs may appear as full https:// URLs, youtube.com/… or youtu.be/…; bare forms MUST be normalized to full https:// URLs before use.
• If more than one URL appears on a single line, the implementation may either:
  • treat each URL as a separate tile entry, or
  • treat the first URL as primary and log others for future features.
  The current reference implementation creates a tile for each extracted URL.

4. Playlist source transparency in the modal

• The modal header includes a small status line of the form:
  Source: <description>
• The implementation maintains a variable such as currentPlaylistSource that records where the current playlist was loaded from:
  • ./_MyAnythingList.txt (local same-directory file),
  • https://define.com/_MyAnythingList.txt (remote fallback),
  • DEFAULT_FEED_TEXT (embedded in HTML) for non-production demos, or
  • (no local or remote playlist loaded yet) if nothing succeeds.
• Whenever the playlist text is (re)loaded or overridden, the modal status label MUST be updated to reflect the current source so that users always understand what they are editing.

5. Downloading the current playlist

• The modal footer includes a blue “Download _MyAnythingList.txt” button.
• Clicking this button MUST:
  • Read the current contents of the editor textarea (including unsaved edits),
  • Generate a blob with MIME type text/plain; charset=utf-8,
  • Trigger a browser download named _MyAnythingList.txt using a synthetic <a download> click.
• This behavior MUST be fully client-side and must not require a backend.
• The downloaded file is the canonical representation that users may later upload, sync, or place on a server as their live playlist.

Fullscreen, Immersive, TV Mode & Hotzone Behavior

1. Definitions

• Director / Computer mode: normal browser window with full controls, scrollbars allowed, and the grid treated as a working surface.
• TV / Immersive mode: a layout that hides most chrome, may lock scrolling, and is optimized for remote viewing on a large display.
• Real fullscreen: the browser’s actual fullscreen state (e.g., document.fullscreenElement or vendor-prefixed equivalents), tracked by a helper such as isFullscreen().

2. Non‑negotiable fullscreen branding rule

• When the browser is in real fullscreen, branding text and the full top header bar MUST NOT be visible.
• The implementation SHOULD add a class such as hard-fullscreen on <html> when isFullscreen() is true and remove it when false.
• A CSS override such as html.hard-fullscreen .top-bar { display: none !important; } SHOULD be used to guarantee that branding cannot appear while the app is truly fullscreen.

3. Mode = "tv" vs. Immersive = true

• For now, both Mode: "tv" and Immersive: true enable the TV-style immersive layout and may request fullscreen on startup.
• Future refactors SHOULD treat:
  • Mode: "tv" as controlling layout (grid density, scroll locking, visible controls), and
  • Immersive: true as controlling whether fullscreen is requested automatically.
• Regardless of future refactors, the “no branding in real fullscreen” rule is absolute.

4. Gear button behavior and exit semantics

• The gear button in the upper-right corner is the primary control for entering/exiting immersive and fullscreen states.
• Its click handler MUST examine both:
  • whether the app is in immersive mode (e.g. html.immersive / body.immersive), and
  • whether the browser is in real fullscreen (via isFullscreen()).
• Expected behavior:
  • Director windowed → gear click → Immersive + real fullscreen.
  • Immersive windowed (TV layout but not fullscreen) → gear click → Immersive + real fullscreen.
  • Immersive + real fullscreen → gear click → exit fullscreen and exit immersive (back to director windowed).
  • Director + real fullscreen (e.g. user pressed F11) → gear click → exit fullscreen, remain in director mode.
• The gear icon MUST remain visible and clickable in immersive and fullscreen modes so that users always have a mouse-only escape path.

5. Upper‑right hotzone behavior

• A small fixed rectangle in the upper-right corner (the “hotzone”) sits above the tiles for interaction routing.
• When the app is in real fullscreen:
  • Clicks inside this hotzone MUST be intercepted and must not trigger the URL of any tile beneath it.
  • Instead, a click in the hotzone MUST be treated as an intent to show/activate the gear (e.g. by programmatically clicking the gear button).
• When the app is not in real fullscreen, the hotzone behaves normally and tile clicks outside the buttons remain active.
• This guarantees that remote users on a TV can always reach a safe “exit fullscreen” control by moving a pointer to the upper-right corner.

6. Mobile / small-screen expectations

• On phones and small tablets in “computer mode,” vertical space is extremely limited. The layout SHOULD:
  • Minimize header padding and optional branding,
  • Ensure that at least one full 1×1 panel row is visible without scrolling whenever possible, and
  • Keep the gear icon reachable even when the browser enters a pseudo-fullscreen state.

Appendix A: Bulletized Human Context (for Engineers)

This appendix translates the narrative human context into explicit, implementation-relevant bullets.

A.1 Cognitive & emotional constraints

• The target user may:
  • Struggle to learn new remote layouts.
  • Have severely impaired spatial memory.
  • Rely on consistent voice or one-button affordances.
  • Be extremely sensitive to truth/falsehood and manipulation.
• Therefore:
  • Do not move key controls around between sessions.
  • Do not animate or redraw the interface after first paint without strong reasons.
  • Use large, stable visual anchors (thumbnails, safe margins, clear text).

A.2 Media system harms to avoid

• Retention-maze cancellation flows.
• Arbitrary device redesigns that break learned behaviors.
• Hidden limits on features like pause/rewind.
• Unlabeled or involuntary advertising.
• UI patterns that exploit addiction or outrage.

A.3 Values to embed in the codebase

• Truth over engagement.
• Accessibility over novelty.
• Decentralization over central control.
• User autonomy over behavioral manipulation.
• Transparency over “magic” black-box effects.

Appendix B: Directory Structure Template

/home-server/
  _MyAnythingList.html
  _MyAnythingListREADME.html

  /spec/
    _MyAnythingListRequirements.html
    _MyAnythingListRequirements.es.html  (and other languages)

  /lang/
    /branding/
      en.html
      es.html
      ...
    /footer/
      en.html
      es.html
      ...
    /readme/
      en.html
      es.html
      ...
    /requirements/
      en.html
      es.html
      ...

  /playlists/
    _MyAnythingList.txt
    _MyAnythingList.es.txt
    ...

  /tools/
    translate.php     (optional, local-only translation engine)
    ...

Appendix C: Configuration Object Schema

window.MyAnythingListConfig = {
  Mode: "computer" | "tv",
  Immersive: boolean,
  GRID: number,                // e.g., 1–6
  Aspect_Ratio: string,        // "16x9", "9x16", etc.
  Output_Resolution: string,   // "3840x2160", "1920x1080", ...
  QR_X: number,                // 0–100 (relative)
  QR_Y: number,                // 0–100 (relative)
  QR_SIZE: number,             // 0–100 (relative)
  TVModeShowBrandingText: boolean,
  defaultLanguage: string      // e.g., "en", "es"
};

Appendix D: URL Parameters & Mappings

All visible control labels must correspond to URL parameters with identical names (case-insensitive), e.g.:

• ?GRID=3 → sets window.MyAnythingListConfig.GRID = 3
• ?QR_X=80&QR_Y=90 → sets QR position defaults.
• ?Mode=tv → starts in TV mode.
• ?Aspect_Ratio=9x16 → sets initial aspect ratio.

This mapping must remain stable so that URLs can be bookmarked, shared, and reasoned about by non-programmers.

This document is intentionally verbose and emotionally explicit, because the harms it seeks to prevent are real and widespread. Future revisions should preserve its spirit while refining details as the system evolves.

Appendix E: Model for Transitioning Into Home‑Based Knowledge Work

1. Stabilization First

• Pause new expenses: Avoid new hardware or domain purchases until income stabilizes.
• Consolidate effort: Focus on one working demo or product instead of many parallel domains.
• Use existing equipment: Large displays, green screens, cameras, and capture tools can be leveraged later for content production, not immediately.
• Prioritize mental and physical safety: Build processes that reduce overwhelm rather than increase it.

2. Build a Single Demonstration Artifact

• One working prototype: A single HTML/JS demo or web app is enough to begin gathering support, collaborators, or donors.
• Local-first design: Ensure the project works offline or in local “file mode” when possible, lowering barriers to participation.
• Clear documentation: A requirement document like this one provides structure, communicates vision, and helps others onboard.

3. Develop a Support‑Ready Presence

• Create one funding entry point: Patreon, OpenCollective, Ko‑fi, or a nonprofit donation page.
• Mission statement: Define the educational, creative‑commons, or public‑benefit purpose clearly.
• Transparency: Explain where funds go (hosting fees, accessibility tools, studio gear, etc.).

4. Use Media and Avatars Strategically

• Green‑screen avatars: Individuals may record themselves teaching or explaining concepts, then superimpose onto animated or static video walls.
• Accessible home‑studio pipeline: OBS Studio, capture cards, and 8K/4K displays can be used to generate professional‑looking educational content with minimal physical movement.
• Reusable persona assets: Avatars or character rigs can reduce the cognitive load of appearing on camera frequently.

5. Sustainable Home‑Based Knowledge Work

• Small but cumulative outputs: Short videos, code snippets, curated playlists, annotated articles, or micro‑lessons can build a library of public value.
• Asynchronous workflow: Allows creators with disabilities or unpredictable energy levels to work in flexible bursts.
• Community alignment: Contributing to open‑source, education, or nonprofit ecosystems increases visibility and support opportunities.

6. Long‑Term Growth Model

• Grants and nonprofit accelerators: Many foundations support accessible education technology, media literacy, and open‑source tools.
• Collaborations: Partner with educators, NGOs, creators, and community groups who benefit from curated knowledge tools.
• Ethical monetization: Affiliate links, donor programs, and sponsorships may be used if transparently disclosed and consistent with nonprofit values.

Appendix F: Playlist Editor & Local/Remote Source Handling

This appendix summarizes key behaviors for engineers implementing or re-implementing the playlist editor in new environments or future forks.

• Respect the data-only rule: no embedded production playlists in HTML/JS; always load from text files or user-provided sources.
• Preserve the parsing rules for URLs with natural-language explainers and comment lines starting with #.
• Keep the modal height at ~80% of viewport with an editor that feels comfortable for very long lists.
• Always expose the actual playlist source in the UI so users know what they are editing.
• Make the “Download _MyAnythingList.txt” workflow bulletproof, as it is the primary way users back up and move their playlists.

Appendix G: Fullscreen / TV Wall Interaction Patterns

This appendix captures the intent behind the fullscreen and hotzone behavior so that future developers do not regress important affordances.

• Never show branding header text in real fullscreen — the wall should feel like a pure canvas.
• Always provide a mouse/touch-accessible escape path out of fullscreen and immersive modes (gear + hotzone).
• Favor simple, explainable state diagrams over clever transitions; being predictable matters more than being flashy.
• When in doubt, optimize for legibility and control for the director at their desk and for viewers on a large TV across the room.