You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feat(identity): derive package name/version into project identity (stages 1-2) (#121)
* feat(identity): derive package name/version into project identity (stages 1-2)
Part of #94. Derives validated packageName/packageVersion from the
project's package.json into NormalizedMetadata and ProjectContext, and
exposes both axes distinctly in artifact manifests, inspect output, and
dev status DTOs (ArtifactEpoch). Projects without a package version keep
a clearly labeled development fallback in displays; nothing new is
required. New warning diagnostics: AB4008 (plugin.version differs from
the package version), AB4009 (invalid npm package name), AB4010
(invalid package semver), AB4011 (unparsable package.json). Per G9,
plugin.name stays the host-native slug and is never derived.
* feat(identity): adopt #115 conventions and fix Codex findings
Adopted from PR #115 (parallel session): the labeled 0.0.0-dev
development-fallback naming, package identity on the dev source status
DTO (SourceStatus + agent API wire DTOs + coordinator passthrough), a
minor changeset (new public manifest/context fields are a feature), and
ProjectService-level source-status test coverage. Codex fixes: reject
npm-reserved package names (node_modules, favicon.ico) and ignore a
package.json symlinked outside the project root (AB4011) so identity
cannot drift without a revision change. Also pins rejection of invalid
semver prerelease identifiers, which #115's looser pattern accepted.
* fix(workbench): accept the derived package identity fields in strict status and artifact decoders
The workbench client decodes /api/project/status and the artifact inspection
route with exact-key validation, so the new optional packageName/packageVersion
axes made every decode fail and the dashboard never settled (all browser e2e
suites timed out on visibility). Allow both optional fields in
sourceStatusSchema, artifactEpochSchema, and the artifact-client isProject
check, and flip the overview.e2e source-status pin to include the derived
packageName.
Derive validated `packageName`/`packageVersion` from the project's `package.json` into the project identity (issue #94 stages 1-2). Both axes now flow through the normalized model metadata, `ProjectContext`, artifact manifests, inspect output, and dev status DTOs (source status and artifact epochs); `plugin.version` still authors the native plugin version but the package version is authoritative for release identity and a mismatch never silently wins. Projects without a package version keep a clearly labeled `0.0.0-dev` development fallback in displays. New warning diagnostics: AB4008 (`plugin.version` differs from the package version), AB4009 (invalid npm package name), AB4010 (invalid package semver), AB4011 (unusable package.json).
`Config plugin.version ${JSON.stringify(pluginVersion)} differs from package.json version ${JSON.stringify(identity.packageVersion)}; the package version is authoritative for release identity.`,
1389
+
loaded.configPath,
1390
+
'Align plugin.version with the package.json version, or update package.json.',
0 commit comments