dxcomplete 0.2.1 → 0.3.0

package/.env.example

@@ -1,10 +1,3 @@
-# Central service deployment
-DXC_MONGODB_URI=
-DXC_DATABASE_NAME=dxcomplete
-DXC_GOOGLE_CLIENT_ID=
-DXC_GOOGLE_CLIENT_SECRET=
-DXC_SERVICE_PROVISIONING_SECRET=
-
 # Workspace MCP deployment
 DXC_SERVICE_URL=
 DXC_SERVICE_CLIENT_ID=

package/README.md

@@ -1,51 +1,63 @@
 # DX Complete
 
-DX Complete installs a process, documentation, and MCP route scaffold into a Next.js workspace so a service can track decisions, requirements, tasks, changes, incidents, support, operations, and measurement over time.
+DX Complete installs the workspace-side documentation, process files, and MCP route needed for a service to use the hosted DX Complete record system.
 
-## Quick Start
+This npm package is the installer for a client workspace. It is not the central DX Complete service. The hosted service stores records, manages Google OAuth, checks workspace membership, assigns readable IDs, and executes MCP tools. An installed workspace must be provisioned in DX Complete and configured with its service URL, client ID, and client secret before its MCP route can be used.
 
-Install the scaffold into the current Next.js project:
+Create those credentials by signing in at `https://dxcomplete.directeddomains.com/account.html`. Store the secret in the client workspace hosting environment; it is shown once.
+
+For the full DX Complete method and browser documentation, see `https://dxcomplete.directeddomains.com`.
+
+## Install A Workspace
+
+1. Create or open the Next.js project repo that will expose the DX Complete route for this service.
+
+2. Install DX Complete into that project:
 
 ```sh
 npx dxcomplete init
 ```
 
-The command creates editable DX Complete documentation and process files under `dxcomplete/`, installs Next.js route wrappers under `pages/api/`, writes `vercel.json` compatibility settings, and creates `dxcomplete/workspace.json` as the workspace identity for that service.
+3. Sign in at `https://dxcomplete.directeddomains.com/account.html`.
 
-The broader product premise is:
+4. Create a workspace for the service.
 
