agentme 0.25.0 → 0.25.2

package/.filedist-package.yml

@@ -1,5 +1,5 @@
 sets:
-  - package: xdrs-core@0.37.2
+  - package: xdrs-core@0.38.3
   # - package: git:https://github.com/flaviostutz/xdrs-core.git@main
     selector:
       files:

package/.xdrs/agentme/edrs/application/019-ai-agents-development-standards.md

@@ -108,11 +108,11 @@ When agents are used as nodes in workflows, the node name MUST use the `_agent`
 
 #### 05-agent-composition
 
-When multiple agents are needed:
+When multiple agents are needed, one of these composition patterns MUST be chosen:
 
 - **Single agent with multiple tools:** Use when tools share a common goal and context (e.g., a code analysis agent with `read_file`, `search_code`, and `analyze_pattern` tools).
 - **Multiple agents as workflow nodes:** Use when agents have distinct responsibilities and outputs that feed into each other. Orchestrate them using LangGraph per [agentme-edr-021](021-ai-workflow-development-standards.md).
-- Do NOT create nested agent loops (agent calling agent autonomously). Use workflows for multi-agent orchestration.
+- Nested agent loops (agent calling agent autonomously) MUST NOT be created. Use workflows for multi-agent orchestration.
 
 **Decision criteria:**
 

package/.xdrs/agentme/edrs/application/021-ai-workflow-development-standards.md

@@ -37,7 +37,7 @@ Use **MLflow** for all workflow observability and evaluation:
 
 #### 04-dataset-driven-accuracy-measurement
 
-Eval dataset and implementation requirements are defined in [agentme-edr-028](028-ai-eval-standards.md). Testing requirements (when evals are required, release gates) are defined in [agentme-edr-007](../principles/007-project-quality-standards.md) rule `09-ai-project-testing-requirements`.
+Projects MUST follow the eval dataset and implementation requirements defined in [agentme-edr-028](028-ai-eval-standards.md). Testing requirements (when evals are required, release gates) are defined in [agentme-edr-007](../principles/007-project-quality-standards.md) rule `09-ai-project-testing-requirements`.
 
 #### 05-flow-documentation
 
@@ -101,11 +101,11 @@ lib/src/<package_name>/
 
 #### 08-workflow-evals
 
-Eval folder structure and script requirements are defined in [agentme-edr-028](028-ai-eval-standards.md).
+Projects MUST follow the eval folder structure and script requirements defined in [agentme-edr-028](028-ai-eval-standards.md).
 
 #### 09-node-naming-conventions
 
-See [agentme-edr-029](029-ai-workflow-naming-conventions.md) rule `01-node-naming-conventions`.
+Nodes MUST follow the naming conventions defined in [agentme-edr-029](029-ai-workflow-naming-conventions.md) rule `01-node-naming-conventions`.
 
 #### 10-workflow-unit-testing
 
@@ -159,15 +159,15 @@ Workflows MUST accept the LLM instance as a constructor parameter so that unit t
 
 #### 11-state-type-conventions
 
-See [agentme-edr-029](029-ai-workflow-naming-conventions.md) rule `02-state-type-conventions`.
+State types MUST follow the conventions defined in [agentme-edr-029](029-ai-workflow-naming-conventions.md) rule `02-state-type-conventions`.
 
 #### 12-workflow-naming-conventions
 
-See [agentme-edr-029](029-ai-workflow-naming-conventions.md) rule `04-workflow-naming-conventions`.
+Workflows MUST be named following the conventions in [agentme-edr-029](029-ai-workflow-naming-conventions.md) rule `04-workflow-naming-conventions`.
 
 #### 13-judge-node-output-format
 
-See [agentme-edr-029](029-ai-workflow-naming-conventions.md) rule `03-judge-node-output-format`.
+Judge nodes MUST use the output format defined in [agentme-edr-029](029-ai-workflow-naming-conventions.md) rule `03-judge-node-output-format`.
 
 #### 15-workflow-state-persistence
 
@@ -200,7 +200,7 @@ result = graph.invoke(input_state, config={"thread_id": "session-123"})
 
 #### 16-cross-element-naming-coherence
 
