본문으로 건너뛰기

ADR —

  • Status: proposed | accepted | informational | superseded by ADR-XXXX | rejected
  • Date: YYYY-MM-DD
  • Spec target: XTL 0.x
  • Affects: language.md | evaluation.md | new section | impl-only

Context​

What problem motivates this decision? What constraint is currently under-specified, ambiguous, or in conflict?

Considered Options​

Brief comparison of the realistic alternatives. List each, with the strongest argument for and against.

Decision​

The chosen option, stated in normative language. Quote the exact spec text that should change, where possible.

Consequences​

What does this commit the spec to? What follow-up work does it imply (impl changes, fixtures, deprecations)? What does it explicitly not commit to?

References​

Links to related ADRs, issues, or external precedent.

Status values​

  • proposed — under discussion; impl MAY anticipate but spec is not yet binding.
  • accepted — normative; impl and conformance corpus reflect it.
  • process-normative — accepted, but binds only the ADR pipeline and authoring discipline (not runtime impl). Future ADR authors MUST honor it; impl authors need not. ADR-0043 and ADR-0048 take this status. (Added 2026-05-18 to replace the earlier compound accepted (informational + process-level normative) phrasing.)
  • informational — non-normative documentation, audit, or process. Does not bind impl behavior or future ADR authors.
  • superseded by ADR-NNNN — replaced (in whole or part) by a later decision. Both ADRs remain in the corpus for traceability.
  • rejected — considered and explicitly NOT adopted; kept for the historical record so the option does not get reproposed without new context.