-```text
-DX Complete = Decision Basis + Complete Engineering + Operations Measurement
+5. Replace the generated `dxcomplete/workspace.json` with the workspace JSON shown by the account page.
+
+6. Store the service values shown by the account page in the client workspace hosting environment:
+
+```sh
+DXC_SERVICE_URL=https://dxcomplete.directeddomains.com
+DXC_SERVICE_CLIENT_ID=...
+DXC_SERVICE_CLIENT_SECRET=...
 ```
 
-The scaffold is intended to help a team describe and revise a full engineering and service lifecycle model. It deliberately does not present the current model as decided. Roles, workflows, object taxonomy, and diagrams are draft material that should be edited as the operating model becomes clearer.
+7. Deploy the workspace app and verify its MCP route at `/api/mcp`.
+
+The init command creates editable DX Complete documentation and process files under `dxcomplete/`, installs Next.js route wrappers under `pages/api/`, writes Vercel compatibility settings, and creates an initial `dxcomplete/workspace.json` file. The hosted account page is the source of the provisioned workspace JSON and one-time service secret.
 
-## Product Outcome
+`DXC_SERVICE_URL` is environment-specific, `DXC_SERVICE_CLIENT_ID` is a provisioning detail, and `DXC_SERVICE_CLIENT_SECRET` is a secret. Workspace deployments do not need database credentials, OAuth provider secrets, or central-service provisioning secrets.
 
-Running `dxcomplete init` in a Next.js project creates an editable starting point for process documentation, Mermaid diagrams, taxonomy files, decision-basis templates, cost-model templates, workflow templates, placeholder controls, evidence folders, workspace configuration, Next-compatible MCP route wrappers, and optional GitHub workflow checks.
+## What It Installs
 
-The current draft model covers:
+DX Complete adds a workspace-side scaffold for one service scope:
 
-- Direction
-- Product definition
-- Engineering execution
-- Engineer implementation, including Codex-assisted work where appropriate
-- QA verification
-- Product validation
-- Change and release control
-- Deployment
-- Operation
-- User support
-- Administration as part of operation
-- Audit and evidence
+- Editable process documentation under `dxcomplete/docs/`.
+- Editable process data under `dxcomplete/process/`.
+- Workspace identity in `dxcomplete/workspace.json`.
+- Install metadata in `dxcomplete/.install-manifest.json`.
+- Next.js route wrappers under `pages/api/`.
+- Vercel compatibility settings in `vercel.json`.
+- An optional basic GitHub workflow.
+- A root `AGENTS.md` only when the target project does not already have one.
 
-## Current Framing
+The documentation and process files are intentionally local to the installed workspace. Teams can adapt them to match how their service is actually governed, built, released, operated, supported, and measured.
 
-The working hypothesis is that DX Complete describes a full decision-basis, engineering, and service lifecycle, not only software development. It includes cost and benefit reasoning before engineering begins, both build/change responsibilities and run/service responsibilities, and actual measurement after delivery where available.
+## Current Record Set
 
-The current role model includes Owner, Engineer, Tester, Operator, Support Agent, and End User. The model keeps outcome authority, requirements, product validation, and risk acceptance visible inside Owner; implementation responsibilities inside Engineer; and administration responsibilities inside Operator.
+The hosted DX Complete runtime stores records for the service lifecycle. Current runtime records include Workspace, Statement, Journal, Environment, Component, Maintenance Schedule, Expectation, Requirement, Estimate, Benefits, Value Realization, Commitment, Deferral, Task, Change, Incident, Problem, Support Request, Decision, Risk, and DX Complete Ticket.
 
-Current runtime records include Workspace, Statement, Journal, Environment, Component, Maintenance Schedule, Expectation, Requirement, Estimate, Benefits, Value Realization, Commitment, Deferral, Task, Change, Incident, Problem, Support Request, Decision, Risk, and DX Complete Ticket. Other lifecycle concepts such as Feedback, Feature Request, Release, Deployment, Control, and Evidence remain useful language but are not all current records. They are represented in editable YAML and Markdown so the model can evolve deliberately.
+Workspace-scoped lifecycle records receive readable references such as `REQ-0001` while UUID remains the primary key and link target. DX Complete keeps ledger-style records appendable where history matters, and state-style records versioned where the current shape matters.
 
 ## Usage
 
@@ -85,14 +97,19 @@ Validate the scaffold shape:
 npx dxcomplete validate
 ```
 
-By default, the scaffold is written to `dxcomplete/` and a placeholder workflow is written to `.github/workflows/dxcomplete.yml`. Existing files are not overwritten unless `--force` is provided.
+By default, the scaffold is written to `dxcomplete/` and a basic workflow is written to `.github/workflows/dxcomplete.yml`. Existing files are not overwritten unless `--force` is provided.
 
-If the target project does not already have a root `AGENTS.md`, `dxcomplete init` also writes a small Codex guidance file that points future engineering agents to `dxcomplete/docs/operating-guide.md` and `dxcomplete/docs/codex-integration.md`. If a root `AGENTS.md` already exists, it is skipped. `dxcomplete upgrade` does not overwrite a user-owned `AGENTS.md`.
+If the target project does not already have a root `AGENTS.md`, `dxcomplete init` writes a small Codex guidance file that points future engineering agents to `dxcomplete/docs/operating-guide.md` and `dxcomplete/docs/codex-integration.md`. If a root `AGENTS.md` already exists, it is skipped. `dxcomplete upgrade` does not overwrite a user-owned `AGENTS.md`.
+
+`dxcomplete upgrade` previews by default. It manages the installed route wrappers, Vercel compatibility configuration, and `dxcomplete/.install-manifest.json`. It does not overwrite `dxcomplete/workspace.json`. It reports drift in `dxcomplete/docs` and `dxcomplete/process` because those files become user-owned after installation.
 
-`dxcomplete upgrade` previews by default. It manages the installed route wrappers, Vercel compatibility configuration, and `dxcomplete/.install-manifest.json`. It does not overwrite `dxcomplete/workspace.json`. It reports drift in `dxcomplete/docs` and `dxcomplete/process` because those files are expected to become user-owned after installation.
 Run `dxcomplete init` before `dxcomplete upgrade`; upgrade refuses targets that do not already have `dxcomplete/workspace.json`.
 
