icdev 0.0.3__py3-none-any.whl

docs/adr/README.md

@@ -0,0 +1,66 @@
+# CUI // SP-CTI
+# Architecture Decision Records — Index
+
+**Total decisions:** 104
+**Last updated:** 2026-03-08
+
+## Decision Groups
+
+| Group | File | Count | Description |
+|-------|------|-------|-------------|
+| Core Architecture | [core-decisions.md](core-decisions.md) | 20 | Foundational system decisions: protocols, data models, compliance, observability |
+| Database & Storage | [db-decisions.md](db-decisions.md) | 6 | PostgreSQL migration, storage abstraction, schema versioning |
+| Connector Forge & CloudForge | [connector-forge-decisions.md](connector-forge-decisions.md) | 22 | Dynamic connector generation, runbooks, metastore, ops server |
+| Innovation Features | [innovation-decisions.md](innovation-decisions.md) | 18 | cATO, DORA, narratives, threat modeling, scorecard, golden path, SBOM |
+| WriteGuard | [writeguard-decisions.md](writeguard-decisions.md) | 9 | AI writing assistant: deterministic pipeline, style guides, analysis |
+| Marketplace | [marketplace-decisions.md](marketplace-decisions.md) | 7 | SaaS extraction, licensing, community model, sponsor tiers |
+| Scale Engine | [scale-engine-decisions.md](scale-engine-decisions.md) | 7 | Parallel sync execution, connection pools, batch writes |
+| Harness Engineering | [harness-decisions.md](harness-decisions.md) | 8 | Loop detection, maturity assessment, exit criteria, trace analysis |
+| Secure by Design | [sbd-decisions.md](sbd-decisions.md) | 7 | CISA SbD, Cloudyrion 8-Pillar, exception registry, scorecard integration |
+
+## Summary by Status
+
+| Status | Count |
+|--------|-------|
+| Accepted | 103 |
+| Superseded | 1 |
+
+## Superseded Decisions
+
+| ID | Superseded By | Original Decision |
+|----|---------------|-------------------|
+| D1 | D-DB-20 | SQLite for internal operational data (zero-config portability) |
+
+## How to Use
+
+These ADRs are extracted from `CLAUDE.md` Key Architecture Decisions section.
+
+To regenerate all ADR files:
+```bash
+python tools/architecture/adr_extractor.py --extract --json
+```
+
+To list all decisions:
+```bash
+python tools/architecture/adr_extractor.py --list --json
+```
+
+## ADR Format
+
+Each group file contains:
+- **Summary table** — ID, status, and brief description for quick scanning
+- **Individual sections** — Status, Date, Context, Decision, and Consequences for each ADR
+
+## Naming Convention
+
+Decision IDs follow the pattern `D-{PREFIX}-{NUMBER}`:
+- `D{N}` — Core architecture decisions (no prefix)
+- `D-DB-{N}` — Database and storage layer
+- `D-CF-{N}` — Connector Forge and CloudForge
+- `D-INV-{N}` — Innovation features
+- `D-WG-{N}` — WriteGuard writing assistant
+- `D-MKT-{S|C}{N}` — Marketplace (S=SaaS, C=Community)
+- `D-SC-{N}` — Scale Engine
+- `D-HARNESS-{N}` — Harness Engineering
+- `D-SBD-{N}` — Secure by Design
+- `D-ARCH-{N}` — Architecture Patterns (reserved)

docs/adr/connector-forge-decisions.md

