Make repository metadata and label tooling safe across repositories

[daniel-kindl]

Problem

repo-meta and repo-labels are intended to be reusable user-side tools, but their current ownership model is ambiguous and unsafe once the commands are installed globally.

repo-meta can apply dk-devkit metadata to another repository

repo-meta uses manifests/github-metadata.json from the dk-devkit checkout by default, but when --repo is omitted it resolves the repository from the current working directory.

That means a globally installed command can be invoked like this:

cd ~/projects/t1pal
repo-meta sync

and try to converge T1Pal toward dk-devkit's description, topics and repository settings.

This is especially dangerous because some replacements, such as replacing a non-empty description, are not currently classified as destructive and therefore may not require confirmation.

repo-labels needs an explicit ownership model

repo-labels treats manifests/github-labels.json as an exact canonical label set. Exact sync can delete labels that are not in the manifest.

That is fine only if the manifest is deliberately a universal taxonomy for every repository. It becomes wrong if dk-devkit-specific labels such as platform-support or verification are added and the same manifest is then used from dkkb, T1Pal, LUDWISE, etc.

Goal

Define and enforce which repository owns which metadata/label configuration so these tools are safe to expose as normal global commands.

Design questions

Metadata

Prefer making the target explicit in the configuration rather than trusting the current working directory blindly. One possible shape:

{
  "version": 1,
  "repository": "daniel-kindl/dk-devkit",
  "description": "...",
  "topics": []
}

repo-meta should refuse a repository/config mismatch unless the user deliberately selects an alternate configuration or explicit override.

Also consider whether the reusable engine should look for a manifest owned by the target repository instead of always defaulting to dk-devkit's manifest.

Labels

Choose and document one model:

1. one universal label taxonomy for every repository; or
2. a shared base taxonomy plus repository-specific labels.

The second model is preferred because the projects have materially different domains. For example, platform-support and verification make sense for dk-devkit but should not automatically become required labels in unrelated repositories.

A possible design is:

shared canonical labels
        +
repository-local additions/overrides
        =
effective desired label set

Exact/destructive sync should operate on that effective set, not blindly on one dk-devkit-specific manifest.

Acceptance criteria

• repo-meta sync cannot silently apply dk-devkit's metadata manifest to a different repository.
• Repository/config mismatch has a clear, fail-closed error.
• Tests cover invoking repo-meta from a repository other than dk-devkit.
• The label ownership model is explicitly chosen and documented.
• If using shared + repository-specific labels, the merge/order/override semantics are deterministic and tested.
• Destructive label removal remains visible and requires the existing confirmation semantics.
• A repository-specific label does not become mandatory in unrelated repositories unless explicitly configured there.
• Documentation examples show how to manage dk-devkit and another repository safely.
• Existing repo-meta and repo-labels deterministic tests remain green.