---
id: LSN-0037
ticket: runtime-edge-test-plan
title: Domain Gates Must Be Owned by the Repository
created: 2026-04-21
tags: [tests, coverage, ci, governance]
---

## Context

PROMETEU moved runtime-edge coverage governance away from a single workspace-wide percentage and toward canonical domain gates. That shift mattered not only for policy, but also for how CI logic is expressed and maintained.

The resulting model now treats `system/runtime`, `fs`, `asset/bank`, `firmware`, and `host-dependent` as the operational coverage authorities for runtime-edge changes.

## Key Decisions

### Domain-first coverage governance

**What:**
The authoritative CI gate is no longer a global aggregate percentage. The gate is evaluated per canonical domain, with `lines` coverage compared against the domain baseline, while scenario expectations remain the real acceptance contract.

**Why:**
A single global number can hide risk in firmware transitions, boot flow, host integration, and other sensitive edges. Domain ownership makes the gate reflect where regressions actually matter.

**Trade-offs:**
This model is more explicit and more honest, but it requires clearer mapping between code changes, domain responsibility, and test evidence.

### Repository-owned CI helpers

**What:**
Jenkins should call repository helpers such as `make ci-domains`, rather than reimplementing coverage policy inline in the pipeline file.

**Why:**
The coverage contract evolves with the repository. When CI duplicates the decision logic, policy drifts and operational changes become harder to propagate consistently.

**Trade-offs:**
The helper must remain readable and stable, because it becomes part of the repository contract rather than a local convenience script.

## Patterns and Algorithms

- Keep the policy in repository files (`Makefile`, coverage scripts, domain baseline config), and keep Jenkins as a thin caller.
- Use domain-scoped baselines as a quantitative gate, but keep mandatory scenarios as the governing behavioral rule.
- Publish operationally useful coverage output that emphasizes gate status first and only exposes deeper evidence on demand.

## Pitfalls

- Treating a global coverage increase as proof that a touched domain is adequately tested.
- Encoding gate math directly in Jenkins and forcing future policy changes to update multiple authorities.
- Letting verbose evidence output bury the actual pass/fail signal in CI logs.

## Takeaways

- Runtime-edge coverage is safer when CI enforces domain ownership instead of trusting a workspace aggregate.
- Scenario-first review and domain baselines complement each other; neither should replace the other.
- Coverage gates that live in repository helpers are easier to evolve, audit, and keep consistent than CI-local logic.