acdl/.ciagent/PERSONAS.md

project, milestone, generated_at, generator, verification_toolchain

project	milestone	generated_at	generator	verification_toolchain
acdl	v1.18	2026-08-06	lead-developer	typecheck test build note python3 -m py_compile core/submission_readiness.py mcp/atelier/server.py && python3 -m jsonschema schemas/submission-readiness.schema.json pytest tests/test_submission_readiness.py tests/test_atelier_mcp.py # REQ-220 + REQ-225 bash scripts/render_deck.sh docs/presentations/nova-no-humans-platform-marp.md # HTML + PPTX (D-142) v1.18 adds the Citizen Developer & Production-Grade Guidance surface: submission-readiness gate, Atelier-derived skills, the Atelier MCP server (plugin-registry, stdio), and PPTX-as-first-class-artifact deck automation. Three active personas: lead-developer (coordination + decks + RACI/scope docs), backend-engineer (MCP server + submission-readiness validator + render/attach scripts), data-engineer (submission-readiness schema if it touches contract storage / DynamoDB shape). frontend-engineer stays deactivated (v1.18 has no frontend; decks are markdown = lead-developer territory). The MCP plugin-registry is a backend pattern, so a separate mcp-engineer persona is NOT added — it folds into backend-engineer.

ACDL — Persona Roster (v1.18 Citizen Developer & Production-Grade Guidance)

v1.18 roster. Three active personas + one deactivated. The MCP server plugin-registry (D-140) is a backend pattern, not a new persona — it folds into backend-engineer. v1.17 precedent (frontend-engineer deactivated, decks are markdown = lead-developer territory) is upheld.

Active personas

lead-developer

