dxcomplete 0.2.2 → 0.3.0

package/templates/process/controls.yml

@@ -1,18 +1,18 @@
 schema: dxcomplete.controls.v0
-status: draft
+status: current
 notes:
-  - Controls are placeholders.
-  - Do not treat these as compliance requirements without a project-specific decision.
+  - Controls are editable workspace process expectations.
+  - Do not treat these as compliance requirements without a workspace-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.
+    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:
+    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.
@@ -23,10 +23,10 @@ controls:
 
   - id: requirement_acceptance_criteria
     name: Requirement acceptance criteria
-    draft_purpose: Ensure each requirement has enough clarity for engineering work, QA verification, and product validation.
+    purpose: Ensure each requirement has enough clarity for engineering work, QA verification, and product validation.
     applies_to:
       - Requirement
-    draft_evidence:
+    evidence:
       - Requirement record with acceptance criteria.
       - Owner or delegated approval.
       - Review notes where Engineer input should remain visible.
@@ -35,11 +35,11 @@ controls:
 
   - id: implementation_review
     name: Implementation review
-    draft_purpose: Ensure engineering output is reviewed before QA verification.
+    purpose: Ensure engineering output is reviewed before QA verification.
     applies_to:
       - Task
       - Change
-    draft_evidence:
+    evidence:
       - Pull request, commit, or task review notes.
       - Engineer approval or review outcome.
     open_questions:
@@ -47,12 +47,12 @@ controls:
 
   - id: qa_verification_evidence
     name: QA verification evidence
-    draft_purpose: Preserve verification results against requirements and acceptance criteria.
+    purpose: Preserve verification results against requirements and acceptance criteria.
     applies_to:
       - Requirement
       - Task
       - Change
-    draft_evidence:
+    evidence:
       - Test plan or verification notes.
       - Pass, fail, or retest outcome.
       - Defects or follow-up tasks where needed.
@@ -61,11 +61,11 @@ controls:
 
   - id: product_validation
     name: Product validation
-    draft_purpose: Confirm the verified output is the right product outcome.
+    purpose: Confirm the verified output is the right product outcome.
     applies_to:
       - Requirement
       - Release
-    draft_evidence:
+    evidence:
       - Product validation note.
       - Owner approval or user input where required.
     open_questions:
@@ -73,11 +73,11 @@ controls:
 
   - id: release_readiness
     name: Release readiness
-    draft_purpose: Confirm change type, scope, risk, rollback, notice, veto, and required evidence before release.
+    purpose: Confirm change type, scope, risk, rollback, notice, veto, and required evidence before release.
     applies_to:
       - Change
       - Release
-    draft_evidence:
+    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.
@@ -88,10 +88,10 @@ controls:
 
   - id: deployment_record
     name: Deployment record
-    draft_purpose: Preserve when, where, and how a release was deployed.
+    purpose: Preserve when, where, and how a release was deployed.
     applies_to:
       - Deployment
-    draft_evidence:
+    evidence:
       - Deployment identifier or URL.
       - Environment.
       - Timestamp.
@@ -101,14 +101,14 @@ controls:
 
   - id: service_impact_response_evidence
     name: Service-impact response evidence
-    draft_purpose: Preserve response details for service-impacting events through Incident entries.
+    purpose: Preserve response details for service-impacting events through Incident entries.
     applies_to:
       - DX Complete Ticket
       - Risk
       - Task
       - Change
       - Decision
-    draft_evidence:
+    evidence:
       - Timeline.
       - Impact.
       - Actions taken.

package/templates/process/cost-model.yml

@@ -1,5 +1,5 @@
 schema: dxcomplete.cost_model.v0
-status: draft
+status: current
 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.
@@ -25,7 +25,7 @@ cost_objects:
   estimate:
     purpose: Itemized cost information for the scope being weighed.
     generated_by_default: true
-    draft_fields:
+    fields:
       - line_items
       - covered_requirements
       - covered_expectations
@@ -41,7 +41,7 @@ cost_objects:
 
   benefits:
     purpose: Expected benefit information for the scope being weighed.
-    draft_fields:
+    fields:
       - benefit_items
       - covered_requirements
       - covered_expectations

package/templates/process/decision-basis.yml

@@ -1,5 +1,5 @@
 schema: dxcomplete.decision_basis.v0
-status: draft
+status: current
 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.
@@ -16,10 +16,10 @@ decision_basis_rules:
     - greenfield
     - limited-disclosure
 
