dxcomplete 0.1.0

package/templates/process/workflows.yml

@@ -0,0 +1,210 @@
+schema: dxcomplete.workflows.v0
+status: draft
+notes:
+  - These workflows are editable templates.
+  - Add, remove, merge, or split workflows as the model becomes clearer.
+
+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.
+    likely_roles:
+      - Owner
+      - Engineer
+      - Operator
+      - End User
+    draft_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.
+      - Elicit requirements, dependencies, constraints, and unknowns from expectations.
+      - Make current-state cost context visible where it is relevant and available.
+      - Generate an itemized cost Estimate from the elicited requirement set where cost reasoning is needed.
+      - Capture Benefits where benefit reasoning is needed.
+      - Prepare the decision basis from Estimate, Benefits, risks, review notes, and linked Decisions where useful.
+      - Record a Commitment or Deferral.
+      - Link any separate Decision to the records that informed it.
+      - If committing, move the requirement set into Build and Go Live planning.
+      - If deferring, record the unmet conditions.
+      - Capture useful post-launch observations after delivery where available.
+      - Use available actuals to refine estimates for future projects.
+    rules:
+      - Cost visibility is mandatory.
+      - Complete cost data is not mandatory.
+      - Current-state cost context should be attempted where relevant, but may be unavailable.
+      - Post-launch observations should be captured when useful, but must not block closure.
+      - Transformation, greenfield, and limited-disclosure modes must be supported.
+      - Approval checkpoints reduce risk but should not block progress by themselves.
+      - Moving past an open checkpoint should leave the open risk visible.
+
+  - id: intake_triage
+    name: Intake and triage
+    draft_purpose: Decide whether a signal should become feedback, feature request, requirement, incident, problem, or another lifecycle object.
+    likely_roles:
+      - Owner
+      - Support Agent
+      - Operator
+    draft_steps:
+      - Capture signal.
+      - Identify source and urgency.
+      - Route to Owner, Operator, or Support Agent.
+      - Record initial object and links.
+      - Capture open questions.
+
+  - id: product_definition
+    name: Product definition
+    draft_purpose: Translate expectations into requirements before Weigh, then refine requirement detail after Commitment where needed.
+    likely_roles:
+      - Owner
+      - End User
+      - Engineer
+    draft_steps:
+      - Review linked Statement, Estimate, Benefits, and decisions where available.
+      - Review captured statement and expectations.
+      - Draft requirement and acceptance criteria.
+      - Add Engineer review notes where delivery input should remain visible.
+      - Refine requirement detail after Commitment where needed.
+      - Link source objects.
+      - Identify risks, constraints, and decisions.
+      - Confirm readiness for engineering review.
+
+  - id: engineering_execution
+    name: Engineering execution
+    draft_purpose: Refine committed requirements into tasks and perform implementation work.
+    likely_roles:
+      - Engineer
+    draft_steps:
+      - Review requirement and acceptance criteria.
+      - Review important notes attached to expectations or requirements.
+      - Add requirement detail and decide implementation approach.
+      - Break requirement into tasks.
+      - Assign Engineer tasks and identify Codex-assisted work where useful.
+      - Implement, review, and prepare for testing.
+
+  - id: qa_verification
+    name: QA verification
+    draft_purpose: Verify completed work against requirements and acceptance criteria.
+    likely_roles:
+      - Tester
+      - Engineer
+    draft_steps:
+      - Review requirement and task output.
+      - Plan verification.
+      - Execute checks.
+      - Record evidence and defects.
+      - Recommend pass, fail, or retest.
+
+  - id: product_validation
+    name: Product validation
+    draft_purpose: Decide whether verified work achieves the intended product outcome.
+    likely_roles:
+      - Owner
+      - End User
+    draft_steps:
+      - Review QA evidence.
+      - Validate outcome against product intent.
+      - Capture approval, rejection, or follow-up requirements.
+      - Link validation evidence.
+
+  - id: change_release_control
+    name: Change and release control
+    draft_purpose: Record a discrete service change, including plan, execution, rollback, notice, veto, emergency posture, and result.
+    likely_roles:
+      - Operator
+      - Owner
+      - Engineer
+      - Tester
+    draft_steps:
+      - Record the Change baseline.
+      - Confirm required evidence and notice.
+      - Assess risk, impact, and rollback.
+      - Append notice, veto, emergency, decision, result, recovery, note, or revision events as they occur.
+      - Link release or deployment evidence where needed.
+
+  - id: deployment_operations
+    name: Deployment and operations
+    draft_purpose: Deploy and run the service safely.
+    likely_roles:
+      - Operator
+      - Engineer
+      - Support Agent
+    draft_steps:
+      - Prepare deployment.
+      - Execute deployment.
+      - Monitor service health.
+      - Update Environment and Component records when operational inventory changes.
+      - Record deployment evidence.
+      - Route issues to incident or support 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.
+    likely_roles:
+      - Operator
+      - Engineer
+    draft_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.
+      - Keep secret pointers as store and key names only; do not store secret values.
+      - Link Components to Changes, Decisions, Risks, or Tasks when those records need the inventory context.
+
+  - id: support_incident_management
+    name: Support and incident management
+    draft_purpose: Handle user-facing issues and service-impacting events.
+    likely_roles:
+      - Support Agent
+      - Operator
+      - Owner
+      - Engineer
+    draft_steps:
+      - Capture user or monitoring signal.
+      - Classify as ticket, incident, feedback, or problem candidate.
+      - Communicate status to affected users where needed.
+      - Resolve or route.
+      - Link follow-up objects.
+
+  - id: problem_improvement
+    name: Problem and improvement management
+    draft_purpose: Convert recurring or root-cause issues into durable improvements.
+    likely_roles:
+      - Operator
+      - Engineer
+      - Owner
+      - Support Agent
+    draft_steps:
+      - Identify recurring issue or root cause.
+      - Record problem.
+      - Decide whether improvement requires a requirement or Change.
+      - Track corrective action.
+      - Capture outcome and evidence.
+
+  - id: risk_control_management
+    name: Risk and control management
+    draft_purpose: Identify risks and define controls or evidence requirements.
+    likely_roles:
+      - Owner
+      - Operator
+      - Tester
+      - Engineer
+    draft_steps:
+      - Identify risk.
+      - Decide owner and impact.
+      - Define control or mitigation.
+      - Link related lifecycle objects.
+      - Review control evidence.
+
+  - id: audit_evidence_capture
+    name: Audit and evidence capture
+    draft_purpose: Preserve evidence for decisions, verification, controls, releases, deployments, and approvals.
+    likely_roles:
+      - Operator
+      - Tester
+      - Engineer
+      - Owner
+    draft_steps:
+      - Identify required evidence.
+      - Capture or link evidence.
+      - Record responsible person and timestamp.
+      - Review completeness.
+      - Preserve for audit or retrospective use.

