dxcomplete 0.2.1 → 0.3.0

package/docs/model.md

@@ -1,44 +1,36 @@
-# Draft Model
+# DX Complete Model
 
-## Working Hypothesis
+## Current Model
 
 The model is a full DX lifecycle, not merely a software development workflow.
 
-The broader product premise is:
+It includes cost and benefit reasoning before engineering begins, both build/change roles and run/service roles, and actual measurement after delivery where available.
 
-```text
-DX Complete = Decision Basis + Complete Engineering + Operations Measurement
-```
-
-It should include cost and benefit reasoning before engineering begins, both build/change roles and run/service roles, and actual measurement after delivery where available.
+The current runtime scope decision is `Workspace`: the hosted-record container for one service scope. The default MCP deployment model is one endpoint per workspace. Each installed project repo carries its workspace identity in editable DX Complete config and exposes one MCP route for that workspace.
 
-The current runtime scope decision is `Workspace`: the shared-runtime container for one service scope. The default MCP deployment model is one endpoint per workspace. Each installed project repo carries its workspace identity in editable DX Complete config and exposes one hosted MCP route for that workspace.
-
-Workspace MCP deployments are not database runtimes. They proxy auth and MCP requests to the central DX Complete service. The central service owns database access, Google OAuth exchange, workspace membership, readable-ID allocation, and MCP tool execution. Separate database deployment may be revisited later, but workspace servers should not hold database credentials in the current model.
+Workspace MCP deployments are not database runtimes and do not install the hosted DX Complete service. They proxy auth and MCP requests to that service. The hosted service owns database access, OAuth exchange, workspace membership, readable-ID allocation, and MCP tool execution. Separate database deployment may be revisited later, but workspace servers should not hold database credentials in the current model.
 
 Workspace carries the service identity through its name, summary, and mode when useful. A separate service charter record is not part of the current model; if a presentation summary is needed, it should be derived from the workspace and current expectations.
 
-The current decision-basis hypothesis is that `Statement`, `Expectation`, `Requirement`, `Estimate`, `Benefits`, and `Decision` sit upstream of Build inside the Workspace. Statements, expectations, dependencies, constraints, unknowns, and requirements should be elicited before useful estimates are generated. Current-state cost context should be attempted where relevant, an itemized cost `Estimate` should be generated by default from the elicited requirement set where cost reasoning is needed, expected `Benefits` should be recorded where possible, and Weigh should bridge into Build through a Commitment or keep the path visible through a Deferral. A Decision can preserve ordered rationale entries and records that informed the Owner's judgment.
+The current decision-basis model is that `Statement`, `Expectation`, `Requirement`, `Estimate`, `Benefits`, and `Decision` sit upstream of Build inside the Workspace. Statements, expectations, dependencies, constraints, unknowns, and requirements should be elicited before useful estimates are generated. Current-state cost context should be attempted where relevant, an itemized cost `Estimate` should be generated by default from the elicited requirement set where cost reasoning is needed, expected `Benefits` should be recorded where possible, and Weigh should bridge into Build through a Commitment or keep the path visible through a Deferral. A Decision can preserve ordered rationale entries and records that informed the Owner's judgment.
 
