dxcomplete 0.1.0 → 0.2.1

package/dist/validate.js

@@ -7,6 +7,7 @@ const docs = [
     "cost-model.md",
     "glossary.md",
     "model.md",
+    "operating-guide.md",
     "roles.md",
     "taxonomy.md",
     "workflows.md",
@@ -66,9 +67,10 @@ function packageRequiredFiles() {
         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", "dogfood-work-order.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"),

package/docs/codex-integration.md

@@ -1,29 +1,56 @@
-# Codex Integration Draft
+# Codex Integration
 
 Codex is an instance of a coding-capable model. It is not a role in the DX Complete operating model.
 
 The related role is `Engineer`: the person who performs implementation work directly or drives coding-capable tools. Codex may assist the Engineer.
 
-## Current Hypothesis
+## Engineer Default
 
-Codex assistance works primarily on `Task` objects. The Engineer defines or accepts the implementation approach, assigns task scope, reviews outputs, and decides whether work is ready for testing.
+Codex assistance should normally follow:
 
-This does not mean Codex can only work on tasks. Codex may also help draft requirements, generate diagrams, update documentation, collect evidence, or propose workflow revisions. Those uses should remain subject to the owning role.
+```text
+Requirement -> Task
+```
 
-## Draft Operating Pattern
+Use `Task` for ordinary implementation work. Keep the task linked to the requirement it implements when that relationship exists.
 
-1. Owner defines the requirement and acceptance criteria.
-2. Engineer may add non-blocking review notes to the expectation or requirement where delivery input should stay visible.
-3. Engineer refines the committed requirement into requirement detail and tasks.
-4. Engineer performs implementation on a task, with Codex assistance where appropriate.
-5. Engineer reviews the implementation output.
-6. Tester verifies against requirements and acceptance criteria.
-7. Owner validates the result.
+Use other records only when warranted:
 
-## Guardrails To Resolve
+- `Decision`: a meaningful implementation choice or tradeoff should remain legible.
+- `Risk`: uncertainty or exposure could affect value, delivery, service, or compliance.
+- `Journal`: relevant context has no better dedicated record home.
+- `Change`: the work is a discrete alteration to the running service, not merely coding or documentation work.
 
-- What level of task detail is required before Codex assistance can begin?
-- Who approves Codex-generated changes?
-- What evidence should Codex produce automatically?
-- How should Codex hand off incomplete or uncertain work?
-- Which tasks are not appropriate for Codex assistance?
+Do not create ITSM-style records merely because Codex is doing work. Change, Incident, and Problem language belongs to run-side service control. Use `Change` for a discrete alteration to the running service, `Incident` for a specific service-impacting occurrence, and `Problem` for an underlying or recurring cause behind incidents.
+
+## Operating Pattern
+
+1. Owner defines or approves the expectation and requirement context.
+2. Engineer may add non-blocking review notes where delivery input should stay visible.
+3. Engineer breaks committed requirements into tasks.
+4. Codex assists the Engineer on the task.
+5. Engineer reviews the output and decides whether it is ready for verification.
+6. Tester verifies against requirements and success criteria.
+7. Owner validates the outcome where outcome validation is needed.
+
+## Fresh Codex Session Checklist
+
+When a Codex session starts without prior context:
+
+1. Read `dxcomplete/docs/operating-guide.md`.
+2. Read this file.
+3. Identify the active role. For Codex, assume Engineer assistance unless the user explicitly says otherwise.
+4. Prefer Task for implementation work.
+5. Use Decision, Risk, Journal, or Change only when the record meaning fits.
+6. Do not invent Owner intent or End User feedback. Create Incident or Problem records only when the operational meaning fits.
+7. Keep public documentation user-facing when editing website pages.
+
+## Evidence
+
+Codex should leave evidence through the normal project channel: code changes, tests run, validation output, and concise handoff notes. When the work itself needs DX Complete recordkeeping, use the smallest appropriate record:
+
+- Task entry for work progress or completion.
+- Decision entry for a meaningful choice.
+- Risk for unresolved uncertainty.
+- Journal only for useful context with no better home.
+- Change only for run-side alteration context.

package/docs/glossary.md

@@ -40,6 +40,10 @@ Locator: Structured location information for a Component, such as a URL, project
 
 Secret Pointer: A reference to where a secret is stored and what it is called. It should not contain the secret value.
 
+Maintenance Schedule: A recurring operational hygiene record with cadence, start date, rationale, and due state derived from linked completed Changes or Tasks.
+
+Cadence: How often recurring operational work is expected to happen, such as every month or every quarter.
+
 Informed By: The relationship from a decision to the record that helped inform it.
 
 Readable ID: A short record reference such as `REQ-0001`. It helps people refer to records while the UUID remains the primary key.
@@ -60,6 +64,8 @@ Risk Acceptance: An Owner decision to own an open risk on the project's behalf.
 
 Transformation: Work that moves from an existing state to an improved state.
 
+Git Commit Reference: An optional commit identifier recorded on a Change result or recovery event to show what code state was used for that execution attempt or rollback. DX Complete records the reference as provided and does not validate it.
+
 Greenfield: Work that moves from a new idea to a new system.
 
 Limited Disclosure: Work where available information is incomplete by design or circumstance.
@@ -78,6 +84,12 @@ Benefit Item: One item inside Benefits. It may have an amount or range, or it ma
 
 Estimate Refinement: The use of actual cost and benefit signals to improve future estimates.
 
+Value Realization: A record that compares baseline and actual value metrics after work or operation when measurement is available.
+
+Value Metric: One before-and-after measure inside Value Realization, with a baseline, optional actual value, unit, direction, and measured dates.
+
+Measured At: The date or time when a value metric baseline or actual value was measured.
+
 ## Roles
 
 Owner: The role that sets authority, priority, outcome direction, requirements, product validation direction, budget commitment, escalation direction, and formal risk acceptance.
@@ -112,7 +124,7 @@ QA Verification: The check that delivered work satisfies requirements and accept
 
 Product Validation: The check that verified work achieves the intended product outcome.
 
-Change: A record for a specific alteration to the running service. It keeps the plan, execution, rollback, notice, veto, emergency, decision, result, and recovery history without controlling the operation.
+Change: A record for a specific alteration to the running service. It keeps the change type, plan, execution, rollback, notice, veto, decision, result, recovery history, and optional Git commit references without controlling the operation.
 
 Change Plan: The part of a Change record that explains what is changing, why, scope, timing, and notice.
 
@@ -120,8 +132,6 @@ Execution Plan: The ordered practical steps inside a Change record for carrying
 
 Rollback Plan: The part of a Change record that explains how to reverse or recover if the change fails or should not remain in use.
 
-Emergency Change: A change where normal notice is shortened or skipped because both importance and immediacy are recorded.
-
 Veto: A serious recorded objection to a Change by the Owner or Engineer. It does not mechanically stop the Operator, but proceeding over it creates a strong accountability record.
 
 Release: A grouped set of changes prepared for delivery.
@@ -130,13 +140,35 @@ Deployment: The act of putting a release or change into an environment.
 
 ## Operations And Control
 
-Support Ticket: A user-facing support interaction, request, or issue report.
+Support Request: A shared support record for a reported user experience, question, request, or issue that needs workspace-visible follow-up.
+
+Support Request Entry: One ordered entry in a Support Request, such as raised, triage, update, escalated, resolved, reopened, or note.
+
+Incident: A specific service-impacting or potentially service-impacting occurrence with response history, current status, and severity derived from ordered entries.
+
+Incident Entry: One ordered entry in an Incident, such as detected, update, severity, resolved, reopened, or note.
+
+Problem: An underlying or recurring cause evidenced by one or more Incidents, with investigation, root-cause, known-error, and resolution history.
+
+Problem Entry: One ordered entry in a Problem, such as identified, investigation, root cause, known error, resolved, reopened, or note.
+
+Risk: An uncertainty or exposure that could affect product, service, delivery, compliance, or operations. Current risk state comes from ordered entries.
+
+Risk Entry: One ordered entry in a Risk, such as identified, assessment, treatment, monitor note, closed, or reopened.
+
+Risk Treatment: The chosen response to a Risk: accept, mitigate, transfer, or avoid. Formal acceptance is Owner-only.
+
+Change Type: The classification of a Change as standard, normal, or emergency.
+
+Standard Change: A low-risk, pre-understood, repeatable Change type.
+
+Normal Change: The default Change type for an assessed alteration to the running service.
 
-Incident: A service-impacting or potentially service-impacting event requiring response.
+Emergency Change: A Change where normal notice or review is shortened because the situation is important and immediate.
 
-Problem: An underlying cause or recurring issue that may require investigation and improvement work.
+Root Cause: The underlying cause recorded in a Problem when investigation identifies why one or more incidents occurred.
 
-Risk: An uncertainty or exposure that could affect product, service, delivery, compliance, or operations.
+Known Error: A Problem state showing an underlying cause is known even if the full improvement is not complete.
 
 Control: A policy, check, approval, or evidence expectation used to manage risk or governance.
 

package/docs/index.md

@@ -52,9 +52,10 @@ The installed scaffold should help describe and evolve a model covering:
 - Audit and evidence
 - Actual cost / benefit measurement where available
 - Estimate refinement for future projects
+- 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 `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 `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.

package/docs/model.md

@@ -24,7 +24,7 @@ The current early lifecycle hypothesis is `Statement -> Expectation -> Requireme
 
 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. Feature Request, Feedback, Authoritative Request, Incident, Problem, Release, Deployment, and Control remain useful lifecycle concepts, but they are not separate runtime records in the current model.
+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.
 
@@ -54,11 +54,11 @@ QA verification checks whether the work satisfies requirements and acceptance cr
 
 Product validation checks whether the verified result is the right product outcome.
 
-Change and release control records the service change, readiness basis, notice, vetoes, emergency posture, result, and recovery where needed.
+Change and release control records the service change, change type, readiness basis, notice, vetoes, result, and recovery where needed.
 
 Deployment and operation release, monitor, and run the service safely.
 
-`Change` is the current run-side control record for a discrete, time-bound alteration to the running service. It is not a standing Operations Plan. A Change keeps baseline sections for change plan, execution steps, rollback plan, and risk or impact, then records notice, veto, emergency posture, decision, result, recovery, notes, and plan revisions as append-only events. DX Complete records the accountability trail; it does not perform or enforce the operation.
+`Change` is the current run-side control record for a discrete, time-bound alteration to the running service. It is not a standing Operations Plan. A Change keeps baseline sections for change type, change plan, execution steps, rollback plan, and risk or impact, including downstream impact where known: what else may be affected and what depends on what is changing. It then records notice, veto, decision, result, recovery, notes, and plan revisions as append-only events. Result and recovery events may include optional Git commit references for point-in-time traceability. DX Complete stores those references as provided; it does not call Git, validate commits, or assume a specific Git host. Emergency is a Change type, not a separate event path. DX Complete records the accountability trail; it does not perform or enforce the operation.
 
 Support Agent work handles user-facing issues and routes signals into Owner or Operator follow-up.
 

package/docs/operating-guide.md

@@ -0,0 +1,116 @@
+# Operating Guide
+
+DX Complete works best when each role uses the record that matches the work in front of them. This guide is the role-facing companion to the phase and records documentation.
+
+## Owner
+
+The Owner sets direction, weighs value against cost and risk, records Commitment or Deferral, validates outcomes, and formally accepts risk when the project should own it.
+
+Common records:
+
+- `Statement`
+- `Expectation`
+- `Benefits`
+- `Value Realization`
+- `Commitment`
+- `Deferral`
+- `Decision`
+- `Risk`
+
+Do not treat every comment as a requirement. Do not treat End User feedback as approval unless the same person is explicitly acting in an authority role.
+
+## Engineer and Codex Assistance
+
+The Engineer turns committed requirements into tasks and working changes. Codex may assist the Engineer, but Codex is a coding-capable tool, not a DX Complete role.
+
+Default path:
+
+```text
+Requirement -> Task
+```
+
+Use `Task` for ordinary implementation work. Use `Decision` for meaningful choices between alternatives. Use `Risk` for uncertainty or exposure. Use `Journal` only for relevant context with no better record home. Use `Change` only when work becomes a discrete alteration to the running service.
+
+Do not create ITSM-style records merely because implementation work is happening.
+
+## Tester
+
+The Tester checks completed work against requirements and success criteria. Verification evidence should stay tied to the requirement or task being checked.
+
+Common records:
+
+- `Task` entries for verification notes tied to implementation work.
+- `Review Note` when the check reveals useful input on an expectation or requirement.
+- `Risk` when the check exposes uncertainty or possible harm.
+- `Decision` when a test result forces a choice.
+- `Journal` when the note is useful context with no better home.
+
+Do not default to `Change` for testing observations.
+
+## Operator and Administration
+
+The Operator manages run-side change, operational inventory, rollout and rollback planning, monitoring, users, permissions, settings, provisioning, and run-side security.
+
+Common records:
+
+- `Change` for a discrete alteration to the running service.
+- `Environment` for a named operating context such as local, staging, or production.
+- `Component` for an environment-specific app, database, queue, storage location, external service, or other operational item.
+- `Maintenance Schedule` for recurring operational hygiene such as scheduled checks, reviews, rotations, or maintenance duties.
+- `Risk` and `Decision` when run-side accountability needs to remain visible.
+
+The Operational Registry stores pointers and identifiers, not secret values. Record where a secret is stored and what it is called; do not record the credential itself.
+
+## Support Agent
+
+The Support Agent helps users, captures questions and reports, and routes signals into shared follow-up only when shared follow-up is needed.
+
+Start with `Support Request` for a user-facing question, report, request, or issue that needs shared follow-up. Use `DX Complete Ticket` only for private communication with DX Complete itself.
+
+Possible promotions:
+
+- `Statement` when the signal expresses a need or concern in the user's own words.
+- `Requirement` when the desired truth needs to become buildable and checkable.
+- `Task` when someone needs to act.
+- `Support Request` when the signal needs a shared support thread.
+- `Risk` when uncertainty or exposure needs to remain visible.
+- `Decision` when a meaningful choice is needed.
+- `Change` when the follow-up is a discrete alteration to the running service.
+- `Journal` when the signal is relevant context with no better home.
+
+## End User
+
+The End User uses the service and provides requests, feedback, corrections, and issue reports. Another role captures that input when it belongs in DX Complete.
+
+End User feedback is not authority approval unless that person is also explicitly acting in an authority role.
+
+## Record Routing
+
+| Situation | Use | Reason |
+| --- | --- | --- |
+| Normal implementation work | `Task` | A task is concrete work someone needs to do. |
+| Meaningful choice | `Decision` | A decision keeps the choice and its inputs legible. |
+| Uncertainty or exposure | `Risk` | A risk keeps uncertainty visible without pretending it is resolved. |
+| Run-side alteration | `Change` | A change records service alteration, execution, rollback, and events. |
+| User-facing support follow-up | `Support Request` | A support request keeps the shared support thread visible without turning every report into an incident. |
+| Operational inventory | `Environment` or `Component` | The registry shows what exists and where it lives. |
+| Recurring operational hygiene | `Maintenance Schedule` | A maintenance schedule keeps cadence and due state visible while completed changes or tasks show what happened. |
+| Measured value after work or operation | `Value Realization` | Value realization compares baseline and actual metrics without replacing benefits or estimates. |
+| Useful context with no better home | `Journal` | Journal is fallback context, not the default home for load-bearing records. |
+| Question, report, request, correction, or follow-up with DX Complete | `DX Complete Ticket` | A ticket keeps private communication with DX Complete before shared process follow-up is created. |
+
+The practical test is:
+
+```text
+Will anything reference or depend on this?
+```
+
+If yes, prefer the dedicated record that can carry the relationship. If no, and the context is still relevant, Journal may fit.
+
+## ITSM Boundary
+
+`Change` is the current first-class run-side control record. Use it for a discrete alteration to the running service, with a change type, plan, execution path, rollback path, risk and impact, downstream impact where known, and event history. Result and recovery events may include optional Git commit references for the specific execution attempt or rollback. These are references only; DX Complete does not inspect Git or require them.
+
+`Incident` and `Problem` are current run-side records. Use Incident for a specific service-impacting or potentially service-impacting occurrence. Use Problem for an underlying or recurring cause evidenced by one or more incidents.
+
+Do not create ITSM-style records merely because work is happening. Use service records when the information is truly run-side control, operational signal, or service history.

package/docs/taxonomy.md

@@ -10,14 +10,19 @@ The object taxonomy is draft material. Use it to preserve the current working mo
 - Journal
 - Environment
 - Component
+- Maintenance Schedule
 - Estimate
 - Benefits
+- Value Realization
 - Expectation
 - Requirement
 - Commitment
 - Deferral
 - Task
 - Change
+- Incident
+- Problem
+- Support Request
 - Decision
 - Risk
 
@@ -28,9 +33,6 @@ These concepts remain useful, but they are not separate runtime records in the c
 - Feedback
 - Authoritative Request
 - Feature Request
-- Incident
-- Problem
-- Support Ticket
 - Release
 - Deployment
 - Control
@@ -53,10 +55,14 @@ Workspace-scoped lifecycle records use UUIDs as primary keys and links, while al
 
 `Component` is one operational item in one Environment. It can describe the kind of component, where it lives, non-secret identifiers, secret pointers, and notes. Secret pointers should name where a secret is stored and what it is called, not the secret value itself. Component history should stay versioned state; service events and process history belong in Change, Decision, Risk, Task, or other matching records.
 
+`Maintenance Schedule` is a recurring operational hygiene record. It records the name, kind, cadence, start date, rationale, and notes for scheduled checks, reviews, rotations, or maintenance duties. Due state is derived from cadence and completed Changes or Tasks linked to the schedule.
+
 `Estimate` is the structured itemized cost record used during Weigh. It can cover requirements or expectations, rolls cost totals up while keeping one-time, recurring, period, and currency distinctions visible, and should preserve prior versions when edited.
 
 `Benefits` is the Owner-authored benefit record used during Weigh. It can cover requirements or expectations, may include quantified or qualitative benefit items, rolls up quantified benefit totals only, and should preserve prior versions when edited.
 
+`Value Realization` is the measured-value record used during Measure. It compares baseline and actual metrics for expectations, requirements, or commitments where measurement is available. Metrics without actual values remain open rather than blocking closure.
+
 `Expectation` is now a runtime collection. It restates the expected result and how success will be recognized, in user-facing language. The MCP client should confirm wording before recording it on a user's behalf. Separate authority approval can be tracked when it reduces risk. Requirements should link back to the expectations they are meant to satisfy. When an expectation changes, prior versions should be kept so the current wording is not silently detached from what came before.
 
 `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.
@@ -71,9 +77,9 @@ A separate technical specification object is not part of the current model. Impl
 
 Approval and similar checkpoints are 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.
 
-`Feature Request`, `Feedback`, `Authoritative Request`, `Incident`, `Problem`, `Support Ticket`, `Release`, `Deployment`, `Control`, `Evidence`, and `Estimate Refinement` remain lifecycle concepts. In the current runtime, they should be represented through current records such as Requirement, Task, Change, Risk, Decision, Estimate, Benefits, or DX Complete Ticket unless a later model decision promotes them into first-class records.
+`Incident`, `Problem`, and `Support Request` are current run-side or support records. Use Incident for a specific service-impacting or potentially service-impacting occurrence, Problem for an underlying or recurring cause evidenced by one or more incidents, and Support Request for a shared user-facing support thread. `Feature Request`, `Feedback`, `Authoritative Request`, `Release`, `Deployment`, `Control`, `Evidence`, and `Estimate Refinement` remain lifecycle concepts. In the current runtime, they should be represented through current records such as Requirement, Task, Change, Incident, Problem, Support Request, Risk, Decision, Estimate, Benefits, Value Realization, or DX Complete Ticket unless a later model decision promotes them into first-class records.
 
-`Change` is now the run-side record for a discrete alteration to the running service. It should keep the original plan, execution steps, rollback plan, and risk or impact as the baseline, then use append-only events for notice, veto, emergency posture, decision, result, recovery, notes, and plan revisions. A Change is not a standing Operations Plan and does not enforce deployment.
+`Change` is now the run-side record for a discrete alteration to the running service. It should keep the change type, original plan, execution steps, rollback plan, and risk or impact as the baseline, including downstream impact where known: what else may be affected and what depends on what is changing. Then use append-only events for notice, veto, decision, result, recovery, notes, and plan revisions. Result and recovery events may carry optional Git commit references for each execution attempt or rollback, but those references are recorded as provided and are not validated by DX Complete. Emergency is a Change type, not a separate event path. A Change is not a standing Operations Plan and does not enforce deployment.
 
 `Decision` captures the matter being decided, ordered argument/note/decision entries, and links to records that informed the choice. The current decision is derived from the latest decision entry, while earlier decisions and arguments remain visible. Arguments are not weighted by default and do not need to be mapped to a single side of a choice. DX Complete preserves the decision trail; it does not decide whether the authority's reasoning was correct.
 
@@ -91,6 +97,6 @@ The installed scaffold includes `dxcomplete/process/taxonomy.yml`. Treat that fi
 - Should decision arguments remain embedded text, or should they become first-class records after repeated use?
 - How should limited-disclosure cost data be represented?
 - Should `Authoritative Request` be a separate object or a source category for Requirements?
-- Should `Incident` and `Support Ticket` be distinct in small teams?
+- When should a `Support Request` escalate into an `Incident`?
 - Should `Control` be modeled as a lifecycle object, a policy object, or both?
 - How should evidence attach to each object?

package/docs/workflows.md

@@ -28,7 +28,7 @@ These workflows are editable drafts. They describe likely lifecycle paths withou
 
 ## Draft End-To-End Flow
 
-1. A signal enters through feedback, authoritative request, support ticket, incident, or strategic direction.
+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.
 3. Orient captures statement, confirms wording before recording, and restates expectations with approval where needed.
 4. Elicitation translates expectations into requirements, dependencies, constraints, and unknowns.
@@ -41,13 +41,15 @@ These workflows are editable drafts. They describe likely lifecycle paths withou
 11. Engineer implements tasks and may use Codex assistance where appropriate.
 12. Tester verifies completed work against requirements and acceptance criteria.
 13. Owner validates whether the result is the right outcome.
-14. Change and release control records the service change plan, execution steps, rollback path, notice, vetoes, emergency posture, and result.
+14. Change and release control records the service change type, plan, execution steps, rollback path, notice, vetoes, and result.
 15. Operator carries out the change in external operational tooling, then monitors and runs the service.
 16. Environment and Component records are kept current when the operational inventory changes.
 17. Support Agent handles user-facing issues and routes signals back into Owner or Operator follow-up.
 18. Actual cost / benefit observations are captured where available.
 19. Audit evidence is captured across decisions, controls, releases, deployments, measurement, and verification.
 
+`Change` is the current first-class run-side control record. `Incident` is the current first-class record for a specific service-impacting occurrence. `Problem` is the current first-class record for an underlying or recurring cause evidenced by incidents. Use these records only when their meaning fits; do not create ITSM records merely because work is happening.
+
 ## Workflow Questions
 
 - Which steps require explicit approval?
@@ -55,6 +57,6 @@ These workflows are editable drafts. They describe likely lifecycle paths withou
 - What cost visibility is enough to proceed when baseline data is unavailable?
 - How should proceeding past an open checkpoint be shown when the risk remains open?
 - What evidence is required before release?
-- What notice, veto, and emergency evidence is enough for a Change record?
+- What notice, veto, change-type, and emergency rationale is enough for a Change record?
 - What operational inventory belongs in Environment and Component records rather than Journal?
 - What is the smallest useful workflow for a solo project?

package/package.json

@@ -1,8 +1,26 @@
 {
   "name": "dxcomplete",
-  "version": "0.1.0",
-  "description": "Reusable DX Complete / Complete Engineering documentation and scaffold kit.",
+  "version": "0.2.1",
+  "description": "Install a Next.js workspace scaffold for DX Complete process records, MCP routes, and service lifecycle documentation.",
   "type": "module",
+  "keywords": [
+    "dxcomplete",
+    "mcp",
+    "nextjs",
+    "service-management",
+    "requirements",
+    "operations",
+    "process",
+    "codex"
+  ],
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/DirectedDomains/dxcomplete.git"
+  },
+  "homepage": "https://github.com/DirectedDomains/dxcomplete#readme",
+  "bugs": {
+    "url": "https://github.com/DirectedDomains/dxcomplete/issues"
+  },
   "bin": {
     "dxcomplete": "dist/cli.js"
   },
@@ -43,7 +61,7 @@
     "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",
-    "dogfood:work-order": "node scripts/dogfood-work-order.mjs",
+    "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"
   },

package/scripts/{dogfood-work-order.mjs → runtime-work-order.mjs}

@@ -473,14 +473,14 @@ function elapsedSeconds(started) {
 }
 
 function printHelp() {
-  console.log(`dogfood-work-order
+  console.log(`runtime-work-order
 
 Usage:
-  node scripts/dogfood-work-order.mjs --plan ./work-order.json
-  node scripts/dogfood-work-order.mjs --module ./one-off.mjs
+  node scripts/runtime-work-order.mjs --plan ./work-order.json
+  node scripts/runtime-work-order.mjs --module ./one-off.mjs
 
 Purpose:
-  Open Mongo once and batch dogfood reads, ticket replies, simple verification,
+  Open one runtime connection and batch ticket reads, ticket replies, simple verification,
   and optional one-off work-order modules.
 
 Plan shape: