bQUARKz
5984eaaf24
All checks were successful
Intrepid/Prometeu/Runtime/pipeline/head This commit looks good
56 lines
2.7 KiB
Markdown
56 lines
2.7 KiB
Markdown
---
|
|
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.
|