agentme 0.27.0 → 0.29.0

package/.xdrs/agentme/edrs/{observability/011-service-health-check-endpoint.md → operations/401-service-health-check-endpoint.md}

@@ -1,11 +1,11 @@
 ---
-name: agentme-edr-policy-011-service-health-check-endpoint
+name: agentme-edr-policy-401-service-health-check-endpoint
 description: Defines the required health endpoint contract for service availability and dependency readiness checks. Use when implementing or reviewing service health endpoints.
 apply-to: Service projects with health endpoints
 valid-from: 2026-05-25
 ---
 
-# agentme-edr-policy-011: Service health check endpoint
+# agentme-edr-policy-401: Service health check endpoint
 
 ## Context and Problem Statement
 

package/.xdrs/agentme/edrs/{devops/005-monorepo-structure.md → platform/301-monorepo-structure.md}

@@ -1,11 +1,11 @@
 ---
-name: agentme-edr-policy-005-monorepo-structure
+name: agentme-edr-policy-301-monorepo-structure
 description: Defines the standard monorepo layout, naming, and build conventions using shared areas, Mise, and Makefiles. Use when creating or reviewing monorepos.
 apply-to: Monorepo projects
 valid-from: 2026-05-25
 ---
 
-# agentme-edr-policy-005: Monorepo structure
+# agentme-edr-policy-301: Monorepo structure
 
 ## Context and Problem Statement
 
@@ -24,6 +24,8 @@ Module folder responsibilities, artifact locations, and test-folder conventions
 
 #### 01-top-level-directory-layout
 
