docs(P00): grill — v1.28 adversarial review (PROCEED 0.76, 3 critical + 16 tracked conditions applied)
---ci--- project: acdl phase: 0 milestone: v1.28 status: grill ---/ci---
This commit is contained in:
Jon Chery
+98
-129
@@ -1,141 +1,110 @@
|
||||
# GRILL — v1.27 PO State Catalog & Ciagent Compression
|
||||
# GRILL — v1.28 CLI Canonicalization + Identity Layer
|
||||
|
||||
> Adversarial review of the v1.27 SPECIFY + CLARIFY + RESEARCH + PLAN.
|
||||
> The grill red-teams the proposal across feasibility, scope, and the
|
||||
> compression-loss claims. Each challenge gets a binding verdict
|
||||
> (PROCEED / REVISE / ESCALATE). Autonomy: full.
|
||||
|
||||
## Verdict: PROCEED (0.88) — 0 escalations, 1 revision
|
||||
|
||||
The milestone is feasible, scoped, and the compression is lossless. One
|
||||
binding revision (G-Q2) refines the archive list; already captured in
|
||||
PLAN. No work is blocked.
|
||||
> Adversarial review of the v1.28 SPECIFY + CLARIFY + RESEARCH + PLAN.
|
||||
> Griller: ci-griller subagent. Autonomy: full. All 9 axes reviewed;
|
||||
> every claim verified against the live codebase.
|
||||
|
||||
---
|
||||
|
||||
## Challenges
|
||||
## Overall verdict: **PROCEED-WITH-CONDITIONS** · Confidence 0.76
|
||||
|
||||
### G-Q1 — Is archiving AUTONOMY_THESIS.md + COST.md a context loss?
|
||||
The plan is fundamentally sound — architecture correct, re-mapping
|
||||
clean (no ID collisions), technical depth accurate (DER→raw, strong-
|
||||
read revocation, stdin TTY), highest-risk item (kj binary) has a
|
||||
Fargate fallback. Not unfeasible, not over-scoped beyond an agent-driven
|
||||
repo's capacity, not security-broken by design.
|
||||
|
||||
**Challenge:** `AUTONOMY_THESIS.md` is the "autonomy in operations;
|
||||
human at stage gates" thesis — the defensibility brief. `COST.md` is
|
||||
the only AWS cost record. Archiving both moves them out of active
|
||||
context. Does this lose load-bearing content?
|
||||
|
||||
**Verdict:** PROCEED (confidence 0.90).
|
||||
- `AUTONOMY_THESIS.md` (65 lines, "Last refined: v1.21") is fully
|
||||
folded into `NORTH_STAR.md` Vision (lines 17–22: "infrastructure
|
||||
operations become visible... human attestation remains required at
|
||||
stage gates") + Anti-Goals #2 ("Not a system that removes humans from
|
||||
accountability"). The thesis is the source; NORTH_STAR is the
|
||||
authoritative durable copy. Archive preserves the v1.21 refinement;
|
||||
active context reads NORTH_STAR.
|
||||
- `COST.md` (106 lines, dated 2026-07-29, "v1.0 → v1.14") predates the
|
||||
v1.26 live pilot. The v1.26 live apply (ECS + ALB + DynamoDB + S3)
|
||||
incurred real costs this snapshot doesn't reflect. Archiving it is
|
||||
honest — a stale cost record misleads. STATE.md Domain 7 notes cost
|
||||
tracking as a capability (pre-apply Infracost grounded; actual-spend
|
||||
CUR deferred D-096). A future cost milestone writes a fresh report.
|
||||
No revision needed.
|
||||
|
||||
### G-Q2 — Does the archive list include the v1.27 P0 pre-execution files by mistake?
|
||||
|
||||
**Challenge:** D-219 (user-confirmed) says "archive all 4 pre-execution
|
||||
artifacts" (CLARIFY/GRILL/IDEATE/RESEARCH). But P0 already overwrote
|
||||
them with v1.27 content. Archiving the v1.27 versions at v1.27 P1 would
|
||||
lose the v1.27 pre-execution narrative (the decisions D-214..D-225, the
|
||||
research inventory, this grill). Is the archive list wrong?
|
||||
|
||||
**Verdict:** REVISE (confidence 0.92). This is a real ambiguity in the
|
||||
plan. The user's D-219 decision was made *before* P0 overwrote the
|
||||
files; the intent was to archive the *v1.26* pre-execution record. The
|
||||
v1.26-era content is preserved in git history (the pre-P0 commits) —
|
||||
the archive directory is not the only preservation layer. PLAN Task 2.1
|
||||
already self-corrected: the final archive list is **7 platform files +
|
||||
1 consumer file = 8 files**, excluding the 4 pre-execution files. The 4
|
||||
v1.27 P0 versions stay active through v1.27; they archive at v1.28 P1
|
||||
if v1.28 happens. The archive README notes the v1.26 pre-execution
|
||||
record is in git history. No further revision needed — the plan self-
|
||||
corrected.
|
||||
|
||||
### G-Q3 — Is the STATE.md backfill accurate enough to be the PO's source of truth?
|
||||
|
||||
**Challenge:** STATE.md has 36 capability rows across 10 domains,
|
||||
backfilled from 8 sources. The PO will read this before writing new
|
||||
REQs. If a row is inaccurate (wrong shipped tag, wrong file path,
|
||||
wrong controlling REQ), the PO could re-spec an existing capability or
|
||||
cite a stale invariant. Is the backfill accurate?
|
||||
|
||||
**Verdict:** PROCEED (confidence 0.85). The backfill sources are
|
||||
authoritative: `core/regression_verify.py` (the machine CAP-NNN
|
||||
registry), `modules/registry.json` (the live module catalog),
|
||||
`REQUIREMENTS.md` traceability (the REQ→phase→status record),
|
||||
`CHECKPOINT.json` (shipped tags), `git log` (file paths). The
|
||||
citations are direct (each row cites the controlling REQ + decision
|
||||
ID). The 11 invariants are distilled from PROJECT.md load-bearing
|
||||
decisions D-034..D-072 + W1..BA + Q1.3. The accuracy risk is
|
||||
mitigated by P1 Wave 1 (verify STATE.md against sources before
|
||||
archive). No revision needed — the verification step is in the plan.
|
||||
|
||||
### G-Q4 — Does the NFR purity gate (zero `feat:` commits) hold for v1.27?
|
||||
|
||||
**Challenge:** v1.27 authors STATE.md (a new file). Is authoring a new
|
||||
catalog file a `feat:` (feature) that breaks the NFR purity gate?
|
||||
|
||||
**Verdict:** PROCEED (confidence 0.92). D-220 (CLARIFY) resolved this:
|
||||
STATE.md is documentation (a catalog of *existing* capabilities), not a
|
||||
new platform capability. The archive moves are `chore:` (file
|
||||
relocation, lossless). No code, no schema, no platform behavior
|
||||
change. The NFR purity gate (zero `feat:` commits) holds. All v1.27
|
||||
commits use `docs(P0N):` or `chore(P01):` prefixes. No revision
|
||||
needed.
|
||||
|
||||
### G-Q5 — Does fixing PROJECT.md phase-status in P2 create a P0/P1 audit inconsistency?
|
||||
|
||||
**Challenge:** The PROJECT.md phase-status block shows P3/P4/P5 as
|
||||
"pending" (the bug flagged in the prior conversation). P0 + P1 ship
|
||||
with the bug still present (the fix is P2). Does the P0/P1 audit see
|
||||
the inconsistency?
|
||||
|
||||
**Verdict:** PROCEED (confidence 0.86). The bug is pre-existing
|
||||
(it predates v1.27; it was the trigger for the prior conversation).
|
||||
P0/P1 audits check the *v1.27* commits against the `.ciagent/` state,
|
||||
not the pre-existing PROJECT.md drift. The P2 fix is the correction;
|
||||
the P3 audit verifies the fix landed. The intermediate state (P0/P1
|
||||
with the bug present) is honest — the bug is documented in the v1.27
|
||||
PLAN + the prior conversation, and the fix is scheduled. No revision
|
||||
needed — the phasing is intentional (D-225: P1 additive, P2
|
||||
correction).
|
||||
|
||||
### G-Q6 — Is the milestone scoped too small (3 phases, 8 archive moves)?
|
||||
|
||||
**Challenge:** v1.27 is a small milestone (3 phases, ~15 file
|
||||
operations, no code). Is it worth a milestone, or should it be a
|
||||
patch on v1.26?
|
||||
|
||||
**Verdict:** PROCEED (confidence 0.88). v1.27 is not a patch on v1.26
|
||||
— v1.26 is shipped (`v1.25.5`, merged to main, milestone complete).
|
||||
The work is a new milestone by definition. The size is appropriate:
|
||||
STATE.md is a durable PO-facing artifact (loaded every ci-run going
|
||||
forward); the compression reduces active context by ~26%; the
|
||||
ship-discipline wiring affects every future milestone ship. Small but
|
||||
high-leverage. No revision needed.
|
||||
**3 critical conditions (must-fix before P1) + 16 tracked conditions.**
|
||||
No escalations (all axes ≥ 0.70 confidence).
|
||||
|
||||
---
|
||||
|
||||
## Summary
|
||||
## Axis verdicts
|
||||
|
||||
6 challenges; 0 escalations; 1 binding revision (G-Q2, already
|
||||
captured in PLAN Task 2.1). Overall verdict: PROCEED (confidence
|
||||
0.88).
|
||||
| Axis | Verdict | Confidence | Critical condition |
|
||||
|------|---------|-----------|-------------------|
|
||||
| §1 Feasibility | PROCEED-WITH-CONDITIONS | 0.82 | C-1.1 KMS asym verify; C-1.2 Argon2 fail-closed test |
|
||||
| §2 Scope | PROCEED-WITH-CONDITIONS | 0.74 | C-2.1 fold P5 into P4; C-2.2 P4 overload |
|
||||
| §3 Cost | PROCEED-WITH-CONDITIONS | 0.70 | C-3.1 cost estimate; C-3.2 CodeArtifact P1 task |
|
||||
| §4 Schedule | PROCEED-WITH-CONDITIONS | 0.76 | C-4.1 P4 critical path; C-4.2 per-phase exit |
|
||||
| §5 Technical Depth | PROCEED-WITH-CONDITIONS | 0.80 | C-5.1 ABAC shape; **C-5.2 JWS KDF** |
|
||||
| §6 Operational Readiness | PROCEED-WITH-CONDITIONS | 0.72 | **C-6.1 ABAC fail-closed**; C-6.2 threat model; C-6.3 ops guide |
|
||||
| §7 Security Posture | PROCEED-WITH-CONDITIONS | 0.73 | **C-7.1 ABAC fail-closed**; C-7.2 Argon2 params; C-7.3 cred file |
|
||||
| §8 Dependency Risk | PROCEED-WITH-CONDITIONS | 0.83 | C-8.1 CodeArtifact P1; C-8.2 pin kj version |
|
||||
| §9 Re-mapping Integrity | PROCEED-WITH-CONDITIONS | 0.84 | **C-9.1 traceability fix**; C-9.2 INV audit |
|
||||
|
||||
**Binding revisions:**
|
||||
- **G-Q2:** Archive list refined to 7 platform + 1 consumer = 8 files.
|
||||
The 4 pre-execution files (CLARIFY/GRILL/IDEATE/RESEARCH) stay active
|
||||
through v1.27 (they hold the v1.27 P0 content); the v1.26-era content
|
||||
is in git history. Already in PLAN.
|
||||
---
|
||||
|
||||
**No work is blocked.** The milestone is feasible, scoped, the
|
||||
compression is lossless (archive + git history), the STATE.md backfill
|
||||
is source-grounded with a verification step, the NFR purity holds, and
|
||||
the phasing (P1 additive, P2 correction, P3 ship) is sound.
|
||||
## Critical conditions (the 3 must-fix-before-P1)
|
||||
|
||||
### 🔴 C-6.1 / C-7.1 — ABAC fail-closed
|
||||
The token-vend Lambda's behavior on `kj` absence/error is unspecified.
|
||||
Without fail-closed, INV-17 is documentation, not a runtime guarantee —
|
||||
a `kj` load failure would bypass the ABAC gate (every PAT gets a token).
|
||||
**Fix applied to PLAN.md P4 Wave 4 Task 4.1:** "If
|
||||
`KyvernoJsonEngine.is_configured()` returns false or `evaluate()`
|
||||
raises, return 403 + audit `token.vend.denied` (reason:
|
||||
`abac_eval_failed`). Never fail open. Test: `tests/test_abac_fail_closed.py`."
|
||||
|
||||
### 🔴 C-5.2 — JWS-from-PAT key derivation
|
||||
REQ-332's AC ("public key derivable from the PAT") is unimplementable
|
||||
without a specified KDF. A PAT is a JWT, not a keypair.
|
||||
**Fix applied to PLAN.md P2 Wave 2 Task 2.3 + REQ-332 AC:** the JWS
|
||||
uses HMAC-SHA256 with a key derived via
|
||||
`HKDF-SHA256(PAT_bytes, salt='nova-local-attestation', info='jws-signing-key')`
|
||||
→ 32-byte symmetric key. The "public key derivable" AC is re-interpreted:
|
||||
the *verification key* is derived from the PAT via the same KDF (the
|
||||
PAT is the shared secret). This is a symmetric scheme, not asymmetric.
|
||||
|
||||
### 🔴 C-9.1 — Traceability drift
|
||||
REQUIREMENTS.md §v1.28 traceability table mapped 16 REQs to P2;
|
||||
PLAN.md splits them across P2/P3/P4/P5/P6. **Fix applied to
|
||||
REQUIREMENTS.md** — traceability table updated to match PLAN.md phase
|
||||
structure.
|
||||
|
||||
---
|
||||
|
||||
## Tracked conditions (16 — applied to PLAN.md as amendments)
|
||||
|
||||
- **C-1.1** KMS asymmetric key verification before P4 Wave 3 (one
|
||||
`aws kms create-key --key-spec ECC_NIST_P256` call).
|
||||
- **C-1.2** Argon2 fail-closed test in P3 Wave 2 (Lambda returns 503
|
||||
on `ImportError`, not a crash or pure-Python hash).
|
||||
- **C-2.1** Fold P5 (idp-setup) into P4 as P4 Wave 8 → **reduces to 6
|
||||
execution phases** (P1..P6, P7 = final). Applied.
|
||||
- **C-2.2** P4 is a double-length phase; acknowledged in P4 header.
|
||||
- **C-3.1** Cost envelope subsection added to PLAN.md.
|
||||
- **C-3.2 / C-8.1** CodeArtifact provisioning = P1 Wave 0 task with
|
||||
binary go/no-go gate; Gitea wheel index fallback documented.
|
||||
- **C-4.1** P4 flagged as critical-path phase (kj spike = highest-
|
||||
probability schedule slip; Fargate = +1 week).
|
||||
- **C-4.2** Per-phase exit criteria added to PLAN.md.
|
||||
- **C-5.1** `requested_claims` = list of claim names (the policy
|
||||
asserts the subject is *allowed* to request those claims).
|
||||
- **C-6.2** Threat model (REQ-347) adds: JWKS DDoS surface, PAT theft
|
||||
+ max TTL (≤24h dev, ≤1h service-account), ABAC fail-closed,
|
||||
INV-18..21 compression audit.
|
||||
- **C-6.3** Operator guide (REQ-345) adds: KMS rotation, layer update,
|
||||
PITR restore, emergency PAT revocation.
|
||||
- **C-7.2** Argon2id parameters: t=3, m=65536 KiB, p=1 (OWASP min).
|
||||
- **C-7.3** `~/.nova/credentials.json` stores OIDC token + PAT metadata
|
||||
(jti, exp, type), NOT the raw PAT.
|
||||
- **C-8.2** `kj` pinned to a specific release + SHA256 recorded.
|
||||
- **C-9.2** Threat model includes INV-18..21 compression audit
|
||||
(verify spec's attestation invariant semantics are captured by
|
||||
INV-15/16/17 + REQ-332).
|
||||
|
||||
---
|
||||
|
||||
## Escalations
|
||||
|
||||
None. All 9 axes resolved at confidence ≥ 0.70. No human escalation
|
||||
required (full autonomy).
|
||||
|
||||
---
|
||||
|
||||
## Grill complete
|
||||
|
||||
The plan proceeds with the 3 critical fixes and 16 tracked conditions
|
||||
applied to PLAN.md + REQUIREMENTS.md. The binding decisions above are
|
||||
the authoritative grill record. Next: MVP/UX CHECK → SHIP phase 0.
|
||||
Reference in New Issue
Block a user