feat(code-reviewer)- Add Process Rule Validation Rules to the code-reviewer scan/review command

cmf-codereview/docs/architecture.md

@@ -234,3 +234,16 @@ loop/method-analyzed at most once no matter how many passes touch it.
 **Adding a rule** doesn't touch any of this. It's one more class implementing `IReviewRule` (or
 one more instantiation of `LoopSensitiveCallRule` / `EntityPropertyAccessRule` if the shape
 already fits), registered in `CmFrameworkScanner.Rules`. See [docs/rules.md](rules.md).
+
+## Process Rule deployment context
+
+`ProcessRuleValidationRule` is registered with the normal built-in rules. After warming the
+shared syntax cache, the scanner builds one read-only `ProcessRuleRepositoryContext`: package
+content/phase/version classification, same-package MasterData schema changes, and resolvable
+entity-type creator/consumer ordering. `RuleFileContext` carries this context into the parallel
+rule loop; Process Rule detection reuses the cached Roslyn trees and yields ordinary `RuleMatch`
+values. Existing enrichment, configuration, suppression, baseline, and changed-file filters apply.
+
+Deployment metadata comes from repository source/package files. The Markdown authoring guidelines
+are implementation reference material and have no runtime role. No language model or policy
+interpreter is involved. Findings use the existing JSON, Markdown, and HTML outputs.

cmf-codereview/docs/commands.md

@@ -192,6 +192,19 @@ Scan and produce a Detailed, self-contained HTML report for browser triage:
 cmf-codereview review --repository-root C:\repos\YourProject --report-mode Detailed --report-format Html
 ```
 
+## Reviewing Process Rules
+
+Process Rule diagnostics run automatically as part of the DEEs/Both scope. No guideline file
+or additional validation flag is required. To focus on the Micron deployment rules:
+
+```powershell
+cmf-codereview scan --repository-root C:\workspaces\Micron --roots Cmf.Custom.Data/Cmf.Custom.Data.Packages/DEEs/ProcessRules --fail-on High --output findings.json
+cmf-codereview report --findings-path findings.json --report-mode Detailed --report-format Html --report-path process-rules.html
+```
+
+Supported Process Rule checks and deployment evidence that still needs review are documented in
+[rules.md](rules.md#process-rule-deployment-validation).
+
 ## Choosing between the three commands
 
 - Use **`review`** for everyday use — it's the one-command path from repository to report.

cmf-codereview/docs/configuration.md

@@ -57,6 +57,24 @@ Notes:
 - Comments and trailing commas are allowed in the file.
 - A malformed file fails the scan with a clear error rather than being silently ignored.
 
+## Process Rule checks
+
+Process Rule validation uses the same `rules` dictionary as every other built-in check:
+
+```json
+{
+  "rules": {
+    "ProcessRuleCondition": { "severity": "Critical" },
+    "ProcessRuleUnresolvedGuard": { "enabled": false }
+  }
+}
+```
+
+There is no `guidelinesPath` or policy-file configuration. The Markdown authoring guidelines
+inform the C# implementation only; they are not loaded during scans. See
+[rules.md](rules.md#process-rule-deployment-validation) for diagnostic IDs and supported patterns.
+Each diagnostic can also be suppressed inline or accepted in the normal baseline.
+
 ## Inline suppression comments
 
 ```csharp

cmf-codereview/docs/rules.md

@@ -1,6 +1,6 @@
 # Rule Reference
 
-All 17 rules implemented by `CmFrameworkScanner.GetFindings`. When a finding's severity escalates, the
+Built-in checks implemented by `CmFrameworkScanner.GetFindings`. When a finding's severity escalates, the
 finding's JSON also carries a machine-readable `Escalation` object (base severity, reasons, nested-loop
 depth) — see [commands.md](commands.md#scan). Severity can escalate above the base level
 listed here for `LoadInsideLoop`, `ResolveInsideLoop`, `QueryExecuteInsideLoop`, `SaveInsideLoop`,
@@ -67,6 +67,64 @@ ad-hoc query pattern). See `EntityCatalog.NonLazyLoadedReferenceNames` /
 | `DirectEntityInstantiation` | Medium | `new Material(`, `new Product(`, etc. — direct construction of a known entity type | Use `entityFactory.Create<TInterface>()` instead of direct construction. |
 | `GetConfigInsteadOfTryGetConfig` | Medium | A `GetConfig(` call that is not `TryGetConfig` and not `Config.GetConfig` (already covered by that rule) | Confirm whether this should use `TryGetConfig` or an existing wrapper service before keeping the direct call. |
 
