Correct the target template to describe how the framework actually works

[fdesbiens]

Correct the target template to describe how the framework actually works

The problem

templates/target/ documented a structure the repository does not have, and following it produced a build that could not configure. Its app/CMakeLists.txt compiled ../../../../apps/threadx_demo/main.c, but there is no apps/ directory and never has been. The first thing a new contributor hits is a CMake error on a path that does not exist.

Of the three shared root directories the template declared governed, only one was real:

Declared	Reality
/bsp	✅ Real. Both framework targets implement board.h, led.h, console.h
/cmake	❌ Dead. cmake/utilities.cmake was referenced by nothing; all four targets carry their own copy, and the root file was byte-identical to the NUCLEO one apart from a license URL typo (licenses/MIT vs license/mit)
/apps	❌ Absent. Referenced by the template, by docs/architecture.md, and by the template's own CMake, but never created

What changed

The template now says what the framework does: applications and toolchain files live with their target.

The claim that applications have "no compile-time dependency on vendor-specific HALs, SDKs, or hardware registers" is retired rather than restated, because neither existing demo satisfies it — both include their board_config.h for memory sizing and vendor headers for board-specific startup self-tests. A portable shared application layer stays documented as a goal, explicitly labelled as one, rather than as a feature that exists.

templates/target/app/main.c is added, because the template now points at it. It depends only on <tx_api.h> and the <bsp/...> contracts and uses static thread stacks, so it avoids needing the board's memory extents and will compile for any target implementing the interfaces. It is a starting point to grow in place, not a shared application.

Also cleaned up in the template:

• Removed the dead SHARED_APP_DIR.
• Removed the guarded include of ${SHARED_CMAKE_DIR}/gcc-arm-none-eabi.cmake — a file that was never added, so if(EXISTS ...) meant it silently never fired.
• The BSP CMake now uses SHARED_BSP_DIR instead of a five-level relative path, matching what both real targets do.
• CMAKE_C_STANDARD 11 → 99, per AGENTS.md.

On deleting cmake/utilities.cmake

It was referenced by nothing in this state. Leaving a duplicate that looks authoritative invites edits that have no effect — someone changing the root copy would see no result, because every target loads its own. It is recoverable from history if the intent was for it to become the shared location; say so in review and I will restore it and wire the targets to it instead.

What this does not do

This does not make applications portable. That is a design change, not a cleanup, and it is deliberately out of scope here:

• The two demos are different applications, not variants — PolarFire is a 328-line LM75 condition monitor (3 threads, queue, event flags, static stacks); NUCLEO is a 653-line RTOS showcase (9 threads, byte pool and block pool, mutex, semaphore, timer). Neither is a subset of the other.
• Startup self-tests are irreducibly board-specific: _heap_limit vs __end, PLIC vs NVIC, CSR reads vs HAL_GetTick().
• Memory strategy differs — NUCLEO derives its byte pool from BSP_RAM_END; PolarFire uses static arrays.

Doing it properly needs at least two new generic BSP interfaces, roughly bsp_self_test() and bsp_ram_region(&base, &size), which changes the shared contract both targets implement and would require rehoming the self-tests added in #51. Worth a separate discussion.

Verification

Documentation and template files only; no target consumes them, and templates/ is inert until copied (there is no root CMakeLists.txt). Confirmed anyway that nothing regressed:

• NUCLEO-F401RE builds clean under Arm GNU Toolchain 14.2.Rel1 with -Werror: 22068 B ROM, 6000 B RAM — unchanged.
• Its Renode suite still passes, exit 0.
• Verified by grep that no target, script, doc, or workflow referenced the removed file.