feat: provide openedx_learning djangoapp and CompetencyTaxonomy model

[jesperhodge]

AI-first work.

This was coded with human-in-the-loop. I created the initial instructions; Claude Code created a plan, I (Jesper) reviewed the plan and edited as needed; Claude Code implemented, and I reviewed the implementation and tested.

Related links

Implements #640.

What this does

Open edX already has "taxonomies", which are just collections of tags. This PR adds a way
to mark a taxonomy as holding competencies rather than ordinary tags, so that
competency-based education (CBE) features can later be built on top of it.

• Adds a new Django app, openedx_learning, and its first sub-package, cbe. This is a
  new home for learning-side features. It follows the same layout as the existing
  openedx_content app: one Django app, split into subfolders for readability.
• Adds one model, CompetencyTaxonomy. Marking a taxonomy as a competency taxonomy means
  creating one of these. It does not copy the taxonomy or replace it; it points at the
  existing taxonomy and adds a single extra setting to it.
• Adds a small public API so other code can ask "is this taxonomy a competency taxonomy?"
  without needing to know how that link is stored.
• Wires it all up: app registration, the database migration, a Django admin page, and a
  rule that keeps the dependency pointing one way (the CBE code may use the tagging code,
  never the reverse).

There is no REST API and no user interface here. This is the groundwork that the follow-up
tickets #641 and #642 are waiting on.

Depends on work in edx-platform

openedx-core is a library, so this app only becomes active once edx-platform lists it in
its settings. That platform-side work is tracked in openedx/openedx-platform#38958.

How to test

This runs entirely inside this repo against a local SQLite file, so you do not need
devstack, tutor, or MySQL. manage.py defaults to the projects.dev settings, which are
already configured to use SQLite at ./dev.db, so there is nothing to configure.

1. Set up a virtualenv (skip if you already have one for this repo):

python3 -m venv .venv
.venv/bin/pip install -r requirements/dev.txt
.venv/bin/pip install -e .

.venv/ is already in .gitignore.

2. Create the database and a login.

.venv/bin/python manage.py migrate
.venv/bin/python manage.py createsuperuser

The first command creates dev.db and applies all migrations, including the new
openedx_learning.0001_initial.

3. Start the server.

.venv/bin/python manage.py runserver

4. Add a competency taxonomy through the admin.

Open http://127.0.0.1:8000/admin/ and log in. You should see a section called
Open edX Core > Learning containing Competency Taxonomies. Click Add, fill in
Name (for example Nursing) and Export id (for example nursing-v1), and save.

You should land back on a list showing the columns Name, Export id, Enabled, and Taxonomy
overrides org.

5. Confirm it wrote to both tables.

sqlite3 dev.db "SELECT t.id, t.name, c.taxonomy_overrides_org
  FROM oel_tagging_taxonomy t
  JOIN openedx_learning_competencytaxonomy c ON c.taxonomy_ptr_id = t.id;"

You should get your row back, something like 1|Nursing|0.

That join returning a result is the thing worth seeing: one save through the admin created
a row in the existing tagging table and a linked row in the new CBE table. That is the
link this PR is really about.

Cleaning up: rm dev.db and re-run step 2 to start over.

[openedx-webhooks]

Thanks for the pull request, @jesperhodge!

This repository is currently maintained by @axim-engineering.

Once you've gone through the following steps feel free to tag them in a comment and let them know that your changes are ready for engineering review.

🔘 Get product approval

If you haven't already, check this list to see if your contribution needs to go through the product review process.

• If it does, you'll need to submit a product proposal for your contribution, and have it reviewed by the Product Working Group.
  • This process (including the steps you'll need to take) is documented here.
• If it doesn't, simply proceed with the next step.

🔘 Provide context

To help your reviewers and other members of the community understand the purpose and larger context of your changes, feel free to add as much of the following information to the PR description as you can:

• Dependencies

  This PR must be merged before / after / at the same time as ...

• Blockers

  This PR is waiting for OEP-1234 to be accepted.

• Timeline information

  This PR must be merged by XX date because ...

• Partner information

  This is for a course on edx.org.

• Supporting documentation
• Relevant Open edX discussion forum threads

🔘 Get a green build

If one or more checks are failing, continue working on your changes until this is no longer the case and your build turns green.

Details

---

Where can I find more information?

If you'd like to get more details on all aspects of the review process for open source pull requests (OSPRs), check out the following resources:

• Overview of Review Process for Community Contributions
• Pull Request Status Guide
• Making changes to your pull request

When can I expect my changes to be merged?

Our goal is to get community contributions seen and reviewed as efficiently as possible.

However, the amount of time that it takes to review and merge a PR can vary significantly based on factors such as:

• The size and impact of the changes that it introduces
• The need for product review
• Maintenance status of the parent repository

💡 As a result it may take up to several weeks or months to complete a review and merge your PR.

[kdmccormick]

two stylistic comments, but otherwise this looks good to me.

@ormsbee let me know if you'd like to do a pass before I approve and merge.

[kdmccormick]

i think that this is unnecessarily indirect, and as an abstraction it's leaky. you cannot stop callers from accessing taxonomy.competencytaxonomy directly, so renaming the CompetencyTaxonomy model would be a breaking change--we'd best treat it that way rather than pretending that all references to .competencytaxonomy will go through the two functions below.

I would just use the "competencytaxonomy" string literal in the function below, as is idiomatic in django code. mypy is sometimes actually smart enough to do type checking on expressions like taxonomies.select_related("competencytaxonomy"), but when it's been abstracted out to taxonomies.select_related(_COMPETENCY_TAXONOMY_RELATION), it will never be able to do any static analysis.

[kdmccormick]

could you add a note stating that this isn't yet used anywhere? bonus points if you add a comment linking to a task or epic issue that would implement it.

[ormsbee]

@kdmccormick: No need to block on me. Thank you.