Skip to content

story(adr): migration job-runner offering — self-hosted-application-platform #772

@Zaba505

Description

@Zaba505

Decision

What's the platform's one-shot migration job runner — distinct in role from long-running tenant components, supporting concurrent migrations, holding tenant data in-place on failure, tearing down per-job artifacts on issue closure, and rejecting requests whose declared peak exceeds 2× steady-state?

Technical requirements addressed

  • TR-38 — Platform must offer a one-shot job runner distinct from long-running tenant components
  • TR-40 — Migration approval must reject any request whose declared peak exceeds 2× the destination tenant's steady-state
  • TR-41 — Migration runner must support concurrent migrations across distinct tenants
  • TR-42 — Migration runner must not auto-clean, auto-retry, or auto-progress on job failure
  • TR-43 — Migration runner must deprovision job artifacts on issue closure

Parent capability

Self-Hosted Application Platform

Confirmed framing

Same compute substrate as long-running tenants — TR-38's "distinct" is a role distinction, not a substrate one. The 2× cap is enforced at both filing time (engagement-thread tooling) and runner admission gate (defense-in-depth). Failure-recovery action mechanics (wipe-and-retry, resume, accept partial, abandon) are deferred to component design — this ADR pins the action vocabulary the runner recognizes.

Authoring

This ADR will be authored via the define-adr skill — one invocation per ADR. The skill will identify research tasks, propose options tied back to the TR-NNs above, and stop for the human to make the final selection.

Related

#742

Metadata

Metadata

Assignees

No one assigned

    Labels

    documentationImprovements or additions to documentation

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions