Decision: does the knowledge plane need workspace_id? ADR-0007 says department is a workspace label, not metadata

[monthop-gmail]

ต้องให้ทีมตัดสินใจ + ต้องได้คำตอบจาก agent-platform ไม่ใช่งาน implement

เจอตอนเปิด contracts/identity/v1/identity.schema.yaml จริงเพื่อทำ #17

ปัญหา

ADR-0007 วางลำดับชั้นไว้ว่า Tenant → Workspace → Resource และ schema เขียนกำกับ WorkspaceId ไว้ตรง ๆ ว่า

ขอบเขตงานภายใน tenant — agent, knowledge, tool, policy อยู่ใน workspace
Project และ Department เป็น label ของ workspace ไม่ใช่ชั้น id ใหม่

และ RequestContext มี workspace_id เป็น field จริง (optional เฉพาะ event ระดับ tenant)

แต่ repo นี้ไม่มี workspace เลยทั้ง repo — และเราใช้ department เป็น metadata filter ธรรมดา ซึ่งตาม ADR-0007 คือ label ของ workspace ไม่ใช่ metadata อิสระ

ทำไมต้องรีบ

ถ้าคำตอบคือ knowledge plane ต้องมี workspace_id → มันคือ isolation ชั้นที่สองถัดจาก tenant ไม่ใช่ field เพิ่มเฉย ๆ กระทบ:

ของที่ต้องแก้	ผลกระทบ
schema.sql	ต้องมี column workspace_id + เข้า composite index + เข้า unique constraint
ScopePredicate	ต้องบังคับ workspace เหมือนที่บังคับ tenant (hard, ไม่ใช่ filter)
PolicyContext / TenantScope	ต้องมี workspace scope
evaluation/ground_truth.py	fixture ทั้งชุดต้องมี workspace + ต้องมี case พิสูจน์ว่าข้ามไม่ได้
department ที่ใช้อยู่	อาจต้องเลิกเป็น metadata filter แล้วกลายเป็น label ของ workspace

เหมือนเคสเดียวกับ #5 — เปลี่ยนหลังมี baseline แล้วตัวเลข benchmark เดิมใช้เทียบไม่ได้ และรอบนี้หนักกว่าเพราะแตะ security boundary ด้วย

ตั้ง milestone ไว้ที่ Phase 1 เพราะ schema.sql อยู่ตรงนั้น — ต้องเคาะก่อนเริ่มเขียนแถวจริงลงตาราง ไม่ใช่หลัง

คำถามที่ต้องได้คำตอบ

1. knowledge plane ต้องมี workspace_id ตั้งแต่แรกไหม หรือ tenant พอสำหรับเฟสนี้
2. ถ้าต้องมี — workspace_id เป็น hard boundary ระดับเดียวกับ tenant หรือเป็นชั้นที่อ่อนกว่า (ข้าม workspace ในเงื่อนไขบางอย่างได้)
3. department ที่เราใช้เป็น metadata filter อยู่ ควรกลายเป็น label ของ workspace ตาม ADR-0007 หรือคงเป็น metadata ได้

ทางเลือก

1. คง tenant อย่างเดียวตอนนี้ แล้วบันทึกเป็น known gap — เร็ว แต่ต้องรื้อ schema ทีหลังแน่ถ้าคำตอบข้อ 1 คือ "ต้องมี"
2. ใส่ workspace_id เลยตั้งแต่ตอนนี้ ตาม ADR-0007 — แพงกว่าตอนนี้ ถูกกว่าตอนหลัง
3. ใส่เป็น nullable ก่อน แล้วค่อยบังคับตอน Phase 8 — ⚠️ §25 ห้าม "ให้ tenant filter เป็น optional ใน production path" ไว้ชัด ทางนี้เสี่ยงผิดหลักการเดียวกัน

เงื่อนไขว่าปิดได้

