6529 Release Coordinator

The Coordinator is being built to handle releases across the frontend and backend. Request intake is live. One local command now checks either a guarded set of Issues or the whole inbox, rehearses suitable PRs, runs supported sandbox service/database checks, and updates those same tickets with the result. A sandbox run can now move one selected no-database-change batch through protected test staging, product-shaped deployment workflow mirrors, matching E2E against the built backend and frontend, and protected test production. The merged source also lets one verified database-changing sandbox ticket take that path alone. The current working tree extends that same Coordinator engine to the real repositories and their existing deployment/E2E workflows. This real adapter has offline tests but has not been merged or exercised in a live product release yet; see progress for the evidence boundary.

Operational-monitoring release requests are recorded and labelled, and their exact PRs are checked. The sandbox deploys a sample monitoring package for a complete production ticket after the merge into test main, before the production application deployments. The real adapter calls the existing backend monitoring workflow from the exact merged main commit in the same order; that path is implemented locally but has no live product acceptance yet.

The public CLI creates a request, validates it, saves local records, and submits it to a central GitHub workflow. The workflow saves one public Issue and returns its link. The local reader checks open request Issues against their workflow results. The readiness command also inspects current PRs and backend dependency order. These commands do not approve or perform a release.

Frontend and backend release-recording integrations are merged. Current versions, exact PR/commit evidence, local-versus-remote state, tests, and remaining work are tracked in Progress and next steps.

Run the ticket workflow

Use one command with an explicit repository profile and inbox scope:

Sandbox service checks require GitHub CLI 2.97.0 or later; see the command requirements.

RELEASE_COORDINATOR_PROFILE=sandbox RELEASE_COORDINATOR_SCOPE=filtered \
  npm run inbox:run -- --issue 101 --issue 104 --actor GITHUB_LOGIN --json

The local controller runs this sequence, then exits:

1. Verify the saved ticket and inspect its PRs, checks, reviews, and dependencies.
2. Retire clearly outdated or already-merged requests; give other blockers a reason.
3. For a suitable ticket, create and save its merge plan from the ticket and current configured destinations, then try its exact PRs in temporary local Git repositories.
4. For a complete supported sandbox ticket, run the database, worker, API, and frontend checks on an isolated GitHub Actions runner.
5. Save the results and update the same ticket's labels, status comment, and decision history.

The Issue numbers are the complete inbox visible to this run. Every one must be an open, verified release request submitted by GITHUB_LOGIN; otherwise the run stops before taking the journal lock. After that guard, the normal Coordinator logic applies. Compatible no-database-change tickets can batch, while a verified database-changing ticket is still selected alone.

To expose the complete selected-profile inbox instead, use:

RELEASE_COORDINATOR_PROFILE=sandbox RELEASE_COORDINATOR_SCOPE=inbox \
  npm run inbox:run -- --json

A selected batch continues in dependency order through its configured staging branches. A production-target request continues to its configured main branches only after matching staging E2E passes. Every integration PR, workflow operation, exact commit pair and result is saved before the ticket is completed. Each fake environment builds from its exact commit, uploads a short-lived GitHub Actions artifact, and runs E2E through the built backend and frontend HTTP servers. The Coordinator checks the pinned workflow, contract, build helper and runner files at the exact fake environment commit before dispatch. Trial, staging and production PRs use separate commit IDs, so one PR's checks cannot be reused as another stage's evidence.

A passing rehearsal adds rehearsal:passed. A selected sandbox batch completes only after its required test release sequence passes. Sandbox application results have their own services:* label; no product deployment occurs. Conflicts and missing evidence get visible reasons and next actions. Repeating unchanged work rechecks the facts without adding duplicate comments or decisions.

The ticket already supplies the exact PRs, services, target, and dependencies. The Coordinator creates the rehearsal plan itself. Both profiles currently test against each repository's current main; this does not change main or choose a deployment policy. See the profiled inbox guide. Use RELEASE_COORDINATOR_SCOPE=inbox to process the complete inbox. Sandbox runs first check each visible ticket, then test suitable whole tickets together through the bounded batch flow below. filtered changes only visibility; it does not switch off batching, database isolation, target ordering, or release rules. Real runs use the same batching, database isolation, release order and recovery decisions, but their adapter targets the product repositories and existing product workflows. A rehearsal alone never changes a shared branch; release mutations begin only after the exact selected batch passes its required checks.

inbox:run replaces the old inbox:process and merge:rehearse commands; those entry points have been removed. inbox:read and readiness:check remain read-only diagnostics. Submission still uses the public CLI or private request:submit.

The command writes the selected inbox's managed ticket presentation and codex/inbox-state history, where plans are saved before Git work. In sandbox it also dispatches the fixed, pinned service-check workflow in the test backend. It also creates temporary local Git repositories and saves rehearsal reports with requested PR versions and destinations in profile-specific local paths before updating the ticket. An already-merged closure says the Coordinator will not handle that request; it does not claim deployment. Mixed merged/open requests remain open for a scope decision. See the command guide for permissions, exit codes and recovery, and ticket rules for labels.

The command prints live progress to stderr and saves per-run logs outside this checkout, under ~/.6529-release-coordinator/logs/. It reports the exact path and preserves earlier history on explicit resume. See run logs.

The developer fixture harness still tests the merge engine against sample PRs, including deliberate failures. Test manifests cannot enter the ticket workflow or either decision journal. Public npm version 0.0.5 adds request schema 0.000002 while preserving validation of existing 0.000001 records. Frontend and backend pin that exact public version; progress records the publication and consumer merge evidence.

Sandbox services and database

The local implementation now extends the same inbox:run command with one complete sandbox ticket: temporary MySQL with fake rows, a database change when needed, a worker, an API, and a frontend output check. Steps run in dependency order; a failed prerequisite stops its dependents.

no means no release-specific database change; the application still uses a database. unknown, incomplete inspection, and a false no hold execution. Exact inputs and workflow attempts are saved. Retrying the same input verifies its existing run instead of dispatching another one.

The controller runs locally; the sample programs and temporary database run in the test backend repository's GitHub Actions job. Each run uses fake data and removes its owned database after saving the result. A sandbox ticket's staging target does not connect to the real product's staging database. The sandbox guide owns runtime pins, tests and limits. Progress distinguishes local implementation from merged code and live acceptance. The one-ticket acceptance cases have passed; PR #45 tracks source delivery, review, and CI. The real profile deliberately skips this sample harness; its selected backend units run later through the product release adapter. That adapter has offline tests but no live acceptance yet.

Test a batch of sandbox tickets

Sandbox inbox:run now finishes cheap ticket, scope, database and Git checks first, then runs normal PR checks on a compatible group's combined code using temporary PRs. Combined service checks follow. filtered scope can name one or several Issues; they become the complete candidate inbox and then use this same behavior. There is no extra full run per ticket by default. Confirmed test failures can divide the group within fixed limits; the final selected combination must itself pass. The merged implementation selects one database-changing ticket alone, after its exact temporary MySQL check passes. Staging requests stop after matching staging E2E. Production requests repeat the protected merge/check sequence on test main. See progress for local versus merged and live evidence.

Excluded tickets stay visible with a reason and next action. If A and B pass alone but fail together, use a saved priority order to select one independent candidate and defer the other. After A reaches main, B may need a correction to work with that new base. A failed group is not proof every ticket is broken. See the batch design, ticket outcomes, and sandbox acceptance.

Read-only diagnostics

From this repository, use Node.js 20+ and an authenticated, current GitHub CLI (gh). Install dependencies if needed, then run one scan:

npm ci --ignore-scripts
npm run inbox:read

For JSON without npm's script banner:

npm run --silent inbox:read -- --json

The command runs on your machine, reads GitHub, prints a report, and exits. It reads all open release-request Issues, including waiting tickets, validates their saved JSON, and checks the matching successful workflow evidence. Missing proof is reported as unverified; a listing failure is an error rather than an empty inbox. Valid means the saved record is verified, not that the PR is ready to release. See the reader guide for the exact checks, exit codes, and limits.

To also inspect current PR commits, GitHub merge/check/review evidence, and backend service dependencies:

npm run readiness:check

Use npm run --silent readiness:check -- --json for JSON. The report separates known blockers from missing evidence. It reports release history and execution merge proof as unknown: it has no verified release-outcome source and does not consume the separate merge-rehearsal reports. See readiness checks for details.

Agreed next direction

The sandbox worker now proves the sequence: find a passing batch, integrate it through protected test staging, produce locked builds and artifacts, run ordered checks, wait for matching built-output E2E, and only then repeat the protected sequence on test main for a production request. It keeps one release active through completion or explicit recovery. See the live release acceptance for the original source-level sequence. The September 15 build acceptance proves the GitHub-only build, artifact, built-output E2E, recovery and cleanup path now merged into main through PR #149. Continue using the test repositories for any follow-up sandbox work. The sandbox Coordinator now defaults to a narrow adapter for the product-shaped test workflows; the generic test workflow remains an explicit fallback. Connecting the same design to real product Actions remains a later, separately authorized stage. Product-shaped test workflow interfaces are merged through frontend test PR #92 and backend test PR #100 so that adapter behavior can be learned against fake deployments first. The mirror's protected staging/production success path now has live acceptance; the Coordinator adapter has separate success and failure/recovery acceptance. This repository still has no permission or adapter that merges or deploys the real products.

Sandbox recovery uses protected new commits undoing the failed batch and ordinary build/E2E checks when no database change is confirmed. Staging and fake-production restoration passed controlled live sandbox tests; see the production-failure acceptance. Database changes or uncertain recovery need a person. Fake-production restoration is merged through PR #172. Real-product rollback remains future work.

The v6 journal keeps active work complete, records release operations, and archives finished batch and service records in the same GitHub repository. Exact retries retain their old attempts and budgets. The lifetime record caps are removed. Sandbox migration and an exact repeat passed from merged source; see live acceptance and history storage.

Documentation map

Need	Document
What has shipped, what is local, and what comes next	Progress
Read live and saved run logs, including interruptions and cleanup	Run logging
Check changes to this repository before merging	Repository code checks
Create or submit a request with the installed CLI	CLI guide
Inspect saved requests and current readiness evidence	Local Coordinator guide
Understand the ticket workflow, labels, reasons, and migration	Inbox processing guide
Select sandbox or real, submit a request, and run its ticket workflow	Profiled inbox guide
Understand the sandbox merge, service, batch, and release test matrix	Sandbox testing guide
Review the live fake staging/E2E/production runs	Initial sequence acceptance, build and E2E acceptance
Understand the implemented one-ticket service/database checks and evidence	Service and database acceptance
Review sandbox batching, limits, and excluded-ticket handling	Batch design
Understand request fields and validation limits	Field guide, JSON Schema, example
See the implemented request and inspection path	Intake diagram
Review agreed release rules and remaining integration work	Design, process diagram
Publish or adopt an exact package version	Publishing guide
Read completed migration/review evidence	Migration history

The design and process diagram reflect the September 11 decisions, the live-tested sandbox subset, and the locally implemented but not yet live-tested real-product adapter. Implementation and acceptance evidence remain separate in progress.

Code and ownership

• packages/release-request/: the small published CLI. Product repositories install this package only. Its own README and license are part of the npm archive and must remain with it.
• apps/coordinator/: private profiled submission, read-only diagnostics, and the combined ticket workflow. These are not published with the CLI.
• .github/workflows/submit-release-request.yml: validates and saves inbox Issues.
• .github/workflows/publish-release-request.yml: checks the workspaces and publishes the CLI through the protected manual publication path.

The schema and code define current behavior. Progress is a dated evidence record. Design documents describe future work; history preserves past evidence. Product repositories retain their own authorized merge and deployment procedures. Release requests and workflow logs are public and must never contain secrets.

Check changes to this repository

After npm ci --ignore-scripts, run npm run check. It checks JavaScript, formatting, all automated tests, workflow permissions, and the packed public CLI. GitHub runs the same command on PRs into main and pushes to main. The branch also configures CodeQL for JavaScript and Actions, CodeRabbit draft reviews, and a fixed 6529bot general/security/deployment/GLM set on PRs and pushes, with a follow-up review after pushes. Bot base-branch activation, Snyk integration and external merge enforcement have separate delivery evidence in progress. CI also runs a non-fixing npm audit of the shared lockfile, including every workspace and development tools. Snyk scans the public package's manifest; its npm workspace limitation makes the separate lockfile audit necessary. The existing required Check package result requires every configured Node version to pass. See code checks for setup and boundaries and progress for local versus merged/CI evidence.

This checks Coordinator code using controlled inputs and temporary repositories; it does not process real inbox tickets. inbox:run is the separate ticket command. npm test still runs just the automated tests. Fix formatting separately with npm run format:fix, then review the diff and rerun the checks.