641dc6053b
All checks were successful
Build and deploy / Validate source (push) Successful in 5s
Build and deploy / Integration suite on a real stack (push) Successful in 2m5s
Build and deploy / Secret scan and release gate (push) Successful in 5s
Build and deploy / Publish images (push) Successful in 1m54s
The release job enforced the production source preflight, which blocks while the payment and messaging adapters are fake. They still are, by design, so since 2026-09-23 no release could succeed and production kept running older images while main moved on. Pushes to main that pass validation, the integration suite and the scans now build, scan and publish the images. Nothing is deployed automatically: production changes when the stack is pulled and redeployed in Portainer. A manual run also calls the Portainer webhook when one is configured. The preflight stays in the scan job, advisory unless ENFORCE_PRODUCTION_PREFLIGHT is true, in which case a blocked preflight stops publishing. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Documents
| File | What it is |
|---|---|
reuniao-2026-09-09-anotacoes.pdf |
Meeting notes that set the business direction: the bottleneck, the 24h goal, the automation and payment decisions. Still the record of what was asked for. |
roadmap-cliente.pdf |
The client-facing plan, as last sent. Generated by tools/generate_dtf_report.py; regenerate rather than edit. |
historico/ |
The original specification and prototype documents. Background only — they describe a model this system does not implement. |
Current engineering documents live at the repository root: CONTEXT.md for how
the system works, ROADMAP.md for what is outstanding, LOCAL_SETUP.md to run
it, PORTAINER.md to deploy it, SECURITY_REPORT.md and PRODUCTION_INPUTS.md
for the security position and the decisions still owed by the client.
Weekly client reports are deliverables, not repository content. They are produced for a specific week and are deliberately not versioned here.