openvidu-dashboard: archive remove-info-license, keep only the specs

openvidu-dashboard/openspec/changes/remove-info-license/.openspec.yaml

@@ -1,2 +0,0 @@
-schema: spec-driven
-created: 2026-10-27

openvidu-dashboard/openspec/changes/remove-info-license/design.md

@@ -1,43 +0,0 @@
-# Design
-
-## Context
-
-- `InfoService.build()` reads an optional `license` callback, bound in the container to `TOKENS.LicenseInfo` (`() =>
-  undefined` on CE). It spreads the result into the response only when it is defined.
-- The `GET /api/v1/info` route declares `license` as an optional object of its zod response schema, so the OpenAPI
-  document shows it.
-- `FeatureKey.LICENSE_INFO` has a copy in `FEATURE_COPY`, but no route or page gates on it.
-
-## Goals / Non-Goals
-
-**Goals:**
-- No edition can add license data to `GET /api/v1/info`, and the OpenAPI document does not suggest it.
-
-**Non-Goals:**
-- Changing `info.license` of the OpenAPI document or `apiLicense`.
-- Any other key of the info response.
-
-## Decisions
-
-### Remove the seam, not only the field
-
-The token, the service option, the type and the schema property all go. An extending edition can no longer rebind
-`LicenseInfo`, because the token no longer exists. The response schema has no `license` property, so the document
-never declares it.
-
-Alternative rejected: keeping the token with a CE default and dropping only the schema property. The response
-would still carry whatever a rebinding returned, without documentation.
-
-### Drop the feature identifier
-
-`license-info` gated nothing. Keeping it would advertise a feature in `features` that no page offers.
-
-### OpenAPI shape
-
-- `GET /api/v1/info`: the `200` schema loses `license`, and `features` items lose `license-info`.
-- Paths, parameters and status codes do not change. No query, index or performance budget is involved.
-
-## Risks / Trade-offs
-
-- **[Removing a key from `v1`]** → The key was never released, so the versioning policy for released fields does not
-  apply.

openvidu-dashboard/openspec/changes/remove-info-license/proposal.md

@@ -1,44 +0,0 @@
-# Proposal
-
-## Why
-
-`GET /api/v1/info` declares an optional `license` block, and the feature catalogue a `license-info` key. No page
-shows either, and the dashboard is not meant to expose license data, in the UI or through the API.
-
-## What Changes
-
-- **BREAKING (unreleased):** `GET /api/v1/info` loses the optional `license` key: no edition reports it, and the
-  OpenAPI document no longer declares it.
-- The `license-info` identifier leaves the `FeatureKey` enumeration and the lock catalogue of the UI.
-- The backend loses the `LicenseInfo` extension token, the `InfoLicense` type and the info service option that
-  filled the key.
-
-Scope excludes the following:
-- The OpenAPI document's `info.license` (the license of the API itself) and the `apiLicense` option of
-  `startDashboard()`.
-- CE's lack of license checks, which stays as specified.
-
-Edition: CE, and the seams an extending edition uses. Repository: dashboard only (`openvidu-dashboard/` in
-`OpenVidu/openvidu`).
-
-CHANGELOG: none. The key and the feature identifier never shipped in a release.
-
-## Capabilities
-
-### New Capabilities
-
-None.
-
-### Modified Capabilities
-
-- `editions-info`: the Info endpoint keys, the migration outcome requirement (replaced by one without the license)
-  and the feature catalogue.
-
-## Impact
-
-- Typings: `api/info.ts` (`InfoLicense`, `InfoResponse.license`) and `api/features.ts` (`LICENSE_INFO`).
-- Backend: `di/tokens.ts`, `di/container.ts`, `info/info-service.ts` and `info/info-routes.ts`. Rebinding
-  `LicenseInfo` from `DashboardOptions.configure` is no longer possible.
-- Frontend: `components/lock/features.ts`.
-- Tests: the typings UI contract, the info, shell and settings specs, and the settings e2e suite.
-- Docs: `dashboard-ce/backend/AGENTS.md`, which lists the extension tokens.

openvidu-dashboard/openspec/changes/remove-info-license/specs/editions-info/spec.md

