Decorator Proposal: Code Location

### Target Schema:

New file: `decorators/code-location/code-location.decorator.standard.json` (extends `meta/decorators.json`)

### Description of Change:

Add a new **Code Location** decorator that captures where source code is physically hosted for architecture elements.

**Background:** Organisations manage source code across a variety of platforms (GitHub, GitLab, Bitbucket, Azure DevOps) and version control systems (Git, SVN, CVS). Teams working in regulated industries often operate in multi-platform environments — acquired businesses may use different tooling, internal teams may run self-hosted GitLab while open-source work lives on GitHub, and legacy systems may still rely on SVN or CVS. Capturing this information consistently against architecture elements enables traceability from design to code, supports compliance reporting, and helps teams discover where systems actually live.

### Use Cases:

1. **Traceability** — Link architecture nodes to their source repositories so reviewers and auditors can trace design decisions to implementation.
2. **Multi-platform discovery** — In organisations with code spread across GitHub, GitLab, Bitbucket, and Azure DevOps, provide a single consistent view of where each system's code lives.
3. **Legacy VCS support** — Capture location for systems still under SVN or CVS, not just Git.
4. **Onboarding** — New team members can navigate from an architecture diagram directly to the relevant repository.

### Current Limitations:

The CALM schema has no standard way to record where the source code for an architecture element is hosted. Teams either omit this information entirely or embed ad-hoc links in descriptions or custom properties, leading to inconsistency and no tooling support.

### Proposed Schema Changes:

```json
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"$id": "https://calm.finos.org/draft/2026-03/standards/code-location/code-location.decorator.standard.json",
"title": "CALM Code Location Decorator Standard",
"allOf": [
{
"$ref": "https://calm.finos.org/draft/2026-03/meta/decorators.json#/defs/decorator"
},
{
"type": "object",
"properties": {
"type": { "const": "code-location" },
"target-type": {
"type": "array",
"items": {
"type": "string",
"enum": ["architecture"]
}
},
"data": {
"type": "object",
"properties": {
"repository-type": {
"type": "string",
"enum": ["git", "svn", "cvs"],
"description": "The version control system used."
},
"repository-instance": {
"type": "string",
"enum": ["github", "gitlab", "bitbucket", "azure-devops", "other"],
"description": "The hosting platform."
},
"url": {
"type": "string",
"format": "uri",
"description": "Browsable URL to the repository or project."
},
"clone-url": {
"type": "string",
"format": "uri",
"description": "URL used to clone the repository (optional)."
}
},
"required": ["repository-type", "repository-instance", "url"],
"additionalProperties": false
}
},
"required": ["type", "target-type", "data"]
}
]
}
```

### Backward Compatibility:

- **No breaking changes.** This is a new additive decorator standard.
- Existing CALM documents remain valid — code-location is entirely opt-in.
- No migration required for existing documents.

### Validation Strategy:

- Example decorator documents that validate against the new schema (GitHub, GitLab, Bitbucket/SVN examples).
- Schema itself validates against JSON Schema 2020-12.
- Extend existing CLI `calm validate` to recognise decorator documents in future tooling work.

### Implementation Impact:

- **Existing tools**: No impact — this is a new standard. Future tooling can choose to consume it.
- **Documentation**: Add code-location to the standards listing in the draft 2026-03 README.
- **Related schemas**: References `meta/decorators.json` base schema only — no changes to other schemas required.

### Version Strategy:

- **Minor addition** to the existing draft 2026-03 specification.
- No new draft version required — this fits alongside the existing deployment decorator standard.

### Implementation Checklist:

- [ ] Schema changes drafted and validated
- [ ] Example documents created that validate against the new schema
- [ ] Tests written to verify schema behavior
- [ ] Documentation updated to reflect changes
- [ ] Migration guide created (if applicable)
- [ ] Related schemas updated (if applicable)

### Additional Context:

This standard follows the same pattern as the existing deployment decorator standard (`standards/deployment/`), using the base decorator schema with constrained `type`, `target-type`, and a typed `data` object.
There is still open question on whether standards will be considered as part of core schema or not

Fields:
| Field | Required | Description |
|---|---|---|
| `repository-type` | Yes | `git`, `svn`, or `cvs` |
| `repository-instance` | Yes | `github`, `gitlab`, `bitbucket`, `azure-devops`, or `other` |
| `url` | Yes | Browsable URL to the repository |
| `clone-url` | No | URL used to clone the repository |