components(asking-star): add Scheme-B semantic runtime components

[ymy-yry]

Summary

This PR introduces Asking Star Scheme-B into TGOSKits as componentized runtime
and Soil/adapter components, together with import scripts, component smoke-test
scripts, the system architecture diagram, and documentation.

The goal is not to replace the existing StarryOS, ArceOS, or AxVisor
architecture, nor to directly rewrite StarryOS kernel scheduling paths. Instead,
this PR organizes the Asking Star semantic runtime, Sky/Soil symmetric boundary,
OS/ABI adapter layer, DigitalSet evidence chain, and local test entry points as
buildable, testable, and reviewable components for incremental upstream review.

This PR adds:

• components/asking-star-runtime
• components/asking-star-soil
• tools/import_asking_star_scheme_b.sh
• tools/run_asking_star_scheme_b_tests.sh
• docs/docs/asking-star/scheme-b-overview.md
• docs/static/images/asking-star-system-architecture.png
• README documentation for the Asking Star background, five-layer architecture,
  validation boundary, and collaboration notes

Motivation

Asking Star targets StarryOS, RK3588 / Orange Pi 5 Plus edge-intelligence
platforms, AI inference adaptation, and embodied-intelligence application
migration.

In edge-intelligence systems, application intent, AI inference, OS services,
drivers, syscalls, ioctls, device nodes, and hardware behavior are often tightly
coupled. That can work in a Linux environment, but it becomes difficult to
migrate, replay, or compare behavior across StarryOS, QEMU, Mock, Replay, Linux
user, and real-board validation.

Asking Star tries to address the following problems:

1. application intent is too tightly coupled with OS/ABI details;
2. AI inference results, KernelRequest, KernelResult, trace, and logs are
   scattered;
3. Mock, Replay, QEMU dry-run, StarryOS adapter, and BoardReal evidence can be
   confused;
4. upper-level task organization and lower-level driver calls have unclear
   boundaries;
5. there is no unified fact carrier for replay, audit, and comparison.

Asking Star uses DigitalSet, StarRuntime, Sun/Organ, VesselBus, MultiChamber,
SoilRuntime, Trace, and adapter boundaries to organize application intent,
runtime state, AI inference requests, OS/ABI requests, and execution results
into a traceable semantic runtime path.

Five-Layer Architecture

The system uses a layered architecture across the hardware platform, StarryOS
kernel, runtime and verification layer, and OuterKernel / application-intent
layer. The hardware layer is centered on RK3588 and provides ARM big.LITTLE CPU,
NPU, memory, storage, UART, USB, camera, and related devices. The StarryOS
kernel layer handles early boot, MMU, memory management, task scheduling,
syscalls, and basic drivers. Starry Sentinel runs on the host side and handles
builds, loading, serial logs, and exception reports; it is not a guest-kernel
component.

Asking Star V5.6 sits in the runtime and adaptation layer. It uses the
OuterKernel -> SkyLayer -> Asking Star Core -> SoilLayer -> InnerKernelLayer
Sky-Soil symmetric structure to unify application intent, AI inference requests,
OS/ABI calls, and test evidence into recordable DigitalSet structures:

Layer 1: OuterKernel / application intent layer
  Desktop-Wanderer, LeRobot, RKNN demo, shell, AI demo, robot task, SkinUI,
  Walker input

Layer 2: SkyLayer / DigitalSet fact layer
  DigitalSetRecord, DigitalSetFragment, RefRecord, PrimordialDigitalSet,
  WalkerIngress, SkinUIProjection

Layer 3: Asking Star Core / middle core / Star semantic layer
  StarRuntime, Gene, Charge, DigitalCell, Sun admission, OrganRuntime

Layer 4: SoilLayer / skeleton-vessel-chamber layer
  AlgebraSkeleton, TimelineJoint, VesselBus, MultiChamber, ChamberRuntime,
  ChamberPouchView, ReflexGeneBank, SoilRuntime

Layer 5: InnerKernelLayer / kernel boundary layer
  StarryOS kernel, scheduler, memory, file system, driver interface,
  KernelRequest, KernelResult, StarryOS adapter, LinuxUser adapter, QEMU dry-run,
  BoardReal guard

The terms OuterKernel, Asking Star Core / middle core, and InnerKernelLayer are
engineering metaphors in the Asking Star design. They do not rename or replace
the traditional OS kernel:

• OuterKernel is the application-facing and demonstration-facing layer,
  including shell commands, AI demos, robot tasks, SkinUI, Walker input, and
  outer-kernel userspace. It expresses intent, but does not directly access
  OS/ABI details.
• Asking Star Core / middle core is the Star semantic runtime, including
  DigitalSet interpretation, Gene / Charge / DigitalCell, Sun admission, and
  Organ execution organization. It understands task semantics, organizes runtime
  state, and creates executable semantic units.
• InnerKernelLayer is the real OS / ABI / kernel / driver boundary,
  including StarryOS, ArceOS, AxVisor, Linux user, QEMU, and BoardReal paths.
  Asking Star enters this layer only through SoilRuntime and adapter surfaces.
  StarRuntime, ChamberRuntime, and Walker surfaces must not bypass Soil.

The Star layer sits between application intent and the OS boundary. It is not a
traditional OS kernel and not just an application framework. It is the semantic
middle core of Asking Star: it converts external intent into traceable,
schedulable, replayable, and verifiable runtime facts.

Implemented Architecture Surface

This PR does not only add a minimal StarRuntime facade. The Scheme-B component
import includes the core Asking Star V5/V5.5/V5.6 implementation surface,
including:

• DigitalSet as the fact carrier;
• Gene / Charge / DigitalCell semantic runtime units;
• Walker-Giant ingress as the outer input surface;
• PrimordialDigitalSet / startup seed refs;
• AlgebraSkeleton as the main time-axis skeleton;
• TimelineJoint for horizontal ref mounting;
• asking_star/v56/vessel Star-layer vessel transport;
• Sun / Organ admission and execution organization;
• MultiChamber runtime;
• ChamberRuntime execution-environment selection;
• ChamberPouchView for observation, health, fallback, trace, and reflex
  candidates;
• SkinUIProjection for readable state projection and UI event input;
• ReflexGeneBank and preset-charge flow;
• Replay / RKNN / StarryOS dry-run chamber surfaces;
• SoilRuntime and the Soil MultiChamber adapter;
• evidence boundaries for Mock, LinuxUser, QEMU dry-run, StarryOS adapter, and
  BoardReal guard paths.

The intended path is:

OuterKernel application intent
  -> DigitalSet fact records
  -> SkyLayer ingress / projection
  -> Star middle-core interpretation
  -> AlgebraSkeleton / TimelineJoint mounting
  -> VesselBus transport
  -> Sun admission
  -> OrganRuntime / MultiChamber placement
  -> ChamberRuntime / ChamberPouchView observation
  -> Soil boundary translation
  -> InnerKernelLayer OS / ABI / Kernel result
  -> Trace write-back

Asking Star Runtime does not directly replace StarryOS kernel scheduling.
Instead, it adds task orchestration, capability scheduling, and state-feedback
layers above the traditional OS. It focuses on how tasks are expressed, how they
flow, how state is generated, and how runtime work enters the system boundary.
The current design uses the DigitalSet fact base, Star-layer dual semantic
modules, cell-level task units, organ-level capability execution,
chamber-backend selection, and Sky/Soil symmetric boundaries to satisfy the
design requirement of building a semantic runtime above kernel scheduling.

The benefit is not simply making the call chain shorter. The value is reducing
invalid computation, repeated failures, and resource waste through task-graph
scheduling, capability selection, device adaptation, inference fallback, and
observation feedback, thereby improving the overall efficiency and
optimizability of edge-intelligence tasks.

Validation

Local validation results:

• Scheme-B component smoke tests passed: 31/31 tests passed
• TGOSKits root cargo fmt --all -- --check passed
• TGOSKits root cargo xtask clippy passed
• TGOSKits root cargo xtask sync-lint passed
• TGOSKits root cargo xtask test passed
• Official-container local QEMU matrix passed: 11/11

The QEMU matrix covers:

• ArceOS: x86_64, aarch64, riscv64, loongarch64
• Starry: x86_64, aarch64, riscv64, loongarch64
• AxVisor: aarch64, riscv64, loongarch64

Evidence Boundary

This PR does not claim:

• official self-hosted runner completion;
• RK3588 / BoardReal completion;
• complete StarryOS-native RKNN/NPU execution;
• complete camera input integration;
• motor, robotic-arm, or full robot closed-loop completion;
• local validation replacing upstream CI or real-board evidence.

Mock, Replay, Linux baseline, QEMU dry-run, and StarryOS dry-run results are not
treated as BoardReal evidence. Starry Sentinel host-side artifact verification,
U-Boot probes, serial marker monitoring, JSONL event streams, and Markdown
reports are also not equivalent to guest-kernel execution evidence.

Review Notes

Suggested review order:

1. Asking Star background, Figure 3-1, and five-layer architecture in
   README.md;
2. docs/docs/asking-star/scheme-b-overview.md;
3. tools/import_asking_star_scheme_b.sh;
4. tools/run_asking_star_scheme_b_tests.sh;
5. components/asking-star-runtime;
6. components/asking-star-soil;
7. CI/QEMU fix commits.

We would like to share Asking Star in small, reviewable steps while respecting
the upstream maintenance process. We hope this work can serve as a basis for
equal collaboration, mutual learning, and cooperative development with the
upstream community.

If maintainers prefer different directory placement, API naming, component
boundaries, test organization, or documentation scope, we are willing to keep
adjusting the branch based on community feedback and work together toward a
cleaner, more maintainable integration path.

[ymy-yry]

Ownership and Maintenance Boundary

Asking Star Scheme-B is submitted as a componentized contribution for TGOSKits upstream review. This PR does not transfer the independent ownership, project identity, roadmap authority, or sublicensing authority of Asking Star to unrelated third parties.

Future maintenance should follow TGOSKits repository governance and should be performed by the repository owners, authorized maintainers, original contributors, or contributors accepted through the normal PR review process.

Substantial architecture changes, public renaming, license changes, or transfer of maintenance authority should require explicit review by the original contributors and TGOSKits maintainers.