SOFT4U with Codex and Astra
What: In the TrustRelay implementation of SOFT4U, Codex now performs primary coding and coordination, using Astra as the configuration chosen by the project owner. The former arrangement used Claude Code for primary implementation and Codex for independent pull-request review. The change moves implementation responsibility; it retains human architectural ownership, independent review and required CI before merge.
The operating workflow is in use. The evidence below describes its current delivery checkpoint, including incomplete validation. It does not establish a model ranking or a completed reusable installation kit.
The Business Intent Lifecycle white paper describes the proposed collaboration model upstream of engineering: establish approved meaning before turning it into specifications and tests. Its reference model is distinct from the operating evidence on this page.
Why: The objective is to shorten the path from an observed product defect to a verified correction. Local work should answer the immediate regression question quickly. Comprehensive CI should check the proposed integration before it reaches mainline. Running every expensive check twice is not a prerequisite for opening a pull request.
A coordinator gives each contributor a bounded change and an exclusive worktree or file boundary. Contributors retain the reproduction, changed source, test evidence and unresolved review findings. The coordinator composes the result and remains responsible for the whole customer journey. Parallel work is useful only while its resource use and integration dependencies remain manageable.
Evidence: The 10 September 2026 TrustRelay checkpoint records:
| Observation | What it establishes | Limit |
|---|---|---|
| PR #1421 pushed at a01eaa24 after 125 targeted tests passed | The selected regression tests passed before submission | It is a push, not a merge or a deployment |
| 96.31% coverage for the selected measurement | 1,489 / 1,546 statements in config and two detector test modules | It includes test code; it is not whole-application coverage |
| Full frontend checks and advisory checks passed | Those local checks completed | Required CI and current-head independent review were still pending |
| Comprehensive local backend attempt recorded 14,837 passes and zero failures before its time cap | Substantial execution occurred without a recorded failure | No final coverage or successful suite completion; this run is incomplete, not green |
These are observations from one project and one operating transition. They do not measure comparative defect rates, delivery speed, token consumption or cloud-cost savings. Those comparisons require a common scope and completed delivery cycles. The dated showcase evidence entry records this checkpoint; Appendix F points to that collection.
How: Apply the following division of verification work.
- Reproduce the problem. Name the observable failure and the control that would detect its return. For database, workflow or document behavior, exercise the relevant real integration boundary under the project's testing standard.
- Validate the changed paths locally. Run the relevant regression and integration tests, lint, type checks and source review. Record commands, source identity, actual counts and coverage scope. An incomplete run stays incomplete.
- Submit the bounded correction. A full local suite is optional diagnostic work when the risk justifies its cost. It is not a universal prerequisite for a push. This cadence is the owner's explicit policy; any conflicting executable push gate must be reconciled through a reviewed change, not bypassed.
- Require comprehensive CI before merge. CI checks the integration candidate. Independent review examines the current head; the implementer's own review is useful preparation and does not replace it. Resolve actionable findings and preserve their disposition. A later source change requires evidence appropriate to that change.
- Verify delivery. Capture rollback identity before activation, deploy through the authorized path, and check actual deployed behavior. Update the business documentation only to describe what the product supports.
The resource budget is a coordination rule, not evidence that CPU or memory capacity is sufficient. Measure active workloads before increasing concurrency. Save resumable checkpoints before stopping work, and clean up only processes and disposable services owned by that run.
Aikido and CodeRabbit are optional extension candidates. Licences have not been purchased and their contribution has not been validated in this operating setup. They are not required stages or claimed sources of the results above. A future evaluation should name the added checks, observe findings that existing controls miss, and measure the resulting cost and review effort before making them part of the required pipeline.
The next evidence checkpoint is completed CI and current-head review for the submitted candidate, followed by delivery verification. A methodology release should update this record with actual outcomes; elapsed time or a large passing-test count cannot substitute for them.