@@ -1,71 +0,0 @@
-## MODIFIED Requirements
-
-### Requirement: Info endpoint
-
-Edition: CE. With a valid bearer token `GET /api/v1/info` SHALL answer `200` with the keys `edition`, `versions`,
-`schema`, `migration`, `retention?`, `database`, `storage`, `features`, `limits` and `openapiDocsEnabled`, where
-`schema.status` is the writer schema gate's `ok`, `newer`, `older` or `uninitialized` and `openapiDocsEnabled` tells
-whether the docs routes are served.
-
-#### Scenario: CE with a running writer
-
-- **GIVEN** the CE dashboard 3.10.0 expects schema 1 and `schema_meta` records writer schema 1, server 3.10.0, a
-  completed migration and the default retention, with the default `DASHBOARD_LIST_TOTAL_MAX_RANGE`
-- **WHEN** the client requests `GET /api/v1/info` with a valid token
-- **THEN** the response is `200` with `edition: "ce"`, `versions: { dashboard: "3.10.0", server: "3.10.0" }`,
-  `schema: { dashboard: 1, writer: 1, status: "ok" }`, `migration.state: "completed"`, `migration.progress.processed`
-  and `.total`, `retention: { eventsMs: 604800000, statsMs: 604800000, tracksMs: 604800000,
-  entitiesMs: 7776000000, rollups5MinMs: 604800000, rollupsHourlyMs: 34560000000, rollupsDailyMs: null }`,
-  `features: []`, `limits: { rankedSortMaxRangeMs: 604800000, participantRankedSortMaxRangeMs: 86400000 }` and
-  `openapiDocsEnabled: false`
-
-#### Scenario: Migration in progress
-
-- **GIVEN** the writer's migration document has `state: 'running'`, `processed: 400000` and `total: 1200000`
-- **WHEN** the client requests `GET /api/v1/info` with a valid token
-- **THEN** `migration` is `{ state: "running", progress: { processed: 400000, total: 1200000, startedAt } }`
-
-#### Scenario: Nested keys
-
-- **WHEN** a client with a valid bearer token requests `GET /api/v1/info`
-- **THEN** `versions` holds `dashboard` and `server?`, `schema` holds `dashboard`, `writer?` and `status`, `migration`
-  holds `state`, `progress?` and `error?`, and `limits` holds `rankedSortMaxRangeMs` and
-  `participantRankedSortMaxRangeMs`
-
-### Requirement: Feature catalogue
-
-Edition: CE. `features` SHALL be an array of `FeatureKey` identifiers from a shared enumeration (`room-detail`,
-`participant-detail`, `egress-detail`, `ingress-detail`, `analytics-quality`, `analytics-diagnostics`,
-`analytics-top-rooms`, `track-detail`, `per-node-breakdown`), empty on CE; every PRO feature has its identifier in it.
-
-#### Scenario: CE feature list
-
-- **WHEN** the CE dashboard answers `GET /api/v1/info`
-- **THEN** `features` is `[]`
-
-#### Scenario: Unknown identifier tolerated
-
-- **GIVEN** a PRO backend newer than the UI reports a feature the UI does not know
-- **WHEN** the UI reads `features`
-- **THEN** it ignores the unknown identifier and keeps working
-
-## ADDED Requirements
-
-### Requirement: Migration outcome in info
-
-Edition: CE. `migration.progress` SHALL carry `processed`, `total`, `startedAt?` and `finishedAt?`, and `migration.error`
-SHALL carry the reason of a `failed` migration.
-
-#### Scenario: Failed migration
-
-- **GIVEN** the writer's migration document has `state: 'failed'`, `finishedAt` and `error: 'legacy event without a room'`
-- **WHEN** the client requests `GET /api/v1/info` with a valid token
-- **THEN** `migration` has `state: "failed"`, `progress.finishedAt` and `error: "legacy event without a room"`
-
-## REMOVED Requirements
-
-### Requirement: Migration outcome and license in info
-
-**Reason**: Info no longer reports a license; the migration outcome moves to "Migration outcome in info".
-
-**Migration**: None. The `license` key never shipped in a release.

openvidu-dashboard/openspec/changes/remove-info-license/tasks.md