+Every monorepo MUST follow this top-level directory layout:
+
 ```
 /
 ├── .cache/               # Optional shared cache for repo-level tooling
@@ -76,7 +78,7 @@ Module folder responsibilities, artifact locations, and test-folder conventions
 
 A `Makefile` MUST be present at the repository root, in every application folder, and in every module folder.
 
-All Makefiles MUST use the shared target vocabulary from [agentme-edr-008](008-common-targets.md).
+All Makefiles MUST use the shared target vocabulary from [agentme-edr-303](303-common-targets.md).
 
 Repository, application, and module Makefiles MUST define at minimum: `all`, `build`, `lint`, `test`, and `clean`.
 
@@ -92,7 +94,7 @@ The root `setup` target MUST run `mise install` and any small repository bootstr
 - Every language runtime or CLI referenced by any module `Makefile`, CI workflow, or README command MUST be pinned in `.mise.toml`.
 - Contributors and CI run `make setup` after cloning or checkout; this target MUST call `mise install`.
 - Agents and contributors MUST check `.mise.toml` before using a system-installed compiler, runtime, or CLI.
-- When `.mise.toml` exists, all build, test, lint, and code-generation commands MUST run through `make <target>`, and the Makefile recipes MUST execute the underlying tools via `mise exec -- <command>`, following [agentme-edr-017](017-tool-execution-and-scripting.md).
+- When `.mise.toml` exists, all build, test, lint, and code-generation commands MUST run through `make <target>`, and the Makefile recipes MUST execute the underlying tools via `mise exec -- <command>`, following [agentme-edr-304](304-tool-execution-and-scripting.md).
 - If a required tool is missing, the first remediation step MUST be to update `.mise.toml` or run `mise install`, not to install ad-hoc global tools with language-specific installers such as `go install`, `npm install -g`, `pip install --user`, or `cargo install`.
 - Root and module `Makefile` targets MUST work when invoked as plain `make <target>` after `make setup`.
 

package/.xdrs/agentme/edrs/{devops/006-github-pipelines.md → platform/302-github-pipelines.md}

@@ -1,11 +1,11 @@
 ---
-name: agentme-edr-policy-006-github-ci-cd-pipelines
+name: agentme-edr-policy-302-github-ci-cd-pipelines
 description: Defines the standard GitHub Actions workflow split for CI, release tagging, and publishing. Use when configuring project automation.
 apply-to: Projects using GitHub Actions
 valid-from: 2026-05-25
 ---
 
-# agentme-edr-policy-006: GitHub CI/CD pipelines
+# agentme-edr-policy-302: GitHub CI/CD pipelines
 
 ## Context and Problem Statement
 
@@ -142,7 +142,7 @@ jobs:
 
 *Why rebuild on publish:* The checkout is done from the exact tag commit. Rebuilding ensures the published artifact matches exactly what is tagged, rather than relying on a prior CI artifact.
 
-*Why `id-token: write`:* Required for npm provenance attestation via `npm publish --provenance`, as specified in [agentme-edr-003](../application/003-javascript-project-tooling.md).
+*Why `id-token: write`:* Required for npm provenance attestation via `npm publish --provenance`, as specified in [agentme-edr-101](../application/101-javascript-project-tooling.md).
 
 ---
 

package/.xdrs/agentme/edrs/{devops/008-common-targets.md → platform/303-common-targets.md}

@@ -1,11 +1,11 @@
 ---
-name: agentme-edr-policy-008-common-development-script-names
+name: agentme-edr-policy-303-common-development-script-names
 description: Defines standard Makefile target names and the mandatory tool-execution flow using Mise. Use when designing build, lint, test, and release entry points.
 apply-to: All projects with Makefiles
 valid-from: 2026-05-25
 ---
 
-# agentme-edr-policy-008: Common development script names
+# agentme-edr-policy-303: Common development script names
 
 ## Context and Problem Statement
 
@@ -15,7 +15,7 @@ What standard set of Makefile target names and execution rules should projects a
 
 ## Decision Outcome
 
-**Every project MUST expose its development actions through a root `Makefile` using a defined set of standardized target names. Target implementation and tool-execution rules follow [agentme-edr-017](017-tool-execution-and-scripting.md), which requires `mise exec --` before routine tool commands.**
+**Every project MUST expose its development actions through a root `Makefile` using a defined set of standardized target names. Target implementation and tool-execution rules follow [agentme-edr-304](304-tool-execution-and-scripting.md), which requires `mise exec --` before routine tool commands.**
 
 Standardizing both the target names and the execution chain removes per-project guesswork, makes CI pipelines reusable, and keeps tooling behavior visible in one place.
 
@@ -49,7 +49,7 @@ make <target>
 
 - 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).
+- Each Makefile recipe MUST call the real underlying command through `mise exec --`, following [agentme-edr-304](304-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`
@@ -73,10 +73,10 @@ Targets are organized into five lifecycle groups. Projects MUST use these names
 | Target | Purpose |
 |--------|---------|
 | `setup` | Run `mise install` and any small project bootstrap needed before normal targets work. This is the first command after checkout. |
-| `all` | Alias that runs `build`, `lint`, and `test` in sequence. **MUST** be the default target (i.e., running `make` or the runner with no arguments invokes `all`). Used by developers as a fast pre-push check to verify the software meets minimum quality standards in one command. **MUST** only invoke targets that run **offline** — no external credentials, running servers, paid APIs, or environment-specific configuration outside the repository. |
+| `all` | Alias that runs `build`, `lint`, and `test` in sequence. MUST be the default target (i.e., running `make` or the runner with no arguments invokes `all`). Used by developers as a fast pre-push check to verify the software meets minimum quality standards in one command. MUST only invoke targets that run **offline** — no external credentials, running servers, paid APIs, or environment-specific configuration outside the repository. |
 | `clean` | Remove all temporary or generated files created during build, lint, or test (e.g., `node_modules`, virtual environments, compiled binaries, generated files). Used both locally and in CI for a clean slate. |
 | `dev` | Run the software locally for development (e.g., start a Node.js API server, open a Jupyter notebook, launch a React dev server). May have debugging tools, verbose logging, or hot reloading features enabled. |
-| `run` | Run the software in production mode (e.g., start a compiled binary, launch a production server). Debugging or development-only features **SHOULD NOT** be enabled. |
+| `run` | Run the software in production mode (e.g., start a compiled binary, launch a production server). Debugging or development-only features SHOULD NOT be enabled. |
 | `update-lockfile` | Update the dependency lockfile to reflect the latest resolved versions of all dependencies. |
 
 ##### Build group
