sqlite-web 0.7.2
gitea.db
action
Create
Query
access
access_token
action
action_artifact
action_run
action_run_index
action_run_job
action_runner
action_runner_token
action_schedule
action_schedule_spec
action_task
action_task_output
action_task_step
action_tasks_version
action_variable
app_state
attachment
auth_token
badge
branch
collaboration
comment
commit_status
commit_status_index
commit_status_summary
commit_sync_log
commit_sync_status
dbfs_data
dbfs_meta
deploy_key
email_address
email_hash
external_login_user
follow
gpg_key
gpg_key_import
hook_task
issue
issue_assignees
issue_content_history
issue_dependency
issue_index
issue_label
issue_pin
issue_user
issue_watch
label
language_stat
lfs_lock
lfs_meta_object
login_source
milestone
mirror
notice
notification
oauth2_application
oauth2_authorization_code
oauth2_grant
org_user
package
package_blob
package_blob_upload
package_cleanup_rule
package_file
package_property
package_version
project
project_board
project_issue
protected_branch
protected_tag
public_key
pull_auto_merge
pull_request
push_mirror
reaction
release
renamed_branch
repo_archiver
repo_hidden_file
repo_indexer_status
repo_license
repo_redirect
repo_topic
repo_transfer
repo_unit
repository
review
review_state
secret
session
sqlite_sequence
star
stopwatch
system_setting
task
team
team_invite
team_repo
team_unit
team_user
topic
tracked_time
two_factor
upload
user
user_badge
user_blocking
user_open_id
user_redirect
user_setting
version
watch
webauthn_credential
webhook
Toggle helper tables
Structure
Content
Query
Insert
Drop
Import
Export
Delete row 30904 from action
id
30904
user_id
5
op_type
5
act_user_id
5
repo_id
117
comment_id
0
is_deleted
0
ref_name
refs/heads/main
is_private
0
content
{"Commits":[{"Sha1":"f4540e69b
{"Commits":[{"Sha1":"f4540e69b1656232b677571584d3bd6ad57217be","Message":"docs(架构): 总架构增 §3.8——基座的装载 / 调用两个方向与接入能力归属\n\n起因是一次实际误读：`c433d57` 被当成「另一个 OS 产品」。它是数字员工OS 仓的提交\nSHA（2026-09-14），由 base-framework-os-product/os.upstream.json 连同 protocol\n1.3.0 钉住，用途是让「上游 OS 走动了」以 O0-SHA 显式变红。与基座并列的不是它，\n是 base-framework-os-product 这个仓——示例产品扩展加两道 OS 门禁，2026-09-10\n随 G26 自框架仓移出以保框架零依赖。误读本身说明这几件事在文档里没写清，本节补上。\n\n**两个方向。** PNG 给基座的定语「理解、编排、调用、执行」对应两个方向相反的接口：\n装载（OS → 应用）已有协议（KERNEL_EXTENSION_PROTOCOL_VERSION = 1.3.0，定义在 OS\n仓 packages/contracts/src/product-manifest.ts），真装 1 个；调用（应用 → OS）基本\n空白——协议草案 §4 已给出 ProductActivationIntent / ToolIntentReceipt 并写明「OS\n应提供、产品不再自建」，2026-09-18 复核 OS 仓 apps/ 下仍无 product-activations\n路由，智服已在自己仓内造了一套。两个方向归属不同，混谈会把落点找错。\n\n**接入形态实测已分叉成五种：** product.manifest.json（示例 / 设备云 / 知识云）、\nmanifest.json（HR，另有 ddl-authority / distribution / readiness 三个独有文件且无\npackage.json）、manifest.ts（工单，另有 kernel.products.entry.json）。只有示例与\n设备云带 os-host 测试配置。\n\n**为什么「每个应用继承一份」今天做不到**（两条方向相反的硬事实）：OS 的包是\n@repo/* 仓内作用域名（@repo/contracts@1.16.0，与工单仓同名包撞名），外仓依赖不了，\n只能照抄；而协议 §2.1 又反向禁止产品导入宿主私有 @repo/*，宿主能力一律由组合根\n注入、产品契约要自包含。由此划边界：可继承的是契约 / Schema / 校验器 / 门禁，不可\n继承的是宿主运行时——搞混会废掉 §2.1 的 fail-closed import 扫描。\n\n**四个落点按依赖方向逐个判定：** 协议与 SDK 由基座以 @juhai/ 发布（合法，阻碍是\n@repo/* 命名）；分发通道归基础设施（合法，DEC-031 已批准，缺口是契约包 pin 无门禁\n——HR 与 OS 停在 rc.1、源仓已 rc.3，不像 kernel 有 L12 守着）；脚手架归框架（合法\n但受零依赖限制，只能给目录形状）；**把装载协议搬进基础设施不合法**——基础设施要\n编码基座契约即反向依赖，撞图 1 的唯一硬约束。本节只判合法性，不选落点。\n\n另记一条门禁抓不到的过期陈述：协议草案 §4 写「DEC-006 / 007 pending 期间」，两条\n实际都已 approved；L10 只抓「等 / 待 / 尚未裁决」措辞，这句不在模式内。该文是\nDEC-009 材料，处置留给 OS Owner，本次未动。\n\n需走 DEC / CHG 的两件已列入 §9 不裁决清单：装载协议是否切出改名发布、走哪条通道、\n谁做 Owner；草案 §4 两个契约由基座实现的排期。\n\n门禁复跑：L3 / L4 / L10 / L13 均为 0，仍只剩既有的 L9；新增的两条跨层链接\n（os.upstream.json、装载与对账协议草案）解析通过。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-18T00:54:12-07:00"}],"HeadCommit":{"Sha1":"f4540e69b1656232b677571584d3bd6ad57217be","Message":"docs(架构): 总架构增 §3.8——基座的装载 / 调用两个方向与接入能力归属\n\n起因是一次实际误读：`c433d57` 被当成「另一个 OS 产品」。它是数字员工OS 仓的提交\nSHA（2026-09-14），由 base-framework-os-product/os.upstream.json 连同 protocol\n1.3.0 钉住，用途是让「上游 OS 走动了」以 O0-SHA 显式变红。与基座并列的不是它，\n是 base-framework-os-product 这个仓——示例产品扩展加两道 OS 门禁，2026-09-10\n随 G26 自框架仓移出以保框架零依赖。误读本身说明这几件事在文档里没写清，本节补上。\n\n**两个方向。** PNG 给基座的定语「理解、编排、调用、执行」对应两个方向相反的接口：\n装载（OS → 应用）已有协议（KERNEL_EXTENSION_PROTOCOL_VERSION = 1.3.0，定义在 OS\n仓 packages/contracts/src/product-manifest.ts），真装 1 个；调用（应用 → OS）基本\n空白——协议草案 §4 已给出 ProductActivationIntent / ToolIntentReceipt 并写明「OS\n应提供、产品不再自建」，2026-09-18 复核 OS 仓 apps/ 下仍无 product-activations\n路由，智服已在自己仓内造了一套。两个方向归属不同，混谈会把落点找错。\n\n**接入形态实测已分叉成五种：** product.manifest.json（示例 / 设备云 / 知识云）、\nmanifest.json（HR，另有 ddl-authority / distribution / readiness 三个独有文件且无\npackage.json）、manifest.ts（工单，另有 kernel.products.entry.json）。只有示例与\n设备云带 os-host 测试配置。\n\n**为什么「每个应用继承一份」今天做不到**（两条方向相反的硬事实）：OS 的包是\n@repo/* 仓内作用域名（@repo/contracts@1.16.0，与工单仓同名包撞名），外仓依赖不了，\n只能照抄；而协议 §2.1 又反向禁止产品导入宿主私有 @repo/*，宿主能力一律由组合根\n注入、产品契约要自包含。由此划边界：可继承的是契约 / Schema / 校验器 / 门禁，不可\n继承的是宿主运行时——搞混会废掉 §2.1 的 fail-closed import 扫描。\n\n**四个落点按依赖方向逐个判定：** 协议与 SDK 由基座以 @juhai/ 发布（合法，阻碍是\n@repo/* 命名）；分发通道归基础设施（合法，DEC-031 已批准，缺口是契约包 pin 无门禁\n——HR 与 OS 停在 rc.1、源仓已 rc.3，不像 kernel 有 L12 守着）；脚手架归框架（合法\n但受零依赖限制，只能给目录形状）；**把装载协议搬进基础设施不合法**——基础设施要\n编码基座契约即反向依赖，撞图 1 的唯一硬约束。本节只判合法性，不选落点。\n\n另记一条门禁抓不到的过期陈述：协议草案 §4 写「DEC-006 / 007 pending 期间」，两条\n实际都已 approved；L10 只抓「等 / 待 / 尚未裁决」措辞，这句不在模式内。该文是\nDEC-009 材料，处置留给 OS Owner，本次未动。\n\n需走 DEC / CHG 的两件已列入 §9 不裁决清单：装载协议是否切出改名发布、走哪条通道、\n谁做 Owner；草案 §4 两个契约由基座实现的排期。\n\n门禁复跑：L3 / L4 / L10 / L13 均为 0，仍只剩既有的 L9；新增的两条跨层链接\n（os.upstream.json、装载与对账协议草案）解析通过。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-18T00:54:12-07:00"},"CompareURL":"luoanwu/platform-governance/compare/34c5fecec1074d5a01acd8b184e70c63c5ed947b...f4540e69b1656232b677571584d3bd6ad57217be","Len":1}
...
created_unix
1789718060
Delete
Cancel