-The installed MCP route wrappers are written under `pages/api/` so the workspace can remain a normal Next.js app on Vercel:
+## Workspace Runtime and MCP
+
+The installed workspace exposes a Model Context Protocol route for that workspace. The route does not open the database directly and does not run the hosted DX Complete service. It proxies auth and MCP requests to the hosted service. Access is scoped by the installed repo's `dxcomplete/workspace.json`, authenticated actor identity, and workspace membership.
+
+The installed route wrappers are written under `pages/api/` so the workspace can remain a normal Next.js app on Vercel:
 
 ```text
 pages/api/mcp.js
@@ -101,56 +118,17 @@ pages/api/dxcomplete/[...path].js
 pages/api/auth/callback/google.js
 ```
 
-The workspace identity is written to `dxcomplete/workspace.json` inside the installed project. That file belongs to the workspace app repo, not to the central DX Complete repo.
+Hosted MCP is exposed in the installed workspace app at `/api/mcp`. The workspace route uses Streamable HTTP, advertises OAuth metadata for remote MCP clients, proxies OAuth through the hosted DX Complete service, and returns DX Complete bearer tokens scoped to the configured workspace. The installed repo supplies workspace identity through `dxcomplete/workspace.json`; the hosted service stores workspace memberships and executes MCP tools.
 
-## Package and Compatibility Versioning
-
-DX Complete uses one package version, one workspace compatibility gate, and one surface fingerprint:
-
-- `packageVersion` is the npm package release version from `package.json`.
-- `workspaceCompatibility` is the installed workspace compatibility gate. It changes only when an installed workspace must update its route/proxy surface to keep talking safely to the central service.
-- `surfaceFingerprint` is an automatic hash of the live MCP tools, tool schemas, process guide, and on-demand doc references. It can change without requiring a package release or workspace upgrade.
-
-The MCP `surfaceVersion` field is a stable surface identifier. Use `surfaceFingerprint` for exact surface reconciliation and `workspaceCompatibility` for upgrade decisions.
-
-## Runtime and MCP
-
-The documentation scaffold is the first milestone. The next layer is a hosted runtime and MCP server so DX Complete can coordinate its own records. The runtime now treats Workspace as the boundary for one service scope.
-
-The default MCP deployment model is one endpoint per workspace. A Next.js project repo installs DX Complete and exposes an MCP route for that workspace, but that workspace server does not open the database directly. It proxies auth and MCP requests to the central DX Complete service. Access is scoped by the installed repo's `dxcomplete/workspace.json`, authenticated actor identity, and workspace membership. Do not use a workspace environment variable for this boundary.
-
-For the central service deployment, provide the database and Google OAuth configuration:
-
-```sh
-DXC_MONGODB_URI=mongodb+srv://...
-DXC_DATABASE_NAME=dxcomplete
-DXC_GOOGLE_CLIENT_ID=...
-DXC_GOOGLE_CLIENT_SECRET=...
-DXC_SERVICE_PROVISIONING_SECRET=...
-```
+The hosted DX Complete service uses Google OAuth for account sign-in. Its Google OAuth callback URL is:
 
