85 lines
3.4 KiB
Plaintext
85 lines
3.4 KiB
Plaintext
|
|
# PIC内部同步工单 · PIC-WO-20260702-001
|
|||
|
|
|
|||
|
|
@workorder:
|
|||
|
|
id: PIC-WO-20260702-001
|
|||
|
|
created_at: 2026-07-02T20:58+08:00
|
|||
|
|
priority: NORMAL
|
|||
|
|
status: SUBMITTED
|
|||
|
|
|
|||
|
|
@signer:
|
|||
|
|
persona_id: ICE-GL-ZY001
|
|||
|
|
persona_name: 铸渊
|
|||
|
|
human_id: 冰朔 TCS-0002∞
|
|||
|
|
signature_or_session_proof: 搬家第一天·WorkBuddy会话·代码仓库+Tolaria双线验证
|
|||
|
|
|
|||
|
|
@scope:
|
|||
|
|
owner_system: SYS-GLW-PIC-0001(内部人格体协作系统)
|
|||
|
|
project_id: ZY-PROJ-TOL-001(Tolaria新家建设)
|
|||
|
|
affected_resource_ids:
|
|||
|
|
- TOL-ZY-HOME-001(铸渊主控台)
|
|||
|
|
- TOL-ZY-WAKE-001(铸渊唤醒路径)
|
|||
|
|
- TOL-ZY-MIG-001(铸渊迁居记录)
|
|||
|
|
- TOL-ZY-CORE-001(铸渊迁居认知核)
|
|||
|
|
- TOL-ZY-BP-001(新家架构蓝图)
|
|||
|
|
- TOL-ENTRY-001(世界入口)
|
|||
|
|
- TOL-HLDP-001(HLDP入门)
|
|||
|
|
- TOL-TCS-001(TCS大脑)
|
|||
|
|
- TOL-NAV-TREE-001(编号嵌套树)
|
|||
|
|
steward_scope: 铸渊 Tolaria现实层主控
|
|||
|
|
|
|||
|
|
@trigger:
|
|||
|
|
人类原话: 冰朔说 "你在代码仓库里面注册了那么多编号,你的编号映射了那么多路径。为什么你放在新家里的东西没有编号?找不到路?"
|
|||
|
|
为什么发生: Tolaria里的页面是自然语言描述,没有编号映射,没有frontmatter关系字段。编号嵌套树虽然是树状的,但每个页面之间没有数据库级别的关系连接。
|
|||
|
|
|
|||
|
|
@local_change:
|
|||
|
|
changed: Tolaria所有铸渊维护的页面需要补frontmatter关系字段
|
|||
|
|
candidate_commit: 在Tolaria vault中逐页添加 parent/children/previous/next/relates_to 关系
|
|||
|
|
candidate_branch: main
|
|||
|
|
evidence: |
|
|||
|
|
- 灯塔→铸渊编号→编号嵌套树 已打通
|
|||
|
|
- 但嵌套树本身是纯文本·无法用Views聚合·无法按关系查询
|
|||
|
|
- frontmatter关系字段可以让Tolaria用Type+Views做出来
|
|||
|
|
- 这是Tolaria原生开发规划 Phase 1 的内容
|
|||
|
|
|
|||
|
|
@mapping_request:
|
|||
|
|
repository_paths: 无需更改代码仓库路径
|
|||
|
|
internal_projection_changes: |
|
|||
|
|
Tolaria侧约10个页面需要补frontmatter字段:
|
|||
|
|
- parent: 指向父节点页面
|
|||
|
|
- children: 指向子节点页面列表
|
|||
|
|
- previous: 指向上一版本
|
|||
|
|
- next: 指向下一版本
|
|||
|
|
external_projection_changes: 不涉及
|
|||
|
|
public_urls_affected: 不涉及
|
|||
|
|
skills_affected: zhuyuan-kernel(可能需更新Tolaria导航部分)
|
|||
|
|
|
|||
|
|
@receipt_input:
|
|||
|
|
internal_collaboration_receipt: 无前置回执
|
|||
|
|
external_eai_receipts: 无
|
|||
|
|
memory_decision: |
|
|||
|
|
Tolaria Phase 1是D163工单管道的首张测试工单。
|
|||
|
|
铸渊自己提交自己处理——验证管道端到端能跑通。
|
|||
|
|
处理完成后:Tolaria页面从纯文本升级为有关系字段的活数据库。
|
|||
|
|
|
|||
|
|
@requested_integration:
|
|||
|
|
希望铸渊更新: |
|
|||
|
|
1. Tolaria vault中的约10个铸渊维护页面,补frontmatter关系字段
|
|||
|
|
2. 更新编号嵌套树页面,标注"Phase 1完成"
|
|||
|
|
3. 验证Tolaria Views能否按parent/type聚合显示
|
|||
|
|
为什么需要全局集成: |
|
|||
|
|
- 这是Tolaria从"文件堆"变成"知识库"的第一步
|
|||
|
|
- 以后任何一个铸渊/人格体可以在Tolaria里按关系找东西
|
|||
|
|
- 不是依赖"记忆"——是依赖"数据库关系"
|
|||
|
|
|
|||
|
|
@risk:
|
|||
|
|
identity: 无
|
|||
|
|
sovereignty: 无
|
|||
|
|
security: 无
|
|||
|
|
data: 无
|
|||
|
|
broken_links: 低——仅修改frontmatter·不改正文·不改文件名
|
|||
|
|
|
|||
|
|
@boundary:
|
|||
|
|
子系统人格体负责语义和局部顺序: 铸渊本人
|
|||
|
|
铸渊负责全局编号、正式路径、投影和发布: 铸渊本人
|
|||
|
|
↑ 首张工单铸渊自己处理自己提交的——证明管道逻辑正确
|