Document source: e47887d3a11f; code reference: e47887d3a11f. 中文. Source language: en; requested: en; actual: en; translation: original.

Source documentation does not establish software or physical hardware qualification. See the support and qualification records for their exact scope.

Developer experience and provider iteration

This iteration keeps the static factory and shared polymorphic interfaces while reducing unnecessary product and maintenance work. The 75-task execution ledger is the task-status authority; its readable view preserves the same fields: W1–W9 contain 63 software work items, I-01–I-06 track integration, and H1–H6 require connected equipment. Implementation, software execution and physical execution are separate columns. A software mechanism does not close a physical exit condition.

The subsequent delivery-completion ledger and its readable view remain one follow-up authority. It preserves N01–N14 and appends the accepted A01–J04 work breakdown, including X01–X05: complete maintained-mode cold lifecycle, configuration contracts, public consumption, execution efficiency, delivery, HIL and environment recovery. These tasks preserve the original 75-task ledger and its fixed P/E evidence. Each row keeps its full exit condition; a migrated peripheral or prepared instrument does not close a whole-family or physical task. Hardware execution and a formal software candidate have separate exits; neither inherits an earlier iteration’s status.

The implementation order is coverage and baselines, C lifecycle and configuration contracts, family and cross-controller migration, public recipes, then frozen integration. Tool efficiency, delivery reports and environment recovery can proceed in parallel. Physical execution follows actual station admission. The current architecture diagram still applies: these tasks refine existing mechanisms without adding a runtime layer. Actual status remains in the same CSV; the work breakdown is not another support matrix or a project-wide percentage.

The follow-up development index retains its original development observations without relabeling old P/E results. The subsequent sealed cold-lifecycle baseline records the final source, complete gates, fixed examples consumption, offline reproduction and post-merge association. Read the later source-bound observation before interpreting an older pending field; a prepared plan or successful configuration query alone cannot close an exit.

Boundaries that stay explicit

The current architecture diagram still applies. One product TOML becomes immutable typed IR and exact static instances; CMake selects sources. Factory getters return existing readonly faces. Products own execution, storage, private PCB and recovery policy outside this repository. A friendlier command does not create a second configuration or build authority.

Work package	Delivered mechanism and source of truth	Exit evidence
W1: application entry	External versioned templates and dev.py create; SDK maintenance remains separate	Created application actually resolves, builds and runs; template and actual SDK identities remain distinct
W2: configuration	Board-first bindings, validated profiles, human explanation, effective diff and editor schema	Normal rejection and immutable resolved output remain authoritative
W3: provider boundaries	Family resolution and typed construction; common arbitration and atomic publication	Equivalent configurations retain generated bytes; moved source remains selected by CMake and SDK
W4: support selection	Existing Board/SoC facts, provider modes, derived matrix and explicit unknowns	Exact route, backend, mode, memory and evidence match; no second support-status database
W5: lifecycle use	External main-loop, exclusive-task and shared-owner recipes; optional copied-fact diagnostics	Borrow, backpressure, cancellation, drain and observer-join behavior actually executes
W6: resource cost	Actual linked variants, existing image reports and selected physical measurement plans	Equivalent-cost rules distinguish measured deltas from unexecuted timing
W7: official reuse	Locked vendor source and one bounded actual HAL/SPL evaluation	Semantics, linked costs and maintenance scope justify one production implementation
W8: execution efficiency	Existing process receipts, focused development and complete final gates	Timings preserve unknowns and failure; any test deletion preserves independent coverage
W9: external integration	Actual examples applications, source lock and public SDK consumption	Platform P and examples E are fixed in the final delivery association

Source ownership and migration

The H743 DMA2D component lives at components/soc/stm32/stm32h743_frame_dma2d. Its public include nexus/components/frame_dma2d.h and CMake target stay stable. This is a private source ownership correction, not new multimedia or hardware support. Historical records keep the paths belonging to their recorded revisions.

explain now prints a human summary by default; automation must use --json. The optional owner observation gains admission facts and changes its public sidecar layout, so source consumers recompile. New helpers do not add mandatory state to every provider, allocate a global registry or release borrowed storage. The product workflow documents these changes.

Official library reuse is evaluated per exact operation. A library name alone does not determine timing or ownership. The F4 HAL reference is finite USART1 TX with DMA2 Stream7; it is not a production backend or a migration of every mode. For HAL v1.8.5, DMA transfer-error IRQ cleanup uses a bounded SystemCoreClock / 9600 enable-bit loop. Tick waits occur in separate DMA Init, Abort and PollForTransfer paths. Do not describe every normal finite TX or interrupt-driven abort as a HAL_GetTick wait. The official provider contract retains callback, deadline, single-owner and full-drain obligations.

