dxcomplete 0.1.0

package/templates/next/pages/api/dxcomplete/[...path].js

@@ -0,0 +1,12 @@
+import workspaceConfig from "../../../dxcomplete/workspace.json";
+import handleDxcompleteRequest, { configureDxcompleteWorkspace } from "dxcomplete/http";
+
+configureDxcompleteWorkspace(workspaceConfig);
+
+export const config = {
+  api: {
+    bodyParser: false
+  }
+};
+
+export default handleDxcompleteRequest;

package/templates/next/pages/api/dxcomplete.js

@@ -0,0 +1,12 @@
+import workspaceConfig from "../../dxcomplete/workspace.json";
+import handleDxcompleteRequest, { configureDxcompleteWorkspace } from "dxcomplete/http";
+
+configureDxcompleteWorkspace(workspaceConfig);
+
+export const config = {
+  api: {
+    bodyParser: false
+  }
+};
+
+export default handleDxcompleteRequest;

package/templates/next/pages/api/mcp.js

@@ -0,0 +1,12 @@
+import workspaceConfig from "../../dxcomplete/workspace.json";
+import handleDxcompleteRequest, { configureDxcompleteWorkspace } from "dxcomplete/http";
+
+configureDxcompleteWorkspace(workspaceConfig);
+
+export const config = {
+  api: {
+    bodyParser: false
+  }
+};
+
+export default handleDxcompleteRequest;

package/templates/next/vercel.json

@@ -0,0 +1,18 @@
+{
+  "$schema": "https://openapi.vercel.sh/vercel.json",
+  "functions": {
+    "pages/api/**/*.js": {
+      "includeFiles": "dxcomplete/workspace.json"
+    }
+  },
+  "rewrites": [
+    {
+      "source": "/.well-known/oauth-authorization-server",
+      "destination": "/api/dxcomplete/.well-known/oauth-authorization-server"
+    },
+    {
+      "source": "/.well-known/oauth-protected-resource/api/mcp",
+      "destination": "/api/dxcomplete/.well-known/oauth-protected-resource/api/mcp"
+    }
+  ]
+}

package/templates/process/README.md

@@ -0,0 +1,38 @@
+# DX Complete Process Scaffold
+
+This directory is an editable draft scaffold for a DX Complete model.
+
+The current model is not final. Update these files as the decision-basis, engineering, service, roles, workflows, object taxonomy, and controls become clearer.
+
+The current scope commitment is that a Workspace contains one service scope. Statements, journal entries, decisions, requirements, work, cost, benefit, support, operations, and measurement records should be understood inside that workspace unless a project explicitly decides otherwise. The default runtime shape is one hosted MCP endpoint for that installed workspace, with workspace identity coming from DX Complete config and access constrained by authenticated actor identity plus workspace authorization.
+
+## Files
+
+- `decision-basis.yml` stores draft decision-basis templates and Commitment-or-Deferral framing.
+- `cost-model.yml` stores draft current-state cost context, estimate, and actuals concepts.
+- `roles.yml` stores draft role responsibilities.
+- `taxonomy.yml` stores draft lifecycle objects and relationships.
+- `workflows.yml` stores draft workflow templates.
+- `controls.yml` stores placeholder controls and evidence expectations.
+- `diagrams/` stores editable Mermaid diagrams.
+- `evidence/` stores captured evidence or pointers to evidence.
+- `decisions/` stores decision records.
+- `risks/` stores risk notes and linked controls.
+
+## Editing Guidance
+
+Prefer explicit draft language until a decision is made. When a decision is made, capture the decision record and update the relevant YAML, Markdown, and Mermaid files together.
+
+## Suggested First Pass
+
+1. Confirm which roles exist in the current team.
+2. Capture statement and restate expectations.
+3. Add shared Journal notes only for relevant context that does not belong in a dedicated record.
+4. Elicit requirements, dependencies, constraints, and unknowns from expectations.
+5. Attempt current-state cost context, even if the result is unavailable or limited-disclosure.
+6. Generate an itemized cost Estimate and capture Benefits from the elicited requirement set.
+7. Decide whether the decision basis is sufficient for Commitment, or whether Deferral conditions should stay visible.
+8. Keep `Requirement` as the main engineering lifecycle object unless the model proves otherwise.
+9. Remove objects that are too heavy for the current context.
+10. Add evidence expectations only where they are useful.
+11. Review open questions before turning placeholders into policy.

