Development, acceptance and publication

Choose checks for their consequence

Do not run Linux containers or Linux workload matrices on the Mac during R5/R6 development. In-process compiler units may still inspect target-specific data; that is host-compiler coverage, not Linux execution. --host excludes the two native target-workload cases and requires every remaining case to pass. The IR comparison that exposed R5.10's Ada argument-order defect remains included.

Choose the smallest test that can expose the changed behavior first. When it passes, broaden only for another affected subsystem or a remaining concern. Run routine acceptance once for the final committed promotion candidate; resume verified successful jobs after interruption. A failed job or changed source requires a new acceptance run. Do not repeat full local matrices before that gate. Documentation changes still receive full check.py; the checker retains every invariant and fixture.

Debugger risk means changed debug metadata, source/variable locations, unwind/frame conventions, debugger transport or debugger checks. Record the reason for enabling it. A status-page edit or an unrelated tool change is not a reason to run GDB. The R5.10 ordering repair preserves the existing Linux IR and copy behavior, changes no debug encoding/location/unwind code, and passed the unchanged IR golden and traversal execution checks in both compiler modes; this delivery therefore uses routine scope without GDB.

Before a major milestone such as R5.50 or R6.100, select and commit milestone scope with the closure candidate. A routine approval cannot be cited as a full milestone result. Subsequent development returns to routine scope.

python3 scripts/ci/policy.py routine
python3 scripts/ci/policy.py routine --debugger
python3 scripts/ci/policy.py milestone

These commands edit the committed policy; they do not run or approve anything. Approval validates the exact job list and command set for the selected scope. Historical schema-1 approvals remain full eight-job evidence. The native operations guide documents acceptance, export, approval and promotion.

What the measurements say

The retained full Linux run 20260914T204024Z-147ccbe20b60 ran its eight jobs concurrently. Its slowest job determined about 91 minutes of wall time:

The document/tooling job took 111.0 seconds, including 88.2 in check.py, 10.5 in CI failure-path tests and 2.1 in rendering. The complete R5.10 Mac harness took 2522.2 seconds in debug and 911.3 in release, largely compiling Linux workloads before the inevitable missing-tool refusal. Those runs remain historical evidence, not the future development cadence.

A local Python profile put 99.9 of 106.5 instrumented seconds in the grammar corpus check: 50.9 in recognition and 44.7 in lexical membership. The lexical matcher was called 952266 times. It now reuses repeated spellings within one file with a bounded cache. Grammar edits cannot reuse answers from a previous invocation, and token offsets/refusals remain checked. No corpus is skipped and no persistent cache supplies acceptance evidence.

The subsequent same-host profile took 72.6 seconds, about 32% less. Lexical membership fell to 101568 calls and 8.2 instrumented seconds. The new debug host run passed 711 cases and 192905 checks; its transcript timestamps span about 280 seconds including incremental rebuilding. These local measurements describe this checkout and host, not fixed performance bounds.

The first routine run, 20260915T082011Z-70a07a37aea3, measured 1208.5 seconds for its slowest job. Release suite and quality commands took 1094.9 and 1081.5 seconds; their separate bootstrap builds took 111.6 and 113.8. Debug host checks took 437.3 seconds after a 46.1-second build. Documents and bindings jobs took 84.1 and 60.6 seconds. These are measured results, not fixed performance bounds.

Parallel work and build reuse

The outer jobs already run in parallel. The remaining opportunity is inside long jobs: independent workload/profile compilations run sequentially, and the same compiler mode or workload is built for several consumers.

The proposed build graph is: one compiler build per mode, independent program builds keyed by their complete inputs and flags, then separate execution, quality and debugger consumers. Share immutable artifacts with verified identities, not mutable output paths. Use one aggregate CPU/memory budget; nested unrestricted worker pools would oversubscribe the runner. Keep GPRbuild's existing Ada dependency and checksum handling.

R5.20 evaluated one versus two workers on native Linux using the same immutable release compiler and fresh outputs for the parser/container programs under none/off and size/auto. The four compilations took 111.15 seconds sequentially and 55.55 with two workers; every assembly hash matched. Individual peak RSS was at most 50372 KiB. These samples justify two-worker experimentation; they do not bound memory for the whole fixture matrix.

The evaluated dependency graph keys a compiler artifact by complete source, project/pin inventory, host/tool identities, mode, flags and path mapping. A workload artifact additionally keys reached source/roots, configuration, profile, debug settings, compiler identity, adapter inputs and target tools. Execution, quality and debugger consumers retain independent run records. The two existing release compiler artifacts have different binary hashes and sizes in their different build contexts; they cannot simply be exchanged under today's acceptance identity records. Their builds already overlap, so sharing would save CPU but is not a measured 112-second wall-time improvement.

The production scheduler/cache remains deferred to the scale and self-hosting successor under ROADMAP.md's R5.20 disposition. Integrating bounded workers requires shared cancellation, timeout ownership and aggregate resource tests; artifact sharing requires an acceptance-schema change for producer identities. The quality command's second compilation deliberately checks determinism and must stay fresh. Cache hits must be labelled as reuse, and native execution must still run. This closes the evaluation without weakening those oracles or introducing nested worker pools into the routine gate.

Nix later

The current flake.nix supplies development shells. It does not define a cached refine package or the project's test derivations. More nix develop invocations alone would not remove repeated compilation.

Nix could later own compiler packages and suitable checks with narrow, complete inputs, and schedule them on the correct native builders. Its flake checks build the declared check derivations; distributed builds and separate job/core controls provide the scheduling mechanisms. Flake checks, distributed builds, job/core controls.

Nix CI is explicitly deferred. A later evaluation must account for the pinned Apple SDK, native debugger permissions, input selection, cache provenance and the existing native acceptance record. Build reuse cannot replace the native Darwin, Linux or freestanding executions required at a milestone.