icdev 0.0.3__py3-none-any.whl

docs/adr/db-decisions.md

@@ -0,0 +1,94 @@
+# CUI // SP-CTI
+# Database & Storage — Architecture Decision Records
+
+**Total decisions:** 6
+**Last updated:** 2026-03-08
+
+| ID | Status | Decision |
+|----|--------|----------|
+| D-DB-20 | Accepted | PostgreSQL is the primary backend; SQLite retained as lightweight fallback for portable/browser scenarios |
+| D-DB-21 | Accepted | Storage abstraction layer in `tools/db/storage.py` -- all tools use `get_connection()` (backend-agnostic) |
+| D-DB-22 | Accepted | `args/storage_config.yaml` controls backend selection; env vars override YAML (ICDEV_STORAGE_BACKEND, ICDEV_PG_*) |
+| D-DB-23 | Accepted | Placeholder translation (? -> %s) handled transparently by StorageConnection wrapper |
+| D-DB-24 | Accepted | Supabase for marketplace-saas (PostgreSQL + Auth + RLS + Realtime) |
+| D-DB-25 | Accepted | Alembic for PostgreSQL schema versioning (replaces table-recreation pattern) |
+
+---
+
+## D-DB-20: PostgreSQL is the primary backend
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** Data persistence strategy must balance portability, performance, and compliance. SQLite (D1) was insufficient for production multi-user scenarios.
+**Decision:** PostgreSQL is the primary backend; SQLite retained as lightweight fallback for portable/browser scenarios
+**Consequences:**
+- PostgreSQL provides ACID compliance, concurrent access, and production-grade performance.
+- SQLite remains available for development, testing, and air-gapped portable deployments.
+- Supersedes D1 (SQLite-only approach).
+
+---
+
+## D-DB-21: Storage abstraction layer in `tools/db/storage.py`
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** All tools must work with both PostgreSQL and SQLite backends without code changes.
+**Decision:** Storage abstraction layer in `tools/db/storage.py` -- all tools use `get_connection()` (backend-agnostic)
+**Consequences:**
+- All tools use a single `get_connection()` entry point.
+- Backend switching requires only configuration changes, not code changes.
+- All components must conform to this architectural constraint.
+
+---
+
+## D-DB-22: `args/storage_config.yaml` controls backend selection
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** Configuration and templates must follow GOTCHA separation of concerns. Backend selection must be overridable per environment.
+**Decision:** `args/storage_config.yaml` controls backend selection; env vars override YAML (ICDEV_STORAGE_BACKEND, ICDEV_PG_*)
+**Consequences:**
+- YAML config provides default backend selection.
+- Environment variables override YAML for deployment flexibility.
+- Follows GOTCHA args layer pattern.
+
+---
+
+## D-DB-23: Placeholder translation (? -> %s) handled transparently
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** SQLite uses `?` placeholders while PostgreSQL uses `%s`. Tools should not need to know which backend is active.
+**Decision:** Placeholder translation (? -> %s) handled transparently by StorageConnection wrapper
+**Consequences:**
+- All tools write SQL with `?` placeholders (SQLite syntax).
+- StorageConnection automatically translates to `%s` when PostgreSQL is active.
+- No backend-specific SQL in tool code.
+
+---
+
+## D-DB-24: Supabase for marketplace-saas
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** The marketplace SaaS requires PostgreSQL with authentication, row-level security, and realtime capabilities.
+**Decision:** Supabase for marketplace-saas (PostgreSQL + Auth + RLS + Realtime)
+**Consequences:**
+- Marketplace uses Supabase-hosted PostgreSQL.
+- Row-level security enforces tenant isolation.
+- Realtime subscriptions enable live marketplace updates.
+
+---
+
+## D-DB-25: Alembic for PostgreSQL schema versioning
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** The table-recreation pattern used with SQLite does not work for PostgreSQL with existing data. A proper migration framework is needed.
+**Decision:** Alembic for PostgreSQL schema versioning (replaces table-recreation pattern)
+**Consequences:**
+- Schema changes are versioned and reversible.
+- Migration history provides audit trail of schema evolution.
+- Replaces the SQLite-era table-recreation pattern.
+
+---

