agentme 0.25.0 → 0.26.0

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

@@ -23,18 +23,18 @@ Standardizing both the target names and the execution chain removes per-project
 
 #### 01-every-project-must-have-root-makefile
 
-The project root **MUST** contain a single authoritative `Makefile` that exposes the standard target names defined in rule 3. Developers and CI pipelines **MUST** invoke routine actions through this `Makefile`, **NEVER** by calling underlying tools directly in documentation, CI, or daily workflow commands.
+The project root MUST contain a single authoritative `Makefile` that exposes the standard target names defined in rule 3. Developers and CI pipelines MUST invoke routine actions through this `Makefile`, MUST NOT call underlying tools directly in documentation, CI, or daily workflow commands.
 
 `make <target>` is the shared contract across projects and languages.
 
-- The root `Makefile` **MUST** be the entry point for both developers and pipelines.
-- The root `Makefile` **MUST** expose at minimum the common targets defined in this XDR.
-- Reverse-compatibility wrappers are allowed when an ecosystem expects them, but they **MUST** stay trivial.
+- The root `Makefile` MUST be the entry point for both developers and pipelines.
+- The root `Makefile` MUST expose at minimum the common targets defined in this XDR.
+- Reverse-compatibility wrappers are allowed when an ecosystem expects them, but they MUST stay trivial.
 	- Allowed: `package.json` script `"test": "make test"`
 	- Not allowed: `make test` -> `npm run test` -> tool command
-- Project logic **MUST NOT** live in npm scripts, Mise tasks, shell wrappers, or other secondary runners when the same logic belongs in the `Makefile`.
+- Project logic MUST NOT live in npm scripts, Mise tasks, shell wrappers, or other secondary runners when the same logic belongs in the `Makefile`.
 
-*Why:* The project entry point **MUST** stay language-agnostic and obvious. A developer **SHOULD** be able to inspect the `Makefile` and immediately see which real tool commands will run.
+*Why:* The project entry point MUST stay language-agnostic and obvious. A developer SHOULD be able to inspect the `Makefile` and immediately see which real tool commands will run.
 
 #### 02-makefile-recipes-must-use-mise
 
@@ -47,10 +47,10 @@ make <target>
 			-> explicit tool command
 ```
 
-- The `setup` target **MUST** run `mise install` and any small project-specific bootstrap needed before normal targets work.
-- Routine targets such as `build`, `lint`, `test`, `run`, and `publish` **MUST** be invoked as `make <target>` by both contributors and CI.
-- Each Makefile recipe **MUST** call the real underlying command through `mise exec --`, following [agentme-edr-017](017-tool-execution-and-scripting.md).
-- Makefile recipes **MUST NOT** add extra script layers such as `npm run`, `pnpm run`, `yarn run`, `mise run`, `mise tasks`, or shell aliases when those layers only forward to another command.
+- The `setup` target MUST run `mise install` and any small project-specific bootstrap needed before normal targets work.
+- Routine targets such as `build`, `lint`, `test`, `run`, and `publish` MUST be invoked as `make <target>` by both contributors and CI.
+- Each Makefile recipe MUST call the real underlying command through `mise exec --`, following [agentme-edr-017](017-tool-execution-and-scripting.md).
+- Makefile recipes MUST NOT add extra script layers such as `npm run`, `pnpm run`, `yarn run`, `mise run`, `mise tasks`, or shell aliases when those layers only forward to another command.
 - Calling the actual tool is allowed even when that tool itself launches another program as part of its normal interface.
 	- Allowed: `mise exec -- pnpm exec eslint ./src`
 	- Allowed: `mise exec -- go test -cover ./...`
@@ -66,7 +66,7 @@ make <target>
 
 #### 03-standard-target-groups-and-names
 
-Targets are organized into five lifecycle groups. Projects **MUST** use these names unchanged. Extensions are allowed (see rule 5) but the core names **MUST NOT** be repurposed.
+Targets are organized into five lifecycle groups. Projects MUST use these names unchanged. Extensions are allowed (see rule 5) but the core names MUST NOT be repurposed.
 
 ##### Developer group
 
@@ -150,28 +150,6 @@ The prefix convention ensures developers can infer the purpose of any target wit
 
 ---
 
-#### 09-ai-project-dev-targets
-
-AI-based projects (LLM, Agent, and Workflow tiers as defined in [agentme-edr-018](../application/018-ai-llm-development-standards.md)) MUST expose a `dev-mlflow` target that starts a local MLflow tracking server for development inspection.
-
-**Example implementation:**
-
-```makefile
-dev-mlflow:
-	mise exec -- mlflow ui --host 0.0.0.0 --port 5000
-	open http://localhost:5000/
-```
-
----
-
-#### 08-default-targets-must-only-include-offline-subtargets
-
-`make all`, `make test`, and `make lint` **MUST** include every subtarget that runs **offline** — meaning it requires no external credentials, no running servers, no paid APIs, and no environment-specific configuration outside the repository.
-
-Subtargets that require external dependencies (e.g., `test-integration` against a live database, `test-e2e` against a staging environment, `lint-api` against a remote schema registry) **MUST** exist as named targets so developers can invoke them explicitly, but **MUST NOT** be invoked from `all`, `test`, or `lint`.
-
----
-
 #### 06-monorepo-usage
 
 In a monorepo, each module has its own `Makefile` with its own `build`, `lint`, `test`, and `deploy` targets scoped to that module. Parent-level Makefiles (at the application or repo root) delegate to child Makefiles in sequence. The parent Makefile **SHOULD** call `$(MAKE) -C <child> <target>` directly, while each child `Makefile` runs its actual tool commands through `mise exec --`.
@@ -195,7 +173,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
@@ -238,6 +216,28 @@ make clean
 make all
 ```
 
