Project Foundation and Decision Baseline
Tenant, Organization, Project, and API Shell
Organization and Project Product Surface
Core Collaboration Objects
Internationalization
Memory Engine MVP
Ambient AI MVP
System Notification Center
External Work Source Integration - GitHub Adapter MVP
Memory Intelligence
Self-Authored Procedural Skill Induction
Production Hardening and Multi-Agent Expansion
Post-Launch and Long-Tail Features
Conversational Intake
Conversational Surface
Platform-Native Demo Site Generator
Grounded Read-Only Q&A in Capture Thread
Intake 候選卡就地編輯
宣告式授權防線
Standing-Facts Memory Layer
Provider Key Env Elimination
Passkey Authentication
Conversation Knowledge Intake
Memory Connectivity & Dynamic Views
ADR Closure & Independent Verification
MCP Capture and Recall Adapter
Prompt Cache Governance and Context Assembly
Notification Read-State Integrity and Content i18n
Notification Aggregation and Seen Semantics
Worker Prompt LPRC Rollout
Upload Content-Type Verification
Reconcile Quality Stage 1
Entity-Anchored Cross-File Reconciliation
Forgot Password
Claude/Codex Integration Guide
Relation Coverage and Review Calibration
Transactional Email Deliverability
Worker Horizontal Scaling
Project Status Page
Use Nx Integrated Monorepo
Use DB-Backed Memory Repository First
Organization Owner / Admin Automatically Inherits Project Admin Permissions
Internationalization Strategy
Org-Scoped Layered Memory Namespace
Bi-Temporal, Weighted Memory Model on Postgres + pgvector
Human Knowledge Edits Apply Directly, Destructive Edits Stay Reviewed
System Notification Center — Per-Recipient Fan-Out, SSE Push via LISTEN/NOTIFY, Never-Delete
Platform Admin Layer
Chat-as-Capture Conversational Intake
Tiered Memory Governance — Ambient Auto-Commit by Default, Review by Exception
Tenant BYO API Keys and Per-Capability Model Selection
Distilled-Proposition Memory Units — Structured Block Body, Source Separation, Write-Time Reconcile
Impact-Graded Supersede — Review by Architectural Impact, not Blanket
Platform-Native LLM-Codegen Demo Site Generator
EPISODIC Provenance Events Decouple from the Extraction Confidence Band
Org-Scope Direct Authoring & Organization Decay
Memory Connectivity, Dynamic Views & Vault Export
Grounded Read-Only Q&A Inside the Capture Thread
Standing-Facts Memory Layer (`facts.md`)
Eliminate Provider API Keys from Environment Variables
Passkey Authentication
Conversation Knowledge Intake
MCP Capture and Recall Adapter
Provider-Agnostic Prompt Cache Governance and Conversation Context Assembly
Notification Aggregation and Seen Semantics
Entity-Anchored Cross-File Memory Reconciliation
Worker Horizontal Scaling（多 replica 水平擴展）
Memory Maintainer 多文件**並行**上傳會產生語意重複的 memory block（無語意去重；commit 層 branch 鎖只序列化寫入、不擋重複知識）。修法三階段全交付：per-branch advisory lock 序列化＋同專案多文件合併抽取（per-item attribution、union refs）＋burst 後即時 entity consolidation；同時修掉重驗中發現的多 chunk anchor 碰撞＋事件級冪等吞 chunk（靜默知識遺失）。**→ 已修（2026-07-06，44ece00＋11747cc＋DI 增補；Encore e2e R4 全輪重驗完成 2026-07-07：S0 合併 pass、全批次唯一性 PASS，見 e2e-fixtures/encore/VERIFICATION-REPORT.md）**
Demo build：專案在 BUILDING 中途被 archive 時，該 build 永久停留 BUILDING（handler 跳過 archived 專案、無自動失敗轉換）**→ 已修（2026-07-10，Phase 20 W3；transaction-internal project lock + interleaving regression；global V3 / W3 round 2 獨立 VERIFIED）**
Demo build 完成通知收件人固定為 plan 作者（`generatedByMemberId`），非實際觸發 build 者。**→ 已修（2026-07-10，Phase 20 W3；persist actual requester + legacy fallback；global V3 / W3 round 2 獨立 VERIFIED）**
Tier 1（RENDERER）demo spec 使用相對路徑，renderer 公開部署需 spec 絕對 URL 才能脫離 api 依賴。**→ 已結案（2026-07-10，Phase 20 W3 global V3 / W3 round 2 獨立證實 renderer dist + 同站 `/spec.json` 為 self-contained public deploy）**
Production worker replica 曾於 2026-07-05 Encore e2e 期間縮至 0，需確認已恢復（一次性 ops 確認，非程式缺陷）。2026-07-06 更新：e2e 重驗期間 replicas 刻意維持 0。**→ 已結案（2026-07-07，e2e 收尾恢復 `kubectl scale --replicas=1`，pod 1/1 Running 實查確認）**
client 測試套件在 main 上有 23 個既存失敗（7 個 spec 檔）：`0b390a6 chore(i18n): refine zh-TW/en-US term translations` 調整了 catalog 用語（如「輸入你的名字（選填）」「已移除」「等待你處理」）但未同步更新斷言這些字串的 spec，`pnpm test` 全套因此無法過閘。**→ 已修（2026-07-07，Phase 12 收尾隨行修復：7 個 spec 檔斷言對齊現行 catalog 用語（你→您、決策→決議、核可→核准、駁回/移除→忽略等），catalog 與產品碼未動；`nx run client:test` 240/240 綠）**
Reconcile 的 embedding 相似度 dedup 對「剛 commit 的 blocks」全盲：`findSimilarActiveBlocks` 只查 `memory_block_embeddings`，而新 block 的 embedding 由 `MEMORY_COMMIT_CREATED_EVENT` 非同步補寫、且會被同一 AI poller 的 long pollOnce（多 chunk 音檔 4 分鐘）卡到整批結束才寫入 → 長文件 chunk 之間、鄰近批次之間的重述照樣 ADD（entity-keyed 的 glossary/stakeholders 不受影響）。修法方向：maintainer commit transaction 內同步產 embedding，或 reconcile 對缺 embedding 的 ACTIVE block 現場計算補比。**→ 已修（2026-07-06，dde441a；maintainer 於 advisory lock 內 commit 後同步 refreshBranchEmbeddings，async 路徑留作 backstop；Encore e2e R4 全輪重驗完成 2026-07-07：逐 pass 同步刷新實錄、跨 chunk dedup 生效）**
Maintainer 抽取/reconcile 的「具體事實被一般規則吸收」（specificity loss）：來源片段中的具名個案事實未落地——slack-encore 4/30 的「《午夜計程車》林佳恩/小林五五對拆」與「Spotify 一行 ISRC TWA472600099 對不到→丟 suspense」兩個種子，該批 26 NOOP/8 UPDATE 處理後 memory 全文無「午夜」「099」任何 block（同批其他事實正常落地）；無法區分抽取層遺漏或 reconcile 被既有一般規則（suspense 流程、拆帳比例）判 NOOP 吞掉——candidate 級 NOOP 無記錄可稽（觀測性缺口一併在此）。影響：依賴該種子的後續 supersede（S3 午夜 50/50→60/40）無標的可改。**→ 已修（2026-07-06，1dae1f8；兩層修法：抽取 prompt 補 standing-data-facts 指引（重放種子命中 1→9）＋雙 judge 加個案不併規則守則（099 案例 NOOP 3/3→ADD 3/3）＋candidate 級 reconcile log 補觀測；Encore e2e R4 全輪重驗完成 2026-07-07：S2 種子＋S11 六項行級事實全落地）**
`withBranchLock` 的 unlock 失敗會向上拋出並遮蔽 fn() 原始結果：DB 連線中斷時（實測 2026-07-06 網路中斷）專用 QueryRunner 死亡 → finally 內 unlock 拋 `Query runner already released` → 已成功 commit 的 pass 被標失敗、事件多跑一次重試（chunk 冪等會收斂，資料無損但噪音＋浪費一次 attempt）。修法：unlock 失敗只 log（連線死亡時 PostgreSQL session 終止會自動釋放 advisory lock，吞掉安全）**→ 已修（2026-07-09，Phase 15 收尾；`memory-maintainer.handler.ts` withBranchLock unlock 加 try/catch 吞掉並 log）**
Intake extractor 對「標題＋條列」高密度訊息的 specificity loss：7 條獨立事實（單機部署風險、3→5 nodes 變更、Git 同步架構決策、今年完成期限…）被收成**單一** TASK 候選（細節僅存 description、卡片不顯示），RISK/DECISION/MILESTONE 全數未分解——`buildExtractionPrompt` 無任何逐條分解與類型對映指引（KB-08 同款問題修在 memory maintainer，intake extractor 未同步）。修法：抽取 prompt 補分解指引＋卡片顯示 description 摘要，比照 KB-08 離線重放驗證。**→ 已修（2026-07-07：extraction prompt 補 DENSE LIST 分解與類型對映指引（含散文不過度分解防退化）＋SummaryCardItem/卡片補 description 摘要（worker 200 字/client 80 字雙層截斷）；離線重放 gpt-5.4-nano——富蘭克林訊息修前 1 候選全 TASK 高變異、修後三輪穩定 7 候選（RISK×2/TASK×3/DECISION/umbrella MILESTONE），散文對照無退化）**
Phase 15 document upload → AI maintainer live path 一度未產生 standing-fact proposal：初查時測試文件上傳與 document parsing 已完成，但 `document.source_extracted.v1` 的 AI consumer 停在 `pending attempts=3`，尚未建立對應 `ai_actions` 或包含 `TWA472600099` 的 proposal。後續原事件第 4 次 retry 自然收斂並 committed；另以 clean retest 重跑 service upload path，AI consumer `attempts=1` processed，Memory Maintainer 建立 target `facts.md` proposal/commit，`requirements.md` 未承擔測試 facts。**→ 已結案（2026-07-09，Phase 15 closeout）**
MCP runbook 與帳號頁 setup guide 的 Codex server 命名不一致：`docs/runbooks/mcp-integration.md:100` 的 Codex remote 範例用 `lilas-remote`，但帳號頁實際產生的指令（`apps/client/src/app/account-mcp-setup-guide.tsx`）Codex 用 `lilas`、Claude 才用 `lilas-remote`。功能無礙（server 名稱任意），但兩份使用者面向文件對不上，照著 runbook 設定的人與帳號頁指引產出的設定名稱會分歧。修法：擇一命名並同步兩處（建議以帳號頁為準）。**→ 已修（2026-07-14，Phase 30 M1：remote 統一 `lilas`、developer local stdio 改 `lilas-local-dev`，五處同步含 spec 測試；全 repo 掃描無非預期殘留、獨立驗證 PASS）**
Sign-in 頁 React hydration mismatch：`auth-form.tsx` 的 passkey 條件式 UI（`authPasskeyMethod` div）只在 client 端渲染（WebAuthn 可用性判斷），SSR HTML 與 client 首次 render 不一致 → console 每次載入都拋 `Hydration failed`、整棵樹 client 端重建（dev 顯示 1 issue badge；功能無礙但有重建成本與噪音）。修法方向：以 `useEffect` 後置 state 控制 passkey 區塊顯示（首次 render 與 SSR 一致），或該區塊改 dynamic no-ssr。**→ 已修（2026-07-14：`browserSupported` 改為 `useState(false)` ＋ `useEffect` 後置 `browserSupportsWebAuthn()` 判斷，SSR 與首次 client render 一致；live 驗證兩次載入 console 零 hydration 錯誤、dev issue badge 消失、passkey 按鈕 mount 後正常顯示；client 303/303 / lint / typecheck 全綠）**
重設密碼後帳號仍鎖定、且鎖定被誤報為「帳號或密碼不正確」：member-base 預設 `loginFailedBanThreshold=5` 且未設自動解鎖，`login()` 在驗證密碼**之前**就拋 `MemberBannedError`；而 `changePasswordWithToken` 不歸零 `loginFailedCounter` → 使用者忘記密碼連錯 5 次後，即使成功重設密碼也永遠登不進去；又因 `AuthService.signIn` 裸 catch 把所有錯誤壓成 `AUTH_INVALID_CREDENTIALS`，使用者只看到「帳號或密碼不正確」，無從得知已鎖定。**→ 已修（2026-07-14 同日：(1) `resetPasswordWithToken` 成功後歸零 `loginFailedCounter`（重設即證明信箱所有權，解鎖自助化）；(2) `signIn` 對 `MemberBannedError` 改拋新錯誤碼 `AUTH_ACCOUNT_LOCKED`（403）＋雙語訊息引導走忘記密碼；auth 83/83、live 驗證鎖定訊息顯示、重設後計數 5→0、新密碼登入成功）；上游同款修法已隨 `@rytass/member-base-nestjs-module@0.4.0` 發佈（2026-07-15 升級採用，應用層補償同日移除、live 重驗計數歸零由套件完成）。同版新增的 `defaultAdminAccount`（授 `::SUPER_ADMIN::` guard 層全域 allow-all）經評估**不採用**：語意與 Phase 7a M5/D6 的 org-less `platform_admin`（僅 /platform 面）不符、且過不了 `PlatformAdminGuard`，seed script 維持原樣（2026-07-15 產品裁示）**
**→ 已修（2026-07-18）**：`resolveActiveConversationOrThrow` 共用 helper 拆三情境——tenant 內查無 / 配錯 project → `MCP_INPUT_INVALID`，真非 ACTIVE 才回 `MCP_TARGET_FROZEN`；tenant 過濾留在 SQL WHERE 維持跨 tenant 不可枚舉；早期檢查與 transaction 內行為一致；新增 2 個 failpoint 測試。原始問題：`MCP_TARGET_FROZEN` 語意過載：`mcp-capture-submission.service.ts` 的 conversation 查核（id＋tenant＋projectId＋ACTIVE 的 findOne）落空時一律回 `MCP_TARGET_FROZEN`——「projectId 與 conversationId 配對不符／不存在」與「目標真的被封存」共用同一錯誤碼，MCP client 端 agent 會誤判為專案凍結、回報「清單顯示可寫但送出被凍結」的假性資料不一致。修法方向：同 tenant 內的配對不存在改回 `MCP_INPUT_INVALID`（或獨立 not-found 語意），跨 tenant 仍維持不可枚舉。
多 replica 下 Casbin enforcer in-memory policy 與 DB 分歧：production `lilas-api`（2 replicas，v0.0.60）其中一個 pod（`bhzqh`）自 2026-07-15 13:14 UTC 起對 org owner 的繼承專案存取一律 enforce false（`findProject` 拋 `PROJECT_PERMISSION_DENIED`），另一 pod（`jhm5s`）同請求正常 allow——同一 token 對 `project(id)` 連打 10 次呈 `DENIED,OK` 完美交替（round-robin）。DB `casbin_rule` 規則完整（offline 以相同 model＋DB 規則重放 enforce = true；member 的 `organization_owner` grouping 與 org domain 全套 project policy 都在），故為壞 pod 的記憶體態分歧，非規則遺失、非部署落後（v0.0.60 = main HEAD）。根因類別：casbin typeorm-adapter 無 watcher／跨 pod policy 同步機制，任一 pod 開機後其 in-memory policy 只反映自身寫入；該 pod 開機（07-15 00:07）後正常 13 小時才開始 denial，確切觸發事件未定位（07-15 當日有 Phase 30 M5 live e2e 與大量 AI memory 活動）。使用者可見症狀：org owner 側欄看得到所有專案、點任何專案間歇（或經 SPA 快取後穩定）顯示「您沒有存取此專案的權限」。緊急處置：`kubectl rollout restart deploy/lilas-api -n lilas`（重載 policy 即復原）——**已於 2026-07-16 執行並驗證復原**（同 token 10 連發 `project(id)` 全 OK、專案頁完整渲染）。**→ 已修（2026-07-16，0330a6b；v0.0.62 已部署上線）**：根治修正：`libs/auth` 新增 `CasbinPolicyReloadService`——週期性（`CASBIN_POLICY_RELOAD_INTERVAL_MS`，預設 60s）將 `casbin_rule` 與 enforcer 記憶體 diff，以 `selfAddPolicy` / `selfRemovePolicy`（watcher 回呼原語，不寫回 DB、增量重建 role links）只修 delta，避免 `loadPolicy()` 清空視窗競態；偵測到分歧記 warn log 供觀測。6 項 spec 全過（含 KB-16 情境重現：分歧 enforce false → reconcile 後 true）。
AI suggestion ACTIVE 去重為 check-then-act 競態：`hasActiveSuggestionWithTitle`（`libs/ai-core/src/lib/ai-suggestion.service.ts:143`）先 `findOne` 查有無 ACTIVE 列、呼叫方再自行 insert，中間有 TOCTOU 空隙；`ai_suggestions` 僅有 `@Index(['projectId', 'status'])` 一般索引（`libs/ai-core/src/lib/ai.entities.ts:640`），無 `(project_id, suggestion_type, title, status)` unique constraint。三個呼叫點（`memory-unlinked-mention.handler.ts:170`、`structured-activity-observer.handler.ts:156`、`project-observer.handler.ts:371`）皆受影響。單 replica 下同一 poll tick 以 `Promise.all` 平行處理多個 claimed event 即有機率重複（同 project 同 term 的 GLOSSARY_GAP 疊卡）；worker 多 replica 會放大。修法：partial unique index `(project_id, suggestion_type, title) WHERE status = 'ACTIVE'` ＋寫入端 `ON CONFLICT DO NOTHING`，見 [ADR 0028](../adr/0028-worker-horizontal-scaling.md) 決策 4。**→ 已修（2026-07-17，Phase 33 M1）**：migration `1786500000000` 清 ACTIVE 重複列＋partial unique index `IDX_ai_suggestions_project_type_title_active`（已套用 shared DB）；`createSuggestion` 改 `.orIgnore()`、conflict 回 null 不發 audit；全部 6 個呼叫點（含 spec 未列的 project-observer decision 路徑、github ×2、intake ask 路徑）null 安全；獨立稽核 PASS、ai-core 399 spec 全綠
**→ 已修（2026-07-18）**：`*_status_updated_at` 欄位＋claim 放寬（PENDING 或逾時 SENDING，`NOTIFICATION_SENDING_TIMEOUT_SECONDS` 預設 600s）＋handler no-op 語意修正（終態才 no-op，新鮮 SENDING 丟例外交還 outbox 退避重試）；migration `1786500000004` 一次性把既存卡死 SENDING 標 FAILED（其 outbox 已 PROCESSED 無法重驅動）。原始問題：Notification email/push 卡 SENDING 即永久漏寄：email（`apps/worker/src/notification/notification-email.handler.ts:86-104`）與 push（Phase 33 M3 起同款 claim 機制）都以原子 `UPDATE ... SET *_status='SENDING' WHERE *_status='PENDING'` claim 後才寄送，若 process 在 SENDING 期間死亡（pod 重啟／OOM），該列狀態永遠停在 SENDING——之後任何重試都 claim 不到（非 PENDING），信件/推播靜默漏發，無補償機制。與 Phase 33 的「防重寄」修法方向相反（重寄防護正確依賴 SENDING 排他），需獨立設計補償（如 SENDING 超時掃描回退 PENDING＋attempts 上限，或 outbox 式 lease）。
Multi-agent coordination policies：ADR + 現況 event/artifact 協調文件化 + guardrail 測試（設計工作，非新子系統）
外部 queue provider 評估（GCP Pub/Sub + Cloud Tasks 或 Redis + BullMQ）
Production DB / R2 與 dev 拆分 cutover（乾淨起步）；屆時一併評估 HPA
Notification retention 分區/歸檔（仍不刪除）
Multi-replica 冪等強化殘項（Phase 33 M3 收尾分流）：(a) GitHub backfill（`runBackfill` 的 `backfillPullRequests`/`backfillIssues`/`backfillReleases`）逐筆 upsert transaction 未套 entity 級 advisory lock，與同 entity 即時 webhook 並行時為 last-write-wins 冗餘覆寫（cost-only，webhook 端已有鎖、per-link event 由 `detectAndPublish` repo 級鎖涵蓋）；(b) document extraction 的 OCR/LLM 呼叫在 lease 超時極窄窗口可能重複執行（資料/事件重複已由 `document_source_texts` unique index 擋下，僅成本），可選 per-documentVersion `pg_advisory_xact_lock` 消除。兩項皆非正確性缺口，依營運觀測（lease 超時頻率、backfill 使用頻率）決定是否補。
ADR 0012 BYO-keys 棧的 production live 驗證：取得 Anthropic（等）API key → capability binding 指向 → live smoke + browser smoke（原 items J/K 收斂；transport 與 binding 機制已於 2026-06-23 交付，剩驗證非實作）
真實 OCR / document extraction provider 接入（原 item L；ADR 0012 之後即 `VISION_OCR` slot 的 provider 選擇問題）：第一層 text-layer PDF，掃描件再評估；含成本/隱私/timeout/audit 設計
GitHub milestone drift detection（前置：milestone projection 或裁示 title-only weak matching）
高歧義 entity link AI ranking：AI 直接建 `github_entity_links` candidate rows（`created_by_kind = AI`），沿用既有 confirm/reject
Confirmed-link deterministic read model：把 `findConfirmedLinks()` ad hoc 直查升級為 materialized read model + invalidation（讀取路徑已運行，屬 hardening）
Transcript 候選的 thread 卡片連結（conversationId 反查或 event payload 補欄）
Extractor 模型升級評估（gpt-4o-mini → gpt-4o）
Edit 信號入校準迴路（標題大改的 update mutation 信號）
UPDATE 候選的 FK 欄位 matching（`milestoneId` / `ownerMemberId` 解析）
`.mp4` 視訊音軌提取（ffmpeg / cloud transcoding 評估）
Whisper 繁體輸出 OpenCC 確定性後備（現況為引導 prompt，非 100% 保證）
QA citation 深連結：collaboration 分頁 query-param 可定址（Plan/Decisions/Materials 現為 client-side `useState` tab）+ 物件/文件錨點定位 + ORG/USER scope citation 的 organizationId 穿線（Phase 12 as-built 僅 MEMORY_BLOCK(PROJECT)→memory 頁、其餘連 collaboration 頁或不連結，見 phase-12-implementation-plan.md §1.4）
`AiSuggestionStatus.SUPERSEDED` 語意與 DB constraint（原 Phase 8 item Q；varchar 無 enum constraint 的收斂）
→ 移至 known-bugs **KB-01**（2026-07-06；Maintainer 並行去重）
→ 移至 known-bugs **KB-05**（2026-07-06；prod worker replica 確認）
Demo quota 平台管理 CRUD（tenant ceiling / self-quota 調整 UI；目前僅 enforcement 生效，原 phase-11 plan 未竟項 2026-07-06 分流至此）
Maintainer 批次 pass 的 per-unit action rows 只有第一筆掛 proposal 的 `aiActionId`，其餘 unit 的 action 無反向關聯（KB-01 修復的已知設計債；目前無下游功能依賴，若未來要做「action → 產出 proposal」查詢/UI 需補關聯欄位）。同場觀察：advisory lock 專用連線橫跨 judge LLM 呼叫，多 group 平行時的連線池壓力值得加 metrics（2026-07-06 稽核報告）
Pattern-audit LPRC ordering check：擴充 `project-rule:audit-patterns` 的 pattern-auditor agent，新增 LPRC 稽核項（L1 zero-interpolation、no-static-after-dynamic、template-version 常數存在性）。需改共用 plugin 內 agent 邏輯（`rytass-claude-code/project-rule` marketplace plugin，非本 repo 檔案），影響範圍跨專案，需另行評估。來源：Phase 22 M6（2026-07-11）。
宣告式授權防線（defense-in-depth）：升級 `@rytass/member-base-nestjs-module` ^0.3.0（2026-07-07 上游已交付四開口：checker 注入 ExecutionContext/request、`casbinDomainResolver` 多 domain OR enforce、richer decision 掛 `request.casbinDecision`、`@HasPermission` 對齊），接 `casbinDomainResolver`（GraphQL args → project/org/tenant 三層 domain）＋在 root handler 逐步補 `@AllowActions`。**邊界**：service 層 `canForProject` guard 維持授權 SSOT 不拆；visibility 隱式存取（ORG_OPEN/ORG_INTERNAL）無 Casbin policy row，宣告層覆蓋範圍需避開或以自訂 checker 委派處理（見 phase spec 分析）。2026-07-07 權限盤點研究產出
Transactional email 送達性強化：2026-07-16 live 證據——reset-password 信在 Gmail 被標「看似危險」且連結被停用（SPF/DKIM/DMARC 對齊皆 pass、SendGrid 網域驗證 valid、Safe Browsing 無標記；判定為 heuristic 疊加：寄件網域 `rytass.com` 與連結網域 `kusabanabiyori.com` 錯配＋新網域信譽不足＋密碼重設措辭＋HTTP open-tracking 像素）。解法選單（依效果/成本）：(A1) per-message 停用 open tracking——nodemailer 加 `X-SMTPAPI` header `filters.opentrack.enable=0`，不動 SendGrid 帳號層級設定；(A2) HTML 樣板補完整文件結構＋可見網址文字＋品牌 footer；(B) 消除網域錯配——From 改 `noreply@lilas.kusabanabiyori.com`（SendGrid 對該網域做 domain authentication，需 DNS 權限）或產品改掛 `lilas.rytass.com`（產品決策）；(C) Google Postmaster Tools + Search Console 監測信譽。建議 A1+A2 先行，B 需確認 DNS/產品方向。
Worker 多 replica 水平擴展：解除 `workerDefaults.replicas: 1` 過時限制（2026-07-17 三方查證——`main.ts` / `values.yaml` 聲稱的 GitHub `requestManualSync` in-process mutex 已不存在，現行防重為 DB-backed `github_sync_runs`；claim 基礎設施 `FOR UPDATE SKIP LOCKED` + lease 本已 multi-replica safe）。放寬前缺口：(1) lease 預設 60s 不敵長任務（AI LLM 呼叫、demo build）致超時重複認領；(2) `ai_suggestions` ACTIVE 去重為 check-then-act 無 unique constraint（KB-17）；(3) `event_outbox` 無 `lease_owner` 可觀測；(4) handler 冪等未逐一審查（email 寄送不冪等）。設計決策見 [ADR 0028](../adr/0028-worker-horizontal-scaling.md)：靜態拉高 lease、DB partial unique index、冪等審查 gate、整包 ×2 + PDB；HPA 仍綁 BL-04、外部 queue 仍綁 BL-03。
Capture thread 內 grounded read-only Q&A（同對話框問答＋擷取並存：多意圖 triage、以提問者身分三層檢索、拒答 fallback 落 OPEN_QUESTION、回答持久化永不再擷取；設計決策見 [ADR 0019](../adr/0019-grounded-readonly-qa-in-capture-thread.md)，2026-07-06 產品裁示 D1–D4 已定）
W1 Backlinks：反向引用查詢 + 面板（1 個 index migration）
W2 Vault export：唯讀 markdown zip 匯出 + audit event
W3 Wikilinks：`[[#block-id]]` 解析 → REFERENCES 邊 reconcile
W4 Dynamic views：block metadata 過濾視圖（Wave B 才加 saved views 表）
**Phase 28 relation coverage / review volume 校準**：S0-S14 after 為 511 ACTIVE blocks、cosine >= 0.85 跨檔 54 對（before 426 blocks / 33 對），pair density 0.0456% -> 0.0533%；雖建立 50 wikilink REFERENCES，但僅 3 條直接覆蓋該 54 對，另有 57 READY/HIGH（14 multi-file）待人審。2026-07-15 使用者裁示採 measurement-first 推進：relation/proposal-aware audit、明確 oracle、原 Encore 全量重放＋多組隔離 fixture，證明合法共存、destructive recall 與 pending churn 收斂；不得先降 band `0.70` / top-K `5`，Decision 5 仍待證據。**→ Phase 31 underway**。
Cross-organization / cross-tenant intelligence decision record + isolation guardrails（僅文件與守衛，無資料流）
Quota 硬擋 / 付費方案（目前 AI budget 超標僅通知不中斷）
External sharing / guest-seat 產品決策：是否需獨立 `external_collaborator` role，或維持 guest seat + 補文案/quota/sharing UX（原 Phase 8 item P，詳見 [`archive/phase-8-post-launch.md`](./archive/phase-8-post-launch.md)）
Per-thread intake 開關（`conversations.intake_disabled`）
Passkey authentication：在既有 `@rytass/member-base-nestjs-module` + JWT + Casbin 架構上新增 Lilas-owned WebAuthn credential layer（`member_passkeys` + one-time challenge store），支援登入後綁定、discoverable Conditional UI 與 email-first passkey fallback；不改 `members.password`、不重寫 cookie/session 模型、不做 passkey-only sign-up。設計決策見 [ADR 0022](../adr/0022-passkey-authentication.md)。
Provider key 全面去 env：移除 credential `env_fallback` column ＋ legacy `ModelRouter`/adapter/5 個 env-reading transport，12 個 worker handler 翻成 resolver-only，`OPENAI_API_KEY`/`ANTHROPIC_API_KEY` 從部署 env 退役。設計決策見 [ADR 0021](../adr/0021-eliminate-provider-env-keys.md)，2026-07-08 產品裁示上 Scope L。涵蓋原 BL-08 剩餘的 production live 驗證（resolver-only 全鏈 live e2e）。
Server 端上傳 bytes 與宣告 contentType 的一致性驗證：現行白名單為純宣告制（`createPendingUploadObject` 於 bytes 到達前驗證、`uploadDocumentBytes` 不嗅探內容），client 可宣告任意白名單型別上傳任意 bytes——既有信任模型缺口，非 2026-07-07 client 端純文字嗅探（未知副檔名 → sniff → text/plain）所引入；補法：PUT bytes 時 server 端嗅探與宣告型別一致性檢查
Conversation knowledge intake reclassification：Phase 18 已完成 `STANDING_FACT` immediate intake MVP，但未開 work ↔ knowledge / knowledge type ↔ knowledge type reclassification。後續需設計 GraphQL input 支援 `targetKind` / `knowledgeType`，至少先支援 work → `STANDING_FACT`、`STANDING_FACT` → work，並保留校準信號。
Knowledge candidate edit-before-confirm：Phase 18 memory candidate UI 暫時隱藏 inline edit；後續需補 `STANDING_FACT` 的 entity / attribute / value / detail 編輯表單與 server-side typed validator，再擴展到其他 knowledge payload。
Reserved knowledge type executable rollout：Phase 18 只保守 reserve `GLOSSARY_TERM` / `REQUIREMENT` / `EPISODIC_NOTE` / `PROCEDURAL_RULE` schema + UI label；後續需逐類啟用 extractor normalization、canonical file mapping、proposal rendering、risk semantics 與 tests。
First-class intake calibration dimensions：Phase 18 以 `DOCUMENT` compatibility sentinel + exemplar JSON note 記錄 memory candidate calibration；後續需把 target family / knowledge type 升為 first-class calibration key 或欄位，避免長期污染 object-type analytics。
Knowledge intake dedup fingerprint：Phase 18 consolidation dedup 先用 overlapping source refs 避免同訊息重複 `facts.md` proposals；後續需加入 entity/attribute/value fingerprint 或 canonical block fingerprint，處理不同訊息重述同一 fact 的重複 proposal。
W5 Unlinked mentions：偵測器 + AI suggestion（新 enum 值含 i18n）
W6 Local graph：一跳關係圖 UI
Reconcile 近義重述召回與跨檔收斂。Phase 27 已完成稽核、pending supersede、glossary/attribution、judge rubric 第一段；2026-07-13 新 Encore 重放（project `fee443bd-8b04-4db6-afe3-3a3b8d2143ee`、branch `ed511f31-1bf0-4c63-95f6-6ee8c83c5720`，`pnpm memory:audit --branch <id> --json`）after 仍有 40 對近重複（同檔 7、跨檔 33），跨檔占 82.5%；flat -> points 與 monthly -> weekly 兩類均以 destructive UPDATE proposal 正確指向舊 block，recall 2/2。I5 結構性方案見 [ADR 0027](../adr/0027-entity-anchored-cross-file-reconciliation.md)。
`facts.md` standing-facts 記憶層實作（[ADR 0020](../adr/0020-standing-facts-memory-layer.md)，Accepted implemented）：新 canonical 檔（SEMANTIC、AI 可寫、參與 decay + bi-temporal supersede）＋entity-anchored proposition 格式（復用 ADR 0013）＋entity index MVP（read-side projection，不把 JSON 混入 canonical markdown parser）＋maintainer/consolidation 抽取改派（KB-08 指引 requirements→facts、對話事實入 facts）＋requirements.md 130+ 誤置列遷移。2026-07-08 後續產品裁示補 immediate intake → knowledge rail，另立 [ADR 0023](../adr/0023-conversation-knowledge-intake.md) / Phase 18，不回填 Phase 15。**→ Phase 15 completed**（2026-07-09；core implementation、M8 migration、live e2e、KB-11 retest 已完成）
Lilas MCP capture and recall adapter：讓 Claude / Codex / Cursor 等本地或 remote MCP host 可將 AI 工具收集到的研究、筆記、摘錄與脈絡送進 Lilas capture thread，並以使用者身份做 bounded memory recall。設計決策見 [ADR 0024](../adr/0024-mcp-capture-and-recall-adapter.md)。**→ Phase 21 completed（2026-07-10；local stdio + remote OAuth verified）**。
`lilas-capture` skill 帳號頁服務化發佈：`docs/integrations/mcp-skill/`（2026-07-14 建立）的 user-scoped Agent Skill + CLAUDE.md/AGENTS.md hint 目前為手動複製安裝；後續可由 account MCP setup guide 動態產生含正確 API base 的 skill 下載包與 hint 文字，並評估另建公開 repo 走 Claude Code plugin marketplace 推送更新。MCP tool 介面變更時須同步更新該目錄（SSOT：`libs/mcp/src/lib/mcp-tool-contracts.ts`）。**→ Phase 30 completed（2026-07-15 live e2e PASS；帳號頁 host × scope 四組合指南＋api skill endpoint＋curl 安裝；marketplace 評估仍留本檔未排程）**
Prompt cache governance 與 conversation context assembly：跨 provider cache-aware invocation 抽象（segments + cacheHint）、LPRC 三層 prompt 渲染慣例（含 5 個既有排序 offender 修正）、`ai_actions` cache-token 欄位與 `ai_model_prices` cache 費率的成本量測、intake 對話管線共享前綴模式、`authoring-cacheable-prompts` project skill、GPT-5.6（explicit breakpoint / 1.25× write / prompt_cache_key）就緒。設計決策見 [ADR 0025](../adr/0025-prompt-cache-governance-and-context-assembly.md)。**→ Phase 22 completed（2026-07-11；OpenAI 路徑 live 驗證 VERIFIED，Anthropic/GPT-5.6 config-gated）**。
Scheduler workload prompt LPRC 重排＋1h marker：consolidation / reflection / skill-induction / maintainer 主抽取的 prompt 前綴目前為 static 與插值交錯（`project_id=`、evidence、languageDirective 混在單一字串），無法標 stable marker。需比照 Phase 22 M3 模式重排為 L1/L3＋golden 迴歸，再掛 `ttl:'1h'`。這些是 ADR 0025 點名的高重複、latency-insensitive workload，重排後收益最大。來源：Phase 22 M5 零插值檢查（2026-07-11）。
通知聚合與 seen 語意：read-time grouping（`aggregate_key`，可聚合類別摺疊為「N 則」群組節點）+ `seen_at` 欄位（badge = unseen、開 Drawer 即 markAllSeen 歸零，`read_at` 語意不變）。解 99+ 同型通知洪水（live 證據 2026-07-10）與「badge 只能靠標已讀歸零」的 UX 缺口。設計見 [ADR 0026](../adr/0026-notification-aggregation-and-seen-semantics.md)。來源：2026-07-12 通知系統稽核（Phase 23 範圍外分流）。**→ Phase 24（2026-07-12，ADR 0026 同日核可）**
build(status-page): invoke wrangler via pnpm dlx
docs(roadmap): record phase 34 delivery, close KB-15 and KB-18
fix(notification): recover notifications stuck in SENDING via claim timeout
fix(mcp): distinguish missing conversation pairing from frozen target
feat(client): add platform admin shortcut to project status page
ci(deploy): publish status page after production rollout
feat(status-page): add project status dashboard app and build-time collector
docs(roadmap): mark phase 33 production rollout complete
docs(roadmap): record phase 33 delivery, close KB-17, add KB-18 and BL-53
build(deploy): scale worker to 2 replicas with PDB and lease overrides
feat(db): register phase 33 migrations
fix(worker): make document source text insert atomic against re-claims
fix(github): serialize projection state-transition detection with advisory locks
fix(notification): claim web push dispatch via push_status state machine
feat(event-core): record outbox lease owner on claim
fix(ai-core): enforce DB-level dedup for ACTIVE AI suggestions
docs(roadmap): record phase 33 worker horizontal scaling spec, ADR 0028, BL-52 and KB-17
style(tenant): format resolver per prettier
docs(roadmap): record phase 32 email deliverability spec and BL-51
docs(roadmap): add phase 28/31 specs and sync reconcile plan records