blog/release/time/d.20240421.md

20240421

小结

根据ego模型时间接口，今天绑定模版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	静默工作
8:45~9:29	45	休整
9:30~10:59	90	静默工作
11:00~13:59	180	备餐、午餐午休
14:00~14:29	30	静默工作
14:30~14:59	30	静默工作
15:00~15:59	60	休整
16:00~16:59	60	静默工作
17:00~18:59	120	晚餐
19:00~19:59	60	讨论、整理提交

模版一采用静默工作方式。
希望讨论的提纲发到 huangyg@mars22.com，通常安排在后面某天的早餐（5:15~5:59）或会议时间（6:00~6:45）。

---

• 07:45 整理思路和基础概念
• 09:30 增加readme字段，纳入interface和map替换范围。
• 14:00 熟悉国密算法的sm3、sm4接口
• 14:30 整理1406历史资料
• 16:00 编辑1406的metadata，并生成view。

---

top | index

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 | index

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 | index

14:00~14:29

熟悉国密算法的sm3、sm4接口

在test.js中增加：

• 用sm3生成杂凑
• 用sm4加密、解密。

local.3.html无效，仍然没有找到原因。

top | index

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次起可以自行汇总，在审议周期结束时提交汇总的通用工单。
   • 重复性的指挥可以制定具体规章，具体规章的性质与效力都和现场指挥相同。
2. 通用工单由决策部门审议，决定：
   • 将该事项的处理要求纳入基本制度。可能与通用工单相同、相似、相反......一旦纳入基本制度就不再允许现场指挥。
   • 继续保留在基本制度以外，允许现场指挥。

效果：

1. 可以在无具体规章的情况下启动业务。
2. 防止权力失控、寻租。

1406是决策部门制定基本制度过程的动议，不是完整的共同体模型。

top | index

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:

• 时间按一月一周期安排，只是范例。可以根据基本制度的完善程度自行调节，从一周到一年都可以考虑。
• 基本制度生效后，所规定的工作事项就不再允许经理直接指挥。相应的具体规章也同时失效。
• 基本制度的规定，可能与通用工单规定的相同、相似、相反......

---

···