The build order starts with milestone 1 and milestone 2, then keeps the
earlier stages in their order, less what the two milestones build.
Milestone 2 builds the container image with runit and the health check,
so it answers /_smallwebwaf/healthz before the other admin endpoints.
The four body-size settings become SWWAF_REQUEST_MAX_BYTES and
SWWAF_RESPONSE_MAX_BYTES, since bodies pass through unchanged; the four
timeouts stay.
GeoJS answers are kept in memory; lookups.json comes in milestone 3 or
later, as sneak ruled.
README.md: the two sentences this change made wrong.
Model: opus-5-5
SPEC.md and README.md now describe sneak's recommended deploy: an app's Dockerfile builds FROM the smallwebwaf image, and runit, started by runsvinit, runs smallwebwaf on :8080 in front of the app on 127.0.0.1:8081, so no setting is required. The spec covers what the app's Dockerfile adds, the users each process runs as, restarts, the health check, ports, the state directory and its volume, the app trusting loopback for forwarded headers, and upaas needing no change. An example app Dockerfile replaces the docker-compose examples. Every setting carries the SWWAF_ prefix, the file form too, and "sidecar" no longer names the deploy shape.
Model: opus-5-5
SPEC.md and README.md now state the resolutions of the old questions section and sneak's later requirements: seven-day bans for clear signs of attack and short, tripling bans for broken limits; state files that follow memory and take in edits while running; ban notes and per-client history; size and time limits in both directions; country deny and allow-only lists; GeoJS as the default lookup source; one listener for everything. The defaults are chosen so that a sidecar with only UPSTREAM_URL set protects an app on the open internet; the Core Rule Set reads no request bodies by default. Choices made where his words left a gap are listed in the PR. Gitea requests the defaults may still refuse are collected in a follow-up issue.
Model: opus-5-5
Initial documents: what smallwebwaf is and why, the proposed feature list, the design spec with the rule file format and the open design questions, and the survey of existing tools.
Model: fable-5-1