@@ -93,17 +93,17 @@ Targets are organized into five lifecycle groups. Projects MUST use these names
 
 | Target | Purpose |
 |--------|---------|
-| `lint` | Run **all static quality checks** outside of tests. This MUST include: code formatting validation, code style enforcement, code smell detection, static analysis, dependency audits for known CVEs, security vulnerability scans (e.g., SAST), and project/configuration structure checks. All checks **MUST** be non-destructive (read-only); fixes are handled by `lint-fix`. **MUST** only invoke subtargets that run **offline** (no external credentials or services). |
+| `lint` | Run **all static quality checks** outside of tests. This MUST include: code formatting validation, code style enforcement, code smell detection, static analysis, dependency audits for known CVEs, security vulnerability scans (e.g., SAST), and project/configuration structure checks. All checks MUST be non-destructive (read-only); fixes are handled by `lint-fix`. MUST only invoke subtargets that run **offline** (no external credentials or services). |
 | `lint-fix` | Automatically fix linting and formatting issues where possible. || `lint-format` | *(Optional)* Check code formatting only (e.g., Prettier, gofmt, Black). |
 ##### Test group
 
 | Target | Purpose |
 |--------|---------|
-| `test` | Run **all offline tests** required for the project. This MUST include unit tests (with coverage enforcement — the build MUST fail if coverage thresholds are not met) and any integration or end-to-end tests that run **offline** (no external servers, credentials, or paid APIs). Normally delegates to `test-unit` and, when offline, `test-integration` in sequence. Suffixed targets that require external dependencies **MUST NOT** be invoked automatically — see rule 08. |
+| `test` | Run **all offline tests** required for the project. This MUST include unit tests (with coverage enforcement — the build MUST fail if coverage thresholds are not met) and any integration or end-to-end tests that run **offline** (no external servers, credentials, or paid APIs). Normally delegates to `test-unit` and, when offline, `test-integration` in sequence. Suffixed targets that require external dependencies MUST NOT be invoked automatically — see rule 08. |
 | `test-unit` | Run unit tests only, including coverage report generation and coverage threshold enforcement. |
 | `test-integration` | *(Optional)* Run integration and end-to-end tests only. Projects without integration tests MAY omit this target. |
 | `test-smoke` | *(Optional)* Run a fast, minimal subset of tests to verify the software is basically functional. Useful as a post-deploy health check. |
-| `eval` | *(Optional)* Run **all evaluations** for the module. Used alongside `test` to measure the accuracy and performance of statistical systems such as ML models, AI agents, or noisy systems. Typically runs against a live or near-live system (similar to an integration test) and produces a performance analysis report (e.g., F1 score, Accuracy, Precision, Recall). **MUST NOT** be included in `test` or `all` — evals are opt-in because they require live dependencies and MAY be slow or costly to run. Individual evaluations **MUST** follow the prefix convention: `eval-<qualifier>` (e.g., `eval-simple`, `eval-complex`). |
+| `eval` | *(Optional)* Run **all evaluations** for the module. Used alongside `test` to measure the accuracy and performance of statistical systems such as ML models, AI agents, or noisy systems. Typically runs against a live or near-live system (similar to an integration test) and produces a performance analysis report (e.g., F1 score, Accuracy, Precision, Recall). MUST NOT be included in `test` or `all` — evals are opt-in because they require live dependencies and MAY be slow or costly to run. Individual evaluations MUST follow the prefix convention: `eval-<qualifier>` (e.g., `eval-simple`, `eval-complex`). |
 
 ##### Release group
 
@@ -119,18 +119,18 @@ Targets are organized into five lifecycle groups. Projects MUST use these names
 
 #### 04-standard-environment-variables
 
-Two environment variables have defined semantics and **MUST** be used consistently.
+Two environment variables have defined semantics and MUST be used consistently.
 
 | Variable | Purpose |
 |----------|---------|
