Separate component and package update feeds

.github/workflows/release.yml

@@ -1,4 +1,4 @@
-name: Release component with OctoJPack and OctoShoom
+name: Release component with OctoShoom and OctoJPack
 
 on:
   workflow_dispatch:
@@ -54,24 +54,23 @@ jobs:
             git tag -a "$tag" -m "Release $tag"
             git push --atomic origin HEAD:main "refs/tags/$tag"
           fi
-      - name: Build and push the package
-        id: package
-        uses: octoleo/octojpack@master
-        with:
-          config: .octojpack
-          push: 'true'
-      - name: Update the package download entry
+      - name: Update the component download entry
         env:
-          VERSION: ${{ steps.package.outputs.version }}
+          VERSION: ${{ inputs.version }}
         run: |
           php tools/release.php feed "$VERSION"
           git add joomengine_mcp_update_server.xml
           if ! git diff --cached --quiet; then
-            git commit -m "Publish package $VERSION update metadata"
+            git commit -m "Publish component $VERSION update metadata"
             git push origin HEAD:main
           fi
-      - name: Hash the published package
+      - name: Hash the published component
         uses: octoleo/octoshoom@master
         with:
           config-json: |
             {"update_servers":[{"owner":"joomengine","repo":"mcp_component","branch":"main","path":"joomengine_mcp_update_server.xml"}]}
+      - name: Build and push the package
+        uses: octoleo/octojpack@master
+        with:
+          config: .octojpack
+          push: 'true'

.octojpack

@@ -20,7 +20,7 @@
     "author_url": "https://dev.vdm.io/",
     "description": "JoomEngine MCP component, webservices routing, and local console server.",
     "version_id": "com_joomengine_mcp",
