icdev 0.0.3__py3-none-any.whl

goals/build_app.md

@@ -0,0 +1,604 @@
+# Build App — ATLAS Workflow
+
+## Goal
+
+Build full-stack applications using AI assistance within the GOTCHA framework. This workflow ensures apps are production-ready, not just demos.
+
+**ATLAS** is a 5-step process (6 steps with optional Critique phase):
+
+| Step | Phase | What You Do |
+|------|-------|-------------|
+| **A** | Architect | Define problem, users, success metrics |
+| **T** | Trace | Data schema, integrations map, stack proposal |
+| **L** | Link | Validate ALL connections before building |
+| **A** | Assemble | Build with layered architecture |
+| **C** | Critique | *(Optional)* Adversarial multi-agent plan review |
+| **S** | Stress-test | Test functionality, error handling |
+
+When the Critique phase is enabled (`atlas_critique.enabled: true` in `args/atlas_critique_config.yaml`), the workflow becomes **ATLAS-CR**:
+
+```
+A(rchitect) → T(race) → L(ink) → A(ssemble) → C(ritique) → S(tress-test)
+```
+
+```mermaid
+flowchart LR
+    A["A: Architect\nDefine problem, users,\nsuccess metrics"]
+    T["T: Trace\nData schema,\nintegrations, stack"]
+    L["L: Link\nValidate connections,\ntest APIs"]
+    As["A: Assemble\nBuild layers\nDB → Backend → UI"]
+    C["C: Critique\nAdversarial\nmulti-agent review"]
+    S["S: Stress-test\nFunctional, integration,\nedge case tests"]
+    A --> T --> L --> As --> C --> S
+    C -.->|CONDITIONAL\nrevise| As
+    C -.->|NOGO\nescalate| Stop["Human\nEscalation"]
+    S -.->|Issues found| As
+    style A fill:#1a3a5c,stroke:#4a90d9,color:#e0e0e0
+    style T fill:#1a3a5c,stroke:#4a90d9,color:#e0e0e0
+    style L fill:#1a3a5c,stroke:#4a90d9,color:#e0e0e0
+    style As fill:#1a3a5c,stroke:#4a90d9,color:#e0e0e0
+    style C fill:#3a1a3a,stroke:#9b59b6,color:#e0e0e0
+    style S fill:#1a3a2d,stroke:#28a745,color:#e0e0e0
+    style Stop fill:#3a1a1a,stroke:#e74c3c,color:#e0e0e0
+```
+
+If the Critique phase is disabled, ATLAS operates as the original 5-step process (backward compatible).
+
+## For prod builds when asked specifically add:
++ V - Validate (security/input sanitization, edge cases, unit tests)
++ M - Monitor (logging, observability, alerts)
+
+---
+
+## A — Architect
+
+**Purpose:** Know exactly what you're building before touching code.
+
+### Step 0: Agentic Fitness Assessment (Phase 19)
+
+Before answering architecture questions, evaluate the component's fitness for agentic architecture:
+
+```bash
+python tools/builder/agentic_fitness.py --spec "<component description>" --project-id "<id>" --json
+```
+
+The assessor scores 6 dimensions (data_complexity, decision_complexity, user_interaction, integration_density, compliance_sensitivity, scale_variability) and recommends: **agent**, **hybrid**, or **traditional** architecture. Use the scorecard to guide all downstream decisions (scaffolding, code generation, infrastructure).
+
+See `context/agentic/fitness_rubric.md` for the scoring rubric.
+
+### Questions to Answer
+
+1. **What problem does this solve?**
+   - One sentence. If you can't say it simply, you don't understand it.
+
+2. **Who is this for?**
+   - Specific user: "Me" / "Sales team" / "YouTube subscribers"
+   - Not "everyone"
+
+3. **What does success look like?**
+   - Measurable outcome: "I can see my metrics in one dashboard"
+   - Not vague: "It works"
+
+4. **What are the constraints?**
+   - Budget (API costs)
+   - Time (MVP vs full build)
+   - Technical (must use Supabase, must integrate with X)
+
+### Output
+
+```markdown
+## App Brief
+- **Problem:** [One sentence]
+- **User:** [Who specifically]
+- **Success:** [Measurable outcome]
+- **Constraints:** [List]
+```
+
+---
+
+## T — Trace
+
+**Purpose:** Design before building. This is where most "vibe coders" fail.
+
+### Data Schema
+
+Define your source of truth BEFORE building:
+
+```
+Tables:
+- users (id, email, name, created_at)
+- saved_items (id, user_id, title, content, source, created_at)
+- metrics (id, user_id, platform, value, date)
+
+Relationships:
+- users 1:N saved_items
+- users 1:N metrics
+```
+
+### Integrations Map
+
+List every external connection:
+
+| Service | Purpose | Auth Type | MCP Available? |
+|---------|---------|-----------|----------------|
+| Supabase | Database | API Key | Yes |
+| YouTube API | Metrics | OAuth | Via MCP |
+| Notion | Save items | API Key | Yes |
+
+### Technology Stack Proposal
+
+Based on requirements, propose:
+- Database (Supabase, Firebase, Postgres, etc.)
+- Backend (Supabase Functions, n8n, custom API)
+- Frontend (React, Next.js, vanilla, etc.)
+- Any other services needed
+
+User approves or overrides before proceeding.
+
+### Edge Cases
+
+Document what could break:
+
+- API rate limits (YouTube: 10,000 quota/day)
+- Auth token expiry
+- Database connection timeout
+- Invalid user input
+- MCP server unavailability
+
+### Output
+
+- Data schema diagram or markdown table
+- Technology stack (approved by user)
+- Integrations checklist
+- Edge cases documented
+
+---
+
+## L — Link
+
+**Purpose:** Validate all connections BEFORE building. Nothing worse than building for 2 hours then discovering the API doesn't work.
+
+### Connection Validation Checklist
+
+```
+[ ] Database connection tested
+[ ] All API keys verified
+[ ] MCP servers responding
+[ ] OAuth flows working
+[ ] Environment variables set
+[ ] Rate limits understood
+```
+
+### How to Test
+
+**Database:**
+```bash
+# Test via MCP or direct API call
+# Should return empty array or existing data, not error
+```
+
+**APIs:**
+```bash
+# Make a simple GET request
+# Verify response format matches expectations
+```
+
+**MCPs:**
+```
+# List available tools
+# Test one simple operation
+```
+
+### Output
+
+All green checkmarks. If anything fails, fix it before proceeding.
+
+---
+
+## A — Assemble
+
+**Purpose:** Build the actual application with proper architecture.
+
+### Architecture Layers
+
+Follow GOTCHA separation:
+
+1. **Frontend** (what user sees)
+   - UI components
+   - User interactions
+   - Display logic
+
+2. **Backend** (what makes it work)
+   - API routes
+   - Business logic
+   - Data validation
+
+3. **Database** (source of truth)
+   - Schema implementation
+   - Migrations
+   - Indexes
+
+### Build Order
+
+1. Database schema first
+2. Backend API routes second
+3. Frontend UI last
+
+This order prevents building UI for data structures that don't exist.
+
+### Component Strategy
+
+- Use existing component libraries (don't reinvent buttons)
+- Keep components small and focused
+- Document any non-obvious logic
+
+### Output
+
+Working application with:
+- Functional database
+- API endpoints responding
+- UI rendering correctly
+
+---
+
+## C — Critique (Optional, Phase 61)
+
+**Purpose:** Adversarial multi-agent review of the Assemble output before stress-testing. Catches security, compliance, and architectural issues early through independent parallel review.
+
+This phase is **optional** and controlled by `atlas_critique.enabled` in `args/atlas_critique_config.yaml`. When disabled, ATLAS proceeds directly from Assemble to Stress-test (backward compatible).
+
+### How It Works
+
+1. The Assemble-phase output (plan/implementation) is dispatched to **3 critic agents** in parallel:
+   - **Security Agent** — Reviews for vulnerabilities, attack surface, OWASP Top 10, STIG compliance
+   - **Compliance Agent** — Reviews for NIST 800-53 gaps, FedRAMP requirements, CUI markings, audit trail
+   - **Knowledge Agent** — Reviews for architecture flaws, performance risks, maintainability, testing gaps
+
+2. Each agent independently produces findings classified by severity: **critical**, **high**, **medium**, **low**
+
+3. A **consensus vote** determines the outcome:
+   - **GO** (0 critical, 0 high) — Proceed to Stress-test
+   - **CONDITIONAL** (0 critical, >0 high) — Loop back to Assemble with fix list (max 3 rounds)
+   - **NOGO** (>0 critical) — Stop, escalate to human
+
+4. If CONDITIONAL, the architect revises and resubmits. Up to `max_rounds` (default 3) revision cycles.
+
+### Running the Critique
+
+```bash
+# Run critique on plan text
+python tools/agent/atlas_critique.py --project-id "proj-123" \
+    --phase-output "plan text here" --json
+
+# Run critique on a file
+python tools/agent/atlas_critique.py --project-id "proj-123" \
+    --phase-output /path/to/plan.md --json
+
+# Check session status
+python tools/agent/atlas_critique.py --project-id "proj-123" \
+    --session-id "crit-abc123" --status --json
+
+# View critique history for a project
+python tools/agent/atlas_critique.py --project-id "proj-123" \
+    --history --json
+```
+
+### Finding Types
+
+| Type | Description |
+|------|-------------|
+| `security_vulnerability` | Security weakness or attack vector |
+| `compliance_gap` | Missing or incomplete compliance control |
+| `architecture_flaw` | Design pattern violation or structural issue |
+| `performance_risk` | Potential performance bottleneck |
+| `maintainability_concern` | Code quality or maintainability issue |
+| `testing_gap` | Missing or inadequate test coverage |
+| `deployment_risk` | Deployment or operational risk |
+| `data_handling_issue` | Data classification, encryption, or handling gap |
+
+### Configuration
+
+See `args/atlas_critique_config.yaml` for:
+- Critic agent assignments and focus areas
+- Consensus rules (GO/NOGO/CONDITIONAL thresholds)
+- Revision prompt template
+- Max rounds
+
+### Output
+
+Critique result with:
+- Consensus decision (GO/NOGO/CONDITIONAL)
+- All findings with severity, type, and suggested fixes
+- Revision summary (if CONDITIONAL with revisions)
+- Round count
+
+---
+
+## S — Stress-test
+
+**Purpose:** Test before shipping. This is the step most "vibe coding" tutorials skip entirely.
+
+### Functional Testing
+
+Does it actually work?
+
+```
+[ ] All buttons do what they should
+[ ] Data saves to database
+[ ] Data retrieves correctly
+[ ] Navigation works
+[ ] Error states handled
+```
+
+### Integration Testing
+
+Do the connections hold?
+
+```
+[ ] API calls succeed
+[ ] MCP operations work
+[ ] Auth persists across sessions
+[ ] Rate limits not exceeded
+```
+
+### Edge Case Testing
+
+What breaks?
+
+```
+[ ] Invalid input handled gracefully
+[ ] Empty states display correctly
+[ ] Network errors show feedback
+[ ] Long text doesn't break layout
+```
+
+### Acceptance Criteria Validation (V&V)
+
+Validate that what was built matches what was required. This is a **mandatory gate** — not a soft checklist.
+
+```bash
+python tools/testing/acceptance_validator.py \
+    --plan <plan_file> \
+    --test-results .tmp/test_runs/<run_id>/state.json \
+    --base-url <app_url if applicable> \
+    --pages <list of pages from plan> \
+    --json
+```
+
+**GATE (per `security_gates.yaml` `acceptance_validation`):**
+- 0 failed acceptance criteria
+- 0 pages rendering with error patterns (500, tracebacks, JS errors)
+- Plan MUST have `## Acceptance Criteria` section
+
+If gate fails: review the plan's acceptance criteria against actual implementation, fix gaps, and re-run.
+
+### Output
+
+Test report with:
+- What passed
+- What failed
+- What needs fixing
+- Acceptance criteria verification results
+
+---
+
+## M-ATLAS Variant (MBSE-Enabled Projects)
+
+If the project has `mbse_enabled=1`, use the **M-ATLAS** workflow which adds a **Model** pre-phase:
+
+| Step | Phase | What You Do |
+|------|-------|-------------|
+| **M** | Model | Import XMI/ReqIF, build digital thread, generate code scaffolding |
+| **A** | Architect | System design informed by model elements |
+| **T** | Trace | Data schema + integrations (augmented with model traceability) |
+| **L** | Link | Validate connections including model-code mappings |
+| **A** | Assemble | Build with model-generated scaffolding as starting point |
+| **C** | Critique | *(Optional)* Adversarial multi-agent plan review |
+| **S** | Stress-test | Test including model-generated test stubs |
+
+```mermaid
+flowchart LR
+    Check{"MBSE\nenabled?"}
+    M["M: Model\nImport XMI/ReqIF,\ndigital thread,\ncode scaffolding"]
+    A["A: Architect\nSystem design informed\nby model elements"]
+    T["T: Trace\nData schema +\nmodel traceability"]
+    L["L: Link\nValidate connections +\nmodel-code mappings"]
+    As["A: Assemble\nBuild with model-generated\nscaffolding"]
+    C["C: Critique\nAdversarial\nmulti-agent review"]
+    S["S: Stress-test\nTest including\nmodel-generated stubs"]
+    Check -->|Yes| M --> A
+    Check -->|No| A
+    A --> T --> L --> As --> C --> S
+    C -.->|CONDITIONAL| As
+    S -.->|Issues found| As
+    style Check fill:#3a3a1a,stroke:#ffc107,color:#e0e0e0
+    style M fill:#1a3a5c,stroke:#4a90d9,color:#e0e0e0
+    style A fill:#1a3a5c,stroke:#4a90d9,color:#e0e0e0
+    style T fill:#1a3a5c,stroke:#4a90d9,color:#e0e0e0
+    style L fill:#1a3a5c,stroke:#4a90d9,color:#e0e0e0
+    style As fill:#1a3a5c,stroke:#4a90d9,color:#e0e0e0
+    style C fill:#3a1a3a,stroke:#9b59b6,color:#e0e0e0
+    style S fill:#1a3a2d,stroke:#28a745,color:#e0e0e0
+```
+
+### M — Model Phase
+
+**Purpose:** Import authoritative system model and establish digital thread before design.
+
+1. Import latest XMI from Cameo: `python tools/mbse/xmi_parser.py --project-id X --file model.xmi`
+2. Import latest ReqIF from DOORS NG: `python tools/mbse/reqif_parser.py --project-id X --file reqs.reqif`
+3. Build digital thread: `python tools/mbse/digital_thread.py --project-id X auto-link`
+4. Generate code scaffolding: `python tools/mbse/model_code_generator.py --project-id X --language python --output ./src`
+5. Map model to NIST controls: `python tools/mbse/model_control_mapper.py --project-id X --map-all`
+
+If no model exists, skip this phase — ATLAS starts at Architect (backward compatible).
+
+---
+
+## Post-Implementation Checklist (Mandatory)
+
+After Stress-test passes, the following steps are **mandatory** before declaring a phase/feature complete:
+
+### 1. Playwright E2E Verification (if dashboard changes exist)
+
+If the implementation added or modified dashboard pages, routes, or templates:
+
+```
+[ ] Start dashboard: python tools/dashboard/app.py
+[ ] Login via Playwright MCP
+[ ] Navigate to the new/changed page
+[ ] Verify page loads (HTTP 200, no server errors)
+[ ] Test interactive elements (forms, buttons, dropdowns, modals)
+[ ] Verify form validation (submit with missing fields)
+[ ] Verify successful form submission (end-to-end: UI → API → DB → table update)
+[ ] Take screenshot at desktop viewport (1440x900)
+[ ] Take screenshot at tablet viewport (768x1024)
+[ ] Take screenshot at mobile viewport (375x812)
+[ ] Check browser console for errors (ignore pre-existing SSE polling errors)
+[ ] Fix ALL issues found — do not defer
+[ ] Create/update E2E test spec in .claude/commands/e2e/<page>.md
+```
+
+**Do NOT wait for the user to request this.** Playwright E2E is part of Stress-test, not a separate step.
+
+### 2. Feature Documentation
+
+Create `docs/features/phase-{N}-{descriptive-slug}.md` following the standard format:
+
+```
+[ ] CUI // SP-CTI markings (top and bottom)
+[ ] Metadata table (Phase, Title, Status, Priority, Dependencies, Author, Date)
+[ ] Problem Statement — what gaps existed
+[ ] Goals — numbered list of objectives
+[ ] Architecture — pipeline stages, data flow, key components
+[ ] Database Schema — new tables with type (CRUD/append-only) and purpose
+[ ] Configuration — relevant args/*.yaml sections
+[ ] CLI Commands — all new tool commands with examples
+[ ] Dashboard — routes, pages, features
+[ ] Architecture Decisions — ADR table (D-XXX)
+[ ] Testing — test commands and categories
+[ ] Security Considerations — CUI, append-only, access control, etc.
+```
+
+**Do NOT wait for the user to request this.** Documentation is a mandatory deliverable of every phase.
+
+### 3. CLAUDE.md Updates
+
+If the phase added new capabilities, update CLAUDE.md:
+- New DB tables → update table count
+- New tools → update tool count
+- New ADRs → add to Architecture Decisions section
+- New pipeline stages → update relevant section
+- New dashboard pages → update page list
+- New tests → add test command
+- New slash commands → update skills table
+
+---
+
+## Note: Deployment
+
+Deployment is **not part of this workflow**. It's a separate, user-initiated action.
+
+When you're ready to deploy, explicitly ask. This keeps deployment decisions in your control, not automated.
+
+---
+
+## Anti-Patterns (What NOT to Do)
+
+These are the mistakes "vibe coders" make:
+
+1. **Building before designing** — You end up rewriting everything
+2. **Skipping connection validation** — Hours wasted on broken integrations
+3. **No data modeling** — Schema changes cascade into UI rewrites
+4. **No testing** — Ship broken code, lose trust
+5. **Hardcoding everything** — No flexibility for changes
+
+---
+
+## GOTCHA Layer Mapping
+
+| ATLAS Step | GOTCHA Layer |
+|------------|--------------|
+| Architect | Goals (define the process) |
+| Trace | Context (reference patterns) |
+| Link | Args (environment setup) |
+| Assemble | Tools (execution) |
+| Critique | Orchestration (multi-agent adversarial review) |
+| Stress-test | Orchestration (AI validates) |
+
+
+---
+
+## Related Files
+
+- **Args:** `args/app_defaults.yaml` (if created)
+- **Context:** `context/ui_patterns/` (design references)
+- **Hard Prompts:** `hardprompts/app_building/` (generation templates)
+
+---
+
+## Mandatory: Child Application Generation Pipeline
+
+When building a **child application** (an application generated by ICDEV), the following rules are **mandatory**:
+
+### 1. Use the Child App Generator Pipeline
+
+All child applications MUST be generated through the `child_app_generator.py` pipeline (`tools/builder/child_app_generator.py`). This pipeline executes 16 steps that ensure every GOTCHA layer is populated:
+
+1. Directory tree creation (all 6 GOTCHA layer directories)
+2. Tool generation (deterministic Python scripts)
+3. Agent infrastructure (agent cards, A2A protocol)
+4. Memory system (MEMORY.md, logs, SQLite)
+5. Database initialization (standalone init script)
+6. Goals and hard prompts (adapted from ICDEV)
+7. Args and context (YAML configs, reference material)
+8. A2A callback client (parent-child communication)
+9. CI/CD setup (GitHub + GitLab)
+10. CSP MCP configuration (cloud provider integration)
+11. Dynamic CLAUDE.md generation (Jinja2)
+12. Audit trail and child registry registration
+13. Production audit (38-check readiness scan)
+14. **GOTCHA compliance validation** (6-layer + 4 meta checks)
+
+**Do NOT manually scaffold child applications.** Manual creation bypasses GOTCHA layer population, ATLAS workflow integration, and compliance validation.
+
+### 2. Post-Generation GOTCHA Validation
+
+After generation, `gotcha_validator.py` (`tools/builder/gotcha_validator.py`) MUST pass with `--gate` mode. This validates:
+
+| Check | GOTCHA Layer | Requirement |
+|-------|-------------|-------------|
+| Goals | G | `goals/manifest.md` exists + at least `build_app.md` + 1 other goal |
+| Orchestration | O | Agent cards in `tools/agent/cards/` OR `args/agent_config.yaml` |
+| Tools | T | `tools/` has at least 3 subdirectories |
+| Args | A | `args/` has at least 1 YAML file |
+| Context | C | `context/` has at least 1 subdirectory with content |
+| Hard Prompts | H | `hardprompts/` has at least 1 `.md` file |
+| CLAUDE.md | meta | Exists and references "GOTCHA" |
+| Memory | meta | `memory/MEMORY.md` exists |
+| Database | meta | `tools/db/` has an init script |
+| ATLAS | meta | `goals/build_app.md` exists |
+
+### 3. BMAD Quality Gates (Recommended)
+
+ICDEV includes BMAD Method tools that SHOULD be used during child app generation:
+
+- **PRD Validator** (`tools/requirements/prd_validator.py`) — Validate requirements quality before building
+- **Complexity Scorer** (`tools/requirements/complexity_scorer.py`) — Assess project complexity to select appropriate pipeline
+- **Elicitation Techniques** (`tools/requirements/elicitation_techniques.py`) — Use structured reasoning (pre-mortem, first principles) during architecture
+- **Adversarial Review** (`.claude/commands/review.md`) — Run adversarial code review with minimum 3 issues per review
+
+### 4. Entry Point
+
+The `/icdev-agentic` command is the standard entry point for generating child applications. It orchestrates:
+1. Requirements gathering
+2. Fitness assessment (6-dimension scoring)
+3. User decision confirmation
+4. Blueprint generation
+5. Child app generation (16-step pipeline)
+6. GOTCHA validation gate
+7. Verification and reporting
+
+---
+
+## Changelog

goals/cato_live_evidence.md

@@ -0,0 +1,77 @@
+# CUI // SP-CTI
+
+# F1: cATO Live Evidence Engine
+
+## Purpose
+
+Continuously collect, stream, and refresh compliance evidence for continuous Authority to Operate (cATO). Replaces periodic manual evidence gathering with automated, schedule-driven collection tied to OSCAL-formatted control catalogs.
+
+## Prerequisites
+
+- `data/icdev.db` initialized with compliance tables
+- OSCAL catalog loaded via `tools/compliance/oscal_generator.py`
+- Control mappings populated via `tools/compliance/control_mapper.py`
+
+## Workflow Steps
+
+### 1. Stream OSCAL Evidence
+```bash
+python tools/compliance/cato_live_engine.py --stream-oscal --project-id "sparkpilot" --json
+```
+**Expected output:** JSON with `oscal_stream` array of control-evidence pairs, timestamps, and freshness scores.
+
+### 2. Get Evidence Dashboard
+```bash
+python tools/compliance/cato_live_engine.py --dashboard --project-id "sparkpilot" --json
+```
+**Expected output:** JSON summary with total controls, evidence coverage percentage, stale count, and freshness histogram.
+
+### 3. Get Evidence Timeline
+```bash
+python tools/compliance/cato_live_engine.py --timeline --project-id "sparkpilot" --window-days 30 --json
+```
+**Expected output:** JSON array of evidence collection events with timestamps, control IDs, source, and staleness flags.
+
+### 4. Trigger Evidence Collection
+```bash
+python tools/compliance/cato_live_engine.py --collect --project-id "sparkpilot" --control-family AC --json
+```
+**Expected output:** JSON with collection results per control, new evidence count, errors, and next scheduled run.
+
+### 5. Check Freshness SLA
+```bash
+python tools/compliance/cato_live_engine.py --freshness-check --project-id "sparkpilot" --sla-hours 24 --json
+```
+**Expected output:** JSON with SLA compliance status, stale controls list, and recommended actions.
+
+## Decision Reference
+
+| Decision | Description |
+|----------|-------------|
+| D-INV-1 | Evidence stored in append-only SQLite tables (NIST AU compliant) |
+| D-INV-2 | OSCAL streaming uses incremental diff -- only changed controls re-collected |
+| D-INV-3 | Freshness scored 0.0-1.0 based on hours since last collection vs SLA threshold |
+| D-INV-4 | Scheduler uses stdlib `sched` module -- no external dependencies |
+
+## Edge Cases
+
+- Missing OSCAL catalog returns error with setup instructions
+- Stale evidence older than 2x SLA flagged as CRITICAL, not just WARNING
+- Air-gapped mode: all collection is local scan only, no external API calls
+- Empty control family returns note listing available families
+
+## Tier Gating
+
+| Capability | Community | Pro |
+|------------|-----------|-----|
+| Manual evidence collection | Yes | Yes |
+| Evidence dashboard | Yes | Yes |
+| Automated scheduling | No | Yes |
+| 24h freshness SLA enforcement | No | Yes |
+| OSCAL streaming with incremental diff | No | Yes |
+
+## Security
+
+- All evidence records are append-only (NIST AU compliant)
+- Collection audit trail logged to `audit_trail` table
+- CUI markings applied to all generated evidence artifacts