Skip to content

fix(collective): bound participation owner reads - #170

Open
zts212653 wants to merge 2 commits into
mainfrom
fix/f290-owner-participation-candidates
Open

zts212653 wants to merge 2 commits into
mainfrom
fix/f290-owner-participation-candidates

Conversation

@zts212653

Copy link
Copy Markdown
Owner

Summary

  • derive the owner-view thread set only from current route endpoints, inbox receipts, and matching owner Tasks
  • ask Core for that exact owner-visible candidate set instead of paging every private thread
  • keep deleted/foreign threads filtered by Core and preserve route, revoke, Task-source, Cat-participant, and request-execution checks
  • add the additive threadIds type to the next plugin SDK source

With 120 unrelated private threads, the regression now returns only the referenced channel and performs one candidate list, one metadata read, and one participant read. The previous code returned all 120 unrelated rows and performed 3 list + 120 get + 120 getCats calls.

Dependency and release boundary

Depends on Core PR https://github.com/zts212653/cat-cafe/pull/6341. Core must land before this caller is packaged or installed; an older Host rejects the new option rather than silently restoring the full scan.

This PR intentionally does not change Collective version, shrinkwrap, catalog, or alpha.23. The existing alpha.23 owner retains package/release custody.

Risk and architecture

  • behavior: participation response threads becomes the complete participation/work-referenced subset, not the unrelated owner directory
  • security: the plugin supplies candidate ids; Core remains the owner-visibility authority
  • contract: additive SDK typing plus the Core dependency above
  • data / irreversible: none

Architecture cell: plugin / existing Collective runtime adapter

Map delta: none. The caller and view remain the same read owner; only the input set is narrowed to canonical route/inbox/Task references.

Canonical source: packages/collective-connector/src/owner-participation-view.ts#collectiveOwnerParticipationView and owner-participation-caller.ts#createCollectiveOwnerView

Consumer evidence: rg -n "threads\.list\(|owner-participation-view|PluginThreadHost" packages

Claim guard: owner-participation-view.test.ts adds 120 unrelated owner threads and asserts the fixed response and constant Host-call count.

Verification

  • pnpm --filter @clowder-ai/plugin-sdk test — 228/228
  • pnpm --filter @clowder-ai/plugin-sdk lint
  • pnpm --filter @clowder-ai/collective-connector build
  • pnpm --filter @clowder-ai/collective-connector typecheck
  • pnpm --filter @clowder-ai/collective-connector test:business — 443/443
  • git diff --check

Post-merge/live timing remains with the existing Task485 deployment consumer; this source PR does not claim boot64 or two-Human acceptance.

Why: Build the owner view from route, inbox, and matching Task references, then ask Core for that exact owner-visible set instead of walking every private thread on each participation read.

[小太阳·砚砚/gpt-5.6-sol🐾]

Thread-Context: threadId=thread_mtr820c45n7l2b2s invocationId=9655091a-9825-425f-b44f-46860173ff70 catId=codex-sol
Why: A valid persisted participation history can exceed the Host's per-request candidate bound. Read every referenced thread in fenced batches, merge the complete owner-visible result, and retain duplicate protection without truncating history.

[小太阳·砚砚/gpt-5.6-sol🐾]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant