1.9 KiB
1.9 KiB
Why
The current server workflow uses one RunEndpoint both as a pre-existing worker that builds and installs software and as the server-scoped Run binary generated after creation. This creates a bootstrap loop, permits multiple servers to share one endpoint despite the intended one-server/one-Run model, and leaves component registration insufficiently bound to its server.
What Changes
- Add a server-scoped Run binding with an explicit lifecycle from draft, through target selection and Run registration, to deployment.
- BREAKING Separate a deployment target from the dedicated Run endpoint that controls one server; a selected target no longer immediately dispatches installation.
- Require a generated Run to register with the endpoint identity reserved for its server before deployment or runtime jobs can be dispatched.
- Reject endpoint reuse, mismatched component registration, and cross-server job access; revoke only the Run bound to the affected server.
- Update the server creation workflow to save a draft, describe the selected target accurately, and guide the operator through Run generation, registration, and deployment.
Capabilities
New Capabilities
server-scoped-run-binding: Securely reserve, register, validate, replace, and revoke one dedicated Run endpoint for a server instance.server-run-bootstrap-workflow: Create a server as a draft and progress it through deployment-target selection, dedicated Run registration, and explicit deployment.
Modified Capabilities
- None.
Impact
platform/: domain, DTOs, models/repositories, services, control registration, lifecycle dispatch, distribution build selection, validation, API documentation, and tests.platform_web/: API types, server creation/deployment workflow, Run builder status and focused tests.run/: independent repository coordination is required for the revised registration identity; this repository will only update its public contract.