agentme 0.7.4 → 0.8.0

package/.specify/memory/constitution.md

@@ -40,78 +40,59 @@ vibe coding, onboarding, and future feature development.
 - EDRs capture concrete engineering decisions: tooling, structure, practices.
 - Every non-trivial implementation decision MUST have a corresponding XDR entry before the implementation task is marked complete. Create new XDRs if necessary.
 
-### II. Preset Integrity (NON-NEGOTIABLE)
+### II. XDR as the Single Source of Truth for All Policies
 
-agentme distributes files to consumer projects via named presets (`basic`, `speckit`). Each
-preset MUST be independently coherent, non-overlapping, and verified on every build.
+All quality standards, business policies, architectural policies, and engineering policies that
+specs, plans, and implementations must follow MUST be captured exclusively in XDRs. The
+constitution does not restate those rules; it defers to them.
 
-- A preset MUST contain all files a consumer needs and nothing more.
-- Presets MUST NOT share extraction sets unless the consumer explicitly requests multiple presets.
-- The `examples/` folder MUST assert the exact file presence/absence for each preset combination
-  after every `make build`.
-- Adding a file to a preset or changing selector patterns is a public API change and requires a
-  version bump (MINOR or MAJOR depending on impact).
-
-### III. Consumer-First API Discipline
-
-XDRs, skills, and preset file sets are a public API consumed by external projects. Changes MUST
-respect semantic versioning.
-
-- MAJOR: removing or renaming a preset, removing or restructuring an XDR that external consumers
-  reference, or any change that requires consumer-side migration.
-- MINOR: adding a new preset, adding XDRs or skills, adding files to an existing preset.
-- PATCH: wording, clarifications, typo fixes inside XDRs or skills that carry no structural change.
-- Breaking changes MUST be documented in the release notes and in the relevant XDR's `Conflicts`
-  or `Implementation Details` section before merging.
-
-### IV. Self-Contained Artifacts
-
-Every XDR and skill MUST work without any implicit context outside itself.
-
-- XDRs MUST be under 100 lines (hard limit 200 for templates and elaborate decisions).
-- Skills MUST be under 500 lines; lengthy reference material goes in `references/`.
-- Internal cross-references MUST use relative file paths; no absolute or external URLs without
-  explanation.
-- A consumer reading an XDR or skill for the first time MUST be able to follow it without
-  accessing other systems.
-
-### V. Simplicity and Verified Quality
-
-The simplest solution that passes all tests is always preferred. Quality gates are non-negotiable.
-
-- `make test` MUST pass before any release; failures block publish.
-- Linting MUST be clean (`make lint-fix`) before merging.
-- Files MUST NOT exceed 400 lines (test files excepted).
-- No feature scope creep: implement only what the current spec requires.
-- Avoid adding error handling, fallbacks, or abstractions for hypothetical future scenarios.
-
-## Quality Requirements
-
-- `make test` in `examples/` MUST verify all preset extraction scenarios end-to-end.
-- XDRs produced during a feature MUST be reviewed for non-conflict before merging.
-- All XDR indexes (`_local`, `agentme`, `_core`) MUST be updated before a PR is merged.
-- New presets or selector changes MUST include updated test assertions in the examples Makefile.
+- Quality gates (testing, linting, coverage thresholds, file-size limits) → EDRs.
+- Business rules, consumer workflows, versioning contracts → BDRs.
+- Architectural patterns, cross-cutting concerns, dependency strategies → ADRs.
+- If a policy is not in an XDR, it is not an enforceable policy. Write the XDR first.
+- Agents and humans MUST consult the XDR index before starting any work and MUST follow every
+  relevant XDR found there without exception.
 
 ## Development Workflow
 
 1. Before starting a feature: check existing XDRs for applicable decisions.
 2. During specifying (`speckit.specify`): capture business requirements as BDRs in `_local`.
+   **After every `speckit.specify` run the agent MUST offer to run `speckit.clarify` (refine)
+   before proceeding to planning. This is non-negotiable.**
 3. During planning (`speckit.plan`): update or create ADRs and EDRs in `_local` that reflect
    architectural and engineering decisions made during the planning phase.
+   **After every `speckit.plan` run the agent MUST propose running `speckit.checklist` to enrich
+   the plan with domain-specific quality checks before generating tasks.**
 4. During implementation: follow XDRs; create new `_local` XDRs for decisions not yet captured.
 5. After implementation: delete feature specs and plans; XDRs remain permanently.
 6. Runtime guidance: see `.xdrs/index.md` and all linked scope indexes.
 