@@ -0,0 +1,318 @@
+# CUI // SP-CTI
+# Connector Forge & CloudForge — Architecture Decision Records
+
+**Total decisions:** 22
+**Last updated:** 2026-03-08
+
+| ID | Status | Decision |
+|----|--------|----------|
+| D-CF-1 | Accepted | Connector Forge `forge/` is a subpackage of `tools/databridge/` -- imports from existing ABCs |
+| D-CF-2 | Accepted | Two-tier LLM for code gen (qwen3 drafts connector skeleton, Claude reviews against ABC contract) |
+| D-CF-3 | Accepted | Inline Jinja2 template strings with string-replacement fallback (air-gap safe) |
+| D-CF-4 | Accepted | Docker sandbox primary (--network none, --memory 256m), subprocess fallback |
+| D-CF-5 | Accepted | Two new ConnectorType enum values: SOAP, HEALTH |
+| D-CF-6 | Accepted | Promotion state machine: sandboxed -> promoted -> published -> deprecated |
+| D-CF-7 | Accepted | 8 new audit event types for forge lifecycle |
+| D-CF-8 | Accepted | Marketplace install via ASSET_TYPE_DIRS["databridge_connector"] |
+| D-CF-9 | Accepted | MCP server exposes 8 tools for forge operations |
+| D-CF-10 | Accepted | Config in databridge_config.yaml under forge: block |
+| D-CF-19 | Accepted | Runbooks stored as JSON DAG (tasks_json + edges_json) in SQLite -- air-gap safe |
+| D-CF-20 | Accepted | Runbook executions are append-only with per-task log (NIST AU compliance) |
+| D-CF-21 | Accepted | DAG execution uses Kahn's algorithm (topological sort) -- deterministic O(V+E), no LLM in critical path |
+| D-CF-22 | Accepted | Snippets are self-contained sub-DAGs embedded by reference with usage count tracking |
+| D-CF-23 | Accepted | Metastore uses adjacency list for dependency graph (matches D27 pattern, SQL joins) |
+| D-CF-24 | Accepted | Auto-discovery pulls from db_connections, cf_landing_zones, devices -- idempotent upsert |
+| D-CF-25 | Accepted | Conditional branching uses deterministic expression eval (key-operator-value triples, no eval()) |
+| D-CF-26 | Accepted | AI runbook generation is non-critical-path, always outputs status='draft' |
+| D-CF-27 | Accepted | RTO/RPO stored as hours (REAL) on cf_applications -- simple numeric comparison |
+| D-CF-28 | Accepted | Single unified Ops MCP server with 18 tools (reduces MCP server proliferation) |
+| D-CF-29 | Accepted | YAML runbook templates in args/cloudforge_runbook_templates/ (GOTCHA args layer) |
+| D-CF-30 | Accepted | Community: 3 runbooks, no snippets/AI/discovery; Pro: unlimited |
+
+---
+
+## D-CF-1: Connector Forge as subpackage of tools/databridge/
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** Connector Forge needs to reuse existing DataBridge abstract base classes and connector patterns without duplication.
+**Decision:** Connector Forge `forge/` is a subpackage of `tools/databridge/` -- imports from existing ABCs
+**Consequences:**
+- Forge connectors inherit from the same ABCs as built-in connectors.
+- No code duplication of connector interfaces.
+- Forge directory is self-contained within the DataBridge module.
+
+---
+
+## D-CF-2: Two-tier LLM for code gen
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** Connector code generation needs both speed (drafting) and accuracy (contract validation) at reasonable token cost.
+**Decision:** Two-tier LLM for code gen (qwen3 drafts connector skeleton, Claude reviews against ABC contract)
+**Consequences:**
+- qwen3 handles initial code generation (fast, low cost).
+- Claude reviews for ABC contract compliance (high accuracy).
+- Reduced Claude token consumption (~40% savings).
+
+---
+
+## D-CF-3: Inline Jinja2 template strings with string-replacement fallback
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** The system must operate in air-gapped environments without external dependencies for template rendering.
+**Decision:** Inline Jinja2 template strings with string-replacement fallback (air-gap safe)
+**Consequences:**
+- No external network dependencies required at runtime.
+- Jinja2 used when available, string replacement as fallback.
+- Templates are embedded in source code, not external files.
+
+---
+
+## D-CF-4: Docker sandbox primary, subprocess fallback
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** Generated connector code must be executed in isolation to prevent security risks from untrusted code.
+**Decision:** Docker sandbox primary (--network none, --memory 256m), subprocess fallback
+**Consequences:**
+- Network-isolated Docker container for maximum security.
+- Memory-limited to prevent resource exhaustion.
+- Subprocess fallback when Docker is unavailable.
+
+---
+
+## D-CF-5: Two new ConnectorType enum values
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** The connector type system needed to support SOAP web services and health check endpoints.
+**Decision:** Two new ConnectorType enum values: SOAP, HEALTH
+**Consequences:**
+- SOAP connectors can be properly categorized.
+- Health check connectors have a distinct type.
+- Enum extended without breaking existing connector types.
+
+---
+
+## D-CF-6: Promotion state machine
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** Generated connectors need a clear lifecycle from initial sandbox testing through production deployment and eventual retirement.
+**Decision:** Promotion state machine: sandboxed -> promoted -> published -> deprecated
+**Consequences:**
+- Clear progression path for connector maturity.
+- Each state has distinct permissions and visibility.
+- Deprecated connectors are retained but not recommended.
+
+---
+
+## D-CF-7: 8 new audit event types for forge lifecycle
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** Federal compliance requirements (NIST 800-53 AU controls) mandate audit logging of forge lifecycle events.
+**Decision:** 8 new audit event types for forge lifecycle
+**Consequences:**
+- Historical records cannot be modified or deleted.
+- Complete audit trail of connector generation, validation, promotion, and deprecation.
+- All forge operations are traceable.
+
+---
+
+## D-CF-8: Marketplace install via ASSET_TYPE_DIRS
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** The marketplace and community features require clear operational boundaries for installing forge connectors.
+**Decision:** Marketplace install via ASSET_TYPE_DIRS["databridge_connector"]
+**Consequences:**
+- Connectors installed to a known directory path.
+- Asset type directory mapping is consistent across marketplace.
+- All components must conform to this architectural constraint.
+
+---
+
+## D-CF-9: MCP server exposes 8 tools for forge operations
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** Multi-agent communication requires well-defined protocols for Claude Code to interact with forge capabilities.
+**Decision:** MCP server exposes 8 tools for forge operations
+**Consequences:**
+- Claude Code can invoke forge operations via MCP.
+- Eight distinct tool functions for full forge lifecycle.
+- Consistent with existing MCP server patterns.
+
+---
+
+## D-CF-10: Config in databridge_config.yaml under forge: block
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** Configuration and templates must follow GOTCHA separation of concerns.
+**Decision:** Config in databridge_config.yaml under forge: block
+**Consequences:**
+- Forge configuration colocated with DataBridge config.
+- Follows GOTCHA args layer pattern.
+- Single config file for all DataBridge-related settings.
+
+---
+
+## D-CF-19: Runbooks stored as JSON DAG
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** The system must operate in air-gapped environments. Runbook task graphs need a portable representation.
+**Decision:** Runbooks stored as JSON DAG (tasks_json + edges_json) in SQLite -- air-gap safe
+**Consequences:**
+- No external network dependencies required at runtime.
+- DAG structure enables parallel task execution.
+- SQLite storage provides portability.
+
+---
+
+## D-CF-20: Runbook executions are append-only with per-task log
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** Federal compliance requirements (NIST 800-53 AU controls) mandate immutable execution records.
+**Decision:** Runbook executions are append-only with per-task log (NIST AU compliance)
+**Consequences:**
+- Historical records cannot be modified or deleted.
+- Per-task log enables granular execution audit.
+- Satisfies NIST AU compliance requirements.
+
+---
+
+## D-CF-21: DAG execution uses Kahn's algorithm
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** Probabilistic behavior in business logic leads to unreliable results. Runbook task ordering must be deterministic.
+**Decision:** DAG execution uses Kahn's algorithm (topological sort) -- deterministic O(V+E), no LLM in critical path
+**Consequences:**
+- Results are reproducible across runs.
+- O(V+E) time complexity for task ordering.
+- No LLM involvement in execution critical path.
+
+---
+
+## D-CF-22: Snippets are self-contained sub-DAGs
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** Runbook composition requires reusable building blocks that can be embedded by reference.
+**Decision:** Snippets are self-contained sub-DAGs embedded by reference with usage count tracking
+**Consequences:**
+- Reusable runbook fragments across multiple runbooks.
+- Usage count tracking for impact analysis.
+- Self-contained design prevents cross-snippet dependencies.
+
+---
+
+## D-CF-23: Metastore uses adjacency list for dependency graph
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** Data persistence strategy must support dependency graph traversal. Consistency with existing patterns (D27) is preferred.
+**Decision:** Metastore uses adjacency list for dependency graph (matches D27 pattern, SQL joins)
+**Consequences:**
+- Consistent with supply chain graph pattern (D27).
+- Standard SQL queries for dependency traversal.
+- No additional database technology required.
+
+---
+
+## D-CF-24: Auto-discovery pulls from existing tables
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** Application metastore needs to discover existing infrastructure without manual registration.
+**Decision:** Auto-discovery pulls from db_connections, cf_landing_zones, devices -- idempotent upsert
+**Consequences:**
+- Existing infrastructure is automatically registered.
+- Idempotent upsert prevents duplicate entries.
+- Discovery sources span DataBridge, CloudForge, and Fleet.
+
+---
+
+## D-CF-25: Conditional branching uses deterministic expression eval
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** Probabilistic behavior in business logic leads to unreliable results. Runbook branching must be deterministic and secure.
+**Decision:** Conditional branching uses deterministic expression eval (key-operator-value triples, no eval())
+**Consequences:**
+- Results are reproducible across runs.
+- No `eval()` prevents code injection attacks.
+- Key-operator-value triples provide sufficient expressiveness.
+
+---
+
+## D-CF-26: AI runbook generation is non-critical-path
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** AI-generated runbooks need human review before execution. LLM output must not be directly executable.
+**Decision:** AI runbook generation is non-critical-path, always outputs status='draft'
+**Consequences:**
+- Generated runbooks require human promotion to active status.
+- LLM failures do not block runbook operations.
+- Draft status clearly signals review needed.
+
+---
+
+## D-CF-27: RTO/RPO stored as hours (REAL) on cf_applications
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** Recovery time/point objectives need simple comparison for compliance checking.
+**Decision:** RTO/RPO stored as hours (REAL) on cf_applications -- simple numeric comparison
+**Consequences:**
+- Simple SQL comparison for RTO/RPO threshold checks.
+- Hours provide sufficient granularity for enterprise applications.
+- Stored directly on application record for fast access.
+
+---
+
+## D-CF-28: Single unified Ops MCP server with 18 tools
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** Multi-agent communication requires well-defined protocols. Proliferation of MCP servers increases complexity.
+**Decision:** Single unified Ops MCP server with 18 tools (reduces MCP server proliferation)
+**Consequences:**
+- One MCP server instead of multiple for ops domain.
+- 18 tools cover runbooks, metastore, and cross-domain queries.
+- Reduced configuration and maintenance overhead.
+
+---
+
+## D-CF-29: YAML runbook templates in args/cloudforge_runbook_templates/
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** Configuration and templates must follow GOTCHA separation of concerns.
+**Decision:** YAML runbook templates in args/cloudforge_runbook_templates/ (GOTCHA args layer)
+**Consequences:**
+- Templates live in the GOTCHA args layer.
+- Behavior changes without editing goals or tools.
+- YAML format for human readability.
+
+---
+
+## D-CF-30: Community vs Pro feature split
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** The marketplace and community features require clear operational boundaries between free and paid tiers.
+**Decision:** Community: 3 runbooks, no snippets/AI/discovery; Pro: unlimited
+**Consequences:**
+- Community tier has clear, documented limits.
+- Pro tier removes all limits.
+- Feature gating enforced at runtime.
+
+---

