docs(P00): clarify — v1.28 ambiguities resolved (6 Qs + 5 grounding gaps, D-226..D-231)
---ci--- project: acdl phase: 0 milestone: v1.28 status: clarify ---/ci---
This commit is contained in:
Jon Chery
@@ -1,10 +1,10 @@
|
|||||||
{
|
{
|
||||||
"phase": 0,
|
"phase": 0,
|
||||||
"stage": "specify",
|
"stage": "clarify",
|
||||||
"milestone": "v1.28",
|
"milestone": "v1.28",
|
||||||
"phase_role": "pre_execution",
|
"phase_role": "pre_execution",
|
||||||
"attempts": 0,
|
"attempts": 0,
|
||||||
"updated_at": "2026-08-19T20:00:00Z",
|
"updated_at": "2026-08-19T20:10:00Z",
|
||||||
"project": "acdl",
|
"project": "acdl",
|
||||||
"projects": ["acdl", "nova-blockchain-exchange"],
|
"projects": ["acdl", "nova-blockchain-exchange"],
|
||||||
"active_milestone": "v1.28",
|
"active_milestone": "v1.28",
|
||||||
@@ -12,5 +12,6 @@
|
|||||||
"phase_branch": "phase/00-pre-execution",
|
"phase_branch": "phase/00-pre-execution",
|
||||||
"tag_line": "v1.27.x",
|
"tag_line": "v1.27.x",
|
||||||
"previous_milestone": {"milestone": "v1.27", "tag": "v1.26.3", "status": "complete"},
|
"previous_milestone": {"milestone": "v1.27", "tag": "v1.26.3", "status": "complete"},
|
||||||
"notes": "v1.28 SPECIFY. Re-mapped from source spec (v1.18 framing) to v1.28. ID allocations: REQ-323..353, CAP-033..038, INV-12..17, D-226..231. kj engine mapped to kyverno-json (D-227). Requirements validated in REQUIREMENTS.md. Next: CLARIFY."
|
"decisions": ["D-226", "D-227", "D-228", "D-229", "D-230", "D-231"],
|
||||||
|
"notes": "v1.28 CLARIFY. 6 open Qs + 5 grounding gaps resolved at full autonomy. D-226..D-231 authored (confidence >= 0.80). kj mapped to kyverno-json (D-227). Cognito-drop reframed as greenfield (G3). CAP-033..038, INV-12..17, REQ-323..353 allocated. Next: RESEARCH."
|
||||||
}
|
}
|
||||||
+232
-139
@@ -1,183 +1,276 @@
|
|||||||
# CLARIFY — v1.27 PO State Catalog & Ciagent Compression
|
# CLARIFY — v1.28 CLI Canonicalization + Identity Layer
|
||||||
|
|
||||||
> **Autonomy:** full. Auto-resolution with assumption logging per
|
> **Autonomy:** full. Auto-resolution with assumption logging per
|
||||||
> `config.autonomy.level: "full"`. No human escalation unless
|
> `config.autonomy.level: "full"`. No human escalation unless confidence
|
||||||
> confidence < 0.60. The prior conversation resolved all material
|
> < 0.60. The user-approved re-mapping plan (v1.18 spec → v1.28) resolved
|
||||||
> ambiguities (4 user-answered questions). This file records the
|
> the headline discrepancy. This file records the remaining ambiguities
|
||||||
> assumptions for the v1.27 record.
|
> and the grounding gaps surfaced in pre-flight.
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## Method
|
## Method
|
||||||
|
|
||||||
The clarify stage identifies ambiguities in the v1.27 specification
|
The clarify stage identifies ambiguities in the v1.28 specification and
|
||||||
and resolves them at full autonomy. The v1.27 spec is the user-approved
|
resolves them at full autonomy. The v1.28 spec is the user-provided
|
||||||
plan from the prior conversation + the STATE.md design locked by 4
|
"Universal Feature Specification — v1.18 CLI Canonicalization + Identity
|
||||||
question answers. Each ambiguity gets a decision ID (D-214+; continuing
|
Layer," re-mapped to v1.28 (milestone number, tag line, and all
|
||||||
from the v1.26 decisions D-200..D-213), a resolution, a confidence
|
ID namespaces) per the user-approved plan. Each ambiguity gets a
|
||||||
score, and a rationale.
|
decision ID (D-226+, continuing from v1.27's D-214..D-225), a resolution,
|
||||||
|
a confidence score, and a rationale.
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## Prior-conversation resolutions (already locked, restated for the record)
|
## Prior-conversation resolutions (already locked, restated for the record)
|
||||||
|
|
||||||
These were resolved by user-answered questions in the conversation that
|
These were resolved by the user-approved re-mapping plan in the
|
||||||
spawned v1.27. They are load-bearing for v1.27 execution and cited
|
conversation that spawned v1.28. They are load-bearing for v1.28
|
||||||
here so the v1.27 record is self-contained.
|
execution.
|
||||||
|
|
||||||
### Q-P1 — What should the new PO-reference file catalog?
|
### Q-P1 — The source spec is titled "v1.18" but v1.18 already shipped. What milestone is this?
|
||||||
|
|
||||||
**Resolution:** Capability catalog (what the system can do today).
|
**Resolution:** Re-map the spec's *content* (CLI Canonicalization +
|
||||||
**Confidence:** 1.0 (user-confirmed). **Decision:** D-214.
|
Identity Layer) to **v1.28**, the next milestone after v1.27 (complete).
|
||||||
|
Tags run on the **v1.27.x** line (P0 = `v1.27.0`). Milestone branch:
|
||||||
|
`milestone/v1.28-cli-identity`.
|
||||||
|
**Confidence:** 1.0 (user-confirmed — "Re-map to v1.28"). **Decision:** n/a (milestone identity, not a D-ID).
|
||||||
|
|
||||||
### Q-P2 — How should the new file relate to CAPABILITY_INVENTORY.md?
|
### Q-P2 — The spec's "locked inputs" (D-NEW-26, kj engine, Nova-idp, INV-63/64/65, CAP-025..030, REQ-001..031) don't exist in the repo. How to handle?
|
||||||
|
|
||||||
**Resolution:** Call it `STATE.md`. PO-owned, ciagent-updated after
|
**Resolution:** Author them fresh in this milestone's CLARIFY/RESEARCH as
|
||||||
milestone implementation. CAPABILITY_INVENTORY.md is archived.
|
**D-226..D-231, INV-12..17, CAP-033..038, REQ-323..353**. The `kj` engine
|
||||||
**Confidence:** 1.0 (user-confirmed). **Decision:** D-215.
|
is mapped to the existing **kyverno-json** engine (INV-4 swappable) — no
|
||||||
|
new engine is built. CAP/INV/REQ IDs are re-allocated to avoid collisions
|
||||||
|
with shipped history (CAP-025..032 and INV-1..11 are blockchain/pilot).
|
||||||
|
**Confidence:** 1.0 (user-confirmed — "Re-map to v1.28"). **Decision:** D-227 (kj→kyverno-json), plus the ID-allocation block in REQUIREMENTS.md.
|
||||||
|
|
||||||
### Q-P3 — Where should the file live, and who owns it?
|
### Q-P3 — The spec claims a "Cognito drop." No Cognito exists in the repo. What does NFR-5 mean?
|
||||||
|
|
||||||
**Resolution:** Owned by the PO, updated by ciagent after the milestone
|
**Resolution:** NFR-5 (no AWS-managed identity in the path) is a
|
||||||
is implemented with additives.
|
**greenfield constraint**, not a migration. Nova-idp is built fresh; no
|
||||||
**Confidence:** 1.0 (user-confirmed). **Decision:** D-216.
|
Cognito/IAM Identity Center is *introduced*. The "drop" framing is
|
||||||
|
aspirational language from the source spec, not a literal removal.
|
||||||
### Q-P4 — How should "additive when new features are implemented" be enforced?
|
**Confidence:** 1.0. **Decision:** D-226 (recorded below; NFR-5 restated
|
||||||
|
as a greenfield constraint in INV-15).
|
||||||
**Resolution:** On the last phase / milestone ship (the P-final Wave 3
|
|
||||||
"milestone ship" step). No regression-gate check in this pass.
|
|
||||||
**Confidence:** 1.0 (user-confirmed). **Decision:** D-217.
|
|
||||||
|
|
||||||
### Q-P5 — Should the initial STATE.md backfill all shipped capabilities through v1.26?
|
|
||||||
|
|
||||||
**Resolution:** Backfill all shipped capabilities through v1.26
|
|
||||||
(compressed one-liners for v1.1–v1.24; full entries for v1.25 + v1.26).
|
|
||||||
**Confidence:** 1.0 (user-confirmed). **Decision:** D-218.
|
|
||||||
|
|
||||||
### Q-P6 — Should the v1.26 pre-execution artifacts (CLARIFY, GRILL, IDEATE, RESEARCH) be archived?
|
|
||||||
|
|
||||||
**Resolution:** Archive all 4 to `.ciagent/archive/` with `-v1.26`
|
|
||||||
suffixes. The next milestone's P0 writes fresh versions. Decisions are
|
|
||||||
already folded into PROJECT.md load-bearing decisions + PLAN.md
|
|
||||||
binding revisions.
|
|
||||||
**Confidence:** 1.0 (user-confirmed). **Decision:** D-219.
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## Ambiguities + Resolutions (this CLARIFY pass)
|
## Open questions from the spec's §7 (auto-resolved at full autonomy)
|
||||||
|
|
||||||
### Q1 — Is v1.27 a feature milestone or an NFR milestone?
|
### Q1 — Argon2 native dependency in Lambda runtime
|
||||||
|
|
||||||
**Ambiguity:** v1.27 authors `STATE.md` (a new file/capability for the
|
`argon2-cffi` has a C extension that may not build cleanly in the Lambda
|
||||||
PO) and archives 11 files. Does the new-file authoring count as `feat:`
|
Python 3.12 runtime.
|
||||||
(making this a feature milestone, tags on v1.26.x with progressive
|
|
||||||
patches) or `docs:`/`chore:` (NFR milestone, same tag behavior but
|
|
||||||
subject to the NFR purity gate)?
|
|
||||||
|
|
||||||
**Resolution:** NFR milestone. `STATE.md` is documentation (a catalog of
|
**Resolution (D-228):** Use `argon2-cffi` with bundled wheels; if the
|
||||||
existing capabilities), not a new platform capability. The archive moves
|
extension fails to load, fall back to the pure-Python implementation. If
|
||||||
are `chore:` (file relocation, lossless). No code, no schema, no
|
both fail, document the Fargate migration path for the auth Lambda.
|
||||||
platform behavior change. Tags run on the v1.26.x patch line:
|
CAP-036 covers end-to-end verification.
|
||||||
`v1.26.0` (P0) → `v1.26.1..v1.26.3` (P1..P3). The final phase's patch
|
**Confidence:** 0.85. **Rationale:** Bundled wheels are the standard
|
||||||
(`v1.26.3`) IS the milestone release.
|
workaround for Lambda native deps; the pure-Python fallback is a safe
|
||||||
|
degradation. Fargate is the escape hatch if Lambda's runtime is
|
||||||
|
fundamentally incompatible. RESEARCH will validate wheel availability for
|
||||||
|
Python 3.12 + the Lambda execution environment.
|
||||||
|
**Impact if wrong:** Auth Lambda migrates to Fargate, adding ~1 week to P2.
|
||||||
|
|
||||||
**Confidence:** 0.95. **Decision:** D-220.
|
### Q2 — PAT revocation propagation latency
|
||||||
|
|
||||||
### Q2 — Where does the consumer-side archive (nova-blockchain-exchange/ROADMAP.md) land?
|
The 60-second SLO (NFR-4) depends on whether the token-vend Lambda reads
|
||||||
|
PAT revocation state from DynamoDB on every request (eventually
|
||||||
|
consistent reads) or via a cached/denylist mechanism.
|
||||||
|
|
||||||
**Ambiguity:** The platform archive convention is
|
**Resolution (D-229):** Read-on-every-request with strongly consistent
|
||||||
`.ciagent/archive/<file>-<milestone>.md`. The consumer subproject
|
reads on the PAT hash table. Cost is acceptable given expected request
|
||||||
(`nova-blockchain-exchange/`) has no `archive/` subdirectory. Does the
|
volume (token vending is not a hot path — it precedes a deploy, not every
|
||||||
consumer ROADMAP archive at `.ciagent/archive/` (platform-side, mixed)
|
request). REV-351 verifies the SLO in CI.
|
||||||
or `.ciagent/nova-blockchain-exchange/archive/` (consumer-side, new
|
**Confidence:** 0.90. **Rationale:** Strongly consistent DynamoDB reads
|
||||||
subdir)?
|
have single-digit-ms latency at expected volume; the 60s SLO has >10x
|
||||||
|
headroom. A cache layer adds invalidation complexity that the SLO does
|
||||||
|
not require.
|
||||||
|
**Impact if wrong:** If read latency exceeds 60s under load, introduce a
|
||||||
|
DynamoDB TTL + cache layer; SLO must be re-verified.
|
||||||
|
|
||||||
**Resolution:** Consumer-side. Create
|
### Q3 — JWKS endpoint: Lambda function URL vs. API Gateway
|
||||||
`.ciagent/nova-blockchain-exchange/archive/` and relocate to
|
|
||||||
`ROADMAP-v1.26.md`. This preserves the per-project path convention
|
|
||||||
(multi-project mode: `.ciagent/<slug>/` paths). The platform archive
|
|
||||||
directory is not mixed with consumer archives.
|
|
||||||
|
|
||||||
**Confidence:** 0.92. **Decision:** D-221.
|
A function URL is simpler and cheaper but lacks throttling, WAF, and
|
||||||
|
custom domains out of the box.
|
||||||
|
|
||||||
### Q3 — Does archiving CLARIFY/GRILL/IDEATE/RESEARCH lose the "how v1.26 was specified" traceability?
|
**Resolution (D-230):** Start with a Lambda function URL behind a custom
|
||||||
|
domain; rate limiting configured at the DNS/CDN layer. API Gateway
|
||||||
|
migration deferred to v1.19+ if throttling requirements grow.
|
||||||
|
**Confidence:** 0.80. **Rationale:** The JWKS endpoint is public-key
|
||||||
|
only (no secrets); the threat surface is low. Function URL + CDN rate-
|
||||||
|
limiting covers the v1.28 volume. API Gateway is over-engineering until
|
||||||
|
traffic patterns are known.
|
||||||
|
**Impact if wrong:** If throttling becomes a requirement, API Gateway
|
||||||
|
migration adds ~3-5 days.
|
||||||
|
|
||||||
**Ambiguity:** The pre-execution artifacts document the v1.26 decision
|
### Q4 — Mode resolver precedence with invalid `NOVA_CLIENT_MODE` value
|
||||||
path. Archiving them moves them out of active context. Is the
|
|
||||||
traceability preserved?
|
|
||||||
|
|
||||||
**Resolution:** Yes. Three layers preserve it: (1) the archive files
|
What happens if the env var is set to something other than `agent` or
|
||||||
are byte-identical relocations inside `.ciagent/archive/` (reachable by
|
`interactive` (e.g., `NOVA_CLIENT_MODE=auto`)?
|
||||||
agents + git history); (2) the decisions D-200..D-213 are folded into
|
|
||||||
`PROJECT.md` load-bearing decisions (the durable record); (3) git
|
|
||||||
history at the v1.26 commits preserves the authoritative state. The
|
|
||||||
active-context reduction is the point — v1.26 is shipped; the next P0
|
|
||||||
writes fresh CLARIFY/GRILL/IDEATE/RESEARCH.
|
|
||||||
|
|
||||||
**Confidence:** 0.95. **Decision:** D-222.
|
**Resolution (D-226):** Invalid env var values are ignored, falling
|
||||||
|
through to credential type. A warning is logged. Behavior is documented
|
||||||
|
in the `nova-cli` README. This is a sub-clause of the mode-resolution
|
||||||
|
priority decision.
|
||||||
|
**Confidence:** 0.90. **Rationale:** Ignoring + warning is the least
|
||||||
|
surprising behavior for an operator debugging mode issues. Failing hard
|
||||||
|
would block legitimate workflows that set a stale/typo'd env var.
|
||||||
|
**Impact if wrong:** Operators debugging mode issues may be confused;
|
||||||
|
non-blocking.
|
||||||
|
|
||||||
### Q4 — Should IAM_POLICY.md be archived (it predates v1.26 and is dated v1.11)?
|
### Q5 — Service-account PAT vs. developer PAT in the same session
|
||||||
|
|
||||||
**Ambiguity:** `IAM_POLICY.md` is dated v1.11 (2026-07-28). It predates
|
What if both credential types are available (e.g., a developer explicitly
|
||||||
v1.26 by 5 milestones. The D-207 future key-split (P1+ R-3 in
|
exports a service-account PAT)?
|
||||||
REVIEW-AUDIT-P05) is pending. Archive or keep?
|
|
||||||
|
|
||||||
**Resolution:** Keep active. `IAM_POLICY.md` is a live baseline —
|
**Resolution (D-226):** The most recently acquired credential wins.
|
||||||
referenced by the regression gate
|
Documented in `nova auth login` output. The credential type is what
|
||||||
(`tests/test_iam_policy_baseline.py`), enforced by a managed policy on
|
drives mode resolution (INV-14), so the operator sees which mode was
|
||||||
account `581513795199`, and the D-207 key-split is a pending future-
|
selected and why.
|
||||||
hardening item. It is not stale; it is a baseline that grows when
|
**Confidence:** 0.85. **Rationale:** "Most recent wins" is the simplest
|
||||||
grants change. The v1.11 date reflects the last grant addition, not
|
deterministic rule that matches operator mental models of "I just logged
|
||||||
staleness.
|
in as X." The audit event records the winning credential type, so the
|
||||||
|
selection is traceable.
|
||||||
|
**Impact if wrong:** Mode selection may surprise the operator; non-
|
||||||
|
blocking, but `nova auth status` must make the active credential explicit.
|
||||||
|
|
||||||
**Confidence:** 0.90. **Decision:** D-223.
|
### Q6 — ABAC policy ownership and versioning
|
||||||
|
|
||||||
### Q5 — Should REGRESSION_REPORT.{json,md} be refreshed as part of v1.27?
|
`platform/abac/token-vend.policy` is referenced, but who owns changes?
|
||||||
|
How are policy versions tracked in audit?
|
||||||
|
|
||||||
**Ambiguity:** Both files are dated 2026-08-01 (v1.10 Phase 52), show
|
**Resolution (D-231):** Policy changes require PR review; the policy
|
||||||
CAP-025 absent, and mark live-aws CAPs "Skipped" (state bucket absent
|
version (git SHA) is recorded in every token-vend audit event. Owner:
|
||||||
pre-v1.26 re-bootstrap). They are stale. Should v1.27 refresh them?
|
Platform Security. The policy file lives in the platform repo at
|
||||||
|
`platform/abac/token-vend.policy` and is reviewed like any other
|
||||||
**Resolution:** No. Both files are machine-managed — written by
|
production config.
|
||||||
`core/regression_verify.py:704-705` on every `run_regression.sh` run.
|
**Confidence:** 0.90. **Rationale:** Git SHA is the natural version
|
||||||
They regenerate on the next regression run. v1.27 is docs/chore only
|
identifier for a repo-resident policy; recording it in the audit event
|
||||||
(no code); touching machine-managed files by hand creates a drift
|
makes every allow/deny decision reconstructable to the exact policy text.
|
||||||
source. The stale state is honest (the last gate run was v1.10; the
|
**Impact if wrong:** Untracked policy changes could lead to unexpected
|
||||||
next run regenerates). The STATE.md Domain 7 row "Regression gate"
|
allow/deny decisions in production, undermining audit defensibility.
|
||||||
notes the current CAP range (CAP-001..025).
|
|
||||||
|
|
||||||
**Confidence:** 0.88. **Decision:** D-224.
|
|
||||||
|
|
||||||
### Q6 — Does PROJECT.md get the v1.26 phase-status fix in v1.27 P1 or P2?
|
|
||||||
|
|
||||||
**Ambiguity:** The plan splits work into P1 (author + archive) and P2
|
|
||||||
(fix stale + wire). The PROJECT.md phase-status fix (P3/P4/P5 pending
|
|
||||||
→ complete) is a "fix stale" item. P1 or P2?
|
|
||||||
|
|
||||||
**Resolution:** P2. P1 is the additive authoring + lossless archive
|
|
||||||
moves. P2 is the corrections to kept files + the ship-discipline wiring.
|
|
||||||
This keeps P1 a pure-additive, no-edit phase (easier review + audit) and
|
|
||||||
P2 the correction phase. The PROJECT.md fix is a correction; P2.
|
|
||||||
|
|
||||||
**Confidence:** 0.85. **Decision:** D-225.
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## Summary
|
## Grounding gaps surfaced in pre-flight (auto-resolved)
|
||||||
|
|
||||||
6 prior-conversation resolutions (D-214..D-219, all user-confirmed)
|
### G1 — The `kj` engine does not exist; the spec treats it as locked.
|
||||||
+ 6 new ambiguities (D-220..D-225, all auto-resolved at full autonomy,
|
|
||||||
confidence ≥ 0.60). 0 escalations.
|
|
||||||
|
|
||||||
**Key decisions:**
|
**Resolution (D-227):** The token-vend Lambda uses the existing
|
||||||
- D-220: v1.27 is an NFR milestone (tags on v1.26.x; final patch is the
|
**kyverno-json** engine (INV-4 swappable) as the ABAC evaluator. The
|
||||||
milestone release).
|
policy at `platform/abac/token-vend.policy` is a kyverno-json policy.
|
||||||
- D-221: Consumer archives land in `.ciagent/nova-blockchain-exchange/archive/`.
|
No new `kj` engine is built in v1.28. If a distinct `kj` engine is
|
||||||
- D-222: Archiving pre-execution artifacts preserves traceability
|
desired later, it is a separate research spike (not this milestone).
|
||||||
(archive files + PROJECT.md load-bearing decisions + git history).
|
**Confidence:** 0.95. **Rationale:** The repo already has a swappable
|
||||||
- D-223: IAM_POLICY.md stays active (live baseline, test-enforced,
|
policy engine (INV-4) implemented as kyverno-json. Building a second
|
||||||
D-207 pending).
|
engine to do the same job violates the swappable-engine invariant's
|
||||||
- D-224: REGRESSION_REPORT.{json,md} regenerate on next
|
spirit. kyverno-json's `evaluate` semantics cover the spec's ABAC needs
|
||||||
`run_regression.sh` (machine-managed; v1.27 is docs/chore only).
|
(subject, claims, resource, environment → allow/deny).
|
||||||
- D-225: PROJECT.md phase-status fix is P2 (correction phase), not P1
|
**Impact if wrong:** If the user actually wants a new `kj` engine, v1.28
|
||||||
(additive phase).
|
scope expands significantly (engine design + implementation + migration).
|
||||||
|
This was flagged as caveat #3 in the approved plan; the recommended path
|
||||||
|
(kyverno-json) is locked here.
|
||||||
|
|
||||||
|
### G2 — The spec's INV-18..21, INV-34, INV-63/64/65 don't exist.
|
||||||
|
|
||||||
|
**Resolution:** Re-allocated as **INV-12..INV-17** (see REQUIREMENTS.md
|
||||||
|
§v1.28 Invariants). The 1:1 mapping:
|
||||||
|
- INV-63 (mode observability) → INV-12
|
||||||
|
- INV-64 (mode determinism) → INV-13
|
||||||
|
- INV-65 (credential type encodes role) → INV-14
|
||||||
|
- INV-18..21 (attestation invariants) → INV-15 (no AWS-managed identity),
|
||||||
|
INV-16 (password storage), INV-17 (ABAC discipline). The spec's
|
||||||
|
attestation invariants INV-18..21 are partially covered by existing
|
||||||
|
invariants (INV-6 immutable audit) + INV-17; the JWS-from-PAT behavior
|
||||||
|
(REQ-332) is a requirement, not a separate invariant, in this mapping.
|
||||||
|
- INV-34 (MFA enforcement) → deferred to v1.21+ (out of scope per §2.2);
|
||||||
|
no INV allocated in v1.28.
|
||||||
|
**Confidence:** 0.85. **Rationale:** The mapping preserves the spec's
|
||||||
|
intent without colliding with the repo's INV-1..11. INV-34 (MFA) is
|
||||||
|
explicitly deferred per the spec's own §2.2 out-of-scope table.
|
||||||
|
**Impact if wrong:** If the user wants the exact INV-18..21 semantics as
|
||||||
|
separate invariants, INV-12..17 can be re-numbered; non-blocking.
|
||||||
|
|
||||||
|
### G3 — The spec's CAP-025..030 collide with blockchain/pilot CAPs.
|
||||||
|
|
||||||
|
**Resolution:** Re-allocated as **CAP-033..CAP-038** (see REQUIREMENTS.md
|
||||||
|
§v1.28 + REQ-352). The 1:1 mapping:
|
||||||
|
- CAP-025 (CLI subcommand surface) → CAP-033
|
||||||
|
- CAP-026 (subcommand delegates to core/) → CAP-034
|
||||||
|
- CAP-027 (layer matches wheel) → CAP-035
|
||||||
|
- CAP-028 (Nova-idp auth flow) → CAP-036
|
||||||
|
- CAP-029 (token-vend signs via KMS) → CAP-037
|
||||||
|
- CAP-030 (PAT issuance + revocation) → CAP-038
|
||||||
|
**Confidence:** 1.0. **Rationale:** Existing CAP-025..032 are
|
||||||
|
blockchain/pilot capabilities (STATE.md); re-use would corrupt the
|
||||||
|
capability registry. The re-allocated IDs are the next available.
|
||||||
|
**Impact if wrong:** None — this is a numbering decision, not a semantic
|
||||||
|
one.
|
||||||
|
|
||||||
|
### G4 — The spec's REQ-001..031 collide / don't exist.
|
||||||
|
|
||||||
|
**Resolution:** Re-allocated as **REQ-323..REQ-353** (1:1 with the spec's
|
||||||
|
REQ-001..031). Full text in REQUIREMENTS.md §v1.28. Max existing REQ =
|
||||||
|
REQ-322.
|
||||||
|
**Confidence:** 1.0. **Rationale:** Same as G3 — avoid collision, use
|
||||||
|
next available range.
|
||||||
|
|
||||||
|
### G5 — `platform/abac/`, `nova/` subcommand dir, `nova-idp-*` Lambdas don't exist.
|
||||||
|
|
||||||
|
**Resolution:** These are **greenfield deliverables** of v1.28 execution
|
||||||
|
phases, not pre-existing "locked architectures." RESEARCH will design
|
||||||
|
them; PLAN will sequence them; EXECUTE will build them. The spec's
|
||||||
|
"Operating Principle 1" (incremental delivery) is honored — v1.28 is
|
||||||
|
net-new work.
|
||||||
|
**Confidence:** 1.0. **Rationale:** The spec itself describes these as
|
||||||
|
new ("introducing Nova-idp"). The mis-framing was in calling them
|
||||||
|
"locked" — they are locked in *scope*, not in *prior existence*.
|
||||||
|
**Impact if wrong:** None — this is a framing correction.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Decision ledger (v1.28 — D-226..D-231)
|
||||||
|
|
||||||
|
| ID | Title | Confidence | Load-bearing for |
|
||||||
|
|----|-------|------------|------------------|
|
||||||
|
| D-226 | Mode resolution priority + invalid-env + dual-credential | 0.90 | REQ-327, INV-12, INV-13, INV-14 |
|
||||||
|
| D-227 | ABAC engine = kyverno-json (no `kj` engine built) | 0.95 | REQ-336, REQ-339, INV-17, NFR-9 |
|
||||||
|
| D-228 | Argon2id in Lambda: bundled wheels + pure-Python fallback + Fargate path | 0.85 | REQ-333, REQ-334, INV-16, NFR-8 |
|
||||||
|
| D-229 | PAT revocation: strongly-consistent DDB read-on-every-request, 60s SLO | 0.90 | REQ-342, REQ-343, REQ-351, NFR-4 |
|
||||||
|
| D-230 | JWKS endpoint: Lambda function URL + custom domain + CDN rate-limit | 0.80 | REQ-338, NFR-5 |
|
||||||
|
| D-231 | ABAC policy ownership: Platform Security, git SHA in audit | 0.90 | REQ-339, NFR-9 |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Assumptions logged (full autonomy, no human escalation)
|
||||||
|
|
||||||
|
1. **CodeArtifact is provisionable** in AWS account `581513795199` (the
|
||||||
|
pilot account). RESEARCH will confirm IAM permissions + repository
|
||||||
|
creation. If not, v1.28 falls back to a private PyPI server or a
|
||||||
|
Gitea-hosted wheel index; the CLI subcommand surface (REQ-324) and
|
||||||
|
identity layer (REQ-333+) are unaffected.
|
||||||
|
2. **Python 3.12** is the target runtime for both the CLI wheel and the
|
||||||
|
Lambda functions (spec §4 REQ-004.3). The repo's current Python
|
||||||
|
version will be confirmed in RESEARCH; if it differs, the CLI pins
|
||||||
|
3.12 and Lambda uses the 3.12 runtime regardless.
|
||||||
|
3. **KMS asymmetric signing** (RSA-2048 or ECDSA P-256) is available in
|
||||||
|
the target account. RESEARCH will confirm. If only symmetric KMS is
|
||||||
|
available, the token-vend Lambda uses symmetric signing + a public-key
|
||||||
|
publication step (less ideal, but functional); INV-15 is unaffected.
|
||||||
|
4. **The Forge action** (REQ-326) is the existing `nova cli-action`
|
||||||
|
pattern, extended to both GitHub and Gitea marketplaces. The repo's
|
||||||
|
current Forge/Gitea workflow conventions (`.gitea/workflows/`,
|
||||||
|
`deploy.yml@v1.25`) are the baseline.
|
||||||
|
5. **MFA/TOTP** code path ships in v1.28 (per spec §2.2) but enforcement
|
||||||
|
for prod/dr is deferred to v1.21+. This is a doc/test-only path in
|
||||||
|
v1.28 — no enforcement gate.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## CLARIFY complete
|
||||||
|
|
||||||
|
All material ambiguities resolved at full autonomy (6 open questions +
|
||||||
|
5 grounding gaps → D-226..D-231, confidence ≥ 0.80). No human escalation
|
||||||
|
triggered (all confidences ≥ 0.60 threshold). REQUIREMENTS.md updated
|
||||||
|
with the decision ledger + invariants. Next: RESEARCH.
|
||||||
Reference in New Issue
Block a user