docs(P00): grill — v1.26 adversarial review (9 challenges, PROCEED 0.84, 2 revisions)
---ci--- project: acdl phase: 0 milestone: v1.26 status: grill verdict: PROCEED confidence: 0.84 revisions: [G-Q4 REQ-322 to P2 W0, G-Q6 enforcement-deferred note, G-Q9 key-split future item] ---/ci---
This commit is contained in:
Jon Chery
@@ -1,10 +1,10 @@
|
|||||||
{
|
{
|
||||||
"phase": 0,
|
"phase": 0,
|
||||||
"stage": "plan",
|
"stage": "grill",
|
||||||
"milestone": "v1.26",
|
"milestone": "v1.26",
|
||||||
"phase_role": "pre_execution",
|
"phase_role": "pre_execution",
|
||||||
"attempts": 0,
|
"attempts": 0,
|
||||||
"updated_at": "2026-08-12T21:15:00Z",
|
"updated_at": "2026-08-12T21:16:00Z",
|
||||||
"project": "acdl",
|
"project": "acdl",
|
||||||
"projects": ["acdl", "nova-blockchain-exchange"],
|
"projects": ["acdl", "nova-blockchain-exchange"],
|
||||||
"active_milestone": "v1.26",
|
"active_milestone": "v1.26",
|
||||||
|
|||||||
+182
-173
@@ -1,14 +1,15 @@
|
|||||||
# GRILL — v1.25 kyverno-json Unified Policy Engine
|
# GRILL — v1.26 Live Pilot Estate Activation
|
||||||
|
|
||||||
> Adversarial review of the v1.25 SPECIFY + CLARIFY + RESEARCH + IDEATE +
|
> Adversarial review of the v1.26 SPECIFY + CLARIFY + RESEARCH + IDEATE +
|
||||||
> PLAN. The grill red-teams the proposal across feasibility, scope,
|
> PLAN. The grill red-teams the proposal across feasibility, scope,
|
||||||
> budget, and the swap-boundary claim. Each challenge gets a binding
|
> budget, and the domain claims (homegrown blockchain, pilot estate,
|
||||||
> verdict (PROCEED / REVISE / ESCALATE). Autonomy: full — escalations
|
> metric grounding). Each challenge gets a binding verdict
|
||||||
> auto-resolve with assumption logging unless confidence < 0.60.
|
> (PROCEED / REVISE / ESCALATE). Autonomy: full — escalations auto-
|
||||||
|
> resolve with assumption logging unless confidence < 0.60.
|
||||||
|
|
||||||
## Verdict: PROCEED (0.86) — 0 escalations, 2 revisions
|
## Verdict: PROCEED (0.84) — 0 escalations, 2 revisions
|
||||||
|
|
||||||
The milestone is feasible, scoped, and the swap boundary is real. Two
|
The milestone is feasible, scoped, and the domain claims hold. Two
|
||||||
plan revisions are binding (G-Q4, G-Q8) and are already captured in
|
plan revisions are binding (G-Q4, G-Q8) and are already captured in
|
||||||
PLAN.md. No work is blocked.
|
PLAN.md. No work is blocked.
|
||||||
|
|
||||||
@@ -16,201 +17,209 @@ PLAN.md. No work is blocked.
|
|||||||
|
|
||||||
## Challenges
|
## Challenges
|
||||||
|
|
||||||
### G-Q1 — Does kyverno-json violate "platform functions without AI"?
|
### G-Q1 — Is a homegrown PoA blockchain viable for a pilot, or is it reckless?
|
||||||
|
|
||||||
**Challenge:** NORTH_STAR.md Strategic Objective #2 says "the platform
|
**Challenge:** Authoring a blockchain (even a minimal PoA ledger) is a
|
||||||
functions without AI." kyverno-json is a new runtime dependency. Is
|
non-trivial domain. A homegrown chain could have correctness bugs (hash
|
||||||
this a real violation, or is the tenet about LLMs (not deterministic
|
chain breaks, non-deterministic blocks, settlement-finality race
|
||||||
engines)?
|
conditions). Why not use a proven chain (Ethereum L2, Solana, Hyperledger
|
||||||
|
Fabric)?
|
||||||
|
|
||||||
**Verdict:** PROCEED (confidence 0.95). kyverno-json is deterministic
|
**Verdict:** PROCEED (confidence 0.88). The pilot's purpose is to
|
||||||
(same policy + payload → same result, every run). The tenet
|
exercise the Nova platform's deploy/policy/attestation gates over a
|
||||||
distinguishes AI (non-reproducible) from automation (reproducible).
|
real consumer estate — not to build a production blockchain. A
|
||||||
kyverno-json is the latter — and is *more* aligned than the imperative
|
homegrown PoA ledger is the minimal viable chain: append-only blocks,
|
||||||
Python it replaces (`core/env_transition.py`, `core/regression_verify.py`)
|
single validator, SHA-256 hash chain, deterministic block production.
|
||||||
because the policy is declarative (visible, auditable). The
|
This is ~200 lines of Python (block + ledger + validator). The chain
|
||||||
`is_configured()` guard ensures the platform runs without the binary.
|
needs to be real enough to record transactions + produce a settlement-
|
||||||
Already resolved as D-120 in CLARIFY. No revision needed.
|
finality signal for the kyverno-json policy (REQ-315) — not to solve
|
||||||
|
Byzantine consensus. A proven chain (Ethereum/Solana/Hyperledger) would
|
||||||
|
be the *consumer app's* choice, not the platform's; the platform is
|
||||||
|
chain-agnostic. For the pilot, the homegrown chain avoids a heavyweight
|
||||||
|
external dependency (a full node, smart contracts, gas models) that
|
||||||
|
would obscure the platform-gates demonstration. REQ-310 tests cover
|
||||||
|
chain integrity, hash determinism, genesis, append/verify — the
|
||||||
|
correctness surface is bounded. Multi-validator BFT is a future
|
||||||
|
milestone (D-201). No revision needed.
|
||||||
|
|
||||||
### G-Q2 — Is the PolicyEngine protocol over-engineered for a 2-engine future?
|
### G-Q2 — Does "all types of securities" scope-explode the milestone?
|
||||||
|
|
||||||
**Challenge:** The user asked for a swappable adapter ("we might one
|
**Challenge:** The user said "offering all types of securities." Equities
|
||||||
day decide to replace it with something else like OPA"). A Python
|
(D-200, pilot scope) is one type. Bonds (T+2), derivatives (varying),
|
||||||
Protocol + registry is ~40 lines. But Nova has 1 engine today. Is this
|
options (exercise models) have very different settlement models. Does
|
||||||
premature abstraction?
|
the equities-only deferral betray the user's intent?
|
||||||
|
|
||||||
**Verdict:** PROCEED (confidence 0.85). The user *explicitly* asked for
|
**Verdict:** PROCEED (confidence 0.85). The user *chose* equities-only
|
||||||
the swap boundary — this is not speculative abstraction, it's a
|
pilot (Q4 in the plan discussion, answer "A to all 3 questions" — the
|
||||||
stated requirement. The protocol is minimal (3 methods) and the OPA-
|
recommended scope). "All types of securities" is the *product vision*;
|
||||||
equivalent surface is documented (RESEARCH §4.2) — the swap is a known
|
v1.26 is the *pilot* (equities first). The roadmap documents the
|
||||||
quantity, not a hope. The cost is ~40 lines of Python + a config key;
|
deferral. The pilot demonstrates the Nova platform's gates over the
|
||||||
the benefit is a documented, tested swap boundary that a future
|
simplest settlement model (T+1); expanding to other security types is
|
||||||
milestone implements without re-architecting. This is the moat (NORTH
|
a straightforward extension (new settlement-service branches + new
|
||||||
STAR Objective #2 — provable trust via a replaceable substrate, not a
|
kyverno-json policies) once the platform-gates pattern is proven. No
|
||||||
vendor lock-in).
|
revision needed — the scope decision is the user's, not the grill's.
|
||||||
|
|
||||||
### G-Q3 — Does wrapping checkov findings in kyverno-json meta-policies break the MTTR < 60s target?
|
### G-Q3 — Does the consumer-repo-as-2nd-project break single-project tooling?
|
||||||
|
|
||||||
**Challenge:** NORTH_STAR.md MTTR target: < 60s p95. Adding a second
|
**Challenge:** CIAgent has been single-project since v1.0. v1.26
|
||||||
engine pass over the terraform plan + a meta-policy pass over the
|
activates multi-project mode (2 projects: `acdl` +
|
||||||
merged PCR list adds latency. Does this break the target?
|
`nova-blockchain-exchange`). Does this break assumptions in the
|
||||||
|
CIAgent tooling (branch naming, `.ciagent/` paths, commit `---ci---`
|
||||||
|
blocks)?
|
||||||
|
|
||||||
**Verdict:** PROCEED (confidence 0.88). RESEARCH §5 analyzes: the kj
|
**Verdict:** PROCEED (confidence 0.90). `run.md` Step 0 explicitly
|
||||||
pass over plan JSON is < 1s (Go binary startup + JMESPath over a small
|
specifies multi-project mode: `projects[]` with length > 0,
|
||||||
plan); it runs **in parallel** with Checkov (REQ-301), so wall-clock
|
`active_projects` array, `.ciagent/<slug>/` subdirectory paths, branch
|
||||||
impact is `max(checkov_time, kj_time)` ≈ checkov_time. Meta-policies
|
prefixes `<slug>/`. The `---ci---` block gains a `project: <slug>`
|
||||||
run in-memory over the merged list (< 10ms). Total MTTR impact: < 1s
|
field (already in the v1.26 commits). The consumer's project files
|
||||||
on a 5-15s step. **Binding revision (G-Q3a):** P3 VERIFY must include a
|
live in `.ciagent/nova-blockchain-exchange/`. The platform's existing
|
||||||
timing assertion — `run_platform.sh` Step 5 wall-clock with vs without
|
flat `.ciagent/` files remain the primary set (the platform is the
|
||||||
kj must be within 1s (or kj must be faster than checkov, which is
|
default project). Branch naming: the consumer's phases use
|
||||||
expected). Captured as a P3 verify gate, not a PLAN change.
|
`nova-blockchain-exchange/phase/01-...`; the platform's phases use
|
||||||
|
`acdl/phase/03-...` (or flat `phase/03-...` for platform-level work).
|
||||||
|
No tooling change needed — the multi-project spec is already in
|
||||||
|
`run.md`. D-206 records this. No revision needed.
|
||||||
|
|
||||||
### G-Q4 — Plan revision: NullEngine fallback may mask misconfiguration
|
### G-Q4 — Does the P2 contract reference a `dynamodb` module that doesn't exist until P3?
|
||||||
|
|
||||||
**Challenge:** PLAN.md P1 says "existing tests pass (NullEngine
|
**Challenge:** The original plan had REQ-322 (DynamoDB primitive) in
|
||||||
fallback when `policy` key absent in test config)." But the v1.25
|
P3, but the P2 contract (REQ-313) references `dynamodb` in its
|
||||||
config.json *sets* the `policy` key. So existing tests that load the
|
`infrastructure` block. If the primitive doesn't exist until P3, the
|
||||||
real config get `KyvernoJsonEngine` with `is_configured()==false` →
|
P2 contract's `dynamodb` block can't resolve at registry time — only
|
||||||
`SKIPPED`. The NullEngine fallback only triggers when the key is
|
at schema time (the schema is open). Is this a vertical-slice
|
||||||
*absent*. Is there a gap where a test expects `NullEngine` but gets
|
violation (P2 ships a contract that can't fully resolve)?
|
||||||
`KyvernoJsonEngine` (skipped)?
|
|
||||||
|
|
||||||
**Verdict:** REVISE (confidence 0.82). The fallback path is correct
|
**Verdict:** REVISE (confidence 0.92). This is a real vertical-slice
|
||||||
but the PLAN wording is ambiguous. **Binding revision:** P1 must
|
violation. PLAN.md already revised: REQ-322 moves to P2 W0 (before the
|
||||||
explicitly test *both* paths: (a) `policy` key absent → `NullEngine`
|
contract). The revised mapping (PLAN.md "Revised: REQ-322 → P2 W0")
|
||||||
→ `SKIPPED` PCR; (b) `policy` key present + `which kj` false →
|
makes P2 self-contained: the primitive + the contract + the deploy
|
||||||
`KyvernoJsonEngine` → `is_configured()==false` → `SKIPPED` PCR with
|
invocation all land in P2. This is a binding revision — the original
|
||||||
`KJ_ENGINE_NOT_CONFIGURED` (distinct from NullEngine's
|
P3 placement is superseded. ROADMAP.md is already updated (REQ-322 in
|
||||||
`NULL_ENGINE_INACTIVE`). The two `SKIPPED` PCRs have different
|
P2). No further revision needed — the plan self-corrected.
|
||||||
`ruleId`s so audit can distinguish "policy disabled" from "engine not
|
|
||||||
installed." PLAN.md P1 verification is amended to assert both paths.
|
|
||||||
Already reflected in REQ-291 (NullEngine) + REQ-293
|
|
||||||
(`KJ_ENGINE_NOT_CONFIGURED`). No requirement change — PLAN wording
|
|
||||||
clarified.
|
|
||||||
|
|
||||||
### G-Q5 — Policy explosion: 4 targets × N rules = maintenance load
|
### G-Q5 — Does live-AWS pilot break the MTTR < 60s target?
|
||||||
|
|
||||||
**Challenge:** v1.25 adds ~13 policy files (4 contract + 3 stack-IR +
|
**Challenge:** NORTH_STAR.md MTTR target: < 60s p95. The pilot runs
|
||||||
3 plan-JSON + 2 meta + 3 regression + 1 smoke). Each is a YAML file
|
`terraform apply` (creating real AWS resources: ECS + DynamoDB + S3).
|
||||||
with JMESPath. Is this a maintenance burden that grows unbounded?
|
Apply latency for a 3-resource stack is typically 2-5 minutes (ECS
|
||||||
|
service creation is the slow step). Does this break the MTTR target?
|
||||||
|
|
||||||
**Verdict:** PROCEED (confidence 0.80). 13 policies is manageable —
|
**Verdict:** PROCEED (confidence 0.86). The MTTR target is for
|
||||||
each is < 30 lines of YAML, co-located per target dir, and the meta-
|
*platform-detected + platform-remediated incidents* (apply.failed →
|
||||||
policy cross-check (`tagging-rules-agree`) keeps the set auditable.
|
successful retry), not for first-time apply latency. The pilot's
|
||||||
The growth rate is bounded by the module count (module owners author
|
first apply is a deployment, not an incident-remediation. The MTTR
|
||||||
per-module policies, documented in P4 STANDARDS.md). The alternative
|
metric measures the retry path: if the apply fails (e.g. IAM
|
||||||
(imperative Python in `regression_verify.py` + `env_transition.py`) is
|
permission), the platform retries — the retry MTTR is the time from
|
||||||
*less* auditable — the policies are a net improvement. No revision.
|
`apply.failed` to `apply.succeeded`, which is < 60s for a retry (the
|
||||||
|
resources are already partially created; the retry completes the
|
||||||
|
remaining steps). The pilot's apply latency is a deployment metric
|
||||||
|
(lead time), not an MTTR metric. RESEARCH §1.2 (v1.25 grill G-Q3)
|
||||||
|
analyzed this same question for the kyverno-json pass — the same
|
||||||
|
reasoning applies. No revision needed.
|
||||||
|
|
||||||
### G-Q6 — The tagging cross-check (D-118) is the only redundant rule — is it worth the complexity?
|
### G-Q6 — Is the settlement-finality policy (REQ-315) over-engineering for a pilot?
|
||||||
|
|
||||||
**Challenge:** D-118 keeps `NOVA_TAG_NAMING` (Checkov) AND adds
|
**Challenge:** A kyverno-json policy asserting settlement finality
|
||||||
`KJ_REQUIRE_TAGGING_STANDARD` (kyverno-json) with a `tagging-rules-agree`
|
(`all_committed: true`) before promotion is a securities-specific
|
||||||
meta-policy. This is the only case where two engines evaluate the same
|
extension of v1.25's policy engine. Is this over-engineering for a
|
||||||
concern. Is the defense-in-depth worth the complexity?
|
pilot that only runs in `dev` (autonomous, no promotion to qa/prod/dr
|
||||||
|
in v1.26 per D-208)?
|
||||||
|
|
||||||
**Verdict:** PROCEED (confidence 0.82). The tagging standard is the
|
**Verdict:** PROCEED (confidence 0.80). The policy is *authored* in
|
||||||
highest-impact rule (v1.8 D-tagging-standard, v1.10 re-verification —
|
v1.26 (P3) but its *enforcement* activates when a promotion to qa/prod
|
||||||
the rule that gates every resource). Redundancy here is intentional:
|
happens — which is a *future* milestone (D-208: qa/prod/dr stay
|
||||||
the Checkov rule catches HCL-level violations; the kj policy catches
|
placeholder this milestone). The policy is tested (passing + failing
|
||||||
IR-level violations (before terraform runs); the meta-policy catches
|
fixtures; skip when `kj` absent) in P3, but it doesn't gate a `dev`
|
||||||
engine drift. The cost is 2 policy files + 1 meta-policy; the benefit
|
apply (the pilot-readiness policy REQ-320 gates `dev`; the settlement-
|
||||||
is that a tagging violation can't slip through a single engine's
|
finality policy gates promotions). Authoring + testing the policy in
|
||||||
blind spot. This is the textbook defense-in-depth case. No revision.
|
v1.26 is the right thing: it (a) proves the kyverno-json engine can
|
||||||
|
assert a domain invariant, (b) ships the policy artifact so a future
|
||||||
|
milestone that binds qa/prod/dr can enable it without re-architecting,
|
||||||
|
(c) extends v1.25's moat (the policy engine is swappable + extensible
|
||||||
|
to new domains). The cost is ~1 policy file + 1 test file. No revision
|
||||||
|
needed — but the POLICY IS NOT ENFORCED in v1.26 (it's authored +
|
||||||
|
tested, enforcement is future). PLAN.md should note this. **Minor
|
||||||
|
revision: PLAN.md P3 W4 Task 4.1 should note "policy authored + tested;
|
||||||
|
enforcement deferred to the milestone that binds qa/prod/dr."** Already
|
||||||
|
implicit in the plan (the policy gates promotions, not dev applies);
|
||||||
|
making it explicit is a documentation refinement, not a scope change.
|
||||||
|
|
||||||
### G-Q7 — Can `kj scan` actually evaluate the merged PCR list as a payload?
|
### G-Q7 — Is D-083 deferral defensible for a pilot with real money-like flows?
|
||||||
|
|
||||||
**Challenge:** The meta-policies (REQ-303) consume the merged
|
**Challenge:** The pilot is a stock exchange — securities trading. D-083
|
||||||
`list[PolicyCheckResult]` as their payload. `kj scan` expects a JSON/
|
(S3 Object Lock / JWS tamper-evident ledger) is deferred (D-204). The
|
||||||
YAML *file*. Is the PCR list a valid kyverno-json payload shape?
|
SQLite hash-chain + DynamoDB outbox is the audit record. Is this
|
||||||
|
defensible for a domain where audit integrity is legally mandated?
|
||||||
|
|
||||||
**Verdict:** PROCEED (confidence 0.85). The PCR list is a JSON array
|
**Verdict:** PROCEED (confidence 0.82). The pilot is a *technical
|
||||||
of objects — a valid kyverno-json payload. The `~` modifier iterates
|
demonstration*, not a production trading system. No real money, no real
|
||||||
the array; JMESPath asserts over each PCR's `severity`/`result`/
|
securities, no real investors — the "securities" are test tokens on a
|
||||||
`ruleId`/`resourceRef` fields. The engine writes the list to a temp
|
homegrown chain. The audit integrity requirement (SEC Rule 17a-4, FINRA
|
||||||
JSON file and invokes `kj scan --payload <file>`. This is verified in
|
retention) applies to *production* trading systems, not to a pilot
|
||||||
P3 `test_meta_policies.py`. No revision — but **binding note (G-Q7a):**
|
exercising a platform's deploy/policy/attestation gates. The SQLite
|
||||||
the `KyvernoJsonEngine.evaluate()` must accept a `list[dict]` payload
|
hash-chain + DynamoDB outbox is a tamper-*evident* record (any tampering
|
||||||
(not just a `dict`) — the `payload: dict | str` signature in RESEARCH
|
breaks the hash chain) — it's just not tamper-*resistant* (S3 Object
|
||||||
§4.1 is too narrow. **Revision:** the protocol signature is
|
Lock + JWS would make it tamper-resistant). For a pilot, tamper-evident
|
||||||
`payload: dict | list | str` (a list is a valid payload for meta-
|
suffices. D-083 lift is a future milestone (when the pilot becomes a
|
||||||
policies). Captured in REQ-291 + REQ-293 (the engine writes whatever
|
production system). D-204 records this. No revision needed.
|
||||||
JSON-serializable payload it receives to the temp file). PLAN.md P1
|
|
||||||
amended.
|
|
||||||
|
|
||||||
### G-Q8 — Plan revision: the OPA swap surface claims (RESEARCH §4.2) are unverified
|
### G-Q8 — Does the outcome-backfill emitter (REQ-317) touch the PCR schema?
|
||||||
|
|
||||||
**Challenge:** RESEARCH §4.2 documents the OPA-equivalent surface
|
**Challenge:** REQ-317 wires `apply.completed`/`apply.failed` →
|
||||||
(`opa eval -d <dir> -i <json>`), but no `OpaEngine` is implemented in
|
`fact_decision.outcome`. The v1.25 hard constraint says "DO NOT change
|
||||||
v1.25. Is the swap-boundary claim testable, or is it aspirational?
|
`schemas/policy_check_result.schema.json`." Does the backfill touch the
|
||||||
|
PCR schema?
|
||||||
|
|
||||||
**Verdict:** REVISE (confidence 0.78). The swap-boundary claim is
|
**Verdict:** PROCEED (confidence 0.95). D-211 (CLARIFY) already
|
||||||
*testable in v1.25* without implementing OPA: the `PolicyEngine`
|
resolved this: the outcome backfill touches the *metrics cold store*
|
||||||
Protocol + registry is the contract; the `NullEngine` proves a second
|
(`fact_decision` table in `metrics/nova_metrics.db`), not the PCR
|
||||||
implementation exists (structural conformance). **Binding revision
|
schema. The backfill reads run-manifest events (not PCRs) and updates
|
||||||
(G-Q8a):** P1 `test_policy_engine.py` must include a
|
the decision's outcome column. The PCR schema is unchanged. This
|
||||||
`test_protocol_conformance_null_engine` that asserts `NullEngine`
|
respects the v1.25 hard constraint. No revision needed.
|
||||||
satisfies the `PolicyEngine` Protocol (via
|
|
||||||
`isinstance(NullEngine(), PolicyEngine)` under `runtime_checkable`).
|
|
||||||
This proves the protocol is *real* (a second engine implements it)
|
|
||||||
without implementing OPA. The OPA-equivalent surface in RESEARCH §4.2
|
|
||||||
stays as documentation (the future milestone implements it). PLAN.md
|
|
||||||
P1 verification amended. No requirement change — the test is already
|
|
||||||
in REQ-308 ("protocol conformance").
|
|
||||||
|
|
||||||
### G-Q9 — Budget: is 4 execution phases + P5 too many for the scope?
|
### G-Q9 — Does the `NOVA_AWS_*` root-equivalent key create a security risk?
|
||||||
|
|
||||||
**Challenge:** v1.25 is 19 requirements across 6 phases. Recent
|
**Challenge:** D-207 says `NOVA_AWS_*` has root-equivalent permissions
|
||||||
milestones: v1.24 had 15 reqs / 4 phases; v1.23 had 13 reqs / 7 phases.
|
(confirmed empirically: the bootstrap created the S3 bucket + DynamoDB
|
||||||
Is 6 phases too many (overhead) or too few (per-phase overload)?
|
table). Using a root key for the pilot's `terraform apply` is a
|
||||||
|
security risk — a key compromise gives full account access. Should the
|
||||||
|
pilot use a least-privilege key?
|
||||||
|
|
||||||
**Verdict:** PROCEED (confidence 0.85). 19 reqs / 6 phases ≈ 3.2 reqs/
|
**Verdict:** PROCEED (confidence 0.78). The risk is real but bounded:
|
||||||
phase — within the v1.24 cadence (3.75 reqs/phase). The phases are
|
(a) the pilot runs in a single account (`581513795199`) with no
|
||||||
vertical slices (each ships a working increment): P1 engine works
|
production workloads (the v1.11 teardown left it empty; the pilot is
|
||||||
end-to-end with a smoke policy; P2 contract + IR policies feed the
|
the only workload), (b) the key is in `.env.secrets` (gitignored, never
|
||||||
confidence signal; P3 plan-JSON + meta + pipeline wiring; P4
|
committed), (c) the deploy workflow uses OIDC by default (the static
|
||||||
regression + docs. The phase count matches the user's "3-4 phases"
|
key is the override, not the primary path). A future hardening
|
||||||
selection (4 execution + 1 final = 5, which is the v1.24 shape). No
|
milestone should split `NOVA_AWS_*` into a root `NOVA_BOOTSTRAP_AWS_*`
|
||||||
revision.
|
+ a least-privilege `NOVA_AWS_*` runner key (the spike-runner pattern).
|
||||||
|
For v1.26, the single key suffices (pilot scope). D-207 records this.
|
||||||
### G-Q10 — The `nova.cloudinit.dev/severity` annotation convention is unvalidated
|
**Minor revision: PLAN.md should note the key-split as a future
|
||||||
|
hardening item.** Already implicit in D-207; making it explicit in the
|
||||||
**Challenge:** RESEARCH §2.6 declares the severity-via-annotation
|
plan is a documentation refinement.
|
||||||
convention, but kyverno-json's behavior with unknown annotations is
|
|
||||||
not verified. Does `kj scan` ignore unknown annotations, or does it
|
|
||||||
reject the policy?
|
|
||||||
|
|
||||||
**Verdict:** PROCEED (confidence 0.80). kyverno-json is Kubernetes-
|
|
||||||
style CRD-based — unknown `metadata.annotations` are preserved and
|
|
||||||
ignored (standard K8s behavior). The engine reads the annotation from
|
|
||||||
the loaded policy YAML (via `yaml.safe_load`) before invoking `kj
|
|
||||||
scan` — so even if `kj scan` stripped annotations, the engine still
|
|
||||||
has them. **Binding note (G-Q10a):** P1 `test_kyverno_json_engine.py`
|
|
||||||
must assert the severity annotation is read correctly (a policy with
|
|
||||||
`nova.cloudinit.dev/severity: high` produces PCRs with `severity:
|
|
||||||
"high"`; a policy without the annotation produces PCRs with
|
|
||||||
`severity: "info"` default). Captured in REQ-309 ("PCR schema
|
|
||||||
validity" includes severity). No requirement change — the test is
|
|
||||||
already in REQ-309.
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## Summary
|
## Summary
|
||||||
|
|
||||||
10 challenges; 10 resolved (8 PROCEED, 2 REVISE, 0 ESCALATE).
|
9 challenges; 0 escalations; 2 binding revisions (G-Q4, G-Q6/G-Q9
|
||||||
- **Revisions (binding, already in PLAN/REQs):**
|
minor). Overall verdict: PROCEED (confidence 0.84).
|
||||||
- G-Q4: P1 tests both fallback paths (NullEngine vs
|
|
||||||
KyvernoJsonEngine-not-configured) — distinct `ruleId`s for audit.
|
|
||||||
- G-Q7a: protocol signature `payload: dict | list | str` (list is a
|
|
||||||
valid payload for meta-policies).
|
|
||||||
- G-Q8a: P1 test asserts `NullEngine` satisfies the `PolicyEngine`
|
|
||||||
Protocol (proves the swap boundary is real without implementing OPA).
|
|
||||||
- G-Q3a: P3 VERIFY includes a timing assertion (kj pass < 1s, parallel
|
|
||||||
with checkov).
|
|
||||||
- G-Q10a: P1 test asserts severity annotation is read correctly.
|
|
||||||
- **No requirement changes** — all revisions are clarifications to
|
|
||||||
PLAN.md verification text, already supported by existing REQs
|
|
||||||
(REQ-291, REQ-293, REQ-308, REQ-309).
|
|
||||||
- **0 escalations** — all challenges auto-resolved at full autonomy.
|
|
||||||
|
|
||||||
The milestone PROCEEDs to PHASE 0 SHIP → P1.
|
**Binding revisions:**
|
||||||
|
- **G-Q4:** REQ-322 moves to P2 W0 (already revised in PLAN.md + ROADMAP.md).
|
||||||
|
- **G-Q6:** PLAN.md P3 W4 Task 4.1 should note the settlement-finality
|
||||||
|
policy is authored + tested in v1.26 but *enforcement* is deferred to
|
||||||
|
the milestone that binds qa/prod/dr (documentation refinement).
|
||||||
|
- **G-Q9:** PLAN.md should note the `NOVA_AWS_*` key-split as a future
|
||||||
|
hardening item (documentation refinement).
|
||||||
|
|
||||||
|
**No work is blocked.** The milestone is feasible, scoped, and the
|
||||||
|
domain claims hold. The homegrown PoA blockchain is a minimal viable
|
||||||
|
chain (~200 lines), not a production consensus protocol. The equities-
|
||||||
|
only scope is the user's choice. The multi-project mode is specified in
|
||||||
|
`run.md`. The P2→P3 dependency is resolved (REQ-322 → P2 W0). The
|
||||||
|
MTTR target is for incident-remediation, not first-time apply. The
|
||||||
|
settlement-finality policy is authored + tested, enforcement is future.
|
||||||
|
D-083 deferral is defensible for a technical pilot. The PCR schema is
|
||||||
|
unchanged. The root-equivalent key is a bounded risk with a documented
|
||||||
|
future hardening path.
|
||||||
+23
-2
@@ -195,7 +195,10 @@ policy-engineer (kyverno-json policies).
|
|||||||
- **Task 4.1** (policy-engineer):
|
- **Task 4.1** (policy-engineer):
|
||||||
`adapters/kyverno-json/policies/settlement-finality/all-matches-committed.json`
|
`adapters/kyverno-json/policies/settlement-finality/all-matches-committed.json`
|
||||||
— kyverno-json policy over settlement-service status JSON (asserts
|
— kyverno-json policy over settlement-service status JSON (asserts
|
||||||
`all_committed: true`).
|
`all_committed: true`). **Note (G-Q6):** the policy is authored +
|
||||||
|
tested in v1.26; *enforcement* is deferred to the milestone that
|
||||||
|
binds qa/prod/dr (D-208 — the policy gates promotions, not dev
|
||||||
|
applies).
|
||||||
- **Task 4.2** (policy-engineer):
|
- **Task 4.2** (policy-engineer):
|
||||||
`adapters/kyverno-json/policies/pilot-readiness/no-placeholder-account.json`
|
`adapters/kyverno-json/policies/pilot-readiness/no-placeholder-account.json`
|
||||||
— kyverno-json policy over env JSON (asserts
|
— kyverno-json policy over env JSON (asserts
|
||||||
@@ -386,4 +389,22 @@ schema time. This makes P2 self-contained: the primitive + the contract
|
|||||||
| REQ-321 (docs) | P4 | W2 | lead-developer |
|
| REQ-321 (docs) | P4 | W2 | lead-developer |
|
||||||
|
|
||||||
This revision is a binding plan decision (G-Q8 in the grill may
|
This revision is a binding plan decision (G-Q8 in the grill may
|
||||||
challenge it).
|
challenge it).
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Future Hardening Items (not in v1.26 scope, documented per grill G-Q9)
|
||||||
|
|
||||||
|
- **`NOVA_AWS_*` key-split:** v1.26 uses a single `NOVA_AWS_*` key with
|
||||||
|
root-equivalent permissions (D-207, confirmed empirically by the
|
||||||
|
bootstrap). A future hardening milestone should split this into a
|
||||||
|
`NOVA_BOOTSTRAP_AWS_*` root key (bootstrap only) + a least-privilege
|
||||||
|
`NOVA_AWS_*` runner key (the spike-runner pattern). The pilot scope
|
||||||
|
(single account, no production workloads, OIDC default) bounds the
|
||||||
|
risk.
|
||||||
|
- **Multi-account landing zone:** qa/prod/dr on separate accounts (D-208
|
||||||
|
keeps them placeholder in v1.26).
|
||||||
|
- **D-083 lift:** S3 Object Lock + JWS tamper-evident ledger (when the
|
||||||
|
pilot becomes a production system, D-204).
|
||||||
|
- **Multi-validator BFT consensus:** D-201.
|
||||||
|
- **Other security types:** bonds (T+2), derivatives, options (D-200).
|
||||||
Reference in New Issue
Block a user