docs: classify architecture inventory and refresh guidance

docs/ARCHITECTURE.md

@@ -0,0 +1,87 @@
+# Architecture
+
+> [!NOTE]
+> This document is the proposed canonical destination for stable high-level
+> architecture facts. It remains subject to maintainer review. Source code,
+> tests, and configuration remain authoritative for implementation-sensitive
+> behaviour.
+
+## Purpose
+
+This document identifies the stable runtime boundaries and primary ownership
+locations used to navigate and extend Odysseus.
+
+It intentionally excludes generated metrics, file-size rankings, refactor
+priorities, unresolved investigation findings, and proposed package layouts.
+
+## Runtime structure
+
+| Area | Responsibility |
+|---|---|
+| `app.py` | FastAPI application composition and primary application entry point |
+| `launcher.py` | Application launch support |
+| `setup.py` | Native setup workflow |
+| `core/` | Authentication, middleware, persistence, sessions, and platform primitives |
+| `routes/` | HTTP and API route handlers |
+| `src/` | Application orchestration, tools, providers, and runtime helpers |
+| `services/` | Domain-oriented service implementations |
+| `mcp_servers/` | Built-in MCP server implementations |
+| `scripts/` | CLI tools, diagnostics, maintenance, and migration helpers |
+| `static/` | No-build browser frontend and bundled assets |
+| `tests/` | Automated tests and supporting test infrastructure |
+
+## Subsystem boundaries
+
+| Subsystem | Primary implementation locations |
+|---|---|
+| Application startup | `app.py`, `src/app_initializer.py`, `core/` |
+| Authentication and sessions | `core/auth.py`, `core/middleware.py`, `core/session_manager.py`, `routes/auth_routes.py` |
+| Chat and streaming | `routes/chat_routes.py`, `routes/chat_helpers.py`, `src/chat_handler.py`, `src/chat_processor.py`, `src/llm_core.py` |
+| Agents and tools | `src/agent_loop.py`, `src/tool_execution.py`, `src/agent_tools/`, `src/tools/`, `src/tool_policy.py`, `src/tool_security.py` |
+| Models and providers | `routes/model_routes.py`, `src/model_discovery.py`, `src/model_capabilities.py`, `src/endpoint_resolver.py`, `src/llm_core.py` |
+| Cookbook and hardware fit | `routes/cookbook_routes.py`, `routes/cookbook_helpers.py`, `src/cookbook_serve_lifecycle.py`, `services/hwfit/` |
+| Search and research | `routes/search_routes.py`, `services/search/`, `routes/research/`, `services/research/`, `src/deep_research.py` |
+| Documents and retrieval | `routes/document_routes.py`, `src/document_processor.py`, `src/personal_docs.py`, `src/rag_manager.py`, `src/pdf_runtime.py` |
+| Memory and skills | `routes/memory/`, `services/memory/`, `routes/skills_routes.py` |
+| Email | `routes/email_routes.py`, `routes/email_helpers.py`, `routes/email_pollers.py`, `mcp_servers/email_server.py` |
+| Calendar, contacts, notes, and tasks | `routes/calendar_routes.py`, `routes/contacts/`, `routes/note/`, `routes/task_routes.py`, `src/task_scheduler.py` |
+| Media and speech | `routes/gallery/`, `routes/stt_routes.py`, `routes/tts_routes.py`, `services/stt/`, `services/tts/` |
+| Persistence and operations | `core/database.py`, `src/runtime_paths.py`, `src/bg_jobs.py`, `routes/backup_routes.py`, `routes/cleanup/` |
+
+## Architectural constraints
+
+- Preserve established import and compatibility paths unless a focused change
+  explicitly migrates them.
+- Keep HTTP concerns in route modules and reusable domain behaviour in runtime
+  or service modules.
+- Treat shared persistence, agent orchestration, tool execution, and application
+  startup as high-authority boundaries.
+- Change one ownership boundary at a time.
+- Do not mix structural movement with unrelated feature behaviour.
+- Validate affected imports, startup paths, compatibility surfaces, and tests.
+
+## Frontend
+
+The browser frontend is a no-build ES-module application under `static/`.
+
+Its maintained module-level structure is documented in
+[`static/js/MODULE_SUMMARY.md`](../static/js/MODULE_SUMMARY.md).
+
+## Investigation and snapshots
+
+Non-canonical investigation material is maintained under [`discovery/`](../discovery/).
+
+The following documents may contain dated observations, metrics, unresolved
+questions, or historical planning and must not be treated as specifications:
+
+- [`discovery/system-map.md`](../discovery/system-map.md)
+- [`discovery/architecture-runtime-inventory.md`](../discovery/architecture-runtime-inventory.md)
+
+## Documentation authority
+
+- Code, tests, and configuration define implemented behaviour.
+- Mature specifications define accepted subsystem behaviour where they exist.
+- Following maintainer acceptance, this document will define the high-level
+  architecture map.
+- Discovery documents preserve evidence and uncertainty but remain
+  non-canonical.