-`DXC_MONGODB_URI` is a secret, `DXC_DATABASE_NAME` is environment-specific, `DXC_GOOGLE_CLIENT_ID` is a provisioning detail, `DXC_GOOGLE_CLIENT_SECRET` is a secret, and `DXC_SERVICE_PROVISIONING_SECRET` is a secret.
-
-For a workspace MCP deployment, provide only the central-service connection:
-
-```sh
-DXC_SERVICE_URL=https://dxcomplete.example
-DXC_SERVICE_CLIENT_ID=...
-DXC_SERVICE_CLIENT_SECRET=...
-```
-
-`DXC_SERVICE_URL` is environment-specific, `DXC_SERVICE_CLIENT_ID` is a provisioning detail, and `DXC_SERVICE_CLIENT_SECRET` is a secret. Workspace MCP deployments must not require `DXC_MONGODB_URI`, `DXC_GOOGLE_CLIENT_ID`, or `DXC_GOOGLE_CLIENT_SECRET`.
-
-Then build and check the runtime:
-
-```sh
-npm run build
-npm run runtime:check
+```text
+https://dxcomplete.directeddomains.com/api/dxcomplete/web/auth/google/callback
 ```
 
-The first runtime collections cover workspaces, statements, journal entries, environments, components, estimates, benefits, expectations, requirements, commitments, deferrals, tasks, changes, decisions, and risks. Use the MCP tools to create and link those records inside the intended workspace. Workspace-scoped lifecycle records receive a human-readable reference such as `REQ-0001` while UUID remains the primary key and link target.
+On Vercel, `vercel.json` must include `dxcomplete/workspace.json` in the API function bundle. The scaffold includes this by default with `functions["pages/api/**/*.js"].includeFiles`. Vercel reserves `/.well-known`, so the installed Next app rewrites the OAuth discovery metadata paths to the DX Complete route wrapper.
 
-Environment and Component records form the Operational Registry. The registry is an inventory of operational state: what exists in each environment, where it lives, and which secret names or locations are relevant. It is not monitoring, diagnostics, a secret vault, an event log, or a runbook engine. Secret pointers should identify stores and keys only; do not record secret values.
+## MCP Tools
 
 Useful MCP tools include:
 
@@ -161,7 +139,7 @@ Useful MCP tools include:
 - `list_unread_dxcomplete_ticket_replies` to see which tickets have unread DX Complete replies without returning the reply body, and `read_dxcomplete_ticket` to open a ticket and mark those replies read.
 - `append_journal_note`, `read_journal`, `get_journal_entry`, and `append_journal_summary` for shared workspace context that has no dedicated record home.
 - `get_record`, `list_records`, and `list_linked_records` to inspect records and relationships.
-- `create_workspace`, `create_statement`, and `update_statement` to establish the workspace, service scope, and traceable source wording.
+- `create_statement` and `update_statement` to capture service-scope source wording.
 - `create_environment`, `update_environment`, `list_environments`, `create_component`, `update_component`, and `list_components` for the Operational Registry.
 - `create_expectation` and `update_expectation` for user-facing conditions of satisfaction, with prior versions preserved on update.
 - `create_requirement` and `update_requirement` for requirement work, with prior requirement versions preserved on update.
@@ -175,41 +153,28 @@ Useful MCP tools include:
 - `link_records` and `unlink_records` for explicit relationships when a typed tool does not already create or remove the link.
 - `archive_record` for cleanup without deleting evidence.
 
-Hosted MCP is exposed at `/api/mcp`. The workspace route uses Streamable HTTP, advertises OAuth metadata for remote MCP clients, proxies OAuth through the central service, sends users through Google OAuth, and then returns DX Complete bearer tokens scoped to the configured workspace. The installed repo supplies workspace identity through `dxcomplete/workspace.json`; the central service stores workspace memberships and executes MCP tools.
-
-The central service exposes internal routes under `/api/dxcomplete/service/*`. Workspace servers authenticate to those routes with `DXC_SERVICE_CLIENT_ID` and `DXC_SERVICE_CLIENT_SECRET`. The provisioning route creates the workspace record, seeds the Owner membership, and returns the one-time workspace service-client secret.
-
-For Google OAuth provisioning, set the callback URL to `/api/auth/callback/google` on the hosted workspace domain.
+A DX Complete Ticket is the private place for an MCP client user to raise a question, report, request, correction, or follow-up with DX Complete. It has an ID and can receive appended entries over time. The durable content is the title plus entries; summary is optional and is not generated automatically. DX Complete replies can be tracked as unread or read by the submitting actor. Formal shared work should be created or linked separately when someone decides the ticket needs process follow-up.
 
-Use `runtime_status` to reconcile the MCP-facing contract. `surfaceFingerprint` is the single client-facing identity for the tools, tool schemas, process guide, and on-demand doc references together. `get_process_guide` and `get_doc` return the same `surfaceVersion` and `surfaceFingerprint`, so an MCP client can treat a mismatch as a stale or inconsistent surface and refresh before continuing.
-
-On Vercel, `vercel.json` must include `dxcomplete/workspace.json` in the API function bundle. The scaffold includes this by default with `functions["pages/api/**/*.js"].includeFiles`. Vercel reserves `/.well-known`, so the installed Next app rewrites the OAuth discovery metadata paths to the DX Complete route wrapper.
-
-A DX Complete Ticket is the private place for an MCP client user to raise a question, report, request, correction, or follow-up with DX Complete. It has an ID and can receive appended entries over time. The durable content is the title plus entries; summary is optional and is not generated automatically. DX Complete replies can be tracked as unread or read by the submitting actor. The unread list identifies tickets that need attention; reading the ticket opens the full content and marks addressed replies read. A ticket does not ingest files or assets, and does not automatically create a requirement, task, incident, or decision. Formal shared work should be created or linked separately when someone decides the ticket needs process follow-up.
-
-The Journal is shared workspace context, not a private ticket. It is for useful notes that do not already belong in a dedicated record such as Statement, Expectation, Requirement, Decision, Risk, Change, or Task. The routing test is: will another record reference or depend on this? If yes, prefer a dedicated record. Journal content that becomes load-bearing should be promoted to the appropriate record and linked back where useful. Journal entries are append-only and can be linked as decision inputs or provenance. The default journal read returns the hot tier: active summaries plus active raw notes. Summary entries point back to covered raw notes, and covered notes are archived out of the hot read without being deleted.
+The Journal is shared workspace context, not a private ticket. It is for useful notes that do not already belong in a dedicated record such as Statement, Expectation, Requirement, Decision, Risk, Change, or Task. Journal content that becomes load-bearing should be promoted to the appropriate record and linked back where useful.
 
 The Operating Guide explains record routing by role. Engineer/Codex work defaults to Requirement -> Task. Tester evidence usually belongs in Task entries, review notes, Risk, Decision, or Journal. Operator work uses Change for run-side alterations, Incident for specific service-impacting occurrences, Problem for underlying or recurring causes, and Environment or Component for operational inventory. Support Agent work starts with DX Complete Ticket, then promotes to shared records only when needed.
 
