Content Registry
| Key | Value |
|---|---|
| Status | Active |
| Owner | QA Automation |
| Updated | 2026-03-26 |
| Scope | Registry model for content coverage across CNC sites |
The content registry is the source of truth for what the content test system is supposed to know about CNC editorial modules. It exists so coverage can be deliberate instead of accidental.
Why The Registry Exists
Before the registry, content checks were scattered and hard to reason about. The registry changed that.
| Registry Benefit | Why It Matters |
|---|---|
| shared source of truth | everyone can see what is covered and what is missing |
| site-aware structure | one content type can behave differently across sites |
| test-depth metadata | not everything needs the same level of validation |
| easier maintenance | new modules can be added without inventing a new mini-system each time |
Current Scope
| Metric | Current Snapshot |
|---|---|
| registry entries | 120 |
| site slots | 231 |
| covered sites | 6 |
| average existence pass rate | about 85% |
| Blesk existence pass rate | 100% |
What One Registry Entry Represents
Each entry describes a content type or module the system cares about.
| Registry Attribute | Typical Meaning |
|---|---|
| category | broad module family |
| site coverage | where the module exists |
| selectors or detection rules | how the system identifies it |
| seed URLs | stable places to find it when homepage content rotates |
| test depth | existence, interaction, or journey |
Why Site Slots Matter
One entry is not the same thing as one working implementation. A module may exist on one site, be absent on another, or need a different selector path somewhere else. That is why site-slot accounting matters more than a simple module count.
Seed URLs
Seed URLs are a practical answer to a live-site reality: the homepage is not stable enough to guarantee that every interesting module appears when the suite runs.
| Why Seed URLs Are Used | Example Outcome |
|---|---|
| editorial rotation | module is still testable even when not on the homepage |
| site-specific depth | one site may need article-level coverage while another does not |
| targeted confidence | known QA pages make the suite less random |
Dedicated Test Articles
Dedicated QA-friendly articles are especially valuable for rare or fragile embeds. They give the suite somewhere stable to look when live editorial rotation would otherwise make coverage unreliable.
How The Registry Is Used
| Consumer | How It Uses The Registry |
|---|---|
| content tests | chooses what to validate and how deeply |
| coverage tools | show gaps and distribution |
| operators | understand what “content coverage” means in practice |
| future documentation | keeps module coverage explainable |
What The Registry Is Not
- it is not a CMS inventory of everything editors could possibly create
- it is not a pixel-perfect frontend spec
- it is not a replacement for broader user-journey tests
It is a QA coverage map for the content surfaces that matter most.
[EXPAND: When to update the registry]
Update the registry when:
- a new reusable content module appears
- a module moves to a different selector structure
- a seed URL becomes unreliable
- a test article is created or retired
- the desired test depth changes from existence to interaction or journey
[END EXPAND]
Related Pages
| Need | Go To |
|---|---|
| how the suite runs against the registry | Content Tests |
| main suite overview | Test Types |