# Backend boundary

Status: architecture draft; implementation MUST live in a separate repository.

## Purpose

AI.TORCH is both a road multitool and a voice communicator between its user and an AI system. The backend handles expensive, networked and account-bound work while the device remains useful offline.

## V1 responsibilities

- device enrollment and scoped credentials;
- idempotent request ingestion and encrypted outbox acknowledgements;
- voice object upload and speech-to-text adapter;
- model/session routing;
- device capabilities represented as discoverable AI tools;
- concise response and text-to-speech adapter;
- message synchronization;
- map-pack metadata and route summaries;
- RSS fetch/deduplication/digest;
- SIP account state and call signaling adapter;
- audit metadata, retention policy and deletion.

## Explicitly not V1

- general remote shell;
- always-on cloud microphone;
- arbitrary third-party plugins with device credentials;
- server-required operation of flashlight, sensors, mesh or cached maps;
- raw private telemetry by default.

## Repository contract

The separate repository starts with:

- `openapi.yaml` and event contract;
- JSON Schemas and generated typed client;
- `llms.txt` and `AGENTS.md`;
- local development stack with fake ASR/LLM/TTS providers;
- deterministic fixtures for voice, map, RSS, messaging and SIP;
- CI lint, schema validation, unit/integration tests and container build;
- deployable service definition consumed by the existing `habibi/services` CI flow.

## Deployment note

The local services repository contains validation and production deployment jobs, but its latest inspected GitLab pipeline (#85, 2026-09-20) failed in `deploy-habibi` because `sudo` was blocked by `no new privileges`. Treat deployment as blocked until that runner configuration is repaired and a green deploy pipeline is observed.