feat: rebrand the fork with a one-word product identity

[absolutepraya]

Goal

Choose a distinctive one-word product name, then rebrand this personal Karakeep fork coherently across every user-facing and operator-facing surface. The name is deliberately not locked yet. Current shortlist: Latch, Nook, Coda, Trove, Mica, Cove, and Orbit.

Scope

Product identity

• Replace visible product names in the web app: header, navigation, auth, onboarding, settings, dialogs, empty states, notifications, and footer.
• Create and apply the new logo, wordmark, favicon, app icons, PWA manifest assets, social cards, and screenshots.
• Rebrand the browser extension, mobile app, landing app, and MCP server wherever users see the product identity.
• Review all email, invitation, export, RSS, webhook, and API-facing copy for visible branding.

Web and discovery

• Update browser page titles, title templates, descriptions, Open Graph and Twitter metadata, structured data, canonical URLs, manifest metadata, and SEO copy.
• Update landing-site copy, screenshots, and public docs-site branding.
• Plan redirects and compatibility if the public domain changes.

Repository and distribution

• Rename or reframe the GitHub repository, description, social preview, README, badges, links, issue templates, and release-facing copy.
• Decide the desired GitHub package and container-image naming strategy, including transition support for the existing GHCR image and Watchtower deployment.
• Review package names, extension identifiers, mobile app identifiers, and publish metadata before changing any that would affect existing installs.

Operator and deployment surfaces

• Update fork-specific docs, deployment docs, compose labels, service names where user-visible, environment-variable documentation, dashboards, health-check labels, and monitoring names.
• Update domain, nginx, OAuth callback, CORS, authentication, webhook, and email configuration references if the public hostname changes.
• Keep production data, stored assets, and existing bookmark URLs intact through the migration.

Documentation and assistant context

• Keep README.md, CONTRIBUTING.md, AGENTS.md, CLAUDE.md, GEMINI.md, docs/fork-setup.md, and relevant docs/docs/** pages aligned.
• Update product-facing repository screenshots and examples.
• Preserve upstream attribution and distinguish fork-specific operational guidance from upstream product documentation.

Naming criteria

• One word, easy to pronounce and spell.
• Distinctive enough for a domain, GitHub repository, package, and visual identity.
• Feels like a durable product, not a generic bookmarking feature.
• Check trademark, domain, social-handle, GitHub, npm, and App Store or Play Store availability before committing.

Migration guardrails

• Prefer changing user-facing identity first. Preserve internal Karakeep-compatible identifiers unless a deliberate migration adds clear maintenance value.
• Do not break existing container updates, production state, API clients, browser-extension users, OAuth callbacks, or links without a documented migration path.
• Treat any public-domain or GitHub repository rename as a separate cutover plan with redirects and rollback steps.

Acceptance criteria

• Final name, logo direction, and naming rationale are approved.
• Product UI, landing page, extension, mobile, and MCP surfaces use the new identity.
• Metadata, manifest, icons, social cards, and SEO surfaces are updated.
• Repository, docs, deployment, and operator-facing references are updated or intentionally retained with rationale.
• Existing deployment continues updating normally after the rebrand.
• Existing production data and bookmark assets remain accessible.
• A final search confirms no unintended old user-facing branding remains.
• Live production verification covers the web app, worker processing, browser extension or mobile entry points as applicable, and public metadata.

Audit additions

Production Compose and container naming

• Define and document one stable production Compose project name, including the exact invocation used on the VPS.
• Do not depend on generated container names in runbooks, scripts, health checks, or deployment verification. Target Compose services with docker compose ... exec or discover containers through Compose labels.
• Align deploy/docker-compose.prod.yml, docs/fork-setup.md, .env.sample, README.md, AGENTS.md, CLAUDE.md, and GEMINI.md with the split web-main and workers-main GHCR image tags and the chosen Compose-project convention.
• Preserve the existing data volume and update path. A branding change must not recreate or orphan production data.

Asset inventory

• Replace the web app logo component, browser favicon, Apple touch icon, PWA manifest icons, PWA screenshots, metadata, and share assets as one versioned identity set.
• Replace corresponding browser-extension icons and manifest copy, mobile app icons and splash assets, landing-site favicon/logo/social cards, and docs-site favicon/logo/social card.
• Audit visible product copy in web UI, auth, onboarding, settings, wrapped/share export names, extension context menus, mobile display name, MCP-facing copy, RSS/webhook/email/API copy, and public documentation.
• Keep package scopes, mobile bundle identifiers, extension IDs, API namespaces, stored-data paths, and protocol keys unchanged unless a separately approved migration covers compatibility.

Additional acceptance criteria

• Production deployment guidance uses the chosen Compose project convention and contains no hardcoded generated container names.
• All assistant and operator documentation describes the current split web and workers image tags.
• Web, PWA, extension, mobile, landing, and docs assets have been updated from a single approved logo source, with light and dark variants where required.
• A repository-wide audit distinguishes intentionally retained internal karakeep compatibility identifiers from stale user-facing branding.

[absolutepraya]

Scope split and completion status

The core one-word identity work is complete through merged PRs #31, #43, #44, and #45:

• Marka is the public product identity across the web app, repository, README, installer, operator docs, GHCR, VPS paths, Hermes-facing skill, and canonical domain.
• https://marka.abhipraya.dev is live, while keep.abhipraya.dev permanently redirects with path/query preservation.
• The repository is absolutepraya/marka and production runs the paired Marka images.

The remaining identity work is intentionally split into focused follow-ups:

• feat(landing): establish a fork-owned Marka landing site #25: Marka landing site
• docs: publish fork-owned Marka documentation at docs.marka.abhipraya.dev #26: hosted Marka documentation
• feat(identity): rebrand deferred extension, mobile, MCP, and distribution surfaces #46: deferred browser-extension, mobile, MCP, CLI, and distribution-facing identity surfaces

Compatibility-sensitive internal identifiers remain preserved by design rather than being treated as stale public branding.