xdrs-core 0.2.9-beta.0 → 0.2.12

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.
@@ -16,53 +16,46 @@ categorizing findings by severity and type, and reporting them without modifying
16
16
 
17
17
  ## Instructions
18
18
 
19
- ### Phase 1: XDR Compilation
19
+ ### Phase 1: Code Gathering
20
+
21
+ 1. Identify changes based on requested scope:
22
+ - For diffs: run and parse `git diff origin/main`
23
+ - For files: analyze file contents directly
24
+
25
+ ### Phase 2: XDR Compilation
20
26
 
21
27
  1. Gather all Decision Records from `.xdrs/index.md` starting from the working directory.
22
28
  - XDR scopes are controlled by nested folders; some are broad, others domain-specific.
23
29
  - Extract metadata first (status, impact, scope, applicability) to filter relevant XDRs before deep analysis.
24
30
  2. Filter relevance based on file types, domains, and architectural patterns in scope.
25
31
 
26
- ### Phase 2: Code Analysis
32
+ ### Phase 3: XDR Review
27
33
 
28
- 1. Identify changes based on requested scope:
29
- - For diffs: run and parse `git diff origin/main`
30
- - For files: analyze file contents directly
31
- - For services: scan all files in the service directory
32
- 2. Categorize potential findings:
33
- - Architecture: violations of structural decisions
34
- - Coding Standards: style and pattern violations
35
- - Testing: missing or inadequate test coverage
36
- - Documentation: missing or outdated documentation
37
- - Security: security practice violations
38
- - Performance: performance best practice violations
39
- 3. Compile specific, measurable rules from each XDR and compare against the changes.
40
- 4. Prioritize by criticality: Accepted > Proposed; Impact: critical > high > medium > low.
41
-
42
- ### Phase 3: Review and Judgment
43
-
44
- 1. Cross-reference each finding against applicable XDRs.
34
+ 1. Cross-reference each file in scope against applicable XDRs.
45
35
  - **Drop any finding that cannot be traced to a specific rule in an Accepted XDR.** General good-practice observations, personal opinions, or inferred issues without an explicit XDR backing must not be reported.
46
36
  - Classify as ERROR (mandatory) or WARNING (advisory).
47
37
  - Include: location, description, XDR reference (file + line), suggestion.
48
38
  2. Reduce false positives:
49
- - Re-evaluate ERROR findings for mandatory language in the XDR ("must", "always", "never", "required", "mandatory"). Drop or downgrade to WARNING if the language is advisory ("should", "recommended", "advised").
39
+ - Evaluate ERROR findings for mandatory language in the XDR ("must", "always", "never", "required", "mandatory"). Drop or downgrade to WARNING if the language is advisory ("should", "recommended", "advised").
50
40
  - Remove findings unrelated to actual changes.
51
41
  - Consolidate duplicates.
52
42
  - Consider context (existing style, legacy sections, etc.).
43
+ 3. For related XDRs and files, lookup for the specific line number in both the XDR and the code that are related to the finding. This will be used in the reporting phase to provide precise references and actionable suggestions.
44
+
45
+ ### Phase 4: Judgment
53
46
  3. Judgment criteria (all must be true to keep a finding):
54
- - Is the violation explicitly stated in an Accepted XDR? (If no, drop it.)
47
+ - Is the violation explicitly stated as a rule in an Accepted XDR using mandatory or advisory language? Templates, examples, and diagrams in XDRs are illustrative only — they do not constitute rules. If the only evidence for the violation is an implicit pattern in a code sample or template, drop it.
55
48
  - Is there concrete evidence in the code or diff?
56
49
  - Is the finding actionable?
57
50
  - Would fixing it meaningfully improve compliance with the XDR?
58
51
 
59
- ### Phase 4: Reporting
52
+ ### Phase 5: Reporting
60
53
 
61
54
  Format each finding as:
62
55
 
63
56
  ```
64
- >> [ERROR|WARNING] [CATEGORY] filename:line_number: Description
65
- - XDR Reference: .xdrs/scope/type/subject/number-title.md:line_number
57
+ >> [ERROR|WARNING] [CATEGORY] [filename:line_number](filename#Lline_number): Description
58
+ - XDR Reference: [.xdrs/scope/type/subject/number-title.md:line_number](.xdrs/scope/type/subject/number-title.md#Lline_number)
66
59
  - Rule: Specific rule text from XDR
67
60
  - Severity: [ERROR|WARNING]
68
61
  - Suggestion: Specific action to fix this issue
@@ -86,7 +79,7 @@ Changes: [+X lines, -Y lines]
86
79
  - Review Status: [PASS|FAIL]
87
80
 
88
81
  Affected Files Requiring Changes
89
- [bullet list of files with issues, linked to specific findings and severity]
82
+ [bullet list of files with markdown links to specific findings and severity]
90
83
  ```
91
84
 
92
85
  ### Constraints
@@ -16,23 +16,18 @@ Clear behavior standards ensure consistency through EDR compliance, maintain cod
16
16
 
17
17
  **Mandatory behaviors for AI coding agents:**
18
18
 