-draft_decision_basis:
+decision_basis:
   id: null
   workspace_id: null
-  status: draft
+  status: current
   problem_to_be_solved: null
   goal: null
   workspace_mode: null
@@ -41,7 +41,7 @@ draft_decision_basis:
   unavailable_data: []
   limited_disclosure_notes: []
 
-draft_statuses:
+statuses:
   - draft
   - awaiting_current_state_context
   - awaiting_estimate

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

@@ -1,4 +1,4 @@
-%% DX Complete draft diagram. Decision basis is upstream of Complete Engineering.
+%% DX Complete diagram. Decision basis is upstream of Complete Engineering.
 flowchart LR
   Workspace[Workspace] --> Statement[Capture User Statement]
   Statement --> Expectation[Restate Expected Result]

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

@@ -1,4 +1,4 @@
-%% DX Complete draft diagram. Revise as the model evolves.
+%% DX Complete diagram. Revise when the workspace process changes.
 flowchart LR
   Workspace[Workspace] --> Orient[Orient]
   Workspace --> Journal[Journal]

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

@@ -1,9 +1,9 @@
-%% Draft intake and triage workflow.
+%% DX Complete intake and triage workflow.
 flowchart TD
   Signal[Incoming signal] --> Source{Likely source?}
-  Source -->|Client or user| SupportSignal[Support Request draft]
-  Source -->|Product idea| Feedback[Feedback draft]
-  Source -->|Authority or commitment| AuthoritySignal[Authoritative Request draft]
+  Source -->|Client or user| SupportSignal[Support Request candidate]
+  Source -->|Product idea| Feedback[Feedback candidate]
+  Source -->|Authority or commitment| AuthoritySignal[Authoritative Request candidate]
   Source -->|Service health| ServiceImpact[Service-impact signal]
   SupportSignal --> Triage[Triage]
   Feedback --> Triage

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

@@ -1,10 +1,10 @@
-%% Draft product definition workflow.
+%% DX Complete product definition workflow.
 flowchart TD
   SourceObject[Feedback / Feature Request / Authoritative Request / Recurring issue] --> Clarify[Clarify desired outcome]
   Clarify --> Statement[Capture User Statement]
   Statement --> Expectation[Restate Expected Result]
-  Expectation --> Requirement[Draft Requirement]
-  Requirement --> Acceptance[Draft acceptance criteria]
+  Expectation --> Requirement[Requirement]
+  Requirement --> Acceptance[Acceptance criteria]
   Acceptance --> Constraints[Identify constraints and risks]
   Constraints --> Review{Ready for engineering review?}
   Review -->|No| OpenQuestions[Record open questions]

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

@@ -1,4 +1,4 @@
-%% Draft engineering execution workflow.
+%% DX Complete engineering execution workflow.
 flowchart TD
   Requirement[Committed Requirement] --> RequirementDetail[Refine requirement detail]
   RequirementDetail --> Approach[Engineer decides implementation approach]

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

@@ -1,4 +1,4 @@
-%% Draft QA verification workflow.
+%% DX Complete QA verification workflow.
 flowchart TD
   QAHandoff[QA handoff] --> ReviewInputs[Review requirement, tasks, and acceptance criteria]
   ReviewInputs --> Plan[Plan verification]

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

@@ -1,4 +1,4 @@
-%% Draft product validation workflow.
+%% DX Complete product validation workflow.
 flowchart TD
   QAEvidence[QA evidence] --> ProductReview[Owner reviews outcome]
   ProductReview --> Outcome{Right outcome?}

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

@@ -1,4 +1,4 @@
-%% Draft change and release control workflow.
+%% DX Complete change and release control workflow.
 flowchart TD
   Change[Create Change record] --> Type[Classify standard, normal, or emergency]
   Type --> Plan[Record change plan]

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

@@ -1,4 +1,4 @@
-%% Draft deployment and operations workflow.
+%% DX Complete deployment and operations workflow.
 flowchart TD
   DeploymentPrep[Deployment preparation] --> Deploy[Deploy release]
   Deploy --> Record[Record Deployment evidence]

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

@@ -1,4 +1,4 @@
-%% Draft support and incident management workflow.
+%% DX Complete support and incident management workflow.
 flowchart TD
   UserSignal[End User signal] --> Ticket[Support Request]
   Ticket --> Classify{Classify}

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

@@ -1,4 +1,4 @@
-%% Draft problem and improvement workflow.
+%% DX Complete problem and improvement workflow.
 flowchart TD
   Signal[Incident / ticket / repeated service signal] --> Problem[Create Problem]
   Problem --> Investigate[Append investigation entry]

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

