@thedecipherist/mdd 1.6.3 → 1.6.4

package/commands/mdd-audit.md

@@ -140,6 +140,7 @@ Manifest:    .mdd/jobs/audit-<date>/MANIFEST.md
 - CLI command missing any of the universal flags (--env, --cwd, --verbose, --strict, --silent) — check all commands against the CLI feature doc's universal flags requirement
 - `file.*` filesystem helpers or path-resolving functions accept arbitrary paths without confinement to a documented jailRoot
 - Silent error swallow: catch block returns empty/undefined without pushing to warnings array
+- Template/substitution function matches `{{varname}}` without spaces but not `{{ varname }}` with spaces — spec uses spaced form; use regex `\s*` not exact string
 
 ### P4 Low
 - Code style inconsistencies

package/commands/mdd-build.md

@@ -287,6 +287,8 @@ Using a plain `const` array is not sufficient and will fail audit.
 
 **Node substitution completeness rule:** Any function that transforms, substitutes, or dispatches across AST node types must handle ALL node types defined in `types.ts` — either explicitly or with a documented explicit-skip decision. An unhandled node type that silently falls through is a bug, not a design choice.
 
+**Template pattern matching rule:** Any function that matches `{{ expression }}` patterns (macro parameter substitution, interpolation, template engines) MUST use a regex with `\s*` around the identifier — e.g., `/\{\{\s*varname\s*\}\}/g` — not exact string matching like `'{{varname}}'`. The spec's canonical form uses spaces (`{{ param }}`); exact matching silently fails for spec-valid usage. This applies to any function that replaces, finds, or validates `{{ ... }}` syntax.
+
 **Existence gate for source_files:** When marking `status: complete`, all files listed in `source_files` must exist on disk. Missing files block completion. Add missing files to `known_issues` with a TODO, or implement them before closing the feature.
 
 **Determine the `path` field** before writing the doc. Read the `path` values of all existing docs in `.mdd/docs/` to understand established product vocabulary and category names. Then ask: "What would a user navigate to in order to reach this feature?" — answer in their mental model of the product, not the code structure. Use 1–3 segments, Title Case, product vocabulary (e.g. `Auth/Login`, `E-commerce/Cart`, `Dashboard/Analytics`). Siblings must use identical parent spelling — if `Auth/Login` exists, use `Auth` not `Authentication`. If you can infer the path from context with confidence, set it and show the user. If genuinely ambiguous (feature could belong in 2+ places), ask: "Where does this feature live in the product? (e.g. `Auth/Login` or `Dashboard/Reports`)"

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@thedecipherist/mdd",
-  "version": "1.6.3",
+  "version": "1.6.4",
   "description": "MDD — Manual-Driven Development workflow for Claude Code",
   "type": "module",
   "bin": {