Next iterations and team execution¶

Selected software delivery in this round is fixed to public P2 ab532250: two complete 159-stage runs, SDK v15, eight candidates / 16 fresh network-disabled builds, P2 strict bilingual documentation and actual public recovery of the unsigned outer archive have completed. Independent QA followup 706ee80 passed the ordinary complete-index gate and full Python174 analysis: all 38 findings, comprising 30 notes / 6 warnings / 2 errors, uniquely map to previously reviewed dispositions; seven old findings disappeared and none is new. Current private E f59debf1 pins P2, with 17 presets / 116 commands, five real C broker scenarios each in source and installed builds, three recipes and the public SDK walk actually passed. E completed a normal nonforce push and exact readback of f59debf1; the repository remains private and private main is unchanged. Later D/deployment and final FF await actual results. The published v0.2.1 preview at b1b903da and historical candidates at 7590b2d4 retain their original identities. See current P2 unsigned software delivery for exact source, execution and obtainability boundaries.

The goals are independent external SoC/provider integration, usable industrial control and secure networking, and diagnosable failure and upgrade paths. Preserve static factories, read-only faces, C11 hardware behavior, explicit execution and borrowing contracts; optional features must not become default threads, global device registries or maximum-size pools.

The tables preserve the original 71 planning IDs and their mapping to 107 authoritative tasks, without creating another status ledger. The same delivery ledger still contains 210 rows: the original 175 retain their historical identities, and the 35 IT- rows separately describe implementation and current development checks. The readable view is generated by the existing renderer; original IDs, order and exit conditions remain unchanged.

External providers, Settings, wait-select, optional observation, TMP117, entropy, TLS, MQTT and developer tools have bounded implementations. RX payload loans, MCUboot control, TX error observation, PCAP, resolver/CLI refinements and SDK v15 belong to the current combination. Implementation, focused GREEN results, the complete gate and installed SDK are accepted separately. Test-source paths are review entry points and do not replace fresh execution receipts.

IT-R04 reuses the existing H743 V/fixed HSI64/Cache-off/baremetal SPI4 lifecycle pause/resume path; it does not plan a new generic PM system. Current integration execution and physical acceptance remain open. Reviewed IT-S06 consumers use Settings, explicit Flash regions and MCUboot byte storage, with no file-oriented consumer yet. IT-X04 has no new probe requirement. No filesystem dependency or device runner is added until a real requirement enters through the original exit conditions.

F01 reconciled current159 checks and their original costs. F07 completed an observational comparison on the same P2/tools/environment, retaining cache and RSS limitations without claiming controlled causal acceleration. N09 fresh-build-directory/warm configure-build observations establish only the selected Native trace; other MCU, CLI and F05 exits remain independent. Open work includes Flash/ECC event-owner/sticky/recovery details, seven vendor-leaf proposals, GD303 reference review, the physical developer path, later D/deployment/FF, server rules and physical HIL. Test retention decisions need original-contract or independent equivalent-coverage evidence; checks must not be removed to manufacture a pass.

Work packages, dependencies and authoritative tasks¶

Every item starts from exact part/Board/backend/controller/mode/route selections and memory, clock and security configuration. CPU profiles do not substitute for SoC/Board support; unselected components stay absent and actual ELF results explain added cost. Extend existing external Boards, resource graphs, capability queries, lifecycle diagnostics, Storage, ClockDomain and HIL.

Baseline and delivery entry points¶

Priority: P0. Admission and order: None; first check actual source and published assets.

Planning ID	Iteration work entry	Authoritative task IDs
`IT-B01`	Version and qualification navigation	`G04`
`IT-B02`	Exact support matrix	`A01`, `V-A01`
`IT-B03`	Complete development-operation baseline	`V-K05`
`IT-B04`	Same-context cost baseline	`A03`, `F01`, `F07`
`IT-B05`	Server-side branch protection	`V-X02`

External SoC/provider integration¶

Priority: P0. Admission and order: IT-B02; fix the package contract before resolution, build, SDK and independent fixtures.