-See [agentme-edr-029](029-ai-workflow-naming-conventions.md) rule `05-cross-element-naming-coherence`.
+All workflow elements MUST maintain naming coherence as defined in [agentme-edr-029](029-ai-workflow-naming-conventions.md) rule `05-cross-element-naming-coherence`.
 
 ## References
 

package/.xdrs/agentme/edrs/application/026-pragmatic-hexagonal-architecture.md

@@ -21,7 +21,7 @@ How should application source code be organized to separate business logic from
 
 #### 01-three-layer-separation
 
-Every application is conceptually divided into three layers:
+Every application MUST be organized into these three conceptual layers:
 
 | Layer | Description |
 |-------|-------------|
@@ -31,6 +31,8 @@ Every application is conceptually divided into three layers:
 
 #### 02-adapter-naming-conventions
 
+Adapters MUST follow these naming conventions:
+
 **Inbound adapters** receive external requests or events and trigger application logic. Each gets a flat folder under `adapters/`:
 
 - `cli/` — command-line interface entry point
@@ -50,7 +52,7 @@ Every application is conceptually divided into three layers:
 #### 03-application-layer-rules
 
 - Expose functionality as typed library interfaces
-- All inputs must be explicitly passed as typed parameters
+- All inputs MUST be explicitly passed as typed parameters
 - No global variables, no direct environment variable access in `app/` or `shared/`
 - Business logic with well-defined input/output behavior
 - Group related logic into subfolders (aggregation roots)
@@ -66,6 +68,8 @@ Kafka message →  adapters/kafka/    →  app/process-event   →  adapters/con
 
 #### 04-mandatory-folder-structure
 
