Supply the GitHub token for OctoJPack public sources

.github/workflows/golden-image.yml

@@ -40,7 +40,7 @@ jobs:
         uses: actions/checkout@v7
         with:
           repository: joomengine/mcp_plugin
-          ref: fe387b962dab605191ef18efe4d5cb94821165d9
+          ref: eab466cfb51c9ef51bdb2f18431c2e2fcdafbc3b
           path: build/plugin-source
           persist-credentials: false
       - name: Check out the remote client bridge under test

.github/workflows/integration.yml

@@ -51,7 +51,7 @@ jobs:
         uses: actions/checkout@v7
         with:
           repository: joomengine/mcp_plugin
-          ref: fe387b962dab605191ef18efe4d5cb94821165d9
+          ref: eab466cfb51c9ef51bdb2f18431c2e2fcdafbc3b
           path: build/plugin-source
           persist-credentials: false
       - name: Check out the independent webservices plugin under test

.github/workflows/release.yml

@@ -20,7 +20,7 @@ jobs:
     if: github.ref == 'refs/heads/main'
     runs-on: ubuntu-latest
     env:
-      VDM_GLOBAL_TOKEN: ${{ secrets.GIT_TOKEN }}
+      VDM_GLOBAL_TOKEN: ${{ secrets.GIT_TOKEN || github.token }}
     steps:
       - uses: actions/checkout@v7
         with:

CHANGELOG.md

@@ -1,5 +1,12 @@
 # Changelog
 
+## [[[NEXT_VERSION]]]
+
+### Fix
+
+- Supply OctoJPack with the workflow's read-only GitHub token when the optional `GIT_TOKEN` secret is unset, so public tagged sources can be packaged.
+- Use the console plugin's independent-version installer fix in the installed Joomla and JCB checks.
+
 ## 1.0.0
 
 ### Fix

changelog.xml

@@ -1,5 +1,14 @@
 <?xml version="1.0" encoding="utf-8"?>
 <changelogs>
+  <changelog>
+    <element>com_joomengine_mcp</element>
+    <type>component</type>
+    <version>[[[NEXT_VERSION]]]</version>
+    <fix>
+      <item>Supply OctoJPack with the workflow's read-only GitHub token when the optional GIT_TOKEN secret is unset, so public tagged sources can be packaged.</item>
+      <item>Use the console plugin's independent-version installer fix in the installed Joomla and JCB checks.</item>
+    </fix>
+  </changelog>
   <changelog>
     <element>com_joomengine_mcp</element>
     <type>component</type>

docs/IMPLEMENTATION.md

@@ -1,8 +1,14 @@
-# Implementation status — 28 September 2026
+# Implementation status — 29 September 2026
 
 ## Repository and source baseline
 
