Remaining quality debt after the #180 sweep: E2E red, gate-19 (491), gate-25 (10), gate-26 (4)

[rubenvdlinde]

Tracking the three quality signals on hermiq that PR #180 deliberately did not touch, so the numbers are on record and nobody re-measures them from scratch.

Honest full-scope baseline: development @ cd23f547, workflow_dispatch --full, run 31490144919.

⚠️ The push-scope figure of "16 gates / ~1,184 findings" is not comparable to a full-scope one. gate-16 (spec-coverage, 473) and gate-52 (custom-widget-ratchet) are diff-scoped and drop out of a whole-repo run by design; gate-29/33/47/48/61 report NOT APPLICABLE. The full-scope figure is 14 gates / 743 findings.

1. E2E (Playwright) — red, job 93775011235

Scoped to tests/e2e/spec-coverage by .github/workflows/code-quality.yml, and that scoping is stated in the workflow rather than assumed. Not investigated in #180. Before concluding it is a test bug, check the known shape first: an admin root that mounts every section on one storesReady flag produces a DOM large enough that Playwright's role queries never terminate while the page itself loads in ~3.5s (procest#784). Also note waitForLoadState('networkidle') hides the race it appears to fix, and mode: 'serial' masks failures — a suite reporting "N did not run" is not telling you it is healthy.

2. gate-19 e2e-coverage — 491 scenarios missing @e2e

This number is directional, not exact. Four known gate defects:

• .github#343 — a file-level @e2e tag is credited without checking the test body, so a file can be credited for scenarios nothing in it exercises;
• .github#345 — an @e2e exclude is read as positive coverage, so excluding and covering are indistinguishable to the gate;
• a dangling @e2e anchor fails silently;
• .github#209 (fixed) — gate-19 used to return its finding count as an exit status, so any figure quoted in an older issue is wrong.

Real work, but it is the long tail: 491 scenarios is a programme, not a sweep.

3. gate-25 (10) and gate-26 (4)

• gate-25 contract-coverage — 10 new public endpoints with no contract test.
• gate-26 visual-coverage — 4 new page components with no visual baseline. ⚠️ This gate can be satisfied by a bare PascalCase token in a comment — it looks for the component name anywhere in the corpus. Create real baselines and verify each one actually captures the component; making the token appear turns it green with no baseline existing.

Where hermiq stands after #180