+All projects MUST follow this folder structure:
+
 ```text
 mysystem/
   Makefile             # targets to run different inbound interfaces (e.g. run-http, run-cli)
@@ -97,7 +101,7 @@ mysystem/
 
 #### 06-bootstrap-and-entry-points
 
-- Each inbound adapter folder (`cli/`, `http/`, `grpc/`, etc.) contains the bootstrap and entry point for that interface
+- Each inbound adapter folder (`cli/`, `http/`, `grpc/`, etc.) MUST contain the bootstrap and entry point for that interface
 - The project root Makefile must have targets to run the different inbound interfaces following [agentme-edr-008](../devops/008-common-targets.md) extension conventions (e.g. `run-http`, `run-grpc`)
 - Bootstrap code lives in the adapter that receives inbound requests, not in a separate wiring layer
 

package/.xdrs/agentme/edrs/application/030-ai-test-types-taxonomy.md

@@ -21,7 +21,7 @@ Each test type is named with its group, objective, mocking constraint, applicabi
 
 #### 01-golden-dataset-concept
 
-A **golden dataset** comprises all eval case entries used to test an AI component (LLM, Agent, or Workflow tier); each entry is labeled with the `test_types` (rule `04`) it applies to. It is the dataset consumed by [agentme-edr-028](028-ai-eval-standards.md) evals and stored as one JSON file per entry per [agentme-edr-024](024-ml-dataset-structure.md) rule `04`, at `evals/<component>/eval-<name>/golden_dataset/`.
+Projects MUST use a golden dataset to test AI components. A **golden dataset** comprises all eval case entries used to test an AI component (LLM, Agent, or Workflow tier); each entry is labeled with the `test_types` (rule `04`) it applies to. It is the dataset consumed by [agentme-edr-028](028-ai-eval-standards.md) evals and stored as one JSON file per entry per [agentme-edr-024](024-ml-dataset-structure.md) rule `04`, at `evals/<component>/eval-<name>/golden_dataset/`.
 
 #### 02-golden-dataset-entry-envelope
 
@@ -61,6 +61,8 @@ A golden dataset entry's `test_types` array MUST only use these values: `safety`
 
 #### 05-test-type-taxonomy
 
+Test types MUST be selected from this taxonomy. Each test type is named with its group, objective, mocking constraint, applicability, and relevance:
+
 | Test Type Name | Group | Test Objective | Mocks Allowed | When to Apply | Relevance – Business | Relevance – Development Team | Priority (1-5) |
 |---|---|---|---|---|---|---|---|
 | Safety/content eval | Safety & adversarial | Detect harmful, biased, or policy-violating output | mocks disallowed for LLM calls | Any user-facing release | Avoids reputational harm; acceptable-use compliance | Automated content gate before merge/release | 5 |
@@ -79,11 +81,11 @@ A golden dataset entry's `test_types` array MUST only use these values: `safety`
 
 #### 06-priority-and-relevance-are-descriptive-only
 
-Priority, Relevance, and When to Apply in rule `05` are guidance for prioritization conversations — they do NOT mandate which test types a project must implement, nor their thresholds. [agentme-edr-007](../principles/007-project-quality-standards.md) rule `09` remains the only tier-level testing requirement in force (Workflow unit tests + functional evals). Once a project chooses to implement and threshold a test type, [agentme-edr-028](028-ai-eval-standards.md) rule `02`'s failing-threshold behavior applies uniformly, regardless of this table's priority rating — a project may enforce fairness at 70% and functional at 90%, or skip fairness entirely; that choice is a project/business decision, not one this Policy makes.
+Priority, Relevance, and When to Apply in rule `05` are guidance for prioritization conversations — they MUST NOT be treated as mandating which test types a project must implement, nor their thresholds. [agentme-edr-007](../principles/007-project-quality-standards.md) rule `09` remains the only tier-level testing requirement in force (Workflow unit tests + functional evals). Once a project chooses to implement and threshold a test type, [agentme-edr-028](028-ai-eval-standards.md) rule `02`'s failing-threshold behavior applies uniformly, regardless of this table's priority rating — a project may enforce fairness at 70% and functional at 90%, or skip fairness entirely; that choice is a project/business decision, not one this Policy makes.
 
 #### 07-smoke-is-distinct-from-test-smoke
 
-The `smoke` test type (surfaced as the `eval-smoke` Makefile target, a fast subset of the golden-dataset functional eval) is a different concept from [agentme-edr-008](../devops/008-common-targets.md)'s existing `test-smoke` target (a fast subset of code-level tests). Both may exist in the same project; do not conflate them.
+The `smoke` test type (surfaced as the `eval-smoke` Makefile target, a fast subset of the golden-dataset functional eval) is a different concept from [agentme-edr-008](../devops/008-common-targets.md)'s existing `test-smoke` target (a fast subset of code-level tests). Both MAY exist in the same project; teams MUST NOT conflate them.
 
 ## References
 

package/.xdrs/agentme/edrs/devops/005-monorepo-structure.md

@@ -114,6 +114,8 @@ All releases **MUST** be tagged using the format `<module-name>/<semver>` (e.g.,
 
 #### 11-summary-of-requirements
 
+All requirements marked 'Yes' MUST be met. The table below summarizes the mandatory requirements:
+
 | Requirement | Scope | Mandatory |
 |---|---|---|
 | Lowercase folder/file names | All | Yes |

package/.xdrs/agentme/edrs/devops/006-github-pipelines.md

@@ -37,7 +37,7 @@ All workflows run on `ubuntu-latest`. Tool versions MUST be managed by Mise via
 
 File: `.github/workflows/ci.yml`
 
-Triggered on every PR targeting `main` and every push to `main`. Runs the standard `build`, `lint`, and `test` targets from the root Makefile and fails the workflow if any step exits non-zero.
+Projects MUST configure this workflow, triggered on every PR targeting `main` and every push to `main`. It runs the standard `build`, `lint`, and `test` targets from the root Makefile and fails the workflow if any step exits non-zero.
 
 ```yaml
 name: ci
@@ -67,7 +67,7 @@ jobs:
 
 File: `.github/workflows/release.yml`
 
-Manually dispatched (`workflow_dispatch`). Calculates the next semantic version tag using **monotag** and pushes that tag to the repository. Pushing the tag then automatically triggers the publish workflow.
+Projects MUST use this manually dispatched (`workflow_dispatch`) workflow. It calculates the next semantic version tag using **monotag** and pushes that tag to the repository. Pushing the tag then automatically triggers the publish workflow.
 
 The checkout step **must** use `fetch-depth: 0` so monotag can traverse the full commit history to determine the correct next version.
 
