Problem
PDD uses two ways to think about module dependencies:
architecture.json dependencies — declarative; drives agentic sync when present (build_dep_graph_from_architecture).
tags in prompts — what the LLM actually pulls in; used when there is no architecture graph (build_dependency_graph).
Those sources drift, and several issues followed:
Silent surprises: Adding or removing architecture.json switches which graph defines constraints and execution order, without making that difference obvious.
Cross-layer drift: Arch lists deps that prompts don’t (or the reverse) — hard to spot until something mis-orders or mis-documents.
auto-deps divergence: pdd auto-deps could add module s while architecture.json stayed stale, widening the gap with the declarative layer.
We needed validation, automation, and explicit visibility so none of this stays silent.
Proposed solution
Cross-validate architecture.json dependencies against module-level s (same rules as sync_order: extract_includes_from_file, extract_module_from_include). Emit warnings for mismatches and missing prompt files; skip bundled sample trees by default where appropriate.
Surface validation in normal workflows: pdd sync / --dry-run (non-quiet), agentic sync (non-quiet), a pdd validate-arch-includes command (with --strict / --project-root), and CI (pdd validate-arch-includes after install).
Shared loaders/helpers in architecture_registry: find_project_root, load_combined_architecture_data; agentic _load_architecture_json delegates to the loader; keep _find_project_root as a backward-compatible alias.
After auto-deps writes the prompt, merge new module includes into the matching row’s dependencies in the right architecture.json, only when both modules already exist in that file (no orphan dep strings).
Related
Parent #733 (addresses last part of issue)(broken up into multiple PRs)
Problem
PDD uses two ways to think about module dependencies:
architecture.json dependencies — declarative; drives agentic sync when present (build_dep_graph_from_architecture).
tags in prompts — what the LLM actually pulls in; used when there is no architecture graph (build_dependency_graph).
Those sources drift, and several issues followed:
Silent surprises: Adding or removing architecture.json switches which graph defines constraints and execution order, without making that difference obvious.
Cross-layer drift: Arch lists deps that prompts don’t (or the reverse) — hard to spot until something mis-orders or mis-documents.
auto-deps divergence: pdd auto-deps could add module s while architecture.json stayed stale, widening the gap with the declarative layer.
We needed validation, automation, and explicit visibility so none of this stays silent.
Proposed solution
Cross-validate architecture.json dependencies against module-level s (same rules as sync_order: extract_includes_from_file, extract_module_from_include). Emit warnings for mismatches and missing prompt files; skip bundled sample trees by default where appropriate.
Surface validation in normal workflows: pdd sync / --dry-run (non-quiet), agentic sync (non-quiet), a pdd validate-arch-includes command (with --strict / --project-root), and CI (pdd validate-arch-includes after install).
Shared loaders/helpers in architecture_registry: find_project_root, load_combined_architecture_data; agentic _load_architecture_json delegates to the loader; keep _find_project_root as a backward-compatible alias.
After auto-deps writes the prompt, merge new module includes into the matching row’s dependencies in the right architecture.json, only when both modules already exist in that file (no orphan dep strings).
Related
Parent #733 (addresses last part of issue)(broken up into multiple PRs)