azaion/gps-denied-onboard

Fork 0

mirror of https://github.com/azaion/gps-denied-onboard.git synced 2026-06-21 09:01:14 +00:00

Files

T

Oleksandr Bezdieniezhnykh 1f634c2604

ci/woodpecker/push/02-build-push Pipeline failed

Details

Update demo replay validation and testing documentation

- Modified the autodev state to reflect the current testing phase and details of the new `jetson-e2e` tests.
- Enhanced the "How to Test" documentation to provide clearer instructions on the demo replay validation process, including video and tlog alignment steps.
- Updated architectural documentation to include the new demo replay operator flow and its dependencies.
- Documented the removal of deprecated auto-sync features and clarified the operator-facing UI for replay validation.
- Added new entries in the dependencies table for upcoming tasks related to the demo replay flow.

These changes improve clarity and usability for operators and developers working with the demo replay system.

2026-06-20 11:24:43 +03:00

2.7 KiB

Raw Blame History

System Flows Template

Use this template for the system flows document. Save as _docs/02_document/system-flows.md. Individual flow diagrams go in _docs/02_document/diagrams/flows/flow_[name].md.

# [System Name] — System Flows

## Flow Inventory

| # | Flow Name | Trigger | Primary Components | Criticality |
|---|-----------|---------|-------------------|-------------|
| F1 | [name] | [user action / scheduled / event] | [component list] | High/Medium/Low |
| F2 | [name] | | | |
| ... | | | | |

## Flow Dependencies

| Flow | Depends On | Shares Data With |
|------|-----------|-----------------|
| F1 | — | F2 (via [entity]) |
| F2 | F1 must complete first | F3 |

---

## Flow F1: [Flow Name]

### Description

[1-2 sentences: what this flow does, who triggers it, what the outcome is]

### Preconditions

- [Condition 1]
- [Condition 2]

### Sequence Diagram

```mermaid
sequenceDiagram
    participant User
    participant ComponentA
    participant ComponentB
    participant Database

    User->>ComponentA: [action]
    ComponentA->>ComponentB: [call with params]
    ComponentB->>Database: [query/write]
    Database-->>ComponentB: [result]
    ComponentB-->>ComponentA: [response]
    ComponentA-->>User: [result]

Flowchart

flowchart TD
    Start([Trigger]) --> Step1[Step description]
    Step1 --> Decision{Condition?}
    Decision -->|Yes| Step2[Step description]
    Decision -->|No| Step3[Step description]
    Step2 --> EndNode([Result])
    Step3 --> EndNode

Data Flow

Step	From	To	Data	Format
1	[source]	[destination]	[what data]	[DTO/event/etc]
2

Error Scenarios

Error	Where	Detection	Recovery
[error type]	[which step]	[how detected]	[what happens]

Performance Expectations

Metric	Target	Notes
End-to-end latency	[target]	[conditions]
Throughput	[target]	[peak/sustained]

Flow F2: [Flow Name]

(repeat structure above)


---

## Mermaid Diagram Conventions

Follow these conventions for consistency across all flow diagrams:

- **Participants**: use component names matching `components/[##]_[name]`
- **Node IDs**: camelCase, no spaces (e.g., `validateInput`, `saveOrder`)
- **Decision nodes**: use `{Question?}` format
- **Start/End**: use `([label])` stadium shape
- **External systems**: use `[[label]]` subroutine shape
- **Subgraphs**: group by component or bounded context
- **No styling**: do not add colors or CSS classes — let the renderer theme handle it
- **Edge labels**: wrap special characters in quotes (e.g., `-->|"O(n) check"|`)

2.7 KiB Raw Blame History