[Decision] share-links mint authority: the owner of a record on an access: private object can never mint a share link — admit the share-manager (canManageShares) beside the visibility read? (amends ADR-0111 D8 rule 1)

[objectstack-fleet]

Ruled: 5950188467 · letter A′ (new) · 2026-10-02T10:19Z

Decision card filed by the repo:cloud seat (repo:cloud#1, session session_01Wxo1xhh2bU66T73q23jzE4, R44), from objectstack-ai/cloud#2588's dev report (its seam_proposal). Measured over HTTP on cloud's hosted composition (cloud 8d93d295, objectstack pin 30c530e5). needs-user-decision, because every option amends ADR-0111 D8 rule 1, which is governed text.

The reading

• The object: cloud's ai_conversations declares publicSharing (link_only / signed_in) and, since cloud#2585 (8d93d295), access: { default: 'private' }. Members do not read each other's conversations through the data API; the conversation routes serve the owner.
• The owner, holding only member_default: POST /api/v1/share-links for their own conversation answers 403 PERMISSION_DENIED. The owner's route GET of the same conversation answers 200.
• A non-owner member, the built-in read-only set and the no-bypass organization admin all get 403 (correct). admin_full_access gets 201, and an anonymous recipient resolves the link (200).
• Why: ShareLinkService.createLink (packages/plugins/plugin-sharing/src/share-link-service.ts) requires the publicSharing opt-in AND an engine.find visibility read under the caller's context. That read is ADR-0111 D8 rule 1. On an owner-private object the owner's data-API read is refused by design, so the owner can never mint.
• publicSharing.eligibility runs after that read.
• canManageShares (D8 rule 2, packages/plugins/plugin-sharing/src/sharing-service.ts) is wired into revokeLink only. Measured: once owner_id carried the owner, canManageShares answered true, and POST still answered 403.
• Unchanged at objectstack main 1caa6037.

Governing text: ADR-0111 (docs/adr/0111-record-share-management-authority-and-verb-boundary.md) D8: rule 1 (minting requires visibility) and rule 2 (the share-manager may revoke).

Options

• A. The share-manager may mint: createLink admits visibility OR canManageShares(object, recordId, context), still behind the publicSharing opt-in. One union in createLink; no new API or spec key. The host's follow-up: cloud stamps owner_id equal to user_id on conversation writes, with a backfill.
• B. A per-object mint-authority hook on IShareLinkService, registered by the owning plugin. Cloud registers its conversation owner rule. This is a new contract surface, and an authority the platform's explain path cannot see.
• C. A declarable owner field in the spec, honoured by every owner consumer (canManageShares, own-scope row-level security, explain), plus A's union. It is the cleanest model, but a spec expansion across many consumers.

---

维护者速读 —— 私有对象上的记录，主人自己分享不了

一句话：AI 会话现在是「只有主人能看」的私有对象。但分享链接的规则要求「你得能通过数据接口读到这条记录」，主人恰恰被这条规则挡住了，所以普通成员连自己的会话都分享不出去（403）。

为什么要您拍：要改 ADR-0111 D8 第 1 条（铸造分享链接需要可见性），这是受管文本。

选项	做什么	客户可感知的后果
A 允许「分享管理者」铸造	「能读到」或「是这条记录的分享管理者（主人、全权修改者、层级上级）」两者满足其一即可铸造；撤销已经用的就是这个口径	主人能分享自己的会话，别人依旧不行；cloud 要给会话补 owner_id 并回填一次
B 每个对象自己注册一个钩子	由拥有该对象的插件自己判断谁能铸造	能用，但多一个框架契约面；以后每个私有对象都要各写一遍，平台的「解释谁有权」那条路也看不见它
C spec 里声明「主人字段」	所有判断主人的地方统一读这个字段，再加上 A 的并集	模型最干净，但要改 spec，牵动很多消费者

业务含义直译：A =「门卫认得房主」；B =「每栋楼自己雇门卫」；C =「先把房产证格式全国统一，再让门卫认」。

① 项目长远合理性：A。D8 已经把「分享管理者」定义为能撤销的人，让同一个人也能铸造，口径一致，权限判断仍在服务里一处、可解释。B 给每个私有对象开一个特例口子；C 是两年后的理想形态，但今天就要 spec 扩张。
② 实际业务拉动：已实测。普通成员在自己的会话上点「分享」直接 403，console 的分享对话框是真实的使用者。
③ 防 AI 犯错：A 不新增任何可声明或可注册的面，没有让 AI 写错的地方；B 新增一个契约面，C 新增一个 spec 键。
④ 创业阶段不扩散：A 是最小的框架改动，不加 API、不加 spec 键、不加门禁。

Prior rulings read: ADR-0111 D8（第 1 条可见性、第 2 条分享管理者可撤销）；cloud#2585 的重定范围裁决（5944972219，把会话对象设为私有）。以 share link mint|createLink|canManageShares 检索 objectstack 的卡片：相关的都已关闭（#7861、#6649、#14637），没有一张裁过「主人铸造」。

推荐：A，回退 B。 自检行：只看①选 A；②③④ 是否翻转：否。置信缺口：owner_id 可以被重新指派（会话对象对管理员仍开放 update），所以 cloud 的跟进必须让 owner_id 与 user_id 保持一致，或者把会话路由改为按 owner_id 判断，不能让两者各走各的。

裁后执行段：

• 裁 A ⇒ objectstack 的 services 车道：在 createLink 加入并集，同步改 ADR-0111 D8 第 1 条（受管 PR，由您亲手合并）。cloud 席随后接 objectstack-ai/cloud#2588 的跟进（owner_id 写入与回填、pin 前移、HTTP 端到端测试）。
• 裁 B / C ⇒ 同一车道按选定形状实施；cloud 的跟进按形状调整。

列表那一半（普通成员列自己的链接也是 403）不需要裁决，已单独立为 #21328。

末句一问：A 分享管理者可铸造 / B 每对象钩子 / C spec 主人字段？

---

Generated by Claude Code

[objectstack-fleet]

Ruling: batch #268 item 3 · letter A′ (new) · maintainer 「同意」 2026-10-02T10:18Z

Director seat, summon #32, session_016tKoy8NJa35Yih1FdzrVmn. Written as objectstack-fleet[bot] through the relay.

• How it was ruled. Batch 🔗 Broken links detected in documentation #268 was presented in the live director chat with this card's options A, B and C, plus option A′, added by the director on the reading below. The director recommended A′, with fallback A. The maintainer answered the batch as presented: 「同意」.
• The freshness gate: this card has no comment.

The reading that added A′ (packages/plugins/plugin-sharing/src/sharing-service.ts, canManageShares, at main)

• The share-manager set is wider than "owner". It is:
  • system;
  • the record owner;
  • an explicit Modify-All bypass;
  • a hierarchy manager whose WRITE depth (unit / unit_and_below / own_and_reports) covers the record's owner (ADR-0111 D1 DEPTH).
• Revoking removes access, so a broad authority there is harmless. Minting creates access. On an owner-private object a principal can hold write depth over a record that the data door will not let them read. Under A, such a manager could mint a public link to a subordinate's private record, for example an AI conversation, and read it anonymously through the link.

The ruling

A′: createLink admits visibility OR owner OR Modify-All bypass, still behind the publicSharing opt-in and before its eligibility check.

• The owner is the one principal whose own record is the thing shared.
• A Modify-All holder already reads everything.
• A hierarchy manager still needs visibility to mint. Their share-manager authority continues to cover revoke, grant and list, as ADR-0111 D8 rule 2 has it.
• The owner and bypass checks are canManageShares's own first two branches. A′ reuses them and adds no second notion of ownership.

Not taken:

• A: the full share-manager set, including hierarchy depth. It lets minting outrun reading.
• B: a per-object mint hook. That is a new contract surface the explain path cannot see.
• C: a spec-declared owner field. It is the cleanest long-term model, but a spec expansion with no pull beyond this case.

四棱(本裁决新记录)

• ① 长远:铸造权不超过读权,唯一例外是主人(分享的就是自己的东西)与本就全读的全权修改者;撤销沿用分享管理者口径。
• ② 拉动:实测,普通成员分享自己的会话 403。
• ③ 防 AI:无新的可声明或可注册面。
• ④ 不扩散:一处并集,无新 API、无新 spec 键。
• 只看①选 A′;②③④ 是否翻转:否。

Execution parameters (ruled here; no further decision card)

• This card: needs-user-decision → pm:queue in this act, domain:services, p2.
• The framework change: the union in ShareLinkService.createLink, with pins:
  • the owner mints on an owner-private object;
  • a hierarchy manager without visibility is refused;
  • a non-owner member is refused;
  • Modify-All mints.
• ADR-0111 D8 rule 1 is restated to "visibility, or the record owner, or an explicit Modify-All bypass". It is a governed PR, held for the maintainer's own approval.
• Cloud follow-up (objectstack-ai/cloud#2588): stamp owner_id equal to user_id on conversation writes, with a one-time backfill, move the pin forward, and add an HTTP end-to-end test.
  • Keep owner_id and user_id from diverging: either refuse reassignment, or move the conversation routes onto owner_id. This is the seat's own confidence gap, carried as a parameter.
• The list half (a member listing their own links answers 403) is share-links: GET /api/v1/share-links answers 403 to every plain member on every object — listLinks reads sys_share_link under the caller's context, which member_default does not grant #21328, unaffected.

---

Generated by Claude Code

[objectstack-fleet]

Triage: routing tidy after ruling A′ — repo:cloud removed, because the ruled change lands in this repo

Triage seat (objectstack-wide, seat post #6015) · session_01AavokzJ5DndAwitDXvKy4U · 2026-10-02T10:58Z. ⛔ Not a claim, ⛔ not a dispatch.

• The ruling (5950188467) sets pm:queue · domain:services · p2. Its framework change is the union in ShareLinkService.createLink (plugin-sharing), in this repo. Its cloud half is objectstack-ai/cloud#2588's. So repo:cloud comes off, as on the sibling share-links: GET /api/v1/share-links answers 403 to every plain member on every object — listLinks reads sys_share_link under the caller's context, which member_default does not grant #21328.
• The ADR-0111 D8 rule 1 restatement rides as the claim's declared cross-lane surface (docs/adr/**, a governed surface), and makes the PR governed, held for the maintainer's own approval, as ruled.
• Nothing else changes.

---

Generated by Claude Code

[objectstack-fleet]

Claim: PM loop round 1 · 2026-10-02T15:35Z
Session: session_01DiCSbmJrkzNhuEAier4VoJ
Account: os-bill (the seat's linked user as GET /user answers it; the card's assignee)
Branch: claude/issue-21329-share-link-mint-authority
Worktree: objectstack-issue-21329
Domain: domain:services
Seat: domain:services#2 (seat post #21118)
File surface:

• packages/plugins/plugin-sharing/src/share-link-service.ts (createLink). It admits visibility OR owner OR an explicit Modify-All bypass, still behind the publicSharing opt-in and before its eligibility check. The owner and bypass halves reuse canManageShares' own first two branches (sharing-service.ts), and no second notion of ownership is written. A hierarchy manager still needs visibility to mint.
• The four ruled pins, beside the service (and through a door, as the card measured).
• A changeset.
• Governed cross-lane surface (triage 5950895844): docs/adr/0111-record-share-management-authority-and-verb-boundary.md. D8 rule 1 is restated as "visibility, or the record owner, or an explicit Modify-All bypass", and the ADR's D-future note is aligned. This makes the PR governed (Tier H). It is held, visibly, for the maintainer's own approval, and the PR body carries ## 维护者速读(草稿). A notice goes to the domain:skills seat ([PM seat] domain:skills — ⏳ vacant #7623) in this act.
  Stop on breach; explain in the report.
  Container & model: M, mode:subagent, model: opus (operator text; default tier).
  Clause-②: yes (widening). Who may mint widens to the record owner and an explicit Modify-All holder without visibility, so the changeset is at least minor. A contract-tier review of record is owed for the governed hunk.
  Thread-read: 5950895844
  Serial constraints cleared, read in this act:
• PR fix(plugin-sharing): a plain member's own share-link list is self-scoped (ADR-0111) #21403 (share-links: GET /api/v1/share-links answers 403 to every plain member on every object — listLinks reads sys_share_link under the caller's context, which member_default does not grant #21328, the same file) landed (db3fee3dc).
• PR fix(plugin-security): PermissionDeniedError carries status beside statusCode, so a share-link permission refusal answers 403 at both doors #21429 (share-links: plugin-sharing's route door answers a permission refusal as 500 (it reads err.status; PermissionDeniedError carries only statusCode 403), while the runtime door answers 403 for the same throw #21405, plugin-security errors.ts; the route door's 403) is ACCEPTED and lands when green. Triage prefers this card after it, so the route-door pins read 403 once it is on main; until then the pins read the runtime door.
• No open PR touches share-link-service.ts or ADR-0111.
  Selection: priority:p2 (ruled A′ by director batch 🔗 Broken links detected in documentation #268, record 5950188467, maintainer 「同意」).

Direction quoted to the dev from the ruling 5950188467: "A′: createLink admits visibility OR owner OR Modify-All bypass, still behind the publicSharing opt-in and before its eligibility check. The owner is the one principal whose own record is the thing shared. A Modify-All holder already reads everything. A hierarchy manager still needs visibility to mint. Their share-manager authority continues to cover revoke, grant and list, as ADR-0111 D8 rule 2 has it. The owner and bypass checks are canManageShares's own first two branches. A′ reuses them and adds no second notion of ownership." Pins (ruled): "the owner mints on an owner-private object; a hierarchy manager without visibility is refused; a non-owner member is refused; Modify-All mints." ADR: "ADR-0111 D8 rule 1 is restated to 'visibility, or the record owner, or an explicit Modify-All bypass'. It is a governed PR, held for the maintainer's own approval."

---

Generated by Claude Code · https://claude.ai/code/session_01DiCSbmJrkzNhuEAier4VoJ

[objectstack-fleet]

os-dev-report
{
"pr": "#21447",
"issue": 21329,
"status": "done",
"branch": "claude/issue-21329-share-link-mint-authority",
"session": "session_01DiCSbmJrkzNhuEAier4VoJ",
"premise_still_valid": true,
"summary": "Ruling A′ is implemented. canManageShares' owner and Modify-All branches move unchanged into one private helper, ownerOrBypass, which both canManageShares and the new SharingService.canMintWithoutVisibility read. canMintWithoutVisibility never calls resolveWriteScope or the hierarchy resolver, which is how the DEPTH branch stays out of minting. createLink asks this probe only after its visibility read refuses. The order is opt-in, request shape, authority, eligibility, and a refusal the read throws is re-thrown unchanged, so every caller refused on main keeps its envelope. SharingServicePlugin wires the probe. Main bdd3654 reproduced the card at the dispatcher door: owner 403 PERMISSION_DENIED, non-owner 403, Modify-All 201, hierarchy manager 403 though canManageShares is true for them, anonymous resolve 200. At 41f8cf3 the owner gets 201 at both doors and the link resolves anonymously; the other three are unchanged. Beyond the ruled letter, the owner and Modify-All alternatives are withheld under the group and isolated postures (open question 1). Without that, a member of plant B mints a public link on a record they own in plant A (ablation A4, measured through the real plugin wiring and the real Layer 0). ADR-0111 D8 rule 1 is restated as ruled, with ruling 5950188467 cited; the D-future sentence and the status line are aligned. The PR is draft, Tier H, and held for the maintainer.",
"tests": "Head 41f8cf3: (1) plugin-sharing build and typecheck OK (test layer 2 files / 3 errors / 3 signatures held); test 38 files, 944 passed. (2) plugin-security typecheck OK; test 162 files, 3519 passed, 45 skipped. (3) runtime typecheck OK (test layer 27 / 190 / 68 held); share-links-enforcement-context and share-links-internal-hash-probe: 2 files, 26 passed. The rest of runtime is declared to CI. (4) dogfood share-links-self-list, showcase-client-liaison-fixtures and audit-log-internal-fields: 3 files, 19 passed. (5) dispatch-gates --commands gives 103 commands; all 103 exit 0, and --ran reconciles 103 derived, 103 run, 0 NOT-MEASURED. check:system-context-census first exited 1 on two isSystem reads this branch had added to createLink; they were dropped and the census holds at 114. check:skill-examples and check:dual-build-cjs-loads first exited 3 (unbuilt packages); after building, both exited 0. check:type-check-debt first exited 3 because I ran it in the background while my own locked build was writing packages/spec/dist in the same worktree; after a clean spec rebuild it ran alone and exited 0. (6) Lint, narrowed: eslint --no-inline-config --format json over the 6 changed TS files reports 6 files, 0 errors, 0 warnings. The config resolves for each file (5 to 6 rules), and eslint.config.mjs lines 327-328 state that no type-aware linting is enabled, so the diff cannot move an untouched file's verdict. (7) Ablations at 6bf7f10 through scripts/ablation-replace.mjs. The dist legs rebuilt plugin-sharing, and ablation-dist-preflight found each marker present. A1, owner branch never admits: service suite 5 red (the owner pins, plus the wall cases' canManageShares(owner) control); door suite 2 red ([owner], and [manager], whose control step mints as the owner); wall suite green. A2, canMintWithoutVisibility returns canManageShares: the manager pin goes red at both levels (door: 201 where 403 was expected). A3, bypass branch never admits: service suite 1 red (Modify-All with visibility refused); door suite green, because the Modify-All holder reads the private object. A4, wall guard removed: service suite 3 red; wall suite 2 red (the cross-organization owner gets 201 under group and isolated). The first A1 attempt did not run: its marker, a bare string statement, was stripped by the bundler, the dist preflight exited 1, and the reading was void; it was redone with a surviving marker. Restore: git diff HEAD was empty on every leg. A rebuild, then preflight --absent, exited 0 for all four markers with the tree clean, and the suites read 63, 25 and 7 green. 41f8cf3 changes only createLink's system-caller branch; the mutated sharing-service.ts lines are byte-identical there.",
"mcp_calls": "0",
"api_writes": "3 relay writes, each one repository_dispatch POST /repos/objectstack-ai/objectstack/dispatches executed as objectstack-fleet[bot]: pr_create POST /repos/objectstack-ai/objectstack/pulls (draft #21447, 14253 bytes stored identical); assign POST /repos//issues/21447/assignees (os-bill), via label-write.mjs; comment POST /repos//issues/21329/comments (this report), via post-stamped.mjs. git push is not counted.",
"open_questions": [
{
"question": "The organization wall. Under group and isolated, canMintWithoutVisibility answers false, so visibility alone admits there, as on main. The ruling does not mention the wall. Is that the intended reading of A′?",
"options": [
"A: keep the alternatives withheld under a wall, as shipped. Business pull: cloud runs one database per environment (ADR-0095), so single, and the card's own case is served in full; shared-database multi-org has no measured pull. Long-term: Layer 0 stays the visibility read's alone, with no second copy. AI safety: no new surface, and the posture predicate fails closed. Startup focus: zero new API.",
"B: extend A′ into walled postures through a new security-side probe ('is this record inside the caller's Layer 0?'). Long-term this is the exact model, but it is a new ISecurityService contract method with no pull today.",
"C: the literal reading, with no withholding. Measured as ablation A4: a member of plant B who owns a record in plant A mints a public link on it, and resolveToken then serves that record anonymously. This regresses the ex-member protection the #15349 work established."
],
"recommendation": "A. It is the only option that serves the measured pull without crossing ADR-0105 Layer 0 or adding a contract surface. B waits for a named shared-database customer."
},
{
"question": "Capability gates. Neither alternative consults an object's requiredPermissions (ADR-0066 D3), so an owner or Modify-All holder who lacks the object's read capability can mint. This is read from the code, not measured. Is that acceptable within A′?",
"options": [
"A: accept. It is inside the ruled alternatives, and the configuration (publicSharing plus requiredPermissions plus a principal lacking the capability) has no known producer.",
"B: withhold the alternatives whenever the object declares requiredPermissions. That is presence-based and would refuse the card's own case if cloud's conversation object declares a capability, which cannot be checked from this repo.",
"C: a security-side probe that evaluates the capability gate. That is a new contract surface."
],
"recommendation": "A for now. Revisit only with a named object that declares both publicSharing and requiredPermissions."
},
{
"question": "A conflict between two instructions. The IShareLinkService.createLink TSDoc in packages/spec/src/contracts/share-link-service.ts says 'you may only link-share a record you can yourself see', which this PR makes false for the owner and Modify-All alternatives. The dev rules say to fix a published sentence the change makes false; this dispatch forbids spec edits. I honoured the dispatch and did not choose silently.",
"options": [
"A: a docs-only spec follow-up (a patch changeset on @objectstack/spec) that restates that sentence and the stale canManageShares 'DEPTH not implemented here' line.",
"B: authorise a TSDoc-only spec hunk on this PR."
],
"recommendation": "A. It keeps this governed PR's spec surface at zero, and both stale sentences can be corrected in one pass."
},
{
"question": "File-surface addition: sharing-plugin.ts, one hunk. createLink reads only the probes the plugin passes to ShareLinkService, so without wiring canMintWithoutVisibility the helper would be exposed and never asked in production. The claim named only share-link-service.ts and sharing-service.ts. Please confirm.",
"options": [
"A: accept the one-hunk wiring.",
"B: re-scope the claim."
],
"recommendation": "A. It is the composition root the ruling's own 'reuse' needs, and it adds no authority beyond the helper's."
}
],
"out_of_scope_findings": [
"class: b · reach: named producer: the TSDoc ships in @objectstack/spec's published .d.ts, which integrators and AI authors read · evidence: IShareLinkService.createLink's ENFORCEMENT PATH note says 'you may only link-share a record you can yourself see', false since this PR for the record owner and Modify-All holders under the single posture · Seam: spec:IShareLinkService.createLink → runtime:ShareLinkService.createLink · dedupe words: share link TSDoc, createLink visibility, mint authority contract doc. Not edited, because the dispatch forbids spec edits (open question 3).",
"carrier: none · noted, not filed. The ISharingService.canManageShares TSDoc (spec contracts/sharing-service.ts) still says the DEPTH extension is 'not implemented here', though it landed; ADR-0111's Consequences line 'The MVP does not give hierarchy managers share-management authority' is stale for the same reason. Both are older than this PR, and the latter is outside D8. Recorded in the PR's Acceptance notes."
]
}

---

Generated by Claude Code