acdl/.ciagent/IDEATE.md

IDEATE — v1.25 kyverno-json Unified Policy Engine

Autonomy: full. 3-tier ideation per config.json ideation.enabled: true. cross_project.enabled: false → cross-project tier scoped to single-project (deferred ideas only, no cross-project candidates accepted). confidence_threshold: 0.6, max_ideas: 20. Categories: security, quality, architecture, coverage, improvement.

Tier 1 — Mechanical (pattern-driven, codebase-grounded)

I1 — Regression-gate-as-policy ✅ ACCEPTED (REQ-304, REQ-305)

Category: quality, coverage Confidence: 0.90 Pattern: imperative check → declarative policy (the milestone's core thesis applied to Nova's own regression gate). Source: core/regression_verify.py (CAP-013, CAP-023, CAP-024) are imperative Python checks. The milestone makes compliance declarative; Nova's own capability regression should follow. Idea: Port the three capability checks into adapters/kyverno-json/policies/regression/ as declarative policies over the capability-inventory JSON frontmatter. The imperative regression_verify.py stays (it drives the CI gate); the policies are the declarative mirror that makes capability regression auditable as a policy artifact. Accepted into: REQ-304 (policies), REQ-305 (tests). Phase P4.

I2 — Contract-shape validation as policy ✅ ACCEPTED (REQ-295)

Category: security, architecture Confidence: 0.92 Pattern: jsonschema constraint → declarative policy (same constraint, different language, Nova posture on top). Source: schemas/contract.schema.json required/pattern/enum. Idea: The 4 contract policies (require-id-pattern, require-env-in-enum, require-infrastructure-min-1, forbid-unknown- fields) are the declarative equivalent of the jsonschema constraints — they let Nova apply its own compliance posture (e.g. forbid a specific env for a specific consumer) on top of schema validity without editing the jsonschema. Accepted into: REQ-295. Phase P2.

I3 — Stack-IR imperative rules → declarative policies ✅ ACCEPTED (REQ-297)

Category: security, architecture Confidence: 0.88 Pattern: imperative Python rule → declarative kyverno-json policy. Source: adapters/terraform/policy/custom_rules/nova_tagging.py (tagging), the v1.0 demo public-ingress: true rule, the v1.8 D-encryption-default rule. Idea: Port the three highest-impact imperative rules into declarative kyverno-json policies over the resolved Stack IR. The tagging rule is a cross-check (D-118 — both engines, agree meta-policy); public-ingress and encryption-by-default are kyverno-json only (the IR is the earliest point these can be caught). Accepted into: REQ-297. Phase P2.

Tier 2 — Backend-enriched (signal-driven)

I4 — Plan-JSON Checkov RULE_MAP → kyverno-json mirrors ✅ ACCEPTED (REQ-300)

Category: security, coverage Confidence: 0.85 Pattern: existing engine rule → declarative mirror in the new engine (defense-in-depth against engine drift). Source: checkov_adapter.py:RULE_MAP (CKV_AWS_41/45/46, CKV_AWS_1/40, CKV_AWS_7/33). Idea: Port the 6 Checkov rules over terraform_plan into declarative kyverno-json policies over terraform show -json output. The Checkov rules stay the source of truth for HCL scanning; the kyverno-json policies are mirrors (different rule language, same plan JSON). Defense- in-depth: if Checkov and kyverno-json disagree on the same plan, the divergence is visible (two PCRs with different results for the same resource). Accepted into: REQ-300. Phase P3.

I5 — Meta-policy over the merged PCR list ✅ ACCEPTED (REQ-303)

Category: architecture, quality Confidence: 0.90 Pattern: the policy result list is itself a policy target (the most novel use of kyverno-json in v1.25). Source: core/confidence_signal.py PENALTY hardcode (critical override), the D-118 tagging cross-check. Idea: block-on-any-critical (declarative "critical = block") + tagging-rules-agree (Checkov vs kj agree). The meta-policies consume the merged PCR list as their payload. The critical-block meta-policy is the declarative source of truth; the confidence_signal.py hard-override stays as defense-in-depth (D-119). Accepted into: REQ-303. Phase P3.

I6 — Env-transition destroy as a declarative policy ❌ DEFERRED

Category: improvement Confidence: 0.55 (below threshold — deferred, not rejected) Pattern: imperative lifecycle Python → declarative policy. Source: core/env_transition.py (v1.24 detect-and-destroy). Idea: The v1.24 env-transition destroy logic (detect env change via DynamoDB, destroy prior env, fail-closed) is imperative Python. A declarative kyverno-json policy could assert "if environment changed on a stable contract.id, a destroy event MUST precede the apply" — turning the lifecycle enforcement into an auditable policy artifact. Reason deferred: The env-transition logic is stateful (DynamoDB queries, terraform state inspection) — kyverno-json policies are stateless (payload in, PCRs out). A policy can assert the contract shape (the env value is valid) but not the lifecycle (the prior env was destroyed). The stateful check stays in core/env_transition.py; a future milestone could emit a nova.env.destroyed event that a kyverno-json policy then asserts is present in the evidence stream (event-as-policy). Recorded as a future-idea, not a v1.25 requirement.

I7 — Drift detection as policy ❌ DEFERRED

Category: security, coverage Confidence: 0.40 (below threshold — deferred) Pattern: scheduled job → policy over the drift report. Source: NORTH_STAR.md Non-Goal #4 (drift detection scheduled job, deferred — D-096 + no scheduler). Idea: A kyverno-json policy over a terraform drift report could assert "no drifted resources" declaratively. But drift detection itself requires a scheduled terraform plan -detailed-exitcode job, which is deferred (no scheduler). The policy is the easy part; the emitter is the blocking dependency. Reason deferred: Blocked by D-096 + no scheduler (same as NORTH_STAR Non-Goal #4). The policy shape is documented for when the emitter ships.

Tier 3 — Cross-project (deferred — single project)

I8 — Cross-project policy sharing ❌ DEFERRED (config)

Category: improvement Confidence: N/A Pattern: policies shared across projects in a multi-project org. Source: config.json ideation.cross_project.enabled: false. Idea: In a multi-project org, kyverno-json policies could be shared across projects (a tagging standard policy applies to all projects). Reason deferred: ACDL is single-project (active_projects: ["acdl"]). Cross-project ideation is disabled in config. Recorded for when the org grows.

Summary

• 5 ideas accepted (I1..I5) → already captured as REQ-295, REQ-297, REQ-300, REQ-303, REQ-304, REQ-305.
• 3 ideas deferred (I6, I7, I8) with documented blocking reasons.
• 0 ideas rejected (below-threshold ideas are deferred, not rejected — they may activate when their blockers lift).
• The accepted ideas are the quality improvement the user asked for ("ideate and explore how it can be used within the Nova platform to improve quality of the platform checks"): I1 (regression-gate-as- policy) is the headline quality improvement; I4 + I5 are the defense- in-depth coverage improvements; I2 + I3 are the architecture improvements (imperative → declarative).
• No new requirements added beyond REQ-291..309 (the accepted ideas are already scoped into the existing requirements). The IDEATE pass validated the requirement set rather than expanding it — the ideas were anticipated in the SPECIFY stage and explicitly captured.