# Task: Connect shared Yuxi knowledge and personal knowledge uploads

## Identity

- Task ID: 20261012-agent-knowledge-picker-b71e8a2c
- Mode: Feature
- Branch: codex/20261012-agent-knowledge-picker-b71e8a2c-agent-knowledge-picker
- Worktree: /Users/chillishark/Makelore 麦洛/.codex-worktrees/makelore/20261012-agent-knowledge-picker-b71e8a2c
- Base commit: bcb1b61564b05c92fb51d8791ce15db3ab8e8b2c
- Owner: codex
- Status: Ready for Integration

## Scope

- Read-only review of personal Agent advanced knowledge configuration, native Yuxi sharing and the existing Makelore facade; propose dropdown and personal-document upload interactions.
- No product or test modifications remain. User clarified that design discussion must precede implementation.

## Intent And Constraints

- User requests a proposal for selecting Yuxi platform knowledge or uploading personal files as knowledge. Latest instruction explicitly forbids beginning code changes until the design is discussed. Screenshot is teammate-provided evidence of native global-read sharing, not an instruction to modify platform permissions.
- Concurrent and Planning Gates Passed: matching task/worktree reservation verified at the completed current trial base bcb1b615; entry/memory, own record, positioning/current snapshot, decisions/system/domain/success, relevant knowledge evidence and commitments loaded; peer Scope/Intent/Promotion sections assessed.
- Main owns credentials and file IO; Yuxi remains authority for readable/selectable resources and mutations. Shared read-only libraries must not expose upload/replace/process/delete controls. Selection only changes the draft until explicitly saved/applied.
- Preserve completed card size, avatar, configuration, chat/composer and thinking changes. Active 20261012-agent-chat-files-review-e87b41c6 owns separate chat attachment UI; isolate files and retain its eventual integration. Historical undefined child-skill scope has no concrete dependency.
- Do not steal desktop focus, open native file pickers in verification, mutate live cloud knowledge, send paid model requests, deploy, push or edit peer/canonical documents. Background temporary-app rollout must use a current source comparison and preserve profile/latest compatible peer changes.
- Initial implementation interpretation was corrected by the user. All known task-owned product/test experiments were reverted, implementation agents stopped, and the temporary application/cloud remained untouched.

## Outcome

- Existing facade catalog already lists authorized usable owned/shared Milvus knowledge libraries. The separate Agent-scoped knowledge management list contains only the current creator's libraries across Agents; its IDs provide an authoritative join for identifying personal versus shared libraries without a new backend DTO.
- All document upload/list/process/delete operations enforce owned_knowledge independently. Shared libraries can be bound but cannot be maintained through this facade. Shared document metadata is not available through the owned-management endpoint; proposal shows only shared name/description.
- Personal Makelore cloud execution already derives retrieval tools from selected and authorized knowledge, so selection writes only configuration.knowledges and does not force a knowledge-base Skill/tools/preload selection. Native Yuxi web configuration has a different Skill requirement.
- Proposal: dropdown adds multiple readable libraries to an explicit selected list; a separate personal-upload action expands existing create/select-owned library and document processing workflow. Bindings remain draft-only until explicit save/apply. Upload readiness follows server parsing/indexing and chunk availability, with existing idempotent retries.

## Verification

- Source-contract inspection only; no claim of live cloud or runtime acceptance. Native ACL/runtime verification delegated to the isolated Yuxi contract review.
- Confirmed product/test rollback to recorded base; only this task record remains changed. No deployment, app update, native picker, focus change or model call.

## Follow-ups

- Await user agreement on the interaction before any implementation. Preserve the live runtime's latest compatible peer changes when a later rollout is authorized.

## Promotion Candidates

- None recorded.