Planning ID	Iteration work entry	Authoritative task IDs
`IT-P01`	External SoC/provider package contract	`IT-P01`
`IT-P02`	Immutable package context	`IT-P02`
`IT-P03`	External-package identity and path admission	`IT-P03`
`IT-P04`	External configuration resolution	`IT-P04`
`IT-P05`	External CMake integration	`IT-P05`
`IT-P06`	Installed-SDK consumption of external packages	`IT-P06`
`IT-P07`	External-package input and evidence closure	`IT-P07`
`IT-P08`	Independent integration acceptance fixture	`IT-P08`

Configuration and diagnostics¶

Priority: P0–P1. Admission and order: Reuse selected contracts and typed IR; external-package results must reach queries.

Planning ID	Iteration work entry	Authoritative task IDs
`IT-C01`	Mode list/explain	`N06`, `N08`
`IT-C02`	Usage and lifecycle constraints	`V-A02`, `B02`
`IT-C03`	Lifecycle diagnostics in user configuration	`V-C08`, `N08`
`IT-C04`	Resolver-stage localization	`D02`, `V-H01`
`IT-C05`	CMake mode-query costs	`F05`, `N09`

Drivers and resource costs¶

Priority: P1. Admission and order: Review official implementations by complete mode; fix regression scope before changing each driver.

Planning ID	Iteration work entry	Authoritative task IDs
`IT-D01`	Official-library and direct-access decisions	`V-A03`, `V-A04`
`IT-D02`	Shared-IP engine ownership	`V-H04`
`IT-D03`	DMA memory and ownership	`D04`, `V-G06`, `V-G07`
`IT-D04`	Read-only configuration and mutable-state costs	`V-I01`, `V-I03`
`IT-D05`	Full-mode regressions and cost comparisons	`V-J02`, `V-J05`, `V-I06`

Runtime and shutdown coordination¶

Priority: P1–P2. Entry and order: R01/R02 reuse existing observation and wait contracts. R04 checks integration, retention and recovery of the existing exact H743 path; public types do not imply generic PM.

Planning ID	Iteration work entry	Authoritative task IDs
`IT-R01`	Read-only runtime-state observation	`IT-R01`
`IT-R02`	Multi-source wait-set and explicit executor	`IT-R02`
`IT-R03`	Shutdown and recovery coordination	`E02`, `E03`, `V-C06`, `V-C08`
`IT-R04`	Exact runtime-PM path	`IT-R04`
`IT-R05`	Second sensor and sampling contract	`IT-R05`

Networking and secure connections¶

Priority: P0–P1. Admission and order: N01→N02→N03/N04→N05; N06→N07→N08, followed by N09.

Planning ID	Iteration work entry	Authoritative task IDs
`IT-N01`	Initial networking scope and budgets	`IT-N01`
`IT-N02`	Mature C network-stack integration	`IT-N02`
`IT-N03`	Ethernet-frames network-stack adapter	`IT-N03`
`IT-N04`	Network execution and bounded memory	`IT-N04`
`IT-N05`	Basic IPv4 networking	`IT-N05`
`IT-N06`	Entropy interface and first provider	`IT-N06`
`IT-N07`	TLS resource and trust ports	`IT-N07`
`IT-N08`	Optional MQTT adapter	`IT-N08`
`IT-N09`	End-to-end networking fault and resource validation	`IT-N09`

Settings and image maintenance¶

Priority: P1–P2. Admission and order: Reuse Storage; S03→S04→S05; enter S06 on a real file requirement.

Planning ID	Iteration work entry	Authoritative task IDs
`IT-S01`	Bounded Settings/KV	`IT-S01`
`IT-S02`	Settings failure regressions	`IT-S02`
`IT-S03`	Narrow image-maintenance ports	`IT-S03`
`IT-S04`	External integration of a mature bootloader	`IT-S04`
`IT-S05`	Image fault and resource validation	`IT-S05`
`IT-S06`	Filesystem admission and adaptation	`IT-S06`

