Jyong 79116d8c4b feat(knowledge-fs): scope dataset API keys by knowledge base type ... Legacy knowledge bases (`datasets`) and KnowledgeFS spaces (`knowledge_fs_control_spaces`) live in different tables, so a dataset API key binding could only ever name a legacy dataset and the KnowledgeFS service API never consulted bindings at all: a key scoped to specific knowledge bases still reached every KnowledgeFS space in the workspace. - Bindings carry a `resource_type` (`dataset` | `knowledge_fs_space`) and a nullable `control_space_id` (migration 9a4e7d1c2b60, existing rows stay `dataset`), with a CHECK that exactly one id column matches the type. - `dataset_api_key_service` exposes the key scope by kind, validates and binds KnowledgeFS spaces (tenant-owned, not deleting/deleted), and cleans up keys scoped only to a space when its deletion is requested. The orphan-key cleanup is now NULL-safe so a space binding keeps a key alive. - Legacy dataset routes only honour `dataset` bindings; the KnowledgeFS authorization service only honours `knowledge_fs_space` bindings and raises a scope error that the service API maps to 403 (unknown keys stay 401). - Console key creation accepts `knowledge_space_ids`; list/create responses return them next to `dataset_ids`. - The web scope picker lists KnowledgeFS spaces alongside legacy datasets when KnowledgeFS is enabled and submits the ids by kind; the scope column counts both. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015zw5G5SX3HmVfnZof6YWAc		2026-09-03 05:59:39 -04:00
..
api-key-modal.spec.tsx	feat(knowledge-fs): scope dataset API keys by knowledge base type	2026-09-03 05:59:39 -04:00