package/templates/process/controls.yml

@@ -0,0 +1,113 @@
+schema: dxcomplete.controls.v0
+status: draft
+notes:
+  - Controls are placeholders.
+  - Do not treat these as compliance requirements without a project-specific decision.
+
+controls:
+  - id: cost_visibility
+    name: Cost visibility
+    draft_purpose: Ensure the workspace elicits enough detail, attempts current-state cost visibility, generates a cost Estimate where cost reasoning is needed, and records Benefits where benefit reasoning is needed.
+    applies_to:
+      - Workspace
+      - Estimate
+      - Benefits
+    draft_evidence:
+      - Elicited needs, dependencies, constraints, and unknowns.
+      - Current-state cost context, including unavailable or undisclosed data notes where applicable.
+      - Estimate with assumptions and cost roll-up.
+      - Benefits with quantified or qualitative benefit items.
+      - Weigh outcome, linked inputs, and remaining concerns.
+    open_questions:
+      - What is enough cost visibility to commit when baseline data is unavailable?
+
+  - id: requirement_acceptance_criteria
+    name: Requirement acceptance criteria
+    draft_purpose: Ensure each requirement has enough clarity for engineering work, QA verification, and product validation.
+    applies_to:
+      - Requirement
+    draft_evidence:
+      - Requirement record with acceptance criteria.
+      - Owner or delegated approval.
+      - Review notes where Engineer input should remain visible.
+    open_questions:
+      - What is the minimum acceptance criteria format?
+
+  - id: implementation_review
+    name: Implementation review
+    draft_purpose: Ensure engineering output is reviewed before QA verification.
+    applies_to:
+      - Task
+      - Change
+    draft_evidence:
+      - Pull request, commit, or task review notes.
+      - Engineer approval or review outcome.
+    open_questions:
+      - Can Codex-generated changes be accepted by automated checks alone?
+
+  - id: qa_verification_evidence
+    name: QA verification evidence
+    draft_purpose: Preserve verification results against requirements and acceptance criteria.
+    applies_to:
+      - Requirement
+      - Task
+      - Change
+    draft_evidence:
+      - Test plan or verification notes.
+      - Pass, fail, or retest outcome.
+      - Defects or follow-up tasks where needed.
+    open_questions:
+      - Which changes require formal QA evidence?
+
+  - id: product_validation
+    name: Product validation
+    draft_purpose: Confirm the verified output is the right product outcome.
+    applies_to:
+      - Requirement
+      - Release
+    draft_evidence:
+      - Product validation note.
+      - Owner approval or user input where required.
+    open_questions:
+      - Is product validation required before every release?
+
+  - id: release_readiness
+    name: Release readiness
+    draft_purpose: Confirm change scope, risk, rollback, notice, veto, emergency posture, and required evidence before release.
+    applies_to:
+      - Change
+      - Release
+    draft_evidence:
+      - Change record with baseline plan sections.
+      - Append-only Change events for notice, veto, emergency, decision, result, recovery, notes, or revisions where applicable.
+      - Release checklist.
+      - Linked QA and product validation evidence.
+      - Rollback or mitigation notes.
+    open_questions:
+      - Who owns release approval?
+
+  - id: deployment_record
+    name: Deployment record
+    draft_purpose: Preserve when, where, and how a release was deployed.
+    applies_to:
+      - Deployment
+    draft_evidence:
+      - Deployment identifier or URL.
+      - Environment.
+      - Timestamp.
+      - Operator or automation identity.
+    open_questions:
+      - Which deployment evidence is automatically available?
+
+  - id: incident_response_record
+    name: Incident response record
+    draft_purpose: Preserve response details for service-impacting events.
+    applies_to:
+      - Incident
+    draft_evidence:
+      - Timeline.
+      - Impact.
+      - Actions taken.
+      - Resolution and follow-up links.
+    open_questions:
+      - Which support tickets should be promoted to incidents?