docs/adr/harness-decisions.md

@@ -0,0 +1,122 @@
+# CUI // SP-CTI
+# Harness Engineering — Architecture Decision Records
+
+**Total decisions:** 8
+**Last updated:** 2026-03-08
+
+| ID | Status | Decision |
+|----|--------|----------|
+| D-HARNESS-1 | Accepted | Loop state in `.tmp/sessions/` JSON (ephemeral, not DB) |
+| D-HARNESS-2 | Accepted | Loop detection is soft-signal only (stderr, exit 0) -- never blocks |
+| D-HARNESS-3 | Accepted | Progress file is JSON (models handle structured data better) |
+| D-HARNESS-4 | Accepted | Exit criteria in args/ YAML (GOTCHA separation) |
+| D-HARNESS-5 | Accepted | Trace analyzer scanner-tier only (zero Claude tokens) |
+| D-HARNESS-6 | Accepted | Maturity assessor read-only, advisory-only |
+| D-HARNESS-7 | Accepted | Scaffolder generates 3 hooks (minimal), not all 7 |
+| D-HARNESS-8 | Accepted | One new append-only DB table: `harness_trace_recommendations` |
+
+---
+
+## D-HARNESS-1: Loop state in `.tmp/sessions/` JSON
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** Loop detection state is ephemeral and session-scoped. Persisting it in the database adds unnecessary complexity.
+**Decision:** Loop state in `.tmp/sessions/` JSON (ephemeral, not DB)
+**Consequences:**
+- Session state is disposable and does not pollute the database.
+- JSON format is human-readable for debugging.
+- State is lost on session end (by design).
+
+---
+
+## D-HARNESS-2: Loop detection is soft-signal only
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** Loop detection should inform but never block agent operations to prevent false positives from halting work.
+**Decision:** Loop detection is soft-signal only (stderr, exit 0) -- never blocks
+**Consequences:**
+- Warnings emitted to stderr for visibility.
+- Exit code 0 ensures downstream processes are not blocked.
+- Human judgment required for loop resolution.
+
+---
+
+## D-HARNESS-3: Progress file is JSON
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** AI models handle structured data better than free-form text. Progress tracking must be machine-readable.
+**Decision:** Progress file is JSON (models handle structured data better)
+**Consequences:**
+- JSON format enables programmatic progress tracking.
+- AI models can parse and reason about progress state.
+- Human-readable with standard JSON formatting.
+
+---
+
+## D-HARNESS-4: Exit criteria in args/ YAML
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** Configuration and templates must follow GOTCHA separation of concerns. Exit criteria must be adjustable without code changes.
+**Decision:** Exit criteria in args/ YAML (GOTCHA separation)
+**Consequences:**
+- Exit criteria defined in YAML configuration.
+- Behavior changes without editing goals or tools.
+- Follows GOTCHA args layer pattern.
+
+---
+
+## D-HARNESS-5: Trace analyzer scanner-tier only
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** Trace analysis must be cost-effective and available in air-gapped environments without Claude tokens.
+**Decision:** Trace analyzer scanner-tier only (zero Claude tokens)
+**Consequences:**
+- No Claude token consumption for trace analysis.
+- Uses local models or deterministic analysis only.
+- Available in air-gapped environments.
+
+---
+
+## D-HARNESS-6: Maturity assessor read-only, advisory-only
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** Maturity assessment must never modify the system it is assessing to prevent measurement from affecting results.
+**Decision:** Maturity assessor read-only, advisory-only
+**Consequences:**
+- Assessment tools only read system state, never modify it.
+- Results are advisory and do not enforce changes.
+- Safe to run in production without risk.
+
+---
+
+## D-HARNESS-7: Scaffolder generates 3 hooks (minimal)
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** Scaffolded harness should be minimal and not overwhelm new projects with unnecessary complexity.
+**Decision:** Scaffolder generates 3 hooks (minimal), not all 7
+**Consequences:**
+- Three essential hooks provided out of the box.
+- Additional hooks can be added as needed.
+- Lower barrier to adoption for new projects.
+
+---
+
+## D-HARNESS-8: One new append-only DB table
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** Federal compliance requirements (NIST 800-53 AU controls) mandate immutable storage for trace recommendations.
+**Decision:** One new append-only DB table: `harness_trace_recommendations`
+**Consequences:**
+- Historical records cannot be modified or deleted.
+- Single table for all trace-derived recommendations.
+- Satisfies NIST AU compliance requirements.
+
+---

