ocl: add workflow for putting a PIH source export into a distro

plugins/ocl/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "ocl",
-  "version": "0.1.0",
+  "version": "0.2.0",
   "description": "Search and maintain the PIH concept dictionary in Open Concept Lab (OCL): look up concepts, check set membership, clone from CIEL, and create or edit PIH concepts and mappings.",
   "author": {
     "name": "Partners In Health"

plugins/ocl/skills/ocl-search/SKILL.md

@@ -155,5 +155,17 @@ Changes reach OpenMRS servers through released source versions, not the live sou
 - **Check the latest:** `GET /orgs/PIH/sources/PIH/versions/?limit=5&verbose=true` lists recent versions. They're numbered sequentially (`1.8.x`), each with a short description of what changed.
 - **Create the next one:** `POST /orgs/PIH/sources/PIH/versions/` with `{"id": "<next>", "description": "<what changed>", "released": true}`.
 - **Verify it:** `GET …/PIH/latest/` should return it, and `GET …/PIH/<version>/concepts/<id>/` reads that version's snapshot.
-- **Get the export:** the zip export is built separately. Right after creation, `GET …/PIH/<version>/export/` may return 204 (not ready). PIH distros ship the export zip in `content/configuration/backend_configuration/ocl/`.
+- **Get the export:** the zip export is built separately. Right after creation, `GET …/PIH/<version>/export/` may return 204 (not ready). Workflow 6 covers downloading it into a distro.
 - **Coordinate first:** releasing a version includes everyone's unreleased edits, not just yours. Check with the dictionary maintainers before releasing.
+
+### 6. Put a released version's export into a PIH distro
+
+OpenMRS servers load the PIH dictionary from an export zip committed to the distro, so a release only reaches them once its zip is swapped in.
+
+- **No checkout needed:** `PIH/pihemr` may have an *Update OCL export* GitHub Action (Actions tab → Run workflow) that does all of this and opens a PR. If it exists, point non-developers to it. The steps below are for doing it locally.
+
+1. **Get the download URL.** `GET …/PIH/<version>/export/` with the token returns `302`, redirecting to a signed S3 URL such as `https://ocl-production-s3.s3.amazonaws.com/orgs/PIH/PIH_PIH_v1.8.43.2026-10-29_212531.zip?…`. Read the `Location` header (`curl -s -D - -o /dev/null …`), then download that URL in a separate curl *without* the token header. It's already signed, and this keeps the token from going to S3.
+2. **Check the zip** before using it. It holds a single `export.json`. Confirm its `id` is the version you wanted, and note how many `concepts` and `mappings` it has, so you can tell the user.
+3. **Find the distro folder.** In the pihemr distro (`PIH/pihemr`), it's `content/configuration/backend_configuration/ocl/`. The folder holds exactly one zip, which is the current export. Other PIH config repos (e.g. `config-pihemr/configuration/ocl/`) carry their own, often older, export. Update only the ones the user asks for.
+4. **Check master first.** Others commit export bumps often, sometimes several a week. `git fetch`, then compare the branch's zip with `origin/master`'s. If master already has a newer version than the branch, rebase before swapping, so you don't hit a conflict on the binary file.
+5. **Swap the zip.** Delete the old one and add the new one, named to match master. Since Oct 2026 that's `orgs_PIH_sources_PIH_<version>_<YYYY-MM-DD_HHMMSS>.zip`, using the timestamp from the S3 filename. Older commits used the raw S3 name (`PIH_PIH_v<version>.<timestamp>.zip`). Then `git grep` for the old filename. No references have been found so far.