@6529-collections/release-request

This package creates, validates, and submits one 6529 release request.

Its central workflow saves each accepted request as one public GitHub Issue. It does not queue, merge, build, test, or deploy anything.

Commands

Print the current agent-input template:

6529-release-request template

The agent fills this template and removes any frontend or backend part that is not included in the release. The CLI adds schema_version, request_id, and created_at; the agent must not provide them.

Current source creates schema 0.000002. It can record ordinary frontend and backend service releases, plus the backend repository's separate operational monitoring package. A monitoring-only backend part uses empty deploy_units and operational_deployments: ["monitoring"]. This records the request; it does not give the Coordinator a monitoring deployment workflow.

Create a request from standard input:

6529-release-request create --input -

Create a request from a file:

6529-release-request create --input release-input.json

The command writes local files inside the project directory where it runs:

.release-coordinator/runs/<run-id>.json
.release-coordinator/outbox/<request-id>.json

Every create attempt saves a run record. Only a valid release request is saved to the outbox.

Submit a request

create remains available for local-only use. Product release skills use submit, which accepts the same agent-input JSON:

6529-release-request submit --input release-input.json

The CLI creates and validates the full request, saves the local run, starts one central workflow in the Release Coordinator repository, waits for it, and returns success or failure with a reason. The agent will not run gh, choose a workflow, or poll GitHub itself. Frontend and backend do not need their own submission workflow files.

The workflow validates the request again and saves one public GitHub Issue. The Issue title is Release request <request-id>. Its body contains the exact validated request, checksum, real GitHub actor, stable actor ID, workflow run, submission time, and accepted result. It starts with release-request, pending, and target labels. In this version, submitted means GitHub validated and saved the request. It does not mean that anything was approved or deployed.

By default, GitHub allows accounts with Write access to the Release Coordinator repository to start this manual workflow. The request JSON already names every repository, branch, pull request, and exact commit to release.

The release JSON says what should be released. Its requested_by field is not authentication. The GitHub submission proof says who sent it. Future delivery must keep those two records separate.

The CLI returns the request ID and Issue link. Sending the same request again reuses the same Issue. Reusing the same request ID with different JSON fails. Invalid requests create no Issue.

A future command can read the issue status without exposing GitHub workflow details to the agent:

6529-release-request status REQUEST_ID

The status command does not exist yet. This package returns and saves the Issue link as part of submit. The separate local Coordinator app can inspect pending Issues; it is not installed with this package. Consumer rollout status is tracked in the Coordinator repository.

Publishing

Stable version 0.0.4 is available from public npm. Source version 0.0.5 contains the new request shape but is not published by this local change. New releases use the protected publication workflow; product repositories pin a reviewed exact version rather than relying on a moving tag.

The package manifest points to the public npm registry and allows public access. The published archive contains only the CLI, source files, schema, example, README, license, and npm package metadata. It has no install-time scripts.

Install the public stable package by its exact version:

npm install --save-dev --save-exact @6529-collections/[email protected]

This npm command is for a standalone consumer. In the 6529 product repositories, use their 6529 wrapper and package policy instead of calling npm directly. Keep the version exact so a product repository always installs the reviewed archive. Version 0.0.4 was published from protected main by Trusted Publishing and its public npm provenance points to the exact GitHub workflow and source commit.

The central GitHub workflow checks every pull request. It can also publish an exact version from protected main. npm accepts that publish only from the named workflow and npm-publish environment. GitHub sends a short-lived proof; the workflow does not store an npm publishing token.