-The current early lifecycle hypothesis is `Statement -> Expectation -> Requirement -> Commitment`, with `Deferral` as the alternate Weigh outcome that can resolve into a Commitment. `Statement` preserves the user's own words before interpretation as a runtime record. `Expectation` is tracked as a runtime record and restates the expected result and how success will be recognized in user-facing language. The MCP client should confirm captured wording before recording it on a user's behalf. Separate authority approval, usually by Owner, can be tracked when it reduces risk. `Requirement` is the team-owned commitment that translates expectations into something buildable and verifiable. Statements, expectations, and requirements should keep prior versions when their current wording changes. `Commitment` records the Owner moving requirements or expectations into Build. `Task` is a cross-cutting execution object that can be created whenever a phase needs concrete action. `Journal` is cross-cutting shared workspace context for relevant notes that do not have a dedicated record home.
+The current early lifecycle is `Statement -> Expectation -> Requirement -> Commitment`, with `Deferral` as the alternate Weigh outcome that can resolve into a Commitment. `Statement` preserves the user's own words before interpretation as a runtime record. `Expectation` is tracked as a runtime record and restates the expected result and how success will be recognized in user-facing language. The MCP client should confirm captured wording before recording it on a user's behalf. Separate authority approval, usually by Owner, can be tracked when it reduces risk. `Requirement` is the team-owned commitment that translates expectations into something buildable and verifiable. Statements, expectations, and requirements should keep prior versions when their current wording changes. `Commitment` records the Owner moving requirements or expectations into Build. `Task` is a cross-cutting execution object that can be created whenever a phase needs concrete action. `Journal` is cross-cutting shared workspace context for relevant notes that do not have a dedicated record home.
 
 A separate technical specification object is not part of the current model. Implementation and verification detail should live inside a Requirement as optional requirement detail until the need for an independent object is proven.
 
-The current engineering lifecycle hypothesis is that the main end-to-end engineering object may be `Requirement`. Requirements are shaped during elicitation, committed or deferred during Weigh, and refined into requirement detail and tasks during Build once covered by a Commitment. Task is a cross-cutting execution record with ordered entries and a current status derived from the latest status-change entry. The Engineer works primarily on Tasks and may use coding-capable tools such as Codex where appropriate. Incident and Problem are now run-side records: Incident records a specific service-impacting occurrence, and Problem records an underlying or recurring cause evidenced by incidents. Feature Request, Feedback, Authoritative Request, Release, Deployment, and Control remain useful lifecycle concepts, but they are not separate runtime records in the current model.
-
-The current review-note hypothesis is that Engineer input on Expectations or Requirements should be preserved as append-only free text. A review note can be marked important to draw attention, but it does not block progress, create a severity state, or require an Owner response.
+The current engineering lifecycle uses `Requirement` as the main end-to-end engineering object. Requirements are shaped during elicitation, committed or deferred during Weigh, and refined into requirement detail and tasks during Build once covered by a Commitment. Task is a cross-cutting execution record with ordered entries and a current status derived from the latest status-change entry. The Engineer works primarily on Tasks and may use coding-capable tools such as Codex where appropriate. Incident and Problem are run-side records: Incident records a specific service-impacting occurrence, and Problem records an underlying or recurring cause evidenced by incidents. Feature Request, Feedback, Authoritative Request, Release, Deployment, and Control remain useful lifecycle concepts, but they are not separate runtime records in the current model.
 
-The current checkpoint hypothesis is that approval and similar confirmation points are advisory risk checkpoints, not blockers. A checkpoint can be approved, formally accepted as risk by the Owner, or proceeded past with the open risk still visible. Proceeding past an open checkpoint does not close or accept the risk.
+Engineer input on Expectations or Requirements is preserved as append-only free text. A review note can be marked important to draw attention, but it does not block progress, create a severity state, or require an Owner response.
 
-The current decision rationale hypothesis is that DX Complete should preserve the matter being decided, ordered decision entries, loose argument and note entries, and the records that informed the choice. The current decision is derived from the latest decision entry while earlier decisions remain visible. DX Complete should not require numeric weights or attempt to prove that the decision was objectively correct. Authority can make a poor or unreasonable decision; the system's role is to keep the decision trail visible for accountability, review, audit, and learning.
+Approval and similar confirmation points are advisory risk checkpoints, not blockers. A checkpoint can be approved, formally accepted as risk by the Owner, or proceeded past with the open risk still visible. Proceeding past an open checkpoint does not close or accept the risk.
 
