docs: adopt practical domain modeling

.agents/skills/docslime-adr/SKILL.md

@@ -23,7 +23,7 @@ The `docs/` tree must exist (run **docslime-init** if not) and `docslime` must b
 
 - Record one decision per ADR. Do not use an ADR to relitigate the whole system.
 - Keep accepted ADRs immutable; create a new superseding ADR for changed decisions.
-- Tie context back to requirement IDs, domain boundaries, constraints, or forces when they are known.
+- Tie context back to requirement IDs, modeled concepts, relationships, rules, constraints, workflows, responsibility boundaries, or forces when they are known.
 - Ask the user what options were actually considered; do not invent alternatives for polish.
 
 ## Steps

.agents/skills/docslime-fill/SKILL.md

@@ -35,12 +35,13 @@ This is a menu and a common order, not a mandatory checklist. First identify whi
 
 ## Guardrails
 
+- Use practical domain modeling: understand the real-world problem before designing the solution, establish preferred terminology, and carry meaningful concepts, relationships, constraints, rules, workflows, and lifecycle states through product decisions, implementation, and verification.
 - Do not invent product facts, requirements, architecture, tests, decisions, users, or metrics.
 - Do not fill or preserve a document merely because the template created it. Recommend removing, merging, or replacing irrelevant docs with a link to the authoritative source.
 - Treat developers, operators, integrators, and coding agents as real users when they consume a service, library, SDK, CLI, or API; retain `experience/` when DX or agent experience matters.
 - Ask one focused question at a time when facts are missing.
 - Preserve existing user-written content unless it conflicts with a correction the user gives.
-- Keep requirements testable and solution-neutral, architecture grounded in real domain boundaries, and testing mapped to Given/When/Then behavior.
+- Keep requirements testable and solution-neutral, architecture grounded in the real-world concepts, relationships, constraints, rules, workflows, lifecycle states, responsibility boundaries, and preferred terminology that matter, and testing mapped to Given/When/Then behavior.
 - Keep publishing grounded in actual artifacts, gates, promotion, verification, and rollback.
 - Present Semantic Versioning and Conventional Commits as optional publishing practices. Read the existing workflow first; never impose enforcement, rewrite history, or change release automation without explicit team agreement.
 - Keep observability tied to user outcomes as well as system health; never invent telemetry.
@@ -60,7 +61,7 @@ Read all of them before asking anything, so you understand the whole document.
 
 Follow the guidance comments. Ask **one focused question at a time**, reflect the user's answer back in your own words, and confirm before writing. Don't dump every question at once and don't invent facts — if the user doesn't know something, note it and move on.
 
-Pull context from the applicable lifecycle: when filling `REQUIREMENTS.md`, ground it in the retained local docs, experience evidence, and linked organization-level sources. When filling observability, trace signals back to requirements and discovery hypotheses.
+Pull context from the applicable lifecycle: real-world problem -> shared terminology and model -> product decisions -> implementation -> verification. When filling `REQUIREMENTS.md`, ground it in the retained local docs, experience evidence, and linked organization-level sources. When filling observability, trace signals back to requirements and discovery hypotheses so new evidence can refine the model.
 
 ### 3 — Write each section
 

.agents/skills/docslime-init/SKILL.md

@@ -54,7 +54,7 @@ docs/
 ├── experience/         # continuous discovery and experience design
 └── engineering/
     ├── README.md       # engineering lifecycle index
-    ├── ARCHITECTURE.md # domain and system design
+    ├── ARCHITECTURE.md # problem model and system design
     ├── TESTING.md      # testing strategy and CI evidence
     ├── PUBLISHING.md   # continuous delivery and rollback
     ├── OBSERVABILITY.md # production health and product learning
@@ -81,7 +81,7 @@ docslime list
 
 ### 5 — Orient and hand off
 
-The docs form a lifecycle: strategy -> product/design -> discovery -> requirements -> architecture -> testing -> publishing -> observability -> discovery. Each template contains inline `<!-- LLM: ... -->` guidance for interviewing the user and filling the sections.
+The docs connect real-world problem -> shared terminology and model -> product decisions -> implementation -> verification, within the broader strategy -> product/design -> discovery -> requirements -> architecture -> testing -> publishing -> observability -> discovery lifecycle. Each template contains inline `<!-- LLM: ... -->` guidance for interviewing the user and filling the sections.
 
 Tell the user the tailored tree is ready, and offer to start filling the first applicable document with the **docslime-fill** skill. Begin with `docs/PRODUCT.md` only when project-level product context belongs in this repo; otherwise start with the most relevant experience, requirements, or architecture document.
 