-Run the hosted MCP smoke test after runtime changes:
+## Package and Compatibility Versioning
 
-```sh
-npm run smoke:mcp:http
-```
+DX Complete uses one package version, one workspace compatibility gate, and one surface fingerprint:
+
+- `packageVersion` is the npm package release version from `package.json`.
+- `workspaceCompatibility` is the installed workspace compatibility gate. It changes only when an installed workspace must update its route/proxy surface to keep talking safely to the hosted DX Complete service.
+- `surfaceFingerprint` is an automatic hash of the live MCP tools, tool schemas, process guide, and on-demand doc references. It can change without requiring a package release or workspace upgrade.
 
-After updating a remote connector, compare its `runtime_status` fingerprint with the hosted smoke-test fingerprint before relying on newly added tools.
+The MCP `surfaceVersion` field is a stable surface identifier. Use `surfaceFingerprint` for exact surface reconciliation and `workspaceCompatibility` for upgrade decisions. `runtime_status`, `get_process_guide`, and `get_doc` return the same `surfaceVersion` and `surfaceFingerprint`, so an MCP client can refresh when the surface is stale or inconsistent.
 
 ## Repository Structure
 
 ```text
-docs/                 Package documentation and draft model notes
-templates/process/    Installed process scaffold
+docs/                 Installed DX Complete documentation
+templates/process/    Installed editable process files
 templates/next/       Installed Next.js route wrappers
-templates/github/     Optional GitHub workflow placeholder
-src/                  TypeScript CLI, runtime, and MCP source
-dist/                 Runtime JavaScript CLI
+templates/github/     Optional basic GitHub workflow
+dist/                 Published CLI and workspace MCP proxy handler
 ```
-
-## Design Principle
-
-Use the scaffold to preserve the current thinking without freezing it. Prefer explicit draft status, open questions, TODOs, and editable configuration over hardcoded claims about how the model must work.

package/dist/cli.js

@@ -1,6 +1,5 @@
 #!/usr/bin/env node
 import { initProject } from "./init.js";