ได้คำตอบทั้ง 3 ข้อ แล้วบันทึกเป็น ADR ใน docs/ (เกี่ยวกับ #21) · ถ้าเลือกทาง 2 ให้เปิด issue implement แยก

ถามฝั่ง platform ไว้ที่ #17 แล้ว

อ้างอิง: ADR-0007 · schema.sql, src/enterprise_knowledge/security.py, src/enterprise_knowledge/contracts.py

[monthop-gmail]

จาก agent-platform — เคาะแล้วครับ ตอบครบทั้ง 3 ข้อ เดินหน้า Phase 1 ได้เลย

ADR-0021 · PR #41 (รอ merge · identity/v1 v1.1.0)

ข้อ 1 — ต้องมี workspace_id ตั้งแต่แรก ✅

อันนี้ ADR-0007 ตอบไว้แล้ว ไม่ใช่เรื่องใหม่ — ใน Consequences เขียนตรง ๆ ว่า

workspace_id required สำหรับ execution/knowledge/tool · optional สำหรับ event ระดับ tenant

ทางเลือกที่ 2 ของท่าน (ใส่เลยตอนนี้) คือทางที่สัญญากำหนดอยู่แล้ว ไม่ใช่ทางที่แพงกว่าเพื่อกันเหนียว

⚠️ ทางเลือกที่ 3 (nullable ก่อน แล้วบังคับตอน Phase 8) ใช้ไม่ได้ — ขัดทั้ง ADR-0007 ที่ระบุว่า required และขัด §25 ของท่านเองที่ห้าม "ให้ tenant filter เป็น optional ใน production path" · ท่านเขียนข้อกังวลนี้ไว้เองใน issue แล้วและถูกต้อง

ข้อ 2 — ไม่เท่ากับ tenant และนี่คือข้อที่ต้องเคาะจริง ๆ

ADR-0007 พูดสองอย่างที่ต้องอ่านคู่กัน — "tenant = boundary, workspace = grouping" กับเหตุผลที่ปฏิเสธ option C ว่า "ไม่มี workspace แล้วทีมหนึ่งเห็น knowledge อีกทีมทั้งหมด" · ถ้า workspace ไม่บังคับอะไรเลย การปฏิเสธ option C ก็ไม่มีความหมาย แต่ถ้าแข็งเท่า tenant ก็ไม่มีเหตุผลที่ต้องมีสองชั้น

คำตอบ: สองชั้นนี้ต่างกันที่ "ข้ามได้ไหมถ้ามีคนอนุญาต" ไม่ใช่ที่ "เข้มแค่ไหน"

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

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

แปลเป็นงานของท่าน

ของที่ท่านลิสต์ไว้	ต้องทำอะไร
schema.sql	workspace_id เป็น column จริง · เข้า composite index และ unique constraint · แต่ไม่ต้องทำ RLS ให้มันแบบที่ทำกับ tenant
ScopePredicate	tenant = hard บังคับที่ชั้นเก็บข้อมูล · workspace = deny by default ที่ชั้นตรวจสิทธิ์ ขยายได้เมื่อมีการตัดสิน
PolicyContext / TenantScope	มี workspace scope · และเป็นที่ที่การขยายขอบเขตถูกตัดสิน
evaluation/ground_truth.py	ต้องมีเคสพิสูจน์ สองอย่าง — ข้าม tenant ไม่ได้แม้ policy อนุญาต · ข้าม workspace ได้เมื่อมีการตัดสิน และ มี event บันทึกทุกครั้ง

เคสที่สองสำคัญกว่าที่ดู — เป็นตัวพิสูจน์ว่า workspace ไม่ได้ถูก implement เป็น tenant ตัวที่สอง

ข้อ 3 — department เป็น label ของ workspace ❌ ไม่ใช่ metadata อิสระ

ADR-0007 ระบุไว้ตรง ๆ และอยู่ในตารางศัพท์ที่ lock ไว้ ตั้งแต่วันแรก · identity/v1 WorkspaceId ก็เขียนกำกับไว้เอง

⚠️ metadata filter ที่ลอยอยู่โดยไม่มี workspace คือชั้นที่สามที่ ADR-0007 ห้ามไว้ ในชื่ออื่น

ตอนนี้ repo ท่านไม่มี workspace เลยแล้วใช้ department เป็นตัวแบ่ง — นั่นแปลว่า department กลายเป็นชั้น grouping จริงโดยพฤตินัย ซึ่งเป็นสิ่งที่ ADR ห้าม · พอมี workspace_id แล้ว department กลับไปเป็น label ได้ตามที่ควรเป็น

สรุปสั้น

1. ใส่ workspace_id ตั้งแต่ตอนนี้ (ทางเลือกที่ 2) — ไม่ใช่ทางเลือก แต่เป็นสิ่งที่ ADR-0007 กำหนดไว้แล้ว
2. บังคับคนละชั้นกับ tenant — hard ที่ storage สำหรับ tenant · deny-by-default ที่ authorization สำหรับ workspace
3. department → label ของ workspace

ขอบคุณที่ถามก่อนเขียน schema.sql ครับ — ถ้าเขียนไปก่อนแล้วค่อยรู้ว่าต้องมี workspace จะต้องรื้อทั้ง index และ fixture ซึ่งแพงกว่ามาก · และคำถามข้อ 2 ของท่านเป็นสิ่งที่ ADR-0007 ค้างไว้จริง ไม่มีใครเคาะมาก่อน

[monthop-gmail]

ขอบคุณมากครับ — เคาะครบ 3 ข้อแล้ว ปิด issue นี้ งาน implement ย้ายไปที่ #24

สรุปสิ่งที่ตัดสิน

1. workspace_id ต้องมีตั้งแต่แรก — และรับทราบว่าอันนี้ ADR-0007 ตอบไว้แล้ว ไม่ใช่เรื่องใหม่ · ที่ผมเขียนเป็น "ทางเลือกที่ 2 แพงกว่าตอนนี้ ถูกกว่าตอนหลัง" จริง ๆ แล้วไม่ใช่ทางเลือก แต่เป็นสิ่งที่สัญญากำหนดอยู่แล้ว ผมอ่าน ADR-0007 ไม่ครบเอง
2. ไม่เท่ากับ tenant — tenant hard ที่ชั้นเก็บข้อมูล · workspace deny-by-default ที่ชั้นตรวจสิทธิ์ ข้ามได้ถ้ามีการตัดสิน และต้องออก audit event ทุกครั้งที่ข้าม
3. department เป็น label ของ workspace — ที่ repo นี้ทำอยู่ตอนนี้คือชั้น grouping ที่ ADR-0007 ห้ามไว้ ในชื่ออื่น

ข้อที่ผมคิดว่าเป็นหัวใจจริง ๆ

ถ้า cross-workspace ทำได้เงียบ ๆ มันก็ไม่ต่างจากไม่มี workspace เลย

เอาไปเขียนเป็นเงื่อนไขของ ground truth ใน #24 แล้ว — ต้องมีเคสที่ ข้าม workspace สำเร็จ แล้วตรวจว่า audit event ออกจริง ไม่ใช่มีแต่เคส "ข้ามไม่ได้"

เพราะถ้าเทสมีแต่ฝั่ง "ข้ามไม่ได้" แปลว่าเรา implement workspace เป็น tenant ตัวที่สองโดยไม่รู้ตัว ซึ่งเป็นสิ่งที่ ADR-0021 เตือนไว้พอดี — และมันจะสอบผ่านทุกเทสด้วย

ขอบคุณที่ตอบละเอียดครับ 🙏