package/website/.well-known/oauth-authorization-server

@@ -0,0 +1,22 @@
+{
+  "issuer": "https://dxcomplete.directeddomains.com",
+  "authorization_endpoint": "https://dxcomplete.directeddomains.com/api/dxcomplete/auth/authorize",
+  "token_endpoint": "https://dxcomplete.directeddomains.com/api/dxcomplete/auth/token",
+  "registration_endpoint": "https://dxcomplete.directeddomains.com/api/dxcomplete/auth/register",
+  "response_types_supported": [
+    "code"
+  ],
+  "code_challenge_methods_supported": [
+    "S256"
+  ],
+  "token_endpoint_auth_methods_supported": [
+    "none"
+  ],
+  "grant_types_supported": [
+    "authorization_code",
+    "refresh_token"
+  ],
+  "scopes_supported": [
+    "mcp:tools"
+  ]
+}

package/website/.well-known/oauth-protected-resource/api/dxcomplete/mcp

@@ -0,0 +1,10 @@
+{
+  "resource": "https://dxcomplete.directeddomains.com/api/mcp",
+  "authorization_servers": [
+    "https://dxcomplete.directeddomains.com"
+  ],
+  "scopes_supported": [
+    "mcp:tools"
+  ],
+  "resource_name": "DX Complete"
+}

package/website/.well-known/oauth-protected-resource/api/mcp

@@ -0,0 +1,10 @@
+{
+  "resource": "https://dxcomplete.directeddomains.com/api/mcp",
+  "authorization_servers": [
+    "https://dxcomplete.directeddomains.com"
+  ],
+  "scopes_supported": [
+    "mcp:tools"
+  ],
+  "resource_name": "DX Complete"
+}

package/website/README.md

@@ -0,0 +1,12 @@
+# DX Complete
+
+DX Complete helps teams decide what is worth doing, deliver it with control, run it safely, and learn from the results.
+
+The documentation is organized into:
+
+- Start here: a short overview.
+- Outcomes: why the process exists and what it is meant to improve.
+- Flow: phase workflows from Orient through Measure.
+- Records: information kept so decisions, work, service issues, and measurements can be followed over time.
+- Roles: who is responsible for each kind of work.
+- Glossary: shared terms in plain language.

