xdrs-core 0.37.2 → 0.38.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
|
@@ -65,6 +65,7 @@ Policy documents are the authoritative source of truth for their scope, type, an
|
|
|
65
65
|
- The `### Details` section SHOULD state relevant boundaries or exceptions and what a reader SHOULD do or avoid in common cases. Use the frontmatter fields `apply-to` and `valid-from` as the first-pass filter for applicability, then keep nuanced boundaries in the decision text.
|
|
66
66
|
- Use concise rules, examples, `Allowed` / `Disallowed` lists or checklists with required items to help the reader apply the decision correctly. Keep them short and decision-specific.
|
|
67
67
|
- Policies MUST NOT include historical change notes or descriptions of what changed from a previous version. State only the current rule that MUST be followed. Historical context is available via git history or versioned packages.
|
|
68
|
+
- The `valid-from` field MUST NOT be updated automatically when a Policy is changed. It reflects the original enforcement date and MUST remain unchanged throughout the Policy's lifetime. Only update it intentionally when explicitly changing the enforcement start date as a deliberate decision.
|
|
68
69
|
- When a policy covers elements that could be confused with each other, include explicit disambiguation statements clarifying the distinction before stating the rules for each.
|
|
69
70
|
- A "why" explanation for a policy rule MAY only be included if it is brief, non-obvious, relevant to the reader, and not longer than the rule itself.
|
|
70
71
|
- Rules MUST focus on what is required or forbidden. Explanations of why a rule exists belong in a Research document, not in the Policy itself. Link to the relevant research when the rationale is important for adoption.
|
|
@@ -63,6 +63,14 @@ A scope that is governed by a `core` scope MUST declare this relationship explic
|
|
|
63
63
|
|
|
64
64
|
A `core`-type scope MAY be distributed to consumers alongside the companion consumable scope, or kept internal to the team that maintains the domain. When distributed, consumers who extend or contribute to the domain scope locally MUST follow its standards. When not distributed, internal contributors MUST still comply.
|
|
65
65
|
|
|
66
|
+
#### 08-unavailable-core-read-only
|
|
67
|
+
|
|
68
|
+
A `-core` scope referenced via `follows:` in a companion scope's `index.md` may not be present in the workspace of a consumer of that companion scope. When the referenced `-core` scope is absent, the companion scope MUST be treated as READ-ONLY: no content in it MUST be added, changed, or removed. The scope lacks the meta governance that defines how its content must be authored, and modifications without those standards would produce non-compliant content. Tools and agents MUST NOT propose or apply changes to a READ-ONLY scope and MUST surface the read-only status to the user when the scope is accessed.
|
|
69
|
+
|
|
70
|
+
#### 09-distribution-advisable
|
|
71
|
+
|
|
72
|
+
Distributing `-core` scopes alongside their companion consumable scope to downstream consumers SHOULD be done when possible. Having the meta governance available locally allows tools, agents, and contributors to reason about authoring standards, validate content, and apply scope-local conventions correctly. Distribution is not mandatory; the companion scope remains valid and usable in READ-ONLY mode when the `-core` scope is absent (see `08-unavailable-core-read-only`).
|
|
73
|
+
|
|
66
74
|
## References
|
|
67
75
|
|
|
68
76
|
- [_core-adr-policy-010 - Scope governance](010-scope-governance.md) — full scope governance model including when to prefer a `{scope-name}-core` policy (scope-local) vs. this pattern
|