@@ -1,4 +1,4 @@
-%% Draft risk and control management workflow.
+%% DX Complete risk and control management workflow.
 flowchart TD
   RiskSignal[Risk signal] --> Risk[Create Risk ledger]
   Risk --> Identify[Append identified entry]

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

@@ -1,4 +1,4 @@
-%% Draft audit and evidence capture workflow.
+%% DX Complete audit and evidence capture workflow.
 flowchart TD
   LifecycleObject[Requirement / Task / Change / Incident / Problem / Decision / Risk / Control] --> EvidenceNeed{Evidence needed?}
   EvidenceNeed -->|No| Note[Record no evidence required decision if useful]

package/templates/process/roles.yml

@@ -9,7 +9,7 @@ notes:
 roles:
   - id: owner
     name: Owner
-    draft_responsibility: Sets authority, priority, outcome direction, requirements, product validation direction, budget commitment, escalation direction, and formal risk acceptance.
+    responsibility: Sets authority, priority, outcome direction, requirements, product validation direction, budget commitment, escalation direction, and formal risk acceptance.
     likely_owns:
       - authority
       - priority
@@ -30,7 +30,7 @@ roles:
 
   - id: engineer
     name: Engineer
-    draft_responsibility: Turns committed requirements into tasks and working changes, either directly or by driving coding-capable tools.
+    responsibility: Turns committed requirements into tasks and working changes, either directly or by driving coding-capable tools.
     likely_owns:
       - solution approach
       - task decomposition
@@ -46,7 +46,7 @@ roles:
 
   - id: tester
     name: Tester
-    draft_responsibility: Checks completed work against requirements and success criteria.
+    responsibility: Checks completed work against requirements and success criteria.
     likely_owns:
       - verification plans
       - test evidence
@@ -57,7 +57,7 @@ roles:
 
   - id: operator
     name: Operator
-    draft_responsibility: Releases, deploys, monitors, and runs the service, including provisioning, administration, users, permissions, settings, and run-side security.
+    responsibility: Releases, deploys, monitors, and runs the service, including provisioning, administration, users, permissions, settings, and run-side security.
     likely_owns:
       - release execution
       - deployment
@@ -75,7 +75,7 @@ roles:
 
   - id: support_agent
     name: Support Agent
-    draft_responsibility: Helps users, captures signals, and routes questions, feedback, and issues to the right follow-up.
+    responsibility: Helps users, captures signals, and routes questions, feedback, and issues to the right follow-up.
     likely_owns:
       - user issue communication
       - support tickets
@@ -86,7 +86,7 @@ roles:
 
   - id: end_user
     name: End User
-    draft_responsibility: Uses the service and provides requests, feedback, corrections, and issue reports.
+    responsibility: Uses the service and provides requests, feedback, corrections, and issue reports.
     likely_owns:
       - service use
       - feedback

package/templates/process/taxonomy.yml

@@ -1,10 +1,10 @@
 schema: dxcomplete.taxonomy.v0
-status: draft
+status: current
 notes:
-  - This taxonomy is a working hypothesis.
-  - Object names, boundaries, and relationships should be edited as the model is discovered.
+  - This taxonomy is editable workspace process data.
+  - Object names, boundaries, and relationships should be updated when the workspace process changes.
 
-current_lifecycle_hypothesis:
+current_lifecycle_model:
   runtime_scope_object: Workspace
   private_ticket_object: DX Complete Ticket
   current_runtime_record_objects:
@@ -57,8 +57,8 @@ current_lifecycle_hypothesis:
 objects:
   - id: workspace
     name: Workspace
-    draft_definition: The shared-runtime container for one service scope.
-    draft_fields:
+    definition: The shared-runtime container for one service scope.
+    fields:
       - name
       - summary
       - mode
@@ -73,8 +73,8 @@ objects:
 
   - id: dxcomplete_ticket
     name: DX Complete Ticket
-    draft_definition: An actor-scoped, appendable item used to raise a question, report, request, correction, or follow-up with DX Complete.
-    draft_fields:
+    definition: An actor-scoped, appendable item used to raise a question, report, request, correction, or follow-up with DX Complete.
+    fields:
       - title
       - body
       - entries
@@ -98,8 +98,8 @@ objects:
 
   - id: journal
     name: Journal
