feat: publish reviewed architecture and ADR batch
Some checks failed
Build and publish policy-nexus image / build-and-push (push) Failing after 19s

Assistant: codex
Assistant-Model: gpt-5.6-sol
Assistant-Session: 01a058f3-8ba0-7692-a042-9a870fc3d663
This commit is contained in:
tegwick 2026-08-31 21:34:23 +02:00
parent 023badb512
commit 93608c1f17
120 changed files with 17791 additions and 727 deletions

View file

@ -1,7 +1,7 @@
<!doctype html>
<html lang="en"><meta charset="utf-8">
<meta name="policy-source-revision" content="468a52af2b14eba08e05be69c4d2866bfd8d9d7d">
<meta name="policy-source-digest" content="263431f88ba04d6ab9ab3b6c0d6a2bb08634bfe83dc0719350f0855d399c18b2">
<meta name="policy-source-revision" content="5ffd7d1b40d56249f490a318e728047fd3517c4c">
<meta name="policy-source-digest" content="b1185388ded53188dc624fbda9bee517dd3ac80b35e881cd4a7962531bec52ff">
<title>Rapp Declaration Contract</title>
<style>
:root{
@ -191,7 +191,7 @@ a:focus-visible,.rail a:focus-visible{outline:2px solid var(--brass);outline-off
@media (prefers-reduced-motion:reduce){*{animation:none!important;transition:none!important}}
</style>
<div class="wrap"><header><div class="eyebrow"><span>RMASTER-ADR-0007</span> <span class="stat">accepted · accepted-1</span> <span>railiance-master</span> <span>reviewed 2026-08-13</span><span>generated from canonical source — do not edit</span></div><h1>Rapp Declaration Contract</h1><p class="sub">Source: <code>railiance-master · docs/adr/ADR-0007-rapp-declaration-contract.md · 468a52af2b14eba08e05be69c4d2866bfd8d9d7d</code></p><p class="sub">Review due: 2027-02-13</p></header><div class="layout"><nav class="rail" aria-label="Sections"><ol><li><a href="#context"><span class="n">·</span>Context</a></li><li><a href="#decision"><span class="n">·</span>Decision</a></li><li><a href="#consequences"><span class="n">·</span>Consequences</a></li></ol></nav><main><p>Date: 2026-08-13 Status: Accepted</p>
<div class="wrap"><header><div class="eyebrow"><span>RMASTER-ADR-0007</span> <span class="stat">accepted · accepted-2</span> <span>railiance-master</span> <span>reviewed 2026-08-23</span><span>generated from canonical source — do not edit</span></div><h1>Rapp Declaration Contract</h1><p class="sub">Source: <code>railiance-master · docs/adr/ADR-0007-rapp-declaration-contract.md · 5ffd7d1b40d56249f490a318e728047fd3517c4c</code></p><p class="sub">Review due: 2027-02-23</p></header><div class="layout"><nav class="rail" aria-label="Sections"><ol><li><a href="#context"><span class="n">·</span>Context</a></li><li><a href="#decision"><span class="n">·</span>Decision</a></li><li><a href="#consequences"><span class="n">·</span>Consequences</a></li></ol></nav><main><p>Date: 2026-08-13 Status: Accepted</p>
<section id="context"><h2>Context</h2>
<p><code>RMASTER-WP-0017</code> through <code>RMASTER-WP-0019</code> established the four-axis model and materialized the first family repos. The model held up. Its enforcement did not.</p>
<p>A 2026-08-11 survey by <code>railiance-platform</code> found that the three live <code>rapp.yaml</code> files were mutually unreadable: rollout, smoke, and rollback contracts used different shapes; metadata that both rails carry consistently appeared in only one rapp; <code>reef-railiance</code> <code>bound_rapps</code> listed <code>rapp-qonto</code> only, while <code>rapp-openbao</code> and <code>rapp-postgres</code> were already live on the same reef. <code>docs/repo-family-bootstrap-contract.md</code> named fields in prose and could not catch any of this.</p>
@ -203,8 +203,11 @@ a:focus-visible,.rail a:focus-visible{outline:2px solid var(--brass);outline-off
<ol><li><strong>Two cardinalities stay distinct.</strong> Repos to rapps is many-to-many: a repo may appear in the <code>composition.member_repos</code> of more than one rapp. Deployables to rapps is one-to-one: every running deployable has exactly one rapp that owns its rollout. The coverage question — <em>does every live deployable belong to exactly one rapp?</em> — is well-formed only if these stay distinct.</li></ol>
<ol><li><strong>Granularity is grouped-by-bounded-context.</strong> One rapp per cohesive group that deploys, versions, and rolls back together, not one rapp per deployable. Grouping is legitimate only where members share rollout and rollback fate. A single-repo rapp is the one-member case of the same <code>composition</code> block, not a second shape.</li></ol>
<ol><li><strong>The schema is normative.</strong> <code>schemas/rapp.schema.json</code>, <code>schemas/rail.schema.json</code>, and <code>schemas/reef.schema.json</code> define the shapes. Framework prose cites those files. It does not restate their fields. Reef <code>bound_rapps</code> is a derived projection of <code>rapp.bound_reefs</code>, not a hand-maintained registry.</li></ol>
<ol><li><strong>Coverage includes every managed running deployable.</strong> Application, operational, and tooling runtimes participate in the same exactly-one-rapp invariant when they are installed, scheduled, or otherwise operated as a managed deployable. This includes a managed one-shot Job; it does not turn a human command or approval act into a workload. Human access, credential patterns, broker actions, one-off operational acts, and infrastructure resources that are not workloads retain their native actor, lane, activity, or resource identity.</li></ol>
<p>A running deployable that predates rapp extraction is migration debt. Until an authoritative declaration claims it, workload-based controls report it as <code>unknown</code>; they do not infer a rapp from its repository, namespace, path, labels, or apparent owner. A subject explicitly established as not being a workload is <code>not-applicable</code>. <code>unknown</code> and <code>not-applicable</code> are different outcomes and omission must not collapse them.</p>
<p>Railiance Master remains the sole owner of the normative rapp vocabulary and schemas. Consumer catalogs may store explicit references and integration owners may resolve them, but neither creates a parallel declaration surface or copies rapp metadata as another source of truth.</p>
<p>The detailed shapes, including the single normative form of the rollout, smoke, and rollback contracts, live in the schema files and <code>schemas/README.md</code>.</p>
</section>
<section id="consequences"><h2>Consequences</h2>
<ul><li>Drift across family declarations fails in <code>tools/validate-family-declarations.py</code> instead of accumulating in prose.</li><li><code>railiance-platform</code> <code>RAILIANCE-WP-0015-T02</code> can converge <code>rapp-openbao</code> and <code>rapp-postgres</code> onto one shape. Migration belongs to the owning repos; this ADR does not move any declaration.</li><li><code>reef-railiance</code> must stop treating <code>bound_rapps: [rapp-qonto]</code> as source of truth. The list is already stale.</li><li>Three further <code>rapp-*</code> repos (<code>rapp-secrets-engine</code>, <code>rapp-tenant-engine</code>, <code>rapp-user-engine</code>) carry the family prefix and no declaration. They are visible to the validator as undeclared and must be declared, renamed, or retired by their owners.</li><li>Calling the validator from <code>fix-consistency</code> still waits on <code>the-custodian</code> admitting the family prefixes into the classification standard. That sequencing is not this repo's.</li></ul>
</section><footer><span>RMASTER-ADR-0007 · accepted-1 · accepted</span><span>railiance-master · docs/adr/ADR-0007-rapp-declaration-contract.md · 468a52af2b14eba08e05be69c4d2866bfd8d9d7d</span></footer></main></div></div></html>
<ul><li>Drift across family declarations fails in <code>tools/validate-family-declarations.py</code> instead of accumulating in prose.</li><li><code>railiance-platform</code> <code>RAILIANCE-WP-0015-T02</code> can converge <code>rapp-openbao</code> and <code>rapp-postgres</code> onto one shape. Migration belongs to the owning repos; this ADR does not move any declaration.</li><li><code>reef-railiance</code> must stop treating <code>bound_rapps: [rapp-qonto]</code> as source of truth. The list is already stale.</li><li>Three further <code>rapp-*</code> repos (<code>rapp-secrets-engine</code>, <code>rapp-tenant-engine</code>, <code>rapp-user-engine</code>) carry the family prefix and no declaration. They are visible to the validator as undeclared and must be declared, renamed, or retired by their owners.</li><li>Operational and tooling deployables are not exempt from family coverage. Existing pre-rapp runtimes may continue during migration, but their workload identity remains visibly <code>unknown</code> to controls until declared.</li><li>Runtime inventory is still required to prove universal coverage. Repository discovery alone cannot establish that every running unit has exactly one authoritative rapp.</li><li>Calling the validator from <code>fix-consistency</code> still waits on <code>the-custodian</code> admitting the family prefixes into the classification standard. That sequencing is not this repo's.</li></ul>
</section><footer><span>RMASTER-ADR-0007 · accepted-2 · accepted</span><span>railiance-master · docs/adr/ADR-0007-rapp-declaration-contract.md · 5ffd7d1b40d56249f490a318e728047fd3517c4c</span></footer></main></div></div></html>