# XCUT — Cross-cutting issues and TODOs

Canonical home for issues, TODOs, bugs, and critical items that span **two or more topics** (e.g., BINARY + SIGNALR, LOGGING + SIGNALR, BINARY + TOON).

## When to use `XCUT-*-N` vs a topic-specific ID

- **Single topic** (concern, bug, or planned work inside one domain) → `ACCORE-{TOPIC}-{TYPE}-{XXXX}` in that topic's `{TOPIC}_ISSUES.md` / `{TOPIC}_TODO.md` (e.g., `ACCORE-LOG-I-X7Q1` in `LOGGING_ISSUES.md`).
- **Two or more ACCORE topics** (coordinated change needed across domains, or the issue's root cause spans multiple subsystems) → `ACCORE-XCUT-{TYPE}-{XXXX}` here, with cross-references from each affected topic's file.

## Examples of cross-cutting items

- **`ACCORE-XCUT-I-X8Q1: JSON-in-Binary request parameters`** — affects both the BINARY serializer (wire format) and SIGNALR transport (envelope). Neither side can fix it alone; it needs a coordinated client+server+consumer migration.
- *(hypothetical)* `ACCORE-XCUT-T-XXXX` for a shared infrastructure refactor that touches Logger, SignalR, and SourceGenerator simultaneously.
- *(hypothetical)* `ACCORE-XCUT-B-XXXX` for a bug where the symptom appears in one topic but the root cause lives in another.

## Files in this folder

- [`XCUT_ISSUES.md`](XCUT_ISSUES.md) — cross-cutting known issues (canonical entries)
- [`XCUT_TODO.md`](XCUT_TODO.md) — cross-cutting planned work (canonical entries)

## Cross-reference convention

1. **Canonical entry** lives here. Full body: status, affects (list of topics), rationale, migration plan.
2. **Each affected topic** adds a short `### ACCORE-XCUT-{TYPE}-{XXXX}: <title> — cross-ref` section in its own `_ISSUES.md` / `_TODO.md`, pointing back to this canonical entry (with the SAME 4-char suffix as the canonical, since cross-ref pointers are pointers — not duplicate IDs).
3. The **topic-specific cross-ref** body is one sentence: "See canonical entry at `../XCUT/XCUT_ISSUES.md#accore-xcut-{type}-{xxxx}`" + a 1-2 line summary of what this topic contributes.

## How `ACCORE-XCUT-*` IDs are formed

Per the `REPO_PREFIXES.md` and `TOPIC_CODES.md` registries:
- Format: `ACCORE-XCUT-<TYPE>-<RAND>` where `<TYPE>` is `I` (issue), `T` (TODO), `B` (bug), or `C` (critical), and `<RAND>` is a random 4-character `[A-Z0-9]` suffix.
- All ACCORE cross-cutting issues live in the `ACCORE-XCUT-I-*` namespace, regardless of which topics they span. Same for TODOs (`ACCORE-XCUT-T-*`), bugs (`ACCORE-XCUT-B-*`), critical-severity (`ACCORE-XCUT-C-*`).
- Append-only — once assigned, IDs never change. The random suffix avoids collisions across parallel branches; uniqueness is verified at creation per `REPO_PREFIXES.md` "Random suffix spec".

## Historical note

Before this folder existed, cross-cutting entries were duplicated in each affected topic's file (e.g., `XCUT-1` in both `BINARY_ISSUES.md` and `SIGNALR_ISSUES.md`). The canonical-home pattern replaces that — one authoritative entry, short cross-refs from each affected topic.

## See also

- **Registry** (topic codes, type codes, ID format rules): `../../../.github/skills/docs-check/references/TOPIC_CODES.md`
- **Decision Log** (why this folder exists): `../../../.github/LLM_PROTOCOL_DECISIONS.md` — entry "XCUT consolidation to dedicated folder".