package/templates/process/cost-model.yml

@@ -0,0 +1,71 @@
+schema: dxcomplete.cost_model.v0
+status: draft
+notes:
+  - Use broad cost language at the top level.
+  - OPEX/CAPEX-like categories can exist inside the cost model, but should not be the top-level frame.
+  - Current-state context, Estimate, Benefits, and post-launch observations are distinct concepts.
+
+cost_visibility_rules:
+  visibility_required: true
+  complete_data_required: false
+  current_state_context_attempt_required: true
+  estimate_required_by_default: true
+  actuals_required_when_available: true
+  missing_actuals_block_closure: false
+
+cost_data_availability:
+  - known
+  - estimated
+  - partial
+  - unavailable
+  - undisclosed
+  - not_applicable
+
+cost_objects:
+  estimate:
+    purpose: Itemized cost information for the scope being weighed.
+    generated_by_default: true
+    draft_fields:
+      - line_items
+      - covered_requirements
+      - covered_expectations
+      - rollup_by_currency_timing_and_period
+      - assumptions
+      - confidence
+      - notes
+    rules:
+      - Estimate line items are cost items.
+      - One-time and recurring totals should remain separate.
+      - Recurring totals should remain separated by period.
+      - Edits should preserve prior versions.
+
+  benefits:
+    purpose: Expected benefit information for the scope being weighed.
+    draft_fields:
+      - benefit_items
+      - covered_requirements
+      - covered_expectations
+      - quantified_rollup_by_currency_timing_and_period
+      - assumptions
+      - confidence
+      - notes
+    rules:
+      - Benefit items may be quantified or qualitative.
+      - Qualitative benefit items are complete without amount, timing, period, or currency.
+      - Quantified one-time and recurring totals should remain separate.
+      - Quantified recurring totals should remain separated by period.
+      - Edits should preserve prior versions.
+
+example_cost_categories:
+  - build_labor
+  - codex_assisted_implementation
+  - qa_and_validation
+  - infrastructure
+  - licenses_and_tools
+  - migration
+  - training_and_adoption
+  - support_load
+  - operational_run_cost
+  - maintenance
+  - risk_mitigation
+  - decommissioning_or_replacement

package/templates/process/decision-basis.yml

@@ -0,0 +1,53 @@
+schema: dxcomplete.decision_basis.v0
+status: draft
+notes:
+  - Decision basis is first-class, but it is assembled from deliberate records rather than a standalone extra record.
+  - Use Estimate for cost, Benefits for expected value, and Decision entries for rationale where a separate decision trail is useful.
+  - Cost visibility is mandatory, but complete cost data is not mandatory.
+
+decision_basis_rules:
+  cost_visibility_required: true
+  complete_cost_data_required: false
+  current_state_context_attempt_required: true
+  estimate_generated_by_default: true
+  actuals_block_closure: false
+  supports_workspace_modes:
+    - transformation
+    - greenfield
+    - limited-disclosure
+
+draft_decision_basis:
+  id: null
+  workspace_id: null
+  status: draft
+  problem_to_be_solved: null
+  goal: null
+  workspace_mode: null
+  estimate_id: null
+  benefits_id: null
+  decision_id: null
+  decision_basis_summary: null
+  weigh_outcome: null # commitment | deferral
+  decision_rationale:
+    decision_entries: []
+    argument_entries: []
+    note_entries: []
+  elicited_needs: []
+  downstream_requirement_ids: []
+  measurement_plan:
+    intended_observations: []
+    notes: null
+  assumptions: []
+  unavailable_data: []
+  limited_disclosure_notes: []
+
+draft_statuses:
+  - draft
+  - awaiting_current_state_context
+  - awaiting_estimate
+  - awaiting_benefits
+  - ready_for_decision
+  - commitment_recorded
+  - deferral_recorded
+  - measuring_actuals
+  - closed