-The migration PR #1 and release realignment PR #3 are merged. Original MCP source: `2cff50f4f6b440da3c684f9995a77efad32e1a36`. JCB source: `extension-builder/joomla@5ee658dd07eb749dca43ed4722f6cca7eb8208cf`. The development component version is 0.1.1. OctoJPack selects the tagged component and independent plugins from its fixed configuration and publishes to `joomengine/mcp_package`.
+The migration PR #1 and release realignment PR #3 are merged. Original MCP source: `2cff50f4f6b440da3c684f9995a77efad32e1a36`. JCB source: `extension-builder/joomla@5ee658dd07eb749dca43ed4722f6cca7eb8208cf`. The component has published tag `v1.0.0`. OctoJPack selects the tagged component and independent plugins from its fixed configuration and publishes to `joomengine/mcp_package`.
+
+## Package release follow-up
+
+[Release run 36543905015](https://github.com/joomengine/mcp_component/actions/runs/36543905015) updated and hashed the component feed, then stopped before packaging because `GIT_TOKEN` was unavailable and `VDM_GLOBAL_TOKEN` was empty. The `.octojpack` format matches the native loader; its `.global.token` error is the fallback for a missing environment token. The workflow now supplies the built-in read-only GitHub token unless `GIT_TOKEN` is configured. SSH publication still uses the single Git User setup. No published tag or checksum is changed by this fix; package publication remains unverified until the release workflow completes.
+
+The first [installed matrix run for PR #6](https://github.com/joomengine/mcp_component/actions/runs/36544871715) rejected the console plugin because the old pinned installer required its release major to match the component's. The [JCB golden-image run](https://github.com/joomengine/mcp_component/actions/runs/36544871672) also stopped at console installation. Both workflows now pin console plugin `eab466cfb51c9ef51bdb2f18431c2e2fcdafbc3b` from [plugin PR #4](https://github.com/joomengine/mcp_plugin/pull/4), which checks the supported component minimum independently of the plugin version. Its installed regression tests read the installed plugin manifest, including in the JCB container fixture. Results for this updated pin are recorded in PR #6 after CI completes; the earlier failed runs are not passing evidence.
 
 ## Implemented server
 
@@ -24,7 +30,7 @@ The administrator Operations screen includes jobs/artifact metadata and cancella
 
 The tracked component source contains production dependencies, installation data and its administrator licence. Source ZIP installation replaces local archive builders. The manual release freezes metadata and tags the component, updates its component-only feed and hashes its tagged ZIP, then OctoJPack publishes the package with that version. The package tag triggers its own feed and OctoShoom workflow in `mcp_package`. The shared versioned changelog remains here. See [RELEASE.md](RELEASE.md).
 
-The native Octoleo actions use one Git setup and fully concrete `.octojpack` values. Each extension explicitly selects its latest tag. The component feed has the current 0.1.1 prepared metadata; the first release run updates it to the published component version and adds its real hash. Package automation and its separate feed stay under `mcp_package/.github`, which native OctoJPack preserves during replacement. The extracted webservices plugin remains independently installed, upgraded and uninstalled; no component runtime changes are needed for feed separation.
+The native Octoleo actions use one Git setup and fully concrete `.octojpack` values. Each extension explicitly selects its latest tag. The component feed has the published 1.0.0 download and its OctoShoom hash. Package automation and its separate feed stay under `mcp_package/.github`, which native OctoJPack preserves during replacement. The extracted webservices plugin remains independently installed, upgraded and uninstalled; no component runtime changes are needed for feed separation.
 
 The first-package follow-up adds the missing webservices version/feed/OctoShoom workflow and completes the rollout instructions in [RELEASE.md](RELEASE.md). Release both plugins through their manual workflows, then release the component; no hand-edited release metadata is required. Repository secrets and an authorized release run remain deployment setup, not something inferred from green source/installation CI. This follow-up does not create release tags or publish a package.
 

docs/RELEASE.md

@@ -11,7 +11,7 @@ This repository contains only the component. Its source ZIP installs directly in
 | Component | https://raw.githubusercontent.com/joomengine/mcp_component/main/joomengine_mcp_update_server.xml | `com_joomengine_mcp`, component, administrator | `mcp_component/archive/refs/tags/vVERSION.zip` |
 | Package | https://raw.githubusercontent.com/joomengine/mcp_package/main/.github/joomengine_mcp_update_server.xml | `pkg_joomengine_mcp`, package, site | `mcp_package/archive/refs/tags/vVERSION.zip` |
 
-The component manifest references the component feed. OctoJPack writes the package manifest with the package feed URL from `.octojpack`. OctoShoom hashes the exact GitHub tag ZIP named in each feed, so each checksum belongs to that extension's download. The component's initial 0.1.1 entry is prepared metadata; its first release replaces the version and adds a real checksum after publishing the tag.
+The component manifest references the component feed. OctoJPack writes the package manifest with the package feed URL from `.octojpack`. OctoShoom hashes the exact GitHub tag ZIP named in each feed, so each checksum belongs to that extension's download.
 
 The shared, versioned changelog remains https://raw.githubusercontent.com/joomengine/mcp_component/main/changelog.xml. The licence remains https://raw.githubusercontent.com/joomengine/mcp_component/main/LICENSE. Package versions follow component versions, so Joomla can use the same changelog by version.
 
@@ -31,13 +31,15 @@ Follow the native [git-user](https://github.com/octoleo/git-user#workflows), Oct
 | `GPG_KEY`, `GPG_USER` | Signing key and its user ID. |
 | `SSH_KEY`, `SSH_PUB` | Matching SSH keypair. |
 
-Each plugin and the package workflow needs permission to push to its own repository. The component's SSH identity needs permission to push to both `mcp_component` and `mcp_package`. The component additionally uses `GIT_TOKEN` for OctoJPack's source API access, exposed as `VDM_GLOBAL_TOKEN`. The package workflow does not invoke OctoJPack and needs no packaging token.
+Each plugin and the package workflow needs permission to push to its own repository. The component's SSH identity needs permission to push to both `mcp_component` and `mcp_package`. OctoJPack reads the public source tags and archives using the workflow's built-in GitHub token with `contents: read`, exposed as `VDM_GLOBAL_TOKEN`. An optional `GIT_TOKEN` secret overrides that token. Git pushes still use the SSH identity. The package workflow does not invoke OctoJPack and needs no packaging token.
+
+For standalone OctoJPack runs, export `VDM_GLOBAL_TOKEN` or set it in OctoJPack's environment file. The native loader requires that value even for public sources. Keep credentials out of `.octojpack`; its repository, feed, changelog and licence values remain fixed and usable from any machine.
 
 Git User runs once per workflow. The shared actions inherit that Git setup; credentials stay in GitHub secrets. No repository placeholders, configuration rendering, local package builder or duplicate hash implementation is needed.
 
 ## First release
 
-In each extension repository, open **Actions**, select its release workflow, choose **Run workflow**, select `main` and enter an unused version. For example, `0.1.2` works above all current development baselines; `v0.1.2` is also accepted. The component's 0.1.0 and 0.1.1 changelog entries cannot be reused. The workflow creates the tag; pushing an extension tag manually does not start these manual release workflows.
+In each extension repository, open **Actions**, select its release workflow, choose **Run workflow**, select `main` and enter an unused version above the current manifest version. A `v` prefix is also accepted. Released versions and development-baseline changelog entries cannot be reused for new changes. The workflow creates the tag; pushing an extension tag manually does not start these manual release workflows.
 
 | Order | Workflow | Result |
 | --- | --- | --- |
@@ -50,6 +52,8 @@ Wait for both plugin releases before starting the component release. Wait for **
 
 Later component releases can reuse existing plugin tags when those plugins have not changed. Plugin versions may differ; the package always follows the component version. A completed release needs no manual ZIP upload, packaging or update-XML editing.
 
+If a component release stops after tagging but before packaging, fix the workflow on `main`, then start a **new** manual run with that existing version. Re-running the failed job would reuse its old workflow revision. The new run preserves the existing component tag and checksum and resumes packaging. Publish any required plugin fixes first, so OctoJPack selects their corrected latest tags.
+
 ## Changelogs and dependencies
 
 Keep `CHANGELOG.md` and `changelog.xml` consistent, with new changes under one literal `[[[NEXT_VERSION]]]` section in each file. Release replaces the marker with its version. Create another pending section when subsequent changes begin; preserve released history. Use Joomla categories `security`, `fix`, `language`, `addition`, `change`, `remove` and `note`, with `item` children and matching Markdown headings.