Bumps [actions/add-to-project](https://github.com/actions/add-to-project) from 1.0.2 to 2.0.0.
- [Release notes](https://github.com/actions/add-to-project/releases)
- [Commits](actions/add-to-project@244f685...5afcf98)

---
updated-dependencies:
- dependency-name: actions/add-to-project
  dependency-version: 2.0.0
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>

…atus values beyond

…ent definition as well not just ssp.

The "Tests for match=@opr:id template" scenario used
<x:context select="@opr:id"> with inline content <foo opr:id="..."/>.
XSpec evaluates the select against the document node that wraps the inline
content, and a document node has no attributes, so the context was an empty
sequence and the scenario aborted with XTMM9000 ("Context is an empty
sequence"), the failure reported in #2166.

Select the attribute through its element instead. Because merge.xspec declares
the default namespace http://csrc.nist.gov/ns/oscal/1.0, the inline <foo> is in
that namespace, so the selector uses the o: prefix already bound in the file
(as in existing scenarios like //o:selection): o:foo/@opr:id. The attribute
node then dispatches to the no-op template match="@opr:id" in
oscal-profile-resolve-merge.xsl, producing nothing, which matches the
scenario's <x:expect select="()"/>.

This is a test-case defect, not a profile-resolver defect: the @opr:id scrub
template is correct and is relied on across the merge suite (the several
"@opr:id omitted" expectations). Only the test's context selector changes.

Refs #2166

Signed-off-by: Arpit Jain <arpitjain099@gmail.com>

oscal-unique-metadata-link keyed uniqueness on @href, @rel, and @media-type
only. Two links referencing the same back-matter resource by UUID but citing
different fragments via @resource-fragment collided and produced a false
uniqueness violation, while the equivalent direct-link form (distinct @href)
validated cleanly.

Add @resource-fragment to the key so links differing only by fragment are
treated as distinct. Relax the constraint from ERROR to WARNING since these
links are citations rather than addressable keys; WARNING is already used for
comparable advisory constraints in the metaschema.

Refs #2228

Signed-off-by: Arpit Jain <arpitjain099@gmail.com>

The by-item-name flag description gave 'title' as an example item-name to remove, but the oscal-profile-alter-by-item-name-values constraint intentionally does not allow 'title' (a control title is required, cardinality 1, and removing it would permit substituting a control's identity while keeping its id). Per the discussion in #2155, the description text is the inconsistency, not the constraint. Replace the title example with valid removable item-names (prop, link).

Signed-off-by: Arpit Jain <arpitjain099@gmail.com>