phase: 94_ls_tree_drilldown

All green. Verification complete.

**Phase 94 — `ls` drill-down tree: final verification pass (all 5 tasks were already complete; verified, nothing to fix)**

- Verified `ls` 3-level tree (`app/rag/agent.py`): `ls()` sources + summaries, `ls(source)`/`ls(source/folder)` drill-down, 50-line file cap + grep-pointer note, NOT-A-FOLDER teaching refusal
- Verified `folder_summaries` (migration 0017, model, `app/rag/folder_summaries.py` generator: `FOLDER_SUMMARY_MODE` marker, fail-soft per folder, ≥2-doc scope + prune) wired change-gated in both sync paths
- Verified 10-turn fixture battery verdict recorded in `TOOL_CALLING_TESTING.md` §9 (2026-09-11): turbo PASS 19/19 contract, 98.7 s (−12.5…−13.2 % vs baseline); lite PASS 18/18, 43.6 s (+7.7 %) — accuracy at/above baseline, gate met
- `uv run pytest --cov=app --cov-report=term-missing` → 1939 passed, 0 failed; TOTAL coverage **99 %** (folder_summaries.py 100 %)
- `uv run ruff check .` → clean; `uv run pyright` → 0 errors, 0 warnings
- E2E in isolation: `test_ls_tree_drilldown.py` 3 passed; `test_agent_document_tools` 4, `test_agent_unlimited_tools` 4, `test_harness_aligned_tools` 3, `test_search_tool` 3, `test_grep_regex_teaching` 2, `test_response_to_docs` 4 — all passed (read/grep contracts untouched)
- Dedicated folder-summary tests (fail-soft, prune, both sync paths, migration): 46 passed
- Completion criteria: all 6 met; working tree holds only phase-94 changes (commit left to harness per protocol)

**Next pending phase:** `95_read_truncation_cap`

scripts/restore_test_kb.py

@@ -11,11 +11,13 @@ snapshot in **one transaction** through the app's own database URL
 (``BOR_DATABASE_URL``): no git clone of the homelab repo, no re-embedding,
 no ``lite``-model calls — the whole known state (documents, chunks +
 embeddings, the source registry rows, the KB overview, the sources
-version) lands in a fraction of a second, which is what makes a
-tool-calling iteration loop fast (see ``TOOL_CALLING_TESTING.md``):
+version, the stored folder summaries — the drill-down ``ls``'s rows,
+phase 94, task 05) lands in a fraction of a second, which is what makes
+a tool-calling iteration loop fast (see ``TOOL_CALLING_TESTING.md``):
 
     uv run python -m scripts.restore_test_kb
-    # restore_test_kb: ok in 0.41s (8 docs, 2 sources, 16 chunks)
+    # restore_test_kb: ok in 0.41s (8 docs, 2 sources, 9 chunks,
+    # 4 folder summaries, dump … KB)
 
 The gate runs the same restore inline:
 ``uv run python -m scripts.agent_realmodel_check --restore``.
@@ -57,6 +59,10 @@ APP_TABLES: tuple[str, ...] = (
     "query_log",
     "saved_chats",
     "doc_drafts",
+    # Phase 94 (task 05): the sync-time folder summaries the drill-down
+    # ``ls`` shows — the dump carries the rows (built by
+    # ``scripts.load_test_kb`` against the live ``lite`` endpoint).
+    "folder_summaries",
 )
 
 #: Repo-relative default dump location (the load script writes it there).
@@ -71,6 +77,7 @@ class RestoreResult:
     docs: int
     sources: tuple[str, ...]
     chunks: int
+    folders: int  # stored folder summaries (phase 94)
     dump_bytes: int
 
 
@@ -127,11 +134,13 @@ def restore_dump(dump: Path) -> RestoreResult:
             )
         )
         chunks = db.execute(text("select count(*) from chunks")).scalar_one()
+        folders = db.execute(text("select count(*) from folder_summaries")).scalar_one()
     return RestoreResult(
         seconds=seconds,
         docs=docs,
         sources=sources,
         chunks=chunks,
+        folders=folders,
         dump_bytes=dump.stat().st_size,
     )
 
@@ -169,7 +178,8 @@ def main(argv: list[str] | None = None) -> int:
     print(
         f"restore_test_kb: ok in {result.seconds:.2f}s "
         f"({result.docs} docs, {len(result.sources)} sources, "
-        f"{result.chunks} chunks, dump {result.dump_bytes // 1024} KB)"
+        f"{result.chunks} chunks, {result.folders} folder summaries, "
+        f"dump {result.dump_bytes // 1024} KB)"
     )
     return 0