第220章　GoalCapabilityRepository

220.1 GoalCapabilityRepository定义

在前面的 Repository 体系中，已经建立：

IndividualRepository
ObjectRepository
StateRepository
RelationRepository
KnowledgeRepository

这些 Repository 分别负责 Individual、Object、State、Relation、Knowledge 的持久化。

在 ICAI 的认知过程继续向上运行时，需要解决一个直接关系：

Goal
  ↓
需要什么能力？
  ↓
Capability
  ↓
是否匹配？
  ↓
当前是否可用？
  ↓
Method

因此，本章建立：

$GoalCapabilityRepositoryGoalCapabilityRepository$

GoalCapabilityRepository 并不是把 Goal 和 Capability 合并成为一个 Domain Object，而是建立一个面向目标—能力关联数据的 Repository 协作边界。

其核心模型：

$GCR=(G,C,M,S,Q,P,T)GCR=(G,C,M,S,Q,P,T)$

其中：

$GG$ ：Goal，目标；
$CC$ ：Capability，能力；
$MM$ ：Matching，目标与能力之间的匹配数据；
$SS$ ：State，目标和能力的状态；
$QQ$ ：Query，查询；
$PP$ ：Persistence，持久化；
$TT$ ：Time，时间。

因此：

$GoalCapabilityRepository=Goal+Capability+Matching+State Persistence\boxed{ GoalCapabilityRepository = Goal + Capability + Matching + State\ Persistence }$

但必须特别强调：

$GoalCapabilityRepository≠GoalCapability\boxed{ GoalCapabilityRepository \neq GoalCapability }$

它不是创造一个新的“目标能力对象”，而是负责围绕 Goal、Capability、Matching、State 建立持久化查询和关联。

220.2 Goal与Capability的基本关系

Goal 在第175章已经定义：

$G=(ID,N,T,C,P,S)G=(ID,N,T,C,P,S)$

其中：

$IDID$ ：Goal ID；
$NN$ ：Goal Name；
$TT$ ：Goal Type；
$CC$ ：Goal Condition；
$PP$ ：Priority；
$SS$ ：Goal State。

Capability 在第159章和第193章已经定义：

$C=(T,Co,S,R,V)C=(T,Co,S,R,V)$

其中：

$TT$ ：Capability Type；
$CoCo$ ：Capability Condition；
$SS$ ：Capability State；
$RR$ ：Capability Range；
$VV$ ：Verification。

目标提出：

我要达到什么结果？

能力回答：

我能够完成什么？

因此：

$Goal≠CapabilityGoal\neq Capability$

二者之间需要通过 MatchingEngine 建立计算关系：

$Match(G,C,Context)→MMatch(G,C,Context)\rightarrow M$

220.3 GoalCapabilityRepository的职责

本 Repository 协作体系主要处理四类数据：

目标
能力
目标—能力匹配记录
目标—能力相关状态

因此可以形成：

Goal
  ↓
GoalRepository

Capability
  ↓
CapabilityRepository

Goal + Capability
  ↓
MatchingEngine
  ↓
Match Result
  ↓
GoalCapabilityRepository

Repository 主要负责：

第一，目标读取

Goal Load
Goal Query
Goal State Read

第二，能力读取

Capability Load
Capability Query
Capability State Read

第三，匹配记录保存与查询

Goal
 ↓
Capability
 ↓
Match Result

第四，状态相关数据读取

Goal State
Capability State
Match State

220.4 Repository不是匹配计算器

这一点必须明确。

GoalCapabilityRepository 可以保存：

Goal G1
Capability C1
Match M1

但是：

G1 是否真的适合 C1？

不是 Repository 判断。

真正的计算：

$Match(G,C,Context)→MMatch(G,C,Context) \rightarrow M$

由 MatchingEngine 完成。

因此：

$Repository=保存和查询\boxed{ Repository=保存和查询 }$ $MatchingEngine=匹配计算\boxed{ MatchingEngine=匹配计算 }$