.agents/skills/docslime-kiss/SKILL.md

@@ -37,7 +37,7 @@ Answer with evidence from the files, not vibes.
 - Lead with concrete findings and file references.
 - Prefer deleting filler over rewriting it into prettier filler.
 - Distinguish current behavior from target architecture or future ideas.
-- Do not invent missing strategy, requirements, domain boundaries, tests, or ADRs.
+- Do not invent missing strategy, requirements, concepts, relationships, rules, workflows, responsibility boundaries, tests, or ADRs.
 - Do not penalize a project for intentionally removing irrelevant template files. Judge whether the retained tree serves its actual users, including developers and agents.
 - Do not rewrite accepted ADRs except for path/index maintenance; create a superseding ADR when a decision changes.
 
@@ -57,6 +57,7 @@ Good DocSlime docs are:
 - **Fit for purpose:** retain only docs that help this project's humans or agents make better decisions; omissions are explicit and authoritative external context is linked.
 - **Short enough to maintain:** no filler sections kept only because the template had them.
 - **Traceable:** requirements serve evidence; architecture serves requirements; tests prove behavior; publishing delivers verified artifacts; observability feeds production evidence back into discovery.
+- **Terminology-aligned:** the same preferred names for meaningful concepts, relationships, rules, workflows, and lifecycle states appear across product docs, requirements, interfaces, code, and tests unless a distinction is documented.
 - **Checkable:** requirements and testing claims can be verified.
 - **Current-state honest:** distinguish implemented behavior from target architecture or future ideas.
 - **Decision-light:** major durable choices live in ADRs; ordinary implementation detail does not.

.impeccable/critique/2026-07-09T20-59-43Z__docs-index-md.md

@@ -9,6 +9,8 @@ slug: docs-index-md
 
 Method: dual-agent (A: 019f48a8-cfba-77c2-9f76-630962df1a34 · B: 019f48a8-f6e0-7a10-9c31-fd531f345f45)
 
+> Historical context: This timestamped critique records the homepage's former methodology wording. Current DocSlime guidance uses practical domain modeling.
+
 ## Design Health Score
 
 | # | Heuristic | Score | Key Issue |

.impeccable/critique/2026-07-09T21-58-35Z__docs-index-md.md

@@ -9,6 +9,8 @@ slug: docs-index-md
 
 Method: dual-agent (A: 019f48db-2792-7db3-8b40-dfec3def1718 · B: 019f48db-5277-75b1-a137-fa0fdf79d6ce)
 
+> Historical context: This timestamped critique records the homepage's former methodology wording. Current DocSlime guidance uses practical domain modeling.
+
 # DocSlime Homepage Completion Critique
 
 ## Design Health Score

Cargo.toml

@@ -3,7 +3,7 @@ name = "docslime"
 version = "0.3.0"
 edition = "2021"
 rust-version = "1.74"
-description = "Opinionated DocSlime docs scaffolding for AI agents, TDD+BDD, DDD, and ADRs"
+description = "Traceable documentation lifecycle scaffolding for AI agents, domain modeling, TDD+BDD, and ADRs"
 license = "MIT"
 homepage = "https://docmd.io"
 repository = "https://github.com/DecisionNerd/DocSlime"

README.md

@@ -2,7 +2,7 @@
 
 DocSlime is an opinionated CLI and agent-skill system for turning a repo into a living, agent-ready documentation workspace. It scaffolds a standardized docs tree that coding agents can fill in with you, then tighten through skills like `docslime-fill`, `docslime-adr`, and `docslime-kiss`.
 
-The point is to keep a complete product-and-engineering learning loop in the repo: strategy, product/design context, continuous discovery, requirements, architecture, TDD/BDD evidence, delivery, observability, and decisions. DocSlime is built for services and user-facing products with user-driven Domain Driven Design and explicit traceability from evidence to production learning.
+The point is to keep a complete product-and-engineering learning loop in the repo: strategy, product/design context, continuous discovery, requirements, architecture, TDD/BDD evidence, delivery, observability, and decisions. DocSlime uses domain modeling to bring the concepts, relationships, constraints, and workflows of the real-world problem into the development cycle, with explicit traceability from evidence to production learning.
 
 ## The tree it creates
 