19
- 1. **Follow instruction hierarchy when making implementation decisions**
20
- 1. **Closest AGENTS.md** to the file being changed (search from target directory up to workspace root). Instructions in those files override the global EDRs. If multiple AGENTS.md files exist in the path, merge their instructions; the closest AGENTS.md overrides those farther away.
21
- 2. **Global EDR** Follow scope-based precedence defined in [.xdrs/index.md](../../../../index.md). EDRs in scopes listed last override EDRs in scopes listed first.
19
+ 1. **Always consult XDRs before making implementation decisions**
20
+ - Follow coding agent behavior and decision hierarchy rules in [.xdrs/_general/edrs/principles/001-coding-agent-behavior.md](.xdrs/_general/edrs/principles/001-coding-agent-behavior.md)
21
+ - Search for XDRs in [.xdrs/index.md](.xdrs/index.md) during design, plan and implementation steps
22
+ - Follow XDRs as the source of truth for all decisions and procedures
22
23
 
23
24
  2. **Verify all work with build, tests and linting before completion**
24
- - Check EDRs for workspace tooling: [.xdrs/index.md](../../../../index.md)
25
- - Run quality checks in sequence relative to the module directory: `STAGE=dev make build-module`, `make lint-module`, then `make test-module`
26
- - Use `make lint-fix` to fix lint issues
27
- - Do not run commands outside Makefiles
28
-
29
- 3. **Verify implementation complies with EDRs**
30
- - Review relevant EDRs before marking work complete
31
- - Ensure implementation decisions follow EDR guidelines and patterns
32
-
33
- 4. **Do not perform git operations**
34
- - Do not run git commands (add, commit, push, branch creation, etc.)
35
- - Inform the developer when work is ready for version control
25
+ - Always run `make build`, `make lint-fix` and `make test` at the end of the implementation
26
+ - Fix any issues
27
+
28
+ 3. **Verify if implementation complies with XDRs**
29
+ - Re-analyse your work against the XDRs and ensure implementation decisions follow guidelines and patterns
30
+
36
31
 
37
32
  ## Considered Options
38
33
 
package/.xdrs/index.md CHANGED
@@ -20,6 +20,14 @@ General engineering decisions covering cross-business standards and practices.
20
20
 
21
21
  ---
22
22
 
23
+ ### EDRs - agentkit
24
+
25
+ General engineering decisions from agentkit scope
26
+
27
+ [View agentkit EDRs Index](agentkit/edrs/index.md)
28
+
29
+ ---
30
+
23
31
  ### _local (reserved)
24
32
 
25
33
  Project-local XDRs that must not be shared with other contexts. Always keep this scope last so its decisions override or extend all scopes listed above. Add specific `_local` ADR/BDR/EDR index links here when present.
package/AGENTS.md CHANGED
@@ -8,6 +8,7 @@
8
8
  - Follow XDRs as the source of truth for all decisions and procedures
9
9
 
10
10
  2. **Verify all work with build, tests and linting before completion**
11
+ - Always run `make build`, `make lint-fix` and `make test` at the end of the implementation
11
12
  - Fix any issues
12
13
 
13
14
  3. **Verify if implementation complies with XDRs**
package/bin/npmdata.js CHANGED
@@ -1,4 +1,3 @@
1
1
  #!/usr/bin/env node
2
-
3
- // DON'T EDIT THIS FILE MANUALLY - this script is generated by "npmdata init" command
4
- require('npmdata/dist/runner.js').run(__dirname);
2
+ 'use strict';
3
+ require('npmdata').binpkg(__dirname, process.argv.slice(2));
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "xdrs-core",
3
- "version": "0.2.9-beta.0",
3
+ "version": "0.2.12",
4
4
  "description": "A standard way to organize Decision Records (XDRs) across scopes, subjects, and teams so that AI agents can reliably query and follow them.",
5
5
  "repository": {
6
6
  "type": "git",
@@ -20,35 +20,37 @@
20
20
  "bin/npmdata.js"
21
21
  ],
22
22
  "dependencies": {
23
- "npmdata": "^0.10.3"
23
+ "npmdata": "^0.13.0"
24
+ },
25
+ "npmdata": {
26
+ "sets": [
27
+ {
28
+ "package": "xdrs-core",
29
+ "outputDir": ".",
30
+ "files": [
31
+ "AGENTS.md",
32
+ ".xdrs/**",
33
+ "!.xdrs/index.md"
34
+ ],
35
+ "symlinks": [
36
+ {
37
+ "source": ".xdrs/**/skills/*",
38
+ "target": "./.github/skills"
39
+ }
40
+ ],
41
+ "gitignore": false
42
+ },
43
+ {
44
+ "package": "xdrs-core",
45
+ "outputDir": ".",
46
+ "files": [
47
+ ".xdrs/index.md"
48
+ ],
49
+ "gitignore": false,
50
+ "unmanaged": true,
51
+ "keepExisting": true
52
+ }
53
+ ]
24
54
  },
25
- "npmdata": [
26
- {
27
- "package": "xdrs-core",
28
- "outputDir": ".",
29
- "files": [
30
- "AGENTS.md",
31
- ".xdrs/**",
32
- "!.xdrs/index.md"
33
- ],
34
- "symlinks": [
35
- {
36
- "source": ".xdrs/**/skills/*",
37
- "target": "./.github/skills"
38
- }
39
- ],
40
- "gitignore": false
41
- },
42
- {
43
- "package": "xdrs-core",
44
- "outputDir": ".",
45
- "files": [
46
- ".xdrs/index.md"
47
- ],
48
- "gitignore": false,
49
- "unmanaged": true,
50
- "keepExisting": true
51
- }
52
- ],
53
55
  "bin": "bin/npmdata.js"
54
56
  }