dxcomplete 0.2.1 → 0.3.0

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

package/templates/process/workflows.yml

@@ -1,19 +1,19 @@
 schema: dxcomplete.workflows.v0
-status: draft
+status: current
 notes:
   - These workflows are editable templates.
-  - Add, remove, merge, or split workflows as the model becomes clearer.
+  - Add, remove, merge, or split workflows when the workspace process changes.
 
 workflows:
   - id: decision_basis
     name: Decision basis
-    draft_purpose: Move from user statement to expectations and requirements with enough detail to support useful cost, benefit, risk, confidence, and Weigh outcomes.
+    purpose: Move from user statement to expectations and requirements with enough detail to support useful cost, benefit, risk, confidence, and Weigh outcomes.
     likely_roles:
       - Owner
       - Engineer
       - Operator
       - End User
-    draft_steps:
+    steps:
       - Capture statement in the user's own words and restate the expected result.
       - Confirm captured wording before recording it on the user's behalf.
       - Confirm how success will be recognized where possible.
@@ -39,12 +39,12 @@ workflows:
 
   - id: intake_triage
     name: Intake and triage
-    draft_purpose: Decide whether a signal should become a ticket, statement, requirement, task, risk, decision, change, journal note, or another matching lifecycle concept.
+    purpose: Decide whether a signal should become a ticket, statement, requirement, task, risk, decision, change, journal note, or another matching lifecycle concept.
     likely_roles:
       - Owner
       - Support Agent
       - Operator
-    draft_steps:
+    steps:
       - Capture signal.
       - Identify source and urgency.
       - Route to Owner, Operator, or Support Agent.
@@ -53,15 +53,15 @@ workflows:
 
   - id: product_definition
     name: Product definition
-    draft_purpose: Translate expectations into requirements before Weigh, then refine requirement detail after Commitment where needed.
+    purpose: Translate expectations into requirements before Weigh, then refine requirement detail after Commitment where needed.
     likely_roles:
       - Owner
       - End User
       - Engineer
-    draft_steps:
+    steps:
       - Review linked Statement, Estimate, Benefits, and decisions where available.
       - Review captured statement and expectations.
-      - Draft requirement and acceptance criteria.
+      - Prepare requirement and acceptance criteria.
       - Add Engineer review notes where delivery input should remain visible.
       - Refine requirement detail after Commitment where needed.
       - Link source objects.
@@ -70,10 +70,10 @@ workflows:
 
   - id: engineering_execution
     name: Engineering execution
-    draft_purpose: Refine committed requirements into tasks and perform implementation work.
+    purpose: Refine committed requirements into tasks and perform implementation work.
     likely_roles:
       - Engineer
-    draft_steps:
+    steps:
       - Review requirement and acceptance criteria.
       - Review important notes attached to expectations or requirements.
       - Add requirement detail and decide implementation approach.
@@ -83,11 +83,11 @@ workflows:
 
   - id: qa_verification
     name: QA verification
-    draft_purpose: Verify completed work against requirements and acceptance criteria.
+    purpose: Verify completed work against requirements and acceptance criteria.
     likely_roles:
       - Tester
       - Engineer
-    draft_steps:
+    steps:
       - Review requirement and task output.
       - Plan verification.
       - Execute checks.
@@ -96,11 +96,11 @@ workflows:
 
   - id: product_validation
     name: Product validation
-    draft_purpose: Decide whether verified work achieves the intended product outcome.
+    purpose: Decide whether verified work achieves the intended product outcome.
     likely_roles:
       - Owner
       - End User
-    draft_steps:
+    steps:
       - Review QA evidence.
       - Validate outcome against product intent.
       - Capture approval, rejection, or follow-up requirements.
@@ -108,13 +108,13 @@ workflows:
 
   - id: change_release_control
     name: Change and release control
-    draft_purpose: Record a discrete service change, including change type, plan, execution, rollback, notice, veto, and result.
+    purpose: Record a discrete service change, including change type, plan, execution, rollback, notice, veto, and result.
     likely_roles:
       - Operator
       - Owner
       - Engineer
       - Tester
-    draft_steps:
+    steps:
       - Record the Change baseline.
       - Confirm required evidence and notice.
       - Assess risk, impact, and rollback.
@@ -124,12 +124,12 @@ workflows:
 
   - id: deployment_operations
     name: Deployment and operations
-    draft_purpose: Deploy and run the service safely.
+    purpose: Deploy and run the service safely.
     likely_roles:
       - Operator
       - Engineer
       - Support Agent
-    draft_steps:
+    steps:
       - Prepare deployment.
       - Execute deployment.
       - Monitor service health.
@@ -139,11 +139,11 @@ workflows:
 
   - id: operational_registry
     name: Operational Registry maintenance
