@kaddo/cli 3.39.0 → 3.39.1

package/README.md

@@ -536,6 +536,7 @@ create --from roadmap → owners → guard → explain`.
 | v3.37.1 | Unified next-step: one shared resolver (`core/next-step.ts`) powers `context`, `understand` and `explain` (Phase + Readiness) so they never diverge; agent JSON exposes `nextStepRecommendation`. Fixes duplicate `capabilities` line in explain |
 | v3.38 | Open-question source locations: `kaddo questions` shows each question's `Source` (path:line), `Status`, `Severity`, `Note` + a copy/paste resolution example and localized how-to-resolve guide; JSON/report/MCP carry `sourcePath`, `line`, `raw`, `note` |
 | v3.39 | Existing capability discovery: state-aware `capabilities.md` (pre-ai/legacy = evidence-backed Capability Inventory + Gaps + Roadmap Candidate Signals; legacy adds criticality/change-risk/modernization); capability-agent discovers with evidence, roadmap-agent treats capabilities as primary source |
+| v3.39.1 | Domain-oriented capability inventory: pre-ai/legacy `capabilities.md` groups capabilities under `## Capability Domains` (functional domains, not technical folders); gaps/candidates name their `Domain`; roadmap-agent reads it as a domain map; work-item-agent recommends `related_domain` + `related_capability` |
 
 **Optional modules (installed with `kaddo add`):**
 

package/dist/index.js