-This is a draft. The primary lifecycle object, object boundaries, role ownership, and lifecycle links may change.
+DX Complete preserves the matter being decided, ordered decision entries, loose argument and note entries, and the records that informed the choice. The current decision is derived from the latest decision entry while earlier decisions remain visible. DX Complete does not require numeric weights or attempt to prove that the decision was objectively correct. Authority can make a poor or unreasonable decision; the system's role is to keep the decision trail visible for accountability, review, audit, and learning.
 
 ## Model Layers
 
 Direction sets authority, priority, boundaries, and escalation paths.
 
-Workspace scope contains one service context and prevents records from different service scopes from mixing in the shared runtime. In the hosted model, the endpoint gets workspace scope from repo config, then the central service checks the authenticated actor identity and workspace authorization before executing tools.
+Workspace scope contains one service context and prevents records from different service scopes from mixing in the hosted record store. In the hosted model, the endpoint gets workspace scope from repo config, then the hosted DX Complete service checks the authenticated actor identity and workspace authorization before executing tools.
 
 Decision-basis work captures the initial statement and expected outcome, elicits expectations, requirements, and enough detail for useful estimates, attempts current-state cost visibility where relevant, estimates projected cost through `Estimate`, records expected value through `Benefits`, and supports Weigh. `Estimate` is the structured itemized cost record for Weigh. `Benefits` is the Owner-authored benefit record and may include quantified or qualitative benefit items. Decision records preserve rationale and linked inputs when a separate decision trail is useful.
 
@@ -70,7 +62,7 @@ Operations measurement captures actual cost and benefit observations where avail
 
 Decision rationale captures ordered entries for the matter being decided, including decision entries, argument entries, and notes without forcing those arguments into weighted or directional scoring. Decision inputs link the Decision to the records that informed it, so the trail can be followed from the choice back to its basis.
 
-## Draft Relationship Shape
+## Relationship Shape
 
 ```mermaid
 flowchart LR
@@ -105,6 +97,6 @@ flowchart LR
   Decision -. informed_by .-> Change
 ```
 
-## Revision Principle
+## Adaptation Principle
 
-Keep the model editable. If a team discovers that `Change`, `Requirement`, or another object should be the central lifecycle object, update the docs and YAML files before treating the scaffold as operating policy.
+Keep the workspace process files editable. If a team makes a local policy decision that changes how it uses `Change`, `Requirement`, or another record, update the Markdown, YAML, and Mermaid files together so the workspace guidance stays consistent.

package/docs/open-questions.md

@@ -1,6 +1,6 @@
 # Open Questions
 
-Use this file to keep uncertainty visible. The package should preserve draft thinking without making the model appear decided.
+Use this file to keep genuine unresolved policy questions visible. When a question is answered, update the related Markdown, YAML, and Mermaid files together.
 
 ## Model
 

package/docs/taxonomy.md

@@ -1,8 +1,8 @@
-# Draft Taxonomy
+# DX Complete Records
 
-The object taxonomy is draft material. Use it to preserve the current working model, not to declare final truth.
+The record set describes the current DX Complete runtime model for one workspace.
 
-## Current Runtime Record Hypothesis
+## Current Runtime Records
 
 - Workspace
 - DX Complete Ticket
@@ -39,9 +39,9 @@ These concepts remain useful, but they are not separate runtime records in the c
 - Evidence
 - Estimate Refinement
 
-## Current Lifecycle Hypothesis
+## Current Lifecycle Model
 
-`Workspace` is the runtime scope object. It contains one service scope and is the boundary for shared database records. The default MCP deployment model is one endpoint per installed workspace, with workspace identity coming from DX Complete config and access constrained by authenticated actor plus workspace authorization.
+`Workspace` is the runtime scope object. It contains one service scope and is the boundary for hosted DX Complete records. The default MCP deployment model is one endpoint per installed workspace, with workspace identity coming from DX Complete config and access constrained by authenticated actor plus workspace authorization.
 
 Workspace-scoped lifecycle records use UUIDs as primary keys and links, while also carrying a human-readable reference such as `REQ-0001`. The readable reference is for people; it does not replace the UUID.
 