PHPUnit (all cells), phpstan, psalm green; gate-7/13/24/30/40/51/54 closed at source; gate-46 201 → 25 (#183); gate-17 (#182) and gate-57 (#181) filed as false-positive / product decisions rather than fake-fixed. Remaining: this issue.

[rubenvdlinde]

The E2E failure, pinned down — it is ONE test, and it is not flaky

Measured on both sides, byte-identical counts:

run	job	result
31490144919 (development, before the sweep)	93775011235	1 failed / 3 skipped / 33 passed (4.2m)
31497253661 (PR #180)	93799056905	1 failed / 3 skipped / 33 passed (4.1m)

Same test both times, including the retry:

✘ 10 tests/e2e/spec-coverage/hydra-console-agent-leaves.spec.ts:197:6
     › the triage flow is seeded once, declares its trigger, and contains only permitted step types
✘ 11 … (retry #1)

So the suite is 32 of 33 green with one deterministic failure — the E2E job is not a wall of noise, and PR #180 did not change it in either direction.

The assertion

Error: node "finding" has an unexpected type "undefined"
expect(received).toContain(expected)
  Expected value: undefined
  Received array: ["hermiq.agent-step", "openregister.route", "openregister.end", "openregister.stop"]

from

for (const node of nodes) {
  expect(permitted, `node "${String(node.id)}" has an unexpected type "${String(node.type)}"`)
    .toContain(node.type)
}

The seeded triage flow contains a node with id: "finding" and no type at all. "finding" is also the value of flow.triggerSchema, asserted three lines earlier — so the likely reading is that the trigger is being carried in flow.nodes in a shape that has no type, and the permitted-step-types inventory is walking over it.

⚠️ Do not "fix" this by skipping typeless nodes. That is the assertion doing its job: the block exists to prove no step type outside the permitted list ever appears, and it already carries a comment about a previous version of itself that could not pass after the ADR-065 node/edge inversion. Filtering the offending node out would be the second time this test was quietly narrowed until it went green.

The two adjacent tests in the same file carry 🔴 FIXME(hermiq#140) — same missing seed, so this is plausibly the same seed defect rather than a test bug — but I did not open the live seeded flow document to confirm that, so treat it as the hypothesis it is. The next step is to read the seeded hydra triage flow's nodes array on a live instance and see what the finding entry actually is; judging it from the assertion alone is how the wrong bug gets fixed.

[rubenvdlinde]

The E2E failure is NOT a test bug — and the hypothesis in this issue was only half right. I opened the artefact.

The earlier note here offered, explicitly as unverified, that "the seeded triage
flow carries a node with id: "finding" and no type". I have now opened
lib/Repair/SeedHydraTriageFlow.php, the engine it is authored against, and the
release state of that engine. The symptom is confirmed and the diagnosis is wrong
in the way that matters: it is not one anomalous node. Every node in the seeded
flow is typeless, by deliberate design, and the seed's own comments assert the
opposite of the engine's current contract as fact.

What the run actually says

hydra-console-agent-leaves.spec.ts:197, run 31502914249, job 93818270613 —
identical on the retry, and identical before and after PR #180:

Error: node "finding" has an unexpected type "undefined"
Expected value: undefined
Received array: ["hermiq.agent-step", "openregister.route", "openregister.end", "openregister.stop"]

finding is simply the first node iterated. There are five, and none has a type.

What the seed authors — lib/Repair/SeedHydraTriageFlow.php

private function nodes(): array {
    return [
        ['id' => 'finding',   'position' => [...]],
        ['id' => 'triaged',   'position' => [...]],
        ['id' => 'command',   'position' => [...]],
        ['id' => 'no-result', 'position' => [...]],
        ['id' => 'done',      'position' => [...]],
    ];
}

Every type/config lives on edges[] — triage (hermiq.agent-step), gate
(openregister.route), command-stop and no-result-stop (openregister.stop).
The seed states the model in prose, twice:

notes: "Note the work lives on the edges — a type on a node is never read by the engine."
edges() docblock: "🔑 In OpenRegister's engine the executable unit is the EDGE. … A node is a Petri-net PLACE and carries no behaviour."

What the engine says — OpenRegister lib/Service/Flow/FlowDefinitionBuilder.php

Both halves, quoted, and they are exactly inverted from the seed:

• refuseLegacyShape() — "a document is pre-inversion iff any EDGE carries a
  non-empty type" → InvalidArgumentException: "Flow edge "%s" carries "type",
  which the engine no longer reads — an edge is sequence and a NODE is the action.
  This flow is in the pre-inversion shape and has not been migrated."
• extractNodes() — "Flow node "%s" declares no "type". A node is the action that
  runs, so a node without a type is a step that does nothing while reporting success."

So the seeded flow fails both guards. It cannot be lowered to a Definition at
all. It ships disabled (an owner must be supplied by hand), which is why nobody hit
it at runtime.

How it got here — a 4-day window, both sides moving

date	event
2026-07-24	f3be6ae9e OpenRegister flow engine on symfony/workflow lands
2026-07-31	24d7ad683 OR refuses a node that carries step config
2026-07-31	hermiq's seed converted node-form → edge-form to match. Its docblock records the measurement: node-form "imported cleanly, walked all three edges and reported completed having called no agent". That fix was correct on the day.
2026-08-04	8a7d05440 OR inverts: "a node is the action, an edge is sequence, and a token has one exit" (or-flow-action-nodes, ADR-065)
—	hermiq's seed was never migrated.

The e2e spec was updated for the inversion — its own comment says the old
assertion "could not pass, and had not since the migration". So the one artefact in
this repo telling the truth is the red test, and it has been red ever since.

🔴 A green PHPUnit suite asserts the shape the engine refuses

tests/Unit/Repair/SeedHydraTriageFlowTest.php::testNoNodeCarriesExecutableConfig():

$this->assertArrayNotHasKey('type', $node, "Node '{$node['id']}' carries a type the engine never reads.");

It asserts a node must not have a type. The engine throws when a node has
no type. That test is green precisely while the flow is unrunnable, and its
header carries the warning ⚠️ EVERY ASSERTION HERE USED TO READ nodes[], AND THAT IS WHY THEY ALL PASSED — written about the previous inversion. Same trap, other
side. Same family as a test that asserted the inverse of its own name.

🔴 Why this must NOT be hand-fixed here, today

The engine this depends on is unreleased, and hermiq's CI pins the moving branch.
Measured, with a positive control that the refs are real trees:

openregister ref	tree size	lib/Service/Flow/ files	FlowDefinitionBuilder.php
origin/main	3463	0	absent
origin/beta	3454	0	absent
origin/development	6810	59	present, post-inversion

code-quality.yml:142 installs
{"repo":"ConductionNL/openregister","app":"openregister","ref":"development"}.

So migrating the seed to node-form now would make hermiq's e2e green and break
the seed for every install running OpenRegister beta or main — where the flow
engine does not exist yet and, when it arrives, arrives at whichever shape is
current then. Making a red test green by pinning one app to another app's unreleased
development is not a fix; it is a coupling.

The migration, when it is sequenced

It is the graph dual, and OpenRegister already ships the tested transformation as
or-flow-migrate-definitions (old edge → new node; old place → new edge titled for
the place). For this seed it is:

nodes: triage(hermiq.agent-step) · gate(openregister.route) ·
       command-stop(openregister.stop) · no-result-stop(openregister.stop)
edges: triage → gate            (title "triaged")
       gate  → command-stop     (title "command",   via the gate's `command` exit)
       gate  → no-result-stop   (title "no-result", via the gate's `no-result` exit)
initial: triage   (the old `finding` place had no inbound edge)

⚠️ The router does not transfer mechanically: post-inversion a branching node
declares exits[] with an optional JSONLogic condition, edges bind to them via
fromExit, and FlowDefinitionBuilder::assertExitsCanAlwaysBeTaken() refuses a
branching node without an unconditioned else. That is a behaviour change, and it
needs to be executed, not shape-checked — the e2e assertion here only inspects the
document, so satisfying it proves nothing about whether the flow runs.

Also corrected, from the same reading

The e2e comment cites FlowDefinitionBuilder::assertNotPreInversion(). No such
method exists in OpenRegister (positive control: the class is there, 9 methods,
none by that name). The real one is refuseLegacyShape(). Harmless, but it is the
kind of citation that gets trusted.

Proposed disposition

1. Leave the e2e test exactly as it is. It is correct and it is the only thing
   in this repo that noticed.
2. Sequence the seed migration with the OR flow-engine release (ADR-065 parity
   programme) — not as a hermiq quality sweep.
3. When it lands, rewrite SeedHydraTriageFlowTest in the same commit: it currently
   pins the wrong side and would have to go red for the fix to be right.
4. Verify by executing the migrated flow, not by re-reading its shape.

Nothing about this was changed in #180 or since; the E2E cell is byte-identical
before and after (1 failed / 3 skipped / 33 passed, same test, same retry).

[rubenvdlinde]

gate-26 on hermiq: the remedy this issue recommends is UNREACHABLE here, and 3 of the 4 findings are probably false

Measured on development @ 468f5f13 against the canonical package
ConductionNL/.github@main (81c8c97), base origin/beta.

The four findings:

src/views/AgentMemory.vue              — new page component missing visual baseline
src/views/FlowBuilder.vue              — new page component missing visual baseline
src/views/GuardrailPolicySettings.vue  — new page component missing visual baseline
src/views/McpTools.vue                 — new page component missing visual baseline

1. tests/e2e/visual/** would be a pure dodge on this repo

check_visual_coverage.py offers three remedies, the preferred one being a
baseline or spec under tests/e2e/visual/**. On hermiq:

• tests/e2e/visual/ does not exist;
• no toHaveScreenshot / toMatchSnapshot exists anywhere under tests/e2e/;
• and code-quality.yml:163 sets playwright-test-path: "tests/e2e/spec-coverage".

So anything dropped in tests/e2e/visual/ would never be executed by CI and
would turn the gate green while proving nothing. This is the doriath finding
(tests/e2e/visual/ is never executed by CI — baselines there are a dodge)
reproduced here for a different reason: doriath's config carried
testIgnore: ['**/visual/**']; hermiq's CI simply never points at the directory.

2. The reachable remedy is grep-based, and hermiq's e2e suite is DATA-DRIVEN

The fallback remedy is "any e2e test references the component file or its
stem/id" — a literal text search over the e2e corpus. Measured:

component	literal hits in tests/e2e/spec-coverage/	literal hits in all of tests/e2e/
AgentMemory	0	0
FlowBuilder	0	0
GuardrailPolicySettings	0	0
McpTools	0	0

But manifest-pages.spec.ts generates its cases from src/manifest.json at
run time, so the names exist only in the generated test titles. Three of the
four are demonstrably mounted and asserted in CI — from the passing list of run
31502914249:

✓ [custom] AgentMemory mounts at /memory
✓ [custom] McpTools mounts at /mcp-tools
✓ [custom] GuardrailPolicy mounts at /guardrail-policy   (component: GuardrailPolicySettings)

Those three are covered by a CI-executed test and reported as uncovered
purely because the gate greps for a literal the data-driven test never contains.
FlowBuilder.vue looks genuinely uncovered — the manifest mounts FlowIndex at
/flows; FlowBuilder is the canvas behind flow-detail, and no
spec-coverage test reaches it.

🔴 Do not close the three by making the token appear. .github#358 already
established that gate-26 is satisfied by a bare PascalCase token in a comment
— so writing // covers AgentMemory into a spec file would turn this green with
no additional assertion whatsoever. That is the failure mode, not the fix.

Proposed disposition

• Do not create tests/e2e/visual/. On this repo it is unreachable by CI.
• FlowBuilder is the one real finding: it wants a spec-coverage test that
  opens a flow's canvas and asserts something about it.
• The other three want a gate change, not an app change: check_visual_coverage.py
  cannot see coverage produced by a test that derives its targets from a manifest
  at run time, and hermiq's manifest-pages.spec.ts is exactly that shape. Worth
  raising on ConductionNL/.github — any app with a manifest-driven page suite
  hits it, and the "fix" the gate's own message suggests is a comment.

Related, same measurement pass

gate-25 contract-coverage (8) names its endpoints, and two of them resolve to a
URL while six read url=?:

guardrailPolicy#effective     url=/api/guardrail-policies/effective
tenantModelPolicy#effective   url=/api/model-policy/effective
agentTemplate#exportPackage   url=?      memory#consolidate  url=?
memory#recall                 url=?      memory#userProfiles url=?
skill#install                 url=?      skill#uninstall     url=?

Those are real Newman contract tests to write, and unlike gate-26 they have no
false-positive shape that I could find. Left for the next pass.

⚠️ Also correcting two numbers in the issue body, which came from a different
base. On development @ 468f5f13 with base origin/beta: gate-19 is 461
(not 491) and gate-25 is 8 (not 10). Name the base beside every gate number.

[rubenvdlinde]

Decision on the E2E red: do not migrate the seed. Leave the test red.

Asked to decide deliberately and say why, so here is the reasoning and the evidence it rests on, rather than a verdict.

What the red actually is

hydra-console-agent-leaves.spec.ts:197. The cause is established and is not a test bug and not a seed typo:

OpenRegister inverted the flow contract on 2026-08-04 (8a7d05440, ADR-065): a node is the action, an edge is sequence. FlowDefinitionBuilder now fails hermiq's seeded triage flow on both guards — refuseLegacyShape() throws on any edge carrying a non-empty type, and extractNodes() throws on any node without one. lib/Repair/SeedHydraTriageFlow.php puts every type/config on edges[] and states that model in prose twice. The document cannot be lowered to a Definition at all.

It ships disabled (an owner must be supplied by hand), which is why nobody hit it at runtime.

Why fixing it would be worse than leaving it

The flow engine exists only on openregister development.

openregister ref	tree size	files under lib/Service/Flow/
origin/main	3463	0
origin/beta	3454	0
origin/development	6810	59

Positive-controlled: both zero rows come from real ~3,400-file trees, so this is a measurement and not a bad checkout.

hermiq's CI pins the moving branch — code-quality.yml:142 → ref: development. So migrating the seed to the post-inversion shape would:

1. turn the cell green against an unreleased branch, and
2. break the seed on every install running beta or main, where FlowDefinitionBuilder does not exist at all.

We would be trading a red test that is telling the truth for a green test that is conditional on a branch no install runs. The red is currently the only artefact in the repo that is honest about this, and deleting that signal to satisfy a cell is the exact move the no-weakening rule exists to prevent.

🔴 And a green test is asserting the shape the engine refuses

tests/Unit/Repair/SeedHydraTriageFlowTest::testNoNodeCarriesExecutableConfig() asserts a node must not carry a type. The engine throws when a node has none. The suite is green precisely while the flow is unrunnable. Its own header warns ⚠️ EVERY ASSERTION HERE USED TO READ nodes[], AND THAT IS WHY THEY ALL PASSED — written about the previous inversion. Same trap, other side.

That test must be migrated in the same change as the seed, never before, or it will pin the obsolete contract for a second time.

The condition for reversing this decision

Not "when we get round to it" — a checkable fact:

git ls-tree -r origin/beta --name-only | grep -c '^lib/Service/Flow/' on ConductionNL/openregister returns non-zero.

When the flow engine ships to beta, migrate seed + unit suite + e2e together, in one change. Until then this stays red and stays tracked here. Sequenced onto the ADR-065 parity programme.

⚠️ Correction to the e2e spec's own comment while we are here: it cites FlowDefinitionBuilder::assertNotPreInversion(). No such method exists — positive control: the class is present with 9 methods, none by that name. The real one is refuseLegacyShape().

🔑 Generalisable: when two apps disagree about a document shape, the release state of the consumer decides who is wrong. Check whether the contract you are conforming to has actually shipped before conforming to it.

---

Gate table — re-measured, and one number moved

Canonical gate package ConductionNL/.github @ 57bcb2b (freshly cloned; not the adjacent .github checkout, which SHARED-LESSONS records as stale and producing different numbers). Both columns are the same scope, --scope-to-diff --base origin/beta, so they are comparable:

gate	development @ 40064e77	PR #188	note
gate-16 spec-coverage	480	480	unchanged — every new method in #188 carries a resolving @spec
gate-17 redundant-controller	3	3	#182 — all three have callers
gate-19 e2e-coverage	461	461	this issue
gate-25 contract-coverage	8	3	↓5 — #188's endpoint tests are contract tests
gate-26 visual-coverage	4	4	3 of the 4 are false, see below
gate-46 spec-anchor-existence	25	25	#183 — do not author the missing requirements
gate-52 custom-widget-ratchet	1	1	diff-scoped
gate-57 orphaned-write-capability	2	2	#181 — both are product decisions
gate-7 no-admin-idor	PASS	PASS	🔴 see below

⚠️ Scope matters and the two are not interchangeable. The same tree run whole-repo (--base origin/beta, no --scope-to-diff) gives gate-25 3 on both trees and gate-46 26, and gate-16 correctly reports NOT APPLICABLE — full-repo run computed NO diff … This is NOT a pass. That wording is .github#364 landed and working; it is the fix for the class of PASS-over-nothing that made every earlier full-scope table overstate its coverage.

⚠️ gate-22 / gate-53 read ajv is not resolvable in a bare worktree (node_modules absent). Both are green in CI. Not findings; do not carry them into a debt total.

🔴 gate-7 printed PASS on this repo before AND after 13 live IDORs were closed

The only thing that changed between those two PASSes is that thirteen endpoints that answered an attacker HTTP 200 now answer 404 (#187, #188 — reproduced live with two accounts, status codes printed both ways).

That is .github#365 demonstrated as cleanly as it can be: the checker accepts Http::STATUS_UNAUTHORIZED / 401 as an authorisation guard, and 28 of hermiq's 43 controller files carry that preamble. A gate whose reading is identical over a vulnerable tree and a fixed one is not measuring the property it is named for.

⚠️ Do not conflate this with hermiq's earlier gate-7 story. Those 3 findings were false positives from verb-object naming (canUserAccessAgent()), fixed at source in .github#353. These 13 are the opposite failure mode — a false negative — and none of them is the #353 class: a false positive cannot return 200 to an attacker.

gate-26: 3 of the 4 findings are false

manifest-pages.spec.ts generates its cases from src/manifest.json at run time, so the gate's fallback grep finds zero literal hits for components that are mounted and asserted in CI:

component	literal hits in tests/e2e/**	mounted + asserted in CI?
AgentMemory	0	✅ ✓ [custom] AgentMemory mounts at /memory
McpTools	0	✅ ✓ [custom] McpTools mounts at /mcp-tools
GuardrailPolicySettings	0	✅ ✓ [custom] GuardrailPolicy mounts at /guardrail-policy
FlowBuilder	0	❌ genuinely uncovered

Both of the gate's documented remedies are dodges on this repo: tests/e2e/visual/ never executes (code-quality.yml:163 scopes Playwright to tests/e2e/spec-coverage), and per .github#358 the grep is satisfied by a bare PascalCase token in a comment. Filed as a comment on .github#362; nothing was changed on hermiq to make it green.

[rubenvdlinde]

Re-verified the three load-bearing facts myself rather than inheriting them (a memory is a claim with an expiry date):

• git ls-tree -r <ref> --name-only on ConductionNL/openregister, fetched now: origin/main 3463 files / 0 under lib/Service/Flow/; origin/beta 3454 / 0; origin/development 6812 / 59. (Development was quoted as 6810 above — it advanced 2 files while this was written. The load-bearing numbers, the two zeros, are unchanged.)
• FlowDefinitionBuilder @ origin/development: refuseLegacyShape() at :176 and extractNodes() at :211 both exist; assertNotPreInversion() does not — the e2e comment naming it is wrong.
• SeedHydraTriageFlowTest runs 14 tests, 56 assertions, all green today, and testNoNodeCarriesExecutableConfig():209-211 asserts assertArrayNotHasKey('type', $node) — i.e. it is green because it encodes the pre-inversion contract that extractNodes() now throws on. The false-green is real and must be migrated in the same change as the seed, never before.

[rubenvdlinde]

The E2E half is closed (#189), and the reason it was deferred was wrong

This issue records that migrating the seeded triage flow to node-form
"goes green against an unreleased branch and breaks every install on beta/main",
and sequences the work behind the ADR-065 parity programme on that basis.

That premise is measured false.

SeedHydraTriageFlow::run() opens with:

try { $mapper = $this->container->get(FlowMapper::class); }
catch (Throwable $e) { $output->warning('OpenRegister not available — skipping...'); return; }

and OpenRegister ships none of its 91 flow classes on either ref:

ref	files under lib/**Flow*
origin/main	0
origin/beta	0
origin/development	91

OCA\OpenRegister\Db\FlowMapper does not exist on beta or main, so on exactly the
installs the concern named, the seed resolves nothing, returns early, and writes no flow
at all. The node-vs-edge shape of a document that is never written cannot break anything.

The original observation — that the engine exists only on development — was correct and
well-evidenced. The step that was missed is one further on: does my code path even execute
where the consumer is absent? The app had already answered that, with a lazy-resolution
guard written for precisely this reason.

What shipped

Rebuilt with OpenRegister's own documented graph dual rather than by hand, and verified by
driving the real FlowDefinitionBuilder over the document the seed emits, three arms:

NEW (node-form, migrated)     BUILT   places=6 transitions=4 initial=[triage]
CTRL-A edge carries a type    REFUSED refuseLegacyShape()
CTRL-B node missing its type  REFUSED extractNodes()      <- the shape that shipped

E2E went from 1 failed / 33 passed to 34 passed.

One trap worth recording for anyone else migrating a flow: the dual does not fix the
router. rules[].output / default named the old place ids, and post-inversion an output
must name the target node — otherwise it matches no place and every routed item is
silently dropped. See ConductionNL/hydra#534, where 13 routers across 8 flows have exactly
that, including the live sequencer.

Still open under this issue

gate-19 (461) · gate-25 (3) · gate-26 (4, of which 3 are measured false positives). The
gate-19 number is now decomposed with measurements in #176 — it is a wiring fault worth
58 scenarios, not 461 missing tests.

[rubenvdlinde]

Re-measured on development @ ce6e1e5, 2026-08-13, ConductionNL/.github@923f57d, full scope. Two of the three numbers in this title have moved, and the reason is not in this repo.

⚠️ .github#378 made whole-tree scope the default at 2026-08-12 13:14Z, and gate-package 946326d landed at 21:53Z. No run before those is comparable to one after. Quote the package SHA beside any gate count.

gate	this issue	today
19 e2e-coverage	491	491
25 contract-coverage	10	5
26 visual-coverage	4	6

Current CI: run 31645324155 (push), COVERAGE: 60 of 65 declared gates reported a result (5 not applicable; 60 of 60 applicable gates ran). Every non-gate quality cell is green on both events — the only red anywhere is Hydra Gates and its aggregator.

gate-25 — the exact five, and why two of them are category-wrong

agentTemplate#exportPackage        url=?
dashboard#catchAll                 url=?
dashboard#page                     url=/
guardrailPolicy#effective          url=/api/guardrail-policies/effective
tenantModelPolicy#effective        url=/api/model-policy/effective

dashboard#page and dashboard#catchAll are not APIs. Both return a TemplateResponse — DashboardController.php:88 is new TemplateResponse(Application::APP_ID, 'index') and :182 is the SPA catch-all at /{path}. A Newman/PHPUnit contract test over an HTML shell asserts nothing about a contract.

⚠️ The obvious dodge is a @contract exclude naming the Playwright suite — and it would be a false reason. #176 establishes that playwright-test-path scopes the CI job to tests/e2e/spec-coverage, so 62 tests in 14 files have never run in CI. An exclusion whose reason names a test artifact holds only while that artifact runs; here it does not. Fix #176 first, or the waiver rots on the day it is written.

The other three are real, writable contract tests: guardrailPolicy#effective and tenantModelPolicy#effective are plain JSON GETs on fixed URLs, and exportPackage already has service-level coverage to lean on. 3 of 5 are a normal afternoon; 2 of 5 are blocked on #176.

gate-26 — the exact six, and the trap to avoid

src/views/AgentMemory.vue
src/views/ApprovalInbox.vue
src/views/FlowBuilder.vue
src/views/GuardrailPolicySettings.vue
src/views/McpTools.vue
src/views/TenantOps.vue

The gate accepts three things: a baseline/spec under tests/e2e/visual/**, an e2e test anywhere under tests/e2e/** that drives the component, or a reason-bearing @visual exclude.

⛔ Do not take option 1. The fleet has confirmed twice (doriath, pipelinq) that CI's Playwright project carries testIgnore: ['**/visual/**'], so PNGs dropped in tests/e2e/visual/ are a baselines-to-dodge green: the gate goes quiet and nothing is ever checked. Option 2 is the only honest one, and it too runs into #176.

🔑 gate-25 and gate-26 on this repo are both downstream of #176. Six visual findings and two of the five contract findings are not really coverage debt — they are "the Playwright job does not run the tests" wearing two different gate numbers. Fixing playwright-test-path is the highest-leverage item on this list.

gate-19 — unchanged at 491, and one thing that will raise it

Still a multi-week backlog. ⚠️ One caution for whoever schedules it: restoring the deleted session-context-performance change (see #183 — the requirements were deleted by 6cc6f17, not never written) hands gate-19 six more scenarios. That is the right thing to do for gate-46 (21 → 1) and it makes this number worse. Land them in that order and say so, or the rise reads as a regression.

Not on this list but now tracked

gate-7 residue after #187/#188 is 17 and had no issue — filed as #203. gate-46 is 26 → 21 via #202. gate-17 (3) and gate-57 (2) re-verified unchanged on #182 / #181.