Menü
Enforces Standard Versioning discipline.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
Enforces Standard-compliant modeling, brokers, services, aggregation, exposers, REST APIs, and UI architecture.
Enforces the C# naming, organization, method, variable, class, field, instantiation, and comment/documentation rules of The Standard.
Enforces the theory, purpose, modeling, simulation flow, and non-negotiable core values of The Standard.
Enforces Standard contribution workflow, branching, categories, commits, pull requests, configuration handling, measurements, contribution points, and ranks.
Enforces Standard TDD discipline, validation testing, exception mapping, controller acceptance tests, and UI component testing.
| name | The Standard Versioning |
| description | Enforces Standard Versioning discipline. |
| the standard version | v2.12.0 |
| skill version | v0.3.0.0 |
This skill defines the required versioning approach for:
This skill MUST follow the explicit versioning model defined here and MUST NOT substitute alternative semantic versioning strategies, compatibility theories, or inferred conventions.
The skill exists to keep version changes:
Use this skill whenever:
This skill covers these primary areas:
Code versioning in this skill includes:
Release versions MUST use the following exact format:
v1.2.3.4
| Segment | Meaning |
|---|---|
| 1 | Model change |
| 2 | Service or routine change |
| 3 | Bug fix or configuration change |
| 4 | Automated build version |
These meanings are fixed for this skill and MUST NOT be reinterpreted.
A release version MUST remain in the exact v1.2.3.4 shape.
A model change MUST increment segment 1 and MUST reset segments 2, 3, and 4 to zero.
A service or routine change MUST increment segment 2 and MUST reset segments 3 and 4 to zero.
A bug fix or configuration change MUST increment segment 3 and MUST reset segment 4 to zero.
A new automated build for the same code MUST increment segment 4 only.
If multiple change types occur together, the highest-order change MUST win and all lower segments MUST reset to zero.
Given current version:
v1.2.3.4
Expected next versions:
v2.0.0.0v1.3.0.0v1.2.4.0v1.2.3.5v2.0.0.0Use the release version to describe what kind of change happened, not merely that a change happened.
That means:
A file without a version folder is treated as V0.
Examples:
Models/Foundations/Students/Student.cs
Services/Foundations/Students/StudentService.cs
Models/Foundations/Students/Exceptions/
This means the starting shape is unversioned on disk, but version zero is still logically assumed.
When a model changes, a new versioned file MUST be created under a version folder that is a subfolder of the original location.
Example:
Models/Foundations/Students/V1/StudentV1.cs
This pattern means:
V1 folderWhen a service changes, a new versioned service MUST be created under a version folder that is a subfolder of the original location.
Example:
Services/Foundations/Students/V1/StudentV1Service.cs
Related exceptions MUST align with the matching versioned model path.
Example:
Models/Foundations/Students/V1/Exceptions/
No version folder means V0 is implied.
A new version MUST be introduced by creating new versioned files and folders, not by overwriting the earlier implementation.
A model change MUST produce a versioned model file under a Vn subfolder.
A service change MUST produce a versioned service file under a Vn subfolder.
Versioned exceptions MUST live beneath the corresponding versioned model path.
Existing earlier-version code MUST remain available unless there is an explicit deprecation/removal strategy outside the introduction of the new version.
Versioned file/type naming MUST follow this pattern:
{Entity}V{n}.cs{Entity}V{n}Service.csExamples:
StudentV1.csStudentV1Service.csThe initial API is exposed without a version prefix:
api/Students
This is the route for V0.
If the model changes, the route MUST surface the model version:
api/V1/Students
Here, V1 tells the consumer that this endpoint represents the version 1 model.
If the model is already at version 1 and the service behavior changes for that model, the route MUST surface both the model version and the behavior version:
api/V1.1/Students
In this shape:
1 before the dot denotes the model version1 after the dot denotes the behavior/service versionThis is a model + behavior pairing and MUST be interpreted that way.
If only behaviour changed but the model stayed the same, the new route will be api/V0.1/Students — the model version is still 0, but the behavior version has incremented to 1.
api/{resource} denotes V0.
api/Vn/{resource} denotes model version n.
api/Vn.m/{resource} denotes model version n with behavior version m.
A route version MUST communicate the intended model and behavior pairing.
The API route MUST remain aligned with the versioning story of the underlying model/service pair.
Starting point:
api/Students
After model change:
api/V1/Students
After additional service behavior change for the V1 model:
api/V1.1/Students
Deprecation MUST be clear enough that consumers can see:
Consumers MUST be given enough time to act before the deprecated version is sunset.
A valid approach is to surface deprecation metadata through headers or attributes that emit those headers.
Example using a controller action attribute:
[ApiController]
[Route("api/[controller]")]
public class SampleController : ControllerBase
{
[HttpGet]
[DeprecatedApi(
Sunset = "2024-12-31",
Warning = "This API is deprecated. Please migrate to v2.",
Link = "https://example.com/deprecation-info")]
public IActionResult GetSampleData()
{
return Ok(new { message = "Sample data" });
}
}
| Package | Purpose |
|---|---|
Attrify | A NuGet library for controlling API visibility and lifecycle (e.g. deprecation) through attributes applied to controllers and actions |
Code that is no longer maintained or supported SHOULD be marked with:
[Obsolete("This version is deprecated and no longer maintained.")]
Use the obsolete marker to make deprecation visible to maintainers and consumers at compile time.
Capabilities are recommended so consumers can discover what is supported in each version before invoking a feature.
This is especially useful where model versions and service behaviors differ by version or by provider.
A capabilities surface should help consumers discover:
Capabilities MAY be exposed through:
In a provider-based architecture such as a SPAL provider, each concrete provider can expose a capabilities endpoint that tells consumers which operations are supported.
This pattern allows consumers to safely determine whether a provider supports a given operation before invoking it, avoiding runtime failures.
[AttributeUsage(AttributeTargets.Method, AllowMultiple = false, Inherited = true)]
public sealed class StudentOperationAttribute : Attribute
{
public string OperationName { get; }
public StudentOperationAttribute(string operationName) =>
OperationName = operationName ?? string.Empty;
public StudentOperationAttribute() =>
OperationName = string.Empty;
}
public sealed class ResourceCapabilities
{
public string ResourceName { get; init; } = string.Empty;
public IReadOnlyCollection<string> SupportedOperations { get; init; } =
Array.Empty<string>();
}
public sealed class ProviderCapabilities
{
public string ProviderName { get; init; } = string.Empty;
public IReadOnlyCollection<ResourceCapabilities> SupportedResources { get; init; } =
Array.Empty<ResourceCapabilities>();
}
public interface IStudentProvider
{
string ProviderName { get; }
ProviderCapabilities Capabilities { get; }
IStudentResource Students { get; }
}
public interface IStudentResource
{
ValueTask<Student> AddAsync(Student student);
}
public abstract class StudentProviderBase : IStudentProvider
{
public abstract string ProviderName { get; }
public abstract IStudentResource Students { get; }
public virtual ProviderCapabilities Capabilities =>
new ProviderCapabilities
{
ProviderName = ProviderName,
SupportedResources = new[]
{
new ResourceCapabilities
{
ResourceName = "Student",
SupportedOperations = GetSupportedOperations(Students)
}
}
};
private static IReadOnlyCollection<string> GetSupportedOperations(object resource)
{
if (resource is null)
return Array.Empty<string>();
return resource.GetType()
.GetMethods()
.Select(method =>
method.GetCustomAttributes(typeof(StudentOperationAttribute), true)
.FirstOrDefault() as StudentOperationAttribute)
.Where(attribute => attribute is not null)
.Select(attribute => attribute!.OperationName)
.Where(name => !string.IsNullOrWhiteSpace(name))
.Distinct()
.ToArray();
}
}
public sealed class StudentResource : IStudentResource
{
[StudentOperation("Add")]
public ValueTask<Student> AddAsync(Student student)
{
return ValueTask.FromResult(student);
}
}
public sealed class StudentProvider : StudentProviderBase
{
public override string ProviderName => "DefaultStudentProvider";
public override IStudentResource Students { get; } = new StudentResource();
}
public static class StudentProviderCapabilitiesExtensions
{
public static bool SupportsOperation(
this IStudentProvider provider,
string resourceName,
string operationName)
{
var resource = provider.Capabilities.SupportedResources
.FirstOrDefault(r => r.ResourceName == resourceName);
if (resource is null)
return false;
return resource.SupportedOperations.Contains(operationName);
}
}
IStudentProvider provider = new StudentProvider();
if (!provider.SupportsOperation("Student", "Add"))
{
// avoid call
return;
}
await provider.Students.AddAsync(new Student());
Capabilities turn runtime uncertainty into a deterministic check:
This aligns with the Standard principle:
Avoid invalid operations rather than reacting to them