package/templates/process/decisions/.gitkeep

@@ -0,0 +1 @@
+

package/templates/process/diagrams/00-decision-basis.mmd

@@ -0,0 +1,24 @@
+%% DX Complete draft diagram. Decision basis is upstream of Complete Engineering.
+flowchart LR
+  Workspace[Workspace] --> Statement[Capture User Statement]
+  Statement --> Expectation[Restate Expected Result]
+  Expectation --> Elicit[Elicit requirements, dependencies, and unknowns]
+  Elicit --> CurrentCostContext[Current Cost Context]
+  CurrentCostContext --> Estimate[Itemized Estimate]
+  Elicit --> Benefits[Benefits]
+  Estimate --> DecisionBasis[Decision Basis]
+  Benefits --> DecisionBasis
+  CurrentCostContext --> DecisionBasis
+  DecisionBasis --> Weigh{Weigh}
+  Weigh -. informed_by .-> DecisionBasis
+  Weigh -. informed_by .-> Estimate
+  Weigh -. informed_by .-> Benefits
+  Weigh -->|Commit| Commitment[Commitment]
+  Weigh -->|Defer| Deferral[Deferral]
+  Deferral -->|Conditions resolved| Commitment
+  Commitment --> Build[Build]
+  Build --> GoLive[Go Live]
+  GoLive --> Operate[Operate]
+  Operate --> Observations[Post-launch Observations]
+  Observations --> EstimateLearning[Estimate Refinement]
+  EstimateLearning -. informs .-> Estimate

package/templates/process/diagrams/00-overview.mmd

@@ -0,0 +1,20 @@
+%% DX Complete draft diagram. Revise as the model evolves.
+flowchart LR
+  Workspace[Workspace] --> Orient[Orient]
+  Workspace --> Journal[Journal]
+  Orient --> Statement[Statement]
+  Statement --> Expectation[Expectation]
+  Expectation --> Elicit[Elicit]
+  Elicit --> Estimate[Itemized Estimate]
+  Elicit --> Benefits[Benefits]
+  Estimate --> Weigh
+  Benefits --> Weigh
+  Elicit --> Weigh{Weigh}
+  Weigh -->|Commit| Commitment[Commitment]
+  Weigh -->|Defer| Deferral[Deferral]
+  Deferral -->|Conditions resolved| Commitment
+  Commitment --> Build[Build]
+  Build --> GoLive[Go Live]
+  GoLive --> Operate[Operate]
+  Operate --> Measure[Measure]
+  Measure --> FutureContext[Future estimate context]

package/templates/process/diagrams/01-intake-triage.mmd

@@ -0,0 +1,20 @@
+%% Draft intake and triage workflow.
+flowchart TD
+  Signal[Incoming signal] --> Source{Likely source?}
+  Source -->|Client or user| SupportSignal[Support Ticket draft]
+  Source -->|Product idea| Feedback[Feedback draft]
+  Source -->|Authority or commitment| AuthoritySignal[Authoritative Request draft]
+  Source -->|Service health| Incident[Incident draft]
+  SupportSignal --> Triage[Triage]
+  Feedback --> Triage
+  AuthoritySignal --> Triage
+  Incident --> Triage
+  Triage --> OwnerRoute[Route to Owner]
+  Triage --> OpsRoute[Route to Operator]
+  Triage --> DecisionRoute[Route for authority decision]
+  ProductRoute --> RequirementCandidate[Requirement candidate]
+  OpsRoute --> IncidentOrProblem[Incident or Problem candidate]
+  DecisionRoute --> Decision[Decision or priority]
+  RequirementCandidate --> OpenQuestions[Capture open questions]
+  IncidentOrProblem --> OpenQuestions
+  Decision --> OpenQuestions

package/templates/process/diagrams/02-product-definition.mmd

