SQLite Web: gitea.db

id

Primary key. INTEGER NOT NULL

user_id

INTEGER

op_type

INTEGER

act_user_id

INTEGER

repo_id

INTEGER

comment_id

INTEGER

is_deleted

INTEGER NOT NULL (default 0

ref_name

TEXT

is_private

INTEGER NOT NULL (default 0

content

{"Commits":[{"Sha1":"1a1b37e4669cfd80f87650050894fede8aee6b90","Message":"test(contracts): 会话准入 planner 的门禁覆盖——20 个可达出口只有 1 个走过，ADMIT 与 SKIP_DUPLICATE 还是同一个结果\n\n同日第一条（5720165）把判定收紧了，但门禁看不到其中绝大部分。对 dist 逐条实测：\nplan() 有 20 个可达出口，check:fixtures 上只走过 1 个（N06 无策略即拒），整张租户策略矩阵\n与 appendRejections 全部 8 行映射都只有单测看着，其中四个出口连单测也没有。\n\n本次判定逻辑一行未改——conversation-message.ts 与 conversation-admission-planner.ts 零改动，\n只动 fixture-evaluator.ts 的可见性，加用例。\n\n1. ADMIT 与 SKIP_DUPLICATE 在夹具里是同一个结果。评估器 plan 分支的判据是 `\"reasons\" in r`，\n   两者都没有 reasons，于是都返回空数组 = ACCEPT。把 ADMIT 全改写成 SKIP_DUPLICATE（或反过来）\n   门禁不会红，而这两者的区别正是「这条消息要不要真的落账」。同一文件里的 append 规则本来就写成\n   「只有 APPEND 算放行」，plan 现在与之同口径：非 ADMIT 即列出出口名。\n\n2. refresh() 在门禁上零覆盖（与公共文件 793d0a1 同形）。planner 三个公开方法里它是唯一没有夹具\n   规则的，版本回退拒绝与坏快照保留 last-known-good 此前只有单测。新增 refresh 规则：\n   applied=true 为放行，否则返回 planner 自己给的 reason。\n\n3. 四个出口此前任何地方都没走过，均补单测：TENANT_NOT_ALLOWED（策略里根本没有这个租户，与\n   「请求跨租户」不是一回事）、CONVERSATION_TYPE_NOT_ALLOWED、SENDER_TYPE_NOT_ALLOWED（凭据与\n   发送者类型配套、策略仍不允许该类型，须与 ACTOR_CREDENTIAL_MISMATCH 分开证明）、\n   CONVERSATION_TENANT_MISMATCH（映射表把 classify 的 TENANT_MISMATCH 换成 planner 自己的码）。\n\n覆盖：夹具 14 例（正 2 / 反 12）→ 39 例（正 4 / 反 35）；定向测试 23 → 30 例，第一轮的断言一条未动。\n并给此前只断言「拒绝」的 N05 / N06 补上 reasons 声明。plan 与 refresh 各留一例放行（P03 / P04）——\n只有放行一侧也钉住，SKIP_DUPLICATE 与 applied 的区分才有意义。\n\n一处明写不覆盖：appendRejections 的 REJECT → MESSAGE_APPEND_INVALID 按当前控制流不可达——\nclassifyConversationAppend 只在 preflight 失败时返回 REJECT，而 plan() 更早就返回了 preflight 拒绝。\n保留该行作纵深防御，但不造用例假装覆盖，理由写进夹具 description 与蓝图。\n\n未做（越界）：会话 / 成员 / 消息账本、长连接服务、Fact、独立运行服务一件未建，C16 按缺失模块完善清单\n仍卡在「裁决 · 实现」（Owner ADR、三消费者、G4）；Catalog 登记一律未动。\n\n证据：真实工作树 pnpm --dir contracts build / typecheck 绿、check:generated 14 files / 12 schemas\n无漂移、node --test contracts/test/*.test.mjs 382/382、contract-collaboration-messaging 夹具 39/39。\n负向实测两次：把 N19 的声明原因改成 ACTOR_CREDENTIAL_MISMATCH → 门禁 exit 1 并点名该例\n（reasons=[\"SENDER_TYPE_NOT_ALLOWED\"]）；把 N13 的 expect 翻成 ACCEPT → 被 id/expect 一致性规则\n先挡下（exit 1）。两次还原后 exit 0。本次不回绑任何 reports/。\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-18T16:01:18-07:00"}],"HeadCommit":{"Sha1":"1a1b37e4669cfd80f87650050894fede8aee6b90","Message":"test(contracts): 会话准入 planner 的门禁覆盖——20 个可达出口只有 1 个走过，ADMIT 与 SKIP_DUPLICATE 还是同一个结果\n\n同日第一条（5720165）把判定收紧了，但门禁看不到其中绝大部分。对 dist 逐条实测：\nplan() 有 20 个可达出口，check:fixtures 上只走过 1 个（N06 无策略即拒），整张租户策略矩阵\n与 appendRejections 全部 8 行映射都只有单测看着，其中四个出口连单测也没有。\n\n本次判定逻辑一行未改——conversation-message.ts 与 conversation-admission-planner.ts 零改动，\n只动 fixture-evaluator.ts 的可见性，加用例。\n\n1. ADMIT 与 SKIP_DUPLICATE 在夹具里是同一个结果。评估器 plan 分支的判据是 `\"reasons\" in r`，\n   两者都没有 reasons，于是都返回空数组 = ACCEPT。把 ADMIT 全改写成 SKIP_DUPLICATE（或反过来）\n   门禁不会红，而这两者的区别正是「这条消息要不要真的落账」。同一文件里的 append 规则本来就写成\n   「只有 APPEND 算放行」，plan 现在与之同口径：非 ADMIT 即列出出口名。\n\n2. refresh() 在门禁上零覆盖（与公共文件 793d0a1 同形）。planner 三个公开方法里它是唯一没有夹具\n   规则的，版本回退拒绝与坏快照保留 last-known-good 此前只有单测。新增 refresh 规则：\n   applied=true 为放行，否则返回 planner 自己给的 reason。\n\n3. 四个出口此前任何地方都没走过，均补单测：TENANT_NOT_ALLOWED（策略里根本没有这个租户，与\n   「请求跨租户」不是一回事）、CONVERSATION_TYPE_NOT_ALLOWED、SENDER_TYPE_NOT_ALLOWED（凭据与\n   发送者类型配套、策略仍不允许该类型，须与 ACTOR_CREDENTIAL_MISMATCH 分开证明）、\n   CONVERSATION_TENANT_MISMATCH（映射表把 classify 的 TENANT_MISMATCH 换成 planner 自己的码）。\n\n覆盖：夹具 14 例（正 2 / 反 12）→ 39 例（正 4 / 反 35）；定向测试 23 → 30 例，第一轮的断言一条未动。\n并给此前只断言「拒绝」的 N05 / N06 补上 reasons 声明。plan 与 refresh 各留一例放行（P03 / P04）——\n只有放行一侧也钉住，SKIP_DUPLICATE 与 applied 的区分才有意义。\n\n一处明写不覆盖：appendRejections 的 REJECT → MESSAGE_APPEND_INVALID 按当前控制流不可达——\nclassifyConversationAppend 只在 preflight 失败时返回 REJECT，而 plan() 更早就返回了 preflight 拒绝。\n保留该行作纵深防御，但不造用例假装覆盖，理由写进夹具 description 与蓝图。\n\n未做（越界）：会话 / 成员 / 消息账本、长连接服务、Fact、独立运行服务一件未建，C16 按缺失模块完善清单\n仍卡在「裁决 · 实现」（Owner ADR、三消费者、G4）；Catalog 登记一律未动。\n\n证据：真实工作树 pnpm --dir contracts build / typecheck 绿、check:generated 14 files / 12 schemas\n无漂移、node --test contracts/test/*.test.mjs 382/382、contract-collaboration-messaging 夹具 39/39。\n负向实测两次：把 N19 的声明原因改成 ACTOR_CREDENTIAL_MISMATCH → 门禁 exit 1 并点名该例\n（reasons=[\"SENDER_TYPE_NOT_ALLOWED\"]）；把 N13 的 expect 翻成 ACCEPT → 被 id/expect 一致性规则\n先挡下（exit 1）。两次还原后 exit 0。本次不回绑任何 reports/。\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-18T16:01:18-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/ffdd21a2ae238023f2bb48a632deaabade5e88f1...1a1b37e4669cfd80f87650050894fede8aee6b90","Len":1}

TEXT

created_unix

INTEGER

Update row 31170 in action