dxcomplete 0.1.0

package/docs/decision-basis.md

@@ -0,0 +1,57 @@
+# Draft Decision Basis
+
+DX Complete should be modeled as:
+
+```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
+
+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.
+
+It should support:
+
+- Transformation projects: existing state to improved state.
+- Greenfield projects: new idea to new system.
+- Limited-disclosure projects: client or sponsor does not share enough financial or current-state data.
+
+## Required Framing
+
+Cost visibility is mandatory.
+
+Complete cost data is not mandatory.
+
+Current-state cost context should be attempted, but it may be unavailable.
+
+An itemized cost Estimate should be generated by default after enough expectations, requirements, constraints, dependencies, and unknowns have been elicited. It should keep one-time, recurring, period, and currency distinctions visible.
+
+Benefits should be recorded before Weigh where possible. Benefit items may be quantified, or qualitative when an amount is not available.
+
+Actual cost and benefit measurements should be captured after launch where available, but unavailable actuals should not block closure.
+
+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
+
+1. Statement capture
+2. Capture statement and expectations
+3. Elicit requirements, dependencies, and unknowns
+4. Current cost context attempt
+5. Itemized cost Estimate
+6. Benefits where useful
+7. Decision basis from Estimate, Benefits, risks, and linked Decision rationale
+8. Weigh: Commitment or Deferral
+9. Build
+10. Go Live
+11. Operate
+12. Actual cost / benefit observations where available
+13. Estimate refinement for future projects
+
+## Boundary
+
+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.

package/docs/diagrams.md

@@ -0,0 +1,31 @@
+# Draft Diagrams
+
+The Mermaid diagrams are draft visualizations. They should be revised as roles, workflows, and object relationships change.
+
+Installed diagram files:
+
+- `00-decision-basis.mmd`
+- `00-overview.mmd`
+- `01-intake-triage.mmd`
+- `02-product-definition.mmd`
+- `03-engineering-execution.mmd`
+- `04-qa-verification.mmd`
+- `05-product-validation.mmd`
+- `06-change-release-control.mmd`
+- `07-deployment-operations.mmd`
+- `08-support-incident-management.mmd`
+- `09-problem-improvement.mmd`
+- `10-risk-control-management.mmd`
+- `11-audit-evidence-capture.mmd`
+
+## 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.
+
+## Revision Questions
+
+- Are the diagrams better as object flows, responsibility flows, or both?
+- Should each diagram identify required evidence?
+- Should role swimlanes be standardized?
+- Should the decision-basis diagram stay separate from the Complete Engineering overview?
+- Which diagrams belong in the package docs versus the installed project scaffold?

package/docs/glossary.md

@@ -0,0 +1,147 @@
+# Glossary
+
+## Business And Service Context
+
+Approval: A separate authority confirming an expectation or decision, tracked when it reduces risk.
+
+Workspace: The runtime container for one service scope and the records connected to it.
+
+Weigh: The phase where cost, value, risk, and confidence are compared before recording a Commitment or Deferral.
+
+Commitment: An Owner record that says preparation is sufficient to commit requirements or expectations into Build, with any reservations kept visible.
+
+Reservation: A concern recorded inside a Commitment when the Owner moves forward despite it.
+
+Deferral: An Owner record for not committing yet, with explicit conditions that make the path to a future Commitment clear.
+
+Condition: Something that must be addressed before a Deferral can resolve into a Commitment.
+
+Decision: A revisitable choice record. The current decision comes from the latest decision entry, while earlier arguments, notes, and decisions remain visible.
+
+Decision Entry: One ordered entry in a Decision, such as an argument, note, or decision.
+
+Decision Input: A record that informed a decision. Outgoing links from a decision show what informed it; incoming links to a record show which decisions used it.
+
+DX Complete Ticket: A private, appendable item used to raise a question, report, request, correction, or follow-up with DX Complete.
+
+Journal: A shared workspace record for useful notes that do not have a better dedicated home.
+
+Journal Note: A raw Journal entry with text, author, and timestamp. It can be summarized later without being deleted.
+
+Journal Summary: A compact Journal entry that summarizes covered notes and points back to them so details remain retrievable.
+
+Operational Registry: The inventory of Environments and Components that shows what exists, where it lives, and which secret locations are relevant. It is not monitoring, diagnostics, a secret vault, an event log, or a runbook.
+
+Environment: A named operating context such as local, staging, or production. Components belong to one Environment so each operating context can be understood separately.
+
+Component: One operational item in one Environment, such as an app, database, queue, storage location, or external service. It records where it lives and which non-secret identifiers or secret locations matter.
+
+Locator: Structured location information for a Component, such as a URL, project, region, host, or route.
+
+Secret Pointer: A reference to where a secret is stored and what it is called. It should not contain the secret value.
+
+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.
+
+Record Link: A relationship from one record to another. Links can be added or removed when the relationship changes or was recorded incorrectly.
+
+Statement: The user's own words before DX Complete interprets or translates them, kept as the traceable root for expectations and downstream work.
+
+Expectation: The expected result and how success will be recognized, in user-facing language.
+
+Version History: Prior versions kept when an expectation or requirement changes, so current wording can be understood without losing what came before.
+
+Checkpoint: A confirmation point that reduces risk. It can be approved, formally accepted as risk by the Owner, or proceeded past with open risk visible.
+
+Proceeding Past an Open Checkpoint: Moving forward while an approval, readiness concern, or other checkpoint is still open. The risk remains visible and is not formally accepted.
+
+Risk Acceptance: An Owner decision to own an open risk on the project's behalf. It is different from simply proceeding past an open checkpoint.
+
+Transformation: Work that moves from an existing state to an improved state.
+
+Greenfield: Work that moves from a new idea to a new system.
+
+Limited Disclosure: Work where available information is incomplete by design or circumstance.
+
+## Cost And Benefit
+
+Estimate: An itemized cost estimate used during Weigh, linked to the requirements or expectations it covers.
+
+Estimate Line Item: One cost item inside an Estimate, with a label, amount or range, one-time or recurring timing, and currency.
+
+Roll-up: Grouped totals from quantified cost or benefit items, keeping one-time amounts, recurring amounts, periods, and currencies distinct.
+
+Benefits: An Owner-authored benefit record used during Weigh. Benefits may be quantified or qualitative.
+
+Benefit Item: One item inside Benefits. It may have an amount or range, or it may be qualitative with no amount.
+
+Estimate Refinement: The use of actual cost and benefit signals to improve future estimates.
+
+## Roles
+
+Owner: The role that sets authority, priority, outcome direction, requirements, product validation direction, budget commitment, escalation direction, and formal risk acceptance.
+
+Engineer: The role that turns committed requirements into tasks and working changes, directly or by driving coding-capable tools.
+
+Tester: The role that checks completed work against requirements and success criteria.
+
+Operator: The role that releases, deploys, monitors, runs the service, and manages users, permissions, settings, provisioning, and run-side security.
+
+Support Agent: The role that helps users, captures signals, and routes questions, feedback, and issues to the right follow-up.
+
+End User: The person the service is for; uses the service and provides requests, feedback, corrections, and issue reports.
+
+## Delivery
+
+Requirement: A team-owned commitment that translates expectations into something buildable and verifiable.
+
+Requirement Detail: Optional behavior, edge cases, or check notes kept with a requirement when needed.
+
+Review Note: A free-text note on an expectation or requirement. It may be marked important, but it does not block progress or require an Owner response.
+
+Task: A piece of work with an entry history. The current status comes from the latest status-change entry.
+
+Task Entry: One ordered entry in a Task, such as a comment, note, or status change.
+
+Complete Engineering: The controlled delivery lifecycle covering implementation, verification, validation, release, and deployment.
+
+Codex: A coding-capable model that may assist the Engineer. Codex is not a role.
+
+QA Verification: The check that delivered work satisfies requirements and acceptance criteria.
+
+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 Plan: The part of a Change record that explains what is changing, why, scope, timing, and notice.
+
+Execution Plan: The ordered practical steps inside a Change record for carrying out the change.
+
+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.
+
+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.
+
+Incident: A service-impacting or potentially service-impacting event requiring response.
+
+Problem: An underlying cause or recurring issue that may require investigation and improvement work.
+
+Risk: An uncertainty or exposure that could affect product, service, delivery, compliance, or operations.
+
+Control: A policy, check, approval, or evidence expectation used to manage risk or governance.
+
+Evidence: Information, an artifact, measurement, approval, or result used to support a decision, verification, release, deployment, or control.
+
+MCP: The operating interface used for role-aware DX Complete actions after initialization.
+
+CLI: The command-line bootstrap mechanism, including `npx dxcomplete init`.

package/docs/index.md

@@ -0,0 +1,60 @@
+# DX Complete Draft Scaffold
+
+## Goal
+
+Build a Node package that installs a reusable DX Complete documentation and scaffold kit into a project.
+
+## Important Context
+
+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.
+
+Do not treat the current model as final. Preserve it as draft material and make it easy to revise.
+
+## Core Product Outcome
+
+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.
+
+The broader product premise is:
+
+```text
+DX Complete = Decision Basis + Complete Engineering + Operations Measurement
+```
+
+Command target:
+
+```sh
+npx dxcomplete init
+```
+
+## Scope Of The Draft Model
+
+The installed scaffold should help describe and evolve a model covering:
+
+- Workspace and service context
+- Statement capture
+- Shared Journal context
+- Current-state cost context attempts
+- Itemized cost estimates
+- Benefits
+- 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
+- Change and release control
+- Deployment
+- Operation
+- User support
+- Administration as part of operation
+- Audit and evidence
+- Actual cost / benefit measurement where available
+- Estimate refinement for future projects
+
+## 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.

package/docs/model.md

@@ -0,0 +1,110 @@
+# Draft Model
+
+## Working Hypothesis
+
+The model is a full DX lifecycle, not merely a software development workflow.
+
+The broader product premise is:
+
+```text
+DX Complete = Decision Basis + Complete Engineering + Operations Measurement
+```
+
+It should include cost and benefit reasoning before engineering begins, both build/change roles and run/service roles, and actual measurement after delivery where available.
+
+The current runtime scope decision is `Workspace`: the shared-runtime container for one service scope. The default MCP deployment model is one endpoint per workspace. Each installed project repo carries its workspace identity in editable DX Complete config and exposes one hosted MCP route for that workspace.
+
+Workspace MCP deployments are not database runtimes. They proxy auth and MCP requests to the central DX Complete service. The central service owns database access, Google OAuth exchange, workspace membership, readable-ID allocation, and MCP tool execution. Separate database deployment may be revisited later, but workspace servers should not hold database credentials in the current model.
+
+Workspace carries the service identity through its name, summary, and mode when useful. A separate service charter record is not part of the current model; if a presentation summary is needed, it should be derived from the workspace and current expectations.
+
+The current decision-basis hypothesis is that `Statement`, `Expectation`, `Requirement`, `Estimate`, `Benefits`, and `Decision` sit upstream of Build inside the Workspace. Statements, expectations, dependencies, constraints, unknowns, and requirements should be elicited before useful estimates are generated. Current-state cost context should be attempted where relevant, an itemized cost `Estimate` should be generated by default from the elicited requirement set where cost reasoning is needed, expected `Benefits` should be recorded where possible, and Weigh should bridge into Build through a Commitment or keep the path visible through a Deferral. A Decision can preserve ordered rationale entries and records that informed the Owner's judgment.
+
+The current early lifecycle hypothesis is `Statement -> Expectation -> Requirement -> Commitment`, with `Deferral` as the alternate Weigh outcome that can resolve into a Commitment. `Statement` preserves the user's own words before interpretation as a runtime record. `Expectation` is tracked as a runtime record and restates the expected result and how success will be recognized in user-facing language. The MCP client should confirm captured wording before recording it on a user's behalf. Separate authority approval, usually by Owner, can be tracked when it reduces risk. `Requirement` is the team-owned commitment that translates expectations into something buildable and verifiable. Statements, expectations, and requirements should keep prior versions when their current wording changes. `Commitment` records the Owner moving requirements or expectations into Build. `Task` is a cross-cutting execution object that can be created whenever a phase needs concrete action. `Journal` is cross-cutting shared workspace context for relevant notes that do not have a dedicated record home.
+
+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 review-note hypothesis is that Engineer input on Expectations or Requirements should be preserved as append-only free text. A review note can be marked important to draw attention, but it does not block progress, create a severity state, or require an Owner response.
+
+The current checkpoint hypothesis is that approval and similar confirmation points are advisory risk checkpoints, not blockers. A checkpoint can be approved, formally accepted as risk by the Owner, or proceeded past with the open risk still visible. Proceeding past an open checkpoint does not close or accept the risk.
+
+The current decision rationale hypothesis is that DX Complete should preserve the matter being decided, ordered decision entries, loose argument and note entries, and the records that informed the choice. The current decision is derived from the latest decision entry while earlier decisions remain visible. DX Complete should not require numeric weights or attempt to prove that the decision was objectively correct. Authority can make a poor or unreasonable decision; the system's role is to keep the decision trail visible for accountability, review, audit, and learning.
+
+This is a draft. The primary lifecycle object, object boundaries, role ownership, and lifecycle links may change.
+
+## Model Layers
+
+Direction sets authority, priority, boundaries, and escalation paths.
+
+Workspace scope contains one service context and prevents records from different service scopes from mixing in the shared runtime. In the hosted model, the endpoint gets workspace scope from repo config, then the central service checks the authenticated actor identity and workspace authorization before executing tools.
+
+Decision-basis work captures the initial statement and expected outcome, elicits expectations, requirements, and enough detail for useful estimates, attempts current-state cost visibility where relevant, estimates projected cost through `Estimate`, records expected value through `Benefits`, and supports Weigh. `Estimate` is the structured itemized cost record for Weigh. `Benefits` is the Owner-authored benefit record and may include quantified or qualitative benefit items. Decision records preserve rationale and linked inputs when a separate decision trail is useful.
+
+Weigh records the Owner outcome: a Commitment that moves work into Build, or a Deferral that records unmet conditions.
+
+Product definition converts needs, feedback, and authoritative requests into desired outcomes and requirements.
+
+Engineering execution refines committed requirements into requirement detail where needed and decomposes work into tasks.
+
+Engineer implementation performs task work directly or by driving coding-capable tools. Codex may assist as a coding-capable model, but Codex is not itself a role.
+
+QA verification checks whether the work satisfies requirements and acceptance criteria.
+
+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.
+
+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.
+
+Support Agent work handles user-facing issues and routes signals into Owner or Operator follow-up.
+
+Operator administration manages users, permissions, configuration, and governance setup.
+
+Audit and evidence captures decisions, controls, releases, deployments, approvals, and verification results.
+
+Operations measurement captures actual cost and benefit observations where available and feeds future estimate refinement.
+
+Decision rationale captures ordered entries for the matter being decided, including decision entries, argument entries, and notes without forcing those arguments into weighted or directional scoring. Decision inputs link the Decision to the records that informed it, so the trail can be followed from the choice back to its basis.
+
+## Draft Relationship Shape
+
+```mermaid
+flowchart LR
+  Workspace --> Statement
+  Workspace --> Journal[Journal]
+  Statement --> Expectation
+  Expectation --> Requirement
+  Requirement --> Estimate
+  Requirement --> Benefits
+  Requirement --> Risk
+  Estimate --> DecisionBasis
+  Benefits --> DecisionBasis
+  Requirement --> DecisionBasis
+  Risk --> DecisionBasis
+  DecisionBasis --> Weigh{Weigh}
+  Weigh -->|Commit| Commitment
+  Weigh -->|Defer| Deferral
+  Deferral -->|Conditions resolved| Commitment
+  Commitment --> Task
+  Task --> Change
+  OperationalSignal[Operational signal] --> Ticket[DX Complete Ticket]
+  OperationalSignal --> Risk
+  OperationalSignal --> Task
+  OperationalSignal --> Requirement
+  Change --> ActualObservation[Actual cost or benefit observation]
+  ActualObservation --> Estimate
+  ActualObservation --> Benefits
+  Decision -. informed_by .-> Requirement
+  Decision -. informed_by .-> Estimate
+  Decision -. informed_by .-> Benefits
+  Decision -. informed_by .-> Risk
+  Decision -. informed_by .-> Change
+```
+
+## Revision Principle
+
+Keep the model editable. If a team discovers that `Change`, `Requirement`, or another object should be the central lifecycle object, update the docs and YAML files before treating the scaffold as operating policy.

package/docs/open-questions.md

@@ -0,0 +1,61 @@
+# Open Questions
+
+Use this file to keep uncertainty visible. The package should preserve draft thinking without making the model appear decided.
+
+## Model
+
+- What is the main lifecycle object?
+- Should the model optimize first for decision-basis clarity, product delivery, service operation, compliance, or a balanced lifecycle?
+- Which parts of the model are universal and which are implementation-specific?
+- How should related workspaces be grouped when a client, company, or portfolio view is needed?
+
+## Decision Basis
+
+- What minimum cost visibility is required before proceeding?
+- How should transformation, greenfield, and limited-disclosure workspace modes differ?
+- Should a pause or stop decision have a revisit date by default?
+
+## Cost And Benefit
+
+- Which cost categories should exist by default?
+- How should unavailable current-state baseline data be represented?
+- How should intentionally undisclosed data differ from unavailable data?
+- When are quantified Benefits required?
+- What actual cost and benefit measurements are realistic after launch?
+- How should actuals refine future estimates when the data is incomplete?
+
+## Roles
+
+- Which roles are mandatory?
+- Which roles are optional for small teams?
+- Which roles can be held by the same person?
+- Who owns final release authority?
+- Who owns service operation authority during incidents?
+
+## Objects
+
+- Are `Requirement`, `Change`, and `Feature Request` distinct enough?
+- Is `Authoritative Request` an object or a source type?
+- Should `Control` be a first-class object?
+- Should `Risk` link to requirements, releases, controls, or all of them?
+
+## Workflows
+
+- What is the minimum viable lifecycle?
+- Which approvals are required for normal changes?
+- What evidence should be recorded when normal change notice is shortened or skipped?
+- How does Support Agent route issues into Owner versus Operator follow-up?
+- Where should Product validation occur relative to release approval?
+
+## Evidence
+
+- What evidence should be required for each object?
+- Which evidence should be automated?
+- Which evidence should be manually approved?
+- How should audit trails be preserved across tools?
+
+## Packaging
+
+- Should initialization create only documentation, or also tool-specific configuration?
+- Should GitHub, Jira, Linear, or other integrations be optional modules?
+- Should teams be able to select a lightweight, standard, or regulated scaffold profile?

package/docs/roles.md

@@ -0,0 +1,42 @@
+# Roles
+
+These roles describe responsibility in the current DX Complete model. One person may hold more than one role, especially in a small team.
+
+## Current Role Model
+
+- Owner
+- Engineer
+- Tester
+- Operator
+- Support Agent
+- End User
+
+## Responsibilities
+
+Owner sets authority, priority, escalation direction, outcome direction, requirements, product validation direction, budget commitment, and formal risk acceptance.
+
+Engineer turns committed requirements into tasks and working changes. The Engineer may implement directly, drive coding-capable tools such as Codex, and leave non-blocking review notes on expectations or requirements.
+
+Tester checks completed work against requirements and success criteria.
+
+Operator releases, deploys, monitors, and runs the service. Operator also owns provisioning, administration, users, permissions, settings, infrastructure, and run-side security.
+
+Support Agent helps users, captures signals, and routes questions, feedback, and issues to the right follow-up.
+
+End User uses the service and provides requests, feedback, corrections, and issue reports.
+
+## Folded Responsibilities
+
+Coder is not a separate DX Complete role in the current model. Coding work is part of the Engineer role, and Codex is a coding-capable model that may assist the Engineer.
+
+Admin is not a separate DX Complete role in the current model. Administration is part of the Operator role because it belongs to running and governing the service safely.
+
+Director and Product Lead are not separate DX Complete roles in the current model. Their authority, outcome definition, requirement direction, product validation, budget, and risk-acceptance responsibilities are folded into Owner.
+
+## Role Questions
+
+- Which roles can be held by the same person in a small team?
+- Which Owner approvals should be explicit checkpoints?
+- Which run-side administration changes require change control?
+- Which Support Agent signals should become requirements, incidents, problems, or risks?
+- Which tasks are appropriate for Codex-assisted coding under Engineer direction?

package/docs/taxonomy.md

@@ -0,0 +1,96 @@
+# Draft Taxonomy
+
+The object taxonomy is draft material. Use it to preserve the current working model, not to declare final truth.
+
+## Current Runtime Record Hypothesis
+
+- Workspace
+- DX Complete Ticket
+- Statement
+- Journal
+- Environment
+- Component
+- Estimate
+- Benefits
+- Expectation
+- Requirement
+- Commitment
+- Deferral
+- Task
+- Change
+- Decision
+- Risk
+
+## Current Lifecycle Concepts
+
+These concepts remain useful, but they are not separate runtime records in the current model.
+
+- Feedback
+- Authoritative Request
+- Feature Request
+- Incident
+- Problem
+- Support Ticket
+- Release
+- Deployment
+- Control
+- Evidence
+- Estimate Refinement
+
+## Current Lifecycle Hypothesis
+
+`Workspace` is the runtime scope object. It contains one service scope and is the boundary for shared database records. The default MCP deployment model is one endpoint per installed workspace, with workspace identity coming from DX Complete config and access constrained by authenticated actor plus workspace authorization.
+
+Workspace-scoped lifecycle records use UUIDs as primary keys and links, while also carrying a human-readable reference such as `REQ-0001`. The readable reference is for people; it does not replace the UUID.
+
+`DX Complete Ticket` is actor-scoped communication between an MCP client user and DX Complete. It can hold a question, report, request, correction, or follow-up and can receive appended entries over time. Its durable content is the title plus entries; summary is optional and is not generated automatically. It is private from the submitting actor's view, while DX Complete replies can be tracked as unread or read by that actor. The unread list identifies tickets that need attention; reading the ticket opens the full content and marks addressed replies read. It does not ingest files or assets, and does not automatically become a shared lifecycle object.
+
+`Statement` is now a runtime collection. Statement preserves a user's own words before interpretation, can link to the expectation derived from it, and should preserve prior versions when edited.
+
+`Journal` is shared workspace context. It is append-only and should be used for relevant background, preferences, observations, and notes that do not have a better dedicated record home. Dedicated records should be used first: claims and success conditions belong in Statement, Expectation, or Requirement records; choices belong in Decisions; actions belong in Tasks; risks and service changes belong in their matching records. Operational infrastructure state belongs in the Operational Registry through Environment and Component records. The sharp test is: will anything reference or depend on this? If yes, prefer a dedicated record. Journal entries can be linked when they inform another record, and Journal content that becomes load-bearing should be promoted.
+
+`Environment` is a named operating context such as local, staging, or production. It helps the team separate what exists in one operating context from what exists in another, and it should preserve prior versions when edited.
+
+`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.
+
+`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.
+
+`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.
+
+The main engineering object may be `Requirement`. Requirements translate expectations into team-owned commitments that are shaped during elicitation, weighed by the Owner, and refined during Build once covered by a Commitment. When a requirement changes, prior versions should be kept so the current commitment remains reconstructable.
+
+`Commitment` is the Owner's point-in-time authority record that moves named requirements or expectations into Build. It can include reservations: concerns the Owner is moving forward despite.
+
+`Deferral` is the Owner's record for not committing yet. It records explicit conditions that must be addressed before a future Commitment. Conditions should have directly readable current state and append-only event history.
+
+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 an independent object is proven necessary. `Task` is a cross-cutting execution record that can be created whenever a phase needs concrete action. Task status is derived from the latest status-change entry so prior movement remains visible. The Engineer works primarily on `Task`; Codex assistance may also operate on Tasks where appropriate.
+
+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.
+
+`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.
+
+`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.
+
+Decision inputs use the `informed_by` relationship from a Decision to the records that informed it. Outbound links from a Decision answer "what informed this decision?" Inbound links to an input record answer "which decisions used this?"
+
+## Editable Source
+
+The installed scaffold includes `dxcomplete/process/taxonomy.yml`. Treat that file as the editable taxonomy source for a project.
+
+## Taxonomy Questions
+
+- Is `Requirement` the main lifecycle object, or should the center be `Change`, `Feature Request`, or another object?
+- Is `Workspace` sufficient as the service-scope boundary, or will related workspaces need a stronger grouping model?
+- Should future work need a grouping model above Workspace, or is Workspace sufficient as the service scope?
+- Should decision arguments remain embedded text, or should they become first-class records after repeated use?
+- 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?
+- Should `Control` be modeled as a lifecycle object, a policy object, or both?
+- How should evidence attach to each object?