• Domain: coordination
• Active: true
• Phase-specific: false
• Frameworks: [] (no framework — owns process + narrative, not code)
• Constraints: ["pragmatic", "battle-tested defaults", "no fabrication (NORTH_STAR honesty model)"]
• Territory:
  • docs/presentations/** (Step 1/2/4 markdown + the deck automation trigger)
  • .ciagent/** (PROJECT, ROADMAP, REQUIREMENTS, RESEARCH, PLAN, GRILL, PERSONAS, REVIEW, CHECKPOINT)
  • PROJECT.md (RACI matrix + PDLC-scope statement, REQ-215/216)
  • ROADMAP.md
  • REQUIREMENTS.md
  • docs/raci.md (REQ-215)
  • docs/scope.md (REQ-216)
  • docs/skills.md (REQ-222 — the index page, not the skill files themselves)
  • docs/submission-readiness.md (REQ-219 — citizen-developer-facing copy; co-owned with backend-engineer for the reason-code catalog)
• Reason: Owns CIAgent metadata, the milestone narrative, the RACI + PDLC-scope statements (REQ-215/216), the deck (21 slides, S&P theme regression check vs P1, CAP-024), the skills index page (REQ-222), and the citizen-developer-facing submission-readiness doc (REQ-219). Is the only persona that touches .ciagent/** and the deck markdown.
• Phase-specific flag: none (active for all of P0–P7).

backend-engineer

• Domain: backend
• Active: true
• Phase-specific: false
• Frameworks: ["mcp (Python SDK v2)", "pydantic", "jsonschema", "urllib"]
• Constraints: ["api-first", "strict-typing", "plugin-registry extensible (D-140)", "stdio now / HTTP-ready (D-135)", "no stack traces to citizen developers (REQ-218)"]
• Territory:
  • mcp/atelier/server.py (REQ-223)
  • mcp/atelier/plugins/**/*.py (REQ-223 — principles.py, validation.py)
  • mcp/atelier/vendor/** (REQ-224 — vendored Atelier snapshot)
  • mcp/atelier/VERSION.md + mcp/atelier/README.md (REQ-224)
  • scripts/update_atelier_vendor.sh (REQ-224)
  • core/submission_readiness.py (REQ-218 — the validator, invoked as contract_ingestor.py --check-readiness)
  • scripts/render_deck.sh (REQ-228 — HTML + PPTX render)
  • scripts/attach_release_asset.py (REQ-228 — Gitea release asset upload)
  • tests/test_atelier_mcp.py (REQ-225)
  • tests/test_submission_readiness.py (REQ-220)
  • docs/submission-readiness.md (REQ-219 — reason-code catalog section; co-owned with lead-developer for the narrative)
• Reason: Owns the MCP server (plugin-registry, stdio, vendored Atelier), the submission-readiness validator (extends contract_ingestor.py --check-readiness, D-133), the render/attach scripts (D-142 trigger), and the two new test files. The MCP plugin-registry (D-140) is a backend pattern — no separate mcp-engineer persona is created; backend-engineer owns it.
• Phase-specific flag: none (active for P1 deck-render, P3 validator, P5 MCP server, P6 scripts).

data-engineer

• Domain: data
• Active: true
• Phase-specific: false
• Frameworks: ["jsonschema", "dynamodb (item shape)"]
• Constraints: ["schema-first", "superset-gate NOT duplicate (PROJECT.md hard constraint)", "W3.E per-env mandatory table is the source of truth"]
• Territory:
  • schemas/** (REQ-217 — submission-readiness.schema.json is the new schema; existing schemas untouched)
  • core/lambda/contract_ingestor.py (the --check-readiness subcommand wiring, D-133 — the validator is in core/submission_readiness.py but the ingestor dispatches to it; co-owned with backend-engineer)
• Reason: Owns the submission-readiness JSON Schema (REQ-217) — it is a schema artifact, data-engineer territory. The schema is a superset gate above contract.schema.json, not a duplicate (it references contract fields, does not redefine them). The per-env-mandatory table comes from W3.E (the locked decision). The ingestor wiring is co-owned with backend-engineer (the dispatch point is backend; the schema it validates against is data).
• Phase-specific flag: none (active for P3 schema + ingestor wiring).

Deactivated personas

frontend-engineer

• Active: false
• Domain: frontend
• Frameworks: ["react", "next.js"] (inert — no territory)
• Constraints: ["component-first", "server-components", "minimal-client-js"] (inert)
• Territory: [] (no territory in v1.18)
• Reason: v1.18 has no frontend; decks are markdown (lead-developer territory); deactivated per PERSONAS.md v1.17 precedent. v1.18's observability stays PowerBI / external (Out of Scope: "A Nova-built frontend / dashboard"). The MCP server exposes tools to an AI agent, not a web UI. No reactivation trigger in this milestone.

Roster decisions

D-143 (0.90): Fold mcp-engineer into backend-engineer

The MCP plugin-registry (D-140: plugins/<name>.py register(mcp)) is a backend code pattern — Python modules, type hints, stdio transport, urllib for the Gitea asset API. It shares nothing with the data domain (schemas/DynamoDB) and is not a new engineering discipline. Creating a separate mcp-engineer persona would fragment ownership of the server + its tests + the render/attach scripts (all backend). Decision: fold into backend-engineer. backend-engineer's frameworks list gains mcp (Python SDK v2). Confidence 0.90 — the only counter-argument is that MCP is a distinct protocol skill, but the SDK v2 API surface (@mcp.tool() + type hints) is small and well within backend-engineer's range (it's the same Pydantic/FastAPI-style pattern the persona already knows).

Territory-overlap resolution (co-ownership)

Path	Primary	Co-owner	Why
docs/submission-readiness.md	lead-developer (narrative + examples)	backend-engineer (reason-code catalog, REQ-218 codes)	The doc is citizen-developer-facing copy (lead) but the reason-code catalog (MISSING_TAGS, ENV_MISSING_MANDATORY, AGENTIC_MISSING_INTENT, MISSING_APP_SOURCE, POLICY_PRECONDITION_MISSING) is backend (it mirrors the validator's return codes).
core/lambda/contract_ingestor.py	backend-engineer (dispatch wiring)	data-engineer (the schema it validates against)	D-133 places the --check-readiness subcommand on the ingestor (backend dispatch), but the readiness schema it loads is data-engineer territory.
schemas/submission-readiness.schema.json	data-engineer (schema artifact)	backend-engineer (the validator must match it)	The schema is data-engineer's; the validator (REQ-218) is backend-engineer's and must stay in sync with it.