-| `STAGE` | Identifies the runtime environment. Format: `[prefix][-variant]`. Common prefixes: `dev`, `tst`, `acc`, `prd`. Examples: `dev`, `dev-pr123`, `tst`, `prd-blue`. **MAY** be required by any target that is environment-aware (build, lint, deploy, etc.). |
+| `STAGE` | Identifies the runtime environment. Format: `[prefix][-variant]`. Common prefixes: `dev`, `tst`, `acc`, `prd`. Examples: `dev`, `dev-pr123`, `tst`, `prd-blue`. MAY be required by any target that is environment-aware (build, lint, deploy, etc.). |
 | `VERSION` | Sets the explicit version used during packaging and deployment. Used when there is no automatic version-tagging utility, or to override it. |
 
 ---
 
 #### 05-extending-targets-with-prefixes
 
-Projects **MAY** add custom targets beyond the standard set. Custom targets **MUST** be named by prefixing a standard target name with a descriptive qualifier, keeping the naming intuitive and consistent with the group it belongs to.
+Projects MAY add custom targets beyond the standard set. Custom targets MUST be named by prefixing a standard target name with a descriptive qualifier, keeping the naming intuitive and consistent with the group it belongs to.
 
 **Examples:**
 
@@ -152,7 +152,7 @@ The prefix convention ensures developers can infer the purpose of any target wit
 
 #### 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 --`.
+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 --`.
 
 ```makefile
 # root Makefile — delegates to all modules