@@ -1,32 +0,0 @@
-# Tasks
-
-## 1. Typings
-
-- [x] 1.1 Remove `InfoLicense` and `InfoResponse.license` from `typings/src/api/info.ts`, and `LICENSE_INFO` from
-      `typings/src/api/features.ts`. Drop the `license` assertion of `typings/test/ui-contract.test.ts`. Verify with the
-      typings typecheck and tests.
-
-## 2. Backend
-
-- [x] 2.1 Remove `TOKENS.LicenseInfo`, its default binding and the `license` option of `InfoService`, and the
-      `license` property of the info response schema. Verify with the backend typecheck and unit tests, and that the
-      OpenAPI document of the integration suite has no `license` under the info response.
-
-## 3. Frontend
-
-- [x] 3.1 Remove the `license-info` entry of `FEATURE_COPY` and the uses of that identifier and of "License" in the
-      info, shell and settings specs. Verify with the library unit tests.
-
-## 4. Tests
-
-- [x] 4.1 In `e2e/tests/settings.spec.ts`, drop the `license` of the PRO info and the "License" checks, keeping the
-      PRO badge check. Verify with the e2e suite.
-
-## 5. Docs and CHANGELOG
-
-- [x] 5.1 Remove `LicenseInfo` from the extension tokens of `dashboard-ce/backend/AGENTS.md`. No CHANGELOG line: the
-      key never shipped. Verify by reading the file against the change.
-
-## 6. Integration check
-
-- [x] 6.1 Run lint, format check, typecheck, spec validation, unit, integration and e2e tests. Verify that they pass.

openvidu-dashboard/openspec/specs/editions-info/spec.md

@@ -10,9 +10,9 @@ them from the same contract.
 ### Requirement: Info endpoint
 
 Edition: CE. With a valid bearer token `GET /api/v1/info` SHALL answer `200` with the keys `edition`, `versions`,
-`schema`, `migration`, `retention?`, `database`, `storage`, `features`, `limits`, `license?` and `openapiDocsEnabled`,
+`schema`, `migration`, `retention?`, `database`, `storage`, `features`, `limits` and `openapiDocsEnabled`, where
-where `schema.status` is the writer schema gate's `ok`, `newer`, `older` or `uninitialized` and `openapiDocsEnabled`
+`schema.status` is the writer schema gate's `ok`, `newer`, `older` or `uninitialized` and `openapiDocsEnabled` tells
-tells whether the docs routes are served.
+whether the docs routes are served.
 
 #### Scenario: CE with a running writer
 
@@ -39,11 +39,10 @@ tells whether the docs routes are served.
   holds `state`, `progress?` and `error?`, and `limits` holds `rankedSortMaxRangeMs` and
   `participantRankedSortMaxRangeMs`
 
-### Requirement: Migration outcome and license in info
+### Requirement: Migration outcome in info
 
 Edition: CE. `migration.progress` SHALL carry `processed`, `total`, `startedAt?` and `finishedAt?`, and `migration.error`
-SHALL carry the reason of a `failed` migration. `license` (`validUntil?`, `maskedKey`) SHALL be reported only by a
+SHALL carry the reason of a `failed` migration.
-licensed PRO deployment; CE never reports it.
 
 #### Scenario: Failed migration
 
@@ -51,12 +50,6 @@ licensed PRO deployment; CE never reports it.
 - **WHEN** the client requests `GET /api/v1/info` with a valid token
 - **THEN** `migration` has `state: "failed"`, `progress.finishedAt` and `error: "legacy event without a room"`
 
-#### Scenario: No license on CE
-
-- **GIVEN** the CE dashboard
-- **WHEN** the client requests `GET /api/v1/info` with a valid token
-- **THEN** the response has no `license` property
-
 ### Requirement: Info fields recorded by the writer
 
 Edition: CE. `versions.server`, `schema.writer`, `migration` and `retention` (`eventsMs`, `statsMs`, `tracksMs`,
@@ -118,8 +111,7 @@ subset.
 
 Edition: CE. `features` SHALL be an array of `FeatureKey` identifiers from a shared enumeration (`room-detail`,
 `participant-detail`, `egress-detail`, `ingress-detail`, `analytics-quality`, `analytics-diagnostics`,
-`analytics-top-rooms`, `track-detail`, `per-node-breakdown`, `license-info`), empty on CE; every PRO feature has its
+`analytics-top-rooms`, `track-detail`, `per-node-breakdown`), empty on CE; every PRO feature has its identifier in it.
-identifier in it.
 
 #### Scenario: CE feature list