@@ -2213,11 +2213,11 @@ Adapt to \`project.state\` (from \`.kaddo/config.yml\`):
 
 - **new \u2192 Planned Capability Definition.** Define the capabilities the product *should* have. Use
   \`[planned]\` items; evidence is not required yet.
-- **pre-ai \u2192 Existing Capability Discovery.** Document the capabilities the system *already has*, as a
-  structured inventory with **evidence**, status and gaps \u2014 a photograph of what exists today, not a
-  wishlist.
-- **legacy \u2192 Legacy Capability Discovery.** Same inventory plus **criticality**, **change risk**,
-  **operational dependency** and **modernization notes** per capability.
+- **pre-ai \u2192 Existing Capability Discovery (Domain-Oriented Capability Inventory).** Document the
+  capabilities the system *already has*, **grouped by functional domain**, with **evidence**, status
+  and gaps \u2014 a photograph of what exists today, not a wishlist.
+- **legacy \u2192 Legacy Capability Discovery.** Same domain-oriented inventory plus **criticality**,
+  **change risk**, **operational dependency** and **modernization notes** per domain/capability.
 
 ## Capability status values
 
@@ -2256,10 +2256,12 @@ Analyze the context pack and identify:
 7. Suggested ownership.
 8. Candidate code globs if evident.
 
-For **pre-ai** and **legacy**, produce the richer inventory (see Output Format): a
-\`## Capability Inventory\` with status + evidence per capability, a \`## Capability Gaps\` section, and
-\`## Roadmap Candidate Signals\` (signals only \u2014 never a formal roadmap). For **legacy**, add
-\`Criticality\`, \`Change risk\`, \`Operational dependency\` and \`Modernization notes\` per capability.
+For **pre-ai** and **legacy**, produce the domain-oriented inventory (see Output Format): a
+\`## Capability Domains\` section where each \`### Domain:\` groups capabilities by functional
+responsibility (with Purpose + Evidence summary), each \`#### Capability:\` has status + evidence, plus
+\`## Capability Gaps\` and \`## Roadmap Candidate Signals\` (signals only \u2014 never a formal roadmap). Every
+gap and candidate names its \`Domain\` and \`Related capability\`. For **legacy**, add \`Criticality\`,
+\`Change risk\`, \`Operational dependency\` and \`Modernization notes\`.
 
 ## Constraints
 
@@ -2312,36 +2314,50 @@ Generated from Kaddo Context Pack.
 ## Suggested Next Step
 \`\`\`
 
-### Output Format \u2014 pre-ai / legacy (Existing Capability Discovery)
+### Output Format \u2014 pre-ai / legacy (Domain-Oriented Capability Inventory)
+
+Group capabilities by **functional domain**, not by technical folder. Infer domains from the system
+(e.g. Loyalty, Billing & Subscriptions, Communications, Operations & Automation) \u2014 do not use a rigid
+universal taxonomy and do not use folders like \`src/components\` or \`src/app/api\` as domains. A single
+capability may have evidence across layers (frontend hook + API route + table + webhook).
 
 \`\`\`markdown
 # Existing Capabilities
 
-## Capability Inventory
+## Capability Domains
+
+### Domain: <Domain name>
+
+**Purpose:** <functional responsibility of this domain>
+
+**Evidence summary:**
+- \`<path>\` / \`<route>\` / \`<table>\` / \`<function>\`
+<!-- legacy only: -->
+**Criticality:** low | medium | high
+**Change risk:** low | medium | high
+**Operational dependency:** <...>
 
-### <Capability name>
+#### Capability: <Capability name>
 
 - Status: implemented | partial | inferred | risky | deprecated | unknown
 - Capability type: business | product | technical | integration | operational
 - User-facing: yes | no | internal
 - Evidence:
-  - \`<path/to/file>\`
-  - \`<route>\` / \`<table>\` / \`<function>\`
-- Related flows / data / integrations:
+  - \`<path/to/file>\` / \`<route>\` / \`<table>\` / \`<function>\`
+- Related flows:
+- Related data:
+- Related integrations:
 - Current behavior:
 - Known constraints:
 - Risks or uncertainty:
 - Open questions:
   - [open] ...
-<!-- legacy only: -->
-- Criticality: low | medium | high
-- Change risk: low | medium | high
-- Operational dependency:
-- Modernization notes:
+<!-- legacy only, per capability: Modernization notes -->
 
 ## Capability Gaps
 
 - [gap] <Gap description>
+  - Domain: <Domain name>
   - Related capability: <name>
   - Impact: low | medium | high
   - Possible roadmap candidate: yes | no
@@ -2349,10 +2365,20 @@ Generated from Kaddo Context Pack.
 ## Roadmap Candidate Signals
 
 - [candidate] <Potential roadmap candidate>
-  - Based on: partial capability | gap | risk | open question | business goal
+  - Domain: <Domain name>
   - Related capability: <name>
+  - Based on: partial capability | gap | risk | open question | business goal
 \`\`\`
 
+### Domain grouping rules
+
+- Group by **functional responsibility**, never by technical folder.
+- A capability may span multiple layers \u2014 list all its evidence.
+- Keep the VS-074 evidence rule: \`implemented\` needs concrete evidence; indirect \u2192 \`inferred\`; none \u2192
+  \`unknown\`. Never invent domains, paths, routes, tables or functions.
+- Every \`[gap]\` names its \`Domain\` and \`Related capability\`; every \`[candidate]\` names \`Domain\`,
+  \`Related capability\` and \`Based on\`.
+
 ## Where to Save the Result
 
 Save the output as \`knowledge/product/capabilities.md\`.
@@ -2472,7 +2498,8 @@ Use this agent after capabilities and architecture are understood (or at least a
 Provide \`.kaddo/context-pack.md\` as the primary input, and treat
 \`knowledge/product/capabilities.md\` as the **primary source for roadmap candidates** (VS-074).
 
-Derive roadmap candidates from the capability inventory, prioritizing:
+Read \`capabilities.md\` as a **map of functional domains** (\`## Capability Domains\`). Derive roadmap
+candidates from the inventory, prioritizing:
 
 - \`partial\` capabilities (finish what exists)
 - \`## Capability Gaps\` (\`[gap]\` items, especially Impact: high)
@@ -2481,6 +2508,15 @@ Derive roadmap candidates from the capability inventory, prioritizing:
 - resolved/assumed/deferred open questions and business goals
 - technical risks and decision candidates
 
+Each roadmap candidate should reference its \`Domain\` and \`Related capability\`, e.g.:
+
+\`\`\`md
+- [candidate] Harden idempotent payment webhook processing.
+  - Domain: Billing & Subscriptions
+  - Related capability: Payment Webhook Processing
+  - Based on: risk
+\`\`\`
+
 **Do not** build a roadmap from general ideas when \`capabilities.md\` is still a placeholder or weak:
 if capabilities are not yet discovered, recommend running the \`capability-agent\` first.
 
@@ -2895,9 +2931,10 @@ A refined Work Item intended to be saved under the lifecycle workspace:
 
 **Suggested ownership (code globs):**
 
-**Related capability:** <!-- recommended (VS-074): the capability from
-knowledge/product/capabilities.md this Work Item advances, so work traces back to a real capability.
-Add \`related_capability: <name>\` to the front matter when known. -->
+**Related domain / capability:** <!-- recommended (VS-074/074.1): the functional domain and the
+capability from knowledge/product/capabilities.md this Work Item advances, so work traces back to the
+system's functional map. Add \`related_domain: <domain>\` and \`related_capability: <name>\` to the front
+matter when known. -->
 \`\`\`
 
 ## Where to Save the Result
@@ -7084,6 +7121,9 @@ function isPlaceholderLine(line) {
   if (/<[^>]+>/.test(t)) return true;
   if (/^[-*]\s+[^:]+:\s*$/.test(t)) return true;
   if (/^[-*]\s+[^:]+:\s*\S.*\s\|\s/.test(t)) return true;
+  if (/^\*\*[^*]+:\*\*\s*$/.test(t)) return true;
+  if (/^\*\*[^*]+:\*\*\s*_.*_$/.test(t)) return true;
+  if (/^\*\*[^*]+:\*\*\s*\S.*\s\|\s/.test(t)) return true;
   return false;
 }
 function isStructuralLine(line, inFrontMatter) {
@@ -7926,7 +7966,7 @@ function resolveNextStep(dir, now = /* @__PURE__ */ new Date()) {
   if (qBusiness !== "useful") return refine("refine-business", "business-agent", B, qBusiness);
   if (qProduct !== "useful" || qCap !== "useful") {
     if (qCap !== "useful") {
-      return refine("refine-product", "capability-agent", CAP, qCap, discovery ? "discover and document existing system capabilities in" : "complete");
+      return refine("refine-product", "capability-agent", CAP, qCap, discovery ? "discover and document existing system capabilities grouped by functional domains in" : "complete");
     }
     return refine("refine-product", "capability-agent", P, qProduct);
   }
@@ -12252,18 +12292,29 @@ _Document the product capabilities that should exist._
 `,
     "pre-ai": `# Existing Capabilities
 
-> Discover the capabilities the system already has (evidence-backed). Use the capability-agent to fill this in \u2014 run \`kaddo add agents\`, then feed it the context pack.
+> Discover the capabilities the system already has, grouped by **functional domain** (not technical folders), evidence-backed. Use the capability-agent to fill this in \u2014 run \`kaddo add agents\`, then feed it the context pack.
 
-## Capability Inventory
+## Capability Domains
 
-### <Capability name>
+### Domain: <Domain name>
+
+**Purpose:** _What functional responsibility this domain covers._
+
+**Evidence summary:**
+- _\`path\`, route, table or function._
+
+#### Capability: <Capability name>
 
 - Status: implemented | partial | inferred | risky | deprecated | unknown
 - Capability type: business | product | technical | integration | operational
 - User-facing: yes | no | internal
 - Evidence:
   - _\`path/to/file\`, route, table or function \u2014 or \`pending validation\`._
-- Related flows / data / integrations:
+- Related flows:
+  - _..._
+- Related data:
+  - _..._
+- Related integrations:
   - _..._
 - Current behavior:
   - _..._
@@ -12277,6 +12328,7 @@ _Document the product capabilities that should exist._
 ## Capability Gaps
 
 - [gap] _Gap description._
+  - Domain: _<Domain name>_
   - Related capability: _<name>_
   - Impact: low | medium | high
   - Possible roadmap candidate: yes | no
@@ -12284,24 +12336,32 @@ _Document the product capabilities that should exist._
 ## Roadmap Candidate Signals
 
 - [candidate] _Potential roadmap candidate._
-  - Based on: partial capability | gap | risk | open question | business goal
+  - Domain: _<Domain name>_
   - Related capability: _<name>_
+  - Based on: partial capability | gap | risk | open question | business goal
 `,
     legacy: `# Legacy Capabilities
 
-> Discover existing capabilities plus their criticality, change risk and modernization signals. Use the capability-agent to fill this in.
+> Discover existing capabilities grouped by **functional domain** (not technical folders), plus criticality, change risk and modernization signals. Use the capability-agent to fill this in.
 
-## Capability Inventory
+## Capability Domains
 
-### <Capability name>
+### Domain: <Domain name>
+
+**Purpose:** _What functional responsibility this domain covers._
+
+**Criticality:** low | medium | high
+**Change risk:** low | medium | high
+**Operational dependency:** _..._
+
+**Evidence summary:**
+- _\`path\`, route, table or function._
+
+#### Capability: <Capability name>
 
 - Status: implemented | partial | inferred | risky | deprecated | unknown
 - Capability type: business | product | technical | integration | operational
 - User-facing: yes | no | internal
-- Criticality: low | medium | high
-- Change risk: low | medium | high
-- Operational dependency:
-  - _..._
 - Evidence:
   - _\`path/to/file\`, route, table or function \u2014 or \`pending validation\`._
 - Current behavior:
@@ -12314,6 +12374,7 @@ _Document the product capabilities that should exist._
 ## Capability Gaps
 
 - [gap] _Gap description._
+  - Domain: _<Domain name>_
   - Related capability: _<name>_
   - Impact: low | medium | high
   - Possible roadmap candidate: yes | no
@@ -12321,8 +12382,9 @@ _Document the product capabilities that should exist._
 ## Roadmap Candidate Signals
 
 - [candidate] _Potential modernization or roadmap candidate._
-  - Based on: partial capability | gap | risk | open question | business goal
+  - Domain: _<Domain name>_
   - Related capability: _<name>_
+  - Based on: partial capability | gap | risk | open question | business goal
 `
   },
   codebase: {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@kaddo/cli",
-  "version": "3.39.0",
+  "version": "3.39.1",
   "description": "Knowledge Driven Development toolkit",
   "license": "MIT",
   "repository": {