@@ -18,7 +18,7 @@ docs/
 │   └── README.md          # continuous discovery and experience design
 └── engineering/
     ├── README.md          # engineering lifecycle index
-    ├── ARCHITECTURE.md    # domain and system design
+    ├── ARCHITECTURE.md    # problem model and system design
     ├── TESTING.md         # TDD/BDD strategy and CI evidence
     ├── PUBLISHING.md      # continuous delivery, verification, rollback
     ├── OBSERVABILITY.md   # production health and user-outcome learning

docs/DESIGN.md

@@ -16,7 +16,7 @@ DocSlime has no graphical app today, but it still has a product experience: the
 - **Product name:** use `DocSlime` for the product and `docslime` for the binary/command.
 - **Tone:** practical, direct, and lightly playful when the name earns it. The product can carry the integrated "slime" idea without turning docs into a joke.
 - **Mascot:** use the blue anime slime as a product signal. It can appear in the homepage hero and brand surfaces, but it should support the repo/docs artifact rather than replacing developer credibility.
-- **Terminology:** use "docs tree," "product context," "design context," "requirements," "BDD," "Domain Driven Design," "ADR," "template," "skill," and "agent" consistently.
+- **Terminology:** use "docs tree," "product context," "design context," "requirements," "domain modeling," "BDD," "ADR," "template," "skill," and "agent" consistently across docs, interfaces, code, and tests.
 - **Writing rules:** generated guidance should be specific and interview-driven. Prefer "ask the user," "trace this to a requirement," and "record the decision" over vague advice.
 
 ## Impeccable Workflow
@@ -52,7 +52,7 @@ For the homepage, the desired direction is:
 
 - Requirements should be testable and carry stable IDs.
 - Testing docs should map requirements and experiences to Given/When/Then behavior coverage.
-- Architecture docs should describe domain concepts and boundaries when the project has them.
+- Architecture docs should model the real-world concepts, relationships, constraints, rules, workflows, lifecycle states, and responsibility boundaries that matter to the project.
 - Publishing docs should distinguish built, deployed, and verified artifacts and include a safe rollback path.
 - Observability should cover user outcomes as well as logs, metrics, traces, SLOs, and alerts.
 - Significant product or technical decisions should be captured as ADRs.

docs/PRODUCT.md

@@ -23,26 +23,23 @@ The system is playful in name but serious in method: it gathers the scattered pi
 - **Impeccable integration:** `docs/PRODUCT.md` and `docs/DESIGN.md` are discoverable product and design context files without needing root-level duplicates, so `impeccable` can critique and polish product surfaces from the same docs tree agents use.
 - **Lifecycle:** discovery evidence becomes requirements, architecture and tests implement the contract, publishing carries verified artifacts to users, and observability closes the learning loop.
 - **Publishing path:** the docs stay plain Markdown and can publish through `docmd.io`; the engineering publishing template also covers software artifacts, promotion, deployment, verification, and rollback.
-- **Quality stance:** requirements should trace to BDD scenarios and tests, architecture should use Domain Driven Design language where it clarifies the system, and significant choices should become ADRs.
+- **Quality stance:** requirements should trace to BDD scenarios and tests, architecture should carry a practical model of the problem into implementation, and significant choices should become ADRs.
 
 ## Quality Method
 
 DocSlime's quality method is a trace, not a ceremony:
 
 ```mermaid
 flowchart LR
-    Strategy["Strategy"] --> ProductDesign["Product / design"]
-    ProductDesign --> Discovery["Discovery"]
-    Discovery --> Requirement["Requirement"]
-    Requirement --> Architecture["Architecture"]
-    Architecture --> Test["Test"]
-    Test --> Publish["Publish"]
-    Publish --> Observe["Observe"]
-    Observe --> Strategy
+    Problem["Real-world problem"] --> Model["Shared terminology and model"]
+    Model --> Decisions["Product decisions"]
+    Decisions --> Implementation["Implementation"]
+    Implementation --> Verification["Verification"]
+    Verification -. "Refine understanding" .-> Problem
 ```
 
 - **TDD+BDD:** requirements get stable IDs, behavior is written in Given/When/Then language, and tests prove observable behavior before the docs call it done.
