Migrate kaizen distribution to Forgejo

workplans/kaizen-agentic-WP-0010-forgejo-pypi-migration.md

@@ -4,7 +4,7 @@ type: workplan
 title: "Migrate package distribution from gitea to forgejo before CoulombCore retires"
 domain: agents
 repo: kaizen-agentic
-status: proposed
+status: finished
 owner: kaizen-agentic
 topic_slug: custodian
 created: "2026-08-20"
@@ -12,20 +12,21 @@ updated: "2026-08-20"
 depends_on: []
 tasks:
   - id: T01
-    status: todo
+    status: done
     title: Establish whether kaizen-agentic packages already exist on forgejo
   - id: T02
-    status: todo
+    status: done
     title: Publish current versions to the forgejo PyPI index
   - id: T03
-    status: todo
+    status: done
     title: Repoint Makefile and all six docs in one change
   - id: T04
-    status: todo
+    status: done
     title: Verify a clean install from forgejo on an uncached machine
   - id: T05
-    status: todo
+    status: done
     title: Retire the gitea variables and close out
+state_hub_workstream_id: "78d33e10-49dc-41c2-8fbf-475520704f08"
 ---
 
 # KAIZEN-WP-0010 — Migrate package distribution to forgejo
@@ -39,12 +40,10 @@ the operator on that date.
 registry and a **PyPI package index** at `/api/packages/coulomb/pypi`. Both stop
 existing when the host does.
 
-kaizen-agentic appears to be the only repo in the estate that never migrated.
-The rest moved in early July — `issue-core` carries both endpoints
-(`Makefile:68` gitea, `Makefile:69` forgejo, publish targets at `240` and `250`),
-and `vergabe-teilnahme/pyproject.toml` already points at
-`forgejo.coulomb.social/api/packages/coulomb/pypi/simple/`. So the destination
-exists and is in use; this repo was missed.
+kaizen-agentic's release workflow moved to Forgejo in early July, but the
+Makefile, consumer documentation, issue links, templates, and capability
+metadata did not move with it. This left a split-brain distribution story even
+though the destination already existed and was in use.
 
 ### What breaks, and why it is worse than a broken link
 
@@ -76,8 +75,9 @@ together — a half-migrated doc set is how the next repo gets missed.
 
 ```task
 id: KAIZEN-WP-0010-T01
-status: todo
+status: done
 priority: high
+state_hub_task_id: "c00cbfde-7cfa-46d3-9e81-73d5c504a78f"
 ```
 
 **Establish whether kaizen-agentic packages already exist on forgejo.** Check
@@ -88,14 +88,19 @@ Record what is there against what gitea holds. If forgejo already has current
 versions, T02 becomes a no-op and this finishes much faster than feared — worth
 five minutes before assuming a full republication.
 
-Credentials: this needs a forgejo package token, not a gitea one. Route through
-`warden plan "forgejo package publish token"` rather than reusing
-`GITEA_PACKAGE_TOKEN`, and never paste a token into the Makefile or a doc.
+**Result (2026-08-20):** Forgejo anonymously serves the current `1.4.0` wheel
+and sdist. Gitea serves `1.1.0`, `1.2.0`, and `1.4.0`. The repository version
+and latest tag are both `1.4.0`.
+
+The simple package index is anonymously readable. If a write or authenticated
+API inventory is ever needed, route the Forgejo credential through `warden`
+and never paste a token into the Makefile or documentation.
 
 ```task
 id: KAIZEN-WP-0010-T02
-status: todo
+status: done
 priority: high
+state_hub_task_id: "3a65ae76-08fe-4535-aebf-c1bdec0860d9"
 ```
 
 **Publish current versions to the forgejo PyPI index.** Only the versions that
@@ -106,10 +111,15 @@ actually pins an old version.
 `issue-core/Makefile:250` is a working example of the forgejo `twine upload`
 target and is the shortest path to a correct invocation.
 
+**Result (2026-08-20):** No-op. The current `1.4.0` release was already on
+Forgejo, published by `.forgejo/workflows/publish-python-package.yml`; no
+credential request or duplicate upload was necessary.
+
 ```task
 id: KAIZEN-WP-0010-T03
-status: todo
+status: done
 priority: high
+state_hub_task_id: "872a5464-a985-473d-a65f-099a30b4d1d0"
 ```
 
 **Repoint the Makefile and all six docs in one change.** Add
@@ -126,10 +136,18 @@ Also update `GITEA_PACKAGE_USER` / `GITEA_PACKAGE_TOKEN` variable *names* if you
 keep the credential envelope — a variable called `GITEA_*` pointing at forgejo is
 the kind of thing that survives for years and confuses everyone who reads it.
 
+**Result (2026-08-20):** Removed the Gitea Make variables and target outright;
+`publish-forgejo` and `FORGEJO_PYPI_*` are the only release path. Consumer
+instructions now use the anonymously readable Forgejo index without embedding
+unnecessary credentials. Updated the six named documents plus operational
+references in contributing/scope/capability metadata, CLI feedback URLs, issue
+templates, project metadata, and packaged agent guidance.
+
 ```task
 id: KAIZEN-WP-0010-T04
-status: todo
+status: done
 priority: high
+state_hub_task_id: "f4e40f59-ca22-4dd5-b043-7d69c8cf0be5"
 ```
 
 **Verify a clean install from forgejo on a machine with no cache.** A `pip
@@ -140,10 +158,16 @@ still wrong regardless of what the registry holds.
 
 This is the task that actually closes the risk. T01–T03 are preparation.
 
+**Result (2026-08-20):** A new temporary virtual environment installed
+`kaizen-agentic==1.4.0` with `--no-cache-dir` and the documented anonymous
+Forgejo extra index. Pip downloaded the wheel from Forgejo; both the CLI and
+Python package reported `1.4.0`.
+
 ```task
 id: KAIZEN-WP-0010-T05
-status: todo
+status: done
 priority: medium
+state_hub_task_id: "c9f9c64f-27d4-41de-a1e8-a01734ce7964"
 ```
 
 **Close out.** Remove any remaining gitea references from operational files
@@ -154,6 +178,10 @@ tidy a grep loses information.
 Tell `prj-state-hub-retirement` when T04 passes; this is tracked there as
 `SHR-WP-0002-T07` and is one of two items gating CoulombCore's retirement.
 
+**Result (2026-08-20):** No CoulombCore/Gitea host, package variable, publish
+target, workflow path, or issue-template path remains in operational files.
+Historical workplans and changelog entries were deliberately preserved.
+
 ## Notes
 
 - Drafted by `prj-state-hub-retirement` on 2026-08-20 from the estate-wide sweep