continuous-intelligence/acdl
3
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 128 Wiki Activity
Files
139224ff6c5ede0b7c79092d8207b06751c8c432
acdl/.ciagent/PERSONAS.md
T
Jon Chery ad0e0378da docs(P56a): research findings for v1.11 RESTART 
RESEARCH stage. Verified the technical assumptions behind the 13-phase
v1.11 restart plan against the live codebase (branched off v1.10.2).

Findings:
- Adapter monolith audit: adapters/terraform/adapter.py is 918 lines
  with 3 constant tables (TYPE_MAP/INPUT_MAP/OUTPUT_MAP) that duplicate
  what interface.json already declares, plus 39 type-specific branches
  across 18 stack types carrying nested HCL blocks + hardcoded defaults
  (CIDR, assume_role_policy JSON, ECR/logs inline policy, Fargate
  requires_compatibilities, assign_public_ip, listener/target ports,
  security group emission). STANDARDS.md §8 blessed this drift as the
  intended design — the standards doc itself must be rewritten (P56a).
- State-key root cause of the 4-VPC bug: adapter.py:664,676 emits
  spike/{stack_name}/terraform.tfstate where stack_name = contract.id;
  all 5 microservice contracts share id 'msvc' but differ in
  environment (dev/qa/prod/dr); the state key does NOT include the
  environment, so all 4 env contracts collide on spike/msvc/terraform.tfstate.
  Combined with verify_deploy_microservice.py running terraform init
  -reconfigure in a fresh temp dir each time, each run created a fresh
  VPC. Two root causes: (1) per-contract state keys with no VPC sharing,
  (2) non-deterministic state keys across environments. D-105 + D-106 +
  D-101 correct all three.
- Per-module terraform module design: documented the
  versions/variables/locals/main/outputs.tf layout for s3, vpc, ecs-service
  and how the stateless adapter assembles them via registry.json →
  terraform_dir → module-instantiation blocks + ref wiring.
- Existing pipeline architecture: run_platform.sh line 287 runs terraform
  plan only (never apply/destroy); the --apply/--destroy lifecycle modes
  must be ADDED (P57). Byte-identical Gitea+GitHub convention documented.

PERSONAS.md updated for v1.11:
- Deactivated lambda-engineer, platform-engineer, security-engineer,
  frontend-engineer (no per-module Python this milestone).
- Reactivated data-engineer (owns terraform/ + per-module terraform
  subdirs — the heaviest v1.11 work).
- Kept backend-engineer (adapter/resolver), general (pipelines/workflows).
- Territory enforcement: warn (co-authoring expected on adapter +
  run_platform.sh boundary).
- Domain priority: data → backend → general.

6 assumptions logged (A-1.1..A-5.1), all >= 0.6 confidence, none
escalated.

---ci---
project: acdl
phase: 0
milestone: v1.11
status: research
---/ci---
2026-07-28 16:07:57 +00:00

12 KiB
Raw Blame History

