AyCode.Core/AyCode.Services/docs/adr/README.md

Architecture Decision Records (ADRs)

Project-scoped Architecture Decision Records for AyCode.Services — design decisions specific to this project's internal architecture (binary hub protocol composition, SignalR client design, etc.). Repo-wide cross-cutting decisions live in AyCode.Core/docs/adr/, not here.

See .github/skills/adr-author/SKILL.md for the full authoring procedure (routing rules, Socratic interview, trade-off elicitation, draft → review → write).

Convention

• Format: Nygard-style ADR; one file per decision.
• Filename: NNNN-<slug>.md — zero-padded 4-digit sequence + kebab-case slug derived from the title (e.g. 0001-acbinary-decorator-feature-stack-design.md).
• Numbering: sequential, append-only. Derive next NNNN from max(existing) + 1 at write time.
• Template: copy 0000-TEMPLATE.md when starting a new ADR.
• Status field: Proposed (YYYY-MM-DD) → Accepted (YYYY-MM-DD) / Rejected (YYYY-MM-DD) / Superseded by ADR-XXXX (YYYY-MM-DD). Update in-place; entry body / ID / Decision text remain immutable.

Index

ID	Title	Status
0001	AcBinaryHubProtocol optional feature stack — decorator-based composition design	Proposed (2026-04-25)

Related

• Repo-wide cross-cutting decisions: AyCode.Core/docs/adr/.
• Protocol-meta decisions (rule changes, skill additions, instruction-file structural shifts): .github/LLM_PROTOCOL_DECISIONS.md.
• Topic-level cross-references for AcBinaryHubProtocol-specific ADRs surface in SIGNALR_BINARY_PROTOCOL/README.md under ## Related ADRs (added in Step 8 of the adr-author skill — separate mehet round).