+## XDR Compliance Check (Mandatory at Every Stage)
+
+Every Spec, Refinement (clarify), Plan, Checklist, and Implementation task MUST include an
+explicit step that verifies compliance with the XDRs present in the repository:
+
+1. Read `.xdrs/index.md` and all linked scope indexes (`_local`, `agentme`, `_core`).
+2. Identify every XDR relevant to the work being performed.
+3. Confirm that the artifact (spec, plan, task list, or code change) does not contradict any
+   relevant XDR.
+4. If a contradiction or gap is found: either update the artifact to comply, or create/update the
+   relevant XDR to reflect the new decision before continuing.
+5. Document the compliance check result in the artifact (e.g., a "XDR Compliance" section or
+   comment) so reviewers can audit it.
+
+No artifact may be considered complete without a passed XDR compliance check.
+
 ## Governance
 
 This constitution supersedes all other development practices within this repository. Amendments
 require:
-1. A version bump following semantic versioning rules stated in Principle III.
+1. A version bump following semantic versioning rules stated in the relevant BDR/ADR/EDR.
 2. An updated `LAST_AMENDED_DATE` in this file.
-3. A review of all five principles for continued non-conflict.
+3. A review of all principles for continued non-conflict.
 4. An updated Sync Impact Report (HTML comment at the top of this file).
 
-All PRs MUST include a "Constitution Check" section confirming compliance with all five principles.
+All PRs MUST include a "Constitution Check" section confirming compliance with all principles.
 Complexity MUST be justified; if a solution requires deviation from a principle, that deviation
 MUST be documented in a new or updated XDR in `_local`.
 

package/.xdrs/agentme/edrs/application/003-javascript-project-tooling.md

@@ -13,7 +13,7 @@ What tooling and project structure should JavaScript/TypeScript projects follow
 
 ## Decision Outcome
 
-**Use a Mise-managed Node.js and pnpm toolchain together with pnpm, tsc, esbuild, eslint, and jest in a module-root layout that follows [agentme-edr-016](/.xdrs/agentme/edrs/principles/016-cross-language-module-structure.md), with runnable usage examples in sibling `examples/` folders and Makefiles as the only entry points.**
+**Use a Mise-managed Node.js and pnpm toolchain together with pnpm, tsc, esbuild, eslint, and jest in a module-root layout that follows [agentme-edr-016](../principles/016-cross-language-module-structure.md), with runnable usage examples in sibling `examples/` folders and Makefiles as the only entry points.**
 
 Clear, consistent tooling and layout enable fast onboarding, reliable CI pipelines, and a predictable developer experience across projects.
 
@@ -30,7 +30,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](/.xdrs/agentme/edrs/devops/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-017](../devops/017-tool-execution-and-scripting.md). Calling project tools directly in docs, CI, or daily workflows instead of `make <target>` is not allowed.
 
 #### ESLint
 

package/.xdrs/agentme/edrs/application/010-golang-project-tooling.md

@@ -13,7 +13,7 @@ What tooling and project structure should Go projects follow to ensure consisten
 
 ## Decision Outcome
 
-**Use a Mise-managed Go toolchain with `go build`, `go test`, and `golangci-lint`, module-root folder responsibilities from [agentme-edr-016](/.xdrs/agentme/edrs/principles/016-cross-language-module-structure.md), feature packages in subdirectories, a `cli/` package for command wiring, and a Makefile as the single entry point for all development tasks.**
+**Use a Mise-managed Go toolchain with `go build`, `go test`, and `golangci-lint`, module-root folder responsibilities from [agentme-edr-016](../principles/016-cross-language-module-structure.md), feature packages in subdirectories, a `cli/` package for command wiring, and a Makefile as the single entry point for all development tasks.**
 
 A predictable layout and minimal external tooling keep Go projects approachable, fast to build, and easy to distribute as cross-platform binaries.
 
