E2E: #957 left 3 failures on development — VotingRound has no link to a Motion

[rubenvdlinde]

quality / E2E Tests (Playwright) is red on development. The run at 13:48 (33255969802) was green; the run at 15:09 (33259463878) is red, and 140a7ad4 feat(types): introduce the configurable type layer (#957) is the only commit between them — it landed 5 seconds before the failing run started.

4 failed, 141 passed. One is fixed in #967 (the gov/assoc MODE_LABELS unification). These three are for the #957 workstream, because fixing them means deciding a data model that #957 is actively changing.

---

1 + 2. voting-rules.spec.ts:222 and :281 — the panel shows another motion's round

⚠️ This is a product defect, not only a test one.

VotingRoundPanel.fetchCurrentRound() scopes by:

this.objectStore.fetchCollection('voting-round', { 'relations.motion': this.motionId })

But VotingRound declares no motion property and no relations property. From lib/Settings/decidesk_register.json:

VotingRound -> votingMethod, isSecret, openedAt, closedAt, quorumWith, result,
               votesFor, votesAgainst, votesAbstain, votingDeadline,
               deadlineReminderSentAt, voteThreshold, abstentionHandling,
               tieBreakRule, chairCastingVote, revoteOfRound, voteBase,
               decisionStage

Its only declared link is decisionStage. The spec seeds the other side of the same non-existent shape:

relations: [{ register: 'decidiq', schema: 'motion', id: motionId }]

So neither side ever established the link. LiveMeeting.vue:560 already documents the dialect and warns against exactly this — a query key that is not a real schema property is classified as an object-field filter, and applyObjectFilters() appends 1 = 0.

Why it passed until now: the filter was inert, so fetchCurrentRound() effectively saw every voting-round in the register — and the test's own round was the only row. #957's register.d/70-configurable-types.json seeds three voting-rounds, so open || recent now selects a seeded one:

Expected substring: "Qualified majority (3/4)"        ← the test's seed, base 10
Received string:    "Rules: Simple majority (50%+1) · Abstentions excluded
                     from base · Tie: chair decides — base: 0"

That received string is the seed data (voteThreshold: simple-majority, no votes → base 0), not a component default — the rules paragraph only renders when currentRound is truthy. :222 is the same cause: its result-voting-rules block never renders because the round it finds is not the closed one it seeded.

The decision needed: how should a VotingRound be scoped to a Motion — through decisionStage, or by adding a real motion property? Once that is settled, the panel filter, the two seeds and the assertions all follow. I did not guess at it.

3. crud-persistence.spec.ts:405 — meeting edit does not persist

Expected: "e2e-1788018432457-5433-meeting-editbug-edited"
Received: "e2e-1788018432457-5433-meeting-editbug"

The dialog closes, but the object keeps its old title. #957 also touched the meeting surfaces (MeetingCalendarView.vue, MeetingViewToggle.vue, UpcomingMeetingsListWidget.vue) and added meeting-type configurable types, so this is most likely the same change — but I did not trace it to a specific mechanism and it should not be assumed.

---

cc the #957 author — the diagnosis above is also in #967's description.

[github-actions]

Thank you for opening this issue! It has been assigned to @rubenvdlinde for review.

What happens next:

1. A maintainer will review this issue and determine the appropriate action
2. If accepted, it may be converted into an OpenSpec change for structured development
3. You will be notified of any status changes

Triage labels:

• triage:accept-feature — accepted as a new feature
• triage:accept-bugfix — accepted as a bug fix
• triage:needs-info — more information needed
• triage:wontfix — will not be addressed
• triage:duplicate — duplicate of another issue

[rubenvdlinde]

Status change worth knowing about: these are no longer red — they are invisible.

development now reports 146 passed, 45 skipped, 0 failed (run 33265879025). The three failures did not get fixed; two of them turned into silent skips, and the third no longer appears at all.

The mechanism, for whoever picks up #957:

getFirstObject() in relation-tab-ui.spec.ts did if (!resp.ok()) return null, which gives the same null for schema absent (404) and schema empty (200, no rows). Every caller then skipped with No <schema> objects found.

But the decidiq register has no motion schema and no amendment schema at all. ci-seed prints the ~100 slugs it does have — agenda-item, decision, voting-round, vote, minutes are all there; motion and amendment are not. So:

test	now	why
motion detail renders votes tab area	skipped	GET /api/objects/decidiq/motion → 404
amendment detail renders with parent motion tab	skipped	GET …/amendment → 404

This is the same finding #969 already reaches — "fixing them means deciding a data model" — but the failure mode has changed underneath it. A red test argues for itself on every run; a skip inside a green run does not, and nothing will resurface these when #957 lands.

#975 makes the skip reason state which gap it is (data-model vs seeding). It deliberately un-skips nothing and moves no verdict — the data-model decision stays yours. Worth adding an acceptance criterion to #957 that these two are un-skipped once motions have a home, since right now nothing in CI will notice if they stay skipped forever.