incorrect-package regex is not anchored and lets invalid package names pass

Problem

incorrect-package lets invalid package names pass because the second alternative of its regex is not anchored to the start of the string.

Root cause

src/main/resources/org/eolang/lints/metas/incorrect-package.xsl:17:

<xsl:if test="not(matches($tail, $eo:package-regexp))">

with the pattern

<xsl:variable name="eo:package-regexp" select="concat('[a-z][a-z0-9]*(\.[a-z0-9]+)*|[\p{L}\p{M}\p{N}_]+(\.[...])*$', ...)"/>

The second alternative [\p{L}\p{M}\p{N}_]+(\.[...])*$ has no leading ^, and matches() in XPath is not anchored by default. Verified: -bad and org..example are accepted without a defect.

Minimal example

+package -bad
+architect yegor@256.com
+version 0.0.1
+home https://github.com/objectionary
+spdx SPDX-FileCopyrightText: Copyright (c) 2026 Objectionary.com
+spdx SPDX-License-Identifier: MIT

[] > main

+package -bad does not trigger incorrect-package, although the name is clearly invalid.

Expected behavior

The whole regex should be anchored (a single ^...$ expression, or ^ added to the second alternative), so that invalid package names are always caught.

Related

• metas/prohibited-package.xsl — sibling rule for runtime-repo packages.

Start at src/main/resources/org/eolang/lints/metas/incorrect-package.xsl:17 and read how the package-regexp variable is used with XPath matches(). Compare the rule with metas/prohibited-package.xsl, then verify the minimal example and similar invalid package names. Done means invalid names such as -bad and org..example trigger incorrect-package while valid names remain accepted.