@@ -165,9 +165,9 @@ test:
 	$(MAKE) -C module-b test
 ```
 
-A developer can run `make test` at the repo root to test everything, or `cd module-a && make test` to test a single module. Both **MUST** work.
+A developer can run `make test` at the repo root to test everything, or `cd module-a && make test` to test a single module. Both MUST work.
 
-**Reference:** See [agentme-edr-005](005-monorepo-structure.md) for the full monorepo layout convention.
+**Reference:** See [agentme-edr-301](301-monorepo-structure.md) for the full monorepo layout convention.
 
 ---
 
@@ -220,15 +220,15 @@ 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.
+`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`.
+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.
+AI-based projects (LLM, Agent, and Workflow tiers as defined in [agentme-edr-141](../application/141-ai-llm-development-standards.md)) MUST expose a `dev-mlflow` target that starts a local MLflow tracking server for development inspection.
 
 **Example implementation:**
 
@@ -251,5 +251,5 @@ dev-mlflow:
 
 ## References
 
-- [agentme-edr-005](005-monorepo-structure.md) - Monorepo layout and delegation structure
-- [agentme-edr-017](017-tool-execution-and-scripting.md) - Tool-execution rules for Makefile targets and CI
+- [agentme-edr-301](301-monorepo-structure.md) - Monorepo layout and delegation structure
+- [agentme-edr-304](304-tool-execution-and-scripting.md) - Tool-execution rules for Makefile targets and CI

package/.xdrs/agentme/edrs/{devops/017-tool-execution-and-scripting.md → platform/304-tool-execution-and-scripting.md}

@@ -1,11 +1,11 @@
 ---
-name: agentme-edr-policy-017-tool-execution-and-scripting
+name: agentme-edr-policy-304-tool-execution-and-scripting
 description: Defines how Makefiles, CI pipelines, and optional wrapper scripts execute project commands. Use when designing project automation or command entry points.
 apply-to: All projects with Makefiles and CI pipelines
 valid-from: 2026-05-25
 ---
 
-# agentme-edr-policy-017: Tool execution and scripting
+# agentme-edr-policy-304: Tool execution and scripting
 
 ## Context and Problem Statement
 
@@ -15,14 +15,14 @@ How should projects execute development commands so the command surface stays pr
 
 ## Decision Outcome
 
-**Use Makefiles as the only authoritative command entry point, with targets named by [agentme-edr-008](008-common-targets.md) and implemented with `mise exec --` before the real tool command.**
+**Use Makefiles as the only authoritative command entry point, with targets named by [agentme-edr-303](303-common-targets.md) and implemented with `mise exec --` before the real tool command.**
 
 This keeps local development and CI aligned, reduces indirection, and lets contributors understand project behavior by reading one command surface.
 
 ### Details
 
 - 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).
+- The target names in that `Makefile` MUST follow [agentme-edr-303](303-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 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.
@@ -58,9 +58,9 @@ Disallowed:
 
 ## References
 
-- [agentme-edr-005](005-monorepo-structure.md) - Monorepo layout and Makefile hierarchy
-- [agentme-edr-006](006-github-pipelines.md) - CI/CD workflows should call Make targets
-- [agentme-edr-008](008-common-targets.md) - Standard target names
-- [agentme-edr-003](../application/003-javascript-project-tooling.md) - JavaScript tooling commands inside Makefiles
-- [agentme-edr-010](../application/010-golang-project-tooling.md) - Go tooling commands inside Makefiles
-- [agentme-edr-014](../application/014-python-project-tooling.md) - Python tooling commands inside Makefiles
+- [agentme-edr-301](301-monorepo-structure.md) - Monorepo layout and Makefile hierarchy
+- [agentme-edr-302](302-github-pipelines.md) - CI/CD workflows should call Make targets
+- [agentme-edr-303](303-common-targets.md) - Standard target names
+- [agentme-edr-101](../application/101-javascript-project-tooling.md) - JavaScript tooling commands inside Makefiles
+- [agentme-edr-102](../application/102-golang-project-tooling.md) - Go tooling commands inside Makefiles
+- [agentme-edr-103](../application/103-python-project-tooling.md) - Python tooling commands inside Makefiles

package/.xdrs/agentme/edrs/{devops/027-environment-variable-configuration.md → platform/305-environment-variable-configuration.md}

@@ -1,11 +1,11 @@
 ---
-name: agentme-edr-policy-027-environment-variable-configuration-files
+name: agentme-edr-policy-305-environment-variable-configuration-files
 description: Defines when to use YAML config files versus .env files for configuration, how to combine them, and how .env is loaded for spawned processes. Use when setting up project configuration for any application, CLI, or library.
 apply-to: All projects that use environment variables for configuration
 valid-from: 2026-06-09
 ---
 
-# agentme-edr-policy-027: Environment variable configuration files
+# agentme-edr-policy-305: Environment variable configuration files
 
 ## Context and Problem Statement
 
@@ -19,7 +19,7 @@ How should projects manage environment variable configuration and CLI invocation
 
 **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 NOT 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-124](../application/124-secrets-management.md).
 
 ### Details
 
@@ -28,7 +28,7 @@ Secrets (API keys, passwords, tokens) MUST NOT be placed in `.env` files. Those
 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).
+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).
 
 Do not use `.env` as a general-purpose configuration store when a YAML config file is the right tool (see rule 07).
 
@@ -64,7 +64,7 @@ FEATURE_FLAG_NEW_UI=false
 
 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.
+The generic `.env` MUST 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.
 
 ---
 
@@ -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:
 
@@ -116,9 +116,9 @@ This rule prevents two parallel loading paths — OS env and file-based env —
 
 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.
+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.
 
-Default config file discovery should follow the pattern defined in [agentme-edr-015](../application/015-cli-tool-standards.md): load `[cwd]/[tool-name].yml` by default, or an explicit path provided via `--config`.
+Default config file discovery SHOULD follow the pattern defined in [agentme-edr-104](../application/104-cli-tool-standards.md): load `[cwd]/[tool-name].yml` by default, or an explicit path provided via `--config`.
 
 Example `myconfig.yml`:
 ```yaml
@@ -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.
 