-    draft_definition: Shared workspace notes for relevant context that does not have a better dedicated record home.
-    draft_fields:
+    definition: Shared workspace notes for relevant context that does not have a better dedicated record home.
+    fields:
       - body
       - kind
       - tag
@@ -126,8 +126,8 @@ objects:
 
   - id: environment
     name: Environment
-    draft_definition: A named operating context such as local, staging, or production.
-    draft_fields:
+    definition: A named operating context such as local, staging, or production.
+    fields:
       - name
       - summary
       - description
@@ -143,8 +143,8 @@ objects:
 
   - id: component
     name: Component
-    draft_definition: One operational item that belongs to exactly one Environment.
-    draft_fields:
+    definition: One operational item that belongs to exactly one Environment.
+    fields:
       - name
       - environment
       - kind
@@ -168,8 +168,8 @@ objects:
 
   - id: maintenance_schedule
     name: Maintenance Schedule
-    draft_definition: A recurring operational hygiene record with cadence, start date, rationale, and derived due state.
-    draft_fields:
+    definition: A recurring operational hygiene record with cadence, start date, rationale, and derived due state.
+    fields:
       - name
       - kind
       - cadence
@@ -188,7 +188,7 @@ objects:
 
   - id: estimate
     name: Estimate
-    draft_definition: An itemized cost record used during Weigh, linked to the requirements or expectations it covers.
+    definition: An itemized cost record used during Weigh, linked to the requirements or expectations it covers.
     rules:
       - Estimate line items are cost items.
       - Amounts may be single values or min/expected/max ranges.
@@ -203,7 +203,7 @@ objects:
 
   - id: benefits
     name: Benefits
-    draft_definition: An Owner-authored benefit record used during Weigh, linked to the requirements or expectations it covers.
+    definition: An Owner-authored benefit record used during Weigh, linked to the requirements or expectations it covers.
     rules:
       - Benefit items may be quantified or qualitative.
       - Qualitative benefit items are complete without amount, timing, period, or currency.
@@ -219,7 +219,7 @@ objects:
 
   - id: value_realization
     name: Value Realization
-    draft_definition: A measured before-and-after value record for expectations, requirements, or commitments.
+    definition: A measured before-and-after value record for expectations, requirements, or commitments.
     rules:
       - Value Realization metrics have a baseline, unit, direction, and optional actual value.
       - Metrics without actual values remain open.
@@ -234,7 +234,7 @@ objects:
   - id: feedback
     name: Feedback
     status: lifecycle_concept
-    draft_definition: A signal from a client, user, interested party, or service observation.
+    definition: A signal from a client, user, interested party, or service observation.
     likely_sources:
       - End User
       - Support Agent
@@ -248,7 +248,7 @@ objects:
   - id: authoritative_request
     name: Authoritative Request
     status: lifecycle_concept
-    draft_definition: A request or directive with authority behind it, such as Owner commitment, leadership decision, legal need, or contractual obligation.
+    definition: A request or directive with authority behind it, such as Owner commitment, leadership decision, legal need, or contractual obligation.
     likely_sources:
       - Owner
     possible_links:
@@ -259,7 +259,7 @@ objects:
   - id: feature_request
     name: Feature Request
     status: lifecycle_concept
-    draft_definition: A desired capability or product change that may become one or more requirements.
+    definition: A desired capability or product change that may become one or more requirements.
     likely_sources:
       - Feedback
       - Owner
@@ -270,7 +270,7 @@ objects:
 
   - id: statement
     name: Statement
-    draft_definition: The user's own words before DX Complete interprets or translates them.
+    definition: The user's own words before DX Complete interprets or translates them.
     status: runtime_record
     runtime_collection: statements
     notes:
@@ -284,7 +284,7 @@ objects:
 
   - id: expectation
     name: Expectation
-    draft_definition: User-facing condition of satisfaction, including the result expected and how success will be recognized.
+    definition: User-facing condition of satisfaction, including the result expected and how success will be recognized.
     status: runtime_record
     runtime_collection: expectations
     notes:
@@ -302,14 +302,14 @@ objects:
 
   - id: requirement
     name: Requirement
-    draft_definition: A team-owned commitment that translates expectations into something buildable and verifiable. In the current model, requirements are shaped during elicitation, weighed by the Owner, and refined during Build once covered by a Commitment.
+    definition: A team-owned commitment that translates expectations into something buildable and verifiable. In the current model, requirements are shaped during elicitation, weighed by the Owner, and refined during Build once covered by a Commitment.
     likely_sources:
       - Owner
       - Expectation
       - Authoritative Request
       - Feature Request
       - Problem
