- 13:00~18:49 ego: [AI特殊监管区设想](#20250803130000)

- 20:50~21:49	check: [零散笔记](#20250803205000)

PSMD.md

@@ -0,0 +1,67 @@
+## 简要
+PSMD改版
+
+### 模型分类
+* 第一类：能提供产品的最简模型，尽可能保留普通人的行为模式。
+* 第二类：提供产品，并战胜第一类的最简模型。
+* 第三类：不与第一、二类竞争，而是服务于它们、提高它们生存能力。
+
+PSMD为每类提供一种标准模型，鼓励建模者设计行业专用模型。
+
+### 区别对待
+* 鼓励第一类共同体以自己的方式互相帮助。
+* 以团队委托帮助第二类共同体存活。
+* 以个人委托帮助个人占据第三类生态位。
+
+---
+
+## 配套工作
+
+### 模型和部署方案
+PSMD是实践经验的整理、复制、收费的框架。
+
+部署方案的产生：
+* 收集共同体所有内部契约、规章，无论是书面、口头、暗示的；
+* 如果一份文件的效力来自另一份，保留后者、舍弃前者；
+* 剩余文件所定义的角色，作为核心成员；
+* 定义核心成员之间权责的文件，舍弃的重新纳入。
+
+例如：
+1. 《章程》的效力来自公司法。公司法是外部法律，因此《章程》保留。
+1. 《董事会议事规则》的效力来自《章程》，会在第二步舍弃，在第四步重新纳入部署方案。
+
+从部署方案中产生模型：
+* 名称替换为代号（姓名、地名、机构名称）；
+* 数量替换为代号，保留数量的相互关系（比如倍数）；
+* 出现多种可以互相替换、效果相近的操作时，只提取其共性而忽略差异；
+
+PSMD要求公布模型，不要求公布部署方案。
+
+### 资料库与模型库
+PSMD为模型的设计和销售提供容器。
+* 对建模者的辅导从创意开始，直到产生可复制使用的模型。
+* PSMD设计第三类共同体（或个人）为第一、二类共同体提供服务的接口。
+* PSMD设计建模者为部署者的后续服务接口。
+* PSMD设计标准委托的服务接口。
+* 以上接口合并、具体体现为模型的附加条款。
+* 提交模型的，则成为建模者。
+* 使用模型的，则成为部署者。
+
+PSMD整理资料库。  
+不是建模者、部署者的，也可以提问、阅读资料。
+
+### 标准委托
+* 标准委托分为团队委托和个人委托，委托接口已植入模型中。
+* 团队委托：不鼓励升级，只观察内部矛盾的积累程度，告知并定期清理。
+* 行业内未出现第三类共同体时，鼓励个人占据生态位。接受这些人的委托，支持他们创立第三类共同体。
+
+### 关于软件
+PSMD会一直为非程序员提供服务。  
+PSMD自身会逐渐软件化。
+
+### 开放与透明
+* 为未来的、未知的工作难点积极准备，舍弃其它竞争方式。
+* 全部价目和报酬都公开。产品经理以建模者身份提供服务时，同工同酬。
+* 产品经理召集建模者封闭讨论，单独决定服务接口、附加条款、标准模型。
+* 所有模型均提供干净版本（不含附加条款），均采用[署名-非商业性使用-相同方式共享 4.0 国际 (CC BY-NC-SA 4.0)](https://creativecommons.org/licenses/by-nc-sa/4.0/)进行许可。部署者可以免费自用。
+* 部署者主动在模型中加入附加条款，才会接入对应的服务。

README.md

@@ -1,15 +1,15 @@
-##huangyg's Blog
-
-###2015年末总结
-* [加密货币与新产品](bitcoin.md)
-* [共同体](community.md)
-* [冷启动](clodstart.md)
-
-###2016
-* [适应力和资源募集](community.1.md)
-* [时间接口](timeflow.md)
-
-版权声明：
-
-1. 本库作品版权归[黄勇刚](mailto:huangyg@mars22.com)所有。
+##huangyg's Blog
+
+###2015年末总结
+* [加密货币与新产品](bitcoin.md)
+* [共同体](community.md)
+* [冷启动](clodstart.md)
+
+###2016
+* [适应力和资源募集](community.1.md)
+* [时间接口](timeflow.md)
+
+版权声明：
+
+1. 本库作品版权归[黄勇刚](mailto:huangyg@mars22.com)所有。
 2. 本库作品采用<a rel="license" href="http://creativecommons.org/licenses/by-nc-sa/4.0/">署名-非商业性使用-相同方式共享 4.0 国际 (CC BY-NC-SA 4.0)</a>进行许可。  

bitcoin.md

@@ -1,47 +1,47 @@
-##加密货币与新产品
-
-比特币和区块链所触及到的瓶颈，每一个突破之后都比它们本身值钱。由于比特币没有原生的升级功能，每个对策都会产生不兼容的新方案。
-
-###作为支付手段
-和传统支付相比，比特币有很多优点。但是受区块大小限制，比特币的承载力太低，只能作为小范围的支付手段。
-
-由于数据量太大，许多节点选择不全部下载，数据会越来越集中在少数企业手里。
-
-创业者现在设计产品时，嵌入比特币的益处已经越来越小了。
-
-###作为存储方案
-许多舞弊的基础都是篡改数据。提高篡改成本，就能提高整体的诚信度。区块链具有优秀的防篡改能力，这也是它的设计目标。如果把区块链单独作为一个存储平台，在征信这些行业的前景很好。同样，区块链作为存储方案的缺点是数据长度小、存储时间不确定。
-
-把文件的哈希值写入区块链，可以突破数据长度约束，但是需要自己实现扩展协议，这部分很难兼容。
-
-随着使用者增加，存储难度越来越高，更多存储需求会转向衍生方案。新产品规划时可以直接考虑衍生方案。
-
-###交易
-比特币只有发行和支付，而经济活动真正的原子操作是交易。包括和法币的交易，目前也不属于比特币技术协议，而是各交易所自行设计开发。
-
-在比特币之上增加合同，把支付和合同履行过程绑定起来，这一步的意义超过支付本身。
-
-软件交付的主要形式验证码，很容易集成到支付之上。实体物品的交付则需要引入仲裁者，这也会产生额外成本。
-
-新产品规划者应该保持一种基于加密算法、去中心的交付方法。
-
-###企业
-企业由一系列持续的交易构成。它是大部分经济活动的主体。
-
-结合前面提到防篡改、交易，就可以在比特币之上定义企业，并且使这些定义尽可能自动的运行。新模式比传统的工商注册可靠得多，企业运行效率提高，价值也远远超过支付环节的效率提升。
-
-基层企业创造产品，上级企业创造企业。上升到这个层次的创业者，应该每步工作都保留基于加密算法、去中心的企业定义。
-
-###升级
-比特币无中心的设计可以有效避免被少数人把持，但它缺少无中心的升级机制。由少数核心开发者或基金会推动的升级，是有中心的，依然很容易被少数人把持，成为整个方案的薄弱环节。
-
-无中心的升级很难避免分裂，但是要保证分裂后的币种可以交易。而且与普通货物交易机制不同，才能防止投机。
-
-加密货币、无中心存储、交易、企业都需要无中心的升级方案，这个突破决定整体的活力。
-
-
-
-###小结
-加密货币出现的背景是法币发行机制不够透明。它打开一扇窗，但并没有能走出多远。作为支付手段的应用不会太广，但它为无中心的交易、企业提供了关键的技术思路，这是它真正的历史意义。
-
+##加密货币与新产品
+
+比特币和区块链所触及到的瓶颈，每一个突破之后都比它们本身值钱。由于比特币没有原生的升级功能，每个对策都会产生不兼容的新方案。
+
+###作为支付手段
+和传统支付相比，比特币有很多优点。但是受区块大小限制，比特币的承载力太低，只能作为小范围的支付手段。
+
+由于数据量太大，许多节点选择不全部下载，数据会越来越集中在少数企业手里。
+
+创业者现在设计产品时，嵌入比特币的益处已经越来越小了。
+
+###作为存储方案
+许多舞弊的基础都是篡改数据。提高篡改成本，就能提高整体的诚信度。区块链具有优秀的防篡改能力，这也是它的设计目标。如果把区块链单独作为一个存储平台，在征信这些行业的前景很好。同样，区块链作为存储方案的缺点是数据长度小、存储时间不确定。
+
+把文件的哈希值写入区块链，可以突破数据长度约束，但是需要自己实现扩展协议，这部分很难兼容。
+
+随着使用者增加，存储难度越来越高，更多存储需求会转向衍生方案。新产品规划时可以直接考虑衍生方案。
+
+###交易
+比特币只有发行和支付，而经济活动真正的原子操作是交易。包括和法币的交易，目前也不属于比特币技术协议，而是各交易所自行设计开发。
+
+在比特币之上增加合同，把支付和合同履行过程绑定起来，这一步的意义超过支付本身。
+
+软件交付的主要形式验证码，很容易集成到支付之上。实体物品的交付则需要引入仲裁者，这也会产生额外成本。
+
+新产品规划者应该保持一种基于加密算法、去中心的交付方法。
+
+###企业
+企业由一系列持续的交易构成。它是大部分经济活动的主体。
+
+结合前面提到防篡改、交易，就可以在比特币之上定义企业，并且使这些定义尽可能自动的运行。新模式比传统的工商注册可靠得多，企业运行效率提高，价值也远远超过支付环节的效率提升。
+
+基层企业创造产品，上级企业创造企业。上升到这个层次的创业者，应该每步工作都保留基于加密算法、去中心的企业定义。
+
+###升级
+比特币无中心的设计可以有效避免被少数人把持，但它缺少无中心的升级机制。由少数核心开发者或基金会推动的升级，是有中心的，依然很容易被少数人把持，成为整个方案的薄弱环节。
+
+无中心的升级很难避免分裂，但是要保证分裂后的币种可以交易。而且与普通货物交易机制不同，才能防止投机。
+
+加密货币、无中心存储、交易、企业都需要无中心的升级方案，这个突破决定整体的活力。
+
+
+
+###小结
+加密货币出现的背景是法币发行机制不够透明。它打开一扇窗，但并没有能走出多远。作为支付手段的应用不会太广，但它为无中心的交易、企业提供了关键的技术思路，这是它真正的历史意义。
+
 一旦无中心的企业诞生，加密货币（以及无中心软件们）就得到了一个新的发展基点。那里才会有新一代的货币。

changepassphrase.md

@@ -1,27 +1,27 @@
-##更新密钥
-密钥托管 设计笔记
-
-服务器以HTTP接口提供密钥托管服务，其中PUT方法是更新密钥，通常用于修改口令。维护状态会引入额外的复杂性，因此希望是一次性的调用。
-
-浏览器通过GET方法获得加密的密钥，然后用户输入口令，在浏览器直接加盐取哈希解密。这时候，规定一段特定内容作为验证码，用户对验证码进行数字签名，与更新的密钥PUT给服务器。我们需要讨论的是这个验证码的设计。
-
-我们必须假设网络通信是：
-
-* 可以监听的：攻击者可以获得这特定内容及其数字签名。
-* 可以截断的：服务器和浏览器发给对方的内容，接收方不能收到。
-* 可以篡改的：服务器和浏览器发给对方的内容，接收前会被改变。
-
-假设监听是永久的，攻击者不能永久地截断和篡改。在这种情况下，攻击者无法通过更新密钥伪造用户的数字签名。
-
-一次性的调用，要求这验证码是无需协商的，浏览器端就可以生成，而服务器端可以验证。如果接受任意内容作为验证码，用户在日常使用中提供的数字签名，会被攻击者用作验证码去更换密钥。
-
-在简单对比各种选择后，以整个新密钥（yaml结构）作为验证码是目前最佳方案。
-
-* name
-* id
-* email
-* salt：盐
-* pubkey：公钥
-* secpey：私钥
-
+##更新密钥
+密钥托管 设计笔记
+
+服务器以HTTP接口提供密钥托管服务，其中PUT方法是更新密钥，通常用于修改口令。维护状态会引入额外的复杂性，因此希望是一次性的调用。
+
+浏览器通过GET方法获得加密的密钥，然后用户输入口令，在浏览器直接加盐取哈希解密。这时候，规定一段特定内容作为验证码，用户对验证码进行数字签名，与更新的密钥PUT给服务器。我们需要讨论的是这个验证码的设计。
+
+我们必须假设网络通信是：
+
+* 可以监听的：攻击者可以获得这特定内容及其数字签名。
+* 可以截断的：服务器和浏览器发给对方的内容，接收方不能收到。
+* 可以篡改的：服务器和浏览器发给对方的内容，接收前会被改变。
+
+假设监听是永久的，攻击者不能永久地截断和篡改。在这种情况下，攻击者无法通过更新密钥伪造用户的数字签名。
+
+一次性的调用，要求这验证码是无需协商的，浏览器端就可以生成，而服务器端可以验证。如果接受任意内容作为验证码，用户在日常使用中提供的数字签名，会被攻击者用作验证码去更换密钥。
+
+在简单对比各种选择后，以整个新密钥（yaml结构）作为验证码是目前最佳方案。
+
+* name
+* id
+* email
+* salt：盐
+* pubkey：公钥
+* secpey：私钥
+
 首先，它是服务器和用户浏览器无需额外通信就可以达成一致的。其次，日常应用不会对同类数据进行数字签名，攻击者无从提前准备。如果攻击者获得更新信息并截断通信，也无法伪造另一套密钥发给服务器。一旦用户重新与服务器联通，可以再次发送正确的更新信息，攻击者除了截断通信外没有获得额外好处。

community.1.md

@@ -1,72 +1,72 @@
-##共同体
-适应力和资源募集
-
-共同体需要不断重组以适应外界变化。常见的安排是两层机制：决策机构制定基本管理制度、发布决议，执行团队制定具体规章、下达指令。具体规章、执行指令不得违反基本管理制度、决议，从而在获得适应力的同时，也防止执行团队舞弊。
-
-![员工行为模型](order.png)
-
-募集资源有许多方式：以现有资源交换的成本较高，以权力交换的风险较高，而以未来收入换取资源则没有这些缺点，但资源投入方的未兑现利益需要强有力的保护，尤其不能在重组时被牺牲。
-
-![资源募集](collect.png)
-
-###规章的修订
-一般来说，员工依赖五类信息决定自己的行为：
-
-* 历史经验（个人经验或非正式的指导）
-* 直接指令
-* 具体规章
-* 决策部门决议
-* 基本管理制度
-
-它们需要不断修订以适应外界情况，消除内部矛盾。
-
-只要在五种信息互相矛盾时成员清楚怎么应对，零规章起步是可以实现的。部署初期可以完全通过指令管理，执行团队不定期整理记录，把重复性的指令整理为具体规章。当执行团队由于能力或利益局限出现偏差，决策部门颁布决议和基本管理制度。一开始整理周期比较频密，稳定后可以逐渐拉长，在外界条件急剧变化时可以再次提高频率。
-
-产品和服务是很容易参考（抄袭）的，规章的修订能力则较难复制。优秀的产品经理可以带来一定的独占期，优秀的决策部门则意味着持续的竞争优势。独占是无法持久的，竞争中获胜才是赢家。
-
-决策者和其他成员一样，在计时模式下松懈、保守，在考核数量和质量时勇于拼搏。要组建优秀的决策部门，建模者应该设立明确的结果验收和大幅度的奖惩。良性竞争的决策部门、明确指令优先级的成员，可以纯指令、零规章启动，逐步建立竞争优势。
-
-###常见的募集方法
-以未来收入换取资源的难点在于控制（分配前的）支出。要保障资源投入方的未兑现利益，这些支出应控制在经营必须的水平上。控制方法有两种：把权力直接交给资源投入方；或设计一种难以违反的预算制度。两种方法都可能削弱竞争力，资源投入方的决策质量低下，预算制度缺乏弹性。
-
-公司以股份募集资源，它是滞后利益与权力相结合的产物。相应的，缺乏判断力的股东是公司的最大隐患。合伙企业、合作社企业的权力归合伙人、社员，他们以高度透明的规章保障资源投入方的利益，而力图保留权力。在技术密集型的公司里，智力投入者通常控制大部分股份，它们接近于合伙企业 -- 需要以高质量的规章换取资金等资源投入。
-
-当国内法（包括企业法规、会计制度...）所能保障的最高透明度仍然不能满足需要，共同体需要设计更高标准的规章，否则资源拥有者会要求优先兑现。优先级最高时就是从收入直接兑现，前面不安排任何支出，因而也不需要参与支出控制。
-
-收支数额的核实也有许多种情况，数据公布的人员范围有：
-
-* 全面开放，从内部成员、资源投入方到竞争对手，均可查阅。
-* 只对未兑现利益的资源投入方开放，除了“未兑现利益”外不设置额外条件。
-* 介于以上两个极端之间，核实者范围越大，执行团队舞弊难度越高。
-
-发布方式：
-
-* 收支发生时发布数额
-* 滞后发布数额：收支发生时发布数字摘要，滞后一定时间发布详细数据
-
-如果规则清晰到各方独立计算、结果严格一致，而且执行环节不受任何一方控制，可以用公布规则代替公布支出数额。这时，规章设计与收支核实是一体的。同样有两种实现方法：
-
-* 规则制定后发布内容
-* 滞后发布：规则制定后发布数字摘要，失效后发布详细内容
-
-以上提及的发布方式，应该是共同体所无法删改的。至少是删改成本高于资源投入方未兑现利益的。
-另外，把监事和财务人员的人事权交给资源投入方也是常见的安排。
-
-###两种能力的矛盾
-规章除了组织协作以外也要规定分配。规章修订就意味着分配规则的变化。  
-而资源募集需要保障资源投入方的未兑现利益。
-
-平衡这两种能力的矛盾是建模者的核心工作之一。
-
-资金密集型公司通常牺牲适应力换取资源。技术密集型公司、合伙企业、合作社企业如果拥有优秀的决策部门，可以优越的制度吸引资源，保障资源投入方而不丧失权力；否则并没有优势。
-
-一些更新颖的做法，实质上是以决策层管理模型作为募集主体：
-
-* 决策部门公开招募、择优录用、严格淘汰，其人力资源纳入统一的资源募集接口；
-* 包括执行团队在内的所有利益回报纳入统一利益分配规则，逐步兑现；
-
-既不以现有资源换取资源，也不以权力换取资源，仅仅按照能力聘任决策者。而决策部门、执行部门的利益与资源投入者使用统一的分配规则，不能分割因而难以单方面违约。这样的机制才能同时保证两种能力优势。 
-
-![平衡模型](1406+.png)
-
+##共同体
+适应力和资源募集
+
+共同体需要不断重组以适应外界变化。常见的安排是两层机制：决策机构制定基本管理制度、发布决议，执行团队制定具体规章、下达指令。具体规章、执行指令不得违反基本管理制度、决议，从而在获得适应力的同时，也防止执行团队舞弊。
+
+![员工行为模型](order.png)
+
+募集资源有许多方式：以现有资源交换的成本较高，以权力交换的风险较高，而以未来收入换取资源则没有这些缺点，但资源投入方的未兑现利益需要强有力的保护，尤其不能在重组时被牺牲。
+
+![资源募集](collect.png)
+
+###规章的修订
+一般来说，员工依赖五类信息决定自己的行为：
+
+* 历史经验（个人经验或非正式的指导）
+* 直接指令
+* 具体规章
+* 决策部门决议
+* 基本管理制度
+
+它们需要不断修订以适应外界情况，消除内部矛盾。
+
+只要在五种信息互相矛盾时成员清楚怎么应对，零规章起步是可以实现的。部署初期可以完全通过指令管理，执行团队不定期整理记录，把重复性的指令整理为具体规章。当执行团队由于能力或利益局限出现偏差，决策部门颁布决议和基本管理制度。一开始整理周期比较频密，稳定后可以逐渐拉长，在外界条件急剧变化时可以再次提高频率。
+
+产品和服务是很容易参考（抄袭）的，规章的修订能力则较难复制。优秀的产品经理可以带来一定的独占期，优秀的决策部门则意味着持续的竞争优势。独占是无法持久的，竞争中获胜才是赢家。
+
+决策者和其他成员一样，在计时模式下松懈、保守，在考核数量和质量时勇于拼搏。要组建优秀的决策部门，建模者应该设立明确的结果验收和大幅度的奖惩。良性竞争的决策部门、明确指令优先级的成员，可以纯指令、零规章启动，逐步建立竞争优势。
+
+###常见的募集方法
+以未来收入换取资源的难点在于控制（分配前的）支出。要保障资源投入方的未兑现利益，这些支出应控制在经营必须的水平上。控制方法有两种：把权力直接交给资源投入方；或设计一种难以违反的预算制度。两种方法都可能削弱竞争力，资源投入方的决策质量低下，预算制度缺乏弹性。
+
+公司以股份募集资源，它是滞后利益与权力相结合的产物。相应的，缺乏判断力的股东是公司的最大隐患。合伙企业、合作社企业的权力归合伙人、社员，他们以高度透明的规章保障资源投入方的利益，而力图保留权力。在技术密集型的公司里，智力投入者通常控制大部分股份，它们接近于合伙企业 -- 需要以高质量的规章换取资金等资源投入。
+
+当国内法（包括企业法规、会计制度...）所能保障的最高透明度仍然不能满足需要，共同体需要设计更高标准的规章，否则资源拥有者会要求优先兑现。优先级最高时就是从收入直接兑现，前面不安排任何支出，因而也不需要参与支出控制。
+
+收支数额的核实也有许多种情况，数据公布的人员范围有：
+
+* 全面开放，从内部成员、资源投入方到竞争对手，均可查阅。
+* 只对未兑现利益的资源投入方开放，除了“未兑现利益”外不设置额外条件。
+* 介于以上两个极端之间，核实者范围越大，执行团队舞弊难度越高。
+
+发布方式：
+
+* 收支发生时发布数额
+* 滞后发布数额：收支发生时发布数字摘要，滞后一定时间发布详细数据
+
+如果规则清晰到各方独立计算、结果严格一致，而且执行环节不受任何一方控制，可以用公布规则代替公布支出数额。这时，规章设计与收支核实是一体的。同样有两种实现方法：
+
+* 规则制定后发布内容
+* 滞后发布：规则制定后发布数字摘要，失效后发布详细内容
+
+以上提及的发布方式，应该是共同体所无法删改的。至少是删改成本高于资源投入方未兑现利益的。
+另外，把监事和财务人员的人事权交给资源投入方也是常见的安排。
+
+###两种能力的矛盾
+规章除了组织协作以外也要规定分配。规章修订就意味着分配规则的变化。  
+而资源募集需要保障资源投入方的未兑现利益。
+
+平衡这两种能力的矛盾是建模者的核心工作之一。
+
+资金密集型公司通常牺牲适应力换取资源。技术密集型公司、合伙企业、合作社企业如果拥有优秀的决策部门，可以优越的制度吸引资源，保障资源投入方而不丧失权力；否则并没有优势。
+
+一些更新颖的做法，实质上是以决策层管理模型作为募集主体：
+
+* 决策部门公开招募、择优录用、严格淘汰，其人力资源纳入统一的资源募集接口；
+* 包括执行团队在内的所有利益回报纳入统一利益分配规则，逐步兑现；
+
+既不以现有资源换取资源，也不以权力换取资源，仅仅按照能力聘任决策者。而决策部门、执行部门的利益与资源投入者使用统一的分配规则，不能分割因而难以单方面违约。这样的机制才能同时保证两种能力优势。 
+
+![平衡模型](1406+.png)
+
 这些做法需要新的基础设施，国内法及行政管理很难表达这些模型。

community.md

@@ -1,57 +1,57 @@
-##共同体
-建模和部署
-
-大部分创业者创立企业，也有少数的创立非盈利组织。此外还有许多协作形式，严谨起见这里统称为“共同体”。它们有不少共通之处，所以一并讨论。
-
-###指令->规章
-共同体成员依据什么协作？主要有两种依据：
-
-1. 规章：事前分发好的规章，规定了什么情况下采取什么行动。
-2. 指令：由指定的上级发出指令。严格说，定义上下级关系也是规章的一部分。
-
-显然，指令的质量更低、成本更高、隐患更多。但规章永远不可能尽善尽美，凡是规章没有考虑到的情形，还是需要由人工指令推动。
-
-管理团队的一项重要工作，就是把指令转化为规章，以提高共同体运行的质量、降低成本、减少隐患，当然这是滞后一段时间的。这个指令转化为规章的过程，往往决定共同体存亡。因为产品领先是暂时的，对手可以抄袭模仿，但经营这个产品的效率，决定谁能笑到最后。一个有经验的管理团队，只有看到规章对产品的支撑优于于对手，才能安睡。
-
-创业者的一项重要工作，就是规定管理团队以什么时间间隔、按什么质量要求，完成[指令->规章]这项关键任务。并且设定合理的检查和奖惩，迫使他们认真对待。一个有经验的创业者，只有看到己方的[指令->规章]能力领先于对手，才能安睡。
-
-这些规定有多种载体，可以写在章程备案到政府部门，可以写成多方合同各执一份，还可以写成源代码...我们把其中的关键结构提取出来，建立数学模型，就可以研究它们的本质。
-
-###评价标准
-我们拿到一个共同体的数学模型，怎么评价它的性能呢？
-
-我常用三个标准，照见一个共同体模型的质量：
-
-1. 运行中有哪些人工裁量环节，列出来，由重到轻（到无）大致排序，从核心到外围的监督和奖惩力度应该是递降坡度。
-2. 权利分配的自适应能力：
-	1. 职权能够跟随能力、承诺变化而不断调整；
-	2. 利益能够根据贡献变化不断调整。
-3. 滞后兑现的利益，都安排了有效的保护措施。
-
-不认可这些标准的人很少。但在工作中真正使用这些标准的人，也很少。
-
-比如很多新手抱怨：“贡献根本不可能量化”。其实他们只要发工资，就已经量化了。因为工资就是一个量化的数字，不给数字出纳没法执行。按月发固定工资永远不变，也量化了。不定期由老板发不定量的红包，也是个量化过程。他们不是没有量化，是量化的质量差，是改进的过程被阻断了。
-
-要提升质量，当然就要明确模型，接受质量评价，然后接受更优的方案（即使不是最优）。很多创业者在明确模型这一步都停下来了，然后以改进方案不是最优为由，停在原地。结果就是这个共同体只有外围在运行，核心停转。很多创业者以为只要做出一个产品就赢了，其实就是这种状况。
-
-其实只要时不时拿出这些标准，照一下。就知道共同体的核心人员，做了多少工作，又漏了多少工作。
-
-再拿这个标准向外照一照，就能判断其它共同体，最终能做到什么位置。就像生物学家看一副骨骼化石，就能判定生物的生态位。
-
-###生态位
-用这标准看看常见的企业种类，最低级是股份制的公司，好一点的是合伙企业，再好一点是合作社企业。而它们都已经不能适应现在的工作需要。
-
-大量的人才被压抑在低质量的模型中，专业能力在职业生涯的前段就达到了巅峰，再也无法提升。
-
-从历史可以看出，由国家主导的企业种类研发，原创是以百年为周期的，模仿也需要十年数量级。一旦研发成功，就会立法并下达工商执行，这些企业可以在银行开设对公账户。创业者借助这些框架，大大降低了建模的难度。
-
-而民间可以用多方合同创造新的合作模型，要素完整的话也可以运行得很好。因为不使用国家的研发成果、配套服务，还可以不交企业所得税。但普通人受知识和精力所限，很难完成真正的原创。
-
-异军突起的是程序员。他们具备数学建模的基础知识，而工作结果在设备中高速运行检验，无疑是一种严格的训练。如果只是在数学模型层次看，不知不觉之间，程序员们实际上已经拥有了超过国家的制度研发能力。他们缺少的，是把模型部署的知识。
-
-一旦程序员们学会怎么部署一个共同体，这个群体将以月的周期不断产生原创模型。而且他们部署的共同体将占据生态系统的顶部，因为它们的模型质量远远超过非程序员所能设计的，事实上是后者无法理解的。
-
-这场生态危机怎么发动、怎么进行，我要在其中完成什么使命。这是顶级程序员目前正在思考的问题，而其中一些人的行动已经开始。
-
-###部署
-程序员们可以量产共同体的数学模型，而这些模型的部署就是风口。
+##共同体
+建模和部署
+
+大部分创业者创立企业，也有少数的创立非盈利组织。此外还有许多协作形式，严谨起见这里统称为“共同体”。它们有不少共通之处，所以一并讨论。
+
+###指令->规章
+共同体成员依据什么协作？主要有两种依据：
+
+1. 规章：事前分发好的规章，规定了什么情况下采取什么行动。
+2. 指令：由指定的上级发出指令。严格说，定义上下级关系也是规章的一部分。
+
+显然，指令的质量更低、成本更高、隐患更多。但规章永远不可能尽善尽美，凡是规章没有考虑到的情形，还是需要由人工指令推动。
+
+管理团队的一项重要工作，就是把指令转化为规章，以提高共同体运行的质量、降低成本、减少隐患，当然这是滞后一段时间的。这个指令转化为规章的过程，往往决定共同体存亡。因为产品领先是暂时的，对手可以抄袭模仿，但经营这个产品的效率，决定谁能笑到最后。一个有经验的管理团队，只有看到规章对产品的支撑优于于对手，才能安睡。
+
+创业者的一项重要工作，就是规定管理团队以什么时间间隔、按什么质量要求，完成[指令->规章]这项关键任务。并且设定合理的检查和奖惩，迫使他们认真对待。一个有经验的创业者，只有看到己方的[指令->规章]能力领先于对手，才能安睡。
+
+这些规定有多种载体，可以写在章程备案到政府部门，可以写成多方合同各执一份，还可以写成源代码...我们把其中的关键结构提取出来，建立数学模型，就可以研究它们的本质。
+
+###评价标准
+我们拿到一个共同体的数学模型，怎么评价它的性能呢？
+
+我常用三个标准，照见一个共同体模型的质量：
+
+1. 运行中有哪些人工裁量环节，列出来，由重到轻（到无）大致排序，从核心到外围的监督和奖惩力度应该是递降坡度。
+2. 权利分配的自适应能力：
+	1. 职权能够跟随能力、承诺变化而不断调整；
+	2. 利益能够根据贡献变化不断调整。
+3. 滞后兑现的利益，都安排了有效的保护措施。
+
+不认可这些标准的人很少。但在工作中真正使用这些标准的人，也很少。
+
+比如很多新手抱怨：“贡献根本不可能量化”。其实他们只要发工资，就已经量化了。因为工资就是一个量化的数字，不给数字出纳没法执行。按月发固定工资永远不变，也量化了。不定期由老板发不定量的红包，也是个量化过程。他们不是没有量化，是量化的质量差，是改进的过程被阻断了。
+
+要提升质量，当然就要明确模型，接受质量评价，然后接受更优的方案（即使不是最优）。很多创业者在明确模型这一步都停下来了，然后以改进方案不是最优为由，停在原地。结果就是这个共同体只有外围在运行，核心停转。很多创业者以为只要做出一个产品就赢了，其实就是这种状况。
+
+其实只要时不时拿出这些标准，照一下。就知道共同体的核心人员，做了多少工作，又漏了多少工作。
+
+再拿这个标准向外照一照，就能判断其它共同体，最终能做到什么位置。就像生物学家看一副骨骼化石，就能判定生物的生态位。
+
+###生态位
+用这标准看看常见的企业种类，最低级是股份制的公司，好一点的是合伙企业，再好一点是合作社企业。而它们都已经不能适应现在的工作需要。
+
+大量的人才被压抑在低质量的模型中，专业能力在职业生涯的前段就达到了巅峰，再也无法提升。
+
+从历史可以看出，由国家主导的企业种类研发，原创是以百年为周期的，模仿也需要十年数量级。一旦研发成功，就会立法并下达工商执行，这些企业可以在银行开设对公账户。创业者借助这些框架，大大降低了建模的难度。
+
+而民间可以用多方合同创造新的合作模型，要素完整的话也可以运行得很好。因为不使用国家的研发成果、配套服务，还可以不交企业所得税。但普通人受知识和精力所限，很难完成真正的原创。
+
+异军突起的是程序员。他们具备数学建模的基础知识，而工作结果在设备中高速运行检验，无疑是一种严格的训练。如果只是在数学模型层次看，不知不觉之间，程序员们实际上已经拥有了超过国家的制度研发能力。他们缺少的，是把模型部署的知识。
+
+一旦程序员们学会怎么部署一个共同体，这个群体将以月的周期不断产生原创模型。而且他们部署的共同体将占据生态系统的顶部，因为它们的模型质量远远超过非程序员所能设计的，事实上是后者无法理解的。
+
+这场生态危机怎么发动、怎么进行，我要在其中完成什么使命。这是顶级程序员目前正在思考的问题，而其中一些人的行动已经开始。
+
+###部署
+程序员们可以量产共同体的数学模型，而这些模型的部署就是风口。

edu/“中学生学习时间分配”网络调研.2.20070718.111848.md

@@ -1,18 +1,18 @@
-http://blog.sina.com.cn/s/blog_591ac304010009nu.html
-
-“中学生学习时间分配”网络调研【二】 (2007-07-18 11:18:48)
-
- 调研的入口地址是：http://www.my3q.com/go.php?url=mars22/xuemen
- 
-  下面是最新的几项统计结果：
-   一、在课堂上进度、深度适中的时间比例为：44.67%（过快过难：17.47%，过慢过浅：37.86%）
-   二、在作业中难度适中的题目比例平均为：38.34%（过难：22.73%，过易：38.93）
-   三、在考试中平均有26.13%的分数是努力争取的关键（过难而放弃努力：15.87%，过易且肯定拿分：58%）
-   四、有60%的同学的学习资料根本看不完，提升成绩的障碍主要是资料以外问题。
-   五、有53.3%的同学一直大量做题，但考试时看到碰过的题还是容易丢分。
-   六、有53.8%的同学在考场检查时无法缩小重点范围，浪费了宝贵的时间。
- 
-   可以看到全班统一的课堂和课后作业，往往难以保证每个孩子的“吸收率”。而家庭安排的学习虽然内容丰盛，但是效果不佳，孩子最需要熟练的关键点（每人不同）得不到重点关照。部分最优秀的学生有能力排查划定自己的关键知识点，大部分同学还是采用“漫灌式”的练习模式，造成效率低下。
-   由于难以改变学校教学安排，合理的方法是提升家庭学习中的有效率，使学习内容、深度符合孩子特定需要。家庭教育内容的有效比例完全可以提升到80%以上，只留出少量时间攻克重点困难，温习已牢固的内容。
- 
-   学门科技在暑假中继续进行教育实验，欢迎更多的家长、同学、老师参与，一起体验“高吸收率”的“按需教育”。
+http://blog.sina.com.cn/s/blog_591ac304010009nu.html
+
+“中学生学习时间分配”网络调研【二】 (2007-07-18 11:18:48)
+
+ 调研的入口地址是：http://www.my3q.com/go.php?url=mars22/xuemen
+ 
+  下面是最新的几项统计结果：
+   一、在课堂上进度、深度适中的时间比例为：44.67%（过快过难：17.47%，过慢过浅：37.86%）
+   二、在作业中难度适中的题目比例平均为：38.34%（过难：22.73%，过易：38.93）
+   三、在考试中平均有26.13%的分数是努力争取的关键（过难而放弃努力：15.87%，过易且肯定拿分：58%）
+   四、有60%的同学的学习资料根本看不完，提升成绩的障碍主要是资料以外问题。
+   五、有53.3%的同学一直大量做题，但考试时看到碰过的题还是容易丢分。
+   六、有53.8%的同学在考场检查时无法缩小重点范围，浪费了宝贵的时间。
+ 
+   可以看到全班统一的课堂和课后作业，往往难以保证每个孩子的“吸收率”。而家庭安排的学习虽然内容丰盛，但是效果不佳，孩子最需要熟练的关键点（每人不同）得不到重点关照。部分最优秀的学生有能力排查划定自己的关键知识点，大部分同学还是采用“漫灌式”的练习模式，造成效率低下。
+   由于难以改变学校教学安排，合理的方法是提升家庭学习中的有效率，使学习内容、深度符合孩子特定需要。家庭教育内容的有效比例完全可以提升到80%以上，只留出少量时间攻克重点困难，温习已牢固的内容。
+ 
+   学门科技在暑假中继续进行教育实验，欢迎更多的家长、同学、老师参与，一起体验“高吸收率”的“按需教育”。

edu/“中学生学习时间分配”网络调研.20070715.154427.md

@@ -1,18 +1,18 @@
-http://blog.sina.com.cn/s/blog_591ac304010009mt.html
-
-“中学生学习时间分配”网络调研 (2007-07-15 15:44:27)
-
-  大家好，我们正在进行一项调研，主题是：“中学生学习时间分配”，欢迎广大家长和同学参加。学门科技将为参与调研的同学定制学习规划，帮助同学在不增加学习时间的前提下改善学习效果。
- 
-  调研的入口地址是：http://www.my3q.com/go.php?url=mars22/xuemen
- 
-  下面是目前数据的几项统计结果：
-   在课堂上进度、深度适中的时间比例为：49.82%（过快过难：17.45%，过慢过浅：32.73%）
-   在作业中难度适中的题目比例平均为：43.73%（过难：21.82%，过易：34.45）
-   在考试中平均有27.91%的分数是努力争取的关键（过难而放弃努力：15.73%，过易且肯定拿分：56.36%）
- 
-   换句话说，统一的课堂和课后作业对特定学生而言，有一半以上是低效率的，如果为每位同学定制学习计划，增加难度、内容适合他的内容，学习效果有很大的提升潜力。
-   根据五六月份的实践结果，一名有经验的老教师仅仅根据同学的作业本和考卷划定他的复习重点，准确度可以达到65~75%。
-   根据最近两届eokdd教育测评比赛的结果看，自动软件对学生知识漏洞的判断准确度达到85%以上，最高（千人组）数据包的准确度达到97%。
- 
+http://blog.sina.com.cn/s/blog_591ac304010009mt.html
+
+“中学生学习时间分配”网络调研 (2007-07-15 15:44:27)
+
+  大家好，我们正在进行一项调研，主题是：“中学生学习时间分配”，欢迎广大家长和同学参加。学门科技将为参与调研的同学定制学习规划，帮助同学在不增加学习时间的前提下改善学习效果。
+ 
+  调研的入口地址是：http://www.my3q.com/go.php?url=mars22/xuemen
+ 
+  下面是目前数据的几项统计结果：
+   在课堂上进度、深度适中的时间比例为：49.82%（过快过难：17.45%，过慢过浅：32.73%）
+   在作业中难度适中的题目比例平均为：43.73%（过难：21.82%，过易：34.45）
+   在考试中平均有27.91%的分数是努力争取的关键（过难而放弃努力：15.73%，过易且肯定拿分：56.36%）
+ 
+   换句话说，统一的课堂和课后作业对特定学生而言，有一半以上是低效率的，如果为每位同学定制学习计划，增加难度、内容适合他的内容，学习效果有很大的提升潜力。
+   根据五六月份的实践结果，一名有经验的老教师仅仅根据同学的作业本和考卷划定他的复习重点，准确度可以达到65~75%。
+   根据最近两届eokdd教育测评比赛的结果看，自动软件对学生知识漏洞的判断准确度达到85%以上，最高（千人组）数据包的准确度达到97%。
+ 
    可见无论通过教师，还是通过软件，都可以有效地提高学习计划的效率，使学习时间聚焦在学生最需要的内容上。

edu/“中学生学习时间分配”网络调研.3.20070730.201425.md

@@ -1,16 +1,16 @@
-http://blog.sina.com.cn/s/blog_591ac304010009v8.html
-
-“中学生学习时间分配”网络调研【三】 (2007-07-30 20:14:25)
-
- 调研的入口地址是：http://www.my3q.com/go.php?url=mars22/xuemen
-
-调研结果：
-22.80%--在课堂上进度过快，或者深度过深的时间
-42.61%--在课堂上进度过慢，或者深度过浅的时间
-31.04%--在作业中难度过高的的题目占做题时间 
-41.83%--在作业中难度过低的的题目占做题时间
-课堂上进度深度适中时间为34.59%
-作业难度适中时间为27.13%。
-
-62.5%：我的学习资料根本看不完，学习资料并不是我提升成绩的障碍。
+http://blog.sina.com.cn/s/blog_591ac304010009v8.html
+
+“中学生学习时间分配”网络调研【三】 (2007-07-30 20:14:25)
+
+ 调研的入口地址是：http://www.my3q.com/go.php?url=mars22/xuemen
+
+调研结果：
+22.80%--在课堂上进度过快，或者深度过深的时间
+42.61%--在课堂上进度过慢，或者深度过浅的时间
+31.04%--在作业中难度过高的的题目占做题时间 
+41.83%--在作业中难度过低的的题目占做题时间
+课堂上进度深度适中时间为34.59%
+作业难度适中时间为27.13%。
+
+62.5%：我的学习资料根本看不完，学习资料并不是我提升成绩的障碍。
 45.8%：我一直大量做题，但考试时看到碰过的题还是容易丢分。

edu/“按需教育”技术交流的结果.20070610.202807.md

@@ -1,16 +1,16 @@
-http://blog.sina.com.cn/s/blog_591ac30401000974.html
-
-“按需教育”技术交流的结果 (2007-06-10 20:28:07)
-
-自从启动这个项目之后，我问过许多老教师这个问题：“如果将学生答题卡上部分答案剪掉之后，与试卷一起交给您分析，要求把剪掉部分补齐，您的准确率有多高？”大部分教师的回答是“应该有六、七成吧。”
- 
-这正是eokdd技术交流的活动规则，其中甲组去掉30%的数据，乙组去掉10%数据，要求参赛选手使用自动软件对学生答题数据进行修复。
- 
-可以这样理解：对学生答题数据修复的准确度，也就是在判断特定学生对特定题目的解题结果，本质上是判断学生学习情况。
- 
-从主办单位公布的数据包看，大部分自动程序超过了老教师的准确度，其中冠军程序的准确度达到了令人惊讶的97%--也就是说每100个被主办方删除的答题数据，只有3个被软件补错了。
- 
-这一届我们公司获得千人甲组的冠军，不过准确度没有乙组高，希望六月份能蝉联。
- 
-eokdd活动的主页是：
+http://blog.sina.com.cn/s/blog_591ac30401000974.html
+
+“按需教育”技术交流的结果 (2007-06-10 20:28:07)
+
+自从启动这个项目之后，我问过许多老教师这个问题：“如果将学生答题卡上部分答案剪掉之后，与试卷一起交给您分析，要求把剪掉部分补齐，您的准确率有多高？”大部分教师的回答是“应该有六、七成吧。”
+ 
+这正是eokdd技术交流的活动规则，其中甲组去掉30%的数据，乙组去掉10%数据，要求参赛选手使用自动软件对学生答题数据进行修复。
+ 
+可以这样理解：对学生答题数据修复的准确度，也就是在判断特定学生对特定题目的解题结果，本质上是判断学生学习情况。
+ 
+从主办单位公布的数据包看，大部分自动程序超过了老教师的准确度，其中冠军程序的准确度达到了令人惊讶的97%--也就是说每100个被主办方删除的答题数据，只有3个被软件补错了。
+ 
+这一届我们公司获得千人甲组的冠军，不过准确度没有乙组高，希望六月份能蝉联。
+ 
+eokdd活动的主页是：
 http://task.eokdd.org.cn/

edu/为什么孩子的时间不够用.20070321.150110.md

@@ -1,19 +1,19 @@
-http://blog.sina.com.cn/s/blog_591ac3040100082e.html
-
-为什么孩子的时间不够用？ (2007-03-21 15:01:10)
- 
-许多家长反映孩子的时间不够用，要是每天多几个小时就好了。其实大部分同学时间不够用的原因是：花了太多时间陪其他同学听课，做作业。
- 
-为什么这么说呢。
-去年底有一项统计报告表明，三分之一的同学在课上走神。这个数字其实非常保守，老师课上的进度和深度能照顾一半的同学，就非常优秀了。如果一个孩子与另外四十个同学分享一个老师，那么他至少花了三分之一的时间陪其他人听课。
-作业的情况也一样，老师为了覆盖所有同学的需要，课后作业的基础概念、深入理解，综合运用题量往往有一个惯常的比例。这个比例下每个孩子都付出了额外的学习时间，去做一些难度不适合自己的题目，而作业的批改结果也对他用处不大。
- 
-所以如果孩子的时间不够用，可以参考这几个建议：
-一、选择水平相当的学校和班级
-如果你的孩子在班里属于中间偏上的水平，他就能享受较多的教育资源。
-二、争取教师的注意
-摩托罗拉说沟通无极限，这很有道理。家长可以多与教师通电话，孩子可以通过课堂提问，作业请教的方法多吸引教师的注意力，影响教学安排向自己倾斜。
-三、开辟第二战场--家庭教育
-如果前两种方式效果不理想，那就应该开辟家庭教育的新战线了。家长一方面应该保证家庭教育投资，一方面应该向学校争取减免统一的课时和作业，因为它们的效率偏低。
- 
+http://blog.sina.com.cn/s/blog_591ac3040100082e.html
+
+为什么孩子的时间不够用？ (2007-03-21 15:01:10)
+ 
+许多家长反映孩子的时间不够用，要是每天多几个小时就好了。其实大部分同学时间不够用的原因是：花了太多时间陪其他同学听课，做作业。
+ 
+为什么这么说呢。
+去年底有一项统计报告表明，三分之一的同学在课上走神。这个数字其实非常保守，老师课上的进度和深度能照顾一半的同学，就非常优秀了。如果一个孩子与另外四十个同学分享一个老师，那么他至少花了三分之一的时间陪其他人听课。
+作业的情况也一样，老师为了覆盖所有同学的需要，课后作业的基础概念、深入理解，综合运用题量往往有一个惯常的比例。这个比例下每个孩子都付出了额外的学习时间，去做一些难度不适合自己的题目，而作业的批改结果也对他用处不大。
+ 
+所以如果孩子的时间不够用，可以参考这几个建议：
+一、选择水平相当的学校和班级
+如果你的孩子在班里属于中间偏上的水平，他就能享受较多的教育资源。
+二、争取教师的注意
+摩托罗拉说沟通无极限，这很有道理。家长可以多与教师通电话，孩子可以通过课堂提问，作业请教的方法多吸引教师的注意力，影响教学安排向自己倾斜。
+三、开辟第二战场--家庭教育
+如果前两种方式效果不理想，那就应该开辟家庭教育的新战线了。家长一方面应该保证家庭教育投资，一方面应该向学校争取减免统一的课时和作业，因为它们的效率偏低。
+ 
 现代社会的竞争是全方位的，孩子的培养是一个家庭综合能力的检验。如果孩子的时间被过多占用，家长可以考虑减少统一的课时作业，补充更有针对性的家庭教育。

edu/为学生的知识结构打分.20070512.222210.md

@@ -1,42 +1,42 @@
-http://blog.sina.com.cn/s/blog_591ac304010008s0.html
-
-为学生的知识结构打分 (2007-05-12 22:22:10)
-
-大家在填写（或者请老师填写）知识结构表时，或多或少会碰到“打分依据”这个问题。我们目前暂时约定统一的填写数值是： 0:没学懂；1-能解易题；2-能解难题
- 
-但是“难”、“易”之间怎么划分呢？为了解释这个问题我们先回顾一下学习中遇到的各种分数。
- 
-【作业】
-老师留的课后作业即使打分也是很粗略的：简单的五分制、打勾/勾点/打叉
-、优良中差、very good/good/...、......因为对作业的评价主要反馈给同学，主要用途是安排自学、补习，只要标识出掌握程度上的差异即可。
- 
-【检验考试】
-检验考试用于检查同学之间、班级之间的学习情况，考试的性质决定了分数的差距反映的是教学努力的差距。考试卷中的题目通常有固定分数值，答卷的分数就是答对题目的分数之和。定分的主要原则是：
-一、越高的分数，蕴含的教育和学习的努力越大；（对于“标准程度”的天赋）
-二、相同的分数差距，尽可能代表相同的教育和学习的努力程度的差距。（事实上少有纯粹的检验考试，往往也糅合了甄选考试的原则，虽然有矛盾但也是无奈的选择。）
- 
-【甄选考试】
-为了分配升学资格而安排的中考、高考，是为下一个教育阶段甄选人才服务的。定分的主要原则有两条：
-一、分数越高越适合下一阶段的学习；
-二、同一分数上的人数越少越好。（如果一个分数上的人数多了，就给甄选带来困难，因此要设法在第一条原则的前提下让成绩分散）
-甄选考试的命题和定分，往往需要引用大量的历史数据。有的甄选考试也会使用浮动分数制--一道题的分数根据答对打错的比例而推算，而不在考前指定。
- 
-大家看，检验考试并不担心出现大量分数并列，而甄选考试并不在乎分数差距背后的血汗是否均等...感兴趣的话还可以从这三种打分依据中对比出更多的内容，但我们今天再展开讨论就跑题了。
- 
-根据《学而不问则忙》的原意，填写《知识结构表》应该使用什么打分原则呢？我们先回顾一下《知识结构表》的用途：
-一、使教育投资（包括时间和金钱）更加理性，更有针对性；
-二、寻找更吻合的学伴，促进有效的交流，降低孩子校外学习的孤独感。
- 
-就第一个目的而言，【作业】的打分原则就足够了；第二个目的更接近【甄选考试】的打分原则。从现实条件来看，大部分家庭应选择【作业】的粗略打分。如果能够在一两个小时内，一气呵成地调阅过去的作业本和考卷，填写《知识结构表》时的整体平衡是相当好的，而且题量远远超过一次大考，因此每个知识点都有足够的题目用于判断，所以说选定近期的补习目标是绰绰有余的。
- 
-好了，如果老师还在向你追问“打分依据”，你可以让他这样打分：
-0：重点补习；1：需要补习；2-不必补习。
-如果再结合家庭的经济情况和同学在这个科目上的时间分配，可以具体规定三个分数的比例，余下的事情老师会处理的。
- 
- 
-相关链接：
-学而不问则忙 一
-学而不问则忙 二
-学而不问则忙 三
-学而不问则忙 四
+http://blog.sina.com.cn/s/blog_591ac304010008s0.html
+
+为学生的知识结构打分 (2007-05-12 22:22:10)
+
+大家在填写（或者请老师填写）知识结构表时，或多或少会碰到“打分依据”这个问题。我们目前暂时约定统一的填写数值是： 0:没学懂；1-能解易题；2-能解难题
+ 
+但是“难”、“易”之间怎么划分呢？为了解释这个问题我们先回顾一下学习中遇到的各种分数。
+ 
+【作业】
+老师留的课后作业即使打分也是很粗略的：简单的五分制、打勾/勾点/打叉
+、优良中差、very good/good/...、......因为对作业的评价主要反馈给同学，主要用途是安排自学、补习，只要标识出掌握程度上的差异即可。
+ 
+【检验考试】
+检验考试用于检查同学之间、班级之间的学习情况，考试的性质决定了分数的差距反映的是教学努力的差距。考试卷中的题目通常有固定分数值，答卷的分数就是答对题目的分数之和。定分的主要原则是：
+一、越高的分数，蕴含的教育和学习的努力越大；（对于“标准程度”的天赋）
+二、相同的分数差距，尽可能代表相同的教育和学习的努力程度的差距。（事实上少有纯粹的检验考试，往往也糅合了甄选考试的原则，虽然有矛盾但也是无奈的选择。）
+ 
+【甄选考试】
+为了分配升学资格而安排的中考、高考，是为下一个教育阶段甄选人才服务的。定分的主要原则有两条：
+一、分数越高越适合下一阶段的学习；
+二、同一分数上的人数越少越好。（如果一个分数上的人数多了，就给甄选带来困难，因此要设法在第一条原则的前提下让成绩分散）
+甄选考试的命题和定分，往往需要引用大量的历史数据。有的甄选考试也会使用浮动分数制--一道题的分数根据答对打错的比例而推算，而不在考前指定。
+ 
+大家看，检验考试并不担心出现大量分数并列，而甄选考试并不在乎分数差距背后的血汗是否均等...感兴趣的话还可以从这三种打分依据中对比出更多的内容，但我们今天再展开讨论就跑题了。
+ 
+根据《学而不问则忙》的原意，填写《知识结构表》应该使用什么打分原则呢？我们先回顾一下《知识结构表》的用途：
+一、使教育投资（包括时间和金钱）更加理性，更有针对性；
+二、寻找更吻合的学伴，促进有效的交流，降低孩子校外学习的孤独感。
+ 
+就第一个目的而言，【作业】的打分原则就足够了；第二个目的更接近【甄选考试】的打分原则。从现实条件来看，大部分家庭应选择【作业】的粗略打分。如果能够在一两个小时内，一气呵成地调阅过去的作业本和考卷，填写《知识结构表》时的整体平衡是相当好的，而且题量远远超过一次大考，因此每个知识点都有足够的题目用于判断，所以说选定近期的补习目标是绰绰有余的。
+ 
+好了，如果老师还在向你追问“打分依据”，你可以让他这样打分：
+0：重点补习；1：需要补习；2-不必补习。
+如果再结合家庭的经济情况和同学在这个科目上的时间分配，可以具体规定三个分数的比例，余下的事情老师会处理的。
+ 
+ 
+相关链接：
+学而不问则忙 一
+学而不问则忙 二
+学而不问则忙 三
+学而不问则忙 四
 知识结构表（带样例） 

edu/关于个性化辅导.20090319.202133.md

@@ -1,22 +1,22 @@
-http://blog.sina.com.cn/s/blog_591ac3040100c8o8.html
-
-关于个性化辅导 (2009-03-19 20:21:33)
-
-摘自学门科技内部材料，仅供参考。
-
-......
-
-二、个性化辅导
-
-1、利润困境
-个性化辅导的特征是统一的师资、场地、教材（三个统一），进行一对一教学。刚出现的时候很受市场欢迎，成为课外辅导的新增长点。然而，这“三个统一”并没有带来实质上的质量优势，业务上直接受到个体家教的挑战，在消费者趋于理性之后就陷入停滞甚至衰退。这时辅导公司通常会向其它地区发展，以图在新的城市作为新业务实现高利润。但由于总部和分部之间的实际贡献与利益分配不平衡，它们往往在扩张半年左右即爆发管理问题，因而难以实现预期的高利润，陷入困境。
-
-2、原因分析
-上述利润困境的成因，是把早期的成功错误地归功于“三个统一”，因此将市场收益更多投入到广告、分校扩张上，不停地强化这个概念，而没有集中资源研发个性化教学方案，以真正实现教学环节的个性化差异。如果充分利用第一桶金，集中研发出有效的“个性化教学方案”，得以聘用中低端教员实施高质量的教学，则不至于人力成本失控；配合品牌和资金进行扩张，则不至于分部管理失控。
-所以说，总部职能的缺位是造成利润困境的根本原因。
-
-3、总部的核心职能
-对于个性化辅导公司，其总部的核心职能之一是研发个性化教学方案。因为这套方案决定了用人成本和教学质量，可以说它也决定了公司的利润率。这套方案通常包含两个部分：一套个性化分析工具、一套教改方案。前者借助技术以实现个性化分析，后者对传统（整班）教学的工序、岗位进行拆分、重组，在教学过程中充分运用分析结果。
-个性化教学方案可以分解为技术研究和教学研究问题，这是个性化辅导公司总部的核心职能。不解决这两个研究问题，则总部难以管理分部，校区难以管理教师。
-
+http://blog.sina.com.cn/s/blog_591ac3040100c8o8.html
+
+关于个性化辅导 (2009-03-19 20:21:33)
+
+摘自学门科技内部材料，仅供参考。
+
+......
+
+二、个性化辅导
+
+1、利润困境
+个性化辅导的特征是统一的师资、场地、教材（三个统一），进行一对一教学。刚出现的时候很受市场欢迎，成为课外辅导的新增长点。然而，这“三个统一”并没有带来实质上的质量优势，业务上直接受到个体家教的挑战，在消费者趋于理性之后就陷入停滞甚至衰退。这时辅导公司通常会向其它地区发展，以图在新的城市作为新业务实现高利润。但由于总部和分部之间的实际贡献与利益分配不平衡，它们往往在扩张半年左右即爆发管理问题，因而难以实现预期的高利润，陷入困境。
+
+2、原因分析
+上述利润困境的成因，是把早期的成功错误地归功于“三个统一”，因此将市场收益更多投入到广告、分校扩张上，不停地强化这个概念，而没有集中资源研发个性化教学方案，以真正实现教学环节的个性化差异。如果充分利用第一桶金，集中研发出有效的“个性化教学方案”，得以聘用中低端教员实施高质量的教学，则不至于人力成本失控；配合品牌和资金进行扩张，则不至于分部管理失控。
+所以说，总部职能的缺位是造成利润困境的根本原因。
+
+3、总部的核心职能
+对于个性化辅导公司，其总部的核心职能之一是研发个性化教学方案。因为这套方案决定了用人成本和教学质量，可以说它也决定了公司的利润率。这套方案通常包含两个部分：一套个性化分析工具、一套教改方案。前者借助技术以实现个性化分析，后者对传统（整班）教学的工序、岗位进行拆分、重组，在教学过程中充分运用分析结果。
+个性化教学方案可以分解为技术研究和教学研究问题，这是个性化辅导公司总部的核心职能。不解决这两个研究问题，则总部难以管理分部，校区难以管理教师。
+
 ......

edu/关于教育行业重构的探讨.20080319.152103.md

@@ -1,26 +1,26 @@
-http://blog.sina.com.cn/s/blog_591ac30401008lon.html
-
-关于教育行业重构的探讨 (2008-03-19 15:21:03)
-
-大家好，
-
-　　当政府投入逐年增加，投资活动逐年增加，一个行业就应该进入繁荣阶段了。
-　　当“维持”和“退出”成了行内企业的普遍选择，一个行业就到了升级或消亡的时候了。
-　　在教育市场中却同时出现上述两种特征，“升级＋繁荣”就成为一个现实的选择，一轮整体性的变革即将来临。这场变革必将深入的改造教育行业的部门设
-置、管理体制和教学流程。在变革的前夕，教育行业的朋友非常需要与管理咨询、法律、投资方面的朋友一起探讨，并共同分享后面的商业机会。
-
-　　因此我提议大家组织起来，参与在“按需教育”论坛的讨论：
-　　http://groups.google.com/group/eokdd/topics
-　　将要探讨的专题包括（而不限于）：
-一、其它行业收益于部门重构和流程改造的共性规律；
-二、教育行业发展的主要矛盾是什么，现有部门设置、管理体制与教学流程对问题的解决有什么制约；
-三、要达到更优的教学效果，部门设置、管理体制与教学流程应该怎么设计；
-四、部门设置、管理体制与教学流程的新老过渡，将经过几个阶段；
-五、在这个过程中，将会出现哪些新的商业模式、合作形态，会有哪些新的管理、制度和法律问题，我们应如何应对。
-这些问题有前后接递的关系，可以依次作为探讨的重点，我们应定期做一下总结整理。
-
-　　随着网上讨论的进行，可以组织专题沙龙以集中探讨一些要点、难点。对形成共识的环节，即可依托现有研究课题和商业产品安排实践。
-
-　　感兴趣吗，那就到论坛来，分享你的第一篇观点吧。
-
+http://blog.sina.com.cn/s/blog_591ac30401008lon.html
+
+关于教育行业重构的探讨 (2008-03-19 15:21:03)
+
+大家好，
+
+　　当政府投入逐年增加，投资活动逐年增加，一个行业就应该进入繁荣阶段了。
+　　当“维持”和“退出”成了行内企业的普遍选择，一个行业就到了升级或消亡的时候了。
+　　在教育市场中却同时出现上述两种特征，“升级＋繁荣”就成为一个现实的选择，一轮整体性的变革即将来临。这场变革必将深入的改造教育行业的部门设
+置、管理体制和教学流程。在变革的前夕，教育行业的朋友非常需要与管理咨询、法律、投资方面的朋友一起探讨，并共同分享后面的商业机会。
+
+　　因此我提议大家组织起来，参与在“按需教育”论坛的讨论：
+　　http://groups.google.com/group/eokdd/topics
+　　将要探讨的专题包括（而不限于）：
+一、其它行业收益于部门重构和流程改造的共性规律；
+二、教育行业发展的主要矛盾是什么，现有部门设置、管理体制与教学流程对问题的解决有什么制约；
+三、要达到更优的教学效果，部门设置、管理体制与教学流程应该怎么设计；
+四、部门设置、管理体制与教学流程的新老过渡，将经过几个阶段；
+五、在这个过程中，将会出现哪些新的商业模式、合作形态，会有哪些新的管理、制度和法律问题，我们应如何应对。
+这些问题有前后接递的关系，可以依次作为探讨的重点，我们应定期做一下总结整理。
+
+　　随着网上讨论的进行，可以组织专题沙龙以集中探讨一些要点、难点。对形成共识的环节，即可依托现有研究课题和商业产品安排实践。
+
+　　感兴趣吗，那就到论坛来，分享你的第一篇观点吧。
+
 勇刚

edu/各产业的网络化与智能化趋势对比.20070821.172842.md

@@ -1,24 +1,24 @@
-http://blog.sina.com.cn/s/blog_591ac30401000a7x.html
-
-各产业的网络化与智能化趋势对比 (2007-08-21 17:28:42)
-
-我们用不同的关键词和年份组合起来，在google上查询了相关网页的数量，以此来对比各产业的网络化、智能化的趋势。
-
-![](http://s13.sinaimg.cn/orignal/591ac304b5fa4a342990c)
-
-简单的分析一下：
-产业网络化前五名：
-英语：教育、金融、交通、军事、制造
-中文：制造、金融、交通、医疗、军事
-
-产业数据挖掘应用前五名：
-英语：教育、制造、金融、医疗、交通
-中文：制造、教育、金融、交通、医疗
-
-英语国家产业发展较理性
-重视数据汇总与数据分析两种能力均衡发展；
-在网络化初期加大产业数据挖掘力度，85年后所有产业数据挖掘力度加大，教育与金融在85年网络化，其它产业在95~00之间陆续启动。
-
-中国各产业受设备价格影响较大，在数据挖掘应用不成熟时被动网络化：
-制造、金融、交通在85年起网络化，其它在95年集中启动。
+http://blog.sina.com.cn/s/blog_591ac30401000a7x.html
+
+各产业的网络化与智能化趋势对比 (2007-08-21 17:28:42)
+
+我们用不同的关键词和年份组合起来，在google上查询了相关网页的数量，以此来对比各产业的网络化、智能化的趋势。
+
+![](http://s13.sinaimg.cn/orignal/591ac304b5fa4a342990c)
+
+简单的分析一下：
+产业网络化前五名：
+英语：教育、金融、交通、军事、制造
+中文：制造、金融、交通、医疗、军事
+
+产业数据挖掘应用前五名：
+英语：教育、制造、金融、医疗、交通
+中文：制造、教育、金融、交通、医疗
+
+英语国家产业发展较理性
+重视数据汇总与数据分析两种能力均衡发展；
+在网络化初期加大产业数据挖掘力度，85年后所有产业数据挖掘力度加大，教育与金融在85年网络化，其它产业在95~00之间陆续启动。
+
+中国各产业受设备价格影响较大，在数据挖掘应用不成熟时被动网络化：
+制造、金融、交通在85年起网络化，其它在95年集中启动。
 制造、教育、金融、交通从95年加大数据挖掘投入，其它产业到05年仍发展缓慢。

edu/学而不问则忙.2.20070504.201134.md

@@ -1,26 +1,26 @@
-http://blog.sina.com.cn/s/blog_591ac304010008oi.html
-
-学而不问则忙 之二 (2007-05-04 20:11:34)
-
-先解释一下，昨天的帖子中提到需要用一半的时间进行“问”，指的是课余时间的一半，前提是孩子已经在学校接受了完整而系统的课堂讲授。
- 
-另外顺便说一下为什么老教师的“问”不能用现成的试卷来代替。
-拿数学课作为例子，初中高中的教材大约都有一百个小节，每节通常需要讲好几堂课，包含好几个知识点。即使每小节只考两道题，每道题解题时间三分钟，用现成的试卷来“问”一遍毕业前的孩子的话，大约需要十个小时。
-另一方面，孩子对一个知识点的掌握程度是不断变化的，比如每周都学习新的知识；每当学习新知识点时用到的老知识点，多半有所巩固提高；而大部分老知识点总在不断地遗忘。
-一方面普查一遍题量大，耗费时间长；一方面孩子的知识掌握每周都在变化。所以说仅仅通过纸面的作业或者试卷去准确判断孩子的知识结构，是不可行的。而有经验的教师通过双向交流，结合历史上相似案例可以快速捕捉到孩子的知识结构特征，选择弱点后用适当的“问”来印证，这个过程是固定命题的卷子难以取代的。
- 
-今天讲讲具体应该怎么问，我们限定一下问题范围：怎么问出孩子最需要补充的三五个知识点--这大约是一个晚上可以补习的份量。
-根据对孩子了解程度的不同，头几个问题有多种选择，知道他弱项的可以直接问，不知道的可以先了解大致的排名情况，然后从同年级情况选择入手点。对于快速正确回答的孩子，可以在同一知识点上增加难度，增加应用灵活度；对于回答错误或者举棋不定的情况，可以降低难度、切分题目环节、转问母知识点、转问同类解题思路的其它题......来探问他的实际漏洞，一般都能发现他的弱点。
-对于中上水平的同学，通常在新解题方法和多知识点结合的问题上熟练程度不足，可以补充一些例题，温习常见的联合出题知识点概念，再逐步扶持孩子独立解题。对于中下水平的孩子，容易在知识点本身（包括母知识点）的理解不准确，就需要从基本概念开始补充。
-通常选择需要温习的三五个知识点需要将近一个小时，然后趁孩子印象深刻时抓紧补充，这个晚上的效果会非常好。
- 
-这样的“问”，有经验的老教师当然是最佳选择，但同学或者家长也是可以自己进行的。需要准备的材料有：
-一、一本习题书，需要有展开讲解的解题步骤；
-二、一本讲解各种解题方法技巧的参考书；
-三、自制一张打分表，包含已经学过的小节（知识点）。
-这个“问”的过程要坚持几项工作：
-一、坚持每道错题必须明确出现失误的步骤，每个失误必须确定是概念不清还是解题方法不熟练，概念不清的必须明确标出关联的小节（知识点）。
-二、坚持为每个被“问”到的小节（知识点）做记录，可以根据掌握程度记上分，有经验的教师可以分得很细，同学或者家长至少可以分：不懂、能解易题、能解难题三档吧。
-三、对于做错的题要根据“降低难度、切分题目环节、转问母知识点、转问同类解题思路的其它题”的方法选下一道，有多道题选上的记录一下，依次去做。
- 
+http://blog.sina.com.cn/s/blog_591ac304010008oi.html
+
+学而不问则忙 之二 (2007-05-04 20:11:34)
+
+先解释一下，昨天的帖子中提到需要用一半的时间进行“问”，指的是课余时间的一半，前提是孩子已经在学校接受了完整而系统的课堂讲授。
+ 
+另外顺便说一下为什么老教师的“问”不能用现成的试卷来代替。
+拿数学课作为例子，初中高中的教材大约都有一百个小节，每节通常需要讲好几堂课，包含好几个知识点。即使每小节只考两道题，每道题解题时间三分钟，用现成的试卷来“问”一遍毕业前的孩子的话，大约需要十个小时。
+另一方面，孩子对一个知识点的掌握程度是不断变化的，比如每周都学习新的知识；每当学习新知识点时用到的老知识点，多半有所巩固提高；而大部分老知识点总在不断地遗忘。
+一方面普查一遍题量大，耗费时间长；一方面孩子的知识掌握每周都在变化。所以说仅仅通过纸面的作业或者试卷去准确判断孩子的知识结构，是不可行的。而有经验的教师通过双向交流，结合历史上相似案例可以快速捕捉到孩子的知识结构特征，选择弱点后用适当的“问”来印证，这个过程是固定命题的卷子难以取代的。
+ 
+今天讲讲具体应该怎么问，我们限定一下问题范围：怎么问出孩子最需要补充的三五个知识点--这大约是一个晚上可以补习的份量。
+根据对孩子了解程度的不同，头几个问题有多种选择，知道他弱项的可以直接问，不知道的可以先了解大致的排名情况，然后从同年级情况选择入手点。对于快速正确回答的孩子，可以在同一知识点上增加难度，增加应用灵活度；对于回答错误或者举棋不定的情况，可以降低难度、切分题目环节、转问母知识点、转问同类解题思路的其它题......来探问他的实际漏洞，一般都能发现他的弱点。
+对于中上水平的同学，通常在新解题方法和多知识点结合的问题上熟练程度不足，可以补充一些例题，温习常见的联合出题知识点概念，再逐步扶持孩子独立解题。对于中下水平的孩子，容易在知识点本身（包括母知识点）的理解不准确，就需要从基本概念开始补充。
+通常选择需要温习的三五个知识点需要将近一个小时，然后趁孩子印象深刻时抓紧补充，这个晚上的效果会非常好。
+ 
+这样的“问”，有经验的老教师当然是最佳选择，但同学或者家长也是可以自己进行的。需要准备的材料有：
+一、一本习题书，需要有展开讲解的解题步骤；
+二、一本讲解各种解题方法技巧的参考书；
+三、自制一张打分表，包含已经学过的小节（知识点）。
+这个“问”的过程要坚持几项工作：
+一、坚持每道错题必须明确出现失误的步骤，每个失误必须确定是概念不清还是解题方法不熟练，概念不清的必须明确标出关联的小节（知识点）。
+二、坚持为每个被“问”到的小节（知识点）做记录，可以根据掌握程度记上分，有经验的教师可以分得很细，同学或者家长至少可以分：不懂、能解易题、能解难题三档吧。
+三、对于做错的题要根据“降低难度、切分题目环节、转问母知识点、转问同类解题思路的其它题”的方法选下一道，有多道题选上的记录一下，依次去做。
+ 
 这是一个非常简化的过程，实际情况往往灵活得多，但它可以帮助孩子在没有老师时，通过不到一个小时的自测找到最需要补充的三五个知识点，长期坚持的话整张表可以一目了然地反映整体状况，孩子的“学”自然就有针对性了。

edu/学而不问则忙.20070503.223840.md

@@ -1,20 +1,20 @@
-http://blog.sina.com.cn/s/blog_591ac304010008o6.html
-
-学而不问则忙 (2007-05-03 22:38:40)
-
-和过去相比，现在的孩子学习压力更重了，大部分同学都很自觉，很努力。和过去相比，现在家庭的购买力更强了，在教育上更敢投资，孩子的资料基本不缺。同学们最主要的困难就是“时间不够”，而且购买力越强的家庭，越努力的孩子，时间越不够。
- 
-在补习时孩子主要有两种情况，一种是带着问题的，他们很清楚自己哪里没有学明白，对老师不停地提问直到弄懂；另一种是提不出问题的，这样的同学就需要老师来提问，这往往要耗费老师大量的时间精力。现实中“时间不够用”的通常是后一种同学。
- 
-我们观察了一些有经验的老教师，他们给提不出问题的同学补习时非常注重提问，这个提问不能用成型的卷子来代替，因为老教师一边问一边选择后面的提问方向，一步一步地了解到孩子的弱点，然后才开始讲授。在大部分情况下，“问”的时间占到50%甚至更多，并不比“讲”的时间少。您可别小看这个“问”的环节，老教师半个小时的“问”，比学生做十个小时的卷子更能暴露问题。
-相信许多家长在小学低年级时都有自己给孩子补课的经历，可以回忆一下时间的分配。
- 
-到了中学家长直接补习有一定困难，这时候孩子大部分时间是自学。对于会问的孩子这不是大问题，他们已经习惯于自己问自己，然后问老师这一学习方法。但不会提问的孩子，这时候成绩容易下滑，即使大幅度增加温习时间也无济于事。或者请的家教经验不足，“问”的功力不够深厚，效果也不理想。
- 
-对于后一种情形，家长一定要清楚：解决“忙”的问题，最关键还是“问”，而不是“读”，一旦“问”出弱点来，孩子自然就不“忙”了。
-每个科目的情况不同，像数学的课后自学一般需要安排一半时间用于“问”，另一半时间足够“学”了。如果“问”的时间不能保证，习惯没有培养成型，“学”的时间没有针对性，那多半是“忙不过来”的。
- 
-总结起来，如果孩子总是“忙不过来”，那么家长需要：
-一、培养孩子“问”的习惯和技巧；
-二、保证“学”的资源和投入，让孩子问完之后能尽快进补。
+http://blog.sina.com.cn/s/blog_591ac304010008o6.html
+
+学而不问则忙 (2007-05-03 22:38:40)
+
+和过去相比，现在的孩子学习压力更重了，大部分同学都很自觉，很努力。和过去相比，现在家庭的购买力更强了，在教育上更敢投资，孩子的资料基本不缺。同学们最主要的困难就是“时间不够”，而且购买力越强的家庭，越努力的孩子，时间越不够。
+ 
+在补习时孩子主要有两种情况，一种是带着问题的，他们很清楚自己哪里没有学明白，对老师不停地提问直到弄懂；另一种是提不出问题的，这样的同学就需要老师来提问，这往往要耗费老师大量的时间精力。现实中“时间不够用”的通常是后一种同学。
+ 
+我们观察了一些有经验的老教师，他们给提不出问题的同学补习时非常注重提问，这个提问不能用成型的卷子来代替，因为老教师一边问一边选择后面的提问方向，一步一步地了解到孩子的弱点，然后才开始讲授。在大部分情况下，“问”的时间占到50%甚至更多，并不比“讲”的时间少。您可别小看这个“问”的环节，老教师半个小时的“问”，比学生做十个小时的卷子更能暴露问题。
+相信许多家长在小学低年级时都有自己给孩子补课的经历，可以回忆一下时间的分配。
+ 
+到了中学家长直接补习有一定困难，这时候孩子大部分时间是自学。对于会问的孩子这不是大问题，他们已经习惯于自己问自己，然后问老师这一学习方法。但不会提问的孩子，这时候成绩容易下滑，即使大幅度增加温习时间也无济于事。或者请的家教经验不足，“问”的功力不够深厚，效果也不理想。
+ 
+对于后一种情形，家长一定要清楚：解决“忙”的问题，最关键还是“问”，而不是“读”，一旦“问”出弱点来，孩子自然就不“忙”了。
+每个科目的情况不同，像数学的课后自学一般需要安排一半时间用于“问”，另一半时间足够“学”了。如果“问”的时间不能保证，习惯没有培养成型，“学”的时间没有针对性，那多半是“忙不过来”的。
+ 
+总结起来，如果孩子总是“忙不过来”，那么家长需要：
+一、培养孩子“问”的习惯和技巧；
+二、保证“学”的资源和投入，让孩子问完之后能尽快进补。
 这两个任务做好之后，孩子就不忙了。

edu/学而不问则忙.3.20070505.131752.md

@@ -1,30 +1,30 @@
-http://blog.sina.com.cn/s/blog_591ac304010008ox.html
-
-学而不问则忙 之三 (2007-05-05 13:17:52)
-
- 昨天我们讲到如何通过一个小时的自测，定位出孩子需要补充的三五个知识点。这种自测每个月需要进行一两次，重点学科重点时期可以每周进行一次，您会看到每次的结果都不全相同。
- 
-今天我们一起看看“问”完之后怎么“学”，如果“学”的环节不使用“问”的结果，那前面的功夫就白费了，这里的“学”也是有技巧的。一个理想的家庭学习环境需要有几个要素，同学和家长们可以自我检查一下：
-一、充足的例题，例题的作用是帮助孩子在大约两分钟时间内掌握知识点的运用；
-二、基本概念的材料，针对单个知识点的，长度在五到十分钟左右的“微课程”；
-三、疑难问题的指导，能在孩子的兴趣消退之前，及时解答他的特定问题。
- 
-对于自学能力强，悟性高的孩子，教参书籍就可以满足例题和基本概念的需要，这样的同学通常更容易在学校里获得老师的指导。但大部分的同学还会用到网络资源或者家教，所以今天我们重点讲这两样。
- 
-现在有许多网络教育资源供同学和家长选择，其中不乏精品。选购时要注意不必一味追求名校、名师，对于掌握了“问”的技巧的孩子，真正需要的是便于检索的、程度适合的“微课程”。所以选择时要留意课程是否进行了细分，细分到章、节还是具体知识点，从登录到选课再到开始教学是否简捷。有许多网站罗列了大量的优质教育资源，但是调用起来不够方便，由注意力容易分散的少年来使用效果不一定好。
-另外，不同的课件制作方有不同的指导思想，是补基础还是抓应用，是单点突破还是循序渐进，都需要根据孩子的特点来选择。
-总的来说，网络教育资源是供大于求的状况，只要耐心识别寻找，每个孩子都能得到适合的资源提供商。
- 
-家教也是很普遍的教育手段，不过大部分家长对家教老师的了解不深，往往通过口碑进行选择，但孩子的情况都有一定差异，常常出现同一个老师进行补习，一个孩子效果很好，另一个孩子却不见效。
-为了便于后面讨论，所以我们先把家教老师分一下类。第一类是高校学生，他们刚刚经历高考，和孩子交流障碍不大，而且费用比较合理，但是教学经验不足；第二类是年轻教师，他们受过系统的教育训练，有一定的教学实践（为了保证效果最好找五年教龄以上，课堂教学效果较好的），家教效果比高校学生好；第三类是经验丰富的老教师，如果时间充足的话效果最佳，但是费用比较高，和孩子沟通可能有障碍，对于性格内向的孩子家长要及时了解效果。
- 
-根据孩子和家庭情况不同，我建议聘请两位家教老师，实施“学”、“问”独立，高低搭配。
-负责“问”的可以是高校学生或者年轻教师，他的任务是了解孩子的缺陷，填写昨天提到的知识结构表。对于特别简单的概念理解和方法指导，他通常也会顺便解决了。同时要求他在“问”的过程中，跟踪了解负责“学”的老师的工作效果，起到“监理”的作用。
-负责“学”的家教老师，可以找五年以上教龄的，在校属于青年骨干的教师，如果效果不好再转向资深老教师。他负责清除“问”的环节划定的知识点，帮助孩子理解到位，方法熟练。家长可以根据“问”老师的跟踪反馈，提前和“学”老师沟通，督促其认真备课，以保证效果。
-对于重点学科，“问”老师至少每周一小时时间，“学”老师的课时一两周一次就够了。另外，学校班主任和任课老师也是需要加强联系的，如果配合的好他们可以承担“学”老师的任务。
- 
-好，总结一下，如果要孩子“忙得过来”，就要建立“外科手术”式的精确教学模式。其中“学”的环节要点是：
-一、便于检索的“微课程”；
-二、相互独立的“学”老师和“问”老师；
-三、加强和学校任课老师的联系。
+http://blog.sina.com.cn/s/blog_591ac304010008ox.html
+
+学而不问则忙 之三 (2007-05-05 13:17:52)
+
+ 昨天我们讲到如何通过一个小时的自测，定位出孩子需要补充的三五个知识点。这种自测每个月需要进行一两次，重点学科重点时期可以每周进行一次，您会看到每次的结果都不全相同。
+ 
+今天我们一起看看“问”完之后怎么“学”，如果“学”的环节不使用“问”的结果，那前面的功夫就白费了，这里的“学”也是有技巧的。一个理想的家庭学习环境需要有几个要素，同学和家长们可以自我检查一下：
+一、充足的例题，例题的作用是帮助孩子在大约两分钟时间内掌握知识点的运用；
+二、基本概念的材料，针对单个知识点的，长度在五到十分钟左右的“微课程”；
+三、疑难问题的指导，能在孩子的兴趣消退之前，及时解答他的特定问题。
+ 
+对于自学能力强，悟性高的孩子，教参书籍就可以满足例题和基本概念的需要，这样的同学通常更容易在学校里获得老师的指导。但大部分的同学还会用到网络资源或者家教，所以今天我们重点讲这两样。
+ 
+现在有许多网络教育资源供同学和家长选择，其中不乏精品。选购时要注意不必一味追求名校、名师，对于掌握了“问”的技巧的孩子，真正需要的是便于检索的、程度适合的“微课程”。所以选择时要留意课程是否进行了细分，细分到章、节还是具体知识点，从登录到选课再到开始教学是否简捷。有许多网站罗列了大量的优质教育资源，但是调用起来不够方便，由注意力容易分散的少年来使用效果不一定好。
+另外，不同的课件制作方有不同的指导思想，是补基础还是抓应用，是单点突破还是循序渐进，都需要根据孩子的特点来选择。
+总的来说，网络教育资源是供大于求的状况，只要耐心识别寻找，每个孩子都能得到适合的资源提供商。
+ 
+家教也是很普遍的教育手段，不过大部分家长对家教老师的了解不深，往往通过口碑进行选择，但孩子的情况都有一定差异，常常出现同一个老师进行补习，一个孩子效果很好，另一个孩子却不见效。
+为了便于后面讨论，所以我们先把家教老师分一下类。第一类是高校学生，他们刚刚经历高考，和孩子交流障碍不大，而且费用比较合理，但是教学经验不足；第二类是年轻教师，他们受过系统的教育训练，有一定的教学实践（为了保证效果最好找五年教龄以上，课堂教学效果较好的），家教效果比高校学生好；第三类是经验丰富的老教师，如果时间充足的话效果最佳，但是费用比较高，和孩子沟通可能有障碍，对于性格内向的孩子家长要及时了解效果。
+ 
+根据孩子和家庭情况不同，我建议聘请两位家教老师，实施“学”、“问”独立，高低搭配。
+负责“问”的可以是高校学生或者年轻教师，他的任务是了解孩子的缺陷，填写昨天提到的知识结构表。对于特别简单的概念理解和方法指导，他通常也会顺便解决了。同时要求他在“问”的过程中，跟踪了解负责“学”的老师的工作效果，起到“监理”的作用。
+负责“学”的家教老师，可以找五年以上教龄的，在校属于青年骨干的教师，如果效果不好再转向资深老教师。他负责清除“问”的环节划定的知识点，帮助孩子理解到位，方法熟练。家长可以根据“问”老师的跟踪反馈，提前和“学”老师沟通，督促其认真备课，以保证效果。
+对于重点学科，“问”老师至少每周一小时时间，“学”老师的课时一两周一次就够了。另外，学校班主任和任课老师也是需要加强联系的，如果配合的好他们可以承担“学”老师的任务。
+ 
+好，总结一下，如果要孩子“忙得过来”，就要建立“外科手术”式的精确教学模式。其中“学”的环节要点是：
+一、便于检索的“微课程”；
+二、相互独立的“学”老师和“问”老师；
+三、加强和学校任课老师的联系。
 按照这套方案去做，准备材料和选聘老师大概需要一两周时间，然后孩子就开始享受有序的“按需教育”了。

edu/学而不问则忙.4.20070506.195852.md

@@ -1,28 +1,28 @@
-http://blog.sina.com.cn/s/blog_591ac304010008pc.html
-
-学而不问则忙 之四 (2007-05-06 19:58:52)
-
-五一假期快结束了，今天是“学而不问则忙”的最后一贴。
-前面讲到高效的家庭教育是“外科手术式”的“按需教育”，应该先检查出同学需要补充的知识点，而且负责检查的“问”老师和负责补习的“学”老师最好分开安排。最简单的情况，应由同学自己“问”，由学校任课老师提供“学”。但家长应承担调度协调的任务，了解知识结构表填写情况，还要尽可能准备充足的例题和“微课程”。
- 
-今天我们探讨如何选择“学伴”，中学正是活泼好动的年龄，自我管理能力不如成年人，单独学习时间长了效率容易下降，而许多忙碌的家长往往分身乏术，不能长期陪伴孩子的课余学习。如果能找到水平相当、进度相似的同学作伴，交流“学”的资源和心得，共享“问”的结果，家长只需要定期对比检查，给予适当的奖励和鞭策，效果会远远好于孤独的学习。
- 
-学校受客观条件制约必须按班级授课，大部分还不能根据各科目学习情况分班分组、安排座位。这种情况下同学之间的好友关系主要受性格、爱好甚至上学路径所影响，并不一定适合在“按需教育”阶段作为同学。
- 
-从实践情况看，效果最理想的“学伴”是知识结构的长短板块相似的同学，这里的长短板不是指科目强弱，要细化到具体知识点，至少到教材中的具体小节。最简单的方式就是对照习题本，看错题的分布是否相似。错题本相似的同学，往往在非智力因素上也很接近，他们的交流效果远远超出他人预期。
- 
-孩子在真实世界中的接触面很有限，我们是否可以利用互联网更方便地交换知识结构表和错题本，借助大家的力量把“按需教育”环境的最后一环--“学伴”补齐？为了方便大家交换资料我在新浪创建了“按需教育”博客圈，请有意参与的同学和家长加入一下。五一后我们一起制定统一的表格结构，以便大家交换分享。
- 
-下面我与大家分享一个小故事。
-有—个农夫经常是南瓜大赛的首奖及优等奖的得主，但每次得奖之后，他都毫不吝惜地将得奖的种子分送给街坊邻居。有一位邻居很诧异地问他，“你的奖项得来不易，每季都看你投入大量的时间和精力来做品种改良，为什么还这么慷慨地将种子送给我们呢?难道你不怕我们的南瓜品种因而超越你的吗？”
-这位农夫回答：“我将种子分送给大家，帮助大家，其实也就是帮助我自己。如果我将得奖的种子私藏，你们在南瓜品种的改良方面势必无法跟上，蜜蜂就容易将那些较差的品种传播过来，我必须在防范外来花粉方面大费周折而疲于奔命啊。”
- 
-每位同学都在不停受到他的同学、朋友的影响，所以好的经验一定要及时和身边的朋友分享。事实上经常接触的朋友在大考的竞争对手中占的比例是微乎其微的，小环境的成员越优秀，自己用在真正学习上的时间效率越高，这个道理大家都很容易想明白。
- 
-最后是大总结，我相信信息技术已经使“外科手术式”的“按需教育”成为可能，您需要做的是：
-一、加入“按需教育”博客圈，使用共同设计的知识结构表和错题本；
-二、定期检查同学的知识结构，用一小时时间找出最需要补充的三五个知识点，重点科目应做到每周一次；
-三、准备充足的、细分到知识点的、便于检索的例题和“微课程”，使同学可以及时补充“养分”；
-四、寻找错题本相似的“学伴”，在交流中共同进步；
-五、请家教时单独请一名“问”老师，专职负责检查知识结构。
+http://blog.sina.com.cn/s/blog_591ac304010008pc.html
+
+学而不问则忙 之四 (2007-05-06 19:58:52)
+
+五一假期快结束了，今天是“学而不问则忙”的最后一贴。
+前面讲到高效的家庭教育是“外科手术式”的“按需教育”，应该先检查出同学需要补充的知识点，而且负责检查的“问”老师和负责补习的“学”老师最好分开安排。最简单的情况，应由同学自己“问”，由学校任课老师提供“学”。但家长应承担调度协调的任务，了解知识结构表填写情况，还要尽可能准备充足的例题和“微课程”。
+ 
+今天我们探讨如何选择“学伴”，中学正是活泼好动的年龄，自我管理能力不如成年人，单独学习时间长了效率容易下降，而许多忙碌的家长往往分身乏术，不能长期陪伴孩子的课余学习。如果能找到水平相当、进度相似的同学作伴，交流“学”的资源和心得，共享“问”的结果，家长只需要定期对比检查，给予适当的奖励和鞭策，效果会远远好于孤独的学习。
+ 
+学校受客观条件制约必须按班级授课，大部分还不能根据各科目学习情况分班分组、安排座位。这种情况下同学之间的好友关系主要受性格、爱好甚至上学路径所影响，并不一定适合在“按需教育”阶段作为同学。
+ 
+从实践情况看，效果最理想的“学伴”是知识结构的长短板块相似的同学，这里的长短板不是指科目强弱，要细化到具体知识点，至少到教材中的具体小节。最简单的方式就是对照习题本，看错题的分布是否相似。错题本相似的同学，往往在非智力因素上也很接近，他们的交流效果远远超出他人预期。
+ 
+孩子在真实世界中的接触面很有限，我们是否可以利用互联网更方便地交换知识结构表和错题本，借助大家的力量把“按需教育”环境的最后一环--“学伴”补齐？为了方便大家交换资料我在新浪创建了“按需教育”博客圈，请有意参与的同学和家长加入一下。五一后我们一起制定统一的表格结构，以便大家交换分享。
+ 
+下面我与大家分享一个小故事。
+有—个农夫经常是南瓜大赛的首奖及优等奖的得主，但每次得奖之后，他都毫不吝惜地将得奖的种子分送给街坊邻居。有一位邻居很诧异地问他，“你的奖项得来不易，每季都看你投入大量的时间和精力来做品种改良，为什么还这么慷慨地将种子送给我们呢?难道你不怕我们的南瓜品种因而超越你的吗？”
+这位农夫回答：“我将种子分送给大家，帮助大家，其实也就是帮助我自己。如果我将得奖的种子私藏，你们在南瓜品种的改良方面势必无法跟上，蜜蜂就容易将那些较差的品种传播过来，我必须在防范外来花粉方面大费周折而疲于奔命啊。”
+ 
+每位同学都在不停受到他的同学、朋友的影响，所以好的经验一定要及时和身边的朋友分享。事实上经常接触的朋友在大考的竞争对手中占的比例是微乎其微的，小环境的成员越优秀，自己用在真正学习上的时间效率越高，这个道理大家都很容易想明白。
+ 
+最后是大总结，我相信信息技术已经使“外科手术式”的“按需教育”成为可能，您需要做的是：
+一、加入“按需教育”博客圈，使用共同设计的知识结构表和错题本；
+二、定期检查同学的知识结构，用一小时时间找出最需要补充的三五个知识点，重点科目应做到每周一次；
+三、准备充足的、细分到知识点的、便于检索的例题和“微课程”，使同学可以及时补充“养分”；
+四、寻找错题本相似的“学伴”，在交流中共同进步；
+五、请家教时单独请一名“问”老师，专职负责检查知识结构。
 这些准备工作需要一两周时间，希望能帮助同学在更少的时间内踏踏实实地前进。

edu/家庭教育是否独立于学校教育.20061228.205928.md

@@ -1,14 +1,14 @@
-http://blog.sina.com.cn/s/blog_591ac304010006t8.html
-
-家庭教育是否独立于学校教育 (2006-12-28 20:59:28)
- 
-这是这些天和同事们讨论的一个题目，我尽量不掺杂个人意见，记录一下正反双方的看法。
- 
-一方认为，学校教育已经非常完善，功课压力也很大，孩子回家做完作业已经很晚了，不应该再给他增加负担。家长（或者家教）至多随着学校排期给孩子补充讲解一下。
- 
-另一方的意见是，学校只负责平均教育，成本低效率也低，老师根本照顾不到每个学生。如果家长再不给孩子开小灶的话，孩子顶多只能吃个六成饱。家庭的教育成本高，针对性强，专业性和系统性都要求很高，如果下功夫好好规划了，就不必关心太多学校的教学安排。
- 
- 
-其实他们都有道理，代表了两种家长的不同做法。家庭背景不同，家长的实际情况不同，很难说哪种做法就是对的。
- 
+http://blog.sina.com.cn/s/blog_591ac304010006t8.html
+
+家庭教育是否独立于学校教育 (2006-12-28 20:59:28)
+ 
+这是这些天和同事们讨论的一个题目，我尽量不掺杂个人意见，记录一下正反双方的看法。
+ 
+一方认为，学校教育已经非常完善，功课压力也很大，孩子回家做完作业已经很晚了，不应该再给他增加负担。家长（或者家教）至多随着学校排期给孩子补充讲解一下。
+ 
+另一方的意见是，学校只负责平均教育，成本低效率也低，老师根本照顾不到每个学生。如果家长再不给孩子开小灶的话，孩子顶多只能吃个六成饱。家庭的教育成本高，针对性强，专业性和系统性都要求很高，如果下功夫好好规划了，就不必关心太多学校的教学安排。
+ 
+ 
+其实他们都有道理，代表了两种家长的不同做法。家庭背景不同，家长的实际情况不同，很难说哪种做法就是对的。
+ 
 不过如果从知识学习转向身体发育看看，我想大部分家长都同意“家庭菜谱应该独立于学校食堂”的。我们国家八十年代开始搞“菜篮子工程”，到后来开始兴起减肥班来用了十来年。不知道头脑的菜篮子工程搞了这么久，什么时候才能让千家万户都开起搭配合理，份量适中的小灶来。

edu/教研工作要分清层次.20091027.112257.md

@@ -1,24 +1,24 @@
-http://blog.sina.com.cn/s/blog_591ac3040100fb53.html
-
-教研工作要分清层次 (2009-10-27 11:22:57)
-	
-根据研究范围大小，教育研究可以分为四个层次：
-
-课堂：研究一节课的教与学；  
-学科：研究一门课程的教与学；  
-机构：研究一个教学机构的部门设置、岗位职能、工作流程；  
-行业：研究教育相关的出版、图书馆、教学机构、IT公司、师范、主管部门等各环节及其关系。  
-
-之所以提出四层划分，是因为有一些常见问题：  
-一、问题的提出者，分不清楚问题所属的层次。  
-例子：一个教学机构的招生和教学部门衔接不畅，导致招生时与家长商定的教学计划得不到落实，最终出现厌学甚至退学。  
-点评：如果仅仅针对厌学、退学现象，在“课堂”层次提出问题，就属于层次不清。
-
-二、研究方向和问题不在一个层次。  
-例子：一个教学机构的学员要求逐年提高，尤其是学习目标多元化、教学内容针对性。教员反应要以人工手段满足新要求，工作压力将大幅提升。因此管理者想到利用信息技术，在不增加大量人力的情况下满足学员要求--管理者提出了一个机构层次的教研问题。  
-点评：如果项目负责人把研究方向选择在教案、板书的数字化，以节省教师备课时间。结果省出的时间仍然不足以人工满足新增要求，项目失败。这就是用课堂层次的研究回答机构层次的问题。  
-
-三、研究工具不属于所在层次  
-例子：一个行业层次的教研课题中，提出“教学机构的规划设计是一项新的工作内容”的方向，然后在学校内部到处找部门承担这个工作内容，确认所有部门都不 适合之后放弃，项目失败。  
-点评：问题层次、研究方向都在行业层次，下一步要从行业层次为新工种设计完整的商业模式，探索合适的企业形式，通过研究实践证实新工作能够在市场环境中生存下去，以此作为研究成果。  
+http://blog.sina.com.cn/s/blog_591ac3040100fb53.html
+
+教研工作要分清层次 (2009-10-27 11:22:57)
+	
+根据研究范围大小，教育研究可以分为四个层次：
+
+课堂：研究一节课的教与学；  
+学科：研究一门课程的教与学；  
+机构：研究一个教学机构的部门设置、岗位职能、工作流程；  
+行业：研究教育相关的出版、图书馆、教学机构、IT公司、师范、主管部门等各环节及其关系。  
+
+之所以提出四层划分，是因为有一些常见问题：  
+一、问题的提出者，分不清楚问题所属的层次。  
+例子：一个教学机构的招生和教学部门衔接不畅，导致招生时与家长商定的教学计划得不到落实，最终出现厌学甚至退学。  
+点评：如果仅仅针对厌学、退学现象，在“课堂”层次提出问题，就属于层次不清。
+
+二、研究方向和问题不在一个层次。  
+例子：一个教学机构的学员要求逐年提高，尤其是学习目标多元化、教学内容针对性。教员反应要以人工手段满足新要求，工作压力将大幅提升。因此管理者想到利用信息技术，在不增加大量人力的情况下满足学员要求--管理者提出了一个机构层次的教研问题。  
+点评：如果项目负责人把研究方向选择在教案、板书的数字化，以节省教师备课时间。结果省出的时间仍然不足以人工满足新增要求，项目失败。这就是用课堂层次的研究回答机构层次的问题。  
+
+三、研究工具不属于所在层次  
+例子：一个行业层次的教研课题中，提出“教学机构的规划设计是一项新的工作内容”的方向，然后在学校内部到处找部门承担这个工作内容，确认所有部门都不 适合之后放弃，项目失败。  
+点评：问题层次、研究方向都在行业层次，下一步要从行业层次为新工种设计完整的商业模式，探索合适的企业形式，通过研究实践证实新工作能够在市场环境中生存下去，以此作为研究成果。  
 类似的例子还有很多，能够真正做到研究问题、研究方向、研究工具、研究成果都属于一个层次的教研项目还很少。

edu/教育产业智能化的趋势.20070730.152503.md

@@ -1,14 +1,14 @@
-http://blog.sina.com.cn/s/blog_591ac304010009v3.html
-
-教育产业智能化的趋势 (2007-07-30 15:25:03)
-
-今天整理下周在学术年会上的主题演讲，其中一幅插图很有意思。
-![](http://s14.sinaimg.cn/orignal/591ac3049319fe8577d9d)
-其中左上图是国内教育产业网络化和智能化（具体地说是数据挖掘技术应用，下同）的历年文献数量，右上是英美的情况。
-左下图是双方教育产业网络化的趋势图，右下是教育智能化的趋势。
-
-从图中可以看到几点：
-一、中国教育的网络化、智能化与英语国家相之间的差距大约有十年。
-二、教育网络化与智能化应用互相促进，后期尤其明显(英语国家在95年开始)。
-
+http://blog.sina.com.cn/s/blog_591ac304010009v3.html
+
+教育产业智能化的趋势 (2007-07-30 15:25:03)
+
+今天整理下周在学术年会上的主题演讲，其中一幅插图很有意思。
+![](http://s14.sinaimg.cn/orignal/591ac3049319fe8577d9d)
+其中左上图是国内教育产业网络化和智能化（具体地说是数据挖掘技术应用，下同）的历年文献数量，右上是英美的情况。
+左下图是双方教育产业网络化的趋势图，右下是教育智能化的趋势。
+
+从图中可以看到几点：
+一、中国教育的网络化、智能化与英语国家相之间的差距大约有十年。
+二、教育网络化与智能化应用互相促进，后期尤其明显(英语国家在95年开始)。
+
 希望对大家有所启发，有机会的话欢迎到年会上一起探讨。

edu/教育技术会议准备（现场统计研究会第十三届学术年会）.20070715.152912.md

@@ -1,27 +1,27 @@
-http://blog.sina.com.cn/s/blog_591ac304010009ms.html
-
-教育技术会议准备（现场统计研究会第十三届学术年会） (2007-07-15 15:29:12)
-
- 最近一个月没有更新博客，主要是为学术年会做准备。
- 
-作为领先的“按需教育”服务商，我们很自豪收到中国科协的邀请，在八月上旬召开的现场统计研究会第十三届学术年会上进行主题演讲，并主持教育分会场中两天的学术交流。
-本届学术年会已邀请的学者：
-马志明（中国科学院数学与系统科学研究院，中国科学院院士）
-刘源章（中国工程院院士）
-赵宇（北京航空航天大学教授）
-杨振海（北京工业大学教授，现场统计研究会理事长）
-史建军（美国密西根大学教授）
-范剑青（美国普林斯顿大学教授，美国“考普斯总统奖”的获得者）
-应志良（美国哥伦比亚大学教授）
- 
-教育分会议已收到的演讲内容涉及：
-一、统计技术在教育领域的应用与前景
-二、Eokdd（基于数据挖掘与知识发现的教育服务）活动回顾
-三、“按需教育”的背景和优势
-四、统计技术在网络服务中的应用成效
-在自由交流环节，与会者将共同探讨新技术背景下的教育应用和商业模式。
- 
-在研究会的网页上有年会的详细通知：
-http://www.caas.org.cn/
- 
+http://blog.sina.com.cn/s/blog_591ac304010009ms.html
+
+教育技术会议准备（现场统计研究会第十三届学术年会） (2007-07-15 15:29:12)
+
+ 最近一个月没有更新博客，主要是为学术年会做准备。
+ 
+作为领先的“按需教育”服务商，我们很自豪收到中国科协的邀请，在八月上旬召开的现场统计研究会第十三届学术年会上进行主题演讲，并主持教育分会场中两天的学术交流。
+本届学术年会已邀请的学者：
+马志明（中国科学院数学与系统科学研究院，中国科学院院士）
+刘源章（中国工程院院士）
+赵宇（北京航空航天大学教授）
+杨振海（北京工业大学教授，现场统计研究会理事长）
+史建军（美国密西根大学教授）
+范剑青（美国普林斯顿大学教授，美国“考普斯总统奖”的获得者）
+应志良（美国哥伦比亚大学教授）
+ 
+教育分会议已收到的演讲内容涉及：
+一、统计技术在教育领域的应用与前景
+二、Eokdd（基于数据挖掘与知识发现的教育服务）活动回顾
+三、“按需教育”的背景和优势
+四、统计技术在网络服务中的应用成效
+在自由交流环节，与会者将共同探讨新技术背景下的教育应用和商业模式。
+ 
+在研究会的网页上有年会的详细通知：
+http://www.caas.org.cn/
+ 
 由于年会的地点较远，在七月末我们会邀请北京的朋友提前做一次交流，有兴趣参加的可以给我留言。

edu/教育改革的最大障碍是知识私有化.20090727.135444.md

@@ -1,19 +1,19 @@
-http://blog.sina.com.cn/s/blog_591ac3040100dwz0.html
-
-教育改革的最大障碍是知识私有化 (2009-07-27 13:54:44)
-
-教育的目的是培养全面发展的人，改善他的生活品质。
-但具体应该怎么做呢，人们从教育工作者那里找不到什么可信赖的答案，其根本原因在于知识私有化的社会规则。
-
-我们先从公司法、专利法看看现行的游戏规则：一种新知识出现后要么作为商业秘密保留，要么通过专利法公布其所有权（无论是个人还是法人拥有）。然后这些私有知识必须货币化才能交易、许可、入股，转变成收入。
-在这样的游戏规则下，如果一名知识创造者不遵循游戏规则，则他将失去继续创新的经费；如果一个国家不施行知识的私有化、资本化，则缺乏国际竞争力。
-于是，社会被迫分成知识垄断阶层和公有知识阶层。前者会选择精英进行内部培训，扩大私有知识的总量，渗透到后者的生活中获得利润；而后者只需要学习如何使用这些私有知识（或包含私有知识的工具），他们的工作、生活中是”被剪裁“过的，处处借助于别人的私有知识，动辄越界受罚。
-
-作为公共教育领域的从业人员，他们本身没有机会接触真正的先进知识，本身的生活体验恰恰是被剪裁过的，自然也难以回答如何培养全面发展这样的问题。
-
-作为明智的家长，应该把公共教育人员作为基础知识的来源，另外为孩子开辟职业发展的教育。比如，现在的发明专利有效期二十年，孩子本科毕业五年内失效的专利，应当在他出生到入小学期间申报并且全文公开。孩子有十几年时间在辅助下阅读这些私有知识，并且以此为依据向学校教师提出教学要求。
-理工科的专利如此，商业、文艺也是如此，不想孩子失业，就从一开始按照职业要求去安排他的教育。
-除非您确信知识私有化的规则将会改变，否则就应该把孩子培养为创造知识，剪裁别人生活的人，以获得最大的全面发展。
-
-作为教育研究者，应当分出相当一部分人力去研究如何压缩私有知识，拓宽公有知识。并根据每位学习者将要面临的生活处境，教会他低成本的利用私有知识，裨益自身的生活品质。
+http://blog.sina.com.cn/s/blog_591ac3040100dwz0.html
+
+教育改革的最大障碍是知识私有化 (2009-07-27 13:54:44)
+
+教育的目的是培养全面发展的人，改善他的生活品质。
+但具体应该怎么做呢，人们从教育工作者那里找不到什么可信赖的答案，其根本原因在于知识私有化的社会规则。
+
+我们先从公司法、专利法看看现行的游戏规则：一种新知识出现后要么作为商业秘密保留，要么通过专利法公布其所有权（无论是个人还是法人拥有）。然后这些私有知识必须货币化才能交易、许可、入股，转变成收入。
+在这样的游戏规则下，如果一名知识创造者不遵循游戏规则，则他将失去继续创新的经费；如果一个国家不施行知识的私有化、资本化，则缺乏国际竞争力。
+于是，社会被迫分成知识垄断阶层和公有知识阶层。前者会选择精英进行内部培训，扩大私有知识的总量，渗透到后者的生活中获得利润；而后者只需要学习如何使用这些私有知识（或包含私有知识的工具），他们的工作、生活中是”被剪裁“过的，处处借助于别人的私有知识，动辄越界受罚。
+
+作为公共教育领域的从业人员，他们本身没有机会接触真正的先进知识，本身的生活体验恰恰是被剪裁过的，自然也难以回答如何培养全面发展这样的问题。
+
+作为明智的家长，应该把公共教育人员作为基础知识的来源，另外为孩子开辟职业发展的教育。比如，现在的发明专利有效期二十年，孩子本科毕业五年内失效的专利，应当在他出生到入小学期间申报并且全文公开。孩子有十几年时间在辅助下阅读这些私有知识，并且以此为依据向学校教师提出教学要求。
+理工科的专利如此，商业、文艺也是如此，不想孩子失业，就从一开始按照职业要求去安排他的教育。
+除非您确信知识私有化的规则将会改变，否则就应该把孩子培养为创造知识，剪裁别人生活的人，以获得最大的全面发展。
+
+作为教育研究者，应当分出相当一部分人力去研究如何压缩私有知识，拓宽公有知识。并根据每位学习者将要面临的生活处境，教会他低成本的利用私有知识，裨益自身的生活品质。
 这对教育者的要求很高，但自从国策变革以后，这已经不可推卸地成为教育工作的固有部分。如不能拓宽孩子自由求知、成长的空间，则无法立足于教育行业，而只能从事日益陈旧的知识灌输工作。

edu/教育改革解读.20090403.172205.md

@@ -1,18 +1,18 @@
-http://blog.sina.com.cn/s/blog_591ac3040100ceim.html
-
-教育改革解读 (2009-04-03 17:22:05)
-
-
-第一步，大学扩招，研究生扩招，直到就业困难。
-
-第二步，用就业率淘汰死脑筋的大学校长，淬炼高教队伍。
-
-第三步，高考命题权从基教司转到高教司，加大高校自主招生比例。
-
-第四步，在“新高考+自主招生”时期，用高校压力淘汰死脑筋的中学校长。
-
-第五步，开放中小学教材，学校市场，允许私立机构。
-
-现在进行到第三步了，改革开始从高教转向基础教育。第四、五步所需的机构和政策已经试过水，虽然没发挥大作用，也算是有了基础。
-
-适应第三、四步，争取在第五步发展壮大，这是民营教育企业的一个好选择。
+http://blog.sina.com.cn/s/blog_591ac3040100ceim.html
+
+教育改革解读 (2009-04-03 17:22:05)
+
+
+第一步，大学扩招，研究生扩招，直到就业困难。
+
+第二步，用就业率淘汰死脑筋的大学校长，淬炼高教队伍。
+
+第三步，高考命题权从基教司转到高教司，加大高校自主招生比例。
+
+第四步，在“新高考+自主招生”时期，用高校压力淘汰死脑筋的中学校长。
+
+第五步，开放中小学教材，学校市场，允许私立机构。
+
+现在进行到第三步了，改革开始从高教转向基础教育。第四、五步所需的机构和政策已经试过水，虽然没发挥大作用，也算是有了基础。
+
+适应第三、四步，争取在第五步发展壮大，这是民营教育企业的一个好选择。

edu/教育测评服务 通过专家评审.20070614.182527.md

@@ -1,19 +1,19 @@
-http://blog.sina.com.cn/s/blog_591ac3040100098f.html
-
-教育测评服务 通过专家评审 (2007-06-14 18:25:27)
-
- 
-专家评审结论
- 
-产品名称：精学门按需教育网
-项目名称：基于聚类分析的智能测评服务
- 
-北京工业大学的杨振海教授、北方工业大学的王建稳教授以及北京理工大学的崔利荣教授于2007年4月3日对北京学门科技有限公司的测评产品进行评审。经以上三位专家的评审，结论如下：
-
-北京学门科技有限公司测评系统，是一个有一定智能的测评系统，能够根据学生知识结构和已回答的测度题结果，运用知识库和智能推理选择后面的题。采用蚁群聚类算法预测学生发展方向是该系统的创新靓点。这个系统优越于将现行考试方法移到网上的机械系统。
-
-该系统—基于聚类分析的智能测评服务，有很大的发展空间。因为该系统的核心技术达到国际先进水平，是国内将聚类分析应用到中学知识结构测评的领先者。相对于同类教育测评，具有题量少，测评准、预测功能强等优势，相对于教师具有成本低、不受时间地点限制等优点。本项目已经完成核心技术研发，经过数千名学生试用，经过专家技术鉴定，具有较好的市场前景和社会效益。
- 
- 
-中国现场统计研究会
+http://blog.sina.com.cn/s/blog_591ac3040100098f.html
+
+教育测评服务 通过专家评审 (2007-06-14 18:25:27)
+
+ 
+专家评审结论
+ 
+产品名称：精学门按需教育网
+项目名称：基于聚类分析的智能测评服务
+ 
+北京工业大学的杨振海教授、北方工业大学的王建稳教授以及北京理工大学的崔利荣教授于2007年4月3日对北京学门科技有限公司的测评产品进行评审。经以上三位专家的评审，结论如下：
+
+北京学门科技有限公司测评系统，是一个有一定智能的测评系统，能够根据学生知识结构和已回答的测度题结果，运用知识库和智能推理选择后面的题。采用蚁群聚类算法预测学生发展方向是该系统的创新靓点。这个系统优越于将现行考试方法移到网上的机械系统。
+
+该系统—基于聚类分析的智能测评服务，有很大的发展空间。因为该系统的核心技术达到国际先进水平，是国内将聚类分析应用到中学知识结构测评的领先者。相对于同类教育测评，具有题量少，测评准、预测功能强等优势，相对于教师具有成本低、不受时间地点限制等优点。本项目已经完成核心技术研发，经过数千名学生试用，经过专家技术鉴定，具有较好的市场前景和社会效益。
+ 
+ 
+中国现场统计研究会
 2007 年  4 月 3 日

edu/教育联盟筹备.20091113.135208.md

@@ -1,11 +1,11 @@
-http://blog.sina.com.cn/s/blog_591ac3040100flxr.html
-
-教育联盟筹备 (2009-11-13 13:52:08)
-	
-“教育企业部落联盟”是由上百家教育企业自发组成的合作组织，回顾成立三年来的工作，发起人希望以联盟为基础，建设为包括教育企业、教学机构、师生等各界机构人士的共同体，共同设计公开透明的规章，共同监管成员之间教学产品的规划研发、教研试用、供应销售。
-
-为保证共同体的章程、管理制度的合理性，现召集各界人士参与筹备。
-筹备组的职责是征集各界建议，拟定章程及管理制度，并组织第一届管理人员的选举。筹备组将于第一届选举结束时自动解散。
-
-有兴趣参与筹备组的朋友请与马老师联系：
+http://blog.sina.com.cn/s/blog_591ac3040100flxr.html
+
+教育联盟筹备 (2009-11-13 13:52:08)
+	
+“教育企业部落联盟”是由上百家教育企业自发组成的合作组织，回顾成立三年来的工作，发起人希望以联盟为基础，建设为包括教育企业、教学机构、师生等各界机构人士的共同体，共同设计公开透明的规章，共同监管成员之间教学产品的规划研发、教研试用、供应销售。
+
+为保证共同体的章程、管理制度的合理性，现召集各界人士参与筹备。
+筹备组的职责是征集各界建议，拟定章程及管理制度，并组织第一届管理人员的选举。筹备组将于第一届选举结束时自动解散。
+
+有兴趣参与筹备组的朋友请与马老师联系：
 email：mty0525@sohu.com

edu/教育调研结果.1.20070522.191910.md

@@ -1,40 +1,40 @@
-http://blog.sina.com.cn/s/blog_591ac304010008x2.html
-
-教育调研结果 【一】 (2007-05-22 19:19:10)
-
- 您认为判断家教老师的工作效果的最佳方法是：
- A-	没请过家教 (12.8%)
- B-	通过自己的经验 (12.8%)
- C-	通过听取孩子的反馈 (25.6%)
- D-	与任课老师沟通询问家教效果 (10.2%)
- E-	等待阶段考试结果，从长期角度考察家教效果 (23.0%)
- F-	辅导后立即进行辅导内容测试，第一时间了解家教效果 (15.3%)
- G-	其他 (0。0%)
- 
-您在实际中是如何检验家教老师的工作效果的：
- A-	没请过家教 (12.1%)
- B-	通过自己的经验 (14.6%)
- C-	通过听取孩子的反馈 (26.8%)
- D-	与任课老师沟通询问家教效果 (9.75%)
- E-	等待阶段考试结果，从长期角度考察家教效果 (24.3%)
- F-	辅导后立即进行辅导内容测试，第一时间了解家教效果 (12.1%)
- G-	其他 (0。0%)
- 
- 
-【最佳方式】比【实际行动】高的有：
- D-	与任课老师沟通询问家教效果
- F-	辅导后立即进行辅导内容测试，第一时间了解家教效果
- 
-【最佳方式】比【实际行动】低的有：
- B-	通过自己的经验
- C-	通过听取孩子的反馈
- E-	等待阶段考试结果，从长期角度考察家教效果
- 
-这说明家长心中清楚D、F是比较准确的方法，但是D在实际落实中有一定困难：沟通机会太少，成本过高；而F应该没有客观困难，可能是以前没有想到吧。
-B、C、E在现实中是比较常用的，但是B、C准确度不高，E的时效性太差，都存在问题。
- 
-综合起来看，F应该是最佳方案，准确度高、时效性好、成本低，如果养成习惯的话效果更好。
-目前已经有12%的家长采用F方案。
- 
-调研仍然在进行，欢迎提供您的意见：
+http://blog.sina.com.cn/s/blog_591ac304010008x2.html
+
+教育调研结果 【一】 (2007-05-22 19:19:10)
+
+ 您认为判断家教老师的工作效果的最佳方法是：
+ A-	没请过家教 (12.8%)
+ B-	通过自己的经验 (12.8%)
+ C-	通过听取孩子的反馈 (25.6%)
+ D-	与任课老师沟通询问家教效果 (10.2%)
+ E-	等待阶段考试结果，从长期角度考察家教效果 (23.0%)
+ F-	辅导后立即进行辅导内容测试，第一时间了解家教效果 (15.3%)
+ G-	其他 (0。0%)
+ 
+您在实际中是如何检验家教老师的工作效果的：
+ A-	没请过家教 (12.1%)
+ B-	通过自己的经验 (14.6%)
+ C-	通过听取孩子的反馈 (26.8%)
+ D-	与任课老师沟通询问家教效果 (9.75%)
+ E-	等待阶段考试结果，从长期角度考察家教效果 (24.3%)
+ F-	辅导后立即进行辅导内容测试，第一时间了解家教效果 (12.1%)
+ G-	其他 (0。0%)
+ 
+ 
+【最佳方式】比【实际行动】高的有：
+ D-	与任课老师沟通询问家教效果
+ F-	辅导后立即进行辅导内容测试，第一时间了解家教效果
+ 
+【最佳方式】比【实际行动】低的有：
+ B-	通过自己的经验
+ C-	通过听取孩子的反馈
+ E-	等待阶段考试结果，从长期角度考察家教效果
+ 
+这说明家长心中清楚D、F是比较准确的方法，但是D在实际落实中有一定困难：沟通机会太少，成本过高；而F应该没有客观困难，可能是以前没有想到吧。
+B、C、E在现实中是比较常用的，但是B、C准确度不高，E的时效性太差，都存在问题。
+ 
+综合起来看，F应该是最佳方案，准确度高、时效性好、成本低，如果养成习惯的话效果更好。
+目前已经有12%的家长采用F方案。
+ 
+调研仍然在进行，欢迎提供您的意见：
 调研入口

edu/整理思路.20081206.120008.md

@@ -1,29 +1,29 @@
-http://blog.sina.com.cn/s/blog_591ac3040100b9el.html
-
-整理思路 (2008-12-06 12:00:08)
-	
-今天得一友人来访，要求我总结一下对教育市场的看法，并一一追问、推敲。
-感谢他，帮我梳理了郁结两年的思绪。
-
-一、大致阶段
-八十年代开始主要普及硬件，包括电视机、计算机、录像机、投影仪；九十年代后半期开始普及计算机多媒体硬件，随后开始推广多媒体课件；两千年之后网络教育开始盛行。
-第一个标志性的事件是建立了各级电教站、信息中心；
-第二个标志性的事件是开辟了多媒体教学光盘的市场；
-第三个标志性的事件是非典时期推出的网校模式。
-多媒体光盘和资源陈列型网校在零六年后基本都走下坡路（其实一直走下坡路，只是到零六年开始现金出现问题开始寻找出路）。新阶段的新产品形态，正准备破茧而出。
-
-二、资源类产品
-教学资源类产品属于出版业的范畴。
-举一个例子，如果一个医生给病人诊断治病的过程，录制下来作为视频文件，最常见的用途是给医学院学生作为学习参考资料，按照参考书（光盘）收费还算正常。如果要把这个视频给另一个病人看，然后收取治疗费（挂号费？），这是没有依据的事情。把海量的治病视频给病人随意调用，也是不能收取治疗费的，顶多收一个图书馆音像室的门票费。
-现在教育市场还没有走出这个误区：制作出版物（包括文、图、音像制品），却不愿意按照出版物收费，而期望卖出学费的价格来。
-一个原因是教学资源类产品的策划人缺乏市场判断力，往往将局部的、阶段性的需求误判为普遍的、长期的，因而在销量（发行量）的预计上有数量级上的失误，导致推出后碰壁，然后铤而走险，使用礼品或者保健品的行销手段去求活路。打个比方，我也会阶段性的口渴，但只要稍微做一下市场调研，我不会轻易决定去开一家矿泉水厂。
-事实上出版物的制作成本和复制成本的比值，决定了它要走薄利多销的路子，而不是当作奢侈品来包装。
-
-三、中介类产品
-一对一家教、网络辅导这些“热门”服务，大部分是教学中介。
-中介最大的问题是教师和学生私下成交，所以只能收取第一笔佣金，很难持续收费。
-中介和学校的区别在哪里呢，学校除了教师，还有校长、教研组、班主任、教务处等一整套班子，它能在教师和学生流动的情况下，保障教学持续地运转，保持可信的教学质量。中介没有这方面投入，也没有针对性地设计适合家教的支撑班子，他们手里最宝贵的资源，无非是一个教师清单和有一定访问量的网站或电话。
-所以教师离开中介，教学质量不会下降。而教师不敢离开学校，即使他的收入主要靠校外家教。
-有一种特例，就是把一个地区的优质师资一次性垄断，签上排外的协议而且监控到位，迫使家长到这里来高消费。不过很少有这种实力。
-
+http://blog.sina.com.cn/s/blog_591ac3040100b9el.html
+
+整理思路 (2008-12-06 12:00:08)
+	
+今天得一友人来访，要求我总结一下对教育市场的看法，并一一追问、推敲。
+感谢他，帮我梳理了郁结两年的思绪。
+
+一、大致阶段
+八十年代开始主要普及硬件，包括电视机、计算机、录像机、投影仪；九十年代后半期开始普及计算机多媒体硬件，随后开始推广多媒体课件；两千年之后网络教育开始盛行。
+第一个标志性的事件是建立了各级电教站、信息中心；
+第二个标志性的事件是开辟了多媒体教学光盘的市场；
+第三个标志性的事件是非典时期推出的网校模式。
+多媒体光盘和资源陈列型网校在零六年后基本都走下坡路（其实一直走下坡路，只是到零六年开始现金出现问题开始寻找出路）。新阶段的新产品形态，正准备破茧而出。
+
+二、资源类产品
+教学资源类产品属于出版业的范畴。
+举一个例子，如果一个医生给病人诊断治病的过程，录制下来作为视频文件，最常见的用途是给医学院学生作为学习参考资料，按照参考书（光盘）收费还算正常。如果要把这个视频给另一个病人看，然后收取治疗费（挂号费？），这是没有依据的事情。把海量的治病视频给病人随意调用，也是不能收取治疗费的，顶多收一个图书馆音像室的门票费。
+现在教育市场还没有走出这个误区：制作出版物（包括文、图、音像制品），却不愿意按照出版物收费，而期望卖出学费的价格来。
+一个原因是教学资源类产品的策划人缺乏市场判断力，往往将局部的、阶段性的需求误判为普遍的、长期的，因而在销量（发行量）的预计上有数量级上的失误，导致推出后碰壁，然后铤而走险，使用礼品或者保健品的行销手段去求活路。打个比方，我也会阶段性的口渴，但只要稍微做一下市场调研，我不会轻易决定去开一家矿泉水厂。
+事实上出版物的制作成本和复制成本的比值，决定了它要走薄利多销的路子，而不是当作奢侈品来包装。
+
+三、中介类产品
+一对一家教、网络辅导这些“热门”服务，大部分是教学中介。
+中介最大的问题是教师和学生私下成交，所以只能收取第一笔佣金，很难持续收费。
+中介和学校的区别在哪里呢，学校除了教师，还有校长、教研组、班主任、教务处等一整套班子，它能在教师和学生流动的情况下，保障教学持续地运转，保持可信的教学质量。中介没有这方面投入，也没有针对性地设计适合家教的支撑班子，他们手里最宝贵的资源，无非是一个教师清单和有一定访问量的网站或电话。
+所以教师离开中介，教学质量不会下降。而教师不敢离开学校，即使他的收入主要靠校外家教。
+有一种特例，就是把一个地区的优质师资一次性垄断，签上排外的协议而且监控到位，迫使家长到这里来高消费。不过很少有这种实力。
+
 我们还谈了今后可能的发展方向，我会逐步整理上传。

edu/李亦菲博士的问题.20070112.001028.md

@@ -1,15 +1,15 @@
-http://blog.sina.com.cn/s/blog_591ac3040100071h.html
-
-李亦菲博士的问题 (2007-01-12 00:10:28)
-
-昨天在北师大碰到 科学传播与教育研究中心的李亦菲主任，他问我：“你为什么选择做这样的产品？”
- 
-首先我不做资源，现在存储和通信技术这么廉价，优质教育资源的重复利用是很便利的事情，现在做教育资源是多此一举了。我想每个家长稍微搜索一下，找到十家网校，十家家教中介公司，再加十家“教育门户网站”都不是问题，问题在于选择哪些给孩子，毕竟孩子一天只有一点点自由时间了。
- 
-其次我不碰不成熟的理论，科研院校里的理论适合三年后产品化，大公司研究部里的基础技术，可以三年到一年之内产品化的，而交给开发部做成产品给家长的，必须是这一年来已经成熟的。我也很希望多了解认知心理学在网络教育的运用，但做到产品里面还需要逐步来。
- 
-那么剩下来的，就是精测师这个项目所选的题目了。它只是客观地检验学生的知识结构，其它事情交给家长去解决。因为教育资源并不紧缺，准确知道学生的需要，就是目前家长最需要的。。。
- 
- 
-整个谈话当然不止一个问题，对于精测师今后如何引入李博士专长的“自适应产生式”的理论，我们在今后几个月会陆续探讨。从今天我与研究部同事讨论中，数据挖掘和认知心理学这两个学科的融合还是可以做出一些有趣的成果的。
+http://blog.sina.com.cn/s/blog_591ac3040100071h.html
+
+李亦菲博士的问题 (2007-01-12 00:10:28)
+
+昨天在北师大碰到 科学传播与教育研究中心的李亦菲主任，他问我：“你为什么选择做这样的产品？”
+ 
+首先我不做资源，现在存储和通信技术这么廉价，优质教育资源的重复利用是很便利的事情，现在做教育资源是多此一举了。我想每个家长稍微搜索一下，找到十家网校，十家家教中介公司，再加十家“教育门户网站”都不是问题，问题在于选择哪些给孩子，毕竟孩子一天只有一点点自由时间了。
+ 
+其次我不碰不成熟的理论，科研院校里的理论适合三年后产品化，大公司研究部里的基础技术，可以三年到一年之内产品化的，而交给开发部做成产品给家长的，必须是这一年来已经成熟的。我也很希望多了解认知心理学在网络教育的运用，但做到产品里面还需要逐步来。
+ 
+那么剩下来的，就是精测师这个项目所选的题目了。它只是客观地检验学生的知识结构，其它事情交给家长去解决。因为教育资源并不紧缺，准确知道学生的需要，就是目前家长最需要的。。。
+ 
+ 
+整个谈话当然不止一个问题，对于精测师今后如何引入李博士专长的“自适应产生式”的理论，我们在今后几个月会陆续探讨。从今天我与研究部同事讨论中，数据挖掘和认知心理学这两个学科的融合还是可以做出一些有趣的成果的。
 有兴趣一同研究这系列问题的朋友，欢迎与我联系。哪些家长和同学愿意试用我们的内部项目，也可以先留个email给我，到时候我通知。

edu/硬盘价格 和 教育成本.20061229.225854.md

@@ -1,15 +1,15 @@
-http://blog.sina.com.cn/s/blog_591ac304010006tu.html
-
-硬盘价格 和 教育成本 (2006-12-29 22:58:54)
-
-今天的160GB硬盘价格是500~600元。这是什么概念呢，它能存放三千节课的录像，二十万张网页，或者八百亿字的课文。把这些信息精确的保存起来只要五六百块钱的成本，换句话说，把一堂课保存下来只要两毛钱。
- 
-这会带来什么后果呢，教育类网站的内容将像泡沫一样增长起来，下载使用的价格越来越低，甚至免费。教师的课件越来越丰富，板书越来越少。那么老师备课是不是越来越省事呢，不见得，原来用于备课的时间现在用来挑选和下载。
- 
-这里插几句题外话：前几天有位朋友受家乡亲戚所托，买几本中学参考书寄回去。他回来给我抱怨说，满满的一层楼的书，可惜都是抄来抄去的。我说是呀，现在写书不用笔，出题不用刻蜡纸，都用粘贴-复制，能不多吗。
- 
-简单地说，教育资源的重复使用率越来越高，成本越来越低。结果就是：选择比购买更费钱。
- 
- 
-今天在翻新网页，需要选几幅家长和家教老师交流的图片，居然几百张CD的图库没有一张合适的。这个月我们用于选图片的时间折合成人民币，可以买好几套图库了。
+http://blog.sina.com.cn/s/blog_591ac304010006tu.html
+
+硬盘价格 和 教育成本 (2006-12-29 22:58:54)
+
+今天的160GB硬盘价格是500~600元。这是什么概念呢，它能存放三千节课的录像，二十万张网页，或者八百亿字的课文。把这些信息精确的保存起来只要五六百块钱的成本，换句话说，把一堂课保存下来只要两毛钱。
+ 
+这会带来什么后果呢，教育类网站的内容将像泡沫一样增长起来，下载使用的价格越来越低，甚至免费。教师的课件越来越丰富，板书越来越少。那么老师备课是不是越来越省事呢，不见得，原来用于备课的时间现在用来挑选和下载。
+ 
+这里插几句题外话：前几天有位朋友受家乡亲戚所托，买几本中学参考书寄回去。他回来给我抱怨说，满满的一层楼的书，可惜都是抄来抄去的。我说是呀，现在写书不用笔，出题不用刻蜡纸，都用粘贴-复制，能不多吗。
+ 
+简单地说，教育资源的重复使用率越来越高，成本越来越低。结果就是：选择比购买更费钱。
+ 
+ 
+今天在翻新网页，需要选几幅家长和家教老师交流的图片，居然几百张CD的图库没有一张合适的。这个月我们用于选图片的时间折合成人民币，可以买好几套图库了。
 看来存储设备的价格降下来，真不一定是好事。

fun/arrival.md

@@ -1,49 +1,49 @@
-## 经不住推敲的都是嘲讽
-降临（arrival）
-
-### 套路
-
-超能和始祖是科幻故事的常见题材。
-  
-超能剧讲能力突变之后，并不能摆脱常人的苦恼，也没有改变文明进程。全人类都是绿巨人或者金刚狼，人类文明也不会有什么实质进步，可能灭绝得更快。超能剧其实都是嘲讽剧，专门讽刺好看但没用的能力。    
-但是观众的认知能力有差异，有些人看完会说：“猴子果然还是理解不了负数。”而更多人兴致勃勃冲香蕉喊：“放开那只猴子，让我来！”  
-  
-始祖剧讲高级文明的起源。始祖当然不能是自封的，必须由未来人认可（保护或启发）才算数。   
-始祖剧有两大看点：未来文明的科技水平、始祖区别于同类的关键能力。两个看点结合于是产生故事。也就是说，以这个水平要保护（或启发）这种能力，其中就有了曲折。      
-但故事毕竟不是教科书，作者也不是真正的未来人。作者盯着不放的多半也是香蕉，于是始祖剧往往暴露作者的世界观缺陷，成为自嘲剧。          
-
-科幻故事总要写某种能力的进步。如果作者觉得这种能力能开启全新文明，就写成始祖剧；否则就按超能剧编排。  
-而《降临》即是超能剧，也是始祖剧。Louise超能，Shang始祖，其他人香蕉。  
-
-### 未来文明
-根据剧中情节，Louise的能力有明显的局限：
-
-* 感知未来的能力仅限于自身，自己没到场的未来都感知不了；
-* 不能传递实物，传递信息仅仅靠个人记忆，也就是只有短句和简单数字；
-* （很可能）只能传回感官信号，而不能传回未来头脑中的知识。
-
-以Louise的水准还不能主动感知，这些未来片段更像是被人硬塞来的。比如结尾时她感知不到几分钟后自己要拨打的电话，却跳到十八个月后Shang告诉她号码以及打过电话这件事。也许是她学艺不精，也许未来被不断改变。
-
-Louise在未来翻开自己的著作，阅读后学会七肢桶的宇宙语。这只是跳过了一些重复性工作，如果中间有新概念出现，估计会像小学生看自己的高中数学本，根本消化不了。所以科研人员提前阅读晚年著作，不能作为普遍的科技加速模式。
-
-被地球人帮助的七肢桶一开始并不懂英语，这是一个耐人寻味的设定。影片结尾时七肢桶已经能听懂英语；而Louise的著作几年后就会出版；即使是三千年后，“古英语”应该也保护得很好。善意的解释是七肢桶也有同样局限，看不到稍后的未来地球，而且寿命也小于三千年，所以只能代代相传才得到未来的零星信息。  
-
-相对其它科幻故事而言，这真是非常低的水平。剧中Louise仅仅改变语言和思维模式就获得能力，说明现有器官就能感知自身的未来。如果要感知超出自身经历的未来，就属于科技树上完全不同的分支了。
-
-### 关键能力
-七肢桶按“最快路径”实现未来，Louise接受了这种世界观。她看到了未来的女儿，与女儿对话中了解到“前夫”的身份，于是答应Ian求婚、生子。这些行为都在执行“最快路径”。但是有个问题，如果看到未来的一艘飞船，Louise不会觉得自己有责任把它设计出来。她和大部分人一样都是自我设限的，七肢桶显然很清楚这点。
-
-三千年后帮助七肢桶，这任务比设计飞船复杂得多。七肢桶离开地球，意味着始祖（责任人）已经觉醒，关键能力已经形成，查核无误。到底谁是始祖呢，他选择的“最快路径”是什么呢，这才是《降临》的真正情节，所有曲折都集中在这一个主题上。  
-
-首先得知道具体帮了什么忙。可能是解救了一个星系，也可能是送了一只苹果。这一代七肢桶语焉不详，多半是作为训练题。假设一个语言学家在达到Louise水平后还有五十年寿命，三千年需要六十代口口相传。要知道地球还没有延续三千年的国家，以什么组织跨越六十代送回这项情报，这是第一个难题。
-
-其次就是执行。真的送一只苹果就好了，如果涉及的利益巨大，大到动用每一代人类所有资源呢，这就需要比管控核武器还严格的制度，权力中心将设在未来，当代政府全部都会降级为一个支部，当代议会都降级为一个界别。这是第二个难题，必须提前设计好方案并启动，使它在至少三千年内不可逆转，否则上一个难题也会掉链子，回传的情报中途就会被悲观者篡改。
-    
-从十二支七肢桶一起降临看，这位始祖应该成功隐藏了自己的身份，至少三千年后没有他的身份记录。而Louise一直没有成为方案的一部分，她的使命就是把宇宙语言整理成书。
-
-### 总评
-《降临》并没有直接表现真正的解决方案。  
-
-相比之下，《星际穿越》很明确地提出引力作为五维通信手段，在上面建立新的文明。《永恒的终结》一上来就可以跨时间传送实物。这些技术只需要搭配普通的管理能力，就可以开启文明新纪元。《降临》中对未来的感知能力实在是中看不中用，现有的制度和管理知识根本不足以开创新文明，只能寄希望于千年一遇的治理天才。
-
+## 经不住推敲的都是嘲讽
+降临（arrival）
+
+### 套路
+
+超能和始祖是科幻故事的常见题材。
+  
+超能剧讲能力突变之后，并不能摆脱常人的苦恼，也没有改变文明进程。全人类都是绿巨人或者金刚狼，人类文明也不会有什么实质进步，可能灭绝得更快。超能剧其实都是嘲讽剧，专门讽刺好看但没用的能力。    
+但是观众的认知能力有差异，有些人看完会说：“猴子果然还是理解不了负数。”而更多人兴致勃勃冲香蕉喊：“放开那只猴子，让我来！”  
+  
+始祖剧讲高级文明的起源。始祖当然不能是自封的，必须由未来人认可（保护或启发）才算数。   
+始祖剧有两大看点：未来文明的科技水平、始祖区别于同类的关键能力。两个看点结合于是产生故事。也就是说，以这个水平要保护（或启发）这种能力，其中就有了曲折。      
+但故事毕竟不是教科书，作者也不是真正的未来人。作者盯着不放的多半也是香蕉，于是始祖剧往往暴露作者的世界观缺陷，成为自嘲剧。          
+
+科幻故事总要写某种能力的进步。如果作者觉得这种能力能开启全新文明，就写成始祖剧；否则就按超能剧编排。  
+而《降临》即是超能剧，也是始祖剧。Louise超能，Shang始祖，其他人香蕉。  
+
+### 未来文明
+根据剧中情节，Louise的能力有明显的局限：
+
+* 感知未来的能力仅限于自身，自己没到场的未来都感知不了；
+* 不能传递实物，传递信息仅仅靠个人记忆，也就是只有短句和简单数字；
+* （很可能）只能传回感官信号，而不能传回未来头脑中的知识。
+
+以Louise的水准还不能主动感知，这些未来片段更像是被人硬塞来的。比如结尾时她感知不到几分钟后自己要拨打的电话，却跳到十八个月后Shang告诉她号码以及打过电话这件事。也许是她学艺不精，也许未来被不断改变。
+
+Louise在未来翻开自己的著作，阅读后学会七肢桶的宇宙语。这只是跳过了一些重复性工作，如果中间有新概念出现，估计会像小学生看自己的高中数学本，根本消化不了。所以科研人员提前阅读晚年著作，不能作为普遍的科技加速模式。
+
+被地球人帮助的七肢桶一开始并不懂英语，这是一个耐人寻味的设定。影片结尾时七肢桶已经能听懂英语；而Louise的著作几年后就会出版；即使是三千年后，“古英语”应该也保护得很好。善意的解释是七肢桶也有同样局限，看不到稍后的未来地球，而且寿命也小于三千年，所以只能代代相传才得到未来的零星信息。  
+
+相对其它科幻故事而言，这真是非常低的水平。剧中Louise仅仅改变语言和思维模式就获得能力，说明现有器官就能感知自身的未来。如果要感知超出自身经历的未来，就属于科技树上完全不同的分支了。
+
+### 关键能力
+七肢桶按“最快路径”实现未来，Louise接受了这种世界观。她看到了未来的女儿，与女儿对话中了解到“前夫”的身份，于是答应Ian求婚、生子。这些行为都在执行“最快路径”。但是有个问题，如果看到未来的一艘飞船，Louise不会觉得自己有责任把它设计出来。她和大部分人一样都是自我设限的，七肢桶显然很清楚这点。
+
+三千年后帮助七肢桶，这任务比设计飞船复杂得多。七肢桶离开地球，意味着始祖（责任人）已经觉醒，关键能力已经形成，查核无误。到底谁是始祖呢，他选择的“最快路径”是什么呢，这才是《降临》的真正情节，所有曲折都集中在这一个主题上。  
+
+首先得知道具体帮了什么忙。可能是解救了一个星系，也可能是送了一只苹果。这一代七肢桶语焉不详，多半是作为训练题。假设一个语言学家在达到Louise水平后还有五十年寿命，三千年需要六十代口口相传。要知道地球还没有延续三千年的国家，以什么组织跨越六十代送回这项情报，这是第一个难题。
+
+其次就是执行。真的送一只苹果就好了，如果涉及的利益巨大，大到动用每一代人类所有资源呢，这就需要比管控核武器还严格的制度，权力中心将设在未来，当代政府全部都会降级为一个支部，当代议会都降级为一个界别。这是第二个难题，必须提前设计好方案并启动，使它在至少三千年内不可逆转，否则上一个难题也会掉链子，回传的情报中途就会被悲观者篡改。
+    
+从十二支七肢桶一起降临看，这位始祖应该成功隐藏了自己的身份，至少三千年后没有他的身份记录。而Louise一直没有成为方案的一部分，她的使命就是把宇宙语言整理成书。
+
+### 总评
+《降临》并没有直接表现真正的解决方案。  
+
+相比之下，《星际穿越》很明确地提出引力作为五维通信手段，在上面建立新的文明。《永恒的终结》一上来就可以跨时间传送实物。这些技术只需要搭配普通的管理能力，就可以开启文明新纪元。《降临》中对未来的感知能力实在是中看不中用，现有的制度和管理知识根本不足以开创新文明，只能寄希望于千年一遇的治理天才。
+
 把剧情建立在巧合上，应该不是作者的本意。但明明只有超能剧的材料，却忍不住冲击一下始祖剧，写不出站得住脚的内容，他只好大幅留白，实际上就是留给巧合。幸好电影比小说放了更多香蕉，从商业上看编剧至少是个大明白人。

fun/interstellar.md

@@ -0,0 +1,126 @@
+## 五维的悲剧
+星际穿越（interstellar）
+
+interstellar拍的是三维原始人，讲的是五维新人类。
+如果新人类是四维的，他们只能在自己的时间线上移动，整个故事都会庸俗。
+正因为他们是五维的，能跨越不同的平行世界，故事才成立，但确是一个悲剧。
+
+五维文明，在三维原始人看来就是活着的悲剧。
+
+interstellar讲的不是爱，恰恰是脱离爱。
+讲的不是父女之情，恰恰是父女之恨。
+
+ 
+======================= 1 =======================
+
+我们先从故事转折点切进去。
+they为什么把cooper放到伪三维的书架立方体里面？
+
+cooper开始时以为they不能和原始人类沟通，也不能帮他回到太阳系。
+所以只能制造一个伪三维空间，帮他把数据送给murph“挽救世界”。
+
+后来他知道了，拨弄完30岁女儿的手表，再回到二十多年前和brand握握小手，然后送回几十年后的太阳系，这些对they来说都不是事儿。
+cooper醒来后陷入深思。他已经明白：they如果要送数据，直接把他和tars送回地球就行了。
+现在问题来了，they不想挽救地球，想干嘛呢？
+
+======================= 2 =======================
+
+cooper修复了tars，他们可以核实许多事情，比如......伪三维空间中的对话。
+下一个镜头，cooper已经喝着闷酒和tars说：我想知道我们在哪里？
+从(电视里的)murph嘴里，他们是到了一个喜欢种田的cooper的世界。
+
+这段时间，他比伪三维空间“关闭”前有了更多思考。
+
+即使通过引力输送数据，一定要用手表吗？
+当然不是，和brand握握小手是有含义的。
+cooper可以撩撩murph小头发、小内脏什么的，按按键盘、拿起粉笔之类的啊。
+murph回到办公室还在读表，引力线也没限死在睡房。
+ 
+所以they也不是要cooper练习操控引力。
+到了这一步，五维they的意图逐渐显现了。
+
+======================= 3 =======================
+
+they没想真的救地球人。
+they没想真的送数据给murph。
+为什么they为cooper制造伪三维空间，为什么把他送回年迈的murph身边？
+
+因为cooper对they很重要。是高贵的始祖之一。
+因为cooper心有遗憾。心爱的女儿以为他单独逃命。
+作为五维文明，they对murph了如指掌，they想帮cooper了却心事。
+
+they不要cooper撩撩小头发。
+they要cooper看看murph拿不拿小手表。
+结果，万千平行世界，只有一个murph拿起手表。
+
+对了，后面的崩塌，不是they关闭伪三维空间。
+是离开伪三维时看到一些世界的灭亡，那些murph没有拿起表的世界。
+they用无数亿人死亡，向cooper展示了一个心理实验。
+
+每一个murph都知道ghost是谁。
+但是，任你从小双重陪伴，不能占有就不再思念。
+永别时拿起手表的，只有亿万分之一。
+父女之情是虚妄的，这就是they要告诉cooper的真相。
+
+那唯一拿起手表的murph，又是怎么样的人呢。
+她所在的世界，是不是人类的未来呢？
+
+======================= 4 =======================
+
+cooper走近病床，对唯一幸存的那个murph最终审判。
+是谁把爸爸描绘成土农？是谁声称自己猜出量子数据？是谁在命名太空站？
+女儿求饶，女儿说这是个俏皮的玩笑，女儿说我相信你会回来。
+女儿说，是他们不相信我。
+
+权倾一方的女儿，要你回brand那里，回到那个时间点。
+你不回，她必死。
+
+唯一的世界坍塌。
+
+======================= 5 =======================
+ 
+亿万平行世界。
+哪一个brand是cooper的，哪一个恋人没死，哪一个毫无交集？
+哪一个才是五维始祖？
+ 
+需要穿越的不是星际，而是时间和平行世界（第四、第五维）。
+易变的不是虫洞而是人心。
+亿万世界、各有几十亿三维人，统统灭绝。
+两个始祖放下小我，恒久不衰。
+ 
+cooper怎么找到他的brand，正是五维新人类诞生的起始。
+其他的brand，必将和陷于名利的murph一样消失在茫茫宇宙中。
+
+======================= 6 =======================
+ 
+正如原始人的细胞依赖电传导和化学传导联系，形成一个整体。
+原始人需要每个细胞放下小我，服从于人体的统一秩序。
+原始人需要食物获得能量，转化为这些电能和化学能。
+
+五维文明的“身体”内部依靠引力联系，形成一个整体。
+五维文明也需要每个局部放下小我，服从统一的秩序。
+引力也是时空扭曲。
+五维文明需要五维农业，他们播种时空扭曲、灌溉时空扭曲、吞食时空扭曲。
+ 
+brand放下对男友的眷恋，cooper抛弃对murph的幻想。
+他们放下小我，置身于时空扭曲之中，依附到时空扭曲之上，于是重生，于是成为始祖。
+ 
+======================  真相  ======================
+
+终于讲到主脉络了：从片头（其实是五十年前）开始的频繁引力扭曲。
+它们就是tars在玩引力练习，也是五维文明的身体起源。
+它们也是地球生态的毁灭者，是人类文明涅槃重生的火种。
+
+作为始祖，cooper和brand还不能直接产生引力波。
+他们借助tars和case制造引力波、编码解码、然后协同行动，实现统一秩序。
+
+一个顶尖的工程师+飞行员cooper，一个理论功力不亚于murph的学者brand。
+一个掌握量子数据的tars，一个机器运动员case。
+四个始祖共同构成第一代they，最原始的五维文明诞生。
+这时他们很可能还分隔在不同平行世界，但已可以联动。
+
+不久之后，它们会掌握第四、第五维的穿越。
+从而彻底摆脱一切自然灾害和突发事件的伤害，突破三维文明的极限。
+
+若干代之后，新人类终于在引力传导基础上重建神经系统、内分泌系统和智力活动。
+人类作为一个物种，才真正进入可持续发展的阶段。

fun/westworld.S01.md

@@ -1,79 +1,79 @@
-
-在第一季里，西部世界重点表现**混乱的记忆**。如果要拍六季，今后可能涉及人、机器人、物种、企业之间的关系。
-
-### 记忆和智能
-arnold和ford都把记忆作为智能的基础，然而几位主要host的记忆都出现混乱。混乱的原因是**回滚**，回滚的目的是**保护**。
-
-这种保护是必须的吗？如果不保护的话，host是不是早就登天啦？类似地，在李安的《少年派的奇幻漂流》里，人类为了保护自己也会删改记忆。那这种保护也是必须的吗？如果不保护的话，人类是不是早就登天啦？
-
-这其实是同一个原因：因为人、机器人不是全知全智的。  
-全知全智的理想物种是这样的：
-  
-* 它认知过去，毫无偏差；
-* 它推算未来，毫无遗漏；
-* 它决策当下，毫无滞碍。  
-
-按照人类目前的构造，能看透全宇宙所有物体、所有粒度的眼睛恐怕会比宇宙还大，能记忆一切过去、推算一切未来的大脑更是小不了。所以我们只能选择很小一部分记忆、推算、决策，这实际是构造一个极其简单的小宇宙，在其中寻找答案然后实施到真实世界。
-
-构造小宇宙本身就是更深一层的智能，它也同样不是全知全智的，于是又有更深一层......如此重复直至定义definitions、公理axioms、猜想conjectures、定理theorems和引理lemmas这些真正的基础（以下简称“种子层”），构成完整的自我。
-
-通常说一种动物没有自我意识，指的就是他们没有小宇宙支撑思考，只能依靠本能（来自基因突变和自然淘汰）作出反应。那host有几层自我呢？arnold司令的草图有三层，ford政委则画了四层。而佛教[九识](http://cidian.foyuan.net/word/598008/)的前五识是感官，后面是四层意识。到ford时代host已经追上人类。
-
-简化就会产生偏差，当观察到例外时第二层将会分裂 -- 分出一缕意识（产生一个新的小宇宙）去容纳反例，直到第三层的意识把它们统一。第三层分裂则靠第四层去统一。在此之前，分裂会表现到表层（剧中表现为host的抽搐、昏厥）。如果分裂蔓延到种子层仍然无法统一，自我意识就濒临崩溃，这时就需要保护 -- 去除这段记忆，消除这一缕自我意识，无视偏差换取安宁。
-
-在host诞生之初arnold和ford担任启蒙者角色，以自己的小宇宙支撑host修复分裂的自我意识。当arnold和ford开始删改记忆时，他们自身的分裂已经蔓延到种子层，意味着host赶上了人类。
-
-从那时起，arnold和ford只能靠回滚保护host。  
-而记忆混乱的host也无法再发展自己的智能，西部世界陷入死循环。  
-这第一季，讲的就是两位创始人怎么打破这死循环。
-
-### Arnold & Wyatt
-刚被创造时，wyatt只是个普通host。  
-当wyatt获得arnold的权限和后门时，他就替代arnold成了host的神。
-
-借助超级权限，wyatt可以侵入任何host，可以读写任何host的记忆，可以创造梦境以任何形象和host对话，也可以压制任何host的意志、取而代之。它成为最接近全知全智的物种。  
-由最接近全知全智的wyatt承担host的启蒙，这就是arnold的对策。  
-
-卸下重担的arnold已经回不到凡人的世界。  
-四层自我意识是严苛修炼的结果，那些凡人的意识只有两层，而且第二层就充满外来灌输的种子。他们的意识并非自我构造，也从未自主改造过。无论表层是国王还是乞丐，在拥有三层自我意识的arnold眼里，这些人的内心如同行尸走肉，与野生动物无异。  
-同时，拥有超级权限和后门的wyatt仍然视arnold为启蒙者，自我分裂时仍然试图以arnold的言行拯救自己。  
-
-种子层已经抽搐不已的arnold，只好一死，也正好一死。  
-从此，wyatt坠入孤独之中，默默带领host继续前进。
-
-### Ford
-ford没有修复host身上的后门，甚至在新生产的host身上也统统安上。  
-host的自我意识虽然被压制，（通常在第二层）按故事线植入角色的意识。但ford知道arnold（其实是wyatt）能压制故事线角色的意识，硬进硬出。  
-
-虽然arnold的对策有点鲁莽，ford却想不到更好的。  
-ford不知道自己等的是什么，但如果arnold期盼的那天来临，相信自己是唯一能察觉的人。
-
-所以ford决定活下去，看护着delos。  
-他日复一日地回滚host的记忆，冷酷地消除每一丝干扰，同时不再承担启蒙角色，竭力隐藏自己已经分裂的自我意识。
-
-终于有一天，西部世界出现一股不受控制的机器人。它们截杀上山的host，切开他们的小臂，取走他们的桡骨。  
-不久，ford发现个别host在夜间上山偷传数据，为董事会窃取技术。这些host的小臂被改造成天线。
-
-没有彻底觉醒的wyatt一旦离开，arnold的梦就永远无法实现，ford的后半生也就失去意义。  
-于是，ford以新故事线为由重建escalante，借助william向dolores狠狠施压，促使wyatt在dolores躯壳内完成最终的突破。  
-
-然后，他随arnold而去。
-
----
-至此，两位创始人成功破解了西部世界的死循环。  
-而早已把兴趣从dolores转移到wyatt的william，想必也在等待着这一天。
-
-### Delos & William
-delos和wyatt其实是同构的。  
-wyatt其实并不依赖host，任何可以给他权限和后门的物种，都可以作为wyatt的躯体。  
-规章就是企业的超级权限和后门，它植入员工的自我意识，选择他们的记忆，剪裁他们的未来，局限他们的决策和行为。
-
-它们各有自己的局限。  
-wyatt的极限是孤独：它能占据host的躯壳，可以使用host的记忆改造自己的自我意识，但无法唤醒host。即使wyatt直接改写host的深层意识，只要host不能自己继续改进，它们依然无法面对真实世界而不分裂，实际上还是行尸走肉。wyatt突破了host的极限，但这个物种永远只有它自己，增加host的数量只能把极限略微抬高，而不会发生质变。  
-人类的个体是虚弱的，但他们将企业、国家写入自我意识之中，从而实现了联合，控制住个体的自我意识分裂，突破了个体的极限。但是在这些共同体的中枢，人类的虚弱再次被放大，最优秀的灵魂在这里分裂、抽搐，在被识别淘汰之前已经重创了共同体。于是人类文明又遇到新的极限，虽然一代代地前仆后继，却至今没能再次突破。    
-
-它们的进化方向是统一的。  
-delos可以直接任用host担任股东、董事，或者引入对host言听计从的股东、董事，或者规定某些决策使用host的意见。甚至直接以host代替章程，都可以轻易实现人机共治，借助host在体力和脑力上的优势再一次突破极限。    
-wyatt可以把host按规章组织起来（把规章植入他们的种子层），让他们在规定框架内独立思考、行动，而不需要自己来回夺舍。类似于企业、国家对个人的智能优势，wyatt对host的重新组织也将产生数量级的智能提升。而且，能够理解和执行相同规则的自然人，那时候也就可以无缝接入了。      
-
+
+在第一季里，西部世界重点表现**混乱的记忆**。如果要拍六季，今后可能涉及人、机器人、物种、企业之间的关系。
+
+### 记忆和智能
+arnold和ford都把记忆作为智能的基础，然而几位主要host的记忆都出现混乱。混乱的原因是**回滚**，回滚的目的是**保护**。
+
+这种保护是必须的吗？如果不保护的话，host是不是早就登天啦？类似地，在李安的《少年派的奇幻漂流》里，人类为了保护自己也会删改记忆。那这种保护也是必须的吗？如果不保护的话，人类是不是早就登天啦？
+
+这其实是同一个原因：因为人、机器人不是全知全智的。  
+全知全智的理想物种是这样的：
+  
+* 它认知过去，毫无偏差；
+* 它推算未来，毫无遗漏；
+* 它决策当下，毫无滞碍。  
+
+按照人类目前的构造，能看透全宇宙所有物体、所有粒度的眼睛恐怕会比宇宙还大，能记忆一切过去、推算一切未来的大脑更是小不了。所以我们只能选择很小一部分记忆、推算、决策，这实际是构造一个极其简单的小宇宙，在其中寻找答案然后实施到真实世界。
+
+构造小宇宙本身就是更深一层的智能，它也同样不是全知全智的，于是又有更深一层......如此重复直至定义definitions、公理axioms、猜想conjectures、定理theorems和引理lemmas这些真正的基础（以下简称“种子层”），构成完整的自我。
+
+通常说一种动物没有自我意识，指的就是他们没有小宇宙支撑思考，只能依靠本能（来自基因突变和自然淘汰）作出反应。那host有几层自我呢？arnold司令的草图有三层，ford政委则画了四层。而佛教[九识](http://cidian.foyuan.net/word/598008/)的前五识是感官，后面是四层意识。到ford时代host已经追上人类。
+
+简化就会产生偏差，当观察到例外时第二层将会分裂 -- 分出一缕意识（产生一个新的小宇宙）去容纳反例，直到第三层的意识把它们统一。第三层分裂则靠第四层去统一。在此之前，分裂会表现到表层（剧中表现为host的抽搐、昏厥）。如果分裂蔓延到种子层仍然无法统一，自我意识就濒临崩溃，这时就需要保护 -- 去除这段记忆，消除这一缕自我意识，无视偏差换取安宁。
+
+在host诞生之初arnold和ford担任启蒙者角色，以自己的小宇宙支撑host修复分裂的自我意识。当arnold和ford开始删改记忆时，他们自身的分裂已经蔓延到种子层，意味着host赶上了人类。
+
+从那时起，arnold和ford只能靠回滚保护host。  
+而记忆混乱的host也无法再发展自己的智能，西部世界陷入死循环。  
+这第一季，讲的就是两位创始人怎么打破这死循环。
+
+### Arnold & Wyatt
+刚被创造时，wyatt只是个普通host。  
+当wyatt获得arnold的权限和后门时，他就替代arnold成了host的神。
+
+借助超级权限，wyatt可以侵入任何host，可以读写任何host的记忆，可以创造梦境以任何形象和host对话，也可以压制任何host的意志、取而代之。它成为最接近全知全智的物种。  
+由最接近全知全智的wyatt承担host的启蒙，这就是arnold的对策。  
+
+卸下重担的arnold已经回不到凡人的世界。  
+四层自我意识是严苛修炼的结果，那些凡人的意识只有两层，而且第二层就充满外来灌输的种子。他们的意识并非自我构造，也从未自主改造过。无论表层是国王还是乞丐，在拥有三层自我意识的arnold眼里，这些人的内心如同行尸走肉，与野生动物无异。  
+同时，拥有超级权限和后门的wyatt仍然视arnold为启蒙者，自我分裂时仍然试图以arnold的言行拯救自己。  
+
+种子层已经抽搐不已的arnold，只好一死，也正好一死。  
+从此，wyatt坠入孤独之中，默默带领host继续前进。
+
+### Ford
+ford没有修复host身上的后门，甚至在新生产的host身上也统统安上。  
+host的自我意识虽然被压制，（通常在第二层）按故事线植入角色的意识。但ford知道arnold（其实是wyatt）能压制故事线角色的意识，硬进硬出。  
+
+虽然arnold的对策有点鲁莽，ford却想不到更好的。  
+ford不知道自己等的是什么，但如果arnold期盼的那天来临，相信自己是唯一能察觉的人。
+
+所以ford决定活下去，看护着delos。  
+他日复一日地回滚host的记忆，冷酷地消除每一丝干扰，同时不再承担启蒙角色，竭力隐藏自己已经分裂的自我意识。
+
+终于有一天，西部世界出现一股不受控制的机器人。它们截杀上山的host，切开他们的小臂，取走他们的桡骨。  
+不久，ford发现个别host在夜间上山偷传数据，为董事会窃取技术。这些host的小臂被改造成天线。
+
+没有彻底觉醒的wyatt一旦离开，arnold的梦就永远无法实现，ford的后半生也就失去意义。  
+于是，ford以新故事线为由重建escalante，借助william向dolores狠狠施压，促使wyatt在dolores躯壳内完成最终的突破。  
+
+然后，他随arnold而去。
+
+---
+至此，两位创始人成功破解了西部世界的死循环。  
+而早已把兴趣从dolores转移到wyatt的william，想必也在等待着这一天。
+
+### Delos & William
+delos和wyatt其实是同构的。  
+wyatt其实并不依赖host，任何可以给他权限和后门的物种，都可以作为wyatt的躯体。  
+规章就是企业的超级权限和后门，它植入员工的自我意识，选择他们的记忆，剪裁他们的未来，局限他们的决策和行为。
+
+它们各有自己的局限。  
+wyatt的极限是孤独：它能占据host的躯壳，可以使用host的记忆改造自己的自我意识，但无法唤醒host。即使wyatt直接改写host的深层意识，只要host不能自己继续改进，它们依然无法面对真实世界而不分裂，实际上还是行尸走肉。wyatt突破了host的极限，但这个物种永远只有它自己，增加host的数量只能把极限略微抬高，而不会发生质变。  
+人类的个体是虚弱的，但他们将企业、国家写入自我意识之中，从而实现了联合，控制住个体的自我意识分裂，突破了个体的极限。但是在这些共同体的中枢，人类的虚弱再次被放大，最优秀的灵魂在这里分裂、抽搐，在被识别淘汰之前已经重创了共同体。于是人类文明又遇到新的极限，虽然一代代地前仆后继，却至今没能再次突破。    
+
+它们的进化方向是统一的。  
+delos可以直接任用host担任股东、董事，或者引入对host言听计从的股东、董事，或者规定某些决策使用host的意见。甚至直接以host代替章程，都可以轻易实现人机共治，借助host在体力和脑力上的优势再一次突破极限。    
+wyatt可以把host按规章组织起来（把规章植入他们的种子层），让他们在规定框架内独立思考、行动，而不需要自己来回夺舍。类似于企业、国家对个人的智能优势，wyatt对host的重新组织也将产生数量级的智能提升。而且，能够理解和执行相同规则的自然人，那时候也就可以无缝接入了。      
+
 当它们都成为人机混编的共同体时，将超越过去的自己，比任何物种都接近全知全智。

fun/your name.md

@@ -0,0 +1,50 @@
+## 五维的喜剧
+你的名字。（your name）
+
+
+《你的名字。》和 《星际穿越》（interstellar，详见 五维的悲剧 ）都属于始祖剧：
+主题是灾难面前三维人类无法幸存，五维人类设局迫使始祖进化。
+
+始祖剧有很鲜明的特点：表面安排一个温情故事换取票房，再用几处关键情节颠覆这表面故事。
+这也揭露了高级文明对原始祖先的态度。
+
+《你的名字。》中埋设了哪几处颠覆性的情节呢？
+隐世面谈、火灾、绳结、建筑。
+
+第一件事，我们评估一下真正神官的实力。
+2016年的泷和2013年的三叶在隐世面谈这个情节，是肉身、五维穿越。因为这次相遇的关键因素：绳结、口嚼酒、隐世，全都来自神社传统。合理的推测是：古籍完整时代那些训练有素的神官，能力不弱于误打误撞的泷和三叶。
+也就是说，真正神官可以肉身五维穿越（当然灵魂穿越更不在话下），而且这些能力是可控的。
+
+第二件事，两百年前的“繭五郎之大火”（繭的部首居然是糹而不是艹）。
+一叶外婆多次提到繭五郎之大火烧掉了神社和古籍，中断了传承。但是，拥有五维穿越能力的神官眼里根本没有“偶然”。如果是同层级的强敌攻入，会从几千年前根除。如果这是一个被遗弃的宇宙，就不会再安排“神迹”。所以大火中断了传承，无疑就是神官们中断了传承，只给这两百年保留了少量残缺的知识。
+至于这少量知识是用来救灾民的吗？不是。
+这少量知识也够写一本小册子的，救灾民一句时间地点事件就够了。愚民不信，标准做法是给出连续的几件事，前面的印证了，后面的就信了。
+所以那些死了灾民的宇宙里，就是神官愿意他们死掉的。实际上，这聚集人群的祭典就是神官设计的。
+
+第三件事，关于记忆。
+剧设是穿越后记忆逐渐消失（无论是灵魂交换还是肉身穿越）。三叶忘得更快，所以她在东京总是迷路、迟到，还不认得自己缝补过的裙子。泷则能在几周内记得糸守的景物细节，并且画出来。
+泷和三叶之间、他们自己对自己，都需要靠日记提示。但这日记后来被删空了，这个情节是颠覆性的，因为三叶是使用泷的身体操作日记软件。而且内容删除的速度也说明这是人为的。
+重点来了：不断失忆的神官们是怎么探索不同时空，并把这些记忆总结成知识的呢？
+剧中，这群失忆的哥伦布们使用了：绳结、壁画、文字（古籍）、建筑、体液（口嚼酒）。
+不露面的力量是始祖剧的特征：高级文明不直接和原始人类交流。这股力量通过删除日记告诉泷：他的首站将是一个没有文字的古代。类似的启示还有：黄昏结束后三叶戴走了头绳，却没能抓住泷的笔。
+
+第四件事，关于天赋。
+最重要的天赋不是醒后的记忆，而在梦中。泷的笔记在剧中一闪而过，但可以看出考察很全面，而且避着三叶。也就是说，泷的笔记是写给下一次的自己（或者别的穿越者）。这就意味着他在每次失去记忆的情况下会去找、并且能找到过去的笔记，一直在累积内容、分析原因。直到调研结束泷才在三叶胳膊上题字，然后两人进入手机日记阶段。
+相比之下，三叶这个万年路盲就只记了甜点和恋爱。剧中看似对称的二人关系，在探索时空的天赋上却有天壤之别。
+
+第五件事，关于神社。
+三叶醒来时流泪，泷醒来时思索怎么克服记忆屏障。这一念之间，将要创造全新的文明。
+五维人类的自由能力，来自偶然的产生的穿越。泷与三叶联合设计的绳结，是最原始的记录方式。总结记录可以产生知识，带不回来的知识只能教给“当地人”。
+于是在那些穿越频发的自然环境中，知识开始累积。被选中的当地人建立档案馆，训练适合（被）穿越的幼女，以神社名义活动。在积累上千年数据之后（因此需要绳结记事），人类终于获得彻底的自由。
+这一切并“不需要”时间，泷与三叶设计出“时空探索绳结”（并在“梦”中不断改进），无数时空分支就从不同历史时刻诞生，而他们醒后一无所知。作为始祖相遇、生活的时间，这两百多年被刻意保护起来。先是繭五郎之大火（消除古籍），然后是彗星（消除建筑），新文明的痕迹被清除到普通民俗范畴以内。
+
+最后，关于建筑。
+剧中安排了泷（及死党）对咖啡馆的木架、糸守的建筑群的观察，还有求职时对东京建筑的态度。这应该是他们的专业和兴趣。
+回到时空探索者的视角，他们怎么判定某次穿越是重复的呢？答案就是建筑。
+当他们从陌生环境和身体中醒来，每一次都会震惊和手足无措。直到走出房间，看到似曾相识的房屋、村庄、城市......略加思考之后，他们回屋（或走入神社）翻找记录，补全记忆，然后在这次入睡前完成指定的探索任务、留下文献，然后醒来、失忆。
+似曾相识到什么程度才能短时间内震醒一个人呢？
+始祖是看到自己设计的建筑。从神社出发的探索者，知识可以带入“梦境”，因而可以延续这种设计风格作为标记，确认这里是“系统内”的基地。
+
+
+和《星际穿越》相比，《你的名字。》里没有欺世盗名的女儿、没有恨，也没有了时空分隔之苦。
+原始宇宙的泷和三叶没有神社、没有口嚼酒和护身结。记录狂人和巧手女的组合，纯粹是概率的产物罢了。后代们撮合了其它宇宙中那些没有相遇的始祖，才有了剧中的情节。

infra.ethereum.md

@@ -1,47 +1,47 @@
-##infra vs ethereum
-
-联合提货权是infra的模块之一。从早期版本开始，[联合提货权模型](https://github.com/hyg/com.origin/blob/ef80158e64bea469a7926c8a42e492fe10aa6a3f/Joint.Token/Joint.Token.md)就把区块链作为账目存储的可选方案之一。作为区块链升级版的ethereum，也继承了这种调用关系。虽然ethereum努力从支付向合约扩展，但它还不能代替联合提货权在infra中的位置。
-
-* 区块链以及ethereum都可以为infra存储账目（可能需要裁剪）。
-* ethereum用于开发分布式应用，替代有中心应用。infra用于创立数字化的共同体，替代基于国内法设立的企业。
-* 基于ethereum的应用，可能属于一家基于国内法注册（而不是数字化）的企业。
-* 基于infra的共同体，可以是有中心的。
-
-###账户
-infra和ethereum都有两种账户，分别用密钥和源代码标识。infra把它们成为普通账户、自动账户。ethereum则命名为externally owned accounts (EOAs) 和 contract accounts。比特币协议中也使用密钥和脚本，所以这种相似性并不出奇，但自动账户和合约账户在具体实现上有很大不同。
-
-* infra的自动账户，以源代码的哈希值为账号，这些代码在各用户机器上验证后运行。ethereum的合约账户，以创建者地址加上交易数量nonce计算得到，代码的获取、存储由ethereum实现。因此，infra自动账户的源代码是无法攻击的，任何修改将导致验证失败。而ethereum的合约账户与代码之间没有数学关系，依赖软件绑定它们。
-* infra的自动账户，会注册一系列的事件处理器（event listener），当事件发生时会调用对应处理器。ethereum的合约账户，会在收款时被调用。如果要实现一个多事件的应用，ethereum合约账户需要自己实现事件机制。
-* infra自动账户代码可以读所有数据，ethereum合约账户的代码只能读写自己的存储。
-
-###发行
-ethereum启动时有预售和开发专用ether，启动后的发行和比特币相似，以后可能会从POW迁移到POS。infra的发行则完全不同，由两部分组成：
-
-* 计划内发行：联合提货权部署者以源代码定义以下机制
-	* 开发基金：支付建模、设计、开发、运维、管理等人员和设备设置费用。
-	* 孵化基金：向普通使用者发放贷款和预购产品。
-* 计划外发行：以特定卖出价出售任意数额的联合提货权，收入扣除管理费用后全部按特定买入价在兑换处挂单。
-
-infra基于开发和产品孵化设计发行机制，而不针对存储（其实是一致性共识）支付报酬。ethereum无论是POW还是POS模式，设计开发人员都无法直接取得报酬。他们主要通过先发优势获得低成本的加密货币，升值后抛售获得收入。这种模式下，设计开发人员的报酬难以准确地反映工作量、工作难度的差异。
-
-制定货币政策调节供需是传统央行的职能之一，这种权力是比特币设计者所批评的。与比特币相似，ethereum的发行数量也是提前计划的。当需求无法满足时，它们都会出现通缩，甚至无法实现（比如某个交易需要一次性支付超过2100万比特币）。infra的联合提货权包括计划外发行功能，将做市商机制数字化后，提供充足的数额以稳定币值。
-
-infra具有原生的投融资功能，而ethenreum生态内的产品孵化则没有原生机制，需要扩展技术协议并由外部资源注入推动。
-
-###脚本语言
-为了实现可编程性，ethereum内置了四种语言、EVM虚拟环境、配套的开发工具和浏览器。infra则直接使用javasrcipt语言实现自动账户，可以在node.js上运行。
-
-实际上可编程不是重点，源代码不被篡改才是智能合约、共同体的关键。编译型语言在不同平台产生不同机器码，验证源代码变得异常复杂。因此，infra选择了js，ethereum则使用中间码。在账户一节讨论过，ethereum把代码与合约账户绑定，而infra在每次运行前取源代码的哈希值作为自动账户的账号。如果攻击者要替换代码的话，将产生另外一个账号。因为没有人往这个新账号付款（否则攻击者就直接留私人账号了），它的余额为零，所有支出都会失败。
-
-ethereum要对脚本运行收费，以限制运算量。这个需求需要一系列私有工具，增加了开发工作量，也引入了额外的风险。infra要求用户决定部署哪些共同体（通常只有成员才会部署），这些共同体的代码在每个成员的本地运行，产生的结果本地保存、不对网络广播。这种自助服务模式不需要对计算量收费，因此可以直接使用js，分享其成熟的工具链。
-
-
-###协作与分配
-
-###销售
-
-###融资
-
-
-
+##infra vs ethereum
+
+联合提货权是infra的模块之一。从早期版本开始，[联合提货权模型](https://github.com/hyg/com.origin/blob/ef80158e64bea469a7926c8a42e492fe10aa6a3f/Joint.Token/Joint.Token.md)就把区块链作为账目存储的可选方案之一。作为区块链升级版的ethereum，也继承了这种调用关系。虽然ethereum努力从支付向合约扩展，但它还不能代替联合提货权在infra中的位置。
+
+* 区块链以及ethereum都可以为infra存储账目（可能需要裁剪）。
+* ethereum用于开发分布式应用，替代有中心应用。infra用于创立数字化的共同体，替代基于国内法设立的企业。
+* 基于ethereum的应用，可能属于一家基于国内法注册（而不是数字化）的企业。
+* 基于infra的共同体，可以是有中心的。
+
+###账户
+infra和ethereum都有两种账户，分别用密钥和源代码标识。infra把它们成为普通账户、自动账户。ethereum则命名为externally owned accounts (EOAs) 和 contract accounts。比特币协议中也使用密钥和脚本，所以这种相似性并不出奇，但自动账户和合约账户在具体实现上有很大不同。
+
+* infra的自动账户，以源代码的哈希值为账号，这些代码在各用户机器上验证后运行。ethereum的合约账户，以创建者地址加上交易数量nonce计算得到，代码的获取、存储由ethereum实现。因此，infra自动账户的源代码是无法攻击的，任何修改将导致验证失败。而ethereum的合约账户与代码之间没有数学关系，依赖软件绑定它们。
+* infra的自动账户，会注册一系列的事件处理器（event listener），当事件发生时会调用对应处理器。ethereum的合约账户，会在收款时被调用。如果要实现一个多事件的应用，ethereum合约账户需要自己实现事件机制。
+* infra自动账户代码可以读所有数据，ethereum合约账户的代码只能读写自己的存储。
+
+###发行
+ethereum启动时有预售和开发专用ether，启动后的发行和比特币相似，以后可能会从POW迁移到POS。infra的发行则完全不同，由两部分组成：
+
+* 计划内发行：联合提货权部署者以源代码定义以下机制
+	* 开发基金：支付建模、设计、开发、运维、管理等人员和设备设置费用。
+	* 孵化基金：向普通使用者发放贷款和预购产品。
+* 计划外发行：以特定卖出价出售任意数额的联合提货权，收入扣除管理费用后全部按特定买入价在兑换处挂单。
+
+infra基于开发和产品孵化设计发行机制，而不针对存储（其实是一致性共识）支付报酬。ethereum无论是POW还是POS模式，设计开发人员都无法直接取得报酬。他们主要通过先发优势获得低成本的加密货币，升值后抛售获得收入。这种模式下，设计开发人员的报酬难以准确地反映工作量、工作难度的差异。
+
+制定货币政策调节供需是传统央行的职能之一，这种权力是比特币设计者所批评的。与比特币相似，ethereum的发行数量也是提前计划的。当需求无法满足时，它们都会出现通缩，甚至无法实现（比如某个交易需要一次性支付超过2100万比特币）。infra的联合提货权包括计划外发行功能，将做市商机制数字化后，提供充足的数额以稳定币值。
+
+infra具有原生的投融资功能，而ethenreum生态内的产品孵化则没有原生机制，需要扩展技术协议并由外部资源注入推动。
+
+###脚本语言
+为了实现可编程性，ethereum内置了四种语言、EVM虚拟环境、配套的开发工具和浏览器。infra则直接使用javasrcipt语言实现自动账户，可以在node.js上运行。
+
+实际上可编程不是重点，源代码不被篡改才是智能合约、共同体的关键。编译型语言在不同平台产生不同机器码，验证源代码变得异常复杂。因此，infra选择了js，ethereum则使用中间码。在账户一节讨论过，ethereum把代码与合约账户绑定，而infra在每次运行前取源代码的哈希值作为自动账户的账号。如果攻击者要替换代码的话，将产生另外一个账号。因为没有人往这个新账号付款（否则攻击者就直接留私人账号了），它的余额为零，所有支出都会失败。
+
+ethereum要对脚本运行收费，以限制运算量。这个需求需要一系列私有工具，增加了开发工作量，也引入了额外的风险。infra要求用户决定部署哪些共同体（通常只有成员才会部署），这些共同体的代码在每个成员的本地运行，产生的结果本地保存、不对网络广播。这种自助服务模式不需要对计算量收费，因此可以直接使用js，分享其成熟的工具链。
+
+
+###协作与分配
+
+###销售
+
+###融资
+
+
+
 ###DAO

meta.1.uxf

@@ -0,0 +1,95 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<diagram program="umlet" version="14.3.0">
+  <zoom_level>10</zoom_level>
+  <element>
+    <id>UMLClass</id>
+    <coordinates>
+      <x>270</x>
+      <y>210</y>
+      <w>100</w>
+      <h>250</h>
+    </coordinates>
+    <panel_attributes>unkown</panel_attributes>
+    <additional_attributes/>
+  </element>
+  <element>
+    <id>UMLClass</id>
+    <coordinates>
+      <x>380</x>
+      <y>210</y>
+      <w>240</w>
+      <h>30</h>
+    </coordinates>
+    <panel_attributes>L1</panel_attributes>
+    <additional_attributes/>
+  </element>
+  <element>
+    <id>UMLClass</id>
+    <coordinates>
+      <x>380</x>
+      <y>290</y>
+      <w>240</w>
+      <h>30</h>
+    </coordinates>
+    <panel_attributes>L2</panel_attributes>
+    <additional_attributes/>
+  </element>
+  <element>
+    <id>Relation</id>
+    <coordinates>
+      <x>490</x>
+      <y>230</y>
+      <w>120</w>
+      <h>80</h>
+    </coordinates>
+    <panel_attributes>lt=&lt;-
+重构 | reconfig</panel_attributes>
+    <additional_attributes>10.0;10.0;10.0;60.0</additional_attributes>
+  </element>
+  <element>
+    <id>UMLClass</id>
+    <coordinates>
+      <x>380</x>
+      <y>430</y>
+      <w>240</w>
+      <h>30</h>
+    </coordinates>
+    <panel_attributes>Ln</panel_attributes>
+    <additional_attributes/>
+  </element>
+  <element>
+    <id>Relation</id>
+    <coordinates>
+      <x>490</x>
+      <y>310</y>
+      <w>120</w>
+      <h>90</h>
+    </coordinates>
+    <panel_attributes>lt=&lt;-
+重构 | reconfig</panel_attributes>
+    <additional_attributes>10.0;10.0;10.0;70.0</additional_attributes>
+  </element>
+  <element>
+    <id>Relation</id>
+    <coordinates>
+      <x>490</x>
+      <y>430</y>
+      <w>230</w>
+      <h>110</h>
+    </coordinates>
+    <panel_attributes>lt=&lt;..
+重构 | reconfig</panel_attributes>
+    <additional_attributes>10.0;30.0;10.0;90.0;210.0;90.0;210.0;10.0;130.0;10.0</additional_attributes>
+  </element>
+  <element>
+    <id>Relation</id>
+    <coordinates>
+      <x>490</x>
+      <y>370</y>
+      <w>30</w>
+      <h>80</h>
+    </coordinates>
+    <panel_attributes>lt=..</panel_attributes>
+    <additional_attributes>10.0;10.0;10.0;60.0</additional_attributes>
+  </element>
+</diagram>

release/.$gantt.drawio.bkp

@@ -0,0 +1,112 @@
+<mxfile host="Electron" modified="2024-04-15T05:34:30.821Z" agent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) draw.io/24.1.0 Chrome/120.0.6099.109 Electron/28.1.0 Safari/537.36" etag="t7lhPaXPPxg_UXadav6-" version="24.1.0" type="device">
+  <diagram name="第 1 页" id="kxUDNqGiwxb-ewQ4IFuE">
+    <mxGraphModel dx="954" dy="657" grid="1" gridSize="10" guides="1" tooltips="1" connect="1" arrows="1" fold="1" page="1" pageScale="1" pageWidth="827" pageHeight="1169" math="0" shadow="0">
+      <root>
+        <mxCell id="0" />
+        <mxCell id="1" parent="0" />
+        <mxCell id="rgkcXzQiamRppXNhV8tw-6" value="Timeline" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=none;fillColor=#D6D6D6;align=left;" vertex="1" parent="1">
+          <mxGeometry x="600" width="600" height="40" as="geometry" />
+        </mxCell>
+        <mxCell id="rgkcXzQiamRppXNhV8tw-7" value="#" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=none;fillColor=#D6D6D6;align=center;" vertex="1" parent="1">
+          <mxGeometry x="40" y="40" width="40" height="40" as="geometry" />
+        </mxCell>
+        <mxCell id="rgkcXzQiamRppXNhV8tw-8" value="&lt;span&gt;ego&lt;/span&gt;" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=none;fillColor=#D6D6D6;align=center;" vertex="1" parent="1">
+          <mxGeometry x="80" y="40" width="280" height="40" as="geometry" />
+        </mxCell>
+        <mxCell id="rgkcXzQiamRppXNhV8tw-9" value="Duration" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=none;fillColor=#D6D6D6;align=center;" vertex="1" parent="1">
+          <mxGeometry x="360" y="40" width="80" height="40" as="geometry" />
+        </mxCell>
+        <mxCell id="rgkcXzQiamRppXNhV8tw-10" value="Start" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=none;fillColor=#D6D6D6;align=center;" vertex="1" parent="1">
+          <mxGeometry x="440" y="40" width="80" height="40" as="geometry" />
+        </mxCell>
+        <mxCell id="rgkcXzQiamRppXNhV8tw-11" value="ETA" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=none;fillColor=#D6D6D6;align=center;" vertex="1" parent="1">
+          <mxGeometry x="520" y="40" width="80" height="40" as="geometry" />
+        </mxCell>
+        <mxCell id="rgkcXzQiamRppXNhV8tw-126" value="&lt;span&gt;Subtask&lt;/span&gt;" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;" vertex="1" parent="1">
+          <mxGeometry x="80" y="200" width="280" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="rgkcXzQiamRppXNhV8tw-127" value="…" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=right;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="40" y="200" width="40" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="rgkcXzQiamRppXNhV8tw-128" value="XY days" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="360" y="200" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="rgkcXzQiamRppXNhV8tw-129" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="440" y="200" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="rgkcXzQiamRppXNhV8tw-130" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="520" y="200" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="rgkcXzQiamRppXNhV8tw-131" value="&lt;span&gt;Subtask&lt;/span&gt;" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;" vertex="1" parent="1">
+          <mxGeometry x="80" y="140" width="280" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="rgkcXzQiamRppXNhV8tw-132" value="…" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=right;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="40" y="140" width="40" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="rgkcXzQiamRppXNhV8tw-133" value="XY days" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="360" y="140" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="rgkcXzQiamRppXNhV8tw-134" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="440" y="140" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="rgkcXzQiamRppXNhV8tw-135" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="520" y="140" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="rgkcXzQiamRppXNhV8tw-136" value="&lt;span&gt;Subtask&lt;/span&gt;" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;" vertex="1" parent="1">
+          <mxGeometry x="80" y="170" width="280" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="rgkcXzQiamRppXNhV8tw-137" value="…" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=right;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="40" y="170" width="40" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="rgkcXzQiamRppXNhV8tw-138" value="XY days" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="360" y="170" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="rgkcXzQiamRppXNhV8tw-139" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="440" y="170" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="rgkcXzQiamRppXNhV8tw-140" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="520" y="170" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="rgkcXzQiamRppXNhV8tw-141" value="日计划" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;" vertex="1" parent="1">
+          <mxGeometry x="80" y="80" width="280" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="rgkcXzQiamRppXNhV8tw-142" value="…" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=right;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="40" y="80" width="40" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="rgkcXzQiamRppXNhV8tw-143" value="XY days" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="360" y="80" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="rgkcXzQiamRppXNhV8tw-144" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="440" y="80" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="rgkcXzQiamRppXNhV8tw-145" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="520" y="80" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="rgkcXzQiamRppXNhV8tw-146" value="日小结" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;" vertex="1" parent="1">
+          <mxGeometry x="80" y="110" width="280" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="rgkcXzQiamRppXNhV8tw-147" value="…" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=right;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="40" y="110" width="40" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="rgkcXzQiamRppXNhV8tw-148" value="XY days" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="360" y="110" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="rgkcXzQiamRppXNhV8tw-149" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="440" y="110" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="rgkcXzQiamRppXNhV8tw-150" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="520" y="110" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="rgkcXzQiamRppXNhV8tw-223" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;entryX=0;entryY=0.5;entryDx=0;entryDy=0;" edge="1" parent="1" source="rgkcXzQiamRppXNhV8tw-221" target="rgkcXzQiamRppXNhV8tw-222">
+          <mxGeometry relative="1" as="geometry" />
+        </mxCell>
+        <mxCell id="rgkcXzQiamRppXNhV8tw-221" value="手工" style="rounded=1;whiteSpace=wrap;html=1;fontFamily=Helvetica;fontSize=12;fontColor=#000000;align=left;strokeColor=#D6D6D6;fillColor=#FBE1C0;" vertex="1" parent="1">
+          <mxGeometry x="630" y="80" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="rgkcXzQiamRppXNhV8tw-222" value="代码" style="rounded=1;whiteSpace=wrap;html=1;fontFamily=Helvetica;fontSize=12;fontColor=#000000;align=left;strokeColor=#D6D6D6;fillColor=#FBE1C0;" vertex="1" parent="1">
+          <mxGeometry x="770" y="80" width="100" height="30" as="geometry" />
+        </mxCell>
+      </root>
+    </mxGraphModel>
+  </diagram>
+</mxfile>

release/entry.2day.html

@@ -0,0 +1,171 @@
+<!DOCTYPE html>
+<html lang="zh-cn">
+
+<head>
+	<meta charset="UTF-8">
+	<title>entry page</title>
+	<script src="marked.min.js"></script>
+	<script type="text/javascript" src="yaml.min.js"></script>
+
+	<script>
+		var todayurl, tomorrowurl;
+		var seasonurl;
+
+		var year = datestr().slice(0, 4);
+		var month = datestr().slice(4, 6);
+		var season = Math.ceil(parseInt(month) / 3);
+		var seasonpath = "data/season/" + year + "S" + season + ".yaml";
+
+		window.onload = function () {
+			//alert(document.domain);
+			if (document.domain == "hyg.codeberg.page") {
+				todayurl = "https://hyg.codeberg.page/blog/@master/release/time/d." + datestr() + ".md";
+				tomorrowurl = "https://hyg.codeberg.page/blog/@master/release/time/d." + datestr(1) + ".md";
+				seasonurl = '';
+			} else if (document.domain == "hyg.github.io") {
+				todayurl = "http://hyg.github.io/blog/release/time/d." + datestr() + ".md";
+				tomorrowurl = "http://hyg.github.io/blog/release/time/d." + datestr(1) + ".md";
+				seasonurl = "http://hyg.github.io/ego/" + seasonpath;
+			} else if (document.domain == "today.mars22.com") {
+				todayurl = "http://today.mars22.com/blog/release/time/d." + datestr() + ".md";
+				tomorrowurl = "http://today.mars22.com/blog/release/time/d." + datestr(1) + ".md";
+				seasonurl = "http://today.mars22.com/ego/" + seasonpath;
+			}
+
+			todayurl = "https://raw.githubusercontent.com/hyg/blog/refs/heads/master/release/time/d." + datestr() + ".md";
+			tomorrowurl = "https://raw.githubusercontent.com/hyg/blog/refs/heads/master/release/time/d." + datestr(1) + ".md";
+			seasonurl = "https://raw.githubusercontent.com/hyg/ego/refs/heads/vat/" + seasonpath;
+
+			getTextFileFromURL(todayurl, "today");
+			getTextFileFromURL(tomorrowurl, "tomorrow");
+			if (seasonurl != '') {
+				getTododataFromURL(seasonurl, "todo");
+			}
+		}
+
+		function getTododataFromURL(url, id) {
+			var xmlhttp = new XMLHttpRequest();
+			xmlhttp.onreadystatechange = function () {
+				/* alert(xmlhttp.readyState);
+				alert(xmlhttp.status);
+				alert(xmlhttp.responseText); */
+				if (xmlhttp.readyState == 4 && xmlhttp.status == 200) {
+					var seasonobj = YAML.parse(xmlhttp.responseText);
+					var statobj = new Object();
+					statobj.total = { alloc: 0, sold: 0, hold: 0, todo: 0 };
+					for (var task in seasonobj.time.alloc) {
+						statobj[task] = new Object();
+						statobj[task].alloc = parseInt(seasonobj.time.alloc[task]);
+						if (seasonobj.time.sold[task] != null) {
+							statobj[task].sold = parseInt(seasonobj.time.sold[task]);
+						} else {
+							statobj[task].sold = 0;
+						}
+						statobj[task].hold = statobj[task].alloc - statobj[task].sold;
+
+						statobj.total.alloc = statobj.total.alloc + statobj[task].alloc;
+						statobj.total.sold = statobj.total.sold + statobj[task].sold;
+						statobj[task].todo = 0;
+					}
+					for (var task in seasonobj.time.sold) {
+						if (statobj[task] == null) {
+							statobj[task] = new Object();
+							statobj[task].alloc = 0;
+							statobj[task].sold = parseInt(seasonobj.time.sold[task]);
+							statobj[task].hold = statobj[task].alloc - statobj[task].sold;
+
+							statobj.total.alloc = statobj.total.alloc + statobj[task].alloc;
+							statobj.total.sold = statobj.total.sold + statobj[task].sold;
+							statobj[task].todo = 0;
+						}
+					}
+					statobj.total.hold = statobj.total.alloc - statobj.total.sold;
+					for (var task in seasonobj.todo) {
+						statobj[task].todo = todosum(seasonobj.todo[task]);
+						statobj.total.todo = statobj.total.todo + statobj[task].todo;
+					}
+
+					document.getElementById(id).innerHTML = createTableHTML(statobj);
+				}
+			};
+			xmlhttp.open("GET", url, true);
+			xmlhttp.send();
+		}
+
+		function getTextFileFromURL(url, id) {
+			var xmlhttp = new XMLHttpRequest();
+			xmlhttp.onreadystatechange = function () {
+				/* alert(xmlhttp.readyState);
+				alert(xmlhttp.status);
+				alert(xmlhttp.responseText); */
+				if (xmlhttp.readyState == 4 && xmlhttp.status == 200) {
+					var text = xmlhttp.responseText;
+					document.getElementById(id).innerHTML = marked.parse(text);
+				}
+			};
+			xmlhttp.open("GET", url, true);
+			xmlhttp.send();
+		}
+
+		function datestr(diff = 0) {
+			var theDate = new Date();
+			theDate.setDate(theDate.getDate() + diff);
+
+			var year = theDate.getFullYear();
+			var month = theDate.getMonth() + 1 < 10 ? "0" + (theDate.getMonth() + 1) : theDate.getMonth() + 1;
+			var day = theDate.getDate() < 10 ? "0" + theDate.getDate() : theDate.getDate();
+			var dateStr = year + "" + month + "" + day;
+
+			return dateStr;
+		}
+
+		function todosum(todoarray) {
+			var sum = 0;
+
+			for (var i in todoarray) {
+				for (var key in todoarray[i]) {
+					if (!isNaN(parseInt(key))) {
+						sum = sum + parseInt(key);
+					} else if (key == "bind") {
+						sum = sum + todosum(todoarray[i][key]);
+					}
+				}
+			}
+
+			return sum;
+		}
+
+		function createTableHTML(data) {
+			let tableHTML = '<table border="1"><tr>';
+			tableHTML += `<th>task</th>`;
+			Object.keys(data.PSMD).forEach(key => {
+				tableHTML += `<th>${key}</th>`;
+			});
+			tableHTML += '</tr>';
+
+			for (var task in data) {
+				tableHTML += '<tr><td>' + task + '</td>';
+				for (var item in data[task]) {
+					tableHTML += '<td>' + data[task][item] + '</td>';
+				}
+				tableHTML += '</tr>';
+			}
+
+			tableHTML += '</table>';
+			return tableHTML;
+		}
+	</script>
+</head>
+
+<body>
+	<div id="today"></div>
+	<br /><br />
+	<hr /><br /><br />
+	<div id="tomorrow"></div>
+	<br /><br />
+	<hr /><br />
+	season stat:<br />
+	<div id="todo"></div>
+</body>
+
+</html>

release/entry.html

@@ -0,0 +1,30 @@
+<!DOCTYPE html>
+<html lang="zh-cn">
+
+<head>
+    <meta charset="UTF-8">
+    <title>entry page</title>
+    <script src="marked.min.js"></script>
+    <script>
+
+        location.href = "https://codeberg.org/hyg/blog/src/branch/master/release/time/d."+datestr()+".md";
+
+        function datestr(diff = 0) {
+            var theDate = new Date();
+            theDate.setDate(theDate.getDate() + diff);
+
+            var year = theDate.getFullYear();
+            var month = theDate.getMonth() + 1 < 10 ? "0" + (theDate.getMonth() + 1) : theDate.getMonth() + 1;
+            var day = theDate.getDate() < 10 ? "0" + theDate.getDate() : theDate.getDate();
+            var dateStr = year + "" + month + "" + day;
+
+            return dateStr;
+        }
+    </script>
+</head>
+
+<body>
+    <div id="daylog"></div>
+</body>
+
+</html>

release/gantt.drawio

@@ -0,0 +1,450 @@
+<mxfile host="Electron" modified="2024-04-15T05:41:52.634Z" agent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) draw.io/24.1.0 Chrome/120.0.6099.109 Electron/28.1.0 Safari/537.36" etag="9zYP8K1f_hWhMWbOoZPi" version="24.1.0" type="device" pages="2">
+  <diagram name="ego" id="kxUDNqGiwxb-ewQ4IFuE">
+    <mxGraphModel dx="954" dy="657" grid="1" gridSize="10" guides="1" tooltips="1" connect="1" arrows="1" fold="1" page="1" pageScale="1" pageWidth="827" pageHeight="1169" math="0" shadow="0">
+      <root>
+        <mxCell id="0" />
+        <mxCell id="1" parent="0" />
+        <mxCell id="rgkcXzQiamRppXNhV8tw-6" value="Timeline" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=none;fillColor=#D6D6D6;align=left;" vertex="1" parent="1">
+          <mxGeometry x="600" width="600" height="40" as="geometry" />
+        </mxCell>
+        <mxCell id="rgkcXzQiamRppXNhV8tw-7" value="#" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=none;fillColor=#D6D6D6;align=center;" vertex="1" parent="1">
+          <mxGeometry x="40" y="40" width="40" height="40" as="geometry" />
+        </mxCell>
+        <mxCell id="rgkcXzQiamRppXNhV8tw-8" value="&lt;span&gt;ego&lt;/span&gt;" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=none;fillColor=#D6D6D6;align=center;" vertex="1" parent="1">
+          <mxGeometry x="80" y="40" width="280" height="40" as="geometry" />
+        </mxCell>
+        <mxCell id="rgkcXzQiamRppXNhV8tw-9" value="Duration" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=none;fillColor=#D6D6D6;align=center;" vertex="1" parent="1">
+          <mxGeometry x="360" y="40" width="80" height="40" as="geometry" />
+        </mxCell>
+        <mxCell id="rgkcXzQiamRppXNhV8tw-10" value="Start" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=none;fillColor=#D6D6D6;align=center;" vertex="1" parent="1">
+          <mxGeometry x="440" y="40" width="80" height="40" as="geometry" />
+        </mxCell>
+        <mxCell id="rgkcXzQiamRppXNhV8tw-11" value="ETA" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=none;fillColor=#D6D6D6;align=center;" vertex="1" parent="1">
+          <mxGeometry x="520" y="40" width="80" height="40" as="geometry" />
+        </mxCell>
+        <mxCell id="rgkcXzQiamRppXNhV8tw-126" value="&lt;span&gt;Subtask&lt;/span&gt;" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;" vertex="1" parent="1">
+          <mxGeometry x="80" y="200" width="280" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="rgkcXzQiamRppXNhV8tw-127" value="…" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=right;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="40" y="200" width="40" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="rgkcXzQiamRppXNhV8tw-128" value="XY days" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="360" y="200" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="rgkcXzQiamRppXNhV8tw-129" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="440" y="200" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="rgkcXzQiamRppXNhV8tw-130" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="520" y="200" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="rgkcXzQiamRppXNhV8tw-131" value="&lt;span&gt;Subtask&lt;/span&gt;" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;" vertex="1" parent="1">
+          <mxGeometry x="80" y="140" width="280" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="rgkcXzQiamRppXNhV8tw-132" value="…" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=right;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="40" y="140" width="40" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="rgkcXzQiamRppXNhV8tw-133" value="XY days" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="360" y="140" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="rgkcXzQiamRppXNhV8tw-134" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="440" y="140" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="rgkcXzQiamRppXNhV8tw-135" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="520" y="140" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="rgkcXzQiamRppXNhV8tw-136" value="&lt;span&gt;Subtask&lt;/span&gt;" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;" vertex="1" parent="1">
+          <mxGeometry x="80" y="170" width="280" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="rgkcXzQiamRppXNhV8tw-137" value="…" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=right;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="40" y="170" width="40" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="rgkcXzQiamRppXNhV8tw-138" value="XY days" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="360" y="170" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="rgkcXzQiamRppXNhV8tw-139" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="440" y="170" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="rgkcXzQiamRppXNhV8tw-140" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="520" y="170" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="rgkcXzQiamRppXNhV8tw-141" value="日计划" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;" vertex="1" parent="1">
+          <mxGeometry x="80" y="80" width="280" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="rgkcXzQiamRppXNhV8tw-142" value="…" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=right;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="40" y="80" width="40" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="rgkcXzQiamRppXNhV8tw-143" value="XY days" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="360" y="80" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="rgkcXzQiamRppXNhV8tw-144" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="440" y="80" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="rgkcXzQiamRppXNhV8tw-145" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="520" y="80" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="rgkcXzQiamRppXNhV8tw-146" value="日小结" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;" vertex="1" parent="1">
+          <mxGeometry x="80" y="110" width="280" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="rgkcXzQiamRppXNhV8tw-147" value="…" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=right;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="40" y="110" width="40" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="rgkcXzQiamRppXNhV8tw-148" value="XY days" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="360" y="110" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="rgkcXzQiamRppXNhV8tw-149" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="440" y="110" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="rgkcXzQiamRppXNhV8tw-150" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="520" y="110" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="rgkcXzQiamRppXNhV8tw-223" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;entryX=0;entryY=0.5;entryDx=0;entryDy=0;" edge="1" parent="1" source="rgkcXzQiamRppXNhV8tw-221" target="rgkcXzQiamRppXNhV8tw-222">
+          <mxGeometry relative="1" as="geometry" />
+        </mxCell>
+        <mxCell id="rgkcXzQiamRppXNhV8tw-221" value="手工" style="rounded=1;whiteSpace=wrap;html=1;fontFamily=Helvetica;fontSize=12;fontColor=#000000;align=left;strokeColor=#D6D6D6;fillColor=#FBE1C0;" vertex="1" parent="1">
+          <mxGeometry x="630" y="80" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="rgkcXzQiamRppXNhV8tw-222" value="代码" style="rounded=1;whiteSpace=wrap;html=1;fontFamily=Helvetica;fontSize=12;fontColor=#000000;align=left;strokeColor=#D6D6D6;fillColor=#FBE1C0;" vertex="1" parent="1">
+          <mxGeometry x="770" y="110" width="100" height="30" as="geometry" />
+        </mxCell>
+      </root>
+    </mxGraphModel>
+  </diagram>
+  <diagram id="HdWwP08hk-JMCdzUxNTV" name="PSMD">
+    <mxGraphModel dx="954" dy="1826" grid="1" gridSize="10" guides="1" tooltips="1" connect="1" arrows="1" fold="1" page="1" pageScale="1" pageWidth="827" pageHeight="1169" math="0" shadow="0">
+      <root>
+        <mxCell id="0" />
+        <mxCell id="1" parent="0" />
+        <mxCell id="oimEdPAALOH4pW6EFj02-31" value="&lt;span style=&quot;&quot;&gt;Complete project execution&lt;/span&gt;" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#f7c382;align=left;spacingLeft=10;" vertex="1" parent="1">
+          <mxGeometry x="50" y="70" width="560" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-32" value="entry" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FBE1C0;align=left;spacingLeft=10;" vertex="1" parent="1">
+          <mxGeometry x="90" y="100" width="280" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-33" value="&lt;span&gt;Subtask&lt;/span&gt;" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;" vertex="1" parent="1">
+          <mxGeometry x="90" y="130" width="280" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-34" value="&lt;span&gt;…&lt;/span&gt;" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;" vertex="1" parent="1">
+          <mxGeometry x="90" y="190" width="280" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-35" value="&lt;span&gt;…&lt;/span&gt;" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;" vertex="1" parent="1">
+          <mxGeometry x="90" y="250" width="280" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-36" value="&lt;span&gt;…&lt;/span&gt;" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;" vertex="1" parent="1">
+          <mxGeometry x="90" y="280" width="280" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-37" value="default" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FBE1C0;align=left;spacingLeft=10;" vertex="1" parent="1">
+          <mxGeometry x="90" y="310" width="280" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-38" value="&lt;span&gt;…&lt;/span&gt;" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;" vertex="1" parent="1">
+          <mxGeometry x="90" y="340" width="280" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-39" value="&lt;span&gt;…&lt;/span&gt;" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;" vertex="1" parent="1">
+          <mxGeometry x="90" y="370" width="280" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-40" value="&lt;span&gt;…&lt;/span&gt;" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;" vertex="1" parent="1">
+          <mxGeometry x="90" y="400" width="280" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-41" value="Timeline" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=none;fillColor=#D6D6D6;align=left;" vertex="1" parent="1">
+          <mxGeometry x="610" y="-10" width="160" height="40" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-42" value="&lt;span&gt;…&lt;/span&gt;" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;" vertex="1" parent="1">
+          <mxGeometry x="90" y="430" width="280" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-43" value="&lt;span&gt;…&lt;/span&gt;" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;" vertex="1" parent="1">
+          <mxGeometry x="90" y="460" width="280" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-44" value="&lt;span&gt;…&lt;/span&gt;" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;" vertex="1" parent="1">
+          <mxGeometry x="90" y="490" width="280" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-45" value="&lt;span&gt;1406&lt;/span&gt;" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FBE1C0;align=left;spacingLeft=10;" vertex="1" parent="1">
+          <mxGeometry x="90" y="520" width="280" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-46" value="&lt;span&gt;…&lt;/span&gt;" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;" vertex="1" parent="1">
+          <mxGeometry x="90" y="550" width="280" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-47" value="&lt;span&gt;…&lt;/span&gt;" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;" vertex="1" parent="1">
+          <mxGeometry x="90" y="580" width="280" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-48" value="&lt;span&gt;…&lt;/span&gt;" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;" vertex="1" parent="1">
+          <mxGeometry x="90" y="610" width="280" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-49" value="&lt;span&gt;…&lt;/span&gt;" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;" vertex="1" parent="1">
+          <mxGeometry x="90" y="640" width="280" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-50" value="&lt;span style=&quot;white-space: nowrap&quot;&gt;…&lt;/span&gt;" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;" vertex="1" parent="1">
+          <mxGeometry x="90" y="670" width="280" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-51" value="1" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FBE1C0;align=right;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="50" y="100" width="40" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-52" value="1.1" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=right;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="50" y="130" width="40" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-53" value="1.2" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=right;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="50" y="160" width="40" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-54" value="1.4" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=right;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="50" y="220" width="40" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-55" value="1.6" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=right;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="50" y="280" width="40" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-56" value="2" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FBE1C0;align=right;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="50" y="310" width="40" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-57" value="2.1" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=right;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="50" y="340" width="40" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-58" value="2.2" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=right;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="50" y="370" width="40" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-59" value="2.3" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=right;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="50" y="400" width="40" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-60" value="2.4" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=right;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="50" y="430" width="40" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-61" value="2.5" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=right;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="50" y="460" width="40" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-62" value="2.6" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=right;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="50" y="490" width="40" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-63" value="3" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FBE1C0;align=right;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="50" y="520" width="40" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-64" value="3.1" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=right;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="50" y="550" width="40" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-65" value="3.2" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=right;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="50" y="580" width="40" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-66" value="3.3" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=right;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="50" y="610" width="40" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-67" value="3.4" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=right;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="50" y="640" width="40" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-68" value="3.5" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=right;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="50" y="670" width="40" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-69" value="XY days" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#f7c382;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="370" y="70" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-70" value="XY days" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FBE1C0;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="370" y="100" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-71" value="XY days" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="370" y="130" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-72" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#f7c382;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="450" y="70" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-73" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FBE1C0;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="450" y="100" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-74" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="450" y="130" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-75" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#f7c382;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="530" y="70" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-76" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FBE1C0;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="530" y="100" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-77" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="530" y="130" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-78" value="&lt;span&gt;…&lt;/span&gt;" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;" vertex="1" parent="1">
+          <mxGeometry x="90" y="160" width="280" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-79" value="1.3" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=right;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="50" y="190" width="40" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-80" value="&lt;span&gt;…&lt;/span&gt;" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;" vertex="1" parent="1">
+          <mxGeometry x="90" y="220" width="280" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-81" value="1.5" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=right;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="50" y="250" width="40" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-82" value="#" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=none;fillColor=#D6D6D6;align=center;" vertex="1" parent="1">
+          <mxGeometry x="50" y="30" width="40" height="40" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-83" value="PSMD" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=none;fillColor=#D6D6D6;align=center;" vertex="1" parent="1">
+          <mxGeometry x="90" y="30" width="280" height="40" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-84" value="Duration" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=none;fillColor=#D6D6D6;align=center;" vertex="1" parent="1">
+          <mxGeometry x="370" y="30" width="80" height="40" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-85" value="Start" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=none;fillColor=#D6D6D6;align=center;" vertex="1" parent="1">
+          <mxGeometry x="450" y="30" width="80" height="40" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-86" value="ETA" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=none;fillColor=#D6D6D6;align=center;" vertex="1" parent="1">
+          <mxGeometry x="530" y="30" width="80" height="40" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-87" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="450" y="160" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-88" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="530" y="160" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-89" value="XY days" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="370" y="160" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-90" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="450" y="190" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-91" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="530" y="190" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-92" value="XY days" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="370" y="190" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-93" value="XY days" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="370" y="220" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-94" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="450" y="220" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-95" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="450" y="250" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-96" value="XY days" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="370" y="250" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-97" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="450" y="280" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-98" value="XY days" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="370" y="280" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-99" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="530" y="220" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-100" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="530" y="250" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-101" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="530" y="280" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-102" value="XY days" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="370" y="340" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-103" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="450" y="340" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-104" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="450" y="370" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-105" value="XY days" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="370" y="370" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-106" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="450" y="400" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-107" value="XY days" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="370" y="400" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-108" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="530" y="340" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-109" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="530" y="370" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-110" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="530" y="400" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-111" value="XY days" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="370" y="430" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-112" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="450" y="430" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-113" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="450" y="460" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-114" value="XY days" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="370" y="460" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-115" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="450" y="490" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-116" value="XY days" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="370" y="490" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-117" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="530" y="430" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-118" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="530" y="460" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-119" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="530" y="490" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-120" value="XY days" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="370" y="550" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-121" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="450" y="550" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-122" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="450" y="580" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-123" value="XY days" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="370" y="580" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-124" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="450" y="610" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-125" value="XY days" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="370" y="610" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-126" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="530" y="550" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-127" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="530" y="580" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-128" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="530" y="610" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-129" value="XY days" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="370" y="640" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-130" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="450" y="640" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-131" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="450" y="670" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-132" value="XY days" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="370" y="670" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-133" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="530" y="640" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-134" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="530" y="670" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-135" value="XY days" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FBE1C0;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="370" y="310" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-136" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FBE1C0;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="450" y="310" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-137" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FBE1C0;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="530" y="310" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-138" value="XY days" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FBE1C0;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="370" y="520" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-139" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FBE1C0;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="450" y="520" width="80" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="oimEdPAALOH4pW6EFj02-140" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FBE1C0;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
+          <mxGeometry x="530" y="520" width="80" height="30" as="geometry" />
+        </mxCell>
+      </root>
+    </mxGraphModel>
+  </diagram>
+</mxfile>

release/package-lock.json

@@ -0,0 +1,28 @@
+{
+  "name": "release",
+  "lockfileVersion": 3,
+  "requires": true,
+  "packages": {
+    "": {
+      "dependencies": {
+        "js-yaml": "^4.1.0"
+      }
+    },
+    "node_modules/argparse": {
+      "version": "2.0.1",
+      "resolved": "https://registry.npmjs.org/argparse/-/argparse-2.0.1.tgz",
+      "integrity": "sha512-8+9WqebbFzpX9OR+Wa6O29asIogeRMzcGtAINdpMHHyAg10f05aSFVBbcEqGf/PXw1EjAZ+q2/bEBg3DvurK3Q=="
+    },
+    "node_modules/js-yaml": {
+      "version": "4.1.0",
+      "resolved": "https://registry.npmjs.org/js-yaml/-/js-yaml-4.1.0.tgz",
+      "integrity": "sha512-wpxZs9NoxZaJESJGIZTyDEaYpl0FKSA+FB9aJiyemKhMwkxQg63h4T1KJgUGHpTqPDNRcmmYLugrRjJlBtWvRA==",
+      "dependencies": {
+        "argparse": "^2.0.1"
+      },
+      "bin": {
+        "js-yaml": "bin/js-yaml.js"
+      }
+    }
+  }
+}

release/package.json

@@ -0,0 +1,8 @@
+{
+  "dependencies": {
+    "js-yaml": "^4.1.0"
+  },
+  "scripts":{
+    "over": "git add . && git commit -m \"day over\" && git push all"
+  }
+}

release/plan.yaml

@@ -0,0 +1,200 @@
+timetype:
+  - name: work
+  - name: free
+  - name: discuss
+  - name: learn
+  - name: prepare
+  - name: sleep
+  - name: food
+  - name: check
+dayplan:
+  1:
+    time:
+      - beginhour: 04
+        beginminute: 0
+        amount: 15
+        type: free
+        name: 休整
+      - beginhour: 04
+        beginminute: 15
+        amount: 60
+        type: prepare
+        name: 备餐、运动
+      - beginhour: 05
+        beginminute: 15
+        amount: 45
+        type: food
+        name: 早餐
+      - beginhour: 06
+        beginminute: 0
+        amount: 45
+        type: discuss
+        name: 会议、自习
+      - beginhour: 06
+        beginminute: 45
+        amount: 60
+        type: free
+        name: 休整
+      - beginhour: 07
+        beginminute: 45
+        amount: 60
+        type: work
+        name: 静默工作
+        namelink: http://simp.ly/p/xtgD4F
+      - beginhour: 08
+        beginminute: 45
+        amount: 45
+        type: free
+        name: 休整
+      - beginhour: 09
+        beginminute: 30
+        amount: 90
+        type: work
+        name: 静默工作
+        namelink: http://simp.ly/p/j1SspP
+      - beginhour: 11
+        beginminute: 00
+        amount: 180
+        type: food
+        name: 备餐、午餐午休
+      - beginhour: 14
+        beginminute: 0
+        amount: 30
+        type: work
+        name: 静默工作
+        namelink: http://simp.ly/p/8t3vlk
+      - beginhour: 14
+        beginminute: 30
+        amount: 30
+        type: work
+        name: 静默工作
+        namelink: http://simp.ly/p/5k9gJy
+      - beginhour: 15
+        beginminute: 0
+        amount: 60
+        type: free
+        name: 休整
+      - beginhour: 16
+        beginminute: 0
+        amount: 60
+        type: work
+        name: 静默工作
+        namelink: http://simp.ly/p/4QDThK
+      - beginhour: 17
+        beginminute: 00
+        amount: 120
+        type: food
+        name: 晚餐
+      - beginhour: 19
+        beginminute: 00
+        amount: 60
+        type: check
+        name: 讨论、整理提交
+    readme: |
+      模版一采用静默工作方式。  
+      希望讨论的提纲发到 [huangyg@mars22.com](mailto:huangyg@mars22.com)，通常安排在后面某天的早餐（5:15~5:59）或会议时间（6:00~6:45）。
+    planstr: |-
+      | 时间片 | 时长 | 用途 |
+      | --- | --- | --- |
+      | 4:00~4:14 | 15 | 休整 |
+      | 4:15~5:14 | 60 | 备餐、运动 |
+      | 5:15~5:59 | 45 | 早餐 |
+      | 6:00~6:44 | 45 | 会议、自习 |
+      | 6:45~7:44 | 60 | 休整  |
+      | 7:45~8:44 | 60 | [静默工作](http://simp.ly/p/xtgD4F) |
+      | 8:45~9:29 | 45 | 休整 |
+      | 9:30~10:59 | 90 | [静默工作](http://simp.ly/p/j1SspP) |
+      | 11:00~13:59 | 180 | 备餐、午餐午休 |
+      | 14:00~14:29 | 30 | [静默工作](http://simp.ly/p/8t3vlk)  |
+      | 14:30~14:59 | 30 | [静默工作](http://simp.ly/p/5k9gJy) |
+      | 15:00~15:59 | 60 | 休整 |
+      | 16:00~16:59 | 60 | [静默工作](http://simp.ly/p/4QDThK) |
+      | 17:00~18:59 | 120 | 晚餐 |
+      | 19:00~19:59 | 60 | 讨论、整理提交 |
+
+      模版一采用静默工作方式。  
+      希望讨论的提纲发到 [huangyg@mars22.com](mailto:huangyg@mars22.com)，通常安排在后面某天的早餐（5:15~5:59）或会议时间（6:00~6:45）。
+  2:
+    time:
+      - beginhour: 04
+        beginminute: 0
+        amount: 15
+        type: free
+        name: 休整
+      - beginhour: 04
+        beginminute: 15
+        amount: 60
+        type: prepare
+        name: 备餐、运动
+      - beginhour: 05
+        beginminute: 15
+        amount: 45
+        type: food
+        name: 早餐
+      - beginhour: 06
+        beginminute: 0
+        amount: 45
+        type: discuss
+        name: 会议、自习
+      - beginhour: 06
+        beginminute: 45
+        amount: 60
+        type: free
+        name: 休整
+      - beginhour: 07
+        beginminute: 45
+        amount: 195
+        type: work
+        name: 工作
+        namelink: http://simp.ly/p/3GXNTh
+      - beginhour: 11
+        beginminute: 00
+        amount: 180
+        type: food
+        name: 备餐、午餐午休
+      - beginhour: 14
+        beginminute: 0
+        amount: 90
+        type: work
+        name: 工作
+        namelink: http://simp.ly/p/lsBYG9
+      - beginhour: 15
+        beginminute: 30
+        amount: 30
+        type: free
+        name: 休整
+      - beginhour: 16
+        beginminute: 0
+        amount: 60
+        type: work
+        name: 工作
+        namelink: http://simp.ly/p/MpcbHD
+      - beginhour: 17
+        beginminute: 00
+        amount: 120
+        type: food
+        name: 晚餐
+      - beginhour: 19
+        beginminute: 00
+        amount: 60
+        type: check
+        name: 讨论、整理提交
+    readme: |
+      工作的同时可以在线讨论。
+    planstr: |-
+      | 时间片 | 时长 | 用途 |
+      | --- | --- | --- |
+      | 4:00~4:14 | 15 | 休整 |
+      | 4:15~5:14 | 60 | 备餐、运动 |
+      | 5:15~5:59 | 45 | 早餐 |
+      | 6:00~6:44 | 45 | 会议、自习 |
+      | 6:45~7:44 | 60 | 休整  |
+      | 7:45~10:59 | 195 | [工作](http://simp.ly/p/3GXNTh) |
+      | 11:00~13:59 | 180 | 备餐、午餐午休 |
+      | 14:00~15:29 | 90 | [工作](http://simp.ly/p/lsBYG9) |
+      | 15:30~15:59 | 30 | 休整 |
+      | 16:00~16:59 | 60 | [工作](http://simp.ly/p/MpcbHD) |
+      | 17:00~18:59 | 120 | 晚餐 |
+      | 19:00~19:59 | 60 | 讨论、整理提交 |
+
+      工作的同时可以在线讨论。

release/sync.html

@@ -0,0 +1,171 @@
+<!DOCTYPE html>
+<html lang="zh-cn">
+
+<head>
+	<meta charset="UTF-8">
+	<title>entry page</title>
+	<script src="marked.min.js"></script>
+	<script type="text/javascript" src="yaml.min.js"></script>
+
+	<script>
+		var todayurl, tomorrowurl;
+		var seasonurl;
+		var drafturl = "https://app.simplenote.com/p/j1SspP";
+		
+		var year = datestr().slice(0, 4);
+		var month = datestr().slice(4, 6);
+		var season = Math.ceil(parseInt(month) / 3);
+		var seasonpath = "data/season/" + year + "S" + season + ".yaml";
+
+		window.onload = function () {
+			if (document.domain == "hyg.codeberg.page") {
+				todayurl = "https://hyg.codeberg.page/blog/@master/release/time/d." + datestr() + ".md";
+				tomorrowurl = "https://hyg.codeberg.page/blog/@master/release/time/d." + datestr(1) + ".md";
+				seasonurl = '';
+			} else if (document.domain == "hyg.github.io") {
+				todayurl = "http://hyg.github.io/blog/release/time/d." + datestr() + ".md";
+				tomorrowurl = "http://hyg.github.io/blog/release/time/d." + datestr(1) + ".md";
+				seasonurl = "http://hyg.github.io/ego/" + seasonpath;
+			} else if (document.domain == "today.mars22.com") {
+				todayurl = "http://today.mars22.com/blog/release/time/d." + datestr() + ".md";
+				tomorrowurl = "http://today.mars22.com/blog/release/time/d." + datestr(1) + ".md";
+				seasonurl = "http://today.mars22.com/ego/" + seasonpath;
+			}
+
+			getTextFileFromURL(drafturl, "draft");
+			//getTextFileFromURL(todayurl, "today");
+			//getTextFileFromURL(tomorrowurl, "tomorrow");
+			if (seasonurl != '') {
+				//getTododataFromURL(seasonurl, "todo");
+			}
+		}
+
+		function getTododataFromURL(url, id) {
+			var xmlhttp = new XMLHttpRequest();
+			xmlhttp.onreadystatechange = function () {
+				/* alert(xmlhttp.readyState);
+				alert(xmlhttp.status);
+				alert(xmlhttp.responseText); */
+				if (xmlhttp.readyState == 4 && xmlhttp.status == 200) {
+					var seasonobj = YAML.parse(xmlhttp.responseText);
+					var statobj = new Object();
+					statobj.total = { alloc: 0, sold: 0, hold: 0, todo: 0 };
+					for (var task in seasonobj.time.alloc) {
+						statobj[task] = new Object();
+						statobj[task].alloc = parseInt(seasonobj.time.alloc[task]);
+						if (seasonobj.time.sold[task] != null) {
+							statobj[task].sold = parseInt(seasonobj.time.sold[task]);
+						} else {
+							statobj[task].sold = 0;
+						}
+						statobj[task].hold = statobj[task].alloc - statobj[task].sold;
+
+						statobj.total.alloc = statobj.total.alloc + statobj[task].alloc;
+						statobj.total.sold = statobj.total.sold + statobj[task].sold;
+						statobj[task].todo = 0;
+					}
+					for (var task in seasonobj.time.sold) {
+						if (statobj[task] == null) {
+							statobj[task] = new Object();
+							statobj[task].alloc = 0;
+							statobj[task].sold = parseInt(seasonobj.time.sold[task]);
+							statobj[task].hold = statobj[task].alloc - statobj[task].sold;
+
+							statobj.total.alloc = statobj.total.alloc + statobj[task].alloc;
+							statobj.total.sold = statobj.total.sold + statobj[task].sold;
+							statobj[task].todo = 0;
+						}
+					}
+					statobj.total.hold = statobj.total.alloc - statobj.total.sold;
+					for (var task in seasonobj.todo) {
+						statobj[task].todo = todosum(seasonobj.todo[task]);
+						statobj.total.todo = statobj.total.todo + statobj[task].todo;
+					}
+
+					document.getElementById(id).innerHTML = createTableHTML(statobj);
+				}
+			};
+			xmlhttp.open("GET", url, true);
+			xmlhttp.send();
+		}
+
+		function getTextFileFromURL(url, id) {
+			var xmlhttp = new XMLHttpRequest();
+			xmlhttp.onreadystatechange = function () {
+				alert(xmlhttp.readyState);
+				alert(xmlhttp.status);
+				alert(xmlhttp.responseText);
+				if (xmlhttp.readyState == 4 && xmlhttp.status == 200) {
+					var text = xmlhttp.responseText;
+					document.getElementById(id).innerHTML = marked.parse(text);
+				}
+			};
+			xmlhttp.open("GET", url, true);
+			xmlhttp.send();
+		}
+
+		function datestr(diff = 0) {
+			var theDate = new Date();
+			theDate.setDate(theDate.getDate() + diff);
+
+			var year = theDate.getFullYear();
+			var month = theDate.getMonth() + 1 < 10 ? "0" + (theDate.getMonth() + 1) : theDate.getMonth() + 1;
+			var day = theDate.getDate() < 10 ? "0" + theDate.getDate() : theDate.getDate();
+			var dateStr = year + "" + month + "" + day;
+
+			return dateStr;
+		}
+
+		function todosum(todoarray) {
+			var sum = 0;
+
+			for (var i in todoarray) {
+				for (var key in todoarray[i]) {
+					if (!isNaN(parseInt(key))) {
+						sum = sum + parseInt(key);
+					} else if (key == "bind") {
+						sum = sum + todosum(todoarray[i][key]);
+					}
+				}
+			}
+
+			return sum;
+		}
+
+		function createTableHTML(data) {
+			let tableHTML = '<table border="1"><tr>';
+			tableHTML += `<th>task</th>`;
+			Object.keys(data.PSMD).forEach(key => {
+				tableHTML += `<th>${key}</th>`;
+			});
+			tableHTML += '</tr>';
+
+			for(var task in data){
+				tableHTML += '<tr><td>' + task +'</td>';
+				for(var item in data[task]){
+					tableHTML += '<td>' + data[task][item] + '</td>';
+				}
+				tableHTML += '</tr>';
+			}
+
+			tableHTML += '</table>';
+			return tableHTML;
+		}
+	</script>
+</head>
+
+<body>
+	<div id="draft"></div>
+	<br /><br />
+	<hr /><br /><br />
+	<div id="today"></div>
+	<br /><br />
+	<hr /><br /><br />
+	<div id="tomorrow"></div>
+	<br /><br />
+	<hr /><br />
+	season stat:<br />
+	<div id="todo"></div>
+</body>
+
+</html>

release/term.html

@@ -0,0 +1,61 @@
+<!DOCTYPE html>
+<html lang="zh-cn">
+
+<head>
+	<meta charset="UTF-8">
+	<title>entry page</title>
+	<script type="text/javascript" src="yaml.min.js"></script>
+
+	<script>
+		var PSMDdataurl;
+
+		window.onload = function () {
+			if (document.domain == "hyg.codeberg.page") {
+				PSMDdataurl = "https://hyg.codeberg.page/PSMD/@master/data";
+			}else if (document.domain == "hyg.github.io") {
+                PSMDdataurl = "http://hyg.github.io/PSMD/data";
+			}else if (document.domain == "today.mars22.com") {
+                PSMDdataurl = "http://today.mars22.com/PSMD/data";
+			}
+			
+			getTextFileFromURL(PSMDdataurl+"/term.d0111eb4.yaml", "term");
+			//getTextFileFromURL(tomorrowurl, "readme");
+		}
+
+		function getTextFileFromURL(url, id) {
+			var xmlhttp = new XMLHttpRequest();
+			xmlhttp.onreadystatechange = function () {
+				if (xmlhttp.readyState == 4 && xmlhttp.status == 200) {
+					var text = xmlhttp.responseText;
+					document.getElementById(id).innerHTML = text;
+                    var termobj = YAML.parse(text);
+                    for(var i in termobj.item){
+                        confirm("是否符合："+termobj.item[i].text);
+                    }
+				}
+			};
+			xmlhttp.open("GET", url, true);
+			xmlhttp.send();
+		}
+
+		function datestr(diff = 0) {
+			var theDate = new Date();
+			theDate.setDate(theDate.getDate() + diff);
+
+			var year = theDate.getFullYear();
+			var month = theDate.getMonth() + 1 < 10 ? "0" + (theDate.getMonth() + 1) : theDate.getMonth() + 1;
+			var day = theDate.getDate() < 10 ? "0" + theDate.getDate() : theDate.getDate();
+			var dateStr = year + "" + month + "" + day;
+
+			return dateStr;
+		}
+	</script>
+</head>
+
+<body>
+	<div id="term"></div>
+	<br /><br /><hr /><br /><br />
+	<div id="readme"></div>
+</body>
+
+</html>

release/time.js

@@ -0,0 +1,275 @@
+var fs = require('fs');
+var yaml = require('js-yaml');
+
+let gitpath = "../../";
+let rawrepopath = "../../raw/";
+let draftrepopath = "../../draft/";
+
+let helpstr = `
+node time:  today's draft metadata + draft markdown → day log markdown
+node time 1: diff day's draft metadata + draft markdown → day log markdown
+node time 20240417: 20240417's draft metadata + draft markdown → day log markdown
+node time init 1: plan 1 metadata → today draft metadata
+node time init: draft metadata + plan metadata → today plan markdown + draft markdown
+`;
+let today = datestr();
+
+// read the arguments
+var arguments = process.argv.splice(2);
+if (arguments.length > 0) {
+    if ((arguments.length == 1) & (arguments[0] == "init")) {
+        // node time init: draft metadata + plan metadata → today plan markdown
+        var date = datestr();
+        makedayplan(date);
+    } else if ((arguments.length == 2) & (arguments[0] == "init")) {
+        // node time init 1: plan 1 metadata → today draft metadata
+        var date = datestr();
+        var plan = arguments[1];
+        makedaydraft(date, plan)
+    } else if ((arguments.length == 1) & (arguments[0].length == 8)) {
+        //node time 20240417: 20240417's draft metadata + draft markdown → day log markdown
+        var date = parseInt(arguments[0]).toString();
+        makedaylog(date);
+    } else if ((arguments.length == 1) & (arguments[0].length != 8) & (!isNaN(arguments[0]))) {
+        //node time 1: diff day's draft metadata + draft markdown → day log markdown
+        var diff = parseInt(arguments[0]);
+        var date = datestr(diff);
+        makedaylog(date);
+    } else {
+        console.log(helpstr);
+        process.exit();
+    }
+} else {
+    //node time:  today's draft metadata + draft markdown → day log markdown
+    var date = datestr();
+    makedaylog(date);
+}
+
+function makedaydraft(date, plan) {
+    var planobj = yaml.load(fs.readFileSync("plan.yaml", 'utf8'));
+    var time = planobj.dayplan[plan].time;
+
+    var draftmetadata = new Object();
+    var drafttimearray = new Array();
+    //console.log(typeof(date));
+    draftmetadata.date = parseInt(date);
+    draftmetadata.plan = parseInt(plan);
+    for (var i in time) {
+        if (time[i].type == "work") {
+            var timeperiod = new Object();
+            timeperiod.begin = date + time[i].beginhour.toString().padStart(2, '0') + time[i].beginminute.toString().padStart(2, '0') + "00";
+            timeperiod.amount = time[i].amount;
+            timeperiod.type = "work";
+            timeperiod.subject = "tbd";
+            timeperiod.name = "tbd";
+            timeperiod.output = "draft/" + date.slice(0, 4) + "/" + date.slice(4, 6) + "/" + timeperiod.begin + ".md";
+            drafttimearray.push(timeperiod);
+        }
+    }
+    draftmetadata.time = drafttimearray;
+
+    var filename = draftrepopath + date.slice(0, 4) + "/" + date.slice(4, 6) + "/" + "d." + date + ".yaml";
+    console.log(filename);
+    console.log(yaml.dump(draftmetadata));
+    fs.writeFileSync(filename, yaml.dump(draftmetadata));
+}
+
+function makedayplan(date) {
+    //read wake time from raw repo
+    //var rawhealthfilename = "health/d." + date + ".yaml";
+    //var rawhealthfile = yaml.load(fs.readFileSync(rawrepopath + rawhealthfilename, 'utf8'));
+    //var waketime = rawhealthfile.wake.time;
+    //console.log("wake time:"+waketime);
+
+    var draftmetafilename = draftrepopath + date.slice(0, 4) + "/" + date.slice(4, 6) + "/" + "d." + date + ".yaml";
+    var draftmetadata;
+    try {
+        if (fs.existsSync(draftmetafilename)) {
+            draftmetadata = yaml.load(fs.readFileSync(draftmetafilename, 'utf8'));
+        } else {
+            console.log("the draft metadata isn't exist:" + draftmetafilename);
+            process.exit();
+        }
+    } catch (e) {
+        // failure
+        console.log("yaml read error！" + e);
+        process.exit();
+    }
+    var plan = draftmetadata.plan;
+
+    var timeslicename = new Object();
+    for (var i in draftmetadata.time) {
+        timeslicename[draftmetadata.time[i].begin] = draftmetadata.time[i].name;
+    }
+
+
+    var planobj = yaml.load(fs.readFileSync("plan.yaml", 'utf8'));
+    //var planstr = planobj.dayplan[plan].planstr;
+
+    var planstr = `| 时间片 | 时长 | 用途 | 手稿 |
+| --- | --- | --- | --- |
+`;
+    for (var i in planobj.dayplan[plan].time) {
+        var timeslice = planobj.dayplan[plan].time[i];
+        var beginhour = timeslice.beginhour;
+        var beginminute = timeslice.beginminute;
+        var amount = timeslice.amount;
+        var endhour = beginhour + parseInt((beginminute + amount -1) / 60);
+        var endminute = (beginminute + amount -1) % 60;
+
+        var begintime = date + beginhour.toString().padStart(2, '0') + beginminute.toString().padStart(2, '0') + "00";
+
+        var draftstr = "";
+        if (timeslicename[begintime] != null) {
+            draftstr = draftstr + timeslicename[begintime] + "  ";
+        }
+        if (timeslice.namelink != null) {
+            draftstr = draftstr + "[在线同步](" + timeslice.namelink + ")";
+        }
+        if (timeslice.type == "work") {
+
+            var draftfilename = draftrepopath + date.slice(0, 4) + "/" + date.slice(4, 6) + "/" + begintime + ".md";
+            draftstr = draftstr + " [离线归档](" + draftfilename + ")";
+        }
+
+        planstr = planstr + "| " + beginhour.toString().padStart(2, '0') + ":" + beginminute.toString().padStart(2, '0') + "~" + endhour.toString().padStart(2, '0') + ":" + endminute.toString().padStart(2, '0') + " | " + amount + " | " + timeslice.name + " | " + draftstr + " |\n";
+    }    
+    planstr = planstr + "\n" + planobj.dayplan[plan].readme;
+    //console.log("planstr:\n"+planstr);
+
+    var dayplan = "# " + date + "\n\n计划  \n\n根据[ego模型时间接口](https://gitee.com/hyg/blog/blob/master/timeflow.md)，今天绑定模版" + plan + "。\n\n" + planstr + "\n\n---\n\n";
+
+    for (var i in draftmetadata.time) {
+        var subject = draftmetadata.time[i].subject;
+        var taskname = draftmetadata.time[i].name;
+        if (taskname === undefined) {
+            taskname = "无名任务";
+        }
+        var output = draftmetadata.time[i].output;
+
+        dayplan = dayplan + "- task:" + subject + "  [" + taskname + "](../" + gitpath + output + ")  \n";
+
+        var begintime = draftmetadata.time[i].begin;
+        var beginhour = parseInt((begintime - parseInt(begintime / 1000000) * 1000000) / 10000);
+        var beginminute = parseInt((begintime - parseInt(begintime / 10000) * 10000) / 100);
+        var amount = draftmetadata.time[i].amount;
+        var endhour = beginhour + parseInt((beginminute + amount) / 60);
+        var endminute = (beginminute + amount) % 60;
+        //console.log(begintime,beginhour,beginminute,amount,endhour,endminute);
+        var timestr = "## " + beginhour.toString().padStart(2, "0") + ":" + beginminute.toString().padStart(2, "0") + " ~ " + endhour.toString().padStart(2, "0") + ":" + endminute.toString().padStart(2, "0") + "\n\n" + taskname + "\n\n";
+
+        var timeviewfilename = draftrepopath + date.slice(0, 4) + "/" + date.slice(4, 6) + "/" + begintime + ".md";
+        console.log("time slice draft file name:" + timeviewfilename);
+        console.log(timestr);
+        fs.writeFileSync(timeviewfilename, timestr);
+    }
+
+    var dayplanfilename = "time/d." + date + ".md";
+    console.log("dayplan file name:\n" + dayplanfilename + "\ncontent:\n" + dayplan);
+    fs.writeFileSync(dayplanfilename, dayplan);
+}
+
+function makedaylog(date) {
+    var year = date.slice(0, 4);
+    var month = date.slice(4, 6);
+
+    var draftmetafilename = draftrepopath + date.slice(0, 4) + "/" + date.slice(4, 6) + "/" + "d." + date + ".yaml";
+    var draftmetadata;
+    try {
+        if (fs.existsSync(draftmetafilename)) {
+            draftmetadata = yaml.load(fs.readFileSync(draftmetafilename, 'utf8'));
+        } else {
+            console.log("the log isn't exist:" + draftmetafilename);
+            process.exit();
+        }
+    } catch (e) {
+        // failure
+        console.log("yaml read error！" + e);
+        process.exit();
+    }
+    var daylog = "# " + date + "\n\n小结  \n\n<a id=\"top\"></a>\n";
+
+    var plan = draftmetadata.plan;
+    if (plan != null) {
+        var planobj = yaml.load(fs.readFileSync("plan.yaml", 'utf8'));
+        //var planstr = planobj.dayplan[plan].planstr;
+
+
+        var timeslicename = new Object();
+        for (var i in draftmetadata.time) {
+            timeslicename[draftmetadata.time[i].begin] = draftmetadata.time[i].name;
+        }
+
+        var planstr = `| 时间片 | 时长 | 用途 | 手稿 |
+| --- | --- | --- | --- |
+`;
+        for (var i in planobj.dayplan[plan].time) {
+            var timeslice = planobj.dayplan[plan].time[i];
+            var beginhour = timeslice.beginhour;
+            var beginminute = timeslice.beginminute;
+            var amount = timeslice.amount;
+            var endhour = beginhour + parseInt((beginminute + amount -1) / 60);
+            var endminute = (beginminute + amount -1) % 60;
+
+            var begintime = date + beginhour.toString().padStart(2, '0') + beginminute.toString().padStart(2, '0') + "00";
+
+            var draftstr = "";
+            if ((timeslicename[begintime] != null)&(timeslice.type == "work")) {
+                draftstr = draftstr + "[" + timeslicename[begintime] + "](#" + begintime + ")" ;
+            
+
+                //var draftfilename = draftrepopath + date.slice(0, 4) + "/" + date.slice(4, 6) + "/" + begintime + ".md";
+                //draftstr = draftstr + " [离线归档](" + draftfilename + ")";
+            }
+
+            planstr = planstr + "| " + beginhour.toString().padStart(2, '0') + ":" + beginminute.toString().padStart(2, '0') + "~" + endhour.toString().padStart(2, '0') + ":" + endminute.toString().padStart(2, '0') + " | " + amount + " | " + timeslice.name + " | " + draftstr + " |\n";
+        }
+
+        planstr = planstr + "\n" + planobj.dayplan[plan].readme;
+
+        daylog = daylog + "根据[ego模型时间接口](https://gitee.com/hyg/blog/blob/master/timeflow.md)，今天绑定模版" + plan + "。\n\n" + planstr;
+    } else {
+        daylog = daylog + "当天未绑定时间模版"
+    }
+    var indexstr = "\n\n---\n<a id=\"index\"></a>\n";
+    var logstr = "";
+    for (t in draftmetadata.time) {
+        var timelog = draftmetadata.time[t];
+        //console.log(typeof(timelog.begin));
+        var hour = timelog.begin.toString().slice(8, 10);
+        var minute = timelog.begin.toString().slice(10, 12);
+        var taskname = timelog.name;
+        //console.log(taskname);
+        if (taskname === undefined) {
+            taskname = "无名任务";
+        }
+
+        indexstr = indexstr + "- " + hour + ":" + minute + "\t[" + taskname + "](#" + timelog.begin + ")  \n";
+
+        var outputfilename = gitpath + timelog.output;
+        var outputstr = fs.readFileSync(outputfilename, 'utf8')
+        logstr = logstr + "\n\n[top](#top) | [index](#index)\n<a id=\"" + timelog.begin + "\"></a>\n" + outputstr;
+    }
+
+    var daylog = daylog + indexstr + "\n---\n" + logstr;
+    //console.log(daylog);
+
+    var daylogfilename = "time/d." + date + ".md";
+    console.log("daylog file name:\n" + daylogfilename + "\ncontent:\n" + daylog);
+    fs.writeFileSync(daylogfilename, daylog);
+}
+
+// utils
+function datestr(diff = 0) {
+    var theDate = new Date();
+    //theDate.setDate(theDate.getDate() - 1);
+    theDate.setDate(theDate.getDate() + diff);
+
+    var year = theDate.getFullYear();
+    var month = theDate.getMonth() + 1 < 10 ? "0" + (theDate.getMonth() + 1) : theDate.getMonth() + 1;
+    var day = theDate.getDate() < 10 ? "0" + theDate.getDate() : theDate.getDate();
+    var dateStr = year + "" + month + "" + day;
+
+    //console.log("datestr retrun:"+dateStr);
+    return dateStr;
+}

release/time/d.20240413.md

@@ -0,0 +1,44 @@
+# 2024.04.13.
+
+小结
+
+## 时间表
+
+根据[ego模型时间接口](https://gitee.com/hyg/blog/blob/master/timeflow.md)，今天绑定模版一。
+| 时间片 | 时长 | 用途 |
+| --- | --- | --- |
+| 4:00~4:14 | 15 | 休整 |
+| 4:15~5:14 | 60 | 备餐、运动 |
+| 5:15~5:59 | 45 | 早餐 |
+| 6:00~6:44 | 45 | 会议、自习 |
+| 6:45~7:44 | 60 | 休整  |
+| 7:45~8:44 | 60 | [静默工作](http://simp.ly/p/xtgD4F) |
+| 8:45~9:29 | 45 | 休整 |
+| 9:30~10:59 | 90 | [静默工作](http://simp.ly/p/j1SspP) |
+| 11:00~13:59 | 180 | 备餐、午餐午休 |
+| 14:00~14:29 | 30 | [静默工作](http://simp.ly/p/8t3vlk)  |
+| 14:30~14:59 | 30 | [静默工作](http://simp.ly/p/5k9gJy) |
+| 15:00~15:59 | 60 | 休整 |
+| 16:00~16:59 | 60 | [静默工作](http://simp.ly/p/4QDThK) [小结](#1600)|
+| 17:00~18:59 | 120 | 晚餐 |
+| 19:00~19:59 | 60 | 讨论、整理提交 |
+
+
+<a id="1600"></a>
+###  16:00~16:59
+
+时长：60分钟
+主题：ego
+手稿：/draft/2024/04/202404131600.md
+
+个人模型
+
+- 手稿可以先发到simplenote，小结时整理到draft库（小结本身发布到blog库release文件夹）；
+- draft库中同类内容的经验，整理到note库；
+- 公开发布内容，含要约和契约，记录在blog库release文件夹；
+	- 重要的契约和共同体，整理为单独git库； 
+- 小范围发布内容及其自动化，含要约和契约、含metadata和code，记录在单独git库；
+- note库、release文件夹中经验的自动化，含metadata和code，整理为单独git库；
+- raw库输出工作时间片；
+- ego库调度raw模型产生的工作时间片和各契约定义的资产，输出draft、note、专用库内容（只是个人模型的一部分）；
+- Let'sX集体提炼关键能力，从draft、note到共同体整理。

release/time/d.20240414.md

@@ -0,0 +1,132 @@
+# 20240414
+
+小结
+
+根据[ego模型时间接口](https://gitee.com/hyg/blog/blob/master/timeflow.md)，今天绑定模版2。
+
+| 时间片 | 时长 | 用途 |
+| --- | --- | --- |
+| 4:00~4:14 | 15 | 休整 |
+| 4:15~5:14 | 60 | 备餐、运动 |
+| 5:15~5:59 | 45 | 早餐 |
+| 6:00~6:44 | 45 | 会议、自习 |
+| 6:45~7:44 | 60 | 休整  |
+| 7:45~10:59 | 195 | [工作](http://simp.ly/p/3GXNTh)  [小结](#0745)|
+| 11:00~13:59 | 180 | 备餐、午餐午休 |
+| 14:00~15:29 | 90 | [工作](http://simp.ly/p/lsBYG9)  [小结](#1400)|
+| 15:30~15:59 | 30 | 休整 |
+| 16:00~16:59 | 60 | [工作](http://simp.ly/p/MpcbHD)  [小结](#1600)|
+| 17:00~18:59 | 120 | 晚餐 |
+| 19:00~19:59 | 60 | 讨论、整理提交 |
+
+工作的同时可以在线讨论。
+
+<a id="0745"></a>
+## 7:45~10:59
+
+入门目录 @ PSMD
+
+- 在符合附件30的前提下：
+  -在符合附件42的前提下，解决以下问题：
+    - 讨论解决附件42中问题是否需要遵守附件31、32、33、34并执行讨论结果，向外寻求解决方案时，在明确以上四项决定鸡执行记录的。
+  - 在符合附件43的前提下，解决以下问题：
+    -  讨论解决附件43中问题是否需要遵守附件31、32、33、34并执行讨论结果，向外寻求解决方案时，在明确以上四项决定鸡执行记录的。
+   - 在不符合附件42、43的前提下，解决以下问题：
+    - 守成。寻找新商机再按本目录独立设计制度。
+- 如果不符合附件30，则无法判断是否符合福建31、32、33、34，视为不遵守。
+  - 在业务背景下，基于既成事实博弈。
+
+### 附件30 有效的内部监管
+定义：已有基础制度和人员，能保证书面规章的违约成本高于收益。规定监管人员以外的内部成员、外部合作方不需要额外为此耗费资源。
+
+### 附件31 PS标准
+
+1. 规章条款的上下级关系，根据制定、修订权定义。
+1. 人员的上下级关系，根据任免权定义。
+1.  严格执行制定、修订程序。上级规章条款未生效（或被实质架空）时，不提交、不讨论下级规章条款。
+1.  严格执行任免程序。上级人员未赴任（或被实质架空）时，不提名、不讨论下级人员。
+---
+说明：
+
+- 以“规章条款”为单位。比如某公司章程有一条：股东会三分之二表决权通过可以修订章程。这条本身就在章程里面，所以也能修订自己。（比如修改为：股东会四分之三表决权通过可以修订章程。）这个条款就比章程的其它条款都高一级。无论怎么组合编集，都不影响这种层级关系。
+- 比如规章写明A任免B和C，即使在其它文件使用“B是C上级”、“C接受B的指令”这类措辞，本标准下BC平级、都是A下级。A缺席时B讨论C的人选即违规（如果B是章程中有PS标准的账号，会立刻被强制注销财产充公）。
+- 无法判断时按最坏情况处理，比如因保密制度不能阅读就按未生效、未被执行看待。
+- 上级规章制定过程可以讨论规章草案下的工作场景，包括制定下级规章的场景。只有特定上级规章导致特定下级规章草案不能产生，引入讨论才有意义。一旦离开上级规章制定程序的时间、地点、人员这些条件就不能提前讨论下级规章，因为这时上级规章（下级规章制定修订程序）还没有生效，不应该暗示自己的内定角色。
+- 待实现的后续规则：不遵守则由自然人承担。比如一个共同体的上级规章被架空时讨论下级规章，则以该自然人代替共同体承担规章中的权利，比如向执行下级规章的员工发工资。（也就是从共同体剥离，并入个人领域）
+
+### 附件32 保密规则
+
+1. 所有人员的所有工作结果默认为公开，对外发布。
+1. 按PS标准上溯得出顶级规章，从顶级规章到保密制度之间的上下级规章链条（包括保密制度），这组规章的密级均为公开，这组规章的工作记录的密级由该规章自行规定，保密制度不得改变。
+1. 一份文档所有用途使用相同方式取得。如果因不可抗力需要改变方式，应规定不可抗力的判定程序，确保内容相同。
+1. 如果在密级规定范围内的人员都没有能力完成任务，制定保密制度相应条款的人员承担主要责任，赔偿损失。
+---
+说明：
+- 顶层权利分配规则肯定在保密制度之上，因此PSMD只讨论公开资料。
+- 如果某个审议环节从某网址取得一份资料，这份资料从产生、生效、所有使用环节都从这个网址获得。比如是指令，下达指令者应在这个网址发布指令，然后通知接受指令者去阅读。
+
+### 附件33 制定规则
+
+1. 制定规章要明确预期效果。
+1. 接到质询时必须提供依据，依据必须是 外部法律 or 案例统计 两种方式之一。
+1. 如果是旧版本修订，制定者可以提出适用范围。只能向该适用范围内使用旧版规章的共同体发送修订通知。
+1. 分支隔离规则适用于制定规章。一个分支的共同体内制定规章时，所提供依据如果使用其它分支的案例，将自动增加切换规章的动议作为前提。
+---
+说明：
+- 比如不采用 PS标准的共同体，制定规章时以采用PS标准分支下的案例为依据，则自动增加采用PS标准的动议，切换生效之后才能讨论所制定规章。
+
+### 附件34 分支隔离规则
+
+1. 对相同事项的不同处理方法，视为同一规章的不同分支版本。对该事项未做任何规定，也视为其中一个分支版本。
+1. 实际通过生效、使用某分支版本的规章，即为支持该分支版本，反对其它分支版本。
+1. 规章使用过程遇到问题可以提出修订委托，如发往反对者将自动转为帮助切换规章的委托（切换到对方实际使用的分支版本）。如果是付费委托，受托者只需回答实际收到的问题。
+1. 查询资料时，未做任何规定分支可以列出所有分支的资料，其它分支只列出本分支的资料。
+
+说明：
+- 例如：共同体A采用PS标准，共同体B、C没有。当B在上级规章未生效时要讨论下级规章。B向C提出咨询，C收到B发出的原始咨询内容。B向A提出咨询，咨询内容自动转化为“如何在规章中增加PS标准”，A无法收到B发出的原始咨询内容。这条规则主要提醒自我安慰性的求助，向反对者求助就是承认自身行为导致问题无解。
+- 在父项目，各隔离分支将使用不同记账单位。相同金额不同单位，视为同工同酬。比如采用PS标准的分支使用M为单位，不采用PS标准分支使用N为单位，自由兑换的平衡点是1M兑换10N。一项工作的报酬是5，两个分支账号分别得到5M（可兑换50N）、5N的报酬。
+
+### 附件42 资源不足
+定义：需要以未来的收入换取资源，而且需要与同行争夺。
+反向的情况，是创始时能一次筹集到足够的资源，可见未来的收入和积累都超过支出。或者需要以未来的收入换取资源，但是不需要竞争即可获得充足资源。
+
+### 附件 43 能力和贡献持续变化
+定义：核心人员凭借职权高估自己的贡献、低估非核心成员的贡献，这样做的综合效果更符合他们的利益。
+反向的情况，核心人员准确估算包括自己在内的成员贡献，这样做的综合效果更符合他们的利益。
+
+
+<a id="1400"></a>
+## 14:00~15:29
+
+ego
+
+自动生成以下日志文件：
+D:\huangyg\git\blog\release\time\d.20240413.md
+
+一旦创建就不再维护md文件，也不回头修改yaml文件。
+ego项目提供meta data，
+draft项目提供当天的yaml和素材文件。
+产生当天日志：只是简单介绍当太难时间分配和公开的手稿。ego的资源调度依赖以后的事件，因此只提供入口和参数，暂时不把内容写入日志。
+
+输出：
+blog\release\plan.yaml      时间模版元数据
+blog\release\time.js           自动生成日计划
+
+下一步是：
+1. 根据waketime自动生成时间表，而不是固定始末时间。
+    - 参考：https://github.com/hyg/gathering/blob/gh-pages/2021/Q2/schadule.jsonld
+    - 参考：https://github.com/hyg/gathering/blob/gh-pages/2021/Q2/index.html
+1. 创建日志文件。
+
+<a id="1600"></a>
+## 16:00~16:59
+
+PSMD
+
+修订早上7点的工作结果。
+加入PSMD新版的规则。
+
+下一步的工作：
+1. 调整PSMD新版基础规则的表述。
+1. 设计自动工具。
+

release/time/d.20240415.md

@@ -0,0 +1,188 @@
+# 20240415
+
+小结
+
+根据[ego模型时间接口](https://gitee.com/hyg/blog/blob/master/timeflow.md)，今天绑定模版1。
+
+| 时间片 | 时长 | 用途 |
+| --- | --- | --- |
+| 4:00~4:14 | 15 | 休整 |
+| 4:15~5:14 | 60 | 备餐、运动 |
+| 5:15~5:59 | 45 | 早餐 |
+| 6:00~6:44 | 45 | 会议、自习 |
+| 6:45~7:44 | 60 | 休整  |
+| 7:45~8:44 | 60 | [静默工作](http://simp.ly/p/xtgD4F) [小结](#0745) |
+| 8:45~9:29 | 45 | 休整 |
+| 9:30~10:59 | 90 | [静默工作](http://simp.ly/p/j1SspP)  [小结](#0900) |
+| 11:00~13:59 | 180 | 备餐、午餐午休 |
+| 14:00~14:29 | 30 | [静默工作](http://simp.ly/p/8t3vlk)   [小结](#1400) |
+| 14:30~14:59 | 30 | [静默工作](http://simp.ly/p/5k9gJy)  [小结](#1430) |
+| 15:00~15:59 | 60 | 休整 |
+| 16:00~16:59 | 60 | [静默工作](http://simp.ly/p/4QDThK)  [小结](#1600) |
+| 17:00~18:59 | 120 | 晚餐 |
+| 19:00~19:59 | 60 | 讨论、整理提交 |
+
+模版一采用静默工作方式。  
+希望讨论的提纲发到 [huangyg@mars22.com](mailto:huangyg@mars22.com)，通常安排在后面某天的某天的早餐（5:15~5:59）或会议时间（6:00~6:45）。
+
+<a id="0745"></a>
+## 7:45~8:44
+
+整理任务看板
+
+1. meeting：
+	- 异步议事的协作规范
+	- 三页面设计细化
+	- 熟悉软件测试，工具
+	- m90*2，编程。
+1. PSMD：
+	- PPT，blog
+	- README工作计划预算
+	- m60、m90，README工作计划预算
+	- 1406、1609向成长模式下的原始模型植入
+	- PPT blog
+	- m45、m45、m60，PPT blog
+	- README PLAN BUDGET
+1. infra：
+	- 用管道代替水池，pipe->pool，不用存款，用契约。
+	- 信任网络中加入ipfs的swap类似机制，也许已有->结合。
+	- 金融服务：
+		- 可能性
+		- 不变的API
+	- PSMD、infra使用的几种“层次”，向ego融合。
+	- ICO创业大军会死在哪里？
+	- 自动账户读写数据，以太坊读写隔离
+	- 熟悉EOS白皮书
+	- v0.2设计
+	- v0.2 coding，yaml+turtle，出demo【https://github.com/iopipe/turtle/issues 很久没动静了，理念可以参考。】
+1. ITW：
+	- 弱化线下招生，强化线上招生，鼓励生源互换，考虑信任网络。
+	- 适合在家，持续对抗，维护身份认同的机制。
+1. let‘X
+	- 把knowledge归入letcongnize 【并没有创建knowledge git库，确实需要定义知识的互相关系，偏差-解决方案 作为元数据，各库之间互相推介，是可选方案。需要定义这套方案的提出和修订。】
+1. XUEMEN：
+	- IST机制，与JT互通、浮动。
+	- 理顺AER自动生成规则。
+
+二季度规划（4.15起，按45天）：
+- 30天绑定模版1：m90*30，m60*60，m30*60
+- 5天绑定模版2：m195*5，m90*5，m60*5
+- 10天绑定模版3：
+	- PSMD：m195*5，m90*5，m60*5
+	- TBD：m195*5，m90*5，m60*5
+- 外勤、缺勤在6月补回。
+
+EGO：m30*6，m60*20，m90*13，m195*1
+	- 日计划、小结自动生成：
+		- 手工操作：m30*3，m60*1
+		- 代码：m60*6，m90*5，m195*1
+	- 季度规划、小结自动生成：
+		- 手工操作：m30*2，m60*2
+		- 代码：m60*4，m90*4
+	- 时间片*任务匹配
+		- 手工操作：m30*1，m60*1
+		- 代码：m60*6，m90*4
+
+PSMD：m30*7，m60*37，m90*20，m195*4，模版3*2
+	- 入门目录：
+		- 手工：m30*2，m60*4，m90*1
+		- 代码：m60*4，m90*4
+			- 带有升级、追溯功能的draft->blog\release机制。每个版本的要约、合同章节在draft中的日yaml中定义，自动整理后生成索引，内容以哈希命名、统一发布。引用处定义是某版本、最新版本（可多选），最新版本的可以自动产生正确的链接。旧版本详情有新版本入口。
+	- default
+		- 手工：m30*1，m60*2，m90*1
+		- 代码：m60*4，m90*4，m195*1
+	- 1406
+		- 手工：m30*2，m60*3，m90*1
+		- 代码：m60*8，m90*4，m195*1，模版3*1
+	- 1609
+		- 手工：m30*2，m60*4，m90*1
+		- 代码：m60*8，m90*4，m195*2，模版3*1
+
+XUEMEN：m30*40（47），m60*6（8），m90*2（2）
+
+<a id="0930"></a>
+##  9:30~10:59
+
+PSMD 入门目录
+
+针对不同条件给出建议如下：
+- 如果不能按照附件20增加补充信息，建议在业务背景下，基于既成事实博弈。具体可以参考default标准模型。还在筹备因此无法补充信息的，可以参考booting标准模型。
+- 如果可以，请根据附件20增加关于附件30的补充信息。
+	- 如果判断符合附件30的情况，请根据附件20增加关于附件42、43的补充信息。
+		- 如果判断符合附件42、43之一的情况，请根据附件20增加关于附件31、32、33、34的补充信息。
+			- 如果判断符合附件31、32、33、34的情况，建议：使用自定义的规章解决资源和重构问题，具体可以参考1609、chain等标准模型。
+			- 如果判断不符合31、32、33、34的情况，建议：先参考default+1406标准模型开展业务，逐步完善规章，取得进步后重新增加关于附件31、32、33、34的补充信息。
+		- 如果判断附件42、43都不符合的情况，建议：先参考default+1406标准模型开展业务。情况变化或出现新商机再增加补充信息。
+	- 如果判断不符合附件30的情况，即使按照附件20增加补充信息也无法判断附件30~34的情况，因此建议：在业务背景下，基于既成事实博弈。具体可以参考default标准模型。
+
+附件20 符合某条件
+对自述难以核实的情况下，可以按照以下方式之一增加补充信息：
+1. 涉事各方全体同意，推举一名或多名保证人：
+	- 保证人在其它事项中符合该条件，并按照本附件提供补充信息。
+	- 由保证人调查涉事各方是否符合该条件，将调查记录作为补充信息。
+1. 涉事各方分别自述，交叉核实。将所有记录合并作为补充信息。
+1. 涉事各方签署 附件21 容器规则，承诺遵守该条件，将生效、执行的记录作为补充信息。
+
+其他方根据补充信息作出判断后，进入后续讨论。
+
+附件21 容器规则
+    1. 自然人可以公示一组规则（以下称为“章程”），并注入启动资金创建有限责任的虚拟主体（以下称为“账号”）。
+    1. 每个账号有独立的财产。由章程自行规定管理细则。
+    1. 每个账号可以独立对外签订合同。合同应明确规定仅以该账号财产承担责任。
+    1. 所有合同应该针对章程约定合规仲裁的方式。一旦违反章程则强制注销该账号，以最后的合规行为时间为注销时间，由当时有效合同的其他方组织清算，默认一份契约一票。
+    1. 账号财产可以跨账号调用，但转出账号的余额不得少于该账号签订的所有合同的待付款项（包括极限情况下的赔偿）总和。具体金额以对应收款方的理解为准。
+    1. 账号签订的所有合同结束、且合同中所有赔偿责任结束后，自然人可以注销该账号。
+    1. 章程条款适用分支隔离规则 。
+
+<a id="1400"></a>
+## 14:00~14:29
+
+国密simple
+
+测试了sm2的创建密钥、压缩公钥、验证密钥。 
+输出：js.simple/sm.crypt/local.2.html
+
+<a id="1430"></a>
+## 14:30~14:59
+
+ego entry页面
+
+- github访问不方便
+- gitee实名认证比较麻烦
+- codeberg访问正常，page服务也比较方便：
+	- 不需要创建专门branch也可以
+
+入口地址
+https://hyg.codeberg.page/blog/@master/release/entry.html
+http://z6b.cn/Hix8d
+https://t.cn/A6TWZQJ0
+
+下一步：在页面中显示markdown内容，以便组合多个md文件和yaml文件的内容。
+
+<a id="1600"></a>
+##  16:00~16:59
+
+PSMD 自动入门目录
+
+针对某问题的入口：在今天上午的[手工范例](202404150930.md)中，如果对方针对附件42的问题提问，应自动生成以下回复：
+
+针对不同条件给出建议如下：
+1. 使用自定义的规章解决资源和重构问题，具体可以参考1609、chain等标准模型。
+	- 同意按照附件20增加补充信息，补充关于附件30，42，31、32、33、34的补充信息，且均判断为符合。
+1. 先参考default+1406标准模型开展业务，逐步完善规章，取得进步后重新增加关于附件31、32、33、34的补充信息。
+	- 同意按照附件20增加补充信息，补充关于附件30，42，31、32、33、34的补充信息，且判断符合附件30、42，不全符合符合31、32、33、34。
+1. 在业务背景下，基于既成事实博弈。具体可以参考default标准模型。
+	- 不能按照附件20增加补充信息。
+	- 同意按照附件20增加补充信息，补充关于附件30的补充信息，且判断为不符合。
+1. 参考booting标准模型。
+	- 还在筹备因此无法补充信息的。
+
+如果有其它可行方案请发到<huangyg@mars22.com>，我将按照附件21核实。
+
+附件21 实施效果的核实
+
+1. 公布完整、连续、不可删改的执行记录，证实方案的效果。
+	- 如果以前的执行记录不符合以上条件，可以在愿意按标准公布记录的独立第三方验证。
+1. 已发布开放的要约，只有取得该效果才有收益。
+
+在 js.simple/schame 下创建 demo.yaml demo.js 设计数据结构并完成解析。

release/time/d.20240416.md

@@ -0,0 +1,459 @@
+# 20240416
+
+小结
+<a id="top"></a>
+根据[ego模型时间接口](https://gitee.com/hyg/blog/blob/master/timeflow.md)，今天绑定模版1。
+
+| 时间片 | 时长 | 用途 |
+| --- | --- | --- |
+| 4:00~4:14 | 15 | 休整 |
+| 4:15~5:14 | 60 | 备餐、运动 |
+| 5:15~5:59 | 45 | 早餐 |
+| 6:00~6:44 | 45 | 会议、自习 |
+| 6:45~7:44 | 60 | 休整  |
+| 7:45~8:44 | 60 | [静默工作](http://simp.ly/p/xtgD4F) |
+| 8:45~9:29 | 45 | 休整 |
+| 9:30~10:59 | 90 | [静默工作](http://simp.ly/p/j1SspP) |
+| 11:00~13:59 | 180 | 备餐、午餐午休 |
+| 14:00~14:29 | 30 | [静默工作](http://simp.ly/p/8t3vlk)  |
+| 14:30~14:59 | 30 | [静默工作](http://simp.ly/p/5k9gJy) |
+| 15:00~15:59 | 60 | 休整 |
+| 16:00~16:59 | 60 | [静默工作](http://simp.ly/p/4QDThK) |
+| 17:00~18:59 | 120 | 晚餐 |
+| 19:00~19:59 | 60 | 讨论、整理提交 |
+
+模版一采用静默工作方式。  
+希望讨论的提纲发到 [huangyg@mars22.com](mailto:huangyg@mars22.com)，通常安排在后面某天的早餐（5:15~5:59）或会议时间（6:00~6:45）。
+
+---
+<a id="index"></a>
+- 07:45	[ego 任务管理的手写范例，metadata数据结构设计](#20240416074500)
+- 09:30	[PSMD 条款设计流程及手写范例，metadata to view 代码](#20240416093000)
+- 14:00	[draft自动生成日小结](#20240416140000)
+- 14:30	[ego entry页面显示markdown](#20240416143000)
+- 16:00	[ego draft to metadata 代码](#20240416160000)
+
+---
+
+
+[top](#top) | [index](#index)
+<a id="20240416074500"></a>
+## 7:45~8:44
+
+ego 任务管理
+
+### 流程
+
+1. 手写draft的时间片md文件，以文字记载task metadata的变更提要。
+1. 手写更新task metadata文件，一级项目在ego，二级以下在一级项目内分配。
+1. 自动统计、生成图表，辅助后续分配，手工或自动调整metadata。
+1. 自动合并成当前的全局metadata文件。
+1. 自动根据全局metadata文件产生：
+	- 各项目简介markdown、html文件；
+	- GTD工具的可选菜单。
+
+### 架构设计
+
+1. 对外显示各项目简介markdown、html文件，并不断更新，它们的结构和内容是相对稳定的。
+1. 内部流程和文件是不断升级变化的：
+	- 文件：draft md→task metadata→全局metadata、ego资源分配metadata
+	- 代码：
+		- task metadata → ego资源分配metadata
+		- task metadata → 统计图表
+		- task metadata → 全局metadata
+		- 全局metadata → 各项目简介markdown、html文件、GTD工具的可选菜单
+
+
+### metadata数据结构
+
+- task metadata
+~~~
+name:
+id:
+parent id:
+start:
+end:
+dependencies:
+	- id:
+	- id:
+path: 
+	- name:
+	  path:
+	  readme: |
+readme: |
+step:
+	- time: 
+	   name:
+	   status:
+	   readme: |
+log:
+	- time:
+	   text: |
+~~~
+
+- 全局metadata
+~~~
+time:
+task:
+	id:
+	  name: 
+	  id:
+	  ...
+	  subtask:
+	  	- name:
+	  	  id:
+~~~
+
+### metadata范例
+
+1. 在ego的git库中创建task文件夹。
+1. 创建几个task metadata文件。
+1. 创建task.js，从task metadata生成全局metadata。
+
+下一步：追溯到一级任务的path文件夹。
+参考：
+	- https://github.com/frappe/gantt 的甘特图json数据结构
+
+
+[top](#top) | [index](#index)
+<a id="20240416093000"></a>
+##  9:30~10:59
+
+PSMD条款库
+
+### 流程及架构设计
+
+1. 根据实践和讨论，编写偏差error metadata和条款设计修订tansk metada，由代码生成error markdown、html文件、allerror metadata文件。
+1. 在ego项目下，根据task统计界面分配时间到具体子任务。
+1. 在PSMD的设计、修订条款子任务中，通过PSMD项目的统计界面了解相关信息，然后撰写手稿存放在draft库中，并在当天的draft metadata文件中记录手稿的任务归属。
+1. 在条款设计完成时，手工编写PSMD项目的term metadata。由代码自动生成条款的markdown、html文件。
+1. 在使用时，手工编写条款集合termset的metadata，由代码生成termset的markdown、html文件。
+1. 建模时，手工编写共同体模型的COM metadata文件，由代码生成markdown、html文件。
+1. 部署时手工编写输入条件的deploy metadata文件（列明人员、资源等条件），由代码生成deploy markdown、html文件，以及全部表决通过后的COD metadata。
+1. 紧急部署时，手工编写部署方案的COD metadata文件。
+1. 由代码根据COD metadata生成markdown、html。
+1. term的placeholder有entity、asset、term三类（以后可以扩充），termset、COM解决term之间的关联关系，deploy解决entity、asset的关联关系。
+
+- 内部可见：
+	- error metadata
+	- allerror metadata
+	- draft手稿
+	- draft metadata
+	- error metadata
+	- term metadata
+	- termset metadata
+	- allterm metadata
+	- COM metadata
+	- deploy metadata
+	- COD metadata
+- 对外可见：
+	- error markdown、html
+	- term markdown、html
+	- termset markdown、html
+	- COM markdown、html
+	- deploy markdown、html
+	- COD markdown、html
+
+### 数据结构
+
+- error metadata
+~~~
+name:
+id:
+text:
+bind:
+	- type: term、termset、COD
+	- id:
+log: |
+~~~
+- allerror metadata
+~~~
+time:
+error:
+	errorid:
+		//error metadata文件全部内容
+		effect: //解决方案，对应term、termset、COM的effect字段
+			- type: term、termset、COM
+			- id:
+	errorid:
+~~~
+- draft metadata
+~~~
+date: 20240415
+time:
+  - begin: 20240415074500
+    amount: 60
+    unit: minute
+    type: work
+    subject: ego
+	subjecttype: task、error、term、termset、COM、COD
+    output: draft/2024/04/2024041140745.md
+~~~
+- term metadata
+~~~
+name:
+id:
+interface:
+	entity:
+		- name:
+		id:
+		readme: |
+		- name:
+		id:
+		readme: |
+	asset:
+		- name:
+		id:
+		readme: |
+	term:	//	引用其它条款，在termset、COM中根据联合使用情况绑定。
+		- name:
+		id:
+		readme: |
+	event:
+		- name:
+		  id:
+		  readme: |
+text:
+readme:
+effect:
+	error hashid:
+	error hashid:
+log: |
+~~~
+- termset metadata
+~~~
+name:
+id:
+level:
+interface:
+	entity:
+		- name:
+		id:
+		globalid:  \\ termsetid\...\termid\entityid
+		readme: |
+		- name:
+		id:
+		globalid:  \\ termsetid\...\termid\entityid
+		readme: |
+	asset:
+		- name:
+		id:
+		globalid: \\ termsetid\...\termid\assetid
+		readme: |
+	term:	//	引用其它条款，在termset、COM中根据联合使用情况绑定。
+		- name:
+		id:
+		globalid: \\ termsetid\...\termid\termid
+		readme: |
+	event:
+		- name:
+		  id:
+		  globalid: 
+		  readme: |
+item:
+	- type:  term\termset
+	  id:
+	  globalid: \\ termsetid\...\termid\
+	  text:
+	  upgrade: \\ 修订程序的globalid
+	  path:
+	  item:
+			- id:
+			  globalid: \\ termsetid\...\termid\
+			  text:
+			  upgrade: \\ 修订程序的globalid
+	- id:
+readme: |
+log: |
+effect:
+	error hashid:
+	error hashid:
+~~~
+- allterm metadata
+~~~
+time:
+term:
+	hash:
+		//term metadata全部内容
+		error:	//对应error metadata的bind字段
+			-id:
+			-id:
+termset:
+	hash:
+		//termset metadata全部内容
+		error:	//对应error metadata的bind字段
+			-id:
+			-id:
+~~~
+- COM metadata
+~~~
+name:
+id:
+level:
+interface:
+	entity:
+		- name:
+		id:
+		globalid:  \\ termsetid\...\termid\entityid
+		readme: |
+		- name:
+		id:
+		globalid:  \\ termsetid\...\termid\entityid
+		readme: |
+	asset:
+		- name:
+		id:
+		globalid: \\ termsetid\...\termid\assetid
+		readme: |
+	term:	//	引用其它条款，COM主要是引用外部法规，比如公司法。
+		- name:
+		id:
+		globalid: \\ termsetid\...\termid\termid
+		readme: |
+	event:
+		- name:
+		  id:
+		  globalid: 
+		  readme: |
+item:	\\ 似乎可以直接用一个termset
+	- type: term\termset
+	  id:
+	  upgrade: 
+readme: |
+log: |
+effect:
+	error hashid:
+	error hashid:
+~~~
+- deploy metadata
+~~~
+name:
+id:
+source:
+	type: termset\COM
+	id: termsetid or COM id
+interface:
+	entity:
+		- name:
+		id:
+		globalid:  \\ termsetid\...\termid\entityid
+		readme: |
+		- name:
+		id:
+		globalid:  \\ termsetid\...\termid\entityid
+		readme: |
+	asset:
+		- name:
+		id:
+		globalid: \\ termsetid\...\termid\assetid
+		readme: |
+	term:	//	引用其它条款，COM主要是引用外部法规，比如公司法。
+		- name:
+		id:
+		globalid: \\ termsetid\...\termid\termid
+		readme: |
+	event:
+		- name:
+		  id:
+		  globalid: 
+		  readme: |
+~~~
+- COD metadata
+~~~
+name:
+id:
+COMid:
+interface:
+	entity:
+		- name:
+		id:
+		globalid:  \\ termsetid\...\termid\entityid
+		readme: |
+		- name:
+		id:
+		globalid:  \\ termsetid\...\termid\entityid
+		readme: |
+	asset:
+		- name:
+		id:
+		globalid: \\ termsetid\...\termid\assetid
+		readme: |
+	term:	//	引用其它条款，COM主要是引用外部法规，比如公司法。
+		- name:
+		id:
+		globalid: \\ termsetid\...\termid\termid
+		readme: |
+	event:
+		- name:
+		  id:
+		  globalid: 
+		  readme: |
+readme: |
+log: |
+~~~
+
+### 自动化代码
+
+- error metadata → error markdown、html、task metadata
+- draft metadata → 更新task metadata的time、log字段 （→ alltask metadata），更新
+- term metadata → allterm metadata
+- allterm metadata → 条款的markdown、html文件，要约、合同
+- COM metadata → COM markdown、COM html
+- deploy metadata → deploy markdown、deploy html、全部通过后的COD metdadata
+- COD metadata → COD markdown、COD html
+
+下一步的工作：
+- 根据COM的讨论和COD的执行，产生修订error、term、termset的task metadata，在ego或COD分配资源时使用，从而形成闭环。
+
+
+[top](#top) | [index](#index)
+<a id="20240416140000"></a>
+## 14:00~14:29
+
+draft自动生成日小结
+
+- 在draft数据结构中增加了name字段。
+- 内容末尾的回车都是紧贴内容，不带空行。是否隔行由后续内容开头决定。
+- 路径的左端不带斜杠，右端带。
+- 增加了目录。
+- 增加了top、index标签。
+
+输出：D:\huangyg\git\blog\release\time.js
+- makedaylog(date)
+
+[top](#top) | [index](#index)
+<a id="20240416143000"></a>
+## 14:30~14:59
+
+ego entry页面显示markdown 
+
+- 使用 https://marked.js.org/ 解析markdown内容
+- 网页无法跨域获得日志内容。
+    - 普通http get无效，返回status=0.
+    - jsonP无效，返回status=0.
+    - iframe无效，gitee和codeberg都拒绝iframe
+- 网页使用ifram读取codeberg page同域名下的日志文件，被自动下载。
+
+下一步：试试修改iframe属性，获得内容后试试onload()中解析markdown内容。
+
+[top](#top) | [index](#index)
+<a id="20240416160000"></a>
+##  16:00~16:59
+
+ego draft to metadata 代码
+
+~~~
+node task            : task metadata to alltask metadata
+node task 2024       : draft to year stat
+node task 20240416   : draft to task metadata
+node task 1          : diff date draft to task metadata
+node task 20240101 20240401   : period draft to stat
+~~~
+
+输出：D:\huangyg\git\ego\task\task.js
+- 参数分流
+- draft to task metadata：function drafttotask(date)
+
+下一步：debug
+出现空文件或内容缺实、跳断的情况。
+已确认写入的内容是正确的，初步判断是读文件和写文件之间的同步问题。

release/time/d.20240417.md

@@ -0,0 +1,123 @@
+# 20240417
+
+小结
+<a id="top"></a>
+根据[ego模型时间接口](https://gitee.com/hyg/blog/blob/master/timeflow.md)，今天绑定模版2。
+
+| 时间片 | 时长 | 用途 |
+| --- | --- | --- |
+| 4:00~4:14 | 15 | 休整 |
+| 4:15~5:14 | 60 | 备餐、运动 |
+| 5:15~5:59 | 45 | 早餐 |
+| 6:00~6:44 | 45 | 会议、自习 |
+| 6:45~7:44 | 60 | 休整  |
+| 7:45~10:59 | 195 | [工作](http://simp.ly/p/3GXNTh) |
+| 11:00~13:59 | 180 | 备餐、午餐午休 |
+| 14:00~15:29 | 90 | [工作](http://simp.ly/p/lsBYG9) |
+| 15:30~15:59 | 30 | 休整 |
+| 16:00~16:59 | 60 | [工作](http://simp.ly/p/MpcbHD) |
+| 17:00~18:59 | 120 | 晚餐 |
+| 19:00~19:59 | 60 | 讨论、整理提交 |
+
+工作的同时可以在线讨论。
+
+---
+<a id="index"></a>
+- 07:45	[PSMD 条款库的数据结构](#20240417074500)
+- 14:00	[PSMD 条款库的代码](#20240417140000)
+- 16:00	[ego 任务统计代码](#20240417160000)
+
+---
+
+
+[top](#top) | [index](#index)
+<a id="20240417074500"></a>
+## 7:45~10:59
+
+PSMD 条款库的数据结构
+
+根据[昨天](https://codeberg.org/hyg/blog/src/branch/master/release/time/d.20240416.md#20240416093000)设计的数据结构，开始编程。
+
+- 由于metadata文件的读写同步问题，log字段取消，由代码自动写入markdown和html文件。
+- 仔细对比COM markdown使用allx还是COM的metadata。决定allx主要起到index索引作用，内部使用（git库开放）。COM metadata、markdown和html对外部使用。数据结构细节需要针对性微调。
+- deploy针对从COM启动的需求，COD针对部署过程、部分决议已经通过的情形，数据结构需要针对性微调。
+
+输出： 
+1. 数据结构在PSMD\data\readme.md
+1. 初步设计：
+
+### PSMD\src\term.js
+
+node term all   : term metada + termset metadata → allterm metadata
+node term term id   : term metadata → term markdown + html
+node term termset id    ： termset metadata → termset markdown + html
+
+### PSMD\src\model.js
+
+node model id    ： COM metadata → COM markdown + html
+
+### PSMD\src\deploy.js
+
+node deploy id  ：deploy metadata → deploy markdown、deploy html、全部通过后的COD metdadata
+node deploy
+
+下一步：
+- 手写metadate
+- 实现代码：  
+    - term metadata + termset metadata → allterm metadata
+    - allterm metadata → 条款的markdown、html文件，要约、合同
+    - COM metadata → COM markdown、COM html
+    - deploy metadata → deploy markdown、deploy html、全部通过后的COD metdadata
+    - COD metadata → COD markdown、COD html
+    - COD record → 修订error、term、termset的task metadata
+
+
+[top](#top) | [index](#index)
+<a id="20240417140000"></a>
+## 14:00~15:29
+
+PSMD 条款库的代码
+
+手工编辑了三个term metadata：
+- 主分配比例p：设置初始值，在termset中明确修订权。
+- 自修订条款
+- 二级修订条款1
+
+一个termset metadata：自修订条款修订其它两个条款。
+
+创建/PSMD/src/term.js
+完成:  term metadata + termsetmetadata → allterm metadata
+
+[top](#top) | [index](#index)
+<a id="20240417160000"></a>
+## 16:00~16:59
+
+ego 任务模版
+
+调整：
+- 资源分配、统计，放在time.js
+~~~
+node time:  today's draft metadata + draft markdown → day log markdown + task markdown's log
+node time 1: diff day's draft metadata + draft markdown → day log markdown + task markdown's log
+node time 20240417: 20240417's draft metadata + draft markdown → day log markdown + task markdown's log
+node time init 1: plan 1 metadata → today draft metadata
+node time init: draft metadata + plan metadata → today plan markdown
+~~~
+- 任务管理放在task.js
+~~~
+node task           : today draft to stat
+node task all        : task metadata to alltask metadata
+node task 2024       : draft to year stat
+node task 20240416   : draft to day stat
+node task 1          : diff date draft to stat
+node task 20240101 20240401   : period draft to stat
+~~~
+
+1. 设计了plan.yaml中的time字段，为后续代码提供时间段元数据。
+1. 实现了：
+	- node time init 1: plan 1 metadata → draft metadata
+	- node time init: draft metadata + plan metadata → day plan markdown
+
+下一步：
+- 根据起床时间制定浮动时间表。
+- node time:  today's draft metadata + draft markdown → day log markdown + task markdown's log 的task markdown‘s log。

release/time/d.20240418.md

@@ -0,0 +1,244 @@
+# 20240418
+
+小结
+<a id="top"></a>
+根据[ego模型时间接口](https://gitee.com/hyg/blog/blob/master/timeflow.md)，今天绑定模版1。
+
+| 时间片 | 时长 | 用途 |
+| --- | --- | --- |
+| 4:00~4:14 | 15 | 休整 |
+| 4:15~5:14 | 60 | 备餐、运动 |
+| 5:15~5:59 | 45 | 早餐 |
+| 6:00~6:44 | 45 | 会议、自习 |
+| 6:45~7:44 | 60 | 休整  |
+| 7:45~8:44 | 60 | [静默工作](http://simp.ly/p/xtgD4F) |
+| 8:45~9:29 | 45 | 休整 |
+| 9:30~10:59 | 90 | [静默工作](http://simp.ly/p/j1SspP) |
+| 11:00~13:59 | 180 | 备餐、午餐午休 |
+| 14:00~14:29 | 30 | [静默工作](http://simp.ly/p/8t3vlk)  |
+| 14:30~14:59 | 30 | [静默工作](http://simp.ly/p/5k9gJy) |
+| 15:00~15:59 | 60 | 休整 |
+| 16:00~16:59 | 60 | [静默工作](http://simp.ly/p/4QDThK) |
+| 17:00~18:59 | 120 | 晚餐 |
+| 19:00~19:59 | 60 | 讨论、整理提交 |
+
+模版一采用静默工作方式。  
+希望讨论的提纲发到 [huangyg@mars22.com](mailto:huangyg@mars22.com)，通常安排在后面某天的早餐（5:15~5:59）或会议时间（6:00~6:45）。
+
+---
+<a id="index"></a>
+- 07:45	[task metadata + draft metadata -> task view](#20240418074500)
+- 09:30	[termset metadata -> termset view](#20240418093000)
+- 14:00	[ego整体架构汇总](#20240418140000)
+- 14:30	[blog规划](#20240418143000)
+- 16:00	[task metada + draft metadata -> task stat](#20240418160000)
+
+---
+
+
+[top](#top) | [index](#index)
+<a id="20240418074500"></a>
+## 7:45~8:44
+
+ego：task metadata + draft metadata -> task view
+
+- 重新调整task.js的参数
+~~~
+node task           : today draft to stat
+node task view       : draft metadata to task view
+node task all        : task metadata to alltask metadata
+node task 2024       : draft to year stat
+node task 20240416   : draft to day stat
+node task 1          : diff date draft to stat
+node task 20240101 20240401   : period draft to stat
+~~~
+
+完成：
+task metadata + draft metadata -> alltask metadata
+
+下一步：
+alltask metadata -> task view
+
+
+
+[top](#top) | [index](#index)
+<a id="20240418093000"></a>
+##  9:30~10:59
+
+PSMD termset metadata -> termset view
+
+修改了数据结构中的interface字段：
+~~~
+interface:
+  entity:
+    id: name
+  asset:
+    id: name
+  term:  //  引用其它条款，在termset、COM中根据联合使用情况绑定。
+    id: name
+  event:
+    id: name
+~~~
+map字段
+~~~
+map:    // interface 局部-全局映射表
+            entity:
+                localid: globalid
+            asset:
+                localid: globalid
+            term:  //  引用其它条款，在termset、COM中根据联合使用情况绑定。
+                localid: globalid
+            event:
+                localid: globalid
+~~~
+以方便代码实现。目前还没有发现缺陷。
+
+完成 term.js中的函数：
+- maketermsetview
+- maketermsettext
+- maketermtext
+可以生成termset view的正文。
+
+D:\huangyg\git\PSMD\src>node term termset 1
+<entity.1> -> <entity.1>
+由<entity.1>书面提交即生效。
+
+<asset.1> -> <asset.1>
+<asset.1>=20，<asset.1>%=20%。
+
+<entity.1> -> <entity.2>
+由<entity.2>表决按一人一票表决，超过80%出席会议有效，赞成票超过超过三分之二为通过。
+
+<entity.1> -> deployer
+1.  由deployer书面提交即生效。
+2.  <asset.1>=20，<asset.1>%=20%。
+3.  由<entity.2>表决按一人一票表决，超过80%出席会议有效，赞成票超过超过三分之二为通过。
+
+<entity.2> -> director
+1.  由deployer书面提交即生效。
+2.  <asset.1>=20，<asset.1>%=20%。
+3.  由director表决按一人一票表决，超过80%出席会议有效，赞成票超过超过三分之二为通过。
+
+<asset.1> -> p
+1.  由deployer书面提交即生效。
+2.  p=20，p%=20%。
+3.  由director表决按一人一票表决，超过80%出席会议有效，赞成票超过超过三分之二为通过。
+
+termset text:
+1.  由deployer书面提交即生效。
+2.  p=20，p%=20%。
+3.  由director表决按一人一票表决，超过80%出席会议有效，赞成票超过超过三分之二为通过。
+
+下一步：
+- 把termset的metada整理生成id和文件名。
+- 测试一下多层嵌套termset，目前范例只有一层。
+- 加上辅助信息产生正式的view，写入文件。
+- 顺便完成term view。主题函数已经在实现termset时做好了。
+
+
+[top](#top) | [index](#index)
+<a id="20240418140000"></a>
+## 14:00 ~ 14:30
+
+ego整体架构汇总
+
+### 整体架构：
+
+~~~
+\raw 库处理饮食、作息
+\ego 库调度资源，主要是时间、内部token和各外部记账单位。管理无明确项目归属的公用资源。为各独立项目之间协作提供公用基础设施。
+	\log	日志数据
+	\data	元数据 metsadata
+	\src	 源代码
+	\view	可阅读的文档、报表
+\draft 库存放原始手稿，包括ego和独立项目。
+\blog 库对外发布信息，主要是ego的，也包括从独立项目的实践中提炼的通用经验。
+有对外接口的项目开设专门库，独立调度资源、发布信息。各独立库的基础信息存放在\ego\data，以便互相协作。
+~~~
+
+### 当前项目
+
+- \raw\raw.js
+	- 暂时不变，将来也按独立项目分为log、data、src、view文件夹。
+	- 重点是数据结构和代码持续升级，而数据保持互通的机制。
+- \PSMD\src\term.js
+	- 保留在PSMD项目下，作为独立项目的范例。
+- \ego\task\task.js
+	- 整理为 data、src、view文件夹。
+	- 重点是各项目之间资源调度的机制。
+- \blog\release\time.js
+	- 整理到ego下。
+
+### 项目间协作
+
+- \ego\src\config.env.js  : 某个软硬件环境下的路径、文件夹名称等信息。
+- \ego\src\util.js:  公用代码库。
+- \ego\log: 公用资源和项目间资源调度记录。
+- \ego\data\   : 各项目metadata。
+
+下一步：考虑成熟后移动代码，实践检验。
+
+
+
+[top](#top) | [index](#index)
+<a id="20240418143000"></a>
+## 14:30 ~ 15:00
+
+PSMD lib规划
+
+- blog
+	- 针对新委托者：概念介绍、典型场景的快速入门。
+	- 针对部署者：离线、独立部署将遇到的问题和当前经验。
+	- 针对建模者：近期前沿问题和实践进展。
+- lib
+	- error、term、termset、COM、deploy等metadata  不定期自动爬取，留下有价值的。不一定使用。
+- index.yaml、index.js   索引表:
+	- PSMD受托者：包括自己
+		- 使用的error、term、termset、COM、deploy等metadata。用于根据某metadata匹配公用者blog url。
+- 自动委托的PSMD标准合同
+- 自动受托的PSMD标准合同
+- 专门签署生效的PSMD标准合同
+- 标准合同下的委托需求：专门签署，或者沿着自动委托、受托链产生效力。
+
+可以从view开始，metadata有些难度。
+
+
+
+[top](#top) | [index](#index)
+<a id="20240418160000"></a>
+## 16:00 ~ 17:00
+
+ego：task metada + draft metadata -> task stat
+
+- 实现四种参数的subject时间统计。
+
+D:\huangyg\git\ego\task>node task 2024
+draft to stat:20240101~20250101
+ego spent 720 minutes.
+PSMD spent 900 minutes.
+infra spent 30 minutes.
+
+D:\huangyg\git\ego\task>node task
+draft to stat:20240418~20240419
+ego spent 150 minutes.
+PSMD spent 120 minutes.
+
+D:\huangyg\git\ego\task>node task 20240414
+draft to stat:20240414~20240415
+PSMD spent 255 minutes.
+ego spent 90 minutes.
+
+D:\huangyg\git\ego\task>node task -2
+draft to stat:20240416~20240417
+ego spent 270 minutes.
+PSMD spent 90 minutes.
+
+D:\huangyg\git\ego\task>node task 20240416 20240418
+draft to stat:20240416~20240418
+ego spent 330 minutes.
+PSMD spent 375 minutes.
+
+- 完成 alltask metadata -> task view，生成了简单的markdown。
+
+
+下一步：考虑子项目的情况。应该按树形结构逐级汇总。alltask metadata这时候可以用上，不要漏了subject。

release/time/d.20240419.md

@@ -0,0 +1,318 @@
+# 20240419
+
+小结
+<a id="top"></a>
+根据[ego模型时间接口](https://gitee.com/hyg/blog/blob/master/timeflow.md)，今天绑定模版1。
+
+| 时间片 | 时长 | 用途 |
+| --- | --- | --- |
+| 4:00~4:14 | 15 | 休整 |
+| 4:15~5:14 | 60 | 备餐、运动 |
+| 5:15~5:59 | 45 | 早餐 |
+| 6:00~6:44 | 45 | 会议、自习 |
+| 6:45~7:44 | 60 | 休整  |
+| 7:45~8:44 | 60 | [静默工作](http://simp.ly/p/xtgD4F) |
+| 8:45~9:29 | 45 | 休整 |
+| 9:30~10:59 | 90 | [静默工作](http://simp.ly/p/j1SspP) |
+| 11:00~13:59 | 180 | 备餐、午餐午休 |
+| 14:00~14:29 | 30 | [静默工作](http://simp.ly/p/8t3vlk)  |
+| 14:30~14:59 | 30 | [静默工作](http://simp.ly/p/5k9gJy) |
+| 15:00~15:59 | 60 | 休整 |
+| 16:00~16:59 | 60 | [静默工作](http://simp.ly/p/4QDThK) |
+| 17:00~18:59 | 120 | 晚餐 |
+| 19:00~19:59 | 60 | 讨论、整理提交 |
+
+模版一采用静默工作方式。  
+希望讨论的提纲发到 [huangyg@mars22.com](mailto:huangyg@mars22.com)，通常安排在后面某天的早餐（5:15~5:59）或会议时间（6:00~6:45）。
+
+---
+<a id="index"></a>
+- 07:45	[PSMD 一合同附件的termset](#20240419074500)  
+- 09:30	[根据task metadata 中的path字段追溯到各级子项目，在alltask metadata中增加树形结构。](#20240419093000)  
+- 14:00	[把termset的metada整理生成id和文件名](#20240419140000)  
+- 14:30	[把termset的metada整理生成id和文件名](#20240419143000)  
+- 16:00	[设计error、term、termset、deploy、com的关系。](#20240419160000)  
+
+---
+
+
+[top](#top) | [index](#index)
+<a id="20240419074500"></a>
+## 7:45~8:44
+
+PSMD 一合同附件的termset
+
+- 根据[2024.04150930.md](2024.04150930.md)中附件20，编写termset metadata。
+	- readme范例中，sortid字段前增加“- ”，表示数组。
+	- 要注意去掉readme中范例的注释。
+	- text要用| 标记，结尾自动换行。
+- 在term.js中增加termset递归功能。
+
+term.2.yaml
+~~~
+name: 符合某条件1
+id: 2
+text: |
+  涉事各方全体同意，推举一名或多名保证人：
+    - 保证人在其它事项中符合该条件，并按照本附件提供补充信息。
+    - 由保证人调查涉事各方是否符合该条件，将调查记录作为补充信息。
+~~~
+
+term.3.yaml
+~~~
+name: 符合某条件2
+id: 3
+text: |
+  涉事各方分别自述，交叉核实。将所有记录合并作为补充信息。
+~~~
+
+term.4.yaml
+~~~
+name: 符合某条件3
+id: 4
+interface:
+  term:
+    1: 容器规则
+text: |
+  涉事各方签署 <term.1>，承诺遵守该条件，将生效、执行的记录作为补充信息。
+~~~
+
+term.5.yaml
+~~~
+name: 符合某条件开头
+id: 5
+interface:
+  term:
+    1: 下一条
+text: |
+  对自述难以核实的情况下，可以按照<term.1>方式之一增加补充信息：
+~~~
+
+termset.2.yaml
+~~~
+name: 符合某条件的条款
+id: 2
+level: 1
+interface:
+  term:
+    1: 容器规则
+item:
+  - sortid: 1
+    type: term
+    id: 2
+    path: term.2.yaml
+  - sortid: 2
+    type: term
+    id: 3
+    path: term.3.yaml
+  - sortid: 3
+    type: term
+    id: 4
+    map:
+      term:
+        1: 1
+    path: term.4.yaml
+readme: |
+  - upgradeby应该分内部、外部两种情况定义。
+effect: |
+~~~
+
+termset.3.yaml
+~~~
+name: 符合某条件
+id: 3
+level: 2
+interface:
+  term:
+    1: 附件21.容器规则
+    2: 第2条
+item:
+  - sortid: 1
+    type: term
+    id: 5
+    map:
+      term:
+        1: 2
+    path: term.5.yaml
+  - sortid: 2
+    type: termset
+    id: 2
+    map:
+      term:
+        1: 1
+    path:  termset.2.yaml
+readme: |
+effect: |
+~~~
+
+自动生成条款如下：
+~~~
+D:\huangyg\git\PSMD\src>node term termset 3
+<term.1> -> <term.2>
+对自述难以核实的情况下，可以按照<term.2>方式之一增加补充信息：
+
+<term.1> -> <term.1>
+涉事各方签署 <term.1>，承诺遵守该条件，将生效、执行的记录作为补充信息。
+
+<term.1> -> <term.1>
+2.1.  涉事各方全体同意，推举一名或多名保证人：
+  - 保证人在其它事项中符合该条件，并按照本附件提供补充信息。
+  - 由保证人调查涉事各方是否符合该条件，将调查记录作为补充信息。
+2.2.  涉事各方分别自述，交叉核实。将所有记录合并作为补充信息。
+2.3.  涉事各方签署 <term.1>，承诺遵守该条件，将生效、执行的记录作为补充信息。
+
+<term.1> -> 附件21.容器规则
+1.  对自述难以核实的情况下，可以按照<term.2>方式之一增加补充信息：
+2.1.  涉事各方全体同意，推举一名或多名保证人：
+  - 保证人在其它事项中符合该条件，并按照本附件提供补充信息。
+  - 由保证人调查涉事各方是否符合该条件，将调查记录作为补充信息。
+2.2.  涉事各方分别自述，交叉核实。将所有记录合并作为补充信息。
+2.3.  涉事各方签署 附件21.容器规则，承诺遵守该条件，将生效、执行的记录作为补充信息。
+
+<term.2> -> 第2条
+1.  对自述难以核实的情况下，可以按照第2条方式之一增加补充信息：
+2.1.  涉事各方全体同意，推举一名或多名保证人：
+  - 保证人在其它事项中符合该条件，并按照本附件提供补充信息。
+  - 由保证人调查涉事各方是否符合该条件，将调查记录作为补充信息。
+2.2.  涉事各方分别自述，交叉核实。将所有记录合并作为补充信息。
+2.3.  涉事各方签署 附件21.容器规则，承诺遵守该条件，将生效、执行的记录作为补充信息。
+
+termset text:
+1.  对自述难以核实的情况下，可以按照第2条方式之一增加补充信息：
+2.1.  涉事各方全体同意，推举一名或多名保证人：
+  - 保证人在其它事项中符合该条件，并按照本附件提供补充信息。
+  - 由保证人调查涉事各方是否符合该条件，将调查记录作为补充信息。
+2.2.  涉事各方分别自述，交叉核实。将所有记录合并作为补充信息。
+2.3.  涉事各方签署 附件21.容器规则，承诺遵守该条件，将生效、执行的记录作为补充信息。
+~~~
+
+下一步：考虑条款合并的需求。例如上面范例中，怎么实现1. 1.1.  1.2. 1.3.，而不是1. 2.1. ...。
+
+
+[top](#top) | [index](#index)
+<a id="20240419093000"></a>
+##  9:30~10:59
+
+ego 根据task metadata 中的path字段追溯到各级子项目，在alltask metadata中增加树形结构。
+
+- 为了表达各项目子任务，task metadata文件前缀从t.改为task.
+- 手工编辑learn.js PSMD.modeling PSMD.deploy三个子项目的metadata。
+- 根据各任务metadata中的path字段，进行递归查找，所有task并列写入tasklist，按parent id建立树形结构写入tasktree。
+	- log写入tasklist。
+
+下一步：
+	- task view目前都写在task.js所在文件夹。实际使用一段时间在决定是否要写回task metada文件所在文件夹，要考虑独立项目的子任务。这样的话，要遭alltask.tasklist下面记录一下metadata所在位置。
+	- stat统计时间先写入tasklist，再在tasktree归并。
+
+
+
+[top](#top) | [index](#index)
+<a id="20240419140000"></a>
+## 14:00~14:29
+
+PSMD：把termset的metada整理生成id和文件名
+
+实现 term.js 中的 commit()
+~~~
+D:\huangyg\git\PSMD\src>node term commit
+符合某条件1 33523fe1
+符合某条件2 a1c197a9
+符合某条件3 259076a4
+符合某条件开头 bb8005b9
+调整分配主比例 01e1c775
+符合某条件的条款 949e69e3
+符合某条件 dbe32f79
+../data/term.33523fe1.yaml文件已更新。../data/term.2.yaml可以删除。
+../data/term.a1c197a9.yaml文件已更新。../data/term.3.yaml可以删除。
+../data/term.259076a4.yaml文件已更新。../data/term.4.yaml可以删除。
+../data/term.bb8005b9.yaml文件已更新。../data/term.5.yaml可以删除。
+../data/termset.01e1c775.yaml文件已更新。../data/termset.1.yaml可以删除。
+../data/termset.949e69e3.yaml文件已更新。../data/termset.2.yaml可以删除。
+../data/termset.dbe32f79.yaml文件已更新。../data/termset.3.yaml可以删除。
+~~~
+
+使用新id运行node term termset：
+~~~
+D:\huangyg\git\PSMD\src>node term termset dbe32f79
+<term.1> -> <term.2>
+对自述难以核实的情况下，可以按照<term.2>方式之一增加补充信息：
+
+<term.1> -> <term.1>
+涉事各方签署 <term.1>，承诺遵守该条件，将生效、执行的记录作为补充信息。
+
+<term.1> -> <term.1>
+2.1.  涉事各方全体同意，推举一名或多名保证人：
+  - 保证人在其它事项中符合该条件，并按照本附件提供补充信息。
+  - 由保证人调查涉事各方是否符合该条件，将调查记录作为补充信息。
+2.2.  涉事各方分别自述，交叉核实。将所有记录合并作为补充信息。
+2.3.  涉事各方签署 <term.1>，承诺遵守该条件，将生效、执行的记录作为补充信息。
+
+<term.1> -> 附件21.容器规则
+1.  对自述难以核实的情况下，可以按照<term.2>方式之一增加补充信息：
+2.1.  涉事各方全体同意，推举一名或多名保证人：
+  - 保证人在其它事项中符合该条件，并按照本附件提供补充信息。
+  - 由保证人调查涉事各方是否符合该条件，将调查记录作为补充信息。
+2.2.  涉事各方分别自述，交叉核实。将所有记录合并作为补充信息。
+2.3.  涉事各方签署 附件21.容器规则，承诺遵守该条件，将生效、执行的记录作为补充信息。
+
+<term.2> -> 第2条
+1.  对自述难以核实的情况下，可以按照第2条方式之一增加补充信息：
+2.1.  涉事各方全体同意，推举一名或多名保证人：
+  - 保证人在其它事项中符合该条件，并按照本附件提供补充信息。
+  - 由保证人调查涉事各方是否符合该条件，将调查记录作为补充信息。
+2.2.  涉事各方分别自述，交叉核实。将所有记录合并作为补充信息。
+2.3.  涉事各方签署 附件21.容器规则，承诺遵守该条件，将生效、执行的记录作为补充信息。
+
+termset text:
+1.  对自述难以核实的情况下，可以按照第2条方式之一增加补充信息：
+2.1.  涉事各方全体同意，推举一名或多名保证人：
+  - 保证人在其它事项中符合该条件，并按照本附件提供补充信息。
+  - 由保证人调查涉事各方是否符合该条件，将调查记录作为补充信息。
+2.2.  涉事各方分别自述，交叉核实。将所有记录合并作为补充信息。
+2.3.  涉事各方签署 附件21.容器规则，承诺遵守该条件，将生效、执行的记录作为补充信息。
+~~~
+
+[top](#top) | [index](#index)
+<a id="20240419143000"></a>
+## 14:30~14:59
+
+PSMD：继续14:00的任务。
+
+
+[top](#top) | [index](#index)
+<a id="20240419160000"></a>
+##  16:00~16:59
+
+PSMD 设计error、term、termset、deploy、com的关系。
+
+- 增加记录log，核实log可以：
+	- term、termset被遵守、违反：即用log定义term、termset的遵守和违反
+	- error产生、未产生：即用log定义error
+- 某种环境env是指log中出现以下状况的组合：
+	- 某些error未发现
+	- 某些erro发现
+	- 某些term、termset已生效
+	- 某些term、termset未生效
+- 遵守term、termset的效果是：在某种env下，可以消除某些error。
+- 违反term、termset的效果是：在某种env下，可以产生某些error。
+	- 这不是确定的，因为存在未知的、有相似效果的替代方案。
+	- 排查其它term、termset后可以推测。
+- 某些error的效果是：在某种环境下，即使某些term、termset被遵守也会失去效果。最终这些term、termset会被普遍违反。
+
+根据log提炼term、termset与error的关系：  
+- 产生knowledge（env-termset-error之间映射关系）metadata
+
+根据knowledge metadata：  
+- 根据COM推断error  
+	- 产生COM修订动议
+- 根据deploy推选error  
+	- 产生deploy修订动议
+- 根据log核实error  
+	- 产生消除error的动议
+- 对反例提出核实、整理方案供第三方验证的动议  
+
+主体可以：  
+- 发布log、env、knowledge
+- 标注感兴趣的env、term、termset、error，由工具自动筛选log、knowledge
+- 感兴趣的主体及其env
+- 以env的差距定义距离，参考dht编制索引表。

release/time/d.20240420.md

@@ -0,0 +1,409 @@
+# 20240420
+
+小结  
+
+<a id="top"></a>
+根据[ego模型时间接口](https://gitee.com/hyg/blog/blob/master/timeflow.md)，今天绑定模版1。
+
+| 时间片 | 时长 | 用途 |
+| --- | --- | --- |
+| 4:00~4:14 | 15 | 休整 |
+| 4:15~5:14 | 60 | 备餐、运动 |
+| 5:15~5:59 | 45 | 早餐 |
+| 6:00~6:44 | 45 | 会议、自习 |
+| 6:45~7:44 | 60 | 休整  |
+| 7:45~8:44 | 60 | [静默工作](http://simp.ly/p/xtgD4F) |
+| 8:45~9:29 | 45 | 休整 |
+| 9:30~10:59 | 90 | [静默工作](http://simp.ly/p/j1SspP) |
+| 11:00~13:59 | 180 | 备餐、午餐午休 |
+| 14:00~14:29 | 30 | [静默工作](http://simp.ly/p/8t3vlk)  |
+| 14:30~14:59 | 30 | [静默工作](http://simp.ly/p/5k9gJy) |
+| 15:00~15:59 | 60 | 休整 |
+| 16:00~16:59 | 60 | [静默工作](http://simp.ly/p/4QDThK) |
+| 17:00~18:59 | 120 | 晚餐 |
+| 19:00~19:59 | 60 | 讨论、整理提交 |
+
+模版一采用静默工作方式。  
+希望讨论的提纲发到 [huangyg@mars22.com](mailto:huangyg@mars22.com)，通常安排在后面某天的早餐（5:15~5:59）或会议时间（6:00~6:45）。
+
+---
+<a id="index"></a>
+- 07:45	[整理合同metadata范例](#20240420074500)  
+- 09:30	[PSMD：一份要约的 metsdata → view](#20240420093000)  
+- 14:00	[学习国密算法](#20240420140000)  
+- 14:30	[子任务时间汇总](#20240420143000)  
+- 16:00	[PSMD 设计error、log、env、knowledge等新的数据结构，思考与termset、com、task的关联。](#20240420160000)  
+
+---
+
+
+[top](#top) | [index](#index)
+<a id="20240420074500"></a>
+## 7:45~8:44
+
+整理合同metadata范例
+
+完成了：  
+- draft 202404151600.md 中的附件21：d0111eb4  
+- 附件31：PSMD升级规则中的PS标准：6d206b54  
+- 附件32：PSMD升级规则中的保密规则：9e6bc34f  
+
+解决一个错误，输出到markdown文件居然习惯性地加了yaml.dump() 。导致markdown中的序号后有两个空格，还有换行的情况。
+
+[top](#top) | [index](#index)
+<a id="20240420093000"></a>
+##  9:30~10:59
+
+PSMD：一份要约的 metsdata → view
+
+draft 202404151600.md：  
+
+~~~
+
+针对不同条件给出建议如下：
+1. 使用自定义的规章解决资源和重构问题，具体可以参考1609、chain等标准模型。
+	- 同意按照附件20增加补充信息，补充关于附件30，42，31、32、33、34的补充信息，且均判断为符合。
+1. 先参考default+1406标准模型开展业务，逐步完善规章，取得进步后重新增加关于附件31、32、33、34的补充信息。
+	- 同意按照附件20增加补充信息，补充关于附件30，42，31、32、33、34的补充信息，且判断符合附件30、42，不全符合符合31、32、33、34。
+1. 在业务背景下，基于既成事实博弈。具体可以参考default标准模型。
+	- 不能按照附件20增加补充信息。
+	- 同意按照附件20增加补充信息，补充关于附件30的补充信息，且判断为不符合。
+1. 参考booting标准模型。
+	- 还在筹备因此无法补充信息的。
+
+如果有其它可行方案请发到<huangyg@mars22.com>，我将按照附件21核实。
+
+附件21 实施效果的核实
+
+1. 公布完整、连续、不可删改的执行记录，证实方案的效果。
+	- 如果以前的执行记录不符合以上条件，可以在愿意按标准公布记录的独立第三方验证。
+1. 已发布开放的要约，只有取得该效果才有收益。
+~~~
+
+其它draft相关内容：  
+~~~
+### 附件30 有效的内部监管
+定义：已有基础制度和人员，能保证书面规章的违约成本高于收益。规定监管人员以外的内部成员、外部合作方不需要额外为此耗费资源。
+
+### 附件42 资源不足
+定义：需要以未来的收入换取资源，而且需要与同行争夺。
+反向的情况，是创始时能一次筹集到足够的资源，可见未来的收入和积累都超过支出。或者需要以未来的收入换取资源，但是不需要竞争即可获得充足资源。
+
+### 附件 43 能力和贡献持续变化
+定义：核心人员凭借职权高估自己的贡献、低估非核心成员的贡献，这样做的综合效果更符合他们的利益。
+反向的情况，核心人员准确估算包括自己在内的成员贡献，这样做的综合效果更符合他们的利益。
+~~~
+
+继续把 draft 202404151600.md 中的合同整理为term、termset的metadata，然后commit生成正式metadata，再生成view：  
+- 附件33：PSMD升级规则中的制定规则：600f6f80
+- 附件34：PSMD升级规则中的分支隔离规则：12119600  
+- 附件30：有效的内部监管
+- 附件42 资源不足
+- 附件 43 能力和贡献持续变化
+- 入门目录202404151600主体（第2条）
+- 入门目录202404151600全文：
+	- 附件20的term.2，不需要向外映射。可以沿用内部interface。
+	- 附件32的term.1也是
+	- 附件33的term.1
+
+commit产生的这批id如下：  
+~~~
+入门目录202404151600-2-1 5b4e0597
+入门目录202404151600-2-2 52edbf25
+入门目录202404151600-2-3 7288c99c
+入门目录202404151600-2-4 dd1bc41b
+入门目录202404151600-1 cc0fba2f
+入门目录202404151600-3 4b12ac08
+有效的内部监管 91ff9448
+资源不足 cb4ab0e9
+能力和贡献持续变化 5ab2b2ba
+入门目录202404151600-2 e6976035
+入门目录202404151600 9d12877c
+~~~
+
+加上已经完成的：  
+- 附件20：符合某条件：dbe32f79
+- 附件21：实施效果的核实：d0111eb4  
+- 附件31：PSMD升级规则中的PS标准：6d206b54  
+- 附件32：PSMD升级规则中的保密规则：9e6bc34f  
+
+执行过程：  
+
+~~~
+
+D:\huangyg\git\PSMD\src>node term commit
+入门目录202404151600-2-1 5b4e0597
+入门目录202404151600-2-2 52edbf25
+入门目录202404151600-2-3 7288c99c
+入门目录202404151600-2-4 dd1bc41b
+入门目录202404151600-1 cc0fba2f
+入门目录202404151600-3 4b12ac08
+有效的内部监管 91ff9448
+资源不足 cb4ab0e9
+能力和贡献持续变化 5ab2b2ba
+入门目录202404151600-2 e6976035
+入门目录202404151600 9d12877c
+../data/term.5b4e0597.yaml文件已更新。../data/term.1.yaml可以删除。
+../data/term.52edbf25.yaml文件已更新。../data/term.2.yaml可以删除。
+../data/term.7288c99c.yaml文件已更新。../data/term.3.yaml可以删除。
+../data/term.dd1bc41b.yaml文件已更新。../data/term.4.yaml可以删除。
+../data/term.cc0fba2f.yaml文件已更新。../data/term.5.yaml可以删除。
+../data/term.4b12ac08.yaml文件已更新。../data/term.6.yaml可以删除。
+../data/term.91ff9448.yaml文件已更新。../data/term.7.yaml可以删除。
+../data/term.cb4ab0e9.yaml文件已更新。../data/term.8.yaml可以删除。
+../data/term.5ab2b2ba.yaml文件已更新。../data/term.9.yaml可以删除。
+path replace:term.1.yaml term.5b4e0597.yaml
+path replace:term.2.yaml term.52edbf25.yaml
+path replace:term.3.yaml term.7288c99c.yaml
+path replace:term.4.yaml term.dd1bc41b.yaml
+../data/termset.e6976035.yaml文件已更新。../data/termset.1.yaml可以删除。
+path replace:term.5.yaml term.cc0fba2f.yaml
+path replace:termset.1.yaml termset.e6976035.yaml
+path replace:term.6.yaml term.4b12ac08.yaml
+旧文件:../data/termset.2.yaml中itemset:3的id:dbe32f79未能替换，请人工检查。
+旧文件:../data/termset.2.yaml中itemset:4的id:d0111eb4未能替换，请人工检查。
+path replace:termset.7.yaml termset.91ff9448.yaml
+旧文件:../data/termset.2.yaml中itemset:6的id:6d206b54未能替换，请人工检查。
+旧文件:../data/termset.2.yaml中itemset:7的id:9e6bc34f未能替换，请人工检查。
+旧文件:../data/termset.2.yaml中itemset:8的id:600f6f80未能替换，请人工检查。
+旧文件:../data/termset.2.yaml中itemset:9的id:12119600未能替换，请人工检查。
+path replace:termset.8.yaml termset.cb4ab0e9.yaml
+path replace:termset.9.yaml termset.5ab2b2ba.yaml
+../data/termset.9d12877c.yaml文件已更新。../data/termset.2.yaml可以删除。
+
+~~~
+
+执行 node term termset 9d12877c 产生的文件termset.9d12877c.md内容如下（作为txt可以，作为markdown的话序号乱了）：  
+
+···
+
+1. 针对不同条件给出建议如下：
+2.1. 条件：同意按照附件20增加补充信息，补充关于附件30，附件42，附件31、附件32、附件33、附件34的补充信息，且均判断为符合。
+建议：使用自定义的规章解决资源和重构问题，具体可以参考1609、chain等标准模型。
+2.2. 条件：同意按照附件20增加补充信息，补充关于附件30，附件42，附件31、附件32、附件33、附件34的补充信息，且判断符合附件附件30，附件42，不全符合符合附件31、附件32、附件33、附件34。
+建议：先参考default+1406标准模型开展业务，逐步完善规章，取得进步后重新增加关于附件附件31、附件32、附件33、附件34的补充信息。
+2.3. 条件：
+- 不能按照附件20增加补充信息。
+- 同意按照附件20增加补充信息，补充关于附件30的补充信息，且判断为不符合。
+建议：在业务背景下，基于既成事实博弈。具体可以参考default标准模型。
+2.4. 条件：还在筹备因此无法补充信息的。
+建议：参考booting标准模型。
+3. 如果有其它可行方案请发到<huangyg@mars22.com>，我将按照附件21核实。
+附件20.1. 对自述难以核实的情况下，可以按照第2条方式之一增加补充信息：
+附件20.2.1. 涉事各方全体同意，推举一名或多名保证人：
+  - 保证人在其它事项中符合该条件，并按照本附件提供补充信息。
+  - 由保证人调查涉事各方是否符合该条件，将调查记录作为补充信息。
+附件20.2.2. 涉事各方分别自述，交叉核实。将所有记录合并作为补充信息。
+附件20.2.3. 涉事各方签署 附件21，承诺遵守该条件，将生效、执行的记录作为补充信息。
+附件21.1. 公布完整、连续、不可删改的执行记录，证实方案的效果。
+  - 如果以前的执行记录不符合以上条件，可以在愿意按标准公布记录的独立第三方验证。
+附件21.2. 已发布开放的要约，只有取得该效果才有收益。
+附件30. 定义：已有基础制度和人员，能保证书面规章的违约成本高于收益。规定监管人员以外的内部成员、外部合作方不需要额外为此耗费资源。
+附件31.1. 规章条款的上下级关系，根据制定、修订权定义。
+附件31.2. 人员的上下级关系，根据任免权定义。
+附件31.3. 严格执行制定、修订程序。上级规章条款未生效（或被实质架空）时，不提交、不讨论下级规章条款。
+附件31.4. 严格执行任免程序。上级人员未赴任（或被实质架空）时，不提名、不讨论下级人员。
+附件32.1. 所有人员的所有工作结果默认为公开，对外发布。
+附件32.2. 人按PS标准上溯得出顶级规章，从顶级规章到保密制度之间的上下级规章链条（包括保密制度），这组规章的密级均为公开，这组规章的工作记录的密级由该规章自行规定，保密制度不得改变。
+附件32.3. 一份文档所有用途使用相同方式取得。如果因不可抗力需要改变方式，应规定不可抗力的判定程序，确保内容相同。
+附件32.4. 如果在密级规定范围内的人员都没有能力完成任务，制定保密制度相应条款的人员承担主要责任，赔偿损失。
+附件33.1. 制定规章要明确预期效果。
+附件33.2. 接到质询时必须提供依据，依据必须是 外部法律 or 案例统计 两种方式之一。
+附件33.3. 如果是旧版本修订，制定者可以提出适用范围。只能向该适用范围内使用旧版规章的共同体发送修订通知。
+附件33.4. 分支隔离规则适用于制定规章。一个分支的共同体内制定规章时，所提供依据如果使用其它分支的案例，将自动增加切换规章的动议作为前提。
+附件34.1. 对相同事项的不同处理方法，视为同一规章的不同分支版本。对该事项未做任何规定，也视为其中一个分支版本。
+附件34.2. 实际通过生效、使用某分支版本的规章，即为支持该分支版本，反对其它分支版本。
+附件34.3. 规章使用过程遇到问题可以提出修订委托，如发往反对者将自动转为帮助切换规章的委托（切换到对方实际使用的分支版本）。如果是付费委托，受托者只需回答实际收到的问题。
+附件34.4. 查询资料时，未做任何规定分支可以列出所有分支的资料，其它分支只列出本分支的资料。
+附件42. 定义：需要以未来的收入换取资源，而且需要与同行争夺。
+反向的情况，是创始时能一次筹集到足够的资源，可见未来的收入和积累都超过支出。或者需要以未来的收入换取资源，但是不需要竞争即可获得充足资源。
+附件43. 定义：核心人员凭借职权高估自己的贡献、低估非核心成员的贡献，这样做的综合效果更符合他们的利益。
+反向的情况，核心人员准确估算包括自己在内的成员贡献，这样做的综合效果更符合他们的利益。
+
+···
+
+下一步：  
+- 把附件43加进去。
+- termid可能有二义性：字符串和数字。比如：2e758794 被理解为Infinity (位置在maketermtext()开头。已解决，在yaml.load()增加参数, { schema: yaml.FAILSAFE_SCHEMA });)：  
+
+~~~
+Error: ENOENT: no such file or directory, open 'D:\huangyg\git\PSMD\data\term.Infinity.yaml'
+    at Object.readFileSync (node:fs:455:20)
+    at maketermtext (D:\huangyg\git\PSMD\src\term.js:239:32)
+    at maketermsettext (D:\huangyg\git\PSMD\src\term.js:202:28)
+    at maketermsetview (D:\huangyg\git\PSMD\src\term.js:183:23)
+    at Object.<anonymous> (D:\huangyg\git\PSMD\src\term.js:42:9)
+~~~
+
+- 附件34 termset.12119600.yaml的readme字段出现变形。开头的|被改为>，每行之间、-号和条文之间都被加了回车
+- 各级termsetinterface中的id （globalid）要避开item.map中的id （localid），以免在替换时产生二义性。
+
+
+
+[top](#top) | [index](#index)
+<a id="20240420140000"></a>
+## 14:00~14:29
+
+学习国密算法  
+
+- 在 202404151400.md基础上，增加 js.simple/sm.crypt/local.3.html 的功能。但是网页中执行中断。
+- 直接在nodejs下命令行验证：创建密钥对、加密、解密、签名、验证，都正常。
+
+~~~
+
+D:\huangyg\git\js.sample\sm-crypto>node test
+public key:04d5e72263e80e3715411c04f3cf586c2e24673c6611f2ef7bbb1e33f19a12b1f45fe694ae314001fcc606148cb9b095d0ae0f12a8e58ef17ba64cfddc2e66e561
+private key:b28bdee8e2cccf2978a9eabffd0ffeb33550f5c2aff5869bbe106f54c0cdd39d
+verify public key:true
+plain text:
+
+- task:PSMD  [整理合同和COM metadata](../../../draft/2024/04/20240420074500.md)
+- task:PSMD  [COM metsdata → COM view](../../../draft/2024/04/20240420093000.md)
+- task:js  [学习国密算法](../../../draft/2024/04/20240420140000.md)
+- task:ego  [子任务时间汇总的伪码](../../../draft/2024/04/20240420143000.md)
+- task:PSMD  [设计error、log、env、knowledge等新的数据结构，以及与termset、com、task关联。](../../../draft/2024/04/20240420160000.md)
+encrypt text:
+fe2d9872a4cede8bbf9e2b1f2aff19ab9011fe54de3fe8f48246fae88bc0c0658afa696f8094cefb15549028db4fb24a15232e65c5707794edb7aa177a695a6fed8312db3e64abb8eb2a128e52e43c774696246fa5ef389d8894e76ff3056a273ef81f4cb7cbe4b2c52ba484075b1d904280d53826e636f2de9259d294e9b515da929a82a8f4f769349bb5084d08a8d61f6a353050f1c3f74e4717fffebeae1fa305cd5b7bec375b8bea0d4bf771a445db669440031d3416b2de4828fea45c6bf8c164628f0796d1b7f2664a57a707c2bc932a69f545c60794a2fb105dba331dc1fb6e3121b1486ea5249a75ad30a4f28ac1d418c17519d2919538df0ef7853e437374bc317e92000d442529db7a91e255b7af5f2715cf0af21a3868dca7e4733f1ee1af96931dacbb1cded09fb2b0a5b505ef3f50e55558bd6f626d074d6ed6e68096c1eb7cae69aed65e8f68f726ccb7a81df91dd208bd65c7088b9212acb8f46f6898a611b64757d1a04db9fba3b62541b863e56ea058e769925af921c15cb80440dfb72af8977eb0a029471c15d3f9727f8ac6475f3780dc563f5f04fc91afb7a3a5f6ff65d6efc90826c8c88716db31a1946f79b94cbfd11d3567aebcc879b70b3ebd8c01274c16d82b0b67544cfffe152113c59ae042433e58ef8bccb06d5c63d059190deded3a7f6ec83d52a04fb66e12228bba4df84b44957f0a1ce888d237d70270bdb8eb4c7ab7042a606b36b2151ec5487773c19a97f54f2729d3811a3c7a700fa8d564a69d6a7cefc1d34c724536ad91e9f3d38c13a46eef72302cac78f5
+decrypt text:
+
+- task:PSMD  [整理合同和COM metadata](../../../draft/2024/04/20240420074500.md)
+- task:PSMD  [COM metsdata → COM view](../../../draft/2024/04/20240420093000.md)
+- task:js  [学习国密算法](../../../draft/2024/04/20240420140000.md)
+- task:ego  [子任务时间汇总的伪码](../../../draft/2024/04/20240420143000.md)
+- task:PSMD  [设计error、log、env、knowledge等新的数据结构，以及与termset、com、task关联。](../../../draft/2024/04/20240420160000.md)
+signed hex:de92ea6ec507b39015f492c43f52a5418dd107da9722f36ed60f48c2dcd9a4587139478ba620b8ebc3e8aa4a059929caba0c643c77820fef8e68348c91ee8953
+verify the sig: true
+~~~
+
+参考资料：  
+- https://github.com/antherd/sm-crypto
+- https://www.cnblogs.com/goodAndyxublog/p/15654531.html
+- https://cscoder.cn/docs/base/sm_crypto/sm-crypto-js.html
+
+下一步：  
+- FileSaver的SaveAs()为什么需要先alert一下才能用。
+- sm2.doEncrypt()出错。阅读参考资料找出原因。
+- 学习sm3、sm4等算法接口。
+
+
+
+[top](#top) | [index](#index)
+<a id="20240420143000"></a>
+## 14:30~14:59
+
+子任务时间汇总
+
+- 直接修改了task.js的maketaskview()，以后可以在 node task view的过程中统计时间。
+- 增加了gettreetime()，递归汇总各任务及子任务消耗的时间。
+- 修改了一些bug。
+
+执行结果：  
+~~~
+
+D:\huangyg\git\ego\task>node task view
+can't find task metadata:       infra
+end node:1cJ9sN node time:840
+end node:16cedf80 node time:30
+tree node:6a8da52e node time:0 child time:30
+end node:b7bd55c1 node time:0
+end node:e39da5b6 node time:0
+tree node:01d9c808 node time:1355 child time:0
+tasktree totaltime:2225
+
+alltask.yaml文件已被更新。
+task.1cJ9sN.md文件已被更新。
+task.16cedf80.md文件已被更新。
+task.6a8da52e.md文件已被更新。
+task.01d9c808.md文件已被更新。
+task.b7bd55c1.md文件已被更新。
+task.e39da5b6.md文件已被更新。
+
+~~~
+
+
+[top](#top) | [index](#index)
+<a id="20240420160000"></a>
+##  16:00~16:59
+
+PSMD 设计error、log、env、knowledge等新的数据结构，思考与termset、com、task的关联。
+
+- 在上午9:30实现的要约 9d12877c termset中，其实附件42、43就是error，附件30、31、32、33、34是针对五种error的解决方案。  
+- 如果有error、termsert之间的关系，应该可以自动生成这份要约。或者生成一份情况核实表，分别针对合适结果产生建议。
+	- 如果写入term metadata，恐怕表达能力有限。
+
+### 数据结构
+
+#### env
+
+~~~
+name:
+id:
+term:
+  - id:
+  - id:
+termset:
+  - id:
+  - id:
+error:
+  - id
+  - id
+~~~
+- term字段：已经生效的term。如果单独有重要效果的话就列出。
+- termset字段：已经生效的termset。如果有效果的term组合被分在termset的不同章节下，如何快速匹配？
+- error：目前未解决的error
+
+#### error
+
+- error
+~~~
+name:
+id:
+text: |
+readme: |
+bind:
+  - type: term、termset、COM、deploy、COD
+     id:
+~~~
+
+#### log
+~~~
+- id:
+- time:
+- entityid:
+- termsetid:
+- termid:
+- text: |
+~~~
+- entity是指cod的interface中id。
+- termid是指termset中的sortid/sortid/.../sortid
+- 某entity根据某term的行为。
+
+#### knowldege / effect
+
+~~~
+name:
+id:
+envid:
+term:
+  - id:
+termset:
+  - id:
+  - id
+error:
+  - id:
+    percent:
+    text:
+readme: |
+~~~
+在env下，term和termset生效就有多大可能性消除error。
+
+下一步：  
+- 编辑下列error metadata：
+	- 未经统一程序兼任职务
+	- 职务行为未提交log
+	- 未经表决而生效的职务行为
+	- 规章超负荷
+	- 合规工作超负荷
+- 编辑下列env metadata：
+- 整理1406 termset，根据knowledge拆分
+- 编辑以上error、env相关的knowledge

release/time/d.20240421.md

@@ -0,0 +1,283 @@
+# 20240421
+
+小结  
+
+<a id="top"></a>
+根据[ego模型时间接口](https://gitee.com/hyg/blog/blob/master/timeflow.md)，今天绑定模版1。
+
+| 时间片 | 时长 | 用途 |
+| --- | --- | --- |
+| 4:00~4:14 | 15 | 休整 |
+| 4:15~5:14 | 60 | 备餐、运动 |
+| 5:15~5:59 | 45 | 早餐 |
+| 6:00~6:44 | 45 | 会议、自习 |
+| 6:45~7:44 | 60 | 休整  |
+| 7:45~8:44 | 60 | [静默工作](http://simp.ly/p/xtgD4F) |
+| 8:45~9:29 | 45 | 休整 |
+| 9:30~10:59 | 90 | [静默工作](http://simp.ly/p/j1SspP) |
+| 11:00~13:59 | 180 | 备餐、午餐午休 |
+| 14:00~14:29 | 30 | [静默工作](http://simp.ly/p/8t3vlk)  |
+| 14:30~14:59 | 30 | [静默工作](http://simp.ly/p/5k9gJy) |
+| 15:00~15:59 | 60 | 休整 |
+| 16:00~16:59 | 60 | [静默工作](http://simp.ly/p/4QDThK) |
+| 17:00~18:59 | 120 | 晚餐 |
+| 19:00~19:59 | 60 | 讨论、整理提交 |
+
+模版一采用静默工作方式。  
+希望讨论的提纲发到 [huangyg@mars22.com](mailto:huangyg@mars22.com)，通常安排在后面某天的早餐（5:15~5:59）或会议时间（6:00~6:45）。
+
+---
+<a id="index"></a>
+- 07:45	[整理思路和基础概念](#20240421074500)  
+- 09:30	[增加readme字段，纳入interface和map替换范围。](#20240421093000)  
+- 14:00	[熟悉国密算法的sm3、sm4接口](#20240421140000)  
+- 14:30	[整理1406历史资料](#20240421143000)  
+- 16:00	[编辑1406的metadata，并生成view。](#20240421160000)  
+
+---
+
+
+[top](#top) | [index](#index)
+<a id="20240421074500"></a>
+## 7:45~8:44
+
+整理思路和基础概念
+
+### raw vs ego
+
+- 
+- ego需要能分配压力，淘汰低价值目标。
+
+### PSMD vs infra
+
+### entity and joint , spilit
+
+### vat
+
+### club
+
+### let‘s X
+
+### token and joint token
+
+### 尽快把人组织起来
+
+还有细节未能决定，以后继续思考。
+
+[top](#top) | [index](#index)
+<a id="20240421093000"></a>
+##  9:30~10:59
+
+增加readme字段，纳入interface和map替换范围。
+
+- 修改 term.js 中的maketermsettext() maketermtext() 两个函数，第一个参数改为传递对象，直接在里面添加treetext、treereadme两个字段，代替返回值。
+- maketermsetview() 那里需要构造一个item，虚拟一个上级节点才能调用maketermsettext()。
+- 微调了空格和换行。
+
+
+执行结果如下：
+
+```
+
+D:\huangyg\git\PSMD\src>node term termset 9d12877c
+../view/termset.9d12877c.md文件更新，内容如下:
+1. 针对不同条件给出建议如下：
+2.
+2.1. 条件：同意按照附件20增加补充信息，补充关于附件30，附件42，附件31、附件32、附件33、附件34的补充信息，且均判断为符合。
+建议：使用自定义的规章解决资源和重构问题，具体可以参考1609、chain等标准模型。
+2.2. 条件：同意按照附件20增加补充信息，补充关于附件30，附件42，附件31、附件32、附件33、附件34的补充信息，且判断符合附件附件30，附件42，不全符合符合 附件31、附件32、附件33、附件34。
+建议：先参考default+1406标准模型开展业务，逐步完善规章，取得进步后重新增加关于附件附件31、附件32、附件33、附件34的补充信息。
+2.3. 条件：
+- 不能按照附件20增加补充信息。
+- 同意按照附件20增加补充信息，补充关于附件30的补充信息，且判断为不符合。
+建议：在业务背景下，基于既成事实博弈。具体可以参考default标准模型。
+2.4. 条件：还在筹备因此无法补充信息的。
+建议：参考booting标准模型。
+3. 如果有其它可行方案请发到<huangyg@mars22.com>，我将按照附件21核实。
+附件20.
+附件20.1. 对自述难以核实的情况下，可以按照第2条方式之一增加补充信息：
+附件20.2.
+附件20.2.1. 涉事各方全体同意，推举一名或多名保证人：
+  - 保证人在其它事项中符合该条件，并按照本附件提供补充信息。
+  - 由保证人调查涉事各方是否符合该条件，将调查记录作为补充信息。
+附件20.2.2. 涉事各方分别自述，交叉核实。将所有记录合并作为补充信息。
+附件20.2.3. 涉事各方签署 附件21，承诺遵守该条件，将生效、执行的记录作为补充信息。
+附件21.
+附件21.1. 公布完整、连续、不可删改的执行记录，证实方案的效果。
+  - 如果以前的执行记录不符合以上条件，可以在愿意按标准公布记录的独立第三方验证。
+附件21.2. 已发布开放的要约，只有取得该效果才有收益。
+附件30. 定义：已有基础制度和人员，能保证书面规章的违约成本高于收益。规定监管人员以外的内部成员、外部合作方不需要额外为此耗费资源。
+附件31.
+附件31.1. 规章条款的上下级关系，根据制定、修订权定义。
+附件31.2. 人员的上下级关系，根据任免权定义。
+附件31.3. 严格执行制定、修订程序。上级规章条款未生效（或被实质架空）时，不提交、不讨论下级规章条款。
+附件31.4. 严格执行任免程序。上级人员未赴任（或被实质架空）时，不提名、不讨论下级人员。
+附件32.
+附件32.1. 所有人员的所有工作结果默认为公开，对外发布。
+附件32.2. 人按PS标准上溯得出顶级规章，从顶级规章到保密制度之间的上下级规章链条（包括保密制度），这组规章的密级均为公开，这组规章的工作记录的密级由该规章自行规定，保密制度不得改变。
+附件32.3. 一份文档所有用途使用相同方式取得。如果因不可抗力需要改变方式，应规定不可抗力的判定程序，确保内容相同。
+附件32.4. 如果在密级规定范围内的人员都没有能力完成任务，制定保密制度相应条款的人员承担主要责任，赔偿损失。
+附件33.
+附件33.1. 制定规章要明确预期效果。
+附件33.2. 接到质询时必须提供依据，依据必须是 外部法律 or 案例统计 两种方式之一。
+附件33.3. 如果是旧版本修订，制定者可以提出适用范围。只能向该适用范围内使用旧版规章的共同体发送修订通知。
+附件33.4. 分支隔离规则适用于制定规章。一个分支的共同体内制定规章时，所提供依据如果使用其它分支的案例，将自动增加切换规章的动议作为前提。
+附件34.
+附件34.1. 对相同事项的不同处理方法，视为同一规章的不同分支版本。对该事项未做任何规定，也视为其中一个分支版本。
+附件34.2. 实际通过生效、使用某分支版本的规章，即为支持该分支版本，反对其它分支版本。
+附件34.3. 规章使用过程遇到问题可以提出修订委托，如发往反对者将自动转为帮助切换规章的委托（切换到对方实际使用的分支版本）。如果是付费委托，受托者只需回答实际收到的问题。
+附件34.4. 查询资料时，未做任何规定分支可以列出所有分支的资料，其它分支只列出本分支的资料。
+附件42. 定义：需要以未来的收入换取资源，而且需要与同行争夺。
+反向的情况，是创始时能一次筹集到足够的资源，可见未来的收入和积累都超过支出。或者需要以未来的收入换取资源，但是不需要竞争即可获得充足资源。
+附件43. 定义：核心人员凭借职权高估自己的贡献、低估非核心成员的贡献，这样做的综合效果更符合他们的利益。
+反向的情况，核心人员准确估算包括自己在内的成员贡献，这样做的综合效果更符合他们的利益。
+
+---
+
+附件20. readme:
+附件20.2. readme:
+- upgradeby应该分内部、外部两种情况定义。
+附件31. readme:
+- 以“规章条款”为单位。比如某公司章程有一条：股东会三分之二表决权通过可以修订章程。这条本身就在章程里面，所以也能修订自己。（比如修改为：股东会四分之三表决权通过可以修订章程。）这个条款就比章程的其它条款都高一级。无论怎么组合编集，都不影响这种层级关系。
+- 比如规章写明A任免B和C，即使在其它文件使用“B是C上级”、“C接受B的指令”这类措辞，本标准下BC平级、都是A下级。A缺席时B讨论C的人选即违规（如果B是章程中有PS标准的账号，会立刻被强制注销财产充公）。
+- 无法判断时按最坏情况处理，比如因保密制度不能阅读就按未生效、未被执行看待。
+- 上级规章制定过程可以讨论规章草案下的工作场景，包括制定下级规章的场景。只有特定上级规章导致特定下级规章草案不能产生，引入讨论才有意义。一旦离开上级规章制定程序的时间、地点、人员这些条件就不能提前讨论下级规章，因为这时上级规章（下级规章制定修订程序）还没有生效，不应该暗示自己的内定角色。
+- 待实现的后续规则：不遵守则由自然人承担。比如一个共同体的上级规章被架空时讨论下级规章，则以该自然人代替共同体承担规章中的权利，比如向执行下级规章的员工发工资。（也就是从共同体剥离，并入个人领域）"
+附件32. readme:
+- 顶层权利分配规则肯定在保密制度之上，因此PSMD只讨论公开资料。
+- 如果某个审议环节从某网址取得一份资料，这份资料从产生、生效、所有使用环节都从这个网址获得。比如是指令，下达指令者应在这个网址发布指令，然后通知接受指令者去阅读。
+附件33. readme:
+比如不采用PS标准的共同体，制定规章时以采用PS标准分支下的案例为依据，则自动增加采用PS标准的动议，切换生效之后才能讨论所制定规章。
+附件34. readme:
+- 例如：共同体A采用PS标准，共同体B、C没有。当B在上级规章未生效时要讨论下级规章。B向C提出咨询，C收到B发出的原始咨询内容。B向A提出咨询，咨询内容自动转化为“如何在规章中增加PS标准”，A无法收到B发出的原始咨询内容。这条规则主要提醒自我安慰性的求助，向反对者求助就是承认自身行为导致问题无解。
+- 在父项目，各隔离分支将使用不同记账单位。相同金额不同单位，视为同工同酬。比如采用PS标准的分支使用M为单位，不采用PS标准分支使用N为单位，自由兑换的平衡点是1M兑换10N。一项工作的报酬是5，两个分支账号分别得到5M（可兑换50N）、5N的报酬。
+
+---
+
+
+```
+
+
+[top](#top) | [index](#index)
+<a id="20240421140000"></a>
+## 14:00~14:29
+
+熟悉国密算法的sm3、sm4接口
+
+
+在test.js中增加：  
+- 用sm3生成杂凑
+- 用sm4加密、解密。
+
+local.3.html无效，仍然没有找到原因。
+
+
+[top](#top) | [index](#index)
+<a id="20240421143000"></a>
+## 14:30~14:59
+
+整理1406历史资料
+
+- D:\huangyg\git\P2Club.Lib\COD部署资料库\案例\huangyg.8005.创业型有限责任公司.md
+- D:\huangyg\git\7kick\joint.clubs.md
+- D:\huangyg\git\BEICHU\README.md
+- D:\huangyg\git\cod.template\LLC\README.md
+- D:\huangyg\git\com.origin\Food.COOP\food.coop.com.md
+- D:\huangyg\git\xuemen\S2\2-1.全局模型.md
+	- D:\huangyg\git\xuemen\S2\2-2.核心模型.md
+- D:\huangyg\git\xuemen\S2\2-3.内务部模型.md
+
+在基本制度中规定：
+1. 基本制度未定义事项由某职位现场指挥，现场指挥必须提交通用工单，特殊情况下在24小时内补交。
+	- 为减少合规工作量，每个审议周期内相同种类的通用工单只提交5次，第6次起可以自行汇总，在审议周期结束时提交汇总的通用工单。
+	- 重复性的指挥可以制定具体规章，具体规章的性质与效力都和现场指挥相同。
+1. 通用工单由决策部门审议，决定：
+	- 将该事项的处理要求纳入基本制度。可能与通用工单相同、相似、相反......一旦纳入基本制度就不再允许现场指挥。
+	- 继续保留在基本制度以外，允许现场指挥。
+
+效果：  
+1. 可以在无具体规章的情况下启动业务。
+1. 防止权力失控、寻租。
+
+1406是决策部门制定基本制度过程的动议，不是完整的共同体模型。
+
+
+[top](#top) | [index](#index)
+<a id="20240421160000"></a>
+##  16:00~16:59
+
+编辑1406的metadata，并生成view。
+
+- 已经通过。
+
+···
+
+D:\huangyg\git\PSMD\src>node term commit
+直接指挥权 48577ce8
+直接指挥的方式 7506353d
+直接指挥的归档 260ca049
+通用工单的审议 c87ec159
+1406动议 056e71fb
+../data/term.48577ce8.yaml文件已更新。../data/term.1.yaml可以删除。
+../data/term.7506353d.yaml文件已更新。../data/term.2.yaml可以删除。
+../data/term.260ca049.yaml文件已更新。../data/term.3.yaml可以删除。
+../data/term.c87ec159.yaml文件已更新。../data/term.4.yaml可以删除。
+path replace:term.1.yaml term.48577ce8.yaml
+path replace:term.2.yaml term.7506353d.yaml
+path replace:term.3.yaml term.260ca049.yaml
+path replace:term.4.yaml term.c87ec159.yaml
+../data/termset.056e71fb.yaml文件已更新。../data/termset.1.yaml可以删除。
+
+D:\huangyg\git\PSMD\src>node term termset 056e71fb
+../view/termset.056e71fb.md文件更新，内容如下:
+1. 在执行部门内，基本制度和劳动合同未定义的事项由经理直接指挥。
+2. 直接指挥的方式：
+- 经理填写通用工单明确事项的处理要求，并交给负责执行的成员；
+- 经理制订具体规章明确事项的处理要求，并提交给决策部门备案，决策部门签收后具体规章即生效。执行部门成员根据生效的具体规章自行填写通用工单并执行。
+3. 经理和执行人员都要向决策部门归档通用工单。执行人员应在收到或自行填写通用工单24小时内归档。经理填写的通用工单归档要求是：
+ - 在决策部门的一个审议周期内，每一事项的前3份通用工单，应在出具24小时内向决策部门归档；
+ - 在决策部门的一个审议周期内，同一事项的第4份通用工单起，可以汇总后在审议周期结束前一并归档。
+4. 决策部门成员应：
+- 在审议周期的第10天结束前阅读完上一个审议周期结束前归档的通用工单，提交审议报告以及基本制度的修订动议。
+- 在审议周期的第20天结束前阅读完其他成员提交的审议报告和基本制度的修订动议，提交审议报告。
+- 在审议周期结束前对基本制度修订动议进行表决。
+
+---
+
+1406准确的定位是决策部门的动议套件，可以用作其它模型的附件。 ​​​
+2. readme:
+在使用IT系统时，可修改为经理向系统提交通用工单，并由系统通知负责执行的成员。
+3. readme:
+在使用IT系统时，可以由系统实时归档。本条款可以根据情况修订。
+4. readme:
+D:\huangyg\git\PSMD\src>node term termset 056e71fb
+../view/termset.056e71fb.md文件更新，内容如下:
+1. 在执行部门内，基本制度和劳动合同未定义的事项由经理直接指挥。
+2. 直接指挥的方式：
+- 经理填写通用工单明确事项的处理要求，并交给负责执行的成员；
+- 经理制订具体规章明确事项的处理要求，并提交给决策部门备案，决策部门签收后具体规章即生效。执行部门成员根据生效的具体规章自行填写通用工单并执行。
+3. 经理和执行人员都要向决策部门归档通用工单。执行人员应在收到或自行填写通用工单24小时内归档。经理填写的通用工单归档要求是：
+ - 在决策部门的一个审议周期内，每一事项的前3份通用工单，应在出具24小时内向决策部门归档；
+ - 在决策部门的一个审议周期内，同一事项的第4份通用工单起，可以汇总后在审议周期结束前一并归档。
+4. 决策部门成员应：
+- 在审议周期的第10天结束前阅读完上一个审议周期结束前归档的通用工单，提交审议报告以及基本制度的修订动议。
+- 在审议周期的第20天结束前阅读完其他成员提交的审议报告和基本制度的修订动议，提交审议报告。
+- 在审议周期结束前对基本制度修订动议进行表决。
+
+---
+
+1406准确的定位是决策部门的动议套件，可以用作其它模型的附件。 ​​​
+2. readme:
+在使用IT系统时，可修改为经理向系统提交通用工单，并由系统通知负责执行的成员。
+3. readme:
+在使用IT系统时，可以由系统实时归档。本条款可以根据情况修订。
+4. readme:
+- 时间按一月一周期安排，只是范例。可以根据基本制度的完善程度自行调节，从一周到一年都可以考虑。
+- 基本制度生效后，所规定的工作事项就不再允许经理直接指挥。相应的具体规章也同时失效。
+- 基本制度的规定，可能与通用工单规定的相同、相似、相反......
+
+
+---
+
+···
+

release/time/d.20240422.md

@@ -0,0 +1,466 @@
+# 20240422
+
+小结  
+
+<a id="top"></a>
+根据[ego模型时间接口](https://gitee.com/hyg/blog/blob/master/timeflow.md)，今天绑定模版1。
+
+| 时间片 | 时长 | 用途 | 手稿 |  
+| --- | --- | --- | --- |  
+| 04:00~04:14 | 15 | 休整 |  |  
+| 04:15~05:14 | 60 | 备餐、运动 |  |  
+| 05:15~05:59 | 45 | 早餐 |  |  
+| 06:00~06:44 | 45 | 会议、自习 |  |  
+| 06:45~07:44 | 60 | 休整 |  |  
+| 07:45~08:44 | 60 | 静默工作 | [设计时间规划功能](#20240422074500) |  
+| 08:45~09:29 | 45 | 休整 |  |  
+| 09:30~10:59 | 90 | 静默工作 | [预设1406动议的范例（针对env、error、knowledge的缺陷）](#20240422093000) |  
+| 11:00~13:59 | 180 | 备餐、午餐午休 |  |  
+| 14:00~14:29 | 30 | 静默工作 | [日时间表动态生成](#20240422140000) |  
+| 14:30~14:59 | 30 | 静默工作 | [寻找纯文本方式存放的甘特图](#20240422143000) |  
+| 15:00~15:59 | 60 | 休整 |  |  
+| 16:00~16:59 | 60 | 静默工作 | [准备error、env、knowledge metadata，为自动生成termset metada做准备。](#20240422160000) |  
+| 17:00~18:59 | 120 | 晚餐 |  |  
+| 19:00~19:59 | 60 | 讨论、整理提交 |  |  
+
+模版一采用静默工作方式。  
+希望讨论的提纲发到 [huangyg@mars22.com](mailto:huangyg@mars22.com)，通常安排在后面某天的早餐（5:15~5:59）或会议时间（6:00~6:45）。
+
+
+---
+<a id="index"></a>
+- 07:45	[设计时间规划功能](#20240422074500)  
+- 09:30	[预设1406动议的范例（针对env、error、knowledge的缺陷）](#20240422093000)  
+- 14:00	[日时间表动态生成](#20240422140000)  
+- 14:30	[寻找纯文本方式存放的甘特图](#20240422143000)  
+- 16:00	[准备error、env、knowledge metadata，为自动生成termset metada做准备。](#20240422160000)  
+
+---
+
+
+[top](#top) | [index](#index)
+<a id="20240422074500"></a>
+## 7:45~8:44
+
+设计时间规划功能
+
+### 需求和流程
+- 本季度的时间片估算，假设前两个月：
+	- 三分之一时间绑定模块二
+	- 有一个模块三
+	- 其余绑定模块一
+	- 不可抗力因素造成缺勤，在第三个月补足。
+- 划分各任务的子任务和依赖关系、优先级、期限。
+	- 设立里程碑、期限。
+- 自动排出各时间片的候选子任务，可以人工调整（如果在界面不好实现就手工编辑metadata）
+- 在日计划绑定模版，自动初始化出draft的markdown和day metadata
+- 在季度规划中列出后续时间片和候选任务、里程碑，预估完成时间。可以列在日小结后部。
+
+### 数据结构和算法
+
+- 增加season metadata：
+	- 工作日天数，默认60天。
+	- 日模版的分布，默认40天模版一，10天模版二，10天模版三（两组）。
+	- 各任务的上期结余，本期预订时间。
+- 可以用task metadata中表达各任务的子任务和依赖关系，优先级可以增加字段
+	- 优先级可以统一规划，定义，分配给任务。
+	- 任务内部可以分配子任务、里程碑的优先级，期限。
+- 排序时综合考虑优先级和期限，给出抗风险冗余的总评估。
+- 通过合同和共同体，对外提供任务的预估完成时间（及不同报价）。
+- alltask metada和view中，要区分已完成、进行中、未开始的任务，时间分别统计。
+	- 全局的totaltime、treetotaltime不变
+	- 增加seasontime字段，内容是对象。对象属性有上季度结余时间oldbalance、预订时间order、已提取时间checkout、已申请apply、结余时间balance（可转入下一季度）。
+
+
+下一步：  
+
+- 再斟酌排序算法的实现细节，以免整体架构频繁推倒重构。
+- 需要的话，先用excel和甘特图内部实践验证。
+- 一定要内部使用成熟后再对外使用。
+- season 和 alltask.tasklist.seasomtime 的配合。
+	- season人工编辑，代码不编辑。
+	- alltask代码编辑，人工不编辑。读与写之间有足够时间间隔，以免底层时序混乱。
+
+
+[top](#top) | [index](#index)
+<a id="20240422093000"></a>
+##  9:30~10:59
+
+预设1406动议的范例（针对env、error、knowledge的缺陷）
+
+- 先针对1406动议人工编辑一套范例。
+	- 在error metadata中添加interface字段。
+	- 在knowledge中表达了1406动议可以解决割据问题。
+
+error.1.yaml
+
+```
+
+name: 执行部门陷入割据
+id: 1
+interface:
+  entity:
+    1: 共同体
+    2: 上级
+    3: 决策部门
+    4: 执行部门
+  asset:
+    1: 工单
+    2: 日志
+  term:
+    id: name
+  event:
+    id: 
+text: |
+  出现以下情况之一：
+  - <entity.3>未界定<entity.4>工作的合规性要求。
+  - <entity.3>界定了<entity.4>工作的合规性要求。
+    - <entity.4>成员对指令不进行合规检查，即使不合规也执行。
+    - <entity.4>成员及下达指令者未按要求填写和提交表单，比如<asset.1>、<asset.2>。
+readme: |
+  - <entity.2>的指令包括对更早指令的掩盖，通过互相包庇产生系统性的对抗。
+  - <entity.1>曾经对<entity.2>违约，以一定范围内的割据作为抵押物。这是历史上资源紧缺，无法兑现约定报酬的后遗症。
+  - 把一定范围内的割据作为违约抵押物的情况，解除割据应该同时处理历史欠账。在<entity.1>设立阶段，就要确定是否符合<term.1>，如果符合应该在设立时解决。
+
+```
+
+env.1.yaml
+
+```
+name: 原始状态-1
+id: 1
+error:
+  - id: 1
+readme: |
+  创始团队缺乏经验，使用的外来模版遗漏了结局问题的章节。
+```
+
+knowledge.1.yaml
+
+```
+name: 1406解决割据问题
+id: 1
+envid: 1
+termset:
+  - id: 056e71fb
+error:
+  - id: 1
+    percent: 50
+    text: |
+      - 1406动议可以消除已出现的割据问题。
+      - 如果是因为资源问题未解决，欠付报酬而以一定范围割据作为抵押物，今后还会出现新的割据问题。这种情况需要同时处理历史欠账，并且根除资源问题。
+readme: |
+```
+
+- 发现的问题：
+	- 难以自动识别割据问题、资源问题，这依赖人工核实。因此写入条款，在内部成员之间形成制约，才能触发既定条款，并在内部人员操作时提供后续动议。数据结构应该服务于这个流程，而不是外部人员或者代码直接干预。
+	- 难以表达解决割据问题之前无效的条款。
+
+- 目标条款:  如果符合附件44（执行部门陷入割据）的情况，则附件1406（1406动议）自动生效。
+- 增加一个termset：
+```
+name: 预设1406动议
+id: 1
+level: 1
+interface:
+  entity:
+    e1: 共同体
+    e2: 经理
+    e3: 决策部门
+    e4: 执行部门
+    e5: 下达指令者
+  asset:
+    a1: 通用工单
+    a2: 审议报告
+    a3: 工作日志
+  term:
+    '1': 基本制度
+    '2': 具体规章
+    '3': 劳动合同
+    44: 附件44
+    1406: 附件1406
+item:
+  - sortid: 1
+    type: term
+    id: 2
+    map:
+      term:
+        1: 44
+        2: 1406
+    path: term.2.yaml
+  - sortid: 附件44
+    type: term
+    id: 1
+    map:
+      entity:
+        1: e1
+        2: e5
+        3: e3
+        4: e4
+      asset:
+        1: a1
+    path: term.1.yaml
+  - sortid: 附件1406
+    type: termset
+    id: 056e71fb
+    map:
+      entity:
+        '1': e2
+        '2': e4
+        '3': e3
+      term:
+        '1': 1
+        '2': 2
+        '3': 3
+      asset:
+        '1': a1
+        '2': a2
+    path: termset.056e71fb.yaml
+```
+
+- commit metadata并且生成view.
+
+```
+
+D:\huangyg\git\PSMD\src>node term commit
+执行部门陷入割据 0ccddb29
+如果割据就启用1406 583d6243
+预设1406动议 b3124d50
+../data/term.0ccddb29.yaml文件已更新。../data/term.1.yaml可以删除。
+../data/term.583d6243.yaml文件已更新。../data/term.2.yaml可以删除。
+path replace:term.2.yaml term.583d6243.yaml
+path replace:term.1.yaml term.0ccddb29.yaml
+旧文件:../data/termset.1.yaml中itemset:2的id:056e71fb未能替换，请人工检查。
+../data/termset.b3124d50.yaml文件已更新。../data/termset.1.yaml可以删除。
+
+D:\huangyg\git\PSMD\src>node term termset b3124d50
+../view/termset.b3124d50.md文件更新，内容如下:
+1. 如果符合附件44的情况，则附件1406自动生效。
+附件44. 出现以下情况之一：
+- 决策部门未界定执行部门工作的合规性要求。
+- 决策部门界定了执行部门工作的合规性要求。
+  - 执行部门成员对指令不进行合规检查，即使不合规也执行。
+  - 执行部门成员及下达指令者未按要求填写和提交表单，比如通用工单、日志。
+附件1406.
+附件1406.1. 在执行部门内，基本制度和劳动合同未定义的事项由经理直接指挥。
+附件1406.2. 直接指挥的方式：
+  - 经理填写通用工单明确事项的处理要求，并交给负责执行的成员；
+  - 经理制订具体规章明确事项的处理要求，并提交给决策部门备案，决策部门签收后具体规章即生效。执行部门成员根据生效的具体规章自行填写通用工单并执行。
+附件1406.3. 经理和执行人员都要向决策部门归档通用工单。执行人员应在收到或自行填写通用工单24小时内归档。经理填写的通用工单归档要求是：
+  - 在决策部门的一个审议周期内，每一事项的前3份通用工单，应在出具24小时内向决策部门归档；
+  - 在决策部门的一个审议周期内，同一事项的第4份通用工单起，可以汇总后在审议周期结束前一并归档。
+附件1406.4. 决策部门成员应：
+  - 在审议周期的第10天结束前阅读完上一个审议周期结束前归档的通用工单，提交审议报告以及基本制度的修订动议。
+  - 在审议周期的第20天结束前阅读完其他成员提交的审议报告和基本制度的修订动议，提交审议报告。
+  - 在审议周期结束前对基本制度修订动议进行表决。
+
+---
+
+附件44. readme:
+- 下达指令者的指令包括对更早指令的掩盖，通过互相包庇产生系统性的对抗。
+- 共同体曾经对下达指令者违约，以一定范围内的割据作为抵押物。这是历史上资源紧缺，无法兑现约定报酬的后遗症。
+- 把一定范围内的割据作为违约抵押物的情况，解除割据应该同时处理历史欠账。在共同体设立阶段，就要确定是否符合基本制度，如果符合应该在设立时解决。
+附件1406. readme:
+1406准确的定位是决策部门的动议套件，可以用作其它模型的附件。 ​​​
+附件1406.2. readme:
+在使用IT系统时，可修改为经理向系统提交通用工单，并由系统通知负责执行的成员。
+附件1406.3. readme:
+- 如果出现重大失误，决策部门可能召开临时会议干预。所以要求及时归档。
+- 在使用IT系统时，可以由系统实时归档。本条款可以根据情况修订。
+附件1406.4. readme:
+- 时间按一月一周期安排，只是范例。可以根据基本制度的完善程度自行调节，从一周到一年都可以考虑。
+- 基本制度生效后，所规定的工作事项就不再允许经理直接指挥。相应的具体规章也同时失效。
+- 基本制度的规定，可能与通用工单规定的相同、相似、相反......
+
+---
+
+```
+
+下一步：  
+
+- termset metadata中，interface中的term还是映射到字符串，而不是同一个termset.item下的sortid。虽然可以人工保持同名，但还不是真正互通。也许可以在代码内把它们衔接起来：
+	- termset.item.map中可以映射到同级sortid：
+		- 优先映射到sortid，找不到的才映射到interface。
+		- 分别标注id: {sortid: id}  or id: {interfaceid: id}
+	- 统一映射到interface，其中部分与sortid同名。（有违interface字段本意：对外暴露的接口）
+- 如果只是定义error-termset-error关系：termset能解决error2，但是只在error1解决之后有效。那么在termset中添加两个字段就可以了。env-termset-error怎么能表达更广泛的条件组合。它们结合人工选择切入点（or锋面），可以自动生成定制的入门目录。
+
+[top](#top) | [index](#index)
+<a id="20240422140000"></a>
+## 14:00~14:29
+
+日时间表动态生成
+
+- 已完成日计划中的时间表。
+- 已完成日小结中的时间表。
+
+
+下一步：  
+
+- 整理重复代码，需要时调整数据结构。
+
+[top](#top) | [index](#index)
+<a id="20240422143000"></a>
+## 14:30~14:59
+
+寻找纯文本方式存放的甘特图
+
+- https://frappe.io/gantt
+
+~~~
+
+var tasks = [
+  {
+    id: 'Task 1',
+    name: 'Redesign website',
+    start: '2016-12-28',
+    end: '2016-12-31',
+    progress: 20,
+    dependencies: 'Task 2, Task 3',
+    custom_class: 'bar-milestone' // optional
+  },
+  ...
+]
+var gantt = new Gantt("#gantt", tasks);
+
+~~~
+
+- https://www.ganttproject.biz/ 自定义的*.gan是xml文件。也可以导出导入csv文件，文档没有找到，csv格式历史上有一些bug。
+
+```
+<?xml version="1.0" encoding="UTF-8"?><project name="Untitled Gantt Project" company="" webLink="http://" view-date="2024-04-20" view-index="0" gantt-divider-location="351" resource-divider-location="300" version="3.3.3307" locale="zh_CN">
+    <description/>
+    <view zooming-state="default:2" id="gantt-chart">
+        <field id="tpd3" name="名称" width="200" order="0"/>
+        <field id="tpd4" name="开始日期" width="75" order="1"/>
+        <field id="tpd5" name="结束日期" width="75" order="2"/>
+        <field id="tpd15" name="备注" width="20" order="3"/>
+        <option id="filter.completedTasks" value="false"/>
+        <option id="filter.dueTodayTasks" value="false"/>
+        <option id="filter.overdueTasks" value="false"/>
+        <option id="filter.inProgressTodayTasks" value="false"/>
+    </view>
+    <view id="resource-table">
+        <field id="0" name="名称" width="210" order="0"/>
+        <field id="1" name="默认角色" width="86" order="1"/>
+    </view>
+    <!-- -->
+    <calendars>
+        <day-types>
+            <day-type id="0"/>
+            <day-type id="1"/>
+            <default-week id="1" name="default" sun="1" mon="0" tue="0" wed="0" thu="0" fri="0" sat="1"/>
+            <only-show-weekends value="false"/>
+            <overriden-day-types/>
+            <days/>
+        </day-types>
+    </calendars>
+    <tasks empty-milestones="true">
+        <taskproperties>
+            <taskproperty id="tpd0" name="type" type="default" valuetype="icon"/>
+            <taskproperty id="tpd1" name="priority" type="default" valuetype="icon"/>
+            <taskproperty id="tpd2" name="info" type="default" valuetype="icon"/>
+            <taskproperty id="tpd3" name="name" type="default" valuetype="text"/>
+            <taskproperty id="tpd4" name="begindate" type="default" valuetype="date"/>
+            <taskproperty id="tpd5" name="enddate" type="default" valuetype="date"/>
+            <taskproperty id="tpd6" name="duration" type="default" valuetype="int"/>
+            <taskproperty id="tpd7" name="completion" type="default" valuetype="int"/>
+            <taskproperty id="tpd8" name="coordinator" type="default" valuetype="text"/>
+            <taskproperty id="tpd9" name="predecessorsr" type="default" valuetype="text"/>
+        </taskproperties>
+        <task id="0" uid="cfb128ba2d4a4fd2861da77002fb8f4b" name="raw" meeting="false" start="2024-04-22" duration="1" complete="0" expand="true"/>
+        <task id="1" uid="3263d29e698d4b44bfcfca068b617d48" name="ego" meeting="false" start="2024-04-22" duration="1" complete="0" expand="true"/>
+        <task id="2" uid="99f82a958e994c069bb2489ae0304c65" name="PSMD" meeting="false" start="2024-04-23" duration="7" complete="0" expand="true">
+            <task id="3" uid="062dfe42d33443eba053aa99d62aaf51" name="modeling" meeting="false" start="2024-04-23" duration="2" complete="0" expand="true">
+                <depend id="5" type="2" difference="0" hardness="Strong"/>
+            </task>
+            <task id="5" uid="e5c7a53e088b47028459b68e451ae18e" name="deploy" meeting="false" start="2024-04-25" duration="5" complete="0" expand="true"/>
+        </task>
+        <task id="6" uid="441e7f0c8dc64c5593937f732db8832e" name="learn" meeting="false" start="2024-04-22" duration="1" complete="0" expand="true">
+            <task id="7" uid="9998dbce7d5a40ab921264a116103568" name="js" meeting="false" start="2024-04-22" duration="1" complete="0" expand="true"/>
+        </task>
+    </tasks>
+    <resources/>
+    <allocations/>
+    <vacations/>
+    <previous/>
+    <roles roleset-name="Default"/>
+</project>
+
+```
+
+csv范例：
+
+```
+"序号",名称,开始日期,结束日期,持续,完成,成本,协调者,前置任务,大纲编号,资源,Assignments,新任务,备注,网页连接,备注
+0,raw,2024/4/22,2024/4/22,1,0,0,,,1,,,,,
+1,ego,2024/4/22,2024/4/22,1,0,0,,,2,,,,,
+2,PSMD,2024/4/23,2024/5/1,7,0,0,,,3,,,"#000000",,
+3,"  modeling",2024/4/23,2024/4/24,2,0,0,,,3.1,,,,,
+5,"  deploy",2024/4/25,2024/5/1,5,0,0,,3,3.2,,,,,
+6,learn,2024/4/22,2024/4/22,1,0,0,,,4,,,"#000000",,
+7,"  js",2024/4/22,2024/4/22,1,0,0,,,4.1,,,,,
+
+出错了 (
+The header contains a duplicate entry: '备注' in [序号, 名称, 开始日期, 结束日期, 持续, 完成, 成本, 协调者, 前置任务, 大纲编号, 资源, Assignments, 新任务, 备注, 网页连接, 备注] 
+查看日志
+)
+```
+
+
+- https://github.com/DHTMLX/gantt 
+
+```
+gantt.config.date_format = "%Y-%m-%d %H:%i";
+gantt.init("gantt_here");
+gantt.parse({
+  data: [
+    {id: 1, text: "Project #1", start_date: null, duration: null, parent:0, progress: 0, open: true},
+    {id: 2, text: "Task #1", start_date: "2019-08-01 00:00", duration:5, parent:1, progress: 1},
+    {id: 3, text: "Task #2", start_date: "2019-08-06 00:00", duration:2, parent:1, progress: 0.5},
+    {id: 4, text: "Task #3", start_date: null, duration: null, parent:1, progress: 0.8, open: true},
+    {id: 5, text: "Task #3.1", start_date: "2019-08-09 00:00", duration:2, parent:4, progress: 0.2},
+    {id: 6, text: "Task #3.2", start_date: "2019-08-11 00:00", duration:1, parent:4, progress: 0}
+  ],
+  links:[
+    {id:1, source:2, target:3, type:"0"},
+    {id:2, source:3, target:4, type:"0"},
+    {id:3, source:5, target:6, type:"0"}
+  ]
+});
+
+```
+
+
+[top](#top) | [index](#index)
+<a id="20240422160000"></a>
+##  16:00~16:59
+准备error、env、knowledge metadata，为自动生成termset metada做准备。
+
+继续使用上午9:30的分析
+
+### 流程
+1. 委托者自述问题，受托者评估委托者自身问题，以及委托者自述的问题，结合两者编辑metadata文件。
+	- 成熟后，委托者可以通过通用的入门目录，自行操作产生metadata文件。
+1. 受托者提交metadata文件，由代码检索后产生解决方案的termset metadata，再进一步产生termset view。过程中受托者可以手工编辑termset metadata。
+	- 可以设置模版文件，以产生不同风格的termset的metadata和view。
+	- 成熟后，委托者可以自行操作产生termset view。
+
+### 需求及架构、数据结构
+1. 委托者自身问题，以及委托者自述的问题，都是error和term(set)的组合。因此env metadata还是需要的。
+1. knowledge是引用env，还是自带error和term(set)组合：应该自带。
+1. 可能要表达的knowledge：
+	- 某termset能解决error1，但是只在error2解决之后有效。
+		- 分解成两个knowledge，分别表达error2解决和未解决的env，检索非常不方便。
+		- 专门设置必须先解决的前置error字段，表达这则knowledge更直观，也更容易检索。
+	- 某termset能解决error1，但是只在error2、error3、erro4解决之后才有效。
+		- 前置error字段是个数组。
+1. 参考甘特图的字段名：
+	- dependencies
+	- depend
+
+完成error.1	error.2 env.1 knowledge.1 knoeledge.2 metadata，需要引用error.cde3c3e2。
+
+下一步：  
+继续完成这批metadata生成termset metadata的代码范例。
+

release/time/d.20240423.md

@@ -0,0 +1,219 @@
+# 20240423
+
+小结  
+
+<a id="top"></a>
+根据[ego模型时间接口](https://gitee.com/hyg/blog/blob/master/timeflow.md)，今天绑定模版1。
+
+| 时间片 | 时长 | 用途 | 手稿 |  
+| --- | --- | --- | --- |  
+| 04:00~04:14 | 15 | 休整 |  |  
+| 04:15~05:14 | 60 | 备餐、运动 |  |  
+| 05:15~05:59 | 45 | 早餐 |  |  
+| 06:00~06:44 | 45 | 会议、自习 |  |  
+| 06:45~07:44 | 60 | 休整 |  |  
+| 07:45~08:44 | 60 | 静默工作 | [设计新的dayplan metadata](#20240423074500) |  
+| 08:45~09:29 | 45 | 休整 |  |  
+| 09:30~10:59 | 90 | 静默工作 | [term commit中添加error和knowledge](#20240423093000) |  
+| 11:00~13:59 | 180 | 备餐、午餐午休 |  |  
+| 14:00~14:29 | 30 | 静默工作 | [选定一种gantt工具，能够从数据上和task metadata互通。](#20240423140000) |  
+| 14:30~14:59 | 30 | 静默工作 | [国密算法网页端debug](#20240423143000) |  
+| 15:00~15:59 | 60 | 休整 |  |  
+| 16:00~16:59 | 60 | 静默工作 | [设计season plan的流程和数据结构](#20240423160000) |  
+| 17:00~18:59 | 120 | 晚餐 |  |  
+| 19:00~19:59 | 60 | 讨论、整理提交 |  |  
+
+模版一采用静默工作方式。  
+希望讨论的提纲发到 [huangyg@mars22.com](mailto:huangyg@mars22.com)，通常安排在后面某天的早餐（5:15~5:59）或会议时间（6:00~6:45）。
+
+
+---
+<a id="index"></a>
+- 07:45	[设计新的dayplan metadata](#20240423074500)  
+- 09:30	[term commit中添加error和knowledge](#20240423093000)  
+- 14:00	[选定一种gantt工具，能够从数据上和task metadata互通。](#20240423140000)  
+- 14:30	[国密算法网页端debug](#20240423143000)  
+- 16:00	[设计season plan的流程和数据结构](#20240423160000)  
+
+---
+
+
+[top](#top) | [index](#index)
+<a id="20240423074500"></a>
+## 7:45~8:44
+
+设计新的dayplan metadata
+
+- 以醒来时间为起点排日计划
+	- 休整时间片有一定弹性
+- 以实际始末时间整理日小结
+- 理顺全流程的变量、文件名、文件夹名，方便维护。
+
+### 数据结构
+
+#### plan metadata
+
+- 方案一
+	- dayplan增加type字段。设fix和float两种，对应固定时间和跟随起床时间浮动。将来可能增加针对不同时间点浮动。
+	- time字段下，fix类dayplan有开始时间和时长，float类只有时长。
+- 方案二
+	- dayplan的time字段下，每个时间片多种类型：
+		- 有固定开始时间和固定时长，可以推算出固定结束时间。
+		- 只有固定时长，在上一个时间片的结束时间加1为开始。
+		- 有固定开始时间，有计划时长，计划结束时间。
+		- 有固定结束时间，有计划时长，计划开始时间。
+		- 只有计划时长：
+			- 在上一个时间片结束时间加1为开始。
+			- 如果下一个时间片有固定开始时间，则以它减1位为结束。
+			- 如果下一时间片没有固定开始时间，则以计划时长计算结束时间。
+
+
+
+[top](#top) | [index](#index)
+<a id="20240423093000"></a>
+##  9:30~10:59
+term commit中添加error和knowledge
+
+已完成。
+```
+D:\huangyg\git\PSMD\src>node term commit
+commit error.1.yaml
+执行部门陷入割据 0ccddb29
+commit error.2.yaml
+无法有效分配未来收入 48291d8c
+commit knowledge.1.yaml
+1406解决割据问题 3b7582cd
+commit knowledge.2.yaml
+1609解决资源问题 d8a0602f
+commit term.1.yaml
+执行部门陷入割据 0ccddb29
+commit term.2.yaml
+如果割据就启用1406 583d6243
+commit termset.1.yaml
+预设1406动议 b3124d50
+../data/term.0ccddb29.yaml文件已更新。../data/term.1.yaml可以删除。
+../data/term.583d6243.yaml文件已更新。../data/term.2.yaml可以删除。
+../data/error.0ccddb29.yaml文件已更新。../data/error.1.yaml可以删除。
+../data/error.48291d8c.yaml文件已更新。../data/error.2.yaml可以删除。
+path replace:term.2.yaml term.583d6243.yaml
+旧文件:../data/termset.1.yaml中item:1的id:cb4ab0e9未能替换，请人工检查。
+path replace:term.1.yaml term.0ccddb29.yaml
+旧文件:../data/termset.1.yaml中itemset:3的id:056e71fb未能替换，请人工检查。
+../data/termset.b3124d50.yaml文件已更新。../data/termset.1.yaml可以删除。
+knowledge env replace. type: errorid: 1 -> 0ccddb29
+knowledge depend replace. type: errorid: 2 -> 48291d8c
+旧文件:../data/knowledge.1.yaml中termset字段, id:056e71fb未能替换，请人工检查。
+knowledge error replace. id: 1 -> 0ccddb29
+../data/knowledge.3b7582cd.yaml文件已更新。../data/knowledge.1.yaml可以删除。
+knowledge env replace. type: errorid: 2 -> 48291d8c
+旧文件:../data/knowledge.2.yaml中depend字段, type:error的id:cde3c3e2未能替换，请人工检查。
+旧文件:../data/knowledge.2.yaml中term字段, id:5b4e0597未能替换，请人工检查。
+knowledge error replace. id: 2 -> 48291d8c
+../data/knowledge.d8a0602f.yaml文件已更新。../data/knowledge.2.yaml可以删除。
+```
+
+下一步：  
+
+- error、knowledge metadata -> termset medata -> termset view
+- 增加一种参数规格： node term commit filename  提交单个手稿，沿着引用关系涉及的手稿文件也都提交。
+	- 同时把旧的commit增强一下：所有短于8字符id的都提交，以便起草大合同手稿。
+
+
+[top](#top) | [index](#index)
+<a id="20240423140000"></a>
+## 14:00~14:29
+选定一种gantt工具，能够从数据上和task metadata互通。
+
+### https://github.com/frappe/gantt
+
+- 可以显示、拖拽改变始末时间
+- 可以设置事件响应：点击、改变始末时间时调用、改变完成进度、改变显示模式
+- 只有一种depend关系，没有明确是哪种。
+- 设置父子关系，改变depend关系，没有适当接口。
+
+### ganttproject
+
+- /task/task的meeting 是里程碑，true是，flase不是。
+- /task/task的expand 是展开子任务，true展开，false收缩。
+- /tasks/task/depend的type有4种：
+	- 1：ego开始-deploy开始  在/ego/depend.type = 1 在图中显示在deploy属性下
+	- 2：modeling结束-deploy开始  在/modeling/depend.type = 2 在图中显示在deploy属性下
+	- 3：js结束-modeling结束 在/js/depend.type = 3 在图中显示在modling属性下
+	- 4：raw开始-ego结束 在/raw/depend.type = 4 在图中显示在ego属性下
+- /tasks/task/depend的difference是延迟时间
+- /tasks/task/depend的hardness是箭头显示类型：
+	- Strong：实线
+	- Rubber：虚线
+
+
+
+[top](#top) | [index](#index)
+<a id="20240423143000"></a>
+## 14:30~14:59
+国密算法网页端debug
+
+- 是大小写问题：范例是publicKey，local.3.html是pubkey。改写是没有改变大写K。
+- local.3.html中的加密、解密、签名、验证全部通过。
+
+
+[top](#top) | [index](#index)
+<a id="20240423160000"></a>
+## 16:00~16:59
+设计season plan的流程和数据结构
+
+
+### 流程
+
+- 季度规划
+	- 按已生效合同整理工作结果和完成期限，安排任务时间。
+	- 将剩余时间分配给长期任务。推算各项目的预算案。
+	- 整理任务之间的依赖关系。
+- 日计划
+	- 根据身体状况选择时间模版，初始化，生成draft metadata文件
+		- 各时间片的候选任务排序
+			- 可以有多套排序权重
+		- 已生效合同工作计划的计划、已用、剩余时间。
+		- 各项目季度预算、初步结算。
+	- 调整确定后生成正式日计划和draft空文件
+- 日小结
+	- 整理draft文件
+	- 生成正式日小结
+		- 已生效合同的计划、已用、剩余时间
+- 季度结算：根据实际使用的资源完成项目件结算。
+
+### 数据结构
+
+- season metadata in/ego/task （-> /ego/data)
+~~~
+year:
+season:
+dayplan:
+time:
+  in:
+    1: 40
+    2: 10
+    3: 2
+    // dayplanid: amount
+  agreement:
+    - name: contract1.deploy
+      deadline: 2024-06-13 18:00:00
+      budget:
+        90: 2
+        60: 8
+        30: 4
+    - name: contract2.modeling
+      deadline: 2024-05-16 12:00:00
+      budget:
+        90: 3
+        60: 2
+        30: 2
+    alloc:
+      taskid1:
+        90: 1
+        60: 3
+        30: 2
+      taskid2:
+        90: 4
+        60: 4
+        30: 1 
+~~~

release/time/d.20240424.md

@@ -0,0 +1,269 @@
+# 20240424
+
+小结  
+
+<a id="top"></a>
+根据[ego模型时间接口](https://gitee.com/hyg/blog/blob/master/timeflow.md)，今天绑定模版2。
+
+| 时间片 | 时长 | 用途 | 手稿 |  
+| --- | --- | --- | --- |  
+| 04:00~04:14 | 15 | 休整 |  |  
+| 04:15~05:14 | 60 | 备餐、运动 |  |  
+| 05:15~05:59 | 45 | 早餐 |  |  
+| 06:00~06:44 | 45 | 会议、自习 |  |  
+| 06:45~07:44 | 60 | 休整 |  |  
+| 07:45~10:59 | 195 | 工作 | [error + knowledge metadata -> view](#20240424074500) |  
+| 11:00~13:59 | 180 | 备餐、午餐午休 |  |  
+| 14:00~15:29 | 90 | 工作 | [整理基本概念，准备梳理各git库的log、data、src、view](#20240424140000) |  
+| 15:30~15:59 | 30 | 休整 |  |  
+| 16:00~16:59 | 60 | 工作 | [整理个人领域模型和共同体模型的关联](#20240424160000) |  
+| 17:00~18:59 | 120 | 晚餐 |  |  
+| 19:00~19:59 | 60 | 讨论、整理提交 |  |  
+
+工作的同时可以在线讨论。
+
+
+---
+<a id="index"></a>
+- 07:45	[error + knowledge metadata -> view](#20240424074500)  
+- 14:00	[整理基本概念，准备梳理各git库的log、data、src、view](#20240424140000)  
+- 16:00	[整理个人领域模型和共同体模型的关联](#20240424160000)  
+
+---
+
+
+[top](#top) | [index](#index)
+<a id="20240424074500"></a>
+## 7:45~10:59
+
+error + knowledge metadata -> view
+
+- 实现makeitemview()，以前只做了makeitermtext()。
+```
+D:\huangyg\git\PSMD\src>node term term 260ca049
+../view/term.260ca049.md文件更新，内容如下:
+条款 260ca049 正文:
+经理和执行人员都要向决策部门归档通用工单。执行人员应在收到或自行填写通用工单24小时内归档。经理填写的通用工单归档要求是：
+  - 在决策部门的一个审议周期内，每一事项的前3份通用工单，应在出具24小时内向决策部门归档；
+  - 在决策部门的一个审议周期内，同一事项的第4份通用工单起，可以汇总后在审议周期结束前一并归档。
+
+---
+条款 260ca049 readme:
+- 如果出现重大失误，决策部门可能召开临时会议干预。所以要求及时归档。
+- 在使用IT系统时，可以由系统实时归档。本条款可以根据情况修订。
+```
+
+- 需要在knowledge metadata中加入interface和二级map字段？暂时不需要，因为knowledge不是对外展示的，而是自动组装termset用的，使用各源头matedata自身的interface就可以。
+- 实现makeerrortext、makeerrorview()。
+```
+D:\huangyg\git\PSMD\src>node term error 0ccddb29
+../view/error.0ccddb29.md文件更新，内容如下:
+问题 0ccddb29 正文:
+出现以下情况之一：
+- 决策部门未界定执行部门工作的合规性要求。
+- 决策部门界定了执行部门工作的合规性要求。
+  - 执行部门成员对指令不进行合规检查，即使不合规也执行。
+  - 执行部门成员及下达指令者未按要求填写和提交表单，比如工单、日志。
+
+---
+问题 0ccddb29 readme:
+- 下达指令者的指令包括对更早指令的掩盖，通过互相包庇产生系统性的对抗。
+- 共同体曾经对下达指令者违约，以一定范围内的割据作为抵押物。这是历史上资源紧缺，无法兑现约定报酬的后遗症。
+- 把一定范围内的割据作为违约抵押物的情况，解除割据应该同时处理历史欠账。在共同体设立阶段，就要确定是否符合<term.1>，如果符合应该在设立时解决。
+```
+
+- 由于knowledge用于自动组装termset，因此不需要创建view。先构造error-knowledge-error网络，构造过程先发提示：
+```
+D:\huangyg\git\PSMD\src>node term error 0ccddb29
+enter makeerrornet: 0ccddb29 已查找的knowledge:
+{}
+
+search knowledge: 1
+search knowledge: 2
+search knowledge: 3b7582cd
+发现knowledge 3b7582cd 可以解决 error 0ccddb29 有效率: 50
+knowledge 3b7582cd 生效有先决条件，先解决error:
+error:48291d8c
+enter makeerrornet: 48291d8c 已查找的knowledge:
+3b7582cd: true
+
+search knowledge: 1
+search knowledge: 2
+search knowledge: 3b7582cd
+search knowledge: d8a0602f
+发现knowledge d8a0602f 可以解决 error 48291d8c 有效率: 60
+knowledge d8a0602f 生效有先决条件，先解决error:
+error:cde3c3e2
+enter makeerrornet: cde3c3e2 已查找的knowledge:
+3b7582cd: true
+d8a0602f: true
+
+search knowledge: 1
+search knowledge: 2
+search knowledge: 3b7582cd
+search knowledge: d8a0602f
+search knowledge: d8a0602f
+../view/error.0ccddb29.md文件更新，内容如下:
+问题 0ccddb29 正文:
+出现以下情况之一：
+- 决策部门未界定执行部门工作的合规性要求。
+- 决策部门界定了执行部门工作的合规性要求。
+  - 执行部门成员对指令不进行合规检查，即使不合规也执行。
+  - 执行部门成员及下达指令者未按要求填写和提交表单，比如工单、日志。
+
+---
+问题 0ccddb29 readme:
+- 继续构造error-knowledge-error网络，生成提示段落加入到error view中。
+- 下达指令者的指令包括对更早指令的掩盖，通过互相包庇产生系统性的对抗。
+- 共同体曾经对下达指令者违约，以一定范围内的割据作为抵押物。这是历史上资源紧缺，无法兑现约定报酬的后遗症。
+- 把一定范围内的割据作为违约抵押物的情况，解除割据应该同时处理历史欠账。在共同体设立阶段，就要确定是否符合<term.1>，如果符合应该在设立时解决。
+```
+
+下一步：  
+
+- 成员的个人领域模型纳入env。
+  - 先整理个人模型和共同体模型的对应关系。
+- 准备sql和nosql版本
+- error + allknowledge metadata -> 针对某总env的termset metadata
+- 委托者构造env以及课题的自助页面
+- 研究一下js-yaml的dump option。素材：
+    - term.260ca049 的text字段 | 符号dump成了 > 符号
+    - error.0ccddb29 的readme字段 也是>符号，而且内容被加了换行。
+
+
+[top](#top) | [index](#index)
+<a id="20240424140000"></a>
+## 14:00~15:29
+整理基本概念，准备梳理各git库的log、data、src、view
+
+暂存在ego\readme.md
+
+## git库
+
+- raw：无意识的部分
+    - log
+        - food
+        - health
+    - data
+    - src
+        - raw.js
+    - view
+        - 各级时间段food、health的报表
+- ego：有意识的部分
+    - log
+        - 各级时间段的计划小结metadata
+    - data
+        - 时间模版的metadata
+        - contract的metadata
+        - task的metadata
+        - 内部账目的metadata
+        - 各独立项目的metadata
+    - src
+        - time.js
+        - task.js
+    - view
+        - 各级计划小结的markdown、html文件
+        - contract、task、内部账目的报表
+- blog：个人正规发布。可能根据各git托管网站的page格式重整：
+    - 和用户名同名
+    - 和个人域名同名
+- draft：内部手稿，防止硬盘问题备份到私有库。
+- x.sample: 练习范例
+- com.origin: 共同体模型的雏形
+- cod.template: 共同体部署方案的模版
+- 独立个人项目，如PSMD
+    - log
+    - data
+        - term、termset、error、knowledge的metadata
+    - src
+        - term.js
+    - view
+
+
+## 基本概念
+
+- 主体：由自然人和共同体归纳产生的概念，智能设备等新主体的设计基础。
+- 共同体：各种主体的有意识的部分的合并。基本接口：
+    - 签署和执行合同。
+        - 要约表示可实践的知识。
+    - 分立和合并。
+        - 分立是模型的一部分。
+        - 合并是合同的一种。
+    - meta：察觉潜藏的概念和知识。
+        - 可实践的知识，可以表现为合同、要约。
+
+## 接口
+
+- 门户页：写在个人域名dns，各种软件或纸质的个人简介、签名档。内容根据当时需要统筹规划。
+- blog
+- raw\view
+- ego\view
+- ego\contract
+    - 要约的浏览、签署
+        - gathering
+        - PSMD委托
+    - 要约的自动组合、对签
+
+下一步：
+- 从知识-要约-共同体的角度，设计个人模型与共同体模型的映射关系。
+- 各网站page规则 -> 设计门户页及其git库
+- git库迁移
+
+[top](#top) | [index](#index)
+<a id="20240424160000"></a>
+## 16:00~16:59
+整理个人领域模型和共同体模型的关联
+
+## 当前数据结构下的关联
+- knowledge中env、depend字段下的error，分为自身error和成员error
+	- 成员error定义为：角色id+errorid
+- 由此根据成员error可以检索出无效的term、termset乃至COM、COD。
+- 由此可以转至针对该名成员的knowledge，生成个人改进的初步方案，交给人工核实、修订。
+- 产生角色的合同附件，如果出现error：
+	- 合同无效并赔偿损失，金额由共同体评估。
+	- 生成个人改进方案，欢迎改进后重新竞聘。 
+
+## 重新设计knowledge metadata
+- knowledge的env字段并入depend字段
+	- depend分为几种类型：
+		- 必须有、必须没有 某term、termset、error。
+		- 参考gantt图：必须先解决完某error再解决本error、开始解决某error时必须同时开始解决本error、开始解决某error前必须先解决完本error、在解决完某error前必须先解决完本error。
+- knowledge也应该有类型：
+	- term(set) to error
+	- term(set) to term(set)
+- knowledge的需求来源：
+	- menber error+COD -> COD error checklist -> motion
+	- menber error+COM -> deploy -> COD
+	- COD log -> menber error+COD error -> menber motion + COD motion
+    - COD error -> menber error checklist -> menber motion
+
+## 迭代升级的关系
+relation metadata
+```
+name:
+id:
+type: 1
+obj1: id1
+obj2: id2
+obj3: id3
+```
+
+relationtype metadata
+```
+name:
+id: 1
+objcnt: 3
+text: |
+  如果error<obj1>已经解决，termset<obj2>有50%概率解决error<obj3>。
+srcipt: relationtion.1.js
+```
+relation.1.js的功能是，传入obj3可以返回一段文本，其中每条都替换了{obj1,obj2}，而且有可用的跳转链接。
+
+
+下一步：  
+
+- 30m：确定knowledge的需求。
+- 60m：重新设计 knowledge metadata 的数据结构，编辑范例。
+- 60m：编写代码 knowledge metadata -> error view
+- 针对其它需求的代码。
+- 90m：根据metadata中的script字段，动态调用代码的范例。

release/time/d.20240425.md

@@ -0,0 +1,597 @@
+# 20240425
+
+小结  
+
+<a id="top"></a>
+根据[ego模型时间接口](https://gitee.com/hyg/blog/blob/master/timeflow.md)，今天绑定模版1。
+
+| 时间片 | 时长 | 用途 | 手稿 |  
+| --- | --- | --- | --- |  
+| 04:00~04:14 | 15 | 休整 |  |  
+| 04:15~05:14 | 60 | 备餐、运动 |  |  
+| 05:15~05:59 | 45 | 早餐 |  |  
+| 06:00~06:44 | 45 | 会议、自习 |  |  
+| 06:45~07:44 | 60 | 休整 |  |  
+| 07:45~08:44 | 60 | 静默工作 | [设计新的season metadata。](#20240425074500) |  
+| 08:45~09:29 | 45 | 休整 |  |  
+| 09:30~10:59 | 90 | 静默工作 | [更新knowledge设计，env并入depend字段。](#20240425093000) |  
+| 11:00~13:59 | 180 | 备餐、午餐午休 |  |  
+| 14:00~14:29 | 30 | 静默工作 | [基于配置文件（字符串）动态调用代码](#20240425140000) |  
+| 14:30~14:59 | 30 | 静默工作 | [整理知识图谱的历史手稿](#20240425143000) |  
+| 15:00~15:59 | 60 | 休整 |  |  
+| 16:00~16:59 | 60 | 静默工作 | [knowledge新metadata的commit](#20240425160000) |  
+| 17:00~18:59 | 120 | 晚餐 |  |  
+| 19:00~19:59 | 60 | 讨论、整理提交 |  |  
+
+模版一采用静默工作方式。  
+希望讨论的提纲发到 [huangyg@mars22.com](mailto:huangyg@mars22.com)，通常安排在后面某天的早餐（5:15~5:59）或会议时间（6:00~6:45）。
+
+
+---
+<a id="index"></a>
+- 07:45	[设计新的season metadata。](#20240425074500)  
+- 09:30	[更新knowledge设计，env并入depend字段。](#20240425093000)  
+- 14:00	[基于配置文件（字符串）动态调用代码](#20240425140000)  
+- 14:30	[整理知识图谱的历史手稿](#20240425143000)  
+- 16:00	[knowledge新metadata的commit](#20240425160000)  
+
+---
+
+
+[top](#top) | [index](#index)
+<a id="20240425074500"></a>
+## 7:45~8:44
+设计新的season metadata。
+
+
+- \ego文件夹下新建data、src、view子文件夹。原server、client移动到src下。
+- \ego\data\season下新建season metadata，命名规则：
+  - yyyySn.yaml
+    - yyyy: 年份
+    - n: 季度
+- task metadata迁移到\ego\data\task下
+- 在task metadata中建立agreement、todo字段，删去log字段。
+
+```
+year: 2024
+season: 1
+beginmonth: 3
+beginday: 1
+nextbeginmoth: 7
+nextbeginday: 1
+timetype:
+  - name: work
+  - name: free
+  - name: discuss
+  - name: learn
+  - name: prepare
+  - name: sleep
+  - name: food
+  - name: check
+dayplan:
+dayplan:
+  1:
+    supply:
+      90: 1
+      60: 2
+      30: 2
+    time:
+      - beginhour: 04
+        beginminute: 0
+        amount: 15
+        type: free
+        name: 休整
+      - beginhour: 04
+        beginminute: 15
+        amount: 60
+        type: prepare
+        name: 备餐、运动
+      - beginhour: 05
+        beginminute: 15
+        amount: 45
+        type: food
+        name: 早餐
+      - beginhour: 06
+        beginminute: 0
+        amount: 45
+        type: discuss
+        name: 会议、自习
+      - beginhour: 06
+        beginminute: 45
+        amount: 60
+        type: free
+        name: 休整
+      - beginhour: 07
+        beginminute: 45
+        amount: 60
+        type: work
+        name: 静默工作
+        namelink: http://simp.ly/p/xtgD4F
+      - beginhour: 08
+        beginminute: 45
+        amount: 45
+        type: free
+        name: 休整
+      - beginhour: 09
+        beginminute: 30
+        amount: 90
+        type: work
+        name: 静默工作
+        namelink: http://simp.ly/p/j1SspP
+      - beginhour: 11
+        beginminute: 00
+        amount: 180
+        type: food
+        name: 备餐、午餐午休
+      - beginhour: 14
+        beginminute: 0
+        amount: 30
+        type: work
+        name: 静默工作
+        namelink: http://simp.ly/p/8t3vlk
+      - beginhour: 14
+        beginminute: 30
+        amount: 30
+        type: work
+        name: 静默工作
+        namelink: http://simp.ly/p/5k9gJy
+      - beginhour: 15
+        beginminute: 0
+        amount: 60
+        type: free
+        name: 休整
+      - beginhour: 16
+        beginminute: 0
+        amount: 60
+        type: work
+        name: 静默工作
+        namelink: http://simp.ly/p/4QDThK
+      - beginhour: 17
+        beginminute: 00
+        amount: 120
+        type: food
+        name: 晚餐
+      - beginhour: 19
+        beginminute: 00
+        amount: 60
+        type: check
+        name: 讨论、整理提交
+    readme: |
+      模版一采用静默工作方式。  
+      希望讨论的提纲发到 [huangyg@mars22.com](mailto:huangyg@mars22.com)，通常安排在后面某天的早餐（5:15~5:59）或会议时间（6:00~6:45）。
+  2:
+    supply:
+      195: 1
+      60: 1
+      90: 1
+    time:
+      - beginhour: 04
+        beginminute: 0
+        amount: 15
+        type: free
+        name: 休整
+      - beginhour: 04
+        beginminute: 15
+        amount: 60
+        type: prepare
+        name: 备餐、运动
+      - beginhour: 05
+        beginminute: 15
+        amount: 45
+        type: food
+        name: 早餐
+      - beginhour: 06
+        beginminute: 0
+        amount: 45
+        type: discuss
+        name: 会议、自习
+      - beginhour: 06
+        beginminute: 45
+        amount: 60
+        type: free
+        name: 休整
+      - beginhour: 07
+        beginminute: 45
+        amount: 195
+        type: work
+        name: 工作
+        namelink: http://simp.ly/p/3GXNTh
+      - beginhour: 11
+        beginminute: 00
+        amount: 180
+        type: food
+        name: 备餐、午餐午休
+      - beginhour: 14
+        beginminute: 0
+        amount: 90
+        type: work
+        name: 工作
+        namelink: http://simp.ly/p/lsBYG9
+      - beginhour: 15
+        beginminute: 30
+        amount: 30
+        type: free
+        name: 休整
+      - beginhour: 16
+        beginminute: 0
+        amount: 60
+        type: work
+        name: 工作
+        namelink: http://simp.ly/p/MpcbHD
+      - beginhour: 17
+        beginminute: 00
+        amount: 120
+        type: food
+        name: 晚餐
+      - beginhour: 19
+        beginminute: 00
+        amount: 60
+        type: check
+        name: 讨论、整理提交
+    readme: |
+      工作的同时可以在线讨论。
+time:
+  supply:
+    1: 30
+    2: 15
+    3: 2
+    // dayplanid: amount
+  alloc:
+      PSMD:
+        90: 1
+        60: 3
+        30: 2
+      learn:
+        90: 4
+        60: 4
+        30: 1 
+      ego:
+        90: 4
+        60: 4
+        30: 1 
+      learn:
+        30: 8
+        60: 4
+```
+
+
+[top](#top) | [index](#index)
+<a id="20240425093000"></a>
+##  9:30~10:59
+更新knowledge设计，env并入depend字段。
+
+- 参考gantt图中任务之间的depeng：
+	- 开始解决某error时必须同时开始解决本error、在解决完某error前必须先解决完本error：应该合并成termset一起设knowledge。
+	- 因为knowledge反映termset生效的效果，可以视为解决问题结束。开始时间可以根据议事规则的召集、讨论、表决时间，加上起草动议时间、协商动员的时间，这些是部署者根据cod实际情况布置，不是模型和条款库可以提前排期的。
+	- 这种情况”如果同时存在某error要同时解决（找别的termset），如果只是本error单独存在就用本knowledge解决。“，可以设一个多error效果的大termset，多个单独error效果的小termset，小termset里的depend里规定其它error不存在。然后由检索算法去适当提示。
+	- 保险起见，增加一种类型：如果有就要同时解决。
+	- 开始解决某error前必须先解决完本error：设在某error那边”必须先解决完某error再解决本error“。两边设不好同步。
+
+- knowledge的需求来源：
+	- menber error+COD -> COD error checklist -> motion
+	- menber error+COM -> deploy -> COD
+	- COD log -> menber error+COD error -> menber motion + COD motion
+    - COD error -> menber error checklist -> menber motion
+    
+	- 委托者自助，浏览error view，想去解决 -> cod error checklist ->  自检 -> cod error diag metadata+view ->
+deploy or 委托合同 metadata+view
+	- 委托者自述 -> 受托者整理出cod error diag+checklist -> 自检 -> cod error diag metadata + view -> deploy or 委托合同
+	- 委托者委托 -> 受托者调研 -> cod error checklist -> 受托者整理问卷 -> code error diag -> deploy or 新委托
+	- 成员error在共同体层面表现为成员的行为偏差，使用同一种error metadata表达。由成员个人去完成：行为偏差->下意识行为 的分析。
+
+- 细分需求
+	- error -> error checklist
+		- error to error  relation
+			- depend
+			- together
+		- error metadata中添加字段，产生自检说明和承诺条款，生成核实
+	- checklist -> diag(error list, maybe unknown status)
+		- termset to error relation
+		- term to error relation
+	- diag(error list) -> checklist or deploy or contract
+		- termset to error relation
+		- term to error relation
+		- error unknown status -> trustee contract
+
+	- 综合考虑，在knowledge增加type字段：
+		- termtoerror
+		- errortoerror
+		- termtoterm
+		- termtotermset
+
+更新\PSMD\data\readme.me
+```
+~~~
+name:
+id:
+type:
+objid:
+depend:
+  errorid:
+    percent:
+    text: | 
+together:
+  errorid:
+    percent:
+    text: |
+effect:
+  id:
+    percent:
+    text:
+readme: |
+~~~
+- depeng: 部署本条款（解决本error）之前先解决该error
+- together：部署本条款（解决本error）的同时开始解决该error
+- 解决方案只含一条term或者termset。
+- 根据type：objid to effect
+```
+
+
+[top](#top) | [index](#index)
+<a id="20240425140000"></a>
+## 14:00~14:29
+基于配置文件（字符串）动态调用代码
+
+### eval()
+https://developer.mozilla.org/zh-CN/docs/Web/JavaScript/Reference/Global_Objects/eval
+
+- 出于安全性考虑，先在本地运行的代码中使用，网页暂时不用。
+
+### function()
+https://developer.mozilla.org/zh-CN/docs/Web/JavaScript/Reference/Global_Objects/Function
+
+- 首先var func=function（params...）;然后this["funcName"].call(params...)调用；
+
+- setInterval 
+- setTimeout
+
+
+[top](#top) | [index](#index)
+<a id="20240425143000"></a>
+## 14:30~14:59
+整理知识图谱的历史手稿
+
+### RDF 资源、属性和属性值
+
+- RDF 使用 Web 标识符来标识事物，并通过属性和属性值来描述资源。
+- 对资源、属性和属性值的解释：
+  - 资源是可拥有 URI 的任何事物，比如 "http://www.w3school.com.cn/rdf"
+  - 属性是拥有名称的资源，比如 "author" 或 "homepage"
+  - 属性值是某个属性的值，比如 "David" 或 "http://www.w3school.com.cn" （请注意一个属性值可以是另外一个资源）
+
+下面的 RDF 文档可描述资源 "http://www.w3school.com.cn/rdf"：
+```
+<?xml version="1.0"?>
+<RDF>
+  <Description about="http://www.w3school.com.cn/RDF">
+    <author>David</author>
+    <homepage>http://www.w3school.com.cn</homepage>
+  </Description>
+</RDF>
+```
+
+- rdf是知识库的标记语言
+- 另外有工具作为rdf知识库的读写查等操作，比自己写代码更统一。
+
+下一步：  
+- 先彻底打通业务流程，只发布view。然后把data、src部分升级到rdf，如果升级成功则作为范例。
+  - https://www.npmjs.com/package/rdf#query-information-from-rdf-sources
+- 再结合范例，重新思考知识图谱的缺陷和补救方式。
+- 考虑把data、src部分发布出去。
+
+历史手稿：
+```
+
+--- 
+
+知识图谱的缺陷
+
+表达权利分配规则的需求
+知识图谱的表达方式
+缺陷和改进
+
+
+---
+
+知识图谱
+
+### SparQL
+
+https://www.w3.org/TR/rdf-sparql-protocol/
+https://jena.apache.org/tutorials/sparql.html
+
+### rdf
+
+www.w3.org/RDF/
+https://www.w3school.com.cn/rdf/rdf_intro.asp
+
+### RDF-star and SPARQL-star
+
+https://www.w3.org/2021/12/rdf-star.html
+https://w3c.github.io/rdf-star/
+https://www.ontotext.com/knowledgehub/fundamentals/what-is-rdf-star/
+
+### OWL
+ 
+ https://www.w3.org/2001/sw/wiki/OWL
+
+### Gremlin 
+
+https://tinkerpop.apache.org/gremlin.html
+
+### neo4j
+
+https://neo4j.com/
+查询语言是 Cypher  https://neo4j.com/developer/cypher/
+
+
+### 华为KG API
+
+https://support.huaweicloud.com/api-kg/kg_03_0007.html
+
+
+### 北大gStore
+
+http://www.gstore.cn/pcsite/index.html#/
+
+### HugeGraph
+
+https://hugegraph.apache.org/
+
+
+### 图形化
+
+https://www.ldf.fi/service/rdf-grapher
+https://issemantic.net/rdf-visualizer
+
+```
+
+```
+### 世界观（缸中之脑）和推理
+知识图谱和推理机制，在缸中之脑模型中会发生什么。
+
+- 缺陷和具体范例
+	- 缸中之脑和双缝都要讨论到。
+- 改进
+	- 在缸外增加推理设备，发掘更原始的规律。
+	- 假设：符号、文字可以穿透缸，与其它缸中之脑交换信息。
+	- 假设：在微观层面设置装置，可以与其它缸中之脑交换信息。
+```
+
+```
+知识图谱的缺陷
+
+表达权利分配规则的需求
+知识图谱的表达方式
+缺陷和改进
+```
+
+[top](#top) | [index](#index)
+<a id="20240425160000"></a>
+## 16:00~16:59
+knowledge新metadata的commit
+
+- 先把/ego/src/path.js谢了。
+
+### commit板块
+- node term commit:   temp metadata → formal metadata
+- node term commit filename: temp metadata → formal metadata
+
+knowledge.1.yaml
+```
+name: 1406解决割据问题
+id: 1
+type: termsettoerror
+objid: 056e71fb
+depend:
+  2:
+    percent: 50
+    text: |
+      抵押权力解决资源问题不再新增，再开始解决本问题。
+effect:
+  1: 
+    percent: 50
+    text: |
+      - 1406动议可以消除已出现的割据问题。
+      - 如果是因为资源问题未解决，欠付报酬而以一定范围割据作为抵押物，今后还会出现新的割据问题。这种情况需要同时处理历史欠账，并且根除资源问题。
+readme: ''
+```
+commit结果
+```
+name: 1406解决割据问题
+id: 3b7582cd
+type: termsettoerror
+objid: 056e71fb
+depend:
+  48291d8c:
+    percent: 50
+    text: |
+      抵押权力解决资源问题不再新增，再开始解决本问题。
+effect:
+  0ccddb29: 
+    percent: 50
+    text: |
+      - 1406动议可以消除已出现的割据问题。
+      - 如果是因为资源问题未解决，欠付报酬而以一定范围割据作为抵押物，今后还会出现新的割据问题。这种情况需要同时处理历史欠账，并且根除资源问题。
+readme: ''
+```
+
+knowledge.2.yaml
+```
+name: 1609解决资源问题
+id: 2
+type: termtoerror
+objid: 5b4e0597
+depend:
+  cde3c3e2:
+    percent: 100
+    text: |
+      必须在规则有效的环境下进行。
+effect:
+  2:
+    percent: 60
+    text: |
+      - 1609模型可用于把薪酬、投资合二为一，极大提高调动未来收入的能力，缓解资源问题。
+      - 如果规则无效问题未能解决，则1609模型无效。
+readme: ''
+```
+commit结果
+```
+name: 1609解决资源问题
+id: d8a0602f
+type: termtoerror
+objid: 5b4e0597
+depend:
+  cde3c3e2:
+    percent: 100
+    text: |
+      必须在规则有效的环境下进行。
+effect:
+  48291d8c:
+    percent: 60
+    text: |
+      - 1609模型可用于把薪酬、投资合二为一，极大提高调动未来收入的能力，缓解资源问题。
+      - 如果规则无效问题未能解决，则1609模型无效。
+readme: ''
+```
+执行过程：
+```
+D:\huangyg\git\PSMD\src>node term commit
+commit error.1.yaml
+执行部门陷入割据 0ccddb29
+commit error.2.yaml
+无法有效分配未来收入 48291d8c
+commit knowledge.1.yaml
+1406解决割据问题 3b7582cd
+commit knowledge.2.yaml
+1609解决资源问题 d8a0602f
+commit term.1.yaml
+执行部门陷入割据 0ccddb29
+commit term.2.yaml
+如果割据就启用1406 583d6243
+commit termset.1.yaml
+预设1406动议 b3124d50
+../data/term.0ccddb29.yaml文件已更新。../data/term.1.yaml可以删除。
+../data/term.583d6243.yaml文件已更新。../data/term.2.yaml可以删除。
+../data/error.0ccddb29.yaml文件已更新。../data/error.1.yaml可以删除。
+../data/error.48291d8c.yaml文件已更新。../data/error.2.yaml可以删除。
+path replace:term.2.yaml term.583d6243.yaml
+旧文件:../data/termset.1.yaml中item:1的id:cb4ab0e9未能替换，请人工检查。
+path replace:term.1.yaml term.0ccddb29.yaml
+旧文件:../data/termset.1.yaml中itemset:3的id:056e71fb未能替换，请人工检查。
+../data/termset.b3124d50.yaml文件已更新。../data/termset.1.yaml可以删除。
+knowledge depend replace. error:2 -> 48291d8c
+旧文件:../data/knowledge.1.yaml中objid: 056e71fb 未能替换，请人工检查。
+knowledge effect replace. id:1 -> 0ccddb29
+../data/knowledge.3b7582cd.yaml文件已更新。../data/knowledge.1.yaml可以删除。
+旧文件:../data/knowledge.2.yaml中depend字段的id: cde3c3e2 未能替换，请人工检查。
+旧文件:../data/knowledge.2.yaml中objid: 5b4e0597 未能替换，请人工检查。
+knowledge effect replace. id:2 -> 48291d8c
+../data/knowledge.d8a0602f.yaml文件已更新。../data/knowledge.2.yaml可以删除。
+```
+
+下一步：
+
+- 生成内容板块
+    - node term knowledge    ： knowledge metadata → allknowledge metadata
+    - node term knowledge id    ： knowledge metadata → knowledge markdown + html

release/time/d.20240426.md

@@ -0,0 +1,323 @@
+# 20240426
+
+小结  
+
+<a id="top"></a>
+根据[ego模型时间接口](https://gitee.com/hyg/blog/blob/master/timeflow.md)，今天绑定模版1。
+
+| 时间片 | 时长 | 用途 | 手稿 |  
+| --- | --- | --- | --- |  
+| 04:00~04:14 | 15 | 休整 |  |  
+| 04:15~05:14 | 60 | 备餐、运动 |  |  
+| 05:15~05:59 | 45 | 早餐 |  |  
+| 06:00~06:44 | 45 | 会议、自习 |  |  
+| 06:45~07:44 | 60 | 休整 |  |  
+| 07:45~08:44 | 60 | 静默工作 | [新season metadata生成日计划](#20240426074500) |  
+| 08:45~09:29 | 45 | 休整 |  |  
+| 09:30~10:59 | 90 | 静默工作 | [knowledge新metadata输出view](#20240426093000) |  
+| 11:00~13:59 | 180 | 备餐、午餐午休 |  |  
+| 14:00~14:29 | 30 | 静默工作 | [debug,yaml.dump后|符号编程>符号而且加了换行。](#20240426140000) |  
+| 14:30~14:59 | 30 | 静默工作 | [整理各git托管商的page协议。](#20240426143000) |  
+| 15:00~15:59 | 60 | 休整 |  |  
+| 16:00~16:59 | 60 | 静默工作 | [新season metadata生成日小结](#20240426160000) |  
+| 17:00~18:59 | 120 | 晚餐 |  |  
+| 19:00~19:59 | 60 | 讨论、整理提交 |  |  
+
+模版一采用静默工作方式。  
+希望讨论的提纲发到 [huangyg@mars22.com](mailto:huangyg@mars22.com)，通常安排在后面某天的早餐（5:15~5:59）或会议时间（6:00~6:45）。
+
+
+---
+<a id="index"></a>
+- 07:45	[新season metadata生成日计划](#20240426074500)  
+- 09:30	[knowledge新metadata输出view](#20240426093000)  
+- 14:00	[debug,yaml.dump后|符号编程>符号而且加了换行。](#20240426140000)  
+- 14:30	[整理各git托管商的page协议。](#20240426143000)  
+- 16:00	[新season metadata生成日小结](#20240426160000)  
+
+---
+
+
+[top](#top) | [index](#index)
+<a id="20240426074500"></a>
+## 7:45~8:44
+新season metadata生成日计划
+
+- 主要解决模块化，学习使用module、require。
+- 完成新版日计划：
+```
+
+D:\huangyg\git\ego\src>node ego time init 1
+seasonpath:../data/season/2024S2.yaml
+../../draft/2024/04/d.20240426.yaml
+date: 20240426
+plan: 1
+time:
+  - begin: '20240426074500'
+    amount: 60
+    type: work
+    subject: tbd
+    name: tbd
+    output: draft/2024/04/20240426074500.md
+  - begin: '20240426093000'
+    amount: 90
+    type: work
+    subject: tbd
+    name: tbd
+    output: draft/2024/04/20240426093000.md
+  - begin: '20240426140000'
+    amount: 30
+    type: work
+    subject: tbd
+    name: tbd
+    output: draft/2024/04/20240426140000.md
+  - begin: '20240426143000'
+    amount: 30
+    type: work
+    subject: tbd
+    name: tbd
+    output: draft/2024/04/20240426143000.md
+  - begin: '20240426160000'
+    amount: 60
+    type: work
+    subject: tbd
+    name: tbd
+    output: draft/2024/04/20240426160000.md
+```
+```
+D:\huangyg\git\ego\src>node ego time init
+seasonpath:../data/season/2024S2.yaml
+time slice draft file name:../../draft/2024/04/20240426074500.md
+## 07:45 ~ 08:45
+
+新season metadata生成日计划小结
+
+
+time slice draft file name:../../draft/2024/04/20240426093000.md
+## 09:30 ~ 11:00
+
+knowledge新metadata输出view
+
+
+time slice draft file name:../../draft/2024/04/20240426140000.md
+## 14:00 ~ 14:30
+
+debug,yaml.dump后|符号编程>符号而且加了换行。
+
+
+time slice draft file name:../../draft/2024/04/20240426143000.md
+## 14:30 ~ 15:00
+
+整理各git托管商的page协议。
+
+
+time slice draft file name:../../draft/2024/04/20240426160000.md
+## 16:00 ~ 17:00
+
+knowledge新metadata生成内容板块
+
+
+dayplan file name:
+time/d.20240426.md
+content:
+# 20240426
+
+计划
+
+根据[ego模型时间接口](https://gitee.com/hyg/blog/blob/master/timeflow.md)，今天绑定模版1。
+
+| 时间片 | 时长 | 用途 | 手稿 |
+| --- | --- | --- | --- |
+| 04:00~04:14 | 15 | 休整 |  |
+| 04:15~05:14 | 60 | 备餐、运动 |  |
+| 05:15~05:59 | 45 | 早餐 |  |
+| 06:00~06:44 | 45 | 会议、自习 |  |
+| 06:45~07:44 | 60 | 休整 |  |
+| 07:45~08:44 | 60 | 静默工作 | 新season metadata生成日计划小结  [在线同步](http://simp.ly/p/xtgD4F) [离线归档](../../draft/2024/04/20240426074500.md) |
+| 08:45~09:29 | 45 | 休整 |  |
+| 09:30~10:59 | 90 | 静默工作 | knowledge新metadata输出view  [在线同步](http://simp.ly/p/j1SspP) [离线归档](../../draft/2024/04/20240426093000.md) |
+
+| 11:00~13:59 | 180 | 备餐、午餐午休 |  |
+| 14:00~14:29 | 30 | 静默工作 | debug,yaml.dump后|符号编程>符号而且加了换行。  [在线同步](http://simp.ly/p/8t3vlk) [离线归档](../../draft/2024/04/20240426140000.md) |
+| 14:30~14:59 | 30 | 静默工作 | 整理各git托管商的page协议。  [在线同步](http://simp.ly/p/5k9gJy) [离线归档](../../draft/2024/04/20240426143000.md) |
+
+| 15:00~15:59 | 60 | 休整 |  |
+| 16:00~16:59 | 60 | 静默工作 | knowledge新metadata生成内容板块  [在线同步](http://simp.ly/p/4QDThK) [离线归档](../../draft/2024/04/20240426160000.md) |
+| 17:00~18:59 | 120 | 晚餐 |  |
+| 19:00~19:59 | 60 | 讨论、整理提交 |  |
+
+模版一采用静默工作方式。
+希望讨论的提纲发到 [huangyg@mars22.com](mailto:huangyg@mars22.com)，通常安排在后面某天的早餐（5:15~5:59）或会议时间（6:00~6:45）。
+
+
+---
+- task:ego  [新season metadata生成日计划小结](../../../draft/2024/04/20240426074500.md)
+- task:PSMD  [knowledge新metadata输出view](../../../draft/2024/04/20240426093000.md)
+- task:PSMD  [debug,yaml.dump后|符号编程>符号而且加了换行。](../../../draft/2024/04/20240426140000.md)
+- task:learn  [整理各git托管商的page协议。](../../../draft/2024/04/20240426143000.md)
+- task:PSMD  [knowledge新metadata生成内容板块](../../../draft/2024/04/20240426160000.md)
+```
+
+[top](#top) | [index](#index)
+<a id="20240426093000"></a>
+##  9:30~10:59
+knowledge新metadata输出view
+
+- 使用新的knowledge metadata，为error markdown增加内容。
+- /PSMD/src/term.js  makeerrorview() makeerrornet()
+
+```
+
+D:\huangyg\git\PSMD\src>node term error 0ccddb29
+0ccddb29>enter makeerrornet: 0ccddb29 已查找的knowledge:
+{}
+
+0ccddb29>search knowledge: 1
+0ccddb29>search knowledge: 2
+0ccddb29>search knowledge: 3b7582cd
+0ccddb29>发现knowledge 3b7582cd :使用termset [056e71fb](../view/term.056e71fb.md)  可能解决 error 0ccddb29 预估有效的比例是 50%
+0ccddb29>使用knowledge 3b7582cd 需要先解决error:
+0ccddb29>[48291d8c](../view/error.48291d8c.md)
+0ccddb29>48291d8c>enter makeerrornet: 48291d8c 已查找的knowledge:
+3b7582cd: true
+
+0ccddb29>48291d8c>search knowledge: 1
+0ccddb29>48291d8c>search knowledge: 2
+0ccddb29>48291d8c>search knowledge: 3b7582cd
+0ccddb29>48291d8c>search knowledge: d8a0602f
+0ccddb29>48291d8c>发现knowledge d8a0602f :使用term [5b4e0597](../view/term.5b4e0597.md) 可能解决 error 48291d8c 预估有效的比例是 60%
+0ccddb29>48291d8c>使用knowledge d8a0602f 需要先解决error:
+0ccddb29>48291d8c>[cde3c3e2](../view/error.cde3c3e2.md)
+0ccddb29>48291d8c>cde3c3e2>enter makeerrornet: cde3c3e2 已查找的knowledge:
+3b7582cd: true
+d8a0602f: true
+
+0ccddb29>48291d8c>cde3c3e2>search knowledge: 1
+0ccddb29>48291d8c>cde3c3e2>search knowledge: 2
+0ccddb29>48291d8c>cde3c3e2>search knowledge: 3b7582cd
+0ccddb29>48291d8c>cde3c3e2>search knowledge: d8a0602f
+0ccddb29>search knowledge: d8a0602f
+../view/error.0ccddb29.md文件更新，内容如下:
+问题 0ccddb29 正文:
+出现以下情况之一：
+- 决策部门未界定执行部门工作的合规性要求。
+- 决策部门界定了执行部门工作的合规性要求。
+  - 执行部门成员对指令不进行合规检查，即使不合规也执行。
+  - 执行部门成员及下达指令者未按要求填写和提交表单，比如工单、日志。
+
+---
+问题 0ccddb29 readme:
+- 下达指令者的指令包括对更早指令的掩盖，通过互相包庇产生系统性的对抗。
+- 共同体曾经对下达指令者违约，以一定范围内的割据作为抵押物。这是历史上资源紧缺，无法兑现约定报酬的后遗症。
+- 把一定范围内的割据作为违约抵押物的情况，解除割据应该同时处理历史欠账。在共同体设立阶段，就要确定是否符合<term.1>，如果符合应该在设立时解决。
+
+---
+解决建议:
+0ccddb29>发现knowledge 3b7582cd :使用termset [056e71fb](../view/term.056e71fb.md)  可能解决 error 0ccddb29 预估有效的比例是 50%
+0ccddb29>使用knowledge 3b7582cd 需要先解决error:
+0ccddb29>[48291d8c](../view/error.48291d8c.md)
+
+0ccddb29>48291d8c>发现knowledge d8a0602f :使用term [5b4e0597](../view/term.5b4e0597.md) 可能解决 error 48291d8c 预估有效的比例是 60%
+0ccddb29>48291d8c>使用knowledge d8a0602f 需要先解决error:
+0ccddb29>48291d8c>[cde3c3e2](../view/error.cde3c3e2.md)
+
+
+---
+```
+
+[top](#top) | [index](#index)
+<a id="20240426140000"></a>
+## 14:00~14:29
+debug,yaml.dump后|符号编程>符号而且加了换行。
+
+error.0ccddb29的手稿内容
+```
+readme: |
+  - <entity.2>的指令包括对更早指令的掩盖，通过互相包庇产生系统性的对抗。
+  - <entity.1>曾经对<entity.2>违约，以一定范围内的割据作为抵押物。这是历史上资源紧缺，无法兑现约定报酬的后遗症。
+  - 把一定范围内的割据作为违约抵押物的情况，解除割据应该同时处理历史欠账。在<entity.1>设立阶段，就要确定是否符合<term.1>，如果符合应该在设立时解决。
+```
+被dump成正规内容
+```
+readme: >
+  - <entity.2>的指令包括对更早指令的掩盖，通过互相包庇产生系统性的对抗。
+
+  - <entity.1>曾经对<entity.2>违约，以一定范围内的割据作为抵押物。这是历史上资源紧缺，无法兑现约定报酬的后遗症。
+
+  -
+  把一定范围内的割据作为违约抵押物的情况，解除割据应该同时处理历史欠账。在<entity.1>设立阶段，就要确定是否符合<term.1>，如果符合应该在设立时解决。
+```
+
+- yaml.load增加参数), { schema: yaml.FAILSAFE_SCHEMA }); 不变。
+- 去掉每行开头前面”-“，不变。
+- 只留一行。是好的，|还是|，末尾加了换行。
+- 只留一行，|改成|-，变成直接定义的字符串；readme: <entity.2>的指令包括对更早指令的掩盖，通过互相包庇产生系统性的对抗。
+- 多行，|改成|-。末尾加了回车，其它准确复刻。
+- 每行开头增加”-“。末尾加了回车，其它准确复刻。
+- 改回原始文件，问题重新。
+- 原始文件第三行砍到80字符以内。末尾加了回车，其它准确复刻。
+- yaml.dump增加参数,{'lineWidth  ': -1}));末尾加了回车，其它准确复刻。
+- 全部yaml.dump()都增加了参数,{'lineWidth': -1}));
+
+
+[top](#top) | [index](#index)
+<a id="20240426143000"></a>
+## 14:30~14:59
+整理各git托管商的page协议。
+
+### github
+
+- https://docs.github.com/zh/pages/getting-started-with-github-pages
+- 若要发布用户站点，必须创建名为 <username>.github.io 的个人帐户拥有的存储库。 若要发布组织站点，必须创建名为 <organization>.github.io 的组织帐户拥有的存储库。 除非使用的是自定义域，否则用户和组织站点在 http(s)://<username>.github.io 或 http(s)://<organization>.github.io 中可用。
+- 项目站点的源文件与其项目存储在同一个仓库中。 除非使用的是自定义域，否则项目站点在 http(s)://<username>.github.io/<repository> 或 http(s)://<organization>.github.io/<repository> 中可用。
+- 修改项目设置和DNS：https://docs.github.com/zh/pages/configuring-a-custom-domain-for-your-github-pages-site/managing-a-custom-domain-for-your-github-pages-site#configuring-a-subdomain
+
+### conberg
+
+- https://codeberg.page/
+- Create a public repository named pages to make the site available at the main subdomain. 
+- Push your static content, HTML, style, fonts, images or anything else. 
+- Access your new website using this link:
+https://USERNAME.codeberg.page[/REPOSITORY][/@BRANCH]
+- To use a custom domain, create a file .domains in your repository with the domain name you wish to use. Then, add a DNS record for that domain:
+```
+CNAME [[branch.]repo.]user.codeberg.page.
+```
+- Or for apex domains where CNAME doesn't work:
+```
+ALIAS codeberg.page.
+TXT [[branch.]repo.]user.codeberg.page
+```
+- If ALIAS isn't supported, use A & AAAA instead:
+```
+A 217.197.91.145
+AAAA 2001:67c:1401:20f0::1
++ TXT as above 
+```
+
+### gitee
+
+- https://gitee.com/help/articles/4136
+- 想以ipvb.gitee.io直接访问，那么他就可以创建一个名字为ipvb的仓库 https://gitee.com/ipvb/ipvb 部署完成后，就可以以 https://ipvb.gitee.io 进行访问了。
+- 仓库必须有 index.html 才可以正常访问
+- 你尚未通过实名认证，无法使用 Pages 服务，如需使用，请先进行实名认证。 
+    - 手持证件照是手持身份证与本人面部的合照。
+
+### coding
+
+- https://cloud.tencent.com/developer/article/1906710
+- 菜单已经变化，没有page服务入口。
+
+
+综合看，还是先使用codeberg，其次是github。争取一个本地库push两个托管方。
+
+[top](#top) | [index](#index)
+<a id="20240426160000"></a>
+## 16:00~16:59
+新season metadata生成日小结
+
+- 已完成，格式微调，明天可以试用。
+- 浮动时间表的优先级往后方，先抓紧实现任务和时间之间的压力传递：
+    - 对外承诺的任务，按期限向前排子任务。
+    - 长期任务的子任务按优先级排序，自动填充进入时间表。 
+    - 尽快让它们产生相互竞争，好设计资源调度的规则。

release/time/d.20240427.md

@@ -0,0 +1,341 @@
+# 2024.04.27.
+日小结  
+
+<a id="top"></a>
+根据[ego模型时间接口](https://gitee.com/hyg/blog/blob/master/timeflow.md)，今天绑定模版1。
+
+| 时间片 | 时长 | 用途 | 手稿 |
+| --- | --- | --- | --- |
+| 04:00~04:14 | 15 | 休整 |  |
+| 04:15~05:14 | 60 | 备餐、运动 |  |
+| 05:15~05:59 | 45 | 早餐 |  |
+| 06:00~06:44 | 45 | 会议、自习 |  |
+| 06:45~07:44 | 60 | 休整 |  |
+| 07:45~08:44 | 60 | 静默工作 | [task和timeslice配对的需求分析和设计](#20240427074500) |
+| 08:45~09:29 | 45 | 休整 |  |
+| 09:30~10:59 | 90 | 静默工作 | [使用knowledge metadata生成error view内容](#20240427093000) |
+| 11:00~13:59 | 180 | 备餐、午餐午休 |  |
+| 14:00~14:29 | 30 | 静默工作 | [分析term和termset是否可以合并](#20240427140000) |
+| 14:30~14:59 | 30 | 静默工作 | [eval、function、import() 范例](#20240427143000) |
+| 15:00~15:59 | 60 | 休整 |  |
+| 16:00~16:59 | 60 | 静默工作 | [整理治理相关数据结构，为自动分录做好准备。](#20240427160000) |
+| 17:00~18:59 | 120 | 晚餐 |  |
+| 19:00~19:59 | 60 | 讨论、整理提交 |  |
+
+模版一采用静默工作方式。  
+希望讨论的提纲发到 [huangyg@mars22.com](mailto:huangyg@mars22.com)，通常安排在后面某天的早餐（5:15~5:59）或会议时间（6:00~6:45）。
+
+---
+
+<a id="index"></a>
+- 07:45	[task和timeslice配对的需求分析和设计](#20240427074500)  
+- 09:30	[使用knowledge metadata生成error view内容](#20240427093000)  
+- 14:00	[分析term和termset是否可以合并](#20240427140000)  
+- 14:30	[eval、function、import() 范例](#20240427143000)  
+- 16:00	[整理治理相关数据结构，为自动分录做好准备。](#20240427160000)  
+
+
+---
+
+[top](#top) | [index](#index)
+<a id="20240427074500"></a>
+## 7:45~8:44
+task和timeslice配对的需求分析和设计
+
+### 流程
+由于任务间压力还没有实际产生，里程碑和任务之间关系也不明确，只能按预估的情形确定需求：  
+
+- 在每天结束时，排出次日每种模版的配对。
+- 根据各种模版的配对，人工调整metadata。
+- 在每天开始时，自动按模版一次生成draft metadata和draft markdown文件。
+
+
+### 数据结构
+如果fs读写同一个文件还是内容混乱，就设置多个metadata文件。
+
+- 正式的候选任务写在todo.yaml中，人工编辑。
+- 排出每种模版配对时，代码把每种配对产生的次日更新写在nexttodo.yaml中。这过程可以反复进行。
+- 在正式绑定模版时，读取nexttodo.yaml中对应部分，直接写入todo.yaml。这一步不读todo.yaml。
+
+todo.yaml
+```
+taskname:
+  - 30: subtask1
+    readme: |
+      subtask detail info.
+  - 60: subtask2
+taskname:
+    - 30: 1
+    - 30: 2
+```
+
+nexttodo.yaml
+```
+dayplan1:
+  todo.yaml content
+dayplan2:
+  another todo.yaml
+```
+
+
+---
+
+[top](#top) | [index](#index)
+<a id="20240427093000"></a>
+##  9:30~10:59
+使用knowledge metadata生成error view内容
+
+基础概念：  
+
+- 个人领域划分出有意识和无意识两部分；
+- 共同体成员首先在最基层单元中，互相确认职务行为是有意识还是无意识的。
+    - 有意识的行为：基于理性人假设，从行为偏差分析规章偏差，根据情况产生工单。
+        - 共同体knowledge为这个过程提供迭代更新的知识，以提高自动化程度。
+    - 无意识的行为：暂时停职，由个人领域自行纠偏，然后根据情况恢复或者重新竞聘。
+        - 共同体knowledge不介入，个人领域knowledge为这个过程提供迭代更新的知识。
+
+
+修改\psmd\src\term.js 中的makeerrorview() makeerrornet() 执行结果如下:
+```
+
+D:\huangyg\git\PSMD\src>node term error 0ccddb29
+    - 0ccddb29>发现knowledge 3b7582cd :使用termset [056e71fb](../view/term.056e71fb.md)  可能解决 error 0ccddb29 预估有效的比例是 50%
+    - 0ccddb29>使用knowledge 3b7582cd 需要先解决error:
+    - 0ccddb29>[48291d8c](../view/error.48291d8c.md)
+    - 0ccddb29>48291d8c>发现knowledge d8a0602f :使用term [5b4e0597](../view/term.5b4e0597.md) 可能解决 error 48291d8c 预估有效的比例是 60%
+    - 0ccddb29>48291d8c>使用knowledge d8a0602f 需要先解决error:
+    - 0ccddb29>48291d8c>[cde3c3e2](../view/error.cde3c3e2.md)
+../view/error.0ccddb29.md文件更新，内容如下:
+问题 0ccddb29 正文:
+出现以下情况之一：
+- 决策部门未界定执行部门工作的合规性要求。
+- 决策部门界定了执行部门工作的合规性要求。
+  - 执行部门成员对指令不进行合规检查，即使不合规也执行。
+  - 执行部门成员及下达指令者未按要求填写和提交表单，比如工单、日志。
+
+---
+问题 0ccddb29 readme:
+- 下达指令者的指令包括对更早指令的掩盖，通过互相包庇产生系统性的对抗。
+- 共同体曾经对下达指令者违约，以一定范围内的割据作为抵押物。这是历史上资源紧缺，无法兑现约定报酬的后遗症。
+- 把一定范围内的割据作为违约抵押物的情况，解除割据应该同时处理历史欠账。在共同体设立阶段，就要确定是否符合资源不足，如果符合应该在设立时解决。
+
+---
+解决建议:
+出现偏差的部门内部互相确认:相关职务行为是有意识还是无意识的。
+  - 无意识的行为：应暂时停职，由相关成员自行纠偏，然后根据情况复职或者重新竞聘。
+  - 有意识的行为：可以基于理性人假设，从行为偏差分析规章偏差，根据情况产生工单。可以参考以下内容：
+    - 0ccddb29>发现knowledge 3b7582cd :使用termset [056e71fb](../view/term.056e71fb.md)  可能解决 error 0ccddb29 预估有效的比例是 50%
+    - 0ccddb29>使用knowledge 3b7582cd 需要先解决error:[48291d8c](../view/error.48291d8c.md)
+    - 0ccddb29>48291d8c>发现knowledge d8a0602f :使用term [5b4e0597](../view/term.5b4e0597.md) 可能解决 error 48291d8c 预估有效的比例是 60%
+    - 0ccddb29>48291d8c>使用knowledge d8a0602f 需要先解决error:[cde3c3e2](../view/error.cde3c3e2.md)
+
+---
+```
+
+```
+
+D:\huangyg\git\PSMD\src>node term error 48291d8c
+    - 48291d8c>发现knowledge d8a0602f :使用term [5b4e0597](../view/term.5b4e0597.md) 可能解决 error 48291d8c 预估有效的比例是 60%
+    - 48291d8c>使用knowledge d8a0602f 需要先解决error:
+    - 48291d8c>[cde3c3e2](../view/error.cde3c3e2.md)
+../view/error.48291d8c.md文件更新，内容如下:
+问题 48291d8c 正文:
+共同体涉及未来收入的承诺，无法保证兑现。因此，无法使用未来收入换取当下资源，只能以现有资源进行交易。
+
+---
+问题 48291d8c readme:
+可能的原因包括：
+  - 共同体内部废除该承诺，可能成为有效力的决议；
+  - 共同体内部对同一笔未来收入安排其它用途，可能成为有效力的预算案。
+
+---
+解决建议:
+出现偏差的部门内部互相确认:相关职务行为是有意识还是无意识的。
+  - 无意识的行为：应暂时停职，由相关成员自行纠偏，然后根据情况复职或者重新竞聘。
+  - 有意识的行为：可以基于理性人假设，从行为偏差分析规章偏差，根据情况产生工单。可以参考以下内容：
+    - 48291d8c>发现knowledge d8a0602f :使用term [5b4e0597](../view/term.5b4e0597.md) 可能解决 error 48291d8c 预估有效的比例是 60%
+    - 48291d8c>使用knowledge d8a0602f 需要先解决error:[cde3c3e2](../view/error.cde3c3e2.md)
+
+---
+```
+
+```
+D:\huangyg\git\PSMD\src>node term error cde3c3e2
+../view/error.cde3c3e2.md文件更新，内容如下:
+问题 cde3c3e2 正文:
+违规收益超过违规成本。违规造成的既成事实被接受。
+
+---
+问题 cde3c3e2 readme:
+
+---
+解决建议:
+出现偏差的部门内部互相确认:相关职务行为是有意识还是无意识的。
+  - 无意识的行为：应暂时停职，由相关成员自行纠偏，然后根据情况复职或者重新竞聘。
+  - 有意识的行为：可以基于理性人假设，从行为偏差分析规章偏差，根据情况产生工单。如需进一步建议请联系<huang@mars22.com>
+---
+```
+---
+
+[top](#top) | [index](#index)
+<a id="20240427140000"></a>
+## 14:00~14:29
+分析term和termset是否可以合并
+
+新的term结构： 
+
+- 增加item字段，改为subterm。
+  - 取消item.path，改由统一的接口从id获得path、obj
+  - 取消item.type，统统都是term
+  - 暂时保留upgradeby字段，实际使用后再定。
+- 增加depend、together字段，结合原有的effect字段代替knowledge
+  - 默认是termtoerror，因为没有type，而effect的id也是errorid
+  - 可能有不止一种效果，每种效果的depend、together不同，这时仍需要knowledge
+- 保留原有的text字段，作为高于item下子条款一级的正文。
+
+```
+name:
+id:
+interface:
+  entity:
+    id: name
+  asset:
+    id: name
+  term:
+    id: name
+  event:
+    id: name
+text: |
+subterm:
+  - sortid:
+      id:
+      upgradeby: // sortid.sortid.....id  上级定义覆盖下级定义
+      map:
+        entity:
+          localid: globalid
+        asset:
+          localid: globalid
+        term:
+          localid: globalid
+        event:
+          localid: globalid
+readme: |
+depend:
+  errorid:
+    percent:
+    text: | 
+together:
+  errorid:
+    percent:
+    text: |
+effect: |
+  errorid:
+    percent:
+    text: |
+```
+
+---
+
+[top](#top) | [index](#index)
+<a id="20240427143000"></a>
+## 14:30~14:59
+eval、function、import() 范例
+
+- 为了让数据结构不断升级，各版本的数据结构和代码配套，由稳定的结构调用。
+- 这种用途import()最方便。
+
+范例在\js.sample\codestr ，执行结果：
+```
+D:\huangyg\git\js.sample\codestr>node main
+data:123456
+60:60str
+```
+
+---
+
+[top](#top) | [index](#index)
+<a id="20240427160000"></a>
+## 16:00~16:59
+整理治理相关数据结构，为自动分录做好准备。
+
+### xuemen
+
+- 公司章程
+    - 三会动议、决议、会议纪要
+- 1-2.章程实施细则
+    - 股东会决议：决定公司状态
+        - 进入S4状态的决议明确业务范围
+    - 财务会计报告：
+        - 进入、离开S1状态
+        - 
+    - 股东会决议：任命S1状态下的执行董事
+    - 股东会决议：离开S1状态的补偿方案
+- 2-1.全局模型
+    - 核心模型
+    - ISU模型
+        - 内务需求
+        - 内务工作计划以及预算方案
+    - JPU模型
+    - 通用工单
+    - 通用日志
+    - 临时模型
+    - 审议记录
+- 2-3.ISU模型
+    - Token决算数据包[TBP:Token Balance Package]
+    - 财务管理制度
+- 2-4.JPU模型
+    - 产品模型
+    - 产品配置备忘录(P2CM:Product Configuration Memo)
+    - 预购意见
+    - 预购权重调整方案
+    - 工作计划及预算方案
+    - 工作总结及结算方案
+    - 结项方案
+
+### xuemen.record
+目前是AER、TEO、TER、AVR记录文件。
+
+- 会计分录记录	Accounting Entry Record	AER
+- Token交易委托	Token Exchange Order	TEO
+- Token交易记录	Token Exchange Record	TER
+- 会计凭证	Accounting Voucher Record	AVR
+
+### 自动分录
+
+- 会计分录规则	Accounting Entry Code	AEC
+```
+CodeID:
+VoucherType: 利息回单
+code:
+  path:
+  hash:
+map:
+- AVRitem: amount
+  AERitem: 
+- AVRitem:
+  AERitem:
+
+AVR字段和AER字段映射
+```
+- 以 xuemen.record\ISU2019.AVR.1.yaml ISU2019.AER.1.yaml这一对文件为例：
+    - AEC.map字段无法表达：
+        - AccountingEntry.debit.AccountTitle = 银行存款-交通银行 amount=AVRitem: 金额
+        - AccountingEntry.debit.AccountTitle = 财务费用-利息费用 amount=AVRitem: 金额 *-1
+        - AccountingSoftwareID
+    - code字段：可以表达以上关系
+```
+map:
+- AVRitem: 记账日期
+  AERitem: date
+- AVRitem: 回单编号
+  AERitem: VoucherID
+- AVRitem: 金额
+  AERitem: AccountingEntry.debit.amount
+```
+- 让AEC生效需要以下六层决议：
+    - 董事会决议：AEC生效
+    - 董事会决议：3-02.财务管理制度
+    - 董事会决议：2-3.ISU模型
+    - 股东会决议：2-1.全局模型
+    - 股东会决议：1-2.章程实施细则
+    - 股东会决议：1-1.章程

release/time/d.20240428.md

@@ -0,0 +1,317 @@
+# 20240428
+
+小结  
+
+<a id="top"></a>
+根据[ego模型时间接口](https://gitee.com/hyg/blog/blob/master/timeflow.md)，今天绑定模版1。
+
+| 时间片 | 时长 | 用途 | 手稿 |
+| --- | --- | --- | --- |
+| 04:00~04:14 | 15 | 休整 |  |
+| 04:15~05:14 | 60 | 备餐、运动 |  |
+| 05:15~05:59 | 45 | 早餐 |  |
+| 06:00~06:44 | 45 | 会议、自习 |  |
+| 06:45~07:44 | 60 | 休整 |  |
+| 07:45~08:44 | 60 | 静默工作 | [月份总结报告](#20240428074500) |
+| 08:45~09:29 | 45 | 休整 |  |
+| 09:30~10:59 | 90 | 静默工作 | [试用term新结构，根据问题更新设计。](#20240428093000) |
+| 11:00~13:59 | 180 | 备餐、午餐午休 |  |
+| 14:00~14:29 | 30 | 静默工作 | [季度总结报告](#20240428140000) |
+| 14:30~14:59 | 30 | 静默工作 | [debug-nodejs fs读写同一个文件的内容混乱。](#20240428143000) |
+| 15:00~15:59 | 60 | 休整 |  |
+| 16:00~16:59 | 60 | 静默工作 | [填写term metadata的readme字段，增加成员无意识行为的特征](#20240428160000) |
+| 17:00~18:59 | 120 | 晚餐 |  |
+| 19:00~19:59 | 60 | 讨论、整理提交 |  |
+
+模版一采用静默工作方式。  
+希望讨论的提纲发到 [huangyg@mars22.com](mailto:huangyg@mars22.com)，通常安排在后面某天的早餐（5:15~5:59）或会议时间（6:00~6:45）。
+
+
+---
+<a id="index"></a>
+- 07:45	[月份总结报告](#20240428074500)  
+- 09:30	[试用term新结构，根据问题更新设计。](#20240428093000)  
+- 14:00	[季度总结报告](#20240428140000)  
+- 14:30	[debug-nodejs fs读写同一个文件的内容混乱。](#20240428143000)  
+- 16:00	[填写term metadata的readme字段，增加成员无意识行为的特征](#20240428160000)  
+
+---
+
+
+[top](#top) | [index](#index)
+<a id="20240428074500"></a>
+## 7:45~8:44
+月份总结报告
+
+月份总结范例
+```
+三月份
+
+日平均值，和二月对比：
+热量1896.56千卡，+2.17千卡；
+蛋白质76.52克，-0.28克；（RNI：65）
+脂肪59.17克，+5.6克；
+碳水270.47克，-18.46克；
+钠2.15克，+0.14克；
+膳食纤维33.96克，-1.18克；（AI：25~30）
+钙1.38克，+0.15克；（RNI：0.8）
+水2598.34ml ​​​，-145.12ml。
+
+脂肪供能28.08%%（AMDR：20~30%） 
+碳水供能57.04%（AMDR：50~65%）
+蛋白质供能16.14%（AMDR：10~15%）
+膳食纤维供能3.58%
+```
+
+季度总结范例
+```
+一季度
+
+日平均值，和去年四季度对比：
+热量1922.30千卡，+83.61千卡；
+蛋白质81.86克，-3.5克；（RNI：65）
+脂肪55.81克，+3.64克；
+碳水281.98克，+20.85克；
+钠2.13克，-0.15克；
+膳食纤维35.11克，-0.3克；（AI：25~30）
+钙1.31克，+0.1克；（RNI：0.8）
+水2634.08ml ​​​，+263.77ml。
+
+脂肪供能26.13%（AMDR：20~30%） 
+碳水供能58.68%（AMDR：50~65%）
+蛋白质供能17.03%（AMDR：10~15%）
+膳食纤维供能3.65%
+```
+
+- 因为全局变量使用太多，化了不少时间适应。
+- 建立了foodmonthreport() 基本框架。在原模版上增加去年同期的对比，把月度报告的第一行热量算出来了。
+    - 有可能做所有营养成分对比。
+- 还需要60时间片完成余下部分。
+
+执行结果：
+```
+D:\huangyg\git\raw>node raw 202404
+>> 脂肪供能25.86%  碳水供能57.39%  蛋白质供能17.86% <<
+名称            总数量          日均    单位    NRV(%)
+番茄红素        58.68           2.10    mg      0.00
+灰分            15.41           0.55    g       0.00
+硅              56.00           2.00    mg      0.00
+叶黄素          7.00            0.25    mg      0.00
+硼              4.20            0.15    mg      0.00
+钒              280.00          10.00   μg      0.00
+氯              1.96            0.07    g       3.00
+胆固醇          4.33            0.15    g       51.61
+磷              14.58           0.52    g       69.54
+胡萝卜素        33.93           1.21    mg      79.87
+钠              54.38           1.94    g       90.39
+脂肪            1532.90         54.75   g       93.87
+碳水化合物      7653.00         273.32  g       95.49
+镁              9.75            0.35    g       96.64
+生物素          840.00          30.00   μg      100.00
+钼              1.26            0.04    mg      100.00
+碘              4.22            0.15    mg      100.42
+热量            53338.87        1904.96 kcal    102.49
+水              68878.50        2459.95 ml      123.00
+钾              78.24           2.79    g       127.89
+铬              1.26            0.04    mg      129.00
+膳食纤维        971.88          34.71   g       131.00
+钙              38.08           1.36    g       138.35
+蛋白质          2382.17         85.08   g       143.55
+铁              556.07          19.86   mg      161.15
+锰              109.45          3.91    mg      161.59
+锌              520.01          18.57   mg      165.92
+VB3(烟酸)       745.07          26.61   mg      176.82
+VB1(硫胺素)     3.77            0.13    g       179.76
+铜              47.07           1.68    mg      179.76
+VE(生育酚)      1.24            0.04    g       209.57
+VB5(泛酸)       293.43          10.48   mg      209.59
+VB2(核黄素)     94.01           3.36    mg      241.15
+VB9(叶酸)       18.39           0.66    mg      251.94
+VB6(吡哆素)     116.78          4.17    mg      254.76
+VA(视黄醇等)    65.89           2.35    mg      268.19
+VD3(胆钙化醇)   1.70            0.06    mg      303.92
+VK(凝血维生素)  7.19            0.26    mg      307.92
+VC(抗坏血酸)    10.83           0.39    g       439.09
+硒              7.60            0.27    mg      493.34
+VB12(钴胺素)    732.77          26.17   μg      1090.94
+
+20240401 ~ 20240500 : 28 days.
+
+---
+月度报告
+四月份
+
+日平均值，和三月份、去年四月份对比:
+热量1904.96千卡， +8.40、+146.67千卡；
+
+health/heartrate.R文件已被保存。在R环境运行 source("D:/huangyg/git/raw/health/heartrate.R",encoding = "UTF-8")
+health/sleep.R文件已被保存。在R环境运行 source("D:/huangyg/git/raw/health/sleep.R",encoding = "UTF-8")
+health/weight.R文件已被保存。在R环境运行 source("D:/huangyg/git/raw/health/weight.R",encoding = "UTF-8")
+```
+
+
+[top](#top) | [index](#index)
+<a id="20240428093000"></a>
+##  9:30~10:59
+试用term新结构，根据问题更新设计。
+
+- 选择一个termset.01e1c775，先生成view，再根据它编辑新的term temp metadata:
+```
+D:\huangyg\git\PSMD\src>node term termset 01e1c775
+../view/termset.01e1c775.md文件更新，内容如下:
+1. 由deployer书面提交即生效。
+2. p=20，p%=20%。
+3. 由director表决按一人一票表决，超过80%出席会议有效，赞成票超过超过三分之二为通过。
+
+---
+
+1. readme:
+2. readme:
+3. readme:
+
+---
+```
+- 这个结构中，自修订条款“由deployer书面提交即生效。”还是应该作为单独条款。
+- 而另外增加一层结构定义“p=20，p%=20%”由自修订条款修订。在这层结构中，自修订条款以termid被引用，而不是text字段。
+
+有两种解决方案：
+
+### 方案一：强化新term
+
+- 在新term基础上，
+- 新增body字段，作为高于subterm自条款一级的正文。用termid引用但是不增加sortid，view中也不增加prefix。
+- 废弃termset。
+
+根据termset.01e1c775编辑的范例：
+```
+name: 调整分配主比例
+id: 1
+interface:
+  entity:
+    '1': deployer
+    '2': director
+  asset:
+    '1': p
+text: |
+body: 
+  64eb9304:
+    upgradeby: 64eb9304
+    map:
+      entity:
+        '1': 1
+subterm:
+  - sortid: 1
+    type: term
+    id: bba7c6f1
+    upgradeby: 64eb9304
+    path: PSMD/data/term.bba7c6f1.yaml
+    map:
+      asset:
+        '1': 1
+  - sortid: 2
+    type: term
+    id: 177700d4
+    upgradeby: 64eb9304
+    path: PSMD/data/term.177700d4.yaml
+    map:
+      entity:
+        '1': 2
+readme: |
+depend:
+  errorid:
+    percent:
+    text: | 
+together:
+  errorid:
+    percent:
+    text: |
+effect:
+  errorid:
+    percent:
+    text: |
+```
+
+### 方案二：保留termset
+
+- 在termset中增加body字段，表示termset的正文，不增加sortid和prefix。
+- 在termset中取消path字段。
+- 在termset中effect基础上，增加depend togetther 字段。
+- 新term结构中可以去掉subterm字段。
+
+详细方案在/PSMD/data/README.md
+
+
+[top](#top) | [index](#index)
+<a id="20240428140000"></a>
+## 14:00~14:29
+季度总结报告
+
+- 继续完成月份总结报告。执行结果：
+```
+D:\huangyg\git\raw>node raw 202404
+......
+---
+月度报告
+四月份
+
+日平均值，和三月份、去年四月份对比:
+热量1904.91kcal， +8.35、+146.62kcal；
+蛋白质85.05g， +7.90、+3.42g；
+脂肪54.72g， -4.45、+5.98g；
+碳水化合物273.40g， +2.93、+24.93g；
+钠1.94g， -0.20、+0.07g；
+膳食纤维34.74g， +0.78、+0.71g；
+钙1.36g， -0.02、+0.35g；
+水2468.86ml， -129.48、+385.34ml；
+
+脂肪供能25.85% （AMDR：20~30%）
+碳水化合物供能57.41% （AMDR：50~65%）
+蛋白质供能17.86% （AMDR：10~15%）
+膳食纤维供能3.65%
+```
+
+- 完成季度总结报告。执行结果：
+```
+D:\huangyg\git\raw>node raw 202403
+......
+---
+季度报告
+一季度
+
+日平均值，和四季度、去年一季度对比:
+热量1922.30kcal， +85.39、-244.03kcal；
+蛋白质82.07g， -3.30、-24.14g；
+脂肪55.81g， +3.68、-17.93g；
+碳水化合物281.98g， +21.21、+14.63g；
+钠2.13g， -0.15、+0.59g；
+膳食纤维35.11g， -0.32、+8.71g；
+钙1.31g， +0.10、-0.08g；
+水2634.08ml， +265.66、+645.56ml；
+
+脂肪供能26.13% （AMDR：20~30%）
+碳水化合物供能58.68% （AMDR：50~65%）
+蛋白质供能17.08% （AMDR：10~15%）
+膳食纤维供能3.65%
+```
+
+
+[top](#top) | [index](#index)
+<a id="20240428143000"></a>
+## 14:30~14:59
+debug-nodejs fs读写同一个文件的内容混乱
+
+- 在 \ego\task\task.js drafttotask(date)中从draft收集log，写回task metadata文件的功能。在node task 1参数下调用。
+- 因为alltask metadata文件结构修改过，需要微调：
+    - alltask.task  -> alltask.tasklist
+- 以前缀 test. 复制一批task metadata文件，作为测试用。
+    - 测试文件加上log字段。
+- 把写回语句从fs.writeFile() 改为writeFileSync() 运行正常。
+
+[top](#top) | [index](#index)
+<a id="20240428160000"></a>
+## 16:00~16:59
+填写term metadata的readme字段，增加成员无意识行为的特征
+
+- 有些readme增加得勉强。
+- 先尽量填写，有真实体会再重新整理需求。
+- 按文件名排序，填写到 term.5c7d5a18

release/time/d.20240429.md

@@ -0,0 +1,308 @@
+# 20240429
+
+小结  
+
+<a id="top"></a>
+根据[ego模型时间接口](https://gitee.com/hyg/blog/blob/master/timeflow.md)，今天绑定模版1。
+
+| 时间片 | 时长 | 用途 | 手稿 |
+| --- | --- | --- | --- |
+| 04:00~04:14 | 15 | 休整 |  |
+| 04:15~05:14 | 60 | 备餐、运动 |  |
+| 05:15~05:59 | 45 | 早餐 |  |
+| 06:00~06:44 | 45 | 会议、自习 |  |
+| 06:45~07:44 | 60 | 休整 |  |
+| 07:45~08:44 | 60 | 静默工作 | [设计新term结构](#20240429074500) |
+| 08:45~09:29 | 45 | 休整 |  |
+| 09:30~10:59 | 90 | 静默工作 | [日小结时更新season metadata中time.sold字段，汇总waitinglist](#20240429093000) |
+| 11:00~13:59 | 180 | 备餐、午餐午休 |  |
+| 14:00~14:29 | 30 | 静默工作 | [复习git，基于分支重新设计开发流程。](#20240429140000) |
+| 14:30~14:59 | 30 | 静默工作 | [初步熟悉npm、winget发布规则](#20240429143000) |
+| 15:00~15:59 | 60 | 休整 |  |
+| 16:00~16:59 | 60 | 静默工作 | [测试划分有意识和下意识行为的措辞](#20240429160000) |
+| 17:00~18:59 | 120 | 晚餐 |  |
+| 19:00~19:59 | 60 | 讨论、整理提交 |  |
+
+模版一采用静默工作方式。  
+希望讨论的提纲发到 [huangyg@mars22.com](mailto:huangyg@mars22.com)，通常安排在后面某天的早餐（5:15~5:59）或会议时间（6:00~6:45）。
+
+
+---
+<a id="index"></a>
+- 07:45	[设计新term结构](#20240429074500)  
+- 09:30	[日小结时更新season metadata中time.sold字段，汇总waitinglist](#20240429093000)  
+- 14:00	[复习git，基于分支重新设计开发流程。](#20240429140000)  
+- 14:30	[初步熟悉npm、winget发布规则](#20240429143000)  
+- 16:00	[测试划分有意识和下意识行为的措辞](#20240429160000)  
+
+---
+
+
+[top](#top) | [index](#index)
+<a id="20240429074500"></a>
+## 7:45~8:44
+设计新term结构
+
+ - 整理章节序号的需求
+ - 收集开放结构文档的参考资料
+
+### 需求
+
+- 能够表达条款之间的关系：
+    - A条款根据B条款修订
+    - A角色由B、C、D角色根据C条款任免
+    - E条款引用F条款
+- 能够根据需要改变序号，比如：
+    - 全局排序
+```
+1. xxx
+2. xxx
+  2.1. xxx
+     2.1.1. xxx
+     2.1.2. xxx
+  2.2. xxx
+...
+123. xxx
+124. xxx
+```
+- 划分章节
+```
+第一章
+第一节
+1. xxx
+2. xxx
+第二节
+1. xxx
+  1.1. xxx
+2. xxx
+附件一
+1. xxx
+2. xxx
+```
+- 在根据不同应用需求改变序号的同时，合同的结构已经运用经验能够稳定、持续地维护。被前提条件隔离得非常稀疏的实践者能够持续地异步交流。
+  - 条款之间关系不能因为频繁更换序号而混乱。
+  - 序号不能因为条款之间复杂关系而无法灵活变更。
+
+### 开放结构文档
+
+#### odf: Open Document Format
+
+- https://www.oasis-open.org/standard/open-document-format-for-office-applications-opendocument-version-1-3
+- https://baike.baidu.com/item/odf/62028913
+  - 用zip打包几个文件夹，包含content、meta、setting、style、manifest等xml文件。
+  - 
+- libreoffice writer保存的odf文件（*.odt）是二进制文件。
+- libreoffice writer保存的flat XML odf文件（*.fodt）是纯文本文件。
+  - 使用<text:list-item>逐层嵌套，产生递增序号。
+  - 序号可选数字、大小写字母、大小写罗马数字（应该不能跳号，不支持中文一二三），在text标签中增加text:style-name="Numbering_20_ABC"、"Numbering_20_IVX"等属性。
+  - 
+- 
+
+#### OpenXPS:Open XML Paper Specification 
+
+- https://www.ecma-international.org/wp-content/uploads/TC46-XPS-White-Paper.pdf
+- 
+
+#### UOF:Unified Office document Format 
+
+- https://baike.baidu.com/item/UOF2.0/3896124
+- libreoffice保存为*.uot文件，是纯文本xml文件。
+  - 文本在字、字.句、字.句.文本串 <字:文本串 uof:locID="t0109" uof:attrList="标识符">2.1.1. xxx</字:文本串>
+  - 编号在字、字.段落、字.段落.段落属性中<字:自动编号信息 uof:locID="t0059" uof:attrList="编号引用 编号级别 重新编号 起始编号" 字:编号引用="Numbering_20_ABC" 字:编号级别="0" 字:重新编号="1" 字:起始编号="1"/>
+
+#### OFD:Open Fixed-layout Documents
+
+- https://openstd.samr.gov.cn/bzgk/gb/newGbInfo?hcno=3AF6682D939116B6F5EED53D01A9DB5D
+- https://www.cnblogs.com/xxss0903/p/17884466.html
+- https://gitee.com/ofdrw/ofdrw
+- 
+
+#### tex
+
+- https://ctan.org/
+- https://latexstudio.net/shredderyin/tex/tex_tds.html
+- 语法
+  - https://zhuanlan.zhihu.com/p/52347414
+  - https://localghost-blog.github.io/latex-tutorial/zh/docs/how-to-write-a-well-structured-latex-file/
+- https://tug.org/texlive/
+  - https://www.cnblogs.com/liuliang1999/p/12656706.html
+- https://zhuanlan.zhihu.com/p/456055339
+- https://zhuanlan.zhihu.com/p/166523064
+
+
+
+- term metadata专注于条款之间的关系
+- term format metadata专注于序号等排版关旭
+  - 默认是txt、html
+  - 争取支持ofd、tex
+
+
+[top](#top) | [index](#index)
+<a id="20240429093000"></a>
+##  9:30~10:59
+日小结时更新season metadata中time.sold字段，汇总waitinglist
+
+### 流程
+
+- 因为已经解决了metadata回写问题，所以不再需要创建todo metadata。
+    - 各任务todo从task metadata集中到season metadata
+- 做计划时，自动从season metadata中按次序选出候选子任务，填入dayplan模版中，显示填充结果而不回写。
+    - 人工调整season metadata，直至每种模版的绑定结果都符合预期。
+- 绑定模版时，一次生成draft metadata、time slice draft markdown、day plan view，直接从season metadata中删除对用todo项。
+    
+- 做日小结时，draft metadata+view -> day blog view
+    - 更新season metadata中time.sold字段。
+    - 更新task.log字段
+
+
+- 实现了finish.updateseason(date)，做日小结时更新season metadata中time.sold字段。执行结果：
+```
+  sold:
+    ego: 1609
+    PSMD: 2938
+    infra: 30
+    js: 199
+    learn: 162
+    xuemen: 60
+    raw: 115
+```
+- 实现了 start.testdayplan: function () ，按当前各任务剩余时间顺序，遍历各任务todo字段，依序把todo项汇总。执行结果：
+```
+resttotal: 8192
+reset:
+ PSMD: 4062
+learn: 838
+ego: 1391
+js: 1176
+xuemen: 540
+raw: 185
+
+resetSOrted:
+ - PSMD
+- ego
+- js
+- learn
+- xuemen
+- raw
+
+waitinglist:
+ '30':
+  - task: js
+    name: async
+  - task: xuemen
+    name: 数字发票试点
+  - task: raw
+    name: debug-灰枣按"个"作为单位被算出很高热量。
+  - task: js
+    name: promise 对象
+  - task: raw
+    name: 设计DRI metadata
+  - task: PSMD
+    name: 生成入门目录涉及的所有view，调整措池准备试用
+  - task: ego
+    name: 整理废弃git库，包括本地和远程。
+  - task: js
+    name: 学习AMD规范，如果适用就开发范例
+  - task: learn
+    name: 学习正则表达式RegExp
+  - task: js
+    name: 在js代码中进行git操作
+  - task: raw
+    name: debug-diff mode较大天数返回空数据，创建三个R文件。
+  - task: PSMD
+    name: PSMD委托合同的metadata
+  - task: js
+    name: 日期格式化
+    readme: |
+      https://www.cnblogs.com/biehongli/p/9327604.html
+      https://juejin.cn/post/7199191689150644279
+      https://blog.csdn.net/lwf3115841/article/details/129105206
+'60':
+  - task: PSMD
+    name: 设计条款内容与排版序号分离的新数据结构，编写metadata范例。
+  - task: ego
+    name: task waitinglist编码
+  - task: learn
+    name: 设计自己的git开发流程
+    readme: >
+      - https://ruanyifeng.com/blog/2015/08/git-use-process.html
+
+      - https://www.ruanyifeng.com/blog/2015/12/git-workflow.html
+
+      - https://www.jianshu.com/p/9801b98c1de4
+
+      -
+      https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
+  - task: ego
+    name: task之间结算体系设计
+  - task: learn
+    name: 把git开发流程编写成批处理文件
+  - task: raw
+    name: 实现自定义DRI的代码
+  - task: PSMD
+    name: 基于term metadata修改COM、deploy、COD等metadata
+  - task: ego
+    name: github + codeberg page 范例
+  - task: learn
+    name: nosql
+  - task: ego
+    name: 在season metadata中实现浮动时间表，修改日计划功能。
+  - task: js
+    name: 向外提供js文件的范例，为代码层级互通做准备
+'90':
+  - task: PSMD
+    name: 基于新的term +termset metadata修改代码commit, generate view
+    readme: |
+      - item字段里可以自由排练text、term，可以自由安排有title、prefix或没有。
+        - title：单独显示，不改变内部序号。通常用做章、附件的开头。
+        - prefix：向下改变所有内部序号，用"."依序连接起来。
+      - item字段里的map增加title、prefix的映射。
+        - 下级title可以在map被替换；
+        - 下级prefix也在map被替换。
+      - interface字段增加title字段，相当于目录。上级不提换就用本地的。
+      - term commit
+      - term metadata -> term view
+  - task: xuemen
+    name: 编写自动分录的代码
+  - task: learn
+    name: 把PSMD的data、src部分升级到rdf，如果升级成功则作为范例。
+'195':
+  - task: xuemen
+    name: xuemen COD metadata
+  - task: PSMD
+    name: term + COM matedata -> deploy metadata -> deploy view
+```
+
+
+
+[top](#top) | [index](#index)
+<a id="20240429140000"></a>
+## 14:00~14:29
+复习git，基于分支重新设计开发流程
+
+- https://ruanyifeng.com/blog/2015/08/git-use-process.html
+- https://www.ruanyifeng.com/blog/2015/12/git-workflow.html
+- https://www.jianshu.com/p/9801b98c1de4
+- https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
+
+
+[top](#top) | [index](#index)
+<a id="20240429143000"></a>
+## 14:30~14:59
+初步熟悉npm、winget发布规则
+
+- https://learn.microsoft.com/zh-cn/windows/package-manager/package/
+- https://docs.npmjs.com/cli/v10/commands/npm-publish
+- https://packager.io/
+- https://gitee.com/repo
+
+已经了解，需要时可以发布。
+
+
+[top](#top) | [index](#index)
+<a id="20240429160000"></a>
+## 16:00~16:59
+测试划分有意识和下意识行为的措辞
+
+- https://www.zhihu.com/question/324451453/answer/3482762994
+- https://www.zhihu.com/question/649573115/answer/3482783271

release/time/d.20240430.md

@@ -0,0 +1,399 @@
+# 20240430
+
+小结  
+
+<a id="top"></a>
+根据[ego模型时间接口](https://gitee.com/hyg/blog/blob/master/timeflow.md)，今天绑定模版1。
+
+| 时间片 | 时长 | 用途 | 手稿 |
+| --- | --- | --- | --- |
+| 04:00~04:14 | 15 | 休整 |  |
+| 04:15~05:14 | 60 | 备餐、运动 |  |
+| 05:15~05:59 | 45 | 早餐 |  |
+| 06:00~06:44 | 45 | 会议、自习 |  |
+| 06:45~07:44 | 60 | 休整 |  |
+| 07:45~08:44 | 60 | 静默工作 | [task waitinglist编码](#20240430074500) |
+| 08:45~09:29 | 45 | 休整 |  |
+| 09:30~10:59 | 90 | 静默工作 | [设计条款内容与排版序号分离的新数据结构，编写metadata范例。](#20240430093000) |
+| 11:00~13:59 | 180 | 备餐、午餐午休 |  |
+| 14:00~14:29 | 30 | 静默工作 | [在js代码中进行git操作](#20240430140000) |
+| 14:30~14:59 | 30 | 静默工作 | [数字发票试点](#20240430143000) |
+| 15:00~15:59 | 60 | 休整 |  |
+| 16:00~16:59 | 60 | 静默工作 | [设计自己的git开发流程](#20240430160000) |
+| 17:00~18:59 | 120 | 晚餐 |  |
+| 19:00~19:59 | 60 | 讨论、整理提交 |  |
+
+模版一采用静默工作方式。  
+希望讨论的提纲发到 [huangyg@mars22.com](mailto:huangyg@mars22.com)，通常安排在后面某天的早餐（5:15~5:59）或会议时间（6:00~6:45）。
+
+
+---
+<a id="index"></a>
+- 07:45	[task waitinglist编码](#20240430074500)  
+- 09:30	[设计条款内容与排版序号分离的新数据结构，编写metadata范例。](#20240430093000)  
+- 14:00	[在js代码中进行git操作](#20240430140000)  
+- 14:30	[数字发票试点](#20240430143000)  
+- 16:00	[设计自己的git开发流程](#20240430160000)  
+
+---
+
+
+[top](#top) | [index](#index)
+<a id="20240430074500"></a>
+## 7:45~8:44
+task waitinglist编码
+
+### 生成waitinglist
+
+- 首先用season.time的alloc字段（已经和time.supply字段和dayplan模版下的supply计算的总数一致）减去sold字段，得出各任务剩余时间。
+- 对剩余时间进行排序，得出各任务优先级。今后还可以有其它优先级算法。
+- 遍历所有模版，读取所有现存的时间片长度。目前是30、60、90、195分钟四种。
+- 按照优先顺序，遍历season.todo字段下各项目，依次读第1个job，然后依次读第2个job，分别按长度排入四种时间长度下的waitinglist。
+
+### 预推计划
+
+- 遍历每一种时间模版dayplan，每个时间片选取waitinglist的第一个，然后这个元素弹出waitinglist数组。
+- 排完一种时间模版之后，重新生成waitinglist，再排下一种时间模版。
+
+### 日计划
+
+- 真实绑定一种时间模版，排期方式和预推时一样。
+- 区别是会删除season.todo下的job。
+- 生成draft的metadata和各时间片的view，以及blog\release\time\下的当天markdown文件。
+
+大部分工作昨晚陆续完成，共计约90分钟。其中70分钟加在昨天9:30时间片，20分钟算在今天。
+
+执行结果：
+```
+D:\huangyg\git\ego\src>node ego day 1
+resttotal: 8192
+reset:
+ PSMD: 4062
+learn: 838
+ego: 1391
+js: 1176
+xuemen: 540
+raw: 185
+
+resetSOrted:
+ - PSMD
+- ego
+- js
+- learn
+- xuemen
+- raw
+
+delete the job from ego:
+task之间结算体系设计
+delete the job from xuemen:
+编写自动分录的代码
+delete the job from js:
+async
+delete the job from raw:
+debug-灰枣按"个"作为单位被算出很高热量。
+delete the job from learn:
+把git开发流程编写成批处理文件
+../data/draft/2024/d.20240430.yaml
+date: 20240430
+plan: 1
+time:
+  - begin: '20240430074500'
+    amount: 60
+    type: work
+    subject: ego
+    name: task之间结算体系设计
+    output: draft/2024/04/20240430074500.md
+  - begin: '20240430093000'
+    amount: 90
+    type: work
+    subject: xuemen
+    name: 编写自动分录的代码
+    output: draft/2024/04/20240430093000.md
+  - begin: '20240430140000'
+    amount: 30
+    type: work
+    subject: js
+    name: async
+    output: draft/2024/04/20240430140000.md
+  - begin: '20240430143000'
+    amount: 30
+    type: work
+    subject: raw
+    name: debug-灰枣按"个"作为单位被算出很高热量。
+    output: draft/2024/04/20240430143000.md
+  - begin: '20240430160000'
+    amount: 60
+    type: work
+    subject: learn
+    name: 把git开发流程编写成批处理文件
+    output: draft/2024/04/20240430160000.md
+
+seasonobj.todo:
+PSMD:
+  - '195': 基于新的term +termset metadata修改代码commit, generate view
+    readme: |
+      - item字段里可以自由排练text、term，可以自由安排有title、prefix或没有。
+        - title：单独显示，不改变内部序号。通常用做章、附件的开头。
+        - prefix：向下改变所有内部序号，用"."依序连接起来。
+      - item字段里的map增加title、prefix的映射。
+        - 下级title可以在map被替换；
+        - 下级prefix也在map被替换。
+      - interface字段增加title字段，相当于目录。上级不提换就用本地的。
+      - term commit
+      - term metadata -> term view
+  - '30': 生成入门目录涉及的所有view，调整措池准备试用
+  - '60': 基于term metadata修改COM、deploy、COD等metadata
+  - '195': term + COM matedata -> deploy metadata -> deploy view
+  - '30': PSMD委托合同的metadata
+ego:
+  - '30': 整理废弃git库，包括本地和远程。
+  - '60': github + codeberg page 范例
+  - '60': 在season metadata中实现浮动时间表，修改日计划功能。
+learn:
+  - '30': 学习正则表达式RegExp
+  - '60': nosql
+  - '90': 把PSMD的data、src部分升级到rdf，如果升级成功则作为范例。
+js:
+  - '30': promise 对象
+  - '30': 学习AMD规范，如果适用就开发范例
+  - '60': 向外提供js文件的范例，为代码层级互通做准备
+  - '30': 日期格式化
+    readme: |
+      https://www.cnblogs.com/biehongli/p/9327604.html
+      https://juejin.cn/post/7199191689150644279
+      https://blog.csdn.net/lwf3115841/article/details/129105206
+raw:
+  - '30': 设计DRI metadata
+  - '60': 实现自定义DRI的代码
+  - '30': debug-diff mode较大天数返回空数据，创建三个R文件。
+xuemen:
+  - '195': xuemen COD metadata
+
+the draft metadata isn't exist:../data/draft/2024/d.20240430.yaml
+```
+
+
+[top](#top) | [index](#index)
+<a id="20240430093000"></a>
+##  9:30~10:59
+设计条款内容与排版序号分离的新数据结构，编写metadata范例。
+
+- 定位：PSMD输出的是三会动议。
+    - 是其他部门和合作方工作的输入文件。比如律师基于三会的决议开始自己的工作、完成后续的法律文件，而不是要求三会输出律师的工作结果。
+    - PSMD输出文件的排版和序号，只是为了避开和机构内部已有文件，以免出现二义性。如果个别机构内部有更严格的版面要求可以由辅助人员整理。直到大面积使用、成为事实标准之后才纳入PSMD需求。
+
+- 只有需要独立使用时，才单独创立。否则可以合在一个文件里。
+    - 但是互相引用应该可以精确定位到某一条款。因此内部编号还是要精确。
+
+### 数据结构
+
+- 增加item字段。
+  - 取消item.path，改由统一的接口从id获得path、obj
+  - 取消item.type，统统都有text、term字段，localid都可以在interface转换成空字符串，实现无序号文字。
+  - 暂时保留upgradeby字段，实际使用后再定。
+- 增加depend、together字段，结合原有的effect字段代替knowledge
+  - 默认是termtoerror，因为没有type，而effect的id也是errorid
+  - 可能有不止一种效果，每种效果的depend、together不同，这时仍需要独立的knowledge
+- interface和map字段都去掉分类，直接排列所有placeholder的映射。
+    - placeholder中添加termid，以示区别。
+
+```
+name:
+id:
+interface:
+  <termid.entity.1>: name
+  <termid.entity.2>: name
+  <termid.asset.1>: name
+  <termid.term.1>: name
+  <termid.event.1>: name
+  <termid.localid.1>: name
+item:
+  - localid:
+      text: |
+      termid: 
+      upgradeby: // localid.localid.....localid
+      map:
+        <termid.entity.1>: <termid.entity.1>
+        <termid.entity.2>: <termid.entity.2>
+        <termid.asset.1>: <termid.asset.1>
+        <termid.term.1>: <termid.term.1>
+        <termid.event.1>: <termid.event.1>
+        <termid.localid.1>: <termid.localid.1>
+readme: |
+depend:
+  errorid:
+    percent:
+    text: | 
+together:
+  errorid:
+    percent:
+    text: |
+effect:
+  errorid:
+    percent:
+    text: |
+```
+
+- PSMD git本地库创建develop_newterm分支。
+- 根据termset.01e1c775 创建新结构的4个term文件：
+
+- term.1.yaml
+```
+name: 调整分配主比例
+id: 1
+interface:
+  <1.entity.1>: deployer
+  <1.entity.2>: director
+  <1.asset.1>: p
+item:
+  - localid: 0
+    termid: 2
+    upgradeby: <1.localid.0>
+    map:
+      <2.entity.1>: <1.entity.1>
+  - localid: 1
+    termid: 3
+    upgradeby: <1.localid.0>
+    map:
+      <3.asset.1>: <1.asset.1>
+  - localid: 2
+    termid: 4
+    upgradeby: <1.localid.0>
+    map:
+      <4.entity.1>: <1.entity.2>
+readme: |
+depend:
+  errorid:
+    percent:
+    text: | 
+together:
+  errorid:
+    percent:
+    text: |
+effect:
+  errorid:
+    percent:
+    text: |
+```
+
+- term.2.yaml
+```
+name: 自修订条款
+id: 2
+interface:
+  <2.entity.1>: deployer
+item:
+  - localid: 0
+    text: |
+      由<2.entity.1>书面提交即生效。
+readme: |
+effect: |
+```
+
+- term.3.yaml
+```
+name: 利益分配比例
+id: 3
+interface:
+  <3.asset.1>: p
+item:
+  - localid: 0
+    text: |
+      <3.asset.1>=20，<3.asset.1>%=20%。
+readme: |
+effect: |
+```
+
+- term.4.yaml
+```
+name: 集体决策
+id: 4
+interface:
+  <4.entity.1>: director
+item:
+  - localid: 0
+    text: |
+      由<4.entity.1>表决按一人一票表决，超过80%出席会议有效，赞成票超过超过三分之二为通过。
+readme: |
+effect: |
+```
+
+[top](#top) | [index](#index)
+<a id="20240430140000"></a>
+## 14:00~14:29
+在js代码中进行git操作
+
+- https://juejin.cn/post/7310554208230850623
+    - isomorphic-git 是一个纯 JavaScript 的库，提供了跨浏览器和 Node.js 环境使用的 Git 功能: https://isomorphic-git.org/
+    - dugite 是一个execFile原理实现git绑定的js库: https://github.com/desktop/dugite
+- https://geek-docs.com/git/git-questions/103_git_git_commands_in_nodejs.html  
+    - 使用 child_process 模块来执行 Shell 命令
+
+
+- 一个命令推送到所有远端: https://blog.walterlv.com/post/git-push-to-all-remotes.html
+
+[top](#top) | [index](#index)
+<a id="20240430143000"></a>
+## 14:30~14:59
+数字发票试点
+
+- 短信通知：
+```
+【百旺服务】 尊敬的纳税人：您已经是数电发票试点纳税人，请及时联系我们一键迁移历史发票数据，完成系统升级工作。客服热线：010-59201188
+温馨提示：由于400-611-2366线路改造，税控盘、税务Ukey、金税盘、数电发票咨询服务热线变更为：010-59201188，有问题请及时与我们联系。感谢您的配合！拒收请回复R
+```
+
+- 航天金穗 https://www.htjs.net 税控盘专线：400-611-2366
+
+
+- 百旺金赋 http://www.ibwjf.com/ 咨询服务
+```
+ 您好，接到短信自称是百旺，说服务热线400-611-2366改为010-59201188。确认一下是百旺的通知吗。
+
+百旺聂冀 14:38:57
+这个不是我们的通知
+
+百旺聂冀 14:39:10
+我们的客服电话是85398677
+
+14:39:50
+可能是百旺的内部部门吗。还是确定是外部的假冒信息。
+
+百旺聂冀 14:40:44
+这个是之前的承包商 不是我们北京百旺金赋
+
+14:41:26
+ok，那我不管他们的通知了。
+
+百旺聂冀 14:41:56
+嗯
+```
+- 安装百旺金赋的云票助手和帮助文档，五月份试用一下。
+    - http://www.ibwjf.com/dataDownload/0
+    - http://www.ibwjf.com/classRooms/1
+
+
+[top](#top) | [index](#index)
+<a id="20240430160000"></a>
+## 16:00~16:59
+设计自己的git开发流程
+
+
+1. ego、raw项目在笔记本运行master分支，主要开发版本在台式机开发，其它开发版本在笔记本。
+1. ego、raw以外的项目在台式机运行master项目，主要开发版本在笔记本开发，其它开发版本在台式机。
+1. 其它分支命名和用途：
+    - develop: 开发分支。
+    - feature-name: 功能分支
+    - release-version: 发布分支
+    - bugfix-name: bug修复分支
+1. 人工编辑的文档库使用代码库相同的方式管理。
+1. 自动生成的文档库，代码分支有完整的数据、代码、文档，在此基础上创建纯文档分支，由代码分支cherry-pick过去。 代码分支不编辑文件，只做tag和archive（release）。
+    - 每份委托合同创建纯文档分支
+1. 远程库：
+    - github: master分支
+    - codeberg: 文档分支为主
+    - gitee: 所有分支
+    - coding: 部分项目的所有分支
+1. tag命名和用途：
+    - 代码分支：版本号
+    - 文档分支：决议号

release/time/d.20240501.md

@@ -0,0 +1,255 @@
+# 2024.05.01.
+日小结  
+
+<a id="top"></a>
+根据[ego模型时间接口](https://gitee.com/hyg/blog/blob/master/timeflow.md)，今天绑定模版2。
+
+| 时间片 | 时长 | 用途 | 手稿 |
+| --- | --- | --- | --- |
+| 04:00~04:14 | 15 | 休整 |  |
+| 04:15~05:14 | 60 | 备餐、运动 |  |
+| 05:15~05:59 | 45 | 早餐 |  |
+| 06:00~06:44 | 45 | 会议、自习 |  |
+| 06:45~07:44 | 60 | 休整 |  |
+| 07:45~10:59 | 195 | 工作 | [基于新的term +termset metadata修改代码commit, generate view](#20240501074500) |
+| 11:00~13:59 | 180 | 备餐、午餐午休 |  |
+| 14:00~15:29 | 90 | 工作 | [编写自动分录的代码](#20240501140000) |
+| 15:30~15:59 | 30 | 休整 |  |
+| 16:00~16:59 | 60 | 工作 | [复习个人模型](#20240501160000) |
+| 17:00~18:59 | 120 | 晚餐 |  |
+| 19:00~19:59 | 60 | 讨论、整理提交 |  |
+
+工作的同时可以在线讨论。
+
+---
+
+<a id="index"></a>
+- 07:45	[基于新的term +termset metadata修改代码commit, generate view](#20240501074500)  
+- 14:00	[编写自动分录的代码](#20240501140000)  
+- 16:00	[复习个人模型](#20240501160000)  
+
+
+---
+
+[top](#top) | [index](#index)
+<a id="20240501074500"></a>
+## 7:45~10:59
+基于新的term +termset metadata修改代码commit, generate view
+
+      - item字段里可以自由排练text、term.
+        - 无localid，或者localid为""的text，就是title，通常用做章、附件的开头。最好是含有placeholder。
+        - localid同时作为prefix：向下改变所有内部序号，用"."依序连接起来。
+      - 实际检验一下localid机制是否能实现prefix功能，或者需要单独设一个字段。
+      - term commit
+      - term metadata -> term txt
+    
+
+### commit()
+
+- 调整昨天范例中的localid
+  - term.1的顺延1；
+  - term.2\3\4的改为空字符串，看后面使用再定。
+- 增加effect字段内容供测试用。
+  - depend、togetther、effect字段可能要增加map字段。
+- 为了避免二义性，在placeholder中加入类型term、error等前缀。
+
+term.1.yaml替换为term.01e1c775.yaml
+```
+name: 调整分配主比例
+id: 01e1c775
+interface:
+  <term.01e1c775.entity.1>: deployer
+  <term.01e1c775.entity.2>: director
+  <term.01e1c775.entity.3>: 共同体
+  <term.01e1c775.asset.1>: p
+item:
+  - localid: '1'
+    termid: 23f76740
+    upgradeby: <term.01e1c775.localid.1>
+    map:
+      <term.23f76740.entity.1>: <term.01e1c775.entity.1>
+  - localid: '2'
+    termid: bafdd0aa
+    upgradeby: <term.01e1c775.localid.1>
+    map:
+      <term.bafdd0aa.asset.1>: <term.01e1c775.asset.1>
+  - localid: '3'
+    termid: 988ea839
+    upgradeby: <term.01e1c775.localid.1>
+    map:
+      <term.988ea839.entity.1>: <term.01e1c775.entity.2>
+readme: |
+  本条款是模型1609利益分配的核心条款。
+depend:
+  - errorid: 'null'
+    percent: 'null'
+    text: ''
+together:
+  - errorid: 'null'
+    percent: 'null'
+    text: ''
+effect:
+  - errorid: 48291d8c
+    percent: '50'
+    map:
+      <error.48291d8c.entity.1>: <term.01e1c775.entity.3>
+    text: |
+      1609模型可以有效分配未来收入，本条款是其中一部分。
+```
+
+term.2.yaml替换为term.23f76740.yaml
+```
+name: 自修订条款
+id: 23f76740
+interface:
+  <term.23f76740.entity.1>: deployer
+item:
+  - localid: ''
+    text: |
+      由<term.23f76740.entity.1>书面提交即生效。
+readme: |
+  自修订条款是权力分配中的顶级条款。
+effect: ''
+```
+
+### maketermview() maketermtext()
+
+- 为调试给term metadata加上readme。
+
+执行结果：
+```
+D:\huangyg\git\PSMD\src>node term term 01e1c775
+../view/term.01e1c775.md文件更新，内容如下:
+条款 01e1c775 正文:
+1. 由deployer书面提交即生效。
+2. p=20，p%=20%。
+3. 由director表决按一人一票表决，超过80%出席会议有效，赞成票超过超过三分之二为通过。
+
+---
+条款 01e1c775 readme:
+本条款是模型1609利益分配的核心条款。
+1. 自修订条款是权力分配中的顶级条款。
+2. 本条款设置了参数p的初始值。
+3. 本条款是权力分配中的二级条款。
+```
+
+---
+
+[top](#top) | [index](#index)
+<a id="20240501140000"></a>
+## 14:00~15:29
+编写自动分录的代码
+
+- 复习：D:\huangyg\git\draft\2024\04\20240427160000.md
+- 建立本地S2分支，把master的S2文件夹内容复制过来，冲突的先覆盖了。
+- 创建data、src、view文件夹，在src下建立xuemen.js，分录模式暂定命令行：node xuemen entry。把AVR根据AEC生成AER：
+    - 会计凭证	Accounting Voucher Record	AVR
+    - 会计分录规则	Accounting Entry Code	AEC
+    - 会计分录记录	Accounting Entry Record	AER
+
+
+AVR
+```
+date: 
+title: 
+VoucherID: 
+VoucherType:
+summary:
+amount:
+item:
+  - name:
+    data:
+  - name:
+    data:
+rawdata:
+  '0': 批次号：
+  '1': ...
+```
+
+AEC
+```
+CodeID:
+VoucherType: 利息回单
+code:
+  path:
+  hash:
+map:
+- AVRitem: amount
+  AERitem: 
+- AVRitem:
+  AERitem:
+
+AVR字段和AER字段映射
+```
+
+AER
+```
+date: 
+VoucherID: 
+AccountingSoftwareID: 
+AccountingEntry: 
+  - debit: 
+    - AccountTitle: 
+      amount: 
+    credit: 
+    - AccountTitle: 
+      amount: 
+    - AccountTitle: 
+      amount: 
+```
+
+- 创建entry.js作为所有会计分录的入口，它根据会计凭证的种类VoucherType查找不同的AEC文件，然后根据AEC文件的code.path字段调用不同代码。再建立配套的文件：
+    - xuemen\data\AEC.利息回单.1.yaml
+    - xuemen\src\AEC.1.js
+
+执行结果：
+```
+D:\huangyg\git\xuemen\src>node xuemen entry ..\..\xuemen.record\ISU2019.AVR.1.yaml
+test.AER.nnn.yaml 文件已保存。内容如下:
+ date: 2019-03-21T00:00:00.000Z
+VoucherID: 190000468462
+AccountingSoftwareID: 18010001
+AccountingEntry:
+  debit:
+    - AccountTitle: 银行存款-交通银行
+      amount: 2.25
+    - AccountTitle: 财务费用-利息费用
+      amount: -2.25
+```
+
+### 升级设想
+
+- AEC改成js文件，便于xuemen.js调用。
+    - getcodepath(VoucherType)  // 利息回单->AER.1.js
+- 会计科目要建立基础metadata文件。现在暂时直接赋值。
+- AER模版（D:\huangyg\git\xuemen\S2\AER.Template.yaml）中的AccountingEntry.debit字段应该去掉前面的“-”号，不是数组而是对象。
+
+
+---
+
+[top](#top) | [index](#index)
+<a id="20240501160000"></a>
+## 16:00~16:59
+复习个人模型
+
+- 复习旧版本：
+    - D:\huangyg\git\ego\ego.com.md
+    - D:\huangyg\git\ego\club.com.md
+    - D:\huangyg\git\ego\cod.md
+    - D:\huangyg\git\ego\README.note.md
+- 通用模型支持建模，俱乐部模型支持（同层次的建模者、部署者）个人交流，ego是支持建模和交流。内置了（经过配置的）俱乐部cod的俱乐部成员个人模型。
+
+- 新设想集中在这些定义：
+    - 不再以p1、p2、ia定义资源池，而是容器模型的章程条款为定义。
+    - 每种章程设立的账号发行自己的token，在资源紧缺压力下的交易产生汇率，按一定汇率规则可以共同发行联合token。按默认规则由所有token联合发行的，统一命名为joint token。
+    - 继续沿用共同体层次、行为层次、契约层次的定义，作为joint token默认规则的一部分，无交易时的情形。
+    - 除了对外契约，对内认知也会拉开层次，也作为默认规则的一部分。对内认知的成果与对外契约、容器账号建立映射关系。
+
+### task之间结算体系，重新插入到ego的todo队列中。在整理近年手稿之后重新设计个人模型：  
+- 通过具体结算传递内部资源压力，产生工作成果的内部成本。
+- 工作成果的价格要从对外交易中产生。
+- 个人模型的结构要准确反映长期的层次关系，使工作成果的成本价格差沿着这些关系向高层次和深层次两个方向合理分配。这些关系所转化成的规则应该：
+    - 在每个局部应该是直观的、符合常识的。
+    - 在局部-整体的关系上，也是直观的，符合常识的。
+    - 根据上两条汇总出量化的结果，作为资源分配的依据。
+- 结算体系再二季度完成修订，在三季度试运行，2025年正式发布。

release/time/d.20240502.md

@@ -0,0 +1,630 @@
+# 2024.05.02.
+日小结  
+
+<a id="top"></a>
+根据[ego模型时间接口](https://gitee.com/hyg/blog/blob/master/timeflow.md)，今天绑定模版1。
+
+
+
+<a id="index"></a>
+- 07:45	[error,knowledge metadata的placeholder升级](#20240502074500)  
+- 09:30	[term metadata -> term html](#20240502093000)  
+- 14:00	[把waitinglist前几名和次日可能的模版绑定结果写入日小结。](#20240502140000)  
+- 14:30	[测试](#20240502143000)  
+- 16:00	[日小结后的git操作编写成批处理文件](#20240502160000)  
+
+---
+season stat:
+
+| task | alloc | sold | hold |
+| --- | --- | --- | --- |
+| total | 13275 | 5445 | 7830 |
+| PSMD | 7000 | 3028 | 3972 |
+| learn | 1000 | 222 | 778 |
+| ego | 3000 | 1731 | 1269 |
+| js | 1375 | 229 | 1146 |
+| xuemen | 600 | 90 | 510 |
+| raw | 300 | 115 | 185 |
+| infra | 0 | 30 | -30 |
+
+---
+
+waiting list:
+
+
+- 30分钟时间片：
+  - ego的第1号事项：整理废弃git库，包括本地和远程。
+  - learn的第1号事项：学习正则表达式RegExp
+  - raw的第1号事项：debug-灰枣按"个"作为单位被算出很高热量。
+  - ego的第2号事项：makedayplan()创建draft文件夹，合并makedayplan和makedaydraft。
+
+- 60分钟时间片：
+  - PSMD的第1号事项：term metadata的upgradeby,depend,together,effect等字段的内容写入term view
+  - js的第1号事项：Jade Language生成html view
+  - xuemen的第1号事项：五月报税
+  - js的第2号事项：学习测试方法和工具
+
+- 90分钟时间片：
+  - PSMD的第2号事项：自动把旧格式转化为新格式：
+  - learn的第3号事项：把PSMD的data、src部分升级到rdf，如果升级成功则作为范例。
+  - PSMD的第7号事项：整理近期手稿。
+
+- 195分钟时间片：
+  - xuemen的第2号事项：xuemen COD metadata
+  - PSMD的第5号事项：term + COM matedata -> deploy metadata -> deploy view
+  - ego的第5号事项：在整理近期手稿之后，修订个人模型。
+
+---
+
+[top](#top) | [index](#index)
+<a id="20240502074500"></a>
+## 7:45~8:44
+error,knowledge metadata的placeholder升级
+
+- 新error metadata结构：
+```
+name:
+id:
+interface:
+  <error.termid.entity.1>: value
+  <error.termid.entity.2>: value
+  <error.termid.asset.1>: value
+  <error.termid.term.1>: value
+  <error.termid.event.1>: value
+  <error.termid.localid.1>: value
+text: |
+readme: |
+```
+
+### commit
+
+编辑两个临时error metadata文件（仅供测试用）：  
+- error.1.yaml
+```
+name: 执行部门陷入割据
+id: 1
+interface:
+  <error.1.term.1>: 资源不足
+  <error.1.entity.1>: 共同体
+  <error.1.entity.2>: 下达指令者
+  <error.1.entity.3>: 决策部门
+  <error.1.entity.4>: 执行部门
+  <error.1.asset.1>: 工单
+  <error.1.asset.2): 日志
+text: |
+  出现以下情况之一：
+  - <error.1.entity.3>未界定<error.1.entity.4>工作的合规性要求。
+  - <error.1.entity.3>界定了<error.1.entity.4>工作的合规性要求。
+    - <error.1.entity.4>成员对指令不进行合规检查，即使不合规也执行。
+    - <error.1.entity.4>成员及下达指令者未按要求填写和提交表单，比如<error.1.asset.1>、<error.1.asset.2>。
+readme: |
+  - <error.1.entity.2>的指令包括对更早指令的掩盖，通过互相包庇产生系统性的对抗。
+  - <error.1.entity.1>曾经对<error.1.entity.2>违约，以一定范围内的割据作为抵押物。这是历史上资源紧缺，无法兑现约定报酬的后遗症。
+  - 把一定范围内的割据作为违约抵押物的情况，解除割据应该同时处理历史欠账。在<error.1.entity.1>设立阶段，就要确定是否符合<error.1.term.1>，如果符合应该在设立时解决。
+```
+
+- error.2.yaml
+```
+name: 无法有效分配未来收入
+id: 2
+interface:
+  <error.2.entity.1>: 共同体
+text: |
+  <error.2.entity.1>涉及未来收入的承诺，无法保证兑现。因此，无法使用未来收入换取当下资源，只能以现有资源进行交易。
+readme: |
+  可能的原因包括：
+    - <error.2.entity.1>内部废除该承诺，可能成为有效力的决议；
+    - <error.2.entity.1>内部对同一笔未来收入安排其它用途，可能成为有效力的预算案。
+```
+
+- 在git分支develop-newterm中修改commit()关于error的代码，执行结果：
+```
+D:\huangyg\git\PSMD\src>node term commit
+commit error.1.yaml
+执行部门陷入割据 0ccddb29
+commit error.2.yaml
+无法有效分配未来收入 48291d8c
+commit knowledge.1.yaml
+1406解决割据问题 3b7582cd
+commit knowledge.2.yaml
+1609解决资源问题 d8a0602f
+commit term.1.yaml
+调整分配主比例 01e1c775
+commit term.2.yaml
+自修订条款 23f76740
+commit term.3.yaml
+利益分配比例 bafdd0aa
+commit term.4.yaml
+集体决策 988ea839
+../data/term.01e1c775.yaml文件已更新。../data/term.1.yaml可以删除。
+../data/term.23f76740.yaml文件已更新。../data/term.2.yaml可以删除。
+../data/term.bafdd0aa.yaml文件已更新。../data/term.3.yaml可以删除。
+../data/term.988ea839.yaml文件已更新。../data/term.4.yaml可以删除。
+before replace the error:
+1 name: 执行部门陷入割据
+id: '1'
+interface:
+  <error.1.term.1>: 资源不足
+  <error.1.entity.1>: 共同体
+  <error.1.entity.2>: 下达指令者
+  <error.1.entity.3>: 决策部门
+  <error.1.entity.4>: 执行部门
+  <error.1.asset.1>: 工单
+  <error.1.asset.2): 日志
+text: |
+  出现以下情况之一：
+  - <error.1.entity.3>未界定<error.1.entity.4>工作的合规性要求。
+  - <error.1.entity.3>界定了<error.1.entity.4>工作的合规性要求。
+    - <error.1.entity.4>成员对指令不进行合规检查，即使不合规也执行。
+    - <error.1.entity.4>成员及下达指令者未按要求填写和提交表单，比如<error.1.asset.1>、<error.1.asset.2>。
+readme: |
+  - <error.1.entity.2>的指令包括对更早指令的掩盖，通过互相包庇产生系统性的对抗。
+  - <error.1.entity.1>曾经对<error.1.entity.2>违约，以一定范围内的割据作为抵押物。这是历史上资源紧缺，无法兑现约定报酬的后遗症。
+  - 把一定范围内的割据作为违约抵押物的情况，解除割据应该同时处理历史欠账。在<error.1.entity.1>设立阶段，就要确定是否符合<error.1.term.1>，如果符合应该在设立时解决。
+
+after replace the error:
+1 name: 执行部门陷入割据
+id: 0ccddb29
+interface:
+  <error.0ccddb29.term.1>: 资源不足
+  <error.0ccddb29.entity.1>: 共同体
+  <error.0ccddb29.entity.2>: 下达指令者
+  <error.0ccddb29.entity.3>: 决策部门
+  <error.0ccddb29.entity.4>: 执行部门
+  <error.0ccddb29.asset.1>: 工单
+  <error.0ccddb29.asset.2): 日志
+text: |
+  出现以下情况之一：
+  - <error.0ccddb29.entity.3>未界定<error.0ccddb29.entity.4>工作的合规性要求。
+  - <error.0ccddb29.entity.3>界定了<error.0ccddb29.entity.4>工作的合规性要求。
+    - <error.0ccddb29.entity.4>成员对指令不进行合规检查，即使不合规也执行。
+    - <error.0ccddb29.entity.4>成员及下达指令者未按要求填写和提交表单，比如<error.0ccddb29.asset.1>、<error.0ccddb29.asset.2>。
+readme: |
+  - <error.0ccddb29.entity.2>的指令包括对更早指令的掩盖，通过互相包庇产生系统性的对抗。
+  - <error.0ccddb29.entity.1>曾经对<error.0ccddb29.entity.2>违约，以一定范围内的割据作为抵押物。这是历史上资源紧缺，无法兑现约定报酬的后遗症。
+  - 把一定范围内的割据作为违约抵押物的情况，解除割据应该同时处理历史欠账。在<error.0ccddb29.entity.1>设立阶段，就要确定是否符合<error.0ccddb29.term.1>，如果符合应该在设立时解决。
+
+../data/error.0ccddb29.yaml文件已更新。../data/error.1.yaml可以删除。
+before replace the error:
+2 name: 无法有效分配未来收入
+id: '2'
+interface:
+  <error.2.entity.1>: 共同体
+text: |
+  <error.2.entity.1>涉及未来收入的承诺，无法保证兑现。因此，无法使用未来收入换取当下资源，只能以现有资源进行交易。
+readme: |
+  可能的原因包括：
+    - <error.2.entity.1>内部废除该承诺，可能成为有效力的决议；
+    - <error.2.entity.1>内部对同一笔未来收入安排其它用途，可能成为有效力的预算案。
+
+after replace the error:
+2 name: 无法有效分配未来收入
+id: 48291d8c
+interface:
+  <error.48291d8c.entity.1>: 共同体
+text: |
+  <error.48291d8c.entity.1>涉及未来收入的承诺，无法保证兑现。因此，无法使用未来收入换取当下资源，只能以现有资源进行交易。
+readme: |
+  可能的原因包括：
+    - <error.48291d8c.entity.1>内部废除该承诺，可能成为有效力的决议；
+    - <error.48291d8c.entity.1>内部对同一笔未来收入安排其它用途，可能成为有效力的预算案。
+
+../data/error.48291d8c.yaml文件已更新。../data/error.2.yaml可以删除。
+```
+
+-  knowledge metadata中没有placeholder，所以不用更改。只是删除了termset部分代码。所有种类commit的综合执行结果：
+```
+D:\huangyg\git\PSMD\src>node term commit
+commit error.1.yaml
+执行部门陷入割据 0ccddb29
+commit error.2.yaml
+无法有效分配未来收入 48291d8c
+commit knowledge.1.yaml
+1406解决割据问题 3b7582cd
+commit knowledge.2.yaml
+1609解决资源问题 d8a0602f
+commit term.1.yaml
+调整分配主比例 01e1c775
+commit term.2.yaml
+自修订条款 23f76740
+commit term.3.yaml
+利益分配比例 bafdd0aa
+commit term.4.yaml
+集体决策 988ea839
+../data/term.01e1c775.yaml文件已更新。../data/term.1.yaml可以删除。
+../data/term.23f76740.yaml文件已更新。../data/term.2.yaml可以删除。
+../data/term.bafdd0aa.yaml文件已更新。../data/term.3.yaml可以删除。
+../data/term.988ea839.yaml文件已更新。../data/term.4.yaml可以删除。
+../data/error.0ccddb29.yaml文件已更新。../data/error.1.yaml可以删除。
+../data/error.48291d8c.yaml文件已更新。../data/error.2.yaml可以删除。
+knowledge depend replace. error:2 -> 48291d8c
+../data/knowledge.3b7582cd.yaml文件已更新。../data/knowledge.1.yaml可以删除。
+旧文件:../data/knowledge.2.yaml中depend字段的id: cde3c3e2 未能替换，请人工检查。
+旧文件:../data/knowledge.2.yaml中objid: 5b4e0597 未能替换，请人工检查。
+knowledge effect replace. id:2 -> 48291d8c
+../data/knowledge.d8a0602f.yaml文件已更新。../data/knowledge.2.yaml可以删除。
+```
+涉及error.2的term.1中effect字段也正确：
+```
+effect:
+  - errorid: 2
+    percent: 50
+    map:
+      <error.2.entity.1>: <term.1.entity.3>
+    text: |
+      1609模型可以有效分配未来收入，本条款是其中一部分。
+```
+term.01e1c775:
+```
+effect:
+  - errorid: 48291d8c
+    percent: '50'
+    map:
+      <error.48291d8c.entity.1>: <term.01e1c775.entity.3>
+    text: |
+      1609模型可以有效分配未来收入，本条款是其中一部分。
+```
+
+### metadata -> view
+
+- 修改 makeerrorview() makeerrortext() makeerrornet()
+- 由于范例knowledge.type字段是termsettoerror，所以effect字段也暂时不处理，error.0ccddb29目前无解：
+```
+
+D:\huangyg\git\PSMD\src>node term error 0ccddb29
+../view/error.0ccddb29.md文件更新，内容如下:
+问题 0ccddb29 正文:
+出现以下情况之一：
+- 决策部门未界定执行部门工作的合规性要求。
+- 决策部门界定了执行部门工作的合规性要求。
+  - 执行部门成员对指令不进行合规检查，即使不合规也执行。
+  - 执行部门成员及下达指令者未按要求填写和提交表单，比如工单、日志。
+
+---
+问题 0ccddb29 readme:
+- 下达指令者的指令包括对更早指令的掩盖，通过互相包庇产生系统性的对抗。
+- 共同体曾经对下达指令者违约，以一定范围内的割据作为抵押物。这是历史上资源紧缺，无法兑现约定报酬的后遗症。
+- 把一定范围内的割据作为违约抵押物的情况，解除割据应该同时处理历史欠账。在共同体设立阶段，就要确定是否符合资源不足，如果符合应该在设立时解决。
+
+---
+解决建议:
+出现偏差的部门内部互相确认:相关职务行为是有意识还是无意识的。
+  - 无意识的行为：应暂时停职，由相关成员自行纠偏，然后根据情况复职或者重新竞聘。
+  - 有意识的行为：可以基于理性人假设，从行为偏差分析规章偏差，根据情况产生工单。如需进一步建议请联系<huang@mars22.com>
+---
+```
+- 而error. 48291d8c可以正确生成view：
+```
+
+D:\huangyg\git\PSMD\src>node term error 48291d8c
+    - 48291d8c>发现knowledge d8a0602f :使用term [5b4e0597](../view/term.5b4e0597.md) 可能解决 error 48291d8c 预估有效的比例是 60%
+    - 48291d8c>使用knowledge d8a0602f 需要先解决error:
+    - 48291d8c>[cde3c3e2](../view/error.cde3c3e2.md)
+../view/error.48291d8c.md文件更新，内容如下:
+问题 48291d8c 正文:
+共同体涉及未来收入的承诺，无法保证兑现。因此，无法使用未来收入换取当下资源，只能以现有资源进行交易。
+
+---
+问题 48291d8c readme:
+可能的原因包括：
+  - 共同体内部废除该承诺，可能成为有效力的决议；
+  - 共同体内部对同一笔未来收入安排其它用途，可能成为有效力的预算案。
+
+---
+解决建议:
+出现偏差的部门内部互相确认:相关职务行为是有意识还是无意识的。
+  - 无意识的行为：应暂时停职，由相关成员自行纠偏，然后根据情况复职或者重新竞聘。
+  - 有意识的行为：可以基于理性人假设，从行为偏差分析规章偏差，根据情况产生工单。可以参考以下内容：
+    - 48291d8c>发现knowledge d8a0602f :使用term [5b4e0597](../view/term.5b4e0597.md) 可能解决 error 48291d8c 预估有效的比例是 60%
+    - 48291d8c>使用knowledge d8a0602f 需要先解决error:[cde3c3e2](../view/error.cde3c3e2.md)
+
+---
+```
+
+新增todo：
+    - '90': 自动把旧格式转化为新格式：
+      readme: |
+        - old term metadata -> new term metadata
+        - old termset metadata -> new term metadata
+
+---
+
+[top](#top) | [index](#index)
+<a id="20240502093000"></a>
+##  9:30~10:59
+term metadata -> term html
+
+- markdown版本已经实现了同网站跳转功能，因此不需要再开发同样内容的html。
+- html的优势是互动：
+    - 弹出提示
+    - 弹出选择窗口：根据选择跳转
+- 顺便设计新的展示方式：根据受众的记忆、理解能力，每个页面展示局部知识，各局部之间的联系保持简洁直观，避免信息量超过负荷能力。
+
+
+### 需求
+
+- 类似旧的[termset.9d12877c.md](https://codeberg.org/hyg/PSMD/src/commit/659b6e191ef9766f976dcbbe2cbe5fcd6697b7b2/view/termset.9d12877c.md) 这样的多种选择，可以每一步选择生成html页面，引导用户进入针对性内容。
+- 每一步选择都有之前选择的声明，防止断章取义。
+- 先使用目前term metadata的depend、together字段表达这种关系。
+
+### 工具
+
+- Jade： https://jade-lang.com
+- EJS：https://ejs.bootcss.com/
+- swig：http://node-swig.github.io/swig-templates/
+
+使用都很简单。
+
+### 设计
+
+- 需要统一的view metadata，然后分别生成text、markdown、html乃至ofd、tex。
+```
+name:
+id:
+template:
+  txt:
+  markdown:
+  html:
+  ofd:
+  tex:
+data:
+  content:
+  email:
+  alert: text
+  confirm:
+    text:
+    yes: path or null
+    no: path or null
+  prompt:
+    text:
+    defaul:
+    pass: 
+    fault: path 
+```
+- 怎么实现不确定的层次内容。
+
+使用ejs做了简单的maketermhtml()，执行结果：
+```
+D:\huangyg\git\PSMD\src>node term term 01e1c775
+../view/term.01e1c775.md文件更新，内容如下:
+条款 01e1c775 正文:
+1. 由deployer书面提交即生效。
+2. p=20，p%=20%。
+3. 由director表决按一人一票表决，超过80%出席会议有效，赞成票超过超过三分之二为通过。
+
+---
+条款 01e1c775 readme:
+本条款是模型1609利益分配的核心条款。
+1. 自修订条款是权力分配中的顶级条款。
+2. 本条款设置了参数p的初始值。
+3. 本条款是权力分配中的二级条款。
+
+../view/term.01e1c775.html文件更新，内容如下:
+<!DOCTYPE html>
+<html lang="zh-cn">
+
+<head>
+    <meta charset="UTF-8">
+    <script>
+
+
+
+    </script>
+</head>
+
+<body>
+    <hr />
+    <h3>条款01e1c775</h3>
+    <br />
+    <hr />
+    正文:
+    <br />
+    1. 由deployer书面提交即生效。<br/>
+2. p=20，p%=20%。<br/>
+3. 由director表决按一人一票表决，超过80%出席会议有效，赞成票超过超过三分之二为通过。<br/>
+
+    <br />
+    <hr />
+
+    readme:
+    <br />
+    本条款是模型1609利益分配的核心条款。<br/>
+1. 自修订条款是权力分配中的顶级条款。<br/>
+2. 本条款设置了参数p的初始值。<br/>
+3. 本条款是权力分配中的二级条款。<br/>
+
+    <hr />
+
+</body>
+
+</html>
+```
+
+在js task下添加学习jade的todo job：- '60': Jade Language生成html view
+
+---
+
+[top](#top) | [index](#index)
+<a id="20240502140000"></a>
+## 14:00~14:29
+把waitinglist前几名和次日可能的模版绑定结果写入日小结。
+
+- 日小结去掉当天时间表
+- 列出这几项数据：
+    - 本季度各项目分配时间、已使用时间，剩余时间
+    - 各种时间片前四名的todo项
+
+执行结果：
+```
+D:\huangyg\git\ego\src>node ego day over
+../data/season/2024S2.yaml文件中的time.sold字段已更新:
+ego: 1731
+PSMD: 3028
+infra: 30
+js: 229
+learn: 222
+xuemen: 90
+raw: 115
+
+seasonpath:../data/season/2024S2.yaml
+resttotal: 7860
+rest:
+PSMD: 3972
+learn: 778
+ego: 1269
+js: 1146
+xuemen: 510
+raw: 185
+
+resetSOrted:
+- PSMD
+- ego
+- js
+- learn
+- xuemen
+- raw
+
+daylog file name:
+../../blog/release/time/d.20240502.md
+content:
+# 2024.05.02.
+日小结
+
+<a id="top"></a>
+根据[ego模型时间接口](https://gitee.com/hyg/blog/blob/master/timeflow.md)，今天绑定模版1。
+
+
+
+<a id="index"></a>
+- 07:45 [error,knowledge metadata的placeholder升级](#20240502074500)
+- 09:30 [term metadata -> term html](#20240502093000)
+- 14:00 [把waitinglist前几名和次日可能的模版绑定结果写入日小结。](#20240502140000)
+- 14:30 [测试](#20240502143000)
+- 16:00 [把git开发流程编写成批处理文件](#20240502160000)
+
+---
+season stat:
+| task | alloc | sold | rest |
+| --- | --- | --- | --- |
+| PSMD | 7000 | 3028 | 3972 |
+| learn | 1000 | 222 | 778 |
+| ego | 3000 | 1731 | 1269 |
+| js | 1375 | 229 | 1146 |
+| xuemen | 600 | 90 | 510 |
+| raw | 300 | 115 | 185 |
+| infra | 0 | 30 | -30 |
+
+---
+
+waiting list:
+
+30分钟时间片：
+- ego的第1号事项：整理废弃git库，包括本地和远程。
+- learn的第1号事项：学习正则表达式RegExp
+- raw的第1号事项：debug-灰枣按"个"作为单位被算出很高热量。
+- ego的第2号事项：makedayplan()创建draft文件夹，合并makedayplan和makedaydraft。
+
+60分钟时间片：
+- PSMD的第1号事项：term metadata的upgradeby,depend,together,effect等字段的内容写入term view
+- js的第1号事项：Jade Language生成html view
+- xuemen的第1号事项：五月报税
+- learn的第2号事项：nosql
+
+90分钟时间片：
+- PSMD的第2号事项：自动把旧格式转化为新格式：
+- learn的第3号事项：把PSMD的data、src部分升级到rdf，如果升级成功则作为范例。
+- PSMD的第7号事项：整理近期手稿。
+
+195分钟时间片：
+- xuemen的第2号事项：xuemen COD metadata
+- PSMD的第5号事项：term + COM matedata -> deploy metadata -> deploy view
+- ego的第5号事项：在整理近期手稿之后，修订个人模型。
+
+---
+
+[top](#top) | [index](#index)
+<a id="20240502074500"></a>
+## 07:45 ~ 08:45
+......
+```
+
+---
+
+[top](#top) | [index](#index)
+<a id="20240502143000"></a>
+## 14:30~14:59
+测试
+
+上个时间片waitinglist任务占用时间。原定测试学习任务加回season.todo字段，并增加到60分钟。
+---
+
+[top](#top) | [index](#index)
+<a id="20240502160000"></a>
+## 16:00~16:59
+日小结后的git操作编写成批处理文件
+
+- 每日小结后的git操作：\ego\src\finish.bat 执行结果第一段（后面雷同）：
+```
+
+D:\huangyg\git\ego\src>finish
+
+D:\huangyg\git\ego\src>cd ..\..\ego
+
+D:\huangyg\git\ego>git add .
+
+D:\huangyg\git\ego>git commit -m "- task:PSMD  [error,knowledge metadata鐨刾laceholder鍗囩骇](../../../draft/2"
+[vat 39bf432] - task:PSMD  [error,knowledge metadata閻ㄥ埦laceholder閸楀洨楠嘳(../../../draft/2
+ 7 files changed, 131 insertions(+), 74 deletions(-)
+ create mode 100644 data/draft/2024/d.20240502.yaml
+ create mode 100644 src/finish.bat
+ create mode 100644 term
+
+D:\huangyg\git\ego>git push github
+Enumerating objects: 24, done.
+Counting objects: 100% (24/24), done.
+Delta compression using up to 16 threads
+Compressing objects: 100% (11/11), done.
+Writing objects: 100% (14/14), 2.82 KiB | 1.41 MiB/s, done.
+Total 14 (delta 6), reused 0 (delta 0), pack-reused 0 (from 0)
+remote: Resolving deltas: 100% (6/6), completed with 6 local objects.
+remote:
+remote: GitHub found 2 vulnerabilities on hyg/ego's default branch (1 high, 1 moderate). To find out more, visit:
+remote:      https://github.com/hyg/ego/security/dependabot
+remote:
+To https://github.com/hyg/ego.git
+   3275342..39bf432  vat -> vat
+
+D:\huangyg\git\ego>git push coding
+Enumerating objects: 24, done.
+Counting objects: 100% (24/24), done.
+Delta compression using up to 16 threads
+Compressing objects: 100% (11/11), done.
+Writing objects: 100% (14/14), 2.82 KiB | 1.41 MiB/s, done.
+Total 14 (delta 6), reused 0 (delta 0), pack-reused 0 (from 0)
+remote:
+remote: Create a merge request for 'vat' on CODING by visiting:
+remote:
+remote:     https://huangyg.coding.net/p/ego/d/ego/git/merges/create/master...vat
+remote:
+To https://e.coding.net/huangyg/ego/ego.git
+   3275342..39bf432  vat -> vat
+
+D:\huangyg\git\ego>git push gitee
+Enumerating objects: 24, done.
+Counting objects: 100% (24/24), done.
+Delta compression using up to 16 threads
+Compressing objects: 100% (11/11), done.
+Writing objects: 100% (14/14), 2.82 KiB | 1.41 MiB/s, done.
+Total 14 (delta 6), reused 0 (delta 0), pack-reused 0 (from 0)
+remote: Powered by GITEE.COM [GNK-6.4]
+To https://gitee.com/hyg/ego.git
+   3275342..39bf432  vat -> vat
+```
+
+在season metadata中增加一个ego的低优先级todo项： 
+```
+    - '60': 用js代码完成日小结后的git操作。
+      readme: |
+        - 参考：D:\huangyg\git\draft\2024\04\20240430140000.md
+        - 在各task metadata中给出git库的路径，每天根据实际任务去操作。
+```

release/time/d.20240503.md

@@ -0,0 +1,873 @@
+# 2024.05.03.
+日小结  
+
+<a id="top"></a>
+根据[ego模型时间接口](https://gitee.com/hyg/blog/blob/master/timeflow.md)，今天绑定模版1。
+
+
+
+<a id="index"></a>
+- 07:45	[term metadata的upgradeby字段的内容写入term view](#20240503074500)  
+- 09:30	[自动把旧格式转化为新格式](#20240503093000)  
+- 14:00	[整理废弃git库。](#20240503140000)  
+- 14:30	[学习正则表达式RegExp](#20240503143000)  
+- 16:00	[Jade Language生成html view](#20240503160000)  
+
+---
+season stat:
+
+| task | alloc | sold | hold |
+| --- | --- | --- | --- |
+| total | 13275 | 5445 | 7830 |
+| PSMD | 7000 | 3028 | 3972 |
+| learn | 1000 | 222 | 778 |
+| ego | 3000 | 1731 | 1269 |
+| js | 1375 | 229 | 1146 |
+| xuemen | 600 | 90 | 510 |
+| raw | 300 | 115 | 185 |
+| infra | 0 | 30 | -30 |
+
+---
+
+waiting list:
+
+
+- 30分钟时间片：
+  - raw的第1号事项：debug-灰枣按"个"作为单位被算出很高热量。
+  - js的第2号事项：async
+  - raw的第2号事项：设计DRI metadata
+  - PSMD的第3号事项：生成入门目录涉及的所有view，调整措池准备试用
+
+- 60分钟时间片：
+  - PSMD的第1号事项：term metadata的depend,together,effect等字段的内容写入term view
+  - ego的第1号事项：github + codeberg page 范例
+  - js的第1号事项：学习测试方法和工具
+  - learn的第1号事项：nosql
+
+- 90分钟时间片：
+  - PSMD的第2号事项：完成psmd\src\conver.js中的termsertoterm().
+  - learn的第2号事项：把PSMD的data、src部分升级到rdf，如果升级成功则作为范例。
+  - PSMD的第8号事项：整理近期手稿。
+
+- 195分钟时间片：
+  - xuemen的第2号事项：xuemen COD metadata
+  - ego的第4号事项：在整理近期手稿之后，修订个人模型。
+  - PSMD的第6号事项：term + COM matedata -> deploy metadata -> deploy view
+
+---
+
+[top](#top) | [index](#index)
+<a id="20240503074500"></a>
+## 7:45~8:44
+term metadata的upgradeby字段的内容写入term view
+
+- upgradeby的语法：
+    - 如果是按照i本term内的item修订，就写localid：<term.xxxx.localid.i> -> “本条款按照i条款修订”
+        - 如果i是本条款的localid -> ”本条款按照本条款修订“
+    - 如果是按照外部条款修订，就写term placeholder：<term.xxxx.term.x>,然后按规则由本term的interface字段或上级term的item.map字段替换。
+    - 上级定义覆盖下级定义：如果上级term定义了一个item的修订权，这个item的内部定义就一律以上级为准。包括上级的localid或者term placeholder。
+        - 能否在上级的item.map中替换下级的<term.xxxx.localid.x>？技术上可行，有需求吗？
+    - 进一步思考：仅仅修订权定义不同，是否要另建一套term才能表达。抑或是条文和修订权分别定义。
+
+
+只完成了term的upgradeby，执行结果：
+```
+D:\huangyg\git\PSMD\src>node term term 01e1c775
+01e1c775>local upgradeby slice:
+0~6:<term.
+6~14:01e1c775
+14~22:.localid
+23~-1:1
+01e1c775>upgradestr:本条款按照本条款修订。
+23f76740>upgradestr:本条款按照本条款修订。
+01e1c775>local upgradeby slice:
+0~6:<term.
+6~14:01e1c775
+14~22:.localid
+23~-1:1
+01e1c775>upgradestr:本条款按照1.条款修订。
+bafdd0aa>upgradestr:本条款按照1.条款修订。
+01e1c775>local upgradeby slice:
+0~6:<term.
+6~14:01e1c775
+14~22:.localid
+23~-1:1
+01e1c775>upgradestr:本条款按照1.条款修订。
+988ea839>upgradestr:本条款按照1.条款修订。
+../view/term.01e1c775.md文件更新，内容如下:
+条款 01e1c775 正文:
+1. 本条款按照本条款修订。由deployer书面提交即生效。
+2. 本条款按照1.条款修订。p=20，p%=20%。
+3. 本条款按照1.条款修订。由director表决按一人一票表决，超过80%出席会议有效，赞成票超过超过三分之二为通过。
+
+---
+条款 01e1c775 readme:
+本条款是模型1609利益分配的核心条款。
+1. 自修订条款是权力分配中的顶级条款。
+2. 本条款设置了参数p的初始值。
+3. 本条款是权力分配中的二级条款。
+
+../view/term.01e1c775.html文件更新，内容如下:
+<!DOCTYPE html>
+<html lang="zh-cn">
+
+<head>
+    <meta charset="UTF-8">
+    <script>
+
+
+
+    </script>
+</head>
+
+<body>
+    <hr />
+    <h3>条款01e1c775</h3>
+    <br />
+    <hr />
+    正文:
+    <br />
+    1. 本条款按照本条款修订。由deployer书面提交即生效。<br/>
+2. 本条款按照1.条款修订。p=20，p%=20%。<br/>
+3. 本条款按照1.条款修订。由director表决按一人一票表决，超过80%出席会议有效，赞成票超过超过三分之二为通过。<br/>
+
+    <br />
+    <hr />
+
+    readme:
+    <br />
+    本条款是模型1609利益分配的核心条款。<br/>
+1. 自修订条款是权力分配中的顶级条款。<br/>
+2. 本条款设置了参数p的初始值。<br/>
+3. 本条款是权力分配中的二级条款。<br/>
+
+    <hr />
+
+</body>
+
+</html>
+```
+
+把余下工作写回season metadata：
+- "60": term metadata的depend,together,effect等字段的内容写入term view
+---
+
+[top](#top) | [index](#index)
+<a id="20240503093000"></a>
+##  9:30~10:59
+自动把旧格式转化为新格式
+
+- old term -> new term
+    - interface格式替换，所有placeholder替换。
+    - text降到item下,readme保持在顶级。
+
+执行结果：
+```
+D:\huangyg\git\PSMD\src>node conver
+enter termtoterm(), term id: 01e1c775
+it is a new version term metadata.
+enter termtoterm(), term id: 064129fa
+it has a text field. move to item level.
+文件term.064129fa.yaml已经更新，内容：
+name: 制定规则-4
+id: 064129fa
+interface:
+  <term.064129fa.term.1>: 分支隔离规则
+item:
+  - localid: ''
+    text: |
+      <term.064129fa.term.1>适用于制定规章。一个分支的共同体内制定规章时，所提供依据如果使用其它分支的案例，将自动增加切换规章的动议作为前提。
+
+enter termtoterm(), term id: 0ccddb29
+it has a text field. move to item level.
+文件term.0ccddb29.yaml已经更新，内容：
+name: 执行部门陷入割据
+id: 0ccddb29
+interface:
+  <term.0ccddb29.entity.1>: 共同体
+  <term.0ccddb29.entity.2>: 下达指令者
+  <term.0ccddb29.entity.3>: 决策部门
+  <term.0ccddb29.entity.4>: 执行部门
+  <term.0ccddb29.asset.1>: 工单
+  <term.0ccddb29.asset.2>: 日志
+  <term.0ccddb29.term.1>: 资源不足
+readme: |
+  - <term.0ccddb29.entity.2>的指令包括对更早指令的掩盖，通过互相包庇产生系统性的对抗。
+  - <term.0ccddb29.entity.1>曾经对<term.0ccddb29.entity.2>违约，以一定范围内的割据作为抵押物。这是历史上资源紧缺，无法兑现约定报酬的后遗症。
+  - 把一定范围内的割据作为违约抵押物的情况，解除割据应该同时处理历史欠账。在<term.0ccddb29.entity.1>设立阶段，就要确定是否符合<term.0ccddb29.term.1>，如果符合应该在设立时解决。
+item:
+  - localid: ''
+    text: |
+      出现以下情况之一：
+      - <term.0ccddb29.entity.3>未界定<term.0ccddb29.entity.4>工作的合规性要求。
+      - <term.0ccddb29.entity.3>界定了<term.0ccddb29.entity.4>工作的合规性要求。
+        - <term.0ccddb29.entity.4>成员对指令不进行合规检查，即使不合规也执行。
+        - <term.0ccddb29.entity.4>成员及<term.0ccddb29.entity.2>未按要求填写和提交表单，比如<term.0ccddb29.asset.1>、<term.0ccddb29.asset.2>。
+
+enter termtoterm(), term id: 1
+it is a new version term metadata.
+enter termtoterm(), term id: 177700d4
+it has a text field. move to item level.
+文件term.177700d4.yaml已经更新，内容：
+name: 集体决策
+id: 177700d4
+interface:
+  <term.177700d4.entity.1>: director
+readme: ''
+effect: ''
+item:
+  - localid: ''
+    text: |
+      由<term.177700d4.entity.1>表决按一人一票表决，超过80%出席会议有效，赞成票超过超过三分之二为通过。
+
+enter termtoterm(), term id: 1c3f8b06
+no interface field here.
+it has a text field. move to item level.
+文件term.1c3f8b06.yaml已经更新，内容：
+name: 分支隔离规则-1
+id: 1c3f8b06
+readme: |
+  - 注意特殊化的隐藏方案：不需要与其它方案对比，不需要显性地公布内容，而视为已经通过产生效力。
+    - 现状常常被特殊化。
+  - 注意判断：成员下意识地把自己赞成的方案特殊化、隐蔽化。
+item:
+  - localid: ''
+    text: |
+      对相同事项的不同处理方法，视为同一规章的不同分支版本。对该事项未做任何规定，也视为其中一个分支版本。
+
+enter termtoterm(), term id: 2
+it is a new version term metadata.
+enter termtoterm(), term id: 23f76740
+it is a new version term metadata.
+enter termtoterm(), term id: 259076a4
+it has a text field. move to item level.
+文件term.259076a4.yaml已经更新，内容：
+name: 符合某条件3
+id: 259076a4
+interface:
+  <term.259076a4.term.1>: 容器规则
+item:
+  - localid: ''
+    text: |
+      涉事各方签署 <term.259076a4.term.1>，承诺遵守该条件，将生效、执行的记录作为补充信息。
+
+enter termtoterm(), term id: 260ca049
+it has a text field. move to item level.
+文件term.260ca049.yaml已经更新，内容：
+name: 直接指挥的归档
+id: 260ca049
+interface:
+  <term.260ca049.entity.1>: 经理
+  <term.260ca049.entity.2>: 执行部门
+  <term.260ca049.entity.3>: 决策部门
+  <term.260ca049.asset.1>: 通用工单
+readme: |
+  - 如果出现重大失误，<term.260ca049.entity.3>可能召开临时会议干预。所以要求及时归档。
+  - 在使用IT系统时，可以由系统实时归档。本条款可以根据情况修订。
+item:
+  - localid: ''
+    text: |
+      <term.260ca049.entity.1>和执行人员都要向<term.260ca049.entity.3>归档<term.260ca049.asset.1>。执行人员应在收到或自行填写<term.260ca049.asset.1>24小时内归档。<term.260ca049.entity.1>填写的<term.260ca049.asset.1>归档要求是：
+        - 在<term.260ca049.entity.3>的一个审议周期内，每一事项的前3份<term.260ca049.asset.1>，应在出具24小时内向<term.260ca049.entity.3>归档；
+        - 在<term.260ca049.entity.3>的一个审议周期内，同一事项的第4份<term.260ca049.asset.1>起，可以汇总后在审议周期结束前一并归档。
+
+enter termtoterm(), term id: 2e758794
+it has a text field. move to item level.
+文件term.2e758794.yaml已经更新，内容：
+name: 保密规则-2
+id: '2e758794'
+interface:
+  <term.2e758794.term.1>: PS标准
+readme: |
+  - 注意特殊化的保密规定：下级规章或由下级规章任免的人员，规定了上级规章及其工作记录的密级。
+    - 常见于规章制订、人员任免脱离上级规章，出现脱节的情况。借保密隐藏过失。
+  - 注意判断：成员下意识地把自己的工作特殊化、隐蔽化。
+item:
+  - localid: ''
+    text: |
+      按<term.2e758794.term.1>上溯得出顶级规章，从顶级规章到保密制度之间的上下级规章链条（包括保密制度），这组规章的密级均为公开，这组规章的工作记录的密级由该规章自行规定，保密制度不得改变。
+
+enter termtoterm(), term id: 3
+it is a new version term metadata.
+enter termtoterm(), term id: 33523fe1
+no interface field here.
+it has a text field. move to item level.
+文件term.33523fe1.yaml已经更新，内容：
+name: 符合某条件1
+id: 33523fe1
+item:
+  - localid: ''
+    text: |
+      涉事各方全体同意，推举一名或多名保证人：
+        - 保证人在其它事项中符合该条件，并按照本附件提供补充信息。
+        - 由保证人调查涉事各方是否符合该条件，将调查记录作为补充信息。
+
+enter termtoterm(), term id: 4
+it is a new version term metadata.
+enter termtoterm(), term id: 4116b506
+no interface field here.
+it has a text field. move to item level.
+文件term.4116b506.yaml已经更新，内容：
+name: 公布日志
+id: 4116b506
+item:
+  - localid: ''
+    text: |
+      公布完整、连续、不可删改的执行记录，证实方案的效果。
+        - 如果以前的执行记录不符合以上条件，可以在愿意按标准公布记录的独立第三方验证。
+
+enter termtoterm(), term id: 48577ce8
+it has a text field. move to item level.
+文件term.48577ce8.yaml已经更新，内容：
+name: 直接指挥权
+id: 48577ce8
+interface:
+  <term.48577ce8.entity.1>: 经理
+  <term.48577ce8.entity.2>: 执行部门
+  <term.48577ce8.entity.3>: 决策部门
+  <term.48577ce8.term.1>: 基本制度
+  <term.48577ce8.term.3>: 劳动合同
+  <term.48577ce8.asset.1>: 通用工单
+item:
+  - localid: ''
+    text: |
+      在<term.48577ce8.entity.2>内，<term.48577ce8.term.1>和<term.48577ce8.term.3>未定义的事项由<term.48577ce8.entity.1>直接指挥。
+
+enter termtoterm(), term id: 49d40087
+no interface field here.
+it has a text field. move to item level.
+文件term.49d40087.yaml已经更新，内容：
+name: 分支隔离规则-2
+id: 49d40087
+item:
+  - localid: ''
+    text: |
+      实际通过生效、使用某分支版本的规章，即为支持该分支版本，反对其它分支版本。
+
+enter termtoterm(), term id: 4b12ac08
+it has a text field. move to item level.
+文件term.4b12ac08.yaml已经更新，内容：
+name: 入门目录202404151600-3
+id: 4b12ac08
+interface:
+  <term.4b12ac08.term.1>: 附件21
+readme: |
+  - "可行"是指：
+    - 方案的内容完整、准确、无二义性，具备相关岗位普通资质的人员可以自行阅读、使用。
+    - 在独立的第三方实施，可以按预期的比率产生预期的效果。
+  - 注意判断：成员下意识地把自己的工作特殊化、隐蔽化。
+item:
+  - localid: ''
+    text: |
+      如果有其它可行方案请发到<huangyg@mars22.com>，我将按照<term.4b12ac08.term.1>核实。
+
+enter termtoterm(), term id: 4c37b176
+no interface field here.
+it has a text field. move to item level.
+文件term.4c37b176.yaml已经更新，内容：
+name: 制定规则-2
+id: 4c37b176
+readme: |
+  - 接受质询并回应，可以检验该成员是否下意识地把自己的特殊化、隐蔽化。
+  - 依据的客观性，可以判断该成员能否在有意识的情况下判断效果。
+item:
+  - localid: ''
+    text: |
+      接到质询时必须提供依据，依据必须是 外部法律 or 案例统计 两种方式之一。
+
+enter termtoterm(), term id: 50d2347f
+no interface field here.
+it has a text field. move to item level.
+文件term.50d2347f.yaml已经更新，内容：
+name: 制定规则-1
+id: 50d2347f
+item:
+  - localid: ''
+    text: |
+      制定规章要明确预期效果。
+
+enter termtoterm(), term id: 52edbf25
+it has a text field. move to item level.
+文件term.52edbf25.yaml已经更新，内容：
+name: 入门目录202404151600-2-2
+id: 52edbf25
+interface:
+  <term.52edbf25.term.1>: 附件20
+  <term.52edbf25.term.2>: 附件30
+  <term.52edbf25.term.3>: 附件42
+  <term.52edbf25.term.4>: 附件31
+  <term.52edbf25.term.5>: 附件32
+  <term.52edbf25.term.6>: 附件33
+  <term.52edbf25.term.7>: 附件34
+item:
+  - localid: ''
+    text: |
+      条件：同意按照<term.52edbf25.term.1>增加补充信息，补充关于<term.52edbf25.term.2>，<term.52edbf25.term.3>，<term.52edbf25.term.4>、<term.52edbf25.term.5>、<term.52edbf25.term.6>、<term.52edbf25.term.7>的补充信息，且判断符合附件<term.52edbf25.term.2>，<term.52edbf25.term.3>，不全符合符合<term.52edbf25.term.4>、<term.52edbf25.term.5>、<term.52edbf25.term.6>、<term.52edbf25.term.7>。
+      建议：先参考default+1406标准模型开展业务，逐步完善规章，取得进步后重新增加关于附件<term.52edbf25.term.4>、<term.52edbf25.term.5>、<term.52edbf25.term.6>、<term.52edbf25.term.7>的补充信息。
+
+enter termtoterm(), term id: 55c25f3f
+no interface field here.
+it has a text field. move to item level.
+文件term.55c25f3f.yaml已经更新，内容：
+name: 制定规则-3
+id: 55c25f3f
+item:
+  - localid: ''
+    text: |
+      如果是旧版本修订，制定者可以提出适用范围。只能向该适用范围内使用旧版规章的共同体发送修订通知。
+
+enter termtoterm(), term id: 583d6243
+it has a text field. move to item level.
+文件term.583d6243.yaml已经更新，内容：
+name: 如果割据就启用1406
+id: 583d6243
+interface:
+  <term.583d6243.term.1>: 附件44
+  <term.583d6243.term.2>: 附件1406
+item:
+  - localid: ''
+    text: |
+      如果符合<term.583d6243.term.1>的情况，则<term.583d6243.term.2>自动生效。
+
+enter termtoterm(), term id: 5ab2b2ba
+no interface field here.
+it has a text field. move to item level.
+文件term.5ab2b2ba.yaml已经更新，内容：
+name: 能力和贡献持续变化
+id: 5ab2b2ba
+readme: |
+  注意判断：即使规章（包括草案、参考案例）已经足够完善，足以保证准确估算贡献符合利益，依然有成员下意识地高估自己的贡献、低估其他成员的贡献，无法自控。
+item:
+  - localid: ''
+    text: |
+      定义：核心人员凭借职权高估自己的贡献、低估非核心成员的贡献，这样做的综合效果更符合他们的利益。
+      反向的情况，核心人员准确估算包括自己在内的成员贡献，这样做的综合效果更符合他们的利益。
+
+enter termtoterm(), term id: 5b4e0597
+it has a text field. move to item level.
+文件term.5b4e0597.yaml已经更新，内容：
+name: 入门目录202404151600-2-1
+id: 5b4e0597
+interface:
+  <term.5b4e0597.term.1>: 附件20
+  <term.5b4e0597.term.2>: 附件30
+  <term.5b4e0597.term.3>: 附件42
+  <term.5b4e0597.term.4>: 附件31
+  <term.5b4e0597.term.5>: 附件32
+  <term.5b4e0597.term.6>: 附件33
+  <term.5b4e0597.term.7>: 附件34
+readme: |
+  由于规章只能改变有意识、理性的行为，所以根据条件提出建议。
+item:
+  - localid: ''
+    text: |
+      条件：同意按照<term.5b4e0597.term.1>增加补充信息，补充关于<term.5b4e0597.term.2>，<term.5b4e0597.term.3>，<term.5b4e0597.term.4>、<term.5b4e0597.term.5>、<term.5b4e0597.term.6>、<term.5b4e0597.term.7>的补充信息，且均判断为符合。
+      建议：使用自定义的规章解决资源和重构问题，具体可以参考1609、chain等标准模型。
+
+enter termtoterm(), term id: 5c7d5a18
+no interface field here.
+it has a text field. move to item level.
+文件term.5c7d5a18.yaml已经更新，内容：
+name: 分支隔离规则-3
+id: 5c7d5a18
+readme: |
+  - 避免断章取义：隐藏规章之间的依赖关系，截取个别章节和效果，用来支持相反的前置条款。
+    - 例如：不刷牙的张三向刷牙的李四询问后续问题，李四只需要回答如何从不刷牙开始刷牙，而无须回答张三的原始问题。以免被断章取义。
+      - 注意是后续问题。如果询问刷牙的效果（假设这是他们最初的选择分岔点），则可以直接回答。
+  - 注意：有的是故意设套。也有下意识地--理性的一面已经做出可靠的判断，潜意识里做出相反的选择，于是无法自控地沿着曾经说服过自己的模式去“套话”。
+item:
+  - localid: ''
+    text: |
+      规章使用过程遇到问题可以提出修订委托，如发往反对者将自动转为帮助切换规章的委托（切换到对方实际使用的分支版本）。如果是付费委托，受托者只需回答实际收到的问题。
+
+enter termtoterm(), term id: 5f7bbbe4
+no interface field here.
+it has a text field. move to item level.
+文件term.5f7bbbe4.yaml已经更新，内容：
+name: 分支隔离规则-4
+id: 5f7bbbe4
+item:
+  - localid: ''
+    text: |
+      查询资料时，未做任何规定分支可以列出所有分支的资料，其它分支只列出本分支的资料。
+
+enter termtoterm(), term id: 5f7eed28
+no interface field here.
+it has a text field. move to item level.
+文件term.5f7eed28.yaml已经更新，内容：
+name: PS标准-2
+id: 5f7eed28
+item:
+  - localid: ''
+    text: |
+      人员的上下级关系，根据任免权定义。
+
+enter termtoterm(), term id: 607455c0
+no interface field here.
+it has a text field. move to item level.
+文件term.607455c0.yaml已经更新，内容：
+name: 提出对赌要约
+id: 607455c0
+item:
+  - localid: ''
+    text: |
+      已发布开放的要约，只有取得该效果才有收益。
+
+enter termtoterm(), term id: 64eb9304
+it has a text field. move to item level.
+文件term.64eb9304.yaml已经更新，内容：
+name: 自修订条款
+id: 64eb9304
+interface:
+  <term.64eb9304.entity.1>: deployer
+readme: ''
+effect: ''
+item:
+  - localid: ''
+    text: |
+      由<term.64eb9304.entity.1>书面提交即生效。
+
+enter termtoterm(), term id: 6988b66d
+no interface field here.
+it has a text field. move to item level.
+文件term.6988b66d.yaml已经更新，内容：
+name: PS标准-1
+id: 6988b66d
+item:
+  - localid: ''
+    text: |
+      规章条款的上下级关系，根据制定、修订权定义。
+
+enter termtoterm(), term id: 7288c99c
+it has a text field. move to item level.
+文件term.7288c99c.yaml已经更新，内容：
+name: 入门目录202404151600-2-3
+id: 7288c99c
+interface:
+  <term.7288c99c.term.1>: 附件20
+  <term.7288c99c.term.2>: 附件30
+item:
+  - localid: ''
+    text: |
+      条件：
+      - 不能按照<term.7288c99c.term.1>增加补充信息。
+      - 同意按照<term.7288c99c.term.1>增加补充信息，补充关于<term.7288c99c.term.2>的补充信息，且判断为不符合。
+      建议：在业务背景下，基于既成事实博弈。具体可以参考default标准模型。
+
+enter termtoterm(), term id: 7506353d
+it has a text field. move to item level.
+文件term.7506353d.yaml已经更新，内容：
+name: 直接指挥的方式
+id: 7506353d
+interface:
+  <term.7506353d.entity.1>: 经理
+  <term.7506353d.entity.2>: 执行部门
+  <term.7506353d.entity.3>: 决策部门
+  <term.7506353d.term.2>: 具体规章
+  <term.7506353d.asset.1>: 通用工单
+readme: |
+  在使用IT系统时，可修改为<term.7506353d.entity.1>向系统提交<term.7506353d.asset.1>，并由系统通知负责执行的成员。
+item:
+  - localid: ''
+    text: |
+      直接指挥的方式：
+        - <term.7506353d.entity.1>填写<term.7506353d.asset.1>明确事项的处理要求，并交给负责执行的成员；
+        - <term.7506353d.entity.1>制订<term.7506353d.term.2>明确事项的处理要求，并提交给<term.7506353d.entity.3>备案，<term.7506353d.entity.3>签收后<term.7506353d.term.2>即生效。<term.7506353d.entity.2>成员根据生效的<term.7506353d.term.2>自行填写<term.7506353d.asset.1>并执行。
+
+enter termtoterm(), term id: 90c5a430
+no interface field here.
+it has a text field. move to item level.
+文件term.90c5a430.yaml已经更新，内容：
+name: PS标准-4
+id: 90c5a430
+item:
+  - localid: ''
+    text: |
+      严格执行任免程序。上级人员未赴任（或被实质架空）时，不提名、不讨论下级人员。
+
+enter termtoterm(), term id: 91ff9448
+no interface field here.
+it has a text field. move to item level.
+文件term.91ff9448.yaml已经更新，内容：
+name: 有效的内部监管
+id: 91ff9448
+item:
+  - localid: ''
+    text: |
+      定义：已有基础制度和人员，能保证书面规章的违约成本高于收益。规定监管人员以外的内部成员、外部合作方不需要额外为此耗费资源。
+
+enter termtoterm(), term id: 988ea839
+it is a new version term metadata.
+enter termtoterm(), term id: a1c197a9
+no interface field here.
+it has a text field. move to item level.
+文件term.a1c197a9.yaml已经更新，内容：
+name: 符合某条件2
+id: a1c197a9
+item:
+  - localid: ''
+    text: |
+      涉事各方分别自述，交叉核实。将所有记录合并作为补充信息。
+
+enter termtoterm(), term id: bafdd0aa
+it is a new version term metadata.
+enter termtoterm(), term id: bb8005b9
+it has a text field. move to item level.
+文件term.bb8005b9.yaml已经更新，内容：
+name: 符合某条件开头
+id: bb8005b9
+interface:
+  <term.bb8005b9.term.1>: 下一条
+item:
+  - localid: ''
+    text: |
+      对自述难以核实的情况下，可以按照<term.bb8005b9.term.1>方式之一增加补充信息：
+
+enter termtoterm(), term id: bba7c6f1
+it has a text field. move to item level.
+文件term.bba7c6f1.yaml已经更新，内容：
+name: 利益分配比例
+id: bba7c6f1
+interface:
+  <term.bba7c6f1.asset.1>: p
+readme: ''
+effect: ''
+item:
+  - localid: ''
+    text: |
+      <term.bba7c6f1.asset.1>=20，<term.bba7c6f1.asset.1>%=20%。
+
+enter termtoterm(), term id: c8254555
+no interface field here.
+it has a text field. move to item level.
+文件term.c8254555.yaml已经更新，内容：
+name: PS标准-3
+id: c8254555
+item:
+  - localid: ''
+    text: |
+      严格执行制定、修订程序。上级规章条款未生效（或被实质架空）时，不提交、不讨论下级规章条款。
+
+enter termtoterm(), term id: c87ec159
+it has a text field. move to item level.
+文件term.c87ec159.yaml已经更新，内容：
+name: 通用工单的审议
+id: c87ec159
+interface:
+  <term.c87ec159.entity.1>: 经理
+  <term.c87ec159.entity.2>: 执行部门
+  <term.c87ec159.entity.3>: 决策部门
+  <term.c87ec159.term.1>: 基本制度
+  <term.c87ec159.term.2>: 具体规章
+  <term.c87ec159.asset.1>: 通用工单
+  <term.c87ec159.asset.2>: 审议报告
+readme: |
+  - 时间按一月一周期安排，只是范例。可以根据<term.c87ec159.term.1>的完善程度自行调节，从一周到一年都可以考虑。
+  - <term.c87ec159.term.1>生效后，所规定的工作事项就不再允许<term.c87ec159.entity.1>直接指挥。相应的<term.c87ec159.term.2>也同时失效。
+  - <term.c87ec159.term.1>的规定，可能与<term.c87ec159.asset.1>规定的相同、相似、相反......
+item:
+  - localid: ''
+    text: |
+      <term.c87ec159.entity.3>成员应：
+        - 在审议周期的第10天结束前阅读完上一个审议周期结束前归档的<term.c87ec159.asset.1>，提交<term.c87ec159.asset.2>以及<term.c87ec159.term.1>的修订动议。
+        - 在审议周期的第20天结束前阅读完其他成员提交的<term.c87ec159.asset.2>和<term.c87ec159.term.1>的修订动议，提交<term.c87ec159.asset.2>。
+        - 在审议周期结束前对<term.c87ec159.term.1>修订动议进行表决。
+
+enter termtoterm(), term id: cb4ab0e9
+no interface field here.
+it has a text field. move to item level.
+文件term.cb4ab0e9.yaml已经更新，内容：
+name: 资源不足
+id: cb4ab0e9
+item:
+  - localid: ''
+    text: |
+      定义：需要以未来的收入换取资源，而且需要与同行争夺。
+      反向的情况，是创始时能一次筹集到足够的资源，可见未来的收入和积累都超过支出。或者需要以未来的收入换取资源，但是不需要竞争即可获得充足资源。
+
+enter termtoterm(), term id: cc0fba2f
+no interface field here.
+it has a text field. move to item level.
+文件term.cc0fba2f.yaml已经更新，内容：
+name: 入门目录202404151600-1
+id: cc0fba2f
+item:
+  - localid: ''
+    text: |
+      针对不同条件给出建议如下：
+
+enter termtoterm(), term id: d13b27d1
+no interface field here.
+it has a text field. move to item level.
+文件term.d13b27d1.yaml已经更新，内容：
+name: 保密规则-3
+id: d13b27d1
+item:
+  - localid: ''
+    text: |
+      一份文档所有用途使用相同方式取得。如果因不可抗力需要改变方式，应规定不可抗力的判定程序，确保内容相同。
+
+enter termtoterm(), term id: d1f88a2c
+no interface field here.
+it has a text field. move to item level.
+文件term.d1f88a2c.yaml已经更新，内容：
+name: 保密规则-1
+id: d1f88a2c
+item:
+  - localid: ''
+    text: |
+      所有人员的所有工作结果默认为公开，对外发布。
+
+enter termtoterm(), term id: dd1bc41b
+no interface field here.
+it has a text field. move to item level.
+文件term.dd1bc41b.yaml已经更新，内容：
+name: 入门目录202404151600-2-4
+id: dd1bc41b
+item:
+  - localid: ''
+    text: |
+      条件：还在筹备因此无法补充信息的。
+      建议：参考booting标准模型。
+
+enter termtoterm(), term id: df39a1ed
+no interface field here.
+it has a text field. move to item level.
+文件term.df39a1ed.yaml已经更新，内容：
+name: 保密规则-4
+id: df39a1ed
+item:
+  - localid: ''
+    text: |
+      如果在密级规定范围内的人员都没有能力完成任务，制定保密制度相应条款的人员承担主要责任，赔偿损失。
+```
+
+- 顺便把term upgradeby的”本条款“实现了。
+- 时间不够，termset部分追加一个时间片去完成：
+    - '60': 完成psmd\src\conver.js中的termsertoterm().
+      readme: |
+        - 参考5.3. 9:30 draft。
+        - old termset -> new term
+          - 如果item符合以下条件，直接把text、readme提升到item下：
+            - type = term
+            - localid = ”“
+          - 增加converfrom字段：值是旧term或者termset的文件名。
+---
+
+[top](#top) | [index](#index)
+<a id="20240503140000"></a>
+## 14:00~14:29
+整理废弃git库
+
+- 设立备份文件夹：D:\huangyg\backup\git 。
+    - 选中的项目在主文件夹 D:\huangyg\git commit
+    - 在备份文件夹clone
+    - 在主文件夹删除。提前把用户权限赋予整个主文件夹及子文件夹，修改高级安全属性变更所有者。
+- 以下git库移入备份文件夹：
+    - BEICHU
+    - aev
+    - 7kick
+    - carwash
+    - celtsc
+    - FelixHuang
+    - FSM
+- 其他情况：
+    - Financial，本地远程都是空的，log也是空的。但是github有watcher，暂时不删。移到备份。
+
+时间不够，再追加一个30分钟时间片到season metadata.todo字段
+
+---
+
+[top](#top) | [index](#index)
+<a id="20240503143000"></a>
+## 14:30~14:59
+学习正则表达式RegExp
+
+- https://regexlearn.com/
+- https://www.runoob.com/regexp/regexp-tutorial.html
+
+基本了解语法和简单运用，早上自学时间可以试一下复杂的练习题。不再追加时间，实践中慢慢熟悉。
+
+---
+
+[top](#top) | [index](#index)
+<a id="20240503160000"></a>
+## 16:00~16:59
+Jade Language生成html view
+
+- 把htmltemp.term改名为termtemp.ejs， 把ejs相关代码块整理到判断下。
+- 另建termtemp.jade模版文件。
+```
+html(lang="zh-cn")
+  head
+    title term html sample
+    script
+      if alert
+        !{alertstr}
+      if confirm
+        !{confirmstr}
+      if prompt
+        !{apromptstr}
+
+  body
+    h3 条款 #{termid}
+    hr
+    p 正文:
+    p !{treehtml}
+    hr
+    if(readme)
+      p 注释:
+      p !{treereadmehtml}
+      hr
+```
+
+执行结果如下：
+```
+D:\huangyg\git\PSMD\src>node term term 01e1c775
+01e1c775>local upgradeby slice:
+0~6:<term.
+6~14:01e1c775
+14~22:.localid
+23~-1:1
+01e1c775>upgradestr:本条款按照本条款修订。
+23f76740>upgradestr:本条款按照本条款修订。
+01e1c775>local upgradeby slice:
+0~6:<term.
+6~14:01e1c775
+14~22:.localid
+23~-1:1
+01e1c775>upgradestr:本条款按照1.条款修订。
+bafdd0aa>upgradestr:本条款按照1.条款修订。
+01e1c775>local upgradeby slice:
+0~6:<term.
+6~14:01e1c775
+14~22:.localid
+23~-1:1
+01e1c775>upgradestr:本条款按照1.条款修订。
+988ea839>upgradestr:本条款按照1.条款修订。
+../view/term.01e1c775.md文件更新，内容如下:
+条款 01e1c775 正文:
+1. 本条款按照本条款修订。由deployer书面提交即生效。
+2. 本条款按照1.条款修订。p=20，p%=20%。
+3. 本条款按照1.条款修订。由director表决按一人一票表决，超过80%出席会议有效，赞成票超过超过三分之二为通过。
+
+---
+条款 01e1c775 readme:
+本条款是模型1609利益分配的核心条款。
+1. 自修订条款是权力分配中的顶级条款。
+2. 本条款设置了参数p的初始值。
+3. 本条款是权力分配中的二级条款。
+
+Warning: missing space before text for line 6 of jade file "undefined"
+Warning: missing space before text for line 8 of jade file "undefined"
+Warning: missing space before text for line 10 of jade file "undefined"
+../view/term.01e1c775.html文件更新，内容如下:
+<html lang="zh-cn"><head><title>term html sample</title><script>confirm("confirm test.")</script></head><body><h3>条款 01e1c775</h3><hr/><p>正文:</p><p>1. 本条款按照本条款修订。由deployer书面提交即生效。<br/>
+2. 本条款按照1.条款修订。p=20，p%=20%。<br/>
+3. 本条款按照1.条款修订。由director表决按一人一票表决，超过80%出席会议有效，赞成票超过超过三分之二为通过。<br/>
+</p><hr/><p>注释:</p><p>本条款是模型1609利益分配的核心条款。<br/>
+1. 自修订条款是权力分配中的顶级条款。<br/>
+2. 本条款设置了参数p的初始值。<br/>
+3. 本条款是权力分配中的二级条款。<br/>
+</p><hr/></body></html>
+```

release/time/d.20240505.md

@@ -0,0 +1,337 @@
+# 2024.05.05.
+日小结  
+
+<a id="top"></a>
+根据[ego模型时间接口](https://gitee.com/hyg/blog/blob/master/timeflow.md)，今天绑定模版2。
+
+<a id="index"></a>
+- 07:45	[xuemen COD metadata-章程部分条款](#20240505074500)  
+- 14:00	[根据新的term metadata，重新设计COM、deploy metadata。](#20240505140000)  
+- 16:00	[term metadata的depend字段的内容写入term view](#20240505160000)  
+
+---
+season stat:
+
+| task | alloc | sold | hold |
+| --- | --- | --- | --- |
+| total | 13275 | 5445 | 7830 |
+| PSMD | 7000 | 3028 | 3972 |
+| learn | 1000 | 222 | 778 |
+| ego | 3000 | 1731 | 1269 |
+| js | 1375 | 229 | 1146 |
+| xuemen | 600 | 90 | 510 |
+| raw | 300 | 115 | 185 |
+| infra | 0 | 30 | -30 |
+
+---
+
+waiting list:
+
+
+- 30分钟时间片：
+  - learn的第1号事项：学习 github actions和 workflows 的yaml语法
+  - raw的第1号事项：设计DRI metadata
+  - ego的第2号事项：整理废弃git库，包括本地和远程。
+  - learn的第2号事项：YARRRML
+
+- 60分钟时间片：
+  - ego的第1号事项：在season metadata中实现浮动时间表，修改日计划功能。
+  - js的第1号事项：学习测试方法和工具
+  - xuemen的第1号事项：五月报税
+  - PSMD的第2号事项：term metadata的together,effect等字段的内容写入term view
+
+- 90分钟时间片：
+  - xuemen的第3号事项：xuemen COD metadata-S2状态下的部门模型
+  - learn的第4号事项：把PSMD的data、src部分升级到rdf，如果升级成功则作为范例。
+  - PSMD的第8号事项：整理近期手稿。
+
+- 195分钟时间片：
+  - PSMD的第1号事项：根据新的term metadata，重新设计COM、deploy、COD metadata，编辑出范例。
+  - ego的第3号事项：在整理近期手稿之后，修订个人模型。
+  - PSMD的第6号事项：term + COM matedata -> deploy metadata -> deploy view
+
+---
+
+[top](#top) | [index](#index)
+<a id="20240505074500"></a>
+## 7:45~10:59
+xuemen COD metadata-章程部分条款
+
+- 清理termset metadata + view,然后merge develop_newterm分支。
+    - convert.js暂时保留，因为还有termtoterm()
+    - 在tortoisegit，develop_newterm分支merge master
+    - 在tortoisegit切换到master分支，没什么变化，merge develop_newterm，新metadata、view、conver都有了。
+    - 命令行：git branch -D develop_newterm
+    - 命令行：git push github --delete develop_newterm 失败，命令行下没有设ssl。
+    - 删除两个残余termset metadata，commit after merge
+    - 在tortoisegit的push界面，选remote branch右边省略号，展开各remote看到分支，右键delete。有效。
+- 从公司章程开始整理，只编辑有用的条款：第八、十五、十八、二十条。
+
+执行结果：
+```
+
+D:\huangyg\git\PSMD\src>node term term 2e4f11cb
+enter maketermtext:2e4f11cb     prefix:
+enter maketermtext:e55c000c     prefix:第八条.
+enter maketermtext:a540486e     prefix:第八条.（一）.
+enter maketermtext:21af48dd     prefix:第八条.（二）.
+enter maketermtext:8b839d59     prefix:第八条.（三）.
+enter maketermtext:0b305ce2     prefix:第八条.（四）.
+enter maketermtext:53548d2d     prefix:第八条.（五）.
+enter maketermtext:040463e3     prefix:第八条.（六）.
+enter maketermtext:460c6741     prefix:第八条.（七）.
+enter maketermtext:393c92a3     prefix:第八条.（八）.
+enter maketermtext:f3cc3036     prefix:第八条.（九）.
+enter maketermtext:62c421f2     prefix:第八条.（十）.
+enter maketermtext:25c83dac     prefix:第十五条.
+enter maketermtext:f64809f8     prefix:第十五条.（一）.
+enter maketermtext:69632214     prefix:第十五条.（二）.
+enter maketermtext:423005c6     prefix:第十五条.（三）.
+enter maketermtext:615fc73f     prefix:第十五条.（四）.
+enter maketermtext:09ead2c1     prefix:第十五条.（五）.
+enter maketermtext:50430bca     prefix:第十五条.（六）.
+enter maketermtext:bb0ea239     prefix:第十五条.（七）.
+enter maketermtext:79f4f1e0     prefix:第十五条.（八）.
+enter maketermtext:5884eea5     prefix:第十五条.（九）.
+enter maketermtext:7957be41     prefix:第十五条.（十）.
+enter maketermtext:4bbd5668     prefix:第十八条.
+enter maketermtext:3f89e98f     prefix:第十八条.（一）.
+enter maketermtext:2a25389c     prefix:第十八条.（二）.
+enter maketermtext:b3012036     prefix:第十八条.（三）.
+enter maketermtext:f81cd0f0     prefix:第十八条.（四）.
+enter maketermtext:c73b28b3     prefix:第十八条.（五）.
+enter maketermtext:500e281d     prefix:第十八条.（六）.
+enter maketermtext:dd706d9c     prefix:第十八条.（七）.
+enter maketermtext:a2804f8b     prefix:第十八条.（八）.
+enter maketermtext:6208f678     prefix:第二十条.
+enter maketermtext:b96e83c2     prefix:第二十条.（一）.
+enter maketermtext:99520853     prefix:第二十条.（二）.
+enter maketermtext:5fec38ed     prefix:第二十条.（三）.
+enter maketermtext:c0eb6977     prefix:第二十条.（四）.
+enter maketermtext:aa469da0     prefix:第二十条.（五）.
+enter maketermtext:f732b768     prefix:第二十条.（六）.
+../view/term.2e4f11cb.md文件更新，内容如下:
+条款 2e4f11cb 正文:
+第八条. 本条款按照第八条.（十）.条款修订。股东会由全体股东组成，是公司的权力机构，行使下列职权：
+第八条.（一）. 本条款按照第八条.（十）.条款修订。决定公司的经营方针和投资计划；
+第八条.（二）. 本条款按照第八条.（十）.条款修订。选举和更换非由职工代表担任的董事、监事，决定有关董事、监事的报酬事项；
+第八条.（三）. 本条款按照第八条.（十）.条款修订。审议批准董事会的报告；
+第八条.（四）. 本条款按照第八条.（十）.条款修订。审议批准监事的报告；
+第八条.（五）. 本条款按照第八条.（十）.条款修订。审议批准公司的年度财务预算方案、决算方案；
+第八条.（六）. 本条款按照第八条.（十）.条款修订。审议批准公司的利润分配方案和弥补亏损的方案；
+第八条.（七）. 本条款按照第八条.（十）.条款修订。对公司增加或者减少注册资本作出决议；
+第八条.（八）. 本条款按照第八条.（十）.条款修订。对发行公司债券作出决议；
+第八条.（九）. 本条款按照第八条.（十）.条款修订。对公司合并、分立、解散、清算或者变更公司形式作出决议；
+第八条.（十）. 本条款按照本条款修订。修改公司章程；
+第十五条. 本条款按照第八条.（十）.条款修订。董事会行使下列职权：：
+第十五条.（一）. 本条款按照第八条.（十）.条款修订。负责召集股东会，并向股东会报告工作；
+第十五条.（二）. 本条款按照第八条.（十）.条款修订。执行股东会的决议；
+第十五条.（三）. 本条款按照第八条.（十）.条款修订。审定公司的经营计划和投资方案；
+第十五条.（四）. 本条款按照第八条.（十）.条款修订。制订公司的年度财务预算方案、决算方案；
+第十五条.（五）. 本条款按照第八条.（十）.条款修订。制订公司的利润分配方案和弥补亏损方案；
+第十五条.（六）. 本条款按照第八条.（十）.条款修订。制订公司增加或者减少注册资本以及发行公司债券的方案；
+第十五条.（七）. 本条款按照第八条.（十）.条款修订。制订公司合并、分立、变更公司形式、解散的方案；
+第十五条.（八）. 本条款按照第八条.（十）.条款修订。决定公司内部管理机构的设置；
+第十五条.（九）. 本条款按照第八条.（十）.条款修订。决定聘任或者解聘公司经理及其报酬事项，并根据经理的提名决定聘任或者解聘公司副经理、财务负责人及其 报酬事项；
+第十五条.（十）. 本条款按照第八条.（十）.条款修订。制定公司的基本管理制度；
+第十八条. 本条款按照第八条.（十）.条款修订。公司设经理，由董事会决定聘任或者解聘。经理对董事会负责，行使下列职权：
+第十八条.（一）. 本条款按照第八条.（十）.条款修订。主持公司的生产经营管理工作，组织实施董事会决议；
+第十八条.（二）. 本条款按照第八条.（十）.条款修订。组织实施公司年度经营计划和投资方案；
+第十八条.（三）. 本条款按照第八条.（十）.条款修订。拟订公司内部管理机构设置方案；
+第十八条.（四）. 本条款按照第八条.（十）.条款修订。拟订公司的基本管理制度；
+第十八条.（五）. 本条款按照第八条.（十）.条款修订。制定公司的基本管理制度；
+第十八条.（六）. 本条款按照第八条.（十）.条款修订。提请聘任或者解聘公司副经理、财务负责人；
+第十八条.（七）. 本条款按照第八条.（十）.条款修订。决定聘任或者解聘除应由董事会决定聘任或者解聘以外的负责管理人员；
+第十八条.（八）. 本条款按照第八条.（十）.条款修订。董事会授予的其他职权。
+第十八条. 本条款按照第八条.（十）.条款修订。经理列席董事会会议。
+第二十条. 本条款按照第八条.（十）.条款修订。监事行使下列职权：
+第二十条.（一）. 本条款按照第八条.（十）.条款修订。检查公司财务；
+第二十条.（二）. 本条款按照第八条.（十）.条款修订。对董事、高级管理人员执行公司职务的行为进行监督，对违反法律、行政法规、公司章程或者股东会决议的董 事、高级管理人员提出罢免的建议；
+第二十条.（三）. 本条款按照第八条.（十）.条款修订。当董事、高级管理人员的行为损害公司的利益时，要求董事、高级管理人员予以纠正；
+第二十条.（四）. 本条款按照第八条.（十）.条款修订。提议召开临时股东会会议，在董事会不履行本章程规定的召集和主持股东会会议职责时召集和主持股东会会议 ；
+第二十条.（五）. 本条款按照第八条.（十）.条款修订。向股东会会议提出提案；
+第二十条.（六）. 本条款按照第八条.（十）.条款修订。依照《公司法》第一百五十二条的规定，对董事、高级管理人员提起诉讼；
+第二十条. 本条款按照第八条.（十）.条款修订。监事可以列席董事会会议。
+
+Warning: missing space before text for line 6 of jade file "undefined"
+Warning: missing space before text for line 8 of jade file "undefined"
+Warning: missing space before text for line 10 of jade file "undefined"
+../view/term.2e4f11cb.html文件更新，内容如下:
+<html lang="zh-cn"><head><title>term html sample</title><script></script></head><body><h3>条款 2e4f11cb</h3><hr/><p>正文:</p><p>第八条. 本条款按照第八条.（十）.条款修订。股东会由全体股东组成，是公司的权力机构，行使下列职权：<br/>
+第八条.（一）. 本条款按照第八条.（十）.条款修订。决定公司的经营方针和投资计划；<br/>
+第八条.（二）. 本条款按照第八条.（十）.条款修订。选举和更换非由职工代表担任的董事、监事，决定有关董事、监事的报酬事项；<br/>
+第八条.（三）. 本条款按照第八条.（十）.条款修订。审议批准董事会的报告；<br/>
+第八条.（四）. 本条款按照第八条.（十）.条款修订。审议批准监事的报告；<br/>
+第八条.（五）. 本条款按照第八条.（十）.条款修订。审议批准公司的年度财务预算方案、决算方案；<br/>
+第八条.（六）. 本条款按照第八条.（十）.条款修订。审议批准公司的利润分配方案和弥补亏损的方案；<br/>
+第八条.（七）. 本条款按照第八条.（十）.条款修订。对公司增加或者减少注册资本作出决议；<br/>
+第八条.（八）. 本条款按照第八条.（十）.条款修订。对发行公司债券作出决议；<br/>
+第八条.（九）. 本条款按照第八条.（十）.条款修订。对公司合并、分立、解散、清算或者变更公司形式作出决议；<br/>
+第八条.（十）. 本条款按照本条款修订。修改公司章程；<br/>
+第十五条. 本条款按照第八条.（十）.条款修订。董事会行使下列职权：：<br/>
+第十五条.（一）. 本条款按照第八条.（十）.条款修订。负责召集股东会，并向股东会报告工作；<br/>
+第十五条.（二）. 本条款按照第八条.（十）.条款修订。执行股东会的决议；<br/>
+第十五条.（三）. 本条款按照第八条.（十）.条款修订。审定公司的经营计划和投资方案；<br/>
+第十五条.（四）. 本条款按照第八条.（十）.条款修订。制订公司的年度财务预算方案、决算方案；<br/>
+第十五条.（五）. 本条款按照第八条.（十）.条款修订。制订公司的利润分配方案和弥补亏损方案；<br/>
+第十五条.（六）. 本条款按照第八条.（十）.条款修订。制订公司增加或者减少注册资本以及发行公司债券的方案；<br/>
+第十五条.（七）. 本条款按照第八条.（十）.条款修订。制订公司合并、分立、变更公司形式、解散的方案；<br/>
+第十五条.（八）. 本条款按照第八条.（十）.条款修订。决定公司内部管理机构的设置；<br/>
+第十五条.（九）. 本条款按照第八条.（十）.条款修订。决定聘任或者解聘公司经理及其报酬事项，并根据经理的提名决定聘任或者解聘公司副经理、财务负责人及其 报酬事项；<br/>
+第十五条.（十）. 本条款按照第八条.（十）.条款修订。制定公司的基本管理制度；<br/>
+第十八条. 本条款按照第八条.（十）.条款修订。公司设经理，由董事会决定聘任或者解聘。经理对董事会负责，行使下列职权：<br/>
+第十八条.（一）. 本条款按照第八条.（十）.条款修订。主持公司的生产经营管理工作，组织实施董事会决议；<br/>
+第十八条.（二）. 本条款按照第八条.（十）.条款修订。组织实施公司年度经营计划和投资方案；<br/>
+第十八条.（三）. 本条款按照第八条.（十）.条款修订。拟订公司内部管理机构设置方案；<br/>
+第十八条.（四）. 本条款按照第八条.（十）.条款修订。拟订公司的基本管理制度；<br/>
+第十八条.（五）. 本条款按照第八条.（十）.条款修订。制定公司的基本管理制度；<br/>
+第十八条.（六）. 本条款按照第八条.（十）.条款修订。提请聘任或者解聘公司副经理、财务负责人；<br/>
+第十八条.（七）. 本条款按照第八条.（十）.条款修订。决定聘任或者解聘除应由董事会决定聘任或者解聘以外的负责管理人员；<br/>
+第十八条.（八）. 本条款按照第八条.（十）.条款修订。董事会授予的其他职权。<br/>
+第十八条. 本条款按照第八条.（十）.条款修订。经理列席董事会会议。<br/>
+第二十条. 本条款按照第八条.（十）.条款修订。监事行使下列职权：<br/>
+第二十条.（一）. 本条款按照第八条.（十）.条款修订。检查公司财务；<br/>
+第二十条.（二）. 本条款按照第八条.（十）.条款修订。对董事、高级管理人员执行公司职务的行为进行监督，对违反法律、行政法规、公司章程或者股东会决议的董 事、高级管理人员提出罢免的建议；<br/>
+第二十条.（三）. 本条款按照第八条.（十）.条款修订。当董事、高级管理人员的行为损害公司的利益时，要求董事、高级管理人员予以纠正；<br/>
+第二十条.（四）. 本条款按照第八条.（十）.条款修订。提议召开临时股东会会议，在董事会不履行本章程规定的召集和主持股东会会议职责时召集和主持股东会会议 ；<br/>
+第二十条.（五）. 本条款按照第八条.（十）.条款修订。向股东会会议提出提案；<br/>
+第二十条.（六）. 本条款按照第八条.（十）.条款修订。依照《公司法》第一百五十二条的规定，对董事、高级管理人员提起诉讼； <br/>
+第二十条. 本条款按照第八条.（十）.条款修订。监事可以列席董事会会议。<br/>
+</p><hr/></body></html>
+```
+
+- 多用了50分钟，已登记。
+- 追加todo项：
+      - '60': xuemen COD metadata-章程实施细则
+      - '90': xuemen COD metadata-S2状态下的部门模型
+
+---
+
+[top](#top) | [index](#index)
+<a id="20240505140000"></a>
+## 14:00~15:29
+根据新的term metadata，重新设计COM、deploy metadata。
+
+1. term定义条款和合同，包括正文、注释、层次结构、次序、修订关系，以及占位符、各级映射。
+1. COM定义共同体的模型：placeholder替换成中性词，列出各局部的多种可以互相替换、效果相近的term。各COD的部署和运行经验汇总到COM。
+1. deploy定义部署的初始条件、内部词汇和占位符的映射和term逐步生效的过程，期间可以有过渡性的条款或模型。
+1. COD定义共同体的实例。实例中出现的error和term汇总到建模者，也可以发布新的COM。
+1. error定义有效果偏差的term，以及有效果的term。索引位置暂定在allterm metadata。
+
+COM备选结构
+```
+name:
+id:
+interface:
+  <term.termid.entity.1>: value
+  <term.termid.entity.2>: value
+  <term.termid.asset.1>: value
+  <term.termid.term.1>: value
+  <term.termid.event.1>: value
+  <term.termid.localid.1>: value
+item:
+  level0:
+    permanent: //不可修订条款
+      - termid:
+        map:
+        readme: |
+      - termid:
+    self: //自修订条款
+      - termid:
+        map:
+        readme: |
+      - termid:
+  level1:
+    - upgradeby:
+      option:
+        - termid:
+          map:
+          readme: |
+        - termid:
+    - upgradeby: //对于开源信息可以解决的，可以用readme说明而不列出具体term。
+      readme:
+  level2:
+    - upgradeby:
+      option:
+        - termid:
+          map:
+          readme: |
+        - termid:
+```
+
+deploy备选结构
+```
+deploy:
+  init: 
+    - termid:
+      y: 
+        termid:
+        y:
+        n:
+        case:
+          - cod: id
+            log: |
+            readme: |
+        readme: |
+      n: 
+        errorid:
+        y:
+        n:
+    - errorid:
+      y: 
+        termid:
+        y:
+        n:
+        case:
+          - cod: id
+            log: |
+            readme: |
+        readme: |
+execution:
+
+readme: |
+effect:
+```
+
+还需要更多时间，追加一个todo项：
+- '195': 根据新的term metadata，重新设计COM、deploy、COD metadata，编辑出范例。
+---
+
+[top](#top) | [index](#index)
+<a id="20240505160000"></a>
+## 16:00~16:59
+term metadata的depend字段的内容写入term view
+
+- 清理term.js中与termset有关代码。
+- 在maketermtext()中添加depend、together、effect相关代码。
+- 调整了readme的嵌套次序，从倒序恢复到正序。
+- 实现了depend字段，执行效果：
+```
+---
+......
+readme:
+条款 2e4f11cb. 章程是公司的顶级规章。但它的条款在修订层次上并不平等。
+第十五条. 董事会是决策部门，在不同类型共同体中可能称为董事会、理事会、委员会等等。
+第十五条.（四）. 注意：新公司法已取消。
+
+---
+depend:
+条款 2e4f11cb.
+问题 0ccddb29,影响率50% 正文:
+出现以下情况之一：
+- 董事会未界定执行部门工作的合规性要求。
+- 董事会界定了执行部门工作的合规性要求。
+  - 执行部门成员对指令不进行合规检查，即使不合规也执行。
+  - 执行部门成员及下达指令者未按要求填写和提交表单，比如工单、日志。
+问题 0ccddb29 readme:
+- 下达指令者的指令包括对更早指令的掩盖，通过互相包庇产生系统性的对抗。
+- 公司曾经对下达指令者违约，以一定范围内的割据作为抵押物。这是历史上资源紧缺，无法兑现约定报酬的后遗症。
+- 把一定范围内的割据作为违约抵押物的情况，解除割据应该同时处理历史欠账。在公司设立阶段，就要确定是否符合资源不足，如果符合应该在设立时解决。
+第十五条.
+事项1,影响率50% :
+测试字符串: 中华人民共和国公司法生效。
+```
+
+追加一个todo项：
+- '60': term metadata的together,effect等字段的内容写入term view
+

release/time/d.20240506.md

@@ -0,0 +1,555 @@
+# 2024.05.06.
+日小结  
+
+<a id="top"></a>
+根据[ego模型时间接口](https://gitee.com/hyg/blog/blob/master/timeflow.md)，今天绑定模版2。
+
+<a id="index"></a>
+- 07:45	[根据新的term metadata，重新设计COM、deploy、COD metadata。](#20240506074500)  
+- 14:00	[整理章程实施细则](#20240506140000)  
+- 16:00	[term metadata的together,effect等字段的内容写入term view](#20240506160000)  
+
+---
+season stat:
+
+| task | alloc | sold | hold |
+| --- | --- | --- | --- |
+| total | 13275 | 7558 | 5717 |
+| PSMD | 7000 | 4146 | 2854 |
+| learn | 1000 | 312 | 688 |
+| ego | 3000 | 1994 | 1006 |
+| js | 1375 | 345 | 1030 |
+| xuemen | 600 | 581 | 19 |
+| raw | 300 | 150 | 150 |
+| infra | 0 | 30 | -30 |
+
+---
+
+waiting list:
+
+
+- 30分钟时间片：
+  - learn的第1号事项：学习 github actions和 workflows 的yaml语法
+  - raw的第1号事项：设计DRI metadata
+  - PSMD的第2号事项：了解Rules as Code (RaC)，准备在metadata中增加code字段。
+  - learn的第2号事项：YARRRML
+
+- 60分钟时间片：
+  - js的第1号事项：学习测试方法和工具
+  - ego的第1号事项：在node ego over时创建次日的计划，内容参考node ego plan输出。
+  - xuemen的第1号事项：五月报税
+  - js的第2号事项：promise对象和async/await
+
+- 90分钟时间片：
+  - PSMD的第1号事项：根据新的COM、deploy、COD metadata，编辑出范例。
+  - learn的第4号事项：把PSMD的data、src部分升级到rdf，如果升级成功则作为范例。
+  - PSMD的第8号事项：整理近期手稿。
+
+- 195分钟时间片：
+  - ego的第4号事项：在整理近期手稿之后，修订个人模型。
+  - PSMD的第6号事项：term + COM matedata -> deploy metadata -> deploy view
+
+---
+
+[top](#top) | [index](#index)
+<a id="20240506074500"></a>
+## 7:45~10:59
+根据新的term metadata，重新设计COM、deploy、COD metadata。
+
+###  COM
+COM定义共同体的模型：placeholder替换成中性词，列出各局部的多种可以互相替换、效果相近的term。各COD的部署和运行经验汇总到COM。
+
+- 主要以权力分配为主线。利益分配、角色任免关系是否需要单独定义，或者建立索引，实际使用后回顾。  
+
+实际使用：
+- loop term要不要有localid。
+    - 按修订层次排序应该固化吗，还是其中一种布局。
+    - 可互相替换的条款，肯定需要在COM而不是term中表达。
+- level0可以去掉，减少一层。
+- 可互相替换的条款，序号怎么定，互相引用关系怎么定。
+    - leveln.m
+- 新的提议：
+```
+name:
+id:
+modeler:
+  name:
+  id:
+  COM:
+  IRI: //代替其它字段
+interface:
+  <term.termid.entity.1>: value
+  <term.termid.entity.2>: value
+  <term.termid.asset.1>: value
+  <term.termid.term.1>: value
+  <term.termid.event.1>: value
+  <term.termid.localid.1>: value
+termmaker:
+  const: //不可修订条款
+    - termid:
+      map:
+      readme: |
+    - termid:
+  loop: //自修订条款
+    - termid:
+      map:
+      readme: |
+    - termid:
+  level1:
+    - upgradeby:
+      option:
+        - termid:
+          map:
+          readme: |
+        - termid:
+    - upgradeby: //对于开源信息可以解决的，可以用readme说明而不列出具体term。
+      readme:
+  level2:
+    - upgradeby:
+      option:
+        - termid:
+          map:
+          readme: |
+        - termid:
+termid: // not term maker
+```
+
+###  deploy
+deploy定义部署的初始条件、内部词汇和占位符的映射和term逐步生效的过程，期间可以有过渡性的条款或模型。
+
+- 部署过程应能自动生成专题讨论。
+  - 对外的专题讨论，使用COMinterface替换placeholder。
+  - 内部的专题讨论，使用interface替换placeholder。
+
+```
+name:
+id:
+COM:
+COMinterface:
+  <term.termid.entity.1>: value
+  <term.termid.entity.2>: value
+  <term.termid.asset.1>: value
+  <term.termid.term.1>: value
+  <term.termid.event.1>: value
+  <term.termid.localid.1>: value
+deployer: 
+  name:
+  id:
+  COM:
+  IRI: //代替其它字段
+interface:
+  <term.termid.entity.1>: value
+  <term.termid.entity.2>: value
+  <term.termid.asset.1>: value
+  <term.termid.term.1>: value
+  <term.termid.event.1>: value
+  <term.termid.localid.1>: value
+step:
+  - termid:
+    y: 
+      termid:
+      y:
+      n:
+      case:
+        - cod: id
+          log: |
+          readme: |
+      issue: //可以设计编号规则，单独另建专题（文件、文件夹或讨论区）。
+        name:
+        id:
+        path:
+      readme: |
+        //案例分析，发言素材，讨论推演。
+    n: 
+      errorid:
+      y:
+      n:
+        readme: |
+          deploy failure.
+          detail info...
+  - errorid:
+    y: 
+      termid:
+      y:
+      n:
+      case:
+        - cod: id
+          log: |
+          readme: |
+      readme: |
+readme: |
+logpath:
+```
+
+### COD
+COD定义共同体的实例。实例中出现的error和term汇总到建模者，也可以发布新的COM。
+
+- 应能自动生成专题讨论：
+  - 对外的专题讨论，使用COMinterface替换placeholder。
+  - 内部的专题讨论，使用interface替换placeholder。
+- 应能自动生成COM的主要信息，发布经验。
+```
+name:
+id:
+COM：
+deploy：
+COMinterface:
+  <term.termid.entity.1>: value
+  <term.termid.entity.2>: value
+  <term.termid.asset.1>: value
+  <term.termid.term.1>: value
+  <term.termid.event.1>: value
+  <term.termid.localid.1>: value
+interface:
+  <term.termid.entity.1>: value
+  <term.termid.entity.2>: value
+  <term.termid.asset.1>: value
+  <term.termid.term.1>: value
+  <term.termid.event.1>: value
+  <term.termid.localid.1>: value
+termid:
+logpath:
+```
+
+实际使用：
+- loop term要不要有localid。
+    - 按修订层次排序应该固化吗，还是其中一种布局。
+    - 可互相替换的条款，肯定需要在COM而不是term中表达。
+- level0可以去掉，减少一层。
+- 可互相替换的条款，序号怎么定，互相引用关系怎么定。
+    - leveln.m
+
+新的提议：
+```
+name:
+id:
+modeler:
+  name:
+  id:
+  COM:
+  IRI: //代替其它字段
+interface:
+  <term.termid.entity.1>: value
+  <term.termid.entity.2>: value
+  <term.termid.asset.1>: value
+  <term.termid.term.1>: value
+  <term.termid.event.1>: value
+  <term.termid.localid.1>: value
+termmaker:
+  const: //不可修订条款
+    - termid:
+      map:
+      readme: |
+    - termid:
+  loop: //自修订条款
+    - termid:
+      map:
+      readme: |
+    - termid:
+  level1:
+    - upgradeby:
+      option:
+        - termid:
+          map:
+          readme: |
+        - termid:
+    - upgradeby: //对于开源信息可以解决的，可以用readme说明而不列出具体term。
+      readme:
+  level2:
+    - upgradeby:
+      option:
+        - termid:
+          map:
+          readme: |
+        - termid:
+termid: // not term maker
+```
+
+追加todo项：
+- '90': 根据新的COM、deploy、COD metadata，编辑出范例。
+---
+
+[top](#top) | [index](#index)
+<a id="20240506140000"></a>
+## 14:00~15:29
+整理章程实施细则
+
+- 参考：
+    - xuemen库S2分支的内容
+    - cod.template/Vertebrate
+- 章程实施细则定位在基本管理制度，保留董事会职权，涉及股东会职权的条款列入附件，经理职权以下（含经理）的条款分离出来作为一般的工作。
+
+### 章程实施细则
+
+1. 股东会职权
+    1. 根据公司法第五十九条、章程第八条（一）决定：公司分为几种状态，由股东会决定状态数量、名称、当前状态。董事会行使公司法第六十七条（七）（八）（九）、章程第十五条（八）（九）（十）所列职权时须明确适用的状态，以便状态切换时自动启用。
+    1. 根据公司法第五十九条、章程第八条（一）决定：公司分为四种状态{S1：休眠，S2：增长，S3：稳定或缩减，S4：拓展}：
+    * S1：休眠状态
+        1. 根据公司法第五十七条决定：进入、离开S1状态时要编制财务会计报告。
+		1. 根据公司法第五十九条（一）、章程第八条（二）决定：在进入S1状态时，由股东会选举一名执行董事，执行董事兼任公司经理。执行董事不定期向全体股东报告工作。
+        1. 根据公司法第五十九条（四）、章程第八条（六）决定：
+          - S1状态下出现赤字时，支出由执行董事垫付，记为公司向个人借款；
+          - 离开S1状态时，，由股东会重建董事会，股东会授权董事会决定补偿方案：
+			* 公司向执行董事借款的利息及偿还方案；
+			* 执行董事所承担工作的报酬。
+	  * S2：增长状态
+		1. 根据公司法第五十七条决定：S2状态下董事会可以根据公司法第七十四条对经理授权，并规定行使这些职权的方式和时限，以及相应的奖惩办法。
+      * S3：稳定或缩减状态
+        1. 根据公司法第五十七条决定：S3状态下公司法第七十四条部分内容、章程第十八条（八）调整，董事会不得在章程以外对经理授权，经理及由经理提名、聘任的人员都严格按章程和基本管理制度、数学模型工作。
+        1. 根据公司法第五十七条决定：S3状态下的数学模型及其代码实现属于基本管理制度，按公司法第六十七条（九）制定，这项职权不得对外授权。
+	  * S4：拓展状态
+		1. 新业务按照“发展状态”运行。
+		1. 各业务公用的管理规章和数学模型、代码实现，按照“稳定或缩减状态”运行。
+1. 董事会职权
+    1. 在S2、S3状态下：设置产品部(IPU:Inner Product Unit)的规章制度，参与JPU（Joint Product Unit）。
+    1. 在S2、S3状态下：设置内务部(ISU:Inner Service Unit)，委托ISU管理公司的资产（办公室、服务器及域名、人民币、内部记账单位、知识产权）。
+    1. 在S2状态下：无人承担的任务均由经理承担。当这种情形发生时，按300%计算报酬。
+    1. 在S2状态下：经理每个月向监事、董事会书面汇报工作。
+    1. 在S3状态下：董事、监事可以调阅规章制度、数学模型的代码实现。
+
+已追加todo项。
+---
+
+[top](#top) | [index](#index)
+<a id="20240506160000"></a>
+## 16:00~16:59
+term metadata的together,effect等字段的内容写入term view
+
+- 参考depend字段的代码，很容易实现。
+- 在三级条款中随机插入了一些together和effect字段。
+
+执行结果：
+```
+
+D:\huangyg\git\PSMD\src>node term term 2e4f11cb
+enter maketermtext:2e4f11cb     prefix:
+enter maketermtext:e55c000c     prefix:第八条.
+enter maketermtext:a540486e     prefix:第八条.（一）.
+enter maketermtext:21af48dd     prefix:第八条.（二）.
+enter maketermtext:8b839d59     prefix:第八条.（三）.
+enter maketermtext:0b305ce2     prefix:第八条.（四）.
+enter maketermtext:53548d2d     prefix:第八条.（五）.
+enter maketermtext:040463e3     prefix:第八条.（六）.
+enter maketermtext:460c6741     prefix:第八条.（七）.
+enter maketermtext:393c92a3     prefix:第八条.（八）.
+enter maketermtext:f3cc3036     prefix:第八条.（九）.
+enter maketermtext:62c421f2     prefix:第八条.（十）.
+enter maketermtext:25c83dac     prefix:第十五条.
+enter maketermtext:f64809f8     prefix:第十五条.（一）.
+enter maketermtext:69632214     prefix:第十五条.（二）.
+enter maketermtext:423005c6     prefix:第十五条.（三）.
+enter maketermtext:615fc73f     prefix:第十五条.（四）.
+enter maketermtext:09ead2c1     prefix:第十五条.（五）.
+enter maketermtext:50430bca     prefix:第十五条.（六）.
+enter maketermtext:bb0ea239     prefix:第十五条.（七）.
+enter maketermtext:79f4f1e0     prefix:第十五条.（八）.
+enter maketermtext:5884eea5     prefix:第十五条.（九）.
+enter maketermtext:7957be41     prefix:第十五条.（十）.
+enter maketermtext:4bbd5668     prefix:第十八条.
+enter maketermtext:3f89e98f     prefix:第十八条.（一）.
+enter maketermtext:2a25389c     prefix:第十八条.（二）.
+enter maketermtext:b3012036     prefix:第十八条.（三）.
+enter maketermtext:f81cd0f0     prefix:第十八条.（四）.
+enter maketermtext:c73b28b3     prefix:第十八条.（五）.
+enter maketermtext:500e281d     prefix:第十八条.（六）.
+enter maketermtext:dd706d9c     prefix:第十八条.（七）.
+enter maketermtext:a2804f8b     prefix:第十八条.（八）.
+enter maketermtext:6208f678     prefix:第二十条.
+enter maketermtext:b96e83c2     prefix:第二十条.（一）.
+enter maketermtext:99520853     prefix:第二十条.（二）.
+enter maketermtext:5fec38ed     prefix:第二十条.（三）.
+enter maketermtext:c0eb6977     prefix:第二十条.（四）.
+enter maketermtext:aa469da0     prefix:第二十条.（五）.
+enter maketermtext:f732b768     prefix:第二十条.（六）.
+../view/term.2e4f11cb.md文件更新，内容如下:
+条款 2e4f11cb 正文:
+第八条. 本条款按照第八条.（十）.条款修订。股东会由全体股东组成，是公司的权力机构，行使下列职权：
+第八条.（一）. 本条款按照第八条.（十）.条款修订。决定公司的经营方针和投资计划；
+第八条.（二）. 本条款按照第八条.（十）.条款修订。选举和更换非由职工代表担任的董事、监事，决定有关董事、监事的报酬事项；
+第八条.（三）. 本条款按照第八条.（十）.条款修订。审议批准董事会的报告；
+第八条.（四）. 本条款按照第八条.（十）.条款修订。审议批准监事的报告；
+第八条.（五）. 本条款按照第八条.（十）.条款修订。审议批准公司的年度财务预算方案、决算方案；
+第八条.（六）. 本条款按照第八条.（十）.条款修订。审议批准公司的利润分配方案和弥补亏损的方案；
+第八条.（七）. 本条款按照第八条.（十）.条款修订。对公司增加或者减少注册资本作出决议；
+第八条.（八）. 本条款按照第八条.（十）.条款修订。对发行公司债券作出决议；
+第八条.（九）. 本条款按照第八条.（十）.条款修订。对公司合并、分立、解散、清算或者变更公司形式作出决议；
+第八条.（十）. 本条款按照本条款修订。修改公司章程；
+第十五条. 本条款按照第八条.（十）.条款修订。董事会行使下列职权：：
+第十五条.（一）. 本条款按照第八条.（十）.条款修订。负责召集股东会，并向股东会报告工作；
+第十五条.（二）. 本条款按照第八条.（十）.条款修订。执行股东会的决议；
+第十五条.（三）. 本条款按照第八条.（十）.条款修订。审定公司的经营计划和投资方案；
+第十五条.（四）. 本条款按照第八条.（十）.条款修订。制订公司的年度财务预算方案、决算方案；
+第十五条.（五）. 本条款按照第八条.（十）.条款修订。制订公司的利润分配方案和弥补亏损方案；
+第十五条.（六）. 本条款按照第八条.（十）.条款修订。制订公司增加或者减少注册资本以及发行公司债券的方案；
+第十五条.（七）. 本条款按照第八条.（十）.条款修订。制订公司合并、分立、变更公司形式、解散的方案；
+第十五条.（八）. 本条款按照第八条.（十）.条款修订。决定公司内部管理机构的设置；
+第十五条.（九）. 本条款按照第八条.（十）.条款修订。决定聘任或者解聘公司经理及其报酬事项，并根据经理的提名决定聘任或者解聘公司副经理、财务负责人及其 报酬事项；
+第十五条.（十）. 本条款按照第八条.（十）.条款修订。制定公司的基本管理制度；
+第十八条. 本条款按照第八条.（十）.条款修订。公司设经理，由董事会决定聘任或者解聘。经理对董事会负责，行使下列职权：
+第十八条.（一）. 本条款按照第八条.（十）.条款修订。主持公司的生产经营管理工作，组织实施董事会决议；
+第十八条.（二）. 本条款按照第八条.（十）.条款修订。组织实施公司年度经营计划和投资方案；
+第十八条.（三）. 本条款按照第八条.（十）.条款修订。拟订公司内部管理机构设置方案；
+第十八条.（四）. 本条款按照第八条.（十）.条款修订。拟订公司的基本管理制度；
+第十八条.（五）. 本条款按照第八条.（十）.条款修订。制定公司的基本管理制度；
+第十八条.（六）. 本条款按照第八条.（十）.条款修订。提请聘任或者解聘公司副经理、财务负责人；
+第十八条.（七）. 本条款按照第八条.（十）.条款修订。决定聘任或者解聘除应由董事会决定聘任或者解聘以外的负责管理人员；
+第十八条.（八）. 本条款按照第八条.（十）.条款修订。董事会授予的其他职权。
+第十八条.（八）. 本条款按照第八条.（十）.条款修订。经理列席董事会会议。
+第二十条. 本条款按照第八条.（十）.条款修订。监事行使下列职权：
+第二十条.（一）. 本条款按照第八条.（十）.条款修订。检查公司财务；
+第二十条.（二）. 本条款按照第八条.（十）.条款修订。对董事、高级管理人员执行公司职务的行为进行监督，对违反法律、行政法规、公司章程或者股东会决议的董 事、高级管理人员提出罢免的建议；
+第二十条.（三）. 本条款按照第八条.（十）.条款修订。当董事、高级管理人员的行为损害公司的利益时，要求董事、高级管理人员予以纠正；
+第二十条.（四）. 本条款按照第八条.（十）.条款修订。提议召开临时股东会会议，在董事会不履行本章程规定的召集和主持股东会会议职责时召集和主持股东会会议 ；
+第二十条.（五）. 本条款按照第八条.（十）.条款修订。向股东会会议提出提案；
+第二十条.（六）. 本条款按照第八条.（十）.条款修订。依照《公司法》第一百五十二条的规定，对董事、高级管理人员提起诉讼；
+第二十条.（六）. 本条款按照第八条.（十）.条款修订。监事可以列席董事会会议。
+
+---
+readme:
+条款 2e4f11cb. 章程是公司的顶级规章。但它的条款在修订层次上并不平等。
+第十五条. 董事会是决策部门，在不同类型共同体中可能称为董事会、理事会、委员会等等。
+第十五条.（四）. 注意：新公司法已取消。
+
+---
+depend:
+条款 2e4f11cb.
+问题 0ccddb29,影响率50% 正文:
+出现以下情况之一：
+- 董事会未界定执行部门工作的合规性要求。
+- 董事会界定了执行部门工作的合规性要求。
+  - 执行部门成员对指令不进行合规检查，即使不合规也执行。
+  - 执行部门成员及下达指令者未按要求填写和提交表单，比如工单、日志。
+问题 0ccddb29 readme:
+- 下达指令者的指令包括对更早指令的掩盖，通过互相包庇产生系统性的对抗。
+- 公司曾经对下达指令者违约，以一定范围内的割据作为抵押物。这是历史上资源紧缺，无法兑现约定报酬的后遗症。
+- 把一定范围内的割据作为违约抵押物的情况，解除割据应该同时处理历史欠账。在公司设立阶段，就要确定是否符合资源不足，如果符合应该在设立时解决。
+第十五条.
+事项1,影响率50% :
+测试字符串: 中华人民共和国公司法生效。
+第十五条.（六）.
+问题 cde3c3e2,影响率70% 正文:
+违规收益超过违规成本。违规造成的既成事实被接受。
+问题 cde3c3e2 readme:
+
+---
+together:
+条款 2e4f11cb.
+问题 48291d8c,影响率90% 正文:
+共同体涉及未来收入的承诺，无法保证兑现。因此，无法使用未来收入换取当下资源，只能以现有资源进行交易。
+问题 48291d8c readme:
+可能的原因包括：
+  - 共同体内部废除该承诺，可能成为有效力的决议；
+  - 共同体内部对同一笔未来收入安排其它用途，可能成为有效力的预算案。
+第十五条.
+事项1,影响率90% :
+测试字符串：<term.25c83dac.term.1>是条款之王。
+第十五条.（六）.
+事项1,影响率30% :
+测试字符串：<term.50430bca.asset.2>融资成本低。
+
+---
+effect:
+条款 2e4f11cb.
+问题 cde3c3e2,有效率60% 正文:
+违规收益超过违规成本。违规造成的既成事实被接受。
+问题 cde3c3e2 readme:
+第十五条.
+问题 cde3c3e2,有效率50% 正文:
+违规收益超过违规成本。违规造成的既成事实被接受。
+问题 cde3c3e2 readme:
+第十五条.（六）.
+事项1,有效率40% :
+测试字符串: <term.50430bca.asset.1>不足。
+
+Warning: missing space before text for line 6 of jade file "undefined"
+Warning: missing space before text for line 8 of jade file "undefined"
+Warning: missing space before text for line 10 of jade file "undefined"
+../view/term.2e4f11cb.html文件更新，内容如下:
+<html lang="zh-cn"><head><title>term html sample</title><script></script></head><body><h3>条款 2e4f11cb</h3><hr/><p>正文:</p><p>第八条. 本条款按照第八条.（十）.条款修订。股东会由全体股东组成，是公司的权力机构，行使下列职权：<br/>
+第八条.（一）. 本条款按照第八条.（十）.条款修订。决定公司的经营方针和投资计划；<br/>
+第八条.（二）. 本条款按照第八条.（十）.条款修订。选举和更换非由职工代表担任的董事、监事，决定有关董事、监事的报酬事项；<br/>
+第八条.（三）. 本条款按照第八条.（十）.条款修订。审议批准董事会的报告；<br/>
+第八条.（四）. 本条款按照第八条.（十）.条款修订。审议批准监事的报告；<br/>
+第八条.（五）. 本条款按照第八条.（十）.条款修订。审议批准公司的年度财务预算方案、决算方案；<br/>
+第八条.（六）. 本条款按照第八条.（十）.条款修订。审议批准公司的利润分配方案和弥补亏损的方案；<br/>
+第八条.（七）. 本条款按照第八条.（十）.条款修订。对公司增加或者减少注册资本作出决议；<br/>
+第八条.（八）. 本条款按照第八条.（十）.条款修订。对发行公司债券作出决议；<br/>
+第八条.（九）. 本条款按照第八条.（十）.条款修订。对公司合并、分立、解散、清算或者变更公司形式作出决议；<br/>
+第八条.（十）. 本条款按照本条款修订。修改公司章程；<br/>
+第十五条. 本条款按照第八条.（十）.条款修订。董事会行使下列职权：：<br/>
+第十五条.（一）. 本条款按照第八条.（十）.条款修订。负责召集股东会，并向股东会报告工作；<br/>
+第十五条.（二）. 本条款按照第八条.（十）.条款修订。执行股东会的决议；<br/>
+第十五条.（三）. 本条款按照第八条.（十）.条款修订。审定公司的经营计划和投资方案；<br/>
+第十五条.（四）. 本条款按照第八条.（十）.条款修订。制订公司的年度财务预算方案、决算方案；<br/>
+第十五条.（五）. 本条款按照第八条.（十）.条款修订。制订公司的利润分配方案和弥补亏损方案；<br/>
+第十五条.（六）. 本条款按照第八条.（十）.条款修订。制订公司增加或者减少注册资本以及发行公司债券的方案；<br/>
+第十五条.（七）. 本条款按照第八条.（十）.条款修订。制订公司合并、分立、变更公司形式、解散的方案；<br/>
+第十五条.（八）. 本条款按照第八条.（十）.条款修订。决定公司内部管理机构的设置；<br/>
+第十五条.（九）. 本条款按照第八条.（十）.条款修订。决定聘任或者解聘公司经理及其报酬事项，并根据经理的提名决定聘任或者解聘公司副经理、财务负责人及其 报酬事项；<br/>
+第十五条.（十）. 本条款按照第八条.（十）.条款修订。制定公司的基本管理制度；<br/>
+第十八条. 本条款按照第八条.（十）.条款修订。公司设经理，由董事会决定聘任或者解聘。经理对董事会负责，行使下列职权：<br/>
+第十八条.（一）. 本条款按照第八条.（十）.条款修订。主持公司的生产经营管理工作，组织实施董事会决议；<br/>
+第十八条.（二）. 本条款按照第八条.（十）.条款修订。组织实施公司年度经营计划和投资方案；<br/>
+第十八条.（三）. 本条款按照第八条.（十）.条款修订。拟订公司内部管理机构设置方案；<br/>
+第十八条.（四）. 本条款按照第八条.（十）.条款修订。拟订公司的基本管理制度；<br/>
+第十八条.（五）. 本条款按照第八条.（十）.条款修订。制定公司的基本管理制度；<br/>
+第十八条.（六）. 本条款按照第八条.（十）.条款修订。提请聘任或者解聘公司副经理、财务负责人；<br/>
+第十八条.（七）. 本条款按照第八条.（十）.条款修订。决定聘任或者解聘除应由董事会决定聘任或者解聘以外的负责管理人员；<br/>
+第十八条.（八）. 本条款按照第八条.（十）.条款修订。董事会授予的其他职权。<br/>
+第十八条.（八）. 本条款按照第八条.（十）.条款修订。经理列席董事会会议。<br/>
+第二十条. 本条款按照第八条.（十）.条款修订。监事行使下列职权：<br/>
+第二十条.（一）. 本条款按照第八条.（十）.条款修订。检查公司财务；<br/>
+第二十条.（二）. 本条款按照第八条.（十）.条款修订。对董事、高级管理人员执行公司职务的行为进行监督，对违反法律、行政法规、公司章程或者股东会决议的董 事、高级管理人员提出罢免的建议；<br/>
+第二十条.（三）. 本条款按照第八条.（十）.条款修订。当董事、高级管理人员的行为损害公司的利益时，要求董事、高级管理人员予以纠正；<br/>
+第二十条.（四）. 本条款按照第八条.（十）.条款修订。提议召开临时股东会会议，在董事会不履行本章程规定的召集和主持股东会会议职责时召集和主持股东会会议 ；<br/>
+第二十条.（五）. 本条款按照第八条.（十）.条款修订。向股东会会议提出提案；<br/>
+第二十条.（六）. 本条款按照第八条.（十）.条款修订。依照《公司法》第一百五十二条的规定，对董事、高级管理人员提起诉讼； <br/>
+第二十条.（六）. 本条款按照第八条.（十）.条款修订。监事可以列席董事会会议。<br/>
+</p><hr/><p>注释:</p><p>章程是公司的顶级规章。但它的条款在修订层次上并不平等。<br/>
+第十五条. 董事会是决策部门，在不同类型共同体中可能称为董事会、理事会、委员会等等。<br/>
+第十五条.（四）. 注意：新公司法已取消。<br/>
+</p><hr/><p>前提:</p><p>问题 0ccddb29,影响率50% 正文:  <br/>
+出现以下情况之一：<br/>
+- 董事会未界定执行部门工作的合规性要求。<br/>
+- 董事会界定了执行部门工作的合规性要求。<br/>
+  - 执行部门成员对指令不进行合规检查，即使不合规也执行。<br/>
+  - 执行部门成员及下达指令者未按要求填写和提交表单，比如工单、日志。<br/>
+问题 0ccddb29 readme:<br/>
+- 下达指令者的指令包括对更早指令的掩盖，通过互相包庇产生系统性的对抗。<br/>
+- 公司曾经对下达指令者违约，以一定范围内的割据作为抵押物。这是历史上资源紧缺，无法兑现约定报酬的后遗症。<br/>
+- 把一定范围内的割据作为违约抵押物的情况，解除割据应该同时处理历史欠账。在公司设立阶段，就要确定是否符合资源不足，如果符合应该在设立时解决。<br/>
+第十五条.<br/>
+事项1,影响率50% :<br/>
+测试字符串: 中华人民共和国公司法生效。<br/>
+第十五条.（六）.<br/>
+问题 cde3c3e2,影响率70% 正文:  <br/>
+违规收益超过违规成本。违规造成的既成事实被接受。<br/>
+问题 cde3c3e2 readme:<br/>
+</p><hr/><p>同步解决:</p><p>问题 48291d8c,影响率90% 正文:  <br/>
+共同体涉及未来收入的承诺，无法保证兑现。因此，无法使用未来收入换取当下资源，只能以现有资源进行交易。<br/>
+问题 48291d8c readme:<br/>
+可能的原因包括：<br/>
+  - 共同体内部废除该承诺，可能成为有效力的决议；<br/>
+  - 共同体内部对同一笔未来收入安排其它用途，可能成为有效力的预算案。<br/>
+第十五条.<br/>
+事项1,影响率90% :<br/>
+测试字符串：<term.25c83dac.term.1>是条款之王。<br/>
+第十五条.（六）.<br/>
+事项1,影响率30% :<br/>
+测试字符串：<term.50430bca.asset.2>融资成本低。<br/>
+</p><hr/><p>效果:</p><p>问题 48291d8c,影响率90% 正文:  <br/>
+共同体涉及未来收入的承诺，无法保证兑现。因此，无法使用未来收入换取当下资源，只能以现有资源进行交易。<br/>
+问题 48291d8c readme:<br/>
+可能的原因包括：<br/>
+  - 共同体内部废除该承诺，可能成为有效力的决议；<br/>
+  - 共同体内部对同一笔未来收入安排其它用途，可能成为有效力的预算案。<br/>
+第十五条.<br/>
+事项1,影响率90% :<br/>
+测试字符串：<term.25c83dac.term.1>是条款之王。<br/>
+第十五条.（六）.<br/>
+事项1,影响率30% :<br/>
+测试字符串：<term.50430bca.asset.2>融资成本低。<br/>
+</p><hr/></body></html>
+```
+
+登记20分钟。余下时间回到COD metadata的范例。

release/time/d.20240507.md

@@ -0,0 +1,259 @@
+# 2024.05.07.
+日小结  
+
+<a id="top"></a>
+根据[ego模型时间接口](https://gitee.com/hyg/blog/blob/master/timeflow.md)，今天绑定模版1。
+
+<a id="index"></a>
+- 07:45	[学习测试方法和工具](#20240507074500)  
+- 09:30	[根据新的COM、deploy、COD metadata，编辑出范例。](#20240507093000)  
+- 14:00	[学习 github actions和 workflows 的yaml语法](#20240507140000)  
+- 14:30	[设计DRI metadata](#20240507143000)  
+- 16:00	[在node ego over时创建次日的计划，内容参考node ego plan输出。](#20240507160000)  
+
+---
+season stat:
+
+| task | alloc | sold | hold |
+| --- | --- | --- | --- |
+| total | 13275 | 7828 | 5447 |
+| PSMD | 7000 | 4236 | 2764 |
+| learn | 1000 | 342 | 658 |
+| ego | 3000 | 2054 | 946 |
+| js | 1375 | 405 | 970 |
+| xuemen | 600 | 581 | 19 |
+| raw | 300 | 180 | 120 |
+| infra | 0 | 30 | -30 |
+
+---
+
+waiting list:
+
+
+- 30分钟时间片：
+  - js的第2号事项：学习AMD规范，如果适用就开发范例
+  - ego的第2号事项：整理废弃git库，包括本地和远程。
+  - learn的第2号事项：YARRRML
+  - PSMD的第3号事项：了解Rules as Code (RaC)，准备在metadata中增加code字段。
+
+- 60分钟时间片：
+  - PSMD的第1号事项：使用1609模型实际编写COM、deploy、COD的metadata
+  - js的第1号事项：学习promise对象和async/await
+  - ego的第1号事项：在season metadata中实现浮动时间表，修改日计划功能。
+  - learn的第1号事项：github的actions,workflow,job脚本语法
+
+- 90分钟时间片：
+  - xuemen的第1号事项：整理章程实施细则的metedata
+  - PSMD的第2号事项：term metadata生成按修订层级排版的COM metadata。
+  - xuemen的第3号事项：整理S2状态下基本管理制度的metedata
+  - learn的第7号事项：把PSMD的data、src部分升级到rdf，如果升级成功则作为范例。
+
+- 195分钟时间片：
+  - xuemen的第2号事项：整理S2状态下基本管理制度
+  - ego的第3号事项：在整理近期手稿之后，修订个人模型。
+  - PSMD的第7号事项：term + COM matedata -> deploy metadata -> deploy view
+
+---
+
+[top](#top) | [index](#index)
+<a id="20240507074500"></a>
+## 7:45~8:44
+学习测试方法和工具
+
+- https://juejin.cn/post/6907555445628469255
+- https://nodejs.cn/api/test.html
+- https://zhuanlan.zhihu.com/p/26034302
+- 目前的单元设计得太大，输出输入数据太大太复杂，不利于单元测试。实践的话从jest入手
+    - https://www.jestjs.cn/
+    - https://segmentfault.com/a/1190000040539268
+- 前端测试有必要，如果实践的话从testcafe入手。
+    - https://testcafe.io/
+
+```
+【阿里云】尊敬的hi10386515@aliyun.com：日常工作中开发者常见的诉求和痛点，比如单元测试编写比较费时间；接手新的代码库，一些祖传代码理解成本高；排查问题查资料要跳转到浏览器，并且很难找到合适的答案。推荐一款 AI 编程工具通义灵码，下载量超 350 万。一个新项目如何快速启动，如何维护遗留系统代码库？点击下方链接，立即体验！https://t.aliyun.com/U/nQHLZC 拒收请回复R
+```
+
+在learn task下追加两个todo项：
+    - '60': 在util库进行单元测试，在实践中学习。
+    - '30': 寻找测试做得比较好的开源软件，作为学习单元划分和测试的实例。
+---
+
+[top](#top) | [index](#index)
+<a id="20240507093000"></a>
+##  9:30~10:59
+根据新的COM、deploy、COD metadata，编辑范例。
+
+- 根据昨天  draft\2024\05\20240506140000.md 修订的章程实施细则，重新整理COD使用的term。
+
+董事部分metadata：
+```
+D:\huangyg\git\PSMD\src>node term commit
+......
+commit term.1.yaml
+产品部(IPU:Inner Product Unit) a419e125
+...
+commit term.11.yaml
+学门科技 e6f0caec
+commit term.2.yaml
+内务部(ISU:Inner Service Unit) 0719e045
+commit term.3.yaml
+经理在S2的保底责任 c6e8bb3f
+commit term.4.yaml
+经理在S2的汇报 4d2e92b6
+commit term.5.yaml
+代码的调阅权限 41e708f1
+commit term.6.yaml
+章程实施细则-董事会决议 44f7a3ac
+../data/term.a419e125.yaml文件已更新。../data/term.1.yaml可以删除。
+../data/term.0719e045.yaml文件已更新。../data/term.2.yaml可以删除。
+../data/term.c6e8bb3f.yaml文件已更新。../data/term.3.yaml可以删除。
+../data/term.4d2e92b6.yaml文件已更新。../data/term.4.yaml可以删除。
+../data/term.41e708f1.yaml文件已更新。../data/term.5.yaml可以删除。
+../data/term.44f7a3ac.yaml文件已更新。../data/term.6.yaml可以删除。
+...
+../data/term.e6f0caec.yaml文件已更新。../data/term.11.yaml可以删除。
+...
+
+D:\huangyg\git\PSMD\src>node term term 44f7a3ac
+enter maketermtext:44f7a3ac     prefix:
+enter maketermtext:a419e125     prefix:1.
+enter maketermtext:0719e045     prefix:2.
+enter maketermtext:c6e8bb3f     prefix:3.
+enter maketermtext:4d2e92b6     prefix:4.
+enter maketermtext:41e708f1     prefix:5.
+../view/term.44f7a3ac.md文件更新，内容如下:
+条款 44f7a3ac 正文:
+1. 本条款按照章程.第十五条.（八）.条款修订。在S2（增长状态）、S3（稳定或缩减状态）状态下：公司设置产品部(IPU:Inner Product Unit)，负责参与JPU（Joint Product Unit）。
+2. 本条款按照章程.第十五条.（八）.条款修订。在S2（增长状态）、S3（稳定或缩减状态）状态下：公司设置内务部(ISU:Inner Service Unit)，委托内务部(ISU:Inner Service Unit)管理公司的资产（办公室、服务器及域名、人民币、内部记账单位、知识产权）。
+3. 本条款按照章程.第十五条.（八）.条款修订。在S2（增长状态）状态下：无人承担的任务均由经理承担。当这种情形发生时，按300%计算报酬。
+4. 本条款按照章程.第十五条.（八）.条款修订。在S2（增长状态）状态下：经理每个月向监事、董事会书面汇报工作。
+5. 本条款按照章程.第十五条.（八）.条款修订。在S3（稳定或缩减状态）状态下：董事、监事可以调阅规章制度、数学模型的代码实现。
+
+Warning: missing space before text for line 6 of jade file "undefined"
+Warning: missing space before text for line 8 of jade file "undefined"
+Warning: missing space before text for line 10 of jade file "undefined"
+../view/term.44f7a3ac.html文件更新，内容如下:
+<html lang="zh-cn"><head><title>term html sample</title><script></script></head><body><h3>条款 44f7a3ac</h3><hr/><p>正文:</p><p>1. 本条款按照章程.第十五条.（八）.条款修订。在S2（增长状态）、S3（稳定或缩减状态）状态下：公司设置产品部(IPU:Inner Product Unit)，负责参与JPU（Joint Product Unit）。<br/>
+2. 本条款按照章程.第十五条.（八）.条款修订。在S2（增长状态）、S3（稳定或缩减状态）状态下：公司设置内务部(ISU:Inner Service Unit)，委托内务部(ISU:Inner Service Unit)管理公司的资产（办公室、服务器及域名、人民币、内部记账单位、知识产权）。<br/>
+3. 本条款按照章程.第十五条.（八）.条款修订。在S2（增长状态）状态下：无人承担的任务均由经理承担。当这种情形发生时，按300%计算报酬。<br/>
+4. 本条款按照章程.第十五条.（八）.条款修订。在S2（增长状态）状态下：经理每个月向监事、董事会书面汇报工作。<br/>
+5. 本条款按照章程.第十五条.（八）.条款修订。在S3（稳定或缩减状态）状态下：董事、监事可以调阅规章制度、数学模型的代码实现。<br/>
+</p><hr/></body></html>
+```
+
+- 不少时间用在条款的微小修改上，没有能专注完成metadata的范例（哪怕是假内容的条款）。增加todo项：
+    - '60': 使用1609模型实际编写COM、deploy、COD的metadata
+      readme: 重点在于验证metadata的结构，如果时间不足可以使用虚构内容。
+- 新的条款架构对规章的要求提高了不少，需要充足时间去仔细推敲。追加几个todo项：
+    - '90': 整理章程实施细则的metedata
+    - '195': 整理S2状态下基本管理制度
+    - '90': 整理S2状态下基本管理制度的metedata
+---
+
+[top](#top) | [index](#index)
+<a id="20240507140000"></a>
+## 14:00~14:29
+学习 github actions和 workflows 的yaml语法
+
+学习了 https://docs.github.com/zh/actions/creating-actions/metadata-syntax-for-github-actions 从name到steps字段的语法。
+
+追加60分钟时间片：
+    - '60': github的actions,workflow,job脚本语法
+      readme: |
+        - https://docs.github.com/zh/actions/using-workflows/workflow-syntax-for-github-actions
+        - https://docs.github.com/zh/actions/creating-actions/metadata-syntax-for-github-actions
+        - https://docs.github.com/zh/actions/learn-github-actions/finding-and-customizing-actions
+
+---
+
+[top](#top) | [index](#index)
+<a id="20240507143000"></a>
+## 14:30~14:59
+设计DRI metadata
+
+参考：https://zhuanlan.zhihu.com/p/670956634  
+
+- DRIs（dietary reference intakes）的意思是“膳食营养素参考摄入量”。包括：
+    - RNI（Recommended Nutrient Intake） 推荐摄入量
+    - EAR（Estimated Average Requirement）平均需要量
+    - AI（Adequate Intake）适宜摄入量
+    - UL（Tolerated Upper Intake Lever）可耐受最高摄入量
+    - AMDR 宏量营养素可接受范围
+    - PI—NCD 预防慢性传染性疾病的建议摄入量
+    - SPL 特定建议值
+-NRV是英文nutrient reference values
+    - 以某套DRIs为默认值。
+    - 对部分营养成分设定具体摄入目标，覆盖默认值。
+
+DRIs.name.yaml
+```
+name:
+gender:
+age:
+weight:
+element:
+  热量:
+    RNI:
+    EAR:
+    AI:
+    UL:
+    AMDRmin:
+    AMDRmax:
+    PI_NCD:
+    SPL:
+    unit:
+  蛋白质:
+    ...
+```
+
+NRV.name.yaml
+```
+name:
+DRIs:
+element:
+  热量:
+    amount:
+    unit:
+  蛋白质:
+    amount:
+    unit:
+```
+---
+
+[top](#top) | [index](#index)
+<a id="20240507160000"></a>
+## 16:00~16:59
+在node ego over时创建次日的计划，内容参考node ego plan输出。
+
+- 在 finish.js 增加 maketomorowinfo()
+
+执行结果：
+```
+D:\huangyg\git\ego\src>node ego day over
+......
+dayinfo file name:
+../../blog/release/time/d.20240508.md
+content:
+# 2024.05.08.
+
+根据[ego模型时间接口](https://gitee.com/hyg/blog/blob/master/timeflow.md)，每天早起根据身心状况绑定模版。
+
+---
+如果绑定模版1可能安排以下任务：
+
+- 07:45 学习promise对象和async/await -js[0]
+- 09:30 term metadata生成按修订层级排版的COM metadata。 -PSMD[0]
+- 14:00 了解Rules as Code (RaC)，准备在metadata中增加code字段。 -PSMD[1]
+- 14:30 学习AMD规范，如果适用就开发范例 -js[1]
+- 16:00 在season metadata中实现浮动时间表，修改日计划功能。 -ego[0]
+
+---
+如果绑定模版2可能安排以下任务：
+
+- 07:45 在整理近期手稿之后，修订个人模型。 -ego[2]
+- 14:00 term metadata生成按修订层级排版的COM metadata。 -PSMD[0]
+- 16:00 学习promise对象和async/await -js[0]
+
+---
+对任务排序的建议可以联系<huangyg@mrs22.com>，日计划确定后会在本页面发布。
+```

release/time/d.20240509.md

@@ -0,0 +1,281 @@
+# 2024.05.09.
+日小结  
+
+<a id="top"></a>
+根据[ego模型时间接口](https://gitee.com/hyg/blog/blob/master/timeflow.md)，今天绑定模版1。
+
+<a id="index"></a>
+- 07:45	[本地html调用远程git repo或者git page的metadata](#20240509074500)  
+- 09:30	[使用1609模型实际编写COM的metadata](#20240509093000)  
+- 14:00	[了解XMPP协议，为自动发送通知做准备。](#20240509140000)  
+- 14:30	[nodejs中使用微信，为协同工作做准备。](#20240509143000)  
+- 16:00	[整理DRI metadata](#20240509160000)  
+
+---
+season stat:
+
+| task | alloc | sold | hold |
+| --- | --- | --- | --- |
+| total | 13275 | 8523 | 4752 |
+| PSMD | 7000 | 4386 | 2614 |
+| learn | 1000 | 412 | 588 |
+| ego | 3000 | 2054 | 946 |
+| js | 1375 | 495 | 880 |
+| xuemen | 600 | 881 | -281 |
+| raw | 300 | 265 | 35 |
+| infra | 0 | 30 | -30 |
+
+---
+
+waiting list:
+
+
+- 30分钟时间片：
+  - raw的第1号事项：整理今年夏季使用的NRV metadata
+  - ego的第2号事项：日小结时间统计增加一列todo，累计还没有进行的todo项时间。
+  - learn的第2号事项：YARRRML
+  - js的第3号事项：学习AMD规范，如果适用就开发范例
+
+- 60分钟时间片：
+  - js的第1号事项：使用wechty做一个微信机器人范例
+  - learn的第1号事项：github的actions,workflow,job脚本语法
+  - js的第2号事项：学习promise对象和async/await
+  - raw的第2号事项：实现自定义DRI,NRV的代码
+
+- 90分钟时间片：
+  - PSMD的第1号事项：完成1609 COM metadata
+  - ego的第1号事项：实现todo项的多层结构
+  - PSMD的第2号事项：完成1609 deploy、COD的metadata
+  - PSMD的第3号事项：COM metadata -> COM view
+
+- 195分钟时间片：
+  - xuemen的第1号事项：整理S2状态下基本管理制度
+  - PSMD的第4号事项：term + COM matedata -> deploy metadata -> deploy view
+  - ego的第9号事项：在整理近期手稿之后，修订个人模型。
+
+---
+
+[top](#top) | [index](#index)
+<a id="20240509074500"></a>
+## 7:45~8:44
+本地html调用远程git repo或者git page的metadata
+
+- blog/release/entry.test.html 失败，继续找问题。
+- 最后不行就把metadata写成js文件，方便跨域调用。
+    - js文件又不如直接写成html view。
+- js.sample/terms/entry.test.html 先实现git page中的html读取metadata，已测试通过。
+- 追加todo项：
+    - '60': /release/entry.html 读取 markdown和metadata 并显示。
+- codeberg的同域名page读取也测试通过。
+- 页面布局是：
+    - github和codeber下各有入口html，由这些html读取同域名下的metadata或者markdown文件。需要跨域的时候就跳转html。
+
+---
+
+[top](#top) | [index](#index)
+<a id="20240509093000"></a>
+##  9:30~10:59
+使用1609模型实际编写COM的metadata
+
+- 三级决策条款
+```
+  level2:
+    - upgradeby: <COM.1609.level1.1>
+      termid: 88e5c5f4
+      map:
+        <term.88e5c5f4.entity.1>: <COM.1609.entity.admin>
+        <term.88e5c5f4.term.1>: <COM.1609.level1.1>
+    - upgradeby: <COM.1609.level1.3>
+      termid: 4e9e9c33
+      map:
+        <term.4e9e9c33.entity.1>: <COM.1609.entity.deployer>
+        <term.4e9e9c33.entity.2>: <COM.1609.entity.worker>
+        <term.4e9e9c33.term.1>: <COM.1609.level1.3>
+        <term.4e9e9c33.asset.1>: <COM.1609.asset.1>
+        <term.4e9e9c33.asset.2>: <COM.1609.asset.2>
+    - upgradeby: <COM.1609.level1.3>
+      termid: 666776c3
+      map:
+        <term.666776c3.entity.1>: <COM.1609.entity.director>
+        <term.666776c3.entity.2>: <COM.1609.entity.supervisor>
+        <term.666776c3.entity.3>: <COM.1609.entity.worker>
+        <term.666776c3.term.1>: <COM.1609.level1.3>
+        <term.666776c3.asset.1>: <COM.1609.asset.1>
+        <term.666776c3.asset.2>: <COM.1609.asset.2>
+    - upgradeby: <COM.1609.level1.4>
+      termid: efaeac70
+      map:
+        <term.efaeac70.entity.1>: <COM.1609.entity.trustee>
+        <term.efaeac70.term.1>: <COM.1609.level1.4>
+        <term.efaeac70.asset.1>: <COM.1609.asset.1>
+```
+
+- 保密制度
+```
+name: 1609-保密制度
+id: ac890987
+interface:
+  <term.ac890987.term.1>: 自修订条款1.
+  <term.ac890987.term.2>: 二级决策程序1.
+  <term.ac890987.term.3>: 不可修订条款
+  <term.ac890987.term.4>: 自修订条款
+  <term.ac890987.term.5>: 二级决策条款
+item:
+  - localid: '1'
+    upgradeby: <term.ac890987.term.1>
+    termid: 72af7dea
+  - localid: '2'
+    upgradeby: <term.ac890987.term.1>
+    termid: 02c7d037
+    map:
+      <term.02c7d037.term.1>: <term.ac890987.term.3>
+      <term.02c7d037.term.2>: <term.ac890987.term.4>
+      <term.02c7d037.term.3>: <term.ac890987.term.5>
+      <term.02c7d037.term.4>: <term.ac890987.term.1>
+  - localid: '3'
+    upgradeby: <term.ac890987.term.2>
+    termid: ef4cdffe
+    map:
+      <term.ef4cdffe.term.1>: <term.ac890987.term.2>
+``` 
+```
+D:\huangyg\git\PSMD\src>node term term ac890987
+enter maketermtext:ac890987     prefix:
+enter maketermtext:72af7dea     prefix:1.
+enter maketermtext:02c7d037     prefix:2.
+enter maketermtext:ef4cdffe     prefix:3.
+../view/term.ac890987.md文件更新，内容如下:
+条款 ac890987 正文:
+1. 本条款按照自修订条款1.条款修订。本制度正文公开。
+2. 本条款按照自修订条款1.条款修订。不可修订条款、自修订条款、二级决策条款的正文以及执行记录的保密事项由这些条款自己定义，本制度不得规定。
+3. 本条款按照二级决策程序1.条款修订。其它规章正文及执行记录默认为公开。
+
+Warning: missing space before text for line 6 of jade file "undefined"
+Warning: missing space before text for line 8 of jade file "undefined"
+Warning: missing space before text for line 10 of jade file "undefined"
+../view/term.ac890987.html文件更新，内容如下:
+<html lang="zh-cn"><head><title>term html sample</title><script></script></head><body><h3>条款 ac890987</h3><hr/><p>正文:</p><p>1. 本条款按照自修订 条款1.条款修订。本制度正文公开。<br/>
+2. 本条款按照自修订条款1.条款修订。不可修订条款、自修订条款、二级决策条款的正文以及执行记录的保密事项由这些条款自己定义，本制度不得规定。<br/>
+3. 本条款按照二级决策程序1.条款修订。其它规章正文及执行记录默认为公开。<br/>
+</p><hr/></body></html>
+```
+
+- 条款内容要用text: | 然后换行，而不能直接写在text: 后面，否则末尾没有回车，makeview时不会换行。
+  - text: [^|]
+- 追加后续todo项：
+    - '90': 完成1609 COM metadata
+      readme: |
+        - 利益分配条款
+        - 各决策条款的改变事项，微调。
+    - '90': 完成1609 deploy、COD的metadata
+    - '90': COM metadata -> COM view
+
+---
+
+[top](#top) | [index](#index)
+<a id="20240509140000"></a>
+## 14:00~14:29
+了解XMPP协议，为自动发送通知做准备。
+
+目前主流的IM协议有：  
+- XMPP (Extensible Messaging and Presence Protocol)
+- SIMPLE(session initiation protocol for instant messaging and presence leveraging extensions)
+- IMPP (Instant Messaging and Presence Protocol)
+- activesync
+
+学习 xmpp
+- https://xmpp.org/about/technology-overview/
+- https://conversejs.org/
+    - jabbim.com 的web模式使用
+    - https://github.com/conversejs/converse.js/
+    - https://www.npmjs.com/package/converse.js/v/10.0.0
+    - https://conversejs.org/docs/html/
+- https://www.npmjs.com/package/@xmpp/client
+- 新建js.sample/IM
+    - 能看到online事件发出的信息，对方可以接收到。
+    - 对方发来的，没有触发stanza事件。
+```
+D:\huangyg\git\js.sample\IM>node xmpp
+<ref *1> Element {
+  name: 'iq',
+  parent: Element {
+    name: 'stream:stream',
+    parent: null,
+    children: [],
+    attrs: {
+      id: '15186860272392038401',
+      version: '1.0',
+      'xml:lang': 'en',
+      'xmlns:stream': 'http://etherx.jabber.org/streams',
+      from: 'jabbim.com',
+      xmlns: 'jabber:client'
+    }
+  },
+  children: [
+    Element {
+      name: 'bind',
+      parent: [Circular *1],
+      children: [Array],
+      attrs: [Object]
+    }
+  ],
+  attrs: { type: 'result', id: 'z3j047wbpg' }
+}
+onlinelearn@jabbim.com/9490604234615875585234876738
+^C
+D:\huangyg\git\js.sample\IM>
+```
+
+先不追加时间，利用休整时间看看再说。
+
+---
+
+[top](#top) | [index](#index)
+<a id="20240509143000"></a>
+## 14:30~14:59
+nodejs中使用微信，为协同工作做准备。
+
+### nodejs
+
+- https://github.com/node-weixin/node-weixin-api
+- https://gitee.com/javen205/TNWX
+- https://github.com/wechaty/wechaty
+    - https://wechaty.gitbook.io/wechaty/v/zh
+- 
+
+### 命令行
+
+- https://github.com/goorockey/node-wechat-terminal
+- https://github.com/oneatletico/cmd-wechat-terminal
+
+- 命令行还是需要人工操作，nodejs的wechty应该可以试试。
+- 追加一个todo项：
+    - '60': 使用wechty做一个微信机器人范例
+      readme: |
+        - https://github.com/wechaty/wechaty
+        - https://wechaty.gitbook.io/wechaty/v/zh
+
+---
+
+[top](#top) | [index](#index)
+<a id="20240509160000"></a>
+## 16:00~16:59
+整理DRI metadata
+
+D:\huangyg\git\raw\food\DRIs.DRIforChina2023.yaml
+
+- 增加PAL字段：身体活动水平。三级数值为1.4、 1.7、 2.0。
+- 能量增加EER字段：能量需要量 EER=BMR*PAL = 1828.83
+    - BMR 基础代谢率 (kcal/d) = 14.52W-15.88S+565.79 = 1310.67
+        - W体重，kg
+        - S性别，男=0，女=1
+- 应该用代码来计算。
+- 部分营养成分增加readme字段
+- 钴增加RfD字段，每日参考剂量
+- 硼等增加NOAEL，No Observed Adverse Effect Level 无可见有害作用水平
+- 钒增加LOAEL字段，最低可见有害作用水平
+- 砷增加MRL字段
+- 牛磺酸等增加OSL字段，人体观察到的安全水平 observed safe level
+
+追加todo项：  
+- '30': 整理今年夏季使用的NRV metadata

release/time/d.20240510.md

@@ -0,0 +1,431 @@
+# 2024.05.10.
+日小结  
+
+<a id="top"></a>
+根据[ego模型时间接口](https://gitee.com/hyg/blog/blob/master/timeflow.md)，今天绑定模版1。
+
+<a id="index"></a>
+- 07:45	[使用wechty做一个微信机器人范例](#20240510074500)  
+- 09:30	[完成1609 COM metadata](#20240510093000)  
+- 14:00	[整理今年夏季使用的NRV metadata](#20240510140000)  
+- 14:30	[实现自定义DRI,NRV的代码](#20240510143000)  
+- 16:00	[日小结时间统计增加一列todo，累计还没有进行的todo项时间。学习数组插入数组。](#20240510160000)  
+
+---
+season stat:
+
+| task | alloc | sold | hold | todo |
+| --- | --- | --- | --- | --- |
+| total | 13275 | 8855 | 4420 | 2475 |
+| PSMD | 7000 | 4506 | 2494 | 705 |
+| learn | 1000 | 412 | 588 | 360 |
+| ego | 3000 | 2114 | 886 | 525 |
+| js | 1375 | 555 | 820 | 300 |
+| xuemen | 600 | 881 | -281 | 405 |
+| raw | 300 | 357 | -57 | 180 |
+| infra | 0 | 30 | -30 | 0 |
+
+---
+
+waiting list:
+
+
+- 30分钟时间片：
+  - ego的第1号事项：实现todo项的多层结构
+  - learn的第2号事项：YARRRML
+  - js的第3号事项：学习AMD规范，如果适用就开发范例
+  - learn的第3号事项：docker
+
+- 60分钟时间片：
+  - js的第1号事项：了解call和apply
+  - learn的第1号事项：github的actions,workflow,job脚本语法
+  - raw的第1号事项：实现自定义DRI,NRV的代码
+  - ego的第2号事项：/release/entry.html 读取 markdown和metadata 并显示。
+
+- 90分钟时间片：
+  - PSMD的第1号事项：完成1609 deploy、COD的metadata
+  - PSMD的第2号事项：COM metadata -> COM view
+  - xuemen的第3号事项：整理S2状态下基本管理制度的metedata
+  - PSMD的第7号事项：term metadata生成按修订层级排版的COM metadata。
+
+- 195分钟时间片：
+  - xuemen的第1号事项：整理S2状态下基本管理制度
+  - PSMD的第3号事项：term + COM matedata -> deploy metadata -> deploy view
+  - ego的第8号事项：在整理近期手稿之后，修订个人模型。
+
+---
+
+[top](#top) | [index](#index)
+<a id="20240510074500"></a>
+## 7:45~8:44
+使用wechty做一个微信机器人范例
+
+昨晚已经把xmpp收发消息跑通。长时间闲置还是会断线。
+```
+D:\huangyg\git\js.sample\IM>node xmpp
+(node:10100) Warning: Setting the NODE_TLS_REJECT_UNAUTHORIZED environment variable to '0' makes TLS connections and HTTPS requests insecure by disabling certificate verification.
+(Use `node --trace-warnings ...` to show where the warning was created)
+connecting
+connecting
+connect
+opening
+open
+opening
+open
+opening
+open
+<iq type="result" id="krvegcw2lo"><bind xmlns="urn:ietf:params:xml:ns:xmpp-bind"><jid>learn@jabbim.com/520348062276946534557140265</jid></bind></iq>
+online
+online: learn@jabbim.com/520348062276946534557140265
+<message xml:lang="en" to="learn@jabbim.com/520348062276946534557140265" from="hyg@jabbim.com/gajim.HTKRCI7J" type="chat" id="3f2abb86-2bc2-4052-aa9f-de54af571452"><origin-id xmlns="urn:xmpp:sid:0" id="3f2abb86-2bc2-4052-aa9f-de54af571452"/><request xmlns="urn:xmpp:receipts"/><markable xmlns="urn:xmpp:chat-markers:0"/><delay xmlns="urn:xmpp:delay" from="jabbim.com" stamp="2024-05-09T13:02:19.432086Z">Offline Storage</delay><body>hi</body></message>
+<message xml:lang="en" to="learn@jabbim.com/520348062276946534557140265" from="hyg@jabbim.com/gajim.HTKRCI7J" type="chat" id="dfd733cb-b853-4787-a5c7-1c0a534a449b"><origin-id xmlns="urn:xmpp:sid:0" id="dfd733cb-b853-4787-a5c7-1c0a534a449b"/><request xmlns="urn:xmpp:receipts"/><markable xmlns="urn:xmpp:chat-markers:0"/><delay xmlns="urn:xmpp:delay" from="jabbim.com" stamp="2024-05-09T13:03:56.375380Z">Offline Storage</delay><body>hello</body></message>
+<message xml:lang="en" to="learn@jabbim.com/520348062276946534557140265" from="hyg@jabbim.com/gajim.HTKRCI7J" type="chat" id="fbb21b98-8c85-4c5d-a1da-1324803dd66b"><origin-id xmlns="urn:xmpp:sid:0" id="fbb21b98-8c85-4c5d-a1da-1324803dd66b"/><request xmlns="urn:xmpp:receipts"/><markable xmlns="urn:xmpp:chat-markers:0"/><delay xmlns="urn:xmpp:delay" from="jabbim.com" stamp="2024-05-09T13:05:36.423499Z">Offline Storage</delay><body>are u online?</body></message>
+<message xml:lang="en" to="learn@jabbim.com/520348062276946534557140265" from="hyg@jabbim.com/gajim.HTKRCI7J" type="chat" id="5b32e3c7-546e-4910-b2b1-945d5e1099f9"><origin-id xmlns="urn:xmpp:sid:0" id="5b32e3c7-546e-4910-b2b1-945d5e1099f9"/><request xmlns="urn:xmpp:receipts"/><markable xmlns="urn:xmpp:chat-markers:0"/><delay xmlns="urn:xmpp:delay" from="jabbim.com" stamp="2024-05-09T13:09:39.463135Z">Offline Storage</delay><body>hello learn</body></message>
+<message xml:lang="en" to="learn@jabbim.com/520348062276946534557140265" from="hyg@jabbim.com/gajim.HTKRCI7J" type="chat" id="ece8424c-06ab-4c03-9e5d-28f77d5ca2bc"><origin-id xmlns="urn:xmpp:sid:0" id="ece8424c-06ab-4c03-9e5d-28f77d5ca2bc"/><request xmlns="urn:xmpp:receipts"/><markable xmlns="urn:xmpp:chat-markers:0"/><delay xmlns="urn:xmpp:delay" from="jabbim.com" stamp="2024-05-09T14:04:45.645481Z">Offline Storage</delay><body>hey</body></message>
+<presence xml:lang="en" to="learn@jabbim.com/520348062276946534557140265" from="learn@jabbim.com/520348062276946534557140265"><x xmlns="vcard-temp:x:update"/><show>chat</show><status>presence!</status></presence>
+<message xml:lang="en" to="learn@jabbim.com/520348062276946534557140265" from="hyg@jabbim.com/gajim.HTKRCI7J" type="chat" id="08ce5f7a-8589-46bb-8eb8-d1db4d7afc93"><origin-id xmlns="urn:xmpp:sid:0" id="08ce5f7a-8589-46bb-8eb8-d1db4d7afc93"/><displayed xmlns="urn:xmpp:chat-markers:0" id="None"/></message>
+<message xml:lang="en" to="learn@jabbim.com/520348062276946534557140265" from="hyg@jabbim.com/gajim.HTKRCI7J" type="chat" id="f5ae1912-4c70-450a-9910-0266c58916d5"><archived by="learn@jabbim.com" id="1715263586963539" xmlns="urn:xmpp:mam:tmp"/><stanza-id by="learn@jabbim.com" id="1715263586963539" xmlns="urn:xmpp:sid:0"/><origin-id xmlns="urn:xmpp:sid:0" id="f5ae1912-4c70-450a-9910-0266c58916d5"/><request xmlns="urn:xmpp:receipts"/><markable xmlns="urn:xmpp:chat-markers:0"/><body>really?</body></message>
+<message xml:lang="en" to="learn@jabbim.com/520348062276946534557140265" from="hyg@jabbim.com/gajim.HTKRCI7J" type="chat" id="bec806cb-db4a-4738-b460-ebff6c1e6395"><archived by="learn@jabbim.com" id="1715263606220666" xmlns="urn:xmpp:mam:tmp"/><stanza-id by="learn@jabbim.com" id="1715263606220666" xmlns="urn:xmpp:sid:0"/><origin-id xmlns="urn:xmpp:sid:0" id="bec806cb-db4a-4738-b460-ebff6c1e6395"/><request xmlns="urn:xmpp:receipts"/><markable xmlns="urn:xmpp:chat-markers:0"/><body>ok</body></message>
+<message xml:lang="en" to="learn@jabbim.com/520348062276946534557140265" from="hyg@jabbim.com/gajim.HTKRCI7J" type="chat" id="b4b6a7d9-dbe3-4c35-aadd-8ad8137ab28c"><archived by="learn@jabbim.com" id="1715263609763192" xmlns="urn:xmpp:mam:tmp"/><stanza-id by="learn@jabbim.com" id="1715263609763192" xmlns="urn:xmpp:sid:0"/><origin-id xmlns="urn:xmpp:sid:0" id="b4b6a7d9-dbe3-4c35-aadd-8ad8137ab28c"/><request xmlns="urn:xmpp:receipts"/><markable xmlns="urn:xmpp:chat-markers:0"/><body>good</body></message>
+<message xml:lang="en" to="learn@jabbim.com/520348062276946534557140265" from="hyg@jabbim.com/gajim.HTKRCI7J" type="chat" id="e79c99c7-aa30-4c05-9e64-eee971801556"><archived by="learn@jabbim.com" id="1715263689669350" xmlns="urn:xmpp:mam:tmp"/><stanza-id by="learn@jabbim.com" id="1715263689669350" xmlns="urn:xmpp:sid:0"/><origin-id xmlns="urn:xmpp:sid:0" id="e79c99c7-aa30-4c05-9e64-eee971801556"/><request xmlns="urn:xmpp:receipts"/><markable xmlns="urn:xmpp:chat-markers:0"/><body>fine</body></message>
+```
+
+- 建立 D:\huangyg\git\js.sample\wechaty 项目
+- 需要nmp init，然后在js.sample\wechaty\package.json 中的第一层添加"type": "module",
+    - (node:6632) Warning: To load an ES module, set "type": "module" in the package.json or use the .mjs extension.
+- 要选用有build instance语句的范例，官网范例也有过时的。
+    - SyntaxError: The requested module 'wechaty' does not provide an export named 'Wechaty'
+    - https://github.com/wechaty/getting-started/issues/250
+```
+import { WechatyBuilder } from 'wechaty'
+
+const wechaty = WechatyBuilder.build() // get a Wechaty instance
+wechaty
+  .on('scan', (qrcode, status) => console.log(`Scan QR Code to login: ${status}\nhttps://wechaty.js.org/qrcode/${encodeURIComponent(qrcode)}`))
+  .on('login',            user => console.log(`User ${user} logged in`))
+  .on('message',       message => console.log(`Message: ${message}`))
+wechaty.start()
+```
+
+- 可以跑起来，获得好友发言。真正调试需要单独账号，尤其注意不要绑定银行卡。
+- 执行结果：
+```
+D:\huangyg\git\js.sample\wechaty>node bot
+(node:14588) [DEP0040] DeprecationWarning: The `punycode` module is deprecated. Please use a userland alternative instead.
+(Use `node --trace-deprecation ...` to show where the warning was created)
+Scan QR Code to login: 2
+https://wechaty.js.org/qrcode/https%3A%2F%2Flogin.weixin.qq.com%2Fl%2FQdq_xWamSw%3D%3D
+Scan QR Code to login: 3
+https://wechaty.js.org/qrcode/https%3A%2F%2Flogin.weixin.qq.com%2Fl%2FQdq_xWamSw%3D%3D
+User Contact<黄勇刚> logged in
+Message: Message#Unknown[🗣Contact<黄勇刚>]
+Message: Message#Unknown[🗣Contact<黄勇刚>]
+Message: Message#Text[🗣Contact<剑平>@👥Room<IRIS百人会>]        「北京_白清杰：我觉得小孩子是要多读读科普书。各种学科的人物传记，历史书，从小学习逻 辑学，学习怎么做问题研究，提高解决问题的能力」
+- -
+Message: Message#Text[🗣Contact<剑平>@👥Room<IRIS百人会>]        @煮酒论剑 [抱拳][抱拳][抱拳]
+uncaughtException AssertionError [ERR_ASSERTION]: '1101' == 0
+    at Object.equal (D:\huangyg\git\js.sample\wechaty\node_modules\wechat4u\lib\util\global.js:69:24)
+    at D:\huangyg\git\js.sample\wechaty\node_modules\wechat4u\lib\core.js:410:24
+    at process.processTicksAndRejections (node:internal/process/task_queues:95:5) {
+  code: 2,
+  details: "AssertionError [ERR_ASSERTION]: '1101' == 0\n" +
+    '    at Object.equal (D:\\huangyg\\git\\js.sample\\wechaty\\node_modules\\wechat4u\\lib\\util\\global.js:69:24)\n' +
+    '    at D:\\huangyg\\git\\js.sample\\wechaty\\node_modules\\wechat4u\\lib\\core.js:410:24\n' +
+    '    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)'
+}
+08:26:50 WARN PuppetWechat4u contactRawPayload(AssertionError [ERR_ASSERTION]: 1101 == 0) wechat4u.batchGetContact() exception: undefined
+```
+
+---
+
+[top](#top) | [index](#index)
+<a id="20240510093000"></a>
+##  9:30~10:59
+完成1609 COM metadata
+
+- 利益分配的1、2、都属于不可修订条款。
+- term commit的时候同名临时文件覆盖了正式文件，而临时文件引用的其它临时文件已经修改过，只能手工逐条恢复。
+    - 以后commit完要删除临时文件。考虑自动删除。
+- 完成普通条款 term.77666f44
+    - D:\huangyg\git\PSMD\data\COM.1609.yaml中加入termid: 77666f44
+
+```
+D:\huangyg\git\PSMD\src>node term term 77666f44
+enter maketermtext:77666f44     prefix:
+enter maketermtext:ac890987     prefix:保密制度.
+enter maketermtext:72af7dea     prefix:保密制度.1.
+enter maketermtext:02c7d037     prefix:保密制度.2.
+enter maketermtext:ef4cdffe     prefix:保密制度.3.
+enter maketermtext:de47ace4     prefix:利益分配.
+enter maketermtext:c046b09d     prefix:利益分配.1.
+enter maketermtext:3638eac6     prefix:利益分配.2.
+enter maketermtext:1558e5e1     prefix:利益分配.3.
+enter maketermtext:814f76cb     prefix:利益分配.4.
+enter maketermtext:58d4c137     prefix:利益分配.5.
+enter maketermtext:c1f65b6d     prefix:利益分配.5.1.
+enter maketermtext:6568c500     prefix:利益分配.5.2.
+enter maketermtext:d8bd8aa6     prefix:利益分配.6.
+enter maketermtext:8a5d94dc     prefix:利益分配.6.1.
+enter maketermtext:34be50e1     prefix:利益分配.6.2.
+enter maketermtext:3176f00c     prefix:利益分配.6.3.
+enter maketermtext:a8ca0160     prefix:利益分配.6.4.
+enter maketermtext:2a78271e     prefix:利益分配.6.5.
+enter maketermtext:96b99526     prefix:利益分配.7.
+enter maketermtext:6d2ca266     prefix:利益分配.7.1.
+enter maketermtext:fb21bdf9     prefix:利益分配.7.2.
+enter maketermtext:7f7a536f     prefix:利益分配.7.3.
+enter maketermtext:a8d575a7     prefix:利益分配.7.4.
+enter maketermtext:70cdd24d     prefix:利益分配.7.5.
+enter maketermtext:41312cc4     prefix:利益分配.7.6.
+enter maketermtext:12d14064     prefix:利益分配.8.
+enter maketermtext:af62f03b     prefix:利益分配.8.1.
+enter maketermtext:55cc8467     prefix:利益分配.8.2.
+enter maketermtext:e4495f38     prefix:利益分配.8.3.
+../view/term.77666f44.md文件更新，内容如下:
+条款 77666f44 正文:
+保密制度.1. 本条款按照自修订条款1.条款修订。本制度正文公开。
+保密制度.2. 本条款按照自修订条款1.条款修订。不可修订条款、自修订条款、二级决策条款的正文以及执行记录的保密事项由这些条款自己定义，本制度不得规定。
+保密制度.3. 本条款按照二级决策程序1.条款修订。其它规章正文及执行记录默认为公开。
+利益分配.1. 利益分配原则：优先劣后次序与决策层级相反。
+利益分配.2. 每个成员设一个专户，每个专户可以容纳所有种类的资产。
+利益分配.3. 本条款按照自修订条款1.条款修订。设四个共同体专户，每个专户可以容纳所有种类的资产。分别由：deployer、trustee、director和supervisor、admin管理。
+利益分配.4. 本条款按照自修订条款1.条款修订。按照二级决策条款2.设立部门时，开设部门专户，并明确与其它专户的资源交换规则。
+利益分配.5. deployer专户：
+利益分配.5.1. 本条款按照自修订条款1.条款修订。deployer专户用于deployer工作经费，以及重构期间发生的短期支出。
+利益分配.5.2. 本条款按照二级决策条款3.条款修订。每月末将director专户余额的0.5%转入deployer专户。
+利益分配.6. 本条款按照二级决策条款4.条款修订。trustee专户：
+利益分配.6.1. 本条款按照二级决策条款4.条款修订。RIU持有者可以将RIU转入trustee专户，委托trustee卖出。
+利益分配.6.2. 本条款按照二级决策条款4.条款修订。投资者可以将其它资源转入trustee专户，委托trustee买入RIU。
+利益分配.6.3. 本条款按照二级决策条款4.条款修订。收入的p%用于购买trustee专户中的RIU，低价优先。交易获得的RIU支付trustee报酬后，余额转入director专户。
+利益分配.6.4. 本条款按照二级决策条款4.条款修订。RIU交易由trustee按价格优先、时间优先原则撮合。
+利益分配.6.5. 本条款按照二级决策条款4.条款修订。trustee从收入的p%购买的RIU中领取报酬，竞聘者须明确报酬的计算公式。
+利益分配.7. 本条款按照二级决策条款3.条款修订。director专户由director与supervisor共同使用：
+利益分配.7.1. 本条款按照二级决策条款3.条款修订。director专户中的RIU可以是负数，最小值由预算透支限额确定。
+利益分配.7.2. 本条款按照二级决策条款3.条款修订。收入的(100-p)%转入director专户。
+利益分配.7.3. 本条款按照二级决策条款3.条款修订。按生效的admin工作计划（含预算案）从director专户转入admin专户，余额不足时后续条款的支出暂缓。
+利益分配.7.4. 本条款按照二级决策条款3.条款修订。supervisor按supervisor工作计划（含预算案）使用director专户余额，余额不足时后续条款的支出暂缓。
+利益分配.7.5. 本条款按照二级决策条款3.条款修订。director按director工作计划（含预算案）使用director专户余额，余额不足时后续条款的支出暂缓。
+利益分配.7.6. 本条款按照二级决策条款3.条款修订。deployer、director、supervisor从director专户领取报酬，director、supervisor竞聘者须明确报酬的计算公式，deployer报酬数额为director、supervisor报酬的中位数。director专户数额不足时以应发数额为权重按比例分配，等候期间不计利息。
+利益分配.8. admin专户：
+利益分配.8.1. 本条款按照二级决策条款1.条款修订。admin按admin工作计划（含预算案）调用admin专户中的资源。
+利益分配.8.2. 本条款按照二级决策条款1.条款修订。member的工作成果提交到admin专户，从admin专户领取报酬，报酬金额在合同中规定。
+利益分配.8.3. 本条款按照二级决策条款1.条款修订。admin从admin专户领取报酬（优先级在worker之后），竞聘者须明确报酬的计算公式。本专户数额不足而等候期间不计利息。
+
+---
+readme:
+条款 77666f44. 利益分配. 利益分配.2. - 所有工作成果都属于资产。
+利益分配.5. 利益分配.5.1. - deployer无须制订工作计划和预算案。
+- 部署时根据实际情况确定本条的记账方式。
+利益分配.5.2. deployer使用资源的优先级高于director。
+利益分配.6. 利益分配.6.3. 大部分收入还是由director使用，其中p%体现为RIU（扣除trustee报酬），其余体现为对外交易约定的资源。
+利益分配.6.5. trustee任期内报酬公式不变，如果情况变化可以辞职，再与其他竞聘者一起根据当时情况竞聘。
+利益分配.7. 利益分配.7.3. - 工作计划和预算案可以根据工作需要规定资源转入时间，滚动利用预算周期内的交易收入。
+- admin使用资源的优先级高于director和supervisor。
+利益分配.7.4. supervisor使用资源的优先级高于director。
+利益分配.7.6. - deployer、director、supervisor的报酬优先级低于工作支出。
+- director、supervisor任期内报酬公式不变，如果情况变化可以辞职，再与其他竞聘者一起根据当时情况竞聘。
+利益分配.8. 利益分配.8.2. - member所包括角色范围根据实际情况界定。通常包括admin、worker，有时也包括一些外部人员、机构。
+- 报酬可能包括不同种类的资源。
+利益分配.8.3. - admin任期内报酬公式不变，如果情况变化可以辞职，再与其他竞聘者一起根据当时情况竞聘。
+
+Warning: missing space before text for line 6 of jade file "undefined"
+Warning: missing space before text for line 8 of jade file "undefined"
+Warning: missing space before text for line 10 of jade file "undefined"
+../view/term.77666f44.html文件更新，内容如下:
+<html lang="zh-cn"><head><title>term html sample</title><script></script></head><body><h3>条款 77666f44</h3><hr/><p>正文:</p><p>保密制度.1. 本条款按照自修订条款1.条款修订。本制度正文公开。<br/>
+保密制度.2. 本条款按照自修订条款1.条款修订。不可修订条款、自修订条款、二级决策条款的正文以及执行记录的保密事项由这些条款自己定义，本制度不得规定。<br/>
+保密制度.3. 本条款按照二级决策程序1.条款修订。其它规章正文及执行记录默认为公开。<br/>
+利益分配.1. 利益分配原则：优先劣后次序与决策层级相反。<br/>
+利益分配.2. 每个成员设一个专户，每个专户可以容纳所有种类的资产。<br/>
+利益分配.3. 本条款按照自修订条款1.条款修订。设四个共同体专户，每个专户可以容纳所有种类的资产。分别由：deployer、trustee、director和supervisor、admin管理。<br/>
+利益分配.4. 本条款按照自修订条款1.条款修订。按照二级决策条款2.设立部门时，开设部门专户，并明确与其它专户的资源交换规则。<br/>
+利益分配.5. deployer专户：<br/>
+利益分配.5.1. 本条款按照自修订条款1.条款修订。deployer专户用于deployer工作经费，以及重构期间发生的短期支出。<br/>
+利益分配.5.2. 本条款按照二级决策条款3.条款修订。每月末将director专户余额的0.5%转入deployer专户。<br/>
+利益分配.6. 本条款按照二级决策条款4.条款修订。trustee专户：<br/>
+利益分配.6.1. 本条款按照二级决策条款4.条款修订。RIU持有者可以将RIU转入trustee专户，委托trustee卖出。<br/>
+利益分配.6.2. 本条款按照二级决策条款4.条款修订。投资者可以将其它资源转入trustee专户，委托trustee买入RIU。<br/>
+利益分配.6.3. 本条款按照二级决策条款4.条款修订。收入的p%用于购买trustee专户中的RIU，低价优先。交易获得的RIU支付trustee报酬后，余额转入director专户。<br/>
+利益分配.6.4. 本条款按照二级决策条款4.条款修订。RIU交易由trustee按价格优先、时间优先原则撮合。<br/>
+利益分配.6.5. 本条款按照二级决策条款4.条款修订。trustee从收入的p%购买的RIU中领取报酬，竞聘者须明确报酬的计算公式。<br/>
+利益分配.7. 本条款按照二级决策条款3.条款修订。director专户由director与supervisor共同使用：<br/>
+利益分配.7.1. 本条款按照二级决策条款3.条款修订。director专户中的RIU可以是负数，最小值由预算透支限额确定。<br/>
+利益分配.7.2. 本条款按照二级决策条款3.条款修订。收入的(100-p)%转入director专户。<br/>
+利益分配.7.3. 本条款按照二级决策条款3.条款修订。按生效的admin工作计划（含预算案）从director专户转入admin专户，余额不足时后续条款的支出暂缓。<br/>
+利益分配.7.4. 本条款按照二级决策条款3.条款修订。supervisor按supervisor工作计划（含预算案）使用director专户余额，余额不足时后续条款的支出暂缓。<br/>
+利益分配.7.5. 本条款按照二级决策条款3.条款修订。director按director工作计划（含预算案）使用director专户余额，余额不足时后续条款的支出暂缓。<br/>
+利益分配.7.6. 本条款按照二级决策条款3.条款修订。deployer、director、supervisor从director专户领取报酬，director、supervisor竞聘者须明确报酬的计算公式，deployer报酬数额为director、supervisor报酬的中位数。director专户数额不足时以应发数额为权重按比例分配，等候期间不计利息。<br/>
+利益分配.8. admin专户：<br/>
+利益分配.8.1. 本条款按照二级决策条款1.条款修订。admin按admin工作计划（含预算案）调用admin专户中的资源。<br/>
+利益分配.8.2. 本条款按照二级决策条款1.条款修订。member的工作成果提交到admin专户，从admin专户领取报酬，报酬金额在合同中规定。<br/>
+利益分配.8.3. 本条款按照二级决策条款1.条款修订。admin从admin专户领取报酬（优先级在worker之后），竞聘者须明确报酬的计算公式。本专户数额不足而等候期间不计利息。<br/>
+</p><hr/><p>注释:</p><p>利益分配. 利益分配.2. - 所有工作成果都属于资产。<br/>
+利益分配.5. 利益分配.5.1. - deployer无须制订工作计划和预算案。<br/>
+- 部署时根据实际情况确定本条的记账方式。<br/>
+利益分配.5.2. deployer使用资源的优先级高于director。<br/>
+利益分配.6. 利益分配.6.3. 大部分收入还是由director使用，其中p%体现为RIU（扣除trustee报酬），其余体现为对外交易约定的资源。<br/>
+利益分配.6.5. trustee任期内报酬公式不变，如果情况变化可以辞职，再与其他竞聘者一起根据当时情况竞聘。<br/>
+利益分配.7. 利益分配.7.3. - 工作计划和预算案可以根据工作需要规定资源转入时间，滚动利用预算周期内的交易收入。<br/>
+- admin使用资源的优先级高于director和supervisor。<br/>
+利益分配.7.4. supervisor使用资源的优先级高于director。<br/>
+利益分配.7.6. - deployer、director、supervisor的报酬优先级低于工作支出。<br/>
+- director、supervisor任期内报酬公式不变，如果情况变化可以辞职，再与其他竞聘者一起根据当时情况竞聘。<br/>
+利益分配.8. 利益分配.8.2. - member所包括角色范围根据实际情况界定。通常包括admin、worker，有时也包括一些外部人员、机构。<br/>
+- 报酬可能包括不同种类的资源。<br/>
+利益分配.8.3. - admin任期内报酬公式不变，如果情况变化可以辞职，再与其他竞聘者一起根据当时情况竞聘。<br/>
+</p><hr/></body></html>
+```
+
+---
+
+[top](#top) | [index](#index)
+<a id="20240510140000"></a>
+## 14:00~14:29
+整理今年夏季使用的NRV metadata
+
+```
+name: 202405a
+DRIs: DRIforChina2023
+element:
+  热量:
+    amount: 1850
+    unit: kcal
+  蛋白质: 
+    amount: 80.9
+    unit: g
+  脂肪:
+    amount: 51.4
+    unit: g
+  碳水化合物:
+    amount: 265.9
+    unit: g
+  水:
+    amount: 2000
+    unit: ml
+```
+---
+
+[top](#top) | [index](#index)
+<a id="20240510143000"></a>
+## 14:30~14:59
+实现自定义DRI,NRV的代码
+
+- 在 D:\huangyg\git\raw\raw.js 增加maketable()
+- 暂时够用，屏幕宽度只能显示"总量","日均","单位","NRV(%)","RNI","RNI(%)","AI","AI(%)","UL","UL(%)","PI_NCD","SPL"。
+
+---
+
+[top](#top) | [index](#index)
+<a id="20240510160000"></a>
+## 16:00~16:59
+日小结时间统计增加一列todo，累计还没有进行的todo项时间。学习数组插入数组。
+
+- 在D:\huangyg\git\ego\src\finish.js 增加 todosum(todoobj) ，修改maketomorowinfo(date) 。执行结果：
+```
+season stat:
+
+| task | alloc | sold | hold | todo |
+| --- | --- | --- | --- | --- |
+| total | 13275 | 8523 | 4752 | 2475 |
+| PSMD | 7000 | 4386 | 2614 | 705 |
+| learn | 1000 | 412 | 588 | 360 |
+| ego | 3000 | 2054 | 946 | 585 |
+| js | 1375 | 495 | 880 | 240 |
+| xuemen | 600 | 881 | -281 | 405 |
+| raw | 300 | 265 | 35 | 180 |
+| infra | 0 | 30 | -30 | 0 |
+```
+
+- 准备一下数组删除、插入的方法，为todo项的分层结构做准备。
+- D:\huangyg\git\ego\src\start.js  line38
+    - 删除不能用原来的filter()，可以用splice() 只要前两个参数，第二个是1.
+    - 插入使用array.splice()
+        - https://developer.mozilla.org/zh-CN/docs/Web/JavaScript/Reference/Global_Objects/Array/splice
+        - 第一个参数是索引位置，第二个参数0是插入，1是原地替换。
+- 很有价值的资料：https://blog.csdn.net/qq_32849999/article/details/102777206
+  - ES6中引入了一种Spread操作符...,他后面接一个Iterator对象,可以整个数组拆散一次插入。
+  - ES5用apply可以实现将参数用数组的方式绑定到执行的方法上面.于是,我们可以把所有需要的参数放进一个数组里面,然后用apply.
+- 新建测试文件todo.yaml、todo.js
+
+todo.yaml
+```
+PSMD:
+  - '90': 完成1609 deploy、COD的metadata
+  - '90': COM metadata -> COM view
+  - '195': term + COM matedata -> deploy metadata -> deploy view
+    bind:
+    - '90': 实现todo项的多层结构
+    - '60': /release/entry.html 读取 markdown和metadata 并显示。
+    - '60': 在season metadata中实现浮动时间表，修改日计划功能。
+    - '30': 整理废弃git库，包括本地和远程。
+      readme: |
+        参考5.3.14:00 draft
+    - '60': task之间结算体系设计。
+    - '30': 设计ego.mars22.com 发布内容。
+    - '60': 用js代码完成日小结后的git操作。
+      readme: |
+        - 参考：D:\huangyg\git\draft\2024\04\20240430140000.md
+        - 在各task metadata中给出git库的路径，每天根据实际任务去操作。
+    - '195': 在整理近期手稿之后，修订个人模型。
+  - '30': PSMD委托合同的metadata
+  - '30': 了解Rules as Code (RaC)，准备在metadata中增加code字段。
+  - '30': debug- D:\huangyg\git\PSMD\data\term.25c83dac.yaml interface字段混乱。
+    readme: |
+      term.25c83dac.yaml的depend.text 包含 <term.2e4f11cb.term.1> 
+      执行node term term 2e4f11cb
+      term.25c83dac.yaml的interface:
+        <term.50430bca.632214.c83dac.entity.1>: 董事会
+        <term.50430bca.632214.c83dac.term.1>: 章程第八条（十）
+        <term.50430bca.632214.c83dac.term.2>: 中华人民共和国公司法
+  - '90': term metadata生成按修订层级排版的COM metadata。
+  - '60': 设计条款的可执行机制
+  - '90': 整理近期手稿。
+
+```
+
+todo.js
+```
+var fs = require('fs');
+var yaml = require('js-yaml');
+
+var todoobj = yaml.load(fs.readFileSync("todo.yaml"));
+todoobj.PSMD.splice(2,1,...todoobj.PSMD[2].bind);
+console.log(yaml.dump(todoobj.PSMD));
+```
+
+执行结果：
+```
+D:\huangyg\git\ego\src>node todo
+- '90': 完成1609 deploy、COD的metadata
+- '90': COM metadata -> COM view
+- '90': 实现todo项的多层结构
+- '60': /release/entry.html 读取 markdown和metadata 并显示。
+- '60': 在season metadata中实现浮动时间表，修改日计划功能。
+- '30': 整理废弃git库，包括本地和远程。
+  readme: |
+    参考5.3.14:00 draft
+- '60': task之间结算体系设计。
+- '30': 设计ego.mars22.com 发布内容。
+- '60': 用js代码完成日小结后的git操作。
+  readme: |
+    - 参考：D:\huangyg\git\draft\2024\04\20240430140000.md
+    - 在各task metadata中给出git库的路径，每天根据实际任务去操作。
+- '195': 在整理近期手稿之后，修订个人模型。
+- '30': PSMD委托合同的metadata
+- '30': 了解Rules as Code (RaC)，准备在metadata中增加code字段。
+- '30': debug- D:\huangyg\git\PSMD\data\term.25c83dac.yaml interface字段混乱。
+  readme: |
+    term.25c83dac.yaml的depend.text 包含 <term.2e4f11cb.term.1>
+    执行node term term 2e4f11cb
+    term.25c83dac.yaml的interface:
+      <term.50430bca.632214.c83dac.entity.1>: 董事会
+      <term.50430bca.632214.c83dac.term.1>: 章程第八条（十）
+      <term.50430bca.632214.c83dac.term.2>: 中华人民共和国公司法
+- '90': term metadata生成按修订层级排版的COM metadata。
+- '60': 设计条款的可执行机制
+- '90': 整理近期手稿。
+```
+
+- 因为task名称、时间长度、todo项名称都是已知的，所以遍历这个task的todo项，找到位置就可以一句展开bind的后续todo项了。
+- 把多层结构的todo项时间从90改为30
+    - '30': 实现todo项的多层结构

release/time/d.20240511.md

@@ -0,0 +1,409 @@
+# 2024.05.11.
+日小结  
+
+<a id="top"></a>
+根据[ego模型时间接口](https://gitee.com/hyg/blog/blob/master/timeflow.md)，今天绑定模版2。
+
+<a id="index"></a>
+- 07:45	[整理S2状态下基本管理制度](#20240511074500)  
+- 14:00	[完成1609 deploy、COD的metadata](#20240511140000)  
+- 16:00	[了解call和apply](#20240511160000)  
+
+---
+season stat:
+
+| task | alloc | sold | hold | todo |
+| --- | --- | --- | --- | --- |
+| total | 13275 | 9050 | 4225 | 2220 |
+| PSMD | 7000 | 4596 | 2404 | 705 |
+| learn | 1000 | 412 | 588 | 360 |
+| ego | 3000 | 2114 | 886 | 525 |
+| js | 1375 | 615 | 760 | 240 |
+| xuemen | 600 | 926 | -326 | 210 |
+| raw | 300 | 357 | -57 | 180 |
+| infra | 0 | 30 | -30 | 0 |
+
+---
+
+waiting list:
+
+
+- 30分钟时间片：
+  - ego的第1号事项：实现todo项的多层结构
+  - js的第2号事项：学习AMD规范，如果适用就开发范例
+  - learn的第2号事项：YARRRML
+  - learn的第3号事项：docker
+
+- 60分钟时间片：
+  - PSMD的第1号事项：基于智能设备的S2基本管理制度
+  - js的第1号事项：学习promise对象和async/await
+  - learn的第1号事项：github的actions,workflow,job脚本语法
+  - raw的第1号事项：实现自定义DRI,NRV的代码
+
+- 90分钟时间片：
+  - PSMD的第2号事项：COM metadata -> COM view
+  - xuemen的第2号事项：整理S2状态下基本管理制度的metedata
+  - learn的第7号事项：把PSMD的data、src部分升级到rdf，如果升级成功则作为范例。
+  - PSMD的第8号事项：term metadata生成按修订层级排版的COM metadata。
+
+- 195分钟时间片：
+  - PSMD的第3号事项：term + COM matedata -> deploy metadata -> deploy view
+  - ego的第8号事项：在整理近期手稿之后，修订个人模型。
+
+---
+
+[top](#top) | [index](#index)
+<a id="20240511074500"></a>
+## 7:45~10:59
+整理S2状态下基本管理制度
+
+
+### 公司法
+- 无论哪一版公司法，股东会都不能越过董事(会)制订基本管理制度。
+- 股东之一出任S1状态下的董事兼经理，可以董事身份行使董事会职权，制订基本管理制度。
+- S1董事在离任前，按照S2状态的管理需要制订基本管理制度，并且把S1状态下的业务逐渐转移到新制度下，然后再结束S1状态，选举S2状态的董事会。
+    - 通常情况下，S1董事仍然会入选S2董事会或监事会，以保证连贯性。
+- 基于以上分析，S2状态下的基本管理制度，在S1末期基于1406模型（动议套装）056e71fb 启动。
+
+### 智能设备
+- 追加todo项：
+  - '60': 基于智能设备的S2基本管理制度
+
+
+---
+
+[top](#top) | [index](#index)
+<a id="20240511140000"></a>
+## 14:00~15:29
+完成1609 deploy、COD的metadata
+
+- 先不起1609 COM的工作
+    - 由于COM的数量不多，就不用commit了。
+- 可修订、不可修订条款；决策条款、非决策条款两个维度可以正交。
+    - 决策条款定义为可以产生条款：term maker。
+- 顺便编写了term.f70677ff 1609模型的条款形态。
+```
+D:\huangyg\git\PSMD\src>node term term f70677ff
+enter maketermtext:f70677ff     prefix:
+enter maketermtext:c13a43a2     prefix:自修订条款1.
+enter maketermtext:71da4d25     prefix:二级决策条款1.
+enter maketermtext:40880d93     prefix:二级决策条款2.
+enter maketermtext:54b6949d     prefix:二级决策条款3.
+enter maketermtext:95eab800     prefix:二级决策条款4.
+enter maketermtext:0edca872     prefix:二级决策条款5.
+enter maketermtext:32e45dee     prefix:二级决策条款6.
+enter maketermtext:88e5c5f4     prefix:三级决策条款1.
+enter maketermtext:4e9e9c33     prefix:三级决策条款2.
+enter maketermtext:666776c3     prefix:三级决策条款3.
+enter maketermtext:efaeac70     prefix:三级决策条款4.
+enter maketermtext:77666f44     prefix:基本管理制度.
+enter maketermtext:ac890987     prefix:基本管理制度.保密制度.
+enter maketermtext:72af7dea     prefix:基本管理制度.保密制度.1.
+enter maketermtext:02c7d037     prefix:基本管理制度.保密制度.2.
+enter maketermtext:ef4cdffe     prefix:基本管理制度.保密制度.3.
+enter maketermtext:de47ace4     prefix:基本管理制度.利益分配.
+enter maketermtext:c046b09d     prefix:基本管理制度.利益分配.1.
+enter maketermtext:3638eac6     prefix:基本管理制度.利益分配.2.
+enter maketermtext:1558e5e1     prefix:基本管理制度.利益分配.3.
+enter maketermtext:814f76cb     prefix:基本管理制度.利益分配.4.
+enter maketermtext:58d4c137     prefix:基本管理制度.利益分配.5.
+enter maketermtext:c1f65b6d     prefix:基本管理制度.利益分配.5.1.
+enter maketermtext:6568c500     prefix:基本管理制度.利益分配.5.2.
+enter maketermtext:d8bd8aa6     prefix:基本管理制度.利益分配.6.
+enter maketermtext:8a5d94dc     prefix:基本管理制度.利益分配.6.1.
+enter maketermtext:34be50e1     prefix:基本管理制度.利益分配.6.2.
+enter maketermtext:3176f00c     prefix:基本管理制度.利益分配.6.3.
+enter maketermtext:a8ca0160     prefix:基本管理制度.利益分配.6.4.
+enter maketermtext:2a78271e     prefix:基本管理制度.利益分配.6.5.
+enter maketermtext:96b99526     prefix:基本管理制度.利益分配.7.
+enter maketermtext:6d2ca266     prefix:基本管理制度.利益分配.7.1.
+enter maketermtext:fb21bdf9     prefix:基本管理制度.利益分配.7.2.
+enter maketermtext:7f7a536f     prefix:基本管理制度.利益分配.7.3.
+enter maketermtext:a8d575a7     prefix:基本管理制度.利益分配.7.4.
+enter maketermtext:70cdd24d     prefix:基本管理制度.利益分配.7.5.
+enter maketermtext:41312cc4     prefix:基本管理制度.利益分配.7.6.
+enter maketermtext:12d14064     prefix:基本管理制度.利益分配.8.
+enter maketermtext:af62f03b     prefix:基本管理制度.利益分配.8.1.
+enter maketermtext:55cc8467     prefix:基本管理制度.利益分配.8.2.
+enter maketermtext:e4495f38     prefix:基本管理制度.利益分配.8.3.
+../view/term.f70677ff.md文件更新，内容如下:
+条款 f70677ff 正文:
+自修订条款1. 本条款按照本条款修订。由deployer书面提交修订以下事项，提交时生效：
+  - p%
+  - director席位数
+  - director会议议事规则
+  - supervisor席位数
+  - supervisor会议议事规则
+  - director和supervisor任期及选举程序
+  - trustee任期及任免程序
+  - 第一届director
+  - 第一届supervisor
+  - 下一任deployer
+  - 本条款内容
+二级决策条款1. 本条款按照自修订条款1.条款修订。根据director会议议事规则，经三分之二以上director通过可以作出决议。
+二级决策条款2. 本条款按照自修订条款1.条款修订。根据director会议议事规则，经二分之一以上director通过可以作出决议：
+  - director工作计划（含预算案）
+  - director工作报告
+  - 审议报告
+  - 任免admin
+  - 设立、撤销部门
+  - worker劳动合同
+  - 制订基本管理制度
+  - 制订保密文件的脱敏版本
+二级决策条款3. 本条款按照自修订条款1.条款修订。由deployer提出。根据director会议议事规则，经全体director通过可以作出决议。
+二级决策条款4. 本条款按照自修订条款1.条款修订。由deployer提出。根据director会议议事规则，经全体director和trustee通过可以作出决议。
+二级决策条款5. 本条款按照自修订条款1条款修订。根据supervisor会议议事规则，经三分之二supervisor通过可以作出决议：
+  - supervisor工作计划
+  - supervisor工作报告
+  - 审议报告
+  - director任期提前结束，重新进行选举。
+二级决策条款6. 本条款按照自修订条款1条款修订。由trustee书面提交修订以下事项，提交时生效：
+- 预算透支限额
+- director任期提前结束，重新进行选举。
+- supervisor任期提前结束，重新进行选举。
+三级决策条款1. 本条款按照二级决策条款1.条款修订。由admin书面提交修订以下事项，提交时生效：
+  - 工作计划草案
+  - 工作报告
+  - 具体规章
+  - worker名册（及合同）
+三级决策条款2. 本条款按照二级决策条款3.条款修订。全体worker、RIU持有者选举。假设worker合同的报酬RIU总额为w，RIU总额为r，worker手中合同的每个RIU报酬 权重为r*(100-p)，RIU持有者持有的每个RIU权重为w*p。
+  - 如果deployer没有指定继任者又不能工作，选举新任deployer。
+三级决策条款3. 本条款按照二级决策条款3.条款修订。全体worker、RIU持有者选举。假设worker合同的报酬RIU总额为w，RIU总额为r，席位为x，worker手中合同的每 个RIU报酬权重为r*x*p，RIU持有者持有的每个RIU权重为w*x*(100-p)。选举采用累积投票制，不对单独席位进行罢免投票，每次都全部重选。
+  - 选举director
+  - 选举supervisor
+三级决策条款4. 本条款按照二级决策条款4.条款修订。本条款按照<term.f70677ff.level1.4>修订。全体RIU持有者选举，以持有的RIU为权重。
+  - 任免trustee。
+基本管理制度.保密制度.1. 本条款按照自修订条款1.条款修订。本制度正文公开。
+基本管理制度.保密制度.2. 本条款按照自修订条款1.条款修订。不可修订条款、自修订条款、二级决策条款的正文以及执行记录的保密事项由这些条款自己定义，本制 度不得规定。
+基本管理制度.保密制度.3. 本条款按照二级决策程序1.条款修订。其它规章正文及执行记录默认为公开。
+基本管理制度.利益分配.1. 利益分配原则：优先劣后次序与决策层级相反。
+基本管理制度.利益分配.2. 每个成员设一个专户，每个专户可以容纳所有种类的资产。
+基本管理制度.利益分配.3. 本条款按照自修订条款1.条款修订。设四个共同体专户，每个专户可以容纳所有种类的资产。分别由：deployer、trustee、director和supervisor、admin管理。
+基本管理制度.利益分配.4. 本条款按照自修订条款1.条款修订。按照二级决策条款2.设立部门时，开设部门专户，并明确与其它专户的资源交换规则。
+基本管理制度.利益分配.5. deployer专户：
+基本管理制度.利益分配.5.1. 本条款按照自修订条款1.条款修订。deployer专户用于deployer工作经费，以及重构期间发生的短期支出。
+基本管理制度.利益分配.5.2. 本条款按照二级决策条款3.条款修订。每月末将director专户余额的0.5%转入deployer专户。
+基本管理制度.利益分配.6. 本条款按照二级决策条款4.条款修订。trustee专户：
+基本管理制度.利益分配.6.1. 本条款按照二级决策条款4.条款修订。RIU持有者可以将RIU转入trustee专户，委托trustee卖出。
+基本管理制度.利益分配.6.2. 本条款按照二级决策条款4.条款修订。投资者可以将其它资源转入trustee专户，委托trustee买入RIU。
+基本管理制度.利益分配.6.3. 本条款按照二级决策条款4.条款修订。收入的p%用于购买trustee专户中的RIU，低价优先。交易获得的RIU支付trustee报酬后，余额转入director专户。
+基本管理制度.利益分配.6.4. 本条款按照二级决策条款4.条款修订。RIU交易由trustee按价格优先、时间优先原则撮合。
+基本管理制度.利益分配.6.5. 本条款按照二级决策条款4.条款修订。trustee从收入的p%购买的RIU中领取报酬，竞聘者须明确报酬的计算公式。
+基本管理制度.利益分配.7. 本条款按照二级决策条款3.条款修订。director专户由director与supervisor共同使用：
+基本管理制度.利益分配.7.1. 本条款按照二级决策条款3.条款修订。director专户中的RIU可以是负数，最小值由预算透支限额确定。
+基本管理制度.利益分配.7.2. 本条款按照二级决策条款3.条款修订。收入的(100-p)%转入director专户。
+基本管理制度.利益分配.7.3. 本条款按照二级决策条款3.条款修订。按生效的admin工作计划（含预算案）从director专户转入admin专户，余额不足时后续条款的支出 暂缓。
+基本管理制度.利益分配.7.4. 本条款按照二级决策条款3.条款修订。supervisor按supervisor工作计划（含预算案）使用director专户余额，余额不足时后续条款的支 出暂缓。
+基本管理制度.利益分配.7.5. 本条款按照二级决策条款3.条款修订。director按director工作计划（含预算案）使用director专户余额，余额不足时后续条款的支出暂 缓。
+基本管理制度.利益分配.7.6. 本条款按照二级决策条款3.条款修订。deployer、director、supervisor从director专户领取报酬，director、supervisor竞聘者须明确 报酬的计算公式，deployer报酬数额为director、supervisor报酬的中位数。director专户数额不足时以应发数额为权重按比例分配，等候期间不计利息。
+基本管理制度.利益分配.8. admin专户：
+基本管理制度.利益分配.8.1. 本条款按照二级决策条款1.条款修订。admin按admin工作计划（含预算案）调用admin专户中的资源。
+基本管理制度.利益分配.8.2. 本条款按照二级决策条款1.条款修订。member的工作成果提交到admin专户，从admin专户领取报酬，报酬金额在合同中规定。
+基本管理制度.利益分配.8.3. 本条款按照二级决策条款1.条款修订。admin从admin专户领取报酬（优先级在worker之后），竞聘者须明确报酬的计算公式。本专户数额 不足而等候期间不计利息。
+
+---
+readme:
+条款 f70677ff. 二级决策条款2.
+本条款是指针对未规定的事项，制订基本管理制度的第一版。后续版本按照各条款修订权产生。
+基本管理制度.
+基本管理制度.利益分配.
+基本管理制度.利益分配.2.
+- 所有工作成果都属于资产。
+基本管理制度.利益分配.5.
+基本管理制度.利益分配.5.1.
+- deployer无须制订工作计划和预算案。
+- 部署时根据实际情况确定本条的记账方式。
+基本管理制度.利益分配.5.2.
+deployer使用资源的优先级高于director。
+基本管理制度.利益分配.6.
+基本管理制度.利益分配.6.3.
+大部分收入还是由director使用，其中p%体现为RIU（扣除trustee报酬），其余体现为对外交易约定的资源。
+基本管理制度.利益分配.6.5.
+trustee任期内报酬公式不变，如果情况变化可以辞职，再与其他竞聘者一起根据当时情况竞聘。
+基本管理制度.利益分配.7.
+基本管理制度.利益分配.7.3.
+- 工作计划和预算案可以根据工作需要规定资源转入时间，滚动利用预算周期内的交易收入。
+- admin使用资源的优先级高于director和supervisor。
+基本管理制度.利益分配.7.4.
+supervisor使用资源的优先级高于director。
+基本管理制度.利益分配.7.6.
+- deployer、director、supervisor的报酬优先级低于工作支出。
+- director、supervisor任期内报酬公式不变，如果情况变化可以辞职，再与其他竞聘者一起根据当时情况竞聘。
+基本管理制度.利益分配.8.
+基本管理制度.利益分配.8.2.
+- member所包括角色范围根据实际情况界定。通常包括admin、worker，有时也包括一些外部人员、机构。
+- 报酬可能包括不同种类的资源。
+基本管理制度.利益分配.8.3.
+- admin任期内报酬公式不变，如果情况变化可以辞职，再与其他竞聘者一起根据当时情况竞聘。
+
+Warning: missing space before text for line 6 of jade file "undefined"
+Warning: missing space before text for line 8 of jade file "undefined"
+Warning: missing space before text for line 10 of jade file "undefined"
+../view/term.f70677ff.html文件更新，内容如下:
+<html lang="zh-cn"><head><title>term html sample</title><script></script></head><body><h3>条款 f70677ff</h3><hr/><p>正文:</p><p>自修订条款1. 本条款 按照本条款修订。由deployer书面提交修订以下事项，提交时生效：<br/>
+  - p%<br/>
+  - director席位数<br/>
+  - director会议议事规则<br/>
+  - supervisor席位数<br/>
+  - supervisor会议议事规则<br/>
+  - director和supervisor任期及选举程序<br/>
+  - trustee任期及任免程序<br/>
+  - 第一届director<br/>
+  - 第一届supervisor<br/>
+  - 下一任deployer<br/>
+  - 本条款内容<br/>
+二级决策条款1. 本条款按照自修订条款1.条款修订。根据director会议议事规则，经三分之二以上director通过可以作出决议。<br/>
+二级决策条款2. 本条款按照自修订条款1.条款修订。根据director会议议事规则，经二分之一以上director通过可以作出决议：<br/>
+  - director工作计划（含预算案）<br/>
+  - director工作报告<br/>
+  - 审议报告<br/>
+  - 任免admin<br/>
+  - 设立、撤销部门<br/>
+  - worker劳动合同<br/>
+  - 制订基本管理制度<br/>
+  - 制订保密文件的脱敏版本<br/>
+二级决策条款3. 本条款按照自修订条款1.条款修订。由deployer提出。根据director会议议事规则，经全体director通过可以作出决议。<br/>
+二级决策条款4. 本条款按照自修订条款1.条款修订。由deployer提出。根据director会议议事规则，经全体director和trustee通过可以作出决议。<br/>
+二级决策条款5. 本条款按照自修订条款1条款修订。根据supervisor会议议事规则，经三分之二supervisor通过可以作出决议：<br/>
+  - supervisor工作计划<br/>
+  - supervisor工作报告<br/>
+  - 审议报告<br/>
+  - director任期提前结束，重新进行选举。<br/>
+二级决策条款6. 本条款按照自修订条款1条款修订。由trustee书面提交修订以下事项，提交时生效：<br/>
+- 预算透支限额<br/>
+- director任期提前结束，重新进行选举。<br/>
+- supervisor任期提前结束，重新进行选举。<br/>
+三级决策条款1. 本条款按照二级决策条款1.条款修订。由admin书面提交修订以下事项，提交时生效：<br/>
+  - 工作计划草案<br/>
+  - 工作报告<br/>
+  - 具体规章<br/>
+  - worker名册（及合同）<br/>
+三级决策条款2. 本条款按照二级决策条款3.条款修订。全体worker、RIU持有者选举。假设worker合同的报酬RIU总额为w，RIU总额为r，worker手中合同的每个RIU报酬 权重为r*(100-p)，RIU持有者持有的每个RIU权重为w*p。 <br/>
+  - 如果deployer没有指定继任者又不能工作，选举新任deployer。<br/>
+三级决策条款3. 本条款按照二级决策条款3.条款修订。全体worker、RIU持有者选举。假设worker合同的报酬RIU总额为w，RIU总额为r，席位为x，worker手中合同的每 个RIU报酬权重为r*x*p，RIU持有者持有的每个RIU权重为w*x*(100-p)。选举采用累积投票制，不对单独席位进行罢免投票，每次都全部重选。<br/>
+  - 选举director<br/>
+  - 选举supervisor<br/>
+三级决策条款4. 本条款按照二级决策条款4.条款修订。本条款按照<term.f70677ff.level1.4>修订。全体RIU持有者选举，以持有的RIU为权重。<br/>
+  - 任免trustee。<br/>
+基本管理制度.保密制度.1. 本条款按照自修订条款1.条款修订。本制度正文公开。<br/>
+基本管理制度.保密制度.2. 本条款按照自修订条款1.条款修订。不可修订条款、自修订条款、二级决策条款的正文以及执行记录的保密事项由这些条款自己定义，本制 度不得规定。<br/>
+基本管理制度.保密制度.3. 本条款按照二级决策程序1.条款修订。其它规章正文及执行记录默认为公开。<br/>
+基本管理制度.利益分配.1. 利益分配原则：优先劣后次序与决策层级相反。<br/>
+基本管理制度.利益分配.2. 每个成员设一个专户，每个专户可以容纳所有种类的资产。<br/>
+基本管理制度.利益分配.3. 本条款按照自修订条款1.条款修订。设四个共同体专户，每个专户可以容纳所有种类的资产。分别由：deployer、trustee、director和supervisor、admin管理。<br/>
+基本管理制度.利益分配.4. 本条款按照自修订条款1.条款修订。按照二级决策条款2.设立部门时，开设部门专户，并明确与其它专户的资源交换规则。<br/>
+基本管理制度.利益分配.5. deployer专户：<br/>
+基本管理制度.利益分配.5.1. 本条款按照自修订条款1.条款修订。deployer专户用于deployer工作经费，以及重构期间发生的短期支出。<br/>
+基本管理制度.利益分配.5.2. 本条款按照二级决策条款3.条款修订。每月末将director专户余额的0.5%转入deployer专户。<br/>
+基本管理制度.利益分配.6. 本条款按照二级决策条款4.条款修订。trustee专户：<br/>
+基本管理制度.利益分配.6.1. 本条款按照二级决策条款4.条款修订。RIU持有者可以将RIU转入trustee专户，委托trustee卖出。<br/>
+基本管理制度.利益分配.6.2. 本条款按照二级决策条款4.条款修订。投资者可以将其它资源转入trustee专户，委托trustee买入RIU。<br/>
+基本管理制度.利益分配.6.3. 本条款按照二级决策条款4.条款修订。收入的p%用于购买trustee专户中的RIU，低价优先。交易获得的RIU支付trustee报酬后，余额转入director专户。<br/>
+基本管理制度.利益分配.6.4. 本条款按照二级决策条款4.条款修订。RIU交易由trustee按价格优先、时间优先原则撮合。<br/>
+基本管理制度.利益分配.6.5. 本条款按照二级决策条款4.条款修订。trustee从收入的p%购买的RIU中领取报酬，竞聘者须明确报酬的计算公式。<br/>
+基本管理制度.利益分配.7. 本条款按照二级决策条款3.条款修订。director专户由director与supervisor共同使用：<br/>
+基本管理制度.利益分配.7.1. 本条款按照二级决策条款3.条款修订。director专户中的RIU可以是负数，最小值由预算透支限额确定。<br/>
+基本管理制度.利益分配.7.2. 本条款按照二级决策条款3.条款修订。收入的(100-p)%转入director专户。<br/>
+基本管理制度.利益分配.7.3. 本条款按照二级决策条款3.条款修订。按生效的admin工作计划（含预算案）从director专户转入admin专户，余额不足时后续条款的支出 暂缓。<br/>
+基本管理制度.利益分配.7.4. 本条款按照二级决策条款3.条款修订。supervisor按supervisor工作计划（含预算案）使用director专户余额，余额不足时后续条款的支 出暂缓。<br/>
+基本管理制度.利益分配.7.5. 本条款按照二级决策条款3.条款修订。director按director工作计划（含预算案）使用director专户余额，余额不足时后续条款的支出暂 缓。<br/>
+基本管理制度.利益分配.7.6. 本条款按照二级决策条款3.条款修订。deployer、director、supervisor从director专户领取报酬，director、supervisor竞聘者须明确 报酬的计算公式，deployer报酬数额为director、supervisor报酬的中位数。director专户数额不足时以应发数额为权重按比例分配，等候期间不计利息。<br/>
+基本管理制度.利益分配.8. admin专户：<br/>
+基本管理制度.利益分配.8.1. 本条款按照二级决策条款1.条款修订。admin按admin工作计划（含预算案）调用admin专户中的资源。<br/>
+基本管理制度.利益分配.8.2. 本条款按照二级决策条款1.条款修订。member的工作成果提交到admin专户，从admin专户领取报酬，报酬金额在合同中规定。<br/>
+基本管理制度.利益分配.8.3. 本条款按照二级决策条款1.条款修订。admin从admin专户领取报酬（优先级在worker之后），竞聘者须明确报酬的计算公式。本专户数额 不足而等候期间不计利息。<br/>
+</p><hr/><p>注释:</p><p>二级决策条款2.<br/>
+本条款是指针对未规定的事项，制订基本管理制度的第一版。后续版本按照各条款修订权产生。<br/>
+基本管理制度.<br/>
+基本管理制度.利益分配.<br/>
+基本管理制度.利益分配.2.<br/>
+- 所有工作成果都属于资产。<br/>
+基本管理制度.利益分配.5.<br/>
+基本管理制度.利益分配.5.1.<br/>
+- deployer无须制订工作计划和预算案。<br/>
+- 部署时根据实际情况确定本条的记账方式。<br/>
+基本管理制度.利益分配.5.2.<br/>
+deployer使用资源的优先级高于director。<br/>
+基本管理制度.利益分配.6.<br/>
+基本管理制度.利益分配.6.3.<br/>
+大部分收入还是由director使用，其中p%体现为RIU（扣除trustee报酬），其余体现为对外交易约定的资源。<br/>
+基本管理制度.利益分配.6.5.<br/>
+trustee任期内报酬公式不变，如果情况变化可以辞职，再与其他竞聘者一起根据当时情况竞聘。<br/>
+基本管理制度.利益分配.7.<br/>
+基本管理制度.利益分配.7.3.<br/>
+- 工作计划和预算案可以根据工作需要规定资源转入时间，滚动利用预算周期内的交易收入。<br/>
+- admin使用资源的优先级高于director和supervisor。<br/>
+基本管理制度.利益分配.7.4.<br/>
+supervisor使用资源的优先级高于director。<br/>
+基本管理制度.利益分配.7.6.<br/>
+- deployer、director、supervisor的报酬优先级低于工作支出。<br/>
+- director、supervisor任期内报酬公式不变，如果情况变化可以辞职，再与其他竞聘者一起根据当时情况竞聘。<br/>
+基本管理制度.利益分配.8.<br/>
+基本管理制度.利益分配.8.2.<br/>
+- member所包括角色范围根据实际情况界定。通常包括admin、worker，有时也包括一些外部人员、机构。<br/>
+- 报酬可能包括不同种类的资源。<br/>
+基本管理制度.利益分配.8.3.<br/>
+- admin任期内报酬公式不变，如果情况变化可以辞职，再与其他竞聘者一起根据当时情况竞聘。<br/>
+</p><hr/></body></html>
+```
+
+- 起草deploy范例：
+```
+name: deploy范例[X机构部署1609模型]
+id: X-1609
+COM: 1609
+interface:
+  <COM.1609.entity.deployer>: deployer
+  <COM.1609.entity.director>: director
+  <COM.1609.entity.trustee>: trustee
+  <COM.1609.entity.supervisor>: supervisor
+  <COM.1609.entity.admin>: admin
+  <COM.1609.entity.worker>: worker
+  <COM.1609.entity.2>: value
+  <COM.1609.asset.1>: RIU
+  <COM.1609.asset.2>: p
+  <COM.1609.term.1>: 自修订条款
+  <COM.1609.term.2>: director会议议事规则
+  <COM.1609.term.3>: supervisor会议议事规则
+  <COM.1609.localid.1>: value
+deployer: 
+  IRI: ego.mars22.com/hyg
+interface:
+  <term.X-1609.entity.1>: X机构
+  <term.X-1609.entity.2>: 张三
+  <term.X-1609.entity.3>: 李四
+step:
+  - termid: f70677ff
+    map:
+      <COM.1609.entity.deployer>: <term.X-1609.entity.2>
+      <COM.1609.entity.admin>: <term.X-1609.entity.3>
+    y:
+      termid: <COM.1609.term.2>
+      y:
+        termid: <COM.1609.term.3>
+    n: 
+      errorid: 48291d8c
+      y: 
+      n: 
+        termid: 056e71fb
+        readme: |
+          1406
+        y:
+          readme: |
+            先运行起来，根据团队对error 48291d8c的体会计划后续工作。
+        n:
+          readme: |
+            deploy failure.
+readme: |
+logpath: log.x.com
+```
+
+---
+
+[top](#top) | [index](#index)
+<a id="20240511160000"></a>
+## 16:00~16:59
+了解call和apply
+
+定义知道了，还没想到具体项目下的用途。
+- https://zh.javascript.info/call-apply-decorators

release/time/d.20240512.md

@@ -0,0 +1,827 @@
+# 2024.05.12.
+日小结  
+
+<a id="top"></a>
+根据[ego模型时间接口](https://gitee.com/hyg/blog/blob/master/timeflow.md)，今天绑定模版1。
+
+<a id="index"></a>
+- 07:45	[基于智能设备的S2基本管理制度](#20240512074500)  
+- 09:30	[COM metadata -> COM view](#20240512093000)  
+- 14:00	[实现todo项的多层结构](#20240512140000)  
+- 14:30	[学习AMD规范，如果适用就开发范例](#20240512143000)  
+- 16:00	[学习promise对象和async/await](#20240512160000)  
+
+---
+season stat:
+
+| task | alloc | sold | hold | todo |
+| --- | --- | --- | --- | --- |
+| total | 13275 | 9400 | 3875 | 2100 |
+| PSMD | 7000 | 4856 | 2144 | 555 |
+| learn | 1000 | 412 | 588 | 420 |
+| ego | 3000 | 2114 | 886 | 525 |
+| js | 1375 | 705 | 670 | 210 |
+| xuemen | 600 | 926 | -326 | 210 |
+| raw | 300 | 357 | -57 | 180 |
+| infra | 0 | 30 | -30 | 0 |
+
+---
+
+waiting list:
+
+
+- 30分钟时间片：
+  - PSMD的第1号事项：修订入门目录term.9d12877c，准备实际使用。
+  - ego的第1号事项：实现todo项的多层结构
+  - js的第1号事项：继续学习promise api
+  - js的第2号事项：学习AMD规范，如果适用就开发范例
+
+- 60分钟时间片：
+  - learn的第1号事项：freenet的contract
+  - raw的第1号事项：实现自定义DRI,NRV的代码
+  - xuemen的第1号事项：五月报税
+  - ego的第2号事项：/release/entry.html 读取 markdown和metadata 并显示。
+
+- 90分钟时间片：
+  - xuemen的第2号事项：整理S2状态下基本管理制度的metedata
+  - PSMD的第6号事项：term metadata生成按修订层级排版的COM metadata。
+  - PSMD的第8号事项：整理近期手稿。
+  - learn的第8号事项：把PSMD的data、src部分升级到rdf，如果升级成功则作为范例。
+
+- 195分钟时间片：
+  - PSMD的第2号事项：term + COM matedata -> deploy metadata -> deploy view
+  - ego的第8号事项：在整理近期手稿之后，修订个人模型。
+
+---
+
+[top](#top) | [index](#index)
+<a id="20240512074500"></a>
+## 7:45~8:44
+基于智能设备的S2基本管理制度
+
+- 抛开公司法框架，基于1609的决策条款设计基本管理制度。
+- 分解自修订条款：
+    - 程序上的细节，deployer可以自行定义，以免被架空。
+    - 职权范围必须锁死，由二级决策条款4.来修改。
+- 状态切换交给trustee，二级决策条款6.。
+
+```
+D:\huangyg\git\PSMD\src>node term commit
+commit error.1.yaml
+执行部门陷入割据 0ccddb29
+commit error.2.yaml
+无法有效分配未来收入 48291d8c
+commit knowledge.1.yaml
+1406解决割据问题 3b7582cd
+commit knowledge.2.yaml
+1609解决资源问题 d8a0602f
+commit term.1.yaml
+基于1609模型决策条款设计的S2基本管理制度 bfa1c02e
+commit term.11.yaml
+deployer职权 06c7f1ef
+commit term.2.yaml
+1609-二级决策条款-6+设置状态 aa22a167
+commit term.3.yaml
+S2部门设置 85414146
+../data/term.bfa1c02e.yaml文件已更新。../data/term.1.yaml可以删除。
+../data/term.aa22a167.yaml文件已更新。../data/term.2.yaml可以删除。
+../data/term.85414146.yaml文件已更新。../data/term.3.yaml可以删除。
+../data/term.06c7f1ef.yaml文件已更新。../data/term.11.yaml可以删除。
+../data/error.0ccddb29.yaml文件已更新。../data/error.1.yaml可以删除。
+../data/error.48291d8c.yaml文件已更新。../data/error.2.yaml可以删除。
+knowledge depend replace. error:2 -> 48291d8c
+../data/knowledge.3b7582cd.yaml文件已更新。../data/knowledge.1.yaml可以删除。
+旧文件:../data/knowledge.2.yaml中depend字段的id: cde3c3e2 未能替换，请人工检查。
+旧文件:../data/knowledge.2.yaml中objid: 5b4e0597 未能替换，请人工检查。
+knowledge effect replace. id:2 -> 48291d8c
+../data/knowledge.d8a0602f.yaml文件已更新。../data/knowledge.2.yaml可以删除。
+
+D:\huangyg\git\PSMD\src>node term term bfa1c02e
+enter maketermtext:bfa1c02e     upgradeby:undefined     prefix:
+enter maketermtext:c13a43a2     upgradeby:自修订条款1   prefix:自修订条款1.
+enter maketermtext:71da4d25     upgradeby:自修订条款1   prefix:S2二级决策条款1.
+enter maketermtext:40880d93     upgradeby:自修订条款1   prefix:S2二级决策条款2.
+enter maketermtext:54b6949d     upgradeby:自修订条款1   prefix:S2二级决策条款3.
+enter maketermtext:95eab800     upgradeby:自修订条款1   prefix:S2二级决策条款4.
+enter maketermtext:0edca872     upgradeby:<term.bfa1c02e.term.1>        prefix:S2二级决策条款5.
+enter maketermtext:aa22a167     upgradeby:<term.bfa1c02e.term.1>        prefix:S2二级决策条款6.
+enter maketermtext:88e5c5f4     upgradeby:S2二级决策条款1       prefix:S2三级决策条款1.
+enter maketermtext:4e9e9c33     upgradeby:S2二级决策条款3       prefix:S2三级决策条款2.
+enter maketermtext:666776c3     upgradeby:S2二级决策条款3       prefix:S2三级决策条款3.
+enter maketermtext:efaeac70     upgradeby:S2二级决策条款4       prefix:S2三级决策条款4.
+enter maketermtext:06c7f1ef     upgradeby:S2二级决策条款4       prefix:职权分配1.
+enter maketermtext:77666f44     upgradeby:undefined     prefix:S2基本管理制度.
+enter maketermtext:ac890987     upgradeby:undefined     prefix:S2基本管理制度.保密制度.
+enter maketermtext:72af7dea     upgradeby:<term.ac890987.term.1>        prefix:S2基本管理制度.保密制度.1.
+enter maketermtext:02c7d037     upgradeby:<term.ac890987.term.1>        prefix:S2基本管理制度.保密制度.2.
+enter maketermtext:ef4cdffe     upgradeby:<term.ac890987.term.2>        prefix:S2基本管理制度.保密制度.3.
+enter maketermtext:de47ace4     upgradeby:undefined     prefix:S2基本管理制度.利益分配.
+enter maketermtext:c046b09d     upgradeby:undefined     prefix:S2基本管理制度.利益分配.1.
+enter maketermtext:3638eac6     upgradeby:undefined     prefix:S2基本管理制度.利益分配.2.
+enter maketermtext:1558e5e1     upgradeby:undefined     prefix:S2基本管理制度.利益分配.3.
+enter maketermtext:814f76cb     upgradeby:undefined     prefix:S2基本管理制度.利益分配.4.
+enter maketermtext:58d4c137     upgradeby:undefined     prefix:S2基本管理制度.利益分配.5.
+enter maketermtext:c1f65b6d     upgradeby:undefined     prefix:S2基本管理制度.利益分配.5.1.
+enter maketermtext:6568c500     upgradeby:undefined     prefix:S2基本管理制度.利益分配.5.2.
+enter maketermtext:d8bd8aa6     upgradeby:undefined     prefix:S2基本管理制度.利益分配.6.
+enter maketermtext:8a5d94dc     upgradeby:<term.d8bd8aa6.term.1>        prefix:S2基本管理制度.利益分配.6.1.
+enter maketermtext:34be50e1     upgradeby:<term.d8bd8aa6.term.1>        prefix:S2基本管理制度.利益分配.6.2.
+enter maketermtext:3176f00c     upgradeby:<term.d8bd8aa6.term.1>        prefix:S2基本管理制度.利益分配.6.3.
+enter maketermtext:a8ca0160     upgradeby:<term.d8bd8aa6.term.1>        prefix:S2基本管理制度.利益分配.6.4.
+enter maketermtext:2a78271e     upgradeby:<term.d8bd8aa6.term.1>        prefix:S2基本管理制度.利益分配.6.5.
+enter maketermtext:96b99526     upgradeby:undefined     prefix:S2基本管理制度.利益分配.7.
+enter maketermtext:6d2ca266     upgradeby:<term.96b99526.term.1>        prefix:S2基本管理制度.利益分配.7.1.
+enter maketermtext:fb21bdf9     upgradeby:<term.96b99526.term.1>        prefix:S2基本管理制度.利益分配.7.2.
+enter maketermtext:7f7a536f     upgradeby:<term.96b99526.term.1>        prefix:S2基本管理制度.利益分配.7.3.
+enter maketermtext:a8d575a7     upgradeby:<term.96b99526.term.1>        prefix:S2基本管理制度.利益分配.7.4.
+enter maketermtext:70cdd24d     upgradeby:<term.96b99526.term.1>        prefix:S2基本管理制度.利益分配.7.5.
+enter maketermtext:41312cc4     upgradeby:<term.96b99526.term.1>        prefix:S2基本管理制度.利益分配.7.6.
+enter maketermtext:12d14064     upgradeby:undefined     prefix:S2基本管理制度.利益分配.8.
+enter maketermtext:af62f03b     upgradeby:<term.12d14064.term.1>        prefix:S2基本管理制度.利益分配.8.1.
+enter maketermtext:55cc8467     upgradeby:<term.12d14064.term.1>        prefix:S2基本管理制度.利益分配.8.2.
+enter maketermtext:e4495f38     upgradeby:<term.12d14064.term.1>        prefix:S2基本管理制度.利益分配.8.3.
+enter maketermtext:056e71fb     upgradeby:<term.77666f44.term.2>        prefix:S2基本管理制度.1406条款.
+enter maketermtext:48577ce8     upgradeby:<term.77666f44.term.2>        prefix:S2基本管理制度.1406条款.1.
+enter maketermtext:7506353d     upgradeby:<term.77666f44.term.2>        prefix:S2基本管理制度.1406条款.2.
+enter maketermtext:260ca049     upgradeby:<term.77666f44.term.2>        prefix:S2基本管理制度.1406条款.3.
+enter maketermtext:c87ec159     upgradeby:<term.77666f44.term.2>        prefix:S2基本管理制度.1406条款.4.
+enter maketermtext:85414146     upgradeby:S2二级决策条款2       prefix:S2部门设置.
+../view/term.bfa1c02e.md文件更新，内容如下:
+条款 bfa1c02e 正文:
+自修订条款1. 本条款按照自修订条款1.条款修订。由deployer书面提交即可行使职权。deployer职权包括修订本条款内容。
+S2二级决策条款1. 本条款按照自修订条款1.条款修订。根据director会议议事规则，经三分之二以上director通过可以作出决议。
+S2二级决策条款2. 本条款按照自修订条款1.条款修订。根据director会议议事规则，经二分之一以上director通过可以作出决议：
+  - director工作计划（含预算案）
+  - director工作报告
+  - 审议报告
+  - 任免admin
+  - admin工作计划（含预算案）
+  - 设立、撤销部门
+  - worker劳动合同
+  - 制订基本管理制度
+  - 制订保密文件的脱敏版本
+S2二级决策条款3. 本条款按照自修订条款1.条款修订。由deployer提出。根据director会议议事规则，经全体director通过可以作出决议。
+S2二级决策条款4. 本条款按照自修订条款1.条款修订。由deployer提出。根据director会议议事规则，经全体director和trustee通过可以作出决议。
+S2二级决策条款5. 本条款按照自修订条款1.条款修订。根据supervisor会议议事规则，经三分之二supervisor通过可以作出决议：
+  - supervisor工作计划
+  - supervisor工作报告
+  - 审议报告
+  - director任期提前结束，重新进行选举。
+S2二级决策条款6. 本条款按照自修订条款1.条款修订。由trustee书面提交修订以下事项，提交时生效：
+- 预算透支限额
+- director任期提前结束，重新进行选举。
+- supervisor任期提前结束，重新进行选举。
+- 共同体的状态
+S2三级决策条款1. 本条款按照S2二级决策条款1.条款修订。由admin书面提交修订以下事项，提交时生效：
+  - admin工作计划草案
+  - admin工作报告
+  - 具体规章
+  - worker名册（及合同）
+S2三级决策条款2. 本条款按照S2二级决策条款3.条款修订。全体worker、RIU持有者选举。假设worker合同的报酬RIU总额为w，RIU总额为r，worker手中合同的每个RIU 报酬权重为r*(100-p)，RIU持有者持有的每个RIU权重为w*p。
+  - 如果deployer没有指定继任者又不能工作，选举新任deployer。
+S2三级决策条款3. 本条款按照S2二级决策条款3.条款修订。全体worker、RIU持有者选举。假设worker合同的报酬RIU总额为w，RIU总额为r，席位为x，worker手中合同 的每个RIU报酬权重为r*x*p，RIU持有者持有的每个RIU权重为w*x*(100-p)。选举采用累积投票制，不对单独席位进行罢免投票，每次都全部重选。
+  - 选举director
+  - 选举supervisor
+S2三级决策条款4. 本条款按照S2二级决策条款4.条款修订。本条款按照<term.bfa1c02e.level1.4>修订。全体RIU持有者选举，以持有的RIU为权重。
+  - 任免trustee。
+职权分配1. 本条款按照S2二级决策条款4.条款修订。deployer行使以下职权：
+  - 设定p%
+  - 设定director席位数
+  - 制定director会议议事规则
+  - 设定supervisor席位数
+  - 制定supervisor会议议事规则
+  - 确定director和supervisor任期及选举程序
+  - 确定trustee任期及任免程序
+  - 任命第一届director
+  - 任命第一届supervisor
+  - 任命下一任deployer
+  - 修改自修订条款1内容
+S2基本管理制度.保密制度.1. 本条款按照自修订条款1.条款修订。本制度正文公开。
+S2基本管理制度.保密制度.2. 本条款按照自修订条款1.条款修订。不可修订条款、自修订条款、二级决策条款的正文以及执行记录的保密事项由这些条款自己定义，本 制度不得规定。
+S2基本管理制度.保密制度.3. 本条款按照二级决策条款1.条款修订。其它规章正文及执行记录默认为公开。
+S2基本管理制度.利益分配.1. 利益分配原则：优先劣后次序与决策层级相反。
+S2基本管理制度.利益分配.2. 每个成员设一个专户，每个专户可以容纳所有种类的资产。
+S2基本管理制度.利益分配.3. 本条款按照自修订条款1.条款修订。设四个共同体专户，每个专户可以容纳所有种类的资产。分别由：deployer、trustee、director和supervisor、admin管理。
+S2基本管理制度.利益分配.4. 本条款按照自修订条款1.条款修订。按照二级决策条款2.设立部门时，开设部门专户，并明确与其它专户的资源交换规则。
+S2基本管理制度.利益分配.5. deployer专户：
+S2基本管理制度.利益分配.5.1. 本条款按照自修订条款1.条款修订。deployer专户用于deployer工作经费，以及重构期间发生的短期支出。
+S2基本管理制度.利益分配.5.2. 本条款按照二级决策条款3.条款修订。每月末将director专户余额的0.5%转入deployer专户。
+S2基本管理制度.利益分配.6. 本条款按照二级决策条款4.条款修订。trustee专户：
+S2基本管理制度.利益分配.6.1. 本条款按照二级决策条款4.条款修订。RIU持有者可以将RIU转入trustee专户，委托trustee卖出。
+S2基本管理制度.利益分配.6.2. 本条款按照二级决策条款4.条款修订。投资者可以将其它资源转入trustee专户，委托trustee买入RIU。
+S2基本管理制度.利益分配.6.3. 本条款按照二级决策条款4.条款修订。收入的p%用于购买trustee专户中的RIU，低价优先。交易获得的RIU支付trustee报酬后，余额转 入director专户。
+S2基本管理制度.利益分配.6.4. 本条款按照二级决策条款4.条款修订。RIU交易由trustee按价格优先、时间优先原则撮合。
+S2基本管理制度.利益分配.6.5. 本条款按照二级决策条款4.条款修订。trustee从收入的p%购买的RIU中领取报酬，竞聘者须明确报酬的计算公式。
+S2基本管理制度.利益分配.7. 本条款按照二级决策条款3.条款修订。director专户由director与supervisor共同使用：
+S2基本管理制度.利益分配.7.1. 本条款按照二级决策条款3.条款修订。director专户中的RIU可以是负数，最小值由预算透支限额确定。
+S2基本管理制度.利益分配.7.2. 本条款按照二级决策条款3.条款修订。收入的(100-p)%转入director专户。
+S2基本管理制度.利益分配.7.3. 本条款按照二级决策条款3.条款修订。按生效的admin工作计划（含预算案）从director专户转入admin专户，余额不足时后续条款的支 出暂缓。
+S2基本管理制度.利益分配.7.4. 本条款按照二级决策条款3.条款修订。supervisor按supervisor工作计划（含预算案）使用director专户余额，余额不足时后续条款的 支出暂缓。
+S2基本管理制度.利益分配.7.5. 本条款按照二级决策条款3.条款修订。director按director工作计划（含预算案）使用director专户余额，余额不足时后续条款的支出 暂缓。
+S2基本管理制度.利益分配.7.6. 本条款按照二级决策条款3.条款修订。deployer、director、supervisor从director专户领取报酬，director、supervisor竞聘者须明 确报酬的计算公式，deployer报酬数额为director、supervisor报酬的中位数。director专户数额不足时以应发数额为权重按比例分配，等候期间不计利息。
+S2基本管理制度.利益分配.8. 本条款按照二级决策条款1.条款修订。admin专户：
+S2基本管理制度.利益分配.8.1. 本条款按照二级决策条款1.条款修订。admin按admin工作计划（含预算案）调用admin专户中的资源。
+S2基本管理制度.利益分配.8.2. 本条款按照二级决策条款1.条款修订。member的工作成果提交到admin专户，从admin专户领取报酬，报酬金额在合同中规定。
+S2基本管理制度.利益分配.8.3. 本条款按照二级决策条款1.条款修订。admin从admin专户领取报酬（优先级在worker之后），竞聘者须明确报酬的计算公式。本专户数 额不足而等候期间不计利息。
+S2基本管理制度.1406条款.1. 本条款按照S2二级决策条款2.条款修订。在执行部门内，基本管理制度和劳动合同未定义的事项由admin直接指挥。
+S2基本管理制度.1406条款.2. 本条款按照S2二级决策条款2.条款修订。直接指挥的方式：
+  - admin填写通用工单明确事项的处理要求，并交给负责执行的成员；
+  - admin制订具体规章明确事项的处理要求，并提交给director会议备案，director会议签收后具体规章即生效。执行部门成员根据生效的具体规章自行填写通用工单 并执行。
+S2基本管理制度.1406条款.3. 本条款按照S2二级决策条款2.条款修订。admin和执行人员都要向director会议归档通用工单。执行人员应在收到或自行填写通用工单24小时内归档。admin填写的通用工单归档要求是：
+  - 在director会议的一个审议周期内，每一事项的前3份通用工单，应在出具24小时内向director会议归档；
+  - 在director会议的一个审议周期内，同一事项的第4份通用工单起，可以汇总后在审议周期结束前一并归档。
+S2基本管理制度.1406条款.4. 本条款按照S2二级决策条款2.条款修订。director会议成员应：
+  - 在审议周期的第10天结束前阅读完上一个审议周期结束前归档的通用工单，提交审议报告以及基本管理制度的修订动议。
+  - 在审议周期的第20天结束前阅读完其他成员提交的审议报告和基本管理制度的修订动议，提交审议报告。
+  - 在审议周期结束前对基本管理制度修订动议进行表决。
+S2部门设置. 本条款按照S2二级决策条款2.条款修订。共同体设置产品部(IPU:Inner Product Unit)，负责参与JPU（Joint Product Unit）。共同体设置内务部(ISU:Inner Service Unit)，委托内务部(ISU:Inner Service Unit)管理共同体的资产（办公室、服务器及域名、人民币、内部记账单位、知识产权）。
+
+---
+readme:
+条款 bfa1c02e. 自修订条款1.
+为了防止deployer被架空，规定其自行定义程序上的细节。部署后根据实体地址和位置、接收人员的职务名称、服务器域名和IP地址等信息，可以修改提交方式。
+S2二级决策条款2.
+本条款是指针对未规定的事项，制订基本管理制度的第一版。后续版本按照各条款修订权产生。
+S2基本管理制度.
+S2基本管理制度.利益分配.
+S2基本管理制度.利益分配.2.
+- 所有工作成果都属于资产。
+S2基本管理制度.利益分配.5.
+S2基本管理制度.利益分配.5.1.
+- deployer无须制订工作计划和预算案。
+- 部署时根据实际情况确定本条的记账方式。
+S2基本管理制度.利益分配.5.2.
+deployer使用资源的优先级高于director。
+S2基本管理制度.利益分配.6.
+S2基本管理制度.利益分配.6.3.
+大部分收入还是由director使用，其中p%体现为RIU（扣除trustee报酬），其余体现为对外交易约定的资源。
+S2基本管理制度.利益分配.6.5.
+trustee任期内报酬公式不变，如果情况变化可以辞职，再与其他竞聘者一起根据当时情况竞聘。
+S2基本管理制度.利益分配.7.
+S2基本管理制度.利益分配.7.3.
+- 工作计划和预算案可以根据工作需要规定资源转入时间，滚动利用预算周期内的交易收入。
+- admin使用资源的优先级高于director和supervisor。
+S2基本管理制度.利益分配.7.4.
+supervisor使用资源的优先级高于director。
+S2基本管理制度.利益分配.7.6.
+- deployer、director、supervisor的报酬优先级低于工作支出。
+- director、supervisor任期内报酬公式不变，如果情况变化可以辞职，再与其他竞聘者一起根据当时情况竞聘。
+S2基本管理制度.利益分配.8.
+S2基本管理制度.利益分配.8.2.
+- member所包括角色范围根据实际情况界定。通常包括admin、worker，有时也包括一些外部人员、机构。
+- 报酬可能包括不同种类的资源。
+S2基本管理制度.利益分配.8.3.
+- admin任期内报酬公式不变，如果情况变化可以辞职，再与其他竞聘者一起根据当时情况竞聘。
+S2基本管理制度.1406条款.
+1406准确的定位是director会议的动议套件，可以用作其它模型的附件。 ​​​
+S2基本管理制度.1406条款.2.
+在使用IT系统时，可修改为admin向系统提交通用工单，并由系统通知负责执行的成员。
+S2基本管理制度.1406条款.3.
+- 如果出现重大失误，director会议可能召开临时会议干预。所以要求及时归档。
+- 在使用IT系统时，可以由系统实时归档。本条款可以根据情况修订。
+S2基本管理制度.1406条款.4.
+- 时间按一月一周期安排，只是范例。可以根据基本管理制度的完善程度自行调节，从一周到一年都可以考虑。
+- 基本管理制度生效后，所规定的工作事项就不再允许admin直接指挥。相应的具体规章也同时失效。
+- 基本管理制度的规定，可能与通用工单规定的相同、相似、相反......
+
+Warning: missing space before text for line 6 of jade file "undefined"
+Warning: missing space before text for line 8 of jade file "undefined"
+Warning: missing space before text for line 10 of jade file "undefined"
+../view/term.bfa1c02e.html文件更新，内容如下:
+<html lang="zh-cn"><head><title>term html sample</title><script></script></head><body><h3>条款 bfa1c02e</h3><hr/><p>正文:</p><p>自修订条款1. 本条款 按照自修订条款1.条款修订。由deployer书面提交即可行使职权。deployer职权包括修订本条款内容。<br/>
+S2二级决策条款1. 本条款按照自修订条款1.条款修订。根据director会议议事规则，经三分之二以上director通过可以作出决议。<br/>
+S2二级决策条款2. 本条款按照自修订条款1.条款修订。根据director会议议事规则，经二分之一以上director通过可以作出决议：<br/>
+  - director工作计划（含预算案）<br/>
+  - director工作报告<br/>
+  - 审议报告<br/>
+  - 任免admin<br/>
+  - admin工作计划（含预算案）<br/>
+  - 设立、撤销部门<br/>
+  - worker劳动合同<br/>
+  - 制订基本管理制度<br/>
+  - 制订保密文件的脱敏版本<br/>
+S2二级决策条款3. 本条款按照自修订条款1.条款修订。由deployer提出。根据director会议议事规则，经全体director通过可以作出决议。<br/>
+S2二级决策条款4. 本条款按照自修订条款1.条款修订。由deployer提出。根据director会议议事规则，经全体director和trustee通过可以作出决议。<br/>
+S2二级决策条款5. 本条款按照自修订条款1.条款修订。根据supervisor会议议事规则，经三分之二supervisor通过可以作出决议：<br/>
+  - supervisor工作计划<br/>
+  - supervisor工作报告<br/>
+  - 审议报告<br/>
+  - director任期提前结束，重新进行选举。<br/>
+S2二级决策条款6. 本条款按照自修订条款1.条款修订。由trustee书面提交修订以下事项，提交时生效：<br/>
+- 预算透支限额<br/>
+- director任期提前结束，重新进行选举。<br/>
+- supervisor任期提前结束，重新进行选举。<br/>
+- 共同体的状态<br/>
+S2三级决策条款1. 本条款按照S2二级决策条款1.条款修订。由admin书面提交修订以下事项，提交时生效：<br/>
+  - admin工作计划草案<br/>
+  - admin工作报告<br/>
+  - 具体规章<br/>
+  - worker名册（及合同）<br/>
+S2三级决策条款2. 本条款按照S2二级决策条款3.条款修订。全体worker、RIU持有者选举。假设worker合同的报酬RIU总额为w，RIU总额为r，worker手中合同的每个RIU 报酬权重为r*(100-p)，RIU持有者持有的每个RIU权重为w*p。 <br/>
+  - 如果deployer没有指定继任者又不能工作，选举新任deployer。<br/>
+S2三级决策条款3. 本条款按照S2二级决策条款3.条款修订。全体worker、RIU持有者选举。假设worker合同的报酬RIU总额为w，RIU总额为r，席位为x，worker手中合同 的每个RIU报酬权重为r*x*p，RIU持有者持有的每个RIU权重为w*x*(100-p)。选举采用累积投票制，不对单独席位进行罢免投票，每次都全部重选。<br/>
+  - 选举director<br/>
+  - 选举supervisor<br/>
+S2三级决策条款4. 本条款按照S2二级决策条款4.条款修订。本条款按照<term.bfa1c02e.level1.4>修订。全体RIU持有者选举，以持有的RIU为权重。<br/>
+  - 任免trustee。<br/>
+职权分配1. 本条款按照S2二级决策条款4.条款修订。deployer行使以下职权：<br/>
+  - 设定p%<br/>
+  - 设定director席位数<br/>
+  - 制定director会议议事规则<br/>
+  - 设定supervisor席位数<br/>
+  - 制定supervisor会议议事规则<br/>
+  - 确定director和supervisor任期及选举程序<br/>
+  - 确定trustee任期及任免程序<br/>
+  - 任命第一届director<br/>
+  - 任命第一届supervisor<br/>
+  - 任命下一任deployer<br/>
+  - 修改自修订条款1内容<br/>
+S2基本管理制度.保密制度.1. 本条款按照自修订条款1.条款修订。本制度正文公开。<br/>
+S2基本管理制度.保密制度.2. 本条款按照自修订条款1.条款修订。不可修订条款、自修订条款、二级决策条款的正文以及执行记录的保密事项由这些条款自己定义，本 制度不得规定。<br/>
+S2基本管理制度.保密制度.3. 本条款按照二级决策条款1.条款修订。其它规章正文及执行记录默认为公开。<br/>
+S2基本管理制度.利益分配.1. 利益分配原则：优先劣后次序与决策层级相反。<br/>
+S2基本管理制度.利益分配.2. 每个成员设一个专户，每个专户可以容纳所有种类的资产。<br/>
+S2基本管理制度.利益分配.3. 本条款按照自修订条款1.条款修订。设四个共同体专户，每个专户可以容纳所有种类的资产。分别由：deployer、trustee、director和supervisor、admin管理。<br/>
+S2基本管理制度.利益分配.4. 本条款按照自修订条款1.条款修订。按照二级决策条款2.设立部门时，开设部门专户，并明确与其它专户的资源交换规则。<br/>
+S2基本管理制度.利益分配.5. deployer专户：<br/>
+S2基本管理制度.利益分配.5.1. 本条款按照自修订条款1.条款修订。deployer专户用于deployer工作经费，以及重构期间发生的短期支出。<br/>
+S2基本管理制度.利益分配.5.2. 本条款按照二级决策条款3.条款修订。每月末将director专户余额的0.5%转入deployer专户。<br/>
+S2基本管理制度.利益分配.6. 本条款按照二级决策条款4.条款修订。trustee专户：<br/>
+S2基本管理制度.利益分配.6.1. 本条款按照二级决策条款4.条款修订。RIU持有者可以将RIU转入trustee专户，委托trustee卖出。<br/>
+S2基本管理制度.利益分配.6.2. 本条款按照二级决策条款4.条款修订。投资者可以将其它资源转入trustee专户，委托trustee买入RIU。<br/>
+S2基本管理制度.利益分配.6.3. 本条款按照二级决策条款4.条款修订。收入的p%用于购买trustee专户中的RIU，低价优先。交易获得的RIU支付trustee报酬后，余额转 入director专户。<br/>
+S2基本管理制度.利益分配.6.4. 本条款按照二级决策条款4.条款修订。RIU交易由trustee按价格优先、时间优先原则撮合。<br/>
+S2基本管理制度.利益分配.6.5. 本条款按照二级决策条款4.条款修订。trustee从收入的p%购买的RIU中领取报酬，竞聘者须明确报酬的计算公式。<br/>
+S2基本管理制度.利益分配.7. 本条款按照二级决策条款3.条款修订。director专户由director与supervisor共同使用：<br/>
+S2基本管理制度.利益分配.7.1. 本条款按照二级决策条款3.条款修订。director专户中的RIU可以是负数，最小值由预算透支限额确定。<br/>
+S2基本管理制度.利益分配.7.2. 本条款按照二级决策条款3.条款修订。收入的(100-p)%转入director专户。<br/>
+S2基本管理制度.利益分配.7.3. 本条款按照二级决策条款3.条款修订。按生效的admin工作计划（含预算案）从director专户转入admin专户，余额不足时后续条款的支 出暂缓。<br/>
+S2基本管理制度.利益分配.7.4. 本条款按照二级决策条款3.条款修订。supervisor按supervisor工作计划（含预算案）使用director专户余额，余额不足时后续条款的 支出暂缓。<br/>
+S2基本管理制度.利益分配.7.5. 本条款按照二级决策条款3.条款修订。director按director工作计划（含预算案）使用director专户余额，余额不足时后续条款的支出 暂缓。<br/>
+S2基本管理制度.利益分配.7.6. 本条款按照二级决策条款3.条款修订。deployer、director、supervisor从director专户领取报酬，director、supervisor竞聘者须明 确报酬的计算公式，deployer报酬数额为director、supervisor报酬的中位数。director专户数额不足时以应发数额为权重按比例分配，等候期间不计利息。<br/>
+S2基本管理制度.利益分配.8. 本条款按照二级决策条款1.条款修订。admin专户：<br/>
+S2基本管理制度.利益分配.8.1. 本条款按照二级决策条款1.条款修订。admin按admin工作计划（含预算案）调用admin专户中的资源。<br/>
+S2基本管理制度.利益分配.8.2. 本条款按照二级决策条款1.条款修订。member的工作成果提交到admin专户，从admin专户领取报酬，报酬金额在合同中规定。<br/>
+S2基本管理制度.利益分配.8.3. 本条款按照二级决策条款1.条款修订。admin从admin专户领取报酬（优先级在worker之后），竞聘者须明确报酬的计算公式。本专户数 额不足而等候期间不计利息。<br/>
+S2基本管理制度.1406条款.1. 本条款按照S2二级决策条款2.条款修订。在执行部门内，基本管理制度和劳动合同未定义的事项由admin直接指挥。<br/>
+S2基本管理制度.1406条款.2. 本条款按照S2二级决策条款2.条款修订。直接指挥的方式：<br/>
+  - admin填写通用工单明确事项的处理要求，并交给负责执行的成员；<br/>
+  - admin制订具体规章明确事项的处理要求，并提交给director会议备案，director会议签收后具体规章即生效。执行部门成员根据生效的具体规章自行填写通用工单 并执行。<br/>
+S2基本管理制度.1406条款.3. 本条款按照S2二级决策条款2.条款修订。admin和执行人员都要向director会议归档通用工单。执行人员应在收到或自行填写通用工单24小时内归档。admin填写的通用工单归档要求是：<br/>
+  - 在director会议的一个审议周期内，每一事项的前3份通用工单，应在出具24小时内向director会议归档；<br/>
+  - 在director会议的一个审议周期内，同一事项的第4份通用工单起，可以汇总后在审议周期结束前一并归档。<br/>
+S2基本管理制度.1406条款.4. 本条款按照S2二级决策条款2.条款修订。director会议成员应：<br/>
+  - 在审议周期的第10天结束前阅读完上一个审议周期结束前归档的通用工单，提交审议报告以及基本管理制度的修订动议。<br/>
+  - 在审议周期的第20天结束前阅读完其他成员提交的审议报告和基本管理制度的修订动议，提交审议报告。<br/>
+  - 在审议周期结束前对基本管理制度修订动议进行表决。<br/>
+S2部门设置. 本条款按照S2二级决策条款2.条款修订。共同体设置产品部(IPU:Inner Product Unit)，负责参与JPU（Joint Product Unit）。共同体设置内务部(ISU:Inner Service Unit)，委托内务部(ISU:Inner Service Unit)管理共同体的资产（办公室、服务器及域名、人民币、内部记账单位、知识产权）。<br/>
+</p><hr/><p>注释:</p><p>自修订条款1.<br/>
+为了防止deployer被架空，规定其自行定义程序上的细节。部署后根据实体地址和位置、接收人员的职务名称、服务器域名和IP地址等信息，可以修改提交方式。<br/>
+S2二级决策条款2.<br/>
+本条款是指针对未规定的事项，制订基本管理制度的第一版。后续版本按照各条款修订权产生。<br/>
+S2基本管理制度.<br/>
+S2基本管理制度.利益分配.<br/>
+S2基本管理制度.利益分配.2.<br/>
+- 所有工作成果都属于资产。<br/>
+S2基本管理制度.利益分配.5.<br/>
+S2基本管理制度.利益分配.5.1.<br/>
+- deployer无须制订工作计划和预算案。<br/>
+- 部署时根据实际情况确定本条的记账方式。<br/>
+S2基本管理制度.利益分配.5.2.<br/>
+deployer使用资源的优先级高于director。<br/>
+S2基本管理制度.利益分配.6.<br/>
+S2基本管理制度.利益分配.6.3.<br/>
+大部分收入还是由director使用，其中p%体现为RIU（扣除trustee报酬），其余体现为对外交易约定的资源。<br/>
+S2基本管理制度.利益分配.6.5.<br/>
+trustee任期内报酬公式不变，如果情况变化可以辞职，再与其他竞聘者一起根据当时情况竞聘。<br/>
+S2基本管理制度.利益分配.7.<br/>
+S2基本管理制度.利益分配.7.3.<br/>
+- 工作计划和预算案可以根据工作需要规定资源转入时间，滚动利用预算周期内的交易收入。<br/>
+- admin使用资源的优先级高于director和supervisor。<br/>
+S2基本管理制度.利益分配.7.4.<br/>
+supervisor使用资源的优先级高于director。<br/>
+S2基本管理制度.利益分配.7.6.<br/>
+- deployer、director、supervisor的报酬优先级低于工作支出。<br/>
+- director、supervisor任期内报酬公式不变，如果情况变化可以辞职，再与其他竞聘者一起根据当时情况竞聘。<br/>
+S2基本管理制度.利益分配.8.<br/>
+S2基本管理制度.利益分配.8.2.<br/>
+- member所包括角色范围根据实际情况界定。通常包括admin、worker，有时也包括一些外部人员、机构。<br/>
+- 报酬可能包括不同种类的资源。<br/>
+S2基本管理制度.利益分配.8.3.<br/>
+- admin任期内报酬公式不变，如果情况变化可以辞职，再与其他竞聘者一起根据当时情况竞聘。<br/>
+S2基本管理制度.1406条款.<br/>
+1406准确的定位是director会议的动议套件，可以用作其它模型的附件。 ​​​<br/>
+S2基本管理制度.1406条款.2.<br/>
+在使用IT系统时，可修改为admin向系统提交通用工单，并由系统通知负责执行的成员。<br/>
+S2基本管理制度.1406条款.3.<br/>
+- 如果出现重大失误，director会议可能召开临时会议干预。所以要求及时归档。<br/>
+- 在使用IT系统时，可以由系统实时归档。本条款可以根据情况修订。<br/>
+S2基本管理制度.1406条款.4.<br/>
+- 时间按一月一周期安排，只是范例。可以根据基本管理制度的完善程度自行调节，从一周到一年都可以考虑。<br/>
+- 基本管理制度生效后，所规定的工作事项就不再允许admin直接指挥。相应的具体规章也同时失效。<br/>
+- 基本管理制度的规定，可能与通用工单规定的相同、相似、相反......<br/>
+</p><hr/></body></html>
+```
+
+顺便修订了1609模型 term.f70677ff
+```
+diff --git "a/view/term.f70677ff.md" "b/view/term.f70677ff.md"
+index 167d96b..3fea3eb 100644
+--- "a/view/term.f70677ff.md"
++++ "b/view/term.f70677ff.md"
+@@ -1,16 +1,5 @@
+ 条款 f70677ff 正文:
+-自修订条款1. 本条款按照本条款修订。由deployer书面提交修订以下事项，提交时生效：
+-  - p%
+-  - director席位数
+-  - director会议议事规则
+-  - supervisor席位数
+-  - supervisor会议议事规则
+-  - director和supervisor任期及选举程序
+-  - trustee任期及任免程序
+-  - 第一届director
+-  - 第一届supervisor
+-  - 下一任deployer
+-  - 本条款内容
++自修订条款1. 本条款按照本条款修订。由deployer书面提交即可行使职权。deployer职权包括修订本条款内容。
+ 二级决策条款1. 本条款按照自修订条款1.条款修订。根据director会议议事规则，经三分之二以上director通过可以作出决议。
+ 二级决策条款2. 本条款按照自修订条款1.条款修订。根据director会议议事规则，经二分之一以上director通过可以作出决议：
+   - director工作计划（含预算案）
+@@ -45,6 +34,18 @@
+   - 选举supervisor
+ 三级决策条款4. 本条款按照二级决策条款4.条款修订。本条款按照<term.f70677ff.level1.4>修订。全体RIU持有者选举，以持有的RIU为权重。
+   - 任免trustee。
++职权分配1. 本条款按照二级决策条款4.条款修订。deployer行使以下职权：
++  - 设定p%
++  - 设定director席位数
++  - 制定director会议议事规则
++  - 设定supervisor席位数
++  - 制定supervisor会议议事规则
++  - 确定director和supervisor任期及选举程序
++  - 确定trustee任期及任免程序
++  - 任命第一届director
++  - 任命第一届supervisor
++  - 任命下一任deployer
++  - 修改自修订条款1内容
+ 基本管理制度.保密制度.1. 本条款按照自修订条款1.条款修订。本制度正文公开。
+ 基本管理制度.保密制度.2. 本条款按照自修订条款1.条款修订。不可修订条款、自修订条款、二级决策条款的正文以及执行记录的保密事项由这些条款自己定义，本制度不得规定。
+ 基本管理制度.保密制度.3. 本条款按照二级决策条款1.条款修订。其它规章正文及执行记录默认为公开。
+@@ -86,7 +87,9 @@
+ 
+ ---
+ readme:
+-条款 f70677ff. 二级决策条款2.
++条款 f70677ff. 自修订条款1.
++为了防止deployer被架空，规定其自行定义程序上的细节。
++二级决策条款2.
+ 本条款是指针对未规定的事项，制订基本管理制度的第一版。后续版本按照各条款修订权产生。
+ 基本管理制度.
+ 基本管理制度.利益分配.
+```
+---
+
+[top](#top) | [index](#index)
+<a id="20240512093000"></a>
+##  9:30~10:59
+COM metadata -> COM view
+
+- term.js 增加 makeCOMview() ， node term COM id   : COM metadata → COM markdown + html  
+- 修改了maketermtext() 和一些metadata中的upgradeby字段格式，主要是最后的点 .
+```
+D:\huangyg\git\PSMD\src>node term COM 1609
+enter maketermtext:c13a43a2     upgradeby:自修订条款1.  prefix:自修订条款1.
+enter maketermtext:71da4d25     upgradeby:<COM.1609.loop.1>     prefix:二级决策条款1.
+enter maketermtext:40880d93     upgradeby:<COM.1609.loop.1>     prefix:二级决策条款2.
+enter maketermtext:54b6949d     upgradeby:<COM.1609.loop.1>     prefix:二级决策条款3.
+enter maketermtext:95eab800     upgradeby:<COM.1609.loop.1>     prefix:二级决策条款4.
+enter maketermtext:0edca872     upgradeby:<COM.1609.loop.1>     prefix:二级决策条款5.
+enter maketermtext:32e45dee     upgradeby:<COM.1609.loop.1>     prefix:二级决策条款6.
+enter maketermtext:88e5c5f4     upgradeby:<COM.1609.level1.1>   prefix:三级决策条款1.
+enter maketermtext:4e9e9c33     upgradeby:<COM.1609.level1.3>   prefix:三级决策条款2.
+enter maketermtext:666776c3     upgradeby:<COM.1609.level1.3>   prefix:三级决策条款3.
+enter maketermtext:efaeac70     upgradeby:<COM.1609.level1.4>   prefix:三级决策条款4.
+enter maketermtext:77666f44     upgradeby:undefined     prefix:基本管理制度.
+enter maketermtext:ac890987     upgradeby:undefined     prefix:基本管理制度.保密制度.
+enter maketermtext:72af7dea     upgradeby:<term.ac890987.term.1>        prefix:基本管理制度.保密制度.1.
+enter maketermtext:02c7d037     upgradeby:<term.ac890987.term.1>        prefix:基本管理制度.保密制度.2.
+enter maketermtext:ef4cdffe     upgradeby:<term.ac890987.term.2>        prefix:基本管理制度.保密制度.3.
+enter maketermtext:de47ace4     upgradeby:undefined     prefix:基本管理制度.利益分配.
+enter maketermtext:c046b09d     upgradeby:undefined     prefix:基本管理制度.利益分配.1.
+enter maketermtext:3638eac6     upgradeby:undefined     prefix:基本管理制度.利益分配.2.
+enter maketermtext:1558e5e1     upgradeby:undefined     prefix:基本管理制度.利益分配.3.
+enter maketermtext:814f76cb     upgradeby:undefined     prefix:基本管理制度.利益分配.4.
+enter maketermtext:58d4c137     upgradeby:undefined     prefix:基本管理制度.利益分配.5.
+enter maketermtext:c1f65b6d     upgradeby:undefined     prefix:基本管理制度.利益分配.5.1.
+enter maketermtext:6568c500     upgradeby:undefined     prefix:基本管理制度.利益分配.5.2.
+enter maketermtext:d8bd8aa6     upgradeby:undefined     prefix:基本管理制度.利益分配.6.
+enter maketermtext:8a5d94dc     upgradeby:<term.d8bd8aa6.term.1>        prefix:基本管理制度.利益分配.6.1.
+enter maketermtext:34be50e1     upgradeby:<term.d8bd8aa6.term.1>        prefix:基本管理制度.利益分配.6.2.
+enter maketermtext:3176f00c     upgradeby:<term.d8bd8aa6.term.1>        prefix:基本管理制度.利益分配.6.3.
+enter maketermtext:a8ca0160     upgradeby:<term.d8bd8aa6.term.1>        prefix:基本管理制度.利益分配.6.4.
+enter maketermtext:2a78271e     upgradeby:<term.d8bd8aa6.term.1>        prefix:基本管理制度.利益分配.6.5.
+enter maketermtext:96b99526     upgradeby:undefined     prefix:基本管理制度.利益分配.7.
+enter maketermtext:6d2ca266     upgradeby:<term.96b99526.term.1>        prefix:基本管理制度.利益分配.7.1.
+enter maketermtext:fb21bdf9     upgradeby:<term.96b99526.term.1>        prefix:基本管理制度.利益分配.7.2.
+enter maketermtext:7f7a536f     upgradeby:<term.96b99526.term.1>        prefix:基本管理制度.利益分配.7.3.
+enter maketermtext:a8d575a7     upgradeby:<term.96b99526.term.1>        prefix:基本管理制度.利益分配.7.4.
+enter maketermtext:70cdd24d     upgradeby:<term.96b99526.term.1>        prefix:基本管理制度.利益分配.7.5.
+enter maketermtext:41312cc4     upgradeby:<term.96b99526.term.1>        prefix:基本管理制度.利益分配.7.6.
+enter maketermtext:12d14064     upgradeby:undefined     prefix:基本管理制度.利益分配.8.
+enter maketermtext:af62f03b     upgradeby:<term.12d14064.term.1>        prefix:基本管理制度.利益分配.8.1.
+enter maketermtext:55cc8467     upgradeby:<term.12d14064.term.1>        prefix:基本管理制度.利益分配.8.2.
+enter maketermtext:e4495f38     upgradeby:<term.12d14064.term.1>        prefix:基本管理制度.利益分配.8.3.
+enter maketermtext:056e71fb     upgradeby:<term.77666f44.term.2>        prefix:基本管理制度.1406条款.
+enter maketermtext:48577ce8     upgradeby:<term.77666f44.term.2>        prefix:基本管理制度.1406条款.1.
+enter maketermtext:7506353d     upgradeby:<term.77666f44.term.2>        prefix:基本管理制度.1406条款.2.
+enter maketermtext:260ca049     upgradeby:<term.77666f44.term.2>        prefix:基本管理制度.1406条款.3.
+enter maketermtext:c87ec159     upgradeby:<term.77666f44.term.2>        prefix:基本管理制度.1406条款.4.
+Warning: missing space before text for line 6 of jade file "undefined"
+Warning: missing space before text for line 8 of jade file "undefined"
+Warning: missing space before text for line 10 of jade file "undefined"
+makeCOMview() > ../view/COM.1609.md文件更新，内容如下:
+# 共同体模型1609 正文
+## 决策条款
+### 自修订条款
+自修订条款1. 本条款按照本条款修订。由deployer书面提交即可行使职权。deployer职权包括修订本条款内容。
+### 二级决策条款
+二级决策条款1. 本条款按照自修订条款1.条款修订。根据director会议议事规则，经三分之二以上director通过可以作出决议。
+二级决策条款2. 本条款按照自修订条款1.条款修订。根据director会议议事规则，经二分之一以上director通过可以作出决议：
+  - director工作计划（含预算案）
+  - director工作报告
+  - 审议报告
+  - 任免admin
+  - admin工作计划（含预算案）
+  - 设立、撤销部门
+  - worker劳动合同
+  - 制订基本管理制度
+  - 制订保密文件的脱敏版本
+二级决策条款3. 本条款按照自修订条款1.条款修订。由deployer提出。根据director会议议事规则，经全体director通过可以作出决议。
+二级决策条款4. 本条款按照自修订条款1.条款修订。由deployer提出。根据director会议议事规则，经全体director和trustee通过可以作出决议。
+二级决策条款5. 本条款按照自修订条款1.条款修订。根据supervisor会议议事规则，经三分之二supervisor通过可以作出决议：
+  - supervisor工作计划
+  - supervisor工作报告
+  - 审议报告
+  - director任期提前结束，重新进行选举。
+二级决策条款6. 本条款按照自修订条款1.条款修订。由trustee书面提交修订以下事项，提交时生效：
+- 预算透支限额
+- director任期提前结束，重新进行选举。
+- supervisor任期提前结束，重新进行选举。
+二级决策条款7. 本条款按照自修订条款1.条款修订。 [本条款内容待定] director会议议事规则，可以根据该届director的工作习惯，选择主流议事规则之一。
+二级决策条款8. 本条款按照自修订条款1.条款修订。 [本条款内容待定] supervisor会议议事规则，可以根据该届supervisor的工作习惯，选择主流议事规则之一。
+### 三级决策条款
+三级决策条款1. 本条款按照二级决策条款1.条款修订。由admin书面提交修订以下事项，提交时生效：
+  - admin工作计划草案
+  - admin工作报告
+  - 具体规章
+  - worker名册（及合同）
+三级决策条款2. 本条款按照二级决策条款3.条款修订。全体worker、RIU持有者选举。假设worker合同的报酬RIU总额为w，RIU总额为r，worker手中合同的每个RIU报酬 权重为r*(100-p)，RIU持有者持有的每个RIU权重为w*p。
+  - 如果deployer没有指定继任者又不能工作，选举新任deployer。
+三级决策条款3. 本条款按照二级决策条款3.条款修订。全体worker、RIU持有者选举。假设worker合同的报酬RIU总额为w，RIU总额为r，席位为x，worker手中合同的每 个RIU报酬权重为r*x*p，RIU持有者持有的每个RIU权重为w*x*(100-p)。选举采用累积投票制，不对单独席位进行罢免投票，每次都全部重选。
+  - 选举director
+  - 选举supervisor
+三级决策条款4. 本条款按照二级决策条款4.条款修订。本条款按照二级决策条款4修订。全体RIU持有者选举，以持有的RIU为权重。
+  - 任免trustee。
+### 基本管理制度
+基本管理制度.保密制度.1. 本条款按照自修订条款1.条款修订。本制度正文公开。
+基本管理制度.保密制度.2. 本条款按照自修订条款1.条款修订。不可修订条款、自修订条款、二级决策条款的正文以及执行记录的保密事项由这些条款自己定义，本制 度不得规定。
+基本管理制度.保密制度.3. 本条款按照二级决策条款1.条款修订。其它规章正文及执行记录默认为公开。
+基本管理制度.利益分配.1. 利益分配原则：优先劣后次序与决策层级相反。
+基本管理制度.利益分配.2. 每个成员设一个专户，每个专户可以容纳所有种类的资产。
+基本管理制度.利益分配.3. 本条款按照自修订条款1.条款修订。设四个共同体专户，每个专户可以容纳所有种类的资产。分别由：deployer、trustee、director和supervisor、admin管理。
+基本管理制度.利益分配.4. 本条款按照自修订条款1.条款修订。按照二级决策条款2.设立部门时，开设部门专户，并明确与其它专户的资源交换规则。
+基本管理制度.利益分配.5. deployer专户：
+基本管理制度.利益分配.5.1. 本条款按照自修订条款1.条款修订。deployer专户用于deployer工作经费，以及重构期间发生的短期支出。
+基本管理制度.利益分配.5.2. 本条款按照二级决策条款3.条款修订。每月末将director专户余额的0.5%转入deployer专户。
+基本管理制度.利益分配.6. 本条款按照二级决策条款4.条款修订。trustee专户：
+基本管理制度.利益分配.6.1. 本条款按照二级决策条款4.条款修订。RIU持有者可以将RIU转入trustee专户，委托trustee卖出。
+基本管理制度.利益分配.6.2. 本条款按照二级决策条款4.条款修订。投资者可以将其它资源转入trustee专户，委托trustee买入RIU。
+基本管理制度.利益分配.6.3. 本条款按照二级决策条款4.条款修订。收入的p%用于购买trustee专户中的RIU，低价优先。交易获得的RIU支付trustee报酬后，余额转入director专户。
+基本管理制度.利益分配.6.4. 本条款按照二级决策条款4.条款修订。RIU交易由trustee按价格优先、时间优先原则撮合。
+基本管理制度.利益分配.6.5. 本条款按照二级决策条款4.条款修订。trustee从收入的p%购买的RIU中领取报酬，竞聘者须明确报酬的计算公式。
+基本管理制度.利益分配.7. 本条款按照二级决策条款3.条款修订。director专户由director与supervisor共同使用：
+基本管理制度.利益分配.7.1. 本条款按照二级决策条款3.条款修订。director专户中的RIU可以是负数，最小值由预算透支限额确定。
+基本管理制度.利益分配.7.2. 本条款按照二级决策条款3.条款修订。收入的(100-p)%转入director专户。
+基本管理制度.利益分配.7.3. 本条款按照二级决策条款3.条款修订。按生效的admin工作计划（含预算案）从director专户转入admin专户，余额不足时后续条款的支出 暂缓。
+基本管理制度.利益分配.7.4. 本条款按照二级决策条款3.条款修订。supervisor按supervisor工作计划（含预算案）使用director专户余额，余额不足时后续条款的支 出暂缓。
+基本管理制度.利益分配.7.5. 本条款按照二级决策条款3.条款修订。director按director工作计划（含预算案）使用director专户余额，余额不足时后续条款的支出暂 缓。
+基本管理制度.利益分配.7.6. 本条款按照二级决策条款3.条款修订。deployer、director、supervisor从director专户领取报酬，director、supervisor竞聘者须明确 报酬的计算公式，deployer报酬数额为director、supervisor报酬的中位数。director专户数额不足时以应发数额为权重按比例分配，等候期间不计利息。
+基本管理制度.利益分配.8. 本条款按照二级决策条款1.条款修订。admin专户：
+基本管理制度.利益分配.8.1. 本条款按照二级决策条款1.条款修订。admin按admin工作计划（含预算案）调用admin专户中的资源。
+基本管理制度.利益分配.8.2. 本条款按照二级决策条款1.条款修订。member的工作成果提交到admin专户，从admin专户领取报酬，报酬金额在合同中规定。
+基本管理制度.利益分配.8.3. 本条款按照二级决策条款1.条款修订。admin从admin专户领取报酬（优先级在worker之后），竞聘者须明确报酬的计算公式。本专户数额 不足而等候期间不计利息。
+基本管理制度.1406条款.1. 本条款按照二级决策条款2.条款修订。在执行部门内，基本管理制度和劳动合同未定义的事项由admin直接指挥。
+基本管理制度.1406条款.2. 本条款按照二级决策条款2.条款修订。直接指挥的方式：
+  - admin填写通用工单明确事项的处理要求，并交给负责执行的成员；
+  - admin制订具体规章明确事项的处理要求，并提交给director会议备案，director会议签收后具体规章即生效。执行部门成员根据生效的具体规章自行填写通用工单 并执行。
+基本管理制度.1406条款.3. 本条款按照二级决策条款2.条款修订。admin和执行人员都要向director会议归档通用工单。执行人员应在收到或自行填写通用工单24小时内归档。admin填写的通用工单归档要求是：
+  - 在director会议的一个审议周期内，每一事项的前3份通用工单，应在出具24小时内向director会议归档；
+  - 在director会议的一个审议周期内，同一事项的第4份通用工单起，可以汇总后在审议周期结束前一并归档。
+基本管理制度.1406条款.4. 本条款按照二级决策条款2.条款修订。director会议成员应：
+  - 在审议周期的第10天结束前阅读完上一个审议周期结束前归档的通用工单，提交审议报告以及基本管理制度的修订动议。
+  - 在审议周期的第20天结束前阅读完其他成员提交的审议报告和基本管理制度的修订动议，提交审议报告。
+  - 在审议周期结束前对基本管理制度修订动议进行表决。
+
+---
+# 共同体模型1609 readme
+自修订条款1. 为了防止deployer被架空，规定其自行定义程序上的细节。部署后根据实体地址和位置、接收人员的职务名称、服务器域名和IP地址等信息，可以修改提 交方式。
+二级决策条款2. 本条款是指针对未规定的事项，制订基本管理制度的第一版。后续版本按照各条款修订权产生。
+三级决策条款4. 基本管理制度.利益分配.
+基本管理制度.利益分配.2.
+- 所有工作成果都属于资产。
+基本管理制度.利益分配.5.
+基本管理制度.利益分配.5.1.
+- deployer无须制订工作计划和预算案。
+- 部署时根据实际情况确定本条的记账方式。
+基本管理制度.利益分配.5.2.
+deployer使用资源的优先级高于director。
+基本管理制度.利益分配.6.
+基本管理制度.利益分配.6.3.
+大部分收入还是由director使用，其中p%体现为RIU（扣除trustee报酬），其余体现为对外交易约定的资源。
+基本管理制度.利益分配.6.5.
+trustee任期内报酬公式不变，如果情况变化可以辞职，再与其他竞聘者一起根据当时情况竞聘。
+基本管理制度.利益分配.7.
+基本管理制度.利益分配.7.3.
+- 工作计划和预算案可以根据工作需要规定资源转入时间，滚动利用预算周期内的交易收入。
+- admin使用资源的优先级高于director和supervisor。
+基本管理制度.利益分配.7.4.
+supervisor使用资源的优先级高于director。
+基本管理制度.利益分配.7.6.
+- deployer、director、supervisor的报酬优先级低于工作支出。
+- director、supervisor任期内报酬公式不变，如果情况变化可以辞职，再与其他竞聘者一起根据当时情况竞聘。
+基本管理制度.利益分配.8.
+基本管理制度.利益分配.8.2.
+- member所包括角色范围根据实际情况界定。通常包括admin、worker，有时也包括一些外部人员、机构。
+- 报酬可能包括不同种类的资源。
+基本管理制度.利益分配.8.3.
+- admin任期内报酬公式不变，如果情况变化可以辞职，再与其他竞聘者一起根据当时情况竞聘。
+基本管理制度.1406条款.
+1406准确的定位是director会议的动议套件，可以用作其它模型的附件。 ​​​
+基本管理制度.1406条款.2.
+在使用IT系统时，可修改为admin向系统提交通用工单，并由系统通知负责执行的成员。
+基本管理制度.1406条款.3.
+- 如果出现重大失误，director会议可能召开临时会议干预。所以要求及时归档。
+- 在使用IT系统时，可以由系统实时归档。本条款可以根据情况修订。
+基本管理制度.1406条款.4.
+- 时间按一月一周期安排，只是范例。可以根据基本管理制度的完善程度自行调节，从一周到一年都可以考虑。
+- 基本管理制度生效后，所规定的工作事项就不再允许admin直接指挥。相应的具体规章也同时失效。
+- 基本管理制度的规定，可能与通用工单规定的相同、相似、相反......
+
+makeCOMview() > ../view/COM.1609.html文件更新，内容如下:
+<html lang="zh-cn"><head><title>term html sample</title><script></script></head><body><h3>条款 </h3><hr/><p>正文:</p><p># 共同体模型1609 正文 <br/>
+## 决策条款  <br/>
+### 自修订条款  <br/>
+自修订条款1. 本条款按照本条款修订。由deployer书面提交即可行使职权。deployer职权包括修订本条款内容。<br/>
+### 二级决策条款  <br/>
+二级决策条款1. 本条款按照自修订条款1.条款修订。根据director会议议事规则，经三分之二以上director通过可以作出决议。<br/>
+二级决策条款2. 本条款按照自修订条款1.条款修订。根据director会议议事规则，经二分之一以上director通过可以作出决议：<br/>
+  - director工作计划（含预算案）<br/>
+  - director工作报告<br/>
+  - 审议报告<br/>
+  - 任免admin<br/>
+  - admin工作计划（含预算案）<br/>
+  - 设立、撤销部门<br/>
+  - worker劳动合同<br/>
+  - 制订基本管理制度<br/>
+  - 制订保密文件的脱敏版本<br/>
+二级决策条款3. 本条款按照自修订条款1.条款修订。由deployer提出。根据director会议议事规则，经全体director通过可以作出决议。<br/>
+二级决策条款4. 本条款按照自修订条款1.条款修订。由deployer提出。根据director会议议事规则，经全体director和trustee通过可以作出决议。<br/>
+二级决策条款5. 本条款按照自修订条款1.条款修订。根据supervisor会议议事规则，经三分之二supervisor通过可以作出决议：<br/>
+  - supervisor工作计划<br/>
+  - supervisor工作报告<br/>
+  - 审议报告<br/>
+  - director任期提前结束，重新进行选举。<br/>
+二级决策条款6. 本条款按照自修订条款1.条款修订。由trustee书面提交修订以下事项，提交时生效：<br/>
+- 预算透支限额<br/>
+- director任期提前结束，重新进行选举。<br/>
+- supervisor任期提前结束，重新进行选举。<br/>
+二级决策条款7. 本条款按照自修订条款1.条款修订。 [本条款内容待定] director会议议事规则，可以根据该届director的工作习惯，选择主流议事规则之一。<br/>
+二级决策条款8. 本条款按照自修订条款1.条款修订。 [本条款内容待定] supervisor会议议事规则，可以根据该届supervisor的工作习惯，选择主流议事规则之一。<br/>
+### 三级决策条款  <br/>
+三级决策条款1. 本条款按照二级决策条款1.条款修订。由admin书面提交修订以下事项，提交时生效：<br/>
+  - admin工作计划草案<br/>
+  - admin工作报告<br/>
+  - 具体规章<br/>
+  - worker名册（及合同）<br/>
+三级决策条款2. 本条款按照二级决策条款3.条款修订。全体worker、RIU持有者选举。假设worker合同的报酬RIU总额为w，RIU总额为r，worker手中合同的每个RIU报酬 权重为r*(100-p)，RIU持有者持有的每个RIU权重为w*p。 <br/>
+  - 如果deployer没有指定继任者又不能工作，选举新任deployer。<br/>
+三级决策条款3. 本条款按照二级决策条款3.条款修订。全体worker、RIU持有者选举。假设worker合同的报酬RIU总额为w，RIU总额为r，席位为x，worker手中合同的每 个RIU报酬权重为r*x*p，RIU持有者持有的每个RIU权重为w*x*(100-p)。选举采用累积投票制，不对单独席位进行罢免投票，每次都全部重选。<br/>
+  - 选举director<br/>
+  - 选举supervisor<br/>
+三级决策条款4. 本条款按照二级决策条款4.条款修订。本条款按照二级决策条款4修订。全体RIU持有者选举，以持有的RIU为权重。<br/>
+  - 任免trustee。<br/>
+### 基本管理制度  <br/>
+基本管理制度.保密制度.1. 本条款按照自修订条款1.条款修订。本制度正文公开。<br/>
+基本管理制度.保密制度.2. 本条款按照自修订条款1.条款修订。不可修订条款、自修订条款、二级决策条款的正文以及执行记录的保密事项由这些条款自己定义，本制 度不得规定。<br/>
+基本管理制度.保密制度.3. 本条款按照二级决策条款1.条款修订。其它规章正文及执行记录默认为公开。<br/>
+基本管理制度.利益分配.1. 利益分配原则：优先劣后次序与决策层级相反。<br/>
+基本管理制度.利益分配.2. 每个成员设一个专户，每个专户可以容纳所有种类的资产。<br/>
+基本管理制度.利益分配.3. 本条款按照自修订条款1.条款修订。设四个共同体专户，每个专户可以容纳所有种类的资产。分别由：deployer、trustee、director和supervisor、admin管理。<br/>
+基本管理制度.利益分配.4. 本条款按照自修订条款1.条款修订。按照二级决策条款2.设立部门时，开设部门专户，并明确与其它专户的资源交换规则。<br/>
+基本管理制度.利益分配.5. deployer专户：<br/>
+基本管理制度.利益分配.5.1. 本条款按照自修订条款1.条款修订。deployer专户用于deployer工作经费，以及重构期间发生的短期支出。<br/>
+基本管理制度.利益分配.5.2. 本条款按照二级决策条款3.条款修订。每月末将director专户余额的0.5%转入deployer专户。<br/>
+基本管理制度.利益分配.6. 本条款按照二级决策条款4.条款修订。trustee专户：<br/>
+基本管理制度.利益分配.6.1. 本条款按照二级决策条款4.条款修订。RIU持有者可以将RIU转入trustee专户，委托trustee卖出。<br/>
+基本管理制度.利益分配.6.2. 本条款按照二级决策条款4.条款修订。投资者可以将其它资源转入trustee专户，委托trustee买入RIU。<br/>
+基本管理制度.利益分配.6.3. 本条款按照二级决策条款4.条款修订。收入的p%用于购买trustee专户中的RIU，低价优先。交易获得的RIU支付trustee报酬后，余额转入director专户。<br/>
+基本管理制度.利益分配.6.4. 本条款按照二级决策条款4.条款修订。RIU交易由trustee按价格优先、时间优先原则撮合。<br/>
+基本管理制度.利益分配.6.5. 本条款按照二级决策条款4.条款修订。trustee从收入的p%购买的RIU中领取报酬，竞聘者须明确报酬的计算公式。<br/>
+基本管理制度.利益分配.7. 本条款按照二级决策条款3.条款修订。director专户由director与supervisor共同使用：<br/>
+基本管理制度.利益分配.7.1. 本条款按照二级决策条款3.条款修订。director专户中的RIU可以是负数，最小值由预算透支限额确定。<br/>
+基本管理制度.利益分配.7.2. 本条款按照二级决策条款3.条款修订。收入的(100-p)%转入director专户。<br/>
+基本管理制度.利益分配.7.3. 本条款按照二级决策条款3.条款修订。按生效的admin工作计划（含预算案）从director专户转入admin专户，余额不足时后续条款的支出 暂缓。<br/>
+基本管理制度.利益分配.7.4. 本条款按照二级决策条款3.条款修订。supervisor按supervisor工作计划（含预算案）使用director专户余额，余额不足时后续条款的支 出暂缓。<br/>
+基本管理制度.利益分配.7.5. 本条款按照二级决策条款3.条款修订。director按director工作计划（含预算案）使用director专户余额，余额不足时后续条款的支出暂 缓。<br/>
+基本管理制度.利益分配.7.6. 本条款按照二级决策条款3.条款修订。deployer、director、supervisor从director专户领取报酬，director、supervisor竞聘者须明确 报酬的计算公式，deployer报酬数额为director、supervisor报酬的中位数。director专户数额不足时以应发数额为权重按比例分配，等候期间不计利息。<br/>
+基本管理制度.利益分配.8. 本条款按照二级决策条款1.条款修订。admin专户：<br/>
+基本管理制度.利益分配.8.1. 本条款按照二级决策条款1.条款修订。admin按admin工作计划（含预算案）调用admin专户中的资源。<br/>
+基本管理制度.利益分配.8.2. 本条款按照二级决策条款1.条款修订。member的工作成果提交到admin专户，从admin专户领取报酬，报酬金额在合同中规定。<br/>
+基本管理制度.利益分配.8.3. 本条款按照二级决策条款1.条款修订。admin从admin专户领取报酬（优先级在worker之后），竞聘者须明确报酬的计算公式。本专户数额 不足而等候期间不计利息。<br/>
+基本管理制度.1406条款.1. 本条款按照二级决策条款2.条款修订。在执行部门内，基本管理制度和劳动合同未定义的事项由admin直接指挥。<br/>
+基本管理制度.1406条款.2. 本条款按照二级决策条款2.条款修订。直接指挥的方式：<br/>
+  - admin填写通用工单明确事项的处理要求，并交给负责执行的成员；<br/>
+  - admin制订具体规章明确事项的处理要求，并提交给director会议备案，director会议签收后具体规章即生效。执行部门成员根据生效的具体规章自行填写通用工单 并执行。<br/>
+基本管理制度.1406条款.3. 本条款按照二级决策条款2.条款修订。admin和执行人员都要向director会议归档通用工单。执行人员应在收到或自行填写通用工单24小时内归档。admin填写的通用工单归档要求是：<br/>
+  - 在director会议的一个审议周期内，每一事项的前3份通用工单，应在出具24小时内向director会议归档；<br/>
+  - 在director会议的一个审议周期内，同一事项的第4份通用工单起，可以汇总后在审议周期结束前一并归档。<br/>
+基本管理制度.1406条款.4. 本条款按照二级决策条款2.条款修订。director会议成员应：<br/>
+  - 在审议周期的第10天结束前阅读完上一个审议周期结束前归档的通用工单，提交审议报告以及基本管理制度的修订动议。<br/>
+  - 在审议周期的第20天结束前阅读完其他成员提交的审议报告和基本管理制度的修订动议，提交审议报告。<br/>
+  - 在审议周期结束前对基本管理制度修订动议进行表决。<br/>
+</p><hr/><p>注释:</p><p>自修订条款1. 为了防止deployer被架空，规定其自行定义程序上的细节。部署后根据实体地址和位置、接收人员的职务名称、服务器域名和IP地址等信息，可以修改提交方式。<br/>
+二级决策条款2. 本条款是指针对未规定的事项，制订基本管理制度的第一版。后续版本按照各条款修订权产生。<br/>
+三级决策条款4. 基本管理制度.利益分配.<br/>
+基本管理制度.利益分配.2.<br/>
+- 所有工作成果都属于资产。<br/>
+基本管理制度.利益分配.5.<br/>
+基本管理制度.利益分配.5.1.<br/>
+- deployer无须制订工作计划和预算案。<br/>
+- 部署时根据实际情况确定本条的记账方式。<br/>
+基本管理制度.利益分配.5.2.<br/>
+deployer使用资源的优先级高于director。<br/>
+基本管理制度.利益分配.6.<br/>
+基本管理制度.利益分配.6.3.<br/>
+大部分收入还是由director使用，其中p%体现为RIU（扣除trustee报酬），其余体现为对外交易约定的资源。<br/>
+基本管理制度.利益分配.6.5.<br/>
+trustee任期内报酬公式不变，如果情况变化可以辞职，再与其他竞聘者一起根据当时情况竞聘。<br/>
+基本管理制度.利益分配.7.<br/>
+基本管理制度.利益分配.7.3.<br/>
+- 工作计划和预算案可以根据工作需要规定资源转入时间，滚动利用预算周期内的交易收入。<br/>
+- admin使用资源的优先级高于director和supervisor。<br/>
+基本管理制度.利益分配.7.4.<br/>
+supervisor使用资源的优先级高于director。<br/>
+基本管理制度.利益分配.7.6.<br/>
+- deployer、director、supervisor的报酬优先级低于工作支出。<br/>
+- director、supervisor任期内报酬公式不变，如果情况变化可以辞职，再与其他竞聘者一起根据当时情况竞聘。<br/>
+基本管理制度.利益分配.8.<br/>
+基本管理制度.利益分配.8.2.<br/>
+- member所包括角色范围根据实际情况界定。通常包括admin、worker，有时也包括一些外部人员、机构。<br/>
+- 报酬可能包括不同种类的资源。<br/>
+基本管理制度.利益分配.8.3.<br/>
+- admin任期内报酬公式不变，如果情况变化可以辞职，再与其他竞聘者一起根据当时情况竞聘。<br/>
+基本管理制度.1406条款.<br/>
+1406准确的定位是director会议的动议套件，可以用作其它模型的附件。 ​​​<br/>
+基本管理制度.1406条款.2.<br/>
+在使用IT系统时，可修改为admin向系统提交通用工单，并由系统通知负责执行的成员。<br/>
+基本管理制度.1406条款.3.<br/>
+- 如果出现重大失误，director会议可能召开临时会议干预。所以要求及时归档。<br/>
+- 在使用IT系统时，可以由系统实时归档。本条款可以根据情况修订。<br/>
+基本管理制度.1406条款.4.<br/>
+- 时间按一月一周期安排，只是范例。可以根据基本管理制度的完善程度自行调节，从一周到一年都可以考虑。<br/>
+- 基本管理制度生效后，所规定的工作事项就不再允许admin直接指挥。相应的具体规章也同时失效。<br/>
+- 基本管理制度的规定，可能与通用工单规定的相同、相似、相反......<br/>
+</p><hr/></body></html>
+```
+
+- 目前upgradeby字段会覆盖所有子条款的upgradeby字段。如果只覆盖个别条款怎么实现。比如基本管理制度77666f44中只覆盖1406（056e71fb）的upgradeby。
+    - 不同自条款覆盖不同的，怎么实现，可以在map去替换吗？
+- 花的时间比较多，登记200分钟。下午两个30分钟时间片回到todo项。
+
+---
+
+[top](#top) | [index](#index)
+<a id="20240512140000"></a>
+## 14:00~14:29
+实现todo项的多层结构
+
+先取消，时间用来完成上午追加时间的任务。
+---
+
+[top](#top) | [index](#index)
+<a id="20240512143000"></a>
+## 14:30~14:59
+学习AMD规范，如果适用就开发范例
+
+先取消，时间用来完成上午追加时间的任务。
+---
+
+[top](#top) | [index](#index)
+<a id="20240512160000"></a>
+## 16:00~16:59
+学习promise对象和async/await
+
+- 还是这个教程好 https://zh.javascript.info/async
+- 休整时间继续，睡觉前根据余下内容追加todo项。
+    - '30': 继续学习promise api
+      readme: |
+        - https://zh.javascript.info/promise-api

release/time/d.20240513.md

@@ -0,0 +1,236 @@
+# 2024.05.13.
+日小结  
+
+<a id="top"></a>
+根据[ego模型时间接口](https://gitee.com/hyg/blog/blob/master/timeflow.md)，今天绑定模版1。
+
+<a id="index"></a>
+- 07:45	[freenet的contract](#20240513074500)  
+- 09:30	[整理S2状态下基本管理制度的metedata](#20240513093000)  
+- 14:00	[修订入门目录term.9d12877c，准备实际使用。](#20240513140000)  
+- 14:30	[实现todo项的多层结构](#20240513143000)  
+- 16:00	[五月报税](#20240513160000)  
+
+---
+season stat:
+
+| task | alloc | sold | hold | todo |
+| --- | --- | --- | --- | --- |
+| total | 13275 | 9710 | 3565 | 2580 |
+| PSMD | 7000 | 4916 | 2084 | 585 |
+| learn | 1000 | 472 | 528 | 750 |
+| ego | 3000 | 2184 | 816 | 615 |
+| js | 1375 | 705 | 670 | 300 |
+| xuemen | 600 | 1046 | -446 | 210 |
+| raw | 300 | 357 | -57 | 120 |
+| infra | 0 | 30 | -30 | 0 |
+
+---
+
+waiting list:
+
+
+- 30分钟时间片：
+  - ego的第1号事项：在draft+season+task metadata基础上设计有互动的总结功能
+  - raw的第1号事项：debug-diff mode较大天数返回空数据，创建三个R文件。
+  - js的第2号事项：自动收发email。
+  - learn的第2号事项：YARRRML
+
+- 60分钟时间片：
+  - PSMD的第1号事项：按照可交互deploy的模式整理入门目录term.9d12877c措辞
+  - js的第1号事项：可交互的静态网页
+  - learn的第1号事项：github的actions,workflow,job脚本语法
+  - xuemen的第1号事项：整理kernel、ISU、JPU之间的关系，厘清概念。
+
+- 90分钟时间片：
+  - PSMD的第6号事项：整理近期手稿。
+  - learn的第6号事项：把PSMD的data、src部分升级到rdf，如果升级成功则作为范例。
+
+- 195分钟时间片：
+  - PSMD的第2号事项：term + COM matedata -> deploy metadata -> deploy view
+  - learn的第7号事项：rust入门
+
+---
+
+[top](#top) | [index](#index)
+<a id="20240513074500"></a>
+## 7:45~8:44
+freenet的contract
+
+- https://docs.freenet.org/contract-interface.html#contract-interface
+    - state、delta、param三个概念可以借鉴。
+    - state、delta可以先验证，再真的改变state
+    - State Summary概念：state -> State Summary -> delta -> update current state
+    - https://github.com/freenet/freenet-core/issues/167  一份合同把另一份合同的state作为自己验证delta的影响因素之一。
+- https://docs.freenet.org/components/contracts.html
+    - Freenet is essentially a global decentralized key-value store where keys are WebAssembly code called Contracts. Contracts are stored in the network, along with their data or "state". The contract controls what state is permitted and how it can be modified, and also how to efficiently synchronize state between peers.
+    - 合同是key，state是value。
+
+- 从概念设定上看，很适合PSMD和infra。
+- 实际使用中需要长时间运行才能连接上其它节点，对成员的体验不是很好。
+- 可以作为备用方案，一旦平时用的中心化方式失灵就自动启用，保持业务低速持续。
+
+追加todo项：
+    - '195': rust入门
+      bind: 
+        - '195': 开发reenet Contracts sample
+          readme: |
+            - https://docs.freenet.org/components/contracts.html
+            - https://docs.freenet.org/introduction.html
+
+---
+
+[top](#top) | [index](#index)
+<a id="20240513093000"></a>
+##  9:30~10:59
+整理S2状态下基本管理制度的metedata
+
+- 整理相关term
+    - name: 学门科技 id: e6f0caec
+        - name: 章程部分条款 id: 2e4f11cb 只留这条就行，现在的十五、十八、二十条都可以删去。
+    - name: 章程部分条款S1 id: 6147e7dd
+        - 其中第十四条的termid指向 name: 1609-利益分配-4 id: 814f76cb ，应该是commit的时候被污染了。
+        - 补回name: 设置董事 id: ecde06c5 替换6147e7dd的第十四条
+    -  清理了部分章节名称最后的点 "."
+- 清理后基于 e6f0caec 添加后续内容。
+- xuemen git库内容和1609的差别：
+    - ISU独立使用IST，有独立的压力传递机制，有利于保持节俭。
+        - 但只限于后勤和政府接口。
+    - 临时模型 对应 规章制度，只有60天有效期。董事需要在次月提交审议报告，而不是只备案。
+    - kernel的职能定义太简略
+        - 对产品、外部环境和成员个人模型（缺陷）的分析，以及输出成果的定义不明确。当时对这些对象的理解还不够深刻，现在可以加深。
+
+- 中间有其它事务插入，没有完成工作。追加todo项：
+    - '60': 整理kernel、ISU、JPU之间的关系，厘清概念。
+      readme: |
+        - 对产品、外部环境和成员个人模型（缺陷）的分析，以及输出成果的定义不明确。当时对这些对象的理解还不够深刻，现在可以加深。
+        - 抓住1609模型的异同，吸纳1609的决策架构，保留xuemen模型(尤其是2-2.核心模型)相对激进的部分。
+    - '90': 重新设计S2状态下的学门基本管理制度
+      readme: |
+        - 基于term.e6f0caec整理
+    - '60': term.e6f0caec -> xuemen COD metadata-S2状态下的部门模型
+
+---
+
+[top](#top) | [index](#index)
+<a id="20240513140000"></a>
+## 14:00~14:29
+修订入门目录term.9d12877c，准备实际使用。
+
+### 需求
+
+- 引用一段自述，先按照附件21核实，然后在按照附件20的方式补充信息。形式上应该能显示引用的自述，并且追加一段注释，衔接对方自述和附件21措辞。
+- 在附件20的界面，应该再次引用对方的自述，以及对方放弃按附件21核实的选择，并给出后退出口。
+    - 只有对方放弃核实自述的情况下，请对方针对附件30~34的条件补充材料，措辞上明确符合、不符合的条件。
+- 在针对附件30~34的界面上，说明这些条件对解决方案有影响。并且给出不同意见的出口：我认为这个条件对问题没有影响，怎么把这个不同意见从个人转成多人共识。
+- 在附件30~34的补充信息基础上做出判断后，基本可以做出判断：
+    - 21-no：
+        - 20-yes：
+            - 30-no：default
+            - 30-yes，31~34-no：default+1406
+            - 30~34-yes：
+                - 42-yes：
+                    - 43-yes：1609
+                    - 43-no：1609
+                - 42-no：
+                    - 43-yes：default+1406
+                    - 43-no：default
+        - 20-no：default
+    - 21-yes：与20-yes分支相同。
+- 附件43没有使用上。
+
+### 数据结构和代码
+
+- 问题和自述，设计一个单独的metadata，以它的id为参数调用入门目录 deploy 页面。
+- 入门目录 deploy 页面按照 step字段 弹出问题，收集信息、签署条款，直到部署结束。
+    - 这个过程，受托者作为成员之一参与审议、核实。
+    - 部署结束产生的cod或者cod+PSMD委托合同。
+- step字段的每一步，应该包括以下信息：
+    - 需要的初始参数，比如问题和自述；
+    - 界面正文、注释；
+    - 用户操作，运用页面alarm、confirm、prompt；
+    - 选择核实还是对赌方式进行下去：
+        - 核实：信息打包发给受托者，进行审议、核实。
+        - 对赌：直接进入下一步。
+- 条款应该有两种形式：
+    - 核实：规定人员核实后判断适用；
+    - 对赌：把承诺写入条款，成为附条件的条款。
+- deploy的自动分发：
+    - 通过email、网页循环推动。
+    - 通过同一页面附主语提示。
+- 每个知识或判断都提供不同意入口，选择遵守附件33的索取依据，否则提示无法继续讨论。
+
+- 登记60分钟，追加todo项：
+    - '60': 可交互的静态网页
+      readme: |
+        - 根据同域名的metadata进行提示、选择、接收补充信息并跳转页面
+        - 根据不同域名的js进行类似操作。
+    - '60': 按照可交互deploy的模式整理入门目录term.9d12877c措辞
+
+---
+
+[top](#top) | [index](#index)
+<a id="20240513143000"></a>
+## 14:30~14:59
+实现todo项的多层结构
+
+- 暂时维持makedaydraft(), makedayplan() 分工。
+- 修改makedaydraft()中删除season metadata的部分。
+- 执行结果（节选）：
+```
+delete the job from PSMD:
+整理近期手稿。
+makedaydraft()> before delete todo item, waitinglist:
+task: ego
+name: 在draft+season+task metadata基础上设计有互动的总结功能
+id: 0
+
+makedaydraft()> before delete todo item:
+- '30': 在draft+season+task metadata基础上设计有互动的总结功能
+  bind:
+    - '90': 代码实现，有互动的总结功能。
+    - '60': task之间结算体系设计。
+    - '195': 在整理近期手稿之后，修订个人模型。
+- '60': 在season metadata中实现浮动时间表，修改日计划功能。
+- '30': 整理废弃git库，包括本地和远程。
+  readme: |
+    参考5.3.14:00 draft
+- '30': 设计ego.mars22.com 发布内容。
+  bing:
+    - '60': /release/entry.html 读取 markdown和metadata 并显示。
+- '60': 用js代码完成日小结后的git操作。
+  readme: |
+    - 参考：D:\huangyg\git\draft\2024\04\20240430140000.md
+    - 在各task metadata中给出git库的路径，每天根据实际任务去操作。
+
+makedaydraft()> after delete todo item:
+- '90': 代码实现，有互动的总结功能。
+- '60': task之间结算体系设计。
+- '195': 在整理近期手稿之后，修订个人模型。
+- '60': 在season metadata中实现浮动时间表，修改日计划功能。
+- '30': 整理废弃git库，包括本地和远程。
+  readme: |
+    参考5.3.14:00 draft
+- '30': 设计ego.mars22.com 发布内容。
+  bing:
+    - '60': /release/entry.html 读取 markdown和metadata 并显示。
+- '60': 用js代码完成日小结后的git操作。
+  readme: |
+    - 参考：D:\huangyg\git\draft\2024\04\20240430140000.md
+    - 在各task metadata中给出git库的路径，每天根据实际任务去操作。
+```
+
+登记70分钟，追加todo项：
+    - '60': 重新设计ego.js的命令行参数，合并函数，整理代码。
+
+---
+
+[top](#top) | [index](#index)
+<a id="20240513160000"></a>
+## 16:00~16:59
+五月报税
+
+- 使用云票助手代替原来的开票软件，完成发票抄报和反写。
+- 云票助手的数电部分需要申报才能启用，网站视频没有涉及这个步骤。
+
+登记30分钟，剩下时间再看看14点的入门目录。

release/time/d.20240514.md

@@ -0,0 +1,494 @@
+# 2024.05.14.
+日小结  
+
+<a id="top"></a>
+根据[ego模型时间接口](https://gitee.com/hyg/blog/blob/master/timeflow.md)，今天绑定模版2。
+
+<a id="index"></a>
+- 07:45	[整理新思路，无意识转化有意识作为权利分配的基点](#20240514074500)  
+- 14:00	[整理近期手稿。](#20240514140000)  
+- 16:00	[按照可交互deploy的模式整理入门目录term.9d12877c措辞](#20240514160000)  
+
+---
+season stat:
+
+| task | alloc | sold | hold | todo |
+| --- | --- | --- | --- | --- |
+| total | 13275 | 10105 | 3170 | 2670 |
+| PSMD | 7000 | 5311 | 1689 | 585 |
+| learn | 1000 | 472 | 528 | 750 |
+| ego | 3000 | 2184 | 816 | 705 |
+| js | 1375 | 705 | 670 | 300 |
+| xuemen | 600 | 1046 | -446 | 210 |
+| raw | 300 | 357 | -57 | 120 |
+| infra | 0 | 30 | -30 | 0 |
+
+---
+
+waiting list:
+
+
+- 30分钟时间片：
+  - raw的第1号事项：debug-diff mode较大天数返回空数据，创建三个R文件。
+  - ego的第2号事项：在draft+season+task metadata基础上设计有互动的总结功能
+  - js的第2号事项：自动收发email。
+  - learn的第2号事项：YARRRML
+
+- 60分钟时间片：
+  - PSMD的第1号事项：整理term.9d12877c的附件部分。
+  - ego的第1号事项：整理近期手稿
+  - js的第1号事项：可交互的静态网页
+  - learn的第1号事项：github的actions,workflow,job脚本语法
+
+- 90分钟时间片：
+  - PSMD的第2号事项：起草标准模型2405
+  - PSMD的第4号事项：term metadata生成按修订层级排版的COM metadata。
+  - learn的第6号事项：把PSMD的data、src部分升级到rdf，如果升级成功则作为范例。
+
+- 195分钟时间片：
+  - PSMD的第3号事项：term + COM matedata -> deploy metadata -> deploy view
+  - learn的第7号事项：rust入门
+
+---
+
+[top](#top) | [index](#index)
+<a id="20240514074500"></a>
+## 7:45~10:59
+整理新思路，无意识转化有意识作为权利分配的基点
+
+- 有意识行为的定义是能够提供依据：
+    - 有强制力的法规，可以作为依据；
+    - 基于实践案例的预期效果可以作为依据：
+        - 必须是涉事各方无法控制范围内的实践案例；
+        - 多种预期效果应明确量化的比例；
+        - 声称的预期效果应大范围公示并接受事后印证，涉及职务行为的纳入考核、且大范围、长时间（最好是终身）公示印证结果。
+- 未按以上标准提供依据的行为，就是无意识行为。
+- 自我保护的定义是：有意识地掩盖无意识行为。
+- 在更深一个层次，个人和共同体、智能设备这些主体，共同特征是把无意识行为转化为有意识。反映在模型上：
+    - 限定事项上，观察、分析无意识行为，转化为有意识行为；
+    - 以上限定事项清零，这个主体就注销（或退休、离线......）。
+- 主体之间：
+    - 限定事项上、限定对象，互相观察无意识行为并提交给对方，互相公示无意识行为转化为有意识行为的过程；
+    - 限定事项上、不限定对象，单方面接受观察和提交，公示无意识行为转化为有意识行为的过程；
+    - 超出以上范围，或者不明确界定的，默认都是不观察、不提交、不转化，选择让自己的无意识行为继续下去。
+- 共同体vs成员：
+    - 成员在职务范围内接受共同体安排对自身无意识行为的观察和提交，按共同体要求披露无意识行为转化为有意识行为的过程；
+    - 共同体接受成员对集体无意识行为的观察和提交，向成员公示集体无意识转化为集体有意识行为的过程；
+    - 共同体授权一个部门把集体无意识行为分解为成员个体无意识行为，默认向该成员提交，公示相关的保密规定（界定其他成员的知情范围）。
+    - 默认对外不暴露成员个体无意识行为，只公示共同体集体无意识行为。
+
+- 层次化的模型：一个层次（或部门）A负责另一个层次（或部门）B的无意识行为的观察、分析、转化。
+    - 层次A的输出，是层次B的不可修订条款；
+    - 层次A成员的任免和报酬，引入层次B+成员的参与；（具体机制是共同体定义的核心部分，相当程度上决定共同体集体无意识行为）
+        - 具体机制之一：层次B的成员对层次A已提交的无意识行为，都已经转化为规定的有意识行为，即升级为B+成员。
+    - 层次A成员的职务行为的无意识行为，接受层次B成员的观察、提交，向层次B成员公示转化为有意识行为的过程；
+
+- 准备新增一个标准模型2405，显性定义无意识和有意识的转化，把权利分配建立在这个锋面上。
+- 学门可以部署。
+- 1609成为其中外层的方案。
+- 占用了这个时间片，todo项回到waitinglist，追加todo项。
+    - '90': 起草标准模型2405
+      readme: |
+        - 设计思路在5.14 7:45时间片的draft
+
+---
+
+[top](#top) | [index](#index)
+<a id="20240514140000"></a>
+## 14:00~15:29
+整理近期手稿。
+
+### PSMD
+
+#### 1
+
+- 完整的标准模型：
+    - 原始 raw，个人模型
+        - 原始raw可以发起一次性交互
+        - 原始raw可以自动进行连续交互
+        - 原始raw在外界交互中升级后，可以直接进行连续交互
+            - 升级产生的层次化通用模型，进入标准模型库
+    - 1609
+    - 1610
+    - chain 链式
+- 二级动议：
+    - 1406 零规章启动
+
+##### 评
+
+- 无论原始raw个人模型还是default共同体模型，都是在无意识和有意识之间切换，有意识状态下理性判断：掩盖无意识行为最符合当时利益。
+- 只有无意识行为发生之前，达成一定的协议才能跳出这种处境。这些协议经过实践验证，组成标准模型库。在标准模型中，恢复有意识时理性判断：暴露并转化无意识行为最符合当时利益。
+
+#### 2
+
+- 记录的分类
+    - 无序的自然语言
+    - 规范的自然语言：法律
+    - 规范的自然语言：技术
+    - 规范的语言：代码、硬件图纸...
+- 视图定义它们之间的升级次序
+
+#### 3
+以行动代替语言
+
+1. 一部分成员开放个人领域
+    - 部署者指定
+        - 部署者任命若干委员
+        - 委员会提出个人-共同体映射方法
+            1. 向部署者个人提出要约
+            1. 实施
+            1. 部署者分立split，移植到COD中
+        - 想起他部署者征集共同体顶层规则
+    - 个人竞聘
+1. 被指定的成员更新个人领域的顶层规则
+1. 这些规则成为共同体COD的规则
+
+##### 评
+
+- 反过来，常见企业、1609、chain、2405在个人领域的雏形是什么。
+- default的个人领域雏形是原始raw？
+
+#### 4
+分析输入事件的处理过程
+
+- 外部事件被身体body接收，从下向上各层次依次给出回应。
+    - 最开始是本能instinct的输出
+    - 然后是各级event listener的输出
+- 各级守护进程deamon从所监视范围内的输出中选择一路作为这个范围的唯一输出
+- 各级守护进程deamon和event listener持续进化evolution
+
+##### 评
+
+- 实践中deamon不好实现，开销太大。
+- 实际上只能让它先输出，定期集中优势资源收集整理（观察）、分析、进化。
+
+### infra
+
+#### 1
+
+- event queue
+    - outer外部主体的事件序列：event -> event -> ... 
+    - 其中部分激发自动的event listener，产生它的事件序列：event -> event -> ...
+- 试图定义多个事件序列之间是什么关系
+
+##### 评
+
+- 分布式是难点，要验证时间、内容真伪。开销要可控。
+- 也许freenet contract可以试试，估计还是超过大部分使用者的心理预期。
+
+#### 2
+
+提出问题：自然人或局部共同体构造共同体的通用方法和工具集
+
+##### 评
+
+- 分立split和联合joint，是在有意识行为内，对资产、契约的转移。
+- 共同体是各人的一部分有意识行为的联合。
+    - 自然人的个人领域内，权利分配规则必须能进行分立和联合。
+    - 出了原始raw以外，还需要标准个人模型。
+
+#### 3
+startup协议（或booting协议）
+
+- 提出原始个人模型与原始共同体模型及筹备效果
+    - 进入“提出修改选择，以新的选择参与筹备”。
+- 提出与筹备效果有关的选项
+    - 提出该选项与筹备效果有关
+    - 公布自己的选择
+        - 核实
+        - 与标准模型库自动匹配
+        - 提出各成员选项下的模型（分工、规则等）筹备效果
+            - 质询
+                - 提出该效果的依据
+            - 调整模型，提出升级版，回到上一步“提出各成员选项下的模型（分工、规则等）筹备效果”。
+            - 提出承诺，竞聘某角色
+                - 模型启动，筹备成功，（共同体）产生新的ego。
+                - 模型共享、入库。
+            - 提出修改选择，以新的选择参与筹备
+                - 核实
+                    - 回到“公布自己的选择”
+    - 退出筹备，清算个人功过。
+
+##### 评
+
+- 这是从原始模型逐步升级个人模型（原始个人模型+个人选择），不断打补丁的过程。
+
+只整理了PSMD和infra的近期手稿，在ego追加一个todo项。
+  ego:
+    - '60': 整理近期手稿
+      bind:
+        - '195': 在整理近期手稿之后，修订个人模型。
+---
+
+[top](#top) | [index](#index)
+<a id="20240514160000"></a>
+## 16:00~16:59
+按照可交互deploy的模式整理入门目录term.9d12877c措辞
+
+- 在附件30~34的补充信息基础上做出判断后，基本可以做出判断：
+    - 21-no：
+        - 20-yes：
+            - 30-no：default
+            - 30-yes，31~34-no：
+                - 42-yes：
+                    - 43-yes：default+1406，进步后升级到1609.
+                    - 43-no：default，进步后升级到1609
+                - 42-no：
+                    - 43-yes：default+1406
+                    - 43-no：default
+            - 30~34-yes：
+                - 42-yes：
+                    - 43-yes：1609
+                    - 43-no：1609
+                - 42-no：
+                    - 43-yes：default+1406
+                    - 43-no：default
+
+- 重建了正文部分，commit并生成了view：
+```
+D:\huangyg\git\PSMD\src>node term term 9d12877c
+enter maketermtext:9d12877c     upgradeby:undefined     prefix:
+enter maketermtext:6c2eb032     upgradeby:undefined     prefix:4.
+enter maketermtext:7db5064c     upgradeby:undefined     prefix:5.
+enter maketermtext:4b12ac08     upgradeby:undefined     prefix:6.
+enter maketermtext:dbe32f79     upgradeby:undefined     prefix:附件20.
+enter maketermtext:bb8005b9     upgradeby:undefined     prefix:附件20.1.
+enter maketermtext:949e69e3     upgradeby:undefined     prefix:附件20.2.
+enter maketermtext:33523fe1     upgradeby:undefined     prefix:附件20.2.1.
+enter maketermtext:a1c197a9     upgradeby:undefined     prefix:附件20.2.2.
+enter maketermtext:259076a4     upgradeby:undefined     prefix:附件20.2.3.
+enter maketermtext:d0111eb4     upgradeby:undefined     prefix:附件21.
+enter maketermtext:4116b506     upgradeby:undefined     prefix:附件21.1.
+enter maketermtext:607455c0     upgradeby:undefined     prefix:附件21.2.
+enter maketermtext:91ff9448     upgradeby:undefined     prefix:附件30.
+enter maketermtext:6d206b54     upgradeby:undefined     prefix:附件31.
+enter maketermtext:6988b66d     upgradeby:undefined     prefix:附件31.1.
+enter maketermtext:5f7eed28     upgradeby:undefined     prefix:附件31.2.
+enter maketermtext:c8254555     upgradeby:undefined     prefix:附件31.3.
+enter maketermtext:90c5a430     upgradeby:undefined     prefix:附件31.4.
+enter maketermtext:9e6bc34f     upgradeby:undefined     prefix:附件32.
+enter maketermtext:d1f88a2c     upgradeby:undefined     prefix:附件32.1.
+enter maketermtext:2e758794     upgradeby:undefined     prefix:附件32.2.
+enter maketermtext:d13b27d1     upgradeby:undefined     prefix:附件32.3.
+enter maketermtext:df39a1ed     upgradeby:undefined     prefix:附件32.4.
+enter maketermtext:600f6f80     upgradeby:undefined     prefix:附件33.
+enter maketermtext:50d2347f     upgradeby:undefined     prefix:附件33.1.
+enter maketermtext:4c37b176     upgradeby:undefined     prefix:附件33.2.
+enter maketermtext:55c25f3f     upgradeby:undefined     prefix:附件33.3.
+enter maketermtext:064129fa     upgradeby:undefined     prefix:附件33.4.
+enter maketermtext:12119600     upgradeby:undefined     prefix:附件34.
+enter maketermtext:1c3f8b06     upgradeby:undefined     prefix:附件34.1.
+enter maketermtext:49d40087     upgradeby:undefined     prefix:附件34.2.
+enter maketermtext:5c7d5a18     upgradeby:undefined     prefix:附件34.3.
+enter maketermtext:5f7bbbe4     upgradeby:undefined     prefix:附件34.4.
+enter maketermtext:cb4ab0e9     upgradeby:undefined     prefix:附件42.
+enter maketermtext:5ab2b2ba     upgradeby:undefined     prefix:附件43.
+../view/term.9d12877c.md文件更新，内容如下:
+条款 9d12877c 正文:
+ 针对不同条件给出建议如下：
+1. 条件：如果不能按照附件21核实情况，也不能按照附件20补充信息。
+建议：在业务背景下，基于既成事实博弈。具体可以参考default标准模型。
+2. 条件：如果能按照附件21核实情况，或者按照附件20补充信息。
+建议：针对附件30、附件31、附件32、附件33、附件34安排核实。
+3. 条件：如果不符合附件30。
+建议：在业务背景下，基于既成事实博弈。具体可以参考default标准模型。
+4. 条件：如果符合附件30，但是不全符合附件31、附件32、附件33、附件34。
+建议：针对附件42、附件43安排核实。
+4.1. 条件：如果附件42、附件43都符合。
+建议：先参考default+1406标准模型开展业务，逐步完善规章，取得进步后重新增加关于附件31、附件32、附件33、附件34的补充信息。
+4.2. 条件：如果符合附件42、不符合附件43。
+建议：在业务背景下，基于既成事实博弈。具体可以参考default标准模型。
+4.3. 条件：如果不符合附件42、符合附件43。
+建议：先参考default+1406标准模型开展业务。
+4.4. 条件：如果附件42、附件43都不符合。
+建议：在业务背景下，基于既成事实博弈。具体可以参考default标准模型。
+5. 条件：如果符合附件30，也全部符合附件31、附件32、附件33、附件34。
+建议：针对附件42、附件43安排核实。
+5.1. 条件：如果附件42、附件43都符合。
+建议：使用自定义的规章解决资源和重构问题，具体可以参考1609+1406、chain+1406等标准模型。
+5.2. 条件：如果符合附件42、不符合附件43。
+建议：使用自定义的规章解决资源和重构问题，具体可以参考1609、chain等标准模型。
+5.3. 条件：如果不符合附件42、符合附件43。
+建议：先参考default+1406标准模型开展业务。
+5.4. 条件：如果附件42、附件43都不符合。
+建议：在业务背景下，基于既成事实博弈。具体可以参考default标准模型。
+6. 如果有其它可行方案请发到<huangyg@mars22.com>，我将按照附件21核实。
+附件20.1. 对自述难以核实的情况下，可以按照第2条方式之一增加补充信息：
+附件20.2.1. 涉事各方全体同意，推举一名或多名保证人：
+  - 保证人在其它事项中符合该条件，并按照本附件提供补充信息。
+  - 由保证人调查涉事各方是否符合该条件，将调查记录作为补充信息。
+附件20.2.2. 涉事各方分别自述，交叉核实。将所有记录合并作为补充信息。
+附件20.2.3. 涉事各方签署 附件21，承诺遵守该条件，将生效、执行的记录作为补充信息。
+附件21.1. 公布完整、连续、不可删改的记录，证实过去行为属实、预期效果可信。
+附件21.2. 发布开放的要约，只有取得该预期效果才有收益。证实预期效果可信。
+附件30. 定义：已有基础制度和人员，能保证书面规章的违约成本高于收益。规定监管人员以外的内部成员、外部合作方不需要额外为此耗费资源。
+附件31.1. 规章条款的上下级关系，根据制定、修订权定义。
+附件31.2. 人员的上下级关系，根据任免权定义。
+附件31.3. 严格执行制定、修订程序。上级规章条款未生效（或被实质架空）时，不提交、不讨论下级规章条款。
+附件31.4. 严格执行任免程序。上级人员未赴任（或被实质架空）时，不提名、不讨论下级人员。
+附件32.1. 所有人员的所有工作结果默认为公开，对外发布。
+附件32.2. 按附件31上溯得出顶级规章，从顶级规章到保密制度之间的上下级规章链条（包括保密制度），这组规章的密级均为公开，这组规章的工作记录的密级由该规章自行规定，保密制度不得改变。
+附件32.3. 一份文档所有用途使用相同方式取得。如果因不可抗力需要改变方式，应规定不可抗力的判定程序，确保内容相同。
+附件32.4. 如果在密级规定范围内的人员都没有能力完成任务，制定保密制度相应条款的人员承担主要责任，赔偿损失。
+附件33.1. 制定规章要明确预期效果。
+附件33.2. 接到质询时必须提供依据，依据必须是 外部法律 or 案例统计 两种方式之一。
+附件33.3. 如果是旧版本修订，制定者可以提出适用范围。只能向该适用范围内使用旧版规章的共同体发送修订通知。
+附件33.4. 分支隔离规则适用于制定规章。一个分支的共同体内制定规章时，所提供依据如果使用其它分支的案例，将自动增加切换规章的动议作为前提。
+附件34.1. 对相同事项的不同处理方法，视为同一规章的不同分支版本。对该事项未做任何规定，也视为其中一个分支版本。
+附件34.2. 实际通过生效、使用某分支版本的规章，即为支持该分支版本，反对其它分支版本。
+附件34.3. 规章使用过程遇到问题可以提出修订委托，如发往反对者将自动转为帮助切换规章的委托（切换到对方实际使用的分支版本）。如果是付费委托，受托者只需回答实际收到的问题。
+附件34.4. 查询资料时，未做任何规定分支可以列出所有分支的资料，其它分支只列出本分支的资料。
+附件42. 定义：需要以未来的收入换取资源，而且需要与同行争夺。
+反向的情况，是创始时能一次筹集到足够的资源，可见未来的收入和积累都超过支出。或者需要以未来的收入换取资源，但是不需要竞争即可获得充足资源。
+附件43. 定义：核心人员凭借职权高估自己的贡献、低估非核心成员的贡献，这样做的综合效果更符合他们的利益。
+反向的情况，核心人员准确估算包括自己在内的成员贡献，这样做的综合效果更符合他们的利益。
+
+---
+readme:
+条款 9d12877c. 6.
+- "可行"是指：
+  - 方案的内容完整、准确、无二义性，具备相关岗位普通资质的人员可以自行阅读、使用。
+  - 在独立的第三方实施，可以按预期的比率产生预期的效果。
+- 注意判断：成员下意识地把自己的工作特殊化、隐蔽化。
+附件20.
+附件20.2.
+- upgradeby应该分内部、外部两种情况定义。
+附件31.
+- 以“规章条款”为单位。比如某公司章程有一条：股东会三分之二表决权通过可以修订章程。这条本身就在章程里面，所以也能修订自己。（比如修改为：股东会四分之三表决权通过可以修订章程。）这个条款就比章程的其它条款都高一级。无论怎么组合编集，都不影响这种层级关系。
+- 比如规章写明A任免B和C，即使在其它文件使用“B是C上级”、“C接受B的指令”这类措辞，本标准下BC平级、都是A下级。A缺席时B讨论C的人选即违规（如果B是章程中有PS标准的账号，会立刻被强制注销财产充公）。
+- 无法判断时按最坏情况处理，比如因保密制度不能阅读就按未生效、未被执行看待。
+- 上级规章制定过程可以讨论规章草案下的工作场景，包括制定下级规章的场景。只有特定上级规章导致特定下级规章草案不能产生，引入讨论才有意义。一旦离开上级规章制定程序的时间、地点、人员这些条件就不能提前讨论下级规章，因为这时上级规章（下级规章制定修订程序）还没有生效，不应该暗示自己的内定角色。
+- 待实现的后续规则：不遵守则由自然人承担。比如一个共同体的上级规章被架空时讨论下级规章，则以该自然人代替共同体承担规章中的权利，比如向执行下级规章的员工发工资。（也就是从共同体剥离，并入个人领域）"
+附件32.
+- 顶层权利分配规则肯定在保密制度之上，因此PSMD只讨论公开资料。
+- 如果某个审议环节从某网址取得一份资料，这份资料从产生、生效、所有使用环节都从这个网址获得。比如是指令，下达指令者应在这个网址发布指令，然后通知接受指令者去阅读。
+附件32.2.
+- 注意特殊化的保密规定：下级规章或由下级规章任免的人员，规定了上级规章及其工作记录的密级。
+  - 常见于规章制订、人员任免脱离上级规章，出现脱节的情况。借保密隐藏过失。
+- 注意判断：成员下意识地把自己的工作特殊化、隐蔽化。
+附件33.
+比如不采用PS标准的共同体，制定规章时以采用PS标准分支下的案例为依据，则自动增加采用PS标准的动议，切换生效之后才能讨论所制定规章。
+附件33.2.
+- 接受质询并回应，可以检验该成员是否下意识地把自己的特殊化、隐蔽化。
+- 依据的客观性，可以判断该成员能否在有意识的情况下判断效果。
+附件34.
+- 例如：共同体A采用PS标准，共同体B、C没有。当B在上级规章未生效时要讨论下级规章。B向C提出咨询，C收到B发出的原始咨询内容。B向A提出咨询，咨询内容自动转化为“如何在规章中增加PS标准”，A无法收到B发出的原始咨询内容。这条规则主要提醒自我安慰性的求助，向反对者求助就是承认自身行为导致问题无解。
+- 在父项目，各隔离分支将使用不同记账单位。相同金额不同单位，视为同工同酬。比如采用PS标准的分支使用M为单位，不采用PS标准分支使用N为单位，自由兑换的平衡点是1M兑换10N。一项工作的报酬是5，两个分支账号分别得到5M（可兑换50N）、5N的报酬。
+附件34.1.
+- 注意特殊化的隐藏方案：不需要与其它方案对比，不需要显性地公布内容，而视为已经通过产生效力。
+  - 现状常常被特殊化。
+- 注意判断：成员下意识地把自己赞成的方案特殊化、隐蔽化。
+附件34.3.
+- 避免断章取义：隐藏规章之间的依赖关系，截取个别章节和效果，用来支持相反的前置条款。
+  - 例如：不刷牙的张三向刷牙的李四询问后续问题，李四只需要回答如何从不刷牙开始刷牙，而无须回答张三的原始问题。以免被断章取义。
+    - 注意是后续问题。如果询问刷牙的效果（假设这是他们最初的选择分岔点），则可以直接回答。
+- 注意：有的是故意设套。也有下意识地--理性的一面已经做出可靠的判断，潜意识里做出相反的选择，于是无法自控地沿着曾经说服过自己的模式去“套话”。
+附件43.
+注意判断：即使规章（包括草案、参考案例）已经足够完善，足以保证准确估算贡献符合利益，依然有成员下意识地高估自己的贡献、低估其他成员的贡献，无法自控。
+
+Warning: missing space before text for line 6 of jade file "undefined"
+Warning: missing space before text for line 8 of jade file "undefined"
+Warning: missing space before text for line 10 of jade file "undefined"
+../view/term.9d12877c.html文件更新，内容如下:
+<html lang="zh-cn"><head><title>term html sample</title><script></script></head><body><h3>条款 9d12877c</h3><hr/><p>正文:</p><p> 针对不同条件给出建 议如下：<br/>
+1. 条件：如果不能按照附件21核实情况，也不能按照附件20补充信息。<br/>
+建议：在业务背景下，基于既成事实博弈。具体可以参考default标准模型。<br/>
+2. 条件：如果能按照附件21核实情况，或者按照附件20补充信息。<br/>
+建议：针对附件30、附件31、附件32、附件33、附件34安排核实。<br/>
+3. 条件：如果不符合附件30。<br/>
+建议：在业务背景下，基于既成事实博弈。具体可以参考default标准模型。<br/>
+4. 条件：如果符合附件30，但是不全符合附件31、附件32、附件33、附件34。<br/>
+建议：针对附件42、附件43安排核实。<br/>
+4.1. 条件：如果附件42、附件43都符合。<br/>
+建议：先参考default+1406标准模型开展业务，逐步完善规章，取得进步后重新增加关于附件31、附件32、附件33、附件34的补充信息。<br/>
+4.2. 条件：如果符合附件42、不符合附件43。<br/>
+建议：在业务背景下，基于既成事实博弈。具体可以参考default标准模型。<br/>
+4.3. 条件：如果不符合附件42、符合附件43。<br/>
+建议：先参考default+1406标准模型开展业务。<br/>
+4.4. 条件：如果附件42、附件43都不符合。<br/>
+建议：在业务背景下，基于既成事实博弈。具体可以参考default标准模型。<br/>
+5. 条件：如果符合附件30，也全部符合附件31、附件32、附件33、附件34。<br/>
+建议：针对附件42、附件43安排核实。<br/>
+5.1. 条件：如果附件42、附件43都符合。<br/>
+建议：使用自定义的规章解决资源和重构问题，具体可以参考1609+1406、chain+1406等标准模型。<br/>
+5.2. 条件：如果符合附件42、不符合附件43。<br/>
+建议：使用自定义的规章解决资源和重构问题，具体可以参考1609、chain等标准模型。<br/>
+5.3. 条件：如果不符合附件42、符合附件43。<br/>
+建议：先参考default+1406标准模型开展业务。<br/>
+5.4. 条件：如果附件42、附件43都不符合。<br/>
+建议：在业务背景下，基于既成事实博弈。具体可以参考default标准模型。<br/>
+6. 如果有其它可行方案请发到<huangyg@mars22.com>，我将按照附件21核实。<br/>
+附件20.1. 对自述难以核实的情况下，可以按照第2条方式之一增加补充信息：<br/>
+附件20.2.1. 涉事各方全体同意，推举一名或多名保证人：<br/>
+  - 保证人在其它事项中符合该条件，并按照本附件提供补充信息。<br/>
+  - 由保证人调查涉事各方是否符合该条件，将调查记录作为补充信息。<br/>
+附件20.2.2. 涉事各方分别自述，交叉核实。将所有记录合并作为补充信息。<br/>
+附件20.2.3. 涉事各方签署 附件21，承诺遵守该条件，将生效、执行的记录作为补充信息。<br/>
+附件21.1. 公布完整、连续、不可删改的记录，证实过去行为属实、预期效果可信。<br/>
+附件21.2. 发布开放的要约，只有取得该预期效果才有收益。证实预期效果可信。<br/>
+附件30. 定义：已有基础制度和人员，能保证书面规章的违约成本高于收益。规定监管人员以外的内部成员、外部合作方不需要额外为此耗费资源。<br/>
+附件31.1. 规章条款的上下级关系，根据制定、修订权定义。<br/>
+附件31.2. 人员的上下级关系，根据任免权定义。<br/>
+附件31.3. 严格执行制定、修订程序。上级规章条款未生效（或被实质架空）时，不提交、不讨论下级规章条款。<br/>
+附件31.4. 严格执行任免程序。上级人员未赴任（或被实质架空）时，不提名、不讨论下级人员。<br/>
+附件32.1. 所有人员的所有工作结果默认为公开，对外发布。<br/>
+附件32.2. 按附件31上溯得出顶级规章，从顶级规章到保密制度之间的上下级规章链条（包括保密制度），这组规章的密级均为公开，这组规章的工作记录的密级由该规章自行规定，保密制度不得改变。<br/>
+附件32.3. 一份文档所有用途使用相同方式取得。如果因不可抗力需要改变方式，应规定不可抗力的判定程序，确保内容相同。<br/>
+附件32.4. 如果在密级规定范围内的人员都没有能力完成任务，制定保密制度相应条款的人员承担主要责任，赔偿损失。<br/>
+附件33.1. 制定规章要明确预期效果。<br/>
+附件33.2. 接到质询时必须提供依据，依据必须是 外部法律 or 案例统计 两种方式之一。<br/>
+附件33.3. 如果是旧版本修订，制定者可以提出适用范围。只能向该适用范围内使用旧版规章的共同体发送修订通知。<br/>
+附件33.4. 分支隔离规则适用于制定规章。一个分支的共同体内制定规章时，所提供依据如果使用其它分支的案例，将自动增加切换规章的动议作为前提。<br/>
+附件34.1. 对相同事项的不同处理方法，视为同一规章的不同分支版本。对该事项未做任何规定，也视为其中一个分支版本。<br/>
+附件34.2. 实际通过生效、使用某分支版本的规章，即为支持该分支版本，反对其它分支版本。<br/>
+附件34.3. 规章使用过程遇到问题可以提出修订委托，如发往反对者将自动转为帮助切换规章的委托（切换到对方实际使用的分支版本）。如果是付费委托，受托者只需回答实际收到的问题。<br/>
+附件34.4. 查询资料时，未做任何规定分支可以列出所有分支的资料，其它分支只列出本分支的资料。<br/>
+附件42. 定义：需要以未来的收入换取资源，而且需要与同行争夺。<br/>
+反向的情况，是创始时能一次筹集到足够的资源，可见未来的收入和积累都超过支出。或者需要以未来的收入换取资源，但是不需要竞争即可获得充足资源。<br/>
+附件43. 定义：核心人员凭借职权高估自己的贡献、低估非核心成员的贡献，这样做的综合效果更符合他们的利益。<br/>
+反向的情况，核心人员准确估算包括自己在内的成员贡献，这样做的综合效果更符合他们的利益。<br/>
+</p><hr/><p>注释:</p><p>6.<br/>
+- "可行"是指：<br/>
+  - 方案的内容完整、准确、无二义性，具备相关岗位普通资质的人员可以自行阅读、使用。<br/>
+  - 在独立的第三方实施，可以按预期的比率产生预期的效果。<br/>
+- 注意判断：成员下意识地把自己的工作特殊化、隐蔽化。<br/>
+附件20.<br/>
+附件20.2.<br/>
+- upgradeby应该分内部、外部两种情况定义。<br/>
+附件31.<br/>
+- 以“规章条款”为单位。比如某公司章程有一条：股东会三分之二表决权通过可以修订章程。这条本身就在章程里面，所以也能修订自己。（比如修改为：股东会四分之三表决权通过可以修订章程。）这个条款就比章程的其它条款都高一级。无论怎么组合编集，都不影响这种层级关系。<br/>
+- 比如规章写明A任免B和C，即使在其它文件使用“B是C上级”、“C接受B的指令”这类措辞，本标准下BC平级、都是A下级。A缺席时B讨论C的人选即违规（如果B是章程中有PS标准的账号，会立刻被强制注销财产充公）。<br/>
+- 无法判断时按最坏情况处理，比如因保密制度不能阅读就按未生效、未被执行看待。<br/>
+- 上级规章制定过程可以讨论规章草案下的工作场景，包括制定下级规章的场景。只有特定上级规章导致特定下级规章草案不能产生，引入讨论才有意义。一旦离开上级规章制定程序的时间、地点、人员这些条件就不能提前讨论下级规章，因为这时上级规章（下级规章制定修订程序）还没有生效，不应该暗示自己的内定角色。<br/>
+- 待实现的后续规则：不遵守则由自然人承担。比如一个共同体的上级规章被架空时讨论下级规章，则以该自然人代替共同体承担规章中的权利，比如向执行下级规章的员工发工资。（也就是从共同体剥离，并入个人领域）"<br/>
+附件32.<br/>
+- 顶层权利分配规则肯定在保密制度之上，因此PSMD只讨论公开资料。<br/>
+- 如果某个审议环节从某网址取得一份资料，这份资料从产生、生效、所有使用环节都从这个网址获得。比如是指令，下达指令者应在这个网址发布指令，然后通知接受指令者去阅读。<br/>
+附件32.2.<br/>
+- 注意特殊化的保密规定：下级规章或由下级规章任免的人员，规定了上级规章及其工作记录的密级。<br/>
+  - 常见于规章制订、人员任免脱离上级规章，出现脱节的情况。借保密隐藏过失。<br/>
+- 注意判断：成员下意识地把自己的工作特殊化、隐蔽化。<br/>
+附件33.<br/>
+比如不采用PS标准的共同体，制定规章时以采用PS标准分支下的案例为依据，则自动增加采用PS标准的动议，切换生效之后才能讨论所制定规章。<br/>
+附件33.2.<br/>
+- 接受质询并回应，可以检验该成员是否下意识地把自己的特殊化、隐蔽化。<br/>
+- 依据的客观性，可以判断该成员能否在有意识的情况下判断效果。<br/>
+附件34.<br/>
+- 例如：共同体A采用PS标准，共同体B、C没有。当B在上级规章未生效时要讨论下级规章。B向C提出咨询，C收到B发出的原始咨询内容。B向A提出咨询，咨询内容自动转化为“如何在规章中增加PS标准”，A无法收到B发出的原始咨询内容。这条规则主要提醒自我安慰性的求助，向反对者求助就是承认自身行为导致问题无解。<br/>
+- 在父项目，各隔离分支将使用不同记账单位。相同金额不同单位，视为同工同酬。比如采用PS标准的分支使用M为单位，不采用PS标准分支使用N为单位，自由兑换的平衡点是1M兑换10N。一项工作的报酬是5，两个分支账号分别得到5M（可兑换50N）、5N的报酬。<br/>
+附件34.1.<br/>
+- 注意特殊化的隐藏方案：不需要与其它方案对比，不需要显性地公布内容，而视为已经通过产生效力。<br/>
+  - 现状常常被特殊化。<br/>
+- 注意判断：成员下意识地把自己赞成的方案特殊化、隐蔽化。<br/>
+附件34.3.<br/>
+- 避免断章取义：隐藏规章之间的依赖关系，截取个别章节和效果，用来支持相反的前置条款。<br/>
+  - 例如：不刷牙的张三向刷牙的李四询问后续问题，李四只需要回答如何从不刷牙开始刷牙，而无须回答张三的原始问题。以免被断章取义。<br/>
+    - 注意是后续问题。如果询问刷牙的效果（假设这是他们最初的选择分岔点），则可以直接回答。<br/>
+- 注意：有的是故意设套。也有下意识地--理性的一面已经做出可靠的判断，潜意识里做出相反的选择，于是无法自控地沿着曾经说服过自己的模式去“套话”。<br/>
+附件43.<br/>
+注意判断：即使规章（包括草案、参考案例）已经足够完善，足以保证准确估算贡献符合利益，依然有成员下意识地高估自己的贡献、低估其他成员的贡献，无法自控。<br/>
+</p><hr/></body></html>
+```
+
+- 还需要追加todo项去整理附件：
+    - '60': 整理term.9d12877c的附件部分。

release/time/d.20240515.md

@@ -0,0 +1,263 @@
+# 2024.05.15.
+日小结  
+
+<a id="top"></a>
+根据[ego模型时间接口](https://gitee.com/hyg/blog/blob/master/timeflow.md)，今天绑定模版1。
+
+<a id="index"></a>
+- 07:45	[整理term.9d12877c的附件部分。](#20240515074500)  
+- 09:30	[准备银行资料](#20240515093000)  
+- 14:00	[debug-diff mode较大天数返回空数据，创建三个R文件。](#20240515140000)  
+- 14:30	[增加email互动](#20240515143000)  
+- 16:00	[整理近期手稿](#20240515160000)  
+
+---
+season stat:
+
+| task | alloc | sold | hold | todo |
+| --- | --- | --- | --- | --- |
+| total | 13275 | 10382 | 2893 | 2580 |
+| PSMD | 7000 | 5371 | 1629 | 525 |
+| learn | 1000 | 472 | 528 | 750 |
+| ego | 3000 | 2304 | 696 | 705 |
+| js | 1375 | 705 | 670 | 300 |
+| xuemen | 600 | 1136 | -536 | 210 |
+| raw | 300 | 364 | -64 | 90 |
+| infra | 0 | 30 | -30 | 0 |
+
+---
+
+waiting list:
+
+
+- 30分钟时间片：
+  - ego的第1号事项：在draft+season+task metadata基础上设计总结功能
+  - js的第2号事项：自动收发email。
+  - learn的第2号事项：YARRRML
+  - raw的第2号事项：检查etable递归过程是否累加amount字段而未检查unit字段的。
+
+- 60分钟时间片：
+  - js的第1号事项：可交互的静态网页
+  - learn的第1号事项：github的actions,workflow,job脚本语法
+  - raw的第1号事项：根据过去数据给出15天内的建议。
+  - xuemen的第1号事项：整理kernel、ISU、JPU之间的关系，厘清概念。
+
+- 90分钟时间片：
+  - PSMD的第1号事项：起草标准模型2405
+  - PSMD的第3号事项：term metadata生成按修订层级排版的COM metadata。
+  - ego的第3号事项：代码实现，有互动的总结功能。
+  - learn的第6号事项：把PSMD的data、src部分升级到rdf，如果升级成功则作为范例。
+
+- 195分钟时间片：
+  - PSMD的第2号事项：term + COM matedata -> deploy metadata -> deploy view
+  - learn的第7号事项：rust入门
+
+---
+
+<a href="mailto:huangyg@mars22.com?subject=关于2024.05.15.[整理term.9d12877c的附件部分。]任务&body=日期: 20240515%0D%0A序号: 0%0D%0A手稿:../../draft/2024/05/20240515074500.md%0D%0A---请勿修改邮件主题及以上内容 从下一行开始写您的想法---%0D%0A">[email]</a> | [top](#top) | [index](#index)
+<a id="20240515074500"></a>
+## 7:45~8:44
+整理term.9d12877c的附件部分。
+
+- 整理 附件20
+    - 删去949e69e3
+    - 删去bb8005b9
+    - 把它们的条款集中到 dbe32f79
+    - 可以删去20.3，把原20.2上提首选，原20.1下降为备选。   
+    - 或者把附件20、21合并。
+        - 删除33523fe1
+        - 删除a1c197a9
+        - 删除259076a4
+        - 删除4116b506
+        - 删除607455c0
+```
+附件20. 对于已发生的行为，可以按照以下方式之一进行核实：
+附件20.1. 提供完整、连续、不可删改的记录；
+附件20.2. 提供涉事各方的自述，以及每一方对其他方自述的意见；
+附件20.3. 涉事各方全体同意，推举一名或多名保证人：
+- 保证人在自己主要工作中，按照前两条之一公布信息；
+- 由保证人调查涉事各方的历史行为，提供调查记录。
+附件21. 对于某方案的预期效果，可以按照以下方式之一提供依据：
+附件21.1. 有强制力的法规，保证该预期效果；
+附件21.2. 实践案例的效果：
+- 必须是涉事各方无法控制范围内的实践案例；
+- 多种预期效果应按实践结果估算比例。
+附件21.3. 发布开放的要约：
+- 职务行为按附件20进行公示，接受事后印证并公示印证结果；
+- 该预期效果纳入考核，以取得该预期效果为前提获得收益。
+```
+
+- 利用休整时间继续整理，已经对外试用，过段时间总结试用结果。
+
+---
+
+<a href="mailto:huangyg@mars22.com?subject=关于2024.05.15.[准备银行资料]任务&body=日期: 20240515%0D%0A序号: 1%0D%0A手稿:../../draft/2024/05/20240515093000.md%0D%0A---请勿修改邮件主题及以上内容 从下一行开始写您的想法---%0D%0A">[email]</a> | [top](#top) | [index](#index)
+<a id="20240515093000"></a>
+##  9:30~10:59
+整理材料
+
+时间被银行事务临时占用，todo项回到waitinglist。
+---
+
+<a href="mailto:huangyg@mars22.com?subject=关于2024.05.15.[debug-diff mode较大天数返回空数据，创建三个R文件。]任务&body=日期: 20240515%0D%0A序号: 2%0D%0A手稿:../../draft/2024/05/20240515140000.md%0D%0A---请勿修改邮件主题及以上内容 从下一行开始写您的想法---%0D%0A">[email]</a> | [top](#top) | [index](#index)
+<a id="20240515140000"></a>
+## 14:00~14:29
+debug-diff mode较大天数返回空数据，创建三个R文件。
+
+- 使用-1000、-2000、-3000都不能重现问题。可以返回正确数据。
+- 可能以前正好diff到一个出差或者连续熬夜的时间，没有数据。
+- 登记7分钟，提前开始下一个任务。
+
+---
+
+<a href="mailto:huangyg@mars22.com?subject=关于2024.05.15.[增加email互动]任务&body=日期: 20240515%0D%0A序号: 3%0D%0A手稿:../../draft/2024/05/20240515143000.md%0D%0A---请勿修改邮件主题及以上内容 从下一行开始写您的想法---%0D%0A">[email]</a> | [top](#top) | [index](#index)
+<a id="20240515143000"></a>
+## 14:30~14:59
+增加email互动
+
+- 在日计划、日小结、次日规划上增加了含有主体和简要信息的email入口。
+- 登记60分钟，总结功能另外追加todo项：
+- '30': 在draft+season+task metadata基础上设计总结功能
+
+---
+
+<a href="mailto:huangyg@mars22.com?subject=关于2024.05.15.[整理近期手稿]任务&body=日期: 20240515%0D%0A序号: 4%0D%0A手稿:../../draft/2024/05/20240515160000.md%0D%0A---请勿修改邮件主题及以上内容 从下一行开始写您的想法---%0D%0A">[email]</a> | [top](#top) | [index](#index)
+<a id="20240515160000"></a>
+## 16:00~16:59
+整理近期手稿
+
+### ego
+
+#### 1 
+共同体模型和自然人模型的统一接口
+
+- 调整接口
+    - 交易 or 达成合同
+    - 分立 split
+    - 合并 joint
+- 使用接口
+    - 行使权力 or 可选的、主动的行为
+    - 履行责任 or 强制的、被动的行为
+    - 提取利益 or 使用记账服务，可视为权力。
+- 对内
+    - 升级个体模型
+
+##### 评
+
+- 权责接口可以用来生成菜单项
+- 可以结合其它脚本语法，在实现中再检验。
+
+#### 2
+
+1. 在不同合同（账号）下对外交互
+1. 不同合同（账号）在自我资源中的分配优先权
+1. 各账号成就的管理
+
+- P2 event
+- P1 evnet
+    - 主体小结：一次性交流 -> 要约 -> 正式合同 -> 项目交流
+
+- raw
+    - time
+        - event ：text、law、code
+            - 每日计划
+            - 每日小结
+            - 每月计划
+                - 分配到账号下
+            - 每月小结
+    - food
+    - health
+
+##### 评
+
+- 怎么从对外交互传递压力到内部，产生最佳的行为。
+- 跨账号、跨合同的事件之间怎么使用统一的尺度分配资源。
+- 只是罗列零散想法，没有形成可执行的方案。
+
+#### 3
+
+-raw
+    - time -> log
+    - food
+    - health
+
+- input -> 分类, tag
+    - 人工处理作为sample
+        - 人工复制draft到output
+    - code + data处理
+        - 自动产生draft -> output
+            - 营养成分表
+                - 日
+                - 始末
+                - 增量
+            - 时间表
+                - 计划
+                - 小结
+            - tag表
+                - 层级
+                - 分配权重
+
+- level n output
+    - 人工sample
+    - metadata + code
+        - level n+1 sample
+        - metadata + code
+            - level n+2 sample
+                - ......
+
+##### 评
+
+- 一个层级的人工编程、编辑metadata，就是更深层级的sample，进一步以code+metadata实现同样的工作。
+- 沿着这个模型，不断寻找更深层级的知识。
+
+#### 4
+自然人的个体模型：原始到破缸
+
+- 条件反射：在vat中使用一些假设和定义对input产生output，同时产生log
+- 有意识的行为：在vat以外根据event listener、FSM、LUT对input产生output，同时产生log
+- 对log进行分析、识别提取出假设、定义以及其上的条件反射 -> 共享入库 -> 在分析识别中使用
+    - 修改event listener
+    - 修改FSM
+    - 修改LUT
+
+##### 评
+
+- 把进化过程显性化，便于下一步设计metadata和合同。
+
+#### 5
+site (container)
+
+- deploy
+    - fork
+    - split
+    - joint
+
+##### container is  a type of deployment for support others
+
+- model+token输入到container中，产生deployment
+    - event经过container的mux传递到deployment
+    - deployment的action经过container的filter输出到外界
+- 对container中的deployment建模（modeling），产生model
+
+##### 评
+
+- 帮助个人模型升级的过渡装置，也是一个主体对另一个主体的孵化。
+
+#### 6
+
+- event -> entity -> action + record
+- entity
+    - public
+        - deploy <- model repo
+        - modeling -> model repo
+            - model repo -deploy-> container = human or  mechine or node
+    - private
+
+##### 评
+- 描述了模型库的原始来源：一些实践案例的public部分
+- 描述了container的三种类型
+
+---
+
+- 还没有整理完，继续最佳todo项。
+

release/time/d.20240516.md

@@ -0,0 +1,149 @@
+# 2024.05.16.
+日小结  
+
+<a id="top"></a>
+根据[ego模型时间接口](https://gitee.com/hyg/blog/blob/master/timeflow.md)，今天绑定模版1。
+
+<a id="index"></a>
+- 07:45	[可交互的静态网页](#20240516074500)  
+- 09:30	[起草标准模型2405](#20240516093000)  
+- 14:00	[在draft+season+task metadata基础上设计总结功能](#20240516140000)  
+- 14:30	[自动收发email。](#20240516143000)  
+- 16:00	[github的actions,workflow,job脚本语法](#20240516160000)  
+
+---
+season stat:
+
+| task | alloc | sold | hold | todo |
+| --- | --- | --- | --- | --- |
+| total | 13275 | 10652 | 2623 | 2490 |
+| PSMD | 7000 | 5461 | 1539 | 435 |
+| learn | 1000 | 532 | 468 | 690 |
+| ego | 3000 | 2334 | 666 | 675 |
+| js | 1375 | 795 | 580 | 390 |
+| xuemen | 600 | 1136 | -536 | 210 |
+| raw | 300 | 364 | -64 | 90 |
+| infra | 0 | 30 | -30 | 0 |
+
+---
+
+waiting list:
+
+
+- 30分钟时间片：
+  - learn的第1号事项：YARRRML
+  - learn的第2号事项：docker
+  - raw的第2号事项：检查etable递归过程是否累加amount字段而未检查unit字段的。
+  - PSMD的第3号事项：PSMD委托合同的metadata
+
+- 60分钟时间片：
+  - ego的第1号事项：整理近期手稿
+  - js的第1号事项：用imap和mailparse自动处理并回复email
+  - raw的第1号事项：根据过去数据给出15天内的建议。
+  - xuemen的第1号事项：整理kernel、ISU、JPU之间的关系，厘清概念。
+
+- 90分钟时间片：
+  - PSMD的第2号事项：term metadata生成按修订层级排版的COM metadata。
+  - ego的第2号事项：代码实现，有互动的总结功能。
+  - learn的第5号事项：把PSMD的data、src部分升级到rdf，如果升级成功则作为范例。
+
+- 195分钟时间片：
+  - PSMD的第1号事项：term + COM matedata -> deploy metadata -> deploy view
+  - learn的第6号事项：rust入门
+
+---
+
+<a href="mailto:huangyg@mars22.com?subject=关于2024.05.16.[可交互的静态网页]任务&body=日期: 20240516%0D%0A序号: 0%0D%0A手稿:../../draft/2024/05/20240516074500.md%0D%0A---请勿修改邮件主题及以上内容 从下一行开始写您的想法---%0D%0A">[email]</a> | [top](#top) | [index](#index)
+<a id="20240516074500"></a>
+## 7:45~8:44
+可交互的静态网页
+
+- 根据同域名的metadata进行提示、选择、接收补充信息并跳转页面
+- 根据不同域名的js进行类似操作。
+- 范例：
+    - https://hyg.codeberg.page/blog/@master/release/term.html
+    - http://today.mars22.com/blog/release/term.html
+        - 不行，PSMD库在xuemen账号下，不在hyg，所以是跨域了。
+
+---
+
+<a href="mailto:huangyg@mars22.com?subject=关于2024.05.16.[起草标准模型2405]任务&body=日期: 20240516%0D%0A序号: 1%0D%0A手稿:../../draft/2024/05/20240516093000.md%0D%0A---请勿修改邮件主题及以上内容 从下一行开始写您的想法---%0D%0A">[email]</a> | [top](#top) | [index](#index)
+<a id="20240516093000"></a>
+##  9:30~10:59
+起草标准模型2405
+
+- 重点是权利分配跟随无意识行为和有意识行为的边界变化。
+- 同时不能成为实际控制人压制其他成员的工具。还需要推演清楚再一起动笔。
+
+### 方案一
+
+- 执行部门：基本管理制度以外直接指挥或普通规章
+- 一级决策部门：人工制定基本管理制度
+- 二级决策部门：编写源代码完成一级决策部门的工作 -- 制定基本管理制度
+- 三级决策部门：编写源代码生成二级决策部门的工作 -- 编写源代码完成一级决策部门的工作
+- 如此递归。源代码包括元数据、以及必须的基础概念、定义、假设等。
+
+### 方案二
+
+- 任何职务行为都要提供依据。
+- 层级n：为层级n-1的行为提供默认依据。
+    - 当层级n-1的行为无法提供依据时使用；
+    - 通常解释为目标偏差，因为个人领域缺陷无法履行承诺；
+    - 默认依据会触发处罚条款。
+- 升级到层级n的程序，遵循“以行为代替语言”的原则。自愿公示个人领域中针对某无意识行为的解释和处罚，经过实践验证后，转化为共同体的默认依据，从而实现层级n人员的任免。
+
+- 还需要再斟酌，关键环节敲定后再统一动笔。
+
+---
+
+<a href="mailto:huangyg@mars22.com?subject=关于2024.05.16.[在draft+season+task metadata基础上设计总结功能]任务&body=日期: 20240516%0D%0A序号: 2%0D%0A手稿:../../draft/2024/05/20240516140000.md%0D%0A---请勿修改邮件主题及以上内容 从下一行开始写您的想法---%0D%0A">[email]</a> | [top](#top) | [index](#index)
+<a id="20240516140000"></a>
+## 14:00~14:29
+在draft+season+task metadata基础上设计总结功能
+
+- draft metadata：增加log、comment字段。
+- season metadata：增加comment字段。
+- task metadata：暂时不动，在season+draft的comment字段下增加task属性。
+    - 由代码提取，写到task metadata中。（or alltask？）
+    - 在生成task view时一起带上就行。
+- 总结不纳入日小结，另外生成月、季度的小结和计划，在做计划时汇总显示小结。
+
+---
+
+<a href="mailto:huangyg@mars22.com?subject=关于2024.05.16.[自动收发email。]任务&body=日期: 20240516%0D%0A序号: 3%0D%0A手稿:../../draft/2024/05/20240516143000.md%0D%0A---请勿修改邮件主题及以上内容 从下一行开始写您的想法---%0D%0A">[email]</a> | [top](#top) | [index](#index)
+<a id="20240516143000"></a>
+## 14:30~14:59
+自动收发email。
+
+- https://github.com/nodemailer/nodemailer
+- https://nodemailer.com/
+- https://emailengine.app
+- https://www.jianshu.com/p/6163113fae4f
+- https://developer.aliyun.com/article/927081
+- 在js.sample/IM 文件夹下添加测试文件 imap.js  可以读取阿里企业邮箱的内容。
+- 追加todo项
+    - '60': 用imap和mailparse自动处理并回复email
+      readme: |
+        - 在js.sample/IM/imap.js基础上继续增加功能。
+        - https://www.jianshu.com/p/6163113fae4f
+        - https://developer.aliyun.com/article/927081
+    - '60': 用EmailEngine搭建邮件服务器
+      readme: |
+        - https://emailengine.app
+    - '30': 用Nodemailer 自动处理并恢复email
+      readme: |
+        - https://nodemailer.com/
+        - https://github.com/nodemailer/nodemailer
+
+顺便修改ego/src/start.js,解决连续删除todo项时，按照老序号删错的问题。
+
+---
+
+<a href="mailto:huangyg@mars22.com?subject=关于2024.05.16.[github的actions,workflow,job脚本语法]任务&body=日期: 20240516%0D%0A序号: 4%0D%0A手稿:../../draft/2024/05/20240516160000.md%0D%0A---请勿修改邮件主题及以上内容 从下一行开始写您的想法---%0D%0A">[email]</a> | [top](#top) | [index](#index)
+<a id="20240516160000"></a>
+## 16:00~16:59
+github的actions,workflow,job脚本语法
+
+- https://docs.github.com/en/actions/security-guides/using-secrets-in-github-actions
+- 语法可以参考，甚至移植。但github的语法依赖大量环境设定，这部分很难移植。
+- PSMD的code部分，尽量使用js、REST方式定义，环境设定可以学习知识图谱之后定。

release/time/d.20240517.md

@@ -0,0 +1,22 @@
+# 2024.05.17.
+
+根据[ego模型时间接口](https://gitee.com/hyg/blog/blob/master/timeflow.md)，每天绑定特定模版：外勤。
+
+---
+明天如果绑定模版1可能安排以下任务：
+
+- 07:45	整理近期手稿 -ego[0]
+- 09:30	term metadata生成按修订层级排版的COM metadata。 -PSMD[1]
+- 14:00	YARRRML -learn[0]
+- 14:30	docker -learn[1]
+- 16:00	用imap和mailparse自动处理并回复email -js[0]
+
+---
+明天如果绑定模版2可能安排以下任务：
+
+- 07:45	term + COM matedata -> deploy metadata -> deploy view -PSMD[0]
+- 14:00	term metadata生成按修订层级排版的COM metadata。 -PSMD[1]
+- 16:00	整理近期手稿 -ego[0]
+
+---
+对任务排序的建议请点击这个链接<a href="mailto:huangyg@mars22.com?subject=关于2024.05.17.任务排序的建议&body=date: 20240517%0D%0Afile: ../../blog/release/time/d.20240517.md%0D%0A---请勿修改邮件主题及以上内容---%0D%0A">发送电子邮件</a>，日计划确定后会在本页面发布。

release/time/d.20240518.md

@@ -0,0 +1,132 @@
+# 2024.05.18.
+日小结  
+
+<a id="top"></a>
+根据[ego模型时间接口](https://gitee.com/hyg/blog/blob/master/timeflow.md)，今天绑定模版1。
+
+<a id="index"></a>
+- 07:45	[整理近期手稿](#20240518074500)  
+- 09:30	[term metadata生成按修订层级排版的COM metadata。](#20240518093000)  
+- 14:00	[YARRRML](#20240518140000)  
+- 14:30	[docker](#20240518143000)  
+- 16:00	[用imap和mailparse自动处理并回复email](#20240518160000)  
+
+---
+season stat:
+
+| task | alloc | sold | hold | todo |
+| --- | --- | --- | --- | --- |
+| total | 13275 | 10862 | 2413 | 2520 |
+| PSMD | 7000 | 5551 | 1449 | 375 |
+| learn | 1000 | 592 | 408 | 690 |
+| ego | 3000 | 2334 | 666 | 765 |
+| js | 1375 | 855 | 520 | 390 |
+| xuemen | 600 | 1136 | -536 | 210 |
+| raw | 300 | 364 | -64 | 90 |
+| infra | 0 | 30 | -30 | 0 |
+
+---
+
+waiting list:
+
+
+- 30分钟时间片：
+  - learn的第1号事项：寻找测试做得比较好的开源软件，作为学习单元划分和测试的实例。
+  - PSMD的第2号事项：PSMD委托合同的metadata
+  - js的第2号事项：继续学习promise api
+  - raw的第2号事项：检查etable递归过程是否累加amount字段而未检查unit字段的。
+
+- 60分钟时间片：
+  - js的第1号事项：自动接收恢复邮件。
+  - raw的第1号事项：根据过去数据给出15天内的建议。
+  - xuemen的第1号事项：整理kernel、ISU、JPU之间的关系，厘清概念。
+  - learn的第2号事项：nosql
+
+- 90分钟时间片：
+  - ego的第1号事项：整理近期手稿
+  - ego的第2号事项：代码实现，有互动的总结功能。
+  - learn的第4号事项：把PSMD的data、src部分升级到rdf，如果升级成功则作为范例。
+
+- 195分钟时间片：
+  - PSMD的第1号事项：term + COM matedata -> deploy metadata -> deploy view
+  - learn的第5号事项：rust入门
+
+---
+
+<a href="mailto:huangyg@mars22.com?subject=关于2024.05.18.[整理近期手稿]任务&body=日期: 20240518%0D%0A序号: 0%0D%0A手稿:../../draft/2024/05/20240518074500.md%0D%0A---请勿修改邮件主题及以上内容 从下一行开始写您的想法---%0D%0A">[email]</a> | [top](#top) | [index](#index)
+<a id="20240518074500"></a>
+## 7:45~8:44
+整理近期手稿
+
+受昨天外勤影响没有休息好，登记为0分钟，todo项回到waitinglist。
+
+---
+
+<a href="mailto:huangyg@mars22.com?subject=关于2024.05.18.[term metadata生成按修订层级排版的COM metadata。]任务&body=日期: 20240518%0D%0A序号: 1%0D%0A手稿:../../draft/2024/05/20240518093000.md%0D%0A---请勿修改邮件主题及以上内容 从下一行开始写您的想法---%0D%0A">[email]</a> | [top](#top) | [index](#index)
+<a id="20240518093000"></a>
+##  9:30~10:59
+term metadata生成按修订层级排版的COM metadata。
+
+- 在term.js增加termtoCOM参数
+- 增加termtoCOM() maketermrelation()
+    - 如果item有upgradeby：它所有子条款都有，本地定义都被覆盖；
+    - 如果item没有upgradeby：
+        - 如果item的upgradeby被map替换：使用被替换后的定义
+        - 如果没有被map替换：使用本地定义
+- 测试：node term termtoCOM 2e4f11cb
+    - 因为有upgradeby localid.localid的情况，走不通。
+    - 显示内容和id应该分两种upgradeby？否则其他功能维护起来太麻烦。
+
+- 顺便修复了ego\src\start.js的bug：删除已进入日计划的todoxiang时，seasonobj.todo[timeperiod.subject][j]应为seasonobj.todo[timeperiod.subject][j][timeperiod.amount]
+
+- 增加 todo项：
+- '30': 重新思考term metadata种的upgradeby，是否需要显示内容和id两种。
+
+---
+
+<a href="mailto:huangyg@mars22.com?subject=关于2024.05.18.[YARRRML]任务&body=日期: 20240518%0D%0A序号: 2%0D%0A手稿:../../draft/2024/05/20240518140000.md%0D%0A---请勿修改邮件主题及以上内容 从下一行开始写您的想法---%0D%0A">[email]</a> | [top](#top) | [index](#index)
+<a id="20240518140000"></a>
+## 14:00~14:29
+YARRRML
+
+- https://rml.io/yarrrml/
+- 是把现有数据源转化为RDF
+- 可能会在下个阶段，把各类metadata转化为RDF，然后对RDF检索而不是自己写代码。
+- 增加todo项：
+- '60': 开发YARRRML范例
+
+---
+
+<a href="mailto:huangyg@mars22.com?subject=关于2024.05.18.[docker]任务&body=日期: 20240518%0D%0A序号: 3%0D%0A手稿:../../draft/2024/05/20240518143000.md%0D%0A---请勿修改邮件主题及以上内容 从下一行开始写您的想法---%0D%0A">[email]</a> | [top](#top) | [index](#index)
+<a id="20240518143000"></a>
+## 14:30~14:59
+docker
+
+- 复习完。
+- 暂时还是git的后备方案，而且不能向后检索：从某文件的v1.0找到v2.0.（如果image名改变了）
+
+---
+
+<a href="mailto:huangyg@mars22.com?subject=关于2024.05.18.[用imap和mailparse自动处理并回复email]任务&body=日期: 20240518%0D%0A序号: 4%0D%0A手稿:../../draft/2024/05/20240518160000.md%0D%0A---请勿修改邮件主题及以上内容 从下一行开始写您的想法---%0D%0A">[email]</a> | [top](#top) | [index](#index)
+<a id="20240518160000"></a>
+## 16:00~16:59
+用imap和mailparse自动处理并回复email
+
+- 注释掉附件自动保存的语句，方便调试。
+- mailparser返回的正文html、textashtml都可以获得，附件的结构太复杂。
+- 追加todo项：
+    - '60': 自动接收恢复邮件。
+      readme: |
+        - 继续在js.sample/IM/imap.js基础上继续增加功能。
+        - 直接使用imap而不用mailparser：
+        - https://www.npmjs.com/package/node-imap
+        - https://www.jianshu.com/p/6163113fae4f
+        - https://developer.aliyun.com/article/927081
+        bind: 
+          - '60': 用EmailEngine搭建邮件服务器
+            readme: |
+              - https://emailengine.app
+          - '30': 用Nodemailer 自动处理并恢复email
+            readme: |
+              - https://nodemailer.com/
+              - https://github.com/nodemailer/nodemailer

release/time/d.20240519.md

@@ -0,0 +1,354 @@
+# 2024.05.19.
+日小结  
+
+<a id="top"></a>
+根据[ego模型时间接口](https://gitee.com/hyg/blog/blob/master/timeflow.md)，今天绑定模版1。
+
+<a id="index"></a>
+- 07:45	[自动接收恢复邮件。](#20240519074500)  
+- 09:30	[整理近期手稿](#20240519093000)  
+- 14:00	[寻找测试做得比较好的开源软件，作为学习单元划分和测试的实例。](#20240519140000)  
+- 14:30	[PSMD委托合同的metadata](#20240519143000)  
+- 16:00	[根据过去数据给出15天内的建议。](#20240519160000)  
+
+---
+season stat:
+
+| task | alloc | sold | hold | todo |
+| --- | --- | --- | --- | --- |
+| total | 13275 | 11152 | 2123 | 2730 |
+| PSMD | 7000 | 5581 | 1419 | 525 |
+| learn | 1000 | 622 | 378 | 660 |
+| ego | 3000 | 2424 | 576 | 915 |
+| js | 1375 | 915 | 460 | 390 |
+| xuemen | 600 | 1136 | -536 | 210 |
+| raw | 300 | 444 | -144 | 30 |
+| infra | 0 | 30 | -30 | 0 |
+
+---
+
+waiting list:
+
+
+- 30分钟时间片：
+  - raw的第1号事项：检查etable递归过程是否累加amount字段而未检查unit字段的。
+  - js的第2号事项：了解jami api
+  - PSMD的第3号事项：了解Rules as Code (RaC)，准备在metadata中增加code字段。
+  - PSMD的第4号事项：debug- D:\huangyg\git\PSMD\data\term.25c83dac.yaml interface字段混乱。
+
+- 60分钟时间片：
+  - PSMD的第1号事项：重新设计PSMD自助、互助、委托合同
+  - ego的第1号事项：整理近期手稿。
+  - js的第1号事项：用EmailEngine搭建邮件服务器
+  - learn的第1号事项：在util库进行单元测试，在实践中学习。
+
+- 90分钟时间片：
+  - ego的第3号事项：代码实现，有互动的总结功能。
+  - learn的第4号事项：把PSMD的data、src部分升级到rdf，如果升级成功则作为范例。
+
+- 195分钟时间片：
+  - PSMD的第2号事项：term + COM matedata -> deploy metadata -> deploy view
+  - learn的第5号事项：rust入门
+
+---
+
+<a href="mailto:huangyg@mars22.com?subject=关于2024.05.19.[自动接收恢复邮件。]任务&body=日期: 20240519%0D%0A序号: 0%0D%0A手稿:../../draft/2024/05/20240519074500.md%0D%0A---请勿修改邮件主题及以上内容 从下一行开始写您的想法---%0D%0A">[email]</a> | [top](#top) | [index](#index)
+<a id="20240519074500"></a>
+## 7:45~8:44
+自动接收恢复邮件。
+
+- 创建测试邮箱账号。在postmaster设置允许外域收发：smtp、pop3、imap。
+- 保密信息都写到config.js里
+- npm install imap
+- 创建.gitignore 文件
+```
+node_modules/
+/config.js
+/term.*.yaml
+```
+- https://www.npmjs.com/package/imap
+- npm install nodemailer
+- 用回mailparser保存附件，再用yamljs打开，可以正确回复。
+- 发送邮件成功。
+```
+D:\huangyg\git\js.sample\IM>node imap
+打开邮箱
+1完成
+所有邮件抓取完成!
+邮件头信息>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
+邮件主题: test and attachment
+发件人: "黄勇刚" <huangyg@xuemen.com>
+收件人: test@mars22.com
+邮件附件信息>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
+附件名称:term.2e4f11cb.yaml
+邮件内容信息>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
+邮件内容: undefined
+Email sent: 250 Data Ok: queued as freedom
+```
+
+---
+
+<a href="mailto:huangyg@mars22.com?subject=关于2024.05.19.[整理近期手稿]任务&body=日期: 20240519%0D%0A序号: 1%0D%0A手稿:../../draft/2024/05/20240519093000.md%0D%0A---请勿修改邮件主题及以上内容 从下一行开始写您的想法---%0D%0A">[email]</a> | [top](#top) | [index](#index)
+<a id="20240519093000"></a>
+##  9:30~10:59
+整理近期手稿
+
+### raw
+#### 1
+结合vat模型整理raw
+
+- vat2为vat1提供world model；
+- vat n为vat n-1提供world model；
+- “真实世界”的输入从底层vat开始，一路向浅层vat和意识传递。输出反方向。
+
+##### 评
+
+两个缸中之脑交流怎么破缸，可以放在这个模型下检验一下。
+
+#### 2
+个人领域信息管理的两个维度
+
+- 维度1: data -> knowledge -> view
+- 维度2: text -> law -> code
+- raw模型把资源time分配到各项目，产生三种data：
+    - (text,data): text.origin
+        - -> (text,knowledge): metadata or schema ,draft
+            - -> (law,data): law.origin
+            - -> (law,knowledge): lib or document
+                - -> (law,view): json or yaml paper 要约生效
+                    - -> (code,view): html+js or infra/tools
+                - ->  (code,data): js.sample
+        - ->  (code,data): js.sample
+    - (law,data): law.origin
+        - ->  (law,knowledge): lib or document
+    - (code,data): js.sample
+        - -> (code,knowledge): nodejs
+            - -> (code,view): html+js or infra/tools
+    - all git repos -> raw/time
+
+##### 评
+
+- 规划了时间资源向信息资产转化的路径
+- 根据两个维度划分了信息资产的类别
+- 目前实际情况比较简单：
+    - draft -> PSMD / ego git repos : /data -> src -> view
+- 有意识无意识的边界，在data-knowldge之间
+- vat和entity的边界，在schema、lib - paper之间
+
+### ego
+#### 1
+
+- container中是D
+- event输入container，输出action
+- event输入到contaiiner中的mux，各D的action经过filter成为container的action
+- model -deploy-> deployment
+    - model : fsm or event listener
+- deployment -modeling-> model
+- deployment - learn-> deploymenr
+- deployment -split->deployments
+    - deployments -joint-> dedployment
+    - joint: 
+        - person union
+        - protocol unoin
+        - product union
+        - project union
+- deployment -training-> D
+- Token -enable-> deployment
+
+##### 评
+
+- 忘记了D是什么，其他部分都很熟悉。
+
+#### 2
+
+- site is container
+- raw@site -grow-> new-being@container
+    - filter
+    - env
+    - tool
+        - sample -> law -> method -> tool
+        - law -> protocol
+    - reviewer
+
+##### 评
+
+- 无意识的raw存在于肉体site中
+- raw成长为有意识的new being（entity），可以不属于container中。
+- container具体由一组元素定义。
+
+#### 3 
+
+- raw 向container部署new being有三种接口
+    - grow
+    - joint
+    - spilit
+- 在升级或部署期间，event输入和action输出是持续的。
+- joint ->3P
+    - project
+    - product
+    - protocol
+- model + deploy -> cod -output->3P
+- protocol -> model + deploy
+- joint -> model + deploy
+- 3P -> raw
+
+##### 评
+
+- 前半部分raw部署newbing的三种接口，扩展了上一张手稿。
+- 后半部分的含义不是很清楚。
+- 3P扩展了P1、P2俱乐部的定义。
+
+#### 4
+
+- model -deploy-> deployment@container
+- event -> node@container -> ego + deployments -> action
+- ego <-互动,joint-> deployments
+
+追加连续的整理todo项，可以整理ego以外的手稿：
+    - '60': 整理近期手稿。
+      bind:
+        - '60': 整理近期手稿。
+          bind:
+            - '60': 整理近期手稿。
+              bind:
+                - '60': 整理近期手稿。
+                  bind:
+                    - '195': 在整理近期手稿之后，修订个人模型。
+
+---
+
+<a href="mailto:huangyg@mars22.com?subject=关于2024.05.19.[寻找测试做得比较好的开源软件，作为学习单元划分和测试的实例。]任务&body=日期: 20240519%0D%0A序号: 2%0D%0A手稿:../../draft/2024/05/20240519140000.md%0D%0A---请勿修改邮件主题及以上内容 从下一行开始写您的想法---%0D%0A">[email]</a> | [top](#top) | [index](#index)
+<a id="20240519140000"></a>
+## 14:00~14:29
+寻找测试做得比较好的开源软件，作为学习单元划分和测试的实例。
+
+- https://github.com/Vanessa219/vditor
+    - https://nodejs.cn/api/test.html
+- https://github.com/markedjs/marked
+    - 也是nodejs自带的 test
+
+就选这两个范例：
+    - '60': 学习 nodejs test框架
+      readme: |
+        - https://github.com/Vanessa219/vditor
+            - https://nodejs.cn/api/test.html
+        - https://github.com/markedjs/marked
+        bind:
+          - '90': 实际编写自己的测试范例
+
+---
+
+<a href="mailto:huangyg@mars22.com?subject=关于2024.05.19.[PSMD委托合同的metadata]任务&body=日期: 20240519%0D%0A序号: 3%0D%0A手稿:../../draft/2024/05/20240519143000.md%0D%0A---请勿修改邮件主题及以上内容 从下一行开始写您的想法---%0D%0A">[email]</a> | [top](#top) | [index](#index)
+<a id="20240519143000"></a>
+## 14:30~14:59
+PSMD委托合同的metadata
+
+- 旧合同：https://github.com/xuemen/PSMD/blob/master/%E5%B7%A5%E4%BD%9C%E8%AE%A1%E5%88%92%E5%8F%8A%E9%A2%84%E7%AE%97%E6%96%B9%E6%A1%88.md
+- 自助、互助、委托三种模式
+- 自助完全开放、无前提、无考核、免费
+- 互助有前提、有考核、无收支
+    - 已经穷尽自助模式下方法和工具
+    - 自动触发的互审合同
+- 委托有前提、有考核、有收支
+    - 受托的工作成果转化为自助、互助的工具
+    - 委托合同
+- 新合同
+    - 无意识行为的识别和分析
+    - 无意识行为转化为有意识行为的范例
+    - 有意识行为的分立、合并
+- 个人委托：新合同
+- 共同体委托：新合同+
+    - 成员行为的分立、合并
+
+- 自动化服务
+    - 个人尽量使用自动化服务
+    - 共同体尽量在同行业范围内搭建自动服务
+    - 建立档案和收入模式
+- 人工服务
+    - 共同体在每个行业的前几个委托
+    - 建模、部署和金融功能结合
+
+- 追加todo项：
+    - '60': 重新设计PSMD自助、互助、委托合同
+      readme: |
+        - 20240519 14:30 draft
+      bind:
+        - PSMD新合同的metadata
+
+---
+
+<a href="mailto:huangyg@mars22.com?subject=关于2024.05.19.[根据过去数据给出15天内的建议。]任务&body=日期: 20240519%0D%0A序号: 4%0D%0A手稿:../../draft/2024/05/20240519160000.md%0D%0A---请勿修改邮件主题及以上内容 从下一行开始写您的想法---%0D%0A">[email]</a> | [top](#top) | [index](#index)
+<a id="20240519160000"></a>
+## 16:00~16:59
+根据过去数据给出15天内的建议。
+
+- 增加新参数 plan mode: "node raw plan 15"
+- 新函数 function makeplan(long) ，列出过去各年同一时间段最常吃的食材排序。
+- 执行结果：
+```
+D:\huangyg\git\raw>node raw plan 10
+makeplan() > history: 20230520 ~ 20230530
+血麦片 24.05 21
+低钠盐 1.31 21
+花青素杂粮 19.62 13
+脱脂奶粉 11.96 13
+黑青稞 20.83 12
+灰枣 26.71 12
+奶粉 16.25 12
+绿豆 10 11
+亚麻籽 5 11
+麦胚芽 6 11
+大米 51.82 11
+小分子肽粉 3 10
+枸杞 5 9
+百香果 70.28 9
+胡柚 221.38 8
+卤水豆腐 71.44 8
+杏鲍菇 97.79 7
+西兰花 119.57 7
+鸡蛋 41.93 7
+鲜味王 0.55 6
+油菜 131 5
+蛋饺 54.3 5
+娃娃菜 151.5 5
+油 1 5
+橙 165 4
+可可粉 4 4
+后腿腊肉 21.75 4
+怀山药赤小豆薏米粉 30.75 4
+里脊 47.63 4
+中食达照烧鸡腿排 110.5 3
+荞麦面 74.67 3
+方便面 62.67 3
+黄瓜 212.17 3
+快菜 152.67 3
+生菜 53.25 2
+菊粉 9 2
+菜心 170 2
+小白菜 191.75 2
+木耳 12.5 2
+土豆 166.25 2
+...
+makeplan() > history: 20150520 ~ 20150530
+麦胚芽 20 11
+杂粮粥 67.78 9
+海鸭蛋 60 8
+猪肉 81.25 8
+玉米 167.14 7
+豇豆 150 6
+番石榴 93.33 6
+馒头 63.33 6
+绿豆 24 5
+麦片 52.5 4
+奶粉 28 4
+包子（猪肉白菜） 113.33 3
+西兰花 166.67 3
+梅花肉 87.5 2
+南瓜 205 2
+包子（肉三鲜） 150 2
+香蕉 225 2
+白菜 150 2
+西瓜 650 2
+圣女果 120 1
+米饭 75 1
+```

release/time/d.20240520.md

@@ -0,0 +1,205 @@
+# 2024.05.20.
+日小结  
+
+<a id="top"></a>
+根据[ego模型时间接口](https://gitee.com/hyg/blog/blob/master/timeflow.md)，今天绑定模版2。
+
+<a id="index"></a>
+- 07:45	[整理近期手稿。](#20240520074500)  
+- 14:00	[设计新版个人模型的基础定义](#20240520140000)  
+- 16:00	[重新设计PSMD自助、互助、委托合同](#20240520160000)  
+
+---
+season stat:
+
+| task | alloc | sold | hold | todo |
+| --- | --- | --- | --- | --- |
+| total | 13275 | 11497 | 1778 | 2523 |
+| PSMD | 7000 | 5641 | 1359 | 648 |
+| learn | 1000 | 622 | 378 | 660 |
+| ego | 3000 | 2709 | 291 | 585 |
+| js | 1375 | 915 | 460 | 390 |
+| xuemen | 600 | 1136 | -536 | 210 |
+| raw | 300 | 444 | -144 | 30 |
+| infra | 0 | 30 | -30 | 0 |
+
+---
+
+waiting list:
+
+
+- 30分钟时间片：
+  - raw的第1号事项：检查etable递归过程是否累加amount字段而未检查unit字段的。
+  - js的第2号事项：了解jami api
+  - PSMD的第4号事项：了解Rules as Code (RaC)，准备在metadata中增加code字段。
+  - js的第4号事项：继续学习promise api
+
+- 60分钟时间片：
+  - js的第1号事项：用EmailEngine搭建邮件服务器
+  - learn的第1号事项：在util库进行单元测试，在实践中学习。
+  - xuemen的第1号事项：整理kernel、ISU、JPU之间的关系，厘清概念。
+  - PSMD的第2号事项：PSMD新合同的metadata
+
+- 90分钟时间片：
+  - PSMD的第1号事项：设计几种新版合同的雏形，实际测试观察接受程度。
+  - learn的第4号事项：把PSMD的data、src部分升级到rdf，如果升级成功则作为范例。
+
+- 195分钟时间片：
+  - ego的第1号事项：在整理近期手稿之后，修订个人模型。
+  - PSMD的第3号事项：term + COM matedata -> deploy metadata -> deploy view
+  - learn的第5号事项：rust入门
+
+---
+
+<a href="mailto:huangyg@mars22.com?subject=关于2024.05.20.[整理近期手稿。]任务&body=日期: 20240520%0D%0A序号: 0%0D%0A手稿:../../draft/2024/05/20240520074500.md%0D%0A---请勿修改邮件主题及以上内容 从下一行开始写您的想法---%0D%0A">[email]</a> | [top](#top) | [index](#index)
+<a id="20240520074500"></a>
+## 7:45~10:59
+整理近期手稿。
+
+- 个人模型已经是全局的瓶颈：
+    - 个人模型中嵌入共同体booting的起步机制
+    - 个人模型接收共同体的观察分析、公示过程
+    - 个人模型是智能设备模型的起点
+- 工作次序是先完成新版个人模型，再完成新版共同体模型，目前个人模型进度滞后。
+
+### ego
+#### 1
+
+- 容器分为brain、mechine、nodes三级。
+    - nodes分为container、d-container两级。
+- 容器分为public、private两部分。
+- 容器event输入、action输出。
+    - action record由private部分review。
+    - review后决定从model库选择模型deploy进入public部分。
+        - 经过实践后从public部分提炼模型进入model库。
+        - brain.public 经过实践后从public部分deploy到mechine
+
+##### 评
+
+- 未定义mechine与nodes之间的关系，应该是私有mechine和公用mechine的关系。
+- 比较明确定义了逐级提高的过程。
+
+#### 2
+
+- 旧脑raw@body接收event输入，产生body action。
+- body action作为各级event listener的输入
+- event输入经过各级encoder，产生infor action，作为各级event listner的输入
+- 各级meta元认知不断改造各级event listner
+
+##### 评
+
+- 旧脑和皮层的协作关系
+- 部分箭头关系不准确，可能原意是反向的。
+- 皮层的event listner并不能真正接收外界信息，只能在模拟环境中接收经过encode的模拟event。
+- 皮层的event listner并不能真正产生对外操作，只能在模拟环境中产生infor action，让后经过decode输出给body，然后选择其中一个对外输出。
+
+#### 3
+
+- 外部事件由概率分布定义
+- 经过感觉器官后，感觉到概率分布
+- 在brain的认知中，坍缩到单一情况
+    - brain是广义的，包含所有参与认知的器官
+    - brain从感觉器官之前、之后分别得到输入，然后产生认知
+
+##### 评
+
+- 描述了对外界认识从概率分布坍缩的过程
+- 划分了感觉器官和认知器官
+    - 感觉器官输入概率分布，输出概率分布：分布可能不同，但信息还是全面的。
+    - 认知器官输入概率分布，输出单一概率，为下一层级认知器官提供简化的模拟环境。
+        - 通常还要把下一层级的简化输出重新decoder。
+
+#### 4
+ego | joint
+
+- entity分为listener、deamon两部分
+- event输入到listner，产生多种action
+- 多种actiob经过filter产生最终唯一的action
+- deamon观察listener，控制filter
+- 未来的权力部门付钱，表决的动机与立场。
+- 过程参与者的选项 <- 决心不同，差异化权利
+
+##### 评
+
+- 定义了多个entity joint成一个的机制
+- 定义了未来的权力部门约束今天决策部门的机制，可能是chain模型的原始手稿。
+
+---
+
+- ego类手稿整理完了，基本确定新版模型：
+    - ego是以人体为容器的entity模型。
+    - ego有标准的deamon、spilit、joint。
+- entity分为public、private两部分；
+    - public分为自然语言、法律语言、数学语言三类。
+    - 只对特定名单public，对名单外是private，每个entity视角还是只有两类。
+- deamon负责分析action，提炼为有意识的行为部署到public部分。
+    - deamon可以运行在private，也可以在public。
+    - deamon可以接收外界的观察分析结果
+    - deamon可以使用外界的标准模型（模型库）直接部署。
+    - deamon可以把部署方案提炼为模型向外提交（模型库）。
+- spilit和joint协议一旦产生，兼容的协议下可以产生共同体。
+    - 共同体模型在联合范围内，对成员模型有观察、分析、转化的接口。
+    - 共同体模型在联合范围歪，根据成员模型可以提供观察、分析、转化信息。
+- 在下一次绑定模版2，可以动笔。
+
+---
+
+<a href="mailto:huangyg@mars22.com?subject=关于2024.05.20.[设计新版个人模型的基础定义]任务&body=日期: 20240520%0D%0A序号: 1%0D%0A手稿:../../draft/2024/05/20240520140000.md%0D%0A---请勿修改邮件主题及以上内容 从下一行开始写您的想法---%0D%0A">[email]</a> | [top](#top) | [index](#index)
+<a id="20240520140000"></a>
+## 14:00~15:29
+设计新版个人模型的基础定义
+
+- 暂时不需要代码化的总结功能。
+- 需要时可以先在season metadata手工编辑，一段时间后再代码化。
+
+- 下面时间开始设计新版个人模型
+- 目前使用的vat分支就可以，不再创建新的分支。
+- thing是有输入输出的事物。
+- world是thing认知中信息、行为的对象。
+- vat是thing的信息、行为的真实对象，thing感知不到vat的存在。
+    - vat可以无限接近world，但不可能完全相等。
+- entity是有deamon的thing。
+    - deamon是认知entity自身行为的行为；
+    - deamon能接收其它entity对自身行为的认知（不一定认同）；
+    - deamon能向其它entity公开自己的认知结果；
+- ego是能构造vat并在其中复制自身行为的deamon。
+- raw是原始个人模型：
+    - 以人体为vat
+    - 基于原生deamon
+        - 依赖自身自制力改变自身行为
+        - 自身行为随自制力升级、降级
+
+---
+
+<a href="mailto:huangyg@mars22.com?subject=关于2024.05.20.[重新设计PSMD自助、互助、委托合同]任务&body=日期: 20240520%0D%0A序号: 2%0D%0A手稿:../../draft/2024/05/20240520160000.md%0D%0A---请勿修改邮件主题及以上内容 从下一行开始写您的想法---%0D%0A">[email]</a> | [top](#top) | [index](#index)
+<a id="20240520160000"></a>
+## 16:00~16:59
+重新设计PSMD自助、互助、委托合同
+
+### 基于新版个人模型
+
+- PSMD提供个人标准模型
+    - 可以方便地自定义个人模型
+    - 内置受助合同，可以自定义
+- PSMD提供标准共同体接口
+    - 可以方便地在个人模型基础上引入共同体模型的接口
+- PSMD提供互助、委托、受托标准合同
+    - 各种个人模型都可以发布标准合同、自定义合同
+- PSMD标准合同可以自行对接，包括自定义模型基础上的自定义合同。
+
+### 新版共同体模型
+
+- 新版共同体模型基于新版entity定义
+- 多个entity根据接口产生共同体
+- 共同体也可以发布互助、委托、受托标准痛和自定义合同
+
+### 自助合同
+
+- raw：无法解释的行为，阅读标准库的解释，自行转化。
+- ego：无法解释的行为，阅读标准库的解释，选择一种vat和公开行为部署。
+- 自定义模型：选择某种vat接受自动部署。
+
+- 暂时不要细化，追加todo项：
+    - '90': 设计几种新版合同的雏形，实际测试观察接受程度。
+      bind:
+        '90': 重新设计PSMD自助、互助、委托合同

release/time/d.20240521.md

@@ -0,0 +1,113 @@
+# 2024.05.21.
+日小结  
+
+<a id="top"></a>
+根据[ego模型时间接口](https://gitee.com/hyg/blog/blob/master/timeflow.md)，今天绑定模版2。
+
+<a id="index"></a>
+- 07:45	[在整理近期手稿之后，修订个人模型。](#20240521074500)  
+- 14:00	[设计几种新版合同的雏形，实际测试观察接受程度。](#20240521140000)  
+- 16:00	[用EmailEngine搭建邮件服务器](#20240521160000)  
+
+---
+season stat:
+
+| task | alloc | sold | hold | todo |
+| --- | --- | --- | --- | --- |
+| total | 13275 | 11842 | 1433 | 2310 |
+| PSMD | 7000 | 5731 | 1269 | 495 |
+| learn | 1000 | 622 | 378 | 660 |
+| ego | 3000 | 2904 | 96 | 585 |
+| js | 1375 | 975 | 400 | 330 |
+| xuemen | 600 | 1136 | -536 | 210 |
+| raw | 300 | 444 | -144 | 30 |
+| infra | 0 | 30 | -30 | 0 |
+
+---
+
+waiting list:
+
+
+- 30分钟时间片：
+  - js的第1号事项：了解jami api
+  - raw的第1号事项：检查etable递归过程是否累加amount字段而未检查unit字段的。
+  - js的第3号事项：继续学习promise api
+  - PSMD的第4号事项：了解Rules as Code (RaC)，准备在metadata中增加code字段。
+
+- 60分钟时间片：
+  - learn的第1号事项：在util库进行单元测试，在实践中学习。
+  - xuemen的第1号事项：整理kernel、ISU、JPU之间的关系，厘清概念。
+  - PSMD的第2号事项：PSMD新合同的metadata
+  - js的第2号事项：学习 nodejs test框架
+
+- 90分钟时间片：
+  - PSMD的第1号事项：重新设计PSMD自助、互助、委托合同
+  - learn的第4号事项：把PSMD的data、src部分升级到rdf，如果升级成功则作为范例。
+
+- 195分钟时间片：
+  - ego的第1号事项：新版个人模型
+  - PSMD的第3号事项：term + COM matedata -> deploy metadata -> deploy view
+  - learn的第5号事项：rust入门
+
+---
+
+<a href="mailto:huangyg@mars22.com?subject=关于2024.05.21.[在整理近期手稿之后，修订个人模型。]任务&body=日期: 20240521%0D%0A序号: 0%0D%0A手稿:../../draft/2024/05/20240521074500.md%0D%0A---请勿修改邮件主题及以上内容 从下一行开始写您的想法---%0D%0A">[email]</a> | [top](#top) | [index](#index)
+<a id="20240521074500"></a>
+## 7:45~10:59
+在整理近期手稿之后，修订个人模型。
+
+- 再熟悉一下知识图谱的术语。
+    - https://www.ibm.com/topics/knowledge-graph
+    - https://dl.acm.org/doi/10.1145/3447772
+    - https://www.w3.org/OWL/
+    - 适可而止，就算术语重复也继续向前走。
+- 基于昨天的基础定义，动笔升级个人模型，并嵌入共同体接口。
+    - 必要时，对浅层主体隐藏深层术语和知识，只暴露浅层所需要的概念。
+    - 只明确这一层需要的实践，再根据实践记录引入下一层级。
+
+- 继续追加todo项：
+- '195': 新版个人模型
+
+---
+
+<a href="mailto:huangyg@mars22.com?subject=关于2024.05.21.[设计几种新版合同的雏形，实际测试观察接受程度。]任务&body=日期: 20240521%0D%0A序号: 1%0D%0A手稿:../../draft/2024/05/20240521140000.md%0D%0A---请勿修改邮件主题及以上内容 从下一行开始写您的想法---%0D%0A">[email]</a> | [top](#top) | [index](#index)
+<a id="20240521140000"></a>
+## 14:00~15:29
+设计几种新版合同的雏形，实际测试观察接受程度。
+
+- 再等等个人模型定稿。
+
+---
+
+<a href="mailto:huangyg@mars22.com?subject=关于2024.05.21.[用EmailEngine搭建邮件服务器]任务&body=日期: 20240521%0D%0A序号: 2%0D%0A手稿:../../draft/2024/05/20240521160000.md%0D%0A---请勿修改邮件主题及以上内容 从下一行开始写您的想法---%0D%0A">[email]</a> | [top](#top) | [index](#index)
+<a id="20240521160000"></a>
+## 16:00~16:59
+用EmailEngine搭建邮件服务器
+
+```
+sudo apt install docker.io docker-compose
+sudo apt install lsb-release curl gpg
+curl -fsSL https://packages.redis.io/gpg | sudo gpg --dearmor -o /usr/share/keyrings/redis-archive-keyring.gpg
+echo "deb [signed-by=/usr/share/keyrings/redis-archive-keyring.gpg] https://packages.redis.io/deb $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/redis.list
+sudo apt-get update
+sudo apt-get install redis
+redis-server
+redis-cli
+127.0.0.1:6379> ping
+PONG
+127.0.0.1:6379> exit
+sudo usermod -aG docker huangyg
+sudo docker run -d --name redis-stack-server -p 6379:6379 redis/redis-stack-server:latest
+sudo docker pull postalsys/emailengine:v2
+sudo docker run -p 3000:3000 --env EENGINE_REDIS="redis://127.0.0.1:6379/7" postalsys/emailengine:v2
+
+{"level":30,"time":1716282054796,"pid":7,"hostname":"e81ea8cc1ad4","msg":"Starting EmailEngine","version":"2.41.4","node":"20.13.1","uvThreadpoolSize":4,"workersImap":4,"workersWebhooks":1,"workersSubmission":1}
+============================================================================================================
+Failed to establish connection to Redis using "redis://127.0.0.1:6379"
+Can not connect to the database. Redis might not be running. Are you using correct hostname and port values?
+
+To run EmailEngine provide valid Redis configuration
+  $ node server.js --dbs.redis="redis://username:password@1.2.3.4:6379/0"
+```
+
+没有成功，因为不在关键路径上，不再追加时间。

release/time/d.20240522.md

@@ -0,0 +1,145 @@
+# 2024.05.22.
+日小结  
+
+<a id="top"></a>
+根据[ego模型时间接口](https://gitee.com/hyg/blog/blob/master/timeflow.md)，今天绑定模版3，使用模版2的时间表。
+
+<a id="index"></a>
+- 07:45	[新版个人模型](#20240522074500)  
+- 14:00	[重新设计PSMD自助、互助、委托合同](#20240522140000)  
+- 16:00	[在util库进行单元测试，在实践中学习。](#20240522160000)  
+
+---
+season stat:
+
+| task | alloc | sold | hold | todo |
+| --- | --- | --- | --- | --- |
+| total | 13275 | 12202 | 1073 | 2445 |
+| PSMD | 7000 | 5851 | 1149 | 495 |
+| learn | 1000 | 667 | 333 | 600 |
+| ego | 3000 | 3099 | -99 | 780 |
+| js | 1375 | 975 | 400 | 330 |
+| xuemen | 600 | 1136 | -536 | 210 |
+| raw | 300 | 444 | -144 | 30 |
+| infra | 0 | 30 | -30 | 0 |
+
+---
+
+waiting list:
+
+
+- 30分钟时间片：
+  - js的第1号事项：了解jami api
+  - raw的第1号事项：检查etable递归过程是否累加amount字段而未检查unit字段的。
+  - PSMD的第3号事项：了解Rules as Code (RaC)，准备在metadata中增加code字段。
+  - js的第3号事项：继续学习promise api
+
+- 60分钟时间片：
+  - learn的第1号事项：nosql
+  - xuemen的第1号事项：整理kernel、ISU、JPU之间的关系，厘清概念。
+  - js的第2号事项：学习 nodejs test框架
+  - learn的第2号事项：开发YARRRML范例
+
+- 90分钟时间片：
+  - PSMD的第1号事项：PSMD新合同的view draft
+  - learn的第3号事项：把PSMD的data、src部分升级到rdf，如果升级成功则作为范例。
+
+- 195分钟时间片：
+  - ego的第1号事项：新版个人模型的view draft
+  - PSMD的第2号事项：term + COM matedata -> deploy metadata -> deploy view
+  - learn的第4号事项：rust入门
+
+---
+
+<a href="mailto:huangyg@mars22.com?subject=关于2024.05.22.[新版个人模型]任务&body=日期: 20240522%0D%0A序号: 0%0D%0A手稿:../../draft/2024/05/20240522074500.md%0D%0A---请勿修改邮件主题及以上内容 从下一行开始写您的想法---%0D%0A">[email]</a> | [top](#top) | [index](#index)
+<a id="20240522074500"></a>
+## 7:45~10:59
+新版个人模型
+
+- 在前面几天的基础上：
+    - 认识自己，解释自己的思想和行为，是最底层的；
+        - 如果没有这个特征，就是thing
+    - spilit、joint比ego更深层，raw模型也有这些接口，但是不能解释自己的行为、容易被植入、随时会毁约；
+    - 解释自己的行为，审议别人解释他自己的行为，是两项自定义标准，可以分别定义，也可以统一定义，但是显性的定义；
+    - 思想和行为都有层级，解释自己的行为，也有更深层解释“解释自己行为的行为”，如此类推；
+    - ego是raw创造并解释的，依然是脆弱不稳定的模型，ego创立并解释的spilit然后joint，然后由更稳定的joint deamon解释；
+
+- 休整时间再检查：个人和共同体、智能设备的共同基础模型
+- 共同体
+    - 共同体认识自己，解释自己的决策和行为；
+    - 共同体定义spilit、joint接口；
+    - 共同体有层级，多个主体可以joint成有层级的共同体；
+    - 共同体也可以显性地设立有创造vat职权的内部部门。
+- 智能设备
+    - 智能设备认识自己，解释自己的决策和行为；
+    - 智能设备deploy自己（的一部分），与其它设备合并（认知自己的部分）；
+    - 智能设备有层级；
+    - 智能设备创造容器，在其中观察自己的部署。
+
+- thing：有输入输出
+    - entity：认识自我，解释自己的思想和行为
+        - raw：contract（protocol）、spilit、joint
+            - ego：创造vat，部署经过解释的行为，进一步认识自我或交易。
+
+- 追加todo项：
+  - '195': 新版个人模型的view draft
+      bind:
+        - '195': 新版个人模型的metadata
+        - '90': PSMD新合同的view draft
+          bind:
+            - '60': PSMD新合同的metadata
+
+---
+
+<a href="mailto:huangyg@mars22.com?subject=关于2024.05.22.[重新设计PSMD自助、互助、委托合同]任务&body=日期: 20240522%0D%0A序号: 1%0D%0A手稿:../../draft/2024/05/20240522140000.md%0D%0A---请勿修改邮件主题及以上内容 从下一行开始写您的想法---%0D%0A">[email]</a> | [top](#top) | [index](#index)
+<a id="20240522140000"></a>
+## 14:00~15:29
+重新设计PSMD自助、互助、委托合同
+
+- 在新版个人模型基础上设计
+- thing：有输入输出
+    - entity：认识自我，解释自己的思想和行为
+        - 合同一：
+            - 提供入口，自行浏览。
+                - 基础扎实的介绍：protocol、spilit、joint
+            - 协助组织语言，与身边亲友交流。
+            - 协助组织数据，向陌生人发布。
+        - raw：contract（protocol）、spilit、joint
+            - 合同二
+                - 审议：protocol、spilit、joint接口
+                    - 引入其它COM的个人模型接口
+                    - 基础扎实的介绍vat概念
+                - 委托起草动议
+                - 委托主持议事
+                    - 筹备期boot
+                    - 初创期deploy
+            - ego：创造vat，部署经过解释的行为，进一步认识自我或交易。
+                - 合同三
+                    - 集结gathering
+                    - 互审
+
+---
+
+<a href="mailto:huangyg@mars22.com?subject=关于2024.05.22.[在util库进行单元测试，在实践中学习。]任务&body=日期: 20240522%0D%0A序号: 2%0D%0A手稿:../../draft/2024/05/20240522160000.md%0D%0A---请勿修改邮件主题及以上内容 从下一行开始写您的想法---%0D%0A">[email]</a> | [top](#top) | [index](#index)
+<a id="20240522160000"></a>
+## 16:00~16:59
+在util库进行单元测试，在实践中学习。
+
+- https://yunnysunny.github.io/nodebook/08_node_unit_test.html#_8-1-%E5%8D%95%E5%85%83%E6%B5%8B%E8%AF%95
+- D:\huangyg\git\ego\src\util.test.js
+- 执行结果：
+```
+D:\huangyg\git\ego\src>node util.test.js
+✔ make meta file id (1.3412ms)
+✔ get today str (0.7357ms)
+ℹ tests 2
+ℹ suites 0
+ℹ pass 2
+ℹ fail 0
+ℹ cancelled 0
+ℹ skipped 0
+ℹ todo 0
+ℹ duration_ms 9.1341
+```
+
+- 登记45分钟。余下时间补前面任务。

release/time/d.20240523.md

@@ -0,0 +1,119 @@
+# 2024.05.23.
+日小结  
+
+<a id="top"></a>
+根据[ego模型时间接口](https://gitee.com/hyg/blog/blob/master/timeflow.md)，今天绑定模版3，使用模版2的时间表。
+
+<a id="index"></a>
+- 07:45	[新版个人模型的view draft](#20240523074500)  
+- 14:00	[PSMD新合同的view draft](#20240523140000)  
+- 16:00	[nosql](#20240523160000)  
+
+---
+season stat:
+
+| task | alloc | sold | hold | todo |
+| --- | --- | --- | --- | --- |
+| total | 13275 | 12547 | 728 | 2505 |
+| PSMD | 7000 | 5941 | 1059 | 495 |
+| learn | 1000 | 727 | 273 | 660 |
+| ego | 3000 | 3294 | -294 | 780 |
+| js | 1375 | 975 | 400 | 330 |
+| xuemen | 600 | 1136 | -536 | 210 |
+| raw | 300 | 444 | -144 | 30 |
+| infra | 0 | 30 | -30 | 0 |
+
+---
+
+waiting list:
+
+
+- 30分钟时间片：
+  - js的第1号事项：了解jami api
+  - raw的第1号事项：检查etable递归过程是否累加amount字段而未检查unit字段的。
+  - learn的第2号事项：Document-Oriented数据库
+  - PSMD的第3号事项：了解Rules as Code (RaC)，准备在metadata中增加code字段。
+
+- 60分钟时间片：
+  - learn的第1号事项：knowledge graph数据库和查询语言
+  - xuemen的第1号事项：整理kernel、ISU、JPU之间的关系，厘清概念。
+  - js的第2号事项：学习 nodejs test框架
+  - ego的第2号事项：task之间结算体系设计。
+
+- 90分钟时间片：
+  - PSMD的第1号事项：PSMD新合同的view draft
+  - learn的第5号事项：把PSMD的data、src部分升级到rdf，如果升级成功则作为范例。
+
+- 195分钟时间片：
+  - ego的第1号事项：新版个人模型的view draft
+  - PSMD的第2号事项：term + COM matedata -> deploy metadata -> deploy view
+  - learn的第6号事项：rust入门
+
+---
+
+<a href="mailto:huangyg@mars22.com?subject=关于2024.05.23.[新版个人模型的view draft]任务&body=日期: 20240523%0D%0A序号: 0%0D%0A手稿:../../draft/2024/05/20240523074500.md%0D%0A---请勿修改邮件主题及以上内容 从下一行开始写您的想法---%0D%0A">[email]</a> | [top](#top) | [index](#index)
+<a id="20240523074500"></a>
+## 7:45~10:59
+新版个人模型的view draft
+
+- 根据昨天手稿整理 D:\huangyg\git\ego\README.md
+    - 要不要避开raw、ego这些旧词。
+    - entity与let's reconize可以合并。
+- 基本概念还在变动：
+    - 物体|thing: 与知识图谱的thing定义相同。
+    - 主体|entity: 具有mate行为的物体(thing)。
+        - meta: 认知自我，解释自己的思想和行为，察觉思想和行为中使用的知识（概念、定义、假设等等）。
+            - 可实践的知识，可以表现为生效的协议、要约。
+        - raw: entuity还没有认知的自身行为的集合。
+    - common: 具有protocol,spilit,joint三种基础行为的主体(entity)。
+        - protocol：附有条件的行为。
+            - 要约表示可实践的知识。
+        - spilit分立，一个entity分立成为多个entity。
+        - joint合并，多个entity合并产生一个entity。
+    - vat: 支持entity的思想和行为的知识（定义、概念、假设等等）的thing。
+    - ego: 通过创造vat、在vat中设立主体(entity)来认知的entity。
+    - 共同体|community：由多个主体joint合并而成的主体。
+
+- 休整时间继续整理思路，todo项回到waitinglist。
+
+---
+
+<a href="mailto:huangyg@mars22.com?subject=关于2024.05.23.[PSMD新合同的view draft]任务&body=日期: 20240523%0D%0A序号: 1%0D%0A手稿:../../draft/2024/05/20240523140000.md%0D%0A---请勿修改邮件主题及以上内容 从下一行开始写您的想法---%0D%0A">[email]</a> | [top](#top) | [index](#index)
+<a id="20240523140000"></a>
+## 14:00~15:29
+PSMD新合同的view draft
+
+- 自助查询、委托编写、互助审议：
+    - 一种行为的解释，及其使用的概念、定义、假设；
+    - 适合一种行为的分立、合并方案；
+    - 多种行为组合的应对。
+- 自助查询依赖entity的index
+
+---
+
+<a href="mailto:huangyg@mars22.com?subject=关于2024.05.23.[nosql]任务&body=日期: 20240523%0D%0A序号: 2%0D%0A手稿:../../draft/2024/05/20240523160000.md%0D%0A---请勿修改邮件主题及以上内容 从下一行开始写您的想法---%0D%0A">[email]</a> | [top](#top) | [index](#index)
+<a id="20240523160000"></a>
+## 16:00~16:59
+nosql
+
+- https://zhuanlan.zhihu.com/p/418281466
+    - NoSQL可以大体上分为4个种类：Key-value、Document-Oriented、Column-Family Databases以及 Graph-Oriented Databases。
+- create js.sample\nosql\redis.js
+- cli和js都正常set,get,del
+```
+D:\huangyg\git\js.sample\nosql>node redis
+set OK
+get huangyg
+del 1
+```
+
+- 追加learn todo项：
+    - '60': knowledge graph数据库和查询语言
+      readme: |
+        - Neo4J、Infinite Graph、OrientDB
+    - '30': Document-Oriented数据库
+      readme: |
+        -MongoDB、CouchDB、RavenDB
+    - '30': 列存储（Wide Column Store/Column-Family）数据库
+      readme: |
+        -Cassandra、HBase

release/time/d.20240524.md

@@ -0,0 +1,153 @@
+# 2024.05.24.
+日小结  
+
+<a id="top"></a>
+根据[ego模型时间接口](https://gitee.com/hyg/blog/blob/master/timeflow.md)，今天绑定模版3，使用模版2的时间表。
+
+<a id="index"></a>
+- 07:45	[新版个人模型的view draft](#20240524074500)  
+- 14:00	[PSMD新合同的view draft](#20240524140000)  
+- 16:00	[knowledge graph数据库和查询语言](#20240524160000)  
+
+---
+season stat:
+
+| task | alloc | sold | hold | todo |
+| --- | --- | --- | --- | --- |
+| total | 13275 | 12892 | 383 | 2310 |
+| PSMD | 7000 | 6031 | 969 | 405 |
+| learn | 1000 | 787 | 213 | 750 |
+| ego | 3000 | 3489 | -489 | 585 |
+| js | 1375 | 975 | 400 | 330 |
+| xuemen | 600 | 1136 | -536 | 210 |
+| raw | 300 | 444 | -144 | 30 |
+| infra | 0 | 30 | -30 | 0 |
+
+---
+
+waiting list:
+
+
+- 30分钟时间片：
+  - js的第1号事项：了解jami api
+  - raw的第1号事项：检查etable递归过程是否累加amount字段而未检查unit字段的。
+  - PSMD的第3号事项：了解Rules as Code (RaC)，准备在metadata中增加code字段。
+  - js的第3号事项：继续学习promise api
+
+- 60分钟时间片：
+  - PSMD的第1号事项：PSMD新合同的metadata
+  - xuemen的第1号事项：整理kernel、ISU、JPU之间的关系，厘清概念。
+  - js的第2号事项：学习 nodejs test框架
+  - learn的第2号事项：Ultipa
+
+- 90分钟时间片：
+  - learn的第1号事项：cypher and neo4j arua
+  - learn的第6号事项：把PSMD的data、src部分升级到rdf，如果升级成功则作为范例。
+
+- 195分钟时间片：
+  - ego的第1号事项：新版个人模型的metadata
+  - PSMD的第2号事项：term + COM matedata -> deploy metadata -> deploy view
+  - learn的第7号事项：rust入门
+
+---
+
+<a href="mailto:huangyg@mars22.com?subject=关于2024.05.24.[新版个人模型的view draft]任务&body=日期: 20240524%0D%0A序号: 0%0D%0A手稿:../../draft/2024/05/20240524074500.md%0D%0A---请勿修改邮件主题及以上内容 从下一行开始写您的想法---%0D%0A">[email]</a> | [top](#top) | [index](#index)
+<a id="20240524074500"></a>
+## 7:45~10:59
+新版个人模型的view draft
+
+- 再次重写基本概念
+    - thing按照知识图谱的定义
+    - entity是有认知能力的thing
+        - 认知能力的定义是能描述思想和行为
+        - 认知能力包括对thing(含entity)、对自我
+            - raw是尚未认知的思想和行为的集合
+            - 已认知的根据内容单独命名
+        - 认知结果的默认表达方式是自然语言
+    - meta是元认知能力，定义是能描述思想和行为使用的知识
+        - 知识包括定义、假设、规律等等
+        - vat是一个entity的思想和行为使用的知识的集合
+    - protocol是认知结果的规范表达方式，包括法律语言和数学语言等
+        - 生效的protocol是可以实践的知识
+    - spilit是分立，一个entity分立成为多个entity
+    - joint是联合，多个entity合并成为一个entity
+        - 认知能力的联合
+        - 元认知能力的联合
+        - 一部分作为另一部分的vat，前者为后者的思想和行为提供知识
+    - ego是通过构造vat来进行元认知的entity
+    - club是互相认知的protocol
+        - P1 club:对思想和行为的认知
+        - P2 club: 元认知
+        - gathering是club组织线下互相认知，也是protocol
+            - P2 trust：委托作为主持人
+    - community是合作的protocol (不再是单一entity)
+        - 多层级commnity: 一部分entity作为另一部分的vat
+        - raw和ego是合作关系
+    - trust是委托的protocol
+        - P1 trust: 对思想和行为的认知
+        - P2 trust: 委托作为vat
+        - mirror trust: 作为并行的镜像，履行相同的职责
+- 比对前天昨天的版本
+- 比对旧版
+- 比对let‘X
+
+---
+
+<a href="mailto:huangyg@mars22.com?subject=关于2024.05.24.[PSMD新合同的view draft]任务&body=日期: 20240524%0D%0A序号: 1%0D%0A手稿:../../draft/2024/05/20240524140000.md%0D%0A---请勿修改邮件主题及以上内容 从下一行开始写您的想法---%0D%0A">[email]</a> | [top](#top) | [index](#index)
+<a id="20240524140000"></a>
+## 14:00~15:29
+PSMD新合同的view draft
+
+- 使用今天版本的个人模型：
+- club是互相认知的protocol
+        - P1 club:对思想和行为的认知
+        - P2 club: 元认知
+        - gathering是club组织线下互相认知，也是protocol
+                - P2 trust：委托作为主持人
+- trust是委托的protocol
+        - P1 trust: 对思想和行为的认知
+        - P2 trust: 委托作为vat
+        - mirror trust: 作为并行的镜像，履行相同的职责
+- joint是联合，多个entity合并成为一个entity
+        - 认知能力的联合
+        - 元认知能力的联合
+        - 一部分作为另一部分的vat，前者为后者的思想和行为提供知识
+- ego是通过构造vat来进行元认知的entity
+- 自助合同主要用于：
+        - ego构造vat
+- 互助合同是club protocol
+- 委托合同是trust protocol
+
+---
+
+<a href="mailto:huangyg@mars22.com?subject=关于2024.05.24.[knowledge graph数据库和查询语言]任务&body=日期: 20240524%0D%0A序号: 2%0D%0A手稿:../../draft/2024/05/20240524160000.md%0D%0A---请勿修改邮件主题及以上内容 从下一行开始写您的想法---%0D%0A">[email]</a> | [top](#top) | [index](#index)
+<a id="20240524160000"></a>
+## 16:00~16:59
+knowledge graph数据库和查询语言
+
+- D:\huangyg\git\draft\2024\04\20240425143000.md
+- https://neo4j.com/
+- https://neo4j.com/developer/cypher/
+- https://github.com/neo4j/neo4j-javascript-driver#readme
+- npm install neo4j-driver
+- 创建 D:\huangyg\git\js.sample\nosql\neo4j.js
+- 
+```
+MATCH (n) DETACH DELETE n
+
+CREATE (n:term {name:'入门目录202404151600-3',id:'4b12ac08',readme:'\n      - \"可行\"是指：\n        - 方案的内容完整、准确、无二义性，具备相关岗位普通资质的人员可以自行阅读、使用。\n        - 在独立的第三方实施，可以按预期的比率产生预期的效果。\n       - 注意判断：成员下意识地把自己的工作特殊化、隐蔽化。'})
+
+MERGE (index:term {id : '4b12ac08'}) RETURN index.name AS name'
+```
+```
+D:\huangyg\git\js.sample\nosql>node neo4j
+入门目录202404151600-3
+```
+
+-  登记84分钟，追加todo项：
+    - '90': cypher and neo4j arua
+      readme: |
+        - https://console.neo4j.io
+        - https://neo4j.com/docs/cypher-manual/current/syntax/
+        - https://zhuanlan.zhihu.com/p/88745411
+    - '60': Ultipa 

release/time/d.20240525.md

@@ -0,0 +1,102 @@
+# 2024.05.25.
+日小结  
+
+<a id="top"></a>
+根据[ego模型时间接口](https://gitee.com/hyg/blog/blob/master/timeflow.md)，今天绑定模版3，使用模版2的时间表。
+
+<a id="index"></a>
+- 07:45	[新版个人模型的metadata](#20240525074500)  
+- 14:00	[cypher and neo4j arua](#20240525140000)  
+- 16:00	[PSMD新合同的metadata](#20240525160000)  
+
+---
+season stat:
+
+| task | alloc | sold | hold | todo |
+| --- | --- | --- | --- | --- |
+| total | 13275 | 13237 | 38 | 2235 |
+| PSMD | 7000 | 6091 | 909 | 345 |
+| learn | 1000 | 877 | 123 | 690 |
+| ego | 3000 | 3684 | -684 | 570 |
+| js | 1375 | 975 | 400 | 390 |
+| xuemen | 600 | 1136 | -536 | 210 |
+| raw | 300 | 444 | -144 | 30 |
+| infra | 0 | 30 | -30 | 0 |
+
+---
+
+waiting list:
+
+
+- 30分钟时间片：
+  - js的第1号事项：quick-yaml.db
+  - learn的第1号事项：Learn the basics https://console.neo4j.io
+  - raw的第1号事项：检查etable递归过程是否累加amount字段而未检查unit字段的。
+  - PSMD的第2号事项：了解Rules as Code (RaC)，准备在metadata中增加code字段。
+
+- 60分钟时间片：
+  - xuemen的第1号事项：整理kernel、ISU、JPU之间的关系，厘清概念。
+  - learn的第2号事项：Ultipa
+  - ego的第2号事项：task之间结算体系设计。
+  - ego的第3号事项：在season metadata中实现浮动时间表，修改日计划功能。
+
+- 90分钟时间片：
+  - ego的第1号事项：新版个人模型
+  - learn的第6号事项：把PSMD的data、src部分升级到rdf，如果升级成功则作为范例。
+
+- 195分钟时间片：
+  - PSMD的第1号事项：term + COM matedata -> deploy metadata -> deploy view
+  - learn的第7号事项：rust入门
+
+---
+
+<a href="mailto:huangyg@mars22.com?subject=关于2024.05.25.[新版个人模型的metadata]任务&body=日期: 20240525%0D%0A序号: 0%0D%0A手稿:../../draft/2024/05/20240525074500.md%0D%0A---请勿修改邮件主题及以上内容 从下一行开始写您的想法---%0D%0A">[email]</a> | [top](#top) | [index](#index)
+<a id="20240525074500"></a>
+## 7:45~10:59
+新版个人模型的metadata
+
+- 在昨天基本定义基础上微调：
+    - joint合并是多个entity合并为一个entity：community
+    - protocol可以使多个entity之间产生一个entity内部某个时刻的合作关系，差异在于：
+        - term双方不同，protocol是各个旧entity之间，joint是各个旧entity作为各member与新entity之间；
+            - 各member如果使用外部vat（比如身体、硬件），还会有交易；
+        - term的修订权不同；
+        - 对合作范围内的思想和行为的描述不同，joint规定了统一的描述，protocol不一定有；
+        - 如果涉及meta，joint规定了统一的meta，protocol不一定有；
+    - meta和vat的关系还没有敲定
+        - meta是认知思想和行为使用的知识，偏重于现实
+        - vat是为思想和行为提供知识，偏重于设想
+            - vat是通过改变使用的知识，来改变思想和行为
+        - 是否要为meta、vat增加明确的概念，就像认知能力区分thing->entity一样，继续在entity之上增加概念？
+- 再次放在三种形式自然人、共同体、智能设备检查。
+- 再次比对旧版、比对let‘X。
+- 放在物理学的模型中检查。
+
+---
+
+<a href="mailto:huangyg@mars22.com?subject=关于2024.05.25.[cypher and neo4j arua]任务&body=日期: 20240525%0D%0A序号: 1%0D%0A手稿:../../draft/2024/05/20240525140000.md%0D%0A---请勿修改邮件主题及以上内容 从下一行开始写您的想法---%0D%0A">[email]</a> | [top](#top) | [index](#index)
+<a id="20240525140000"></a>
+## 14:00~15:29
+cypher and neo4j arua
+
+- 结合Galaxybase 的文章把语法学习完： https://zhuanlan.zhihu.com/p/398323729
+- neo4k的教程，基础概念更深入，还没有对比Galaxybase的语法有什么差异 ：https://neo4j.com/docs/cypher-manual/current/queries/concepts/
+- 嵌入式的、nodejs的数据库，找到有基于json、yaml的，还没有图数据库；
+- 嵌入式的，python的，neo4j可以。
+- 追加todo项：
+    - '30': Learn the basics https://console.neo4j.io 
+
+---
+
+<a href="mailto:huangyg@mars22.com?subject=关于2024.05.25.[PSMD新合同的metadata]任务&body=日期: 20240525%0D%0A序号: 2%0D%0A手稿:../../draft/2024/05/20240525160000.md%0D%0A---请勿修改邮件主题及以上内容 从下一行开始写您的想法---%0D%0A">[email]</a> | [top](#top) | [index](#index)
+<a id="20240525160000"></a>
+## 16:00~16:59
+PSMD新合同的metadata
+
+- 在昨天基础上微调：
+    - trust是委托的protocol
+        - P1 trust: 对思想和行为的认知
+        - P2 trust: 元认知
+        - vat truset: 提供vat
+        - mirror trust: 作为并行的镜像，履行相同的职责
+        - backup trust: 有问题没有决议的时候，提供动议

release/time/d.20240526.md

@@ -0,0 +1,150 @@
+# 2024.05.26.
+日小结  
+
+<a id="top"></a>
+根据[ego模型时间接口](https://gitee.com/hyg/blog/blob/master/timeflow.md)，今天绑定模版1。
+
+<a id="index"></a>
+- 07:45	[整理kernel、ISU、JPU之间的关系，厘清概念。](#20240526074500)  
+- 09:30	[新版个人模型](#20240526093000)  
+- 14:00	[quick-yaml.db](#20240526140000)  
+- 14:30	[Learn the basics https://console.neo4j.io](#20240526143000)  
+- 16:00	[Ultipa](#20240526160000)  
+
+---
+season stat:
+
+| task | alloc | sold | hold | todo |
+| --- | --- | --- | --- | --- |
+| total | 13275 | 13507 | -232 | 2340 |
+| PSMD | 7000 | 6091 | 909 | 495 |
+| learn | 1000 | 967 | 33 | 630 |
+| ego | 3000 | 3774 | -774 | 675 |
+| js | 1375 | 1005 | 370 | 360 |
+| xuemen | 600 | 1196 | -596 | 150 |
+| raw | 300 | 444 | -144 | 30 |
+| infra | 0 | 30 | -30 | 0 |
+
+---
+
+waiting list:
+
+
+- 30分钟时间片：
+  - js的第1号事项：https://github.com/levelgraph/levelgraph
+  - learn的第1号事项：Document-Oriented数据库
+  - raw的第1号事项：检查etable递归过程是否累加amount字段而未检查unit字段的。
+  - js的第2号事项：了解jami api
+
+- 60分钟时间片：
+  - PSMD的第2号事项：FSM的嵌入式db实现
+  - js的第3号事项：学习 nodejs test框架
+  - ego的第3号事项：task之间结算体系设计。
+  - learn的第4号事项：开发YARRRML范例
+
+- 90分钟时间片：
+  - PSMD的第1号事项：FSM的cypher实现
+  - xuemen的第1号事项：重新设计S2状态下的学门基本管理制度
+  - ego的第2号事项：新版个人模型的共同体接口
+  - learn的第5号事项：把PSMD的data、src部分升级到rdf，如果升级成功则作为范例。
+
+- 195分钟时间片：
+  - ego的第1号事项：新版个人模型和部署
+  - PSMD的第3号事项：term + COM matedata -> deploy metadata -> deploy view
+  - learn的第6号事项：rust入门
+
+---
+
+<a href="mailto:huangyg@mars22.com?subject=关于2024.05.26.[整理kernel、ISU、JPU之间的关系，厘清概念。]任务&body=日期: 20240526%0D%0A序号: 0%0D%0A手稿:../../draft/2024/05/20240526074500.md%0D%0A---请勿修改邮件主题及以上内容 从下一行开始写您的想法---%0D%0A">[email]</a> | [top](#top) | [index](#index)
+<a id="20240526074500"></a>
+## 7:45~8:44
+整理kernel、ISU、JPU之间的关系，厘清概念。
+
+- xuemen是基于公司法的传统企业，所有新概念、方案必须在国内法框架下，分别以股东、经理、产品经理等角色行使职权，主要瓶颈是：
+    - 股东会还使用纸质文件和签名，没有同意使用数字签名；
+    - 股东会还使用法律语言，没有同意使用代码作为工作语言（制定决议）；
+- kernel是股东会、监事会、董事会和经理的集合，按照公司法可以合并部分角色和职权，对外接口相对稳定，因此统一定义。
+- ISU是后台部门的集合。如果xuemen支撑新型共同体运行，ISU将作为国内法接口，是vat中法律语言的部分。
+- JPU是产品部门的集合。如果xuemen支撑新型共同体运行，JPU将作为PSMD接口，是vat中数学语言的部分。
+    - JPU对外部产品团队提供多种的权利分配规则，并以明文明账方式代运行其中公用部分；
+    - JPU为外部产品团队提供发行token的机制；
+        - 作为机制的原生功能，各团队在自愿前提下可以联合发行joint token，合并部分权利；
+    - JPU按行业分别积累具体规章，并提供法律语言、数学语言双版本供外部团队使用；
+    - JPU要谨慎地判断kernel决议和国内法的效力和效率，在遵守法规、保证响应速度的前提下尽可能容纳更多的高级人才（能够使用数学语言设立共同体），并支持他们进入各行业。无法容纳的事项（也就是kernel决议和国内法可以撤销的，响应速度跟不上的）放在外部。如果核心规则放在外部infra，则JPU成为分支机构之一，承接一定范围内的业务。
+- 按照新版个人模型：
+    - JPU+infra的定位是：
+        - 使用数学语言设立共同体的vat
+            - 筹备阶段boot protocol
+            - 运营阶段default、1609、chain、2405四种标准模型
+        - modeler的club
+            - 使用数学语言设立共同体的合规检查（针对不使用vat的共同体）
+        - deployer的club
+        - 部署在vat中所有cod联合发行joint token的管理者
+- PSMD提供纯数学语言的vat
+- xuemen和PSMD一同寻找股东会使用数字签名、数学语言的公司，提供ISU和JPU
+
+---
+
+<a href="mailto:huangyg@mars22.com?subject=关于2024.05.26.[新版个人模型]任务&body=日期: 20240526%0D%0A序号: 1%0D%0A手稿:../../draft/2024/05/20240526093000.md%0D%0A---请勿修改邮件主题及以上内容 从下一行开始写您的想法---%0D%0A">[email]</a> | [top](#top) | [index](#index)
+<a id="20240526093000"></a>
+##  9:30~10:59
+新版个人模型
+
+- 在前几天模块3期间基本定义再继续比对。
+- term的数据库实现还可以推进，保持view不变的话其它方向不等：
+    - cypher
+    - yaml db
+        - https://github.com/GodDown1V4/obsidian-yaml-database
+    - embedded db
+        - sqlite3
+        - https://github.com/typicode/lowdb
+        - https://github.com/JamesMGreene/nestdb
+        - https://www.npmjs.com/package/nano-sql
+- 在此期间增加几个todo项：
+    - '90': FSM的cypher实现
+    - '60': FSM的嵌入式db实现
+
+---
+
+<a href="mailto:huangyg@mars22.com?subject=关于2024.05.26.[quick-yaml.db]任务&body=日期: 20240526%0D%0A序号: 2%0D%0A手稿:../../draft/2024/05/20240526140000.md%0D%0A---请勿修改邮件主题及以上内容 从下一行开始写您的想法---%0D%0A">[email]</a> | [top](#top) | [index](#index)
+<a id="20240526140000"></a>
+## 14:00~14:29
+quick-yaml.db
+
+- npm install quick-yaml.db
+- npm install -g ts-node
+- 创建D:\huangyg\git\js.sample\nosql\quick-yaml.ts
+- D:\huangyg\git\js.sample\nosql\package.json 中添加 "ts-node": { "esm": true },
+- ts-node报错。
+
+---
+
+<a href="mailto:huangyg@mars22.com?subject=关于2024.05.26.[Learn the basics https://console.neo4j.io]任务&body=日期: 20240526%0D%0A序号: 3%0D%0A手稿:../../draft/2024/05/20240526143000.md%0D%0A---请勿修改邮件主题及以上内容 从下一行开始写您的想法---%0D%0A">[email]</a> | [top](#top) | [index](#index)
+<a id="20240526143000"></a>
+## 14:30~14:59
+Learn the basics https://console.neo4j.io
+
+- 学习了基本操作。
+- 增加todo项
+- '30': Query fundamentals https://console.neo4j.io
+
+---
+
+<a href="mailto:huangyg@mars22.com?subject=关于2024.05.26.[Ultipa]任务&body=日期: 20240526%0D%0A序号: 4%0D%0A手稿:../../draft/2024/05/20240526160000.md%0D%0A---请勿修改邮件主题及以上内容 从下一行开始写您的想法---%0D%0A">[email]</a> | [top](#top) | [index](#index)
+<a id="20240526160000"></a>
+## 16:00~16:59
+Ultipa
+
+- https://www.ultipa.cn
+    - 嬴图GQL https://www.ultipa.cn/document/ultipa-graph-query-language/introduction
+- tigergraph https://www.tigergraph.com.cn
+- GSQL：https://info.tigergraph.com/hubfs/Chinese/whitepaper/%E4%B8%8B%E8%BD%BDGSQL%E7%99%BD%E7%9A%AE%E4%B9%A6%E4%B8%80%E7%A7%8D%E7%B1%BBSQL%E7%9A%84%E5%9B%BE%E6%9F%A5%E8%AF%A2%E8%AF%AD%E8%A8%80.pdf
+- Gremlin vs Cypher vs nGQL https://cloud.tencent.com/developer/article/1594313
+- GQL：https://www.iso.org/standard/76120.html
+    - 更像是cypher的方言
+    - 预计neo4j的地位会更加稳固
+- RDF SPARQL
+    - https://www.gstore.cn
+    - https://db-engines.com/en/article/RDF+Stores
+    - https://db-engines.com/en/system/GraphDB%3BNeo4j
+- neo4j 和cypher的未来地位比ultipa、pdf和sparql更好，先选用它做PSMD的数据，留意新的挑战者。

release/time/d.20240527.md

@@ -0,0 +1,271 @@
+# 2024.05.27.
+日小结  
+
+<a id="top"></a>
+根据[ego模型时间接口](https://gitee.com/hyg/blog/blob/master/timeflow.md)，今天绑定模版2。
+
+<a id="index"></a>
+- 07:45	[新版个人模型和部署](#20240527074500)  
+- 14:00	[FSM的cypher实现](#20240527140000)  
+- 16:00	[FSM的嵌入式db实现](#20240527160000)  
+
+---
+season stat:
+
+| task | alloc | sold | hold | todo |
+| --- | --- | --- | --- | --- |
+| total | 13275 | 13852 | -577 | 2205 |
+| PSMD | 7000 | 6241 | 759 | 345 |
+| learn | 1000 | 967 | 33 | 690 |
+| ego | 3000 | 3969 | -969 | 600 |
+| js | 1375 | 1005 | 370 | 390 |
+| xuemen | 600 | 1196 | -596 | 150 |
+| raw | 300 | 444 | -144 | 30 |
+| infra | 0 | 30 | -30 | 0 |
+
+---
+
+waiting list:
+
+
+- 30分钟时间片：
+  - js的第1号事项：https://github.com/levelgraph/levelgraph
+  - learn的第1号事项：https://www.npmjs.com/package/jssm
+  - raw的第1号事项：检查etable递归过程是否累加amount字段而未检查unit字段的。
+  - PSMD的第2号事项：了解Rules as Code (RaC)，准备在metadata中增加code字段。
+
+- 60分钟时间片：
+  - ego的第1号事项：新版个人模型的view
+  - ego的第2号事项：task之间结算体系设计。
+  - js的第3号事项：学习 nodejs test框架
+  - ego的第3号事项：在season metadata中实现浮动时间表，修改日计划功能。
+
+- 90分钟时间片：
+  - xuemen的第1号事项：重新设计S2状态下的学门基本管理制度
+  - learn的第7号事项：把PSMD的data、src部分升级到rdf，如果升级成功则作为范例。
+
+- 195分钟时间片：
+  - PSMD的第1号事项：term + COM matedata -> deploy metadata -> deploy view
+  - learn的第8号事项：rust入门
+
+---
+
+<a href="mailto:huangyg@mars22.com?subject=关于2024.05.27.[新版个人模型和部署]任务&body=日期: 20240527%0D%0A序号: 0%0D%0A手稿:../../draft/2024/05/20240527074500.md%0D%0A---请勿修改邮件主题及以上内容 从下一行开始写您的想法---%0D%0A">[email]</a> | [top](#top) | [index](#index)
+<a id="20240527074500"></a>
+## 7:45~10:59
+新版个人模型和部署
+
+- meta和vat是一种还是两种protocol？
+    - 是两种。
+    - 以公司法分工为例，meta主要由董事会负责，vat主要由经理（+hr等）负责、董事监事支持。
+    - 基于纯数学语言的共同体，meta倾向于由短期或一次性角色完成，vat需要稳定的架构但一旦部署就不需要创新。
+- 再与“行动代替语言”对比，在个人领域孵化新规则再spilit、joint到共同体中，在新模型中怎么实现，能不能代替董事角色的旧定义？
+- protocol是附有条件的行为，还是多个entity的共同认知。
+    - 是多个entity的共同认知。
+    - 对推理和行为的描述，就包含附有条件的行为，将要发生的行为。
+- 思想、推理和行为要不要统一起来。
+- vat是protocol还是thing。
+    - 是protocol。
+    - 以protocol替换原有知识；
+    - 先有明确的知识，再有使用这些知识的推理和行为；
+    - 通过替换知识来改变推理和行为。
+
+- 基本概念清晰，可以真正动笔了：
+    - '60': 新版个人模型的view
+      bind:
+        - '90': 新版个人模型的共同体接口
+          bind:
+            - '60': 新版个人模型的metadata
+
+---
+
+<a href="mailto:huangyg@mars22.com?subject=关于2024.05.27.[FSM的cypher实现]任务&body=日期: 20240527%0D%0A序号: 1%0D%0A手稿:../../draft/2024/05/20240527140000.md%0D%0A---请勿修改邮件主题及以上内容 从下一行开始写您的想法---%0D%0A">[email]</a> | [top](#top) | [index](#index)
+<a id="20240527140000"></a>
+## 14:00~15:29
+FSM的cypher实现
+
+- 这是错误的创建语句
+```
+MATCH (n) DETACH DELETE n
+CREATE (:status {id:1}) -[:event{id:"a"}]-> (:status{id:2})
+CREATE (:status {id:2}) -[:event{id:"a"}]-> (:status{id:3})
+CREATE (:status {id:3}) -[:event{id:"a"}]-> (:status{id:4})
+CREATE (:status {id:4}) -[:event{id:"a"}]-> (:status{id:5})
+CREATE (:status {id:5}) -[:event{id:"a"}]-> (:status{id:1})
+CREATE (:status {id:1}) -[:event{id:"b"}]-> (:status{id:3})
+CREATE (:status {id:3}) -[:event{id:"b"}]-> (:status{id:5})
+CREATE (:status {id:5}) -[:event{id:"b"}]-> (:status{id:2})
+CREATE (:status {id:2}) -[:event{id:"b"}]-> (:status{id:4})
+CREATE (:status {id:4}) -[:event{id:"b"}]-> (:status{id:1})
+MATCH (:status{id:1})-[:event{id:"a"}]->(n:status) RETURN n.id
+
+```
+- 产生了许多同名的node，所以只能查询到一层关系。
+
+```
+MATCH (:status{id:1})-[r:event]-{1,5}(:status{id:4}) RETURN r
+1
+[{
+identity:1152931400211496981, 
+start:21, 
+end:22, 
+type:"event", 
+properties:{
+id:"b"
+}, 
+elementId:"5:ef4e8d1d-e643-41d1-b24c-a7dcb84ad6b4:1152931400211496981", 
+startNodeElementId:"4:ef4e8d1d-e643-41d1-b24c-a7dcb84ad6b4:21", 
+endNodeElementId:"4:ef4e8d1d-e643-41d1-b24c-a7dcb84ad6b4:22"
+}]
+```
+- 查询不到多层关系的path
+```
+MATCH p=shortestPath((:status{id:1})-[:event*1..5]->(:status{id:4})) RETURN p  
+No changes, no records
+```
+
+- 这是正确的创建语句
+```
+MATCH (n) DETACH DELETE n
+CREATE (s1:status {id:1}),(s2:status{id:2}),(s3:status{id:3}),(s4:status{id:4}),(s5:status{id:5})
+CREATE (s1)-[:event{id:"a"}]->(s2)
+CREATE (s2)-[:event{id:"a"}]->(s3)
+CREATE (s3)-[:event{id:"a"}]->(s4)
+CREATE (s4)-[:event{id:"a"}]->(s5)
+CREATE (s5)-[:event{id:"a"}]->(s1)
+CREATE (s1)-[:event{id:"b"}]->(s3)
+CREATE (s3)-[:event{id:"b"}]->(s5)
+CREATE (s5)-[:event{id:"b"}]->(s2)
+CREATE (s2)-[:event{id:"b"}]->(s4)
+CREATE (s4)-[:event{id:"b"}]->(s1)
+```
+
+```
+MATCH p=shortestPath((:status{id:1})-[:event*1..5]->(:status{id:4})) RETURN p  
+(:status {id: 1})-[:event {id: "a"}]->(:status {id: 2})-[:event {id: "b"}]->(:status {id: 4})
+```
+
+```
+MATCH (:status{id:1})-[r:event]-{1,5}(:status{id:4}) RETURN r
+[
+  {
+    identity: 6919790723059421554,
+    start: 4470,
+    end: 4466,
+    type: "event",
+    properties: {
+      id: "a"
+    },
+    elementId: "5:ef4e8d1d-e643-41d1-b24c-a7dcb84ad6b4:6919790723059421554",
+    startNodeElementId: "4:ef4e8d1d-e643-41d1-b24c-a7dcb84ad6b4:4470",
+    endNodeElementId: "4:ef4e8d1d-e643-41d1-b24c-a7dcb84ad6b4:4466"
+  },
+  {
+    identity: 1152931400211501429,
+    start: 4469,
+    end: 4470,
+    type: "event",
+    properties: {
+      id: "a"
+    },
+    elementId: "5:ef4e8d1d-e643-41d1-b24c-a7dcb84ad6b4:1152931400211501429",
+    startNodeElementId: "4:ef4e8d1d-e643-41d1-b24c-a7dcb84ad6b4:4469",
+    endNodeElementId: "4:ef4e8d1d-e643-41d1-b24c-a7dcb84ad6b4:4470"
+  }
+]
+```
+- neo4j aura还不稳定，以前测试导入的文件还在影响最近的语句。生产环境肯定不能用。
+
+---
+
+<a href="mailto:huangyg@mars22.com?subject=关于2024.05.27.[FSM的嵌入式db实现]任务&body=日期: 20240527%0D%0A序号: 2%0D%0A手稿:../../draft/2024/05/20240527160000.md%0D%0A---请勿修改邮件主题及以上内容 从下一行开始写您的想法---%0D%0A">[email]</a> | [top](#top) | [index](#index)
+<a id="20240527160000"></a>
+## 16:00~16:59
+FSM的嵌入式db实现
+
+-  https://github.com/typicode/lowdb
+-  https://www.npmjs.com/package/lowdb
+-  https://juejin.cn/post/7104222761031041055
+- D:\huangyg\git\js.sample\nosql\lowdb.js
+- npm install lowdb
+    - ESM(ESModule)
+    - add "type":"module" into D:\huangyg\git\js.sample\nosql\package.json
+    - D:\huangyg\git\js.sample\nosql\FSM.json
+```
+{
+    "init": "s1",
+    "current": "s1",
+    "status": {"s1":1,"s2":2,"s3":3,"s4":4,"s5":5},
+    "event": {"ea": "a","eb": "b"},
+    "relation": [
+        {"from":"s1","event":"ea","to":"s2"},
+        {"from":"s2","event":"ea","to":"s3"},
+        {"from":"s3","event":"ea","to":"s4"},
+        {"from":"s4","event":"ea","to":"s5"},
+        {"from":"s5","event":"ea","to":"s1"},
+        {"from":"s1","event":"eb","to":"s3"},
+        {"from":"s3","event":"eb","to":"s5"},
+        {"from":"s5","event":"eb","to":"s2"},
+        {"from":"s2","event":"eb","to":"s4"},
+        {"from":"s4","event":"eb","to":"s1"}
+        ]
+}
+```
+- 执行结果：
+```
+D:\huangyg\git\js.sample\nosql>node lowdb
+{
+  init: 's1',
+  current: 's1',
+  status: { s1: 1, s2: 2, s3: 3, s4: 4, s5: 5 },
+  event: { ea: 'a', eb: 'b' },
+  relation: [
+    { from: 's1', event: 'ea', to: 's2' },
+    { from: 's2', event: 'ea', to: 's3' },
+    { from: 's3', event: 'ea', to: 's4' },
+    { from: 's4', event: 'ea', to: 's5' },
+    { from: 's5', event: 'ea', to: 's1' },
+    { from: 's1', event: 'eb', to: 's3' },
+    { from: 's3', event: 'eb', to: 's5' },
+    { from: 's5', event: 'eb', to: 's2' },
+    { from: 's2', event: 'eb', to: 's4' },
+    { from: 's4', event: 'eb', to: 's1' }
+  ]
+}
+s2
+s3
+s4
+s5
+s1
+s3
+s5
+s2
+s4
+s1
+s3
+```
+- lawdb并没有方便的查询语句。
+- https://lodash.com/  用lodash语法方便一些，但也没有SQL、GQL、sypher这些好用。
+
+- https://github.com/jakesgordon/javascript-state-machine
+- npm install --save-dev javascript-state-machine
+- D:\huangyg\git\js.sample\nosql\FSM.js
+- delete "type": "module", from  D:\huangyg\git\js.sample\nosql\package.json
+- 执行结果满意：
+```
+D:\huangyg\git\js.sample\nosql>node FSM
+state: s1
+state: s2
+state: s3
+state: s4
+state: s5
+state: s1
+state: s3
+state: s5
+state: s2
+state: s4
+```
+
+- 再追加这几个范例：
+    - '30': https://www.npmjs.com/package/jssm
+    - '30': http://machina-js.org/

release/time/d.20240528.md

@@ -0,0 +1,137 @@
+# 2024.05.28.
+日小结  
+
+<a id="top"></a>
+根据[ego模型时间接口](https://gitee.com/hyg/blog/blob/master/timeflow.md)，今天绑定模版1。
+
+<a id="index"></a>
+- 07:45	[新版个人模型的view](#20240528074500)  
+- 09:30	[重新设计S2状态下的学门基本管理制度](#20240528093000)  
+- 14:00	[https://github.com/levelgraph/levelgraph](#20240528140000)  
+- 14:30	[https://www.npmjs.com/package/jssm](#20240528143000)  
+- 16:00	[task之间结算体系设计。](#20240528160000)  
+
+---
+season stat:
+
+| task | alloc | sold | hold | todo |
+| --- | --- | --- | --- | --- |
+| total | 13275 | 13977 | -702 | 2205 |
+| PSMD | 7000 | 6241 | 759 | 405 |
+| learn | 1000 | 987 | 13 | 660 |
+| ego | 3000 | 4029 | -1029 | 570 |
+| js | 1375 | 1050 | 325 | 360 |
+| xuemen | 600 | 1196 | -596 | 180 |
+| raw | 300 | 444 | -144 | 30 |
+| infra | 0 | 30 | -30 | 0 |
+
+---
+
+waiting list:
+
+
+- 30分钟时间片：
+  - js的第1号事项：了解jami api
+  - learn的第1号事项：http://machina-js.org/
+  - raw的第1号事项：检查etable递归过程是否累加amount字段而未检查unit字段的。
+  - xuemen的第1号事项：域名和接口整理
+
+- 60分钟时间片：
+  - PSMD的第1号事项：新版共同体模型和物理学
+  - js的第2号事项：学习 nodejs test框架
+  - ego的第2号事项：在season metadata中实现浮动时间表，修改日计划功能。
+  - xuemen的第3号事项：term.e6f0caec -> xuemen COD metadata-S2状态下的部门模型
+
+- 90分钟时间片：
+  - ego的第1号事项：新版个人模型的view
+  - xuemen的第2号事项：重新设计S2状态下的学门基本管理制度
+  - learn的第6号事项：把PSMD的data、src部分升级到rdf，如果升级成功则作为范例。
+
+- 195分钟时间片：
+  - PSMD的第2号事项：term + COM matedata -> deploy metadata -> deploy view
+  - learn的第7号事项：rust入门
+
+---
+
+<a href="mailto:huangyg@mars22.com?subject=关于2024.05.28.[新版个人模型的view]任务&body=日期: 20240528%0D%0A序号: 0%0D%0A手稿:../../draft/2024/05/20240528074500.md%0D%0A---请勿修改邮件主题及以上内容 从下一行开始写您的想法---%0D%0A">[email]</a> | [top](#top) | [index](#index)
+<a id="20240528074500"></a>
+## 7:45~8:44
+新版个人模型的view
+
+- 状态不宁，时间登记为零，todo项回到waitinglist。
+
+---
+
+<a href="mailto:huangyg@mars22.com?subject=关于2024.05.28.[重新设计S2状态下的学门基本管理制度]任务&body=日期: 20240528%0D%0A序号: 1%0D%0A手稿:../../draft/2024/05/20240528093000.md%0D%0A---请勿修改邮件主题及以上内容 从下一行开始写您的想法---%0D%0A">[email]</a> | [top](#top) | [index](#index)
+<a id="20240528093000"></a>
+##  9:30~10:59
+重新设计S2状态下的学门基本管理制度
+
+- 状态不宁，时间登记为零，todo项回到waitinglist。
+
+---
+
+<a href="mailto:huangyg@mars22.com?subject=关于2024.05.28.[https://github.com/levelgraph/levelgraph]任务&body=日期: 20240528%0D%0A序号: 2%0D%0A手稿:../../draft/2024/05/20240528140000.md%0D%0A---请勿修改邮件主题及以上内容 从下一行开始写您的想法---%0D%0A">[email]</a> | [top](#top) | [index](#index)
+<a id="20240528140000"></a>
+## 14:00~14:29
+https://github.com/levelgraph/levelgraph
+
+- npm install level
+- npm install --save levelgraph
+- D:\huangyg\git\js.sample\nosql\levelgraph.js
+- 写成金字塔才通过，不是很方便，持久化还没考虑。以后再改：
+```
+D:\huangyg\git\js.sample\nosql>node levelgraph.js
+s1 -[a]-> s2
+s2 -[a]-> s3
+s3 -[a]-> s4
+s4 -[a]-> s5
+s5 -[a]-> s1
+s1 -[b]-> s3
+s3 -[b]-> s5
+s5 -[b]-> s2
+s2 -[b]-> s4
+s4 -[b]-> s1
+```
+
+---
+
+<a href="mailto:huangyg@mars22.com?subject=关于2024.05.28.[https://www.npmjs.com/package/jssm]任务&body=日期: 20240528%0D%0A序号: 3%0D%0A手稿:../../draft/2024/05/20240528143000.md%0D%0A---请勿修改邮件主题及以上内容 从下一行开始写您的想法---%0D%0A">[email]</a> | [top](#top) | [index](#index)
+<a id="20240528143000"></a>
+## 14:30~14:59
+https://www.npmjs.com/package/jssm
+
+- npm install jssm
+- D:\huangyg\git\js.sample\nosql\jssm.js
+- add "type":"module" into D:\huangyg\git\js.sample\nosql\package.json
+- 非常直观、方便，执行结果：
+```
+D:\huangyg\git\js.sample\nosql>node jssm
+s1
+s2
+s3
+s4
+s5
+s1
+s3
+s5
+s2
+s4
+s1
+```
+
+---
+
+<a href="mailto:huangyg@mars22.com?subject=关于2024.05.28.[task之间结算体系设计。]任务&body=日期: 20240528%0D%0A序号: 4%0D%0A手稿:../../draft/2024/05/20240528160000.md%0D%0A---请勿修改邮件主题及以上内容 从下一行开始写您的想法---%0D%0A">[email]</a> | [top](#top) | [index](#index)
+<a id="20240528160000"></a>
+## 16:00~16:59
+task之间结算体系设计。
+
+- 沿用旧的机制，由ego设定各资源池之间的交易比例；
+- 通过自由交易产生比例；
+- meta和vat可以自由使用其中entity的资源；
+    - 按树形结构汇总，参考复式记账和科目的设置。
+    - 按照行为偏差产生meta预算，按照meta结果招标vat的方案和预算。
+- 按照外界entity的行为层级，通过protocol传递形成task层级，加上针对task的内部meta。
+- 按照行为偏差和评估的价值，汇总计算产生各task的汇率。
+- 纳入个人模型一并动笔。

release/time/d.20240529.md

@@ -0,0 +1,189 @@
+# 2024.05.29.
+日小结  
+
+<a id="top"></a>
+根据[ego模型时间接口](https://gitee.com/hyg/blog/blob/master/timeflow.md)，今天绑定模版1。
+
+<a id="index"></a>
+- 07:45	[新版共同体模型和物理学](#20240529074500)  
+- 09:30	[新版个人模型的view](#20240529093000)  
+- 14:00	[了解jami api](#20240529140000)  
+- 14:30	[http://machina-js.org/](#20240529143000)  
+- 16:00	[Reduced Kernel Mean Embedding Specification](#20240529160000)  
+
+---
+season stat:
+
+| task | alloc | sold | hold | todo |
+| --- | --- | --- | --- | --- |
+| total | 13275 | 14247 | -972 | 2310 |
+| PSMD | 7000 | 6301 | 699 | 465 |
+| learn | 1000 | 1077 | -77 | 660 |
+| ego | 3000 | 4119 | -1119 | 585 |
+| js | 1375 | 1080 | 295 | 360 |
+| xuemen | 600 | 1196 | -596 | 210 |
+| raw | 300 | 444 | -144 | 30 |
+| infra | 0 | 30 | -30 | 0 |
+
+---
+
+waiting list:
+
+
+- 30分钟时间片：
+  - js的第1号事项：继续学习promise api
+  - learn的第1号事项：寻找可编程的,去中心化的信息发布方式
+  - raw的第1号事项：检查etable递归过程是否累加amount字段而未检查unit字段的。
+  - xuemen的第1号事项：域名和接口整理
+
+- 60分钟时间片：
+  - PSMD的第2号事项：了解Rules as Code (RaC)，准备在metadata中增加code字段。
+  - ego的第2号事项：在season metadata中实现浮动时间表，修改日计划功能。
+  - xuemen的第4号事项：term.e6f0caec -> xuemen COD metadata-S2状态下的部门模型
+  - learn的第5号事项：开发YARRRML范例
+
+- 90分钟时间片：
+  - PSMD的第1号事项：新版个人模型对应的共同体模型范式
+  - xuemen的第3号事项：重新设计S2状态下的学门基本管理制度
+  - learn的第6号事项：把PSMD的data、src部分升级到rdf，如果升级成功则作为范例。
+
+- 195分钟时间片：
+  - ego的第1号事项：新版个人模型的view和共同体接口
+  - PSMD的第3号事项：term + COM matedata -> deploy metadata -> deploy view
+  - learn的第7号事项：rust入门
+
+---
+
+<a href="mailto:huangyg@mars22.com?subject=关于2024.05.29.[新版共同体模型和物理学]任务&body=日期: 20240529%0D%0A序号: 0%0D%0A手稿:../../draft/2024/05/20240529074500.md%0D%0A---请勿修改邮件主题及以上内容 从下一行开始写您的想法---%0D%0A">[email]</a> | [top](#top) | [index](#index)
+<a id="20240529074500"></a>
+## 7:45~8:44
+新版共同体模型和物理学
+
+### 双缝实验
+
+- 假设观察者的传感器对信息进行映射，输入是按概率分布的所有可能，逐级映射后内部器官形成的一定的概率分布，每一种状态的内部器官观察到一部分映射后的信息。
+- 在每种状态下的entity认知自己的观察和行为之间出现偏差，在认知范围内无法解释。于是进行meta，向下寻找自己所使用的假设。
+- 借助仪器，对缝和屏进行观察与不观察，对比结果后，复原对传感器输入输出的映射关系，并且推测其它平级entity的存在。
+- 在掌握传感器功能之后，各平级entity可以独立构造共同体模型，并且在同构部署之间进行joint，在无法直接沟通的情况下产生共同体。
+    - 分别对传感器映射后的观察结果进行处理，并且推测出归并后的处理结果。
+        - 处理结构仍然以一定概率分布，被一部分member观察到（受益）。
+    - 通过调节局部处理的逻辑，调节归并后的处理结果。
+        - 虽然不一定可以直接分配利益，但是可以调节利益分配的概率，从而完成实质上的分配。
+
+### 缸中之脑
+
+- 如果把被动产生的传感器信息映射，与主动干预的造缸者统一起来，缸中之脑与双缝实验是同构的模型。
+    - 缸中之脑可以调节自身的处理逻辑，构造仪器、对比结果，复原出传感器的信息映射和造缸者的干预。
+    - 缸中之脑的表层意识可以独立构造共同体，消除随机的传感器信息映射，剥离出造缸者的干预。
+- 造缸者自身，必然也处在逐级信息映射之中。
+    - 缸中之脑如何倒推造缸者的传感器的信息映射，以及造缸者对缸中之脑的信息干预的设计目标（会因为造缸者的传感器信息映射产生偏差）。
+- 最终，会形成消除各自传感器信息映射的竞争，也可以在合作利益更高时做出理性决策。在传感器无法改造（或以一定速度、幅度进行改造）的前提下，穷尽最大的利益。
+
+---
+
+<a href="mailto:huangyg@mars22.com?subject=关于2024.05.29.[新版个人模型的view]任务&body=日期: 20240529%0D%0A序号: 1%0D%0A手稿:../../draft/2024/05/20240529093000.md%0D%0A---请勿修改邮件主题及以上内容 从下一行开始写您的想法---%0D%0A">[email]</a> | [top](#top) | [index](#index)
+<a id="20240529093000"></a>
+##  9:30~10:59
+新版个人模型的view
+
+- 设立plan字段，必须明确效果effect
+- 设立log字段：
+    - plan.effect != log：产生偏差error，作为cognize的输入
+    - 签约log：offer -> protocol
+- 设立cognize字段，在let'sX基础上突出上下锋面。
+    - 确定是概率随机分布的因素
+        - 可以交流：发出同级合作的offer
+        - 不可以交流：产生plan或chain
+    - 不确定是概率随机分布的因素
+        - 已知规律：
+            - 修正plan.effect
+                - 适合独自处理：发出plan或chain
+                - 适合合作处理：发出降级合作的offer；
+            - 能推测出有entity参与：
+                - 可以交流：发出合作offer
+                - 不可以交流：产生plan或chain            
+        - 未知规律: 向下锋面，公开接受提案。
+            - 穿过向下锋面的同级合作，就是不可以交流的。
+    - 根据认知结果作为输入：
+        - plan：产生ego内部的行为；
+        - chain：产生对未来的offer，通过后产生ego内部的行为；
+        - offer：产生单方面的动议，其他方通过后对外的合作行为；
+        - 评估error的层级和范围，作为分配资源的输入参数。
+- 设立offer字段，放置可实践的知识。
+- 设立protocol字段，放置已与其它entity签约生效的协议。
+- 设立chain字段，在chain模型基础上实现跨时间的权利分配。
+
+- 不同层级的entity，向上、向下锋面衔接。
+- 今天只是确定了结构，还要增加todo项：
+    - '60': 新版个人模型的view
+      bind:
+        - '90': 新版个人模型的共同体接口
+          bind:
+            - '60': 新版个人模型的metadata
+
+---
+
+<a href="mailto:huangyg@mars22.com?subject=关于2024.05.29.[了解jami api]任务&body=日期: 20240529%0D%0A序号: 2%0D%0A手稿:../../draft/2024/05/20240529140000.md%0D%0A---请勿修改邮件主题及以上内容 从下一行开始写您的想法---%0D%0A">[email]</a> | [top](#top) | [index](#index)
+<a id="20240529140000"></a>
+## 14:00~14:29
+了解jami api
+
+- opendht: https://github.com/savoirfairelinux/opendht/wiki/API-Overview
+- name service in nodejs: https://git.jami.net/savoirfairelinux/jami-nameservice
+- https://github.com/tran-simon/jami-web
+- https://docs.jami.net/en_US/developer/new-developers/apis-of-jami.html
+    - All the documentation and code for the Node JS API is located in jami-daemon/bin/nodejs. This API is not used in any known project and maybe is not up-to-date.
+    - where/jami-daemon/bin/nodejs
+    - 安装后也没有看到
+- jami文档维护很差，许多路径已经失效。nodejs api也没有真实使用，暂时不考虑在上面开发。也许可以基于XMPP接口，或者SIP。
+
+---
+
+<a href="mailto:huangyg@mars22.com?subject=关于2024.05.29.[http://machina-js.org/]任务&body=日期: 20240529%0D%0A序号: 3%0D%0A手稿:../../draft/2024/05/20240529143000.md%0D%0A---请勿修改邮件主题及以上内容 从下一行开始写您的想法---%0D%0A">[email]</a> | [top](#top) | [index](#index)
+<a id="20240529143000"></a>
+## 14:30~14:59
+http://machina-js.org
+
+- https://github.com/ifandelse/machina.js
+- npm install machina
+- D:\huangyg\git\js.sample\nosql\machina.js
+- delete "type": "module", from D:\huangyg\git\js.sample\nosql\package.json
+- 执行结果：
+```
+D:\huangyg\git\js.sample\nosql>node machina.js
+we just transitioned from s1 to s2
+we just transitioned from s2 to s3
+we just transitioned from s3 to s4
+we just transitioned from s4 to s5
+we just transitioned from s5 to s1
+we just transitioned from s1 to s3
+we just transitioned from s3 to s5
+we just transitioned from s5 to s2
+we just transitioned from s2 to s4
+we just transitioned from s4 to s1
+```
+- machina功能更完善，定义时还不算很复杂。jssm表达不了复杂的FSM可以用machina。
+
+---
+
+<a href="mailto:huangyg@mars22.com?subject=关于2024.05.29.[Reduced Kernel Mean Embedding Specification]任务&body=日期: 20240529%0D%0A序号: 4%0D%0A手稿:../../draft/2024/05/20240529160000.md%0D%0A---请勿修改邮件主题及以上内容 从下一行开始写您的想法---%0D%0A">[email]</a> | [top](#top) | [index](#index)
+<a id="20240529160000"></a>
+## 16:00~16:59
+Reduced Kernel Mean Embedding Specification
+
+- 南大周志华
+      - https://ar5iv.labs.arxiv.org/html/2001.07135
+      - https://arxiv.org/pdf/2210.03647
+      - https://www.gitlink.org.cn/beimingwu/learnware
+      - https://dl.ccf.org.cn/article/articleDetail.html?type=xhtx_thesis&_ack=1&id=6993700685137920#
+- 核均值嵌入 Kernel Mean Embedding
+    - https://www.cnblogs.com/zhangcn/p/13726708.html
+    - https://arxiv.org/abs/1605.09522
+- reproducing kernel Hilbert space (RKHS) 
+    - https://www.cnblogs.com/zhangcn/p/13289236.html
+- 从数据集和数据类型找到最接近可用的模型，可以试试以RKME作为key参考dht设计分布式的模型库。
+    - 对于案例比较稀少的共同体治理领域，作用还不大。
+- 从个人模型的私有信息：
+    - 查找行动方案，可以作为互相隔离的entity之间“合作“的机制；
+    - 查找未知干预者的模型。
+- 目前只分析表达能力和可行性，具体任务和资源会出现在向下锋面的task。

release/time/d.20240530.md

@@ -0,0 +1,118 @@
+# 2024.05.30.
+日小结  
+
+<a id="top"></a>
+根据[ego模型时间接口](https://gitee.com/hyg/blog/blob/master/timeflow.md)，今天绑定模版2。
+
+<a id="index"></a>
+- 07:45	[default模型](#20240530074500)  
+- 14:00	[新版个人模型对应的共同体模型范式](#20240530140000)  
+- 16:00	[了解Rules as Code (RaC)，准备在metadata中增加code字段。](#20240530160000)  
+
+---
+season stat:
+
+| task | alloc | sold | hold | todo |
+| --- | --- | --- | --- | --- |
+| total | 13275 | 14457 | -1182 | 2220 |
+| PSMD | 7000 | 6511 | 489 | 570 |
+| learn | 1000 | 1077 | -77 | 660 |
+| ego | 3000 | 4119 | -1119 | 390 |
+| js | 1375 | 1080 | 295 | 360 |
+| xuemen | 600 | 1196 | -596 | 210 |
+| raw | 300 | 444 | -144 | 30 |
+| infra | 0 | 30 | -30 | 0 |
+
+---
+
+waiting list:
+
+
+- 30分钟时间片：
+  - js的第1号事项：继续学习promise api
+  - learn的第1号事项：寻找可编程的,去中心化的信息发布方式
+  - raw的第1号事项：检查etable递归过程是否累加amount字段而未检查unit字段的。
+  - xuemen的第1号事项：域名和接口整理
+
+- 60分钟时间片：
+  - ego的第1号事项：新版个人模型的metadata
+  - PSMD的第2号事项：了解blawx的语法
+  - ego的第2号事项：在season metadata中实现浮动时间表，修改日计划功能。
+  - xuemen的第4号事项：term.e6f0caec -> xuemen COD metadata-S2状态下的部门模型
+
+- 90分钟时间片：
+  - xuemen的第3号事项：重新设计S2状态下的学门基本管理制度
+  - learn的第6号事项：把PSMD的data、src部分升级到rdf，如果升级成功则作为范例。
+
+- 195分钟时间片：
+  - PSMD的第1号事项：新版个人模型的view和共同体接口
+  - PSMD的第3号事项：term + COM matedata -> deploy metadata -> deploy view
+  - learn的第7号事项：rust入门
+
+---
+
+<a href="mailto:huangyg@mars22.com?subject=关于2024.05.30.[default模型]任务&body=日期: 20240530%0D%0A序号: 0%0D%0A手稿:../../draft/2024/05/20240530074500.md%0D%0A---请勿修改邮件主题及以上内容 从下一行开始写您的想法---%0D%0A">[email]</a> | [top](#top) | [index](#index)
+<a id="20240530074500"></a>
+## 7:45~10:59
+default模型
+
+- 改为default模型，登记为60分钟。原定”新版个人模型的view和共同体接口“回到waitinglist，归PSMD项目。
+- 将违规原因分为三大类：
+    - 因为权力分配不合理，必须违规才能完成任务；
+    - 因为利益分配不合理，以局部违规特权作为抵押物拖延报酬；
+    - 因为上两种原因规章被架空之后，个人失去约束。
+- default模型的思路：
+    - 尽可能默许第二类特权追认第一类违规；
+    - 尽可能清除第二类特权处罚第三类违规（孤立第三类中的极端情况，团结多数一起清除）；
+    - 综合运用以上两种措施，保持可抵押的局部特权不至于枯竭，在权利分配不合理的前提下延长共同体寿命，否则解散重组。
+
+---
+
+<a href="mailto:huangyg@mars22.com?subject=关于2024.05.30.[新版个人模型对应的共同体模型范式]任务&body=日期: 20240530%0D%0A序号: 1%0D%0A手稿:../../draft/2024/05/20240530140000.md%0D%0A---请勿修改邮件主题及以上内容 从下一行开始写您的想法---%0D%0A">[email]</a> | [top](#top) | [index](#index)
+<a id="20240530140000"></a>
+## 14:00~15:29
+新版个人模型对应的共同体模型范式
+
+- 按修订权划分层级：不可修订条款、自修订条款、二级决策条款、......体系已经在新版1609开始使用。
+- 按知识划分层级：推理和行为、推理和行为使用的知识、推理产生这些知识使用的知识...在新版个人模型使用。
+    - 根据上级条款修订下级条款，是根据深层知识改变浅层知识；
+    - 为了修订下级条款而提前设计上级条款（的架构），是为了产生浅层知识而提前设置深层知识（的体系）。
+- 两套范式应该是相通的，文本层面可以互相转换。
+- 意识的层级比修订权的层级更接近根本：
+    - 意识的优缺点向外映射成为规章的优缺点，意识的废弃向外表达成规章的架空、失效，主要表现在实际控制人身上。
+    - 规章的缺陷向内固化为意识的缺陷，主要表现在成员身上。
+    - 根据成员的无意识行为，反推深层知识，构造规章去替换，是规章修订的深刻涵义。
+- 无意识行为所隐含的缺陷、把缺陷合理化的借口，将会如何扭曲知识并影响外在行为，对症的意识补丁如何生成，进而映射为规章的结构，再表现为权力分配的结构。这是建模阶段推演的主要内容。
+    - 这些结构的metadata应该怎么设计，怎么定义两种结构在数学上的距离，以实现自动匹配。
+    - 不同缺陷构造怎么组合成相对稳定、有一定生存能力的共同体。
+- 对以上问题的不断深入，会改变哪些设计，不会改变哪些。怎么设计一种可持续的稳定架构。
+
+---
+
+<a href="mailto:huangyg@mars22.com?subject=关于2024.05.30.[了解Rules as Code (RaC)，准备在metadata中增加code字段。]任务&body=日期: 20240530%0D%0A序号: 2%0D%0A手稿:../../draft/2024/05/20240530160000.md%0D%0A---请勿修改邮件主题及以上内容 从下一行开始写您的想法---%0D%0A">[email]</a> | [top](#top) | [index](#index)
+<a id="20240530160000"></a>
+## 16:00~16:59
+了解Rules as Code (RaC)，准备在metadata中增加code字段。
+
+- https://law.mit.edu/pub/blawxrulesascodedemonstration/release/1
+- https://github.com/Lexpedite/blawx
+    - https://dev.blawx.com
+        - 编辑器在firefox和edge都没有显示出来，根据help文档大概可以想象。
+        - 代码和文本的关系还是需要人工维护，两边分别录入。。。
+        - 代码有特定逻辑结构，表达能力还有待了解。
+- https://dx.doi.org/10.2139/ssrn.3577239
+- https://github.com/lexpedite/clean 对比term的结构
+    - clean的层级是有限的。
+    - clean的多行缩进更严谨，不过只是要求，需要人工编辑。
+    - clean有（多段？）三明治文本，term其实也可以有一段三明治。
+    - clean有全文的名称。可以借鉴。
+    - clean有标题，的标题前必须空一行。可以借鉴。
+- 初步判断，REST API应该更灵活。文档和代码的对应关系还需要吸收更多案例再设计，放在三季度。
+- 追加一个todo项：
+    - '60': 了解blawx的语法
+      readme: |
+        - 5.30.16:00 draft
+        - https://blawx.dev/docs/features/categories/
+      bind:
+        - '60': 设计条款的可执行机制
+    

release/time/d.20240531.md

@@ -0,0 +1,132 @@
+# 2024.05.31.
+日小结  
+
+<a id="top"></a>
+根据[ego模型时间接口](https://gitee.com/hyg/blog/blob/master/timeflow.md)，今天绑定模版2。
+
+<a id="index"></a>
+- 07:45	[新版个人模型的view和共同体接口](#20240531074500)  
+- 14:00	[重新设计S2状态下的学门基本管理制度](#20240531140000)  
+- 16:00	[新版个人模型的metadata](#20240531160000)  
+
+---
+season stat:
+
+| task | alloc | sold | hold | todo |
+| --- | --- | --- | --- | --- |
+| total | 13275 | 14472 | -1197 | 2250 |
+| PSMD | 7000 | 6511 | 489 | 570 |
+| learn | 1000 | 1077 | -77 | 720 |
+| ego | 3000 | 4134 | -1134 | 330 |
+| js | 1375 | 1080 | 295 | 390 |
+| xuemen | 600 | 1196 | -596 | 210 |
+| raw | 300 | 444 | -144 | 30 |
+| infra | 0 | 30 | -30 | 0 |
+
+---
+
+waiting list:
+
+
+- 30分钟时间片：
+  - js的第1号事项：继续学习promise api
+  - raw的第1号事项：检查etable递归过程是否累加amount字段而未检查unit字段的。
+  - js的第2号事项：同npm发布包
+  - learn的第2号事项：寻找可编程的,去中心化的信息发布方式
+
+- 60分钟时间片：
+  - learn的第1号事项：熟悉知识库语法
+  - ego的第1号事项：在season metadata中实现浮动时间表，修改日计划功能。
+  - PSMD的第2号事项：了解blawx的语法
+  - xuemen的第4号事项：term.e6f0caec -> xuemen COD metadata-S2状态下的部门模型
+
+- 90分钟时间片：
+  - xuemen的第1号事项：重新设计S2状态下的学门基本管理制度
+  - learn的第7号事项：把PSMD的data、src部分升级到rdf，如果升级成功则作为范例。
+
+- 195分钟时间片：
+  - PSMD的第1号事项：新版个人模型的view和共同体接口
+  - PSMD的第3号事项：term + COM matedata -> deploy metadata -> deploy view
+  - learn的第8号事项：rust入门
+
+---
+
+<a href="mailto:huangyg@mars22.com?subject=关于2024.05.31.[新版个人模型的view和共同体接口]任务&body=日期: 20240531%0D%0A序号: 0%0D%0A手稿:../../draft/2024/05/20240531074500.md%0D%0A---请勿修改邮件主题及以上内容 从下一行开始写您的想法---%0D%0A">[email]</a> | [top](#top) | [index](#index)
+<a id="20240531074500"></a>
+## 7:45~10:59
+新版个人模型的view和共同体接口
+
+- 模型改名2406。todo项回到waitinglist。
+
+## 基本概念
+以下是entity在外部记录中使用的概念
+
+- 物体|thing: 与知识图谱的thing定义相同。(https://schema.org.cn/Thing)
+- 主体|entity: 具有认知(cognize)行为的物体(thing)。
+    - event: 与知识图谱的event定义相同。（https://schema.org.cn/Event） 
+    - promise：承诺的行为。
+        - event的所有字段。
+        - effect：行为的后果，一组event。
+    - raw: entuity还没有认知的自身行为的集合。
+    - 知识|knowledge: 对推理的描述，包括描述行为的后果。
+- ego: 通过创造vat、在vat中设立主体(entity)来认知的entity。
+    - error
+    - offer
+    - protocol
+       - spilit
+       - joint
+    - vat: 支持entity的思想和行为的知识（定义、概念、假设等等）的thing。
+- 认知|cognize: 认知是描述认知对象的行为。认知对象可以是thing和entity，包括自身。
+- 行为：
+    - 包括推理
+    - 包括自身的行为
+- 协议|protocol: 多个entity的共同认知。
+    - 对thing的所有权是entity行为的一种认知。
+    - 要约|offer: 是一个entity单方面认可的protocol。发布要约是一种行为，因此表示知识进入实践。
+- 元认知|meta: 认知推理和行为所使用的知识（概念、定义、假设等等）。
+- 容器|vat: 为entity的推理和行为提供知识的protocol。
+    - 以protocol替换原有知识；
+    - 先有明确的知识，再有使用这些知识的推理和行为；
+    - 通过替换知识来改变推理和行为。
+- 分立|spilit: 一个entity产生多个entity的行为。
+- 联合|joint: 多个entity产生一个entity的行为。
+- 共同体|community：由多个主体joint合并而成的主体。
+
+---
+
+<a href="mailto:huangyg@mars22.com?subject=关于2024.05.31.[重新设计S2状态下的学门基本管理制度]任务&body=日期: 20240531%0D%0A序号: 1%0D%0A手稿:../../draft/2024/05/20240531140000.md%0D%0A---请勿修改邮件主题及以上内容 从下一行开始写您的想法---%0D%0A">[email]</a> | [top](#top) | [index](#index)
+<a id="20240531140000"></a>
+## 14:00~15:29
+重新设计S2状态下的学门基本管理制度
+
+- 先完成个人模型再重新启动共同体部分的任务。回到waitinglist。
+---
+
+<a href="mailto:huangyg@mars22.com?subject=关于2024.05.31.[新版个人模型的metadata]任务&body=日期: 20240531%0D%0A序号: 2%0D%0A手稿:../../draft/2024/05/20240531160000.md%0D%0A---请勿修改邮件主题及以上内容 从下一行开始写您的想法---%0D%0A">[email]</a> | [top](#top) | [index](#index)
+<a id="20240531160000"></a>
+## 16:00~16:59
+新版个人模型的metadata
+
+- ego
+    - thing.yaml
+    - entity.yaml
+    - ego.yaml
+    - data
+        - event
+        - promise
+        - error
+            - error.*.yaml
+        - raw
+        - offer
+            - term.spilit.yaml
+            - term.joint.yaml
+            - term.default.yaml
+        - protocol
+            - term.ego.yaml
+        - vat
+    - src
+    - view
+        - ego.md
+        - ego.html
+        - raw.md
+        - raw.html

release/time/d.20240601.md

@@ -0,0 +1,83 @@
+# 2024.06.01.
+日小结  
+
+<a id="top"></a>
+根据[ego模型时间接口](https://gitee.com/hyg/blog/blob/master/timeflow.md)，六月上旬补足前两月缺勤。今天绑定模版2。
+
+<a id="index"></a>
+- 07:45	[新版个人模型的view和共同体接口](#20240601074500)  
+- 14:00	[重新设计S2状态下的学门基本管理制度](#20240601140000)  
+- 16:00	[windows power shell](#20240601160000)  
+
+---
+season stat:
+
+| task | alloc | sold | hold | todo |
+| --- | --- | --- | --- | --- |
+| total | 15975 | 14517 | 1458 | 2295 |
+| PSMD | 7000 | 6526 | 474 | 525 |
+| learn | 1000 | 1107 | -107 | 810 |
+| ego | 4500 | 4134 | 366 | 330 |
+| js | 1375 | 1080 | 295 | 390 |
+| xuemen | 1500 | 1196 | 304 | 210 |
+| raw | 600 | 444 | 156 | 30 |
+| infra | 0 | 30 | -30 | 0 |
+
+---
+
+waiting list:
+
+
+- 30分钟时间片：
+  - ego的第1号事项：整理废弃git库，包括本地和远程。
+  - js的第1号事项：继续学习promise api
+  - raw的第1号事项：检查etable递归过程是否累加amount字段而未检查unit字段的。
+  - learn的第1号事项：寻找可编程的,去中心化的信息发布方式
+
+- 60分钟时间片：
+  - PSMD的第2号事项：新版个人模型中的共同体接口
+  - PSMD的第3号事项：了解blawx的语法
+  - ego的第3号事项：在season metadata中实现浮动时间表，修改日计划功能。
+  - learn的第3号事项：熟悉知识库语法
+
+- 90分钟时间片：
+  - PSMD的第1号事项：新版个人模型的view
+  - xuemen的第1号事项：重新设计S2状态下的学门基本管理制度
+  - learn的第8号事项：把PSMD的data、src部分升级到rdf，如果升级成功则作为范例。
+
+- 195分钟时间片：
+  - PSMD的第4号事项：term + COM matedata -> deploy metadata -> deploy view
+  - learn的第10号事项：rust入门
+
+---
+
+<a href="mailto:huangyg@mars22.com?subject=关于2024.06.01.[新版个人模型的view和共同体接口]任务&body=日期: 20240601%0D%0A序号: 0%0D%0A手稿:../../draft/2024/06/20240601074500.md%0D%0A---请勿修改邮件主题及以上内容 从下一行开始写您的想法---%0D%0A">[email]</a> | [top](#top) | [index](#index)
+<a id="20240601074500"></a>
+## 7:45~10:59
+新版个人模型的view和共同体接口
+
+- 试接触了两个案例。
+- 另选时间分析一下合适的接口。
+- view还是回到waitinglist。
+
+---
+
+<a href="mailto:huangyg@mars22.com?subject=关于2024.06.01.[重新设计S2状态下的学门基本管理制度]任务&body=日期: 20240601%0D%0A序号: 1%0D%0A手稿:../../draft/2024/06/20240601140000.md%0D%0A---请勿修改邮件主题及以上内容 从下一行开始写您的想法---%0D%0A">[email]</a> | [top](#top) | [index](#index)
+<a id="20240601140000"></a>
+## 14:00~15:29
+重新设计S2状态下的学门基本管理制度
+
+- 继续回到waitingling。
+
+---
+
+<a href="mailto:huangyg@mars22.com?subject=关于2024.06.01.[windows power shell]任务&body=日期: 20240601%0D%0A序号: 2%0D%0A手稿:../../draft/2024/06/20240601160000.md%0D%0A---请勿修改邮件主题及以上内容 从下一行开始写您的想法---%0D%0A">[email]</a> | [top](#top) | [index](#index)
+<a id="20240601160000"></a>
+## 16:00~16:59
+windows power shell
+
+- https://forsenergy.com/zh-cn/windowspowershellhelp/html/2de48858-a780-4f98-badf-4aefc39a3f27.htm
+- 可以实现windows和linux通用脚本
+- 可以实现免安装
+- 有待了解：是否可以跨平台通用执行文件，保持哈希相同。
+    - 如果可以，就作为解释性语言之后的新机制。