Double AI-companion hex still live on 14 apps: nc-vue locked below 2.7.0

[rubenvdlinde]

The double hex is still live on 14 of 17 apps

The companion singleton fix shipped in nc-vue 2.7.0. Measured on the running instance this morning:

page	nc-vue	.cn-ai-floating-button	result
/apps/openconnector/	2.7.1	1	hermiq's standalone stood down correctly
/apps/openbuild/	2.6.3	2, both visible at 52×60, offset 8 px	the reported double hex

The two on the openbuild page are not duplicates of one mount — they are two different mounts:

button.cn-ai-floating-button → div.cn-ai-companion → div#content-vue.app-openbuild   ← host app's bundle
button.cn-ai-floating-button → div.cn-ai-companion → div#hermiq-companion-root       ← hermiq's init script

window.__cnAiCompanionPrimary was claimed, and both still rendered display:flex / visibility:visible / opacity:1 long past the 1200 ms LEGACY_SIBLING_DELAY. So the negotiation works between two 2.7.x instances and fails when the host app's copy predates it.

Who is affected — read from development, not from local checkouts

package-lock.json on development:

version	apps
2.3.0	opencatalogi, docudesk, pipelinq, decidesk, nldesign, larpingapp, softwarecatalog, procest, shillinq, doriath, launchpad, scholiq
2.4.0	portaliq
2.6.3	openbuild
≥ 2.7.0	openregister (2.8.0), openconnector (2.8.0), hermiq (2.7.0)

14 apps below 2.7.0. The caret ranges (^2.3.0) already permit 2.8.0 — as with hydra-gates, it is the lockfile doing the pinning, not the constraint.

⚠️ The npm vue3 dist-tag still points at 2.3.0 while latest is 2.8.0, which makes 2.3.0 look deliberate. It is not a compatibility boundary: npm view shows the two releases declare identical peer dependencies, vue: ^3.5.0 included. The tag is simply stale and worth moving or retiring.

Validated, not assumed

On a clean clone of openbuild@development:

npm install @conduction/nextcloud-vue@2.8.0   → exit 0, lock 2.6.3 → 2.8.0
npm run build                                  → exit 0 (webpack, 3 warnings, no errors)
grep __cnAiCompanionPrimary js/                → present in openbuild-main.js and openbuild-builder.js

So the bump installs, compiles, and ships the guard.

Why this is filed rather than merged

Bumping a UI library five minor versions across 14 apps is a visible change, and the only gate is each app's own e2e suite. That is a fleet-wide UI decision, not a lockfile bump, so it should not land unattended overnight.

The recipe is ready and can be executed per-app on approval — same shape as the hydra-gates v1.8.1 rollout that landed this morning.

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

Fixed fleet-wide. All 17 apps are on @conduction/nextcloud-vue 2.8.2 on development.

	before	now
below 2.7.0 (double hex)	14 apps — 2.3.0 ×12, 2.4.0 (portaliq), 2.6.3 (openbuild)	0
at/above 2.7.0	openregister, openconnector, hermiq	all 17

The pin was the lockfile, not the constraint — every app's caret already permitted it, exactly as with hydra-gates v1.8.0. npm update … --package-lock-only was used so nothing but the lock moved; each PR is a three-line diff (version, resolved, integrity).

What 2.8.2 carries

The companion singleton (2.7.0). Below it the host app's own companion never stands down, so hermiq's page-wide mount rendered alongside it. Measured before the roll: openconnector (2.7.1) → 1 button; openbuild (2.6.3) → 2, both visible at 52×60, 8 px apart, from two separate mounts (#content-vue.app-openbuild and #hermiq-companion-root).

A second, unrelated defect I found while chasing this — CnDetailPage reclosed its own sidebar while hydrating. syncSidebarState() documented "seed open only on the inactive→active edge … subsequent syncs must NOT clobber it", but set sidebarSeeded and never read it, so open was re-applied on every sync. Fixed in ConductionNL/nextcloud-vue#711 and released as 2.8.2, with three regression tests written against the unfixed component first (the key one failed: expected true, received false). Full library suite after: 535 suites, 6408 tests, all passing.

A note on the vue3 dist-tag

npm still advertises vue3 → 2.3.0 while latest is 2.8.2, which makes 2.3.0 look like a deliberate compatibility floor. It is not — npm view shows 2.3.0 and 2.8.x declare identical peer dependencies, vue: ^3.5.0 included. The tag is stale and worth moving or retiring before it pins someone again.

Closing. The remaining verification is each app's own e2e on development, which CI is working through now.