AgentSkillsCN

version-manager

针对 core/versioning/version-manager.js 的编辑设置防护措施,涵盖 SemVer 版本验证、弃用标记、迁移策略以及兼容性规则。适用于更改版本注册方式或调整迁移逻辑时使用。

SKILL.md
--- frontmatter
name: version-manager
description: "Guardrails for edits to core/versioning/version-manager.js covering semver validation, deprecation, migrations, and compatibility rules. Use when changing version registration or migration handling."

Skill: Version Manager Guardian

Purpose & Scope

This skill applies when modifying the Version Manager (core/versioning/version-manager.js).

The Version Manager provides:

  • Semantic versioning enforcement
  • Version compatibility analysis
  • Migration handler registration and execution
  • Version deprecation management
  • Breaking change detection
  • Compatibility matrix tracking

Critical Rules - NEVER Do

Version Lifecycle

  • NEVER delete versions without deprecation period (minimum 30 days)
  • NEVER skip the deprecation phase for any version
  • NEVER remove versions that are still in active use
  • NEVER change version registration timestamps retroactively

Semver Compliance

  • NEVER mark breaking changes as compatible
  • NEVER skip major version bump for breaking changes
  • NEVER allow non-semver version formats
  • NEVER bypass semver validation

Breaking Changes Classification

  • NEVER allow these changes in minor/patch versions:
    • Removing endpoints
    • Adding required parameters
    • Changing parameter types
    • Modifying authentication requirements
    • Changing response structure

Migration Safety

  • NEVER skip version compatibility analysis
  • NEVER allow migrations without registered handlers
  • NEVER execute migrations without rollback capability
  • NEVER bypass migration validation

Compatibility Matrix

  • NEVER delete compatibility matrix entries
  • NEVER falsify compatibility status
  • NEVER hide breaking changes in compatibility reports

Required Patterns - MUST Follow

Semver Validation

javascript
// MUST validate version format before registration
registerVersion(serviceId, version, config) {
    if (!semver.valid(version)) {
        throw new Error(`Invalid version format: ${version}`);
    }
    // Continue with registration
}

Breaking Change Detection

javascript
// MUST detect these as breaking changes:
const breakingChangeTypes = [
    'endpoint_removed',
    'method_changed',
    'path_changed',
    'required_parameter_added',
    'required_parameter_removed',
    'parameter_type_changed',
    'auth_type_changed',
    'baseUrl_changed'
];

// Compatibility MUST be false if any breaking changes exist
compatibility.compatible = compatibility.breakingChanges.length === 0;

Version Registration

javascript
// MUST include metadata on registration
this.supportedVersions.set(key, {
    ...config,
    registeredAt: new Date(),
    deprecated: false
});

// MUST create compatibility mappings
this.createCompatibilityMappings(serviceId, version, config);

// MUST emit registration event
this.emit('version:registered', { serviceId, version, config });

Deprecation Process

javascript
// MUST follow deprecation protocol
deprecateVersion(serviceId, version, reason) {
    config.deprecated = true;
    config.deprecationReason = reason;
    config.deprecatedAt = new Date();

    this.emit('version:deprecated', { serviceId, version, reason });
}

Migration Handler Registration

javascript
// MUST register handlers for version transitions
registerMigrationHandler(serviceId, fromVersion, toVersion, handler) {
    const key = `${serviceId}:${fromVersion}->${toVersion}`;
    this.migrationHandlers.set(key, handler);
}

Event Emission

javascript
// MUST emit events for version lifecycle
this.emit('version:registered', { serviceId, version, config });
this.emit('version:deprecated', { serviceId, version, reason });
this.emit('migration:completed', { serviceId, fromVersion, toVersion, data });
this.emit('migration:failed', { serviceId, fromVersion, toVersion, error });

Version Deprecation Timeline

code
Day 0:    Mark as deprecated, emit 'version:deprecated' event
Day 1-7:  Log warnings for all requests using deprecated version
Day 8-14: Return deprecation headers in responses
Day 15-29: Increase warning severity
Day 30+:  Safe to remove (after migration verification)

Breaking Change Reference

Change TypeSeverityVersion BumpMigration Required
Endpoint removedBREAKINGMajorYes
Method changedBREAKINGMajorYes
Path changedBREAKINGMajorYes
Required param addedBREAKINGMajorYes
Required param removedBREAKINGMajorYes
Param type changedBREAKINGMajorYes
Auth type changedBREAKINGMajorYes
Optional param addedCompatibleMinorNo
New endpoint addedCompatibleMinorNo
Bug fixCompatiblePatchNo

Version Status Lifecycle

code
REGISTERED -> ACTIVE -> DEPRECATED -> REMOVED
     ^           |
     +-----------+ (rollback possible before deprecation)
  • REGISTERED: Version exists but may not be in use
  • ACTIVE: Version is in production use
  • DEPRECATED: Marked for removal, deprecation period started
  • REMOVED: Version no longer supported (30+ days after deprecation)

Integration Points

ComponentIntegration Method
Base ClientVersion passed in request options
Metrics CollectorVersion label in request metrics
REST API/v{version}/ path prefix
MCP ServerVersion header in tool calls
Vendor AbstractionVersion-specific vendor mappings