@@ -0,0 +1,14 @@
+%% Draft product definition workflow.
+flowchart TD
+  SourceObject[Feedback / Feature Request / Authoritative Request / Problem] --> Clarify[Clarify desired outcome]
+  Clarify --> Statement[Capture User Statement]
+  Statement --> Expectation[Restate Expected Result]
+  Expectation --> Requirement[Draft Requirement]
+  Requirement --> Acceptance[Draft acceptance criteria]
+  Acceptance --> Constraints[Identify constraints and risks]
+  Constraints --> Review{Ready for engineering review?}
+  Review -->|No| OpenQuestions[Record open questions]
+  OpenQuestions --> Clarify
+  Review -->|Yes| EngineerReview[Engineer review]
+  EngineerReview --> Decision[Record decision if needed]
+  Decision --> RequirementReady[Requirement ready for execution]

package/templates/process/diagrams/03-engineering-execution.mmd

@@ -0,0 +1,15 @@
+%% Draft engineering execution workflow.
+flowchart TD
+  Requirement[Committed Requirement] --> RequirementDetail[Refine requirement detail]
+  RequirementDetail --> Approach[Engineer decides implementation approach]
+  Approach --> Tasks[Decompose into Tasks]
+  Tasks --> Eligibility{Codex assistance useful?}
+  Eligibility -->|Yes| CodexTask[Engineer task with Codex assistance]
+  Eligibility -->|No| ManualTask[Engineer task]
+  CodexTask --> EngineerReview[Engineer review]
+  ManualTask --> EngineerReview
+  EngineerReview --> Complete{Ready for QA verification?}
+  Complete -->|No| Rework[Rework or clarify]
+  Rework --> Tasks
+  Complete -->|Yes| ReadyForCheck[Ready for verification]
+  ReadyForCheck --> QAHandoff[QA handoff]

package/templates/process/diagrams/04-qa-verification.mmd

@@ -0,0 +1,12 @@
+%% Draft QA verification workflow.
+flowchart TD
+  QAHandoff[QA handoff] --> ReviewInputs[Review requirement, tasks, and acceptance criteria]
+  ReviewInputs --> Plan[Plan verification]
+  Plan --> Execute[Execute checks]
+  Execute --> Result{Verification result}
+  Result -->|Pass| Evidence[Record QA evidence]
+  Result -->|Fail| Defect[Record defect or follow-up task]
+  Result -->|Unclear| Clarification[Request clarification]
+  Defect --> Engineer[Return to Engineer]
+  Clarification --> OwnerOrEngineer[Owner or Engineer clarification]
+  Evidence --> ProductValidation[Product validation]

package/templates/process/diagrams/05-product-validation.mmd

@@ -0,0 +1,12 @@
+%% Draft product validation workflow.
+flowchart TD
+  QAEvidence[QA evidence] --> ProductReview[Owner reviews outcome]
+  ProductReview --> Outcome{Right outcome?}
+  Outcome -->|Yes| ValidationEvidence[Record validation evidence]
+  Outcome -->|No| FollowUpRequirement[Create or revise Requirement]
+  Outcome -->|Needs end user input| ClientReview[End User review]
+  ClientReview --> ClientOutcome{Accepted?}
+  ClientOutcome -->|Yes| ValidationEvidence
+  ClientOutcome -->|No| FollowUpRequirement
+  ValidationEvidence --> ReleaseCandidate[Release candidate]
+  FollowUpRequirement --> ProductDefinition[Product definition]

package/templates/process/diagrams/06-change-release-control.mmd

@@ -0,0 +1,16 @@
+%% Draft change and release control workflow.
+flowchart TD
+  Change[Create Change record] --> Plan[Record change plan]
+  Plan --> Execution[Record execution steps]
+  Execution --> Rollback[Record rollback plan]
+  Rollback --> RiskImpact[Record risk and impact]
+  RiskImpact --> Notice[Append notice event]
+  Notice --> Veto{Veto recorded?}
+  Veto -->|Yes| VetoEvent[Append veto event]
+  Veto -->|No| Decision[Append decision event]
+  VetoEvent --> Decision
+  Decision --> Emergency{Emergency path?}
+  Emergency -->|Yes| EmergencyEvent[Append importance and immediacy]
+  Emergency -->|No| Release[Prepare release or deployment]
+  EmergencyEvent --> Release
+  Release --> Result[Append result or recovery event]

