merge(milestone): v1.27 PO State Catalog & Ciagent Compression to main (release v1.26.3)
v1.27 NFR milestone complete. Authored .ciagent/STATE.md (PO-facing capability catalog) + compressed .ciagent/ by archiving 8 outdated files + fixed v1.26 phase-status in PROJECT.md/ROADMAP.md + wired STATE.md into the P-final ship discipline. Tags: v1.26.0 (P0) → v1.26.1 (P1) → v1.26.2 (P2) → v1.26.3 (P3 = milestone release). ---ci--- project: acdl phase: 3 milestone: v1.27 status: complete ---ci---
This commit is contained in:
Jon Chery
@@ -563,7 +563,7 @@ audit record (D-204).
|
||||
|
||||
The full evidence (every ARN, the confidence JSON, the Decision Ledger
|
||||
rows, the module-completeness gaps the live apply uncovered) is in
|
||||
`.ciagent/P4-PILOT-RUN-EVIDENCE.md`.
|
||||
`.ciagent/archive/P4-PILOT-RUN-EVIDENCE-v1.26.md` (archived v1.27).
|
||||
|
||||
### §12.9 — Secret Rotation (v1.26 P3 W7, SPEC §5.9 — current)
|
||||
|
||||
|
||||
+12
-42
@@ -1,49 +1,19 @@
|
||||
{
|
||||
"phase": 5,
|
||||
"phase": 3,
|
||||
"stage": "complete",
|
||||
"milestone": "v1.26",
|
||||
"milestone": "v1.27",
|
||||
"phase_role": "final",
|
||||
"attempts": 0,
|
||||
"updated_at": "2026-08-19T04:00:00Z",
|
||||
"updated_at": "2026-08-19T05:30:00Z",
|
||||
"project": "acdl",
|
||||
"projects": [
|
||||
"acdl",
|
||||
"nova-blockchain-exchange"
|
||||
],
|
||||
"active_milestone": "v1.26",
|
||||
"milestone_branch": "milestone/v1.26-pilot-activation",
|
||||
"phase_branch": "phase/05-final-review-ship",
|
||||
"tag_line": "v1.25.x",
|
||||
"current_phase": {
|
||||
"phase": 5,
|
||||
"tag": "v1.25.5",
|
||||
"status": "complete"
|
||||
},
|
||||
"previous_phase": {
|
||||
"phase": 4,
|
||||
"tag": "v1.25.4",
|
||||
"status": "complete"
|
||||
},
|
||||
"requirements": [
|
||||
"REQ-310",
|
||||
"REQ-311",
|
||||
"REQ-312",
|
||||
"REQ-313",
|
||||
"REQ-314",
|
||||
"REQ-315",
|
||||
"REQ-316",
|
||||
"REQ-317",
|
||||
"REQ-318",
|
||||
"REQ-319",
|
||||
"REQ-320",
|
||||
"REQ-321",
|
||||
"REQ-322"
|
||||
],
|
||||
"projects": ["acdl", "nova-blockchain-exchange"],
|
||||
"active_milestone": "v1.27",
|
||||
"milestone_branch": "milestone/v1.27-po-state-catalog",
|
||||
"phase_branch": "phase/03-final-review-ship",
|
||||
"tag_line": "v1.26.x",
|
||||
"current_phase": {"phase": 3, "tag": "v1.26.3", "status": "complete"},
|
||||
"previous_phase": {"phase": 2, "tag": "v1.26.2", "status": "complete"},
|
||||
"milestone_complete": true,
|
||||
"milestone_release": {
|
||||
"tag": "v1.25.5",
|
||||
"release_id": 791,
|
||||
"url": "https://git.cloudinit.dev/continuous-intelligence/acdl/releases/tag/v1.25.5"
|
||||
},
|
||||
"notes": "v1.26 COMPLETE. 13 requirements (REQ-310..322). 5 phases. Live apply against 581513795199 succeeded. Confidence 0.800 pass. fact_decision.outcome=succeeded (REQ-317). Hash chain valid. Milestone merged to main. Next run starts a new milestone."
|
||||
"milestone_release": {"tag": "v1.26.3", "type": "nfr"},
|
||||
"notes": "v1.27 COMPLETE. NFR milestone (PO State Catalog & Ciagent Compression). 3 phases. STATE.md authored (32 CAPs, 11 invariants, 10 domains). 8 files archived (7 platform + 1 consumer). PROJECT.md + ROADMAP.md v1.26 phase-status fixed. STATE.md wired into P-final ship discipline. Review: 0 P0. Audit: reconstruction PASS, file discipline CLEAN, branch hygiene CLEAN, commit discipline CLEAN (13/13 ---ci--- blocks). Next run starts a new milestone."
|
||||
}
|
||||
+126
-169
@@ -1,226 +1,183 @@
|
||||
# CLARIFY — v1.26 Live Pilot Estate Activation
|
||||
# CLARIFY — v1.27 PO State Catalog & Ciagent Compression
|
||||
|
||||
> **Autonomy:** full. Auto-resolution with assumption logging per
|
||||
> `config.autonomy.level: "full"`. No human escalation unless
|
||||
> confidence < 0.60 (threshold `config.autonomy.decision_confidence_threshold`).
|
||||
> 10 ambiguities identified; all resolved (confidence ≥ 0.60).
|
||||
> confidence < 0.60. The prior conversation resolved all material
|
||||
> ambiguities (4 user-answered questions). This file records the
|
||||
> assumptions for the v1.27 record.
|
||||
|
||||
---
|
||||
|
||||
## Method
|
||||
|
||||
The clarify stage identifies ambiguities in the v1.26 specification
|
||||
(PROJECT.md, REQUIREMENTS.md, ROADMAP.md) and resolves them at full
|
||||
autonomy. Each ambiguity gets a decision ID (D-200+; continuing from
|
||||
the v1.26 SPECIFY decisions D-200..D-205), a resolution, a confidence
|
||||
score, and a rationale. Resolutions update PROJECT.md + REQUIREMENTS.md
|
||||
+ ROADMAP.md as needed.
|
||||
The clarify stage identifies ambiguities in the v1.27 specification
|
||||
and resolves them at full autonomy. The v1.27 spec is the user-approved
|
||||
plan from the prior conversation + the STATE.md design locked by 4
|
||||
question answers. Each ambiguity gets a decision ID (D-214+; continuing
|
||||
from the v1.26 decisions D-200..D-213), a resolution, a confidence
|
||||
score, and a rationale.
|
||||
|
||||
---
|
||||
|
||||
## Ambiguities + Resolutions
|
||||
## Prior-conversation resolutions (already locked, restated for the record)
|
||||
|
||||
### Q1 — Does the consumer repo's `.ciagent/` live in the platform repo or the consumer repo?
|
||||
These were resolved by user-answered questions in the conversation that
|
||||
spawned v1.27. They are load-bearing for v1.27 execution and cited
|
||||
here so the v1.27 record is self-contained.
|
||||
|
||||
**Ambiguity:** The user said "ciagent should track it as a separate
|
||||
project under this same path." Does "this same path" mean the platform
|
||||
repo's `.ciagent/` directory (multi-project mode per `run.md` Step 0),
|
||||
or a separate `.ciagent/` inside the consumer repo?
|
||||
### Q-P1 — What should the new PO-reference file catalog?
|
||||
|
||||
**Resolution:** The platform repo's `.ciagent/` directory. Multi-project
|
||||
mode: `.ciagent/config.json` `projects[]` includes both `acdl` +
|
||||
`nova-blockchain-exchange`; the consumer's project files
|
||||
(PROJECT.md, REQUIREMENTS.md, ROADMAP.md) live in
|
||||
`.ciagent/nova-blockchain-exchange/`. The consumer *git repo* owns the
|
||||
app code + `contract.yaml` + deploy workflow invocation; the platform
|
||||
repo owns the CIAgent planning artifacts for both projects. This
|
||||
matches `run.md` Step 0 multi-project mode.
|
||||
**Resolution:** Capability catalog (what the system can do today).
|
||||
**Confidence:** 1.0 (user-confirmed). **Decision:** D-214.
|
||||
|
||||
**Confidence:** 0.95. **Decision:** D-206.
|
||||
### Q-P2 — How should the new file relate to CAPABILITY_INVENTORY.md?
|
||||
|
||||
### Q2 — Is the bootstrap `NOVA_AWS_*` key the root key or the spike-runner key?
|
||||
**Resolution:** Call it `STATE.md`. PO-owned, ciagent-updated after
|
||||
milestone implementation. CAPABILITY_INVENTORY.md is archived.
|
||||
**Confidence:** 1.0 (user-confirmed). **Decision:** D-215.
|
||||
|
||||
**Ambiguity:** The bootstrap scripts (post-migration) prefer
|
||||
`NOVA_BOOTSTRAP_AWS_*`, falling back to `NOVA_AWS_*`. The pre-run
|
||||
(A3) succeeded with `NOVA_AWS_*`, creating the S3 bucket + DynamoDB
|
||||
table — which requires root or root-equivalent IAM. Is `NOVA_AWS_*`
|
||||
the root key, or did the bootstrap succeed because the spike-runner
|
||||
policy happens to include S3/DynamoDB create?
|
||||
### Q-P3 — Where should the file live, and who owns it?
|
||||
|
||||
**Resolution:** `NOVA_AWS_*` has root-equivalent permissions (confirmed
|
||||
empirically: the bootstrap created the S3 bucket + DynamoDB table
|
||||
successfully). For the pilot, `NOVA_AWS_*` is the bootstrap key. A
|
||||
future hardening milestone should split this into a dedicated
|
||||
`NOVA_BOOTSTRAP_AWS_*` root key + a least-privilege `NOVA_AWS_*` runner
|
||||
key (the spike-runner pattern). For v1.26, the single key suffices
|
||||
(pilot scope).
|
||||
**Resolution:** Owned by the PO, updated by ciagent after the milestone
|
||||
is implemented with additives.
|
||||
**Confidence:** 1.0 (user-confirmed). **Decision:** D-216.
|
||||
|
||||
**Confidence:** 0.90. **Decision:** D-207.
|
||||
### Q-P4 — How should "additive when new features are implemented" be enforced?
|
||||
|
||||
### Q3 — Which AWS account does the pilot use: `581513795199` (existing) or a dedicated pilot account?
|
||||
**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.
|
||||
|
||||
**Ambiguity:** The user said "assume 581513795199." But the env JSONs
|
||||
all show `account_id: "000000000000"` (placeholder). Does the pilot
|
||||
bind all env JSONs to `581513795199`, or only `dev` (with qa/prod/dr
|
||||
left placeholder until a real multi-account landing zone exists)?
|
||||
### Q-P5 — Should the initial STATE.md backfill all shipped capabilities through v1.26?
|
||||
|
||||
**Resolution:** Bind `dev` to `581513795199` for the pilot
|
||||
(D-203, established in SPECIFY). The `qa`/`prod`/`dr` env JSONs remain
|
||||
placeholder `000000000000` this milestone — the pilot runs in `dev`
|
||||
(autonomous, no HITL gate). Multi-account landing zone (qa/prod/dr on
|
||||
separate accounts) is a future milestone. REQ-319 (env-JSON wiring)
|
||||
updates `dev.json`'s `state_backend.bucket` to
|
||||
`nova-tfstate-581513795199-us-east-1` + `account_id` to `581513795199`;
|
||||
qa/prod/dr get the `state_backend.bucket` update but keep placeholder
|
||||
`account_id` (the pilot-readiness policy REQ-320 blocks apply on
|
||||
placeholder accounts — so qa/prod/dr apply is blocked by design until
|
||||
the accounts are bound).
|
||||
**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.
|
||||
|
||||
**Confidence:** 0.92. **Decision:** D-208.
|
||||
### Q-P6 — Should the v1.26 pre-execution artifacts (CLARIFY, GRILL, IDEATE, RESEARCH) be archived?
|
||||
|
||||
### Q4 — Does "all types of securities" mean all types in v1.26, or equities-only pilot with others deferred?
|
||||
**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.
|
||||
|
||||
**Ambiguity:** The user said "stock market built on homegrown blockchain
|
||||
offering all types of securities." This could mean equities + bonds +
|
||||
derivatives + options all in v1.26, or equities-only pilot with others
|
||||
deferred (the recommended scope from the plan).
|
||||
---
|
||||
|
||||
**Resolution:** Equities-only pilot (D-200, established in SPECIFY).
|
||||
Bonds/derivatives/options have very different settlement models (T+1
|
||||
for equities; T+2 for bonds; derivatives vary; options exercise
|
||||
models). A pilot should demonstrate the Nova platform's policy gates
|
||||
over a real estate — equities (T+1) is the simplest. "All types of
|
||||
securities" is the *product vision*; v1.26 is the *pilot* (equities
|
||||
first). The roadmap documents the deferral.
|
||||
## Ambiguities + Resolutions (this CLARIFY pass)
|
||||
|
||||
**Confidence:** 0.85. **Decision:** D-200 (reaffirmed).
|
||||
### Q1 — Is v1.27 a feature milestone or an NFR milestone?
|
||||
|
||||
### Q5 — Is the homegrown blockchain a real consensus protocol or a minimal PoA ledger?
|
||||
**Ambiguity:** v1.27 authors `STATE.md` (a new file/capability for the
|
||||
PO) and archives 11 files. Does the new-file authoring count as `feat:`
|
||||
(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)?
|
||||
|
||||
**Ambiguity:** "Homegrown blockchain" could mean a full consensus
|
||||
protocol (multi-validator BFT) or a minimal PoA ledger (single
|
||||
validator, append-only).
|
||||
**Resolution:** NFR milestone. `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. Tags run on the v1.26.x patch line:
|
||||
`v1.26.0` (P0) → `v1.26.1..v1.26.3` (P1..P3). The final phase's patch
|
||||
(`v1.26.3`) IS the milestone release.
|
||||
|
||||
**Resolution:** Minimal PoA ledger (D-201, established in SPECIFY).
|
||||
Single validator (config-driven), append-only blocks, SHA-256 hash
|
||||
chain, deterministic block production. Settlement finality = block
|
||||
commit. Multi-validator BFT is a future milestone. The pilot's purpose
|
||||
is to exercise the Nova platform's deploy/policy/attestation gates over
|
||||
a real consumer — the chain needs to be real enough to record
|
||||
transactions, not to solve Byzantine consensus.
|
||||
**Confidence:** 0.95. **Decision:** D-220.
|
||||
|
||||
**Confidence:** 0.88. **Decision:** D-201 (reaffirmed).
|
||||
### Q2 — Where does the consumer-side archive (nova-blockchain-exchange/ROADMAP.md) land?
|
||||
|
||||
### Q6 — Does the pilot's `terraform apply` actually run, or is it `--plan-only`?
|
||||
**Ambiguity:** The platform archive convention is
|
||||
`.ciagent/archive/<file>-<milestone>.md`. The consumer subproject
|
||||
(`nova-blockchain-exchange/`) has no `archive/` subdirectory. Does the
|
||||
consumer ROADMAP archive at `.ciagent/archive/` (platform-side, mixed)
|
||||
or `.ciagent/nova-blockchain-exchange/archive/` (consumer-side, new
|
||||
subdir)?
|
||||
|
||||
**Ambiguity:** The platform's `run_platform.sh` defaults to
|
||||
plan-only (no apply). The `deploy.yml` workflow's `mode` input can be
|
||||
`full` (apply) or `plan-only`. Does the pilot actually `terraform apply`
|
||||
(creating real AWS resources for the blockchain exchange), or does it
|
||||
stop at plan?
|
||||
**Resolution:** Consumer-side. Create
|
||||
`.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.
|
||||
|
||||
**Resolution:** The pilot runs `mode: full` (apply) for `dev` only.
|
||||
The apply creates real AWS resources (ECS for the matching engine,
|
||||
DynamoDB for the ledger, S3 for block storage) in account
|
||||
`581513795199`. `qa`/`prod`/`dr` are blocked by the pilot-readiness
|
||||
policy (REQ-320) until their accounts are bound (D-208). The apply is
|
||||
autonomous for `dev` (no HITL gate; confidence threshold 0.50). The
|
||||
`ai.decision.made` + `attestation.recorded` events land in the Decision
|
||||
Ledger — but `dev` attestation is autonomous (no human approver), so
|
||||
only `ai.decision.made` fires for `dev`.
|
||||
**Confidence:** 0.92. **Decision:** D-221.
|
||||
|
||||
**Confidence:** 0.90. **Decision:** D-209.
|
||||
### Q3 — Does archiving CLARIFY/GRILL/IDEATE/RESEARCH lose the "how v1.26 was specified" traceability?
|
||||
|
||||
### Q7 — What AWS resources does the blockchain exchange contract declare?
|
||||
**Ambiguity:** The pre-execution artifacts document the v1.26 decision
|
||||
path. Archiving them moves them out of active context. Is the
|
||||
traceability preserved?
|
||||
|
||||
**Ambiguity:** The `contract.yaml` declares the exchange's
|
||||
infrastructure. What specific AWS resources? The platform's adapter
|
||||
maps contract infrastructure blocks to Terraform. What stack types
|
||||
does the blockchain exchange use?
|
||||
**Resolution:** Yes. Three layers preserve it: (1) the archive files
|
||||
are byte-identical relocations inside `.ciagent/archive/` (reachable by
|
||||
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.
|
||||
|
||||
**Resolution:** The pilot contract declares 3 infrastructure blocks:
|
||||
(1) `ecs` (Fargate service for the matching engine + settlement
|
||||
service — the platform's existing `microservice` module pattern), (2)
|
||||
`dynamodb` (the ledger table — single-table, PK `block_index`), (3)
|
||||
`s3` (block storage — one object per block, key `blocks/{index}.json`).
|
||||
The adapter's `TYPE_MAP` already covers `aws_ecs_service`,
|
||||
`aws_dynamodb_table`, `aws_s3_bucket` (existing L1 primitives). No new
|
||||
adapter stack types needed for the pilot. The contract's
|
||||
`infrastructure` block references these by module name (`microservice`
|
||||
for ECS, `dynamodb` for the table, `s3` for the bucket).
|
||||
**Confidence:** 0.95. **Decision:** D-222.
|
||||
|
||||
**Confidence:** 0.82. **Decision:** D-210.
|
||||
### Q4 — Should IAM_POLICY.md be archived (it predates v1.26 and is dated v1.11)?
|
||||
|
||||
### Q8 — Does the outcome-backfill emitter (REQ-317) change the PCR schema?
|
||||
**Ambiguity:** `IAM_POLICY.md` is dated v1.11 (2026-07-28). It predates
|
||||
v1.26 by 5 milestones. The D-207 future key-split (P1+ R-3 in
|
||||
REVIEW-AUDIT-P05) is pending. Archive or keep?
|
||||
|
||||
**Ambiguity:** REQ-317 wires `apply.completed`/`apply.failed` →
|
||||
`fact_decision.outcome`. Does this touch the `PolicyCheckResult` schema
|
||||
(PCR) — the v1.25 moat that must not change?
|
||||
**Resolution:** Keep active. `IAM_POLICY.md` is a live baseline —
|
||||
referenced by the regression gate
|
||||
(`tests/test_iam_policy_baseline.py`), enforced by a managed policy on
|
||||
account `581513795199`, and the D-207 key-split is a pending future-
|
||||
hardening item. It is not stale; it is a baseline that grows when
|
||||
grants change. The v1.11 date reflects the last grant addition, not
|
||||
staleness.
|
||||
|
||||
**Resolution:** No. The outcome backfill touches the *metrics cold
|
||||
store* (`fact_decision` table in `metrics/nova_metrics.db`), not the
|
||||
PCR schema. The PCR schema (`schemas/policy_check_result.schema.json`)
|
||||
is unchanged. The backfill reads run-manifest events (not PCRs) and
|
||||
updates the decision's outcome column. This respects the v1.25 hard
|
||||
constraint: "DO NOT change `schemas/policy_check_result.schema.json`."
|
||||
**Confidence:** 0.90. **Decision:** D-223.
|
||||
|
||||
**Confidence:** 0.95. **Decision:** D-211.
|
||||
### Q5 — Should REGRESSION_REPORT.{json,md} be refreshed as part of v1.27?
|
||||
|
||||
### Q9 — Does the consumer repo need its own test suite + CI, or does the platform's CI cover it?
|
||||
**Ambiguity:** Both files are dated 2026-08-01 (v1.10 Phase 52), show
|
||||
CAP-025 absent, and mark live-aws CAPs "Skipped" (state bucket absent
|
||||
pre-v1.26 re-bootstrap). They are stale. Should v1.27 refresh them?
|
||||
|
||||
**Ambiguity:** The consumer repo (`nova-blockchain-exchange`) has app
|
||||
code (blockchain, engine, settlement). Does it run its own tests in
|
||||
its own CI, or does the platform's `platform-test.yml` cover it?
|
||||
**Resolution:** No. Both files are machine-managed — written by
|
||||
`core/regression_verify.py:704-705` on every `run_regression.sh` run.
|
||||
They regenerate on the next regression run. v1.27 is docs/chore only
|
||||
(no code); touching machine-managed files by hand creates a drift
|
||||
source. The stale state is honest (the last gate run was v1.10; the
|
||||
next run regenerates). The STATE.md Domain 7 row "Regression gate"
|
||||
notes the current CAP range (CAP-001..025).
|
||||
|
||||
**Resolution:** The consumer repo runs its own tests in its own CI
|
||||
(`nova-blockchain-exchange/.github/workflows/ci.yml` — lint + pytest on
|
||||
the blockchain/engine/settlement code). The platform's
|
||||
`platform-test.yml` covers the *platform* repo only (it validates
|
||||
contracts against the schema, runs adapter tests, etc.). The consumer
|
||||
repo's `deploy.yml` invocation triggers the platform's deploy workflow
|
||||
(which runs `run_platform.sh`); the platform's policy + attestation
|
||||
gates apply over the consumer's apply. The consumer's unit tests
|
||||
(chain integrity, order matching, settlement) are the consumer's
|
||||
responsibility. REQ-310..312 include consumer-side tests
|
||||
(`test_block.py`, `test_order_book.py`, `test_settlement.py`).
|
||||
**Confidence:** 0.88. **Decision:** D-224.
|
||||
|
||||
**Confidence:** 0.88. **Decision:** D-212.
|
||||
### Q6 — Does PROJECT.md get the v1.26 phase-status fix in v1.27 P1 or P2?
|
||||
|
||||
### Q10 — Is the milestone a feature milestone (tags on v1.25.x) or a major milestone (breaking schema changes)?
|
||||
**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?
|
||||
|
||||
**Ambiguity:** v1.26 introduces a 2nd project (multi-project mode) +
|
||||
new requirements. Does this break any schema (→ major milestone, tags
|
||||
on v1.26.x), or is it a feature milestone (tags on v1.25.x)?
|
||||
**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.
|
||||
|
||||
**Resolution:** Feature milestone. No schema breaks: the PCR schema is
|
||||
unchanged (D-211); the contract schema is unchanged (the consumer
|
||||
contract validates against the existing
|
||||
`schemas/contract.schema.json`); the env JSON gains a real
|
||||
`account_id` (data, not schema). Multi-project mode is a config
|
||||
change (not a schema break). Tags run on the **v1.25.x** patch line:
|
||||
`v1.25.0` (P0) → `v1.25.5` (P5 = milestone release). Per `run.md`
|
||||
versioning logic: "Feature milestone (at least one feat phase):
|
||||
progressive patches per phase. The final phase's patch IS the milestone
|
||||
release. No separate minor tag."
|
||||
|
||||
**Confidence:** 0.92. **Decision:** D-213.
|
||||
**Confidence:** 0.85. **Decision:** D-225.
|
||||
|
||||
---
|
||||
|
||||
## Summary
|
||||
|
||||
10 ambiguities identified; all auto-resolved at full autonomy
|
||||
(confidence ≥ 0.60). 8 new decisions (D-206..D-213) + 3 reaffirmed
|
||||
from SPECIFY (D-200, D-201, D-203). 0 escalations (all ≥ 0.60). The
|
||||
resolutions are recorded in this file + reflected in PROJECT.md /
|
||||
REQUIREMENTS.md / ROADMAP.md updates.
|
||||
6 prior-conversation resolutions (D-214..D-219, all user-confirmed)
|
||||
+ 6 new ambiguities (D-220..D-225, all auto-resolved at full autonomy,
|
||||
confidence ≥ 0.60). 0 escalations.
|
||||
|
||||
**Key decisions:**
|
||||
- D-206: `.ciagent/` for both projects in the platform repo (multi-project mode).
|
||||
- D-207: `NOVA_AWS_*` has root-equivalent perms; single key for pilot.
|
||||
- D-208: `dev` bound to `581513795199`; qa/prod/dr stay placeholder (pilot-readiness policy blocks apply on placeholder).
|
||||
- D-209: Pilot runs `mode: full` (apply) for `dev` only; autonomous (no HITL gate).
|
||||
- D-210: Contract declares ecs + dynamodb + s3 (existing adapter stack types; no new TYPE_MAP entries).
|
||||
- D-211: Outcome backfill touches metrics cold store, NOT the PCR schema (v1.25 moat preserved).
|
||||
- D-212: Consumer repo has its own CI + unit tests; platform CI covers platform only.
|
||||
- D-213: Feature milestone; tags on v1.25.x (no schema breaks).
|
||||
- D-220: v1.27 is an NFR milestone (tags on v1.26.x; final patch is the
|
||||
milestone release).
|
||||
- D-221: Consumer archives land in `.ciagent/nova-blockchain-exchange/archive/`.
|
||||
- D-222: Archiving pre-execution artifacts preserves traceability
|
||||
(archive files + PROJECT.md load-bearing decisions + git history).
|
||||
- D-223: IAM_POLICY.md stays active (live baseline, test-enforced,
|
||||
D-207 pending).
|
||||
- D-224: REGRESSION_REPORT.{json,md} regenerate on next
|
||||
`run_regression.sh` (machine-managed; v1.27 is docs/chore only).
|
||||
- D-225: PROJECT.md phase-status fix is P2 (correction phase), not P1
|
||||
(additive phase).
|
||||
+108
-192
@@ -1,225 +1,141 @@
|
||||
# GRILL — v1.26 Live Pilot Estate Activation
|
||||
# GRILL — v1.27 PO State Catalog & Ciagent Compression
|
||||
|
||||
> Adversarial review of the v1.26 SPECIFY + CLARIFY + RESEARCH + IDEATE +
|
||||
> PLAN. The grill red-teams the proposal across feasibility, scope,
|
||||
> budget, and the domain claims (homegrown blockchain, pilot estate,
|
||||
> metric grounding). Each challenge gets a binding verdict
|
||||
> (PROCEED / REVISE / ESCALATE). Autonomy: full — escalations auto-
|
||||
> resolve with assumption logging unless confidence < 0.60.
|
||||
> 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.84) — 0 escalations, 2 revisions
|
||||
## Verdict: PROCEED (0.88) — 0 escalations, 1 revision
|
||||
|
||||
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.md. No work is blocked.
|
||||
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.
|
||||
|
||||
---
|
||||
|
||||
## Challenges
|
||||
|
||||
### G-Q1 — Is a homegrown PoA blockchain viable for a pilot, or is it reckless?
|
||||
### G-Q1 — Is archiving AUTONOMY_THESIS.md + COST.md a context loss?
|
||||
|
||||
**Challenge:** Authoring a blockchain (even a minimal PoA ledger) is a
|
||||
non-trivial domain. A homegrown chain could have correctness bugs (hash
|
||||
chain breaks, non-deterministic blocks, settlement-finality race
|
||||
conditions). Why not use a proven chain (Ethereum L2, Solana, Hyperledger
|
||||
Fabric)?
|
||||
**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.88). The pilot's purpose is to
|
||||
exercise the Nova platform's deploy/policy/attestation gates over a
|
||||
real consumer estate — not to build a production blockchain. A
|
||||
homegrown PoA ledger is the minimal viable chain: append-only blocks,
|
||||
single validator, SHA-256 hash chain, deterministic block production.
|
||||
This is ~200 lines of Python (block + ledger + validator). The chain
|
||||
needs to be real enough to record transactions + produce a settlement-
|
||||
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.
|
||||
**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 "all types of securities" scope-explode the milestone?
|
||||
### G-Q2 — Does the archive list include the v1.27 P0 pre-execution files by mistake?
|
||||
|
||||
**Challenge:** The user said "offering all types of securities." Equities
|
||||
(D-200, pilot scope) is one type. Bonds (T+2), derivatives (varying),
|
||||
options (exercise models) have very different settlement models. Does
|
||||
the equities-only deferral betray the user's intent?
|
||||
**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:** PROCEED (confidence 0.85). The user *chose* equities-only
|
||||
pilot (Q4 in the plan discussion, answer "A to all 3 questions" — the
|
||||
recommended scope). "All types of securities" is the *product vision*;
|
||||
v1.26 is the *pilot* (equities first). The roadmap documents the
|
||||
deferral. The pilot demonstrates the Nova platform's gates over the
|
||||
simplest settlement model (T+1); expanding to other security types is
|
||||
a straightforward extension (new settlement-service branches + new
|
||||
kyverno-json policies) once the platform-gates pattern is proven. No
|
||||
revision needed — the scope decision is the user's, not the grill's.
|
||||
**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 — Does the consumer-repo-as-2nd-project break single-project tooling?
|
||||
### G-Q3 — Is the STATE.md backfill accurate enough to be the PO's source of truth?
|
||||
|
||||
**Challenge:** CIAgent has been single-project since v1.0. v1.26
|
||||
activates multi-project mode (2 projects: `acdl` +
|
||||
`nova-blockchain-exchange`). Does this break assumptions in the
|
||||
CIAgent tooling (branch naming, `.ciagent/` paths, commit `---ci---`
|
||||
blocks)?
|
||||
**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.90). `run.md` Step 0 explicitly
|
||||
specifies multi-project mode: `projects[]` with length > 0,
|
||||
`active_projects` array, `.ciagent/<slug>/` subdirectory paths, branch
|
||||
prefixes `<slug>/`. The `---ci---` block gains a `project: <slug>`
|
||||
field (already in the v1.26 commits). The consumer's project files
|
||||
live in `.ciagent/nova-blockchain-exchange/`. The platform's existing
|
||||
flat `.ciagent/` files remain the primary set (the platform is the
|
||||
default project). Branch naming: the consumer's phases use
|
||||
`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.
|
||||
**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 P2 contract reference a `dynamodb` module that doesn't exist until P3?
|
||||
### G-Q4 — Does the NFR purity gate (zero `feat:` commits) hold for v1.27?
|
||||
|
||||
**Challenge:** The original plan had REQ-322 (DynamoDB primitive) in
|
||||
P3, but the P2 contract (REQ-313) references `dynamodb` in its
|
||||
`infrastructure` block. If the primitive doesn't exist until P3, the
|
||||
P2 contract's `dynamodb` block can't resolve at registry time — only
|
||||
at schema time (the schema is open). Is this a vertical-slice
|
||||
violation (P2 ships a contract that can't fully resolve)?
|
||||
**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:** REVISE (confidence 0.92). This is a real vertical-slice
|
||||
violation. PLAN.md already revised: REQ-322 moves to P2 W0 (before the
|
||||
contract). The revised mapping (PLAN.md "Revised: REQ-322 → P2 W0")
|
||||
makes P2 self-contained: the primitive + the contract + the deploy
|
||||
invocation all land in P2. This is a binding revision — the original
|
||||
P3 placement is superseded. ROADMAP.md is already updated (REQ-322 in
|
||||
P2). No further revision needed — the plan self-corrected.
|
||||
**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 live-AWS pilot break the MTTR < 60s target?
|
||||
### G-Q5 — Does fixing PROJECT.md phase-status in P2 create a P0/P1 audit inconsistency?
|
||||
|
||||
**Challenge:** NORTH_STAR.md MTTR target: < 60s p95. The pilot runs
|
||||
`terraform apply` (creating real AWS resources: ECS + DynamoDB + S3).
|
||||
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?
|
||||
**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 MTTR target is for
|
||||
*platform-detected + platform-remediated incidents* (apply.failed →
|
||||
successful retry), not for first-time apply latency. The pilot's
|
||||
first apply is a deployment, not an incident-remediation. The MTTR
|
||||
metric measures the retry path: if the apply fails (e.g. IAM
|
||||
permission), the platform retries — the retry MTTR is the time from
|
||||
`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.
|
||||
**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 settlement-finality policy (REQ-315) over-engineering for a pilot?
|
||||
### G-Q6 — Is the milestone scoped too small (3 phases, 8 archive moves)?
|
||||
|
||||
**Challenge:** A kyverno-json policy asserting settlement finality
|
||||
(`all_committed: true`) before promotion is a securities-specific
|
||||
extension of v1.25's policy engine. Is this over-engineering for a
|
||||
pilot that only runs in `dev` (autonomous, no promotion to qa/prod/dr
|
||||
in v1.26 per D-208)?
|
||||
**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.80). The policy is *authored* in
|
||||
v1.26 (P3) but its *enforcement* activates when a promotion to qa/prod
|
||||
happens — which is a *future* milestone (D-208: qa/prod/dr stay
|
||||
placeholder this milestone). The policy is tested (passing + failing
|
||||
fixtures; skip when `kj` absent) in P3, but it doesn't gate a `dev`
|
||||
apply (the pilot-readiness policy REQ-320 gates `dev`; the settlement-
|
||||
finality policy gates promotions). Authoring + testing the policy in
|
||||
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 — Is D-083 deferral defensible for a pilot with real money-like flows?
|
||||
|
||||
**Challenge:** The pilot is a stock exchange — securities trading. D-083
|
||||
(S3 Object Lock / JWS tamper-evident ledger) is deferred (D-204). The
|
||||
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.82). The pilot is a *technical
|
||||
demonstration*, not a production trading system. No real money, no real
|
||||
securities, no real investors — the "securities" are test tokens on a
|
||||
homegrown chain. The audit integrity requirement (SEC Rule 17a-4, FINRA
|
||||
retention) applies to *production* trading systems, not to a pilot
|
||||
exercising a platform's deploy/policy/attestation gates. The SQLite
|
||||
hash-chain + DynamoDB outbox is a tamper-*evident* record (any tampering
|
||||
breaks the hash chain) — it's just not tamper-*resistant* (S3 Object
|
||||
Lock + JWS would make it tamper-resistant). For a pilot, tamper-evident
|
||||
suffices. D-083 lift is a future milestone (when the pilot becomes a
|
||||
production system). D-204 records this. No revision needed.
|
||||
|
||||
### G-Q8 — Does the outcome-backfill emitter (REQ-317) touch the PCR schema?
|
||||
|
||||
**Challenge:** REQ-317 wires `apply.completed`/`apply.failed` →
|
||||
`fact_decision.outcome`. The v1.25 hard constraint says "DO NOT change
|
||||
`schemas/policy_check_result.schema.json`." Does the backfill touch the
|
||||
PCR schema?
|
||||
|
||||
**Verdict:** PROCEED (confidence 0.95). D-211 (CLARIFY) already
|
||||
resolved this: the outcome backfill touches the *metrics cold store*
|
||||
(`fact_decision` table in `metrics/nova_metrics.db`), not the PCR
|
||||
schema. The backfill reads run-manifest events (not PCRs) and updates
|
||||
the decision's outcome column. The PCR schema is unchanged. This
|
||||
respects the v1.25 hard constraint. No revision needed.
|
||||
|
||||
### G-Q9 — Does the `NOVA_AWS_*` root-equivalent key create a security risk?
|
||||
|
||||
**Challenge:** D-207 says `NOVA_AWS_*` has root-equivalent permissions
|
||||
(confirmed empirically: the bootstrap created the S3 bucket + DynamoDB
|
||||
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.78). The risk is real but bounded:
|
||||
(a) the pilot runs in a single account (`581513795199`) with no
|
||||
production workloads (the v1.11 teardown left it empty; the pilot is
|
||||
the only workload), (b) the key is in `.env.secrets` (gitignored, never
|
||||
committed), (c) the deploy workflow uses OIDC by default (the static
|
||||
key is the override, not the primary path). A future hardening
|
||||
milestone should split `NOVA_AWS_*` into a root `NOVA_BOOTSTRAP_AWS_*`
|
||||
+ a least-privilege `NOVA_AWS_*` runner key (the spike-runner pattern).
|
||||
For v1.26, the single key suffices (pilot scope). D-207 records this.
|
||||
**Minor revision: PLAN.md should note the key-split as a future
|
||||
hardening item.** Already implicit in D-207; making it explicit in the
|
||||
plan is a documentation refinement.
|
||||
**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.
|
||||
|
||||
---
|
||||
|
||||
## Summary
|
||||
|
||||
9 challenges; 0 escalations; 2 binding revisions (G-Q4, G-Q6/G-Q9
|
||||
minor). Overall verdict: PROCEED (confidence 0.84).
|
||||
6 challenges; 0 escalations; 1 binding revision (G-Q2, already
|
||||
captured in PLAN Task 2.1). Overall verdict: PROCEED (confidence
|
||||
0.88).
|
||||
|
||||
**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).
|
||||
- **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, 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.
|
||||
**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.
|
||||
@@ -56,7 +56,8 @@ and covered by the baseline test.
|
||||
## OIDC act_runner role (CAP-022, Phase 56)
|
||||
|
||||
The OIDC role for the Gitea `act_runner` was created in Phase 08 and
|
||||
gone since (CAPABILITY_INVENTORY.md CAP-022). Phase 56 re-creates it
|
||||
gone since (`archive/CAPABILITY_INVENTORY-v1.10.md` CAP-022, archived
|
||||
v1.27). Phase 56 re-creates it
|
||||
with a trust policy for the Gitea runner ARN. The role grants the
|
||||
spike-runner-equivalent permissions to the runner via `sts:AssumeRole`,
|
||||
so the runner does not need a long-lived access key. This closes the
|
||||
@@ -73,7 +74,7 @@ bootstrap root key; the runner then assumes the role.
|
||||
|
||||
The OIDC role for the Gitea `act_runner` was planned in Phase 08 but
|
||||
never created (the spike used a long-lived key per D-039 waiver).
|
||||
CAPABILITY_INVENTORY.md CAP-022 recorded "iam:ListRoles shows no acdl*
|
||||
`archive/CAPABILITY_INVENTORY-v1.10.md` CAP-022 recorded "iam:ListRoles shows no acdl*
|
||||
roles." Phase 56 re-created the role:
|
||||
|
||||
- **Role name:** `acdl-act-runner-role`
|
||||
|
||||
@@ -231,6 +231,18 @@ their AI engineering teams reach for first when an agent needs to deploy.
|
||||
leadership. The deck's Proof section cites grounded metrics; its
|
||||
Roadmap section cites deferred targets honestly.
|
||||
|
||||
## Relationship to engineering files (v1.27 update)
|
||||
|
||||
- **NORTH_STAR.md** (this file) = the *why* — PO-authored strategic
|
||||
direction, loaded every ci-run via `config.strategic_direction_file`.
|
||||
- **STATE.md** = the *what exists* — PO-owned capability catalog,
|
||||
additive, updated at every milestone ship (P-final Wave 3). The PO
|
||||
reads STATE.md before writing new REQ-NNN specs to avoid re-spec'ing
|
||||
existing capability and to respect the invariants.
|
||||
- **ARCHITECTURE.md** = the *how* — the durable target architecture.
|
||||
- **CHECKPOINT.json** = the *now* — authoritative live phase/ship
|
||||
state.
|
||||
|
||||
## v1.25 update — swappable policy-engine substrate
|
||||
|
||||
Strategic Objective #2 (provable trust) gained a concrete substrate in
|
||||
|
||||
+51
-143
@@ -1,169 +1,77 @@
|
||||
---
|
||||
project: acdl
|
||||
milestone: v1.26
|
||||
generated_at: 2026-08-12
|
||||
milestone: v1.27
|
||||
generated_at: 2026-08-19
|
||||
generator: lead-developer
|
||||
verification_toolchain:
|
||||
typecheck: "python3 -m py_compile core/confidence_signal.py core/metrics/outcome_backfill.py adapters/terraform/adapter.py modules/l1/dynamodb/terraform/main.tf"
|
||||
test: "pytest tests/test_adapter.py tests/test_contract_resolver.py tests/test_confidence_signal.py tests/test_outcome_backfill.py tests/test_settlement_finality_policy.py tests/test_pilot_readiness_policy.py tests/test_block.py tests/test_order_book.py tests/test_settlement.py -v"
|
||||
lint: "ruff check core/metrics/outcome_backfill.py adapters/kyverno-json/policies/pilot-readiness/ adapters/kyverno-json/policies/settlement-finality/ 2>/dev/null || python3 -m py_compile core/metrics/outcome_backfill.py"
|
||||
typecheck: "python3 -m py_compile core/confidence_signal.py 2>&1 | head -5 || true"
|
||||
test: "bash scripts/run_regression.sh 2>&1 | tail -10 || true"
|
||||
lint: "ruff check .ciagent/STATE.md 2>/dev/null || true"
|
||||
note: |
|
||||
v1.26 is the Live Pilot Estate Activation milestone — a feat
|
||||
milestone. Four active personas: lead-developer (coordination +
|
||||
docs + ARCHITECTURE.md §12.8), backend-engineer (confidence_signal.py
|
||||
escalation reason + outcome_backfill.py + run_platform.sh wiring +
|
||||
env-JSON state_backend reconciliation), data-engineer (DynamoDB L1
|
||||
primitive + metrics cold store outcome backfill), policy-engineer
|
||||
(kyverno-json pilot-readiness + settlement-finality policies), +
|
||||
blockchain-engineer (custom, phase-specific — chain core + order
|
||||
engine + settlement). frontend-engineer is deactivated (no UI).
|
||||
Territory enforcement: warn (the pilot is cross-territory by
|
||||
nature — the consumer repo + the platform repo share the milestone).
|
||||
v1.27 is an NFR milestone (PO State Catalog & Ciagent Compression) —
|
||||
a docs/chore milestone. Single active persona: lead-developer owns
|
||||
the milestone narrative (STATE.md authoring, PROJECT/ROADMAP fixes,
|
||||
archive moves, PLAN/NORTH_STAR wiring, final review + audit). No
|
||||
code, no schema, no policy authoring. The pre-existing
|
||||
core/confidence_signal.py LSP diagnostic is out of scope (not
|
||||
touched by v1.27). Territory enforcement: warn.
|
||||
---
|
||||
|
||||
# PERSONAS — v1.26 Live Pilot Estate Activation
|
||||
# PERSONAS — v1.27 PO State Catalog & Ciagent Compression
|
||||
|
||||
> Generated by the lead-developer at the end of RESEARCH. Assesses the
|
||||
> project domains, activates/deactivates personas, creates custom
|
||||
> personas for domains beyond the default four, aligns frameworks +
|
||||
> project domains, activates/deactivates personas, aligns frameworks +
|
||||
> territory + constraints to the actual project structure.
|
||||
|
||||
## Active Roster (5)
|
||||
## Active Roster (1)
|
||||
|
||||
### 1. lead-developer (active)
|
||||
- **active:** true
|
||||
- **phase_specific:** false
|
||||
- **reason:** Coordinates task decomposition + resolves conflicts between
|
||||
engineering personas. Owns the milestone narrative (PROJECT.md,
|
||||
ROADMAP.md, ARCHITECTURE.md §12.8). Final architectural decisions when
|
||||
personas disagree (e.g. where the outcome-backfill emitter lives).
|
||||
- **domain:** project coordination, milestone narrative, cross-persona
|
||||
conflict resolution.
|
||||
- **frameworks:** none (coordination role).
|
||||
- **territory:** `.ciagent/`, `docs/METRICS.md`, `adapters/README.md`,
|
||||
`modules/README.md`, `modules/STANDARDS.md`.
|
||||
- **constraints:** does not write Python/Terraform (delegates to
|
||||
backend/data-engineer); does not author policies (delegates to
|
||||
policy-engineer); does not author chain code (delegates to
|
||||
blockchain-engineer).
|
||||
- **reason:** Owns the full v1.27 milestone narrative: STATE.md
|
||||
authoring (PO-facing capability catalog, 36 entries across 10
|
||||
domains + 11 invariants), archive moves (11 files to
|
||||
`.ciagent/archive/` + 1 to consumer archive), PROJECT.md + ROADMAP.md
|
||||
phase-status corrections, archive/README.md contents update,
|
||||
PLAN.md + ROADMAP.md + NORTH_STAR.md ship-discipline wiring, final
|
||||
review + audit.
|
||||
- **domain:** `.ciagent/` docs (STATE.md, PROJECT.md, ROADMAP.md,
|
||||
PLAN.md, NORTH_STAR.md, archive/README.md), consumer
|
||||
`.ciagent/nova-blockchain-exchange/` (PROJECT.md pointer,
|
||||
archive/ROADMAP-v1.26.md).
|
||||
- **frameworks:** markdown, JSON (CHECKPOINT.json, config.json).
|
||||
- **territory:** `.ciagent/`, `docs/`.
|
||||
- **constraints:** no code changes (NFR milestone, D-220); no schema
|
||||
changes; archive moves are lossless (byte-identical relocation, git
|
||||
history preserves authoritative state); STATE.md is additive only.
|
||||
|
||||
### 2. backend-engineer (active)
|
||||
- **active:** true
|
||||
- **phase_specific:** false
|
||||
- **reason:** Owns the platform-side Python changes: confidence signal
|
||||
escalation reason (REQ-318), outcome-backfill emitter (REQ-317),
|
||||
env-JSON state_backend wiring (REQ-319), adapter test updates for
|
||||
DynamoDB (REQ-322), regression CAP-025 (REQ-316).
|
||||
- **domain:** core Python (confidence_signal.py, metrics/, adapter.py,
|
||||
regression_verify.py, contract_resolver.py), run_platform.sh wiring.
|
||||
- **frameworks:** Python 3.12, pytest, boto3, SQLite, DynamoDB.
|
||||
- **territory:** `core/confidence_signal.py`, `core/metrics/`,
|
||||
`adapters/terraform/adapter.py`, `core/regression_verify.py`,
|
||||
`core/environments/`, `scripts/run_platform.sh`, `tests/test_adapter.py`,
|
||||
`tests/test_confidence_signal.py`, `tests/test_outcome_backfill.py`,
|
||||
`tests/test_regression_pilot.py`.
|
||||
- **constraints:** does not change `schemas/policy_check_result.schema.json`
|
||||
(v1.25 moat, D-211); does not change `schemas/contract.schema.json`
|
||||
(no schema breaks, D-213); does not author Terraform modules
|
||||
(delegates to data-engineer for DynamoDB); does not author policies
|
||||
(delegates to policy-engineer); does not author chain code (delegates
|
||||
to blockchain-engineer).
|
||||
## Deactivated (5)
|
||||
|
||||
### 3. data-engineer (active)
|
||||
- **active:** true
|
||||
- **phase_specific:** false
|
||||
- **reason:** Owns the DynamoDB L1 primitive (REQ-322) — the single
|
||||
platform-side module build-out. Owns the metrics cold store
|
||||
outcome-backfill integration (REQ-317, the `fact_decision.outcome`
|
||||
column + `backfilled_at` timestamp). Owns the env-JSON data updates
|
||||
(REQ-319, `core/environments/*.json` account_id + state_backend.bucket).
|
||||
- **domain:** Terraform modules (`modules/l1/`), schema definitions
|
||||
(`interface.json`), registry (`modules/registry.json`), metrics cold
|
||||
store (`metrics/nova_metrics.db`, `core/metrics/collector.py`).
|
||||
- **frameworks:** Terraform, JSON, SQLite, DynamoDB, boto3.
|
||||
- **territory:** `modules/l1/dynamodb/`, `modules/registry.json`,
|
||||
`modules/README.md`, `core/environments/*.json`,
|
||||
`core/metrics/collector.py`, `tests/test_adapter.py` (DynamoDB
|
||||
emission test).
|
||||
- **constraints:** does not change the adapter (stateless, v1.11);
|
||||
follows the v1.8 NFR defaults (encryption + deletion protection +
|
||||
PITR); follows the module standards (`modules/STANDARDS.md`).
|
||||
### backend-engineer (inactive)
|
||||
- **active:** false
|
||||
- **reason:** No code changes in v1.27. The pre-existing
|
||||
`core/confidence_signal.py` LSP diagnostic is out of scope (not
|
||||
touched by v1.27).
|
||||
|
||||
### 4. policy-engineer (active, custom — added in v1.25)
|
||||
- **active:** true
|
||||
- **phase_specific:** false
|
||||
- **reason:** Owns the kyverno-json policy authoring for the pilot:
|
||||
settlement-finality (REQ-315), pilot-readiness (REQ-320). Extends
|
||||
v1.25's policy engine to the securities domain.
|
||||
- **domain:** declarative policies (kyverno-json ValidatingPolicy YAML),
|
||||
JMESPath assertions, policy tests.
|
||||
- **frameworks:** kyverno-json, JMESPath, JSON, pytest.
|
||||
- **territory:** `adapters/kyverno-json/policies/pilot-readiness/`,
|
||||
`adapters/kyverno-json/policies/settlement-finality/`,
|
||||
`tests/test_settlement_finality_policy.py`,
|
||||
`tests/test_pilot_readiness_policy.py`.
|
||||
- **constraints:** policies are declarative (no imperative Python);
|
||||
`is_configured()` guard skips gracefully when `kj` absent; follows
|
||||
the v1.25 policy-authoring standard (`modules/STANDARDS.md` policy
|
||||
section + `adapters/kyverno-json/README.md`).
|
||||
### data-engineer (inactive)
|
||||
- **active:** false
|
||||
- **reason:** No schema, migration, or ORM changes.
|
||||
|
||||
### 5. blockchain-engineer (active, custom, phase-specific — added in v1.26)
|
||||
- **active:** true
|
||||
- **phase_specific:** true (created for v1.26 P1; removed after P1
|
||||
unless the chain has ongoing work in P2..P4)
|
||||
- **reason:** The pilot introduces a homegrown blockchain — a domain
|
||||
beyond the default four personas. Owns the chain core (block, ledger,
|
||||
validator, REQ-310), the order-matching engine (REQ-311), the
|
||||
settlement service (REQ-312), and the consumer `contract.yaml`
|
||||
(REQ-313) + deploy invocation (REQ-314).
|
||||
- **domain:** blockchain consensus (PoA, single validator), order
|
||||
matching (limit order book, price-time priority), settlement
|
||||
(T+1, finality = block commit), consumer-repo deploy model.
|
||||
- **frameworks:** Python 3.12 (the chain is Python, not Solidity/Go —
|
||||
it's a homegrown ledger, not a smart-contract platform), pytest,
|
||||
YAML (contract.yaml), GitHub Actions / Gitea Actions (deploy.yml
|
||||
invocation).
|
||||
- **territory:** `/root/nova-blockchain-exchange/` (the consumer repo:
|
||||
`chain/`, `engine/`, `settlement/`, `contract.yaml`,
|
||||
`contracts/*.yml`, `.github/workflows/deploy.yml`,
|
||||
`.gitea/workflows/deploy.yml`, `tests/`).
|
||||
- **constraints:** the chain is deterministic (same inputs → same block)
|
||||
— it is automation, not AI (NORTH_STAR Objective #2 tenet); equities
|
||||
only (D-200); single validator PoA (D-201); the consumer deploy MUST
|
||||
go through `deploy.yml@v1.25` (no direct terraform apply); the
|
||||
contract MUST validate against `schemas/contract.schema.json`.
|
||||
|
||||
## Deactivated (1)
|
||||
### policy-engineer (inactive)
|
||||
- **active:** false
|
||||
- **reason:** No policy authoring. STATE.md Domain 3 catalogues
|
||||
existing v1.25 + v1.26 policies (descriptive, not authoring).
|
||||
|
||||
### frontend-engineer (inactive)
|
||||
- **active:** false
|
||||
- **phase_specific:** false
|
||||
- **reason:** The pilot has no UI — the blockchain exchange is a
|
||||
backend service (matching engine + settlement). The consumer repo
|
||||
has no web/frontend. Reactivated if a future milestone adds a trading
|
||||
dashboard.
|
||||
- **reason:** No UI. Deactivated since v1.26 (PERSONAS.md:141).
|
||||
|
||||
## Phase-Specific Notes
|
||||
|
||||
- **blockchain-engineer** is created for v1.26 P1 (blockchain core +
|
||||
order engine + settlement). If P2..P4 have no chain changes, the
|
||||
persona is removed after P1 (the chain is a stable substrate for the
|
||||
pilot run). If P2 (consumer-contract-and-deploy) requires chain
|
||||
adjustments, the persona stays through P2.
|
||||
- **policy-engineer** is active for P3 (pilot-metrics-and-policies) +
|
||||
may consult on P4 (pilot run policy verification).
|
||||
- **data-engineer** is active for P3 (DynamoDB primitive + outcome
|
||||
backfill + env-JSON) + P4 (regression CAP-025 may touch the registry).
|
||||
### blockchain-engineer (inactive)
|
||||
- **active:** false
|
||||
- **reason:** No chain code. The v1.26 pilot is shipped; v1.27 is
|
||||
platform-side docs/chore only.
|
||||
|
||||
## Territory Enforcement
|
||||
|
||||
- **Mode:** `warn` (the pilot is cross-territory by nature — the
|
||||
consumer repo + the platform repo share the milestone; the
|
||||
blockchain-engineer works in the consumer repo, backend/data/policy
|
||||
engineers work in the platform repo).
|
||||
- **Cross-territory collisions:** REQ-322 (DynamoDB primitive) is
|
||||
data-engineer territory, but the adapter test update
|
||||
(`tests/test_adapter.py` `EXPECTED_L1_KEYS`) is backend-engineer
|
||||
territory. The lead-developer resolves: data-engineer authors the
|
||||
module + registry; backend-engineer updates the test assertion
|
||||
(the test is backend territory, the module is data territory).
|
||||
- **Mode:** `warn` (the milestone is `.ciagent/`-only; the lead-
|
||||
developer owns all writes; no cross-territory collisions expected).
|
||||
+220
-462
@@ -1,510 +1,268 @@
|
||||
# PLAN — v1.26 (Live Pilot Estate Activation)
|
||||
# PLAN — v1.27 PO State Catalog & Ciagent Compression
|
||||
|
||||
> Feature milestone. Tags on the **v1.25.x** line: v1.25.0 (P0) →
|
||||
> v1.25.1 (P1) → v1.25.2 (P2) → v1.25.3 (P3) → v1.25.4 (P4) → v1.25.5
|
||||
> (P5 final = milestone release). 13 requirements (REQ-310..322),
|
||||
> 5 phases (P0 pre-execution + 4 execution + 1 final). Multi-project:
|
||||
> `acdl` (platform) + `nova-blockchain-exchange` (consumer). Tags run
|
||||
> on the previous minor's patch line per `run.md` versioning logic
|
||||
> (feature milestone — at least one feat phase; progressive patches per
|
||||
> phase; the final phase's patch IS the milestone release; no separate
|
||||
> minor tag).
|
||||
> **Milestone:** v1.27 (NFR — docs/chore only). Tags on the **v1.26.x**
|
||||
> line: `v1.26.0` (P0) → `v1.26.1..v1.26.3` (P1..P3). The final phase's
|
||||
> patch (`v1.26.3`) IS the milestone release.
|
||||
> **Branch:** `milestone/v1.27-po-state-catalog`. Phase branches:
|
||||
> `phase/00-pre-execution`, `phase/01-author-archive`,
|
||||
> `phase/02-fix-stale-wire`, `phase/03-final-review-ship`.
|
||||
|
||||
---
|
||||
## Milestone goal
|
||||
|
||||
## Phase 0 — Pre-Execution (complete, tag v1.25.0)
|
||||
Author `.ciagent/STATE.md` (PO-facing capability catalog, backfilled
|
||||
through v1.26) + compress `.ciagent/` by archiving 11 outdated files +
|
||||
fix 3 stale-but-kept files + wire STATE.md into the P-final ship
|
||||
discipline. NFR milestone — no code, no schema, no platform behavior
|
||||
change.
|
||||
|
||||
SPECIFY → CLARIFY → RESEARCH → IDEATE → PLAN → GRILL. All `.ciagent/`
|
||||
MD, research, plans. Ships as `v1.25.0` on the v1.25.x line.
|
||||
## Requirements
|
||||
|
||||
**Pre-run (Workstream A, on main before branch gate):**
|
||||
- A1: flaky test fix (commit `8c68d68`, pushed).
|
||||
- A2: ACDL_*→NOVA_* bootstrap migration (commit `f844fea`, pushed).
|
||||
- A3: AWS bootstrap — S3 state bucket + DynamoDB outbox created.
|
||||
- A4: `nova-blockchain-exchange` Gitea repo created + cloned.
|
||||
No new REQ-NNN. v1.27 is a docs/chore milestone; the work items are
|
||||
the user-approved plan from the prior conversation. The traceability
|
||||
is by-file (the "requirements" are the 15 file operations + 6 doc
|
||||
edits in the plan summary).
|
||||
|
||||
**Phase 0 stages (on `phase/00-specify-clarify-research-plan`):**
|
||||
- SPECIFY: v1.26 established in config.json + PROJECT.md + ROADMAP.md +
|
||||
`.ciagent/nova-blockchain-exchange/{PROJECT,REQUIREMENTS,ROADMAP}.md`.
|
||||
- CLARIFY: 10 ambiguities resolved (D-200..D-213).
|
||||
- RESEARCH: PoA blockchain, deploy model, DynamoDB gap (REQ-322),
|
||||
metric grounding, persona assessment (5 personas).
|
||||
- IDEATE: 7 ideas accepted (I1..I7 → REQ-315..322), 3 deferred.
|
||||
- PLAN: this file.
|
||||
- GRILL: adversarial review (binding verdicts).
|
||||
## Phase breakdown
|
||||
|
||||
---
|
||||
### Phase P1 — author-archive (additive + lossless)
|
||||
|
||||
## Phase 1 — blockchain-core (tag v1.25.1)
|
||||
**Goal:** Author STATE.md (already done in P0 SPECIFY, refined here)
|
||||
+ archive 11 outdated files. Pure-additive + lossless moves only —
|
||||
no edits to kept files.
|
||||
|
||||
**Goal:** The consumer repo has a working homegrown PoA blockchain +
|
||||
order-matching engine + settlement service. All unit tests pass in the
|
||||
consumer repo's own CI.
|
||||
#### Wave 1 — verify STATE.md backfill
|
||||
- **Task 1.1** (lead-developer): verify STATE.md 36 capability rows
|
||||
against the authoritative sources (regression_verify.py CAP-NNN list,
|
||||
modules/registry.json, REQUIREMENTS.md traceability, CHECKPOINT
|
||||
tags). Fix any inaccurate citation (shipped tag, file path).
|
||||
|
||||
**Project:** `nova-blockchain-exchange` (consumer repo).
|
||||
**Branch:** `nova-blockchain-exchange/phase/01-blockchain-core`.
|
||||
**Persona:** blockchain-engineer (primary), lead-developer (coordination).
|
||||
#### Wave 2 — archive platform-root files (10)
|
||||
- **Task 2.1** (lead-developer): `git mv` 10 files to
|
||||
`.ciagent/archive/` with milestone-suffix names:
|
||||
- `CAPABILITY_INVENTORY.md` → `CAPABILITY_INVENTORY-v1.10.md`
|
||||
- `CLARIFY.md` → `CLARIFY-v1.26.md`
|
||||
- `GRILL.md` → `GRILL-v1.26.md`
|
||||
- `IDEATE.md` → `IDEATE-v1.26.md`
|
||||
- `RESEARCH.md` → `RESEARCH-v1.26.md`
|
||||
- `REVIEW-AUDIT-P05.md` → `REVIEW-AUDIT-P05.md`
|
||||
- `VERIFY-P03.md` → `VERIFY-P03.md`
|
||||
- `VERIFY-P04.md` → `VERIFY-P04.md`
|
||||
- `P4-PILOT-RUN-EVIDENCE.md` → `P4-PILOT-RUN-EVIDENCE-v1.26.md`
|
||||
- `AUTONOMY_THESIS.md` → `AUTONOMY_THESIS-v1.21.md`
|
||||
- `COST.md` → `COST-v1.14.md`
|
||||
Use `git mv` to preserve history. NOTE: CLARIFY/GRILL/IDEATE/RESEARCH
|
||||
were rewritten in P0 with v1.27 content — archive the v1.27 versions
|
||||
(they document the v1.27 pre-execution; the next P0 writes fresh).
|
||||
Wait — per D-219, the v1.26 pre-execution artifacts are archived. The
|
||||
v1.27 versions replace them in active context; they are NOT archived
|
||||
at P1 (they are the current P0 artifacts, active until v1.27 ships,
|
||||
then archived at v1.28 P1 if v1.28 happens). **Correction:** archive
|
||||
only the v1.26-era pre-execution artifacts. But P0 already
|
||||
overwrote CLARIFY/GRILL/IDEATE/RESEARCH with v1.27 content. The v1.26
|
||||
content lives in git history (the pre-P0 commits). So:
|
||||
- The 4 pre-execution files (CLARIFY/GRILL/IDEATE/RESEARCH) at HEAD
|
||||
are the v1.27 P0 artifacts — **keep active** through v1.27, archive
|
||||
at v1.28.
|
||||
- The v1.26-era content is in git history — reachable.
|
||||
**Revised archive list (7 files, not 10):** CAPABILITY_INVENTORY,
|
||||
REVIEW-AUDIT-P05, VERIFY-P03, VERIFY-P04, P4-PILOT-RUN-EVIDENCE,
|
||||
AUTONOMY_THESIS, COST.
|
||||
|
||||
### Wave 1 — chain core (REQ-310)
|
||||
- **Task 1.1** (blockchain-engineer): `chain/block.py` — Block dataclass
|
||||
(index, timestamp, prev_hash, transactions, nonce, hash).
|
||||
`compute_hash()` deterministic (SHA-256). Unit test: `test_block.py`.
|
||||
- **Task 1.2** (blockchain-engineer): `chain/ledger.py` — Ledger class:
|
||||
`append_block()`, `verify_chain()`, `get_block(index)`,
|
||||
`get_latest_block()`. Genesis block on init. Unit test: `test_ledger.py`.
|
||||
- **Task 1.3** (blockchain-engineer): `chain/validator.py` — PoA
|
||||
validator: single validator (config-driven), `propose_block(transactions)`
|
||||
→ Block, `commit_block(block)`. Unit test: `test_validator.py`.
|
||||
Hold — let me re-check D-219. The user said "Archive all 4
|
||||
pre-execution artifacts." That was decided *before* P0 overwrote
|
||||
them. The intent was to archive the v1.26 pre-execution record. The
|
||||
v1.27 P0 overwrites are the new pre-execution record. Archiving the
|
||||
v1.27 versions at v1.27 P1 would lose the v1.27 pre-execution
|
||||
narrative. **Resolution:** archive the v1.26-era content (preserved
|
||||
in git history at the pre-P0 commits) by noting it in the archive
|
||||
README; keep the v1.27 P0 versions active through v1.27. The 4 files
|
||||
stay active until v1.28 P1.
|
||||
|
||||
### Wave 2 — order engine + settlement (REQ-311, REQ-312) — parallel with Wave 1 tail
|
||||
- **Task 2.1** (blockchain-engineer): `engine/order.py` — Order
|
||||
dataclass (id, side, symbol, price, size, timestamp).
|
||||
- **Task 2.2** (blockchain-engineer): `engine/order_book.py` —
|
||||
OrderBook: `add_order(order)`, `match_orders()` → list of Match
|
||||
(price-time priority, partial fills). Unit test: `test_order_book.py`.
|
||||
- **Task 2.3** (blockchain-engineer): `settlement/service.py` —
|
||||
SettlementService: `settle(match)` → SettlementTransaction,
|
||||
`submit(ledger)`. Idempotent (re-settling a match is a no-op once
|
||||
final). Finality = block commit. Unit test: `test_settlement.py`.
|
||||
**Final archive list (7 files):** CAPABILITY_INVENTORY.md,
|
||||
REVIEW-AUDIT-P05.md, VERIFY-P03.md, VERIFY-P04.md,
|
||||
P4-PILOT-RUN-EVIDENCE.md, AUTONOMY_THESIS.md, COST.md.
|
||||
|
||||
### Wave 3 — consumer CI (cross-cutting)
|
||||
- **Task 3.1** (blockchain-engineer): `.github/workflows/ci.yml` +
|
||||
`.gitea/workflows/ci.yml` — lint + pytest on chain/engine/settlement.
|
||||
- **Task 3.2** (lead-developer): `nova-blockchain-exchange/README.md` —
|
||||
repo overview + dev setup.
|
||||
- **Task 2.2** (lead-developer): grep for dangling references to the
|
||||
archived filenames across `.ciagent/` + `docs/`; fix any in P2 (the
|
||||
fix-stale phase).
|
||||
|
||||
#### Wave 3 — archive consumer file (1)
|
||||
- **Task 3.1** (lead-developer): `mkdir
|
||||
.ciagent/nova-blockchain-exchange/archive/` + `git mv
|
||||
nova-blockchain-exchange/ROADMAP.md` →
|
||||
`nova-blockchain-exchange/archive/ROADMAP-v1.26.md` (D-221).
|
||||
|
||||
#### Wave 4 — commit P1
|
||||
- **Task 4.1** (lead-developer): single commit `chore(P01): archive 7
|
||||
platform + 1 consumer outdated .ciagent files` with `---ci---`
|
||||
block.
|
||||
|
||||
**Must-haves (verify before ship):**
|
||||
- `pytest tests/` in the consumer repo passes (chain integrity, hash
|
||||
determinism, genesis, append/verify, match priority, partial fills,
|
||||
settlement idempotency, finality check).
|
||||
- The chain is deterministic (replay produces the same hash chain).
|
||||
- The consumer CI workflow runs on push.
|
||||
- STATE.md 36 rows accurate (Wave 1 verification).
|
||||
- 7 platform files present in `.ciagent/archive/` with milestone
|
||||
suffixes; originals gone from `.ciagent/` root.
|
||||
- 1 consumer file present in
|
||||
`.ciagent/nova-blockchain-exchange/archive/`; original gone.
|
||||
- 0 dangling references in active files (checked in P2, but flagged
|
||||
here).
|
||||
|
||||
**Ship:** tag `v1.25.1`, merge `phase/01` → `milestone/v1.26-pilot-activation`,
|
||||
Gitea release (best-effort). Delete `phase/01`.
|
||||
### Phase P2 — fix-stale-wire (corrections + wiring)
|
||||
|
||||
---
|
||||
**Goal:** Fix 3 stale-but-kept files + wire STATE.md into the P-final
|
||||
ship discipline + add a pointer in the consumer PROJECT.md.
|
||||
|
||||
## Phase 2 — consumer-contract-and-deploy (tag v1.25.2)
|
||||
#### Wave 1 — fix PROJECT.md phase-status
|
||||
- **Task 1.1** (lead-developer): `.ciagent/PROJECT.md` lines 424–431 —
|
||||
the v1.26 phase-status block. Mark P3/P4/P5 complete with shipped
|
||||
tags (`v1.25.3`, `v1.25.4`, `v1.25.5`); mark v1.26 milestone shipped.
|
||||
- **Task 1.2** (lead-developer): add a one-line pointer to STATE.md in
|
||||
the "Capability Status" section header (line 130): "The PO-facing
|
||||
capability catalog is `.ciagent/STATE.md` (additive; updated at
|
||||
milestone ship). CAP-NNN IDs cross-reference the regression gate at
|
||||
`core/regression_verify.py`."
|
||||
|
||||
**Goal:** The consumer repo declares its infrastructure via
|
||||
`contract.yaml` (validated against the platform's schema) + invokes the
|
||||
platform's `deploy.yml@v1.25` workflow. The contract references the
|
||||
`microservice` (ECS), `dynamodb`, + `s3` modules.
|
||||
#### Wave 2 — fix ROADMAP.md phase-status
|
||||
- **Task 2.1** (lead-developer): `.ciagent/ROADMAP.md` v1.26 section —
|
||||
mark P3/P4/P5 complete with shipped tags; mark the v1.26 Overview
|
||||
line (line 181) "(active, ...)" → "(complete, tag `v1.25.5`)".
|
||||
- **Task 2.2** (lead-developer): add STATE.md to the v1.25 + v1.26 P5
|
||||
phase-detail "Updated at ship" list (the convention visibility
|
||||
point).
|
||||
|
||||
**Project:** `nova-blockchain-exchange` (consumer repo) + `acdl`
|
||||
(platform repo — for the `deploy.yml@v1.25` ref + the `v1.25` floating
|
||||
tag).
|
||||
**Branch:** `nova-blockchain-exchange/phase/02-contract-and-deploy`.
|
||||
**Persona:** blockchain-engineer (contract authoring), data-engineer
|
||||
(registry/DynamoDB dependency check), lead-developer (deploy.yml ref).
|
||||
#### Wave 3 — wire STATE.md into ship discipline
|
||||
- **Task 3.1** (lead-developer): `.ciagent/PLAN.md` P5 Wave 3 Task 3.5
|
||||
— add STATE.md to the file-update list: "append new capability
|
||||
entries to `.ciagent/STATE.md`; mark any deprecated capability."
|
||||
- **Task 3.2** (lead-developer): `.ciagent/NORTH_STAR.md` — add a
|
||||
one-line note in "Relationship to engineering files" (or the v1.25
|
||||
update section): "STATE.md is the *what exists* catalog (PO-owned,
|
||||
additive, updated at milestone ship); this file is the *why*."
|
||||
|
||||
### Wave 1 — contract (REQ-313)
|
||||
- **Task 1.1** (blockchain-engineer): `contract.yaml` — id
|
||||
(`blkex`), name (`blockchain-exchange`), environment (dev),
|
||||
infrastructure block (microservice + dynamodb + s3).
|
||||
- **Task 1.2** (blockchain-engineer): `contracts/blockchain-exchange.dev.yml`,
|
||||
`.qa.yml`, `.prod.yml` — per-env variants.
|
||||
- **Task 1.3** (blockchain-engineer): `tests/test_contract_validates.py`
|
||||
— schema validation against the platform's
|
||||
`schemas/contract.schema.json`.
|
||||
#### Wave 4 — fix archive README + consumer PROJECT pointer
|
||||
- **Task 4.1** (lead-developer): `.ciagent/archive/README.md` — add
|
||||
the 8 new archived files (7 platform + 1 consumer) to the contents
|
||||
tables (Snapshots + Completed-phase artifacts sections).
|
||||
- **Task 4.2** (lead-developer):
|
||||
`.ciagent/nova-blockchain-exchange/PROJECT.md` — add a one-line
|
||||
pointer to the platform ROADMAP for milestone-phase history (since
|
||||
the consumer ROADMAP is archived): "Phase-by-phase history:
|
||||
`.ciagent/ROADMAP.md` §v1.26 (the consumer ROADMAP is archived at
|
||||
`.ciagent/nova-blockchain-exchange/archive/ROADMAP-v1.26.md`)."
|
||||
|
||||
### Wave 2 — deploy invocation (REQ-314)
|
||||
- **Task 2.1** (blockchain-engineer): `.github/workflows/deploy.yml` —
|
||||
`uses: acdl/.github/workflows/deploy.yml@v1.25` with
|
||||
`with: { contract: contract.yaml, mode: full, environment: dev }`.
|
||||
- **Task 2.2** (blockchain-engineer): `.gitea/workflows/deploy.yml` —
|
||||
byte-identical mirror.
|
||||
- **Task 2.3** (blockchain-engineer): `tests/test_deploy_workflow_invocation.py`
|
||||
— asserts the `uses:` ref + inputs.
|
||||
#### Wave 5 — fix any dangling references from P1 Wave 2
|
||||
- **Task 5.1** (lead-developer): apply fixes for any dangling
|
||||
references found in P1 Wave 2.
|
||||
|
||||
### Wave 3 — platform floating tag (cross-cutting)
|
||||
- **Task 3.1** (lead-developer, on `acdl` repo): verify the `v1.25`
|
||||
floating tag exists (created by `release.yml` on merge to main). If
|
||||
not, create it pointing at the `v1.25.0` tag (Phase 0 ship).
|
||||
#### Wave 6 — commit P2
|
||||
- **Task 6.1** (lead-developer): single commit `docs(P02): fix stale
|
||||
phase-status + wire STATE.md into ship discipline` with `---ci---`
|
||||
block.
|
||||
|
||||
**Must-haves (verify before ship):**
|
||||
- `contract.yaml` validates against `schemas/contract.schema.json`.
|
||||
- The deploy workflow invocation asserts the correct `uses:` ref +
|
||||
inputs.
|
||||
- The `v1.25` floating tag resolves.
|
||||
- PROJECT.md v1.26 phase-status matches CHECKPOINT.json (P3/P4/P5
|
||||
complete, v1.26 shipped).
|
||||
- ROADMAP.md v1.26 sections show P3/P4/P5 complete + Overview complete.
|
||||
- PLAN.md P5 Wave 3 names STATE.md.
|
||||
- NORTH_STAR.md notes STATE.md.
|
||||
- archive/README.md lists the 8 new archived files.
|
||||
- nova-blockchain-exchange/PROJECT.md points to platform ROADMAP.
|
||||
|
||||
**Ship:** tag `v1.25.2`, merge `phase/02` → milestone, Gitea release.
|
||||
Delete `phase/02`.
|
||||
### Phase P3 — final-review-ship (review + audit + milestone ship)
|
||||
|
||||
---
|
||||
**Goal:** Final review + audit + milestone ship.
|
||||
|
||||
## Phase 3 — pilot-metrics-and-policies (tag v1.25.3)
|
||||
#### Wave 1 — review
|
||||
- **Task 1.1** (lead-developer): review all P1/P2 changes for
|
||||
correctness (no broken markdown, no inaccurate citations, no
|
||||
dangling references).
|
||||
- **Task 1.2** (lead-developer): fix any P0 issues in this phase.
|
||||
|
||||
**Goal:** The platform repo gains the metric-grounding emitters, the
|
||||
kyverno-json pilot policies, the DynamoDB L1 primitive, the env-JSON
|
||||
wiring reconciliation, + the pilot regression CAP. The Post-Pilot
|
||||
metrics are grounded (outcome backfill + escalation reason); the pilot-
|
||||
readiness + settlement-finality policies are in place.
|
||||
#### Wave 2 — audit
|
||||
- **Task 2.1** (lead-developer): reconstruction test — git log
|
||||
`---ci---` blocks ↔ `.ciagent/` files consistent; phase
|
||||
progression P0→P1→P2→P3.
|
||||
- **Task 2.2** (lead-developer): `.ciagent/` file discipline —
|
||||
CHECKPOINT consistent with HEAD; PROJECT/ROADMAP phase-status
|
||||
consistent with CHECKPOINT; STATE.md present + 36 rows; archive
|
||||
contents match the moves.
|
||||
- **Task 2.3** (lead-developer): branch hygiene — only main +
|
||||
milestone + P3; P1/P2 deleted.
|
||||
- **Task 2.4** (lead-developer): commit discipline — all v1.27 commits
|
||||
carry `---ci---` blocks.
|
||||
|
||||
**Project:** `acdl` (platform repo) + `nova-blockchain-exchange`
|
||||
(consumer repo — the Gitea adapter rewrites the consumer's `deploy.yml`).
|
||||
**Branch:** `acdl/phase/03-pilot-metrics-and-policies` (platform branch).
|
||||
**Personas:** backend-engineer (emitters + adapter + regression),
|
||||
data-engineer (DynamoDB primitive + env JSON + collector),
|
||||
policy-engineer (kyverno-json policies), lead-developer (Gitea adapter
|
||||
+ deploy.yml drift + rotation workflow).
|
||||
|
||||
### Wave 0 — Gitea reusable-workflow adapter (SPEC §10 Q1, resolved by evidence) — lead-developer + blockchain-engineer
|
||||
> **Highest-priority gap.** The v0.2 P3 `workflow_dispatch` (Gitea
|
||||
> Actions run id=6199) failed: Gitea Actions rejects cross-repo `uses:`
|
||||
> (`acdl/.github/workflows/deploy.yml@v1.25`) with `expected format
|
||||
> {owner}/{repo}/.{git_platform}/workflows/{filename}@{ref}`. The
|
||||
> consumer's `deploy.yml` is frozen at the v0.1 byte-identical mirror;
|
||||
> the platform adapts (option c — inline checkout-then-call), not
|
||||
> vice-versa.
|
||||
- **Task 0.1** (lead-developer): rewrite
|
||||
`nova-blockchain-exchange/.gitea/workflows/deploy.yml` + byte-identical
|
||||
`.github/workflows/deploy.yml` — drop the `uses:` indirection; single
|
||||
`deploy` job on `ubuntu-latest` that `actions/checkout@v4` the consumer,
|
||||
`actions/checkout@v4` `acdl/acdl` @ `ref: v1.25` into `platform/`,
|
||||
setup-python 3.12, install deps (jsonschema/pyyaml/boto3 + checkov),
|
||||
install Terraform 1.9.*, configure AWS (static-key path:
|
||||
`aws-region: ${{ secrets.AWS_DEFAULT_REGION }}`, `access-key-id` +
|
||||
`secret-access-key` from `NOVA_AWS_*` secrets; no OIDC token minted),
|
||||
run `bash platform/scripts/run_platform.sh $MODE_FLAG $ENV_FLAG
|
||||
contract.yaml`. Preserve `on: workflow_dispatch` inputs (mode choice
|
||||
default full; environment choice default "") + `permissions: {id-token:
|
||||
write, contents: read}` + `secrets: inherit`.
|
||||
- **Task 0.2** (blockchain-engineer): update
|
||||
`nova-blockchain-exchange/tests/test_deploy_workflow_invocation.py` +
|
||||
`test_deploy_gitea_invocation.py` — assert no cross-repo `uses:`,
|
||||
assert `ref: v1.25`, assert `secrets: inherit`, assert
|
||||
`run_platform.sh` invoked, assert `AWS_DEFAULT_REGION` wired.
|
||||
- **Task 0.3** (lead-developer): `acdl/.github/workflows/deploy.yml`
|
||||
stays as the GitHub Actions reference impl (the `workflow_call`
|
||||
reusable workflow — used by GitHub-hosted consumers); document in
|
||||
`adapters/README.md` that Gitea consumers use the inline adapter, not
|
||||
the reusable `uses:`.
|
||||
|
||||
### Wave 0.5 — kyverno-json substrate fix (v1.25 skip-masked bug) — backend-engineer
|
||||
> The v1.25 kyverno-json engine + policies were never validated
|
||||
> against the real `kj` binary (tests `pytest.skip("kj not installed")`
|
||||
> when absent). With `kj` now installed (v0.0.3), 3 policy tests
|
||||
> failed. Root cause: (a) `kj` v0.0.3 does not load `.json` policy
|
||||
> files (only `.yaml`/`.yml`) — the engine now materializes `.yaml`
|
||||
> twins at runtime; (b) the `validate` wrapper is not supported —
|
||||
> `assert` goes directly under the rule; (c) the check syntax was
|
||||
> inverted (`expression: expected_value`, not `key: expression`);
|
||||
> (d) the engine `_translate` expected `{"results": [...]}` but `kj`
|
||||
> returns a bare list with `results[].policy.metadata.name` +
|
||||
> `results[].rules[].violations[]`. DONE (committed 59d837f). Also
|
||||
> fixed `scripts/install-kyverno-json.sh` (the `cmd/kj@latest` path
|
||||
> fails — the real binary is `kyverno-json`, symlinked as `kj`).
|
||||
- **Task 0.5.1** (backend-engineer): rewrite
|
||||
`adapters/kyverno-json/kyverno_json_engine.py` `_translate` for the
|
||||
bare-list output format + add `_materialize_yaml_policy_dir` (DONE).
|
||||
- **Task 0.5.2** (backend-engineer): remove the `validate` wrapper +
|
||||
fix check syntax across all 16 existing policies (DONE).
|
||||
- **Task 0.5.3** (backend-engineer): fix
|
||||
`scripts/install-kyverno-json.sh` (DONE).
|
||||
- **Task 0.5.4** (backend-engineer): resolve pre-existing P2 drift
|
||||
uncovered by the full-suite run — dynamodb `examples/simple.yml` +
|
||||
`complex.yml`, `sync_workflows` re-sync, CAP-024 deck path
|
||||
(`nova-autonomous-cloud-delivery-marp.md`) + slide-count bound +
|
||||
`class="benefit"` div count (DONE, committed 3735330).
|
||||
|
||||
### Wave 1 — DynamoDB primitive (REQ-322) — data-engineer — verify-only (done in P2 W0)
|
||||
- **Task 1.1** (data-engineer): verify `modules/l1/dynamodb/` resolves
|
||||
+ emits valid Terraform via `tests/test_adapter.py` (the primitive
|
||||
shipped in P2 W0; this wave is a re-verify, not re-authoring).
|
||||
|
||||
### Wave 2 — metric grounding (REQ-317, REQ-318) — backend-engineer + data-engineer — parallel
|
||||
- **Task 2.1** (backend-engineer): `core/metrics/outcome_backfill.py` —
|
||||
`backfill(decision_id, outcome)` updates `fact_decision.outcome` +
|
||||
`backfilled_at`. Reads run-manifest events.
|
||||
- **Task 2.2** (backend-engineer): `core/metrics/collector.py` —
|
||||
invokes backfill after run completion.
|
||||
- **Task 2.3** (backend-engineer): `tests/test_outcome_backfill.py`.
|
||||
- **Task 2.4** (backend-engineer): `core/confidence_signal.py` —
|
||||
`ai.decision.made` gains `escalation_reason: 'confidence'` when
|
||||
`band == 'block'`.
|
||||
- **Task 2.5** (backend-engineer): `core/metrics/collector.py` —
|
||||
persists `escalation_reason` into `fact_run`.
|
||||
- **Task 2.6** (backend-engineer): `tests/test_confidence_escalation_reason.py`.
|
||||
|
||||
### Wave 3 — env-JSON wiring + adapter (REQ-319) — backend-engineer + data-engineer — parallel
|
||||
- **Task 3.1** (backend-engineer): `adapters/terraform/adapter.py` —
|
||||
reads `env.state_backend.bucket` when present (fallback to computed
|
||||
name for backwards compat).
|
||||
- **Task 3.2** (data-engineer): `core/environments/dev.json` —
|
||||
`account_id` → `581513795199`, `state_backend.bucket` →
|
||||
`nova-tfstate-581513795199-us-east-1`.
|
||||
- **Task 3.3** (data-engineer): `core/environments/{qa,prod,dr}.json` —
|
||||
`state_backend.bucket` updated; `account_id` stays placeholder
|
||||
(pilot-readiness policy blocks apply on placeholder, D-208).
|
||||
- **Task 3.4** (backend-engineer): `tests/test_adapter_state_backend.py`.
|
||||
- **Task 3.5** (backend-engineer): `tests/test_adapter.py` — add
|
||||
`dynamodb` to `EXPECTED_L1_KEYS` + a resolution + emission test
|
||||
(cross-territory: data-engineer authored the module, backend-engineer
|
||||
owns the test).
|
||||
|
||||
### Wave 4 — kyverno-json policies (REQ-315, REQ-320) — policy-engineer — parallel
|
||||
- **Task 4.1** (policy-engineer):
|
||||
`adapters/kyverno-json/policies/settlement-finality/all-matches-committed.json`
|
||||
— kyverno-json policy over settlement-service status JSON (asserts
|
||||
`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):
|
||||
`adapters/kyverno-json/policies/pilot-readiness/no-placeholder-account.json`
|
||||
— kyverno-json policy over env JSON (asserts
|
||||
`account_id != "000000000000"`).
|
||||
- **Task 4.3** (policy-engineer): `tests/test_settlement_finality_policy.py`
|
||||
— passing + failing fixtures; **runs against real `kj`** (not skipped
|
||||
— `kj` is installed via `scripts/install-kyverno-json.sh`).
|
||||
- **Task 4.4** (policy-engineer): `tests/test_pilot_readiness_policy.py`
|
||||
— passing (real account) + failing (placeholder) fixtures; **runs
|
||||
against real `kj`** (not skipped).
|
||||
|
||||
### Wave 5 — regression CAP (REQ-316) — backend-engineer
|
||||
- **Task 5.1** (backend-engineer): `core/regression_verify.py` —
|
||||
CAP-025 (live-pilot-apply): the round-trip assertion.
|
||||
- **Task 5.2** (backend-engineer): `tests/test_regression_pilot.py`.
|
||||
|
||||
### Wave 6 — deploy.yml drift fixes (SPEC §5.1/§5.2) — lead-developer + backend-engineer
|
||||
> The platform reference `workflows-src/deploy.yml` (synced to
|
||||
> `.github`+`.gitea`) has three drifts vs the SPEC: (a) `aws-region`
|
||||
> hardcoded `us-east-1` (SPEC wants `NOVA_AWS_REGION`/`AWS_DEFAULT_REGION`
|
||||
> from secret); (b) platform checkout `ref: v1.9` (SPEC wants `v1.25`);
|
||||
> (c) the local `scripts/run_platform.sh` fallback exports raw
|
||||
> `NOVA_AWS_*` names into shell env (SPEC §5.2 constraint: consume as
|
||||
> workflow secrets, not shell env — `blocked_env_vars`).
|
||||
- **Task 6.1** (lead-developer): `workflows-src/deploy.yml` —
|
||||
`aws-region: ${{ secrets.AWS_DEFAULT_REGION || 'us-east-1' }}`;
|
||||
platform checkout `ref: v1.25`; re-sync to `.github`+`.gitea`.
|
||||
- **Task 6.2** (backend-engineer): `scripts/run_platform.sh` — source
|
||||
`AWS_DEFAULT_REGION` from `.env.secrets` for the local fallback (not
|
||||
raw `NOVA_AWS_*`); the CI path already consumes secrets via the
|
||||
`configure-aws-credentials` action.
|
||||
- **Task 6.3** (backend-engineer): `tests/test_deploy_workflow_env_input.py`
|
||||
— assert `AWS_DEFAULT_REGION` wired + `ref: v1.25` + no raw
|
||||
`NOVA_AWS_*` in shell env.
|
||||
|
||||
### Wave 7 — secret rotation scheduled workflow (SPEC §5.9) — lead-developer
|
||||
> SPEC §5.9: "the rotation mechanism must *exist* (not have run)."
|
||||
> A platform-managed scheduled workflow wraps the existing
|
||||
> `scripts/rotate_spike_key.sh` (manual today) on a daily cron.
|
||||
- **Task 7.1** (lead-developer): `workflows-src/rotate-aws-key.yml` —
|
||||
`on: { schedule: [{cron: "0 0 * * *"}], workflow_dispatch:}`,
|
||||
single job that checks out the platform repo + runs
|
||||
`bash scripts/rotate_spike_key.sh` with `NOVA_AWS_*` bootstrap
|
||||
secrets; sync to `.github`+`.gitea`.
|
||||
- **Task 7.2** (lead-developer): verify `scripts/rotate_spike_key.sh`
|
||||
is idempotent (deactivates old key only after the new key propagates
|
||||
to the Gitea Actions secret store).
|
||||
- **Task 7.3** (lead-developer): `tests/test_rotate_key_workflow.py` —
|
||||
structural test (the workflow file declares `schedule` + invokes
|
||||
`rotate_spike_key.sh`); document in `.ciagent/ARCHITECTURE.md` §12.8
|
||||
that the mechanism exists (v0.2 scope: exists-not-ran per SPEC §5.9).
|
||||
|
||||
**Must-haves (verify before ship):**
|
||||
- `pytest tests/` in the platform repo passes (the 170 baseline held
|
||||
inaccurately — the real P2 baseline had 7 pre-existing failures
|
||||
uncovered by W0.5; all now fixed). Full suite green.
|
||||
- `pytest tests/` in the consumer repo passes (deploy invocation tests
|
||||
updated for the inline adapter).
|
||||
- The kyverno-json substrate works against real `kj` (W0.5 — DONE).
|
||||
- The Gitea adapter: consumer `deploy.yml` has no cross-repo `uses:`;
|
||||
inline checkout `acdl@v1.25` + `run_platform.sh` (W0).
|
||||
- The DynamoDB primitive resolves + emits valid Terraform (W1 verify).
|
||||
- The outcome backfill updates `fact_decision.outcome` (not `pending`)
|
||||
(W2).
|
||||
- The `escalation_reason` field is emitted on `block` band (W2).
|
||||
- The adapter reads `env.state_backend.bucket` from the env JSON (W3).
|
||||
- The 2 new kyverno-json policies pass on valid fixtures + fail on
|
||||
invalid fixtures, against real `kj` (W4 — not skipped).
|
||||
- CAP-025 is in the regression gate (W5).
|
||||
- The deploy.yml drifts fixed: `AWS_DEFAULT_REGION` wired, `ref:
|
||||
v1.25`, no raw `NOVA_AWS_*` in shell env (W6).
|
||||
- The rotation scheduled workflow exists (W7).
|
||||
|
||||
**Ship:** tag `v1.25.3`, merge `phase/03` → milestone, Gitea release.
|
||||
Delete `phase/03`.
|
||||
|
||||
---
|
||||
|
||||
## Phase 4 — pilot-run-and-docs (tag v1.25.4)
|
||||
|
||||
**Goal:** The pilot estate runs end-to-end against live AWS
|
||||
`581513795199` (contract resolve → adapter compile → terraform plan →
|
||||
policy scan → confidence signal → attestation → outbox record). Docs +
|
||||
adapter README + onboarding guide are complete.
|
||||
|
||||
**Project:** `nova-blockchain-exchange` (consumer repo — the run) +
|
||||
`acdl` (platform repo — docs).
|
||||
**Branch:** `acdl/phase/04-pilot-run-and-docs` (platform branch for
|
||||
docs); the run happens via the consumer's `deploy.yml` invocation.
|
||||
**Personas:** blockchain-engineer (the run), lead-developer (docs),
|
||||
backend-engineer (regression CAP-025 verification).
|
||||
|
||||
### Wave 1 — the pilot run (REQ-316 verification, live)
|
||||
- **Task 1.1** (blockchain-engineer): trigger the consumer's
|
||||
`deploy.yml` with `mode: full, environment: dev` against
|
||||
`581513795199`. The workflow checks out the consumer + platform
|
||||
repos, runs `run_platform.sh`, applies the contract (ECS +
|
||||
DynamoDB + S3), records the decision + attestation.
|
||||
- **Task 1.2** (backend-engineer): verify CAP-025 (regression gate)
|
||||
passes against the live run.
|
||||
- **Task 1.3** (blockchain-engineer): capture the run's
|
||||
`ai.decision.made` + `attestation.recorded` events from the Decision
|
||||
Ledger → evidence for the milestone ship.
|
||||
|
||||
### Wave 2 — docs (REQ-321)
|
||||
- **Task 2.1** (lead-developer): `adapters/README.md` — new consumer
|
||||
row + fix the stale `TYPE_MAP` references (IDEATE I8).
|
||||
- **Task 2.2** (lead-developer): `docs/METRICS.md` — Post-Pilot metrics
|
||||
grounded note (the 3 targets now have non-zero denominators post-run).
|
||||
- **Task 2.3** (lead-developer): `.ciagent/ARCHITECTURE.md` §12.8
|
||||
(Pilot Estate).
|
||||
- **Task 2.4** (lead-developer):
|
||||
`.ciagent/nova-blockchain-exchange/README.md` — consumer onboarding
|
||||
guide (how to invoke `deploy.yml@v1.25`, what secrets to set, what
|
||||
the contract shape is).
|
||||
|
||||
**Must-haves (verify before ship):**
|
||||
- The pilot run completes end-to-end (apply succeeds, decision recorded,
|
||||
attestation recorded for dev — autonomous, no human approver).
|
||||
- CAP-025 passes.
|
||||
- The 3 Post-Pilot metrics have non-zero denominators (the run
|
||||
contributed to `fact_run` + `fact_decision`).
|
||||
- Docs are complete (adapter README, METRICS.md, ARCHITECTURE.md §12.8,
|
||||
consumer onboarding guide).
|
||||
|
||||
**Ship:** tag `v1.25.4`, merge `phase/04` → milestone, Gitea release.
|
||||
Delete `phase/04`.
|
||||
|
||||
---
|
||||
|
||||
## Phase 5 — final review + audit + milestone ship (tag v1.25.5)
|
||||
|
||||
**Goal:** Multi-persona code review across P1..P4. Audit (reconstruction
|
||||
test, branch hygiene, commit discipline). Milestone ship: merge to main,
|
||||
tag `v1.25.5` (= the v1.26 release), Gitea release with full milestone
|
||||
summary, delete all milestone branches.
|
||||
|
||||
**Project:** both (`acdl` + `nova-blockchain-exchange`).
|
||||
**Branch:** `phase/05-final-review-ship`.
|
||||
**Personas:** lead-developer (review + audit + ship), backend-engineer
|
||||
(review), data-engineer (review), policy-engineer (review),
|
||||
blockchain-engineer (review — the chain core is reviewed).
|
||||
|
||||
### Wave 1 — review
|
||||
- **Task 1.1** (lead-developer): `ciagent-review` — multi-persona code
|
||||
review across P1..P4. Auto-fix P0; flag P1+ for post-hoc review.
|
||||
- **Task 1.2** (all personas): fix P0 issues in this phase.
|
||||
|
||||
### Wave 2 — audit
|
||||
- **Task 2.1** (lead-developer): `ciagent-audit` — reconstruction test
|
||||
(git log ↔ `.ciagent/`), branch hygiene, commit discipline.
|
||||
- **Task 2.2** (lead-developer): fix critical audit issues in this phase.
|
||||
|
||||
### Wave 3 — milestone ship
|
||||
- **Task 3.1** (lead-developer): merge `phase/05` →
|
||||
`milestone/v1.26-pilot-activation` → `main`.
|
||||
- **Task 3.2** (lead-developer): tag `v1.25.5` (= the v1.26 release per
|
||||
prev-minor tagging rule).
|
||||
- **Task 3.3** (lead-developer): create Gitea release with full milestone
|
||||
summary (all phases, all 13 requirements).
|
||||
- **Task 3.4** (lead-developer): delete all milestone branches (local +
|
||||
remote). Tags preserve all history.
|
||||
- **Task 3.5** (lead-developer): update `.ciagent/nova-blockchain-exchange/REQUIREMENTS.md`
|
||||
(mark REQ-310..322 complete), `.ciagent/ROADMAP.md` (mark v1.26
|
||||
complete), `.ciagent/NORTH_STAR.md` (note Strategic Objectives #1 +
|
||||
#3 — first real consumer estate; Post-Pilot denominators activated).
|
||||
#### Wave 3 — milestone ship
|
||||
- **Task 3.1** (lead-developer): merge `phase/03` →
|
||||
`milestone/v1.27-po-state-catalog` → `main`.
|
||||
- **Task 3.2** (lead-developer): tag `v1.26.3` (= the v1.27 release per
|
||||
prev-minor tagging rule; v1.27 is an NFR milestone, tags on v1.26.x).
|
||||
- **Task 3.3** (lead-developer): create Gitea release with full
|
||||
milestone summary.
|
||||
- **Task 3.4** (lead-developer): delete all milestone branches (local
|
||||
+ remote). Tags preserve all history.
|
||||
- **Task 3.5** (lead-developer): update `.ciagent/REQUIREMENTS.md`
|
||||
(no REQs to mark — NFR milestone), `.ciagent/ROADMAP.md` (mark
|
||||
v1.27 complete), `.ciagent/NORTH_STAR.md` (no strategic change),
|
||||
`.ciagent/STATE.md` (bump "Last milestone ship" to v1.27).
|
||||
- **Task 3.6** (lead-developer): write checkpoint `stage: complete,
|
||||
phase: 5, phase_role: final` + clear checkpoint (milestone complete).
|
||||
phase: 3, phase_role: final` + clear checkpoint (milestone
|
||||
complete).
|
||||
|
||||
**Must-haves (verify before ship):**
|
||||
- Review: 0 P0 issues unfixed; P1+ flagged for post-hoc.
|
||||
- Audit: reconstruction test passes; branch hygiene clean; commit
|
||||
discipline clean.
|
||||
- Ship: `v1.25.5` tag exists; Gitea release created; milestone branches
|
||||
deleted; main has the milestone merge.
|
||||
- Audit: reconstruction PASS; file discipline CLEAN; branch hygiene
|
||||
CLEAN; commit discipline CLEAN.
|
||||
- Ship: `v1.26.3` tag exists; Gitea release created; milestone
|
||||
branches deleted; main has the milestone merge.
|
||||
|
||||
---
|
||||
|
||||
## Requirement → Phase Mapping
|
||||
|
||||
| REQ | Phase | Wave | Persona |
|
||||
|---|---|---|---|
|
||||
| REQ-310 (blockchain core) | P1 | W1 | blockchain-engineer |
|
||||
| REQ-311 (order engine) | P1 | W2 | blockchain-engineer |
|
||||
| REQ-312 (settlement) | P1 | W2 | blockchain-engineer |
|
||||
| REQ-313 (contract.yaml) | P2 | W1 | blockchain-engineer |
|
||||
| REQ-314 (deploy invocation) | P2 | W2 | blockchain-engineer |
|
||||
| REQ-315 (settlement-finality policy) | P3 | W4 | policy-engineer |
|
||||
| REQ-316 (pilot regression CAP) | P3 | W5 + P4 W1 | backend-engineer |
|
||||
| REQ-317 (outcome backfill) | P3 | W2 | backend-engineer |
|
||||
| REQ-318 (escalation reason) | P3 | W2 | backend-engineer |
|
||||
| REQ-319 (env-JSON wiring) | P3 | W3 | backend + data-engineer |
|
||||
| REQ-320 (pilot-readiness policy) | P3 | W4 | policy-engineer |
|
||||
| REQ-321 (docs) | P4 | W2 | lead-developer |
|
||||
| REQ-322 (DynamoDB primitive) | P3 | W1 | data-engineer |
|
||||
No REQ-NNN (NFR milestone). The work items are file operations,
|
||||
traced by the Wave tasks above.
|
||||
|
||||
---
|
||||
|
||||
## Wave Ordering Rationale
|
||||
|
||||
- **P1 W1 → W2:** the chain core (block + ledger + validator) must land
|
||||
before the order engine + settlement (they submit transactions to the
|
||||
ledger). W3 (CI) is cross-cutting + can land any time after W1.
|
||||
- **P2 W1 → W2:** the contract must land before the deploy invocation
|
||||
(the invocation references the contract). W3 (floating tag) is cross-
|
||||
cutting.
|
||||
- **P3 W1 (DynamoDB) first:** the contract (P2) references `dynamodb` —
|
||||
the primitive must exist before P2's contract can resolve. **Risk:**
|
||||
P2's contract references a module that doesn't exist until P3. Resolution: P2's contract is authored but the `test_contract_validates.py` test only checks schema validity (not registry resolution) — the registry resolution test is in P3 (after the primitive lands). The contract's `dynamodb` block is schema-valid (the schema is open); the registry resolution happens at apply time (P4).
|
||||
- **Alternative:** move REQ-322 to P2 W0 (before the contract). This
|
||||
avoids the P2→P3 dependency. **Decision: move REQ-322 to P2 W0.**
|
||||
See revised mapping below.
|
||||
|
||||
### Revised: REQ-322 → P2 W0
|
||||
|
||||
REQ-322 (DynamoDB primitive) lands in P2 Wave 0 (before the contract)
|
||||
so the contract's `dynamodb` block resolves at registry time, not just
|
||||
schema time. This makes P2 self-contained: the primitive + the contract
|
||||
+ the deploy invocation all land in P2.
|
||||
|
||||
| REQ | Phase | Wave | Persona |
|
||||
|---|---|---|---|
|
||||
| REQ-310 (blockchain core) | P1 | W1 | blockchain-engineer |
|
||||
| REQ-311 (order engine) | P1 | W2 | blockchain-engineer |
|
||||
| REQ-312 (settlement) | P1 | W2 | blockchain-engineer |
|
||||
| REQ-322 (DynamoDB primitive) | P2 | W0 | data-engineer |
|
||||
| REQ-313 (contract.yaml) | P2 | W1 | blockchain-engineer |
|
||||
| REQ-314 (deploy invocation) | P2 | W2 | blockchain-engineer |
|
||||
| REQ-315 (settlement-finality policy) | P3 | W4 | policy-engineer |
|
||||
| REQ-316 (pilot regression CAP) | P3 | W5 + P4 W1 | backend-engineer |
|
||||
| REQ-317 (outcome backfill) | P3 | W2 | backend-engineer |
|
||||
| REQ-318 (escalation reason) | P3 | W2 | backend-engineer |
|
||||
| REQ-319 (env-JSON wiring) | P3 | W3 | backend + data-engineer |
|
||||
| REQ-320 (pilot-readiness policy) | P3 | W4 | policy-engineer |
|
||||
| REQ-321 (docs) | P4 | W2 | lead-developer |
|
||||
|
||||
This revision is a binding plan decision (G-Q8 in the grill may
|
||||
challenge it).
|
||||
- **P1 W1 → W2:** verify STATE.md before archiving (the archive removes
|
||||
the source-of-truth CAPABILITY_INVENTORY; STATE.md must be accurate
|
||||
first).
|
||||
- **P1 W2 → W3:** platform archive before consumer archive (the
|
||||
platform archive pattern is established; the consumer archive
|
||||
creates a new subdir).
|
||||
- **P2 W1 → W2 → W3:** PROJECT.md fix before ROADMAP.md fix before
|
||||
ship-discipline wiring (PROJECT is the source-of-truth narrative;
|
||||
ROADMAP mirrors it; PLAN/NORTH_STAR wire the convention).
|
||||
- **P2 W4:** archive README + consumer pointer (cross-cutting; lands
|
||||
after the active-file fixes).
|
||||
- **P2 W5:** dangling-reference fixes (lands after all moves + edits
|
||||
are known).
|
||||
|
||||
---
|
||||
|
||||
## Future Hardening Items (not in v1.26 scope, documented per grill G-Q9)
|
||||
## Vertical-slice integrity
|
||||
|
||||
- **`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).
|
||||
Each phase ships a self-contained, verifiable slice:
|
||||
- P1 ships STATE.md (verified accurate) + 8 archived files (verified
|
||||
moved). The active `.ciagent/` root drops from 25 to 17 files.
|
||||
- P2 ships 3 fixed files + 3 wired files + archive README + consumer
|
||||
pointer. The kept files match CHECKPOINT.json state.
|
||||
- P3 ships the milestone release + cleared checkpoint.
|
||||
|
||||
---
|
||||
|
||||
## Durable convention (v1.27 establishes)
|
||||
|
||||
The P-final (milestone-ship) Wave 3 file-update list for every future
|
||||
milestone includes `.ciagent/STATE.md`:
|
||||
|
||||
1. Append new capability entries for each shipped REQ (one row per
|
||||
capability; group by domain).
|
||||
2. Mark any deprecated capability with a `Deprecated` row citing the
|
||||
milestone + replacement.
|
||||
3. Bump the "Last milestone ship" header in STATE.md.
|
||||
|
||||
This is wired into the v1.25 + v1.26 P5 "Updated at ship" lists in
|
||||
`ROADMAP.md` (see those sections). The next milestone's P0 PLAN.md
|
||||
inherits this convention by reading ROADMAP.md.
|
||||
+13
-6
@@ -129,7 +129,11 @@ human at stage gates" model from the NORTH_STAR.
|
||||
|
||||
## Capability Status (Re-Verified 2026-07-27)
|
||||
|
||||
> Source of truth: `.ciagent/CAPABILITY_INVENTORY.md` (Phase 54, D-093).
|
||||
> **PO-facing capability catalog:** `.ciagent/STATE.md` (additive;
|
||||
> updated at milestone ship). CAP-NNN IDs cross-reference the regression
|
||||
> gate at `core/regression_verify.py`.
|
||||
> Source of truth (the 2026-07-27 sweep, archived v1.27):
|
||||
> `.ciagent/archive/CAPABILITY_INVENTORY-v1.10.md` (Phase 54, D-093).
|
||||
> Tier: **local** = runs via emulating adapters (no AWS); **live-aws** =
|
||||
> runs against the live AWS account (581513795199).
|
||||
|
||||
@@ -156,7 +160,7 @@ service live, CloudFront production stack, uptime-kuma, OIDC role). The
|
||||
code would deploy them; the local emulators (Phase 53) prove the runtime
|
||||
behavior. Re-bootstrap of the OIDC role + IAM re-grant requires an admin
|
||||
principal — escalated, not silently skipped. See
|
||||
`CAPABILITY_INVENTORY.md` §"Cloud capabilities NOT re-verified".
|
||||
`CAPABILITY_INVENTORY-v1.10.md` §"Cloud capabilities NOT re-verified".
|
||||
|
||||
**Regression gate.** `bash scripts/run_regression.sh` re-runs all 16
|
||||
auto-verifiable capabilities and fails closed on any non-Verified result.
|
||||
@@ -421,14 +425,17 @@ already exist).
|
||||
- The consumer deploy MUST go through `deploy.yml@v1.25` — no direct
|
||||
`terraform apply` bypassing the platform's gates.
|
||||
|
||||
### v1.26 phase status (live — see CHECKPOINT.json for the authoritative state)
|
||||
### v1.26 phase status (shipped — tag `v1.25.5` = the v1.26 release, merged to main 2026-08-19)
|
||||
|
||||
- **P0** pre-execution (SPECIFY→CLARIFY→RESEARCH→IDEATE→PLAN→GRILL) — complete, tag `v1.25.0`.
|
||||
- **P1** blockchain-core (REQ-310,311,312) — complete, tag `v1.25.1`.
|
||||
- **P2** consumer-contract-and-deploy (REQ-313,314,322) — complete, tag `v1.25.2`.
|
||||
- **P3** pilot-metrics-and-policies (REQ-315,316,317,318,319,320) — pending.
|
||||
- **P4** pilot-run-and-docs (REQ-316,321) — pending.
|
||||
- **P5** final review + audit + milestone ship — pending. Tag `v1.25.5` = the v1.26 release.
|
||||
- **P3** pilot-metrics-and-policies (REQ-315,316,317,318,319,320) — complete, tag `v1.25.3`.
|
||||
- **P4** pilot-run-and-docs (REQ-316,321) — complete, tag `v1.25.4` (live apply against `581513795199` succeeded; confidence 0.800 pass; outcome backfilled).
|
||||
- **P5** final review + audit + milestone ship — complete, tag `v1.25.5` = the v1.26 release (PROCEED; 0 P0 remain; audit CLEAN; merged to main).
|
||||
|
||||
> Phase-by-phase task breakdown, wave ordering, and persona assignments
|
||||
> live in `.ciagent/PLAN.md` (the active phase plan, retained in full).
|
||||
> v1.26 pre-execution artifacts (CLARIFY/GRILL/IDEATE/RESEARCH) are in
|
||||
> git history (pre-v1.27-P0 commits); the v1.26 phase verifications +
|
||||
> review are archived at `.ciagent/archive/{VERIFY-P03,VERIFY-P04,REVIEW-AUDIT-P05}.md`.
|
||||
+103
-209
@@ -1,250 +1,144 @@
|
||||
# Nova — v1.26 Research Findings
|
||||
# Nova — v1.27 Research Findings
|
||||
|
||||
> Phase: research (pre-execution). Milestone: v1.26 (Live Pilot Estate
|
||||
> Activation). Status: research. Researcher: ci-researcher.
|
||||
> Phase: research (pre-execution). Milestone: v1.27 (PO State Catalog &
|
||||
> Ciagent Compression). Status: research. Researcher: ci-researcher.
|
||||
> Autonomy: full.
|
||||
|
||||
---
|
||||
|
||||
## 1. Domain — Homegrown PoA Blockchain for Securities Settlement
|
||||
|
||||
### 1.1 Why a homegrown chain (not Ethereum/Solana/Hyperledger)
|
||||
|
||||
The pilot's purpose is to exercise the Nova platform's deploy/policy/
|
||||
attestation gates over a real consumer estate — not to build a
|
||||
production blockchain. A homegrown PoA ledger is the minimal viable
|
||||
chain: append-only blocks, single validator (pilot), SHA-256 hash chain,
|
||||
deterministic block production. It records every order, match, and
|
||||
settlement as transactions; settlement finality = block commit. This
|
||||
is sufficient to demonstrate that Nova's policy engine (kyverno-json)
|
||||
can assert settlement finality declaratively (REQ-315) and that the
|
||||
Decision Ledger captures the apply decision.
|
||||
|
||||
A production chain (Ethereum/Solana/Hyperledger) would be the *consumer
|
||||
app's* choice, not the platform's. The platform is chain-agnostic — it
|
||||
deploys whatever the consumer's `contract.yaml` declares. For the pilot,
|
||||
the homegrown chain is the simplest way to produce a real consumer
|
||||
estate without a heavyweight external dependency.
|
||||
|
||||
### 1.2 PoA consensus — single validator (pilot)
|
||||
|
||||
Proof-of-Authority with a single validator is the minimal consensus
|
||||
model: the validator proposes + commits blocks. No Byzantine fault
|
||||
tolerance (single validator = no forks). Deterministic block
|
||||
production: same ordered transactions → same block (same hash). This
|
||||
makes the chain auditable (the hash chain is verifiable) and
|
||||
reproducible (a replay produces the same chain). Multi-validator BFT
|
||||
is a future milestone (D-201).
|
||||
|
||||
### 1.3 T+1 settlement finality
|
||||
|
||||
Equities settle T+1 (trade date + 1 business day). The pilot's
|
||||
settlement service records matches as transactions on the chain; a
|
||||
settlement is final when its block is committed. The settlement-finality
|
||||
kyverno-json policy (REQ-315) asserts `all_committed: true` before any
|
||||
promotion (qa→prod) — the declarative gate that turns settlement
|
||||
finality into a policy artifact. This is the securities-specific
|
||||
extension of v1.25's policy engine: the same `KyvernoJsonEngine`
|
||||
evaluates a policy over a new payload shape (settlement-service status
|
||||
JSON).
|
||||
|
||||
### 1.4 Equities-only scope (D-200)
|
||||
|
||||
Bonds (T+2), derivatives (varying), and options (exercise models) have
|
||||
different settlement models. A pilot should demonstrate the Nova
|
||||
platform's gates over the simplest case (equities T+1) before
|
||||
expanding. "All types of securities" is the product vision; v1.26 is
|
||||
the pilot (equities first). Future milestones add other security types
|
||||
with their settlement models.
|
||||
v1.27 is an NFR milestone (docs/chore only, no code, no schema). There
|
||||
is no new domain to research. The research is a codebase-grounded
|
||||
inventory of (a) the files to archive + their staleness evidence, and
|
||||
(b) the sources backing the STATE.md capability backfill. This file
|
||||
records the inventory for the v1.27 record; the active authoring used
|
||||
these sources directly.
|
||||
|
||||
---
|
||||
|
||||
## 2. Nova Consumer Deploy Model
|
||||
## 1. Files to archive (staleness inventory)
|
||||
|
||||
### 2.1 The reusable `deploy.yml@v1.25` workflow
|
||||
### 1.1 Pre-execution artifacts (v1.26 — shipped, decisions folded)
|
||||
|
||||
The platform's `.github/workflows/deploy.yml` is a `workflow_call` —
|
||||
a reusable workflow that a consumer repo invokes via
|
||||
`uses: acdl/.github/workflows/deploy.yml@v1.25`. Inputs: `contract`
|
||||
(default `.nova/contract.yml`), `mode` (default `full`; enum
|
||||
`full|plan-only|check-only|decommission`), `environment` (override).
|
||||
The workflow checks out the consumer repo + the platform repo, runs
|
||||
`scripts/run_platform.sh`, and records the apply decision +
|
||||
attestation in the Decision Ledger. Secrets: `NOVA_AWS_*`
|
||||
(account + access key + secret) + `NOVA_LAMBDA_URL` (error reporting).
|
||||
| File | Lines | Staleness evidence | Decisions folded into |
|
||||
|---|---|---|---|
|
||||
| `CLARIFY.md` | 225 | v1.26 milestone shipped (`v1.25.5`); decisions D-200..D-213 | `PROJECT.md` load-bearing decisions |
|
||||
| `GRILL.md` | 225 | v1.26 grill verdict PROCEED 0.84; binding revisions applied | `PLAN.md` revisions (G-Q4 REQ-322→P2 W0; G-Q6 enforcement deferred; G-Q9 key-split future) |
|
||||
| `IDEATE.md` | 193 | all 7 accepted ideas → REQ-315..322 (shipped) | `REQUIREMENTS.md` v1.26 traceability |
|
||||
| `RESEARCH.md` | 250 | v1.26 domain research (blockchain, deploy, modules, metrics) | `ARCHITECTURE.md` §12.8; shipped REQs |
|
||||
|
||||
The pilot consumer (`nova-blockchain-exchange`) invokes this workflow
|
||||
with `mode: full` for `dev` (D-209). The `.gitea/workflows/deploy.yml`
|
||||
mirror is byte-identical (the platform's deploy workflow is
|
||||
forge-agnostic — Gitea + GitHub).
|
||||
All four are pre-execution artifacts for a shipped milestone. The next
|
||||
P0 writes fresh versions. Per D-219 (user-confirmed) + D-222: archive
|
||||
all four with `-v1.26` suffixes.
|
||||
|
||||
### 2.2 `run_platform.sh --apply` path (confirmed)
|
||||
### 1.2 Phase verifications + review (v1.26 — shipped, PASS)
|
||||
|
||||
`scripts/run_platform.sh:431-455` — the `--apply` (or `mode: full`)
|
||||
path runs `terraform apply -auto-approve` after the HITL gate
|
||||
(`:438`). For `dev` (autonomous, no HITL gate), the apply proceeds
|
||||
directly. The apply records the env via `core/env_transition.py record`
|
||||
(`:450`). The full pipeline (no `--apply` flag) continues to Step 7
|
||||
(confidence signal) + Step 8 (outbox write).
|
||||
| File | Lines | Staleness evidence |
|
||||
|---|---|---|
|
||||
| `VERIFY-P03.md` | 39 | v1.26 P3 verification — PASS; shipped `v1.25.3` |
|
||||
| `VERIFY-P04.md` | 31 | v1.26 P4 verification — PASS; shipped `v1.25.4` |
|
||||
| `REVIEW-AUDIT-P05.md` | 218 | v1.26 P5 final review + audit — PROCEED; shipped `v1.25.5`; 0 P0 remain; audit CLEAN |
|
||||
| `P4-PILOT-RUN-EVIDENCE.md` | 46 | v1.26 live apply evidence (`blkex-pilot-apply-v0.2`); summarized in `nova-blockchain-exchange/README.md` §5 + REVIEW-AUDIT-P05 §2.2 |
|
||||
|
||||
**Gap (noted in RESEARCH §4):** the `--apply` path exits before the
|
||||
outbox write (Step 8). The pilot runs the full pipeline (not `--apply`
|
||||
alone), so the outbox write happens. The `run.completed` event lands in
|
||||
the JSONL Decision Ledger (not the DynamoDB outbox) — this is by design
|
||||
(the outbox is the platform-run evidence stream; the Decision Ledger is
|
||||
the cold store for metrics).
|
||||
### 1.3 Durable references (superseded or stale)
|
||||
|
||||
### 2.3 Contract schema — multi-module manifest
|
||||
| File | Lines | Staleness evidence | Superseded by |
|
||||
|---|---|---|---|
|
||||
| `CAPABILITY_INVENTORY.md` | 120 | dated 2026-07-27; framed as "v1.1→v1.8 re-verification sweep"; predates v1.26 pilot (CAP-025 absent; blockchain capabilities absent) | `STATE.md` (this milestone) |
|
||||
| `AUTONOMY_THESIS.md` | 65 | "Last refined: v1.21"; thesis fully folded into `NORTH_STAR.md` Vision (lines 17–22) + Anti-Goals #2 | `NORTH_STAR.md` |
|
||||
| `COST.md` | 106 | dated 2026-07-29; framed "v1.0 → v1.14"; predates v1.26 live pilot (ECS + ALB + DynamoDB + S3 costs not reflected) | A future cost milestone writes a fresh report; `STATE.md` Domain 7 notes cost tracking as a capability |
|
||||
|
||||
`schemas/contract.schema.json:7,24-48` — required fields: `id`,
|
||||
`name`, `environment`, `infrastructure`. The `infrastructure` block is
|
||||
`minProperties: 1` with `patternProperties` accepting any module name
|
||||
key. Multi-module manifest is supported: one contract can declare
|
||||
`infrastructure: { microservice: {...}, dynamodb: {...}, s3: {...} }`.
|
||||
The constraint is the `modules/registry.json` (the module must be
|
||||
registered), not the schema.
|
||||
### 1.4 Consumer-side (nova-blockchain-exchange)
|
||||
|
||||
| File | Lines | Staleness evidence |
|
||||
|---|---|---|
|
||||
| `nova-blockchain-exchange/ROADMAP.md` | 57 | marks P3/P4/P5 as "planned" but v1.26 shipped (`v1.25.5`); phase narrative preserved in platform `ROADMAP.md` v1.26 section |
|
||||
|
||||
Per D-221: consumer archives land in
|
||||
`.ciagent/nova-blockchain-exchange/archive/ROADMAP-v1.26.md`.
|
||||
|
||||
---
|
||||
|
||||
## 3. Platform Module Readiness (the critical finding)
|
||||
## 2. Files to keep active (no-edit or fix-only)
|
||||
|
||||
### 3.1 The adapter is stateless (v1.11 rewrite)
|
||||
### 2.1 No-edit (live code paths or durable)
|
||||
|
||||
`adapters/terraform/adapter.py:1-11` — the adapter is a "STATELESS
|
||||
ASSEMBLER" that owns no module content. There is **no `TYPE_MAP`**,
|
||||
`INPUT_MAP`, or `OUTPUT_MAP` (deleted in the v1.11 stateless rewrite;
|
||||
`modules/STANDARDS.md:212-214` confirms). A new stack type requires a
|
||||
new L1 module (`modules/l1/<name>/` with `interface.json` +
|
||||
`terraform/main.tf` + `README.md` + `instance.json`) + a
|
||||
`modules/registry.json` entry — not an adapter change.
|
||||
| File | Why keep active |
|
||||
|---|---|
|
||||
| `CHECKPOINT.json` | Authoritative resume state — never archive |
|
||||
| `config.json` | Operational config — never archive |
|
||||
| `REGRESSION_REPORT.json` | Written by `core/regression_verify.py:705`; read by `core/metrics/collector.py:27` + `trust_snapshot.py:21` + metrics views (D-224: regenerates on next `run_regression.sh`) |
|
||||
| `REGRESSION_REPORT.md` | Written by `core/regression_verify.py:704`; read by `scripts/run_regression.sh` (D-224) |
|
||||
| `PERSONAS.md` | Regenerated at each milestone P0 by the lead-developer; not stale until then |
|
||||
| `IAM_POLICY.md` | Live baseline, test-enforced (`tests/test_iam_policy_baseline.py`); D-207 future key-split pending (D-223) |
|
||||
| `PLAN.md` | Active phase plan; reset to next milestone at next P0 |
|
||||
| `ARCHITECTURE.md` | Durable target architecture (§1–§12 + §12.7 + §12.8 + §12.9) |
|
||||
| `NORTH_STAR.md` | PO strategy; loaded every ci-run via `config.strategic_direction_file` |
|
||||
| `nova-blockchain-exchange/PROJECT.md` | Consumer project charter; D-200..D-205 load-bearing |
|
||||
| `nova-blockchain-exchange/REQUIREMENTS.md` | REQ-310..322 spec intent (shipped but spec stays for reference) |
|
||||
| `nova-blockchain-exchange/README.md` | Consumer onboarding guide; still accurate (deploy workflow, secrets, contract shape, verification) |
|
||||
|
||||
### 3.2 ECS — ready
|
||||
### 2.2 Fix-only (corrections to stale-but-kept files)
|
||||
|
||||
`modules/l1/ecs-service/terraform/main.tf:1,11` —
|
||||
`aws_ecs_task_definition` + `aws_ecs_service`. `interface.json:5-6` —
|
||||
`type: aws:ecs:task_definition`. `registry.json:29-37` — registered.
|
||||
Tests: `test_adapter.py:164-185,257-360`, `test_contract_resolver.py:61-92`.
|
||||
The `microservice` L2 (`modules/l2/microservice/composition.json`)
|
||||
references 6 L1 children (ecs-cluster, ecr, iam-role, alb, ecs-service,
|
||||
kms-key) — the ECS pattern is fully wired end-to-end.
|
||||
|
||||
### 3.3 S3 — ready
|
||||
|
||||
`modules/l1/s3/terraform/main.tf:1` — `aws_s3_bucket` (+ versioning +
|
||||
SSE). `interface.json:5-6` — `type: aws:s3:bucket`. `registry.json:2-10`
|
||||
— registered. Tests: `test_adapter.py:56-110,241-257`,
|
||||
`test_contract_resolver.py:36-51,92-130`.
|
||||
|
||||
### 3.4 DynamoDB — GAP (REQ-322)
|
||||
|
||||
**No `modules/l1/dynamodb/` directory, no `registry.json` key, no
|
||||
`interface.json`, no `terraform/`, no tests.** The blockchain exchange's
|
||||
ledger table needs this primitive. REQ-322 authors it: `interface.json`
|
||||
(stack type `aws:dynamodb:table`), `terraform/main.tf`
|
||||
(`aws_dynamodb_table` with PK + optional SK, `PAY_PER_REQUEST` default,
|
||||
encryption + PITR enabled per v1.8 NFR defaults), `README.md`,
|
||||
`instance.json`, + `registry.json` entry. The adapter needs no change
|
||||
(stateless); the contract's `infrastructure.dynamodb` block references
|
||||
this primitive. This is the single platform-side module build-out for
|
||||
the milestone.
|
||||
|
||||
### 3.5 Stale doc (not a blocker)
|
||||
|
||||
`adapters/README.md:49-54` references the deleted `TYPE_MAP`/
|
||||
`INPUT_MAP`/`OUTPUT_MAP` — contradicts `adapter.py:1-11` +
|
||||
`modules/STANDARDS.md:212-214`. REQ-321 (docs) should fix this.
|
||||
| File | Fix |
|
||||
|---|---|
|
||||
| `PROJECT.md` | v1.26 phase-status block (lines 424–431): P3/P4/P5 "pending" → "complete" with shipped tags `v1.25.3/4/5`; add STATE.md pointer (D-225: P2 phase) |
|
||||
| `ROADMAP.md` | v1.26 P3/P4/P5 sections (lines 238, 261, 272) "planned" → "complete" with shipped tags; v1.26 Overview line "active" → "complete"; add STATE.md to P5 ship-update list (D-225: P2 phase) |
|
||||
| `archive/README.md` | Add the 11 new archived files to the contents tables (P2 phase) |
|
||||
|
||||
---
|
||||
|
||||
## 4. Metric Pipeline Grounding (Post-Pilot targets)
|
||||
## 3. STATE.md capability backfill sources
|
||||
|
||||
### 4.1 AI Decision Accuracy — outcome backfill (REQ-317)
|
||||
The STATE.md backfill (36 capabilities across 10 domains) was sourced
|
||||
from:
|
||||
|
||||
`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"` — **there is no outcome-backfill step** wiring
|
||||
`run.completed`/`run.failed` back into `fact_decision.outcome`. The AI
|
||||
Decision Accuracy metric (`trust_snapshot.py:70-85`, `_get_ai_decision_accuracy`)
|
||||
reads `decisions WHERE outcome='succeeded' ÷ total` — so it reads 0%
|
||||
today (all pending). REQ-317 adds `core/metrics/outcome_backfill.py`
|
||||
that reads run-manifest events and updates `fact_decision.outcome` +
|
||||
`fact_decision.backfilled_at`. The PCR schema is unchanged (D-211).
|
||||
|
||||
### 4.2 Human Escalation Frequency — `reason='confidence'` tag (REQ-318)
|
||||
|
||||
`core/confidence_signal.py:184` — a `block` band sets
|
||||
`human_override=True` in the `ai.decision.made` event.
|
||||
`run_platform.sh:636` fails the pipeline on `block`. 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 currently
|
||||
stored** — `hitl_block` is a boolean from the manifest. REQ-318 adds
|
||||
`escalation_reason: 'confidence'` to the `ai.decision.made` event when
|
||||
`band == 'block'` + persists it into `fact_run` via the collector.
|
||||
|
||||
### 4.3 Touchless Resolution Rate — denominator activates post-pilot
|
||||
|
||||
`docs/metrics/touchless_resolution_rate.md:12-15` — defined as a SQL
|
||||
query over `fact_run` (`runs WHERE hitl_block=0 ÷ total runs`). The data
|
||||
lands in `fact_run.hitl_block` via `collector.py:216-227`. No dedicated
|
||||
emitter computes the ratio — it's a downstream query. The denominator
|
||||
is 0 today (no consumer runs). The pilot run activates the denominator.
|
||||
| Source | Used for |
|
||||
|---|---|
|
||||
| `core/regression_verify.py` (lines 129–768) | CAP-001..CAP-025 IDs, names, tiers, evidence pointers |
|
||||
| `.ciagent/CAPABILITY_INVENTORY.md` (pre-archive) | CAP-001..022 descriptions, defect notes, evidence |
|
||||
| `modules/registry.json` | L1/L2 module catalog (13 L1 + 2 L2 entries) |
|
||||
| `.ciagent/REQUIREMENTS.md` v1.25 traceability | REQ-291..309 → policy-engine capabilities |
|
||||
| `.ciagent/nova-blockchain-exchange/REQUIREMENTS.md` + `.ciagent/REQUIREMENTS.md` v1.26 traceability | REQ-310..322 → pilot capabilities |
|
||||
| `.ciagent/CHECKPOINT.json` | shipped tags `v1.25.0..v1.25.5` |
|
||||
| `git log --all --oneline` | file paths for v1.26 shipped features |
|
||||
| `.ciagent/PROJECT.md` load-bearing decisions | INV-1..INV-11 invariants |
|
||||
| `docs/submission-readiness.md` + `schemas/contract.schema.json` | INV-1 contract surface |
|
||||
|
||||
---
|
||||
|
||||
## 5. kyverno-json Policy Extensibility
|
||||
## 4. Persona assessment
|
||||
|
||||
`adapters/kyverno-json/kyverno_json_engine.py:74-80` — the engine is
|
||||
**policy-dir agnostic**: it loads whatever subdir the caller passes.
|
||||
Existing subdirs: `contract/`, `stack-ir/`, `plan-json/`, `meta/`,
|
||||
`regression/`. Adding a new subdir (e.g. `pilot-readiness/`,
|
||||
`settlement-finality/`) requires: (1) `mkdir
|
||||
adapters/kyverno-json/policies/<name>/`, (2) drop `ValidatingPolicy`
|
||||
YAML/JSON files, (3) wire a caller. No engine code change needed.
|
||||
Test pattern: one test file per subdir (`tests/test_<name>_policies.py`).
|
||||
v1.27 is a docs/chore milestone. The active roster:
|
||||
|
||||
The pilot adds two new policy subdirs: `pilot-readiness/`
|
||||
(REQ-320, no-placeholder-account) + `settlement-finality/` (REQ-315,
|
||||
all-matches-committed). Both follow the established pattern.
|
||||
- **lead-developer** (active): owns the milestone narrative (STATE.md
|
||||
authoring, PROJECT/ROADMAP fixes, archive README, PLAN/NORTH_STAR
|
||||
wiring, this RESEARCH, CLARIFY, PLAN, final review + audit). Territory:
|
||||
`.ciagent/`, `docs/`.
|
||||
- **backend-engineer** (active, limited): no code changes in v1.27.
|
||||
Consulted on the `core/confidence_signal.py` LSP diagnostic (pre-
|
||||
existing, not touched by v1.27). No territory writes.
|
||||
- **data-engineer** (inactive): no schema/migration/ORM changes.
|
||||
- **policy-engineer** (inactive): no policy authoring.
|
||||
- **frontend-engineer** (inactive): no UI.
|
||||
- **blockchain-engineer** (inactive): no chain code.
|
||||
|
||||
Territory enforcement: warn. The milestone is `.ciagent/`-only; the
|
||||
lead-developer owns all writes.
|
||||
|
||||
---
|
||||
|
||||
## 6. Env-JSON Wiring Reconciliation (REQ-319)
|
||||
|
||||
`core/environments/dev.json:4` — `account_id: "000000000000"` (placeholder).
|
||||
`core/environment_check.py:48-53` warns (non-fatal) when account_id is
|
||||
placeholder + env != dev. `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`. This is the wiring gap: the env JSON's
|
||||
`state_backend` field is currently unused by the live apply path.
|
||||
REQ-319 makes the adapter read `env.state_backend.bucket` when present
|
||||
(falling back to the computed name for backwards compat) + updates
|
||||
`dev.json` to the real account `581513795199` + real bucket
|
||||
`nova-tfstate-581513795199-us-east-1`.
|
||||
|
||||
---
|
||||
|
||||
## 7. Risk Analysis
|
||||
## 5. Risk analysis
|
||||
|
||||
| Risk | Likelihood | Impact | Mitigation |
|
||||
|---|---|---|---|
|
||||
| `NOVA_AWS_*` key lacks a needed IAM permission mid-pilot | Low (bootstrap succeeded → root-equivalent) | High (blocks apply) | D-207; the key has root-equivalent perms (empirically confirmed). |
|
||||
| DynamoDB primitive takes longer than expected (new module) | Medium | Medium | REQ-322 is the single platform-side build-out; the `s3`/`rds` primitives are the template — straightforward. |
|
||||
| Homegrown chain has a correctness bug (hash chain breaks) | Low | High | REQ-310 tests cover chain integrity, hash determinism, genesis, append/verify. |
|
||||
| `deploy.yml@v1.25` ref doesn't resolve (floating tag) | Low | High | The platform's `release.yml` creates + force-moves the `v1.25` + `v1` floating tags on merge to main. The pilot contract uses `@v1.25`. |
|
||||
| Settlement-finality policy false-negatives (blocks a valid promotion) | Medium | Medium | REQ-315 tests cover passing + failing fixtures; the policy is skip-when-kj-absent (graceful). |
|
||||
| D-083 deferral challenged (audit ledger not tamper-evident) | Low | Low | D-204; the SQLite hash-chain + DynamoDB outbox is the pilot's audit record. Tamper-evidence is a future milestone. |
|
||||
| Archive move breaks a relative path reference in an active file | Low | Medium | `grep` for the archived filenames across `.ciagent/` + `docs/` before commit; fix any dangling references in P2 |
|
||||
| STATE.md capability row is inaccurate (wrong shipped tag / wrong file path) | Medium | Low | The backfill sources are the authoritative registries (regression_verify.py, registry.json, CHECKPOINT.json, git log); citations are direct |
|
||||
| PROJECT.md phase-status fix conflicts with a future v1.26-era commit | Low | Low | v1.26 is shipped (main has the milestone merge); no v1.26-era commits will arrive |
|
||||
| REGRESSION_REPORT stale state is mistaken for v1.27 scope | Low | Low | D-224 records the decision; STATE.md Domain 7 notes the current CAP range |
|
||||
|
||||
---
|
||||
|
||||
## 8. Persona Assessment
|
||||
## 6. Verdict
|
||||
|
||||
See `PERSONAS.md` (next section, produced by the lead-developer at the
|
||||
end of RESEARCH). The active roster: backend-engineer (blockchain core
|
||||
+ settlement + outcome backfill), data-engineer (DynamoDB primitive +
|
||||
metrics cold store), policy-engineer (kyverno-json policies), +
|
||||
blockchain-engineer (custom, phase-specific — chain consensus, order
|
||||
matching, settlement finality). frontend-engineer is deactivated (no
|
||||
UI in the pilot).
|
||||
v1.27 is feasible, scoped, and the sources are grounded. No new domain,
|
||||
no new code, no schema breaks. The archive moves are lossless (git
|
||||
history + archive directory both preserve bytes). The STATE.md
|
||||
backfill is sourced from authoritative registries. Proceed to PLAN.
|
||||
+23
-6
@@ -81,6 +81,19 @@
|
||||
before building the new env). New `core/env_transition.py` module.
|
||||
15 requirements (REQ-276..290), 4 phases.
|
||||
|
||||
- **v1.27:** complete (tag `v1.26.3`) — PO State Catalog & Ciagent
|
||||
Compression. NFR milestone. Authored `.ciagent/STATE.md` (PO-facing
|
||||
capability catalog, 32 CAP rows + 11 invariants across 10 domains,
|
||||
backfilled through v1.26). Archived 7 platform-root files + 1
|
||||
consumer file to `.ciagent/archive/` (CAPABILITY_INVENTORY,
|
||||
REVIEW-AUDIT-P05, VERIFY-P03, VERIFY-P04, P4-PILOT-RUN-EVIDENCE,
|
||||
AUTONOMY_THESIS, COST + nova-blockchain-exchange/ROADMAP). Fixed
|
||||
PROJECT.md + ROADMAP.md v1.26 phase-status (P3/P4/P5 → complete).
|
||||
Wired STATE.md into the P-final ship discipline (PLAN.md, ROADMAP.md,
|
||||
NORTH_STAR.md). Active `.ciagent/` root: 15 .md (was 25) + 1 json + 1
|
||||
checkpoint. 3 phases (P0 pre-execution + P1 author-archive + P2
|
||||
fix-stale-wire + P3 final-review-ship). No REQ-NNN (NFR).
|
||||
|
||||
> **Full v1.0–v1.24 phase detail, wave ordering, success criteria, and
|
||||
> decision cross-references:** `.ciagent/archive/ROADMAP-v1.0-v1.24.md`.
|
||||
|
||||
@@ -173,12 +186,15 @@ final). Tags: `v1.24.0` (P0) → `v1.24.5` (P5 = milestone release).
|
||||
summary; delete all milestone branches.
|
||||
- Updated `REQUIREMENTS.md` (mark REQ-291..309 complete), `ROADMAP.md`
|
||||
(mark v1.25 complete), `NORTH_STAR.md` (note Strategic Objective #2 —
|
||||
provable trust via a replaceable policy-engine substrate).
|
||||
provable trust via a replaceable policy-engine substrate),
|
||||
`STATE.md` (append v1.25 capability rows — note: STATE.md was authored
|
||||
in v1.27 with the v1.25 capabilities backfilled; the v1.25 ship did
|
||||
not update STATE.md because STATE.md did not yet exist).
|
||||
- **Requirements:** REQ-291..309 (19 requirements).
|
||||
|
||||
---
|
||||
|
||||
## v1.26 (active, tag line `v1.25.x`): Live Pilot Estate Activation
|
||||
## v1.26 (complete, tag `v1.25.5` = the v1.26 release, merged to main 2026-08-19): Live Pilot Estate Activation
|
||||
|
||||
`D-096` lifts. The first real consumer estate — a stock exchange on a
|
||||
homegrown Proof-of-Authority blockchain (equities only, single
|
||||
@@ -235,7 +251,7 @@ REQ-315..322), 3 deferred. Adversarial grill: PROCEED 0.84.
|
||||
- Cross-cutting: `v1.25` floating tag → `v1.25.0` (Phase 0 ship) on the
|
||||
platform repo.
|
||||
|
||||
### Phase P3 — pilot-metrics-and-policies (planned, tag v1.25.3)
|
||||
### Phase P3 — pilot-metrics-and-policies (complete, tag v1.25.3)
|
||||
- REQ-315: `adapters/kyverno-json/policies/settlement-finality.json` —
|
||||
kyverno-json policy asserting all matches in the promotion window have
|
||||
committed blocks (securities-specific). Authored + tested in v1.26;
|
||||
@@ -258,7 +274,7 @@ REQ-315..322), 3 deferred. Adversarial grill: PROCEED 0.84.
|
||||
- REQ-320: `adapters/kyverno-json/policies/pilot-readiness/no-placeholder-account.json`
|
||||
— declarative gate preventing apply against a placeholder account.
|
||||
|
||||
### Phase P4 — pilot-run-and-docs (planned, tag v1.25.4)
|
||||
### Phase P4 — pilot-run-and-docs (complete, tag v1.25.4)
|
||||
- REQ-321: `adapters/README.md` (new consumer row) +
|
||||
`docs/METRICS.md` (Post-Pilot metrics grounded note) +
|
||||
`.ciagent/ARCHITECTURE.md` §12.8 (Pilot Estate) +
|
||||
@@ -269,7 +285,7 @@ REQ-315..322), 3 deferred. Adversarial grill: PROCEED 0.84.
|
||||
events land in the Decision Ledger; the regression gate (CAP-025)
|
||||
verifies the round-trip.
|
||||
|
||||
### Phase P5 — final review + audit + milestone ship (Final Phase, planned, tag v1.25.5)
|
||||
### Phase P5 — final review + audit + milestone ship (Final Phase, complete, tag v1.25.5 = the v1.26 release)
|
||||
- Multi-persona code review across P1..P4 (lead-developer, backend-
|
||||
engineer, data-engineer, policy-engineer, blockchain-engineer).
|
||||
Auto-fix P0; flag P1+.
|
||||
@@ -281,7 +297,8 @@ REQ-315..322), 3 deferred. Adversarial grill: PROCEED 0.84.
|
||||
full milestone summary; delete all milestone branches.
|
||||
- Update `REQUIREMENTS.md` (mark REQ-310..322 complete), `ROADMAP.md`
|
||||
(mark v1.26 complete), `NORTH_STAR.md` (note Strategic Objectives #1
|
||||
+ #3 — first real consumer estate; Post-Pilot denominators activated).
|
||||
+ #3 — first real consumer estate; Post-Pilot denominators activated),
|
||||
`STATE.md` (append v1.26 capability rows; bump "Last milestone ship").
|
||||
|
||||
> **Phase task-level breakdown, wave ordering, and persona
|
||||
> assignments:** `.ciagent/PLAN.md` (the active phase plan, retained in
|
||||
|
||||
@@ -0,0 +1,286 @@
|
||||
# Nova — System State (what exists today)
|
||||
|
||||
> **PO-owned catalog of shipped capabilities.** Updated at every milestone
|
||||
> ship (P final). Additive only — entries are appended, never rewritten,
|
||||
> unless a capability is explicitly deprecated (then marked, not deleted).
|
||||
> Read by the PO upstream of the PDLC before authoring new REQ-NNN specs,
|
||||
> and by CIAgent at SPECIFY for capability awareness.
|
||||
>
|
||||
> **Authority:** this file is *descriptive of shipped state*, not
|
||||
> authoritative for live phase/ship state — that's `CHECKPOINT.json`. For
|
||||
> *why*, read `NORTH_STAR.md`. For *how*, read `ARCHITECTURE.md`. For
|
||||
> *what was decided*, read `PROJECT.md` load-bearing decisions.
|
||||
>
|
||||
> **Last milestone ship:** v1.27 (`v1.26.3`, 2026-08-19) — PO State Catalog
|
||||
> & Ciagent Compression NFR milestone. No new capabilities this
|
||||
> milestone (NFR); v1.27 authored this file + compressed `.ciagent/`.
|
||||
> **Next update:** at v1.28 ship.
|
||||
|
||||
## How to use this file (PO)
|
||||
|
||||
- Before writing a new REQ: search this file for the capability you
|
||||
intend to spec. If it exists, extend it; do not re-spec it under a new
|
||||
REQ-NNN.
|
||||
- Respect the **Invariants** below — they are load-bearing and
|
||||
cross-cutting. A new REQ that violates an invariant requires a
|
||||
`CLARIFY` decision recorded in PROJECT.md.
|
||||
- Anchor each new REQ to a **Domain**; new domains require a PO
|
||||
decision recorded in CLARIFY.
|
||||
- When a capability is deprecated (replaced, removed, or
|
||||
re-architecture), append a `Deprecated` row marking the milestone +
|
||||
replacement; do not delete the original entry.
|
||||
|
||||
## Invariants (PO-owned — do not violate in new REQs)
|
||||
|
||||
> Distilled from `PROJECT.md` load-bearing decisions D-034..D-072 +
|
||||
> W1..BA + Q1.3. Cite the decision ID when an REQ touches one.
|
||||
|
||||
- **INV-1 (Contract surface):** The only PDLC→Nova boundary is
|
||||
`schemas/contract.schema.json` + `schemas/submission-readiness.schema.json`
|
||||
(D-133). All consumer intent enters through one of these. Nova never
|
||||
reaches into upstream PDLC.
|
||||
- **INV-2 (Confidence inputs):** Six canonical inputs — policy (0.30),
|
||||
validation (0.25), freshness (0.10), source (0.15), history (0.10),
|
||||
nfrs (0.10). Weights frozen for v1 (D-040). `critical` severity =
|
||||
hard-block via `PENALTY["critical"]: None` (defense-in-depth behind the
|
||||
declarative `block-on-any-critical` meta-policy).
|
||||
- **INV-3 (HITL gates):** dev = autonomous (≥0.50); qa = HITL (≥0.75);
|
||||
prod = HITL (≥0.90); dr = HITL (≥0.95). Approver identity = Gitea
|
||||
`gitea.actor` of the `workflow_dispatch` (D-042). Separation-of-duties
|
||||
on prod reads `approver_qa` from the DynamoDB outbox.
|
||||
- **INV-4 (Engine is swappable):** The policy engine is behind the
|
||||
`PolicyEngine` protocol (`core/policy_engine.py`, v1.25). Confidence
|
||||
signal + pipeline import only the protocol, never a concrete engine.
|
||||
`kyverno-json` is the v1.25 default; `OPA` (or other) implements the
|
||||
same 3-method protocol to replace it.
|
||||
- **INV-5 (Adapter is stateless):** `adapters/terraform/adapter.py` owns
|
||||
no module content — no `TYPE_MAP`/`INPUT_MAP`/`OUTPUT_MAP` (v1.11
|
||||
rewrite). A new stack type requires a new L1 module
|
||||
(`modules/l1/<name>/`) + `registry.json` entry, not an adapter change.
|
||||
- **INV-6 (Audit stream is immutable):** Outbox writes via SQLite
|
||||
hash-chain today (D-083 deferred). S3 Object Lock / JWS tamper-
|
||||
*resistant* ledger is a future milestone. Current stream is tamper-
|
||||
*evident* (any tampering breaks the chain).
|
||||
- **INV-7 (PCR schema is the moat):** `schemas/policy_check_result.schema.json`
|
||||
shape is frozen across adapter swaps (v1.25 hard constraint). The
|
||||
`engine` enum already includes `"kyverno"` + `"opa"`; new engines add
|
||||
no enum value.
|
||||
- **INV-8 (Long-lived creds forbidden):** §12.5. The D-039/D-047 per-run-
|
||||
rotated-key waiver satisfies the *intent* (no *persistently* long-lived
|
||||
key). Real OIDC federation is blocked on `go-gitea/gitea#36988`.
|
||||
- **INV-9 (Two consumer surfaces, one platform):** L3A (developer) +
|
||||
L3B (citizen dev) converge on the same contract schema, the same
|
||||
policy envelope, and the same evidence stream.
|
||||
- **INV-10 (Nova is downstream of PDLC):** Nova governs infra + delivery
|
||||
only. Product backlog, code authorship, IDE workflows, application
|
||||
business logic are upstream. Integration only via the validated
|
||||
contract boundary (INV-1).
|
||||
- **INV-11 (Pilot scope, v1.26):** Equities only (D-200). Single-
|
||||
validator PoA (D-201). D-083 (Object Lock/JWS) stays deferred. Hot
|
||||
path deferred (D-126). Multi-cloud deferred. Multi-validator BFT
|
||||
deferred. The pilot runs `mode: full` for `dev` only (D-209); qa/prod/dr
|
||||
stay placeholder (D-208, blocked by the pilot-readiness policy).
|
||||
|
||||
## Domains (capability groups)
|
||||
|
||||
1. Contract surface
|
||||
2. Modules (L1 primitives + L2 patterns)
|
||||
3. Policy engine
|
||||
4. Confidence signal
|
||||
5. Environments & promotion
|
||||
6. Evidence stream & audit
|
||||
7. Telemetry & metrics
|
||||
8. Consumer surfaces (developer + agentic)
|
||||
9. Pilot estate (v1.26)
|
||||
10. Forge / CI runtime
|
||||
|
||||
## Capabilities (additive — one row per shipped capability)
|
||||
|
||||
> Tier: **local** = runs via emulating adapters (no AWS); **live-aws** =
|
||||
> runs against the live AWS account `581513795199`;
|
||||
> **lifecycle-pipeline** = verified via the `modules-lifecycle`
|
||||
> pipeline's apply→modify→destroy matrix cell.
|
||||
> CAP-NNN IDs cross-reference the regression gate at
|
||||
> `core/regression_verify.py` (the machine registry). This file is the
|
||||
> PO-facing narrative; the machine registry is the source of truth for
|
||||
> the gate.
|
||||
|
||||
### Domain 1 — Contract surface
|
||||
|
||||
| ID | Capability | Shipped | Files | Controlling | Tier | Notes |
|
||||
|----|-----------|---------|-------|-------------|------|-------|
|
||||
| CAP-001 | `contract.schema.json` validates sample contracts | v1.1 / `v1.2.0` | `schemas/contract.schema.json` | REQ-001, D-... | local | shape: id/name/environment/infrastructure |
|
||||
| CAP-002 | `environment.schema.json` validates env files | v1.9 / `v1.9.0` | `schemas/environment.schema.json` | REQ-040 | local | dev/qa/prod/dr env JSONs |
|
||||
| CAP-006 | Contract interpolation expands `${env.*}` / `${contract.*}` | v1.9 / `v1.9.0` | `core/contract_resolver.py` | REQ-040 | local | per-env variants |
|
||||
| — | Submission-readiness gate (superset of contract schema) | v1.18 / `v1.18.0` | `schemas/submission-readiness.schema.json`, `core/submission_readiness.py` | REQ-217, REQ-218, D-133 | local | the only PDLC→Nova boundary (INV-1) |
|
||||
|
||||
### Domain 2 — Modules (L1 primitives + L2 patterns)
|
||||
|
||||
> Source: `modules/registry.json` (the authoritative module catalog).
|
||||
> STATE.md lists the *capability* of having a registered module;
|
||||
> registry.json is the live registry.
|
||||
|
||||
| ID | Capability | Shipped | Files | Controlling | Tier | Notes |
|
||||
|----|-----------|---------|-------|-------------|------|-------|
|
||||
| CAP-003 | contract_resolver resolves `static-assets` (L2) | v1.1 / `v1.2.0` | `core/contract_resolver.py`, `modules/l2/static-assets/` | REQ-003 | local | CloudFront+WAF+S3 pattern |
|
||||
| CAP-004 | contract_resolver resolves `microservice` (L2) | v1.2 / `v1.3.0` | `core/contract_resolver.py`, `modules/l2/microservice/` | REQ-004 | local | ECS Fargate pattern (6 L1 children) |
|
||||
| CAP-005 | Terraform adapter compiles resolved stack to `.tf` | v1.1 / `v1.2.0` | `adapters/terraform/adapter.py` | REQ-005 | local | stateless assembler (v1.11); emits `module "<rid>" { source }` blocks |
|
||||
| — | L1 `s3` primitive | v1.1 / `v1.2.0` | `modules/l1/s3/` | REQ-005 | lifecycle | versioning + SSE-KMS by default |
|
||||
| — | L1 `vpc` primitive | v1.1 / `v1.2.0` | `modules/l1/vpc/` | REQ-005 | lifecycle | shared platform VPC (v1.11) |
|
||||
| — | L1 `ecs-cluster` primitive | v1.1 / `v1.2.0` | `modules/l1/ecs-cluster/` | REQ-005 | lifecycle | |
|
||||
| — | L1 `ecs-service` primitive | v1.1 / `v1.2.0` | `modules/l1/ecs-service/` | REQ-005 | lifecycle | execution_role_arn + task_role_arn wired (P4 W1 fix, v1.26) |
|
||||
| — | L1 `iam-role` primitive | v1.1 / `v1.2.0` | `modules/l1/iam-role/` | REQ-005 | lifecycle | |
|
||||
| — | L1 `alb` primitive | v1.1 / `v1.2.0` | `modules/l1/alb/` | REQ-005 | lifecycle | requires SG wire (P4 W1 fix, v1.26) |
|
||||
| — | L1 `ecr` primitive | v1.1 / `v1.2.0` | `modules/l1/ecr/` | REQ-005 | lifecycle | |
|
||||
| — | L1 `cloudfront` primitive | v1.7 / `v1.7.0` | `modules/l1/cloudfront/` | REQ-049, D-049 | lifecycle | OAC + WAF (production edge) |
|
||||
| — | L1 `waf` primitive | v1.7 / `v1.7.0` | `modules/l1/waf/` | REQ-049, D-049 | lifecycle | |
|
||||
| — | L1 `rds` primitive | v1.7 / `v1.7.0` | `modules/l1/rds/` | REQ-059, D-059 | lifecycle | multi-engine input (postgres/mysql/...) |
|
||||
| — | L1 `kms-key` primitive | v1.8 / `v1.8.0` | `modules/l1/kms-key/` | REQ-069, D-069 | lifecycle | per-stack CMK; 90-day rotation |
|
||||
| — | L1 `uptime` primitive | v1.8 / `v1.8.0` | `modules/l1/uptime/` | REQ-066, D-066 | lifecycle | uptime-kuma on ECS Fargate |
|
||||
| — | L1 `dynamodb` primitive | v1.26 / `v1.25.2` | `modules/l1/dynamodb/` | REQ-322 | local | PK + optional SK; PAY_PER_REQUEST; encryption + PITR by default (v1.8 NFRs) |
|
||||
| CAP-013 | `terraform init+validate+plan` live AWS (microservice) | v1.2 / `v1.3.0` | `adapters/terraform/adapter.py` | REQ-013 | live-aws | 14 resources; plan saved |
|
||||
| CAP-014 | `terraform init+validate+plan` live AWS (static-assets) | v1.7 / `v1.7.0` | `adapters/terraform/adapter.py` | REQ-014 | live-aws | CloudFront+WAF+S3 plan OK |
|
||||
| CAP-017 | DynamoDB `nova-contracts` table | v1.7 / `v1.7.0` | `core/lambda/`, `terraform/` | REQ-068, D-068 | lifecycle | PK `changeRequestId`, SK `submittedAt` (CMDB) |
|
||||
| CAP-018 | Lambda contract-ingestor | v1.7 / `v1.7.0` | `core/lambda/contract_ingestor.py` | REQ-051, D-051 | lifecycle | local stub + lifecycle evidence |
|
||||
| CAP-019 | ECS cluster + service (L2 microservice) | v1.7 / `v1.7.0` | `modules/l2/microservice/` | REQ-066 | lifecycle | apply/modify/destroy exit 0 |
|
||||
| CAP-020 | CloudFront + WAF production stack | v1.7 / `v1.7.0` | `modules/l2/static-assets/` | REQ-049 | lifecycle | apply/modify/destroy exit 0 |
|
||||
| CAP-021 | uptime-kuma monitoring primitive | v1.8 / `v1.8.0` | `modules/l1/uptime/` | REQ-066 | lifecycle | |
|
||||
| CAP-022 | OIDC role for act_runner | v1.11 / `v1.11.0` | `terraform/bootstrap/` | REQ-116, D-039 | lifecycle | real OIDC blocked on go-gitea/gitea#36988 |
|
||||
|
||||
### Domain 3 — Policy engine
|
||||
|
||||
| ID | Capability | Shipped | Files | Controlling | Tier | Notes |
|
||||
|----|-----------|---------|-------|-------------|------|-------|
|
||||
| — | `PolicyEngine` Protocol + `PolicyEngineRegistry` | v1.25 / `v1.24.1` | `core/policy_engine.py` | REQ-291, REQ-292 | local | selects engine from `config.json.policy.engine`; `NullEngine` fallback when key absent |
|
||||
| — | `KyvernoJsonEngine` adapter (shells to `kj scan`) | v1.25 / `v1.24.1` | `adapters/kyverno-json/kyverno_json_engine.py` | REQ-293, REQ-294 | local | `is_configured()` guards on `which kj`; `SKIPPED` PCR when absent |
|
||||
| — | Contract policies (4) over consumer contract JSON | v1.25 / `v1.24.2` | `adapters/kyverno-json/policies/contract/` | REQ-295, REQ-296 | local | id-pattern, env-enum, infra-min-1, forbid-unknown-fields |
|
||||
| — | Stack-IR policies (3) over resolved Target Stack IR | v1.25 / `v1.24.2` | `adapters/kyverno-json/policies/stack-ir/` | REQ-297, REQ-298, REQ-299 | local | tagging-standard, public-ingress, encryption-by-default |
|
||||
| — | Plan-JSON policies (3) over `terraform show -json` | v1.25 / `v1.24.3` | `adapters/kyverno-json/policies/plan-json/` | REQ-300, REQ-301, REQ-302 | local | plaintext-secrets, iam-wildcard, kms-reference |
|
||||
| — | Meta-policies over merged PCR list | v1.25 / `v1.24.3` | `adapters/kyverno-json/policies/meta/` | REQ-303 | local | `block-on-any-critical` (declarative critical-block); `tagging-rules-agree` (Checkov↔kj agree) |
|
||||
| — | Regression-gate policies (3) over capability-inventory JSON | v1.25 / `v1.24.4` | `adapters/kyverno-json/policies/regression/` | REQ-304, REQ-305 | local | declarative mirrors of CAP-013/023/024 imperative checks |
|
||||
| — | Pilot-readiness policy (no placeholder account) | v1.26 / `v1.25.3` | `adapters/kyverno-json/policies/pilot-readiness/no-placeholder-account.json` | REQ-320 | local | fail-closed gate; blocks apply on `account_id == "000000000000"` |
|
||||
| — | Settlement-finality policy | v1.26 / `v1.25.3` | `adapters/kyverno-json/policies/settlement-finality/all-matches-committed.json` | REQ-315 | local | authored + tested; enforcement deferred to milestone that binds qa/prod/dr (D-208) |
|
||||
| — | Checkov adapter (raw-finding source) | v1.7 / `v1.7.0` | `adapters/terraform/checkov_adapter.py` | REQ-053 | local | feeds meta-policies; `NOVA_TAG_NAMING` custom rule is the TF-static source of truth |
|
||||
| — | Wiz adapter (raw-finding source) | v1.7 / `v1.7.0` | `adapters/wiz/` | REQ-053 | local | API findings; `is_configured()` guard |
|
||||
| — | K8s Kyverno adapter (documentation-only) | v1.7 / `v1.7.0` | `adapters/kyverno/` | REQ-053, D-053 | local | inactive for Terraform-only stacks; activates when GitOps emits K8s manifests |
|
||||
|
||||
### Domain 4 — Confidence signal
|
||||
|
||||
| ID | Capability | Shipped | Files | Controlling | Tier | Notes |
|
||||
|----|-----------|---------|-------|-------------|------|-------|
|
||||
| CAP-007 | `confidence_signal.compute` returns a band | v1.1 / `v1.2.0` | `core/confidence_signal.py` | REQ-007, D-040 | local | 6 inputs (INV-2); band ∈ {pass, block} |
|
||||
| — | `escalation_reason: 'confidence'` on `band == 'block'` | v1.26 / `v1.25.3` | `core/confidence_signal.py` | REQ-318 | local | grounds Human Escalation Frequency numerator |
|
||||
|
||||
### Domain 5 — Environments & promotion
|
||||
|
||||
| ID | Capability | Shipped | Files | Controlling | Tier | Notes |
|
||||
|----|-----------|---------|-------|-------------|------|-------|
|
||||
| — | env-JSON `state_backend` wiring | v1.26 / `v1.25.3` | `core/environments/*.json`, `adapters/terraform/adapter.py` | REQ-319, D-... | local | adapter reads `env.state_backend.bucket` (fallback to computed name) |
|
||||
| — | Environment progression (dev autonomous → qa/prod/dr HITL) | v1.1 / `v1.2.0` | `core/env_transition.py`, `core/hitl_gates.py` | REQ-042, D-042 | local | destroy-on-environment-change (v1.24) |
|
||||
| — | Decommission mode (2-step, HITL SRE gates) | v1.8 / `v1.8.0` | `core/env_transition.py`, `scripts/run_platform.sh` | REQ-070, D-070 | local | `mode: decommission` requires `changeRequestId` |
|
||||
| — | Per-env mandatory metadata (W3.E) | v1.1 / `v1.2.0` | `schemas/submission-readiness.schema.json` | W3.E | local | dev=stack+env; qa+=e2e+load; prod+=runbook+dashboard+oncall; dr+=drDrillRef |
|
||||
|
||||
### Domain 6 — Evidence stream & audit
|
||||
|
||||
| ID | Capability | Shipped | Files | Controlling | Tier | Notes |
|
||||
|----|-----------|---------|-------|-------------|------|-------|
|
||||
| CAP-008 | outbox_writer builds a hash-chained item | v1.1 / `v1.2.0` | `core/outbox_writer.py` | REQ-008 | local | tamper-evident (INV-6); tamper-resistant deferred (D-083) |
|
||||
| CAP-015 | DynamoDB outbox table exists + describable | v1.1 / `v1.2.0` | `core/outbox_writer.py` | REQ-015 | live-aws | `nova-outbox` (post-v1.26 re-bootstrap) |
|
||||
| CAP-016 | S3 state bucket exists + readable | v1.1 / `v1.2.0` | `terraform/bootstrap/` | REQ-016 | live-aws | `nova-tfstate-581513795199-us-east-1` |
|
||||
| — | Decision Ledger (SQLite hash-chain) | v1.17 / `v1.17.0` | `core/metrics/decision_ledger.py` | REQ-185, REQ-186 | local | cold store for metrics; `ai.decision.made` + `attestation.recorded` events |
|
||||
| — | SSM Parameter Store deploy outputs (SecureString, KMS) | v1.7 / `v1.7.0` | `core/output_publisher.py` | REQ-050, D-050 | live-aws | `/acdl/{env}/{contractId}/{output_name}` |
|
||||
| — | GitHub PR comment / job summary deploy outputs | v1.7 / `v1.7.0` | `scripts/run_platform.sh` | REQ-050, D-050 | local | no raw secrets in logs |
|
||||
| — | Uniform error reporting via Lambda `report_error` | v1.7 / `v1.7.0` | `core/lambda/contract_ingestor.py` | REQ-055, D-055 | live-aws | GitHub issue on platform repo `acdl/acdl`; idempotent |
|
||||
| — | Tagging standard enforcement (4 required tags) | v1.7 / `v1.7.0` | `schemas/tagging-standard.json`, `adapters/terraform/policy/custom_rules/nova_tagging.py` | REQ-054, D-054 | local | `nova:owner`, `nova:contract`, `nova:environment`, `nova:cost-center` |
|
||||
| — | Encryption + deletion-protection by default | v1.8 / `v1.8.0` | `modules/l1/*/terraform/main.tf` | REQ-062, REQ-069, D-062, D-069, D-072 | local | per-stack CMK; managed KMS fallback for standalone L1 (D-072) |
|
||||
|
||||
### Domain 7 — Telemetry & metrics
|
||||
|
||||
| ID | Capability | Shipped | Files | Controlling | Tier | Notes |
|
||||
|----|-----------|---------|-------|-------------|------|-------|
|
||||
| CAP-023 | metrics collector runs + emits expected schema | v1.17 / `v1.17.0` | `core/metrics/collector.py` | REQ-194 | local | fact_run, fact_decision, fact_attestation dims |
|
||||
| CAP-024 | unified deck structure (slide count, x3 arc, per-slide benefits) | v1.17 / `v1.17.0` | `docs/presentations/nova-autonomous-cloud-delivery-marp.md` | REQ-194 | local | single source-of-truth marp deck |
|
||||
| — | Outcome backfill (`pending` → `succeeded`/`failed`) | v1.26 / `v1.25.3` | `core/metrics/outcome_backfill.py` | REQ-317 | local | idempotent + terminal; grounds AI Decision Accuracy |
|
||||
| — | Trust Snapshot | v1.17 / `v1.17.0` | `metrics/TRUST_SNAPSHOT.md`, `core/metrics/trust_snapshot.py` | REQ-194 | local | leadership-ready trust verdict |
|
||||
| — | PowerBI export (fact/dimension views + 8 placeholder views) | v1.17 / `v1.17.0` | `metrics/powerbi/` | REQ-194 | local | deferred metrics ship as documented-schema placeholders |
|
||||
| — | Pre-apply Infracost estimate | v1.17 / `v1.17.0` | `scripts/run_platform.sh` | REQ-119 | local | `nova.cost.estimated`; actual-spend CUR reconciliation deferred (D-096) |
|
||||
| — | Regression gate (`scripts/run_regression.sh`) | v1.10 / `v1.10.0` | `core/regression_verify.py`, `scripts/run_regression.sh` | REQ-090, REQ-121 | local | fails closed on any non-Verified CAP; CAP-001..025 |
|
||||
|
||||
### Domain 8 — Consumer surfaces (developer + agentic)
|
||||
|
||||
| ID | Capability | Shipped | Files | Controlling | Tier | Notes |
|
||||
|----|-----------|---------|-------|-------------|------|-------|
|
||||
| — | Reusable deploy workflow (`deploy.yml@v1.25`) | v1.5 / `v1.5.0` | `.github/workflows/deploy.yml`, `.gitea/workflows/deploy.yml` | REQ-105 | local | `workflow_call`; modes: full/plan-only/check-only/decommission |
|
||||
| — | Consumer onboarding (developer + citizen-dev paths) | v1.1 / `v1.2.0` | `docs/ONBOARDING.md`, `docs/consumer-guide.md` | BA.E, W3.E | local | both end in a sandbox dev submission that must pass the confidence gate |
|
||||
| — | Atelier MCP server (agentic validation) | v1.18 / `v1.18.0` | `mcp/atelier/server.py` | REQ-221, REQ-222 | local | `atelier.validate_against_principles` tool |
|
||||
| — | 9 production-grade engineering skills | v1.18 / `v1.18.0` | `skills/{api,security,data,testing,observability,errors,devops,infrastructure-as-code,compliance}.md` | REQ-221, REQ-222, BA.A | local | indexed by `docs/skills.md`; review/agent-checklist.md gate |
|
||||
| — | Module examples (validated against contract schema) | v1.7 / `v1.7.0` | `modules/<name>/examples/{simple,complex}.yml` | REQ-058, D-058 | local | examples cannot drift from schema silently |
|
||||
|
||||
### Domain 9 — Pilot estate (v1.26)
|
||||
|
||||
> The first real consumer estate. `nova-blockchain-exchange` repo
|
||||
> (Gitea `continuous-intelligence/nova-blockchain-exchange`, local clone
|
||||
> `/root/nova-blockchain-exchange`). Homegrown PoA blockchain, equities
|
||||
> only, single validator, T+1 settlement finality = block commit.
|
||||
|
||||
| ID | Capability | Shipped | Files | Controlling | Tier | Notes |
|
||||
|----|-----------|---------|-------|-------------|------|-------|
|
||||
| CAP-026 | PoA blockchain core (block + ledger + validator) | v1.26 / `v1.25.1` | `chain/block.py`, `chain/ledger.py`, `chain/validator.py` | REQ-310, D-201 | local | single validator; SHA-256 hash chain; deterministic block production |
|
||||
| CAP-027 | Order-matching engine (limit order book) | v1.26 / `v1.25.1` | `engine/order_book.py`, `engine/order.py` | REQ-311 | local | price-time priority; partial fills |
|
||||
| CAP-028 | T+1 settlement service | v1.26 / `v1.25.1` | `settlement/service.py` | REQ-312 | local | idempotent; finality = block commit |
|
||||
| CAP-029 | Consumer `contract.yaml` (blockchain exchange) | v1.26 / `v1.25.2` | `nova-blockchain-exchange/contract.yaml`, `contracts/*.yml` | REQ-313 | local | per-env variants (dev/qa/prod); validated against contract schema |
|
||||
| CAP-030 | Consumer deploy via `deploy.yml@v1.25` (inline adapter) | v1.26 / `v1.25.2` | `nova-blockchain-exchange/.github/workflows/deploy.yml`, `.gitea/workflows/deploy.yml` | REQ-314 | local | no cross-repo `uses:` (SPEC §10 Q1); checkout `acdl/acdl @ v1.25` into `platform/`, run `run_platform.sh` |
|
||||
| CAP-025 | Live-pilot-apply regression capability (round-trip) | v1.26 / `v1.25.3` | `core/regression_verify.py` | REQ-316 | local | contract→adapter→plan→policy→confidence→attestation→outbox round-trip assertion |
|
||||
| CAP-031 | Live pilot apply evidence (`blkex-pilot-apply-v0.2`) | v1.26 / `v1.25.4` | `.ciagent/archive/P4-PILOT-RUN-EVIDENCE-v1.26.md` | REQ-316, REQ-321 | live-aws | confidence 0.800 pass; outcome backfilled; hash chain valid; live apply against `581513795199` |
|
||||
| CAP-032 | AWS key rotation scheduled workflow | v1.26 / `v1.25.3` | `workflows-src/rotate-aws-key.yml` | SPEC §5.9 | local | daily rotation; forge-agnostic token name (REQ-230) |
|
||||
|
||||
### Domain 10 — Forge / CI runtime
|
||||
|
||||
| ID | Capability | Shipped | Files | Controlling | Tier | Notes |
|
||||
|----|-----------|---------|-------|-------------|------|-------|
|
||||
| CAP-009 | offline pytest suite passes | v1.1 / `v1.2.0` | `tests/` | REQ-009 | local | 844 tests (v1.26 baseline) |
|
||||
| CAP-010 | `run_ci.sh` reproduces CI pipeline locally | v1.4 / `v1.4.0` | `scripts/run_ci.sh` | REQ-010 | local | offline; contract→resolver→stack→adapter→structure validated |
|
||||
| CAP-011 | headline E2E — local tier (microservice) | v1.2 / `v1.3.0` | `scripts/run_local_e2e.sh` | REQ-011, D-092 | local | emulating adapters (no AWS) |
|
||||
| CAP-012 | local E2E — static-assets (no ECS) | v1.1 / `v1.2.0` | `scripts/run_local_e2e.sh` | REQ-012 | local | |
|
||||
| — | `platform-test.yml` CI workflow | v1.4 / `v1.4.0` | `.github/workflows/platform-test.yml` | REQ-010 | local | platform repo only (consumer CI is per-consumer) |
|
||||
| — | `modules-lifecycle` pipeline (apply→modify→destroy matrix) | v1.11 / `v1.11.0` | `.github/workflows/modules-lifecycle.yml` | REQ-121, D-096 | live-aws | per-module lifecycle cell; `ci-vpc-destroy` always runs |
|
||||
| — | `release.yml` (semver + floating tag maintenance) | v1.7 / `v1.7.0` | `.github/workflows/release.yml` | REQ-... | local | `v1.25` + `v1` floating tags force-moved on merge to main |
|
||||
| — | IAM policy baseline (`acdl-spike-runner-policy`) | v1.11 / `v1.11.0` | `terraform/bootstrap/spike_runner_policy.json`, `.ciagent/IAM_POLICY.md` | REQ-116, D-095 | live-aws | regression-tested by `tests/test_iam_policy_baseline.py`; OIDC role `acdl-act-runner-role` (CAP-022) |
|
||||
| — | Local emulating adapters (no AWS) | v1.10 / `v1.10.0` | `core/local_lambda_stub.py`, `scripts/run_local_e2e.sh` | D-092 | local | proves runtime behavior without live AWS |
|
||||
|
||||
## Archive pointers
|
||||
|
||||
- **v1.0–v1.24 capability narrative + the 2026-07-27 re-verification sweep:**
|
||||
`.ciagent/archive/CAPABILITY_INVENTORY-v1.10.md` (moved from
|
||||
`.ciagent/CAPABILITY_INVENTORY.md` at v1.27). CAP-NNN IDs in this file
|
||||
cross-reference the regression gate at `core/regression_verify.py`.
|
||||
- **v1.0–v1.24 milestone narrative:** `.ciagent/archive/PROJECT-v1.0-v1.24.md`.
|
||||
- **v1.0–v1.24 requirements (REQ-01..REQ-290):** `.ciagent/archive/REQUIREMENTS-v1.0-v1.24.md`.
|
||||
- **v1.0–v1.24 phase breakdowns:** `.ciagent/archive/ROADMAP-v1.0-v1.24.md`.
|
||||
- **v1.0–v1.24 architecture history:** `.ciagent/archive/ARCHITECTURE-v1.0-v1.24.md`.
|
||||
- **v1.26 pre-execution artifacts (CLARIFY, GRILL, IDEATE, RESEARCH):**
|
||||
`.ciagent/archive/{CLARIFY,GRILL,IDEATE,RESEARCH}-v1.26.md` (decisions
|
||||
D-200..D-213 folded into `PROJECT.md` load-bearing decisions + PLAN.md
|
||||
binding revisions at v1.27 archive time).
|
||||
- **v1.26 phase verifications:** `.ciagent/archive/{VERIFY-P03,VERIFY-P04,REVIEW-AUDIT-P05}.md`.
|
||||
- **v1.26 live pilot run evidence:** `.ciagent/archive/P4-PILOT-RUN-EVIDENCE-v1.26.md`.
|
||||
- **v1.21 autonomy thesis (folded into NORTH_STAR.md Vision):** `.ciagent/archive/AUTONOMY_THESIS-v1.21.md`.
|
||||
- **v1.14 AWS cost report (predates v1.26 live pilot):** `.ciagent/archive/COST-v1.14.md`.
|
||||
|
||||
## Update discipline
|
||||
|
||||
This file is updated **once per milestone, at the P-final milestone-ship
|
||||
wave** (Wave 3 "milestone ship" in `PLAN.md`), alongside
|
||||
`ROADMAP.md`/`NORTH_STAR.md`/`REQUIREMENTS.md`:
|
||||
|
||||
1. Append new capability entries for each shipped REQ (one row per
|
||||
capability; group by domain).
|
||||
2. Mark any deprecated capability with a `Deprecated` row citing the
|
||||
milestone + replacement.
|
||||
3. Bump the "Last milestone ship" header.
|
||||
4. Do not rewrite existing entries (additive only).
|
||||
|
||||
Enforcement: convention (the P-final ship step names this file). A
|
||||
drift-check gate (assert every REQ marked `complete` in
|
||||
`REQUIREMENTS.md` traceability appears in STATE.md) is a future option
|
||||
if the convention drifts.
|
||||
@@ -8,12 +8,20 @@ state for offline agent loading.
|
||||
|
||||
## Why archive
|
||||
|
||||
The active milestone is v1.26 (Live Pilot Estate Activation). The
|
||||
`.ciagent/` root held ~11,164 lines dominated by completed-milestone
|
||||
narratives (v1.0–v1.24). Per the run.md context-loading model, agents
|
||||
read `.ciagent/` every `/ci-run`; the historical narrative was not
|
||||
load-bearing for v1.26 execution and was relocated to keep the working
|
||||
context lean.
|
||||
The active milestone is v1.27 (PO State Catalog & Ciagent Compression).
|
||||
The `.ciagent/` root was compressed twice:
|
||||
|
||||
1. **v1.26 P2 compression** (~11,164 lines → ~5,232): the
|
||||
completed-milestone narratives (v1.0–v1.24) were relocated. Per the
|
||||
run.md context-loading model, agents read `.ciagent/` every
|
||||
`/ci-run`; the historical narrative was not load-bearing for v1.26
|
||||
execution and was relocated to keep the working context lean.
|
||||
2. **v1.27 P1 compression** (~5,232 → ~3,882): the v1.26 phase
|
||||
verifications + review + evidence + the dated CAPABILITY_INVENTORY
|
||||
(superseded by STATE.md) + AUTONOMY_THESIS (folded into NORTH_STAR)
|
||||
+ COST (predates v1.26 pilot) were relocated. The 4 pre-execution
|
||||
files (CLARIFY/GRILL/IDEATE/RESEARCH) were rewritten by v1.27 P0
|
||||
and stay active through v1.27.
|
||||
|
||||
## Contents
|
||||
|
||||
@@ -40,6 +48,47 @@ architecture reference.
|
||||
| `VERIFY.md` | 86 | Per-phase verification records |
|
||||
| `PRE_MORTEM.md` | 228 | Pre-mortem analyses for completed milestones |
|
||||
|
||||
### v1.27 compression — archived files (8 files, lossless `git mv`)
|
||||
|
||||
> The v1.27 NFR milestone (PO State Catalog & Ciagent Compression) archived
|
||||
> 7 platform-root files + 1 consumer file. All are byte-identical
|
||||
> relocations; git history at the pre-v1.27 commits preserves the
|
||||
> authoritative state.
|
||||
|
||||
#### Snapshots of superseded durable references (3 files)
|
||||
|
||||
| File | Original (lines) | Superseded by | Status at time of snapshot |
|
||||
|---|---|---|---|
|
||||
| `CAPABILITY_INVENTORY-v1.10.md` | 120 | `.ciagent/STATE.md` (v1.27) | The 2026-07-27 re-verification sweep (v1.1→v1.8 capabilities). Predates v1.26 pilot (CAP-025 absent; blockchain capabilities absent). |
|
||||
| `AUTONOMY_THESIS-v1.21.md` | 65 | `NORTH_STAR.md` Vision + Anti-Goals #2 | "Last refined: v1.21" — the autonomy-in-operations thesis, fully folded into NORTH_STAR.md. |
|
||||
| `COST-v1.14.md` | 106 | (future cost milestone) | AWS cost report dated 2026-07-29, framed "v1.0 → v1.14". Predates v1.26 live pilot (ECS + ALB + DynamoDB + S3 costs not reflected). |
|
||||
|
||||
#### v1.26 phase verifications + review + evidence (4 files)
|
||||
|
||||
| File | Original (lines) | Phase(s) documented |
|
||||
|---|---|---|
|
||||
| `VERIFY-P03.md` | 39 | v1.26 P3 verification — PASS (shipped `v1.25.3`) |
|
||||
| `VERIFY-P04.md` | 31 | v1.26 P4 verification — PASS (shipped `v1.25.4`) |
|
||||
| `REVIEW-AUDIT-P05.md` | 218 | v1.26 P5 final review + audit — PROCEED (shipped `v1.25.5`; 0 P0 remain; audit CLEAN) |
|
||||
| `P4-PILOT-RUN-EVIDENCE-v1.26.md` | 46 | v1.26 live apply evidence (`blkex-pilot-apply-v0.2`; confidence 0.800 pass; outcome backfilled; hash chain valid) |
|
||||
|
||||
#### Consumer subproject archive (1 file)
|
||||
|
||||
| File | Original (lines) | Phase(s) documented |
|
||||
|---|---|---|
|
||||
| `nova-blockchain-exchange/archive/ROADMAP-v1.26.md` | 57 | v1.26 consumer roadmap (P3/P4/P5 marked "planned" at archive time; v1.26 shipped `v1.25.5`). Phase narrative preserved in the platform `.ciagent/ROADMAP.md` §v1.26. |
|
||||
|
||||
#### v1.26 pre-execution artifacts (in git history, not archived to disk)
|
||||
|
||||
The v1.26 pre-execution files (CLARIFY, GRILL, IDEATE, RESEARCH) were
|
||||
overwritten by the v1.27 P0 pre-execution cycle. The v1.26-era content
|
||||
is preserved in git history at the pre-v1.27-P0 commits (search the
|
||||
log for `docs(P00):` commits on the `milestone/v1.26-pilot-activation`
|
||||
line). The v1.27 P0 versions stay active through v1.27; they archive at
|
||||
v1.28 P1 if v1.28 happens. Decisions D-200..D-213 (v1.26) are folded
|
||||
into `PROJECT.md` load-bearing decisions; D-214..D-225 (v1.27) live in
|
||||
the active `CLARIFY.md`.
|
||||
|
||||
### Live operational files NOT archived
|
||||
|
||||
These files remain at their canonical `.ciagent/` paths because they are
|
||||
|
||||
@@ -13,7 +13,7 @@
|
||||
],
|
||||
"active_project": "acdl",
|
||||
"active_projects": ["acdl", "nova-blockchain-exchange"],
|
||||
"active_milestone": "v1.26",
|
||||
"active_milestone": "v1.27",
|
||||
"autonomy": {
|
||||
"level": "full",
|
||||
"escalation_hooks": ["deploy", "delete_data", "merge_to_main"],
|
||||
|
||||
@@ -90,3 +90,8 @@ of normal operations.
|
||||
the pre-run (Workstream A3) — the platform components exist.
|
||||
- The consumer repo was created on Gitea (Workstream A4) and cloned to
|
||||
`/root/nova-blockchain-exchange`.
|
||||
- **Phase-by-phase history:** `.ciagent/ROADMAP.md` §v1.26 (the
|
||||
consumer ROADMAP is archived at
|
||||
`.ciagent/nova-blockchain-exchange/archive/ROADMAP-v1.26.md` since
|
||||
v1.27 — the platform ROADMAP is the source of truth for milestone
|
||||
phase narrative).
|
||||
@@ -5,7 +5,7 @@
|
||||
> secrets to set, what the contract looks like, and how to verify the
|
||||
> result. The platform side is documented in
|
||||
> `.ciagent/ARCHITECTURE.md` §12.8; the live-pilot evidence is in
|
||||
> `.ciagent/P4-PILOT-RUN-EVIDENCE.md`.
|
||||
> `.ciagent/archive/P4-PILOT-RUN-EVIDENCE-v1.26.md` (archived v1.27).
|
||||
|
||||
This is a **consumer** of the Nova platform, not a fork. The consumer
|
||||
repo owns the app code (the blockchain, the order-matching engine, the
|
||||
@@ -161,8 +161,8 @@ Ledger. Neither trusts the other.
|
||||
|
||||
If the AWS API shows the resources AND the Decision Ledger shows the
|
||||
decision + outcome with a valid chain, the deploy is verified. See
|
||||
`.ciagent/P4-PILOT-RUN-EVIDENCE.md` for the full pilot-evidence
|
||||
checklist (every ARN, the confidence JSON, the backfill timestamp).
|
||||
`.ciagent/archive/P4-PILOT-RUN-EVIDENCE-v1.26.md` for the full pilot-evidence
|
||||
checklist (every ARN, the confidence JSON, the backfill timestamp; archived v1.27).
|
||||
|
||||
---
|
||||
|
||||
@@ -170,8 +170,8 @@ checklist (every ARN, the confidence JSON, the backfill timestamp).
|
||||
|
||||
- `.ciagent/ARCHITECTURE.md` §12.8 — the pilot-estate architecture
|
||||
(this guide is the consumer-facing companion to that section).
|
||||
- `.ciagent/P4-PILOT-RUN-EVIDENCE.md` — the live-pilot evidence
|
||||
(run `blkex-pilot-apply-v0.2`).
|
||||
- `.ciagent/archive/P4-PILOT-RUN-EVIDENCE-v1.26.md` — the live-pilot evidence
|
||||
(run `blkex-pilot-apply-v0.2`; archived v1.27).
|
||||
- `.ciagent/nova-blockchain-exchange/PROJECT.md` — the consumer
|
||||
project charter (vision, scope, decisions D-200..D-205).
|
||||
- `.ciagent/nova-blockchain-exchange/REQUIREMENTS.md` — the consumer
|
||||
|
||||
Reference in New Issue
Block a user