@@ -28,7 +28,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 are run exclusively through the Makefile, never 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](/.xdrs/agentme/edrs/devops/017-tool-execution-and-scripting.md).
+All commands are run exclusively through the Makefile, never 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](../devops/017-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

package/.xdrs/agentme/edrs/application/014-python-project-tooling.md

@@ -13,7 +13,7 @@ What tooling and project structure should Python projects follow to ensure consi
 
 ## Decision Outcome
 
-**Use a Mise-managed Python and uv toolchain with `pyproject.toml`, `ruff`, `pyright`, `pytest`, `pytest-cov`, `pip-audit`, and a layout that follows [agentme-edr-016](/.xdrs/agentme/edrs/principles/016-cross-language-module-structure.md): a module root under `lib/`, runnable consumer examples in sibling `examples/`, and standardized `dist/` and `.cache/` locations.**
+**Use a Mise-managed Python and uv toolchain with `pyproject.toml`, `ruff`, `pyright`, `pytest`, `pytest-cov`, `pip-audit`, and a layout that follows [agentme-edr-016](../principles/016-cross-language-module-structure.md): a module root under `lib/`, runnable consumer examples in sibling `examples/`, and standardized `dist/` and `.cache/` locations.**
 
 A single dependency manager, isolated package internals under `lib/`, and a standard Makefile contract keep Python projects predictable for contributors and CI while keeping the repository root clean.
 
@@ -34,7 +34,7 @@ A single dependency manager, isolated package internals under `lib/`, and a stan
 
 All routine commands must run through the project `Makefile`, never by calling `uv`, `ruff`, `pytest`, or `pyright` 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](/.xdrs/agentme/edrs/devops/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-017](../devops/017-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.
 
@@ -80,7 +80,7 @@ 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 `pyrightconfig.json` by default; keep project metadata and tool configuration in `lib/pyproject.toml`.
 
-Libraries and shared utilities must include an `examples/` folder and wire example execution into the root `test` flow, following [agentme-edr-007](/.xdrs/agentme/edrs/principles/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-007](../principles/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/`.
 
 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.
 
@@ -98,7 +98,7 @@ Ruff is the default formatter and linter. Do not add Black, isort, or Flake8 unl
 
 Pyright must run on every lint pass. `typeCheckingMode = "standard"` is the minimum baseline; projects may raise this to `strict` when the codebase is ready.
 
-Pytest coverage must fail below 80% line and branch coverage, following [agentme-edr-004](/.xdrs/agentme/edrs/principles/004-unit-test-requirements.md).
+Pytest coverage must fail below 80% line and branch coverage, following [agentme-edr-004](../principles/004-unit-test-requirements.md).
 
 #### Makefile targets
 
@@ -137,7 +137,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](/.xdrs/agentme/edrs/devops/008-common-targets.md).
+The root `Makefile` must remain the only contract for CI and contributors, in line with [agentme-edr-008](../devops/008-common-targets.md).
 
 ## Considered Options
 
@@ -148,7 +148,7 @@ The root `Makefile` must remain the only contract for CI and contributors, in li
 
 ## References
 
-- [agentme-edr-004](/.xdrs/agentme/edrs/principles/004-unit-test-requirements.md) - Coverage and unit-test baseline
-- [agentme-edr-007](/.xdrs/agentme/edrs/principles/007-project-quality-standards.md) - Examples and quality requirements
-- [agentme-edr-008](/.xdrs/agentme/edrs/devops/008-common-targets.md) - Standard Makefile target names
+- [agentme-edr-004](../principles/004-unit-test-requirements.md) - Coverage and unit-test baseline
+- [agentme-edr-007](../principles/007-project-quality-standards.md) - Examples and quality requirements
+- [agentme-edr-008](../devops/008-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

@@ -99,9 +99,9 @@ This keeps the user-facing command predictable while preserving a clean library
 ## References
 
 - [agentme-edr-003](003-javascript-project-tooling.md) - JavaScript project packaging and structure
-- [agentme-edr-007](/.xdrs/agentme/edrs/principles/007-project-quality-standards.md) - README and examples baseline
-- [agentme-edr-008](/.xdrs/agentme/edrs/devops/008-common-targets.md) - Standard command names for project entry points
-- [agentme-edr-009](/.xdrs/agentme/edrs/principles/009-error-handling.md) - Process error signaling and error handling expectations
+- [agentme-edr-007](../principles/007-project-quality-standards.md) - README and examples baseline
+- [agentme-edr-008](../devops/008-common-targets.md) - Standard command names for project entry points
+- [agentme-edr-009](../principles/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
 - [cosmiconfig](https://github.com/cosmiconfig/cosmiconfig) - Example JSON configuration discovery library for JavaScript CLIs

package/.xdrs/agentme/edrs/application/skills/001-create-javascript-project/SKILL.md

@@ -19,7 +19,7 @@ the sibling `examples/` folder, redirects persistent caches into `.cache/`, and
 the only entry points. Boilerplate is derived from the [filedist](https://github.com/flaviostutz/filedist)
 project.
 
-Related EDRs: [agentme-edr-003](/.xdrs/agentme/edrs/application/003-javascript-project-tooling.md), [agentme-edr-016](/.xdrs/agentme/edrs/principles/016-cross-language-module-structure.md)
+Related EDRs: [agentme-edr-003](../../003-javascript-project-tooling.md), [agentme-edr-016](../../../principles/016-cross-language-module-structure.md)
 
 ## Instructions
 
@@ -418,7 +418,7 @@ Review all created files and confirm:
 - [ ] `lib/eslint.config.mjs` points `parserOptions.project` to `tsconfig.json`
 - [ ] `lib/README.md` starts with Quick Start and ends with module development commands
 - [ ] All `[package-name]` placeholders are replaced with the actual name
-- [ ] Structure matches the layout in [agentme-edr-003](/.xdrs/agentme/edrs/application/003-javascript-project-tooling.md)
+- [ ] Structure matches the layout in [agentme-edr-003](../../003-javascript-project-tooling.md)
 
 ## Examples
 

package/.xdrs/agentme/edrs/application/skills/003-create-golang-project/SKILL.md

@@ -12,9 +12,9 @@ compatibility: Go 1.21+
 
 ## Overview
 
-Creates a complete Go CLI project from scratch, following the layout from [agentme-edr-010](/.xdrs/agentme/edrs/application/010-golang-project-tooling.md). Business logic lives in named feature packages; CLI wiring lives in `cli/<feature>/`; `main.go` is a thin dispatcher. The module root owns its `Makefile`, `README.md`, `dist/`, and `.cache/` folders.
+Creates a complete Go CLI project from scratch, following the layout from [agentme-edr-010](../../010-golang-project-tooling.md). Business logic lives in named feature packages; CLI wiring lives in `cli/<feature>/`; `main.go` is a thin dispatcher. The module root owns its `Makefile`, `README.md`, `dist/`, and `.cache/` folders.
 
-Related EDRs: [agentme-edr-010](/.xdrs/agentme/edrs/application/010-golang-project-tooling.md), [agentme-edr-016](/.xdrs/agentme/edrs/principles/016-cross-language-module-structure.md)
+Related EDRs: [agentme-edr-010](../../010-golang-project-tooling.md), [agentme-edr-016](../../../principles/016-cross-language-module-structure.md)
 
 ## Instructions
 

package/.xdrs/agentme/edrs/application/skills/004-select-relevant-xdrs/SKILL.md

@@ -159,9 +159,9 @@ Input: "Set up agentme for this repo and keep the speckit workflow we already us
 
 ## References
 
-- [agentme README](/README.md)
-- [agentme-edr-003 - JavaScript project tooling and structure](/.xdrs/agentme/edrs/application/003-javascript-project-tooling.md)
-- [agentme-edr-005 - Monorepo structure](/.xdrs/agentme/edrs/devops/005-monorepo-structure.md)
-- [agentme-edr-007 - Project quality standards](/.xdrs/agentme/edrs/principles/007-project-quality-standards.md)
-- [agentme-edr-008 - Common development script names](/.xdrs/agentme/edrs/devops/008-common-targets.md)
-- [_core-adr-003 - Skill standards](/.xdrs/_core/adrs/principles/003-skill-standards.md)
+- [agentme README](../../../../../../README.md)
+- [agentme-edr-003 - JavaScript project tooling and structure](../../003-javascript-project-tooling.md)
+- [agentme-edr-005 - Monorepo structure](../../../devops/005-monorepo-structure.md)
+- [agentme-edr-007 - Project quality standards](../../../principles/007-project-quality-standards.md)
+- [agentme-edr-008 - Common development script names](../../../devops/008-common-targets.md)
+- [_core-adr-003 - Skill standards](../../../../../_core/adrs/principles/003-skill-standards.md)

package/.xdrs/agentme/edrs/application/skills/005-create-python-project/SKILL.md

@@ -18,7 +18,7 @@ Pyright, Pytest, and Makefiles. The default layout keeps the library self-contai
 uses a shared root `.venv/`, redirects persistent caches into `.cache/`, and places runnable
 consumer projects under the sibling `examples/` folder.
 
-Related EDRs: [agentme-edr-014](/.xdrs/agentme/edrs/application/014-python-project-tooling.md), [agentme-edr-016](/.xdrs/agentme/edrs/principles/016-cross-language-module-structure.md)
+Related EDRs: [agentme-edr-014](../../014-python-project-tooling.md), [agentme-edr-016](../../../principles/016-cross-language-module-structure.md)
 
 ## Instructions
 
@@ -375,5 +375,5 @@ After creating the files:
 
 ## References
 
-- [agentme-edr-014](/.xdrs/agentme/edrs/application/014-python-project-tooling.md)
-- [_core-adr-003 - Skill standards](/.xdrs/_core/adrs/principles/003-skill-standards.md)
+- [agentme-edr-014](../../014-python-project-tooling.md)
+- [_core-adr-003 - Skill standards](../../../../../_core/adrs/principles/003-skill-standards.md)

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

@@ -16,7 +16,7 @@ What monorepo structure, naming conventions, tooling, and build standards should
 **Adopt a standardized monorepo layout with top-level application folders that aggregate independent module roots, shared parent-level example and test areas, Mise-managed tooling, and Makefiles at every level.**
 
 For step-by-step scaffolding instructions see [skill 002-monorepo-setup](skills/002-monorepo-setup/SKILL.md).
-Module folder responsibilities, artifact locations, and test-folder conventions follow [agentme-edr-016](/.xdrs/agentme/edrs/principles/016-cross-language-module-structure.md).
+Module folder responsibilities, artifact locations, and test-folder conventions follow [agentme-edr-016](../principles/016-cross-language-module-structure.md).
 
 ### Implementation Details
 
@@ -63,7 +63,7 @@ Module folder responsibilities, artifact locations, and test-folder conventions
 - May depend on sibling modules within the same application or on `/shared/` resources.
 - **MUST NOT** depend on modules from other applications.
 - **MUST** contain its own `Makefile`, `README.md`, and language/tooling configuration.
-- **MUST** keep build outputs under `dist/` and persistent caches under `.cache/`, following [agentme-edr-016](/.xdrs/agentme/edrs/principles/016-cross-language-module-structure.md).
+- **MUST** keep build outputs under `dist/` and persistent caches under `.cache/`, following [agentme-edr-016](../principles/016-cross-language-module-structure.md).
 - **MUST NOT** keep consumer examples inside the module folder; those belong in a sibling `examples/` folder at the nearest parent aggregation root.
 
 #### 04-naming-conventions

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

@@ -140,7 +140,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](/.xdrs/agentme/edrs/application/003-javascript-project-tooling.md).
+*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).
 
 ---
 

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

@@ -59,6 +59,6 @@ Disallowed:
 - [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](/.xdrs/agentme/edrs/application/003-javascript-project-tooling.md) - JavaScript tooling commands inside Makefiles
-- [agentme-edr-010](/.xdrs/agentme/edrs/application/010-golang-project-tooling.md) - Go tooling commands inside Makefiles
-- [agentme-edr-014](/.xdrs/agentme/edrs/application/014-python-project-tooling.md) - Python tooling commands inside Makefiles
+- [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

package/.xdrs/agentme/edrs/devops/skills/002-monorepo-setup/SKILL.md

@@ -13,12 +13,12 @@ metadata:
 
 ## Overview
 
-Creates or extends a monorepo that follows the standard layout from [agentme-edr-005](/.xdrs/agentme/edrs/devops/005-monorepo-structure.md):
+Creates or extends a monorepo that follows the standard layout from [agentme-edr-005](../../005-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](/.xdrs/agentme/edrs/devops/005-monorepo-structure.md), [agentme-edr-013](/.xdrs/agentme/edrs/governance/013-contributing-guide-requirements.md), [agentme-edr-016](/.xdrs/agentme/edrs/principles/016-cross-language-module-structure.md)
+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)
 
 ## Instructions
 

package/.xdrs/agentme/edrs/governance/013-contributing-guide-requirements.md

@@ -38,5 +38,5 @@ Projects must keep a `CONTRIBUTING.md` file at the repository root. The file mus
 
 ## References
 
-- [agentme-edr-005 - Monorepo structure](/.xdrs/agentme/edrs/devops/005-monorepo-structure.md)
-- [002-monorepo-setup skill](/.xdrs/agentme/edrs/devops/skills/002-monorepo-setup/SKILL.md)
+- [agentme-edr-005 - Monorepo structure](../devops/005-monorepo-structure.md)
+- [002-monorepo-setup skill](../devops/skills/002-monorepo-setup/SKILL.md)

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

@@ -65,7 +65,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](/.xdrs/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
@@ -85,7 +85,7 @@ Projects larger than 10 files or 200 lines of code must have a linter configured
 
 **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.
 
-**Reference:** [agentme-edr-003](/.xdrs/agentme/edrs/application/003-javascript-project-tooling.md) for JavaScript-specific tooling.
+**Reference:** [agentme-edr-003](../application/003-javascript-project-tooling.md) for JavaScript-specific tooling.
 
 ---
 

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

@@ -38,7 +38,7 @@ Developers must treat reusable missing guidance discovered during implementation
 
 ## References
 
-- [_core-adr-001](/.xdrs/_core/adrs/principles/001-xdrs-core.md)
-- [_core-article-001](/.xdrs/_core/adrs/principles/articles/001-xdrs-overview.md)
+- [_core-adr-001](../../../_core/adrs/principles/001-xdrs-core.md)
+- [_core-article-001](../../../_core/adrs/principles/articles/001-xdrs-overview.md)
 - [agentme-article-001](articles/001-continuous-xdr-improvement.md)
-- [002-write-xdr skill](/.github/skills/002-write-xdr/SKILL.md)
+- [002-write-xdr skill](../../../../.github/skills/002-write-xdr/SKILL.md)

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

@@ -23,7 +23,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](/.xdrs/agentme/edrs/devops/008-common-targets.md)
+- a `Makefile` following [agentme-edr-008](../devops/008-common-targets.md)
 - a `README.md` for the module itself
 - all configuration files required to build, lint, test, package, or publish that module
 - its generated `dist/` directory when the module produces distributable artifacts
@@ -125,9 +125,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](/.xdrs/agentme/edrs/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-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.
 
 ## References
 
-- [agentme-edr-005](/.xdrs/agentme/edrs/devops/005-monorepo-structure.md) - Monorepo aggregation and delegation rules
-- [agentme-edr-008](/.xdrs/agentme/edrs/devops/008-common-targets.md) - Shared Makefile target names
+- [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

package/.xdrs/agentme/edrs/principles/articles/001-continuous-xdr-improvement.md

@@ -51,7 +51,7 @@ Good opening questions:
 
 ### How should you organize the XDR?
 
-Follow the XDR template from [_core-adr-002](/.xdrs/_core/adrs/principles/002-xdr-standards.md). Keep the document small, explicit, and decision-focused.
+Follow the XDR template from [_core-adr-002](../../../../_core/adrs/principles/002-xdr-standards.md). Keep the document small, explicit, and decision-focused.
 
 Use this checklist:
 
@@ -87,7 +87,7 @@ If the same clarification would likely be needed in another feature, by another
 
 ## References
 
-- [_core-adr-001](/.xdrs/_core/adrs/principles/001-xdrs-core.md) - XDR structure, numbering, and mandatory template
-- [_core-article-001](/.xdrs/_core/adrs/principles/articles/001-xdrs-overview.md) - XDR introduction and general adoption guidance
-- [agentme-edr-012](/.xdrs/agentme/edrs/principles/012-continuous-xdr-enrichment.md) - Shared-first XDR enrichment policy and 80% coverage target
-- [002-write-xdr skill](/.github/skills/002-write-xdr/SKILL.md) - Step-by-step procedure for drafting new XDRs
+- [_core-adr-001](../../../../_core/adrs/principles/001-xdrs-core.md) - XDR structure, numbering, and mandatory template
+- [_core-article-001](../../../../_core/adrs/principles/articles/001-xdrs-overview.md) - XDR introduction and general adoption guidance
+- [agentme-edr-012](../012-continuous-xdr-enrichment.md) - Shared-first XDR enrichment policy and 80% coverage target
+- [002-write-xdr skill](../../../../../.github/skills/002-write-xdr/SKILL.md) - Step-by-step procedure for drafting new XDRs

package/package.json

@@ -1,10 +1,10 @@
 {
   "name": "agentme",
-  "version": "0.7.4",
+  "version": "0.8.0",
   "description": "",
   "dependencies": {
-    "filedist": "^0.26.0",
-    "xdrs-core": "^0.20.0"
+    "filedist": "^0.28.1",
+    "xdrs-core": "^0.21.1"
   },
   "bin": "bin/filedist.js",
   "files": [
@@ -24,7 +24,7 @@
   "filedist": {
     "sets": [
       {
-        "package": "xdrs-core",
+        "package": "xdrs-core@latest",
         "selector": {
           "files": [
             ".xdrs/_core/**",