acdl/.ciagent/IDEATE.md

IDEATE — v1.26 Live Pilot Estate Activation

Autonomy: full. 3-tier ideation per config.json ideation.enabled: true. cross_project.enabled: false → cross-project tier scoped to multi-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 — Outcome-backfill emitter ✅ ACCEPTED (REQ-317)

Category: quality, coverage Confidence: 0.92 Pattern: stuck pending status → backfilled from a later event (the most direct metric-grounding pattern). Source: core/metrics/decision_ledger.py:210-211 documents the event chain confidence.computed → ai.decision.made → attestation.recorded → run.completed/failed. collector.py:262 inserts fact_decision.outcome as "pending" — no backfill step wires run.completed/failed back into the decision's outcome. The AI Decision Accuracy metric (trust_snapshot.py:70-85) reads decisions WHERE outcome='succeeded' ÷ total → 0% today (all pending). Idea: core/metrics/outcome_backfill.py reads run-manifest completed/failed events and updates fact_decision.outcome + fact_decision.backfilled_at. The collector invokes backfill after run completion. Grounds AI Decision Accuracy (Post-Pilot target). Accepted into: REQ-317. Phase P3.

I2 — reason='confidence' escalation tag ✅ ACCEPTED (REQ-318)

Category: quality, coverage Confidence: 0.90 Pattern: boolean field → discriminated field (the metric-numerator precision pattern). Source: core/confidence_signal.py:184 — a block band sets human_override=True. The Human Escalation Frequency metric (docs/metrics/human_escalation_frequency.md:11-12) is defined as count(runs WHERE hitl_block=1 AND reason='confidence') ÷ total runs. The reason='confidence' discriminator is not stored today. Idea: ai.decision.made gains escalation_reason: 'confidence' when band == 'block'. The collector persists it into fact_run. Grounds Human Escalation Frequency numerator. Accepted into: REQ-318. Phase P3.

I3 — Env-JSON state_backend wiring reconciliation ✅ ACCEPTED (REQ-319)

Category: architecture, improvement Confidence: 0.88 Pattern: unused config field → wired config field (the single-source-of-truth pattern). Source: adapters/terraform/adapter.py:116-117 computes the state bucket as nova-tfstate-<AWS_ACCOUNT_ID>-us-east-1 from the AWS_ACCOUNT_ID env var — not from the env JSON's state_backend.bucket. The env JSON's state_backend field is currently unused by the live apply path. Idea: The adapter reads env.state_backend.bucket when present (falling back to the computed name for backwards compat). dev.json gets the real bucket name. Closes the wiring gap so the pilot's env JSON is the single source of truth. Accepted into: REQ-319. Phase P3.

I4 — Pilot-readiness kyverno-json policy ✅ ACCEPTED (REQ-320)

Category: security, architecture Confidence: 0.85 Pattern: runtime guard → declarative policy (the v1.25 thesis applied to pilot onboarding). Source: core/environment_check.py:48-53 emits a stderr warning (non-fatal) when account_id == "000000000000" and env != dev. A warning is not a gate. The pilot should fail-closed if someone tries to apply against a placeholder account. Idea: A kyverno-json policy over the env JSON asserting account_id != "000000000000" before any apply. Declarative fail-closed gate. Extends v1.25's policy engine to the pilot-onboarding domain. Accepted into: REQ-320. Phase P3.

Tier 2 — Backend-enriched (signal-driven)

I5 — Settlement-finality kyverno-json policy ✅ ACCEPTED (REQ-315)

Category: security, coverage Confidence: 0.82 Pattern: domain invariant → declarative policy (the v1.25 thesis applied to the securities domain — the most novel use of kyverno-json in v1.26). Source: The pilot's settlement service records matches as transactions on the chain; settlement finality = block commit. The NORTH_STAR Objective #2 (provable trust) says trust should be a policy artifact, not a promise. Today settlement finality is a runtime property of the chain; making it a declarative policy turns it into an auditable gate. Idea: A kyverno-json policy over the settlement-service status JSON asserting all_committed: true before any promotion (qa→prod). The securities-specific extension of v1.25's policy engine. The policy is skip-when-kj-absent (graceful). Accepted into: REQ-315. Phase P3.