220.5 Goal与Capability的匹配模型

目标能力匹配可以定义：

$Mgc=(G,C,O,S,Co,R,V,T)M_{gc}= (G,C,O,S,Co,R,V,T)$

其中：

$GG$ ：Goal；
$CC$ ：Capability；
$OO$ ：适用对象；
$SS$ ：当前状态；
$CoCo$ ：条件；
$RR$ ：能力范围；
$VV$ ：验证状态；
$TT$ ：匹配时间。

基本匹配过程：

Goal
 ↓
Required Capability
 ↓
Load Capability
 ↓
Object Check
 ↓
Condition Check
 ↓
State Check
 ↓
Range Check
 ↓
Verification Check
 ↓
Match Result

220.6 Goal到Capability的查询

Repository 可以根据 Goal 查询候选 Capability。

例如：

$QueryCapabilities(G)→{C1,C2,…,Cn}QueryCapabilities(G) \rightarrow \{C_1,C_2,\ldots,C_n\}$

但这里的“候选”只是持久化层面的候选集合。

它不代表：

$Ci=MatchedC_i=Matched$

完整流程：

Goal
 ↓
GoalCapabilityRepository
 ↓
Capability Candidates
 ↓
MatchingEngine
 ↓
Matching Result

220.7 Capability到Goal的反向查询

同样可以根据 Capability 查询它可能服务的 Goal：

$QueryGoals(C)→{G1,G2,…,Gn}QueryGoals(C) \rightarrow \{G_1,G_2,\ldots,G_n\}$

例如：

Capability:
process_object

↓
Goals:
process_object
inspect_object
transform_object

但是最终适用关系仍需要 MatchingEngine 计算。

220.8 Goal状态

Goal 本身具有生命周期状态：

created
pending
active
paused
blocked
completed
failed
cancelled
expired

因此：

$SG∈{created,pending,active,paused,blocked,completed,failed,cancelled,expired}S_G\in \{ created, pending, active, paused, blocked, completed, failed, cancelled, expired \}$

GoalCapabilityRepository 可以保存和查询 Goal 当前状态。

但状态转换：

$SGt→SGt+1S_{G_t}\rightarrow S_{G_{t+1}}$

应由 StateEngine / UpdateEngine 计算和应用。

220.9 Capability状态

Capability 同样具有状态。

例如：

available
unavailable
blocked
expired
verified
unverified

能力可用性不能简单等同于能力存在。

因此：

$CapabilityExists≠CapabilityAvailableCapabilityExists \neq CapabilityAvailable$

进一步：

$CapabilityAvailable≠CapabilityVerifiedCapabilityAvailable \neq CapabilityVerified$

前面 CapabilityEngine 已经定义：

$CapabilityAvailable=T∧Co∧S∧RCapabilityAvailable = T\land Co\land S\land R$

验证后的能力：

$CapabilityVerified=T∧Co∧S∧R∧VCapabilityVerified = T\land Co\land S\land R\land V$

GoalCapabilityRepository 保存这些状态事实，但不计算它们。

220.10 Goal与Capability状态共同作用

目标是否能够推进，需要同时考虑：

$GoalStateGoalState$

和：

$CapabilityStateCapabilityState$

例如：

Goal = active
Capability = available

可能允许继续匹配。

如果：

Goal = active
Capability = blocked

则：

$Match(G,C)=BlockedMatch(G,C)=Blocked$

如果：

Goal = completed
Capability = available

则当前 Goal 已经不需要继续执行。

因此匹配结果需要保留状态原因。

220.11 匹配结果不是Boolean

不能只保存：

matched = 1

更完整的 Match Result：

$M=(ID,G,C,S,Score,Reason,Ev,T)M= (ID,G,C,S,Score,Reason,Ev,T)$

其中：

$IDID$ ：匹配记录 ID；
$GG$ ：Goal ID；
$CC$ ：Capability ID；
$SS$ ：Match State；
$ScoreScore$ ：匹配计算结果；
$ReasonReason$ ：原因；
$EvEv$ ：Evidence；
$TT$ ：时间。