+---
+
+#### 08-default-targets-must-only-include-offline-subtargets
+
+`make all`, `make test`, and `make lint` **MUST** include every subtarget that runs **offline** — meaning it requires no external credentials, no running servers, no paid APIs, and no environment-specific configuration outside the repository.
+
+Subtargets that require external dependencies (e.g., `test-integration` against a live database, `test-e2e` against a staging environment, `lint-api` against a remote schema registry) **MUST** exist as named targets so developers can invoke them explicitly, but **MUST NOT** be invoked from `all`, `test`, or `lint`.
+
+---
+
+#### 09-ai-project-dev-targets
+
+AI-based projects (LLM, Agent, and Workflow tiers as defined in [agentme-edr-018](../application/018-ai-llm-development-standards.md)) MUST expose a `dev-mlflow` target that starts a local MLflow tracking server for development inspection.
+
+**Example implementation:**
+
+```makefile
+dev-mlflow:
+	mise exec -- mlflow ui --host 0.0.0.0 --port 5000
+	open http://localhost:5000/
+```
+
 ## Considered Options
 
 * (REJECTED) **Language-native entry points only** - Use `npm run`, `python -m`, `go run`, and similar tool-specific commands directly as the standard surface

package/.xdrs/agentme/edrs/devops/017-tool-execution-and-scripting.md

@@ -24,7 +24,7 @@ This keeps local development and CI aligned, reduces indirection, and lets contr
 - Every project MUST use a root `Makefile` as the authoritative entry point for developer and pipeline commands.
 - The target names in that `Makefile` MUST follow [agentme-edr-008](008-common-targets.md).
 - CI pipelines MUST run `make <target>` from the relevant root instead of calling language-specific scripts such as `npm run`, `pnpm run`, shell wrappers, or secondary task runners.
-- A Makefile target MUST execute the real operation through `mise exec --` before invoking the tool itself, so it always uses the version pinned in `.mise.toml`. Avoid intermediate script layers that hide the actual command.
+- A Makefile target MUST execute the real operation through `mise exec --` before invoking the tool itself, so it MUST use the version pinned in `.mise.toml`. Avoid intermediate script layers that hide the actual command.
 - Every Makefile target MUST start by echoing a concise summary of the target and folder or context, using fewer than 10 words. When delegating to another Makefile, echo the child path and delegated target before invoking it.
 - Direct delegation to another Makefile is allowed when traversing repo, app, or module boundaries, for example `$(MAKE) -C lib build`.
 - Calling the actual tool binary through its native executable launcher is allowed when that is the direct command under `mise exec --`, for example `mise exec -- pnpm exec eslint ./src`, `mise exec -- uv run ty check`, `mise exec -- go test`, or `mise exec -- npx -y monotag`.

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