-- **Domain Driven Design:** architecture docs name the domain concepts, boundaries, and language that matter for the project; small projects can stay light, but they should still know their core nouns and responsibilities.
+- **Domain modeling:** DocSlime uses domain modeling to bring the concepts, relationships, constraints, and workflows of the real-world problem into the development cycle. Model the problem clearly, use the same terminology throughout the project, and ensure the software reflects the meaningful concepts, rules, and workflows of that problem.
 - **ADRs:** durable choices live in `engineering/adrs/` so future humans and agents can see why the current shape exists.
 - **Observability:** production health and user-outcome signals trace back to requirements and discovery, so learning continues after release.
 

docs/README.md

@@ -2,7 +2,7 @@
 
 DocSlime dogfoods the documentation lifecycle it scaffolds. Product and design context feed continuous discovery, requirements translate that evidence into a build contract, and the engineering docs carry the contract through architecture, testing, publishing, and production observability.
 
-Start with the [lifecycle guide](lifecycle.md) for the full UX → DDD → TDD+BDD trace and day-to-day tool usage.
+Start with the [lifecycle guide](lifecycle.md) for the full problem → model → product decisions → implementation → verification trace and day-to-day tool usage.
 
 ## Adapt the scaffold
 

docs/REQUIREMENTS.md

@@ -19,7 +19,7 @@ DocSlime must scaffold a fixed, standardized `docs/` tree into a git repo, add i
 | FR-11 | The generated tree shall include `docs/PRODUCT.md` and `docs/DESIGN.md` so `impeccable` can discover product and design context from the docs directory without duplicate root files. | Integrate with impeccable |
 | FR-12 | KISS review shall remain an agent skill rather than a `docslime` CLI subcommand. | Tighten docs after filling |
 | FR-13 | Documentation guidance shall make the lifecycle trace explicit: strategy -> product/design -> discovery -> requirement -> architecture -> test -> publish -> observe -> discovery, with ADRs linked when a durable decision explains the design. | Trace intent through production |
-| FR-14 | Architecture guidance shall ask for domain language and boundaries when useful, without forcing heavyweight Domain Driven Design ceremony on small projects. | Domain Driven Design |
+| FR-14 | Architecture guidance shall ask teams to model the real-world problem through its meaningful concepts, relationships, constraints, rules, workflows, lifecycle states, preferred terminology, and responsibility boundaries without requiring ceremonial abstractions. | Domain modeling |
 | FR-15 | Publishing guidance shall cover artifacts, versioning, CI gates, promotion, deployment verification, rollback, and official platform references without copying volatile provider instructions. | Publish verified artifacts |
 | FR-16 | Each bundled DocSlime skill shall include clear prerequisites, steps, guardrails, verification, and failure handling. | Robust agent skills |
 | FR-17 | When a legacy numbered path exists, `init` and `list` shall recognize it as satisfying the corresponding current template and shall not create a duplicate renamed file unless `--force` is explicit. | Preserve existing documentation during upgrades |
@@ -40,7 +40,7 @@ DocSlime must scaffold a fixed, standardized `docs/` tree into a git repo, add i
 | NFR-5 | Maintainability | Templates are plain Markdown files in the repo, editable without touching Rust logic (rebuild required). |
 | NFR-6 | Toolchain | Builds with Rust 1.74+ (2021 edition). |
 | NFR-7 | Publication | Generated docs remain plain Markdown suitable for the `docmd.io` publishing system. |
-| NFR-8 | Quality stance | Docs support TDD+BDD traceability, Domain Driven Design framing where useful, and ADR-backed decisions. |
+| NFR-8 | Quality stance | Docs connect the real-world problem and shared model to product decisions, implementation, TDD+BDD verification, and ADR-backed decisions. |
 | NFR-9 | Skill maintainability | Skill instructions stay compact enough for agents to follow while still naming setup, verification, and blocked-state behavior. |
 | NFR-10 | Design context | `impeccable` context loading should be verified from `docs/PRODUCT.md` and `docs/DESIGN.md` whenever homepage or design docs change. |
 | NFR-11 | Privacy | The default observability guidance must not normalize collecting sensitive repository or user data without an explicit decision, consent, and controls. |