RFC-006 — Hub Unification and Rename (Store → Hub)

*uthor:*Koder Engineering *ate:*20260429 *tatus:*Accepted *odule:*productsdevstore (to be renamed to productsdevhub) *upersedes:*none *elated:*backlog #026, #029

Table of Contents

1. Summary
2. Problem Statement
3. Goals
4. Non-Goals
5. Background
6. Decision
   • 6.1 Unification
   • 6.2 Rename Surface
   • 6.3 Wipe Without Migration
   • 6.4 Icon Direction
   • 6.5 Package Type Discriminator
7. Scope of Change
8. Execution Plan
9. Risks and Mitigations
10. Alternatives Considered
11. References

1. Summary

Rename *oder Store*to *oder Hub*across every surface (module path, domain, CLI, SDK, brand, icon, vocabulary, CI/CD, packaging) and unify under a single registry the distribution of all Koder ecosystem artifacts: apps, skills, personas, plugins and bundles. Wipe the old store.koder.dev deployment and the old registry without redirect or migration packages, since the Stack has not yet entered homologation and there is no external install base to preserve.

2. Problem Statement

Two unresolved tensions surfaced during the OpenClaw + ClawHub analysis (20260429):

1. *ragmentation pressure.*The OpenClaw ecosystem keeps the app store and the skill registry (ClawHub) as separate products. Replicating that split inside the Koder Stack would mean duplicating auth, moderation, UI, distribution, search, and governance for two registries that share 90% of their machinery. Backlog #026 already proposed unifying skills into the existing Store as a type=skill category to avoid this.

2. *rand mismatch.*"Store" carries a commercial connotation (App Store, Play Store, Microsoft Store) that fits paid app distribution but reads as wrong for free skills, personas and plugins. The Koder ecosystem is closer in audience and content mix to GitHub, Docker Hub and HuggingFace Hub — all of which use *ub*as the umbrella term for "registry + CLI + web + community surface".

The decision was deferred to backlog #029 ("RFC-015 — Koder Hub skill registry"), which proposed two paths: (A) extend the Store with a skills category, or (B) build a separate Hub product. This RFC closes that decision.

3. Goals

• One registry for every distributable artifact in the Koder ecosystem.
• One brand for every consumer surface: web, mobile, desktop, TV, CLI.
• Naming aligned with the technical-leaning audience of the Koder Stack (Hub > Store > Registry, ranked by fit).
• Clean cutover with zero surface area carried forward from the old name.

4. Non-Goals

• Preserving install base. The Stack is pre-homologation; there are no external users with the Koder Store app installed. No migration packages, no deprecation window, no 301 redirect from the old domain.
• Splitting consumer (store.koder.dev) from developer (registry.koder.dev) surfaces. The Hub is one place.
• Relitigating perartifact registry decisions (kpkg format, signing, federation, delta delivery, build attestation, upgrade chains, migration manifests). Those are governed by RFC001..005 (which become hubRFC-001..005 after this rename) and remain valid as written.

5. Background

The Koder Store currently ships as:

• *odule:*products/dev/store/ — Flutter apps (mobile, desktop, web), Go CLI (kstore), Go backend, privileged installer, landing page.
• *DK:*engines/sdk/store/ — Flutter package consumed by Hub-aware apps.
• *omain:*store.koder.dev.
• *ICD:*composite action `.giteaactionsstore-publishaction.yml, used by ~30 product *-release.yml` workflows that publish their builds to the registry on every release tag.
• *ocabulary*(memory project_koder_store_vocabulary): "Koder Store" = module; "Store registry" = backend instance; "Store clients" = UIs; "Store CLIwebdesktop/mobile" = specific UI; "Store catalog" = metadata index.
• *FCs:*five accepted RFCs (store-RFC-001..005) covering delta delivery, federation, build attestation, upgrade chains, migration manifests.

Backlog ticket #026 ("Koder Store: categoria 'skills' textbased + indexação vetorial") proposed extending the Store with a type=skill category. Ticket #029 ("RFC015 — Koder Hub") proposed promoting "Hub" to a peer registry and named this RFC to settle the question. Both tickets are superseded by the decisions in §6.

The naming convention for RFCs in meta/docs/stack/rfcs/ is <topic>-RFC-NNN-<title>.md (namespaced per module), aggregated via symlinks from each module's docs/rfcs/. Ticket #029 named this RFC "RFC015" (assuming a global counter that does not exist). The correct name under the convention is `hubRFC006* (continuing the existing storeRFC001..005` series under the new namespace).

6. Decision

6.1 Unification

A single registry distributes every Koder artifact type. Skills, personas, plugins and bundles are not separate registries — they are different values of the type field inside the same .kpkg envelope, served by the same backend, browsed through the same UIs, published through the same CLI, governed by the same auth and moderation pipeline.

Path A from #029 is adopted (unify into one registry). Path B (separate Hub product) is rejected: the only justification for a split is divergent governance, and there is none planned.

6.2 Rename Surface

The rename is *imultaneous*— no compatibility aliases, no transitional shim. See §6.3.

6.3 Wipe Without Migration

Old store.koder.dev deployment, DNS record, and the old registry data (every published .kpkg of every Koder app under the Store name) are deleted. No 301 redirect, no migration .kpkg for the old "Koder Store" app to point users at the new "Koder Hub" app, no deprecation window in the registry.

Justification: the Stack has not entered homologation. There are no external users with installed apps to break, no third-party links pointing at store.koder.dev, no badges in published collateral. The repopulation of the registry happens organically as each Koder product cuts its next release through the renamed CI pipeline.

6.4 Icon Direction

The current shopping-bag icon embodies the rejected commerce metaphor. The new icon follows direction * — Hub & Spoke* a 3D central node with 4–6 spokes irradiating to differently shaped artifacts (cube, sphere, prism), translating literally "the place where multiple things converge". Stylistic family: same lineage as Docker Hub and HuggingFace Hub icons without copying either. Generation and selection follow the same iterative batch workflow used for the Koder Flow icon (memory project_flow_icon_selection).

6.5 Package Type Discriminator

The .kpkg format (specs/kpkg/format.kmd) gains a required top-level field:

[kpkg]
type = "app" | "skill" | "bundle"

app is the existing semantics (installable binary for a target platform). skill is a SKILL.md + resources package, no binary, consumed by Kode at runtime. bundle is a manifest that declares dependencies on other .kpkgs (apps, skills, or both) and installs them transactionally.

The Hub catalog filters and the CLI verbs (khub install <slug>, khub search --type=skill) consume this discriminator. No separate Hub for skills; it is one catalog with a facet.

7. Scope of Change

Inventory built during the F1.1 mapping pass:

• **composite action to rename and edit (store-publish → hub-publish); removes hardcoded https://store.koder.dev/downloads/kstore-linux-amd64.
• *30*per-product release workflows in `.gitea/workflows