docs/adr/innovation-decisions.md

@@ -0,0 +1,262 @@
+# CUI // SP-CTI
+# Innovation Features — Architecture Decision Records
+
+**Total decisions:** 18
+**Last updated:** 2026-03-08
+
+| ID | Status | Decision |
+|----|--------|----------|
+| D-INV-1 | Accepted | cATO OSCAL streaming uses incremental assessment-results (per-control, not bulk) |
+| D-INV-2 | Accepted | Evidence freshness thresholds: current <= 30d, stale <= 90d, expired > 90d |
+| D-INV-5 | Accepted | Template provenance via SHA-256 content hash (tamper detection) |
+| D-INV-9 | Accepted | DORA metrics computed from audit_trail stage timestamps (no external CI integration needed) |
+| D-INV-10 | Accepted | Bottleneck detection via p90 statistical analysis (no ML) |
+| D-INV-13 | Accepted | Two-tier LLM for narrative generation: qwen3 drafts, Claude reviews |
+| D-INV-14 | Accepted | Narrative approval workflow: draft -> pending_review -> approved/rejected |
+| D-INV-17 | Accepted | Heatmap matrix uses N x M artifact-type cross-reference (not individual artifacts) |
+| D-INV-21 | Accepted | PR diff analysis via subprocess git (no GitHub API dependency) |
+| D-INV-25 | Accepted | STRIDE threat analysis is deterministic rule-based per component type (no LLM) |
+| D-INV-26 | Accepted | STRIDE-to-NIST mapping: Spoofing->AC/IA, Tampering->SC/SI, Repudiation->AU, InfoDisc->SC, DoS->SC/CP, EoP->AC |
+| D-INV-29 | Accepted | Scorecard weighted composite (6 dimensions): code_quality=0.20, security=0.20, compliance=0.15, ... |
+| D-INV-33 | Accepted | Golden Path uses declarative YAML template definitions (5 built-in templates) |
+| D-INV-37 | Accepted | Forge Hub trust score: validation=0.30, rating=0.25, downloads=0.20, age=0.15, author=0.10 |
+| D-INV-41 | Accepted | ATO simulator uses PERT sampling via stdlib random.betavariate (zero deps) |
+| D-INV-45 | Accepted | Firmware SBOM output format: CycloneDX 1.5 JSON |
+| D-INV-46 | Accepted | VEX output format: CSAF 2.0 with per-component exploitability status |
+| D-INV-48 | Accepted | All innovation features use icdev.db (NOT sparkpilot.db -- that's for IoT/embedded only) |
+
+---
+
+## D-INV-1: cATO OSCAL streaming uses incremental assessment-results
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** Continuous ATO requires real-time evidence streaming without overwhelming the system with bulk assessments.
+**Decision:** cATO OSCAL streaming uses incremental assessment-results (per-control, not bulk)
+**Consequences:**
+- Individual control assessments streamed as they complete.
+- Reduces latency for evidence freshness monitoring.
+- OSCAL format ensures interoperability with GRC tools.
+
+---
+
+## D-INV-2: Evidence freshness thresholds
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** Federal compliance requirements mandate evidence currency. Stale evidence must be flagged and expired evidence must block authorization.
+**Decision:** Evidence freshness thresholds: current <= 30d, stale <= 90d, expired > 90d
+**Consequences:**
+- Three-tier freshness classification: current, stale, expired.
+- Automated alerts when evidence transitions to stale.
+- Expired evidence blocks cATO continuation.
+
+---
+
+## D-INV-5: Template provenance via SHA-256 content hash
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** Security posture must be maintained. Compliance templates must be tamper-evident.
+**Decision:** Template provenance via SHA-256 content hash (tamper detection)
+**Consequences:**
+- Content hash computed on template creation and verified on use.
+- Tampered templates are detected and rejected.
+- Hash stored alongside template metadata.
+
+---
+
+## D-INV-9: DORA metrics computed from audit_trail stage timestamps
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** DORA metrics (deployment frequency, lead time, MTTR, change failure rate) must be computed without external CI/CD integration.
+**Decision:** DORA metrics computed from audit_trail stage timestamps (no external CI integration needed)
+**Consequences:**
+- Metrics derived from existing audit trail data.
+- No external CI/CD system integration required.
+- Works in air-gapped environments.
+
+---
+
+## D-INV-10: Bottleneck detection via p90 statistical analysis
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** Pipeline bottleneck detection must be deterministic and reproducible without ML model dependencies.
+**Decision:** Bottleneck detection via p90 statistical analysis (no ML)
+**Consequences:**
+- Results are reproducible across runs.
+- P90 percentile analysis identifies outlier stages.
+- No ML model training or inference required.
+
+---
+
+## D-INV-13: Two-tier LLM for narrative generation
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** Compliance narrative generation needs both speed (drafting) and quality (review) at reasonable token cost.
+**Decision:** Two-tier LLM for narrative generation: qwen3 drafts, Claude reviews
+**Consequences:**
+- qwen3 handles initial narrative drafting (fast, low cost).
+- Claude reviews for accuracy and compliance language.
+- Consistent with two-tier LLM pattern (D-CF-2).
+
+---
+
+## D-INV-14: Narrative approval workflow
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** AI-generated compliance narratives require human review and approval before inclusion in ATO packages.
+**Decision:** Narrative approval workflow: draft -> pending_review -> approved/rejected
+**Consequences:**
+- Three-state workflow with clear transitions.
+- Human review required before approval.
+- Rejected narratives can be revised and resubmitted.
+
+---
+
+## D-INV-17: Heatmap matrix uses N x M artifact-type cross-reference
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** Digital thread coverage visualization must show gaps at the artifact-type level, not individual artifact level, to remain useful at scale.
+**Decision:** Heatmap matrix uses N x M artifact-type cross-reference (not individual artifacts)
+**Consequences:**
+- Coverage gaps visible at category level.
+- Scalable visualization regardless of artifact count.
+- N artifact types x M artifact types matrix.
+
+---
+
+## D-INV-21: PR diff analysis via subprocess git
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** PR intelligence must work without GitHub API access for air-gapped and self-hosted environments.
+**Decision:** PR diff analysis via subprocess git (no GitHub API dependency)
+**Consequences:**
+- No external network dependencies required at runtime.
+- Works with any git hosting platform.
+- Subprocess git available in all environments.
+
+---
+
+## D-INV-25: STRIDE threat analysis is deterministic rule-based
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** Probabilistic behavior in threat modeling leads to inconsistent results. STRIDE analysis must be reproducible.
+**Decision:** STRIDE threat analysis is deterministic rule-based per component type (no LLM)
+**Consequences:**
+- Results are reproducible across runs.
+- Component type determines applicable threats.
+- No LLM token cost for threat analysis.
+
+---
+
+## D-INV-26: STRIDE-to-NIST mapping
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** STRIDE threats must map to NIST 800-53 controls for compliance integration.
+**Decision:** STRIDE-to-NIST mapping: Spoofing->AC/IA, Tampering->SC/SI, Repudiation->AU, InfoDisc->SC, DoS->SC/CP, EoP->AC
+**Consequences:**
+- Automatic control mapping from threat identification.
+- Six STRIDE categories map to specific NIST control families.
+- Enables auto-generation of POAM items from threats.
+
+---
+
+## D-INV-29: Scorecard weighted composite (6 dimensions)
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** Developer scorecard must provide a single health score from multiple quality dimensions with configurable weights.
+**Decision:** Scorecard weighted composite (6 dimensions): code_quality=0.20, security=0.20, compliance=0.15, test_coverage=0.15, velocity=0.10, sbd_posture=0.20
+**Consequences:**
+- Single composite score from six dimensions.
+- Weights are configurable but must sum to 1.0.
+- SbD posture weight (0.20) reflects security-first priorities.
+
+---
+
+## D-INV-33: Golden Path uses declarative YAML template definitions
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** Configuration and templates must follow GOTCHA separation of concerns. Project scaffolding must be extensible.
+**Decision:** Golden Path uses declarative YAML template definitions (5 built-in templates)
+**Consequences:**
+- Templates defined in YAML, not code.
+- 5 built-in templates cover common project types.
+- New templates added without code changes.
+
+---
+
+## D-INV-37: Forge Hub trust score
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** The marketplace and community features require trust scoring for community-contributed connectors.
+**Decision:** Forge Hub trust score: validation=0.30, rating=0.25, downloads=0.20, age=0.15, author=0.10
+**Consequences:**
+- Five-factor weighted trust score.
+- Validation weight (0.30) prioritizes technical correctness.
+- Trust score visible to users during connector selection.
+
+---
+
+## D-INV-41: ATO simulator uses PERT sampling
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** The system must operate in air-gapped environments without external dependencies for Monte Carlo simulation.
+**Decision:** ATO simulator uses PERT sampling via stdlib random.betavariate (zero deps)
+**Consequences:**
+- No external network dependencies required at runtime.
+- PERT distribution via betavariate provides realistic timeline estimates.
+- Works in air-gapped environments without numpy/scipy.
+
+---
+
+## D-INV-45: Firmware SBOM output format: CycloneDX 1.5 JSON
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** Firmware SBOM must use a widely adopted standard format for interoperability with vulnerability management tools.
+**Decision:** Firmware SBOM output format: CycloneDX 1.5 JSON
+**Consequences:**
+- CycloneDX 1.5 provides firmware-specific component types.
+- JSON format enables programmatic consumption.
+- Compatible with OWASP Dependency-Track and similar tools.
+
+---
+
+## D-INV-46: VEX output format: CSAF 2.0
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** Vulnerability exploitability exchange documents must use a standard format for automated triage.
+**Decision:** VEX output format: CSAF 2.0 with per-component exploitability status
+**Consequences:**
+- CSAF 2.0 provides structured vulnerability advisories.
+- Per-component exploitability status enables targeted remediation.
+- Compatible with CISA VEX requirements.
+
+---
+
+## D-INV-48: All innovation features use icdev.db
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** Data persistence strategy must separate operational data (icdev.db) from IoT/embedded data (sparkpilot.db).
+**Decision:** All innovation features use icdev.db (NOT sparkpilot.db -- that's for IoT/embedded only)
+**Consequences:**
+- Clear database boundary between ICDEV platform and SparkPilot embedded.
+- Innovation features never touch sparkpilot.db.
+- All components must conform to this architectural constraint.
+
+---

docs/adr/marketplace-decisions.md

@@ -0,0 +1,109 @@
+# CUI // SP-CTI
+# Marketplace — Architecture Decision Records
+
+**Total decisions:** 7
+**Last updated:** 2026-03-08
+
+| ID | Status | Decision |
+|----|--------|----------|
+| D-MKT-S1 | Accepted | Marketplace extracted to standalone SaaS (marketplace.icdev.ai) -- ICDEV uses thin client (4 files, ~400 LOC) |
+| D-MKT-S2 | Accepted | Two modes: oss (all unlocked, default), saas (token verification) |
+| D-MKT-S3 | Accepted | Token verification is 100% offline via RSA-SHA256 public key -- 30-day grace period for air-gap |
+| D-MKT-S4 | Accepted | Thin client: module_runtime.py (gating), license_client.py (sync/verify/renew/feedback), token_store.py (local JSON cache) |
+| D-MKT-C1 | Accepted | Community-first model: 90-day free activation, unlimited renewals, no SLA |
+| D-MKT-C2 | Accepted | Sponsor tiers (platinum/gold/silver/bronze) are recognition badges only -- no feature gating, donations handled externally |
+| D-MKT-C3 | Accepted | Renewal = feedback touchpoint: optional survey on each renewal for continuous improvement |
+
+---
+
+## D-MKT-S1: Marketplace extracted to standalone SaaS
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** The marketplace needed to operate independently from ICDEV core to scale and serve multiple tenants.
+**Decision:** Marketplace extracted to standalone SaaS (marketplace.icdev.ai) -- ICDEV uses thin client (4 files, ~400 LOC)
+**Consequences:**
+- Marketplace operates as independent service.
+- ICDEV uses thin client (4 files, ~400 LOC) for integration.
+- Independent scaling and deployment.
+
+---
+
+## D-MKT-S2: Two modes: oss and saas
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** The marketplace and community features require clear operational boundaries between open-source and commercial modes.
+**Decision:** Two modes: oss (all unlocked, default), saas (token verification)
+**Consequences:**
+- OSS mode has all features unlocked (default).
+- SaaS mode requires token verification for premium features.
+- Mode selection via configuration.
+
+---
+
+## D-MKT-S3: Token verification is 100% offline via RSA-SHA256 public key
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** The system must operate in air-gapped environments. License verification cannot depend on network connectivity.
+**Decision:** Token verification is 100% offline via RSA-SHA256 public key -- 30-day grace period for air-gap
+**Consequences:**
+- No external network dependencies required for license verification.
+- RSA-SHA256 public key embedded in client.
+- 30-day grace period allows operation during network outages.
+
+---
+
+## D-MKT-S4: Thin client architecture
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** ICDEV's marketplace integration must be minimal to avoid tight coupling with the SaaS platform.
+**Decision:** Thin client: module_runtime.py (gating), license_client.py (sync/verify/renew/feedback), token_store.py (local JSON cache)
+**Consequences:**
+- Four files total for marketplace integration (~400 LOC).
+- module_runtime.py handles feature gating.
+- license_client.py manages token lifecycle.
+- token_store.py provides local caching.
+
+---
+
+## D-MKT-C1: Community-first model
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** The marketplace and community features must lower barriers to adoption and encourage community growth.
+**Decision:** Community-first model: 90-day free activation, unlimited renewals, no SLA
+**Consequences:**
+- 90-day free activation period for all users.
+- Unlimited renewals maintain free access.
+- No SLA commitment for community tier.
+
+---
+
+## D-MKT-C2: Sponsor tiers are recognition badges only
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** Sponsorship must not create feature inequality. Recognition-only model preserves community equity.
+**Decision:** Sponsor tiers (platinum/gold/silver/bronze) are recognition badges only -- no feature gating, donations handled externally
+**Consequences:**
+- All features available regardless of sponsor status.
+- Sponsor badges provide visibility and recognition.
+- Donations handled through external platforms.
+
+---
+
+## D-MKT-C3: Renewal = feedback touchpoint
+
+**Status:** Accepted
+**Date:** 2026-03-08
+**Context:** License renewal provides a natural touchpoint for gathering user feedback without being intrusive.
+**Decision:** Renewal = feedback touchpoint: optional survey on each renewal for continuous improvement
+**Consequences:**
+- Optional survey presented during renewal.
+- Feedback data drives product improvement.
+- Non-blocking: survey is skippable.
+
+---