+## Process Rule deployment validation
+
+`ProcessRuleValidationRule` implements deterministic Roslyn checks for `DeeDevBase` deployment
+classes. The authoring guidelines are development reference material: **the scanner never reads
+`process-rule-validation-guidelines.md`**. Identical source, package metadata, tool version, and
+review configuration produce identical findings. Changes to checks are C# changes with tests.
+
+Process Rules are discovered from Data-package `EntityTypes`, `ProcessRulesPre`, and
+`ProcessRulesPost` content entries, including repositories without a general `DEE` entry.
+Standard `DEEs/ProcessRules/` paths also work with explicit roots. Classification distinguishes
+versioned Before/After, EntityTypes, EntityTypesAttributes, and recurring unversioned Services.
+The older `IsOneTimeMigrationFile` exemptions remain unchanged for compatibility; that flag alone
+does not imply a Services rule runs once.
+
+| Diagnostic | Default severity | Detects / remediation |
+|---|---|---|
+| `ProcessRuleCondition` | High | Condition contains more than an unconditional `return true` / `=> true`. Deployment skips it; move guards into `DeeActionCode`. |
+| `ProcessRuleUnguardedMutation` | High; Critical when the same guard exists only in the skipped condition | Attribute creation or typed Action/Rule/Config/EntityType creation, deletion, removal, saving, action-group removal, or termination lacks a recognized guard for its own target. |
+| `ProcessRuleUnresolvedGuard` | Medium | Attribute target or a helper-based guard cannot be resolved. Review the helper rather than treating it as proven safe. |
+| `ProcessRuleTerminationState` | High | Termination lacks an already-terminated state guard. Check both existence and `UniversalState != Terminated`. |
+| `ProcessRuleSchemaRegeneration` | High | Raw property collection creation or `FullUpdateEntityType` property changes lack subsequent schema regeneration for the same entity on the same path. |
+| `ProcessRuleAttributeRemoval` | High; Critical when matching cleanup occurs after removal | A resolved property removal has no matching earlier `RemoveAttributes` cleanup. Clear all holders and preserve values where required before removing metadata. |
+| `ProcessRuleAttributeRemovalReview` | Medium | Removed properties are supplied through an unresolved collection/helper; verify guards and cleanup. |
+| `ProcessRuleTableMigration` | Critical | Smart/Generic Table data access or mutation targets schema created/changed in the same package version's MasterData. Move migration to a post-install step or later independent package. |
+| `ProcessRuleTableMigrationReview` | Medium | Table mutation has an unresolved name/package/version; verify deployment dependencies and rerun safety. |
+| `ProcessRulePlacement` | High | Unsupported folder, conflicting namespace phase/content type, wrong position relative to MasterData, or attribute changes in a general Before/After folder. |
+| `ProcessRuleVersionNamespace` | Medium | Namespace version does not match the dotted folder version's underscore form. |
+| `ProcessRuleRecurringMigration` | Medium | Recognizable migration mutations under Services will run on every deployment; confirm intent or move to a versioned folder. |
+| `ProcessRuleDependencyOrder` | High | A literal entity-type load precedes its unique same-package, same-version creation rule in manifest/alphabetical file order. Move the creator earlier. |
+
+Guards recognize `HasProperty`, `TryGetEntityTypeProperty`, `ObjectExists`, `TryLoad`, boolean
+negation/comparisons, applicable branches, and early returns. Checks on another property or target
+do not protect an operation. Reachable local functions are analyzed, including guards at their
+call sites; dormant local functions and callbacks are excluded. Raw metadata changes recognize
+`GenerateSchema` and `GenerateEntityTypeDBSchema` after the update. The normal
+`IMicronEntityTypeService.UpdateEntityTypeProperties` route does not require a duplicate schema
+call. A guarded removal followed by recreation supports deliberate attribute-definition repairs;
+the removal still needs value cleanup.
+
+Schema context is read once per scan from the same Data package's versioned MasterData. It tracks
+new Smart/Generic Tables and changes to property structure. Row data, precedence keys, and
+description-only updates are not schema changes. Partial property updates retain earlier field
+definitions. Names must resolve from local/constant strings, a table's `Name`, or a named `Load`;
+unrelated packages' tables are never correlated. Unchanged files provide context even when
+`--changed-files-list` restricts the reported findings.
+
+These are bounded syntax checks, not execution or whole-program proofs. External helpers,
+callbacks, indirect SQL/query table dependencies, and arbitrary alias/data flow may require
+review. Cleanup recognition does not prove a query included every populated holder. Rename/move
+value preservation is a developer decision; verify copies finish before cleanup. Released-version
+immutability, database execution twice, complete test coverage, and manual release-note steps
+need release/deployment evidence and are not inferred from folder age or missing static findings.
+Do not edit shipped rules to resolve historical findings: fix forward, or baseline accepted debt.
+
+All diagnostics use the existing per-rule settings, inline suppressions, baselines, changed-file
+filtering, severity gates, and JSON/Markdown/HTML reporting. They do not use loop escalation.
+
+
 ## The entity catalog (`src/Rules/EntityCatalog.cs`)
 
 `SaveInsideLoop`, `CreateInstanceInsideLoop`, `DeleteRemoveInsideLoop`, `ExcessiveLazyLoading`,