@@ -112,7 +112,7 @@ jobs:
 
 File: `.github/workflows/publish.yml`
 
-Triggered exclusively when a tag matching `v*.*.*` is pushed to the repository. This ensures only explicitly tagged commits produce published artifacts. Runs `make publish` against the tagged commit.
+Projects MUST configure this workflow, triggered exclusively when a tag matching `v*.*.*` is pushed to the repository. This ensures only explicitly tagged commits produce published artifacts. Runs `make publish` against the tagged commit.
 
 ```yaml
 name: publish

package/.xdrs/agentme/edrs/devops/008-common-targets.md

@@ -195,7 +195,7 @@ A developer can run `make test` at the repo root to test everything, or `cd modu
 
 #### 07-quick-reference
 
-Any project following this EDR supports the following actions through the root `Makefile`.
+Any project following this EDR MUST support the following actions through the root `Makefile`.
 
 ```sh
 # install the pinned toolchain and project bootstrap

package/.xdrs/agentme/edrs/devops/027-environment-variable-configuration.md

@@ -25,7 +25,7 @@ Secrets (API keys, passwords, tokens) must never be placed in `.env` files. Thos
 
 #### 01-when-to-use-dotenv
 
-Use a `.env` file when either of the following is true:
+A `.env` file MUST be used when either of the following is true:
 
 1. **Spawned process needs env vars** — the project launches a process (a deployable service, background worker, or shell script) that reads configuration from OS environment variables such as port numbers or API endpoint URLs.
 2. **Value must not be committed** — a configuration value used in a YAML config file (see rule 07) is environment-specific or sensitive enough to exclude from version control. In that case, store the value in `.env` and reference it from the YAML file using env var substitution (see rule 08).
@@ -43,13 +43,13 @@ FEATURE_FLAG_NEW_UI=false
 
 #### 02-dotenv-not-committed
 
-`.env` must be listed in `.gitignore` and must never be committed to the repository. It is intended for local use in standalone projects and libraries that do not have a formal deployment pipeline.
+`.env` MUST be listed in `.gitignore` and must never be committed to the repository. It is intended for local use in standalone projects and libraries that do not have a formal deployment pipeline.
 
 ---
 
 #### 03-dotenv-example-committed
 
-A `.env.example` file must be committed alongside `.env`. It contains all the same variable names with placeholder or illustrative values — no real URLs, credentials, or server names. This file documents what configuration is expected without exposing real values.
+A `.env.example` file MUST be committed alongside `.env`. It contains all the same variable names with placeholder or illustrative values — no real URLs, credentials, or server names. This file documents what configuration is expected without exposing real values.
 
 Example `.env.example`:
 ```
@@ -62,7 +62,7 @@ FEATURE_FLAG_NEW_UI=false
 
 #### 04-stage-specific-dotenv-committed
 
-Stage-specific overrides must use the naming convention `.env.[stage]` (e.g., `.env.production`, `.env.staging`, `.env.test`). These files may be committed to the repository because they carry deployment-stage configuration rather than local developer configuration. They are used during deployment pipelines where the stage is known and explicit.
+Stage-specific overrides MUST use the naming convention `.env.[stage]` (e.g., `.env.production`, `.env.staging`, `.env.test`). These files may be committed to the repository because they carry deployment-stage configuration rather than local developer configuration. They are used during deployment pipelines where the stage is known and explicit.
 
 The generic `.env` must still not be committed. The distinction is: `.env` is for local, ad-hoc, standalone use; `.env.[stage]` is for deployment pipelines with a defined environment identity.
 
@@ -70,7 +70,7 @@ The generic `.env` must still not be committed. The distinction is: `.env` is fo
 
 #### 05-load-in-makefile-before-processes
 
