@atlashub/smartstack-cli 2.2.0 → 2.4.0

package/templates/skills/business-analyse/steps/step-03-validate.md

@@ -1,862 +0,0 @@
-# Step 03: Validation
-
-> **Version:** 3.0.0
-> **Name:** step-03-validate
-> **Next step:** steps/step-04-handoff.md
-> **Purpose:** Validate specification completeness, consistency, and SmartStack conventions. Approve or reject with revision options.
-> **Input:** feature.json (specification section populated)
-> **Output:** feature.json.validation enriched + status: "approved" or "specified" (if rejected)
-
----
-
-## 1. Introduction
-
-This step **quality-gates** the specification before handoff to development. You will:
-
-1. **Check completeness** - All specification sections present and non-empty
-2. **Verify consistency** - Use cases, FRs, and business rules cross-reference correctly
-3. **Validate SmartStack conventions** - Naming, structure, RBAC, SeedData patterns
-4. **Assess risks** - Identify ambiguities, dependencies, scope creep
-5. **Make approval decision** - Approve (→ handoff) or reject (→ revision)
-6. **Handle rejections** - Auto-revise, manual fix, or force-accept
-
----
-
-## 2. Mode Support
-
-### Standard Mode
-Execute all validation checks in full detail. Require user confirmation for approval.
-
-### Micro Mode
-IF use_case = micro:
-- Auto-validate structural completeness only (no human confirmation required)
-- Skip complex consistency checks (cross-module, audit, archival)
-- Auto-approve if basic structure valid
-- Mark as "approved" without user interaction
-
-### Delta Mode
-IF use_case = refactoring:
-- Validate only **affected** sections (marked with `delta: true`)
-- Skip validation of unchanged sections
-- Approve if delta sections are consistent with existing data
-
----
-
-## 2. Completeness Checklist
-
-### 2.1 Specification Sections Present
-
-Verify all required sections exist in feature.json.specification:
-
-| Section | Required | Status |
-|---------|----------|--------|
-| **actors** | ✓ | 4+ roles defined |
-| **useCases** | ✓ | ≥2 UCs (List, Create minimum) |
-| **functionalRequirements** | ✓ | ≥4 FRs linked to BRs |
-| **permissionMatrix** | ✓ | ≥1 resource × 4 actors |
-| **entities** | ✓ | ≥1 entity with fields |
-| **navigationHierarchy** | ✓ | Menu structure defined |
-| **wireframes** | ✓ | ≥2 wireframes (List, Create) |
-| **gherkinScenarios** | ✓ | ≥2 scenarios per major UC |
-| **validations** | ✓ | ≥1 field validation rule |
-| **messages** | ✓ | ≥4 business messages (success, error, warning) |
-| **lifeCycles** | ✓ | ≥1 entity with state machine |
-| **crossModuleDependencies** | ◐ | If module integrates with others |
-| **auditingPolicy** | ◐ | If sensitive data tracked |
-| **archivalPolicy** | ◐ | If long-term data retention required |
-
-**Micro mode:** Minimum set only (actors, UCs, FRs, permissionMatrix, entities, wireframes, gherkin, validations, messages).
-
-### 2.2 Element Counts
-
-For standard mode, typical ranges:
-
-| Element | Typical Range | Minimum | Check |
-|---------|---------------|---------|-------|
-| Actors | 2-6 | 2 (User, Admin minimum) | Count ≥ 2 ✓ |
-| Use Cases | 4-12 | 2 | Count ≥ 2 ✓ |
-| Functional Req | 8-20 | 4 | Count ≥ 4 ✓ |
-| Entities | 1-8 | 1 | Count ≥ 1 ✓ |
-| Permissions | 3-12 | 3 | Count ≥ 3 ✓ |
-| Validations | 5-20 | 5 | Count ≥ 5 ✓ |
-| Messages | 4-20 | 4 | Count ≥ 4 ✓ |
-| Gherkin Scenarios | 4-30 | 4 | Count ≥ 4 ✓ |
-| State transitions | 2-10 | 2 | Count ≥ 2 ✓ |
-
-**Micro mode:** Reduce minimums by 50% (e.g., 1 UC, 2 FRs, 2 scenarios).
-
-### 2.3 Mandatory SeedData Presence
-
-Validate 5 mandatory SeedData tables defined in navigationHierarchy:
-
-```json
-{
-  "seedDataRequired": [
-    {
-      "table": "Module_Status",
-      "rows": 5,
-      "status": "FOUND" ✓
-    },
-    {
-      "table": "Module_Priority",
-      "rows": 3,
-      "status": "FOUND" ✓
-    },
-    {
-      "table": "Module_Category",
-      "rows": 8,
-      "status": "FOUND" ✓
-    },
-    {
-      "table": "Module_Type",
-      "rows": 4,
-      "status": "FOUND" ✓
-    },
-    {
-      "table": "Module_Department",
-      "rows": 6,
-      "status": "FOUND" ✓
-    }
-  ]
-}
-```
-
-**Issue:** Missing SeedData table → validation ERROR, must specify before approval.
-
----
-
-## 3. Consistency Checks
-
-### 3.1 Use Case ↔ Functional Requirement Mapping
-
-**Rule:** Every UC should have ≥1 linked FR.
-
-Check each use case:
-
-```json
-{
-  "checks": [
-    {
-      "check": "UC-001 has linked FRs",
-      "useCaseId": "UC-001",
-      "linkedFRs": ["FR-001", "FR-002"],
-      "status": "PASS" ✓
-    },
-    {
-      "check": "UC-002 has linked FRs",
-      "useCaseId": "UC-002",
-      "linkedFRs": ["FR-003"],
-      "status": "PASS" ✓
-    },
-    {
-      "check": "UC-005 has linked FRs",
-      "useCaseId": "UC-005",
-      "linkedFRs": [],
-      "status": "FAIL" ✗ → "UC-005 orphaned: no FRs linked"
-    }
-  ]
-}
-```
-
-**Resolution:**
-- ✓ PASS: UC has ≥1 FR
-- ✗ FAIL: Add FRs or remove UC
-
-### 3.2 Functional Requirement ↔ Business Rule Mapping
-
-**Rule:** Every FR should have ≥1 linked BR (from analysis section).
-
-Check each FR:
-
-```json
-{
-  "checks": [
-    {
-      "check": "FR-001 has linked BRs",
-      "frId": "FR-001",
-      "linkedRules": ["BR-001", "BR-003"],
-      "status": "PASS" ✓
-    },
-    {
-      "check": "FR-004 has linked BRs",
-      "frId": "FR-004",
-      "linkedRules": [],
-      "status": "WARNING" ⚠ → "FR-004: Consider linking to a BR"
-    }
-  ]
-}
-```
-
-**Resolution:**
-- ✓ PASS: FR has ≥1 BR
-- ⚠ WARNING: FR is implementation-detail (may be OK)
-
-### 3.3 Business Rule ↔ Use Case Mapping
-
-**Rule:** Every BR used in specification should exist in analysis.
-
-Cross-check all BR references:
-
-```json
-{
-  "checks": [
-    {
-      "check": "All BR references valid",
-      "referencedBRs": ["BR-001", "BR-003", "BR-005"],
-      "definedBRs": ["BR-001", "BR-002", "BR-003", "BR-004", "BR-005"],
-      "missing": [],
-      "status": "PASS" ✓
-    },
-    {
-      "check": "All BR references valid",
-      "referencedBRs": ["BR-001", "BR-008"],
-      "definedBRs": ["BR-001", "BR-002", "BR-003"],
-      "missing": ["BR-008"],
-      "status": "FAIL" ✗ → "BR-008 not defined in analysis"
-    }
-  ]
-}
-```
-
-**Resolution:**
-- ✓ PASS: All referenced BRs exist
-- ✗ FAIL: Remove orphaned BR references or add to analysis
-
-### 3.4 Actor ↔ Permission Matrix Mapping
-
-**Rule:** Every actor should appear in permission matrix.
-
-```json
-{
-  "checks": [
-    {
-      "check": "All actors covered in permission matrix",
-      "actors": ["Admin", "Manager", "User", "Guest"],
-      "inMatrix": ["Admin", "Manager", "User", "Guest"],
-      "missing": [],
-      "status": "PASS" ✓
-    },
-    {
-      "check": "All actors covered in permission matrix",
-      "actors": ["Admin", "Manager", "User", "Guest", "External"],
-      "inMatrix": ["Admin", "Manager", "User"],
-      "missing": ["Guest", "External"],
-      "status": "FAIL" ✗ → "2 actors not in permission matrix"
-    }
-  ]
-}
-```
-
-**Resolution:**
-- ✓ PASS: All actors have permissions
-- ✗ FAIL: Add missing actors to matrix or remove from actor list
-
-### 3.5 Entity ↔ Permission Resource Mapping
-
-**Rule:** Every entity in entities[] should have a resource in permissionMatrix.
-
-```json
-{
-  "checks": [
-    {
-      "check": "All entities have permissions",
-      "entities": ["Order", "Customer", "Product"],
-      "permissionResources": ["Order", "Customer", "Product"],
-      "missing": [],
-      "status": "PASS" ✓
-    },
-    {
-      "check": "All entities have permissions",
-      "entities": ["Order", "Customer", "OrderLine"],
-      "permissionResources": ["Order", "Customer"],
-      "missing": ["OrderLine"],
-      "status": "WARNING" ⚠ → "OrderLine has no permissions (may be child entity)"
-    }
-  ]
-}
-```
-
-**Resolution:**
-- ✓ PASS: All entities have permissions
-- ⚠ WARNING: Child entities may not need separate permissions
-
-### 3.6 Gherkin ↔ Use Case Coverage
-
-**Rule:** Every major UC should have ≥2 Gherkin scenarios.
-
-```json
-{
-  "checks": [
-    {
-      "check": "UC-001 has Gherkin coverage",
-      "useCaseId": "UC-001",
-      "scenarios": 3,
-      "status": "PASS" ✓
-    },
-    {
-      "check": "UC-003 has Gherkin coverage",
-      "useCaseId": "UC-003",
-      "scenarios": 0,
-      "status": "FAIL" ✗ → "UC-003: No Gherkin scenarios"
-    }
-  ]
-}
-```
-
-**Resolution:**
-- ✓ PASS: UC has ≥2 scenarios
-- ✗ FAIL: Add Gherkin scenarios or remove UC
-
----
-
-## 4. SmartStack Convention Validation
-
-### 4.1 Naming Conventions
-
-| Element | Pattern | Check |
-|---------|---------|-------|
-| **Actor** | PascalCase | "Admin", "Manager" ✓ |
-| **Use Case** | UC-NNN | "UC-001", "UC-042" ✓ |
-| **Functional Req** | FR-NNN | "FR-001", "FR-025" ✓ |
-| **Business Rule** | BR-NNN | References to BR-* ✓ |
-| **Entity** | PascalCase | "Order", "Customer" ✓ |
-| **Field** | camelCase | "orderNumber", "createdDate" ✓ |
-| **SeedData Table** | Module_Name | "Order_Status", "Customer_Type" ✓ |
-| **State** | PascalCase | "Draft", "Approved" ✓ |
-| **Permission** | PascalCase | "Read", "Create", "Update", "Delete" ✓ |
-
-**Validation:**
-```json
-{
-  "checks": [
-    {
-      "element": "Actors",
-      "rule": "PascalCase",
-      "actual": ["Admin", "Manager", "User", "Guest"],
-      "status": "PASS" ✓
-    },
-    {
-      "element": "Use Cases",
-      "rule": "UC-NNN format",
-      "actual": ["UC-001", "UC-002", "UC-003", "UC-004"],
-      "status": "PASS" ✓
-    },
-    {
-      "element": "Functional Requirements",
-      "rule": "FR-NNN format",
-      "actual": ["FR-001", "fr-002", "FR-003"],
-      "status": "FAIL" ✗ → "fr-002 should be FR-002"
-    }
-  ]
-}
-```
-
-### 4.2 RBAC Pattern Validation
-
-**Rule:** Permission matrix should follow principle of least privilege.
-
-Check role escalation:
-
-| Role | Read | Create | Update | Delete | Approve |
-|------|------|--------|--------|--------|---------|
-| **Guest** | ✓ | ✗ | ✗ | ✗ | ✗ |
-| **User** | ✓ | ✓ | ✓ | ✗ | ✗ |
-| **Manager** | ✓ | ✓ | ✓ | ✗ | ✓ |
-| **Admin** | ✓ | ✓ | ✓ | ✓ | ✓ |
-
-**Validation:**
-```json
-{
-  "check": "RBAC least privilege",
-  "issues": [
-    {
-      "resource": "Order",
-      "issue": "User can Delete (should be Manager minimum)",
-      "severity": "ERROR" ✗
-    },
-    {
-      "resource": "Customer",
-      "issue": "Guest cannot Read (critical data exposure)",
-      "severity": "ERROR" ✗
-    }
-  ]
-}
-```
-
-### 4.3 Entity Structure Validation
-
-**Rule:** Entities must have primary key, timestamps, ownership.
-
-```json
-{
-  "checks": [
-    {
-      "entity": "Order",
-      "fields": ["id", "orderNumber", "orderDate", "createdBy", "createdDate"],
-      "hasPrimaryKey": true,
-      "hasTimestamps": true,
-      "hasOwnership": true,
-      "status": "PASS" ✓
-    },
-    {
-      "entity": "OrderLine",
-      "fields": ["orderId", "lineNumber", "quantity"],
-      "hasPrimaryKey": false,
-      "hasTimestamps": false,
-      "hasOwnership": false,
-      "status": "FAIL" ✗ → "Missing primary key, timestamps"
-    }
-  ]
-}
-```
-
-### 4.4 State Machine Validation
-
-**Rule:** Each state should have exit transitions; terminal states have none.
-
-```json
-{
-  "checks": [
-    {
-      "entity": "Order",
-      "state": "Draft",
-      "hasTransitions": true,
-      "status": "PASS" ✓
-    },
-    {
-      "entity": "Order",
-      "state": "Cancelled",
-      "isTerminal": true,
-      "hasTransitions": false,
-      "status": "PASS" ✓
-    },
-    {
-      "entity": "Order",
-      "state": "Processing",
-      "hasTransitions": false,
-      "isTerminal": false,
-      "status": "WARNING" ⚠ → "Non-terminal state with no exit transitions (deadlock?)"
-    }
-  ]
-}
-```
-
----
-
-## 5. Risk Assessment
-
-### 5.1 Scope Creep Detection
-
-Check for excessive complexity:
-
-```json
-{
-  "riskAssessments": [
-    {
-      "risk": "Scope Creep",
-      "indicators": [
-        {
-          "metric": "Use case count",
-          "value": 8,
-          "threshold": 12,
-          "status": "ACCEPTABLE" ✓
-        },
-        {
-          "metric": "Functional requirement count",
-          "value": 28,
-          "threshold": 20,
-          "status": "WARNING" ⚠ → "Above typical for single iteration"
-        }
-      ]
-    }
-  ]
-}
-```
-
-### 5.2 Missing Validation Rules
-
-Check for fields without validation:
-
-```json
-{
-  "riskAssessments": [
-    {
-      "risk": "Unvalidated Fields",
-      "fields": [
-        {
-          "name": "OrderNumber",
-          "hasValidation": true,
-          "status": "PASS" ✓
-        },
-        {
-          "name": "Notes",
-          "hasValidation": false,
-          "status": "WARNING" ⚠ → "Consider max length, SQL injection protection"
-        }
-      ]
-    }
-  ]
-}
-```
-
-### 5.3 Ambiguous Use Cases
-
-Detect UCs that lack clarity:
-
-```json
-{
-  "riskAssessments": [
-    {
-      "risk": "Ambiguous Use Cases",
-      "useCases": [
-        {
-          "id": "UC-001",
-          "clarity": "clear",
-          "status": "PASS" ✓
-        },
-        {
-          "id": "UC-005",
-          "clarity": "vague",
-          "reason": "Main flow not specific; unclear error handling",
-          "status": "WARNING" ⚠
-        }
-      ]
-    }
-  ]
-}
-```
-
-### 5.4 Dependency Complexity
-
-Check for excessive cross-module dependencies:
-
-```json
-{
-  "riskAssessments": [
-    {
-      "risk": "Dependency Coupling",
-      "dependencies": 2,
-      "threshold": 5,
-      "status": "ACCEPTABLE" ✓
-    }
-  ]
-}
-```
-
-### 5.5 Security & Compliance Gaps
-
-Check for missing audit/archival:
-
-```json
-{
-  "riskAssessments": [
-    {
-      "risk": "Security & Compliance",
-      "checks": [
-        {
-          "check": "Sensitive data (PII) has auditing",
-          "hasAuditingPolicy": true,
-          "status": "PASS" ✓
-        },
-        {
-          "check": "Long-term data has archival policy",
-          "hasArchivalPolicy": true,
-          "status": "PASS" ✓
-        },
-        {
-          "check": "All state transitions logged",
-          "status": "PASS" ✓
-        }
-      ]
-    }
-  ]
-}
-```
-
----
-
-## 6. Approval Decision Logic
-
-### 6.1 Decision Tree
-
-```
-┌─ Completeness Check
-│  ├─ FAIL → Reject: "Incomplete specification"
-│  └─ PASS → Continue
-├─ Consistency Check
-│  ├─ ERROR found → Reject: "Inconsistent cross-references"
-│  ├─ WARNING found → Continue (review)
-│  └─ PASS → Continue
-├─ Convention Check
-│  ├─ ERROR found → Reject: "Convention violations"
-│  └─ PASS → Continue
-├─ Risk Assessment
-│  ├─ CRITICAL risk → Reject: "High-risk specification"
-│  ├─ HIGH risk → Require confirmation
-│  └─ ACCEPTABLE → Continue
-└─ Final Decision
-   ├─ User confirms → APPROVED ✓ (status: "approved")
-   └─ User rejects → REJECTED ✗ (status: "specified", mark for revision)
-```
-
-### 6.2 Approval Criteria (Standard Mode)
-
-**AUTO-APPROVE if:**
-- Completeness: PASS
-- Consistency: PASS or WARNING only
-- Conventions: PASS
-- Risks: ACCEPTABLE or HIGH (with user confirmation)
-
-**AUTO-REJECT if:**
-- Completeness: FAIL
-- Consistency: ERROR
-- Conventions: ERROR
-- Risks: CRITICAL
-
-### 6.3 Approval Criteria (Micro Mode)
-
-**AUTO-APPROVE if:**
-- Completeness: Minimum set present (actors, UCs, FRs, matrix, entities, wireframes, gherkin, validations, messages)
-- Consistency: No cross-reference errors
-- Naming: Follows conventions (UC-*, FR-*, PascalCase)
-
-No user interaction required.
-
-### 6.4 Approval Criteria (Delta Mode)
-
-**AUTO-APPROVE if:**
-- Affected sections (delta: true) are complete
-- Cross-references within delta sections consistent
-- No conflicts with existing sections
-
----
-
-## 7. Handling Rejections
-
-### 7.1 Rejection Reasons & Options
-
-When specification is REJECTED, offer user choices:
-
-```json
-{
-  "rejection": {
-    "reason": "Inconsistent cross-references",
-    "errors": [
-      "UC-005: No linked FRs",
-      "FR-004: Links to undefined BR-008"
-    ],
-    "options": [
-      {
-        "id": 1,
-        "action": "auto-revise",
-        "description": "Fix obvious issues automatically (remove orphaned UCs, skip FRs)"
-      },
-      {
-        "id": 2,
-        "action": "manual-revise",
-        "description": "Return to step-02 to revise specification manually"
-      },
-      {
-        "id": 3,
-        "action": "force-approve",
-        "description": "Override validation and approve anyway (risky)"
-      }
-    ]
-  }
-}
-```
-
-### 7.2 Auto-Revise Strategy
-
-When user chooses auto-revise:
-
-1. **Remove orphaned UCs** - UCs with no linked FRs
-2. **Remove orphaned FRs** - FRs with no linked BRs (optional warning)
-3. **Fix naming** - Convert "fr-002" → "FR-002"
-4. **Remove invalid BR references** - Delete references to undefined BRs
-5. **Add missing permissions** - For any new actors discovered
-6. **Revalidate** - Run validation again
-
-Example:
-```json
-{
-  "autoRevise": {
-    "removedElements": [
-      {
-        "type": "useCase",
-        "id": "UC-005",
-        "reason": "No linked FRs"
-      },
-      {
-        "type": "businessRuleReference",
-        "location": "FR-004.linkedRules",
-        "value": "BR-008",
-        "reason": "BR-008 not defined in analysis"
-      }
-    ],
-    "fixedElements": [
-      {
-        "type": "functionalRequirement",
-        "id": "fr-002",
-        "from": "fr-002",
-        "to": "FR-002"
-      }
-    ],
-    "result": "Revalidating..."
-  }
-}
-```
-
-### 7.3 Manual Revision (Return to Step-02)
-
-If user chooses manual revision:
-
-1. Provide list of errors to fix
-2. Return to step-02-specify.md with context
-3. User revises specification
-4. Return to step-03 for re-validation
-5. Loop until approved
-
-### 7.4 Force-Approve (Override)
-
-If user chooses force-approve:
-
-1. Mark status as "approved" despite errors
-2. Add validation warning to feature.json.validation
-3. Escalate errors to development team
-4. Proceed to handoff
-5. **WARNING:** Development may encounter issues
-
-```json
-{
-  "validation": {
-    "status": "approved",
-    "approvalMode": "force",
-    "overriddenErrors": [
-      {
-        "type": "consistency",
-        "message": "UC-005: No linked FRs"
-      },
-      {
-        "type": "convention",
-        "message": "fr-002: Should be FR-002"
-      }
-    ],
-    "approvedBy": "User override",
-    "approvedAt": "2025-02-01T10:30:00Z"
-  }
-}
-```
-
----
-
-## 8. Execution Workflow
-
-### 8.1 Validation Sequence
-
-1. **Load specification** from feature.json via `ba-reader`
-2. **Run completeness checks** - Verify all sections present
-3. **Run consistency checks** - Cross-reference validation
-4. **Run convention checks** - Naming, RBAC, structure
-5. **Run risk assessment** - Scope, security, dependencies
-6. **Compile report** - Summarize findings
-7. **Make decision** - Auto-approve, require confirmation, or auto-reject
-8. **Handle result** - Approve, reject with revision options, or force-approve
-
-### 8.2 User Interaction (Standard Mode)
-
-After all checks:
-
-```
-Validation Report
-═══════════════════════════════════════════════════════════
-
-✓ Completeness:      PASS (all 9 sections present)
-✓ Consistency:       PASS (all cross-references valid)
-✓ Conventions:       PASS (naming, RBAC, structure OK)
-⚠ Risk Assessment:   HIGH RISK
-  - Functional requirement count: 28 (above 20 threshold)
-  - Consider breaking into multiple iterations
-
-═══════════════════════════════════════════════════════════
-
-Decision:  Specification can be APPROVED
-
-Action:    [ Approve & Continue ] [ Revise ] [ Override ]
-```
-
-### 8.3 Output for Micro Mode
-
-No user interaction needed:
-
-```
-Validation Report (Micro Mode - Auto)
-═══════════════════════════════════════════════════════════
-
-✓ Structure:         PASS (actors, UCs, FRs, matrix, entities, wireframes, gherkin, validations, messages)
-✓ Cross-references:  PASS (UC→FR, FR→BR, Actor→Matrix)
-✓ Naming:            PASS (UC-*, FR-*, PascalCase)
-
-Status:              AUTO-APPROVED
-═══════════════════════════════════════════════════════════
-
-Proceeding to handoff...
-```
-
----
-
-## 9. Output & Status Update
-
-### 9.1 Write Validation Section
-
-Use `ba-writer.updateValidation()` to write:
-
-```json
-{
-  "validation": {
-    "validatedAt": "2025-02-01T10:30:00Z",
-    "completenessChecks": [...],
-    "consistencyChecks": [...],
-    "conventionChecks": [...],
-    "riskAssessments": [...],
-    "decision": {
-      "approved": true,
-      "reason": "Specification complete, consistent, and follows SmartStack conventions",
-      "approvalMode": "standard",
-      "approvedBy": "user_email@company.com",
-      "approvedAt": "2025-02-01T10:35:00Z"
-    }
-  }
-}
-```
-
-### 9.2 Update Status
-
-Use `ba-writer.updateStatus("approved")` to mark validation complete.
-
-(Or keep status as "specified" if rejected.)
-
-### 9.3 User Confirmation (Standard Mode)
-
-```
-✓ Validation complete - APPROVED
-
-Completeness:    9/9 sections present
-Consistency:     28 cross-references valid
-Conventions:     All naming and RBAC patterns followed
-Risks:           Assessed (HIGH: scope count, mitigated in planning)
-
-Next step: Handoff (step-04-handoff.md)
-```
-
----
-
-## OUTPUT
-
-This step enriches **feature.json** with:
-- **validation** section containing validation checks, risk assessment, and approval decision
-- **Status:** "approved" (if validation passes) or "specified" (if rejected, awaiting revision)
-
-**Standard mode:** User confirms before approval.
-**Micro mode:** Auto-validates and auto-approves structural completeness.
-**Delta mode:** Validates only affected sections, preserves existing data.