-    draft_fields:
+    fields:
       - statement
       - acceptance_criteria
       - requirement_detail
@@ -329,12 +329,12 @@ objects:
 
   - id: commitment
     name: Commitment
-    draft_definition: An Owner point-in-time authority record that commits requirements or expectations into Build.
+    definition: An Owner point-in-time authority record that commits requirements or expectations into Build.
     likely_sources:
       - Owner
       - Requirement
       - Expectation
-    draft_fields:
+    fields:
       - commitment_statement
       - reservations
     possible_links:
@@ -350,12 +350,12 @@ objects:
 
   - id: deferral
     name: Deferral
-    draft_definition: An Owner record for not committing yet, with explicit conditions that make a future Commitment possible.
+    definition: An Owner record for not committing yet, with explicit conditions that make a future Commitment possible.
     likely_sources:
       - Owner
       - Requirement
       - Expectation
-    draft_fields:
+    fields:
       - reason
       - status
       - conditions
@@ -374,8 +374,8 @@ objects:
 
   - id: task
     name: Task
-    draft_definition: An execution unit with append-only entries, used to make part of a requirement true.
-    draft_fields:
+    definition: An execution unit with append-only entries, used to make part of a requirement true.
+    fields:
       - description
       - assignee
       - assignor
@@ -394,13 +394,13 @@ objects:
 
   - id: change
     name: Change
-    draft_definition: A discrete alteration to the running service, recorded for service-management control and accountability.
+    definition: A discrete alteration to the running service, recorded for service-management control and accountability.
     likely_sources:
       - Task
       - Engineer
       - Operator
       - Incident
-    draft_fields:
+    fields:
       - change_type
       - change_plan
       - execution_steps
@@ -433,8 +433,8 @@ objects:
   - id: incident
     name: Incident
     status: current_runtime_record
-    draft_definition: A specific service-impacting or potentially service-impacting occurrence requiring response.
-    draft_fields:
+    definition: A specific service-impacting or potentially service-impacting occurrence requiring response.
+    fields:
       - description
       - entries
       - current_status
@@ -458,8 +458,8 @@ objects:
   - id: problem
     name: Problem
     status: current_runtime_record
-    draft_definition: An underlying or recurring cause evidenced by one or more incidents.
-    draft_fields:
+    definition: An underlying or recurring cause evidenced by one or more incidents.
+    fields:
       - description
       - entries
       - current_status
@@ -481,8 +481,8 @@ objects:
   - id: support_request
     name: Support Request
     status: current_runtime_record
-    draft_definition: A shared support ledger for a user-facing reported experience, question, request, or issue.
-    draft_fields:
+    definition: A shared support ledger for a user-facing reported experience, question, request, or issue.
+    fields:
       - reporter
       - kind
       - reported_experience
@@ -503,7 +503,7 @@ objects:
   - id: release
     name: Release
     status: lifecycle_concept
-    draft_definition: A grouped set of changes prepared for delivery.
+    definition: A grouped set of changes prepared for delivery.
     likely_sources:
       - Change
       - Operator
@@ -516,7 +516,7 @@ objects:
   - id: deployment
     name: Deployment
     status: lifecycle_concept
-    draft_definition: The act and evidence of putting a release or change into an environment.
+    definition: The act and evidence of putting a release or change into an environment.
     likely_sources:
       - Release
       - Operator
@@ -527,8 +527,8 @@ objects:
 
   - id: decision
     name: Decision
-    draft_definition: A revisitable choice record with ordered entries and links to the records that informed it.
-    draft_fields:
+    definition: A revisitable choice record with ordered entries and links to the records that informed it.
+    fields:
       - matter
       - entries
       - current_decision
@@ -556,7 +556,7 @@ objects:
 
   - id: risk
     name: Risk
-    draft_definition: An uncertainty or exposure that could affect product, service, delivery, compliance, or operations.
+    definition: An uncertainty or exposure that could affect product, service, delivery, compliance, or operations.
     rules:
       - Open checkpoints should be represented as visible risk rather than blockers.
       - Open risk should remain visible when work proceeds without approval.
@@ -576,7 +576,7 @@ objects:
   - id: control
     name: Control
     status: lifecycle_concept
-    draft_definition: A policy, check, approval, or evidence requirement used to manage risk or governance.
+    definition: A policy, check, approval, or evidence requirement used to manage risk or governance.
     likely_sources:
       - Owner
       - Operator