---
id: RMASTER-WP-0025
type: workplan
title: "Universal rapp workload coverage"
domain: financials
repo: railiance-master
status: finished
owner: codex
topic_slug: universal-rapp-workload-coverage
created: "2026-08-23"
updated: "2026-08-23"
state_hub_workstream_id: "09d6dfc6-0bde-5516-acaa-a6a4f0551805"
---

# RMASTER-WP-0025 - Universal rapp workload coverage

## Goal

Make the normative rapp contract explicit that every managed running
deployable belongs to exactly one rapp, including operational and tooling
workloads that participate in controls, without inventing workload identity for
subjects that are not workloads.

## Source and disposition

Repo Manager published owner interface
`helixforge.workloads.rapp-coverage.v1` for `RMGR-WP-0010-T05` at source
revision `890f3b05b596047a31605c544c56ed8a4f011868`. Railiance Master approves
that interface as supplied. The interface preserves this repository as the
sole owner of the normative rapp vocabulary and schema; Repo Manager remains
the integration, indexing, and reference-resolution owner.

## Boundaries

- Do not create a parallel generic workload declaration surface.
- Do not require one rapp per process where deployables share rollout and
  rollback fate.
- Do not turn human access, credential patterns, broker actions, operational
  approvals, or infrastructure resources into fake workloads.
- Distinguish a managed one-shot deployable from a one-off operational action:
  the former needs rapp coverage; the latter retains its native activity or
  actor identity.
- Do not infer missing workload ownership from a repository name, namespace,
  path, label, or other convention.

## T01 - Review and accept the owner interface

```task
id: RMASTER-WP-0025-T01
status: done
priority: high
state_hub_task_id: "7167e948-0b01-5d1d-971a-89714dc657f0"
```

Validate Repo Manager's interface bundle for owner `railiance-master`, inspect
the source ADR and current Railiance Master contract, and record the exact
source revision and disposition.

Done when the file-backed workplan records `approved`, `amended`, or `rejected`
without reconstructing a duplicate Repo Manager task.

Completed 2026-08-23. The interface validates cleanly and is approved without
amendment. Its objective already follows ADR-0007's distinct repo-to-rapp and
deployable-to-rapp cardinalities; the required change is a boundary
clarification, not a schema fork.

## T02 - Clarify the normative coverage boundary

```task
id: RMASTER-WP-0025-T02
status: done
priority: high
state_hub_task_id: "d07628fe-b83f-5a18-9dce-8f9149a4fa1a"
```

Clarify ADR-0007 and the rapp authoring guide so they answer all of the
following directly:

- operational and tooling deployables require rapp coverage;
- every managed running deployable resolves to exactly one rapp;
- an uncovered pre-rapp deployable is migration debt and remains `unknown` to
  workload controls until declared;
- non-workload operational subjects are `not-applicable` and retain native
  identity;
- schema vocabulary remains authoritative only in Railiance Master.

Done when the coverage, migration-debt, and not-applicable states are distinct
without changing the declaration shape.

Completed 2026-08-23. ADR-0007 revision `accepted-2` and `schemas/README.md`
now define universal managed-deployable coverage, explicitly distinguish a
managed one-shot Job from an operational act, and preserve `resolved`,
`unknown`, and `not-applicable` as separate outcomes. The declaration schema
shape is unchanged.

## T03 - Verify compatibility and hand the ruling back

```task
id: RMASTER-WP-0025-T03
status: done
priority: high
state_hub_task_id: "730603d0-1acd-526d-a9a3-a1a1adb40021"
```

Run the family validator self-test and the interface's two named declaration
checks. Notify Repo Manager with the workplan/task identifiers, exact source
revision, disposition, and verification result.

Done when existing valid rapp declarations still validate and
`RMGR-WP-0010-T05` can consume the authoritative ruling without copying the
vocabulary.

Completed 2026-08-23. Repo Manager's owner-interface validator reports one
matching interface and zero errors. The family validator self-test passes, and
both named repository checks (`rapp-issue-core` and `rapp-qonto`) report 14
declarations, zero errors, and the same informational derived-reef warning.
The completion handoff is sent after the file-backed result is committed.

## Outcome

The owner interface is approved and implemented. Operational and tooling
deployables have no exemption from the exactly-one-rapp invariant;
non-workload subjects retain native identity; uncovered managed deployables
remain visible migration debt rather than receiving inferred identity.