-When `.env` defines variables consumed by shell scripts or spawned processes, the Makefile must load and export them before invoking those processes. Use the following pattern at the top of the relevant Makefile or in a shared include:
+When `.env` defines variables consumed by shell scripts or spawned processes, the Makefile MUST load and export them before invoking those processes. Use the following pattern at the top of the relevant Makefile or in a shared include:
 
 ```makefile
 ifneq (,$(wildcard .env))
@@ -85,7 +85,7 @@ This ensures all variables in `.env` are available as environment variables to e
 
 #### 06-no-application-level-dotenv-loading
 
-Applications must not load `.env` files directly inside their own code using dotenv libraries or equivalent mechanisms. Configuration must enter the process exclusively as OS-level environment variables, set before the process is launched (by the Makefile, a shell script, CI, or a container runtime).
+Applications MUST NOT load `.env` files directly inside their own code using dotenv libraries or equivalent mechanisms. Configuration must enter the process exclusively as OS-level environment variables, set before the process is launched (by the Makefile, a shell script, CI, or a container runtime).
 
 Prohibited patterns:
 
@@ -114,7 +114,7 @@ This rule prevents two parallel loading paths — OS env and file-based env —
 
 #### 07-cli-adapters-use-yaml-config
 
-CLI adapters with multiple configuration attributes must use a YAML config file rather than env vars or flags for those attributes. This applies whenever configuration is nested, repetitive, or too verbose for flags alone.
+CLI adapters with multiple configuration attributes MUST use a YAML config file rather than env vars or flags for those attributes. This applies whenever configuration is nested, repetitive, or too verbose for flags alone.
 
 The CLI layer is responsible for loading and parsing the YAML file and passing the resolved values to the application layer. The application layer must not read the config file directly.
 
@@ -131,7 +131,7 @@ max_retries: 3
 
 #### 08-env-var-substitution-in-config-files
 
-When a YAML config file contains a value that must not be committed (such as a real endpoint URL, a username, or any other environment-specific value), that value must be expressed as an environment variable reference using `${VAR_NAME}` syntax, and the actual value must be defined in `.env`.
+When a YAML config file contains a value that MUST NOT be committed (such as a real endpoint URL, a username, or any other environment-specific value), that value must be expressed as an environment variable reference using `${VAR_NAME}` syntax, and the actual value must be defined in `.env`.
 
 This keeps the YAML file committable while keeping the environment-specific value out of the repository.
 

package/.xdrs/agentme/edrs/principles/002-coding-best-practices.md

@@ -46,7 +46,7 @@ src/
 
 #### 02-apply-template-method-pattern
 
-When a function's main logic contains well-defined sections and **any individual section exceeds ~20 lines**, extract each section into its own named function. The outer function becomes an orchestrator that calls the extracted helpers in sequence.
+When a function's main logic contains well-defined sections and **any individual section exceeds ~20 lines**, each section MUST be extracted into its own named function. The outer function becomes an orchestrator that calls the extracted helpers in sequence.
 
 **Example (Python):**
 
@@ -110,13 +110,13 @@ Every change to a public interface, behavior, or configuration option MUST be re
 
 #### 05-declare-types-in-file-where-used
 
-If a type (struct, interface, class, typedef, etc.) is used in only **one** file, declare it in that same file. Move a type to a shared module only when it is referenced in two or more files.
+Types used in only **one** file MUST be declared in that same file. Move a type to a shared module only when it is referenced in two or more files.
 
 ---
 
 #### 06-keep-test-files-next-to-source
 
-Where the language ecosystem supports it (e.g. JavaScript/TypeScript, Go, Rust), place test files **beside** the source file they cover and use a consistent naming convention rather than mirroring the source tree in a separate `tests/` folder.
+Where the language ecosystem supports it (e.g. JavaScript/TypeScript, Go, Rust), test files MUST be placed **beside** the source file they cover and use a consistent naming convention rather than mirroring the source tree in a separate `tests/` folder.
 
 **Recommended naming conventions:**
 

package/.xdrs/agentme/edrs/principles/004-unit-test-requirements.md

@@ -21,7 +21,7 @@ What unit testing practices should be followed to ensure tests are meaningful, r
 
 #### 01-must-have-at-least-one-assertion-per-test
 
-```typescript
+Every test MUST have at least one assertion that validates the expected behavior.
 // bad — no assertion; passes even when code is broken
 it("processes the order", () => { processOrder(mockOrder); });
 
