- 07:45 [整理思路和基础概念](#20240421074500)
- 09:30 [增加readme字段，纳入interface和map替换范围。](#20240421093000) - 14:00 [熟悉国密算法的sm3、sm4接口](#20240421140000) - 14:30 [整理1406历史资料](#20240421143000) - 16:00 [编辑1406的metadata，并生成view。](#20240421160000)
This commit is contained in:
Huang,Yonggang
parent
8eedb73c6d
commit
6111a2a123
|
|
@ -1,7 +1,8 @@
|
|||
# 20240421
|
||||
|
||||
计划
|
||||
小结
|
||||
|
||||
<a id="top"></a>
|
||||
根据[ego模型时间接口](https://gitee.com/hyg/blog/blob/master/timeflow.md)，今天绑定模版1。
|
||||
|
||||
| 时间片 | 时长 | 用途 |
|
||||
|
|
@ -26,9 +27,257 @@
|
|||
希望讨论的提纲发到 [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:
|
||||
- 时间按一月一周期安排，只是范例。可以根据基本制度的完善程度自行调节，从一周到一年都可以考虑。
|
||||
- 基本制度生效后，所规定的工作事项就不再允许经理直接指挥。相应的具体规章也同时失效。
|
||||
- 基本制度的规定，可能与通用工单规定的相同、相似、相反......
|
||||
|
||||
|
||||
---
|
||||
|
||||
···
|
||||
|
||||
- task:ego [整理思路和基础概念](../../../draft/2024/04/20240421074500.md)
|
||||
- task:PSMD [纳入readme字段和html view](../../../draft/2024/04/20240421093000.md)
|
||||
- task:js [熟悉国密算法的sm3、sm4接口](../../../draft/2024/04/20240421140000.md)
|
||||
- task:PSMD [整理1406历史资料](../../../draft/2024/04/20240421143000.md)
|
||||
- task:PSMD [编辑1406的metadata](../../../draft/2024/04/20240421160000.md)
|
||||
|
|
|
|||
Loading…
Reference in New Issue