-    draft_purpose: Keep the inventory of Environments and Components understandable without turning it into monitoring, diagnostics, secret storage, event history, or a runbook.
+    purpose: Keep the inventory of Environments and Components understandable without turning it into monitoring, diagnostics, secret storage, event history, or a runbook.
     likely_roles:
       - Operator
       - Engineer
-    draft_steps:
+    steps:
       - Create or update Environment records for named operating contexts.
       - Create or update Component records for operational items in each Environment.
       - Record locator details, non-secret identifiers, and secret pointers where useful.
@@ -152,13 +152,13 @@ workflows:
 
   - id: support_incident_management
     name: Support and incident management
-    draft_purpose: Handle user-facing issues and service-impacting events, using Incident when a specific occurrence needs response history.
+    purpose: Handle user-facing issues and service-impacting events, using Incident when a specific occurrence needs response history.
     likely_roles:
       - Support Agent
       - Operator
       - Owner
       - Engineer
-    draft_steps:
+    steps:
       - Capture user or monitoring signal.
       - Classify as ticket, statement, incident, problem, risk, task, change, decision, requirement, or journal note.
       - Communicate status to affected users where needed.
@@ -167,13 +167,13 @@ workflows:
 
   - id: problem_improvement
     name: Problem and improvement management
-    draft_purpose: Convert recurring or root-cause signals into durable improvements through Problem records and linked follow-up.
+    purpose: Convert recurring or root-cause signals into durable improvements through Problem records and linked follow-up.
     likely_roles:
       - Operator
       - Engineer
       - Owner
       - Support Agent
-    draft_steps:
+    steps:
       - Identify recurring issue or root cause.
       - Capture the underlying or recurring cause through Problem when incidents or operational evidence support it.
       - Decide whether improvement requires a Requirement, Task, Risk, Decision, or Change.
@@ -182,13 +182,13 @@ workflows:
 
   - id: risk_control_management
     name: Risk and control management
-    draft_purpose: Identify risks and define controls or evidence requirements.
+    purpose: Identify risks and define controls or evidence requirements.
     likely_roles:
       - Owner
       - Operator
       - Tester
       - Engineer
-    draft_steps:
+    steps:
       - Identify risk.
       - Decide owner and impact.
       - Define control or mitigation.
@@ -197,13 +197,13 @@ workflows:
 
   - id: audit_evidence_capture
     name: Audit and evidence capture
-    draft_purpose: Preserve evidence for decisions, verification, controls, releases, deployments, and approvals.
+    purpose: Preserve evidence for decisions, verification, controls, releases, deployments, and approvals.
     likely_roles:
       - Operator
       - Tester
       - Engineer
       - Owner
-    draft_steps:
+    steps:
       - Identify required evidence.
       - Capture or link evidence.
       - Record responsible person and timestamp.

package/website/account.html

@@ -0,0 +1,57 @@
+<!doctype html>
+<html lang="en">
+  <head>
+    <meta charset="utf-8" />
+    <meta name="viewport" content="width=device-width, initial-scale=1" />
+    <title>DX Complete Account</title>
+    <link rel="stylesheet" href="./styles.css?v=5" />
+  </head>
+  <body>
+    <a class="skip-link" href="#content">Skip to content</a>
+
+    <header class="topbar">
+      <div class="topbar__brand">
+        <span class="brand-mark" aria-hidden="true">DX</span>
+        <span>
+          <strong>DX Complete</strong>
+          <small>Plan, deliver, run, measure</small>
+        </span>
+      </div>
+      <div class="topbar__actions">
+        <a class="topbar__link" href="https://www.npmjs.com/package/dxcomplete" target="_blank" rel="noreferrer">npm</a>
+        <a class="topbar__link" href="./account.html">Sign in</a>
+      </div>
+    </header>
+
+    <div class="layout">
+      <aside class="sidebar" aria-label="Documentation pages">
+        <div class="sidebar__eyebrow">Pages</div>
+        <nav>
+          <a class="nav-link" href="./index.html">Start here</a>
+          <a class="nav-link" href="./outcomes.html">Outcomes</a>
+          <a class="nav-link" href="./flow.html">Flow</a>
+          <a class="nav-link" href="./objects.html">Records</a>
+          <a class="nav-link" href="./roles.html">Roles</a>
+          <a class="nav-link" href="./operating-guide.html">Operating Guide</a>
+          <a class="nav-link" href="./glossary.html">Glossary</a>
+        </nav>
+      </aside>
+
+      <main id="content" class="content" tabindex="-1">
+        <section class="doc-section doc-section--last">
+          <p class="section-kicker">Account</p>
+          <h1>Set Up A Workspace</h1>
+          <p class="lede">
+            Sign in with Google, create a workspace, and save the service values needed by your project.
+          </p>
+
+          <div class="account-panel" data-account>
+            <p>Loading account state...</p>
+          </div>
+        </section>
+      </main>
+    </div>
+
+    <script src="./app.js?v=5"></script>
+  </body>
+</html>