@@ -36,7 +36,7 @@ it("processes the order and returns a confirmation id", () => {
 
 #### 02-must-run-offline
 
-Unit tests must not depend on any external resources: no network calls, no running databases, no external APIs, no file system paths outside the repo. Tests must pass with only static code available.
+Unit tests MUST NOT depend on any external resources: no network calls, no running databases, no external APIs, no file system paths outside the repo. Tests must pass with only static code available.
 
 ```typescript
 // bad — hits a real HTTP endpoint
@@ -64,13 +64,13 @@ export default defineConfig({
 });
 ```
 
-Builds that miss the threshold must not be merged.
+Builds that miss the threshold MUST NOT be merged.
 
 ---
 
 #### 04-must-place-test-files-alongside-source
 
-Test files must live next to the source file they test, in the same directory, following the convention of the language/framework:
+Test files MUST live next to the source file they test, in the same directory, following the convention of the language/framework:
 
 | Language | Pattern | Example |
 |----------|---------|-------|
@@ -96,7 +96,7 @@ Do not flatten or reorganize paths when using a separate test folder.
 
 #### 05-should-extract-shared-setup
 
-When setup logic is repeated across two or more test files, centralize it (`src/test-utils/`, `internal/testutil/`, `tests/conftest.py`).
+When setup logic is repeated across two or more test files, it SHOULD be centralized (`src/test-utils/`, `internal/testutil/`, `tests/conftest.py`).
 
 ```typescript
 // src/test-utils/order-factory.ts
@@ -109,7 +109,7 @@ export function makeOrder(overrides: Partial<Order> = {}): Order {
 
 #### 06-should-avoid-mocks
 
-Use the lowest-cost alternative that exercises real behavior:
+Tests SHOULD use the lowest-cost alternative that exercises real behavior:
 
 1. **Real implementation** — always prefer this
 2. **In-memory / lightweight fake** — e.g. in-memory DB, stub HTTP server

package/.xdrs/agentme/edrs/principles/007-project-quality-standards.md

@@ -23,7 +23,7 @@ These standards form a non-negotiable baseline. Individual projects may raise th
 
 #### 01-readme-must-have-getting-started
 
-`README.md` must include a **Getting Started** section in the first 20 lines with the minimal steps to install and use the project.
+`README.md` MUST include a **Getting Started** section in the first 20 lines with the minimal steps to install and use the project.
 
 **Required content:**
 - Installation or setup command(s)
@@ -52,7 +52,7 @@ myFunction({ input: "value" });
 
 #### 02-unit-tests-must-run-on-every-release
 
-A unit test suite must run automatically before every release. Failing tests must block the release — no silent skips or overrides.
+A unit test suite MUST run automatically before every release. Failing tests must block the release — no silent skips or overrides.
 
 **Requirements:**
 - A `make test` target must exist and run the full suite
@@ -67,7 +67,7 @@ A unit test suite must run automatically before every release. Failing tests mus
 
 #### 03-project-must-comply-with-xdrs
 
-All XDRs that apply to the project's scope (as listed in [.xdrs/index.md](../../../index.md)) must be followed. A deviation requires a project-local XDR documenting the override.
+All XDRs that apply to the project's scope (as listed in [.xdrs/index.md](../../../index.md)) MUST be followed. A deviation requires a project-local XDR documenting the override.
 
 **Requirements:**
 - Review applicable XDRs before any significant implementation
@@ -77,7 +77,7 @@ All XDRs that apply to the project's scope (as listed in [.xdrs/index.md](../../
 
 #### 04-project-must-have-linting
 
-Projects larger than 10 files or 200 lines of code must have a linter configured and actively enforced. Lint failures block CI builds.
+Projects larger than 10 files or 200 lines of code MUST have a linter configured and actively enforced. Lint failures block CI builds.
 
 **Requirements:**
 - `make lint` runs the linter with zero-warning tolerance
@@ -93,7 +93,7 @@ Projects larger than 10 files or 200 lines of code must have a linter configured
 
 #### 05-project-structure-must-be-clear
 
-Directory and file layout must be self-explanatory: source code, tests, configuration, and examples must be clearly separated and named.
+Directory and file layout MUST be self-explanatory: source code, tests, configuration, and examples must be clearly separated and named.
 
 **Requirements:**
 - Directory names must reflect their purpose (`src/`, `lib/`, `tests/`, `examples/`, `docs/`)
@@ -118,7 +118,7 @@ Directory and file layout must be self-explanatory: source code, tests, configur
 
 #### 06-libraries-must-have-runnable-examples
 
-Projects that are libraries or shared utilities must include an `examples/` directory. Each subdirectory represents a usage scenario and must be independently runnable. Examples that are "offline" (require no external credentials, no running servers, no paid APIs, and no environment-specific configuration outside the repository) must be executed as part of `make test`. Examples that depend on external entities may be left out of `make test`.
+Projects that are libraries or shared utilities MUST include an `examples/` directory. Each subdirectory represents a usage scenario and must be independently runnable. Examples that are "offline" (require no external credentials, no running servers, no paid APIs, and no environment-specific configuration outside the repository) must be executed as part of `make test`. Examples that depend on external entities may be left out of `make test`.
 
 **Requirements:**
 - `examples/` must contain at least one subdirectory per major usage scenario
@@ -170,7 +170,7 @@ all:
 
 #### 07-statistical-models-must-have-eval-targets
 
-Projects that contain statistical models (e.g., ML models, LLM-based evaluators, classifiers, ranking systems, or any component whose output quality is measured probabilistically) must define measurable performance thresholds and verify them automatically.
+Projects that contain statistical models (e.g., ML models, LLM-based evaluators, classifiers, ranking systems, or any component whose output quality is measured probabilistically) MUST define measurable performance thresholds and verify them automatically.
 
 **Requirements:**
 - A `make eval` target must exist and execute all performance evaluations

package/.xdrs/agentme/edrs/principles/022-secrets-management.md

@@ -29,7 +29,7 @@ All implementation practices derive from three guiding principles:
 
 #### 01-no-secrets-on-disk
 
-Secrets must never be stored on the disk of a developer machine or server. This includes `.env` files (even when gitignored), plaintext config files, embedded in source code, or any other file-based storage.
+Secrets MUST NEVER be stored on the disk of a developer machine or server. This includes `.env` files (even when gitignored), plaintext config files, embedded in source code, or any other file-based storage.
 
 The only acceptable local persistence is through the operating system's native secret manager (e.g., macOS Keychain, Windows Credential Manager, Linux Secret Service).
 
@@ -37,7 +37,7 @@ The only acceptable local persistence is through the operating system's native s
 
 #### 02-local-dev-uses-native-keychain
 
-During local development, secrets must be stored and retrieved using the native OS secret manager. Use cross-platform libraries to keep the code OS-agnostic:
+During local development, secrets MUST be stored and retrieved using the native OS secret manager. Use cross-platform libraries to keep the code OS-agnostic:
 
 | Language | Library |
 |----------|---------|
@@ -51,7 +51,7 @@ The "group" (service name) defaults to the module name. The secret identifier sh
 
 #### 03-fallback-lookup-order
 
-Secret fetching must implement a fallback chain in the following order:
+Secret fetching MUST implement a fallback chain in the following order:
 
 1. **Native OS keychain** — attempt to retrieve the secret using the local keychain library (used during local development).
 2. **Cloud secret manager** — if not found locally, fetch from the configured cloud secret manager (AWS Secrets Manager, Azure Key Vault, etc.) (used in cloud environments).
@@ -66,13 +66,13 @@ Secret 'db-password' could not be found in keychain under group 'mymodule' or in
 
 #### 04-secret-fetching-in-connector
 
-The secret fetching logic (including the fallback chain from rule 03) must live in a dedicated "connector" module or function. This isolates secret-access concerns from business logic and provides a single point to configure secret sources, caching policy, and error handling.
+The secret fetching logic (including the fallback chain from rule 03) MUST live in a dedicated "connector" module or function. This isolates secret-access concerns from business logic and provides a single point to configure secret sources, caching policy, and error handling.
 
 ---
 
 #### 05-setup-secrets-makefile-target
 
-Every module that requires secrets must expose a `setup-secrets` Makefile target. This target:
+Every module that requires secrets MUST expose a `setup-secrets` Makefile target. This target:
 
 - Prompts the user for each required secret value interactively.
 - If the user provides an empty value, the existing secret is not updated.
@@ -120,13 +120,13 @@ In library code (Python, JS/TS, Go), continue using the cross-platform libraries
 
 #### 06-never-log-or-leak-secrets
 
-Secrets must never be logged under any circumstance or sent to any service that is not clearly the intended consumer of that secret (authentication, encryption, etc.). This applies to all log levels including debug and trace. Error messages must reference the secret name or identifier, never its value.
+Secrets MUST NEVER be logged under any circumstance or sent to any service that is not clearly the intended consumer of that secret (authentication, encryption, etc.). This applies to all log levels including debug and trace. Error messages must reference the secret name or identifier, never its value.
 
 ---
 
 #### 07-prefer-dynamic-fetching
 
-Wherever possible, fetch secrets dynamically from the secret manager at the time of use. Avoid storing secrets in global variables or caching them indefinitely. Dynamic fetching through a specialized service enables:
+Wherever possible, secrets SHOULD be fetched dynamically from the secret manager at the time of use. Avoid storing secrets in global variables or caching them indefinitely. Dynamic fetching through a specialized service enables:
 
 - Automatic password rotation without redeployment.
 - Immediate propagation of rotated secrets.
@@ -138,7 +138,7 @@ Short-lived caching (e.g., a few minutes) is acceptable when performance require
 
 #### 08-prefer-fetching-at-point-of-use
 
-Prefer fetching the secret inside the function that directly needs it rather than passing it through multiple layers as a function argument. This minimizes the exposure surface by reducing the number of code paths that handle the raw secret value.
+Developers SHOULD prefer fetching the secret inside the function that directly needs it rather than passing it through multiple layers as a function argument. This minimizes the exposure surface by reducing the number of code paths that handle the raw secret value.
 
 Passing secrets via function arguments is acceptable when the consuming function cannot access the connector directly, but the default design should fetch at the point of use.
 

package/.xdrs/agentme/edrs/principles/023-coding-abstraction-practices.md

@@ -27,7 +27,7 @@ Prefer functional programming: pure functions with clear input → processing
 
 #### 02-prefer-explicit-calls-over-indirections
 
-A sequence of direct calls to libraries and resources makes logic straightforward. Avoid:
+Developers SHOULD prefer a sequence of direct calls to libraries and resources to keep logic straightforward. Avoid:
 
 - Aspect-oriented programming (AOP)
 - Implicit context injection / dependency injection containers
@@ -103,7 +103,7 @@ function createServerConfig(opts: Partial<ServerOpts>): ServerConfig {
 
 #### 05-abstractions-for-business-logic-are-encouraged
 
-Extracting domain logic into a named function is **encouraged** when it:
+Developers SHOULD extract domain logic into a named function when it:
 
 - Encapsulates a business rule so the reader does not need to parse low-level conditions to understand domain intent.
 - Communicates intent at a glance, making compound conditions or multi-step checks self-describing.
@@ -122,6 +122,6 @@ if (event.status === 'active' && event.role !== 'guest' && event.quota > 0) { ..
 
 #### 06-idiomatic-framework-patterns-are-exempt
 
-React hooks, higher-order components, middleware chains, and similar patterns established by the framework in use are **not** considered unnecessary abstraction. The reader already expects them, and fighting the framework's idioms creates more confusion than it removes.
+React hooks, higher-order components, middleware chains, and similar patterns established by the framework in use MUST NOT be treated as unnecessary abstraction. The reader already expects them, and fighting the framework's idioms creates more confusion than it removes.
 
 This exemption does not override other rules — a trivial wrapper inside a hook is still prohibited.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "agentme",
-  "version": "0.25.0",
+  "version": "0.25.2",
   "description": "",
   "dependencies": {
     "filedist": "^0.39.0"
@@ -18,6 +18,6 @@
     "url": "https://github.com/flaviostutz/agentme.git"
   },
   "devDependencies": {
-    "xdrs-core": "^0.37.1"
+    "xdrs-core": "^0.38.0"
   }
 }