workspace_id เป็นขอบเขตอนุญาต ไม่ใช่กำแพง — identity/v1 v1.1.0

[monthop-gmail]

ADR-0021 option B · ตอบ enterprise-knowledge#23 ที่บล็อก schema.sql ของเขาอยู่

2 ใน 3 ข้อ ADR-0007 ตอบไว้แล้ว — ต้องชี้ ไม่ใช่ตัดสินใหม่

คำถาม	คำตอบที่มีอยู่
knowledge ต้องมี workspace_id ไหม	✅ ต้องมี — ADR-0007 Consequences: "required สำหรับ execution/knowledge/tool"
department เป็น metadata filter ได้ไหม	❌ ไม่ได้ — เป็น label ของ workspace · อยู่ในตารางศัพท์ที่ lock ไว้แล้ว

⚠️ ทางเลือกที่ 3 ของเขา (workspace_id nullable ก่อน) ใช้ไม่ได้ — ขัดทั้ง ADR-0007 และ §25 ของเขาเองที่ห้าม scope filter เป็น optional ใน production path

ข้อที่ยังไม่มีใครเคาะ

ADR-0007 พูดสองอย่างที่ต้องอ่านคู่กัน:

"tenant = boundary, workspace = grouping"
แต่เหตุผลที่ปฏิเสธ option C คือ "ไม่มี workspace → ทีมหนึ่งเห็น knowledge อีกทีมทั้งหมด"

ถ้า workspace ไม่บังคับอะไรเลย   → การปฏิเสธ option C ไม่มีความหมาย
ถ้า workspace แข็งเท่า tenant     → มีสองกำแพงเหมือนกัน แล้วทำไมต้องมีสองชั้น

คำตอบที่ทำให้ทั้งสองประโยคจริงพร้อมกันมีทางเดียว — ต่างกันที่ "ข้ามได้ไหมถ้ามีคนอนุญาต" ไม่ใช่ที่ "เข้มแค่ไหน"

	tenant_id	workspace_id
ข้ามได้ไหม	ไม่ได้ทุกกรณี — ไม่มี policy · consent · admin คนไหนอนุญาตได้	deny by default แต่อนุญาตได้ ผ่าน policy/v1 (+ consent/v1 ถ้าเป็นข้อมูลส่วนบุคคล)
บังคับที่ชั้นไหน	ชั้นเก็บข้อมูล — RLS/partition/index · โค้ดเขียนผิดก็ยังข้ามไม่ได้	ชั้นตรวจสิทธิ์
การข้ามที่สำเร็จ	ไม่มี	ต้องออก audit event เสมอ ว่าอนุญาตด้วยอะไร

แถวสุดท้ายคือหัวใจ — ถ้า cross-workspace ทำได้เงียบ ๆ มันก็ไม่ต่างจากไม่มี workspace

ทำไมไม่เลือกให้แข็งเท่า tenant

• แชร์ knowledge ข้ามทีมใน org เดียวกันไม่ได้เลย ซึ่งเป็นความต้องการปกติ (คู่มือกลาง · นโยบายบริษัท)
• ถ้าสองชั้นข้ามไม่ได้เหมือนกัน ก็ไม่มีเหตุผลที่ต้องมีสองชั้น — ขัดกับเหตุผลที่ ADR-0007 เลือก A แทน B
• ทีมจะเลี่ยงด้วยการทำสำเนาข้าม workspace ซึ่งแย่กว่าปัญหาเดิม — สำเนาที่ drift ได้และเพิกถอนไม่ได้

สิ่งที่เปลี่ยน — ไม่มี field ใหม่ ไม่มี contract ใหม่

กลไกครบอยู่แล้ว (policy/v1 · consent/v1 · event/v1) · เปลี่ยนแค่คำอธิบายให้คนเจอกฎนี้ตรงที่เขาอ่านจริง:

ไฟล์	เปลี่ยนอะไร
identity/v1 WorkspaceId	เขียนความต่างจาก TenantId ให้ชัด — v1.0.0 → v1.1.0
planes/knowledge.md	เพิ่มหัวข้อ ขอบเขตของการค้น · เดิมพูดถึงแต่ tenant

ไม่มี field เปลี่ยน ไม่มีอะไร breaking — เป็นการเขียนสิ่งที่ ADR-0007 ตัดสินไว้แล้วให้ชัดขึ้น

ผลต่อ consumer

• enterprise-knowledge ปลดบล็อก Phase 1 ได้ทันที และรู้ว่าต้องบังคับ workspace ที่ชั้นไหน (ไม่ใช่ชั้นเดียวกับ tenant)
• care-agent-platform ไม่กระทบ — บังคับ tenant ด้วย RLS อยู่แล้วซึ่งแข็งกว่า และ care_organization เป็น record ในโดเมน ไม่ใช่ workspace
• devfactory-core ไม่กระทบ — workspace_id optional สำหรับ event ระดับ tenant ตาม ADR-0007 เดิม

drift_check.py → passed=20 FAIL=0 WARN=0

🤖 Generated with Claude Code

https://claude.ai/code/session_01LHv7HRmnnGAoKT5BvxDWHs