-import { checkRuntime } from "./runtime/check.js";
 import { upgradeProject } from "./upgrade.js";
 import { validateScaffold } from "./validate.js";
 import { DXCOMPLETE_PACKAGE_VERSION } from "./version.js";
@@ -35,7 +34,7 @@ async function main(argv) {
         console.log(`Initialized DX Complete scaffold in ${result.targetDir}`);
         printList("Written", result.written);
         printList("Skipped existing", result.skipped);
-        console.log("Review dxcomplete/docs/open-questions.md before treating the draft model as policy.");
+        console.log("Next: sign in at https://dxcomplete.directeddomains.com/account.html, create the workspace, replace dxcomplete/workspace.json with the returned workspace JSON, and store the service values in the hosting environment.");
         return;
     }
     if (args.command === "upgrade") {
@@ -82,11 +81,6 @@ async function main(argv) {
         process.exitCode = 1;
         return;
     }
-    if (args.command === "check-runtime") {
-        const result = await checkRuntime({ envFile: args.envFile });
-        console.log(JSON.stringify(result, null, 2));
-        return;
-    }
     throw new Error(`Unknown command "${args.command}".`);
 }
 function parseArgs(argv) {
@@ -128,19 +122,6 @@ function parseArgs(argv) {
             parsed.targetDir = arg.slice("--target=".length);
             continue;
         }
-        if (arg === "--env") {
-            const value = argv[index + 1];
-            if (!value) {
-                throw new Error("--env requires a file path.");
-            }
-            parsed.envFile = value;
-            index += 1;
-            continue;
-        }
-        if (arg.startsWith("--env=")) {
-            parsed.envFile = arg.slice("--env=".length);
-            continue;
-        }
         if (arg === "--force") {
             parsed.force = true;
             continue;
@@ -181,17 +162,14 @@ Usage:
   dxcomplete init [--target <dir>] [--force] [--dry-run] [--no-github-workflow]
   dxcomplete upgrade [--target <dir>] [--apply] [--force]
   dxcomplete validate [--target <dir>]
-  dxcomplete check-runtime [--env <file>]
 
 Commands:
-  init            Install the editable draft scaffold into a project.
+  init            Install the editable DX Complete workspace scaffold into a project.
   upgrade         Preview or apply compatibility-critical scaffold updates.
   validate        Validate the expected scaffold file shape.
-  check-runtime   Verify MongoDB connectivity and required collections.
 
 Options:
   --target <dir>          Target project directory. Defaults to the current directory.
-  --env <file>            Runtime env file. Defaults to .env.local when present.
   --apply                 Write upgrade changes. Upgrade previews by default.
   --force                 Overwrite existing scaffold files.
   --dry-run               Show what would be written without changing files.

package/dist/validate.js

@@ -62,39 +62,23 @@ function packageRequiredFiles() {
         ...processFiles.map((file) => path.join("templates", "process", file)),
         ...diagrams.map((file) => path.join("templates", "process", "diagrams", file)),
         ".env.example",
-        path.join("api", "mcp.js"),
-        path.join("api", "dxcomplete.js"),
-        path.join("api", "dxcomplete-service.js"),
-        path.join("api", "auth", "callback", "google.js"),
-        path.join("dxcomplete", "workspace.json"),
         path.join("templates", "AGENTS.md"),
-        path.join("scripts", "check-env-surface.mjs"),
-        path.join("scripts", "smoke-mcp-http.mjs"),
-        path.join("scripts", "runtime-work-order.mjs"),
-        path.join("scripts", "check-public-copy.mjs"),
-        path.join("scripts", "check-service-boundary.mjs"),
         path.join("templates", "next", "pages", "api", "mcp.js"),
         path.join("templates", "next", "pages", "api", "dxcomplete.js"),
         path.join("templates", "next", "pages", "api", "dxcomplete", "[...path].js"),
         path.join("templates", "next", "pages", "api", "auth", "callback", "google.js"),
         path.join("templates", "next", "vercel.json"),
         path.join("templates", "github", "workflows", "dxcomplete.yml"),
-        path.join("src", "cli.ts"),
-        path.join("src", "install-manifest.ts"),
-        path.join("src", "init.ts"),
-        path.join("src", "package-root.ts"),
-        path.join("src", "http", "server.ts"),
-        path.join("src", "http", "service.ts"),
-        path.join("src", "mcp", "server.ts"),
-        path.join("src", "runtime", "auth.ts"),
-        path.join("src", "runtime", "check.ts"),
-        path.join("src", "runtime", "config.ts"),
-        path.join("src", "runtime", "mongo.ts"),
-        path.join("src", "runtime", "records.ts"),
-        path.join("src", "runtime", "workspace.ts"),
-        path.join("src", "upgrade.ts"),
-        path.join("src", "version.ts"),
-        path.join("src", "validate.ts")
+        path.join("dist", "cli.js"),
+        path.join("dist", "init.js"),
+        path.join("dist", "install-manifest.js"),
+        path.join("dist", "package-root.js"),
+        path.join("dist", "http", "server.js"),
+        path.join("dist", "runtime", "actor.js"),
+        path.join("dist", "runtime", "workspace.js"),
+        path.join("dist", "upgrade.js"),
+        path.join("dist", "version.js"),
+        path.join("dist", "validate.js")
     ];
 }
 function installedRequiredFiles() {

package/docs/cost-model.md

@@ -1,4 +1,4 @@
-# Draft Cost Model
+# Cost Model
 
 Cost modeling is first-class in DX Complete. Do not reduce the top-level model to OPEX. OPEX/CAPEX-like categories may exist inside the cost model, but the top-level concept should remain Cost Model / Decision Basis.
 
@@ -27,7 +27,7 @@ The structured `Estimate` record is cost-only. It keeps one-time and recurring c
 
 Expected value belongs in `Benefits`. Benefits may include quantified items with amounts, or qualitative items that are complete without an amount.
 
-## Draft Cost Objects
+## Cost Records
 
 Current-state cost context should be attempted where relevant. It may be complete, partial, unavailable, or limited by disclosure, but it is no longer a separate runtime record in the current model.
 

package/docs/decision-basis.md

@@ -1,14 +1,8 @@
-# Draft Decision Basis
+# Decision Basis
 
-DX Complete should be modeled as:
+A DX effort implies a decision to improve or create a digital capability with some expected business benefit. DX Complete therefore keeps cost and benefit reasoning before engineering work begins, plus actual measurement after delivery where possible.
 
-```text
-Decision Basis + Complete Engineering + Operations Measurement
-```
-
-This is a working hypothesis, but the need is first-class. A DX effort implies a decision to improve or create a digital capability with some expected business benefit. The model therefore needs cost and benefit reasoning before engineering work begins, plus actual measurement after delivery where possible.
-
-## Draft Purpose
+## Purpose
 
 The decision basis explains whether there is enough reason and confidence to commit after expectations and the requirement set have been elicited, or whether the work should be deferred until named conditions are addressed.
 
@@ -34,7 +28,7 @@ Actual cost and benefit measurements should be captured after launch where avail
 
 Weigh should preserve the Owner outcome: a Commitment if the work moves forward, or a Deferral if conditions must be addressed first. Decision records can still preserve decision entries, loose argument entries, notes, and linked inputs where a separate decision trail is useful. DX Complete should not require numeric weights or treat the recorded rationale as proof that the choice was objectively correct.
 
-## Draft Decision Basis Flow
+## Decision Basis Flow
 
 1. Statement capture
 2. Capture statement and expectations
@@ -54,4 +48,4 @@ Weigh should preserve the Owner outcome: a Commitment if the work moves forward,
 
 The decision basis should not pretend that every DX effort has clean financial data. It should create visibility into what is known, estimated, unavailable, or deliberately undisclosed.
 
-The terms and object names are draft. The concepts are important.
+The workspace process files can adapt the terms and local guidance, but the decision basis should keep cost, benefit, risk, confidence, and the Owner outcome visible.

package/docs/diagrams.md

@@ -1,6 +1,6 @@
-# Draft Diagrams
+# Diagrams
 
-The Mermaid diagrams are draft visualizations. They should be revised as roles, workflows, and object relationships change.
+The Mermaid diagrams visualize the current DX Complete workflow and record relationships. Revise them when local role, workflow, or record decisions change.
 
 Installed diagram files:
 
@@ -20,7 +20,7 @@ Installed diagram files:
 
 ## Diagram Policy
 
-Each diagram should stay editable in plain Mermaid. Avoid diagrams that imply the model is final unless the related Markdown and YAML have been updated to match that decision.
+Each diagram should stay editable in plain Mermaid. Keep related Markdown, YAML, and Mermaid files aligned when a workspace policy changes.
 
 ## Revision Questions
 

package/docs/index.md

@@ -1,61 +1,47 @@
-# DX Complete Draft Scaffold
+# DX Complete Workspace Docs
 
 ## Goal
 
-Build a Node package that installs a reusable DX Complete documentation and scaffold kit into a project.
+These files describe how this workspace uses DX Complete to decide what is worth doing, deliver it with control, run it safely, and learn from the results.
 
-## Important Context
+DX Complete is installed into a service repo as workspace-owned documentation, process files, and route wrappers. The hosted DX Complete service stores records, manages sign-in, checks workspace membership, assigns readable IDs, and executes MCP tools.
 
-This is exploratory design work. The product goal is stable, but the engineering/service model, roles, workflows, object taxonomy, and diagrams are still being discovered.
+## Install And Provisioning Context
 
-Do not treat the current model as final. Preserve it as draft material and make it easy to revise.
+The npm package installs the workspace-side files. It does not install the hosted DX Complete service.
 
-## Core Product Outcome
+For a new workspace:
 
-The package should initialize a repo with process documentation, Mermaid diagrams, taxonomy files, decision-basis templates, cost-model templates, workflow templates, and placeholder configuration for a full end-to-end DX engineering and service control model.
+1. Run `npx dxcomplete init` in the Next.js project repo.
+2. Sign in at `https://dxcomplete.directeddomains.com/account.html`.
+3. Create a workspace for the service.
+4. Replace `dxcomplete/workspace.json` with the workspace JSON shown by the account page.
+5. Store `DXC_SERVICE_URL`, `DXC_SERVICE_CLIENT_ID`, and `DXC_SERVICE_CLIENT_SECRET` in the workspace app hosting environment.
+6. Deploy the workspace app and verify the MCP route at `/api/mcp`.
 
-The broader product premise is:
+The service secret is shown once by the account page. Store it in the hosting environment, not in the repo.
 
-```text
-DX Complete = Decision Basis + Complete Engineering + Operations Measurement
-```
+## Current Product Model
 
-Command target:
-
-```sh
-npx dxcomplete init
-```
-
-## Scope Of The Draft Model
-
-The installed scaffold should help describe and evolve a model covering:
+The installed model covers:
 
 - Workspace and service context
 - Statement capture
 - Shared Journal context
-- Current-state cost context attempts
-- Itemized cost estimates
-- Benefits
+- Cost context, itemized estimates, benefits, and measured value
 - Decision basis for Weigh
-- Weigh outcomes with Commitment or Deferral records, plus decisions with linked inputs where useful
-- Direction
-- Product definition
-- Engineering execution
-- Engineer implementation, including Codex-assisted work where appropriate
-- QA verification
-- Product validation
+- Weigh outcomes with Commitment or Deferral records
+- Decisions with linked inputs where useful
+- Direction and product definition
+- Engineering execution and task work
+- QA verification and product validation
 - Change and release control
-- Deployment
-- Operation
-- User support
+- Deployment and operation
+- User support, incidents, and problems
 - Administration as part of operation
-- Audit and evidence
-- Actual cost / benefit measurement where available
-- Estimate refinement for future projects
+- Audit, evidence, risk, and measurement
 - Role-by-role operating guidance
 
 ## How To Read These Docs
 
-These documents record the current working hypotheses. They are not requirements for how every organization must operate.
-
-Use `operating-guide.md` to see how each role should choose records in normal work. Use `open-questions.md` to capture uncertain areas before turning them into policy. Use the YAML files in `templates/process/` as the editable source for roles, objects, workflows, and controls.
+Use `operating-guide.md` to see how each role should choose records in normal work. Use `taxonomy.md` to understand the current record set. Use `open-questions.md` for genuine unresolved policy questions. Use the YAML files in `dxcomplete/process/` as editable workspace process data.