匹配状态可以包括：

matched
partial
unmatched
unknown
blocked
conflicted
expired
invalid

220.12 GoalCapability匹配计算

一个基础匹配条件可以定义为：

$Matchable=Gv∧Cv∧Ov∧Sv∧Cov∧Rv∧VvMatchable = G_v \land C_v \land O_v \land S_v \land Co_v \land R_v \land V_v$

其中：

$GvG_v$ ：Goal 有效；
$CvC_v$ ：Capability 有效；
$OvO_v$ ：对象匹配；
$SvS_v$ ：状态允许；
$CovCo_v$ ：条件满足；
$RvR_v$ ：能力范围满足；
$VvV_v$ ：验证条件满足。

如果所有条件满足：

$Matchable=1Matchable=1$

否则需要进一步分类原因。

220.13 匹配查询与匹配计算的区别

Repository 可以查询：

Goal G1
Capability C1

但 MatchingEngine 才能计算：

G1 ↔ C1 = matched

因此：

$Query(G,C)≠Match(G,C)Query(G,C) \neq Match(G,C)$

这是 ICAI Repository 与 Engine 分层的重要原则。

220.14 GoalCapabilityRepository接口

可以设计：

<?php

interface GoalCapabilityRepositoryInterface
{
    public function findGoalById($goalId);

    public function findCapabilityById($capabilityId);

    public function findCapabilitiesByGoalId($goalId);

    public function findGoalsByCapabilityId($capabilityId);

    public function findMatchesByGoalId($goalId);

    public function findMatchesByCapabilityId($capabilityId);

    public function findMatch(
        $goalId,
        $capabilityId
    );

    public function saveMatch($match);

    public function updateMatch($match);

    public function findGoalState($goalId);

    public function findCapabilityState($capabilityId);
}

这里的 Goal 和 Capability 实体本身仍然可以由：

GoalRepository
CapabilityRepository

负责持久化。

GoalCapabilityRepository 主要承担二者之间的关联查询和匹配结果持久化。

220.15 GoalCapabilityMapper

匹配数据需要独立 Mapper。

class GoalCapabilityMapper
{
    public function toPersistence($match)
    {
        return array(
            'id' => $match->getId(),
            'goal_id' => $match->getGoalId(),
            'capability_id' => $match->getCapabilityId(),
            'match_state' => $match->getState(),
            'score' => $match->getScore(),
            'reason' => $match->getReason(),
            'evidence' => $match->getEvidence(),
            'matched_at' => $match->getTime()
        );
    }

    public function toDomain($data)
    {
        $match = new GoalCapabilityMatch();

        $match->setId($data['id']);
        $match->setGoalId($data['goal_id']);
        $match->setCapabilityId(
            $data['capability_id']
        );
        $match->setState(
            $data['match_state']
        );
        $match->setScore(
            $data['score']
        );
        $match->setReason(
            $data['reason']
        );
        $match->setEvidence(
            $data['evidence']
        );
        $match->setTime(
            $data['matched_at']
        );

        return $match;
    }
}

Mapper只负责转换数据。

220.16 匹配结果保存

匹配计算完成以后：

Goal
 ↓
Capability
 ↓
MatchingEngine
 ↓
Match Result
 ↓
Verification
 ↓
GoalCapabilityRepository
 ↓
MySQL

保存公式：

$Save(M)→Validate→Map→Persist→VerifySave(M) \rightarrow Validate \rightarrow Map \rightarrow Persist \rightarrow Verify$

这里的 Verify 是匹配记录的持久化验证。

它不取代 MatchingEngine 对匹配结果本身的计算。

220.17 匹配记录更新

匹配关系不是永久不变的。

例如：

Goal G1
Capability C1

matched
   ↓
blocked

或者：

partial
   ↓
matched

因此：

$Mt+ΔM→Mt+1M_t+\Delta M\rightarrow M_{t+1}$

更新流程：

Current Match
      ↓
MatchingEngine
      ↓
New Match Candidate
      ↓
Verification
      ↓
UpdateEngine
      ↓
GoalCapabilityRepository

220.18 为什么匹配状态需要更新

例如 Capability 原来：

available

后来：

blocked

那么原来的：

Goal G1 ↔ Capability C1
matched

可能变成：

Goal G1 ↔ Capability C1
blocked

因此：

$CapabilityStateChange→MatchRecalculationCapabilityStateChange \rightarrow MatchRecalculation$

完整过程：

Capability State Change
       ↓
MatchingEngine
       ↓
Goal-Capability Recalculation
       ↓
Match Update Candidate
       ↓
UpdateEngine
       ↓
Repository

220.19 Goal状态变化引起重新匹配

同样：

$GoalStateChange→MatchRecalculationGoalStateChange \rightarrow MatchRecalculation$

例如：

Goal = active

变成：

Goal = completed

那么：

Goal-Capability Match

可能不再是当前执行候选。

这并不意味着 Capability 被删除。

只是当前匹配关系发生变化。

因此：

$GoalCompleted≠CapabilityInvalidGoalCompleted \neq CapabilityInvalid$

220.20 Capability更新不等于匹配更新

例如 Capability 范围：

0-100

变成：

0-50

这是 Capability 更新：

$Ct+ΔC→Ct+1C_t+\Delta C\rightarrow C_{t+1}$

然后必须重新计算相关 Goal：

Capability Update
       ↓
Affected Goals
       ↓
MatchingEngine
       ↓
Match Recalculation

因此：

$CapabilityUpdate→MatchRecalculationCapabilityUpdate \rightarrow MatchRecalculation$

但：

$CapabilityRepository≠MatchingEngineCapabilityRepository \neq MatchingEngine$

220.21 状态查询

GoalCapabilityRepository 可以提供：

findGoalState()
findCapabilityState()
findMatchState()

例如：

public function findMatch(
    $goalId,
    $capabilityId
) {
    $sql = "
        SELECT *
        FROM goal_capability_matches
        WHERE goal_id = :goal_id
        AND capability_id = :capability_id
        ORDER BY id DESC
        LIMIT 1
    ";

    $stmt = $this->pdo->prepare($sql);

    $stmt->execute(array(
        ':goal_id' => $goalId,
        ':capability_id' => $capabilityId
    ));

    $data = $stmt->fetch(PDO::FETCH_ASSOC);

    if (!$data) {
        return null;
    }

    return $this->mapper->toDomain($data);
}

这里查询的是已经保存的匹配记录。

220.22 匹配记录数据库

可以建立：

CREATE TABLE goal_capability_matches (
    id INT NOT NULL AUTO_INCREMENT,
    goal_id INT NOT NULL,
    capability_id INT NOT NULL,
    match_state VARCHAR(50) NOT NULL,
    score DECIMAL(10,4) DEFAULT NULL,
    reason TEXT,
    evidence TEXT,
    matched_at DATETIME NOT NULL,
    PRIMARY KEY (id)
);

可以进一步建立组合索引：

INDEX idx_goal_capability
(goal_id, capability_id)

INDEX idx_goal
(goal_id)

INDEX idx_capability
(capability_id)

INDEX idx_match_state
(match_state)

这些索引只解决查询效率问题。

$DatabaseIndex≠MatchingLogicDatabaseIndex \neq MatchingLogic$

220.23 GoalCapabilityRepository与GoalRepository

GoalRepository负责：

Goal Save
Goal Load
Goal Update
Goal Delete

GoalCapabilityRepository负责：

Goal ↔ Capability
Match Query
Match Persistence

因此：

$GoalRepository≠GoalCapabilityRepositoryGoalRepository \neq GoalCapabilityRepository$

它们可以协作：

GoalRepository
      ↓
Goal

CapabilityRepository
      ↓
Capability

GoalCapabilityRepository
      ↓
Goal-Capability Match

220.24 GoalCapabilityRepository与CapabilityRepository

同理：

CapabilityRepository
        ↓
Capability Domain Object

而：

GoalCapabilityRepository
        ↓
Goal-Capability Association

因此 Capability 本身的保存仍然属于 CapabilityRepository。

GoalCapabilityRepository 不应该复制 CapabilityRepository 的全部保存逻辑。

220.25 GoalCapabilityRepository与StateRepository

状态属于独立的 State Domain Object。

因此：

Goal
 ↓
StateRepository

Capability
 ↓
StateRepository

GoalCapabilityRepository 可以查询关联状态，但状态正式持久化仍可以由 StateRepository 完成。

因此：

$GoalCapabilityRepository≠StateRepositoryGoalCapabilityRepository \neq StateRepository$

如果系统采用独立 State 表，则完整关系为：

Goal
 ↓
State
 ↓
StateRepository

Capability
 ↓
State
 ↓
StateRepository

220.26 GoalCapabilityRepository与MatchingEngine

完整边界：

GoalRepository
      ↓
Goal

CapabilityRepository
      ↓
Capability

Goal + Capability
      ↓
MatchingEngine
      ↓
Match Result
      ↓
GoalCapabilityRepository

因此：

$MatchingEngine=计算匹配\boxed{ MatchingEngine=计算匹配 }$ $GoalCapabilityRepository=保存和查询匹配数据\boxed{ GoalCapabilityRepository=保存和查询匹配数据 }$

220.27 GoalCapabilityRepository与DecisionEngine

匹配之后可能存在多个 Capability：

Goal G1
 ↓
C1 matched
C2 matched
C3 partial

MatchingEngine 得到：

C1 = matched
C2 = matched
C3 = partial

但最终：

选择 C1 还是 C2？

属于 DecisionEngine。

因此：

$MatchingEngine→Candidates→DecisionEngineMatchingEngine \rightarrow Candidates \rightarrow DecisionEngine$

而不是：

$Repository→DecisionRepository \rightarrow Decision$

220.28 GoalCapability完整计算链

最终形成：

Goal
 ↓
Required Capability
 ↓
CapabilityRepository
 ↓
Capability
 ↓
MatchingEngine
 ↓
Object Check
 ↓
State Check
 ↓
Condition Check
 ↓
Range Check
 ↓
Verification Check
 ↓
Match Result
 ↓
GoalCapabilityRepository
 ↓
DecisionEngine

这条链将：

目标
能力
匹配
状态
决策

连接起来。

220.29 GoalCapability状态闭环

状态变化可以产生重新匹配：

Goal
 ↓
Capability
 ↓
Match
 ↓
State
 ↓
State Change
 ↓
Re-Match
 ↓
New Match

例如：

Capability C1
available
      ↓
blocked
      ↓
MatchingEngine
      ↓
G1-C1
matched
      ↓
blocked

之后 DecisionEngine 可以重新寻找其他 Capability。

220.30 GoalCapability持久化闭环

完整持久化：

Goal
 ↓
GoalRepository
 ↓
MySQL

Capability
 ↓
CapabilityRepository
 ↓
MySQL

Goal + Capability
 ↓
MatchingEngine
 ↓
Match
 ↓
GoalCapabilityRepository
 ↓
MySQL

读取：

MySQL
 ↓
GoalRepository
 ↓
Goal

MySQL
 ↓
CapabilityRepository
 ↓
Capability

MySQL
 ↓
GoalCapabilityRepository
 ↓
Match

220.31 GoalCapability更新原则

目标能力体系必须遵守最小更新原则。

如果只改变 Goal State：

$ΔG=ΔSG\Delta G=\Delta S_G$

如果只改变 Capability State：

$ΔC=ΔSC\Delta C=\Delta S_C$

如果只改变匹配结果：

$ΔM=ΔMstate\Delta M=\Delta M_{state}$

不能因为：

Capability State Changed

就直接重建：

Goal
Capability
Method
Behavior

正确流程：

State Change
 ↓
Affected Match
 ↓
Recalculate
 ↓
Update Match

220.32 GoalCapability数据一致性

Goal、Capability、Match 三者之间需要保持引用一致。

至少满足：

$ValidReference=GoalExists∧CapabilityExistsValidReference = GoalExists \land CapabilityExists$

匹配记录：

$ValidMatchReference=GoalExists∧CapabilityExists∧MatchExistsValidMatchReference = GoalExists \land CapabilityExists \land MatchExists$

如果 Goal 被归档：

Goal
 ↓
archived

相关 Match 不能继续被当成当前有效匹配。

因此：

$GoalState→MatchValidityGoalState \rightarrow MatchValidity$

Capability 同样如此：

$CapabilityState→MatchValidityCapabilityState \rightarrow MatchValidity$

220.33 删除原则

GoalCapabilityRepository 不应该简单地：

DELETE FROM goal_capability_matches

删除所有历史匹配。

因为匹配历史对于：

Decision
Experience
Learning
Diagnosis

可能具有价值。

因此优先：

active
 ↓
inactive
 ↓
archived

而不是无条件物理删除。

原则：

$DeleteMatch≠DeleteGoalDeleteMatch \neq DeleteGoal$ $DeleteMatch≠DeleteCapabilityDeleteMatch \neq DeleteCapability$

220.34 GoalCapability历史

为了支持后续 Learning 和 Experience，可以保存：

goal_capability_history

模型：

$GH=(G,C,Mb,Ma,R,T)GH=(G,C,M_b,M_a,R,T)$

其中：

$GG$ ：Goal；
$CC$ ：Capability；
$MbM_b$ ：更新前匹配；
$MaM_a$ ：更新后匹配；
$RR$ ：变化原因；
$TT$ ：变化时间。

例如：

G1
 ↓
C1
 ↓
matched
 ↓
Capability blocked
 ↓
unmatched

该历史事实可以成为后续经验计算的数据来源。

220.35 GoalCapability与Learning

完整学习路径：

Goal
 ↓
Capability
 ↓
Matching
 ↓
Execution
 ↓
Result
 ↓
Feedback
 ↓
Experience
 ↓
LearningEngine
 ↓
Goal/Capability/Match Update Candidate
 ↓
UpdateEngine
 ↓
Repository

因此学习可以发现：

某类 Goal
通常需要某类 Capability

或者：

某 Capability
在某类条件下无法满足某类 Goal

但是这些变化必须经过验证。

220.36 PHP工程结构

推荐目录：

app/
├── Domain/
│   ├── Goal/
│   │   └── Goal.php
│   ├── Capability/
│   │   └── Capability.php
│   └── GoalCapability/
│       └── GoalCapabilityMatch.php
│
├── Engines/
│   ├── GoalEngine.php
│   ├── CapabilityEngine.php
│   └── MatchingEngine.php
│
├── Repositories/
│   ├── GoalRepository.php
│   ├── CapabilityRepository.php
│   ├── StateRepository.php
│   └── GoalCapabilityRepository.php
│
├── Services/
│   ├── GoalService.php
│   ├── CapabilityService.php
│   └── GoalCapabilityService.php
│
└── Infrastructure/
    ├── Database/
    └── Mapping/

这样可以明确：

Domain
 ↓
Engine
 ↓
Service
 ↓
Repository
 ↓
MySQL

220.37 Service调用关系

实际应用中建议：

GoalCapabilityService
        ↓
GoalRepository
        ↓
CapabilityRepository
        ↓
MatchingEngine
        ↓
GoalCapabilityRepository

如果状态需要更新：

GoalCapabilityService
        ↓
StateService
        ↓
StateEngine
        ↓
UpdateEngine
        ↓
StateRepository

这样可以避免 Repository 自己承担业务编排。

220.38 完整GoalCapability流程

正常路径：

Need
 ↓
Goal
 ↓
GoalRepository
 ↓
Required Capability
 ↓
CapabilityRepository
 ↓
Capability
 ↓
MatchingEngine
 ↓
Goal/Capability/State/Condition/Range
 ↓
Match Result
 ↓
GoalCapabilityRepository
 ↓
DecisionEngine
 ↓
MethodEngine

状态变化路径：

Capability State Change
 ↓
StateEngine
 ↓
UpdateEngine
 ↓
StateRepository
 ↓
MatchingEngine
 ↓
Match Recalculation
 ↓
GoalCapabilityRepository
 ↓
DecisionEngine

220.39 核心公式

目标模型：

$G=(ID,N,T,C,P,S)\boxed{ G=(ID,N,T,C,P,S) }$

能力模型：

$C=(T,Co,S,R,V)\boxed{ C=(T,Co,S,R,V) }$

目标能力匹配：

$Mgc=Match(G,C,O,S,Co,R,V,T)\boxed{ M_{gc}=Match(G,C,O,S,Co,R,V,T) }$

匹配条件：

$Matchable=Gv∧Cv∧Ov∧Sv∧Cov∧Rv∧Vv\boxed{ Matchable = G_v \land C_v \land O_v \land S_v \land Co_v \land R_v \land V_v }$

匹配更新：

$Mt+ΔM→Mt+1\boxed{ M_t+\Delta M\rightarrow M_{t+1} }$

目标更新：

$Gt+ΔG→Gt+1\boxed{ G_t+\Delta G\rightarrow G_{t+1} }$

能力更新：

$Ct+ΔC→Ct+1\boxed{ C_t+\Delta C\rightarrow C_{t+1} }$

状态变化：

$St+ΔS→St+1\boxed{ S_t+\Delta S\rightarrow S_{t+1} }$

220.40 本章核心原则

原则一：Goal与Capability是两个独立Domain Object

$Goal≠CapabilityGoal\neq Capability$

原则二：GoalCapabilityRepository不是新的认知对象

它是围绕 Goal、Capability、Match、State 的持久化协作边界。

原则三：Repository不负责匹配计算

$GoalCapabilityRepository≠MatchingEngineGoalCapabilityRepository \neq MatchingEngine$

原则四：匹配不是Boolean

$Match∈{matched,partial,unmatched,unknown,blocked,conflicted,expired,invalid}Match\in \{ matched, partial, unmatched, unknown, blocked, conflicted, expired, invalid \}$

原则五：能力存在不代表能力可用

$Exists(C)≠Available(C)Exists(C)\neq Available(C)$

原则六：能力可用不代表能力已经验证

$Available(C)≠Verified(C)Available(C)\neq Verified(C)$

原则七：状态变化必须能够影响匹配

$StateChange→ReMatchStateChange \rightarrow ReMatch$

原则八：匹配变化应该能够追溯

$MatchChange→MatchHistoryMatchChange \rightarrow MatchHistory$

原则九：多个匹配候选最终由DecisionEngine处理

$Matching→Candidates→DecisionMatching \rightarrow Candidates \rightarrow Decision$

原则十：Repository不负责决策

$Repository≠DecisionEngineRepository\neq DecisionEngine$

220.41 本章总结

GoalCapabilityRepository 建立了 ICAI 中非常重要的：

$Goal↔Capability\boxed{ Goal \leftrightarrow Capability }$

持久化关联体系。

目标回答：

$Goal=需要达到什么Goal=需要达到什么$

能力回答：

$Capability=能够做什么Capability=能够做什么$

MatchingEngine回答：

$Match=当前能力是否能够满足目标Match=当前能力是否能够满足目标$

State回答：

$State=目标、能力以及匹配当前处于什么状态State=目标、能力以及匹配当前处于什么状态$

Repository回答：

$Repository=这些事实如何保存和查询Repository=这些事实如何保存和查询$

因此最终形成：

Goal
 ↓
GoalRepository
 ↓
Goal

Capability
 ↓
CapabilityRepository
 ↓
Capability

Goal + Capability
 ↓
MatchingEngine
 ↓
Match Result
 ↓
GoalCapabilityRepository
 ↓
