Add sample PQC readiness perspective for CBOM - #960

...ract in CI
The registry data file is hand-maintained (no generator), so until now
nothing asserted that it actually conforms to its governing schema or that
the hand-kept enum stays in step with the entries. Add a registry test to
the schema-v2 suite (picked up by `npm test` via the `test:*` glob, so the
existing JavaScript CI workflow runs it on every pull request):
- schema/perspectives-defs.json validates against
 schema/perspectives-defs.schema.json (strict ajv, draft-07 meta-schema,
 formats enabled).
- preDefinedPerspectivesEnum and the entries' `predefined` values are the
 same set, with no duplicates on either side; the message names which
 file to fix.
- every entry's `file` points under perspectives/. A missing document only
 warns, so an identity can be reserved ahead of its catalog document
 (pqc-readiness, CycloneDX#960). An existing document must
 be JSON, declare an integer `version` >= 1 (the value a reference's
 `predefinedVersion` selects), define at least one perspective, and define
 it inline (no `predefined`/`predefinedVersion`), since catalog entries are
 the published definitions, not references.
The test is not versioned (`-v`) because the registry lives at the schema
root and is shared across specification versions.
Verified: suite green; each check fails on a tampered input (unknown
identity/missing file in data, enum drift, catalog document in reference
form, catalog document without version).

...d references, standalone registry
* feat(perspective): namespace pre-defined perspective identities under cdx:perspectives:
Per review on CycloneDX#1067: prefix the pre-defined
perspective enum values with the reserved cdx: namespace and a
cdx:perspectives: path, so 'model-card' becomes
'cdx:perspectives:model-card' and 'pqc-readiness' becomes
'cdx:perspectives:pqc-readiness'. This aligns the identities with the
reserved CycloneDX property taxonomy and keeps them collision-free with
author-chosen names.
Updates the enum, its meta:enum keys, the field description, and the
valid/invalid test fixtures accordingly.
* feat(perspective): version pre-defined perspective references (registry model)
Per Steve's review on CycloneDX#1067: adopt a registry model
for pre-defined perspectives, referenced by identity plus version.
- Add a required sibling 'predefinedVersion' (integer, minimum 1) on the
 reference form. It selects the published revision of the perspective and
 is the 'version' of the catalog document that defines it; like other
 CycloneDX version fields it increments by 1 per revision. Pinning it
 keeps a reference stable as the catalog perspective evolves.
- The reference form now requires both predefined and predefinedVersion
 (and still forbids all inline content but bom-ref); the inline form
 forbids both.
- The 'predefined' enum stays ids-only, hand-maintained inline (the
 registry is this id list plus the versioned catalog files) -- no
 separate data file or generator, unlike the crypto family registry,
 since the set is small and curated and version is not schema-enumerated
 per id (mirroring how crypto validates the family but not the parameter
 set).
Fixtures: valid reference form gains the version; the unknown-id,
annotated and mixed invalid cases gain it so each isolates its intended
violation; new invalid fixture covers a reference missing the required
version.
* feat(perspective): move pre-defined perspective registry into a standalone defs file
Decouples the pre-defined perspective lifecycle from the specification
release cycle, the same way the cryptography algorithm registry is
handled: perspectives can be added or revised, and new catalog document
versions published, by editing the registry alone -- no change to the
versioned specification schemas.
- New schema/perspectives-defs.schema.json: a single registry file
 holding the reserved identity enum (definitions.preDefinedPerspectivesEnum)
 and the identity-to-catalog-document map (definitions.catalog, id ->
 document path under perspectives/). Kept to one file, no separate data
 file or generator (the set is small and curated, unlike the ~100-entry
 crypto family registry that justifies generation).
- cyclonedx-perspective-2.0.schema.json: 'predefined' now the
 external enum (../../perspectives-defs.schema.json#/definitions/
 preDefinedPerspectivesEnum) instead of an inline enum; the inline
 preDefinedPerspective def is removed.
- bundler: perspectives-defs.schema.json added to the external ref
 exceptions so it stays external in the bundle (like cryptography-defs).
- schema-v2 validate + functional harnesses: load and register the new
 external schema so refs resolve.
The registry data is expressed with schema keywords (const-valued map
entries) so the single file remains a valid JSON Schema under the
harness's ajv strict mode. Bundled schemas left to the post-merge
workflow.
* refactor(perspective): split pre-defined registry into data file + governing schema
Follows the crypto registry's file split so the registry data has a real,
checkable contract (the previous single file invented an unvalidated
const-map convention).
- schema/perspectives-defs.json: the registry DATA, hand-edited (no
 generator). Each entry is a proper object: predefined (the reserved
 identity, matching the CycloneDX perspective 'predefined' field),
 file (catalog document path), and description. Declares its governing
 schema via $schema.
- schema/perspectives-defs.schema.json: now a governing meta-schema that
 defines the data file's shape (perspectives[] of {predefined, file,
 description}, predefined constrained to preDefinedPerspectivesEnum) and
 still exposes preDefinedPerspectivesEnum for the specification schema to
 $ref. Identities are entry values, not object keys.