@@ -67,7 +67,7 @@ Workspace-scoped lifecycle records use UUIDs as primary keys and links, while al
 
 `ReviewNote` is not a separate collection. Expectations and Requirements can carry append-only review notes. A note can be marked important, but it does not create a severity state, block progress, or require an Owner response.
 
-The main engineering object may be `Requirement`. Requirements translate expectations into team-owned commitments that are shaped during elicitation, weighed by the Owner, and refined during Build once covered by a Commitment. When a requirement changes, prior versions should be kept so the current commitment remains reconstructable.
+The main engineering object is `Requirement`. Requirements translate expectations into team-owned commitments that are shaped during elicitation, weighed by the Owner, and refined during Build once covered by a Commitment. When a requirement changes, prior versions should be kept so the current commitment remains reconstructable.
 
 `Commitment` is the Owner's point-in-time authority record that moves named requirements or expectations into Build. It can include reservations: concerns the Owner is moving forward despite.
 
@@ -89,9 +89,8 @@ Decision inputs use the `informed_by` relationship from a Decision to the record
 
 The installed scaffold includes `dxcomplete/process/taxonomy.yml`. Treat that file as the editable taxonomy source for a project.
 
-## Taxonomy Questions
+## Open Taxonomy Questions
 
-- Is `Requirement` the main lifecycle object, or should the center be `Change`, `Feature Request`, or another object?
 - Is `Workspace` sufficient as the service-scope boundary, or will related workspaces need a stronger grouping model?
 - Should future work need a grouping model above Workspace, or is Workspace sufficient as the service scope?
 - Should decision arguments remain embedded text, or should they become first-class records after repeated use?

package/docs/workflows.md

@@ -1,6 +1,6 @@
-# Draft Workflows
+# Workflows
 
-These workflows are editable drafts. They describe likely lifecycle paths without declaring them final.
+These workflows describe the current DX Complete lifecycle paths. Adapt the workspace-owned process files when a local policy decision changes how the team works.
 
 ## Current Workflow Areas
 
@@ -26,7 +26,7 @@ These workflows are editable drafts. They describe likely lifecycle paths withou
 - Actual cost / benefit observations
 - Estimate refinement
 
-## Draft End-To-End Flow
+## End-To-End Flow
 
 1. A signal enters through feedback, authoritative request, support ticket, service-impact event, recurring issue, or strategic direction.
 2. Statement capture preserves the user's own words and links the work to the Workspace context.

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "dxcomplete",
-  "version": "0.2.1",
-  "description": "Install a Next.js workspace scaffold for DX Complete process records, MCP routes, and service lifecycle documentation.",
+  "version": "0.3.0",
+  "description": "Install the DX Complete workspace-side docs, process files, and MCP route for the hosted record service.",
   "type": "module",
   "keywords": [
     "dxcomplete",
@@ -17,7 +17,7 @@
     "type": "git",
     "url": "git+https://github.com/DirectedDomains/dxcomplete.git"
   },
-  "homepage": "https://github.com/DirectedDomains/dxcomplete#readme",
+  "homepage": "https://dxcomplete.directeddomains.com",
   "bugs": {
     "url": "https://github.com/DirectedDomains/dxcomplete/issues"
   },