Developer experience¶

Priority: P0–P1. Admission and order: Reuse existing dev/provenance/station locks; extend explicit hosts and probes.

Planning ID	Iteration work entry	Authoritative task IDs
`IT-X01`	Complete template-to-firmware workflow	`E05`, `V-K05`
`IT-X02`	Optional GDB client workflow	`IT-X02`
`IT-X03`	Serial host and baud-rate extensions	`IT-X03`
`IT-X04`	Unified device-runner extension	`IT-X04`
`IT-X05`	Installed-SDK developer diagnostics	`V-K01`, `V-K02`
`IT-X06`	Firmware-artifact queries	`IT-X06`

Test quality and execution efficiency¶

Priority: P0–P1. Admission and order: First record same-coverage costs; retain complete commit gates and independent compile contexts.

Planning ID	Iteration work entry	Authoritative task IDs
`IT-T01`	Read-only test-plan preview	`IT-T01`
`IT-T02`	Actual TDD handoff	`V-J01`, `V-J02`
`IT-T03`	Same-coverage validation costs	`F07`
`IT-T04`	Evidence-based test cleanup	`F04`, `V-J07`
`IT-T05`	Resource budgets and early failure	`F03`, `F06`, `V-J08`
`IT-T06`	Additional high-risk input and concurrency validation	`IT-T06`

External reference systems and documentation¶

Priority: P0–P1. Admission and order: Reuse existing mechanisms for control; gateway depends on N; keep bilingual and external use current.

Planning ID	Iteration work entry	Authoritative task IDs
`IT-E01`	External industrial-control reference system	`IT-E01`
`IT-E02`	External network-gateway reference system	`IT-E02`
`IT-E03`	Reference-system resources and failures	`V-I05`, `V-K04`
`IT-E04`	Bilingual documentation and architecture diagrams	`E06`, `V-K07`
`IT-E05`	From-scratch usage acceptance	`N14`, `V-K05`

Physical acceptance¶

Priority: After equipment connection. Admission and order: After H01/H02, execute modes, networking, power cuts and performance; tooling is not measurement.

Planning ID	Iteration work entry	Authoritative task IDs
`IT-H01`	Real-station connection	`H02`, `H03`, `V-P01`
`IT-H02`	Startup and basic-fact measurements	`H03`, `V-P02`
`IT-H03`	I/O completion and shutdown measurements	`H06`, `H07`, `H08`, `V-P05`
`IT-H04`	Complete networking measurements	`H06`, `H10`
`IT-H05`	Power-cut and boot-maintenance measurements	`H09`, `V-P06`
`IT-H06`	Performance and low-power measurements	`H04`, `H05`, `H08`, `H10`

Candidates and publication¶

Priority: Integration exit. Admission and order: Freeze clean source; execute the full plan, SDK and offline reproduction before publication.

Planning ID	Iteration work entry	Authoritative task IDs
`IT-L01`	Reproducible locked environment	`I01`, `I02`, `I03`
`IT-L02`	New-dependency maintenance closure	`V-B01`, `V-B06`
`IT-L03`	Frozen-source software acceptance	`J02`, `J03`, `V-L03`, `V-L04`
`IT-L04`	New exact software candidate	`N13`, `V-L07`
`IT-L05`	Publication and independent recovery	`V-L08`, `G05`, `G06`

Milestone exits¶

Milestone	Main scope	Observable exit
M1 Baseline and operations	`B、C01、T01、X01`	Users find versions and support scope, explain configurations and test plans, and complete existing software workflows.
M2 Independent integration	`P、C02–C04、D`	An external maintainer delivers a verifiable integration without changing the main repository or inventing physical-chip qualification.
M3 Industrial control	`D、R01–R03、S01–S02、E01`	An exact external system runs, persists, enters maintenance, stops and recovers with failure regressions.
M4 Secure networking	`N、E02–E03、X`	One exact composition completes bounded TCP/TLS/MQTT, resource checks and failure shutdown.
M5 Maintenance and conditional extensions	`S03–S06、R04–R05`	Complete image-maintenance and external reference builds; admit PM, sensors and filesystems under explicit conditions.
M6 Qualification and publication	`E04–E05、L、H`	Restore the frozen-source software candidate, SDK and bilingual docs; publish only actually executed physical scope.

Integration, control, networking and delivery may proceed in parallel; hand off shared contracts before changing behavior. Each increment includes implementation, actual regressions, current documentation and applicable full gates. Close software, physical and publication exits separately, never replacing completion with commit counts, generated plans or old test totals.

Reusable mechanisms belong in the platform; tasks, protocol register maps, Flash partitions, keys, authorization and recovery policy remain external. Private application source and evidence stay out of public platform artifacts; software success for a reference system does not establish physical success.

General DVFS, all-device PM, userspace I/O, general asynchronous TrustZone transport and multiple filesystems still need independent requirements and contracts. Learn from Zephyr external modules, device models, test planning, Settings and PM layering; fix a version or commit before code reuse rather than using rolling documentation as implementation identity.

Admission conditions for physical work and subsequent measurement¶

After equipment connection, first verify the three initial physical Boards and record PCB, oscillator, supply and wiring, then establish probe, serial and waveform/power-cut stations. Check actual G474, H743 and U575 reference boards separately; observe H743 supply mode and confirm U575 option bytes and boot state before running images. First check safe initial levels and clocks, then real UART TC, cancellation, RX loss, watchdog reset, Flash power cuts and EXTI/PWM/ADC. Qualify each mode only for the actually executed target tuple. Keep test outputs disconnected from product loads and follow station contracts for field operations.

Use the same candidate ELF to measure cycles, IRQ latency, maximum service interval, stack high-water, loss and sustained load. Source/assembly inference helps locate causes but is not a measured timing result. Budget or provider changes require regenerated source/config/artifact evidence.

Expand capabilities according to measurements¶

F407/F470 already have bounded UART/SPI DMA, continuous UART RX/bidirectional DMA, bounded/continuous ADC trigger blocks, I2C IRQ/DMA, Classic CAN, USB FS PIO and Ethernet/capture/complementary-PWM exact software fixtures. First refine these existing modes with actual throughput, IRQ latency, inter-block gap, line-drain and overload measurements. Continuous modes cannot promise losslessness under arbitrary IRQ latency or consumer speed. I2C remains 100 kHz, 7-bit, 1–256 bytes per message, at most eight messages and exact routes; 10-bit or longer transactions are separate extensions.

F103/GD303 add finite UART channel-DMA, normal RX blocks, IRQ-message I2C and physical Flash/single-shot ADC/fixed PWM; GD303 also maintains EXTI. Finite RX depends on owner service to rearm, so gaps, backpressure and loss require measurement; priority-zero I2C cannot notify a kernel. The GD303 hardware timer cascade also needs physical carry and Flash-stall observations; host models cannot establish bridge propagation delay.

G474 adds ADC1 bulb shots/TIM6 normal-DMA blocks, polling I2C1 and ECC Flash; first-conversion discard, warmup, the exact 2.5–50 kHz trigger range and actual sampling aperture require measurement. H743 maintains finite UART RX DMA-IDLE, optional initialized D2 SRAM1 and seven finite peripheral classes. Cache-on DMA still requires exclusively owned complete lines; RX has service/rearm gaps and Flash requires Cache off. U575 TZEN0 has finite SPI/I2C/ADC/PWM/EXTI/Flash fixtures; VDDA/ASV, VDDIO2 and actual bus electrical behavior need separate acceptance. The independent TZEN1 reference only adds cooperative jobs of up to eight copied PC7 commands, retaining state in private Secure storage and no NS address across calls. It supplies no general asynchronous borrow, RTOS, dual-world factory or cross-domain DMA. Chip facts authorize neither additional modes/routes nor physical qualification. See SOC-28–36 for sequencing and explicit exits:

Direction	Contract to fix before implementation
New G474 modes or more controllers/routes	Measured limits of existing bulb/finite-DMA/I2C/Flash paths; new controllers additionally fix IRQ/DMA conflicts, Board provenance, instance isolation and budgets
H743 DMA and Cache	Measured coherency of existing AXI/SRAM1 finite paths; other DMA1/2, BDMA and MDMA paths independently review reachability, cache-line ownership, maintenance points and retained borrows on failure
U575 DMA and security domains	GPDMA/LPDMA descriptor lifecycle, memory/peripheral ownership, GTZC/MPCBB, actual TZEN entry and error handling
New fixed clocks or runtime frequency changes	Power/Flash/bus ordering, consumer reconfiguration, rollback and deadline domains; implement fixed profiles separately from dynamic transitions
Bootloader handover or deep STOP	Active VTOR/mask/FP/DMA state, RAM ownership, RTC/LPTIM continuous domain, wake recovery and precision
userspace I/O transport	Actual principals, permissions, copy/pin, asynchronous borrows, exit reclamation and SVC/MPU/TZ gateways; the existing scalar broker does not replace transport

Each extension first fixes owner, buffer, cancel/drain, ISR, deadline, alignment/cache and stop contracts. Then use GoogleTest/GoogleMock for an actual RED→GREEN production-provider vertical slice, followed by generated factory, ARM ELF, SDK and physical-boundary verification. Unselected modes retain no resources; growing generic-object costs are not imposed on every product.

This iteration records source implementation, targeted developer execution and final integrated software qualification separately. Final acceptance must bind exact frozen source/configuration/tool/artifact identities; new documentation, source merges and historical counts do not replace actual execution. ECC Flash program_flags, fresh-erase provenance and per-pulse completion evidence also belong in the product caller contract. Physical equipment is absent, so physical items remain not_executed; they are not promoted to safety certification or production release.

Reuse existing narrow ports and static assembly first; allow explicitly versioned breaking changes when contracts cannot express hardware facts. Flash authentication, upgrades, manufacturing keys and industrial security policy belong to external products/independent mechanisms. Existing storage CRC or watchdog feed cannot establish their completion.

Ten-person roles and enterprise workflow¶

Role	Seats	Reviewable outputs owned
Technical lead	1	Contracts, boundaries, budgets, support scope and cross-layer design review
Core/I/O/OS	2	Ownership, concurrency, time, static resources and public ABI
STM32/GD32 BSP	2	Exact facts/routes, SDK/startup/provider and fault models
Generic devices/communications and external applications	2	Narrow-port components, device drivers and external composition
QA/HIL	2	Software faults, actual stations, timing/power-cut/sustained-load evidence
Build/release	1	Single configuration/CMake graph, locks/SDK, CI and candidate/reproduction evidence

Codex assumes all maintenance responsibility; .github/maintainer-roles.json uses agent_managed. Ten-person roles remain domain/capacity divisions without requiring named accounts. The same maintenance responsibility covers security, manufacturing and field interfaces; product permissions/processes remain in external application repositories.

python tools/maintenance/ownership.py --require-assigned verifies responsible agents, path coverage, backup domains and required gates. GoogleTest/GoogleMock, configuration, ARM, budget, SDK and evidence-identity checks continue. This policy fabricates no CODEOWNERS and claims no independent human review. Actual GitHub branch-rule/required-check configuration still needs remote verification. Commands are in maintenance tools.

Issues describe concrete triggers and observable results. PRs state source/config/dependency/tool identities and affected contracts. Each commit automatically checks staged content and Conventional Commit; CI uses the same whole-file standard. New behavior and bug fixes require TDD: GoogleTest/GoogleMock for host contracts, unittest for Python tools. New cases run RED first, then a minimal GREEN fix. Mechanical gates do not prove historical editing order; PRs record commands, failure reasons and raw logs. IRQ, lifecycle, persistence and concurrency changes need actual failure-path regressions. Nightly/formal-candidate measurements, offline builds and station results are sealed separately; ordinary platform CI does not automatically promote production releases.