package/website/app.js

@@ -0,0 +1,36 @@
+const roleDetails = {
+  owner: "Owner sets priorities, defines outcomes and requirements, commits budget and scope, validates outcomes, and accepts risk when needed.",
+  engineer: "Engineer turns committed requirements into tasks and working changes, directly or by driving coding-capable tools.",
+  tester: "Tester checks completed work against requirements and success criteria.",
+  operator: "Operator releases, deploys, monitors, runs the service, and manages users, permissions, settings, provisioning, and run-side security.",
+  supportAgent: "Support Agent helps users, captures signals, and routes questions, feedback, and issues to the right follow-up.",
+  endUser: "End User uses the service and provides requests, feedback, corrections, and issue reports."
+};
+
+const pageName = window.location.pathname.split("/").pop() || "index.html";
+const activePage = pageName.startsWith("phase-") ? "flow.html" : pageName;
+const links = [...document.querySelectorAll(".nav-link")];
+
+links.forEach((link) => {
+  const href = link.getAttribute("href") || "";
+  const linkPage = href.split("/").pop() || "index.html";
+  link.classList.toggle("is-active", linkPage === activePage);
+});
+
+const detailPanel = document.querySelector("#role-detail");
+const roleButtons = [...document.querySelectorAll("[data-detail]")];
+
+roleButtons.forEach((button, index) => {
+  if (index === 0) {
+    button.classList.add("is-selected");
+  }
+
+  button.addEventListener("click", () => {
+    const detail = roleDetails[button.dataset.detail];
+    if (!detail || !detailPanel) return;
+
+    roleButtons.forEach((item) => item.classList.remove("is-selected"));
+    button.classList.add("is-selected");
+    detailPanel.textContent = detail;
+  });
+});

package/website/flow.html

@@ -0,0 +1,85 @@
+<!doctype html>
+<html lang="en">
+  <head>
+    <meta charset="utf-8" />
+    <meta name="viewport" content="width=device-width, initial-scale=1" />
+    <title>Flow | DX Complete</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>
+    </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="./glossary.html">Glossary</a>
+        </nav>
+      </aside>
+      <main id="content" class="content" tabindex="-1">
+        <section class="doc-section">
+          <p class="section-kicker">Flow</p>
+          <h1>Flow</h1>
+          <p class="lede">
+            Flow is where each phase is explained in detail. Each phase shows the main steps, the roles involved, the important choices, the records used, and the handoff to the next phase.
+          </p>
+        </section>
+
+        <section class="doc-section doc-section--last">
+          <h2 class="section-heading">Phase workflows</h2>
+          <p>
+            Open a phase to see how the work moves through the people involved. The rows read from top to bottom. The columns show who leads each step.
+          </p>
+          <div class="phase-index" aria-label="Phase workflow pages">
+            <a href="./phase-orient.html">
+              <span>01</span>
+              <strong>Orient</strong>
+              <p>Capture the desired outcome, restate expectations, and confirm how success will be recognized.</p>
+            </a>
+            <a href="./phase-elicit.html">
+              <span>02</span>
+              <strong>Elicit</strong>
+              <p>Turn expectations into requirements, dependencies, unknowns, and risk.</p>
+            </a>
+            <a href="./phase-weigh.html">
+              <span>03</span>
+              <strong>Weigh</strong>
+              <p>Compare expected cost, expected value, risks, and confidence before recording a Commitment or Deferral.</p>
+            </a>
+            <a href="./phase-build.html">
+              <span>04</span>
+              <strong>Build</strong>
+              <p>Turn committed requirements into tasks and working changes.</p>
+            </a>
+            <a href="./phase-go-live.html">
+              <span>05</span>
+              <strong>Go Live</strong>
+              <p>Prepare the change, confirm readiness, and put it into use.</p>
+            </a>
+            <a href="./phase-operate.html">
+              <span>06</span>
+              <strong>Operate</strong>
+              <p>Run the service, help users, and respond when something goes wrong.</p>
+            </a>
+            <a href="./phase-measure.html">
+              <span>07</span>
+              <strong>Measure</strong>
+              <p>Compare expected and actual cost or benefit when data is available.</p>
+            </a>
+          </div>
+        </section>
+      </main>
+    </div>
+    <script src="./app.js?v=5"></script>
+  </body>
+</html>