Files
internet_use_control/docker-compose.yml
Sam Rolfe 3cf353d933 Phase 9: Hub API and Apprise alerts (/capabilities, /ask, /notify)
Build on Phases 1-8. Adds the project side of the frozen Hub contract
(central_ai_llm_master/docs/ask-contract.md) and the alert engine from
AGENTS.md §4 FR-12/FR-13, §8, §11 Phase 9.

- hub: internal/hub implements AskRequest/AskResponse/NotifyRequest and a
  deterministic, read-only Answerer. It answers screen time today/yesterday,
  what is blocked now, and device presence, scoped to one child or all kids.
  Screen time is the foreground-app total per device-day; the domain total is
  used only when a device reports no apps, so a report carrying both is never
  double-counted.
- apprise: internal/apprise is a small Apprise API client (stored key or
  stateless URL mode, optional bearer token, typed notifications).
- alert: internal/alert evaluates device state on an interval and raises one
  Apprise alert per transition: a limit hit (a device becomes blocked) or a
  device offline longer than the threshold. A never-seen device is never
  alerted, and the first observation seeds state without replaying an old
  limit. The alert is recorded before delivery, with its delivery outcome.
- store: migration 005 adds `alerts` (delivery outcome, audited) and
  `alert_state` (per-device dedup). New usage reads from the telemetry detail
  table so the daily answer can be checked independently.
- web: GET /capabilities, POST /ask (read-only) and POST /notify behind the
  shared CONTROL_HUB_TOKEN, separate from the session and admin API tokens.
  /notify accepts the contract's {from,level,message,person} and delivers it
  through Apprise (the future tamper-report path, FR-17).
- cmd/control: start the alert engine (CONTROL_ALERTS_ENABLED,
  CONTROL_ALERT_OFFLINE_AFTER, CONTROL_ALERT_INTERVAL) and add `alerts` and
  `usage` subcommands for read-only inspection.
- deploy/verify-phase9.sh + `make verify-phase9` prove the definition of done;
  version 0.7.0-phase9.

Measured on .13 (2026-10-13):
- GET /capabilities -> internet_use_control topics.
- POST /ask "how long have the kids been on screens today?" -> "The kids have
  had 1h 22m of screen time today." (total_seconds=4925); the independent
  count from the telemetry detail table is also 4925 (app=4925, domain=4800).
- A manual lock raised a delivered limit alert (id 4); an MQTT offline status
  raised a delivered offline alert (id 5); POST /notify delivered (id 6). All
  three report delivered=1 in `alerts`.

Tests: gofmt, go vet ./... and go test ./... pass in golang:1.25-alpine.

Co-Authored-By: Paperclip <noreply@paperclip.ing>
2026-10-13 16:41:07 +11:00

47 lines
1.5 KiB
YAML

# Internet Use Control — Control Service (own image, own container, own port).
# Deploy on .13: cd /home/sam/paseo/projects/internet_use_control && docker compose up -d --build
# The service is the single source of truth (SYSTEM_MAP.md). Only it publishes config.
#
# MQTT is transport, not storage: the service publishes retained config to the
# shared Mosquitto on `.13:1883` and writes what devices report into SQLite.
name: webrestrict
services:
control:
build:
context: .
args:
VERSION: "0.7.0-phase9"
image: webrestrict/control:0.7.0-phase9
container_name: webrestrict-control
restart: unless-stopped
env_file:
- environment.d/control-service.env
ports:
- "8791:8791"
# The broker is the Mosquitto container on the host. No host IP is baked
# in: the gateway is resolved at start, so CONTROL_MQTT_BROKER can stay
# "tcp://host.docker.internal:1883".
extra_hosts:
- "host.docker.internal:host-gateway"
volumes:
- webrestrict-data:/data
# The lab CA for broker TLS verification. Read-only and optional: the
# file is absent until the TLS listener exists.
- ./deploy/mosquitto/tls:/etc/webrestrict/tls:ro
healthcheck:
test: ["CMD", "wget", "-qO-", "http://127.0.0.1:8791/health"]
interval: 30s
timeout: 5s
retries: 3
start_period: 10s
logging:
driver: json-file
options:
max-size: "10m"
max-file: "3"
volumes:
webrestrict-data: