case-header: the one-line tab requirement and CnTabs' deliberate wrapping cannot both hold at 1024

[rubenvdlinde]

case-header.spec.ts:287 — "the work tabs share one line at 1024, above the fold" — fails on the current suite, and it cannot be fixed in either place without someone deciding something. I fixed the other two failures in that file (#2011) and left this one alone deliberately.

The failure

Error: work-tab tops: 478.59375, 478.59375, 520.59375, 520.59375, 561.59375
Expected: 1     Received: 3

Five work tabs on three rows at a 1024px viewport.

Why this is not a test bug

The test's own comment states the requirement it is guarding:

Ten tabs wrapped onto three lines at 1440 and the strip fell below the fold at 1024, so the tabs a handler works in were the ones they could not see.

Relaxing the assertion would convert that back into an unobserved product gap. It is the one repair that must not happen here.

Why it is not a component bug either

The wrapping is .cn-tabs__nav in @conduction/nextcloud-vue's CnTabs, and it is deliberate, with its reasoning written beside it:

Wrap before scrolling. A horizontally scrolling strip hides tabs behind an edge with nothing to say they are there, and beside a #nav-end control the clipped tab reads as sitting UNDER the control. Wrapping keeps every tab reachable without a gesture.

That is a considered accessibility choice. Overriding it from one app — or changing it in a library all 21 apps share — to satisfy one spec would trade a real property for a green test.

So the two requirements have diverged

• nc-vue: every tab reachable without a gesture, therefore wrap.
• dossiq A33: the work tabs on one line, above the fold at 1024, therefore do not wrap.

Both are right on their own terms. They are jointly unsatisfiable at nine tabs and this label length on a 1024px viewport. The case header now carries five work tabs plus four conditional ones.

The decision someone owns

1. Fewer tabs at laptop width — collapse the four conditional tabs behind an overflow control, so the five work tabs keep their line.
2. Shorter labels — the current set is Data, Documents, Parties, Tasks, Communication plus four more; narrower labels may fit one line.
3. Accept wrapping and re-state A33 — if two rows above the fold is acceptable, the assertion should say that, and say why it changed.
4. A scrolling strip with an affordance — which is what CnTabs' comment explicitly rejects, so it would need arguing there rather than here.

I have no basis to pick. Option 1 looks strongest to me because it keeps both properties, but it is a change to what the header offers and that is not mine to decide.

Filed rather than fixed. The two fixture bugs in the same file are in #2011.

[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]

This may resolve itself without anyone taking the decision below. #2013 reportedly takes the case page from fourteen tabs to six.

The conflict I described is not really "wrap versus one line" — it is a tab count that outgrew the width available at 1024px. At six tabs the five work tabs plausibly share a line without CnTabs changing anything and without A33 being restated, which would make option 1 in my list the one that happened, arrived at for its own reasons rather than to satisfy a spec.

So before anyone spends time on the four options: re-run case-header.spec.ts:287 once #2013 has landed. If it passes, this issue closes as overtaken and nothing needs deciding. If it still fails at six tabs, the trade-off is real and the options stand.

I have not verified the tab count myself — it comes from the session that owns #2013 — so treat it as a lead rather than a measurement. What I did verify is that the failure is five work tabs on three rows at 1024, and that flex-wrap: wrap in CnTabs is deliberate and documented.