BFE Engineering
c756622c96
The repo's documentation framed it as a support repo for one product (WardenOS). Since going public the real audience is anyone with a Luckfox Pico 86 Panel: a maintained 6.18 kernel, an off-device development loop, and a device simulator that exist nowhere else for this board. Reframe the README and top-level docs board-first, with WardenOS documented as the downstream consumer it is (ADR-0008). Also an editorial pass over the whole doc set: - every H1/H2 is now a short title, not a sentence (ADRs, qemu/, patches/, drivers/, architecture, NPU feasibility, config-lint, payload); workflow flowchart titles fixed at the source in tools/flowgen.py and regenerated with fresh bench numbers - README Quick Start commands verified against the scripts; requirements corrected (curl, bare python, gcc >= 14) and the MC/DC gate added as a step (run green locally on gcc 14.2) - dropped the 'needs python (not python3)' vendor dig: build-kernel.sh inherited the same requirement (filed #10 to remove it) - glossed MC/DC and HPMCU on first use; marked the tests/uboot-ab reference as flare-edge; deduplicated the three-simulator list into the root README table
29 lines
1.3 KiB
Markdown
29 lines
1.3 KiB
Markdown
# ADR 0008 — Panel Development Environment
|
|
|
|
**Status:** Accepted (2026-08-30).
|
|
|
|
## Context
|
|
warden-sdk was written as the SDK for WardenOS, and its documentation framed
|
|
it that way: a support repo for one product. Since going public (ADR-0007,
|
|
GPL-2.0-only), the actual audience is wider — anyone with a Luckfox Pico 86
|
|
Panel gets a maintained 6.18 kernel, an off-device development loop, and a
|
|
device simulator out of this repo, none of which exists elsewhere for this
|
|
board. The product-first framing undersold that and confused the entry point
|
|
for outside readers.
|
|
|
|
## Decision
|
|
Position warden-sdk as **a modern, open development environment for the
|
|
Luckfox Pico 86 Panel (RV1106)**. WardenOS is documented as the downstream
|
|
consumer it is, not the purpose. Documentation follows three rules: lead with
|
|
the board, not the product; keep private-repo references clearly marked as
|
|
context; keep titles short — a heading names a section, it does not summarize
|
|
it.
|
|
|
|
## Consequences
|
|
- README and top-level docs lead with the hardware and the developer loop
|
|
(build, simulate, test), with verified quick-start commands.
|
|
- WardenOS/flare-edge specifics stay where they are engineering truth (the
|
|
seam inventory, scenario payloads) but read as one consumer's usage.
|
|
- The honesty rule is unchanged: emulation results are never on-silicon
|
|
claims.
|