package/templates/process/diagrams/07-deployment-operations.mmd

@@ -0,0 +1,16 @@
+%% Draft deployment and operations workflow.
+flowchart TD
+  DeploymentPrep[Deployment preparation] --> Deploy[Deploy release]
+  Deploy --> Record[Record Deployment evidence]
+  Record --> Registry[Update Environment and Component records if inventory changed]
+  Registry --> Monitor[Monitor service health]
+  Monitor --> Healthy{Healthy?}
+  Healthy -->|Yes| Operate[Operate service]
+  Healthy -->|No| Incident[Create or update Incident]
+  Incident --> Response[Incident response]
+  Response --> Rollback{Rollback needed?}
+  Rollback -->|Yes| RollbackAction[Rollback or mitigation]
+  Rollback -->|No| ContinueMonitor[Continue monitoring]
+  RollbackAction --> Record
+  ContinueMonitor --> Monitor
+  Operate --> SupportSignals[Route user-facing signals to Support Agent]

package/templates/process/diagrams/08-support-incident-management.mmd

@@ -0,0 +1,16 @@
+%% Draft support and incident management workflow.
+flowchart TD
+  UserSignal[End User signal] --> Ticket[Support Ticket]
+  Ticket --> Classify{Classify}
+  Classify -->|Question or request| SupportResponse[Support Agent response]
+  Classify -->|Outcome signal| Feedback[Feedback]
+  Classify -->|Service impact| Incident[Incident]
+  Classify -->|Recurring issue| ProblemCandidate[Problem candidate]
+  Incident --> Operator[Operator response]
+  Operator --> UserComms[Support Agent communicates status]
+  Feedback --> Owner[Owner triage]
+  ProblemCandidate --> ProblemReview[Problem review]
+  SupportResponse --> CloseTicket[Close or update ticket]
+  UserComms --> CloseTicket
+  Owner --> CloseTicket
+  ProblemReview --> CloseTicket

package/templates/process/diagrams/09-problem-improvement.mmd

@@ -0,0 +1,14 @@
+%% Draft problem and improvement workflow.
+flowchart TD
+  Signal[Incident / Support Ticket / QA defect / Operator finding] --> Problem[Problem draft]
+  Problem --> Investigate[Investigate likely cause]
+  Investigate --> CauseKnown{Cause known?}
+  CauseKnown -->|No| MoreEvidence[Collect more evidence]
+  MoreEvidence --> Investigate
+  CauseKnown -->|Yes| Improvement{Improvement needed?}
+  Improvement -->|Requirement| Requirement[Create Requirement]
+  Improvement -->|Service change| Change[Create Change]
+  Improvement -->|No action| Decision[Record decision]
+  Requirement --> ProductDefinition[Product definition]
+  Change --> ChangeControl[Change and release control]
+  Decision --> Review[Schedule review if needed]

package/templates/process/diagrams/10-risk-control-management.mmd

@@ -0,0 +1,14 @@
+%% Draft risk and control management workflow.
+flowchart TD
+  RiskSignal[Risk signal] --> Risk[Risk draft]
+  Risk --> Assess[Assess likelihood, impact, and owner]
+  Assess --> Treatment{Treatment}
+  Treatment -->|Accept| Decision[Record acceptance decision]
+  Decision -. informed_by .-> Risk
+  Treatment -->|Mitigate| Control[Define Control]
+  Treatment -->|Avoid or defer| Requirement[Create or revise Requirement]
+  Control --> EvidenceNeed[Define evidence need]
+  EvidenceNeed --> LinkedObjects[Link Requirement / Release / Deployment]
+  LinkedObjects --> Review[Review control evidence]
+  Requirement --> ProductDefinition[Product definition]
+  Decision --> Review

package/templates/process/diagrams/11-audit-evidence-capture.mmd

