Establish a safe foundation before implementing the geology RAG system

The project begins with architecture, data governance, reproducible evaluation, deployment boundaries, and secret-handling contracts so later code has measurable acceptance criteria.

Constraint: Real provider credentials, workspace identities, and restricted geological data must never enter Git

Rejected: Add placeholder runnable services in the design commit | would imply unverified implementation readiness

Confidence: high

Scope-risk: narrow

Reversibility: clean

Directive: Run make verify before every commit and update ADRs when architecture boundaries change

Tested: Secret scan, Markdown links, YAML parse, shell syntax, and staged diff validation

Not-tested: Application runtime is intentionally deferred to the implementation stage

AGENTS.md

@@ -0,0 +1,9 @@
+# Repository Working Agreement
+
+- Never commit a real API key, `.env`, Docker secret, private document, or restricted evaluation sample.
+- Keep backend code under `backend/`, frontend code under `frontend/`, and all design decisions under `docs/`.
+- Prefer a modular monolith and small, reviewable changes. Do not introduce a new service or dependency without documenting why it is needed.
+- Preserve traceability from every answer citation to a document version, page, section, and chunk.
+- Run `make verify` before every commit and push each verified delivery stage.
+- Update or add an ADR when changing the vector store, model API mode, embedding dimension, chunking contract, or deployment topology.
+- Do not claim that OCR of a map is equivalent to spatial understanding of the map.