The current decision retains the single production LL/provider engine and GD32 SPL operation reuse. Actual HAL software behavior, current production ELF costs and non-equivalent ARM handle layouts are recorded separately. The reference does not implement complete NVIC preemption/vector withdrawal, IRQ wake, concurrent RX, cold-start rollback or full platform stop. Promoting it and comparing equivalent complete images are later work; no HAL-versus-LL resource ranking or production replacement is claimed.

Close work with observations

Compare complete execution costs

The ordinary behavioral TDD gate first runs the maintained python tools/dev/dev.py doctor --target contracts profile. It checks prepared, locked Native/ARM tools before expensive Python and Native suites, without installing tools or requiring Docker. Documentation-only staged changes retain the existing fast path. This preflight neither replaces tests nor establishes software qualification.

Use dev.py timings --compare only after two independent complete executions of the same maintained formal plan, clean source and dependency pins. Each execution must bind the same verified OCI environment-report bytes using the optional qualify --environment input. That binding records observed input identity; it does not prove that checkers ran inside an isolated container. Historical reports without this original binding remain valid for their own executed scope, but cannot be retrofitted into this comparison.

From the clean platform root, set NEXUS_MEASUREMENT_ROOT to a new output parent with adequate capacity, NEXUS_ENVIRONMENT to the sealed OCI layout’s environment.json, and NEXUS_COLD_CACHE_STATE/NEXUS_WARM_CACHE_STATE to the actual cache preparation descriptions. Prepare the intended cold and warm conditions explicitly before their respective executions. These commands run the complete plan; they do not reuse existing successful test reports:

python tools/dev/dev.py qualify --plan tools/dev/plans/software.json \
    --output "$NEXUS_MEASUREMENT_ROOT/cold" --environment "$NEXUS_ENVIRONMENT"
python tools/dev/dev.py qualify --plan tools/dev/plans/software.json \
    --output "$NEXUS_MEASUREMENT_ROOT/warm" --environment "$NEXUS_ENVIRONMENT"
python tools/dev/dev.py timings --compare \
    --plan tools/dev/plans/software.json --root "$PWD" \
    --cold-report "$NEXUS_MEASUREMENT_ROOT/cold/report.json" \
    --warm-report "$NEXUS_MEASUREMENT_ROOT/warm/report.json" \
    --cold-environment "$NEXUS_ENVIRONMENT" \
    --warm-environment "$NEXUS_ENVIRONMENT" \
    --cold-cache-state "$NEXUS_COLD_CACHE_STATE" \
    --warm-cache-state "$NEXUS_WARM_CACHE_STATE" \
    --json "$NEXUS_MEASUREMENT_ROOT/comparison.json"

Both runs must actually complete successfully with the exact plan, stage order, commands, raw streams and independent receipts. Formal plans disable compiler cache; declaring warm preparation does not enable it. The comparison reports the union of original stage-command wall intervals, excluding idle gaps and avoiding nested wall-time sums. Native producer checks additionally validate the current shared build outputs; they do not establish independent historical inner Native XML/artifacts for each cold/warm run. Cache state is declared, not measured cache hits; aggregate CPU, process-tree peak RSS and their deltas remain unknown. A cost comparison is not qualification and cannot qualify changed source. No complete cold/warm measurement is claimed merely because this command exists.

Hand off an unsigned local software preview

When hosted Actions is unavailable, the explicit prepare-local command (bundle-local alias) in tools/release/delivery.py assembles a local preview from original complete software execution, SDK/consumer packages, documentation and sealed candidates. verify-local independently checks the prepared output. Use the local preview contract and exact commands with a new output directory and the expected clean source commit. Input sources, dependency pins, original completed receipts, SDK identity and candidate/document scope must agree; successful reports are not reused to qualify another source.

This path preserves original bytes and restores packages without rebuilding or resealing them. Its trust is local_observation_no_oidc, signature status is unsigned and publication_authorized=false. It does not fabricate Actions runs, OIDC or a formal release, and it does not weaken the existing publication guards. Actual remote publication remains a separate exit.

The ledger records actual implementation and evidence paths, including limited development tests. The development result index keeps maintained test entry points and observed scope; final PR/CI association is recorded after source commits exist. Final source gates, independent SDK consumption and bilingual documentation have separate integration exits. Do not turn an expected CI run, a template manifest or an old release result into a passed current-source exit.

Platform commit P is created before examples lock and gitlink are updated to P. Examples commit E is then recorded with P by the delivery association. Tutorials use an explicit examples-revision variable supplied by that record; neither repository embeds the other repository’s future commit. Normal review and publication controls remain in effect.

No physical station is connected for this iteration. H1–H6 remain not_executed: launch-board bring-up and tools; serial/SPI/I2C and recovery; IRQ/critical-section latency; continuous DMA/Cache; Flash/watchdog/shutdown; and final physical support sealing. Prepared plans preserve unknown PCB facts, station identity and numeric acceptance limits for later real execution.