Feature request: auto-apply repository topics to GitHub-synced projects

Background

I use orx to reproduce papers and sync every paper project to GitHub. After a while this creates a search problem:

The private repos pile up under my account and they all have similar names (basically simplified paper titles). GitHub's repository search mostly looks at the repo name and description, so searching by title alone makes it hard to find "that RL paper I reproduced last month" — I can't remember the repo name, and there is no other signal to filter on.

The information is already there, though: when a project is created from a paper, orx records the paper_id. It just never gets published to GitHub, so it is unusable on the web.

What I would like

When a project is synced to GitHub, I would like the repo to also get repository topics, so I can find projects back by filtered search.

Topics rather than git tags: a tag is a version marker inside one repository and cannot be searched across repos, whereas a topic is repository-level metadata that GitHub search supports natively:

user:<my-account> topic:openresearch
user:<my-account> topic:arxiv-2401-12345
user:<my-account> topic:paper-repro

Suggested topic rules

• Always add openresearch
• When the project comes from a paper (has a paper_id), also add the paper id as arxiv-2401-12345 and paper-repro
  • the id should drop its version suffix so v1/v2 of the same paper land in one topic; otherwise search results get scattered
• Let me add my own topics on top, e.g. domain-llm or status-reproduced, to filter by area or status

Three small requirements

1. It can be turned off. Auto-tagging should be a toggle, on by default for new projects, but I want to be able to disable it.
2. It can be edited. After a project is created I should still be able to add or change topics, rather than only setting them once at creation time.
3. Existing projects get it too. Projects already synced before this feature existed should also get topics, without me re-pushing each one by hand.

One concern

If each push simply overwrites the repo's topics with the set computed for that push, it would wipe out topics I added by hand on GitHub, and projects pointing at the same repo could overwrite each other. So I would prefer an add-only or merge approach.

What we have already done

I have implemented and verified the above locally: automatic topics (including normalizing the paper id's version suffix), the toggle, custom topics on top, backfill for existing projects, and the merge semantics mentioned above (read the repo's current topics, take the union, skip the write when nothing changed, and never clear a repo with an empty set).

Requirement 2 is so far only a backend endpoint — there is no topic editor in the project settings UI yet, and I will add that in the PR as well.

So once this issue is filed I will open a PR with the change.

If you think the direction or some of the trade-offs need adjusting (topic naming, merge semantics, backfill scope), I will change them in the PR.

Test Image