project, milestone, generated_at, generator, verification_toolchain
project milestone generated_at generator verification_toolchain
acdl v1.11 2026-07-28 lead-developer
typecheck test build note
terraform validate && python3 -m py_compile core/**/*.py && python3 -m jsonschema schemas/*.schema.json bash scripts/run_primitive_plan.sh --check-only <primitive> # pipeline-driven (D-102); no per-module pytest terraform init && terraform plan ACDL has no package.json. The execute/verify/ship workflows substitute `terraform validate` + `python -m py_compile` + JSON Schema validation for npm run typecheck, a per-phase verify script (or the modules-lifecycle pipeline cell) for npm test, and `terraform init` + `terraform plan` for npm run build. v1.11 testing is pipeline-driven (D-102): the modules-lifecycle pipeline matrix-runs each L1 module's examples/{simple,complex}.yml contracts through apply→modify→destroy against live AWS. No per-module Python/pytest. This override is documented here as the single source of truth; the ci-* agents read PERSONAS.md before running verification commands.

ACDL — Persona Roster (project-level, v1.11 RESTART)

v1.11 is a restart (D-097). The v1.9 roster is superseded. Three structural corrections: (1) stateless adapter (D-098), (2) terraform owns lifecycle (D-101), (3) pipeline-driven testing (D-102). The roster is simplified to the three active domains: data (terraform foundation), backend (adapter/resolver), general (pipelines/workflows).

Active personas

lead-developer

  • Domain: coordination
  • Active: true
  • Phase-specific: false
  • Reason: Owns CIAgent metadata, cross-phase verification scripts, the v1.11 phase orchestration (D-107: P56a + P56b split), and arbitrates persona conflicts. Resolves the milestone decomposition and the STANDARDS.md §8 rewrite (the adapter extension pattern is replaced by the per-module terraform subdir pattern).

backend-engineer

  • Domain: backend
  • Active: true
  • Phase-specific: false
  • Reason: Owns the adapter rewrite (D-098: stateless assembler — deletes TYPE_MAP/INPUT_MAP/OUTPUT_MAP + 39 type-specific branches, becomes a ~80-line assembler that emits module "x" { source = "..." ... } blocks) and the contract resolver env-aware state keys (D-106: spike/{id}/{env}/terraform.tfstate). The adapter holds no module content; the engine binding lives in the per-module terraform/ subdir. Co-authoring expected on the adapter + run_platform.sh boundary (general adds --apply/--destroy modes that invoke the adapter).
  • Territory: adapters/terraform/adapter.py (rewrite to stateless assembler), core/contract_resolver.py (env-aware state keys, deterministic composition), schemas/stack.schema.json (if the stack instance shape changes), tests/test_adapter*.py (regression baseline — the s3 instance.json round-trip must still pass).

data-engineer

  • Domain: data
  • Active: true
  • Phase-specific: false
  • Reason: Reactivated for v1.11. Owns the heaviest territory: the per-module terraform/ subdirs (D-098/D-099/D-100 — the engine binding) for all 12 L1 modules, plus the single platform VPC (D-105: terraform/platform owns ONE VPC; the microservice composition drops its vpc child and references the platform VPC via data source). Each L1 module ships a real terraform module dir (versions/variables/locals/main/outputs.tf) owning its resource shape, nested blocks, and defaults. locals.tf is used heavily to centralize default interpolation (D-099). Multi-resource modules get the full 5-file split; trivial single-resource modules may inline locals in main.tf. This is the binding constraint — the stateless adapter cannot be written until the reference s3 module exists (D-107: P56a proves the design with s3 first).
  • Territory: terraform/ (platform VPC, D-105), modules/l1/*/terraform/ (per-module terraform subdirs — the engine binding), modules/l1/*/interface.json (defaults move from adapter to interface inputs), modules/registry.json (terraform_dir field), modules/l2/microservice/composition.json (drop the vpc child, D-105), modules/STANDARDS.md §8 (rewrite the adapter extension pattern → per-module terraform subdir pattern).

general (lead-developer + backend-engineer pipeline work)

  • Domain: coordination + pipelines
  • Active: true
  • Phase-specific: false
  • Reason: Owns the pipeline-driven testing (D-102/D-103/D-104) and the terraform lifecycle modes (D-101). The modules-lifecycle pipeline (Gitea + GitHub, byte-identical) matrix-runs each L1 module's examples/{simple,complex}.yml contracts through apply→modify→destroy against live AWS. run_platform.sh gains --apply and --destroy modes; Python never runs terraform. verify_deploy_microservice.py is deleted (D-101). Co-authoring expected on the run_platform.sh boundary (backend-engineer rewrites the adapter that run_platform.sh invokes).
  • Territory: pipelines/modules-lifecycle.yml, .gitea/workflows/modules-lifecycle.yml + .github/workflows/modules-lifecycle.yml (byte-identical, D-102), scripts/run_platform.sh (--apply/--destroy modes, D-101), scripts/run_primitive_plan.sh (if extended for lifecycle), scripts/run_pattern_plan.sh (if extended), pipelines/README.md (document the new pipeline), schemas/deploy-pipeline.schema.json (if the lifecycle stages are added to the contract).

Deactivated personas

lambda-engineer (custom, v1.9 — deactivated for v1.11)

  • Domain: serverless
  • Active: false
  • Phase-specific: false
  • Reason: No per-module Python this milestone (D-102: testing is pipeline-driven, not pytest). The v1.9 Lambda (core/lambda/contract_ingestor.py) and the terraform/platform/main.tf Lambda/DynamoDB/KMS/Secrets definitions persist from v1.9 but are not touched in v1.11. The acdl-sod-halt SNS topic and the attestation matrix are out of scope. Removed from the roster for v1.11; reactivates if a future milestone touches the Lambda.

platform-engineer (custom, v1.9 — folded into data-engineer for v1.11)

  • Domain: infra
  • Active: false
  • Phase-specific: false
  • Reason: The v1.11 scope (D-097..D-107) is terraform module authoring + adapter rewrite + pipelines — not the v1.9-era L1/L2 IR-typed module authoring or the AWS OIDC bootstrap. The platform-engineer's v1.9 territory (adapters/terraform/**, modules/**, terraform/**) is split: the adapter goes to backend-engineer (rewrite), the per-module terraform subdirs + platform VPC go to data-engineer (the heaviest v1.11 work). Folded into data-engineer for v1.11; reactivates if a future milestone does IR-shaped module authoring or OIDC bootstrap work.

security-engineer (custom, v1.9 — deactivated for v1.11)

  • Domain: security
  • Active: false
  • Phase-specific: false
  • Reason: The v1.11 scope does not touch Wiz/Kyverno/Checkov adapters, the HITL matrix, separation-of-duties, or the audit ledger. The security-engineer's v1.9 territory persists but is not touched. Removed from the roster for v1.11; reactivates if a future milestone touches security adapters or HITL gates.

frontend-engineer

  • Domain: frontend
  • Active: false
  • Phase-specific: false
  • Reason: The evidence timeline UI (evidence-ui/**) is unchanged from v1.0 and not touched in v1.11. Removed from the active roster; reactivates if a future milestone touches the timeline UI.

data-engineer (v1.9 — was deactivated, reactivated for v1.11)

  • Domain: data
  • Active: true (reactivated)
  • Phase-specific: false
  • Reason: See the active data-engineer entry above. The v1.9 deactivation rationale ("No ORM/persistence framework") no longer applies — v1.11's data-engineer owns terraform module authoring, not a data persistence layer.

infra-stub-engineer (custom, v1.0 only)

  • Domain: backend
  • Active: false
  • Reason: Owned L1 stub modules in the v1.0 demo. The demo is archived to demo/; real L1 modules are owned by data-engineer (v1.11). Not reactivated.

Phase-specific overrides

Phase Personas active Notes
56a adapter-rewrite-and-s3-reference-module data-engineer (lead: s3 reference terraform module — proves the design), backend-engineer (lead: stateless adapter rewrite — emits module blocks for s3), general (run_platform.sh --apply/--destroy skeleton) security/lambda/frontend idle
56b remaining-11-l1-module-terraform-subdirs data-engineer (lead: author 11 L1 module terraform subdirs — vpc, ecs-cluster, ecs-service, iam-role, alb, ecr, cloudfront, waf, rds, kms-key, uptime), backend-engineer (adapter: confirm each module round-trips through the assembler), general (modules-lifecycle pipeline wiring) security/lambda/frontend idle
(modules-lifecycle pipeline) general (lead: byte-identical Gitea+GitHub workflow + matrix apply→modify→destroy), data-engineer (examples/{simple,complex}.yml contracts as the modify variants), backend-engineer (adapter confirms the lifecycle cells resolve) security/lambda/frontend idle
(platform VPC + composition drop) data-engineer (lead: terraform/platform VPC + microservice composition drops vpc child, D-105), backend-engineer (resolver: env-aware state keys, D-106) general/security/lambda/frontend idle
verify lead-developer (lead: 4-layer verification), all active personas (review their territory) —
review-audit-complete lead-developer (lead: review + audit + milestone completion), all active personas (review participation) —

Domain priority (used by TaskDecomposer)

data → backend → general

Rationale: in v1.11, the terraform foundation (per-module terraform/ subdirs + platform VPC) is the binding constraint — the stateless adapter cannot be written until the reference s3 module exists (D-107: P56a proves the design with s3 first). Backend (adapter/resolver) follows once the module shape is proven. General (pipelines/workflows) wires the lifecycle modes last, once the adapter + modules produce valid terraform.

Conflict resolutions (lead-developer arbitration)

  • backend-engineer vs data-engineer over modules/l1/*/interface.json: data-engineer owns the interface defaults (defaults move from the adapter to the interface inputs, D-100); backend-engineer owns the adapter that reads them. Co-authoring is expected; conflict goes to lead-developer.
  • backend-engineer vs general over scripts/run_platform.sh: backend-engineer rewrites the adapter that run_platform.sh invokes; general adds the --apply/--destroy modes. The interface (the CLI flags + the adapter invocation) is co-authored; conflicts go to lead-developer.
  • data-engineer vs general over modules/l1/*/examples/: data-engineer owns the example contracts (the modify variants, D-103); general owns the pipeline that matrix-runs them. Co-authoring is expected; conflicts go to lead-developer.
  • lead-developer vs any: lead-developer owns .ciagent/** + docs/** meta + verification scripts + modules/STANDARDS.md §8 rewrite; persona engineers do not edit CIAgent metadata or the vision/architecture source docs.

Territory enforcement mode

warn — config.json has no personas.territory_enforcement field, so the default per execute.md is warn. Cross-territory edits are logged in the commit message but do not fail the task. v1.11's scope means co-authoring across territories is likely (e.g. backend + general on the adapter + run_platform.sh boundary; data + general on the examples + pipeline boundary); warn keeps it frictionless.

Reference in New Issue View Git Blame Copy Permalink