@@ -17,15 +17,15 @@ How should projects manage environment variable configuration and CLI invocation
 
 ## Decision Outcome
 
-**Use YAML config files for CLI invocation configuration with multiple attributes; use `.env` files to supply environment variables to spawned processes and to hold uncommitted values referenced by config files. Load `.env` exclusively at process launch time — never inside application code.**
+**Use YAML config files for CLI invocation configuration with multiple attributes; use `.env` files to supply environment variables to spawned processes and to hold uncommitted values referenced by config files. Load `.env` exclusively at process launch time — MUST NOT be loaded inside application code.**
 
-Secrets (API keys, passwords, tokens) must never be placed in `.env` files. Those are handled by [agentme-edr-022](../principles/022-secrets-management.md).
+Secrets (API keys, passwords, tokens) MUST NOT be placed in `.env` files. Those are handled by [agentme-edr-022](../principles/022-secrets-management.md).
 
 ### Details
 
 #### 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 NOT 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/governance/013-contributing-guide-requirements.md

@@ -21,15 +21,41 @@ Projects MUST keep a `CONTRIBUTING.md` file at the repository root. The file MUS
 
 ### Details
 
-- Every project **MUST** have a root `CONTRIBUTING.md`.
-- The guide **MUST** direct bug reports to issues.
-- The guide **MUST** direct feature ideas and feature discussions to issues before implementation starts.
-- The guide **MUST** state that fixes and features are contributed through pull requests.
-- The guide **MUST** state that pull requests come from feature branches targeting `main`.
-- The guide **MUST** ask reviewers and contributors to use [Conventional Comments](https://conventionalcomments.org/) for review feedback.
-- The guide **MUST** ask contributors to keep pull requests small enough to keep review and discussion focused.
-- Project scaffolding skills **SHOULD** create the file by default when they initialize a repository.
-- The content **SHOULD** stay concise and practical; do not turn `CONTRIBUTING.md` into a duplicate of `README.md`.
+#### 01-contributing-md-is-required
+
+Every project MUST have a root `CONTRIBUTING.md` file at the repository root. The file MUST explain where bugs, feature discussions, and code changes belong so contributors follow a predictable workflow before opening pull requests.
+
+#### 02-guide-must-direct-bug-reports-to-issues
+
+The guide MUST direct bug reports to issues.
+
+#### 03-guide-must-route-feature-discussions-to-issues
+
+The guide MUST direct feature ideas and feature discussions to issues before implementation starts.
+
+#### 04-guide-must-require-pull-requests
+
+The guide MUST state that fixes and features are contributed through pull requests.
+
+#### 05-guide-must-require-feature-branches
+
+The guide MUST state that pull requests come from feature branches targeting `main`.
+
+#### 06-guide-must-require-conventional-comments
+
+The guide MUST ask reviewers and contributors to use [Conventional Comments](https://conventionalcomments.org/) for review feedback.
+
+#### 07-guide-must-ask-for-small-pull-requests
+
+The guide MUST ask contributors to keep pull requests small enough to keep review and discussion focused.
+
+#### 08-scaffolding-should-create-contributing-md
+
+Project scaffolding skills SHOULD create the file by default when they initialize a repository.
+
+#### 09-content-should-be-concise
+
+The content SHOULD stay concise and practical; do not turn `CONTRIBUTING.md` into a duplicate of `README.md`.
 
 ## Considered Options
 

package/.xdrs/agentme/edrs/observability/011-service-health-check-endpoint.md

@@ -45,7 +45,7 @@ All services **MUST** expose a `GET /health` endpoint that validates external de
 
 - `health` (required): overall state — `OK`, `WARNING`, or `ERROR`
 - `latencyMs` (required): total milliseconds to run all checks
-- `message` (required): human-readable summary; **MUST NEVER** expose credentials, internal IPs, or stack traces
+- `message` (required): human-readable summary; MUST NOT expose credentials, internal IPs, or stack traces
 
 **Dependency validation rules:**
 

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

@@ -15,12 +15,14 @@ What unit testing practices should be followed to ensure tests are meaningful, r
 
 ## Decision Outcome
 
-**Every test must assert behavior, run offline without external dependencies, enforce 80% coverage, centralize shared setup, and prefer real code over mocks.**
+**Every test MUST assert behavior, run offline without external dependencies, enforce 80% coverage, centralize shared setup, and prefer real code over mocks.**
 
 ### Details
 
 #### 01-must-have-at-least-one-assertion-per-test
 
+Every test MUST have at least one assertion that validates the expected behavior.
+
 ```typescript
 // bad — no assertion; passes even when code is broken
 it("processes the order", () => { processOrder(mockOrder); });
@@ -36,7 +38,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 +66,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 |
 |----------|---------|-------|
@@ -83,7 +85,7 @@ src/mymodule/group1/file1.ts        ← source
 src/mymodule/group1/file1.test.ts   ← test (same directory)
 ```
 
-**Exception — separate test folder:** When the framework makes co-location impractical (e.g. Python's common `tests/` convention), or when the community strongly favors a separate folder, a dedicated test root (e.g. `tests/`) is allowed. In that case the test folder **must mirror** the source folder structure exactly:
+**Exception — separate test folder:** When the framework makes co-location impractical (e.g. Python's common `tests/` convention), or when the community strongly favors a separate folder, a dedicated test root (e.g. `tests/`) is allowed. In that case the test folder MUST mirror the source folder structure exactly:
 
 ```
 src/mymodule/group1/file1.py          ← source
@@ -96,7 +98,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,9 +111,9 @@ 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
+1. **Real implementation** — MUST be preferred
 2. **In-memory / lightweight fake** — e.g. in-memory DB, stub HTTP server
 3. **Recorded fixture** — replay captured real responses
 4. **Mock / stub** — only for external APIs, irreversible operations, or hardware I/O

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

@@ -15,15 +15,15 @@ What minimum quality standards must every project in the organization meet to en
 
 ## Decision Outcome
 
-Every project must meet the minimum quality standards: a Getting Started section in its README, unit tests that run on every release, compliance with workspace XDRs, active linting enforcement, a structure that is clear to new developers, and — for libraries and utilities — a runnable examples folder verified on every test run. Integration tests are advised but not required. Projects with statistical models must have evaluation targets with performance thresholds.
+Every project MUST meet the minimum quality standards: a Getting Started section in its README, unit tests that run on every release, compliance with workspace XDRs, active linting enforcement, a structure that is clear to new developers, and — for libraries and utilities — a runnable examples folder verified on every test run. Integration tests are advised but not required. Projects with statistical models MUST have evaluation targets with performance thresholds.
 
-These standards form a non-negotiable baseline. Individual projects may raise the bar but must never fall below it.
+These standards form a non-negotiable baseline. Individual projects may raise the bar but MUST NOT fall below it.
 
 ### Details
 
 #### 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,14 +52,14 @@ 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
-- CI/CD must invoke it before publish/deploy
+- A `make test` target MUST exist and run the full suite
+- CI/CD MUST invoke it before publish/deploy
 - Test failures block the release
 
-**Exception:** Projects with fewer than 100 lines of code, or whose `README.md` prominently marks them as a **Spike** or **Experiment**, are exempt from this requirement. Such projects must never be deployed to production.
+**Exception:** Projects with fewer than 100 lines of code, or whose `README.md` prominently marks them as a **Spike** or **Experiment**, are exempt from this requirement. Such projects MUST NOT be deployed to production.
 
 **Reference:** [agentme-edr-004](004-unit-test-requirements.md) for detailed unit test requirements.
 
@@ -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
@@ -85,7 +85,7 @@ Projects larger than 10 files or 200 lines of code must have a linter configured
 - Linter config is checked in (e.g., `.eslintrc.js`, `pyproject.toml`, `.golangci.yml`)
 - CI runs `make lint` before merging or releasing
 
-**Exception:** Projects with fewer than 100 lines of code, or whose `README.md` prominently marks them as a **Spike** or **Experiment**, are exempt from this requirement. Such projects must never be deployed to production.
+**Exception:** Projects with fewer than 100 lines of code, or whose `README.md` prominently marks them as a **Spike** or **Experiment**, are exempt from this requirement. Such projects MUST NOT be deployed to production.
 
 **Reference:** [agentme-edr-003](../application/003-javascript-project-tooling.md) for JavaScript-specific tooling.
 
@@ -93,11 +93,11 @@ 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/`)
-- README must describe the top-level layout if non-obvious
+- Directory names MUST reflect their purpose (`src/`, `lib/`, `tests/`, `examples/`, `docs/`)
+- README MUST describe the top-level layout if non-obvious
 - No orphaned or unexplained directories or files at the project root
 
 **Example layout (TypeScript project):**
@@ -118,14 +118,14 @@ 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
-- Each scenario subdirectory must have a `Makefile` with a `run` target
-- Examples must import the library as an external consumer (not via relative `../src` imports)
-- `make test` in the root must run all offline examples; failures block CI and releases
-- Examples that depend on external entities must not be included in `make test`
+- `examples/` MUST contain at least one subdirectory per major usage scenario
+- Each scenario subdirectory MUST have a `Makefile` with a `run` target
+- Examples MUST import the library as an external consumer (not via relative `../src` imports)
+- `make test` in the root MUST run all offline examples; failures block CI and releases
+- Examples that depend on external entities MUST NOT be included in `make test`
 
 **Directory layout:**
 
@@ -170,16 +170,16 @@ 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
-- Each evaluation must have a **documented minimum performance threshold** (e.g., accuracy ≥ 0.85, F1 ≥ 0.80, BLEU ≥ 0.70)
-- Thresholds must be declared explicitly in the project (e.g., in a config file, `Makefile` variable, or documented in `README.md`)
-- `make eval` must **exit with a non-zero status** (fail) if:
+- A `make eval` target MUST exist and execute all performance evaluations
+- Each evaluation MUST have a **documented minimum performance threshold** (e.g., accuracy ≥ 0.85, F1 ≥ 0.80, BLEU ≥ 0.70)
+- Thresholds MUST be declared explicitly in the project (e.g., in a config file, `Makefile` variable, or documented in `README.md`)
+- `make eval` MUST **exit with a non-zero status** (fail) if:
   - The evaluation cannot be executed (missing data, environment errors, model load failures)
   - Any metric falls below its defined minimum threshold
-- CI/CD must invoke `make eval` before releasing any version that changes model weights, prompts, or evaluation logic
+- CI/CD MUST invoke `make eval` before releasing any version that changes model weights, prompts, or evaluation logic
 
 **Threshold declaration example (Makefile):**
 

package/.xdrs/agentme/edrs/principles/009-error-handling.md

@@ -211,7 +211,7 @@ Every system boundary MUST signal failure explicitly:
 
 - **OS processes** MUST exit with a **non-zero exit code** when something went wrong. Exit code `0` means success.
 - **HTTP services** MUST return a **non-2xx/3xx status code** on error, accompanied by a response body that describes the problem without exposing internal system details (stack traces, SQL queries, internal paths, etc.).
-- **All error responses** SHOULD be logged to the console/structured logger, especially system-level or unexpected errors. Operational teams must be able to find the cause from logs alone.
+- **All error responses** SHOULD be logged to the console/structured logger, especially system-level or unexpected errors. Operational teams MUST be able to find the cause from logs alone.
 
 **Examples:**
 

package/.xdrs/agentme/edrs/principles/012-continuous-xdr-enrichment.md

@@ -21,15 +21,33 @@ Developers MUST treat reusable missing guidance discovered during implementation
 
 ### Details
 
-- The main objective is sharing, discussing, and converging practices across teams. Controlled divergence during exploration is acceptable, but recurring successful decisions MUST be converged into shared XDRs.
-- The non _local scope exists to share practices across projects, company areas, and functionally organized teams. Decisions placed in `_local` SHOULD be truly specific to the needs of a single application or repository.
-- When developers or coding agents need too much detailed steering to complete a task, they MUST reflect on whether those details would help other teams or future implementations. If yes, create or update an XDR proposal in the broadest appropriate shared scope.
-- This includes cases where an agent implemented a feature without a framework, pattern, coding standard, or other practice that should likely be standardized. Missing reusable guardrails SHOULD trigger an XDR proposal.
-- Teams SHOULD aim to keep at least 80% of big coding decisions covered by accepted XDRs. Big decisions include framework or tool selection, overall code organization, monorepo structure, complex business flows, and coding standards.
-- If a big decision is not yet covered, developers SHOULD either propose a new XDR or document why the decision is intentionally local and should not be shared.
-- Leaders responsible for the affected scope are accountable for reviewing XDR proposals, adjusting them, and publishing the accepted decision.
-- It is good practice to ask the coding agent which missing XDRs made the task harder, increased adjustment rounds, or forced more vibe coding. Those gaps should feed the XDR backlog.
-- In SDD, specifications describe the feature being built; XDRs describe reusable decisions and guardrails that should survive beyond one feature. Do not keep durable engineering policy only inside feature specs.
+#### 01-reusable-guidance-must-become-shared-xdr
+
+Developers MUST treat reusable missing guidance discovered during implementation as an XDR gap to be proposed and reviewed, not as permanent prompt-only context or repeated vibe coding. The main objective is sharing, discussing, and converging practices across teams. Controlled divergence during exploration is acceptable, but recurring successful decisions MUST be converged into shared XDRs.
+
+#### 02-local-scope-must-be-for-truly-specific-decisions
+
+Decisions placed in `_local` SHOULD be truly specific to the needs of a single application or repository. The non-`_local` scope exists to share practices across projects, company areas, and functionally organized teams.
+
+#### 03-steering-needs-must-trigger-xdr-reflection
+
+When developers or coding agents need too much detailed steering to complete a task, they MUST reflect on whether those details would help other teams or future implementations. If yes, create or update an XDR proposal in the broadest appropriate shared scope. This includes cases where an agent implemented a feature without a framework, pattern, coding standard, or other practice that should likely be standardized. Missing reusable guardrails SHOULD trigger an XDR proposal.
+
+#### 04-coverage-target-should-be-80-percent
+
+Teams SHOULD aim to keep at least 80% of big coding decisions covered by accepted XDRs. Big decisions include framework or tool selection, overall code organization, monorepo structure, complex business flows, and coding standards. If a big decision is not yet covered, developers SHOULD either propose a new XDR or document why the decision is intentionally local and should not be shared.
+
+#### 05-leaders-must-review-xdr-proposals
+
+Leaders responsible for the affected scope MUST review XDR proposals, adjust them as needed, and publish the accepted decision.
+
+#### 06-query-agents-for-missing-xdrs
+
+It is good practice to ask the coding agent which missing XDRs made the task harder, increased adjustment rounds, or forced more vibe coding. Those gaps SHOULD feed the XDR backlog.
+
+#### 07-xdrs-are-not-feature-specs
+
+In SDD, specifications describe the feature being built; XDRs describe reusable decisions and guardrails that MUST survive beyond one feature. Do not keep durable engineering policy only inside feature specs.
 
 ## Considered Options
 

package/.xdrs/agentme/edrs/principles/016-cross-language-module-structure.md

@@ -88,7 +88,7 @@ Examples that demonstrate how to consume a library or reusable module MUST live
 Examples MUST exercise the module through its public distribution surface:
 
 - use the package built into `dist/` when the ecosystem supports local packaged artifacts
-- otherwise use the public module path or equivalent consumer-facing import surface; **MUST NOT** use relative source-file imports or direct references to internal implementation paths
+- otherwise use the public module path or equivalent consumer-facing import surface; MUST NOT use relative source-file imports or direct references to internal implementation paths
 
 Example: