agentme 0.28.1 → 0.29.0

package/.filedist-package.yml

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

package/.xdrs/agentme/edrs/application/{003-javascript-project-tooling.md → 101-javascript-project-tooling.md}

@@ -1,11 +1,11 @@
 ---
-name: agentme-edr-policy-003-javascript-project-tooling-and-structure
+name: agentme-edr-policy-101-javascript-project-tooling-and-structure
 description: Defines the standard JavaScript and TypeScript project toolchain and layout using Mise, pnpm, TypeScript, ESLint, Jest, and Makefiles. Use when scaffolding or reviewing JavaScript projects.
 apply-to: JavaScript and TypeScript projects
 valid-from: 2026-05-25
 ---
 
-# agentme-edr-policy-003: JavaScript project tooling and structure
+# agentme-edr-policy-101: JavaScript project tooling and structure
 
 ## Context and Problem Statement
 
@@ -32,7 +32,7 @@ Clear, consistent tooling and layout enable fast onboarding, reliable CI pipelin
 | **eslint** | Linting — code style and quality enforcement |
 | **jest** | Testing — unit and integration test runner |
 
-All commands are run exclusively through Makefiles, not through `package.json` scripts. The repository root MUST define a `.mise.toml` that pins at least Node.js and pnpm. Contributors and CI MUST bootstrap with `make setup` or `mise install`, then invoke routine work with `make <target>`. Each Makefile recipe MUST execute the underlying tool through `mise exec -- <tool> ...`, following [agentme-edr-017](../platform/017-tool-execution-and-scripting.md). Calling project tools directly in docs, CI, or daily workflows instead of `make <target>` is not allowed.
+All commands are run exclusively through Makefiles, not through `package.json` scripts. The repository root MUST define a `.mise.toml` that pins at least Node.js and pnpm. Contributors and CI MUST bootstrap with `make setup` or `mise install`, then invoke routine work with `make <target>`. Each Makefile recipe MUST execute the underlying tool through `mise exec -- <tool> ...`, following [agentme-edr-304](../platform/304-tool-execution-and-scripting.md). Calling project tools directly in docs, CI, or daily workflows instead of `make <target>` is not allowed.
 
 #### ESLint
 
@@ -48,7 +48,7 @@ When `tsconfig.json` extends `@tsconfig/node24/tsconfig.json`, the default `modu
 
 #### Coverage
 
-Jest must enforce 80% line and branch coverage, following [agentme-edr-004](004-unit-test-requirements.md). Configure thresholds in `lib/jest.config.js`:
+Jest must enforce 80% line and branch coverage, following [agentme-edr-122](122-unit-test-requirements.md). Configure thresholds in `lib/jest.config.js`:
 
 ```js
 coverageThreshold: {
@@ -82,7 +82,7 @@ Builds that miss the threshold MUST NOT be merged.
 │   ├── dist/              # compiled files and packed .tgz artifacts
 │   └── src/               # all TypeScript source files
 │       ├── index.ts       # public API re-exports from app/
-│       ├── adapters/      # I/O boundary layer (following agentme-edr-026)
+│       ├── adapters/      # I/O boundary layer (following agentme-edr-126)
 │       │   ├── cli/       # inbound: CLI bootstrap and entry point
 │       │   ├── http/      # inbound: HTTP server bootstrap and handlers
 │       │   └── connectors/ # outbound: one folder per external resource
@@ -101,7 +101,7 @@ Builds that miss the threshold MUST NOT be merged.
 
 The root `Makefile` delegates every target to `/lib` then `/examples` in sequence. Parent Makefiles should call child Makefiles directly, and each module Makefile is responsible for running its actual tool commands through `mise exec --`.
 
-Internal source code MUST be organized following [agentme-edr-026](026-pragmatic-hexagonal-architecture.md): `adapters/` (inbound and outbound I/O boundaries), `app/` (business logic), and `shared/` (infrastructure-agnostic utilities). The public API entry point (`index.ts`) re-exports from `app/`.
+Internal source code MUST be organized following [agentme-edr-126](126-pragmatic-hexagonal-architecture.md): `adapters/` (inbound and outbound I/O boundaries), `app/` (business logic), and `shared/` (infrastructure-agnostic utilities). The public API entry point (`index.ts`) re-exports from `app/`.
 
 When a repository contains multiple JavaScript/TypeScript packages, each package MUST live in its own module folder such as `lib/my-package/` or `services/my-service/`, each with its own `Makefile`, `README.md`, `dist/`, and `.cache/`.
 
@@ -154,7 +154,7 @@ The examples folder MUST exist for any libraries and utilities that are publishe
 
 ## References
 
-- [agentme-edr-004](004-unit-test-requirements.md) — Coverage and unit-test baseline
-- [agentme-edr-026](026-pragmatic-hexagonal-architecture.md) — Internal adapter/application layer separation for applications
+- [agentme-edr-122](122-unit-test-requirements.md) — Coverage and unit-test baseline
+- [agentme-edr-126](126-pragmatic-hexagonal-architecture.md) — Internal adapter/application layer separation for applications
 - [001-create-javascript-project](skills/001-create-javascript-project/SKILL.md) — scaffolds a new project following this structure
 

package/.xdrs/agentme/edrs/application/{010-golang-project-tooling.md → 102-golang-project-tooling.md}

@@ -1,11 +1,11 @@
 ---
-name: agentme-edr-policy-010-go-project-tooling-and-structure
+name: agentme-edr-policy-102-go-project-tooling-and-structure
 description: Defines the standard Go project toolchain, layout, and Makefile workflow using Mise for agentme-based projects. Use when scaffolding or reviewing Go projects.
 apply-to: Go projects
 valid-from: 2026-05-25
 ---
 
-# agentme-edr-policy-010: Go project tooling and structure
+# agentme-edr-policy-102: Go project tooling and structure
 
 ## Context and Problem Statement
 
@@ -30,7 +30,7 @@ A predictable layout and minimal external tooling keep Go projects approachable,
 | **golangci-lint** | Linting — aggregates many linters in one fast run; configured via `.golangci.yml` |
 | **monotag** | Version tagging from git history for the `publish` target |
 
-All commands MUST be run exclusively through the Makefile and MUST NOT be called ad-hoc. The project root **MUST** define a `.mise.toml` that pins `go`, `golangci-lint`, and any other Go-related CLIs used by the project. Contributors and CI **MUST** bootstrap with `make setup` or `mise install`, then invoke routine work with `make <target>`. Each Makefile recipe **MUST** execute the underlying tool through `mise exec -- <tool> ...`, following [agentme-edr-017](../platform/017-tool-execution-and-scripting.md).
+All commands MUST be run exclusively through the Makefile and MUST NOT be called ad-hoc. The project root **MUST** define a `.mise.toml` that pins `go`, `golangci-lint`, and any other Go-related CLIs used by the project. Contributors and CI **MUST** bootstrap with `make setup` or `mise install`, then invoke routine work with `make <target>`. Each Makefile recipe **MUST** execute the underlying tool through `mise exec -- <tool> ...`, following [agentme-edr-304](../platform/304-tool-execution-and-scripting.md).
 Direct installation of project-required Go CLIs with `go install ...@latest` as a repair step is **NOT** allowed unless an XDR for that repository explicitly permits it.
 
 #### Project structure
@@ -47,7 +47,7 @@ Direct installation of project-required Go CLIs with `go install ...@latest` as
 ├── main.go                    # binary entry point — argument dispatch only, no logic
 ├── .cache/                    # GOCACHE, GOMODCACHE, golangci-lint cache, coverage
 ├── dist/                      # built binaries and packaged outputs
-├── adapters/                  # I/O boundary layer (following agentme-edr-026)
+├── adapters/                  # I/O boundary layer (following agentme-edr-126)
 │   ├── cli/                   # inbound: CLI wiring — flag parsing, output formatting
 │   │   └── *.go               # subfolders per feature only when complexity warrants it
 │   ├── http/                  # inbound: HTTP server bootstrap and handlers
@@ -73,7 +73,7 @@ Direct installation of project-required Go CLIs with `go install ...@latest` as
 
 **Key layout rules:**
 
-- Internal source code is organized following [agentme-edr-026](026-pragmatic-hexagonal-architecture.md): `adapters/` (inbound and outbound I/O boundaries), `app/` (business logic), and `shared/` (infrastructure-agnostic utilities).
+- Internal source code is organized following [agentme-edr-126](126-pragmatic-hexagonal-architecture.md): `adapters/` (inbound and outbound I/O boundaries), `app/` (business logic), and `shared/` (infrastructure-agnostic utilities).
 - One Go module per project (`go.mod` at the project root). In a monorepo, each Go project has its own `go.mod` in its subdirectory. No nested modules within a single project unless explicitly justified.
 - In a multi-module repository, each Go module MUST live in its own folder root with its own `Makefile`, `README.md`, `dist/`, and `.cache/`.
 - `main.go` is solely an argument dispatcher — it reads `os.Args[1]` and delegates to an `adapters/cli/<feature>/Run*()` function. No domain logic lives in `main.go`.
@@ -178,5 +178,5 @@ Use the standard library `flag` package for CLI flags. Each `adapters/cli/<featu
 
 ## References
 
-- [agentme-edr-026](026-pragmatic-hexagonal-architecture.md) — Defines the adapter/application separation that this layout follows
+- [agentme-edr-126](126-pragmatic-hexagonal-architecture.md) — Defines the adapter/application separation that this layout follows
 - [003-create-golang-project](skills/003-create-golang-project/SKILL.md) — scaffolds a new Go project following this structure

package/.xdrs/agentme/edrs/application/{014-python-project-tooling.md → 103-python-project-tooling.md}

@@ -1,11 +1,11 @@
 ---
-name: agentme-edr-policy-014-python-project-tooling-and-structure
+name: agentme-edr-policy-103-python-project-tooling-and-structure
 description: Defines the standard Python project toolchain, layout, and Makefile workflow using Mise, uv, ruff, ty, pytest, and pip-audit. Use when scaffolding or reviewing Python projects.
 apply-to: Python projects
 valid-from: 2026-05-25
 ---
 
-# agentme-edr-policy-014: Python project tooling and structure
+# agentme-edr-policy-103: Python project tooling and structure
 
 ## Context and Problem Statement
 
@@ -36,7 +36,7 @@ A single dependency manager, isolated package internals under `lib/`, and a stan
 
 All routine commands MUST run through the project `Makefile`. MUST NOT call `uv`, `ruff`, `pytest`, or `ty` directly in docs, CI, or daily development workflows.
 
-The repository root MUST define a `.mise.toml` that pins Python and uv. Contributors and CI MUST bootstrap with `make setup` or `mise install`, then invoke routine work with `make <target>`. Each Makefile recipe MUST execute the underlying tool through `mise exec -- <tool> ...`, following [agentme-edr-017](../platform/017-tool-execution-and-scripting.md). Using routine project CLI commands directly outside the Makefile contract is not allowed.
+The repository root MUST define a `.mise.toml` that pins Python and uv. Contributors and CI MUST bootstrap with `make setup` or `mise install`, then invoke routine work with `make <target>`. Each Makefile recipe MUST execute the underlying tool through `mise exec -- <tool> ...`, following [agentme-edr-304](../platform/304-tool-execution-and-scripting.md). Using routine project CLI commands directly outside the Makefile contract is not allowed.
 
 The root `.venv/` is the canonical environment location for both the library and all examples. Subdirectory commands MUST set `UV_PROJECT_ENVIRONMENT` to the workspace root `.venv/` instead of creating nested virtual environments.
 
@@ -71,7 +71,7 @@ Tools MUST NOT write cache or state files to the project root, `src/`, `tests/`,
 │   ├── src/
 │   │   └── <package_name>/
 │   │       ├── __init__.py
-│   │       ├── adapters/       # I/O boundary layer (following agentme-edr-026)
+│   │       ├── adapters/       # I/O boundary layer (following agentme-edr-126)
 │   │       │   ├── cli/        # inbound: CLI bootstrap and entry point
 │   │       │   ├── http/       # inbound: HTTP server bootstrap
 │   │       │   └── connectors/ # outbound: one folder per external resource
@@ -96,9 +96,9 @@ Keep the repository root clean: source code, tests, distribution artifacts, and
 
 Use the `lib/src/` layout for import safety and packaging clarity. Keep tests under `lib/tests/` and shared test setup in `lib/tests/conftest.py`. Do not introduce `requirements.txt`, `setup.py`, `setup.cfg`, `tox.ini`, `ruff.toml`, or `ty.toml` by default; keep project metadata and tool configuration in `lib/pyproject.toml`.
 
-Internal source code MUST be organized following [agentme-edr-026](026-pragmatic-hexagonal-architecture.md): `adapters/` (inbound and outbound I/O boundaries), `app/` (business logic), and `shared/` (infrastructure-agnostic utilities).
+Internal source code MUST be organized following [agentme-edr-126](126-pragmatic-hexagonal-architecture.md): `adapters/` (inbound and outbound I/O boundaries), `app/` (business logic), and `shared/` (infrastructure-agnostic utilities).
 
-Libraries and shared utilities MUST include an `examples/` folder and wire example execution into the root `test` flow, following [agentme-edr-007](../governance/007-project-quality-standards.md). Each example directory is its own Python project with its own `pyproject.toml`, and examples MUST import the library as a consumer would rather than reaching back into `lib/src/` with relative imports. Local example verification MUST install the wheel built into `lib/dist/`; do not use editable or path-based dependencies back to `lib/`.
+Libraries and shared utilities MUST include an `examples/` folder and wire example execution into the root `test` flow, following [agentme-edr-501](../governance/501-project-quality-standards.md). Each example directory is its own Python project with its own `pyproject.toml`, and examples MUST import the library as a consumer would rather than reaching back into `lib/src/` with relative imports. Local example verification MUST install the wheel built into `lib/dist/`; do not use editable or path-based dependencies back to `lib/`.
 
 Python keeps unit tests under `lib/tests/` by default because that remains the more common and maintainable convention for typed/package-based projects than co-locating tests beside every source file. Integration tests belong in `lib/tests_integration/`, and benchmark harnesses belong in `lib/tests_benchmark/` when they are more than a single micro-benchmark helper.
 
@@ -159,7 +159,7 @@ Adjust `target-version` to match the project's minimum supported Python version.
 
 ty MUST run on every lint pass. The default rule set is the minimum baseline; projects may enable stricter rules as the codebase matures.
 
-Pytest coverage MUST fail below 80% line and branch coverage, following [agentme-edr-004](004-unit-test-requirements.md).
+Pytest coverage MUST fail below 80% line and branch coverage, following [agentme-edr-122](122-unit-test-requirements.md).
 
 #### Makefile targets
 
@@ -198,7 +198,7 @@ The root `Makefile` is the only contract for CI and contributors. It delegates l
 | `dev` | Same as `run`, optionally with repository-specific dev defaults |
 | `publish` | `mise exec -- uv publish --project .` after versioning and packaging are complete |
 
-The root `Makefile` MUST remain the only contract for CI and contributors, in line with [agentme-edr-008](../platform/008-common-targets.md).
+The root `Makefile` MUST remain the only contract for CI and contributors, in line with [agentme-edr-303](../platform/303-common-targets.md).
 
 ## Considered Options
 
@@ -209,7 +209,7 @@ The root `Makefile` MUST remain the only contract for CI and contributors, in li
 
 ## References
 
-- [agentme-edr-004](004-unit-test-requirements.md) - Coverage and unit-test baseline
-- [agentme-edr-007](../governance/007-project-quality-standards.md) - Examples and quality requirements
-- [agentme-edr-008](../platform/008-common-targets.md) - Standard Makefile target names
+- [agentme-edr-122](122-unit-test-requirements.md) - Coverage and unit-test baseline
+- [agentme-edr-501](../governance/501-project-quality-standards.md) - Examples and quality requirements
+- [agentme-edr-303](../platform/303-common-targets.md) - Standard Makefile target names
 - [005-create-python-project](skills/005-create-python-project/SKILL.md) - Scaffold a project following this EDR

package/.xdrs/agentme/edrs/application/{015-cli-tool-standards.md → 104-cli-tool-standards.md}

@@ -1,11 +1,11 @@
 ---
-name: agentme-edr-policy-015-cli-tool-standards
+name: agentme-edr-policy-104-cli-tool-standards
 description: Defines how distributable CLI tools should separate command handling from library logic and expose consistent command behavior. Use when designing or reviewing CLI interfaces.
 apply-to: Projects with distributable CLI tools
 valid-from: 2026-05-25
 ---
 
-# agentme-edr-policy-015: CLI tool standards
+# agentme-edr-policy-104: CLI tool standards
 
 ## Context and Problem Statement
 
@@ -34,7 +34,7 @@ This keeps the user-facing command predictable while preserving a clean library
 
 #### CLI to application separation
 
-- Structure the software as `cli -> app` — the CLI adapter delegates to the application layer, following [agentme-edr-026](026-pragmatic-hexagonal-architecture.md).
+- Structure the software as `cli -> app` — the CLI adapter delegates to the application layer, following [agentme-edr-126](126-pragmatic-hexagonal-architecture.md). For unit testing the application layer and mocking outbound connectors, follow [agentme-edr-126 rule `09`](126-pragmatic-hexagonal-architecture.md#09-unit-testing-and-mocking-strategy).
 - The CLI layer MUST only parse arguments, load config, call the application layer, and format output.
 - Domain logic MUST live in the application layer and be usable without CLI globals such as `argv`, `stdout`, or process exit handlers.
 - Every feature available through the CLI MUST also be available through the application API.
@@ -53,7 +53,7 @@ This keeps the user-facing command predictable while preserving a clean library
 #### Configuration
 
 - Prefer flags and positional arguments for simple inputs.
-- When configuration becomes long, nested, or repetitive, use a YAML config file instead of pushing all values into flags. See [agentme-edr-027](../platform/027-environment-variable-configuration.md) for when `.env` values should be referenced from within that file.
+- When configuration becomes long, nested, or repetitive, use a YAML config file instead of pushing all values into flags. See [agentme-edr-305](../platform/305-environment-variable-configuration.md) for when `.env` values should be referenced from within that file.
 - By default, config-file discovery and loading MUST happen in the CLI layer, not in the application layer.
 - When a config file is supported, the CLI MUST try to load a YAML file from `[cwd]/[tool-name].yml` by default.
 - The CLI MUST also support an explicit config path flag such as `--config`.
@@ -87,7 +87,7 @@ This keeps the user-facing command predictable while preserving a clean library
 - Choose language tooling that stays compatible with ecosystem launchers such as `npx`, `pnpm dlx`, `uvx`, or equivalent distribution commands for that ecosystem.
 - `--version` MUST print the same version declared in the published package or release artifact metadata.
 - Do not hard-code a second version string that can drift from the published package version.
-- Language-specific project structure and packaging rules still apply and SHOULD be combined with this XDR, especially [agentme-edr-003](003-javascript-project-tooling.md), [agentme-edr-010](010-golang-project-tooling.md), and [agentme-edr-014](014-python-project-tooling.md).
+- Language-specific project structure and packaging rules still apply and SHOULD be combined with this XDR, especially [agentme-edr-101](101-javascript-project-tooling.md), [agentme-edr-102](102-golang-project-tooling.md), and [agentme-edr-103](103-python-project-tooling.md).
 
 ## Considered Options
 
@@ -98,11 +98,11 @@ This keeps the user-facing command predictable while preserving a clean library
 
 ## References
 
-- [agentme-edr-026](026-pragmatic-hexagonal-architecture.md) - Defines the adapter/application separation that the CLI layer follows
-- [agentme-edr-003](003-javascript-project-tooling.md) - JavaScript project packaging and structure
-- [agentme-edr-007](../governance/007-project-quality-standards.md) - README and examples baseline
-- [agentme-edr-008](../platform/008-common-targets.md) - Standard command names for project entry points
-- [agentme-edr-009](009-error-handling.md) - Process error signaling and error handling expectations
-- [agentme-edr-010](010-golang-project-tooling.md) - Go CLI structure and verbose logging baseline
-- [agentme-edr-014](014-python-project-tooling.md) - Python packaging and CLI entry-point guidance
-- [agentme-edr-027](../platform/027-environment-variable-configuration.md) - Environment variable configuration files; defines how `.env` values are referenced from YAML config files
+- [agentme-edr-126](126-pragmatic-hexagonal-architecture.md) - Defines the adapter/application separation that the CLI layer follows
+- [agentme-edr-101](101-javascript-project-tooling.md) - JavaScript project packaging and structure
+- [agentme-edr-501](../governance/501-project-quality-standards.md) - README and examples baseline
+- [agentme-edr-303](../platform/303-common-targets.md) - Standard command names for project entry points
+- [agentme-edr-123](123-error-handling.md) - Process error signaling and error handling expectations
+- [agentme-edr-102](102-golang-project-tooling.md) - Go CLI structure and verbose logging baseline
+- [agentme-edr-103](103-python-project-tooling.md) - Python packaging and CLI entry-point guidance
+- [agentme-edr-305](../platform/305-environment-variable-configuration.md) - Environment variable configuration files; defines how `.env` values are referenced from YAML config files

package/.xdrs/agentme/edrs/application/{002-coding-best-practices.md → 121-coding-best-practices.md}

@@ -1,11 +1,11 @@
 ---
-name: agentme-edr-policy-002-coding-best-practices
+name: agentme-edr-policy-121-coding-best-practices
 description: Defines cross-language coding practices for keeping code readable, modular, and synchronized with tests and documentation. Apply across projects adopting agentme engineering standards.
 apply-to: All software projects
 valid-from: 2026-05-25
 ---
 
-# agentme-edr-policy-002: Coding best practices
+# agentme-edr-policy-121: Coding best practices
 
 ## Context and Problem Statement
 
@@ -116,4 +116,4 @@ Types used in only **one** file MUST be declared in that same file. Move a type
 
 #### 06-keep-test-files-next-to-source
 
-Test files MUST be placed beside the source file they cover, following the co-location and naming conventions defined in [agentme-edr-004 rule 04](004-unit-test-requirements.md). For Rust, use inline `#[cfg(test)]` modules instead of a separate test file.
+Test files MUST be placed beside the source file they cover, following the co-location and naming conventions defined in [agentme-edr-122 rule 04](122-unit-test-requirements.md). For Rust, use inline `#[cfg(test)]` modules instead of a separate test file.

package/.xdrs/agentme/edrs/application/{004-unit-test-requirements.md → 122-unit-test-requirements.md}

@@ -1,11 +1,11 @@
 ---
-name: agentme-edr-policy-004-unit-test-requirements
+name: agentme-edr-policy-122-unit-test-requirements
 description: Defines unit test requirements for assertions, offline execution, coverage, shared setup, and real-code preference. Use when writing or reviewing tests.
 apply-to: All projects with unit tests
 valid-from: 2026-05-25
 ---
 
-# agentme-edr-policy-004: Unit test requirements
+# agentme-edr-policy-122: Unit test requirements
 
 ## Context and Problem Statement
 

package/.xdrs/agentme/edrs/application/{009-error-handling.md → 123-error-handling.md}

@@ -1,11 +1,11 @@
 ---
-name: agentme-edr-policy-009-error-handling
+name: agentme-edr-policy-123-error-handling
 description: Defines error handling practices for catching, propagating, surfacing, and testing failures consistently across projects. Use when implementing interfaces and failure paths.
 apply-to: All software projects
 valid-from: 2026-05-25
 ---
 
-# agentme-edr-policy-009: Error handling
+# agentme-edr-policy-123: Error handling
 
 ## Context and Problem Statement
 

package/.xdrs/agentme/edrs/application/{022-secrets-management.md → 124-secrets-management.md}

@@ -1,11 +1,11 @@
 ---
-name: agentme-edr-policy-022-secrets-management
+name: agentme-edr-policy-124-secrets-management
 description: Defines how secrets (API keys, passwords, tokens, credentials, private certificates) must be stored, fetched, and provisioned. Use when implementing secret handling in any language or deployment target.
 apply-to: All software projects handling secrets
 valid-from: 2026-05-28
 ---
 
-# agentme-edr-policy-022: Secrets management
+# agentme-edr-policy-124: Secrets management
 
 ## Context and Problem Statement
 
@@ -45,7 +45,7 @@ During local development, secrets MUST be stored and retrieved using the native
 | JavaScript/TypeScript | `cross-keychain` |
 | Go | `go-keyring` |
 
-The "group" (service name) defaults to the module name. The secret identifier should match the ID used in the cloud secret manager for consistency.
+The "group" (service name) defaults to the module name. The secret identifier SHOULD match the ID used in the cloud secret manager for consistency.
 
 ---
 
@@ -164,5 +164,5 @@ In library code (Python, JS/TS, Go), continue using the cross-platform libraries
 
 ## References
 
-- [agentme-edr-008](../platform/008-common-targets.md) - Common development script names (defines Makefile target conventions)
-- [agentme-edr-009](009-error-handling.md) - Error handling (governs how the fallback exception should be raised)
+- [agentme-edr-303](../platform/303-common-targets.md) - Common development script names (defines Makefile target conventions)
+- [agentme-edr-123](123-error-handling.md) - Error handling (governs how the fallback exception should be raised)

package/.xdrs/agentme/edrs/application/{023-coding-abstraction-practices.md → 125-coding-abstraction-practices.md}

@@ -1,11 +1,11 @@
 ---
-name: agentme-edr-policy-023-coding-abstraction-practices
-description: Defines when abstractions (functions, classes, wrappers, factories) are justified and when they must be avoided. Tightly related to agentme-edr-policy-002-coding-best-practices.
+name: agentme-edr-policy-125-coding-abstraction-practices
+description: Defines when abstractions (functions, classes, wrappers, factories) are justified and when they must be avoided. Tightly related to agentme-edr-policy-121-coding-best-practices.
 apply-to: All software projects
 valid-from: 2026-05-29
 ---
 
-# agentme-edr-policy-023: Coding abstraction practices
+# agentme-edr-policy-125: Coding abstraction practices
 
 ## Context and Problem Statement
 

package/.xdrs/agentme/edrs/application/{026-pragmatic-hexagonal-architecture.md → 126-pragmatic-hexagonal-architecture.md}

@@ -1,11 +1,11 @@
 ---
-name: agentme-edr-policy-026-pragmatic-hexagonal-architecture
+name: agentme-edr-policy-126-pragmatic-hexagonal-architecture
 description: Defines a pragmatic variant of Hexagonal Architecture for organizing application source code into Adapters (inbound/outbound I/O boundaries) and Application (business logic) layers, with explicit naming conventions and folder structure. Use when designing or reviewing the internal layout of application modules.
 apply-to: All application projects
 valid-from: 2026-05-28
 ---
 
-# agentme-edr-policy-026: Pragmatic hexagonal architecture
+# agentme-edr-policy-126: Pragmatic hexagonal architecture
 
 ## Context and Problem Statement
 
@@ -56,7 +56,7 @@ Adapters MUST follow these naming conventions:
 - 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)
-- Environment variables must be read only in the bootstrap/entry-point layer of inbound adapters, converted into typed configuration objects, and passed explicitly to all other components
+- Environment variables MUST be read only in the bootstrap/entry-point layer of inbound adapters, converted into typed configuration objects, and passed explicitly to all other components
 
 - Data flow examples
 
@@ -102,7 +102,7 @@ mysystem/
 #### 06-bootstrap-and-entry-points
 
 - 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](../platform/008-common-targets.md) extension conventions (e.g. `run-http`, `run-grpc`)
+- The project root Makefile MUST have targets to run the different inbound interfaces following [agentme-edr-303](../platform/303-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
 
 #### 07-minimum-complexity-threshold
@@ -133,7 +133,7 @@ Inbound adapters (`cli/`, `http/`, `grpc/`) are entry points and do not need to
 
 #### 10-mock-file-strategy
 
-When a mock implementation needs to be **reused across multiple tests or imported by an eval script** (e.g. `eval.py` using `mock_fixtures` from [agentme-edr-052](052-ai-test-types-taxonomy.md) rule `02`), define it in a dedicated `_mock` file rather than inline.
+When a mock implementation needs to be **reused across multiple tests or imported by an eval script** (e.g. `eval.py` using `mock_fixtures` from [agentme-edr-152](152-ai-test-types-taxonomy.md) rule `02`), define it in a dedicated `_mock` file rather than inline.
 
 **When to use a `_mock` file vs inline:**
 - Single-test use → define the mock inline inside the test file (per rule `09` example; no file needed)
@@ -149,7 +149,7 @@ When a mock implementation needs to be **reused across multiple tests or importe
 | `order_service.ts` | `order_service_mock.ts` |
 | `user_store.go` | `user_store_mock_test.go` |
 
-**Placement:** follows the project's test file placement convention per [agentme-edr-004](004-unit-test-requirements.md) rule `04`:
+**Placement:** follows the project's test file placement convention per [agentme-edr-122](122-unit-test-requirements.md) rule `04`:
 - Co-located test convention (TypeScript, Go) → mock file in the same directory as the source file
 - Separate test folder convention (Python) → mock file mirrors the source path under the test folder (e.g. `lib/src/<pkg>/adapters/connectors/user-db/client.py` → `lib/tests/<pkg>/adapters/connectors/user-db/client_mock.py`)
 
@@ -160,6 +160,6 @@ When a mock implementation needs to be **reused across multiple tests or importe
 ## References
 
 - [agentme-edr-016](../principles/016-cross-language-module-structure.md) — Defines the module-root structure (Makefile, dist/, .cache/) that wraps this internal layout
-- [agentme-edr-002](002-coding-best-practices.md) — File size limits and code organization practices that complement this architecture
-- [agentme-edr-004](004-unit-test-requirements.md) — Rule `04`: test file placement convention per language (governs `_mock` file placement in rule `10`)
-- [agentme-edr-052](052-ai-test-types-taxonomy.md) — Rule `02`: `mock_fixtures` golden dataset envelope that drives `_mock` usage in eval scripts
+- [agentme-edr-121](121-coding-best-practices.md) — File size limits and code organization practices that complement this architecture
+- [agentme-edr-122](122-unit-test-requirements.md) — Rule `04`: test file placement convention per language (governs `_mock` file placement in rule `10`)
+- [agentme-edr-152](152-ai-test-types-taxonomy.md) — Rule `02`: `mock_fixtures` golden dataset envelope that drives `_mock` usage in eval scripts

package/.xdrs/agentme/edrs/application/{040-ai-llm-development-standards.md → 141-ai-llm-development-standards.md}

@@ -1,11 +1,11 @@
 ---
-name: agentme-edr-policy-040-ai-llm-development-standards
-description: Defines the standard framework, provider configuration, observability approach, and LLM mocking patterns for simple LLM calls in Python. Use when building, reviewing, or scaffolding any code that makes direct LLM calls using LangChain, manages prompt context, or handles conversation history. For agentic patterns see agentme-edr-041, for workflow patterns see agentme-edr-043.
+name: agentme-edr-policy-141-ai-llm-development-standards
+description: Defines the standard framework, provider configuration, observability approach, and LLM mocking patterns for simple LLM calls in Python. Use when building, reviewing, or scaffolding any code that makes direct LLM calls using LangChain, manages prompt context, or handles conversation history. For agentic patterns see agentme-edr-142, for workflow patterns see agentme-edr-144.
 apply-to: Python projects that make direct LLM calls, manage prompt context, or handle conversation threads
 valid-from: 2026-06-05
 ---
 
-# agentme-edr-policy-040: AI LLM development standards
+# agentme-edr-policy-141: AI LLM development standards
 
 ## Context and Problem Statement
 
@@ -29,7 +29,7 @@ Three distinct tiers of LLM-based computation are recognized in this policy. Eve
 
 These tiers nest: in general, a Workflow may contain Agent nodes; an Agent uses LLM calls internally. The tier of a component is determined by its outermost controlling structure.
 
-See [agentme-edr-041](041-ai-agents-development-standards.md) for Agent implementation standards and [agentme-edr-043](043-ai-workflow-development-standards.md) for Workflow implementation standards.
+See [agentme-edr-142](142-ai-agents-development-standards.md) for Agent implementation standards and [agentme-edr-144](144-ai-workflow-development-standards.md) for Workflow implementation standards.
 
 ### Details
 
@@ -44,7 +44,7 @@ Every component that interacts with an LLM MUST be classified as exactly one of
 **Function calling boundary:**
 
 - A **single** function call decided by the LLM (e.g., "call get_weather(location)") is still an LLM-tier interaction if the function is called once and the result is returned to the user.
-- An **iterative** function-calling loop where the LLM observes results and decides next actions autonomously is an Agent (see [agentme-edr-041](041-ai-agents-development-standards.md)).
+- An **iterative** function-calling loop where the LLM observes results and decides next actions autonomously is an Agent (see [agentme-edr-142](142-ai-agents-development-standards.md)).
 
 #### 02-llm-framework
 
@@ -71,7 +71,7 @@ llm = ChatOpenAI(
 Enable LangChain auto-tracing at every application entry point by calling `mlflow.langchain.autolog()` during startup, before any LLM call is made.
 
 - This captures inputs, outputs, token counts, and latency for every LangChain chain or runnable automatically.
-- The project Makefile MUST expose a `dev-mlflow` target to start a local MLflow tracking server for development inspection, per [agentme-edr-008](../platform/008-common-targets.md) rule `09-ai-project-dev-targets`.
+- The project Makefile MUST expose a `dev-mlflow` target to start a local MLflow tracking server for development inspection, per [agentme-edr-303](../platform/303-common-targets.md) rule `09-ai-project-dev-targets`.
 
 #### 04-unit-test-mocking
 
@@ -213,11 +213,11 @@ Return a JSON object with:
 
 ## References
 
-- [agentme-edr-041](041-ai-agents-development-standards.md) — Agent implementation standards (deepagents, tool-invocation loops)
-- [agentme-edr-043](043-ai-workflow-development-standards.md) — Workflow implementation standards (LangGraph, MLflow run-level tracking)
-- [agentme-edr-004](004-unit-test-requirements.md) — Unit test requirements including external API mocking guidance
-- [agentme-edr-014](014-python-project-tooling.md) — Python project tooling and structure
-- [agentme-edr-007](../governance/007-project-quality-standards.md) — Project quality standards including AI-tier testing requirements (rule `09-ai-project-testing-requirements`)
-- [agentme-edr-051](051-ai-eval-core-standards.md) — AI eval core standards: eval folder structure (rule `01`) and LLM-as-judge binary scoring contract (rule `02`)
-- [agentme-edr-053](053-ai-eval-script.md) — AI eval script: entry-first loop, `--type` filtering, `mock_fixtures`, and MLflow conventions
-- [agentme-edr-054](054-ai-eval-report-format.md) — AI eval report format: `report-<type>.md` template, Wilson CI, and convergence analysis
+- [agentme-edr-142](142-ai-agents-development-standards.md) — Agent implementation standards (deepagents, tool-invocation loops)
+- [agentme-edr-144](144-ai-workflow-development-standards.md) — Workflow implementation standards (LangGraph, MLflow run-level tracking)
+- [agentme-edr-122](122-unit-test-requirements.md) — Unit test requirements including external API mocking guidance
+- [agentme-edr-103](103-python-project-tooling.md) — Python project tooling and structure
+- [agentme-edr-501](../governance/501-project-quality-standards.md) — Project quality standards including AI-tier testing requirements (rule `09-ai-project-testing-requirements`)
+- [agentme-edr-151](151-ai-eval-core-standards.md) — AI eval core standards: eval folder structure (rule `01`) and LLM-as-judge binary scoring contract (rule `02`)
+- [agentme-edr-153](153-ai-eval-script.md) — AI eval script: entry-first loop, `--type` filtering, `mock_fixtures`, and MLflow conventions
+- [agentme-edr-154](154-ai-eval-report-format.md) — AI eval report format: `report-<type>.md` template, Wilson CI, and convergence analysis

package/.xdrs/agentme/edrs/application/{041-ai-agents-development-standards.md → 142-ai-agents-development-standards.md}

@@ -1,11 +1,11 @@
 ---
-name: agentme-edr-policy-041-ai-agents-development-standards
-description: Defines the structural patterns and design decisions for building AI agents with tool-invocation loops using the deepagents framework: framework selection, sandbox setup, state naming, agent naming, composition patterns, and system prompt structure. Use when designing or scaffolding a new agent. For tool definitions, error handling, observability, and testing see agentme-edr-042. For simple LLM calls see agentme-edr-040, for workflow orchestration see agentme-edr-043.
+name: agentme-edr-policy-142-ai-agents-development-standards
+description: Defines the structural patterns and design decisions for building AI agents with tool-invocation loops using the deepagents framework: framework selection, sandbox setup, state naming, agent naming, composition patterns, and system prompt structure. Use when designing or scaffolding a new agent. For tool definitions, error handling, observability, and testing see agentme-edr-143. For simple LLM calls see agentme-edr-141, for workflow orchestration see agentme-edr-144.
 apply-to: AI agent projects — consult when designing agent structure, choosing sandbox approach, defining naming conventions, and composing multi-agent systems
 valid-from: 2026-06-05
 ---
 
-# agentme-edr-policy-041: AI agents development standards
+# agentme-edr-policy-142: AI agents development standards
 
 ## Context and Problem Statement
 
@@ -29,7 +29,7 @@ All agent implementations MUST use the **deepagents** framework.
 
 - Use deepagents whenever the LLM needs to autonomously select and invoke tools to accomplish a task.
 - The agent MUST follow the perceive → plan → act → observe cycle where the LLM observes tool outputs and decides the next action.
-- All LLM calls within agents MUST follow [agentme-edr-040](040-ai-llm-development-standards.md) for LangChain configuration and observability.
+- All LLM calls within agents MUST follow [agentme-edr-141](141-ai-llm-development-standards.md) for LangChain configuration and observability.
 
 **When to use agents vs workflows:**
 
@@ -87,7 +87,7 @@ def run_file_analysis_agent(input_files: List[Path]) -> AnalysisResult:
 **State type naming:**
 
 - Agent state types MUST end with `_agent_state` suffix (e.g., `file_analyzer_agent_state`)
-- Follow [agentme-edr-043](043-ai-workflow-development-standards.md) rule `11-state-type-conventions` when agents are used as workflow nodes
+- Follow [agentme-edr-144](144-ai-workflow-development-standards.md) rule `11-state-type-conventions` when agents are used as workflow nodes
 
 #### 04-agent-naming-conventions
 
@@ -104,14 +104,14 @@ Agent class names MUST follow the pattern `<Purpose>Agent` where `<Purpose>` des
 - `MyAgent` (not descriptive)
 - `Agent1` (numbered, not semantic)
 
-When agents are used as nodes in workflows, the node name MUST use the `_agent` suffix per [agentme-edr-043](043-ai-workflow-development-standards.md) rule `09-node-naming-conventions`.
+When agents are used as nodes in workflows, the node name MUST use the `_agent` suffix per [agentme-edr-144](144-ai-workflow-development-standards.md) rule `09-node-naming-conventions`.
 
 #### 05-agent-composition
 
 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-043](043-ai-workflow-development-standards.md).
+- **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-144](144-ai-workflow-development-standards.md).
 - Nested agent loops (agent calling agent autonomously) MUST NOT be created. Use workflows for multi-agent orchestration.
 
 **Decision criteria:**
@@ -267,7 +267,7 @@ def parse_agent_output(raw: str) -> FileAnalysisResult:
 
 ## References
 
-- [agentme-edr-040](040-ai-llm-development-standards.md) — LLM development standards (LangChain configuration, mocking patterns)
-- [agentme-edr-043](043-ai-workflow-development-standards.md) — Workflow development standards (using agents as workflow nodes)
-- [agentme-edr-042](042-ai-agents-quality-standards.md) — Agent implementation quality standards (tool definitions, error handling, observability, unit testing)
-- [agentme-edr-014](014-python-project-tooling.md) — Python project tooling and structure
+- [agentme-edr-141](141-ai-llm-development-standards.md) — LLM development standards (LangChain configuration, mocking patterns)
+- [agentme-edr-144](144-ai-workflow-development-standards.md) — Workflow development standards (using agents as workflow nodes)
+- [agentme-edr-143](143-ai-agents-quality-standards.md) — Agent implementation quality standards (tool definitions, error handling, observability, unit testing)
+- [agentme-edr-103](103-python-project-tooling.md) — Python project tooling and structure