Decide and plan a distinct project identity

[DenWin]

Purpose

The project is moving beyond a lightly modified fork. Choose a distinct project identity before new documentation, UI work, images, packages, and release automation make a later rename more expensive.

This issue is a decision and migration plan. It does not authorize an immediate repository rename.

Decision criteria

The name should be:

• distinct from existing conversion products and open-source projects;
• easy to pronounce, type, search for, and use as a repository/container name;
• broad enough for document, image, audio, video, and data conversions;
• appropriate for a self-hosted application rather than only an online service;
• usable without implying affiliation with Docker or another vendor;
• compatible with the existing license and preserved upstream attribution.

Initial screening

TransmuteBox is the current working candidate. It describes a self-hosted conversion appliance and had no exact public GitHub repository match, nor a repository under DenWin, when checked on 2026-08-05.

Rejected during the initial screen:

• FormatForge: already used by multiple format/file conversion products and packages.
• ConvertDeck: already used by an online conversion site.
• MorphDock: appears in scientific docking literature and is less clear for this product.

The working candidate is not approved until the checks below are complete.

Tasks

• Write a one-sentence product positioning statement and confirm the intended audience.
• Generate at least three viable candidates, including TransmuteBox.
• Search GitHub, major package registries, OCI registries, app stores, search engines, and relevant domains.
• Perform an appropriate trademark/name-conflict check in intended jurisdictions.
• Record the decision and reasoning in an ADR under Establish an ADR process and record accepted architectural decisions #30.
• Inventory every current identity reference: repository name, UI text, docs, URLs, image names, package metadata, environment variables, volume/data paths, badges, workflows, and release artifacts.
• Define a compatibility and migration policy before changing identifiers.
• Preserve the license, copyright notices, upstream attribution, and Git history.
• Decide whether stable technical identifiers should remain unchanged to avoid breaking deployments.
• Plan GitHub redirects, old OCI image aliases/deprecation notices, and release communication.
• Execute the rename in a dedicated pull request only after the plan is approved.

Acceptance criteria

• The selected name passes the documented collision checks.
• An ADR records the decision, alternatives, and consequences.
• A complete rename inventory and rollback plan exist.
• Compatibility behavior for repository URLs, images, configuration, and persisted data is explicit.
• Automated checks cover changed runtime identifiers and documented upgrade paths.
• The renamed project continues to credit C4illin/ConvertX and complies with its license.

Related work

• Epic: Establish retrospective initial project documentation #24
• Document project purpose, scope, terminology, and repository map #25
• Document current-state architecture, data flows, and security boundaries #26
• Create contributor, development, and testing documentation #27
• Create deployment, operations, backup, recovery, and security runbooks #28
• Document HTTP interfaces and end-user conversion workflows #29
• Establish an ADR process and record accepted architectural decisions #30
• Epic: Harden repository, application, build, and delivery #31