docs/adr/core-decisions.md

@@ -0,0 +1,289 @@
+# CUI // SP-CTI
+# Core Architecture — Architecture Decision Records
+
+**Total decisions:** 20
+**Last updated:** 2026-03-08
+
+| ID | Status | Decision |
+|----|--------|----------|
+| D1 | Superseded | SQLite for internal operational data (zero-config portability) [SUPERSEDED] Superseded by D-DB-20 |
+| D2 | Accepted | Stdio for MCP (Claude Code); HTTPS+mTLS for A2A (K8s inter-agent) |
+| D4 | Accepted | Statistical methods for pattern detection; Bedrock LLM for root cause analysis |
+| D5 | Accepted | CUI markings applied at generation time (inline, not post-processing) |
+| D6 | Accepted | Audit trail is append-only/immutable (no UPDATE/DELETE -- NIST AU compliance) |
+| D7 | Accepted | Python stdlib xml.etree.ElementTree for XMI/ReqIF parsing (zero deps, air-gap safe) |
+| D8 | Accepted | Normalized DB tables for model elements (enables SQL joins across digital thread) |
+| D9 | Accepted | M-ATLAS adds Model pre-phase to ATLAS (backward compatible -- skips if no model) |
+| D12 | Accepted | N:M digital thread links (one block -> many code modules; one control -> many requirements) |
+| D21 | Accepted | Readiness scoring uses deterministic weighted average (reproducible, not probabilistic) |
+| D22 | Accepted | Monte Carlo uses Python stdlib random (zero deps, air-gap safe) |
+| D27 | Accepted | Supply chain graph stored as SQL adjacency list (no graph DB needed) |
+| D52 | Accepted | This is a generated child app -- grandchild app generation is disabled by design |
+| D117 | Accepted | DevSecOps/ZTA Agent with hard veto on pipeline_configuration and zero_trust_policy |
+| D120 | Accepted | ZTA maturity model uses DoD 7-pillar scoring (Traditional -> Advanced -> Optimal) |
+| D215 | Accepted | Prompt injection detector uses 5 detection categories |
+| D216 | Accepted | AI telemetry hashes prompts/responses with SHA-256 (privacy-preserving audit) |
+| D280 | Accepted | Pluggable Tracer ABC: OTelTracer (production), SQLiteTracer (air-gapped), NullTracer (fallback) |
+| D287 | Accepted | PROV-AGENT provenance in 3 append-only SQLite tables (W3C PROV standard) |
+| D331 | Accepted | Code quality metrics are read-only, advisory-only -- never modifies source files |
+
+---
+
+## D1: SQLite for internal operational data
+
+**Status:** Superseded
+**Date:** 2026-03-08
+**Context:** The system needed a lightweight, zero-configuration database for internal operational data storage that works in portable and air-gapped environments.
+**Decision:** ~~SQLite for internal operational data (zero-config portability)~~ Superseded by D-DB-20
+**Consequences:**
+- This decision has been replaced by D-DB-20 (PostgreSQL as primary backend).
+- SQLite is retained as a lightweight fallback for portable/browser scenarios.
+
+---
+
+## D2: Stdio for MCP; HTTPS+mTLS for A2A
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** Multi-agent communication requires well-defined protocols and boundaries between Claude Code MCP servers and inter-agent Kubernetes communication.
+**Decision:** Stdio for MCP (Claude Code); HTTPS+mTLS for A2A (K8s inter-agent)
+**Consequences:**
+- MCP servers use stdio transport for Claude Code integration.
+- Agent-to-agent communication uses HTTPS with mutual TLS within Kubernetes.
+- Clear separation between local tool invocation and network-based agent communication.
+
+---
+
+## D4: Statistical methods for pattern detection
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** Pattern detection in monitoring and self-healing must balance accuracy with cost and latency.
+**Decision:** Statistical methods for pattern detection; Bedrock LLM for root cause analysis
+**Consequences:**
+- Pattern detection runs locally without LLM token costs.
+- Root cause analysis leverages LLM reasoning capabilities when needed.
+- Two-tier approach optimizes cost vs. intelligence tradeoff.
+
+---
+
+## D5: CUI markings applied at generation time
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** Federal compliance requirements (NIST 800-53) mandate CUI markings on all generated artifacts at the appropriate impact level.
+**Decision:** CUI markings applied at generation time (inline, not post-processing)
+**Consequences:**
+- All generated artifacts include classification markings from creation.
+- No post-processing step required to add markings.
+- Reduces risk of unmarked artifacts escaping the system.
+
+---
+
+## D6: Audit trail is append-only/immutable
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** Federal compliance requirements (NIST 800-53 AU controls) mandate immutable audit records that cannot be tampered with.
+**Decision:** Audit trail is append-only/immutable (no UPDATE/DELETE -- NIST AU compliance)
+**Consequences:**
+- Historical records cannot be modified or deleted.
+- All audit tables use INSERT only.
+- Satisfies NIST 800-53 AU control family requirements.
+
+---
+
+## D7: Python stdlib xml.etree.ElementTree for XMI/ReqIF parsing
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** The system must operate in air-gapped environments without external dependencies for MBSE model parsing.
+**Decision:** Python stdlib xml.etree.ElementTree for XMI/ReqIF parsing (zero deps, air-gap safe)
+**Consequences:**
+- No external network dependencies required at runtime.
+- Works in air-gapped environments.
+- Limited to stdlib XML capabilities (no lxml advanced features).
+
+---
+
+## D8: Normalized DB tables for model elements
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** Data persistence strategy must support cross-domain queries across the digital thread (models, requirements, code, compliance).
+**Decision:** Normalized DB tables for model elements (enables SQL joins across digital thread)
+**Consequences:**
+- SQL joins enable cross-domain traceability queries.
+- Standard relational patterns for model element storage.
+- All components must conform to this architectural constraint.
+
+---
+
+## D9: M-ATLAS adds Model pre-phase to ATLAS
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** MBSE model import needed integration with the existing ATLAS build workflow without breaking backward compatibility.
+**Decision:** M-ATLAS adds Model pre-phase to ATLAS (backward compatible -- skips if no model)
+**Consequences:**
+- Existing ATLAS workflows continue to work unchanged.
+- Model import is optional and triggered only when SysML/ReqIF files are present.
+- Backward compatible with all existing projects.
+
+---
+
+## D12: N:M digital thread links
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** Traceability between system artifacts requires many-to-many relationships (one block maps to multiple code modules, one control maps to multiple requirements).
+**Decision:** N:M digital thread links (one block -> many code modules; one control -> many requirements)
+**Consequences:**
+- Full many-to-many traceability across artifact types.
+- More complex queries but more accurate coverage reporting.
+- All components must conform to this architectural constraint.
+
+---
+
+## D21: Readiness scoring uses deterministic weighted average
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** Probabilistic behavior in business logic leads to unreliable results across runs. Readiness scores must be reproducible.
+**Decision:** Readiness scoring uses deterministic weighted average (reproducible, not probabilistic)
+**Consequences:**
+- Results are reproducible across runs.
+- Same inputs always produce same readiness score.
+- No LLM involvement in scoring calculation.
+
+---
+
+## D22: Monte Carlo uses Python stdlib random
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** The system must operate in air-gapped environments without external dependencies for simulation capabilities.
+**Decision:** Monte Carlo uses Python stdlib random (zero deps, air-gap safe)
+**Consequences:**
+- No external network dependencies required at runtime.
+- Works in air-gapped environments without numpy/scipy.
+- Seeded runs are reproducible.
+
+---
+
+## D27: Supply chain graph stored as SQL adjacency list
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** Data persistence strategy must support dependency graph traversal without requiring a dedicated graph database.
+**Decision:** Supply chain graph stored as SQL adjacency list (no graph DB needed)
+**Consequences:**
+- No additional database technology required.
+- Standard SQL queries for graph traversal.
+- Pattern reused by metastore (D-CF-23).
+
+---
+
+## D52: Generated child app — grandchild generation disabled
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** This application is a generated child app of ICDEV. Allowing it to generate further child apps would create uncontrolled proliferation.
+**Decision:** This is a generated child app -- grandchild app generation is disabled by design
+**Consequences:**
+- Agentic fitness assessor, app blueprint engine, and child app generator are excluded.
+- Prevents recursive app generation chains.
+- All components must conform to this architectural constraint.
+
+---
+
+## D117: DevSecOps/ZTA Agent with hard veto
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** Security posture must be maintained across all system boundaries. Pipeline configuration and zero trust policy changes are high-risk operations.
+**Decision:** DevSecOps/ZTA Agent with hard veto on pipeline_configuration and zero_trust_policy
+**Consequences:**
+- DevSecOps/ZTA agent can block pipeline and policy changes.
+- Hard veto cannot be overridden by other agents.
+- Ensures security review for all infrastructure changes.
+
+---
+
+## D120: ZTA maturity model uses DoD 7-pillar scoring
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** Zero Trust Architecture maturity must be assessed using the DoD ZTA Strategy framework across all seven pillars.
+**Decision:** ZTA maturity model uses DoD 7-pillar scoring (Traditional -> Advanced -> Optimal)
+**Consequences:**
+- Three maturity levels per pillar: Traditional, Advanced, Optimal.
+- IL4+ systems must achieve Advanced or higher.
+- Aligned with DoD Zero Trust Strategy.
+
+---
+
+## D215: Prompt injection detector uses 5 detection categories
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** Security posture must be maintained across all system boundaries. AI prompt injection is a critical attack vector.
+**Decision:** Prompt injection detector uses 5 detection categories
+**Consequences:**
+- Five distinct detection categories for comprehensive coverage.
+- Gate-mode blocks deployment when injection defense is inactive.
+- All components must conform to this architectural constraint.
+
+---
+
+## D216: AI telemetry hashes prompts/responses with SHA-256
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** AI telemetry must be auditable while preserving privacy of prompt and response content.
+**Decision:** AI telemetry hashes prompts/responses with SHA-256 (privacy-preserving audit)
+**Consequences:**
+- Prompt and response content is never stored in plain text in telemetry.
+- SHA-256 hashes enable tamper detection and deduplication.
+- Satisfies privacy requirements while maintaining audit capability.
+
+---
+
+## D280: Pluggable Tracer ABC
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** Observability must work in both connected (production) and air-gapped environments with a consistent interface.
+**Decision:** Pluggable Tracer ABC: OTelTracer (production), SQLiteTracer (air-gapped), NullTracer (fallback)
+**Consequences:**
+- Three tracer implementations behind a common abstract base class.
+- Environment-appropriate tracing without code changes.
+- NullTracer ensures graceful degradation when no tracing backend is available.
+
+---
+
+## D287: PROV-AGENT provenance in 3 append-only SQLite tables
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** Federal compliance requirements (NIST 800-53) mandate provenance tracking. W3C PROV standard provides interoperability.
+**Decision:** PROV-AGENT provenance in 3 append-only SQLite tables (W3C PROV standard)
+**Consequences:**
+- Historical records cannot be modified or deleted.
+- W3C PROV standard enables interoperability with external provenance systems.
+- Three tables: entities, activities, derivations.
+
+---
+
+## D331: Code quality metrics are read-only, advisory-only
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** Code intelligence tools must never modify source files to prevent unintended side effects during analysis.
+**Decision:** Code quality metrics are read-only, advisory-only -- never modifies source files
+**Consequences:**
+- Analysis tools only read source files, never write to them.
+- Metrics are advisory and do not enforce changes.
+- Safe to run in any environment without risk of code modification.
+
+---