Data edits stay manual, matching how the crypto data file is maintained;
the enum in the governing schema is kept in sync by hand (the set is
small and curated). Verified the data file validates against the
governing schema, and the schema-v2 suite passes.
* test(perspective): enforce the pre-defined perspectives registry contract in CI
The registry data file is hand-maintained (no generator), so until now
nothing asserted that it actually conforms to its governing schema or that
the hand-kept enum stays in step with the entries. Add a registry test to
the schema-v2 suite (picked up by `npm test` via the `test:*` glob, so the
existing JavaScript CI workflow runs it on every pull request):
- schema/perspectives-defs.json validates against
 schema/perspectives-defs.schema.json (strict ajv, draft-07 meta-schema,
 formats enabled).
- preDefinedPerspectivesEnum and the entries' `predefined` values are the
 same set, with no duplicates on either side; the message names which
 file to fix.
- every entry's `file` points under perspectives/. A missing document only
 warns, so an identity can be reserved ahead of its catalog document
 (pqc-readiness, CycloneDX#960). An existing document must
 be JSON, declare an integer `version` >= 1 (the value a reference's
 `predefinedVersion` selects), define at least one perspective, and define
 it inline (no `predefined`/`predefinedVersion`), since catalog entries are
 the published definitions, not references.
The test is not versioned (`-v`) because the registry lives at the schema
root and is shared across specification versions.
Verified: suite green; each check fails on a tampered input (unknown
identity/missing file in data, enum drift, catalog document in reference
form, catalog document without version).
* test(perspective): register the perspectives registry schema in the Java 2.x harness
The Java schema-v2 verification harness resolves external schema URIs
through an explicit classpath mapping and disallows anything else, so the
perspective schema's $ref to perspectives-defs.schema.json failed to load
("Schema from 'https://cyclonedx.org/schema/perspectives-defs.schema.json'
is not allowed to be loaded"), erroring the five perspective fixtures.
Map the http/https URIs of perspectives-defs.schema.json to the classpath
copy (schema/ is already a test resource root), alongside the existing
cryptography-defs and behavior-taxonomy mappings.
Verified: `mvn clean test -Pschema-v2-tests` green locally (229 tests,
0 errors).
* feat(perspective): generate the pre-defined perspectives registry and enforce immutable published versions
The registry data (schema/perspectives-defs.json) is now GENERATED, in the
spirit of the crypto registry's generator, and published perspective
versions become immutable:
- Naming convention replaces any mapping: the catalog document defining
 `cdx:perspectives:<name>` is `perspectives/<name>-perspective.json`.
 Identities are lowercase-kebab-case. The identity enum in the governing
 schema stays hand-maintained (now with meta:enum descriptions, so a
 reserved identity without a document still has one).
- Registry entries are objects {predefined, file, name, description,
 versions[]}; each version record is {version, sha256, commit, date}:
 sha256 of the catalog document's canonical JSON (keys sorted, no
 whitespace, so formatting-only edits do not count as changes), the last
 commit touching the document, and that commit's UTC date. `name` and
 `description` are copied from the document at the latest version.
 lastUpdated is the newest registered date (deterministic).
- tools/src/main/js/perspectives-registry/: shared module (convention,
 canonical hash, structural checks, version-state assessment) used by both
 the generator and the test, plus generate-perspectives-registry.js. The
 generator only appends unregistered versions (a new perspective at
 version 1, or registered latest + 1); it refuses content changed at a
 registered version, regressed or skipped versions, removed registered
 documents, documents not defining exactly one inline perspective, and
 identities violating the convention. Idempotent when nothing changed.
- .github/workflows/generate_perspectives_registry.yml: on push to
 master/main/2.0-dev touching perspectives/**, the governing schema, or
 the generator, runs the generator and commits the registry directly
 (with a skip-ci marker), mirroring bundle_2.0_schemas.yml. A failing generator (change
 without bump merged over a red check) fails the workflow.
- The schema-v2 registry test now shares that logic and checks every
 identity in the enum: reserved, new, unchanged and pending (latest + 1)
 pass; modified, regressed, skipped and removed fail. It also checks
 registered entries follow the convention and list contiguous versions
 from 1, and that every registered identity is in the enum.
- Governing schema rewritten for the generated shape (patterns for file,
 sha256, commit; date-time dates; versions minItems 1).
- Perspective schema: `predefined` description now states the naming
 convention instead of a mapping.
Initial registry generated from this branch: model-card version 1 at
ebb5184 (the commit is fork-side provenance; the hash is the check key).
Verified: JS schema-v2 suite green; Java schema-v2 suite green (229 tests);
bundler unchanged (registry ref stays external); no new lint findings on
the perspective schema. Test and generator both reject each tampered
input: content change at a registered version, skipped/regressed version,
removed document, non-contiguous registry versions, non-convention
identity, document with two perspectives; a version bump registers cleanly
and formatting-only edits are accepted.
* feat: create generate_perspectives_registry.yml to generate perspectives defs PR
Signed-off-by: Pavel Shukhman <taleodor@users.noreply.github.com>
* fix: switch generate_perspectives_registry.yml to perspectives code
Signed-off-by: Pavel Shukhman <taleodor@users.noreply.github.com>
---------
Co-authored-by: Claude Code (ReARM Agent) <rearm-agent-claude@reliza.io>
Co-authored-by: Pavel Shukhman <taleodor@users.noreply.github.com>
Signed-off-by: Pavel Shukhman <taleodor@users.noreply.github.com>