-    "update_servers": "https://raw.githubusercontent.com/joomengine/mcp_component/main/joomengine_mcp_update_server.xml",
+    "update_servers": "https://raw.githubusercontent.com/joomengine/mcp_package/main/.github/joomengine_mcp_update_server.xml",
     "changelog_servers": "https://raw.githubusercontent.com/joomengine/mcp_component/main/changelog.xml"
   },
   "repository": {
@@ -32,19 +32,22 @@
     {
       "owner": "joomengine",
       "repo": "mcp_component",
+      "mode": "tags",
       "id": "com_joomengine_mcp",
       "type": "component"
     },
     {
       "owner": "joomengine",
       "repo": "mcp_plugin",
+      "mode": "tags",
       "id": "joomengine_mcp",
       "type": "plugin",
       "group": "console"
     },
     {
       "owner": "joomengine",
       "repo": "mcp_webservices",
+      "mode": "tags",
       "id": "joomengine_mcp",
       "type": "plugin",
       "group": "webservices"

AGENTS.md

@@ -34,8 +34,9 @@ PHP style authority: https://github.com/extension-builder/joomla/blob/main/docs/
 - This is exclusively the component repository. A GitHub source ZIP of any reviewed branch or tag must install directly in Joomla, with every manifest file, production Composer dependency, licence and seed already tracked. No downstream Composer run, staging, compilation or packaging is allowed.
 - Keep production dependencies in `admin/vendor` and the installation seed in `admin/data`. When changing dependencies, run Composer as a maintainer, commit the lock and complete resolved runtime, and verify its autoload paths after relocation to Joomla's administrator component directory. Never hand-edit third-party vendor source.
 - Preserve SQL installation/schema updates and the JSON-driven customization-preserving seed updater. They are approved installation mechanisms; do not replace them merely to change the release process.
-- OctoJPack alone combines `mcp_component`, `mcp_plugin` (console) and `mcp_webservices` (HTTP routing), then writes to `joomengine/mcp_package` on `main`. Every plugin belongs in its own repository. Component installation, update and uninstall must never install, change or remove either plugin. The generated package manifest and assembly belong in the package repository. The package update feed `joomengine_mcp_update_server.xml` and shared `changelog.xml` deliberately remain in this component repository, as requested by the maintainer. Keep `.octojpack` concrete and usable from any machine: hardcode stable source/destination repositories, branch, raw GitHub update/changelog URLs and the raw licence URL. Use native latest-tag selection and `version_id`; do not render placeholders or rewrite the configuration during releases. Never change the shared Octo engines without an explicit request.
-- The manual Release workflow takes the next version and freezes component metadata before creating its tag. Call `octoleo/git-user@v2` once, then `octoleo/octojpack@master` with `.octojpack`, update the package feed with the published version, and call `octoleo/octoshoom@master`. Hashing must follow package publication because the feed downloads the package ZIP. Both actions inherit the same Git setup and environment. The feed contains the current `pkg_joomengine_mcp` / `package` / client `site` entry, downloads only `mcp_package` tag archives, and uses the component version. Clear the previous archive checksum when advancing the feed; OctoShoom supplies the new one. Keep credentials in GitHub secrets. Do not duplicate authentication, hashing, archive checks, packaging, configuration rendering or repository preflight logic locally. Local release code only edits the component version, changelogs and package update entry. Never move a released tag.
+- OctoJPack alone combines `mcp_component`, `mcp_plugin` (console) and `mcp_webservices` (HTTP routing), then writes to `joomengine/mcp_package` on `main`. Every plugin belongs in its own repository. Component installation, update and uninstall must never install, change or remove either plugin. The generated package manifest, package update feed and package hash workflow belong in the package repository. This repository's `joomengine_mcp_update_server.xml` serves only the component. Keep `.octojpack` concrete and usable from any machine: hardcode stable source/destination repositories, raw GitHub update/changelog URLs and the raw licence URL. Use explicit `mode: "tags"` on each extension and `version_id: com_joomengine_mcp`; the destination branch is independent of source-tag selection. Never render placeholders or rewrite the configuration during releases. Never change the shared Octo engines without an explicit request.
+- The manual Release workflow freezes component metadata and creates its tag, updates the component feed, calls `octoleo/octoshoom@master` to hash that component tag ZIP, then calls `octoleo/octojpack@master`. Configure `octoleo/git-user@v2` once; both actions inherit its setup. The component feed identifies `com_joomengine_mcp` / `component` / client `administrator` and downloads this repository's tag ZIP. Clear its previous checksum when advancing the feed; OctoShoom supplies the new one. The package tag independently triggers its package-repository workflow to update and hash its own feed. Keep credentials in GitHub secrets. Do not duplicate authentication, hashing, archive checks, packaging or repository preflight logic locally. Local release code only edits the component version, changelogs and component update entry. Never move a released tag.
+- The package feed URL is `https://raw.githubusercontent.com/joomengine/mcp_package/main/.github/joomengine_mcp_update_server.xml`. Keep the package workflow, feed, helper and maintenance docs under `.github`: native OctoJPack replacement already preserves this hidden folder. There is no ignore-folder action input to invent. The package manifest uses this package-only feed. The shared versioned changelog may continue to use this repository's raw `changelog.xml`.
 - Update **both** `CHANGELOG.md` and `changelog.xml` with every meaningful change. Put pending entries under the exact literal `[[[NEXT_VERSION]]]`; create a new pending section after the previous one is released. Do not invent a version or modify historical released entries. The workflow replaces this marker with its input version in both files.
 - Joomla changelog identity is `com_joomengine_mcp` / `component`. Use native categories `security`, `fix`, `language`, `addition`, `change`, `remove`, and `note`, each containing `item` children. Use matching human headings in Markdown. Record compatibility warnings under Note, errors fixed under Fix, and security fixes under Security. Keep both changelogs consistent and the manifest's `changelogurl` valid.
 - Check workflow syntax and changed metadata behavior. Source installation checks inspect the tracked source archive. Do not copy upstream action tests or restore package builders to make a test pass. See `docs/RELEASE.md`.

CHANGELOG.md

@@ -12,14 +12,15 @@
 ### Addition
 
 - Document the complete first-package workflow order, valid first versions and secret scope for both plugins and the component.
-- Add a manual version release workflow that freezes both changelogs, creates an immutable tag, publishes the package with OctoJPack, updates the package feed and runs OctoShoom against the published package.
+- Add a manual version release workflow that freezes both changelogs, creates an immutable tag, updates and hashes the component feed, then publishes the package with OctoJPack.
 - Document GitHub secrets and the source-installation contract for future agents.
 
 ### Change
 
-- Follow the Octoleo quick starts: set up Git once, let OctoJPack read `.octojpack` directly, then let OctoShoom hash the package download.
+- Follow the Octoleo quick starts: set up Git once, let OctoShoom hash the component download, then let OctoJPack read `.octojpack` directly.
 
-- Publish combined Joomla packages to `joomengine/mcp_package`; keep the package feed and shared changelog here, with the package version derived from the component.
+- Separate component and package update feeds: the component feed stays here; the package feed and tag-triggered OctoShoom workflow live in `mcp_package/.github`, preserved by native OctoJPack replacement.
+- Select each extension's latest tag explicitly; derive the package version from the component and retain the shared versioned changelog.
 - Extract webservices routing into its own `mcp_webservices` repository and include it as a separate OctoJPack extension.
 - Verify tracked source archives in component and console installation tests.
 

README.md

@@ -23,7 +23,7 @@ For native JCB background jobs, provide a PHP CLI executable compatible with the
 
 Remote AI applications can use the independent client's [Docker Compose launcher](https://github.com/joomengine/mcp_client/blob/feature/standalone-php-client/docs/DOCKER.md). Supply the HTTPS Joomla installation URL and native API token; the client discovers capabilities from this component. The console plugin is required for direct local Joomla MCP commands, while the remote client connects to the component's authenticated HTTP endpoint.
 
-The combined package is built exclusively by [OctoJPack](https://github.com/octoleo/octojpack), using the fixed `.octojpack` configuration, and published to [mcp_package](https://github.com/joomengine/mcp_package). The component version determines the package version. Run the manual **Release** workflow to freeze the changelogs, tag the component, publish the package, update the package feed here, and let OctoShoom hash that package ZIP. [Release instructions](docs/RELEASE.md) list the required secrets.
+The combined package is built exclusively by [OctoJPack](https://github.com/octoleo/octojpack), using the fixed `.octojpack` configuration and each extension's latest tag, and published to [mcp_package](https://github.com/joomengine/mcp_package). The component version determines the package version. Run the manual **Release** workflow to freeze the changelogs, tag the component, update its own feed and hash its tagged ZIP with OctoShoom, then publish the package. The package tag automatically starts its separate feed and OctoShoom workflow in `mcp_package`. [Release instructions](docs/RELEASE.md) list the required secrets and both workflow runs.
 
 ## Required capabilities
 

changelog.xml

@@ -11,12 +11,13 @@
     </fix>
     <addition>
       <item>Document the complete first-package workflow order, valid first versions and secret scope for both plugins and the component.</item>
-      <item>Add manual version releases with changelog freezing, immutable tags, OctoJPack package publication and subsequent OctoShoom package hashing.</item>
+      <item>Add manual version releases with changelog freezing, immutable tags, component update-feed hashing and subsequent OctoJPack package publication.</item>
       <item>Document release secrets and source installation requirements for maintainers and agents.</item>
     </addition>
     <change>
-      <item>Follow the Octoleo quick starts: set up Git once, let OctoJPack read .octojpack directly, then let OctoShoom hash the package download.</item>
-      <item>Publish packages to joomengine/mcp_package with the component version, keeping the package feed and shared changelog in this component repository.</item>
+      <item>Follow the Octoleo quick starts: set up Git once, let OctoShoom hash the component download, then let OctoJPack read .octojpack directly.</item>
+      <item>Keep the component-only feed here and the package-only feed and tag-triggered OctoShoom workflow in mcp_package/.github, preserved by native OctoJPack replacement.</item>
+      <item>Select each extension's latest tag explicitly, derive the package version from the component and retain the shared versioned changelog.</item>
       <item>Extract webservices routing into its own mcp_webservices repository and include it as a separate OctoJPack extension.</item>
       <item>Verify tracked source archives in component and console installation tests.</item>
     </change>

docs/ARCHITECTURE.md

@@ -52,7 +52,7 @@ JCB source-code fields remain permitted inert definition data under appropriate
 
 ## Distribution and references
 
-This repository is a directly installable component source tree, with production dependencies and installation data committed in place. MySQL/MariaDB and PostgreSQL schema updates and customization-preserving JSON seed updates remain installer-owned. Both plugins have independent repositories and native installers. Manual version releases tag the component, use the standalone `.octojpack` configuration to publish the combined package with the same version, update the package feed in this component repository, then run OctoShoom against the package archive. See RELEASE.md.
+This repository is a directly installable component source tree, with production dependencies and installation data committed in place. MySQL/MariaDB and PostgreSQL schema updates and customization-preserving JSON seed updates remain installer-owned. Both plugins have independent repositories and native installers. Manual version releases tag the component, update its component-only feed and hash its tagged archive, then use the standalone `.octojpack` configuration to publish the combined package with the same version. The package tag starts its own update-feed and OctoShoom workflow in `mcp_package`, whose `.github` directory survives package replacement. See RELEASE.md.
 
 - Original MCP: https://github.com/joomengine/joomla-mcp/tree/2cff50f4f6b440da3c684f9995a77efad32e1a36
 - Joomla/JCB layout: https://github.com/joomengine/Joomla-Component-Builder/tree/6.x

docs/IMPLEMENTATION.md

@@ -22,9 +22,9 @@ Approval previews show the selected definitions, frozen option layers, repositor
 
 The administrator Operations screen includes jobs/artifact metadata and cancellation. The `joomla_job_*` tools expose owned listing, status, cancellation, queued redispatch and bounded artifact reads. An API worker reloads the requesting Joomla user and rechecks authority; it does not become the trusted console owner.
 
-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, then OctoJPack publishes the package with that version. Its current-version update feed and shared changelog stay in this component repository; OctoShoom hashes the published package ZIP. See [RELEASE.md](RELEASE.md).
+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).
 
-PR #3 uses the native Octoleo actions with one Git setup and fully concrete `.octojpack` values. The feed is populated with the current 0.1.1 metadata; the first release run replaces it with the published package version and adds the real hash. No package tag has been published by this PR. The webservices plugin is extracted into `joomengine/mcp_webservices`, PR #1. Installed CI checks use its exact source revision to verify independent plugin install, upgrade and uninstall. Local metadata, source-installation, ownership, PHP and workflow syntax checks pass; the latest installed run is recorded in PR #3.
+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 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.