icdev 1.0.0__py3-none-any.whl

icdev/data/docs/features/phase-13-cicd-integration.md

@@ -0,0 +1,257 @@
+# Phase 13 — CI/CD Integration
+
+**CUI // SP-CTI**
+
+| Field | Value |
+|-------|-------|
+| Phase | 13 |
+| Title | CI/CD Integration |
+| Status | Implemented |
+| Priority | P0 |
+| Dependencies | Phase 12 (Integration Testing), Phase 5 (TDD Workflow) |
+| Author | ICDEV Architect Agent |
+| Date | 2026-02-23 |
+
+---
+
+## 1. Problem Statement
+
+ICDEV's power as an agentic development system is limited if it can only be triggered manually via CLI commands. Gov/DoD development teams use issue trackers (GitHub Issues, GitLab Issues) as their primary work management interface. Developers create issues, write requirements in issue bodies, and expect automated pipelines to plan, build, test, and review code based on those issues. Without CI/CD integration, ICDEV sits outside the team's natural workflow.
+
+Furthermore, Gov/DoD programs often mandate either GitHub (via GitHub Enterprise) or GitLab (via GitLab Ultimate on-prem or GitLab.com SaaS) as their VCS platform. ICDEV must support both equally without requiring teams to switch platforms. A unified VCS abstraction layer allows the same workflow commands (`/icdev_plan`, `/icdev_sdlc`) to work identically on either platform, with platform-specific details (PR vs MR, `gh` vs `glab` CLI) handled transparently.
+
+Bot loop prevention is critical in webhook-driven systems. Without explicit guards, an ICDEV bot comment could trigger another webhook event, which triggers another bot action, creating an infinite loop that consumes CI/CD minutes and floods the issue with duplicate comments. The `[ICDEV-BOT]` identifier in all bot comments provides a simple, reliable mechanism to break this cycle.
+
+---
+
+## 2. Goals
+
+1. Receive webhook events from both GitHub (`/gh-webhook`) and GitLab (`/gl-webhook`) via a Flask webhook server with HMAC-SHA256 (GitHub) and secret token (GitLab) verification
+2. Poll issues every 20 seconds via a cron-based poll trigger that processes new issues and issues with `icdev` comments
+3. Classify workflow requests from issue body or comments (`/icdev_plan`, `/icdev_build`, `/icdev_sdlc`, etc.) and route to appropriate workflow orchestrators
+4. Execute the full SDLC pipeline autonomously: Plan (classify, branch, plan, commit, push), Build (load state, implement, commit, push), Test (suite, gates, commit, push), Review (vs spec, patches, commit, push)
+5. Auto-detect GitHub vs GitLab from `git remote get-url origin` and use the appropriate CLI (`gh` or `glab`) transparently through a unified VCS abstraction
+6. Prevent bot loops by including `[ICDEV-BOT]` in all bot comments and ignoring comments containing this identifier in webhook handlers
+7. Manage persistent state across workflow phases via `agents/{run_id}/icdev_state.json`, supporting piping between scripts for chaining
+8. Generate standardized branch names (`<type>-issue-<num>-icdev-<id>-<name>`) and commit messages (`<agent>: <type>: <message>`) via Claude Code slash commands
+
+---
+
+## 3. Architecture
+
+```
++-----------------------------------------------------------+
+|              Trigger Layer                                 |
+|                                                           |
+|  +-------------------+  +-------------------+             |
+|  | Webhook Server    |  | Poll Trigger      |             |
+|  | (Flask)           |  | (20s interval)    |             |
+|  |                   |  |                   |             |
+|  | POST /gh-webhook  |  | Polls issues for  |             |
+|  | POST /gl-webhook  |  | new or 'icdev'    |             |
+|  | HMAC + token auth |  | comments          |             |
+|  +--------+----------+  +--------+----------+             |
+|           |                      |                        |
++-----------+----------------------+------------------------+
+            |                      |
+            v                      v
++-----------------------------------------------------------+
+|              Workflow Classification                       |
+|                                                           |
+|  /icdev_plan  /icdev_build  /icdev_test  /icdev_review    |
+|  /icdev_sdlc  /icdev_plan_build  /icdev_plan_build_test   |
++----------------------------+------------------------------+
+                             |
+                             v
++-----------------------------------------------------------+
+|              Core Modules                                 |
+|                                                           |
+|  +------+  +-------+  +-------+  +----------+  +------+  |
+|  | VCS  |  | Agent |  | State |  | Git Ops  |  | Wkfl |  |
+|  | gh/  |  | Exec  |  | JSON  |  | Branch/  |  | Ops  |  |
+|  | glab |  | CC CLI|  | file  |  | Commit/  |  | Class|  |
+|  +------+  +-------+  +-------+  | Push/PR  |  +------+  |
+|                                   +----------+            |
++-----------------------------------------------------------+
+                             |
+                             v
++-----------------------------------------------------------+
+|              Workflow Orchestrators                        |
+|                                                           |
+|  icdev_plan.py   --> Classify -> Branch -> Plan -> Commit |
+|  icdev_build.py  --> Load State -> Implement -> Commit    |
+|  icdev_test.py   --> Test Suite -> Gates -> Commit        |
+|  icdev_review.py --> Review vs Spec -> Patches -> Commit  |
+|  icdev_sdlc.py   --> Plan -> Build -> Test -> Review      |
++-----------------------------------------------------------+
+```
+
+### Platform Auto-Detection
+
+```
+git remote get-url origin
+    |
+    +-- contains "github.com" --> GitHub mode (gh CLI)
+    |
+    +-- everything else       --> GitLab mode (glab CLI)
+```
+
+### Bot Loop Prevention
+
+```
+Bot posts comment with [ICDEV-BOT] marker
+    |
+    v
+Webhook receives event for new comment
+    |
+    v
+Check: does comment contain [ICDEV-BOT]?
+    |
+    +-- Yes --> Ignore (break loop)
+    +-- No  --> Process normally
+```
+
+---
+
+## 4. Requirements
+
+### 4.1 Trigger Mechanisms
+
+#### REQ-13-001: Webhook Server
+The system SHALL provide a Flask-based webhook server that receives POST events from GitHub at `/gh-webhook` and GitLab at `/gl-webhook`.
+
+#### REQ-13-002: Webhook Authentication
+GitHub webhooks SHALL be validated via HMAC-SHA256 using `WEBHOOK_SECRET` environment variable. GitLab webhooks SHALL be validated via secret token using `GITLAB_WEBHOOK_TOKEN`.
+
+#### REQ-13-003: Poll Trigger
+The system SHALL provide a polling trigger that checks for new issues or issues with `icdev` comments every 20 seconds, with graceful shutdown via SIGINT/SIGTERM.
+
+#### REQ-13-004: Bot Loop Prevention
+All bot-generated comments SHALL include the `[ICDEV-BOT]` identifier. Webhook handlers SHALL ignore events where the triggering comment contains this identifier.
+
+### 4.2 VCS Abstraction
+
+#### REQ-13-005: Platform Auto-Detection
+The system SHALL auto-detect GitHub vs GitLab from `git remote get-url origin` and route to the appropriate CLI (`gh` or `glab`).
+
+#### REQ-13-006: Unified VCS Module
+The system SHALL provide a unified VCS abstraction module (`tools/ci/modules/vcs.py`) that handles platform-specific operations (PR vs MR, issue comments, labels) transparently.
+
+### 4.3 Workflow Commands
+
+#### REQ-13-007: Workflow Command Parsing
+The system SHALL parse workflow commands from issue body or comments: `/icdev_plan`, `/icdev_build run_id:<id>`, `/icdev_test run_id:<id>`, `/icdev_review run_id:<id>`, `/icdev_sdlc`, and compound variants.
+
+#### REQ-13-008: Build Requires Prior Plan
+The `/icdev_build` command SHALL require a `run_id` parameter referencing a completed plan phase. Invocation without `run_id` SHALL be rejected.
+
+### 4.4 State Management
+
+#### REQ-13-009: Persistent Workflow State
+Workflow state SHALL persist across phases via `agents/{run_id}/icdev_state.json`, containing run_id, issue_number, branch_name, plan_file, issue_class, platform, and project_id.
+
+#### REQ-13-010: State Piping
+Workflow scripts SHALL support piping state between scripts via stdin/stdout for chaining compound workflows.
+
+### 4.5 Code Operations
+
+#### REQ-13-011: Standardized Branch Names
+The system SHALL generate branch names in the format `<type>-issue-<num>-icdev-<id>-<name>` via the `/generate_branch_name` Claude Code command.
+
+#### REQ-13-012: Standardized Commit Messages
+The system SHALL generate commit messages in the format `<agent>: <type>: <message>` via the `/commit` Claude Code command.
+
+### 4.6 Security
+
+#### REQ-13-013: Safe Subprocess Environment
+The system SHALL filter sensitive environment variables before spawning Claude Code CLI subprocesses.
+
+#### REQ-13-014: Webhook Response Handling
+The system SHALL always return HTTP 200 to webhook endpoints to prevent retry storms from the VCS platform.
+
+---
+
+## 5. Database Schema
+
+### Tables
+
+| Table | Purpose |
+|-------|---------|
+| `audit_trail` | Append-only CI/CD event records (plan, build, test, review completions) |
+| `ci_worktrees` | Git worktree records for parallel CI/CD task isolation (Phase 41 extension) |
+| `gitlab_task_claims` | GitLab task polling claims to prevent duplicate processing |
+
+---
+
+## 6. Tools
+
+| Tool | Purpose |
+|------|---------|
+| `tools/ci/triggers/webhook_server.py` | Flask webhook server for GitHub (/gh-webhook) and GitLab (/gl-webhook) events |
+| `tools/ci/triggers/poll_trigger.py` | Cron-based issue polling every 20 seconds |
+| `tools/ci/modules/vcs.py` | Unified VCS abstraction for GitHub (gh) and GitLab (glab) CLI |
+| `tools/ci/modules/agent.py` | Claude Code CLI subprocess invocation |
+| `tools/ci/modules/state.py` | Persistent state management at agents/{run_id}/icdev_state.json |
+| `tools/ci/modules/git_ops.py` | Branch creation, commit, push, PR/MR creation |
+| `tools/ci/modules/workflow_ops.py` | Issue classification, branch naming, commit message formatting |
+| `tools/ci/workflows/icdev_plan.py` | Plan phase: Classify, Branch, Plan, Commit, Push |
+| `tools/ci/workflows/icdev_build.py` | Build phase: Load State, Implement, Commit, Push |
+| `tools/ci/workflows/icdev_test.py` | Test phase: Test Suite, Gates, Commit, Push |
+| `tools/ci/workflows/icdev_review.py` | Review phase: Review vs Spec, Patches, Commit, Push |
+| `tools/ci/workflows/icdev_sdlc.py` | Full SDLC: Plan, Build, Test, Review (sequential or DAG-based) |
+
+---
+
+## 7. Architecture Decisions
+
+| ID | Decision | Rationale |
+|----|----------|-----------|
+| D31 | HMAC-SHA256 event signing for webhook verification | Tamper detection without PKI overhead; secret via environment variable |
+| D32 | Git worktrees with sparse checkout for task isolation | Zero-conflict parallelism, per-task branches, classification markers (Phase 41 extension) |
+| D33 | GitLab tags `{{icdev: workflow}}` for task routing | Mirrors Notion pattern, uses existing VCS abstraction |
+| D35 | Agent executor stores JSONL output in agents/ dir | Auditable, replayable, consistent with observability patterns |
+
+---
+
+## 8. Security Gate
+
+**CI/CD Integration Gate:**
+- Webhook authentication required (HMAC-SHA256 for GitHub, secret token for GitLab)
+- Bot loop prevention active (all bot comments include `[ICDEV-BOT]`)
+- Safe subprocess environment filters sensitive env vars before Claude Code CLI invocation
+- `stdin=subprocess.DEVNULL` prevents Claude Code CLI from hanging
+- Webhook endpoints always return HTTP 200 to prevent retry storms
+- `/icdev_build` rejected without prior plan `run_id` (prevents unplanned builds)
+
+---
+
+## 9. Commands
+
+```bash
+# Trigger mechanisms
+python tools/ci/triggers/webhook_server.py       # Start webhook server
+python tools/ci/triggers/poll_trigger.py          # Start issue polling (20s)
+
+# Individual workflow phases
+python tools/ci/workflows/icdev_plan.py 123       # Plan for issue #123
+python tools/ci/workflows/icdev_build.py 123 abc1234  # Build (requires run-id)
+python tools/ci/workflows/icdev_test.py 123 abc1234   # Test
+python tools/ci/workflows/icdev_review.py 123 abc1234 # Review
+
+# Compound workflows
+python tools/ci/workflows/icdev_sdlc.py 123       # Full SDLC: Plan -> Build -> Test -> Review
+python tools/ci/workflows/icdev_sdlc.py 123 --orchestrated  # DAG-based parallel SDLC
+python tools/ci/workflows/icdev_plan_build.py 123  # Plan + Build
+
+# Git worktree parallel CI/CD (Phase 41 extension)
+python tools/ci/modules/worktree.py --create --task-id test-123 --target-dir src/ --json
+python tools/ci/modules/worktree.py --list --json
+python tools/ci/modules/worktree.py --cleanup --worktree-name icdev-test-123
+
+# GitLab task board monitor (Phase 41 extension)
+python tools/ci/triggers/gitlab_task_monitor.py
+python tools/ci/triggers/gitlab_task_monitor.py --dry-run
+python tools/ci/triggers/gitlab_task_monitor.py --once
+```
+
+**CUI // SP-CTI**

icdev/data/docs/features/phase-14-secure-by-design-ivv.md

@@ -0,0 +1,240 @@
+# Phase 14 — Secure by Design & IV&V
+
+**CUI // SP-CTI**
+
+| Field | Value |
+|-------|-------|
+| Phase | 14 |
+| Title | Secure by Design & Independent Verification and Validation |
+| Status | Implemented |
+| Priority | P1 |
+| Dependencies | Phase 6 (Compliance Workflow), Phase 7 (Security Scanning), Phase 12 (Integration Testing) |
+| Author | ICDEV Architect Agent |
+| Date | 2026-02-23 |
+
+---
+
+## 1. Problem Statement
+
+Traditional compliance assessment treats security as a checklist applied after development. A project can pass individual STIG checks, have no critical CVEs, and maintain 80% test coverage, yet still be fundamentally insecure because security was never an architectural design decision. Default credentials might be absent not because the system enforces unique credentials at the framework level, but because a developer happened to change the defaults. Without Secure by Design (SbD) assessment, there is no distinction between accidental compliance and intentional security architecture.
+
+Similarly, Gov/DoD acquisitions under DoDI 5000.87 (Software Acquisition Pathway) require independent verification and validation (IV&V) as evidence that systems have been independently assessed against requirements. IEEE 1012-2016 defines the V&V standard with 9 process areas covering requirements, design, code, testing, integration, traceability, security, deployment, and process compliance. Without automated IV&V assessment, programs must rely on expensive manual audits that delay ATO timelines by weeks or months.
+
+The Requirements Traceability Matrix (RTM) bridges both standards. SbD needs evidence that security requirements trace from design to implementation to tests. IV&V needs evidence that all requirements (not just security) have forward and backward traceability. The RTM tool discovers requirements from `.feature` files and requirements documents, maps them through design artifacts to source code and tests, and identifies gaps -- untested requirements and orphan tests that trace to no requirement.
+
+---
+
+## 2. Goals
+
+1. Assess applications against CISA Secure by Design commitments across 14 domains with 20 automated checks, covering authentication, memory safety, vulnerability management, cryptography, access control, input handling, supply chain, threat modeling, defense in depth, and CUI compliance
+2. Generate CUI-marked SbD reports with executive summary, CISA 7 Commitment status table, domain-by-domain assessment details, remediation recommendations, and NIST 800-53 control mapping
+3. Generate a Requirements Traceability Matrix (RTM) with forward trace (requirement, design, code, tests), backward trace (test, code, design, requirement), gap analysis, and coverage percentage
+4. Assess applications against IEEE 1012 IV&V across 9 process areas with 18 automated checks, producing certification recommendations (CERTIFY >= 80%, CONDITIONAL >= 60%, DENY < 60%)
+5. Generate CUI-marked IV&V certification reports with verification results, validation results, RTM summary, findings list, independence declaration, and NIST 800-53 control mapping
+6. Assess applications against DoDI 5000.87 Digital Engineering Strategy (DES) requirements for software acquisition pathway compliance
+7. Enforce blocking security gates: 0 critical SbD requirements "not_satisfied", 0 critical IV&V findings, 0 non-compliant DES requirements
+8. Record all assessment events in the append-only audit trail satisfying NIST SA-11, SA-15, SA-24, and CM-3
+
+---
+
+## 3. Architecture
+
+```
++-----------------------------------------------------------+
+|              Assessment Pipeline                          |
+|                                                           |
+|  Step 1: SbD Assessment (14 domains, 20 checks)          |
+|  +----------------------------------------------------+  |
+|  | Authentication | Memory Safety | Vuln Mgmt | Crypto |  |
+|  | Access Control | Input Handling | Error Handling    |  |
+|  | Supply Chain | Threat Modeling | Defense in Depth   |  |
+|  | Secure Defaults | CUI Compliance | DoD Assurance    |  |
+|  +----------------------------------------------------+  |
+|           |                                               |
+|  Step 2: SbD Report Generation                            |
+|           |                                               |
+|  Step 3: RTM Generation                                   |
+|  +----------------------------------------------------+  |
+|  | Requirements --> Design --> Code --> Tests           |  |
+|  | .feature files   arch.md    src/    tests/          |  |
+|  | requirements.md  ADR dir                            |  |
+|  +----------------------------------------------------+  |
+|           |                                               |
+|  Step 4: IV&V Assessment (9 process areas, 18 checks)    |
+|  +----------------------------------------------------+  |
+|  | Requirements Verification  | Design Verification    |  |
+|  | Code Verification          | Test Verification      |  |
+|  | Integration Verification   | Traceability Analysis  |  |
+|  | Security Verification      | Build/Deploy Verify    |  |
+|  | Process Compliance                                  |  |
+|  +----------------------------------------------------+  |
+|           |                                               |
+|  Step 5: IV&V Report + Certification Recommendation       |
+|           |                                               |
+|  Step 6: DES Assessment (DoDI 5000.87)                    |
+|           |                                               |
+|  Step 7: Audit Trail                                      |
++-----------------------------------------------------------+
+```
+
+### SbD Scoring
+
+```
+Score = 100 * (satisfied + partial * 0.5 + risk_accepted * 0.75) / assessable_count
+```
+
+### IV&V Scoring
+
+```
+Verification (60%): Average of process areas 1-6
+Validation   (40%): Average of process areas 4-5 (test-focused)
+Overall:            Weighted combination
+
+CERTIFY:     >= 80% overall, 0 critical findings
+CONDITIONAL: >= 60% overall, 0 critical findings
+DENY:        < 60% OR any critical findings
+```
+
+---
+
+## 4. Requirements
+
+### 4.1 Secure by Design Assessment
+
+#### REQ-14-001: 14-Domain SbD Assessment
+The system SHALL assess applications across 14 Secure by Design domains: authentication, memory safety, vulnerability management, intrusion evidence, cryptography, access control, input handling, error handling, supply chain, threat modeling, defense in depth, secure defaults, CUI compliance, and DoD software assurance.
+
+#### REQ-14-002: CISA 7 Commitment Mapping
+The system SHALL map assessment results to the CISA Secure by Design Pledge 7 commitments, producing a commitment status table in the generated report.
+
+#### REQ-14-003: SbD Scoring
+The system SHALL calculate SbD scores using the formula: 100 * (satisfied + partial * 0.5 + risk_accepted * 0.75) / assessable_count.
+
+#### REQ-14-004: SbD Critical Gate
+The system SHALL block deployment when any critical SbD requirement is "not_satisfied" (0 critical not_satisfied = PASS).
+
+### 4.2 Requirements Traceability Matrix
+
+#### REQ-14-005: Forward and Backward Traceability
+The system SHALL generate forward traces (requirement to design to code to tests) and backward traces (test to code to design to requirement) for all discovered artifacts.
+
+#### REQ-14-006: Gap Analysis
+The RTM SHALL identify untested requirements and orphan tests (tests that trace to no requirement), calculating coverage percentage.
+
+#### REQ-14-007: Multi-Source Discovery
+The RTM tool SHALL discover requirements from `.feature` files, `requirements.md`, and user stories; design from `architecture.md`, `system_design.md`, and ADR directories; code from `src/` modules; and tests from `tests/` directories.
+
+### 4.3 IV&V Assessment
+
+#### REQ-14-008: 9-Process-Area IV&V Assessment
+The system SHALL assess applications across 9 IEEE 1012 process areas: requirements verification, design verification, code verification, test verification, integration verification, traceability analysis, security verification, build/deploy verification, and process compliance.
+
+#### REQ-14-009: Certification Recommendation
+The system SHALL produce certification recommendations: CERTIFY (>= 80% overall, 0 critical findings), CONDITIONAL (>= 60% overall, 0 critical findings), DENY (< 60% or any critical findings).
+
+#### REQ-14-010: Independence Declaration
+IV&V reports SHALL include an independence declaration per IEEE 1012-2016, stating that automated assessment provides process verification (human-independent assessment may additionally be required for formal certification).
+
+### 4.4 DES Compliance
+
+#### REQ-14-011: DoDI 5000.87 DES Assessment
+The system SHALL assess applications against DoDI 5000.87 Digital Engineering Strategy requirements, including digital engineering ecosystem, model-based approaches, data management, and infrastructure requirements.
+
+#### REQ-14-012: DES Critical Gate
+The system SHALL block deployment when any critical DES requirement is "non_compliant" (0 non_compliant critical = PASS).
+
+### 4.5 Reporting and Compliance
+
+#### REQ-14-013: CUI-Marked Reports
+All generated reports (SbD, IV&V, DES) SHALL include CUI markings appropriate to the project's impact level.
+
+#### REQ-14-014: NIST 800-53 Control Mapping
+Assessment results SHALL be mapped to NIST 800-53 Rev 5 controls (SA-11, SA-15, SA-24 and others) for crosswalk integration with other compliance frameworks.
+
+#### REQ-14-015: Certification Validity Period
+IV&V certifications SHALL expire after 12 months per `args/project_defaults.yaml`, requiring re-assessment after significant changes.
+
+---
+
+## 5. Database Schema
+
+### Tables
+
+| Table | Purpose |
+|-------|---------|
+| `sbd_assessments` | SbD assessment results per project with domain scores, overall score, and finding details |
+| `ivv_assessments` | IV&V assessment results per project with process area scores, certification recommendation |
+| `des_assessments` | DES compliance assessment results per project |
+| `traceability_links` | RTM forward and backward trace links between requirements, design, code, and test artifacts |
+| `audit_trail` | Append-only assessment event records (NIST AU compliance) |
+
+---
+
+## 6. Tools
+
+| Tool | Purpose |
+|------|---------|
+| `tools/compliance/sbd_assessor.py` | Secure by Design assessment across 14 domains with 20 automated checks |
+| `tools/compliance/sbd_report_generator.py` | CUI-marked SbD report with CISA commitment status and remediation recommendations |
+| `tools/compliance/traceability_matrix.py` | RTM generation with forward/backward trace, gap analysis, coverage percentage |
+| `tools/compliance/ivv_assessor.py` | IEEE 1012 IV&V assessment across 9 process areas with 18 automated checks |
+| `tools/compliance/ivv_report_generator.py` | CUI-marked IV&V certification report with independence declaration |
+| `tools/mbse/des_assessor.py` | DoDI 5000.87 Digital Engineering Strategy compliance assessment |
+| `tools/mbse/des_report_generator.py` | CUI-marked DES compliance report |
+| `tools/audit/audit_logger.py` | Append-only audit trail recording for all assessment events |
+
+---
+
+## 7. Architecture Decisions
+
+| ID | Decision | Rationale |
+|----|----------|-----------|
+| D5 | CUI markings applied at generation time (inline, not post-processing) | All SbD/IV&V/DES reports include CUI banners from the start, not added after the fact |
+| D6 | Audit trail is append-only/immutable | Assessment events satisfy NIST AU controls with tamper-evident recording |
+| D111 | Dual-hub crosswalk model (NIST 800-53 US hub, ISO 27001 international hub) | SbD/IV&V findings crosswalk through NIST 800-53 to all other frameworks automatically |
+| D116 | BaseAssessor ABC pattern for all compliance assessors | SbD/IV&V assessors inherit crosswalk integration, gate evaluation, and CLI from base class |
+
+---
+
+## 8. Security Gate
+
+**SbD Gate:**
+- 0 critical SbD requirements "not_satisfied"
+- CISA 7 Commitments assessed and documented
+- SbD report generated with CUI markings
+
+**IV&V Gate:**
+- 0 critical IV&V findings
+- Certification recommendation not "DENY"
+- Independence declaration included in report
+- RTM generated with gap analysis
+
+**DES Gate:**
+- 0 non_compliant critical DoDI 5000.87 Digital Engineering requirements
+- DES report generated with CUI markings
+
+---
+
+## 9. Commands
+
+```bash
+# Secure by Design assessment
+python tools/compliance/sbd_assessor.py --project-id "proj-123" --domain all
+python tools/compliance/sbd_report_generator.py --project-id "proj-123"
+
+# Requirements Traceability Matrix
+python tools/compliance/traceability_matrix.py --project-id "proj-123" --project-dir "/path"
+
+# IV&V assessment
+python tools/compliance/ivv_assessor.py --project-id "proj-123" --process-area all
+python tools/compliance/ivv_report_generator.py --project-id "proj-123"
+
+# DES assessment (DoDI 5000.87)
+python tools/mbse/des_assessor.py --project-id "proj-123" --project-dir /path --json
+python tools/mbse/des_report_generator.py --project-id "proj-123" --output-dir /path
+
+# Audit trail
+python tools/audit/audit_logger.py --event-type "sbd_ivv.assessed" --actor "orchestrator" --action "SbD + IV&V assessment complete" --project-id "proj-123"
+```
+
+**CUI // SP-CTI**