> For the complete documentation index, see [llms.txt](https://faction-os.gitbook.io/faction-os-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://faction-os.gitbook.io/faction-os-docs/.spec_system/archive/phases/phase_01/session_06_llm_fallback_and_scan_privacy.md).

# Session 06: LLM Fallback and Scan Privacy

**Session ID**: `phase01-session06-llm-fallback-and-scan-privacy` **Package**: apps/server **Status**: Not Started **Estimated Tasks**: \~16-22 **Estimated Duration**: 2-4 hours

***

## Objective

Preserve deterministic no-key LLM behavior while hardening scan, analysis, memory, and provider-transfer boundaries for local developer data.

***

## Scope

### In Scope (MVP)

* Verify deterministic fallback behavior for plan, analyze, scan, idle suggestion, and memory routes.
* Add or document explicit provider-transfer boundaries when `ANTHROPIC_API_KEY` is configured.
* Tighten scan root handling, ignored directories, file caps, and secret/path scrubbing.
* Keep `EXAMPLES/` and historical artifact directories ignored by default scans.
* Add tests for no-key fallback, provider-enabled call boundaries, scan caps, and malformed file inputs.
* Update docs for LLM privacy and local-only behavior.

### Out of Scope

* Adding new hosted LLM providers.
* Transcript-mining UI redesign.
* Hosted analytics or account-backed storage.

***

## Prerequisites

* [ ] Current LLM route tests and prompt engines are reviewed.
* [ ] `codebaseWalker` ignore behavior is reviewed.
* [ ] Security findings M-002 and M-003 are considered.

***

## Deliverables

1. Hardened LLM route validation and scan privacy behavior.
2. Focused tests for deterministic fallback, bounded scans, ignored historical directories, and provider-transfer warnings or controls.
3. Server README and privacy docs updates for LLM behavior.

***

## EXAMPLES Implementation Sources

| Source                                             | Feature / Contract                                                                                                             | Tests Required                                                                                                                   | Documentation Owner                                                    |
| -------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------- |
| `EXAMPLES/findings/api-routes.txt`                 | LLM route inventory, memory route expectations, and analysis route behavior                                                    | Route tests for plan, analyze, scan, idle, memory, and unsupported historical LLM routes                                         | `docs/api/README_api.md`, `apps/server/README_server.md`               |
| `EXAMPLES/findings/architecture.md`                | Historical LLM, memory, suggestion, auto-improver, scan, summary, and transcript module map                                    | Validation checklist that identifies which LLM modules are Phase 01 runtime hardening and which remain later-phase orchestration | `docs/ARCHITECTURE.md`, `docs/legacy-consolidation.md`                 |
| `EXAMPLES/findings/BUILD_LINKS.md`                 | Traceability from recovered LLM findings to current implementation                                                             | Validation checklist linking LLM decisions to docs and tests                                                                     | `docs/legacy-consolidation.md`                                         |
| `EXAMPLES/findings/claude-hook-contract.md`        | Prompt and event data that may flow into analysis or memory                                                                    | Tests that high-risk hook-derived fields are bounded or redacted before external transfer where applicable                       | `docs/privacy-and-security.md`, `docs/api/event-api-hook-contracts.md` |
| `EXAMPLES/findings/llm-prompts/`                   | Original prompt behavior for plan decomposition, on-demand analysis, idle suggestions, transcript mining, and auto-improvement | LLM fallback and prompt-engine tests for bounded inputs, deterministic no-key outputs, and provider-call guards                  | `apps/server/README_server.md`, `docs/privacy-and-security.md`         |
| `EXAMPLES/1st-pass-artifacts/agent-templates.json` | Original task template affordances that can affect plan generation and future orchestration                                    | Tests or docs that preserve template requirements as deferred if not implemented in Phase 01                                     | `docs/legacy-consolidation.md`                                         |

***

## Success Criteria

* [ ] LLM routes return deterministic useful fallback responses without provider credentials.
* [ ] Codebase scan refuses dangerous roots, respects caps, and ignores `EXAMPLES/` by default.
* [ ] Provider-bound analysis has documented privacy expectations and tested guardrails.
* [ ] Memory routes reject unsupported types and avoid broad raw data exposure.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://faction-os.gitbook.io/faction-os-docs/.spec_system/archive/phases/phase_01/session_06_llm_fallback_and_scan_privacy.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