docs/STYLE.md

@@ -0,0 +1,72 @@
+# Documentation style
+
+This guide defines the shared structure and writing conventions for Odysseus documentation.
+
+## Principles
+
+- Write for a clear audience and purpose.
+- State whether a document is canonical, informational, a snapshot, or planning material.
+- Prefer current behaviour over historical explanation.
+- Link to source files, tests, issues, or other documentation when useful.
+- Separate verified behaviour from assumptions, open questions, and future work.
+- Keep headings descriptive and consistent.
+- Use Markdown callouts where status or risk must be visible.
+- Do not use emojis.
+
+## Document status
+
+Use a status callout near the top when the document is not normal canonical guidance.
+
+### Canonical documentation
+
+> [!IMPORTANT]
+> This document describes accepted current behaviour. Verify implementation-sensitive details against the current code and tests.
+
+### Discovery material
+
+> [!NOTE]
+> This is non-canonical discovery material. It records code-grounded observations and open questions.
+
+### Snapshot or inventory
+
+> [!WARNING]
+> This document is a dated snapshot. Counts, paths, and implementation details may drift as the codebase changes.
+
+### Planning material
+
+> [!NOTE]
+> This document records planning context. It does not define current runtime behaviour or guarantee future implementation.
+
+## Recommended structure
+
+Use the following sections where relevant:
+
+1. Title
+2. Purpose or status callout
+3. Scope
+4. Current behaviour or guidance
+5. Safety, limitations, or known gaps
+6. Validation or evidence
+7. Related documentation
+
+Not every document needs every section.
+
+## Writing style
+
+- Use concise sentences.
+- Prefer direct language.
+- Avoid jokes, filler, and informal warnings.
+- Avoid repeating the same guidance across several files.
+- Link to the owning document instead of duplicating large sections.
+- Use lists for procedures, requirements, and comparisons.
+- Use tables only when they improve scanning.
+- Use fenced code blocks with an appropriate language identifier.
+- Use relative repository links for internal files.
+
+## Authority
+
+The current code, tests, and configuration are the source of truth for implemented behaviour.
+
+Canonical documentation describes accepted behaviour and supported workflows.
+
+Discovery, inventory, and planning documents must identify themselves explicitly and must not silently become behavioural specifications.

docs/pr-blocker-audit.md

@@ -181,8 +181,8 @@ Dirty, blocked, conflicting, and unknown merge states are shown as risk/caution
 ## Validation
 
 ```bash
-python3 -m py_compile scripts/pr_blocker_audit.py tests/test_pr_blocker_audit.py
-python3 -m pytest tests/test_pr_blocker_audit.py -q
+venv/bin/python -m py_compile scripts/pr_blocker_audit.py tests/test_pr_blocker_audit.py
+venv/bin/python -m pytest tests/test_pr_blocker_audit.py -q
 python3 scripts/pr_blocker_audit.py --help
 git diff --check
 ```