docs: Provide additional information in docs

docs/examples_and_validation.md

@@ -24,6 +24,12 @@ It demonstrates how consumers declare toolchains while also serving as the main
 smoke-test surface for validating that the generated toolchains can build and,
 where appropriate, run example targets.
 
+These examples are intended only for sanity testing global changes on the
+module extension side. They are not a reference point for full platform setup.
+For a proper build on a dedicated platform, consumers must consult the
+relevant platform developers and owners rather than relying on these examples
+as a platform configuration guide.
+
 ## Important Files
 
 `examples/MODULE.bazel`
@@ -69,7 +75,7 @@ cd examples
 
 ## What The Tests Prove
 
-The example workspace is not intended to be an exhaustive compiler correctness
+As stated before, the example workspace is not intended to be an exhaustive compiler correctness
 suite. Instead, it answers a narrower question: did the configuration
 repository produce a usable toolchain definition for each supported scenario?
 

docs/overview.md

@@ -44,11 +44,11 @@ them as `cc_toolchain` targets:
 
 The current repository surface supports these platform families:
 
-- Linux `x86_64` with packaged GCC toolchains
-- Linux `aarch64` with packaged GCC toolchains
-- Linux runtime-specific variants such as AutoSD and EB corbos Linux for Safety Applications
-- QNX `x86_64` with packaged or locally built SDP-based toolchains
-- QNX `aarch64` with packaged or locally built SDP-based toolchains
+- Linux AMD64 (`x86_64-linux`) with packaged GCC toolchains
+- Linux ARM64 (`aarch64-linux`) with packaged GCC toolchains
+- Linux runtime-specific variants (`x86_64-linux`, `aarch64-linux`) such as `AutoSD` and `EB corbos Linux for Safety Applications`
+- QNX AMD64 (`x86_64-qnx`) with packaged or locally built SDP-based toolchains
+- QNX ARM64 (`aarch64-qnx`) with packaged or locally built SDP-based toolchains
 
 ## Core Design Model
 

docs/qnx_integration.md

@@ -27,7 +27,8 @@ Relevant `gcc.toolchain(...)` attributes are:
 - `license_info_variable`
 - `license_info_url`
 
-The default shared license path is `/opt/score_qnx/license/licenses`.
+The default shared license path is `/opt/score_qnx/license/licenses`. This has been
+agreed with all module owners and platform developers.
 
 ## Credential Helper
 
@@ -36,7 +37,7 @@ Authenticated QNX downloads are handled by the standalone script
 
 Its purpose is to translate locally available QNX credentials into the cookie
 header format expected by `qnx.com` download endpoints. Bazel executes it via
-`--credential_helper`; it is not referenced as a Bazel target.
+`--credential_helper`;
 
 Supported registration patterns include:
 

docs/repository_layout.md

@@ -56,24 +56,17 @@ Holds the template files used by repository rules. These templates are
 rendered into the generated toolchain repository and differ between Linux and
 QNX because the execution environment, sysroot layout, and licensing model are
 different.
+> NOTE: Future plan is to have a single template for toolchain configuration.
 
 `examples/`
 
 A standalone Bazel workspace used as an integration surface. It declares
 representative toolchain configurations and validates them with a smoke-test
 runner.
+> NOTE: These tests are just a sanity check. They should not be used as reference
+> points for platform development.
 
 `tools/`
 
 Contains utility scripts that Bazel executes directly, most notably the QNX
-credential helper used for authenticated downloads from `qnx.com`.
-
-## How These Pieces Relate
-
-Each directory is part of a single flow:
-
-- `packages/` defines *what* to fetch,
-- `templates/` define *what to generate*,
-- `rules/` define *how to generate it*,
-- `extensions/` define *how consumers ask for it*,
-- `examples/` prove that the generated result actually works.
+credential helper used for authenticated downloads from `qnx.com`.