@@ -0,0 +1,13 @@
+%% Draft audit and evidence capture workflow.
+flowchart TD
+  LifecycleObject[Requirement / Task / Change / Release / Deployment / Incident / Control] --> EvidenceNeed{Evidence needed?}
+  EvidenceNeed -->|No| Note[Record no evidence required decision if useful]
+  EvidenceNeed -->|Yes| Capture[Capture or link evidence]
+  Capture --> ResponsiblePerson[Record responsible person and timestamp]
+  ResponsiblePerson --> Review[Review completeness]
+  Review --> Complete{Complete?}
+  Complete -->|Yes| Preserve[Preserve evidence]
+  Complete -->|No| Gap[Record evidence gap]
+  Gap --> FollowUp[Assign follow-up]
+  Note --> Preserve
+  Preserve --> AuditTrail[Audit trail]

package/templates/process/evidence/.gitkeep

@@ -0,0 +1 @@
+

package/templates/process/risks/.gitkeep

@@ -0,0 +1 @@
+

package/templates/process/roles.yml

@@ -0,0 +1,96 @@
+schema: dxcomplete.roles.v0
+status: editable
+notes:
+  - This role model is a working operating model.
+  - One person may hold more than one role, especially in a small team.
+  - Director and Product Lead are folded into Owner. Coder is folded into Engineer. Admin is folded into Operator.
+  - Revise ownership and escalation paths before treating them as policy.
+
+roles:
+  - id: owner
+    name: Owner
+    draft_responsibility: Sets authority, priority, outcome direction, requirements, product validation direction, budget commitment, escalation direction, and formal risk acceptance.
+    likely_owns:
+      - authority
+      - priority
+      - outcomes
+      - requirements
+      - acceptance criteria
+      - product validation direction
+      - budget commitment
+      - formal risk acceptance
+      - escalation
+      - strategic direction
+    folded_responsibilities:
+      - Director authority and escalation
+      - Product Lead outcome definition and validation
+    open_questions:
+      - Which Owner approvals should be explicit checkpoints?
+      - Which requests require Owner review before becoming requirements?
+
+  - id: engineer
+    name: Engineer
+    draft_responsibility: Turns committed requirements into tasks and working changes, either directly or by driving coding-capable tools.
+    likely_owns:
+      - solution approach
+      - task decomposition
+      - implementation
+      - implementation review
+      - technical decisions
+      - Codex-assisted task direction
+    folded_responsibilities:
+      - Coder task implementation
+    open_questions:
+      - Which tasks are eligible for Codex-assisted coding?
+      - What implementation evidence is required before testing?
+
+  - id: tester
+    name: Tester
+    draft_responsibility: Checks completed work against requirements and success criteria.
+    likely_owns:
+      - verification plans
+      - test evidence
+      - defect signals
+      - release quality input
+    open_questions:
+      - Which changes require formal verification evidence?
+
+  - id: operator
+    name: Operator
+    draft_responsibility: Releases, deploys, monitors, and runs the service, including provisioning, administration, users, permissions, settings, and run-side security.
+    likely_owns:
+      - release execution
+      - deployment
+      - monitoring
+      - service health
+      - operational incidents
+      - provisioning
+      - user administration
+      - permission configuration
+      - run-side security
+    folded_responsibilities:
+      - Admin user and permission management
+    open_questions:
+      - Which administration or run-side security changes require change control?
+
+  - id: support_agent
+    name: Support Agent
+    draft_responsibility: Helps users, captures signals, and routes questions, feedback, and issues to the right follow-up.
+    likely_owns:
+      - user issue communication
+      - support tickets
+      - feedback capture
+      - issue routing
+    open_questions:
+      - When does a support ticket become an incident, problem, or requirement?
+
+  - id: end_user
+    name: End User
+    draft_responsibility: Uses the service and provides requests, feedback, corrections, and issue reports.
+    likely_owns:
+      - service use
+      - feedback
+      - issue reports
+      - corrections
+    open_questions:
+      - Which End User signals should become feedback, requirements, incidents, problems, or risks?