Document the complete first-package rollout

AGENTS.md

@@ -39,6 +39,7 @@ PHP style authority: https://github.com/extension-builder/joomla/blob/main/docs/
 - 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`.
+- First-package readiness includes working manual release workflows for both independent plugins. Run their version/update-feed/OctoShoom workflows before the component workflow; never leave manual manifest editing or tag creation as an undocumented prerequisite. Keep the exact first-release order and secret scope in `docs/RELEASE.md`. CI success verifies code and installation; only a successful release run verifies publication credentials and the published package.
 
 ## Verification
 

CHANGELOG.md

@@ -11,6 +11,7 @@
 
 ### 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.
 - Document GitHub secrets and the source-installation contract for future agents.
 

changelog.xml

@@ -10,6 +10,7 @@
       <item>Point component update discovery to the maintained native XML feed.</item>
     </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>Document release secrets and source installation requirements for maintainers and agents.</item>
     </addition>

docs/IMPLEMENTATION.md

@@ -2,7 +2,7 @@
 
 ## Repository and source baseline
 
-The migration PR #1 is merged; source-installation and release realignment is on `fix/standalone-octojpack`. 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 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`.
 
 ## Implemented server
 
@@ -26,6 +26,8 @@ The tracked component source contains production dependencies, installation data
 
 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 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.
+
 ## Historical verified runtime evidence
 
 The following results belong to the recorded September 24 revisions. Their distribution builders have since been removed; they do not certify the current release workflow. Current source/release verification is recorded separately in the release-alignment PR.

docs/RELEASE.md

@@ -31,14 +31,30 @@ Follow the native [git-user](https://github.com/octoleo/git-user#workflows), Oct
 
 ## Release sequence
 
-Tag reviewed releases of both plugins first. Then run **Release component with OctoJPack and OctoShoom** on `main`, entering the next unused version, such as `1.2.3` or `v1.2.3`.
+All three extension repositories provide a manual version release. In each repository, open **Actions**, select the workflow below, choose **Run workflow**, select `main` and enter the release version. The workflow creates the tag; pushing a tag by itself does not start a release.
+
+For the first package, run these in order and wait for each to succeed:
+
+| Order | Repository and workflow | Result |
+| --- | --- | --- |
+| 1 | [mcp_plugin — Release console plugin with OctoShoom](https://github.com/joomengine/mcp_plugin/actions/workflows/release.yml) | Console tag, plugin update entry and checksum. |
+| 2 | [mcp_webservices — Release webservices plugin with OctoShoom](https://github.com/joomengine/mcp_webservices/actions/workflows/release.yml) | Webservices tag, plugin update entry and checksum. |
+| 3 | [mcp_component — Release component with OctoJPack and OctoShoom](https://github.com/joomengine/mcp_component/actions/workflows/release.yml) | Component tag, combined package tag, package update entry and checksum. |
+
+Choose an unused version above the development baselines. For example, `0.1.2` is suitable for all three first releases; `v0.1.2` is also accepted. The component's `0.1.0` and `0.1.1` changelog entries already describe development baselines and cannot be reused. Plugin versions may differ from the component version; the combined package always follows the component.
+
+The six Git identity/signing/SSH secrets above must be available to **each extension repository**. An organization secret can be shared with all three. The component additionally needs `GIT_TOKEN`; its SSH identity must be able to push to both `mcp_component` and `mcp_package`. Each plugin's SSH identity must be able to push to its own repository. The package repository needs no separate release workflow or secrets: OctoJPack publishes it from the component workflow.
+
+Once plugin tags exist, subsequent package releases can reuse them. Release a plugin again only when its source changes. Keep a pending changelog section in each repository being released.
+
+The component workflow performs these steps:
 
 1. Freeze component/changelog metadata, commit and create its version tag.
 2. OctoJPack builds and publishes the three-extension package using the component version.
 3. Update this repository's feed with the package version and tagged package URL, clearing the previous archive hash.
 4. OctoShoom hashes the published package archive and commits the checksum here.
 
-The package must exist before its hash can be calculated. A failed packaging step stops feed publication and hashing. Neither shared tool's work is duplicated locally. Rerunning keeps existing tags and preserves a matching feed entry/hash.
+The package must exist before its hash can be calculated. A failed packaging step stops feed publication and hashing. Neither shared tool's work is duplicated locally. Rerunning keeps existing tags and preserves a matching feed entry/hash. A successful component workflow makes the package tag ZIP installable from `mcp_package` and publishes its checksum in this repository's update feed; no manual packaging or XML editing is needed.
 
 ## Changelogs and dependencies