platform/crucible-agent-build-fastapi-endpoint
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

decomposer: generate deliverable files for Define the service contract and project architecture for the FastAPI endpoint monitoring service.; Implement the typed monitor CRUD API and concurrency-safe in-memory state according to the service design.; Implement secure on-demand endpoint checks with status updates, latency measurement, robust error handling, and redacted structured logs.; Add operational API endpoints and environment-driven runtime configuration to the monitoring service.; Create automated tests for the monitoring service.; Package the service with Docker and developer documentation.; Validate the complete project.
Some checks are pending
ci / validate (push) Has started running
Details

Browse Source
This commit is contained in:
demo-bot
2026-08-09 15:41:05 +00:00
parent 9e76d6ae92
commit 806aa0779b
1 changed files with 11 additions and 18 deletions
Download Patch File Download Diff File Expand all files Collapse all files

29
docs/verification.md
View File

@@ -1,30 +1,23 @@
# Verification report # Verification record and runbook
## Reproducible validation commands The repository contains executable validation rather than a CI-only claim. Run from a clean checkout with Python 3.12:
Run these from the repository root in a Python 3.12 environment:
```bash ```bash
python -m pip install -e '.[dev]' python -m venv .venv
. .venv/bin/activate
pip install -e '.[dev]'
ruff format --check . ruff format --check .
ruff check . ruff check .
mypy app mypy app
pytest pytest -q
docker build -t endpoint-monitor:verify . docker build -t endpoint-monitor:verify .
docker run --rm -d --name endpoint-monitor-verify -p 18000:8000 endpoint-monitor:verify docker run -d --rm --name endpoint-monitor-verify -p 18000:8000 endpoint-monitor:verify
curl --fail http://127.0.0.1:18000/healthz curl --fail http://127.0.0.1:18000/healthz
curl --fail http://127.0.0.1:18000/readyz curl --fail http://127.0.0.1:18000/readyz
docker rm -f endpoint-monitor-verify curl --fail -H 'content-type: application/json' -d '{"name":"example","url":"https://example.com"}' http://127.0.0.1:18000/monitors
docker stop endpoint-monitor-verify
``` ```
## Coverage represented in the suite `pytest` covers CRUD, status publication, error envelopes, timeout/network mapping, stale-update conflicts, DNS filtering, redirect revalidation, and log redaction with no live outbound traffic. A successful smoke response is `{"status":"ok"}` for both operational endpoints and a 201 monitor document.
The tests cover CRUD and validation, health/readiness/current status, successful and failed status updates, 100 concurrent creates, stale-check compare-and-set behavior, defensive copies, bounded error mapping, public-address pinning, private/loopback/link-local/reserved and mixed DNS answers, redirect revalidation, credential/query/fragment redaction, structured JSON logs, and environment bounds. Outbound HTTP is mocked. Generation environments that do not expose a command runner cannot truthfully record execution results here. The commands above are the exact execution contract; downstream validation should record tool versions, exit codes, and test count. The architectural limitation remains that all monitor data is process-local, ephemeral, and isolated per worker.
## Generation-environment result
Repository generation has no command-execution or Docker daemon interface, so the commands above could not be executed during generation. They are provided as the exact acceptance sequence rather than being falsely marked successful. Static review was performed while assembling the single commit. Docker image build/startup and live smoke checks remain explicitly unverified until run in an environment with Docker and curl.
## Known limitation
The lock coordinates coroutines only inside one process. Data is neither durable nor shared, so the service must remain single-worker and cannot provide continuity across restarts. The supplied Docker command enforces one worker. A database-backed store would be required for durability or horizontal scaling.