feat: establish ffmpegfyMe visual identity and brand assets #40

Problem Statement

ffmpegfyMe has no coherent visual identity or maintained brand assets. Its public README has no banner, its repository has no logo or social banner, and its Zensical site still uses a blue accent. The project needs a distinctive, reusable identity and accurate visuals that reflect implemented behavior.

Solution

Create a self-maintained, SVG-first visual identity for ffmpegfyMe and align the public README and documentation site with it. Build deterministic generation and freshness checks around repository-tracked sources and project facts. Use Catppuccin Macchiato with Sky as the project accent. Keep public claims tied to implemented features.

User Stories

1. As a visitor, I want to recognize ffmpegfyMe through a distinctive mark and wordmark, so that the project has a consistent identity.
2. As a maintainer, I want canonical brand assets in editable SVG, so that artwork remains reviewable and portable.
3. As a maintainer, I want required raster assets generated from canonical sources, so that platform-specific formats do not become manually maintained copies.
4. As a repository contributor, I want a deterministic generation and check workflow, so that generated assets stay fresh and CI catches drift.
5. As a README reader, I want a clear banner and concise product promise, so that I can quickly understand what ffmpegfyMe does.
6. As a GitHub visitor, I want a social banner with a few implemented feature pillars, so that the repository preview communicates the product accurately.
7. As a documentation reader, I want the site to use the project palette and brand assets, so that public materials feel consistent.
8. As a user, I want architecture and workflow diagrams to reflect repository facts, so that diagrams remain accurate as the project changes.
9. As a user, I want public pages to distinguish implemented capabilities from planned work, so that product claims are trustworthy.
10. As a reader using different devices or accessibility settings, I want responsive pages, readable contrast, and accessible visual alternatives, so that the site remains usable.

Implementation Decisions

• Use Catppuccin Macchiato as the base palette and Sky #91d7e3 as the project accent. Key tokens include base #24273a, mantle #1e2030, crust #181926, text #cad3f5, subtext1 #b8c0e0, surface0 #363a4f, and surface1 #494d64.
• Keep the canonical logo composition: a rounded film-strip frame containing handwritten ff, followed by MPEGfyMe. Use vector paths for handwritten glyphs rather than depending on a nonportable runtime font. Use #cad3f5 for the frame and MPEG, and Sky for fyMe.
• Create a simplified favicon from the film frame and ff, with superscript fy; include a small-size fallback.
• Use the README tagline “Download HTTP/HLS streams as MP4 or MKV — no transcoding.” Use verified facts only: two output formats, up to three attempts per item, and a 60-second default inactivity timeout.
• Create a related GitHub social banner with a small set of implemented pillars: authenticated HTTP/HLS, MP4/MKV stream copy, and resumable batches with retries. Use the approved Sky palette.
• Keep brand sources, data, and generated assets in a repository-local structure. Track canonical SVG sources and generated outputs. Generate raster derivatives only where a platform requires them.
• Provide task brand:generate and task brand:check. The check validates deterministic output and detects stale committed assets. CI runs the check.
• Maintain architecture and workflow diagrams as generated SVG backed by machine-readable repository facts where practical. The check detects stale generated diagrams.
• Use website/ for public Zensical content and docs/ for internal engineering material. Align Zensical's native configuration and workflows with that structure.
• Style the site with Catppuccin Macchiato and Sky. Keep it dark-first, responsive, accessible, and accurate about implemented versus planned capabilities. Validate against the installed Zensical release and supported features.
• The accepted brand verification seam is the new brand:check task. The existing docs:check remains the site build and quality seam.

Testing Decisions

• Verify generation is deterministic by running it repeatedly and comparing outputs.
• Verify brand:check passes for current generated assets and fails when committed outputs are stale or missing.
• Verify generated diagrams derive from maintained project data and contain no invented metrics or capabilities.
• Build the public site with the existing documentation quality workflow after the content location and theme change.
• Check asset references, alternative text, contrast, and responsive behavior in the built site.
• Review README and social banner claims against implemented repository behavior.

Out of Scope

• Changes to download behavior or product features.
• A shared runtime art-generation package or global project-to-accent mapping.
• Mandatory use of external design applications or nonportable runtime fonts.
• Building or installing the separate project-presentation skill in another repository.
• Marketing roadmap items as implemented.

Further Notes

This is a follow-on presentation and identity effort after the project refresh in #4. The approved visual direction and logo iterations were settled in the conversation. Existing user-approved concept images are temporary references, not canonical repository assets.