@@ -148,11 +148,11 @@ openapi_endpoint: ${OPENAPI_ENDPOINT}
 log_level: debug
 ```
 
-The `.env` file must be loaded in the Makefile before launching the process (see rule 05) so the variable is available when the CLI or process reads the config file.
+The `.env` file MUST be loaded in the Makefile before launching the process (see rule 05) so the variable is available when the CLI or process reads the config file.
 
 ## References
 
-- [agentme-edr-022](../principles/022-secrets-management.md) - Secrets must use OS keychains or cloud secret managers, not `.env` files
-- [agentme-edr-017](017-tool-execution-and-scripting.md) - Makefiles are the authoritative command entry point; rule 05 above integrates with that standard
-- [agentme-edr-008](008-common-targets.md) - Standard Makefile target names
-- [agentme-edr-015](../application/015-cli-tool-standards.md) - CLI config file discovery and CLI-to-application separation
+- [agentme-edr-124](../application/124-secrets-management.md) - Secrets must use OS keychains or cloud secret managers, not `.env` files
+- [agentme-edr-304](304-tool-execution-and-scripting.md) - Makefiles are the authoritative command entry point; rule 05 above integrates with that standard
+- [agentme-edr-303](303-common-targets.md) - Standard Makefile target names
+- [agentme-edr-104](../application/104-cli-tool-standards.md) - CLI config file discovery and CLI-to-application separation

package/.xdrs/agentme/edrs/{devops → platform}/skills/002-monorepo-setup/SKILL.md

@@ -3,7 +3,7 @@ name: 002-monorepo-setup
 description: >
   Step-by-step instructions for setting up and scaffolding a new monorepo following the standard
   layout, naming conventions, Makefiles, Mise tooling, and README requirements defined in
-  agentme-edr-005. Activate this skill when the user asks to create, initialize, or set up a
+  agentme-edr-301. Activate this skill when the user asks to create, initialize, or set up a
   monorepo, add a new application or module to an existing monorepo, or verify that a monorepo
   complies with the standard structure.
 metadata:
@@ -13,12 +13,12 @@ metadata:
 
 ## Overview
 
-Creates or extends a monorepo that follows the standard layout from [agentme-edr-005](../../005-monorepo-structure.md):
+Creates or extends a monorepo that follows the standard layout from [agentme-edr-301](../../301-monorepo-structure.md):
 top-level application folders, independent module roots, sibling example and multi-module test
 areas, Mise-managed tooling, and Makefiles at every level so any contributor can build, lint, and
 test any part of the monorepo with a single, predictable command.
 
-Related EDRs: [agentme-edr-005](../../005-monorepo-structure.md), [agentme-edr-013](../../../governance/013-contributing-guide-requirements.md), [agentme-edr-016](../../../principles/016-cross-language-module-structure.md)
+Related EDRs: [agentme-edr-301](../../301-monorepo-structure.md), [agentme-edr-502](../../../governance/502-contributing-guide-requirements.md), [agentme-edr-016](../../../principles/016-cross-language-module-structure.md)
 
 ## Instructions
 

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

@@ -35,7 +35,7 @@ When developers or coding agents need too much detailed steering to complete a t
 
 #### 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.
+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
 

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

@@ -25,7 +25,7 @@ Language-specific EDRs MAY add ecosystem details, but they MUST NOT redefine the
 
 A module is the smallest independently buildable, testable, or publishable unit. It MUST live in its own folder and that folder MUST contain:
 
-- a `Makefile` following [agentme-edr-008](../devops/008-common-targets.md)
+- a `Makefile` following [agentme-edr-303](../platform/303-common-targets.md)
 - a `README.md` for the module itself
 - all configuration files needed to build, lint, test, package, or publish that module
 - its generated `dist/` directory when the module produces distributable artifacts
@@ -127,9 +127,9 @@ Benchmark tests MUST live in one of these locations:
 
 #### 08-module-makefiles-must-expose-shared-targets
 
-Every module `Makefile` MUST expose the common target names from [agentme-edr-008](../devops/008-common-targets.md). At minimum, modules MUST provide `build`, `lint`, and `test`, and SHOULD also provide `all`, `clean`, and `lint-fix` when meaningful.
+Every module `Makefile` MUST expose the common target names from [agentme-edr-303](../platform/303-common-targets.md). At minimum, modules MUST provide `build`, `lint`, and `test`, and SHOULD also provide `all`, `clean`, and `lint-fix` when meaningful.
 
 ## References
 
-- [agentme-edr-005](../devops/005-monorepo-structure.md) - Monorepo aggregation and delegation rules
-- [agentme-edr-008](../devops/008-common-targets.md) - Shared Makefile target names
+- [agentme-edr-301](../platform/301-monorepo-structure.md) - Monorepo aggregation and delegation rules
+- [agentme-edr-303](../platform/303-common-targets.md) - Shared Makefile target names

package/package.json

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