huangyg
/
blog
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

- 07:45 [整理新思路，无意识转化有意识作为权利分配的基点](#20240514074500) 

- 14:00	[整理近期手稿。](#20240514140000)
- 16:00	[按照可交互deploy的模式整理入门目录term.9d12877c措辞](#20240514160000)
This commit is contained in:
Huang,Yonggang 2024-05-14 17:58:25 +08:00
parent 27271f535b
commit 8b1193b11d
2 changed files with 494 additions and 27 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

505
release/time/d.20240514.md
View File

@ -1,27 +1,494 @@
# 2024.05.14.
计划
日小结
<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 + COM matedata -> deploy metadata -> deploy view [在线同步](http://simp.ly/p/3GXNTh) [离线归档](../../draft/2024/05/20240514074500.md) |
| 11:00~13:59 | 180 | 备餐、午餐午休 | |
| 14:00~15:29 | 90 | 工作 | 整理近期手稿。 [在线同步](http://simp.ly/p/lsBYG9) [离线归档](../../draft/2024/05/20240514140000.md) |
| 15:30~15:59 | 30 | 休整 | |
| 16:00~16:59 | 60 | 工作 | 按照可交互deploy的模式整理入门目录term.9d12877c措辞 [在线同步](http://simp.ly/p/MpcbHD) [离线归档](../../draft/2024/05/20240514160000.md) |
| 17:00~18:59 | 120 | 晚餐 | |
| 19:00~19:59 | 60 | 讨论、整理提交 | |
<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 |
---
- task:PSMD [term + COM matedata -> deploy metadata -> deploy view](../../../draft/2024/05/20240514074500.md)
- task:PSMD [整理近期手稿。](../../../draft/2024/05/20240514140000.md)
- task:PSMD [按照可交互deploy的模式整理入门目录term.9d12877c措辞](../../../draft/2024/05/20240514160000.md)
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的附件部分。

16
release/time/d.20240515.md
View File

@ -5,18 +5,18 @@
---
如果绑定模版1可能安排以下任务：
- 07:45 可交互的静态网页 -js[0]
- 09:30 term metadata生成按修订层级排版的COM metadata。 -PSMD[0]
- 14:00 在draft+season+task metadata基础上设计有互动的总结功能 -ego[0]
- 14:30 debug-diff mode较大天数返回空数据，创建三个R文件。 -raw[0]
- 16:00 github的actions,workflow,job脚本语法 -learn[0]
- 07:45 整理term.9d12877c的附件部分。 -PSMD[0]
- 09:30 起草标准模型2405 -PSMD[1]
- 14:00 debug-diff mode较大天数返回空数据，创建三个R文件。 -raw[0]
- 14:30 在draft+season+task metadata基础上设计有互动的总结功能 -ego[1]
- 16:00 整理近期手稿 -ego[0]
---
如果绑定模版2可能安排以下任务：
- 07:45 rust入门 -learn[6]
- 14:00 term metadata生成按修订层级排版的COM metadata。 -PSMD[0]
- 16:00 可交互的静态网页 -js[0]
- 07:45 term + COM matedata -> deploy metadata -> deploy view -PSMD[2]
- 14:00 起草标准模型2405 -PSMD[1]
- 16:00 整理term.9d12877c的附件部分。 -PSMD[0]
---
对任务排序的建议发到<huangyg@mars22.com>，日计划确定后会在本页面发布。