8.9 KiB

Raw Blame History

20240415

小结

时间片	时长	用途
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）。

7:45~8:44

整理任务看板

meeting：
- 异步议事的协作规范
- 三页面设计细化
- 熟悉软件测试，工具
- m90*2，编程。
PSMD：
- PPT，blog
- README工作计划预算
- m60、m90，README工作计划预算
- 1406、1609向成长模式下的原始模型植入
- PPT blog
- m45、m45、m60，PPT blog
- README PLAN BUDGET
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 很久没动静了，理念可以参考。】
ITW：
- 弱化线下招生，强化线上招生，鼓励生源互换，考虑信任网络。
- 适合在家，持续对抗，维护身份认同的机制。
let‘X
- 把knowledge归入letcongnize 【并没有创建knowledge git库，确实需要定义知识的互相关系，偏差-解决方案作为元数据，各库之间互相推介，是可选方案。需要定义这套方案的提出和修订。】
XUEMEN：
- IST机制，与JT互通、浮动。
- 理顺AER自动生成规则。

二季度规划（4.15起，按45天）：

30天绑定模版1：m9030，m6060，m30*60
5天绑定模版2：m1955，m905，m60*5
10天绑定模版3：
- PSMD：m1955，m905，m60*5
- TBD：m1955，m905，m60*5
外勤、缺勤在6月补回。

EGO：m306，m6020，m9013，m1951 - 日计划、小结自动生成： - 手工操作：m303，m601 - 代码：m606，m905，m1951 - 季度规划、小结自动生成： - 手工操作：m302，m602 - 代码：m604，m904 - 时间片任务匹配 - 手工操作：m301，m601 - 代码：m606，m904

PSMD：m307，m6037，m9020，m1954，模版32 - 入门目录： - 手工：m302，m604，m901 - 代码：m604，m904 - 带有升级、追溯功能的draft->blog\release机制。每个版本的要约、合同章节在draft中的日yaml中定义，自动整理后生成索引，内容以哈希命名、统一发布。引用处定义是某版本、最新版本（可多选），最新版本的可以自动产生正确的链接。旧版本详情有新版本入口。 - default - 手工：m301，m602，m901 - 代码：m604，m904，m1951 - 1406 - 手工：m302，m603，m901 - 代码：m608，m904，m1951，模版31 - 1609 - 手工：m302，m604，m901 - 代码：m608，m904，m1952，模版31

XUEMEN：m3040（47），m606（8），m90*2（2）

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 符合某条件对自述难以核实的情况下，可以按照以下方式之一增加补充信息：

涉事各方全体同意，推举一名或多名保证人：
- 保证人在其它事项中符合该条件，并按照本附件提供补充信息。
- 由保证人调查涉事各方是否符合该条件，将调查记录作为补充信息。
涉事各方分别自述，交叉核实。将所有记录合并作为补充信息。
涉事各方签署附件21 容器规则，承诺遵守该条件，将生效、执行的记录作为补充信息。

其他方根据补充信息作出判断后，进入后续讨论。

附件21 容器规则 1. 自然人可以公示一组规则（以下称为“章程”），并注入启动资金创建有限责任的虚拟主体（以下称为“账号”）。 1. 每个账号有独立的财产。由章程自行规定管理细则。 1. 每个账号可以独立对外签订合同。合同应明确规定仅以该账号财产承担责任。 1. 所有合同应该针对章程约定合规仲裁的方式。一旦违反章程则强制注销该账号，以最后的合规行为时间为注销时间，由当时有效合同的其他方组织清算，默认一份契约一票。 1. 账号财产可以跨账号调用，但转出账号的余额不得少于该账号签订的所有合同的待付款项（包括极限情况下的赔偿）总和。具体金额以对应收款方的理解为准。 1. 账号签订的所有合同结束、且合同中所有赔偿责任结束后，自然人可以注销该账号。 1. 章程条款适用分支隔离规则。

14:00~14:29

国密simple

测试了sm2的创建密钥、压缩公钥、验证密钥。输出：js.simple/sm.crypt/local.2.html

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文件的内容。

16:00~16:59

PSMD 自动入门目录

针对某问题的入口：在今天上午的手工范例中，如果对方针对附件42的问题提问，应自动生成以下回复：

针对不同条件给出建议如下：

使用自定义的规章解决资源和重构问题，具体可以参考1609、chain等标准模型。
- 同意按照附件20增加补充信息，补充关于附件30，42，31、32、33、34的补充信息，且均判断为符合。
先参考default+1406标准模型开展业务，逐步完善规章，取得进步后重新增加关于附件31、32、33、34的补充信息。
- 同意按照附件20增加补充信息，补充关于附件30，42，31、32、33、34的补充信息，且判断符合附件30、42，不全符合符合31、32、33、34。
在业务背景下，基于既成事实博弈。具体可以参考default标准模型。
- 不能按照附件20增加补充信息。
- 同意按照附件20增加补充信息，补充关于附件30的补充信息，且判断为不符合。
参考booting标准模型。
- 还在筹备因此无法补充信息的。

如果有其它可行方案请发到huangyg@mars22.com，我将按照附件21核实。

附件21 实施效果的核实

公布完整、连续、不可删改的执行记录，证实方案的效果。
- 如果以前的执行记录不符合以上条件，可以在愿意按标准公布记录的独立第三方验证。
已发布开放的要约，只有取得该效果才有收益。

在 js.simple/schame 下创建 demo.yaml demo.js 设计数据结构并完成解析。

8.9 KiB Raw Blame History Unescape Escape