I6 — Pilot-estate regression capability (CAP-025) ✅ ACCEPTED (REQ-316)

Category: quality, coverage Confidence: 0.88 Pattern: manual e2e → regression-gated capability (the v1.0 CAP pattern applied to the pilot). Source: core/regression_verify.py has CAP-013..024 (live-AWS + local tiers). The pilot estate is a new live-AWS capability — "contract resolve → adapter compile → terraform plan → policy scan → confidence signal → attestation → outbox record" against 581513795199. Without a regression CAP, the pilot could silently decay. Idea: CAP-025 (live-pilot-apply) in the regression gate. The round-trip assertion. Grounds the pilot as a maintained capability, not a one-shot demo. Accepted into: REQ-316. Phase P3.

I7 — DynamoDB L1 primitive ✅ ACCEPTED (REQ-322)

Category: architecture, coverage Confidence: 0.95 Pattern: missing primitive → authored module (the v1.7 + v1.8 module-build-out pattern). Source: RESEARCH §3.4 — no modules/l1/dynamodb/ exists. The blockchain exchange's ledger table needs it. The adapter is stateless/registry-driven (no TYPE_MAP); a new stack type requires a new L1 module, not an adapter change. Idea: Author modules/l1/dynamodb/ (interface.json + terraform/main.tf + README.md + instance.json + registry.json entry). The single platform-side module build-out for the milestone. Follows the s3/rds primitive template. Encryption + PITR enabled per v1.8 NFR defaults. Accepted into: REQ-322. Phase P3.

I8 — Stale adapters/README.md TYPE_MAP references ❌ DEFERRED (scope)

Category: improvement Confidence: 0.70 (above threshold, but scoped into REQ-321) Pattern: stale doc → corrected doc. Source: adapters/README.md:49-54 references the deleted TYPE_MAP/INPUT_MAP/OUTPUT_MAP — contradicts adapter.py:1-11 + modules/STANDARDS.md:212-214. Idea: Fix the stale references as part of the docs phase. Reason deferred as a standalone idea: Already captured in REQ-321 (docs + adapter README). No new requirement needed — the fix lands in P4 docs.

Tier 3 — Cross-project (deferred — multi-project, but cross-project sharing disabled)

I9 — 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: cross_project.enabled: false. Even though v1.26 is multi-project (acdl + nova-blockchain-exchange), cross-project ideation is disabled in config. Recorded for when the org grows + the flag is enabled.

I10 — Consumer-repo CI scaffolding as a reusable template ❌ DEFERRED

Category: improvement Confidence: 0.55 (below threshold — deferred, not rejected) Pattern: one-off CI → reusable template. Source: The consumer repo (nova-blockchain-exchange) needs its own CI (ci.yml — lint + pytest). If Nova expects many consumers, a reusable consumer-CI template would reduce onboarding friction. Idea: A nova-consumer-template repo (or a .github/workflow-templates/ dir) that new consumers instantiate. Reason deferred: Nova has 1 consumer today (the pilot). A template is premature abstraction until the 2nd consumer arrives. The pilot's CI is authored directly (REQ-310..312 tests). Recorded for when the 3rd consumer onboards.

Summary

• 7 ideas accepted (I1..I7) → already captured as REQ-315, REQ-316, REQ-317, REQ-318, REQ-319, REQ-320, REQ-322.
• 3 ideas deferred (I8 scoped into REQ-321; I9 config-disabled; I10 below threshold) 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 --ideate flag drives: I1 + I2 ground the Post-Pilot metrics (outcome backfill + escalation reason); I3 closes the env-JSON wiring gap; I4 + I5 extend v1.25's policy engine to the pilot domain (pilot-readiness + settlement-finality); I6 gates the pilot as a maintained capability; I7 is the single platform-side module build-out.
• No new requirements added beyond REQ-310..322 (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 + RESEARCH stages.