MySQL

状态变化：

StateEngine
 ↓
UpdateEngine
 ↓
StateRepository
 ↓
State Change
 ↓
MatchingEngine
 ↓
New Match
 ↓
GoalCapabilityRepository

决策阶段：

Goal
 ↓
Capability Candidates
 ↓
Matching
 ↓
Matched Capabilities
 ↓
DecisionEngine
 ↓
Selected Capability
 ↓
MethodEngine

因此可以最终确定：

$GoalRepository=目标持久化\boxed{ GoalRepository=目标持久化 }$ $CapabilityRepository=能力持久化\boxed{ CapabilityRepository=能力持久化 }$ $MatchingEngine=目标能力匹配计算\boxed{ MatchingEngine=目标能力匹配计算 }$ $StateRepository=状态持久化\boxed{ StateRepository=状态持久化 }$ $GoalCapabilityRepository=目标—能力匹配关联数据的持久化与查询\boxed{ GoalCapabilityRepository=目标—能力匹配关联数据的持久化与查询 }$

最终形成：

$Goal→Capability→Matching→State→Decision\boxed{ Goal \rightarrow Capability \rightarrow Matching \rightarrow State \rightarrow Decision }$

并与前面的认知计算体系连接：

$Need→Goal→Capability→Matching→Method→Decision→Behavior→Action→Execution\boxed{ Need \rightarrow Goal \rightarrow Capability \rightarrow Matching \rightarrow Method \rightarrow Decision \rightarrow Behavior \rightarrow Action \rightarrow Execution }$

GoalCapabilityRepository 因此成为 Goal 从“目标定义”进入“能力可行性判断”，再进入 Method 与 Decision 的持久化连接层。

第220章 GoalCapabilityRepository

第220章 GoalCapabilityRepository

220.1 GoalCapabilityRepository定义

220.2 Goal与Capability的基本关系

220.3 GoalCapabilityRepository的职责

第一，目标读取

第二，能力读取

第三，匹配记录保存与查询

第四，状态相关数据读取

220.4 Repository不是匹配计算器

220.5 Goal与Capability的匹配模型

220.6 Goal到Capability的查询

220.7 Capability到Goal的反向查询

220.8 Goal状态

220.9 Capability状态

220.10 Goal与Capability状态共同作用

220.11 匹配结果不是Boolean

220.12 GoalCapability匹配计算

220.13 匹配查询与匹配计算的区别

220.14 GoalCapabilityRepository接口

220.15 GoalCapabilityMapper

220.16 匹配结果保存

220.17 匹配记录更新

220.18 为什么匹配状态需要更新

220.19 Goal状态变化引起重新匹配

220.20 Capability更新不等于匹配更新

220.21 状态查询

220.22 匹配记录数据库

220.23 GoalCapabilityRepository与GoalRepository

220.24 GoalCapabilityRepository与CapabilityRepository

220.25 GoalCapabilityRepository与StateRepository

220.26 GoalCapabilityRepository与MatchingEngine

220.27 GoalCapabilityRepository与DecisionEngine

220.28 GoalCapability完整计算链

220.29 GoalCapability状态闭环

220.30 GoalCapability持久化闭环

220.31 GoalCapability更新原则

220.32 GoalCapability数据一致性

220.33 删除原则

220.34 GoalCapability历史

220.35 GoalCapability与Learning

220.36 PHP工程结构

220.37 Service调用关系

220.38 完整GoalCapability流程

220.39 核心公式

220.40 本章核心原则

原则一：Goal与Capability是两个独立Domain Object

原则二：GoalCapabilityRepository不是新的认知对象

原则三：Repository不负责匹配计算

原则四：匹配不是Boolean

原则五：能力存在不代表能力可用

原则六：能力可用不代表能力已经验证

原则七：状态变化必须能够影响匹配

原则八：匹配变化应该能够追溯

原则九：多个匹配候选最终由DecisionEngine处理

原则十：Repository不负责决策

220.41 本章总结