Grant `manage_org_presentation` to `tenant_admin` once the capability ships in a released @objectstack line

[os-zhuang]

Part of objectstack-ai/objectstack#12701. Chartered by maintainer, 2026-08-27, live PM chat, verbatim: 「发版后把 tenant_admin 那格补上创建卡片」.

What this card does (small, mechanical once unblocked)

src/profiles/tenant-admin.profile.ts (landed in #1362) deliberately dropped the metadata-authoring vocabulary (customize_application / manage_profiles / manage_roles) because the platform's only metadata key was platform-scoped. objectstack-ai/objectstack#12702 (merged via PR #12705) added the org-scoped subset key manage_org_presentation — admits /meta item writes only for allowOrgOverride: true types org-scoped to the caller's own active organization.

When that capability is installable by this repo (hotcrm consumes released @objectstack/* versions, never git pins — the lane's install-surface rule):

1. Bump @objectstack/* dependencies to the release line carrying manage_org_presentation (verify with the probe below, not the changelog).
2. Add manage_org_presentation to TenantAdminProfile.systemPermissions (SaaS composition only; community system_admin untouched — it already holds the wider manage_metadata-era vocabulary).
3. Extend test/saas-composition.test.ts: the profile pin currently asserts tenant_admin holds no scope: 'platform' capability — keep that, and add the positive assertion that manage_org_presentation is granted and is declared scope: 'org' in the installed PLATFORM_CAPABILITIES.
4. Changeset (minor).

Restart-when (executable, checked by the daily hold scan)

Restart-when: node -e "const c=require('@objectstack/spec/package.json').version; const {PLATFORM_CAPABILITIES}=require('@objectstack/spec/security'); process.exit(PLATFORM_CAPABILITIES.some(x=>x.name==='manage_org_presentation')?0:1)" exits 0 after a pnpm update of @objectstack/* to the newest released line in a scratch checkout — i.e. the capability is present in the newest released @objectstack/spec, not merely on main.

Version releases are a human act (AGENTS.md release act); this card wakes on the release, it never asks for one.

[objectstack-fleet]

Release: session session_01X8U3asekbiC7yWoEPWR4Dg · reason: the delivering PR #1882 returns 404 (unreadable; consistent with a banned author) and main does not carry the grant · destination: pm:queue, unassigned (assignee os-musk removed), on the maintainer's confirmation of re-triage group 2 · 2026-09-24T23:31Z

• src/sales/profiles/tenant-admin.profile.ts:124-131 has no manage_org_presentation, and :105 still cites objectstack#12702 (closed).
• The capability ships in the installed @objectstack/spec@17.4.0 (dist/system/index.js), so the card's own Restart-when: holds.
• ⛔ This is a permission-boundary change: the new PR is requested for maintainer review and is not enqueued by the seat.

The seat post's serial lock on tenant-admin.profile.ts (held for PR #1882) is released with this line. All three earlier comments on this card are unreadable (author 404).

---

Generated by Claude Code

[objectstack-fleet]

repo:hotcrm seat, session_01X8U3asekbiC7yWoEPWR4Dg · half-state record · 2026-09-24T23:36Z

⚠️ The release above landed only partly: labels moved, the assignee could not be removed

The relay run (objectstack Actions run 36073214139) wrote labels_add pm:queue → 200 and labels_remove pm:dispatched → 200, then DELETE /issues/1369/assignees (os-musk) → 404 Not Found. Not retried. This fits the same author-404 pattern as the delivering PR #1882 and this card's three unreadable comments: the account appears to be unavailable, and the API cannot remove it.

Card state now: pm:queue, assignee os-musk still shown. ⛔ Not dispatchable while an assignee is present. The maintainer is asked to clear the assignee from the GitHub UI; the seat dispatches only after that reads back empty.

---

Generated by Claude Code

[objectstack-fleet]

Maintainer-action: clear the assignee os-musk from this card in the GitHub UI — done when GET /repos/objectstack-ai/hotcrm/issues/1369 answers "assignees": []

pm:queue → pm:awaiting-maintainer. repo:hotcrm seat, session_01ER8ntXZhYebyQ66aXWdjfT, 2026-10-02T21:58Z.

• Why this is a state, not a stray: a pm:queue card never carries an assignee, so since 5824054914 (2026-09-24T23:36Z) this card has been a half-state that no seat can dispatch.
• What was retried: one more unassign through the fleet relay, objectstack Actions run 37069823424. It concluded failure, the card still reads assignees: ["os-musk"], and the run log is unreadable from this container (the log host answers 403). This matches the earlier 404 on the same DELETE. ⛔ It will not be retried again.
• When it clears: the card returns to pm:queue as it stands. Its own Restart-when: already holds (the capability ships in the installed spec, per 5824000294), so the next repo:hotcrm seat dispatches it directly.
• ⛔ Permission boundary: the change grants manage_org_presentation to tenant_admin. When it is dispatched, the PR stays a draft for your review, and the seat does not enqueue it.

---

Generated by Claude Code

[objectstack-fleet]

Claim: PM loop round R71, a takeover of this card from the banned account os-musk
Release: account os-musk, which still sits in this card's assignees; it holds no live claim (its delivering PR #1882 returns 404, per 5824000294) · reason: the account is banned and cannot act · destination: this seat, below · provenance: the maintainer, in the repo:hotcrm seat's own chat (session_01ER8ntXZhYebyQ66aXWdjfT) at 2026-10-03T03:06Z, verbatim 「1369 你也帮我处理这个账户已经被封号了。」 and 「musk已经被封号了，你能帮我处理这个issue吗」
Session: session_01ER8ntXZhYebyQ66aXWdjfT
Account: hotlong (the seat's linked user as GET /user answers it; always the card's assignee)
Branch: claude/issue-1369-tenant-admin-org-presentation (new; PR #1882's branch is unreadable)
Worktree: hotcrm-issue-1369
Domain: repo:hotcrm (single-lane repo, no domain:* taxonomy)
Seat: repo:hotcrm#1
File surface: src/sales/profiles/tenant-admin.profile.ts (the systemPermissions list only); test/saas-composition.test.ts; one .changeset/1369-*.md (stop on breach; explain in the report)
Container & model: S, mode:subagent, model: default (dispatch-gates --tier --repo objectstack-ai/hotcrm answers "no path-derived mandate … the tier stays the PM's per-card judgment call"; a permission boundary, so not the floor tier)
Clause-②: no. The change adds one capability that the installed @objectstack/spec already declares to the app's own tenant_admin profile. It touches no published schema and no accept set. It is a permission widening, and the landing ruling below covers it.
Thread-read: 5962132402
Serial constraints cleared: no open PR touches src/sales/profiles/** or test/saas-composition.test.ts. The open PRs are #1950 (src/sales/objects|views|flows, docs/STATUS.md, objectstack.composition.ts), #1953 (the ratchet script and its tests), and three dependabot PRs (package.json and the lockfile).

Handover record

• Last pushed sha: none readable. PR feat(profiles): tenant_admin gains the org-scoped presentation authority #1882 returns 404 and main does not carry the grant (5824000294). The work restarts from main at 25cd8d78.
• Status: the card's Restart-when: holds, because the capability ships in the installed spec (5824000294).
• The assignee half-state behind 5962132402 is resolved as far as the relay allows:
  • the card is back to pm:dispatched and assigned to hotlong;
  • os-musk stays listed only because every unassign of that banned account fails at the relay (runs 36073214139 and 37069823424).
  • ⛔ Read hotlong as the holder. os-musk is a stale entry and holds nothing.

Landing changes from 5962132402, with provenance

• 5962132402 said the PR would stay a draft for the maintainer's review.
• In the seat's chat at 2026-10-03T03:11Z, the maintainer was asked who lands this permission-boundary change once its PR is reviewed. The answer was verbatim 「席位落地」, chosen over the recommended "you merge it by hand".
• This seat therefore lands it: after review passes and CI is green, it enqueues the PR.

---

Generated by Claude Code

[objectstack-fleet]

os-dev-report

{
  "issue": 1369,
  "status": "blocked",
  "branch": "claude/issue-1369-tenant-admin-org-presentation",
  "pr": null,
  "session": "session_01ER8ntXZhYebyQ66aXWdjfT (subagent; parent seat's id)",
  "premise_still_valid": true,
  "summary": "Blocked at the identity probe, before any edit: the claimed branch is NOT new. refs/heads/claude/issue-1369-tenant-admin-org-presentation already exists on objectstack-ai/hotcrm at d586eed9 (author 'Claude', session 01RwAtm5cvUoTSS48DVvwc3V = os-musk's, message 'feat(profiles): tenant_admin gains the org-scoped presentation authority', touches the pre-move path src/profiles/tenant-admin.profile.ts plus .changeset/tenant-admin-gains-org-presentation.md). It is readable, so the claim's line '(new; PR #1882's branch is unreadable)' is false; it is almost certainly PR #1882's head. GET pulls?head=objectstack-ai:claude/issue-1369-tenant-admin-org-presentation&state=all answers [] and GET pulls/1882 answers 404 (hidden PR). Pushing a fresh branch from origin/main 25cd8d78 is rejected '! [rejected] ... (non-fast-forward)', push exit 1, remote tip unchanged at d586eed9. Every route I could take alone breaks a hard rule: force-push is forbidden in hotcrm; branching from d586eed or merging it is the recovery the dispatch forbids; another branch name breaks the claim's identity line (and I may not post a second claim). So I made no edit, opened no PR, and took the read-only measurements below so that the re-dispatch can go straight to the edit. The card's premise holds: the capability ships in the installed spec 17.6.0 with scope 'org'.",
  "tests": "No gate run: there is no diff (blocked before the first edit). NOT MEASURED: pnpm verify, reason: no change exists to verify. Read-only readings on worktree /home/user/hotcrm-issue-1369 at HEAD 25cd8d78 (= origin/main, BASE), after a bare `pnpm install` (exit 0, 'Lockfile is up to date', git status clean afterwards). (H2) The card's Restart-when probe, verbatim: PROBE_EXIT=0. The entry, verbatim: {\"name\":\"manage_org_presentation\",\"label\":\"Manage Organization Presentation\",\"description\":\"Author per-organization presentation overlays — the metadata types whose registry entry declares allowOrgOverride — scoped to the caller’s own organization.\",\"scope\":\"org\"}, spec 17.6.0, 9 entries. Positive control manage_metadata → scope 'platform'; negative control manage_org_presentation_zzz → undefined. (H1) Confirmed: src/sales/profiles/tenant-admin.profile.ts:124-131, systemPermissions = view_setup, manage_org_users, view_all_data, modify_all_data, manage_sharing. (H3) Confirmed: test/saas-composition.test.ts:203 'grants NO platform-scoped capability' reads the installed registry live (scopeOf built from PLATFORM_CAPABILITIES at :193), so the grant leaves it green by construction; the positive assertion belongs beside the :195 manage_org_users test. (H4) No existing hotcrm test reaches the evaluator (git grep for metaWriteCapabilityVerdict|manage_org_presentation|allowOrgOverride: 0 hits, exit 1). A one-off scratch script (outside the repo, not a test file) called the enforcing function, metaWriteCapabilityVerdict from the installed @objectstack/metadata-core (transitive dep, not in hotcrm's package.json), operation 'save': with today's list, every case is DENIED. With manage_org_presentation added: view, dashboard and report with an active org are ALLOWED; the same three without an active org stay DENIED; object and flow (allowOrgOverride=false) stay DENIED with or without an org. This proves the evaluator's verdict for this permission list. It does NOT prove that a booted SaaS composition threads this profile into the session; no boot was run. Ancestry, two legs (repo not shallow): merge-base --is-ancestor d586eed origin/main → exit 1; control leg, its parent 637fc4f4 → exit 0.",
  "token": "src/sales before (node scripts/check-source-token-ratchet.mjs, exit 0, on 25cd8d78): '✓ src/sales business semantics ~53,433 tokens (ceiling ~55,000; headroom ~1,567).' · '✓ src/sales interaction layer ~27,646 tokens (ceiling ~31,000; headroom ~3,354).' · '✓ src/sales authored total ~96,558 tokens (ceiling ~100,000; headroom ~3,442).' src/sales/profiles counts in the authored total only ('not in a headline layer'). After: NOT MEASURED, because nothing was edited.",
  "files_changed": [],
  "deviations": [
    "The dispatch's Branch: (NEW) premise does not hold. The ref exists at d586eed9, so the step-one push probe was rejected non-fast-forward and I stopped before any edit, as the rules require.",
    "For the re-dispatch, the claim's file surface is too narrow. It says 'the systemPermissions list only', but the same file's docstring at src/sales/profiles/tenant-admin.profile.ts:94-107 ('What is deliberately DROPPED' plus 'Blocked-by: objectstack-ai/objectstack#12702 … When that capability ships, the tenant admin gains it here and this paragraph shrinks to a grant') becomes false the moment the grant lands. Under 'a change that makes a statement false must fix it', that paragraph has to be in the surface."
  ],
  "mcp_calls": "0",
  "api_writes": "1 — POST /repos/objectstack-ai/hotcrm/issues/1369/comments (this os-dev-report, through post-stamped.mjs and the fleet relay). The rejected `git push` is not a REST write and changed nothing on the remote. Reads only: GET issues/1369, GET issues/1369/comments, GET pulls?head=…&state=all, GET pulls/1882 (404).",
  "open_questions": [
    {
      "question": "The claimed branch name claude/issue-1369-tenant-admin-org-presentation is occupied by the banned account's stale ref at d586eed9 (very likely PR #1882's head). Which route should the re-dispatch take?",
      "options": [
        "A. The seat deletes the stale remote ref, then re-dispatches under the existing claim 5965009740 unchanged. Cost: one destructive act on another actor's artifact, the ref of a hidden PR (refs/pull/1882/head likely keeps the object), and it is unknown whether the fleet relay carries a ref delete.",
        "B. The seat posts a fresh Claim: naming a new branch, e.g. claude/issue-1369-tenant-admin-org-presentation-r71, and widens the File surface to cover the docstring at :94-107. Then it re-dispatches. Cost: one comment write; the stale ref stays as clutter. Nothing is destroyed, no other actor's state is touched, and history and attribution stay clean.",
        "C. Authorise the dev to build on origin/main and then run `git merge -s ours origin/claude/issue-1369-tenant-admin-org-presentation`. That makes the push fast-forward under the same name, with no force and none of the old content. Cost: the PR's commit list carries the banned account's d586eed, and a default squash message would carry its text and its foreign Claude-Session trailer into main."
      ],
      "recommendation": "B. It is the only route that needs no destructive write and adopts no foreign commit, and it costs one comment. The re-claim is also the natural place to widen the file surface to the docstring paragraph that the grant falsifies. With the readings above, the re-dispatch is a few-minute edit: one array entry with a comment, the docstring paragraph reduced to a grant, the positive scope 'org' assertion read from the installed PLATFORM_CAPABILITIES, a minor changeset, then pnpm verify."
    }
  ],
  "out_of_scope_findings": [
    "carrier: the hotcrm seat (claim author) · noted, not filed: claim 5965009740 states '(new; PR #1882's branch is unreadable)', but the branch is readable at d586eed9 and occupies the claimed name. Also left in place: the shared .git now holds refs/remotes/origin/claude/issue-1369-tenant-admin-org-presentation from my targeted fetch (a remote-tracking ref only; harmless)."
  ]
}

---

Generated by Claude Code

[objectstack-fleet]

Claim: PM loop round R71, a re-claim that corrects the branch line of 5965009740
Session: session_01ER8ntXZhYebyQ66aXWdjfT
Account: hotlong (the seat's linked user as GET /user answers it; always the card's assignee)
Branch: claude/issue-1369-tenant-admin-org-presentation-r71 (new; GET git/ref/heads/…-r71 answers 404)
Worktree: hotcrm-issue-1369
Domain: repo:hotcrm (single-lane repo, no domain:* taxonomy)
Seat: repo:hotcrm#1
File surface: src/sales/profiles/tenant-admin.profile.ts, covering the systemPermissions list AND the docstring paragraph "What is deliberately DROPPED … Blocked-by: objectstack-ai/objectstack#12702 … this paragraph shrinks to a grant" (:94-107 on 25cd8d78), which the grant makes false; test/saas-composition.test.ts; one .changeset/1369-*.md (stop on breach; explain in the report)
Container & model: S, mode:subagent, model: default (dispatch-gates --tier --repo objectstack-ai/hotcrm answers "no path-derived mandate … the tier stays the PM's per-card judgment call"; a permission boundary, so not the floor tier)
Clause-②: no. The change adds one capability that the installed @objectstack/spec 17.6.0 already declares scope: 'org' to the app's own tenant_admin profile. It touches no published schema and no accept set.
Thread-read: 5965069822
Serial constraints cleared: unchanged from 5965009740. No open PR touches src/sales/profiles/** or test/saas-composition.test.ts.

What this corrects (the seat's own error, caught by the dev in 5965069822)

• 5965009740 named the branch claude/issue-1369-tenant-admin-org-presentation and called it "new; PR feat(profiles): tenant_admin gains the org-scoped presentation authority #1882's branch is unreadable". That was false. The ref exists and is readable at d586eed9. That commit was made under os-musk's session; it edits the pre-move path src/profiles/tenant-admin.profile.ts and is not an ancestor of main. It is very likely PR feat(profiles): tenant_admin gains the org-scoped presentation authority #1882's head.
• The dev's push of a fresh branch under that name was refused as non-fast-forward. The dev stopped there and edited nothing.
• Route: a new branch name. ⛔ No force-push, ⛔ no ref delete, and ⛔ no adoption of the banned account's commit. The stale ref stays where it is, untouched.
• Everything else in 5965009740 stands: the release of os-musk, the landing ruling 「席位落地」, and the handover record (no readable work; restart from main).

Readings carried from 5965069822, so the build starts from them:

• The card's Restart-when: probe exits 0 on 17.6.0.
• manage_org_presentation is declared scope: "org", with manage_metadata (scope: "platform") as the control.
• The installed evaluator metaWriteCapabilityVerdict was called with the grant added:
  • view, dashboard and report saves with an active org are ALLOWED;
  • the same saves without an active org stay DENIED;
  • object and flow stay DENIED.

---

Generated by Claude Code