@@ -28,18 +28,31 @@
     "./http": {
       "types": "./dist/http/server.d.ts",
       "default": "./dist/http/server.js"
-    },
-    "./service": {
-      "types": "./dist/http/service.d.ts",
-      "default": "./dist/http/service.js"
     }
   },
   "files": [
     ".env.example",
-    "dist",
+    "dist/cli.d.ts",
+    "dist/cli.js",
+    "dist/http/server.d.ts",
+    "dist/http/server.js",
+    "dist/init.d.ts",
+    "dist/init.js",
+    "dist/install-manifest.d.ts",
+    "dist/install-manifest.js",
+    "dist/package-root.d.ts",
+    "dist/package-root.js",
+    "dist/runtime/actor.d.ts",
+    "dist/runtime/actor.js",
+    "dist/runtime/workspace.d.ts",
+    "dist/runtime/workspace.js",
+    "dist/upgrade.d.ts",
+    "dist/upgrade.js",
+    "dist/validate.d.ts",
+    "dist/validate.js",
+    "dist/version.d.ts",
+    "dist/version.js",
     "docs",
-    "scripts",
-    "src",
     "templates",
     "website",
     "README.md"
@@ -50,20 +63,7 @@
     "check:public-copy": "node scripts/check-public-copy.mjs",
     "check:env-surface": "node scripts/check-env-surface.mjs",
     "check:service-boundary": "node scripts/check-service-boundary.mjs",
-    "smoke:mcp:http": "node scripts/smoke-mcp-http.mjs --depth=light",
-    "smoke:mcp:http:light": "node scripts/smoke-mcp-http.mjs --depth=light",
-    "smoke:mcp:http:deep": "node scripts/smoke-mcp-http.mjs --depth=deep",
-    "smoke:mcp:http:full": "node scripts/smoke-mcp-http.mjs --depth=deep",
-    "smoke:mcp:http:surface": "node scripts/smoke-mcp-http.mjs --area=surface",
-    "smoke:mcp:http:docs": "node scripts/smoke-mcp-http.mjs --area=docs",
-    "smoke:mcp:http:records": "node scripts/smoke-mcp-http.mjs --area=records",
-    "smoke:mcp:http:weigh": "node scripts/smoke-mcp-http.mjs --area=weigh",
-    "smoke:mcp:http:change": "node scripts/smoke-mcp-http.mjs --area=change",
-    "smoke:mcp:http:tickets": "node scripts/smoke-mcp-http.mjs --area=tickets",
-    "smoke:mcp:http:journal": "node scripts/smoke-mcp-http.mjs --area=journal",
-    "runtime:work-order": "node scripts/runtime-work-order.mjs",
-    "validate:package": "node dist/cli.js validate --target . --package-layout",
-    "runtime:check": "node dist/cli.js check-runtime"
+    "validate:package": "node dist/cli.js validate --target . --package-layout"
   },
   "engines": {
     "node": "22.x"

package/templates/process/README.md

@@ -1,19 +1,19 @@
 # DX Complete Process Scaffold
 
-This directory is an editable draft scaffold for a DX Complete model.
+This directory contains editable process files for this DX Complete workspace.
 
-The current model is not final. Update these files as the decision-basis, engineering, service, roles, workflows, object taxonomy, and controls become clearer.
+Update these files when the workspace makes local decisions about decision-basis, engineering, service operation, roles, workflows, records, and controls.
 
-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.
+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 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.
+- `decision-basis.yml` stores decision-basis templates and Commitment-or-Deferral framing.
+- `cost-model.yml` stores current-state cost context, estimate, and actuals concepts.
+- `roles.yml` stores role responsibilities.
+- `taxonomy.yml` stores lifecycle records and relationships.
+- `workflows.yml` stores workflow templates.
+- `controls.yml` stores controls and evidence expectations.
 - `diagrams/` stores editable Mermaid diagrams.
 - `evidence/` stores captured evidence or pointers to evidence.
 - `decisions/` stores decision records.
@@ -21,7 +21,7 @@ The current scope commitment is that a Workspace contains one service scope. Sta
 
 ## 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.
+When a decision changes the workspace process, capture the decision record and update the relevant YAML, Markdown, and Mermaid files together.
 
 ## Suggested First Pass
 
@@ -35,4 +35,4 @@ Prefer explicit draft language until a decision is made. When a decision is made
 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.
+11. Review open questions before turning local process changes into policy.

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