46 lines
2.1 KiB
Markdown
46 lines
2.1 KiB
Markdown
# kaptan
|
|
|
|
Kaptan is a modular flight controller platform focused on deterministic bare-metal execution for flight-critical paths and strong verification discipline around the rest of the stack.
|
|
|
|
The repository is currently in infrastructure setup. Formal project specifications are automatically checked beside the file-backed modules they govern.
|
|
|
|
## Current Direction
|
|
|
|
- Flight-critical runtime stays bare-metal with no RTOS in the control path.
|
|
- The first vehicle scope is multirotor.
|
|
- The first board support lane is Kakute F7 Mini V3.
|
|
- Non-critical extensibility, companion integration, and user-facing tooling will be added only after core runtime and verification contracts are established.
|
|
|
|
## Immediate Priorities
|
|
|
|
- Create specification infrastructure without inventing the first formal spec.
|
|
- Establish crate and board boundaries that fit the first supported hardware lane.
|
|
- Add deterministic host-side validation before simulation and hardware automation expand.
|
|
|
|
## Repository Structure
|
|
|
|
- `kaptan-runtime/`: bare-metal runtime crate scaffold.
|
|
- `tests/sitl/`: host-side simulation and deterministic verification scaffolding.
|
|
- `tests/hitl/`: hardware-in-the-loop scaffolding.
|
|
- `scripts/`: repository validation and developer helper scripts.
|
|
|
|
## Spec Infrastructure
|
|
|
|
Formal specs should be colocated with the code or board package they govern.
|
|
|
|
- Implementation-linked specs should use stable sidecar filenames such as `control_loop.spec.md` next to the related module or package.
|
|
- Version history should live inside the same spec file as additional spec entries, not in the filename.
|
|
- Each appended spec entry should begin with version marker such as `# --- version: 0.1.0 ---`.
|
|
- Inside a spec entry, `#` is reserved for version markers and content headings should start at `##`.
|
|
- Each file-backed Rust module requires a same-name `.spec.md` sidecar.
|
|
- Modules that intentionally have no formal specification must declare `no_spec!("reason");` at module scope.
|
|
- Missing sidecars and modules that have both a sidecar and `no_spec!(...)` fail the build.
|
|
|
|
Example:
|
|
|
|
```rust
|
|
use kaptan_spec::no_spec;
|
|
|
|
no_spec!("Crate root declares child modules only.");
|
|
```
|